All things related to multicast

[Gordon Rogier <>]

well sometimes communications do work.  got a nice and positive message
from Cyndi Jung at 3Com.  when i have heard (and hopefully tested a
possible fix), i will give the group an update.

thanks for the discussion on this issue.

--*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*--
Gordon Rogier                        

            
Network Engineer                     785-864-0381wk 785-550-4468 cell
Great Plains Network                 785-864-9330 FAX

---------- Forwarded message ----------
Date: Mon, 17 Jul 2000 01:46:27 -0700
From: Cyndi Jung 
<>
To: Gordon Rogier 
<>
Subject: Re: 3Com 3300 switch and IGMP Multicast Learning (fwd)

Gordon -

I just got a response from the product group this morning - they
say it is a known issue and that they are currently testing a possible
fix.  I'll let you know as soon as I do - though hopefully they will
contact you directly (they have your e-mail address now).

Cyndi

------------------------------------------------------------------------
OK - I'll try to help.  I know how this snooping is supposed
to work - it sounds as though the switch does not recognize that
there is a router (it is supposed to flood all IGMP messages to
ports where there are routers).  What multicast routing protocol
are you using?  Perhaps the product is not detecting the presence
of a router because it does not recognize the protocol?  Except you
do get some traffic through, but based on the membership reports
sent in response to the General Query?  

In addition to the routing protocol, could you tell me the application
and the type of end system - if we can reproduce the behavior we can
potentially fix the problem.

Cyndi



At 09:29 AM 7/13/00 -0500, Gordon Rogier wrote:
>Cyndi,  Kevin Almeroth suggested that I send you a directed message on
>this issue I am seeing on the 3Com SuperStack II 3300.  I would send it to
>a "TAC" type address for 3Com, but I can not identify one.
>
>thanks in advance.
>
>--*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*--
>Gordon Rogier                        
>
>            
>Network Engineer                     785-864-0381wk 785-550-4468 cell
>Great Plains Network                 785-864-9330 FAX
>
>---------- Forwarded message ----------
>Date: Thu, 13 Jul 2000 07:07:37 -0700 (PDT)
>From: Kevin C. Almeroth 
><>
>To: 
>
>Subject: Re: 3Com 3300 switch and IGMP Multicast Learning
>
>>>If I can figure out a valid support email address for 3Com I will
>forward
>>>this them also.
>
>THere are several 3Com people on this list.  Though, I'd send something
>directly to Cyndi Jung 
>().
>  Maybe you can get a pointer from
>her.
>
>-Kevin
>
>---------- Forwarded message ----------
>Date: Wed, 12 Jul 2000 19:12:59 -0500 (CDT)
>From: Gordon Rogier 
><>
>To: 
>
>Subject: 3Com 3300 switch and IGMP Multicast Learning
>
>I am having a little problem with the 3Com SuperStack II 3000 ethernet
>switch and IGMP Multicast Learning.  I am interested to see if anyone else
>has experience and/or reported this issue to 3Com.
>
>This issue was identified up to and including the latest SSII 3000 code
>available of v2.43.
>
>When in IGMP Multicast Learning mode, it appears to me that the 3Com 3000
>does not forward the IGMPv2 Membership Report (8bit 'type' field of 0x16)
>to which is sent to the 224.0.0.2 group in response to an IGMP Group
>Specific Query (it does not send it anywhere, esp. back towards the
>querier router). Because this membership report does not get back to the
>querier and in the case that this is _not _ the only receiver on the
>segment, the mcast router prunes down the group until a General Query
>rolls around.  This effectively can cut off the mcast traffic
>inappropriately and cause mcast traffic 'ghosting' type problems for most
>applications.  Effectively bad systemic jitter at best.
>
>Turning off IGMP Multicast Learning clearly does "flood" all mcast traffic
>as expected.
>
>It basically looks like the 3Com 3300 actually "eats" all IGMP packets and
>makes specific forwarding decisions for IGMP packets.
>
>Has anyone else seen this problem???
>
>I am quite concerned about this.  It is quite debatable to me if this
>feature should be turned on or off.  If high bandwidth applications are
>present, it almost has to be on for reasonable traffic control..... but,
>it you need to support lower bandwidth applications like SLP services,
>then this could cause some noticable ghosting issues... and for video type
>services where side by side receivers are 'channel-surfing' they can very
>easily cause noticable IGMP induced "jitter" in the traffic stream on the
>local segment.
>
>If I can figure out a valid support email address for 3Com I will forward
>this them also. 
>
>--*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*--
>Gordon Rogier                        
>
>            
>Network Engineer                     785-864-0381wk 785-550-4468 cell
>Great Plains Network                 785-864-9330 FAX