Deux PE, un préfixe : pourquoi le RD décide de la visibilité

Deux routeurs de bordure qui annoncent le même préfixe client décrivent une seule destination VPNv4 tant que quelque chose ne les sépare pas, et ce séparateur est le route distinguisher. Il qualifie le préfixe ; il ne décide pas qui importe le résultat, c’est le rôle du route target. Allouez les RD à partir de l’ensemble des routes qui doivent rester distinguables dans chaque domaine où ces annonces peuvent se rencontrer, et non à partir de l’agencement de fichiers d’une seule machine. Le numéro que vous choisissez est une identité dont dépendront les revues ultérieures, il a donc sa place dans un inventaire avant d’entrer dans une configuration.

Un RD plus un préfixe, une seule destination

Un RD plus un préfixe IPv4 forme la destination VPNv4 que compare le plan de contrôle. Donnez à deux PE le même préfixe pour des clients différents et, sans RD différents, ils annoncent des chemins vers une seule destination. Rien à l’écran ne vous dit que ce regroupement est faux, car la plateforme fait exactement ce que dit l’identité. Changez le RD sur l’un des deux et l’ancienne annonce est retirée tandis qu’une nouvelle apparaît sous une autre identité. Tout ce qui, en aval, reposait sur l’ancienne identité, de la sélection de route à un filtre opérateur enregistré, renvoie désormais à quelque chose qui n’existe plus.

Plusieurs chemins par destination est un comportement BGP ordinaire, pas un symptôme. Un speaker peut conserver plusieurs chemins reçus tout en sélectionnant un meilleur chemin pour le transfert, et l’écart entre reçu et sélectionné est là où vivent les questions de visibilité. Quand un chemin semble avoir disparu, vérifiez si l’identité à laquelle il appartenait existe encore avant de regarder la session.

Même RD, même destination, chemins différents

Envoyez un RD et un préfixe depuis deux routeurs pour le compte du même service et tous deux proposent des chemins vers une seule destination, généralement avec des sauts suivants différents. Lequel un route reflector propage est une décision sur le reflector : sa sélection de chemin, sa capacité d’annonce et toute politique superposée. Aucun des routeurs de bordure ne contrôle ce choix. Donnez aux deux annonces des RD distincts et chacune devient sa propre destination, de sorte que les deux peuvent survivre à un plan de contrôle qui autrement ne porte que le chemin sélectionné pour une identité.

Visibilité et multipath se rejoignent dans le VRF récepteur, mais ce ne sont pas la même décision, et un reflector portant deux identités n’a pas configuré de second chemin installé. Le VRF installe ce que sa politique d’importation admet et ce que son propre réglage de maximum de chemins autorise. Vérifiez ce réglage séparément lorsque vous voulez que le second chemin soit utilisé et pas seulement visible.

Une règle locale d’unicité n’est pas une politique

Donner à chaque PE et à chaque instance de routage son propre RD est une convention saine : elle nomme l’origine, empêche des services sans rapport d’entrer en collision sur une identité et donne à l’inventaire une clé stable. Certaines plateformes n’exigent l’unicité qu’à l’intérieur de la machine et permettent explicitement aux routeurs de partager un RD pour la même instance VPN. Cette permission est une contrainte d’implémentation, pas une règle inter-réseaux que vous pouvez déléguer à un fournisseur. Si le domaine couvre plusieurs équipes, rédigez vous-même la politique d’allocation.

L’appartenance ne vient jamais des chiffres. Un motif comme 65000:12 pour un PE et 65000:13 pour un autre est une habitude, alors que des cibles d’exportation et d’importation concordantes comme 65000:112 sont ce qui place une route dans un VRF. Traitez le RD comme l’identité d’une route et le route target comme la permission qui la porte dans un VRF.

Prouvez le changement sur le VRF, pas sur l’écran

Avant de toucher à un RD, notez quatre choses : ce que le PE annonce aujourd’hui, ce que le reflector reflète, ce que le VRF récepteur importe et quel chemin il sélectionne. Un nouveau RD retire une annonce et en introduit une autre, la modification apparaît donc des deux côtés de la session et se lit facilement de travers si vous ne surveillez que le côté annonceur. L’acceptation doit reposer sur la joignabilité voulue, pas sur une ligne supplémentaire apparue dans une liste de préfixes. Le tableau ci-dessous empêche les trois identifiants de se confondre pendant cette revue.

Partez du PE annonceur et comparez les deux identités pour le même préfixe avant de retirer quoi que ce soit. Les commandes IOS ci-dessous répondent à trois questions dans l’ordre : l’ancienne annonce est-elle toujours là, la nouvelle identité est-elle visible pour le reflector et le VRF sélectionne-t-il le préfixe.

show bgp vpnv4 unicast rd 65000:12 203.0.113.0/24
show bgp vpnv4 unicast rd 65000:13 203.0.113.0/24
show ip route vrf CUSTOMER-A 203.0.113.0/24

D’autres plateformes impriment les mêmes informations avec une autre syntaxe, et les questions survivent à ce changement. Si la nouvelle identité manque chez le reflector alors que le PE la liste comme annoncée, la politique ou la capacité d’annonce du reflector est le premier suspect, pas la numérotation.

Consignez le PE, l’instance, le RD, les cibles d’exportation et d’importation et la propriété du préfixe au même endroit, car l’allocation suivante n’est une consultation et non une supposition que lorsque cet enregistrement existe. Gardez l’ancien RD jusqu’à ce que la nouvelle identité soit visible dans le VRF récepteur, puis retirez-le dans un second temps afin que chaque étape reste réversible.