Strona korzysta z plików cookies w celu realizacji usług i zgodnie z Polityką Plików Cookies.



26.10.2020

Nowa wersja nVision

Można już pobierać nową wersję nVision
26.10.2020

Monitorowanie infrastruktury

Vertiv Environet Alert
23.10.2020

Telefonia w chmurze

NFON Cloudya
23.10.2020

Nowości w EDR

Bitdefender GravityZone
23.10.2020

Wykrywanie anomalii

Flowmon ADS11
23.10.2020

Mobilny monitor

AOC 16T2
22.10.2020

HP Pavilion

HP zaprezentowało nowe laptopy z linii Pavilion.
22.10.2020

Inteligentny monitoring

WD Purple SC QD101
22.10.2020

Przełącznik 2,5GbE

QNAP QSW-1105-5T

Konfiguracja BGP na urządzeniach Juniper

Data publikacji: 26-03-2020 Autor: Piotr Wojciechowski

Protokół BGP stanowi podstawę wymiany informacji o podsieciach w internecie, ale także w sieciach operatorów telekomunikacyjnych czy rozległych sieciach korporacyjnych. Niemniej wymiana informacji pomiędzy systemami autonomicznymi rządzi się swoimi prawami.

 

W poprzednim numerze „IT Professional” analizowaliśmy konfigurację podstawowych parametrów pracy protokołu BGP, czyli numeru systemu autonomicznego oraz identyfikatora router-id, a także połączyliśmy ze sobą dwa routery pracujące w obrębie jednego systemu autonomicznego sesją iBGP. Aby zapewnić routing pomiędzy systemami autonomicznymi, np. między siecią a operatorem internetowym, konieczne jest zestawienie sesji eBGP oraz skonfigurowanie polityk sterowania ruchem.


> KONFIGURACJA SESJI eBGP


Sąsiedztwo eBGP (External BGP) dwóch urządzeń zachodzi wtedy, gdy są one skonfigurowane do pracy w różniących się numerami systemach autonomicznych. Wymieniane pomiędzy nimi informacje o prefiksach służą budowaniu połączenia i możliwości przesłania ruchu pomiędzy tymi systemami. Dotyczy to zarówno pakietów nadawanych i odbieranych przez urządzenia znajdujące się w podsieciach przypisanych do każdego z tych autonomicznych systemów, jak i ruchu tranzytowego.


Sąsiedztwo eBGP tworzymy podobnie jak iBGP, musimy jednak stworzyć odrębną grupę typu  external. W konfiguracji iBGP używaliśmy adresów przypisanych do interfejsów typu Loopback jako adresów sąsiednich urządzeń. Rozgłaszaliśmy je następnie w sieci za pomocą protokołu OSPF, aby zapewnić połączenie pomiędzy urządzeniami. W przypadku eBGP taka konfiguracja wymuszałaby konieczność zdefiniowania statycznego rou­tingu do adresu Loopback sąsiada lub uruchomienia dynamicznego protokołu routingu typu IGP pomiędzy systemami autonomicznymi, co w skrajnym przypadku mogłoby doprowadzić do braku komunikacji i niestabilności routingu w obu AS-ach. Dlatego w konfiguracji eBGP co do zasady używamy adresów przypisanych do interfejsów, które łączą nas bezpośrednio z sąsiednim urządzeniem. Przypomnijmy, że w BGP urządzenia do komunikacji wykorzystują protokół TCP. Ze względów bezpieczeństwa w połączeniach eBGP wartość TTL (Time To Live, czyli liczba dozwolonych urządzeń warstwy trzeciej, przez które może przejść pakiet, zanim zostanie doręczony do odbiorcy) jest ustawiona na 1. Oznacza to, że w celu nawiązania ze sobą połączenia urządzenia muszą znajdować się w tej samej podsieci. Możemy to jednak zmienić, dodając w definicji adresu sąsiada parametr  multihop, który spowoduje, że wartość TTL w pakietach będzie ustawiana na 64. Zastosowanie w konfiguracji sąsiedztwa adresów interfejsów ma jeszcze jedną zaletę – dzięki temu w naszej sieci szybciej uzyskamy ponownie stabilną komunikację.


Oprócz adresu IP sąsiada musimy wskazać w konfiguracji jeszcze numer systemu autonomicznego sąsiada. Jeżeli podana wartość nie będzie zgodna ze skonfigurowaną na drugim urządzeniu, sesja nie zostanie nawiązana. Aby na rou­terze R1 poprawnie zestawić sesję eBGP z routerem R3, musimy wprowadzić następującą konfigurację:


set protocols bgp group eBGP type external
set protocols bgp group eBGP neighbor 10.0.13.3 peer-as 65530


Aby sprawdzić poprawność konfiguracji oraz stan, wykorzystujemy polecenie show bgp summary  oraz  show bgp neighbor.

 

> ROZGŁASZANIE PREFIKSÓW


Prefiksami zarządzamy za pomocą odpowiednio skonfigurowanych polityk eksportu i importu. Za pomocą polityk export definiujemy zasady, którym będą podlegały prefiksy, gdy będziemy je eksportować z tablicy routingu do dynamicznego protokołu routingu. Tylko informacje znajdujące się w tablicy routingu mogą być wykorzystywane przez dynamiczne protokoły routingu i rozgłaszane do kolejnych urządzeń. Nieprzestrzeganie tej zasady bardzo szybko doprowadziłoby do braku spójności informacji pomiędzy routerami i pętli w routingu. Moderować możemy nie tylko informacje rozgłaszane przez nasz router, ale i te przez niego odbierane. Wpływamy w ten sposób na decyzję, która trasa zostanie ostatecznie umieszczona w tablic routingu, a co za tym idzie – jak będą przesyłane pakiety z danymi. Opisane czynności nazywamy potocznie inżynierią ruchu (traffic engineering).

 

[...]

 

Autor specjalizuje się w rozwiązaniach routing & switching, data center oraz service providers. Promuje automatyzację w środowiskach sieciowych i udziela się jako deweloper w projektach open source. Pracuje jako niezależny konsultant IT. Posiada certyfikat CCIE.

Pełna treść artykułu jest dostępna w papierowym wydaniu pisma.

.

Transmisje online zapewnia: StreamOnline

All rights reserved © 2019 Presscom / Miesięcznik "IT Professional"