Ce document décrit comment configurer la fuite de route sur les commutateurs basés sur Cisco Nexus NX-OS.
Cisco vous recommande de prendre connaissance des rubriques suivantes :
Les informations contenues dans ce document sont basées sur Cisco Nexus 7000 avec NXOS version 7.3(0)D1(1).
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.
Vous devez faire passer une route directement du VRF source dans le VRF cible. Vous ne pouvez pas laisser fuir une route qui est actuellement divulguée à partir d'un autre VRF.
Considérez qu'une session BGP du Nexus ne peut pas être établie vers une adresse IP homologue lorsqu'elle est routée via un VRF différent sur le Nexus.
Remarque : Lorsque des routes fuient entre des VRF avec BGP, vous pouvez constater que les changements de route ne sont pas reflétés dans le VRF de destination avant quelques minutes. Cela peut se produire en raison des mécanismes d'amortissement BGP qui ignorent les changements de route basés sur les changements de métrique pour éviter les cas dans lesquels un IGP est instable (problèmes de liaison, par exemple) et vous ne voulez pas que ces instabilités soient propagées au-delà. Si vous souffrez de cette condition et que vous avez besoin que les routes soient immédiatement mises à jour sur le VRF de destination également, veuillez consulter le guide, Configure dampen-igp-metric in BGP on Cisco Nexus Switches, dans la section Related Information.
La fuite entre les VRF est effectuée au niveau du processus BGP. Pour cette raison, il est nécessaire d'ajouter d'abord les routes au processus BGP, en particulier dans la table BGP.
Dans ce cas, Nexus a reçu deux routes dans son VRF par défaut via EIGRP. La configuration laisse passer les routes en VRF BLUE.
Dans le cadre de cet exemple, seule la route 192.168.2.0/24 est divulguée.
| Sortie de la table de routage globale |
|---|
Nexus# show ip route eigrp
IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>
172.16.2.2/32, ubest/mbest: 1/0
*via 10.1.2.2, Eth2/1, [90/130816], 00:00:21, eigrp-1, internal
192.168.2.0/24, ubest/mbest: 1/0
*via 10.1.2.2, Eth2/1, [90/130816], 00:00:21, eigrp-1, internal
Nexus# |

Redistribuez les routes qui existent dans la table de routage VRF par défaut dans BGP. Puisque les routes sont dans le VRF par défaut, la commande redistribute dans BGP passe sous la section globale address-family ipv4 unicast. Utilisez le paramètre correct pour la commande redistribute. Cela dépend de la manière dont les routes se trouvent dans le VRF par défaut (directement connecté, eigrp, ospf, etc.).
| Redistribuer dans BGP |
|---|
route-map ALL permit 10 |

La commande import vrf default est configurée dans le VRF de destination. La ligne de commande requiert une route-map en tant que paramètre afin de définir explicitement les routes à importer dans le VRF de destination, qui dans ce cas est le VRF nommé BLUE.
| Configuration du VRF d'importation par défaut dans le VRF de destination |
|---|
ip prefix-list NETWORK seq 5 permit 192.168.2.0/24
!
route-map GLOBAL-TO-VRF permit 10
match ip address prefix-list NETWORK
!
vrf context BLUE
address-family ipv4 unicast
import vrf default map GLOBAL-TO-VRF |

Vous pouvez confirmer dans le VRF de destination que les routes sont maintenant vues via BGP. Ces routes BGP dans le VRF peuvent maintenant être redistribuées dans tout autre protocole de routage qui s'exécute dans le même VRF.
| Vérification de la table de routage VRF de destination |
|---|
Nexus# show ip route vrf BLUE
IP Route Table for VRF "BLUE"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>
192.168.2.0/24, ubest/mbest: 1/0
*via 10.1.2.2%default, Eth2/1, [20/130816], 00:15:00, bgp-65535, external, tag 65535,
Nexus# |

Dans ce cas, Nexus a reçu deux routes dans son VRF appelé RED via EIGRP. La configuration laisse passer les routes en VRF BLUE.
| Sortie de la table de routage VRF RED |
|---|
Nexus# show ip route eigrp vrf RED
IP Route Table for VRF "RED"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>
172.16.2.2/32, ubest/mbest: 1/0
*via 10.1.2.2, Eth2/1, [90/130816], 00:00:08, eigrp-1, internal
192.168.2.0/24, ubest/mbest: 1/0
*via 10.1.2.2, Eth2/1, [90/130816], 00:00:08, eigrp-1, internal
Nexus# |

Redistribuez les routes qui existent dans la table de routage VRF RED dans BGP. Puisque les routes sont dans le VRF RED, la commande redistribute dans BGP passe sous la section unicast vrf RED address-family ipv4.
| Redistribuer dans BGP |
|---|
route-map ALL permit 10 |

Afin d'assurer une fuite entre les VRF, l'utilisation de route-cibles est requise. Le VRF d'origine exporte une valeur route-cible. Le VRF de destination importe la même valeur route-cible.
| Création de cibles de routage d'exportation et d'importation |
|---|
vrf context RED |

Vous pouvez confirmer dans le VRF de destination que les routes sont maintenant vues via BGP. Ces routes BGP dans le VRF peuvent maintenant être redistribuées dans tout autre protocole de routage qui s'exécute dans le même VRF.
| Vérification de la table de routage VRF de destination |
|---|
Nexus# show ip route vrf BLUE
IP Route Table for VRF "BLUE"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>
172.16.2.2/32, ubest/mbest: 1/0
*via 10.1.2.2%RED, Eth2/1, [20/130816], 00:01:58, bgp-65535, external, tag 65535,
192.168.2.0/24, ubest/mbest: 1/0
*via 10.1.2.2%RED, Eth2/1, [20/130816], 00:01:58, bgp-65535, external, tag 65535,
Nexus# |

Vous pouvez éventuellement utiliser la commande export map sous le VRF d'origine afin d'affecter des cibles de routage à des routes spécifiques à exporter. Utilisez le paramètre set extcommunity rt dans la carte de routage afin d'affecter la cible de routage.
Dans cet exemple, seul le réseau 192.168.2.0/24 est exporté avec Route-Target 1:1 qui est importé ultérieurement en VRF BLUE.
Il en résulte que seul le réseau spécifié est sujet à des fuites.
| Affectation de route-cible à des routes spécifiques |
|---|
ip prefix-list NETWORK seq 5 permit 192.168.2.0/24
!
route-map ADD-RT permit 10
match ip address prefix-list NETWORK
set extcommunity rt 1:1
!
vrf context RED
address-family ipv4 unicast
export map ADD-RT
!
vrf context BLUE
address-family ipv4 unicast
route-target import 1:1 |
Nexus a reçu deux routes dans son VRF appelé RED via EIGRP. La configuration laisse échapper les routes dans le VRF par défaut.
Dans le cadre de cet exemple, seule la route 192.168.2.0/24 est divulguée.

Redistribuez les routes qui existent dans la table de routage VRF RED dans BGP. Puisque les routes sont dans le VRF RED, la commande redistribute dans BGP passe sous la section unicast vrf RED address-family ipv4.
| Redistribuer dans BGP |
|---|
route-map ALL permit 10 |

La commande export vrf default est configurée dans le VRF d'origine. La ligne de commande requiert une route-map en tant que paramètre afin de définir explicitement les routes à exporter dans le VRF par défaut.
| Configuration du VRF d'exportation par défaut dans le VRF d'origine |
|---|
ip prefix-list NETWORK seq 5 permit 192.168.2.0/24
!
route-map GLOBAL-TO-VRF permit 10
match ip address prefix-list NETWORK
!
vrf context RED
address-family ipv4 unicast
export vrf default map GLOBAL-TO-VRF |

Vous pouvez confirmer dans le VRF par défaut que les routes sont maintenant vues via BGP. Ces routes BGP dans le VRF par défaut peuvent maintenant être redistribuées dans tout autre protocole de routage qui s'exécute également dans le VRF par défaut.
| Vérification de la table de routage VRF par défaut |
|---|
Nexus# show ip route |

Le processus de fuite de route VRF comporte 4 phases. La vérification peut être effectuée dans l'ordre suivant :

Afin de vérifier que les routes sont correctement dans la table de routage, la commande est :
show ip route [vrf]
Afin de vérifier que les routes sont correctement dans la table BGP, les commandes sont :
Notez que la deuxième commande peut être utilisée de manière interchangeable afin d'afficher les adresses de monodiffusion IPv4 dans la table BGP.
show bgp ipv4 unicast [vrf] show ip bgp [vrf ]
Enfin, la commande show forwarding route A.B.C.D/LEN [VRF <vrf name>] peut être utilisée afin de confirmer la route de couche 3 programmée au niveau de la carte de ligne (programmation matérielle).
Nexus# show forwarding route 10.1.2.2 slot 1 ======= IPv4 routes for table default/base '*' denotes recursive route ----------------+----------------------------------------+----------------------+----------------- Prefix | Next-hop | Interface | Labels ----------------+----------------------------------------+----------------------+----------------- 10.1.2.0/24 Attached Ethernet2/1 Nexus#
Configurez dampen-igp-metric dans BGP sur les commutateurs Cisco Nexus
| Révision | Date de publication | Commentaires |
|---|---|---|
6.0 |
28-Jul-2026
|
Recertification |
5.0 |
08-Jan-2026
|
Ajout d'une note aux restrictions et ajout d'un article à la section Informations connexes. |
4.0 |
15-Nov-2024
|
Images agrandies pour plus de clarté.
Mise à jour du texte de remplacement et de la mise en forme. |
1.0 |
20-Nov-2018
|
Première publication |