OSPF na urządzeniach Juniper

Konfiguracja protokołu OSPF w podstawowym zakresie jest stosunkowo prosta, niezależnie od tego, z urządzeń którego producenta korzystamy. Na urządzeniach Cisco czy Juniper konfigurację najczęściej wykonujemy z poziomu wiersza poleceń. Wystarczy wydać kilka komend, aby protokół zaczął działać.

OSPF jest protokołem otwartym i niezależnym od żadnego producenta. Dostępny jest praktycznie na każdym średnio zaawansowanym urządzeniu sieciowym, coraz częściej możemy go też spotkać nawet na urządzeniach segmentu SOHO. Jego popularności sprzyja łatwość obsługi. Administrator powinien jednak nie tylko polegać na znajomości komend, ale także przyswoić sobie terminologię związaną z tym protokołem oraz rozumieć podstawy jego działania. Przyjrzyjmy się podstawowej konfiguracji protokołu OSPF w niewielkiej sieci zbudowanej z wykorzystaniem urządzeń Juniper.

W przypadku konfiguracji OSPF w działającej sieci należy pamiętać, że wpłynie ona na działanie innych urządzeń i może spowodować problemy z komunikacją w jej obrębie. Dlatego zawsze należy testować i uczyć się, korzystając z wydzielonego do tego celu środowiska.

 Identyfikator routera

Przed przystąpieniem do konfiguracji jakiegokolwiek dynamicznego protokołu routingu należy zadbać o to, aby każdy z routerów w sieci miał niezmienny i cały czas aktywny identyfikator. Jest to niezbędne, aby każdy z protokołów działał poprawnie. Przesyłając między sobą wiadomości kontrolne oraz informacje o podsieciach, routery budują z użyciem identyfikatora bazę topologii. Najlepszym takim identyfikatorem dostępnym na każdym urządzeniu sieciowym jest adres IP. Urządzenia sieciowe mają jednak wiele interfejsów, spośród których wybrany musi zostać jeden. Jest jeszcze inny problem:

jeżeli interfejs, którego adres zostanie wybrany zmieni swój status na nieaktywny, to identyfikator nie będzie mógł dalej być wykorzystywany.

Taka sytuacja może nastąpić, gdy administrator ręcznie zmieni stan portu lub gdy port czy też karta rozszerzeń, na której znajduje się dany interfejs ulegnie awarii. Powód może być też znacznie bardziej prozaiczny, jak np. uszkodzenie lub wypięcie kabla. Adres IP przypisany do nieaktywnego interfejsu nie będzie mógł służyć jako identyfikator, co sprawi, że router będzie musiał dokonać ponownego wyboru adresu IP, który uzna za identyfikator.

O ile z punktu widzenia samego routera zmiana wydaje się niewielka, to z perspektywy całej sieci może mieć poważne konsekwencje.

Pozostałe routery odczytają ją w taki sposób, jakby jeden router został odłączony od sieci, a w jego miejsce podłączono zupełnie nowe urządzenie. Oznacza to konieczność ponownego rozgłoszenia informacji o podsieciach i zaktualizowania tablic routingu na każdym z pozostałych routerów.

Spowoduje to problemy z przesyłaniem ruchu z i do podsieci podpiętych do danego routera, przez pewien czas może też spowodować nieoptymalne trasowanie w całej sieci.

Przeczytaj także:

https://evoila.com/blog/moja-mala-szkocka-serwerownia/

Wybór adresu IP na identyfikator %%Router-ID%% przez urządzenie sieciowe nie jest przypadkowy.

Proces ten jest ściśle określony, administrator może więc wpływać na to, który adres zostanie wybrany. Pierwszeństwo ma zawsze wartość router-id statycznie deklarowana przez administratora za pomocą polecenia << set routing-options router-id >>.

Jeżeli taka konfiguracja nie zostanie wprowadzona, urządzenie sprawdzi, czy został skonfigurowany co najmniej jeden interfejs typu %%Loopback%%.

Jest to specjalny, wewnętrzny typ interfejsu, do którego możemy przypisać adres IP. Jego cechą charakterystyczną jest to, że niezależnie od stanu innych interfejsów jest on zawsze aktywny. Jedynie administrator może go deaktywować ręcznie. Spośród skonfigurowanych na urządzeniu interfejsów typu Loopback urządzenie jako identyfikator router-id wybierze adres o najniższej wartości numerycznej.

Oznacza to, że porówna ona ze sobą adresy IP w taki sposób, jakby były to zwykłe liczby.

W takim porównaniu adres 172.16.16.10 będzie mniejszy niż 192.168.10.10. Jeżeli na urządzeniu nie skonfigurowano żadnego interfejsu typu Loopback, router porówna w ten sam sposób adresy IP przypisane do fizycznych interfejsów urządzenia i spośród nich wybierze ten o najniższej wartości.

Jeżeli konfiguracja naszego routera nie wymaga skonfigurowania wielu interfejsów typu Loopback, to powinniśmy dążyć do tego, aby identyfikatorem został adres przypisany do jedynego interfejsu tego typu. Zazwyczaj będzie to adres z maską /32. Sam interfejs Loopback należy też ująć w konfiguracji protokołu routingu, tak aby przypisany do niego adres był odpowiednio rozgłaszany w sieci. Na routerze R1 konfigurację interfejsu Loopback wprowadzamy poleceniem:

<< set interfaces lo0 unit 1 family inet address 10.255.0.1/32 >>

Topologia

Nasza przykładowa sieć składa się z czterech routerów. Złączone one są ze sobą w topologii niepełnego kwadratu, w którym brakuje połączenia pomiędzy R3 i R4. Połączenia pomiędzy urządzeniami realizowane są w standardzie GigabitEthernet z wykorzystaniem VLAN-ów, dlatego adresy IP są przydzielone na subinterfejsach. Do połączeń między urządzeniami wykorzystywane są podsieci z maską /24, a numer na ostatnim oktecie jest równy numerowi urządzenia. Dodatkowo na każdym z routerów skonfigurowany jest interfejs typu Loopback o adresie 10.255.0.x/32, gdzie w miejsce „x” umieszczono liczbę odpowiadającą numerowi identyfikacyjnemu routera. Z punktu widzenia protokołu OSPF routery R1 i R2 znajdują się w obszarze 0 (Backbone Area). Router R3 znajduje się w obszarze o identyfikatorze 1, zaś R4 w obszarze o numerze 2, który jest skonfigurowany jako obszar typu Stub.

Uruchamiamy OSPF

Budowa i działanie protokołu OSPF opiera się na koncepcji obszarów. Tworzą go połączone ze sobą routery, których interfejsy są przypisane do danego obszaru. Taki podział sieci ma na celu optymalizację działania protokołu OSPF. Routery w danym obszarze muszą mieć dostęp do informacji o wszystkich urządzeniach w nim pracujących, jak i o podsieciach, które są do nich przypisane. Oznacza to, że każda zmiana w topologii sieci powoduje wysłanie przez router specjalnego komunikatu %%LSA%% (Link State Advertisement), który zawiera informację o wykrytej zmianie.

Rozsyłana jest ona do wszystkich routerów sąsiadujących z urządzeniem, które taką zmianę wykryło.

Odebranie komunikatu LSA skutkuje ponownym przeliczeniem informacji o danej podsieci oraz przesłaniem tej informacji dalej. Jeżeli więc w danym obszarze router zacznie rozgłaszać nową podsieć, to informacja ta za pośrednictwem komunikatów LSA zostanie rozpropagowana pomiędzy pozostałe urządzenia w danym obszarze, a każde z nich będzie musiało uaktualnić informacje posiadane o sieci.

Typy LSA

Każdy z routerów niezależnie zbiera informacje o innych routerach pracujących w sieci, połączeniach pomiędzy nimi oraz rozgłaszanych podsieciach. Informacje te przenoszone są za pomocą komunikatów LSA (Link State Advertisement). Typ LSA jak i przenoszona przez niego informacja uzależniona jest od tego jaki router ją wygenerował. Za pomocą polecenia << show ospf database >> wyświetlimy informację o przetworzonych przez router komunikatach LSA i ich typach.

Typ LSA	Nazwa	Opis
LSA 1	Router	Generowane przez każdy z routerów w danym obszarze, zawiera listę lokalnych interfejsów routera należących do danego obszaru.
LSA 2	Network	Generowany w sieciach, gdzie następuje elekcja DR/BDR. Zawiera informację o sieci typu multiaccess (np. Ethernet), do której podłączone są routery.
LSA 3	Net Summary	Generowany przez ABR. Zawiera informacje zebrane z LSA 1 i 2 z jednego obszaru przed wysłaniem ich do innego obszaru dołączając ich metrykę, ale bez informacji o topologii obszaru.
LSA 4	ASBR Summary	Zawiera informacje o routerze ASBR działającym w sieci oraz koszcie ścieżki do niego. Niezbędne dla routerów do wyznaczenia ścieżki do tras pochodzących z redystrybucji rozgłaszanych w LSA 5 i 7.
LSA 5	External LSA	Zawiera informacje o podsieci pochodzącej z redystrybucji z innego protokołu routingu na routerze ASBR.
LSA 7	AS External LSA	Podobne do LSA 5, generowane jednak w specjalnym obszarze typu NSSA.

Podział na obszary pozwala administratorom zmniejszyć zasięg propagacji tak szczegółowych informacji, a także daje możliwość wprowadzenia agregacji tras techniką sumaryzacji.

Zatrzymajmy się na chwilę, by przybliżyć TYPY OBSZARÓW:

• %%Backbone Area%% – obszar o numerze 0, odpowiada za dystrybucję informacji pomiędzy obszarami, dlatego każdy inny obszar musi być przyłączony bezpośrednio do niego. Wszystkie informacje o urządzeniach i podsieciach rozgłaszane są jak w każdym innym obszarze. Urządzenie, które ma co najmniej jeden interfejs w obszarze 0 nazywamy %%Backbone Router%%. Jeżeli konfigurujesz sieć OSPF z pojedynczym obszarem, to powinien on mieć numer 0.
• %%Non-Backbone Area%% – obszar, który oznaczony jest innym identyfikatorem niż 0. Musi on być połączony z obszarem 0. Router łączący ze sobą obszary typu Backbone oraz Non-Backbone nosi nazwę %%Area Border Router (ABR)%%, natomiast urządzenie, które ma wszystkie interfejsy przypisane tylko do jednego obszaru nazywamy %%Internal Router%%.
• %%Stub Area%% – obszar, do którego nie są rozgłaszane trasy zewnętrzne, czyli takie, które pochodzą z redystrybucji. Rozgłaszane są do niego przez routery ABR jedynie informacje o sieciach pochodzących z innych obszarów domeny OSPF oraz trasa domyślna 0.0.0.0/0 do routera ABR. Pozwala to zmniejszyć liczbę aktualizacji przesyłanych w wiadomościach LSA oraz historycznie pozwalało zoptymalizować zużycie pamięci i procesora na urządzeniach sieciowych zapewniając jednocześnie pełną komunikację z dowolną podsiecią w ramach domeny OSPF (z dowolnego obszaru) jak i tych pochodzących z redystrybucji.
• %%Totally Stubby Area%% – działa podobnie do obszaru typu Stub, z tą różnicą, że nie są do niego rozgłaszane dodatkowo informacje o podsieciach pochodzących z innych obszarów OSPF. Oznacza to, że routery w tym obszarze mają wiedzę jedynie o prefiksach rozgłaszanych przez urządzenia pracujące w tym obszarze oraz domyślną trasę generowaną przez router ABR.
• %%Not-So-Stubby Area (NSSA)%% – usuwa ograniczenie obszarów typu Stub oraz Totally Stubby polegające na tym, że nie można w nich rozgłaszać tras zewnętrznych, czyli korzystać z redystrybucji. Obszar typu NSSA jest obszarem działającym tak jak Stub, z tą różnicą, że dozwolona jest w nim redystrybucja tras zewnętrznych na routerze ASBR (Autonomous System Boundary Router). Zewnętrzne trasy są rozgłaszane z obszaru NSSA to obszaru Backbone.

Obszary identyfikowane są za pomocą numerów. Szczególny obszar nosi identyfikator 0 i nazywany jest %%Backbone Area%%. Wszystkie inne obszary muszą być połączone z obszarem 0, inaczej informacja o podsieciach nie będzie prawidłowo propagowana. Routery, które łączą dwa obszary noszą nazwę %%ABR%% (Area Border Router). Do obszaru przypisujemy zatem nie tyle samo urządzenie, co jego interfejsy. W naszej sieci rolę routerów ABR pełnią urządzenia R1 i R2.

Konfiguracja routera R1 wyglądać będzie następująco.

<< 
set protocols ospf area 0.0.0.0 interface ge-0/0/1.102
set protocols ospf area 0.0.0.0 interface lo0.1
set protocols ospf area 0.0.0.1 interface ge-0/0/0.103
>> 

Analogiczną konfigurację wprowadzimy na routerze R2.

<< 
set protocols ospf area 0.0.0.0 interface ge-0/0/1.102
set protocols ospf area 0.0.0.0 interface lo0.1
set protocols ospf area 0.0.0.2 interface ge-0/0/0.103
set protocols ospf area 0.0.0.2 stub
>> 

Identyfikator obszaru można podać w formacie liczby decymalnej – system Junos zamieni go na notację rozdzieloną kropkami. Aby relacja sąsiedztwa OSPF mogła zostać nawiązana na routerze R3, musimy wprowadzić następującą konfigurację:

<< 
set protocols ospf area 0.0.0.1 interface ge-0/0/0.103
set protocols ospf area 0.0.0.1 interface lo0.1
>> 

Do danego obszaru, oprócz interfejsów, za pośrednictwem których złączone są ze sobą urządzenia, dodajemy także interfejs Loopback, tak aby identyfikator router-id także znalazł się w tablicy routingu. Typ obszaru o numerze 2 należy ustawić na %%Stub%% – odpowiedni parametr dodajemy w definicji obszaru. Na routerze R4 OSPF skonfigurujemy za pomocą następujących poleceń.

<< 
set protocols ospf area 0.0.0.2 stub
set protocols ospf area 0.0.0.2 interface ge-0/0/0.204
set protocols ospf area 0.0.0.2 interface lo0.1
>> 

Gdybyśmy chcieli skonfigurować obszar typu %%Totally Stubby%%, musimy w konfiguracji jako parametr obszaru dodać

<< stub no-summary >>

Jeżeli zaś konfigurowalibyśmy obszar typu %%Not-So-Stubby%%, należy użyć parametru

<< nssa >>

LSA i obszary

Nie każdy typ wiadomości LSA znajdziemy w każdym z obszarów. Niektóre z typów komunikatów LSA znajdziemy jedynie w specjalizowanych obszarach

	LSA 1	LSA 2	LSA 3	LSA 4	LSA 5	LSA 7
Backbone Area	Tak	Tak	Tak	Tak	Tak	Nie
Non-Backbone Area	Tak	Tak	Tak	Tak	Tak	Nie
Stub Area	Tak	Tak	Tak	Nie	Nie	Nie
Totally Stubby Area	Tak	Tak	Nie	Nie	Nie	Nie
Not-So-Stubby Area	Tak	Tak	Tak	Nie	Nie	Tak

Weryfikacja działania

Pierwszym krokiem w przypadku weryfikacji poprawności działania, jak i rozwiązywaniu problemów powinno być sprawdzenie, czy wszystkie relacje sąsiedztwa są poprawnie nawiązane przez urządzenia. Wykorzystamy do tego polecenie

<< show ospf neighbors >>

Jego wynik na routerze R1 w naszej przykładowej sieci jest następujący.

<< 
root@R1 > show ospf neighbor
Address          Interface              State     ID               Pri  Dead
10.0.12.2        ge-0/0/1.102           Full      10.255.0.2       128    31
10.0.13.3        ge-0/0/0.103           Full      10.255.0.3       128    35
>> 

• W kolumnie <<Address>> znajduje się adres IP, z którym nawiązane zostało połączenie, zaś w kolumnie <<ID>> identyfikator Router-ID sąsiada.
• W kolumnie <<Interface>> znajdziemy informację o interfejsie, za pomocą którego nawiązane zostało połączenie.
• Najważniejsza informacja znajduje się w kolumnie <<State>> i oznacza status nawiązanego sąsiedztwa.
• Oczekiwana wartość to <<Full>> – informuje ona, że połączenie jest nawiązane i bierze udział w budowaniu przez protokół OSPF topologii sieci i tablicy routingu.
• Każdy inny stan świadczy o problemach z połączeniem lub o trwającym procesie negocjacji na łączach współdzielonych, np. sieci typu Ethernet. Wydając polecenie

<< show ospf neighbor detail >>

wyświetlimy dodatkowo informację o tym, do którego obszaru dany interfejs jest przypisany. Dowiemy się też ile czasu upłynęło od poprawnego nawiązania sąsiedztwa.

• Informację o interfejsach skonfigurowanych w protokole OSPF wyświetlić można też poleceniami:

<< show ospf interface >>

oraz

<< show ospf interface detail >>.

• Warto też sprawdzić wynik polecenia << show ospf statistics >>. Dzięki niemu uzyskać można statystyki działania procesu obsługującego protokół OSPF, w tym przykładowo liczbę wysłanych i odebranych komunikatów %%Hello%%, które służą do nawiązywania i utrzymywania sąsiedztwa pomiędzy urządzeniami.

Sumaryzacja na brzegu obszaru

Jedną z zalet protokołu OSPF jest możliwość dokonywania sumaryzacji tras, czyli zastąpienia wielu tras szczegółowych jedną trasą o krótszej masce podsieci. Na przykład sieci 192.168.0.0/24 i 192.168.1.0/24 można wspólnie zagregować do podsieci 192.168.0.0/23. W OSPF sumaryzacja dokonywana jest na brzegu obszarów, czyli na routerach ABR. Routery wewnątrz danego obszaru zawsze będą miały pełną szczegółową wiedzę o wszystkich podsieciach, które znajdują się w danym obszarze.

Jeżeli skonfigurujemy sumaryzację na routerze wewnątrz strefy, to po prostu nie będzie ona widoczna.  

Konfigurację sumaryzacji dodajemy na poziomie definicji całego obszaru. W naszej sieci chcemy dokonać sumaryzacji adresów interfejsów Loopback routerów należących do obszaru z identyfikatorem 2, czyli 10.255.0.2/32 na routerze R2 oraz 10.255.0.4/32 na routerze R4. Zamiast tych adresów chcemy w tablicy routingu umieścić podsieć 10.255.0.0/24. Konfiguracji dokonujemy na routerze R2, gdyż pełni on rolę ABR pomiędzy strefami. Dodamy też drugą definicję sumaryzacji.

<< 
set protocols ospf area 0.0.0.2 area-range 10.255.0.0/24
set protocols ospf area 0.0.0.2 area-range 10.100.0.0/24
>> 

Zmiany obserwować będziemy na routerze R3 umieszczonym w obszarze z identyfikatorem 1. Przed włączeniem sumaryzacji router ten miał w tablicy routingu szczegółowe informacje o prefiksach przypisanych do urządzeń R2 i R4. Po aktywacji wprowadzonej konfiguracji z tablicy routingu zniknie trasa 10.255.0.4/32, pojawi się natomiast 10.255.0.0/24. Jest to działanie zgodne z oczekiwaniami – prefiks o dłuższej masce został zastąpiony przez trasę po agregacji.

Dlaczego jednak pozostał prefiks 10.255.0.2/32 z routera R2? Odpowiedź jest prosta – interfejs Loopback w naszej konfiguracji został przypisany do obszaru Backbone, zatem agregacja tras go nie dotyczyła. Gdybyśmy przypisali go do strefy z identyfikatorem 2, to także on zniknąłby z tablicy routingu.

W tablicy routingu na routerze R3 nie pojawiła się jednak druga trasa, którą skonfigurowaliśmy w definicji sumaryzacji, czyli 10.100.0.0/24. Takie działanie jest także zgodne z oczekiwaniem. Ponieważ w tablicy routingu routera R2 w strefie z identyfikatorem 2 nie było żadnej bardziej szczegółowej trasy zawierającej się w podsieci 10.100.0.0/24, rozgłoszenie trasy zagregowanej mijałoby się z celem. Co więcej, mogłoby prowadzić do problemów z routingiem w całej sieci.

Zawsze w tablicy routingu musi być co najmniej jedna bardziej szczegółowa trasa, aby router rozgłaszał trasę zagregowaną.

Firewall domyślnie blokuje OSPF

Należy pamiętać, że protokoły routingu wysyłają własne komunikaty. Większość urządzeń domyślnie ma włączoną zaporę sieciową i będzie te komunikaty odrzucać – więcej na ten temat można przeczytać w poprzednim numerze „IT Professional” na s. 44. Aby router akceptował kierowane do niego pakiety OSPF, konieczne jest dodanie wyjątku dla tego protokołu w strefach bezpieczeństwa, w których znajdują się interfejsy wykorzystywane do nawiązywania sąsiedztwa z innymi urządzeniami. Można tego dokonać poleceniem << set security zone security-zone DMZ host-inbound-traffic protocol ospf >>, zmieniając „DMZ” na właściwą w Twojej konfiguracji nazwę strefy.

Artykuł został opublikowany na łamach IT Professional.

Więcej tekstów z IT Professional