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

OSPF jest uważany za jeden z najbardziej skomplikowanych protokołów routingu, być może nawet bardziej skomplikowany od BGP. Obsługuje 5 różnych rodzajów topologii fizycznych oraz 6 rodzajów obszarów. Ponadto, posiada ponad 10 różnych pakietów LSA oraz mnóstwo opcji konfiguracyjnych.

Na podstawowym poziomie OSPF jest stosunkowo łatwy w wdrożeniu. Jednak diabeł, jak zwykle, tkwi w szczegółach, zwłaszcza gdy mamy specyficzne wymagania co do jego zachowania.

Przejdźmy teraz do omówienia 5 przypadków zachowania i konfiguracji OSPF, które mogą okazać się nieoczywiste.

Adresy loopback rozgłaszane jako /32

Zdarza się, że potrzebujemy zadresować interfejs pętli zwrotnej 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 dotyczące zachowania takich portów są jednak nieco inne w protokole OSPF.

Zgodnie z RFC 2328 adres interfejsu pętli zwrotnej powinien być rozgłaszany jako Typ 3 (sieć typu stub), maska ustawiona na 0xffffff (trasa do hosta), a koszt wynosi 0.

Tyle teorii. Sprawdźmy teraz, jak to wygląda 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ć, konfiguracja spełnia wszystkie założenia. Routery R1 i R2 posiadają interfejsy Loopback z adresami skonfigurowanymi z maską /24.

Sprawdźmy teraz zawartość tablicy 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 interfejsu pętli zwrotnej 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 bywa jednym z najbardziej mylących.

Większość osób, nawet początkujących w dziedzinie sieci, wie, że aby rozgłaszać sieć w OSPF, trzeba ją redystrybuować z innego protokołu lub dodać poleceniem network.

Jednak prawda jest taka, że polecenie network nie określa, które dokładnie sieci mają być rozgłaszane. To polecenie dodaje interfejsy do procesu OSPF, których adresy mieszczą się w określonym zakresie. Dopiero z aktywowanego interfejsu pobierana jest informacja, które sieci powinny być rozgłaszane.

Przyjrzyjmy się prostemu przykładowi składającemu się z 3 routerów pracujących w jednym obszarze. Konfiguracja nie jest skomplikowana, ale warto zwrócić uwagę, że użyłem różnych wariantów polecenia network.

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 poprawnie. Sieci zostały rozgłoszone z odpowiednimi maskami.

Kiedy proces ID ma znaczenie

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 to protokół hierarchiczny. Posiada obszar 0 nazywany backbone oraz obszary do niego przyległe. Bezpośrednia komunikacja między obszarami nie jest możliwa, cały ruch musi przechodzić przez nasz trzon.

Nietypowym przypadkiem jest sytuacja, gdy korzystamy z usługi MPLS L3VPN i rozgłaszamy trasy do naszego dostawcy za pomocą OSPF-a. Wtedy sieć ISP jest dla nas wirtualnym routerem, do którego rozgłaszamy sieci LAN, a następnie te rozgłoszone prefiksy są dostępne w innych lokalizacjach.

Przeanalizujmy, jak realizowana jest usługa przekazywania tras między obszarami przez ISP. Ze względu na niemożliwość utrzymania tysięcy różnych instancji OSPF w sieci, wszystkie otrzymane trasy są redystrybuowane do MP-BGP, a następnie ponownie przekazywane do OSPF. W wyniku tego trasy z jednego obszaru są widoczne w drugim jako zewnętrzne. Co jednak zrobić, gdy taki stan nie odpowiada nam i chcemy widzieć wszystkie nasze prefiksy z różnych lokalizacji w ramach jednej instancji OSPF?

W takim przypadku dostawcy potrzebna jest odpowiednia konfiguracja identyfikatora domeny.

Redystrybucja tras OSPF przez sieć MPLS L3VPN i superbackbone

Jeżeli wartości domain-id na routerach brzegowych ISP są 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 uruchomione zarówno protokoły BGP, jak i OSPF, identyfikator routera (router-id) w obu instancjach musi być taki sam. Jest to bardzo subtelny przypadek, ponieważ bardzo łatwo przeoczyć błędy w konfiguracji. W poniższym przykładzie pokazana jest konfiguracja routerów R3 i ISP-1. Zwróć szczególną uwagę na to, jakie prefiksy są widoczne w obu tabelach routingu.

Redystrybucja z EIGRP do OSPF i z 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 wszystko wydaje się być w porządku z obu stron. Prefixy zostały wymienione poprzez BGP w obu kierunkach. Jednak po dokładniejszym porównaniu tablic, zauważalne jest brakujące trasy. Konkretnie brakuje nam tras, które były widoczne w OSPF jako trasy nauczone z innego protokołu.

Podsumowanie

Omówiliśmy 5 przypadków, w których zachowanie OSPF lub jego konfiguracja nie były całkowicie oczywiste. Czy znasz wszystkie te przypadki? Może masz znajomość innych nieoczywistych zachowań OSPF-a? Koniecznie podziel się nimi w komentarzu!