In my previous post we looked at “SSM Source-Specific Multicast” deployment and how simple that configuration. To enable SSM, you require to configure IGMPv3 on all your network where multicast traffic need to flow. Since I had a opportunity to take packet captures during SSM testing, I thought to write a post about IGMPv3 using those captures. IGMP version 3 defines in RFC3376 (2002) and most of the details of this post directly come from that RFC.

There are two IGMPv3 message types described in the RFC
1. IGMPv3 Membership Query (0x11) – send by multicast router to query the multicast reception state of receivers
2. IGMPv3 Membership Report (0x22) – send by receivers to report current multicast reception state or change in state

For backward compatibility RFC suggested IGMPv3 implementation should support following IGMPv1 and IGMPv2 message types as well

3. IGMPv1 Membership Reports (0x12)
4. IGMPv2 Membership Report (0x16)
5. IGMPv2 Leave Group (0x17)

Any unknown message types of IGMP frames should be silently ignored by the network devices.

I have SPAN G1/0/12 interface traffic (you can download “mrn-igmpv3.pcapng” file from this link) when 192.168.129.221 host join the multicast stream. You can see host is sending IGMPv3 Membership Report to 224.0.0.22 (IGMPv3 link-local multicast address). Note that IGMP use IP Protocol number 2 and TTL value set to 1 (as IGMP messages only require to go to gateway of those receivers)

One difference in IGMPv3 membership Report is you can include many group records in single membership report (in my example only one group record listed though)

Membership Report message include Type (0x22), checksum, Number of Group Records, detail of each group record. Each group record details include, Record Type, Aux Data, Number of Source, Multicast Group Address and individual Source IP address. Record Type can be any of the following values

1. MODE_IS_INCLUDE – indicate that interface has a filter mode of include for the specified multicast address
2. MODE_IS_EXCLUDE – indicate that interface has a filter mode of exclude for the specified multicast address
3. CHANGE_TO_INCLUDE_MODE – indicate interface has changed to INCLUDE filter mode for specified multicast address
4. CHANGE_TO_EXCLUDE_MODE– indicate interface has changed to EXCLUDE filter mode for specified multicast address
5. ALLOW_NEW_SOURCES – indicate list of src that receiver wishes to hear from
6. BLOCK_OLD_SOURCES – indicate list of src that receiver is no longer wishes to hear from

First 2 methods are used in “Current-State Record” in response to a Query received on an interface. It reports the current reception state with respect to a single multicast address.

Number 3 & 4 are part of “Filter-Mode-Change Record” send by a system whenever it needs change of the filter mode (INCLUDE to EXCLUDE or EXCLUDE to INCLUDE). This is used to articulate IGMPv3 leave messages without having special message type for that.

Number 5 & 6 methods are part of “Source-List-Change Record“, which is sent by a system when it needs change of source list that is not coincident with change of filter mode.

In our case, you can see Record Type 5 (ALLOW_NEW_SOURCE) being used indicating receiver is interested to hear multicast traffic for 232.100.100.100 group from 192.168.224.100 source IP address.

Once receiver send the IGMPv3 membership report, SW1 forwarded to upstream router as PIM join message and then it will forward that to SW2 where Multicast traffic receiving from the source 192.168.224.100 that was requested by receiver. So you will see multicast traffic flow from that point onward. We set TTL value to 10 at the Source and value decrement to 7 when it comes to VL129 segment as it passes through 3 hops.

Now let’s see what happen when I exit from multicast application in the receiver. Here is the filtered output for IGMP traffic in that capture.

There are 3 type of Query messages

1. General Query – to learn complete multicast reception state of the neighboring interface (Group Address & Number of Sources fields contain 0). Send to destination address 224.0.0.1 (all-systems multicast address)
2. Group-Specific Query – to learn the reception state, with respect to single multicast group address (Number of Sources field contain 0). Send to destination multicast address of interest.
3. Group-and-Source-Specific Query – to learn about any neighboring interface desires reception of multicast packets sent to specific group address from any of specified list of sources.

You can see “Group-Specific Query” and “Group-and-Source-Specific Query” messages in this example. Below shows the “Group-Specific Query” msg detail. Note that Query msg include “Max Resp Code or Max Resp Time” where router is giving a max time to a receiver to respond (membership report msg field set to 0). In this example router is waiting only 1s (unit is 1/10s and hex value is 0x0a =decimal 10) after sending query msg. Group address is set to 232.100.100.100 which is the group router want to query. (In “General Query” multicast group address is set to 0.0.0.0 and destined to all-systems link local address 224.0.0.1)

There is “S” Flag when set to “1” indicate to any receiving multicast routers that they are to suppress the normal timer updates that they perform upon hearing a Query. QRV (Query Robustness Variable) used by quarrier to adjust the query frequency depend on the quality of the network. QQIC (Quarrier’s Query Interval Code) specified the query interval (60s in our case indicating every 1s interval router should send a query, frame#13137 and frame#14027 are subsequent “Group-Specific Queries“.

Below table compare different IGMP versions and see whether you remember those key differences

If you would like to learn more about this topic I would suggest following materials.

1. Fundamentals of IP Multicast by Beau Williamson
2. Protocol Deep Dive – IGMP & MLD by Nick Russo