Det sker, at jeg løber på tværs af kunder, der har det, jeg definerer som en “asymetrisk routing” i deres netværk. Simpelthen sagt, de har to gateways på det samme IP-undernet. Klienterne er konfigureret til at pege på en gateway (dvs. 172.16.1.1), men der er en anden enhed (dvs. 172.16.1.2), der forbinder og ruter til et eller andet sted. For det meste har jeg set denne form for opsætning, når der er 2 forskellige typer WAN-forbindelser: 1 internetforbindelse og 1 MPLS-forbindelse til virksomheden.
Jeg er personligt ikke tiltrukket af ovennævnte form for netværksdesign: hver undernet skal have en og kun en gateway. Fra mit synspunkt kan ovenstående scenarie skabe nogle problemer for klienter, fordi de sender en pakke til deres standardgateway (172.16.1.1), og disse pakker videresendes derefter til den anden router (172.16.1.2), og når de får svar til, når de klienten ved blot at gå igennem 172.16.1.2. Kunderne ville eller skulle forvente, at svarpakkerne kommer fra 172.16.1.1, eller tager jeg fejl her?
Jeg ville være glad for at have dine meninger og tekniske synspunkter om dette problem.
Kommentarer
- Har noget svar hjulpet dig? Hvis ja, skal du acceptere svaret, så spørgsmålet ikke holder ‘ dukker op for evigt og leder efter et svar. Alternativt kan du sende og acceptere dit eget svar.
Svar
Jeg vil anbefale, at du ser på First Hop Redundancy Protokoller som HSRP eller VRRP.
At have to gateways kan faktisk være et meget godt netværksdesign, for hvis en router skulle fejle, kan den anden router tage Som du “ved, er det ikke let at foretage denne overgang, hvis du skal foretage en manuel omkonfiguration af hver klient på et undernet.
Protokoller som HSRP (eller VRRP hvis du har ikke-Cisco gear) giver dig mulighed for at have to (eller flere) routere (eller L3 switche s) på et subnet deler en enkelt IP-adresse. Du får din første router med en adresse på 2, den seond med en adresse på 3 og en “virtuel IP-adresse” på .1, som begge routere er opmærksomme på gennem konfiguration. Når den primære router fejler, er den sekundære er i stand til at opdage dette og overtage den virtuelle IP-adresse, hvilket betyder, at dine kunder bare skal have .1 konfigureret som deres gateway, og du er klar til at gå.
Med hensyn til routing-design ville det afhænger stort set af den aktuelle opsætning. Det er muligt, at begge gateways fører til den samme internetkant, i hvilket tilfælde du muligvis ikke har et problem. Asymmetrisk routing kan være dårlig, primært fordi du risikerer at pakker leveres i den forkerte rækkefølge, men igen afhænger meget af topologien. du taler om.
Masser af designprincipper antydet i det, jeg lige sagde. Jeg foreslår, at du undersøger begge protokoller og bestemmer, hvad der er bedst for dit miljø. Hvis du bruger Cisco-udstyr, er HSRP en meget anvendt og velforstået metode til at løse dette problem.
Kommentarer
- og don ‘ t glemmer, at der også er GLBP, der gør det samme slags HSRP / VRRP (godt kinda) men tillader begge gateways til faktisk belastningsbalanceretrafik. Bliver bare lidt sværere at debugge til tider, da nogle klienter muligvis er på R1, og andre måske på R2
- @mierdin, asymmetrisk routing har intet at gøre med pakkeordre … ombestilling kommer typisk som resultat af flervejsruter til det samme præfiks …
Svar
Hele internettet er bygget på asymmetrisk routing , så det er meget almindeligt. Klienter er interesserede i grænsefladen, de modtager pakken på, og kilden til pakken, ikke hvilken router der sendte den til dem på den grænseflade.
Asymmetrisk routing kan dog blive problematisk når enheder, der holder styr på tilstand (især firewalls) og NAT er involveret, men så vidt jeg kan se, er dette ikke tilfældet i dit eksempel.
Kommentarer
- Det kan også være et problem, når du kører en form for videresendelse af omvendt vej. Ellers er det ikke så stort et problem
- Hvorfor ville det være et problem? Ruten eksisterer og matcher grænsefladerne, så selv streng RPF ville ikke ‘ t trigger her.
- hvis en router har to eksterne grænseflader med pakker, der går ud en vej ( efter IGP) og kommer tilbage til en anden, ville det tabe den pakke. Den indgående pakke ville mislykkes med en streng RPF-kontrol, medmindre selvfølgelig omkostningerne er lige
Svar
Netværksklienter identificere trafikstrømme baseret på kombinationen af 4 værdier:
- Kildeadresse
- Kildeport
- Destinationsadresse
- Destinationsport
For hver anden forbindelse danner de 4 værdier ovenfor en anden kombination, der bruges til at matche svarpakkerne til den rigtige strøm.Som du kan se, er gatewayen eller next-hop-adressen ikke inkluderet på listen, og derfor er klienten ligeglad med, om en pakke kommer tilbage gennem den samme gateway, som den brugte til at sende sine pakker. Så netværksklienter er ligeglade med assymmetrisk routing, så snart de kan modtage trafikken fra den fjerne ende. Faktisk blev TCP / IP oprindeligt designet til at understøtte assymmetrisk routing.
Hvis vi imidlertid fokuserer på mellemliggende netværksenheder, tolereres ikke assymmetrisk routing, så snart du bruger en enhed / teknologi, der skal se alle pakker i en forbindelse for at give en given funktionalitet. For eksempel: NAT, stateful firewalls eller nogle WAN-optimatorer. Assymmetrisk routing i et sådant scenario vil medføre, at enten den tilsigtede funktionalitet ikke leveres, eller endog værst, at pakker falder, hvilket gør kommunikation umulig.
Svar
Jeg er enig i svarene foran mig, men jeg er nødt til at tilføje noget: hvis der er nogen filtrering på nogen af gateways eller på et hop, der kun sendes via 1 af de 2 gateways, vil der sandsynligvis opstå problemer! (humle, der sendes via begge gateways, såsom kildemaskinen, destinationsmaskinen og ethvert “fælles for begge gateway-stier”, er ikke berørt af følgende scenarier)
For eksempel, hvis A send pakker til B gennem gateway1, og pakker vender tilbage via gateway2, så er det højst sandsynligt, at svarpakke vil blive droppet, hvis gateway2 foretager filtrering (fordi den gateway ikke kunne se den initierende forbindelsespakke, så den forventer ikke svar , hvis destinationen / porten på svarpakken normalt filtreres, filtreres den.)
(Der er selvfølgelig mange lignende scenarier)
Svar
Andre to områder, hvor asymmetriske ruter vil forårsage problemer, er disse: 1. MTU-opdagelse – hvis den mindste MTU af de to stier adskiller sig, kan slutpunkt MTU-sti-opdagelse resultere i en største af de to MTUer, hvilket igen vil resultere i tab af pakker med maksimal størrelse. F.eks. hvis den ene sti går gennem en VPN-tunnel og den anden ikke, VPN-tunnelen vil have en mindre MTU. ping fungerer fint, men overførsel af store filer mislykkes konsekvent. 2. Forbindelsesfejlfinding vil være sværere, hvis den ene af de to veje er brudt, men den anden ikke er. Gode gamle “traceroute” vil slet ikke være nogen hjælp, da det ikke vil være i stand til at detektere de omvendte sti mellemliggende punkter, medmindre det udøves fra begge sider af forbindelsen, hvilket kræver en out-of-band management kanal …