AFI et SAFI : lisez la paire avant le nom du service

Vous pouvez voir une session monter, une route apparaître, et lire malgré tout le mauvais service. La paire de nombres en tête de chaque annonce, l'identifiant de famille d'adresses et l'identifiant de famille d'adresses suivante, décide quel analyseur lit la charge et quelle table conserve le résultat. Trompez-vous sur la paire et la politique d'importation, la correspondance de route-target et la recherche du saut suivant s'exécutent toutes contre une structure que personne n'a annoncée. Le parcours ci-dessous part de cette paire et se termine au résultat du transfert.

Deux nombres décident de la table à laquelle la route appartient

La paire apparaît deux fois : à l'intérieur de la capacité multiprotocole, où un locuteur annonce une famille, et devant chaque NLRI que cette famille transporte. Cela en fait une propriété de la route plutôt qu'un réglage du boîtier d'origine. Les constructeurs l'impriment sous un nom comme Address family VPNv4 Unicast, et la formulation évolue d'une version à l'autre tandis que les nombres restent en place.

Quatre codages couvrent presque tous les cas d'entreprise : 1 avec 128 pour VPN-IPv4 étiqueté MPLS, 2 avec 128 pour l'équivalent IPv6, 25 avec 65 pour VPLS signalé par BGP, et 25 avec 70 pour EVPN. La première erreur est de supposer que tout service Layer 2 se trouve derrière 25 avec 65, ce qui masque EVPN. La deuxième est de traiter les deux familles IP comme une seule famille à adresse plus longue, alors qu'elles se négocient séparément et peuvent être acceptées sur des pairs différents. Une troisième apparaît quand un modèle est copié depuis une version qui n'en connaît qu'une. Une consultation du registre tranche les trois plus vite qu'une supposition bâtie sur le nom du service.

Traitez les quatre lignes comme des exemples du registre IANA, non comme le registre lui-même. Quand un nombre ne correspond à rien de connu, consultez-le avant de bâtir une politique autour.

AFI 25 transporte deux formats NLRI sans rapport

Les deux familles Layer 2 siègent sous AFI 25, et la ressemblance s'arrête là. Le NLRI VPLS de RFC 4761 section 3.2.2 transporte une longueur, un distinguateur de route, un VE ID, un décalage de bloc VE, une taille de bloc VE et une base d'étiquettes, qui nomment ensemble un point d'extrémité pseudowire et son étiquette. EVPN conserve AFI 25 et passe à SAFI 70, où la charge est un type de route : découverte automatique Ethernet, annonce MAC/IP, multicast inclusif, segment Ethernet, préfixe IP. Le même décalage d'octet signifie donc des choses différentes dans les deux familles. Un analyseur écrit pour l'une lit l'autre sans se plaindre et produit des absurdités. La paire est le seul avertissement que l'interprétation est fausse.

Un champ qui signifie décalage de bloc VE dans une famille n'a pas de pendant dans l'autre, et la route d'annonce MAC/IP n'existe qu'avec EVPN. Citer un attribut comme s'il valait pour les deux, c'est ainsi qu'une revue de capture tourne mal.

Quand quelqu'un vous remet une capture ou une table de constructeur, demandez à quelle famille appartient l'attribut. Confirmez ensuite que l'implémentation réceptrice prend en charge cette famille, et non le nom du service sur la fiche technique. Deux plateformes peuvent toutes deux revendiquer le support VPLS tout en implémentant des familles de signalisation différentes. La paire les sépare ; l'étiquette produit non.

La famille d'adresses de la session est une question distincte

VPN-IPv6 est couramment annoncé sur une session dont la connexion TCP passe par IPv4, et c'est une conception prise en charge, pas un défaut. Lire seulement le résumé de session ne dit donc rien des familles VPN que les pairs échangent.

Famille NLRI, famille de transport et famille de transfert sont trois décisions indépendantes. Un routeur peut parler IPv4 à son pair, accepter la joignabilité VPN-IPv6 et installer une route dont le saut suivant est une adresse IPv6 joignable par un chemin que vous n'aviez pas prévu. Chaque couche demande sa propre confirmation. Les sites qui signalent des destinations IPv6 injoignables alors que les annonces semblent correctes ont généralement perdu la résolution du saut suivant, pas la négociation des familles.

Testez la famille d'adresses de la session séparément, puis les familles qu'elle transporte, puis ce que le cœur peut transférer. Garder les trois séparées évite le diagnostic erroné courant où une annonce correcte est lue comme la preuve qu'IPv6 fonctionne de bout en bout. Elle ne prouve qu'un pair a parlé à un autre d'un préfixe.

Négocié, reçu, importé, installé

Pour une route attendue, quatre états doivent tenir dans l'ordre, et chacun est observable. La famille doit être négociée avec ce pair, la route doit arriver, un route-target doit l'importer dans le contexte prévu et le saut suivant doit se résoudre pour que la route s'installe. Sauter le premier état rend les trois autres sans réponse, car une famille non négociée ne produit aucune route à inspecter. Sur les plateformes de style Cisco, les résumés de famille et les capacités par pair sont des commandes distinctes.

show bgp all summary
show bgp vpnv4 unicast all summary
show bgp l2vpn evpn summary
show bgp neighbors <peer-address> | include Address family

La négociation apparaît dans l'échange de capacités imprimé par pair, et une session établie sans aucune famille listée ne transporte rien de ce que vous avez demandé. L'importation est décidée par les route-targets portés comme communautés étendues, si bien qu'une paire correcte avec une cible mal saisie laisse la table vide. L'installation dépend ensuite de la résolution du saut suivant dans le contexte récepteur, qui peut échouer alors que chaque annonce paraît parfaite.

Confirmez le plan de données en dernier, car une route dans la table est une affirmation, non une livraison. Les mêmes quatre états s'appliquent à chaque famille ; seuls les commandes et les noms de table changent.

Ce qu'une paire de familles ne prouve jamais

Lire correctement la paire vous dit comment interpréter l'information de routage qui suit, et c'est toute l'affirmation. Elle ne dit rien sur la joignabilité, rien sur la politique et rien sur la santé du plan de données. Confondre les deux produit des affirmations assurées sur un réseau que personne n'a vérifié. Un désaccord de route-target et un saut suivant cassé se ressemblent à l'identique vus de la seule paire. La paire est une consigne de lecture, jamais un verdict.

Quand vous escaladez, mettez la paire, le route-target et le saut suivant résolu dans la même note. L'ingénieur suivant dispose alors de trois choses indépendantes à tester au lieu d'un nom de service à réinterpréter. Si la négociation manque, il le voit aussitôt, une cible erronée laisse l'importation visiblement absente, et un saut suivant non résolu laisse la route présente mais inutilisable.