VXLAN Journey - Part 02 - What is VXLAN and how it works (Cisco Nexus Switch) - Basic control plane learning
We have covered some basic theories/concepts regarding VXLAN and implemented a simple topology using data-plane learning in Part 01. Now we will use the same topology to implement VXLAN using control-plane learning.
Why I am calling the topology - control-plane learning? This time we will use routing protocols - OSPF, BGP etc. to build our VXLAN tunnels dynamically and exchange forwarding information.
Let's talk about our routing protocols first. We will use OSPF for underlay unicast routing. For overlay we will use BGP-EVPN address family to exchange forwarding information. BGP EVPN Type-2 routes (MAC/IP Advertisement Route) will be used to forward traffic between our clients. BUM traffic will be forwarded using BGP EVPN Type-3 routes. For simplicity we will not use multicast protocol (PIM etc.) for BUM traffic. Instead we will rely on BGP Head-End-Replication (also known as ingress replication) for BUM traffic forwarding.
A little refresher about - RD and RT in BGP protocol. Route Distinguishers (RDs) make routes unique by prepending a 64-bit value to the actual routes. Route Target (RT) is a BGP extended community which controls policy for importing and exporting routes to/from VRFs. But important thing is - RD and RT does different things: in the context of VXLAN; RD makes routes unique in Global/Default VRF; RT is used to import/export routes to/from Global/Default VRF to custom VRFs (a custom VRF = a customer) using BGP. Cisco NXOS supports RD and RT auto generation which makes VXLAN with BGP-EVPN configuration a lot easier. But in this lab we will manually configure RD and RT so that we can understand their use case in BGP-EVPN address family.
Let's have a look at our topology and start configuring -
 |
| 01 - VXLAN - Control-Plane Topology |
IP addressing is configured according to the table below -
|
Device |
Interface |
IP Address |
Mac Adress |
Vlan/VNI |
Description |
|
Leaf-Sw-01 |
loopback0 |
10.81.0.1/32 |
|
|
Underlay routing
loopback |
|
Leaf-Sw-01 |
eth1/1 |
unnumbered loopback0 |
|
|
Underlay layer-3
interface |
|
Leaf-Sw-01 |
eth1/2 |
unnumbered loopback0 |
|
|
Underlay layer-3
interface |
|
Leaf-Sw-01 |
loopback1 |
10.81.1.1/32 |
|
|
Overlay vtep
loopback |
|
Leaf-Sw-01 |
eth1/15 |
|
|
101/100101 |
Connection to Pc-01 |
|
Leaf-Sw-02 |
loopback0 |
10.81.0.2/32 |
|
|
Underlay routing
loopback |
|
Leaf-Sw-02 |
eth1/1 |
unnumbered loopback0 |
|
|
Underlay layer-3
interface |
|
Leaf-Sw-02 |
eth1/2 |
unnumbered loopback0 |
|
|
Underlay layer-3
interface |
|
Leaf-Sw-02 |
loopback1 |
10.81.1.2/32 |
|
|
Overlay vtep
loopback |
|
Leaf-Sw-02 |
eth1/15 |
|
|
101/100101 |
Connection to Pc-01 |
|
Pc-01 |
eth0 |
10.85.101.11/24 |
50:c0:6a:00:04:00 |
|
Pc-01 |
|
Pc-02 |
eth0 |
10.85.101.12/24 |
50:77:ae:00:05:00 |
|
Pc-01 |
!
!!! Underlay will use OSPF dynamic routing protocol for reachability.
feature ospf
!!! OSPF process configuration.
router ospf UNDERLAY
router-id 10.81.0.1
log-adjacency-changes detail
!!! Underlay loopback0 which will be used to configure unnumbered physical interfaces.
interface loopback0
description Underlay-Routing-Loopback
ip address 10.81.0.1/32
!!! OSPF is enabled.
ip router ospf UNDERLAY area 0.0.0.0
!
!!! Inter-switch links are configured as layer-3 to eliminate STP.
interface Ethernet1/1
description To_Leaf-Sw-02_e1/1
no switchport
!!! change mtu to accommodate vxlan packet.
mtu 9216
!!! Cisco quirks to configure interface as unnumbered - medium must be p2p.
medium p2p
!!! Ip address is borrowed from loopback0.
ip unnumbered loopback0
no ip redirects
!!! Inter-switch links are enabled for OSPF.
ip router ospf UNDERLAY area 0.0.0.0
!!! Cisco NXOS automatically configures unnumbered interfaces as p2p for OSPF.
!!! This command is optional for NXOS.
ip ospf network point-to-point
no shutdown
!
interface Ethernet1/2
description To_Leaf-Sw-02_e1/2
no switchport
mtu 9216
medium p2p
ip unnumbered loopback0
no ip redirects
ip router ospf UNDERLAY area 0.0.0.0
ip ospf network point-to-point
no shutdown
!
!!! Overlay Vtep loopback (Vxlan tunnels will be established using loopback1).
interface loopback1
description Overlay-Vtep-Loopback
ip address 10.81.1.1/32
!!! OSPF is enabled.
ip router ospf UNDERLAY area 0.0.0.0
!
Leaf-Sw-02 Underlay Configuration -
!
feature ospf
router ospf UNDERLAY
router-id 10.81.0.2
log-adjacency-changes detail
!
interface loopback0
description Underlay-Routing-Loopback
ip address 10.81.0.2/32
ip router ospf UNDERLAY area 0.0.0.0
!
interface Ethernet1/1
description To_Leaf-Sw-01_e1/1
no switchport
mtu 9216
medium p2p
ip unnumbered loopback0
no ip redirects
ip router ospf UNDERLAY area 0.0.0.0
no shutdown
!
interface Ethernet1/2
description To_Leaf-Sw-01_e1/2
no switchport
mtu 9216
medium p2p
ip unnumbered loopback0
no ip redirects
ip router ospf UNDERLAY area 0.0.0.0
no shutdown
!
interface loopback1
description Overlay-Vtep-Loopback
ip address 10.81.1.2/32
ip router ospf UNDERLAY area 0.0.0.0
!
Underlay routing verification
Because of OSPF configuration above, we should have full network reachability in the underlay network between Leaf-Sw-01 and Leaf-Sw-02. We can verify this with some basic commands -
Leaf-Sw-01# show ip ospf interface brief
OSPF Process ID UNDERLAY VRF default
Total number of interface: 4
!!! 4 interfaces are participating in OSPF - 2 physical & 2 loopback interface.
Interface ID Area Cost State Neighbors Status
Eth1/1 2 0.0.0.0 40 P2P 1 up
Eth1/2 3 0.0.0.0 40 P2P 1 up
Lo0 1 0.0.0.0 1 LOOPBACK 0 up
Lo1 4 0.0.0.0 1 LOOPBACK 0 up
Leaf-Sw-01# show ip ospf neighbors detail
!!! 2 full ospf adjacencies established over two physical interface with Leaf-Sw-02.
Neighbor 10.82.0.2, interface address 10.81.0.2
Process ID UNDERLAY VRF default, in area 0.0.0.0 via interface Ethernet1/1
State is FULL, 5 state changes, last change 6d23h
Hello options 0x2, dbd options 0x42
Last non-hello packet received 00:07:34
Dead timer due in 00:00:41
Neighbor 10.82.0.2, interface address 10.81.0.2
Process ID UNDERLAY VRF default, in area 0.0.0.0 via interface Ethernet1/2
State is FULL, 5 state changes, last change 6d23h
Hello options 0x2, dbd options 0x42
Last non-hello packet received 00:07:34
Dead timer due in 00:00:33
Leaf-Sw-01(config)# show ip route ospf
IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>
!!! ECMP routes with OSPF for Sw-Leaf-02's loopback0.
10.81.0.2/32, ubest/mbest: 2/0
*via 10.81.0.2, Eth1/1, [110/41], 6d23h, ospf-UNDERLAY, intra
*via 10.81.0.2, Eth1/2, [110/41], 6d23h, ospf-UNDERLAY, intra
!!! ECMP routes with OSPF for Sw-Leaf-02's loopback1.
10.81.1.2/32, ubest/mbest: 2/0
*via 10.81.0.2, Eth1/1, [110/41], 6d23h, ospf-UNDERLAY, intra
*via 10.81.0.2, Eth1/2, [110/41], 6d23h, ospf-UNDERLAY, intra
Leaf-Sw-01(config)# ping 10.81.1.2 source 10.81.1.1
!!! Successful ping from Leaf-Sw-01's loopback1 to Leaf-Sw-02's loopback1.
PING 10.81.1.2 (10.81.1.2) from 10.81.1.1: 56 data bytes
64 bytes from 10.81.1.2: icmp_seq=0 ttl=254 time=4.839 ms
64 bytes from 10.81.1.2: icmp_seq=1 ttl=254 time=1.287 ms
64 bytes from 10.81.1.2: icmp_seq=2 ttl=254 time=1.342 ms
64 bytes from 10.81.1.2: icmp_seq=3 ttl=254 time=1.308 ms
64 bytes from 10.81.1.2: icmp_seq=4 ttl=254 time=1.403 ms
--- 10.81.1.2 ping statistics ---
5 packets transmitted, 5 packets received, 0.00% packet loss
Leaf-Sw-01 Overlay Configuration -
!
!!! Allows to map a VLAN to a VXLAN Network Identifier (VNI).
feature vn-segment-vlan-based
!
!!! Allows to configure nve1 interface - which is the actual vxlan/vtep tunnel interface. Cisco calls it - nve (Network Virtualization Edge).
feature nv overlay
!
!!! Enable BGP routing.
feature bgp
!!! Enables BGP-EVPN address family.
nv overlay evpn
!
vlan 101
name Client-Test-Vlan
!!! Assigning a VNI to the Vlan.
vn-segment 100101
!
interface Ethernet1/15
description To_Pc-01
!!! Port connected to Pc-01 is configured for vlan 101 in access mode.
switchport access vlan 101
!
!!! BGP configuration for EVPN address family.
!!! iBGP will be used between Leaf-Sw-01 and Leaf-Sw-02.
router bgp 64512
!!! Router-id is loopback0.
router-id 10.81.0.1
log-neighbor-changes
!!! Leaf-Sw-02's loopback0 is the BGP neighbor.
neighbor 10.81.0.2
remote-as 64512
description Leaf-Sw-02
!!! BGP communication will be done over loopback0 interface.
update-source loopback0
address-family l2vpn evpn
!!! For EVPN address family enable both BGP standard and extended community.
!!! The extended community will carry RT.
!!! Cisco NXOS quirk, as it is not done by default.
send-community
send-community extended
!
evpn
!!! vni to RD and RT mapping (manually).
vni 100101 l2
!!! RD is chosen arbitrary with format BGP-Router-ID:Vlan-Id.
!!! Leaf-Sw-01 will use it's own BGP-Router-ID in RD.
rd 10.81.0.1:101
!!! Import and export RT are chosen arbitrary with format BGP-ASN:VNI-Id.
!!! In our topology route-targets will not be used as we do not have any VRF or customer/tenant routing instance.
route-target import 64512:100101
route-target export 64512:100101
!
interface nve1
no shutdown
description Vtep-Vxlan
!!! Vtep interface borrows it's IP address from loopback1.
source-interface loopback1
!!! NVE/VTEP interface will use BGP EVPN as the control plane for learning remote end-hosts mac addresses.
host-reachability protocol bgp
!!! Enable vni 100101 (vlan 101) traffic tunneling over nve/vtep/vxlan interface.
member vni 100101
!!! How to handle BUM traffic (Broadcast, Unknown Unicast, and Multicast).
!!! BUM traffic received by Leaf-Sw-01, for example - ARP traffic will be forwarded to Leaf-Sw-02 over nve interface.
!!! Replicate the BUM traffic to all the VTEPs learned from BGP-EVPN. This is called ingress-replication or head-end replication (HER).
!!! For simplicity we are not using any multicast protocol for BUM traffic.
ingress-replication protocol bgp
!
Leaf-Sw-02 Overlay Configuration -
!
feature vn-segment-vlan-based
!
feature nv overlay
!
feature bgp
!
nv overlay evpn
!
vlan 101
name Client-Test-Vlan
vn-segment 100101
!
interface Ethernet1/15
description To_Pc-02
switchport access vlan 101
!
router bgp 64512
!!! Router-id is loopback0.
router-id 10.81.0.2
log-neighbor-changes
!!! Leaf-Sw-01's loopback0 is the BGP neighbor.
neighbor 10.81.0.1
remote-as 64512
description Leaf-Sw-01
!!! BGP communication will be done over loopback0 interface.
update-source loopback0
address-family l2vpn evpn
send-community
send-community extended
!
evpn
vni 100101 l2
!!! RD is chosen arbitrary with format BGP-Router-ID:Vlan-Id.
!!! Leaf-Sw-02 will use it's own BGP-Router-ID in RD.
rd 10.81.0.2:101
!!! Import and export RT are chosen arbitrary with format BGP-ASN:VNI-Id.
!!! In our topology route-targets will not be used as we do not have any VRF or customer/tenant routing instance.
route-target import 64512:100101
route-target export 64512:100101
!
interface nve1
no shutdown
description Vtep-Vxlan
source-interface loopback1
host-reachability protocol bgp
member vni 100101
ingress-replication protocol bgp
!
Verification of control-plane and data-plane of VXLAN
Before going further, let's explain some behavioral patterns in Cisco NXOS VXLAN implementation which we have done.
- OSPF is enabled on global/default vrf and used for underlay routing (ECMP for loopback1 - nve interface). BGP-EVPN is enabled on global/default vrf and used for overlay routing (reachability for remote mac-addresses - end-hosts connected with another switch and BUM traffic forwarding between those end-hosts).
- BGP EVPN neighborship is established over loopback0. All the BGP routing updates will be send/received using loopback0.
- Loopback1 is dedicated for NVE interface only to create VXLAN tunnels (encapsulation and decapsulation of VXLAN packets). No BGP related configuration will be done using loopback1.
- BGP next-hop for all the EVPN routes will be loopback1 even though we have established EVPN neighborship over loopback0.
Now we can start our VXLAN verification which is based on BGP-EVPN control-plane -
Leaf-Sw-01# show interface nve 1
nve1 is up
admin state is up, Hardware: NVE
Description: Vtep-Vxlan
MTU 9216 bytes
Encapsulation VXLAN
Auto-mdix is turned off
RX
ucast: 2380 pkts, 224708 bytes - mcast: 88 pkts, 6512 bytes
TX
ucast: 2347 pkts, 338960 bytes - mcast: 0 pkts, 0 bytes
Leaf-Sw-01# show nve interface nve 1 detail
Interface: nve1, State: Up, encapsulation: VXLAN
VPC Capability: VPC-VIP-Only [not-notified]
Local Router MAC: 5000.0100.1b08
!!! VXLAN is operating in Control-Plane mode.
Host Learning Mode: Control-Plane
Source-Interface: loopback1 (primary: 10.81.1.1, secondary: 0.0.0.0)
Source Interface State: Up
Virtual RMAC Advertisement: No
NVE Flags:
Interface Handle: 0x49000001
Source Interface hold-down-time: 180
Source Interface hold-up-time: 30
Remaining hold-down time: 0 seconds
Virtual Router MAC: N/A
Interface state: nve-intf-add-complete
Fabric convergence time: 135 seconds
Fabric convergence time left: 0 seconds
Leaf-Sw-01# show nve peers control-plane
Interface Peer-IP State LearnType Uptime Router-Mac
--------- -------------------------------------- ----- --------- -------- -----------------
!!! nve-peer is learned over control-plane because of BGP-EVPN configuration.
nve1 10.81.1.2 Up CP 2d20h n/a
Leaf-Sw-01# show nve peers control-plane detail
Details of nve Peers:
----------------------------------------
Peer-Ip: 10.81.1.2
NVE Interface : nve1
Peer State : Up
Peer Uptime : 2d20h
Router-Mac : n/a
Peer First VNI : 100101
Time since Create : 2d20h
!!! Leaf-Sw-02 is tunneling VNI/VLAN - 100101/101 using VXLAN.
Configured VNIs : 100101
Provision State : peer-add-complete
Learnt CP VNIs : 100101
vni assignment mode : SYMMETRIC
Peer Location : N/A
Group policy capable: no
Leaf-Sw-01# show bgp l2vpn evpn summary
BGP summary information for VRF default, address family L2VPN EVPN
BGP router identifier 10.81.0.1, local AS number 64512
BGP table version is 1730, L2VPN EVPN config peers 1, capable peers 1
6 network entries and 6 paths using 1976 bytes of memory
BGP attribute entries [6/2208], BGP AS path entries [0/0]
BGP community entries [0/0], BGP clusterlist entries [0/0]
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.81.0.2 4 64512 17477 17187 1730 0 0 4d16h 2
!!! BGP-EVPN neighbor with Leaf-Sw-02 is established over loopback0 interface.
!!! Leaf-Sw-01 is iBGP neighbor and we have received type 2 and type 3 updates (1 of each).
Neighbor T AS Type-1 Type-2 Type-3 Type-4 Type-5
10.81.0.2 I 64512 0 1 1 0 0
Leaf-Sw-01# show bgp l2vpn evpn neighbors 10.81.0.2
!!! Leaf-Sw-01 and Leaf-Sw-02 has established iBGP neighborship.
!!! BGP-EVPN is enabled for global/default vrf.
!!! Switches are using loopback0 for BGP-EVPN communication.
BGP neighbor is 10.81.0.2, remote AS 64512, ibgp link, Peer index 3
Description: Leaf-Sw-02
BGP version 4, remote router ID 10.81.0.2
Neighbor previous state = OpenConfirm
BGP state = Established, up for 2d20h
Neighbor vrf: default
Using loopback0 as update source for this peer
Using iod 71 (loopback0) as update source
Enable logging neighbor events
Warning: Private AS will not be removed for this neighbor
Last read 00:00:31, hold time = 180, keepalive interval is 60 seconds
Last written 00:00:45, keepalive timer expiry due 00:00:14
Received 10527 messages, 1 notifications, 0 bytes in queue
Sent 10345 messages, 0 notifications, 0(0) bytes in queue
Neighbor capabilities:
Dynamic capability: advertised (mp, refresh, gr) received (mp, refresh, gr)
Dynamic capability (old): advertised received
Route refresh capability (new): advertised received
Route refresh capability (old): advertised received
4-Byte AS capability: advertised received
!!! BGP L2VPN EVPN address family enabled between the switches.
Address family L2VPN EVPN: advertised received
Graceful Restart capability: advertised received
For address family: L2VPN EVPN
BGP table version 1048, neighbor version 1048
!!! 2 EVPN prefixes accepted from Leaf-Sw-02 (type 2 and type3 - 1 of each).
2 accepted prefixes (2 paths), consuming 720 bytes of memory
0 received prefixes treated as withdrawn
!!! 2 EVPN prefixes sent to Leaf-Sw-02 (type 2 and type3 - 1 of each).
2 sent prefixes (2 paths)
!!! BGP standard and extended community is sent to Leaf-Sw-02.
!!! Route-Targets are advertised as extended BGP community.
Community attribute sent to this neighbor
Extended community attribute sent to this neighbor
Third-party Nexthop will not be computed.
Advertise GW IP is enabled
Last End-of-RIB received 00:00:01 after session start
Last End-of-RIB sent 00:00:01 after session start
First convergence 00:00:01 after session start with 2 routes sent
Before looking at the BGP routing table we need to explain - evpn route-type 2 and 3.
EVPN route-type 2
EVPN route-type 2 is used by a BGP EVPN router to inform it's neighbor about the end-hosts (servers etc.) directly connected to it (mac and ip address of the end-hosts). We can simply call it by - remote mac/ip address learning by a switch using BGP-EVPN. Below is the BGP-update packet capture when Leaf-Sw-02 has sent information about Pc-02's mac-address -
 |
| 02 - EVPN route-type 2 Wireshark EVPN route-type 3 EVPN route-type 3 - Inclusive Multicast Ethernet Tag (IMET) is used to populate a list of switches/vteps which are interested to receive BUM traffic for a specific vni. Below is a route-type 3 packet capture where Leaf-Sw-02 is informing Leaf-Sw-01 that it is interested in receiving BUM traffic for VLAN/VNI - 101/100101.  03 - EVPN route-type 3 Wireshark |
BGP-L2VPN-EVPN RIB
We will look at BGP-EVPN rib and look at what updates we have received from Leaf-Sw-02.
Leaf-Sw-01# show bgp l2vpn evpn
BGP routing table information for VRF default, address family L2VPN EVPN
BGP table version is 1934, Local Router ID is 10.81.0.1
Status: s-suppressed, x-deleted, S-stale, d-dampened, h-history, *-valid, >-best
Path type: i-internal, e-external, c-confed, l-local, a-aggregate, r-redist, I-injected
Origin codes: i - IGP, e - EGP, ? - incomplete, | - multipath, & - backup, 2 - best2
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 10.81.0.1:101 (L2VNI 100101)
*>i[2]:[0]:[0]:[48]:[5077.ae00.0500]:[0]:[0.0.0.0]/216
10.81.1.2 100 0 i
*>l[2]:[0]:[0]:[48]:[50c0.6a00.0400]:[0]:[0.0.0.0]/216
10.81.1.1 100 32768 i
*>l[3]:[0]:[32]:[10.81.1.1]/88
10.81.1.1 100 32768 i
*>i[3]:[0]:[32]:[10.81.1.2]/88
10.81.1.2 100 0 i
!!! BGP-EVPN updates received from Leaf-Sw-02.
Route Distinguisher: 10.81.0.2:101
!!! EVPN type-2 route for Pc-02's mac-address.
*>i[2]:[0]:[0]:[48]:[5077.ae00.0500]:[0]:[0.0.0.0]/216
10.81.1.2 100 0 i
!!! EVPN type-3 route for receiving BUM traffic for VLAN/VNI - 101/100101.
*>i[3]:[0]:[32]:[10.81.1.2]/88
10.81.1.2 100 0 i
We can inspect in detail how Leaf-Sw-02 sent type-2 update for Pc-02's mac address.
Leaf-Sw-01# show bgp l2vpn evpn 5077.ae00.0500
Route Distinguisher: 10.81.0.2:101
!!! Pc-02's mac-address - 5077.ae00.0500; type-2 update.
BGP routing table entry for [2]:[0]:[0]:[48]:[5077.ae00.0500]:[0]:[0.0.0.0]/216, version 1931
Paths: (1 available, best #1)
Flags: (0x000202) (high32 00000000) on xmit-list, is not in l2rib/evpn, is not in HW
Advertised path-id 1
Path type: internal, path is valid, is best path, no labeled nexthop
Imported to 1 destination(s)
Imported paths list: L2-100101
AS-Path: NONE, path sourced internal to AS
!!! BGP Update is sent by Leaf-Sw-02's loopback0 (10.81.0.2).
!!! Next-hop is Leaf-Sw-02's loopback1 (10.81.1.2).
10.81.1.2 (metric 41) from 10.81.0.2 (10.81.0.2)
Origin IGP, MED not set, localpref 100, weight 0
!!! VLAN 101 has VNI 100101.
Received label 100101
!!! RT is BGP-ASN:VNI-Id - 64512:100101
Extcommunity: RT:64512:100101 ENCAP:8
Path-id 1 not advertised to any peer
Let's inspect the EVPN route-type 3 update from Leaf-Sw-02 which shows for VLAN/VNI - 101/100101, it is interested to receive BUM traffic.
Leaf-Sw-01# show bgp l2vpn evpn route-type 3
BGP routing table information for VRF default, address family L2VPN EVPN
Route Distinguisher: 10.81.0.2:101
!!! Type-3 update to receive BUM traffic for VNI 100101.
BGP routing table entry for [3]:[0]:[32]:[10.81.1.2]/88, version 1055
Paths: (1 available, best #1)
Flags: (0x000002) (high32 00000000) on xmit-list, is not in l2rib/evpn, is not in HW
Advertised path-id 1
Path type: internal, path is valid, is best path, no labeled nexthop, is extd
Imported to 1 destination(s)
Imported paths list: L2-100101
AS-Path: NONE, path sourced internal to AS
!!! BGP Update is sent by Leaf-Sw-02's loopback0 (10.81.0.2).
!!! Next-hop is Leaf-Sw-02's loopback1 (10.81.1.2).
10.81.1.2 (metric 41) from 10.81.0.2 (10.81.0.2)
Origin IGP, MED not set, localpref 100, weight 0
!!! RT is BGP-ASN:VNI-Id - 64512:100101
Extcommunity: RT:64512:100101 ENCAP:8
PMSI Tunnel Attribute:
flags: 0x00, Tunnel type: Ingress Replication
!!! Interested to receive BUM traffic for VNI 100101.
Label: 100101, Tunnel Id: 10.81.1.2
Path-id 1 not advertised to any peer
We can also see the list of switches to which Leaf-Sw-01 will forward BUM traffic for VNI 100101.
Leaf-Sw-01# show nve vni ingress-replication
Interface VNI Replication List Source Up Time
--------- -------- ----------------- ------- -------
!!! VLAN 101 (VNI 100101) BUM traffic will be forwarded to Leaf-Sw-02 (10.81.1.2).
nve1 100101 10.81.1.2 BGP-IMET 1w1d
L2RIB (Layer 2 routing information base)
From the BGP-EVPN updates (type-2), the information will enter into the L2RIB.
Leaf-Sw-01# show l2route evpn mac evi 101
Flags -(Rmac):Router MAC (Stt):Static (L):Local (R):Remote
(Dup):Duplicate (Spl):Split (Rcv):Recv (AD):Auto-Delete (D):Del Pending
(S):Stale (C):Clear, (Ps):Peer Sync (Ro):Re-Originated (Nho):NH-Override
(Asy):Asymmetric (Gw):Gateway
(Bh):Blackhole, (Dum):Dummy, (Vpfn):VPC peer forwarding not ready
(Pf):Permanently-Frozen, (Orp): Orphan
(PipOrp): Directly connected Orphan to PIP based vPC BGW
(PipPeerOrp): Orphan connected to peer of PIP based vPC BGW
NH Flags- (Asy): Asymmetric VNI (RS): Remote Site Flag
(GU): Group Policy Unaware
Topology Mac Address Prod Flags Seq No Next-Hops
----------- -------------- ------ ------------------ ---------- -----------------------------
!!! Pc-02's mac-address (5077.ae00.0500) is learnt from Leaf-Sw-02 (10.81.1.2).
101 5077.ae00.0500 BGP Rcv 0 10.81.1.2 (Label: 100101)
!!! Pc-01's mac-address is learnt normally; as it is directly connected with E1/15.
101 50c0.6a00.0400 Local L, 0 Eth1/15
L2FM (Layer 2 Forwarding Manager)
L2FM is the routing table for layer-2. This is just another name for mac address-table of the switch.
Leaf-Sw-01# show mac address-table vlan 101
Legend:
* - primary entry, G - Gateway MAC, (R) - Routed MAC, O - Overlay MAC
age - seconds since last seen,+ - primary entry using vPC Peer-Link,
(T) - True, (F) - False, C - ControlPlane MAC, ~ - vsan,
(NA)- Not Applicable A - ESI Active Path, S - ESI Standby Path
TL - True Learned, PS - Peer Sync, RO - Re-originate
VLAN MAC Address Type age Secure NTFY Ports
---------+-----------------+--------+---------+------+----+------------------
!!! Pc-02's mac address (5077.ae00.0500) programmed into L2FM from L2RIB.
C 101 5077.ae00.0500 dynamic NA F F nve1(10.81.1.2)
* 101 50c0.6a00.0400 dynamic NA F F Eth1/15
Ping test from Pc-01 to Pc-02
Now it is time to do a ping test from Pc-01 to Pc-02 -
root@Pc-01:~# ping 10.85.101.12
PING 10.85.101.12 (10.85.101.12) 56(84) bytes of data.
64 bytes from 10.85.101.12: icmp_seq=1 ttl=64 time=3.05 ms
64 bytes from 10.85.101.12: icmp_seq=2 ttl=64 time=3.05 ms
64 bytes from 10.85.101.12: icmp_seq=3 ttl=64 time=3.01 ms
64 bytes from 10.85.101.12: icmp_seq=4 ttl=64 time=3.04 ms
--- 10.85.101.12 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
I will not do a ping packet walkthrough - for that kindly check Part 01 (it is exactly the same).
In this blog we have configured configured control-plane (BGP-EVPN) to make our VXLAN dynamic (remove static configuration). But our configuration is not scalable; if we have lots of switches. Stay tuned for Part 03 - where we will introduce Spine-Leaf topology for VXLAN to solve the scalability problem.
Comments
Post a Comment