[nsp] Stub Area design question

[Josh Fleishman]

If I'm understanding this correctly, there are a few options here:

1)  Keep it as is and just scale the memory in your access routers and
distribution routers so they can handle all of your Type 7 LSA's.  

2)  You could just trunk all of your customer connections up to your
Distribution routers and do all of your redistribution (connected and/or
static) there, along with your BGP.  This can be done within each pop and
you can play with the metrics for some traffic engineering.  Essentially
your 3550's become purely layer2 boxes.

Personally I like #2 since it eases your administration by reducing the size
of your routing domain and it pleases the boss since it allows you to use
pure layer2 boxes at your access layer and therefore save some cash. There's
always a trade off, and here it's your reliance on trunking which
fortunately Cisco does well.

 However, #1 is fine especially if your LSDB remains a reasonable size.
Adding addition areas is more than likely going to be overkill.  You want to
maintain a small LSDB but the memory for your routers is fairly cheap and
you probably already have enough to handle an NSSA, unless your
redistributing your BGP routes into your IGP.

Hope this helps..

Josh

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Dan Armstrong
Sent: Sunday, July 18, 2004 6:30 PM
To: Howard C. Berkowitz; Cisco-NSP
Subject: Re: [nsp] Stub Area design question

Thank you for your reply.

No, we are not running any routing protocols with the downstream customers.

BGP Speaking customers get VLANed up to the distribution layer.

I am likely over complicating this.  The scaling issues are a tad different 
than a dial network, in that the access routers are actually L3 switches 
(like 3550s) so they have a relativley small number on each, but there are 
lots of them.

The two distribution layer routers are actually in separate POPs, and every 
ethernet edge switch is physically and logically connected to both 
distribution routers.  A particular Ethernet switch is geographically closer

to one POP or the other, so with OSPF injecting default routes from both 
sides, I would manually play with the metrics to balance traffic between the

dist. routers.

The other issue is that I cannot anchor big blocks of address space on each 
access router, like you might in a dial scenario.  Customers move around the

city, and expect to take their address space with them.  Address space is 
anchored on our metro distrubution routers, and is not portable between
metro 
areas, only within.

I was hoping that a dynamic routing protocol would let me just plunk a 
customer's netblock on an interface of the access router, and have that 
advertised up to the dist. routers, without additional configuration.

The dynamic routing protocol injecting the 2 default routes also gives me
the 
dynamic failover if a link, dist. router or entire POP were to fail.

I think I should probably go buy myself a copy of your book.
:-)




On Sunday 18 July 2004 17:08, Howard C. Berkowitz wrote:
> At 3:53 PM -0400 7/18/04, Dan Armstrong wrote:
> >I have a desgin question about IGP routing protocols in a stub area.
> >
> >Picture a generic service provider network.  Several access routers to
> > which customers are attached.  All of them dual homed up to 2
> > distribution layer/ metro core routers.  All of the access routers are
in
> > the same ospf area. Each city (usually comprised of 2 Metro POPs) is 1
> > OSPF area.
>
> Do the customers just default to you, or do you do BGP or even IGP
> peering with them?
>
> >The area in which the access routers are is an nssa totally stub area.  I
> > just want to inject a default route from each of the distribution layer
> > routers down to the access routers.  I want to advertise the C and S
> > routes UP from the access routers, I redist static subnets, redist conn
> > subnets and we're good to go.
>
> I'm losing track of where you are redistributing. If it's on the
> distribution router, I'm wondering if you really should be running
> OSPF at all at the access tier, but rather static routing (with
> appropriate floating statics for failover).
>
> Remember that you are either going to have to assign PA address space
> to the customer, or know what the customer needs. That information is
> going to go into a database somewhere.  If you look at a presentation
> I did at NANOG, http://www.nanog.org/mtg-9811/ppt/berk/index.htm, you
> will see the skeleton of how you could automatically generate the
> static routes (and other good things) for the access and distribution
> tier.  Doing things this way takes away one of the common objections
> to static routing: "it's too maintenance-intensive."  (Shameless plug
> -- I go into greater detail in my book, _Building Service Provider
> Networks_ [Wiley]).
>
> >The only thing about this design that bothers me is that since all of the
> >access routers are in the same area, they all get each other's intra area
> >routes.  Access router A can only ever reach access router B through the
> >distribution layer anyway.  Each access router does not care what blocks
> > are anchored on other access routers, they just need the default
> > route(s).
> >
> >Should each access router be in it's own area?  Would having a crapload
of
> >ospf areas on the distribution layer routers knock some limit over?
> >
> >Could I write a bunch of messy route maps to handle this?
> >
> >Am I missing something really dumb and obvious?
>
> To me, the fundamental question is whether dynamic routing buys you
> anything at the access tier. Inserting static routes to the customer
> blocks in the distribution router, and redistributing static, may be
> all you need.
>
> I say "may", because I don't know if there's any dynamic routing
> exchange between your access routers and the customer routers. If
> there is, then the problem gets more complex.

_______________________________________________
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/