All things related to multicast

["Curtis, Bruce" <>]

On Jan 11, 2011, at 9:13 AM, Curtis, Bruce wrote:

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

  Cisco says they have fixed this bug.  The bug report says it is fixed in 
15.0(4.1)SID but I see that while 12.2(58)SE is listed as an affected version 
12.2(58)SE1 is not listed as an affected version.

  We probably won't verify this is fixed until next week.

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

---
Bruce Curtis                         

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