Configure Edge Overrides
Configuration overrides can be made to some settings that were assigned to an Edge. In most cases, an override must first be activated, and then changes can be made.
Override rules can be added to existing Business Policy and Firewall rules. Override rules have precedence over all other rules defined for Business Policy or Firewall. For additional information, see Create Business Policy Rule and Configure Firewall Rule.
To override configuration settings for a specific Edge:
- In the SD-WAN service of the Enterprise portal, go to . 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. The configuration options for the selected Edge are displayed in the Device tab.
Figure 1. Configure Edge Overrides 
- The View drop-down menu at the left side of the page allows the user to select the view options. The available options are Expand All and Collapse All. By default, the settings are collapsed.
- The Sort drop-down menu at the left side of the page allows the user to select the sort options: Sort by category and Sort by segment aware. You can view the configuration settings sorted by category or segment aware. By default, the settings are sorted by category. If you choose to sort by segmentation, the settings are grouped as segment aware and segment agnostic.
- For some of the settings, the configuration is inherited from the associated Profile. To edit inherited configuration for the Edge, select the Override check box.
- After modifying the required settings, select Save Changes.
Note: On the Device page, whenever you make configuration changes for the selected Edge, an action bar appears at the bottom of the screen. You can select the notification to view the recent configuration changes and save the changes made to the Edge.
- Select the Shortcuts option to perform the following activities:
- Monitor – Navigates to the Monitoring tab of the selected Edge. See Monitor Edges.
- View Events – Displays the Events related to the selected Edge.
- Remote Diagnostics – Enables to run the Remote Diagnostics tests for the selected Edge. See Run Remote Diagnostics.
- Generate Diagnostic Bundle – Allows to generate Diagnostic Bundle for the selected Edge. See Diagnostic Bundles for Edges.
- Remote Actions – Allows to perform the Remote actions for the selected Edge. See Remote Actions.
- View Profile – Navigates to the Profile page, that is associated with the selected Edge.
- View Gateways – Displays the Gateways connected to the selected Edge.
Edge Device Configurations—A Roadmap
At the Edge-level, some configurations are Segment Aware, that is the configurations must be enabled for each segment where they are intended to work. Whereas, other configurations are Segment Agnostic across multiple segments.
The following table provides the list of Edge-level configurations:
| Settings | Description |
|---|---|
| VLAN | Configure the VLANs with both IPv4 and IPv6 addresses for Edges. Select the IPv4 or IPv6 tabs to configure the corresponding IP addresses for the VLANs. For additional information, see Configure VLAN for Edges. |
| Loopback Interfaces | Configure a logical interface that allows you to assign an IP address, which is used to identify an Edge. For additional information, see Configure a Loopback Interface for an Edge. |
| Management Traffic | Configure the management traffic by selecting a source IP for the Edge to transmit the traffic to VeloCloud Orchestrator. For additional information, see Configure Management Traffic for Edges. |
| ARP Timeouts | By default, the Edge inherits the ARP settings from the associated Profile. Select the Override and Override default ARP Timeouts checkboxes to modify the values. For additional information, see Configure Address Resolution Protocol Timeouts for Edges. |
| Interfaces | Configure the following settings for the Edge Interfaces:
|
| Global IPv6 | Activate IPv6 configurations globally. See Global IPv6 Settings for Edges. |
| Wi-Fi Radio | Activate or deactivate Wi-Fi Radio and configure the band of radio frequencies. For additional information, see Configure Wi-Fi Radio Overrides.
Note: The Wi-Fi Radio option is available only for the following Edge models: 500, 5X0, Edge 510, Edge 510-LTE, Edge 6X0, and Edge 610-LTE.
|
| Common Criteria Firewall | Common Criteria (CC) is an international certification accepted by many countries. Obtaining the CC certification is an endorsement that our product has been evaluated by competent and independent licensed laboratories for the fulfilment of certain security properties. This certification is recognized by all the signatories of the Common Criteria Recognition Agreement (CCRA). The CC is the driving force for the widest available mutual recognition of secure IT products. Having this certification is an assurance of security to a standard extent and can provide Arista with the much needed business parity or advantage with its competitors.
Enterprise users can configure the Common Criteria Firewall settings. By default, this feature is deactivated. See Configure Common Criteria Firewall Settings for Edges. |
| Settings | Description |
|---|---|
| Cloud VPN | Allows Cloud VPN to initiate and respond to VPN connection requests. In the Cloud VPN, you can establish tunnels as follows:
Select the check boxes as required and configure the parameters to establish the tunnels. See Configure Cloud VPN and Tunnel Parameters for Edges. |
| Non SD-WAN Destination via Edge | Allows to establish tunnel between a branch and Non SD-WAN destination via Edge. See Configure a Tunnel Between a Branch and a Non SD-WAN Destinations via Edge.
Select Add to add Non SD-WAN Destinations. Select New NSD via Edge to create new Non SD-WAN Destination via Edge. See Configure Non SD-WAN Destinations via Edge. |
| Hub or Cluster Interconnect | Arista VeloCloud SD-WAN supports interconnection of multiple Hub Edges or Hub Clusters to increase the range of Spoke Edges that can communicate with each other. This feature allows communication between the Spoke Edges connected to one Hub Edge or Hub Cluster and the Spoke Edges connected to another Hub Edge or Hub Cluster, using multiple overlay and underlay connections. See Hub or Cluster Interconnect. |
| Cloud Security Service | Allows to establish a secured tunnel from an Edge to cloud security service sites. This enables the secured traffic being redirected to third-party cloud security sites. See Cloud Security Services. |
| Zscaler | Allows to establish a secured tunnel from an Edge to Zscaler sites. See Configure Zscaler Settings for Edges. |
| Gateway Handoff Assignment | Allows to assign Partner Gateways for Profiles or Edges. In order for customers to be able assign Partner Gateways, the Partner Handoff feature must be activated for the customers. See Assign Partner Gateway Handoff. |
| Controller Assignment | Allows to assign Controllers for Profiles or Edges. In order for customers to be able assign Controllers, the Partner Handoff feature must be activated for the customers. See Assign Controllers. |
| Settings | Description |
|---|---|
| Multicast | Configure Multicast to send data to only interested set of receivers. See Configure Multicast Settings for Edges. |
| BFD | By default, the Edge inherits the BFD configuration settings from the associated Profile. If required, you can select the Override checkbox to modify the settings. For additional information, see Configure BFD for Edges. |
| LAN-Side NAT Rules | Allows you to NAT IP addresses in an unadvertised subnet to IP addresses in an advertised subnet. See LAN-side NAT Rules at Edge Level. |
| ICMP Probes | Configure ICMP probes that check for the network continuity by pinging specified IP address at frequent intervals. See Configure ICMP Probes/Responders. |
| ICMP Responders | Configure ICMP Responders that respond to ICMP probes from a specified IP address. See Configure ICMP Probes/Responders. |
| Static Route Settings | Configure Static Route Settings for special cases in which static routes are needed for existing network attached devices, such as printers. See Configure Static Route Settings. |
| DNS | Use the DNS Settings to configure conditional DNS forwarding through a private DNS service and to specify a public DNS service to be used for querying purpose. See Configure DNS for Edges. |
| OSPF | The OSPF settings configured in the associated Profile are displayed. You can configure OSPF areas only for a Profile and only for a Global Segment. For Edges, you can configure additional OSPF settings for routed Interfaces. For additional information, see Activate OSPF for Edges. |
| BGP | Configure BGP settings for Underlay Neighbors and Non SD-WAN Neighbors. See Configure BGP. |
| Settings | Description |
|---|---|
| High Availability | Activate High Availability for the selected Edge. Choose one of the following options:
For additional information, see Configure High Availability Settings for Edges. |
| Settings | Description |
|---|---|
| Visibility Mode | Choose the visibility mode to track the network using either MAC address or IP address. See Configure Visibility Mode for Edges. |
| Syslog | Configure Syslog collector to receive VeloCloud Orchestrator bound events and firewall logs from the Edges configured in an Enterprise. See Configure Syslog Settings for Edges. |
| Netflow Settings | As an Enterprise Administrator, at the Edge level, you can override the Netflow settings specified in the Profile. Configure Netflow Settings for Edges. |
| SNMP | Enable the required SNMP version for monitoring the network. Ensure that you download and install all the required SNMP MIBs before enabling SNMP. See Configure SNMP Settings for Edges. |
| Settings | Description |
|---|---|
| Security VNF | Configure security VNF to run the functions of a network service in a software-only form. For additional information, see Security Virtual Network Functions. |
| Settings | Description |
|---|---|
| Authentication | Allows to select a RADIUS server to be used for authenticating a user. For additional information, see Configure Authentication Settings for Edges.
Select New RADIUS Service to create a new RADIUS server. For additional information, see Configure Authentication Services. |
| NTP | Allows to synchronize the system clocks of Edges and other network devices. See Configure NTP Settings for Edges. |
Configure VLAN for Edges
At the Edge level, you can add a new VLAN or update the existing VLAN settings inherited from the associated Profile. While configuring a new VLAN at the Edge level, VeloCloud Orchestrator allows you to configure additional Edge-specific VLAN settings such as Fixed IP addresses, LAN interfaces, and Service Set Identifier (SSID) of Wi-Fi interfaces.
To configure VLAN settings for an Edge:
Loopback Interfaces Configuration
A loopback interface is a logical interface that allows you to assign an IP address, which is used to identify a VeloCloud SD-WAN Edge.
You can configure loopback interfaces only for SD-WAN Edges that are running on version 4.3 and above. The Configure Loopback Interfaces area is not available for SD-WAN Edges that are running on version 4.2 or lower. For such Edges, you must configure Management IP address. For details, refer to Configure Management IP Address for Profiles.
Benefits of Loopback Interface
- As loopback interfaces are logical interfaces that are always up and reachable, you can use these interfaces for diagnostic purposes as long as there is layer 3 reachability to at least one physical interface.
- Loopback interfaces can be used as source interface for BGP. This ensures that when the BGP's interface state flaps, the BGP membership does not flap if there is at least one Layer 3 connection available.
- Loopback interface IP address can be used as the source IP address for the various services such as Orchestrator Management Traffic, Authentication, DNS, NetFlow, Syslog, TACACS, BGP, and NTP. As loopback interfaces are always up and reachable, these services can receive the reply packets, if at least one physical interface configured for the Edge has layer 3 reachability.
Limitations of Loopback Interfaces
- Only IPv4 addresses can be assigned for loopback interfaces.
- Loopback interfaces can be configured only for Edges. They cannot be configured for Profiles.
- Loopback interfaces must be configured only after the Edge activation is successful.
- For any Edge that is not activated, the version of the customer operator profile is validated based on which either the Management IP Address section or the Loopback Interfaces section is visible. For example, if the version of the customer operator profile is 4.3 or above, the Loopback Interfaces section is visible at the Edge-level. Whereas, if the version of the customer operator profile is 4.2 or lower and the Edge is not activated, the Management IP Address section is visible at the Edge-level and Profile-level.
- Loopback interface IDs must be unique across all segments within an Edge and must start from 1, as Zero (0) is not supported.
- If you choose to configure loopback interfaces and Orchestrator management traffic through API, the default configuration keys for these two properties are not available. You must modify the
updateConfigurationModuleAPI to configure the loopback interface and management traffic source interface selection. - You can access loopback interfaces only through SSH. Loopback interface access through local Web UI is not supported.
- Consider the following when you upgrade or downgrade your Edges:
- If the Management IP address that is configured either at the Profile-level or at the Edge-level is not the default IP address (
192.168.1.1) and when the Edge is upgraded to version 4.3 or above, the loopback interface is automatically created at the Edge-level with the configured Management IP address as the IP address of the loopback interface. - Consider that you have upgraded your Orchestrator to version 4.3 or above, whereas the Edge still runs on version 4.2 or lower. If you update the Management IP address configuration either at the Profile-level or at the Edge-level, and then upgrade your Edge to version 4.3 or above, all changes that you made to the Management IP address configuration will be lost.
- When the Edge is downgraded to a version lower than 4.3, the Management IP address that was configured before the upgrade will be retained at the Profile-level and at the Edge-level.
- Any changes made to the loopback interface configuration will be lost after the Edge downgrade.
- For example, consider that you had the Management IP address as
1.1.1.1. When you upgrade your Edge to version 4.3 or above, the same IP address,1.1.1.1will be the IP address of the loopback interface at the Edge-level. Then, you change the loopback interface IP address to2.2.2.2. When you downgrade your Edge to a version lower than 4.3, you will notice that the Management IP address at the Edge-level will still be1.1.1.1and the Management IP address at the Profile-level will be empty.
- If the Management IP address that is configured either at the Profile-level or at the Edge-level is not the default IP address (
Configure a Loopback Interface for an Edge
For information about the rules and notes that you must consider before you configure a loopback interface, see Limitations of Loopback Interfaces.
To configure a loopback interface for an Edge:
At any point in time, you can choose to edit the loopback interface settings by selecting the Address link, except CIDR Prefix and Interface ID.
If you delete a loopback interface, the Source Interface field for all the services for which you have selected the loopback interface, is reset to Auto.
- If the loopback interface ID is not found in the Edge.
- If you use older versions of APIs to configure the Edge, sometimes the Edge may not receive the key for source IP address for the services.
- Any non-WAN interface that is advertised is prioritized.
- Among the non-WAN interfaces that are advertised, the source interface selection is based on the following order of priority—Loopback interfaces, VLAN interfaces, or any routed interfaces.
- If there are more than one interfaces of the same type configured and advertised, the interface with the lowest interface ID is selected.
For example, if you have two loopback interfaces (LO3 and LO4), one VLAN interface (VLAN2), and two routed interfaces (GE1 and GE2) configured and advertised, and if the Source Interface field for any service is set to Auto, the Edge selects LO3 as the source interface.
| Services/Settings | For details, refer to.. |
|---|---|
| Orchestrator Management Traffic | Configure Management Traffic for Edges |
| Authentication Settings | Configure Authentication Settings for Profiles |
| DNS Settings | Configure DNS for Profiles |
| Netflow Settings | Configure Netflow Settings for Edges |
| Syslog Settings | Configure Syslog Settings for Edges |
| BGP Settings | Configure BGP from Edge to Underlay Neighbors for Profiles |
| NTP Settings | Configure NTP Settings for Edges |
ConfigureManagement Traffic for Edges
You can configure the Management Traffic for the Edge to transmit the traffic to VeloCloud Orchestrator.
To configure the Management Traffic at the Edge level:
Configure Address Resolution Protocol Timeouts for Edges
At the Edge level, you can override the Address Resolution Protocol (ARP) Timeout settings inherited from a Profile by selecting the Override check box.
To override the ARP timeouts values at the Edge-level, perform the following steps:
Configure Interface Settings for Edges
An Edge has different types of Interfaces. By default, the Interface configuration settings of an Edge are inherited from the associated Profile. You can modify and configure additional settings for each Edge.
The Interface Settings options vary based on the Edge model. For additional information on different Edge models and deployments, see Configure Interface Settings.
To configure Interface settings for a specific Edge, perform the following steps:
Wi-Fi Access Control based on MAC Address
Wi-Fi Access Control can be used as an additional layer of security for wireless networks. When activated, only known and approved MAC addresses are permitted to associate with the base station.

In the SD-WAN service of the Enterprise portal, select and choose an existing WLAN interface to configure the following parameters.
| Option | Description |
|---|---|
| Interface Enabled | Select the check box to activate the interface. |
| VLAN | Choose the VLAN ID from the drop-down menu. |
| SSID | Enter the SSID. |
| Security | Select either WPA2/Enterprise or WPA2/Personal as the Security option. |
| Static MAC Allow List | Select the check box to permit only the listed MACs to associate with the access point.
When Static MAC Allow List is configured, only the Mac addresses specified in the list are permitted to associate with the access point. |
| Radius ACL Check | Select the check box to associate the MAC address with a RADIUS server. If an access-accept is received, the MAC is allowed to associate with the access point.
Note: RADIUS ACL checks are limited to WPA2/Enterprise security mode.
|
| Add | Select to enter a new MAC address. |
| Delete | Select to remove an existing MAC address. |
| MAC filtering for AP Probes | Enabling MAC Filtering for AP probes prevents probes from unapproved MAC Addresses from actively discovering AP parameters. When the SSID is not broadcast, this can assist in preventing unknown stations from connecting to the network. Some devices are known to use random MAC addresses for probing regardless of AP settings and probe filtering may cause these devices to fail to discover or connect to the network even if their device MAC has been approved. |
- Both, MAC filtering for AP Probes and RADIUS ACL Check cannot happen at the same time.
- SD-WAN Edge does not support Link Layer Discovery Protocol (LLDP).
Configure DHCP Server on Routed Interfaces
You can configure DHCP server on a Routed Interface in an SD-WAN Edge.
To configure DHCP Server settings:
Enable RADIUS on a Routed Interface
- A RADIUS server must be configured and added to the Edge. See Configure Authentication Services.
- RADIUS may be enabled on any routed interface. This includes the interfaces for any Edge model, except for the LAN 1-8 ports on Edge models 500/520/540.
RADIUS can be enabled on any interface that is configured as a routed interface. The SD-WAN Edge supports both username/password (EAP-MD5) and certificate (EAP-TLS) based 802.1x Authentication methods.
To enable RADIUS on a Routed Interface:
Configure RADIUS Authentication for a Switched Interface
- A RADIUS server must be configured and added to the Edge. See Configure Authentication Services.
- RADIUS may be configured on any switched interface.
This section discusses configuring user authentication with a RADIUS server using the 802.1x protocol on an Edge's switched interface through the use of a VLAN associated with that switched interface.
Beginning with SD-WAN Release 5.1.0, a user can configure RADIUS authentication to use an Edge's switched interface as they already had been able to do for a routed interface.
The SD-WAN Edge supports both username/password (EAP-MD5) and certificate (EAP-TLS) based 802.1x Authentication methods.
To configure RADIUS Authentication for a Switched Interface:
MAC Address Bypass (MAB) for RADIUS-based Authentication
- A RADIUS server must be configured and added to the Edge. See the topic Configure Authentication Services.
- The RADIUS server must have a list of MAC addresses to be bypassed to take advantage of the MAB feature.
- RADIUS authentication must be configured on an Edge's routed interface or switched interface via a VLAN either at the Profile or Edge level.
On routed interfaces customers can check MAC addresses against a RADIUS server to bypass 802.1x for LAN devices that do not support 802.1x authentication. MAB simplifies IT operations, saves time, and enhances scalability by no longer requiring customers to manually configure every MAC address that may need authentication.
- L2 traffic will not trigger RADIUS MAB.
- L2 traffic will not be forwarded on Linux-based switches until routed traffic is seen. Hardware switches already do not filter pure L2 traffic, and this limitation remains unchanged.
- If no routed traffic is observed and RADIUS MAB times out (default is 30 minutes), L2 traffic will again be blocked.
- Additional hooks to check 802.1x status for self-destined packets may cause performance degradation when 802.1x is enabled.
- Traffic destined to self and managed entirely by Linux will no longer be filtered prior to 802.1x authentication (DHCP, DNS, ssh, and so forth).
Activating MAB for Routed Interface
Activating MAB for Switched Port using a VLAN
Configure Edge LAN Overrides
An Edge has different types of Interfaces. By default, the Interface configuration settings of an Edge are inherited from the associated Profile. At the Edge level, you can override the LAN settings inherited from the Profile.
To override the LAN settings for an Edge:
Configure Edge WLAN Overrides
An Edge has different types of Interfaces. By default, the Interface configuration settings of an Edge are inherited from the associated Profile. At the Edge level, you can override the WLAN settings inherited from the Profile.
To override the WLAN settings for an Edge:
Configure Edge WAN Overlay Settings with New Orchestrator UI
The WAN Overlay settings enables you to add or modify a User-Defined WAN Overlay.
A user-defined overlay needs to be attached to an interface that has been configured ahead of time for WAN overlay. You can configure any one of the following Overlays:
- Private Overlay: This is required on a private network where you want to have the Edge build overlay VCMP tunnels directly between private IP addresses assigned to each Edge on the private network.
Note: In a Partner Gateway setup with handoff Interface configured, when an Edge with private Interface has both IPv4 and IPv6 user-defined overlays, the Edge tries to establish IP tunnels towards the public IP address of the Gateway based on the tunnel preference.
- Public Overlay: This is useful when you want to set a custom VLAN or source IP address and Gateway address for the VCMP tunnels, to reach SD-WAN Gateways over the Internet, as determined by the VeloCloud Orchestrator.
You can also modify or delete an existing auto-detected WAN Overlay that has been detected on a routed interface. An auto-detected overlay is available only when the Edge has successfully made a VCMP tunnel over a routed interface configured with WAN Overlay to Gateways designated by the VeloCloud Orchestrator.
To configure WAN Overlay settings for a specific Edge, perform the following steps:
Support for DSCP Value Tag Per User Defined Overlay
With the 5.0.0 release, network administrators will have the ability to add a DSCP tag to a specific overlay link. The DSCP tag would be applied at the outer header of the VCMP packet going over the overlay link, and will leverage the private network underlay DSCP tag to treat each overlay uniquely via the QoS setting defined on the WAN underlay network.
Enable Per link DSCP Check box
Select this check box to add a DSCP tag to a specific overlay link. The DSCP tag will be applied at the outer header of the VCMP packet going over this overlay link. This will provide the ability to leverage the private network underlay DSCP tag mechanism to treat each overlay uniquely via QoS setting defined at the upstream router.
Use Case: DSCP Value Per User Defined Overlay
In this use case, the requirement is to apply the WAN overlay DSCP tag value configured on the WAN link to all traffic egressing from this link, for the tunnel originating Edge. The configured DSCP value should apply to the VCMP outer header so that the MPLS network can read the DSCP value and apply differentiated services to the VCMP encapsulated packet. The inner DSCP tag value, coming from the LAN side of the edge network, should be kept unmodified. Requirements on the tunnel destination side: The hub or peer edge that is receiving the tunnel creation request must respond with the same DSCP overlay tag value sent by the tunnel originator on the VCMP outer header. The hub or peer edge terminating the overlay tunnel should not modify the inner DSCP tag destined for the LAN.
In the image below, the Enterprise is using DSCP values on their underlay network to provide differentiated services based on source WAN overlay link/tunnel.

Bandwidth Measurement Modes
This section discusses how bandwidth measurement is performed on a WAN link using the Arista SD-WAN service.
Once a WAN link is detected by the SD-WAN Edge, it first establishes DMPO (Dynamic Multi-Path Optimization) tunnels with one or more SD-WAN Gateways and performs a bandwidth test with the Primary Gateway. The bandwidth test is performed by sending a stream of bidirectional UDP traffic and measuring the received rate at each end. In addition, if the Edge is deployed as a Spoke in a Hub/Spoke topology, the Edge will also establish tunnels with the Hub Edge and perform a bandwidth test if configured to do so.
There are three modes of Bandwidth measurement available in SD-WAN.
Slow Start Mode
In Slow Start mode, the Edge sends a smaller burst of UDP traffic followed by a larger burst of UDP traffic to the SD-WAN Gateway. Based on the number of packets received by the Gateway, the Gateway calculates the WAN link's speed. In Slow Start mode, the Edge sends this traffic for a fixed duration of 5 seconds. In the first three seconds, the Edge sends the UDP traffic at a rate of 5000 packets per second, and for the remaining two seconds it sends the traffic at 20000 packets per second. The packet size of this UDP traffic matches the MTU size for that WAN link.
Slow start mode is configured by default for wired links. The Edge sends a steady stream of packets for a short period of time (in case the ISP is throttling the beginning of a session) and then ramps up to a 200 Mbps stream and measures how much is received.
The reason we do this is because there are some ISPs who need packet rates to be ramped up slowly before they allow the full packet rate as part of the link SLA.
Burst Mode
In Burst mode, the Edge sends the UDP packets as single burst (A fixed, high number of packets in one burst) to the Gateway. Based on the number of packets received by the Gateway, the Gateway calculates the speed. It will start the round with 416 packets. If the Gateway response mentions that the packets were received in a very short interval, it will restart with 2000 packets. The packet size of this UDP traffic is the link MTU size.
User Defined Mode (Define Manually)
- For WAN links with greater than 900 Mbps capacity (either upload or download).
- For WAN links on Edges being used as Hubs. (This applies to hubs or any edge with a high number of tunnels.)
- On private links like MPLS, it is recommended to configure the link with a user defined value because a private link has to perform a bandwidth measurement test with every other private link in the customer's network.
- For example in a network with multiple private links where the private peer link bandwidth values are 5 Mbps, 1 Mbps, and 500 Kbps respectively. The private link would do a bandwidth test to each of those private peer links, and may also end up measuring at the lowest peer link value. In a large network with a large number of private links, this would also be undesirable as each bandwidth measurement takes up link resources.
- If the bandwidth measurement is failing for that WAN link and no value is being registered for that link.
- Some other user preference such as deliberately limiting how much of the link capacity is used by the Edge.
Configuration

Important Notes and Limitations
- USB modems are not compatible with the slow start mode of measurement. The recommended bandwidth measurement mode for USB modem is “Burst Mode” (which is configured by default) and for wired WAN links “Slow Start” is recommended (which is configured by default).
- The Dynamic Bandwidth adjustment is recommended on links where available bandwidth can vary over time (especially wireless links). This setting will track WAN congestion and packet loss and adjust bandwidth down and up as needed. To avoid inducing congestion, bandwidth will never be adjusted to be higher than the originally measured value.
- Bandwidth is only measured to the local Gateway path unless the Edge is also a Spoke Edge in a Hub/Spoke topology. In that case bandwidth is also measured between the Spoke Edge and the Hub Edge.
- In a Hub/Spoke topology where the Hub Edge and a connected Spoke Edge have different bandwidth measurement modes configured (for example, the Hub Edge WAN link is configured with a user defined mode but the Spoke Edge's WAN link is configured with either Slow Start or Burst mode), a link measurement will be performed. However, SD-WAN will honor the user defined value if the measured value is greater than the user defined value. This explains why a customer can observe bandwidth measurement events on a Hub Edge even though the Hub Edge's WAN links are configured to not measure bandwidth with a user defined mode.
- When the path to the local Gateway is being measured the rest of the paths are in WAITING_FOR_LINK_BW. Once the measurement to the local Gateway path is done, the rest of the paths update their values and exchange it with their peer. This is also true when the Hub Edge is being measured by a Spoke Edge in a Hub/Spoke topology.
- The wireless links always default to Burst Mode of measurement.
- For wired links the cache is updated only on a successful measurement and this value is valid for 7 days. Bandwidth is only measured if a tunnel flaps or comes up and there is no cache or if there is a value in the cache but the last measurement was 7 days back. Wireless links have a similar behavior, but in their case the cache only needs to be older than 24 hours, and there needs to be a tunnel flap in order to trigger another bandwidth remeasurement.
- If the Automatic bandwidth measurement fails for some reason, a user can trigger a bandwidth measurement manually from the Orchestrator UI by navigating to Test & Troubleshoot → Remote Diagnostics → WAN Link Bandwidth Test.
- If the Automatic bandwidth measurement measures less than 90% of the originally measured (cached) value, it will not update the bandwidth. For example this will happen if you have a 1Gig link and downgrade it to a 500Mbps link, the bandwidth measurement will continue giving the old value of 1Gig. To work around this, Arista Support team will need to be engaged to delete the cached bandwidth measurement, then a new "WAN Link Bandwidth Test" can be ran from Remote Diagnostics.
- Hub Edges and Gateways process one bandwidth test at a time, to ensure accurate results. This is relevant to customers who either manually trigger multiple bandwidth measurements in a short time or make a bulk change via an API that can trigger multiple bandwidth measurements where all the tests use the same Hub Edge or Gateway.
SD-WAN Service Reachability via MPLS
An Edge with only Private MPLS links can reach the Orchestrator and Gateways located in public cloud, by using the SD-WAN Service Reachable option.
In a site with no direct public internet access, the SD-WAN Service Reachable option allows the private WAN to be used for private site-to-site VCMP tunnels and as a path to communicate with an internet hosted Arista service.
- If the Edge is a Hub, and Spoke Edges are using that Hub Edge as the internet breakout, their tunnels to the Gateway may not come up because the Hub Edge may forward those flows back out the private link.
- An Edge with this incorrect setting may appear offline in the Orchestrator. This is because it may try to use the private link to contact the Orchestrator.
MPLS-only Sites
Arista supports private WAN deployments with a hosted Arista service for customers with hybrid environments who deploy in sites with only a private WAN link.
In a site with no public overlays, the private WAN can be used as the primary means of communication with the Arista service, including the following:
- Enabled SD-WAN service reachability through private link
- Enabled NTP override using private NTP servers
The following image shows a Regional Hub with Internet connection and SD-WAN Edge with only MPLS connection.

The traffic from the SD-WAN Edge with MPLS-only links is routed to the Orchestrator and Gateway through a Regional Hub, which is able to break out to the public cloud. SD-WAN Service Reachable option allows the Edge to remain online and manageable from the Orchestrator, and allows public internet connectivity through the Gateway irrespective of whether or not there is public link connectivity.
Dynamic Failover via MPLS
If all the public Internet links fail, you can failover critical Internet traffic to a private WAN link. The following image illustrates Resiliency of the Orchestrator and Non SD-WAN Destination, Zscaler.

- Orchestrator Resiliency – The Orchestrator connects to the Internet. If the Internet fails, the Orchestrator will connect through MPLS. The Orchestrator connection is established using the IP Address which is advertised over MPLS. The connectivity leverages the public Internet link in the Regional Hub.
- Zscaler Resiliency – The Zscaler connectivity is established through Internet. If the public link fails, then Zscaler connects through MPLS.
Configure SD-WAN Service Reachable
Configure Class of Service
You can manage traffic by defining Class of Service (CoS) in a public or private WAN link. You can group similar types of traffic as a class. The CoS treats each class with its level of service priority.
For each Edge consisting of public or private WAN links, you can define the CoS.
Configure Hot Standby Link
Hot Standby link an enhanced backup link, for the WAN links of an Edge, with pre-established VCMP tunnels. When the active links are down, Hot Standby link enables immediate switchover by using the pre-established VCMP tunnels.
To configure a Hot Standby link on an Edge, ensure that the Edge is upgraded to software image version 4.0.0 or later.
You can monitor the Hot Standby links in the monitoring dashboard. See Monitor Hot Standby Links.
Monitor Hot Standby Links
You can monitor the Hot standby links and the corresponding status using the monitoring dashboard.
To view the status of Hot Standby links:
Global IPv6 Settings for Edges
For IPv6 addresses, you can activate some of the configuration settings globally.
To activate global settings for IPv6 at the Edge level:
Configure Wi-Fi Radio Overrides
- Before configuring the WI-FI radio band and channel for the Edge, it is important to set the correct country of operation for the Wi-Fi radio, to conform to local requirements for Wi-Fi transmission. Ensure that the correct country of operation for the Edge is set in the Contact & Location section of the Edge Overview configuration page. The address is populated automatically after the Edge is activated; however, you can override the address manually, if needed.
Note: The country should be specified using the 2-character ISO 3166-1-alpha-2 notation (for example, US, DE, IN, and so on.)
At the Edge level, you can override the WI-FI Radio settings specified in the Profile by selecting the Override checkbox. Based on the Edge model and the country configured for the Edge, WI-FI Radio settings allow you to select a radio band and channel supported for the Edge.
To override the WI-FI Radio settings at the Edge level, perform the following steps.
Configure Automatic SIM Switchover
- You must insert SIM cards in both the SIM slots on the Edge.
- This feature can be activated only on a standalone Edge where High Availability is deactivated. An error is displayed on the Orchestrator if you try to activate both, High Availability and Automatic Switchover features.
- Navigate to , and make sure that the IP Type, L2 Settings, and WAN Overlay settings are same for both Cell1 and Cell2. Other parameters like SIM PIN, Network, and APN need not be same.
- Both Cell1 and Cell2 interfaces must be activated before activating the Automatic Switchover feature. For additional information, see Configure Interface Settings for Edges.
This feature allows you to automate the process of LTE SIM switching in case of primary LTE connection failure. You can configure the Edge to automatically detect the primary LTE link failure and thereby initiate the process of establishing the secondary LTE link. When the Automatic Switchover feature is activated, and for some reason, the secondary LTE link is also down, the Edge tries to establish the connection with the primary link again. This process continues until the Edge detects an active LTE link. Also, if automatic switchover is in progress, manual switchover cannot be performed on the Edge.
To configure the Automatic SIM Switchover feature, perform the following steps:
Configure Common Criteria Firewall Settings for Edges
The Common Criteria (CC) Firewall settings are inherited from the Profile associated with the Edge and can be reviewed in the Edge Device tab. At the Edge level, you can choose to override the CC Firewall settings for an Edge.
To configure the CC Firewall settings at the Edge level, perform the following steps:
Configure Cloud VPN and Tunnel Parameters for Edges
The Edge Cloud VPN settings are inherited from the Profile associated with the Edge and can be reviewed in the Edge Device tab. At the Edge level, you can override these settings inherited from a Profile and configure tunnel parameters.
Configure Cloud Security Services for Edges
When you have assigned a profile to an Edge, the Edge automatically inherits the Cloud Security Service (CSS) and attributes configured in the profile. You can override the settings to select a different cloud security provider or modify the attributes for each Edge.
To override the CSS configuration for a specific Edge, perform the following steps:
- In the SD-WAN service of the Enterprise portal, select . The Edges page displays the existing Profiles.
- Select the link to an Edge or select the View link in the Device column of the Edge. The configuration options for the selected Edge are displayed on the Device tab.
- Under the VPN Services category, in the Cloud Security Service area, the CSS parameters of the associated profile are displayed.
- In the Cloud Security Service area, select the Override check box to select a different CSS or to modify the attributes inherited from the profile associated with the Edge. For additional information on the attributes, see Configure Cloud Security Services for Profiles.
- Select Save Changes in the Edges window to save the modified settings.
Manual Zscaler CSS Provider Configuration for Edges
At the Edge level, for a selected manual Zscaler CSS provider, you can override the settings inherited from the profile and can configure additional parameters manually based on the tunneling protocol selected for tunnel establishment.
If you choose to configure an IPsec tunnel manually, apart from the inherited attributes, you must configure a Fully Qualified Domain Name (FQDN) and Pre-Shared Key (PSK) for the IPsec session.

- Under GRE Tunnels, select +Add.
Figure 50. Configure GRE Tunnel Manually 
- When the Configure Tunnel window appears, configure the following GRE tunnel parameters, and select Update.
Figure 51. Configure Tunnel Parameters 
Table 31. Configure Tunnel Option Descriptions Option Description WAN Links Select the WAN interface to be used as source by the GRE tunnel. Tunnel Source Public IP Choose the IP address to be used as a public IP address by the Tunnel. You can either choose the WAN Link IP or Custom WAN IP. If you choose Custom WAN IP, enter the IP address to be used as public IP. Source public IPs must be different for each segment when Cloud Security Service (CSS) is configured on multiple segments. Primary Point-of-Presence Enter the primary Public IP address of the Zscaler Datacenter. Secondary Point-of-Presence Enter the secondary Public IP address of the Zscaler Datacenter. Primary Router IP/Mask Enter the primary IP address of Router. Secondary Router IP/Mask Enter the secondary IP address of Router. Primary Internal ZEN IP/Mask Enter the primary IP address of Internal Zscaler Public Service Edge. Secondary Internal ZEN IP/Mask Enter the secondary IP address of Internal Zscaler Public Service Edge.
- The Router IP/Mask and ZEN IP/Mask are provided by Zscaler.
- Only one Zscaler cloud and domain are supported per Enterprise.
- Only one CSS with GRE is allowed per Edge. An Edge cannot have more than one segment with Zscaler GRE automation enabled.
- GRE-WAN: Edge supports maximum of four public WAN links for a Non SD-WAN Destination (NSD) and on each link, it can have up to two tunnels (primary/secondary) per NSD. So, for each NSD, you can have maximum of eight tunnels and 8 BGP connections from one Edge.
- GRE-LAN: Edge supports one link to Transit Gateway (TGW), and it can have up to two tunnels (primary/secondary) per TGW. So, for each TGW, you can have maximum of two tunnels and 4 BGP connections from one Edge (two BGP sessions per tunnel).
Automated Zscaler CSS Provider Configuration for Edges
- IPsec/GRE Tunnel Automation
- Zscaler Location/Sub-Location Configuration
IPsec/GRE Tunnel Automation
- In the SD-WAN service of the Enterprise portal, select .
- Select an Edge you want to establish automatic tunnels.
- Select the link to an Edge or select the View link in the Device column of the Edge. The configuration options for the selected Edge are displayed in the Device tab.
- Under the VPN Services category, in the Cloud Security Service area, the CSS parameters of the associated profile are displayed.
- In the Cloud Security Service area, select the Override check box to select a different CSS or to modify the attributes inherited from the profile associated with the Edge. For additional information on the attributes, see Configure Cloud Security Services for Profiles.
- From the Cloud Security Service drop-down menu, select an automated CSS provider and select Save Changes.
Figure 52. Override Zscaler CSS Provider Configuration for Edges Automatically 
The automation will create a tunnel in the segment for each Edge's public WAN link with a valid IPv4 address. In a multi-WAN link deployment, only one of the WAN Links will be utilized for sending user data packets. The Edge chooses the WAN link with the best Quality of Service (QoS) score using bandwidth, jitter, loss, and latency as criteria. Location is automatically created after a tunnel is established. You can view the details of tunnel establishment and WAN links in the Cloud Security Service section
Note: After automatic tunnel establishment, changing to another CSS provider from an Automated Zscaler service provider is not allowed on a Segment. For the selected Edge on a segment, you must explicitly deactivate Cloud Security service and then reactivate CSS if you want to change to a new CSS provider from an Automated Zscaler service provider.
Zscaler Location/Sub-Location Configuration
After you have established automatic IPsec/GRE tunnel for an Edge segment, Location is automatically created and appears under the Zscaler section of the Edge Device page.
- You check that the tunnel is established from the selected Edge and Location is automatically created. You will not be allowed to create a Sub-location if the VPN credentials or GRE options are not set up for the Edge. Before configuring Sub-locations, ensure you understand about Sub location and their limitations. See https://help.zscaler.com/zia/understanding-sublocations.
- You select the same Cloud Subscription that you used to create the Automatic CSS.
- In the SD-WAN service of the Enterprise portal, select .
- Select an Edge and select the icon under the Device column. The Device Settings page for the selected Edge appears.
- Go to the Zscaler section and turn on the toggle button.
Figure 53. Override Zscaler Location Configuration 
- From the Cloud Subscription drop-down menu, select the same Cloud Subscription that you used to create the Automatic CSS. The Cloud Name associated to the selected Cloud Subscription automatically appears.
Note:
- Cloud Subscription must have same Cloud name and Domain name as CSS.
- If you want to change provider for "Cloud Subscription", you must first remove the "Location" by deactivating CSS and Zscaler, and then perform the creation steps with the new provider.
In the Location table, selecting View under the Action Details column displays the actual values for the configuration fetched from Zscaler, if present. If you want to configure the Gateway options and Bandwidth controls for the Location, select the Edit button under Gateway Options. For additional information, see the section "Configure Zscaler Gateway Options and Bandwidth Control".
- To create a Sub-location, in the Sub-Locations table, select the + icon under the Action column.
- In the Sub-Location Name text box, enter a unique name for the Sub-location. The Sub location name should be unique across all segments for the Edge. The name can contain alphanumeric with a maximum word length of 32 characters.
- From the LAN Networks drop-down menu, select a VLAN configured for the Edge. The Subnet for the selected LAN network will be populated automatically.
Note: For a selected Edge, Sub-locations should not have overlapping Subnet IPs.
- Select Save Changes.
Figure 54. Create Zscaler Sub-locations
Note: After you create at least one Sub-location in the Orchestrator, an “Other” Sub location is automatically created in the Zscaler side, and it appears in the Orchestrator UI. You can also configure the “Other” Sub-location’s Gateway options by selecting the Edit button under Gateway Options in the Sub-Locations table. For additional information, see the section "Configure Zscaler Gateway Options and Bandwidth Control". - After creating a Sub-location, you can update the Sub-location configurations from the same Orchestrator page. Once you select Save Changes, the Sub-location configurations on the Zscaler side will be updated automatically.
- To delete a Sub-location, select the - icon in the Action column.
Note: When the last Sub-location is deleted from the table, the "other" Sub-location also gets deleted automatically.
Configure Zscaler Gateway Options and Bandwidth Control
To configure Gateway options and Bandwidth controls for the Location and Sub-location, select the Edit button under Gateway Options, in the respective table.

Configure the Gateway options and Bandwidth controls for the Location and Sub-location, as needed, and select Save Changes.
| Option | Description |
|---|---|
| Gateway Options for Location/Sub-Location | |
| Use XFF from Client Request | Enable this option if the location uses proxy chaining to forward traffic to the Zscaler service, and you want the service to discover the client IP address from the X-Forwarded-For (XFF) headers that your on premises proxy server inserts in outbound HTTP requests. The XFF header identifies the client IP address, which can be leveraged by the service to identify the client’s sub location. Using the XFF headers, the service can apply the appropriate sub location policy to the transaction, and if Enable IP Surrogate is turned on for the location or sub-location, the appropriate user policy is applied to the transaction. When the service forwards the traffic to its destination, it will remove the original XFF header and replace it with an XFF header that contains the IP address of the client gateway (the organization’s public IP address), ensuring that an organization's internal IP addresses are never exposed to externally.
Note: This Gateway option is only configurable for Parent location.
|
| Enable Caution | If you have not enabled Authentication, you can enable this feature to display a caution notification to unauthenticated users. |
| Enable AUP | If you have not enabled Authentication, you can enable this feature to display an Acceptable Use Policy (AUP) for unauthenticated traffic and require users to accept it. If you enable this feature:
|
| Enforce Firewall Control | Select to enable the service's firewall control.
Note: Before enabling this option, user must ensure if its Zscaler account has subscription for "Firewall Basic".
|
| Enable IPS Control | If you have enabled Enforce Firewall Control, select this to enable the service's IPS controls.
Note: Before enabling this option, user must ensure if its Zscaler account has subscription for "Firewall Basic" and "Firewall Cloud IPS".
|
| Authentication | Enable to require users from the Location or Sub-location to authenticate to the service. |
| IP Surrogate | If you enabled Authentication, select this option if you want to map users to device IP addresses. |
| Idle Time for Dissociation | If you enabled IP Surrogate, specify how long after a completed transaction, the service retains the IP address-to-user mapping. You can specify the Idle Time for Dissociation in Mins (default), or Hours, or Days.
|
| Surrogate IP for Known Browsers | Enable to use the existing IP address-to-user mapping (acquired from the surrogate IP) to authenticate users sending traffic from known browsers. |
| Refresh Time for re-validation of Surrogacy | If you enabled Surrogate IP for Known Browsers, specify the length of time that the Zscaler service can use IP address-to-user mapping for authenticating users sending traffic from known browsers. After the defined period of time elapses, the service will refresh and revalidate the existing IP-to-user mapping so that it can continue to use the mapping for authenticating users on browsers. You can specify the Refresh Time for re validation of Surrogacy in minutes (default), or hours, or days.
|
| Bandwidth Control Options for Location | |
| Bandwidth Control | Enable to enforce bandwidth controls for the location. If enabled, specify the maximum bandwidth limits for Download (Mbps) and Upload (Mbps). All sub locations will share the bandwidth limits assigned to this location. |
| Download | If you enabled Bandwidth Control, specify the maximum bandwidth limits for Download in Mbps. The allowable range is from 0.1 through 99999. |
| Upload | If you enabled Bandwidth Control, specify the maximum bandwidth limits for Upload in Mbps. The allowable range is from 0.1 through 99999. |
Bandwidth Control Options for Sub-Location (if Bandwidth Control is enabled on Parent Location)
![]() Note: The following bandwidth control options are configurable for sub-location only if you have bandwidth control enabled on the parent location. If the bandwidth control is not enabled on the parent location, then the bandwidth control options for sub-location are the same as location (Bandwidth Control, Download, Upload).
|
|
| Use Location Bandwidth | If you have bandwidth control enabled on the parent location, select this option to enable bandwidth control on the sub-location and use the download and upload maximum bandwidth limits as specified for the parent location. |
| Override | Select this option to enable bandwidth control on the sub-location and then specify the maximum bandwidth limits for Download (Mbps) and Upload (Mbps). This bandwidth is dedicated to the sub-location and not shared with others. |
| Disabled | Select this option to exempt the traffic from any Bandwidth Management policies. Sub-location with this option can only use up to a maximum of available shared bandwidth at any given time. |
Limitations
- In 4.5.0 release, when a Sub-location is created, Orchestrator automatically saves the "Other" Sub location. In earlier version of Orchestrator, the Zscaler "Other" Sub-location was not saved in Orchestrator. After upgrading Orchestrator to 4.5.0 release, the "Other" Sub-location will be imported automatically only after a new normal (non-Other) Sub-location is created using automation.
- Zscaler Sub-locations cannot have overlapping IP addresses (subnet IP ranges). Attempting to edit (add, update, or delete) multiple Sub-locations with conflicting IP addresses may cause the automation to fail.
- Users cannot update the bandwidth of Location and Sub-location at the same time.
- Sub-locations support the Use Location Bandwidth option for bandwidth control when its Parent Location bandwidth control is enabled. When user turns off the Location bandwidth control on a Parent Location, the Orchestrator does not check or update the Sub-location bandwidth control option proactively.
Configure Zscaler Settings for Edges
Discusses how to configure Zscaler at the Edge level. You can configure the Zscaler settings for an Edge from the Zscaler section available under the VPN Services category in the Device tab.
Before you configure Zscaler, you must have Zscaler cloud subscription. For steps on how to create cloud subscription of type Zscaler, Configure API Credentials.
To configure Zscaler at the Edge level, perform the following steps:
Configure Multicast Settings for Edges
Multicast provides an efficient way to send data to an interested set of receivers to only one copy of data from the source, by letting the intermediate multicast-routers in the network replicate packets to reach multiple receivers based on a group subscription.
The Multicast settings are applied to all the Edges associated with the Profile. You can choose to override the Multicast settings for an Edge:
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:
LAN-side NAT Rules at Edge Level
LAN-Side NAT Rules allow you to NAT IP addresses in an unadvertised subnet to IP addresses in an advertised subnet. For both the Profile and Edge levels, within the Device Settings configuration, LAN-side NAT Rules has been introduced for the 3.3.2 release and as an extension, LAN side NAT based on source and destination, same packet source and destination NAT support have been introduced for the 3.4 release.
By default, the LAN-Side NAT Rules are inherited by the Edges associated with the Profile. To override the NAT-Side NAT Rules at the Edge level, perform the steps below.
For additional information, see LAN-Side NAT Rules at Profile Level.
Configure ICMP Probes/Responders
ICMP handlers may be needed to enable integration with an external router that is performing dynamic routing functionality and needs stateful information about route reachability through Arista. You can configure the ICMP Probes and Responders by navigating to the page.
Configure ICMP Probes
To configure ICMP Probes, perform the following steps:
Configure ICMP Responders
Configure Static Route Settings
Static Route Settings are useful for special cases in which static routes are needed for existing network attached devices, such as printers. You can add or delete Static Route Settings for an Edge. You can configure multiple static routes with different metrics, for the same network, on an Edge. However, only one static route is advertised to overlay for the network.
To configure the Static Route settings:
Configure DNS for Edges
Domain Name System (DNS) is used to configure conditional DNS forwarding through a private DNS service and to specify a public DNS service to be used for querying purpose.
The DNS service can be used for a public DNS service or a private DNS service provided by your company. A Primary Server and Backup Server can be specified. The public DNS service is preconfigured to use Google and Open DNS servers.
The DNS settings are applied to all the Edges associated with the Profile. You can choose to override the DNS settings for an Edge.
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.
If needed, you can view the OSPF configuration for a specific Edge as follows:
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.
If required, you can override the configuration for a specific Edge as follows:
Configure High Availability Settings for Edges
Configure VRRP Settings
You can configure Virtual Router Redundancy Protocol (VRRP) on an Edge to enable next-hop redundancy in the Orchestrator network by peering with third-party CE router. You can configure an Edge to be a primary VRRP device and pair the device with a third-party router.
- You can enable VRRP only between the Edge and third party router connected to the same subnet through an L2 switch.
- You can add only one Edge to the VRRP HA group in a branch.
- You cannot enable both Active-Standby HA and VRRP HA at the same time.
- VRRP is supported on primary routed port, sub-interface, and VLAN interfaces.
- Edge must be configured as the primary VRRP device, by setting higher priority, in order to steer the traffic through SD-WAN.
- If the Edge is configured as the DHCP server, then virtual IP addresses are set as the default Gateway address for the clients. When you use a separate DHCP server relay for the LAN, then the admin must configure the VRRP virtual IP address as the default Gateway address.
- When DHCP server is enabled in both the Edge and third-party router, then split the DHCP pool between the Edge and third party router, to avoid the overlapping of IP addresses.
- VRRP is not supported on an interface enabled with WAN Overlay, that is on the WAN link. If you want to use the same link for LAN, then create a sub-interface and configure VRRP on the sub-interface.
- You can configure only one VRRP group in a broadcast domain in a VLAN. You cannot add additional VRRP group for the secondary IP addresses.
- Do not add WI-FI link to the VRRP enabled VLAN. As the link failure would never happen, the Edge always remains as the primary device.
The following illustration shows a network configured with VRRP:

- In a branch network VLAN, if the Edge goes down, then the clients behind the VLAN are redirected through the backup router.
- The Edge that acts as a primary VRRP device becomes the default Gateway for the subnet.
- If the Edge loses connectivity with all the Edge/Controllers, then the VRRP priority gets reduced to 10 and the Edge withdraws the routes learned from the Edge and routes in the remote Edges as well. This results in the third-party router to become the primary device and take over the traffic.
- Edge automatically tracks overlay failure to the Edge. When all the overlay paths to the Edge are lost, the VRRP priority of the Edge is reduced to 10.
- When the Edge gets into the VRRP backup mode, the Edge drops any packets that go through the virtual MAC. When the path is UP, the Edge becomes the primary VRRP device again, provided the preemption mode is enabled.
- When VRRP is configured on a routed interface, the interface is used for local LAN access and can failover to the backup router.
- VRRP is not supported on a routed interface enabled with WAN Overlay. In such cases, a subinterface, sharing the same physical interface, must be configured for local LAN access to support VRRP.
- When LAN interface is down, VRRP instance would go to INIT state, and then the Edge sends the route withdrawal request to the Edge/Controller and all the remote Edge remove those routes. This behavior is applicable for the static routes added to the VRRP enabled interface as well.
- If the private overlay is present with the Edge peer Hub, then the route is not removed from the Hub, and can cause asymmetric routing. For example, when SD-WAN spoke Edge loses connectivity with public gateway, the third-party router forwards the packets from the LAN to the Hub Edge. The Hub sends the return packets to the SD-WAN spoke Edge instead of the third-party router. As a workaround, enable the SD-WAN Reachable functionality, so that the Edge is reachable on private overlay and remains as the primary VRRP device. As the Internet traffic is also steered through the private link over the overlay through the Edge, there might be some limitation on the performance or throughput.
- The conditional backhaul option is used to steer the Internet traffic through the Hub. However, in VRRP-enabled Edge, when public overlay goes down the Edge becomes Backup. So the conditional backhaul feature cannot be utilized on a VRRP-enabled Edge.
Monitor VRRP Events
You can monitor the events related to changes in VRRP status.
In the SD-WAN service of Enterprise portal, select .
Events
- VRRP HA updated to primary
- VRRP HA updated out of primary
- VRRP Failed
Configure Visibility Mode for Edges
This section discusses how to configure Visibility mode at the Edge level.
By default, the Visibility mode is inherited by the Edges associated with the Profile. To configure the visibility mode for an Edge:
Configure SNMP Settings for Edges
- In the SD-WAN service of the Enterprise portal, go to .
- Select the link to the required Edge, and then go to the MIBs for Edge area. Select VELOCLOUD-EDGE-MIB from the drop-down menu, and then select Run.
- Copy and paste the results onto your local machine.
- Install all MIBs required by
VELOCLOUD-EDGE-MIBon the SNMP manager, includingSNMPv2-SMI,SNMPv2-CONF,SNMPv2-TC,INET-ADDRESS-MIB,IF-MIB,UUID-TC-MIB, andVELOCLOUD-MIB. All these MIBs are available on the Remote Diagnostics page.
- SNMP MIB-2 System
- SNMP MIB-2 Interfaces
- VELOCLOUD-EDGE-MIB
Simple Network Management Protocol (SNMP) is a commonly used protocol for network monitoring, and Management Information Base (MIB) is a database associated with SNMP to manage entities. In the SASE Orchestrator, you can activate SNMP by selecting the desired SNMP version. At the Edge Level, you can override the SNMP settings specified in the Profile.
At the Edge level, you can override the SNMP settings specified in the Profile, by selecting the Override check box. The Edge Override option enables Edge specific edits to the displayed settings, and discontinues further automatic updates from the configuration Profile for this module. For ongoing consistency and ease of updates, it is recommended to set configurations at the Profile level rather than Edge level.
Procedure to configure SNMP settings at Edge Level:
- Navigate to , and then select a Profile.
- Select the View link in the Firewall column.
- Go to Edge Access located under the Edge Security area.
- Configure SNMP Access and select Save Changes.
Configure Syslog Settings for Edges
In an Enterprise network, the VeloCloud Orchestrator supports collection of the Orchestrator bound events and firewall logs originating from enterprise SD-WAN Edge to one or more centralized remote syslog collectors (Servers), in native syslog format. At the Edge level, you can override the syslog settings specified in the Profile by selecting the Enable Edge Override checkbox.
To override the Syslog settings at the Edge level, perform the following steps.
For additional information about Firewall settings at the Edge level, see Configure Edge Firewall.
Configure Netflow Settings for Edges
As an Enterprise Administrator, at the Edge level, you can override the Netflow settings specified in the Profile by selecting the Override check box.
To override the Netflow settings at the Edge level, perform the following steps:
After you enable Netflow on the SD-WAN Edge, it periodically sends messages to the configured collector. The contents of these messages are defined using IPFIX templates. For additional information on templates, see IPFIX Templates.
Security Virtual Network Functions
Virtual Network Functions (VNFs) are individual network services, such as routers and firewalls, running as software-only virtual machine (VM) instances on generic hardware. For example, a routing VNF implements all the functions of a router but runs in a software-only form, alone or along with other VNFs, on generic hardware. VNFs are administered and orchestrated within the NFV architecture.
- Insert network services in an optimal location to provide appropriate security. For example, insert a VNF firewall in an Internet-connected branch office rather than incur the inefficiency of an MPLS link to hairpin traffic through a distant data center to be firewalled.
- Optimize application performance. Traffic can follow the most direct route between the user and the cloud application using a VNF for security or traffic prioritization. In a VM environment, several VNFs may run simultaneously, isolated from each other, and can be independently changed or upgraded.
The following tables list the third-party firewalls supported by Arista along with the support matrix:
| SD-WAN Edge Platform | Edge 520v | Edge 840 | Edge 620 | Edge 640 | Edge 680 |
|---|---|---|---|---|---|
| Recommended VM Series Firewall Models | VM-50 Lite | VM-100 | VM-50 Lite | VM-100 | VM-100 |
| Number of vCPUs available for VM-Series Firewall | 2 | 2 | 2 | 2 | 2 |
| Memory available for VNF | 4.5 GB | 6.5 GB | 4.5 GB | 6.5 GB | 6.5 GB |
| Storage space available on Edge for VNF | 64 GB | 120 GB | 64 GB | 120 GB | 120 GB |
| Software version | Release 3.2.0 or later | Release 3.2.0 or later | Release 3.4.3 or later | Release 3.4.3 or later | Release 3.4.3 or later |
| Panorama version | Release 8.0.5 or later | Release 8.0.5 or later | Release 8.0.5 or later | Release 8.0.5 or later | Release 8.0.5 or later |
| SD-WAN Edge Platform | Edge 520v | Edge 840 | Edge 620 | Edge 640 | Edge 680 |
|---|---|---|---|---|---|
| Memory available for VNF | 2 GB | 4 GB | 2 GB | 4 GB | 4 GB |
| Number of vCPUs available for VNF | 2 | 2 | 2 | 2 | 2 |
| Storage available on Edge for VNF | 64 GB | 100 GB | 120 GB | 120 GB | 120 GB |
| Maximum Throughput of SD-WAN and Checkpoint VNF | 100 Mbps | 550 Mbps | 100 Mbps | 350 Mbps | 500 Mbps |
| Software version | Release 3.3.2 or later | Release 3.3.2 or later | Release 3.4.3 or later | Release 3.4.3 or later | Release 3.4.3 or later |
| Checkpoint VNF OS version | Release R77.20 or later | Release R77.20 or later | Release R77.20 or later | Release R77.20 or later | Release R77.20 or later |
| Checkpoint manager software version | Release 80.30 or later | Release 80.30 or later | Release 80.30 or later | Release 80.30 or later | Release 80.30 or later |
| SD-WAN Edge Platform | Edge 520v | Edge 840 | Edge 620 | Edge 640 | Edge 680 |
|---|---|---|---|---|---|
| Recommended VM Series Firewall Models | VM00, VM01, VM01v | VM00, VM01, VM01v, VM02, VM02v | VM00, VM01, VM01v | VM00, VM01, VM01v, VM02, VM02v | VM00, VM01, VM01v, VM02, VM02v |
| Memory available for VNF | 2 GB | 4 GB | 2 GB | 4 GB | 4 GB |
| Number of vCPUs available for VNF | 2 | 2 | 2 | 2 | 2 |
| Storage available on Edge for VNF | 64 GB | 100 GB | 64 GB | 100 GB | 100 GB |
| Maximum Throughput of SD-WAN and FortiGate VNF | 100 Mbps | 500 Mbps | 100 Mbps | 500 Mbps | 500 Mbps |
| Software version | Release 3.3.1 or later | Release 3.3.1 or later | Release 4.0.0 or later | Release 4.0.0 or later | Release 4.0.0 or later |
| FortiOS version | Release 6.0 and 6.2.0
Starting from the release 4.0.0, FortiOS version 6.4.0 and 6.2.4 are supported. |
Release 6.0 and 6.2.0
Starting from the release 4.0.0, FortiOS version 6.4.0 and 6.2.4 are supported. |
Release 6.4.0 and 6.2.4 | Release 6.4.0 and 6.2.4 | Release 6.4.0 and 6.2.4 |
You can deploy and forward traffic through VNF on an SD-WAN Edge.
Configure VNF Management Service
Arista supports third-party firewalls that can be used as VNF to pass traffic through Edges.
Choose the third-party firewall and configure the settings accordingly. You may need to configure additional settings in the third-party firewall as well. Refer to the deployment guides of the corresponding third-party firewall for the additional configurations.
For the VNF Types Check Point Firewall and Fortinet Firewall configure the VNF image by using the System Property edge.vnf.extraImageInfos. You must be an Operator user to configure the system property. If you do not have the Operator role access, contact your Operator to configure the VNF Image.
Configure Security VNF without High Availability
- VeloCloud Orchestrator and activated SD-WAN Edge running software versions that support deploying a specific security VNF. For additional information on the supported software versions and Edge platforms, refer to the Support Matrix in Security Virtual Network Functions.
- Configured VNF Management service. For additional information, see Configure VNF Management Service.
You can deploy and forward traffic through VNF on the SD-WAN Edge, using third-party firewalls.
If you want to redirect multiple traffic segments to the VNF, define mapping between Segments and service VLANs. See Define Mapping Segments with Service VLANs.
You can insert the security VNF into both the VLAN as well as routed interface to redirect the traffic from the VLAN or the routed interface to the VNF. See Configure VLAN with VNF Insertion.
Configure Security VNF with High Availability
Ensure that you have the following:
- The Orchestrator and activated SD-WAN Edge running software version 4.0.0 or later. For additional information on the supported Edge platforms, refer to the Support Matrix in Security Virtual Network Functions.
- Configured Check Point Firewall VNF Management service. For additional information, see Configure VNF Management Service.
Note: Arista supports only Check Point Firewall VNF on Edges with HA.
You can configure security VNF on Edges configured with High Availability to provide redundancy.
- In a standalone Edge, enable HA and VNF.
- In Edges configured with HA mode, enable VNF.
- LAN interface to VNF
- WAN interface to VNF
- Management Interface – VNF communicates with its manager
- VNF Sync Interface – Synchronizes information between VNFs deployed on Active and Standby Edges
The Edges have the HA roles as Active and Standby. The VNFs on each Edge run with Active-Active mode. The Active and Standby Edges learn the state of the VNF through SNMP. The SNMP poll is done periodically for every 1 second by the VNF daemon on the edges.
VNF is used in the Active-Active mode with user traffic forwarded to a VNF only from the associated Edge in Active mode. On the standby VM, where the Edge in the VM is standby, the VNF will have only traffic to the VNF Manager and data sync with the other VNF instance.
The following example shows configuring HA and VNF on a standalone Edge.
If you want to redirect multiple traffic segments to the VNF, define mapping between Segments and service VLANs. See Define Mapping Segments with Service VLANs.
You can insert the security VNF into both the VLAN as well as routed interface to redirect the traffic from the VLAN or the routed interface to the VNF. See Configure VLAN with VNF Insertion.
Define Mapping Segments with Service VLANs
When you want to redirect multiple traffic segments to the security VNF, define mapping between Segments and service VLANs.
To map the segments with the service VLANs:
Configure VLAN with VNF Insertion
Ensure that you have created a security VNF and configured the settings. See Configure Security VNF without High Availability and Configure Security VNF with High Availability.
Map the segments with service VLANs to enable VNF insertion into the VLANs. See Define Mapping Segments with Service VLANs.
You can insert the security VNF into both the VLAN as well as routed interface.
Monitor VNF for an Edge
You can monitor the status of VNFs and the VMs for an Edge, and also view the VNF network services configured for the Enterprise. To monitor the status of VNFs and VMs of an Edge:
Monitor VNF Events
You can view the events when the VNF VM is deployed, when there is a change in the VNF VM configuration, and when a VNF insertion is enabled in a VLAN.
In the SD-WAN service of the Enterprise portal, select .
To view the events related to VNF, you can use the filter option. Select the drop-down arrow next to the Search option and choose to filter either by the Event or by the Message column.
- VNF deployed
- VNF deleted
- VNF turned off
- VNF error
- VNF is DOWN
- VNF is UP
- VNF power off
- VNF power on
- VNF insertion turned off
- VNF insertion turned on

Configure VNF Alerts
You can configure to receive alerts and notifications related to the VNF events.
To configure alerts and notifications related to the VNF events:
Configure Authentication Settings for Edges
The Device Authentication Settings allows you to select a Radius server to authenticate a user.
At the Edge-level, you can choose to override the Authentication Settings configured for the Profile.
Configure NTP Settings for Edges
As an Enterprise Administrator, at the Edge level, you can override the Network Time Protocol (NTP) settings specified in the Profile by selecting the Override checkbox. By default, at the Edge level, the NTP Servers are deactivated.
- NTP Clients can synchronize to LAN/loopback IP address of the SD-WAN Edge as NTP server but cannot synchronize to WAN IP address.
- NTP synchronization from another segment to LAN interface is not supported.
To override NTP settings at the Edge-level, perform the following steps.
Debugging and troubleshooting are much easier when the timestamps in the log files of all the Edges are synchronized. You can collect NTP diagnostic logs by running the NTP Dump remote diagnostic tests on an Edge. For additional information about how to run remote diagnostic tests on an Edge, see Arista SD-WAN Troubleshooting Guide.
Configure TACACS Services for Edges
Discusses how to configure TACACS Services for Edges.















































































