
Document ID: 116273
Updated: Jun 26, 2013
Contributed by Rahul Parameswaran, Cisco TAC Engineer.
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
Open a Support Case (Requires a Cisco Service Contract.)
Related Cisco Support Community Discussions
The Cisco Support Community is a forum for you to ask and answer questions, share suggestions, and collaborate with your peers.
Refer to Cisco Technical Tips Conventions for information on conventions used in this document.