Quite a while back I chatted with you on the phone about a problem we’ve been experiencing with our older BigIron 4000 switch. The symptoms are:
(a) a Linux-based client joins a multicast group/stream
(b) immediately the switch begins forwarding packets from that stream to the client’s port
(c) a very few (< 5 usually) seconds later, the switch stops forwarding that stream
(d) a seemingly random (from 3 to 40 seconds) time later, the switch resumes forwarding
An FES designed embedded system with no formal Operating System and a minimal IP stack that acts as a client to the same streams does not have this problem with the same switch.
Armed with a packet sniffer, we’ve gathered traffic info that correlates with the symptoms above:
(a) The Linux based application sends an IGMP v3 ‘exclude’ packet to join the stream
(b) immediately the switch begins forwarding packets.
(c) A short time later, the Linux TCP/IP stack sends another, identical IGMP v3 ‘exclude’ packet (this behavior seems to be described in the IGMP v2 RFC *). Immediately after that packet is sent, the switch stops forwarding the mcast packets to that client.
(d) Many seconds later, the switch sends an IGMP v3 membership query. The linux client responds and then the switch resumes forwarding mcast packets to it.
Looking at the Linux IGMP source code in ‘net/igmp.c’ reveals that its duplicate ‘exclude’ packet is sent intentionally. The FES designed embedded system that does not raise this drop-out issue sends only a single ‘exclude’ packet when joining.
So the question we’re facing: is this a Linux/stack issue or a switch/configuration issue? And of course, how can we resolve it?
* RFC 2236, the IGMPv2 spec, states:
"When a host joins a multicast group, it should immediately transmit
an unsolicited Membership Report for that group, in case it
is the first member of that group on the network. To cover the
possibility of the initial Membership Report being lost or damaged,
it is recommended that it be repeated once or twice after short
delays [Unsolicited Report Interval]."