Problemen met EVPN RMAC ExtCommunity-overdracht naar ACI Fabric oplossen

Downloadopties

PDF (914.8 KB)
Met Adobe Reader op diverse apparaten bekijken

Bijgewerkt:13 juni 2023

Document-id:220473

Inclusief taalgebruik

De documentatie van dit product is waar mogelijk geschreven met inclusief taalgebruik. Inclusief taalgebruik wordt in deze documentatie gedefinieerd als taal die geen discriminatie op basis van leeftijd, handicap, gender, etniciteit, seksuele oriëntatie, sociaaleconomische status of combinaties hiervan weerspiegelt. In deze documentatie kunnen uitzonderingen voorkomen vanwege bewoordingen die in de gebruikersinterfaces van de productsoftware zijn gecodeerd, die op het taalgebruik in de RFP-documentatie zijn gebaseerd of die worden gebruikt in een product van een externe partij waarnaar wordt verwezen. Lees meer over hoe Cisco gebruikmaakt van inclusief taalgebruik.

Over deze vertaling

Cisco heeft dit document vertaald via een combinatie van machine- en menselijke technologie om onze gebruikers wereldwijd ondersteuningscontent te bieden in hun eigen taal. Houd er rekening mee dat zelfs de beste machinevertaling niet net zo nauwkeurig is als die van een professionele vertaler. Cisco Systems, Inc. is niet aansprakelijk voor de nauwkeurigheid van deze vertalingen en raadt aan altijd het oorspronkelijke Engelstalige document (link) te raadplegen.

Inhoud

Inleiding

Achtergrondinformatie

Probleem

Oplossing

Gerelateerde informatie

Inleiding

Dit document beschrijft de impact van verkeerd geconfigureerde Router MAC extended community attribuut op een ACI-fabric wanneer ontvangen van een externe BGP peer.

Achtergrondinformatie

Met Border Gateway Protocol is er een optie om community- en extended community-attributen te verzenden met de voorvoegsels die worden geadverteerd aan BGP-peers. Deze community-attributen stellen ons in staat om het routeringsbeleid aan te passen en de manier waarop gerouteerd verkeer wordt afgehandeld dynamisch te wijzigen.

Probleem

Wanneer het Router MAC extended community attribuut wordt verzonden met een IPv4 AFI prefix van een externe BGP peer naar een ACI fabric, treedt FIB en HAL misprogrammering op op elk blad in de fabric dat de route van de border leaf(s) ontvangt via het interne MP-BGP proces. Dit komt omdat het attribuut RMAC extcommunity behoort tot de BGP L2VPN EVPN-adresfamilie en wanneer het wordt geïnjecteerd in de BGP IPv4-adresfamilie, wordt het afgewezen. Dit is te wijten aan een overtreding van regel 5.2 (Uniform-Propagation-Mode), die wordt beschreven in het IETF-document met de titel "EVPN Interworking with IPVPN". Op bladzijde 15, punt 4c, wordt het specifieke probleem genoemd:

 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.

Link naar document: EVPN Interworking with IPVPN

Hier is een voorbeeld van het probleem met iBGP, maar het probleem wordt ook gezien met eBGP.

Topologiediagram:

Topology Diagram topologiediagram

Configureer routekaart op een extern BGP-peer-apparaat (Router 1) en stel het attribuut EVPN RMAC extcommunity in:

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

Configureer onder de configuratie van de IPv4-adresfamilie van de BGP-buur BGP Extended Communities en configureer de routekaart in de uitgaande richting:

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

Controleer de BGP-status op 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

Controleer RIB op 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

Controleer FIB op 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.***

Controleer de HAL-tabel op CL 102:

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

Pings van EP (host 1) naar host in extern netwerk dat afkomstig is van externe BGP-peer (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.***

Controleer ELAM op 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.***

Oplossing

De oplossing is om te stoppen met het verzenden van het Router MAC extended community attribuut met een IPv4 adres familie prefix van een externe BGP peer naar een ACI-fabric.

Verwijder de eerder geconfigureerde routekaart en stop met het verzenden van uitgebreide communities vanaf het externe BGP-peer-apparaat (Router 1). Het verwijderen van een van deze configuraties, of beide, werkt:

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

Een andere (minder gewenste) oplossing is om eenvoudig alle gemeenschappen die van het externe BGP-peer-apparaat zijn ontvangen, uit te filteren door een routekaart te maken in de geconfigureerde L3Out in ACI.

Navigeer naar je Tenant > Policies > Protocol > Route Maps for Route Control > Create Route Maps for Route Controlwebsite:

Select the option to Create Route Maps for Route Control

Selecteer de optie om routekaarten te maken voor routebesturing

Noem uw routekaart, schakel de optie Route-Map Continue in en voeg vervolgens een context toe. Selecteer het + pictogram in de tabel Contexten:

Routekaart maken en context creëren

Geef uw context een naam en laat de standaardactie van Permit geselecteerd staan. Maak vervolgens een overeenkomende regel door het+pictogram in de tabel te selecteren Associated Matched Rules en selecteer Create Match Rule for a Route Mapvervolgens:

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

Route Control Context maken en optie selecteren voor Match Rule maken voor een routekaart

Noem uw overeenkomende regel en voeg een nieuw voorvoegsel toe door het + pictogram in de tabel te selecteren Match Prefix:

Create Match Rule and create Match Prefix

Overeenstemmingsregel maken en Voorvoegsel voor overeenkomst maken

Voeg het gewenste prefix toe. Dit voorbeeld laat zien hoe je een aggregaat van alle voorvoegsels toevoegt:

Bestemmingsregel voor overeenkomende route maken

Nadat u OK in het Create Match Route Destination Rulevenster hebt geselecteerd, ziet u dat uw prefix is toegevoegd aan de Match Prefix tabel in het Create Match Rule venster:

Match Prefix wordt nu toegevoegd aan Match Rule

Nadat u Submit in het venster de optie Create Match Rule hebt geselecteerd, selecteert u Update in de tabel Associated Matched Rules in het venster Create Route Control Context:

Add Associated Match Rule to Route Control Context

Gekoppelde overeenkomende regel toevoegen aan de context van de routebesturing

De bijbehorende wedstrijdregel wordt nu aan de context toegevoegd:

Associated Match Rule is now added to Route Control Context

Associated Match Rule wordt nu toegevoegd aan de context van de routebesturing

Selecteer vervolgens het vervolgkeuzemenu naast Set Rule en selecteer Create Set Rules for a Route Map:

Select option to Create Set Rules for a Route Map

Selecteer de optie om regels voor een routekaart te maken

Geef de ingestelde regel een naam, selecteer vervolgens de optie Set Community en laat de standaardcriteria van No community geselecteerd:

Regel instellen voor routekaart maken

Nadat u Voltooien in het venster hebt geselecteerd Create Set Rules for a Route Map, wordt de ingestelde regel in het venster geselecteerd Create Route Control Context:

Set Rule is now added to Route Control Context

Regel instellen is nu toegevoegd aan de context van routebesturing

Nadat uOKin het Create Route Control Context venster hebt geselecteerd, wordt uw context toegevoegd aan de Contexts tabel in het Create Route Maps for Route Control venster. Selecteer ten slotteSubmitom de configuratie te voltooien:

Context wordt nu toegevoegd aan routekaart

Navigeer naar het BGP Peer Connectivity Profile in de L3Out en selecteer het+pictogram in de Route Control Profile tabel en voeg vervolgens uw routekaart toe met de standaardrichting van Route Import Policy geselecteerd:

Routekaart toevoegen aan BGP Peer Connectivity Profile

Nadat u Bijwerken voor de routekaart hebt geselecteerd, ziet u uw routekaart toegevoegd aan de Route Control Profile tabel:

Routekaart is nu toegevoegd aan BGP Peer Connectivity Profile

*Voor meer informatie over routekaartconfiguratieopties in ACI, raadpleegt u het ACI Fabric L3Out-witboek

Controleer na het implementeren van een van de bovenstaande oplossingen of het probleem is opgelost.

Controleer de BGP-status op 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

Controleer RIB op 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.***

Opmerking: alleen het ontbreken of de aanwezigheid van de rwVnid-vermelding bepaalt niet of het probleem zich voordoet of niet. In veel gevallen wordt de rwVnid-vermelding van de route in kwestie verwijderd zodra het probleem is opgelost. Dit is echter niet altijd het geval. Controleer altijd FIB- en HAL-tabellen om te controleren of het probleem is opgelost of niet.

Controleer FIB op 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

HAL-tabel op 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

Pings van EP (host 1) naar host in extern netwerk dat afkomstig is van externe BGP-peer (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 op 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.***