North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Interesting multiple OSPF area dilemma

  • From: Dustin Clampitt
  • Date: Fri Oct 01 11:25:03 1999


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  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.


Dustin Clampitt