All things related to multicast

["Curtis, Bruce" <>]

On Jul 12, 2011, at 9:50 AM, Curtis, Bruce wrote:

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

  We verified that the bug still exists in 12.2(58)SE1.

Cisco's site says that it is fixed in

15.0(4.1)SID
15.0(1)SE
12.2(55)SE4

We haven't tested 12.2(55)SE4 yet.

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

---
Bruce Curtis                         

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