Configure Edges with New Orchestrator UI
You can configure the Edges using the Orchestrator.
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, 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.
- You can configure a maximum of 32 VLANs across 16 Segments on an Edge.
- On profile change, any VLAN inherited from the Edge's profile will be removed if it is not present in the target profile unless overridden at the Edge level. Any interface associated with such removed VLANs will be reverted to the profile-level configuration in the target profile, even if the interface is overridden at the Edge level.
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 Edge.
You can configure loopback interfaces only for Edges that are running on version 4.3 and above. The Configure Loopback Interfaces area is not available for 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 Interface
- 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 Interface.
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 |
When the Edge transmits the traffic, the packet header will have the IP address of the selected source interface, whereas the packets can be sent through any interface based on the destination route.
Configure Management 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 more 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:
- 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. The configuration options for the selected Edge are displayed in the Device tab.
- In the Connectivity category, expand Interfaces.
- The different types of interfaces available for the selected Edge are displayed. Select the link to an interface to edit the settings. The Interface Settings screen appears.
Figure 10. Configure Interface Settings Screen
You can edit the settings for the following types of interfaces, based on the Edge model:- Switch Port
- Routed Interface
- WLAN Interface
You can also add Sub-interface, Secondary IP address, and Wi-Fi SSID based on the Edge model.
- You can configure the following settings for a Routed interface of an Edge.
Table 13. Routed Interface Option Descriptions Option Description Description Enter a description. This field is optional. Interface Enabled This option is activated by default. If required, you can deactivate the interface. When deactivated, the interface is not available for any communication. Capability For a Switch Port, the option Switched is selected by default. You can choose to convert the port to a routed interface by selecting the option Routed from the drop-down menu. Segments By default, the configuration settings are applicable to all the segments. Radius Authentication Deactivate the Enable WAN Overlay check box to configure Radius Authentication. Select the Radius Authentication check box and add the MAC addresses of pre-authenticated devices. ICMP Echo Response This check box is selected by default. This helps the interface to respond to ICMP echo messages. You can deactivate this option for security purposes. Underlay Accounting This check box is selected by default. If a private WAN overlay is defined on the interface, all underlay traffic traversing the interface are counted against the measured rate of the WAN link to prevent over-subscription. Deactivate this option to avoid this behavior. Note:- Underlay Accounting is supported for both, IPv4 and IPv6 addresses.
- Enabling underlay configuration for LAN is not recommended.
Enable WAN Overlay Select the check box to activate WAN overlay for the interface. DNS Proxy The DNS Proxy feature provides additional support for Local DNS entries on the Edge, to point certain device traffic to specific domains. You can activate or deactivate this option, irrespective of IPv4 or IPv6 DHCP Server setting. Note: This check box is available only for a Routed Interface and a Routed Subinterface.VLAN For an Access port, select an existing VLAN from the drop-down menu. For a Trunk port, you can select multiple VLANs and select an untagged VLAN. EVDSL Modem Attached Select this check box to activate an EVDSL Modem which is connected to one of the Ethernet ports on the Edge. IPv4 Settings Select the Enable check box and configure the IPv4 settings. For additional information, see IPv4 Settings section below. IPv6 Settings Select the Enable check box and configure the IPv6 settings. For additional information, see IPv6 Settings section below. L2 Settings Autonegotiate This option is selected by default. When selected, Auto negotiation allows the port to communicate with the device on the other end of the link to determine the optimal duplex mode and speed for the connection. Speed This option is available only when Autonegotiate is not selected. Select the speed that the port has to communicate with other links. By default, 100 Mbps is selected. Duplex This option is available only when Autonegotiate is not selected. Select the mode of the connection as Full duplex or Half duplex. By default, Full duplex is selected. MTU The default MTU size for frames received and sent on all routed interfaces is 1500bytes. You can change the MTU size for an interface.LOS Detection This option is available only for a routed interface of an Edge. Select the check box to activate Loss of Signal (LoS) detection by using ARP monitoring. For additional information, see HA LoS Detection on Routed Interfaces. Note: You can select the check box only when you have activated High Availability on the Edge.
IPv4 Settings
Select the Enabled check box to configure the following IPv4 Settings:
| Option | Description |
|---|---|
| Addressing Type | Select an addressing type:
Note: 31-bit prefixes are supported for IPv4 as per RFC 3021.
|
| OSPF | This option is available only when you have configured OSPF at the Profile level for the selected Segment. Select the check box and choose an OSPF area from the drop-down menu.
Select Advanced settings to configure the advanced interface settings for the selected OSPF area. Note: When configuring advanced OSPF area settings for a routed interface, the BFD configuration is supported only for global segments.
The OSPFv2 configuration supports only IPv4. The OSPFv3 configuration supports only IPv6. Note: OSFPv3 is only available in the 5.2 release.
|
| Multicast | This option is available only when you have configured multicast settings for the selected Segment. You can configure the following multicast settings for the selected interface.
Select toggle advanced multicast settings to configure the following timers:
Note: Currently, Multicast Listener Discovery (MLD) is deactivated. Hence, Edge does not send the multicast listener report when IPv6 address is assigned to interface. If there is a snooping switch in the network then not sending MLD report may result in Edge not receiving multicast packets which are used in Duplicate Address Detection (DAD). This results in DAD success even with duplicate address.
|
| VNF Insertion | You must deactivate WAN Overlay and select the Trusted Source check box to activate VNF Insertion. When you insert the VNF into Layer 3 interfaces or subinterfaces, the system redirects traffic from the Layer 3 interfaces or subinterfaces to the VNF. |
| Advertise | Select the check box to advertise the interface to other branches in the network. |
| NAT Direct Traffic | Select the check box to apply NAT for IPv4 to network traffic sent from the interface.
CAUTION: It is possible that an older version of the SASE Orchestrator inadvertently configured NAT Direct on a main interface with either a VLAN or subinterface configured. If that interface is sending direct traffic one or hops away, the customer would not observe any issues because the NAT Direct setting was not being applied. However, when an Edge is upgraded to 5.2.0 or later, the Edge build includes a fix for the issue (Ticket #92142) with NAT Direct Traffic not being properly applied, and there is a resulting change in routing behavior since this specific use case was not implemented in prior releases.
In other words, because a 5.2.0 or later Edge now implements NAT Direct in the expected manner for all use cases, traffic that previously worked (because NAT Direct was not being applied per the defect) may now fail because the customer never realized that NAT Direct was checked for an interface with a VLAN or subinterface configured. As a result, a customer upgrading their Edge to Release 5.2.0 or later should first check their Profiles and Edge interface settings to ensure NAT Direct is configured only where they explicitly require it and to deactivate this setting where it is not, especially if that interface has a VLAN or subinterface configured. |
| Trusted Source | Select the check box to set the interface as a trusted source. |
| Reverse Path Forwarding | You can choose an option for Reverse Path Forwarding (RPF) only when you have selected the Trusted Source check box. This option allows traffic on the interface only if return traffic can be forwarded on the same interface. This helps to prevent traffic from unknown sources like malicious traffic on an Enterprise network. If the incoming source is unknown, then the packet is dropped at ingress without creating flows. Select one of the following options from the drop-down menu:
|
- Activated: Activates DHCP with the Edge as the DHCP server. If you choose this option, configure the following details:
- DHCP Start: Enter a valid IP address available within the subnet.
- Num. Addresses: Enter the number of IP addresses available on a subnet in the DHCP Server.
- Lease Time: Select the period of time from the drop-down menu. This is the duration the VLAN is allowed to use an IP address dynamically assigned by the DHCP server.
- Options: Select Add to add pre-defined or custom DHCP options from the drop-down menu. The DHCP option is a network service passed to the clients from the DHCP server. Choose a custom option and enter the code, data type, and value.
- Relay – Allows exchange of DHCPv4 messages between client and server. If you choose this option, configure the following:
- Relay Agent IP(s): Specify the IP address of Relay Agent. Select Add to add more IP addresses.
- Deactivated – Deactivates the DHCP server.
IPv6 Settings
| Option | Description |
|---|---|
| Addressing Type | Select an addressing type:
|
| OSPF | This option is available only when you have configured OSPF at the Profile level for the selected Segment. Select the check box and choose an OSPF area from the drop-down menu. Select Advanced Settings to configure advanced interface settings for the selected OSPF area.
Note: When configuring advanced OSPF area settings for a routed interface, the BFD configuration is supported only for global segments.
The OSPFv2 configuration supports only IPv4. The OSPFv3 configuration supports only IPv6, which is only available in the 5.2 release.
For additional information on OSPF settings and OSPFv3, see Activate OSPF for Profiles.Note: OSFPv3 is only available in the 5.2 release.
|
| Advertise | Select the check box to advertise the interface to other branches in the network. |
| NAT Direct Traffic | Select the check box to apply NAT for IPv6 to network traffic sent from the interface.
CAUTION: It is possible that an older version of the SASE Orchestrator inadvertently configured NAT Direct on a main interface with either a VLAN or subinterface configured. If that interface is sending direct traffic one or hops away, the customer would not observe any issues because the NAT Direct setting was not being applied. However, when an Edge is upgraded to 5.2.0 or later, the Edge build includes a fix for the issue (Ticket #92142) with NAT Direct Traffic not being properly applied, and there is a resulting change in routing behavior since this specific use case was not implemented in prior releases.
In other words, because a 5.2.0 or later Edge now implements NAT Direct in the expected manner for all use cases, traffic that previously worked (because NAT Direct was not being applied per the defect) may now fail because the customer never realized that NAT Direct was checked for an interface with a VLAN or subinterface configured. As a result, a customer upgrading their Edge to Release 5.2.0 or later should first check their Profiles and Edge interface settings to ensure NAT Direct is configured only where they explicitly require it and to deactivate this setting where it is not, especially if that interface has a VLAN or subinterface configured. |
| Trusted Source | Select the check box to set the Interface as a trusted source. |
| Reverse Path Forwarding | You can choose an option for Reverse Path Forwarding (RPF) only when you have selected the Trusted Source check box. This option allows traffic on the interface only if return traffic can be forwarded on the same interface. This helps to prevent traffic from unknown sources like malicious traffic on an Enterprise network. If the incoming source is unknown, then the packet is dropped at ingress without creating flows. Select one of the following options from the drop-down menu:
|
- Activated: Activates DHCPv6 with the Edge as the DHCPv6 server. If you choose this option, configure the following details:
- DHCP Start: Enter a valid IPv6 address available within the subnet.
- Num. Addresses: Enter the number of IP addresses available on a subnet in the DHCPv6 Server.
- Lease Time: Select the period of time from the drop-down list. This is the duration the VLAN is allowed to use an IPv6 address dynamically assigned by the DHCPv6 Server.
- DHCPv6 Prefix Delegation: Select Add to assign prefixes chosen from a global pool to DHCP clients. Enter the prefix pool name along with the prefix start and end details.
- Options – Select Add to add pre-defined or custom DHCP options from the drop-down menu. The DHCP option is a network service passed to the clients from the DHCP server. Choose a custom option and enter the code, data type, and value.
- Relay – Allows exchange of DHCPv6 messages between client and server. If you choose this option, configure the following:
- Relay Agent IP(s): Specify the IP address of Relay Agent. Select Add to add additional IP addresses.
Starting from the 5.2.0 release, VeloCloud Edge supports the DHCPv6 Relay feature. This allows the DHCPv6 clients to communicate with a remote DHCPv6 server. It is mostly similar to the DHCPv4 Relay feature, except that DHCPv6 uses separate message types to allow the Relay agents to insert their own options or to identify the outgoing interface for the reply packet. To activate this feature on an Edge, you must activate IPv6 on the LAN interface of that Edge.
Note:- You must provide the Server IP address as the Relay Agent IP address on the customer-facing interface.
- If this interface belongs to a non-global segment, the Server must be reached through the same non-global segment.
- Relay Agent IP(s): Specify the IP address of Relay Agent. Select Add to add additional IP addresses.
- Deactivated: Deactivates the DHCP server.
Router Advertisement Host Settings: The Router Advertisement (RA) parameters are available only when you activate IPv6 Settings, and then choose the Addressing Type as DHCP Stateless or DHCP Stateful.

| Option | Description |
|---|---|
| MTU | Accepts the MTU value received through Route Advertisement. If you turn off this option, the MTU configuration of the interface is considered. |
| Default Routes | Installs default routes when Route Advertisement is received on the interface. If you turn off this option, then there are no default routes available for the interface. |
| Specific Routes | Installs specific routes when Route Advertisement receives route information on the interface. If you turn off this option, the interface does not install the route information. |
| ND6 Timers | Accepts ND6 timers received through Route Advertisement. If you turn off this option, default ND6 timers are considered. The default value for NDP retransmit timer is 1 second and NDP reachable timeout is 30 seconds. |
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-WANService 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. |
Configure DHCP Server on Routed Interfaces
You can configure DHCP server on a Routed Interface in an Edge.
To configure DHCP Server settings:
Configure RADIUS Authentication on a Routed Interface
RADIUS can be enabled on any interface that is configured as a routed interface. The Edge supports both username/password (EAP-MD5) and certificate (EAP-TLS) based 802.1x Authentication methods.
Prerequisites
- 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.
Configure RADIUS Authentication on a Switched Interface
This section covers 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.
The SD-WAN Edge supports both username/password (EAP-MD5) and certificate (EAP-TLS) based 802.1x Authentication methods.
Prerequisites
- A RADIUS server must be configured and added to the Edge. See Configure Authentication Services.
- RADIUS may be configured on any switched interface.
MAC Address Bypass (MAB) for RADIUS-based Authentication
- A RADIUS server must be configured and added to the Edge. See 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
The WAN Overlay settings enables you to add or modify a User-Defined WAN Overlay.
- 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 VeloCloud Gateways over the Internet, as determined by the 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 Orchestrator.
To configure WAN Overlay settings for a specific Edge, perform the following steps:
- 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. The configuration options for the selected Edge are displayed in the Device tab.
- In the Connectivity category, select Interfaces.
- The WAN Link Configuration section displays the existing Overlays.
Figure 25. Configure Edge WAN Overlay Settings 
- You can select the Name of the overlay to modify the settings. To create a new Public or Private WAN overlay, select Add User Defined WAN Link. The New User Defined WAN Link window appears.
Figure 26. New User Defined WAN Link Window 
- In the User Defined WAN Overlay section, choose the Link Type from the following available options:
- Public overlay is used over the Internet where SD-WAN cloud Gateways, that are on the Internet, are reachable. The user-defined overlay must be attached to an Interface. The public overlay instructs the Edge to assign primary and secondary gateways over the interface it is attached, to help determine the outside global NAT address. This outside global address is reported to the Orchestrator so that all the other Edges use this outside global address, if configured to build VCMP tunnels to the currently selected Edge.
Note: By default, all routed interfaces will attempt to Auto Detect, that is build VCMP tunnels to, pre-assigned cloud Gateways over the Internet. If the attempt is successful, an Auto Detect Public overlay is created. A User Defined Public overlay is only needed if your Internet service requires a VLAN tag or you want to use a different public IP address from the one that the Edge has learned through DHCP on the public facing interface.
- Private overlay is used on private networks such as an MPLS network or point-to-point link. A private overlay is attached to an interface like any user defined overlay and assumes that the IP address on the interface it is attached is routable for all other Edges on the same private network. This means that there is no NAT on the WAN side of the interface. When you attach a private overlay to an interface, the Edge advises the Orchestrator that the IP address on the interface should be used for any remote Edges configured to build tunnels to it.
The following tables describe the Overlay settings:Table 20. User-Defined WAN Overlay Settings Option Descriptions Option Description Address Type Choose the WAN overlay link to use either IPv4 or IPv6 address. You can also select IPv4 and IPv6, which enables to configure both IPv4 and IPv6 user-defined overlay towards the same ISP as a single link. This option helps preventing oversubscription of a link towards an ISP. Note: When you choose IPv6 address, the Duplicate Address Detection (DAD) is not supported for IP steered overlay. The overlay network is steered when you configure the source IP address in the Optional Configuration.Name Enter a descriptive WAN overlay name for the public or private link. Note: WAN overlay name should only consist of ASCII characters. Non-ASCII characters are not supported.You can reference this name while choosing a WAN link in a Business Policy. See Configure Link Steering Modes.Operator Alerts Sends alerts related to the Overlay network to the Operator. Ensure that you have enabled the Link alerts in the page to receive the alerts. Alerts Sends alerts related to the Overlay network to the Customer. Ensure that you have enabled the Link alerts in the page to receive the alerts. Select Interfaces The Routed Interfaces enabled with IPv4 WAN Overlay or IPv6 WAN Overlay and set to User Defined Overlay are displayed as check boxes. The Interfaces displayed are based on the selected Address Type. Note: If the WAN Overlay link uses a static IPv4 address then you can select one or more routed interfaces and the current user-defined overlay is attached to the selected interface. If a static IPv6 address is configured then you cannot select one or more routed interfaces.Note: For the 610-LTE and Edge 710 5G, you can add User Defined WAN overlay on CELL1 or CELL2. The Orchestrator displays both CELL1 and CELL2, irrespective of SIM presence. Therefore, you must be aware of which SIM slot is enabled (Active) and choose that SIM.Table 21. Public WAN Overlay Settings Option Description Public IP Address Displays the discovered public IP address for a public Overlay. This field is populated once the outside global NAT address is discovered using the Gateway method. The following image shows an example of Settings for Public Overlay:Figure 27. Configure Public Overlay Settings 
Table 22. Public Overlay Settings Option Descriptions Option Description SD-WAN Service Reachable When creating a private overlay and attaching it to a private WAN like MPLS network, you may also be able to reach the internet over the same WAN, usually through a firewall in the data center. In this case, it is recommended to enable SD-WAN Service Reachable as it provides the following: - A secondary path to the internet for access to internet hosted Gateways. This is used if all the direct links to the internet from this Edge fail.
- A secondary path to the Orchestrator, when all the direct links to the internet from this Edge fail. The management IP address the Edge uses to communicate must be routable within MPLS, otherwise NAT Direct would need to be checked on the private interface for the Orchestrator traffic to come back properly.
Note: The Edge always prefers the VCMP tunnel created over a local internet link (short path), compared to the VCMP tunnel created over the private network using a remote firewall to the internet (long path).Note: Per-packet or round-robin load balancing will not be performed between the short and long paths.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 VeloCloud SD-WAN service.
Public SD-WAN Addresses When you select the SD-WAN Service Reachable check box, a list of public IPv4 and IPv6 addresses of Gateways and Orchestrator is displayed, which may need to be advertised across the private network, if a default route has not been already advertised across the same private network from the firewall. Note: Some IP addresses in the list, such as Gateways, may change over time.The following image shows an example of Settings for Private Overlay:Figure 28. Private Overlay Settings 
Table 23. Private Overlay Settings Option Descriptions Option Description Source IP Address This is the raw socket source IP address used for VCMP tunnel packets that originate from the interface to which the current overlay is attached. Source IP address does not have to be pre-configured anywhere but must be routable to and from the selected interface.
You can enter IPv4 or IPv6 address in the respective fields to establish WAN overlay with the peer.
Next-Hop IP Address Enter the next hop IP address to which the packets, which come from the raw socket source IP address specified in the Source IP Address field, are to be routed. You can enter IPv4 or IPv6 address in the respective fields.
Custom VLAN Select this check box to enable custom VLAN and enter the VLAN ID. The range is 2 to 4094. This option applies the VLAN tag to the packets originated from the Source IP Address of a VCMP tunnel from the interface to which the current overlay is attached.
Enable Per Link DSCP 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. 802.1P Setting Select this check box to set 802.1p PCP bits on frames leaving the interface to which the current overlay is attached. This setting is only available for a specific VLAN. PCP priority values are a 3-digit binary number. The range is from 000 to 111 and default is 000. This check box is available only when the system property session.options.enable8021PConfiguration must be set to True. By default, this value is False.
If this option is not available for you, contact the Arista VeloCloud support of your operations team to enable the setting.
- Public overlay is used over the Internet where SD-WAN cloud Gateways, that are on the Internet, are reachable. The user-defined overlay must be attached to an Interface. The public overlay instructs the Edge to assign primary and secondary gateways over the interface it is attached, to help determine the outside global NAT address. This outside global address is reported to the Orchestrator so that all the other Edges use this outside global address, if configured to build VCMP tunnels to the currently selected Edge.
- Select View advanced settings to configure the following settings:
Table 24. Advanced Settings Option Descriptions Option Description Bandwidth Measurement Choose a method to measure the bandwidth from the following options: - Measure Bandwidth (Slow Start): When measuring the default bandwidth reports incorrect results, it may be due to ISP throttling. To overcome this behavior, choose this option for a sustained slow burst of UDP traffic followed by a larger burst.
- Measure Bandwidth (Burst Mode): Choose this option to perform short bursts of UDP traffic to an Gateway for public links or to the peer for private links, to assess the bandwidth of the link.
- Do Not Measure (define manually): Choose this option to configure the bandwidth manually. This is recommended for the Hub sites because:
- Hub sites can usually only measure against remote branches which have slower links than the hub.
- If a hub Edge fails and is using a dynamic bandwidth measurement mode, it may add delay in the hub Edge coming back online while it re-measures the available bandwidth.
For additional information, see Bandwidth Measurement Modes.
Upstream Bandwidth Enter the upstream bandwidth in Mbps. This option is available only when you choose Do Not Measure (define manually). Downstream Bandwidth Enter the downstream bandwidth in Mbps. This option is available only when you choose Do Not Measure (define manually). Dynamic Bandwidth Adjustment Dynamic Bandwidth Adjustment attempts to dynamically adjust the available link bandwidth based on packet loss and intended for use with Wireless broadband services where bandwidth can suddenly decrease. Note: This configuration is not recommended for Edges with software release 3.3.x or earlier. You can configure this option for Edges with release 3.4 or later.Note: This configuration is not supported with public link CoS.Link Mode Select the mode of the WAN link from the drop-down. The following options are available: - Active: This option is selected by default. The interface is used as a primary mode to send traffic.
- Backup: This option puts the interface that this WAN Overlay is attached to into Backup Mode. This means that the management tunnels are torn down for this interface, and the attached WAN link receives no data traffic. The Backup link would only be used if all paths from a number of Active links go down, which also drops the number of Active links below the number of Minimum Active Links configured. When this condition is met, management tunnels would be rebuilt for the interface and the Backup Link would become Active and pass traffic.
Only one interface on an Edge can be put into backup mode. When enabled, the interface will be displayed in page as Cloud Status: Standby.
Note: Use this option to reduce user data and SD-WAN performance measurement bandwidth consumption on a 4G or LTE service. However, failover times will be slower when compared to a link that is configured as either Hot Standby or as Active and uses a business policy to regulate bandwidth consumption. Do not use this feature if the Edge is configured as a Hub or is part of a Cluster. - Hot Standby: When you configure the WAN link for Hot Standby mode, the management tunnels are built, which enables a rapid switchover in case of a failure. The Hot Standby link receives no data traffic except for heartbeats, which are sent every 5 seconds.
When all paths from a number of Active links go down, which also drops the number of Active links below the number of Minimum Active Links configured, the Hot Standby link would come up. The traffic is sent through the Hot Standby path.
When the path to the Primary Gateway comes up on Active links such that the number of Active links exceeds the number of Minimum Active Links configured, the Hot Standby link returns to Standby mode and the traffic flow switches over to the Active link(s).
For additional information, see Configure Hot Standby Link.
Once you activate the Backup or Hot Standby link option on an Interface, you cannot configure additional Interfaces of that Edge as either a Backup or Hot Standby Link, as an Edge can have only one WAN link as a Backup or Hot Standby at a time.
Minimum Active Links This option is available only when you choose Backup or Hot Standby as Link Mode. Select the number of active links that can be present in the network at a time, from the drop-down list. When the number of current active links that are UP goes below the selected number, then the Backup or the Hot Standby link comes up. The range is 1 to 3, with the default being 1. MTU The Edge performs path MTU discovery and the discovered MTU value is updated in this field. Most wired networks support 1500 Bytes while 4G networks supporting VoLTE typically only allow up to 1358 Bytes. It is not recommended to set the MTU below 1300 Bytes as it may introduce framing overhead. There is no need to set MTU unless path MTU discovery has failed.
You can find if the MTU is large from the page, as the VCMP tunnels (paths) for the interface never become stable and repeatedly reach an UNUSABLE state with greater than 25% packet loss.
As the MTU slowly increases during bandwidth testing on each path, if the configured MTU is greater than the network MTU, all packets greater than the network MTU are dropped, causing severe packet loss on the path.
For additional information, see Tunnel Overhead and MTU.
Overhead Bytes Enter a value for the Overhead bandwidth in bytes. This is an option to indicate the additional L2 framing overhead that exists in the WAN path. When you configure the Overhead Bytes, the bytes are additionally accounted for by the QoS schedular for each packet, in addition to the actual packet length. This ensures that the link bandwidth is not oversubscribed due to any upstream L2-framing overhead.
Path MTU Discovery Select this check box to enable the discovery of Path MTU. After determining the Overhead bandwidth to be applied, the Edge performs Path MTU Discovery to find the maximum permissible MTU to calculate the effective MTU for customer packets. For additional information, see Tunnel Overhead and MTU. Configure Class of Service Edges can prioritize traffic and provide a 3x3 QoS class matrix over both Internet and Private networks alike. However, some public or private (MPLS) networks include their own quality of service (QoS) classes, each with specific characteristics such as rate guarantees, rate limits, packet loss probability etc. This option allows the Edge to understand the public or private network QoS bandwidth available and policing for the public or private Overlay on a specific interface.
Note: Outer DSCP tags must be set in business policy per application/rule and in this feature, each Class of Service line is matching on those DSCP tags set in the business policy.After you select this check box, configure the following:- Class of Service: Enter a descriptive name for the class of service. You can reference this name while choosing a WAN link in a Business Policy. See Configure Link Steering Modes.
- DSCP Tags: Class of service will match on the DSCP tags defined here. DSCP tags are assigned to each application using business policy.
- Bandwidth: Percentage of interface transmit/upload bandwidth available for this class as determined by the public or private network QoS class bandwidth guaranteed.
- Policing: This option monitors the bandwidth used by the traffic flow in the class of service and when the traffic exceeds the bandwidth, it rate-limits the traffic.
- Default Class: If the traffic does not fall under any of the defined classes, the traffic is associated with the default CoS.
Note: The Dynamic Bandwidth Adjustment configuration is not supported with public link CoS.For additional information about how to configure CoS, see the topic Configure Class of Service.
Strict IP precedence This check box is available when you select the Configure Class of Service check box. When you enable this option, 8 VCMP sub-paths corresponding to the 8 IP precedence bits are created. Use this option when you want to combine the Classes of Service into less number of classes in the network of your Service Provider.
By default, this option is deactivated and the VCMP sub-paths are created for the exact number of classes of service that are configured. The grouping is not applied.
Table 25. Advanced Settings Option Descriptions Option Description UDP Hole Punching If a Branch to Branch SD-WAN overlay is required and branch Edges are deployed behind NAT devices, that is NAT device is WAN side of the Edge, the direct VCMP tunnel on UDP/2426 will not likely come up if the NAT devices have not been configured to allow incoming VCMP tunnels on UDP port 2426 from other Edges. Use Branch to Branch VPN to enable branch to branch tunnels. See Configure a Tunnel Between a Branch and a Branch VPN and Configure Cloud VPN and Tunnel Parameters for Edges.
Use to check that one Edge has built a tunnel to another Edge.
UDP hole punching attempts to work around NAT devices blocking incoming connections. However, this technique is not applicable in all scenarios or with all types of NATs, as NAT operating characteristics are not standardized.
Enabling UDP hole punching on an Edge overlay interface, instructs all remote Edges to use the discovered NAT public IP and NAT dynamic source port discovered through Gateway as destination IP and destination port for creating a VCMP tunnel to this Edge overlay interface.
Note: Before enabling UDP hole punching, configure the branch NAT device to allow UDP/2426 inbound with port forwarding to the Edge private IP address or put the NAT device, which is usually a router or modem, into bridge mode. Use UDP hole punching only as a last resort as it will not work with firewalls, symmetric NAT devices, 4G/LTE networks due to CGNAT, and most modern NAT devices.UDP hole punching may introduce additional connectivity issues as remote sites try to use the new UDP dynamic port for VCMP tunnels.
Type When configuring a business policy for an Edge, you can choose the Link Steering to prefer a Transport Group as: Public Wired, Public Wireless or Private Wired. See Configure Link Steering Modes. Choose Wired or Wireless, to put the overlay into a public wired or wireless transport group.
The following image shows Advanced settings for a Public Overlay.Figure 29. Advanced Settings for a Public Overlay 
Table 26. View Advanced Settings for Public Overlay Field Descriptions Option Description Private Network Name If you have more than one private network and want to differentiate between them to ensure that the Edges try to tunnel only to Edges on the same private network then define a Private Network Name and attach the Overlay to it. This prevents tunneling to Edges on a different private network they cannot reach. In addition, configure the Edges in other locations on this private network to use the same private network name. For example:
Edge1 GE1 is attached to private network A. Use private network A for the private overlay attached to GE1.
Edge1 GE2 is attached to private network B. Use private network B for the private overlay attached to GE2.
Repeat the same attachment and naming for Edge2.
When you enable branch to branch or when Edge2 is a hub site:- Edge1 GE1 attempts to connect to Edge2 GE1 and not GE2.
- Edge1 GE2 attempts to connect to Edge2 GE2 and not GE1.
Configure Static SLA Forces the overlay to assume that the SLA parameters being set are the actual SLA values for the path. No dynamic measurement of packet loss, latency or jitter will be done on this overlay. The QoE report use these values for its Green/Yellow/Red coloring against thresholds. Note: Static SLA configuration is not supported from release 3.4. It is recommended not to use this option, as dynamic measurement of packet loss, latency and jitter will provide a better outcome.The following image shows Advanced settings for a Private Overlay:
Figure 30. Advanced Settings for a Private Overlay 
- Select Add Link to save the configuration.
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 following image, 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 covers how bandwidth measurement is performed on a WAN link using the VeloCloud SD-WAN service.
Once a WAN link is detected by the Edge, it first establishes DMPO (Dynamic Multi-Path Optimization) tunnels with one or more VeloCloud 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 are available in VeloCloud 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 VeloCloud 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 3 seconds, the Edge sends the UDP traffic at a rate of 5000 packets per second, and for the remaining 2 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, VeloCloud 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 .
- 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 VeloCloud 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 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 service for customers with hybrid environments who deploy in sites with only a private WAN link.
- 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 Edge with only MPLS connection.

The traffic from the 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 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
- 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. The configuration options for the selected Edge are displayed in the Device tab.
- In the Connectivity category, expand Interfaces.
- The different types of Interfaces available for the selected Edge are displayed. Select the link to an Interface connected to the MPLS link.
- In the Interface window, select the Override check box and from the WAN Link drop-down menu, select User Defined and select Save.
Figure 35. Configure User Defined WAN Link
Note: The SD-WAN Service Reachable is available only for a User Defined network. - In the WAN Link Configuration section, select the Interface activated with User Defined WAN link. The User Defined WAN Link window appears.
Figure 36. Configure SD-WAN Service Reachability 
- In the User Defined WAN Link window, select the SD-WAN Service Reachable check box to deploy sites which only have a private WAN link and/or activate the capability to failover critical Internet traffic to a private WAN link.
When you select the SD-WAN Service Reachable check box, a list of public IP addresses of Gateways and Orchestrator is displayed, which may need to be advertised across the private network, if a default route has not been already advertised across the same private network from the firewall.
When you select the SD-WAN Service Reachable Backup check box, the Private SD-WAN reachable link is used as the backup link for Internet and as an active link for Enterprise destinations, if Public WAN overlays are present. When this option is deactivated, the Private link is used as an active link.
- Configure other options as required, and then select Update Link to save the settings.
For additional information on other options in the WAN Overlay window, see Configure Edge WAN Overlay Settings.
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.
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:
Configure DHCPv6 Prefix Delegation for Edges
DHCPv6 Prefix Delegation feature allows packet exchange between a DHCP Client and a DHCP Server. The Edge requests the server to provide prefixes over the WAN interfaces to delegate to clients on the LAN side. The server provides a prefix to the Edge in response. The Edge then configures an IP address on the LAN interface using this delegated prefix. The Edge starts sending out router advertisements with this prefix.
You can override the Prefix Delegation settings configured on a Profile (see Configure DHCPv6 Prefix Delegation for Profiles.) To configure DHCPv6 Prefix Delegation on an Edge, ensure that the Edge has upgraded to a version that supports this feature, then perform the following steps:
- 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. The configuration options for the selected Edge display on the Device tab.
- DHCPv6 Prefix Delegation can be configured on WAN, LAN, and VLAN interfaces. See the following sections for additional details:
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
At the Edge level, you can override the Wi-Fi Radio settings specified in the Profile, by selecting the Override check box. 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.
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. The address is populated automatically after the Edge is activated; however, you can override the address manually, if needed. If you want to change the location of the Edge, go to the Contact & Location section of the Edge Overview configuration page and select Edit Location to set the Edge location, and then select Save Changes.
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.
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:
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.

If you choose to configure a GRE tunnel manually, then you must configure GRE tunnel parameters manually for the selected WAN interface to be used as source by the GRE tunnel, by following the steps below.
Automated Zscaler CSS Provider Configuration for Edges
- IPsec/GRE Tunnel Automation
- Zscaler Location/Sub-Location Configuration
IPsec/GRE Tunnel Automation
IPsec/GRE tunnel automation can be configured for each Edge segment. Perform the following steps to establish automatic tunnels from an Edge.
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, go to . The Edges page displays the existing Edges.
- 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 57. Override Zscaler Settings 
- 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 58. Create 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 under 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 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
Describes 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:
VeloCloud SD-WAN supports configuring BFD for BGP and OSPF.
- 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.
LAN-side NAT Rules at Edge Level
LAN-Side NAT (Network Address Translation) 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.
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.
To configure ICMP Probes, perform the following steps:
- Configure ICMP Probes:
- 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 .
- VRRP HA updated to primary
- VRRP HA updated out of primary
- VRRP Failed
Configure Visibility Mode for Edges
This section describes 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 Syslog Settings for Edges
- Ensure that Cloud VPN (branch-to-branch VPN settings) is configured for the Edge (from where the Orchestrator bound events are originating) to establish a path between the Edge and the Syslog collectors. For additional information, see Configure Cloud VPN for Profiles.
In an Enterprise network, Orchestrator supports collection of Orchestrator bound events and firewall logs originating from enterprise 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.
To understand the format of a Syslog message for Firewall logs, see Syslog Message Format for Firewall Logs.
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 VeloCloud 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.
Configure SNMP Settings for Edges
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 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.
Follow the below steps to download the Edge MIB:
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.
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.
The virtualization of both NFV and VNF denotes that network functions are implemented in a generalized manner independent of the underlying hardware. VNFs can run in any VM environment in the branch office, cloud, or data center. This architecture allows you to:
- 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:
| VeloCloud 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 |
| VeloCloud 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 | 1 Mbps | 300 Mbps | 600 Mbps | 1 Gbps |
| 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 |
| VeloCloud 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 | 1 Mbps | 300 Mbps | 600 Mbps | 1 Gbps |
| 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 release 4.0.0, FortiOS version 6.4.0 and 6.2.4 are supported. |
Release 6.0 and 6.2.0
Starting from 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 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
You can deploy and forward traffic through VNF on the Edge, using third-party firewalls.
- Orchestrator and activated 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.
Only an Operator can activate the Security VNF configuration. If the Security VNF option is not available for you, contact your Operator.
Configure Security VNF with High Availability
You can configure security VNF on Edges configured with High Availability to provide redundancy.
- Orchestrator and activated 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.
- 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.
You can configure VNF with HA on Edges in the following scenarios:
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
You can insert the security VNF into both the VLAN as well as routed interface.
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.
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:
To view VNF network services configured for the Enterprise:
- In the SD-WAN Service of the Enterprise portal, select . The list of Edges along with the details of configured VNFs is displayed.
Figure 97. View Edge VNFs Details in Network Services Screen 
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.
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 check box. By default, at the Edge level, the NTP Servers are deactivated.
- To configure an Edge to act as an NTP Server for its Clients, you must first configure the Edge's own NTP time sources by defining Private NTP Servers under .
- NTP Clients can synchronize to LAN/loopback IP address of the 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.













































































