Fun and Games with Overlay Tunnels: Part 3: How to setup a working (n-tier) 4-tier Hierarchy

 

 In my previous blog I stated, that in VMware SD-WAN we can have Branch to Branch connectivity via overlay, as long as we have the branch routes announced with a maximum of 2 overlay hops away.

Now let´s proof this assumption in my lab and modify it in order to establish a 4-tier hierarchy:


I applied a new profile to the Regional Hubs, which now have only overlay tunnels to the 2 DC-Hubs, thus removing the permanant tunnel between all Regional Hubs.


There is no change in paths between Branch Edges and DC-network

 VPC-A1> ping 10.1.201.2   (VPC-DC)

84 bytes from 10.1.201.2 icmp_seq=1 ttl=60 time=58.340 ms
84 bytes from 10.1.201.2 icmp_seq=2 ttl=60 time=19.604 ms
84 bytes from 10.1.201.2 icmp_seq=3 ttl=60 time=48.628 ms
84 bytes from 10.1.201.2 icmp_seq=4 ttl=60 time=180.321 ms
84 bytes from 10.1.201.2 icmp_seq=5 ttl=60 time=23.469 ms

VPC-A1> trace 10.1.201.2   (VPC-DC)
trace to 10.1.201.2, 8 hops max, press Ctrl+C to stop
 1   10.2.201.1   3.737 ms  2.933 ms  0.999 ms                  (VCE-A1)
 2   100.64.112.2   546.692 ms  32.041 ms  15.937 ms      OVL 1 (Hub-A2)
 3   100.64.121.2   276.149 ms  47.469 ms  101.017 ms     OVL 2 (HUB-DC-1)
 4   10.0.201.2   379.116 ms  84.234 ms  332.541 ms             (R-DC)
 5   *10.1.201.2   552.016 ms (ICMP type:3, code:3, Destination port unreachable

But there is now a 4 hop working overlay tunnel between branches in different regions:  

VPC-A1> ping 10.3.202.79 (VPC-B2)

84 bytes from 10.3.202.79 icmp_seq=1 ttl=59 time=204.124 ms
84 bytes from 10.3.202.79 icmp_seq=2 ttl=59 time=60.646 ms
84 bytes from 10.3.202.79 icmp_seq=3 ttl=59 time=83.949 ms
84 bytes from 10.3.202.79 icmp_seq=4 ttl=59 time=72.727 ms
84 bytes from 10.3.202.79 icmp_seq=5 ttl=59 time=80.987 ms

VPC-A1> trace 10.3.202.79   (VPC-B2)
trace to 10.3.202.79, 8 hops max, press Ctrl+C to stop
 1   10.2.201.1   9.563 ms  0.466 ms  2.328 ms                   (VCE-A1)
 2   100.64.112.2   295.644 ms  6.665 ms  9.424 ms         OVL 1 (Hub-A2)
 3   100.64.122.2   232.402 ms  12.292 ms  14.411 ms       OVL 2 (Hub-DC-2)
 4   100.64.113.2   118.506 ms  36.059 ms  44.155 ms       OVL 3 (Hub-B)
 5   100.64.104.2   107.179 ms  75.817 ms  56.842 ms       OVL 4 (VCE-B2)
 6   *10.3.202.79   236.379 ms (ICMP type:3, code:3, Destination port unreachable)
 


 So, YES , that is the proof that we can build up B2B connectivity over 4 or n hops, as long as we readvertise the branch routes after every 2 hops. 

And I also could proof the assumption, that in networking almost everything is possible.


 

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