IGMP Snooping

(Ananth Maruti M) #19

In the below message , u had mentioned the switch will send a message if any-one else is still interested? where is this message seen?

SW1#
IGMPSN: group: Group exist - Leave for group 239.1.1.1 received on Vlan 1, port Gi0/3, group state (1)
IGMPSN: group: Created v2 leave port on port Gi0/3, for group 239.1.1.1 on Vlan 1 
IGMPSN: group: Deleting leave port on port Gi0/3, for 4.124.4.0 on Vlan 1 
L2MM: Add member: gda:0100.5e01.0101, removing Gi0/3
IGMPSN: mgt: deleted port Gi0/3 on gce 0100.5e01.0101, on Vlan 1
IGMPSN: group: Deleting port Gi0/3 from group 239.1.1.1 on Vlan 1

As you can see the switch receives the leave group message from H2. It sends a message on interface Gigabit0/3 to figure out if anyone is still interested but doesn’t get a reply. The interface will then be removed.

(Ananth Maruti M) #20

Also generally only one host will be connected to one port of the switch right? Then why there is a need to send the group specific query to the port when one of the host decides to leave from that port?

(Ananth Maruti M) #21

You had mentioned the below statement

Leave group messages are always sent to multicast group 224.0.0.2 using destination MAC address 0100.5e00.0002. When the switch receives the IGMP leave, it will forward it on the internal interface to the CPU.

In response, the switch will send an IGMP general query on the interface that connects to H1:


My question here us why the switch sends the IGMP general query ? how different it is from a group specific query sent by a router?

Pls explain. I think I am confused here.

(XIN W) #22

If we have 2 Host which connected to IGMP snooping enabled switch, and those 2 hosts joined group 225.0.0.1(H1) and 226.0.0.1(H2) separately, the tricky here is both 225.0.0.1 and 226.0.0.1 are have the same multicast MAC address, so on the IGMP Snooping enabled switch treat those 2 multicast group?

If there is multicast traffic coming from source for 225.0.0.1, will H2 also received 225.0.0.1 traffic ?

(Andrew P) #23

Xin,
You are exactly right in everything you said. 225.0.0.1 and 226.0.0.1 both share the same layer 2 MAC address. As a result, the switch, at layer 2, can’t distinguish between them, so a receiver for 225.0.0.1 would also get all multicast traffic for every other layer 3 feed that matches the same layer 2 MAC.

This is one area where administrators have to be careful in planning their multicast environments–making sure this overlap does not happen.

The story about how this happened is somewhat interesting (and funny). Basically, an engineer’s manager was too cheap to reserve the entire range needed, so now the whole world has this problem to worry about!

You can read more about it in another lesson here:
https://networklessons.com/multicast/multicast-ip-address-to-mac-address-mapping

(Lazaros Agapides) #24

Hello Ananth. I will attempt to answer all of your questions in this single reply.

  1. You wrote: H1 and H2 are still interested so they will respond with a membership report. The switch will intercept these two messages and forwards them to the CPU. One of the two membership reports is then forwarded to the router. In the above statement , only one the membership report is forwarded to the router . Is this a form of report suppression? Also explain why only one report is sent?

Yes, only one membership report is forwarded to the router, however this one membership report includes all of the interfaces that want to take part in the multicast group. This is not a form of membership report suppression, because as mentioned in the lesson:

"our hosts don’t hear each others membership reports. This overrules the membership report suppression mechanism which I described in the IGMP version 2 lesson. This is required since the switch has to hear the membership report from all interfaces that need to receive the multicast traffic."
  1. You wrote: Also one more query , if the router sends a general query , the switch forwards the query to all hosts? Is that correct? Will the switch able to generate query message on its own?

Yes, that is correct. The switch will forward the query to all hosts. The switch does not generate its own queries, but transmits the queries received from the router.

  1. You wrote: It might be a dum question. How the PC has interface address as 0/1 . Normally the PC is connected to the switch right?

Rene here is using routers to act as the PCs so that information about IGMP can be viewed. That is why the interface is GigabitEthernet 0/1 on the logging output in the lesson.

  1. You wrote: In the below message, Send v2 Report for 239.1.1.1 on GigabitEthernet0/1. Which 0/1 interface it is referiing to ? Is it switch or the host interface

Again, this is the interface of the router that is playing the role of the PCs. Router with hostname H1 plays the role of Host 1 and router with hostname H2 for Host 2.

  1. You wrote: In the below message , u had mentioned the switch will send a message if any-one else is still interested? where is this message seen?

Yes, you are right. The first line should read
IGMPSN: group: Group exist - Leave for group 239.1.1.1 received on Vlan 1, port Gi0/2, group state (1)
and not Gi0/3

  1. You wrote: Also generally only one host will be connected to one port of the switch right? Then why there is a need to send the group specific query to the port when one of the host decides to leave from that port?

Actually, you may have more than one host connected to one port of a switch. What if you connect a hub to this port? (not that you would, but this must also be taken into account). What if you connect an unmanaged switch to this port? So you may have more than one host on a port…

  1. You wrote: My question here us why the switch sends the IGMP general query? [as a response to a leave group message] how different it is from a group specific query sent by a router?

For this question, Andrew has written a very good answer. Take a look at this post: https://networklessons.com/topic/igmp-snooping/#post-23806

I hope these answers have been helpful!

Laz

1 Like
(Shantel - Networklessons.com) split this topic #25

19 posts were merged into an existing topic: IGMP Snooping

(Stefanio L) #26

Hi Rene

I did a lab with two switches connected via a trunk link. the SW1 is connected in a multicast router and the SW2 exists 2 receivers connected, but after I activate the multicast routing and the PIM, only SW1 discovered the querier, but besides not SW2. In SW1, I can’t see the groups, which I set up in H1 and H2. This is a limitation of the igmp snooping or is supposed to work?

(Rene Molenaar) #27

@stlourenco This should normally work. Did you use real hardware or an emulator like Cisco VIRL?

(say hian a) #28

Hi Rene

Had a couple of question to ask regarding about multicasting within a switch.

Regarding about IGMP configuration without router, What is the H1 and H2? are they workstation or switch? how is it able to configure ‘ip igmp join-group’ on H1 and H2?

Does the following commands assign multicast ip address to ports in switch?
ip igmp snooping vlan (vlan number) static (multicast address) interface (interface number)
Example:

ip igmp snooping vlan 2 static 239.1.2.3 int gi1/0/3

When I set ip igmp snooping querier on a switch, should it be in the same vlan
as the multicasting ports?

(Lazaros Agapides) #29

Hello Say Hian

I will attempt to answer your questions below:

H1 and H2 are hosts. However, Rene has used routers there to simulate the hosts. This is why he has command line access to them.[quote=“sayhian16, post:28, topic:1321”]
Does the following commands assign multicast ip address to ports in switch?
ip igmp snooping vlan (vlan number) static (multicast address) interface (interface number)
Example:

ip igmp snooping vlan 2 static 239.1.2.3 int gi1/0/3
[/quote]

This command will configure a layer 2 port as a member of the group defined by the static multicast address that you specify.

The IGMP Snooping Querier feature can be enabled either globally or on a per-VLAN basis. If you only want to query only the specific multicasting ports, then you can limit it to the VLAN. For more information, take a look at this Cisco documentation.

I hope this has been helpful!

Laz

(say hian a) #30

Hi lagapides,

Thank you very much on your reply and guidance, it was useful.
Just want to clarify more on the previous command

ip igmp snooping vlan 2 static 239.1.2.3 int gi1/0/3

Does this command has the same meaning as configuring a switch as a host and plug into gi1/0/3?
Example:

int vlan 2
ip address 192.168.1.20 255.255.255.0
ip igmp join-group 239.1.2.3

Just want to seek your guidance on verification on if multicasting is workable on the following lab experiment

PC1

ip address 192.168.1 10
subnet mask 255.255.255.0  

SW1

int range gi1/0/1-2
switchport mode access
switchport access vlan 100

ip igmp snooping
int vlan 100
ip address 192.168.1.20 255.255.255.0
ip igmp snooping querier

H1 (using mr rene method of configuring a switch as a host)

int gi1/0/1
no switchport
ip address 192.168.1.50 255.255.255.0
ip igmp join-group 239.156.1.16

The PC1 was connect to gi1/01 of SW1 and H1 is connect to gi1/0/2 of SW1

the result of command on SW1

sh ip igmp snooping querier

vlan    IP address         IGMP version     Port
100      192.168.1.20        V2                    Switch

sh ip igmp snooping group

vlan      group                       Type     version   port list
100      224.0.1.40                igmp        v2         gi1/0/2
100      239.156.1.16            igmp        v2        gi1/0/2
100      239.255.255.250     igmp         v2        gi1/0/1, gi1/0/2

how to I verify that multicast is working in this system?

using PC1 to ping 239.156.1.16?

Please advise, Thank you

(Lazaros Agapides) #31

Hello Say Hian

No. The two commands differ in the following way:

The command ip igmp snooping vlan 2 static 239.1.2.3 int gi1/0/3 will statically configure a multicast group on a specific physical port.

The commands

int vlan 2 ip address 192.168.1.20 255.255.255.0 ip igmp join-group 239.1.2.3

will configure a multicast group on the VLAN interface itself.

As for your lab configuration, it looks like it is correct. You can check it by issuing the debug commands that Rene has in the lesson starting from the commands after the video.

I hope this has been helpful!

Laz

(sims) #32

HI
“From now on, all multicast traffic that has destination MAC address 0100.5e01.0101 will only be forwarded on interface Gi0/1, Gi0/4 and the internal interface to the CPU.”

" In the example above we see that R1 is sending 10 Mbps of multicast traffic which is forwarded to H1 and the CPU. Our CPU is unable to process 10 Mbps of traffic so it will choke on it…when this occurs, there’s a couple of things that could occur: "

Why the traffic itself sending to the CPU

Thanks

(Lazaros Agapides) #33

Hello Sims

When stating that multicast traffic will be sent to the CPU, it essentially means that any traffic with a destination MAC of 0100.5e01.0101 will not be forwarded directly to any physical ports, but will be further processed to determine where it should go. This is conceptually described as being sent to the INT interface that connects to the CPU.

In essence what is happening is the switch receives multicast traffic and it recognises it as such from the destination MAC address. It knows that such traffic must go to several destinations, but in order to find out where, it goes to the INT interface or to the CPU, and the CPU then determines which interfaces it should go to by looking it up in the CAM table.

Once this is determined, the frames are then sent out the appropriate interfaces according to the CAM table entries found.

I hope this has been helpful!

Laz

(Hussein Samir) #34

Hi Rene,

which command can I use to show the multicast mac addresses in CAM table ??

(Rene Molenaar) #35

Hi Hussein,

You can try:

R1# show mac address-table multicast vlan 1
 vlan   mac address     type    qos             ports
 -----+---------------+--------+---+--------------------------------
   1  0100.5e02.0203  static   --  Gi0/1,Gi0/2,Router
   1  0100.5e00.0127  static   --  Gi0/1,Gi0/2,Router
   1  0100.5e00.0128  static   --  Gi0/1,Gi0/2,Router
   1  0100.5e00.0001  static   --  Gi0/1,Gi0/2,Router,Switch
2 Likes
(Hussein Samir) #36

Thanks Rene,

I know this command but it’s only show statically configured mac addresses, what about dynamic learned by igmp snooping ? how can I verify them ? or they are only shown by “show ip igmp snooping groups” command ???

And I have four other questions :-

1- Can you please explain the robustness variable to me ??
The RFC2236 said :-
**“The Robustness Variable allows tuning for the expected packet loss on a subnet. If a subnet is expected to be lossy, the Robustness Variable may be increased. IGMP is robust to (Robustness Variable-1) packet losses. The Robustness Variable MUST NOT be zero, and SHOULD NOT be one. Default: 2”**
I understand that I must increased it when there is a packet loss in a subnet but I did not understand its effect or why must not be zero ??

2- what are the difference between the “show ip IGMP snooping” command and “show ip IGMP snooping detail” command since they are display the same output ??

3- what are the relationship between the TCN and IGMP snooping because I saw configuration part of them in global and per interface ???

4- I saw in the output of “show ip igmp snooping” command that IGMPv3 snooping not supported, how can I enable it or it’s platform dependent ??

(Rene Molenaar) #39

Hi Hussein,

You can see the multicast groups with show ip igmp snooping groups but it won’t show the corresponding MAC addresses that are used per group. About your questions:

You can use this if you expect packet loss on your subnet. It changes the interval for some IGMP messages. The downside of changing this is that you increase the leave latency:

* Group member interval: this is the amount of time that the router waits before it determines there are no members left in the group. It is calculated as (robustness variable * query-interval) + (1x query response interval).
* Other querier present interval: the amount of time that a router has to wait before determining there is no other multicast router that is the querier. Calculated as (robustness variable * query interval) + (0.5 x query response interval).
* Last member query count: number of group specific querier that the router sends before it determines there are no members left in the multicast group. The number of queries is equal to the value of the robustness variable.

The reason it can’t be zero is probably because of the last member query count. A setting of 0 would indicate it won’t send any last member query count messages.

That is a good question…I didn’t see this before but you are right, the output is exactly the same. Probably a Cisco IOS quirk…

Before Cisco IOS 12.1(11b)EW, the default behavior of the switch was to flood multicast traffic on all interfaces when it receives a TCN (which indicates a spanning-tree topology change). The idea behind this is that multicast traffic is not interrupted but it can get pretty ugly if you have a lot of multicast traffic which is why there is the no ip igmp snooping tcn flood command.

This command disables the flooding of multicast when a TCN is received, and you can set it per interface.

Hmm I think this depends on the platform and IOS version. I don’t believe there is a separate command to enable/disable IGMPv3 snooping.

1 Like
(Hussein Samir) #40

Thank you very much MR. Rene, I appreciate your efforts and do not know how to reward you.