All things related to multicast

[Ray Soucy <>]

Who want's to open a TAC case? :-)

On Wed, Nov 10, 2010 at 11:44 AM, Curtis, Bruce 
<>
 wrote:
>
> On Nov 8, 2010, at 6:22 AM, Ray Soucy wrote:
>
>> We noticed that a recent upgrade on our Catalyst 3560 and 3750s made
>> it so that MLD broke ND (and thus IPv6).  I haven't had time to check
>> into it more, but we assumed it was a bug and disabled MLD snooping
>> for now.  MLD snooping seemed to work OK in previous releases.
>>
>> I did some searching a few weeks ago and couldn't find anyone else
>> talking about the problem.  This is the first time I've seen someone
>> else mention the issue.
>>
>> Has anyone else seen MLD snooping break ND or is it just a
>> configuration oversight?
>
>  I checked and MLD Snooping wasn't braking ND on our 3750s.
>
>  We then upgraded to the latest code on a single 3750 and MLD snooping did 
> indeed break ND.
>
>
>> On Mon, Nov 8, 2010 at 2:27 AM, Multicast maillist
>> <>
>>  wrote:
>>> As per RFC 4541 (Considerations for Internet Group Management Protocol
>>> (IGMP)and Multicast Listener Discovery (MLD) Snooping Switches), it is
>>> inferred that forwarding criteria for all multicast IPv6 address (except
>>> ff02::1) is always based on group database as MLD is mandated for all the
>>> multicast v6 address.
>>>
>>> As per this, there is no special consideration for solicited multicast
>>> addresses or multicast addresses used for protocol control traffic.
>>>
>>> I feel this could cause issues in protocol adjacency maintenance or DAD
>>> process.
>>>
>>> Below is the link discussing about CISCO mld snooping breaking DAD
>>> functionality.
>>>
>>> http://networking.itags.org/networking-tech/148011/
>>>
>>> OSPFv3 adjacency could break if MLD snooping is enabled on a L2 switch
>>> between two OSPFv3 neighbors. (If the enable configuration happens just
>>> after a MLD query in the network, It would take another 120+ seconds to 
>>> get
>>> the MLD report for FF02::5. OSPFv3 hello packets will not be forwarded by
>>> the MLD snooping enabled switch till report for FF02::5 is received and
>>> adjacency will break).
>>>
>>> There was a draft draft-pashby-magma-simplify-mld-snooping-01.txt stating
>>> that multicast traffic for solicited addresses and control packet reserved
>>> addresses should be forwarded to all ports. But that draft was not taken
>>> forward and has expired.
>>>
>>> What is the stand taken by vendors implementing MLD snooping to address 
>>> the
>>> above issues?
>>>
>>> Shouldn’t the MLD snooping enabled switch forward the traffic for 
>>> solicited
>>> multicast address and protocol control packets to all the ports of VLAN?
>>>
>>>
>>> Regards,
>>>
>>> Magna.
>>
>>
>>
>> --
>> Ray Soucy
>>
>> Epic Communications Specialist
>>
>> Phone: +1 (207) 561-3526
>>
>> Networkmaine, a Unit of the University of Maine System
>> http://www.networkmaine.net/
>>
>
> ---
> Bruce Curtis                         
> 
> Certified NetAnalyst II                701-231-8527
> North Dakota State University
>
>
>



-- 
Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

Networkmaine, a Unit of the University of Maine System
http://www.networkmaine.net/