Lors de la conception d’un Backbone MPLS (Plus de 300 PE) pour un de mes clients, j’ai opté pour l’utilisation de l’IP unnumbered interface pour tous le liens point-à-point liant les routeurs PE aux routeur P ainsi que les liens interconnectant les PE entre eux. Lors de la discussion avec des collègues autour cette fonctionnalité, l’un d’entre eux m’a posé la question suivante :

Comment l’OSPF va monter entre deux voisins via des interfaces Unnumbered ? et c’est grâce à lui j’ai décidé de faire cet article.

Tout d’abord, c’est quoi un IP unnumbered ?

IP Unnumbered est une fonctionnalité qui permet à une interface IP de louer l’adresse IP d’une autre interface du routeur, généralement l’interface Loopback (car cette interface est toujours UP) au lieu d’avoir une adresse dédiée. Cette fonctionnalité est supportée depuis des années pour les interfaces de type Point-à-Point comme les interfaces Serial.

Pourquoi parles-tu de cette fonctionnalité si elle supportée seulement dans les interfaces Point-à-Point dans un monde ou l’Ethernet (Multi-Access) est dominant ?

Tout simplement parce qu’elle a été adoptée par les interfaces Ethernet pour ses avantages suivants :

  • Limiter la consommation des adresses IPv4 dans un monde ou l’adresse IPv4 publique devient précieuse.
  • Éliminer l’utilisation des petits subnets /30 ou /31 pour interconnecter des routeurs entre eux sans oublier ainsi leurs suivis dans notre fameux fichier Excel.
  • Faciliter la configuration des routeurs et rendre la configuration facilement automatisable.

Ok maintenant revenant à la question initiale, comment deux routeurs peuvent monter une session OSPF et deviennent voisins via une liaison point à point en utilisant IP Unnumbered.

Commençant tout d’abord par les fondamentaux et le process suivi par un routeur OSPF lors de l’établissement d’une session de voisinage OSPF.

  • Premièrement, le routeur OSPF doit s’identifier avec un identifiant unique, c’est le fameux routeur ID, c’est souvent l’adresse IP de l’interface Loopback, ou la plus grande adresse IP des interfaces physique du routeur.
  • La découverte des voisins et l’échange des LSA, le routeur OSPF envoi des messages Hello via toutes les interfaces qui participent dans le process OSPF. La fonctionnalité IP Unnumbered fonctionne seulement sur les interfaces OSPF de type Point-à-Point. Sachant que les messages Hello sont envoyés vers l’adresses IP multicast (All-Routers) 224.0.0.5. Donc en utilisant l’adresse Mac de l’interface Unnumbered et l’adresse IP louée comme source et l’adresse Mac Multicast et l’IP 224.0.0.5, le routeur peut envoyer des messages Hello via ses interfaces Point-à-Point. Cerise sur le gâteau, les routeurs OSPF peuvent monter une session OSPF via des interfaces de type Point-à-Point même si le masque IP des interfaces Loopback est différent.
  • La création de la base de données OSPF, rien de spécial, chaque routeur OSPF crée une base de données locale contenant des informations sur ces interfaces OSPF comme le nombre d’interface OSPF, leurs types, leurs métriques…etc, et échangent leurs bases de données locales LSDB avec les autres routeurs de la même aire via des mise à jour appelés Link State Update (LSU)
  • Finalement chaque routeur, démarre un algorithme appelé Shortest Path First (SPF) pour identifier le meilleur chemin ver vers chaque destination.
  • Le calcul effectué de l’étape précédente permet à chaque routeur de construire la table RIB (Routing Information Base). C’est tout, on peut maintenant acheminer le trafic entre deux routeurs ? Pas encore. Les routes de la table RIB doivent être programmées dans le plan de donnée (Data Plan) et pour cela on a besoin de deux informations :
    • La table FIB : qui contient seulement les meilleures routes vers chaque destination, cette table est extraite de la table RIB
    • La table Adjacency qui contient les Next-HOP de chaque route et leurs adresses Mac associées, généralement ces informations sont récupérées depuis la table ARP.

Vous voyez ou je veux en venir ? Non ? ce n’est pas grave, il y’a deux questions pour lesquelles, on doit venir avec une réponse :

Première question : C’est quoi l’adresse IP du Next-HOP pour un subnet connecté derrière un routeur OSPF voisin connecté via IP Unnumbered ?

Deuxième question : comment le routeur local trouve l’adresse Mac associé au Next-HOP pour établir sa table Adjacency ?

Pour répondre à ces deux questions. J’ai monté une maquette avec deux routeurs connectés via un lien Point-à-Point avec un subnet d’interconnexion/30 et deux routeurs connectés via un lien Point-à-Point en mode Unnumbered pour identifier toute différence entre les deux configurations, le schéma ci-dessous illustre le principe d’interconnexion :

Pour faciliter la lecture des debug, j’ai changé l’adresse Mac de l’interface Eth1/1 du routeur 1 en 0000.0000.0001 et celle du Routeur 2 en 0000.0000.0002.

Petite Note, j’ai utilisé dans ma maquette des Nexus 9000v.

Graphical user interface

Description automatically generated with medium confidence

Configuration OSPF avec un subnet d’interconnexion:

Routeur 1:

interface loopback0
ip address 1.1.1.1/32
ip ospf network point-to-point
ip router ospf 1 area 0.0.0.0
!
interface Ethernet1/1
no switchport
mac-address 0000.0000.0001
medium p2p
ip address 192.168.12.1/30
ip ospf network point-to-point
ip router ospf 1 area 0.0.0.0
no shutdown
!
router ospf 1

Routeur 2:

interface loopback0
ip address 2.2.2.2/32
ip ospf network point-to-point
ip router ospf 1 area 0.0.0.0
!
interface Ethernet1/1
no switchport
mac-address 0000.0000.0002
medium p2p
ip address 192.168.12.2/30
ip ospf network point-to-point
ip router ospf 1 area 0.0.0.0
no shutdown
!
router ospf 1

Configuration OSPF sans subnet d’interconnexion (IP Unnumbered):

Routeur 1:

interface loopback0
ip address 1.1.1.1/32
ip ospf network point-to-point
ip router ospf 1 area 0.0.0.0
!
interface Ethernet1/1
no switchport
mac-address 0000.0000.0001
medium p2p
ip unnumbered loopback0
ip ospf network point-to-point
ip router ospf 1 area 0.0.0.0
no shutdown
!
router ospf 1
Routeur 2:
interface loopback0
ip address 2.2.2.2/32
ip ospf network point-to-point
ip router ospf 1 area 0.0.0.0
!
interface Ethernet1/1
no switchport
mac-address 0000.0000.0002
medium p2p
ip unnumbered loopback0
ip ospf network point-to-point
ip router ospf 1 area 0.0.0.0
no shutdown
!
router ospf 1

Commençant par une vérification de l’etat de voisinage OSPF dans les deux configurations :

OSPF avec un Subnet d’interconnexion

OSPF avec Unnumbered Interface

L’état de voisinage OSPF :

Text

Description automatically generated

La session OSPF est en état Full ce qui signifie que les deux routeurs ont bien montés la session OSPF et ils ont échangés leurs Bases de données

Le champs « address » dans l’output ci-dessus affiche l’adresse IP de l’interface du routeur voisin utilisée pour l’interconnexion

L’état de voisinage OSPF :

La session OSPF est en état Full ce qui signifie que les deux routeurs ont bien montés la session OSPF et ils ont échangés leurs Bases de données

Le champs « address » dans l’output ci-dessus affiche normalement l’adresse IP louée par l’interface du routeur voisin utilisée pour l’interconnexion

Vérification de la base de données OSPF du Routeur 1 :

Text

Description automatically generated

3 liens OSPF :

  • Le Loopack (1.1.1.1) comme Stub Subnet
  • Lien d’interconnexion Point-à-Point au voisin 🡪 L’adresse d’interconnexion du routeur 192.168.12.1
  • Le Subnet d’interconnexion comme Stub Network (192.168.12.0)

Vérification de la base de données OSPF du Routeur 1 :

Text

Description automatically generated

2 liens OSPF :

  • Le Loopack (1.1.1.1) comme Stub Subnet
  • Lien d’interconnexion Point-à-Point au voisin 🡪 L’adresse d’interconnexion du routeur 0.0.0.2, je ne sais pas d’où ça vient !!!
  • Pas de subnet d’interconnexion 🡪 Réduction de la taille de la base de données OSPF

Vérifiant maintenant la table de routage (RIB) :

Text

Description automatically generated

Comme prévu, le routeur R1 installe une seule route dans sa table de routage :

  • Le 2.2.2.2 via le Nexthop 192.168.12.2

Vérifiant maintenant la table de routage (RIB) :

Text

Description automatically generated

Comme prévu, le routeur R1 installe une seule route dans sa table de routage :

  • Le 2.2.2.2 via le Nexthop 2.2.2.2(Génial, pour atteindre 2.2.2.2 il faut utiliser le 2.2.2.2 comme passerelle ça ne nous aide pas vraiment)

On a quoi dans la table ARP ?

Text

Description automatically generated

Ok, comme prévu l’ARP a fait la résolution du Next-Hop

On a quoi dans la table ARP ?

Text

Description automatically generated

Bizarrement, la table ARP est vide !!! Comment R1 peut envoyer des paquets à R2 alors ?

Est-ce que la route vers le 2.2.2.2/32 est installée dans la table FIB ?

Text

Description automatically generated

Parfait, la route est bien installée avec un le Next-hop 192.168.12.2

Est-ce que la route vers le 2.2.2.2/32 est installée dans la table FIB ?

Graphical user interface, text

Description automatically generated

Oui la route 2.2.2.2/32 est bien installée avec le Next-hop 2.2.2.2

Finalement, allons vérifier l’Adjacency table :

Text

Description automatically generatedTout va bien, le mapping entre le Next-HOP/adresse mac est présent.

Finalement, allons vérifier l’Adjacency table :

Rien dans la table Adjacency.pas de résolution de Next-hop donc pratiquement R ! ne pourra pas former un paquet ip pour joindre l’interface Loopback R 2

Un ping pour confirmer :

Text

Description automatically generated

Comme prévu, tout fonctionne

Et Ici ?

Text

Description automatically generated

J’ai perdu deux pings mais ça marche quand même.hmmm

Je me focalise sur l’IP Unnumbered solution

Je revérifie la table ARP :

Text

Description automatically generated

Et la table adjacency du routeur1 pour voir si on a quelque chose :

Text

Description automatically generated

R1 possède désormais une adresse Mac associée à 2.2.2.2 et c’est bien l’adresse Mac de l’interface Eth1/1 du R2, c’est normal, sinon comment il peut construire un paquet sans adresse Mac de destination.

Avant de lancer le ping, j’ai capturé le trafic sur l’interface Eth1/1 (bonne idée ☺)

Table

Description automatically generated with low confidence

Selon la capture,

  • Le routeur1 a envoyer une demande ARP (Request) demandant l’adresse Mac associée à l’IP 2.2.2.2 (Paquet Wireshark 16)
  • Le routeur1 a eu la réponse ARP (reply) comme quoi l’adresse Mac de l’IP 2.2.2.2 est 0000.0000.0002 (Paquet 17 de la capture Wireshark)
  • Finalement le Routeur1 a commencé l’envoi des paquets ICMP, cela explique pourquoi on a eu un ping perdu car Le routeur R1 a dû mettre à jour sa table ARP ainsi que la table Adjacency avec l’adresse Mac du Next-Hop et programmer la route dans le plan de donnée afin de pouvoir formuler des requêtes ICMP.

On peut déduire à partir de ces tests que l’adresse Mac du Next-HOP est récupérée via le protocole ARP lors de l’utilisation da fonctionnalité Unnumbered Interface dans les Cisco Nexus 9000.

Selon le RFC 5309, il existe 3 méthodes pour récupérer l’adresse Mac du Next-HOP :

  • Via l’ARP, la méthode utilisée par les Nexus 9000
  • Via une configuration statique –> configurer une entrée statique dans la table ARP
  • Récupérer l’adresse MAC source à partir des paquets envoyés par le routeur voisin si un protocole du routage est utilisé –> le routeur1 pouvait récupérer l’adresse Mac de l’interface Eth1/1 du routeur2 en inspectant les paquets Hello OSPF, cette méthode s’appelle ARP Gleaning

Dans cet article, on a exploré la fonctionnalité IP Unnumbered ses avantages et comment on peut router le trafic entre deux routeurs connectés via un lien Point-à-Point sans utiliser un subnet d’interconnexion.

Finalment si vous avez des questions, n’hésitez pas à laisser un message en commentaire de la page ou nous contacter à l’adresse : contact@mhd-experts.com

Author

Driss JABBAR Un Architect réseaux avec plus de 10 ans d'expérience dans la conception et l'implémentation des architectures complexes LAN/WAN/DC. Pendant son parcours professionnelle, Driss a travaillé chez des intégrateurs et aussi des opérateurs. Driss possède actuellement trois certifications d'expertise Cisco CCIE RS & SP et CCDE. En dehors du travail, Driss consacre plus de temps pour sa famille mais il réserve toujours un petit créneau pour apprendre des nouvelles technologies ou pour regarder un match de foot de son club préféré. Driss est contributeur du blog MHD et joignable à l’adresse : driss.jabbar@mhd-experts.com

Write A Comment