All things related to multicast

[Multicast maillist <>]

Was this issue persistent or transient for a period of 100s of seconds after upgrade and reboot?

On Wed, Nov 10, 2010 at 10:14 PM, 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