IPv6 dans un VPN MPLS : trois choix, pas une seule famille d'adresses
Les routes du VPN client, la session BGP entre les PE et le transport du cœur sont des décisions distinctes. Une session peut tourner dans une famille et en transporter une autre.
Dites « fais tourner un L3VPN IPv6 sur BGP IPv6 » en revue de conception, et trois décisions distinctes se cachent dans cette seule phrase. Quels préfixes appartiennent au VPN du client, quelles adresses portent la session de routage entre les bords de l'opérateur et quel cœur déplace le paquet étiqueté sont des choix indépendants. Ils peuvent tous être IPv6, ils peuvent être mélangés, et le mélange est permis exprès. C'est démêler les trois qui transforme une exigence vague en quelque chose contre quoi une plateforme peut être testée.
Séparez les trois tâches
La première tâche est la route client : des préfixes IPv6 qui appartiennent à un contexte de routage du VPN et doivent rester hors de tout autre contexte. La deuxième est la connexion de routage entre les routeurs de bord de l'opérateur qui échangent ces préfixes. La troisième est le transport qui achemine le paquet client étiqueté à travers le cœur jusqu'au bord distant. Nommer une seule des trois n'est pas encore une conception.
| Job | The question it answers | What confusion looks like |
|---|---|---|
| Customer VPN routes | Which IPv6 prefixes belong to each VPN context, and how are they kept apart? | Prefixes leak into the global table and between customers |
| PE-to-PE BGP session | Which addresses carry the routing connection between the two edges? | A session-family mismatch gets chased as a core transport fault |
| Transport to the remote PE | How does the chosen core move the labelled packet to the far edge? | A route is present and unforwardable in the same moment |
Chaque tâche a sa propre famille d'adresses, ses propres modes de défaillance et souvent sa propre équipe. Le tableau est utile précisément parce qu'une seule phrase dans un document de conception tend à écraser les trois lignes en une.
La famille de la route est VPN-IPv6, pas IPv6 unicast
RFC 4659 définit la famille BGP/MPLS IPv6 VPN, et en faire partie est plus précis que le mot IPv6 ne le suggère. Une route y est un discriminateur de route joint à un préfixe IPv6, encodé sous AFI 2 et SAFI 128. L'IPv6 unicast ordinaire est une autre famille, donc une annonce qui ressemble à un préfixe dans un looking glass n'est peut-être pas du tout le même objet. Mal lire la famille est la première façon dont cette conception tourne mal.
La différence mord au bord, où une route doit atterrir dans le bon contexte VPN avant de faire quoi que ce soit. Recevoir un préfixe prouve que l'échange a eu lieu et ne dit rien de l'installation. Cet écart produit le rapport classique où la session est montée et le client reste dans le noir.
La session peut tourner dans une famille différente du VPN
Rien n'oblige la connexion BGP entre deux bords à utiliser la famille du VPN elle-même. La spécification autorise une session IPv4 ou IPv6, et le transport IPv6 VPN est lui-même défini sur les deux types de cœur. Une session IPv6 ne dit donc rien de la famille de ce qu'elle transporte, et elle ne choisit pas non plus le plan de données. Trois bits indépendants, et la conception devrait porter les trois séparément.
Cela libère et se lit facilement de travers du même souffle. Les routes client IPv6 peuvent chevaucher une session adressée en IPv4, et les routes IPv4 une session IPv6, à condition que la plateforme prenne en charge la combinaison et que le saut suivant se résolve. Ce qui ne doit pas arriver, c'est de laisser la session impliquer la charge utile, dans le document de conception ou dans la supervision qui prouve le service plus tard.
Le saut suivant sur un cœur IPv4 a son propre encodage
Quand le cœur sous le VPN est IPv4, la route n'apparaît pas avec un saut suivant que le bord d'entrée peut utiliser directement. Elle arrive sous forme IPv6 mappée en IPv4, et c'est ainsi que la spécification exprime le bord de sortie quand le transport en dessous est IPv4. Le routeur d'entrée doit alors transformer cette adresse mappée en quelque chose qu'il peut réellement atteindre à travers le cœur, et la résolution est l'étape qui échoue en silence.
Lisez-le comme une dépendance de transfert et non comme une chaîne à copier entre équipements. Confirmez trois choses sur la plateforme que vous exploitez réellement : le saut suivant annoncé se résout en un chemin utilisable, la pile d'étiquettes est acceptée et la destination atterrit dans le contexte VPN prévu. Que l'une de ces vérifications échoue laisse une session qui semble saine et ne transfère rien, et c'est pourquoi le contrôle appartient à la recette d'acceptation plutôt qu'à un incident ultérieur.
Écrivez l'exigence en quatre lignes
Une exigence qui mérite d'être testée nomme quatre choses : la famille du VPN, le transport de la session, l'encodage du saut suivant et l'agencement du cœur. Elle nomme ensuite un préfixe client à suivre de bout en bout : à travers l'échange, l'installation, la résolution des étiquettes et le chemin de retour. « Prend en charge BGP IPv6 » ne couvre aucune des quatre et cache où se trouve réellement l'incohérence.
Une session saine sans l'échange VPN-IPv6 est incomplète, et une route VPN reçue sans transfert fonctionnel l'est tout autant. Les garder comme des lignes d'acceptation séparées rend courte la prochaine conversation de dépannage, parce que la ligne qui échoue est déjà écrite.