Techinka: Konfiguracja systemu Vyatta w ćwiczeniach
Autor: Łukasz Łaciak | Data: 09/06/11
| |
|
8. BGP-4.
Protokół BGP (ang. Border Gateway Protocol) w wersji 4 należy do kategorii protokołów trasowania zewnętrznego (ang. Exterior Gateway Protocol, EGP). Działa w warstwie 4, korzystając z protokołu TCP na porcie 179, a zatem zapewnia niezawodność, dzięki połączeniowemu trybowi pracy. Opisano go w RFC 4271.
BGP dzieli się na dwa standardy: wewnętrzny (ang. internal BGP, iBGP), nawiązujący relacje sąsiedztwa z routerami wewnątrz systemu autonomicznego (AS) oraz zewnętrzny (ang. external BGP, eBGP), który nawiązuje relacje między AS.
iBGP służy do routowania wewnątrz systemu autonomicznego, który jest pewną grupą sieci zarządzaną przez jeden podmiot oraz mającą wspólną politykę trasowania. Gdy w danym AS jest więcej niż jeden router BGP, to jego wewnętrzna forma pomaga przedostać się pakietom przez ten system autonomiczny, a następnie dzięki eBGP jest kierowana do kolejnego AS. Korzystając z iBGP trzeba mieć na uwadze, że każdy z routerów wewnętrznych musi mieć kontakt z każdym innym - jest to forma zapobiegania pętlom routingu.
Jednak mówiąc o BGP, zazwyczaj ma się na myśli eBGP, czyli standard zewnętrzny. Routery eBGP znajdują się na brzegach systemów autonomicznych, a zatem wyznaczają trasę tworząc listę AS po drodze do celu. Zewnętrzny BGP posiada zabezpieczenie przeciw pętlom routingu polegające na odrzucaniu rozgłoszeń w których jest numer systemu autonomicznego w którym on sam się znajduje.
Dla BGP zdefiniowane są następujące atrybuty:
- ORIGIN - opisuje pochodzenie rozgłoszenia; z wewnątrz AS (IGP, wartość 0), z zewnątrz (EGP, wartość 1) lub niepełne, czyli ścieżka pochodzi z redystrybucji (wartość 2).
- AS_PATH - jest to wspomniana wcześniej lista systemów autonomicznych do celu.
- NEXT_HOP - określa adres następnego przeskoku.
- MULTI_EXIT_DISC - informuje o preferowanej trasie w przypaku, gdy istnieje więcej niż jedna trasa do sąsiedniego AS. Przybiera formę czterech oktetów cyfr.
- LOCAL_PREFERENCE - atrybut podobny do powyższego, jednak jest rozgłaszany tylko w sesji iBGP.
- ATOMIC_AGGREGATE - pozwala na rozgłaszanie jednego prefiksu zamiast kilku.
- AGGREGATOR - identyfikator routera, który wykonał agregację.
Algorytm wyboru trasy sprawdza porównuje atrybuty w pewnej kolejności, a gdy znajdzie pierwszą różnicę, to wybiera daną trasę:
- LOCAL_PREFERENCE - preferowana wyższa wartość.
- długość AS_PATH - pożądana krótsza lista systemów autonomicznych.
- ORIGIN - preferowana niższa wartość.
- MULTI_EXIT_DISC - pożądana niższa wartość.
- typ sąsiada - preferowana trasa nauczona przez eBGP, przed iBGP.
- metryka IGP - pożądana ścieżka z niższą wartością.
- identyfikator BGP- preferowana niższa wartość identyfikatora routera.
- adres IP sąsiada - pożądany niższy IP.
Przy komunikacji BGP używa następujących typów wiadomości:
- OPEN - po nawiązaniu połączenia TCP, jest pierwszą wiadomością przesyłaną przez każdą stronę. Zestawia sesję BGP.
- UPDATE - służy rozgłaszania informacji o routingu.
- KEEPALIVE - utrzymuje sesję BGP.
- NOTIFICATION - jest wysyłana po wykryciu błędu. Po przesłaniu tej wiadomości, sesja BGP jest natychmiast zrywana.
Protokół BGP jest podatny na zjawisko zwane route flapping, które jest sytuacją, gdy trasa jest rozgłaszana i odrzucana na przemian bez końca. Wysyłana jest wtedy nadmiarowa ilość rozgłoszeń, co zapycha łącza oraz obciąża procesory routerów. W systemie Vyatta zawarty jest mechanizm flap damping redukujący to zjawisko na zasadzie ograniczania rozgłoszeń, jednak może dość do całkowitego zaniechania ich rozsyłania, a wtedy wymagana jest interwencja administratora.
Do innych wad BGP należy zaliczyć długi czas zbieżności, podatność na sabotaże mogące odciąć od Internetu wiele ludzi oraz duże tablice routingu. Pełna tablica routera podłączonego do Internetu może się ładować nawet kilka godzin. A niedoświadczeni administratorzy mogą nieopatrznie rozsyłać niepotrzebne rozgłoszenia daleko w Internet, narażając swoją sieć na ataki z zewnątrz. Ze względu na dużą ilość danych w tablicy routingu w większych sieciach oraz proces wyboru trasy, routery służące do obsługi ruchu BGP potrzebują dość dużo pamięci RAM i mocnego procesora, a co za tym idzie, są droższe.
Niewątpliwie jednak bez protokołu BGP nie byłoby dzisiejszego Internetu. Protokół ten, co prawda jest dość skomplikowany, ale jest podstawą jego działania, gdyż zapewnia niezawodność oraz nadmiarowość tras prowadzących do celów na całym globie, a żaden inny protokół routingu nie poradziłby sobie z tak wielką i zróżnicowaną siecią.
8.1. Cel oraz założenia.
Celem niniejszego ćwiczenia jest poznanie protokołu BGP w wersji czwartej oraz praca z nim w różnych konfiguracjach.
Użytkownik powinien zapoznać się z teorią przygotowaną do ćwiczenia, a w razie niezrozumienia działania protokołu lub jego części powinien zapoznać się z bibliografią dla tego działu. Niezbędna może okazać się znajomość poprzednich ćwiczeń.
8.2. iBGP - Full Mesh.
Obraz 8-1: Topologia pełnej sieci
Tak jak w poprzednich ćwiczeniach, na obrazie topologii nie ma informacji o połączeniu z Internetem, ale w rzeczywistości będzie ono skonfigurowane. Na kolejnych obrazach w tym ćwiczeniu także jej nie będzie.
8.2.1. Przygotowanie wirtualnych sieci.
Jako, że topologia się zmieniła, zachodzi potrzeba zmian w konfiguracji wirtualnych sieci. Poniżej wypisane są poszczególne interfejsy maszyn oraz przypisane im wirtualne sieci.
R1:
eth0 - NAT (VMnet8)
eth1 - VMnet2
R2:
eth0 - VMnet2
R3:
eth0 - VMnet2
eth1 - VMnet6
R4:
eth0 - VMnet2
Host:
eth0 - VMnet6
8.2.2. Konfiguracja.
Konfiguracja oparta o pełną sieć (ang. full mesh) zapewnia kontakt każdego routera z każdym innym, co jest konieczne w iBGP do uniknięcia pętli routingu. Jest rzadko używana, zazwyczaj w bardzo małych sieciach.
Dobrym rozwiązaniem jest wczytanie konfiguracji zapisanej w ćwiczeniu "5. Routing statyczny" poleceniem 'load'. Jednak dwa interfejsy trzeba przekonfigurować.
R3:
delete interfaces ethernet eth0
set interfaces ethernet eth0 address 10.50.0.3/28
commit
R4:
delete interfaces
set interfaces ethernet eth0 address 10.50.0.4/28
commit
Następnie należy skonfigurować protokół BGP, zgodnie ze składnią:
- 'set protocols bgp < numer AS> neighbor < identyfikator routera> remote-as < numer AS>' - określa numer systemu autonomicznego routera-sąsiada o podanym identyfikatorze w formacie ipv4.
- 'set protocols bgp < numer AS> neighbor < identyfikator routera> update-source < adres IP>' - określa adres IP będący źródłem aktualizacji routingu dla sąsiedniego routera.
- 'set protocols bgp < numer AS> parameter router-id < ipv4>' - określa identyfikator routera w formacie ipv4.
- 'set protocols bgp < numer AS> network < adres sieci>' - definiuje adres rozgłaszaną sieć.
R1:
set protocols bgp 100 neighbor 10.50.0.2 remote-as 100
set protocols bgp 100 neighbor 10.50.0.2 update-source 10.50.0.1
set protocols bgp 100 neighbor 10.50.0.3 remote-as 100
set protocols bgp 100 neighbor 10.50.0.3 update-source 10.50.0.1
set protocols bgp 100 neighbor 10.50.0.4 remote-as 100
set protocols bgp 100 neighbor 10.50.0.4 update-source 10.50.0.1
set protocols bgp 100 parameter router-id 10.50.0.1
commit
R2:
set protocols bgp 100 neighbor 10.50.0.1 remote-as 100
set protocols bgp 100 neighbor 10.50.0.1 update-source 10.50.0.2
set protocols bgp 100 neighbor 10.50.0.3 remote-as 100
set protocols bgp 100 neighbor 10.50.0.3 update-source 10.50.0.2
set protocols bgp 100 neighbor 10.50.0.4 remote-as 100
set protocols bgp 100 neighbor 10.50.0.4 update-source 10.50.0.2
set protocols bgp 100 parameter router-id 10.50.0.2
commit
R3:
set protocols bgp 100 neighbor 10.50.0.1 remote-as 100
set protocols bgp 100 neighbor 10.50.0.1 update-source 10.50.0.3
set protocols bgp 100 neighbor 10.50.0.2 remote-as 100
set protocols bgp 100 neighbor 10.50.0.2 update-source 10.50.0.3
set protocols bgp 100 neighbor 10.50.0.4 remote-as 100
set protocols bgp 100 neighbor 10.50.0.4 update-source 10.50.0.3
set protocols bgp 100 parameter router-id 10.50.0.3
set protocols bgp 100 network 192.168.0.0/24
commit
R4:
set protocols bgp 100 neighbor 10.50.0.1 remote-as 100
set protocols bgp 100 neighbor 10.50.0.1 update-source 10.50.0.4
set protocols bgp 100 neighbor 10.50.0.2 remote-as 100
set protocols bgp 100 neighbor 10.50.0.2 update-source 10.50.0.4
set protocols bgp 100 neighbor 10.50.0.3 remote-as 100
set protocols bgp 100 neighbor 10.50.0.3 update-source 10.50.0.4
set protocols bgp 100 parameter router-id 10.50.0.4
commit
Wpisując polecenie 'show ip bgp summary' w trybie operacyjnym, można zobaczyć krótkie podsumowanie działania BGP zawierające przede wszystkim informacje o sąsiadach [Obraz 8-2].
Obraz 8-2: Podsumowanie BGP
Na obrazie 8-3 ukazane jest wykonanie komendy 'show ip route', wyświetlające tablicę routingu. Protokół BGP informuje, że sieć 192.168.0.0/24 jest osiągalna poprzez adres 10.50.0.3.
Obraz 8-3: Tablica routingu komputera R1
Jak widać konfiguracja internal BGP nie jest trudna, ani skomplikowana. Jednak implementacja tego protokołu routingu jako samodzielnego, mija się z celem, gdyż do takich zadań zostały stworzone protokoły RIP oraz OSPF.
8.3. iBGP - Route Reflector.
Obraz 8-4: Topologia sieci z użyciem propagatora tras
8.3.1. Przygotowanie wirtualnych sieci.
Ponownie zachodzi potrzeba zmian w konfiguracji wirtualnych sieci.
R1:
eth0 - NAT (VMnet8)
eth1 - VMnet2
eth2 - VMnet3
eth3 - VMnet4
R2:
eth0 - VMnet2
R3:
eth0 - VMnet3
eth1 - VMnet6
R4:
eth0 - VMnet4
8.3.2. Konfiguracja.
Konfiguracja sieci z użyciem routera będącego propagatorem tras (ang. route reflector) jest sporo korzystniejsza niż wykorzystanie pełnej sieci (ang. full mesh), ponieważ nie ma potrzeby, aby każdy łączył się z każdym, a wystarczy, że jeden router będzie węzłem, swoistym zwierciadłem, zestawiającym sesje z resztą routerów. W rezultacie zamiast topologii pełnej sieci zostanie otrzymana topologia gwiazdy, co przy większej sieci nie pozostaje bez znaczenia.
Konieczna była ponowna konfiguracja wirtualnych sieci, więc dobrym sposobem na rozpoczęcie pracy będzie wczytanie zapisanego stanu z ćwiczenia "5. Routing statyczny" polecenim 'load'.
R1:
delete interfaces ethernet eth2
set interfaces ethernet eth1 address 10.50.0.1/28
set interfaces ethernet eth2 address 10.50.10.1/28
set interfaces ethernet eth3 address 10.50.20.1/28
commit
Następnie należy przystąpić do konfiguracji protokołu BGP. Dodatkowo na drugiej konsoli komputera R1 można uruchomić program Tshark poleceniem 'tshark -i eth1'.
Składnia użytych poleceń:
- 'set protocols bgp < numer AS> neighbor < identyfikator routera> remote-as route-reflector-client' - przypisuje router o podanym identyfikatorze jako klienta route reflectora, tym samym router lokalny staje się route reflectorem.
R1:
set protocols bgp 100 neighbor 10.50.0.2 remote-as 100
set protocols bgp 100 neighbor 10.50.0.2 route-reflector-client
set protocols bgp 100 neighbor 10.50.0.2 update-source 10.50.0.1
set protocols bgp 100 neighbor 10.50.10.2 remote-as 100
set protocols bgp 100 neighbor 10.50.10.2 route-reflector-client
set protocols bgp 100 neighbor 10.50.10.2 update-source 10.50.10.1
set protocols bgp 100 neighbor 10.50.20.2 remote-as 100
set protocols bgp 100 neighbor 10.50.20.2 route-reflector-client
set protocols bgp 100 neighbor 10.50.20.2 update-source 10.50.20.1
set protocols bgp 100 network 10.50.0.0/28
set protocols bgp 100 network 10.50.10.0/28
set protocols bgp 100 network 10.50.20.0/28
set protocols bgp 100 parameter router-id 10.50.0.1
commit
R2:
set protocols bgp 100 neighbor 10.50.0.1 remote-as 100
set protocols bgp 100 neighbor 10.50.0.1 update-source 10.50.0.2
set protocols bgp 100 network 10.50.0.0/28
set protocols bgp 100 parameters router-id 10.50.0.2
commit
R3:
set protocols bgp 100 neighbor 10.50.0.1 remote-as 100
set protocols bgp 100 neighbor 10.50.0.1 update-source 10.50.10.2
set protocols bgp 100 network 10.50.10.0/28
set protocols bgp 100 network 192.168.0.0/24
set protocols bgp 100 parameters router-id 10.50.10.2
commit
R4:
set protocols bgp 100 neighbor 10.50.0.1 remote-as 100
set protocols bgp 100 neighbor 10.50.0.1 update-source 10.50.20.2
set protocols bgp 100 network 10.50.20.0/28
set protocols bgp 100 parameters router-id 10.50.20.2
commit
Polecenie 'traceroute 192.168.0.2' wykonane z komputera R4 potwierdza poprawność wykonanej konfiguracji - pakiety są przesyłane kolejno przez routery R4->R1->R3->Host [Obraz 8-5].
Obraz 8-5: Wykonanie polecenia traceroute 192.168.0.2'
Wcześniej uruchomiony Tshark może pokazać co się dzieje na łączach - jak przebiega wymiana informacji oraz utrzymanie sesji BGP [Obraz 8-6].
Obraz 8-6: Wymiana informacji przez BGP
Tak samo jak konfiguracja sieci full mesh, konfiguracja z użyciem route reflectora nie jest zbyt skomplikowana. Trzeba tylko poinformować routery, że mają być klientami w stosunku do jednej, nadrzędnej maszyny. Efektem wykorzystania propagatora tras jest spora oszczędność pasma, szczególnie w większych sieciach - routery nie muszą zapinać sesji z każdym innym, wystarczy z jednym.
W powyższym przypadku można było uniknąć rozgłaszania tylu podsieci, tworząc tylko jedną, główną - jak w przypadku konfiguracji pełnej sieci, gdzie nie było sensu tworzyć dwóch dodatkowych sieci na krzyż, gdyż niepotrzebnie skomplikowałoby to obraz topologii. Jednak nie można unikać zmienności i podziału, więc na potrzeby niniejszych ćwiczeń będą stosowane zróżnicowane topologie, dające nieco pracy routerom i użytkownikom.
8.4. eBGP.
Obraz 8-7: Topologia sieci z wykorzystaniem eBGP
8.4.1. Przygotowanie wirtualnych sieci.
R1:
eth0 - NAT (VMnet8)
eth1 - VMnet2
eth2 - VMnet5
R2:
eth0 - VMnet2
eth1 - VMnet3
R3:
eth0 - VMnet3
eth1 - VMnet6
eth2 - VMnet4
R4:
eth0 - VMnet4
eth1 - VMnet5
Host:
eth0 - VMnet6
8.4.2. Konfiguracja.
Ćwiczenie należy rozpocząć od wczytania konfiguracji zapisanej w ćwiczeniu "5. Routing statyczny". Topologia jest taka sama, więc nie trzeba wprowadzać żadnych zmian.
Podstawowa konfiguracja eBGP jest trochę krótsza niż dwie poprzednie iBGP, jednak działanie protokołu jest zgoła odmienne. Routery już nie muszą mieć kontaktu z każdym innym, a działają na podstawie jednostek organizacyjnych zwanych systemami autonomicznymi. Niniejsza konfiguracja jest mała jak to możliwe; służyć ma tylko ukazaniu działania sieci. W Internecie każdy pojedynczy system autonomiczny zawiera w sobie dużą ilość komputerów, jak i routerów oraz jest podzielony na mniejsze podsieci, zarządzane protokołami wewnętrznego routingu.
R1:
set protocols bgp 100 neighbor 10.50.0.2 remote-as 200
set protocols bgp 100 neighbor 10.50.30.1 remote-as 400
set protocols bgp 100 network 10.50.0.0/28
set protocols bgp 100 parameter router-id 10.50.0.1
commit
R2:
set protocols bgp 200 neighbor 10.50.0.1 remote-as 100
set protocols bgp 200 neighbor 10.50.10.2 remote-as 300
set protocols bgp 200 network 10.50.10.0/28
set protocols bgp 200 parameter router-id 10.50.10.1
commit
R3:
set protocols bgp 300 neighbor 10.50.10.1 remote-as 200
set protocols bgp 300 neighbor 10.50.20.2 remote-as 400
set protocols bgp 300 network 10.50.20.0/28
set protocols bgp 300 network 192.168.0.0/24
set protocols bgp 300 parameter router-id 10.50.20.1
commit
R4:
set protocols bgp 400 neighbor 10.50.20.1 remote-as 300
set protocols bgp 400 neighbor 10.50.30.2 remote-as 100
set protocols bgp 400 network 10.50.30.0/28
set protocols bgp 400 parameter router-id 10.50.30.1
commit
Po wyświetleniu tablicy routingu BGP komputera R1 poleceniem 'show ip bgp' (w trybie operacyjnym), pokazanej na obrazie 8-8, można zobaczyć sieci i wyznaczone do nich trasy, reprezentowane przez ciąg systemów autonomicznych, przez które kolejno będą poruszać się pakiety. Te oznaczone znakiem większości (">") są ścieżkami preferowanymi, po których będą poruszać się pakiety.
Obraz 8-8: Tablica routingu BGP komputera R1
8.4.3. Wprowadzenie lokalnych preferencji.
Jak widać na powyższym obrazie, komputer R1 chcąc dostać się do maszyny Host preferuje trasę przez router R4. Administrator może sprawić, aby pakiety opuszczające system autonomiczny były przesyłane inną ścieżką, w tym przypadku przez R2. W tym celu trzeba zmienić atrybut o nazwie LOCAL_PREFERENCE (pol. lokalna preferencja). Jako, że w niniejszej topologii każdy router jest w osobnym systemie autonomicznym, nie ma możliwości eksportowania (rozgłaszania) preferencji lokalnej do sąsiadów, jak ma to miejsce, gdy są w tym samym AS.
Na początek należy skonfigurować politykę routowania dla obu tras.
Składnia użytych poleceń:
- 'set policy route-map < nazwa mapy> rule < numer> action permit' - tworzy regułę w mapie routingu o podanej nazwie z akcją zezwalaj. Określenie akcji jest obowiązkowe.
- 'set policy route-map < nazwa mapy> rule < numer> set local-preference < wartość>' - ustanawia preferencję lokalną o wpisanej wartości.
R1:
set policy route-map LOC-PREF rule 1 action permit
set policy route-map LOC-PREF rule 1 set local-preference 200
set policy route-map LOC-PREF-DOWN rule 1 action permit
set policy route-map LOC-PREF-DOWN rule 1 set local-preference 100
commit
Następnie należy wprowadzić politykę w użytek.
R1:
set protocols bgp 100 neighbor 10.50.0.2 route-map import LOC-PREF
set protocols bgp 100 neighbor 10.50.0.2 route-map import LOC-PREF-DOWN
commit
Na koniec należy zresetować sesje z sąsiadami w celu odświeżenia tablicy routingu. Należy wykonać to poleceniami 'clear ip bgp 10.50.0.2' oraz 'clear ip bgp 10.50.30.1' w trybie operacyjnym.
Tablica routingu routera R1 ukazuje zmiany [Obraz 8-9]. W kolumnie "LocPrf" pojawiły się ustawione preferencje, a trasy oznaczone znakiem większości zmieniły się na inne, ponieważ atrybut LOCAL_PREFERENCE ma pierwszeństwo przed innymi.
Obraz 8-9: Tablica routingu BGP
Polecenie 'traceroute 192.168.0.2' wykonane z komputera R1 potwierdza zmiany, które zaszły. Preferowana ścieżka zmieniła swój bieg i teraz pakiety są przesyłane przez maszynę R2 [Obraz 8-10].
Obraz 8-10: Przebieg trasy R1->Host
Podobny efekt można uzyskać używając atrybutu MULTI_EXIT_DISC, jednak jest on niżej w hierarchii algorytmu wyboru trasy, więc zadziałałby tylko dla tras o takiej same długości AS_PATH, a nie dla wszystkich. Innym kryterium koniecznym do działania MULTI_EXIT_DISC jest ustawienie pochodzenia pakietów na EGP, co można uczynić korzystając z mapy routingu.
8.4.4. Filtrowanie rozgłoszeń.
Protokół BGP pozwala na filtrowanie rozgłoszeń pochodzących z innych routerów lub wysyłanych do innych routerów. Są sytuacje, gdy niektóre trasy nie są pożądane do przesyłania pewnych pakietów, zaś inne ścieżki są dedykowane tylko dla określonego ruchu. Za przykład można podać taki oto scenariusz: dwie firmy życzą sobie wymieniać informacje między sobą, lecz nie za pomocą internetu, ponieważ koszt łącza dzierżawionego od dostawcy jest wysoki. Firmy te decydują się utworzyć połączenie pomiędzy sieciami, przez które będzie kierowany cały ruch między nimi. O taki stan rzeczy może zadbać BGP, rozgłaszając prefiksy każdej z tych sieci.
Topologia powyższego przykładu została przedstawiona na obrazie 8-11. Poniżej znajduje się konfiguracja.
Obraz 8-11: Topologia dwóch połączonych sieci
Aby nie trudzić się z usuwaniem zbędnych elementów konfiguracji, poleceniem 'load' wystarczy ponownie załadować zapisaną wcześniej konfigurację. Usunięte zostaną interfejsy eth1 routera R1 oraz eth0 komputera R2, a także bramy domyślne wszystkich komputerów, prócz maszyny Host, ze względu na problemy w obserwacji, które mogą sprawiać.
R1:
delete interfaces ethernet eth1
delete system gateway-address
set protocols bgp 100 neighbor 10.50.30.1 remote-as 100
set protocols bgp 100 neighbor 10.50.30.1 update-source 10.50.30.2
set protocols bgp 100 parameter router-id 10.50.0.1
commit
R2:
delete interfeces ethernet eth0
delete system gateway-address
set protocols bgp 200 neighbor 10.50.10.2 remote-as 200
set protocols bgp 200 neighbor 10.50.10.2 update-source 10.50.10.1
set protocols bgp 200 parameter router-id 10.50.10.1
commit
R3:
delete system gateway-address
set protocols bgp 200 neighbor 10.50.10.1 remote-as 200
set protocols bgp 200 neighbor 10.50.10.1 update-source 10.50.10.2
set protocols bgp 200 neighbor 10.50.20.2 remote-as 100
set protocols bgp 200 network 10.50.10.0/28
set protocols bgp 200 network 192.168.0.0/24
set protocols bgp 200 parameter router-id 10.50.20.1
commit
R4:
delete system gateway-address
set protocols bgp 100 neighbor 10.50.20.1 remote-as 200
set protocols bgp 100 neighbor 10.50.30.2 remote-as 100
set protocols bgp 100 neighbor 10.50.30.2 update-source 10.50.30.1
set protocols bgp 100 network 10.50.30.0/28
set protocols bgp 100 parameter router-id 10.50.30.1
commit
Jednak po wpisaniu powyższych linii nie wszystkie sieci będą osiągalne. Maszyna R1 nie będzie mogła pingować sieci 10.50.10.2/28 oraz 192.168.0.0./24, a router R2 nie będzie mógł pingować sieci 10.50.30.0/28. Wszystkiemu winne są wpisy z tablicy routingu informujące o następnym skoku do adresu IP niedostępnego bezpośrednio - komputery po prostu nie posiadają wiedzy, którym kolejnym węzłem sieci mają wysyłać pakiety i przez to są wysyłane na adres bramy domyślnej.
Na obrazie 8-12 pokazana jest tablica routingu komputera R1 z takimi właśnie wpisami, kierującymi na adres IP 10.50.20.1.
Obraz 8-12: Tablica routingu BGP z niepożądanymi wpisami
Aby zapobiec powyższej sytuacji, trzeba poinformować komputery, które węzły mają umieścić w tablicach routingu.
R3:
set protocols bgp 200 neighbor 10.50.10.1 nexthop-self
commit
R4:
set protocols bgp 200 neighbor 10.50.30.2 nexthop-self
commit
Na koniec, w trybie operacyjnym na komputerze R4, poleceniem 'clear ip bgp 10.50.20.1', należy zresetować sesję z sąsiadem.
Powyższe polecenia informują komputery R3 oraz R4, aby w wysyłanych aktualizacjach routingu do komputerów określonych po słowie 'neighbor' (pol. sąsiad) jako adres następnego przeskoku wpisały same siebie. Po odebraniu aktualizacji router R2 (10.50.30.2) dodaje wpis o następnym skoku z adresem 10.50.10.2, a R1 dodaje wpis z adresem 10.50.30.1 [Obraz 8-13].
Obraz 8-13: Tablica routingu BGP komputera R1 z poprawionymi wpisami
W rezultacie sieci wcześniej nieosiągalne stały się dostępne, a sieć odwzorowuje topologię z obrazu 8-11.
Teraz można przejść do filtrowania rozgłoszeń. Cel jest następujący: tylko sieć 192.168.0.0/24 z AS 200 powinna być rozgłaszana do systemu autonomicznego numer 100. Stan taki można osiągnąć wprowadzając do konfiguracji komputera R3 mapy routingu dla rozgłoszeń wychodzących lub analogicznie mapy dla rozgłoszeń przychodzących do konfiguracji routera R4. Poniższy przykład pokaże pierwszą z opcji.
Składnia użytych poleceń:
- 'set policy prefix-list < nazwa listy> rule < numer> action permit' - tworzy regułę w liście prefiksów o podanej nazwie z akcją zezwalaj. Określenie akcji jest obowiązkowe.
- 'set policy prefix-list < nazwa listy> rule < numer> prefix < adres sieci>' - do danej reguły przypisuje podany adres sieci.
- 'set policy route-map < nazwa mapy> rule < numer> action permit' - tworzy regułę dla podanej mapy z akcją zezwalaj. Określenie akcji jest obowiązkowe.
- 'set policy route-map < nazwa mapy> rule < numer> action deny' - tworzy regułę dla podanej mapy z akcją odrzuć.
- 'set policy route-map < nazwa mapy> rule < numer> match ip address prefix-list < nazwa listy prefiksów>' - przypasowuje adresy sieci z listy prefiksów o wpisanej nazwie.
- 'set protocols bgp < numer AS> neighbor < identyfikator routera> route-map export < nazwa mapy>' - włącza do działania stworzoną wcześniej mapę routingu sąsiada o podanym identyfikatorze. Słowo 'export' oznacza rozgłoszenia wychodzące.
R3:
set policy prefix-list PREFIXES rule 1 action permit
set policy prefix-list PREFIXES rule 1 prefix 192.168.0.0/24
set policy route-map MAP rule 1 action permit
set policy route-map MAP rule 1 match ip address prefix-list PREFIXES
set policy route-map MAP rule 2 action deny
set protocols bgp 200 neighbor 10.50.20.2 route-map export MAP
commit
Trzeba pamiętać o zresetowaniu sesji z sąsiadem (w trybie operacyjnym), poleceniem 'clear ip bgp 10.50.20.2' na routerze R3.
Finalnie rozgłoszenia o sieci 10.50.10.0/28 nie powinny być wysyłane do routera R4, a co za tym idzie, żaden komputer z AS 100, nie będzie miał dostępu do tej sieci (nie będą o niej wiedzieć), jak i żaden komputer z sieci 10.50.10.0/28 nie będzie potrafił osiągnąć maszyn z systemu autonomicznego nr 100 (będzie do nich wysyłał pakiety, ale komputery z AS 100 nie będą wiedziały gdzie odpowiedzieć).
Na obrazie 8-14 pokazana jest tablica routingu komputera R1 po operacji filtrowania rozgłoszeń. Natomiast obraz 8-15 przedstawiona jest próba wyznaczenia trasy z maszyny R2 do R1.
Obraz 8-14: Tablica routingu BGP komputera R1
Obraz 8-15: Próba wyznaczenia trasy Host->R1
Rozgłoszenia można także blokować na podstawie numeru systemu autonomicznego. W stosunku do powyższego przykładu zmian będzie niewiele, a dla odmiany blokowane będą rozgłoszenia przychodzące.
Składnia użytych poleceń:
- 'delete protocols bgp < numer AS> neighbor < identyfikator routera> route-map' - wyłącza mapę routingu.
- 'delete policy' - usuwa politykę routingu.
- 'set policy as-path-list < nazwa listy> rule < numer> action permit' - tworzy regułę dla podanej listy numerów systemów autonomicznych z akcją zezwalaj. Określenie akcji jest obowiązkowe.
- 'set policy as-path-list < nazwa listy> rule < numer> regex < wartość>' - dopisuje podanej listy numer AS.
- 'set policy route-map < nazwa mapy> rule < numer> match match as-path < nazwa listy>' - przypasowuje numery AS z listy o podanej nazwie.
R3:
delete protocols bgp 200 neighbor 10.50.20.2 route-map
delete policy
commit
R4:
set policy as-path-list LIST rule 1 action permit
set policy as-path-list LIST rule 1 regex 200
set policy route-map MAP rule 1 action deny
set policy route-map MAP rule 1 match as-path LIST
set policy route-map MAP rule 2 action permit
set protocols bgp 100 neighbor 10.50.20.1 route-map import MAP
commit
Na komputerze R4 należy zresetować sesję poleceniem 'clear ip bgp 10.50.20.1'.
Z komputerów w AS 100 zostały usunięte wpisy o sieciach 10.50.10.0/28 oraz 192.168.0.0/24, gdyż pasują one do wzoru z listy systemów autonomicznych przeznaczonych do odrzucenia. W AS 200 wpisy z adresem sieci 10.50.30.0/28 znajdują się nadal, jednak może być problem z kontaktem. Jak pokazano na obrazie 8-16, pakiety z komputera R2 dochodzą do R1, ale router R1 nie odpowiada na nie, gdyż pochodzą one z sieci w AS 200, a on nie zna trasy do niej.
Obraz 8-16: Żądanie echa wysyłane z komputera R2 do R1
Filtrowanie rozgłoszeń umożliwia odpowiednie zarządzanie ruchem między systemami autonomicznymi. Przytaczając raz jeszcze przykład dwóch firm, można oczekiwać, że część przynajmniej jednej z firmowych sieci nie powinna być dostępna dla drugiej ze względu na poufność, co zostało osiągnięte.
Protokół BGP pozwala na prostą, jak i bardzo skomplikowaną administrację sieciami, a przez swoje możliwości stał się trzonem dzisiejszego Internetu, choć z powodu swojej złożoności jest protokołem dość trudnym i, niejednokrotnie, powodującym problemy na skalę międzynarodową.
|
poprzednia strona (7. RIPv2.) 
