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

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 ...
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 ...
Read more

Secure Edge CLI Access: Addditional Useful Commands and Parameter

Image
 additionally to the possible commands and paramteres described in the docu Secure Edge CLI: Output Examples V5.2 there are a lot of useful commands and procedures you can use  Here some of the commands which does not have a direct representation in the Remote Diagnostics debug --dec  <shows the actual detailed status and QOE for each path RX and TX>   debug --peer_stats all <shows packet counts and peer-is for all peers> the peer-id is needed for a detailed dump of peer statistics per peer diag PATHS_DUMP --peer <peer-id> <shows counter and QOE parameters for all paths to a specific peer> for a nice display you need a terminal window of 350 chars/line if you have priviledged shell access you can also use cd /opt/vc/bin in this directory you find a lot of internal but useful prgrams, phyton or shell scripts like...  ./dispcnt here an example for usage:   ./dispcnt -s  bgp -t 15 -z   shows all non-zero bgp counter updated e...
Read more