Het komt voor dat ik klanten tegenkom die wat ik definieer als een “asymmetrische routing” in hun netwerken hebben. Simpel gezegd, ze hebben twee gateways op hetzelfde IP-subnet. De clients zijn geconfigureerd om naar één gateway te wijzen (d.w.z. 172.16.1.1), maar er is een ander apparaat (d.w.z. 172.16.1.2) dat verbinding maakt en ergens naartoe leidt. Meestal heb ik dit soort instellingen gezien als er 2 verschillende soorten WAN-verbindingen zijn: 1 internetverbinding en 1 zakelijke MPLS-verbinding.
Persoonlijk voel ik me niet aangetrokken tot het bovenstaande soort netwerkontwerp: elk subnet moet één en slechts één gateway hebben. Vanuit mijn oogpunt kan het bovenstaande scenario enkele problemen opleveren voor clients, omdat ze een pakket naar hun standaardgateway (172.16.1.1) sturen en die pakketten worden vervolgens doorgestuurd naar de andere router (172.16.1.2) en wanneer ze worden beantwoord bereiken, bereiken ze de klant door simpelweg via 172.16.1.2. De klanten zouden of mogen verwachten dat de antwoordpakketten afkomstig zijn van 172.16.1.1, of heb ik het hier mis?
Ik zou graag uw mening en technische opvattingen over deze kwestie hebben.
Opmerkingen
- Heeft een antwoord u geholpen? Zo ja, dan moet u het antwoord accepteren zodat de vraag ‘ niet behoudt voor altijd opduiken, op zoek naar een antwoord. Je kunt ook je eigen antwoord posten en accepteren.
Answer
Ik zou je aanraden First Hop Redundancy Protocols zoals HSRP of VRRP te bekijken.
Eigenlijk kan het hebben van twee gateways een heel goed netwerkontwerp zijn, want als een router uitvalt, kan de andere router enigszins naadloos over.
Zoals u weet, is het echter niet gemakkelijk om deze overgang te maken als u elke client op een subnet handmatig moet herconfigureren.
Protocollen zoals HSRP (of VRRP als je hebt niet-Cisco-apparatuur), kun je twee (of meer) routers (of L3-switche s) op een subnet delen een enkel IP-adres. Je hebt je eerste router met een adres van .2, de tweede met een adres van .3 en een virtueel IP-adres van .1 waarvan beide routers op de hoogte zijn via de configuratie. Als de primaire router uitvalt, wordt de secundaire is in staat om dit te detecteren en het virtuele IP-adres over te nemen, wat betekent dat uw klanten .1 geconfigureerd moeten hebben als hun gateway en u bent klaar om te gaan.
In termen van routing-ontwerp zou dat grotendeels afhankelijk van de huidige opstelling. Het is mogelijk dat beide gateways naar dezelfde internetrand leiden, in welk geval u geen probleem heeft. Asymmetrische routering kan slecht zijn, vooral omdat u het risico loopt dat pakketten in de verkeerde volgorde worden afgeleverd, maar nogmaals, hangt sterk af van de topologie waar je het over hebt.
Veel ontwerpprincipes geïmpliceerd in wat ik net zei. Ik raad u aan beide protocollen te onderzoeken en te bepalen wat het beste is voor uw omgeving. Als u Cisco-apparatuur gebruikt, is HSRP een veelgebruikte en goed begrepen methode om dit probleem op te lossen.
Opmerkingen
- en niet ‘ vergeten dat er ook GLBP is die hetzelfde doet als HSRP / VRRP (nou ja, een beetje) maar beide toestaat gateways om verkeer daadwerkelijk te verdelen. Het wordt soms een beetje moeilijker om te debuggen, omdat sommige clients R1 kunnen gebruiken en andere R2.
- @mierdin, asymmetrische routing heeft niets te maken met het opnieuw ordenen van pakketten … herordenen komt meestal als de resultaat van routes met meerdere paden voor hetzelfde voorvoegsel …
Antwoord
Het hele internet is gebouwd op asymmetrische routering , dus het is heel gebruikelijk. Cliënten zijn geïnteresseerd in de interface waarop ze het pakket ontvangen en de bron van het pakket, niet welke router het op die interface aan hen heeft doorgegeven.
Asymmetrische routering kan echter problematisch worden wanneer apparaten de status (vooral firewalls) en NAT bijhouden, maar voor zover ik kan nagaan is dit in uw voorbeeld niet het geval.
Opmerkingen
- Het kan ook een probleem zijn wanneer u een soort reverse path forwarding uitvoert. Anders is het niet zon groot probleem.
- Waarom zou dat een probleem zijn? De route bestaat en komt overeen met de interfaces, dus zelfs strikte RPF zou hier niet ‘ worden geactiveerd.
- als een router twee externe interfaces heeft met pakketten die in één richting uitgaan ( na IGP) en terugkomend in een ander, zou het dat pakket laten vallen. Het inkomende pakket zou een strikte RPF-controle niet doorstaan, tenzij de kosten natuurlijk gelijk zijn
Answer
Netwerkclients verkeersstromen identificeren op basis van de combinatie van 4 waarden:
- Bronadres
- Bronpoort
- Bestemmingsadres
- Bestemmingspoort
Voor elke verschillende verbinding vormen de 4 bovenstaande waarden een andere combinatie die wordt gebruikt om de antwoordpakketten aan de juiste stroom te matchen.Zoals je kunt zien, is het gateway- of next-hop-adres niet opgenomen in de lijst en daarom maakt het de client niet uit of een pakket terugkomt via dezelfde gateway als waarmee het zijn pakketten heeft verzonden. Netwerkclients geven dus niet om assymmetrische routering zodra ze het verkeer van de andere kant kunnen ontvangen. Eigenlijk is TCP / IP oorspronkelijk ontworpen om assymmetrische routering te ondersteunen.
Als we ons echter concentreren op tussenliggende netwerkapparaten, wordt assymmetrische routering niet getolereerd zodra u een apparaat / technologie gebruikt die alle pakketten in een verbinding moet zien om een bepaalde functionaliteit te bieden. Bijvoorbeeld: NAT, stateful firewalls of sommige WAN-optimalisators. Assymmetrische routering in een dergelijk scenario zou ervoor zorgen dat de beoogde functionaliteit niet wordt geleverd of, erger nog, dat pakketten worden weggelaten, waardoor communicatie onmogelijk wordt.
Antwoord
Ik ben het eens met de antwoorden die voor me liggen, maar ik moet iets toevoegen: als er gefilterd wordt op een van de gateways, of op een hop die wordt doorgegeven via slechts 1 van de 2 gateways, zullen er waarschijnlijk problemen optreden! (hops die via beide gateways worden doorgegeven, zoals de bronmachine, de bestemmingsmachine en alle “gemeenschappelijk voor beide gatewaypaden” hops, hebben geen betrekking op de volgende scenarios)
Bijvoorbeeld, als A verzend pakketten naar B via gateway1, en pakketten komen terug via gateway2, dan is het zeer waarschijnlijk dat het antwoordpakket zal worden verwijderd als gateway2 bezig is met filteren (omdat die gateway het initiërende verbindingspakket niet heeft gezien, dus het verwacht geen antwoord , dus als de dest / port van het antwoordpakket meestal wordt gefilterd, wordt het gefilterd.)
(Er zijn natuurlijk veel vergelijkbare scenarios)
Antwoord
Andere twee gebieden waar asymmetrische routes problemen zullen veroorzaken, zijn: 1. MTU-detectie – als de kleinste MTU van de twee paden verschilt, kan MTU-paddetectie op het eindpunt resulteren in een grootste van de twee MTUs, wat op zijn beurt zal resulteren in het laten vallen van pakketten met maximale grootte. Als het ene pad bijvoorbeeld door een VPN-tunnel gaat en het andere niet, de VPN-tunnel heeft een kleinere MTU. ping werkt prima, maar het overzetten van grote bestanden zal consistent mislukken. 2. Het oplossen van verbindingsproblemen zal moeilijker zijn als een van de twee paden is verbroken, maar het andere niet. De goede oude “traceroute” zal helemaal geen hulp zijn, omdat het de tussenliggende punten van het omgekeerde pad niet zal kunnen detecteren, tenzij het wordt uitgeoefend vanaf beide zijden van de verbinding, wat een out-of-band beheerkanaal vereist …