I posted these questions a couple days ago as a post to an older thread. It got no response and I don't know if that was because it was an old thread, so I'm starting a new thread. If the redundancy is a violation of board policy, please forgive me.

Currently all of our network is in one big area. But, it's NOT Area 0. It's area 198.51.x.x. I can't say why - I'd have to ask the previous Network Admin. It's not even an IP range that we use.

If I add additional areas, do I have to rename the existing backbone area to 0?

If I add a new area without the backbone area being area 0, what happens?

How difficult is it to change the existing area to 0? What complications or problems could arise as a result of that change?

Can I just change all the network statements on the various routers from "network 10.x.x.x 0.0.0.255 area 198.51.x.x" to "network 10.x.x.x 0.0.0.255 area 0.0.0.0"? Where should I start?

Should I start a new router ospf process and move one network statement at a time?

Or would it be better to just continue with the single area at this point?

I have googled, but can't find any documents regarding changing an existing non-0 area to area 0.

If you have two areas and neither of them are Area0 then they won't be able to exchange LSA's between them so yes, you will need to create a backbone area.

_________________
---
David
CCIE R&S #38338, CCIP, CCNP

http://networkbroadcast.co.uk - My Blog
http://twitter.com/davidrothera

So if you do a show run you don't see under any of your interfaces a command like

ip ospf xxx area 0

_________________
Networking is much like making love to a beautiful woman
Slide your equipment in to the rack, Stick your plug in the socket, and if you have done it right at the end everyone is happy

Correct. There is no area 0. But I have learned the reason for this. Once upon a time, our network was an area within a larger OSPF network. Our ISP was "area 0" and we were "area 198.51.x.x." The ISP changed their design so we're no longer connected to an area 0, but maintain the original area number. That is how my boss explained it to me, anyway.




Thanks. Now, how to fix it...

Make the new area area 0 =)

Simple, and if it is a small network it will work. However, all it does is put off the redesign for awhile. Eventually you will have to redo everything.

-Otanx

Why do you need to change the existing area to area 0? If you're going to add another area, can't you just make that area 0?

Making the new area 0 is a suggestion I hadn't thought about... But I'm not sure that is what I want to do as it will be a stub area.

But, could I make this new area 0, then move all the existing networks to area 0, then move the new area to a different area number?

I wouldn't make the stub area area 0, this wouldn't be good.
do you have any decent spare routers? maybe you can connect
the router to the network and configure it for area 0?
ahh, but then your other area would need to connect to area zero.
but may not be such a bad idea if you have the spare router parts.

_________________
"If you're good at anticipating the human mind. It leaves nothing to chance."
-Jigsaw

On the router between the two areas put a loopback in Area 0.

-Otanx

I would slowly migrate everything to Area 0. How big is your network? If it's not too big you can do it all in a couple of hours one night

_________________
www.mellowd.co.uk/ccie/

By the moment now you might have realised that you need the Area 0 (backbone area) if u need multi area OSPF. All non zero areas must be attached to the area zero.

I would in your case create a second OSPF process and add all the network statements in area 0. After this I would delete the other OSPF process. This will yield the lest downtime or no downtime at all. Anyway before deleting the OSPF process make sure that you check the OSPF database.

So you're saying basically duplicate the existing OSPF process for Area 198 and call it Area 0. Then I can delete Area 198?

I would need to build that Area 0 on all of the routers first before I start deleting the old Area 198, correct?

The effect would be that all routers would temporarily be ABRs between Area 0 and Area 198... then Area 198 goes away?

The backbone cannot be configured as a stub area.

_________________
"Where I excel is ridiculous, sickening, work ethic. You know, while the other guy’s sleeping? I’m working. While the other guy’s eatin’? I’m working. While the other guy’s making love, I mean, I’m making love, too. But I’m working really hard at it."

correct

NOT correct

If you are having 2 different OSPF process on a single router, it's like having two different routing protocols. So it will not be an ABR. an ABR by definition is a router who is having an interface in Area 0 and another area.

On the new OSPF process you could set the admin distance to 255, this allows for you to get all the routers in the right area but they wouldn't be installed into the routing table so no downtime.

Once you were ready you would need to lower the AD on the new process to bring the routes into the routing table, you could do this by raising the old process to higher than the OSPF defaults and then bring down the new process to the default AD.

If all this is done correctly then you shouldn't even see any downtime.

I'm sure there was an article I read ages ago on changing routing protocols on a live network which is basically what you are wanting to do.

EDIT: Yup, thought there was http://stack.nil.com/ipcorner/ChangingRoutingProtocol/

_________________
---
David
CCIE R&S #38338, CCIP, CCNP

http://networkbroadcast.co.uk - My Blog
http://twitter.com/davidrothera

David, I studied that document and felt pretty comfortable going in that direction. But I had a chat with my Cisco SE about it yesterday and he recommended not doing that. He was a little unsure of what would happen with 2 instances of OSPF using the same interface.

I'm in a situation where almost all of my routers are directly connected to one of the core L3 switches. So his recommendation was to just take it one switch at a time and rename the existing area to 0. As long as I'm consoled in to the core switch they are all connected to, I should never lose connectivity to them during the process.

No offence but just because your SE 'has a bad feeling' doesn't mean anything in my experience, my recommendation if possible would be to try it for yourself if you have any spare/lab devices hanging around.

_________________
---
David
CCIE R&S #38338, CCIP, CCNP

http://networkbroadcast.co.uk - My Blog
http://twitter.com/davidrothera

there is probably a good reason why he's a SE and not a NE

_________________
"If you're good at anticipating the human mind. It leaves nothing to chance."
-Jigsaw

From what I've read, an interface can only be active on one OSPFv2 process. I've tried it before on a test lab and the second instance of OSPF remained "Inactive" even after I removed the first instance of ospf and cleared the ospf process. I had to shutdown the interfaces and bring them back up for them to even start sending hellos to each other.

Here's an explanation I found in cisco's support forum when I was trying to figure out why it wouldn't work:

Thank you for sharing your experience, prtech!

And I'm not going to say my SE knows everything, but he knows a lot more than I do and has never steered me wrong. Sure, he could be wrong from time to time just like anybody else, but he has earned my trust.