Asymetrisk dirigering – orsaker och effekter?

Jag skulle rekommendera att du tittar på First Hop Redundancy Protocols som HSRP eller VRRP.

Att ha två gateways kan faktiskt vara en mycket bra nätverksdesign, för om en router skulle misslyckas kan den andra routern ta Som du är medveten om är det dock inte lätt att göra denna övergång om du måste göra en manuell omkonfigurering av varje klient i ett undernät.

Protokoll som HSRP (eller VRRP om om du inte har Cisco-utrustning) kan du ha två (eller fler) routrar (eller L3-switche s) i ett undernät delar en enda IP-adress. Du kommer att ha din första router med adressen .2, den andra med adressen .3 och en ”virtuell IP-adress” .1 som båda routrarna är medvetna om genom konfiguration. När den primära routern misslyckas, kan upptäcka detta och ta över den virtuella IP-adressen, vilket betyder att dina kunder bara behöver ha .1 konfigurerad som sin gateway och du är bra att gå.

När det gäller routing-design skulle det beror till stor del på den aktuella installationen. Det är möjligt att båda gatewayerna leder till samma Internet-kant, i vilket fall du kanske inte har problem. Asymmetrisk routing kan vara dålig, främst för att du riskerar att paket levereras i fel ordning, men återigen beror mycket på topologin du pratar om.

Massor av designprinciper antyds i det jag just sa. Jag föreslår att du undersöker båda protokollen och bestämmer vad som är bäst för din miljö. Om du använder Cisco-redskap är HSRP en mycket använd och välförstått metod för att lösa detta problem.

Kommentarer

• och don ’ glöm inte att det också finns GLBP som gör samma sort HSRP / VRRP (bra kinda) men tillåter båda portar för att faktiskt belasta balansera trafik. Blir lite svårare att felsöka ibland eftersom vissa klienter kan vara på R1 och andra kan vara på R2
• @mierdin, asymmetrisk routing har inget att göra med paketbeställning … omordning kommer vanligtvis som resultat av flervägsrutter för samma prefix …

Hela internet bygger på asymmetrisk routing , så det är väldigt vanligt. Kunder är intresserade av gränssnittet som de får paketet på och källan till paketet, inte vilken router som skickade det till dem på det gränssnittet.

Asymmetrisk routing kan dock bli problematisk när enheter som håller reda på tillstånd (särskilt brandväggar) och NAT är inblandade, men så vitt jag kan säga så är det inte fallet i ditt exempel.

Kommentarer

• Det kan också vara ett problem när du kör någon form av vidarebefordran. Annars är det inte så stort av ett problem
• Varför skulle det vara ett problem? Rutten existerar och matchar gränssnitten, så även strikt RPF skulle inte ’ t trigger här.
• om en router har två externa gränssnitt med paket som går ut en väg ( följer IGP) och kommer tillbaka till en annan, skulle det släppa det paketet. Det inkommande paketet skulle misslyckas med en strikt RPF-kontroll, om inte naturligtvis kostnaderna är lika

Nätverksklienter identifiera trafikflöden baserat på kombinationen av fyra värden:

• Källadress
• Källport
• Destinationsadress
• Destinationsport

För varje annan anslutning bildar de fyra värdena ovan en annan kombination som används för att matcha svarspaketen till rätt flöde.Som du kan se ingår inte gatewayen eller nästa hoppadress i listan och därför bryr sig klienten inte om ett paket kommer tillbaka genom samma gateway som det använde för att skicka sina paket. Så nätverksklienter bryr sig inte om assymmetrisk dirigering så snart de kan ta emot trafiken från fjärranslutningen. Egentligen utformades TCP / IP ursprungligen för att stödja assymmetrisk routing.

Men om vi fokuserar på mellanliggande nätverksenheter tolereras inte assymmetrisk routing så snart du använder någon enhet / teknik som behöver se alla paket i en anslutning för att ge en viss funktionalitet. Till exempel: NAT, statliga brandväggar eller några WAN-optimatorer. Assymmetrisk dirigering i ett sådant scenario skulle orsaka att antingen den avsedda funktionaliteten inte tillhandahålls eller, till och med värst, att paket släpps vilket gör kommunikationen omöjlig.

Jag håller med om svaren framför mig, men jag måste lägga till något: om det finns någon filtrering på någon av portarna, eller på något hopp som skickas via endast en av de två portarna, kommer det troligtvis att uppstå problem! (humle som skickas via båda gateways, såsom källmaskinen, destinationsmaskinen och alla ”gemensamma för båda gateway-banorna”, berör inte följande scenarier)

Till exempel om A skicka paket till B via gateway1, och paket returnerar via gateway2, då är det mycket troligt att svarpaket kommer att tappas om gateway2 gör filtrering (eftersom gatewayen inte såg det initierande anslutningspaketet, så det förväntar sig inte något svar , alltså om destinationspaketet för svarspaketet vanligtvis filtreras kommer det att filtreras.)

(Det finns naturligtvis många liknande scenarier)

Andra två områden där asymmetriska rutter kommer att orsaka problem är de: 1. MTU-upptäckt – om den minsta MTU-en av de två vägarna skiljer sig åt kan slutpunkt MTU-sökning upptäcka resultera i en största av de två MTU, vilket i sin tur kommer att leda till att paket med maximal storlek tappas. Till exempel om en väg går genom en VPN-tunnel och den andra inte, VPN-tunneln kommer att ha en mindre MTU. ping fungerar bra, men överföring av stora filer misslyckas konsekvent. 2. Felsökning av anslutningar blir svårare om en av de två vägarna bryts men den andra inte. God gammal ”traceroute” kommer inte att vara någon hjälp alls, eftersom den inte kommer att kunna upptäcka mellanvägs omvända banor, såvida den inte utövas från båda sidor av anslutningen, vilket kräver en ledningskanal utanför bandet …