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.

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.

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.

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!