Edges and Bandwidth and Performance Measurement: What you need to know about...

 


Around 2 months ago when doing a Speedtest check of my links I experienced a substancial reduction of measured UPlink and DOWNlink speed.

As I only have a single link to the Internet using Cable Modem connectivity which is a shared linktype, after some retries I assumed the problem to be at the Service Provider and some congestion there. I contacted the Service Provider but he assured me, that this is not the case.

Then I found the real "culprit".

It was my VMware SD WAN Edge which drastically reduced the bandwidth sent out via the Overlay.

When checking the Edge I found out that the last measured Bandwidth was around 40/10 instead of 180/40 Mbps.  

I was quite unsure about that measured  bandwidth and found out that according to this VMware knowledge base article ...

... on wired links the bandwidth test is only done when there is a Link Up event or after 7 days.

So what seemed have happened was, that the last bandwidth measurement took place at a time, where due to some external reasons the resulting bandwidth was much lower than usual. After that until rerunning  a new bandwidth measurement by navigating to 

Test&Troubleshoot --> WAN Link Bandwidth Test 

the lower measured and store bandwidth limited the bandwidth used by the Edge to reach destinations via Overlay. 

Note: Even checking the Dynamic Bandwidth Adjustment will not help as it never adjusts to a higher value than the originally measured one

 Therefore whenever you are concerned about performance and want to monitor performance of your Edges you should also include the Measured Uplink and Downlink Bandwidth values

  • bpsOfBestPathTx
  • bpsOfBestPathRx

in your monitoring and rerun a bandwidth Test when the values are below 90% of the expected or highest measured values

The values typically can be gathered via RestAPI ('metrics/getEdgeLinkMetrics' or 'livedata´)

ubuntu@SDwan-Monitor:/$ vcoclient.py --vco="10.8.1.254" edges_get_lm   --enterpriseid=1 --edgeid=1 --starttime="2022-01-26 12:00" --endtime="2022-01-26 12:30" --filters="bpsOfBestPath"

                       GE3        GE4
bpsOfBestPathRx   95518000  639905000
bpsOfBestPathTx  871032000  277411000

The above output uses a nice tool from Github  

 https://github.com/iddocohen/vcoclient

For an automatic measurement and email alerting of remaining important link values like Delay, Jitter and Packet Loss in case of a degradation, you also find a nice solution on Github

 https://github.com/kurtcms/vco-api-wan-anomaly-alert

 Here is an actual example of such email message:

 

Hope that will help you keep an eye on your SD-WAN Edge and Link performance.



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