Előfordul, hogy olyan ügyfelekkel találkozom, akik hálózataikban az általam definiált “aszimmetrikus útválasztást” jelentik. Egyszerűen szólva: két átjárójuk van ugyanazon IP alhálózaton. Az ügyfelek úgy vannak konfigurálva, hogy egy átjáróra mutassanak (azaz 172.16.1.1), de van egy másik eszköz (azaz 172.16.1.2), amely összekapcsol és átirányít valahova. Leginkább akkor láttam ezt a fajta beállítást, amikor 2 különböző típusú WAN-kapcsolat létezik: 1 internetkapcsolat és 1 vállalati MPLS-kapcsolat.
Engem személy szerint nem vonz a fenti hálózati kialakítás: mindegyik az alhálózatnak egyetlen és egyetlen átjáróval kell rendelkeznie. Véleményem szerint a fenti forgatókönyv néhány problémát okozhat az ügyfelek számára, mert csomagot küldenek az alapértelmezett átjárójuknak (172.16.1.1), majd ezeket a csomagokat továbbítják a másik útválasztóra (172.16.1.2), és amikor választ kapnak a klienshez egyszerűen eljutnak a 172.16.1.2. Az ügyfelek azt várnák vagy számíthatnák a válaszcsomagokra, amelyek a 172.16.1.1-es verziótól származnak, vagy tévedek itt?
Örülnék, ha véleményed és technikai véleményed lenne erről a kérdésről.
Megjegyzések
- Segített valamilyen válasz? Ha igen, akkor fogadja el a választ, hogy a kérdés ne maradjon ‘ örökre felbukkan, és választ keres. Alternatív megoldásként elküldheti és elfogadhatja saját válaszát is.
Válasz
Azt javaslom, hogy nézzen utána az első hop redundancia protokolloknak, például a HSRP vagy a VRRP.
Valójában két átjáró megléte nagyon jó hálózati tervezés lehet, mert ha egy útválasztó meghibásodik, akkor a másik útválasztó is igénybe veheti kissé zökkenőmentesen. Azonban, amint tudatában van, nem könnyű ezt az átállást végrehajtani, ha manuálisan kell konfigurálnia az egyes klienseket egy alhálózaton.
Protokollok, mint például a HSRP (vagy a VRRP, ha nem Cisco felszereléssel rendelkezik) lehetővé teszi két (vagy több) útválasztó (vagy L3 kapcsoló) használatát s) egy alhálózaton egyetlen IP-címet oszt meg. Megvan az első útválasztója .2 címmel, a seond .3 címmel és .1 “virtuális IP-címmel”, amelyről mindkét útválasztó tud a konfiguráción keresztül. Amikor az elsődleges útválasztó meghibásodik, a másodlagos képes ezt észlelni és átvenni a virtuális IP-címet, ami azt jelenti, hogy az ügyfeleknek csak .1-et kell konfigurálniuk átjárójuknak, és máris jó.
Az útválasztási tervezés szempontjából ez nagyban függ az aktuális beállítástól. Lehetséges, hogy mindkét átjáró ugyanahhoz az internetes élhez vezet, ebben az esetben nem biztos, hogy problémája van. Az aszimmetrikus útválasztás rossz lehet, elsősorban azért, mert kockáztatja, hogy a csomagokat rossz sorrendben juttassák el, de ez ismét nagyban függ a topológiától beszélsz.
Rengeteg tervezési elv vonatkozik az imént mondottakra. Javaslom, hogy kutassa meg mindkét protokollt, és határozza meg, hogy mi a legjobb a környezetének. Ha Cisco felszerelést használ, a HSRP széles körben használt és jól ismert módszer a probléma megoldására.
Megjegyzések
- és ne ‘ ne felejtsük el, hogy létezik olyan GLBP is, amely ugyanazt a sorta dolgot csinálja, mint a HSRP / VRRP (jól, de mindkettőt) átjárók a ténylegesen terheléselosztó forgalomhoz. Néha kissé nehezebb hibakeresést végezni, mivel egyes ügyfelek R1, mások R2-n lehetnek
- @mierdin, az aszimmetrikus útválasztásnak semmi köze nincs a csomagok átrendezéséhez … az átrendezés általában a többutas útvonalak eredménye ugyanazon előtaghoz …
Válasz
Az egész internet aszimmetrikus útválasztásra épül , így nagyon gyakori. Az ügyfeleket érdekli az a felület, amelyen a csomagot kapják, és a csomag forrása, nem pedig az, hogy melyik útválasztó adta át nekik az adott felületen.
Az aszimmetrikus útválasztás azonban problematikussá válhat amikor az állapotot nyomon követő eszközök (különösen a tűzfalak) és a NAT érintettek, de amennyire meg tudom mondani, a példádban ez nem így van.
Megjegyzések
- Probléma lehet akkor is, ha valamilyen fordított útirányú továbbítást futtat. Egyébként nem olyan nagy kérdés
- Miért lenne ez probléma? Az útvonal létezik, és megegyezik az interfészekkel, így még a szigorú RPF ‘ sem váltaná ki itt.
- ha egy útválasztónak két külső felülete van, a csomagok egyfelé mennek ki ( IGP-t követve) és visszatérve egy másikba, eldobná azt a csomagot. A bejövő csomag nem felel meg az RPF szigorú ellenőrzésének, kivéve, ha a költségek természetesen megegyeznek.
Answer
Hálózati ügyfelek azonosítsa a forgalmi folyamatokat 4 érték kombinációja alapján:
- Forráscím
- Forrásport
- Célcím
- Célport
Minden egyes kapcsolathoz a fenti 4 érték különböző kombinációt alkot, amelyet a válaszcsomagok megfelelő áramlathoz illesztenek.Amint láthatja, az átjáró vagy a következő ugrás címe nem szerepel a listában, ezért az ügyfelet nem érdekli, hogy egy csomag ugyanazon az átjárón érkezik-e vissza, amelyen a csomagjait küldte. Tehát a hálózati ügyfelek nem törődnek az aszimmetrikus útvonallal, amint fogadják a forgalmat a távoli végről. Valójában a TCP / IP-t eredetileg az aszimmetrikus útválasztás támogatására tervezték.
Ha azonban a hálózati köztes eszközökre összpontosítunk, akkor az aszimmetrikus útvonalválasztás nem tolerálható, amint olyan eszközt / technológiát használ, amelynek az összes csomagot látnia kell egy adott kapcsolatban egy adott funkció biztosításához. Például: NAT, állapotos tűzfalak vagy néhány WAN-optimalizátor. Az aszimmetrikus útválasztás ilyen esetekben vagy a tervezett funkcionalitás hiányát eredményezi, vagy ami a legrosszabb, ha a csomagok elesnek, ami lehetetlenné teszi a kommunikációt.
Válasz
Egyetértek az előttem álló válaszokkal, de hozzá kell tennem valamit: ha az átjárók bármelyikén vagy bármelyik ugráson szűrés zajlik, amely a 2 átjáró közül csak az egyiken halad át, akkor valószínűleg problémák merülnek fel! (a két átjárón, például a forrásgépen, a célgépen és minden “mindkét átjáró útvonalán közös” komlón átjutó komló nem foglalkozik a következő esetekkel)
Például, ha A csomagokat küldjön B-nek az1-es átjárón keresztül, és a csomagok visszatérnek a 2-es átjárón keresztül, akkor nagyon valószínű, hogy a válaszcsomag eldobásra kerül, ha a 2-es átjáró szűrést végez (mert az az átjáró nem látta a kezdeményező kapcsolati csomagot, ezért nem várt választ) , így ha a válaszcsomag dest / portját általában szűrjük, akkor az is szűrni fog.)
(Természetesen sok hasonló forgatókönyv létezik)
Válasz
A másik két terület, ahol az aszimmetrikus útvonalak gondot okoznak, a következők: 1. MTU felfedezése – ha a két út közül a legkisebb MTU különbözik egymástól, akkor a végpont MTU útjának felfedezése a két MTU közül a legnagyobbat eredményezi, ami viszont maximális méretű csomagok eldobását eredményezi. Például, ha az egyik út egy VPN-alagúton megy keresztül, a másik pedig nem, a VPN alagút kisebb MTU-val rendelkezik. A ping jól fog működni, de a nagy fájlok átvitele következetesen sikertelen lesz. 2. A kapcsolódási hibaelhárítás nehezebb lesz, ha a két út egyike megszakad, a másik viszont nem. A jó öreg “traceroute” egyáltalán nem lesz segítség, mivel nem képes észlelni a fordított út közbenső pontjait, hacsak nem a kapcsolat mindkét oldaláról gyakorolják, amihez sávon kívüli irányítási csatornára van szükség …