Configure Dynamic Routing with OSPF or BGP
The system supports only eBGP when configuring BGP over IPsec.
The Edge learns routes from adjacent routers via OSPF and BGP, then transmits these routes to the Gateway/Controller. Acting as a route reflector, the Gateway/Controller distributes the learned routes to other Edges. The Overlay Flow Control (OFC) provides enterprise-wide route visibility and control, simplifying programming for both full and partial overlays.
The system supports Inbound/Outbound filters for OSPF neighbors, OE1/OE2 route types, and MD5 authentication. Routes that the Edge learns through OSPF automatically redistribute to the controller, whether hosted in the cloud or on-premises. Additionally, the administrator can apply BGP Inbound/Outbound filters and set them to Deny. Optionally, the administrator can add or modify BGP attributes—such as RFC 1998 community (https://datatracker.ietf.org/doc/html/rfc1998), MED, and local preference—to influence path selection.
Activate 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
- OSPFv2 supports only IPv4. OSPFv3 supports only IPv6 and is available starting with the 5.2 release.
- Route Summarization is available starting with the 5.2 release.
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 which prefixes the system redistributes into 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:
Configure 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
Arista VeloCloud SD-WAN supports 4-Byte ASN BGP. See Configure BGP, for additional information.
Route Summarization is new for the 5.2 release. For an overview, use case, and black hole routing details for Route Summarization, see section titled, Route Summarization. For configuration details, see the steps below.
To configure BGP:
- Users can also configure BGP for Non SD-WAN Destination Neighbors in an Edge. For additional information, see Configure BGP Over IPsec from Edge to Non SD-WAN Neighbors.
- Configure BGP
Configure BGP from Edge to Underlay Neighbors for Edges
Users can override the inherited Profile settings at the Edge level when configuring BGP from the Edge to Underlay Neighbors.
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. Users 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, allowing the addition of 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) creates BGP peering with the Azure Gateway.
Azure has a restriction that the BGP peer IP (Edge's local tunnel IP) cannot be on the same subnet as the Edge or on the 169.x.x.x subnet, and therefore, VeloCloud supports multi-hop BGP on the Edge. In BGP terminology, the local tunnel-ip maps to the BGP source address, and the peer tunnel-ip maps to the 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 is uniquely associated with one BGP connection, identified by the local tunnel_ip and the 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. 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) creates BGP peering with 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 set of public IPs allocated to a branch Edge from an AWS Gateway equals the number of Edge public WAN links that connect to the AWS VPN Gateway. Similarly, a /30 internal/private subnet allocates a per-tunnel address for BGP peering on that tunnel. The user can manually override these IPs in the 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. It 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 4 tunnels. It terminates in different public IPs on the AWS Gateway and four BGP connections.

Use Case 2- An Edge Connecting to Both AWS and Azure VPN Gateways (Hybrid Cloud)
An Edge at a single branch can connect to both an Azure Gateway and an AWS Gateway to provide redundancy or to reach specific workloads and applications hosted across different cloud providers. Regardless of a specific use case, the Edge always establishes one BGP session per tunnel and propagates routes between the SD-WAN and the IaaS environment. The following diagram shows an example of a branch Edge connected to both the Azure and AWS clouds.

Use Case 3- A Hub Cluster Connecting to Azure and AWS Transit Gateways
Hub cluster members can form IPsec tunnels to the Azure and AWS transit Gateways and leverage them as Layer 3 for routing traffic between different VPCs. Without the native BGP over IPsec functionality on the Hub, the Hub must connect to an L3 router via native BGP, and the L3 router forms a mesh of BGP over IPsec tunnels among different VPCs. The L3 router serves as a transit endpoint between different VPCs.
Use Case-1 uses a Hub as a transit node between VPCs in different Availability Zones (AZs), enabling communication between VPCs. 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 route distribution between cluster members. In both use cases, without support for BGP over IPsec on the Hub, the Hub connects to an L3 router like a CSR using native BGP and peers with a transit and VPC gateway using BGP over IPsec.

Use Case 4- 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 BGP over IPsec, can rely on SD-WAN Edge/Hub deployed in the cloud to achieve transit between different VPCs/VNETs. Without BGP over IPsec support, users must use an L3 router to achieve the transit functionality.
Next Steps- See Configure BGP over IPsec from Edge to Non SD-WAN Neighbors.
Configure BGP over IPsec from Edge to Non SD-WAN Neighbors
Prerequisites
- Ensure that users configure a tunnel between a branch and a 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:
Configure BGP Over IPsec from Gateways
The system supports only eBGP when configuring BGP over IPsec..
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.
- For the 5.2 release, when multiple NSDs are configured for the same segment, the same set of summary route configurations must be present across all NSDs.
- The Azure vWAN Automation from Gateway feature is not compatible with BGP over IPsec. It only supports static routes when automating connectivity from a Gateway to an Azure vWAN.
- Create a Non SD-WAN Destination via Gateway for one of the following sites:
- Configure 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 the 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
- Configure 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.
Monitor BGP Sessions
Users can monitor the BGP sessions on Edges and Gateways.
Monitor BGP Events
Users 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, users 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
Troubleshoot BGP Sessions
Users can run Remote Diagnostics tests to view the logs of the BGP sessions and use the log information for troubleshooting purposes.
OSPF and BGP Redistribution
The administrator may enable OSPF and BGP independently; this release removes the previous restriction that allowed only one active routing protocol. This version also enables the system to redistribute OSPF into BGP, BGP into OSPF (or both simultaneously), and other route sources such as overlay-learned prefixes, connected routes, and static routes.
With release 3.2, the system standardizes redistribution behavior to align with traditional routing vendor standards. For example, if multiple routes exist for the same prefix, the system only redistributes the best route from the system RIB to the destination protocol—provided the destination protocol configuration allows redistribution for that route type.
Consider a scenario where the administrator redistributes the prefix 192.168.1.0/24 into BGP. The system sees this prefix as locally available, learned from OSPF, and learned as an overlay prefix. If the system ranks the OSPF route higher than the overlay route based on OFC flow ordering, metrics, and preference, it redistributes the OSPF route into BGP (assuming the administrator turned on OSPF redistribution in BGP). Because the overlay prefix is not the "best" route in the system RIB, the system will not redistribute it into BGP, even if the administrator enabled overlay prefix redistribution.
To facilitate the redistribution of the best route for a prefix, the user enables redistribution for that specific route type. Alternatively, if the user prefers to redistribute a different route source, they can control the route’s precedence in the system RIB by using the Overlay Flow Control (OFC) facility or by adjusting 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 system assigns a transit metric of 0 if the Edge learns the route from a directly connected peer Edge.
- The system assigns a transit metric of 90 if the Edge learns the route via a Gateway.
- The system calculates the transit metric as 32 + the hub's order value if the Edge learns the route via a Hub Edge.
For OSPF External Type-1 (OE1) routes, the system uses this sum as the final metric. For OSPF External Type-2 (OE2) routes, the system adds the non-preferred metric constant (8388607) to that sum. This calculation explains why Edge peers receive such a high metric value for an OE2 route type.
Regarding BGP, this change means the Hub Edge now advertises BGP MED values starting from 33, 34, and 35, rather than the previous values of 9, 10, and 11.
BFD Settings Overview
Bidirectional Forwarding Detection (BFD) provides a simple Hello protocol similar to the detection components of well-known routing protocols. A pair of systems transmits BFD packets periodically over each path between them. If a system stops receiving BFD packets for a sufficiently long period, the neighboring system is assumed to have failed.
A BFD session is established based on the application's needs that will utilize BFD. The user must explicitly configure the address and parameters for the BFD session, and the subscribers/applications (BGP/OSPF) associated with the session, since there is no discovery mechanism in BFD.
Routing protocols such as Border Gateway Protocol (BGP) or Open Shortest Path First (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 to the other entity at a frequently configured interval, known as the keepalive time. These routing protocols have higher keepalive timers, which results in alonger duration to detect the route failures. BFD detects route failures between two connected entities more quickly with minimal overhead in failure detection.
- 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 functions as a simple service within the network architecture. The service primitives provided by BFD enable the creation, destruction, and modification of 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
Configure BFD for Profiles
VeloCloud SD-WAN enables the configuration of Bidirectional Forwarding Detection (BFD) sessions to detect route failures between two connected entities.
Configure BFD for Edges
Use the following steps to override the configuration for a specific Edge:
Configure BFD with BGP for Profiles
Configure Bidirectional Forwarding Detection (BFD) for Border Gateway Protocol (BGP) on SD-WAN Profiles.
Enabling BFD for a BGP neighbor does not create a BFD session. Users 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, users must be an Operator super user. For additional information, refer to the Configure Partner Handoff section in the VeloCloud SD-WAN Operator Guide.
Configure BFD with BGP for Edges
Enterprise users can override the inherited settings at the Edge level for Bidirectional Forwarding Detection (BFD) for Border Gateway Protocol (BGP).
Configure BFD with OSPF for Profiles
Enabling BFD for an OSPF neighbor does not create a BFD session. Users 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 Configure OSPF for Profiles.
To configure the Interface settings, see Configure Interface Settings for Profiles.
Configure BFD with OSPF for Edges
Enterprise users can modify the inherited Profile settings at the Edge level for Bidirectional Forwarding Detection (BFD) for Open Shortest Path First (OSPF).
Configure BFD for Gateways
- Create a Non SD-WAN Destination via Gateway for one of the following sites:
- Configure a Non SD-WAN Destination of Type AWS VPN Gateway
- Configure a Non SD-WAN Destination of the 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 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.
To configure BFD for a Gateway:
Monitor BFD Sessions
Monitor the Bidirectional Forwarding Detection (BFD) Sessions on Edges and Gateways. To view the BFD Sessions, use the following steps:
Monitor BFD Events
View the events related to the Bidirectional Forwarding Detection (BFD) sessions.
In the SD-WAN service of the Enterprise portal, select .
To view the events related to BFD, select the Filter option. Select the Filter icon next to the Search option and filter the details by different categories.

- BFD session established to the Gateway neighbor
- BFD session established to the Edge neighbor
- BFDv6 session established to the Edge neighbor
- Edge BFD Configuration
- Edge BFD IPv6 Configuration
- Edge BFD neighbor unavailable
- Edge BFDv6 neighbor unavailable
- Gateway BFD neighbor unavailable
Troubleshoot BFD
Run Remote Diagnostics tests to view the logs of the Bidirectional Forwarding Detection (BFD) sessions and utilize the log information for troubleshooting purposes.
Overlay Flow Control
The 4.3 release introduces a new Non SD-WAN Destination (NSD) bucket for classifying NSD Routes. The new NSD bucket preference logic applies only when both the Use NSD policy and the Distributed Cost Calculation are enabled. Ensure that the user enables Distributed Cost Calculation before the user can enable the Use NSD policy.
Users can view and edit the global routing preferences and the advertised actions for the Edges, Hubs, Partner Gateways, and Non SD-WAN Destinations via Edge and Gateway.
Configure Global Routing Preferences
In the Overlay Flow Control window, the Enterprise users can edit global routing preferences, define advertise actions, and modify the priorities of the destinations where the system routes traffic.




































