Fun and Games with Overlay Tunnels: Part 1, Dynamic Edge2Edge

 

 Last week a VMware instructor collegue sent me an interesting question which came up during an SD-WAN course:

 "If I set up  Profile A using Gateways, and Profile B using Hubs, would we set up a dynamic VPN from Edge A with Profile A and Edge B with Profile B?"

My first idea was, that such configuration cannot work, but then I decided to try it in my lab first, before answering that question with a categoric NO.


So I defined 3 different Branch Profiles:


BR-3 is using Gateway for E2E (with no Branch to Hub connectivity)


whereas BR-7 is using the DC-HUB for E2E


When starting communication from BR-7  we see, that no Dynamic E2E tunnel is established:

VPCS> ping 10.1.103.75

84 bytes from 10.1.103.75 icmp_seq=1 ttl=61 time=49.366 ms
84 bytes from 10.1.103.75 icmp_seq=2 ttl=61 time=16.159 ms
84 bytes from 10.1.103.75 icmp_seq=3 ttl=61 time=23.028 ms
84 bytes from 10.1.103.75 icmp_seq=4 ttl=61 time=20.930 ms
84 bytes from 10.1.103.75 icmp_seq=5 ttl=61 time=19.896 ms

VPCS> trace 10.1.103.75
trace to 10.1.103.75, 8 hops max, press Ctrl+C to stop
 1   10.1.107.1   8.755 ms  0.699 ms  1.030 ms        
 2   10.10.12.3   69.626 ms  8.462 ms  4.910 ms        < ...DC-Hub
 3   110.1.1.174   19.512 ms  24.615 ms  19.443 ms     < ...Gateway
 4   110.1.1.17   29.702 ms  15.487 ms  7.885 ms       < ...BR-7 WAN IP
 5   *10.1.103.75   51.142 ms (ICMP type:3, code:3, Destination port unreachable)

 

This is what we would expect in that configuration


But when I reverse the initial communication message and started it from BR-3

As expected, the first packets are forwarded via Gateway:

 VPCS> trace 10.1.107.95
trace to 10.1.107.95, 8 hops max, press Ctrl+C to stop
 1   10.1.103.1   2.847 ms  0.585 ms  1.769 ms
 2   110.1.1.174   25.652 ms  1.800 ms  2.354 ms      <... Gateway
 3   110.1.1.33   14.600 ms  8.164 ms  5.189 ms
 4   *10.1.107.95   36.023 ms (ICMP type:3, code:3, Destination port unreachable)

VPCS> ping 10.1.107.95

84 bytes from 10.1.107.95 icmp_seq=1 ttl=61 time=19.774 ms
84 bytes from 10.1.107.95 icmp_seq=2 ttl=61 time=27.347 ms
84 bytes from 10.1.107.95 icmp_seq=3 ttl=61 time=19.014 ms
84 bytes from 10.1.107.95 icmp_seq=4 ttl=62 time=5.505 ms
84 bytes from 10.1.107.95 icmp_seq=5 ttl=62 time=11.103 ms

But then the TTL jumps from 61 to 62, one hop less, as against my initial assumption a dynamic tunnel has been sucessfully established


VPCS> trace 10.1.107.95
trace to 10.1.107.95, 8 hops max, press Ctrl+C to stop
 1   10.1.103.1   6.424 ms  0.895 ms  0.568 ms         
 2   110.1.1.33   43.315 ms  3.747 ms  3.524 ms         <... BR-3 WAN IP
 3   *10.1.107.95   28.896 ms (ICMP type:3, code:3, Destination port unreachable)

and the dynamic tunnel can also be seen using diagnostics

That established tunnel is then used in both directions (also from BR-7 to BR-3)

VPCS> trace 10.1.103.75
trace to 10.1.103.75, 8 hops max, press Ctrl+C to stop
 1   10.1.107.1   5.354 ms  0.548 ms  0.350 ms
 2   110.1.1.17   26.379 ms  2.289 ms  2.479 ms
 3   *10.1.103.75   32.386 ms (ICMP type:3, code:3, Destination port unreachable)

I retested the same situation but changed profile for BR-3 using gateway for E2E and with a permanent tunnel to the DC-HUB as I wanted to see if the result is different, but again only BR-3 could establish a dynamic tunnel and not with initiating packets comming from BR-7.

NOTE: this configuration is neither supported nor recommended but it nicely shows that the VMware SD-WAN overlay trys to establish communication even in seemingly impossible configurations.

As a kind of resume, it seems that whenever there is a static overlay tunnel established from a Branch Edge to a Gateway defined for dynamic E2E traffic, a dynamic E2E tunnel can be established.

On the other hand established overlay tunnels between edges via Hub alone does not alone qualify for establishing a direct dynamic E2E tunnel.

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