I am always interested to learn how vendors implement their SD-WAN solution. For example, what protocols they are using for data plane and control plane? What makes their solution unique?
While it is unfortunate that there are no SD-WAN standards and there are as many protocols as there are SD-WAN vendors, there is a positive side to this also. Vendors have their unique ways to implement SD-WAN. For some, this makes their solution stand out from the competition.
For this post, I want to write about Riverbed’s SD-WAN solution. In particular, about one of the features that caught my attention. This feature is the unique way they do IPsec tunnels on their SD-WAN system that makes the system more scalable.
Let’s talk about how they handle IPsec tunnels on their SD-WAN products SteelConnect EX and SteelConnect CX
But before that, a word about why IPsec tunnels are important for SD-WAN.
IPsec tunnel is a basic, yet important, feature in any SD-WAN system. SD-WAN primarily uses the internet as a transport medium. Internet by its nature is not a trusted medium, therefore it needs an authentication and encryption mechanism to secure the traffic. The IPSec tunnel achieves exactly that purpose. If the medium is private or trusted like MPLS, using IPSec becomes an option but not mandatory.
With either Internet or MPLS, vendors use a packet tunnel technology like GRE or VXLAN and then combine it with IPsec for added security. This is also called an overlay tunnel.
Usually, the vendor will build up a separate IPsec tunnel for each uplink. In the Riverbed case, however, it only uses one IPsec tunnel even if there are multiple uplinks. This makes their system more scalable.
How? Though the smart use of protocol stack.
They use a pure VXLAN tunnel on transport (as underlay) and on top of it, a second IPSec/GRE tunnel for encryption (as overlay). That is a double tunnel mechanism.
Confused?
I was also until I probed more deeply to see why they are doing so and what benefits it can bring.
Let’s dive a little deeper.
Under the hood in each CPE, there are multiple virtual routers, separating underlay and overlay as shown in the figure below.
- The LAN VRF faces the LAN side and is the point of entry for the LAN traffic.
- The Control VR advertises the remote SD-WAN sites. The control VRF then encapsulates the traffic as IPSec/GRE and sends it to the control VR in the remote SD-WAN CPE which is BGP next hop for it.
- The transport VR is the actual underlay like MPLS and the Internet.
Here is a clearer diagram of how different tunnels are in action, involving both MPLS and the internet underlay. There are two different transport VXLAN tunnels, one MPLS, and the other Internet. However, there is only one IPSec tunnel as the underlay. This means that the actual traffic passed on transport is using double tunnels.
So here is the sweet part. The presence of the extra layer of control VR brings extra benefits – since control VR is talking to another control VR in a remote branch, it does not matter how many underlay links there are between them. There will always be one IPsec tunnel between the control VRs and not multiple IPSec tunnels.
This is different compared to other SD-WAN systems that will need a different IPsec tunnel on each uplink underlay. One tunnel versus multiple IPsec tunnels has several benefits.
Firstly, the other SD-WAN systems will need one IPSec tunnel for MPLS underlay and another one for internet underlay and more if there are more uplinks. All of these tunnels are pre-established. Quickly, the system can run into scalability issues as there are a lot of IPsec tunnels needed. In a full mesh network, the number of tunnels can significantly increase and can stretch the scalability of the system. The benefit of establishing one IPsec tunnel even when there are multiple uplinks significantly reduces the number of IPsec tunnels required in the network and makes the system more scalable.
Second, an alternative solution to reduce the number of IPsec tunnels (for other SD-WAN vendors) is to avoid pre-establishing the tunnels on the backup path and let the protection tunnel get established on the fly during failover. However, this will significantly increase the restoration time as IPSec tunnels need time to re-establish. Therefore this solution is not practical.
So that’s it, this feature of a single IPsec tunnel makes the Riverbed solution scalable and simple. And therefore, in conclusion, you might very well add this to your checklist when buying an SD-WAN solution in comparison to different SD-WAN vendors’ solutions based on their scalability and the way they handle IPsec tunnels.
