Changing the OSPF Area 0 For Another

[Hannibal]

Hi Community, the best of internet !!!!

Dear all, let me to open this new topic

We have a project to change the OSPF areas of a Network of switches/routers currently all in area Zero (0).  The network was growing and now is the time to put things as they should be.

We want to know what is the best practice and experience in this type of change. The final network will finally be made up of 5 areas plus area "0" or the backbone area.

Each area will be made up of its ABR switch/router with two connections to area zero (0) and one connection to the new area where there will be between 15 and 20 switches/routers belonging to the area. The figure shows a general diagram of the network.

I would like to know about this thread what has been your experience and best practice:

1. I have a doubt: on the side of the new areas, when should I change the announced networks in the new area within the OSPF protocol; it would only suffice to delete the command, for example:

   no network 10.0.0.0 0.0.0.3 area 0

    and then apply the command

   network 30.30.30.0 0.0.0.3 area 51??

2. I am thinking of starting the area change in the router/switch closest to the ABR router or the best practice would be in the one furthest from the ABR router?

3. Does anyone of you have experience in making changes remotely without the need to go to the site, fearing losing the remote connection?

The final diagram network is as follow:

 

Thank you very much, Communityand I hope to know about your experiencie about this topic

Hann

[balaji.bandi · Accepted solution]

If the design you looking to move the address in different area, that is the requirement.

make sure you when using the syntax use correct IP  (both are different - example)

or example:

no network 10.0.0.0 0.0.0.3 area 0

and then apply the command

network 30.30.30.0 0.0.0.3 area 51 ??

when you change area - the routing and change and convergence take place, if this critical or (any network) - suggest to perform the task in maintenance window.

as long you have other source of reachabilioty to device, not matter which side you change first.

[Hannibal]

Thank you very much, Balaji

Yes, The correct syntax is

no network 10.0.0.0 0.0.0.3 area 0

and then apply the command

network 10.10.10.0 0.0.0.3 area 51

Hann

[Hannibal]

Hi Balaji, sorry

I will correct again (the second byte)

The correct syntax is

no network 10.0.0.0 0.0.0.3 area 0

and then apply the command

network 10.0.0.0 0.0.0.3 area 51

Hann

[Joseph W. Doherty]

"Does anyone of you have experience in making changes remotely without the need to go to the site, fearing losing the remote connection?"

I have quite a bit experience dealing with remote sites without any remote site network support.

On Cisco platforms, generally, I used a timed reload in case something goes so wrong I lose access to the device.  (Later platforms, though, support an [optional?] rollback feature, which it too, might be triggered on a time basis [?].)

I also made changes, to remote platforms, that while applying some of the config it will break a remote connection.  For those, I load a small file on the remote device, and copy it into the

running config

as a single command.

Occasionally, (like when doing remote IOS upgrades) the device hangs.  So, I also plan for what to do for those cases (which usually entails getting someone to that site (if that happens), hopefully avoiding impacting the remote network during normal usage hours).

"I am thinking of starting the area change in the router/switch closest to the ABR router or the best practice would be in the one furthest from the ABR router?"

Unsure it make much of a difference, as you will lose remote access to devices as you "break" the OSPF topology until it's setup, correctly, for the new area topology.  Usually I've done it from the edge inward.

Tip: remember, you should be able to telnet between directly connected devices, assuming they both have IPs for a shared network on their shared link.

"Each area will be made up of its ABR switch/router with two connections to area zero (0) and one connection to the new area where there will be between 15 and 20 switches/routers belonging to the area. The figure shows a general diagram of the network."

From your diagram and description, it's unclear (to me) where the ABRs are.

For example, are the links between routers 1.1.1.1, 2.2.2.2 and 3.3.3.3 in area 0 or area 10?

"I have a doubt: on the side of the new areas, when should I change the announced networks in the new area within the OSPF protocol; it would only suffice to delete the command, for example:

no network 10.0.0.0 0.0.0.3 area 0

and then apply the command

network 30.30.30.0 0.0.0.3 area 51??

I have doubt as you're also changing a network prefix?  You also realize that OSPF network statements don't need to directly match network prefixes, because they match like ACL ACEs?

[Hannibal]

Hi Joseph

Excellent your comments

About "I also made changes, to remote platforms, that while applying some of the config it will break a remote connection.  For those, I load a small file on the remote device, and copy it into the running config"

This is not clear to me how you can do this to recover a connection lost due to a misconfiguration done remotely

About "From your diagram and description, it's unclear (to me) where the ABRs are.

For example, are the links between routers 1.1.1.1, 2.2.2.2 and 3.3.3.3 in area 0 or area 10?

I mean, for example, router, 1.1.1.1 and 2.2.2.2 have a P2P subnet (vlan) shared with the router 3.3.3.3. That subnet is configured in the area "0". At the same time the router 3.3.3.3 has an interface or subnet belonging to the area "10". And similarly, with routers 4.4.4.4, 5.5.5.5 and other routers for two other areas not shown in the figure.  Currently all routers belong to area "0"

About the prefix, Really this was a typing error.

The correct is a follow:

no network 10.0.0.0 0.0.0.3 area 0

network 10.0.0.0 0.0.0.3 area 51

Thank you very much, Joseph

[Joseph W. Doherty]

"This is not clear to me how you can do this to recover a connection lost due to a misconfiguration done remotely"

Recover connection - it doesn't - that's what I use a time reload for.  What this technique does is allow remote configuration changes, in a way, that otherwise would cause a lost connection.

"I mean, for example, router, 1.1.1.1 and 2.2.2.2 have a P2P subnet (vlan) shared with the router 3.3.3.3. That subnet is configured in the area "0". At the same time the router 3.3.3.3 has an interface or subnet belonging to the area "10". "

Okay, you're saying, for example, router 3.3.3.3 would be the ABR for area 10; which is fine.

New point of confusion, though, "router, 1.1.1.1 and 2.2.2.2 have a P2P subnet (vlan) shared with the router 3.3.3.3", the two links between those 3 routers are in the same network and VLAN, but they're also p2p?  Would expect each link to be its own p2p network (i.e. /30 or /31) and also not be in a VLAN, although you can have p2p VLANs, just not very common for p2p links.

[Hannibal]

Hi Joseph

Yeas, about the reload time, I know that procedure. Sorry, I thought you meant a different procedure.

Regarding the new point of confusion, each remote connection to the two Switch/routers in the area 0 is a different subnet on different vlan; no same network..

So, as a conclusion, to change the area number, only the two commands are enough ??:

no network 10.0.0.0 0.0.0.3 area 0

network 10.0.0.0 0.0.0.3 area 51

Thank you very much Joseph

Hann

[Joseph W. Doherty · Accepted solution]

Well, first, of course, your new network statement should only impact the interfaces to be placed into the new area.  I mention this because I notice your network prefix and mask are the same in both statements.

Otherwise, yes, I believe that's all you need to change (again, without knowing all the existing interface IPs).  Further, though, it might be possible you don't even need the "no" variant, i.e. the replacement network statement might just override the prior statement (but I'm unsure about this, especially as OSPF network statements support overlapping of prefixes [forget whether last or first match "wins" in overlap]).

[Hannibal]

Hi Joseph, me again

we're finally going to have someone at each of the remote sites.

Since we are going to enter several commands and the person who will be at the remote site has little experience, we are going to apply an old practice in case of :

If it doesn't work, the remote person will enter the command:

switch#copy startup config running-config

The old rollback procedure in case of failure of procedure

How about?

Thanks

Hann

[Joseph W. Doherty]

If I remember (?) correctly, that might not work as you expect.  I recall when you copy to startup it's a complete replace, but when you copy to running it's a merge.

You might have remote personal be ready to do a reload if the copy from startup to running doesn't correct the problem.

You might also look into whether the rollback feature is available on the platform, and if so, enable it and use it rather than a copy from startup to running.

[Hannibal]

Hi Joseph, Balji

Just last question about this issue..

In some case, we will no have an engineer on remote site so we will apply the reload command to execute in two munutes without confirm. I we no lost connection, then apply reload cancel command

Exactly, in some places there are router/switch conforme by two stackable switches. For thouse cases, If we don't specify the stack member, for example, the "reload in 3" command will reinitialize the entire stack, right?

For us it is very important that the stack with all its members is reset. The documentation is no clear about this command in stackable switch/router

Thanks in advance

Hann

[Joseph W. Doherty]

Depends on what you're doing, but a two minute reload can be rather "tight".  Personally, I usually used a five minute reload.

Cannot say for certain on latest gen of switched, but when I supported 3750s in stacks, a reload would effectively bounce the whole stack.  (What it may have actually done, was force a new stack election.  However, effectively the stack would be running the current startup config, although possibly with a different stack master.)

[balaji.bandi]

i would not suggest that operation.,

Instead, make a role back with commands and give to an engineer who is on site to paste that command when you lost other side of the network.

or do not save the changes or reload.