Nexus 7000 IPv6 Configuration Pitfalls

/ Blog, IPv6, IPv6 in the Industry, Routing and Switching

I have recently started working in a datacenter configuring quite a few Nexus 7000 series switches to act mainly as datacenter access switches – mainly making use of the popular features of Virtual Device Contexts (VDCs) and Virtual Port-Channels (vPCs).  Well, IPv6 is a key part of the network environment.

So for the last week, I discovered that IPv6 was not working across a few standard layer-2 untagged VLAN access ports – even thought IPv4 had no issues.  It took a Cisco TAC Case and a very nice engineer from Cisco to discover why.

Read the %^&*$# Manual

My environment consisted of a router-on-a-stick approach to layer 3 routed interfaces.  This is mainly due to High Availability (HA) considerations.  In this most recent example, I had two firewalls connected directly (logically through two access ports) and was using the Nexus 7000 switch to act as a go-between.  Meaning, in order to ensure $FAILOVER technology can function, there needs to be some layer 2 connectivity to each other.  So one firewall connects to one 10 GE interface and the other connects to another 10 GE interface on the same layer-2 VLAN like this:

interface e1/1
 description 1st Firewall Link
 switchport
 switchport access vlan 10

interface e1/2
 description 2nd Firewall Link
 switchport
 switchport access vlan 10

After much troubleshooting, and discovering this setup works just fine with IPv4, the great engineers at Cisco TAC informed me that a default configuration on Nexus 7000 switches with Fabric 2 Modules have the following issues with IPv6 (from Cisco):

Guidelines and Limitations for IPv6

IPv6 has the following configuration guidelines and limitations:

  • IPv6 packets are transparent to Layer 2 LAN switches because the switches do not examine Layer 3 packet information before forwarding IPv6 frames. IPv6 hosts can be directly attached to Layer 2 LAN switches.
  • You can configure multiple IPv6 global addresses within the same prefix on an interface. However, multiple IPv6 link-local addresses on an interface are not supported.
  • Because RFC 3879 deprecates the use of site-local addresses, you should configure private IPv6 addresses according to the recommendations of unique local addressing (ULA) in RFC 4193.
  • F2 Series modules do not support IPv6 tunnels.
  • On F2 Series modules, you must disable IGMP optimized multicast flooding (OMF) on any VLANs that require any IPv6 packet forwarding (unicast or multicast). IPv6 neighbor discovery functions correctly only in a VLAN with the OMF feature disabled. To disable OMF, use the no ip igmp snooping optimised-multicast-flood command in VLAN configuration mode. With OMF disabled, unknown IPv4 multicast traffic (as well as all IPv6 multicast traffic) is flooded to all ports in the VLAN. Note that unknown multicast traffic refers to multicast packets with an active source but no receivers (and therefore no group forwarding entry in the hardware) in the ingress VLAN.

Yeah, that last one got me.  Apparently, Cisco is trying to “help” me by taking multicast snooping to an all new level – killing any IPv6 communication.  Why this is important is because IPv6 Neighbor Discovery (think ARP for IPv4) goes over multicast.  So what I imagine the snooping is doing on F2 Modules is drop all Ethernet frames with the the destination MAC of 33-33-xx-xx-xx-xx.  The “XX” map to the IPv6 multicast group the frame is trying to reach.  For example, the all-nodes multicast address is ff02::1 the Ethernet MAC maps to 33:33:00:00:00:01.

So by disabling Cisco’s “optimized” multicast flood protection, you get IPv6 to work on a layer-2 interface.  The command should be done on the VDC you are working in.  You have to make sure you think in the Queen’s English for this one:

  • no ip igmp snooping optimised-multicast-flood
Scroll to Top