Border Gateway Protocol – Wikipedia, wolna encyklopedia

BGP (ang. Border Gateway Protocol) – zewnętrzny protokół trasowania (routingu). BGP w wersji czwartej jest podstawą działania współczesnego Internetu. Istnieje wiele rozszerzeń BGP stosowanych przy implementacji MPLS VPN, IPv6 czy Multicast VPN.

Jest protokołem wektora ścieżki umożliwiającym tworzenie niezapętlonych ścieżek pomiędzy różnymi systemami autonomicznymi. Obecny otwarty standard protokołu BGP jest opisany w dokumentach RFC 4271 i 1771. Protokół ten nie używa tradycyjnych metryk – analogiczną funkcję (determinanty wyboru trasy) pełnią atrybuty i algorytm wyboru. BGP pozwala na pełną redundancję w połączeniu z Internetem, jest również używany do połączenia dwóch systemów autonomicznych, do wymiany ruchu między tymi systemami.

Protokół BGP funkcjonuje w oparciu o protokół warstwy 4 modelu OSI (port TCP o numerze 179). Zapewnia to, że aktualizacje są wysyłane w sposób niezawodny, dzięki czemu w BGP niepotrzebne są mechanizmy retransmisji, segmentacji itp. Routery zestawiają pomiędzy sobą sesje BGP, dzięki którym mogą wymieniać się informacjami o dostępnych trasach (prefiksach) i wyznaczać najlepszą niezapętloną ścieżkę do sieci docelowych.

Podstawą funkcjonowania BGP jest system autonomiczny, (ang. Autonomous System, AS), czyli sieć lub grupa sieci pod wspólną administracją i ze wspólną polityką trasowania. Systemy autonomiczne identyfikowane są za pomocą numerów, zwanych numerami AS, które przyznawane są przez organizację RIR (w Europie i części Azji jest to RIPE NCC). Protokół BGP w wersji oryginalnej zakładał dwubajtowe numery AS (16 bit), co ze względu na ich ograniczoną liczbę (65536) stanowiło poważniejsze ograniczenie rozwoju Internetu niż brak numerów IP. W 2007 roku wprowadzono numery AS o długości 4 bajtów (32 bit), przez co powiększono znacznie przestrzeń dostępnej numeracji. Implementacja 32 bitowego ASN jest rozwiązana za pomocą dodatkowych atrybutów, przez co jest kompatybilna ze starszym formatem i nie wymagała wymiany oprogramowania na wszystkich routerach.

Możemy rozróżnić EBGP (ang. exterior), gdy mamy sesję między dwoma różnymi AS oraz IBGP (ang. interior), gdy sesja BGP nawiązana jest między dwoma routerami brzegowymi w obrębie jednego AS. Protokół wymiany informacji przez routery IBGP oraz EBGP jest taki sam, natomiast routery inaczej interpretują trasy otrzymane poprzez protokół BGP z własnego lub obcego systemu autonomicznego. Trasy otrzymane przy użyciu BGP od routerów znajdujących się w tym samym systemie autonomicznym (IBGP) mają zazwyczaj bardzo niski priorytet. Pozwala to na stosowanie wewnętrznych protokołów routingu (IGP) do optymalizacji tras wewnątrz systemu autonomicznego. W implementacjach stosujących tzw. dystans administracyjny, czyli parametr określający priorytet ważności tras otrzymanych za pośrednictwem danego źródła (protokołu routingu), przejawia się to domyślnym ustawieniem dystansu dla EBGP na 20 (wysoki priorytet), a dla IBGP na 200 (bardzo niski priorytet). Routery również ustawiają w różny sposób atrybuty tras przy wysyłaniu aktualizacji przez IBGP lub EBGP^[1].

Sesje mogą być zestawione pomiędzy routerami bezpośrednio połączonymi (standardowo na stykach Internetowych) lub pomiędzy zdalnymi routerami (BGP multihop). Sesje multihop są naturalne dla IBGP, w połączeniach zewnętrznych (EBGP) są rzadziej używane, gdyż najczęściej do prawidłowego działania wymagają wsparcia innych protokołów trasowania dynamicznego bądź też trasowania statycznego. Wynika to z konieczności uzyskania komunikacji na poziomie protokołu TCP z sąsiednim routerem EBGP, w przypadku braku trasy pochodzącej z innego źródła nie ma możliwości zestawienia sesji BGP.

Każdy system autonomiczny może rozgłaszać pewną liczbę adresów IP zgrupowanych w prefiksy. Np. www.onet.pl ma adres IP 213.180.130.200, Onet.pl rozgłasza prefiks 213.180.128.0/21 (czyli zakres IP 213.180.128.0-213.180.135.255) pod AS o numerze 12990. Liczba prefiksów w Internecie cały czas rośnie wraz z liczbą użytych adresów i wyczerpywaniem się adresacji (potrzeba dzielenia bloków adresowych na mniejsze), w kwietniu 2011 prefiksów w tablicy routingu było już 350000 a w maju 2013 już 450000.

BGP używa się typowo jako protokołu routingu w sieci posiadającej styki internetowe z 2 (lub więcej) dostawcami Internetu. BGP jest protokołem o długim czasie zbieżności (pobranie pełnej tablicy routingu Internetu może potrwać wiele godzin, jak również rozpowszechnienie nowego wpisu z tablicy routingu w całej sieci).

• Protokół wektora ścieżki;
• Używa TCP jako protokołu warstwy transportowej;
• Pełna tablica trasowania jest wymieniana tylko podczas początkowej sesji BGP;
• Aktualizacje przesyłane są przez port TCP o numerze 179;
• Sesje BGP są utrzymywane przez wiadomości typu „keepalive”;
• Każda zmiana w sieci powoduje wysłanie zawiadomienia o aktualizacji;
• BGP ma swoją własną tablicę BGP. Każda pozycja w sieci musi znaleźć się najpierw w tablicy BGP;
• BGP ma skomplikowaną tabelę atrybutów, np. sąsiedniego skoku i pochodzenia;
• Obsługuje VLSM i podsumowanie (zwane też bezklasowym trasowaniem międzydomenowym (ang. Classless Inter-Domain Routing (CIDR));

Każdy zestaw ścieżek (tras) przesyłanych przez BGP opisywany jest zestawem atrybutów. Pozwalają one na większą elastyczność i podejmowanie złożonych decyzji dotyczących wyboru najlepszej trasy. Atrybuty BGP są przenoszone w komunikatach aktualizacyjnych (UPDATE) protokołu BGP.

BGP definiuje następujące rodzaje atrybutów ścieżki:

• standardowe (ang. well-known) lub niestandardowe. Atrybuty standardowe muszą być rozumiane przez wszystkie implementacje BGP.
• obowiązkowe lub opcjonalne. Niektóre ze standardowych atrybutów są obowiązkowe, tzn. muszą być podane w opisie ścieżki. Wszystkie atrybuty niestandardowe są opcjonalne.
• przechodnie lub nieprzechodnie. Atrybut przechodni jest przekazywany dalej do innych routerów BGP. Wszystkie parametry standardowe są przechodnie. Atrybuty opcjonalne mogą być przechodnie (wówczas router jest zobowiązany przekazać atrybut do innych routerów, nawet jeżeli jego implementacja protokołu go nie interpretuje) lub nieprzechodnie (wówczas atrybut może zostać zignorowany).

BGP z założenia pracuje w sieciach redundantnych, gdzie istnieje kilka możliwości osiągnięcia sieci docelowej. Gdy protokół BGP otrzyma wiele ścieżek do konkretnego celu w zdalnej sieci, musi wybrać najlepszą ścieżkę. Różne ścieżki do tych samych prefiksów (a tak naprawdę ich atrybuty) są porównywane zgodnie z poniższym algorytmem. Atrybuty są sprawdzane po kolei, jeżeli dany atrybut ma taką samą wartość we wszystkich ścieżkach (opcjach dojścia do prefiksu), to porównywany jest kolejny atrybut. Atrybuty sprawdzane są z podaną kolejnością, poszukiwane jest pierwsze wystąpienie nierównych parametrów (co pozwala wybrać lepszą ścieżkę). BGP nie bierze pod uwagę kwestii związanych z jakością połączenia.

BGP zawsze propaguje najlepszą ścieżkę do wszystkich routerów równorzędnych.

Algorytm wyboru trasy stosowany przez routery Cisco^[2]:

1. Preferuj najwyższą wagę (ang. WEIGHT, lokalny parametr routingu BGP specyficzny dla Cisco, nie przesyłany do innych routerów)
2. Preferuj najwyższy LOCAL_PREF,
3. Preferuj trasy ogłoszone lokalnie przez komendę network lub redistribute.
4. Preferuj ścieżkę z krótszym AS_PATH (mniejsza liczba systemów autonomicznych w ścieżce).
5. Preferuj niższy ORIGIN.
6. Preferuj niższy MED.
7. Preferuj ścieżki z eBGP nad iBGP.
8. Preferuj ścieżki, gdzie koszt IGP do BGP next-hopa jest niższy.
9. Jeżeli włączony jest BGP multipath to zainstaluj trasę w tablicy routingu.
10. Preferuj starszą ścieżkę (otrzymaną wcześniej).
11. Preferuj ścieżkę, która ma niższy router-id.
12. Preferuj ścieżkę, która przyszła od sąsiada (neighbor) z niższym adresem IP.

• Quagga
• GNU Zebra
• OpenBGPD(inne języki) – www.openbgpd.org, zaimplementowane przez zespół OpenBSD
• XORP(inne języki)
• BIRD(inne języki) – bird.network.cz

• BGPlay,
• SSFnet. ssfnet.org. [zarchiwizowane z tego adresu (2009-03-22)].
• BGP++
• ns-BGP

• system autonomiczny
• provider independent
• protokoły trasowania
• trasowanie
• EGP
• GNS3 – darmowy symulator sprzętu Cisco/Juniper
• Vyatta – darmowy router OSPF/BGP

• Istotne RFC BGP
  • T.T. Bates T.T., E.E. Chen E.E., R.R. Chandra R.R., BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP), RFC 4456, IETF, kwiecień 2006, DOI: 10.17487/RFC4456, ISSN 2070-1721, OCLC 943595667  (ang.). (przestarzały: RFC 2796)
  • S.S. Bellovin S.S., A.A. Zinin A.A., Standards Maturity Variance Regarding the TCP MD5 Signature Option (RFC 2385) and the BGP-4 Specification, RFC 4278, IETF, styczeń 2006, DOI: 10.17487/RFC4278, ISSN 2070-1721, OCLC 943595667  (ang.).
  • D.D. McPherson D.D., K.K. Patel K.K., Experience with the BGP-4 Protocol, RFC 4277, IETF, styczeń 2006, DOI: 10.17487/RFC4277, ISSN 2070-1721, OCLC 943595667  (ang.).
  • S.S. Hares S.S., A.A. Retana A.A., BGP-4 Implementation Report, RFC 4276, IETF, styczeń 2006, DOI: 10.17487/RFC4276, ISSN 2070-1721, OCLC 943595667  (ang.).
  • S.S. Hares S.S., D.D. Hares D.D., BGP-4 MIB Implementation Survey, RFC 4275, IETF, styczeń 2006, DOI: 10.17487/RFC4275, ISSN 2070-1721, OCLC 943595667  (ang.).
  • D.D. Meyer D.D., K.K. Patel K.K., BGP-4 Protocol Analysis, RFC 4274, IETF, styczeń 2006, DOI: 10.17487/RFC4274, ISSN 2070-1721, OCLC 943595667  (ang.).
  • J.J. Haas J.J., S.S. Hares S.S., Definitions of Managed Objects for BGP-4, RFC 4273, IETF, styczeń 2006, DOI: 10.17487/RFC4273, ISSN 2070-1721, OCLC 943595667  (ang.).
  • S.S. Murphy S.S., BGP Security Vulnerabilities Analysis, RFC 4272, IETF, styczeń 2006, DOI: 10.17487/RFC4272, ISSN 2070-1721, OCLC 943595667  (ang.).
  • Y.Y. Rekhter Y.Y., T.T. Li T.T., S.S. Hares S.S., A Border Gateway Protocol 4 (BGP-4), RFC 4271, IETF, styczeń 2006, DOI: 10.17487/RFC4271, ISSN 2070-1721, OCLC 943595667  (ang.). (przestarzały: RFC 1771)
  • R.R. Chandra R.R., J.J. Scudder J.J., Capabilities Advertisement with BGP-4, RFC 3392, IETF, listopad 2002, DOI: 10.17487/RFC3392, ISSN 2070-1721, OCLC 943595667  (ang.).
  • P.P. Traina P.P., D.D. McPherson D.D., J.J. Scudder J.J., Autonomous System Confederations for BGP, RFC 3065, IETF, luty 2001, DOI: 10.17487/RFC3065, ISSN 2070-1721, OCLC 943595667  (ang.).
  • E.E. Chen E.E., Route Refresh Capability for BGP-4, RFC 2918, IETF, wrzesień 2000, DOI: 10.17487/RFC2918, ISSN 2070-1721, OCLC 943595667  (ang.).
  • Y.Y. Rekhter Y.Y., P.P. Gross P.P., Application of the Border Gateway Protocol in the Internet, RFC 1772, IETF, marzec 1995, DOI: 10.17487/RFC1772, ISSN 2070-1721, OCLC 943595667  (ang.).
• Przestarzałe RFC BGP
  • T.T. Bates T.T., R.R. Chandra R.R., E.E. Chen E.E., BGP Route Reflection - An Alternative to Full Mesh IBGP, RFC 2796, IETF, kwiecień 2000, DOI: 10.17487/RFC2796, ISSN 2070-1721, OCLC 943595667  (ang.).
  • P.P. Traina P.P., Autonomous System Confederations for BGP, RFC 1965, IETF, czerwiec 1996, DOI: 10.17487/RFC1965, ISSN 2070-1721, OCLC 943595667  (ang.).
  • Y.Y. Rekhter Y.Y., T.T. Li T.T., A Border Gateway Protocol 4 (BGP-4), RFC 1771, IETF, marzec 1995, DOI: 10.17487/RFC1771, ISSN 2070-1721, OCLC 943595667  (ang.).
  • S.S. Willis S.S., J.J. Burruss J.J., J.J. Chu J.J., Definitions of Managed Objects for the Fourth Version of the Border Gateway Protocol (BGP-4) using SMIv2, RFC 1657, IETF, lipiec 1994, DOI: 10.17487/RFC1657, ISSN 2070-1721, OCLC 943595667  (ang.).
  • Y.Y. Rekhter Y.Y., P.P. Gross P.P., Application of the Border Gateway Protocol in the Internet, RFC 1655, IETF, lipiec 1994, DOI: 10.17487/RFC1655, ISSN 2070-1721, OCLC 943595667  (ang.).
  • Y.Y. Rekhter Y.Y., T.T. Li T.T., A Border Gateway Protocol 4 (BGP-4), RFC 1654, IETF, lipiec 1994, DOI: 10.17487/RFC1654, ISSN 2070-1721, OCLC 943595667  (ang.).
  • K.K. Lougheed K.K., Y.Y. Rekhter Y.Y., Border Gateway Protocol (BGP), RFC 1105, IETF, czerwiec 1989, DOI: 10.17487/RFC1105, ISSN 2070-1721, OCLC 943595667  (ang.).
• Problem z brakiem adresów IPv4 potrzebnych do uruchomienia BGP
  • konfiguracja BGP w oparciu o adresy IPv4 PA dostawcy. lipowski.org. [zarchiwizowane z tego adresu (2014-11-29)].
  • dzierżawa adresów IPv4 na potrzeby wdrożenia BGP. lipowski.org. [zarchiwizowane z tego adresu (2014-11-29)].