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@ziplink.net> To: nanog@merit.edu Cc: jdustin@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)