SD-WAN VeloCloud Traffic Flow

SD-WAN VeloCloud Traffic Flow

Posted on Jan 08, 2020 (0)

SD-WAN VeloCloud Traffic Flow

Before we talk about how talk to SD-WAN network Branch and how migration is done, let’s understand  what ports and Protocols are being used for communication on SD-WAN NSX VeloCloud environment.

Ports & Protocols for Communication:

  • Branch to VCO ( Orchestrator ) : for Management , TCP/443
  • Branch to Hub : data Traffic UDP/2426 ( tunnel to hub is created )
  • Branch to Hosted VCG or On-Prim VCC : Control and data UDP/2426
  • Hosted VCG or On-Prim to Orchestrator : TCP 443 for Management

SD-WAN Reference Topology:

Below topology will explain how NSX SD-WAN are connected by different method, how SD-WAN CPE is connected to MPLS and Internet via VRRP, How SD-WAN with L3 switch is connected, How Hybrid SD-WAN site is connected and How Non SD-WAN site is connected with SD-WAN CPE Internet connection.

Below is the figure that explains that:

HUB VCE Placement:

There are two options to which HUB can create Tunnel:

  • Option1: Route the private tunnel traffic through the firewall
  • Option2: Route the private tunnel traffic directly to the L3 core

Migration Work Flow

Following are the Migration flow of any WAN sites which has to be migrated from Typical WAN to SD-WAN using VeloCloud technology.


  • Ensure firewall ports are opened to allow SD-WAN components to communicate
  • Define the traffic flow, do I need BGP at branch WAN or not. How does my branch users reach the Internet. Filter what you do not need.


  • Install and activate the hub & enabling routing protocol
  • Ensure routes are learned properly by SD-WAN but do not advertise anything into the network until you are ready


  • Install and activate the branch
  • Validate the traffic flow

Communicate with Non SD-WAN Site:

There are two ways to connect the Non SD-WAN sites to SD-WAN sites, which are as follows:

  • Use HUB Sites as Transit
  • Connect the Non SD-WAN site directly to SD-WAN Branch Site

Use HUB Site as Transit:

  • Traffic to/from non-SD-WAN sites go through transit site first to reach SD-WAN site
  • If non-SD-WAN sites are high BW, allow SD-WAN sites to use combined link BW
  • Will introduce latency due to backhaul

Connect the Non SD-WAN site directly to SD-WAN Branch Site

  • Traffic to/from non-SD-WAN sites go directly to MPLS and use transit site as backup
  • Lowest latency but less available bandwidth

Understand SD-WAN Routing

Let’s understand how routing stack integration is done with SD-WAN Overlay. In this Control Plane channel peer is created between edge to gateway to share route and a separate data plane dynamic tunnel is created between edges. Due to this separate Tunnel, it achieves the separation between control plane and data plane.

Following are the some highlights of SD-WAN VeloCloud.

  • Support overlay and underlay routes over the same interface
  • Underlay route options: Static (with IP SLA), OSPF, BGP
  • OSPF and/or BGP underlay routing protocol at each site
  • Underlay routes are redistributed to the overlay and vice versa while retaining the BGP attributes

Branch becoming Transit Site: issue

In the SD-WAN environment, our design should be in such a way that Branch site should not become transit site, to understand this let’s assume the below topology:

Let’s discuss it point by point

  1. Hub sites can reach to
  2. Hub sites advertise this network to MPLS via BGP
  3. Non SD-WAN sites stores prefix in its routing table stating that it can reach to by HUB.
  4. BR1 gets activated on SD-WAN and starting learning the by SD-WAN overlay
  5. BR1 advertises the to MPLS  which its learned from SD-WAN
  6. Non SD-WAN site puts the reachability via BR1
  7. BR2 gets activated over SD-WAN
  8. sends that is reachable via BR2
  9. Non-SD-WAN sites puts is reachable from BR2

Non-SD-WAN sites puts is reachable from BR2

Now when sending traffic to, which routes Non SD-WAN will take, as it has three entry n its routing table

To avoid this following steps should be taken:

  • Stop mutual re-distribution between overlay and MPLS at branches
  • Prefixes belong to the branch should still be advertised into the overlay

But this can be more complicated, so there is various technique developed by Velo cloud which is been discussed below:

BGP Uplink Neighbor

Uplink neighbor is the neighbor who takes you in and out from network and is CPE or PE router. So if you mark the neighbor as uplink, to the int which is connected to that neighbor, mutual re-distribution between overlay and underlay will be prevented.

In the above figure, prefix learned from internet will be redistributed to LAN but we have made the MPLS Router as neighbor of SD-WAN router, so SD-WAN router will not redistribute prefix learned from Overlay (Internet) to underlay (Internet).

This BGP Uplink Neighbor helps in following way:

  • Assist with stopping a site from being a transit
  • Control route exchange between underlay and overlay

BGP Uplink Community: 

This is the case when the Traditional CE and VCE is connected via L3 switch , (typically used in DC ) , in this case we cannot define the CE router as uplink neighbor, now if you want to tag the prefix coming from CE router – tag it , that means anything that is coming from CE router will be tagged by a certain community , so now when VCE will learn the prefix from its neighbor , it can easily distinguish that which prefix is learned by CE and which prefix is learned by LAN  and so that based on tagging it can redistribute the LAN prefix to Overlay and not CE learned Prefix to Overlay.

It does the following:

  • Tagged the prefixes learned from the MPLS
  • VCE knows not to re-advertise the prefixes tagged as uplink to the overlay

Lets suppose take an another example , here I want to reach to legacy MPLS site from Hybrid branch , and not via Overlay , but if my MPLS goes down I want to send the traffic to MPLS router via HUB.

Sol: To achieve this tag the MPLS prefix with community so that as soon as it reaches to Hybrid Router, Hybrid Router will guess that this prefix is not belong to SD-Wan site and will use it as backup also it will not advertise the prefix to underlay( MPLS) again.

Route Preferences, for a given prefix

  • Take the overlay if prefixes are owned by SD-WAN site
  • Take the underlay, e.g. direct MPLS, if the route exists
  • Send to the hub


    You are will be the first.


Please login here to comment.