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



20.07.2020

Baramundi

Pomoc w czasie pandemii.
20.07.2020

Stop infekcjom

CloudGuard
17.07.2020

Analiza zagrożeń

Kaspersky Threat Attribution Engine
17.07.2020

Strażnik danych

QGD-1602P
16.07.2020

Dysk przemysłowy

Transcend MTE352T
16.07.2020

Połączenie sił

Fugaku
16.07.2020

Brama bezpieczeństwa

Check Point 1570R
23.06.2020

PLNOG Online

PLNOG Online
23.06.2020

Nowe zagrożenie

Ramsay

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"