IGMP Version 3

IGMP version 3 adds support for “source filtering”. IGMP version 1 and version 2 allow hosts to join multicast groups but they don’t check the source of the traffic. Any source is able to receive traffic to the multicast group(s) that they joined.

With source filtering, we can join multicast groups but only from specified source addresses. IGMP version 3 is a requirement for SSM (Source Specific Multicast) which we will cover in another lesson.

Why is this useful? Let me give you an example:

Multicast video server four hosts

Above we have a video server that is streaming multicast traffic on the network using destination address 239.1.1.1. There are four hosts listening to this traffic, life is good. Suddenly something happens:

multicast attacker sending traffic

An attacker didn’t like the video stream and decided to stream his favorite video to destination address 239.1.1.1.1. Since we don’t check the source address, everyone will receive the traffic from our attacker. It’s also possible to send bogus traffic and create a DoS attack like this.

IGMP version 1 and 2 don’t have any protection against this.

With IGMP version 3, our hosts can be configured to receive multicast traffic only from specified source addresses. Let’s see how this works, I’ll use the following topology for this:

Multicast IGMP Version 3 topology

We will only use two devices, one multicast enabled router and a host device. I’m using a Cisco router as the host device as well.

Let’s start with R1:

R1(config)#ip multicast-routing
R1(config)#interface GigabitEthernet 0/1
R1(config-if)#ip pim sparse-mode 
R1(config-if)#ip igmp version 3

Our router requires multicast routing and PIM should be enabled on the interface. The default version of IGMP is 2 so we’ll change it to version 3. Before we let H1 join a multicast group, let’s enable debugging on both devices:

R1 & H1#debug ip igmp 
IGMP debugging is on

R1 will start sending membership general queries like the one below:

multicast igmp version 3 membership query general

Let’s configure H1 to join a multicast group:

H1(config)#interface GigabitEthernet 0/1
H1(config-if)#ip igmp join-group 239.1.1.1 ?
  source  Include SSM source
  <cr>

Besides configuring a group, I can configure the host to include a source address. Let’s pick something:

H1(config-if)#ip igmp join-group 239.1.1.1 1.1.1.1

H1 will now include the source address in its membership report messages. Here’s what you will see on the console:

H1#
IGMP(0): WAVL Insert group: 239.1.1.1 interface: GigabitEthernet0/1Successful
IGMP(0): Create source 1.1.1.1
IGMP(0): Building v3 Report on GigabitEthernet0/1
IGMP(0): Add Group Record for 239.1.1.1, type 5
IGMP(0): Add Source Record 1.1.1.1
IGMP(0): Add Group Record for 239.1.1.1, type 6
IGMP(0): No sources to add, group record removed from report
IGMP(0): Send unsolicited v3 Report with 1 group records on GigabitEthernet0/1
IGMP(0): Building v3 Report on GigabitEthernet0/1
IGMP(0): Add Group Record for 239.1.1.1, type 5
IGMP(0): Add Source Record 1.1.1.1
IGMP(0): Add Group Record for 239.1.1.1, type 6
IGMP(0): No sources to add, group record removed from report
IGMP(0): Send unsolicited v3 Report with 1 group records on GigabitEthernet0/1

H1 sends two membership report messages. The first message includes the multicast group address and source address that we want to receive. The second message includes the “mode”. There are two modes:

  • Include: this is a list of source addresses that we accept multicast traffic from, everything else should not be forwarded.
  • Exclude: this is a list of source addresses that we refuse to accept multicast traffic from, everything else should be forwarded.

Here’s what it looks like in wireshark:

We're Sorry, Full Content Access is for Members Only...

If you like to keep on reading, Become a Member Now! Here is why:

  • Learn any CCNA, CCNP and CCIE R&S Topic. Explained As Simple As Possible.
  • Try for Just $1. The Best Dollar You've Ever Spent on Your Cisco Career!
  • Full Access to our 662 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)

515 Sign Ups in the last 30 days

satisfaction-guaranteed
100% Satisfaction Guaranteed!
You may cancel your monthly membership at any time.
No Questions Asked!

Tags: ,


Forum Replies

  1. Rene,

    Great lesson, however I have a question about for the host don’t we need ip pim sparse-mode? I can see on the router we have ip pim sparse-mode.

    Please clarify.

    Hamood

     

     

  2. great post.

    with respect to below 2 statements: what is the diff between multicast-routing and PIM command ? both seems to be doing same thing - process the IGMP traffic.

    1.First we enabled multicast routing globally, this is required for the router to process IGMP traffic.
    2.We enabled PIM on the interface. PIM is used for multicast routing between routers and is also required for the router to process IGMP traffic.

    Also
    a. from where .40 address came ? does router generates it randomly ?
    b. group address 239.1.1.1 who decides and gives this IP in real time environment ?

  3. Hi,

    R1#show ip igmp groups 239.1.1.1
    IGMP Connected Group Membership
    Group Address    Interface                Uptime    Expires   Last Reporter   Group Accounted
    239.1.1.1        GigabitEthernet0/1       19:22:56  00:01:07  192.168.1.101
    

    Can you explain
    Why the host cannot see 192.168.1.102 cant see here
    Thanks

  4. There are two options that come to mind:

    R1#show ip multicast                   
            Multicast Routing: enabled
            Multicast Multipath: disabled
            Multicast Route limit: No limit
            Multicast Triggered RPF check: enabled
            Multicast Fallback group mode: Sparse
            Multicast DVMRP Interoperability: disabled
    

    Or just check the running config:

    R1#show run | include multicast-routing
    ip multicast-routing

  5. Hello Recto

    The 239.0.0.0 to 239.255.255.255 range of multicast IP addresses known as “Administratively scoped” addresses. These are defined by RFC 2365 and are reserved for private use within an organization. So to answer your question, yes, when configuring multicast groups it is best practice to use these addresses.

    Having said that, as you probably know, there are various special-use multicast addresses that have various purposes as defined by the IANA and by various RFCs. Although I don’t like linking to Wikipedia, I find that their summary of the IPv4

    ... Continue reading in our forum

13 more replies! Ask a question or join the discussion by visiting our Community Forum