Configure Device Settings for Profiles
This section discusses how to configure a profile device.
In the SD-WAN service of the Enterprise portal, you can perform various configuration settings for a Profile by navigating to the tab. For additional information about Segmentation, see Configure Segments.
Configure a Profile Device
Device configuration page allows you to assign segments to a Profile and configure various settings and interfaces to be associated with a Profile.

The View drop-down menu at the left side of the page allows the user to select the view options. The available options are Expand All and Collapse All. By default, the settings are collapsed.
The Sort drop-down menu at the left side of the page allows the user to select the sort options: Sort by category and Sort by segment aware. You can view the configuration settings sorted by category or segment aware. By default, the settings are sorted by category. If you choose to sort by segmentation, the settings are grouped as Segment Aware and Segment Agnostic as shown in the following screen shot.
In Segment Aware configurations, configuration settings apply only to a specific segment selected from the Segment drop-down menu. In Segment Agnostic configurations, configuration settings apply to multiple segments.

Profile Device Configurations—A Roadmap
The following table provides the list of Profile-level configurations:
| Settings | Description |
|---|---|
| VLAN | Configure the VLANs with both IPv4 and IPv6 addresses for Profiles. Select the IPv4 or IPv6 tabs to configure the corresponding IP addresses for the VLANs. See Configure VLAN for Profiles. |
| Management IP | The Management IP address is used as the source address for local services like DNS and as a destination for diagnostic tests like pinging from another Edge. See Configure Management IP Address for Profiles. |
| ARP Timeouts | By default, the ARP Timeout values are configured. If required, select the Override default ARP Timeouts checkbox, to modify the default values. See Configure Address Resolution Protocol Timeouts for Profiles. |
| Interfaces | Configure the Interface Settings for each Edge model. See Configure Interface Settings for Profile. |
| Global IPv6 | Activate IPv6 configurations globally. See Global IPv6 Settings for Profiles. |
| Wi-Fi Radio | Turn on or turn off Wi-Fi Radio and configure the band of radio frequencies. See Configure Wi-Fi Radio Settings for Profiles. |
| Common Criteria Firewall | Common Criteria (CC) is an international certification accepted by many countries. Obtaining the CC certification is an endorsement that our product has been evaluated by competent and independent licensed laboratories for the fulfilment of certain security properties. This certification is recognized by all the signatories of the Common Criteria Recognition Agreement (CCRA). The CC is the driving force for the widest available mutual recognition of secure IT products. Having this certification is an assurance of security to a standard extent and can provide Arista with the much needed business parity or advantage with its competitors.
Enterprise users can configure the Common Criteria Firewall settings. By default, this feature is deactivated. See Configure Common Criteria Firewall Settings for Profiles. |
| Settings | Description |
|---|---|
| Cloud VPN | Activate Cloud VPN to initiate and respond to VPN connection requests. In the Cloud VPN, you can establish tunnels as follows:
Select the checkboxes as required and configure the parameters to establish the tunnels. See Configure Cloud VPN for Profiles. |
| Non SD-WAN Destination via Edge | Activate to establish tunnel between a branch and Non SD-WAN destination via Edge. See Configure a Tunnel Between a Branch and a Non SD-WAN Destinations via Edge.
Select Add to add Non SD-WAN Destinations. Select New NSD via Edge to create new Non SD-WAN Destination via Edge. See Configure Non SD-WAN Destinations via Edge. |
| Hub or Cluster Interconnect | VeloCloud SD-WAN supports interconnection of multiple Hub Edges or Hub Clusters to increase the range of Spoke Edges that can communicate with each other. This feature allows communication between the Spoke Edges connected to one Hub Edge or Hub Cluster and the Spoke Edges connected to another Hub Edge or Hub Cluster, using multiple overlay and underlay connections. See Hub or Cluster Interconnect. |
| Cloud Security Service | Activate to establish a secured tunnel from an Edge to cloud security service sites. This allows the secured traffic being redirected to third-party cloud security sites. See Cloud Security Services. |
| Zscaler | Allows to establish a secured tunnel from an Edge to Zscaler sites. See Configure Zscaler Settings for Profiles. |
| Gateway Handoff Assignment | Allows to assign Partner Gateways for Profiles or Edges. In order for customers to be able assign Partner Gateways, the Partner Handoff feature must be activated for the customers. See Assign Partner Gateway Handoff. |
| Controller Assignment | Allows to assign Controllers for Profiles or Edges. In order for customers to be able assign Controllers, the Partner Handoff feature must be activated for the customers. See Assign Controllers. |
| Settings | Description |
|---|---|
| Multicast | Activate and configure Multicast to send data to only interested set of receivers. See Configure Multicast Settings for Profiles. |
| DNS | Use the DNS Settings to configure conditional DNS forwarding through a private DNS service and to specify a public DNS service to be used for querying purpose. See Configure DNS for Profiles. |
| OSPF | Configure OSPF areas for the selected Profile. See Activate OSPF for Profiles. |
| BFD | Configure BFD settings for the selected Profile. See Configure BFD for Profiles. |
| LAN-Side NAT Rules | Allows you to NAT IP addresses in an unadvertised subnet to IP addresses in an advertised subnet. See LAN-Side NAT Rules at Profile Level. |
| BGP | Configure BGP for Underlay Neighbors and Non SD-WAN Neighbors. See Configure BGP from Edge to Underlay Neighbors for Profiles. |
| Settings | Description |
|---|---|
| Visibility Mode | Choose the visibility mode to track the network using either MAC address or IP address. See Configure Visibility Mode for Profiles. |
| Syslog | Configure Syslog collector to receive Orchestrator bound events and firewall logs from the Edges configured in an Enterprise. See Configure Syslog Settings for Profiles. |
| Netflow Settings | As an Enterprise Administrator, you can configure Netflow settings at the Profile level. Configure Netflow Settings for Profiles. |
| SNMP | Activate the required SNMP version for monitoring the network. Ensure that you download and install all the required SNMP MIBs before enabling SNMP. See Configure SNMP Settings for Profiles. |
| Settings | Description |
|---|---|
| Authentication | Allows to select a RADIUS server to be used for authenticating a user. See Configure Authentication Settings for Profiles.
Select New RADIUS Service to create a new RADIUS server. For additional information, see Configure Authentication Services. |
| NTP | Activate to synchronize the system clocks of Edges and other network devices. See Configure NTP Settings for Profiles. |
Assign Segments in Profile
After creating a Profile, you can select the Segments that you want to include in your profile from the Segment drop-down menu in the Device tab.
To assign segments to a Profile, perform the following steps:
After you have assigned a Segment to the Profile, you can configure your Segment through the Segment drop-down menu. All Segments available for configuration are listed in the Segment drop-down menu. If a Segment is assigned to a VLAN or interface, it will display the VLAN ID and the Edge models associated with it.
When you choose a Segment to configure from the Segment drop-down menu, depending upon the Segment’s options, the settings associated with that Segment displays in the Segments area.

Configure VLAN for Profiles
As an Enterprise Administrator, you can configure VLANs in a Profile.
To configure VLAN settings in a Profile:
Configure Management IP Address for Profiles
The Management IP address is used as the source address for local services (for example, DNS) and as a destination for diagnostic tests (for example, pinging from another Edge). The Management IP is deprecated and is replaced with Loopback Interfaces.

Configure Address Resolution Protocol Timeouts for Profiles
VeloCloud Orchestrator supports Address Resolution Protocol (ARP) timeout configuration to allow the user to override the default timeout values of the ARP table entries. VeloCloud Orchestrator allows configuration of three types of timeouts: Stale, Dead, and Cleanup. The default values for the various ARP timeouts are Stale: 2 minutes, Dead: 25 minutes, and Cleanup: 4 hours.
To override the default ARP timeouts at the Profile-level, perform the following steps:
At the Edge-level, you can override the inherited ARP Timeouts for specific edges. For additional information, see Configure Address Resolution Protocol Timeouts for Edges.
Configure Interface Settings
This section discusses how to configure the Interface Settings for one or more Edge models in a Profile.
When you configure the Interface Settings for a Profile, the settings are automatically applied to the Edges that are associated with the profile. If required, you can override the configuration for a specific Edge. See Configure Interface Settings for Edges.
Depending on the Edge Model, each interface can be a Switch Port (LAN) interface or a Routed (WAN) Interface. Depending on the Branch Model, a connection port is a dedicated LAN or WAN port, or ports can be configured to be either a LAN or WAN port. Branch ports can be Ethernet or SFP ports. Some Edge models may also support wireless LAN interfaces.
It is assumed that a single public WAN link is attached to a single interface that only serves WAN traffic. If no WAN link is configured for a routed interface that is WAN capable, it is assumed that a single public WAN link should be automatically discovered. If one is discovered, it will be reported to the Orchestrator. This auto-discovered WAN link can then be modified via the Orchestrator and the new configuration pushed back to the branch.
- If the routed Interface is activated with the WAN overlay and attached with a WAN link, then the interface will be available for all Segments.
- If an interface is configured as PPPoE, it will only support a single auto-discovered WAN link. Additional links cannot be assigned to the interface.
- Private WAN links
- Multiple WAN links on a single interface. Example: A Datacenter Hub with 2 MPLS connections
- A single WAN link reachable over multiple interfaces. Example: for an active-active HA topology
Links that are auto-discovered are always public links. User-defined links can be public or private, and will have different configuration options based on which type is selected.
Public WAN Links
Public WAN links are any traditional link providing access to the public internet such as Cable, DSL, etc. No peer configuration is required for public WAN links. They will automatically connect to the Gateway, which will handle the dissemination of information needed for peer connectivity.
Private (MPLS) WAN Links
Private WAN links belong to a private network and can only connect to other WAN links within the same private network. Because there can be multiple MPLS networks, within a single enterprise, for example, the user must identify which links belong to which network. The Gateway uses this information to distribute connectivity information for the WAN links.
You may choose to treat MPLS links as a single link. However, to differentiate between different MPLS classes of service, multiple WAN links can be defined that map to different MPLS classes of service by assigning each WAN link a different DSCP tag.
Additionally, you may decide to define a static SLA for a private WAN link. This will eliminate the need for peers to exchange path statistics and reduce the bandwidth consumption on a link. Since probe interval influences how quickly the device can fail over, it’s not clear whether a static SLA definition should reduce the probe interval automatically.
Device Settings
You can configure the interface settings for one or more Edge models in a Profile by navigating to the . The following screen illustrates the various Edge models and the Interface Settings that can be configured for the supported Edge devices from the Device Settings page of the selected Profile.
Select an Edge model to view the Interfaces available in the Edge.

The following table describes the various interface settings configurable for the selected Edge model:
| Your Edge Models | Select the Edge model for which you want to configure Interface settings from the drop-down menu. The selected Edge models appear in the Interfaces section. Select and expand the Edge model to configure the interface settings. |
| General |
|
| Switch Port Settings | The list of Switch Ports with a summary of some of their settings (such as Access or Trunk mode and the VLANs for the interface). Switch Ports are highlighted with a light, yellow background. |
| Routed Interface Settings | The list of Routed Interfaces with a summary of their settings (such as the addressing type and if the interface was auto-detected or has an Auto Detected or User Defined WAN overlay). Routed Interfaces are highlighted with a light, blue background. |
| Multicast | The Multicast settings configured for the interfaces in the Profile. The following are supported Multicast settings:
|
| Add Wi-Fi SSID | The list of Wireless Interfaces (if available on the Edge device). You can add additional wireless networks by selecting the Add Wi-Fi SSID button. |
| Add SubInterface | You can add sub interfaces by selecting the Add SubInterface button. Sub interfaces are displayed with "SIF" next to the interface. Sub interface for PPPoE interfaces is not supported. |
| Add Secondary IP | You can add secondary IPs by selecting the Add Secondary IP button. Secondary IPs are displayed with 'SIP" next to the interface. |
Edge 710
The Edge 710 is different from all the previous Wi-Fi models, as it has two separate radios for bands 2.4GHz and 5GHz. Dual-radio models independently use both 2.4 and 5GHz bands. However, if the 5GHz band is selected in an unsupported country, it is deactivated, and the 2.4GHz band is activated by default.

Edge 710 Troubleshooting
- If the desired outcome is 5GHz Wi-Fi, but the Edge is operating in 2.4GHz:
Check the device-level location settings:
- The location country must be a country that allows 5GHz.
- The country name must be a proper ISO 3166-1 2-character country code.
- Ensure that the desired IEEE 802.11 standards (802.11n, 802.11ac, 802.11ax, etc.), are explicitly set at the device-level.
Edge 710 5G

Edge 710 5G Troubleshooting
- 710 5G Modem Information Diagnostic Test: If the Edge 710 5G device is configured, the “LTE Modem Information” diagnostic test is available. The LTE Modern Information diagnostic test retrieves diagnostic information, such as signal strength, connection information, etc. For information on how to run a diagnostic test, see Arista VeloCloud SD-WAN Troubleshooting Guide.
- If two 710 5G SIM cards are inserted, CELL1(SIM1/right) is activated by default.
- To use CELL2 (SIM2/left), perform either of the following:
- Reboot the Edge 710 5G with the SIM2 only.
- Perform the SIM switch from the Orchestrator with both SIMs inserted.
- Hot swapping SIM cards is not supported; a reboot is required.
- If you wish to remove a SIM slot, the SIM must be fully removed from the SIM cage. If some part of the SIM is still inserted in the SIM cage, the Orchestrator displays the CELL instance, but the CELL Interface will not be functional.

Edge 610-LTE
The Edge 610-LTE is an extension of the Edge 610 with an integrated CAT12 EM75xx Sierra Wireless (SWI) modem. The 610-LTE device supports all the features that the 510-LTE offers, with an additional power of an CAT12 module and with a wide range of bands covering various geographical locations. The 610-LTE Edge device has two physical SIM slots. The top slot represents SIM1 and is mapped to the WAN routed interface CELL1. The bottom slot represents SIM2 and is mapped to the WAN routed interface CELL2.

Edge 610-LTE Troubleshooting
- 610-LTE Modem Information Diagnostic Test: For the 4.2.0 release, if the Edge 610-LTE device is configured, the “LTE Modem Information” diagnostic test will be available. The LTE Modern Information diagnostic test will retrieve diagnostic information, such as signal strength, connection information, etc. For information on how to run a diagnostic test, see Arista VeloCloud SD-WAN Troubleshooting Guide.
- If two 610-LTE SIM cards are inserted, CELL1(top slot/SIM1) will be activated by default.
- To use CELL2 (bottom slot/SIM2) do either of the following:
- Reboot the 610-LTE Edge with the SIM2 only.
- Perform the SIM switch from the Orchestrator with both SIMs inserted.
- Hot swapping SIM cards is not supported; a reboot is required.
- If you want to remove a SIM slot, the SIM must be fully removed from the SIM cage. If some part of the SIM is still inserted in the SIM cage, the Orchestrator displays the CELL instance, but the CELL Interface will not be functional. The following image shows the CELL1(SIM1 slot), where SIM1 is not fully inserted or removed.
Figure 14. Edge 610-LTE Troubleshooting 
Edge 3810
Edge 3810 is an evolution of the Edge 3800 platform, which includes 6 GE ports and 8 SFP ports. Otherwise, the functionally is identical to the Edge 3800.
Edge 7X0
- Edge 720 supports 2x 10-GbE SFP+, 6x 2.5-GbE RJ45, and 2x USB 3.0 ports.
- Edge 740 supports 2x 10-GbE SFP+, 6x 2.5-GbE RJ45, and 2x USB 3.0 ports.
Edge 6X0
Edge 510-LTE
For the Edge 510-LTE model, a new routed interface (CELL1) is displayed in the Interface Settings. To edit the Cell Settings, see Configure Interface Settings for Profile.
Edge 4100
- 10x 1-Gbps RJ45
- 8x 10-Gbps SFP+
It does not include Wi-Fi or Cellular Modem.
User-defined WAN Overlay Use Cases
The scenarios wherein this configuration is useful are outlined first, followed by a specification of the configuration itself.
- Use Case 1: Two WAN links connected to an L2 Switch- Consider the traditional data center topology where the Edge is connected to an L2 switch in the DMZ that is connected to multiple firewalls, each connected to a different upstream WAN link.
Figure 15. Two WAN links connected to an L2 Switch 
In this topology, the interface has likely been configured with FW1 as the next hop. However, in order to use the DSL link, it must be provisioned with an alternate next hop to which packets should be forwarded, because FW1 cannot reach the DSL. When defining the DSL link, the user must configure a custom next hop IP address as the IP address of FW2 to ensure that packets can reach the DSL modem. Additionally, the user must configure a custom source IP address for this WAN link to allow the edge to identify return interfaces. The final configuration becomes similar to the following figure:
The following paragraph describes how the final configuration is defined.Figure 16. Final Configuration 
- The interface is defined with IP address
10.0.0.1and next hop10.0.0.2. Because more than one WAN link is attached to the interface, the links are set to “user defined.” - The Cable link is defined and inherits the IP address of
10.0.0.1and next hop of10.0.0.2. No changes are required. When a packet needs to be sent out the cable link, it is sourced from10.0.0.1and forwarded to the device that responds to ARP for10.0.0.2(FW1). Return packets are destined for10.0.0.1and identified as having arrived on the cable link. - The DSL link is defined, and because it is the second WAN link, the Orchestrator flags the IP address and next hop as mandatory configuration items. The user specifies a custom virtual IP (e.g.
10.0.0.4) for the source IP and10.0.0.3for the next hop. When a packet needs to be sent out the DSL link, it is sourced from10.0.0.4and forwarded to the device that responds to the ARP for 10.0.0.3 (FW2). Return packets are destined for10.0.0.4and identified as having arrived on the DSL link.
- The interface is defined with IP address
- Use Case 2: Two WAN links connected to an L3 switch/router- Alternatively, the upstream device may be an L3 switch or a router. In this case, the next hop device is the same (the switch) for both WAN links, rather than different (the firewalls) in the previous example. Often this is leveraged when the firewall sits on the LAN side of the Edge.
Figure 17. Two WAN links connected to an L3 switch/router 
In this topology, policy-based routing will be used to steer packets to the appropriate WAN link. This steering may be performed by the IP address or by the VLAN tag, so we support both options.
Steering by IP: If the L3 device is capable of policy-based routing by source IP address, then both devices may reside on the same VLAN. In this case, the only configuration required is a custom source IP to differentiate the devices.
Figure 18. Steering by IP
The following paragraph describes how the final configuration is defined.- The interface is defined with IP address
10.0.0.1and next hop10.0.0.2. Because more than one WAN link is attached to the interface, the links are set to “user defined.” - The Cable link is defined and inherits the IP address of
10.0.0.1and next hop of10.0.0.2. No changes are required. When a packet needs to be sent out the cable link, it is sourced from10.0.0.1and forwarded to the device that responds to ARP for10.0.0.2(L3 Switch). Return packets are destined for10.0.0.1and identified as having arrived on the cable link. - The DSL link is defined, and because it is the second WAN link, the Orchestrator flags the IP address and next hop as mandatory configuration items. The user specifies a custom virtual IP (for example,
10.0.0.3) for the source IP and the same10.0.0.2for the next hop. When a packet needs to be sent out the DSL link, it is sourced from10.0.0.3and forwarded to the device that responds to the ARP for10.0.0.2(L3 Switch). Return packets are destined for10.0.0.3and identified as having arrived on the DSL link.
Steering by VLAN: If the L3 device is not capable of source routing, or if for some other reason the user chooses to assign separate VLANs to the cable and DSL links, this must be configured.
Figure 19. Steering by VLAN 
- The interface is defined with IP address
10.100.0.1and next hop10.100.0.2on VLAN 100. Because more than one WAN link is attached to the interface, the links are set to “user defined.” - The Cable link is defined and inherits VLAN 100 as well as the IP address of
10.100.0.1and next hop of10.100.0.2. No changes are required. When a packet needs to be sent out the cable link, it is sourced from10.100.0.1, tagged with VLAN 100 and forwarded to the device that responds to ARP for10.100.0.2on VLAN 100 (L3 Switch). Return packets are destined for10.100.0.1/VLAN 100 and identified as having arrived on the cable link. - The DSL link is defined, and because it is the second WAN link the Orchestrator flags the IP address and next hop as mandatory configuration items. The user specifies a custom VLAN ID (200) as well as virtual IP (e.g.
10.200.0.1) for the source IP and the10.200.0.2for the next hop. When a packet needs to be sent out the DSL link, it is sourced from10.200.0.1, tagged with VLAN 200 and forwarded to the device that responds to the ARP for10.200.0.2on VLAN 200 (L3 Switch). Return packets are destined for10.200.0.1/VLAN 200 and identified as having arrived on the DSL link.
- The interface is defined with IP address
- Use Case 3: One-arm Deployments- One-arm deployments end up being very similar to other L3 deployments.
Figure 20. Use Case 3: One-arm Deployments 
Again, the Edge shares the same next hop for both WAN links. Policy-based routing can be done to ensure that traffic is forwarded to the appropriate destination as defined above. Alternately, the source IP and VLAN for the WAN link objects may be the same as the VLAN of the cable and DSL links to make the routing automatic.
- Use Case 4: One WAN link reachable over multiple interfaces- Consider the traditional gold site topology where the MPLS is reachable via two alternate paths. In this case, we must define a custom source IP address and next hop that can be shared regardless of which interface is being used to communicate.
Figure 21. Use Case 4: One WAN link reachable over multiple interfaces 
- GE1 is defined with IP address
10.10.0.1and next hop10.10.0.2. - GE2 is defined with IP address
10.20.0.1and next hop10.20.0.2. - The MPLS is defined and set as reachable via either interface. This makes the source IP and next hop IP address mandatory with no defaults.
- The source IP and destination are defined, which can be used for communication irrespective of the interface being used. When a packet needs to be sent out the MPLS link, it is sourced from
169.254.0.1, tagged with the configured VLAN and forwarded to the device that responds to ARP for169.254.0.2on the configured VLAN (CE Router). Return packets are destined for169.254.0.1and identified as having arrived on the MPLS link.
Note: If OSPF or BGP is not activated, you may need to configure a transit VLAN that is the same on both switches to allow reachability of this virtual IP. - GE1 is defined with IP address
Configure Interface Settings for Profile
In a Profile, you can configure interface settings for various Edge models.
You can configure the interface settings for each Edge model. Each interface in an Edge can be a Switched port (LAN) or a Routed (LAN or WAN) interface. The interface settings vary based on the Edge model. For additional information on different Edge models and deployments, see Configure Interface Settings.
To configure the interface settings for different Edge models in a Profile:
- In the SD-WAN service of the Enterprise portal, go to .
- The Profiles page displays the existing Profiles.
- Select the link to a Profile or select the View link in the Device column of the Profile. You can also select a Profile and select Modify to configure the Profile.
- The configuration options for the selected Profile are displayed in the Device tab.
- In the Connectivity category, select Interfaces. The Edge models available in the selected Profile are displayed:
Figure 22. Interfaces 
- Select an Edge model to view the interfaces available in the Edge.
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 SubInterface, Secondary IP address, and Wi-Fi SSID based on the Edge model.
Figure 23. Add SubInterface, Secondary IP address, and Wi-Fi SSID 
- Configure the settings for a Routed interface. See the table below for a description of these configuration settings.
Note: The interface settings in the table below can be overwritten at the Edge level.
Figure 24. Routed Interface 
Table 10. Routed Interface- Options and Descriptions Option Description Description Type the description. This field is optional. Interface Enabled This check box is selected by default. If required, you can deactivate the interface. When deactivated, the interface is not available for any communication. Capability For a Routed interface, the option Routed is selected by default. You can choose to convert the port to a Switch port interface by selecting the option Switched from the drop-down list. Segments By default, the configuration settings are applicable to all the segments. This field cannot be edited. 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.Enable WAN Overlay This check box is selected by default. This helps to activate WAN overlay for the interface. DNS Proxy The DNS Proxy feature provides additional support for Local DNS entries on the Edges associated with the Profile, 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.If IPv4/IPv6 DHCP Server is activated and DNS Proxy is deactivated then the DNS Proxy feature will not work as expected and may result in DNS resolution failure.VLAN For an Access port, select an existing VLAN from the drop-down list. For a Trunk port, you can select multiple VLANs and select an untagged VLAN. IPv4 Settings – Select the check box to activate IPv4 Settings. Addressing Type By default, DHCP is selected, which assigns an IPv4 address dynamically. If you select Static or PPPoE, you must configure the addressing details for each Edge. WAN Overlay By default, Auto-Detect Overlay is activated. You can choose the User Defined Overlay and configure the Overlay settings. For additional information, see Configure Edge WAN Overlay Settings. Note:- Enabling OSPF on a WAN Overlay interface will be treated as OSPF in the Global segment on that interface.
- If you have a CSS GRE tunnel created for an Edge and if you change the WAN Overlay settings of the WAN link associated with the CSS tunnel interface from "Auto-Detect Overlay" to "User-Defined Overlay", the WAN link and the associated CSS tunnels are also removed from the CSS configuration at the Edge level.
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 list. Select Advanced settings to configure the advanced interface settings for the selected OSPF area.
Figure 25. Advanced Settings
For additional information on OSPF settings and OSPFv3, see Activate OSPF for Profiles.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.Note: OSFPv3 is only available in the 5.2 release.Multicast This option is available only when you have configured multicast settings for the Profile. You can configure the following multicast settings for the selected interface. - IGMP- Select the check box to activate Internet Group Management Protocol (IGMP). Only IGMP v2 is supported.
- PIM – Select the check box to activate Protocol Independent Multicast. Only PIM Sparse Mode (PIM-SM) is supported.
Select toggle advanced multicast settings to configure the following timers:- PIM Hello Timer – The time interval at which a PIM interface sends out Hello messages to discover PIM neighbors. The range is from 1 to 180 seconds and the default value is 30 seconds.
- IGMP Host Query Interval – The time interval at which the IGMP querier sends out host-query messages to discover the multicast groups with members, on the attached network. The range is from 1 to 1800 seconds and the default value is 125 seconds.
- IGMP Max Query Response Value – The maximum time that the host has to respond to an IGMP query. The range is from 10 to 250 deciseconds and the default value is 100 deciseconds.
Note: Currently, Multicast Listener Discovery (MLD) is deactivated. Hence, Edge will 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 would result 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 activate NAT Direct traffic for IPv4 on a routed 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 list: - Not Enabled – Allows incoming traffic even if there is no matching route in the route table.
- Specific – This option is selected by default, even when the Trusted Source option is deactivated. The incoming traffic should match a specific return route on the incoming interface. If a specific match is not found, then the incoming packet is dropped. This is a commonly used mode on interfaces configured with public overlays and NAT.
- Loose – The incoming traffic should match any route (Connected/Static/Routed) in the routing table. This allows asymmetrical routing and is commonly used on interfaces that are configured without next hop.
IPv6 Settings – Select the check box to activate IPv6 Settings. Addressing Type Choose one of the options from the following to assign an IPv6 address dynamically. - DHCP Stateless – Allows the interface to self-configure the IPv6 address. It is not necessary to have a DHCPv6 server available at the ISP. An ICMPv6 discover message originates from the Edge and is used for auto-configuration.
Note: In DHCP Stateless configuration, two IPv6 addresses are created at the Kernel interface level. The Edge does not use the host address which matches the Link local address.
- DHCP Stateful – This option is similar to DHCP for IPv4. The Gateway connects to the DHCPv6 server of the ISP for a leased address and the server maintains the status of the IPv6 address.
Note: In stateful DHCP, when the valid lifetime and preferred lifetime are set with the infinite value (0xffffffff(4294967295)), the timer does not work properly. The maximum value that the valid and preferred timers can hold is 2147483647.
- Static – If you select this option, you should configure the addressing details for each Edge.
Note: For Cell interfaces, the Addressing Type would be Static by default.WAN Overlay By default, Auto-Detect Overlay is activated. You can choose the User Defined Overlay and configure the Overlay settings. For additional information, see Configure Edge WAN Overlay Settings. 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 list. 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.For additional information on OSPF configuration, see Activate OSPF for ProfilesNote: OSFPv3 is only available in the 5.2 release.Advertise Select the check box to advertise the Interface to other branches in network. NAT Direct Traffic Select the check box to activate NAT Direct traffic for IPv6 on a routed 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 list: - Not Enabled – Allows incoming traffic even if there is no matching route in the route table.
- Specific – This option is selected by default, even when the Trusted Source option is deactivated. The incoming traffic should match a specific return route on the incoming interface. If a specific match is not found, then the incoming packet is dropped. This is a commonly used mode on interfaces configured with public overlays and NAT.
- Loose – The incoming traffic should match any route (Connected/Static/Routed) in the routing table. This allows asymmetrical routing and is commonly used on interfaces that are configured without next hop.
Router Advertisement Host Settings- These settings are available only when you select the IPv6 Settings check box, and choose the Addressing Type as DHCP Stateless or DHCP Stateful. Select the check box to display the following RA parameters. These parameters are activated by default. If required, you can deactivate them. Note: When RA host parameters are deactivated and activated again, then the Edge waits for the next RA to be received before installing routes, MTU, and ND/NS parameters.MTU Accepts the MTU value received through Route Advertisement. If you deactivate 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 deactivate this option, then there is no default routes available for the interface. Specific Routes Installs specific routes when Route Advertisement receives route information on the interface. If you deactivate this option, the interface does not install the route information. ND6 Timers Accepts ND6 timers received through Route Advertisement. If you deactivate this option, default ND6 timers are considered. The default value for NDP retransmit timer is 1 second and NDP reachable timeout is 30 seconds. L2 Settings Autonegotiate This check box is selected by default. This 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 deactivated. Select the speed at which the port communicates with other links. By default, 100 Mbps is selected. Duplex This option is available only when Autonegotiate is deactivated. 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 1500 bytes. You can change the MTU size for an interface. Note: A warning message is displayed when DNS proxy check box is selected in the following scenarios:- Both IPv4 and IPv6 DHCP Servers are Deactivated.
- IPv4 DHCP Server is in Relay state and IPv6 DHCP Server is Deactivated.
If you are using USB Modem to connect to the network, to enable IPv6 addressing, configure the following manually in the Edge:- Add the global parameter usb_tun_overlay_pref_v6:1 to
/etc/config/edged, to update the preference to IPv6 address. - Run the following command to update the IP type of the interface to IPv6.
/etc/modems/modem_apn.sh [USB] [ACTION] [ACTION ARGS...]Enter the parameters as follows:
- USB – Enter the USB Number
- Enter the APN settings as follows:
- apn – Enter the Access Point Name.
- username – Enter the username provided by the carrier.
- password – Enter the password provided by the carrier.
- spnetwork – Enter the name of the Service Provider Network.
- simpin – Enter the PIN number used to unlock the SIM card.
- auth – Specify the Authentication type.
- iptype – Enter the type of IP address.
The following is an example command with sample parameters:
/etc/modems/modem_apn.sh USB3 set ‘’vzwinternet’' ‘’ ‘VERIZON’ ‘’ ‘’ ‘ipv4v6’
Note: For a list of modems supported for use on an Edge, see the Supported Modems page. - Configure the settings for a Switched interface. See the table below for a description of these configuration settings.
Figure 26. Switched Interface Configuration Settings 
Table 11. Switched Interface Configuration Option Descriptions Option Description 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 list. Mode Select the mode of the port as Access or Trunk port. VLANs For an Access port, select an existing VLAN from the drop-down list. For a Trunk port, you can select multiple VLANs and select an untagged VLAN.
L2 Settings Autonegotiate This option is activated by default. When activated, 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 deactivated. 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 deactivated. 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 switch interfaces is 1500 bytes. You can change the MTU size for an interface. - You can also add a Subinterface, Secondary IP address, and Wi-Fi SSID based on the Edge model. Select Delete to remove a selected interface.
- To add Subinterfaces to an existing interface:
- In the Interface section, select Add SubInterface.
- In the Select Interface window, select an interface for which you want to add a subinterface.
- Enter the Subinterface ID and select Next.
- In the Sub Interface window, configure the Interface settings as per your requirement.
- Select Save.
Note: The OSPF support for a subinterface is added in the 6.1 release and so the Edge needs to be running the 6.1 version. Edges running lower versions (6.0 and below) will not process OSPF configuration.Note: When configuring additional OSPF area settings for a subinterface, BFD configuration is not supported for subinterfaces in all segments (global and non-global).
- To add Secondary IP addresses to an existing interface:
- In the Interface section, select Add Secondary IP.
- In the Select Interface window, select the interface for which you want to add a secondary IP address.
- Enter the Subinterface ID and select Next.
- In the Secondary IP window, configure the interface settings as per your requirement.
- Select Save.
- Some of the Edge models support Wireless LAN. To add Wi-Fi SSID to an existing interface:
- In the Interface section, select Add Wi-Fi SSID. The WLAN Interface settings window appears.
Figure 27. Add Wi-Fi SSID Interface Settings 
- Configure the following WLAN interface settings and select Save:
Table 12. WLAN Interface Option Descriptions Option Description Interface Enabled This option is enabled by default. If required, you can deactivate the interface. When deactivated, the interface is not available for any communication VLAN Choose the VLAN to be used by the interface. SSID Enter the wireless network name. Select the Broadcast check box to broadcast the SSID name to the surrounding devices.
Security Select the type of security for the Wi-Fi connection, from the drop-down list. The following options are available: - Open – No security is enforced.
- WPA2 / Personal – A password is required for authentication. Enter the password in the Passphrase field.
Note: Starting from the 4.5 release, the use of the special character "<" in the password is no longer supported. In cases where users have already used "<" in their passwords in previous releases, they must remove it to save any changes on the page.
- WPA2 / Enterprise – A RADIUS server is used for authentication. You should have already configured a RADIUS server and selected it for the Profile and Edge.
To configure a RADIUS server, see Configure Authentication Services.
To select the RADIUS server for a Profile, see Configure Authentication Settings for Profiles.
- In the Interface section, select Add Wi-Fi SSID. The WLAN Interface settings window appears.
- To add Subinterfaces to an existing interface:
- Select Save Changes in the Device window.
When you configure the interface settings for a Profile, the settings are automatically applied to the Edges that are associated with the profile. If required, you can override the configuration for a specific Edge. See Configure Interface Settings for Edges.
Configure DSL Settings
Support is available for xDSL SFP module. It is a highly integrated SFP bridged modem, which provides a pluggable SFP compliant interface to upgrade existing DSL IAD or home Gateway devices to higher bandwidth services.
Configuring DSL includes options for configuring ADSL and VDSL Settings. See Configure ADSL and VDSL Settings for additional information.
Troubleshooting DSL Settings
DSL Status Diagnostic Test: The DSL diagnostic test is available only for 610 devices. In the 4.3 release, testing is also available for the 620, 640, and 680 devices. Running this test will show the DSL status, which includes information such as Mode (Standard or DSL), Profile, xDSL Mode, etc. as shown in the image below.

Configure ADSL and VDSL Settings
The xDSL SFP module can be plugged into either the SD-WAN Edge 610 or the SD-WAN Edge 610-LTE device SFP slot and used in ADSL2+/VDSL2 mode. This module must be procured by the user.
You can configure the SFP interfaces only for the SD-WAN Edge 610 or the SD-WAN Edge 610-LTE device by navigating to the page in the SD-WAN service of the Enterprise portal.
Select the SFP interface that the specific DSL module is plugged into. When the SFP is plugged in, the slot name is displayed as SFP1 and SFP2 under the Interface column as shown in the following screenshot.

To Configure SFP at the Profile level:
Configure GPON Settings
Gigabit Passive Optical Network (GPON) is a point-to-multipoint access network that uses passive splitters in a fiber distribution network, enabling one single feeding fiber from the provider to serve multiple homes and small businesses. GPON supports triple-play services, high-bandwidth, and long reach (up to 20km).
GPON has a downstream capacity of 2.488 Gb/s and an upstream capacity of 1.244 Gbps/s that is shared among users. Encryption is used to keep each user’s data private and secure. There are other technologies that could provide fiber to the home; however, passive optical networks (PONs) like GPON are generally considered the strongest candidate for widespread deployments.
GPON Support
- Longer transmission distance: The transmission media of optical fibers covers up to 60 km coverage radius on the access layer, resolving transmission distance and bandwidth issues in a twisted pair transmission.
- Higher bandwidth: Each GPON port can support a maximum transmission rate of 2.5 Gbit/s in the downstream direction and 1.25 Gbit/s in the upstream direction, meeting the usage requirements of high-bandwidth services, such as high definition television (HDTV) and outside broadcast (OB).
- Better user experience on full services: Flexible QoS measures support traffic control based on users and user services, implementing differentiated service provisioning for different users.
- Higher resource usage with lower costs: GPON supports a split ratio up to 1:128. A feeder fiber from the CO equipment room can be split into up to 128 drop fibers. This economizes on fiber resources and O&M costs.
Configuring GPON ONT from the Orchestrator
You can configure the SFP GPON interface settings only for the SD-WAN Edge 610 or the SD-WAN Edge 610-LTE device by navigating to the page in the SD-WAN service of the Enterprise portal.
Select the SFP interface that the specific GPON module is plugged into. When the SFP is plugged in, the slot name will display as SFP1 and SFP2 in the Interfaces area of the Orchestrator.

To configure GPON ONT SFP at the Profile Level from the Orchestrator:
Troubleshooting GPON Settings
The GPON diagnostic test is available only for 6X0 devices. For additional information, see the Arista VeloCloud SD-WAN Troubleshooting Guide.
Configure DHCPv6 Prefix Delegation for Profiles
To configure DHCPv6 Prefix Delegation for a Profile, perform the following steps:
DHCPv6 Prefix Delegation on a WAN interface
DHCPv6 Prefix Delegation on a LAN interface
DHCPv6 Prefix Delegation on a VLAN interface
IPv6 Settings
VeloCloud SD-WAN supports IPv6 addresses to configure the Edge Interfaces and Edge WAN Overlay settings.
The VCMP tunnel can be setup in the following environments: IPv4 only, IPv6 only, and dual stack.
Mixed Environment on Edge to Edge Network
If the initiator is dual-stack and the responder is single-stack, then the tunnel preference of initiator is ignored and tunnel is formed based on IP type of the responder. In other cases, the tunnel preference of the initiator takes precedence. You cannot establish overlay between an IPv4 only and IPv6 only Interfaces.

In the above example, the Edge B1 has dual stack Interface. The Edge B1 can build IPv4 VCMP to the IPv4 only Interface on Edge B2 (unpreferred tunnel) and IPv6 VCMP to the IPv6 only Interface on Edge B3 (preferred tunnel).
Mixed Environment on Edge to Gateway Network
When a dual-stack (both IPv4 and IPv6 activated) Edge connects to a single-stack Gateway (IPv4 only), IPv4 tunnel is established.

In the above illustration, the IPv4-only Gateway is connected to Edges E1 and E2 that have dual stack Interfaces with preference as IPv6. An IPv4 tunnel is established between the Gateway and Edges.
In this scenario, the Edges do not learn the public IPv6 endpoints of the other Edges/Hubs from the Gateway, as the Gateway is not IPv6 capable. They only learn the IPv4 endpoints, along with the information that the overlay preference of the other Edge or Hub is IPv6. Even though both the devices negotiate and understand that their overlay preference matches (IPv6), they will not be able to form IPv6 tunnels between them due to lack of IPv6 endpoint information. In addition, the overlay preference negotiation match (both IPv6) prevents the devices from forming IPv4 tunnels with each other.
In such cases where an Edge is connected to an IPv4-only Gateway, it is recommended to set the overlay preference as IPv4 so that the Edges can establish IPv4 tunnels among themselves.
Dual Stack Environment
- Edge to Gateway – The initiator, Edge, always chooses the tunnel type based on the tunnel preference.
- Edge to Hub – The initiator, Spoke Edge, always chooses the tunnel type based on the tunnel preference.
- Dynamic Branch to Branch – When there is a mismatch in the tunnel preference, the connection uses IPv4 addresses to ensure consistent and predictable behavior.
- When the Interfaces of Edge peers are set with same preference, the preferred address type is used.
- When the Interfaces of Edge peers are set with different preferences, then the preference of the initiator is used.

- Edge B1: IPv6
- Edge B2: IPv6
- Edge B3: IPv4
In the above example, a dynamic Edge to Edge tunnel is built over IPv4 between the Edges B2 and B3, regardless of the site that initiates the connection.
Impact of IPv6 Tunnel on MTU
When a branch has at least one IPv6 tunnel, DMPO uses this tunnel seamlessly along with other IPv4 tunnels. The packets for any specific flow can take any tunnel, IPv4 or IPv6, based on the real time health of the tunnel. An example for specific flow is path selection score for load balanced traffic. In such cases, the increased size for IPv6 header (additional 20 bytes) should be taken into account and as a result, the effective path MTU will be less by 20 bytes. In addition, this reduced effective MTU will be propagated to the other remote branches through Gateway so that the incoming routes into this local branch from other remote branches reflect the reduced MTU.
When there are single or multiple sub Interfaces available, the Route Advertisement MTU is not updated properly in sub Interface. The sub Interfaces inherit the MTU value from the Parent Interface. The MTU values received on sub interfaces are ignored and only the parent interface MTU is honored. When an Edge has single sub Interface or multiple sub Interfaces, you must turn off the MTU option in the Route Advertisement of the peer Router. As an alternative, you can modify the MTU value of a sub Interface in a user-defined WAN overlay. For additional information, see Configure Edge WAN Overlay Settings.
IPv6 Capability of Edge
The IPv6 Capability of an Edge is decided based on the IPv6 admin status of any interface. The Edge should have any one of the following activated with IPv6: Switched-VLAN, Routed-Interface, Sub-Interface, Loopback-Interface. This allows to categorize the Edge as IPv6 capable node to receive the IPv6 remote routes from Gateway.
Hubs always receive IPv6 remote routes, irrespective of their IPv6 Capability.
- Edge does not support configuring private overlay on one address family and public overlay on the other address family in the same routed Interface. If configured, the Edge would initiate the tunnel using the preferred address family configured on the routed Interface.
- The tunnel preference change can be disruptive for the PMTU overhead. When there is a change in the configuration to setup all Interfaces with IPv4 tunnel preference, the Edge to Edge or Hub to Spoke tunnels may be torn down and re-established to use the IPv4 overhead to ensure that the tunnel bandwidth is used optimally.
- In an Interface with different IP links, the bandwidth measured by the preferred tunnel or link is inherited by other links. Whenever the tunnel preference is changed for a link from IPv6 to IPv4 or vice versa, the link bandwidth is not measured again.
- When there is a change in the tunnel address or change in the preference of the tunnel from IPv6 to IPv4 address or vice versa, the existing flows are dropped in a Hub or Spoke. You should flush the flows in the Hub or Spoke to recover the bi-directional traffic.
- While monitoring the events for a Gateway in Operator Events page or an Edge in the page, when the Gateway or Edge is not able to send heartbeat, the corresponding event message displays the IPv6 address with hyphens instead of colons, in the following format: x-x-x-x-x-x-x-x. This does not have any impact on the functionality.
- Edge version running 4.x switched interface does not support IPv6 address.
- Edge does not use new IPv6 prefixes if it has multiple IPv6 prefixes because it might cause tunnel flaps. In this case, Edge prioritizes the old IPv6 prefix. If there is a need to use the new IPv6 prefix, it is recommended to bounce the Internet-facing WAN interface or restart the Edge for immediate recovery. Alternatively, you can wait until the old address entry ages out.
Management Traffic and IP Addresses
When Edge goes offline with multiple combination of IP address family being used, the Edge will not be able to communicate with the Orchestrator. This happens when sending direct traffic and link selection fails.
In Dual stack Orchestrator and Edge, the Management Plane Daemon (MGD) always prefers IPv6 address for MGD to Orchestrator communication. If IPv6 fails, then it falls back to IPv4. The following matrix shows IP family chosen by MGD for Orchestrator communication.
| Orchestrator | ||||
|---|---|---|---|---|
| Edge | IPv4 | IPv6 | Dual | |
| IPv4 | MGD traffic is IPv4 | Mismatched family | MGD traffic is IPv4 | |
| IPv6 | Mismatched family | MGD traffic is IPv6 | MGD traffic is IPv6 | |
| Dual | MGD traffic is IPv4 | MGD traffic is IPv6 | MGD traffic is IPv6 | |
MGD traffic is always sent over overlay through cloud Gateway unless all the paths to Gateway are down. In this case MGD traffic to Orchestrator is sent directly. The following is the logic to drain packet direct.
- Loop over all the Interface. In the following cases, the Edge is left with Interfaces consisting of activated WAN links only.
- Interface on which WAN overlay is deactivated is not considered.
- When Interface is single stack with IPv6 and traffic is IPv4, then it is not considered.
- When Interface is single stack with IPv4 and traffic is IPv6, then it is not considered.
- Loop over WAN link on Interface. In the following cases, the Edge is left with a WAN link that could be used even if paths are down to cloud Gateway.
- If WAN link is Standby, then it is not considered.
- If WAN link is Private, then it is not considered.
You can configure IPv6 addresses for the following:
- Configure Static Route Settings
- Configure Interface Settings for Edges
- Configure Edge WAN Overlay Settings
- Configure BGP
- Configure BFD for Profiles
- Configure DNS for Profiles
- Configure Firewall Rule
- Create Business Policy Rule
- Configure Object Groups
- Overlay Flow Control
- Global IPv6 Settings for Profiles
Global IPv6 Settings for Profiles
For IPv6 addresses, you can activate some of the configuration settings globally.
To activate global settings for IPv6 at the Profile level:
Monitor IPv6 Events
You can view the events related to the IPv6 configuration settings.
Troubleshooting IPv6 Configuration
You can run Remote Diagnostics tests to view the logs of the IPv6 settings and use the log information for troubleshooting purposes.
To run the tests for IPv6 settings:
Configure Wi-Fi Radio Settings for Profiles
The Wi-Fi radio setting for a Profile is enhanced to enable selection of dual radio frequency bands (2.4 GHz and 5 GHz). Depending on the Edge, you can select either one or both bands of radio frequencies.
The Wi-Fi radio setting for a Profile is activated by default. To access this feature, perform the following steps:
Configure Common Criteria Firewall Settings for Profiles
Common Criteria (CC) is an international certification accepted by many countries. Obtaining the CC certification is an endorsement that our product has been evaluated by competent and independent licensed laboratories for the fulfilment of certain security properties. This certification is recognized by all the signatories of the Common Criteria Recognition Agreement (CCRA). The CC is the driving force for the widest available mutual recognition of secure IT products. Having this certification is an assurance of security to a standard extent and can provide Arista with the much needed business parity or advantage with its competitors.
Enterprise users can configure the Common Criteria Firewall settings both at the Edge and Profile levels. By default, this feature is deactivated.
To configure Common Criteria Firewall settings for a Profile, perform the following steps:
Assign Partner Gateway Handoff
In order for customers to be able to assign Partner Gateways for Profiles or Edges, Operator must activate the Partner Handoff feature for the customers. If you want to activate the Partner Handoff feature, contact your Operator. Once you have the Partner Handoff feature activated, you can assign Partner Gateways from the page.
Considerations When Assigning Partner Gateways:
- Partner Gateways can be assigned at the Profile or Edge level.
- More than two Partner Gateways can be assigned to an Edge (up to 16).
- Partner Gateways can be assigned per Segment.
The Gateway Handoff Assignment feature has been enhanced to also support segment-based configurations. Multiple Partner Gateways can be configured on the Profile level and/or overridden on the Edge level.
- In the SD-WAN service of the Enterprise portal, go to .
- Select a profile you want to configure Gateway Handoff Assignment settings and select the View link in the Device column of the Profile. The Device page for the selected profile appears.
- Scroll down to VPN Services section and expand Gateway Handoff Assignment.
Figure 45. Configure Gateway Handoff Assignment 
- Select + Select Gateways, the Select Partner Gateways for Global Segment dialog box appears.
By default, Global Segment is selected in the Segment drop-down. You can also choose any other segment based on your requirements.
Figure 46. Select Partner Gateways for Global Segment 
- The Partner Gateways section lists the Gateways in the Gateway Pool that are configured as a Partner Handoff Gateway.
Note: If there are other Gateways not configured as a Partner Handoff Gateway, a following sample message will appear in the dialog box:
There is one other Gateway in the Gateway Pool that is not configured as a Partner Handoff Gateway.Note: If you want to see only the list of selected Partner Gateways then select Show only selected. - Select the Partner Gateways from the list that you want to assign to the Profile and select Update.
- The Partner Gateway assignments configured at the Profile level will be applied to all the Edges within the Profile. You can override the settings at the Edge level by selecting the Override check box.
Figure 47. Override Gateway Handoff Assignments 
Select CDE Gateways
In normal scenarios, the PCI traffic runs between the customer branch and Data Center where the PCI traffic is handoff to the PCI network and the Gateways are out of PCI scope. (The Operator can configure the Gateway to exclude PCI Segment by unchecking the CDE role).
In certain scenarios where Gateways can have a handoff to the PCI network and in the PCI scope, the Operator can activate CDE role for the Partner Gateways and these Gateways (CDE Gateways) will be available for the user to assign in the PCI Segments (CDE Type).
Assign a CDE Gateway
To assign a CDE Gateway:
-
- In the SD-WAN service of the Enterprise portal, go to .
- Select a profile you want to configure Gateway Handoff Assignment settings and select the View link in the Device column of the Profile. The Device page for the selected profile appears.
- Scroll down to VPN Services section and expand Gateway Handoff Assignment.
- Select + Select Gateways, the Select Partner Gateways for Global Segment dialog box appears.
Figure 48. Select Partner Gateways for Global Segment 
- In the Select Partner Gateways for Global Segment dialog box, in the Partner Gateways section select a Partner Gateway that is marked as CDE that you want to assign to the Profile and select Update.
Assign Controllers
The Gateway is activated for supporting both the data and control plane. VeloCloud SD-WAN introduces a Controller-only feature (Controller Gateway Assignment).
There are multiple use cases which require the Gateway to operate as a Controller only (that is, to remove the data plane capabilities). Additionally, this will activate the Gateway to scale differently, as resources typically dedicated for packet processing can be shifted to support control plane processing. This will activate, for instance, a higher number of concurrent tunnels to be supported on a Controller than on a traditional Gateway. See the following section for a typical use case.
Use Case: Dynamic Branch-to-Branch via Different Partner Gateways
In this scenario, Edge 1 (E1) and Edge 2 (E2) as shown in the image belong to the same enterprise in the Orchestrator. However, they connect to different Partner Gateways (typically due to being in different regions). Therefore, Dynamic Branch-to-Branch is not possible between E1 and E2, but by leveraging the Controller, this is possible.
Initial Traffic Flow
As shown in the image below, when E1 and E2 attempt to communicate directly, the traffic flow begins by traversing the private network as it would in previous versions of the code. Simultaneously, the Edges will also notify the Controller that they are communicating and request a direct connection.
Dynamic Tunnel
The Controller signals to the Edges to create the dynamic tunnel by providing E1 connectivity information to E2 and vice versa. The traffic flow moves seamlessly to the new dynamic tunnel if and when it is established.

Configuring a Gateway as a Controller
In order for customers to be able to assign Controllers for Profiles or Edges, Operator must activate the Partner Handoff feature for the customers. If you want to activate the Partner Handoff feature, contact your Operator. Once you have the Partner Handoff feature activated, you can assign a Partner Gateway as a Controller by navigating to the page.
To assign Controllers for Profiles, perform the following steps:
Configure Cloud VPN
Cloud VPN Overview
The Cloud Virtual Private Network (VPN) allows a VPNC-compliant IPSec VPN connection that connects Arista and Non SD-WAN Destinations. It also indicates the health of the sites (up or down status) and delivers real-time status of the sites.
- Branch to Non SD-WAN Destination via Gateway
- Branch to Hub
- Branch to Branch VPN
- Branch to Non SD-WAN Destination via Edge
The following figure represents all three branches of the Cloud VPN. The numbers in the image represent each branch and correspond to the descriptions in the table that follows.

|
|
Non SD-WAN Destination |
|
|
Branch to Hub |
|
|
Branch to Branch VPN |
|
|
Branch to Non SD-WAN Destination |
|
|
Branch to Non SD-WAN Destination |
Branch to Non SD-WAN Destination via Gateway
- Connect to Customer Data Center with Existing Firewall VPN Router
- Iaas
- Connect to CWS (Zscaler)
Connect to Customer Data Center with Existing Firewall VPN Router
A VPN connection between the VeloCloud Gateway and the data center firewall (any VPN router) provides connectivity between branches (with Edges installed) and Non SD-WAN Destinations, resulting in ease of insertion, in other words, no customer Data Center installation is required.
The following figure shows a VPN configuration:

|
|
Primary tunnel |
|
|
Redundant tunnel |
|
|
Secondary VPN Gateway |
- Check Point
- Cisco ASA
- Cisco ISR
- Generic IKEv2 Router (Route Based VPN)
- Microsoft Azure Virtual Hub
- Palo Alto
- SonicWALL
- Zscaler
- Generic IKEv1 Router (Route Based VPN)
- Generic Firewall (Policy Based VPN)
Note: Arista supports both Generic Route-based and Policy-based Non SD-WAN Destination from Gateway.
For information on how to configure a Branch to Non SD-WAN Destination through Gateway see Configure Non SD-WAN Destinations via Gateway.
Iaas
When configuring with Amazon Web Services (AWS), use the Generic Firewall (Policy Based VPN) option in the Non SD-WAN Destination dialog box.
- Eliminates mesh
- Cost
- Performance
Arista Cloud VPN is simple to set up (global networks of Gateways eliminates mesh tunnel requirement to VPCs), has a centralized policy to control branch VPC access, assures performance, and secures connectivity as compared to traditional WAN to VPC.
For information about how to configure using Amazon Web Services (AWS), see Configure Amazon Web Services.
Connect to CWS (Zscaler)
Zscaler Web Security provides security, visibility, and control. Delivered in the cloud, Zscaler provides web security with features that include threat protection, real-time analytics, and forensics.
- Performance: Direct to Zscaler (Zscaler via Gateway)
- Managing proxy is complex: Allows simple click policy aware Zscaler
Branch to Hub
The Hub is an Edge deployed in Data Centers for branches to access Data Center resources. You must set up your Hub in the Orchestrator. The Orchestrator notifies all the Edges about the Hubs, and the Edges build secure overlay multi-path tunnel to the Hubs.
The following figure shows how both Active-Standby and Active-Active are supported.

Branch to Branch VPN
Branch to Branch VPN supports configurations for establishing a VPN connection between branches for improved performance and scalability.
- Cloud Gateways
- Hubs for VPN
The following figure shows Branch to Branch traffic flows for both Cloud Gateway and a Hub.

You can also activate Dynamic Branch to Branch VPN for both Cloud Gateways and Hubs.
You can access the 1-click Cloud VPN feature in the Orchestrator from in the Cloud VPN area.
Branch to Non SD-WAN Destination via Edge
- Generic IKEv2 Router (Route Based VPN)
- Generic IKEv1 Router (Route Based VPN)
For additional information, see Configure Non SD-WAN Destinations via Edge.
Configure Cloud VPN for Profiles
At the Profile level, Orchestrator allows you to configure Cloud Virtual Private Network (VPN). To initiate and respond to VPN connection requests, you must activate Cloud VPN.
- In the SD-WAN service of the Enterprise portal, go to .
- Go to VPN Services area and activate Cloud VPN by turning the toggle button to On.

To override these settings and to configure Cloud VPN for Edges, see Configure Cloud VPN and Tunnel Parameters for Edges.
For topology and use cases, see Cloud VPN Overview.
Configure a Tunnel Between a Branch and Hubs VPN
To establish a VPN connection between Branch and Hubs, follow the below steps:
Conditional Backhaul
Conditional Backhaul (CBH) is a feature designed for Hybrid SD-WAN branch deployments that have at least one Public and one Private link.
Use case 1: Public Internet Link Failure
Whenever there is a Public Internet link failure on a VeloCloud Edge, tunnels to VeloCloud Gateway, Cloud Security Service (CSS), and Direct breakout to Internet are not established. In this scenario, the Conditional Backhaul feature, if activated, makes use of the connectivity through Private links to designated Backhaul Hubs, giving the Edge the ability to failover Internet-bound traffic over Private overlays to the Hub and provides reachability to Internet destinations.
- Direct to Internet
- Internet via Gateway
- Cloud Security Service traffic
Under normal operations, the Public link is UP and Internet-bound traffic will flow normally either Direct or via Gateway as per the Business Policies configured.

When the Public Internet link goes DOWN, or the SD-WAN Overlay path goes to QUIET state (no packets received from Gateway after 7 heartbeats), the Internet-bound traffic is dynamically backhauled to the Hub.
- Direct from Hub
- Hub to Gateway and then breakout from the Gateway

When the Public Internet link comes back, CBH will attempt to move the traffic flows back to the Public link. To avoid an unstable link causing traffic to flap between the Public and Private links, CBH has a default 30 seconds holdoff timer. After the holdoff timer is reached, flows will be failed back to the Public Internet link.

Use case 2: Cloud Security Service (CSS) Link Failure
Whenever there is a CSS (Zscaler) link failure on an Edge, while the Public Internet is still up, tunnels to CSS are not established and it causes traffic to get black-holed. In this scenario, the Conditional Backhaul feature, if activated, will allow the business policy to perform conditional backhaul and route the traffic to the Hub.
The Policy-based Conditional Backhaul provides the Edge the ability to failover Internet-bound traffic that use CSS link based on the status of CSS tunnel, irrespective of the status of the public links.
- CSS tunnels on all the segment goes down in the VPN profile.
- While primary CSS tunnel goes down and if secondary CSS tunnel is configured then Internet traffic will not be conditional backhauled, instead traffic will go through the secondary CSS tunnel.

When the tunnels to CSS link come back, CBH will attempt to move the traffic flows back to the CSS and the traffic will not be Conditionally Backhauled.

Behavioral Characteristics of Conditional Backhaul
- When Conditional Backhaul is activated, by default all Business Policy rules at the branch level are subject to failover traffic through CBH. You can exclude traffic from Conditional Backhaul based on certain requirements for selected policies by deactivating this feature at the selected business policy level.
- Conditional Backhaul will not affect existing flows that are being backhauled to a Hub already if the Public link(s) goes down. The existing flows will still forward data using the same Hub.
- If a branch location has backup Public links, the backup Public link will take precedence over CBH. Only if the primary and backup links are all inoperable then the CBH gets triggered and uses the Private link.
- If a Private link is acting as backup, traffic will fail over to Private link using CBH feature when active Public link fails and Private backup link becomes Active.
- In order for the feature to work, both Branches and Conditional Backhaul Hubs need to have the same Private Network name assigned to their Private links. (The Private tunnel will not come up otherwise.)
Configuring Conditional Backhaul
- In the SD-WAN service of the Enterprise portal, go to .
- Select a profile or select the View link in the Device column. The Device settings page for the selected profile appears.
- From the Segment drop-down menu, select a profile segment to configure Conditional Backhaul. By default, Global Segment [Regular] is selected.
Note: The Conditional Backhaul feature is Segment-aware and therefore must be activated at each Segment where it is intended to work.
- Go to VPN Services area and activate Cloud VPN by turning the toggle button to On.
- Select the Enable Branch to Hubs check box.
- Select the Edit Hubs link. The Add Hubs window for the selected profile appears.
Figure 63. Add Hubs 
From Hubs area, select the Hubs to act as Backhaul Hubs and move them to Backhaul Hubs area by using the arrows.
- To activate Conditional Backhaul, select the Enable Conditional BackHaul check box.
With Conditional Backhaul activated, the Edge can failover:
- Internet-bound traffic (Direct Internet traffic, Internet via Gateway and Cloud Security Traffic via IPsec) to MPLS links whenever there is no Public Internet links available.
- Internet-bound CSS traffic to the Hub whenever there is a CSS (Zscaler) link failure on the Edge, while the Public Internet link is still up.
Conditional Backhaul, when activated will apply for all Business Policies by default. If you want to exclude traffic from Conditional Backhaul based on certain requirements, you can deactivate Conditional Backhaul for selected policies to exclude selected traffic (Direct, Multi-Path, and CSS) from this behavior by selecting the Turn off Conditional Backhaul check box in the Action area of the Configure Rule screen for the selected business policy. For additional information, see Configure Network Service for Business Policy Rule.
Figure 64. Add Rule
Note:- Conditional Backhaul and SD-WAN Reachability can work together in the same Edge. Both Conditional Backhaul and SD-WAN reachability support failover of Cloud-bound Gateway traffic to MPLS when Public Internet is down on the Edge. If Conditional Backhaul is activated and there is no path to Gateway and there is a path to hub via MPLS then both direct and Gateway bound traffic apply Conditional Backhaul. For additional information about SD-WAN reachability, see SD-WAN Service Reachability via MPLS.
- When there are multiple candidate hubs, Conditional Backhaul uses the first hub in the list unless the Hub has lost connectivity to Gateway.
- Select Save Changes.
Troubleshooting Conditional Backhaul
Consider a user with Business Policy rules created at the Branch level. You can check if the constant pings to each of these destination IP addresses are active for the Branch by running the List Active Flows command from the Remote Diagnostics section.
For additional information, see the Remote Diagnostic Tests on Edges section in the Arista VeloCloud SD-WAN Troubleshooting Guide.
Configure a Tunnel Between a Branch and a Branch VPN
Configure Branch to Branch VPN to establish a VPN connection between Branches.
Configure a Tunnel Between a Branch and a Non SD-WAN Destinations via Gateway
You can establish a VPN connection between a branch and a Non SD-WAN Destination through Gateway by activating Cloud VPN.
Configure a Tunnel Between a Branch and a Non SD-WAN Destinations via Edge
After configuring a Non SD-WAN Destination via Edge in Orchestrator, you have to associate the Non SD-WAN Destination to the desired Profile in order to establish the tunnels between Gateways and the Non SD-WAN Destination.
To establish a VPN connection between a Branch and a Non SD-WAN Destination configured via Edge, perform the following steps:
Configure Cloud Security Services for Profiles
Enable Cloud Security Service (CSS) to establish a secured tunnel from an Edge to cloud security service sites. This enables the secured traffic being redirected to third-party cloud security sites. At the Profile level, VeloCloud SD-WAN and Zscaler integration supports automation of IPsec and GRE tunnels.
- Ensure that you have access permission to configure network services.
- Ensure that your Orchestrator has version 3.3.x or above.
- You should have Cloud security service gateway endpoint IPs and FQDN credentials configured in the third party Cloud security service.
Configure Zscaler Settings for Profiles
This topic discusses how to configure Zscaler for Profiles. You can configure the Zscaler settings for a Profile from the Zscaler section available under the VPN Services category in the Device tab.
To configure Zscaler at the Profile level, perform the following steps:
Configure Multicast Settings for Profiles
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.
Multicast clients use the Internet Group Management Protocol (IGMP) to propagate membership information from hosts to Multicast activated routers and PIM to propagate group membership information to Multicast servers via Multicast routers.

- Multicast support on both overlay and underlay
- Protocol-Independent Multicast- Sparse Mode (PIM-SM) on Edge
- Internet Group Management Protocol (IGMP) version 2 on Edge
- Static Rendezvous Point (RP) configuration, where RP is activated on a 3rd party router.
You can activate and configure Multicast globally and at the interface-level. If required, you can override the Multicast configurations at the Edge-level.
To configure Multicast globally:
Configure DNS for Profiles
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.
To configure the DNS settings for a Profile:
Activate OSPF for Profiles
Open Shortest Path First (OSPF) can be enabled only on a LAN interface as an active or passive interface. The Edge will only advertise the prefix associated with that LAN switch port. To get full OSPF functionality, you must use it in routed interfaces.
- Support for OSPFv3 is introduced in the SD-WAN Edge for IPv6 underlay routing in addition to existing BGPv6 support. The following is supported:
- Underlay IPv6 route learning.
- Redistribution of OSPFv3 routes into overlay/BGP and vice-versa.
- Support for Overlay Flow Control (OFC).
- OSPFv3 is implemented with feature parity to OSPFv2 with the following exceptions:
- Point to Point (P2P) is not supported.
- BFDv6 with OSPFv3 is not supported.
- md5 authentication is not available, as OSPFv3 header does not support it.
To activate OSPF, perform the steps in the procedure below:
Route Filters
- Inbound Routing includes preferences that can be learned or ignored from OSPF and installed into the Overlay Flow Control.
- Outbound Routing indicates what prefixes can be redistributed into the OSPF.
Configure BFD for Profiles
VeloCloud SD-WAN allows to configure BFD sessions to detect route failures between two connected entities.
To configure a BFD session for Profiles:
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 Profile Level
LAN-Side Network Address Translation (NAT) Rules allow you to NAT IP addresses in an unadvertised subnet to IP addresses in an advertised subnet. For both the Profile and Edge levels, within the Device Settings configuration, LAN-side NAT Rules has been introduced for the 3.3.2 release and as an extension, LAN side NAT based on source and destination, same packet source and destination NAT support have been introduced for the 3.4 release.
- Branch overlapping IP due to M&A (Merger and Acquisitions)
- Hiding the private IP of a branch or data center for security reasons
- Source or Destination NAT for all matched subnets, both 1:1 and Many:1 are supported (3.3.2 release)
- Source NAT based on Destination subnet or Destination NAT based on Source subnet, both 1:1 and Many:1 are supported (3.4 release)
- Source NAT and Destination 1:1 NAT on the same packet (3.4 release)
- LAN-side NAT supports traffic over VCMP tunnel. It does not support underlay traffic.
- Support for "Many:1" and "1:1" (e.g. /24 to /24) Source and Destination NAT.
- If multiple rules are configured, only the first matched rule is executed.
- LAN-side NAT is done before route or flow lookup. To match traffic in the business profile, users must use the NATed IP.
- By default, NATed IP are not advertised from the Edge. Therefore, make sure to add the Static Route for the NATed IP and advertise to the Overlay.
- Configurations in 3.3.2 will be carried over, no need to reconfigure upon 3.4 upgrade.
To apply LAN-Side NAT Rules for a Profile, use the following steps:
Configure BGP from Edge to Underlay Neighbors for Profiles
You can configure the BGP per segment at the Profile level as well as at the Edge level. This section provides steps on how to configure BGP with Underlay Neighbors.
Arista supports 4-Byte ASN BGP. See Configure BGP, for additional information.
To configure BGP:
Configure Visibility Mode for Profiles
This section discusses how to configure Visibility mode at the Profile level.
Even though tracking by MAC Address is ideal (providing a global unique identifier), there’s a lack of visibility when an L3 switch is located between the client and the Edge because the switch MAC is known to the Edge, not the device MAC. Therefore, two tracking modes (MAC Address and now IP Address) are available. When tracking by MAC address is not possible, IP address will be used instead.
Remember the following considerations when choosing a Visibility mode:
- If Visibility by MAC address is selected:
- Clients are behind L2 SW
- Client MAC, IP and Hostname (if applicable) will appear
- Stats are collected based on MAC
- If Visibility by IP address is selected:
- Clients are behind L3 SW
- SW MAC, Client IP and Hostname (if applicable) will appear
- Stats are collected based on IP
To configure Visibility Mode, perform the following steps:
Configure SNMP Settings for Profiles
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.
Follow the below steps to download the Edge MIB:
Procedure to configure SNMP Settings at Profile Level
- Navigate to , and then select a Profile.
- Select the View link in the Firewall column.
- Go to Edge Access located under the Edge Security area.
- Configure SNMP Access and select Save Changes.
Configure Syslog Settings for Profiles
- Ensure that Cloud Virtual Private Network (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 the native Syslog format. For the Syslog collector to receive Orchestrator bound events and firewall logs from the configured edges in an Enterprise, at the profile level, configure Syslog collector details per segment in the Orchestrator by performing the steps on this procedure.
For additional information about Firewall settings at the profile level, see Configure Profile Firewall.
Secure Syslog Forwarding Support
The 5.0 release supports secure syslog forwarding capability. Ensuring security of syslog forwarding is required for federal certifications and is necessary to meet the Edge hardening requirements of large enterprises. The secure syslog forwarding process begins with having a TLS capable syslog server. Currently, the Orchestrator allows forwarding logs to a syslog server that has TLS support. The 5.0 release allows the Orchestrator to control the syslog forwarding and conducts default security checking such as hierarchical PKI verification, CRL validation, etc. Moreover, it also allows customizing the security of forwarding by defining supported cipher suites, not allowing self-signed certificates, etc.
Another aspect of secure syslog forwarding is how revocation information is collected or integrated. The Orchestrator can now allow revocation information input from an Operator that can be fetched manually or via an external process. The Orchestrator will pick up that CRL information and will use it to verify the security of forwarding before all connections are established. In addition, the Orchestrator fetches that CRL information regularly and uses it when validating the connection.
System Properties
Secure syslog forwarding begins with configuring the Orchestrator syslog forwarding parameters to allow it to connect with a syslog server. To do so, the Orchestrator accepts a JSON formatted string to accomplish the following configuration parameters, which is configured in System Properties.
log.syslog.backend: Backend service syslog integration configurationlog.syslog.portal: Portal service syslog integration configurationlog.syslog.upload: Upload service syslog integration configuration

When configuring system properties, the following Secure Syslog Configuration JSON string can be used.
- config <Object>
- enable: <true> <false> Activate or Deactivate Syslog forwarding. Please note that this parameter controls overall syslog forwarding even if secure forwarding is activated.
- options <Object>
- host: <string> The host running syslog, defaults to localhost.
- port: <number> The port on the host that syslog is running on, defaults to syslogd's default port.
- protocol: <string> tcp4, udp4, tls4. Note: (tls4 allows secure syslog forwarding with default settings. To configure it please see the following secure Options object
- pid: <number> PID of the process that log messages are coming from (Default process.pid).
- localhost: <string> Host to indicate that log messages are coming from (Default: localhost).
- app_name: <string> The name of the application (node-portal, node-backend, etc) (Default: process.title).
- secureOptions <Object>
- disableServerIdentityCheck: <boolean> Optionally skipping SAN check while validating, i.e. can be used if the server's certification does not have a SAN for self-signed certificates. Default false.
- fetchCRLEnabled: <boolean> If not false, Orchestrator fetches CRL information which is embedded into provided CAs. Default: true
- rejectUnauthorized: <boolean> If not false, the Orchestrator applies hierarchical PKI validation against the list of supplied CAs. Default: true. (This is mostly required for testing purposes. Please do not use it in production.)
- caCertificate: <string> Orchestrator can accept a string that contain PEM formatted certificates to optionally override the trusted CA certificates (can contain multiple CRLs in openssl friendly concatenated form). Default is to trust the well-known CAs curated by Mozilla. This option can be used for allowing to accept a local CA that is governed by the entity. For instance, for On-prem customers who have their own CAs and PKIs.
- crlPem:<string> Orchestrator can accept a string that contain PEM formatted CRLs (can contain multiple CRLs in openssl friendly concatenated form). This option can be used for allowing to accept a local kept CRLs. If fetchCRLEnabled is set true, the Orchestrator combines this information with fetched CRLs. This is mostly required for a specific scenario where certificates do not have CRLDistribution point information in it.
- crlDistributionPoints: <Array> The Orchestrator can optionally accept an array CRL distribution points URI in "http" protocol. The Orchestrator does not accept any "https" URI
- crlPollIntervalMinutes: <number> if fetchCRLEnabled is not set false, the Orchestrator polls CRLs every 12 hours. However, this parameter can optionally override this default behavior and update CRL according to provided number.
Configuring Secure Syslog Forwarding Example
{"enable": true,"options": {"appName": "node-portal","protocol": "tls","port": 8000,"host": "host.docker.internal","localhost": "localhost"},"secureOptions": {"caCertificate": "-----BEGIN CERTIFICATE-----MIID6TCCAtGgAwIBAgIUaauyk0AJ1ZK/U10OXl0GPGXxahQwDQYJKoZIhvcNAQELBQAwYDELMAkGA1UEBhMCVVMxCzAJBgNVBAgMAkNBMQ8wDQYDVQQHDAZ2bXdhcmUxDzANBgNVBAoMBnZtd2FyZTEPMA0GA1UECwwGdm13YXJlMREwDwYDVQQDDAhyb290Q2VydDAgFw0yMTA5MjgxOTMzMjVaGA8yMDczMTAwNTE5MzMyNVowYDELMAkGA1UEBhMCVVMxCzAJBgNVBAgMAkNBMQ8wDQYDVQQHDAZ2bXdhcmUxDzANBgNVBAoMBnZtd2FyZTEPMA0GA1UECwwGdm13YXJlMREwDwYDVQQDDAhyb290Q2VydDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwG+Xyp5wnoTDxpRRUmE63DUnaJcAIMVABm0xKoBEbOKoW0rnl3nFu3l0u6FZzfq+HBJwnOtrBO0lf/sges2/QeUduCeBC/bqs5VzIRQdNaFXVtundWU+7Tn0ZDKXv4aRC0vsvjejU0H7DCXLg4yGF4KbM6f0gVBgj4iFyIjcy4+aMsvYufDV518RRB3MIHuLdyQXIe253fVSBHA5NCn9NGEF1e6Nxt3hbzy3Xe4TwGDQfpXx7sRt9tNbnxemJ8A2ou8XzxHPc44G4O0eN/DGIwkP1GZpKcihFFMMxMlzAvotNqE25gxN/O04/JP7jfQDhqKrLKwmnAmgH9SqvV0F8CAwEAAaOBmDCBlTAdBgNVHQ4EFgQUSpavxf80w/I3bdLzubsFZnwzpcMwHwYDVR0jBBgwFoAUSpavxf80w/I3bdLzubsFZnwzpcMwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAYYwMgYDVR0fBCswKTAnoCWgI4YhaHR0cDovL2xvY2FsaG9zdDo1NDgzL2NybFJvb3QucGVtMA0GCSqGSIb3DQEBCwUAA4IBAQBrYkmg+4x2FrC4W8eU0S62DVrsCtA26wKTVDtor8QAvi2sPGKNlv1nu3F2AOTBXIY+9QV/Zvg9oKunRy917BEVx8sBuwrHW9IvbThVk+NtT/5fxFQwCjO9l7/DiEkCRTsrY4WEy8AW1CcaBwEscFXXgliwWLYMpkFxsNBTrUIUfpIR0Wiogdtc+ccYWDSSPomWZHUmgumWIikLue9/sOvV9eWy56fZnQNBrOf5wUs0suJyLhi0hhFOAMdEJuL4WnYthX5d+ifNon8ylXGO6cOzXoA0DlvSmAS+NOEekFo6R1Arrws0/nk6otGH/Be5+/WXFmp0nzT5cwnspbpA1seO-----END CERTIFICATE-----","disableServerIdentityCheck": true,"fetchCRLEnabled":true,"rejectUnauthorized": true,"crlDistributionPoints":
http://cacerts.digicert.com/DigiCertTLSHybridECCSHA3842020CA1-1.crtTo configure syslog forwarding, see the following JSON object as an example (image below).

If the configuration is successful, the Orchestrator produces the following log and begins forwarding.
[portal:watch] 2021-10-19T20:08:47.150Z - info: [process.logger.163467409.0] [660] Remote Log has been successfully configured for the following options {"appName":"node-portal","protocol":"tls","port":8000,"host":"host.docker.internal","localhost":"localhost"}
Secure Syslog Forwarding in FIPS Mode
When FIPS mode is activated for secure syslog forwarding, the connection will be rejected if the syslog server does not offer the following cipher suites: "TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256." Also, independent from FIPS mode, if the syslog server certificate does not have an extended key usage field that sets "ServerAuth" attribute, the connection will be rejected.
Constant CRL Information Fetching
If fetchCRLEnabled is not set to false, the Orchestrator regularly updates the CRL information every 12 hours via the backend job mechanism. The fetched CRL information is stored in the corresponding system property titled, log.syslog.lastFetchedCRL.{serverName}. This CRL information is going to be checked in every connection attempt to the syslog server. If an error occurs during the fetching, the Orchestrator generates an Operator event.
fetchCRLEnabled is set to true, there will be three additional system properties to follow the status of the CRL, as follows: log.syslog.lastFetchedCRL.backend, log.syslog.lastFetchedCRL.portal, log.syslog.lastFetchedCRL.upload, as shown in the image below. This information will display the last update time of the CRL and CRL information.

Logging
If the option fetchCRLEnabled is set true, the Orchestrator will try to fetch CRLs. If an error occurs, the Orchestrator raises an event and displays in the Operator Events page.
Syslog Message Format for Firewall Logs
Describes the Syslog message format for Firewall logs with an example.
<%PRI%>%timegenerated% %HOSTNAME% %syslogtag%%msg
The following is a sample syslog message.
<158>Dec 17 07:21:16 b1-edge1 velocloud.sdwan: ACTION=VCF Deny SEGMENT=0 IN="IFNAME" PROTO=ICMP SRC=x.x.x.x DST=x.x.x.x TYPE=8 FW_POLICY_NAME=test SEGMENT_NAME=Global Segment
- Priority- Facility * 8 + Severity (local3 & info)- 158
- Date- Dec 17
- Time- 07:21:16
- Host Name- b1-edge1
- Syslog Tag- velocloud.sdwan
- Message- ACTION=VCF Deny SEGMENT=0 IN="IFNAME" PROTO=ICMP SRC=x.x.x.x DST=x.x.x.x TYPE=8 FW_POLICY_NAME=test SEGMENT_NAME=Global Segment
- With Stateful Firewall enabled:
- Open- The traffic flow session has started.
- Close- The traffic flow session has ended due to session timeout or the session is flushed through the Orchestrator.
- Deny- If the session matches the Deny rule, the Deny log message will appear and the packet will be dropped. In the case TCP, Reset will be sent to the Source.
- Update- For all the ongoing sessions, the Update log message will appear if the firewall rule is either added or modified through Orchestrator.
- With Stateful Firewall deactivated:
- Allow
- Deny
| Option | Description |
|---|---|
| SID | The unique identification number applied to each session. |
| SVLAN | The VLAN ID of the Source device. |
| DVLAN | The VLAN ID of the Destination device. |
| IN | The name of the interface on which the first packet of the session was received. In the case of overlay received packets, this field will contain VPN. For any other packets (received through underlay), this field will display the name of the interface in the edge. |
| PROTO | The type of IP protocol used by the session. The possible values are TCP, UDP, GRE, ESP, and ICMP. |
| SRC | The source IP address of the session in dotted decimal notation. |
| DST | The destination IP address of the session in dotted decimal notation. |
| Type | The type of ICMP message.
Note: The Type parameter appears in logs only for ICMP packets.
Some important ICMP types which are widely used include:
For complete list of ICMP message types, see ICMP Parameters Types. |
| SPT | The source port number of the session. This field is applicable only if the underlaying transport is UDP/TCP. |
| DPT | The destination port number of the session. This field is applicable only if the underlaying transport is UDP/TCP. |
| FW_POLICY_NAME | The name of the firewall policy applied to the session. |
| SEGMENT_NAME | The name of the segment to which the session belongs to. |
| DEST_NAME | The name of the remote-end device of the session. The possible values are:
|
| NAT_SRC | The source IP address used for source netting the direct Internet traffic. |
| NAT_SPT | The source port used for patting the direct Internet traffic. |
| APPLICATION | The Application name to which the session was classified by DPI Engine. This field is available only for Close log messages. |
| BYTES_SENT | The amount of data sent in bytes in the session. This field is available only for Close log messages. |
| BYTES_RECEIVED | The amount of data received in bytes in the session. This field is available only for Close log messages. |
| DURATION_SECS | The duration for which the session has been active. This field is available only for Close log messages. |
| REASON | The reason for closure or denial of the session. The possible values are:
|
Configure Netflow Settings for Profiles
As an Enterprise Administrator, you can configure Netflow settings at the Profile level.
To configure the Netflow settings for a Profile:
Configure Authentication Settings for Profiles
The Device Authentication Settings allows you to select a Radius server to authenticate a user. To configure the Authentication settings for a Profile:
Configure NTP Settings for Profiles
The Network Time Protocol (NTP) provides the mechanisms to synchronize time and coordinate time distribution in a large, diverse network. Arista recommends using NTP to synchronize the system clocks of Edges and other network devices.
- 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.
As an Enterprise user, you can configure a time source for the Edge to set its own time accurately by configuring a set of upstream NTP Servers to get its time. The Edge attempts to set its time from a default set of public NTP Servers, but the time set is not reliable in most secure networks. In order to ensure that the time is set correctly on an Edge, you must activate the Private NTP Servers feature and then configure a set of NTP Servers. Once the Edge's own time source is properly configured, you can configure the Edge to act as an NTP Server to its own clients.

















































