All things related to multicast

[Frank DiGravina <>]

On 1/11/11 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
>
>
>
>
> > 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
Ray,

The bug id - CSCtl51859 - does not exist according to cisco's
Bug Toolkit.  Spelling?


Frank


--
Frank DiGravina
University of Minnesota
Networking&  Telecommunications
Network Operations
Phone: 612-626-9074
Cell:  612-386-0449
E-Mail: 

Helpline: 612-301-HELP