In dem Dokumentationssatz für dieses Produkt wird die Verwendung inklusiver Sprache angestrebt. Für die Zwecke dieses Dokumentationssatzes wird Sprache als „inklusiv“ verstanden, wenn sie keine Diskriminierung aufgrund von Alter, körperlicher und/oder geistiger Behinderung, Geschlechtszugehörigkeit und -identität, ethnischer Identität, sexueller Orientierung, sozioökonomischem Status und Intersektionalität impliziert. Dennoch können in der Dokumentation stilistische Abweichungen von diesem Bemühen auftreten, wenn Text verwendet wird, der in Benutzeroberflächen der Produktsoftware fest codiert ist, auf RFP-Dokumentation basiert oder von einem genannten Drittanbieterprodukt verwendet wird. Hier erfahren Sie mehr darüber, wie Cisco inklusive Sprache verwendet.
Cisco hat dieses Dokument maschinell übersetzen und von einem menschlichen Übersetzer editieren und korrigieren lassen, um unseren Benutzern auf der ganzen Welt Support-Inhalte in ihrer eigenen Sprache zu bieten. Bitte beachten Sie, dass selbst die beste maschinelle Übersetzung nicht so genau ist wie eine von einem professionellen Übersetzer angefertigte. Cisco Systems, Inc. übernimmt keine Haftung für die Richtigkeit dieser Übersetzungen und empfiehlt, immer das englische Originaldokument (siehe bereitgestellter Link) heranzuziehen.
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.
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.
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 spezifische 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:
Konfigurieren Sie die Routenübersicht 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.***
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
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
:
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:
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
:
Benennen Sie Ihre Übereinstimmungsregel, und fügen Sie dann ein neues Präfix hinzu, indem Sie im Match Prefix
Tabelle:
Fügen Sie das gewünschte Präfix hinzu. In diesem Beispiel wird gezeigt, wie eine Aggregation aller Präfixe hinzugefügt wird:
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:
Nach der Auswahl Submit
im Create Match Rule
Fenster, auswählen Update
im Associated Matched Rules
Tabelle im Create Route Control Context
Fenster:
Ihre zugeordnete Abgleichregel wurde Ihrem Kontext hinzugefügt:
Wählen Sie anschließend das Dropdown-Menü neben Set Rule
und wählen Create Set Rules for a Route Map
:
Benennen Sie die festgelegte Regel, und wählen Sie dann Set Community
und belassen Sie die Standardkriterien von No community
ausgewählt:
Nachdem Sie im Create Set Rules for a Route Map
wird die eingestellte Regel im Fenster Create Route Control Context
Fenster:
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:
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:
Nachdem Sie für die Routenübersicht die Option Aktualisieren ausgewählt haben, wird die Routenübersicht der Route Control Profile
Tabelle:
* 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.***
Überarbeitung | Veröffentlichungsdatum | Kommentare |
---|---|---|
1.0 |
12-Jun-2023 |
Erstveröffentlichung |