Home Technologie siecioweRouting & Switching 5 rzeczy w OSPF, o których mogłeś nie wiedzieć
5 rzeczy w ospf o ktorych mogles nie wiedziec

5 rzeczy w OSPF, o których mogłeś nie wiedzieć

Rafał Rudewicz

OSPF jest najbardziej skomplikowanym protokołem routingu. Pokuszę się o stwierdzenie, że jest nawet bardziej skomplikowany od BGP. Obsługuje 5 różnych rodzajów topologii fizycznych oraz 6 rodzajów obszarów. Posiada ponad 10 różnych pakietów LSA oraz prawdziwe zatrzęsienie opcji konfiguracyjnych. 

Nie zrozum mnie źle, OSPF na podstawowym poziomie jest protokołem bardzo łatwym we wdrożeniu. Diabeł jak zwykle tkwi w szczegółach, kiedy mamy specyficzne wymagania co do jego zachowania.

Omówmy 5 nie do końca oczywistych przypadków zachowania i konfiguracji OSPF-a.

Adresy loopback są rozgłaszane jako /32

Zdarza się, że potrzebujemy zaadresowanać interfejs loopback z maską inną niż /32. Dzieje się tak na przykład gdy chcemy mieć pewność, że dana podsieć będzie zawsze widoczna w tablicy routingu. Założenia co do zachowania takich portów jest jednak nieco innew OSPF.

Zgodnie z RFC 2328 adres interfejsu Loopback powinien być rozgłoszony jako Typ 3 (stub network),  maska ustawiona jako 0xffffff (trasa do hosta), a koszt wyniosi 0.

Tyle teorii, sprawdźmy, jak wygląda to w praktyce. Skonfigurujmy 2 bezpośrednio ze sobą połączone routery.

R1#show run interface Loopback0 ip address 1.1.1.1 255.255.255.0 ! interface GigabitEthernet 0/0 ip address 10.0.0.1 255.255.255.0 ! router ospf 1 router-id 1.1.1.1 network 1.1.1.0 0.0.0.255 area 0 network 10.0.0.0 0.0.0.255 area 0
R2#show run interface Loopback0 ip address 2.2.2.2 255.255.255.0 ! interface GigabitEthernet 0/0 ip address 10.0.0.2 255.255.255.0 ! router ospf 1 router-id 2.2.2.2 network 2.2.2.0 0.0.0.255 area 0 network 10.0.0.0 0.0.0.255 area 0 !

Jak widać, w konfiguracji wszystko się zgadza z założeniami. Routery R1 i R2 mają interfejsy Loopback zaadresowane z maską /24. 

Sprawdźmy więc, jak wygląda tablica routingu oraz jakie trasy otrzymujemy od sąsiada.

R2#show ip route  1.0.0.0/32 is subnetted, 1 subnets O 1.1.1.1/32 [110/2] via 10.0.0.1, 00:17:48, GigabitEthernet0/0 2.0.0.0/8 is variably subnetted, 2 subnets, 2 masks C 2.2.2.0/24 is directly connected, Loopback0 L 2.2.2.2/32 is directly connected, Loopback0 10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks C 10.0.0.0/24 is directly connected, GigabitEthernet0/0 L 10.0.0.2/32 is directly connected, GigabitEthernet0/0 R2#show ip ospf database router  OSPF Router with ID (2.2.2.2) (Process ID 1) Router Link States (Area 0) LS age: 1249 Options: (No TOS-capability, DC) LS Type: Router Links Link State ID: 2.2.2.2 Advertising Router: 2.2.2.2 LS Seq Number: 80000003 Checksum: 0x050e Length: 48 Number of Links: 2  Link connected to: a Stub Network (Link ID) Network/subnet number: 2.2.2.2 (Link Data) Network Mask: 255.255.255.255 Number of TOS metrics: 0 TOS 0 Metrics: 1 Link connected to: a Transit Network (Link ID) Designated Router address: 10.0.0.1 (Link Data) Router Interface address: 10.0.0.2 Number of TOS metrics: 0 TOS 0 Metrics: 1 LS age: 1249 Options: (No TOS-capability, DC) LS Type: Router Links Link State ID: 1.1.1.1 Advertising Router: 1.1.1.1 LS Seq Number: 80000003 Checksum: 0x150b Length: 48 Number of Links: 2 Link connected to: a Stub Network (Link ID) Network/subnet number: 1.1.1.1 (Link Data) Network Mask: 255.255.255.255 Number of TOS metrics: 0 TOS 0 Metrics: 1

Jak widać nasze adresy loopback zostały rozgłoszone zgodnie z wytycznymi z RFC, jako adresy hostów z maską /32. Jak więc zmienić to zachowanie na pożądane? Rozwiązanie problemu jest bardzo proste. Wystarczy zmienić typ sieci (network type) interfejsu Loopback na point-to-point.

R1#show run interface Loopback0 ip address 1.1.1.1 255.255.255.0 ip ospf network point-to-point
R2#show ip route  1.0.0.0/24 is subnetted, 1 subnets O 1.1.1.0/24 [110/2] via 10.0.0.1, 00:17:48, GigabitEthernet0/0 R2#show ip ospf database router  Link connected to: a Stub Network (Link ID) Network/subnet number: 1.1.1.0 (Link Data) Network Mask: 255.255.255.0 Number of TOS metrics: 0 TOS 0 Metrics: 1

Polecenie Network nie rozgłasza sieci

Polecenie network w konfiguracji OSPF jest jednym z najbardziej mylących, jakie znam. Każdy, nawet początkujący sieciowiec wie, że jeśli chce rozgłaszać sieć w OSPF, musi ją redystrybuować z innego protokołu lub dodać poleceniem network.

Jednak to zdanie jest jedynie w połowie prawdziwe. Polecenie network nie określa jakie sieci mają być rozgłaszane. To polecenie dodaje interfejsy do procesu OSPF, których adres mieści się w podanym zakresie. Dopiero z tak aktywowanego interfejsu, brana jest informacja, jakie sieci powinny być rozgłaszane.

Spójrzmy na prosty przykład składający się z 3 routerów, które pracują w jednym obszarze. Konfiguracja nie jest skomplikowana, zwróć jednak uwagę, że użyłem różnych wariantów polecenia network.

Działanie polecenia network na przykładzie 3 routerów
R1#show run interface GigabitEthernet0/0 ip address 10.10.1.1 255.255.255.0 ! interface GigabitEthernet0/1 ip address 10.100.0.1 255.255.0.0 ! router ospf 1 router-id 1.1.1.1 network 10.0.0.0 0.255.255.255 area 0
R2#show run interface GigabitEthernet0/0 ip address 10.10.1.2 255.255.255.0 ! interface GigabitEthernet0/1 ip address 192.168.2.2 255.255.255.0 ! router ospf 1 router-id 2.2.2.2 network 10.10.1.2 0.0.0.0 area 0 network 192.168.2.0 0.0.0.255 area 0
R3#show run interface GigabitEthernet0/0 ip address 172.16.0.1 255.255.255.0 ! interface GigabitEthernet0/1 ip address 192.168.2.3 255.255.255.0 ! router ospf 1 router-id 3.3.3.3 network 192.168.2.3 0.0.0.0 area 0 network 172.16.0.1 0.0.0.0 area 0
R2#show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 1.1.1.1 1 FULL/BDR 00:00:32 10.10.1.1 GigabitEthernet0/0 3.3.3.3 1 FULL/DR 00:00:35 192.168.2.3 GigabitEthernet0/1 R2#show ip route 10.0.0.0/8 is variably subnetted, 3 subnets, 3 masks C 10.10.1.0/24 is directly connected, GigabitEthernet0/0 L 10.10.1.2/32 is directly connected, GigabitEthernet0/0 O 10.100.0.0/16 [110/2] via 10.10.1.1, 00:23:34, GigabitEthernet0/0 172.16.0.0/24 is subnetted, 1 subnets O 172.16.0.0/24 [110/2] via 192.168.2.3, 00:30:06, GigabitEthernet0/1 192.168.2.0/24 is variably subnetted, 2 subnets, 2 masks C 192.168.2.0/24 is directly connected, GigabitEthernet0/1 L 192.168.2.2/32 is directly connected, GigabitEthernet0/1

Jak widać, sąsiedztwo pomiędzy routerami jest nawiązane poprawne. Sieci zostały rozgłoszone z poprawnymi maskami.

Proces ID ma znaczenie

W EIGRP podobnie jak w BGP numer procesu określa AS, do którego należy router. Na podstawie tej informacji urządzenia wiedzą, czy należą do tego samego obszaru, czy nie. W OSPF jest inaczej. Możemy z powodzeniem korzystać na jednym routerze z procesu 1 i nawiązać sąsiedztwo z innym posługującym się procesem 100 w ramach jednej arei. Przynależność do obszaru w OSPF jest definiowana poprzez przypisanie poleceniem network x.x.x.x x.x.x.x  area x

Skoro przed chwilą ustaliliśmy, że możemy używać różnych numerów procesów i wszystko będzie działać, dlaczego twierdzę, że proces-id ma znaczenie?

W OSPF mamy parametr, który nazywa się domain ID. Podobnie jak nieskonfigurowany parametr router-id jest domyślnie brany z interfejsów, tak domyślnie domain-id jest przepisanym numerem procesu OSPF.

Do czego jest stosowane domain-id, dowiesz się z następnego punktu.

Superbackbone

OSPF jest protokołem hierarchicznym. Posiada obszar 0 zwanym backbone oraz obszary do niego przyłączone. Bezpośrednia komunikacja pomiędzy obszarami nie jest możliwa, cały ruch musi przechodzić przez nasz szkielet.

Specyficznym przypadkiem jest sytuacja kiedy mamy wykupioną usługę MPLS L3VPN i rozgłaszamy do naszego dostawcy trasy za pomocą OSPF-a. Wtedy z naszego punktu widzenia sieć ISP jest wirtualnym routerem, do którego rozgłaszamy nasze sieci LAN i następnie te rozgłoszone prefixy są dostępne w pozostałych lokacjach. 

Pomówmy chwilę, jak realizowana jest usługa przekazywania tras pomiędzy obszarami przez ISP. Ponieważ utrzymanie tysięcy różnych instancji OSPF w sieci jest niemożliwe, wszystkie otrzymane trasy są redystrybuowane do MP-BGP i następnie ponownie przekazywane do OSPF. Z tego powodu trasy z jednego obszaru są widoczne w drugim jako external. Co jednak kiedy taki stan nas niezadowala i chcemy widzieć wszystkie nasze prefixy z różnych lokacji w ramach jednej instancji OSPF?

Do tego co jest naszemu dostawcy potrzebna odpowiednia konfiguracja domain-id.

Superbackbone w OSPF

Jeżeli na routerach brzegowych ISP wartości domain-id będą identyczne mówimy o superbackbone. Trasy przekazywane z MP-BGP z tego obszaru do naszego obszaru 0 będą traktowane jako interarea, a nie jako zewnętrzne.

Router-ID musi być identyczny jak w BGP

Kiedy na jednym urządzeniu mamy uruchomiony zarówno protokół BGP jak i OSPF, router-id w obu instancja musi być identyczny. Jest to bardzo podchwytliwy przypadek, ponieważ bardzo łatwo przeoczyć błędne ustawienia. W przykładzie poniżej widoczna jest konfiguracja routerów R3 i ISP-1. Zwróć szczególną uwagę na to, jakie prefixy są widoczne w obu tabelach routingu.

redystrybucja eigrp do ospf do bgp
R3#show run interface GigabitEthernet0/3 ip address 10.3.13.3 255.255.255.0 ! router ospf 1  router-id 3.3.3.3 redistribute bgp 6499 subnets network 2.2.2.0 0.0.0.255 area 0 network 3.3.3.0 0.0.0.255 area 0 network 10.2.3.0 0.0.0.255 area 0 network 10.3.4.0 0.0.0.255 area 0 ! router bgp 6499  bgp router-id 99.99.99.99 bgp log-neighbor-changes neighbor 10.3.13.133 remote-as 6500 address-family ipv4  redistribute ospf 1 metric 10 neighbor 10.3.13.133 activate exit-address-family R3#show ip route O*E2 0.0.0.0/0 [110/1] via 10.3.4.4, 00:18:43, GigabitEthernet0/0 [110/1] via 10.2.3.2, 00:18:43, GigabitEthernet0/1 1.0.0.0/32 is subnetted, 1 subnets O 1.1.1.1 [110/3] via 10.3.4.4, 00:18:43, GigabitEthernet0/0 [110/3] via 10.2.3.2, 00:18:43, GigabitEthernet0/1 2.0.0.0/32 is subnetted, 1 subnets O 2.2.2.2 [110/2] via 10.2.3.2, 00:18:43, GigabitEthernet0/1 3.0.0.0/8 is variably subnetted, 2 subnets, 2 masks C 3.3.3.0/24 is directly connected, Loopback0 L 3.3.3.3/32 is directly connected, Loopback0 4.0.0.0/32 is subnetted, 1 subnets O 4.4.4.4 [110/2] via 10.3.4.4, 00:18:43, GigabitEthernet0/0 5.0.0.0/24 is subnetted, 1 subnets O E2 5.5.5.0 [110/120] via 10.3.4.4, 00:18:43, GigabitEthernet0/0 [110/120] via 10.2.3.2, 00:18:43, GigabitEthernet0/1 8.0.0.0/32 is subnetted, 1 subnets O E2 10.0.0.0/8 [110/120] via 10.3.4.4, 00:18:43, GigabitEthernet0/0 [110/120] via 10.2.3.2, 00:18:43, GigabitEthernet0/1 O 10.1.2.0/24 [110/2] via 10.2.3.2, 00:18:43, GigabitEthernet0/1 O 10.1.4.0/24 [110/2] via 10.3.4.4, 00:18:43, GigabitEthernet0/0 C 10.2.3.0/24 is directly connected, GigabitEthernet0/1 L 10.2.3.3/32 is directly connected, GigabitEthernet0/1 C 10.3.4.0/24 is directly connected, GigabitEthernet0/0 L 10.3.4.3/32 is directly connected, GigabitEthernet0/0 C 10.3.13.0/24 is directly connected, GigabitEthernet0/3 L 10.3.13.3/32 is directly connected, GigabitEthernet0/3 100.0.0.0/32 is subnetted, 1 subnets B 100.100.100.100 [20/10] via 10.3.13.133, 00:23:13 101.0.0.0/32 is subnetted, 1 subnets B 101.101.101.101 [20/10] via 10.3.13.133, 00:23:13 172.1.0.0/24 is subnetted, 1 subnets O E2 172.1.5.0 [110/120] via 10.3.4.4, 00:18:43, GigabitEthernet0/0 [110/120] via 10.2.3.2, 00:18:43, GigabitEthernet0/1
ISP-1#show run interface Loopback0 ip address 100.100.100.100 255.255.255.255 ! interface Loopback1 ip address 101.101.101.101 255.255.255.255 ! interface GigabitEthernet0/3 ip address 10.3.13.133 255.255.255.0 duplex auto speed auto media-type rj45 ! router bgp 6500 bgp log-neighbor-changes neighbor 10.3.13.3 remote-as 6499 ! address-family ipv4 redistribute connected metric 10 neighbor 10.3.13.3 activate exit-address-family ISP-1#show ip route 1.0.0.0/32 is subnetted, 1 subnets B 1.1.1.1 [20/10] via 10.3.13.3, 00:22:28 2.0.0.0/32 is subnetted, 1 subnets B 2.2.2.2 [20/10] via 10.3.13.3, 00:22:28 3.0.0.0/24 is subnetted, 1 subnets B 3.3.3.0 [20/0] via 10.3.13.3, 00:27:55 4.0.0.0/32 is subnetted, 1 subnets B 4.4.4.4 [20/10] via 10.3.13.3, 00:22:28 10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks B 10.1.2.0/24 [20/10] via 10.3.13.3, 00:22:28 B 10.1.4.0/24 [20/10] via 10.3.13.3, 00:22:28 B 10.2.3.0/24 [20/0] via 10.3.13.3, 00:27:55 B 10.3.4.0/24 [20/0] via 10.3.13.3, 00:27:55 C 10.3.13.0/24 is directly connected, GigabitEthernet0/3 L 10.3.13.133/32 is directly connected, GigabitEthernet0/3 100.0.0.0/32 is subnetted, 1 subnets C 100.100.100.100 is directly connected, Loopback0 101.0.0.0/32 is subnetted, 1 subnets C 101.101.101.101 is directly connected, Loopback1 

Na pierwszy rzut oka po obu stronach wszystko wygląda w porządku. Prefixy zostały wymienione poprzez BGP w obu kierunkach. Jednak po dłuższym porównaniu obu tablic, widać wyraźnie, że części tras brakuje. Dokładnie brakuje nam tras, które były widoczne w OSPF jako trasy nauczone z innego protokołu.

Podsumowanie

Omówiliśmy sobie 5 przypadków gdy zachowanie OSPF lub jego konfiguracja nie była do końca dla wszystkich oczywista. Jestem mega ciekawy, czy znałeś wszystkie przypadki? Może znasz inne nieoczywiste zachowania OSPF-a? Koniecznie podziel się nimi w komentarzu!

Możesz być również zainteresowany tymi artykułami:

Zostaw komentarz

Na blogu inna sieć wykorzystuję "ciasteczka". Lubię ciastka, a Ty? Lubię ciastka! Chcę wiedzieć więcej