[c-nsp] OSPF NSSA Question

Mon Oct 4 04:01:26 EDT 2004

hello,

just an idea:
  OSPF carrying infrastructure routers, BGP carrying customer routes
That way you have a quickly converging, small-databse, no-need-to-filter, redundant, nice, well-behaving, etc IGP
That way you have a robust, scalable, nicely filterable, well-behaving etc EGP.

  - osfp carrying infrastructure routes (loopbacks, p-to-p links)
  - full mesh iBGP between the core and distribution routers (as i understand there are only few of them,
or if ther are more, you still can go for route-reflectors)
  - distribution routers as RR for access routers.
  - you might want to tweak the bgp scan & import timer

sill a pro:
  BGP has much more features for those having security in mind, like remotely triggered blachole filtering,
with uRPF loose check, sinkhole routing.

rgds
  -zoltan.

-----Original Message-----
From: Oliver Boehmer (oboehmer) [mailto:oboehmer at cisco.com]
Sent: Monday, October 04, 2004 8:53 AM
To: Dan Armstrong; Jay Hennigan
Cc: cisco-nsp
Subject: RE: [c-nsp] OSPF NSSA Question

Some comments here:

I don't see much of an issue with 100 routers within the area, assuming
that the inter-area links (the links connecting the 3550 to the 6509)
are stable so we don't need to run SPF too often. 
The overhead of 100 areas per 6509 is pretty large, we'd need to
maintain 100 area databases, etc. I wouldn't do it. You can still
segment your access area into a handful of areas, but I'd consider 100,
50 or even 20 way too large..

Flapping customer routes are Type-7 routes coming and going. This will
not trigger an expensive full-SPF.
How many routing up/down events are you expecting per second? I don't
know if "IP Event Dampening" feature is supported on the 3550, this
could help for constantly flapping interfaces..

The # of unicast routes a 3550 can support depends on some other
factors, please check out
http://www.cisco.com/univercd/cc/td/doc/product/lan/c3550/1214ea1/3550sc
g/swadmin.htm#47446. But with 2400 customers (100*24) per area (assuming
all 100 routers within the area) and 2-3 routes per customer we are
still well below the default template number of 12000 routes. But if you
are really expecing a large four digit number of customer routes, iBGP
is more suitable, IGPs are generally not designed for a very large # of
routes.

Be aware that there will be only one NSSA ABR (i.e. one 6509) which
translates Type-7 to Type-5 and floods them within your area 0/backbone.
This will impact load-sharing capabilities from the backbone into your
NSSA area which might blow your capacity planning. 

Some folks mentioned EIGRP: Make sure you know what route flaps can do
in an EIGRP network, in this case you might want to investigate features
which limit the query boundary like EIGRP stub or summarization.

my 2c

	oli

cisco-nsp-bounces at puck.nether.net <> wrote on Monday, October 04, 2004
3:01 AM:

> Numbers?  Ok.  Each "access" router is a 3550, 24 ports, 24 customers.
> Each dist router is a 6509 with MSFC2.
> 
> The economics of the design should scale up to about 2000 to 3000
> customers per 6509, so that is about 100 or so 3550 switches
> hanging on
> it, which with an area for each would be 100 or so OSPF
> areas, each with
> 1 router each.  The churn of routes would be fairly high.... larger
> customers tend not to flap, but smaller customers unplug, turn stuff
> off, etc. quite often. 
> 
> I guess I am so concerned about large routing tables on the access
> routers, since 3550s are not really designed for large
> routing tables.
> Each 3550 is attached to each 6509 with a gig link, setup as a trunk,
> and vlan interfaces in the 6509 and a vlan interface in the 3550.  (I
> am oversimplifying the design a bit for clarity... each 3550 is
> actually hung off of 2 6509s) 
> 
> We "try" and keep the cusotmer's subnets as contiguous as
> possible, but
> as people move around the network, summarization becomes difficult.
> 
> I have no problem with making an OSPF area for each access
> router... I
> have been told that I might blow up the 6509 pretty quickly, but who
> knows. 
> 
> I am also considering if EIGRP would be a better way to
> implement this....
> 
> 
> 
> 
> 
> Jay Hennigan wrote:
> 
>> On Sun, 3 Oct 2004, Dan Armstrong wrote:
>> 
>> 
>> 
>>> Yeah, I guess that's why I am confused.... why do the routers in the
>>> stub/nssa area need any information other than a default route?
>>> 
>>> 
>> 
>> Because by definition OSPF routers within an area will all have the
>> same link-state database.  Route aggregation is expected to be done
>> between areas. 
>> 
>> You could try a distribute-list in on each access router limiting it
>> to placing the default and/or your major network(s) into its routing
>> table.  I'm not sure if this would break things, probably best to
>> try it in a lab scenario first. 
>> 
>> 
>> 
>>> The access routers are all in 1, non zero area.  It seems redundant
>>> to me that they need to learn routes from other routers in their
>>> area, since they all point back to the same place as the default
>>> route (the dist router).... If I setup each access router in a
>>> different area, I get exactly the behaviour I want, but that seems
>>> ridiculous to have an area for each access router - I would blow up
>>> my dist routers pretty quickly with too many areas, no?
>>> 
>>> 
>> 
>> It depends.  How many access routers, and how many customer routes
>> per each?  The routing table of the distribution table will be the
>> same isize regardless, and it will still need to do the same
>> housekeeping in terms of hello packets, etc. if each access router
>> is coming in on a separate logical interface (VLAN?).  If all of the
>> access routers are coming into the distribution router on a single
>> logical network, making them all different areas can get messy.
>> 
>> How stable is the network?  If customer interfaces don't flap much
>> causing routes to be withdrawn and then redistributed, the extra
>> overhead of the routing table may not be a big deal.  On the other
>> hand, different areas shouldn't tax the distribution router
>> excessively (again, you haven't given us an indication about numbers
>> of routes/routers and how you think this will scale) and will result
>> in a much cleaner routing table in each access router.  Route flaps
>> on one access router won't affect any others. 
>> 
>> Multiple areas would allow lightweight access routers but might
>> require a beefier distribution router, but I don't think it will
>> need to be much beefier depending on what the numbers are.  Under 30
>> or so areas should not be a big deal at all.  Hundreds might. 
>> "Whack-O" doesn't show up on my calculator.  :-)  More areas mean
>> more configuration on the distribution router, of course.  The load
>> on the distribution router might actually decrease with multiple
>> areas, particularly if the network isn't stable.  With a single area
>> the distribution router is processing a lot of LSAs to all of the
>> access routers every time a cuatomer route changes. 
>> 
>> How you intend to scale it, whether your subnets are logically able
>> to be summarized, etc. can all influence the design.
>> 
>> 
>> 
>>> I was looking into the stub feature in EIGRP, and it apperas to
>>> behave more like I want - but there is no way to prevent routers
>>> neighbouring in EIGRP that I don't want to neighbour, so for a
>>> bunch of other reasons that will send this off topic, I was hoping
>>> not to use EIGRP.... 
>>> 
>>> Even if the area is setup totall stubby (no summary) or not, the
>>> same effect occurs.  The intra area routes still get propagated...
>>> 
>>> 
>> 
>> I think that in a totally stubby scenario, you might have issues with
>> redistribution of the static customer routes back to the backbone.
>> Are you extending OSPF to the customer premise router or statically
>> routing the customer subnet on the access router and redistributing?
>> 
>> 
>> --
>> Jay Hennigan - CCIE #7880 - Network Administration - jay at west.net
>> WestNet:  Connecting you to the planet.  805 884-6323      WB6RDV
>> NetLojix Communications, Inc.  -  http://www.netlojix.com/
>> 
>> 
> 
> _______________________________________________
> 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/

Ez az üzenet és a hozzá kapcsolódó fájlok, tervezetek kizárólag a
Címzettnek szólnak, a bennük foglalt információk bizalmasak, melyek
titokban maradásához a Synergon Informatika Rt.-nek jogilag méltányolható
érdeke fuzodik. Amennyiben valamely hiba folytán Ön nem a címzettje ennek a
levélnek, kérjük, semmisítse meg, és értesítse az üzenet küldojét. Az
üzenet az elküldés elott vírusellenorzésen esett át, de a vírusmentességére
nincs semmilyen garancia, ezért kérjük, ellenorizze azt!

DISCLAIMER

This e-mail and any attached files are confidential and may be legally
privileged. The content of this e-mail is subject of efforts by Synergon to
maintain its confidentiality. Also this e-mail is intended for the sole use
of the individual or entity to whom it is addressed. If you are not the
addressee, and received this transmission in error please delete this
e-mail and notify its sender immediately. This e-mail message has been
checked for computer viruses but it could still be infected. Please test it
for viruses before use.