Strona głównaArtykułyInternet & Sieci

Rozpowszechnianie Tras w BGP: Jak Internet Zgadza się na Ścieżkę

Routowanie wektorowe ścieżek, hierarchia klient-peer-dostawca, zasada 'bezdoliny' oraz powód, dla którego konwergencja po awarii trwa minuty, a nie milisekundy.

mysimulator teamZaktualizowano — czerwiec 2026≈ 9 min czytania▶ Otwórz symulację

Sieć internetowa nie jest jedną siecią, to tysiące sieci, które się zgadzają rozmawiać

Internet publiczny to federacja około 70 000 niezależnie zarządzanych sieci, zwanymi Autonomicznymi Systemami (AS) i identyfikowanych numerycznie – AS15169 to Google, AS7922 to Comcast, a AS13335 to Cloudflare. Żadna centralna władza nie nakazuje im, aby komunikowali się ze sobą. Zamiast tego, każda sieć AS uruchamia Protokół Bramowy (BGP), rozmawiając z bezpośrednimi sąsiadami przez port TCP 179 i rozpowszechniając informacje o wykonalności w sposób hop po hop, aż do momentu, gdy wszystkie sieci na ścieżce usłyszą ogłoszenie dla danego bloku adresów IP.

Jest to protokół wektorowy odległości, kompromis pomiędzy dwoma starszymi koncepcjami. Protokóły wektorowe odległości (takie jak wczesny RIP) wymieniają jedynie liczby hopów, co jest tanie, ale ślepe – router nie może stwierdzić, czy trasę sąsiada krąży wokół siebie. Protokóły stanów linków (takie jak OSPF) rozprzestrzeniają całą topologię do wszystkich routerów, co jest precyzyjne, ale nie skaluje się poza pojedynczą organizację. Kompromis BGP polega na ogłaszaniu pełnej ścieżki AS wraz z każdym trasą: nie tylko "Mogę dotrzeć do 8.8.8.0/24", ale również "Potrafię to zrobić przez AS15169, AS3356, AS6453". Router, który widzi swoją własną liczbę AS w otrzymanej trasie, odrzuca ją natychmiast – ta jedna sprawa stanowi całą mechanizm zapobiegania pętlom BGP.

demo na żywo · powiązana symulacja● LIVE

Co rzeczy są ogłaszane

AS nie ogłasza pojedynczych adresów IP — ogłasza prefiksy, bloki takie jak 8.8.8.0/24 (gdzie /24 oznacza, że pierwsze 24 bity są ustalone, dając 256 adresów). Każde ogłoszenie — wiadomość BGP UPDATE — zawiera predykat plus zestaw atrybutów ścieżki: AS_PATH (każde AS, przez które przechodziła trasa, najstarsze pierwsze), NEXT_HOP (router do wysyłania pakietów), oraz opcjonalne atrybuty takie jak MED i społeczności używane do sterowania ruchem. Gdy router otrzymuje UPDATE, prependuje swój własny numer AS do ścieżki przed ponownym ogłaszaniem jej dalej, co jest dokładnie powodem, dla którego ścieżka rośnie o jeden hop na granicy AS oraz dlaczego liczenie hopów w AS_PATH jest przybliżonym proxy dla odległości sieciowej.

Wybieranie najlepszej ścieżki: jest to decyzja biznesowa, a nie najkrótsza ścieżka

O czym zaskakują ludzi coming from IGP routing (OSPF, routing na najkrótszą drogę w jednej sieci): BGP domyślnie nie wybiera najkrótszego AS path. Rzeczywiste ISP komercyjnie klasyfikują każdego sąsiada w jednym z trzech relacji, a to klasyfikowanie decyduje, który routing wygrywa przed uwzględnieniem długości ścieżki:

klient → sieć płacąca Ci za transit (przenoszenie ruchu dla niej) peer → sieć, z którą wymieniają się danymi bezpłatnie (zazwyczaj sieci o równej wielkości provider → sieć, za pośrednictwem której płacisz za transit (przenoszą ruch dla Ciebie) Standardowy kolejność preferencji: routing klienta > routing peer > routing provider (routing klienta generuje zyski; routing providera generuje koszty) To model Gao-Rexford, sformalizowany na podstawie obserwacji ISP w 2001 roku, który daje słynną zasadę o wolnych dolinach: legalny AS path podąża w górę przez zero lub więcej linków providera, przecina się maksymalnie jednym linkiem peerowym na szczycie, a następnie zjeżdża w dół przez zero lub więcej linków klienta. Ścieżka typu provider → peer → provider (dolina) oznaczałaby, że AS zapewnia bezpłatny transit między dwoma sieciami, dla których nie ma żadnego komercyjnego powodu do subsydiowania, a w praktyce takie ścieżki są filtrowane lub po prostu nigdy nie ogłaszane.

Tylko po ustaleniu relacji komercyjnej BGP wraca do rozstrzygania w oparciu o łańcuch tie-break: najkrótszy AS_PATH, najniższy typ pochodzenia, najniższe MED (wskazówka od sąsiedniego AS na temat jego własnych preferencji wewnętrznych), eBGP nad trasami iBGP, najniższy koszt IGP do następnego przystanku, a ostatecznie najniższy identyfikator routera jako arbitralne ostateczne rozwiązanie. Każdy z tych kroków istnieje, ponieważ dwa routery, stosujące dokładnie ten sam deterministyczny zestaw zasad do dokładnie tych samych danych tras, muszą osiągnąć dokładnie taki sam wynik — w przeciwnym razie sieć oscyluje.

customer  → a network that pays you for transit          (you carry their traffic anywhere)
peer      → a network you exchange traffic with for free  (usually equal-sized networks)
provider  → a network you pay for transit                 (they carry your traffic anywhere)

Standard preference order: customer route > peer route > provider route
(a customer route earns you money; a provider route costs you money)

Zbieżność: dlaczego internet jest wolny do naprawy

Kiedy wystąpi awaria połączenia lub AS wycofa przypis, informacja ta musi przesyłać się hop po hop przez każde AS, które miało trasę przez awarię, a każdy router na swojej drodze musi ponownie obliczyć najlepszą ścieżkę i potencjalnie zbadać kilka alternatyw, zanim ustali się ona — zjawisko to nazywa się eksploracją ścieżek. Zmierzona konwergencja po rzeczywistej awarii zwykle trwa dziesiątki sekund do kilku minut, a nie milisekund, ponieważ BGP celowo ogranicza prędkość, z jaką router ponownie ogłasza trasę migającą (MinRouteAdvertisementInterval, historycznie 30 sekund), aby uniknąć zalewania całego internetu aktualizacjami za każdym razem, gdy awaryjnie wyłącza się połączenie.

Symulacja na tej stronie działa dokładnie ten mechanizm: ogłoszenie wchodzi do jednego AS, każdy sąsiad ocenia je w odniesieniu do polityki klienta/partnera/dostawcy dla połączenia, z którego dotarło i — jeśli wygrywa — ponownie ogłasza je na zewnątrz, dodając swój numer AS do ścieżki, generacja po generacji, aż sieć ustabilizuje się w stabilnym zestawie najlepszych tras.

Kiedy coś idzie nie tak: wycieki tras i przejęcia

BGP został zaprojektowany w 1989 roku przy założeniu dobrosłużności: każdy AS szczerze ogłasza tylko prefiksy, które faktycznie posiada lub za które został upoważniony. Nie ma w podstawowym protokole kryptograficznego dowodu, że ogłoszenie jest legalne, co sprawia, że wycieki tras (przypadkowe ponowne ogłaszanie tras dostawcy do innego dostawcy, tworząc dolinę) i przejęcia BGP (ogłaszanie prefiksu, którego nie posiadasz, celowo lub w wyniku błędnej konfiguracji) powodują rzeczywiste, wielokrotne awarie internetu — przypadkowe przejęcie przez Pakistan Telecom prefiksu YouTube w 2008 roku było typowym przykładem. Współczesną obroną jest RPKI (Infrastruktura Kluczy Publicznych Zasobów), która pozwala właścicielowi prefiksu kryptograficznie podpisać stwierdzenie, który AS może z niego pochodzić, dzięki czemu routery mogą odrzucić oczywistą fałszywą ogłoszenie zamiast go bezkrytycznie propagować.

Często zadawane pytania

Czy BGP zawsze wybiera najkrótszą ścieżkę?

Nie. Relacje komercyjne mają priorytet przed długością ścieżki: trasa wyuczona od płacącego klienta jest preferowana nad trasą wyznaczoną przez partnera bez opłat, a ta z kolei nad trasą wyznaczoną przez dostawcę transportu na żądanie. Tylko wtedy, gdy dwie kandydatkowe trasy są równorzędne pod względem klasy relacji, BGP zwraca się do porównania długości ścieżki AS.

Co to jest trasa bez dolin?

Trasa AS, która tylko wznosi się przez dostawców, przecina maksymalnie jeden link peer-to-peer i opada przez klientów – nigdy nie przechodzi przez dostawcę, partnera ani ponownie przez dostawcę. Ten kształt odzwierciedla, kto jest skłonny przewozić ruch innych za darmo, a kto za pieniądze, a trasy naruszające to zasadniczo wskazują na wyciek trasy.

Dlaczego internet potrzebuje tak długo, aby zauważyć awarię?

Aktualizacja musi propagować się hop po hop przez każdy AS na dotkniętej ścieżce, a każdy z nich ponownie ocenia najlepszą trasę i czasami rozważa kilka pośrednich kandydatów przed ustabilizowaniem się – dodatkowo routery celowo ograniczają częstotliwość ponownego ogłaszania trasy, aby uniknąć zalewania internetu podczas awarii flapping link. Rzeczywista konwergencja po poważnej awarii zwykle zajmuje od dziesiątek sekund do kilku minut.

Wypróbuj na żywo

Wszystko powyżej działa bezpośrednio w Twojej przeglądarce — otwórz BGP Route Propagation i zmieniaj parametry podczas działania. Nic nie jest instalowane ani przesyłane na serwer, cały model działa w jednej karcie.

▶ Otwórz symulację BGP Route Propagation

Co znalazłeś?

Dodaj kroki odtworzenia (opcjonalnie)