Posted on September 18, 2019 2:30 pm
 |  Asked by JEAN-CLAUDE RIOPEL
 |  66 views
0
0
Print Friendly, PDF & Email

Hi,

I am wondering if anyone else notices odd behavior with vEOS and EVPN. Basically connectivity between 2 nodes on VNI 1300, with node-a on leaf 1/2 and node-b on leaf 3/4. Arp tables are good, EVPN tables are good (on both leaf pairs and spines), with type-2 routes evident everywhere. The issue appears to be EVPN between leaf pairs working whenever it feels like it. Out of about 100000 pings 1 worked :). I understand this is “v”EOS so just wondering if this has been identified in the Arista labs, and will be fixed in later versions. I have tried 4.19…. and 4.21…. all the same.

!-leaf 2 arp
Address Age (min) Hardware Addr Interface
10.239.53.140 N/A 0050.7966.680b Vlan300, Ethernet4
10.239.53.141 N/A 0050.7966.680c Vlan300, Vxlan1
!-end leaf 2 arp

!-leaf 2 type-2
Network Next Hop Metric LocPref Weight Path
Route Distinguisher: 10.239.54.4:8000
* > mac-ip 1300 0050.7966.680b
10.239.54.33 – – 0 i
Route Distinguisher: 10.239.54.5:8000
* >Ec mac-ip 1300 0050.7966.680c
10.239.54.34 – 100 0 65000 65002 i
* ec mac-ip 1300 0050.7966.680c
10.239.54.34 – 100 0 65000 65002 i
Route Distinguisher: 10.239.54.6:8000
* >Ec mac-ip 1300 0050.7966.680c
10.239.54.34 – 100 0 65000 65002 i
* ec mac-ip 1300 0050.7966.680c
10.239.54.34 – 100 0 65000 65002 i
!-end leaf 2

!-leaf 4 type-2
Network Next Hop Metric LocPref Weight Path
Route Distinguisher: 10.239.54.3:8000
* >Ec mac-ip 1300 0050.7966.680b
10.239.54.33 – 100 0 65000 65001 i
* ec mac-ip 1300 0050.7966.680b
10.239.54.33 – 100 0 65000 65001 i
Route Distinguisher: 10.239.54.4:8000
* >Ec mac-ip 1300 0050.7966.680b
10.239.54.33 – 100 0 65000 65001 i
* ec mac-ip 1300 0050.7966.680b
10.239.54.33 – 100 0 65000 65001 i
Route Distinguisher: 10.239.54.6:8000
* > mac-ip 1300 0050.7966.680c
10.239.54.34 – – 0 i
!-end leaf 4

0
Posted by Aniket Bhowmick
Answered on September 19, 2019 6:14 am

Hi Jean,

Can you share the configuration of SVI300 ? I believe you are using “ip address virtual” and you are pinging from the switch itself ?

If that is the case, then when you ping the host, Source-IP will get NAT’ed. It doesn’t source with Virtual IP as the virtual IP will exist in other leaf pairs as well and the ICMP reply may never be received on the switch which originated the ICMP request.

So in that case, the end host must have route to reach the NAT’ed IP. If you want you can specify a source IP as well (for which you know the end host has a route to reach that IP), but make sure the source IP is not a virtual IP because it will get NAT’ed.

NAT’ed IP usually takes the highest loopback IP in that vrf (where SVI300 is present) and it can take the Vxlan loopback IP as well. In that situation, when end host will send the ICMP reply (destined to Vxlan loopback IP), there is a chance that the ICMP reply ends up reaching the other MLAG device due to ECMP route from Spine (route would point to both MLAG device). Vxlan loopback IPs are same in a MLAG pair and both device advertise their route to the spine.

A better way to test connectivity (which Arista also recommends) is to do the ping end to end (between two end hosts) rather than pinging from the switch.

Thanks,
Aniket

Post your Answer

You must be logged in to post an answer.