I'm working on a data center project where I'm migrating 6 x /24 subnets from one OSPF area to another.
The main aim of this is to not incur downtime - the two environments have layer two connectivity and SVIs in all the inside subnets.
Initially one way I was thinking about doing this was to advertise the same subnets from a different area but with a higher cost, then remove the same subnets from the old area one by one while adjusting HSRP priorities (temporary asymmetric routing is acceptable). After some conversations with colleagues and a bit of Googling, this doesn't seem like the best approach as it can cause unpredictable results into area 0.
Has anyone had any experience with this previously, or suggest a better way of doing it?
My first thought if there are only 6 subnets is to set static routes for the 6 subnets pointing to a default gateway that will be unaffected by your changes. Then you'll be able to remove/change the OSPF process without reprocussion because the static routes will have a lower admin distance anyway and your subnets will be using those. Make whatever changes to OSPF you need to and then remove the static routes. Is this possible or is the network too large for that to be practical?
Edit: I assumed that you're leaving the subnets in place just changing the area. I also assumed that the area you're migrating them to is adjacent.
Well, my first instinct is that it might work? I'll need to do some research when I get home (I plan to try it out and review how OSPF does type 3 LSA metric cost), but my first thought is that it could work as long as you make sure the subnet advertisements from the new area have a lower route metric than the prexisting routes. That way they'll be the active routes and you can remove the old ones without incidence.
Perhaps you could try using the "area range .. " command on the new area ABR(s) to advertise a summary route. That way the more specific subnets from the old area would be used because they are a longer match prefix and then you can remove them one by one. As the more specific prefix disappears the summary route would be then used as it is the best match.
Once all subnets have been moved across you can then remove the summary and advertise out the specific subnets.
We are pleased to announce availability of Beta software for 16.6.3. 16.6.3 will be the second rebuild on the 16.6 release train targeted towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are looking for early feedback from custome...