Tricky troubleshooting scenario

Unanswered Question
Mar 2nd, 2010

I have a router R with interface FastEthernet 0/0 connected to a switch SW. R is running PIM in dense mode on all interfaces and from inerface Fa0/0 igmp queries are sent. When I turn on a host which injects a high level of broadcast traffic into SW, many queries are lost (they don't reach the hosts connected to SW. Consequently, some hosts which want to reiceve multicast traffic, stop to receive it.

Now, if I disable igmp snooping on SW (which is on by deafault), everything becomes normal again (queries are no  longer lost anf multicast traffic is received by everyone connected to SW).

So, to sum up:

- igm snooping on, no broadcast -> OK

- igmp snooping off, broadcast on -> OK

- igmp snooping on, broadcast on -> PROBLEMS

From show processes cpu and show processes memory, SW does not seem to be overloaded.

Any idea?

Thanks in advance.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Jon Marshall Tue, 03/02/2010 - 13:09

gianluca2891 wrote:

I have a router R with interface FastEthernet 0/0 connected to a switch SW. R is running PIM in dense mode on all interfaces and from inerface Fa0/0 igmp queries are sent. When I turn on a host which injects a high level of broadcast traffic into SW, many queries are lost (they don't reach the hosts connected to SW. Consequently, some hosts which want to reiceve multicast traffic, stop to receive it.

Now, if I disable igmp snooping on SW (which is on by deafault), everything becomes normal again (queries are no  longer lost anf multicast traffic is received by everyone connected to SW).

So, to sum up:

- igm snooping on, no broadcast -> OK

- igmp snooping off, broadcast on -> OK

- igmp snooping on, broadcast on -> PROBLEMS

From show processes cpu and show processes memory, SW does not seem to be overloaded.

Any idea?

Thanks in advance.

If IGMP snooping is disabled then the switch has a simple decision to make ie. send all broadcasts and multicasts to all ports except the one it was received on. It's not that queries are no longer lost, it's just that queries are now irrelevant from the switches point of view.

But if IGMP snooping is enabled then the switch will only send traffic to clients that have responded to an IGMP query. But if IGMP queries are getting lost then the host does not respond and so the switch has no way of knowing that this host wants to receive the multicast traffic.If the switch cannot see the response from the host because the host never got the query the switch will never add that host's port to the list of ports that should receive the multicast stream.

Jon

gianluca2891 Tue, 03/02/2010 - 14:00

jon.marshall ha scritto:

If IGMP snooping is disabled then the switch has a simple decision to make ie. send all broadcasts and multicasts to all ports except the one it was received on. It's not that queries are no longer lost, it's just that queries are now irrelevant from the switches point of view.

I know they are irrilevant, but as a matter of fact, they are no longer lost (the sniffer now shows them).

But if IGMP snooping is enabled then the switch will only send traffic to clients that have responded to an IGMP query. But if IGMP queries are getting lost then the host does not respond and so the switch has no way of knowing that this host wants to receive the multicast traffic.If the switch cannot see the response from the host because the host never got the query the switch will never add that host's port to the list of ports that should receive the multicast stream.

Ok, that's quite clear to me now. What I still don't fully understand, is why when I disable igmp snooping, less packets seem to get lost (for instance, the igmp queries as stated above), altough the switch does not seem to be overloaded (cpu and memory seem ok) even with snoopig on.  

Jon

Thanks!

Giuseppe Larosa Tue, 03/02/2010 - 14:18

Hello Gianluca,

adding some details could be helpful:

what device is SW? What IOS image is running on it?

the server sending broadcast traffic what protocol uses and what is the traffic volume?

unless the switch IGMP ASIC is not fouled by processing also the broadcast frames it should not be affected by broadcast traffic

Other thought:

Is any form of broadcast storm control enabled on the device?

some devices when drop is triggered drop also multicast traffic not only broadcast

Hope to help

Giuseppe

gianluca2891 Wed, 03/03/2010 - 10:36

SW is a 2950 with 12.1(22)EA8 IOS.

The application that is generating broadcast traffic is propietary. Broadcast traffic volume is in the order of a ten of Mbits on the average, but it is very bursty and you can see periodic peaks (every couple of seconds or so). No form of broadcast suppression like storm control is enabled.

Actually, I see something that worries me a bit. For instance, on the interface of the connected router, I see the drops due to interface queue overflow increasing when broadcast traffic is sent and increasing input errors as well.

Thanks 

Actions

This Discussion