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

[Adam Vitkovsky]

1. 
Last time I compared these, in regular IOS ISIS had more knobs than OSPF and
vice versa in XR. 
But what really matters is the versatility of ISIS and adaptability to new
protocols/features as Mark mentioned. 

2.
As Mark mentioned customer tails can be hooked up via two VLANs one going
via 4948(A) to 7200(A) and the other one via (B) path. 
Once you'll have the CE hooked up to two separate PEs, you can than rely on
fast failover provided by dynamic routing. 
Don't forget to use per PE/VRF RDs. 

Since you don't own the L2 access/aggregation an extra(backup) VLAN for a
particular CE will almost certainly result in an additional cost for you
which translates into premium service for customer. 



adam
-----Original Message-----
From: cisco-nsp [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of
CiscoNSP List
Sent: Tuesday, November 05, 2013 10:39 PM
To: mark.tinka at seacom.mu
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] ISP / MPLS "POP" design

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/