Merger and Acquisition Problems

[deanwebb]

Here's one I overheard:

"None of the datacenters use IP ranges that conflict with each other, but there are datacenters at Company_A that overlap with office ranges at Company_B, and vice versa."

The first answer is "OK, time to NAT!" But what do you do for the long term? NAT forever? Reassign IPv4 addresses and hope that doesn't break production apps with hardcoded addresses? Convert to IPv6? Something else?

Discuss.

[Otanx]

1. Identify overlaps, and what that space is used for on each network. If you can include information on if DHCP is used on each side, how many hosts, and criticality of that subnet.

2. Examine the list, and identify what can be resolved quickly. Depending on your environment I would say quickly is less than a week to fix. So changing the subnet of a branch office that has no servers may fall into this. Maybe one company used 10.0.0.0/24 to make /31s for routed interfaces. Depending on redundancy that could be solved quickly.

4. Identify solutions for mitigating the overlap. Maybe you have 10.10.10.0/24 used in both data centers. Can you use some more specific routes to force routing to pick the "right" /24 for some services. So maybe a web server sits in one data center in 10.20.20.0/24. It has no need to talk to the Security camera network at the other data center. You could define a /32 to point everyone at the web server, and maybe have to re-IP one camera on the other side if it has the same IP. Whatever solutions you have during this step you document them like crazy, and make sure everyone understands the limitations. You don't want someone taking the /32 out of the router because it doesn't look like it is needed.

5. Solve the overlap. Re-IP stuff. Do not leave the mitigations in place. However, don't rush it either. Define a standard that everyone can follow. This may mean having to re-IP more than just the overlaps. Maybe move all of Data Center B to 10.32.0.0/16. You are going to run into the "I can't re-IP this app. It hard codes the database IP during the build". It sucks but, rebuild the app. Maybe move both DCs to new space, and then the legacy space is just used for those items that just "can't" be moved. Hopefully you don't have a direct conflict of two "can't" move applications.

Story time. We have an application we can't move. The license for the host includes the IP, and hostname. If you change either one you have to re-license the system. Requesting a re-license costs money because we don't have a support contract. It isn't a lot, but the team responsible won't pay on principle. So we have one server that sits on a subnet by itself with a hostname about 4 hostname standards ago. Every few months I ask about replacing this.

-Otanx

[icecream-guy]

The license for the host includes the IP, and hostname. If you change either one you have to re-license the system. Requesting a re-license costs money because we don't have a support contract. It isn't a lot, but the team responsible won't pay on principle.
-Otanx

We had something like this at my last place, not only was there a penalty fee for reinstating the coverage, but also had to back pay for the years out of coverage and then pay for current coverage.  ended up costing a lot.

[deanwebb]

Oh man, licenses hard-coded to IP addresses... glad that $VENDOR doesn't do that!

Another set of fun times: IP ranges duplicated across self-contained networks that aren't supposed to be routable, but network mapping software putting them on the maps and deciding that all those 192.168.1.0/24s that the ASA firewalls use for HA are all the same network. This makes for some hilarious AI mistakes as the network mapper then decides that the best way to connect two remote offices is to skip the MPLS network and go with all those directly linked ASA firewalls...

[Otanx]

We gave up on the non-routed duplicate networks. We used to do exactly what you listed. All our ASA HA links were 192.168.1.0/30. There were never any major issues that caused outages, or anything, but just automated scanning, and explaining to cyber why those addresses are on all our firewalls. No they don't talk to each other. No it isn't a security concern. We just eventually assigned a /24 from our normal address space, and assigned /30s out of it. Now they don't overlap, and everyone is happy.

We also have 192.168/16 reserved as build networks. Too many systems use static IPs from these space for initial configuration. So we reserve that out, and then if we need to build something we can spin up a /24 of that space, configure the device with the right IP, and put it back on the network. Looking at you Palo Alto.

-Otanx

[deanwebb]

^ Great idea with the 192.168 networks, making them build-only.