[c-nsp] ISP / MPLS "POP" design

[Phil Bedard]

IS-IS can scale to a larger number of devices in a single "area" and
overall network.  Really depends on how many devices you are talking
about.  For smaller deployments it usually comes down to who is supporting
the network and what they are more familiar with.

So you are backhauling most of your customer endpoints from another
carrier's Layer2 network, correct?  You could re-create the L3 interfaces
on both PE devices and use a mechanism like EEM (embedded event manager)
to keep the backup link to the other 7200 down until the link to the
primary 7200 failed. That way the L3 interfaces would be down until a
failure occurred, and no manual intervention would be needed.

Another option may be to use flex-links on the 4948 and then use a
protocol like 802.3ah.  The backup flex-link would block traffic from
going to the 7200 so the 802.3ah PDUs never make it to the 7200 and it
treats the interface as down.  That's a long-shot I don't really know if
that's supported at all.

Otherwise you could use VRRP on the 7200s if you have a /29 to burn for
each customer. 

There are other solutions on newer boxes/software like multi-chassis LACP,
but I don't think anything you listed there supports it.

Phil 

On 11/5/13, 4:39 PM, "CiscoNSP List" <cisconsp_list at hotmail.com> wrote:

>Hi,
>
>Have a couple more questions on this :)
>
>1. I notice that a number of people use IS-IS rather than OSPF - Is there
>benefits to using one vs the other?
>
>2. Majority of customer tails will be supplied via vlans (On Carrier
>AGG's) - Typically we would have two AGG's from two different carriers
>per POP. I was looking at using 2 x 4948's to terminate the Carrier AGG's
>(Trunk ports), then trunk ports to the 7200's(PE's) for L3Any
>recommendations/advice on how to provide redundancy for these customer
>tails?
>i.e.
>Carrier A AGG to 4948(A)
>Carrier B AGG to 4948(B)
>
>4948(A) then has trunk links to both 7200(PE A) and 7200(PE B), and same
>with 4948(B) - Is an acceptable setup to have Carrier A L3 Ints on
>7200(A) and Carrier B L3 Ints on 7200(B), and then if we were to lose
>(for example) 7200(A) we trunk Carrier A's vlans to 7200(B) and create
>the dot1Q Ints to restore service?
>
>Thanks in advance for any feedback/advice.
>
>
> 
>> 
>> > From: mark.tinka at seacom.mu
>> > To: cisconsp_list at hotmail.com
>> > Subject: Re: [c-nsp] ISP / MPLS "POP" design
>> > Date: Thu, 31 Oct 2013 04:06:27 +0200
>> > CC: cisco-nsp at puck.nether.net
>> > 
>> > On Wednesday, October 30, 2013 11:35:59 PM CiscoNSP List
>> > wrote:
>> > 
>> > > Thanks Mark.
>> > > 
>> > > So to clarify - If I run 2 (7201's) as RR's, they would
>> > > take the full tables from the IPTransit 7200's(POPA),
>> > > plus all customer global IP's, plus all VPNv4
>> > > routes(From POPA+B+C)?
>> > 
>> > That's right.
>> > 
>> > The 7201's CPU is very capable. It tops out at 2GB of RAM,
>> > and should be able to handle your current deployment just
>> > fine.
>> > 
>> > > If that's the case - Do you filter what routes the RR's
>> > > advertise to RR clients?  i.e. POPA has the 2 7200's
>> > > with IPTransit full table, do the RR's advertise the
>> > > full table to the 7200's at POPB + C?
>> > 
>> > That's a design decision.
>> > 
>> > Some operators don't filter in iBGP, ensuring every router
>> > has, pretty much, the same view of the state of BGP in the
>> > core.
>> > 
>> > Other operators, like myself, implement network-wide routing
>> > policy in iBGP, which is easiest done in the route
>> > reflectors, as that is how different routers performing
>> > different functions learn (which) routes (they should be
>> > receiving).
>> > 
>> > If you're not sure what to do, go simple and evolve the
>> > configuration as your network does so.
>> > 
>> > Cheers,
>> > 
>> > Mark.
>>  		 	   		  
>> _______________________________________________
>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
> 		 	   		  
>_______________________________________________
>cisco-nsp mailing list  cisco-nsp at puck.nether.net
>https://puck.nether.net/mailman/listinfo/cisco-nsp
>archive at http://puck.nether.net/pipermail/cisco-nsp/