oraz DR z BDR. Wówczas LSA przesyłane jest tylko do tych dwóch urządzeń
natomiast one przekazują te informacje dalej.
</p>
- </div>
- </body>
+ <h1 id="3.2.oneareaospfconfiguration">3.2. Konfiguracja jednoobszarowego OSPFv2</h1>
+ <p>
+ W poprzednim rodziale zapoznaliśmy się z działaniem dynamicznego
+ protokołu routingu, jakim jest OSPF w wersji 2. W tym rozdziale dowiemy
+ się w jaki sposób uruchomić instację OSPF na urządzeniach z systemem
+ IOS. Dla celów szkolenionych przyda nam się topologia utworzona w
+ Packet Tracerze. Topologia powinna składać się z kilku routerów. Za
+ pomocą interfejsów <em>loopback</em>, będziemy symulować obecność sieci
+ lokalnej oraz internetu. Topologia może wyglądać następująco:
+ </p>
+ <p style="width: 100%">
+ <img src="https://ftp.morketsmerke.org/img/ensa_ch_2_sh1.png" />
+ </p>
+ <p>
+ Uruchomienie OSPF w IOS jest czymś w rodzaju uruchomienia odrębnego
+ programu. Ponieważ musimy zdefiniować ID procesu. Jest to wartość
+ lokalna, ustawiana przez administratora. Pozwala ona urządzeniu
+ rozróżnić procesy (na routerach Cisco, można uruchomić wiele instancji
+ OSPF). ID procesu może przyjąć wartość od 1 do 65535. Rozbierzność w
+ identyfikatorach procesu nie wpływa na ustawienie przylegania. Sam
+ proces uruchomiamy w konfiguracji globalnej wydając poniższe polecenie:
+ </p>
+<pre class="code-block">
+R2(config)#router ospf 1
+R2(config-router)#?
+ area OSPF area parameters
+ auto-cost Calculate OSPF interface cost according to bandwidth
+ default-information Control distribution of default information
+ distance Define an administrative distance
+ exit Exit from routing protocol configuration mode
+ log-adjacency-changes Log changes in adjacency state
+ neighbor Specify a neighbor router
+ network Enable routing on an IP network
+ no Negate a command or set its defaults
+ passive-interface Suppress routing updates on an interface
+ redistribute Redistribute information from another routing protocol
+ router-id router-id for this OSPF process
+</pre>
+ <p>
+ Po uruchomieniu procesu, przechodzimy do konfiguracji protokołu. Za
+ pomocą znaku zapytania (<strong>?</strong>) możemy wyświetlić wszystkie
+ dostępne polecenia w trybie konfiguracji OSPF.
+ </p>
+ <p>
+ Jak pamiętamy z poprzedniego rozdziału ID routera w OSPF korzysta
+ formatu adresu IP. Nawet lepiej, wykorzystuje adresy które są
+ zdefiniowane na urządzeniu, w przypadku automatycznej nie podania
+ ID. Nie mniej jednak, należy pamiętać, że to nie są adres IP i
+ nie biorą one udziału w komunikacji. Identyfikator potrzebny w
+ stanie <em>Exchange</em> do ustalenia, który router jako pierwszy
+ wyśle komunikat DBD oraz od określania roli (DR/BDR) routera w
+ przypadku łączy wielodostępowych.
+ </p>
+ <p>
+ Algorytm wyboru identyfikatora przezentuje się w następujący sposób:
+ </p>
+ <ol>
+ <li>Jeśli identyfikator został jawnie skonfigurowany to wybierz
+ go jako identyfikator routera. Jeśli nie to patrz krok 2.</li>
+ <li>Jeśli skonfigurowano interfejs <em>loopback</em>, to użyj jego
+ adresu IPv4 jako identyfikatora routera. Jeśli nie to patrz krok 3.</li>
+ <li>Użyj najwyższego skonfigurowanego adresu IPv4 jako ID routera.</li>
+ </ol>
+ <p>
+ W przypadku jeśli skonfigurowano więcej niż jeden <em>loopback</em>, to
+ wówczas algorytm zachowuje się identycznie jak w kroku 3, tylko wobec
+ interfejsów pętli.
+ </p>
+ <p>
+ W systemach produkcyjnych, możemy skonfigurować sobie interfejs pętli,
+ aby jego adres został użyty jako ID routera w OSPF. W wykorzystywanej
+ tutaj topologii, interfejsy <em>loopback</em> są wykorzystywane więc
+ po uruchomieniu procesu OSPF na R2, przyją on o taki oto identyfikator:
+ </p>
+<pre class="code-block">
+R2#show ip protocols
+
+Routing Protocol is "ospf 1"
+ Outgoing update filter list for all interfaces is not set
+ Incoming update filter list for all interfaces is not set
+ Router ID 64.100.0.1
+ Number of areas in this router is 0. 0 normal 0 stub 0 nssa
+ Maximum path: 4
+ Routing for Networks:
+ Routing Information Sources:
+ Gateway Distance Last Update
+ Distance: (default is 110)
+</pre>
+ <p>
+ Chcąc jawnie zmienić ID routera, musimy przjeść do konfiguracji
+ procesu OSPF, następnie użyć polecenia
+ <code class="code-inline">router-id</code> i jako argument podać ID.
+ </p>
+<pre class="code-block">
+R2(config)#router ospf 1
+R2(config-router)#router-id 2.2.2.2
+R2(config-router)#exit
+R2(config)#do show ip proto
+
+Routing Protocol is "ospf 1"
+ Outgoing update filter list for all interfaces is not set
+ Incoming update filter list for all interfaces is not set
+ Router ID 2.2.2.2
+ Number of areas in this router is 0. 0 normal 0 stub 0 nssa
+ Maximum path: 4
+ Routing for Networks:
+ Routing Information Sources:
+ Gateway Distance Last Update
+ Distance: (default is 110)
+</pre>
+ <p>
+ W przypadku, gdy router bedzie mieć już jakieś relacje przygłości
+ ID nie zostatnie zmienione. Aby nasze zmiany miały skutek, musimy
+ z restartować proces OSPF. Dokonamy tego w trybie
+ <strong>uprzywilejowanym EXEC</strong>, wydając poniższe polecenie:
+ </p>
+<pre class="code-block">
+R2#clear ip ospf process
+Reset ALL OSPF processes? [no]: yes
+</pre>
+ <p>
+ Po wydaniu tego polecenia system zapyta się czy zrestartować wszyskie
+ procesy. Pyta dlatego, że nie podaliśmy ID procesu, nie mniej jednak
+ w Packet Tracerze jest nie zostało to zaimplementowane.
+ </p>
+ <p>
+ Starsze wersje IOS, nie posiadają polecenia
+ <code class="code-inline">router-id</code>. Zatem najlepszym sposobem
+ na ustawienie ID routera jest skonfigurowanie interfejsu <em>loopback</em>.
+ </p>
+ <h2 id="3.2.1.networksinospf">3.2.1. Sieci w OSPF</h2>
+ <p>
+ Sieci w OSPF możemy konfigurować na dwa sposoby pierwszy z nich jest
+ jest przypisanie sieci do procesu OSPF przy użyciu polecenia
+ <strong>network</strong>, trybu konfiguracji protokołu. Poniżej
+ znajduje się ogólna składania tego polecenia.
+ </p>
+<pre class="code-block">
+R2(config-router)# network adres-sieci maska-blankietowa area id-obszaru
+</pre>
+ <p>
+ Kombinacja adres sieci, maska blankietowa służy uruchomieniu OSPF na
+ interfejsach. Natomiast id-obszaru wskazuje numer obszaru, w którym
+ dana sieć ma być rozgłaszana. W przypadku konfiguracji
+ jednoobszarowej, na wszystkich routera powinien być ustawiony ten sam
+ identyfikator obszaru. Dobrą praktyką jest ustawienie obszaru o
+ ID 0.
+ </p>
+ <p>
+ Maska blankietowa (<em>wildcard mask</em>) jest odwrotnością,
+ klasycznej maski podsieci. Jak
+ w przypadku klasycznej maski, wartości binarnej 1 na masce oznaczały
+ dopasowanie bitu adresu, a binarne 0 jego brak tak w przypadku maski
+ blankietowej: binarne 0 oznaczają dopasowanie odpowiedniej wartości
+ bitu w adresie, a jeden zignorowanie wartości tego bitu w adresie.
+ Maskę blankietową najlepiej utworzyć porzez odjęcie od pełnej maski
+ 32-bitowej - 255.255.255.255, maski naszej sieci. Na przykład:
+ </p>
+<pre class="code-block">
+ 255.255.255.255
+- 255.255.255.252
+-----------------
+ 0. 0. 0. 3
+</pre>
+ <p>
+ Maską blankietową dla maski podsieci /30 jest 0.0.0.3.
+ </p>
+ <p>
+ Teraz znając wszysktie części składni polecenia <em>network</em> możemy
+ przejść do jego konfiguracji.
+ </p>
+<pre class="code-block">
+R1(config)#router ospf 1
+R1(config-router)#network 10.1.1.4 0.0.0.3 area 0
+R1(config-router)#network 10.1.1.12 0.0.0.3 area 0
+R1(config-router)#network 10.10.1.0 0.0.0.255 area 0
+</pre>
+ <p>
+ Inną metodą na wykorzystanie polecenia jest <em>network</em> jest
+ podanie zamiast adresu sieci, adresu interfejsu oraz mask 0.0.0.0.
+ Uruchomi to proces na tym interfejsach i zacznie rozgłaszać sieci,
+ które są dostępne na tych interfejsach.
+ </p>
+<pre class="code-block">
+R1(config)#router ospf 1
+R1(config-router)#network 10.1.1.5 0.0.0.0 area 0
+R1(config-router)#network 10.1.1.14 0.0.0.0 area 0
+R1(config-router)#network 10.10.1.1 0.0.0.0 area 0
+</pre>
+ <p>
+ Drugim sposobem na rozgłaszanie sieci przez OSPF jest skonfigurowanie
+ tego bezpośrednio na interfejsie. Zanim do tego przejedziemy musimy,
+ wycofać uprzednio wprowadzone polecenia
+ <code class="code-inline">network</code>.
+ </p>
+<pre class="code-block">
+R1(config)#router ospf 1
+R1(config-router)#no network 10.1.1.4 0.0.0.3 area 0
+R1(config-router)#no network 10.1.1.12 0.0.0.3 area 0
+R1(config-router)#no network 10.1.1.12 0.0.0.3 area 0
+R1(config-router)#exit
+R1(config)#int g0/0
+R1(config-if)# ip ospf 1 area 0
+R1(config-if)#int g0/1
+R1(config-if)# ip ospf 1 area 0
+R1(config-if)#int lo0
+R1(config-if)# ip ospf 1 area 0
+</pre>
+ <p>
+ Komunikty OSPF powinny być wysyłane wyłącznie na interfejsach, do
+ których podłączone są inne routery z włączonym OSPF. Domyślnie jednak
+ są one wysyłane przez wszystkie interfejsy, na których został
+ uruchomiony ten protokół, w tym i sieci LAN, tutaj symulowanej za
+ pomocą <em>loopback</em>-a. Takie działanie nie jest za bardzo
+ pożądane, z kilku powodów:
+ </p>
+ <ul>
+ <li><strong>Nieefektywne wykorzystanie pasa</strong> - poprzez
+ przesyłanie nie potrzebnych komunikatów.</li>
+ <li><strong>Nieefektywny wykorzystanie zasobów</strong> - każdy z
+ hostów w sieci obiera częśc tych komunikatów, następnie musi je
+ przetworzyć, a następnie odrzucić.</li>
+ <li><strong>Zwiększone ryzko bezpieczeństwa</strong> - ruch OSPF bez
+ dodatkowych mechanizmów można przechwycić za pomocą takich narzędzi
+ jak <em>Wireshark</em> i następnie wysłać fałszywą aktualizację
+ ruchu i kierować go gdzie to tylko możliwe.</li>
+ </ul>
+ <p>
+ Zapobieganiu tego rodzaju niedogodnościom służy mechanizm interfejsu
+ pasywnego. Jest to rodzaj konfiguracji, w której wskazujemy interfejs
+ pasywny i ograniczamy wysyłanie komunikatów OSPF przez niego, przyczym
+ pozostaje on częścią obszaru, tj. komunikaty na temat jego sieci dalej
+ będą wysyłane do innych routerów. Konfiguracja pasywnego interfejsu
+ znajduje się poniżej.
+ </p>
+<pre class="code-block">
+R1(config)#router ospf 1
+R1(config-router)#passive-interface lo0
+R1(config-router)#exit
+</pre>
+ <p>
+ Po uzyskaniu zbierzności OSPF, jeśli przyjrzymy się tablicy routingu
+ to trasy do sieci reprezentowanych przez interfejsy <em>loopback</em>.
+ Sa trasami hostów, a nie trasami do sieci. Jest domyślne działanie.
+ Jeśli miały by być one trasami sieci, to na interfejsie pętli należy
+ wydać poniższe polecenie.
+ </p>
+<pre class="code-block">
+R1(config-if)# interface Loopback 0
+R1(config-if)# ip ospf network point-to-point
+</pre>
+ <p>
+ Wówczas ten interfejs będzie traktowany jako połączenie punkt-punkt.
+ I teraz będzie rozgłaszana trasa to sieci interfejsu pętli.
+ </p>
+ <h3 id="3.2.1.pka">Zadanie praktyczne - Packet Tracer</h3>
+ <p>
+ <a href="">Konfiguracja OSPFv2 punkt-punkt - scenariusz</a><br />
+ <a href="">Konfiguracja OSPFv2 punkt-punkt - zadanie</a>
+ </p>
+ <h2 id="3.2.2.multiaccessospfnetworks">3.2.2. Wielodostępowe sieci OSPF</h2>
+ <p>
+ Jak pamiętamy, jeśli skonfigurujemy OSPF na łączu wielodostępowym
+ to wówczas routery ustalają między sobą rolę, aby zapewnić jak
+ najmniejszy narzut OSPF na urządzenia.
+ </p>
+ <p>
+ Aby sprawdzić rolę routera możemy odpytać bazę relacji przyległości:
+ </p>
+<pre class="code-block">
+R1#sh ip ospf neigh
+
+
+Neighbor ID Pri State Dead Time Address Interface
+3.3.3.3 1 FULL/DR 00:00:31 10.1.1.13 GigabitEthernet0/1
+2.2.2.2 1 FULL/DR 00:00:34 10.1.1.6 GigabitEthernet0/0
+</pre>
+
+ <p>
+ Na podstawie kolumn <code class="code-inline">State</code> możemy
+ stwierdzić, że <code class="code-inline">R1</code> jest w pełnej
+ zbieżności OSPF <code class="code-inline">FULL</code> oraz jest
+ zapasowym routerem desygnowanym jeśli role obu sąsiadów to
+ <code class="code-inline">DR</code>. Innym stanem jaki możemy
+ spotkać jest <em>2-WAY/DROTHER</em>, oznacza on, że routery są
+ w stanie uzyskiwania zbieżności i jeszcze nie mają określonych ról.
+ </p>
+ <p>
+ Oczywiście możliwy jest wpływ na określanie ról routerów przy łączach
+ wielodostępowych. Możemy swobodnie manipulować priorytetem OSPF.
+ Dzięki czemy możemy jasno określić jakie urządzenie ma pełnić jaką
+ rolę. Aby zmienić priorytet w konfiguracji interfejsu wydajemy
+ poniższe polecenie:
+ </p>
+<pre class="code-block">
+R1(config)#int g0/0
+R1(config-if)#ip ospf priority 200
+<pre>
+ <p>
+ Po zmianie priorytetu musimy zresetować proces OSPF.
+ </p>
+ <h3 id="3.2.2.pka">Zadanie praktycznie - Packet Tracer</h3>
+ <p>
+ <a href="">Określanie DR i BDR - scenariusz</a><br />
+ <a href="">Określanie DR i BDR - cenariusz</a>
+ </p>
+ <h2 id="3.2.2.modifyingoneareaospfv2">3.2.2. Modyfikowanie jednoobszarowego OSPFv2</h2>
+ <p>
+ Routery na podstawie metryki zapisanej w trasie, w tablicy routingu
+ dokonują wybory najlepszej ścieżki. W przypadku OSPF to metryką jest
+ koszt obliczony poprzez iloraz
+ <strong>referencyjne szerokości pasma</strong> przez
+ <strong>szerokość pasma interfejsu</strong>. Te wartości wyrażone
+ są w bitach na sekundę. Domyślną referencyjną szerokością pasma
+ jest 100,000,000 b/s. To jeśli przeskalujemy sobie tę wartość na
+ Mb. To wówczas wynik będzie = 100Mb/s, ze zwględu na to, że jest
+ iloraz - metryka dla łączy 100Mb/s będzie równa 1. Dodatkowo te
+ obliczenia są całkowite, więc łącza gigabitowe oraz 10-cio gigabitowe
+ będą mieć tę samą metrykę. Więc ze względu na rozwijające się
+ umożliwiono zmianę referencyjnej szerokości pasma.
+ </p>
+ <p>
+ Aby zmienić wartość refencyjną szerokości pasma,
+ <strong>na wszystkich</strong> routerach w trybie konfiguracji
+ protokołu OSPF wydajemy następujące polecenie
+ </p>
+<pre class="code-block">
+Router(config-router)# auto-cost reference-bandwidth Mbps
+</pre>
+ <p>
+ Zamiast <code class="code-inline">Mbps</code> podajemy wartość
+ referencyjną w Mb. W zależności od naszej infrastruktury, myślę że
+ można spokojnie ustawić 10Gb, tj. 10000Mb.
+ </p>
+ <p>
+ Inna wartością jaką możemy manipulować, aby wpłynąć na wybór
+ najlepszej trasy przez OSPF jest sam koszt ścieżki. Dokonać tego
+ możemy za pomocą poniższego polecenie wydane w konfiguracji
+ interfejsu. Uwaga, należy pamiętać, aby ustawić również taki sam
+ koszt po drugiej stronie ścieżki.
+ </p>
+<pre class="code-block">
+R1(config)# interface g0/1
+R1(config-if)# ip ospf cost 30
+R1(config-if)# interface lo0
+R1(config-if)# ip ospf cost 10
+R1(config-if)# end
+</pre>
+ <p>
+ Częstotliwość wysyłania pakietów <em>Hello</em> oraz czas oczekiwania
+ na nie <em>Dead</em>, są kolejnymi cechami protokołu OSPF, na który
+ my jako administratorzy możemy wpłynąć. Za pomocą polecenia:
+ </p>
+<pre class="code-block">
+R2#show ip ospf int g0/0
+...
+ Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
+</pre>
+ <p>
+ Możemy sprawdzić jak została ustawiona częstotliwość pakietów
+ <em>Hello</em> oraz ustawiony czas oczekiwania <em>Dead</em>.
+ Dodatkowo czas oczekiwania <em>Dead</em> występuje w innym poleceniu
+ </p>
+<pre class="code-block">
+R2#show ip ospf neigh
+
+
+Neighbor ID Pri State Dead Time Address Interface
+1.1.1.1 1 FULL/BDR 00:00:30 10.1.1.5 GigabitEthernet0/0
+3.3.3.3 1 FULL/BDR 00:00:30 10.1.1.10 GigabitEthernet0/1
+R2#show ip ospf neigh
+
+
+Neighbor ID Pri State Dead Time Address Interface
+1.1.1.1 1 FULL/BDR 00:00:39 10.1.1.5 GigabitEthernet0/0
+3.3.3.3 1 FULL/BDR 00:00:39 10.1.1.10 GigabitEthernet0/1
+</pre>
+ <p>
+ Tutaj czas oczekiwania został przedstawiony w kolumnie
+ <code class="code-inline">Dead Time</code> w postaci licznika, który
+ odlicza w dół do 0,
+ każdorazowe nadejście pakietu <em>Hello</em> go restartuje
+ </p>
+ <p>
+ Modyfikacji wyżej wymienionych wartości możemy dokonać w konfiguracji
+ interfejsu. <strong>Na obu routerach te wartości muszą być takie same
+ inaczej nie dojdzie do relacji przyległości.</strong>.
+ </p>
+<pre class="code-block">
+R1(config-if)# ip ospf hello-interval S
+R1(config-if)# ip ospf dead-interval S
+</pre>
+ <p>
+ Gdzie <code class="code-inline">S</code>, to liczba sekund. Te
+ wartości domyślnie są oparte o dobre praktyki. Nie ma potrzeby ich
+ zmieniać nie mniej jednak istnieje taka możliwość i została ona tutaj
+ przedstawiona.
+ </p>
+ <h3 id="3.2.3.pka">Zadanie praktyczne - Packet Tracer</h3>
+ <p>
+ <a href="">Modyfikowanie jednoobszarowego OSPFv2 - scenariusz</a><br />
+ <a href="">Modyfikowanie jednoobszarowego OSPFv2 - zadanie</a>
+ </p>
+ <h2 id="3.2.4.propagatedefaultrouteinospf">3.2.4. Propagowanie tras domyślnych w OSPF.</h2>
+ <p>
+ Protokół OSPF daje nam możliwość możliwość rozpropagowania tras
+ domyślnych z jednego routera na pozostałe w danym obszarze. Służy
+ do tego poniższe polecenie wydane w konfiguracji protokołu OSPF.
+ </p>
+<pre class="code-block">
+R2(config)#ip route 0.0.0.0 0.0.0.0 lo1
+%Default route without gateway, if not a point-to-point interface, may impact performance
+R2(config)#
+R2(config)#route ospf 1
+R2(config-router)#default-information originate
+</pre>
+ <p>
+ Aby sprawdzić czy nasza trasa się rozpropagowała, należy wyświetlić
+ tablicę routingu innego routera:
+ </p>
+<pre class="code-block">
+R1#show ip route
+...
+Gateway of last resort is 10.1.1.6 to network 0.0.0.0
+...
+O*E2 0.0.0.0/0 [110/1] via 10.1.1.6, 00:04:14, GigabitEthernet0/0
+<pre>
+ <p>
+ Tak przekazaną trasę IOS traktuje jako zewnętrzną trasę OSPF typu 2.
+ </p>
+ <h3 id="3.2.4.pka">Zadanie praktyczne - Packet Tracer</h3>
+ <p>
+ <a href="">Propagowanie trasy domyślnej w OSPFv2 - scenariusz</a><br />
+ <a href="">Propagowanie trasy domyślnej w OSPFv2 - zadanie</a><br />
+ </p>
+ <h2 id="3.2.5.verifyingoneareaospfv2">3.2.5. Weryfikowanie jednoobszarowego OSPFv2</h2>
+ <p>
+ W celu zweryfikowania konfiguracji OSPFv2 na naszych urządzeniach
+ możemy posłużyć się następującymi poleceniami:
+ </p>
+ <ul>
+ <li><code class="code-inline">show ip ospf neighbor</code> -
+ weryfikacja sąsiadów OSPF.</li>
+ <li><code class="code-inline">show ip protocols</code> -
+ weryfikacja ustawień protokołu OSPF.</li>
+ <li><code class="code-inline">show ip ospf</code> - weryfikacja
+ procesu OSPF.</li>
+ <li><code class="code-inline">show ip ospf interface</code> -
+ weryfikacja ustawień interfejsu OSPF.</li>
+ </ul>
+ <p>
+ Powyższe polecenia mogą pomóc nam również w rozwiązywaniu problemów
+ konfiguracją OSPF.
+ </p>
+ <h3 id="3.2.5.pka">Zadanie praktyczne - Packet Tracer</h3>
+ <p>
+ <a href="">Weryfikowanie jednoobszarowego OSPFv2 - scenariusz</a><br />
+ <a href="">Weryfikowanie jednoobszarowego OSPFv2 - zadanie</a>
+ </p>
+ <h2 id="3.2.summary">Podsumowanie</h2>
+ <p>
+ W tym rozdziale przekonaliśmy się jak pomocne mogą być dynamiczne
+ protokoły routingu. Poznaliśmy metody konfiguracji protokołu,
+ konfiguracji jego funkcji, dzięki czemu dowiedzieliśmy się, że możemy
+ dostoswać część jego aspektów, następnie zapoznaliśmy się z
+ propagacją tras domyślnych, a na koniec poznaliśmy serię poleceń,
+ która pozwoli nam zweryfikować działanie OSPF i rozwiązać ewentualne
+ problemy.
+ </p>
+ </div>
+ </body>
</html>
projects / mmdev.git / commitdiff