A frequent challenge of managing a network at a growing company is that of acquisitions. That is, one of the ways a growing company grows is by acquiring other companies. When that acquisition happens, there is usually the need to connect the two networks together.
Connecting two disparate networks together is one of those tasks that makes network engineers groan. As networks are not built to any sort of agreed-upon norm, what the opposite network will hold is unpredictable–probably in a difficult-to-integrate way.
The Quick & Dirty IPSEC Tunnel
When an acquisition deal goes through, management needs the IT infrastructures connected. Specific applications need to be brought together as soon as possible to facilitate the acquisition deal. For example, accounting and CRM systems might need to be joined quickly.
There’s a proper way to bring networks together…and then there’s the fast way. The proper way involves a full audit of the remote network to insure compliance with regulatory obligations, inventorying IP address blocks both public and private and BGP ASNs in use, understanding IGP routing schemes, reviewing WAN provider contracts, itemizing hardware and software in use, purchasing needed equipment, staging infrastructure changes, scheduling maintenance windows, and so on.
But when management is tapping their collective feet impatiently, time is critical. Merging the two networks properly isn’t going to happen when those well-shod feet are being tapped.
My intermediate step to merge an acquired network has been to build a quick and dirty IPSEC tunnel, exchanging the minimum number of routes required to facilitate the business requirement. With the tunnel and requisite routing in place, business folks can start making the acquisition happen.
The problems with quick and dirty IPSEC tunnels are manifold.
- Manual maintenance of network lists.
- Potentially manual maintenance of route injection into the IGP.
- Probable single points of failure.
One alternative that overcomes these limitations is DMVPN, a predominantly Cisco technology. I’ve built DMVPN solutions that integrate with an IGP, handle being NAT’ted through firewalls, and eliminate some SPOFs. However, DMVPN is just a connectivity technology. What if we want a broader feature set?
SD-WAN As Acquisition Network Glue?
Thinking through SD-WAN technology, I see a potentially quick connectivity option that’s better than a quick and dirty IPSEC tunnel or even DMVPN. What does SD-WAN offer that interests me?
1. Easily managed redundant plumbing. One of SD-WAN’s core value propositions is that of easily managed link redundancy. That is, SD-WAN forms a mesh of tunnels on top of all available paths. That means that a local circuit outage neither takes down the ability to forward nor requires a network engineer to re-configure IP tunnel endpoints.
This is not unlike using loopback addresses to form tunnel endpoints, and then announcing those loopback addresses over multiple physical paths. However, in the case of SD-WAN, this redundancy is functional over the public Internet where tricks like announcing loopback /32s are not available. In the context of an acquisition, this means you’ve got a highly engineered connection that requires less fuss than manually building redundant IPSEC tunnels.
The catch, of course, is that to leverage redundant Internet links, you need, well…redundant Internet links. There is no guarantee that multiple links will be available on the remote network you’re integrating. But if such redundancy exists, you can build a solution that’s reasonably bulletproof.
2. IGP integration. SD-WAN solutions typically offer OSPF and BGP as ways to announce routes into the the local routing domain. While route injection is often available with IPSEC tunnels, I’ve found that route injection isn’t terribly reliable, depending on vendor, software version, and a host of other factors. I’ve never been keen to rely on routes being injected or withdrawn by an IPSEC VPN endpoint.
Static route redistribution can work with IPSEC tunnels, but I don’t love that as a methodology either. To do static route redistribution well, the static route needs to be paired with an IP SLA test to be certain that the tunnel is up before announcing the route. Complex, fussy, and easy to get wrong.
I’d rather that the SD-WAN solution handle the route announcement for me. I want to be able to treat the remote routes in as simple a way as possible, and in that context, I want the connection to the remote site to be as much like a traditional routed path as possible. While there is still complexity in SD-WAN, much of the complexity is hidden away. If the SD-WAN forwarder speaks a routing protocol to my network core, that feels simple.
Note that DMVPN, of course, readily integrates into a variety of IGP schemes.
3. Segment isolation. Another SD-WAN function available from many of SD-WAN vendors is that of segment isolation. That is, you can create virtual network segments that permit intra-segment communication while preventing inter-segment communication. In the case of an acquisition, that functionality seems useful.
While businesses are being joined, keeping the remote company isolated to a specific business unit inside the new parent business might help maintain regulatory compliance. It might also limit exposure to malware if the acquired site has some hidden surprises lurking inside.
Segment isolation might also help simplify routing and addressing schemes when paired with other virtual networking technologies like VRFs. In other words, imagine building a VRF for the financial BU in your organization and then plumbing it to an isolated network segment on the SD-WAN. If you’re facing overlapping RFC1918 network segments, this might help avoid a complex NAT scheme.
4. Service chaining. Many SD-WAN products perform service chaining. That is, SD-WAN devices tunnel between one another. Considering that tunneling ability, it’s possible to drop traffic off wherever it’s needed.
Therefore, if you want to perform deep packet inspection on all traffic coming from the acquired business, you could write an SD-WAN policy that tunnels all traffic back to the HQ SD-WAN device. From there, the traffic can be forwarded out an interface attached to an IDS.
There are ways to get this done with traffic emerging from a VPN termination devices, but often not an approach that’s as easily policy-driven and auditable as an SD-WAN solution.
5. Phasing in acquired network segments more easily. Another challenge of integrating an acquired network is handling all of the remote network’s various segments. For instance, they might have a WAN of remote offices that, for various reasons, will need to pop onto the HQ network to facilitate the acquisition and just generally conduct business.
In this scenario, it’s certainly possible to add acquired remote office network blocks to the quick and dirty IPSEC tunnel. However, this could result in an inefficient forwarding path, routing traffic back through the remote office HQ and across the quick and dirty IPSEC tunnel to the new parent HQ. This is similar to the latency challenges faced by hybrid cloud operators.
With SD-WAN, it’s possible to bring remote offices up quickly over their local Internet connection, minimizing potentially inefficient routing. Each remote office can rely on the SD-WAN forwarding device to determine the most efficient path between destinations, whether that’s through HQ or not.
6. Comfortable permanency. When merging in a new network, I always hated the so-called temporary IPSEC tunnel phase. Such a connection felt too fragile for a crucial business requirement, especially when the IPSEC tunnel endpoints were from two different equipment vendors.
Yes, we were always working on the permanent connectivity solution, but the final solution was always months away due to unpredictable WAN circuit delivery times and the equipment procurement process. With an SD-WAN approach leveraging existing Internet circuits, a solution that could be temporary feels much more robust and capable.
The Caveats Of The SD-WAN Approach
A few negatives to using SD-WAN as a network merger tool come to mind.
1. Cost. The price of adding a new network segment to an SD-WAN deployment varies by licensing scheme, but isn’t free. Quick and dirty IPSEC tunnels often are “free,” requiring no capital expense to stand up.
2. Remote hands. To leverage SD-WAN at remote sites, there’s a good chance you’ll need remote hands to pull off the device installation. That’s not any different than deploying SD-WAN in your own network, but still an operational reality that might limit effectiveness of the SD-WAN proposal I’m making.
3. Perhaps not quick and dirty enough. The big problem I’m engineering around is the long time it takes to stand up dedicated WAN circuits. IPSEC tunnels are often the path of least resistance to bringing up a private connection between two newly acquainted organizations.
Considering the move many organizations are making away from private MPLS circuits and towards using the public Internet as a WAN, I’m thinking that driving ahead with SD-WAN right off the bat for a quick integration is going to work out.
But…maybe not. Perhaps obtaining budget to stand up the new SD-WAN endpoint is a bridge too far. Maybe integrating an SD-WAN forwarding device with a remote network that’s been configured in an unknown way makes using remote hands too unpredictable.
The View From The Hot Aisle
I despise temporary solutions, because they tend to be permanent. Using IPSEC tunnels to join together what will eventually be part of a unified IT whole isn’t a mature solution in the modern era. SD-WAN feels like a mature solution that doesn’t require private MPLS circuits to function.
However, if private MPLS circuits are eventually added to the SD-WAN mix, there is no technology transition required. The SD-WAN solution can stay in place as-is, with the MPLS circuit being added to the SD-WAN forwarding device as a newly available path. That means the “temporary” solution can transition into the permanent solution gracefully.
I see SD-WAN as a way to onboard an acquired network permanently, while retaining the fast time to connect that an IPSEC tunnel offers. For organizations who already have an SD-WAN solution in place, there’s not much to think about. For organizations who haven’t invested in SD-WAN yet, this might be an additional driver to do so.
If you’ve read this but aren’t familiar with SD-WAN, we have a list of SD-WAN vendors with our commentary to help get you started. This is not a clickbait trick–you don’t have to register to read it.
Help improve the IT community with your wisdom. If you have insights or opinions about using SD-WAN as a tool to integrate acquired networks, please leave a comment.