Task TS01: H11(172.16.101.10) cannot ping H21(172.16.101.11)¶
Note
To get started, please select in lab manager option 04 to initialize lab devices. Please wait a minute after lab start for network convergence.
H11 node
1ts01-H11#ping 172.16.101.11
2Type escape sequence to abort.
3Sending 5, 100-byte ICMP Echos to 172.16.101.11, timeout is 2 seconds:
4.....
5Success rate is 0 percent (0/5)
6
7ts01-H11#show ip arp
8Protocol Address Age (min) Hardware Addr Type Interface
9Internet 172.16.101.1 3 aabb.cc80.0300 ARPA Ethernet0/0
10Internet 172.16.101.10 - 0000.0001.0101 ARPA Ethernet0/0
11Internet 172.16.101.11 0 Incomplete ARPA
We will start with the leaf to which the host is connected – Leaf1. In the host information we saw that ARP is incomplete. Lets check the same on Leaf1 and also look into the NVE peering.
Note
Note that VRF “green” is used on the Leaf1 node for L3VNI.
L1 node
1ts01-L1#show ip arp vrf green
2Protocol Address Age (min) Hardware Addr Type Interface
3Internet 10.1.254.3 - aabb.cc80.0300 ARPA Vlan901
4Internet 172.16.101.1 - aabb.cc80.0300 ARPA Vlan101
5Internet 172.16.101.10 1 0000.0001.0101 ARPA Vlan101
6Internet 172.16.102.10 2 0000.0001.0102 ARPA Vlan102
We won’t see ARPs for clients over remote VTEP
1ts01-L1#show nve peers
2'M' - MAC entry download flag 'A' - Adjacency download flag
3'4' - IPv4 flag '6' - IPv6 flag
4
5Interface VNI Type Peer-IP RMAC/Num_RTs eVNI state flags UP time
6nve1 50901 L3CP 10.1.254.4 aabb.cc80.0400 50901 UP A/M/4 00:03:48
7nve1 50901 L3CP 10.1.254.5 aabb.cc80.0500 50901 UP A/M/4 00:03:48
8nve1 10102 L2CP 10.1.254.4 4 10102 UP N/A 00:03:48
9nve1 10102 L2CP 10.1.254.5 4 10102 UP N/A 00:03:48
10nve1 10102 L2CP 10.1.254.6 2 10102 UP N/A 00:03:48
11nve1 10102 L2CP 10.1.254.7 2 10102 UP N/A 00:03:48
In the NVE peers table above that there are no entries that would be showing a peering over VNI 10101. Therefore, lets check the EVI for the vlan where we have H11 attached – vlan 101.
The EVI outputs show the vlan 101 is mapped to the L2 VNI 10110 but the VTEP IP is UNKNOWN.
1ts01-L1#show l2vpn evpn evi vlan 101
2EVI VLAN Ether Tag L2 VNI Multicast Pseudoport
3----- ----- ---------- --------- ------------- ------------------
4101 101 0 10110 UNKNOWN Et0/0:101
5 Et1/1:101
6
7ts01-L1#show l2vpn evpn evi vlan 101 detail
8EVPN instance: 101 (VLAN Based)
9RD: 10.1.255.3:101 (auto)
10Import-RTs: 65001:101
11Export-RTs: 65001:101
12Per-EVI Label: none
13State: Established
14Replication Type: Ingress (global)
15Encapsulation: vxlan
16IP Local Learn: Enabled (global)
17Adv. Def. Gateway: Enabled (global)
18Re-originate RT5: Disabled
19Adv. Multicast: Disabled (global)
20Vlan: 101
21 Ethernet-Tag: 0
22 State: Established
23 Flood Suppress: Attached
24 Core If:
25 Access If:
26 NVE If:
27 RMAC: 0000.0000.0000
28 Core Vlan: 0
29 L2 VNI: 10110
30 L3 VNI: 0
31 VTEP IP: UNKNOWN
32 Pseudoports:
33 Ethernet0/0 service instance 101
34 Routes: 1 MAC, 1 MAC/IP
35 Peers:
36 10.1.254.4
37 Routes: 2 MAC, 2 MAC/IP, 1 IMET, 0 EAD
38 10.1.254.5
39 Routes: 2 MAC, 2 MAC/IP, 1 IMET, 0 EAD
40 10.1.254.6
41 Routes: 1 MAC, 1 MAC/IP, 1 IMET, 0 EAD
42 10.1.254.7
43 Routes: 1 MAC, 2 MAC/IP, 1 IMET, 0 EAD
The MAC/IP information from BGP routes shows that the next show information is actually expecting 10101.
1ts01-L1#show l2route evpn mac ip
2EVI ETag Prod Mac Address Host IP Next Hop(s)
3----- ---------- ----- -------------- --------------- --------------------------
4101 0 L2VPN 0000.0001.0101 172.16.101.10 Et0/0:101
5101 0 BGP 0000.0002.0101 172.16.101.11 V:10101 10.1.254.4
6101 0 BGP 0000.0003.0101 172.16.101.12 V:10101 10.1.254.5
7101 0 BGP aabb.cc80.0400 172.16.101.1 V:10101 10.1.254.4
8101 0 BGP aabb.cc80.0500 172.16.101.1 V:10101 10.1.254.5
9101 0 BGP aabb.cc80.0600 172.16.101.1 V:10101 10.1.254.6
10101 0 BGP aabb.cc80.0700 172.16.101.1 V:10101 10.1.254.7
11<...skip...>
Do those 2 VNIs exist on the switch? Looks like 10110 does not exist – in the configuration of NVE we can find out which VNI is actually expected to be here.
1ts01-L1#show nve vni 10101
2Interface VNI Multicast-group VNI state Mode VLAN cfg vrf
3nve1 10101 N/A BD Down/Re L2CP N/A CLI N/A
4
5ts01-L1#show nve vni 10110
6Interface VNI Multicast-group VNI state Mode VLAN cfg vrf
7% VNI 10110 doesnt exist
8
9ts01-L1#show run int nve1
10interface nve1
11 no ip address
12 source-interface Loopback1
13 host-reachability protocol bgp
14 member vni 10101 ingress-replication
15 member vni 10102 mcast-group 225.0.1.102
16 member vni 50901 vrf green
17 end
18
19ts01-L1#show run vlan 101
20vlan configuration 101
21 member evpn-instance 101 vni 10110
We have identified that there is a mismatch in vlan-to-VNI mapping, as for vlan 101 L2VNI 10110 is used instead of the expected VNI 10101. Correct L2VNI is not configured on the switch.
Lets fix the configuration mistake on L1 node and reconfigure the NVE-VNI membership to retrigger the NVE peer learning for VNI 10101.
L1 node
1conf t
2no vlan configuration 101
3vlan configuration 101
4 member evpn-instance 101 vni 10101
5!
6int nve1
7 no member vni 10101 ingress-replication
8 member vni 10101 ingress-replication
Checking the NVE peers for that VNI afterwards, we see remote Leafs and connectivity start working.
L1 node
1ts01-L1#show nve peers vni 10101
2'M' - MAC entry download flag 'A' - Adjacency download flag
3'4' - IPv4 flag '6' - IPv6 flag
4
5Interface VNI Type Peer-IP RMAC/Num_RTs eVNI state flags UP time
6nve1 10101 L2CP 10.1.254.4 5 10101 UP N/A 00:00:23
7nve1 10101 L2CP 10.1.254.5 5 10101 UP N/A 00:00:23
8nve1 10101 L2CP 10.1.254.6 3 10101 UP N/A 00:00:23
9nve1 10101 L2CP 10.1.254.7 3 10101 UP N/A 00:00:23
H11 node
1ts01-H11#ping 172.16.101.11
2Type escape sequence to abort.
3Sending 5, 100-byte ICMP Echos to 172.16.101.11, timeout is 2 seconds:
4.!!!!
5Success rate is 80 percent (4/5), round-trip min/avg/max = 1/1/1 ms