Comparer le comportement des adresses de transfert OSPF sur IOS et IOS-XR

Introduction

Ce document décrit le concept de l'adresse de transfert Open Shortest Path First (OSPF) sur les périphériques IOS-XR et IOS. Il compare le comportement OSPF entre les périphériques IOS-XR et IOS.

Conditions préalables

Conditions requises

Cisco vous recommande d'avoir une connaissance de base du protocole OSPF.

Components Used

Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :

• Versions des périphériques virtuels IOS-XR : 6.1.3, 6.1.2, 6.0.0, 5.3.0, 5.2.0
• Plates-formes Cisco IOS

Adresse de transfert OSPF

Cette section traite du concept de l’adresse de transfert dans OSPF. Si vous en connaissez déjà, passez à la section suivante.

Lorsqu’un routeur OSPF redistribue une route d’un autre protocole source dans OSPF en tant qu’E1 ou E2, il peut définir une adresse de transfert dans cette LSA externe spécifique. Le protocole OSPF doit remplir ces conditions pour pouvoir définir cet attribut particulier. L'adresse de transfert peut être renseignée (non nulle) ou non remplie (tous les zéros).

Toutes ces conditions doivent définir le champ d'adresse de transfert sur une adresse différente de zéro :

• OSPF est activé sur le routeur ASBR (Autonomous System Boundary Router) de l'interface de tronçon suivant
• L'interface de tronçon suivant d'ASBR n'est pas passive sous OSPF
• L'interface de tronçon suivant d'ASBR n'est pas point à point
• L'interface de tronçon suivant d'ASBR n'est pas point à multipoint
• L'adresse de l'interface de tronçon suivant d'ASBR tombe sous la plage de réseau spécifiée dans la commande router ospf.
• Toutes les autres conditions, outre celles-ci, définissent l’adresse de transfert sur 0.0.0.0.

Lorsque l’adresse de transfert est définie sur tous les zéros (0.0.0.0), cela signifie que le routeur doit se récurer à ce noeud particulier dans la topologie OSPF pour acheminer correctement le trafic vers la destination. Une grande différence avec le protocole OSPF en tant que protocole de routage à état de liens par rapport aux protocoles à vecteur de distance est que l’état des liaisons lui permet d’avoir une vue complète de la topologie dans cette zone particulière, le routeur peut calculer le chemin le plus court vers un noeud de la topologie avec une vue globale de tous les périphériques et de leurs coûts. Il ne se dirige pas nécessairement vers un préfixe mais vers un noeud, ce qui est une grande différence.

Lorsque l’adresse de transfert est définie sur une valeur différente de zéro, le routeur vérifie quel est le chemin le plus court vers ce noeud connecté à l’adresse de transfert.

Cette section passe en revue la topologie pour plus de précisions :

Image 1

Dans l'image 1, Enhanced Interior Gateway Routing Protocol (EIGRP) s'exécute entre R2 et R3 sur le segment partagé 192.168.1.0/24. R1 est également connecté au segment partagé 192.168.1.0/24, bien qu'il n'existe pas de protocole EIGRP. R2 est configuré pour redistribuer 172.16.3.3/32 du protocole EIGRP vers le protocole OSPF en tant que route E2 externe. Le protocole OSPF fonctionne entre R2 et R4, R1 et R4, R1 et Transit_Router et R4 vers XR5. Le logiciel du routeur XR5 est IOS-XR.

Cette section explique l'importance de l'adresse de transfert. Considérez que le trafic va vers 172.16.3.3/32 provient du réseau cloud, qu'il arrive sur le routeur de transit et qu'il est transmis conformément à la table de routage.

Vérifiez ce que vous avez dans la table de routage de Transit_Router pour le préfixe 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#

Le tronçon suivant est 192.168.70.1 va vers R1. Puisque R2 est redistribué au réseau 172.16.3.3/32 dans le protocole OSPF, vous pouvez supposer que vous devez router vers R2 pour atteindre la destination 172.16.3.3/32.

Vous pouvez exécuter traceroute à partir du routeur de transit vers 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

Lorsque R1 reçoit du trafic destiné à 172.16.3.3/32, il est en fait routé directement vers R3. Exécutez show ip route sur R1 pour afficher la table de routage vers 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

En raison de l'adresse de transfert, R1 a un saut suivant 192.168.1.3 va vers R3, Si vous n'avez aucun protocole de routage entre R1 et R3. Vérifiez la LSA externe sur le routeur 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

Comme vous pouvez le voir, l'adresse de transfert est renseignée avec l'adresse IP 192.168.1.3, ce qui signifie que si vous voulez acheminer vers 172.16.3.3/32, vous devez revenir vers 192.168.1.3. Cela implique maintenant que lorsque R1 reçoit des paquets destinés à 172.16.3.3/32, il a également une LSA de type 5 pour 172.16.3.3/32 avec une adresse de transfert de 192.168.1.3 qui est directement connectée sur l'interface Gi0/0. Par conséquent, R1 achemine les paquets vers 192.168.1.3.

L’adresse de transfert aide à limiter le routage sous-optimal. Si l'adresse de transfert n'a pas été définie sur la LSA de type 5, vous devez acheminer tous les paquets destinés à 172.16.3.3 via l'ASBR qui est R2.

Pour le vérifier, vous pouvez réinitialiser l'adresse de transfert sur 0.0.0.0 et exécuter traceroute à partir du routeur de transit.

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#

Vous pouvez voir que l'adresse de transfert est définie sur 0.0.0.0, ce qui signifie que vous devez maintenant acheminer les paquets vers l'ASBR qui est R2. Lorsque vous exécutez une traceroute à partir du routeur de transit vers 172.16.3.3, ce trafic suit le chemin vers le routeur ASBR R2.

On peut le voir ici : 

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#

  

Différences entre IOS et IOS-XR

Cette section décrit une différence entre les périphériques IOS et IOS-XR lorsque vous connaissez l'adresse de transfert via une autre source. 

Dans IOS, lorsque vous avez une route externe OSPF dans la base de données et que l'adresse de transfert est définie, l'adresse de transfert doit être connue via une route OSPF inter ou intra-zone. Si l'adresse de transfert n'est pas connue via une route OSPF interne ou inter-zone, le routeur n'installe pas la route OSPF externe dans la base d'informations de routage (RIB).

Vérifiez ce qui se passe lorsque vous configurez l'adresse de transfert pour qu'elle soit connue via une route statique.

Image 2

Dans la topologie de l'image 2, R2 est configuré comme point de redistribution entre EIGRP et OSPF. Le routeur redistribue 172.16.3.3/32 à partir du protocole EIGRP dans le domaine OSPF. Vous pouvez vérifier à la fois R4 et XR5 pour vérifier quelles sont les différences lorsque l'adresse de transfert est connue via une autre source. La base de données OSPF sur R4 s'affiche ici.

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

 Vérifiez comment vous dirigez vers l'adresse de transfert.

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#

Comme vous pouvez le voir, le routeur apprend l’adresse de transfert via une route intra-zone, ce qui signifie qu’il peut installer la LSA externe dans RIB. Vous pouvez voir que la LSA externe est installée dans 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

Configurez une route statique pour l’adresse de transfert qui va vers l’ASBR qui est 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 

Exécutez show ip route vers l'adresse de transfert.

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

Comme vous pouvez le voir, l’adresse de transfert n’est pas apprise via OSPF mais statique, ce qui signifie que la LSA externe pour 172.16.3.3 ne peut plus répondre aux critères nécessaires à l’utilisation.

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

Enfin, vérifiez si la route externe est installée de la base de données OSPF dans RIB.

R4#show ip route 172.16.3.3
% Network not in table

Comme vous pouvez le voir, le routeur n'installe pas la LSA externe de la base de données OSPF dans RIB, car l'adresse de transfert est connue par l'intermédiaire de la statique et non par l'intermédiaire d'OSPF à l'intérieur ou entre zones.

La logique ici est que le protocole OSPF ne considère pas qu’une autre source de routage vers l’adresse de transfert est fiable. Par conséquent, le routeur ne doit prendre en compte aucune LSA externe dont l’adresse de transfert n’est pas connue via OSPF.

Cette section décrit le même test sur IOS-XR pour vérifier le comportement. Sur XR5, vous avez une LSA externe :

 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

Vérifiez si vous configurez une route statique pour l'adresse de transfert vers R4, si le routeur installe ou non la LSA externe dans la base de données.

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.

Vous pouvez voir que l'adresse de transfert est apprise via static. Maintenant, vérifiez si la LSA externe a été installée dans 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#

Vous pouvez voir une différence entre IOS et IOS-XR. La LSA externe a été installée dans RIB, même si l’adresse de transfert est apprise par l’intermédiaire d’une adresse statique. Le routeur dispose toujours de la connectivité vers le préfixe externe.

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#

Il semble que IOS-XR remplit la LSA externe dans RIB, mais ne prend pas en compte l'adresse de transfert pour la récursivité, ce qui signifie qu'elle se répète vers l'ASBR plutôt que de rechercher l'adresse de transfert dans RIB.

Le test vous indique qu'il peut être pris en compte. Vous pouvez configurer une route statique pour l'adresse de transfert vers null0 et vérifier si la connectivité vers le préfixe externe existe toujours.

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.
 

Vérifiez la connectivité de XR5 vers 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 

Dans ces tests, vous avez vu l'importance de l'adresse de transfert et comment interpréter le routage lorsqu'il est défini. En outre, l'hypothèse que si l'adresse de transfert est définie, elle doit être utilisée, peut être fausse car elle dépend de la plate-forme. Lorsque l'adresse de transfert est connue via la zone OSPF intra/inter, elle est utilisée, sinon elle est renseignée mais non utilisée pour la récursivité. Le comportement sur XR donne un niveau de rassurance, dans le cas où une adresse de transfert de LSA externe devient connue via une autre source, le trafic ne peut pas être mis en veille.