IGMP Version 2

IGMP Version 2 was developed as a solution for the first version's weaknesses. One of which was the inability to detect if there are still hosts which are still members of a multicast group. It will take 3 minutes before the router knows that there are no more members in version 1. The enhancements in Version 2 is shown below.

Group-Specific Query messages – enables the router to do a query operation on specific multicast groups

Leave Group messages – hosts sends a Leave message to the router that they are leaving the multicast group.

Querier election process – can elect the router that will do that query without relying on multicast routing protocols.

Maximum Response Time field - permits the Query Router to specify the maximum Query-Response time. This field
permits the tuning of the Query-Response process to control response burstiness and to fine-tune leave latencies.

The first 2 enhancements above, really helps in saving bandwidth. What happens is, if a host leaves the multicast group, it sends a Leave message. When the router receives this Leave message, it will send out a Group Specific query to that group of which the Leave message indicated and within 10 secs (default) if no host replies a Membership Report the router removes the entry in its IGMP membership table. The router doesn't have to wait 3 minutes like in Version 1.

Below is the Message types.

IGMP Version 2 Message Types

Membership Query (Type code = 0x11)

Two Subtypes:
       General Query – operates the same way like in the
       Group-Specific Query - enables the router to do a query operation on specific multicast groups.

Version 1 Membership Report (Type code = 0x12) - This is for backwards compatibility with version 1.

Version 2 Membership Report (Type code = 0x16)

Leave Group (Type code = 0x17)

Now let’s try this in the lab. I have set up the lab like before using Ubuntu and MINT. To start off, let's configure the router the same way in the IGMP Version 1 post. The command "ip multicast-routing" should be configured under global config mode. Commands "ip igmp version 2" and "ip pim sparse-dense-mode" should be configured on the FastEthernet interface. Let’s see the screenshots on Wireshark. Firstly I have generated the traffic in MINT for the Ubuntu VM to join multicast group 239.10.10.10 port 4321.


The screenshot above shows the Membership report which has a Type code of 0x16. Since in the lab that I made, there are no valid multicast sources, the host immediately sends a Leave message.

We see that the host sends the leave message to a multicast group 224.0.0.2 which means “all routers” in the local subnet. Its clear that they Type code is 0x17. Right below the Leave group message, immediately the router sends a Group Specific Query to check if there are still hosts who are still members on the same multicast group. Also it sends a General Query. Check the screenshots below to spot the difference.


Group Specific Query


General Query


The similarities between both is the Type Code which is 0x11. General Queries send it out to a well known multicast group 224.0.0.1 which is all hosts in the segment. Group Specific queries shows that it sends to the group address. In the Multicast address field, General Queries will have 0.0.0.0 which Group Specific will have the group address.

Finally let’s see the router debug output.

Router>
*Nov 18 15:41:32.759: IGMP(0): Received v2 Report on FastEthernet0/0 from 192.168.59.128 for 239.10.10.10
*Nov 18 15:41:32.759: IGMP(0): Received Group record for group 239.10.10.10, mode 2 from 192.168.59.128 for 0 sources
*Nov 18 15:41:32.763: IGMP(0): WAVL Insert group: 239.10.10.10 interface: FastEthernet0/0Successful
*Nov 18 15:41:32.763: IGMP(0): Switching to EXCLUDE mode for 239.10.10.10 on FastEthernet0/0
*Nov 18 15:41:32.763: IGMP(0): Updating EXCLUDE group timer for 239.10.10.10
*Nov 18 15:41:32.767: IGMP(0): MRT Add/Update FastEthernet0/0 for (*,239.10.10.10) by 0
*Nov 18 15:41:33.975: IGMP(0): Received Leave from 192.168.59.128 (FastEthernet0/0) for 239.10.10.10
*Nov 18 15:41:33.975: IGMP(0): Received Group record for group 239.10.10.10, mode 3 from 192.168.59.128 for 0 sources
*Nov 18 15:41:33.979: IGMP(0): Lower expiration timer to 2000 msec for 239.10.10.10 on FastEthernet0/0
*Nov 18 15:41:33.979: IGMP(0): Send v2 Query on FastEthernet0/0 for group 239.10.10.10
*Nov 18 15:41:34.979: IGMP(0): Send v2 Query on FastEthernet0/0 for group 239.10.10.10
*Nov 18 15:41:35.979: IGMP(0): Switching to INCLUDE mode for 239.10.10.10 on FastEthernet0/0
*Nov 18 15:41:35.979: IGMP(0): MRT delete FastEthernet0/0 for (*,239.10.10.10) by 0

Why did the router send 2 Group Specific Queries on the debug above? The router in this case used a “Last Member Query Interval” in the range of 10 -1 second in between the Group Specific queries. What it did in our case, was to send on Group Specific query and wait for 1 second and then sends another so by the 2nd time it sent the queries and there is no reply, we see now that it did remove the group from its MRT as the last line of the debug indicated. It should take around 3 seconds as shown above for the router to stop sending traffic for a group if there are no more members. Should there were other hosts in the same multicast group 239.10.10.10 the router will continue forwarding traffic.

IGMP Version 1

This protocol's version might be old but its very important how to learn the differences between IGMP V1, V2 and V3. It's important to start learning about how the protocol evolved into what it is now. Learning IGMP V1 will give us a foundational knowledge of what IGMP does and how it functions.

What is IGMP?

IGMP is used for hosts who wish to join a multicast address/group, to inform their nearest 
multicast router on which group they wish to be a member of.

Used by routers to maintain a table of multicast group membership per interface. Multicast 
group membership is active on an interface, if the router receives a Membership 
Report from that interface.

It is only needed on IPV4 networks as IPV6 has a different way to handle multicast.

In this entry, I will focus on how the router forms the multicast membership table and what are the most commonly used multicast addresses used to discover multicast members. I will also do some debugs to check how IGMP Version 1 removes a multicast address from the IGMP membership table. The simple diagram is shown below, instructions on how I set up MINT, Wireshark and Ubuntu can be found on the previous blog entry.

Scenario: Ubuntu VM wishes to receive multicast traffic from 239.10.10.10, 239.20.20.20 and 
239.30.30.30. Observe through Wireshark and debug commands how IGMP Version 1 works.

First thing is to configure the router to make multicast work.

R0(config)#ip multicast-routing
R0(config)#int fa0/0
R0(config-if)#ip pim sparse-dense-mode
R0(config-if)#ip igmp version 1

Router#sh ip igmp interface
FastEthernet0/0 is up, line protocol is up
 Internet address is 192.168.18.10/24
 IGMP is enabled on interface
  Current IGMP host version is 1
  Current IGMP router version is 1
 IGMP query interval is 60 seconds
 Inbound IGMP access group is not set
 IGMP activity: 6 joins, 4 leaves
 Multicast routing is enabled on interface
 Multicast TTL threshold is 0
 Multicast designated router (DR) is 192.168.18.10 (this system)
 IGMP querying router is 192.168.18.10 (this system)
 Multicast groups joined by this system (number of users):
     224.0.1.40(1)

These commands are needed to make multicast operate on the router. PIM sparse-dense mode will be discussed on the other entries. I doubt if any aspiring CCIE candidates who already took their CCNP will know nothing about PIM.:)

Then, Wireshark should already be ready to sniff packets on the VMware interface towards Ubuntu VM. From Ubuntu VM Terminal, generate the commands below for the virtual machine to receive traffic for multicast groups 239.10.10.10, 239.20.20.20 and 239.30.30.30. There are no real multicast sources though so don't expect a continous multicast traffic flow. This commands on MINT will only send Membership Report to the router informing that this host is interested joining these 3 multicast groups.

pete@pete-desktop:~/mint-1.2$ mint -r 239.10.10.10 -p 4321
pete@pete-desktop:~/mint-1.2$ mint -r 239.20.20.20 -p 4321
pete@pete-desktop:~/mint-1.2$ mint -r 239.20.20.20 -p 4321

I filtered the output on Wireshark to only show igmp packets and the first 3 outputs are shown below in the red box. My Ubuntu VM's ip address is 192.168.18.129. Click on the picture below to enlarge...


We can see the lines numbered 2, 4 and 7 with the red box that the Info part specifies a V1 Membership Report. Let's see how the router sees the debug.

*Oct 30 13:39:35.783: IGMP(0): Received v1 Report on FastEthernet0/0 from 192.168.18.129 for 239.10.10.10
*Oct 30 13:39:35.783: IGMP(0): Received Group record for group 239.10.10.10, mode 2 from 192.168.18.129 for 0 sources
*Oct 30 13:39:35.787: IGMP(0): WAVL Insert group: 239.10.10.10 interface: FastEthernet0/0Successful
*Oct 30 13:39:35.787: IGMP(0): Switching to EXCLUDE mode for 239.10.10.10 on FastEthernet0/0
*Oct 30 13:39:35.787: IGMP(0): Updating EXCLUDE group timer for 239.10.10.10
*Oct 30 13:39:35.791: IGMP(0): MRT Add/Update FastEthernet0/0 for (*,239.10.10.10) by 0
*Oct 30 13:39:41.083: IGMP(0): Received v1 Report on FastEthernet0/0 from 192.168.18.129 for 239.20.20.20
*Oct 30 13:39:41.087: IGMP(0): Received Group record for group 239.20.20.20, mode 2 from 192.168.18.129 for 0 sources
*Oct 30 13:39:41.087: IGMP(0): WAVL Insert group: 239.20.20.20 interface: FastEthernet0/0Successful
*Oct 30 13:39:41.087: IGMP(0): Switching to EXCLUDE mode for 239.20.20.20 on FastEthernet0/0
*Oct 30 13:39:41.091: IGMP(0): Updating EXCLUDE group timer for 239.20.20.20
*Oct 30 13:39:41.091: IGMP(0): MRT Add/Update FastEthernet0/0 for (*,239.20.20.20) by 0
*Oct 30 13:39:42.275: IGMP(0): Received v1 Report on FastEthernet0/0 from 192.168.18.129 for 239.20.20.20
*Oct 30 13:39:42.275: IGMP(0): Received Group record for group 239.20.20.20, mode 2 from 192.168.18.129 for 0 sources
*Oct 30 13:39:42.279: IGMP(0): Updating EXCLUDE group timer for 239.20.20.20
*Oct 30 13:39:42.279: IGMP(0): MRT Add/Update FastEthernet0/0 for (*,239.20.20.20) by 0
*Oct 30 13:39:44.651: IGMP(0): Received v1 Report on FastEthernet0/0 from 192.168.18.129 for 239.30.30.30
*Oct 30 13:39:44.651: IGMP(0): Received Group record for group 239.30.30.30, mode 2 from 192.168.18.129 for 0 sources
*Oct 30 13:39:44.655: IGMP(0): WAVL Insert group: 239.30.30.30 interface: FastEthernet0/0Successful
*Oct 30 13:39:44.655: IGMP(0): Switching to EXCLUDE mode for 239.30.30.30 on FastEthernet0/0
*Oct 30 13:39:44.655: IGMP(0): Updating EXCLUDE group timer for 239.30.30.30
*Oct 30 13:39:44.655: IGMP(0): MRT Add/Update FastEthernet0/0 for (*,239.30.30.30) by 0

We can see there the statements "MRT Add/Update FastEthernet0/0" which means it mapped the specific multicast address to the MRT (multicast routing table) for a specific interface. This will be also added to the IGMP membership. Lets check the MROUTE and IGMP memberships.

Router#sh ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
     L - Local, P - Pruned, R - RP-bit set, F - Register flag,
     T - SPT-bit set, J - Join SPT, M - MSDP created entry,
     X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
     U - URD, I - Received Source Specific Host Report,
     Z - Multicast Tunnel, z - MDT-data group sender,
     Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 239.255.255.250), 00:00:44/00:02:15, RP 0.0.0.0, flags: DC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
  FastEthernet0/0, Forward/Sparse-Dense, 00:00:44/00:00:00

(*, 239.10.10.10), 00:00:08/00:02:51, RP 0.0.0.0, flags: DC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
  FastEthernet0/0, Forward/Sparse-Dense, 00:00:08/00:00:00 ######### Added to MRT

(*, 224.0.1.40), 00:00:49/00:02:52, RP 0.0.0.0, flags: DCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
  FastEthernet0/0, Forward/Sparse-Dense, 00:00:49/00:00:00

Router#sh ip igmp member
Flags: A  - aggregate, T - tracked
  L  - Local, S - static, V - virtual, R - Reported through v3
  I - v3lite, U - Urd, M - SSM (S,G) channel
  1,2,3 - The version of IGMP the group is in
Channel/Group-Flags:
  / - Filtering entry (Exclude mode (S,G), Include mode (*,G))
Reporter:
   - last reporter if group is not explicitly tracked
/      -  reporter in include mode,  reporter in exclude

Channel/Group                  Reporter        Uptime   Exp.  Flags  Interface
*,239.255.255.250              192.168.18.1    00:03:32 02:59 1A     Fa0/0
*,239.20.20.20                 192.168.18.129  00:02:38 00:22 1A     Fa0/0
*,239.10.10.10                 192.168.18.129  00:02:43 00:16 1A     Fa0/0
*,239.30.30.30                 192.168.18.129  00:02:34 00:25 1A     Fa0/0
*,224.0.1.40                   192.168.18.10   00:03:34 02:50 1LA    Fa0/0

What are these other groups here? We are these for? Check the Wireshark screenshot above for the blue and green boxes. 239.255.255.250 is used by SSDP (Simple Service Discovery Protocol) used for Universal Plug and Play and from the output above its REPORTER is my Host OS which is Windows (192.168.18.1). 224.0.1.40 is a well known IANA assigned address for RP discovery while its counter part 224.0.1.39 is for RP announcement. This is reported by the router itself.

Multicast Routers use the IANA allocated Multicast address 224.0.0.1 for Membership Queries.
This multicast address is  reserved for all hosts in the LAN segment.

Leave Group

What happens when a host no longer wants to receive multicast traffic? How does the router know that there are no more interested hosts for that multicast group. For version 1, IGMP by default does Membership query every 60 seconds. It sends the multicast to 224.0.0.1 which means all host in the subnet. If by 3 tries which would be 180 secs or 3 mins and there are no Membership Report for a certain address, the router removes the entry from the IGMP membership table. Let's again generate traffic for 239.10.10.10 in MINT and lets see after 3 mins what the router does if there are no more Membership Reports.

pete@pete-desktop:~/mint-1.2$ mint -r 239.20.20.20 -p 4321

Router#debug ip igmp 239.10.10.10
IGMP debugging is on
Router#
*Oct 30 13:53:33.727: IGMP(0): Received v1 Report on FastEthernet0/0 from 192.168.18.129 for 239.10.10.10
*Oct 30 13:53:33.731: IGMP(0): Received Group record for group 239.10.10.10, mode 2 from 192.168.18.129 for 0 sources
*Oct 30 13:53:33.731: IGMP(0): WAVL Insert group: 239.10.10.10 interface: FastEthernet0/0Successful
*Oct 30 13:53:33.731: IGMP(0): Switching to EXCLUDE mode for 239.10.10.10 on FastEthernet0/0
*Oct 30 13:53:33.735: IGMP(0): Updating EXCLUDE group timer for 239.10.10.10
*Oct 30 13:53:33.735: IGMP(0): MRT Add/Update FastEthernet0/0 for (*,239.10.10.10) by 0
*Oct 30 13:54:09.335: IGMP(0): Send v1 general Query on FastEthernet0/0
*Oct 30 13:54:14.815: IGMP(0): Report has illegal group address 224.0.0.251
*Oct 30 13:55:09.335: IGMP(0): Send v1 general Query on FastEthernet0/0
*Oct 30 13:55:14.095: IGMP(0): Report has illegal group address 224.0.0.251
Router#sh ip igmp member
Flags: A  - aggregate, T - tracked
L  - Local, S - static, V - virtual, R - Reported through v3
I - v3lite, U - Urd, M - SSM (S,G) channel
1,2,3 - The version of IGMP the group is in
Channel/Group-Flags:
/ - Filtering entry (Exclude mode (S,G), Include mode (*,G))
Reporter:
 - last reporter if group is not explicitly tracked
/      -  reporter in include mode,  reporter in exclude

Channel/Group                  Reporter        Uptime   Exp.  Flags  Interface
*,239.255.255.250              192.168.18.1    00:17:14 02:13 1A     Fa0/0
*,239.10.10.10                 192.168.18.129  00:02:27 00:32 1A     Fa0/0
*,224.0.1.40                   192.168.18.10   00:17:16 02:08 1LA    Fa0/0
Router#
*Oct 30 13:56:09.335: IGMP(0): Send v1 general Query on FastEthernet0/0
*Oct 30 13:56:15.155: IGMP(0): Report has illegal group address 224.0.0.251
*Oct 30 13:56:34.335: IGMP(0): Switching to INCLUDE mode for 239.10.10.10 on FastEthernet0/0
*Oct 30 13:56:34.335: IGMP(0): MRT delete FastEthernet0/0 for (*,239.10.10.10) by 0

The one highlighted in red is timestamped 13:53:33.735 when the router added 239.10.10.10 in the IGMP membership and when it did not receive a Membership report it removed the entry in its IGMP Membership timestamped 13:56:34.335, thats almost exactly 3 minutes! The command "show ip igmp membership" shows above that in 00:32 secs the multicast group will be removed from the IGMP Membership if it doesn't hear a Membership Report. If there was a real multicast source in this lab, R0 would have been wasting bandwidth for 3 minutes sending multicast traffic out of Fa0/0 with no receivers. IGMP version 1 doesn't have mechanism for hosts to inform the router that they are leaving the group. The host "quietly leaves" the multicast group. This lead to the development of IGMP V2.

Multicast Lab Preparation

My idea of studying the CCIE topics includes sniffing the packets using Wireshark and study the contents of the packet. This I think, is a good way to understand how a protocol works and what components/ fields make up a packet of a certain protocol. I also will continue making use of VMware to host operating systems to be used for my studies of Multicast, QoS and other topics. Here I will show I set up my Guest OS and install the Multicast Traffic Generator I will be using.

Requirements:

VMware Server Installer
MINT software for Linux (Multicast Application)
GNS3
Ubuntu image
Wireshark

Steps:

1. Install VMware software. After installation, create a new virtual machine. For steps, on how to create a virtual machine in VMware click here. Use the Ubuntu ISO image downloaded as the ISO for the virtual CD drive in the virtual machine. This would automatically boot the live cd. It will display a menu and choose "Try Ubuntu without any change to your computer." Screenshot from Ubuntu site seen below.



2. Let the Live CD run and when it fully boots up and shows the desktop, click Install Icon as seen below.


3. Once Ubuntu is done installing on your VMware, run it and it should be ready to be used the first time. Make sure the virtual NIC is set to NAT or Bridge. If this is set to bridge, your internet router should lease an ip addresses to this virtual NIC and would be on the same subnet as your real NIC connected to your internet router.

4. Check if you can browse the internet using Firefox on your Ubuntu VM. Download the MINT from http://mc-mint.sourceforge.net/. Download the latest version 1.2.

5. Ubuntu might need an update to install or compile *.tar files so we would need to update and install those updates. Execute the commands below on the Applications -> Accessories ->Terminal, just make sure you have internet connectivity on your Ubuntu VM.

sudo apt-get update

sudo apt-get install build-essential

6. Now its time to install MINT. Copy the downloaded mint to your /home/username directory. Unzip the file using commands below.

gzip -d mint-1.2.tar.gz

tar -xvf mint-1.2.tar

7. Go to the new mint directory created and execute the command "make" to compile.

8. If you want to install it to /usr/local/bin execute "make install". Open the README file for more details on how to install and run MINT by going to the directory ./mint and execute "more README".

9. Integrate your Ubuntu VM to your GNS by dragging a cloud as seen below(Click on the image to enlarge). Click on the cloud and Choose the VMware NIC and click add. Connect your GNS3 routers ethernet interface to the cloud and then configure the interface with same subnet IP as your VMware interface. Mine defaulted to 192.168.18.0/24. Check your Ubuntu ip address by executing "ifconfig" on the terminal and then ping it from the router to test connectivity. This should be ready for the exercises I will do in my studies.


10. Download Wireshark, on your host Operating System, (I assume its Windows) then install it. It should be ready to sniff any traffic on the VMware virtual NIC's.

Now, I am ready to start my mini labs for Multicasting. :)

Multicast Studies Loading

Its been a while since I posted something here. I have finished my BGP studies but will get back on that again after I have finished the other topics. Now I am into Multicasting and currently reading the book Developing IP Multicast Networks. The book might be a little old but the author is good at explaning what Multicast is and the other topics. I haven't even finished half of the book and yet the information it shares really helps. I have also setup VMware in my laptop and setup Ubuntu as a Guest Operating System on where I will run a multicast software to send and receive multicast traffic. Installed Wireshark for packet sniffing so I can see what's going on, on a multicast packet. I will post the instructions how I set up the lab I will be using and integrate it with Dynamips/GNS3. I am excited in this study because Multicast is one areas I have little to no experience with. I rarely encounter Multicast in the production networks in my present and previous jobs. This is one of weaknesses but the book I'm reading will greatly help me overcome this weakness.