Implementeren en verifiëren van VxLAN-EVPN met alleen BGP op Catalyst 9000

Inleiding

In dit document wordt beschreven hoe u VXLAN Ethernet EVPN kunt implementeren en verifiëren op Switches uit de Cisco Catalyst 9000-reeks met alleen BGP.

Voorwaarden

Vereisten

Cisco raadt kennis van de volgende onderwerpen aan:

• Border Gateway Protocol (BGP) Ethernet VPN (EVPN)
• Virtual Extensible LAN (VXLAN) Overlay
• Gids voor softwareconfiguratie, Cisco IOS® XE

Gebruikte componenten

De informatie in dit document is gebaseerd op de volgende software- en hardware-versies:

• Katalysator 9600X
• Katalysator 9500X
• Cisco IOS XE 10 .12 en hoger
  

De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u zorgen dat u de potentiële impact van elke opdracht begrijpt.

Achtergrondinformatie

Het ontwerpen van een campusnetwerk van de volgende generatie omvat het toepassen van moderne technologieën en architecturen om te voldoen aan de evoluerende eisen van gebruikers, toepassingen en apparaten. VXLAN met BGP EVPN-oplossing kan een op verbindingen gebaseerde architectuur bieden voor eenvoud, schaalbaarheid en beheergemak. Dit document beschrijft de BGP EVPN-oplossing voor gebruikers die om welke reden dan ook liever BGP gebruiken voor zowel IPv4- als EVPN-routering.

BGP-only EVPN-gebruiksfunctie

VXLAN met BGP EVPN maakt gebruik van een stekelbladige architectuur in plaats van het traditionele 3-tier netwerkmodel. Met een ruggengraatarchitectuur fungeert de ruggengraat als een hogesnelheidskanaal tussen de switches. Het wervelkolommodel maakt een schaalmodel mogelijk waarbij de bandbreedte tussen bladeren kan worden verhoogd door extra stekels toe te voegen of de eindpuntcapaciteit kan worden verhoogd door meer bladeren toe te voegen.

Voor gebruikers die liever BGP gebruiken voor zowel IPv4- als EVPN-routeringsinformatie, neemt u deze overwegingen op:

• Vereenvoudigde configuratie: Met één BGP-sessie worden de configuratie en het beheer van routeringsinformatie gestroomlijnd. Het is niet nodig om aparte routeringsprotocollen voor IPv4 en EVPN te implementeren en te onderhouden, waardoor de complexiteit wordt verminderd.
  
• Unified Control Plane: Door gebruik te maken van BGP als het enige routeringsprotocol, is er een uniform controlevlak voor zowel IPv4- als EVPN-routes. Dit vergemakkelijkt efficiënte routeverspreiding, convergentie en routereclame in het hele datacenternetwerk.
• Schaalbaarheid: BGP is zeer geschikt voor het verwerken van grootschalige netwerken en biedt robuuste schaalbaarheid. Het gebruik van één BGP-sessie voor IPv4- en EVPN-routeringsinformatie zorgt voor efficiënte schaling naarmate het netwerk groeit, zonder dat meerdere routeringsprotocolinstanties nodig zijn. Tegelijkertijd is de BGP-convergentietijd voor grootschalige stoffen korter.
• Interoperabiliteit: BGP is een algemeen aanvaard standaard routeringsprotocol. Het gebruik van BGP vereenvoudigt uitsluitend de interoperabiliteit met verschillende netwerkapparatuur en leveranciers, waardoor compatibiliteit en naadloze integratie binnen de datacenteromgeving wordt gewaarborgd.

Deze topologie toont een gemeenschappelijk C9K EVPN Single Fabric-ontwerp.

C9K EVPN Single Fabric Design

BGP-only EVPN vergelijkingen en overwegingen

EBGP-vergelijkingen

Voor een BGP-only ontwerp is het eerste probleem dat moet worden overwogen of u Internal BGP (IBGP) of External BGP (EBGP) moet gebruiken. Het geval van het gebruik van IBGP, wat gebruikelijk is in VxLAN EVPN van traditionele DC. Vergeleken met het gebruik van IBGP als Underlay, bij het gebruik van EBGP, hoeft Spine niet langer te worden geconfigureerd als routereflector, maar functioneert het als een traditionele Router Server om routes uit te wisselen. De voorwaarde voor dit document is dus het gebruik van EBGP.

Optie 1.Two-AS: Spine gebruikt één AS en Leaf en Border Leaf gebruiken een andere AS.

Two-AS-model

Two-AS-model

Optie 2. Multi-AS: Spine, Leaf en Border Leaf gebruiken elk één AS.

Multi-AS-model

Bij het vergelijken van de twee ontwerpen is schaalbaarheid een veel voorkomend probleem, omdat voor optie 2, elke keer dat een ruggengraat of blad wordt toegevoegd, een nieuw AS-nummer moet worden toegevoegd, wat in de toekomst complexere configuratiewijzigingen met zich meebrengt, wat niet het geval is. Daarom wordt in dit document optie 1 gebruikt voor discussie.

In vergelijking met het gebruik van IBGP als Underlay, bij het gebruik van EBGP, hoeft Spine niet langer te worden geconfigureerd als routereflector, maar functioneert het als een traditionele Router Server om routes uit te wisselen.

Overweging voor onderliggend BGP IPv4-routering

Dit zijn belangrijke punten waarmee rekening moet worden gehouden in het onderliggend vlak.

Onderliggende BGP IPv4 toegestaan ALS IN

Onderliggende BGP IPv4 toegestaan ALS IN

AS-lusdetectie wordt uitgevoerd door het volledige AS-pad te scannen (zoals gespecificeerd in het kenmerk AS_PATH) en te controleren of het autonome systeemnummer van het lokale systeem niet in het AS-pad wordt weergegeven.

Volgens het bovenstaande schema wordt de BGP AS Loop gevormd - hetzelfde AS-nummer in het as-pad in dit scenario:

• Op Leaf en Border Leaf apparaten, de as-pad is {#1, #2, #1}.
• Op Spine-apparaten is het as-pad {#2, #1, #2}.

Om dit probleem op te lossen, wordt allow-as-in geconfigureerd in de BGP IPv4-adresfamilie, met de instructies die hier worden beschreven:

• Toegestaan dat AS In slechts één keer wordt weergegeven op alle Leaf- en Border Leaf-apparaten (Leaf > Spine > Leaf), aangezien alle Leaf-switches in dezelfde AS worden uitgevoerd.
• Toegestaan dat AS In slechts één keer wordt weergegeven op alle apparaten van de wervelkolom (wervelkolom > BL > ruggengraat) of (ruggengraat > blad > ruggengraat), aangezien alle apparaten van de wervelkolom in dezelfde AS worden uitgevoerd.

Opmerking: wanneer Single-Fabric wordt gebruikt met DGW, is het onwaarschijnlijk dat routering van de ene wervelkolom naar de andere vereist is. Gezien de veranderingen in de topologie, zoals super-spine, wordt het echter aanbevolen om ook AS-controle op Spine-apparaten uit te schakelen.

Onderliggende BGP IPv4-maximumpaden

BGP kiest een route op basis van zijn criteria en het is onwaarschijnlijk dat 2 ECMP-routes standaard in de BGP-tabel worden weergegeven. Om ECMP voor bandbreedte-optimalisatie te bereiken, moeten maximale paden X worden geconfigureerd in de BGP IPv4-adresfamilie in alle BGP-actieve apparaten. Ondertussen stellen we voor om dezelfde linkbandbreedte tussen wervelkolom en blad te behouden als een beste praktijk.

Opmerking: De maximale paden zijn afhankelijk van het ontwerp van de topologie. Met twee spine-switches kunt u 'maximum-paden 2' configureren.

Overweging BGP EVPN-routering overlay

Deze belangrijke punten moeten worden overwogen in het overlay-vlak.

Overlay BGP EVPN TOEGESTAAN ALS IN

Overlay BGP IPv4 TOEGESTAAN ALS IN

AS-lusdetectie wordt uitgevoerd door het volledige AS-pad te scannen (zoals gespecificeerd in het kenmerk AS_PATH) en te controleren of het autonome systeemnummer van het lokale systeem niet in het AS-pad wordt weergegeven.

Volgens de afbeelding wordt de BGP AS Loop gevormd - hetzelfde AS-nummer in het as-pad in dit scenario:

• Op Leaf en Border Leaf apparaten, de as-pad is {#1, #2, #1}
• Op Spine-apparaten is het as-pad {#2, #1, #2}

Om dit probleem op te lossen, moet allow-as-in worden geconfigureerd in de BGP IPv4-adresfamilie, met de volgende instructies:

• Toegestaan dat AS In slechts één keer wordt weergegeven op alle Leaf- en Border Leaf-apparaten (Leaf > Spine > Leaf), aangezien alle Leaf-switches in dezelfde AS worden uitgevoerd.
• Toegestaan dat AS In slechts één keer wordt weergegeven op alle apparaten van de wervelkolom (wervelkolom > BL > ruggengraat) of (ruggengraat > blad > ruggengraat), aangezien alle apparaten van de wervelkolom in dezelfde AS worden uitgevoerd.

Opmerking: wanneer Single-Fabric wordt gebruikt met DGW, is het onwaarschijnlijk dat routering van de ene wervelkolom naar de andere vereist is. Gezien de veranderingen in de topologie, zoals super-spine, wordt het echter aanbevolen om ook AS-controle op Spine-apparaten uit te schakelen.

Overlay BGP EVPN Verander Next-Hop niet

BGP wijzigt standaard het next-hop attribuut van Network layer accessibility information (NLRI) dat wordt geadverteerd vanuit de EBGP-buur. Leaf/VXLAN Tunnel End Point (VTEP) gebruikt zijn NVE-bronadres als het next-hop-attribuut van de EVPN-routes en dit adres wordt gebruikt om de bestemming van de VXLAN-tunnel (Network Virtual Interface/NVE peer) te bepalen. Als de knooppunten van de wervelkolom de volgende stap wijzigen, kan de VXLAN-tunnel niet correct worden ingesteld.

Om dit probleem op te lossen, worden deze instructies toegepast:

• Op alle Spine-knooppunten moet routekaart worden geconfigureerd met actie next-hop ongewijzigd

Overlay BGP EVPN RT-filter uitschakelen

De EVPN-routes van de Leaf-apparaten worden geadverteerd met de Route Target (RT) -community. Routers zonder de bijbehorende RT-configuratie laten de routes standaard vallen met de RT-community. Terwijl alle apparaten van de wervelkolom geen Virtual Routing and Forwarding (VRF) hebben geconfigureerd. Het betekent dat de ruggengraat apparaten vallen alle EVPN routes geadverteerd van de Leaf apparaten standaard.

Om dit probleem op te lossen moet op alle Spine-knooppunten het standaard route-doelfilter worden uitgeschakeld.

Configureren

Netwerkdiagram

Netwerkdiagram

Interfacedetails voor deze laboratoriumomgeving zijn als volgt.

Opmerking: de toewijzing van het IP-adres in dit laboratorium is alleen voor testdoeleinden. Subnetmasker (dat wil zeggen /30, /31) voor Point-to-Point-verbindingen kan worden overwogen op basis van uw werkelijke ontwerpvereisten.

Configuraties

Onderliggende BGP IPv4-routering

In dit voorbeeld worden de fysieke interfaces gebruikt om BGP-verbindingen tot stand te brengen.

• BGP IPv4-routering configureren
• BGP IPv4 configureren als toegestaan in
• Maximumpaden voor BGP configureren

BGP IPv4-routering configureren

Configuratie op wervelkolom:

router bgp 65001
bgp log-neighbor-changes
bgp listen range 172.16.0.0/16 peer-group Leaf-Peers
no bgp default ipv4-unicast
neighbor Leaf-Peers peer-group
neighbor Leaf-Peers remote-as 65002
!
address-family ipv4
redistribute connected
neighbor Leaf-Peers activate
neighbor Leaf-Peers allowas-in 1
maximum-paths 2
exit-address-family

Configuratie op Leaf-1:

router bgp 65002
bgp log-neighbor-changes
no bgp default ipv4-unicast
neighbor 172.16.11.1 remote-as 65001
neighbor 172.16.21.1 remote-as 65001
!
address-family ipv4
redistribute connected
neighbor 172.16.11.1 activate
neighbor 172.16.21.1 activate
exit-address-family

Configuratie op Leaf-2:

router bgp 65002
bgp log-neighbor-changes
no bgp default ipv4-unicast
neighbor 172.16.12.1 remote-as 65001
neighbor 172.16.22.1 remote-as 65001
!
address-family ipv4
redistribute connected
neighbor 172.16.12.1 activate
neighbor 172.16.22.1 activate
exit-address-family

BGP IPv4 configureren als toegestaan in

Configuratie op wervelkolom:

router bgp 65001
address-family ipv4
neighbor Leaf-Peers allowas-in 1

Configuratie op Leaf-1:

router bgp 65002
address-family ipv4
neighbor 172.16.11.1 allowas-in 1
neighbor 172.16.21.1 allowas-in 1

Configuratie op Leaf-2:

router bgp 65002
address-family ipv4
neighbor 172.16.12.1 allowas-in 1
neighbor 172.16.22.1 allowas-in 1

Maximumpaden voor BGP configureren

Configuratie op wervelkolom:

router bgp 65001
address-family ipv4
maximum-paths 2

Configuratie op blad:

router bgp 65002
address-family ipv4
maximum-paths 2

onderliggend multicast

Om Multicast Replication (MR) in staat te stellen om Broadcast-, Unknown Unicast- en Link-Local Multicast (BUM)-verkeer te verwerken, is multicast-routering vereist op alle Spine- en Leaf-apparaten. Voor alle verbindingsinterfaces van de wervelkolom en het blad en de bijbehorende loopbacks moet PIM zijn ingeschakeld.

Voorbeeld van onderliggend multicast op Spine 1:

ip multicast-routing
ip pim rp-address 10.1.255.1 //configure Spine loopback as RP
interface Loopback0
ip pim sparse-mode
interface HundredGigE1/0/9
ip pim sparse-mode
interface HundredGigE1/0/10
ip pim sparse-mode

Overlay BGP

• BGP L2VPN EVPN configureren
• BGP EVPN configureren als toegestaan in
• BGP EVPN configureren Volgende hop niet wijzigen
• BGP EVPN configureren RT-filter uitschakelen

BGP L2VPN EVPN configureren

Configuratie op wervelkolom:

router bgp 65001
neighbor Leaf-Peers ebgp-multihop 255
address-family l2vpn evpn
neighbor Leaf-Peers activate
neighbor Leaf-Peers send-community both

Configuratie op Leaf-1:

router bgp 65002
neighbor 172.16.11.1 ebgp-multihop 255
neighbor 172.16.21.1 ebgp-multihop 255
address-family l2vpn evpn
neighbor 172.16.11.1 activate
neighbor 172.16.11.1 send-community both
neighbor 172.16.21.1 activate
neighbor 172.16.21.1 send-community both

Configuratie op Leaf-2:

router bgp 65002
neighbor 172.16.12.1 ebgp-multihop 255
neighbor 172.16.22.1 ebgp-multihop 255
address-family l2vpn evpn
neighbor 172.16.12.1 activate
neighbor 172.16.12.1 send-community both
neighbor 172.16.22.1 activate
neighbor 172.16.22.1 send-community both

BGP EVPN configureren als toegestaan in

Configuratie op Leaf-1:

router bgp 65002
address-family l2vpn evpn
neighbor 172.16.11.1 allowas-in 1
neighbor 172.16.21.1 allowas-in 1

Configuratie op Leaf-2:

router bgp 65002
address-family l2vpn evpn
neighbor 172.16.12.1 allowas-in 1
neighbor 172.16.22.1 allowas-in 1

Opmerking: wanneer Single-Fabric wordt gebruikt met DGW, is het onwaarschijnlijk dat routering van de ene wervelkolom naar de andere vereist is. Gezien de veranderingen in de topologie, zoals super-spine, wordt het echter aanbevolen om ook AS-controle op Spine-apparaten uit te schakelen.

BGP EVPN configureren: niet wijzigen Next-Hop

Configuratie op wervelkolom:

route-map BGP-NHU permit 10 
set ip next-hop unchanged
!
router bgp 65001
address-family l2vpn evpn
neighbor Leaf-Peers route-map BGP-NHU out

BGP EVPN configureren RT-filter uitschakelen

Configuratie op wervelkolom:

router bgp 65001
no bgp default route-target filter

VRF-configuratie op blad

vrf definition S1-EVPN
rd 1:1
!
address-family ipv4
route-target export 1:1
route-target import 1:1
route-target export 1:1 stitching
route-target import 1:1 stitching
exit-address-family
router bgp 65002
address-family ipv4 vrf S1-EVPN
advertise l2vpn evpn
redistribute connected
maximum-paths 2
exit-address-family

EVPN L2

L2VPN EVPN- en multicast-replicatie op Leaf inschakelen:

l2vpn evpn
replication-type static

EVPN-instanties (EVI) maken op Leaf:

l2vpn evpn instance 10 vlan-based
encapsulation vxlan
l2vpn evpn instance 20 vlan-based
encapsulation vxlan

Maak VLAN's en VNI voor gebruikersverkeer op Leaf:

vlan configuration 10
member evpn-instance 10 vni 10010
vlan configuration 20
member evpn-instance 20 vni 10020

Maak een NVE-interface en steek VNI om groepen op Leaf te casten.

interface nve1
no ip address
source-interface Loopback1
host-reachability protocol bgp
member vni 10010 mcast-group 225.0.0.10
member vni 10020 mcast-group 225.0.0.20

EVPN L3

Maak VLAN voor L3VNI op Leaf. EVI is niet vereist voor L3VNI.

vlan configuration 3000
member vni 33000

Configureer SVI voor L2VNI op Leaf.

interface Vlan10
mac-address 0010.0010.0010
vrf forwarding S1-EVPN
ip address 192.168.10.254 255.255.255.0

Configureer SVI voor L3VNI op Leaf. "geen autostate" is geconfigureerd om de SVI omhoog te brengen wanneer er geen actieve interface is toegewezen aan dat VLAN. 

interface Vlan3000
vrf forwarding S1-EVPN
ip unnumbered Loopback1
no autostate

Op Leaf, steek L3VNI aan de VRF onder NVE-configuratie.

interface nve1
member vni 33000 vrf S1-EVPN

Verifiëren

Controleer of BGP-sessies zijn ingesteld

C9600X-SPINE-1#show ip bgp all summary 
For address family: IPv4 Unicast
BGP router identifier 10.1.255.1, local AS number 65001
BGP table version is 23, main routing table version 23
12 network entries using 2976 bytes of memory
22 path entries using 2992 bytes of memory
2 multipath network entries and 4 multipath paths
4/3 BGP path/bestpath attribute entries using 1184 bytes of memory
3 BGP AS-PATH entries using 104 bytes of memory
8 BGP extended community entries using 400 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 7656 total bytes of memory
BGP activity 7259/7235 prefixes, 13926/13892 paths, scan interval 60 secs
12 networks peaked at 07:06:41 Dec 5 2023 UTC (2w1d ago)

Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
*172.16.11.2    4        65002     138     130       23    0    0 01:38:17        9
*172.16.12.2    4        65002     138     130       23    0    0 01:38:11        9
* Dynamically created based on a listen range command
Dynamically created neighbors: 2, Subnet ranges: 1

BGP peergroup Leaf-Peers listen range group members: 
  172.16.0.0/16 

For address family: L2VPN E-VPN
BGP router identifier 10.1.255.1, local AS number 65001
BGP table version is 27, main routing table version 27
10 network entries using 3840 bytes of memory
12 path entries using 2784 bytes of memory
8/6 BGP path/bestpath attribute entries using 2368 bytes of memory
3 BGP AS-PATH entries using 104 bytes of memory
8 BGP extended community entries using 400 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 9496 total bytes of memory
BGP activity 7259/7235 prefixes, 13926/13892 paths, scan interval 60 secs
12 networks peaked at 07:38:03 Dec 6 2023 UTC (2w0d ago)

Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
*172.16.11.2    4        65002     138     130       27    0    0 01:38:17        6
*172.16.12.2    4        65002     138     130       27    0    0 01:38:11        6
* Dynamically created based on a listen range command
Dynamically created neighbors: 2, Subnet ranges: 1

BGP peergroup Leaf-Peers listen range group members: 
  172.16.0.0/16 

Total dynamically created neighbors: 2/(100 max), Subnet ranges: 1
  

C9500X-LEAF-1#show ip bgp all summary 
For address family: IPv4 Unicast
BGP router identifier 10.2.255.1, local AS number 65002
BGP table version is 19, main routing table version 19
12 network entries using 2976 bytes of memory
22 path entries using 2992 bytes of memory
2 multipath network entries and 4 multipath paths
4/3 BGP path/bestpath attribute entries using 1184 bytes of memory
3 BGP AS-PATH entries using 104 bytes of memory
8 BGP extended community entries using 384 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 7640 total bytes of memory
BGP activity 577/545 prefixes, 4021/3975 paths, scan interval 60 secs
12 networks peaked at 07:10:16 Dec 5 2023 UTC (1d18h ago)

Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
172.16.11.1     4        65001    2427    3100       19    0    0 20:39:49        9
172.16.21.1     4        65001    2430    3094       19    0    0 20:39:49        9

For address family: L2VPN E-VPN
BGP router identifier 10.2.255.1, local AS number 65002
BGP table version is 5371, main routing table version 5371
16 network entries using 6144 bytes of memory
20 path entries using 4640 bytes of memory
9/9 BGP path/bestpath attribute entries using 2664 bytes of memory
3 BGP AS-PATH entries using 104 bytes of memory
8 BGP extended community entries using 384 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 13936 total bytes of memory
BGP activity 577/545 prefixes, 4021/3975 paths, scan interval 60 secs
16 networks peaked at 07:36:38 Dec 6 2023 UTC (18:16:58.620 ago)

Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
172.16.11.1     4        65001    2427    3100     5371    0    0 20:39:49        4
172.16.21.1     4        65001    2430    3094     5371    0    0 20:39:49        4
 

Initiate traffic between hosts, verify IP Multicast and PIM configuration, and mroute table.

Please note that on IOS-XE platform, (*, G) entry should always present, and (S, G) entry presents only when BUM traffic present.




C9600X-SPINE-1#show ip mroute 
IP Multicast Routing Table
<snip>
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
                          t - LISP transit group
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 225.0.0.20), 16:51:00/stopped, RP 10.1.255.1, flags: SJCx
  Incoming interface: HundredGigE1/0/2, RPF nbr 172.16.11.1
  Outgoing interface list:
    Tunnel0, Forward/Sparse-Dense, 16:51:00/00:02:58, flags: 

(*, 225.0.0.10), 16:51:14/stopped, RP 10.1.255.1, flags: SJCFx
  Incoming interface: HundredGigE1/0/2, RPF nbr 172.16.11.1
  Outgoing interface list:
    Tunnel0, Forward/Sparse-Dense, 16:51:14/00:02:45, flags: 

(10.2.254.1, 225.0.0.10), 00:00:01/00:02:57, flags: FTx
  Incoming interface: Loopback1, RPF nbr 0.0.0.0, Registering
  Outgoing interface list:
    HundredGigE1/0/2, Forward/Sparse, 00:00:01/00:03:27, flags: 

(*, 224.0.1.40), 1d18h/00:02:42, RP 10.1.255.1, flags: SJCL
  Incoming interface: HundredGigE1/0/2, RPF nbr 172.16.11.1
  Outgoing interface list:
    Loopback0, Forward/Sparse, 1d18h/00:02:42, flags 
 

EVPN L2 verifiëren

C9500X-LEAF-1#show l2vpn evpn evi 10 detail 
EVPN instance:       10 (VLAN Based)
  RD:                10.2.254.1:10 (auto)
  Import-RTs:        65002:10 
  Export-RTs:        65002:10
<snip>

C9500X-LEAF-1#show nve peers 
'M' - MAC entry download flag  'A' - Adjacency download flag
'4' - IPv4 flag  '6' - IPv6 flag

Interface  VNI      Type Peer-IP          RMAC/Num_RTs   eVNI     state flags UP time
nve1       33000    L3CP 10.2.254.2       242a.0412.0102 33000      UP  A/M/4 18:11:35
nve1       10010    L2CP 10.2.254.2       2              10010      UP   N/A  00:36:00
nve1       10020    L2CP 10.2.254.2       2              10020      UP   N/A  00:01:17

C9500X-LEAF-1#show bgp l2vpn evpn 
BGP table version is 5475, local router ID is 10.2.254.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, 
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, 
              x best-external, a additional-path, c RIB-compressed, 
              t secondary path, L long-lived-stale,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 10.2.254.1:10
 *>   [2][10.2.254.1:10][0][48][683B78FC8C9F][0][*]/20
                      10.2.254.2                             0 65001 65002 ?
 *>   [2][10.2.254.1:10][0][48][683B78FC8C9F][32][192.168.10.45]/24
                      10.2.254.2                             0 65001 65002 ?
<snip>

C9500X-LEAF-1#show bgp l2vpn evpn detail [2][10.2.254.1:10][0][48][683B78FC8C9F][32][192.168.10.45]/24
BGP routing table entry for [2][10.2.254.1:10][0][48][683B78FC8C9F][32][192.168.10.45]/24, version 5371
Paths: (1 available, best #1, table evi_10)
  Not advertised to any peer
  Refresh Epoch 12
  65001 65002, imported path from [2][10.2.254.2:10][0][48][683B78FC8C9F][32][192.168.10.45]/24 (global)
    10.2.254.2 (via default) from 172.16.21.1 (10.1.255.2)
      Origin incomplete, localpref 100, valid, external, best
      EVPN ESI: 00000000000000000000, Label1 10010, Label2 33000
      Extended Community: RT:1:1 RT:65002:10 ENCAP:8 
        Router MAC:242A.0412.0102
      rx pathid: 0, tx pathid: 0x0
      Updated on Dec 7 2023 01:52:33 UTC

C9500X-LEAF-1#show device-tracking database 
<snip>

    Network Layer Address                    Link Layer Address     Interface  vlan       prlvl      age        state      Time left       
ARP 192.168.20.25                            3c13.cc01.a7df         Hu1/0/7    20         0005       3mn        REACHABLE  103 s           
ARP 192.168.10.25                            3c13.cc01.a7df         Hu1/0/7    10         0005       20mn       STALE     try 0 943 s

C9500X-LEAF-1#show l2vpn evpn mac ip 
IP Address                              EVI   VLAN  MAC Address    Next Hop(s)
--------------------------------------- ----- ----- -------------- -----------
192.168.10.25                           10    10    3c13.cc01.a7df Hu1/0/7:10
192.168.10.45                           10    10    683b.78fc.8c9f 10.2.254.2
 

EVPN L3 verifiëren

C9500X-LEAF-1#show nve peers 
'M' - MAC entry download flag  'A' - Adjacency download flag
'4' - IPv4 flag  '6' - IPv6 flag

Interface  VNI      Type Peer-IP          RMAC/Num_RTs   eVNI     state flags UP time
nve1       33000    L3CP 10.2.254.2       242a.0412.0102 33000      UP  A/M/4 18:50:51
nve1       10010    L2CP 10.2.254.2       2              10010      UP   N/A  01:15:16
nve1       10020    L2CP 10.2.254.2       2              10020      UP   N/A  00:31:39

9500X-LEAF-1#sh bgp l2vpn evpn 
BGP table version is 5523, local router ID is 10.2.255.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, 
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, 
              x best-external, a additional-path, c RIB-compressed, 
              t secondary path, L long-lived-stale,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
<snip>
Route Distinguisher: 1:1 (default for vrf S1-EVPN)
 *>   [5][1:1][0][24][192.168.10.0]/17
                      0.0.0.0                  0         32768 ?
 *>   [5][1:1][0][24][192.168.20.0]/17
                      0.0.0.0                  0         32768 ?

C9500X-LEAF-1#sh ip ro vrf S1-EVPN

Routing Table: S1-EVPN
<snip>
      192.168.10.0/24 is variably subnetted, 4 subnets, 2 masks
C        192.168.10.0/24 is directly connected, Vlan10
S        192.168.10.25/32 is directly connected, Vlan10
B        192.168.10.45/32 [20/0] via 10.2.254.2, 00:00:56, Vlan3000
L        192.168.10.254/32 is directly connected, Vlan10
      192.168.20.0/24 is variably subnetted, 4 subnets, 2 masks
C        192.168.20.0/24 is directly connected, Vlan20
S        192.168.20.25/32 is directly connected, Vlan20
B        192.168.20.45/32 [20/0] via 10.2.254.2, 00:49:54, Vlan3000
L        192.168.20.254/32 is directly connected, Vlan20

Gerelateerde informatie

• BGP EVPN VXLAN Configuratiegids, Cisco IOS XE Dublin 17.12.x:
• Cisco Technical Support en downloads