Split – brain BGP problem

Czy posiadasz swoją adresację (masz własne PI)? Być może jesteś operatorem? Czy w Twojej sieci znajduje się kilka routerów brzegowych (dwa lub więcej), terminujących sesje eBGP? Czy każdy z nich ogłasza Twój (Twoje) prefiks(y) do innych peer’ów eBGP (operatorów)? Jeśli wszystkie odpowiedzi są twierdzące lub jeśli planujesz wdrożyć takie rozwiązanie, ten artykuł jest właśnie dla Ciebie.

Schemat funkcjonowania

Posłużmy się prostym schematem, by lepiej zrozumieć i dostrzec problem.

Prefiks naszego Customera to 50.50.50.0 /24. Rozgłaszany jest przez protokół BGP z obu routerów, odpowiednio do R1-ISP oraz R2-ISP. Sieć po stronie LAN została zaprezentowana w sposób trywialny przez przełącznik i komputer. Sieć po tej stronie może mieć dowolny charakter, np. składać się z wielu routerów działających pod kontrolą protokołów routingu multi-area OSPF oraz iBGP z funkcją route-reflector. Poniżej może działać MPLS/VPLS (Artykuł na temat VPLS).

Z rysunku jasno wynika, że ruch z/do komputera może wychodzić/wracać przez dowolne routery. Może np. wyjść przez R1-CUSTOMER, dalej R1-ISP, dotrzeć do serwera docelowego i wrócić tą samą ścieżką. Ruch kliencki może też wyjść przez R2-CUSTOMER, R2-ISP, a wrócić przez R1-ISP i R1-CUSTOMER (zgodnie ze schematem). Na to, którędy ruch będzie płynął wpływa ogrom czynników, w szczególności parametry BGP, tj. weight, local-preference, ilość prepend’ów w atrybucie as-path, czy też konfiguracja od strony sieci LAN – np. HSRP.

Strata komunikacji od strony LAN

Co w przypadku, gdy stracimy komunikację do jednego z routerów (w tym przypadku R1) od strony LAN? Wszelkie protokoły dynamicznego (i/lub statycznego) routingu od strony LAN przestają funkcjonować. Ruch wychodzący od komputera będzie obsłużony. Natomiast skoro nasz prefiks 50.50.50.0 /24 jest w dalszym ciągu rozgłaszany przez oba routery i jeśli ruch wróci do nas przez R1, mamy problem, ponieważ będzie on dropowany. Pierwsze naturalne rozwiązanie, które się nasuwa to warunkowe rozgłaszanie prefiksu, np. w zależności od stanu łącza lub obecności danych tras w tabeli routingu. Lepsze to niż nic, jednak potrzeba trochę czasu zanim taka informacja rozpropaguje się po wszystkich routerach na całym świecie uczestniczących w protokole BGP.

Rozwiązanie to zapasowy tunel GRE

Rozwiązaniem jest zapasowy tunel GRE między routerami, zestawiony przez Internet. W tunelu mamy dokładnie te same protokoły, co w sieci LAN, tj. np. OSPF i iBGP. Oczywiście należy odpowiednio pogorszyć ruch w tym tunelu, np. przez nadanie gorszego kosztu. Dzięki takiemu rozwiązaniu w razie awarii cały ruch powrotny będzie tunelowany do R2, gdzie zostanie odpowiednio przeroutowany do sieci LAN.

W Network Expert realizowaliśmy już podobne projekty oraz pomagaliśmy naszym Klientom. Jeśli zatem potrzebne jest wsparcie przy rozwiązaniu podobnego problemu – zapraszamy serdecznie do kontaktu.