This is the second blog in an Internet Edge series.
Links to prior blogs in the series:
- Internet Edge: Simple Sites
While this series is about the (data center) Internet Edge, some / many organizations have been deploying SD-WAN. The inevitable question then becomes, “how does SD-WAN tie into all this?”. So, I intend to address that topic now, handle it totally wonderfully, and then be able to more or less ignore it for the rest of the series. Well, at least 2 of those 3 anyway.
As a result, this blog covers the ways I’ve seen people consider inserting SD-WAN into their data center or CoLo presence. No doubt there are others. There’s always the certainty that various SD-WAN vendors have their own quirky ways of doing things. So be aware, “YMMV.” You know where to find me if you have a diagram or explanation of your different way of connecting up SD-WAN alongside or as the data center Internet Edge.
Hmm, for that matter, I’m assuming that we have classic on-premises designs, which is what I intend to describe, and then we more or less emulate them in any cloud-based data center-like equivalent. That’s a fit topic for a later blog – one thing at a time!
If you’re managing all Internet and/or user access to VM servers via VMware or a VMware kernel firewall, then obviously, your diagram may look different. After all, your firewall is in a different place!
Ditto if you’re using secure logins to control access. Or in the cloud, some designs may look rather similar to what I’ll be showing you, but access to containers, etc., may be different.
That’s what makes Internet Edge so much fun – various security drivers and differing approaches mean that there is a lot of variety. That is also why there is a need to understand WHY we do things in certain ways.
Simplified SD-WAN Router
The following diagram is an attempt to show a “generic” SD-WAN router, assuming there is such a thing.
Figure 1: Generic SD-WAN Router
The key point here is that an SD-WAN router likely has an untrusted or underlay side for connecting to one or more outside entities. One of those entities is likely the Internet. Cisco Vitpela refers to them as VPNs. I think of them as VRFs. You can likely put other physical ports into the same VPN / VRF. If so, that’s the top half of the above diagram.
If you can’t add other interfaces to that VPN / VRF, there may be some way to “leak” traffic. If there isn’t, no worries, we’ll get to the alternative below.
On the trusted side, I’d think any vendor has to have a way to take local interfaces and allow them to be routed out the various SD-WAN tunnels to other sites. That’s the bottom green side of the above diagram.
Since SASE (secure edge) and DIA (Direct Internet Access, for SaaS, IaaS, etc. and offload of the Internet at data centers / central sites) are hot SD-WAN features, remote sites SD-WAN often have the ability to selectively “leak” (forward) trusted side traffic into the untrusted side, and pass replies back. That’s something you may not need in a data center SD-WAN device.
SD-WAN Router as Only Internet Connection
If you have an SD-WAN router that behaves as just described, then the following diagram shows how I would most likely connect it up to the data center.
Figure 2: SD-WAN Router as Sole Internet Connection
The relevant points are:
- If you are still using a stateful firewall (which seems likely), you would connect the “outside” of it to an underlay port on the SD-WAN router and pass its traffic out to the Internet as well.
- Routing on the untrusted side could be “interesting.” If your SD-WAN router only does static default on the Internet side, then maybe you redistribute that into OSPF or EIGRP (if available) to share routing info with the firewall. The alternative is BGP on the outside underlay, which means your SD-WAN router has pretty much just replaced the Internet router in the diagrams from the previous blog.
- There is likely a “trusted side” link connecting the “inside” data center core switches to one or more ports on the SD-WAN router that belong to the trusted overlay / VPN / VRF. That is shown in green in the diagram above.
- Routing on the trusted side is whatever dynamic routing protocol the two routers have in common and that you like. One of EIGRP or OSPF seems like the most likely choice to me, but BGP may well also be possible. That depends mostly on what routing protocols your SD-WAN router supports.
SD-WAN Router via a Shared Internet Connection
There is another reasonable way to connect things up. As is common in most networking, it all comes down to the requirements. What do you want to do, what do you absolutely need to do, how much give and take is there in those items, what are the costs, and what is the best set of trade-offs?
Maybe your data center is still the main hosting site for your Internet services offerings or whatever, resulting in a lot of traffic to the Internet. Maybe you just can’t buy a big enough SD-WAN device to handle that Internet volume.
Or maybe you already own a fairly high-performance router for your data center and want to save costs by buying a lower capacity SD-WAN router (assuming that is possible while still having the capacity to handle the projected volume of site-to-site SD-WAN traffic).
In short, how do you get your SD-WAN router to play well with another Internet router?
Here’s the diagram:
Figure 3: SD-WAN via Shared Internet Connection
The point to this is that you can either run the outside of the SD-WAN router into a port on your “BIG” Internet router (with suitable static or other routing), or you can use an L2 or L3 switch (or pair) to “merge the streams.”
To do this, you’ll need public IP addresses for both routers, so at least a /29 to the ISP, not a /30. (Or you can tackle NAT traversal on the SD-WAN side.)
As far as routing, you can peer each onsite router to the ISP depending on your preferences, the ISP, etc. Static and BGP are the obvious choices.
It would be helpful if the SD-WAN only needed to advertise a “corporate default (summary)” to the core L3 switches. In effect, “for other corporate sites, send traffic to me, and then I’ll VPN them as needed.”
Note that this design treats remote site users just like onsite users for better or worse. Putting a firewall between all such users and the servers – that’s an exercise for the reader!
Conclusion
I hope this discussion and diagrams have been helpful to those of you readers who are “SD-WAN-ers” (pronounced “SD winners”?).
As the rest of you will likely be doing SD-WAN at some point, the topic discussed above might be a good one to discuss with vendors: how would YOUR SD-WAN router best be deployed in a data center?
