Dans le cadre de la documentation associée à ce produit, nous nous efforçons d’utiliser un langage exempt de préjugés. Dans cet ensemble de documents, le langage exempt de discrimination renvoie à une langue qui exclut la discrimination en fonction de l’âge, des handicaps, du genre, de l’appartenance raciale de l’identité ethnique, de l’orientation sexuelle, de la situation socio-économique et de l’intersectionnalité. Des exceptions peuvent s’appliquer dans les documents si le langage est codé en dur dans les interfaces utilisateurs du produit logiciel, si le langage utilisé est basé sur la documentation RFP ou si le langage utilisé provient d’un produit tiers référencé. Découvrez comment Cisco utilise le langage inclusif.
Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.
Ce document décrit l'interface de ligne de commande de simplification EVPN pour BGP VRF Auto RD et Auto RT dans EVPN sur les commutateurs de la gamme Catalyst 9000.
Cisco vous recommande de prendre connaissance des rubriques suivantes :
Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :
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.
Les déploiements EVPN de couche 3 impliquent des configurations VRF avec de nombreuses options de configuration, y compris, mais sans s'y limiter, le système de distinction de route (RD) et les cibles de route (RT).
La RD automatique serait constituée de l'ID de routeur BGP plus un numéro unique généré interne, par exemple, si l'ID de routeur BGP est 192.168.1.1, la RD automatique serait comme "192.168.1.1:1".
La possibilité de simplifier la configuration est hautement souhaitable (si elle n'est pas nécessaire) pour que le déploiement soit possible, et a déjà été largement adoptée pour le fabric EVPN BGP. Cette fonctionnalité est souhaitable pour EVPN, car elle permet d'éviter l'écriture et la maintenance de configurations étendues et complexes dans des topologies Spine-Leaf où de nombreux VRF sont configurés dans un leaf particulier.
Remarque : cette fonctionnalité introduit de nouvelles CLI.
VRF |
Transfert de routage virtuel |
Définit un domaine de routage de couche 3 qui peut être séparé des autres domaines de routage VRF et IPv4/IPv6 global |
AF |
Famille d'adresses |
Définit les préfixes de type et les informations de routage des handles BGP |
COMME |
Système Autonome |
Ensemble de préfixes IP routables sur Internet qui appartiennent à un réseau ou à un ensemble de réseaux qui sont tous gérés, contrôlés et supervisés par une seule entité ou organisation |
RD |
Distincteur de route |
Autoriser BGP à différencier un préfixe d'un autre dans différents VRF |
RT |
Cible de route |
Les cibles de routage sont utilisées pour contraindre les mises à jour de routage. Détermine les préfixes pouvant être importés par le périphérique |
EVPN |
Réseau privé virtuel Ethernet |
L'extension qui permet au BGP de transporter des informations MAC de couche 2 et IP de couche 3 est EVPN et utilise le protocole MP-BGP (Multi-Protocol Border Gateway Protocol) comme protocole pour distribuer les informations d'accessibilité relatives au réseau de superposition VXLAN. |
VXLAN |
Réseau local (LAN) virtuel extensible |
VXLAN est conçu pour surmonter les limitations inhérentes aux VLAN et au STP. Il s’agit d’une norme IETF proposée [RFC 7348] qui fournit les mêmes services réseau Ethernet de couche 2 que les VLAN, mais avec une plus grande flexibilité. Fonctionnellement, il s’agit d’un protocole d’encapsulation MAC-in-UDP qui s’exécute en tant que superposition virtuelle sur un réseau sous-jacent de couche 3. |
Leaf-01#sh run | include vrf rd-auto
vrf rd-auto <-- Enable Auto RD for all the VRFs
Leaf-01#sh run | section vrf definition blue
vrf definition blue
vnid 123 evpn-instance <-- Enable Auto RT
!
address-family ipv4 <-- address-family needs to be specified
route-target 100:123 <-- Optionally can have static route-target as required
exit-address-family
!
Leaf-01#sh run | section vrf definition green
vrf definition green
rd-auto <-- Enable Auto RD for this VRF green
vnid 35 evpn-instance <-- Enable Auto RT
!
address-family ipv4 <-- address-family needs to be specified
exit-address-family
!
address-family ipv6
exit-address-family
Remarque : il est possible d'avoir une RD statique et une RD automatique pour différents VRF, mais la RD statique ne doit PAS avoir la même RD réelle que la RD automatique si la RD automatique est affectée en premier.
Conseil : actuellement, la suppression de la RD statique supprimerait la configuration des routes-cibles configurées dans les VRF, ainsi que les familles d'adresses VRF IPv4 et/ou IPv6 BGP (et la configuration associée ci-dessous). Par conséquent, la suppression d'une RD automatique aurait un comportement similaire. Il est recommandé de ne pas déclencher la suppression de la RD sauf en cas d'absolue nécessité. Une modification de la distance annoncée (c'est-à-dire une suppression de la distance annoncée existante, statique ou automatique, puis l'ajout d'une nouvelle distance annoncée, statique ou automatique, est coûteuse et nécessite un certain délai pour que la commande soit exécutée)
vrf rd-auto
vrf definition green <-- This VRF green uses auto RD
vnid 35 evpn-instance
!
address-family ipv6
exit-address-family
vrf definition red <-- This VRF red uses static RD
rd-auto disable
rd 100:1
!
address-family ipv4
route-target export 100:1
route-target import 100:1
route-target export 100:1 stitching
route-target import 100:1 stitching
exit-address-family
(Cet exemple de configuration est une récapitulation de la fonctionnalité existante.)
Leaf-01#show run | sec r bgp router bgp 65000 <-- Required for Auto RT bgp router-id 192.168.1.1 <-- Required for Auto RD bgp log-neighbor-changes no bgp default ipv4-unicast neighbor 192.168.1.2 remote-as 65000 neighbor 192.168.1.2 update-source Loopback0 neighbor 192.168.1.3 remote-as 65001 neighbor 192.168.1.3 update-source Loopback0 ! address-family ipv4 vrf green
advertise l2vpn evpn
redistributed connected
exit-address-family
!
address-family ipv6 vrf green
advertise l2vpn evpn
redistribute connected
exit-address-family
Remarque : la configuration de l'autre réflecteur de route spine est la même. Par conséquent, ne répétez pas cette section
Remarque : d'autres leafs EVPN peuvent utiliser la configuration RD ou RT statique. Tant que le RT correspond, les préfixes EVPN peuvent s'importer/exporter les uns vers les autres.
Vérifiez le leaf pour avoir la RD automatique
VTEP1#show vrf blue Name Default RD Protocols Interfaces blue 192.168.1.1:1(auto) ipv4 Vl34 Lo101 Et1/1 Vl4 Vl15
VTEP1#show vrf green Name Default RD Protocols Interfaces green 192.168.1.1:2(auto) ipv6 Lo102 Et1/2 Vl5 Vl13
VTEP1#show vrf detail blue VRF blue (VRF Id = 2); default RD 192.168.1.1:1(auto); default VPNID New CLI format, supports multiple address-families vnid: 123 evpn-instance vni 35000 core-vlan 34 Flags: 0x180C Interfaces: Vl34 Lo101 Et1/1 Vl4 Vl15 Address family ipv4 unicast (Table ID = 0x2): Flags: 0x0 Export VPN route-target communities RT:100:123 RT:65000:123 (auto) Import VPN route-target communities RT:100:123 RT:65000:123 (auto) Export VPN route-target stitching communities RT:65000:123 (auto) Import VPN route-target stitching communities RT:65000:123 (auto) No import route-map No global export route-map No export route-map VRF label distribution protocol: not configured VRF label allocation mode: per-prefix Address family ipv6 unicast not active Address family ipv4 multicast not active Address family ipv6 multicast not active
VTEP1#show vrf detail green VRF green (VRF Id = 4); default RD 192.168.1.1:2(auto); default VPNID New CLI format, supports multiple address-families vnid: 35 evpn-instance Flags: 0x380C Interfaces: Lo102 Et1/2 Vl5 Vl13 Address family ipv4 unicast not active Address family ipv6 unicast (Table ID = 0x1E000002): Flags: 0x0 Export VPN route-target communities RT:65000:35 (auto) Import VPN route-target communities RT:65000:35 (auto) Export VPN route-target stitching communities RT:65000:35 (auto) Import VPN route-target stitching communities RT:65000:35 (auto) No import route-map No global export route-map No export route-map VRF label distribution protocol: not configured VRF label allocation mode: per-prefix Address family ipv4 multicast not active Address family ipv6 multicast not active
En cas de problème avec VRF auto RD auto RT, vous pouvez utiliser les débogages pour en savoir plus sur le problème
Activer les débogages appropriés
Leaf-01#debug ip bgp autordrt
Leaf-01#debug vrf create
Leaf-01#debug vrf delete
Affichage informations de débogage
VTEP1#show debug VRF Manager: VRF creation debugging is on VRF deletion debugging is on Packet Infra debugs: Ip Address Port ------------------------------------------------------|---------- IP routing: BGP auto rd rt debugging is on
Observer les débogages produits à chaque étape de configuration
Leaf-01(config)#vrf definition test *Jun 26 08:19:44.173: LID: Get id @0x7F4414FE4A18 - current A [1..2705] (checking enabled) *Jun 26 08:19:44.173: LID: AVAIL (verified) - id A *Jun 26 08:19:44.173: vrfmgr: VRF test: Created vrf_rec with vrfid 0xA *Jun 26 08:19:44.173: BGP: VRF config event of rd-auto change for vrf test *Jun 26 08:19:44.173: BGP-VPN: bgp vpn global rd-auto for vrf test assigns rd of 192.168.1.1:6 *Jun 26 08:19:44.173: BGP: VRF config event of vnid change for vrf test Leaf-01(config-vrf)#vnid 246 evpn-instance % vnid 246 evpn-instance auto (vni 0 core-vlan 0) is configured in "vrf test" *Jun 26 08:20:03.466: BGP: VRF config event of vnid change for vrf test Leaf-01(config-vrf)#address-family ipv4 *Jun 26 08:20:12.276: vrfmgr: VRF test ipv4 unicast: Received topology create notification *Jun 26 08:20:12.276: vrfmgr: VRF test ipv4 multicast: Received topology create notification *Jun 26 08:20:12.276: vrfmgr: VRF test ipv4 unicast: Created vrf_sub_rec with vrfid 0xA, tableid 0xA *Jun 26 08:20:12.276: BGP: VRF config event of vnid change for vrf test *Jun 26 08:20:12.276: BGP: afi 0 vrf test vnid 246 RT assign *Jun 26 08:20:12.276: BGP: vrf assign auto import stitching rt for VRF test *Jun 26 08:20:12.276: BGP: vrf assign auto export stitching rt for VRF test Leaf-01(config-vrf-af)#address-family ipv6 *Jun 26 08:20:20.949: vrfmgr: VRF test ipv6 unicast: Received topology create notification *Jun 26 08:20:20.949: vrfmgr: VRF test ipv6 multicast: Received topology create notification *Jun 26 08:20:20.949: vrfmgr: VRF test ipv6 unicast: Created vrf_sub_rec with vrfid 0xA, tableid 0x1E000004 *Jun 26 08:20:20.949: BGP: VRF config event of vnid change for vrf test *Jun 26 08:20:20.949: BGP: afi 0 vrf test vnid 246 RT assign *Jun 26 08:20:20.949: BGP: vrf assign auto import stitching rt for VRF test *Jun 26 08:20:20.949: BGP: vrf assign auto export stitching rt for VRF test *Jun 26 08:20:20.949: BGP: afi 1 vrf test vnid 246 RT assign *Jun 26 08:20:20.949: BGP: vrf assign auto import stitching rt for VRF test *Jun 26 08:20:20.949: BGP: vrf assign auto export stitching rt for VRF test Leaf-01(config-vrf-af)#do sh vrf detail test VRF test (VRF Id = 10); default RD 192.168.1.1:6(auto); default VPNID <-- VRF ID = 10 (hex 0xA) | auto RD assigned matches debug "assigns rd of 192.168.1.1:6" New CLI format, supports multiple address-families vnid: 246 evpn-instance Flags: 0x180C No interfaces Address family ipv4 unicast (Table ID = 0xA): Flags: 0x0 Export VPN route-target communities RT:65000:246 (auto) Import VPN route-target communities RT:65000:246 (auto) Export VPN route-target stitching communities RT:65000:246 (auto) Import VPN route-target stitching communities RT:65000:246 (auto) No import route-map No global export route-map No export route-map VRF label distribution protocol: not configured VRF label allocation mode: per-prefix Address family ipv6 unicast (Table ID = 0x1E000004): <-- ID matches debug "Created vrf_sub_rec with vrfid 0xA, tableid 0x1E000004" Flags: 0x0 Export VPN route-target communities RT:65000:246 (auto) Import VPN route-target communities RT:65000:246 (auto) Export VPN route-target stitching communities RT:65000:246 (auto) Import VPN route-target stitching communities RT:65000:246 (auto) No import route-map No global export route-map No export route-map VRF label distribution protocol: not configured VRF label allocation mode: per-prefix Address family ipv4 multicast not active Address family ipv6 multicast not active Leaf-01(config-vrf-af)#do sh run vrf test Building configuration... Current configuration : 145 bytes vrf definition test vnid 246 evpn-instance ! address-family ipv4 exit-address-family ! address-family ipv6 exit-address-family
Par défaut, Nexus attribue des routes-cibles basées sur le VNI (ASN : VNI), tandis que Catalyst attribue des routes-cibles basées sur le VNI (ASN : EVI).
Lorsque les routes-cibles ne correspondent pas, vous pouvez observer des symptômes tels que :
Il existe plusieurs options pour résoudre ce problème d'interopérabilité
Appliquez ces cli (pour l'option 2) sous la section l2vpn evpn
address-family l2vpn evpn
rewrite-evpn-rt-asn <---
Révision | Date de publication | Commentaires |
---|---|---|
1.0 |
18-Aug-2023 |
Première publication |