RE: Multicast Design

From: Dufour, Andre <Andre.Dufour_at_PAETEC.com>
Date: Tue, 6 Oct 2009 17:05:31 -0400

I agree that using the aggregation layer approach or incorporating in to its own "service module" is one that is used a lot. Generally, I would normally suggest all features that the network brings (FWSM, ACE, etc.) be on the aggregation layer / service layer.

Of course, as mentioned, what should be done and what's in the budget can be two different things...
 
Andre

-----Original Message-----
From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf Of Paul Cosgrove
Sent: Tuesday, October 06, 2009 4:36 PM
To: Rookie Ccie
Cc: ALL From_NJ; ccielab_at_groupstudy.com; nobody_at_groupstudy.com; Charles.Henson_at_regions.com
Subject: Re: Multicast Design

The design Charles described there would be your best bet, if you have the equipment available. Rendezvous points do not normally process much extra traffic. Unfortunately there is a huge difference between what happens normally, and what can happen if there is a configuration error (or if someone wishes to cause break things). Setting the RP up on separate devices helps to ensure that unicast communicaitons are not affected by multicast problems.

Paul.

On Tue, Oct 6, 2009 at 6:19 PM, <Charles.Henson_at_regions.com> wrote:

> Rookie,
> Back in Vietnam, we had a bunch of DLSW peers that we needed to
> bring into the core. We didn't terminate them on our core 6509s (or
> 5500s) but instead had a pair of 7206s hanging directly off the core
> doing on the tunnel termination. I think that when the SRND says
> "core" that it is subject to interpretation. If you are worried about
> adding that overhead to your core hardware, then add new hardware as
> an extension to the core strictly for managing your MCast. Just a thought.
>
> Charles Henson
>
>
>
>
>
> From: ALL From_NJ <all.from.nj_at_gmail.com>
>
> To: Rookie Ccie <rookie.ccie_at_gmail.com>
>
> Cc: ccielab_at_groupstudy.com
>
> Date: 10/06/2009 12:03 PM
>
> Subject: Re: Multicast Design
>
>
>
>
>
>
> Afternoon Rookie Ccie,
>
> The thing about the core, is that it is normally fast, redundant, and
> has connectivity to all of the network. Do not place the RP somewhere
> that it is slow, or where redundancy and reachability is sketchy ...
>
> Not much burden at all to the core ...
>
> In the design guide, it looks like these are within the data path.
> For a medium size network, this is probably fine. For larger networks
> and where mcast is used extensively, you might have the RPs on
> dedicated routers attached to the core. These would be in the core
> still, fast, redundant, etc ...
>
> BTW - if you can say, what apps will you be running and to which clients?
> I
> am just curious ..., hope you do not mind me asking.
>
> HTH,
>
> Andrew
>
>
>
>
> On Tue, Oct 6, 2009 at 12:19 PM, Rookie Ccie <rookie.ccie_at_gmail.com>
> wrote:
>
> > Dear Experts,
> >
> > I'm planning to implement multicast on a medium sized campus network
> using
> > anycast RP. According to the Cisco Multicast SRND (
> > http://www.cisco.com/en/US/tech/tk828/tech_design_guides_list.html)
> > the
> RP
> > should be placed at the core of the network. Will doing this add an
> > extra burden to the core? Please share your thoughts/experiences on this.
> >
> > Rgds
> >
> >
> > Blogs and organic groups at http://www.ccie.net
> >
> > ____________________________________________________________________
> > ___ Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
> >
> >
> >
> >
> >
> >
> >
> >
>
>
> --
> Andrew Lee Lissitz
> all.from.nj_at_gmail.com
>
>
> Blogs and organic groups at http://www.ccie.net
>
> ______________________________________________________________________
> _ Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
> Blogs and organic groups at http://www.ccie.net
>
> ______________________________________________________________________
> _ Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html

Blogs and organic groups at http://www.ccie.net
Received on Tue Oct 06 2009 - 17:05:31 ART

This archive was generated by hypermail 2.2.0 : Sun Nov 01 2009 - 07:50:59 ART