Routing asymetryczny – przyczyny i skutki?

Zalecałbym zapoznanie się z protokołami nadmiarowości pierwszego przeskoku, takimi jak HSRP lub VRRP.

Właściwie posiadanie dwóch bram może być bardzo dobrym projektem sieci, ponieważ jeśli router ulegnie awarii, drugi router może zająć nieco bezproblemowo. Jednakże, jak „zdajesz sobie sprawę”, nie jest łatwo dokonać tego przejścia, jeśli musisz ręcznie zmienić konfigurację każdego klienta w podsieci.

Protokoły takie jak HSRP (lub VRRP, jeśli masz sprzęt inny niż Cisco) pozwalają na posiadanie dwóch (lub więcej) routerów (lub przełącznika L3 s) w podsieci mają wspólny adres IP. Będziesz mieć swój pierwszy router z adresem .2, drugi z adresem .3 i „wirtualnym adresem IP” .1, o którym oba routery są świadome podczas konfiguracji. Gdy główny router ulegnie awarii, drugi jest w stanie to wykryć i przejąć wirtualny adres IP, co oznacza, że Twoi klienci muszą mieć tylko .1 skonfigurowany jako ich brama i jesteś gotowy do pracy.

Jeśli chodzi o projektowanie routingu, to w dużej mierze zależy od aktualnej konfiguracji. Jest możliwe, że obie bramy prowadzą do tego samego brzegu Internetu, w którym to przypadku możesz nie mieć problemu. Asymetryczny routing może być zły, głównie dlatego, że ryzykujesz dostarczenie pakietów w złej kolejności, ale znowu zależy to w dużej mierze od topologii o których mówisz.

Wiele zasad projektowych zawartych w tym, co właśnie powiedziałem. Proponuję zbadać oba protokoły i określić, co jest najlepsze dla Twojego środowiska. Jeśli używasz sprzętu Cisco, HSRP jest szeroko stosowaną i dobrze znaną metodą rozwiązania tego problemu.

Komentarze

• i nie ' nie zapominaj, że jest też GLBP, który robi to samo HSRP / VRRP (no cóż), ale pozwala na oba bramy faktycznie równoważące obciążenie ruchem. Czasami debugowanie staje się nieco trudniejsze, ponieważ niektórzy klienci mogą być na R1, a inni na R2
• @mierdin, asymetryczny routing nie ma nic wspólnego ze zmianą kolejności pakietów … zmiana kolejności zwykle pojawia się, gdy wynik tras wielościeżkowych dla tego samego prefiksu …

Cały internet jest oparty na routingu asymetrycznym , więc jest to bardzo częste. Klienci są zainteresowani interfejsem, przez który otrzymują pakiet i jego źródłem, a nie tym, który router przekazał im go przez ten interfejs.

Asymetryczny routing może być jednak problematyczny gdy zaangażowane są urządzenia śledzące stan (zwłaszcza zapory ogniowe) i NAT, ale o ile wiem, nie ma to miejsca w twoim przykładzie.

Komentarze

• Może to również stanowić problem, gdy używasz jakiegoś rodzaju przekierowania ścieżki wstecznej. W przeciwnym razie nie będzie to taki duży problem.
• Dlaczego miałby to być problem? Trasa istnieje i pasuje do interfejsów, więc nawet ścisły RPF nie byłby tutaj ' wyzwalany.
• jeśli router ma dwa zewnętrzne interfejsy z pakietami wychodzącymi w jedną stronę ( po IGP) i wracając do innego, porzuci ten pakiet. Przychodzący pakiet nie przeszedłby ścisłej kontroli RPF, chyba że oczywiście koszty są równe

Klienci sieci zidentyfikować przepływy ruchu na podstawie kombinacji 4 wartości:

• Adres źródłowy
• Port źródłowy
• Adres docelowy
• Port docelowy

4 powyższe wartości dla każdego innego połączenia tworzą inną kombinację, która jest używana do dopasowania pakietów odpowiedzi do właściwego przepływu.Jak widać, adres bramy lub następnego skoku nie znajduje się na liście i dlatego klient nie będzie się przejmował, czy pakiet wróci przez tę samą bramę, której użył do wysłania pakietów. Dlatego klienci sieci nie przejmują się routingiem asymetrycznym, gdy tylko mogą odebrać ruch z odległego końca. W rzeczywistości protokół TCP / IP został pierwotnie zaprojektowany do obsługi routingu asymetrycznego.

Jednakże, jeśli skupimy się na sieciowych urządzeniach pośredniczących, asymetryczny routing nie jest tolerowany, gdy tylko używasz dowolnego urządzenia / technologii, która potrzebuje zobaczyć wszystkie pakiety w połączeniu, aby zapewnić daną funkcjonalność. Na przykład: NAT, stanowe zapory ogniowe lub niektóre optymalizatory WAN. W takim scenariuszu routing asymetryczny spowodowałby albo niedostarczenie zamierzonej funkcji, albo, co gorsza, odrzucenie pakietów, uniemożliwiając komunikację.

Zgadzam się z odpowiedziami, które mam przed sobą, ale muszę coś dodać: jeśli na którejkolwiek bramce jest jakieś filtrowanie lub przeskok, który jest przekazywany tylko przez 1 z 2 bram, prawdopodobnie wystąpią problemy! (przeskoki, które są przekazywane przez obie bramy, takie jak maszyna źródłowa, maszyna docelowa i wszelkie przeskoki „wspólne dla obu ścieżek bram”, nie dotyczą następujących scenariuszy)

Na przykład, jeśli A wyślij pakiety do B przez bramę 1, a pakiety wrócą przez bramę 2, to jest wysoce prawdopodobne że pakiet odpowiedzi zostanie odrzucony jeśli bramka 2 filtruje (ponieważ ta brama nie widziała pakietu inicjującego połączenie, więc nie oczekuje odpowiedzi , więc jeśli docelowy / port pakietu odpowiedzi jest zwykle filtrowany, będzie filtrowany.)

(Oczywiście jest wiele podobnych scenariuszy)

Pozostałe dwa obszary, w których asymetryczne trasy będą powodować problemy, to: 1. Wykrywanie MTU – jeśli najmniejsza jednostka MTU z dwóch ścieżek różni się, może to spowodować wykrycie ścieżki MTU punktu końcowego. da największą z dwóch jednostek MTU, co z kolei spowoduje porzucenie pakietów o maksymalnym rozmiarze. Na przykład, jeśli jedna ścieżka przechodzi przez tunel VPN, a druga nie, tunel VPN będzie miał mniejszą jednostkę MTU. ping będzie działał dobrze, ale przesyłanie dużych plików będzie się powtarzać. 2. Rozwiązywanie problemów z łącznością będzie trudniejsze, jeśli jedna z dwóch ścieżek jest uszkodzona, a druga nie. Stary dobry „traceroute” nie będzie w ogóle pomocny, ponieważ nie będzie w stanie wykryć punktów pośrednich ścieżki zwrotnej, chyba że zostanie wykonany z obu stron połączenia, co wymaga pozapasmowego kanału zarządzania …