cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2142
Views
5
Helpful
6
Replies

ip igmp debugging -- help with output

branfarm1
Level 4
Level 4

Hi there,

Can someone please tell me what 'Mode X' and "for x sources" means in the ip igmp debugging output?

Here's an example:

Jul 17 14:57:03 192.168.0.3 149897: Jul 17 18:57:02: IGMP(0): Received v2 Report on Vlan1 from 192.168.0.81 for 239.0.0.100

Jul 17 14:57:03 192.168.0.3 149898: Jul 17 18:57:02: IGMP(0): Received Group record for group 239.0.0.100, mode 2 from 192.168.0.81 for 0 sources

Jul 17 14:57:03 192.168.0.3 149899: Jul 17 18:57:02: IGMP(0): Updating EXCLUDE group timer for 239.0.0.100

Jul 17 14:57:03 192.168.0.3 149900: Jul 17 18:57:02: IGMP(0): MRT Add/Update Vlan1 for (*,239.0.0.100) by 0

----At this point I killed the iperf process that was listening on this group address ------------

Jul 17 14:57:44 192.168.0.3 149916: Jul 17 18:57:43: IGMP(0): Received Leave from 192.168.0.81 (Vlan1) for 239.0.0.100

Jul 17 14:57:44 192.168.0.3 149917: Jul 17 18:57:43: IGMP(0): Received Group record for group 239.0.0.100, mode 3 from 192.168.0.81 for 0 sources

Jul 17 14:57:44 192.168.0.3 149918: Jul 17 18:57:43: IGMP(0): Lower expiration timer to 2000 msec for 239.0.0.100 on Vlan1

Jul 17 14:57:44 192.168.0.3 149919: Jul 17 18:57:43: IGMP(0): Send v2 Query on Vlan1 for group 239.0.0.100

Jul 17 14:57:44 192.168.0.3 149920: Jul 17 18:57:44: IGMP(0): Send v2 Query on Vlan1 for group 239.0.0.100

Jul 17 14:57:45 192.168.0.3 149926: Jul 17 18:57:45: IGMP(0): Switching to INCLUDE mode for 239.0.0.100 on Vlan1

Jul 17 14:57:45 192.168.0.3 149927: Jul 17 18:57:45: IGMP(0): MRT delete Vlan1 for (*,239.0.0.100) by 0

Thanks in advance,

--Brandon

1 Accepted Solution

Accepted Solutions

Hello Brandon,

>> A couple of hours ago, the application that was receiving the group reported that it stopped receiving data for 2 mins. I am sniffing the traffic between the Vendor router and my multilayer switch and I didn't see the traffic stop for that group, and the timers don't act like the server actually left/rejoined the group either.

If you were sniffing during the claimed short outage and there is no evidence of IGMP activity related to the host verify if the multicast router was sending the IGMP queries in those two minutes (igmp snooping requires someone to perform queries): I see you say group timers didn't reset.

You also see the group traffic in your capture?

By summing all facts group traffic going with no silence, igmp normal activity if also the L2 port where host is connected didn't changed status I agree it might be an application or o.s. issue on host.

Hope to help

Giuseppe

View solution in original post

6 Replies 6

Giuseppe Larosa
Hall of Fame
Hall of Fame

Hello Brandon,

how are you?

it looks like this device is acting as an IGMPv2 to IGMPv3 translator:

it sends and receive v2 messages and then it builds version3 messages on behalf of the real users

exclude include for source are IGMPv3 concepts

Hope to help

Giuseppe

Hey Giuseppe,

I'm doing well -- glad to see you remember me :) As you can see, I'm back to my multicast problems again. This time I'm fresh from the Cisco ICMI class, so hopefully I'll be able to make more progress. In fact, I went back and re-read the posts you tried to help me with last year and I actually understand what you were trying to have me do!

For this though, if I'm understanding it correctly, then the EXCLUDE really means "send me this data, excluding 0 sources" and the INCLUDE really means "Send me this data, Including 0 sources". The exclude has the effect of joining, and the include has the effect of leaving. Is that right?

Hello Brandon,

I remember I had failed to recognize you in that other thread about OSPF routing!

forget what I wrote in my first post by reading more carefully I think this is only igmpv2 scenario and you can see all the classic stuff:

after a host does an explicit leave a specific query is sent to see if somebody else is on the group for that interface (vlan SVI)

no one answers and at the end the interface is purged from oilist for the group.

some other messages we see might be related to IGMP snooping if this is a multilayer switch.

Under igmp snooping scenario I think the include / exclude means activity on the L2 port replication list for the group.

Hope to help

Giuseppe

Ok -- I see what you're saying.

So, what I'm seeing is that I have an application on one server that receives data on a certain multicast group, 239.0.0.100 we'll say. The path for this data is as follows:

Source -- CLOUD --RouterA(vendor) -- Multilayer Switch B (PIM enabled) -- Multilayer Switch A (not PIM enabled) -- Workgroup Switch -- Server

When I look at the IGMP groups on the router interface on Multilayer Switch B, I see that the group has been joined for 20+ hrs, and the Mroute for that group shows that it's been forwarding for 10+ hours. The difference is due to the fact that the host joined before the group was sending data.

A couple of hours ago, the application that was receiving the group reported that it stopped receiving data for 2 mins. I am sniffing the traffic between the Vendor router and my multilayer switch and I didn't see the traffic stop for that group, and the timers don't act like the server actually left/rejoined the group either.

Do you think the problem could still be in the network somewhere, or would you say it's an application bug?

Hello Brandon,

>> A couple of hours ago, the application that was receiving the group reported that it stopped receiving data for 2 mins. I am sniffing the traffic between the Vendor router and my multilayer switch and I didn't see the traffic stop for that group, and the timers don't act like the server actually left/rejoined the group either.

If you were sniffing during the claimed short outage and there is no evidence of IGMP activity related to the host verify if the multicast router was sending the IGMP queries in those two minutes (igmp snooping requires someone to perform queries): I see you say group timers didn't reset.

You also see the group traffic in your capture?

By summing all facts group traffic going with no silence, igmp normal activity if also the L2 port where host is connected didn't changed status I agree it might be an application or o.s. issue on host.

Hope to help

Giuseppe

Thanks Giuseppe! As always, you've been very helpful

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco