📬 ISN 161: Optymalizuj swoją sieć: Przewodnik po projektowaniu Out-of-Band

W 161. numerze newslettera przyjrzymy się nie do końca martwym trasom BGP, analizujemy wyciek Uztelecom. Dowiesz się, jak zdobyć VMware Workstation za darmo oraz odkryj możliwości Pythona w eksploracji sieci. Nie przegap też nowinek w projektowaniu sieci Out-of-Band!
📬 ISN 161: Optymalizuj swoją sieć: Przewodnik po projektowaniu Out-of-Band

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?

Beyond Their Intended Scope: Uzing into Russia
The first installment of our new blog series, Beyond Their Intended Scope, covers BGP mishaps that may have escaped the community’s attention but are worthy of analysis. In this post, we review a recent BGP leak that redirected internet traffic through Russia and Central Asia as a result of a path error leak by Uztelecom, the incumbent service provider of Uzbekistan.

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 Fusion and Workstation are Now Free for All Users
These powerful desktop hypervisor products are free to all users - commercial, educational, & personal users alike!

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

GitHub - scottpeterman/pynetweaver: PyNetWeaver is a powerful network discovery and data collection tool designed to gather information from multi-vendor network environments using both SNMP and SSH protocols.
PyNetWeaver is a powerful network discovery and data collection tool designed to gather information from multi-vendor network environments using both SNMP and SSH protocols. - scottpeterman/pynetwe…

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

Świetnie! Udało ci się pomyślnie zarejestrować.
Witaj z powrotem! Zalogowałeś się pomyślnie.
Pomyślnie subskrybowałeś Inna Sieć.
Twój link wygasł.
Sukces! Sprawdź swoją skrzynkę e-mailową, aby uzyskać magiczny link do logowania.
Sukces! Twoje informacje rozliczeniowe zostały zaktualizowane.
Twoje informacje rozliczeniowe nie zostały zaktualizowane.