Jak połączyć domeny EVPN i IPVPN bez pętli routingu
Sajassi, A., Ed.
Sieci dzierżawców coraz częściej rozciągają się przez heterogeniczne domeny – część korzysta z EVPN, część z klasycznego IPVPN. Do tej pory brakowało standardowego mechanizmu ich spójnego połączenia. RFC 10039 to właśnie wypełnia.
Serce specyfikacji to nowy opcjonalny i tranzytywny atrybut ścieżki BGP o nazwie Domain Path (D-PATH). Działa analogicznie do AS_PATH, ale na poziomie domen: każdy gateway PE, przez który przechodzi trasa ISF (inter-subnet forwarding), dopisuje do listy swój identyfikator <DOMAIN-ID:ISF_SAFI_TYPE>.
Efekt? Jeśli trasa wróci do bramy, która już widziała swój DOMAIN-ID w atrybucie – oznacza ją jako pętlę i nie re-eksportuje dalej. Proste i skuteczne.
D-PATH wpływa też na selekcję najlepszej ścieżki: preferowane są trasy z krótszym D-PATH, czyli te, które przeszły przez mniej bram. To elegancki mechanizm unikania suboptimalnego routingu w topologiach z redundantnymi gateway PE.
RFC definiuje dwa tryby działania gateway PE przy re-origination tras:
- No Propagation Mode (domyślny) – gateway PE traktuje re-importowaną trasę jak lokalnie podłączony prefiks. Zeruje atrybuty BGP. Prosty, bezpieczny, ale nie propaguje D-PATH – redundantne bramy pozostają podatne na pętle.
- Uniform Propagation Mode – brama przenosi spójny zestaw atrybutów między domenami: AS_PATH, D-PATH, LOCAL_PREF, MED, AIGP, Communities. Uwaga: Extended Communities specyficzne dla EVPN, Route Targets i BGP Encapsulation Extended Communities nie powinny być propagowane – mogą powodować nieprzewidywalne zachowanie w domenie docelowej.
Dla środowisk produkcyjnych z redundantnymi bramami: Uniform Propagation Mode z D-PATH to właściwy wybór. Dla prostszych topologii lub gdy bezpieczeństwo atrybutów jest priorytetem – No Propagation Mode wystarczy.
RFC wprowadza precyzyjną taksonomię:
- Composite PE – jeden PE, dwie rodziny SAFIs (EVPN + IPVPN) w tej samej domenie, ten sam RR. Reklamuje ten sam prefiks dwukrotnie.
- Gateway PE – łączy odrębne domeny, re-originuje trasy między różnymi SAFIs. Kluczowy punkt dla D-PATH.
- Composite/Gateway PE – oba role jednocześnie. Typowy przypadek w dużych DCI, gdzie DC używa EVPN, a WAN – IPVPN.
Selekcja tras między EVPN i IPVPN jest deterministyczna: najpierw wygrywa krótszy D-PATH, potem standardowe reguły BGP, a RT-2 (MAC/IP) ma zawsze priorytet nad RT-5 (IP Prefix) przy równorzędnych kandydatach.
Jeśli planujesz integrację domeny EVPN (datacenter) z IPVPN (WAN/MPLS), RFC 10039 daje ci gotowy framework. Kluczowe decyzje projektowe to: konfiguracja unikalnych DOMAIN-ID per domena (wszystkie gateway PE tej samej domeny muszą używać identycznej wartości), wybór trybu propagacji oraz świadome ograniczenie propagacji Extended Communities na granicach domen.
RFC otrzymał kod atrybutu BGP 36 w rejestrze IANA. Implementacje pojawiają się w głównych stosach sieciowych – warto sprawdzić support w swoim środowisku przed zaprojektowaniem nowej topologii multi-domain.
AI Inference staje się problemem sieciowym
Javier Antich
Przez lata mówiliśmy, że opóźnienia sieciowe to przy AI drugorzędna sprawa. To się zmienia — i warto zrozumieć, dlaczego akurat teraz.
Prompt zanim dotrze do GPU, pokonuje długą drogę. Przechodzi przez stos TCP/TLS, API gateway (Kong, Envoy, AWS API Gateway), LLM router wybierający model i region, a dopiero potem trafia do warstwy inference — gdzie tokenizacja na CPU poprzedza właściwe obliczenia na GPU.
Kluczowe rozróżnienie: istnieją tu dwie zupełnie różne sieci. Ruch north-south (żądanie użytkownika) oparty na HTTP/TCP/TLS, obsługiwany przez CPU. Oraz fabric east-west (między GPU) — NVLink, InfiniBand lub RoCE z RDMA, całkowicie omijający klasyczny stos IP. To nie są warianty tej samej sieci — to odrębne domeny o różnych charakterystykach i problemach.
Całkowita latencja odpowiedzi to: TTFT + (N-1) × ITL, gdzie TTFT (Time to First Token) składa się z czasu kolejkowania, tokenizacji, fazy prefill i opóźnienia sieciowego.
W praktyce dominuje kolejkowanie i prefill — łącznie 300+ ms przy obciążonym klastrze. Sieć WAN dodaje 20–80 ms. Przy takich proporcjach 40 ms RTT to szum statystyczny. Dlatego przez lata latencja sieciowa była dla AI nieistotna.
Nowe generacje sprzętu do inference radykalnie obniżają ITL. Najszybsze obecnie systemy schodzą poniżej 0,5 ms/token, a trend jest jednoznaczny — w ciągu dwóch, trzech lat ITL stanie się marginalny.
Drugi czynnik to agentic AI. Jeden request użytkownika może wygenerować 100 sekwencyjnych wywołań LLM. Przy takim modelu całkowita latencja to w uproszczeniu: 200 × NL2 + 100 × TTFT + 100 × N × ITL.
Przy NL2 = 50 ms i wolniejszym sprzęcie, sieć odpowiada za mniej niż 10% całkowitego czasu. Przy najszybszym dostępnym sprzęcie inference — już za 25–45%. I ten udział będzie rósł.
Inferencja będzie musiała zbliżyć się do użytkowników. Scentralizowane klastry GPU w kilku lokalizacjach przestaną wystarczać dla aplikacji agentic. Rozproszone architektury inference — edge, metro, core — to nie odległa przyszłość, to kierunek, w którym branża już zmierza.
Dla service providerów to konkretna szansa: możliwość dostarczania infrastruktury inference z gwarantowaną niską latencją stanie się elementem portfolio, nie dodatkiem.
Zasady, które znasz z projektowania sieci o niskiej latencji — traffic engineering, locality, distributed systems — bezpośrednio przekładają się na projektowanie infrastruktury AI. To nie jest nowy problem. To znajomy problem w nowym opakowaniu.
Testowanie Segment Routingu
segmentrouting
INFO: Narzędzie służy do symulowania wielościeżkowych, niezawodnych połączeń MRC w sieci korzystającej z dataplane’u SRv6 uSID. Możesz użyć go do testowania wieloplanowej architektury sieci, alokacji uSID, enkapsulacji i dekapsulacji na hostach oraz rozkładu pakietów między ścieżkami. Simulator wdraża topologię Clos opartą na Containerlab i dockerowanych instancjach SONiC-VS, a także hosty Alpine Linux. Umożliwia uruchamianie scenariuszy ruchu, pomiary strat, opóźnień i zmian kolejności pakietów, monitorowanie stanu poszczególnych ścieżek oraz wstrzykiwanie awarii interfejsów i węzłów. Do zarządzania laboratorium służy narzędzie srctl, a opcjonalny dashboard Grafany pozwala obserwować równoważenie ruchu i wpływ awarii w czasie rzeczywistym.
Segment Routing od Nokia
sros-labs
INFO: Publiczne repozytorium GitHub zawiera e-booki o rozwiązaniach SR OS firmy Nokia. Znajdziesz w nim m.in. materiały o Segment Routing oraz routingu i usługach z wykorzystaniem BGP. Autor zaznacza, że publikacje przedstawiają jego własne opinie i wyniki testów, dlatego nie są oficjalną dokumentacją Nokii — tej należy szukać na stronie documentation.nokia.com.
Jak multicast działa w EVPN
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