Configure Device Settings for Profiles

This section discusses how to configure a profile device.

Note: If you are logged in using a user ID with Customer Support privileges, you will only be able to view VeloCloud Orchestrator objects. You will not be able to create new objects or configure/update existing ones.

In the SD-WAN service of the Enterprise portal, you can perform various configuration settings for a Profile by navigating to the Configure > Profiles > Device 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.

In the SD-WAN service of the Enterprise portal, select Configure > Profiles and select a Profile. The configuration options for the selected Profile are displayed on the Device tab.

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 screenshot.

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.

Figure 2. Device Configurations Sorted by Category

Note: On the Device page, whenever you make configuration changes for the selected Profile, an action bar appears at the bottom of the screen. You can select the notification to view the recent configuration changes and save the changes made to the Profile.

Profile Device Configurations—A Roadmap

The following table provides the list of Profile-level configurations:

Table 1. Connectivity
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 Profiles.
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.
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 VeloCloud 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.

Table 2. VPN Services
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: Branch to Hub VPN Branch to Branch VPN Edge to Non SD-WAN via Gateway 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.

Table 3. Routing & NAT
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.

Table 4. Telemetry
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 VeloCloud 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.

Table 5. Edge Services
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:

In the SD-WAN service of the Enterprise portal, go to Configure > Profiles . 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 for which you want to assign segments. 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.
From the Segment drop-down menu, select the Change Profile Segments link. The Change Profile Segments dialog box appears.

Figure 3. Assign Segments for Profile
In this dialog box, you can select the Segments that you want to include in your profile. Segments with a lock symbol next to them indicate that the Segment is in use within a profile, and it cannot be removed. Segments available for use will be displayed under All Segments.
Select Update Segments and then select Save Changes.

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 that Segment display in the Segments area.

Figure 4. View Segment Configuration

Configure VLAN for Profiles

As an Enterprise Administrator, you can configure VLANs in a Profile.

To configure VLAN settings in a Profile:

In the SD-WAN service of the Enterprise portal, go to Configure > 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.
Scroll down to the Connectivity category and select VLAN.

Figure 5. Configure VLAN for Profiles
You can add a new VLAN by selecting + Add VLAN. You can delete a selected VLAN by selecting the Delete.

Note: A VLAN that has been already assigned to a device interface, cannot be deleted.
Select IPv4 or IPv6 button to display the respective list of VLANs.
Selecting + Add VLAN displays the following screen:

Figure 6. Add VLAN

In the Add VLAN window, configure the following VLAN details:

Table 6. VLAN Option Descriptions
Option	Description
General Settings
Segment	Select a segment from the drop-down list. The VLAN belongs to the selected segment.
VLAN Name	Enter a unique name for the VLAN.
VLAN ID	Enter the VLAN ID.
Description	Enter a description. This field is optional.
LAN Interfaces	You can configure the LAN Interfaces only at the Edge level.
SSID	You can configure the Wi-Fi SSID details for the VLAN only at the Edge level.
ICMP Echo Response	Select the check box to allow the VLAN to respond to ICMP echo messages.
DNS Proxy	This check box is selected by default. This option allows you to activate or deactivate a DNS Proxy, irrespective of the IPv4 or IPv6 DHCP Server settings.
IPv4 and IPv6 Settings Note: You can activate either IPv4 or IPv6 or both settings.
Assign Overlapping Subnets	Select the check box if you want to assign the same subnet for the VLAN to every Edge in the Profile and define the subnet in the Edge LAN IP Address. If you want to assign different subnets to every Edge, do not select the check box and configure the subnets on each Edge individually. Note: Overlapping subnets for the VLAN are supported only for SD-WAN to SD-WAN traffic (provided LAN side NAT is activated) and SD-WAN to Internet traffic. Overlapping subnets are not supported for SD-WAN to Cloud Web Security traffic.
Edge LAN IPv4/IPv6 Address	This option is available only if Assign Overlapping Subnets is set to Yes. Enter the LAN IPv4/IPv6 address of the Edge.
Cidr Prefix / Prefix Length	This option is available only if Assign Overlapping Subnets is set to Yes. Enter the CIDR prefix for the LAN IPv4/IPv6 address.
Network	Enter the IPv4/IPv6 address of the Network.
OSPF	This option is activated only when you have configured OSPF for the Edge. Select the check box and choose an OSPF from the drop-down list. Note: The OSPFv2 configuration supports only IPv4. The OSPFv3 configuration supports only IPv6, which is only available in the 5.2 release. For additional information on OSPF settings and OSPFv3, see Activate OSPF for Profiles.
Multicast	This option is activated only when you have configured multicast settings for the Edge. You can configure the following multicast settings for the VLAN. IGMP PIM Select toggle advanced multicast settings to set the following timers: PIM Hello Timer IGMP Host Query Interval IGMP Max Query Response Value Note: This option is available only under IPv4 Settings.
VNF Insertion	Select the check box to insert a VNF to the VLAN, which redirects traffic from the VLAN to the VNF. To activate VNF Insertion, ensure that the selected segment is mapped with a service VLAN. For additional information about VNF, see Security Virtual Network Functions. Note: This option is available only under IPv4 Settings.
Advertise	Select the check box to advertise the VLAN to other branches in the network.
Fixed IPs	You can configure the fixed IP only at the Edge level.

IPv4/IPv6 DHCP Server:

The available options for IPv4 DHCP Server are Activated, Relay, and Deactivated.
The available options for IPv6 DHCP Server are Activated and Deactivated.

Table 7. IPv4/IPv6 DHCP Server Option Descriptions
Option	Description
Activated: Activates the DHCP with the Edge as the DHCP server. Following configuration options are available for this type.
DHCP Start	Enter a valid IPv4/IPv6 address available within the subnet.
Num. Addresses	Enter the number of IPv4/IPv6 addresses available on a subnet in the DHCP Server.
Lease Time	Select the period of time from the drop-down list. This is the duration the VLAN is allowed to use an IPv4/IPv6 address dynamically assigned by the DHCP Server.
Options	Select Add and select pre-defined or custom DHCP options from the drop-down list. The DHCP option is a network service passed to the clients from the DHCP server. For a custom option, enter the Code, Data Type, and Value. Select Delete to delete a selected option.
Relay: Activates the DHCP with the DHCP Relay Agent installed at a remote location. Following configuration options are available for this type.
Source from Secondary IP(s)	When you select this check box, the DHCP discover/request packets from the client are relayed to the DHCP Relay servers sourced from the primary IP address and all the secondary IP addresses configured for the VLAN. The reply from the DHCP Relay servers is sent back to the client after rewriting the source and destination. The DHCP server receives the request from both the primary and secondary IP addresses and the DHCP client can get multiple offers from primary subnet and secondary subnets. When this option is not selected, the DHCP discover/request packets from the client are relayed to the DHCP Relay servers sourced only from the primary IP address.
Relay Agent IP(s)	Select Add to add IPv4 addresses. Select Delete to delete a selected address.
Deactivated: Deactivates the DHCP.

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.

Select Done. On the Device settings screen, select Save Changes to save the settings.

The VLAN is configured for the Profile. You can edit the VLAN settings by selecting the link under the VLAN column.

To configure VLANs for Edges, see Configure VLAN for Edges.

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.

You can configure loopback interfaces only for SD-WAN Edges that are running on version 4.3 and above. The Configure Loopback Interfaces area is not available for SD-WAN Edges that are running on version 4.2 or lower. For such Edges, you must configure Management IP address at the Profile level.

Figure 7. Configure Management IP Address for Profiles

The Loopback Interface configurations can be done only at the Edge level. For additional information about Loopback Interfaces and limitations, see Loopback Interfaces Configuration.

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:

In the SD-WAN service of the Enterprise portal, go to Configure > Profiles . The Configuration Profiles page appears.
Select the link to a Profile for which you want to override ARP timeouts or select the View link in the Device column of the Profile. The Device tab displays the configuration options for the selected Profile.
Under the Connectivity category, select ARP Timeouts.
To override the default ARP timeouts, select the Override default ARP Timeouts check box.

Figure 8. Override Default ARP Timeouts

Configure the various ARP timeouts in hours and minutes as follows:

ARP Stale Timeout must be less than ARP Dead Timeout. ARP Dead Timeout must be less than ARP Cleanup Timeout.

Table 8. Address Resolution Protocol Timeouts Field Descriptions
Field	Description
ARP Stale Timeout	When an ARP’s age exceeds the Stale time, its state changes from ALIVE to REFRESH. At the REFRESH state, when a new packet tries to use this ARP entry, the packet will be forwarded and also a new ARP request will be sent. If the ARP gets resolved, the ARP entry will be moved to the ALIVE state. Otherwise the entry will remain in the REFRESH state and the traffic will be forwarded in this state. The allowable value ranges from 1 minute to 23 hours and 58 minutes.
ARP Dead Timeout	When an ARP’s age exceeds the Dead time, its state changes from REFRESH to DEAD. At the DEAD state, when a new packet tries to use this ARP entry, the packet will be dropped and also an ARP request will be sent. If the ARP gets resolved, the ARP entry will be moved to ALIVE state and the next data packet will be forwarded. If the ARP is not resolved, the ARP entry will remain in the DEAD state. In the DEAD state, traffic will not be forwarded to that port and will be lost. The allowable value ranges from 2 minutes to 23 hours and 59 minutes.
ARP Cleanup Timeout	When an ARP’s age exceeds the Cleanup time, the entry will be completely removed from ARP table. The allowable value ranges from 3 minutes to 24 hours.

Note: The ARP timeout values can only be in increasing order of minutes.

Select Save Changes.

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

Configure Interface Settings allows you 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 VeloCloud Orchestrator. This auto-discovered WAN link can then be modified via the VeloCloud Orchestrator and the new configuration pushed back to the branch.

Note:

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.

If the link should not or cannot be auto-discovered, it must be explicitly configured. There are multiple supported configurations in which auto-discovery will not be possible, including:

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.

Note: Even for auto-discovered links, overriding the parameters that are automatically detected – such as service provider and bandwidth – can be overridden by the Edge configuration.

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 SD-WAN 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 SD-WAN Gateway will use 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 Configure > Profiles/Edges > Connectivity > Interfaces . The following screen illustrates the various Edge models and the Interface Settings that can be configured for the supported SD-WAN 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.

Table 9. Configure Interface Settings
Your Edge Models	Select the Edge model for which you want to configure Interface settings from the drop-down menu. The selected Edge models appears in the Interfaces section. Select and expand the Edge model to configure the interface settings.
General	Interface- The name of the interface. This name matches the Edge port label on the Edge device or is predetermined for wireless LANs. You can select the Interface name link to modify the Interface and Layer 2 (L2) settings. For additional details, see Configure Interface Settings for Profiles. Type- The type of interface. Either Switched or Routed. VNF Insertion- Displays if the VNF insertion is turned on or OFF for the interface. Segments- Displays the Segment for which the configuration settings are applicable.
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: IGMP- Only Internet Group Management Protocol IGMP v2 is supported. PIM – Only Protocol Independent Multicast Sparse Mode (PIM-SM) is supported.
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.

Edges Without Wi-Fi Modules

Arista VeloCloud supports Edge models 510, 610, 620, 640, and 680 without Wi-Fi modules for the following releases: 3.4.6, 4.2.2, 4.3.0, 4.3.1, 4.5.0 or newer. For specific model names, see theModel Names: Edges Without Wi-Fi Modules table below the image. The Edge 6X0 series device and 510 Edge device are shipped with default images, but the working image is typically downloaded from the VeloCloud Orchestrator upon activation.

Table 10. Edges Without Wi-Fi Modules
Marketing Name	Hardware Model	Hardware Part Number
Edge 510N	Edge 510	Edge 510-NW
Edge 610N	E42W	Edge 610N
Edge 620N	E42W	Edge 620N
Edge 640N	E42W	Edge 640N
Edge 680N	E42W	Edge 680N

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.

Note: Only one SIM will be active on the 610-LTE Edge even if both SIMs are inserted in the Edge.

With the Edge 610-LTE device, new routed interfaces (CELL1 and CELL 2) are configurable. For additional information, see Configure Interface Settings for Profiles.

Figure 11. Edge 610-LTE Interface Configuration

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 VeloCloud 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 VeloCloud Orchestrator will display 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 12. Edge 610-LTE Modem

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 6X0

Edge models supported are 610, 620, 640, and 680 devices.

Note: For information on how to Configure DSL Settings, see Configure DSL Settings.

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 Profiles.

Note: 510-LTE Modern Information Diagnostic Test: When Edge 510- LTE device is configured, the LTE Modem Information diagnostic test is available. The LTE Modern Information diagnostic test will retrieve diagnostic information, such as signal strength, connection information, etc. For additional information, see Arista VeloCloud SD-WAN Troubleshooting Guide.

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 SD-WAN 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 13. Two WAN Links Connected to an L2 Switch

In this topology, the Arista 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:

Figure 14. Final Configuration of Use Case 1

The following paragraph describes how the final configuration is defined.
- The interface is defined with IP address 10.0.0.1 and next hop 10.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.1 and next hop of 10.0.0.2. No changes are required. When a packet needs to be sent out the cable link, it is sourced from 10.0.0.1 and forwarded to the device that responds to ARP for 10.0.0.2 (FW1). Return packets are destined for 10.0.0.1 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 virtual IP (e.g. 10.0.0.4) for the source IP and 10.0.0.3 for the next hop. When a packet needs to be sent out the DSL link, it is sourced from 10.0.0.4 and forwarded to the device that responds to the ARP for 10.0.0.3 (FW2). Return packets are destined for 10.0.0.4 and identified as having arrived on the DSL link.
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 SD-WAN Edge.

Figure 15. 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 16. Steering by IP

The following discusses how the final configuration is defined.
- The interface is defined with IP address 10.0.0.1 and next hop 10.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.1 and next hop of 10.0.0.2. No changes are required. When a packet needs to be sent out the cable link, it is sourced from 10.0.0.1 and forwarded to the device that responds to ARP for 10.0.0.2 (L3 Switch). Return packets are destined for 10.0.0.1 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 virtual IP (for example, 10.0.0.3) for the source IP and the same 10.0.0.2 for the next hop. When a packet needs to be sent out the DSL link, it is sourced from 10.0.0.3 and forwarded to the device that responds to the ARP for 10.0.0.2 (L3 Switch). Return packets are destined for 10.0.0.3 and 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.

Steering by VLAN
- The interface is defined with IP address 10.100.0.1 and next hop 10.100.0.2 on 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.1 and next hop of 10.100.0.2. No changes are required. When a packet needs to be sent out the cable link, it is sourced from 10.100.0.1, tagged with VLAN 100 and forwarded to the device that responds to ARP for 10.100.0.2 on VLAN 100 (L3 Switch). Return packets are destined for 10.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 the 10.200.0.2 for the next hop. When a packet needs to be sent out the DSL link, it is sourced from 10.200.0.1, tagged with VLAN 200 and forwarded to the device that responds to the ARP for 10.200.0.2 on VLAN 200 (L3 Switch). Return packets are destined for 10.200.0.1/VLAN 200 and identified as having arrived on the DSL link.
Use Case 3: One-arm Deployments: One-arm deployments end up being very similar to other L3 deployments.

Figure 17. One-Arm Deployments

Again, the SD-WAN 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 in the Arista 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 18. One WAN Link Reachable Over Multiple Interfaces
- GE1 is defined with IP address 10.10.0.1 and next hop 10.10.0.2.
- GE2 is defined with IP address 10.20.0.1 and next hop 10.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 for 169.254.0.2 on the configured VLAN (CE Router). Return packets are destined for 169.254.0.1 and 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.

Configure Interface Settings for Profiles

In a Profile, you can configure Interface settings for various Edge models.

You can configure the Interface settings for each Edge model. Each Interface on an Edge can be a Switch Port (LAN) or a Routed (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 Configure > Profiles .
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 19. Configure Interface Settings for Profiles
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 20. 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.

Table 11. Routed Interface- Options and Descriptions
Option	Description
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 Subinterfaces. Note: 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 with New Orchestrator UI. Note: 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 for the Profile. Select the check box and choose an OSPF from the drop-down list. Select toggle advance ospf settings to configure the Interface settings for the selected OSPF. Note: OSPF is not supported on Subinterfaces, and it is not supported on non 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. For additional information on OSPF settings and OSPFv3, see Activate OSPF for Profiles.
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 sub-interfaces, 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 subinterfaces 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 subinterfaces 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 subinterfaces 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 with New Orchestrator UI.
OSFP	This option is available only when you have configured OSPF for the Profile. Select the check box and choose an OSPF from the drop-down list. Select toggle advance ospf settings to configure the Interface settings for the selected OSPF. Note: OSPF is not supported on Subinterfaces, and it is not supported on non Global Segments. The OSPFv2 configuration supports only IPv4. The OSPFv3 configuration supports only IPv6. Note: OSFPv3 is only available in the 5.2 release. For additional information on OSPF settings and OSPFv3, see Activate OSPF for Profiles.
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 subinterfaces 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 subinterfaces 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 subinterfaces 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’
```

Configure the settings for a Switched Interface. See the table below for a description of these configuration settings.

Table 12. Switched Interface- Options and 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 the Interface for which you want to add a Subinterface.
- Enter the Subinterface ID and select Next.
- In the Subinterface window, configure the Interface settings.
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.

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 23. Add Wi-Fi SSID Interface Settings

Configure the following WLAN Interface settings:

Table 13. 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.

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.

Note: Configuring DSL is only available for the 610, 610-LTE, 620, 640, and 680 devices.

Configuring SFP

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 Configure > Profiles/Edges > Device > Connectivity > Interfaces 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:

In the SD-WAN service of the Enterprise portal, navigate to the Configure > Profiles > Device > Connectivity > Interfaces page.
Select and expand an Edge model (for example SD-WAN Edge 610) for which you want to configure the SFP DSL interface settings.
Under the Interface column, select the SFP interface link (for example SFP1) that you want to configure.
The Interface SFP1 dialog for the selected SD-WAN Edge device is displayed.
Note: The following steps describe only the SFP configuration. For a description of the other fields in the selected SD-WAN Edge device, see Configure Interface Settings for Profiles.
To configure DSL settings in the Interface SFP1 dialog, scroll down to the SFP Settings area.

Figure 26. SFP Interface Settings
From the SFP Module drop-down menu, choose DSL.

Figure 27. DSL Settings

In the DSL Settings area, configure the following:

Table 14. DSL Settings- Options and Descriptions
Option	Description
SFP Module	Three SFP modules are available: Standard, GPON, and DSL By default, Standard is selected. You can select DSL as the module to use the SFP port with higher bandwidth services.
DSL Settings	The option to configure Digital Subscriber Line (DSL) settings is available when you select the SFP module as DSL.
DSL Mode: VDSL2	This option is selected by default. Very-high-bit-rate digital subscriber line (VDSL) technology provides faster data transmission. The VDSL lines connect service provider networks and customer sites to provide high bandwidth applications over a single connection. When you choose VDSL2, select the Profile from the drop-down list. Profile is a list of pre-configured VDSL2 settings. The following profiles are supported: 17a and 30a.
DSL Mode: ADSL2/2+	Asymmetric digital subscriber line (ADSL) technology is part of the xDSL family and is used to transport high-bandwidth data. ADSL2 improves the data rate and reach performance, diagnostics, standby mode, and interoperability of ADSL modems. ADSL2+ doubles the possible downstream data bandwidth. If you choose ADSL2/2+, configure the following settings: PVC – A permanent virtual circuit (PVC) is a software-defined logical connection in a network such as a frame relay network. Choose a PVC number from the drop-down list. The range is from 0 to 7. VPI – Virtual Path Identifier (VPI) is used to identify the path to route the packet of information. Enter the VPI number, ranging from 0 to 255. VCI – Virtual Channel Identifier (VCI) defines the fixed channel on which the packet of information should be sent. Enter the VCI number, ranging from 35 to 65535. PVC VLAN – Set up a VLAN to run over PVCs on the ATM module. Enter the VLAN ID, ranging from 1 to 4094. VLAN TX – Upstream VLAN tagging ID. Supported values are 1-4094. VLAN RX – Downstream VLAN tagging ID, supported values are 1-4094. VLAN TX OP – Operation to perform the upstream PVC VLAN. Supported values are 0-2. VLAN RX OP – Operation to perform for the downstream PVC VLAN, supported values are 0-2.

Select Save to save the configuration.

At the Edge level, you can override the SFP interface settings for the SD-WAN Edge 610 or the SD-WAN Edge 610-LTE device by navigating to the Configure > Edges > Device > Connectivity > Interfaces page.

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

GPON supports the following functions to meet the requirements of broadband services:

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 Configure > > Profiles/Edges > Device > Connectivity > Interfaces 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:

In the SD-WAN service of the Enterprise portal, go to Configure > Profiles > Device > Connectivity > Interfaces .
Select and expand an Edge model (for example SD-WAN Edge 610) for which you want to configure the SFP GPON interface settings.
Under the Interface column, select the SFP interface link (for example SFP1) that you want to configure.
The Interface SFP1 dialog for the selected SD-WAN Edge device is displayed.
Note: The following steps describe only the SFP configuration. For a description of the other fields in the selected SD-WAN Edge device, see Configure Interface Settings for Profiles.
To configure GPON settings in the Interface SFP1 dialog, scroll down to the SFP Settings area.

Figure 29. SFP Interface Settings
From the SFP Module drop-down menu, choose GPON.

Figure 30. GPON settings
In the GPON Settings area, configure the following:
- Subscriber Location ID Mode- Enter the Subscriber Location ID Mode. The Subscriber Location ID can be up to 10 ASCII characters or up to 20 Hex Numbers. The ASCII Subscriber Location ID mode will allow up to 10 ASCII characters. The HEX Subscriber Location ID mode will allow up to 20 Hexadecimal characters.
- Subscriber Location ID- Enter the Subscriber Location ID.
Select Save to save the configuration.
At the Edge level, you can override the SFP interface settings for the SD-WAN Edge 610 or the SD-WAN Edge 610-LTE device by navigating to the Configure > Edges > Device > Connectivity > Interfaces page.

Troubleshooting GPON Settings

The GPON diagnostic test is available only for 6X0 devices. For additional information, see the Arista VeloCloud SD-WAN Troubleshooting Guide.

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.

Note: It is recommended not to include IPv4-only Gateway into a Gateway Pool with dual stack Gateways.

Dual Stack Environment

When all the Edges and Gateways are on dual stack, the tunnel preference is selected as follows:

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.

For Edge to Edge connections, the preference is chosen as follows:

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.

Note: When both the ends are on dual stack, with IPv4 as the preference and the overlay established with IPv4, the IPv6 overlay will not be established.

Figure 33. VCMP Tunnel Setup in Dual Stack Environment

In the above Illustration, all the Edges are on dual stack with the following preferences:

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 more information, see Configure Edge WAN Overlay Settings with New Orchestrator UI.

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.

Note: Hubs always receive IPv6 remote routes, irrespective of their IPv6 Capability.

Limitations of IPv6 Address Configuration

SD-WAN 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 SD-WAN 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 Monitor > Events 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.
SD-WAN 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.

Table 15. IP Family vs MGD Matrix
	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.
1. Interface on which WAN overlay is deactivated is not considered.
2. When Interface is single stack with IPv6 and traffic is IPv4, then it is not considered.
3. 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.
1. If WAN link is Standby, then it is not considered.
2. If WAN link is Private, then it is not considered.

You can configure IPv6 addresses for the following:

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:

In the SD-WAN service of the Enterprise portal, select Configure > Profiles .
Select the link to a Profile or select the View link in the Device column of the Profile. The configuration options for the selected Profile are displayed in the Device tab.
Under the Connectivity category, select Global IPv6.

Figure 34. Configure Global IPv6 Settings for Profiles

You can activate or deactivate the following settings, by using the toggle button. By default, all the options are deactivated.

Table 16. Global IPv6 Settings Field Descriptions
Option	Description
All IPv6 Traffic	Allows all IPv6 traffic in the network. Note: By default, this option is activated.
Routing Header Type 0 Packets	Allows Routing Header type 0 packets. Deactivate this option to prevent potential DoS attack that exploits IPv6 Routing Header type 0 packets.
Enforce Extension Header Validation	Allows to check the validity of IPv6 extension headers.
Enforce Extension Header Order Check	Allows to check the order of IPv6 Extension Headers.
Drop & Log Packets for RFC Reserved Fields	Allows to reject and log network packets if the source or destination address of the network packet is defined as an IP address reserved for future definition.
ICMPv6 Destination Unreachable messages	Generates messages for packets that are not reachable to IPv6 ICMP destination.
ICMPv6 Time Exceeded Message	Generates messages when a packet sent by IPv6 ICMP has been discarded as it was out of time.
ICMPv6 Parameter Problem Message	Generates messages when the device finds problem with a parameter in ICMP IPv6 header.

By default, the configurations are applied to all the Edges associated with the Profile. If required, you can modify the settings for each Edge by selecting the Override option in the Configure > Edges > {Edge Name} > Device > Connectivity > Global IPv6 page.

Monitor IPv6 Events

You can view the events related to the IPv6 configuration settings.

In the SD-WAN service of the Enterprise portal, select Monitor > Events .
To view the events related to IPv6 configuration, you can use the filter option. Select the Filter icon next to the Search option and choose to filter the details by different categories.

Figure 35. Monitor IPv6 Events

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:

In the SD-WAN service of the Enterprise portal, select Diagnostics > Remote Diagnostics .
The Remote Diagnostics page displays all the active Edges.
Select the Edge that you want to troubleshoot. The Edge enters live mode and displays all the possible Remote Diagnostics tests than you can run on the Edge.
For troubleshooting IPv6, scroll to the following sections and run the tests:
- IPv6 Clear ND Cache – Run this test to clear the cache from the ND for the selected Interface.
- IPv6 ND Table Dump – Run this test to view the IPv6 address details of Neighbor Discovery (ND) table.
- IPv6 RA Table Dump – Run this test to view the details of the IPv6 RA table.
- IPv6 Route Table Dump – Run this test to view the contents of the IPv6 Route Table.
- Ping IPv6 Test – Choose a Segment from the drop-down, enter the source Interface and the destination IPv6 address. select Run to ping the specified destination from the source Interface and the results of the ping test are displayed.
For additional information on Remote Diagnostics, see the "Remote Diagnostic Tests on Edges" section in the Arista VeloCloud SD-WAN Troubleshooting Guide.

Configure Wi-Fi Radio Settings

At the Profile level, you can activate or deactivate WI-FI Radio and configure the band of radio frequencies.

In the SD-WAN service of the Enterprise portal, select Configure > Profiles . The Configuration Profiles page appears.
Select a profile you want to configure WI-FI Radio settings and 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 Device Settings page for the selected profile appears.
Under the Connectivity category, select WI-FI Radio.

Figure 36. Configure Wi-Fi Radio Settings
The WI-FI Radio area expands and by default, the Radio Enabled checkbox is selected and Channel is set to Automatic.
Select the radio band. It can be 2.4 GHz or 5 GHz.
Select Save Changes.

At the Edge level, you can override the WI-FI Radio settings specified in the Profile by selecting the Override checkbox. For additional information, see Configure Wi-Fi Radio Overrides.

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 VeloCloud 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:

In the SD-WAN service of the Enterprise portal, go to Configure > Profiles . 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 Device tab displays the configuration options for the selected Profile.

Figure 37. Configure Common Criteria Firewall Settings for Profiles
In the Connectivity category, select Common Criteria Firewall.
Turn on Enable Common Criteria Firewall toggle button.
When the Enable Common Criteria Firewall option is set to On, the following packets are automatically dropped, counted, or logged:
- Packets with invalid fragments or fragments which cannot be completely re-assembled that are destined to the Edge.
- Packets where the source address is defined as being on either broadcast network, multicast network, or loopback address.
- Packets with the IP options: Loose Source Routing, Strict Source Routing, or Record Route specified.
- Packets which have the source or destination address as unspecified or reserved for future.
- Packets where the source address does not belong to the networks reachable via the network interface where the network packet was received.
- Packets where the source or destination address of the network packet is defined as being unspecified (i.e. 0.0.0.0) or an address “reserved for future use” (i.e. 240.0.0.0/4) as specified in RFC 5735 for IPv4.
- Packets where the source or destination address of the network packet is defined as an “unspecified address” or an address “reserved for future definition and use” (i.e. unicast addresses not in this address range: 2000::/3) as specified in RFC 3513 for IPv6.
The CC Firewall settings are applied to all the Edges associated with the Profile. You can choose to override the CC Firewall settings for an Edge. For steps, see Configure Common Criteria Firewall Settings for Edges.

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 Configure > Profile/Edges > Device > VPN Services > Gateway Handoff Assignment page.

Considerations When Assigning Partner Gateways

Consider the following notes 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.

Note: If you do not see the Gateway Handoff Assignment area displayed in the Device page, contact your Operator to activate this feature.

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.

To assign Partner Gateways for Profiles, perform the following steps:

In the SD-WAN service of the Enterprise portal, go to Configure > Profiles .
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 38. 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 39. 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 40. 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:

By default global segment is selected in the Segment drop-down. You can also choose any other segment (CDE Type) based on your requirements.

In the SD-WAN service of the Enterprise portal, go to Configure > Profiles .
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 41. 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 Configure > Profile/Edges > Device > VPN Services > Controller Assignment page.

Note: At least one Gateway in the Gateway Pool should be a "Controller Only" Gateway.

To assign Controllers for Profiles, perform the following steps:

In the SD-WAN service of the Enterprise portal, go to Configure > Profiles .
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.

Figure 43. Configure Controller Assignment
Scroll down to VPN Services section and expand Controller Assignment.
Select + Select Gateways, the Select Partner Gateways for Global Segment dialog box appears.

Figure 44. Select Partner Gateways for Segments
From the Controllers section, select the Controllers to assign to the Profile and select Update.
The Controller 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 in the navigation path Configure > Edges > <Edge name> > VPN Services > Controller Assignment .

Configure Cloud VPN

This section discusses the following topics:

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.

Cloud VPN supports the following traffic flows:

Branch to Non SD-WAN Destination via Gateway
Branch to SD-WAN 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.

Table 17. Destinations
	Non SD-WAN Destination
	Branch to SD-WAN 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

Branch to Non SD-WAN Destination via Gateway supports the following configurations:

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 SD-WAN 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:

Table 18. Tunnels
	Primary tunnel
	Redundant tunnel
	Secondary VPN Gateway

Arista supports the following Non SD-WAN Destination configurations through SD-WAN 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 SD-WAN 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.

Configuring with a third party can benefit you in the following ways:

Eliminates mesh
Cost
Performance

Arista Cloud VPN is simple to set up (global networks of SD-WAN 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 the Configure Amazon Web Services section.

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.

Configuring using Zscaler provides the following benefits:

Performance: Direct to Zscaler (Zscaler via Gateway)
Managing proxy is complex: Allows simple click policy aware Zscaler

Branch to SD-WAN Hub

The SD-WAN Hub is an Edge deployed in Data Centers for branches to access Data Center resources. You must set up your SD-WAN Hub in the SASE Orchestrator. The SASE Orchestrator notifies all the SD-WAN Edges about the Hubs, and the SD-WAN Edges build secure overlay multi-path tunnel to the Hubs.

The following figure shows how both Active-Standby and Active-Active are supported.

Figure 47. Active-Standby and Active-Active

Branch to Branch VPN

Branch to Branch VPN supports configurations for establishing a VPN connection between branches for improved performance and scalability.

Branch to Branch VPN supports two configurations:

Cloud Gateways
SD-WAN Hubs for VPN

The following figure shows Branch to Branch traffic flows for both Cloud Gateway and a SD-WAN 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 SASE Orchestrator from Configure > Profiles > Device Tab in the Cloud VPN area.

Note: For step-by-step instructions to configure Cloud VPN, see Configure Cloud VPN for Profiles.

Branch to Non SD-WAN Destination via Edge

Branch to Non SD-WAN Destination via Edge supports the following Route-based VPN configurations:

Generic IKEv2 Router (Route Based VPN)
Generic IKEv1 Router (Route Based VPN)

Note: Arista supports only Route-based Non SD-WAN Destination configurations through Edge.

For additional information, see Configure Non SD-WAN Destinations via Edge.

Configure Cloud VPN for Profiles

At the Profile level, the Orchestrator allows you to configure Cloud Virtual Private Network (VPN). To initiate and respond to VPN connection requests, you must activate Cloud VPN.

To configure Cloud VPN for a Profile, follow the below steps:

In the SD-WAN service of the Enterprise portal, go to Configure > Profiles > Device tab .
Go to VPN Services area and activate Cloud VPN by turning the toggle button to On.

Figure 49. Configure Cloud VPN for a Profile
On activating Cloud VPN for a Profile, you can configure the following Cloud VPN types:
Note: Cloud VPN must be configured per Segment.

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 SD-WAN Hubs VPN

To establish a VPN connection between Branch and Hubs, follow the below steps:

In the SD-WAN service of the Enterprise portal, go to Configure > Profiles .
Select a Profile or select the View link in the Device column.
The Device settings page for the selected Profile appears.
Go to VPN Services area and activate Cloud VPN by turning the toggle button to On.
Select the Enable Branch to Hubs check box under Branch to Hub Site (Permanent VPN).
The Hubs Designation section appears on the screen.
Select Edit Hubs.
The following window is displayed:

Figure 50. Add Hubs
From Available Edges & Clusters section, you can select and configure the Edges to act as SD-WAN Hubs, or Backhaul Hubs.

Note: An Edge cluster and an individual Edge can be simultaneously configured as Hubs in a Branch Profile. Once Edges are assigned to a Cluster, they cannot be assigned as individual Hubs.
Select the Enable Conditional BackHaul check box to activate Conditional Backhaul.

With Conditional Backhaul activated, the Edge can failover Internet-bound traffic (Direct Internet traffic, Internet via SD-WAN Gateway (IPv4 and IPv6) and Cloud Security Traffic via IPsec) to MPLS links whenever there are no Public Internet links available. When Conditional Backhaul is activated, by default all Business Policy rules at the Branch level are subject to failover traffic through Conditional Backhaul. You can exclude traffic from Conditional Backhaul based on certain requirements for selected policies by deactivating this feature at the selected Business Policy level. For additional information, see Conditional Backhaul.
Select Update Hubs.

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 SD-WAN Edge, tunnels to SD-WAN 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 SD-WAN Edge the ability to failover Internet-bound traffic over Private overlays to the Hub and provides reachability to Internet destinations.

Whenever Public Internet link fails and Conditional Backhaul is activated, the Edge can failover the following Internet-bound traffic types:

Direct to Internet
Internet via SD-WAN Gateway
Cloud Security Service traffic

Under normal operations, the Public link is UP and Internet-bound traffic flows normally either Direct or via SD-WAN Gateway as per the Business Policies configured.

Figure 51. Internet-bound Traffic Flows Normally

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.

The Business Policy configured on the Hub will determine how this traffic is forwarded once it reaches the Hub. The options are:

Direct from Hub
Hub to Gateway and then breakout from the Gateway

Figure 52. Internet-bound Traffic is Dynamically Backhauled to the Hub

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 hold-off timer. After the hold off timer is reached, flows will be failed back to the Public Internet link.

Figure 53. Traffic Flows Back to the Public Link

Use case 2: Cloud Security Service (CSS) Link Failure

Whenever there is a CSS (Zscaler) link failure on an SD-WAN 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 SD-WAN 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.

CBH will be effective only if:

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 CSS link goes DOWN and Public Internet link is UP, the Internet-bound traffic that use CSS link is dynamically backhauled to the Hub, irrespective of the status of the public link.

Figure 54. Traffic is Dynamically Backhauled to the Hub

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.

Figure 55. Traffic Flows Back to the CSS

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

At the Profile level, in order to configure Conditional Backhaul, you should activate Cloud VPN, and then establish VPN connection between Branch and SD-WAN Hubs by performing the following steps:

In the SD-WAN service of the Enterprise portal, go to Configure > Profiles .
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 56. Add Hubs
From the 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 SD-WAN Edge can failover:
- Internet-bound traffic (Direct Internet traffic, Internet via SD-WAN 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 SD-WAN 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 57. 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.

If extreme packet loss occurs in the Public link of the Branch and the link is down then the same flows toggle to Internet Backhaul at the Branch.

Note: The Business Policy on the Hub determines how the Hub forwards the traffic. As the Hub has no specific rule for these flows, they are categorized as default traffic. For this scenario, a Business Policy rule can be created at the Hub level to match the desired IPs or Subnet ranges to define how flows from a specific Branch are handled in the event when Conditional Backhaul becomes operational.

Configure a Tunnel Between a Branch and a Branch VPN

Configure Branch to Branch VPN to establish a VPN connection between Branches.

In the SD-WAN service of the Enterprise portal, go to Configure > Profiles > Device tab .
Go to VPN Services area and activate Cloud VPN by turning the toggle button to On.

To configure a Branch to Branch VPN, select the Enable Branch to Branch VPN check box under Branch to Branch VPN (Transit & Dynamic).

Branch to Branch VPN supports following two configurations for establishing a VPN connection between branches:

Table 19. Branch to Branch VPN Configurations
Configuration	Description
Cloud Gateways	In this option, Edges establish VPN tunnel with the closest Gateway and connections between Edges go through this Gateway. The SD-WAN Gateway may have traffic from other Customers.
Hubs for VPN	In this option, one or more Edges are selected to act as Hubs that can establish VPN connections with Branches. Connections between Branch Edges go through the Hub. The Hub is your only asset which has your corporate data on it, improving overall security.

To activate profile isolation, select the Isolate Profile check box. If selected, the Edges within the Profile do not learn routes from other Edges outside the Profile via the SD-WAN Overlay.
You can activate Dynamic Branch To Branch VPN to all Edges or to Edges within a Profile. By default, it is configured for all Edges.

When you activate Dynamic Branch to Branch VPN, the first packet goes through the Cloud Gateway (or the Hub). If the initiating Edge determines that traffic can be routed through a secure overlay multi-path tunnel, and if Dynamic Branch to Branch VPN is activated, then a direct tunnel is created between the Branches.

Once the tunnel is established, traffic begins to flow over the secure overlay multi-path tunnel between the Branches. After 180 seconds of traffic silence (forward or reverse from either side of the Branches), the initiating Edge tears down the tunnel.

Note: To configure Dynamic Branch To Branch VPN by Profile, make sure the Isolate Profile check box is unselected.
Select Save Changes.

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 SD-WAN Gateway by activating Cloud VPN.

In the SD-WAN service of the Enterprise portal, go to Configure > Profiles .
Select a Profile or select the View link in the Device column.
The Device settings page for the selected Profile appears.
Go to VPN Services area and activate Cloud VPN by turning the toggle button to On.
To establish a VPN connection between a Branch and Non SD-WAN Destination through SD-WAN Gateway, select the Enable Edge to Non SD-WAN via Gateway check box under Edge to Non SD-WAN Sites.

Figure 59. Enable Edge to Non SD-WAN via Gateway
From the drop-down menu, select a Non SD-WAN Destination to establish VPN connection. Select the Add button to add additional Non SD-WAN Destinations.
You can also create VPN connections by selecting the New Destination button. The New Non SD-WAN Destinations via Gateway dialog appears.
For additional information about configuring a Non SD-WAN Destination Network Service through Gateway, see Configure Non SD-WAN Destinations via Gateway
Select Save Changes.

Note: Before associating a Non SD-WAN Destination to a Profile, ensure that the Gateway for the Enterprise Data Center is already configured by the Enterprise Data Center Administrator and the Data Center VPN Tunnel is activated.

Configure a Tunnel Between a Branch and a Non SD-WAN Destinations via Edge

After configuring a Non SD-WAN Destination via Edge in the Orchestrator, you have to associate the Non SD-WAN Destination to the desired Profile in order to establish the tunnels between SD-WAN 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:

In the SD-WAN service of the Enterprise portal, go to Configure > Profiles > Device tab .
Go to VPN Services area and activate Cloud VPN by turning the toggle button to On.
To establish a VPN connection directly from an SD-WAN Edge to a Non SD-WAN Destination (VPN gateway of Cloud provider such as Azure, AWS), select the Enable Non SD-WAN via Edge check box under Non SD-WAN Destinations via Edge section.

Figure 60. Enable Non SD-WAN via Edge
From the configured Services drop-down menu, select a Non SD-WAN Destination to establish VPN connection.
Select the Add button to add additional Non SD-WAN Destinations.

Note: Only one Non SD-WAN Destinations via Edge service is allowed to be activated in at most one Segment. Two Segments cannot have the same Non SD-WAN Destinations via Edge service activated.

For additional information about configuring a Non SD-WAN Destination Network Service through Edge, see Configure Non SD-WAN Destinations via Edge.
To deactivate a particular service, deselect the respective Enable Service check box.
Select Save Changes.

Note: Before associating a Non SD-WAN Destination to a Profile, ensure that the Gateway for the Enterprise Data Center is already configured by the Enterprise Data Center Administrator and the Data Center VPN Tunnel is activated.

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.

Note: Only one CSS with GRE is allowed per Profile.

Before you begin:

Ensure that you have access permission to configure network services.
Ensure that your VeloCloud 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.

In the SD-WAN service of the Enterprise portal, select Configure > Profiles .
Select the Device icon next to a profile, or select the link to the profile, and then select the Device tab.
In the Cloud Security area, switch the dial from the Off position to the On position.

Configure the following settings:

Figure 61. Configure Cloud Security Services for Profiles

Table 20. Cloud Security Service Option Description
Option	Description
Cloud Security Service	Select a cloud security service from the drop-down menu to associate with the profile. You can also select New Cloud Security Service from the drop-down to create a new service type. For additional information about how to create a new CSS, see Configure a Cloud Security Service. Note: For cloud security services with Zscaler login URL configured, Login to Zscaler button appears in the Cloud Security Service area. selecting the Login to Zscaler button will redirect you to the Zscaler Admin portal of the selected Zscaler cloud.
Tunneling Protocol	This option is available only for Zscaler cloud security service provider. If you select a manual Zscaler service provider then choose either IPsec or GRE as the tunneling protocol. By default, IPsec is selected. Note: If you select an automated Zscaler service provider then the Tunneling Protocol field is not configurable but displays the protocol name used by the service provider.
Hash	Select the Hash function as SHA 1 or SHA 256 from the drop-down. By default, SHA 1 is selected.
Encryption	Select the Encryption algorithm as AES 128 or AES 256 from the drop-down. By default, None is selected.
Key Exchange Protocol	Select the key exchange method as IKEv1 or IKEv2. By default, IKEv2 is selected. This option is not available for Symantec cloud security service.
Login to Zscaler	Select Login to Zscaler to login to the Zscaler Admin portal of the selected Zscaler cloud.

Select Save Changes.
When you enable Cloud Security Service and configure the settings in a profile, the setting is automatically applied to the Edges that are associated with the profile. If required, you can override the configuration for a specific Edge. See Configure Cloud Security Services for Edges.
For the profiles created with cloud security service enabled and configured prior to 3.3.1 release, you can choose to redirect the traffic as follows:
- Redirect only web traffic to Cloud Security Service
- Redirect all Internet bound traffic to Cloud Security Service
- Redirect traffic based on Business Policy Settings – This option is available only from release 3.3.1. If you choose this option, then the other two options are no longer available.
Note: For the new profiles that you create for release 3.3.1 or later, by default, the traffic is redirected as per the Business Policy settings. See Configure Business Policies with Cloud Security Services.

Configure Zscaler Settings for Profiles

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 on the Device tab.

Before you configure Zscaler, you must have Zscaler cloud subscription. For steps on how to create cloud subscription of type Zscaler, Configure API Credentials.

Note: By default, the Zscaler section is not available on the Device page for Profiles. Contact your Operator to get this feature activated at the Profile level.

To configure Zscaler at the Profile level, perform the following steps:

In the SD-WAN service of the Enterprise portal, go to Configure > Profiles . 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. The configuration options for the selected Profile are displayed in the Device tab.

Figure 62. Configure Zscaler Settings for Profiles
Under the VPN Services category, select Zscaler and activate Zscaler by turning the toggle button to On.
From the Cloud Subscription drop-down menu, select your Zscaler subscription.
The Zscaler Cloud associated with the selected subscription automatically appears in the Cloud Name field.
To edit location Gateway options. select the Edit button. The Edit Location Gateway Options dialog box appears.

Figure 63. Edit Location Gateway Options
Configure the Gateway options and Bandwidth control settings for Location and select Done. For additional information about Zscaler Gateway Options and Bandwidth Control parameters, see https://help.zscaler.com/zia/configuring-locations.
Select Reset to reset Zscaler Location gateway options to default.
After updating the required settings, select Save Changes in the Device page.

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 includes:

Multicast support on both overlay and underlay
Protocol-Independent Multicast- Sparse Mode (PIM-SM) on SD-WAN Edge
Internet Group Management Protocol (IGMP) version 2 on SD-WAN 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:

In the SD-WAN service of the Enterprise portal, go to Configure > Profiles . 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 on the Device tab.
Scroll down to the Routing & NAT category and expand the Multicast area.
Turn on the toggle button to activate the Multicast feature.

Note: There must be at least one RP group when Multicast is turned on.

The RP Selection is set to Static by default.

Figure 65. Configure Multicast for Profiles

Configure the following Multicast settings:

Table 21. Multicast Settings Option Descriptions
Option	Description
RP Selection	Static is the default and supported mechanism.
RP Address	Enter the IP address of the device, which is the route processor for a multicast group.
Multicast Group	Enter a range of IP addresses and port numbers that define a Multicast group. Once the host device has membership to the Multicast group, it can receive any data packets that are sent to the group defined by the IP address and port number.
Enable PIM on Overlay	Activate PIM peering on SD-WAN Overlay. For example when activated on both branch SD-WAN Edge and hub SD-WAN Edge, they form a PIM peer. By default, the source IP address for the overlays is derived from any Switched interfaces (if present), or a Routed interface of type Static with a deactivated WAN Overlay. You can choose to change the source IP by specifying Source IP Address, which will be a virtual address and will be advertised over the overlay automatically.
PIM Timers	Under Advanced Settings, configure the PIM timers details, if needed: Join Prune Send Interval- The Join Prune Interval Timer. Default value is 60 seconds. The allowable range is 60 through 600. Keep Alive Timer- PIM keep alive timer. Default value is 60 seconds. The allowable range is 31 through 60000.

To configure the multicast settings at the Interface level, see Configure Interface Settings for Profiles.

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:

In the SD-WAN service of the Enterprise portal, go to Configure > Profiles .
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.

Scroll down to the Routing & NAT category and select DNS.

Add New Private DNS Service

In the Conditional DNS Forwarding (Private DNS) section, select Private DNS to forward the DNS requests related to the domain name. Select Add to add existing private DNS servers to the drop-down menu. Select Delete to remove the selected private DNS server from the list.
To add a new private DNS, select New Private DNS.

Figure 67. Add New Private DNS Service

Following are the available options:

Table 22. Private DNS Option Descriptions
Option	Description
DNS Type	Displays Private by default. You cannot edit this option.
Service Name	Type the name of the DNS service.
IPv4 Server	Type the IPv4 address for IPv4 Server. Select the plus (+) icon to add more addresses.
IPv6 Server	Type the IPv6 address for IPv6 Server. Select the plus (+) icon to add more addresses.
Private Domains	Select Add, and then type the Private Domain name and description.

Select Save Changes.

Add New Public DNS Service

In the Public DNS section, select a public DNS service from the drop-down menu to be used for querying the domain names. By default, Google and OpenDNS servers are pre-configured as public DNS.
To add a new public DNS, select New Public DNS.
Note: The Public DNS service is activated on a VLAN or a routed interface, if DNS Proxy is activated on the same VLAN or routed interface.

Figure 68. Add New Public DNS Service

Following are the available options:

Table 23. Public DNS Option Descriptions
Option	Description
DNS Type	Displays Public by default. You cannot edit this option.
Service Name	Enter the name of the DNS service.
IPv4 Server	Enter the IPv4 address for IPv4 Server. Select the plus (+) icon to add more addresses.
IPv6 Server	Enter the IPv6 address for IPv6 Server. Select the plus (+) icon to add more addresses.

Select Save Changes.

Add New Local DNS Entry

In the Local DNS Entries section, select Edit to edit an existing local DNS entry. Select Delete to remove the selected local DNS entry from the list.
To add a new local DNS entry, select New Local DNS Entry.

Figure 69. Add New Local DNS Entry

Following are the available options:

Table 24. Local DNS Entry Option Descriptions
Option	Description
Domain Name	Enter the device domain name.
IP Addresses	Enter either an IPv4 or an IPv6 address.
Add	Select to add multiple IP addresses. Note: A maximum of 10 IP addresses can be added for each domain name.
Delete	Select to delete the selected IP addresses.

Select Save Changes.

After configuring the Private DNS, Public DNS, and Local DNS Entries, select Save Changes in the Device page.

Note: In addition to the actual data from the DNS, Deep Packet Inspection (DPI) also feeds the DNS cache with hostname IP pairs when Qosmos parses the HTTP destination host or SSL SNI.

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.

OSPF is an interior gateway protocol (IGP) that operates within a single autonomous system (AS).

Note: OSPF is configurable only on the Global Segment.

OSPFv3 is introduced in the 5.2 release and provides support for the following:

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.

This section discusses how to configure dynamic routing with OSPFv2 and OSPFv3 along with Route Summarization.

Note: OSPFv2 supports only IPv4. OSPFv3 supports only IPv6 and is available starting with the 5.2 release.

Note: Route Summarization is available starting with the 5.2 release.

To activate OSPF, perform the steps in the procedure below:

In the SD-WAN service of the Enterprise Portal, select Configure > Profiles .

The Profile page displays.

Note: Depending upon your login permissions, you might need to select a Customer or Partner first, then select the Configure tab as indicated in next step.
Select a Profile from the list of available Profiles.
Go to the Routing & NAT section in the UI and select the arrow next to OSPF.

In the OSPF Areas section, configure the Redistribution Settings for OSPFv2/v3, BGP Settings, and if applicable, Route Summarization.

Note: OSPFv2 supports only IPv4. OSPFv3 supports only IPv6 and is only available in the 5.2 release.

Table 25. OSPF Area Option Descriptions
Option	Description
Redistribution Settings
Default Route	Choose an OSPF route type (O1 or O2) to be used for default route. Default selection for this configuration is "None".
Advertise	Choose either Always or Conditional. (Choosing Always means to Advertise the default route always. Choosing Conditional means to redistribute default route only when Edge learns via overlay or underlay). The “Overlay Prefixes” option must be checked to use the Conditional default route.
Overlay Prefixes	If applicable, check the Overlay Prefixes check box.
BGP Settings
BGP	To enable injection of BGP routes into OSPF, select the BGP check box. BGP routes can be redistributed into OSPF, so if this is applicable, enter or choose the configuration options as follows:
Set Metric	In the Set Metric text box, enter the metric. (This is the metric that OSPF would put in its external LSAs that it generates from the redistributed routes). The default metric is 20.
Set Metric Type	From the Set Metric Type drop-down menu, choose a metric type. (This is either type `E1` or `E2` (OSPF External-LSA type)); the default type is `E2`)

In OSPF Areas, select +Add and configure the options, as described in the table below. Add additional areas, if necessary, by selecting +Add. The fields in the table below cannot be overridden at the Edge level.

Table 26. OSPF Area Add Option Descriptions
Option	Description
Area ID	Select inside the Area ID text box, enter an OSPF area ID.
Name	Select inside the Name text box, enter a descriptive name for your area.
Type	By default, the Normal type is selected. Only Normal type is supported at this time.

Next, configure the Interface Settings for OSPF. For configuration details, see either Configure Interface Settings for Profiles or Configure Interface Settings for Edges.

Note: OSPF has to be activated at the Profile level first before you can configure it on Edge interfaces.

If applicable, configure Route Summarization.

Note: The Route Summarization feature is available starting with the 5.2 release, for an overview and use case for this feature, see Route Summarization.

Navigate to Route Summarization.

Select +Add in the Route Summarization area. A new row is added to the Route Summarization area. Configure Route Summarization, as described in the table.

Figure 71. Configuring Route Summarization

Table 27. Route Summarization Option Descriptions
Option	Description
Subnet	Enter the IP subnet.
No Advertise	When No Advertise is set, all the external routes (Type-5) that are under this supernet are summarized and have chosen not to advertise it. This means it effectively blocks the whole supernet from advertising to its peer.
Tag	Enter the router Tag value (1-4294967295).
Metric Type	Enter the Metric Type (E1 or E2).
Metric	Enter the advertised metric for this route (0-16777215).

Add additional routes, if necessary, by selecting +Add. Route Summarization Clone or Delete to copy or delete a Route Summarization.

Select Save Changes.

Route Filters

There are two different types of routing:

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:

In the SD-WAN service of the Enterprise portal, select Configure > Profiles .
Select the Device icon for a profile, or select a profile and select the Device tab.

Note: The Device tab is normally the default tab.
On the Device tab, scroll down to the Routing & NAT section and select the arrow next to the BDF area to open it.

Figure 72. Configure BFD for Profiles

Select the BDF slider to ON position and configure the following settings:

Table 28. BFD for Profiles Configuration Option Descriptions
Field	Description
Peer Address	Enter the IPv4 address of the remote peer to initiate a BFD session.
Local Address	Enter a locally configured IPv4 address for the peer listener. This address is used to send the packets. Note: You can select the IPv6 tab to configure IPv6 addresses for the remote peer and the peer listener. For IPv6, the local and peer addresses support only the following format: IPv6 global unicast address (`2001:CAFE:0:2::1`) IPv6 unique local address (`FD00::1234:BEFF:ACE:E0A4`)
Multihop	Select the check box to enable multi-hop for the BFD session. While BFD on Edge and Gateway supports directly connected BFD Sessions, you need to configure BFD peers in conjunction with multi-hop BGP neighbors. The multi-hop BFD option supports this requirement. Multihop must be enabled for the BFD sessions for NSD-BGP-Neighbors.
Detect Multiplier	Enter the detection time multiplier. The remote transmission interval is multiplied by this value to determine the detection timer for connection loss. The range is from 3 to 50 and the default value is 3.
Receive Interval	Enter the minimum time interval, in milliseconds, at which the system can receive the control packets from the BFD peer. The range is from 300 to 60000 milliseconds and the default value is 300 milliseconds.
Transmit Interval	Enter the minimum time interval, in milliseconds, at which the local system can send the BFD control packets. The range is from 300 to 60000 milliseconds and the default value is 300 milliseconds.

Select the Plus ( +) icon to add details of more peers.
Select Save Changes.
When you configure BFD rules for a profile, the rules 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 BFD for Edges for additional information.
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 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.

From the 3.3.2 release, a new LAN-side NAT module was introduced to NAT VPN routes on the Edge. The primary use cases are as follows:

Branch overlapping IP due to M&A
Hiding the private IP of a branch or data center for security reasons

In the 3.4 release, additional configuration fields are introduced to address additional use cases. Below is a high-level breakdown of LAN-side NAT support in different releases:

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)

Note:

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 at the Profile Level:

Note: If the users want to configure the default rule, “any” they must specify the IP address must be all zeros and the prefix must be zero as well: 0.0.0.0/0.

In the SD-WAN service of the Enterprise Portal, go to Configure > Profiles .
Select the appropriate Profile by selecting the check box next to the Profile Name.
If not already selected, select the Device tab link.
Scroll down to the Routing & NAT.
Open the LAN-Side NAT Rules area.
Select +ADD to add a NAT Source or Destination.

To configure LAN-Side NAT Rules, select +ADD and enter the details as described in the following table to add a NAT Source or Destination.

Table 29. LAN-side NAT Rule- Options and Descriptions
Option	Description
Type	Determine whether the NAT rule should be applied on the source or destination IP address of user traffic, and accordingly select either Source or Destination as the type from the drop-down menu.
Inside Address	Enter the "inside" or "before NAT" IPv4 address (if prefix is 32), or subnet (if prefix is less than 32).
Outside Address	Enter the "outside" or "after NAT" IPv4 address (if prefix is 32), or subnet (if prefix is less than 32).
Source Route	Optionally, for destination NAT, specify source IPv4 address/subnet as match criteria. Only valid if the type is “Destination”. Ensure the prefix is a value from `1` through `32` and the default value is `any`.
Destination Route	Optionally, for source NAT, specify destination IPv4 address/subnet as match criteria. Only valid if the type is “Source”. Ensure the prefix is a value from `1` through `32` and the default value is `any`.
Description	Enter a description for the NAT rule.

Select Save Changes on the Device page. The configured NAT Source and Destination appears as shown in the following screenshot.

Figure 74. Adding the NAT Source and Destination

Important:If the Inside Prefix has a lesser value than the Outside Prefix, the feature supports Many:1 NAT in the LAN to WAN direction and 1:1 NAT in the WAN to LAN direction. For example, if the Source Type has an Inside Address with a value of 10.0.5.0/24, and an Outside Address with the value, 192.168.1.25/32, sessions from the LAN to the WAN with the Source IP address matching the Inside Address 10.0.5.1 translate to 192.168.1.25. For sessions from the WAN to the LAN with a Destination IP address matching the Outside Address, 192.168.1.25 translate to 10.0.5.25. Similarly, if the Inside Prefix has a value greater than the Outside Prefix, the feature supports Many:1 NAT in the WAN to LAN direction and 1:1 NAT in the LAN to WAN direction. The NAT IP address does not automatically advertise, and you must ensure that a static route for the NAT IP address should be configured and the next hop should be the LAN next hop IP address of the source subnet.

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.

Note: Route Summarization is new for the 5.2 release. For an overview, use case, and black hole routing details for Route Summarization, see Route Summarization.

To configure BGP:

In the SD-WAN service of the Enterprise portal, select the Configure tab.
From the left menu, select Profiles. The Profile page displays.
Select a Profile from the list of available Profiles (or Add a Profile if necessary).
Go to the Routing & NAT section and select the arrow next to BGP to expand.
In the BGP area, toggle the radio button from Off to On.

Figure 75. Configure BGP from Edge to Underlay Neighbors for Profiles
In the BGP area, enter the local Autonomous System Number (ASN) number in the appropriate text field.

Configure the BGP Settings.

Table 30. BGP Configuration Option and Descriptions
Option	Description
Router ID	Enter the global BGP router ID. If you do not specify any value, the ID is automatically assigned. If you have configured a loopback Interface for the Edge, the IP address of the loopback Interface will be assigned as the router ID.
Keep Alive	Enter the keep alive timer in seconds, which is the duration between the keep alive messages that are sent to the peer. The range is from 0 to 65535 seconds. The default value is 60 seconds.
Hold Timer	Enter the hold timer in seconds. When the keep alive message is not received for the specified time, the peer is considered as down. The range is from 0 to 65535 seconds. The default value is 180 seconds.
Uplink Community	Enter the community string to be treated as uplink routes. Uplink refers to link connected to the Provider Edge(PE). Inbound routes towards the Edge matching the specified community value will be treated as Uplink routes. The Hub/Edge is not considered as the owner for these routes. Enter the value in number format ranging from 1 to 4294967295 or in AA:NN format.
Enable Graceful Restart check box	When selecting this check box: The local router does not support forwarding during the routing plane restart. This feature supports preserving forwarding and routing in case of peer restart.

Select +Add in the Filter List area to create one or more filters. These filters are applied to the neighbor to deny or change the attributes of the route. The same filter can be used for multiple neighbors.

Figure 76. Add Filter

In the appropriate text fields, set the rules for the filter, as described in the following table.

Table 31. Filter Option Descriptions
Option	Description
Filter Name	Enter a descriptive name for the BGP filter.
Match Type and Value	Choose the type of the routes to be matched with the filter: Prefix for IPv4 or IPv6: Choose to match with a prefix for IPv4 or IPv6 address and enter the corresponding prefix IP address in the Value field. Community: Choose to match with a community and enter the community string in the Value field.
Exact Match	The filter action is performed only when the Prosecutes match exactly with the specified prefix or community string. By default, this option is enabled.
Action Type	Choose the action to be performed when Thebes routes match with the specified prefix or the community string. You can either permit or deny the traffic.
Action Set	When the BGP routes match the specified criteria, you can set to route the traffic to a network based on the attributes of the path. Select one of the following options from the drop-down list: None: The attributes of the matching routes remain the same. Local Preference: The matching traffic is routed to the path with the specified local preference. Community: The matching routes are filtered by the specified community string. You can also select the Community Additivecheck box to enable the additive option, which appends the community value to existing communities. Metric: The matching traffic is routed to the path with the specified metric value.

Select the plus (+) icon to add more matching rules for the filter. Repeat the procedure to create more BGP filters.

The configured filters are displayed in the Filter List area.
Note: The maximum number of supported BGPv4 Match/Set rules is 512 (256 inbound, 256 outbound). Exceeding 512 total Match/Set rules is not supported and may cause performance issues, resulting in disruptions to the enterprise network.

Scroll down to the Neighbors area and select +Add.

Configure the following settings for the IPv4 addressing type, as described in the table below.

Table 32. Neighbor Option Descriptions
Option	Description
Neighbor IP	Enter the IPv4 address of the BGP neighbor
ASN	Enter the ASN of the neighbor
Inbound Filter	Select an Inbound filer from the drop-down list
Outbound Filter	Select an Outbound filer from the drop-down list

Note: When overriding and configuring BGP neighbors at the Edge level, any Profile-level filters associated with the neighbors will be removed when you switch the Edge from one profile to another. So at the Edge level, you must make sure to re-associate the filters with the BGP neighbors after switching the Edge profile.

Select the Plus (+) icon to add more BGP neighbors.

Note: Over Multi-hop BGP, the system might learn routes that require recursive lookup. These routes have a next-hop IP which is not in a connected subnet, and do not have a valid exit Interface. In this case, the routes must have the next-hop IP resolved using another route in the routing table that has an exit Interface. When there is traffic for destination that needs these routes to be looked up, routes requiring recursive lookup will get resolved to a connected Next Hop IP address and Interface. Until the recursive resolution happens, the recursive routes point to an intermediate Interface. For more information about Multi-hop BGP Routes, see the Remote Diagnostic Tests on Edges section in the Arista VeloCloud SD-WAN Troubleshooting Guide.
Scroll down to Advanced Settings and select the down arrow to open the Advanced Settings section.

Figure 78. Advanced BGP Settings

Configure the following advanced settings, as indicated in the following table, which are globally applied to all the BGP neighbors with IPv4 addresses.

Table 33. Advanced BGP Settings Option Descriptions
Option	Description
Overlay Prefix	Select the check box to redistribute the prefixes learned from the overlay. For example, when a Spoke is connected to primary and secondary Hub or Hub Cluster, the Spoke's subnets are redistributed by primary and secondary Hub or Hub Cluster to their neighbor with metric (MED) 33 and 34 respectively. You must configure "bgp always-compare-med" in the neighbor router for symmetric routing.
Turn off AS-Path carry over	By default, this should be left unchecked. Select the check box to deactivate AS-PATH Carry Over. In certain topologies, deactivating AS-PATH Carry Over will influence the outbound AS-PATH to make the L3 routers prefer a path towards an Edge or a Hub. Note: When the AS-PATH Carry Over is deactivated, tune your network to avoid routing loops.
Connected Routes	Select the check box to redistribute all the connected Interface subnets.
OSPF	Select the check box to enable OSPF redistribute into BGP.
Set Metric	When you enable OSPF, enter the BGP metric for the redistributed OSPF routes. The default value is 20.
Default Route	Select the check box to redistribute the default route only when Edge learns the BGP routes through overlay or underlay. When you select the Default Routeoption, the Advertise option is available as Conditional.
Overlay Prefixes over Uplink	Select the check box to propagate routes learned from overlay to the neighbor with uplink flag.
Networks	Enter the network address in IPv4 format that BGP will be advertising to the peers. Select the plus + icon to add more network addresses.

When you enable the Default Route option, the BGP routes are advertised based on the Default Route selection globally and per BGP neighbor, as shown in the following table:

Table 34. Default Route Selection
Global	Per BGP Neighbor	Advertising Options
Yes	Yes	The per BGP neighbor configuration overrides the global configuration and hence default route is always advertised to the BGP peer.
Yes	No	BGP redistributes the default route to its neighbor only when the Edge learns an explicit default route through the overlay or underlay network.
No	Yes	Default route is always advertised to the BGP peer.
No	No	The default route is not advertised to the BGP peer.

Select the IPv6 tab to configure the BGP settings for IPv6 addresses. Enter a valid IPv6 address of the BGP neighbor in the Neighbor IP field. The BGP peer for IPv6 supports the following address format:
- Global unicast address (2001:CAFE:0:2::1)
- Unique Local address (FD00::1234:BEFF:ACE:E0A4)

Select Advanced to configure the following advanced settings, which are globally applied to all the BGP neighbors with IPv6 addresses.

Table 35. Advanced Settings Option Descriptions
Option	Description
Connected Routes	Select the check box to redistribute all the connected Interface subnets.
Default Route	Select the check box to redistribute the default route only when Edge learns the BGP routes through overlay or underlay. When you select the Default Route option, the Advertise option is available as Conditional. The Default Originate Filter option allows you to control how the default route is advertised. You can choose "None" to advertise the default route without any modification, "Same as Outbound" to use the same filter as the outbound filter or select a specific filter from the list. The chosen filter is then be applied to the default route, modifying its parameters accordingly.
Networks	Enter the network address in IPv6 format that BGP will be advertising to the peers. Select the Plus + icon to add more network addresses.

To configure Route Summarization, select +Add in the Route Summarization area and configure the required settings. For additional details, see Route Summarization.

Figure 79. Add Route Summarization
1. Under the Subnet column, enter the network range that you want to summarize in the A.B.C.D/M format and the IP subnet.
2. Under the AS Set column, select the Yes check box if applicable.
3. Under the Summary Only column, select the Yes check box to allow only the summarized route to be sent.
Add additional routes, if necessary, by selecting +Add. To clone or delete a route summarization, use the appropriate buttons, located next to +Add.
Select Save Changes.

Note: When you configure BGP settings for a profile, the configuration settings are automatically applied to the SD-WAN Edges that are associated with the profile.

You can also configure BGP for Non SD-WAN Destination Neighbors in an Edge. For additional information, see Configure BGP Over IPsec from Edge to Non SD-WAN Neighbors.

Configure 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.

Considerations for Using Visibility Mode

Note the following 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 choose a Visibility Mode in the SD-WAN service of the Enterprise portal, select Configure > Profiles .
The Profiles page displays the existing Profiles.
Go to Configure > Profiles .
Select the link to the Profile or select the View link in the Device column of the Profile.
The configuration options are displayed in the Device tab.

Figure 80. Visibility Mode for a Profile
Under Telemetry, go to the Visibility Mode area and select one of the following:
- Visibility by MAC address
- Visibility by IP address
Select Save Changes.

Note: Changes to Visibility mode are non-disruptive.

Configure SNMP Settings for Profiles

Follow the below steps to download the SD-WAN Edge MIB:

In the SD-WAN service of the Enterprise portal, go to Diagnostics > Remote Diagnostics .
Select the link to the required Edge, and then go to the MIBs for Edge area. Select VELOCLOUD-EDGE-MIB from the drop-down menu, and then select Run.
Copy and paste the results onto your local machine.
Install all MIBs required by VELOCLOUD-EDGE-MIB on the client host, including SNMPv2-SMI, SNMPv2-CONF, SNMPv2-TC, INET-ADDRESS-MIB, IF-MIB, UUID-TC-MIB, and VELOCLOUD-MIB. All these MIBs are available on the Remote Diagnostics page.

Supported MIBs

SNMP MIB-2 System
SNMP MIB-2 Interfaces
VELOCLOUD-EDGE-MIB

Simple Network Management Protocol (SNMP) is a commonly used protocol for network monitoring and Management Information Base (MIB) is a database associated with SNMP to manage entities. In the SASE Orchestrator, you can activate SNMP by selecting the desired SNMP version.

Procedure to configure SNMP settings at Profile Level:

In the SD-WAN service of the Enterprise portal, go to Configure > Profiles .
Select a profile for which you want to configure the SNMP settings, and then select the View link under the Device column.
Scroll down to the Telemetry area, and then expand SNMP.
You can select either Enable Version 2c or Enable Version 3, or both SNMP version check boxes.

Figure 81. Configure SNMP Settings for a Profile

Select Enable Version 2c check box to configure the following options:

Table 36. Enable Version 2c- Options and Descriptions
Option	Description
Port	Type the port number in the textbox. The default value is `161`.
Community	Select Add to add any number of communities. Type a word or sequence of numbers as a password, to allow you to access the SNMP agent. The password may include alphabet A-Z, a-z, numbers 0-9, and special characters (e.g. &, $, #, %). 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. You can delete or clone a selected community.
Allow Any IPs	Select this check box to allow any IP address to access the SNMP agent. To restrict access to the SNMP agent, deselect the check box, and then add the IP address(es) that must have access to the SNMP agent. You can delete or clone a selected IP address.

Selecting the Enable Version 3 check box provides additional security. Select Add to configure the following options:

Table 37. Enable Version 3- Options and Descriptions
Option	Description
Name	Type an appropriate username.
Enable Authentication	Select this check box to add extra security to the packet transfer.
Authentication Algorithm	Select an algorithm from the drop-down menu: MD5 SHA1 SHA2 Note: This option is available only for the SNMP version 5.8 or above. Note: This field is available only when the Enable Authentication check box is selected.
Password	Type an appropriate password. Ensure that the Privacy Password is same as the Authentication Password configured on the Edge. Note: This field is available only when the Enable Authentication check box is selected. 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.
Enable Privacy	Select this check box to encrypt the packet transfer.
Algorithm	Choose a privacy algorithm from the drop-down menu: DES AES Note: Algorithm AES indicates AES-128. Note: This field is available only when the Enable Privacy check box is selected.

Note: You can delete or clone the selected entry.

Configure Firewall settings by following the below steps:

Navigate to Configure > Profiles , 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.

Note: SNMP interface monitoring is supported on DPDK enabled interfaces for 3.3.0 and later releases.

Configure Syslog Settings for Profiles

Ensure that Cloud Virtual Private Network (branch-to-branch VPN settings) is configured for the SD-WAN Edge (from where the Orchestrator bound events are originating) to establish a path between the SD-WAN Edge and the Syslog collectors. For more information, see Configure Cloud VPN for Profiles.

In an Enterprise network, the VeloCloud Orchestrator supports collection of Orchestrator bound events and firewall logs originating from enterprise SD-WAN Edge to one or more centralized remote Syslog collectors (Servers), in the native Syslog format. For the Syslog collector to receive the 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.

In the SD-WAN service of the Enterprise portal, click Configure > Profiles .
The Profiles page displays the existing Profiles.
To configure a Profile, click the link to the Profile or click the View link in the Device column of the Profile.
The configuration options are displayed in the Device tab.
From the Configure Segment drop-down menu, select a profile segment to configure Syslog settings. By default, Global Segment [Regular] is selected.

Under Telemetry, go to the Syslog area and configure the following details.

Figure 82. Configure Syslog Settings for a Profile

From the Facility drop-down menu, select a Syslog standard value that maps to how your Syslog server uses the facility field to manage messages for all the events from SD-WAN Edge. The allowed values are from local0 through local7.
Note: The Facility field is configurable only for the Global Segment, irrespective of the Syslog settings for the profile. The other segments will inherit the facility code value from the Global segment.
Select the Enable Syslog check box.

Select the + ADD button and configure the following details:

Table 38. Configure Syslog Settings- Options and Descriptions
Option	Description
IP	Enter the destination IP address of the Syslog collector.
Protocol	Select either TCP or UDP as the Syslog protocol from the drop-down menu.
Port	Enter the port number of the Syslog collector. The default value is 514.
Source Interface	As Edge interfaces are not available at the Profile level, the Source Interface field is set to Auto. The Edge automatically selects an interface with 'Advertise' field set as the source interface.
Roles	Select one of the following: EDGE EVENT FIREWALL EVENT EDGE AND FIREWALL EVENT
Syslog Level	Select the Syslog severity level that need to be configured. For example, If CRITICAL is configured, the SD-WAN Edge will send all the events which are set as either critical or alert or emergency. Note: By default, firewall event logs are forwarded with Syslog severity level INFO. The allowed Syslog severity levels are: EMERGENCY ALERT CRITICAL ERROR WARNING NOTICE INFO DEBUG
Tag	Optionally, enter a tag for the syslog. The Syslog tag can be used to differentiate the various types of events at the Syslog Collector. The maximum allowed character length is 32, delimited by period.
All Segments	When configuring a Syslog collector with FIREWALL EVENT or EDGE AND FIREWALL EVENT role, select the All Segments checkbox if want the Syslog collector to receive firewall logs from all the segments. If the checkbox is not selected, the Syslog collector will receive firewall logs only from that particular Segment in which the collector is configured. Note: When the role is EDGE EVENT, the Syslog collector configured in any segment will receive Edge event logs by default.

Select the + ADD button to add another Syslog collector or else click Save Changes. The remote syslog collector is configured in Orchestrator.
Note:
- You can configure a maximum of two Syslog collectors per segment and 10 Syslog collectors per Edge. When the number of configured collectors reaches the maximum allowable limit, the + button will be deactivated.
- Note: Based on the selected role, the edge will export the corresponding logs in the specified severity level to the remote syslog collector. If you want the Orchestrator auto-generated local events to be received at the Syslog collector, you must configure Syslog at the Orchestrator level by using the log.syslog.backend and log.syslog.upload system properties.
To understand the format of a Syslog message for Firewall logs, see Syslog Message Format for Firewall Logs.

The Orchestrator allows you to activate Syslog Forwarding feature at the Profile and the Edge level. On the Firewall page of the Profile configuration, activate the Syslog Forwarding button if you want to forward firewall logs originating from enterprise SD-WAN Edge to configured Syslog collectors.

Note: By default, the Syslog Forwarding button is available on the Firewall page of the Profile or Edge configuration, and is deactivated.

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.

The following system properties can be configured, as shown in the list below and the image below:

log.syslog.backend: Backend service syslog integration configuration
log.syslog.portal: Portal service syslog integration configuration
log.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. 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, the 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> The 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> The 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

The Orchestrator has the following system property options to arrange described parameters to allow secure syslog forwarding.

Note: The example below should be modified according the trust of chain structure.

{"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.crt

To 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.

If the 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.

Figure 85. Constant CRL Information Fetching

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.

IETF Syslog Message Format (RFC 3164)

<%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

The message has the following parts:

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

Arista supports the following Firewall log messages:

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

Table 39. Syslog Message Formats
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: Echo Reply (0) Echo Request (8) Redirect (5) Destination Unreachable (3) Traceroute (30) Time Exceeded (11) 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 underlying transport is UDP/TCP.
DPT	The destination port number of the session. This field is applicable only if the underlying 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: CSS-Backhaul- For traffic which is destined to Cloud Security Service from edge. Internet-via-< `egress-iface-name`>- For Cloud traffic going directly from edge using business policy. Internet-BH-via-< `backhaul hub name`>- For Cloud-bound traffic going to Internet through Backhaul hub using business policy. < `Remote edge name`>-via-Hub- For VPN traffic flowing through Hub. < `Remote edge name`>-via-DE2E- For VPN traffic flowing between the edges through direct VCMP tunnel. < `Remote edge name`>-via-Gateway- For VPN traffic flowing through Cloud gateway. NVS-via-< `gateway name`>- For Non SD-WAN Destination traffic flowing through Cloud gateway. Internet-via-< `gateway name`>- For Internet traffic flowing through Cloud gateway.
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: State Violation Reset Purged Aged-out Fin-Received RST-Received Error This field is available for Close and Deny log messages.

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:

In the SD-WAN service of the Enterprise portal, go to Configure > Profiles .
The Profiles page displays the existing Profiles.
Click the link to a Profile or click the View link in the Device column of the Profile that you want to configure Netflow.
You can also select a Profile and click Modify to configure the Profile.
The Device page for the selected Profile appears.
From the Segment drop-down menu, select a Profile segment to configure Netflow settings.
Scroll down to the Telemetry category and click the Netflow Settings area to configure Netflow details.
Figure 86. Configure Netflow settings for a Profile
1. Select the Activate Netflow check box. The Orchestrator supports IP Flow Information Export (IPFIX) protocol version 10.
2. From the Collector drop-down menu, select an existing Netflow collector to export IPFIX information directly from SD-WAN Edge, or click + New Collector to configure a new Netflow collector.
  For more information about how to add a new collector, see Configure Netflow Settings.
  
  Note: You can configure a maximum of two collectors per segment and eight collectors per Profile by clicking the + ADD button. When the number of configured collectors reaches the maximum allowable limit, the + ADD button will be deactivated.
  
  Note: Netflow version 10 is the only supported version.
3. From the Filter drop-down menu, select an existing Netflow filter for the traffic flows from SD-WAN Edge, or click + New Filter to configure a new Netflow filter.
  For more information about how to add a new filter, see Configure Netflow Settings.
  
  Note: You can configure a maximum of 16 filters per collector by clicking the + button. However, the ' Allow All' filtering rule is added implicitly at the end of the defined filter list, per collector.
4. Select the Allow All check box corresponding to a collector to allow all segment flows to that collector.
5. Under Intervals, configure the following Netflow export intervals:
  - Flow Stats - Export interval for flow stats template, which exports flow statistics to the collector. By default, netflow records of this template are exported every 60 seconds. The allowable export interval range is from 60 seconds to 300 seconds.
  - FlowLink Stats - Export interval for flow link stats template, which exports flow statistics per link to the collector. By default, netflow records of this template are exported every 60 seconds. The allowable export interval range is from 60 seconds to 300 seconds.
  - Segment Table - Export interval for Segment option template, which exports segment related information to collector. The default export interval is 300 seconds. The allowable export interval range is from 60 seconds to 300 seconds.
  - Application Table - Export interval for Application option template, which exports application information to the collector. The default export interval is 300 seconds. The allowable export interval range is from 60 seconds to 300 seconds.
  - Interface Table - Export interval for Interface option template, which exports interface information to collector. The default export interval is 300 seconds. The allowable export interval range is from 60 seconds to 300 seconds.
  - Link Table - Export interval for Link option template, which exports link information to the collector. The default export interval is 300 seconds. The allowable export interval range is from 60 seconds to 300 seconds.
  - Tunnel Stats - Export interval for tunnel stats template. By default, the statistics of the active tunnels in the edge are exported every 60 seconds. The allowable export interval range is from 60 seconds to 300 seconds.
  Note: In an Enterprise, you can configure the Netflow intervals for each template only on the Global segment. The configured Netflow export interval is applicable for all collectors of all segments on an Edge.
  For more information on various Netflow templates, see IPFIX Templates.
Click Save Changes.

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:

In the SD-WAN service of the Enterprise portal, go to Configure > Profiles .
Click the link to a Profile or click the View link in the Device column of the Profile for which you want to configure the Authentication Settings.
The configuration options for the selected Profile are displayed in the Device tab.
Scroll down to the Edge Services category and click Authentication.

Figure 87. Configure Authentication settings for a Profile
From the RADIUS Server drop-down menu, select the Radius server that you want to use for authentication.

Note: All the Radius servers that are already configured using the Authentication Services feature in the Network Services page appears in the RADIUS Server drop-down menu. Alternatively, you can configure a new authentication service by selecting the New Radius Service button. For instructions about how to configure Authentication Services, see Configure Authentication Services.
Click Save Changes.

Configure NTP Settings for Profiles

To configure an SD-WAN 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.

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.

As an Enterprise user, you can configure a time source for the SD-WAN 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 SD-WAN Edge to act as an NTP Server to its own clients.

In the SD-WAN service of the Enterprise portal, go to Configure > Profiles .
The Configure Profiles page appears.
Click the link to a Profile or click the View link in the Device column of the Profile for which you want to configure the NTP settings.
The configuration options for the selected Profile are displayed in the Device tab.
Configure the Edge's own time sources by defining Private NTP Servers. These servers could be either known time sources within your own network, or well-known time servers on the Public Internet, if they are reachable from the Edge. To define Private NTP Servers:
1. Scroll down to the Edge Services category and go to the NTP area.
  
  Figure 88. Configure NTP settings for a Profile
2. Select the Private NTP Servers check box.
3. In the Servers area, click +Add and enter the IP address of your Private NTP Server. If DNS is configured, you can use a domain name instead of an IP address. To configure another NTP Server, click the +Add button again.
  It is strongly recommended to add two or three servers to increase availability and accuracy of time setting. If you do not set Private NTP Servers, the Edge attempts to set its time from a default set of public NTP Servers, but that is not guaranteed to work, especially if the Edge cannot communicate to servers on the public Internet.
  
  Note: The Orchestrator allows you to activate the Edge to act as an NTP Server to its clients, only if you have defined Private NTP Servers.
  
  As Edge interfaces are not available at the Profile level, the Source Interface field is set to Auto. The Edge automatically selects an interface with 'Advertise' field set as the source interface.
Once you have defined Private NTP Servers, Orchestrator allows you to configure the SD-WAN Edge to act as an NTP Server for its clients:
1. Select the Edge as NTP Server check box. You can select the check box only if you have activated at least one Private NTP Server.
2. Choose the type of NTP Authentication as either None or MD5.
3. If you choose MD5, then you must configure the NTP authentication key value pair details by clicking the +Add button under the Keys area.
Click Save Changes.
The NTP configuration settings are applied to the selected Profile.

At the Edge-level, you can override the NTP settings for specific Edges. For more information, see Configure NTP Settings for Edges.

VeloCloud SD-WAN 5.2 - Administration Guide - Configure Device Settings for Profiles Print

Configure Device Settings for Profiles

Configure a Profile Device

Profile Device Configurations—A Roadmap

Assign Segments in Profile

Configure VLAN for Profiles

Configure Management IP Address for Profiles

Configure Address Resolution Protocol Timeouts for Profiles

Configure Interface Settings

Public WAN Links

Private (MPLS) WAN Links

Device Settings

Edges Without Wi-Fi Modules

Edge 610-LTE

610-LTE Troubleshooting

Edge 3810

Edge 6X0

Edge 510-LTE

User-defined WAN Overlay Use Cases

Configure Interface Settings for Profiles

Configure DSL Settings

Troubleshooting DSL Settings

Configure ADSL and VDSL Settings

Configure GPON Settings

IPv6 Settings

Mixed Environment on Edge to Edge Network

Mixed Environment on Edge to Gateway Network

Dual Stack Environment

Impact of IPv6 Tunnel on MTU

IPv6 Capability of Edge

Limitations of IPv6 Address Configuration

Management Traffic and IP Addresses

Global IPv6 Settings for Profiles

Monitor IPv6 Events

Troubleshooting IPv6 Configuration

Configure Wi-Fi Radio Settings

Configure Common Criteria Firewall Settings for Profiles

Assign Partner Gateway Handoff

Considerations When Assigning Partner Gateways

Select CDE Gateways

Assign a CDE Gateway

Assign Controllers

Configure Cloud VPN

Cloud VPN Overview

Branch to Non SD-WAN Destination via Gateway

Connect to Customer Data Center with Existing Firewall VPN Router

Iaas

Connect to CWS (Zscaler)

Branch to SD-WAN Hub

Branch to Branch VPN

Branch to Non SD-WAN Destination via Edge

Configure Cloud VPN for Profiles

Configure a Tunnel Between a Branch and SD-WAN Hubs VPN

Conditional Backhaul

Configure a Tunnel Between a Branch and a Branch VPN

Configure a Tunnel Between a Branch and a Non SD-WAN Destinations via Gateway

Configure a Tunnel Between a Branch and a Non SD-WAN Destinations via Edge

Configure Cloud Security Services for Profiles

Configure Zscaler Settings for Profiles

Configure Multicast Settings for Profiles

Configure DNS for Profiles

Activate OSPF for Profiles

Route Filters

Configure BFD for Profiles

LAN-Side NAT Rules at Profile Level

Configure BGP from Edge to Underlay Neighbors for Profiles

Configure Visibility Mode for Profiles

Configure SNMP Settings for Profiles

Configure Syslog Settings for Profiles

Syslog Message Format for Firewall Logs

Configure Netflow Settings for Profiles

Configure Authentication Settings for Profiles

Configure NTP Settings for Profiles