Confronto del comportamento dell'indirizzo di inoltro OSPF su IOS e IOS-XR

Introduzione

In questo documento viene descritto il concetto di indirizzo di inoltro OSPF (Open Shortest Path First) sui dispositivi IOS-XR e IOS. Viene confrontato il comportamento OSPF tra i dispositivi IOS-XR e IOS.

Prerequisiti

Requisiti

Cisco raccomanda la conoscenza di base del protocollo OSPF.

Componenti usati

Le informazioni fornite in questo documento si basano sulle seguenti versioni software e hardware:

• Versioni dispositivo virtuale IOS-XR: 6.1.3, 6.1.2, 6.0.0, 5.3.0, 5.2.0
• Piattaforme Cisco IOS

Indirizzo di inoltro OSPF

In questa sezione viene descritto il concetto di indirizzo di inoltro in OSPF. Se si ha già familiarità con questo argomento, è possibile passare alla sezione successiva.

Quando un router OSPF ridistribuisce una route da un altro protocollo di origine in OSPF come E1 o E2, può impostare un indirizzo di inoltro in quel particolare LSA (Link State Advertisement) esterno. Il protocollo OSPF deve soddisfare queste condizioni per poter impostare l'attributo specifico. L'indirizzo di inoltro può essere popolato (diverso da zero) o non popolato (tutti gli zeri).

Tutte le condizioni seguenti devono impostare il campo dell'indirizzo di inoltro su un indirizzo diverso da zero:

• Il protocollo OSPF è abilitato sul router ASBR (Autonomous System Boundary Router) dell'interfaccia dell'hop successivo
• L'interfaccia hop successivo di ASBR è non passiva in OSPF
• L'interfaccia hop successivo di ASBR non è point-to-point
• L'interfaccia hop successivo di ASBR non è point-to-multipoint
• L'indirizzo dell'interfaccia dell'hop successivo di ASBR è compreso nell'intervallo di rete specificato nel comando router ospf.
• Qualsiasi altra condizione oltre a queste, imposta l'indirizzo di inoltro su 0.0.0.0.

Quando l'indirizzo di inoltro è impostato su tutti gli zeri (0.0.0.0), il router deve ricorrere a quel particolare nodo nella topologia OSPF per instradare correttamente il traffico verso la destinazione. Una grande differenza con OSPF come protocollo di routing dello stato del collegamento rispetto ai protocolli del vettore di distanza è che lo stato del collegamento consente di avere una vista completa della topologia in quell'area particolare, il router può calcolare il percorso più breve a un nodo nella topologia con una vista complessiva di tutti i dispositivi e dei relativi costi. Non si dirige necessariamente verso un prefisso, ma verso un nodo, il che è una grande differenza.

Quando l'indirizzo di inoltro è impostato su un valore diverso da zero, il router controlla il percorso più breve del nodo connesso all'indirizzo di inoltro.

Per ulteriori chiarimenti, la topologia viene riesaminata in questa sezione:

Immagine 1

Nell'immagine 1, il protocollo EIGRP (Enhanced Interior Gateway Routing Protocol) viene eseguito tra R2 e R3 sul segmento condiviso 192.168.1.0/24. Anche R1 è collegato al segmento condiviso 192.168.1.0/24, sebbene non esista un protocollo EIGRP. R2 è configurato per ridistribuire 172.16.3.3/32 da EIGRP a OSPF come route E2 esterna. Il software del router XR5 è IOS-XR.

In questa sezione viene illustrata l'importanza dell'indirizzo di inoltro. Si supponga che il traffico vada verso 172.16.3.3/32 proviene dalla rete cloud, arriva sul router Transit_Router e viene inoltrato in base alla tabella di routing.

Controllare la tabella di routing di Transit_Router per individuare il prefisso 172.16.3.3/32.

  

Transit_Router#show ip route 172.16.3.3

Routing entry for 172.16.3.3/32
  Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 2
  Last update from 192.168.70.1 on GigabitEthernet1, 00:00:04 ago
  Routing Descriptor Blocks:
  * 192.168.70.1, from 2.2.2.2, 00:00:04 ago, via GigabitEthernet1        <- You see the prefix is from advertising router with router-id 2.2.2.2
      Route metric is 20, traffic share count is 1

Transit_Router#

L'hop successivo è 192.168.70.1 e viene indirizzato a R1. Poiché R2 viene ridistribuito dalla rete 172.16.3.3/32 in OSPF, si può supporre che sia necessario effettuare il routing verso R2 per raggiungere la destinazione 172.16.3.3/32.

È possibile eseguire traceroute da Transit_Router verso la versione 172.16.3.3/32.

Transit_Router#traceroute 172.16.3.3 timeout 1
Type escape sequence to abort.
Tracing the route to 172.16.3.3
VRF info: (vrf in name/id, vrf out name/id)
  1 192.168.70.1 7 msec 5 msec 8 msec           <- R1
  2 192.168.1.3 10 msec 11 msec 17 msec         <- R3

Quando R1 riceve il traffico destinato a 172.16.3.3/32, viene in realtà indirizzato direttamente a R3. Eseguire show ip route su R1 per visualizzare la tabella di routing verso 172.16.3.3.

  

R1#show ip route 172.16.3.3

Routing entry for 172.16.3.3/32
  Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 1
  Last update from 192.168.1.3 on GigabitEthernet0/0, 02:04:54 ago
  Routing Descriptor Blocks:
  * 192.168.1.3, from 2.2.2.2, 02:04:54 ago, via GigabitEthernet0/0    <-- Next-hop goes directly towards R3 over the shared segment
      Route metric is 20, traffic share count is 1

A causa dell'indirizzo di inoltro, R1 ha un hop successivo di 192.168.1.3 che va verso R3, se non si dispone di alcun protocollo di routing tra R1 e R3. Verificare l'LSA esterno su transit_Router.

Transit_Router#show ip ospf database external 172.16.3.3

            OSPF Router with ID (6.6.6.6) (Process ID 1)

                Type-5 AS External Link States

  LS age: 1641
  Options: (No TOS-capability, DC, Upward)
  LS Type: AS External Link
  Link State ID: 172.16.3.3 (External Network Number )
  Advertising Router: 2.2.2.2
  LS Seq Number: 80000004
  Checksum: 0x8299
  Length: 36
  Network Mask: /32
        Metric Type: 2 (Larger than any link state path)
        MTID: 0
        Metric: 20
        Forward Address: 192.168.1.3      <-R3 interface towards the shared segment
        External Route Tag: 0

Come si può vedere, l'indirizzo di inoltro è popolato con un indirizzo IP di 192.168.1.3, il che significa che se si desidera indirizzare verso 172.16.3.3/32, è necessario eseguire una ricorsione verso 192.168.1.3. Ciò significa che quando R1 riceve pacchetti destinati a 172.16.3.3/32, ha anche un LSA Type-5 per 172.16.3.3/32 con un indirizzo di inoltro di 192.168.1.3 che è connesso direttamente all'interfaccia Gi0/0. Quindi, R1 instrada i pacchetti verso 192.168.1.3.

L'indirizzo di inoltro contribuisce a ridurre il routing non ottimale. Se l'indirizzo di inoltro non è stato impostato sull'LSA Type-5, è necessario indirizzare tutti i pacchetti destinati a 172.16.3.3 tramite l'ASBR che è R2.

Per verificarlo, è possibile ripristinare l'indirizzo di inoltro a 0.0.0.0 ed eseguire traceroute da Transit_Router.

Transit_Router#show ip ospf database external 172.16.3.3

            OSPF Router with ID (6.6.6.6) (Process ID 1)

                Type-5 AS External Link States

  LS age: 14
  Options: (No TOS-capability, DC, Upward)
  LS Type: AS External Link
  Link State ID: 172.16.3.3 (External Network Number )
  Advertising Router: 2.2.2.2
  LS Seq Number: 80000005
  Checksum: 0x196F
  Length: 36
  Network Mask: /32
        Metric Type: 2 (Larger than any link state path)
        MTID: 0
        Metric: 20
        Forward Address: 0.0.0.0    <- Recurse towards the ASBR (RID 2.2.2.2)
        External Route Tag: 0


Transit_Router#

Come accennato, l'indirizzo di inoltro è impostato su 0.0.0.0. Ciò significa che è necessario inoltrare i pacchetti all'ASBR che è R2. Quando si esegue un traceroute da Transit_Router destinato a 172.16.3.3, il traffico segue il percorso verso ASBR R2.

La schermata può essere visualizzata qui: 

Transit_Router#traceroute 172.16.3.3
Type escape sequence to abort.
Tracing the route to 172.16.3.3
VRF info: (vrf in name/id, vrf out name/id)
  1 192.168.70.1 17 msec 12 msec 3 msec     <-R1
  2 192.168.14.4 3 msec 18 msec 7 msec      <-R4
  3 192.168.24.2 15 msec 8 msec 5 msec      <-R2
  4 192.168.1.3 8 msec 11 msec 7 msec       <-R3
Transit_Router#

  

Differenze tra IOS e IOS-XR

In questa sezione viene descritta una differenza tra i dispositivi IOS e IOS-XR quando si conosce l'indirizzo di inoltro tramite un'altra origine. 

In IOS, se nel database è presente una route esterna OSPF e l'indirizzo di inoltro è impostato, l'indirizzo di inoltro deve essere noto tramite una route inter area OSPF o intra area OSPF. Se l'indirizzo di inoltro non è noto tramite la route interna o tra aree OSPF, il router non installa la route OSPF esterna nella base di informazioni di routing (RIB).

Verificare cosa succede quando si configura l'indirizzo di inoltro in modo che sia noto tramite una route statica.

Immagine 2

Nella topologia image 2, R2 è configurato come punto di ridistribuzione tra EIGRP e OSPF. Il router ridistribuisce 172.16.3.3/32 da EIGRP nel dominio OSPF. È possibile controllare sia R4 che XR5 per verificare quali sono le differenze quando l'indirizzo di inoltro è noto da un'altra fonte. Di seguito è riportato il database OSPF su R4.

R4# show ip ospf database external 172.16.3.3

            OSPF Router with ID (4.4.4.4) (Process ID 1)
                Type-5 AS External Link States
  LS age: 4
  Options: (No TOS-capability, DC, Upward)
  LS Type: AS External Link
  Link State ID: 172.16.3.3 (External Network Number )
  Advertising Router: 2.2.2.2
  LS Seq Number: 80000002
  Checksum: 0x8697
  Length: 36
  Network Mask: /32
        Metric Type: 2 (Larger than any link state path)
        MTID: 0
        Metric: 20
        Forward Address: 192.168.1.3
        External Route Tag: 0

 Controlla come ti colleghi all'indirizzo di inoltro.

R4# show ip route 192.168.1.3
Routing entry for 192.168.1.0/24
  Known via "ospf 1", distance 110, metric 2, type intra area      <- Here you see it is know via OSPF intra area 
  Last update from 192.168.24.2 on GigabitEthernet0/0, 00:00:23 ago
  Routing Descriptor Blocks:
    192.168.24.2, from 1.1.1.1, 00:00:23 ago, via GigabitEthernet0/0
      Route metric is 2, traffic share count is 1
  * 192.168.14.1, from 1.1.1.1, 00:04:42 ago, via GigabitEthernet0/1
      Route metric is 2, traffic share count is 1

R4#

Come si può vedere, il router apprende l'indirizzo di inoltro tramite il percorso all'interno dell'area, ossia può installare l'LSA esterno in RIB. Si può vedere che l'LSA esterno è installato in RIB.

R4#show ip route 172.16.3.3

Routing entry for 172.16.3.3/32
  Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 2
  Last update from 192.168.24.2 on GigabitEthernet0/0, 00:01:02 ago
  Routing Descriptor Blocks:
    192.168.24.2, from 2.2.2.2, 00:01:02 ago, via GigabitEthernet0/0
      Route metric is 20, traffic share count is 1
  * 192.168.14.1, from 2.2.2.2, 00:04:57 ago, via GigabitEthernet0/1
      Route metric is 20, traffic share count is 1

Configurare una route statica per l'indirizzo di inoltro verso l'ASBR che è R2

R4#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R4(config)#ip route 192.168.1.0 255.255.255.0 192.168.24.2 

Eseguire il comando show ip route verso l'indirizzo di inoltro.

R4# show ip route 192.168.1.3
Routing entry for 192.168.1.0/24
  Known via "static", distance 1, metric 0
  Routing Descriptor Blocks:
  * 192.168.24.2
      Route metric is 0, traffic share count is 1

Come si può vedere, l'indirizzo di inoltro non viene appreso tramite OSPF ma statico, il che significa che ora l'LSA esterno per 172.16.3.3 non può superare i criteri necessari per essere utilizzato.

R4#show ip ospf database external 172.16.3.3

            OSPF Router with ID (4.4.4.4) (Process ID 1)

                Type-5 AS External Link States

  LS age: 480
  Options: (No TOS-capability, DC, Upward)
  LS Type: AS External Link
  Link State ID: 172.16.3.3 (External Network Number )
  Advertising Router: 2.2.2.2
  LS Seq Number: 80000001
  Checksum: 0x8896
  Length: 36
  Network Mask: /32
        Metric Type: 2 (Larger than any link state path)
        MTID: 0
        Metric: 20
        Forward Address: 192.168.1.3
        External Route Tag: 0

Verificare infine se la route esterna è installata dal database OSPF in RIB.

R4#show ip route 172.16.3.3
% Network not in table

Come si può vedere, il router non installa l'LSA esterno dal database OSPF in RIB, in quanto l'indirizzo di inoltro è noto tramite static e non tramite OSPF intra o inter-area.

La logica è che OSPF non considera attendibile un'altra origine per il routing verso l'indirizzo di inoltro, pertanto il router non deve prendere in considerazione alcuna LSA esterna con un indirizzo di inoltro non noto tramite OSPF.

In questa sezione viene descritto lo stesso test su IOS-XR per verificarne il comportamento. Su XR5, si dispone della scheda LSA esterna:

 RP/0/0/CPU0:XR4#show ospf database external 172.16.3.3
Mon Mar 26 06:26:24.656 UTC


            OSPF Router with ID (192.168.60.1) (Process ID 1)

                Type-5 AS External Link States
 
  Routing Bit Set on this LSA
  LS age: 930
  Options: (No TOS-capability, DC)
  LS Type: AS External Link
  Link State ID: 172.16.3.3 (External Network Number)
  Advertising Router: 2.2.2.2
  LS Seq Number: 80000001
  Checksum: 0x8896
  Length: 36
  Network Mask: /32
        Metric Type: 2 (Larger than any link state path)
        TOS: 0
        Metric: 20
        Forward Address: 192.168.1.3
        External Route Tag: 0

Quando si configura una route statica per l'indirizzo di inoltro verso R4, verificare se il router installa o meno la LSA esterna nel database.

RP/0/0/CPU0:XR4#show route 192.168.1.3
Mon Mar 26 06:33:21.587 UTC
Routing entry for 192.168.1.0/24
  Known via "static", distance 1, metric 0    <- The forwarding address is now known via static
  Installed Mar 26 06:31:55.133 for 00:01:26
  Routing Descriptor Blocks
    192.168.60.4          <- Next-hop is R4
      Route metric is 0, Wt is 1
  No advertising protos.

È possibile visualizzare l'indirizzo di inoltro appreso tramite static. A questo punto, verificare se l'LSA esterno è stato installato in RIB.

RP/0/0/CPU0:XR4#show route 172.16.3.3
Mon Mar 26 06:42:24.830 UTC
Routing entry for 172.16.3.3/32
  Known via "ospf 1", distance 110, metric 20, type extern 2
  Installed Mar 26 06:25:09.841 for 00:17:15
  Routing Descriptor Blocks
    192.168.60.4, from 2.2.2.2, via GigabitEthernet0/0/0/0
      Route metric is 20
  No advertising protos.
RP/0/0/CPU0:XR4#

Si vede una differenza tra IOS e IOS-XR. L'LSA esterno è stato installato in RIB anche se l'indirizzo di inoltro viene appreso tramite statico. Il router ha ancora la connettività verso il prefisso esterno.

RP/0/0/CPU0:XR4#ping 172.16.3.3
Mon Mar 26 06:44:25.772 UTC
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.3.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/9/19 ms
RP/0/0/CPU0:XR4#

Sembra che IOS-XR popola la LSA esterna in RIB ma non tiene conto dell'indirizzo di inoltro per la ricorsione, il che significa che ora ricorre verso l'ASBR piuttosto che cercare in RIB per l'indirizzo di inoltro.

Il test indica che può essere preso in considerazione. È possibile configurare una route statica per l'indirizzo di inoltro verso null0 e verificare se la connettività verso il prefisso esterno esiste ancora.

RP/0/0/CPU0:XR4#show ospf database external 172.16.3.3

Mon Mar 26 06:55:36.296 UTC
            OSPF Router with ID (192.168.60.1) (Process ID 1)
                Type-5 AS External Link States

  Routing Bit Set on this LSA
  LS age: 667
  Options: (No TOS-capability, DC)
  LS Type: AS External Link
  Link State ID: 172.16.3.3 (External Network Number)
  Advertising Router: 2.2.2.2
  LS Seq Number: 80000002
  Checksum: 0x8697
  Length: 36
  Network Mask: /32
        Metric Type: 2 (Larger than any link state path)
        TOS: 0
        Metric: 20
        Forward Address: 192.168.1.3
        External Route Tag: 0

RP/0/0/CPU0:XR4#show route 192.168.1.3

Mon Mar 26 06:55:38.966 UTC

Routing entry for 192.168.1.0/24
  Known via "static", distance 1, metric 0 (connected)
  Installed Mar 26 06:47:15.030 for 00:08:23
  Routing Descriptor Blocks
    directly connected, via Null0
      Route metric is 0, Wt is 1
  No advertising protos.
 

Verificare la connettività da XR5 verso 172.16.3.3.

RP/0/0/CPU0:XR4#ping 172.16.3.3
Mon Mar 26 06:56:45.261 UTC
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.3.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/7/19 ms
RP/0/0/CPU0:XR4#traceroute 172.16.3.3
Mon Mar 26 06:56:51.251 UTC
 
Type escape sequence to abort.
Tracing the route to 172.16.3.3
 1  192.168.60.4 0 msec  0 msec  0 msec
 2  192.168.14.1 0 msec  0 msec  0 msec
 3  192.168.1.3 9 msec  9 msec  0 msec
RP/0/0/CPU0:XR4 

Dai test effettuati è emersa l'importanza dell'indirizzo di inoltro e la modalità di interpretazione del routing quando è impostato. Inoltre, il presupposto che se l'indirizzo di inoltro è impostato, deve essere utilizzato, può essere false in quanto dipende dalla piattaforma. Quando l'indirizzo di inoltro è noto tramite l'area interna/tra OSPF, viene utilizzato, altrimenti viene popolato ma non utilizzato per la ricorsione. Il comportamento di XR garantisce un certo livello di sicurezza: nel caso in cui un indirizzo di inoltro LSA esterno venga conosciuto da un'altra fonte, il traffico non può essere bloccato.