> ## Content Index > Fetch the complete content index at: https://innasiec.pl/llms.txt > Use this file to discover other available public pages before exploring further. # BGP - Border gateway protocol po raz pierwszy w CCNA - URL: https://innasiec.pl/bgp-border-gateway-protocol/ - Published: 2017-10-09T19:10:48.000Z - Updated: 2024-06-25T06:55:04.000Z - Author: Rafał Rudewicz - Tags: Routing & Switching, #wordpress Po raz pierwszy w historii Cisco postanowiło umieścić podstawy Border Gateway Protocols w CCNA R&S. Oczywiście wcześniej external BGP był wspominany jako jeden ze współczesnych protokołów routingu wykorzystywany do wymiany informacji o trasach pomiędzy AS (autonomous system), jednak dopiero zdając CCNA 3.0, będziesz umiał skonfigurować oraz przeprowadzić troubleshooting tego protokołu. **CCNA** **R&S skupia się wyłącznie eBGP single-homed (połączenie do ISP jednym łączem) wersji dla ipv4\. W rzeczystych środowiskach produkcyjnych firmy posiadające wyłącznie jedno podłączenie do ISP nie zaprzątają sobie głowy BGP.** BGP jest obecnie jedynym współcześnie używanym protokołem **exterior gateway protocol (EGP)**. Należy do protokołów path vector, posiada wiele opcji konfiguracyjnych (Ich ilość wystarcza na pokrycie materiałów CCNA poprzez CCNP aż do CCIE i nadal uczysz się czegoś nowego) oraz pozwala na ogromną skalowalność i robi to świetnie. **Tak na marginesie obecna pełna tablica *„routingu Internetu”* zawiera ponad 700 tysięcy wpisów!** ![](https://test.innasiec.pl/wp-content/uploads/2019/01/wzrost-bgp-na-przestrzeni-lat.png) Zdjęcie pochodzi ze strony http://bgp.potaroo.net/ **Do głównych zalet należy zaliczyć:** - Protokół routingu typu path vector - Obsługuje VLSM, CIDR oraz summaryzację - Pełna informacja o trasach rozsyłana na starcie, potem tylko aktualizacje - Połączeniowy tryb komunikacji z użyciem portu 179 - Złożona metryka, na podstawie której wyznaczane są trasy - Dobra skalowalność, rozrastanie sieci nie stanowi problemu - Możliwe jest kierowanie ruchem poprzez odpowiednią konfigurację atrybutów metryki ## **Rozgłaszanie tras** BGP rozgłasza prefixy, wykorzystując podobny mechanizm wymiany informacji co protokoły IGP. Aby wysłać informację (BGP update), jeden z routerów musi posiadać informację o routowalnym w internecie prefiksie. Routery, które posiadają relację sąsiedztwa, nazywane są peer’ami. **W odróżnieniu od protokołów IGP, które rozgłaszają adresy nazywane *podsieciami*, adresy rozgłaszane przez BGP nazywane są *prefiksami*, *blokami adresów* oraz prawidłowo w odniesieniu do BGP *Network Layer Reachability Information (NLRI)*.** ![](https://test.innasiec.pl/wp-content/uploads/2019/01/bgp-routing-information.png) W powyższym przypadku korporacja posiada **relację sąsiedztwa (peering relationship)** ze swoim lokalnym ISP 1, do którego przesyła informację o posiadanym bloku adresów 192.10.10.0/24\. Następnie ISP 1 przesyła NLRI dalej do ISP2 który przesyła update do ISP 3 i tak dalej, aż wszystkie routery w Internecie będą znały trasę do sieci 192.10.10.0/24\. Bardzo ważną rolę w BGP odgrywa **Autonomous system number (ASN).** Identycznie jak ma to miejsce w EIGRP, termin autonomous system odnosi się do autonomicznej sieci. BGP wykorzystuje ASN – numer identyfikujący AS – w wielu aspektach konfiguracji między innymi w mechanizmach zapobiegania pętlą routingu czy wyborze najlepszej ścieżki jednak jest to poza zakresem CCNA R&S. ## **Rozgłaszanie publicznego prefixu do internetu** Rozważmy teraz typową sytuację, w której mamy dwa eBGP peeery. Z jednej strony korporację posiadająca blok adresów klasy C 192.10.10.0/24, który został podzielony na podsieci 192.10.10.0/29 oraz 192.10.10.128/26, oraz prywatny blok adresów klasy A 10.0.0.0/8\. Które podsieci zostały rozgłoszone do routera ISP poprzez eBGP? Oczywiście tylko cała klasa C 192.10.0.0/24\. Stanie się tak, ponieważ **z punktu widzenia ISP interesujący jest jedynie fakt, posiadania przez peera całej klasy C**. Ruch do poszczególnych podsieci będzie i tak przechodził przez ten styk. Obecnie tablice BGP posiadają ponad 700 tysięcy wpisów, wyobraź sobie jak bardzo by urosły gdyby zawierały informację o wszystkich podsieciach na świecie? **Prywatne klasy adresów nie powinny być rozgłaszane do internetu, nawet jeśli tak się stanie, ISP natychmiast odfiltruje takich ruch.** ![](https://test.innasiec.pl/wp-content/uploads/2019/01/korpo-do-isp.png) W drugą stronę ISP rozgłasza default-route do korporacji. Dlaczego tak? Załóżmy, że ISP 1 rozgłosi wszystkie prefiksy i router brzegowy korpo umieści wszystkie trasy w swojej tablicy routingu. Jaki adres następnego skoku będą posiadać wszystkie trasy? Oczywiście routera brzegowego ISP 1. ## **Wybór najlepszej trasy z BGP** Podobnie jak protokoły IGP BGP również posiada coś na wzór metryki, dzięki której wybierana jest najlepsza trasa. Jednakże BGP wykorzystuje nieco inne podejście do tego procesu. Po pierwsze BGP nie ma jednej definicji metryki. W rzeczywistości wykorzystuje atrybuty ścieżki (path attributes). BGP rozgłasza prefiksy wraz z listą atrybutów (sprzęt Cisco rozpoznaje 11 atrybutów). Ze względu, że wybór najlepszej trasy jest podejmowany na podstawie zestawu atrybutów wybranych przez administratora, możliwa jest bardzo precyzyjna konfiguracja, jak chcemy zarządzać przesyłanymi danymi. BGP wykorzystuje proces nazywany **selekcją najlepszej trasy.** Kiedy router otrzymuje **pakiet BGP update** zawierający prefix, który już jest w tabeli routingu, musi podjąć decyzję czy nowa trasa jest lepsza od dotychczasowej. Aby to ustalić, przeprowadzana jest seria porównań (zwykle około 10) na podstawie parametrów trasy. Takie porównywanie wymaga znacznie mniej pracy niż przykładowo uruchomienie procesu SPF dla protokołu OSPF. **Jednym z atrybutów biorących udział w porównaniu jest *AS\_Path (PA) k*tóry zawiera listę wszystkich ASN, które znajdują się na ścieżce do danego bloku adresów.** Przypomina to metrykę liczby przeskoków w RIP’ie, jednakże każdy skok to cały AS zamiast pojedyńczego routera. ![](https://test.innasiec.pl/wp-content/uploads/2019/01/bgp-as-path.png) ## **Styk internetu** Termin styk internetu odnosi się zarówno połączenia pomiędzy użytkownikiem końcowym/korporacją a ISP, jak również do połączeń ISP do ISP. **Na potrzeby CCNA R&S musisz znać tylko jeden model takiego styku zwany *single-homed*.** Pamiętaj jednak, że to nie jedyny możliwy sposób połączenia. Takie rozwiązanie ma oczywiście swoje plusy i minusy. Jeśli łącze ulegnie uszkodzeniu, tracimy dostęp do internetu do czasu naprawienia awarii. Analogiczna sytuacja występuje w przypadku awarii routerów brzegowych. Z drugiej strony takie połączenie jest zdecydowanie tańsze od rozwiązań bazujących na redundancji, czy to poprzez dołożenie dodatkowych łączy do jednego ISP, czy poprzez podłączenie do kolejnych ISP. ![](https://test.innasiec.pl/wp-content/uploads/2019/01/bgp-styk-internetu.png) **Termin Dual odnosi się do sytuacji gdy posiadamy dwa lub więcej łączy do jednego ISP.** Każdy z tych wzorców może być zastosowany do dowolnego łącza WAN, bez różnicy czy będzie to DSL, światłowód itd. ## **Konfiguracja BGP** W odróżnieniu od protokołów IGP takich jak OSPF czy EIGRP w BGP nie ma dynamicznego odkrywania sąsiadów. Wszystkie peery muszą zostać wprowadzane przez administratora. Do komunikacji wykorzystywany jest port TCP 179\. Po nawiązaniu sesji TCP dwa peery sprawdzają wzajemnie, czy powinno ustanowić relację sąsiedztwa. Jeśli weryfikacja zakończy się pomyślnie, rozpoczyna się przesyłanie pakietów BGP update z NLRI. Konfiguracja BGP rozpoczynamy od polecenia **router BGP** **asn** (numer AS, do którego należy router). Router przenosi nas wtedy do konfiguracji BGP. Następnie w celu nawiązania relacji sąsiedztwa musimy wprowadzić polecenie **neighbor *ip\_adres* remote-as** **asn.** ![](https://test.innasiec.pl/wp-content/uploads/2019/01/bgp-peery.png) ISP1#show running-config router bgp 1 neighbor 192.168.100.1 remote-as 1001 R1#show running-config router bgp 1001 neighbor 192.168.100.2 remote-as 1 Polecenie **show tcp brief** pokazuje wszystkie połączenia TCP, terminowane na routerze nie ograniczając się wyłącznie do BGP, jednak może być z powodzeniem wykorzystywane do sprawdzania poprawności relacji sąsiedztwa. ISP1#show tcp brief TCB Local Address Foreign Address (state) 1590F400 192.168.100.2.179 192.168.100.1.1025 ESTABLISHED R1#show tcp brief TCB Local Address Foreign Address (state) 1590F400 192.168.100.1.1025 192.168.100.2.179 ESTABLISHED ## Weryfikacja Polecenie **show ip bgp summary** pokazuje informacje na temat działającego protokołu na routerze oraz listę peerów. W celu sprawdzenia, czy dany peer należy do eBGP, czy do iBGP należy porównać numery AS (nie ma bezpośredniej informacji). Ostatnia kolumna **State/PfxRcd** informuje, w jakim stanie jest relacja sąsiedztwa z danym peerem. Jeśli relacja jest poprawnie nawiązana, taki status nazywa się Established. W takim wypadku zamiast nazwy stanu wyświetlana jest liczba prefixów pobranych od sąsiada. | **Idle** | Sąsiad został administracyjnie wyłączony (**neighbor shutdown**) lub router oczekuje na ponowne nawiązanie relacji. | | --------------- | ----------------------------------------------------------------------------------------------------------------------------------------- | | **Connect** | Została podjęta próba zestawienia sesji TCP jednak nie została prawidłowo zakończona. | | **Active** | Połączenie TCP zostało poprawnie zestawione, jednak żadna wiadomość BGP nie została jeszcze wysłana. | | **Opensent** | Połączenie TCP zostało poprawnie zestawione, router wysłał pierwszą wiadomość w celu nawiązania relacji sąsiedztwa **(BGP Open message)** | | **Openconfirm** | Połączenie TCP zostało poprawnie zestawione, router otrzymał wiadomość BGP Open message. Relacja sąsiedztwa nadal nie ustanowiona. | | **Established** | Routery są obecnie peer’ami BGP i mogą wymieniać informacje | ISP1 #show ip bgp summary BGP router identifier 192.168.100.2, local AS number 1 Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 192.168.100.1 4 1001 39 25 5 0 0 00:23:46 4 R1#show ip bgp summary BGP router identifier 192.168.100.1, local AS number 1001 Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 192.168.100.2 4 1 39 25 5 0 0 00:23:46 4 W celu rozgłoszenia tabeli BGP należy umieścić dany prefix w tablicy routingu. Do tego celu można wykorzystać polecenie **network *ip\_adres* mask** **maska.** Polecenie **network** jednak ma nieco inne zastosowanie niż w protokołach IGP. **Sprowadza się to do:** - Rozgłaszania tras dla całych klasowych sieci lub publicznych bloków adresów Rozgłaszania tras dla podsieci publicznych bloków adresów Rozgłaszania tras dla całych bloków adresów nawet jeżeli w tabeli routingu znajduje się wyłącznie podsieci danego bloku ## **Rozgłaszanie klasowego prefixu z Static Discard Route** Routery ISP nie potrzebują osobnych tras do korporacyjnych podsieci. Zamiast tego zdecydowanie lepszą opcją jest rozgłaszanie poprzez korporację całych bloków adresowych. Jednakże jeśli router korpo nie posiada trasy dla całego bloku adresowego **(w naszym przypadku korpo router posiada wyłącznie podsieci 192.10.10.0/29 i 192.10.10.128/26 zamiast 192.10.10.0/24**) niemożliwe jest dodanie tego bloku poleceniem **network** do tablicy BGP. Rozwiązaniem tego problemu jest stworzenie trasy nazywanej **discard route.** Polega to na stworzeniu trasy do całego bloku adresowego kierującej na interfejs **null0** poprzez polecenie **ip route *ip\_adress maska* null0\.** Od tej pory możemy dodać blok do tablicy BGP i wszystkie pakiety pasujące do danej maski zostaną odrzucone, jednakże pakiety adresowane do naszych podsieci nadal zostaną dostarczone, ponieważ routery przeszukując tablice routingu, poszukują najdłuższego dopasowania. ISP1#show ip route bgp B 192.10.10.0/24 [20/0] via 192.168.100.1, 00:11:39 R1#show ip route S 192.10.10.0/24 is directly connected, Null0