Nie do końca martwe trasy BGP
https://medium.com/thousandeyes-engineering/bgp-zombies-part-i-why-they-matter-546e232c2c42
Podstawowym zadaniem BGP jest informowanie sąsiadów o dostępnych prefiksach, ich trasach oraz uaktualnianie tych informacji w razie zmiany.
W tym celu BGP posługuje się komunikatami: "Announcement", który opisuje drogę i cechy trasy do danego prefiksu, oraz "Withdrawal", służącym do wycofywania nieaktualnych już tras. Kiedy system autonomiczny AS1 przestaje być prawowitym właścicielem jakiegoś prefiksu, na przykład w wyniku sprzedaży tej puli nowemu operatorowi AS2, powinien wysłać komunikat wycofujący tę trasę.
"BGP Zombie" powstaje gdy część ruterów w innych AS-ach nie otrzymuje lub nie stosuje się do tej informacji i nadal utrzymuje stare trasy. Powodować to może nieprawidłowe kierowanie części ruchu, awarie oraz problemy z osiągalnością sieci.
Przyczyny zjawiska "BGP Zombies"
Pozostałości tras zombie mogą być spowodowane licznymi czynnikami. Najczęściej winę ponoszą błędy konfiguracyjne, oprogramowania bądź problemy sprzętowe uniemożliwiające właściwe rozpropagowanie wycofania trasy. Niekiedy winą jest również niekompatybilność urządzeń lub błędy samego protokołu BGP sprawiające, że update nie dociera do wszystkich urządzeń w sieci.
Ryzyko wystąpienia "BGP Zombies" zwiększają między innymi:
- Złożona topologia sieci i duża liczba routerów
- Przestarzałe lub wadliwe oprogramowanie lub sprzęt
- Zbyt rzadkie sesje aktualizacji BGP z sąsiadami
- Nieodpowiednie polityki filtrowania tras i aktualizacji
- Duża liczba równorzędnych alternatyw routingu do sieci docelowej
W praktyce "BGP Zombies" nie są zjawiskiem rzadkim. Szczególnie przydatne w ich badaniu są tzw. beacony RIPE RIS - bloki adresów zaprojektowanych do cyklicznego rozsyłania przez RIPE oraz okresowego wycofywania. Monitorowanie ich widoczności w systemach ThousandEyes dostarczyło wielu przykładów zablokowanych tras, np.:
- Prefiks 2a0d:3dc1:2327::/48 pozostał w RIB-ach 8 ruterów peer-ów RIPE RIS z 6 AS-ów, które dzieliły wspólną podścieżkę „30781 5511 25091 8298 210312”, wskazując AS30781 jako możliwy główny czynnik utrzymania "Zombie".
- Trasa 2a0d:3dc1:1737::/48 nie została w pełni usunięta przez 7 routerów, a wspólnym elementem ich dróg było ogniwo "24961 210312" - AS24961 to potencjalne źródło problemu.
- Aż 24 rutery 21 systemów AS nie wycofywały wpisu 2a0d:3dc1:2233::/48, dzieląc trasę "33891 25091 8298 210312" - AS 33891 to główny podejrzany inicjujący "Zombie".
Jak widać, wykrywanie "BGP Zombies" opiera się na identyfikacji wspólnych elementów dróg AS, na których trasa mogła utknąć.
Radzenie sobie z "BGP Zombies"
Zwalczanie skutków obecności "BGP Zombies" rozpoczyna się od ich właściwej detekcji. Gdy tylko zostanie zidentyfikowany podejrzany przypadek, administrator powinien spróbować:
- Ponownie rozsyłać informacje o wycofaniu trasy, wykonać restart sesji BGP z sąsiadami.
- Skontaktować się z prawdopodobnym systemem, w którym trasa utknęła w celu wyczyszczenia tablic routingu przez operatora.
- Wprowadzić polityki filtrujące nieaktualne już trasy na routerach swojej sieci.
- Jeśli wszystkie powyższe kroki zawiodą, raportować przypadek liderom Project 8 RIPE i dostawcy routerów.
Utrzymywanie aktualnych i szczegółowych danych o stanach routingu oraz kształtowanie odpowiednich polityk aktualizacji jest kluczem do uniknięcia eskalacji problemów wynikających z "BGP Zombies". Współpraca producentów sprzętu, zespołów badawczych i operatorów sieci w celu rozwiązania luk i błędów protokołu BGP może w przyszłości zmniejszyć częstość tego niepokojącego zjawiska
Wyciek Uztelecom: co się stało?
26 września 2024 r. Uztelecom (AS28910) zaczął rozgłaszać ponad 3000 tras ze swoich peerów przez jednego ze swych dostawców tranzytu, rosyjskiego Rostelecomu (AS12389). Ten błąd spowodował, że ruch internetowy z ponad tuzina krajów został przekierowany przez Rosję i Azję Środkową.
Przyjrzyjmy się przykładowi. Przed wyciekiem, sieć University Corporation for Atmospheric Research (AS14041) odbierała trasę dla prefiksu 185.2.49.0/24 należącego do Amazonu (AS16509) ze swojego dostawcy tranzytu Arelion (AS1299). Podczas wycieku AS14041 zaczęła wybierać dłuższą, mniej optymalną wyciekłą trasę od swojego peera Hurricane Electric (AS6939), ponieważ została ona nieprawidłowo uznana za preferowaną.
Wpływ na ruch
Podczas wycieku nagle pojawił się ruch przeznaczony dla krajów poza regionem Centralnej Azji, podróżujący ścieżką zawierającą "12389 28910" (Rostelekom do Uztelekomu). Były to m.in. Hong Kong, Holandia, Afganistan, Rosja, Japonia i Stany Zjednoczone. Natomiast ruch do i z Uzbekistanu, zgodnie z oczekiwaniami, pozostał niezmieniony.
Chociaż ludzie nadal konfigurują rutery i popełniają błędy, globalna higiena routingu poprawiła się dzięki wysiłkom takim jak MANRS. Pomimo to, wycieki nadal się zdarzają i mogą powodować zakłócenia.
Aby temu przeciwdziałać, kluczowe jest wdrożenie RPKI (Resource Public Key Infrastructure) i odrzucanie nieprawidłowych tras przez RPKI. Tworząc ROAs (Route Origin Authorizations) i odrzucając nieprawidłowe elementy, sieci mogą chronić swój przychodzący i wychodzący ruch przed skutkami takich wycieków.
VMware Workstation za darmo
VMware Workstation Pro i Fusion Pro były dostępne za darmo do użytku osobistego od pewnego czasu. Teraz można z nich oficjalnie korzystać także w celach komercyjnych. Czy to pomoże w ociepleniu wizerunku po ubiciu przez Broadcom darmowego ESXi?
Odkrywanie sieci z Pythonem
PyNetWeaver to narzędzie napisane w Pythonie do odkrywania sieci i zbierania danych, które sprawdzi się w środowiskach zbudowanych na wielu producentach. Obsługuje urządzenia takie jak Cisco, Arista, Aruba i Palo Alto, dzięki protokołom SNMP i SSH. Posiada wiele funkcji, takich jak analiza oparta na szablonach oraz możliwość eksportu danych.
Projektowanie sieci Out-of-Band
Przeczytaj całą historię
Zarejestruj się teraz, aby przeczytać całą historię i uzyskać dostęp do wszystkich postów za tylko dla płacących subskrybentów.
Subskrybuj