Nexus 7000 Multicast Failure with the ip igmp join-group Command

Introduction

This document describes a problem encountered when the ip igmp join-group command is used in order to force Cisco Nexus 7000 Series switches to join the multicast group. A solution to the problem is provided also.

Problem

The ip igmp join-group command is used in order to force the Nexus 7000 Series switch to join the multicast group. The switch generates an Internet Group Management Protocol (IGMP)-join for the specified group, and any multicast packets destined to the group are sent to the CPU.

With Nexus Operating Systems earlier than Release 5.2, if there are receivers connected to the Nexus 7000 Series switch that request for the group, then a copy of the packet is also sent to the receiver. In Release 5.2 and later, due to a software bug with the Locator/ID Separation Protocol (LISP), the switch does not program any Outgoing Interface Lists (OILs) in the hardware. Even if there are receivers that request for the stream, no packets are sent to them.

If you check the Multicast Routing Table, you can see the OIL programmed Command Output:

(*, 239.1.1.1/32), uptime: 00:00:05, igmp pim ip
  Incoming interface: Null, RPF nbr: 0.0.0.0
  Outgoing interface list: (count: 1)
    Vlan48, uptime: 00:00:05, igmp

However, when you inspect the programmed values for the internal hardware, you see that no OILs are programmed:

show forwarding multicast route group 239.1.1.1
slot  3
=======
  (*, 239.1.1.1/32), RPF Interface: NULL, flags: GPr
    Received Packets: 0 Bytes: 0
    Number of Outgoing Interfaces: 0
    Null Outgoing Interface List

Solution

The ip igmp join-group command is not intendend for use in production. It is used in order to troubleshoot where there is a need to generate an IGMP-join and no receivers are available. Use the ip igmp static-oif command instead.

If LISP is not active on the switch, you can enter the ip routing multicast enforce-rpf command in order to force the ip igmp join-group command to operate the same way that it used to with Nexus Operating Systems earlier than Release 5.2, which means the OIL is programmed. With the workaround in place, you can see that the OIL is programmed in the hardware:

show forwarding multicast route group 239.1.1.1
slot  3
=======
  (*, 239.1.1.1/32), RPF Interface: NULL, flags: GP
    Received Packets: 0 Bytes: 0
    Number of Outgoing Interfaces: 1
    Outgoing Interface List Index: 2
      Vlan48 Outgoing Packets:0 Bytes:0