In a previous post we talked about multicast and how to generate multicast using Ostinato. As we talked about in that post, to receive multicast traffic one has to explicitly request for it using IGMP (for IPv4) or MLD (for IPv6).
In this post we discuss the various IGMP messages and how to generate them using Ostinato.
MLD (the IPv6 equivalent of IGMP) is very similar and we will cover that in a future post. Till the time use this post as a guide and in case of any question, reach out to us via chat or support.
But first, let’s talk about the test topology.
Test Topology
You want to simulate a network with IGMP clients and multicast sources with a network under test (NUT). The network could consist of just a single switch or router also - in which case it becomes the device under test (DUT).
You can use a single Ostinato instance with 2 ports to emulate the two IGMP clients as shown below. If you want to emulate more IGMP clients you can use more ports on Ostinato or add additional Ostinato instances to your test topology.
You can also emulate upstream routers (IGMP queries) using Ostinato. You can even use the same Ostinato instance to emulate both the IGMP client and IGMP querier on different ports.
IGMP versions
The IGMP (Internet Group Management Protocol) has three different versions since inception. IGMPv1 was the first and oldest but is mostly not used these days.
IGMPv2 is popular and widely deployed and is typically the preferred choice for simple multicasting requirements.
IGMPv3 is also widely deployed especially in use cases where source-specific multicast (SSM) is a requirement.
Ostinato supports all 3 versions. This post will focus on IGMPv2 but generating IGMPv3 (or IGMPv1) is just a matter of selecting a different message type and filling in some extra fields for IGMPv3 - all of which should be obvious.
You can also use the free sendigmp tool (Windows only) to generate IGMP packets. Note that sendigmp does not support IGMPv3.
IGMP packet
To create an IGMP packet, add a new stream and select the protocols Mac | Ethernet | IPv4 | IGMP
On the Protocol Data | IPv4 tab, set the source IPv4 address appropriately, but keep the destination IP address unchanged for the moment - this will be different for different message types.
Set IP TTL to 1 and configure the Router Alert IP option.
You will need to enter IP options as a hex string. To configure Router Alert, enter 94040000 in the IP options field.
0x94IP option for Router Alert0x04Length of option0x0000Router shall examine packet
IGMPv2 report (aka join)
To generate a IGMP join select v2Report as the message type and enter a multicast IP address (224.0.0.0 to 239.255.255.255) as the group address that you want to receive multicast traffic for.
💡 The 224/8 range has several reserved addresses used by protocols such as OSPF etc. It might be easier to just skip the 224.x.x.x range so as to not use such a reserved address by mistake
Go back to the IPv4 fields and set the destination IP to be the same as the IGMP group address -
IGMPv2 leave
To generate an IGMP leave select v2Leave as the message type and enter the multicast group address that you want to leave.
IGMP leaves are sent to the all routers address, so go back to the IPv4 fields and set the destination IP to be 224.0.0.2 -
IGMPv2 query
Routers will periodically send out IGMP Query messages to find out who all are still listening to the multicast group traffic. All listeners are expected to reply to the query by sending an IGMPv2 report.
There are 2 types of query messages - general query or group-specific query.
The general query is sent periodically requesting the listeners to reply with v2report for each of the groups they are listening to (one v2report per group).
The group-specific query is typically sent when the router receives an IGMP leave message and wants to know if there are any more listeners for that particular group behind the port from which the leave message was received - note that there may be multiple listeners behind a port and a leave from one listener should not stop the traffic for other listeners; listeners receiving the group-specific query need to reply only to the specific group queried for.
If an IGMP querier (router sending the IGMP query) does not receive an IGMP v2Report in response to a query from a listener for a certain time duration (the Max Response Time value in the IGMP query message), it will prune its member list by removing the listener. The listener will no longer be sent the multicast traffic.
IGMPv2 General query
To generate an IGMP general query select v2Query as the message type, set Max Response time to 100 (this fields has a unit of 1/10 of a second, so a value of 100 is equal to 10 seconds - the RFC default), and leave the group address at the default 0.0.0.0.
IGMP leaves are sent to the all-systems address, so go back to the IPv4 fields and set the destination IP to 224.0.0.1 -
IGMPv2 Group-specific query
To generate an IGMP group-specific query select v2Query as the message type, set Max Response Time to 10 (1 second - RFC default), and enter the multicast group address that you want to query for.
IGMP-specific query are sent to the group address, so go back to the IPv4 fields and set the destination IP to be the same as the IGMP group address -
Periodic querying and replying
Routers typically send a general query every 125 seconds (default query interval). If you want to emulate such a periodic IGMP querier, you can set a stream rate of 0.008 packets/sec (0.008 = 1/125), set the Number of Packets to 1, and select Goto First.
No auto-responses
Ostinato only sends packets when you explicitly do a Start Transmit.
If the DUT sends an IGMP query, Ostinato will not reply to it and after some time the DUT may stop sending multicast traffic to your Ostinato test port acting as an IGMP client.
To prevent this from happening, set your IGMP join/report stream to send it in a loop - say at around 1 packet/sec. This will ensure that the DUT will not prune its multicast group member list.