L3VPN : routes privées, route par défaut ou table complète ?

Votre circuit est opérationnel, le VRF est configuré et le fournisseur pose une question courte qui décide du reste du design : que doit recevoir le bord client ? Trois réponses sont courantes, et aucune ne découle de l’existence d’une pile d’étiquettes. Ce sont des décisions de service sur l’endroit où le trafic quitte l’agence.

Parcourir la remise dans l’ordre est le moyen le moins coûteux de réussir. Vous partez de ce qui arrive au trafic qui ne correspond à rien, puis vous notez les préfixes privés et leur comportement en cas de panne, et seulement ensuite vous parlez de la taille du flux que vous acceptez de transporter.

Commencez par le trafic que personne n’avait prévu

Posez une question avant qu’apparaisse la moindre liste de préfixes : quand un paquet ne correspond à aucune route privée, où doit-il aller ? Une agence dotée de son propre circuit internet conserve généralement une route par défaut locale, si bien que le trafic web ordinaire sort par le pare-feu local et ne touche jamais le fournisseur. Dans ce design, le VPN ne transporte que les sites privés distants, et les préfixes plus spécifiques font la sélection.

Une agence censée utiliser une sortie centrale est le cas inverse. Là, la route par défaut pointe vers le service, et le fournisseur ou le site central possède le transfert, le retour et toute traduction. Dire « par défaut vers le VPN » sans ce propriétaire produit une agence qui résout les noms et n’atteint rien.

Les deux designs diffèrent par l’allure d’une panne de routage, et c’est pourquoi deviner coûte cher. Avec une route par défaut locale, une route privée perdue envoie ce trafic vers internet, où le pare-feu le rejette ou, pire, quelque chose que vous n’aviez pas prévu y répond. Avec une route par défaut centrale, la même perte supprime totalement l’accès internet et le ticket arrive sous la forme « toute l’agence est en panne ». Aucune des deux pannes n’est fausse en soi, mais une seule correspond au service vendu, et une configuration BGP seule ne vous dira pas laquelle vous avez construite.

Notez les préfixes privés avec leur cas de panne

Listez les préfixes que l’agence doit atteindre et notez lesquels sont résumés. Un agrégat d’un bit trop large attire des destinations inconnues dans le VPN, ce qui n’est acceptable que si le côté distant les possède réellement et les transfère.

Décrivez ensuite le comportement attendu lorsque le service privé tombe. Une route de rejet maintenue tient le trafic à l’écart d’un chemin non autorisé et produit une coupure nette et attendue. Une route par défaut flottante peut préserver la disponibilité en basculant vers un chemin de secours, mais seulement si ce chemin est autorisé à porter ce trafic.

Gardez la disponibilité et le repli autorisé comme deux exigences distinctes dans le document de remise. Les équipes qui les fusionnent finissent par débattre de savoir si l’agence aurait dû tomber, au lieu de vérifier si la politique convenue a été appliquée.

Vérifiez ce que le CE a réellement installé

L’intention de configuration et l’état de transfert divergent assez souvent pour que la vérification relève de la remise, et non de la revue d’incident. Sur un bord client IOS-XE, les trois commandes ci-dessous répondent à trois questions différentes : ce qui a été proposé, ce qui a été accepté et ce qui est réellement utilisé.

show ip bgp vpnv4 vrf BRANCH neighbors 192.0.2.1 received-routes
show ip bgp vpnv4 vrf BRANCH
show ip route vrf BRANCH 0.0.0.0

Exécutez les trois le jour de la remise plutôt qu’un mois plus tard, tant que quelqu’un se souvient encore de ce qui a été convenu. La première sortie dépend de soft-reconfiguration inbound ou d’un rafraîchissement de routes stocké ; sans l’un ou l’autre, le CE ne peut pas vous montrer ce qu’il a rejeté. La seconde montre les routes acceptées et les meilleures après politique. La troisième vous dit où va réellement la route par défaut, et c’est la ligne la plus utile de toute la remise.

Exécutez les mêmes contrôles sur un second CE si le site est relié par deux liens. Une acceptation asymétrique entre deux bords est une cause fréquente du « ça marche depuis un serveur et pas depuis l’autre », et elle est invisible dans un diff de configuration qui paraît symétrique.

Qualifiez un flux plus large au lieu de le supposer

Parfois le client a réellement besoin des informations de routage internet dans le VRF, pour du routage par politique ou pour une sortie centrale qui dirige par préfixe. C’est une exigence à énoncer, à cadrer et à facturer, pas un défaut caché. Elle s’accompagne de mémoire pour la RIB et la FIB, de CPU pour les mises à jour, de maintenance de filtres et d’un propriétaire pour la table résultante.

Les arguments de capacité se trompent dans les deux sens. Une table complète n’est pas interdite dans un VRF, et elle n’est pas gratuite non plus. De même, vous ne pouvez pas déduire le coût actuel d’un ancien nombre de routes, et une allocation d’étiquettes plus petite ne supprime pas le coût de stockage des routes.

La spécification BGP/MPLS IP VPN examine plusieurs dispositions d’accès internet à côté du service VPN lui-même, et elle ne déclare obligatoires ni une table complète ni une route par défaut pour chaque client, et c’est la section à montrer quand surgit une affirmation sur la « pratique standard » : RFC 4364.

Clôturez la remise en consignant l’ensemble annoncé, l’ensemble reçu et l’ensemble sélectionné à côté de la politique de sortie convenue, et en testant une destination privée, une destination publique prévue et un cas de perte de route. Un relevé signé de ces trois tests règle plus de discussions que toute affirmation sur ce que font la plupart des réseaux.