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

OSPF jest najbardziej skomplikowanym protokołem. Poznaj jego 5 nietypowych zachowań.
5 rzeczy w ospf o ktorych mogles nie wiedziec

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!

19 aplikacji, które musi znać każdy sieciowiec

Blog wspiera partner diamentowy

Borg5 - Diamentowy partner bloga

Narzędziownik sieciowca

19 aplikacji newsletter

Grupa na Facebooku

Pierwsze kroki w sieciach

Najnowsze artykuły

Model referencyjny ISO/OSI

Model referencyjny ISO/OSI

Maszyny, podobnie jak ludzie, do skutecznej komunikacji potrzebują pewnych zasad. My przestrzegamy zasad gramatyki oraz używamy słownictwa zrozumiałego dla odbiorcy, urządzenia natomiast wykorzystują standardy i protokoły. Na tym nie kończą się podobieństwa. Zwróć...

Automatyzacja sieci z Netmiko

Automatyzacja sieci z Netmiko

Netmiko to biblioteka napisana w Pythonie przez Kirka Byersa. Jest jedną z najłatwiejszych opcji wejścia w świat automatyzacji sieci. Dlaczego? Ponieważ Netmiko wykorzystuje Pythonową bibliotekę Paramiko do łączenia się poprzez SSH do CLI. Wszystkie przekazywane przez...

13 sposobów na zabezpieczenie sieci

13 sposobów na zabezpieczenie sieci

Zabezpieczanie infrastruktury to niekończący się proces, który polega na ciągłym testowaniu i ulepszaniu. Warto podchodzić do tego skrupulatnie i metodycznie – idealnie sprawdzi się tutaj proponowana poniżej 13-punktowa checklista bezpieczeństwa dla sieciowca.1....

Protokoły FHRP – HSRP, VRRP i GLBP

Protokoły FHRP – HSRP, VRRP i GLBP

Jest takie angielskie powiedzenie "Two is one, one is none". Mówi ono o konieczności stosowania redundacji, czyli zapewnienia nadmiarowości. Kiedy mamy dwa urządzenia, awaria jednego zwykle nie jest problemem i daje nam czas na naprawę. Posiadanie w momencie awarii...

Hot Standby Router Protocol

Hot Standby Router Protocol

HSRP, czyli Hot Standby Router Protocol to protokół  z grupy FHRP (first-hop redundancy protocol) opatentowany przez Cisco w 1994r. Jego zadaniem jest zapewnienie redundancji bramy domyślnej w przypadku awarii, bez potrzeby zmiany w konfiguracji urządzeń końcowych. W...

Jesteśmy parterem miedialnym konferencji 

PLNOG

O autorze

Rafał Rudewicz

Specjalizuję się w rozwiązaniach Enterprise oraz Service Provider. Projektuję, wdrażam oraz naprawiam sieci dla największych firm na świecie.

Komentarze

2 komentarze

  1. Dijkstra

    Ciekawy art.
    Dodatkowo, mam kilka pytań odnośnie OSPF.

    1. Do czego jest nam potrzebna area 0 (tzw. backbone area) ?
    2. Dlaczego potrzebujemy LSDB (czy komunikaty LSA muszą być umieszczane w bazie LSDB) ?
    3. Jakie są różne sposoby zmniejszenia liczby LSA w danym obszarze czy też w danej instancji OSPF ?
    4. Jakie narzędzia/metody konfiguracji/best practices są dostępne w ramach OSPF, aby zwiększyć jego stabilność oraz mieć mniej obliczeń SPF ?

    Odpowiedz

Wyślij komentarz

Twój adres e-mail nie zostanie opublikowany.

Powiązane posty

Zapisz się na newsletter