Inhalt

Einleitung

Hintergrundinformationen

Problem

Einleitung

Dieses Dokument beschreibt die Auswirkungen falsch konfigurierter MAC-erweiterter Router-Community-Attribute auf eine ACI-Fabric, wenn diese von einem externen Border Gateway Protocol (BGP)-Peer empfangen werden.

Hintergrundinformationen

Beim BGP gibt es eine Option zum Senden von Community- und erweiterten Community-Attributen mit den Präfixen, die BGP-Peers angekündigt werden. Mithilfe dieser Community-Attribute können wir Routing-Richtlinien ändern und die Art und Weise, wie gerouteter Datenverkehr behandelt wird, dynamisch ändern.

Problem

Wenn das erweiterte MAC-Communityattribut des Routers mit einem IPv4-AFI-Präfix von einem externen BGP-Peer an eine ACI-Fabric gesendet wird, kommt es zu FIB- und HAL-Fehlprogrammierung auf jedem Leaf in der Fabric, der die Route vom/den Grenzleaf/n über den internen MP-BGP-Prozess empfängt. Der Grund hierfür ist, dass das RMAC extcommunity-Attribut zur BGP L2VPN EVPN-Adressfamilie gehört. Wird es in die BGP IPv4-Adressfamilie eingefügt, wird es abgelehnt. Dies liegt an einem Verstoß gegen Regel 5.2 (Uniform-Propagation-Mode), die im IETF-Dokument "EVPN Interworking with IPVPN" beschrieben wird. Auf Seite 15, Punkt 4c, wird der konkrete Punkt genannt:

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 zum Dokument: EVPN-Kompatibilität mit IPVPN

Hier sehen Sie ein Beispiel für das Problem mit iBGP, das Problem zeigt sich jedoch auch bei eBGP.

Topologiediagramm:

Topologiediagramm

Konfigurieren Sie die Routenzuordnung auf dem externen BGP-Peer-Gerät (Router 1), und legen Sie das Attribut "EVPN RMAC extcommunity" fest:

Router-1# show run | sec route-map

route-map RMAC permit 10

set extcommunity evpn rmac aaaa.bbbb.cccc

Konfigurieren Sie unter der Konfiguration der IPv4-Adressfamilie des BGP-Nachbarn die erweiterten BGP-Communities und die Routenübersicht in ausgehender Richtung:

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

Überprüfen Sie den BGP-Status auf 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

RIB auf CL 102 prüfen:

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

Prüfen Sie die FIB auf 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.***

Prüfen Sie die HAL-Tabelle für CL 102:

module-1(DBG-elam-insel6)# show platform internal hal l3 routes | grep 192.168.20.0

***No entry is present.***

Ping von EP (Host 1) an Host in externem Netzwerk vom externen 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.***

ELAM auf CL 102 überprüfen:

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.***

Lösung

Die Lösung besteht darin, das Senden des erweiterten MAC-Community-Attributs des Routers mit einem Präfix für die IPv4-Adressfamilie von einem externen BGP-Peer an eine ACI-Fabric zu beenden.

Entfernen Sie die zuvor konfigurierte Routenübersicht, und beenden Sie das Senden erweiterter Communitys vom externen BGP-Peer-Gerät (Router 1). Das Entfernen einer oder beider Konfigurationen funktioniert wie folgt:

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

Eine weitere (weniger bevorzugte) Lösung besteht darin, alle vom externen BGP-Peer-Gerät empfangenen Communities herauszufiltern, indem im konfigurierten L3Out in der ACI eine Routing-Map erstellt wird.

Navigieren Sie zu Ihrem  Tenant > Policies > Protocol > Route Maps for Route Control > Create Route Maps for Route Control:

Wählen Sie die Option Create Route Maps for Route Control (Routenzuordnungen für die Routensteuerung erstellen).

Benennen Sie Ihre Routenübersicht, aktivieren Sie die  Route-Map Continue  und fügen Sie dann einen Kontext hinzu. Wählen Sie  +  -Symbol in der Contexts-Tabelle:

Routenübersicht erstellen und Kontext erstellen

Benennen Sie den Kontext, und belassen Sie die Standardaktion von  Permit  ausgewählt wurde, erstellen Sie eine Übereinstimmungsregel, indem Sie den  +  Symbol in der  Associated Matched Rules  -Tabelle ein, und wählen  Create Match Rule for a Route Map:

Erstellen von Routensteuerungskontext und Auswählen der Option zum Erstellen einer Übereinstimmungsregel für eine Routenzuordnung

Benennen Sie Ihre Übereinstimmungsregel, und fügen Sie dann ein neues Präfix hinzu, indem Sie im  Match Prefix  Tabelle:

Zuordnungsregel erstellen und Zuordnungspräfix erstellen

Fügen Sie das gewünschte Präfix hinzu. In diesem Beispiel wird gezeigt, wie eine Aggregation aller Präfixe hinzugefügt wird:

Regel für passendes Routenziel erstellen

Nach der Auswahl  OK im  Create Match Route Destination Rule  wird angezeigt, dass Ihr Präfix zur  Match Prefix  Tabelle im  Create Match Rule  Fenster:

'Präfix zuordnen' wird jetzt der Zuordnungsregel hinzugefügt

Nach der Auswahl  Submit  im  Create Match Rule  Fenster, auswählen  Update  im  Associated Matched Rules  Tabelle im  Create Route Control Context  Fenster:

Zugeordnete Zuordnungsregel zum Routensteuerungskontext hinzufügen

Ihre zugeordnete Abgleichregel wurde Ihrem Kontext hinzugefügt:

Die zugeordnete Zuordnungsregel wurde jetzt dem Routensteuerungskontext hinzugefügt.

Wählen Sie anschließend das Dropdown-Menü neben  Set Rule  und wählen  Create Set Rules for a Route Map:

Wählen Sie die Option Set Rules für eine Routenzuordnung erstellen aus.

Benennen Sie die festgelegte Regel, und wählen Sie dann  Set Community  und belassen Sie die Standardkriterien von  No community  ausgewählt:

Festlegen einer Regel für die Routenzuordnung erstellen

Nachdem Sie im  Create Set Rules for a Route Map  wird die eingestellte Regel im Fenster  Create Route Control Context  Fenster:

Regel festlegen wird jetzt zum Kontext der Routensteuerung hinzugefügt

Nach der Auswahl  OK  im  Create Route Control Context  wird der Kontext zum Fenster  Contexts  Tabelle im  Create Route Maps for Route Control  angezeigt. Wählen Sie anschließend  Submit  um die Konfiguration abzuschließen:

Kontext wird jetzt zur Routenzuordnung hinzugefügt

Navigieren Sie zum BGP-Peer-Konnektivitätsprofil im L3Out, und wählen Sie  +  Symbol in der  Route Control Profile  -Tabelle an, und fügen Sie dann Ihre Routenübersicht mit der Standardrichtung von  Route Import Policy  ausgewählt:

Hinzufügen der Routenzuordnung zum BGP-Peer-Verbindungsprofil

Nachdem Sie für die Routenübersicht die Option Aktualisieren ausgewählt haben, wird die Routenübersicht der  Route Control Profile  Tabelle:

Die Routenzuordnung wird jetzt dem BGP-Peer-Verbindungsprofil hinzugefügt.

* Weitere Informationen zu den Konfigurationsoptionen der Routing-Map in der ACI finden Sie im Whitepaper ACI Fabric L3Out.

Überprüfen Sie nach der Implementierung einer der oben genannten Lösungen, ob das Problem behoben ist.

Überprüfen Sie den BGP-Status auf 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

RIB auf CL 102 prüfen:

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.***

Hinweis: Das Fehlen oder Vorhandensein des rwVnid-Eintrags allein bestimmt nicht, ob das Problem auftritt oder nicht. In vielen Fällen wird der rwVnid-Eintrag aus der betreffenden Route entfernt, sobald das Problem behoben ist. Dies ist jedoch nicht immer der Fall. Überprüfen Sie stets die FIB- und HAL-Tabellen, um sicherzustellen, dass das Problem behoben wurde.

Prüfen Sie die FIB auf 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-Tabelle für 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

Ping von EP (Host 1) an Host in externem Netzwerk vom externen 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 auf 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.***

Zugehörige Informationen

- Dieses Verhalten ist auch in diesem Defekt dokumentiert: Cisco Bug-ID CSCvx28929

- Technischer Support und Dokumentation für Cisco Systeme