Załóżmy hipotetyczną sytuację.
Mam dwa różne łącza vpls pomiędzy tymi samymi lokalizacjami, od dwóch różnych dostawców. Czy możliwe jest spięcie ich w jeden port-channel?
Chciałbym uzyskać działający link w przypadku awarii jednego z dostawców. Czy takie coś będzie działało i czy uzyskam w ten sposób redundantne połączenie między moimi lokalizacjami?
Jeśli błądzę, to czy da się to tymi środkami (2 lokalizacje, 2 switche, 2 łącza) zrealizować takie połączenie w inny sposób?
2 łącza vpls i port channel
Tak, jeżeli sprzęt dostawcy wspiera forwarding ramek LACP przez tunel PW/VPLS.kaps3 pisze:Załóżmy hipotetyczną sytuację.
Mam dwa różne łącza vpls pomiędzy tymi samymi lokalizacjami, od dwóch różnych dostawców. Czy możliwe jest spięcie ich w jeden port-channel?
Można też flex-link i realizację usługi w trybie active/standby.kaps3 pisze:Chciałbym uzyskać działający link w przypadku awarii jednego z dostawców. Czy takie coś będzie działało i czy uzyskam w ten sposób redundantne połączenie między moimi lokalizacjami?
Jeśli błądzę, to czy da się to tymi środkami (2 lokalizacje, 2 switche, 2 łącza) zrealizować takie połączenie w inny sposób?
Ja bym tylko chwilkę pomyślał nad tym, że w przypadku takiego kosmicznego etherchannela (jeden link przez Pułtusk, drugi przez Pabianice) mogą się pojawić pakiety out-of-order między linkami składowymi. W przypadku źle dobranego algorytmu hashowania i specyficznego systemu / aplikacji mogą być z tym problemy.
Algorytm hashowania nie jest per packet, więc efekt out of order nie wystąpi. Chyba, że jest jakiś producent sprzętu, który wspiera per packet load-balancing w etherchannel.mikrobi pisze:Ja bym tylko chwilkę pomyślał nad tym, że w przypadku takiego kosmicznego etherchannela (jeden link przez Pułtusk, drugi przez Pabianice) mogą się pojawić pakiety out-of-order między linkami składowymi. W przypadku źle dobranego algorytmu hashowania i specyficznego systemu / aplikacji mogą być z tym problemy.
Nie musi być per packet. Wystarczy że np. aplikacja robi loadbalancing między dwoma destination IP, a na channelu ustawimy dstIP loadbalancing (junior network consultant powiedział że będzie się lepiej loadbalance'owałogangrena pisze:Algorytm hashowania nie jest per packet, więc efekt out of order nie wystąpi. Chyba, że jest jakiś producent sprzętu, który wspiera per packet load-balancing w etherchannel.mikrobi pisze:Ja bym tylko chwilkę pomyślał nad tym, że w przypadku takiego kosmicznego etherchannela (jeden link przez Pułtusk, drugi przez Pabianice) mogą się pojawić pakiety out-of-order między linkami składowymi. W przypadku źle dobranego algorytmu hashowania i specyficznego systemu / aplikacji mogą być z tym problemy.
). Wówczas może być tak, że dwa pakiety wysłane kolejno do dstIP1 i dstIP2 dojdą w kolejności odwrotnej.Jeżeli jest taka aplikacja, to byłaby podatna nawet na prosty load-balancing w core nawet w przypadku tylko jednego PW. Czyli nie jest to wada architektury w oparciu o LACPo2xPW, ale źle skonstruowanej aplikacji, jeżeli nie ma ona np. numerów sekwencyjnych lub małą tolerancję na efekt, na który się wystawia.mikrobi pisze:Nie musi być per packet. Wystarczy że np. aplikacja robi loadbalancing między dwoma destination IP, a na channelu ustawimy dstIP loadbalancing (junior network consultant powiedział że będzie się lepiej loadbalance'owało
Chodzi o to, że nie mamy tutaj loadbalancingu w obrębie jednego systemu / sieci, ale poprzez dwóch niezależnych operatorów, gdzie potrafię sobie wyobrazić nawet w Polsce różnice w drodze sygnału na poziomie tysiąca kilometrów (szczególnie jak się u jednego coś przełączy w DWDMie na ścieżkę zapasową). Inaczej bym sobie tym przypadkiem głowy nie zaprzątał - ale ok - szukam dziury w całym.gangrena pisze:Jeżeli jest taka aplikacja, to byłaby podatna nawet na prosty load-balancing w core nawet w przypadku tylko jednego PW. Czyli nie jest to wada architektury w oparciu o LACPo2xPW, ale źle skonstruowanej aplikacji, jeżeli nie ma ona np. numerów sekwencyjnych lub małą tolerancję na efekt, na który się wystawia.mikrobi pisze:Nie musi być per packet. Wystarczy że np. aplikacja robi loadbalancing między dwoma destination IP, a na channelu ustawimy dstIP loadbalancing (junior network consultant powiedział że będzie się lepiej loadbalance'owało
Tak, ale w przypadku nawet jednego PW load-balancing w core oraz ECMP nie oznacza automatycznie ścieżki o tym samym opóźnieniu. Zwłaszcza, jeżeli byłby dodatkowo zastosowany MPLS-TE. A przecież, ktoś, kto bierze usługę w postaci 1xPW nawet nie zapytałby się SP o to, co jest w core, a tym bardziej ciężko byłoby mu wymóc ewentualne zmiany per PE lub per fragment sieci podkładowej. Mówiąc wprost nie sądzę by takie aplikacje istniały, a jeżeli istnieją, to i tak ich założenia architektoniczne byłyby znacznie bardziej ułomne, niż LACPo2xPWo2xSP.mikrobi pisze:Chodzi o to, że nie mamy tutaj loadbalancingu w obrębie jednego systemu / sieci, ale poprzez dwóch niezależnych operatorów, gdzie potrafię sobie wyobrazić nawet w Polsce różnice w drodze sygnału na poziomie tysiąca kilometrów (szczególnie jak się u jednego coś przełączy w DWDMie na ścieżkę zapasową). Inaczej bym sobie tym przypadkiem głowy nie zaprzątał - ale ok - szukam dziury w całym.
Poza tym dwóch operatorów, to wiesz, tylko multicast.
Odkopię trochę temat, bo mam podobny temat do rozgryzienia. Mamy dwa łącza VPLS między dwoma lokalizacjami ale od tego samego dostawcy i chcemy zrobić jak najbardziej elastyczne i automatyczne rozwiązanie dla ewentualnych awarii. Jeżeli ramek LACP nie da się przenieść to pozostaje tylko flex-link czy ewentualnie jest jeszcze coś w miarę sensownego?