Główne cechy protokołu OSPF to:

• • jest protokołem bezklasowym czyli nie działa w oparciu o klasy, tym samym przesyłając w swoich aktualizacjach informacje o masce podsieci a idąc dalej typ tropem posiada wsparcie dla mechanizmów VLSM oraz CIDR,
  • jest protokołem stanu łącza, fakt ten wpływa na sposób wyznaczenia trasy do sieci zdalnej (opis w dalszej części artykułu),
  • w celu zwiększenia skalowalności wykorzystuje tzw. obszary (ang. area) czyli jest możliwość podziału routingu na wiele niezależnych od siebie obszarów, oznacza to że część routerów może ograniczać swoje aktualizacje do jednego konkretnego miejsca a inne zaś mogą obsługiwać routing pomiędzy zdefiniowanymi obszarami.

Sposób działania protokołu OSPF opiera się ma algorytmie Dijkstry (częściej nazywa się go po prostu SPF – ang. Shortest Path First) a jego głównym zadaniem jest znalezienie jak najkrótszej drogi od źródła do celu. Aby lepiej to zobrazować przyjrzyjmy się poniższej topologii, na rysunku dodatkowo został zaznaczony koszt każdej ścieżki (topologię tą na razie użyjemy do zrozumienia działania algorytmu SPF by ją nieznacznie zmienić przy tłumaczeniu już samej konfiguracji protokołu OSPF).

Całkowity najmniejszy koszt dotarcia z routera R0 do komputera PC2 wynosi 14 (2+10+2) Koszt ten router R0 wylicza z swojej perspektywy a koszt ten nie jest kosztem, który będzie obowiązywać dla każdego innego routera. Przy protokole OSPF, każdy router wybierze ścieżkę, która będzie najlepsza z jego punktu widzenia a co jest również ważne droga z najlepszą wartością ścieżki wcale nie musi przebiegać przez najmniejszą liczbę routerów.

Przyjrzyjmy się sytuacji w której router R0 próbuje wysłać pakiety do sieci 10.0.0.0/24 (za routerem R2), na pierwszy rzut oka domniemywać można, że pakiety będą podróżować od routera R0 do routera R1 by następnie zostać przekazane do routera R2, który to przekaże pakiety do sieci docelowej (koszt 24). Lecz gdy przyjrzymy się topologii bliżej to okaże się że ścieżka dotarcia do sieci 10.0.0.0/24 będzie inna i prowadzić będzie przez router R3 (koszt 19). Tak więc każdy router oblicza metrykę czyli koszt dotarcia do każdej z sieci zdalnych a następnie te trasy, które są najlepsze z jego punktu widzenia umieszcza w swojej tablicy routingu. W implementacjach Cisco koszt jest obliczany na podstawie szerokości pasma.

Ale jak to się dzieje, że router jest w stanie dowiedzieć się o sieciach zdalnych, obliczyć do tych sieci metrykę i w konsekwencji prowadzić poprawną komunikację z daną siecią zdalną? A więc po kolei.

Pierwszym krokiem jest oczywiście poprawne przypisanie wszystkim interfejsom poprawnych adresów IP i masek. Włączenie interfejsu powoduje, że router dowiaduje się o sieciach z którymi jest połączony bezpośrednio. Informacje te wraz z typem sieci (ethernet, punkt-punkt), kosztem łącza oraz informacją o wszystkich sąsiadach nazywane są stanami łącza (ang. link states).

Drugim krokiem jest rozesłanie pakietów hello. Po uruchomieniu protokołu OSPF, wszystkie routery celem skomunikowania się ze sobą i ustanowienia relacji sąsiedzkich zaczynają wymieniać się między sobą właśnie pakietami hello.

Jak widać na rysunku powyżej na każdym łączu, każdy router rozsyła pakiety hello tak by móc poznać swoich sąsiadów. Routery R0, R1, R2, R3 mają szansę zostać sąsiadami (bo jak się przekonasz dalej czytelniku fakt odebrania pakietu hello nie gwarantuje nam, że relacja zostanie utworzona, na tym etapie przyjmujemy, że routery są sąsiadami), natomiast dwa interfejsy: Fa0/0 – router R2 oraz Fa0/0 – router R3 w procesie tworzenia relacji sąsiedzkich już nie będą uczestniczyć gdyż router na tych interfejsach nie odebrał pakietu hello. Po utworzeniu przyległości z sąsiadem pakiety hello, nadal są wysyłane co pozwala routerowi monitorować stan utworzonej relacji.

Po ustanowieniu przyległości, router może przystąpić do wysłania informacji o stanie swoich interfejsów, zostaje zbudowany pakiet LSP, który zawiera informację o stanie łącz (rysunek poniżej, router R1 ).

Po zbudowaniu pakietu LSP zostaje on wysłany poprzez wszystkie interfejsy routera na których została ustanowiona relacja sąsiedzka (rysunek poniżej, pakiet LSP zostaje wysłany z routera R1). Tak więc pakiet LSP zostaje wysłany do wszystkich sąsiadów a dodatkowo sąsiedzi ci, otrzymany pakiet LSP powielają na wszystkich swoich interfejsach (pakiet LSP nie jest wysyłany poprzez interfejs z którego został otrzymany). Mechanizm ten nazywa się zalewowym rozsyłaniem pakietów LSP (z rozsyłaniem tym jest związane parę problemów ale o tym później). Pakiety LSP w przeciwieństwie do pakietów hello nie są i nie muszą być wysyłane regularnie. Pakiety te budowane są i rozsyłane w następujących sytuacjach:

• • podczas uruchomienia routera,
  • gdy następuje konfiguracja i włączenie protokołu routingu,
  • podczas zmiany topologii sieci, pod pojęciem tym rozumiemy: włączenie/wyłączenie interfejsu/łącza a także ustanowienie bądź zerwanie relacji sąsiedzkiej.

Tak więc po tym jak każdy router należący do danego obszaru roześle swoje pakiety LSP i każdy router od każdego routera takowe pakiety otrzyma, informacje w nich zawarte zostają umieszczone w bazie danych by mógł je wykorzystać algorytm SPF. Wynikiem uruchomienia algorytmu SPF będzie utworzenie tablicy routingu z najlepszymi z punktu widzenia routera ścieżkami do sieci docelowych.

Przykładowa baza danych dla routera R2 będzie wyglądać następująco:

Pakiet LSP od routera R1

• • Połączony z routerem R3; sieć 192.168.2.0/30; koszt 10
  • Połączony z routerem R2; sieć 192.168.0.0/30; koszt 20
  • Połączony z routerem R0; sieć 172.16.0.0/24; koszt 2

Pakiet LSP od routera R3

• • Połączony z routerem R1; sieć 192.168.2.0/30; koszt 10
  • Połączony z routerem R2; sieć 192.168.1.0/30; koszt 10
  • Dostęp do sieci 172.16.1.0/24; koszt 2

Dane o łączach routera R2

• • Połączony z ruterem R1; sieć 192.168.0.0/30; koszt 20
  • Połączony z routerem R3; sieć 192.168.1.0/30; koszt 10
  • Dostęp do sieci 10.0.0.0/24; koszt 2

Informacje o wszystkich dostępnych sieciach router R2 zdobywa właśnie dzięki pakietom LSP:

• • Sieć 10.0.0.0/24; sieć połączona bezpośrednio; koszt 2
  • Sieć 192.168.0.0/30; sieć połączona bezpośrednio; koszt 20
  • Sieć 192.168.0.0/30; droga od R2 poprzez R3 do R1; koszt 35
  • Sieć 192.168.1.0/30; sieć połączona bezpośrednio; koszt 5
  • Sieć 192.168.1.0/30; droga od R2 poprzez R1 do R3; koszt 35
  • Sieć 172.16.0.0/24; droga od R2 do R1; koszt 22
  • Sieć 172.16.0.0/24; droga od R2 poprzez R3 do R1; koszt 17
  • Sieć 172.16.1.0/24; droga od R2 do R3; koszt 7
  • Sieć 172.16.1.0/24; droga od R2 poprzez R1 do R3; koszt 32

z których to ścieżek wybierze najlepsze z swojego punktu widzenia (wynik działania algorytmu SPF):

• • Sieć 10.0.0.0/24; sieć połączona bezpośrednio; koszt 2
  • Sieć 192.168.0.0/30; sieć połączona bezpośrednio; koszt 20
  • Sieć 192.168.1.0/30; sieć połączona bezpośrednio; koszt 5
  • Sieć 172.16.0.0/24; droga od R2 poprzez R3 do R1; koszt 17
  • Sieć 172.16.1.0/24; droga od R2 do R3; koszt 7

Na ilustracji poniżej przedstawiono sposób enkapsulacji pakietów OSPF.

Typ pakietu OSPF (jeden z pięciu, o czym za chwilę) opatrzony jest nagłówkiem, który znajduje się w każdym pakiecie protokołu routingu OSPF, niezależnie od przesyłanego typu. Całość ta jest enkapsulowana w pakiecie IP, (w polu Protokół umieszczona jest wartość 89 oznaczająca typ przenoszonych danych jako dane protokołu OSPF), który następnie jest wysyłany na jeden z dwóch adresów grupowych 224.0.0.5 bądź 224.0.0.6 W przypadku użycia sieci ethernet (a tak najczęściej bywa) całość dodatkowo jest umieszczana w ethernetowej ramce łącza danych o docelowym adresie MAC należącym również jak w przypadku IP do grupy multicastowej - 01-00-5E-00-00-05 bądź 01-00-5E-00-00-06

Poniżej przechwycony pakiet OSPF (pakiet hello pomiędzy dwoma routerami o adresach 192.168.0.1 oraz 192.168.0.2) w którym jak na dłoni widać wszystkie informacje.

1. 1. multicastowy adres rozgłoszeniowy łącza danych (Ethernet) - 01-00-5E-00-00-05,
   2. adres MAC źródłowy - c2:05:0a:f4:00:00,
   3. pole protokołu w nagłówku pakietu IP – 89 OSPF,
   4. źródłowy adres IP – 192.168.0.1,
   5. adres grupowy IP - 224.0.0.5,
   6. nagłówek OSPF,
   7. informacja o id obszaru – area 2
   8. typ pakietu OSPF – pakiet hello.

Istnieje pięć typów pakietów OSPF LSPs (link-state packets).

Hello -do nawiązywania i utrzymywania sąsiedztwa z innymi routerami (zrzut widoku przechwyconego pakietu powyżej),

DBD (ang. Database Description): - skrócona lista bazy danych zawierającej stany łącz routera,

LSR (ang. Link-State Request) - gdy potrzeba jest dodatkowych informacji router możemy wysłać zapytanie z żądaniem dodatkowych danych,

LSU: (ang. Link-State Update) -zawierają informacje o stanie łącz i dodatkowo mogą być odpowiedzią na pakiet LSR. Pakiet ten może zawierać 11 typów ogłoszeń LSA. Akronimy LSU (aktualizacja łącze-stan) oraz LSA (ogłoszenie łącze stan) bardzo często są używane zamiennie, dzieje się tak ponieważ w pakiecie LSU są zawarte ogłoszenie LSA. Tak więc akronimy te używane są zależnie od stopnia szczegółowości omawianego tematu.

Typy poszczególnych pakietów LSA wraz z ich krótkim omówieniem zebrano poniżej:

• • Typ LSA: 1 (Router) – tworzone przez routery celem przedstawienia się innym routerom na swoim obszarze. W pakiecie zawarta jest informacja o identyfikatorze RID routera, interfejsach routera działających w danym obszarze czy kosztach łączy. Pakiet typu LSA 1 może ze sobą nieść informację również o sieciach cząstkowych.
  • Typ LSA: 2 (Network) – pakiet tworzony przez routery desygnowane (DR) a przekazujący informację o podsieci w której znajduje się router DR i połączonych z tą podsiecią interfejsach routera.
  • Typ LSA: 3 (Summary) – pakiet tego typu tworzony jest przez routery ABR a umieszczone są w nim informacje zebrane dzięki pakietom LSA 1 oraz LSA 2. Celem pakietu jest poinformowanie o danych podsieciach lecz informacja ta jest wysyłana do innego obszaru OSPF.
  • Typ LSA: 4 (ASBR Summary) – podobnie jak w przypadku LSA 3 lecz w ogłoszeniu znajduje się informacja o trasie pozwalającej osiągnąć router ASBR.
  • Typ LSA: 5 (AS External) – ogłoszenie tworzone prze router ASBR a zawierające informację o trasach zewnętrznych.
  • Typ LSA: 6 (Group Membership) – nieobsługiwane przez Cisco IOS
  • Typ LSA: 7 (NSSA External) – dotyczy ogłoszeń tworzonych przez routery ASBR znajdujących się w tzw. obszarach niezbyt szczątkowych (NSSA)
  • Typ LSA: 8 (External Attributes) – nieobsługiwane przez Cisco IOS
  • Typ LSA: 9-11 (Opaque) – do zastosowań przyszłościowych

Wiem, że przedstawiony powyżej opis będzie Ci się czytelniku wydawał czarną magią lecz wierz mi gdy powrócisz do niego po przeczytaniu całego artykułu wszystko stanie się jasne (a na pewno większość).

LSAck (ang. LSA Acknowledgment) – potwierdzenie odbioru pakietu LSU.

W początkowej fazie komunikacji pomiędzy routerami na których został skonfigurowany OSPF routery by się odszukać używają pakietów hello. Pakiety te w całym procesie OSPF pełnią następujące role:

• • pozwalają odkryć sąsiadów OSPF,
  • nawiązują sąsiedztwo z wykrytymi sąsiadami,
  • ogłaszają parametry, co do których musi nastąpić ZGODNOŚĆ aby routery mogły zostać sąsiadami a tym samym prowadzić wspólnie proces routingu m.in. interwał hello (ang. hello interval), czas uznania za nieczynny (ang. dead interval), typ sieci (ang. network type),
  • pozwalają wybrać tzw. router desygnowany (ang. designated router - DR) i zapasowy router desygnowany, (ang. backup designated router – BDR) wybór ten jest realizowany w sieciach wielodostępowych tj. ethernet lub frame relay.

Zawartość pakietu hello jest następująca (poniżej przechwycony pakiet z zaznaczonymi wszystkimi informacjami):

1. 1. Type - typ pakietu:hello (Type 1), DBD (Type 2), LS Request – żądanie łącze-stan (Type 3), LS Update – aktualizacja łącze-stan (Type 4), LS ACK – potwierdzenie łącz-stan (Type 5)
   2. Router ID – identyfikator routera: ID ogłaszającego routera,
   3. Area ID – identyfikator obszaru: numer obszaru, z którego pochodzi pakiet,
   4. Network Mask – maska podsieci: maska podsieci interfejsu, z którego pakiet został wysłany,
   5. Hello Interval – interwał hello: w jakim odstępie czasu są wysyłane pakiety hello,
   6. Router Priority – priorytet routera: wykorzystywany przy wyborze routera desygnowanego,
   7. Designated Router (DR) – router desygnowany: ID routera desygnowanego (jeśli jest),
   8. Backup Designated Router (BDR) - zapasowy router desygnowany: ID zapasowego routera desygnowanego (jeśli jest),
   9. List of Neighbors - lista sąsiadów.

Dodatkowo po analizie pakietu możemy uzyskać informację o czasie uznania za nieczynny, który wynosi 40 s (domyślnie czterokrotność interwału hello), co razem z czasem interwału hello wynoszącym 10 s, jest wartościami standardowymi stosowanymi przez urządzenia CISCO. Wartości tych czasów obowiązują w sieciach wielodostępowych i punkt-punkt. Natomiast w sieciach typu NBMA (Frame Relay, X.25 lub ATM) odpowiednio: interwał hello – 30 s, dead interval – 120 s.

Nasze rozważania na temat protokołu OSPF będziemy prowadzili na przykładowej konfiguracji złożonej z trzech routerów i sześciu podsieci. Jeżeli nastąpi zmiana topologii sieci, fakt ten zostanie zaznaczony. Przyjmujemy, że na wszystkich routerach włączony jest routing OSPF.

Proces OSPF rozpoczyna się od wysłania pakietów hello poprzez wszystkie skonfigurowane interfejsy. Przyjęliśmy, że na każdym z routerów proces OSPF jest włączony, uruchomienie routera rozpoczyna proces tworzenia relacji sąsiedzkich z innymi routerami a jego pierwszym etapem jest właśnie rozpoczęcie wysyłania pakietów hello.

Routery wysyłają oraz odbierają pakiety hello na swoich interfejsach ale sam fakt odebrania pakietu hello nie skutkuje utworzeniem przyległości. W tej chwili router ma jedynie informacje, że na łączu po drugiej stronie znajduje się inny router.

By routery mogły prowadzić między sobą routing muszą uzgodnić między sobą trzy wartości czyli mówiąc inaczej routery nie utworzą sąsiedztwa, jeśli nie będą zgadzały się następujące parametry: interwał hello, czas uznania za nieczynny, typ sieci. Dodatkowo interfejsy uzgadniające między sobą sąsiedztwo muszą być w tej samej sieci, oczywiście warunek ten dotyczy również maski.

Gdy parametry zawarte w pakietach hello zgadzają się co do wartości następuje wymiana pakietów LSU, i dopiero po tej wymianie zostaje ustanowiona pełna przyległość.

Zerwanie więzów sąsiedztwa następuje gdy zostanie przekroczony czas dead interval, proces OSPF usuwa sąsiada z bazy danych a dodatkowo informuje on o nieosiągalnym sąsiedzie pozostałe routery OSPF.

Zanim przejdziemy do konfiguracji routerów należy dopowiedzieć jeszcze kilka kwestii dotyczących protokołu OSPF.

Pierwszą z nich jest dystans administracyjny, który dla protokołu OSPF wynosi 110. I jak widać protokół ten przegrywa tylko z innym protokołem routingu dynamicznego jakim jest EIGRP (przegrywa gdyż protokół EIGRP jest własnością CISCO).

Wcześniej wspomniałem o wyborze tzw. Designated Router (DR) i Backup Designated Router (BDR). Routery pełniące te funkcje wybiera się w sieciach wielodostępowych takich jak Ethernet, nasza topologii jest siecią punkt-punkt więc proces elekcji nie będzie następował (wybór routera DR i BDR zostanie omówiony w dalszej części wpisu po zmianie przykładowej topologii). Teraz wystarczy, że nadmienię, że DR jest odpowiedzialny za uaktualnianie pozostałych routerów, BDR jest routerem zapasowym i przejmuje rolę routera DR w razie awarii a cały proces ma za zadanie znacznie zredukować ruch OSPF w procesie budowania relacji sąsiedztwa z innymi routerami.

Kolejną ważną informacją je fakt, że protokół OSPF wspiera uwierzytelnianie (tym również się zajmiemy).

Protokół OSPF nie dokonuje automatycznej sumaryzacji swoich podsieci (w przeciwieństwie do np. RIP), oznacza to nic innego, że ogłaszane są wszystkie sieci skonfigurowane w procesie routingu, bez żadnych uogólnień.

Ok wróćmy do naszej przykładowej topologii i spróbujmy uruchomić routing dynamiczny oparty na protokole OSPF.

Aby włączyć protokół OSPF w trybie konfiguracji globalnej musimy wydać polecenie: router ospf <ID_procesu> ID procesu jest to numer wybierany przez administratora z zakresu od 1 do 65535. Protokół OSPF do działania może wykorzystywać wiele procesów lecz wybór numeru w żaden sposób nie wpływa na ustalenie przyległości czyli w przeciwieństwie do EIGRP gdzie numer musi być zgodny na wszystkich routerach, ma charakter całkowicie lokalny. Oznacza to, że na jednym routerze numer ten można ustalić na 100, zaś na drugim na 200 a routery i tak ustanowią relację sąsiedzką. Najczęściej jednak ustala się jeden stały numer dla zachowania porządku w konfiguracji i zazwyczaj jest to 1.

Po uruchomieniu procesu OSPF należy włączyć rozgłaszanie dostępnych sieci, rozgłaszanie te podobnie jak w przypadku innych protokołów wykonujemy za pomocą polecenia network. Tak więc wydanie polecenia network powoduje włączenie procesu OSPF na każdym interfejsie, którego adres IP pasuje do adresu podanego po słowie network a dodatkowo powoduje rozgłaszanie sieci, do której dany interfejs należy.

Polecenie network wydawane jest w trybie konfiguracji routera i jego ogólna składnia jest następująca: network <adres_sieciowy> <maska_sieci> area <id_obszaru> Jak widać w porównaniu do protokołu RIP polecenie te jest bardziej rozbudowane i w swojej składni zawiera dodatkowe elementy.

W poleceniu network inaczej definiuje się maskę sieci, nie wykonuje się tego w sposób tradycyjny lecz do tego celu używa się tzw. maski blankietowej (choć tak naprawdę wszystko zależy od wersji systemu IOS, nowsze wersje wspierają oba sposoby definiowania maski). Maskę blankietową częściej nazywa się wildcard mask. Maska blankietowa podobnie jak tradycyjna maska sieci jest 32-bitową wielkością podzieloną na cztery oktety. I tak naprawdę podobieństwa na tym się kończą, ponieważ użycie wildcard mask podlega innym regułom i stanowi odrębną koncepcje w podejściu do użycia jej w połączeniu z adresem IP. Maska blankietowa nakładana jest na adres IP co w połączeniu z binarnymi jedynkami i zerami powoduje filtrację adresów IP (pojedynczych lub grup) a nie jak to w przypadku tradycyjnej maski sieci do identyfikacji części należącej do adresu sieci oraz części przynależnej hostom. Wildcard mask najczęściej używa się w połączniu z mechanizmem tworzenia listy kontroli dostępu (ang. ACL), gdzie na podstawie adresu i maski tworzona jest lista adresów co do, których lista ACL zezwalająca bądź zabraniająca ma zastosowanie (kiedyś o listach ACL napiszę szerzej).

Lecz pozostaje pytanie – Jaką wartość w końcu wpisać? Aby przejść z tradycyjnej maski sieci na maskę blankietową możemy użyć takiego o to sposobu: chcemy rozgłosić sieć 172.16.0.0/24, zapis /24 oznacza, że została użyta maska sieci o adresie 255.255.255.0 teraz tylko należy wykonać odejmowanie

Tak więc w poleceniu network celem rozgłoszenia sieci 172.16.0.0/24 należało by użyć następującego adresu: 0.0.0.255

Dla sieci 192.168.0.0/30 maska blankietowa przyjmie wartość 0.0.0.3 ponieważ:

W ten oto prosty sposób możemy wykonać przejście z tradycyjnej maski na maskę blankietowa.

W poleceniu network pozostało nam do omówienia jeszcze jeden parametr a mianowicie fragment odnoszący się do identyfikacji obszaru OSPF – area <id_obszaru>

Zastosowanie koncepcji obszaru jest jednym z ciekawszych i najważniejszych elementów standardu OSPF. Koncepcja ta sprawia administratorom pewne trudności przy konfiguracji routerów lecz po bliższym poznaniu okazuje się, że nie taki diabeł straszny. Zastosowanie obszarów na których to realizowany jest proces routingu oparty o OSPF pozwala nam na zachowanie dużej elastyczności przy tworzeniu topologii sieci oraz zapewnia nam większą skalowalność choć fakt korzystania z różnych obszarów trzeba dobrze przemyśleć szczególnie jeśli chodzi o przydział adresów IP. Sieć podzieloną na obszary można oczywiście łączyć tak by informacje o trasach mogły być przekazywane poza dany obszar. Myślę, że koncepcję obszarów najlepiej przedstawi ten o to rysunek.

Sieć naszą mamy podzieloną na 3 obszary i każdy z tych obszarów jest podłączony do tzw. obszaru szkieletowego (czyli tak naprawdę mamy 4 obszary). Takie zaprojektowanie sieci powoduje, że routery z jednego obszaru nie musza przetwarzać pakietów LSA innego obszaru. Poza obszar jest jedynie przekazywana uogólniona, zsumaryzowana informacja o sieciach znajdujących się w danym obszarze. Informacja ta jest tworzona i rozpowszechniana za pomocą routerów brzegowych tzw. ABR (ang. Area Border Router). W naszym scenariuszu routerami brzegowymi są routery R1,R2 oraz R3 gdyż według definicji routerem brzegowym jest ten router, którego interfejsy należą do różnych obszarów – np. w przypadku routera R3 jeden z interfejsów jest częścią obszaru 3 natomiast drugi jest przyłączony do obszaru szkieletowego. Pozostałe routery w obszarze nazywane są routerami wewnętrznymi (ang. IR – internal router). Wykorzystując podział na obszary, dany router ABR do routera S1 wysyła informację stanowiącą uogólnienie obsługiwanych sieci wewnętrznych jest dokonywana tzw. sumaryzacja tras – zagadnienie to opisałem w wpisie Co w sieci siedzi. Routing statyczny. Celem tego procesu jest zmniejszenie tablic routingu - ponieważ zamiast 12 tras w tablicy routingu routera S1 znajdą się jedynie 3 wpisy. Jednakowo np. do routera R1 zostanie przesłana informacja o dwóch dużych zsumaryzowanych sieciach należących do obszaru 2 (trasa 192.168.0.0/21) i obszaru 3 (trasa 172.16.0.0/21) zamiast ośmiu odrębnych ścieżek. Dlatego tak ważna jest kwestia doboru odpowiedniej adresacji IP tak by jak najefektywniej wykorzystać mechanizm uogólniania rozgłaszanych przez routery ABR tras do swoich sieci. Drugim niezaprzeczalnym atutem (co zresztą już też zostało zaznaczone) takiego podejścia do sprawy jest fakt iż pakiety LSA dotyczące danego obszaru są rozsyłane tylko wewnątrz obszaru, którego dotyczą. Podział na obszary po części niweluje problem zalewowego rozsyłania pakietów a dodatkowo samo wyliczenie tras z wykorzystaniem algorytmu SPF jest ograniczone tylko do obszaru.

W literaturze czytelniku możesz natknąć się na definicję tzw. routera ASBR (ang. Autonomous System Boundary Router). Router ten nazywany jest również brzegowym routerem systemu autonomicznego i pełni on funkcję bramy pomiędzy protokołem OSPF a innymi protokołami routingu (RIP, EIGRP) a także innymi instancjami samego protokołu OSPF. Odnosząc to do naszego przykładu, gdyby np. w obszarze 3 protokołem odpowiedzialnym za zapełnienie tablic routingu był protokół RIPv2 to router R3 będzie definiowany jako router ASBR.

Wracając już do samego polecenia: area <id_obszaru>, każdy obszar definiowany jest jako 32-bitowy identyfikator zapisywany w postaci dziesiętnej, podobnie jak adres IP (świetnie to widać przy zrzucie przechwyconego pakietu hello, 4 rysunki wyżej). Tak więc każda sieć oparta na protokole OSPF w przypadku stosowania podziału na obszary musi zawierać sieci należące do obszaru 0 (sieć szkieletowa) czego następstwem jest przynależność każdego routera ABR do obszaru szkieletowego. Wyjątkiem jest sytuacja w której proces routingu OSPF obejmuje tylko jeden obszar, wówczas identyfikator obszaru może przyjąć wartość dowolną choć przyjęło się że nie nadaje się innej wartości niż 0.

Zanim przejdziemy do omawiana konfiguracji routerów i uruchamiania routingu dynamicznego opartego na protokole OSPF, przypomnę jeszcze raz topologię sieci, która posłuży nam do rozważań na temat protokołu OSPF.

Ćwiczenie nasze rozpoczynamy od skonfigurowania interfejsów czyli każdemu interfejsowi musimy przypisać odpowiednie adresy IP tworząc tym samym odpowiednie podsieci. Jak widać na poniższych zrzutach interfejsy zostały skonfigurowane (jak wykonać adresację? - tu odsyłam do opisu zawartego w innych artykule - http://slow7.pl/sieci-komputerowe/110-co-w-sieci-siedzi-routig-statyczny).

Po wykonaniu konfiguracji interfejsów celem weryfikacji przypisanych adresów IP i sprawdzenia komunikacji pomiędzy routerami został przeprowadzony test, polegający na wysłaniu pakietów ICPM (ping). Jak widać poniżej wszystkie interfejsy odpowiedziały na pakiet ping.

Po uzyskaniu pewności, że proces komunikacji przebiega poprawnie i jest zachowana możliwość poprawnego przesyłania danych możemy przystąpić do konfiguracji protokołu OSPF.

Konfigurację zaczniemy od routera R1. Proces rozpoczynamy od wydania polecenia: router ospf <id_procesu> w naszym przypadku polecenie przyjmie postać: router ospf 1

Router R1 podłączony jest do 3 sieci, wszystkie te sieci będziemy chcieli rozgłosić za pomocą protokołu OSPF. By sieć uczestniczyła w procesie OSPF musimy ją rozgłosić za pomocą polecenia network. Wszystkie sieci będą zgrupowane w jednym obszarze area 0, utworzymy tzw. jednoobszarowy OSPF. Po wyliczeniu maski blankietowej polecenia network przyjmą postać jak na poniższym zrzucie.

Sprawdzenie tablicy routingu routera R1 nie uwidacznia jeszcze żadnych zmian ani aktualizacji uzyskanych dzięki protokołowi OSPF. W tablicy routingu routera R1 znajdują się tylko sieci połączone bezpośrednio z routerem R1.

Po wykonaniu czynności na routerze R1 przechodzimy do konfiguracji protokołu OSPF na routerze R2. Tak jak poprzednio rozpoczynamy od uruchomienia procesu OSPF – polecenie: router ospf 2 (identyfikator został specjalnie zmieniony, by pokazać, że wartość ta nie ma wpływu na ustalenie przyległości) - pkt.1.

W punkcie 2 po wydaniu polecenia network, sieć 192.168.0.0/30 została rozgłoszona, po chwili uzyskujemy informacje o ustanowieniu sąsiedztwa (pkt. 3). Przyległość została utworzona gdyż na routerze R1 sieć ta już uczestniczy w procesie routingu a router R1 jest podłączony bezpośrednio z routerem R2. W punkcie 4 i 5 do procesu OSPF zostały włączone pozostałe sieci połączone bezpośrednio z routerem R2 czyli sieć 192.168.1.0/30 oraz sieć 10.0.0.0/24

Po wydaniu poleceń show ip route na obydwu routerach czyli na routerze R1 oraz R2 w tablicy routingu możemy zauważyć wpisy odnoszące się do wszystkich sieci, które są podłączone do tych routerów. Komunikacja pomiędzy tymi sieciami jest już możliwa. Jak można zauważyć pomimo wydania różnych identyfikatorów procesu (polecenie: router ospf <id_procesu>) sąsiedztwo zostało ustanowione a routery wymieniły się swoimi tablicami routingu.

Gdy już skonfigurowaliśmy dwa routery czas by odpowiednia polecenia wydać na routerze R3. Konfigurację przeprowadzamy analogicznie jak na pozostałych czyli w pierwszej kolejności uruchamiamy protokół OSPF a następnie włączamy rozgłaszanie sieci. Podczas wydawania kolejnych poleceń network będziemy informowani o ustaleniu kolejnych relacji sąsiedztwa.

Po wykonaniu konfiguracji czas na jej weryfikację, kontrola tablic routingu wszystkich routerów przekonuje nas o tym, że wszystkie sieci zostały rozgłoszone poprawnie (rysunek poniżej).

Jak można zauważyć po analizie tablic do pewnych sieci zostały utworzone dwie odrębne trasy np. z punktu widzenia routera R1 do sieci 192.168.1.0/30 pakiety mogą zostać dwojako: pierwsza trasa prowadzi poprzez interfejs serial0/0 (next hoop – 192.168.2.2), druga zaś poprzez interfejs serial0/1 (next hoop 192.168.0.2). Taki stan rzeczy jest możliwy gdyż obliczona metryka (128) dla obu tras jest ta sama, w przypadku zaistnienia takiej sytuacji router będzie prowadził load balancing czyli równoważenie łącza poprzez wysyłanie pakietów do sieci docelowej naprzemiennie obiema trasami. Sytuacja powtarza się na routerze R2 (sieć 192.168.2.0/30) oraz na routerze R3 (sieć 192.168.0.0/30)

Po konfiguracji routerów komputery również mogą prowadzić między sobą komunikację. Poniżej pakiet ping wraz z trasą pakietów wysłany z komputera Windows XP_1 (IP 172.16.0.10) do komputera WindowsXP_2 (IP 10.0.0.10) oraz hosta WindowsXP_3 (IP 172.16.1.10). Jak widać komunikacja przebiega jak najbardziej poprawnie.

Podczas konfiguracji protokołu OSPF szczególnie tej błędnie wykonanej musimy mieć możliwość sprawdzenia gdzie popełniliśmy błąd, do weryfikacji ustawień protokołu OSPF służy wiele poleceń systemu IOS, dlatego teraz krótko o poleceniach, które pozwolą nam na wykrycie i naprawienie ewentualnych błędów.

Pierwszym poleceniem, które umożliwi nam weryfikację ustawień jest zajrzenie do konfiguracji bieżącej routera – polecenie: show running-config (listening poniżej zawiera część informacji uzyskanej dzięki poleceniu).

Po wydaniu polecenia możemy ustalić identyfikator procesu OSPF oraz adresy sieci, które są skojarzone z protokołem OSPF (polecenie network) wraz z obsługiwanym obszarem (polecenie area).

Bardzo przydatną komendą pozwalającą nam uzyskać naprawdę sporo informacji na temat stanu protokołu OSPF i utworzonych relacji sąsiedzkich jest komenda: show ip ospf neighbor

1. Neighbor ID – identyfikator routera sąsiada (o identyfikatorze routera więcej za chwilę i przy omawianiu protokołu OSPF w konfiguracji wielodostępowej, dla przypomnienia bieżąca konfiguracja to punkt-punkt),

2. Pri – priorytet interfejsu OSPF (o tym również szerzej za chwilę),

3. State – stan interfejsu OSPF. Oznaczenie FULL oznacza, że została nawiązana pełna relacja sąsiedzka. Stan bazy łącze-stan na obu urządzeniach jest identyczny. W konfiguracji punkt-punkt wszystkie relacje sąsiedzkie będą w stanie FULL natomiast w konfiguracji wielodostępowej będziemy mieli do czynienia z innymi typami relacji,

4. Dead Time – czas po którym router zerwie nawiązaną relację sąsiedzką, czas jest resetowany po otrzymaniu pakietu hello,

5. Adress – adres IP sąsiada z który został ustanowiona przyległość,

6. Interface – interfejs routera, który ustanowił relację sąsiedzką.

Polecenie show ip ospf neighbor można rozwinąć o parametr detail, uzyskamy w ten sposób jeszcze dokładniejsze informacje o stanie protokołu OSPF.

Kolejnym poleceniem, które pomoże nam sprawdzić stan protokołu OSPF jest polecenie: show ip ospf

1. Informacja o identyfikatorze procesu OSPF wraz z identyfikatorem routera,

2. Liczba interfejsów biorąca udział w procesie routingu,

3. Czas wykonania ostatniego przeliczenia algorytmu SPF – algorytm SPF na nowo przeliczany jest w sytuacji dodania, usunięcia bądź modyfikacji łącza.

Oczywiście polecenie zdradza nam wiele innych cennych informacji, które postaram się omówić w dalszej części wpisu (lecz wszystko w swoim czasie).

Polecenie: show ip protocols (chyba jedno z najbardziej pomocnych poleceń) w zbiorczym listeningu dostarczy nam niezbędnych informacji na temat protokołu OSPF.

1. Identyfikator procesu OSPF,

2. Identyfikator routera,

3. Sieci ogłaszane w procesie routingu z wykorzystaniem protokołu OSPF,

4. Informacja o sąsiadach, wraz z informacją o dystansie administracyjnym i czasem ostatniej aktualizacji.

Sytuacją z którą często możemy spotkać się przy konfiguracji protokołu OSPF jest brak ustanowienia relacji sąsiedzkiej a jednym z powodów niemożności nawiązania połączenia z sąsiadem, jak już zostało wspomniane może być błędnie skonfigurowany licznik wysyłania pakietów hello. Polecenie, które pozwoli nam na sprawdzenie ustawionego czasu rozsyłania tych pakietów to: show ip ospf interface

1. Informacja o adresie IP interfejsu wraz z informacją o numerze obsługiwanego obszaru,

2. Identyfikator routera, typ sieci oraz koszt łącza,

3. Interwał licznika czasu wysyłania pakietów hello oraz czas zerwania przyległości z sąsiadem,

4. Pakiet hello zostanie wysłany za …,

5. Licznik wykrytych sąsiadów wraz z liczbą ustanowionych relacji sąsiedzkich,

6. Adres IP sąsiada.

Aby uzyskać informację w postaci zbiorczej tabeli możemy posłużyć się poleceniem: show ip ospf interface brief Polecenie jest bardzo przydatne bo w postaci tabeli dostarcza nam informację o statucie interfejsów biorących udział w procesie OSPF. Po wydaniu polecenia możemy uzyskać takie informację jak:

1. Nazwa interfejsu biorącego udział w procesie OSPF,

2. Obszar do którego dany interfejs jest przypisany,

3. Adres IP wraz z maską,

4. Koszt łącza,

5. Typ połączenia (jak widać połączenia serialowe są typu peer-to-peer natomiast połączenia ethernetowe należą do połączeń broadcastowych w których wybierany jest router desygnowany),

6. Liczba sąsiadów.

Poleceniem, którym możemy użyć by sprawdzić ruch generowany przez protokół OSPF jest komenda: show ip ospf traffic. Po wydaniu polecenia ukażą nam się dane odnoszące się do każdego typu wysłanego/odebranego pakietu w rozbiciu na każdy interfejs biorący udział w procesie OSPF wraz z informacją o sumarycznej liczbie wysłanych/odebranych pakietów.

Do kontroli trwającego procesu OSPF możemy również użyć serii poleceń debug. Aby wyświetlić informację o odebranych i wysłanych pakietach hello możemy włączyć debugowanie procesu OSPF pod kątem występowania pakietów hello. Aby włączyć debugowanie wydaj polecenie: debug ip ospf hello.

Po wydaniu polecenia uzyskamy informację o wysłanych i odebranych pakietach hello wraz z adresem IP oraz interfejsem (do podglądu pojawiających się pakietów OSPF możemy użyć również polecenia debug ip ospf packet).

Drugim poleceniem, które może nam dostarczyć wiele informacji o utworzonych bądź zerwanych relacjach sąsiedzkich jest: debug ip ospf adj

By połączyć informację z obu poleceń debug tj. hello oraz adj wydaj komendę: debug ip ospf events

Teraz gdy już mamy omówione podstawowe polecenia służące do konfiguracji routingu opartego o OSPF jak i polecenia pozwalające nam na kontrolę działania samego procesu możemy trochę bliżej przyjrzeć się metryce oraz sposobie jej wyliczania.

Jak już zostało nadmienione w wstępie, OSPF w wyliczeniu całościowego kosztu dotarcia do danej sieci zdalnej korzysta z tzw. kosztów przypisanych do danego łącza. Kosz ten domyślnie jest wyliczany według wzoru:

10⁸/szerokość pasma interfejsu

gdzie: przepustowość jest wyrażona w b/s (wzór możemy zmodyfikować do: 10⁵/szerokość pasma interfejsu gdybyśmy chcieli wartości podstawiać w Kb/s).

W obliczeniach wartość 10⁸ nazywana jest: referencyjną szerokością pasma. Czemu przyjęto do obliczeń wartość 10⁸? Otóż dlatego iż domyślnie wartość ta ustawiona jest na 100Mb/s co w przeliczeniu daje 100 000 000 b/s lub krócej 10⁸ b/s. Gdy do wzoru podstawimy odpowiednie wartości szerokości pasma otrzymamy następujące koszty łączy (pamiętamy iż w protokole OSPF w przeciwieństwie do innych protokołów takich jak RIP czy EIGRP rozpowszechniany jest koszt pojedynczych łączy a nie całych tras). Poniżej zebrano domyślne koszty tras w zależności od szerokości pasma interfejsu. Otrzymane wartości zaokrąglamy w dół.

• • Łącze szeregowe – 56 Kb/s – koszt 1785 - ponieważ 100000/56=1785
  • Łącze szeregowe T1 – 1,544 Mb/s – koszt 64 - ponieważ 100000/1544=64
  • Łącze szeregowe E1 – 2,048 Mb/s – koszt 48 - ponieważ 100000/2048=48
  • Token Ring – 4,0 Mb/s – koszt 25 - ponieważ 100000/4000=25
  • Ethernet – 10Mb/s – koszt 10 - ponieważ 100000/10000=10
  • Token Ring 16Mb/s – koszt 6 - ponieważ 100000/16000=6
  • Fast Ethernet 100Mb/s – koszt 1 - ponieważ 100000/100000=1
  • Gigabit Ethernet 1000Mb/s – koszt 1
  • 10 Gigabit Ethernet 10000 – koszt 1

Po analizie otrzymanych kosztów przy domyślnej wartości pasma referencyjnego to co rzuca się w oczy to to iż w przypadku szybkich łączy (od fast ethernet w górę) koszt łącza nie ulega zmianie. Czyli przy ustalaniu kosztu do sieci zdalnej nie zależnie od użytego typu połączenia będzie brana wartość 1. Jest to ustawienie dość niekorzystne gdyż jeżeli w naszej sieci dysponujemy szybkimi łączami ustawienie domyślne nie będzie odzwierciedlać stanu fizycznego naszej sieci a tym samym z punktu widzenia OSPF trasa fast ethernet przez router będzie traktowana na równi z łączem gigabit ethernet. Dlatego by zmienić ten stan rzeczy i doprowadzić do stanu w którym jednak łącza te będą zróżnicowane pod względem kosztu należy zmienić domyślną wartość referencyjną szerokości pasma. Zmiana wartość spowoduje wyliczenie na nowo kosztów poszczególnych łączy. I tak zmieniając wartość z 100Mb/s na 10000Mb/s (do wzoru zostanie podstawiona wartość 10¹⁰ gdy jednostkami będą b/s natomiast gdy Kb/s wartość ta wyniesie 10⁷ – oczywiście mówimy o referencyjnej szerokości pasma)

Po zmianie, koszty tras w zależności od szerokości pasma interfejsu przyjmą następuje wartości:

• • Łącze szeregowe – 56 Kb/s – koszt 178571 - ponieważ 10000000/56=178571
  • Łącze szeregowe T1 – 1,544 Mb/s – koszt 6476 - ponieważ 10000000/1544=6476
  • Łącze szeregowe E1 – 2,048 Mb/s – koszt 4882 - ponieważ 10000000/2048=4882
  • Token Ring – 4,0 Mb/s – koszt 2500 - ponieważ 10000000/4000=2500
  • Ethernet – 10Mb/s – koszt 1000 - ponieważ 10000000/10000=1000
  • Token Ring 16Mb/s – koszt 625 - ponieważ 10000000/16000=625
  • Fast Ethernet 100Mb/s – koszt 100 - ponieważ 10000000/100000=100
  • Gigabit Ethernet 1000Mb/s – koszt 10 - ponieważ 10000000/1000000=10
  • 10 Gigabit Ethernet 10000 – koszt 1 - ponieważ 10000000/10000000=1

Jak widać dzięki zmianie referencyjnej szerokości pasma uzyskaliśmy zróżnicowanie w wyliczeniu kosztów szybkich łączy. Zmianę tą należy dokonać na wszystkich routerach tak aby wyliczana i przekazywana metryka była spójna.

Tak więc przejdźmy do przykładu i pokażmy jak wykonać zmianę domyślnej wartości referencyjnej szerokości pasma.

Po wydaniu polecenia: show ip ospf interface brief uzyskujemy informację o stanie kosztów poszczególnych łączy routera. Jak widać poniżej poszczególne wyliczone koszty łącz opierały się o domyślną wartość referencyjną.

Aby dowiedzieć się jaka wartość szerokości pasma interfejsu została użyta do obliczenia kosztu danego łącza możemy posłużyć się poleceniem: show interface <interfejs> Na uwadze należy mieć fakt iż wartość ta nie wpływa na rzeczywistą, fizyczną przepustowość interfejsu lecz jedynie jest używana do wyliczenia kosztów łącza.

Zmianę wartości referencyjne dokonujemy w trybie konfiguracji routingu za pomocą polecenia: auto-cost reference-bandwidth <wartość_w_Mb/s>. Po wydaniu polecenia system IOS informuje nas o konieczności zmiany tego parametru również na innych urządzeniach.

Nowe wartości kosztów łącz możemy sprawdzić gdy ponownie wydamy polecenie: show ip ospf interface brief

Aby danemu interfejsowi przypisać rzeczywistą wartość szerokości pasma należy użyć polecenia: bandwidth <szerokość_pasma_w_Kb/s>. Polecenie te używamy w trybie konfiguracji interfejsu sieciowego. Ręczna modyfikacja jest konieczna gdy rzeczywista wartość pasma jest różna od zdefiniowanej. System IOS na interfejsie szeregowym przyjmuje domyślną szybkość łącza T1 wynoszącą 1544 Kb/s lecz w rzeczywistości wykupiona wielkość pasma może się różnić od tej zdefiniowanej przez producenta. Tak więc by pokazać jak parametr szerokości pasma wpływa na tablicę routingu tradycyjnie wykonajmy mały przykład. A mianowicie w naszej konfiguracji zmodyfikujemy wartości pasma na każdym z interfejsów zgodnie z rysunkiem poniżej. Modyfikacja ta musi być wykonana po obu stronach łącza.

Zgodnie z rysunkiem powyżej na każdym z interfejsów routera zostały przypisane odpowiednie wartości prędkości łącza. Zostało użyte polecenie: bandwidth <szerokość_pasma_w_Kb/s>

Po skonfigurowaniu interfejsów możemy za pomocą polecenia: show ip ospf interface <nazwa_interfejsu> dokonać sprawdzenia kosztu poszczególnego łącza.

Poniżej koszt łączy na routerze R1 uwzględniający już zmianę prędkości interfejsu (przed zmianą prędkość przyjmowała domyślną wartość 1544 Kb/s czyli koszt łącza wykorzystywany przy obliczaniu metryki OSPF wynosił 64).

i koszt łączy na routerze R3.

Zmiana kosztów łączy wymusiła również zmianę tablicy routingu ponieważ zróżnicowanie metryk spowodowało wypadnięcie pewnych tras. Jak zapewne pamiętasz router R3 (zresztą tak samo router R1 i R2) prowadziły równoważenie łącza poprzez wysyłanie pakietów do sieci zdalnych naprzemiennie. Load balancing był spowodowany wystąpieniem tras o tej samej metryce. Ta sama metryka dla dwóch różnych tras wymuszała uwzględnienie obydwu tras w tablicy routingu. W przypadku routera R3 siecią do której prowadziły dwie trasy była sieć: 192.168.0.0/30. Teraz jak widać poniżej w tablicy routingu routera R3 dotarcie do sieci jest realizowane za pomocą trasy dla której wyliczona wartość metryki przyjmuje niższą wartość (trasa jest szybsza).

Informację o koszcie poszczególnych łączy uzyskaliśmy za pomocą polecenia: show ip ospf interface <nazwa_interfejsu> i oczywiście tym poleceniem możemy się posiłkować by zdobyć potrzebne nam informację ale chciałbym jeszcze pokazać inny sposób. Poleceniem, które posłuży nam do zdobycia potrzebnych danych jest polecenie show ip ospf database. Po wydaniu komendy uzyskamy wgląd w bazę procesu OSPF czyli kto jakie informacje i od kogo uzyskał. Polecenie te wyświetla podsumowanie ogłoszeń LSA znanych danemu routerowi.

Lecz zanim zaczniemy analizować polecenia jeszcze krótkie słowo wstępu. Polecenie te informacje grupuje wg. identyfikatorów routera (lub jak kto woli według identyfikatora RID) temat ten cały czas się przewija i wybacz czytelniku gdyż jeszcze go nie rozwinę. Na tą chwilę wystarczy, że powiem iż identyfikatory te są używane w procesie OSPF celem identyfikacji routera i w tym konkretnym przypadku zostały ustalone na podstawie najwyższego zdefiniowanego i aktywnego adresu IP.

Po wydaniu polecenia: show ip ospf database trzy wyróżnione wiersze zawierają identyfikatory RID z trzech ogłoszeń LSA. Dodatkowo dowiadujemy się że identyfikator routera R3 to adres 192.168.2.2

Aby powiązać pozostałe identyfikatory RID z odpowiednimi routerami możemy posłużyć się poleceniem: show ip ospf neighbor.

Zebrane w ten sposób informacje pozwolą nam na ustalenie wszystkich identyfikatorów routerów w naszej sieci. Tak więc po analizie wyników poleceń możemy stwierdzić, że routerom zostały przypisane identyfikatory RID jak na rysunku poniżej.

Rozwijając polecenie: show ip ospf database o identyfikator routera uzyskamy szczegółowe dane zawarte z ogłoszenia LSA danego routera. Ogólna składnia polecenia przybiera postać: show ip ospf database router <RID_routera> I tak po wydaniu komendy: show ip ospf database router 192.168.2.1 nakazującej wyświetlenie danych LSA routera R1, zaznaczone numerami fragmenty informują nas o sąsiadach routera R1, interfejsach na których ci sąsiedzi są osiągalni i dodatkowo koszcie łącza (pkt. 1 oraz pkt.2) Z danych zawartych w pkt.3 dowiadujemy się dodatkowo, że router R1 podłączony jest do sieci szczątkowej 172.16.0.0/24

Polecenie show ip ospf database router <RID_routera> wydajemy z uwzględnieniem kolejnych identyfikatorów RID.

Poniżej dane z ogłoszeń LSA routera R2

oraz dane z ogłoszeń routera R3

Uzyskane w ten sposób informacje dają nam obraz o koszcie wszystkich łączy w naszej topologii. Tak więc dane te zostały zebrane i naniesione na poniższy rysunek.

Porównanie danych zawartych na powyższym rysunku z np. tablicą routingu router R3 uświadamia nam dlaczego router R3 umieścił w tablicy routingu takie a nie inne trasy do sieci zdalnych. Obliczając koszty wszystkich możliwych tras (całe dwie możliwości) z punktu widzenia routera R3 do sieci 172.16.0.0/24 wiemy już dlaczego router R3 będzie pakiety wysyłał do routera R2 i dalej do routera R1 a nie jak by się mogło wydawać krótszą drogą bezpośrednio do routera R1. Po prostu metryka dla trasy R3-R2-R1 jest korzystniejsza i wynosi 1181 (390+781+10) niż metryka dla trasy R3-R1, która po zsumowaniu wszystkich kosztów łączy równa się 1572 (1562+10).

Jak już wiesz czytelniku relacja sąsiedzka nie zostanie utworzona gdy timery OSPF hello lub dead nie pasują do siebie. Aby zmienić wartość tych interwałów należy użyć poleceń (polecenia wydajemy w trybie konfiguracji interfejsu sieciowego):

• • timer pakietów hello: ip ospf hello-interval <sekundy>
  • timer uznania za nieczynny: ip ospf dead-interval <sekundy>

A więc sprawdźmy jak zmiana tych interwałów wpłynie na naszą sieć. Timer hello zmienimy na 5s (z domyślnych 10s) natomiast timer dead na 20s (z domyślnych 40s). Zmianę interwałów wykonamy na routerze R1. Jak widzimy poniżej routery R2 i R3 utworzyły z routerem R1 pełną relację sąsiedzką.

Na routerze R1 wykonujemy zmianę interwałów (na obu interfejsach).

Dokonaną korekcję możemy sprawdzić po wydaniu polecenia: show ip ospf interface <nazwa_interfejsu> (interfejs s0/0).

A także zmianę tą ukaże nam przechwycony ruch – komunikacja pomiędzy routerem R1 a R2. Na rysunku poniżej zostały przechwycone pakiety hello, po lewej pakiet przed zmianą natomiast po prawej pakiet hello po wprowadzonych poprawkach.

Po dokonanej zmianie relacje sąsiedzkie zostały zerwane. Zmiany te możemy zaobserwować po komunikatach – CLI interfejsu routera R1 oraz po sprawdzeniu stanu utworzonych relacji na routerach R2 oraz R3.

Ewentualny błąd niedopasowania parametrów hello możemy wykryć po włączeniu procesu debugowania tych pakietów. Debugowanie uwidoczni nam w postaci stosownej informacji niedopasowanie interwałów czasowych.

Najdotkliwszym skutkiem opisanej zmiany jest brak możliwości komunikacji z siecią za routerem R1, sieć ta zostaje usunięta z tablic routingu routera R2 oraz R3 (brak wpisu sieci 172.16.0.0/24, tablica routingu routera R3).

co w konsekwencji powoduje brak możliwości skomunikowania się z komputerem WindowsXP_1 (ping z hosta WindowsXP_2).

Jak widać po powyższym przykładzie zmiana interwałów czasowych jest możliwa lecz należy jej dokonywać z rozwagą bo zmiana ta dosyć poważnie wpływa na działanie sieci. Jeżeli już dokonujemy takowej zmiany to musimy ją wykonać na wszystkich routerach obsługujących dany obszar.

Protokół OSPF obsługuje trzy rodzaje uwierzytelnienia: brak uwierzytelnienia (domyślnie włączone), uwierzytelnienie na podstawie zwykłego hasła (metoda ta w literaturze również jest określana jako jawnotekstowa) oraz uwierzytelnienie z wykorzystaniem szyfrowania (algorytm MD5).

Uwierzytelnienie możemy konfigurować dwojako tj. odgórnie dla wszystkich interfejsów (w trybie konfiguracji protokołu routingu) oraz oddzielnie dla każdego interfejsu (w trybie konfiguracji danego interfejsu). Przy czym polecenie wydane w trybie interfejsu ma pierwszeństwo przed poleceniem wydanym w trybie konfiguracji protokołu routingu. Oznacza to, że jeśli skonfigurowano zarówno oba polecenia np. dla obszaru zdefiniowano uwierzytelnienie jawnotekstowe a dla interfejsu uwierzytelnienie MD5 to na konkretnym interfejsie obowiązującym będzie MD5.

Ok no to ćwiczenie aby pokazać różnicę załóżmy, że nasze uwierzytelnienie skonfigurujmy tak jak poniżej.

Przechodzimy do routera R1, oba interfejsy będą korzystać z uwierzytelnienia jawnotekstowego, więc polecenie włączające ten tryb uwierzytelnienia możemy wydać odgórnie w trybie konfiguracji protokołu OSPF. Aby włączyć uwierzytelnienie wydaj polecenie: area <numer_obszaru> authentication.

Wydanie polecenia zrywa relacje sąsiedzkie z routerem R2 oraz R3

Aby przywrócić relacje sąsiedzkie należy przypisać hasła oraz proces uwierzytelnienia skonfigurować na pozostałych routerach. Przyjmijmy, że dla uwierzytelnienia jawnotekstowego hasło przybierze postać ciscoopen natomiast dla MD5 ciscomd5

Hasła przypisujemy w trybie konfiguracji poszczególnego interfejsu. Router R1 połączony jest z routerem R2 za pomocą interfejsu s0/1 tak więc konfigurację hasła rozpoczniemy od tego interfejsu. Po przejściu do trybu interfejsu s0/1 i wydaniu polecenia: ip ospf authentication-key <hasło> (w naszym scenariuszu hasłem jest ciscoopen) jesteśmy poinformowani, że hasło może być zbudowane z maksymalnie 8 znaków i że nasze wpisane hasło zostało skrócone do takiego ciągu. Tak więc hasło nasze przyjmie postać: ciscoope.

Drugi interfejs s0/0 (połączenie router R1-R3) również ma korzystać z uwierzytelnienia opartego na zwykłym haśle tak więc jak powyżej ustalamy hasło: ciscoope lecz tym razem w trybie interfejsu s0/1.

Stan interfejsów możemy sprawdzić po wydaniu polecenia: show ip ospf interface <nazwa_interfejsu>. Wpis Simple password authentication enabled informuje nas o włączeniu uwierzytelnienia jawnotekstowego. Jak widać poniżej oba interfejsy korzystają z tego typu uwierzytelnienia.

Hasła możemy sprawdzić w konfiguracji bieżącej routera (zresztą również typ zastosowanego uwierzytelnienia jak i nazwy interfejsów biorących udział w całym procesie).

Hasła są przechowywane w formie jawnej, co jak wiemy nie jest zbyt dobrym pomysłem. Aby przynajmniej trochę podnieś próg bezpieczeństwa możemy hasła zaszyfrować za pomocą polecenia: service password-encryption. Polecenie przynajmniej uniemożliwi za naszych pleców postronnemu użytkownikowi zdobycie hasła.

Po skonfigurowaniu routera R1 przechodzimy do routera R2.

Rozpoczynamy od przejścia do trybu konfiguracji protokołu OSPF (pkt.1). Na routerze R2 odgórnie skonfigurujemy tryb uwierzytelnienia oparty na algorytmie MD5 by następnie zmodyfikować połączenie pomiędzy routerem R2 a routerem R1 tak by połączenie to korzystało z uwierzytelnienia opartego na znanym haśle. Po przejściu do trybu konfiguracji protokołu routingu, za pomocą polecenia: area <numer_obszaru>authentication message-digest ustawiamy uwierzytelnienie MD5 na wszystkich interfejsach routera (pkt.2). Po wywołaniu polecenia (pkt.3) relacja sąsiedzka z routerem R3 zostaje zerwana (tylko z R3 ponieważ z routerem R1 relacja została już zerwana wcześniej). Router R2 nie ma ustanowionych żadnych relacji sąsiedzkich (pkt. 4). Aby odbudować relację sąsiedzką z routerem R1 w trybie interfejsu s0/1 (pkt. 5) musimy skonfigurować uwierzytelnienie jawnotekstowe. W tym celu po przejściu do trybu konfiguracji interfejsu musimy wydać dwa polecenia: pierwsze z nich: ip ospf authentication (pkt. 6) włącza na interfejsie s0/1 tryb uwierzytelnienia opartego na znanym haśle natomiast drugie polecenie: ip ospf authentication-key ciscoope (pkt. 7) ustawia hasło. Po chwili relacja sąsiedzka z routerem R1 zostaje ustanowiona (pkt. 8). Jak widać po tym przykładzie polecenie włączające dany typ uwierzytelnienia wydane w trybie interfejsu ma pierwszeństwo przed poleceniem wydanym w trybie konfiguracji routingu.

Odbudowę relacji sąsiedzkiej możemy również skontrolować wydając polecenia: show ip ospf interface brief oraz show ip ospf neighbor na routerze R1. Jak widać poniżej wszystko jest OK.

Mamy skonfigurowaną jedną działającą relację sąsiedzką opartą na uwierzytelnieniu (połączenie router R1-R2), tak więc zajmijmy się połączeniem pomiędzy routerem R2 a R3. Pomiędzy tymi routerami ma być skonfigurowana relacja sąsiedzka oparta o MD5, interfejs s0/0 routera R2 działa już w tym trybie uwierzytelnienia (polecenie wydane w trybie konfiguracji protokołu OSPF) jedyne co pozostało do skonfigurowania to hasło. Hasło za pomocą polecenia: ip ospf message-digest-key <nr_klucza> md5 <hasło> ustalamy w trybie konfiguracji interfejsu.

Poszczególne interfejsy routera mogą zostać skonfigurowane do obsługi większej ilości kluczy lecz możliwość ta powinna być wykorzystywana tylko podczas zmiany kluczy.

Stan interfejsów oraz typ uwierzytelnienia możemy sprawdzić wydając polecenia: show ip ospf interface <nazwa_interfejsu>

oraz show running-config

Wpis Message digest authentication enabled w wyniku polecenia show ip ospf interface <nazwa_interfejsu> informuje o wykorzystaniu uwierzytelnienia MD5, natomiast zaznaczony obszar poniższego listeningu zwraca uwagę, że klucz oznaczony cyfrą 2 jest kluczem nowszym niż klucz 1 i że nadal są w sieci routery, które korzystają z starego klucza (specjalnie skonfigurowałem dodatkowy drugi klucz by pokazać iż jest to możliwe).

Ostatnim etapem jest konfiguracja routera R3. Interfejs s0/0 jest połączony z routerem R2 a więc na tym łączu skonfigurujemy uwierzytelnienie protokołu OSPF oparte o algorytm MD5. Po przejściu do trybu konfiguracji interfejsu za pomocą polecenia w pkt. 1 konfigurujemy hasło wykorzystane do uwierzytelnienia natomiast polecenie w pkt. 2 włącza samo uwierzytelnienie. Jak widać w pkt. 3 po przeprowadzonej konfiguracji router R3 odbudowuje relację sąsiedzką z routerem R2.

By odbudować relację sąsiedzką z routerem R1 pozostaje nam skonfigurować interfejs s0/1 routera R3. Tak więc po wydaniu polecenia: ip ospf authentication w trybie konfiguracji interfejsu włączamy uwierzytelnienie jawnotekstowe (pkt.1) natomiast poleceniem: ip ospf authentication-key ciscoope ustawiamy hasło wykorzystywane w procesie uwierzytelnienia (pkt.2) Relacja sąsiedzka z routerem R1 zostaje nawiązana na nowo (pkt.3).

Stan poszczególnych interfejsów tradycyjnie sprawdzimy wydając polecenie: show ip ospf interface <nazwa_interfejsu>.

Po skonfigurowaniu uwierzytelnienia wszystkie relacje sąsiedzkie zostały ponownie nawiązane (rysunek poniżej),

a tablice routingu wypełnione (poniżej tablica routingu routera R2)

Podsumowując temat uwierzytelnienia, polecenia włączające dany typ zebrano w tabeli poniżej:

Włączając uwierzytelnienie OSPF należy mieć na uwadze, że proces ten nie szyfruje nam pakietów generowanych przez protokół OSPF lecz jedynie chroni nas przed przetworzeniem pakietu wygenerowanego przez atakującego np. celem wprowadzenia zamieszania w tablicach routingu tak aby ruch sieciowy przekierować do atakującego (to tylko jeden z typów ataku).

Poniżej przykład przechwyconych dwóch pakietów hello – po lewej pakiet hello z włączonym uwierzytelnieniem jawnotekstowym po prawej zaś pakiet hello wykorzystujący algorytm MD5. To co pierwsze można zauważyć to to że w pierwszym przypadku hasło jest łatwe do odczytania gdyż przesyłane jest otwartym tekstem. W drugim zaś przypadku mamy do czynienia już z hashem hasła. Analiza wielu pakietów hello przekona nas, że hash ten zmienia się i nie ma wartości stałej. Dzieje się tak gdyż routery Cisco celem uniemożliwienia wykorzystania przechwyconego hasha, do wartości zdefiniowanego hasła dodają znacznik czasu („solenie” hasha). Proces ten podwyższa nam oczywiście bezpieczeństwo gdyż na podstawie przechwyconego hasha nie można ustalić pierwotnej wersji hasła lecz proces ten zwiększa możliwość wystąpienia ewentualnych problemów w przypadku stosowania urządzeń różnych producentów.

I na koniec ostanie zdanie, przechwycenie pakietów OSPF pomimo włączonego uwierzytelnienia niestety zdradzi nam topologię sieci, gdyż dane te w żaden sposób nie są chronione. By przynajmniej trochę podwyższyć poziom bezpieczeństwa można dodatkowo wyłączyć rozsyłanie pakietów OSPF na interfejsach których to pakiety te są zbędne. W naszym scenariuszu mamy 3 takie interfejsy, mowa tu o interfejsach ethernetowych każdego z routerów. Połączenia te wykorzystywane są do obsługi hostów pracujących w danej sieci, żaden dodatkowy router w tych podsieciach się nie znajduje a więc rozsyłanie komunikatów OSPF jest zbędne gdyż informacje te nie są w żaden sposób wykorzystywane a przechwycone przez atakującego zdradzają topologię naszej sieci a dodatkowo proces wysyłania pakietów obciąża router, zaś same pakiety zmniejszają niepotrzebnie dostępne pasmo.

Aby wyłączyć interfejs i tym samy zablokować możliwość wysyłania a także przetwarzania pakietów OSPF należy w trybie konfiguracji protokołu routingu wydać polecenie: passive-interface <interfejs> Na poniższym zrzucie wyłączono interfejs f0/0 routera R1.

Włączony proces debugowania wysyłania pakietów hello uwidacznia nam wprowadzoną zmianę. Przed wydaniem polecenia passive-interface jak widać proces OSPF z powodzeniem wysyła pakiety hello poprzez interfejs f0/0 wydanie polecenia zatrzymuje tę czynność, pakiety hello poprzez ten interfejs nie są już wysyłane.

Wpływ polecenia passive-interface na proces przebiegu procesu OSPF jest bardzo znaczący gdyż nieprawidłowo wydane polecenie np. pomylenie interfejsów może spowodować zaburzenie procesu routingu co w konsekwencji może doprowadzić do utraty łączności z sieciami zdalnymi.

Poniżej tablica routingu routera R1 i zaznaczona droga do sieci 10.0.0.0/24, po analizie tablicy stwierdzamy, że aby pakiety osiągnęły sieć muszą zostać wysłane na adres następnego skoku 192.168.0.2 (router R2) z interfejsu s0/1 Metryka sieci wynosi 74.

Przez pomyłkę interfejs s0/1 routera R1 za pomocą polecenia passive-interface został wyłączony z procesu OSPF.

Po wydaniu polecenia natychmiast zostaje zerwana relacja sąsiedzka z routerem R2 a co za tym idzie połączenie z routerem R2 musi zostać wyłączone z procesu routingu.

Po poinformowaniu wszystkich routerów na nowo zostają przebudowane tablice routingu tak aby uwzględnić zaistniałą zmianę. Łączność z siecią 10.0.0.0/24 nie została utracona lecz by pakiety mogły do tej sieci dotrzeć muszą zostać wysłane inna drogą. Ponowna analiza tablicy routingu routera R1 uwzględnia tą zmianę. Jak widać teraz by pakiety mogły swobodnie podróżować muszą zostać wysłane na adres następnego skoku 192.168.2.2 (router R3) z interfejsu s0/0 Metryka sieci wynosi 138.

W naszym scenariuszu wydanie polecenia nie poczyniło zbyt wielu szkód lecz nieumiejętne bądź nieprzemyślane zastosowanie może być przyczyną kłopotów.

Osobna kwestia, którą należy omówić jest dystrybucja tras, które prowadzą do sieci zdalnych lecz są pozyskiwane z innych źródeł niż protokół OSPF. Trasy do sieci zdalnych mogą być pozyskane dzięki protokołowi OSPF ale również mogą to być trasy statyczne wraz z trasą domyślną oraz trasy uzyskiwane z innych protokołów routingu dynamicznego, takich jak RIP czy EIGRP. Protokół OSPF posiada mechanizmy dzięki którym może przekazać informacje o sieciach zdalnych, które są ustalane za pomocą powyższych mechanizmów. Najlepiej zagadnienie tłumaczy przykład, tak więc takowy omówmy. Do naszej topologii dodajmy połączenie z ISP (dostawca Internetu). Połączenie te zestawione jest z routerem R2, interfejs Fa0/1 routera R2 ma przypisany adres IP 200.200.200.201 natomiast adres IP routera ISP to 200.200.200.202 Zmianę topologii obrazuje rysunek poniżej.

Jak widać poniżej trasa do sieci ISP znajduje się w tablicy routingu routera R2.

Chcemy by trasa łącząca router R2 z routerem ISP stała się trasą domyślną, tak by pakiety nie pasujące do wpisów tras zawartych już w tablicy routingu routera R2 zostały przekazane do ISP. Tak więc by tak się stało wydajemy polecenie: ip route 0.0.0.0 0.0.0.0 200.200.200.202 nakazujące przekazanie nie pasującego ruchu do routera ISP. Polecenie to tworzy trasę domyślną lub jak kto woli bramę ostatniej szansy. Konsekwencją wydania polecenia jest wpis w tablicy routingu routera R2.

Naszym zadaniem jest rozpropagowanie tak utworzonej trasy do innych routerów (router R1 oraz router R3) tak i by one mogły pakiety nie znajdujące odwzorowania w wpisach swoich tablic routingu przekazać poprzez trasę domyślną routera R2. Komendą nakazującą przekazanie informacji o utworzonej trasie domyślnej do innych routerów jest polecenie: default-information originate Polecenie wydajemy w trybie konfiguracji protokołu OSPF (oczywiście na routerze na którym takowa trasa istnieje).

Po wydaniu polecenia nakazującego przekazanie informacji o bramie ostatniej szansy do innych routerów nie pozostaje nam nic innego jak sprawdzenie efektu naszego działania. By przekonać się czy osiągnęliśmy cel, sprawdźmy tablice routingu sąsiadów routera R2.

Tablica routingu routera R1

oraz tablica routingu routera R3

Jak widać po powyższych zrzutach zarówno router R1 jak i R3 uzyskały informację o trasie domyślnej i dzięki temu routery te zyskały możliwość komunikacji z routerem ISP. Trasa domyślna dzięki protokołowi OSPF została rozpropagowana do innych routerów.

Kolejnym przypadkiem z jakim możemy się natknąć jest rozpowszechnienie informacji o sieciach statycznych.

W naszej sieci może zdarzyć się sytuacja w której połączenie z siecią zdalną zostało ustanowione za pomocą trasy statycznej a my informację o takiej trasie chcemy przekazać innym routerom tak i by one mogły komunikować się z daną siecią zdalną. Brzmi skomplikowanie? A więc przyjrzy się topologii poniżej. Do znanej nam już topologii dodano nowy router Static na którym utworzono interfejsy loopback symulujące łącza do danych sieci zdalnych. A zadaniem naszym będzie rozpropagowanie informacji o tych sieciach tak by każdy router w naszej topologii mógł z tymi sieciami prowadzić komunikację.

Poniższy zrzut tak dla przypomnienia tworzenia interfejsów wirtualnych typu loopback. Utworzone interfejsy symulują trzy sieci: sieć 192.168.100.0/24 (dostęp do sieci poprzez interfejs loopback 0 o adresie IP 192.168.100.1); sieć 172.16.100.0/24 (dostęp do sieci poprzez interfejs loopback 1 o adresie IP 172.16.100.1); sieć 10.0.100.0/24 (dostęp do sieci poprzez interfejs loopback 2 o adresie IP 10.0.100.1).

Po utworzeniu wszystkich interfejsów loopback informacja o sieciach reprezentujących dany interfejs zostaje wprowadzona do tablicy routingu routera Static.

Kolejnym krokiem jest utworzenie odpowiednich wpisów tras statycznych na routerze R3 tak by router ten uzyskał łączność z sieciami zdalnymi znajdującymi się za routerem Static.

Na routerze R3 zostają utworzone trzy trasy statyczne, wydane polecenia utworzenia poszczególnych tras znajdują odzwierciedlenie w tablicy routingu routera.

Jak widać poniżej router R3 ma łączność z każdym z interfejsów loopback.

Natomiast z poziomu routera R2 nie mamy możliwości prowadzenia komunikacji z sieciami zdalnymi reprezentowanymi przez interfejsy loopback. Tak więc będziemy chcieli to zmienić tak aby komunikacja ta była możliwa.

Aby router R3 dzięki wykorzystaniu protokołu OSPF mógł do innych routerów rozpropagować informację o swoich trasach statycznych należy w trybie konfiguracji protokołu routingu wydać polecenie: redistribute static

Po wydaniu polecenia sprawdźmy rezultaty. Tablica routingu routera R2 ujawnia nam tylko jeden wpis, który prowadzi do sieci 192.168.100.0/24 - a co z pozostałymi sieciami? Nie takiego obrotu spraw się spodziewaliśmy lecz efekt użytego polecenia jest jak najbardziej prawidłowy. Uważny czytelnik na rysunku powyżej ma pewno zauważył komunikat: Only classful networks will be redistributed, komunikat informuje nas o tym iż działanie polecenia: redistribute static jest ograniczone do przekazania informacjio trasach statycznych ale tylko tych, które spełniają warunek klasowości a z podanych trzech sieci tylko sieć 192.168.100.0/24 (klasa C) spełnia to założenie (dla sieci 172.16.100.0/24 założenie to było by spełnione gdyby maska sieci wynosiła /16 czyli 255.255.0.0 – klasa B, natomiast dla sieci 10.0.100.0/24 maska powinna wynosić /8 czyli 255.0.0.0 – klasa A).

Aby zmienić działanie routera i tym samym rozpropagować wszystkie sieci, nawet te które warunku klasowości nie spełniają należy do polecenia: redistribute static dodać dodatkowy człon subnets Dopiero tak zbudowane polecenie gwarantuje nam, że informacja o trasach statycznych niezależnie od użytej maski zostanie przekazana do innych routerów.

Wydanie polecenia: redistribute static subnets i ponowne sprawdzenie tablicy routingu routera R2 uwidacznia nam wpisy wszystkich tras prowadzących do sieci zdalnych znajdujących się za routerem Static a które to dostępne są dzięki trasom statycznym skonfigurowanym na routerze R3.

Ostatnim scenariuszem z jakim możemy się spotkać jest sytuacja w której to musimy przekazać informację o trasach prowadzących do sieci zdalnych lecz trasy te zostały uzyskane od innych protokołów routingu dynamicznego. Tradycyjnie już całą tą sytuację zobrazuje nam kolejny przykład. Podobnie jak to było w przypadku tras statycznych dodamy kolejny router o nazwie RIP na którym to skonfigurujemy interfejsy loopback symulujące nam sieci zdalne, lecz informację o tych sieciach przekażemy dalej za pomocą protokołu RIPv2. Zmianę topologii obrazuje nam poniższy rysunek.

Czynności nasze rozpoczynamy od utworzenia interfejsów wirtualnych loopback. Utworzone interfejsy symulują trzy sieci: sieć 192.168.200.0/24 (dostęp do sieci poprzez interfejs loopback 0 o adresie IP 192.168.200.1); sieć 172.16.200.0/24 (dostęp do sieci poprzez interfejs loopback 1 o adresie IP 172.16.200.1); sieć 10.0.200.0/24 (dostęp do sieci poprzez interfejs loopback 2 o adresie IP 10.0.200.1).

Kolejnym krokiem jest konfiguracja protokołu RIPv2 na routerze RIP , która to szerzej została opisana w wpisie: Co w sieci siedzi. Routing dynamiczny.

a także konfiguracja protokołu RIPv2 na routerze R1. Router R1 obsługuje dwa protokołu routingu.

Po poprawnym skonfigurowaniu obu routerów nie pozostaje nam nic innego jak sprawdzenie czy router R1 potrafi skomunikować się z nowymi sieciami zdalnymi. Analiza tablicy routingu routera R1 przekonuje nas o tym, że tak faktycznie jest, gdyż informacja o sieciach zdalnych dzięki protokołowi RIPv2 znajduje swoje odzwierciedlenie w tablicy routingu (jak można się przekonać i również na tym routerze znajdują się wpisy do sieci zdalnych z poprzedniego przykładu).

Redystrybucja tras zewnętrznych pochodzących od innych protokołów routingu dynamicznego przebiega bardzo podobnie jak w przypadku tras statycznych. Należy jedynie wydać polecenie: redistribute <nazwa_protokołu> subnets W naszym przypadku redystrybucji będą podlegać trasy uzyskane dzięki protokołowi RIP a więc polecenie przyjmie postać: redistribute rip subnets Gdybyśmy chcieli to samo działanie wykonać odnośnie protokołu EIGRP w składni polecenia musiałaby się również znaleźć informacja o numerze procesu protokołu EIGRP, tak więc przykładowe polecenie mogłoby wyglądać następująco: redistribute eigrp 16 subnets Podobnie jak w przypadku tras statycznych by rozesłać informację o sieciach nie spełniających warunek klasowości należy w poleceniu użyć członu subnets.

Po wykonaniu polecenia informacja o trasach, która do routera R1 dotarła dzięki protokołowi RIPv2 do pozostałych routerów zostanie już rozpropagowana dzięki protokołowi OSPF. Pewność, że tak się właśnie stało uzyskamy np. po sprawdzeniu tablicy routingu routera R2.

Trochę inna sytuacja przeprowadzania procesu routingu OSPF występuje w sieciach wielodostępowych - przypomnienie: sieć multicast, to taka sieć gdzie więcej niż dwa urządzenia współdzielą to samo medium np. w sieciach o topologii takiej jak na poniższym rysunku (korzystamy z technologii Ethernet).

Innymi przykładami sieci multicast są sieci typu Token Ring czy Frame Relay. By doprecyzować i trochę rozwiać wątpliwości - sam protokół OSPF wyróżnia pięć typów sieci tj. punkt-punkt (który już sobie omówiliśmy); wielodostępowe rozgłoszeniowe (sieć Ethernet, którą właśnie omawiamy); wielodostępowe nierozgłoszeniowe zwane też sieciami NBMA (sieć typu Frame Relay oraz Token Ring, tych omawiać nie będziemy gdyż Frame Relay w Polsce nadal stanowi egzotykę i poza nielicznymi przedsiębiorstwami nie stosowany, natomiast Token Ring stanowi już pieśń przeszłości); punkt-wielopunkt (sieć ATM oraz X.25 – tymi również nie będziemy się zajmować) oraz łącza wirtualne.

W sieciach wielodostępowych dokonywany jest wybór tzw. routera desygnowanego (ang. designated router, DR) a także zapasowego routera desygnowanego (ang. backup designated router, BDR).Zadaniem routera desygnowanego (DR) jest dystrybucja pakietów LSA (każdy router wysyła LSA tylko do niego no i do BDR) odpowiedzialnych za aktualizacje pozostałych routerów w momencie wystąpienia zmiany w topologii sieci. Natomiast zadaniem zapasowego routera desygnowanego (BDR) jest wykonanie tych samych czynności co routera DR, lecz w momencie wystąpienia jego awarii tak by szybko przejąć jego funkcje. Pozostałe routery nazywane są DROther-ami.

Mechanizm ten ma na celu wyeliminowanie olbrzymiego ruchu pakietów LSA, który jest generowany przy procesie tworzenia relacji sąsiedztw z innymi routerami (a w sieciach typu multicast ilość nawiązywanych relacji sąsiedzkich może być ogromna), zmianie w topologii sieci czy w momencie włączenia samego procesu OSPF. By lepiej zobrazować problem wielu przyległości posłużę się o to taką tabelą w której zebrałem ilość tworzonych przyległości z ilością routerów, jak widać wzrost ten jest wykładniczy i przy wzroście liczby routerów gwałtownie wrasta liczba tworzonych relacji sąsiedzkich.

Jak już wspomniałem wcześniej routery by poinformować sąsiadów o stanie swoich łączy, zalewowo wysyłają pakiety LSA, tak więc bez mechanizmu tworzenia routera DR ruch generowany przez pakiety LSA (lecz także pakiety potwierdzenia ACK) spowodowałoby nadmierne przeciążenie sieci. Tak więc wybór routera DR stanowi rozwiązanie powyższych problemów a tym samym router DR staje się, nazwijmy to - centrum dystrybucyjnym odpowiedzialnym za wysyłanie i odpieranie pakietów LSA. Wybór routera DR czy routera BDR w małych sieciach w których sprzęt jest pod względem wydajnościowym do siebie zbliżony możemy pozostawić przypadkowi (choć dobrą praktyką jest aby proces OSPF był realizowany na sprzęcie oferującym najlepsze osiągi), lecz w sieciach dużych na takie rozwiązanie już pozwolić sobie nie możemy i postawienie przed routerem zadania realizowania procesu OSPF powinno być wyborem świadomym i przemyślanym.

W procesie przypisywania funkcji danemu routerowi wykorzystywany jest tzw. identyfikator routera nazywany również identyfikatorem RID. Identyfikator ten wykorzystywany jest do unikatowej identyfikacji routera biorącego udział w procesie OSPF (identyfikator ten jest oczywiście również wykorzystywany w sieciach punkt-punkt lecz dopiero w sieciach wielodostępowych jest szczególnie ważny) i jest po prostu adresem IP. Proces elekcji routera do funkcji routera desygnowanego i zapasowego routera desygnowanego podlega następującym kryteriom (kryteria są ułożone według określonej kolejności w jakiej są stosowane):

1. identyfikator zdefiniowany za pomocą polecenia: router-id <adres_IP>,

2. identyfikator ustalany za pomocą najwyższego adresu przypisanego do interfejsu pętli zwrotnej (interfejs loopback) w stanie up/up – kryterium oczywiście stosowane w przypadku braku spełnienia pkt.1,

3. identyfikator ustalany za pomocą najwyższego adresu dowolnego interfejsu w stanie up/up nie będącego oczywiście adresem interfejsu pętli zwrotnej – kryterium stosowane w przypadku braku spełnienia pkt. 1 i pkt.2.

Tak więc routerem DR zostaje router z najwyższym identyfikatorem ustalonym według powyższych kryteriów natomiast routerem BDR drugi w kolejności router.

Router DR i BDR między sobą ustalają pełną (full) przyległość natomiast przyległość typu 2way jest ustalana z innymi DROtherami (DROthery nie wymieniają się pomiędzy sobą pakietami LSA a jedynie zachodzi wymiana pakietów hello).

Tak więc sprawdźmy czy przedstawione przeze mnie kryteria mają rację bytu i czy faktycznie proces elekcji przebiega w opisany wyżej sposób. Do przykładu wykorzystamy topologię przedstawioną na rysunku powyżej. Sprawdzenie adresów IP przypisanych do poszczególnych interfejsów wszystkich routerów przedstawia natomiast rysunek poniżej.

Proces routingu nie został jeszcze włączony co uwidacznia tablica routingu routera R1 w której to brak wpisów tras będących wynikiem działania protokołu OSPF.

Do każdego z 4 routerów zostaje przypisany identyfikator RID za pomocą polecenia: router-id <adres_IP> wydanego w trybie konfiguracji procesu routingu.

Dalsze polecenia związane z uruchomieniem procesu routingu opartego na protokole OSPF zostały wydane, proces OSPF zaczął działać (nastąpiła aktualizacja tablic routingu) a że mamy do czynienia z siecią wielodostępową został również wybrany router DR i BDR.

Sprawdźmy więc, które routery zostały wybrane do pełnienia tych funkcji. Aby przeprowadzić proces weryfikacji i sprawdzić, które routery pełnią funkcję routera DR i BDR na dowolnym routerze możemy wydać polecenie: show ip ospf neighbor Polecenie uwidoczni nam stany sasiadów wraz z identyfikatorem RID routera oraz ustanowionym typem przyległości. Po analizie poniższego zrzutu dowiadujemy się że router o identyfikatorze 4.4.4.4 został wydelegowany do pełnienia funkcji routera DR, natomiast router o identyfikatorze 3.3.3.3 został routerem BDR. Przy przypisywaniu funkcji routera zastosowane zostało kryterium pierwsze – identyfikatory RID wszystkim routerom zostały nadane za pomocą polecenia: router-id <adres_IP> a funkcja routera DR zostaje przypisana routerowi o najwyższym adresie (4.4.4.4), routerem BDR zostaje zaś router o kolejnym najwyższym zdefiniowanym adresie (3.3.3.3).

Kolejnym poleceniem, które pomoże nam w określeniu funkcji routera jest komenda: show ip ospf interface brief Polecenie pozwoli nam określić typ przyległości ustalonej na danym interfejsie. Po wydaniu polecenia przekonujemy się, że po stronie sieci 10.0.0.0/24 router jest DROtherem natomiast po stronie sieci 192.168.0.0/24 (sieć ta jest również siecią wielodostępową, bo przecież nic nie stoi na przeszkodzie by i w tej sieci znalazły się inne routery) router pełni funkcję routera DR.

Show ip ospf interface jest kolejnym, zresztą już znanym przez nas poleceniem pozwalającym na ustalenie stanu interfejsów procesu OSPF.

Tak więc wszystkie użyte polecenia i ich analiza doprowadza nas do wniosku, że poszczególne funkcje przypadły w udziale routerom:

Aby jeszcze lepiej zrozumieć proces elekcji routerów w sieciach wielodostępowych przeanalizujmy kolejny przykład. Topologia sieci nie ulega zmianie, tym razem rezygnujemy z polecenia: router-id <adres_IP> natomiast zostają skonfigurowane interfejsy pętli zwrotnej (loopback) według schematu przedstawionego poniżej.

Jak można zauważyć na zrzucie poniżej na każdym z routerów został utworzony interfejs Loopback 0 i do interfejsu został przydzielony odpowiedni adres IP.

Po skonfigurowaniu interfejsów loopback oraz uruchomieniu procesu routingu wydajemy znane nam już polecenia celem ustalenia funkcji poszczególnych routerów. Tak więc w pierwszej kolejności polecenie: show ip ospf neighbor

następnie polecenie: show ip ospf interface brief

i na końcu komendę: show ip ospf interface

Analiza informacji uzyskanych dzięki tym poleceniom przekonuje nas, że routerom zostały przypisane następujące funkcje:

W tym przypadku funkcja pełniona przez router została ustalona na podstawie kryterium 2 (do przydziału funkcji użyj interfejsów pętli zwrotnej), gdyż kryterium 1 nie miało zastosowania (brak użycia polecenia: router-id <adres_IP>).

Jak się pewnie domyślasz czytelniku w kolejnym przykładzie przydział funkcji routerom nastąpi na podstawie kryterium 3, które mówi, że routerem DR zostaje ten router, który ma przypisany najwyższy adres IP do swojego aktywnego interfejsu przy czym interfejs ten nie jest interfejsem loopback ani nie zostało użyte polecenie: router-id <adres_IP> Nasza topologia przedstawia się tak jak na poniższym rysunku.

Aby sprawdzić stan przypisanych funkcji routerom po raz kolejny wydajemy już znane nam polecenia, pierwszym wydanym poleceniem jest: show ip ospf neighbor

natomiast drugim: show ip ospf interface f0/0 sprawdzającym stan interfejsu f0/0 będącego częścią sieci 10.0.0.0/24

Jak widać po analizie powyższych zrzutów jednoznacznie możemy stwierdzić, że routerom zostały przypisane następujące role:

Po raz kolejny routerem DR zostaje router R4 natomiast routerem BDR router R3.

I ostatni przykład tu już mieszany, zależy nam na tym aby routerem DR został router R3 gdyż router ten w naszej sieci jest urządzeniem najszybszym. Aby osiągnąć nasz zamierzony cel na routerze tym skonfigurujemy interfejs loopback a na pozostałych nie. Konfiguracja urządzeń przedstawia się następująco:

Konfigurację zaczynamy od konfiguracji interfejsu loopback na routerze R3

By następnie włączyć proces OSPF. Po wydaniu poleceń: show ip ospf neighbor

oraz show ip ospf interface f0/0 i analizie danych, uzyskujemy pewność, że nasz cel został osiągnięty.

W myśl kryterium 2 wyboru funkcji routera, routerem DR zostaje router R3, gdyż tylko na nim jest skonfigurowany interfejs typu loopback natomiast routerem BDR zostaje router R4 gdyż jego aktywny interfejs o adresie IP 192.168.3.1 w myśl kryterium 3 jest wartością najwyższą. Tak więc funkcje routera przedstawiają się następująco:

I tak sobie myślę, że na tym etapie chciałbym zakończyć moje rozważania na temat protokołu OSPF. Oczywiście artykuł nie do końca wyczerpuje wątek lecz pozwól czytelniku iż w którymś kolejnym wpisie ponownie zajmę się protokołem OSPF lecz w ujęciu wielu obszarów.