Configuring Dynamic Routing with OSPF or BGP
This section discusses configuring dynamic routing with OSPF or BGP.
The Edge learns routes from adjacent routers through OSPF and BGP, and then sends the learned routes to the Gateway/Controller. The Gateway/Controller acts as a route reflector and sends the learned routes to other Edge. The Overlay Flow Control (OFC) enables enterprise-wide route visibility and control for ease of programming and for full and partial overlay.
VeloCloud supports Inbound/Outbound filters to OSPF neighbors, OE1/OE2 route types, MD5 authentication. Routes learned through OSPF automatically redistribute to the controller hosted in the cloud or on-premise. Support for BGP Inbound/Outbound filters and the filter can be set to Deny, or optionally you can add or change the BGP attribute to influence the path selection, such as RFC 1998 community (https://datatracker.ietf.org/doc/html/rfc1998), MED, and local preference.
Activating OSPF for Profiles
Users can enable Open Shortest Path First (OSPF) only on a LAN interface as an active or passive interface. The Edge advertises only the prefix associated with that specific LAN switch port. To access full OSPF functionality, the user must use OSPF on routed interfaces.
- VeloCloud introduced support for OSPFv3 in the SD-WAN Edge for IPv6 underlay routing feature in addition to the existing BGPv6 support and supports the following:
- Underlay IPv6 route learning
- Redistribution of OSPFv3 routes into overlay/BGP and vice-versa
- Support for Overlay Flow Control (OFC).
- OSPFv3 has feature parity with OSPFv2 and does not support the following:
- Point to Point (P2P)
- BFDv6 with OSPFv3
- OSPFv3 header therefore no MD5 authentication available
To activate OSPF, perform the following steps:
Route Filters
- Inbound routing includes preferences that can be learned or ignored from OSPF and installed into the Overlay Flow Control.
- Outbound Routing indicates what prefixes can be redistributed into the OSPF.
Activate OSPF for Edges
Users can enable Open Shortest Path First (OSPF) on a LAN (routed or switched) or a WAN interface. Currently, the system does not provide an option to override the passive interface setting for OSPF on a VLAN interface, as the Edge only supports OSPF on a switched interface as a passive interface. The Edge only advertises the prefix associated with that LAN switch port. To get full OSPF functionality, users must use it on routed interfaces. After users configure the OSPF settings at the Profile level, all the Edges associated with the Profile inherit the OSPF configuration from the Profile. However, users cannot override the OSPF configuration settings at the Edge level.
Use the following steps to view OSPF configuration for a specific Edge device:
Configuring BGP
- As the ASN of Edges
- Peer to a neighbor with 4-Byte ASN
- Accept 4-Byte ASNs in route advertisements
Configure BGP from Edge to Underlay Neighbors for Profiles
You can configure the BGP per segment at the Profile level as well as at the Edge level. This section provides steps on how to configure BGP with Underlay Neighbors.
VeloCloud supports 4-Byte ASN BGP. See Configure BGP for more information.
Configuring BGP from Edge to Underlay Neighbors for Edges
You can override the inherited Profile settings at the Edge level when configuring BGP from the Edge to Underlay Neighbors.
If required, you can override the configuration for a specific Edge as follows:
BGP over IPsec from Edge to Non SD-WAN Neighbors Overview
The Non SD-WAN BGP Neighbors configuration does not apply to the Profile level. You can configure the NSD Neighbors only at the Edge level.
BGP establishes the BGP neighborship over the IPSec tunnels to the Non SD-WAN Sites. Direct IPSec tunnels establish a secure communication between the SD-WAN Edge and the Non SD-WAN Destination (NSD). In previous releases, VeloCloud supported NSD tunnels from the SD-WAN Edge with the ability to add NVS static routes. In the 4.3 release, this functionality extends support to BGP over IPSec to the NSD endpoint for a route-based VPN.
Each Azure VPN gateway allocates one set of public Virtual Public IPs (VIP) for a branch Edge to form IPSec tunnels. Similarly, Azure also allocates one internal private subnet and assigns one internal IP per VIP. This internal tunnel-ip (peer tunnel-ip) will be used for creating BGP peering with the Azure Gateway.
Azure has a restriction that the BGP peer IP (Edge's local tunnel-ip) cannot exist in the same connected subnet or 169.x.x.x subnet, and therefore VeloCloud supports multi-hop BGP on the Edge. In BGP terminology, the local tunnel-ip maps to BGP source address and the peer tunnel-ip maps to neighbor or peer address. The configuration must form a mesh of BGP connections- one per NSD tunnel so that the return traffic from the NVS can be load-balanced (flow-based) on the Azure Gateway side. The example network diagram for the physical Edge displays two public WAN links and therefore consists of four tunnels to an Azure Gateway. Each tunnel associates with one BGP connection uniquely identified by the local tunnel_ip and remote peer tunnel_ip. On the Virtual Edge, the configuration has one public WAN link and a maximum of two tunnels and two BGP sessions to the Azure Gateway.
Use Case 1- BGP Over IPSec from an Edge to an Azure VPN
Unlike Azure, AWS VPN Gateway allocates one set of public VIPs per link to a branch Edge. The total sets of public IPs allocated to a branch Edge from an AWS Gateway equals to the number of Edge public WAN links that connects to the AWS VPN Gateway. Similarly, a /30 internal/private subnet allocates per tunnel used for BGP peering on that tunnel. These IPs can be manually overridden in AWS Gateway configuration to ensure uniqueness across different availability zones.
Similar to the Azure use-case, the Edge forms a mesh of BGP connections- one per tunnel to the AWS gateway. This allows load-balancing of the return traffic from the AWS VPN Gateway- design on the AWS side. In the example diagram, for the physical Edge, the AWS Gateway allocates one set of public IPs and one set of tunnel-ips (/30) for each Edge WAN link for a total of four tunnels, and terminate in different public IPs on the AWS Gateway and four BGP connections.

Use Case 3- An Edge Connecting to Both AWS and Azure VPN Gateways (Hybrid Cloud)
One branch Edge could be connected to both Azure Gateway and AWS Gateway for redundancy purposes or some workloads and apps hosted in one cloud provider while other workloads and apps host in a different cloud provider. Regardless of the use-case, the Edge always establishes one BGP session per tunnel and propagates the routes between SD-WAN and IaaS. The diagram below is an example of one branch Edge connected to both Azure and AWS clouds.

Use Case 4- A Hub Cluster Connecting to Azure and AWS Transit Gateways
The Hub cluster members can form IPSec tunnels to the Azure and AWS transit Gateways and leverage the transit Gateways as Layer 3 for routing traffic between different VPCs. Without the native BGP over IPSec functionality on Hub, the Hub needs to connect to an L3 routerusing native BGP and the L3 router forming a mesh of BGP over IPSec tunnels with different VPCs. The L3 router serves as a transit end-point between different VPCs.
Use Case-1 uses a Hub as a transit node between different VPCs in different Availability Zones (AZ) so that one VPC can communicate to another VPC. Use Case-2 connects all Hubs in the cluster directly to a cloud transit gateway and can use the cloud gateway as a PE(L3) router for routes distribution between cluster members. In both use-cases, without the support for BGP over IPSec on the Hub, the Hub connects to an L3 router like CSR using native BGP and CSR peers with a transit and VPC gateway using BGP over IPSec.

Use Case 5- Supporting Transit Functionality in Cloud Providers without Native Support
Some cloud providers such as Google Cloud and AliCloud do not have native support for transit functionality (no transit Gateways), and with the support for BGP over IPSec, can rely on SD-WAN Edge/Hub deployed in the cloud to achieve the transit functionality between different VPCs/VNETs. Without BGP over IPSec support, you must use an L3 router to achieve the transit functionality.
Prior to the 4.3 release, for customers with reachability to the same NVS-Static destination through an NVS-From-Gateway and NVS-From-Edge, the traffic from other branch SD-WAN Edges prefers the path through a NVS-Gateway. When you upgrade your network to the 4.3 release or later, this traffic path from other branch- SD-WAN Edges prefers the path through the NVS-Edge. Therefore, you must update the NVS-Static-Destination metric of the NSD-Edge and the NSD-Gateway as per the traffic path preference.
Next Steps- See Configuring BGP over IPSec from Edge to Non SD-WAN Neighbors.
Configuring BGP over IPSec from Edge to Non SD-WAN Neighbors
Prerequisites
- Ensure you configured a tunnel between a branch and non SD-WAN destination. See Configure Tunnel Between Branch and Non SD-WAN Destinations via Edge.
- Requires a Local IP address from the Edge to configure BGP with NSD Neighbors.
Use the following steps to enable BGP with Non SD-WAN neighbors:
Configuring BGP Over IPsec from Gateways
Only eBGP is supported with BGP over IPsec.
You can configure BGP Settings for Gateways over IPsec tunnels.
VeloCloud allows Enterprise users to define and configure a Non SD-WAN Destination instance in order to establish a secure IPsec tunnel to a Non SD-WAN Destination through an SD-WAN Gateway.
- Create a Non SD-WAN Destination via Gateway for one of the following sites:
- Configuring a Non SD-WAN Destination of Type AWS VPN Gateway
- Configure a Non SD-WAN Destination of Type Check Point
- Configure a Non SD-WAN Destination of Type Cisco ASA
- Configure a Non SD-WAN Destination of Type Cisco ISR
- Configure a Non SD-WAN Destination of Type Generic IKEv2 Router (Route Based VPN)
- Configure a Non SD-WAN Destination of Type Microsoft Azure Virtual Hub
- Configure a Non SD-WAN Destination of Type Palo Alto
- Configure a Non SD-WAN Destination of Type SonicWALL
- Configure a Non SD-WAN Destination of Type Zscaler
- Configuring a Non SD-WAN Destination of Type Generic IKEv1 Router (Route Based VPN)
- Configure a Non SD-WAN Destination of Type Generic Firewall (Policy Based VPN)
- Associate the Non SD-WAN Destination to a Profile. See Configure a Tunnel Between a Branch and a Non SD-WAN Destinations via Gateway.
Monitoring BGP Sessions
You can monitor the BGP sessions on Edges and Gateways.
Monitoring BGP Events
You can view the events related to the BGP sessions.
In the SD-WAN service of the Enterprise Portal, select .
To view the events related to BGP, you can use the filter option. Select Filter next to Search and opt to filter the details by different categories.

- BGP session established to Gateway neighbor
- BGP session established to Edge neighbor
- BGPv6 session established to Edge neighbor
- Unavailable BGP neighbor
- Unavailable BGPv6 neighbor
- Unavailable Gateway BGP neighbor
Troubleshooting BGP Sessions
You can run Remote Diagnostics tests to view the logs of the BGP sessions and use the log information for troubleshooting purposes.
Use the following steps to run tests for troubleshooting BGP:
OSPF and BGP Redistribution
Each of routing protocols OSPF and BGP may be enabled independently and the prior model of allowing only one routing protocol to be enabled on the system has been removed with this release. This release also allows the possibility of redistributing OSPF into BGP or BGP into OSPF (or both simultaneously), along with other possible route sources like prefixes learnt over the overlay, connected routes, static routes, etc.
In addition, with release 3.2, VeloCloud standardizes the redistribution behavior along more traditional lines (similar to that in other routing vendors). For example, if there is more than one route available for the same prefix, then only the best route for that prefix in the system RIB will be redistributed to the destination protocol if the configuration in the destination protocol allows redistribution for that route type.
Consider, as an example, redistribution of the prefix 192.168.1.0/24 into BGP, and routes to the prefix 192.168.1.0/24 are locally available, learned from OSPF and separately learned as an Overlay prefix. Let's further assume that between the OFC flow ordering for the prefix, and route metrics, and route preference the OSPF route ranks above (is better than) the learned overlay route for that same prefix. Then, the OSPF route will be redistributed into BGP if OSPF redistribution has been turned on in BGP. Note that since the overlay learned prefix is not the best route for that prefix in the system RIB, it will not be redistributed into BGP even if the redistribution of overlay prefixes has been turned on in BGP.
In cases like the above, in order to facilitate the redistribution of the best route for a prefix into a given destination protocol, the user can enable redistribution for the specific route type that is the best route in the system.
Alternately, if the user prefers a different route source for that prefix to be redistributed into the destination protocol, the user can control the relative precedence of the route in the system RIB using the Overlay Flow Control facility provided by the management interface, or by varying the route metric.
Route-Overlap Suppression in Overlay Flow Control
In Overlay Flow Control (OFC), the system employs a route-overlap suppression mechanism to improve network stability and efficiency. This behavior ensures that certain routing prefixes are not advertised into the OFC if they overlap with locally connected interface subnets.
When a received prefix overlaps with a subnet of a locally connected interface, it will not be advertised into the OFC. The system suppresses and intentionally discards both summarized and supernet routes when the user enables this setting. This behavior prevents routing loops, packet misforwarding, and overlay ownership conflicts.
Consider an example configuration scenario in which an Edge LAN interface is configured with the IP address 10.10.10.9/29 and operates within OSPF Area 1. The Edge establishes OSPF neighborship with a LAN core switch, assigned the IP address 10.10.10.10/29. In this scenario, if the Edge receives an OSPF advertisement for the IP subnet 10.10.10.0/24, this subnet will not be added to the OFC table due to route-overlap suppression.
OSPF/BGP Redistribution Metric Calculation
- The transit metric is (0) if the route is learned from a directly connected Edge.
- The transit metric is (90) if the route is learned via a Gateway.
- The transit metric is (32 + hub's order value) if the route is learned via a Hub Edge.
For OSPF External Type-1 (OE1) routes, this is the final metric. For OSPF External Type-2 (OE2) routes, it adds up the non-preferred metric constant (8388607). This is why there is a very high metric value for an OE2 route type on Edge peers.
For BGP, this implies that the BGP MED value advertised by Hub Edges, which previously started from 9, 10, 11, and so forth, now starts from 33, 34, 35, and so forth.
BFD Settings Overview
Bidirectional Forwarding Detection (BFD) provides a simple Hello protocol similar to detection components of well-known routing protocols. A pair of systems transmit BFD packets periodically over each path between the two systems, and if a system stops receiving BFD packets for long enough, the neighboring system is assumed to have failed.
A BFD session is established based on the needs of the application that would use BFD. The user has to explicitly configure the address and parameters for the BFD session and the subscribers/applications (BGP/OSPF) of the session, as there is no discovery mechanism in BFD.
Routing protocols like BGP or OSPF exchange the learned routes between Edges and Routers. These protocols exchange routes and detect route failures using their own mechanism. Generally, route failures are detected based on the keepalive mechanism where one entity echoes other entity on a frequent configured interval, that is the keepalive time. These routing protocols have higher keepalive timers which results in longer duration to detect the route failures. BFD detects route failures between two connected entities faster with low overhead on detection of failures.
- Fast route failure detection with low re-convergence time.
- Less overhead in route failure detection.
- Uniform rate of route failure detection across routing protocols.
BFD can be defined as a simple service. The service primitives provided by BFD are to create, destroy, and modify a session, given the destination address and other parameters. BFD in return provides a signal to the clients indicating when the BFD session goes up or down.
- BGP on Edges and Partner Gateways
- OSPF on Edges
Configuring BFD for Profiles
VeloCloud SD-WAN allows to configure BFD sessions to detect route failures between two connected entities.
To configure a BFD session for Profiles, use the following steps:
Configuring BFD for Edges
VeloCloud SD-WAN allows to configure BFD sessions to detect route failures between two connected entities. Once you have configured BFD rules for a Profile, the rules are automatically applied to the Edges that are associated with the profile. Optionally, you can override the inherited settings at the Edge level.
Use the following steps to override the configuration for a specific Edge:
Configuring BFD with BGP for Profiles
Configure BFD for BGP on SD-WAN Profiles.
By default, BFD is deactivated in BGP neighbor. You can enable BFD for a BGP session to subscribe to BFD session updates.
Enabling BFD for a BGP neighbor does not create a BFD session. You must explicitly configure a BFD session. See Configure BFD for Profiles.
The following procedure describes how to enable BFD for an already configured BGP session on an Edge. To configure BGP settings, see Configure BGP from Edge to Underlay Neighbors for Profiles.
To enable BFD for BGP on partner Gateways, you must be an Operator super user. For more information, see the Configure Partner Handoff section in the VeloCloud SD-WAN Operator Guide.
Configuring BFD with BGP for Edges
You can override the inherited settings at the Edge level for BFD for BGP.
Use the following steps to override the BFD configuration for an Edge:
Configuring BFD with OSPF for Profiles
You can configure BFD for OSPF for Profiles.
By default, BFD is deactivated in OSPF. You can enable BFD for OSPF to subscribe to BFD session updates.
Enabling BFD for an OSPF neighbor does not create a BFD session. You must explicitly configure a BFD session. See Configure BFD for Profiles.
The following procedure describes how to enable BFD for an already configured OSPF session on an Edge Interface. To configure OSPF settings, see Activate OSPF for Profiles.
To configure the Interface settings, see Configure Interface Settings for Profiles.
Configuring BFD with OSPF for Edges
You can modify the inherited Profile settings at the Edge level for BFD for OSPF.
If required, you can override the configuration for a specific Edge as follows:
Configuring BFD for Gateways
You can configure BFD Settings for Gateways over IPsec tunnels.
- Create a Non SD-WAN Destination via Gateway for one of the following sites:
- Configuring a Non SD-WAN Destination of Type AWS VPN Gateway
- Configure a Non SD-WAN Destination of Type Cisco ISR
- Configure a Non SD-WAN Destination of Type Generic IKEv2 Router (Route Based VPN)
- Configure a Non SD-WAN Destination of Type Microsoft Azure Virtual Hub
- Configuring a Non SD-WAN Destination of Type Generic IKEv1 Router (Route Based VPN)
- Associate the Non SD-WAN Destination to a Profile. See Configure a Tunnel Between a Branch and a Non SD-WAN Destinations via Gateway.
Use the following steps to configure BFD for a Gateway:
Monitoring BFD Sessions
Monitor the BFD Sessions on Edges and Gateways. To view the BFD Sessions, use the following steps:
Monitoring BFD Events
View the events related to the BFD sessions.
In the SD-WAN service of the Enterprise portal, click .
To view the events related to BFD, use the Filter option. Click Filter next to the Search option and choose to filter the details by different categories.

The following events relate to BFD sessions:
- BFD session established to Gateway neighbor
- BFD session established to Edge neighbor
- BFDv6 session established to Edge neighbor
- Edge BFD Configuration
- Edge BFD IPv6 Configuration
- Edge BFD neighbor unavailable
- Edge BFDv6 neighbor unavailable
- Gateway BFD neighbor unavailable
Troubleshooting BFD
Run Remote Diagnostics tests to view the logs of the BFD sessions and use the log information for troubleshooting purposes.
Use the following steps to run tests for troubleshooting BFD:
Overlay Flow Control
The Overlay Flow Control page displays a summarized view of all the routes in your network.
For the 4.3 release, a new NSD bucket has been introduced for the classification of NSD Routes. The new NSD bucket preference logic applies only when the Use NSD policy is enabled along with the Distributed Cost Calculation. The Use NSD policy can only be enabled after you enable the Distributed Cost Calculation.
You can view and edit the global routing preferences and the advertise actions for the Edges, Hubs, Partner Gateways, and Non SD-WAN Destinations via Edge and Gateway.
Configuring Global Routing Preferences
In the Overlay Flow Control window, you can edit the global routing preferences, advertise actions, and modify the priorities of the destinations to where the traffic should be routed.
The VRF Global Routing Preferences section displays the Preferred VPN Exits and the Global Advertise Flags areas.
Configuring Subnets
In the Overlay Flow Control window, you can update the priorities of the destinations for the learned routes in the subnets.



































