BGP origin
Iliana Xygkou
70% ścieżek BGP widocznych w publicznych kolektorach ma zmodyfikowany atrybut ORIGIN. Cloudflare właśnie to udowodnił eksperymentalnie — i wyniki powinny zmienić sposób, w jaki patrzysz na selekcję tras.
ORIGIN to obowiązkowy atrybut BGP określający, jak trasa trafiła do protokołu: IGP (0), EGP (1) lub INCOMPLETE (2). RFC4271 mówi jasno — nie należy go modyfikować po ustawieniu przez AS źródłowy. W praktyce jest inaczej.
Cloudflare ogłosił prefiksy z każdą z trzech wartości ORIGIN ze wszystkich lokalizacji peeringowych, a następnie analizował Updates z kolektorów RIPE RIS i RouteViews. Wynik: niemal 10% bezpośrednich peerów przestawiało ORIGIN na IGP — w tym 6 z 16 sieci Tier-1.
Mechanizm jest prosty i dochodowy. Jeśli dwa peery oferują trasę z identyczną długością AS_PATH i Local Preference, router wybierze tę z niższą wartością ORIGIN. Przestawienie EGP lub INCOMPLETE na IGP wystarczy, by przyciągnąć ruch — i przychód z tranzytu.
Liczby mówią same za siebie:
- 26% sieci z Top 50 AS Rank aktywnie modyfikuje ORIGIN
- 70% unikalnych ścieżek IPv4 (67% IPv6) ma ORIGIN zresetowany do IGP
- Rewriterzy ORIGIN zyskali 18% więcej ścieżek IPv4 i aż 40% więcej w IPv6 względem sieci przestrzegających RFC
Co istotne, manipulacja nie jest symetryczna. Niektóre sieci przestawiają ORIGIN na EGP celowo — żeby zdepriorytetyzować trasy od peerów względem tras od klientów. Jeden z operatorów potwierdził to wprost badaczom Cloudflare.
Krótka odpowiedź: przestań traktować ORIGIN jako wiarygodny sygnał routingowy — bo nim nie jest.
Jeśli w twojej polityce BGP ORIGIN wpływa na selekcję tras, de facto oddajesz kontrolę nad ruchem dowolnemu tranzytowemu AS po drodze. W środowiskach, gdzie liczy się deterministyczny routing lub koszt tranzytu, warto to przeanalizować.
Pułapka Dual-Stack SR-MPLS
Segment Routing nad MPLS obsługuje jednocześnie IPv4 i IPv6 — każda rodzina adresowa dostaje własny zakres SID-ów. W teorii proste, w praktyce jest jeden szczegół, który potrafi pochłonąć godziny debugowania.
W dual-stack SR-MPLS przypisujesz osobne Node SID-y do loopbacków IPv4 i IPv6. W typowej konfiguracji testowej IPv4 SID-y startują od 1, IPv6 od 101. IS-IS rozgłasza je odpowiednio w TLV Extended IP Reachability (MT-0) oraz Extended IPv6 Reachability (MT-2), każdy z sub-TLV SR Prefix-SID. Tablica MPLS zawiera wpisy dla obu rodzin — ale next-hop dla IPv6 SID-ów to adres link-local, nie globalny.
Weryfikacja na Arista EOS:
show isis segment-routing prefix-segments
show mpls route
Wynik powinien pokazać SID-y dla prefiksów 10.0.42.x/32 oraz 2001:db8::x/128 z odpowiednimi etykietami MPLS.
Tu zaczyna się problem, który kosztował autora wiele godzin. Arista EOS i Cisco IOS XR reklamują prefix IPv6 loopbacka z sub-TLV SR Prefix-SID tylko gdy prefix to /128. Nokia SR-OS odrzuca loopback IPv6 z prefiksem innym niż /128 już na etapie konfiguracji.
Jeśli wierzysz w "/64 everywhere" — tutaj to nie zadziała. Co gorsza, Cisco IOS XR zachowuje się szczególnie podstępnie: przypisuje SID i etykietę MPLS do /64 loopbacka, ale nie rozgłasza go w IS-IS. Żadnego błędu, żadnego ostrzeżenia.
Jedyne urządzenia, które działają poprawnie z prefiksem innym niż /128, to FRRouting i Junos.
Konfiguracja w netlab wymaga jawnego ustawienia:
addressing:
loopback:
ipv6: 2001:db8::/48
prefix6: 128
Bez prefix6: 128 netlab domyślnie przypisuje /64 — i tracisz godziny na debugowanie.
Warto znać aktualny obraz przed wdrożeniem:
- Arista EOS, Cisco IOS XR, FRRouting, Junos, Nokia SR Linux, Nokia SR-OS — dual-stack SR-MPLS działa
- Cisco IOS XE — brak wsparcia dla SID-ów na prefiksach IPv6 (niespodzianka, biorąc pod uwagę agresywne promowanie SRv6 przez Cisco)
Dual-stack SR-MPLS jest dobrze wspierany przez większość platform, ale wymaga /128 na loopbackach IPv6 — bez wyjątków. Zanim zaczniesz troubleshootować brakujące SID-y w IS-IS, sprawdź długość prefiksu loopbacka. To pierwsze miejsce, gdzie szukać problemu.
Jeśli chcesz przetestować konfigurację samodzielnie, repozytorium warsztatów SR-MPLS na GitHubie zawiera gotowe topologie netlab z obsługą GitHub Codespaces — środowisko działa w przeglądarce bez lokalnej instalacji.
Awesome Automatyzacja sieci
packetcodersStrona zbiera i kataloguje najlepsze zasoby dotyczące zastosowania sztucznej inteligencji (AI), dużych modeli językowych (LLM) oraz uczenia maszynowego (ML) w automatyzacji sieci. Znajdziesz tu narzędzia, frameworki, biblioteki, platformy, artykuły, tutoriale, podcasty, kursy i książki – wszystko w jednym miejscu.
Labuj RIFT na SR Nokia
0return
Repozytorium zawiera gotowy do uruchomienia lab RIFT (Routing in Fat Trees, RFC 9692) działający na Nokia SR Linux, zbudowany w oparciu o agenta NDK hyposcaler/srl-rift autorstwa Dennisa Fanshawa. Sam protokół jest zaimplementowany w tym agencie i nie jest powielany tutaj. Projekt dostarcza kompletną topologię, konfiguracje startowe, skrypty do wdrożenia i weryfikacji działania oraz dokumentację opisującą rzeczywisty przebieg budowy środowiska - co działa, co nie i jaka wersja SR Linux jest wymagana.
Ryzyko dla OT w IPv6
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