EVPN type 2 vs type 5 : pourquoi une adresse IP signifie deux routes

Deux routes sur la même machine peuvent pointer vers 198.51.100.77 et pourtant répondre à des questions différentes. L'une décrit où une adresse MAC est joignable et, éventuellement, quelle IP y est rattachée. L'autre décrit un préfixe qui se résout par un saut suivant, même lorsque ce préfixe est un hôte unique. Les confondre produit un ticket qui ressemble à un bogue de routage mais qui est en réalité un type de route mal lu.

Le moyen le plus rapide de les distinguer est de lire la clé autour de laquelle le NLRI est construit, pas le masque à son extrémité.

La clé de route indique ce que la route affirme

Le type 2 est la route d'annonce MAC/IP de RFC 7432, et sa clé est l'adresse MAC de 48 bits à l'intérieur du NLRI. Derrière cette clé se trouve un champ d'adresse IP dont le champ de longueur peut valoir 0, 32 ou 128 bits, si bien qu'une annonce MAC seule est une route complète et non une entrée d'hôte à laquelle il manque des morceaux. La pile d'étiquettes qui suit pointe vers le contexte de pont où cette MAC réside.

Que le champ IP soit rempli change ce que la route déclare, pas le type de route. Avec une longueur de 32 ou 128 bits, l'émetteur affirme aussi que cette IP appartient à cette MAC au sein d'une instance EVPN. Avec une longueur nulle, l'émetteur ne fait aucune affirmation sur l'IP. Aucune des deux versions ne dit qu'un préfixe est joignable via un routeur.

Le type 5 est la route de préfixe IP de RFC 9136, et sa clé est un préfixe écrit comme une longueur suivie d'autant de bits. La longueur va de 0 à 32 pour IPv4 et de 0 à 128 pour IPv6.

Les deux extrémités de cette plage sont légales, et aucune n'implique de MAC. Un préfixe de longueur nulle revendique la joignabilité sans nommer d'hôte, tandis qu'un /32 nomme exactement une adresse. Le NLRI porte aussi une adresse IP de passerelle que le côté sortant utilise pour construire l'index overlay, plus une étiquette pour le contexte de transfert. Il n'y a pas de champ MAC sur lequel commuter, c'est pourquoi un récepteur traite le type 5 comme une destination routée.

Une route de préfixe /32 n'est pas un type 2 renommé

Les préfixes de taille d'hôte sont des routes de type 5 ordinaires. Une route de préfixe /32 et un type 2 pour la même adresse peuvent coexister dans une instance EVPN, et ils portent des informations de transfert différentes.

Prenez 198.51.100.77 dans une instance EVPN utilisant VNI 10100. Un type 2 peut l'associer à la MAC 02:00:00:00:00:77 et à une étiquette identifiant le domaine de pont où cette MAC a été apprise. Un type 5 peut annoncer 198.51.100.0/24 pour tout le sous-réseau, ou 198.51.100.77/32 pour cette seule adresse, avec une adresse de passerelle pointant vers le VTEP de sortie. Les adresses se chevauchent volontairement parce que les routes répondent à des questions différentes.

Une route dit qu'une liaison de point de terminaison existe et qu'elle est joignable via un pont donné. L'autre dit qu'un préfixe est joignable via un routeur donné, qu'un point de terminaison à l'intérieur ait été appris ou non.

Cette différence décide où regarder en premier lorsque le trafic échoue. Si un hôte unique est injoignable alors que la route de son sous-réseau semble correcte, le type 5 n'était pas censé porter cet hôte ; cherchez le type 2 manquant. Si la route de l'hôte existe mais que tout le sous-réseau est injoignable, vérifiez si le type 5 a été créé. Lire les champs dans l'ordre vaut mieux que deviner d'après la longueur du masque.

Lire les deux routes sans deviner

Sur NX-OS, show bgp l2vpn evpn route type 2 et show bgp l2vpn evpn route type 5 séparent la table exactement selon cette ligne, et show l2route evpn mac ip montre les liaisons locales MAC-IP derrière les routes de type 2. Sur Junos, show evpn database liste les liaisons MAC et IP apprises tandis que show route table bgp.evpn.0 montre ce qui a été annoncé et reçu.

Filtrez par route distinguisher et par étiquette Ethernet avant de tirer des conclusions. La même MAC ou le même préfixe peut apparaître dans plusieurs instances EVPN, et une route qui semble fausse dans une instance peut être correcte dans une autre.

Lisez ensuite le NLRI dans l'ordre : type de route, clé, champs de passerelle ou d'étiquette, puis les route targets des attributs. Un type 2 portant un ESI non nul vous dit que la MAC est multi-homed, et c'est cette valeur qui relie les annonces de différents routeurs PE. Un type 5 portant une adresse de passerelle vous dit quel VTEP de sortie doit recevoir le trafic.

Si une route manque, vérifiez l'origine avant l'encodage. Confirmez que la source possède la liaison ou le préfixe localement, puis confirmez que le route target qui y est attaché est importé sur cette machine. La plupart des signalements de type 5 cassé se terminent sur une politique d'importation, pas sur le format du NLRI.

Notez le contexte, pas seulement le type de route

Notez ensemble le type de route, l'instance EVPN, le route distinguisher, les route targets importés et exportés et le saut suivant résolu. Un type 2 sans son instance est ambigu, et un saut suivant sans la famille de routes invite à une conclusion erronée.

Les deux sont des routes EVPN même lorsque la charge utile est une adresse IPv4. La famille d'adresses à l'intérieur du NLRI et la famille d'adresses de la route elle-même sont des propriétés distinctes, et un type 5 ne devient pas une route IPv4-unicast ou VPN-IPv4 simplement parce qu'il porte un préfixe IPv4.

Cette distinction apparaît à la frontière entre un plan de contrôle EVPN et un IP-VRF. Le route target décide quel VRF importe le préfixe, tandis que l'adresse de passerelle et l'étiquette décident comment le paquet est encapsulé vers la sortie. Lisez-les ensemble et la décision de transfert cesse de paraître arbitraire.

La prochaine fois qu'un /32 apparaît dans la table EVPN, vérifiez la clé avant le masque. Une clé MAC avec une IP facultative est une liaison de type 2 ; une clé de préfixe est une route de type 5 quelle que soit sa longueur. Écrivez le route target et le saut suivant à côté, et le prochain ingénieur n'aura pas à redériver toute l'histoire.