Interesting multiple OSPF area dilemma

Fri Oct 1 15:48:03 UTC 1999

Sorry, but don't do the things more complex than they are. Think about
your network as about the network built ove the mixture of ATM pvc's
(and/or other ATM methods), not important is this A, B or C carriers at
all.

Area in OSPF is the way to decrease the memory and CPU routers use for the
data base calculation; AS'es in BGP are the way to split network to the
different administratively-controlled domains. You have not first not the
second reason to run from the flat model.

If you'll have the big branch with it's own internal structure, you can
consider selecting this branch into the area (if it's structure is not
used for the transit). Through it was discussed here some time ago - it's
not pleasant until OSPF have not somple hierarchy instead of fixed 2-level
one with the special _area-0_ backbone.

PS. The idea pf any dynamic protocol such as OSPF was very simple. Any
config should looks like:

 interface XX1
 	cost XXXX (for YYY traffic)
 interface XX2
	cost YYYY (for YYY traffic, may be)

...
 router PROTOCOL
	network ANY
.

Everything extra was caused by one of the two reasons - the lack of cpu or
memory (OSPF areas, mixture of OSPF or STATIC's, etc), or the necessety to
divide network administration into the different domains (company XX and
company YYY, or the base company and the branch). 

If your background carrier[s] is [are] not IP but L2 (treating ATM or FR
pvc's as
L2) carrier, it's a set of links or a set of LAN, P2P or NBMA networks.

Through I suspect you missed some detailes - elsewhere no one can explain
why did you get different IP addresses for using with the A or B ATM
carrier...
While you can run flat IGP schema, it's not nessesary at all. If you can
not, it's better to divide address space by the geographical, but not Ln-1
carrier's name, principles.

The different address blocks became important issue if you want to use
some Ln (IP in your case) provider for the transit purposes except of Ln-1
(ATM in your case) provider. Usially it's important to have Ln transit
between different geographical locations, and easy to order Ln-1 transit
in the local area (because in the local area you expances are not the link
fee, but in the long-distant transit links the cost of this links became
higher and it can cause you to use, for example, global internet as the
transit area. Don't forgot about the NAT, btw.

PS. May be I was wrong here to getting such advice, but I saw a lot of
mistakes did because the books describing different protocols forget to
explain the SIMPLE model of this protocol, and are trying to explain the
complex mechanisms the protocol use to get over the cpu or memory or
stability limitations...

Alex. /sorry for the long answer/

> Date: Fri, 01 Oct 1999 11:21:37 -0400
> From: Dustin Clampitt <jdustin at ziplink.net>
> To: nanog at merit.edu
> Cc: jdustin at ziplink.net
> Subject: Interesting multiple OSPF area dilemma
> 
> 
> Greetings:
> 
> I seek input on a decision I must make regarding using multiple areas
> in a network using OSPF as the IGP.
> 
> I have reviewed the NANOG archive messages regarding OSPF hierarchy,
> KISS principle, OSPF design, etc., but I'd still enjoy some feedback.
> 
> * We have an existing nationwide network all carried by a single ATM carrier.
>     (Carrier "A")
> 
> *  The network is flat.  Everything is area 0.0.0.0.  Currently less than 1000
>     OSPF route table entries.
> 
> * We are expanding the network via a second carrier.  (Carrier "B")
> 
> * As we do more business with the new carrier "B" we expect to swing cities
>     currently on the "A" network over to the "B" network.
> 
> * I have a fresh /18 from ARIN to apply to the build out with new Carrier "B"
> 
> * Both networks will tie into the same hubs on the east and west coasts.
> 
> The questions are:
> 
> 1. Do I even consider creating a second area "1" for the new network?
> 
>    I don't have a huge number of routers, or routes, yet.  Our existing
>    address space is highly fragmented for various reasons, but that
>    doesn't mean we shouldn't attempt to inject some order to the network
>    as we move forward.  
>     
> 2. If we are successful in moving all business away from existing carrier "A"
>     then we have to create a new area 0.  That puts us in the position of having
>     to put interfaces linking cities into the new area 0, while each city then
>     has to have a unique new area for the "local" interfaces.  I don't even
>     want to think about virtual link games as I'm a big believer in the KISS
>     principle.  (I'm lazy, and I don't expect to be the one supporting this forever.)
>     
>    How do I move area 0?
> 
>     I suppose I could start by putting all inter-city links in the new network in
>     area 0, but then right off the bat I have 2 OSPF areas in every new city.
>     That seems to be counter to much that I've read.  I expect the vast
>     majority of "local" interfaces to be stub areas anyway.
> 
>  3. Are any gains in route aggregation and fault tolerance offset by:
>      * the additional "cost" of complexity 
>      * additional CPU load necessary to process multiple areas?  
> 
> More Gory details: 
> 
> Existing network "A":
>   * East Coast hub with transit via UUNET
>   * West Coast hub with transit via SAVVIS 
>   * 16 Satellite cities.  Each city is dual homed to East/West Coast Hubs
>      via ATM
>   *  2 dozen routers in network.
>   * Currently less than 1000 OSPF routes all in area 0.
>   *  BGP4 as the I/EBGP
> 
> New network "B"
>   * connects to same east/west coast hubs as network "A"
>   * we have a fresh /18 to apply to this buildout
> 
> ---
> 
> I apologize for turning the list into OSPF design 101.  It seems to me
> to be apropos and an interesting dilemma that may be faced by others
> who inherit a network that grew without benefit of a master plan.
> 
> Actually, in deference to those list readers who I know at one time were 
> formerly involved with this network, I'm sure there was a plan, but it was
> lost before I got here.  And 2.5 years ago I probably wouldn't have recognized
> it if it came up and bit me on the butt.
> 
> I could just punt, and put it all in area 0, but I just had to ask.
> 
> Sincerely,
> 
> Dustin Clampitt
> 
> 

Aleksei Roudnev, Network Operations Center, Relcom, Moscow
(+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 230-41-41, N 13729 (pager)
(+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)