Asymetrisk ruting – årsaker og effekter?

Jeg vil anbefale deg å se på First Hop Redundancy Protocols som HSRP eller VRRP.

Å ha to gateways kan faktisk være en veldig god nettverksdesign, for hvis en ruter skulle mislykkes, kan den andre ruteren ta Som du er klar over, er det imidlertid ikke lett å gjøre denne overgangen hvis du må foreta en manuell omkonfigurering av hver klient på et undernett.

Protokoller som HSRP (eller VRRP hvis du har ikke-Cisco-utstyr) kan du ha to (eller flere) rutere (eller L3-switche s) på et subnett dele en enkelt IP-adresse. Du vil ha din første ruter med en adresse på .2, den seond med en adresse på .3 og en «virtuell IP-adresse» på .1 som begge rutere er klar over gjennom konfigurering. Når den primære ruteren mislykkes, vil den sekundære er i stand til å oppdage dette og ta over den virtuelle IP-adressen, noe som betyr at kundene dine bare trenger å ha .1 konfigurert som gateway, og at du er klar til å gå.

Når det gjelder rutingdesign, ville det avhenger i stor grad av gjeldende oppsett. Det er mulig at begge gatewayene fører til den samme internettkanten, i så fall har du kanskje ikke noe problem. Asymmetrisk ruting kan være dårlig, hovedsakelig fordi du risikerer at pakker blir levert i feil rekkefølge, men igjen, avhenger i stor grad av topologien. du snakker om.

Mange designprinsipper antydet i det jeg nettopp sa. Jeg foreslår at du undersøker begge protokollene, og bestemmer hva som er best for miljøet ditt. Hvis du bruker Cisco-utstyr, er HSRP en mye brukt og godt forstått metode for å løse dette problemet.

Kommentarer

• og don ‘ t glemmer at det også er GLBP som gjør det samme slags HSRP / VRRP (vel litt) men tillater begge deler gateways til faktisk å balansere trafikk. Blir bare litt vanskeligere å feilsøke til tider, da noen klienter kan være på R1 og andre kan være på R2
• @mierdin, asymmetrisk ruting har ingenting å gjøre med pakkeordning … ombestilling kommer vanligvis som resultat av flerveisruter for samme prefiks …

Hele internett er bygget på asymmetrisk ruting , så det er veldig vanlig. Klienter er interesserte i grensesnittet de mottar pakken på og kilden til pakken, ikke hvilken ruter som sendte den til dem på det grensesnittet.

Asymmetrisk ruting kan imidlertid bli problematisk når enheter som holder styr på tilstanden (spesielt brannmurer) og NAT er involvert, men så vidt jeg kan si er dette ikke tilfelle i eksemplet ditt.

Kommentarer

• Det kan også være et problem når du kjører en slags omvendt veioverføring. Ellers er det ikke så stort et problem
• Hvorfor ville det være et problem? Ruten eksisterer og samsvarer med grensesnittene, så selv streng RPF ville ikke ‘ t utløser her.
• hvis en ruter har to eksterne grensesnitt med pakker som går ut en vei ( følger IGP) og kommer tilbake til en annen, vil det slippe den pakken. Den innkommende pakken mislykkes med en streng RPF-sjekk, med mindre selvfølgelig kostnadene er like

Nettverksklienter identifiser trafikkflyter basert på kombinasjonen av fire verdier:

• Kildeadresse
• Kildeport
• Destinasjonsadresse
• Destinasjonsport

For hver annen forbindelse danner de fire verdiene ovenfor en annen kombinasjon som brukes til å matche svarpakker til riktig flyt.Som du kan se, inngår ikke gatewayen eller neste-hop-adressen i listen, og klienten bryr seg derfor ikke om en pakke kommer tilbake gjennom den samme gatewayen som den pleide å sende pakkene. Så, nettverksklienter bryr seg ikke om assymmetrisk ruting så snart de kan motta trafikken fra den eksterne enden. Egentlig ble TCP / IP opprinnelig designet for å støtte assymmetrisk ruting.

Men hvis vi fokuserer på mellomliggende nettverksenheter, tolereres ikke assymmetrisk ruting så snart du bruker en hvilken som helst enhet / teknologi som trenger å se alle pakker i en forbindelse for å gi en gitt funksjonalitet. For eksempel: NAT, stateful firewalls eller noen WAN-optimaliserere. Assymmetrisk ruting i et slikt scenario vil føre til at enten den tiltenkte funksjonaliteten ikke blir gitt, eller til og med i verste fall, at pakker faller, noe som gjør kommunikasjon umulig.

Jeg er enig i svarene foran meg, men jeg må legge til noe: hvis det er filtrering på noen av gatewayene, eller på et hopp som bare sendes via en av de to gatewayene, vil det sannsynligvis oppstå problemer! (humle som sendes via begge gatewayene, for eksempel kildemaskinen, destinasjonsmaskinen og alle «felles for begge gateway-stiene», er ikke opptatt av følgende scenarier)

For eksempel hvis A send pakker til B gjennom gateway1, og pakker returnerer via gateway2, så er det høyst sannsynlig at svarpakken vil bli droppet hvis gateway2 gjør filtrering (fordi den gatewayen ikke så den initierende tilkoblingspakken, så den forventer ikke svar , hvis destinasjonen / porten til svarpakken vanligvis blir filtrert, vil den bli filtrert.)

(Det er selvfølgelig mange lignende scenarier)

Andre to områder der asymmetriske ruter vil forårsake problemer, er de: 1. MTU-oppdagelse – hvis den minste MTU-en av de to banene er forskjellige, kan endepunkt-MTU-oppdagelse resultere i en største av de to MTU-ene, som igjen vil føre til at pakker med maksimal størrelse slippes. For eksempel hvis den ene stien går gjennom en VPN-tunnel og den andre ikke, VPN-tunnelen vil ha en mindre MTU. ping fungerer bra, men overføring av store filer mislykkes konsekvent. 2. Feilsøking av tilkoblingsmuligheter vil være vanskeligere hvis den ene av de to stiene er ødelagt, men den andre ikke. Gode, gamle «traceroute» vil ikke være til hjelp i det hele tatt, da det ikke vil være i stand til å oppdage mellomliggende punkter med omvendt vei, med mindre det utøves fra begge sider av forbindelsen, noe som krever en administrasjonskanal utenfor bandet …