Launching soon: The world's first vendor agnostic bug scrubLearn more & join waitlist
OPERATIONAL DEFECT DATABASE
...
...
Traffic blackholing may be observed in one or more VLANs extended over OTV when there's an overlapping MPLS label(s) in the MPLS VDC on the same chassis. The symptom may manifest itself after Cisco NX-OS upgrade from non-8.x (6.x or 7.x) release to 8.x.
All the listed conditions are required to suspect this limitation: - Nexus 7000 chassis with N7K-M224XP-23L (24-port 10GE) or N7K-M206FQ-23L (6-port 10/40GE) linecards - OTV VDC and MPLS VDC are on the same chassis - Cisco NX-OS 8.0(1) or later - OTVv1 encapsulation (MPLS/GRE). The OTV overlay utilizing OTVv2 (VXLAN) encapsulation (draft-hasmit-otv-04) is NOT affected by this limitation. - MPLS labels inside MPLS VDC matching the affected VLAN ID + 32 Note: in the field it was observed that only aggregate MPLS labels were an issue.
a). Configure 'mpls label range <lowest> <highest> ...' in the MPLS VDC to exclude all labels that can be potentially used for OTV VLAN transport (top of the range is 4094 + 32 = 4196) from dynamic allocation. For example: 'mpls label range 4127 1028093' Note: for the existing labels to be re-allocated within this range, the reload of the MPLS VDC is required. b). Downgrade to NX-OS 6.2(x) or 7.x c). Redistribute the ports of the M2 linecard between OTV and MPLS VDCs in such a way, that the single FE won't be shared between them. d). As a temporary workaround, the OTV VLAN translation on the overlay interface (into the "transit" VLAN ID) may be utilized. Note that as new MPLS labels are allocated inside the MPLS VDC, the overlap may occur again (now for the transit VLAN ID) and so, the issue.
The problem is observed on Nexus 7000 M2-series linecards, which allow to put ports on the single Forwarding Engine into different VDCs. If there's an MPLS VDC present on the same chassis as the OTV VDC, and there's an MPLS label overlapping with the one used in OTV VDC for VLAN extension, this limitation may come into play. The OTVv1 encapsulation uses MPLS label to encode the VLAN ID (with 802.1q header being stripped on the encap side). The VLAN ID is encoded as VLAN ID + 32. For example, if OTV VLAN 101 is affected, then MPLS VDC should have the label 101 + 32 = 133. The proxy indicator of this issue may be the lack of MAC address learning information on the downstream L2 switches attached to the internal interfaces of the OTV AED for the affected VLAN, and at the same time present MAC address learning information for this VLAN on the OTV AED itself. The reason is that the MAC learning in OTV is done via IS-IS Control-Plane, and the learning on the L2 switches below the AED is Data-Plane. This means that as long as ingress AED receives the traffic sourced from the (VLAN, MAC), it will redistribute the learned MAC into the IS-IS Control-Plane, so the egress AED will also have it. For the downstream L2 switches on decap side to have this (VLAN, MAC) learned, it should actually receive the actual data frame sourced from it, so if this traffic is blackholed somewhere upstream, this Data-Plane learning never happens.