In diesem Dokument wird die Konfiguration von Route Leak auf Switches auf der Basis des Cisco Nexus NX-OS beschrieben.
Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:
Die Informationen in diesem Dokument basieren auf Cisco Nexus 7000 mit NX-OS 7.3(0)D1(1).
Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.
Sie müssen eine Route direkt von der Quell-VRF in die Ziel-VRF-Instanz leiten. Eine Route, die derzeit von einer anderen VRF-Instanz geleckt wird, kann nicht undicht werden.
Bedenken Sie, dass eine BGP-Sitzung vom Nexus zu einer Peer-IP nicht eingerichtet werden kann, wenn sie über eine andere VRF-Instanz auf dem Nexus geroutet wird.
Anmerkung: Wenn Routen zwischen VRF-Instanzen mit BGP undicht werden, kann es sein, dass Routenänderungen erst einige Minuten später in der Ziel-VRF-Instanz übernommen werden. Dies kann aufgrund von BGP-Dampening-Mechanismen geschehen, die Routenänderungen auf Basis von Metrikänderungen ignorieren, um Flapping-Fälle (z. B. Verbindungsprobleme) zu vermeiden, die nicht darüber hinaus propagiert werden sollen. Wenn Sie unter dieser Bedingung leiden und die Routen auch auf der Ziel-VRF-Instanz sofort aktualisieren müssen, lesen Sie bitte den Leitfaden "Konfigurieren von "dämpen-igp-metric" im BGP auf Cisco Nexus-Switches im Abschnitt "Zugehörige Informationen".
Das Leck zwischen VRFs erfolgt auf BGP-Prozessebene. Aus diesem Grund müssen die Routen zuerst dem BGP-Prozess hinzugefügt werden, und zwar in der BGP-Tabelle.
In diesem Fall hat Nexus in seiner Standard-VRF-Instanz zwei Routen über EIGRP erhalten. Die Konfiguration leckt die Routen in VRF BLAU.
Für dieses Beispiel ist nur die Route 192.168.2.0/24 ausgelaufen.
| Ausgabe der globalen Routing-Tabelle |
|---|
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# |

Verteilen Sie die Routen neu, die in der Standard-VRF-Routing-Tabelle im BGP vorhanden sind. Da sich die Routen in der Standard-VRF befinden, wird der Befehl redistribute im Abschnitt "global address-family ipv4 unicast" ausgeführt. Verwenden Sie den richtigen Parameter für den Befehl redistribute. Dies hängt davon ab, wie die Routen in der Standard-VRF-Instanz sind (direkt verbunden, eigrp, ospf usw.).
| Neuverteilung an BGP |
|---|
route-map ALL permit 10 |

Der Standard-Importbefehl für vrf wird in der Ziel-VRF-Instanz konfiguriert. Die Befehlszeile erfordert eine Route-Map als Parameter, um die zu importierenden Routen in der Ziel-VRF, in diesem Fall die VRF-Instanz mit dem Namen BLAU, explizit zu definieren.
| Konfigurieren der Standard-VRF-Importfunktion in der Ziel-VRF-Instanz |
|---|
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 |

Sie können im Ziel-VRF bestätigen, dass die Routen jetzt über BGP erkannt werden. Diese BGP-Routen im VRF können nun in einem anderen Routing-Protokoll, das im gleichen VRF ausgeführt wird, neu verteilt werden.
| Überprüfen der Ziel-VRF-Routing-Tabelle |
|---|
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# |

In diesem Fall hat Nexus zwei Routen in seiner VRF-Instanz erhalten, die RED via EIGRP heißen. Die Konfiguration leckt die Routen in VRF BLAU.
| Ausgabe der VRF ROT-Routing-Tabelle |
|---|
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# |

Verteilen Sie die Routen, die in der VRF RED-Routing-Tabelle im BGP vorhanden sind. Da die Routen in VRF RED enthalten sind, wird der Befehl redistribute im BGP unter den Unicast-Abschnitt "vrf RED address-family-ipv4" eingefügt.
| Neuverteilung an BGP |
|---|
route-map ALL permit 10 |

Um eine Verbindung zwischen VRFs herzustellen, müssen Route-Targets verwendet werden. Die Ursprungs-VRF-Instanz exportiert einen Route-Target-Wert. Die Ziel-VRF-Instanz importiert denselben Route-Target-Wert.
| Route Targets für Export und Import erstellen |
|---|
vrf context RED |

Sie können im Ziel-VRF bestätigen, dass die Routen jetzt über BGP erkannt werden. Diese BGP-Routen im VRF können nun in einem anderen Routing-Protokoll, das im gleichen VRF ausgeführt wird, neu verteilt werden.
| Überprüfen der Ziel-VRF-Routing-Tabelle |
|---|
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# |

Sie können optional den Befehl export map unter dem Ursprungs-VRF verwenden, um Route-Targets bestimmten zu exportierenden Routen zuzuweisen. Verwenden Sie den Parameter set extcommunity rt in der Route-Map, um das Route-Target zuzuweisen.
In diesem Beispiel wird nur das Netzwerk 192.168.2.0/24 mit dem Route-Target 1:1 exportiert, das später in VRF BLAU importiert wird.
Das Ergebnis ist, dass nur das angegebene Netzwerk undicht ist.
| Zuweisen von Route Target zu bestimmten Routen |
|---|
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 hat in seiner VRF-Instanz zwei Routen erhalten, die als RED über EIGRP bezeichnet werden. Die Konfiguration leckt die Routen in der Standard-VRF-Instanz.
Für dieses Beispiel ist nur die Route 192.168.2.0/24 ausgelaufen.

Verteilen Sie die Routen, die in der VRF RED-Routing-Tabelle im BGP vorhanden sind. Da die Routen in VRF RED enthalten sind, wird der Befehl redistribute im BGP unter den Unicast-Abschnitt "vrf RED address-family-ipv4" eingefügt.
| Neuverteilung an BGP |
|---|
route-map ALL permit 10 |

Der Befehl export vrf default wird im Ursprungs-VRF konfiguriert. Die Befehlszeile erfordert eine Routing-Map als Parameter, um die im Standard-VRF zu exportierenden Routen explizit zu definieren.
| VRF-Standard für Export in der Ursprungs-VRF-Instanz konfigurieren |
|---|
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 |

Sie können im Standard-VRF bestätigen, dass die Routen jetzt über BGP erkannt werden. Diese BGP-Routen im Standard-VRF können nun in einem anderen Routing-Protokoll neu verteilt werden, das ebenfalls im Standard-VRF ausgeführt wird.
| Überprüfen der Standard-VRF-Routing-Tabelle |
|---|
Nexus# show ip route |

Der VRF-Route-Leak-Prozess besteht aus vier Phasen. Die Überprüfung kann in folgender Reihenfolge durchgeführt werden:

Um zu überprüfen, ob die Routen in der Routing-Tabelle korrekt sind, lautet der Befehl:
show ip route [vrf]
Um zu überprüfen, ob die Routen in der BGP-Tabelle korrekt sind, lauten die Befehle:
Beachten Sie, dass der zweite Befehl austauschbar verwendet werden kann, um IPv4-Unicast-Adressen in der BGP-Tabelle anzuzeigen.
show bgp ipv4 unicast [vrf] show ip bgp [vrf ]
Schließlich kann die Show Forwarding Route A.B.C.D/LEN [VRF <VRF-Name>] verwendet werden, um die auf Line Card-Ebene programmierte Layer 3-Route zu bestätigen (Hardware-Programmierung).
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#
Konfigurieren von "dämpfen-igp-metric" im BGP auf Cisco Nexus-Switches
| Überarbeitung | Veröffentlichungsdatum | Kommentare |
|---|---|---|
6.0 |
28-Jul-2026
|
Rezertifizierung |
5.0 |
08-Jan-2026
|
Hinweis zu Einschränkungen und Artikel zum Abschnitt "Zugehörige Informationen" hinzugefügt. |
4.0 |
15-Nov-2024
|
Vergrößerte Bilder, um sie klarer zu machen.
Aktualisierter Alternativer Text und Formatierung. |
1.0 |
20-Nov-2018
|
Erstveröffentlichung |