Catalyst VXLAN-EVPN question

[kim]

Hey guys,

thank you for an awesome resource!

I am referencing this config guide:
https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9500/software/release/17-6/configuration_guide/vxlan/b_176_bgp_evpn_vxlan_9500_cg/configuring_multi_homing_in_bgp_evpn_vxlan_fabric.html#id_114279

My setup is 4 vteps (C9300), paired up to simulate two sites. They are configured just for L2, ingress-replication, and anycast gateways with mac aliasing. In my setup i am dualhoming to a vtep pair from a single switch, this in each end of the setup. I am running mstp to announce and receive mac table flushes. This works fine, failover happens almost instantaneously since the vteps announce their taking over with a mac flush tcn. I see the same behavior when the primary link comes back up again - mstp announces the mac flush and we are back in business.

The thing i can't figure out is how a non-networking device would know how to move back to the primary connection with the switches. There is no link state to listen for and i don't see anything in my captures apart from the mst packets.
What i mean is, that - when initially link 1 fails - the server (as an example) learns to use link 2 towards secondary vtep because of the link failure. If this server does not speak mstp how can it unlearn that outbound interface and go back to using link 1 again?

I am hoping you guys can shed some light - thanks

Cheers

[MHM Cisco World]

I check and see what you confuse about

The server with dual homed connect to two vtep is failover to backup linke 

Now vtep what it do? As I know it shut down vlan (include it vni) and hence all traffic shift to other vtep

This what you confuse about?

[kim]

Hey   Thanks for replying.

So:
Step 1. primary link fails - vtep 2 takes over and secondary link from server is in use. The server has now learned that link 2 is outbound interface for its own traffic to the (in this test case) gateway interface.

Step 2. the primary link is fixed and comes back up. Secondary vtep goes into single-active blocked state and primary vtep takes back over by announcing the mac flush tcn.

Now the server does not speak (that i know of) mstp and does not understand that tcn notification from the primary vtep. So in theory, it is still forwarding traffic out of the link towards vtep two - effectively blackhole'ing traffic.

That is at least how my test switch behaves when i turn off stp. I do this knowing that most likely the server behaves differently. But i dont have a server to test with sadly. 

EDIT: (to my first message) - by configuring vrrp with the same vip as the svi gateway address on both vteps, the server (my switch with stp turned off) can now learn about the new outbound interface. The thing is however that the guide mentions nothing about this as a part of it - on the contrary, with anycast gateways i would expect to not have to do this. But i dont see any gratuitous arp from the gateway without vrrp configured.

[balaji.bandi]

The thing i can't figure out is how a non-networking device would know how to move back to the primary connection with the switches

what kind of device is this, VM ? or give us some example ?

[kim]

Hey Any non-networking device, erm. a SAN maybe. In all honesty thats why i am asking, to hear if someone out there has any experience in the non-networking domain with single active setups like this.

Cheers