3 (or even 4) different Ways to connect your Data Center to SD-WAN

 

 As you already might know we can design our SD-WAN to DC connectivity in various ways.


Beside the most common connectivity via a HUB Cluster we can also use 2 or more separate Hubs to connect the SD-WAN network to our DC. 

The third in enterprise environment less common way is to use Gateways in Partner Gateway Mode and connect the DC via the Handoff Interface.

There is also a fourth possibility to go from a Cloud gateway via IPsec and treat the DC as a NSD (non sd-wan enabled) destination

I want to explain the different methods including advantages and disadvantages of each of those


1.   Using HUB-Cluster

This method uses 2-8 edges in parallell and each Branch edge will connect to only one of the Hubs of that cluster. Thus the implementation needs to set up an internal L3 switch or Router with typical eBGP connectivity to forward routing information (Control Plane function) and data packets between the Hubs inside the cluster. 

Detail on the setup can be found in my blogpost: 

https://sd-wahn.blogspot.com/p/understand-hub-cluster-design-in-vmware.html

 


Advantages:

  • Recommended Setup
  • Branches only need to setup a single tunnel to HUB Cluster
  • Automatic  Failover to another Hub in case of Overload (if Cluster rebalance is turned on) 
  • Automatic Failover to another Hub in case of Hub going down

Disadvantages: 

  • Failover to another hub and build up new tunnel takes some seconds
  • in some versions failover did not work correctly
  • traffic from Branch to Branch goes 3-4 hops (2 overlay, 1-2 underlay in DC-Lan)

 2. Using separate Hubs

 First glimpse into that design I got when teaching SD-WAN to a greek bank. When showing me their topology I saw 4 HUB edges in front of the DC and assumed it to be connected in a cluster. But I was told that VMware professional services recommended against the use of Clustering.


Similar to a cluster you will typically setup N+1 Hubs (N ..the necessary Hubs for providing the ncessary bandwidth). In Cloud VPN all that Edges will be mentioned as Hubs, but you can as well use several profiles and select or reorder the Hub edges for a better load distribution.

The main difference to a cluster setup is, that we typically set up permanent edge to Hub overlay tunnels to more than 1 or all hubs in the DC. And as long  as we always have at least one common Hub between any edges we do not need a seperate control plane and data plane router, so setup is easier than setting up a cluster.

 

In my test case I did set up all 3 Edges in the DC as Hubs for Branch to Hub traffic.

Advantages:

  • Easier Setup, no LAN side router in DC needed
  • Branches can set up a tunnels to 2 or more (all) Hubs
  • Easy rebalancing and per packet remediation in case of degradation or failures
  • Quick Failover to another Hub without the need of a new tunnel setup

Disadvantages: 

  • Depending on the amount of Hubs more tunnels are needed
  • predictability where traffic will flow is not easy to achieve
  • need routing to pereference or depreference certain hubs

 3. Using Gateways in Partner  Gateway Mode 

 This is the setup we have chosen for our company SD-WAN network.

The 2 gateways serve 3 different functions:


 

Advantages:

  • Least amount of devices
  • Least amount of Overlay tunnels used
  • Redundancy as both gateways are stateless
  • use of gateways allow different connectivity into DC per customer and per segment
  • even user with only ipv4 internet connectivity can forward ipv6 traffic via gateway

Disadvantages: 

  • Need either own Orchestrator and Partner Gateways or be an MSP
  • quite complicated setup as in NSX-T a T0-router in active/active can use BGP only on uplink interfaces
  • Gateways have no embedded firewall or security regarding traffic, security need to be defined on the Branch or Home Edges
  • gateways may need some BGP filtering defined to restrict traffic

4. Using Cloud Gateways and IPsec NSD connectivity 

Traffic to the DC will be sent via Overlay to the Gateway and from there via Internet and IPsec to the Router or Firewall sitting in front of the DC.


DC routes can either be defined static or can be dynamically learnt via BGP over IPsec.

Connectivity need to be set up including IKE and IPsec parameters under Network Services and then enabled in Cloud VPN


Advantages:

  • Uses standard Cloud Gateways ( provided by VMware or MSP or own)
  • Gateway nearest to NSD destination is automatically selected so that most of the connection is DMPO secured
  • Redundancy as both gateways are stateless

Disadvantages: 

  • IPsec connectivity into DC need partner router or firewall
  • quite complicated setup as you need the correct IPsec parameter
  • Gateways have no embedded firewall or security regarding traffic, security need to be defined on the Branch or Home Edges
  • gateways may need some BGP filtering defined to restrict traffic

 


 

This concludes my evaluation on the 4 possible ways to connect our SD-WAN to a Data Center



Comments

Post a Comment

Popular posts from this blog

Orchestrator Upgrade to Version 5.2

Image
 Recently I upgraded my VMware SD-WAN lab from version 5.0 to 5.2. Since some previous versions the official documentation  recommends to ask TAC for help in upgrading.   Docu 5.2: Orchestrator Upgrade  But if you have an unsupported implementation, like I do, you need to do it on your own: Trying to copy the new version to the VCO failed and I found out that I needed to increase a disk volume How to increase disk volume on VCO is described in this blog:   VCO Upgrade to 4.5.x After increasing the disk size my copy succeeded   NOTE: I did not copy direct to the installation directory including a renaming, as once an upgrade started that file gets deleted and if there are any problems to have to redo the copy from outside.  vcadmin@vco-lab-254:~$ ls -l total 2504488 drwxr-x--- 2 root    root          4096 Aug 31  2022 20220831130007 -rw-rw---- 1 vcadmin vcadmin 2564587520 Aug 10 07:57 vco-debs-signed-5.2.0.3-R5203-20230809-GA-ff5cd1917e.tar vcadmin@vco-lab-254:~$ sudo cp vco-debs-signed
Read more

Deep Dive on DMPO and its Performance Features (available and missing) Part 1

Image
 In the last year I got quite deep insight into ther vendors SD-WAN implementation and also have seen what various vendors are critizising about the VMware DMPO features. Also there are a lot of misconceptions on the market around some of these features. So let´s try and evaluate and look a little bit deeper into typical performance features and the VMware implementation of them Features discussed in this Blog (Part 1) Per Packet Load Balancing Forward Error Correction (FEC) Packet Replication Latency Remediation The following Features will be discussed in Part 2 of my blog TCP Optimization Techniques Dejitter Buffering SAAS Application Monitoring   Per Packet Load Balancing  Unfortunately this term can be quite easily misinterpreted, when you Google for the term and get the following result:  This behaviour (often criticized by other vendors about VMware) as described above would only work quite well when you have very similar or equal connections. If for example 2 links have  both 10
Read more

Deep Dive on DMPO and its Performance Features (available and missing) Part 2

Image
  The following Features will be discussed in this second part of my blog TCP Optimization Techniques Dejitter Buffering SAAS Application Monitoring   Before diving into the mechanism here an important basic fact:     Remediation is never done for applications classified as LOW priority     TCP optimization TCP has some embedded traffic management capabilities for reliable traffic delivery  (window.size, slow-start, RTT handling,...)  But there are a bunch of factors which can negatively influence the performance, like Latency TCP-slow-start Last Mile network problems Out of Sequence packets Busty losses end host TCP limitations (missing fatures like SACK, windows scaling or timestamp options)  Typically TCP optimization helps on the transmission side and improve the download time for large data transfers over latency-high and lossy WAN links. But it can also be used for improving perfomance when on the receiver side the amount of buffers is limited and/or when the client is n
Read more