Route nulle NX-OS EVPN : garder le rejet à l’intérieur d’un seul tenant

La demande arrive comme une modification d’une ligne : blackholer une adresse. Vous ajoutez une route d’hôte vers Null0 dans le contexte du tenant, le préfixe disparaît de la table locale comme prévu, et les questions commencent. La route a-t-elle quitté l’équipement ? Les VTEP distants ont-ils rejeté, ou ont-ils simplement perdu la joignabilité ? Un second tenant est-il désormais affecté ?

Une route statique locale correcte ne répond qu’à la première de ces questions, ce qui explique pourquoi un changement de blackhole représente en réalité trois résultats vérifiés et non une seule commande.

Ce que le changement doit réellement produire

Commencez par écrire les trois résultats. Le tenant visé doit rejeter la destination localement. Seule la route autorisée peut être exportée, sans rien d’autre qui voyage avec elle. Chaque VTEP récepteur doit sélectionner l’action de rejet prévue et non un autre chemin.

Chaque résultat a ses propres preuves, et aucun n’implique les autres. Une route Null0 locale produit un rejet local et, sans redistribution, n’exporte absolument rien. Une route redistribuée sans la community convenue arrive comme un préfixe ordinaire et est transférée. Une community sans la politique de réception peut être totalement ignorée.

Écrire les résultats d’abord vous protège aussi d’un échec courant : un changement qui semble fonctionner parce que la destination était déjà injoignable pour une raison sans rapport. Si vous ne pouvez pas décrire comment vous distingueriez les deux cas, le test d’acceptation n’est pas encore conçu.

L’instruction locale ne fait que la première partie

Pour NX-OS dans la branche 10.4(x), la route nulle se trouve dans le contexte VRF du tenant plutôt que dans une commande unique qui nomme la VRF. Le fragment est court, et il n’est absolument pas une configuration EVPN complète.

vrf context TENANT_A
  ip route 192.0.2.10/32 Null0

L’adresse est un préfixe de documentation, pas une cible. Notez la différence de syntaxe avec IOS, où le nom de la VRF apparaît à l’intérieur de la commande de route elle-même, et confirmez la forme prise en charge pour la version que vous exploitez réellement avant de coller quoi que ce soit.

À elle seule, cette ligne rejette le trafic vers cet hôte dans TENANT_A et ne fait rien d’autre. Elle ne marque pas la route, ne la sélectionne pas pour BGP et ne définit pas de community. Ce sont des décisions de configuration distinctes, et chacune est un endroit où le changement peut être trop étroit pour fonctionner ou trop large pour être sûr.

Le rejet local affecte aussi le trafic légitime vers la même destination. Si l’intention est d’arrêter une source abusive alors que de vrais utilisateurs ont encore besoin de l’adresse, une route nulle est le mauvais outil et vous l’apprendrez au premier appel au support.

Export et import sont des accords distincts

La redistribution est l’endroit où le périmètre se décide. Limitez les préfixes éligibles à l’atténuation approuvée, gardez-la dans le tenant et limitez les peers d’origine à ceux du design. Redistribuer toutes les routes statiques parce qu’une route d’hôte marquée doit voyager est la façon dont un changement de maintenance devient un incident de routage.

La community BLACKHOLE est un accord sur une valeur bien connue, pas une autorisation pour n’importe quel voisin de rejeter n’importe quelle adresse. Le RFC 7999 la décrit en ces termes, et la frontière de confiance autour de qui peut l’annoncer fait partie de la conception et non d’un détail d’implémentation.

Le côté récepteur a besoin de sa propre configuration. Sur NX-OS, les routes nulles de type 5 exigent un traitement route-map sur le VTEP pour sélectionner le comportement de rejet, ce qui est documenté avec les étapes d’export. Un équipement émetteur qui marque correctement et un récepteur qui ignore le marquage produisent un changement qui semble appliqué et qui transfère le trafic malgré tout.

Examinez la route-map pour ses effets de bord pendant que vous y êtes. Une politique nouvellement restrictive peut supprimer une joignabilité légitime pour des préfixes sans rapport, et ce dommage apparaît plus tard que le blackhole et est plus difficile à lui attribuer.

Écrivez le retrait avant l’insertion

Consignez le propriétaire de la destination, la raison, l’approbateur et une échéance avant que quoi que ce soit ne soit configuré. Un rejet sans échéance devient une entrée permanente dont personne ne se rappelle l’origine, et la prochaine personne qui déboguera l’adresse la traitera comme une partie normale du réseau.

Conservez un chemin de gestion indépendant qui ne dépend pas de la route que vous modifiez. Si l’atténuation couvre une adresse que vous utilisez pour joindre l’équipement, vous avez créé un verrouillage avec des étapes supplémentaires.

Nommez le contrôle exact qui retire l’atténuation et testez ce retrait en laboratoire ou pendant une fenêtre que vous pouvez vous permettre. Un retrait que personne n’a répété est un plan et non une procédure.

Acceptez avec des preuves, pas avec la sortie de la commande

Vérifiez l’état de routage sélectionné et l’état de transfert sur les VTEP visés, et vérifiez une destination voisine qui doit rester intacte. Confirmez qu’aucun autre tenant n’a importé le préfixe, car une fuite entre tenants est le mode de défaillance qui transforme une action de maintenance en incident.

Retirez ensuite et vérifiez que la route normale et le service reviennent. Le guide des routes nulles NX-OS EVPN pour la version 10.4(x) documente le marquage, la redistribution et la politique de réception décrits ici, et c’est la référence à confronter à votre propre version.