All things related to multicast

["Curtis, Bruce" <>]

On Nov 10, 2010, at 11:07 AM, Ray Soucy wrote:

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



Cisco finally opened a bug, here is the ID.


CSCtl51859    IPv6 MLD Snooping Causes Neighbor Discovery to Fail




> 
> 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/
> 

---
Bruce Curtis                         

Certified NetAnalyst II                701-231-8527
North Dakota State University