"High Away Blues Nr 2" or Challenges in Edge High Availability Part 2: Enhanced HA

 

VMware SD-WAN Enhanced High Availability (HA) is a redundant Edge installation where both Edges have each different WAN networks connected to only one of the 2 devices.

When both Edges are online, the standby edge will forward packets between it`s local active WAN circuits to the active edge via the GE1 HA-Link.

 One basic rule for the automatic detection of the Enhanced mode is that WAN circuits have to use different WAN Interfaces on that edges.

 Here is a working example for Enhanced HA


 BR-25 is the Enhanced HA pair with one Internet connection (GE3) and one MPLS connection (GE4)



 As I did not know which interface will be used for the MPLS connection, I configured GE4 to GE6 as  User Defined Private WAN Overlay. In that way a local operator can connect the MPLS circuit to any of those 3 WAN Interfaces.


 
 
This perfectly works for single Edges and even reconnecting from one MPLS interface to another is completely unproblematic.
 
Unfortunately that is not the case for Enhanced HA 
 
When I connect the MPLS on GE4 (the first configured interface for MPLS) everything is working as planned:
 

High Availability Status and Interface Status are correct.
 

 
 You can also achieve a working Enhanced HA with Overlay tunnels established on Internet and MPLS as well by using other interfaces for MPLS
 
 
In my case I use GE6 for the MPLS connectivity
 
 
with the expected Interface Status 
 


and with HA Status


and Monitor Edge Overview status

but this works only when GE4 and GE5 is disabled and thus taken out from WAN Overlay



as soon as I also enable GE4 and GE5 as possible MPLS connection points ...


...the MPLS circuit will go down and never built up again over GE6
 

HA Info shows that even though the WAN count on the standby device is 1, the active edge expects the first active MPLS circuit on the lowest of the configured interfaces (GE4), ignoring the working connection on GE6

Therfore we only see Overlay tunnels established via Internet connection(110.1.1.0/24)

 Also a default route pointing out on GE6 is missing


So this is an Enhanced HA specific problem and for proof of that as comparison I tried the same interface configuration on a non HA enabled edge

and everything was working as expected


Note that I am using virtual edges (KVM version) and not physical ones but according to various documents that should not make any difference regarding the above described behaviour


Resume: I cannot tell, if this is a bug or an undocumented restriction when using Enhanced High Availability on VMware SD-WAN Edges, but you should be aware of that behaviour when installing and configuring Enhanced HA.







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