IGMPv3 Joining w/o replying to query

Hi all,
in my configuration is a switch with is acting as MC Querier (IGMP snooping enabled too). Attached is a Ethernet recorder, which is by default a passive listener to the network traffic. As we want also the MC traffic to be recorded, we’re able to set up the recorder to send out a free defined message periodically. I build up an IGMPv3 Report Message manually and wireshark recognize it as a valid IGMPv3 Report message.
The questions are:
Do the switch add this “host” to its MC routing table? (because the recorder isn’t responding to quries)
What is the correct Group Record Type for that message? Because compared to IGMPv2 I don’t find that typicall “Join” and “Leave” Types here in v3.

Thanks a lot

Best regards, Florian

A post was merged into an existing topic: IGMP Version 3

Hi Florian,

I think you will be fine, if you send a valid periodic membership report then the switch should add the interface where it receives the report on as an outgoing interface for multicast.

About the Group Record Type, take a look at this capture:

https://www.cloudshark.org/captures/296ec7dbf3f6

The first packet is the initial membership report, triggered by the ip igmp join-group command on a route. The Group Record Type is “Allow New Sources”.

The second packet is the periodic membership report. The Group Record Type is “Mode is Include”.

Let’s check the RFC to see what the difference is:

5 ALLOW_NEW_SOURCES - indicates that the Source Address [i]
fields in this Group Record contain a list of the
additional sources that the system wishes to
hear from, for packets sent to the specified
multicast address. If the change was to an INCLUDE
source list, these are the addresses that were added
to the list; if the change was to an EXCLUDE source
list, these are the addresses that were deleted from
the list.

1 MODE_IS_INCLUDE - indicates that the interface has a filter
mode of INCLUDE for the specified multicast address.
The Source Address [i] fields in this Group Record
contain the interface’s source list for the
specified multicast address, if it is non-empty.

Now the question is how the switch responds to these messages. I think I would just try to send a crafted packet that is similar to packet 2, I think it’s enough for the switch to act upon it.

Rene

1 Like