Hello,
Unfortunately I don't have any TAC access but I strongly believe I'm hitting some bug here (hopefully I'm wrong and there could be an explanation to this) but let me explain....
We are now performing migration from our switched traffic to a EVPN VXLAN routed backbone (done through separate routerports as per all guidelines etc). This is being performed step by step (vlan by vlan) conforming with maintenance feasibility etc.
I had an issue when moving a VLAN which is a trunk native on a port over VXLAN bridging. For example we have:
switchport trunk allowed vlan 10,20,30,40
switchport trunk native vlan 10
All of those 4 VLANs are live services between the respective trunk port and another port-channel where they all arrive as trunks (assume, this port-channel is my former uplink interconnection which I'm now trying to decommission).
Yesterday morning I removed VLAN 10 (the native VLAN) from the uplink port-channel and bridged it over the VXLAN fabric so that I can migrate the traffic away from the switchport port-channel. As a consequence, the native VLAN worked as expected, however the other VLANs which still left over the switchport blackholed their traffic (i.e. they stopped registering dynamic mac address record on the switchport towards the host).
In this case, I think there's a bug when mac address (A) tries to communicate with mac address (B) in case when (A) must come from both the uplink switchport port-channel and the nve1 interface due to the bridging. Somehow I suspect the switch thinks this is a loop or something and discards some of the mac addresses for learning despite the fact that they are coming or about to get bridged in different VLANs. I think it's probable to have this scenario in my case because one of the sides is a router which responds with one and same mac address on all VLANs while the other side is a customer/host doing BGPs over different VLANs as well. Hence that's not really a loop however I suspect the switch thinks otherwise and discards some of the mac addresses in question because of this.
This only happens when a native vlan is present on the trunk switch port towards the host and we try to do vxlan bridging of a VNI to the native vlan. Does not occur in case the vlans are all trunk. I also had the same cases with native vlans three times in the past year but I couldn't recall it in time prior to doing the planned maintenance yesterday.
I'm not sure if anybody would have any ideas for resolving it but I think it's relatively easy to represent in lab.
Appreciate any ideas. Thank you.
