Résolution des problèmes de transmission EVPN RMAC ExtCommunity vers le fabric ACI

Options de téléchargement

PDF (1.0 MB)
Consulter à l'aide d'Adobe Reader sur un grand nombre d'appareils
ePub (726.4 KB)
Consulter à l’aide de différentes applications sur iPhone, iPad, Android ou Windows Phone
Mobi (Kindle) (1.0 MB)
Consulter sur un appareil Kindle ou à l’aide d’une application Kindle sur plusieurs appareils

Mis à jour:13 juin 2023

ID du document:220473

Langage exempt de préjugés

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.

À propos de cette traduction

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.

Table des matières

Introduction

Informations générales

Problème

Introduction

Ce document décrit l'impact d'un attribut de communauté étendue MAC de routeur mal configuré sur un fabric ACI lorsqu'il est reçu d'un homologue BGP externe.

Informations générales

Avec BGP, il y a une option pour envoyer des attributs de communauté et de communauté étendue avec les préfixes qui sont annoncés aux homologues BGP. Ces attributs de communauté nous permettent de modifier les politiques de routage et de modifier dynamiquement la façon dont le trafic routé est géré.

Problème

Lorsque l'attribut de communauté étendue MAC du routeur est envoyé avec un préfixe AFI IPv4 d'un homologue BGP externe à un fabric ACI, une erreur de programmation FIB et HAL se produit sur tout leaf du fabric qui reçoit la route des leaf de périphérie via le processus MP-BGP interne. En effet, l'attribut RMAC extcommunity appartient à la famille d'adresses EVPN L2VPN BGP, et lorsqu'il est injecté dans la famille d'adresses IPv4 BGP, il est rejeté. Ceci est dû à une violation de la règle 5.2 (Uniform-Propagation-Mode), qui est décrite dans le document de l'IETF intitulé « EVPN Interworking with IPVPN ». À la page 15, point 4c, la question précise est énoncée :

 4.  As discussed, Communities, Extended Communities and Large
       Communities SHOULD be kept by the gateway PE from the originating
       SAFI route.  Exceptions of Extended Communities that SHOULD NOT
       be kept are:

       C.  All the extended communities of type EVPN.

       The gateway PE SHOULD NOT copy the above extended communities
       from the originating ISF route to the re-advertised ISF route.

Lien vers le document : Interaction EVPN avec IPVPN

Voici un exemple du problème avec iBGP, cependant, le problème est également vu avec eBGP.

Schéma de topologie :

Topology Diagram Diagramme topologique

Configurez la carte de route sur le périphérique homologue BGP externe (Routeur 1) et définissez l'attribut extcommunity EVPN RMAC :

Router-1# show run | sec route-map
route-map RMAC permit 10
  set extcommunity evpn rmac aaaa.bbbb.cccc

Dans la configuration de la famille d'adresses IPv4 du voisin BGP, configurez les communautés étendues BGP et configurez le mappage de route dans la direction sortante :

Router-1# show run bgp
<output omitted>
feature bgp

router bgp 65001
  vrf example
    router-id 192.168.20.20
    address-family ipv4 unicast
      network 192.168.20.0/24
    neighbor 192.168.30.30
      remote-as 65001
      update-source loopback1
      address-family ipv4 unicast
        send-community extended
        route-map RMAC out

Vérifiez l'état BGP sur BL 101 :

leaf-101# show ip bgp 192.168.20.0 vrf example:example
BGP routing table information for VRF example:example, address family IPv4 Unicast
BGP routing table entry for 192.168.20.0/24, version 40 dest ptr 0xa0fec840
Paths: (1 available, best #1)
Flags: (0x80c001a 00000000) on xmit-list, is in urib, is best urib route, is in HW, exported
  vpn: version 2725, (0x100002) on xmit-list
Multipath: eBGP iBGP

  Advertised path-id 1, VPN AF advertised path-id 1
  Path type (0xa96485b8): internal 0x18 0x0 ref 0 adv path ref 2, path is valid, is best path
  AS-Path: NONE, path sourced internal to AS
    192.168.20.20 (metric 5) from 192.168.20.20 (192.168.20.20)
      Origin IGP, MED not set, localpref 100, weight 0 tag 0, propagate 0
      Extcommunity:
          RT:65001:2162688
          COST:pre-bestpath:163:1879048192
          Router MAC:aaaa.bbbb.cccc
          ***Notice that the router mac is present here.***
          VNID:2162688

  VRF advertise information:
  Path-id 1 not advertised to any peer

  VPN AF advertise information:
  Path-id 1 advertised to peers:
    10.0.216.65        10.0.216.66

Vérifiez RIB sur CL 102 :

leaf-102# show ip route 192.168.20.0 vrf example:example
IP Route Table for VRF "example:example"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

192.168.20.0/24, ubest/mbest: 1/0
    *via 10.0.210.70%overlay-1, [200/0], 00:00:43, bgp-65001, internal, tag 65001, rwVnid: vxlan-2162688 
         recursive next hop: 10.0.210.70/32%overlay-1
    ***Notice that we have the route here and our next-hop address is correct (showing the TEP IP of BL 101). Also, notice that there is an rwVnid entry here.***

leaf-102# acidiag fnvread | grep 101
     101        1             leaf-101      <output omitted>     10.0.210.70/32    leaf         active   0

Vérifiez FIB sur CL 102 :

module-1(DBG-elam-insel6)# show forwarding route 192.168.20.0 vrf example:example
ERROR: no longest match in IPv4 table 0xf5df36b0
***No entry is present.***

Vérifiez la table HAL sur CL 102 :

module-1(DBG-elam-insel6)# show platform internal hal l3 routes | grep 192.168.20.0
***No entry is present.***

Envoyez des requêtes ping depuis EP (Hôte 1) vers l'hôte du réseau externe provenant de l'homologue BGP externe (192.168.20.20) :

Host-1# ping 192.168.20.20 vrf example
PING 192.168.20.20 (192.168.20.20): 56 data bytes
Request 0 timed out
Request 1 timed out
Request 2 timed out
Request 3 timed out
Request 4 timed out

--- 192.168.20.20 ping statistics ---
5 packets transmitted, 0 packets received, 100.00% packet loss
***No connectivity.***

Vérifiez ELAM sur CL 102 :

leaf-102# vsh_lc
module-1# debug platform internal roc elam asic 0
module-1(DBG-elam)# trigger reset
module-1(DBG-elam)# trigger init in-select 6 out-select 0
module-1(DBG-elam-insel6)# set outer ipv4 src_ip 192.168.10.10 dst_ip 192.168.20.20
module-1(DBG-elam-insel6)# start
module-1(DBG-elam-insel6)# stat
 ELAM STATUS
===========
Asic 0 Slice 0 Status Armed
Asic 0 Slice 1 Status Triggered

module-1(DBG-elam-insel6)# ereport
Python available. Continue ELAM decode with LC Pkg
 ELAM REPORT
<output omitted>
------------------------------------------------------------------------------------------------------------------------------------------------------
Lookup Drop
------------------------------------------------------------------------------------------------------------------------------------------------------
LU drop reason                          : UC_PC_CFG_TABLE_DROP
                                          ***Notice the drop vector here.***

Solution

La solution consiste à arrêter l'envoi de l'attribut de communauté étendue MAC de routeur avec un préfixe de famille d'adresses IPv4 d'un homologue BGP externe à un fabric ACI.

Supprimez le mappage de route précédemment configuré et arrêtez d'envoyer des communautés étendues à partir du périphérique homologue BGP externe (Routeur 1). La suppression de l'une de ces configurations, ou des deux, fonctionnera :

Router-1# show run bgp

feature bgp

router bgp 65001
  vrf example
    router-id 192.168.20.20
    address-family ipv4 unicast
      network 192.168.20.0/24
    neighbor 192.168.30.30
      remote-as 65001
      update-source loopback1
      address-family ipv4 unicast

Une autre solution (moins préférée) consiste simplement à filtrer toutes les communautés reçues du périphérique homologue BGP externe en créant une carte de route dans l'interface L3Out configurée dans l'ACI.

Accédez à votre Tenant > Policies > Protocol > Route Maps for Route Control > Create Route Maps for Route Control:

Select the option to Create Route Maps for Route Control

Sélectionnez l'option Create Route Maps for Route Control

Nommez votre carte de routage, activez l' Route-Map Continue , puis ajoutez un contexte. Sélectionnez le + dans le tableau Contextes :

Créer une carte de routage et créer un contexte

Nommez votre contexte et conservez l'action par défaut de Permit sélectionné, puis créez une règle de correspondance en sélectionnant le + dans la barre Associated Matched Rules , puis sélectionnez Create Match Rule for a Route Map:

Create Route Control Context and select option for Create Match Rule for a Route Map

Créer un contexte de contrôle de routage et sélectionner une option pour Créer une règle de correspondance pour une carte de routage

Nommez votre règle de correspondance, puis ajoutez un nouveau préfixe en sélectionnant l'icône + dans la Match Prefix tableau :

Create Match Rule and create Match Prefix

Créer une règle de correspondance et créer un préfixe de correspondance

Ajoutez le préfixe souhaité. Cet exemple montre comment ajouter un agrégat de tous les préfixes :

Créer une règle de destination de routage correspondante

Après avoir sélectionné OK dans le Create Match Route Destination Rule , vous voyez que votre préfixe a été ajouté à la Match Prefix dans le tableau Create Match Rule fenêtre :

Le préfixe de correspondance est maintenant ajouté à la règle de correspondance

Après avoir sélectionné Submit dans le Create Match Rule , sélectionnez Update dans le Associated Matched Rules dans le tableau Create Route Control Context fenêtre :

Add Associated Match Rule to Route Control Context

Ajouter la règle de correspondance associée au contexte de contrôle de route

Votre règle de correspondance associée est maintenant ajoutée à votre contexte :

Associated Match Rule is now added to Route Control Context

La règle de correspondance associée est maintenant ajoutée au contexte de contrôle de route

Sélectionnez ensuite le menu déroulant en regard de Set Rule et sélectionnez Create Set Rules for a Route Map:

Select option to Create Set Rules for a Route Map

Sélectionner une option pour créer des règles de définition pour une carte de routage

Nommez votre règle définie, puis sélectionnez la Set Community et conservez les critères par défaut de No community sélectionné :

Créer une règle de définition pour la carte de routage

Après avoir sélectionné Terminer dans la Create Set Rules for a Route Map , vous voyez votre règle définie sélectionnée dans la fenêtre Create Route Control Context fenêtre :

Set Rule is now added to Route Control Context

La règle Set est maintenant ajoutée au contexte de contrôle de route

Après avoir sélectionné OK dans le Create Route Control Context , vous voyez votre contexte ajouté à la fenêtre Contexts dans le tableau Create Route Maps for Route Control s'affiche. Enfin, sélectionnez Submit pour terminer la configuration :

Le contexte est maintenant ajouté à la carte de routage

Accédez au profil de connectivité homologue BGP dans L3Out et sélectionnez le + dans la barre Route Control Profile puis ajoutez votre feuille de route avec la direction par défaut de Route Import Policy sélectionné :

Ajouter un mappage de route au profil de connectivité homologue BGP

Une fois que vous avez sélectionné Update pour la carte de routage, vous voyez votre carte de routage ajoutée à la Route Control Profile tableau :

La carte de routage est maintenant ajoutée au profil de connectivité homologue BGP

*Pour plus d'informations sur les options de configuration de la carte de routage dans l'ACI, reportez-vous au livre blanc ACI Fabric L3Out

Après avoir implémenté l'une des solutions ci-dessus, vérifiez si le problème est résolu.

Vérifiez l'état BGP sur BL 101 :

leaf-101# show ip bgp 192.168.20.0 vrf example:example
BGP routing table information for VRF example:example, address family IPv4 Unicast
BGP routing table entry for 192.168.20.0/24, version 46 dest ptr 0xa0fec840
Paths: (1 available, best #1)
Flags: (0x80c001a 00000000) on xmit-list, is in urib, is best urib route, is in HW, exported
  vpn: version 2731, (0x100002) on xmit-list
Multipath: eBGP iBGP

  Advertised path-id 1, VPN AF advertised path-id 1
  Path type (0xa96485b8): internal 0x18 0x0 ref 0 adv path ref 2, path is valid, is best path
  AS-Path: NONE, path sourced internal to AS
    192.168.20.20 (metric 5) from 192.168.20.20 (192.168.20.20)
      Origin IGP, MED not set, localpref 100, weight 0 tag 0, propagate 0
      Extcommunity:
          RT:65001:2162688
          COST:pre-bestpath:163:1879048192
          ***Notice that no router mac is present here.***
          VNID:2162688

  VRF advertise information:
  Path-id 1 not advertised to any peer

  VPN AF advertise information:
  Path-id 1 advertised to peers:
    10.0.216.65        10.0.216.66

Vérifiez RIB sur CL 102 :

leaf-102# show ip route 192.168.20.0 vrf example:example
IP Route Table for VRF "example:example"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

192.168.20.0/24, ubest/mbest: 1/0
    *via 10.0.210.70%overlay-1, [200/0], 00:00:06, bgp-65001, internal, tag 65001
         recursive next hop: 10.0.210.70/32%overlay-1
    ***Notice that no rwVnid entry is present here.***

Remarque : l'absence ou la présence de l'entrée rwVnid seule ne détermine pas si le problème se produit ou non. Dans de nombreux cas, l'entrée rwVnid est supprimée de la route en question une fois le problème résolu. Mais ce n'est pas toujours le cas. Vérifiez toujours les tables FIB et HAL afin de vérifier si le problème est résolu ou non.

Vérifiez FIB sur CL 102 :

module-1(DBG-elam-insel6)# show forwarding route 192.168.20.0 vrf example:example

IPv4 routes for table example:example/base

------------------+------------------+----------------------+------------------------

Prefix            | Next-hop         | Interface/VRF        | Additional Info

------------------+------------------+----------------------+------------------------
*192.168.20.0/24      10.0.210.70        overlay-1 
***Notice that we have the route here and our next-hop address is correct (showing the TEP IP of BL 101).***
Route Class-id:0x0
Policy Prefix 0.0.0.0/0

leaf-102# acidiag fnvread | grep 101
     101        1             leaf-101           10.0.210.70/32    leaf         active   0

Table HAL sur CL 102 :

module-1(DBG-elam-insel6)# show platform internal hal l3 routes | grep 192.168.20.0
| 4662| 192.168.20.0/ 24| UC|  686|     20601| TRIE|   a5| 5/  0| 60a5|A|     8443|    86b6|  ef5| 1/  2|       a5|  0|      0|   f|  3|   0| 0| 1| sc,spi,dpi
***Notice that we have an entry here and it's in the correct VRF.***

module-1(DBG-elam-insel6)# hex 4662
0x1236

module-1(DBG-elam-insel6)# show platform internal hal l3 vrf pi
============================================================================================================
                                      | -- TOR --  | - Spine -  |                ACL                  |     |
      Vrf           Hw    I I Vrf     | SB    NB   | Proxy ACI  |      Ing               Egr          | vpn |
VrfId Name          VrfId I S Vnid    | BDId  BDId | Ou Bd Enc  | Lbl      Msk      Lbl      Msk      | lbl |
============================================================================================================
26    example:example         1236  0 0 210000    0     0      0     1      0        0        0        0        0

Envoyez des requêtes ping depuis EP (Hôte 1) vers l'hôte du réseau externe provenant de l'homologue BGP externe (192.168.20.20) :

Host-1# ping 192.168.20.20 vrf example
PING 192.168.20.20 (192.168.20.20): 56 data bytes
64 bytes from 192.168.20.20: icmp_seq=0 ttl=252 time=1.043 ms
64 bytes from 192.168.20.20: icmp_seq=1 ttl=252 time=1.292 ms
64 bytes from 192.168.20.20: icmp_seq=2 ttl=252 time=1.004 ms
64 bytes from 192.168.20.20: icmp_seq=3 ttl=252 time=0.769 ms
64 bytes from 192.168.20.20: icmp_seq=4 ttl=252 time=1.265 ms

--- 192.168.20.20 ping statistics ---
5 packets transmitted, 5 packets received, 0.00% packet loss
round-trip min/avg/max = 0.769/1.074/1.292 ms
***Connectivity is there.***

ELAM sur CL 102 :

leaf-102# vsh_lc
module-1# debug platform internal roc elam asic 0
module-1(DBG-elam)# trigger reset
module-1(DBG-elam)# trigger init in-select 6 out-select 0
module-1(DBG-elam-insel6)# set outer ipv4 src_ip 192.168.10.10 dst_ip 192.168.20.20
module-1(DBG-elam-insel6)# start
module-1(DBG-elam-insel6)# stat
 ELAM STATUS
===========
Asic 0 Slice 0 Status Armed
Asic 0 Slice 1 Status Triggered

module-1(DBG-elam-insel6)# ereport
Python available. Continue ELAM decode with LC Pkg
 ELAM REPORT
<output omitted>
------------------------------------------------------------------------------------------------------------------------------------------------------
Lookup Drop
------------------------------------------------------------------------------------------------------------------------------------------------------
LU drop reason                          : no drop
                                          ***Traffic forwards correctly.***

Informations connexes

Ce comportement est également documenté dans ce défaut : ID de bogue Cisco CSCvx28929
Assistance et documentation techniques - Cisco Systems

Historique de révision

Révision	Date de publication	Commentaires
1.0	12-Jun-2023	Première publication

Contribution d’experts de Cisco

Matthew Rich
Ingénieur TAC Cisco

Résolution des problèmes de transmission EVPN RMAC ExtCommunity vers le fabric ACI

Options de téléchargement

Langage exempt de préjugés

À propos de cette traduction

Table des matières

Introduction

Informations générales

Problème

Solution

Informations connexes

Historique de révision

Contribution d’experts de Cisco

Ce document vous est-il utile?

Contacter Cisco

Ce document s’applique à ces produits