Configure 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.
Activate OSPF for Profiles
Open Shortest Path First (OSPF) can be enabled only on a LAN interface as an active or passive interface. The Edge will only advertise the prefix associated with that LAN switch port. To get full OSPF functionality, you must use it in routed interfaces.
- Support for OSPFv3 is introduced in the SD-WAN Edge for IPv6 underlay routing in addition to existing BGPv6 support. The following is supported:
- Underlay IPv6 route learning.
- Redistribution of OSPFv3 routes into overlay/BGP and vice-versa.
- Support for Overlay Flow Control (OFC).
- OSPFv3 is implemented with feature parity to OSPFv2 with the following exceptions:
- Point to Point (P2P) is not supported.
- BFDv6 with OSPFv3 is not supported.
- md5 authentication is not available, as OSPFv3 header does not support it.
To activate OSPF, perform the steps in the procedure below:
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
Open Shortest Path First (OSPF) can be enabled on a LAN (routed and switched) or a WAN interface. But only a LAN interface can be activated as an active or passive interface. The Edge will only advertise the prefix associated with that LAN switch port. To get full OSPF functionality, you must use it in routed interfaces. After you configure the OSPF settings at the Profile level, all the Edges associated with the Profile will inherit the OSPF configuration from the Profile. However, you cannot override the OSPF configuration settings at the Edge level.
- In the SD-WAN service of the Enterprise portal, select .
- Select the Device icon next to an Edge, or select the link to an Edge and then select the Device tab.
- Go to the Routing & NAT section and select the arrow next to OSPF.
- In the OSPF section, you can view all the inherited OSPF configuration such as OSPF areas, Redistribution settings for OSPFv2/v3, BGP settings, and Route Summarization.

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
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.
Arista supports 4-Byte ASN BGP. See Configure BGP, for additional information.
To configure BGP:
Configure 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.
- In the SD-WAN service of the Enterprise portal, select . The Edges page displays the existing Edges.
- Select the link to an Edge or select the View link in the Device column of the Edge.
- Go to the Routing & NAT section and select the arrow next to BGP to expand.
- The BGP settings configured for the associated Profile are displayed. If required, you can select the Override check box and modify the BGP Settings.
Note: When overriding and configuring BGP neighbors at the Edge level, any Profile-level filters associated with the neighbors will be removed when you switch the Edge from one profile to another. So at the Edge level, you must make sure to re-associate the filters with the BGP neighbors after switching the Edge profile.
- In addition to the BGP settings configured for a Profile, you can select an Edge Interface configured in the segment as the source Interface for BGP. For the IPv4 address type, you can select only the Loopback Interface as Source Interface and for the IPv6 address type, you can select any Edge Interface as the Source Interface.
This field is available:
- Only when you choose to override the BGP Settings at the Edge level.
- For eBGP, only when Max-hop count is more than 1. For iBGP, it is always available as iBGP is inherently multi-hop.
Important:- You cannot select an Edge Interface if you have already configured a local IP address in the Local IP field.
- You cannot configure a local IP address if you have selected an Edge Interface in the Source Interface drop-down list.
- Select Save Changes in the Device screen to save the modified configuration.
Configure BGP Over IPsec from Edge to Non SD-WAN Neighbors
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.
Use Case 1- BGP Over IPSec from an Edge to an Azure 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 2- BGP Over IPSec from Edge to AWS VPN and Transit Gateway
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 router using 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.
Configuration Procedure
- Ensure that you have configured Configure a Tunnel Between a Branch and a Non SD-WAN Destinations via Edge to configure BGP with NSD Neighbors.
- The Local IP address from the Edge is required to configure BGP with NSD Neighbors.
Use the following steps to enable BGP with Non SD-WAN neighbors:
- In the SD-WAN service of the Enterprise Portal, select Configure.
- From the left menu, select Edges. The Edges page displays.
- Select an Edge from the list of available Edges.
- Go to the Routing & NAT section in the UI and select the arrow next to BGP.
- In the BGP area, check the Override check box and toggle the radio button from Off to On.
Figure 15. Configuring BGP Settings 
In the BGP Editor window, configure the following settings:
- Enter the local Autonomous System Number (ASN) and then configure the following in the BGP Settings section.
- Configure the BGP Settings:
Table 11. BGP Settings Option Descriptions Option Description Router ID Enter the global BGP router ID. If you do not specify any value, the ID is automatically assigned. If you have configured a loopback Interface for the Edge, the IP address of the loopback Interface will be assigned as the router ID. Keep Alive Enter the keep alive timer in seconds, which is the duration between the keep alive messages that are sent to the peer. The range is from 0 to 65535 seconds. The default value is 60 seconds. Hold Timer Enter the hold timer in seconds. When the keep alive message is not received for the specified time, the peer is considered as down. The range is from 0 to 65535 seconds. The default value is 180 seconds. Uplink Community Enter the community string to be treated as uplink routes. Uplink refers to link connected to the Provider Edge(PE). Inbound routes towards the Edge matching the specified community value will be treated as Uplink routes. The Hub/Edge is not considered as the owner for these routes.
Enter the value in number format ranging from 1 to 4294967295 or in AA:NN format.
Enable Graceful Restart check box Please note when selecting this check box: The local router does not support forwarding during the routing plane restart. This feature supports preserving forwarding and routing in case of peer restart.
- Select +Add in the Filter List area to create one or more filters. These filters are applied to the neighbor to deny or change the attributes of the route. The same filter can be used for multiple neighbors.
Figure 16. Adding Filters to the BGP Configuration 
- In the appropriate text fields, set the rules for the filter:
Table 12. Filter Rules Option Descriptions Option Description Filter Name Enter a descriptive name for the BGP filter. Match Type and Value Choose the type of the routes to be matched with the filter: - Prefix for IPv4 or IPv6: Choose to match with a prefix for IPv4 or IPv6 address and enter the corresponding prefix IP address in the Value field.
- Community: Choose to match with a community and enter the community string in the Value field.
Exact Match The filter action is performed only when the BGP routes match exactly with the specified prefix or community string. By default, this option is enabled. Action Type Choose the action to be performed when the BGP routes match with the specified prefix or the community string. You can either permit or deny the traffic. Action Set When the BGP routes match the specified criteria, you can set to route the traffic to a network based on the attributes of the path. Select one of the following options from the drop-down list: - None: The attributes of the matching routes remain the same.
- Local Preference: The matching traffic is routed to the path with the specified local preference.
- Community: The matching routes are filtered by the specified community string. You can also select the Community Additive check box to enable the additive option, which appends the community value to existing communities.
- Metric: The matching traffic is routed to the path with the specified metric value.
- AS-Path-Prepend: Allows pre-pending multiple entries of Autonomous System (AS) to a BGP route.
- To add more matching rules to the filter, select the Plus ( + ) icon.
- Select OK to create the filter.
The configured filters are displayed in the BGP Editor window.
- Configure Underlay Neighbors for IPv4 and IPv6 addresses, as required. For additional information, see Configure BGP from Edge to Underlay Neighbors for Edges.
Note: The maximum number of supported BGPv4 Match/Set rules is 512 (256 inbound, 256 outbound). Exceeding 512 total Match/Set rules is not supported and may cause performance issues, resulting in disruptions to the enterprise network.
- In the NSD Neighbors section, configure the following settings:
Table 13. NSD Neighbors Option Descriptions Option Description NSD Name Select the NSD Name from the drop-down list. The NSDs already configured in the Branch to Non SD-WAN Destination via Edge area of the Orchestrator are displayed in the drop-down list. Link Name Choose the name of the WAN link associated with the NSD neighbor. Tunnel Type Choose the tunnel type of the Peer as Primary or Secondary. Neighbor IP Enter the IP address of the NSD neighbor. ASN Enter the ASN for the NSD neighbor. Inbound Filter Select an Inbound filer from the drop-down list. Outbound Filter Select an Outbound filer from the drop-down list. Additional Options– Select theview all link to configure the following additional settings: Uplink Used to flag the neighbor type to Uplink. Select this flag option if it is used as the WAN overlay towards MPLS. It will be used as the flag to determine whether the site will become a transit site (e.g. SD-WAN Hub), by propagating routes leant over a SD-WAN overlay to a WAN link toward MPLS. If you need to make it a transit site, select the Overlay Prefix Over Uplink check box in the Advanced Settings. Local IP Local IP is mandatory for configuring Non SD-WAN Neighbors. Local IP address is the equivalent of a loopback IP address. Enter an IP address that the BGP neighborships can use as the source IP address for the outgoing packets. Max-hop Enter the number of maximum hops to enable multi-hop for the BGP peers. For the 5.1 release and later, the range is from 2 to 255 and the default value is 2. Note: When upgrading to the 5.1 release, any max-hop value of 1 will automatically be updated to a max-hop value of 2.Note: This field is available only for eBGP neighbors, when the local ASN and the neighboring ASN are different. With iBGP, when both ASNs are the same, multi-hop is deactivated by default and this field is not configurable.Allow AS Select the check box to allow the BGP routes to be received and processed even if the Edge detects its own ASN in the AS-Path. Default Route The Default Route adds a network statement in the BGP configuration to advertise the default route to the neighbor. Enable BFD Enables subscription to existing BFD session for the BGP neighbor. Note: Single-hop BFD session is not supported for BGP over IPSec with NSD Neighbors. However, multi-hop BFD is supported. Local IP is mandatory for NSD-BGP sessions on the SD-WAN Edge. The SD-WAN Edge handles only the connected Interface IPs as a single-hop BFD.Keep Alive Enter the keep alive timer in seconds, which is the duration between the keep alive messages that are sent to the peer. The range is from 0 to 65535 seconds. The default value is 60 seconds. Hold Timer Enter the hold timer in seconds. When the keep alive message is not received for the specified time, the peer is considered as down. The range is from 0 to 65535 seconds. The default value is 180 seconds. Connect Enter the time interval to try a new TCP connection with the peer if it detects the TCP session is not passive. The default value is 120 seconds. MD5 Auth Select the check box to enable BGP MD5 authentication. This option is used in a legacy network or federal network, and it is common that BGP MD5 is used as a security guard for BGP peering. MD5 Password Enter a password for MD5 authentication. Note: Starting from the 4.5 release, the use of the special character "<" in the password is no longer supported. In cases where users have already used "<" in their passwords in previous releases, they must remove it to save any changes on the page.Note: Over Multi-hop BGP, the system might learn routes that require recursive lookup. These routes have a next-hop IP which is not in a connected subnet, and do not have a valid exit interface. In this case, the routes must have the next-hop IP resolved using another route in the routing table that has an exit interface. When there is traffic for a destination that needs these routes to be looked up, routes requiring recursive lookup will get resolved to a connected Next Hop IP address and interface. Until the recursive resolution happens, the recursive routes point to an intermediate interface. For additional information about Multi-hop BGP Routes, see the Remote Diagnostic Tests on Edges section in the Arista VeloCloud SD-WAN Troubleshooting Guide. - Select Advanced to configure the following settings:
Note: Advanced Settings are shared across both the underlay BGP neighbors and NSD BGP neighbors.
Table 14. Advanced BGP Settings Option Descriptions Option Description Overlay Prefix Select the check box to redistribute the prefixes learned from the overlay. Turn off AS-Path carry over By default, this should be left unchecked. Select the check box to turn off AS-PATH Carry Over. In certain topologies, turning off AS-PATH Carry Over will influence the outbound AS-PATH to make the L3 routers prefer a path towards an Edge or a Hub. Warning: When the AS-PATH Carry Over is turned off, tune your network to avoid routing loops.Connected Routes Select the check box to redistribute all the connected Interface subnets. OSPF Select the check box to enable OSPF redistribute into BGP. Set Metric When you enable OSPF, enter the BGP metric for the redistributed OSPF routes. The default value is 20. Default Route Select the check box to redistribute the default route only when Edge learns the BGP routes through overlay or underlay. When you select the Default Route option, the Advertise option is available as Conditional.
Overlay Prefixes over Uplink Select the check box to propagate routes learned from overlay to the neighbor with uplink flag. Networks Enter the network address that BGP will be advertising to the peers. Select the Plus ( + ) icon to add more network addresses. When you enable the Default Route option, the BGP routes are advertised based on the Default Route selection globally and per BGP neighbor, as shown in the following table.
Table 15. Default Route Selection Global Per BGP Neighbor Advertising Options Yes Yes The per BGP neighbor configuration overrides the global configuration and hence default route is always advertised to the BGP peer. Yes No BGP redistributes the default route to its neighbor only when the Edge learns an explicit default route through the overlay or underlay network. No Yes Default route is always advertised to the BGP peer. No No The default route is not advertised to the BGP peer. - Select OK to save the configured filters and NSD Neighbors.
The BGP Settings section displays the configured settings.
- To configure Route Summarization, select +Add in the Route Summarization area and configure the required settings. For additional details, see Route Summarization.
Figure 17. Add Route Summarization 
- Under the Subnet column, enter the network range that you want to summarize in the A.B.C.D/M format and the IP subnet.
- Under the AS Set column, select the Yes check box if applicable.
- Under the Summary Only column, select the Yes check box to allow only the summarized route to be sent.
- Add additional routes, if necessary, by selecting +Add. To Clone or Delete a route summarization, use the appropriate buttons, located next to +Add.
- Select Save Changes when complete to save the configuration.
You can also configure BGP from Edge to underlay neighbors. For additional information, see Configure BGP from Edge to Underlay Neighbors for Edges.
Configure BGP Over IPsec from 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 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 Sonic WALL
- 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.
Note: It is recommended to turn on Distributed Cost Calculation for best performance and scaling when using BGP over IPsec via Gateway. The Distributed Cost Calculation is supported starting from Release 3.4.0.
For additional information on Distributed Cost Calculation, refer to the Configure Distributed Cost Calculation section in the Arista VeloCloud SD-WAN Operator Guide.
You can configure BGP Settings for Gateways over IPsec tunnels.
Arista VeloCloud SD-WAN 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.
Monitor BGP Sessions
You can monitor the BGP sessions on Edges and Gateways.
Monitor BGP Events
You can view the events related to the BGP sessions.
Troubleshooting BGP Settings
You can run Remote Diagnostics tests to view the logs of the BGP sessions and use the log information for troubleshooting purposes.
To run the tests for BGP:
OSPF/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, we are standardizing 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. Let's say 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.
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 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
Bidirectional Forwarding Detection (BFD) is a simple Hello protocol that is 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
Configure 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:
- To enable BFD for BGP, see Configure BFD for BGP for Profiles.
- To enable BFD for OSPF, see Configure BFD for OSPF for Profiles.
- To view the BFD sessions, see Monitor BFD Sessions.
- To view the BFD events, see Monitor BFD Events.
- For troubleshooting and debugging BFD, see Troubleshooting BFD.
Configure 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.
To override the configuration for a specific Edge:
Configure BFD for BGP for Profiles
You can 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 additional information, see the Configure Partner Handoff section in the Arista VeloCloud SD-WAN Operator Guide.
Configure BFD for BGP for Edges
You can override the inherited settings at the Edge level for BFD for BGP.
To override the configuration for a specific Edge:
Configure BFD for 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 discusses 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 Profile.
Configure BFD for 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:
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 Type Cisco ISR
- Configure a Non SD-WAN Destination of Type Generic IKEv1 Router (Route Based VPN)
- 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
- Associate the Non SD-WAN Destination to a Profile See Configure a Tunnel Between a Branch and a Non SD-WAN Destinations via Gateway.
You can configure BFD Settings for Gateways over IPsec tunnels.
To configure BFD settings for a Gateway:
Monitor BFD Sessions
You can monitor the BFD sessions on Edges and Gateways.
To view the BFD sessions:
Monitor BFD Events
You can view the events related to the BFD sessions.
Troubleshooting BFD
You can run Remote Diagnostics tests to view the logs of the BFD sessions and use the log information for troubleshooting purposes.
To run the tests for BFD:
Overlay Flow Control
The Overlay Flow Control page displays a summarized view of all the routes in your network.
A new NSD bucket has been introduced for the classification of NSD Routes. The new NSD bucket preference logic will be applicable 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.
To configure the Overlay Flow Control settings, perform the following steps:
Configure 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. To edit these areas, refer to the following procedural steps:
Configure Subnets
In the Overlay Flow Control window, you can update the priorities of the destinations for the learned routes in the subnets.

































