All things related to multicast

["Curtis, Bruce" <>]

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