Protokół bramy granicznej - Border Gateway Protocol

„BGP” przekierowuje tutaj. Dla innych zastosowań zobacz BGP (ujednoznacznienie) .
Pakiet protokołów internetowych
Warstwa aplikacji
Warstwa transportowa
Warstwa internetowa
Warstwa łącza

Border Gateway Protocol ( BGP ) to ustandaryzowany protokół bramy zewnętrznej przeznaczony do wymiany informacji o routingu i osiągalności między systemami autonomicznymi (AS) w Internecie . Protokół BGP jest klasyfikowany jako protokół routingu oparty na wektorze ścieżki i podejmuje decyzje dotyczące routingu na podstawie ścieżek, zasad sieciowych lub zestawów reguł skonfigurowanych przez administratora sieci .

Protokół BGP używany do routingu w systemie autonomicznym nazywa się Internal Border Gateway Protocol , Internal BGP ( iBGP ). Natomiast aplikacja internetowa protokołu nazywa się Exterior Border Gateway Protocol , External BGP ( eBGP ).

Historia

Protokół Border Gateway został po raz pierwszy opisany w 1989 r. w RFC 1105 i jest używany w Internecie od 1994 r. BGP IPv6 został po raz pierwszy zdefiniowany w RFC  1654 w 1994 r. i został ulepszony do RFC  2283 w 1998 r.

Obecna wersja BGP to wersja 4 (BGP4), która została opublikowana jako RFC 4271 w 2006 roku. RFC 4271 poprawił błędy, wyjaśnił niejasności i zaktualizował specyfikację o typowe praktyki branżowe. Głównym ulepszeniem była obsługa bezklasowego routingu międzydomenowego (CIDR) i użycie agregacji tras w celu zmniejszenia rozmiaru tablic routingu . Nowe RFC pozwala BGP4 na obsługę szerokiej gamy „rodzin adresów” IPv4 i IPv6 . Nazywa się również Multiprotocol Extensions, czyli Multiprotocol BGP (MP-BGP).

Operacja

Sąsiedzi BGP, zwani peerami, są ustanawiani przez ręczną konfigurację między routerami, aby utworzyć sesję TCP na porcie 179. Głośnik BGP wysyła 19-bajtowe komunikaty o utrzymaniu połączenia co 60 sekund, aby utrzymać połączenie. Wśród protokołów routingu BGP jest wyjątkowy w używaniu TCP jako protokołu transportowego.

Kiedy BGP działa między dwoma peerami w tym samym systemie autonomicznym (AS), jest określany jako Internal BGP ( i-BGP lub Internal Border Gateway Protocol ). Kiedy działa pomiędzy różnymi systemami autonomicznymi, nazywa się to External BGP ( eBGP lub Exterior Border Gateway Protocol ). Routery w granicach jednego AS wymiany informacji z innymi, ponieważ są nazywane granicznych lub krawędzi routerów lub po prostu eBGP równorzędne i zwykle są połączone bezpośrednio, a peerów I-BGP mogą być ze sobą połączone za pośrednictwem routerów pośrednich. Możliwe są również inne topologie wdrażania , takie jak uruchamianie peeringu eBGP w tunelu VPN , co pozwala dwóm zdalnym witrynom na wymianę informacji o routingu w bezpieczny i odizolowany sposób.

Główna różnica między peeringiem iBGP i eBGP polega na sposobie, w jaki trasy otrzymane od jednego peera są propagowane do innych peerów. Na przykład, nowe trasy wyuczone od sąsiada eBGP są zazwyczaj redystrybuowane do wszystkich sąsiadów iBGP, jak również do wszystkich innych sąsiadów eBGP (jeśli na routerze włączony jest tryb tranzytu ). Jednakże, jeśli nowe trasy są wyuczone w peeringu iBGP, to są one ponownie reklamowane tylko do wszystkich sąsiadów eBGP. Te reguły propagacji tras skutecznie wymagają, aby wszystkie peery iBGP wewnątrz AS były połączone w pełną siatkę.

Sposób propagowania tras można szczegółowo kontrolować za pomocą mechanizmu map tras . Ten mechanizm składa się z zestawu zasad. Każda reguła opisuje, dla tras spełniających określone kryteria, jakie działania należy podjąć. Działanie może polegać na usunięciu trasy lub zmodyfikowaniu niektórych atrybutów trasy przed umieszczeniem jej w tabeli routingu .

Negocjacja rozszerzeń

Maszyna stanu BGP

Podczas uzgadniania peeringu, gdy wymieniane są komunikaty OPEN, prelegenci BGP mogą negocjować opcjonalne możliwości sesji, w tym rozszerzenia wieloprotokołowe i różne tryby odzyskiwania. Jeśli wieloprotokołowe rozszerzenia BGP są negocjowane w czasie tworzenia, głośnik BGP może poprzedzić informacje o dostępności warstwy sieci (NLRI), które anonsuje, prefiksem rodziny adresów. Te rodziny obejmują IPv4 (domyślnie), IPv6, IPv4/IPv6 Virtual Private Networks i multicast BGP. Coraz częściej BGP jest używany jako uogólniony protokół sygnalizacyjny do przenoszenia informacji o trasach, które mogą nie być częścią globalnego Internetu, takich jak VPN.

Aby podejmować decyzje w swoich operacjach z peerami, peer BGP wykorzystuje prostą maszynę skończonych stanów (FSM), która składa się z sześciu stanów: Idle; Łączyć; Aktywny; OpenSent; OtwórzPotwierdź; i założona. Dla każdej sesji peer-to-peer implementacja BGP utrzymuje zmienną stanu, która śledzi, w którym z tych sześciu stanów znajduje się sesja. BGP definiuje komunikaty, które każdy peer powinien wymieniać, aby zmienić sesję z jednego stanu na inny.

Pierwszy stan to stan bezczynności. W stanie Idle BGP inicjuje wszystkie zasoby, odrzuca wszystkie przychodzące próby połączenia BGP i inicjuje połączenie TCP z peerem. Drugi stan to Połącz. W stanie Connect router czeka na zakończenie połączenia TCP i przechodzi do stanu OpenSent, jeśli się powiedzie. Jeśli się nie powiedzie, uruchamia licznik czasu ConnectRetry i przechodzi do stanu Aktywny po wygaśnięciu. W stanie Active router resetuje licznik czasu ConnectRetry do zera i powraca do stanu Connect. W stanie OpenSent router wysyła wiadomość Open i czeka na nią w odpowiedzi, aby przejść do stanu OpenConfirm. Wymieniane są komunikaty podtrzymujące, a po pomyślnym odebraniu router przechodzi w stan Ustanowiony. W stanie Ustanowiony router może wysyłać i odbierać: Keepalive; Aktualizacja; oraz Powiadomienia do i od swojego partnera.

  • Stan bezczynności :
    • Odrzuć wszystkie przychodzące połączenia BGP.
    • Rozpocznij inicjowanie wyzwalaczy zdarzeń.
    • Inicjuje połączenie TCP ze skonfigurowanym sąsiadem BGP.
    • Nasłuchuje połączenia TCP od swojego partnera.
    • Zmienia stan na Połącz.
    • Jeśli błąd wystąpi w dowolnym stanie procesu FSM, sesja BGP jest natychmiast przerywana i powraca do stanu bezczynności. Oto niektóre z powodów, dla których router nie przechodzi ze stanu bezczynności:
      • Port TCP 179 nie jest otwarty.
      • Losowy port TCP powyżej 1023 nie jest otwarty.
      • Nieprawidłowo skonfigurowany adres równorzędny na każdym routerze.
      • Nieprawidłowo skonfigurowany numer AS na jednym z routerów.
  • Stan połączenia :
    • Czeka na pomyślną negocjację TCP z peerem.
    • BGP nie spędza dużo czasu w tym stanie, jeśli sesja TCP została pomyślnie nawiązana.
    • Wysyła wiadomość Open do peera i zmienia stan na OpenSent.
    • W przypadku wystąpienia błędu BGP przechodzi do stanu Aktywny. Niektóre przyczyny błędu to:
      • Port TCP 179 nie jest otwarty.
      • Losowy port TCP powyżej 1023 nie jest otwarty.
      • Nieprawidłowo skonfigurowany adres równorzędny na każdym routerze.
      • Nieprawidłowo skonfigurowany numer AS na jednym z routerów.
  • Stan aktywny :
    • Jeśli router nie był w stanie nawiązać udanej sesji TCP, przechodzi w stan Aktywny.
    • BGP FSM próbuje zrestartować kolejną sesję TCP z peerem i jeśli się powiedzie, wysyła wiadomość Open do peera.
    • Jeśli ponownie się nie powiedzie, FSM zostanie zresetowany do stanu bezczynności.
    • Powtarzające się awarie mogą powodować przełączanie routera między stanami bezczynności i aktywności. Oto niektóre z powodów:
      • Port TCP 179 nie jest otwarty.
      • Losowy port TCP powyżej 1023 nie jest otwarty.
      • Błąd konfiguracji BGP.
      • Przeciążenie sieci.
      • Trzepotanie interfejsu sieciowego.
  • Otwarty Stan Wysłany :
    • BGP FSM nasłuchuje otwartej wiadomości od swojego peera.
    • Po odebraniu wiadomości router sprawdza ważność wiadomości Open.
    • Jeśli jest błąd, to dlatego, że jedno z pól w komunikacie Open nie pasuje między peerami, np. niezgodność wersji BGP, router równorzędny oczekuje innego My AS itp. Następnie router wysyła do peera komunikat Notification wskazujący przyczynę wystąpienia błędu.
    • Jeśli nie ma błędu, wysyłana jest wiadomość Keepalive, ustawiane są różne timery, a stan zmienia się na OpenConfirm.
  • OtwórzPotwierdź stan :
    • Partner nasłuchuje wiadomości Keepalive od swojego partnera.
    • Jeśli odebrana zostanie wiadomość Keepalive i żaden timer nie upłynął przed odebraniem wiadomości Keepalive, BGP przechodzi do stanu Established.
    • Jeśli licznik czasu upłynie przed odebraniem komunikatu Keepalive lub wystąpi błąd, router powraca do stanu bezczynności.
  • Stan ustanowiony :
    • W tym stanie peery wysyłają wiadomości Update w celu wymiany informacji o każdej trasie ogłaszanej do peera BGP.
    • Jeśli w komunikacie aktualizacji jest jakiś błąd, do peera wysyłana jest wiadomość z powiadomieniem, a protokół BGP przechodzi z powrotem do stanu bezczynności.

Łączność routera i trasy nauki

W najprostszym układzie wszystkie routery w jednym AS i uczestniczące w routingu BGP muszą być skonfigurowane w pełnej siatce: każdy router musi być skonfigurowany jako równorzędny z każdym innym routerem. Powoduje to problemy ze skalowaniem, ponieważ liczba wymaganych połączeń rośnie kwadratowo wraz z liczbą zaangażowanych routerów. Aby złagodzić ten problem, BGP implementuje dwie opcje: route reflectors (RFC 4456) i konfederacje BGP (RFC 5065). Poniższe omówienie podstawowego przetwarzania UPDATE zakłada pełną siatkę iBGP.

Dany router BGP może akceptować aktualizacje NLRI (Network Layer Reachability Information) od wielu sąsiadów i rozgłaszać NLRI do tego samego lub innego zestawu sąsiadów. Koncepcyjnie BGP utrzymuje własną główną tablicę routingu, zwaną lokalną bazą informacji o routingu (Loc-RIB), oddzieloną od głównej tablicy routingu routera. Dla każdego sąsiada proces BGP utrzymuje koncepcyjną bazę informacji o sąsiednim routingu, przychodzącą (Adj-RIB-In) zawierającą NLRI otrzymaną od sąsiada oraz koncepcyjną bazę informacji wychodzących (Adj-RIB-Out) dla NLRI do wysłania do sąsiad.

O fizycznym przechowywaniu i strukturze tych tabel koncepcyjnych decyduje realizator kodu BGP. Ich struktura nie jest widoczna dla innych routerów BGP, chociaż zazwyczaj można je odpytywać za pomocą poleceń zarządzania na routerze lokalnym. Na przykład dość powszechne jest przechowywanie dwóch Adj-RIB i Loc-RIB razem w tej samej strukturze danych, z dodatkowymi informacjami dołączonymi do wpisów RIB. Dodatkowe informacje informują proces BGP, na przykład, czy poszczególne wpisy należą do Adj-RIB dla określonych sąsiadów, czy proces wyboru trasy peer-neighbor spowodował, że otrzymane polityki kwalifikują się do Loc-RIB i czy wpisy Loc-RIB kwalifikują się do być przesyłane do procesu zarządzania tablicami routingu routera lokalnego.

BGP prześle trasy, które uzna za najlepsze, do procesu głównej tablicy routingu. W zależności od implementacji tego procesu, niekoniecznie wybierana jest trasa BGP. Na przykład, zwykle preferowany jest prefiks podłączony bezpośrednio, wyuczony z własnego sprzętu routera. Dopóki interfejs tej bezpośrednio połączonej trasy jest aktywny, trasa BGP do miejsca docelowego nie zostanie umieszczona w tablicy routingu. Gdy interfejs przestanie działać i nie będzie już preferowanych tras, trasa Loc-RIB zostanie zainstalowana w głównej tablicy routingu.

Do niedawna powszechnym błędem było mówienie „BGP zawiera polisy”. BGP faktycznie przeniósł informacje, za pomocą których reguły wewnątrz routerów mówiących przez BGP mogą podejmować decyzje dotyczące polityki. Niektóre z przekazywanych informacji, które są wyraźnie przeznaczone do wykorzystania przy podejmowaniu decyzji politycznych, dotyczą społeczności i dyskryminatorów wielokrotnych wyjazdów (MED).

Standard BGP określa szereg czynników decyzyjnych, więcej niż te, które są używane w jakimkolwiek innym powszechnym procesie routingu, do wyboru NLRI, aby przejść do Loc-RIB. Pierwszym punktem decyzyjnym do oceny NLRI jest to, że jego atrybut następnego przeskoku musi być osiągalny (lub rozwiązywalny). Innym sposobem powiedzenia, że ​​następny skok musi być osiągalny, jest to, że musi istnieć aktywna trasa, już w głównej tablicy routingu routera, do prefiksu, w którym adres następnego skoku jest osiągalny.

Następnie, dla każdego sąsiada, proces BGP stosuje różne kryteria standardowe i zależne od implementacji, aby zdecydować, które trasy powinny przejść do Adj-RIB-In. Sąsiad może wysłać kilka możliwych tras do miejsca docelowego, ale pierwszy poziom preferencji znajduje się na poziomie sąsiada. W koncepcyjnym wejściu Adj-RIB-In zostanie zainstalowana tylko jedna trasa do każdego miejsca docelowego. Ten proces usunie również z wejścia Adj-RIB-In wszystkie trasy, które zostały wycofane przez sąsiada.

Ilekroć zmienia się koncepcyjny Adj-RIB-In, główny proces BGP decyduje, czy którakolwiek z nowych tras sąsiada jest preferowana względem tras już znajdujących się w Loc-RIB. Jeśli tak, to je zastępuje. Jeśli dana trasa jest wycofana przez sąsiada i nie ma innej trasy do tego miejsca docelowego, trasa jest usuwana z Loc-RIB i nie jest już wysyłana przez BGP do głównego menedżera tablicy routingu. Jeśli router nie ma trasy do tego miejsca docelowego z żadnego źródła innego niż BGP, wycofana trasa zostanie usunięta z głównej tablicy routingu.

Po sprawdzeniu, czy następny przeskok jest osiągalny, jeśli trasa pochodzi z wewnętrznego (tj. iBGP) peera, pierwszą zasadą do zastosowania, zgodnie ze standardem, jest sprawdzenie atrybutu LOCAL_PREFERENCE. Jeśli istnieje kilka tras iBGP od sąsiada, wybierana jest ta z najwyższą wartością LOCAL_PREFERENCE, chyba że istnieje kilka tras o tej samej wartości LOCAL_PREFERENCE. W tym drugim przypadku proces wyboru trasy przechodzi do następnego rozstrzygnięcia . Chociaż LOCAL_PREFERENCE jest pierwszą regułą w standardzie, po zweryfikowaniu osiągalności NEXT_HOP, Cisco i kilku innych dostawców najpierw rozważa czynnik decyzyjny zwany WEIGHT, który jest lokalny dla routera (tzn. nie jest przesyłany przez BGP). Preferowana jest trasa o największej MASY.

LOCAL_PREFERENCE, WEIGHT i inne kryteria mogą być manipulowane przez lokalną konfigurację i możliwości oprogramowania. Taka manipulacja, choć powszechnie stosowana, wykracza poza zakres normy. Na przykład atrybut COMMUNITY (patrz poniżej) nie jest bezpośrednio używany w procesie wyboru protokołu BGP. Jednak sąsiedni proces BGP może mieć regułę ustawiającą LOCAL_PREFERENCE lub inny czynnik oparty na ręcznie zaprogramowanej regule, aby ustawić atrybut, jeśli wartość COMMUNITY pasuje do jakiegoś kryterium dopasowania wzorca. Jeśli trasa została poznana od zewnętrznego peera, proces BGP każdego sąsiada oblicza wartość LOCAL_PREFERENCE na podstawie lokalnych reguł polityki, a następnie porównuje LOCAL_PREFERENCE wszystkich tras od sąsiada.

Na poziomie sąsiada — ignorując modyfikatory polityki specyficzne dla implementacji — kolejność reguł rozstrzygania remisów jest następująca:

  1. Preferuj trasę o najkrótszej AS_PATH. AS_PATH to zestaw numerów AS, przez które należy przejść, aby dotrzeć do ogłoszonego miejsca docelowego. AS1-AS2-AS3 jest krótszy niż AS4-AS5-AS6-AS7.
  2. Preferuj trasy o najniższej wartości atrybutu ORIGIN.
  3. Preferuj trasy z najniższą wartością MULTI_EXIT_DISC (dyskryminator wielu wyjść lub MED).

Po otrzymaniu kandydujących tras od sąsiadów oprogramowanie Loc-RIB stosuje dodatkowe wyłączniki remisowe do tras do tego samego miejsca docelowego.

  1. Jeśli przynajmniej jedna trasa została nauczona od zewnętrznego sąsiada (tj. trasa została nauczona z eBGP), usuń wszystkie trasy nauczone z iBGP.
  2. Preferuj trasę o najniższym koszcie wewnętrznym do NEXT_HOP, zgodnie z główną tablicą routingu. Jeśli dwóch sąsiadów ogłasza tę samą trasę, ale jeden sąsiad jest osiągalny przez łącze o niskiej przepływności, a drugi przez łącze o wysokiej przepływności, a wewnętrzny protokół routingu obliczy najniższy koszt na podstawie najwyższej przepływności, trasa przez łącze o wysokiej przepływności byłyby preferowane, a inne trasy zrezygnowano.
Jeśli w tym momencie istnieje więcej niż jedna trasa, kilka implementacji BGP oferuje konfigurowalną opcję podziału obciążenia między trasy, akceptując wszystkie (lub wszystkie do pewnej liczby).
  1. Preferuj trasę poznaną od rozmówcy BGP o najniższym numerycznie identyfikatorze BGP
  2. Preferuj trasę nauczoną od głośnika BGP z najniższym adresem IP peera

Społeczności

Społeczności BGP to znaczniki atrybutów, które można zastosować do przychodzących lub wychodzących prefiksów, aby osiągnąć pewien wspólny cel. Chociaż powszechnie mówi się, że BGP pozwala administratorowi ustalać zasady dotyczące obsługi prefiksów przez dostawców usług internetowych, ogólnie rzecz biorąc, nie jest to możliwe, ściśle mówiąc. Na przykład, BGP natywnie nie ma pomysłu, aby pozwolić jednemu AS na przekazanie innemu AS ograniczenia reklamy prefiksu tylko do klientów z Ameryki Północnej. Zamiast tego dostawca usług internetowych na ogół publikuje listę dobrze znanych lub prawnie zastrzeżonych społeczności z opisem dla każdej z nich, co zasadniczo stanowi zgodę na to, jak należy traktować prefiksy. RFC 1997 definiuje trzy dobrze znane społeczności o znaczeniu globalnym; NO_EXPORT, NO_ADVERTISE i NO_EXPORT_SUBCONFED. RFC 7611 definiuje ACCEPT_OWN. Przykłady typowych społeczności obejmują lokalne dostosowania preferencji, ograniczenia geograficzne lub typu peer -to- peer, identyfikacja ataku typu „ odmowa usługi” oraz opcje prependingu AS. Dostawca usług internetowych może stwierdzić, że wszelkie trasy otrzymane od klientów ze społeczności XXX:500 będą rozgłaszane do wszystkich równorzędnych użytkowników (domyślnie), podczas gdy społeczność XXX:501 będzie rozgłaszana tylko do Ameryki Północnej. Klient po prostu dostosowuje swoją konfigurację tak, aby zawierała odpowiednią społeczność lub społeczności dla każdej trasy, a dostawca usług internetowych odpowiada za kontrolowanie, komu prefiks jest rozgłaszany. Użytkownik końcowy nie ma technicznej możliwości wyegzekwowania prawidłowych działań podejmowanych przez dostawcę usług internetowych, chociaż problemy w tym obszarze są na ogół rzadkie i przypadkowe.

Powszechną taktyką dla klientów końcowych jest używanie społeczności BGP (zwykle ASN:70,80,90,100) do kontrolowania lokalnych preferencji, które ISP przypisuje do ogłaszanych tras zamiast korzystania z MED (efekt jest podobny). Atrybut community jest przechodni, ale społeczności zastosowane przez klienta bardzo rzadko są propagowane poza AS następnego przeskoku. Nie wszyscy dostawcy usług internetowych udostępniają swoje społeczności opinii publicznej.

BGP Extended Community Attribute został dodany w 2006 roku w celu rozszerzenia zakresu takich atrybutów i zapewnienia struktury atrybutu społeczności za pomocą pola typu. Rozszerzony format składa się z jednego lub dwóch oktetów dla pola typu, po których następuje siedem lub sześć oktetów dla odpowiedniej zawartości atrybutu community. Definicja tego Extended Community Attribute jest udokumentowana w RFC 4360. IANA administruje rejestrem BGP Extended Communities Types. Sam atrybut Extended Communities jest przechodnim opcjonalnym atrybutem BGP. Jednak bit w polu typu w atrybucie decyduje o tym, czy zakodowana rozszerzona społeczność ma charakter przechodni, czy nieprzechodni. Rejestr IANA zapewnia zatem różne zakresy numerów dla typów atrybutów. Ze względu na rozszerzony zakres atrybutów, jego zastosowanie może być wielorakie. RFC 4360 przykładowo definiuje „dwuoktetową rozszerzoną społeczność AS”, „rozszerzoną społeczność specyficzną dla adresu IPv4”, „nieprzezroczystą rozszerzoną społeczność”, „wspólnotę docelową trasy” oraz „wspólnotę źródła trasy”. Wiele wersji roboczych BGP QoS również używa tej struktury Extended Community Attribute do międzydomenowej sygnalizacji QoS.

Uwaga: od RFC 7153 rozszerzone społeczności są kompatybilne z 32-bitowymi ASN-ami.

Wraz z wprowadzeniem 32-bitowych numerów AS od razu pojawiły się pewne problemy związane z atrybutem community, który definiuje tylko 16-bitowe pole ASN, co uniemożliwia dopasowanie między tym polem a rzeczywistą wartością ASN. Jest to powód, dla którego RFC 8092 i RFC 8195 wprowadzają atrybut Large Community o wielkości 12 bajtów, podzielony na trzy pola po 4 bajty (AS:function:parameter).

Dyskryminatory wielowyjściowe

MEDs, zdefiniowane w głównym standardzie BGP, miały pierwotnie pokazywać innemu sąsiadowi AS preferencje reklamowego AS, które z kilku łączy są preferowane dla ruchu przychodzącego. Innym zastosowaniem MEDs jest ogłaszanie wartości, zwykle opartej na opóźnieniu, wielu AS, które są obecne w IXP , które narzucają w celu wysłania ruchu do jakiegoś miejsca przeznaczenia.

Format nagłówka wiadomości

Oto format nagłówka wiadomości BGP w wersji 4:

przesunięcie bitowe 0-15 16–23 24-31
0 Znacznik
32
64
96
128 Długość Rodzaj
  • Znacznik : Dołączony ze względu na kompatybilność, musi być ustawiony na wszystkie.
  • Długość : całkowita długość wiadomości w oktetach , łącznie z nagłówkiem.
  • Typ : typ wiadomości BGP. Zdefiniowano następujące wartości:
    • Otwarte (1)
    • Aktualizacja (2)
    • Powiadomienie (3)
    • Utrzymuj przy życiu (4)
    • Odświeżanie trasy (5)

Skalowalność wewnętrzna

BGP jest „najbardziej skalowalnym ze wszystkich protokołów routingu”.

Autonomiczny system z wewnętrznym BGP (iBGP) musi mieć wszystkich swoich sąsiadów iBGP połączonych ze sobą w pełnej siatce (gdzie każdy rozmawia bezpośrednio ze wszystkimi). Ta konfiguracja z pełną siatką wymaga, aby każdy router utrzymywał sesję z każdym innym routerem. W dużych sieciach ta liczba sesji może obniżyć wydajność routerów z powodu braku pamięci lub wysokich wymagań procesora.

Reflektory tras

Reflektory trasowe zmniejszają liczbę połączeń wymaganych w AS. Pojedynczy router (lub dwa w przypadku redundancji) może stać się reflektorem trasy: inne routery w systemie AS muszą być skonfigurowane tylko jako równorzędne z nimi. Odbłyśnik trasy stanowi alternatywę dla logicznej pełnej siatki wymogu protokołu bramy wewnętrznej granicy (IBGP). RR działa jako punkt centralny dla sesji IBGP. Celem RR jest koncentracja. Wiele routerów BGP może być równorzędnych z punktem centralnym, RR – działającym jako serwer reflektora trasy – zamiast równorzędnych z każdym innym routerem w pełnej siatce. Wszystkie pozostałe routery IBGP stają się klientami routingu.

To podejście, podobne do funkcji DR/BDR OSPF , zapewnia dużym sieciom dodatkową skalowalność IBGP. W pełni meshowej sieci IBGP składającej się z 10 routerów, 90 indywidualnych instrukcji CLI (rozłożonych na wszystkie routery w topologii) jest potrzebnych tylko po to, aby zdefiniować zdalny AS każdego peera: zarządzanie to szybko staje się problemem. Topologia RR może skrócić te 90 instrukcji do 18, oferując opłacalne rozwiązanie dla większych sieci administrowanych przez dostawców usług internetowych.

Reflektor trasy jest pojedynczym punktem awarii , dlatego co najmniej drugi reflektor trasy może być skonfigurowany w celu zapewnienia nadmiarowości. Ponieważ jest to dodatkowy węzeł równorzędny dla pozostałych 10 routerów, zawiera dodatkową instrukcję, która podwaja liczbę minus 2 pojedynczej konfiguracji Route Reflector. Dodatkowe 11*2-2=20 instrukcji w tym przypadku ze względu na dodanie dodatkowego routera. Dodatkowo, w środowisku wielościeżkowym BGP może to również skorzystać, dodając lokalną przepustowość przełączania/routowania, jeśli RR działają jako tradycyjne routery, a nie tylko jako dedykowana rola serwera Route Reflector.

Zasady

Typowa konfiguracja wdrożenia BGP Route Reflector, zaproponowana w sekcji 6, RFC 4456.

Serwery RR propagują trasy wewnątrz AS w oparciu o następujące zasady:

  • Jeśli trasa jest odbierana od peera niebędącego klientem, należy uwzględnić tylko klientów i sąsiadów EBGP.
  • Jeśli trasa jest odebrana od równorzędnego klienta, odbij się na wszystkich równorzędnych klientach, a także na równorzędnych klientach, z wyjątkiem nadawcy trasy i oddzwaniaj do równorzędnych partnerów EBGP.

Grupa

RR i jego klienci tworzą „Klaster”. „Cluster-ID” jest następnie dołączany do każdej trasy ogłaszanej przez RR do swoich klientów lub elementów równorzędnych nie będących klientami. Cluster-ID to skumulowany, nieprzechodni atrybut BGP i każdy RR MUSI dołączyć lokalny CLUSTER_ID do CLUSTER_LIST, aby uniknąć pętli routingu. Zarówno reflektory tras, jak i konfederacje zmniejszają liczbę sąsiadów iBGP do każdego routera, a tym samym zmniejszają obciążenie przetwarzania. Reflektory tras to czysta technika zwiększająca wydajność, podczas gdy konfederacje mogą być również wykorzystywane do wdrażania bardziej szczegółowej polityki.

Konfederacja BGP

Konfederacje to zestawy systemów autonomicznych. W powszechnej praktyce tylko jeden z numerów AS konfederacji jest postrzegany przez Internet jako całość. Konfederacje są używane w bardzo dużych sieciach, w których duży AS można skonfigurować tak, aby obejmował mniejsze, łatwiejsze w zarządzaniu wewnętrzne systemy AS.

Skonfederowany AS składa się z wielu AS. Każdy skonfederowany system autonomiczny ma w pełni zazębiony iBGP i ma połączenia z innymi systemami autonomicznymi wewnątrz konfederacji. Mimo że te AS mają sąsiadów eBGP z AS w ramach konfederacji, AS wymieniają routing tak, jakby używały iBGP. W ten sposób konfederacja zachowuje informacje o następnym przeskoku, metryce i preferencjach lokalnych. Światowi zewnętrznemu konfederacja wydaje się być jednym AS. Dzięki temu rozwiązaniu problemy z tranzytem iBGP AS mogą być rozwiązane, ponieważ iBGP wymaga pełnej siatki pomiędzy wszystkimi routerami BGP: dużej liczby sesji TCP i niepotrzebnego powielania ruchu routingu.

Konfederacje mogą być używane w połączeniu z reflektorami tras. Zarówno konfederacje, jak i reflektory tras mogą podlegać ciągłym oscylacjom, chyba że przestrzegane są określone zasady projektowe, mające wpływ zarówno na BGP, jak i wewnętrzny protokół routingu.

Jednak te alternatywy mogą powodować własne problemy, w tym następujące:

  • oscylacja trasy
  • routing nieoptymalny
  • wydłużenie czasu konwergencji BGP

Ponadto reflektory tras i konfederacje BGP nie zostały zaprojektowane w celu ułatwienia konfiguracji routera BGP. Niemniej jednak są to typowe narzędzia dla doświadczonych architektów sieci BGP. Narzędzia te można łączyć np. w hierarchię reflektorów tras.

Stabilność

Tabele routingu zarządzane przez implementację BGP są stale dostosowywane, aby odzwierciedlać rzeczywiste zmiany w sieci, takie jak zerwanie i przywrócenie łączy lub wyłączenie i ponowne uruchomienie routerów. W sieci jako całości normalne jest, że zmiany te następują niemal w sposób ciągły, ale w przypadku konkretnego routera lub łącza zmiany powinny być stosunkowo rzadkie. Jeśli router jest źle skonfigurowany lub zarządzany, może wchodzić w szybki cykl między stanami down i up. Ten wzorzec powtarzającego się wycofywania i ponownego ogłaszania, znany jako trzepotanie trasy, może powodować nadmierną aktywność we wszystkich innych routerach, które wiedzą o zerwanym łączu, ponieważ ta sama trasa jest stale wstrzykiwana i wycofywana z tablic routingu. Projekt BGP jest taki, że dostarczanie ruchu może nie działać podczas aktualizacji tras. W Internecie zmiana routingu BGP może powodować kilkuminutowe przerwy w działaniu.

Funkcja znana jako tłumienie klap trasy ( RFC 2439 ) jest wbudowana w wiele implementacji BGP w celu złagodzenia skutków klapowania trasy. Bez tłumienia nadmierna aktywność może powodować duże obciążenie przetwarzania na routerach, co z kolei może opóźniać aktualizacje na innych trasach, a tym samym wpływać na ogólną stabilność routingu. W przypadku tłumienia trzepotanie trasy wykładniczo zanika . W pierwszym przypadku, gdy trasa staje się niedostępna i szybko pojawia się ponownie, tłumienie nie działa, aby utrzymać normalne czasy przełączania BGP. Przy drugim wystąpieniu BGP unika tego prefiksu przez pewien czas; kolejne wystąpienia są przekroczone wykładniczo. Po ustąpieniu nieprawidłowości i upłynięciu odpowiedniego czasu dla obraźliwej trasy prefiksy mogą zostać przywrócone, a jej tablica wyczyszczona. Tłumienie może również łagodzić ataki typu „odmowa usługi ”; czasy tłumienia można w dużym stopniu dostosować.

Sugeruje się również w RFC 2439 (w sekcji „Wybory projektowe -> Wrażliwe tłumienie reklam trasy”), że tłumienie klap trasy jest funkcją bardziej pożądaną, jeśli zostanie zaimplementowane w sesjach protokołu bramy zewnętrznej granicy (sesje eBGP lub po prostu nazywane zewnętrznymi peerami), a nie o sesjach protokołu Internal Border Gateway (sesje iBGP lub po prostu nazywane wewnętrznymi peerami); Dzięki takiemu podejściu, gdy trasa trzepocze wewnątrz systemu autonomicznego, nie jest propagowana do zewnętrznych AS – trzepotanie trasy do eBGP będzie miało łańcuch trzepotania dla konkretnej trasy w całym szkielecie. Ta metoda również skutecznie pozwala uniknąć narzutu tłumienia klap trasy w sesjach iBGP.

Jednak późniejsze badania wykazały, że tłumienie klap może w niektórych przypadkach wydłużyć czas zbieżności i może powodować przerwy w łączności, nawet gdy łącza nie trzepoczą. Co więcej, ponieważ łącza szkieletowe i procesory routerów stały się szybsze, niektórzy architekci sieci sugerowali, że tłumienie klap może nie być tak ważne jak kiedyś, ponieważ routery mogą znacznie szybciej obsłużyć zmiany w tablicy routingu. Skłoniło to grupę roboczą RIPE Routing do napisania, że ​​„przy obecnych implementacjach tłumienia klap BGP stosowanie tłumienia klap w sieciach ISP NIE jest zalecane. -wpływ na ich klientów i użytkowników Internetu treści i usług ich klientów… Te skutki uboczne byłyby prawdopodobnie gorsze niż wpływ spowodowany po prostu brakiem działania tłumienia klap”. Poprawa stateczności bez problemów z tłumieniem klap jest przedmiotem aktualnych badań.

Wzrost tabeli routingu

Wzrost tabeli BGP w Internecie
Liczba AS w Internecie a liczba zarejestrowanych AS

Jednym z największych problemów, z jakimi boryka się BGP, a właściwie cała infrastruktura internetowa, jest wzrost tablicy routingu Internetu. Jeśli globalna tablica routingu rozrośnie się do punktu, w którym niektóre starsze, mniej wydajne routery nie będą w stanie sprostać wymaganiom pamięci lub obciążeniu procesora w celu utrzymania tablicy, routery te przestaną być efektywnymi bramami między częściami Internetu, z którymi się łączą. Ponadto, co być może nawet ważniejsze, stabilizacja większych tablic routingu trwa dłużej (patrz powyżej) po poważnej zmianie łączności, przez co usługa sieciowa jest w międzyczasie zawodna lub nawet niedostępna.

Do końca 2001 r. globalna tablica routingu rosła wykładniczo , grożąc w końcu powszechnym załamaniem łączności. Próbując temu zapobiec, dostawcy usług internetowych współpracowali w celu utrzymania możliwie najmniejszej globalnej tablicy routingu, używając bezklasowego routingu międzydomenowego (CIDR) i agregacji tras . Chociaż spowolniło to wzrost tablicy routingu do procesu liniowego przez kilka lat, wraz ze zwiększonym zapotrzebowaniem na wieloadresowe sieci użytkowników końcowych, do połowy 2004 r. wzrost ponownie był superliniowy.

512 tys. dni

Przepełnienie podobne do roku 2000, które wystąpiło w 2014 r. dla tych modeli, które nie zostały odpowiednio zaktualizowane.

Podczas gdy pełna tablica protokołu IPv4 BGP w sierpniu 2014 r. (512 tys. dni) przekraczała 512 000 prefiksów, wiele starszych routerów miało limit 512 tys. (512 000-524 288) wpisów w tablicy routingu. 12 sierpnia 2014 r. przerwy wynikające z pełnych stolików dotknęły m.in. eBay , LastPass i Microsoft Azure . Wiele powszechnie używanych routerów Cisco posiadało TCAM , formę szybkiej pamięci adresowalnej zawartością do przechowywania rozgłaszanych tras BGP. Na dotkniętych routerach TCAM został domyślnie przydzielony jako 512 tys. tras IPv4 i 256 tys. tras IPv6. Podczas gdy zgłoszona liczba anonsowanych tras IPv6 wynosiła tylko około 20 tys., liczba anonsowanych tras IPv4 osiągnęła domyślny limit, powodując efekt uboczny, ponieważ routery próbowały zrekompensować problem, używając wolnego routingu programowego (w przeciwieństwie do szybkiego routingu sprzętowego przez TCAM ). Główna metoda radzenia sobie z tym problemem polega na zmianie alokacji TCAM przez operatorów, aby umożliwić więcej wpisów IPv4, poprzez ponowne przydzielenie części TCAM zarezerwowanych dla tras IPv6, co wymaga ponownego uruchomienia na większości routerów. Problem 512k był przewidziany przez wielu specjalistów IT.

Faktyczne przydziały, które spowodowały wzrost liczby tras powyżej 512 tys., to ogłoszenie około 15 000 nowych tras w krótkim czasie, począwszy od 07:48 UTC. Prawie wszystkie z tych tras trafiały do Verizon Autonomous Systems 701 i 705, powstały w wyniku dezagregacji większych bloków, wprowadzając tysiące nowych / 24 tras i sprawiając, że tablica routingu osiągnęła 515 000 wpisów. Wydaje się, że nowe trasy zostały ponownie zagregowane w ciągu 5 minut, ale niestabilność w Internecie najwyraźniej utrzymywała się przez kilka godzin. Nawet gdyby Verizon nie spowodował przekroczenia przez tablicę routingu 512 tysięcy wpisów w krótkim skoku, to i tak nastąpiłoby to wkrótce dzięki naturalnemu wzrostowi.

Podsumowanie tras jest często używane w celu poprawy agregacji globalnej tablicy routingu BGP, zmniejszając w ten sposób niezbędny rozmiar tablicy w routerach AS. Rozważ AS1 została przydzielona wielką przestrzeń adresową 172.16.0.0 / 16 , to będzie traktowany jako jednej trasy w tabeli, ale ze względu na potrzeby wymagań klienta lub inżynierii ruchu, AS1 chce ogłosić mniejszych, bardziej konkretne trasy 172.16.0.0 / 18 , 172.16.64.0 / 18 i 172.16.128.0 / 18 . Prefiks 172.16.192.0 / 18 nie zawiera żadnych hostów, więc AS1 nie ogłasza określonej trasy 172.16.192.0 / 18 . To wszystko liczy się jako AS1 ogłaszający cztery trasy.

AS2 będzie zobaczyć cztery trasy z AS1 ( 172.16.0.0 / 16 , 172.16.0.0 / 18 , 172.16.64.0 / 18 i 172.16.128.0 / 18 ) i to do polityki routingu AS2 zdecydować, czy weź kopię czterech tras lub, ponieważ 172.16.0.0 / 16 nakłada się na wszystkie inne określone trasy, aby po prostu zapisać podsumowanie, 172.16.0.0 / 16 .

Jeśli AS2 chce wysłać dane z prefiksem 172.16.192.0 / 18 , zostaną one wysłane do routerów AS1 na trasie 172.16.0.0/16 . Na routerze AS1 zostanie on albo odrzucony, albo zostanie odesłany komunikat ICMP o nieosiągalnym miejscu docelowym , w zależności od konfiguracji routerów AS1.

Jeśli AS1 później zdecyduje się porzucić trasę 172.16.0.0 / 16 , pozostawiając 172.16.0.0 / 18 , 172.16.64.0 / 18 i 172.16.128.0 / 18 , AS1 zmniejszy liczbę ogłaszanych tras do trzech. AS2 zobaczy trzy trasy i w zależności od polityki routingu AS2 będzie przechowywać kopię trzech tras lub agregować prefiksy 172.16.0.0/18 i 172.16.64.0 / 18 do 172.16.0.0 / 17 , zmniejszając w ten sposób liczba tras, które AS2 przechowuje do tylko dwóch: 172.16.0.0 / 17 i 172.16.128.0 / 18 .

Jeśli AS2 chce wysłać dane z prefiksem 172.16.192.0 / 18 , zostanie on odrzucony lub wiadomość ICMP o nieosiągalnym miejscu docelowym zostanie odesłana na routery AS2 (nie AS1, jak wcześniej), ponieważ 172.16.192.0 / 18 nie będzie w tablicy routingu.

Wyczerpywanie numerów AS i 32-bitowe ASN

RFC 1771 ( A Border Gateway Protocol 4 (BGP-4) ) zaplanował kodowanie numerów AS na 16 bitach, dla 64510 możliwych publicznych AS, ponieważ ASN 64512 do 65534 były zarezerwowane do użytku prywatnego (zabronione 0 i 65535). W 2011 r. wciąż dostępnych było tylko 15000 numerów AS, a prognozy przewidywały całkowite wyczerpanie dostępnych numerów AS we wrześniu 2013 r.

RFC 6793 rozszerza kodowanie AS z 16 do 32 bitów (zachowując 16-bitowy zakres AS od 0 do 65535 i zarezerwowane numery AS), co pozwala teraz na dostęp do 4 miliardów AS. Dodatkowy prywatny zakres AS jest również zdefiniowany w RFC 6996 (od 4200000000 do 4294967294, 4294967295 jest zabronione przez RFC 7300).

Aby umożliwić przechodzenie grup routerów, które nie są w stanie zarządzać tymi nowymi ASN-ami, używany jest nowy atrybut OT AS4_PATH.

32-bitowe przypisania ASN rozpoczęły się w 2007 roku.

Równoważenie obciążenia

Innym czynnikiem powodującym ten wzrost tablicy routingu jest potrzeba równoważenia obciążenia sieci wieloadresowych. Zrównoważenie ruchu przychodzącego do sieci wieloadresowej na wielu ścieżkach przychodzących nie jest łatwym zadaniem, ze względu na ograniczenia procesu wyboru trasy BGP. W przypadku sieci wieloadresowej, jeśli ogłasza te same bloki sieciowe na wszystkich swoich sąsiadach BGP, może to spowodować, że jedno lub kilka jej łączy przychodzących stanie się przeciążone, podczas gdy inne łącza pozostaną niewykorzystane, ponieważ wszystkie sieci zewnętrzne wybrały to. zestaw zatłoczonych ścieżek jako optymalny. Podobnie jak większość innych protokołów routingu, BGP nie wykrywa przeciążenia.

Aby obejść ten problem, administratorzy BGP tej sieci wieloadresowej mogą podzielić duży, ciągły blok adresów IP na mniejsze bloki i dostosować ogłoszenie trasy, aby różne bloki wyglądały optymalnie na różnych ścieżkach, tak aby zewnętrzne sieci wybierały inną ścieżkę, aby dotrzeć do różnych bloki tej sieci wieloadresowej. Takie przypadki zwiększą liczbę tras widocznych w globalnej tabeli BGP.

Jedną z coraz bardziej popularnych metod rozwiązywania problemu równoważenia obciążenia jest wdrożenie bram BGP/LISP ( Protokół separacji lokalizacji/identyfikatorów ) w punkcie wymiany w Internecie, aby umożliwić inżynierię ruchu przychodzącego przez wiele łączy. Ta technika nie zwiększa liczby tras widocznych w globalnej tablicy BGP.

Bezpieczeństwo

Zobacz też: przejęcie BGP

Zgodnie z projektem routery obsługujące protokół BGP domyślnie akceptują anonsowane trasy z innych routerów BGP. Pozwala to na automatyczne i zdecentralizowane kierowanie ruchu w Internecie, ale jednocześnie naraża Internet na przypadkowe lub złośliwe zakłócenia, znane jako porwanie BGP . Ze względu na stopień, w jakim BGP jest osadzony w podstawowych systemach Internetu oraz liczbę różnych sieci obsługiwanych przez wiele różnych organizacji, które wspólnie tworzą Internet, usunięcie tej luki (np. poprzez wprowadzenie użycia kluczy kryptograficznych do weryfikacji tożsamość routerów BGP) jest problemem trudnym technicznie i ekonomicznie.

Rozszerzenia

Rozszerzeniem BGP jest użycie wielościeżkowego - zwykle wymaga to identycznego MED, wagi, pochodzenia i ścieżki AS, chociaż niektóre implementacje zapewniają możliwość rozluźnienia sprawdzania ścieżki AS, aby oczekiwać tylko równej długości ścieżki, a nie rzeczywistych liczb AS na ścieżce, która ma pasować. Można to następnie rozszerzyć o funkcje takie jak dmzlink-bw firmy Cisco, które umożliwiają współdzielenie ruchu w oparciu o wartości przepustowości skonfigurowane na poszczególnych łączach.

Multiprotocol Extensions for BGP (MBGP), czasami określane jako Multiprotocol BGP lub Multicast BGP i zdefiniowane w IETF RFC 4760, jest rozszerzeniem (BGP), które umożliwia równoległą dystrybucję różnych typów adresów (znanych jako rodziny adresów). Podczas gdy standardowy BGP obsługuje tylko adresy unicast IPv4, Multiprotocol BGP obsługuje adresy IPv4 i IPv6 oraz obsługuje warianty unicast i multicast każdego z nich. Multiprotocol BGP umożliwia wymianę informacji o topologii routerów obsługujących multiemisję IP niezależnie od topologii normalnych routerów IPv4 unicast. W ten sposób umożliwia to topologię routingu multiemisji inną niż topologia routingu unicast. Chociaż MBGP umożliwia wymianę informacji o routingu multiemisji między domenami, inne protokoły, takie jak rodzina Protocol Independent Multicast, są potrzebne do budowania drzew i przekazywania ruchu multiemisji.

Wieloprotokołowy BGP jest również szeroko stosowany w przypadku MPLS L3 VPN, do wymiany etykiet VPN poznanych dla tras z witryn klientów przez sieć MPLS, w celu rozróżnienia między różnymi witrynami klientów, gdy ruch z innych witryn klientów dociera do dostawcy Router brzegowy (router PE) do routingu.

Zastosowania

BGP4 jest standardem dla routingu internetowego i jest wymagany od większości dostawców usług internetowych (ISP) do ustanawiania routingu między sobą. Bardzo duże prywatne sieci IP używają wewnętrznie protokołu BGP. Przykładem jest łączenie kilku dużych sieci Open Shortest Path First (OSPF), w których sam OSPF nie skaluje się do wymaganego rozmiaru. Innym powodem korzystania z BGP jest multihoming sieci w celu uzyskania lepszej redundancji, zarówno do wielu punktów dostępowych jednego dostawcy usług internetowych, jak i wielu dostawców usług internetowych.

Realizacje

Routery, zwłaszcza małe przeznaczone do użytku w małych biurach/domowych biurach (SOHO), mogą nie zawierać oprogramowania BGP. Niektóre routery SOHO po prostu nie są w stanie uruchomić BGP / używać tablic routingu BGP o dowolnej wielkości. Inne routery komercyjne mogą wymagać specjalnego obrazu wykonywalnego oprogramowania, który zawiera protokół BGP lub licencji, która to umożliwia. Pakiety open source obsługujące BGP obejmują GNU Zebra , Quagga , OpenBGPD , BIRD , XORP i Vyatta . Urządzenia sprzedawane jako przełączniki warstwy 3 rzadziej obsługują protokół BGP niż urządzenia sprzedawane jako routery , ale zaawansowane przełączniki warstwy 3 zwykle obsługują protokół BGP.

Produkty sprzedawane jako przełączniki mogą, ale nie muszą, mieć ograniczenie rozmiaru tabel BGP, takie jak 20 000 tras, znacznie mniejsze niż pełna tabela internetowa plus trasy wewnętrzne. Urządzenia te mogą być jednak całkowicie rozsądne i przydatne, gdy są używane do routingu BGP pewnej mniejszej części sieci, takiej jak konfederacja-AS reprezentująca jedno z kilku mniejszych przedsiębiorstw, które są połączone za pomocą szkieletu BGP lub małego przedsiębiorstwo, które ogłasza trasy do dostawcy usług internetowych, ale akceptuje tylko trasę domyślną i być może niewielką liczbę tras zagregowanych.

Router BGP używany tylko w sieci z pojedynczym punktem wejścia do Internetu może mieć znacznie mniejszy rozmiar tablicy routingu (a tym samym wymagania dotyczące pamięci RAM i procesora) niż sieć wieloadresowa. Nawet prosty multihoming może mieć skromny rozmiar tablicy routingu. Zobacz RFC 4098, aby uzyskać parametry wydajności niezależne od dostawcy dla zbieżności pojedynczego routera BGP w płaszczyźnie sterowania. Rzeczywista ilość pamięci wymaganej w routerze BGP zależy od ilości informacji BGP wymienianych z innymi głośnikami BGP oraz sposobu, w jaki dany router przechowuje informacje BGP. Router może być zmuszony do przechowywania więcej niż jednej kopii trasy, aby mógł zarządzać różnymi politykami anonsowania i akceptacji trasy do określonego sąsiedniego AS. Termin widok jest często używany w odniesieniu do tych różnych relacji zasad na uruchomionym routerze.

Jeśli implementacja jednego routera zajmuje więcej pamięci na trasę niż inna implementacja, może to być uzasadniony wybór projektu, polegający na zamianie szybkości przetwarzania na pamięć. Pełna tabela protokołu IPv4 BGP według stanu na sierpień 2015 r. przekracza 590 000 prefiksów. Duzi dostawcy usług internetowych mogą dodać kolejne 50% dla tras wewnętrznych i klientów. Ponownie, w zależności od implementacji, oddzielne tabele mogą być przechowywane dla każdego widoku innego równorzędnego AS.

Godne uwagi bezpłatne i otwarte implementacje BGP obejmują:

Systemy do testowania zgodności BGP, obciążenia lub obciążenia pochodzą od dostawców takich jak:

Dokumenty normatywne

  • Selektywne odświeżanie trasy dla BGP , wersja robocza IETF
  • RFC  1772 , Zastosowanie protokołu Border Gateway w protokole internetowym (BGP-4) przy użyciu SMIv2
  • RFC  2439 , tłumienie klap trasy BGP
  • RFC  2918 , możliwość odświeżania tras dla BGP-4
  • RFC  3765 , NOPEER Community for Border Gateway Protocol (BGP) Route Scope Control
  • RFC  4271 , protokół bramki granicznej 4 (BGP-4)
  • RFC  4272 , analiza luk bezpieczeństwa BGP
  • RFC  4273 , Definicje obiektów zarządzanych dla BGP-4
  • RFC  4274 , Analiza protokołu BGP-4
  • RFC  4275 , Ankieta implementacji BGP-4 MIB
  • RFC  4276 , Raport z implementacji BGP-4
  • RFC  4277 , Doświadczenie z protokołem BGP-4
  • RFC  4278 , Standards Maturity Variance w odniesieniu do opcji podpisu TCP MD5 (RFC 2385) i specyfikacji BGP-4
  • RFC  4456 , BGP Route Reflection — alternatywa dla wewnętrznego BGP o pełnej siatce (iBGP)
  • RFC 4724 , mechanizm bezpiecznego restartu dla protokołu  BGP
  • RFC  4760 , rozszerzenia wieloprotokołowe dla BGP-4
  • RFC 4893 , obsługa protokołu  BGP dla czterooktetowej przestrzeni numerycznej AS
  • RFC  5065 , konfederacje systemów autonomicznych dla BGP
  • RFC  5492 , reklama możliwości z BGP-4
  • RFC  5575 , rozpowszechnianie zasad specyfikacji przepływu
  • RFC 7752 , dystrybucja informacji o stanie łącza i ruchu w kierunku północnym przy użyciu protokołu  BGP
  • RFC  7911 , reklama wielu ścieżek w BGP
  • draft-ietf-idr-custom-decision-08  – BGP Custom Decision Process, 3 lutego 2017 r.
  • RFC  3392 , przestarzałe — reklama możliwości z BGP-4
  • RFC  2796 , przestarzałe — odbicie trasy BGP — alternatywa dla pełnej siatki iBGP
  • RFC  3065 , przestarzałe — konfederacje systemów autonomicznych dla BGP
  • RFC  1965 , przestarzałe — konfederacje systemów autonomicznych dla BGP
  • RFC  1771 , przestarzały — protokół Border Gateway 4 (BGP-4)
  • RFC  1657 , Przestarzałe — definicje obiektów zarządzanych dla czwartej wersji bramy granicznej
  • RFC  1655 , przestarzałe – zastosowanie protokołu Border Gateway w Internecie
  • RFC  1654 , przestarzały — protokół bramy granicznej 4 (BGP-4)
  • RFC  1105 , przestarzały — protokół Border Gateway (BGP)
  • RFC  2858 , przestarzałe — rozszerzenia wieloprotokołowe dla BGP-4

Zobacz też

Uwagi

Bibliografia

Dalsza lektura

Zewnętrzne linki