The blueprints say a lot about interconnecting with partners much like we are connecting to the cloud. However, when I connected to AWS they had very specified process on how the connections were made, they told me how to physically connect, they assigned IP addressed, they dictated routing protocol, and they even gave advice on security. Now that I’m discussing connecting with a partner, we have none of that direction. How do we collectively decide how to design and operate this connection?
When I first read your question, I thought about the Digital Partner Value Chain which discusses how connectivity plus policy can yield create results for digital partners; but the more I thought about it, I realized that before you can have digital flows between two organizations, you first have to physically plug in and handle the network configurations. I’m glad you’ve asked this question as I’m sure many more can benefit from it.
I see two parts to your question:
Part A I’ll answer now, and I’ll answer part B in a follow up post.
Let’s start with some technical best practices. We could likely write a book (or at least create a new blueprint!) on forming connections but we’ll focus on the most critical points here. I like modeling these connections after AWS since they do everything in a manner that scales and you’ve already begun to do this in your very question. So let’s start by identifying a few very important categories:
There are several options for getting partners connected to one another but the common characteristic is that they should be a point-to-point. Within point-to-point connections you have a few options:
IPsec site-to-site and leased line has been a commonly done practice but is cumbersome and expensive making it fairly heavy handed if the partnership is anything short of permanent or has lighter bandwidth needs.
The cross-connect capability (physical or virtual) is much more dynamic and service connectivity needs in a day-to-day timetable. Additionally, the virtual capability allows connections to be spun up in minutes, across large geography, and offer sub-rate speeds to right-size the connection.
I’d also advise using VLAN trunking (802.1q) on any of the Ethernet based options to provide maximum flexibility for the link.
When creating a link between org A and org B, you’ll need to come up with address space for the link which won’t overlap with existing IP space in either organization. For that reason, private IP is probably going to be a challenge because though there might be plenty of it for a simple point-to-point link, you’ll have to dig through each organization’s IP address assignments to ensure there’s no overlap.
Public IP would be the next alternative: either organization can carve off some of their public IP space which is guaranteed to be unique and use it for the link. However, not everyone has spare public IP sitting around and even when they do, they may not be too excited about parting with it.
So we come upon my favorite option, link-local addresses (https://en.wikipedia.org/wiki/Link-local_address). Link-local IPs don’t get talked about very often but are ideal for this use case (likely why you see AWS and Google using them for their private cloud connections). See, link-local addresses are only significant to the network segment they are on and therefore potential overlap is very easily mitigated. With link-local addressing you may not be able to ping the partner’s device from anywhere but the local link, but it will allow you set up a routing protocol to ensure the ability to reach one another.
Last point on IP addressing. For these point-to-point links using a /30 network (two usable IPs) is most appropriate. /31, a true point-to-point connection, are sometimes not supported on all network devices and if you are following my advice on using link-local addresses, there is no need to get stingy.
I don’t want to discredit any creativity, but in my opinion there is only a single choice for a routing protocol between to different organizations: eBGP. There’s a reason that network engineers distinguish internal gateway protocols (IGPs) from external gateway protocols (EGPs) and that’s because IGPs should only ever be used internally to your organization because of scale and security concerns. And the only EBGP is eBGP.
Don’t get scared off by eBGP because for a simple two partner connection you won’t face all the complexities associated with running eBGP on the internet backbone. For this purpose, a private-AS along with a few short network statements and a single neighbor statement is all that you’ll need to get it up and running.
Do spend some time thinking about what networks you want to advertise via BGP. Keep in mind that they should be public IPs only to avoid the IP overlap issue we discussed previously. You’ll also want to limit the networks to those needed for the partner (certainly do not send them all your IP prefixes and DO NOT send a default route!). You probably already operate a DMZ for external connections, that’s likely a good start for what networks you’ll want to advertise to your partner. You’ll also want to screen what routes your partner is sending you, you don’t want to accept a route (like a default route) which could cause major issues for you.
If public IP is an issue, then you’re likely going to have to look at NAT which I’ll address in the next session.
We all want to trust our partners, but an external connection to your network should always be treated as a potential threat vector. I’d highly advise that the traffic be inspected by a firewall and that a white-list security model be implemented (i.e. everything is blocked until specifically allowed).
The firewall may also be the best place to implement any required NAT rules that can perform any needed translation from private to public IP.
Effectively you’ll want to treat these partner connectivity zones like a DMZ, or better yet, use your existing DMZ structure to host these partner connectivity zones.
Whew, that’s a lot to be said (and there’s plenty more than can be said) but this should put you on the right path for implementing best practices for connections to your partners. I’ll take a breath and then post about how you may go about working with your partner to get agreement on these technical decision points.
I hope you haven't been holding your breath for part B! Sorry for the delay. The good news (for everyone) is that this part is much shorter than the thesis I gave for part A
So now onto 2. Who is responsible for deciding the end configuration? Partner A sets them and partner B follows? Vice versa? Or collectively decided?
Like any good partnership, the resulting configuration should come from collaboration and compromise between two parties. And like any good negotiation, the party that comes more prepared often wins.
There are three possible scenarios:
1) Neither party really knows how they want this done.
My suggestion here is to get help (especially if you want this to move forward quickly). Equinix Professional Services can be engaged to help coach both parties into a workable and scalable solution that benefits both parties allowing the connection to proceed.
2) One party is well prepped and the other isn't as prepared.
In my opinion, this is a bit easier to solve. The prepared party should take charge and set the terms for the connection.
3) Both parties are very well prepared.
While this sounds ideal, you may face the challenge that the process and procedures that party A has established are just enough out of sync form party B to make them incompatible. Here is where patience and compromise will be key. My advice is to approach these situations with an open mind as you might be able to glean some great practices from your new peer.
So the best strategy is to be prepared with how you want to connect before you and your new peer begin discussions by investing time in the areas I identified in part A. If you get stuck, this forum is a great place to get help!
Choose a location
There are no forums in this space.