All about the 4.x SD WAN Routing Behaviour Part 2: Routing, Route Redistribution and Preferences

 

SD-WAN has a kind of Plug&Play strategy when it comes to connectivity and routing.
  • Therefore automatically a default route is established on every working WAN-Interface and on every Overlay tunnel.
  • Additionally there is an automatic bidirectional redistribution on every Edge between Underlay, LAN  and Overlay routes.

From a networking point of view a kind of routing nightmare with Mutual Redistribution in both direction on every Edge.

BUT by using an internal clever preferencing algorithm, routing loops and blackholes are mostly avoided.

A SD WAN administrator can avoid pitfalls and wrong paths by following some basic rules: 

  1. Only enable Dynamic Routing when it is really necessary
  2. Never run a Dynamic Routing Protocol direct between Edges

If Dynamic Routing is needed then there are some further rules to consider:

  1. Prevent Redistribution form Overlay to Underlay (it is not needed in most cases)
  2. Restrict Redistribution from Underlay to Overlay to Edges (Hub) who are playing the role of transit points to reach underlay destinations
  3. Use features like UPLINK to de-preference announcements if they are only used as last resort, when preferred paths are not available
  4. Never redistribute dynamically learned tunnel endpoints for Overlay tunnels to the Overlay
First we consider Preferences for Routing which are set on the Orchestrator (Configure/Overlay Flow Control) using Preferred VPN exits
 

 You can remove various route types OR change the ranking and thus the preference of learned routes
 
But what are those routes:

0. Non SD Wan Destination Routes (NSD)

    • Prefix typically reachable via IPSec from Edge or Gateway

 - Only used when DCC is enabled

1. Edge

•Prefix reachable through VMware SD-WAN Edge

2. Router

•Prefix reachable through underlay, such as PE router

3. Partner Gateway

•Prefix reachable through Partner Gateway

4. Hub

•specific Prefix reachable through HUB Devices
- any BGP route from Hub marked as „Uplink“ via Flag or community
- OSPF E1/E2 routes from Hub
-> all others (local) routes are considered Edge Routes


Now let us look into various mechanism to restrict Redistribution

Underlay to Overlay Redistribution 

...is controlled via Orchestrator (Configure/Overlay Flow Control/Edit)

by Checking/Unchecking Global Advertise Flags

for BGP redistribution can also be prevented by either specifying

  • Uplink Feature (set per BGP neighbor)

or

  • Uplink Community Flag (set per prefix)

 But this can be overwritten in the OFC by checking

 
If checked such marked routes are redistributed from Underlay to Overlay but with a high metric so that they are typically only used as last resort when other paths are not available. 
 
Additionally to the OFC setting static routes also need the Preferred and Advertise Flag set, else they are considered as local only 
 

Overlay to Underlay Redistribution 

This is controlled on the Protocol/Device/Interface Level
 

for OSPF
                          
 
 
 
 
 
 
 
for BGP 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Note: You can also redistribute between OSPF and BGP. This can be necessary when you want to advertise OSPF learned local routes via Underlay in case you prefer some direct underlay communication to non SD-Wan enabled sites who could reside on MPLS. 
 
 
If you want to go deeper into some principal aspects of Underlay/Overlay routing there is a nice but older program guide from VMware named


Routing Design Guide 

Underlay/Overlay Routing












This concludes the mini series on VMware SD-WAN version 4.x Routing.

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