OSPF area - migration to new address scheme & area type

[iores]

Hi,

I have OSPF area 1 that I would like to migrate to a new address scheme for P2P links, and new area type - Totally Stub. Currently, only SVI interfaces are used (no routed ports).

I was thinking of a way to minimize downtime. My idea is to create a new "parallel" network with new P2P links and SVI interfaces. These new interfaces and advertised networks would be part of the newly created OSPF area 2 (the current is area 1). Then, when everything in area 2 would be up and running, I would shutdown everything from area 1.

Is this approach OK?

[paul driver]

Hello @Joseph W. Doherty 
I agree, as ive stated it all depends on the OPs topology, there are various ways an ospf address migration can be accomplished but without knowing the topology refining from suggesting a definitive way forward would be best approach, however i believe the OP did state SVIs are in the mix which would narrow down the alternatives

[Joseph W. Doherty]

Yup, as SVIs were mentioned both in use now and continued usage, it begs the question of using new/additional SVIs on transit links.

Fully agree, more information may provide better suggestions.

[iores]

Please explain the difference between "bad news" and "good news" approach.

[Joseph W. Doherty]

---

@iores wrote:

Please explain the difference between "bad news" and "good news" approach.

---

Sure, using the following topology . . .

Links not up, nor configured, but that doesn't matter for the following explanation.

Assume all infrastructure links are costed 10 except the bottom WAN LAN which is costed 100.

Also assume the WAN links rely on OSPF hellos to detect loss of neighbor.

Given the above assumptions, traffic will only flow across the top WAN link.

Bad news - case 1:

For whatever reason, you need to take R2 off-line, so what happens if you just power it off?

Assuming SW1 "sees" its link down to R2, it will re-compute path to SW0, but during that time, packets that would have been sent via R2 are dropped.  Impact, though, should be pretty brief, probably within milliseconds.

R0, doesn't see its WAN link drop, so until it does,  it will continue to send packets to R2, which is off-line (i.e. a black hole).  Impact may extend over multiple (possibly lots of) seconds.

There's more possible delay for the path to switch, but that overlaps with the next case.

Bad news - case 2:

Before taking R2 off line, we use something link max-metric.

Both R0 and SW1 get revised cost LSAs and re-compute (route paths) and now determine they shouldn't be using the top WAN link path.  The big, big improvement is, as R2 is still on-line, and forwarding traffic, any traffic sent to it, during the re-computation, will be forwarded.

However, what about SW0, R1 and R3?

Say, for example, R2 sends SW0 packets back to SW0, but before SW0 gets the updated LSA and does its re-computation.  You may have a temporary routing loop.  This loop should be short lived, but it can re-occur as the "bad news" jumps from routing device to routing device.  Basically, what's known as a race condition.

Good news - case 3:

Before taking R2 off-line, we change the cost of the bottom WAN link to 1.

Just as with hop by hop re-computation of best path for the "bad news", this happens for the "good news" too.

However, you're less likely to create temporary routing loops.  For example, assuming R1 knows to use it's WAN link before SW0, SW0 won't send traffic to it, it will continue to send its traffic via R0.  Likewise, when SW0 starts to forward traffic to R1, R0, which may still not "know" to not send its traffic to R2, will continue to send its traffic to R2, which is fine.

Now good news can have the same problem as bad news if, for example, we revise R1, it notifies SW0, but SW0 completes its computation faster than R1 does, but remember R1 had the good news first, so that's less likely.

Hopefully, the above will make sense when you keep in mind it take time for route changes to propagate and to be processed, i.e. there are possible re-convergence impact issues.  Knowing such issues, you can try to mitigate their impact by how you make changes.  Whether you need to do so, is a separate question, and depends on your network and its service needs.

I'll conclude with, link and/or device failures, generally, are "bad news", but some times they too can be mitigated by design.

[iores]

Hi,

I will try to provide all missing information in this response.

The area 1 has 7 devices. The plan is to introduce new P2P links using SVI interfaces so current network can remain operable. In addition, LAN segments will get re-addressed, too.

The idea is to build the new area 2 in parallel with area 1. Every new interface will be part of the new area 2. The plan is then to gradually shut everithing in area 1, and to migrate to area 2.

Will the idea with two parallel areas work given the introduction of new addressing scheme?

Someone has mentioned introducing additional routing process. What is the idea behind this?

[MHM Cisco World]

If that So' then your idea will work' add additional link for area2 then reassign interface from area1 to area2.

No need new ospf process.

I also suggest use area range in area2' hence when you remove the interface from area1 and add it to area2 the traffic will not so effect' where during the time of swap area2 advertise range and hence other router can still forward traffic to these subnet.

Goodluck 

MHM

[MHM Cisco World]

 this my idea'

With area range in time when you change 10.1.0.0/16 from area1 to area2' R2 still have route to forward traffic to R1 for 10.1.0.0/16 which is 10.0.0.0/8 via area2.

Run LAB I am sure this way will work.

MHM

[paul driver]

Hello

---

@iores wrote:

The plan is to introduce new P2P links using SVI interfaces 
The idea is to build the new area 2 in parallel with area 1. Every new interface will be part of the new area 2.
Will the idea with two parallel areas work given the introduction of new addressing scheme?

@MHM Cisco World wrote:
then your idea will work' add additional link for area2 then reassign interface from area1 to area2.

---

If you are running SVIs then NO it will not work as I don't see how you can have parallel areas/links
SVis relate to L3 vlans so you cannot create two SVIs relating to the same L3 vlan with different ip addressing on the same rtr/l3switch plus any physical links will be associated to the L3 SVIs at L2

@iores 
Based on your OP then its seems you are limited to how you re-address your existing network, i still do not understand when you state P2P links , do you mean the other 6 devices will be P2P toward the device(s) running the L3 svis?

Can you share a topology as requested previously.

[iores]

Each new SVI will be related to new vlan. Basically, I will keep the current network as is, and in parallel will add completely new L2/L3 scheme.

When I say P2P, I mean L3 /30 links between the devices via SVIs. For that I will use unique SVI, as well.

The thing is, devices are now connected via L3 links over trunks, and the plan is to take advantage of such design (at least temporarily).

[Joseph W. Doherty]

---

@iores wrote:

Each new SVI will be related to new vlan. Basically, I will keep the current network as is, and in parallel will add completely new L2/L3 scheme.

When I say P2P, I mean L3 /30 links between the devices via SVIs. For that I will use unique SVI, as well.

The thing is, devices are now connected via L3 links over trunks, and the plan is to take advantage of such design (at least temporarily).

---

Oh, in that case, you shouldn't have any issue creating a new area 2, sharing devices and trunk links.  Then you can migrate edge devices pretty easily.  In fact, you can just migrate an edge network from one area to another, which will knock it down for some seconds.  You can also use, temporarily, primary and secondary networks on the edge networks, which will allow you to easily migrate hosts between subnets on the same VLAN.  (The latter only needed if you're readdressing the edge network.)

[Joseph W. Doherty]

---

@iores wrote:

Hi,

I will try to provide all missing information in this response.

The area 1 has 7 devices. The plan is to introduce new P2P links using SVI interfaces so current network can remain operable. In addition, LAN segments will get re-addressed, too.

The idea is to build the new area 2 in parallel with area 1. Every new interface will be part of the new area 2. The plan is then to gradually shut everithing in area 1, and to migrate to area 2.

Will the idea with two parallel areas work given the introduction of new addressing scheme?

---

Unfortunately, only knowing area 1 has 7 devices, doesn't tell us much, other than there are 7 devices. ; )

However, for so few devices, though, you might be making your project unnecessarily complex.

Possibly you might consider just having two different projects, the area change to stub (you could keep using area 1) and addressing and/or new p2p link changes.

If you split your project into the two forgoing projects, insufficient information to say which should be done first.

Also, for just 7 devices, I wonder about the need for a stub network, but perhaps you have 100 other areas, each with 7, or more, L3 OSPF devices.

[iores]

I am considering stub area because of 1000 external OSPF routes from area 0. The idea was to simplify routing table. In addition, besides intra-area traffic, everything else goes through ABR.

But will changing current area 1 into stub area cause some downtime in the current network because of config changes needed on each device in area 1?

[paul driver]

Hello
it wil cause a disruption yes as the adjacency’s will be torn down and reestablish into a stub area 
Hows that topology diagram getting on any luck compiling one and sharing it ?

[Joseph W. Doherty]

---

@iores wrote:

I am considering stub area because of 1000 external OSPF routes from area 0. The idea was to simplify routing table. In addition, besides intra-area traffic, everything else goes through ABR.

Yea, I can see wanting to filter that.

Of course, that still leaves area 0 with needing to slosh those routes about.  No way to summarize them?

---

@iores wrote:

But will changing current area 1 into stub area cause some downtime in the current network because of config changes needed on each device in area 1?

---

Yup, but so does readdressing.

For 7 devices, you could probably do that whole area conversion, manually, in under two minutes, even by yourself, of downtime.

I believe, with EEM scripting, you could probably cut downtime to half a minute.