[c-nsp] OSPF area design question

Peter van Oene pvo at usermail.com
Tue Aug 31 09:14:37 EDT 2004


At 04:41 PM 8/30/2004, Dan Armstrong wrote:
>We too have a similar situation.  We opted to make a whackload of OSPF areas.  
>I am very curious if this design is going to eat up some resource 
>unnecessarily.
>
>I can't quite figure out why in a "real"  NSSA scenario that other routers in 
>the same area need to know anything about other routers in the stub area, 
>since the only path anywhere else is up to the distribution layer anyway, 
>which is handled with the default route that gets advertised down...

spf comes to mind.


>Dan.
>
>
>
>On Monday 30 August 2004 16:37, Marcel Lammerse wrote:
>> Ok, if you have that area 1 with 15 routers. Would it be a good idea to
>> keep them all in one area, or would it make sense to assign 15
>> different area numbers and make each of them a separate area (NSSA in
>> this case). Because, I figured, an update from one of the router will
>> be flooded throughout the entire area which is totally unnecessary.
>>
>> I like to know whether the extra configuration and administrative
>> overhead is worth saving on unnecessary update floods and cpu cycles
>> processing them.
>>
>> On Aug 30, 2004, at 9:47 PM, James Hampton wrote:
>> > The way I'm reading this is that you have three hub routers connected
>> > like  points on a triangle, with each point having 15 or so spokes? If
>> > this is the case I would make the top router(or the one in the middle)
>> > area 0 and the others 1 and 2 or what ever numbering scheme you come
>> > up with. Than address each area with contiguous blocks so that you can
>> > summarize and keep the routing table as small as possible. The spokes
>> > could be "stubby" sense they have only one way out.
>> >
>> > James
>> >
>> >
>> > On Mon, 30 Aug 2004 17:54:35 +0200 (CEST), Marcel Lammerse
>> >
>> > <lammerse at xs4all.nl> wrote:
>> >> Hi,
>> >>
>> >> I have a hub-and-spoke network, for which I'd like to use OSPF as a
>> >> routing protocol. The spoke sites will advertise their networks to
>> >> the hub and receive a default route from the hub.
>> >>
>> >> A common piece of advice in OSPF design literature, is to use
>> >> different
>> >> area numbers to prevent unnecessary LSA updates from flooding to
>> >> routers
>> >> that don't need the updates and to avoid the cpu processing overhead.
>> >>
>> >> The total network has some 50 routers.  There are 3 inter-connected
>> >> hubs
>> >> and some 15 routers per hub. The way I see it, I can do two things:
>> >>
>> >> 1.      assign a lot of area numbers to prevent the LSAs from
>> >> propagating
>> >>        through to routers that don't need them. However, this leads
>> >> to a
>> >>        relatively complex configuration.
>> >>
>> >> 2.      accept the, potentially small, bandwidth waste and don't care
>> >>        about the cpu overhead (we're talking 2600XMs here).
>> >>
>> >> Option 1 just doesn't seem worth it. Could someone provide some
>> >> advice,
>> >> experience or tips?
>> >>
>> >> Thanks.
>> >>
>> >> -Marcel
>> >>
>> >> _______________________________________________
>> >> 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/
>>
>> ---
>> "..the price to pay for teenage sex is pretty high--
>> unwanted pregnancy, disease, and ending up with one ear
>> bigger than the rest because it's always cocked toward
>> the door in case the parents come home early."
>>                                                                               - Michael Moore
>>
>> _______________________________________________
>> 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/



More information about the cisco-nsp mailing list