Implementierung einer BGP-EVPN-Routing-Richtlinie auf Catalyst Switches der Serie 9000

Einleitung

In diesem Dokument wird die Implementierung einer Routing-Richtlinie in BGP EVPN VXLAN auf Catalyst Switches der Serie 9000 beschrieben.

Voraussetzungen

Anforderungen

Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:

• BGP-Konfiguration und -Validierung 
• Routenzuordnungen und grundlegende BGP-Routing-Richtlinien
• EVPN-VxLAN

Verwendete Komponenten

Die Informationen in diesem Dokument basierend auf folgenden Software- und Hardware-Versionen:

• Catalyst 9300
• Catalyst 9400
• Catalyst 9500
• Catalyst 9600
• Cisco IOS® XE 17.11.1 und neuere Versionen 

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.

Hintergrundinformationen

Die EVPN VxLAN-Routing-Richtlinie verwendet Route Maps, um den Datenverkehrsfluss von Hosts zu steuern und die Routen zu ermitteln, die VTEPs empfangen und verarbeiten:

• Dies ist ein Schlüsselaspekt des EVPN-geschützten Segmenttypdesigns (das nicht in diesem Dokument behandelt wird), bei dem ARP-Datenverkehr nur an das zentrale Gateway (CGW) gesendet wird, sodass der CGW eine Proxyantwort mit einer eigenen MAC-Adresse auch für lokalen Segment-Datenverkehr ausführen kann. 
• Geschütztes Segment ermöglicht die Steuerung des Datenverkehrsflusses auf eine Weise, dass der gesamte Datenverkehr über die Datenverkehrsanalyse und die Datenverkehrsrichtlinien einer Firewall geleitet werden kann. 

Cisco implementierte auch das erweiterte Communityattribut DEF GW (Default Gateway), um anzugeben, welches MAC/IP-Präfix dem CGW gehört.

Dokumentdetails

Wichtige Informationen zu diesem Dokument:

• Der Replikationsmodus für BUM-Datenverkehr ist eingehend (Unicast-BUM-Tunnel).
• Verwendete VLANs: 201 und 202
• Verwendete VNIs sind 20101 und 20201
• Der gesamte geroutete Datenverkehr wird an den CGW gesendet (VTEPs haben keine eigene SVI).
• IMET-Routing-Typ-3-BGP-Präfixe sind Hub-and-Spoke (Leafs akzeptieren nur IMET-Routen vom CGW, nicht voneinander)
• Routentyp 2 und 5 sind vollständig vernetzt 

Unterstützte Routen

• Routentyp 3 (einschl. Multicast Ethernet Tag-Route)
• Routentyp 7 (IGMP Join Synch-Routen)
• Routentyp 8 (IGMP verlässt Synch-Routen)

Terminologie

VRF	Virtual Routing-Weiterleitung	Definiert eine Layer-3-Routing-Domäne, die von anderen VRFs und der globalen IPv4/IPv6-Routing-Domäne getrennt wird.
AF	Adressfamilie	Legt fest, welche Typpräfixe und Routing-Informationen vom BGP verarbeitet werden.
ALS	Autonomes System	Ein Satz von über das Internet routbaren IP-Präfixen, die zu einem Netzwerk gehören, oder eine Sammlung von Netzwerken, die alle von einer einzigen Einheit oder Organisation verwaltet, gesteuert und überwacht werden.
EVPN	Ethernet Virtual Private Network	Eine Erweiterung, die es dem BGP ermöglicht, Layer-2-MAC- und Layer-3-IP-Informationen zu übertragen, ist EVPN und verwendet das Multi-Protocol Border Gateway Protocol (MP-BGP) als Protokoll zur Verteilung von Erreichbarkeitsinformationen für das VXLAN-Overlay-Netzwerk.
VXLAN	Virtuelles erweiterbares LAN (Local Area Network)	VXLAN wurde entwickelt, um die Einschränkungen von VLANs und STP zu überwinden. Es handelt sich um einen vorgeschlagenen IETF-Standard [RFC 7348], der dieselben Ethernet-Layer-2-Netzwerkdienste wie VLANs bereitstellt, jedoch mit größerer Flexibilität. Funktionell handelt es sich um ein MAC-in-UDP-Kapselungsprotokoll, das als virtuelles Overlay auf einem Layer-3-Underlay-Netzwerk ausgeführt wird.
CGW	Zentrales Gateway	Implementierung von EVPN, wobei sich die Gateway-SVI nicht auf jedem Leaf befindet Stattdessen erfolgt das gesamte Routing über ein spezielles Leaf mit asymmetrischem IRB (Integrated Routing and Bridging).
DEF GW	Standardgateway	Ein erweitertes BGP-Community-Attribut, das dem MAC/IP-Präfix über den Befehl "default-gateway advertise enable" im Konfigurationsabschnitt "l2vpn evpn" hinzugefügt wird.
IMET	Inklusives Multicast Ethernet-Tag (Route)	Wird auch als BGP-Typ-3-Route bezeichnet. Dieser Routing-Typ wird im EVPN verwendet, um BUM-Datenverkehr (Broadcast/unbekanntes Unicast/Multicast) zwischen VTEPs zu übertragen.

Konfigurieren

Netzwerkdiagramm

Konfigurationen

Dieser Abschnitt zeigt Konfigurationsbeispiele für Leaf-01- und CGW-Switches (Border Leaf). Andere Leaf-Konfigurationen sind identisch und werden daher hier nicht wiederholt.

• Die Beispiele in diesem Dokument basieren auf der Eingangsreplikation und veranschaulichen, wie Richtlinien angewendet werden, um zu kontrollieren, welche VTEPs Broadcast- und anderen gefluteten Datenverkehr kommunizieren können 

Leaf-01 (Basis-EVPN-Konfiguration)

Leaf-01#show run | sec l2vpn
l2vpn evpn
 replication-type static
 flooding-suppression address-resolution disable  <-- Disables ARP caching so ARP is always sent up to the CGW 
 router-id Loopback1
l2vpn evpn instance 201 vlan-based
 encapsulation vxlan
 replication-type ingress
 multicast advertise enable
l2vpn evpn instance 202 vlan-based
 encapsulation vxlan
 replication-type ingress
 multicast advertise enable

Leaf-01#show run | sec vlan config
vlan configuration 201
 member evpn-instance 201 vni 20101
vlan configuration 202
 member evpn-instance 202 vni 20201

Leaf-01#show run int nve 1
Building configuration...

Current configuration : 327 bytes
!
interface nve1
 no ip address
 source-interface Loopback1
 host-reachability protocol bgp
 member vni 20201 ingress-replication
 member vni 20101 ingress-replication
end

ip bgp-community new-format     <-- Required to see community in aa:nn format

Leaf-01 (Routenfilterung)

Bestimmen Sie das passende Routenziel.

• Der Einfachheit halber werden im Beispiel in diesem Dokument automatische Route-Target-Funktionen verwendet.
• Da dies automatisch erfolgt, führen Sie diesen Befehl aus, um zu erfahren, wie Sie die Community-Liste konfigurieren.

Leaf-01#show l2vpn evpn route-target
Route Target           EVPN Instances
65001:201              201            <-- Route-targets for the Vlan/VNI of interest
65001:202              202    

ip extcommunity-list expanded ALLOW-RT2 permit 65001:20[0-9] <-- match Route-targets 65001:200 - 65001:209
!
ip community-list standard BLOCK-RT3 permit 999:999          <-- Arbitrary RT used to mark IMET prefixes as they are advertised

route-map POLICY-IN deny 5
 match community BLOCK-RT3 exact-match  <-- Deny prefixes that match RT 999:999 in standard community list
!
route-map POLICY-IN permit 10           <-- Permit any other prefixes that do not contain 999:999
!
route-map POLICY-OUT permit 5
 match extcommunity ALLOW-RT2           <-- Match the auto-RT in the extended community list
 match evpn route-type 3                <-- AND match route-type 3 prefixes
 set community 999:999                  <-- Set additional standard community to advertised prefixes  
!
route-map POLICY-OUT permit 10          <-- Permit prefixes that are not RT3 to be sent out without additional attributes added 

router bgp 65001
 bgp router-id 172.16.255.3
 bgp log-neighbor-changes
 no bgp default ipv4-unicast
 neighbor 172.16.255.1 remote-as 65001
 neighbor 172.16.255.1 update-source Loopback0
 neighbor 172.16.255.2 remote-as 65001
 neighbor 172.16.255.2 update-source Loopback0
 !
 address-family ipv4
 exit-address-family
 !
 address-family ipv4 mvpn
  neighbor 172.16.255.1 activate
  neighbor 172.16.255.1 send-community both
  neighbor 172.16.255.2 activate
  neighbor 172.16.255.2 send-community both
 exit-address-family
 !
 address-family l2vpn evpn
  neighbor 172.16.255.1 activate
  neighbor 172.16.255.1 send-community both       <-- Send both standard and extended community attributes 
  neighbor 172.16.255.1 route-map POLICY-IN in    <-- Apply inbound policy to deny prefixes with 999:999 community string
  neighbor 172.16.255.1 route-map POLICY-OUT out  <-- Apply outbound policy to match RT3 / apply standard community & permit other RT2 prefixes as normal 
  neighbor 172.16.255.2 activate
  neighbor 172.16.255.2 send-community both
  neighbor 172.16.255.2 route-map POLICY-IN in
  neighbor 172.16.255.2 route-map POLICY-OUT out
 exit-address-family

CGW (Basiskonfiguration)

CGW#show running-config | beg l2vpn evpn instance 201
l2vpn evpn instance 201 vlan-based
 encapsulation vxlan
 replication-type ingress
 default-gateway advertise enable    <-- adds the BGP attribute EVPN DEF GW:0:0 to the MAC/IP prefix
 multicast advertise enable
!
l2vpn evpn instance 202 vlan-based
 encapsulation vxlan
 replication-type ingress
 default-gateway advertise enable   <-- adds the BGP attribute EVPN DEF GW:0:0 to the MAC/IP prefix
 multicast advertise enable

CGW#show running-config | sec vlan config
vlan configuration 201
 member evpn-instance 201 vni 20101
vlan configuration 202
 member evpn-instance 202 vni 20201

CGW#show run int nve 1
Building configuration...

Current configuration : 313 bytes
!
interface nve1
 no ip address
 source-interface Loopback1
 host-reachability protocol bgp
 member vni 10101 mcast-group 225.0.0.101
 member vni 10102 mcast-group 225.0.0.102
 member vni 20101 ingress-replication local-routing  <-- 'ingress-replication' (Unicast all BUM traffic) / 'local-routing' (Enables vxlan centralized gateway forwarding)
 member vni 20201 ingress-replication local-routing
 member vni 50901 vrf green
end

CGW#show run interface vlan 201
Building configuration...

Current configuration : 231 bytes
!
interface Vlan201
 mac-address 0000.beef.cafe          <-- MAC is static in this example for viewing simplicity. This is not required 
 vrf forwarding red                  <-- SVI is in VRF red
 ip address 10.1.201.1 255.255.255.0
 no ip redirects
 ip local-proxy-arp                 <-- Sets CGW to Proxy reply even for local subnet ARP requests 
 ip pim sparse-mode
 ip route-cache same-interface      <-- This is auto added when local-proxy-arp is configured. However, this is a legacy 'fast switching' command that is not used by CEF & is not required for forwarding 
 ip igmp version 3
 no autostate
end

CGW#show run interface vlan 202
Building configuration...

Current configuration : 163 bytes
!
interface Vlan202
 mac-address 0000.beef.cafe
 vrf forwarding red
 ip address 10.1.202.1 255.255.255.0
 no ip redirects 
 ip local-proxy-arp 
 ip pim sparse-mode
 ip route-cache same-interface
 ip igmp version 3
 no autostate
end

CGW#sh run vrf red
Building configuration...

Current configuration : 873 bytes 
vrf definition red
 rd 2:2
 !
 address-family ipv4
  route-target export 2:2
  route-target import 2:2
  route-target export 2:2 stitching
  route-target import 2:2 stitching
 exit-address-family

Überprüfung

Netzwerkdiagramm

 

Dieses Diagramm soll Ihnen helfen, den in diesem Abschnitt beschriebenen Ablauf der ARP-Auflösung zu veranschaulichen. 

• Die ARP-Anforderung wird lila angezeigt.
  • Diese ARP-Anforderung dient zum Auflösen der MAC-Adresse des Hosts 10.1.202.10 von Leaf-01.
  • Beachten Sie, dass die violette Linie am CGW endet und nicht Leaf-01 erreicht.
• Die ARP-Antwort wird grün dargestellt und enthält die MAC der CGW-SVI für VLAN 202. 
  • Beachten Sie, dass die grüne Linie vom CGW kommt und nicht vom eigentlichen Host
• Das rote X bedeutet, dass diese Kommunikation keinen Datenverkehr an Leaf-01 gesendet hat.

Routingtyp 3 - Richtlinie (Leaf-01)

Überprüfen Sie, ob die Routing-Maps, die auf Leafs angewendet werden, ordnungsgemäß gefiltert werden. Wir sollten nur IMET-Präfixe vom CGW sehen und keine anderen Blätter. 

• Hier wird nur ein Blatt angezeigt, aber diese Prüfung sollte auf allen relevanten Blättern durchgeführt werden 

Es gibt zwei Methoden, um festzustellen, welcher Routing-Typ 3 installiert ist:

• BGP-Einträge überprüfen
• Überprüfen von l2route

BGP-Einträge überprüfen (Leaf-01)

Leaf-01#show bgp l2vpn evpn route-type 3 | inc Tunnel End
      PMSI Attribute: Flags:0x0, Tunnel type:IR, length 4, vni:20101, tunnel identifier: < Tunnel Endpoint: 172.16.254.6 >  <-- No RT3 prefixes present other than the CGW 172.16.254.6 
      PMSI Attribute: Flags:0x0, Tunnel type:IR, length 4, vni:20201, tunnel identifier: < Tunnel Endpoint: 172.16.254.6 >
      PMSI Attribute: Flags:0x0, Tunnel type:IR, length 4, vni:20101, tunnel identifier: < Tunnel Endpoint: 172.16.254.6 >
      PMSI Attribute: Flags:0x0, Tunnel type:IR, length 4, vni:20201, tunnel identifier: < Tunnel Endpoint: 172.16.254.6 >

l2route prüfen

Leaf-01-F241.03.23-9300#show l2route evpn imet
  EVI       ETAG   Prod                          Router IP Addr  Type    Label                               Tunnel ID Multicast Proxy
----- ---------- ------ --------------------------------------- ----- -------- --------------------------------------- ---------------
  201          0    BGP                            172.16.254.6     6    20101                            172.16.254.6              No <-- Only remote IMET producer is the CGW
  201          0  L2VPN                            172.16.254.3     6    20101                            172.16.254.3            IGMP
  202          0    BGP                            172.16.254.6     6    20201                            172.16.254.6              No
  202          0  L2VPN                            172.16.254.3     6    20201                            172.16.254.3            IGMP <-- Only remote IMET producer is the CGW

Lokales Routing (CGW) 

Vergewissern Sie sich, dass der CGW mit seiner eigenen MAC-Adresse antwortet, wenn die lokale ARP-Segmentauflösung auftritt. 

• Es gibt keinen anderen show-Befehl als die Verifizierung der im configure-Abschnitt gezeigten Konfigurationen. 
• Wir können dies überprüfen, indem wir bestätigen, welche MAC-Adresse auf dem Host programmiert ist, wenn ARP für einen Host auf einem anderen Leaf aufgelöst wird.

Erfassung einer ARP-Auflösungsanforderung, die vom Host von Leaf-02 an den Host von Leaf-01 gesendet wurde (Dies wurde mithilfe der EPC-Erfassung an der Leaf-02-Zugangsschnittstelle zum Host durchgeführt)

• Leaf-01 Host tatsächliche MAC: 0006.f601.cd45
• CGW-MAC, die auf die ARP-Anfrage reagiert hat: 0000.beef.cafe

Leaf-02-F241.03.23-9400#show mon cap 1 buff br | i ARP
   32  10.356291 00:06:f6:17:ee:c4 -> ff:ff:ff:ff:ff:ff ARP 64 Who has 10.1.202.10? Tell 10.1.202.11 <-- ARP request from Leaf-02 host
   33  10.357140 00:00:be:ef:ca:fe -> 00:06:f6:17:ee:c4 ARP 68 10.1.202.10 is at 00:00:be:ef:ca:fe   <-- ARP reply is the CGW MAC


Leaf-02-F241.03.23-9400#show mon cap 1 buff det | b Frame 32
Frame 32: 64 bytes on wire (512 bits), 64 bytes captured (512 bits) on interface /tmp/epc_ws/wif_to_ts_pipe, id 0
<...snip...>
    [Protocols in frame: eth:ethertype:vlan:ethertype:arp]
Ethernet II, Src: 00:06:f6:17:ee:c4 (00:06:f6:17:ee:c4), Dst: ff:ff:ff:ff:ff:ff (ff:ff:ff:ff:ff:ff)
    Destination: ff:ff:ff:ff:ff:ff (ff:ff:ff:ff:ff:ff)
        Address: ff:ff:ff:ff:ff:ff (ff:ff:ff:ff:ff:ff)
        .... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default)
        .... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast)
    Source: 00:06:f6:17:ee:c4 (00:06:f6:17:ee:c4)
        Address: 00:06:f6:17:ee:c4 (00:06:f6:17:ee:c4)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Type: 802.1Q Virtual LAN (0x8100)
802.1Q Virtual LAN, PRI: 0, DEI: 0, ID: 202                    <-- Vlan 202 
    000. .... .... .... = Priority: Best Effort (default) (0)
    ...0 .... .... .... = DEI: Ineligible
    .... 0000 1100 1010 = ID: 202
    Type: ARP (0x0806)
    Padding: 0000000000000000000000000000
    Trailer: 00000000
Address Resolution Protocol (request)                          <-- ARP Request 
    Hardware type: Ethernet (1)
    Protocol type: IPv4 (0x0800)
    Hardware size: 6
    Protocol size: 4
    Opcode: request (1)
    Sender MAC address: 00:06:f6:17:ee:c4 (00:06:f6:17:ee:c4)
    Sender IP address: 10.1.202.11
    Target MAC address: 00:00:00:00:00:00 (00:00:00:00:00:00)
    Target IP address: 10.1.202.10                              <-- Leaf-02 Host 

Frame 33: 68 bytes on wire (544 bits), 68 bytes captured (544 bits) on interface /tmp/epc_ws/wif_to_ts_pipe, id 0
<...snip...>
Ethernet II, Src: 00:00:be:ef:ca:fe (00:00:be:ef:ca:fe), Dst: 00:06:f6:17:ee:c4 (00:06:f6:17:ee:c4)
    Destination: 00:06:f6:17:ee:c4 (00:06:f6:17:ee:c4)
        Address: 00:06:f6:17:ee:c4 (00:06:f6:17:ee:c4)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Source: 00:00:be:ef:ca:fe (00:00:be:ef:ca:fe)
        Address: 00:00:be:ef:ca:fe (00:00:be:ef:ca:fe)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Type: CiscoMetaData (0x8909)
Cisco MetaData
    Version: 1
    Length: 1
    Options: 0x0001
    SGT: 0
    Type: ARP (0x0806)
    Padding: 00000000000000000000
    Trailer: 0000000000000000
Address Resolution Protocol (reply)
    Hardware type: Ethernet (1)
    Protocol type: IPv4 (0x0800)
    Hardware size: 6
    Protocol size: 4
    Opcode: reply (2)
    Sender MAC address: 00:00:be:ef:ca:fe (00:00:be:ef:ca:fe)   <-- ARP Reply is the CGW MAC 0000.beef.cafe
    Sender IP address: 10.1.202.10
    Target MAC address: 00:06:f6:17:ee:c4 (00:06:f6:17:ee:c4)   <-- MAC of host off Leaf-02 0006.f617.eec4
    Target IP address: 10.1.202.11

Fehlerbehebung

Debuggen der Route Map-Richtlinie (eingehend)

Bestätigen, dass eingehende Routing-Maps wie erwartet funktionieren

L2VPN-EVPN-Aktualisierungsdebugs aktivieren 

Leaf-02#debug bgp l2vpn evpn updates
BGP updates debugging is on for address family: L2VPN E-VPN

Leaf-02#debug bgp l2vpn evpn updates events
BGP update events debugging is on for address family: L2VPN E-VPN

Löschen der BGP-Adressfamilie zum Instanziieren der Routenrichtlinie

Leaf-02#clear bgp l2vpn evpn *

Vergewissern Sie sich, dass Routing-Typ 3 nur vom CGW akzeptiert und von allen anderen Leafs abgelehnt wird. 

Leaf-02#show log | i rcvd \[3\]
*Jul  4 06:40:41.556: BGP(10): 172.16.255.2 rcvd [3][172.16.254.6:202][0][32][172.16.254.6]/17    <-- Only accepted Type-3 is from the CGW (172.16.254.6)
*Jul  4 06:40:41.557: BGP(10): 172.16.255.2 rcvd [3][172.16.254.6:201][0][32][172.16.254.6]/17
*Jul  4 06:40:41.557: BGP(10): 172.16.255.2 rcvd [3][172.16.254.3:202][0][32][172.16.254.3]/17 -- DENIED due to: route-map;
*Jul  4 06:40:41.557: BGP(10): 172.16.255.2 rcvd [3][172.16.254.5:202][0][32][172.16.254.5]/17 -- DENIED due to: route-map;
*Jul  4 06:40:41.557: BGP(10): 172.16.255.2 rcvd [3][172.16.254.3:201][0][32][172.16.254.3]/17 -- DENIED due to: route-map;
*Jul  4 06:40:41.557: BGP(10): 172.16.255.2 rcvd [3][172.16.254.5:201][0][32][172.16.254.5]/17 -- DENIED due to: route-map;

Überprüfen der Route-Map-Richtlinie (ausgehend)

Überprüfen Sie im CGW, ob die Standard-Community auf die Typ-3-Präfixe von Leafs angewendet wurde. 

• In dieser Beispielausgabe werden BGP-Präfixe von Leaf-01 und Leaf-02 mit dem Community-Attribut dargestellt, das für das VLAN 202-Segment eingefügt wird 

CGW#show bgp l2vpn evpn route-type 3
BGP routing table entry for [3][172.16.254.6:202][0][32][172.16.254.3]/17, version 461855
Paths: (1 available, best #1, table evi_202)                                      <-- The EVI context for the vlan 202 segment 
  Not advertised to any peer
  Refresh Epoch 4
  Local, imported path from [3][172.16.254.3:202][0][32][172.16.254.3]/17 (global)
    172.16.254.3 (metric 3) (via default) from 172.16.255.2 (172.16.255.2)
      Origin incomplete, metric 0, localpref 100, valid, internal, best
      Community: 999:999                                                          <-- Route-map logic is good. Standard community applied to the Type-3 
      Extended Community: RT:65001:202 ENCAP:8 EVPN Mcast Flags:1
      Originator: 172.16.255.3, Cluster list: 172.16.255.2
      PMSI Attribute: Flags:0x0, Tunnel type:IR, length 4, vni:20201, tunnel identifier: < Tunnel Endpoint: 172.16.254.3 > <-- Type-3 tunnel 
      rx pathid: 0, tx pathid: 0x0
      Updated on Jan 22 2025 19:02:18 UTC
BGP routing table entry for [3][172.16.254.6:202][0][32][172.16.254.4]/17, version 605955
Paths: (1 available, best #1, table evi_202)
  Not advertised to any peer
  Refresh Epoch 4
  Local, imported path from [3][172.16.254.4:202][0][32][172.16.254.4]/17 (global)
    172.16.254.4 (metric 3) (via default) from 172.16.255.2 (172.16.255.2)
      Origin incomplete, metric 0, localpref 100, valid, internal, best
      Community: 999:999
      Extended Community: RT:65001:202 ENCAP:8 EVPN Mcast Flags:1
      Originator: 172.16.255.4, Cluster list: 172.16.255.2
      PMSI Attribute: Flags:0x0, Tunnel type:IR, length 4, vni:20201, tunnel identifier: < Tunnel Endpoint: 172.16.254.4 >
      rx pathid: 0, tx pathid: 0x0
      Updated on Jan 30 2025 18:50:49 UTC

Zugehörige Informationen

• Technischer Support und Dokumentation für Cisco Systeme
• BGP EVPN VXLAN Konfigurationsleitfaden, Cisco IOS XE Dublin 17.11.x (Catalyst Switches der Serie 9500)
• Dokumentation des Catalyst EVPN-Supports (LogAdvisor)