Co tak naprawdę dzieje się wewnątrz IXP?
Renato Gentil
Większość inżynierów traktuje Internet Exchange Point jak czarną skrzynkę. Konfigurujesz eBGP do peera, ruch płynie — i tyle. Warto wiedzieć, co jest w środku, bo architektura IXP bezpośrednio przekłada się na decyzje projektowe w sieciach SP i DC.
Fizycznie IXP to przełącznik Layer 2, do którego podłączają się różne AS-y. Wszyscy członkowie siedzą na tej samej sieci peering LAN (np. 198.18.0.0/24). Nie ma dedykowanych VLANów per peer. Kto z kim rozmawia — decyduje wyłącznie konfiguracja BGP.
IXP dostarcza trzy rzeczy: port fizyczny, adres IP na shared peering LAN i opcjonalnie route server. Polityka routingu, filtrowanie prefixów, community — to Twoja sprawa.
Ekonomia jest prosta: port 100GE w dużym IXP kosztuje 2–5 tys. USD miesięcznie. Ten sam wolumen tranzytu od Cogent lub Lumen — kilkanaście razy więcej. Dlatego przychody tranzytowe spadają od dekady.
IXP z 500 członkami oznacza potencjalnie 500 sesji eBGP na Twoim routerze. Route server eliminuje ten problem — peerujesz z jedną instancją, która redystrybuuje trasy od wszystkich pozostałych uczestników.
Kluczowy szczegół: RS działa w trybie transparentnym. Nie modyfikuje AS-path, nie wstawia własnego AS, zachowuje wszystkie community. Twój router widzi trasy jakby origin AS był bezpośrednim perem.
Route serwery w IXP to zazwyczaj Linux z BIRD lub OpenBGPD. Żaden Cisco, żaden Juniper — czyste control-plane, zero forwardingu.
Duże IXP: SR + EVPN zamiast legacy L2
Tu robi się technicznie ciekawie. DE-CIX Frankfurt działa w ponad 30 lokalizacjach w mieście. AMS-IX, LINX — podobnie. Problem: jeden peering VLAN musi być rozciągnięty między dziesiątkami budynków na ciemnym włóknie.
Stare podejście (Q-in-Q, VPLS, długie trunki L2) generowało problemy: STP nie skalował się, eksplozja tablic MAC, słaba izolacja awarii.
DE-CIX w grudniu 2022 zakończył globalną migrację do EVPN (Peering LAN 2.0), wdrożoną live na wszystkich lokalizacjach. Architektura wygląda następująco:
- Underlay: IS-IS + SR-MPLS między przełącznikami IXP
- Overlay: MP-BGP EVPN (ELAN) — MAC learning przez control plane, bez floodingu
- Co widzi member: zwykły VLAN L2, ARP działa normalnie
Efekty mierzalne: 25% redukcja CPU na routerach członków (koniec z broadcast ARP od 2600 innych uczestników), MAC withdrawal przez BGP zamiast timerów starzenia, natywny multi-homing przez EVPN Ethernet Segment bez MC-LAG.
Route Reflektory w IP-MPLS
Abdulqadir Babagana Musa
W sieci z setkami PE-routerów pełna siatka iBGP to pewna droga do operacyjnego chaosu. Jeśli jeszcze jej nie wyeliminowałeś, ten artykuł jest dla Ciebie.
BGP wymaga, żeby router nie propagował trasy odebranej od jednego peera iBGP do innego. Konsekwencja? Full-mesh. Wzór jest bezlitosny:
N × (N - 1) / 2
Przy 500 PE-routerach to 124 750 sesji iBGP. Każda sesja to osobna konfiguracja, osobna para TCP, osobny narzut na CPU i pamięć. A każdy nowy PE oznacza aktualizację konfiguracji na wszystkich pozostałych. W praktyce taka sieć przestaje być zarządzalna znacznie wcześniej niż osiągnie limit sprzętowy.
Route Reflektor przełamuje regułę no-readvertise dla iBGP. PE-router ogłasza trasę do RR, a ten odbija ją do pozostałych klientów. Zamiast pełnej siatki, każdy PE utrzymuje sesje wyłącznie z RR.
Ten sam przykład z 500 PE przy dwóch RR-ach:
500 × 2 = 1 000 sesji
To redukcja o ponad 99%. Każdy nowy PE to dwie nowe sesje, nie pięćset.
Pętlom zapobiegają atrybuty ORIGINATOR_ID i CLUSTER_LIST — RR oznacza trasę swoim cluster-id, a router odrzuca update, jeśli rozpozna własny identyfikator na liście.
To kwestia, która regularnie wywołuje nieporozumienia podczas projektowania. RR dystrybuuje informacje o trasach, ale nie uczestniczy w przesyłaniu ruchu użytkownika. Gdy PE2 odbierze trasę od RR, traffic idzie bezpośrednio przez core MPLS:
CE → PE2 → P2 → P1 → PE1 → CE
RR nie leży na ścieżce danych. To oznacza, że możesz go posadzić na dedykowanym, wysokodostępnym serwerze bez kart linii i portów 100G. Liczy się moc obliczeniowa i pamięć do obsługi pełnej tablicy BGP — nie przepustowość.
Co warto zweryfikować w swojej sieci
Jeśli zarządzasz siecią operatorską lub backbone'em korporacyjnym, sprawdź trzy rzeczy:
- Redundancja RR — dwa RR w oddzielnych lokalizacjach fizycznych i domenach awarii. Utrata jedynego RR izoluje PE od dystrybucji tras.
- Cluster design — w bardzo dużych sieciach hierarchiczne klastry RR (confederation lub multi-level RR) pozwalają dalej skalować bez koncentrowania całej tablicy BGP w jednym miejscu.
- Separacja adresowa RR — loopback RR powinien być dostępny przez IGP niezależnie od stanu jakiegokolwiek pojedynczego łącza.
Stwórz looking glass
thatmattlove
Hyperglass to narzędzie do tworzenia looking glassów, czyli publicznych paneli pozwalających sprawdzać informacje o routingu i wykonywać testy sieciowe z infrastruktury operatora. Użytkownicy mogą między innymi analizować trasy BGP, społeczności BGP i ścieżki AS, a także uruchamiać polecenia ping oraz traceroute. Serwis obsługuje IPv4 i IPv6, wiele popularnych platform sieciowych, zapytania do kilku urządzeń jednocześnie, proxy SSH, filtrowanie dozwolonych celów oraz REST API z dokumentacją OpenAPI. Interfejs można szeroko dostosować, dlatego hyperglass sprawdzi się u operatorów, dostawców usług i innych administratorów, którzy chcą udostępnić klientom lub społeczności wygodny podgląd działania swojej sieci.
Worbooki do JNCIA
Praktyczny workbook do nauki JNCIA-Junos, oparty na laboratoriach uruchamianych w containerlab. Dostajesz gotowe topologie, konfiguracje i instrukcje, dzięki którym możesz ćwiczyć obsługę vJunos-Router i vJunos-Switch bez ręcznego tworzenia środowiska w EVE-NG lub GNS3. Po jednorazowej instalacji containerlab, wymaganych obrazów i repozytorium laboratoria uruchomisz szybko, a konfiguracje możesz przechowywać i wersjonować razem z kodem. To wygodny sposób na regularną naukę Junosa, automatyzację pracy przez SSH i przygotowanie do egzaminu JNCIA-Junos.
Własny ASN
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