You might have come across a post from my good friend Adam on SDWAN Design options in Azure, where he details seven design alternatives when incorporating SDWAN to an Azure network. While I was reading Adam’s great summary, I was wondering whether I could summarize his design options and recommendations using the 3-tier cloud netowrk architecture that I described in this post. If this sounds interesting to you, keep reading!
SD-WAN and Azure: 3-tier design
As a describe in this post, the 3-tier design with Virtual WAN and a regional aggregation layer is the most flexible option, so let’s start with this. There are two primary places where you could insert your SDWAN devices: either in the “hybrid aggregation” layer (options 1 and 2 in the diagram below), or in the “regional aggregation” layer (option 3 in the diagram below):
Only options 1 and 2 are really meaningful, because they leverage the native functionality of Virtual WAN: absorbing and distributing routes across all regions. The main difference between both options is that while in option 1 SDWAN routes are directly injected inside of the Virtual WAN (most likely with SDWAN termination in an NVA hosted inside of Virtual WAN), in option 2 you need some extra effort to inject the routes from the NVA VNet into Virtual WAN.
Option 1 (injecting the SDWAN routes straight into Virtual WAN) supports different protocols and gateways: VPN on an Azure native gateway, ExpressRoute, or even SDWAN appliances deployed inside of the Virtual WAN hub (see NVAs in the Virtual WAN hub), and there is nothing to do to get those routes further to the rest of the network.
You would use option 2 when your NVA vendor does not support deploying inside of the Virtual WAN hub. It has a bit of extra work to inject the routes from the SDWAN appliances to the VNet, with either of these possibilities:
- Use static routing to tell Virtual WAN which prefixes are in the SDWAN network.
- Use a BGP Peering with a Virtual WAN hub to inject routes, which is going to support more dynamic configurations (feature in preview at the time of this writing).
Deploying your SDWAN appliances in the regional aggregation layer (option 3 in the diagram above), while technically viable, does not leverage the functionality of the core layer. We will explore this option further down, in the section on the hub and spoke collapsed design.
SD-WAN and Azure: 2-tier design (Virtual WAN)
The collapsed design where Virtual WAN takes over the role of regional aggregation tier looks very similar to the 3-tier design, since Virtual WAN is still the ideal entry point for external connections, for the same reasons as in the previous section:
As you can see, the same two options apply here: either injecting the prefixes of the SDWAN cloud straight into the Virtual WAN hub (option 1), or deploying the SDWAN appliance in a dedicated VNet if deployments in the virtual hub are not supported, and using either static routing or the Virtual WAN BGP endpoint (option 2).
SD-WAN and Azure: 2-tier design (hub and spoke)
The other variant of the 2-tier collapsed design is when the regional aggregation takes over the inter-regional communication, eliminating Virtual WAN. In this case there is not Virtual WAN to take over the route distribution, so it is up to you to do that. As in the previous collapsed design, you are down to two options:
Option 1 is connecting the SDWAN via standard VPN or ExpressRoute to an Azure Virtual Network Gateway. This is the simplest option, but most SDWAN vendors will offer additional functionality when having an SDWAN appliance in Azure supporting their proprietary encapsulation protocols.
In this case, the appliance should be ideally placed in the regional aggregation tier, along with other network services such as firewalls. The main challenge to solve is how to inject the routes from the SDWAN environment into the different VNets, at least in the same regions (other regions might have their own SDWAN appliances). There are a couple of options how to do that:
- User-Defined Routes: best for static environments, or in situations where SDWAN prefixes can be easily aggregated (for example with RFC 1918 summaries)
- VPN tunnel to Azure Virtual Network Gateway (VNG), so that the VNG injects the routes in the local VNet and the directly peered spokes.
- Using Azure Route Server to interact with the VNet routing, which is the best approach to support dynamic routing environments.
A variant of this design is when the SDWAN appliances have to be deployed in their own Virtual Network, maybe because of some specifics of the SDWAN deployment model. The design would be quite similar:
This design introduces some complexities: first, using the Azure Route Server in a separate VNet could become more complex: for example, other spoke VNets would not be able to use the SDWAN routes, since the next-hop (the SDWAN NVA) is 2 hops away.
Instead, the pattern with using an IPsec tunnel between the SDWAN NVA and a VNG in the hub VNet might be simpler to implement, and would cover approaches such as the ones depicted in the previous figure, where other networks are accessible via ExpressRoute connections (note the Azure Route Server would still be required to provide VPN-to-ExpressRoute transit, but with a much simpler configuration).
TL;DR
If you compare Adam’s SDWAN Design options in Azure with the ones described in this article, you will see they are essentially the same. Be sure to have a look at his article, since he goes more in-depth on each option than what I did here. Hopefully in this blog I could give you an architecture perspective of when to use which design option, and how they fit in the overall patterns that Virtual WAN and the Hub and Spoke model have to offer. Thanks for reading!
Cloudtrooper 