All things related to multicast

[Brent Draney <>]

This exact problem took out LBL's dns servers that were still on
10bT ports.  D'oh.  Snooping got turned on really fast.

Brent

> 
> It's very simple, really.  When the oddball device connected to an
> Ethernet port on some far node of the campus network stops working
> because it cannot absorb 20 Mbps of multicast traffic that it receives
> because of switch flooding, they turn multicast off....hey, everything
> was 'fine' before we turned it on, right?  I've seen it happen...circa
> 1997 print servers. With thousands of ports in a local network, no one
> really knows what's connected any more than you know what's connected to
> the power grid.
> 
> They conclude that multicast causes problems.  Same when their config
> causes high bandwidth multicast to be forwarded to a T1/E1 WAN port.
> Lack of planning, lack of understanding, and all too often lack of
> effort gives 'multicast' a bum rap.
> 
> I think it is dangerous to suggest flooding is okay.  It's okay in a
> lab, but not in a production network.
> 
> /rich
> 
> 
> 
> -----Original Message-----
> From: Leonard Giuliano 
> [mailto:]
>  
> Sent: Monday, May 22, 2006 12:01 PM
> To: Richard Mavrogeanes
> Cc: Joel Jaeggli; Alan Crosswell; 
> 
> Subject: RE: IPV6 Multicast
> 
> 
> It strikes me as odd that lack of snooping could CAUSE mcast to not be 
> deployed and used.  Lack of snooping is only a problem when there's too 
> much mcast (and one could argue that's a good sign for mcast deployment-
> 
> there's too much mcast!).
> 
> It's also been my experience that operators (and humans in general) are 
> generally not proactive enough to delay the deployment of a compelling 
> service bc of the anticipation of a potential problem down the road.
> It's 
> usually some other, more pressing reason.
> 
> -Lenny
> 
> On Sat, 20 May 2006, Richard Mavrogeanes wrote:
> 
> -) Joel,
> -)  
> -) Yes, MLDv2 snooping...but this may be too limiting a statement
> because vendors can/should implement what works for them to enable
> end-to-end IPV6 multicast. Some vendors do some proprietary things to
> enhance multicast behavior I seem to recall, but the result is
> consistant with snooping...that is, you can join a group the switch
> already has without a trip to the router, flooding is avoided, and group
> leaves are pretty quick thus avoiding local oversubscription.
> -)  
> -) We have multicast-enabled hundreds of colleage and K-12 networks in
> the last few years, as well as district-level networks that interconnect
> many schools.  To your point, there remains FUD on the part of the local
> IT manager with regard to multicast rollout...but we've been able to
> overcome these objections and I would say multicast is at last becoming
> conventional wisdom.  I think this is true because it works when
> properly deployed and gives the deploying institution capabilities
> otherwise virtually impossible.
> -)  
> -) My concern is that those forward-thinking institutions planning a
> migration to IPV6 will encounter the same trouble the industry as a
> whole has only recently begun to overcome with IGMPv2 and IGMPv3.  I
> think I'm hearing it's not possible to deploy IPV6 multicast in any sort
> of reasonable end-to-end way...yet.  Please keep in mind that my
> perspective for this thread is largely inside the enterprise, not so
> much the WAN.
> -)  
> -) /rich
> -)  
> -)  
> -) 
> -)    -----Original Message----- 
> -)    From: Joel Jaeggli 
> [mailto:]
>  
> -)    Sent: Sat 5/20/2006 3:08 PM 
> -)    To: Richard Mavrogeanes 
> -)    Cc: Alan Crosswell; 
> 
>  
> -)    Subject: Re: IPV6 Multicast
> -)    
> -)    
> -) 
> -)    Richard Mavrogeanes wrote:
> -)    > Alan,
> -)    > 
> -)    > Well, the next release supports IPV6, and perhaps multicast
> too.
> -)    > 
> -)    > The trouble/question is local Ethernet switch support
> ("snooping" behavior), and I'm hoping someone has some war stories to
> share.  It was bad enough getting the switch vendors fully onboard with
> IGMP, and I wonder where they are with IPV6 multicast.  Obviously, IPV6
> is not so useful if it can't reach the end user (desktop).
> -)    
> -)    By "snooping behavior" I assume you mean mldv2 snooping?
> -)    
> -)    It always seems like people are looking for a reason to not
> deploy this
> -)    (foo multicast technology).    "If we just had igmpv2/v3/mld/v2
> capable
> -)    switches there'd be no impediment to use rolling it out."
> -)    
> -)    The fact of the matter is l2 switching hardware will almost
> always
> -)    evolve more slowly than host stacks or routers. Looking inside
> ethernet
> -)    frames is an expensive exercise for most l2 switches.
> -)    
> -)    What do you do with an elephant with three balls?
> -)    
> -)    Walk it, and pitch to the giraffe...
> -)    
> -)    > /rich
> -)    > 
> -)    >
> -)    >       -----Original Message-----
> -)    >       From: Alan Crosswell 
> [mailto:]
> -)    >       Sent: Sat 5/20/2006 12:54 PM
> -)    >       To: Richard Mavrogeanes
> -)    >       Cc: 
> 
> -)    >       Subject: Re: IPV6 Multicast
> -)    >      
> -)    >      
> -)    >
> -)    >       Abiline and most of the gigapops support it.  There are
> some issues with
> -)    >        some international networks not yet support embedded
> RP.  Campuses are
> -)    >       pretty far behind.  NYU is one of the few that has done
> v6 multicast
> -)    >       with NYSERNet.  In the first ever v6 multicast hands on
> workshop in
> -)    >       Albuquerque a few months ago, we viewed content that was
> being multicast
> -)    >       from Syracuse.
> -)    >      
> -)    >       Put it in a product and I'll have an excuse to replace
> my Vbrick 1200's:-)
> -)    >      
> -)    >       /a
> -)    >      
> -)    >       Richard Mavrogeanes wrote:
> -)    >       > I'd like to explore this group's experience with IPV6
> multicast, in particular, what do we believe is the current state of the
> Internet2 backbone network and what do we think is the state of
> enterprise routers and switches to allow it?
> -)    >       >
> -)    >       > Looking forward to an interesting thread...
> -)    >       >
> -)    >       > /rich
> -)    >       >
> -)    >      
> -)    >
> -)    
> -)    
> -)    --
> -)    -------------------------------------------------
> -)    Joel Jaeggli 
> ()
> -)    GPG Key Fingerprint:
> -)    5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2
> -)    
> -) 
> -) 
> 
>