Nexus 9396px: Issue with vxlan bridging of trunk native vlan
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.
Listen: https://smarturl.it/CCRS9E1 Follow us: https://twitter.com/ciscochampions
Join us for an informal discussion on why enterprise microservices architectures rely on open source service mesh, such as Istio, to secure, connect, obser...
From Vsphere Version 6.6 onwards Basic LACP is not supported, this post is to go through the steps required for the Enhanced LACP configuration when using VMM integration with ACI.
To configure Enhanced LACP please make su...
Listen: https://smarturl.it/CCRS8E50Follow us: https://twitter.com/ciscochampion Demystify your hybrid cloud network automation and operations. With its “one-view” presentation of all your hybrid cloud network sites, Cisco Nexus Dashboard enables IT opera...
※この はじめての Intersight Workload Optimizer / How To "Community" サイトで公開させていただいている情報は、Intersight Workload Optimizer に関わるナレッジを共有させて頂くことを目的としております。なるべく情報の正確性には努めてはおりますが、本 Community サイトで公開させて頂いている情報に基づいておこなわれた構成その他あらゆる設定に関してシスコとして一切の責任を持つことはできませんので、必ず公式なドキュメント、ガ...