Login
- Released At: 16-12-2024
- Page Views:
- Downloads:
- Table of Contents
- Related Documents
-
|
|
|
AD-WAN Branch 6.5 Solution |
|
WAN Service Configuration Guide |
|
|
|
|
Document version: 5W100-20231121
Copyright © 2023 New H3C Technologies Co., Ltd. All rights reserved.
No part of this manual may be reproduced or transmitted in any form or by any means without prior written consent of New H3C Technologies Co., Ltd.
Except for the trademarks of New H3C Technologies Co., Ltd., any trademarks that may be mentioned in this document are the property of their respective owners.
The information in this document is subject to change without notice.
Contents
WebSocket management channel configuration
Interface address and underlay network parameter configuration
NAT address mapping configuration
Port permission rules by the firewall
Underlay configuration on Hub1-1
Underlay configuration on Hub1-2
Underlay configuration on Hub2
Configuration on the firewall when the firewall acts as a hub device
Configure the system and tenants
(Optional.) Configure the mail server
(Optional) Create a tenant service administrator
Configure tunnel BFD templates
Configure WAN service networks of the Internet type
Add a WAN service network of the L3VPN type
Add a WAN service network of the L2VPN type
Add a WAN service network of the VPDN type
Add or import sites and devices
Import loopback interface addresses
Manually add WAN network details
Display and maintain the deployment state
View the deployment state of sites
View the deployment state of WAN details
View and maintain underlay links
View and maintain the deployment state of tunnels
Configure VPDN VT interfaces and L2TP groups
Manually configure other VPDN configurations
Importing NTP settings in bulk
Deploy a VPN and view its state
Add a hub-spoke area topology with branch connectivity
Add a hub-spoke area topology without branch connectivity
Add a topology policy for a hub-spoke area topology with branch connectivity
Add a topology policy for a hub-spoke area topology without branch connectivity
Add a topology policy for a full-mesh area topology
Add LAN service network details
Import LAN service network details
Manually add LAN service network details
Overlay link O&M and topology search
Manually deploy configuration and check status
Optimize static route configuration
Check for configuration that affects features
Manual configuration on the firewall
Configure route redistribution
Configure routing settings on the LAN side
Redistribute overlay routes into the LAN
Configure route synchronization
Display configuration deployment status
Application group traffic engineering and visibility
Configure branch network application groups
Configure rate limit for WAN interfaces
Configure application assurance for WAN interfaces
Configure overlay link (TTE connection) based rate limit and application assurance
Configure priority queue-based assurance for WAN interfaces
Basic and extended O&M features
Edit homepage map settings and configure site locations
Topology visualization and management
Device visualization and management
Link visualization and management
Role-based permission configuration
Configure permissions and domains
Upload device software version to be upgraded
Backup restoration and replacement
Back up device configuration manually
Site Internet access configuration
Access the capacity management page
Configure scheduled sync of resource usage information
Block deployment upon threshold violations
Overview
The controller in the AD-WAN branch 6.5 solution supports automated branch network deployment and WAN service deployment. This document describes how to configure the preceding services and contains the following contents:
· Device onboarding planning—Describes the procedure of automated device registration and onboarding.
· Branch network planning—Describes the network planning and VPN service settings for the branch EVPN solution.
· Application TE settings—Describes the procedure of deploying TE-related functions and QoS services.
· Basic and extended O&M features—Describes basic and extended O&M features, including the dashboard, basic visualized O&M, alarm settings, and Internet access from sites.
Plan the networks
Network diagram
Figure 1 Network diagram for WAN service configuration
Network configuration
Site network configuration
|
|
CAUTION: · To use WAN optimization or RBM in the dual-gateway scenario, make sure the interconnect interfaces are physical interfaces and are directly connected (not connected over a Layer 3 network). · For compatibility with the SDWAN solution, the firewall does not support the dual-gateway site network. To ensure high availability, you can use the IRF network. · For compatibility with the SDWAN solution, the firewall does not support Reth interfaces. To ensure high availability, you can use aggregate Interfaces. |
· HQ1: HQ site. It is a dual-gateway site, and the site role is RR&CPE.
· HQ2: HQ site. It is a standalone device, and the site role is RR&CPE.
· Branch1: Level-2 branch site (distribution site). It is a dual-gateway site, and the site role is RR&CPE.
· Branch2: Level-2 branch site (distribution site). It is a standalone device, and the site role is RR&CPE.
· Branch3: Level-2 branch site without level-3 sites attached. It is a standalone device, and the site role is CPE.
· Branch4: Level-3 branch site. It is a dual-gateway site, and the site role is CPE.
· Branch5: Level-3 branch site. It is a standalone device, and the site role is CPE.
WAN network configuration
· HQ1: Connects to the Internet through Layer 3 firewall NAT. The public address of the site is configured on the firewall. NAT maps the private addresses and service ports of the controller and hub devices to the Internet. Hub1-2 accesses an L3VPN, and uses BGP to ensure connectivity. Because the AS number of SDWAN is different from the AS number of the underlay network, you must use the fake AS feature.
· HQ2: HQ2 accesses the Internet directly by using a fixed address. HQ2 accesses an L3VPN, and uses OSPF to ensure connectivity. HQ2 acts as an LNS to access the VPDN network.
· Branch1: Branch1 accesses HQ1 through an L2VPN, and uses OSPF to ensure connectivity. Spoke1-2 accesses an L3VPN and uses OSPF to ensure connectivity.
· Branch2: Branch2 accesses the Internet through two egresses, and uses fixed public network addresses because it is a distribution site. Branch2 accesses an L3VPN, and uses OSPF to ensure connectivity.
· Branch3: Branch3 accesses the Internet, uses DHCP to obtain a private network address, and translates the source address into a public network address through carrier-grade NAT. Branch3 accesses an L3VPN, and uses OSPF to ensure connectivity. Branch3 accesses the VPDN network through PPPoE dial-up because it cannot simulate 5G dial-up.
· Branch4: Branch4 accesses Branch2 through an L2VPN, and uses OSPF to ensure connectivity. Spoke4-2 accesses an L3VPN and uses OSPF to ensure connectivity.
· Branch5: Branch5 accesses the Internet, uses PPPoE to obtain a private network address, and translates the source address into a public network address through carrier-grade NAT. Branch5 accesses an L3VPN, and uses OSPF to ensure connectivity.
|
|
CAUTION: HQ and distribution sites (RRs) must have fixed public network addresses. To establish a directly-connected tunnel between branches, make sure the branch on at least one end has a fixed public network address. You can configure an IP address on the HQ device or firewall as the public address. If you configure an IP address on the firewall as the public address, configure NAT to map the private addresses and service ports of the hub devices to the Internet. The following NAT modes are supported: · Static NAT—Configure static NAT mappings between the private addresses and public addresses to ensure one-to-one mappings between the private addresses of hub devices and public addresses. · Port mapping—Configure one-to-one mappings between private addresses+service ports and public addresses+service ports. The service port numbers cannot be changed during the NAT translation process. This configuration can achieve the following purposes: ¡ When the private network accesses the public network, the source private address+service port can be translated to the corresponding source public address+service port. ¡ When the public network accesses the private network, the destination public address+service port can be translated to the corresponding destination private address+service port. |
LAN network configuration
|
|
CAUTION: · For a dual-gateway site, if it accesses the LAN network through VRRP or static routes, you must add an interconnect link (which can use subinterfaces) to each service VPN and configure OSPF for route synchronization. If you do not do that, path switchover might fail to be performed after link failure. For more information, see "Configure route synchronization." · A hub device uses two OSPF processes that belong to the public network and VPN, respectively to establish OSPF neighbor relationships with LAN 1. To avoid routing issues, you must configure different router IDs for the two processes. As a best practice, use the global router ID for the OSPF process that belongs to the public network and assign another router ID to the OSPF process that belongs to the VPN. |
· HQ1: Because the controller is deployed on the internal network, two hub devices must use two interfaces (management interface and LAN interface) to connect to LAN1. The management interface is not bound to a VPN instance, and uses OSPF to connect to LAN1. The interface mainly provides the management channel to the controller. The LAN interface is bound to a VPN instance, and uses OSPF to connect to LAN1. The interface is mainly used for service traffic forwarding. The LAN interface uses OSPF to learn internal network routes, redistributes them to BGP, and advertises them to the branch. The branch routes learned from BGP are redistributed to OSPF and then advertised to LAN1 through OSPF.
· HQ2: Because the controller is deployed on the internal network, Hub2 must use two interfaces (management interface and LAN interface) separately to connect to LAN2. The management interface is not bound to a VPN instance, and uses OSPF to connect to LAN2. The interface mainly provides the management channel to the controller. The LAN interface is bound to a VPN instance, and uses OSPF to connect to LAN2. The interface is mainly used for service traffic forwarding. The LAN interface uses OSPF to learn internal network routes, redistributes them to BGP, and advertises them to the branch. The branch routes learned from BGP are redistributed to OSPF and then advertised to LAN2 through OSPF.
· Branch1: VRRP is configured for the LAN interfaces of the dual-gateway site. The gateway for internal endpoints is configured as the VRRP virtual address, and you must add a route interconnect interface for route synchronization.
· Branch2: A single LAN interface is used to access the LAN network.
· Branch3: A single LAN interface is used to access the LAN network.
· Branch4: VRRP is configured for the LAN interfaces of the dual-gateway site. The gateway for internal endpoints is configured as the VRRP virtual address, and you must add a route interconnect interface for route synchronization.
· Branch5: A single LAN interface is used to access the LAN network.
WebSocket management channel configuration
· HQ1 and HQ2: The controller is deployed on the internal network. Hub devices use management interfaces to connect to LAN1, and register and come online through the management interfaces.
· Branch1: Spoke1-1 uses an L2VPN interface to configure the underlay route to the controller and registers and comes online through the L2VPN interface. Spoke1-2 supports the following two registration modes:
¡ Use an L2VPN interface to configure the underlay route to the controller and register and come online through the L2VPN interface.
¡ Use an L3VPN interface to configure the underlay route to the controller and register and come online through the L3VPN interface.
· Branch2: The following two registration modes are supported:
¡ Register through the Internet interface. The registration address is the public address (the mapping port is TCP 19443) that is translated from the northbound virtual address of the controller by device NAT of HQ1.
¡ Use an L3VPN interface to configure the underlay route to the controller, and register and come online through the L3VPN interface.
· Branch3: The following two registration modes are supported:
¡ Register through the Internet interface. The registration address is the public address (the mapping port is TCP 19443) that is translated from the northbound virtual address of the controller by device NAT of HQ1.
¡ Use an L3VPN interface to configure the underlay route to the controller, and register and come online through the L3VPN interface.
· Branch4: Spoke4-1 uses an L2VPN interface to configure the underlay route to the controller and registers and comes online through the L2VPN interface. Spoke4-2 supports the following two registration modes:
¡ Use an L2VPN interface to configure the underlay route to the controller and register and come online through the L2VPN interface.
¡ Use an L3VPN interface to configure the underlay route to the controller and register and come online through the L3VPN interface.
· Branch5: The following two registration modes are supported:
¡ Register through the Internet interface. The registration address is the public address (the mapping port is TCP 19443) that is translated from the northbound virtual address of the controller by device NAT of HQ1.
¡ Use an L3VPN interface to configure the underlay route to the controller, and register and come online through the L3VPN interface.
Access zone planning
The network model is a three-tier network, and requires multiple access zones. The access zone planning is as follows:
· zone1: Site HQ1 acts as the RR, and level-2 sites Branch1, Branch2, and Branch3 access this access zone. For a single-HQ two-tier network, you only need to plan access zone zone1.
· zone2: Site HQ2 acts as the RR, and level-2 sites Branch1, Branch2, and Branch3 access this access zone. For a dual-HQ two-tier network, you must plan access zones zone1 and zone2.
· zone3: Level-2 distribution site Branch1 acts as the RR, and the attached level-3 site Branch4 accesses this access zone.
· zone4: Level-2 distribution site Branch2 acts as the RR, and the attached level-3 site Branch5 accesses this access zone.
Area topology planning
For each access zone, you must create an area topology for the service VPN. As a best practice, include all sites that have the corresponding VPN deployed in the access zone.
Dual-HQ area topology planning:
· topo1: Create an area topology corresponding to access zone zone1, with the area RR as HQ1. Configure branch sites Branch1, Branch2, and Branch3 to access the topology. To specify the preferred area topology policy for the level-2 sites in the dual-HQ site network, configure the local priority as 200 in the area topology when the branch sites are connected. Then, the area topology is preferentially selected for inter-branch connectivity.
· topo2: Create an area topology corresponding to access zone zone2, with the area RR as HQ2. Configure branch sites Branch1, Branch2, and Branch3 to access the topology. To specify the preferred area topology policy for the level-2 sites in the dual-HQ site network, do not modify the local priority (100 by default) in the area topology when the branch sites are connected. Then, the area topology acts as a backup for inter-branch connectivity.
If both topo1 and topo2 are configured with the Hub-Spoke model, inter-branch communication will preferentially select HQ site HQ1 in topo1. When the HQ site or RR in topo1 fails, the key site HQ2 in topo2 will take over. As a best practice, advertise different detailed routes for two HQs. If the same routes are advertised, HQ1 will be given priority.
Level-2 distribution site area planning:
· topo3: Create an area topology corresponding to access zone zone3, with the area RR as Branch1. Configure branch site Branch4 to access this topology.
· topo4: Create an area topology corresponding to access zone zone4, with the area RR as Branch2. Configure branch site Branch5 to access this topology.
Area interconnect planning
The area topology enables intra-area connectivity, while inter-area connectivity requires specifying border sites to facilitate traffic forwarding. The border sites must belong to two area topologies.
For a three-tier network, you must configure area interconnects. The area interconnect plan is as follows.
· Configure the border site as Branch1 between area topologies topo1 and topo3.
· Configure the border site as Branch1 between area topologies topo2 and topo3.
· Configure the border site as Branch2 between area topologies topo1 and topo4.
· Configure the border site as Branch2 between area topologies topo2 and topo4.
No direct connection exists between area topologies topo3 and topo4, so you do not need to create an area interconnect for them. Area topologies topo3 and topo4 communicate through topo1 and topo2.
Interface address and underlay network parameter configuration
Table 1 shows the addresses planned for interfaces on devices.
Table 1 Device node address planning
|
Device |
Interface |
Interface address |
Peer device |
Peer interface |
Peer address |
Remarks |
|
Hub1-1 |
GE2/0.1 |
172.1.1.1/24 |
LAN1 |
|
172.1.1.2 |
Management network |
|
GE2/0.2 |
20.1.10.2/24 2000:2::2/64 |
LAN1 |
|
20.1.10.1 2000:2::1 |
LAN interface in VPN1 |
|
|
GE3/0 |
30.1.1.1/24 |
Hub1-2 |
GE3/0 |
30.1.1.2 |
Horizontal link |
|
|
GE4/0 |
172.1.3.1/24 |
NAT |
GE2/0 |
17.1.3.2 |
Internet link |
|
|
GE5/0 |
172.1.5.1/24 |
Spoke1-1 |
GE3/0 |
172.1.5.2 |
L2VPN |
|
|
Hub1-2 |
GE2/0.1 |
172.1.2.1/24 |
LAN1 |
|
172.1.2.2 |
Management network |
|
GE2/0.2 |
20.1.11.2/24 2000:3::2/64 |
LAN1 |
|
20.1.11.1 2000:3::1 |
LAN interface in VPN1 |
|
|
GE3/0 |
30.1.1.2 |
Hub1-1 |
GE3/0 |
30.1.1.1 |
Horizontal link |
|
|
GE4/0 |
172.1.4.1/24 |
NAT |
GE3/0 |
17.1.4.2 |
Internet link |
|
|
GE5/0 |
172.1.6.1/24 |
Spoke2-1 |
GE3/0 |
172.1.6.2 |
L2VPN |
|
|
GE6/0 |
173.1.1.1/24 |
MPLS |
|
173.1.1.2 |
L3VPN |
|
|
NAT |
GE2/0 |
172.1.3.2/24 |
Hub1-1 |
GE4/0 |
172.1.3.1 |
|
|
GE3/0 |
172.1.4.2/24 |
Hub1-2 |
GE4/0 |
172.1.4.1 |
|
|
|
GE4/0 |
110.1.1.1/24 |
Internet |
|
110.1.1.2 |
Public egress to Internet |
|
|
GE5/0 |
110.1.2.1/24 |
Internet |
|
110.1.2.2 |
Public egress to Internet |
|
|
Hub2 |
GE2/0.1 |
172.1.10.1/24 |
LAN2 |
|
172.1.10.2 |
Management network |
|
GE2/0.2 |
20.1.20.2/24 2000:4::2/64 |
LAN2 |
|
20.1.20.1 2000:4::1 |
LAN interface in VPN1 |
|
|
GE3/0 |
173.1.4.1/24 |
MPLS |
|
173.1.4.2 |
L3VPN |
|
|
GE4/0 |
110.1.3.1/24 |
Internet |
|
110.1.3.2 |
Internet link |
|
|
GE5/0 |
174.1.1.1/24 |
VPDN |
|
174.1.1.2 |
VPDN network |
|
|
Spoke1-1 |
GE2/0 |
20.1.2.2/24 2001::2/64 |
LAN3 |
|
|
LAN interface in VPN1 VRRP (master) 20.1.2.1 2001::1 |
|
GE3/0 |
172.1.5.2/24 |
Hub1-1 |
GE3/0 |
172.1.5.1 |
L2VPN |
|
|
GE4/0 |
30.1.2.1/24 |
Spoke1-2 |
GE4/0 |
30.1.2.2 |
Horizontal link |
|
|
GE4/0.1 |
20.2.21.1/24 2001:2::1/64 |
Spoke1-2 |
GE4/0.1 |
20.2.21.2 2001:2::2 |
LAN interface in VPN1 Horizontal route synchronization |
|
|
GE5/0 |
172.1.5.1/24 |
Spoke4-2 |
GE3/0 |
172.1.5.2 |
L2VPN |
|
|
GE6/0 |
172.1.7.1/24 |
Spoke4-1 |
GE3/0 |
172.1.7.2 |
L2VPN |
|
|
Spoke1-2 |
GE2/0 |
20.1.2.3/24 2001::3/64 |
LAN3 |
|
|
LAN interface in VPN1 VRRP (backup) 20.1.2.1 2001::1 |
|
GE3/0 |
172.1.6.2/24 |
Hub1-2 |
GE3/0 |
172.1.6.1 |
L2VPN |
|
|
GE4/0 |
30.1.2.2/24 |
Spoke1-1 |
GE4/0 |
30.1.2.1 |
Horizontal link |
|
|
GE4/0.1 |
20.2.21.2/24 2001:2::2/64 |
Spoke1-1 |
GE0/1.1 |
20.2.21.1 2001:2::1 |
LAN interface in VPN1 Horizontal route synchronization |
|
|
GE5/0 |
11.1.6.2/24 |
Hub1-2 |
GE3/0 |
11.1.6.1 |
L2VPN |
|
|
GE5/0 |
172.1.8.1/24 |
Spoke4-2 |
GE3/0 |
172.1.8.2 |
L2VPN |
|
|
GE6/0 |
173.1.2.1/24 |
MPLS |
|
173.1.2.2 |
L3VPN |
|
|
Spoke2 |
GE2/0 |
20.1.3.1/24 2002::1/64 |
LAN4 |
|
|
|
|
GE3/0 |
173.1.5.1/24 |
MPLS |
|
173.1.5.2 |
L3VPN |
|
|
GE4/0 |
110.1.4.1/24 |
Internet |
|
110.1.4.2 |
Private network over Internet |
|
|
GE5/0 |
110.1.7.1/24 |
Internet |
|
110.1.7.2 |
Private network over Internet |
|
|
Spoke3 |
GE2/0 |
20.1.4.1/24 2003::1/24 |
LAN5 |
|
|
LAN interface in VPN1 |
|
GE3/0 |
173.1.6.1/24 |
MPLS |
|
173.1.6.2 |
L3VPN |
|
|
GE4/0 |
DHCP |
Internet |
|
|
Private network over Internet |
|
|
GE5/0 |
Dialer1 |
VPDN |
|
|
VPDN network |
|
|
Spoke4-1 |
GE2/0 |
20.1.5.2/24 2004::2/64 |
LAN6 |
|
|
LAN interface in VPN1 VRRP (master) 20.1.5.1 2004::1 |
|
GE3/0 |
172.1.7.2/24 |
Spoke1-1 |
GE3/0 |
172.1.5.1 |
L2VPN |
|
|
GE4/0 |
30.1.3.1/24 |
Spoke4-2 |
GE4/0 |
30.1.3.2 |
Horizontal link |
|
|
GE4/0.1 |
20.2.22.1/24 2001:3::1/64 |
Spoke4-2 |
GE4/0.1 |
20.2.22.2 2001:3::2 |
LAN interface in VPN1 Horizontal route synchronization |
|
|
Spoke4-2 |
GE2/0 |
20.1.5.3/24 2004::3/64 |
LAN6 |
|
|
LAN interface in VPN1 VRRP (master) 20.1.5.1 2004::1 |
|
GE3/0 |
172.1.8.2/24 |
Spoke1-2 |
GE3/0 |
172.1.8.1 |
L2VPN |
|
|
GE4/0 |
30.1.3.2/24 |
Spoke4-1 |
GE4/0 |
30.1.3.1 |
Horizontal link |
|
|
GE4/0.1 |
20.2.22.2/24 2001:3::2/64 |
Spoke4-1 |
GE4/0.1 |
20.2.22.1 2001:3::1 |
LAN interface in VPN1 Horizontal route synchronization |
|
|
GE5/0 |
173.1.3.1 |
MPLS |
|
173.1.3.2 |
L3VPN |
|
|
Spoke5 |
GE2/0 |
20.1.6.1/24 2005::1/24 |
LAN7 |
|
|
LAN interface in VPN1 |
|
GE3/0 |
173.1.7.1/24 |
MPLS |
|
173.1.7.2 |
L3VPN |
|
|
GE4/0 |
Dialer1 |
Internet |
|
|
Private network over Internet |
NAT address mapping configuration
NAT uses port mapping to map private IP addresses + ports to the corresponding public IP addresses + ports. See Table 2 for the NAT mappings.
Table 2 NAT mappings
|
Feature |
Device |
Interface |
Protocol |
External address: Port |
Internal address: Port |
Remarks |
|
Controller mapping |
NAT |
GE4/0 |
TCP |
110.1.1.1: 19443 |
Northbound virtual address of the controller: 19443 |
Registration via Websocket |
|
TCP |
110.1.1.1: 35000 |
Northbound virtual address of the controller: 35000 |
Device configuration backup and upgrade |
|||
|
GE5/0 |
TCP |
110.1.2.1: 19443 |
Northbound virtual address of the controller: 19443 |
Registration via Websocket |
||
|
TCP |
110.1.2.1: 35000 |
Northbound virtual address of the controller: 35000 |
Device configuration backup and upgrade |
|||
|
HQ device mapping |
GE4/0 |
TCP |
110.1.2.1: 2004 |
172.1.3.1: 2004 |
SSL connection setup between CPE and RR The default port number is 2004. You can manually specify a port number. |
|
|
UDP |
110.1.1.1: 4799 |
172.1.3.1: 4799 |
Default SDWAN tunnel encapsulation port mapping |
|||
|
UDP |
110.1.1.1: 12288 |
172.1.3.1: 12288 |
Group ID-based SDWAN tunnel encapsulation port mapping |
|||
|
UDP |
110.1.1.1: 12289 |
172.1.3.1: 12289 |
Group ID-based SDWAN tunnel encapsulation port mapping |
|||
|
UDP |
110.1.1.1: 12290 |
172.1.3.1: 12290 |
Group ID-based SDWAN tunnel encapsulation port mapping |
|||
|
UDP |
110.1.1.1: 12291 |
172.1.3.1: 12291 |
Group ID-based SDWAN tunnel encapsulation port mapping |
|||
|
GE5/0 |
TCP |
110.1.2.1: 2004 |
172.1.4.1: 2004 |
SSL connection setup between CPE and RR The default port number is 2004. You can manually specify a port number. |
||
|
UDP |
110.1.2.1: 4799 |
172.1.4.1: 4799 |
Default SDWAN tunnel encapsulation port mapping |
|||
|
UDP |
110.1.2.1: 12288 |
172.1.4.1: 12288 |
Group ID-based SDWAN tunnel encapsulation port mapping |
|||
|
UDP |
110.1.2.1: 12289 |
172.1.4.1: 12289 |
Group ID-based SDWAN tunnel encapsulation port mapping |
|||
|
UDP |
110.1.2.1: 12290 |
172.1.4.1: 12290 |
Group ID-based SDWAN tunnel encapsulation port mapping |
|||
|
UDP |
110.1.2.1: 12291 |
172.1.4.1: 12291 |
Group ID-based SDWAN tunnel encapsulation port mapping |
|
|
CAUTION: If you configure NAT for the firewall at the HQ, configure one-to-one mappings between private addresses+service ports and public addresses+service ports for the firewall. The service port numbers cannot be changed during the NAT translation process. This configuration can achieve the following purposes: · When the private network accesses the public network, the source private address+service port can be translated to the corresponding source public address+service port. · When the public network accesses the private network, the destination public address+service port can be translated to the corresponding destination private address+service port. |
Key NAT configuration:
#
interface GigabitEthernet4/0
port link-mode route
ip address 110.1.1.1 255.255.255.0
ip last-hop hold
nat server protocol tcp global current-interface 2004 inside 172.1.3.1 2004 reversible
nat server protocol tcp global current-interface 19443 inside 192.168.40.155 19443
nat server protocol tcp global current-interface 35000 inside 192.168.40.155 35000
nat server protocol udp global current-interface 4799 inside 172.1.3.1 4799 reversible //You must specify the reversible keyword for bidirectional address translation
nat server protocol udp global current-interface 12288 inside 172.1.3.1 12288 reversible //You must specify the reversible keyword for bidirectional address translation
nat server protocol udp global current-interface 12289 inside 172.1.3.1 12289 reversible //You must specify the reversible keyword for bidirectional address translation
nat server protocol udp global current-interface 12290 inside 172.1.3.1 12290 reversible //You must specify the reversible keyword for bidirectional address translation
nat server protocol udp global current-interface 12291 inside 172.1.3.1 12291 reversible //You must specify the reversible keyword for bidirectional address translation
#
interface GigabitEthernet5/0
port link-mode route
ip address 110.1.2.1 255.255.255.0
ip last-hop hold
nat server protocol tcp global current-interface 2004 inside 172.1.4.1 2004 reversible
nat server protocol tcp global current-interface 19443 inside 192.168.40.155 19443
nat server protocol tcp global current-interface 35000 inside 192.168.40.155 35000
nat server protocol udp global current-interface 4799 inside 172.1.4.1 4799 reversible //You must specify the reversible keyword for bidirectional address translation
nat server protocol udp global current-interface 12288 inside 172.1.4.1 12288 reversible //You must specify the reversible keyword for bidirectional address translation
nat server protocol udp global current-interface 12289 inside 172.1.4.1 12289 reversible //You must specify the reversible keyword for bidirectional address translation
nat server protocol udp global current-interface 12290 inside 172.1.4.1 12290 reversible //You must specify the reversible keyword for bidirectional address translation
nat server protocol udp global current-interface 12291 inside 172.1.4.1 12291 reversible //You must specify the reversible keyword for bidirectional address translation
#
Port permission rules by the firewall
If a firewall is deployed between a device and the controller, you must permit specific service ports to ensure incorporation of the device by the controller.
Table 3 Permitted ports between the controller and devices
|
Protocol |
Source IP |
Source port |
Destination IP |
Destination port |
Remarks |
|
TCP |
Device registration interface IP |
Any |
Controller northbound IP |
19443 |
This port is used for device registration through WebSocket. |
|
TCP |
Device registration interface IP |
Any |
Controller northbound IP |
35000 |
This port is used for device software upgrade. |
|
UDP |
Server node IP+northbound IP |
Any |
Device management IP |
161 |
To use SNMP, you must permit the access port of the SNMP network management service. |
|
UDP |
Device management IP |
Any |
Controller northbound IP |
162 |
To use SNMP, you must permit the access port of the SNMP network management service. |
|
UDP |
Source address for NTP synchronization on the device |
Any |
Unified northbound address for the controller |
123 |
If you synchronize the NTP time from the controller, you must permit the NTP server port. |
If a firewall is deployed between a CPE and an RR, you must permit specific ports to ensure that an overlay link (TTE connection) can be established correctly.
Table 4 Permitted ports between RRs and CPEs
|
Protocol |
Source IP |
Source port |
Destination IP |
Destination port |
Remarks |
|
TCP |
CPE WAN interface IP Any |
Any |
RR WAN interface IP |
2004 |
This port is used by the TLS connection. You can edit the port as needed. For more information, see "Configure basic settings." |
|
UDP |
CPE WAN interface IP Any |
4799 Any |
RR WAN interface IP |
4799 |
Port number used by the default plane. If the default plane is used, you must permit the port. If a CPE uses a private address and that private address is translated to a public address to communicate with an RR, the source IP and port might change and they must match the any rule. If a CPE uses a private address and that private address is translated to a public address to communicate with an RR, the source IP and port might change and they must match the any rule. |
|
UDP |
CPE WAN interface IP Any |
12288 to 12543 Any |
RR WAN interface IP |
12288 to 12543 |
This port is used by a custom service plane. The source and destination ports to be permitted must be the same. For more information about custom service planes, see "Configure WAN networks." If a CPE uses a private address and that private address is translated to a public address to communicate with an RR, the source IP and port might change and they must match the any rule. |
|
UDP |
RR WAN interface IP |
4799 |
CPE WAN interface IP |
4799 |
Port number used by the default plane. If the default plane is used, you must permit the port. If a CPE uses a public address, the RR will actively perform TTE negotiation. In this case, you must also permit the port. |
|
UDP |
RR WAN interface IP |
12288 to 12543 |
CPE WAN interface IP |
12288 to 12543 |
This port is used by a custom service plane. The source and destination ports to be permitted must be the same. For more information about custom service planes, see "Configure WAN networks." If a CPE uses a public address, the RR will actively perform TTE negotiation. In this case, you must also permit the port. |
If a connection needs to be set up between CPE1 and CPE 2 and a firewall is deployed between them, you must permit specific ports to ensure that an overlay link (TTE connection) can be established correctly.
Table 5 Permitted ports between CPEs
|
Protocol |
Source IP |
Source port |
Destination IP |
Destination port |
Remarks |
|
UDP |
WAN interface IP of CPE1 Any |
4799 Any |
WAN interface IP of CPE2 |
4799 |
Port number used by the default plane. If the default plane is used, you must permit the port. If CPE1 uses a private address and that private address is translated to a public address to communicate with CPE2, the source IP and port might change and they must match the any rule. |
|
UDP |
WAN interface IP of CPE1 Any |
12288 to 12543 Any |
WAN interface IP of CPE2 |
12288 to 12543 |
This port is used by a custom service plane. The source and destination ports to be permitted must be the same. For more information about custom service planes, see "Configure WAN networks." Make sure one end of CPE1 and CPE2 uses a fixed public address. If CPE1 uses a private address and that private address is translated to a public address to communicate with CPE2, the source IP and port might change and they must match the any rule. |
|
UDP |
WAN interface IP of CPE2 |
4799 |
WAN interface IP of CPE1 |
4799 |
Port number used by the default plane. If the default plane is used, you must permit the port. If both CPE1 and CPE2 use fixed public addresses, both sides will actively perform TTE negotiation. In this case, you must also permit the port for backward packets. |
|
UDP |
WAN interface IP of CPE2 |
12288 to 12543 Any |
WAN interface IP of CPE1 |
12288 to 12543 |
This port is used by a custom service plane. The source and destination ports to be permitted must be the same. For more information about custom service planes, see "Configure WAN networks." If both CPE1 and CPE2 use public addresses, both sides will actively perform TTE negotiation. In this case, you must also permit the port for backward packets. |
Resource pool planning
Before automated branch device deployment, you must plan the network to request the resource pools for the network as shown in Table 6.
Table 6 Resource pool planning
|
Address pool |
Addresses required |
Address pool plan |
|
System IP pool |
System IP addresses can be automatically allocated from the address pool or manually specified. Each device must have one system IP address allocated or specified. The number of addresses required is the actual number of devices. |
Assume that 10 devices will be deployed. The address pool must contain more than 10 addresses. Address pool: 6.1.1.1 to 6.1.1.255 Mask length: 24 |
|
|
CAUTION: All resource pools support expansion. As a best practice, make sure the initial deployment of the resource pools meets the current network requirements. |
Initial device configuration
Typically, HQ devices come online through manual deployment. You must manually configure the underlay network.
|
|
CAUTION: Before a device comes online, do not add the configuration that the controller will deploy, for example, RIR configuration and SDWAN configuration. If the device has related configurations (for example, if the device has been incorporated by the controller), you must first clear related configurations and then onboard the device. |
Underlay configuration on Hub1-1
Interface configuration
#
interface GigabitEthernet2/0.1 //Configure the management interface address
port link-mode route
port link-mode route
ip address 172.1.1.2 255.255.255.0
ospf cost 10
vlan-type dot1q vid 201
#
interface GigabitEthernet4/0 //Configure the L2VPN interface
port link-mode route
ip address 172.1.3.1 255.255.255.0
ospf cost 100
#
interface GigabitEthernet3/4/3 //Configure the firewall interconnect interface
port link-mode route
ip address 172.1.5.1 255.255.255.0
#
Routing configuration
#
ospf 1 router-id 172.1.1.2 //Management network, L2VPN, and route to the firewall
area 0.0.0.0
network 172.1.1.2 0.0.0.0
network 172.1.3.1 0.0.0.0
area 0.0.0.10
network 172.1.5.1 0.0.0.0
#
Configuration of registration via Websocket
#
dns proxy enable
#
cloud-management server domain 192.168.40.155 //Configuration of registration via WebSocket
cloud-management keepalive 60
#
NTP configuration
For manual deployment, you can manually add NTP-related configurations. As a best practice, synchronize the time from the controller to the HQ devices. The related configuration is as follows:
#
#
clock protocol ntp mdc 1 //You must specify an MDC ID on an SR66 device
clock protocol ntp //You do not need to specify an MDC ID on an MSR or VSR device
#
tp-service enable
ntp-service unicast-server 192.168.40.155
#
Underlay configuration on Hub1-2
Interface configuration
#
interface GigabitEthernet2/0.1 //Configure the management interface address
port link-mode route
ip address 172.1.2.2 255.255.255.0
ospf cost 20
vlan-type dot1q vid 202
#
interface GigabitEthernet4/0 //Configure the L2VPN interface
port link-mode route
ip address 172.1.4.1 255.255.255.0
ospf cost 100
#
interface GigabitEthernet5/0 //Firewall interconnect interface
port link-mode route
ip address 172.1.6.1 255.255.255.0
#
Do not manually deploy the L3VPN access interface configuration. Later, you can deploy the configuration through WebSocket by the controller.
Routing configuration
#
ospf 1 router-id 172.1.2.2 //Management network, L2VPN, and route to the firewall
area 0.0.0.0
network 172.1.2.2 0.0.0.0
network 172.1.4.1 0.0.0.0
area 0.0.0.10
network 172.1.5.1 0.0.0.0
#
Do not manually deploy the L3VPN access route configuration. Later, you can deploy the configuration (including the fake AS configuration) through WebSocket by the controller.
Configuration of registration via Websocket
#
dns proxy enable
#
cloud-management server domain 192.168.40.155 //Configuration of registration via WebSocket
cloud-management keepalive 60
#
NTP configuration
For manual deployment, you can manually add NTP-related configurations. As a best practice, synchronize the time from the controller to the HQ devices. The related configuration is as follows:
#
clock protocol ntp mdc 1 //You must specify an MDC on SR66 devices
clock protocol ntp //You do not need to specify an MDC on MSR and VSR devices
#
ntp-service enable
ntp-service unicast-server 192.168.40.155
#
Underlay configuration on Hub2
Interface configuration
#
interface GigabitEthernet2/0.1 //Configure the management interface address
port link-mode route
ip address 172.1.10.2 255.255.255.0
vlan-type dot1q vid 203
#
interface GigabitEthernet3/0 //L3VPN interface
port link-mode route
ip address 173.1.4.1 255.255.255.0
#
interface GigabitEthernet4/0 //Internet interface
port link-mode route
ip address 110.1.3.1 255.255.255.0
#
interface GigabitEthernet5/0 // VPDN access
port link-mode route
ip address 174.1.1.1 255.255.255.0
#
Route configuration
#
ip route-static 0.0.0.0 0 110.1.3.2 //Static route for network access
#
ospf 1 router-id 172.1.10.1 //Route to the management network
area 0.0.0.0
network 172.1.10.2 0.0.0.0
#
ospf 2 router-id 173.1.4.1 //Route to L3VPN
area 0.0.0.0
network 173.1.4.1 0.0.0.0
#
Configuration of registration via Websocket
#
dns proxy enable
#
cloud-management server domain 192.168.40.155 //Configuration of registration via WebSocket
cloud-management keepalive 60
#
NTP settings
For manual deployment, you can manually add NTP-related configurations. As a best practice, synchronize the time from the controller to the HQ devices. The related configuration is as follows:
#
clock protocol ntp mdc 1 //You must specify an MDC ID on an SR66 device
clock protocol ntp //You do not need to specify an MDC ID on an MSR or VSR device
#
tp-service enable
ntp-service unicast-server 192.168.40.155
#
Configuration on the firewall when the firewall acts as a hub device
Manually configure the following settings for the firewall except for interface, routing, and WebSocket registration settings.
Security policy configuration
For devices to communicate with the controller, you must configure base security policies on the firewall. Devices at the HQ might onboard through a LAN interface or WAN interface at deployment. Configure security policies to ensure that devices at the HQ can register through a LAN or WAN interface.
#
security-zone name AdwanTrust
import interface GigabitEthernet3/4/0 //LAN interface
#
security-zone name AdwanUntrustPublic
import interface GigabitEthernet3/4/2 //WAN interface
import interface GigabitEthernet3/4/3
import ip 192.168.40.155 32 //Add the WebSocket registration address (unified northbound address or mapped public address) to avoid device disconnection when the interface changes.
#
security-policy ip
rule 61001 name sdwan-out //Apply the policy in the outbound direction to the devices
action pass
counting enable
source-zone Local
destination-zone AdwanUntrustPublic
rule 61002 name sdwan-in //Apply the policy in the inbound direction to the devices
action pass
counting enable
source-zone AdwanUntrustPublic
destination-zone Local
#
NTP configuration
For manual deployment, you can manually add NTP-related configurations. As a best practice, synchronize the time from the controller to the HQ devices. The related configuration is as follows.
#
clock protocol ntp //VFW and firewall models lower than F1000-AI-25 do not support contexts
clock protocol ntp context 1 //You must specify a context ID on firewalls of F1000-AI-25 and higher models. In the current software version, only context 1 is supported.
#
ntp-service enable
ntp-service unicast-server 192.168.40.155
#
Configure the system and tenants
Log in to Unified Platform
After the controller is installed, the tenant named System will be automatically created. Use the default system management group account (admin) of the tenant to log in to the controller as follows:
1. In the address bar of the browser, enter the login address (the default is http://ip_address:30000/central) and press Enter.
The login page as shown in Figure 2 opens. The ip_address parameter specifies the northbound service VIP of Unified Platform, and 30000 specifies the port number.
2. Enter the operator's username and password.
The default password is Pwd@12345. You can perform service configuration by using the user or logging in as a manually created tenant service administrator.
Figure 2 Unified Platform login page
(Optional.) Configure the mail server
To perform deployment via email, you must send alarm messages via mails. Therefore, you must first configure the mail server. Skip this step if you do not perform deployment via email.
1. Log in to Unified Platform as the default administrator (admin), and navigate to the System > System Settings > Mail Server Settings page.
2. Enter the mail server address, server port number (25 by default), username and password for authentication, and sender's mail address, as shown in Figure 3. Click OK.
Figure 3 Mail server information
3. After the configuration is completed, click Send Test Mail to send a test mail to the recipient to identify whether the mail server configuration is correct.
(Optional.) Create a tenant
After the controller is installed, a tenant named System is automatically created. You can use the tenant to incorporate devices and deploy services.
Alternatively, you can manually create a tenant, and incorporate devices and deploy services as the new tenant.
1. Log in to Unified Platform as the default system administrator admin and then navigate to the System > Tenants > Tenants page, as shown in Figure 4.
Figure 4 Tenant management page
2. Click the 
icon to the right
of the tenant named System. Add a new tenant, and
then click OK, as shown in Figure 5.
Key parameters
¡ Tenant Name: Enter the name of the created tenant (SDWAN in this example).
¡ Tenant Type: Select Non-MSP Tenant.
¡ Initial RoleGroup: Select predefined role groups for the current tenant. If you also select to create a tenant administrator, the role group of the tenant administrator is determined depending on whether initial role groups are selected. If no initial role groups are selected, the role group of the tenant administrator is the first one in the initial role group dropdown list. If initial role groups are selected, the role group of the tenant administrator is the first one displayed in the initial role group dropdown list. By default, all predefined role groups of the tenant are copied to the newly created tenant.
¡ Organization Name: Name of the top-level organization in the tenant. By default, it is the same as the tenant name.
¡ Create Tenant Administrator: Select whether to create a tenant administrator. If you turn on this parameter, you add an operator as the tenant's system administrator.
|
|
CAUTION: · When you delete a tenant, the system will check whether the tenant has devices and VPNs. If the tenant has devices and VPNs, the tenant cannot be deleted. · When the controller is abnormal (such as during controller upgrade), the controller cannot check whether devices and VPNs exist in a tenant. In this case, do not delete tenants because data might remain on the controller and requires clearance in the back end. |
(Optional) Create a tenant service administrator
When a tenant is created, you must first create a tenant service administrator to deploy services.
1. Log in to Unified Platform as the default system administrator admin. After logging in to Unified Platform, navigate to the System > Operator Managements > Operators page, as shown in Figure 6. On this page, you can see the list of all operators for the tenant.
2. Click Add. In the dialog box that opens, configure related parameters, and then click OK, as shown in Figure 7.
Parameters:
¡ Operator Name: Enter the username of the operator used for login, sdwan in this example.
¡ Tenant: Tenant used to incorporate devices and deploy services. You can select the tenant named SDWAN created in "(Optional.) Create a tenant."
¡ Organization: Select SDWAN.
¡ Authentication Method: Options include Simple Password Authentication, RADIUS Authentication, LDAP Authentication, TACACS Authentication, and Third-Party Authentication. In this example, select Simple Password Authentication, and set the login password.
¡ By Role Group: Four predefined groups exist in the system. Among them, the service management group and system management group can both deploy services. In this example, select the system management group to assign the relevant system management permissions to the operator.
Plan device onboarding
Deployment workflow
First, make device onboarding plan, and complete registration and onboarding of all devices based on the network diagram. Perform manual deployment for the devices in headquarters 1 and headquarters 2, and perform deployment for devices in branches via USB/email.
In this section, log in to Unified Platform as the tenant service administrator named sdwan. For tenant related configurations, see "(Optional.) Create a tenant" and "(Optional) Create a tenant service administrator."
You can complete configuration in the device onboarding plan through the configuration guide or automation menus. Figure 8 shows the deployment workflow for the device onboarding plan.
Figure 8 Deployment workflow for the device onboarding plan
Global configuration
As the basic controller configuration, global configuration requires to be completed first for a new deployment. As a best practice, complete relevant configuration based on the configuration guide.
Configure basic settings
1. Navigate to the Guide > Branch Network Deployment > Plan Device Onboarding > Global Config > Basic Configuration page, configure the BGP AS number, system IP interface number, and SDWAN server port, and then click OK.
Figure 9 Configuring basic settings
Parameters:
¡ BGP AS Number: AS number used when the controller issues BGP configuration to devices. The BGP AS number is unique to each tenant.
¡ Management Interface: Choose to whether to create a management loopback interface for use with the management VPN. Select On for this field.
¡ Management Loopback Number: Interface number used when the controller assigns a management loopback interface to the device.
¡ System IP Interface Number: Interface number used when the controller issues loopback interface associated with the system IP address to devices.
¡ SDWAN Server Port: Port used for the RR and the access CPE to establish a TLS connection. The default port number is 2004. You can change the port number as needed.
|
|
CAUTION: · To configure a management VPN, you must select On for Management Interface. · After overlay tunnels (TTE connections) are established, changing the SDWAN server port triggers the system to terminate and re-establish the TLS connection between the RR and CPE. This further terminates overlay tunnels (TTE connections) between devices and affects overlay traffic forwarding. |
2. To perform the search operation or relevant configuration, navigate to the Automation > Branch Networks > Parameter Settings > Global Config > Basic Config page.
Configure resource pools
1. Navigate to the Guide > Branch Network Deployment > Plan Device Onboarding > Global Config > Configure Resource Pools page. To add a resource pool, click Add, configure the settings as shown in Figure 10 (see "Resource pool planning" for relevant information), and then click OK.
Figure 10 Configuring resource pools
2. To perform the search operation or relevant configuration, navigate to the Automation > Branch Networks > Parameter Settings > Global Config > IP Address Pools page. When you manually add an address pool, specify its type as system IP interface, as shown in Figure 11.
Configure O&M settings
1. Navigate to the Automation > WAN Deployment Wizards > Plan Branch Networks page or the Automation > Branch Networks > Parameter Settings > O&M Settings page.
2. Configure parameters in the Device Quality and Traffic Statistics Sampling area and the Controller Quality and Traffic Statistics Sampling area, as shown in Figure 12.
3. Edit the global BFD template parameters, as shown in Figure 13.
4. Configure parameters in the Link Quality Score area and the iNQA area, as shown in Figure 14.
5. After configuring parameters in an area, click OK to save the configuration.
Figure 12 Device quality and traffic statistics sampling parameters
Figure 14 Link quality score and iNQA
Parameters:
¡ Device Quality and Traffic Statistics Sampling: According to the network scale, you can select a granularity as needed. Different granularities correspond to different global parameters. You can also select self-defined O&M parameters. The O&M parameters will be deployed to devices. Based on these O&M parameters, the device performs detection and path selection. The O&M parameters are described as follows:
- Link Quality Probe Interval(s): Intervals at which link quality probes are performed for the SDWAN tunnel.
- Interface Statistics Polling Interval: Interval at which interface traffic statistics are collected, in seconds.
- Link Selection Delay: Period of time (in seconds) to be delayed for the RIR to perform a link selection when the link quality or bandwidth does not meet the requirements to avoid frequent link selections.
- Link Selection Suppression Interval: Time interval (in seconds) to be waited for the RIR to perform a link switchback. This parameter is used to avoid frequent switchbacks.
- SDWAN Tunnel Keepalive Interval: Time interval at which the SDWAN tunnel sends keepalive request packets. The value is in the range of 1 to 32767, in seconds. After you enable BFD-based tunnel detection, keepalive packets are used for tunnel establishment.
- SDWAN Tunnel Keepalive Retries: The maximum number of retries allowed if the SDWAN tunnel does not receive a keepalive response packet. The value is in the range of 1 to 255.
¡ Controller Quality and Traffic Statistics Sampling: Time-related settings for the controller to collect device information.
- Quality Report Interval: Interval at which the device reports the link quality, in seconds.
- Real-Time Traffic Report Interval: Interval at which the device reports real-time traffic packets, in seconds.
- Application Traffic Report Interval: Interval at which the device reports application traffic packets, in seconds.
¡ Global BFD Settings: BFD settings that the controller deploys to the routing protocol and time parameters to deploy the BFD settings.
- BFD Detect Multiplier: BFD detection time multiplier.
- BFD Rx Interval: Minimum interval for receiving BFD control packets, in milliseconds.
- BFD Tx Interval: Minimum interval for sending BFD control packets, in milliseconds.
¡ Link Quality Evaluation Weight Assignment: Assign weight values to link quality metrics, including latency, packet loss, and jitter. The system can calculate a link quality score for each link for link quality evaluation. A higher score indicates higher link quality.
- Weight Assignment: Assign weight values to link quality metrics, including latency, packet loss, and jitter.
- Threshold Assignment: Set the threshold of each link quality level for latency, packet loss, and jitter. The link quality levels include Excellent, Good, Fair, and Poor.
¡ iNQA: Use the parameter to select whether to disable bidirectional iNQA. By default, bidirectional iNQA is enabled. If you enable this parameter, bidirectional iNQA is disabled and unidirectional iNQA is enabled. This solution requires using bidirectional iNQA.
|
|
CAUTION: · If you need to enable BFD for BGP neighbors, make sure the BFD detection time and number of detections are greater than those for tunnel BFD keepalive packets. · This solution requires using bidirectional iNQA, and you must disable the iNQA parameter. |
Configure IPsec
1. Navigate to the Guide > Branch Network Deployment > Plan Device Onboarding > Global Config > Configure IPsec page. Configure IPsec parameters, and then click OK to save the configuration.
Figure 15 Configuring IPsec
Parameters:
¡ Anti-Replay Check: As a best practice to avoid traffic interruption when collaborating with QoS, disable anti-replay check.
¡ Encryption Scheme: Five encryption schemes are available, including custom encryption scheme. In this example, the Recommended Encryption Scheme is used.
2. To view the corresponding IPsec encryption scheme, navigate to the Automation > Branch Networks > Parameter Settings > Global Config > Configure IPsec page. After all WAN details configured with IPsec encryption are deleted, you can edit the IPsec encryption scheme.
|
|
CAUTION: · You can select only one IPsec encryption scheme for the network. · The GM encryption scheme must use dedicated GM encryption modules. For a successful IPsec tunnel establishment and traffic forwarding, make sure all devices that need to establish IPsec tunnels have GM encryption modules if you select this scheme. · As a best practice to avoid traffic interruption when collaborating with QoS, disable anti-replay check in IPsec configuration. |
Configure WebSocket templates
1. Navigate to the Guide > Branch Network Deployment > Plan Device Onboarding > Global Config > WebSocket Templates page. WebSocket templates are typically used for generating configuration files for deployment via USB or URL. You do not need to edit this configuration if the deployment is not performed via USB or URL. The address of the global default template is the northbound VIP. For devices to come online through the public network as planned, add a public network address. In this example, two public IP addresses for registration are added, 110.1.1.1 and 110.1.2.1, as shown in Figure 16. Then click OK.
Figure 16 Configuring WebSocket templates
2. To perform the search operation or edit relevant configuration, navigate to the Automation > Branch Networks > Parameter Settings > Templates > WebSocket Templates page.
To deploy a remote disaster recovery network, you must also add the northbound address of the disaster recovery cluster as the backup server address.
Configure SNMP templates
1. Navigate to the Guide > Branch Network Deployment > Plan Device Onboarding > Global Config > SNMP Templates page. The controller does not require using SNMP to manage devices. For the network management component or analyzer to manage devices through SNMP, the controller supports deploying SNMP configuration. Click Add to add an SNMP template. When you add a new SNMP template, select SNMP version v2c, set the read community name to pubic, and set the write community to private, as shown in Figure 17.
Figure 17 Configuring SNMP templates
2. To perform the search operation or relevant configuration, navigate to the Automation > Branch Networks > Parameter Settings > Templates > SNMP Templates page.
Configure tunnel BFD templates
1. Navigate to the Guide > Branch Network Deployment > Plan Device Onboarding > Global Config > Tunnel BFD Templates or Automation > Branch Networks > Parameter Settings > O & M Settings > O & M Parameter Settings page. Click Add to add a tunnel BFD template, as shown in Figure 18.
Figure 18 Configuring a tunnel BFD template
Parameters:
¡ Template Name: Name of the tunnel BFD template specified for the SD-WAN tunnel for overlay link (TTE connection) detection.
¡ BFD Detect Multiplier: As a best practice, set the value to 5. You can edit the setting as needed.
¡ BFD Rx Interval(ms)/BFD Tx Interval(ms): BFD detection interval. As a best practice, set the value to 1000 milliseconds. You can edit the setting as needed.
¡ Enable BFD: Whether or not to use tunnel BFD for connectivity detection. The solution requires enabling tunnel BFD.
2. Click Add to add an extended tunnel BFD template, as shown in Figure 19.
Figure 19 Configuring an extended tunnel BFD template
Parameters:
¡ Template Name: Name of the extended tunnel BFD template specified for the SD-WAN tunnel when the site is deployed with two gateways for extended tunnel connectivity detection.
¡ BFD Detect Multiplier: As a best practice, set the value to 5. You can edit the setting as needed.
¡ BFD Rx Interval(ms)/BFD Tx Interval(ms): BFD detection interval. As a best practice, set the value to 1000 milliseconds. You can edit the setting as needed.
¡ Enable BFD: Whether or not to use extended tunnel BFD for connectivity detection.
|
|
CAUTION: · To use BFD to detect connectivity of tunnels, first configure a tunnel BFD template and then add WAN network details. The detection method without using BFD is only for compatibility with earlier deployment. · If the two gateway devices of a site are connected directly through physical links, do not enable BFD as a best practice. If the two gateway devices are connected through a Layer 3 network or cannot know the fault of the peer through a physical interface down event (for example, VSR devices are used), enable BFD to detect connectivity of tunnels as a best practice. · If you first configure WAN details and then bind a tunnel BFD template, the BFD template configuration is not deployed to original tunnels. You need to delete the WAN details and then add it again. · BFD binding for tunnels or extended tunnels cannot be disabled once enabled. |
After completing global configuration, click Next to access the Configure WAN Networks page.
Configure WAN networks
Navigate to the Guide > Branch Network Deployment > Plan Device Onboarding > Configure WAN Networks page to add WAN service networks as needed. This example requires adding three types of WAN networks.
You can also view or add WAN service networks by navigating to the Automation > Branch Networks > Physical Networks > Sites Settings > WAN Links page
Configure WAN service networks of the Internet type
Add a WAN service network
You must add a WAN service network of the Internet type for an Internet or a network in which NAT is performed through a firewall.
To add a WAN service network:
1. Click Add to add a WAN service network. Configure the WAN network name as Internet and select network type Internet, as shown in Figure 20.
Figure 20 Adding a WAN service network of the Internet type
Parameters:
¡ Network Domain: Specify the network routing domain. You need to specify a different routing domain for each WAN service network. Overlay tunnels (TTE connections) can be established within the same routing domain. The network routing domain is set to 200 in this example.
¡ IPsec Encryption: Enable or disable IPsec encryption. In this example, IPsec encryption is enabled.
¡ WAN Network Across Transmission Switch: If this option is enabled, different transport networks can establish an overlay tunnel (TTE connection). In this example, the option is enabled.
2. Click OK.
Configure the transport network list and service plane list
The transparent network list and service
plane list configuration page automatically opens after you add the WAN service
network of the Internet type. After returning to the previous page, you can
also click 
to enter the transparent network list and
service plane list configuration page.
1. Add transport networks. You must specify different transport networks for the interfaces connecting a site to the same WAN network (Internet type). You need to configure multiple transport networks when the site has multiple interfaces connected to the same Internet network. Typically, configure a transport network for each ISP. Click Add to add a new transport network, as shown in Figure 21.
Figure 21 Transport network list
Parameters:
¡ Transport Network: By default, a transport network named Default exists. You can add or delete a transport network as needed. Different WAN access interfaces of a site must belong to different transport networks.
¡ Transport Network Alias: The alias of a transport network.
In this example, the Internet network is configured with two transport networks named CT and CU, respectively.
|
|
CAUTION: Different WAN service networks must be configured with different network routing domains. Different transport networks must be configured for the interfaces connecting a site to the same WAN service network. |
2. Service plane list
If tunnel setup across transport networks is enabled, and a WAN network contains multiple transport networks, one-to-many overlay tunnels (TTE connections) might exist. Traffic scheduling requires output interface selection on the local device. If an interface establishes multiple overlay tunnels (TTE connections) to the same destination device, no specific overlay tunnel (TTE connection) can be selected. Service plane is introduced to resolve this issue. You can split a WAN interface through service planes. A WAN interface can belong to multiple service planes. Only the WAN interfaces on the same service plane can establish overlay tunnels (TTE connections).
|
|
NOTE: Follow these guidelines when establishing overlay tunnels (TTE connections) between CPE and RR: · If WAN Network Across Transmission Switch is disabled, overlay tunnels (TTE connections) can be established within the same WAN network, same service plane, and same transport network. · If WAN Network Across Transmission Switch is enabled, overlay tunnels (TTE connections) can be established within the same WAN network and same service plane. The transport networks are not required to be the same. |
|
|
NOTE: Follow these guidelines when establishing overlay tunnels (TTE connections) between CPEs: · If WAN Network Across Transmission Switch is disabled, overlay tunnels (TTE connections) can be established within the same WAN network, same service plane, and same transport network only when the CPEs can exchange TTE information through RR (CPE sites are attached as clients) and have a direct route (communication between CPE sites attached to the access zone is allowed or communication between CPE sites attached to the access zone is blocked and no area topology is configured, and both CPEs advertise VPN service routes). · If WAN Network Across Transmission Switch is enabled, overlay tunnels (TTE connections) can be established within the same routing domain (of the same or different tenants) and same service plane only when the CPEs can exchange TTE information through RR (CPE sites are attached as clients) and have a direct route (communication between CPE sites attached to the access zone is allowed or communication between CPE sites attached to the access zone is blocked and no area topology is configured, and both CPEs advertise VPN service routes). The transport networks are not required to be the same. |
The link selection policy for traffic scheduling can be performed by interface (WAN network and transport network) or service plane configuration. You can implement path priority control by configuring service planes.
3. Service plane planning in a two-tier network
In this example, the Internet network has transport networks CT and CU. The headquarters and branches each have two Internet egresses. Tunnel setup across transport networks is enabled. Four overlay tunnels (TTE connections) are established between the headquarters and each branch. To distinguish the four tunnels, you can define four service planes (in the format of upper-level transport network-lower-level transport network) named CT-CT (service plane 1), CT-CU (service plane 2), CU-CT (service plane 3), and CU-CU (service plane 4) as shown in Figure 22. The associated overlay tunnels (TTE connections) can then be accurately selected based on the scheduling policy through the routing domain + transport network + service plane configuration.
For example, an application requires using the CT tunnel of the same ISP as the primary tunnel, the CU tunnel of the same ISP as the secondary tunnel, and cross-ISP tunnels as backup tunnels in a descending order of priority. To meet the requirement, configure policies CT on service plane 1, CU on service plane 4, CT on service plane 2, CU on service plane 2, and CT on service plane 3 in a descending order of priority. The last four policies are all cross-ISP tunnels used as backup tunnels whose priorities are configurable on demand.
Figure 22 Service plane diagram
4. Service plane planning in a three-tier network
In a three-tier network, distribution sites must be configured in routing policies for the HQ site and branch sites. To distinguish paths, you must distinguish the service planes among level-1 and level-2 sites from service planes among level-2 and level-3 sites. According to the service plane planning in a two-tier network, you can define four service planes among level-2 and level-3 sites, named 2-CT-CT (service plane 5), 2-CT-CU (service plane 6), 2-CU-CT (service plane 7), and 2-CU-CU (service plane 8).
5. Configure the service plane list as shown in Figure 23.
Parameters:
¡ Service Plane Name: Enter a service plane name, which will be used in link selection policies.
¡ Service Plane ID: Enter a service plane ID, which must be unique for each service plane on the same WAN network.
¡ UDP Port Number for SDWAN Tunneled Packets: Port number encapsulated by UDP for SDWAN tunnels. Different service planes on the same WAN network must use different UDP port numbers. As a best practice, specify the UDP port number as an integer in the range of 12288 to 12543. If a firewall is deployed, you need to permit the port to pass or configure a mapping for the port. For information about port mapping configuration, see Table 2.
6. Click Back to return to the WAN configuration page.
Add a WAN service network of the L3VPN type
Add a WAN service network
1. Click Add to add a WAN service network. Configure the WAN network name as MPLS and select network type L3VPN, as shown in Figure 24. Then click OK.
Figure 24 Adding a WAN service network of the L3VPN type
Parameters:
¡ Network Domain: Specify the network routing domain. You need to specify a different routing domain for each WAN service network. Overlay tunnels (TTE connections) can be established within the same routing domain. The network routing domain is set to 300 in this example.
¡ IPsec Encryption: Enable or disable IPsec encryption. In this example, IPsec encryption is disabled.
¡ WAN Network Across Transmission Switch: If this option is enabled, different transport networks can establish an overlay tunnel (TTE connection). In this example, the option is disabled.
2. Click OK.
Configure the transport network list and service plane list
The transparent network list and service
plane list configuration page automatically opens after you add the WAN service
network of the L3VPN type. After returning to the previous page, you can also
click 
to enter the transparent network list and
service plane list configuration page.
1. Add transport networks. You must specify different transport networks for the interfaces connecting a site to the same WAN network. You need to configure multiple transport networks when the site has multiple interfaces connected to the same Layer 3 WAN network. This example does not require adding additional transport networks. The transport network list is as shown in Figure 25.
Figure 25 Transport network list
Parameters:
¡ Transport Network: By default, a transport network named Default exists. You can add or delete a transport network as needed. Different WAN access interfaces of a device must belong to different transport networks.
¡ Transport Network Alias: The alias of a transport network.
This example does not require adding additional transport networks.
|
|
CAUTION: Different WAN service networks must be configured with different network routing domains. Different transport networks must be configured for the interfaces connecting a site to the same WAN service network. |
2. Service plane list:
If tunnel setup across transport networks is enabled, and a WAN network contains multiple transport networks, one-to-many overlay tunnels (TTE connections) might exist. Traffic scheduling requires output interface selection on the local device. If an interface establishes multiple overlay tunnels (TTE connections) to the same destination device, no specific overlay tunnel (TTE connection) can be selected. Service plane is introduced to resolve this issue. You can split a WAN interface through service planes. A WAN interface can belong to multiple service planes. Only the WAN interfaces on the same service plane can establish overlay tunnels (TTE connections).
|
|
NOTE: Follow these guidelines when establishing overlay tunnels (TTE connections) between CPE and RR: · If WAN Network Across Transmission Switch is disabled, overlay tunnels (TTE connections) can be established within the same WAN network, same service plane, and same transport network. · If WAN Network Across Transmission Switch is enabled, overlay tunnels (TTE connections) can be established within the same WAN network and same service plane. The transport networks are not required to be the same. |
|
|
NOTE: Follow these guidelines when establishing overlay tunnels (TTE connections) between CPEs: · If WAN Network Across Transmission Switch is disabled, overlay tunnels (TTE connections) can be established within the same WAN network and same transport network only when the CPEs can exchange TTE information through RR (CPE sites are attached as clients) and have a direct route (communication between CPE sites attached to the access zone is allowed or communication between CPE sites attached to the access zone is blocked and no area topology is configured, and both CPEs advertise VPN service routes). · If WAN Network Across Transmission Switch is enabled, overlay tunnels (TTE connections) can be established within the same WAN network and same service plane only when the CPEs can exchange TTE information through RR (CPE sites are attached as clients) and have a direct route (communication between CPE sites attached to the access zone is allowed or communication between CPE sites attached to the access zone is blocked and no area topology is configured, and both CPEs advertise VPN service routes). The transport networks are not required to be the same. |
The link selection policy for traffic scheduling can be performed by interface (WAN network and transport network) or service plane configuration. You can implement path priority control by configuring service planes.
3. Service plane planning in a two-tier network
In this example, the L3VPN network has transport networks CT and CU. The headquarters and branches each have two interfaces connected to the Layer 2 WAN network. Tunnel setup across transport networks is enabled. Four overlay tunnels (TTE connections) are established between the headquarters and each branch. To distinguish the four tunnels, you can define four service planes (in the format of upper-level transport network-lower-level transport network) named tn1-tn1 (service plane 1), tn1-tn2 (service plane 2), tn2-tn1 (service plane 3), and tn2-tn2 (service plane 4) as shown in Figure 26. The associated overlay tunnels (TTE connections) can then be accurately selected based on the scheduling policy configured later.
Figure 26 Service plane diagram
4. Service plane planning in a three-tier network
In a three-tier network, distribution sites must be configured in routing policies for the HQ site and branch sites. To distinguish paths, you must distinguish the service planes among level-1 and level-2 sites from service planes among level-2 and level-3 sites. According to the service plane planning in a two-tier network, you can define four service planes among level-2 and level-3 sites, named 2-CT-CT (service plane 5), 2-CT-CU (service plane 6), 2-CU-CT (service plane 7), and 2-CU-CU (service plane 8).
5. Configure the service plane list as shown in Figure 27. In this example, only one service plane is required between level-1 and level-2 sites, and only one service plane is required between level-2 and level-3 sites. To distinguish paths, two service planes are added: one for establishing a tunnel between the level-1 and level-2 sites and one for establishing a tunnel between the level-2 and level-3 sites.
Parameters:
¡ Service Plane Name: Enter a service plane name, which will be used in link selection policies.
¡ Service Plane ID: Enter a service plane ID, which must be unique for each service plane on the same WAN network.
¡ UDP Port Number for SDWAN Tunneled Packets: Port number encapsulated by UDP for SDWAN tunnels. Different service planes on the same WAN network must use different UDP port numbers. As a best practice, specify the UDP port number as an integer in the range of 12288 to 12543.
6. Click Back to return to the WAN configuration page.
Add a WAN service network of the L2VPN type
Add a WAN service network
When multiple L2VPNs exist between the two sites, you need to create multiple WAN networks.
In this example, two L2VPNs exist between the level-1 and level-2 sites, and two L2VPNs exist between the level-2 and level-3 sites. Four WAN networks are added.
1. Add four WAN service networks of the L2VPN type named MSTP1, MSTP2, MSTP3, and MSTP4. Click Add to add a WAN service network (take MSTP1 as an example). Configure the WAN network name as MPLS1 and select network type L2VPN, as shown in Figure 28. Then click OK.
Figure 28 Adding a WAN service network of the L2VPN type
Parameters:
¡ Network Domain: Specify the network routing domain. You need to specify a different routing domain for each WAN service network of a tenant. Overlay tunnels (TTE connections) can be established within the same routing domain. In this example, specify the network routing domain for MSTP1 as 401, the network routing domain for MSTP2 as 402, the network routing domain for MSTP3 as 403, and the network routing domain for MSTP4 as 404.
¡ Loopback Interface Number: The HQ site or a distribution site must use a loopback interface as the source interface for SDWAN tunnel encapsulation. (The device in the headquarters is connected to multiple branch devices through the same L2VPN.) Different WAN networks require specifying different interface numbers. In this example, specify the loopback interface number for MSTP1 as 10, specify the loopback interface number for MSTP2 as 11, specify the loopback interface number for MSTP3 as 13, and specify the loopback interface number for MSTP4 as 14.
¡ IPsec Encryption: Enable or disable IPsec encryption. In this example, IPsec encryption is disabled.
2. Click OK.
|
|
CAUTION: · You need to specify a different network routing domain for each WAN service network. · For an L2VPN, two sites can establish only one WAN network connection. When multiple L2VPNs exist between the two sites, you need to create multiple WAN networks. · You must create different WAN networks for L2VPNs between sites at different levels. |
Configure the service plane list
1. Click 
in the Actions column for a L2VPN to enter the service plane
configuration page. You can split a WAN interface through service planes. A WAN
interface can belong to multiple service planes. Only the WAN interfaces on the
same service plane can establish overlay tunnels (TTE connections).
You can control overlay tunnel (TTE connection) establishment in specific networks through service plane configuration. (Details not shown.)
Add a WAN service network of the VPDN type
Add a WAN service network
Click Add to add a WAN service network. Configure the service network name as VPDN, select network type VPDN, and click OK, as shown in Figure 29.
Figure 29 Adding a WAN service network of the VPDN type
Parameters:
· Network Routing Domain: Specify the network routing domain. You need to specify a different routing domain for each WAN service network of a tenant. Overlay tunnels (TTE connections) can be established within the same routing domain. The network routing domain is set to 500 in this example.
· IPsec Encryption: Enable or disable IPsec encryption. In this example, IPsec encryption is disabled.
· Across Transmission: If this option is enabled, different transport networks can establish an overlay tunnel (TTE connection). In this example, this option is disabled.
Click OK.
Configure the transport network list and service plane list
The transparent network list and service
plane list configuration page automatically opens after you add the WAN service
network of the VPDN type. After returning to the previous page, you can also
click 
to enter the transparent network list and
service plane list configuration page.
If the LNS device supports using the same VT interface by multiple physical interfaces for authentication and address allocation, you must bind a different transport network to each interface when adding a WAN service detail.
This example does not require adding additional transport networks. Click Cancel to go back to the WLAN configuration page.
Sites and devices
Navigate to the Guide > Branch Network Deployment > Plan Device Onboarding > Sites and Devices page.
Figure 30 Sites and devices
|
|
NOTE: · You can also manually add devices on the Automation > Branch Networks > Physical Networks > Devices > Devices page. Alternatively, you can manually add or import sites and devices from the Automation > Branch Networks > Physical Networks > Sites page. · You can also manually add STUN servers on the Automation > Branch Networks > Physical Networks > Devices Settings > STUN page. · You can configure NTP settings when importing devices into a site, or configure NTP settings on the page after importing devices into the site (see "Configure NTP settings"). |
Add or import sites and devices
Import sites and devices
1. Click Download Template to download a template, and follow the instructions to enter site and device information in the template based on the network model.
Figure 31 Site and device import template
Parameters:
¡ Site Name: Name of a site, a string of 1 to 255 characters. The site name can only contain letters, digits and dots (.) and must be unique.
¡ Site Role: As a best practice, do not configure the NAT Transfer role for the solution in the current software version.
- RR: Route reflector. VPN service traffic is not transmitted through the site. This example does not involve this type of site role.
- CPE: Customer premises equipment. VPN service traffic is transmitted through the site. Specify this role for the three branch sites. Branch3, Branch4, and Branch5 are CPEs.
- RR_CPE: Route reflector and customer premises equipment. Sites of this role reflect CPE routes and forward VPN traffic. Specify this role for the headquarters site. The two HQ sites and the two level-2 distribution sites (Branch1 and Branch2) are RR_CPEs.
- POP: This role is used in an MSP scenario.
¡ WebSocket Template: Global or device-specific WebSocket template name for the device. If you do not specify this value, the global template applies.
¡ SNMP Template: Specify this template for deploying SNMP configuration.
¡ Site Type: Select router. If the site is a firewall device, select firewall.
¡ Interconnect Port Number: Required for dual-gateway sites. Port number for the TCP connection used for link data synchronization between the local and peer devices. The port number cannot be used by any other services on the device, for example, 3001.
¡ GW-GW Packet Redirection: Applicable only to WAN acceleration scenarios. Select Yes if WAAS dual-gateway redirection is used. If you select Yes, for dual-gateway redirection configuration to be deployed, make sure the interconnect interfaces are physical ports (physical sub-interface excluded). By default, this field is No.
¡ NTP: The solution requires time synchronization through NTP. If you select Yes, you can configure NTP settings when importing devices into a site. if you want the generated USB/URL deployment configuration to contain NTP settings. If you select No, you can deploy the NTP service through the controller. For more information, see "Configure NTP settings."
¡ NTP Setup Method: Options include USB/Email and WebSocket. If you select USB/Email, the generated deployment file contains NTP settings. If you select WebSocket, the NTP settings are deployed through WebSocket after the device comes online.
¡ Device Name: Name of the imported device. A dual-gateway site requires importing the names of device 1 and device 2.
¡ Online Authentication Mode: Upon device registration, the controller performs authentication for the device by using three authentication modes.
- Device Serial Number: You can enter multiple serial numbers. You can use relevant commands to obtain the device serial numbers.
- Software Serial Number: Unique identifier of a device from the software aspect. You can manually configure the software serial number for the device, or obtain it in the generated USB/URL configuration.
- Device Serial Number and Software Serial Number: Both serial numbers are authenticated. A device can come online only the authentication succeeds based on both the device serial number and software serial number.
¡ Software serial number: Required if the authentication mode contains software serial number. A software serial number is a string of up to 32 characters. For information about manually configuring software serial numbers, see "Manually deploy devices."
¡ Device Serial Number: Required if the authentication mode contains device serial number. You can enter multiple serial numbers separated by semicolons (;) in the field. You must enter the serial numbers of hosts. For an IRF fabric, you must enter the serial numbers of the two IRF member devices. To obtain the serial numbers of IRF member devices, execute the following commands (the commands might vary with device models):
display license device-id (fixed-port device)
display license device-id slot 1/2 (fixed-port device)
display license device-id chassis 1/2 (modular device)
For example, execute the following command to obtain the serial number of the hub, and input the result in the Excel import template.
<hub>dis license device-id slot 1
SN: 210235A1X5M168A00057
Device ID: pYw5-FWs7-H7PX-m6N@-iu@i-3Chd-3Squ-677n
<hub>dis license device-id slot 2
SN: 2102111111A129000001
Device ID: MAj3-VkTY-jr>D-hnx$-6m9j-wP%y-6PaF-PWw/
¡ Router ID: Global router ID configuration deployed automatically by the controller.
¡ Management IP Address: Management IP address of the device. The interface of a loopback is configured as the management IP address. The management IP address can be configured after the management port is enabled.
¡ System IP Address: Device system IP address configured on the associated loopback interface. If this parameter is not specified, the system IP address is automatically allocated from the global address pool. Do not add the system IP address to underlay routes (including static routes and dynamic routes). If you do so, service traffic might be unable to reach to the overlay network.
¡ Interconnect Interface Name: Interface name used for interconnecting the devices in a dual-gateway site. To use loopback interfaces, make sure the interface IP addresses are reachable to each other at Layer 3.
¡ Interconnect Interface's IP Address: IP address of the interconnect interface at a dual-gateway site.
¡ Secure Deployment: If you select Yes, automatic configuration deployment is not performed after the device comes online. Before configuring services, you must manually confirm the deployment.
¡ NTP Server IP and Source Interface List: After enabling NTP, you can enter one or multiple NTP server IP addresses and source interfaces separated with semicolons (;). Separate an NTP server IP address and a source interface with a colon (:). The source interface is optional. As a best practice, synchronize the time with the controller for VPN networking , and synchronize the time with the RR for non-VPN networking.
¡ MDC Context: This parameter is available only when the USB/email setup method is used. When the USB/email setup method is used, the system cannot determine the generated USB disk deployment file or URL deployment link needs to contain the MDC context parameter. This parameter will not be displayed when the WebSocket setup method is used.
2. Complete importing sites and devices.
|
|
CAUTION: · The system IP address, management IP address, and router ID must globally unique. · In a VPN or an intranet with dynamic route redistribution, to avoid affect system IP address learning, do not configure the system IP address the same as the management IP address. · The network requires configuring NTP time synchronization. As a best practice, synchronize the time with the controller for VPN networking, and synchronize the time with the RR for non-VPN networking. · Do not add the system IP address to underlay routes (including static routes and dynamic routes). If you do so, service traffic might be unable to reach to the overlay network. · The reported hardware SN uses upper-case letters in device registration. If you enter lower-case letters for the hardware SN, they will be converted to upper-case letters when you add or import devices. · When NTP settings are deployed via USB/email, for an SR66 or later version of router or an F1000-AI-25 or later version of firewall, you must set the MDC context to 1. For devices of other models, you cannot specify the MDC context parameter. · As a best practice, do not use a VLAN interface on a router as the interconnect interface for two gateways. The forwarding performance of a VLAN interface is limited. |
Manually add sites and devices
Click Add Site to add a site, as shown in Figure 32.
For the parameters, see "Import sites and devices." To add a device, click 
,
as shown in Figure 33.
For the parameters, see "Import sites and devices."
(Optional) Configure STUN
1. Navigate to the Guide > Branch Network Deployment > Plan Device Onboarding > Import Sites and Devices > STUN page, click Add, and configure the STUN server as shown in Figure 34. STUN is required if dynamic NAT performed on the Internet link (for the branch egress or ISP) from the branch to the headquarters in the network. If this condition does not exist, you can skip this step.
Select an RR as the STUN server. The solution requires only one STUN server . In this example, Hub1-2 is selected as the STUN server, and the STUN server IP address is set to 127.0.0.1.
Parameters:
¡ Device Name: Select a hub device, which is Hub1-2 in this example.
¡ IP Address: IP address of the STUN server, which is 127.0.0.1. The solution requires IP address 127.0.0.1.
2. Other parameters are optional. Click OK to save your settings.
Import loopback interface addresses
In the L2VPN scenario, devices at the headquarters must use loopback interface addresses as source addresses for SDWAN encapsulated packets. To import loopback interface addresses, you can navigate to the Guide > Branch Network Deployment > Plan Device Onboarding > Device LoopBack Address page.
Figure 35 is an example template used to import loopback interface addresses.
Figure 35 Loopback interface address template
Parameters:
· WAN Service Network Name: Name of the L2VPN-type WAN service network.
· Access Site Name: Name of the HQ site of the L2VPN-type WAN service network.
· Access Device Name: Name of a device under the HQ site of the L2VPN-type WAN service network.
· Interface IPv4 Address: IPv4 address of the loopback interface.
You can also click Add to add a loopback interface address, as shown in .
Figure 36 Adding a loopback interface address
WAN network details
Navigate to the Guide > Branch Network Deployment > Plan Device Onboarding > WAN Network Details page. You can import or manually add WAN network details.
You can also view or add WAN network details by navigating to the Automation > Branch Networks > Physical Networks > Sites Settings page.
Import WAN network details
WAN network detail template
Click Download Template to download a template. Then, check the networking model and follow the instructions to enter WAN network detail information in the template.
Figure 37 Guidelines for importing WAN network details
|
|
NOTE: · After you import WAN network details, the controller deploys tunnel configuration. For an IRF fabric or a modular device, you must manually deploy server slot configuration on tunnels. For more information, see "Deploy tunnel configuration." · When you manually create a tunnel, set its tunnel interface number to a value greater than 500, as best practice. · When you add WAN details for RR devices, make sure the interfaces have IP addresses. Otherwise, the adding operation fails. If an interface uses dynamic address allocation, wait for the interface to obtain an IP address and then try again. After successful adding, you cannot edit the WAN interface addresses. To edit a WAN interface address, you must delete the entry and then add it again with the new address. · If you use the WebSocket deployment method, the controller deploys interface configurations, including interface addresses. When deleting WAN details, the system also deletes configurations deployed by the controller, including interface addresses. If you manually configure interface addresses and use the configured addresses to perform WebSocket registration and onboarding, deleting WAN details can cause device and controller unreachability because the configured addresses are deleted, and configuration deletion fails. Therefore, if interface addresses are manually configured, use the manual deployment method. · As a best practice, do not use a VLAN interface on a router as the interconnect interface for two gateways. The forwarding performance of a VLAN interface is limited. |
Import Internet-type WAN network details
When you import Internet-type WAN network details, configure the following parameters:
· WAN Service Network Name: Name of the Internet-type WAN service network. This configuration guide uses Internet as an example.
· Access Site Name: Name of a site attached to the Internet-type WAN service network.
· Access Device Name: Name of a device accessing the Internet-type WAN service network.
· Access Interface: Name of the interface that provides access to the Internet-type WAN service network. You must specify an interface configured with an IP address. For example, configure a dialer interface when using PPPoE dialup.
· Access Transmission Network: Name of the created transmission network. The two interconnect interfaces connect to China Telecom and China Unicom, respectively.
· Service Plane Name: Specify a service plane based on the network plan.
· Zero-Touch Deployment Mode:
¡ USB/Email: Generate the deployment configuration corresponding to the USB flash drive or mail. The device can register and come online through this WAN interface. The interface address, access method, and related routing protocol must be configured. Typically, this method is used in zero-touch deployment for branches.
¡ WebSocket: In this way, the deployment configuration corresponding to the USB flash drive or mail is not generated, and the device does not register or come online through this WAN interface. After the device comes online, the corresponding configuration is deployed to the device through WebSocket. The interface address, access method, and related routing protocol must be configured.
¡ Manual: Manually configure the interface address and routing protocols. Typically, use this mode for devices in the HQ (non-zero-touch deployment).
· Protocol Stack: Protocol stack type for the WAN interface. Both IPv4 and IPv6 are supported. This configuration guide uses IPv4 as an example.
· STUN SERVER: This parameter is required if no fixed public IP address exists or no fixed public IP address can be mapped in a branch. In this configuration example, the STUN server is Hub1-2/127.0.0.1.
· Fixed Public IP: When the firewall service translates the private address of a WAN interface to a public address, enter this public address as the fixed public IP address for that WAN interface. You must configure fixed public IP addresses for hubs used in this configuration example.
· Uplink/Downlink Bandwidth (kbps): Set the available bandwidth for the device to network link or network to device link. The branch solution performs scheduling based on bandwidth, and you must configure the uplink bandwidth and downlink bandwidth.
· MTU: MTU of the interface. By default, the interface has an MTU. As a best practice, do not configure this parameter.
· TCP MSS: As a best practice, do not configure this parameter.
· Network Connection Type: Method through which a WAN interface accesses the network. For a WAN detail with deployment method Manual, you do not need to configure this parameter. Options include:
¡ DHCP: Use the DHCP server to automatically assign IP addresses for network access.
¡ PPPoE: Enable the devices to access the network through dialup.
¡ Static IP: Enable the devices to access the network through fixed IP addresses.
¡ 4G/5G: Enable the devices to access the network through 4G/5G.
· Static IPv4 Address/Mask: This parameter is required when the network connection type is Static IP and the zero-touch deployment mode is not Manual.
· VLAN ID: This parameter is required when the access interface is a subinterface.
· PPPoE configuration items: Specify a physical interface enabled with the PPPoE client and specify the username and password used for authentication.
· 4G/5G configuration items: Configure 4G/5G dialup settings.
· Static Route Destination IPv4 Address/Mask: Deploy static routes as needed.
· IPv4 Gateway Address: This parameter is required when the network connection type is Static IP.
· Dynamic Routing Protocol: Configure a dynamic routing protocol.
|
|
NOTE: · The system automatically sets the allocable bandwidth of physical links and tunnel bandwidth based on the uplink/downlink bandwidth settings in WAN details. The uplink bandwidth setting is used to determine the allocable bandwidth of physical links and tunnel bandwidth from the device to the peer device, and the downlink bandwidth setting is used to determine the allocable bandwidth of physical links from the peer device to the local device. After you importing WAN details, to change the allocable bandwidth of physical links or the allocable bandwidth of tunnels, see "View and maintain underlay links" and "View and maintain the deployment state of tunnels," respectively. · If you have configured a fixed public IP address, you cannot configure a STUN server. You can configure only one of them. |
Import L2VPN-type WAN network details
When you import L2VPN-type WAN network details, configure the following parameters:
· WAN Service Network Name: Name of the L2VPN-type WAN service network. This configuration guide uses MSTP1 and MSTP2 as examples.
· Side-A/B Access Site Name: Name of a site attached to the L2VPN-type WAN service network.
· Side-A/B Access Device Name: Name of a device accessing the L2VPN-type WAN service network.
· Side-A/B Access Interface: Name of the interface that provides access to the L2VPN-type WAN service network.
· Side-A/B Zero-Touch Deployment Mode:
¡ USB/Email: Generate the deployment configuration corresponding to the USB flash drive or mail. The device can register and come online through this WAN interface. The interface address, access method, and related routing protocol must be configured. Typically, this method is used in zero-touch deployment for branches.
¡ WebSocket: In this way, the deployment configuration corresponding to the USB flash drive or mail is not generated, and the device does not register or come online through this WAN interface. After the device comes online, the corresponding configuration is deployed to the device through WebSocket. The interface address, access method, and related routing protocol must be configured.
¡ Manual: Manually configure the interface address and routing protocols. Typically, use this mode for devices in the HQ (non-zero-touch deployment).
· Side-A/B Protocol Stack: Protocol stack type for the WAN interface. Both IPv4 and IPv6 are supported. This configuration guide uses IPv4 as an example.
· Side-A/B Device Network Connection Type: When the network type is L2VPN, only Static IP is supported.
· Side-A/B Static IPv4 Address/Mask: This parameter is required when the network connection type is Static IP and the zero-touch deployment mode is not Manual. This parameter is not required when the zero-touch deployment mode is Manual.
· Routing Protocol Settings: Configure routing protocol settings for interconnect. These settings are not required when the zero-touch deployment mode is Manual.
· Uplink/Downlink Bandwidth (kbps): Set the available bandwidth for the device to network link or network to device link. The branch solution performs scheduling based on bandwidth, and you must configure the uplink bandwidth and downlink bandwidth.
· MTU: MTU of the interface. By default, the interface has an MTU. As a best practice, do not configure this parameter.
· TCP MSS: As a best practice, do not configure this parameter.
|
|
NOTE: The system automatically sets the allocable bandwidth of physical links and tunnel bandwidth based on the uplink/downlink bandwidth settings in WAN details. The uplink bandwidth setting is used to determine the allocable bandwidth of physical links and tunnel bandwidth from the device to the peer device, and the downlink bandwidth setting is used to determine the allocable bandwidth of physical links from the peer device to the local device. For a Layer 2 leased line, since one tunnel might have multiple physical egresses, the tunnel bandwidth is set to 400G by default. After you importing WAN details, to change the allocable bandwidth of physical links or the allocable bandwidth of tunnels, see "View and maintain underlay links" and "View and maintain the deployment state of tunnels," respectively. |
Import L3VPN-type WAN network details
When you import L3VPN-type WAN network details, configure the following parameters:
· WAN Service Network Name: Name of the L3VPN-type WAN service network. This configuration guide uses MPLS as an example.
· Access Site Name: Name of a site attached to the L3VPN-type WAN service network.
· Access Device Name: Name of a device accessing the L3VPN-type WAN service network.
· Access Interface: Name of the interface that provides access to the L3VPN-type WAN service network.
· Access Transmission Network: Name of the created transmission network. This configuration guide uses Default as an example.
· Service Plane Name: Name of the service plane added.
· Zero-Touch Deployment Mode:
¡ USB/Email: Generate the deployment configuration corresponding to the USB flash drive or mail. The device can register and come online through this WAN interface. The interface address, access method, and related routing protocol must be configured. Typically, this method is used in zero-touch deployment for branches.
¡ WebSocket: In this way, the deployment configuration corresponding to the USB flash drive or mail is not generated, and the device does not register or come online through this WAN interface. After the device comes online, the corresponding configuration is deployed to the device through WebSocket. The interface address, access method, and related routing protocol must be configured.
¡ Manual: Manually configure the interface address and routing protocols. Typically, use this mode for devices in the HQ (non-zero-touch deployment).
· Protocol Stack: Protocol stack type for the WAN interface. Both IPv4 and IPv6 are supported. This configuration guide uses IPv4 as an example.
· Network Connection Type: When the network type is L3VPN, only Static IP is supported.
· Static IPv4 Address/Mask: This parameter is required when the network connection type is Static IP and the zero-touch deployment mode is not Manual.
· Routing Protocol Settings: Configure routing protocol settings for interconnect. These settings are not required when the zero-touch deployment mode is Manual.
· Uplink/Downlink Bandwidth (kbps): Set the available bandwidth for the device to network link or network to device link. The branch solution performs scheduling based on bandwidth, and you must configure the uplink bandwidth and downlink bandwidth.
· MTU: MTU of the interface. By default, the interface has an MTU. As a best practice, do not configure this parameter.
· TCP MSS: As a best practice, do not configure this parameter.
Figure 38 Importing WAN network details
|
|
NOTE: The system automatically sets the allocable bandwidth of physical links and tunnel bandwidth based on the uplink/downlink bandwidth settings in WAN details. The uplink bandwidth setting is used to determine the allocable bandwidth of physical links and tunnel bandwidth from the device to the peer device, and the downlink bandwidth setting is used to determine the allocable bandwidth of physical links from the peer device to the local device. After you importing WAN details, to change the allocable bandwidth of physical links or the allocable bandwidth of tunnels, see "View and maintain underlay links" and "View and maintain the deployment state of tunnels," respectively. |
Import VPDN-type WAN network details
In a hub-LNS unification scenario, you must specify a VT interface when importing a WAN detail for the hub device. When you import VPDN-type WAN network details, configure the following parameters:
· WAN Service Network Name: Name of the VPDN-type WAN service network. This configuration guide uses VPDN as an example.
· Access Site Name: Name of a site attached to the VPDN-type WAN service network.
· Access Device Name: Name of a device accessing the VPDN -type WAN service network.
· Access Interface: Name of the interface that provides access to the WAN network. You must specify an interface configured with an IP address. For example, configure an Eth-channel interface when using VPDN dialup.
· Access Transmission Network: Name of the created transmission network. This configuration guide uses Default as an example.
· Service Plane Name: You do not need to specify any service plane in this example.
· Zero-Touch Deployment Mode:
¡ USB/Email: Generate the deployment configuration corresponding to the USB flash drive or mail. The device can register and come online through this WAN interface. The interface address, access method, and related routing protocol must be configured. Typically, this method is used in zero-touch deployment for branches.
¡ WebSocket: In this way, the deployment configuration corresponding to the USB flash drive or mail is not generated, and the device does not register or come online through this WAN interface. After the device comes online, configuration is deployed to the device through WebSocket. The interface address, access method, and related routing protocol must be configured.
¡ Manual: Manually configure the interface address and routing protocols. Typically, use this mode for devices in the HQ upon non-zero-touch deployment.
· Protocol Stack: Protocol stack type for the WAN interface. Both IPv4 and IPv6 are supported. This configuration guide uses IPv4 as an example.
· Uplink/Downlink Bandwidth (kbps): Set the available link bandwidth for the device to network or network to device direction. The branch solution performs scheduling based on bandwidth, and you must configure the uplink bandwidth and downlink bandwidth.
· MTU: MTU of the interface. By default, the interface has an MTU. As a best practice, use the default MTU value.
· TCP MSS: As a best practice, do not configure this parameter.
· VT Interface: You need to specify a VT interface only in a hub-LNS unification scenario.
· Network Connection Type:
¡ Static IP: Enable the devices to access the network through fixed IP addresses.
¡ VPDN Dialup: Enable the devices to access the network through VPDN dialup. Branches use this connection type.
· Static IPv4/Mask: This parameter is required when the network connection type is Static IP and the zero-touch deployment mode is not Manual.
· VLAN ID: This parameter is required when the access interface is a subinterface.
· VPDN Dialup Authentication Mode: Authentication mode for accessing the ISP network. Options include PAP, CHAP, and PAP-CHAP. CHAP is used in this example.
· Authentication Username/Password: Username and password for accessing the ISP network. The username is in the form of username@dmain, where the domain is provided by the ISP and the username is defined on the LNS device.
· VPDN Interface Name: Name of the cellular interface enabled with the VPDN service.
· VPDN Dial String: Dial string provided by the ISP. Typically, the dial strings provided by China Mobile and China Unicom are both *99#, and the dial string provided by China Telecom is #777.
· Access Point Type: Access point type selected when the network connection type is VPDN dialup. A dynamic access point is assigned by the ISP during dialup negotiation. A static access point is provided by the ISP. For a WAN detail with deployment method Manual, you do not need to configure this parameter.
· Access Point Name: Name of the static access point provided by the ISP. Whether the name is case sensitive depends on the ISP. For a WAN detail with deployment method Manual, you do not need to configure this parameter.
· Destination IPv4/Mask: Destination IPv4 address and mask for a static route.
|
|
NOTE: The system automatically sets the allocable bandwidth of physical links and tunnel bandwidth based on the uplink/downlink bandwidth settings in WAN details. The uplink bandwidth setting is used to determine the allocable bandwidth of physical links and tunnel bandwidth from the device to the peer device, and the downlink bandwidth setting is used to determine the allocable bandwidth of physical links from the peer device to the local device. For an L2VPN, a tunnel correspond to multiple output physical interfaces and the default tunnel bandwidth is 400 Gbps. After you importing WAN details, to change the allocable bandwidth of physical links or the allocable bandwidth of tunnels, see "View and maintain underlay links" and "View and maintain the deployment state of tunnels," respectively. |
Manually add WAN network details
Click Add to add a WAN network detail, as shown in Figure 39. For the parameters, see "Import WAN network details."
Figure 39 Adding a WAN network detail
Deploy devices via USB/email
Navigate to the Guide > Branch Network Deployment > Plan Device Onboarding > Deploy via USB/Email or Automation > Branch Networks > Physical Networks > Sites Settings > Deploy via USB/Email page. This page displays devices that support automatic deployment. These devices are devices for which the USB/email NTP setup method is selected when imported into a site or for which deployment via USB/email is selected when you import WAN details, as shown in Figure 40. You can download the URLs or USB configuration files for deployment or directly send them to engineers through email. To send device deployment information through email, you must first configure the mail server, as shown in "(Optional.) Configure the mail server."
Figure 40 Deployment via USB flash drive or email
Deploy devices via email
Obtain the URL for automated deployment
1. Select the device for automatic deployment (Spoke4-1 in this
example), and click the 
icon in the Actions column to access the deployment settings page. Select Deploy via URL for Deployment Method,
configure required parameters, as shown in Figure 41, and
then click OK to save the configuration.
Configure the following parameters:
¡ Default IP: Default interface IP address of a device after the device is powered on. The IP address is used to receive the URL for deployment. Typically, the default IP address is 192.168.0.1.
¡ Inbox Address: Email address used for receiving the deployment URL.
¡ Secret Key: Deployment via URL supports encryption. If you do not configure a secret key, the URLs used for deployment are not encrypted. If you configure a secret key, the secret key is used for encrypting the URLs used for deployment. In this example, the secret key is set to Pwd@12345.
¡ Ethernet Interface Link Mode: Options include Default and Route. In this example, the default route mode is used. The link mode of an Ethernet-type WAN interface is automatically switched to route mode. For VSR devices, you must use the default mode, and interfaces do not support the route mode.
¡ Commands: When the deployment method is Deploy via URL, you can manually add commands as needed. The added commands will be deployed on the device. To log in to and debug the device remotely, you can add remote login configurations in the URL deployment file. For more information, see the corresponding router user manuals.
|
|
IMPORTANT: · Make sure the manually added commands are correct. If a command is incorrect, deployment via URL might fail. · When NTP settings are deployed via URL, for an SR66 or later version of router or an F1000-AI-25 or later version of firewall, you must set the MDC context to 1. For devices of other models, you cannot specify the MDC context parameter. To avoid failures in deployment via URL, make sure the settings are correct. |
2. Obtain the URLs for deployment by using one of the following methods:
¡ Click
the 
icon in the Actions column for the
device to be configured. The mail to be sent is displayed, as shown in Figure 42. The
link information is encrypted. You can edit the mail contents as needed. Click OK to send the mail. After the mail is successfully sent,
the mail delivery state changes to Delivered.
¡ Click
the 
icon in the Actions column for the
device to be configured to download the URL (HTML file) used for deployment, as
shown in Figure 43. The downloaded configuration file name is DeviceSystemIP.html by default. You can select
multiple devices to download the URLs used for deployment in bulk. The
downloaded configuration file name is URL_Timestamp.zip. After
decompression, you can obtain multiple DeviceSystemIP.html files.
Figure 43 Downloading the URL configuration file
Deploy devices via URLs in email
You can obtain the URLs for deployment via email or download them, and use the URLs to perform deployment.
The detailed configuration procedure is as follows:
1. Make sure the computer and device used for deployment are reachable. Use a network cable to directly connect the first network port on the computer and that on the device. Configure an address that is on the same subnet as the device, for example, 192.168.0.100.
2. On the computer, click the URL for deployment or double-click the URL deployment file to perform deployment.
3. If the URL is encrypted, you will be prompted to enter the secret key, as shown in Figure 44. Enter the correct secret key. If no secret key is configured, skip this step.
Figure 44 Entering a secret key
4. Enter the default username and password (admin/admin) to perform authentication, as shown in Figure 45. The deployment authentication and login are completed.
Figure 45 URL deployment authentication and login
5. Access the deployment page, and click View Configuration to Be Deployed. You can see the configuration to be deployed, as shown in Figure 46. Click Start Deployment. Wait a period of time, and the final WebSocket registration result will be displayed, as shown in Figure 47.
Figure 46 Viewing the configuration deployed
Figure 47 Deployment via URL is finished
6. Wait a period of time after deployment via email is finished for a device. Then, navigate to the Automation > Branch Networks > Physical Networks > Devices > Devices page. You can see that the device has come online successfully, as shown in Figure 48.
Figure 48 Device deployed via URL has come online
Deploy devices via USB
Configure deployment via USB
1. Select the device for automatic deployment (Spoke4-2 in this example), and click the 
icon
in the Actions column for the device to deploy.
Select Deploy via USB for the Deployment
Method, and enter the required parameters, as shown in Figure 49. Then,
click OK to save the configuration.
Configure the following parameters:
¡ Inbox Address: Configure the mail address that receives the configuration file for deployment via USB.
¡ Preconfigured Commands: The manually configured commands (for example, aggregate interface configuration commands) that take effect preferentially on the device. Press Enter after entering a command.
¡ Commands: The manually configured commands (for example, authentication configuration commands) that take effect on the device. Press Enter after entering a command. To log in to and debug the device remotely, you can add remote login configurations in the USB deployment file. For more information, see the corresponding router user manuals.
¡ Ethernet Interface Link Mode: The default is route mode. The link mode of an Ethernet-type WAN interface is automatically switched to route mode. For VSR devices, you must use the default mode, and interfaces do not support the route mode.
|
|
NOTE: · Make sure the manually added commands are correct. If a command is incorrect, deployment via USB might fail. · When NTP settings are deployed via USB, for an SR66 or later version of router or an F1000-AI-25 or later version of firewall, you must set the MDC context to 1. For devices of other models, you cannot specify the MDC context parameter. To avoid failures in deployment via USB, make sure the settings are correct. |
2. Obtain the USB deployment file by using one of the following methods:
¡ Click
the 
icon in the Actions column for a device
to download the USB deployment file. The file names include the following types:
- The authentication mode for the device to come online uses device SNs: When only one device SN exists, the downloaded file name is DeviceSN.cfg, and the file can be directly imported into the USB flash drive for the device to recognize the file. When \ multiple device SNs exist, the downloaded file name is DeviceSystemIP_timestamp.zip, and you can decompress the file into multiple DeviceSN.cfg files, and import the decompressed files into the USB flash drive for the device to recognize the files.
- The authentication mode for the device to come online does not use device SNs: The downloaded configuration file is DeviceSystemIP.cfg. Before using the configuration, rename it as autodeploy.cfg for the device to correctly recognize the file.
¡ If you select one or multiple files, and click Download to download the configuration files for deployment. The names include the following types:
- The authentication mode for the device to come online uses device SNs: The downloaded file name is SN_timestamp.zip, you can decompress the file into multiple DeviceSN.cfg files, and import the decompressed files into the USB flash drive for the device to recognize the files.
- The authentication mode for the device to come online does not use device SNs: The downloaded configuration file name is SYSTEM_IP_timestamp.zip. You can decompress the file into multiple DeviceSystemIP.cfg files. Before using such a configuration file, you must rename it as autodeploy.cfg, and import it into the USB flash drive for the device to correctly recognize the file.
Figure 50 Downloading USB deployment file
Figure 51 USB deployment file content
¡ Click
the 
icon in the Actions column for a device
to send the USB deployment file, as shown in Figure 52.
Figure 52 Sending the USB deployment file
Use the USB deployment file to perform deployment
1. Copy the USB deployment file to the root directory of the USB flash drive. Insert the USB flash drive into the device, and reboot the device. The device will automatically start with the configuration file. If the authentication mode for the device to come online uses device SNs, the device deployment configuration file names contain the SNs and each device can automatically select the corresponding deployment configuration file based on its SN. You can place multiple device deployment files in a single USB flash drive for deployment of multiple devices.
|
|
CAUTION: · Make sure the USB flash drive uses the FAT32 file system. Insert the USB flash drive into the first USB interface of the device. · After you finish USB-based deployment, you must plug out the USB flash drive from the device or delete the USB deployment file from the USB flash drive. Otherwise, when the device restarts, it uses the USB deployment as startup file. |
2. Wait a period of time after deployment via USB is finished for the device. Then, navigate to the Automation > Branch Networks > Physical Networks > Devices > Devices page. You can see that the device has come online successfully, as shown in Figure 53.
Figure 53 Device deployed via USB has come online
Manually deploy devices
You can select the manual deployment method. Manually configure the device interface and route settings, and make sure the device and the controller can access each other.
1. The device actively sends WebSocket registration requests to the northbound address of the controller.
¡ When you attempt to use the device serial number for authentication, manually add the registration-related settings. Take device Hub1-1 as an example.
#
dns proxy enable
#
cloud-management backup-server domain 110.1.2.1
cloud-management backup-server domain 110.1.1.1
cloud-management server domain 192.168.40.155
cloud-management keepalive 60
#
¡ When you attempt to use the software serial number for authentication, manually add the registration-related settings. Take device Spoke3 as an example.
#
dns proxy enable
#
cloud-management backup-server domain 110.1.2.1
cloud-management backup-server domain 110.1.1.1
cloud-management server domain 192.168.40.155
cloud-management token simple ADC234SCWW2 //Specify the serial number used for authentication
cloud-management keepalive 60
#
2. (Optional.) When the device can access the controller only when it uses a permitted source address, you can specify that source address for the device during WebSocket registration configuration.
[Hub1-1]cloud-management server domain 192.168.40.155 source 30.1.1.1
3. For firewall devices to onboard, configure a security policy to permit traffic from the management tunnel. For example, on Spoke 3, configure the following:
#
security-zone name AdwanUntrustPublic ///Add WAN ports to a security zone
import interface GigabitEthernet0/1.1
import interface GigabitEthernet0/1.2
import interface GigabitEthernet0/2
import ip 192.168.40.155 32 //Add the WebSocket registration address (unified northbound address or mapped public address) to avoid device disconnection when the interface changes.
#
security-policy ip
rule 61001 name sdwan-out //Permit outgoing traffic for device registration
action pass
counting enable
source-zone Local
destination-zone AdwanUntrustPublic
rule 61002 name sdwan-in //Permit incoming traffic for device registration
action pass
counting enable
source-zone AdwanUntrustPublic
destination-zone Local
#
4. After waiting for a period of time after manual deployment, you can see that the device has come online successfully, as shown in Figure 54.
To log in to and debug the device remotely, you can add remote login configurations. For more information, see the corresponding router user manuals.
Figure 54 Device deployed manually has come online
Perform secure deployment
When a device enabled with secure deployment comes online after registration, the controller does not deploy any configuration on the device.
On the Automation > Branch Networks > Physical Networks > Devices > Devices page, the management status of the device is Deployment Not Confirmed. To have the controller deploy configuration on the device, select the device, and then click Confirm Deployment, as shown in Figure 55.
Figure 55 Confirming deployment
Display and maintain the deployment state
View the deployment state of sites
Navigate to the Automation > Branch Networks > Physical Networks > Sites page, you can view the deployment state of each site. If a site is in abnormal deployment state, you can click Retry to start deployment again.
Figure 56 Site management
View the deployment state of WAN details
Navigate to the Automation > Branch Networks > Sites Settings > WAN Links page, and view the deployment state of WAN service networks. If the deployment state is abnormal, you can click the state to view details. After resolving the issue that caused the anomaly, click Retry to start deployment again.
Figure 57 WAN details management
View and maintain underlay links
1. Navigate to the Automation > Branch Networks > Physical Networks > Physical Links > Physical Links page, and view underlay link information.
Figure 58 Physical link management
2. To change a link name or the allocable
bandwidth, click the 
icon for the link.
Figure 59 Editing a link
View and maintain the deployment state of tunnels
1. Navigate to the Automation > Branch Networks > Physical Networks > Tunnels > SDWAN Tunnels page, and view tunnel information.
Figure 60 SDWAN tunnel management
2. To change the allocable bandwidth of a
tunnel, click the 
icon for the tunnel.
Figure 61 Editing a tunnel
3. To view the deployment state of extended tunnels, navigate to the Automation > Branch Networks > Physical Networks > Tunnels > Extended Tunnels page. If a tunnel is in abnormal state, click Retry to start deployment again.
Figure 62 Extended tunnel management
Configure VPDN VT interfaces and L2TP groups
In a hub-LNS unification VPDN network, you must configure a VT interface and an L2TP group for the hub device. You can use the controller to deploy corresponding services.
Add a VT interface
1. Log in to Unified Platform as a tenant service administrator (for example, sdwan).
2. Navigate to the Automation > Branch Networks > Physical Networks > Devices Settings > VT Interfaces page.
3. Click Add to add a VT interface, as shown in Figure 63.
Figure 63 Adding a VT interface
Configure the following parameters:
¡ Interface Number: Interface number of the VT.
¡ IPV4 Address/Mask: Address of the VT interface.
¡ Peer Authentication Method: Method for authenticating the peer. Options include PAP, CHAP, and PAP-CHAP.
This parameter corresponds to the bold part in the following command:
ppp authentication-mode pap domain test
¡ ISP Domain Name: ISP domain name for user authentication.
¡ PPP Accounting: Specify whether to enable PPP accounting.
This parameter corresponds to the following command:
ppp account-statistics enable
¡ Up/Down Bandwidth(kbps): Specify available bandwidth in kbps for the device-to-network link and network-to-device link, respectively. Because the branch solution needs to be scheduled based on the specified bandwidths, you must specify the up and down bandwidths.
¡ MTU: Maximum transmission unit of the interface. This parameter has a default value on a device. Do not edit this parameter as a best practice.
¡ TCP MSS: Maximum TCP packet length for the interface. As a best practice, do not specify this parameter, including for a WAN interface.
Add an L2TP group
Perform this task to configure L2TP-related parameters.
1. Log in to Unified Platform as a tenant service administrator (for example, sdwan).
2. Navigate to the Automation > Branch Networks > Physical Networks > Devices Settings > L2TP Groups page.
3. Click Add to add an L2TP group, as shown in Figure 64.
Figure 64 Adding an L2TP group
Configure the following parameters:
¡ L2TP Group Number: Number of the L2TP group. The L2TP group with group number 1 is the default L2TP group and can receive tunnel establishment requests from any tunnel peers. You do not need to specify a tunnel peer name. For a L2TP group with any other group number, you must specify the tunnel peer name.
¡ VT Interface: Specify a VT interface for setting up an L2TP tunnel.
¡ Peer Tunnel Name: Name of the tunnel peer. You must specify this parameter for an L2TP group with a group number other than 1.
¡ Tunnel Authentication Key: Specify a tunnel authentication key.
Manually configure other VPDN configurations
The controller cannot deploy all VPDN-related configurations. You must manually configure address pool and ISP-related configurations.
Configure an address pool
In a network where the branch uses VPDN dial-up, you must configure a local address pool on the LNS for allocating an address to the branch.
[Hub2]ip pool aaa 10.100.100.100 10.100.100.200
[Hub2]ip pool aaa gateway 10.100.100.1
[Hub2]interface Virtual-Template 1
[Hub2-Virtual-Template1]remote address pool aaa
If you have other address allocation requirements, see the relevant configuration documents of the device.
Configure an ISP domain
You can configure authentication and authorization for users in an ISP domain. Both local and RADIUS authentication are supported.
Local authentication example
[Hub2]domain system //Specify an ISP domain on Hub2.
[Hub2-isp-system]authentication ppp local //Configure local authentication.
[Hub2]local-user vpdnuser class network //Specify the username, password, and service type for local authentication.
[Hub2-luser-network-vpdnuser] password simple abc123
[Hub2-luser-network-vpdnuser] service-type ppp
RADIUS authentication example
[Hub2]domain system //Specify an ISP domain on Hub2.
[Hub2-isp-system]authentication ppp radius-scheme radius //Configure RADIUS authentication, authorization, and accounting for users based on scheme radius.
[Hub2-isp-system]authorization ppp radius-scheme radius
[Hub2-isp-system] accounting ppp radius-scheme radius
[Hub2] radius scheme radius //Configure a RADIUS scheme.
[Hub2-radius-test]primary authentication 10.1.1.1 //Specify the primary authentication server and the primary accounting server.
[Hub2-radius-test]primary accounting 10.1.1.1
[Hub2-radius-test]key authentication simple expert
[Hub2-radius-test] key accounting simple expert
[Hub2-radius-test]user-name-format with-domain
Configure NTP settings
All devices on a WAN network require NTP-based clock synchronization.
· For devices on a L2VPN-type or L3VPN-type WAN network, configure NTP to synchronize the clock between those devices and the controller.
· For devices on an Internet-type WAN network, configure NTP to synchronize the clock between the RR (deployed on the same internal network as the controller) and the controller, and to synchronize the clock between other devices and the RR.
You can use either of the following methods to deploy NTP settings on devices:
· Deployment through USB/URL—After you configure NTP settings on the controller, the controller generates a configuration file for zero-touch deployment. When a device is onboarded through the configuration file, it will load NTP settings from the configuration file. For more information, see "Sites and devices."
· Deployment through WebSocket—When a device comes online after registration, the controller deploys NTP settings on the device through WebSocket.
You can configure NTP settings when importing devices into a site by following the steps in "Sites and devices", or configure NTP settings on the page after importing devices into the site. This example configures NTP settings on the page.
1. Log in to Unified Platform as a tenant service administrator (for example, sdwan).
2. Navigate to the Automation > Branch Networks > Physical Networks > Sites Settings > NTP page. This page displays all added sites.
3. To view NTP
configuration details of a site, click the 
icon
next to that site name. You can manually
edit or import NTP settings.
Figure 65 NTP settings
Manually edit NTP settings
To configure or edit the NTP settings for a
site (for example, Branch4), click the 
icon in the Actions
column for that site. On the page that opens, you can view the current NTP
settings and status, as shown in Figure 66.
· To add an NTP server IP and source interface entry, click Add.
· To delete an NTP server IP and source interface
entry, click the 
icon in the Actions column for that
entry.
Figure 66 Configuring NTP settings
On this page, you can configure the following parameters:
· NTP: Select whether to enable NTP for the device. This feature enables the selected device to use NTP for clock synchronization. The device can act as an NTP server at the same time. To disable NTP, make sure the NTP server IP and source interface pair list is empty.
· Setup Method: Select a setup method. Options include USB/Email and WebSocket. You can edit this parameter only when NTP is disabled.
· Device Name: Name of the device bound to the site.
· NTP Server IP: Specify an NTP server by its IP address. If the clock is synchronized between the device and the controller, configure the IP as the unified northbound address of the controller. If the clock is synchronized between the device and an RR, configure the IP as the system IP of the RR.
· Source Interface: Specify a source interface for NTP-based clock synchronization. If the clock is synchronized between the device and the controller, you do not need to specify this parameter. If the clock is synchronized between the device and an RR, specify the source interface as the loopback interface that uses the system IP of the selected device.
· MDC Context: Specify an MDC context. This parameter is available for only specific devices when the USB/email setup method is used. This parameter will not be displayed when the WebSocket setup method is used.
|
|
CAUTION: · When NTP settings are deployed via USB/email, for an SR66 or later version of router or an F1000-AI-25 or later version of firewall, you must set the MDC context to 1. For devices of other models, you cannot specify the MDC context parameter. · To disable NTP, make sure the NTP server IP and source interface pair list is empty. You can edit this parameter only when NTP is disabled. · When NTP settings are deployed via USB/email, you need to send the NTP settings to a device via a USB drive or URL. Make sure the deployment status is displayed as Deployed. · When NTP settings are deployed via USB/email, you cannot select a tunnel interface or VLAN interface as the source interface. |
Importing NTP settings in bulk
Click Import. On the page that opens, you can download the corresponding template file, edit it, and then upload it to import NTP settings in bulk. The import operation is available for only sites where NTP is disabled. For more information about disabling NTP for a site, see "Manually edit NTP settings."
Figure 67 Bulk importing NTP settings
Figure 68 NTP template
Configure the following parameters:
· Site Name: Name of the site into which the NTP settings are imported.
· NTP: Specify whether to enable NTP.
· Setup Method: Select a setup method. Options include USB/Email and WebSocket.
· Device Name: Name of the device bound to the site.
· NTP Server IP and Source Interface List: IP address of the NTP server and source interface for NTP-based clock synchronization.
· MDC Context: Specify an MDC context. This parameter is available for only specific devices when the USB/email setup method is used.
|
|
CAUTION: · When NTP settings are deployed via USB/email, for an SR66 or later version of router or an F1000-AI-25 or later version of firewall, you must set the MDC context to 1. For devices of other models, you cannot specify the MDC context parameter. · When NTP settings are deployed via USB/email, you need to send the NTP settings to a device via a USB drive or URL. Make sure the deployment status is displayed as Deployed. |
View NTP status
After the controller deploys NTP settings on the selected device, you can perform the following tasks:
· View NTP configuration on the device.
#
clock protocol ntp
ntp-service enable
ntp-service unicast-server 192.168.40.155
#
· Identify whether the devices finishes clock synchronization.
If NTP synchronization is performed from the system IP interface of the RR, NTP synchronization is complete after branch network planning and tunnel establishment finishes.
<Spoke4-1> display ntp-service sessions
source reference stra reach poll now offset delay disper
********************************************************************************
[12345]192.168.40.155 127.127.1.1 10 255 64 10 0.9872 0.5035 4.3335
Notes: 1 source(master), 2 source(peer), 3 selected, 4 candidate, 5 configured.
Total sessions: 1
<Spoke4-1>
Configure RBM
To use DPI in a dual-gateway network, you must add RBM settings.
To configure RBM:
1. Log in to Unified Platform as a tenant service administrator (for example, sdwan).
2. Navigate to the Automation > Branch Networks > Physical Networks > Sites Settings > RBM page. Click Add and configure RBM settings.
Figure 69 Adding RBM settings
Configure the following parameters:
¡ Site Name: Select an existing site.
¡ Primary Device Name: Specify the name of one gateway device in the dual-gateway site.
¡ Use Interconnect Interface: With this feature enabled, the data tunnel interface is the interconnect interface, and the primary device local address and primary device peer address are the interconnect interface address. In the current software version, this feature is enabled and cannot be disabled.
¡ Data Channel Interface: Interconnect interface of the site. Only physical ports are supported.
¡ Traffic Switchback Delay: Specify a value in the range of 1 to 1440 minutes. You can set the delay time as needed.
¡ Protocol Type: IPv4 or IPv6.
¡ Primary Device Local Address/Primary Device Peer Address: Interconnect interface address.
3. Click OK.
Figure 70 RBM settings
4. To import RBM settings, click Import RBM Settings. Fill in the import template as instructed.
Figure 71 RBM import template
|
|
CAUTION: To use RBM in a dual-gateway site network: · Make sure the interconnect interfaces are physical ports and are directly connected (not through Layer 3 networks). · Make sure the two devices have the same model, same modules, and consistent interconnect interfaces. · Except for forwarding through the coordinative tunnel because of scheduling, make sure the traffic does not pass through two devices in the same site (because it cannot be used in conjunction with an interface used for route synchronization). |
Plan branch networks
Configuration workflow
After device onboarding, you can plan branch networks. To configure branch network settings, use the configuration wizard or the menu on the Automation page. The configuration workflow is shown in Figure 72.
Figure 72 Branch network configuration workflow
Prerequisites
Log in to Unified Platform as a tenant service administrator (for example, sdwan).
Manage access zones
Create access zones
1. Navigate to the Guide > Branch Network Deployment > Plan Branch Networks > Access Zones page or navigate to the Automation > Branch Networks > Virtual Networks > Access Zones page.
2. Click Add to access the Add Site Access Zone page, as shown in Figure 73. Add access zone zone1 as planned in"Access zone planning."
Figure 73 Configuring an access zone
Key parameters
¡ Access Zone Name: Name of the access zone to be created.
¡ BFD: Specify whether to enable BFD for the BGP neighbors established between the RRs in the access zone and the CPE sites attached to the access zone For a single-HQ site network, disable BFD as a best practice. For a multi-HQ site network, enable BFD as a best practice. Enable BFD for access zones zone1 and zone2, and do not enable BFD for access zones zone3 and zone4.
¡ Block Communication Between CPE Sites: Specify whether to block communication between CPE sites attached to the access zone. If you enable this feature, the CPE sites attached to the access zone cannot communicate with each other by default. In this case, you must configure an area topology to enable communication between CPE sites attached to the access zone. If you disable this feature, the CPE sites will automatically reflect service routes after they are attached to the access zone, which might cause too big a routing table or generate a large number of invalid overlay links (TTE connections). When CPE sites are attached as clients, enable this feature as a best practice, and you must configure an area topology. When CPE sites are attached as non-clients, disable this feature as a best practice, and you do not need to configure an area topology. In this case, the HQ sends summary routes to implement the hub-spoke network.
|
|
CAUTION: · You must select a minimum of one RR site for an access zone. If the RR site deployment fails, CPEs cannot access the access zone. · For a single-HQ site network, disable BFD as a best practice. For a multi-HQ site network, enable BFD as a best practice, and you must edit the O&M settings to set the global BFD granularity to be lower than the tunnel BFD keepalive granularity. That is, make sure the BFD detection interval and retries to be greater than the tunnel BFD keepalive interval and retries. For more information, see “Configure O&M settings.” · When CPE sites are attached as clients, enable this feature as a best practice, and you must configure an area topology. When CPE sites are attached as non-clients, disable this feature as a best practice, and you do not need to configure an area topology. In this case, the HQ sends summary routes to implement the hub-spoke network. · After you create an access zone, the settings of BFD and blocking communication between CPE sites cannot be edited for the access zone. · If SDWAN versions that do not support blocking communication between CPE sites (versions E64XX and E66XX) are upgraded to SDWAN versions that support this feature (E68XX and later), this feature is disabled by default for the original access zones. |
3. After you finish access zone configuration, the Access Zones page displays the access zone, as shown in Figure 74.
Figure 74 Access zone information
To verify that the RRs associated with the access zone is
deployed, click the 
icon in the Actions column for the access zone, as shown in Figure 75.
4. Add access zones zone2, zone3, and zone4 in the same way that access zone zone1 is added.
Attach CPE sites
1. After you create access
zone zone1, click the 
icon in the Actions column for the access zone, as shown in Figure 76,
select CPE sites Branch1, Branch2, and Branch3, as
planned in "Access zone planning", and then
click Attach as Client.
If the configuration is successfully deployed, the deployment state of CPE sites is Normal, as shown in Figure 77.
Figure 76 Attaching client sites
Figure 77 Sites attached successfully
|
|
CAUTION: · You must configure WAN details for the sites attached. · When sites are attached as clients, TTE and VPN route information can be reflected between sites, and you can use the VPN topology function. When sites are attached as non-clients, the VPN topology function cannot be used, and the hub-spoke network can be implemented only through sending summary routes on hubs. You must configure settings as needed. In this example, sites are attached as clients. |
2. Attach CPE sites to access zones zone2, zone3, and zone4 in the same way that access zone zone1 is configured.
Configure O&M settings
1. Navigate to the Guide > Branch Network Deployment > Plan Branch Networks > O&M Settings page. Click Add to configure O&M settings for a device, as shown in Figure 78.
Configurable O&M settings include statistics polling interval, link selection delay, link selection suppression interval, SDWAN tunnel keepalive interval, and SDWAN tunnel keepalive retries. For more information about the parameters, see Configure O&M settings.
Skip this step if no device-specific O&M settings are needed.
Figure 78 Adding device-specific parameters
Manage VPNs
Add a VPN instance
VPNs are used to isolate service traffic of users. To use VPN for service path transmission, you must configure a minimum of one VPN. In this example, VPN VPN1 is configured.
1. Navigate to the Guide > Branch Network Deployment > Plan Branch Networks > VPNs page or navigate to the Automation > Branch Networks > Virtual Networks > VPNs Management > VPNs page.
2. Click Add, configure the following parameters, and then click OK to save the configuration, as shown in Figure 79.
Figure 79 Adding a VPN instance
The key parameters include:
¡ VPN Name: VPN name saved on the controller, for example, VPN1.
¡ VPN Instance Name: VPN instance configuration deployed to devices, for example, VPN1.
¡ RT: Specify an RT for the VPN instance. If you do not specify this parameter, the controller automatically assigns an RT to the VPN instance.
¡ VN ID: Specify a unique VN ID for the VPN instance. If you do not specify this parameter, the controller automatically assigns a VN ID to the VPN instance. The RD of the VPN on a device, X:Y for example, takes the specified VN ID as X, and the controller assigns a value as Y to make sure each device has a unique VPN RD.
¡ Management VPN: Specify whether to enable the management VPN. If the management VPN is enabled, the management loopback interface routes will be automatically advertised in the VPN.
3. After you add the VPN, click the 
icon
in the Actions column for
the VPN to bind sites to it, as shown in Figure 80.
4. Click Select, select all sites, and then click OK, as shown in Figure 81.
Figure 81 Binding sites to the VPN
Deploy a VPN and view its state
After you add a VPN, the state of the VPN becomes Deployed, as shown in Figure 82.
If the controller fails to deploy a VPN, click
the 
icon in the Actions
column for the VPN to view the state of each site bound to the VPN. Identify
the failure reason, and then click Retry, as shown
in Figure 83.
Figure 83 States of the bound sites
Add an area topology
The area topology is a topology for interconnecting sites based on VPNs according to different service interconnect requirements. In the current solution, create an area topology for the VPN corresponding to an access zone as a best practice. In the current solution, the supported area topology models are as follows:
· Hub-spoke with intra-area branch connectivity—Applicable to the scenario where all branch sites must pass through the HQ to access each other.
· Hub-spoke without intra-area branch connectivity—Applicable to the scenario where the HQ communicates with branches and the branches do not communicate with each other. The RRs do not reflect route information between CPEs. CPEs cannot communicate with each other or can only communicate through summary routes advertised by RRs.
· Full-mesh—Applicable to the scenario where all sites can communicate directly.
You can customize and plan the topology based on the three topology models.
|
|
CAUTION: When SDWAN versions that do not support the area topology feature (versions E64XX and E66XX) are upgraded to SDWAN versions that support this feature (versions E68XX and later), an access zone created before the upgrade also supports configuring an area topology. In this case, make sure CPE sites are attached to the access zone as clients. However, when an area topology is created, new routing policies will be deployed to BGP neighbors to replace the original routing policies. If BGP neighbors have personalized routing policy settings (which are manually configured or deployed by the controller) before an area topology is created, you must migrate these routing policy settings to the new routing policies. |
Add four hub-spoke area topologies as planned in "Area topology planning." After you add the area topologies, you can view them on the Area Topology page, as shown in Figure 84.
The following section uses area topology topo1 as an example to illustrate how to configure area topologies of different models.
Add a hub-spoke area topology with branch connectivity
1. Navigate to the Guide > Branch Network Deployment > Plan Branch Networks > Area Topology page or the Automation > Branch Networks > Virtual Networks > VPNs Management > Area Topology page. Click Add. On the page that opens, add a hub-spoke area topology, add global configuration, and add area RR sites, as shown in Figure 85.
Figure 85 Adding global configuration and area RRs
The key parameters include:
¡ Area Name: Specify the name of an area, which is used to identify the VPN area created. Set the name to topo1 in this example.
¡ VPN Name: Specify the name of a VPN instance to be bound, VPN1 in this example.
¡ Topology: Select a topology model for this area, HUB-SPOKE in this example.
¡ Intra-Area Branch Connectivity: With this feature enabled, the RRs will reflect inter-CPE route information. Select On in this example.
¡ Area RR Site: Specify RRs for the area topology. In this example, select RR site HQ1.
|
|
CAUTION: · You can configure the VPN area topology only when the CPEs are attached as clients. · If you select multiple area RRs, all these RRs must be in the same access zone. · The area RR sites must be the common RRs of area sites. · An RR site cannot act as an area RR site for multiple area topologies in a VPN. · When the area topology changes, invalid overlay links might be generated. For example, when the CPEs change from direct communication to communication via the HQ site, the overlay tunnels for direct communication between sites will become invalid. You must manually delete them. Before deleting overlay tunnels, you must check the reasons why these overlay tunnels become invalid. After you delete the overlay tunnels, all history information of them will be deleted. Perform this operation with caution. · After you add a topology policy with the interconnect mode as Not Interconnect for an area, you cannot disable the intra-area branch connectivity feature for the area. |
2. Add an HQ site, as shown in Figure 86. Only an area RR can act as an HQ site.
Key parameters
¡ HQ Site: Select an HQ site from the list. In the current software version, only an area RR can be configured as an HQ site. In this example, select site HQ1.
¡ Default Priority: When you add an HQ site, you can specify a priority for it. A smaller priority value means a higher priority. By setting the priority, you can specify the traffic forwarding priority for the HQ site. Set the default priority to 0 in this example, because the current software version supports specifying only one HQ site.
|
|
CAUTION: An HQ site must be an area RR. In the current software version, you can specify only one HQ site. |
3. Add branch sites, as shown in Figure 87. Select CPEs in the area as branch sites.
The key parameters include:
¡ Branch Site: Select branch sites from the list. In this example, select sites Branch1, Branch2, and Branch3 of access zone zone1.
¡ Area Local Priority: Set the area local priority for the branch sites to access the HQ sites. In a multi-HQ network, multiple access zones and area topologies are required, and each branch site must be added into multiple area topologies. Specify the area local priority based on the dual-HQ network model:
- If the two HQs are in the active-active mode and advertise the same overlay route, a branch site selects an HQ based on the cost value of the route. In this case, specify the same area local priority for the branch sites. For more information about overlay routes advertisement, see "Configure overlay routes."
- If the two HQs are in the active-active mode and advertise different detailed overlay routes, they advertise a summary route for backup. In this case, specify different area local priorities for the branch sites. The default value is 100. A larger value indicates a higher priority. Branch sites communicate with each other based on the area topology with the higher priority. When the two HQs advertise the same route, branch sites communicate with each other through the HQ with the higher priority. For more information about overlay route advertisement, see "Configure overlay routes."
- If the two HQs are independent and advertise different overlay routes, specify different area local priorities for the branch sites. The default value is 100. A larger value indicates a higher priority. Branch sites communicate with each other based on the area topology with the higher priority. For more information about overlay route advertisement, see "Configure overlay routes."
¡ HQ Site: Specify the HQ site for forwarding traffic of branch sites. When you specify multiple HQ sites, you can specify different priority values for them. A smaller priority value means a higher priority. Use the default priority 0 in this example.
|
|
CAUTION: · In the current software version, you can specify only one HQ site. · Branch sites must be attached to area RR sites through clients. · When CPE sites (including sites of the CPE+RR role) use one VPN to access multiple area topologies, inter-branch communication selects an area topology as follows: 1. When a branch site has different area local priorities for accessing different area topologies, the area topology with the highest priority is selected. 2. When a branch site has the same area local priority for accessing different area topologies, the hub-spoke area topology is selected. 3. When all area topologies use the hub-spoke model, the area topology bound to the RR with the smallest system IP is selected. |
4. After the hub-spoke VPN area topology is added, verify that the state of the area topology is Deployed, as shown in Figure 88.
Figure 88 Hub-spoke topology deployment state
5. If the deployment state is Deployment Failed, click the link in the State column to view the RR-CPE state. If the deployment state is abnormal, click Retry, as shown in Figure 89.
Add a hub-spoke area topology without branch connectivity
1. Navigate to the Guide > Branch Network Deployment > Plan Branch Networks > > Area Topology page or the Automation > Branch Networks > Virtual Networks > VPNs Management > Area Topology page. Click Add. On the page that opens, add a hub-spoke area topology, add global configuration, and add area RR sites, as shown in Figure 90.
Figure 90 Adding global configuration and area RRs
Key parameters
¡ Area Name: Specify the name of an area, which is used to identify the VPN area created. Set the name to topo1 in this example.
¡ VPN Name: Specify the name of a VPN instance to be bound, VPN1 in this example.
¡ Topology: Select a topology model for this area, HUB-SPOKE in this example.
¡ Intra-Area Branch Connectivity: With this feature disabled, the RRs will not reflect inter-CPE route information. Select Off in this example.
¡ Area RR Site: Specify RRs for the area topology. In this example, select RR site HQ1.
|
|
CAUTION: · You can configure the VPN area topology only when the CPEs are attached as clients. · If you select multiple area RRs, all these RRs must be in the same access zone. · The area RR sites must be the common RRs of area sites. · An RR site cannot act as an area RR site in multiple area topologies. · When the area topology changes, invalid overlay links might be generated. For example, when the CPEs change from direct communication to communication via the HQ site, the overlay tunnels for direct communication between sites will become invalid. You must manually delete them. Before deleting overlay tunnels, you must check the reasons why these overlay tunnels become invalid. After you delete the overlay tunnels, all history information of them will be deleted. Perform this operation with caution. · After you add a topology policy with the interconnect mode as Interconnect Through a Gateway Site for an area, you cannot enable the intra-area branch connectivity feature for the area. |
2. Add an HQ site, as shown in Figure 91. Only an area RR can act as an HQ site.
The key parameters include:
¡ HQ Site: Select an HQ site from the list. In the current software version, only an area RR can be configured as an HQ site. In this example, select site HQ1.
¡ Default Priority: When you add an HQ site, you can specify a priority for it. A smaller priority value means a higher priority. By setting the priority, you can specify the traffic forwarding priority for the HQ site. Set the default priority to 0 in this example, because the current software version supports specifying only one HQ site.
|
|
CAUTION: An HQ site must be an area RR. In the current software version, you can specify only one HQ site. |
3. Add branch sites, as shown in Figure 92. Select CPEs in the area as branch sites.
The key parameters include:
¡ Branch Site: Select branch sites from the list. In this example, select sites Branch1, Branch2, and Branch3 of access zone zone1.
¡ Area Local Priority: Set the area local priority for the branch sites to access the HQ sites. In a multi-HQ network, multiple access zones and area topologies are required, and each branch site must be added into multiple area topologies. Specify the area local priority based on the dual-HQ network model:
- If the two HQs are in the active-active mode and advertise the same overlay route, a branch site selects an HQ based on the cost value of the route. In this case, specify the same area local priority for the branch sites. For more information about overlay route advertisement, see "Configure overlay routes."
- If the two HQs are in the active-active mode and advertise different detailed overlay routes, they advertise a summary route for backup. In this case, specify different area local priorities for the branch sites. The default value is 100. A larger value indicates a higher priority. Branch sites communicate with each other based on the area topology with the higher priority. When the two HQs advertise the same route, branch sites communicate with each other through the HQ with the higher priority. For more information about overlay route advertisement, see "Configure overlay routes."
- If the two HQs are independent and advertise different overlay routes, specify different area local priorities for the branch sites. The default value is 100. A larger value indicates a higher priority. Branch sites communicate with each other based on the area topology with the higher priority. For more information about overlay route advertisement, see "Configure overlay routes."
¡ HQ Site: Specify the HQ site for forwarding traffic of branch sites. When you specify multiple HQ sites, you can specify different priority values for them. A smaller priority value means a higher priority. Use the default priority 0 in this example.
|
|
CAUTION: · In the current software version, you can specify only one HQ site. · Branch sites must be attached to area RR sites through clients. · When CPE sites (including sites of the CPE+RR role) use one VPN to access multiple area topologies, inter-branch communication selects an area topology as follows: 1. When a branch site has different area local priorities for accessing different area topologies, the area topology with the highest priority is selected. 2. When a branch site has the same area local priority for accessing different area topologies, the hub-spoke area topology is selected. 3. When all area topologies use the hub-spoke model, the area topology bound to the RR with the smallest system IP is selected. |
4. After the hub-spoke VPN area topology is added, verify that the state of the area topology is Deployed, as shown in Figure 93.
Figure 93 Hub-spoke topology deployment state
5. If the deployment state is Deployment Failed, click the link in the State column to view the RR-CPE state. If the deployment state is abnormal, click Retry, as shown in Figure 94.
Add a full-mesh area topology
1. Navigate to the Guide > Branch Network Deployment > Plan Branch Networks > Area Topology page or the Automation > Branch Networks > Virtual Networks > VPNs Management > Area Topology page. Click Add. On the page that opens, add a full-mesh area topology, as shown in Figure 95.
Figure 95 Add a full-mesh topology
The key parameters include:
¡ Area Name: Specify the name of an area, which is used to identify the VPN area created. Set the name to topo1 in this example.
¡ VPN Name: Specify the name of a VPN instance to be bound, VPN1 in this example.
¡ Topology: Select a topology model for this area, FULL-MESH in this example.
¡ Area RR Site: Specify RRs for the area topology. In this example, select RR site HQ1.
¡ Branch Site: Select branch sites, and select all sites in the access zone. In this example, select branch sites Branch1, Branch2, and Branch3, and select site HQ1.
¡ Area Local Priority: Set the area local priority to 200 for the branch sites to access the HQ sites. In a multi-HQ network, multiple access zones and area topologies are required, and each branch site must be added into multiple area topologies. Specify the area local priority based on the dual-HQ network model:
- If the two HQs are in the active-active mode and advertise the same overlay route, a branch site selects an HQ based on the cost value of the route. In this case, specify the same area local priority for the branch sites. For more information about overlay route advertisement, see "Configure overlay routes."
- If the two HQs are in the active-active mode and advertise different detailed overlay routes, they advertise a summary route for backup. In this case, specify different area local priorities for the branch sites. The default value is 100. A larger value indicates a higher priority. Branch sites communicate with each other based on the area topology with the higher priority. When the two HQs advertise the same route, branch sites communicate with each other through the HQ with the higher priority. For more information about overlay route advertisement, see "Configure overlay routes."
- If the two HQs are independent and advertise different overlay routes, specify different area local priorities for the branch sites. The default value is 100. A larger value indicates a higher priority. Branch sites communicate with each other based on the area topology with the higher priority. For more information about overlay route advertisement, see "Configure overlay routes."
|
|
CAUTION: · You can configure the VPN area topology only when the CPEs are attached as clients. · If you select multiple area RRs, all these RRs must be in the same access zone. · The area RR sites must be the common RRs of area sites. · An RR site cannot act as an area RR site in multiple area topologies. · When the area topology changes, invalid overlay links might be generated. For example, when the CPEs change from direct communication to communication via the HQ site, the overlay tunnels for direct communication between sites will become invalid. You must manually delete them. Before deleting overlay tunnels, you must check the reasons why these overlay tunnels become invalid. After you delete the overlay tunnels, all history information of them will be deleted. Perform this operation with caution. · The branch sites must be connected to the area RR site through clients. · When CPE sites (including sites of the CPE+RR role) use one VPN to access multiple area topologies, inter-branch communication selects an area topology as follows: 1. When a branch site has different area local priorities for accessing different area topologies, the area topology with the highest priority is selected. 2. When a branch site has the same area local priority for accessing different area topologies, the hub-spoke area topology is selected. 3. When all area topologies use the hub-spoke model, the area topology bound to the RR with the smallest system IP is selected. |
If an area RR site in the full-mesh area topology participates in service traffic forwarding (a site of the CPE+RR role), you must configure the area RR site as a branch site in the area topology.
2. After the full-mesh VPN area topology is added, verify that the state of the area topology is Deployed, as shown in Figure 96.
Figure 96 Full-mesh topology deployment state
3. If the deployment state is Deployment Failed, click the link in the State column to view the RR-CPE state. If the deployment state is abnormal, click Retry, as shown in Figure 97.
Add a topology policy
After an area topology is added, you can add topology policies for it.
Add a topology policy for a hub-spoke area topology with branch connectivity
1. Navigate to the Guide > Branch Network Deployment > Plan Branch Networks > Topology Policy page or the Automation > Branch Networks > Virtual Networks > VPNs Management > Topology Policy page. Click Add to add an area topology, as shown in Figure 98.
Figure 98 Adding a topology policy
The key parameters include:
¡ Site A/Site B: Configure a topology policy for the two selected sites. In this example, select sites Branch2 and Branch3.
¡ Interconnect Mode: If you specify Interconnect Directly, site A and site B can directly communicate. If you specify Not Interconnect, the RRs will not reflect routes between the two sites, and site A and site B cannot communicate. In this example, select Interconnect Directly.
|
|
CAUTION: When the area topology changes, invalid overlay links might be generated. For example, when the CPEs change from direct communication to communication via the HQ site, the overlay tunnels for direct communication between sites will become invalid. You must manually delete them. Before deleting overlay tunnels, you must check the reasons why these overlay tunnels become invalid. After you delete the overlay tunnels, all history information of them will be deleted. Perform this operation with caution. |
Add a topology policy for a hub-spoke area topology without branch connectivity
1. Navigate to the Guide > Branch Network Deployment > Plan Branch Networks > Topology Policy page or the Automation > Branch Networks > Virtual Networks > VPNs Management > Topology Policy page. Click Add to add an area topology, as shown in Figure 99.
Figure 99 Adding a topology policy
The key parameters include:
¡ Site A/Site B: Configure a topology policy for the two selected sites. In this example, select sites Branch2 and Branch3.
¡ Interconnect Mode: If you specify Interconnect Directly, site A and site B can directly communicate. If you specify Interconnect Through a Gateway Site, site A and site B can communicate through a gateway site. In this example, select Interconnect Through a Gateway Site.
¡ Gateway Site: Specify the next hop site list for communication between site A and site B. In this example, they communicate through the HQ. Select HQ1.
¡ Default Priority: Configure the default priority for the HQ site as 0.
|
|
CAUTION: · When the area topology changes, invalid overlay links might be generated. For example, when the CPEs change from direct communication to communication via the HQ site, the overlay tunnels for direct communication between sites will become invalid. You must manually delete them. Before deleting overlay tunnels, you must check the reasons why these overlay tunnels become invalid. After you delete the overlay tunnels, all history information of them will be deleted. Perform this operation with caution. · An HQ site must be an area RR. In the current software version, you can specify only one HQ site. · If the intra-area branch connectivity feature is disabled for an area topology, you cannot add a topology policy with the interconnect mode of Not Interconnect. |
Add a topology policy for a full-mesh area topology
1. Navigate to the Guide > Branch Network Deployment > Plan Branch Networks > Topology Policy page or the Automation > Branch Networks > Virtual Networks > VPNs Management > Topology Policy page. Click Add to add an area topology, as shown in Figure 100.
Figure 100 Adding a topology policy
The key parameters include:
¡ Site A/Site B: Configure a topology policy for the two selected sites. In this example, select sites Branch1 and Branch2.
¡ Interconnect Mode: If you specify Interconnect Through a Gateway Site, site A and site B can communicate through a gateway site. If you specify Not Interconnect, the RRs will not reflect routes between the two sites, and site A and site B cannot communicate. In this example, select Interconnect Through a Gateway Site.
¡ Gateway Site: Specify the next hop site list for communication between site A and site B. If you specify no gateway sites, site A and site B directly communicate. In this example, they communicate through the HQ. Select HQ1.
¡ Default Priority: Configure the default priority for the HQ site as 0.
|
|
CAUTION: · When the area topology changes, invalid overlay links might be generated. For example, when the CPEs change from direct communication to communication via the HQ site, the overlay tunnels for direct communication between sites will become invalid. You must manually delete them. Before deleting overlay tunnels, you must check the reasons why these overlay tunnels become invalid. After you delete the overlay tunnels, all history information of them will be deleted. Perform this operation with caution. · An HQ site must be an area RR. In the current software version, you can specify only one HQ site. |
Add an area interconnect
To make sure the border sites of area topologies can communicate with each other, perform the following task to configure an area interconnect as planned in "Area interconnect planning":
1. Navigate to the Guide > Branch Network Deployment > Plan Branch Networks > Area Interconnect page or the Automation > Branch Networks > Virtual Networks > VPNs Management > Area Interconnect page.
2. Click Add to add an area interconnect, as shown in Figure 101.
Figure 101 Adding an area interconnect
The key parameters include:
¡ VPN Name: Select a VPN to which the area interconnect is bound. In this example, select VPN1.
¡ Interconnect Area A: Select an area topology. In this example, select topo1.
¡ Interconnect Area B: Select an area topology. In this example, select topo3.
¡ Border Site: Select a border site for site communication between the two areas. In this example, select Branch1. A border site is in both area A and area B.
¡ Primary Area: Select an area as the primary area. When multiple border sites exist and require communication with each other, the communication is based on the network model of the primary area. In this example, select either topo1 or topo3, because the current software version supports specifying only one border site.
3. After you add the area interconnect, verify that the state of the area interconnect is Deployed, as shown in Figure 102.
Figure 102 Area interconnect state
4. If the state is Deployment Failed, click the link in the State column to view the border site state. If the deployment state is abnormal, click Retry, as shown in Figure 103.
|
|
CAUTION: Delete an area interconnect with caution, because this operation will cause network disconnection. |
Configure LAN networks
1. Navigate to the Guide > Branch Network Deployment > Plan Branch Networks > Configure LAN Networks page or the Automation > Branch Networks > Virtual Networks > VPNs Management > LAN Networks Deployment page.
2. Click Add to add LAN networks according to the actual network requirements, as shown in Figure 104. In this example, configure a subinterface as the LAN interface of the hub and create two LANs for use by VLAN40 and VLAN41.
Figure 104 Configuring LAN networks
Add LAN service network details
Navigate to the Guide > Branch Network Deployment > Plan Branch Networks > LAN Service Network Details page or the Automation > Branch Networks > Virtual Networks > VPNs Management > LAN Deployment page, and you can import or manually add LAN network details.
Import LAN service network details
1. Click Download Template to download a template, and then enter LAN network detail information in the template according to the networking model and the instructions.
¡ Site Name: Specify a site for the LAN by its name.
¡ Access Device Name: Specify an access device for the LAN by its name.
¡ LAN Interface Operating Mode: Select the bridge mode for a routing switch. Typically, select the route mode.
¡ Create Subinterface: In the route mode, you must specify whether to create a subinterface on the specified access interface on the access device to deploy the configuration. On the subinterface, use the VLAN ID configured in the LAN network to configure VLAN termination. If no VLAN ID is configured for the LAN network , the subinterface cannot be created.
¡ Access Interface: Name of the interface that provides access to the LAN service network.
¡ Service Name: Name of an existing LAN service network.
¡ LAN Interface IP: LAN interface IP address deployed by the controller.
¡ LAN Interface Subaddresses: Secondary IP addresses of the LAN interface. You can specify multiple secondary IP addresses.
¡ LAN Interface IPv6: IPv6 addresses of the LAN interface. You can specify multiple LAN interface IPv6 addresses.
¡ VPN Name: Name of the VPN instance bound to LAN interface. In the EVPN solution, all the LAN interfaces must be bound to VPN instances.
¡ Enable DHCP: Specify whether to enable the IPV4 DHCP service on the LAN interface. For more information about this parameter, see the description in the template or the online help.
¡ Enable DHCPv6: Specify whether to enable the IPV6 DHCPv6 service. For more information about this parameter, see the description in the template or the online help.
¡ Enable VRRP: Specify whether to enable VRRP. If you enable this feature, configure a VRRP ID and a virtual IP. If two gateways are enabled with VRRP, configure the same VRRP ID and virtual IP for them.
¡ Enable IPv6 VRRP: Specify whether to enable IPv6 VRRP. If you enable this feature, configure a VRRP ID, a virtual IPv6 address, and a link-local address. If two gateways are enabled with IPv6 VRRP, configure the same VRRP ID and virtual IPv6 address for them. When you specify a link-local address, make sure it starts with fe80::.
¡ MTU: MTU of the interface. By default, the interface has an MTU. As a best practice, do not set this field.
¡ TCP MSS: Maximum TCP packet fragment size. You must configure this field for LAN services deployed by the controller. As a best practice, set the TCP MSS to 1280.
¡ Auto Import LAN-side Routes: Configure the controller to import routes of the LAN interfaces through routing policies. As a best practice, select Yes for branches. You must manually import routes of the LAN interfaces for headquarters.
After LAN service network details are imported as shown in Figure 105, you can view the deployment state on the Automation > Branch Networks > Virtual Networks > VPNs Management > LAN Deployment page. If the deployment state is abnormal, you can click the state to view the failure reasons. Troubleshoot the anomalies according to the failure reasons, and click Retry to deploy the LAN service network details again.
Figure 105 Importing LAN service network details
|
|
CAUTION: · When importing or adding LAN service network details, you must set TCP MSS to 1280. · Multiple sites share one internal network or use a dual-gateway site network, and dynamic routes are used for communication between devices and the internal network. For example, you must manually configure routes to redirect traffic for site HQ1. · The single-device site network or dual-gateway site network uses static routes or VRRP for communication with the internal network. For example, the branch sites can select to use automatic routes to redirect traffic. · After you add a LAN service network detail, you cannot change the enabling status of DHCP. · DHCPv6 servers and DHCPv6 relay agents support only stateful address autoconfiguration. |
Manually add LAN service network details
1. Click Add in the LAN Service Network Details area. You can manually add a LAN service network detail, as shown in Figure 106. For more information about related parameters, see "Import LAN service network details."
Figure 106 Manually adding a LAN network detail
Overlay link O&M and topology search
After you configure an access topology, the controller will deploy the corresponding routing policy settings. After LAN service network details are imported, the devices can generate the corresponding overlay links (TTE connections), and you can use the controller to search for overlay links and topology information.
|
|
NOTE: Overlay links (TTE connections) are established between CPE and RR following these principles: · When the WAN network across transmission switch is turned off, overlay links (TTE connections) can be established between CPE and RR only when they are in the same WAN network, the same service plane, and the same transport network. · When the WAN network across transmission switch is turned on, overlay links (TTE connections) can be established between CPE and RR only when they are in the same WAN network and the same service plane. The transport networks are not required to be the same. Overlay links (TTE connections) are established between CPEs following these principles: · When the WAN network across transmission switch is turned off, overlay links (TTE connections) can be established between CPEs only when they are in the same WAN network, the same service plane, and the same transport network, and the CPEs can exchange TTE information through RRs and have direct routes in between. · When the WAN network across transmission switch is turned on, overlay links (TTE connections) can be established between CPEs only when they are in the same WAN network and the same service plane, and the CPEs can exchange TTE information through RRs and have direct routes in between. The transport networks are not required to be the same. |
Navigate to the Automation > Branch Networks > Virtual Networks > Virtual Links > Links page. You can search for overlay link information, as shown in Figure 107.
Figure 107 Overlay link information
An overlay link can be in one of the following states:
· Normal: The overlay link is normal.
· Offline: The overlay link is offline because the device is unincorporated or the TTE connection state is abnormal. You must further troubleshoot this issue.
· Minor/Major/Critical Alarm: The link has an alarm. Click the state to obtain the alarm information.
· Deactive: The overlay link is deactive because the corresponding TTE
connection does not exist on the device. Possible reasons for the deactive
overlay link state include the corresponding tunnel is abnormal or the topology
changes. In this case, you must identify whether the overlay links will be used
later. If you do not need the overlay link later, click 
to
manually delete the link.
|
|
CAUTION: If the corresponding TTE connection recovers after the overlay link is deleted, the device will report the overlay link again. However, the history information of the link has been deleted. Perform this operation with caution. |
Manually deploy configuration and check status
The solution allows you to configure settings that cannot be automatically configured by the controller on the device.
Restrictions and guidelines
· As a best practice, do not manually edit or delete the commands deployed by the controller. To do so, contact Technical Support.
· To avoid automatic rollback of the edited or deleted configuration, do not restart the device 30 minutes after you edit or delete the configuration deployed by the controller.
Manually deploy configuration
Switch the working mode
On an MSR device with small memory (smaller than 2G), you must switch the device to the SD-WAN mode to optimize the memory usage. After switching the working mode for an MSR device, you must reboot the device. All MSR devices support switching to the SD-WAN mode.
For an SR66 device, you do not need to switch it to SD-WAN mode.
Execute the following commands to switch the working mode:
<Spoke1-1>system-view
System View: return to User View with Ctrl+Z.
[Spoke1]system-working-mode sd-wan
Do you want to change the system working mode? [Y/N]:y
The system working mode is changed, please save the configuration and reboot the system to make it effective.
[Spoke1]quit
<Spoke1>reboot
|
|
IMPORTANT: After switching the working mode to SD-WAN for a device, you cannot perform deployment via URL. To use deployment via URL, first perform deployment and then switch the working mode. |
Deploy tunnel configuration
In dual-gateway networking, the controller deploys UDP-encapsulated SDWAN tunnels and GRE-encapsulated SDWAN extended tunnels.
· Router: For an IRF fabric or modular device, you must execute the service slot or service chassis x slot x command on the UDP-encapsulated SDWAN tunnel interfaces to specify a traffic processing slot.
· Firewall: For an IRF fabric, you must execute the service slot or service chassis x slot x command on the UDP-encapsulated SDWAN tunnel interfaces to specify a traffic processing slot.
The controller cannot deploy this command automatically.
|
|
CAUTION: Specifying a traffic processing slot for a tunnel interface can cause tunnel flapping and the TTE related to the tunnel will be rebuilt. This practice will affect the traffic on the overlay link (TTE connection). |
· You must manually add more configuration for a UDP-encapsulated SDWAN tunnel.
#
interface Tunnel1 mode sdwan udp //UDP-encapsulated SDWAN tunnel mode
bandwidth 100000
service slot 3 //You must manually configure this command.
ip address unnumbered interface GigabitEthernet3/4/3
source GigabitEthernet3/4/3
tunnel out-interface GigabitEthernet3/4/3
ipv6 address auto link-local
tunnel protection ipsec profile adwan-ipsec-profile
sdwan interface-id 1
sdwan routing-domain 200 id 200
sdwan transport-network CT.1 id 1
sdwan group-id 1
sdwan encapsulation udp-port 12288
sdwan nat-global-ip 110.1.1.1
sdwan bfd enable template tunnelBfdTemplate
sdwan collaboration peer-device-id 2
#
· You do not need to manually configure more settings for a GRE-encapsulated SDWAN tunnel.
#
interface Tunnel4 mode sdwan-ex gre //GRE-encapsulated extended SDWAN tunnel mode
ip address unnumbered interface GigabitEthernet3/4/1
source GigabitEthernet3/4/1
destination 30.1.1.2
gre key 1
tunnel bfd enable template extendTunnelBfdTemplate
ipv6 address auto link-local
#
Optimize OSPF configuration
Optimize VPN multi-instance configuration
You can use the controller to deploy OSPF multi-instance configuration (bound to VPNs). If you configure OSPF multi-instance or OSPFv3 multi-instance settings manually, you must add the vpn-instance-capability simple command to disable routing loop detection for a VPN OSPF process. The controller can deploy this command automatically.
1. OSPF VPN multi-instance configuration
ospf 10 router-id 20.1.11.2 vpn-instance VPN1
vpn-instance-capability simple
2. OSPFv3 VPN multi-instance configuration
#
ospfv3 100 vpn-instance VPN1
router-id 9.9.9.9
vpn-instance-capability simple
#
Optimize NSR configuration
When the device has multiple MPUs (for example, an IRF fabric or modular device with two MPUs), NSR must be configured for OSPF. NSR ensures that the device can automatically recover link state and regenerate routes upon active/standby MPU switchover without interrupting adjacency relationships. In this way, NSR avoids the impact of active/standby switchover on forwarding services.
When multiple OSPF processes exist, each process must be configured.
1. OSPF NSR configuration
ospf 10 router-id 20.1.11.2 vpn-instance VPN1
non-stop-routing
2. OSPFv3 NSR configuration
ospfv3 100 vpn-instance VPN1
non-stop-routing
Optimize BGP configuration
Optimized NSR configuration
When the device has multiple MPUs (for example, an IRF fabric or modular device with two MPUs), NSR must be configured for BGP. NSR ensures that the standby process can seamlessly take over when the active process is interrupted. In this way, NSR ensures that the peer is unaware of the BGP protocol interruption, maintains BGP routes, and ensures that forwarding is uninterrupted.
Example:
#
bgp 6000
non-stop-routing
#
Optimize RIP configuration
When the device has multiple MPUs (for example, an IRF fabric or modular device with two MPUs), RIP must be configured with NSR. NSR synchronizes the route information from the active process to the standby process and ensures that the active process can seamlessly regenerate and issue routes upon active/standby MPU switchover without interrupting adjacency relationships. In this way, NSR avoids the impact of active/standby switchover on forwarding services.
Example:
#
rip 1
non-stop-routing
#
Optimize static route configuration
When a device has multiple network access ports, a static default route pointing to the network access outgoing interface must be configured through the controller or manually. A CPE device uses this route to register with the controller (which is mapped to the public network) and establish TTE connections to RRs (initial TLS connection and subsequent TTE connections). When the CPE has multiple public network egresses, multiple static routes will form ECMP routes. When the CPE registers with the controller and establishes TLS connections to RRs, a route is selected based on ECMP route hash. Only one route is selected for forwarding, so you must configure it to collaborate with a track entry to ensure convergence of failed routes.
Example:
As required by the project, select one or more public network addresses for probe(select two in this example). If the public network addresses fail to be probed, the default route will become invalid.
#
track 2 nqa entry test 1 reaction 1
#
track 3 nqa entry test 2 reaction 1
#
track 10 list boolean or // If both probes fail, the entire probe operation fails.
object 2
object 3
#
nqa entry test 1
type icmp-echo
destination ip 180.76.76.76 //Public network address 1 probed, which is selected based on the project.
frequency 1000
out interface GigabitEthernet0/1 //Output interface for probe packets, and outgoing interface of the default route
reaction 1 checked-element probe-fail threshold-type consecutive 5 action-type trigger-only
source interface GigabitEthernet0/1
#
nqa entry test 2
type icmp-echo
destination ip 223.5.5.5 //Public network address 1 probed, which is selected based on the project.
frequency 1000
out interface GigabitEthernet0/1 //Output interface for probe packets, and outgoing interface of the default route
reaction 1 checked-element probe-fail threshold-type consecutive 5 action-type trigger-only
source interface GigabitEthernet0/1
#
nqa schedule test 1 start-time now lifetime forever
nqa schedule test 2 start-time now lifetime forever
#
ip route-static 0.0.0.0 0 GigabitEthernet0/1 dhcp track 10 ///Track entry collaborating with the default route
ip route-static 180.76.76.76 32 GigabitEthernet0/1 dhcp
ip route-static 223.5.5.5 32 GigabitEthernet0/1 dhcp //Add static routes for two probe destination addresses to ensure that the corresponding routes exist after probe failures, so that probes can continue
Optimize other configuration
1. The TCP MSS function will trigger session setup. Setting the tcp-est aging time to 3600s will cause many sessions to be held. In this case, change the tcp-est aging time to 300s.
session aging-time state tcp-est 300
2. When aggregation is configured for an IRF member device or modular device, you must configure the service slot or service chassis x slot x command to specify a traffic processing slot for an aggregate interface for the NAT device to synchronize sessions automatically. The controller cannot deploy this command automatically.
interface Route-Aggregation3
service chassis 1 slot 3
Check for configuration that affects features
Some configuration might affect service deployment and intelligent path selection. You must check for such configuration and delete it, if any.
1. SaaS path optimization will affect traffic path selection.
¡ Identify whether the following command is configured:
saas-path-optimize
¡ If the command is configured, manually delete the configuration:
undo saas-path-optimize
2. Management IP address 192.168.0.1 of the first interface or VLAN-interface 1 in the initial configuration of MSR devices. This address is used for deployment via URL. This address might conflict with the IP addresses on the live network. As a best practice, manually delete this address after deployment.
interface GigabitEthernet 0/0
undo ip address
interface Vlan-interface 1
undo ip address
Manual configuration on the firewall
Configuration of registration via Websocket
When you delete the WAN interface used by registration via WebSocket, the security controller will reclaim the security zone configuration of the WAN interface. As a result, the device fails to register via WebSocket. Manually add the WebSocket registration address to the security zone to ensure that the management channel is stable.
#
security-zone name AdwanUntrustPublic
import ip 192.168.40.155 32 //Add the WebSocket registration address (unified northbound address or mapped public address) to avoid device disconnection when the interface changes.
#
Security policy related configuration
If no security controller is deployed, you need to manually configure security policies, add interfaces to security zones, and apply security policies.
Specific configuration includes the following:
#
security-zone name AdwanDefaultPublic //System IP, site gateway interconnect interface, and the non-LAN/WAN interfaces to be permitted
import interface GigabitEthernet1/0/1
import interface GigabitEthernet1/0/2
import interface LoopBack1
#
security-zone name Adt_vpn1 //LAN interface. If multiple VPNs exist, you can create multiple LAN interfaces for the VPNs.
import interface GigabitEthernet1/0/3
#
security-zone name AdwanMiddlePublic //All tunnel interfaces, including the SDWAN tunnel interface and the interconnect GRE tunnel.
import interface Tunnel1
import interface Tunnel2
#
security-policy ip
rule 1 name SDN_AdwanUntrustPublic_Adt_vpn1 //Drop the return packets of local Internet access by default
counting enable
source-zone AdwanUntrustPublic
destination-zone Adt_vpn1
rule 3 name SDN_AdwanUntrustPublic_AdwanMiddlePublic //Drop the return packets of centralized Internet access by default
counting enable
source-zone AdwanUntrustPublic
destination-zone AdwanMiddlePublic
rule 2 name SDN_Any_Any_vpn1
action pass
counting enable
vrf vpn1
rule 0 name SDN_Any_Any_
description SDN_DEFAULT-ip
action pass
counting enable
NOTE: If the security policy already has rules configured, place rule 2 and rule 0 at the bottom of the security policy to match all packets that do not match other rules, as follows:
[Spoke1-1]security-policy ip
[Spoke1-1-security-policy-ip]move rule 2 bottom
[Spoke1-1-security-policy-ip]move rule 0 bottom
Loose mode of session state machine
If no security controller is not deployed, you need to manually set the mode of session state machine to loose.
[Spoke1-1]session state-machine mode loose
WAN service deployment
Configuration workflow
WAN service deployment includes deploying application TE settings and the related QoS services. The configuration workflow is shown in Figure 108.
Figure 108 Flowchart of configuring process
Configure route redistribution
Route redistribution configuration includes LAN-side route configuration, overlay route configuration, and dual-gateway route synchronization configuration. You must first complete route configuration.
Configure routing settings on the LAN side
An HQ1 device uses OSPF to communicate with the internal network. After the controller deploys LAN interface settings, you must configure routing settings on the LAN side. The following uses Hub1-1 as an example.
Create LAN-side IPv4 routes
1. Log in to Unified Platform as a tenant service administrator (sdwan). Navigate to the Automation > Branch Networks > Physical Networks > Device Settings > OSPF Routes page, and then click Add to add an OSPF process for Hub1-1, as shown in Figure 109 and Figure 110.
Figure 109 Adding an OSPF route (1)
Figure 110 Adding an OSPF route (2)
Key parameters:
¡ Process ID: Specify a new process ID. ID 10 is specified in this example.
¡ Router ID: Specify a router ID. You must specify a router ID, because the hub device establishes an OSPF neighbor relationship with the LAN through the LAN interface and management interface, respectively. The router ID is LAN interface address 20.1.10.2 in this example.
¡ VPN Instance Name: Specify the name of the bound VPN instance, VPN1 in this example.
¡ Protocol Type: Enter OSPF.
¡ Interface List: Specify LAN interface GE2/0.2 and configure area 0.0.0.0.
¡ Cost: Specify the cost for the OSPF neighbor.
2. Click OK.
Create LAN-side IPv6 routes
1. Log in to Unified Platform as a tenant service administrator (sdwan). Navigate to the Automation > Branch Networks > Physical Networks > Device Settings > OSPF Routes page, and then click Add to add an OSPF process for Hub1-1, as shown in Figure 111.
Figure 111 Adding an OSPFv3 route
Key parameters:
¡ Process ID: Specify a new OSPFv3 ID. ID 20 is specified in this example.
¡ Router ID: Specify a router ID. The router ID is LAN interface address 20.1.10.2 in this example.
¡ VPN Instance Name: Specify the name of the bound VPN instance, VPN1 in this example.
¡ Protocol Type: Enter OSPFv3.
¡ Interface List: Specify LAN interface GE2/0.2 and configure area 0.0.0.0.
¡ Cost: Specify the cost for the OSPFv3 neighbor.
2. Click OK.
Configure overlay routes
The following route redistributions modes are available:
· Manual—Multiple sites share one internal network or two gateways are deployed, and devices and the internal network communicate through dynamic routing. For example, you must manually redistribute routes for an HQ1 site.
· Automatic—Use automatic route redistribution in the single-gateway scenario or in the dual-gateway scenario with static routing or VRRP configured for communication with the internal network. For example, HQ2 and branch sites use automatic route redistribution. For more information, see "Import LAN service network details."
This section uses Hub1-1 as an example to describe how to configure manual route redistribution. Manual overlay route redistribution supports the following methods:
1. Filter redistributed overlay routes by label. Create a routing policy to filter OSPF routes redistributed into BGP by label, and add the associated label when redistributing BGP routes into OSPF. For more information about the configuration, see "Redistribute overlay routes into the LAN” to prevent route loops generated when Hub1-1 redistribute routes redistributed by Hub1-2 to OSPF to the overlay again. This method applies when large numbers of headquarters routes exist and internal network segments cannot be clearly defined.
2. Create a routing policy to filter redistributed overlay routes by prefix list. If the number of routes is small in the HQ, you can create a routing policy to match prefix lists. This method applies when a small number of headquarters routes exist and facilitates refined route control.
3. Configure the network command in BGP address family view to redistribute overlay routes. This method applies when a small number of headquarters routes exist and features easy configuration.
Filter redistributed overlay routes by route label
Create a routing policy
1. Log in to Unified Platform as a tenant service administrator (sdwan).
2. Navigate to the Automation > Branch Networks > Physical Networks > Device Settings > Routing Policies page (the page supports importing and adding routing policies), and then click Add to add a routing policy for Hub1-1. Click Add in the Match List to add two match rules, as shown in Figure 112.
¡ Configure
a rule with the match method of deny, click 
in the
Matching Rule column to specify matching label 100,
as shown in Figure 113.
¡ Configure
a rule with the match method of permit, click 
in
the Matching Rule column to select the LAN
interface from the output interface list, as shown in Figure 114. If
the internal routes learned through OSPF by the two gateways at the site have
different costs, you need to apply the same cost for the redistributed routes,
implementing equal-cost routes learned by the branch site. Click 
in
the Application Policy column to specify cost 0, as
shown in Figure 115.
3. Click OK.
Figure 112 Adding a routing policy
Figure 113 Adding a matching rule (matching label 100)
Figure 114 Matching rule (matching LAN interface)
Figure 115 Adding an application policy
Alternatively, you can import routing policies through a template. Click Import, download the template as shown in Figure 116, and import the routing policies.
Figure 116 Routing policy template
Redistribute IPv4 routes
4. Navigate to the Automation
> Branch Networks > Physical
Networks > Device Settings > BGP Routes page, select Hub1-1, and then click 
in
the Actions column for a BGP VPN instance. Click 
in
the VPN address family list to enter the BGP-VPN address family page, as shown
in Figure 117.
Figure 117 BGP-VPN address family
5. Select the IPv4 unicast address family. Click
in the Address Family Detail column. On
the page that opens, specify process ID 10, specify routing policy filter, and
then click 
, as shown in Figure 118.
Figure 118 Configuring route redistribution
|
|
CAUTION: To ensure a successful configuration deployment when redistributing OSPF routes, you must specify a process ID. |
Redistribute IPv6 routes
6. Navigate to the Automation
> Branch Networks > Physical
Networks > Device Settings > BGP Routes page, select Hub1-1, and then click 
in
the Actions column for a BGP VPN instance. Click 
in
the VPN address family list to enter the BGP-VPN address family page, as shown
in Figure 119.
Figure 119 BGP-VPN address family
7. Select the IPv6 unicast address family. Click
in the Address Family Detail column. On
the page that opens, specify process ID 10, specify routing policy filter, and
then click 
, as shown in Figure 120.
Figure 120 Configuring route redistribution
|
|
CAUTION: To ensure a successful configuration deployment when redistributing OSPFv3 routes, you must specify a process ID. |
Filter redistributed overlay routes by prefix list
Create an IPv4 routing policy
1. Log in to Unified Platform as a tenant service administrator (sdwan).
2. Navigate to the Automation > Branch Networks > Physical Networks > Device Settings > Routing Policies page. On the route prefix management page (supports importing and route prefixes), click Add to add a route prefix to match network 20.1.1.0/24, as shown in Figure 121.
Figure 121 Adding a route prefix
Alternatively, you can click Import, download the template as shown in Figure 122, and import the route prefix list.
Figure 122 Route prefix list template
3. Add or import routing policy filter, click Add in the Match List to add a matching
rule, as shown in Figure 123. Click
in the Matching Rule column to add a
matching rule, as shown in Figure 124. If
the internal routes learned through OSPF by the two gateways at the site have
different costs, you need to apply the same cost for the redistributed routes,
implementing equal-cost routes learned by the branch site. Click 
in
the Application Column
to specify cost 0, as shown in Figure 125.
Figure 123 Adding a routing policy template
Figure 124 Adding a matching rule
Figure 125 Adding an application policy
4. Click OK.
Redistribute IPv4 routes
5. Navigate to the Automation
> Branch Networks > Physical
Networks > Device Settings > BGP Routes page, select Hub1-1, and then click 
in
the Actions column for a BGP VPN instance. Click 
in
the VPN address family list to enter the BGP-VPN address family page, as shown
in Figure 126.
Figure 126 BGP-VPN address family
6. Select the IPv4 unicast address family. Click
in the Address Family Detail column. On
the page that opens, specify process ID 10, specify routing policy filter, and
then click 
, as shown in Figure 127.
Figure 127 Configuring route redistribution
|
|
CAUTION: · For route filtering to take effect, make sure the network specified in a prefix list matches the network in the routing table exactly. · To ensure a successful configuration deployment when redistributing OSPF routes, you must specify a process ID. |
Create an IPv6 routing policy
7. Log in to Unified Platform as a tenant service administrator (sdwan).
8. Navigate to the Automation > Branch Networks > Physical Networks > Device Settings > Routing Policies page. On the route prefix management page (supports importing and route prefixes), click Add to add a route prefix to match network 2000:1::1/64, as shown in Figure 128.
Figure 128 Adding a route prefix
9. Add or import routing policy filter, click Add in the Match List to add a matching
rule, as shown in Figure 129. Click
in the Matching Rule column to add a
matching rule, as shown in Figure 130. If
the internal routes learned through OSPFv3 by the two gateways at the site have
different costs, you need to apply the same cost for the redistributed routes,
implementing equal-cost routes learned by the branch site. Click 
in
the Application Column
to specify cost 0, as shown in Figure 131.
Figure 129 Adding a routing policy template
Figure 130 Adding a matching rule
Figure 131 Adding an application policy
10. Click OK.
Redistribute IPv6 routes
11. Navigate to the Automation
> Branch Networks > Physical
Networks > Device Settings > BGP Routes page, select Hub1-1, and then click 
in
the Actions column for a BGP VPN instance. Click 
in
the VPN address family list to enter the BGP-VPN address family page, as shown
in Figure 132.
Figure 132 BGP-VPN address family
12. Select the IPv6 unicast address family. Click
in the Address Family Detail column. On
the page that opens, specify process ID 10, specify routing policy filter, and
then click 
, as shown in Figure 133.
Figure 133 Configuring route redistribution
|
|
CAUTION: For route filtering to take effect, make sure the network specified in a prefix list matches the network in the routing table exactly. To ensure a successful configuration deployment when redistributing OSPFv3 routes, you must specify a process ID. |
Redistribute overlay routes with the network command
Redistribute IPv4 routes
1. Navigate to the Automation
> Branch Networks > Physical
Networks > Device Settings > BGP Routes page, select Hub1-1, and then click 
in
the Actions column for a BGP VPN instance. Click 
in
the VPN address family list to enter the BGP-VPN address family page, as shown
in Figure 134.
Figure 134 BGP-VPN address family
2. Select the IPv4 unicast address family. Click
in the Address Family Detail column. In
the BGP-NETWORK list, click Add to add a
redistributed route, as shown in Figure 135. Then
click 
.
Figure 135 Configuring route redistribution
|
|
CAUTION: For route filtering to take effect, make sure the network specified in a NETWORK list matches the network in the routing table exactly. |
Redistribute IPv6 routes
3. Navigate to the Automation
> Branch Networks > Physical
Networks > Device Settings > BGP Routes page, select Hub1-1, and then click 
in
the Actions column for a BGP VPN instance. Click 
in
the VPN address family list to enter the BGP-VPN address family page, as shown
in Figure 136.
Figure 136 BGP-VPN address family
4. Select the IPv6 unicast address family. Click
in the Address Family Detail column. In
the BGP-NETWORK list, click Add to add a
redistributed route, as shown in Figure 137. Then click 
.
Figure 137 Configuring route redistribution
|
|
CAUTION: For route filtering to take effect, make sure the network specified in a prefix list matches the network in the routing table exactly. |
Redistribute overlay routes into the LAN
The devices at the HQ1 site use OSPF/OSPFv3 to communicate with the internal network. After completing the overlay route configuration, you need to redistribute the overlay routes into OSPF. This section uses Hub1-1 as an example to describe how to redistribute overlay routes into the LAN.
Filter redistributed overlay routes by route label
If you configure redistributed overlay route filtering by label, you need to add the corresponding label when redistributing the overlay routes into the LAN.
Create a routing policy
1. Log in to Unified Platform as a tenant service administrator (sdwan).
Navigate to the Automation > Branch Networks > Physical Networks > Device Settings > Routing Policies page (the page supports importing and adding routing policies), and then click Add to add a routing policy for Hub1-1. Click Add in the Match List to add a match rule, as shown in Figure 138.
Click 
in
the Application Policy column to specify cost 100,
as shown in Figure 139.
2. Click OK.
Figure 138 Adding a routing policy
Figure 139 Adding an application policy
|
|
CAUTION: By default, the tag value of the BGP routes redistributed into OSPF is 1. To prevent route loops, set the tag to a value other than 1. |
Redistribute IPv4 routes
3. Navigate to the Automation
> Branch Networks > Physical
Networks > Device Settings > OSPF Routes page. Obtain the OSPF process created in
"Configure routing settings on the LAN
side", and then click 
for the
redistributed route, as shown in Figure 140.
4. Click Add to add
the redistributed BGP route. Specify the corresponding AS number, and select a
routing policy label, as shown in Figure 141. Then click 
.
Figure 141 Configuring OSPF route redistribution
Key parameters:
¡ Routing Protocol: Enter BGP to redistribute overlay BGP routes into OSPF.
¡ AS Number: Specify the BGP AS number, which is 6000 in this example.
¡ Routing Policy: Select a routing policy label.
Redistribute IPv6 routes
The controller cannot deploy route redistribution configuration. You must configure route redistribution manually as follows:
#
ospfv3 20 vpn-instance VPN1
router-id 20.1.10.2
import-route bgp4+ route-policy tag //Redistribute BGP4+ routes into OSPFv3, add tags for the routes
area 0.0.0.0
#
Configure route synchronization
In the dual-gateway site scenario, for connection to a LAN through VRRP or static routing, you must add an interconnection link for each service VPN and configure OSPF for route synchronization. If you fail to do that, path switchover cannot be performed upon a WAN link failure.
The following uses Spoke1-1 and Spoke1-2 as an example.
Add a LAN interface route synchronization
1. Log in to Unified Platform as a tenant service administrator (sdwan). Navigate to the Automation > Branch Networks > Virtual Networks > VPNs Management > LAN Deployment page, and then click Add to add LAN network details for Spoke1-2.
Figure 142 Adding LAN network details
Key parameters:
¡ VPN Instance Name: Specify the name of the bound VPN instance, which is VPN1 in this example.
¡ LAN Interface IP: Specify an IPv4 or IPv6 address.
¡ Auto Import LAN Routes: Select No. A LAN interface is used only for route synchronization in the dual-gateway scenario.
2. Add LAN network details for Spoke1-1 in the same way.
Add IPv4 route synchronization configuration
1. Log in to Unified Platform as a tenant service administrator (sdwan). Navigate to the Automation > Branch Networks > Physical Networks > Device Settings > OSPF Routes page, and then click Add to add an OSPF process for Spoke1-1.
Figure 143 Adding an OSPF route (1)
Figure 144 Adding an OSPF route (2)
Key parameters:
¡ Process ID: Specify a new process ID. ID 40 is specified in this example.
¡ Router ID: Specify the router ID as an interconnection IP address.
¡ VPN Instance Name: Specify the name of the bound VPN instance, VPN1 in this example.
¡ Protocol Type: Enter OSPF.
¡ Redistribute Default Route: Turn on this option for network access of the associated site.
¡ Redistribution Method: Select Permit-Calculate-Other. When a router generates and advertises a Type-5 LSA for the default route, the router with this parameter specified still calculates default routes received from other routers.
¡ Route Redistribution Rule List: Specify an AS number and bind a routing policy tag to redistribute BGP routes to OSPF.
¡ Interface List: Specify interface GE4/0.1 and configure area 0.0.0.0.
2. Click OK.
3. Add route configuration for Spoke1-2 in the same way.
Add IPv6 route synchronization configuration
1. Log in to Unified Platform as a tenant service administrator (sdwan). Navigate to the Automation > Branch Networks > Physical Networks > Device Settings > OSPF Routes page, and then click Add to add an OSPF process for Spoke1-1.
Figure 145 Adding an OSPFv3 process
Key parameters:
¡ Process ID: Specify a new process ID. ID 20 is specified in this example.
¡ Router ID: Specify the router ID as an interconnection IP address.
¡ VPN Instance Name: Specify the name of the bound VPN instance, VPN1 in this example.
¡ Protocol Type: Enter OSPFv3.
¡ Interface List: Specify interface GE4/0.1 and configure area 0.0.0.0.
2. Click OK.
The controller cannot deploy route redistribution configuration. You must configure route redistribution manually as follows:
#
ospfv3 50 vpn-instance VPN1
router-id 20.2.21.1
vpn-instance-capability simple
import-route bgp4+ 6000 //Redistribute BGP4+ routes into OSPFv3
area 0.0.0.0
#
3. Add route configuration for Spoke1-2 in the same way.
Display configuration deployment status
Display route redistribution status in the VPN
When route redistribution is complete, you can see on Spoke1-1 that the routes of the corresponding service networks are forwarded through the overlay tunnel, and all tunnels form equal-cost routes.
<Spoke1-1> display ip routing-table vpn-instance VPN1 20.1.1.0
Summary count : 2
Destination/Mask Proto Pre Cost NextHop Interface
20.1.1.0/24 BGP 5 0 7.1.1.11 Tun1
BGP 5 0 7.1.1.12 Tun5
BGP 5 0 7.1.1.12 Tun7
Route redistribution succeeded.
Application group traffic engineering and visibility
To visualize traffic engineering and traffic path in topology view for user-defined applications, perform the following tasks:
1. Define application signatures.
2. Define the corresponding TE policies.
Synchronize device resources
Synchronize devices in QoS management
To use the QoS component, if the device list does not match the incorporated device list of the controller, navigate to the Automation > Network Common > Device Manager > Device List, and click Resource Full Sync page.
Figure 146 Full synchronization of resource
Add devices in SSM
To add devices to be managed by SSM, navigate to Automation > Security Service Manager > Device Manager, and then click Add.
Figure 147 Adding devices in SSM
Define application signatures
Configure a 5-tuple-defined ACL template
1. Log in to Unified Platform as the tenant service administrator (sdwan).
2. Navigate to Automation > Network Common Settings > QoS Manager > ACL Templates and click Add.
Figure 148 Adding an ACL template
3. Configure the ACL template.
¡ Template Name: Name of the ACL template to be displayed on the controller.
¡ Identifier Type: Specify the format of the ACL command to be deployed to devices. If you select the name type, the command format is acl advance name xxx, where xxx represents the ACL name. If you select the number type, the command format is acl advance yyy, where yyy represents the ACL number.
¡ ACL Identifier: Specify the ACL name or ACL number.
¡ ACL Type: Select IPv4 ACL or IPv6 ACL.
4. Click Add Rule and configure the ACL rule.
Since service traffic is bound to specific VPNs, specify the VPN name for the rule.
Figure 149 Adding an ACL rule
You can repeat this step to add multiple ACL rules and adjust the rule matching order by editing the ACL rule IDs. You can also import ACL rules in bulk by using an ACL import template, as shown in Figure 150.
Figure 150 Importing ACL rules
|
|
NOTE: The rule ID, action, and protocol type are required. |
Key ACL rule parameters:
· Rule ID: The value range is 0 to 65534.
· Action:
¡ 1—Deny.
¡ 2—Permit.
· Protocol Type:
¡ 6—TCP.
¡ 17—UDP.
¡ 256—IP.
· Source Address/Destination Address: Valid IPv4/IPv6 address.
· Source/destination object group name: A string of 1 to 63 characters.
· Source/destination port mode:
¡ 1—lt (lower than)
¡ 2—eq (equal to)
¡ 3—gt(greater than)
¡ 4—neq (not equal to)
¡ 5—range (inclusive range)
· Port value:
¡ If the port mode is 1, 2, 3, or 4, the port value can only be 1.
¡ If the port mode is 5, the port value can be 1 or 2.
· VPN Instance: A string of 1 to 31 characters.
· DSCP: The value range is 0 to 63.
Configure a user-defined DPI application
If the predefined signature library can no longer satisfy the network deployment requirements, you need to upgrade the DPI signature libraries of the controller and devices. To upgrade the DPI signature library of devices, see AD-WAN 6.5 Branch Solution Security Controller Configuration Guide.
To upgrade the DPI signature library of SSM:
1. Synchronize the signature library:
Navigate to Automation > App Signature Library > Device App Signature Library List. Select a device, and click Sync.
Figure 151 Device signature library synchronization
2. Verify the synchronization result:
Navigate to System > Log management > Operation Logs to view the successfully synchronized signature library.
Figure 152 Device signature library synchronization succeeded
3. Customize the application signatures:
Use DPI to define FTP traffic as an application:
a. Navigate to Automation > Security Service Manager > Objects > Application Groups > Application Signature Groups.
b. Click Add. The page for adding a user-defined application signature group opens.
c. Configure the application signature group name as FTP. In the app signature list, click Select and then select application signatures ftp and ftp-data.
d. Click OK.
Figure 153 Adding a user-defined application signature group
|
|
CAUTION: · Make sure the device signature libraries contain the application signatures deployed by the controller. Otherwise, application matching might fail. · User-defined application signature groups can be centrally deployed by QoSM. When you edit or delete user-defined application signature groups, QoSM does not identify whether the groups are being used. Therefore, group edit and delete operations might result in application traffic matching failure. Use caution when you perform edit or delete operations. · To use DPI in the dual-gateway scenario, you need to configure RBM. |
Configure a user-defined URL application
For HTTP access, you can define the traffic matching a specific URL (such as domain name h3c.sdwan.xyz) as an application.
1. Add a check item:
Navigate to Automation > Security Service Manager > Objects > Application Groups > Check Items. Click Add to add a check item named h3c. Configure the Header Field Type as Host and Match Value as h3c.
Figure 154 Adding a check item
2. Add a rule:
Navigate to Automation > Security Service Manager > Objects > Application Groups > Rules. Click Add to add a rule named xyz. Configure the Header Field Type as Host and Match Value as sdwan.xyz. In the Check Item List, click Select and then select the check item h3c.
Figure 155 Adding a rule
|
|
CAUTION: The match value in a rule and that in a check item of the rule are in AND relationship. The match values in multiple check items are in OR relationship |
3. Add an application signature:
Navigate to Automation > Security Service Manager > Objects > Application Groups > Application Signatures. Click Add to add a user-defined application signature named url-test. Configure the Recognition Method as NBAR and Protocol Type as HTTP. In the Rule List, click Select and then select rule xyz.
Figure 156 Adding a user-defined application signature
4. Add an application signature group:
Navigate to Automation > Security Service Manager > Objects > Application Groups > Application Signature Groups. Click Add. Configure the application signature group name as url. In the app signature list, click Select and then select application signature url-test.
5. Click OK.
Figure 157 Adding a user-defined app signature group
|
|
CAUTION: User-defined application signature groups can be centrally deployed by QoSM. When you edit or delete user-defined application signature groups, QoSM does not identify whether the groups are being used. Therefore, group edit and delete operations might result in application traffic matching failure. Use caution when you perform edit or delete operations. |
Configure an application with a customized domain name
1. Add an object group:
Navigate to Automation > Security Service Manager > Objects > Object Groups. Click Add to add an object group.
Figure 158 Adding an object group
Click Add to add an object. Select Host Name for Object Type, enter the associated domain name for Host Name, and select the associated VPN instance.
Click OK.
2. Bind the object group to devices:
Click 
in
the Actions column for the application group, and select the target devices to
be bound to the object group.
After binding, the Device Info column displays the Bound Devices link. You can click the link to view the bound interfaces.
3. Add an ACL associated with the object group:
Navigate to Automation > Network Common Settings > QoS Manager > ACL Templates and click Add. For more information, see "Configure a 5-tuple-defined ACL template." Specify the template name as app2, and add a match rule. Specify destination object group baidu and the corresponding VPN instance for the match rule.
Figure 162 Adding a match rule
|
|
CAUTION: To deploy the object group-associated ACL to a device, make sure the object group has already been deployed on the device. |
As a best practice to define an application through domain name, specify the endpoint DNS server as the SDWAN route, and configure the DNS server for the associated VPN instance. In the current software version, you need to manually configure the DNS server with the following command:
[Spoke1-1]dns server 8.8.8.8 vpn-instance VPN1
Deploy a QoS policy
Configure a traffic class template
1. Log in to Unified Platform as the tenant service administrator (sdwan).
2. Navigate to Automation > Network Common Settings > QoS Manager > CBQoS Templates > Traffic Class Templates and click Add.
Figure 163 Adding a traffic class
3. Configure the traffic class basic info:
¡ Template Name: Name of the traffic class.
¡ Rule Logic: Match operator of the traffic class. Options include and and or. If the operator is and, the traffic class matches the packets that match all its match criteria. If the operator is or, the traffic class matches the packets that match any of its match criteria.
4. In the Match Rule section, click Add to configure a match rule. You can select different match types to configure different traffic signatures, as follows:
¡ To match the 5-tuple-defined application traffic, select ACL from the Match Type list, and then select template app1, as shown in Figure 164.
¡ To match DPI/URL applications, select Application Group from the Match Type list, select application group FTP or url-test, as shown in Figure 165.
Figure 165 Application group match type
5. Click OK to save the traffic class.
Configure a traffic behavior template
1. Log in to Unified Platform as the tenant service administrator (sdwan).
2. Navigate to Automation > Network Common Settings > QoS Manager > CBQoS Templates > Traffic Behavior Templates and click Add.
Figure 166 Adding a traffic behavior template
3. Click OK.
|
|
CAUTION: For service traffic entering the SDWAN network, set the same flow ID for the same service flow (identified by the VPN and 5-tuple) as a best practice to facilitate O&M. |
Configure a QoS policy template
1. Log in to Unified Platform as the tenant service administrator (sdwan).
2. Navigate to Automation > Network Common Settings > QoS Manager > CBQoS Templates > QoS Policy Templates and click Add.
3. Configure the QoS policy template.
¡ Template Name: Name of the QoS policy.
¡ Configure Class-Behavior Associations: Select the traffic class and traffic behavior, and click Add to add the traffic class and behavior association.
Figure 167 Adding a QoS policy template
You can add multiple class-behavior associations. To adjust the order of the associations, click the up
arrow icon 
or down arrow icon 
.
4. Click OK.
Apply a QoS policy template to interfaces
1. Log in to Unified Platform as the tenant service administrator (sdwan).
2. Navigate to Automation > Network Common Settings > QoS Manager > CBQoS Templates > QoS Policy Templates.
3. Click the 
icon
for the target QoS policy template.
Figure 168 Applying a QoS policy template to interfaces
4. Click Select Interfaces. Select a device, select the LAN interfaces, and then click Select Inbound Interfaces. Then, click OK to save the selected interfaces.
Make sure to apply the policy template in the inbound direction to all device LAN interfaces.
|
|
NOTE: · If the device uses a Layer 3 LAN interface, apply the policy template to the interface directly. · If the device uses a Layer 2 LAN interface, apply the policy template to the corresponding VLAN interface of the Layer 2 interface. |
Figure 169 Selecting interfaces
Figure 170 Selected interfaces
5. Click OK to apply the policy template to the selected interfaces.
The system starts to deploy QoS policy, traffic behavior, and ACL template configuration to devices.
Figure 171 Deployment success
Configure branch network application groups
Set the link quality weights for link selection
If the SLA thresholds are exceeded for a link, the system considers that the link cannot meet the service quality requirements and evaluates the quality of each link according to the comprehensive quality indexes (CQI algorithm). You can perform this task to set the weights of latency, jitter and packet loss rate indexes.
To set the link quality weights for scheduling, log in to Unified Platform as the tenant service administrator (sdwan). Navigate to Automation > Branch Networks > Application TE > TE Policies > Link Quality Weights, and set the weights.
The weight value must be in the range of 0 to 10. If the weight of an index is 0, the system does not take this index into consideration when selecting a link.
Figure 172 Link quality weights
|
|
IMPORTANT: · You cannot set the jitter weight, latency weight, and packet loss rate weight to 0 at the same time. · Before applying the policy to application groups, you must configure the CQIs. You cannot edit the CQIs of a policy after the policy is deployed. To edit a deployed policy, you must first delete the application group configuration. |
Configure RIR
Log in to Unified Platform as the tenant service administrator (sdwan). Navigate to Automation > Branch Networks > Application TE > TE Policies > RIR Settings, and view or edit the parameters.
· Bandwidth Scheduling Policy: Selects routes that can meet the actual bandwidth requirements for service traffic. This feature is enabled by default.
· Priority-Based Link Selection: Selects routes based on service priority. This feature is disabled by default.
· Link Selection Interval: Scheduling interval for service priority-based route selection. By default, the interval is 30 seconds.
· Lower Bandwidth Usage Threshold: Stops traffic engineering when the percentage of traffic on a link drops below the threshold.
· Upper Bandwidth Usage Threshold: Triggers traffic engineering when the percentage of traffic on a link exceeds the threshold.
· Per-Flow Load Balancing Mode:
¡ Scheduled: Global link load balancing mode that applies to all service traffic participating RIR link selection. In this mode, RIR not only distributes various sessions of the same service flow to different links, but also performs dynamic adjustments at the specified intervals. Within a scheduling interval, RIR transmits traffic of one session through only one link. After link selection, RIR also dynamically adjusts traffic paths based on the threshold configuration at the specified intervals.
¡ Weighted: Global link load balancing mode that applies to all service traffic participating RIR link selection. In this mode, RIR distributes various sessions of the same service flow to different links by weight. RIR transmits traffic of one session through only one link. After link selection, RIR does not dynamically adjust traffic paths based on the threshold configuration at the specified intervals.
· Scheduling Interval: Adjustment interval for the per-flow load balancing mode. In scheduled mode, the device dynamically adjusts service traffic on the links at the specified intervals. When the adjustment interval is reached, the device will detect the link bandwidth usage for all service traffic.
· Upper Threshold for Remaining Bandwidth Ratio Difference: Periodic adjustment upper threshold, which is the largest difference allowed between the largest remaining bandwidth ratio and smallest remaining bandwidth ratio of all available physical output interfaces or tunnel interfaces used to forward traffic of a specific service. If this threshold is crossed, RIR performs link reselection for the service traffic.
· Lower Threshold for Remaining Bandwidth Ratio Difference: Periodic adjustment lower threshold for the difference between the largest remaining bandwidth ratio and the smallest remaining bandwidth ratio. The link adjustment might be last for several adjustment intervals. RIR stops link adjustment if one of the following requirements is met:
¡ The difference between the largest remaining bandwidth ratio and the smallest remaining bandwidth ratio of the physical output interfaces or tunnel interfaces becomes smaller than the periodic adjustment lower threshold.
¡ RIR has performed 19 adjustments after link reselection is triggered.
Figure 173 RIR settings
Add TE scopes
Specify source devices according to the service scope. The controller deploys settings for an application group based on the TE scope bound to the application group.
1. Log in to Unified Platform as the tenant service administrator (sdwan). Navigate to the Automation > Branch Networks > Application TE > TE Scopes page.
2. Click Add to open the Add TE Scope page, and specify a TE scope name.
3. Click Add to add sites for TE deployment.
Key parameters:
¡ TE Scope Name: Name of the TE scope. In this example, the name is All.
¡ Sites: Select all sites.
Figure 174 Adding a TE scope
|
|
CAUTION: Only sites that contain the CPE role can join the TE scope, which includes the CPE or RR&CPE role. |
Add SLA profiles
When the device performs session-based link selection, each session corresponds to traffic with an unambiguous quintuple. To select links for an application, define link quality requirements for the application. Application-based link selection is based on the link quality, the link bandwidth, and the link selection policies applied to the links.
· Basic link selection rules:
a. Selects the link with the highest priority from the links that meet the quality and bandwidth requirements.
b. Selects the link that meets the quality and bandwidth requirements and has the next highest priority if no link with the highest priority meets the quality or bandwidth requirements.
c. Randomly selects a link that meets the bandwidth requirements if no link meets the quality requirements.
d. Does not detect the link quality if no link meets the bandwidth requirements. Multiple links use UCMP. The links load share traffic based on their remaining bandwidths. A link does not meet the bandwidth requirements if its bandwidth usage exceeds 80%.
e. Does not use RIR to select links and performs routing table lookup to forward traffic if the bandwidth usage of all RIR candidate links reaches 100%.
· To configure SLA profiles:
The system has defined eight SLA levels that have priorities in the range of 0 to 7. The larger the priority value is, the higher the priority is. Each SLA level is defined with a set of quality parameters including latency, packet loss, and jitter. You can manually change the quality parameter values for an SLA level.
f. Use tenant service administrator sdwan to log in to Unified Platform. Navigate to the Automation > Branch Networks > Application TE > TE Policies > SLA Profiles page.
Figure 175 SLA quality parameters
|
|
IMPORTANT: The default SLA quality requirement is too high and needs to be adjusted according to the link quality in the network. As a best practice, do not perform adjustment by jitter in the live network. |
b. Click Add. An SLA profile contains the following content:
- SLA Level: Multiple application policies can use the same SLA level. If you do not specify an SLA profile, the system does not take link quality into consideration when selecting links.
- Expected Bandwidth: Per-session expected bandwidth for initial link selection. As a best practice, set the expected bandwidth to 10 Kbps.
- WAN Selection Policy: Define optimal links for applications. You can add multiple optimal links and assign priority values to the links. The lower the priority value is, the higher the priority is.
In this example, SLA profile SLA1 is added, as shown in Figure 176.
In this example, the following WAN selection policies are added: MSTP1 leased link, MSTP2 leased link, Internet CT egress with intra-operator tunnel, Internet CU egress with intra-operation tunnel, Internet CT egress with inter-operator tunnel, Internet CU egress with inter-operator tunnel, and MPLS leased link. The priorities of these policies are in descending order.
Configure time ranges
Use tenant service administrator sdwan to log in to Unified Platform. Navigate to the Automation > Branch Networks > Policies > TE Policies > Time Ranges page. Click Add. In the dialog box that opens, add time range time1 as shown in Figure 177.
Figure 177 Adding a time range
Add application groups
1. Use tenant service administrator sdwan to log in to Unified Platform. Navigate to the Automation > Branch Networks > Application TE > TE Groups page.
2. Click Add. Configure the application group.
Figure 178 Adding application groups
Key configuration description:
¡ TE Scope: The application group is deployed to all devices within the scope.
¡ TE ID: Flow ID of the application group. A flow ID can be used by multiple application groups. A device cannot join multiple application groups with the same flow ID. In this example, specify flow ID 1 defined in "Configure a traffic behavior template."
¡ Load Balancing Mode: The per-flow and per-packet load balancing modes are supported. As a best practice, use per-flow load balancing. If multiple links have the same priority, traffic can be distributed among the links for load balancing.
¡ Drop Packets on Tunnel Failure: Through RIR, the device can select optimal links to forward packets of services. If no optimal links are found for a service, the device forwards the service's packets according to the original routing table information. If all links specified for a service fail and you do not want the service to occupy the links specified for other services, you can turn on this feature to drop the packets of the service. For example, turn on this feature if you do not want low-priority video traffic to occupy the links for higher-priority services.
¡ Exclusive Tunnel Use: If you turn on this option, the selected link tunnels are exclusively used by the traffic of this TE group, and a single selected link can only be used by one TE group. To enable a specific application to exclusively use a particular link for forwarding, you can use this function. When this function is enabled, if no application traffic exists on the associated tunnel, other application traffic can use this tunnel for forwarding. If application traffic that needs to exclusively use this tunnel exists, other application traffic will be automatically switched out.
¡ Link Quality Weights: The system supports specifying link quality weights specific to an application group. For more information, see "Set the link quality weights for link selection."
¡ Application Group Policy: Options for the effective time of an application group policy include permanent and time range-based. If time range-based is selected, you can select different time ranges for different application group policies.
Deploy application groups based on the TE requirements. The deployment succeeds when the deployment progress for each application group is 100%, as shown in Figure 179.
Verify the configuration
Simulate traffic that matches the
application group app1. Navigate to the Monitor > Topology > Branch Topology page. Click the Application
Groups icon 
to display all application
groups. Then, select application group app1 and
click the corresponding colored link to view the traffic forwarding path, as
shown in Figure 180.
Application traffic is forwarded through the MSTP1 leased line as expected.
Figure 180 Forwarding paths for application group app1
|
|
CAUTION: To ensure that the topology displays forwarding paths, make sure the network has traffic that matches the application groups. |
Deploy QoS services
The controller supports the following QoS service deployments:
· Rate limit for WAN interfaces: Rate limits traffic based on WAN interface.
· Application assurance for WAN interfaces: When a WAN interface is congested, the interface allocates different bandwidths to different applications according to the application priorities.
· Overlay link (TTE connection) based rate limit and application assurance: Required when the headquarters use a one-to-multiple tunnel.
· Priority queue-based assurance for WAN interface: When a WAN interface is congested, you can configure priority queues to guarantee resources for high-priority application traffic.
· Application blocking for LAN interface: Identify the traffic and deny forwarding.
Before using the QoS component, synchronize device resources. For more information, see "Synchronize device resources."
Configure rate limit for WAN interfaces
Configure rate limit for physical interfaces
If the bandwidth provided by the service provider is smaller than the interface bandwidth, you must configure rate limit for WAN interfaces.
|
|
IMPORTANT: · If rate limit is not configured for a WAN interface that has smaller bandwidth than the physical interface, traffic sent out of the interface may exceed the service provider limit. In this case, the service provider cannot discard packets based on service priorities and protocol packets or critical service packets might get lost. As a result, for links with certain bandwidth values, you must configure rate limit for the WAN interfaces. · For critical service traffic to be preferentially forwarded when a WAN interface is congested, you must also configure application assurance. · When you configure WAN details for the controller, specify bandwidth parameters for WAN interfaces. Make sure the WAN interface bandwidth limit is consistent with the interface bandwidth. If the bandwidth of a WAN link changes, change the link interface bandwidth and WAN interface rate limit settings accordingly. For more information, see "Link visualization and management." |
To configure rate limit for physical interfaces:
1. Log in to Unified Platform as the tenant service administrator (sdwan). Navigate to the Automation > Network Common Settings > QoS Manager > LR Templates page.
Figure 181 LR template
2. Click Add to configure the LR template. For example, you can limit the rate of the WAN interface of Spoke1-1 connecting to the Layer 2 leased line to 10000 Kbps.
Figure 182 Adding an LR template
3. Click OK to save the template.
Figure 183 LR template created successfully
4. Click the 
icon in the Interface Actions column to apply the LR template to
device interfaces. Click Select Interfaces. Select the device name, select the outbound direction, and then
select outbound interfaces to add the interfaces to the selected interface list. Click OK
to save the selected interface list.
Figure 184 Selected interfaces
5. Click OK to deploy the template to the device interface, as shown in Figure 185.
Figure 185 Selected interface
Figure 186 shows that the template has been successfully deployed to the interface.
Verify the configuration
1. Simulate traffic that exceeds the upper limit and verify that the rate limit settings can take effect.
2. Rate limit for physical interfaces: Check WAN interface configuration on the device and verify that the rate limit settings have been deployed to a physical interface.
<Spoke1-1>display cu int GigabitEthernet 0/2
#
interface GigabitEthernet0/2
port link-mode route
bandwidth 10000
ip address 11.1.5.2 255.255.255.0
ospf 1 area 0.0.0.10
qos lr outbound cir 10000 cbs 625000 ebs 0
#
Configure application assurance for WAN interfaces
|
|
IMPORTANT: You cannot configure both application assurance and priority queue-based assurance for the same WAN interface. |
When a WAN interface is congested, the interface allocates bandwidths to applications based on the application priorities.
In this example, application groups app1 and app2 are configured with the same SLA application policy. The remark DSCP of the traffic behavior for app1 is set to 50, and the remark DSCP of the traffic behavior for app2 is set to 40.
Configure application assurance templates
1. Log in to Unified Platform as the tenant service administrator (sdwan).
2. Navigate to Automation > Network Common Settings > QoS Manager > CBQoS Templates > Traffic Class Templates.
3. Configure traffic class templates, as shown in Figure 187 and Figure 188. In the Match Rule area, click Add and then set the DSCP value. In this example, the DSCP value for app1 is set to 50, and the DSCP value for app2 is set to 40.
Figure 187 Creating
traffic class template-1 
Figure 188 Creating
traffic class template-2 
4. Create traffic behavior templates.
Navigate to Automation > Network Common Settings > QoS Manager > CBQoS Templates > Traffic Behavior Templates. Click Add and configure queues. For example, configure the bandwidth of app1-af queue with a bandwidth value of 1600 Kbps and app2-ef queue with a bandwidth value of 1400 Kbps.
Figure 189 Creating traffic behavior template-1
Figure 190 Creating traffic behavior template-2
5. Create a QoS policy template.
Navigate to Automation > Network Common Settings > QoS Manager > CBQoS Templates > QoS Policy Templates. Click Add. Select a group of traffic class and traffic behavior, and then click Add to bind the traffic class and traffic behavior to the class-behavior association list, as shown in Figure 191.
Figure 191 Creating a QoS policy template
Configure application assurance templates for WAN interfaces
Configure rate limit for physical interfaces. This section takes as an example of limiting the rate to 3000 Kbps.
To configure application assurance templates for WAN interfaces:
1. Click the 
icon in the Actions column for a QoS policy and click Select Interfaces. For example, select outbound interface
GigabitEthernet3/0 of Spoke1-1, as shown in Figure 192.
Figure 192 Selecting deployment interfaces
2. After interfaces are selected, deploy the QoS policy to the device, as shown in Figure 193.
Figure 193 Deployment was successful
Configure overlay link (TTE connection) based rate limit and application assurance
In the EVPN solution, the egress of a headquarters device corresponds to multiple branches and the egress bandwidth of headquarters devices is generally greater than that of branch devices. To ensure that the inbound traffic of each branch does not exceed the upper limit, headquarters devices support configuring rate limit and application guarantee for different branches at the tunnel interface.
To configure an application assurance template on the tunnel interface, you must first configure a parent policy for rate limit based on branch egress bandwidth, and then use the sub-policy of the application assurance template.
Configure application assurance templates
1. Log in to Unified Platform as the tenant service administrator (sdwan).
2. Navigate to Automation > Network Common Settings > QoS Manager > CBQoS Templates > Traffic Class Templates.
3. Click Add. In the dialog box that opens, select SDWAN TTE for Match Type. For example, configure traffic class for Spoke1-2 on the Layer 3 leased line TTE, as shown in Figure 194.
Figure 194 Creating a traffic class template
4. Create the traffic behavior of TTE rate limit.
Navigate to Automation > Network Common Settings > QoS Manager > CBQoS Templates > Traffic Behavior Templates. Click Add. Configure the committed information rate (CIR) in the GTS area (for example, set it to 10000 Kbps). Configure the sub-policy in the Policy area and specify the policy name (for example, spokecbq), as shown in Figure 195.
Figure 195 Creating a traffic behavior template
5. Navigate to Automation > Network Common Settings > QoS Manager > CBQoS Templates > QoS policy Templates. Create a QoS policy template as shown in Figure 196.
Figure 196 Creating
a QoS policy template 
Apply application assurance templates to the tunnel interface
1. Click the 
icon for a QoS
policy in the Actions column to deploy the policy
to outbound tunnel interface of the Layer 3 leased line of headquarters Hub1-2. Take Tunnel3 as an example,
as shown in Figure 197.
If the deployment succeeds, the page as shown in Figure 198 is
displayed.
Figure 197 Selecting deployment interfaces
Figure 198 Deployment was successful
|
|
CAUTION: · Typically, the bandwidth of a WAN interface is lower than the bandwidth of a physical interface. You must limit rate for the WAN interface and configure application assurance for the interface. · Configure absolute bandwidth values to make sure the total bandwidth of all application assurance queues does not exceed the bandwidth of the link output interface. As a best practice to prevent traffic in assurance queues from occupying all interface bandwidth, make sure the bandwidth sum of all application assurance queues does exceed 80% of the actual interface bandwidth. · By default, the maximum bandwidth reserved on an interface is 80% of the total bandwidth. When you specify bandwidth ratios for application assurance queues, the bandwidth used for application assurance is calculated by using the following formula for each queue: Effective bandwidth used for application assurance = link total bandwidth × 80% × application bandwidth ratio. You can change the default reserved bandwidth on an interface by using the qos reserved-bandwidth pct percent command. As a best practice, do not change the default reserved bandwidth. |
Configure priority queue-based assurance for WAN interfaces
Perform this task to configure priority queue-based assurance for WAN interfaces to ensure the forwarding performance of high-priority traffic. You can create eight priority queues.
|
|
IMPORTANT: You cannot configure both application assurance and priority queue-based assurance for the same WAN interface. |
Configure application assurance templates
1. Log in to Unified Platform as the tenant service administrator (sdwan).
2. Navigate to Automation > Network Common Settings > QoS Manager > ACL Templates. Create two ACLs (identified by numbers) to match DSCP 50 and DSCP 40, respectively.
Figure 199 Configuring ACLs (1)
Figure 200 Configuring ACLs (2)
3. Navigate to Automation > Network Common Settings > QoS Manager > PQ Templates. Click Add and configure a queue. Click Add Rule and configure queue rules.
Queue rule parameters:
¡ Rule Type: Select the protocol type.
¡ Queue Priority: Enter an integer in the range of 0 to 7. Larger the value, higher the priority.
¡ IP Version: Select IPv4.
¡ Protocol Type: Select ACL.
¡ ACL: Specify the created ACL.
Create two rules, one for each ACL.
Figure 201 Adding a queue rule
4. Click OK.
Figure 202 Creating a priority queue
Apply the priority queue to WAN interfaces
1. Click the 
icon for priority queue to access the deployment details page.
Figure 203 Deployment details
2. Click Select Interfaces. Select the target interfaces, and then click OK.
Figure 204 Selecting interfaces
3. Click OK. The system starts to deploy the queue configuration to the selected interfaces.
Figure 205 Deployment result
Application blocking
Configure the traffic behavior deny for the application traffic that matches the traffic class, so that the traffic forwarding is denied.
To configure application blocking:
1. Create a traffic class. For more information, see "Define application signatures" and "Configure a traffic class template."
2. Navigate to Automation > Network Common Settings > QoS Manager > CBQoS > Traffic Behavior Templates. Click Add and create a traffic behavior. Select deny for Traffic Filtering, as shown in Figure 206.
Figure 206 Creating a traffic behavior
3. Create a QoS policy, associate the traffic class with the traffic behavior, and apply the association to the inbound LAN interface. For more information, see "Configure a QoS policy template" and "Apply a QoS policy template to interfaces.
Basic and extended O&M features
The O&M and visibility features are relatively independent of each other. Choose the topics for the features as needed. The prerequisites for the features are described in their respective feature overview.
Homepage
1. Use a tenant service administrator account (sdwan) to log in to Unified Platform. Figure 207 shows the homepage information for the tenant, which provides 10 widgets by default. You can edit the map settings and configure device locations on the tenant homepage.
2. If you use the default administrator account to log in, you can also edit the widgets to be displayed on the homepage.
Description on some of the widgets:
¡ Site Health—Averages all the link quality evaluation values in the outbound direction of the site to calculate the site health. For more information about link quality evolution, see "Configure O&M settings."
¡ Inter-Site Links with Lowest Quality-Top5—Displays the five links with the lowest link qualities based on the link quality evaluation values. For more information about link quality evolution, see "Configure O&M settings."
You can click each widget to drill down to the corresponding configuration page. For example, clicking the Link Bandwidth Usage Trends widget in the left lower corner of the page will open the link running status page, as shown in Figure 208.
Figure 208 Links running status
Edit homepage map settings and configure site locations
Edit homepage map settings
Edit map settings
1. Use a tenant service administrator account (sdwan) to log in to Unified Platform.
2. Navigate to the Automation > Branch Networks > Parameter Settings > O&M Settings > Map Settings page, as shown in Figure 209. On this page, you can configure the regions and links to be displayed on the map on the homepage.
Parameters:
· Map Type: Supported map types are static map, Baidu map, and Google map.
· API URL: URL of the API for the selected map type. This field is automatically populated by the controller. Do not edit the URL as a best practice.
· API Key: API key for the selected map type. You must request this key from the official website for the map. For more information, see "Request the Baidu map key" and "Request the Google map key."
· Country: Supported values are Global, Asia, China, Kazakhstan, Malaysia, Japan, Thailand, Indonesia, Philippines, Pakistan, and Russia.
· Province: After you select country China, you can select the province, city, and district/county.
· Display All Sites: Enable this function to display all sites on the current map. After this function is disabled, the map displays only the current level and the next lower level of sites. This function is supported only on the static map.
· Link Type: Select whether to display underlay or overlay links by default.
|
|
CAUTION: · You can select a province, city, and district or county only when the country is China. · If Baidu or Google map is used, you must set the correct key and have Internet access. · After you switch the map type, you need to reconfigure the site physical location settings. |
Request the Baidu map key
1. Click the link for requesting the key: http://lbsyun.baidu.com/apiconsole/key?application=key.
2. Register an account on the website and log in.
3. Select individual developer or enterprise developer as needed. This example chooses to be an enterprise developer.
4. Complete the developer information as required.
5. Wait for the registration result. After the registration succeeds, click the link for requesting the key again to enter the Baidu map console.
6. Go to My Applications and create an application.
7. Select the browser as the application type.
8. Enable the corresponding service and configure IP address allowlist.
9. Submit the configuration to obtain the key.
Request the Google map key
1. Click the link for requesting the key to open the Google map official website: https://developers.google.com/maps/documentation/javascript/get-api-key.
2. Register an account on the official website and log in.
3. Create a Google MAPs object:
4. In the left navigation pane, select Set up in Cloud Console. On the Create a project tab, click Create new project.
5. Enter the project information, and then click CREATE.
6. Obtain the API key for Google Maps.
7. In the left navigation pane, select Set up in Cloud Console. On the Enabling APIs tab, click Enable the Maps JavaScript API.
8. Select the new project, and then click ENABLE to enable the Maps JavaScript API.
9. On the Credentials tab, click CREATE CREDENTIALS. Click API key to obtain the API key.
10. (Optional.) Remove the watermarks on Google Maps.
11. In the left navigation pane, select Set up in Cloud Console. On the Creating budgets and setting alerts tab, click Go to the Billing page.
12. Click ADD BILLING ACCOUNT and enter personal information.
13. Click START MY FREE TRIAL. The watermarks will be removed.
Configure site locations
1. When you import sites and devices, you can
import the site location information. For more information, see "Sites and devices." You can also edit device location information after devices
are added or imported. Navigate to the Automation
> Branch Networks > Physical
Networks > Sites page. On this page, you
can view the site list. To edit
the location of a device, select the device and then click the 
icon in the Actions column, as shown in
Figure 210.
Figure 210 Relocating a device
2. To display underlay links, you must also
configure location information for virtual cloud nodes. Navigate to the Automation > Branch Networks > Physical Networks > Site Settings > WAN Links page. On this page, you can edit location
information for an L3VPN or Internet network. Click the 
icon
to edit the location information, as shown in Figure 211.
Figure 211 Relocating a device
|
|
NOTE: · If you configure the location settings of a site in Chinese environment, the system will still display the location information of that site in Chinese after the system language is changed to English. · If you configure the location settings of a site in English environment, the system will still display the location information of that site in English after the system language is changed to Chinese. |
Edit the homepage
1. Use the tenant
service administrator account (sdwan)
to log in to Unified Platform. Click 
and select Configure Homepage, as shown in Figure 212.
Figure 212 Configuring the homepage 
You can select a homepage from the homepage list. The default homepage is also selectable. After you relog in to the system, the selected homepage will be displayed.
2. To open the dashboard editing page, click Customize Dashboard, as shown in Figure 213.
Figure 213 Editing tenant dashboard
3. Customize the
dashboard as needed, and then click the Save icon 
.
Basic visibility features
After services are deployed, the controller provides the following basic visibility features:
· Topology visualization and management—Allows you to query the controller topology, query devices, links, and application paths on the topology, and add or delete devices on the topology.
· Device visualization and editing—Provides a device list where you can query the device status, including the device module status and interface status.
· Link visualization and management—Provides an underlay link list and an overlay link list, where you can query the basic and historical information of the links and the real-time link operation status.
· Site visualization—Provides site-based topology and related information.
Topology visualization and management
Use a tenant service administrator account (sdwan) to log in to Unified Platform. Navigate to the Monitor > Topology > Branch Topology page. On this page, you can view topology information, move devices, or edit the topology, as shown in Figure 214.
Figure 214 Topology management
The topology page provides the following primary operations (common operations such as zoom in and out are not described):
1. Site Group 
: Add sites to a
group. For example, add sites Branch1 and Branch2 to a
group named Branch, as shown in Figure 215 and Figure 216.
Figure 216 Site group topology
2. Application Group 
: Query the forwarding paths of application groups. For more
information, see "Display route redistribution status in the
VPN."
3. Link Traffic Summary 
: Display Top N
links by history traffic and real-time traffic. You can select the link type Underlay or Overlay. For
history traffic, you can also choose the time range to be displayed, as shown
in Figure 217.
Figure 217 Top N links by traffic
4. Locate Node 
: Search for a specific node. The found node is displayed in a red
box at the center of the topology, as shown in Figure 218.
5. Service Network 
:
Select a service network, and the topology displays only the devices and links
in the network, as shown in Figure 219.
Figure 219 Internet service network
6. Refresh 
: Click the
refresh icon to set the refresh interval, as shown in . The minimum refresh
interval is 1 minute.
Figure 220 Setting refresh interval
7. Overlay and Underlay
Switching 
: Choose to display
the Overlay or Underlay topology.
8. Click a site on the topology page. The
device information is displayed, as shown in Figure 221. If
the device has alarms, you can click the 
icon in the Actions column to view the alarm details.
Figure 221 Viewing device information
9. Click a link on the topology page. The link
information is displayed, as shown in Figure 222. To
view the history link information, click the icon in the Actions
column. If the link has alarms, click the 
icon in the Actions column, and then you can also view the alarm
details.
Figure 222 Viewing link information
10. Right-click the blank space on the topology page to add sites.
11. Right-click the site to view site details, add a site or delete a site.
Device visualization and management
1. Use a tenant service administrator account (sdwan) to log in to Unified Platform. Navigate to the Automation > Branch Networks > Physical Networks > Devices page. On this page, you can view the device list, as shown in Figure 223. On the device list, you can perform the following tasks:
¡ Edit device locations. For configuration procedures, see "Edit homepage map settings and configure site locations."
¡ Upgrade device versions. For configuration procedures, see "Device software upgrade.
¡ Back up device configuration and replace devices. For configuration procedures, see "Backup restoration and replacement."
2. Click the Interfaces tab. Select a device to display the interface list for the device, as shown in Figure 224. You can view interface status and edit the description and TCP MSS value of an interface.
Figure 224 Interface management
3. Click the Modules tab. Select a device and then you can view the module status of the device. If a module is abnormal, you can click the icon in the Actions column to verify the module or submodule status, as shown in Figure 225.
|
|
CAUTION: · If a module is removed from a device, the device generates an alarm. To clear the alarm, you must confirm the removal of the module on this page. · If a module is damaged or removed, the controller does not save the configuration automatically. Please process the module anomaly as soon as possible to avoid configuration loss. · If a module will not be used any longer, you can click Absent Confirmed. Then, the module-related service configuration data, submodule and interface information (such as LAN/WAN network details) at the controller side will be cleared and cannot be restored. Use the clearing operation with caution. |
Link visualization and management
1. Use a tenant service administrator account (sdwan) to log in to Unified Platform. Navigate to the Automation > Branch Networks > Physical
Networks > Physical Links > Links
page or the Automation > Branch Networks > Virtual Networks > Virtual Links > Links page. On this page, you can
view the link list, as shown in Figure 226. You
can choose to display underlay or overlay links. You can display status
information for underlay and overlay links. In the Actions
column, you can click the Edit icon 
to
edit the available bandwidth for an underlay link.
2. Click the Links Run
Status tab. The real-time running status of links is displayed, as shown
in Figure 227.
Click the 
icon to view history information for a link. On the overlay link
list, you can also view
application traffic information, as shown in Figure 228.
Figure 227 Links running status
Figure 228 Link history information
|
|
CAUTION: The overlay link status displayed on the
controller might be inconsistent with that on the device. You can click the |
Site visualization
1. Use a tenant service administrator account (sdwan) to log in to Unified Platform. Navigate to the Automation > Branch Networks > Physical Networks > Sites page. On this page, you can view the site list, as shown in Figure 229.
2. Click the 
icon in the Actions column for a site to view details of the site, as
shown in Figure 230. On
the site details page, you can view the site's basic information, the
performance information for the
devices, and the information for tunnels, links, applications, and alarms in the site. The topology
in the middle of the page displays all the interconnected links of the site.
Alarm settings
Alarm settings
You can configure the alarms generated by the controller, including the link alarm configuration, alarm suppression, and alarm threshold settings.
Use a tenant service administrator account (sdwan) to log in to Unified Platform. Navigate to the Automation > Branch Networks > Parameter Settings > O & M Settings > Alarm Settings page.
· Link alarm settings: Turn on or turn off the alarms for underlay and overlay links, as shown in Figure 231.
Figure 231 Link alarm settings
· Alarm suppression: Configure alarm suppression settings. After alarm suppression is enabled, the system can suppress alarms to reduce the number of alarms to be sent, as shown in Figure 232.
Parameters:
¡ Suppress Link Alarms Generated upon Device Offline: With the suppression interval configured, the system does not immediately send link down alarms generated upon device offline but waits for the alarm suppression interval.
¡ Device Offline Alarm Delay: The controller does not send a device offline alarm if the device restores its state within a delay after a device or link offline event. If the device fails to restore its online state within the delay, the controller sends the device offline alarm.
¡ Suppress Overlay Quality Alarms Generated upon Underlay Offline: When an underlay link goes down, the controller does not send any alarm for the related overlay link.
· Alarm threshold triggers: Configure the alarm thresholds, including the alarm triggers, as shown in Figure 233.
Figure 233 Alarm threshold triggers
Manage alarms
After alarm settings are configured, you can view alarms generated in case of network anomalies.
Active alarms
Use a tenant service administrator account (sdwan) to log in to Unified Platform. Navigate to the Monitor > Alarm > Active Alarms page. By default, the active alarms generated in the last 30 days are displayed. After an alarm is cleared, it will not be immediately moved to the history alarm list. All the alarms cleared at a day will be moved to the history alarm list at 24:00 that day, as shown in Figure 234.
History alarms
Use a tenant service administrator account (sdwan) to log in to Unified Platform. Navigate to the Monitor > Alarm > History Alarms page. By default, the alarms recovered in the last 3 days are displayed, as shown in Figure 235.
Alarm forwarding
Use a tenant service administrator account (sdwan) to log in to Unified Platform. Navigate to the Monitor > Alarm > Alarm Forwarding Rules page. On this page, you can configure alarm forwarding rules. Alarms can be forwarded through emails, SMS messages, and WeChat messages. Click Add to add an alarm forwarding rule, as shown in Figure 236.
Figure 236 Adding an alarm forwarding rule
Trap management
Use a tenant service administrator account (sdwan) to log in to Unified Platform. Navigate to the Monitor > Alarm > Trap Management page. This page includes the following four submenus.
· Trap List: You can view all traps received by Unified Platform. Unified Platform receives trap messages and generates alarms accordingly. The alarms generated by the SeerEngine-SDWAN controller are also sent to Unified Platform through trap messages.
· Trap Definitions: Each trap has a predefined alarm severity. You can edit the
severity of a trap. You can view trap information based on the trap name and
OID. To edit the information of a trap, click the Edit
icon 
in the Actions column. For example, you
can change the severity of the link packet loss rate major alarm to Warning, as shown in Figure 237.
Figure 237 Changing trap severity
· Trap Filter Rules: Filter duplicate alarms according to the configured rules.
· Trap-to-Alarm Rules: After Unified Platform receives traps, it upgrades the traps to alarms according to the trap-to-alarm rules. The system has predefined a large number of trap-to-alarm rules. You can enable or disable the predefined trap-to-alarm rules but you cannot delete them. You can search for specific trap-to-alarm rules and then switch the on/off status by clicking the status. Then, traps sent by SDWAN will not be escalated to alarms, as shown in Figure 238.
Figure 238 Trap-to-alarm rules
Controller log management
The controller can synchronize operation logs and system logs to the upper-level log server for users to implement unified O&M management.
When the controller becomes faulty, you can use the running logs and operation logs of the controller to troubleshoot the issue.
Operation logs
1. Log in to Unified Platform as the system administrator (admin).
2. Navigate to the System > Log Management > Operation Logs Entries page, as shown in Figure 239.
3. To edit operation log settings, navigate to the System > Log Management > Log Settings > Operation Logs Configuration page. On this page, you can edit the operation log settings and log server settings, as shown in Figure 240. To ensure that operations are traceable, the number of log saving days must be greater than 180.
Figure 240 Operation log settings
System logs
System logs contain all alarms.
1. Log in to Unified Platform as the system administrator (admin).
2. Navigate to the System > Log Management > System Logs Entries page. On this page, you can view system logs, as shown in Figure 241.
3. You can implement the alarm forwarding function through system log delivery. To edit system log settings, navigate to the System > Log Management > Log Settings > System Logs Configuration page, as shown in Figure 242.
Figure 242 System log settings
Running logs
The controller requires running logs for troubleshooting.
1. To view global running logs or logs for each node, log in to Unified Platform as the system administrator (admin).
2. Navigate to the System > Log Management > Running Logs Entries page, as shown in Figure 243.
3. Search for the logs based on the time when the problem occurred and the associated component. You can select all displayed logs and export them.
4. To edit running log settings, navigate to the System > Log Management > Log Settings > Running Logs page, as shown in Figure 244.
Figure 244 Running log settings
Role-based permission configuration
Configure permissions and domains
Role-based permission configuration enables users to manage or query various devices and VPNs, and assigns different permissions to different users.
Table 7 shows the configuration requirements.
Table 7 Role-based permission configuration requirements
|
User |
Permissions |
Managed network devices and VPNs |
Remarks |
|
sdwan1 |
Service management permissions. Only the query permissions for application scheduling are supported. Management permissions for application scheduling are not supported. |
· Managed network devices: Hub1-1, Hub1-2, Spoke1-1, and Spoke1-2 · Managed VPNs: All VPNs |
N/A |
|
sdwan2 |
Service management permissions. Permissions for website caching and query are not supported. |
· Managed network devices: All devices · Managed VPNs: VPN 1 |
N/A |
Prerequisites
Create a new VPN (for example, VPN 2), and then bind the VPN to all devices as described in "Manage VPNs."
Create a tenant system administrator
1. Log in to Unified Platform as the default system administrator (admin).
2. Navigate to the System > Operator Management > Operators page. Click Add. Configure related parameters as shown in Figure 245.
3. In this example, specify admin2 as the operator name sdwan, select tenant SDWAN, select organization SDWAN, select System Manager Group as the role group, select Simple Password Authentication as the authentication mode, and set the login password to Pwd@12345.
Figure 245 Adding a system administrator
Create a network device manager and a branch VPN manager
1. Log in to Unified Platform as the tenant system administrator (admin2).
2. Navigate to the System > Role Management > Roles page.
3. Perform the following operations to create a network device manager:
a. Search for the Network
Device Manager role, and then click the 
icon to copy the
role.
b. Specify Network-Device-Manager-1 as the role name, select resources Hub1-1, Hub1-2, Spoke1-1, and Spoke1-2 as the effect scope.
Figure 246 Creating a network device manager
4. Perform the following operations to create a branch VPN manager:
a. Search for the Branch VPN Management Manager role, and then click the 
icon to copy the
role.
b. Specify Branch-VPN-Management -Manager-1 as the role name, select resource VPN 1 as the effect scope.
Figure 247 Creating a branch VPN manager
Create service manager groups and assign permissions to them
1. Log in to Unified Platform as the tenant system administrator (admin2).
2. Navigate to the System > Role Management > Role Groups page.
3. Perform the following operations to create role group Service-Manager-Group1:
a. Click the 
icon for Service Manager Group in the role group list to copy the
role group.
b. Specify Service-Manager-Group1 as the role group name.
c. In the Roles area, perform the following operations in sequence:
- In the Selected column, search for all branch TE-related roles, select all manager roles from the search result, and then
click 
to cancel their permissions.
- In the Available column, search for all branch TE-related roles, select all
viewer roles from the search result, and then click 
to
assign them permissions.
- In the Selected column, search for all network
device-related roles, select all manager roles from the
search result, and then click 
to cancel their
permissions.
- In the Available column, select Network-Device-Manager-1, and then click 
to
assign it permissions.
Figure 248 Creating role group Service-Manager-Group1—TE-related
Figure 249 Creating role group Service-Manager-Group1—network device-related
4. Perform the following operations to create role group Service-Manager-Group2:
a. Click the 
icon for Service Manager Group in the role group list to copy the
role group.
b. Specify Service-Manager-Group2 as the role group name.
c. In the Roles area, perform the following operations in sequence:
- In the Selected column, search for all Web cache-related roles, select them,
and then click 
to cancel their permissions.
- In the Selected column, search for all VPN-related roles, select all branch VPN manager roles from the search result, and then click 
to
cancel their permissions.
- In the Available column, select Branch-VPN-Management -Manager-1, and then click 
to assign it permissions.
Figure 250 Creating role group Service-Manager-Group2—Web cache-related
Figure 251 Creating role group Service-Manager-Group2—VPN management-related
Create users
1. Log in to Unified Platform as the tenant system administrator (admin2).
2. Navigate to the System > Operator Management > Operators page.
3. Add operators sdwan1 and sdwan2 separately.
Operator sdwan1 belongs to role group Service-Manager-Group1 and operator sdwan2 belongs to role group Service-Manager-Group2.
Figure 252 Creating operator sdwan1
Figure 253 Creating operator sdwan2
|
|
CAUTION: · To have a user manage specific resources, you must create a dedicated role. When you configure the related role group, cancel permissions of the default roles (including all resource management permisssions). If you fail to do so, the created role does not take effect. · You must assign permissions for viewing resources to implement role-based permission management. You can bind associated permissions to a role upon creation of the role as described in this document, or use the default resource group viewer or manager role. · For a user that already has VPN resources, the user can search for all configurations of the related VPNs when it views branch VPN resources, regardless of whether it has device management permissions. |
Verify the configuration
Test the functions of sdwan1
1. Log in to the controller as user sdwan1.
2. Navigate to the Automation > Branch Networks > Application TE > TE Groups page. User sdwan1 only has the permission to view TE groups.
Figure 254 TE groups
3. Navigate to the Automation > Branch Networks > Physical Networks > Devices > Devices page to view device information. The device list only displays the devices that are manageable for user sdwan1.
Figure 255 Device list for user sdwan1
Test the functions of sdwan2
1. Log in to the controller as user sdwan2.
2. Navigate to the Automation > Branch Networks page. In the left navigation pane, the Web cache menu is not available.
Figure 256 Menu
3. Navigate to the Automation > Branch Networks > Virtual Networks > VPN Management > VPNs page to view VPN information. The VPN list only displays the VPNs that are manageable for user sdwan2.
Figure 257 VPN list for user sdwan2
Remote management
The controller can remotely manage a device through the WebSocket channel after the device is successfully registered.
You can implement remote management in the following modes:
· Telnet mode—Connects to the device through Telnet over WebSocket. This mode requires additional device configuration, and supports entering the Tab key and question mark (?) for help information.
The controller cannot collect device debugging information through remote management. You can use remote management to deploy remote login configuration to devices and log in to devices remotely for debugging. For the detailed procedure, see the configuration guides for the devices.
Non-telnet mode
1. Log in to Unified Platform as the tenant service administrator (sdwan).
2. Navigate to the Automation > Branch Networks > Assurance > Remote Manage page.
3. Select devices, and turn off the Telnet option to issue commands directly to the devices. For example, you can remotely manage device Spoke1-1 and query the BGP neighbor state, as shown in Figure 258.
Telnet mode
You can use telnet to remotely manage by using the following methods:
· Username and password authentication—This method requires entering the username and password for login authentication.
· Password authentication—This method requires entering the password for login authentication.
· No authentication—This method does not require login authentication.
Username and password authentication
1. When managing the device remotely, you must enter the correct username and password for login authentication, and assign controller permissions on the device in the login user settings. Issue the following commands on the device:
#
line vty 0 63
authentication-mode scheme //Specify scheme authentication. The default method is username and password authentication.
#
local-user telnet //Username used for login.
password simple Pwd@123456 //Authentication password.
service-type telnet //Configure the telnet service type.
authorization-attribute user-role network-admin //Assign user permissions.
#
2. Log in to Unified Platform as the tenant service administrator (sdwan). Navigate to the Automation > Branch Networks > Physical Networks > Devices > Remote Manage page. Select devices, and turn on the Telnet option. As shown in Figure 259, you can remotely manage device Spoke1-1, and then enter the question mark (?) to obtain command information.
Figure 259 Username and password authentication - telnet mode
Password authentication
1. When managing the device remotely, you must enter the correct password for login authentication, and assign controller permissions on the device in the VTY user line. Issue the following commands on the device:
line vty 0 63
authentication-mode password //Configure password authentication.
set authentication password simple Pwd@123456 //Set the password used for password authentication.
user-role network-admin //Assign user permissions.
2. Log in to Unified Platform as the tenant service administrator (sdwan). Navigate to the Automation > Branch Networks > Physical Networks > Devices > Remote Manage page.
3. Select devices, and turn on the Telnet option. As shown in Figure 260, you can remotely manage device Spoke1-1, and then enter the question mark (?) to obtain command information.
Figure 260 Password authentication - telnet mode
No authentication
1. Specify to not use authentication, and assign controller permissions on the device in the VTY user line. Issue the following commands on the device:
line vty 0 63
authentication-mode none //Specify to not use authentication.
user-role network-admin //Assign user permissions.
2. Log in to Unified Platform as the tenant service administrator (sdwan). Navigate to the Automation > Branch Networks > Physical Networks > Devices > Remote Manage page.
3. Select devices, and turn on the Telnet option. As shown in Figure 261, you can remotely manage device Spoke1-1, and then enter the question mark (?) to obtain command information.
Figure 261 No authentication - telnet mode
|
|
CAUTION: The authentication configuration for the VTY user line is the global configuration that must be compliant with the user security policy. As a best practice, use the username and password authentication method. |
O&M diagnostic tools
The controller provides two O&M diagnostic tools: ping and tracert. You can perform ping and tracert operations on the specified device to troubleshoot network problems.
Ping
1. Log in to Unified Platform as the tenant service administrator (sdwan).
2. Navigate to the Automation > Branch Networks > Assurance > O&M Diagnostics > Ping page.
3. Click Diagnose to add a ping task, as shown in Figure 262.
Parameters:
¡ Device Name: Select the device to perform the ping operation.
¡ VPN: Specify the VPN instance for the ping operation. After you specify this parameter, the available interfaces for selection are filtered by the VPN instance.
¡ Output Interface Name: Select an output interface for sending ICMP packets.
¡ Source IP: Specify the source IP address for sending ICMP packets.
¡ Destination Address: Specify the destination IP address or host name. To specify a host name, make sure the host name can be correctly resolved.
¡ Packet Size: Specify the size of ICMP echo request packets.
¡ Packet Count: Specify the number of times to send ICMP echo request packets.
4. Click OK to start the ping operation.
After a period of time when the ping operation is successful, you can view the ping result, as shown in Figure 263.
Tracert
1. To correctly display the tracert result, execute the following commands on all devices in the forwarding path.
<spoke1>system-view
[spoke1]ip ttl-expires enable
[spoke1]ip unreachables enable
2. Log in to Unified Platform as the tenant service administrator (sdwan).
3. Navigate to the Automation > Branch Networks > Assurance > O&M Diagnostics > Tracert page.
4. Click Diagnose to add a tracert task, as shown in Figure 264.
Parameters:
¡ Device Name: Select the device to perform the tracert operation.
¡ VPN: Specify the VPN instance for the tracert operation. After you specify this parameter, the available interfaces for selection are filtered by the VPN instance.
¡ Output Interface Name: Select an output interface for sending tracert packets.
¡ Source IP: Specify the source IP address for sending probe packets.
¡ Destination Address: Specify the destination IP address or host name. To specify a host name, make sure the host name can be correctly resolved.
¡ Dest Port: Typically, this parameter does not need to be edited. If the destination address of the tracert operation is the EID address in a remote LISP site, the destination UDP port number must be equal to or larger than 33434.
¡ Timeout Time: Specify the response timeout timer for probe packets.
¡ Initial TTL: Specify the maximum hop count allowed in the first packet.
¡ Maximum TTL: Specify the maximum hop count allowed in a packet.
¡ Packet Count: Specify the number of times to send probe request packets.
5. Click OK to start the tracert operation.
After a period of time when the tracert operation is successful, you can view the probe result (in a table by default), as shown in Figure 265. To display the path that the probe packets have traversed in a diagram, turn on the Diagram option in the upper right corner, as shown in Figure 266.
Figure 265 Tracert result displayed in a table
Figure 266 Tracert result displayed in a diagram
Device software upgrade
The controller can upgrade the software version of devices on a per device basis or in bulk. To download the software version for upgrade, the devices use HTTPS to access port 35000 associated with the unified northbound IP address of the controller.
Figure 267 shows the device software upgrade workflow.
Figure 267 Device software upgrade workflow
|
|
CAUTION: · With a firewall deployed before the controller, the controller must open TCP port 35000 associated with the unified northbound IP address. · With a NAT device deployed before the controller to map the northbound IP address of the controller to the external network, you must add a mapping between the same public network address and TCP port 35000. |
Upload device software version to be upgraded
1. Log in to Unified Platform as the tenant service administrator (sdwan).
2. Navigate to the Automation > Branch Networks > Physical Networks > Assurance > Device Upgrade > Device Versions page.
3. Click Upload to upload a device software version.
The supported file formats include IPE and BIN. The uploaded files will be sorted by device model and version number, as shown in Figure 268.
|
|
CAUTION: · The supported file format for uploading can only be IPE or BIN. Make sure each file has a unique name. · The controller supports software upgrade by using only the IPE or BIN files. |
Per-device software upgrade
Select a device for upgrading
1. Log in to Unified Platform as the tenant service administrator (sdwan).
2. Navigate to the Automation > Branch Networks > Physical Networks > Devices page.
3. In the Actions column for the target device, click More > Upgrade to display the supported software image files supported by the device model, as shown in Figure 269.
Parameters:
¡ Image File Upload Path—Edit the image file upload path as needed. Typically, the default path is used.
¡ Low-capacity storage mode—Enable low-capacity storage mode if the storage capacity of the device is small. In this mode, the free storage space on the device must be greater than the size of the upgrade file for a successful upgrade. If low-capacity storage mode is disabled, the free storage space on the device must be greater than twice the upgrade file for a successful upgrade.
|
|
CAUTION: For a low-capacity MSR device, the controller identifies whether the device supports the low-capacity storage upgrade mode. If the upgrade mode is supported, the controller will upgrade the device in this upgrade mode. |
4. Select the image file for upgrade, and then click Next to enter the Device Check Before Upgrade page.
Device check before upgrade
Figure 270 shows the Device Check Before Upgrade page.
Figure 270 Device check before upgrade
1. Click Check to check the following items on the device:
¡ Device State Check: A device can be upgraded only when it is online.
¡ Device Module Check: Checks whether the device version has been damaged. Because upgrade based on IPE file requires a save and reboot operation, device version damage might result in configuration loss.
¡ Device Type Check: Checks whether the device model matches the image file.
¡ Device Free Disk Space Check: Checks whether the remaining disk space on the device can meet the upgrade requirements. For a successful upgrade, make sure the remaining space is twice the size of the IPE file to save the IPE file and the decompressed BIN file. In low-capacity storage upgrade mode, make sure the remaining space is greater than the size of the IPE file.
Figure 271 shows the device has successfully passed the checks.
Figure 271 Device check result
2. After the device check, click Upgrade to create an upgrade task.
|
|
CAUTION: · If you do not perform device checks before the upgrade or you forcibly perform an upgrade without a successful upgrade check, the upgrade might fail or configuration loss might occur. Make sure you understand the potential impact before performing such an upgrade. · The controller checks all storage spaces of a device during the space check. For a device that has multiple storage spaces, such as sda0 and sda1, the device can pass the space check only if all of its storage spaces meet the upgrade requirements. |
Upgrade task
The system automatically starts upgrading after an upgrade task is created.
1. Check the remaining disk space. The upgrade cannot be performed if the remaining disk space is not enough. You cannot skip the check. If the space requirement is not satisfied, you must delete the file on the device, release the space, and then perform the upgrade again.
2. The device automatically downloads the software version through HTTPS.
3. After version download, click the 
icon
in the Actions column to continue the upgrade, as
shown in Figure 272.
When the upgrade fails, click 
to
restart the upgrade.
Figure 273 Upgrade failure
After the associated upgrade command is issued, the device saves the configuration and then reboots to complete the upgrade.
|
|
IMPORTANT: When an upgrade task fails, you can retry it directly. To re-upgrade a device with a new upgrade task, delete the failed upgrade task first. |
4. Navigate to the Automation > Branch Networks > Assurance > Device Upgrade > Maintenance Records page to view the associated upgrade task, as shown in Figure 274.
Figure 274 Maintenance records
Bulk device software upgrade
Select software version to be upgraded
1. Log in to Unified Platform as the tenant service administrator (sdwan).
2. Navigate to the Automation > Branch Networks > Assurance > Device Upgrade > Device Versions page.
3. Select the target version and click 
to access the Device
Upgrade Settings page. The
controller provides all devices applicable to this version.
4. Select the devices to be upgraded in bulk. This example selects two devices to perform batch upgrade, as shown in Figure 275.
Figure 275 Device upgrade settings
5. Click Next to access the Device Check Before Upgrade page.
Device check before upgrade
1. Click Check to check the following items on the device:
¡ Device State Check: A device can be upgraded only when it is online.
¡ Device Module Check: Checks whether the device version has been damaged. Because upgrade based on IPE file requires a save and reboot operation, device version damage might result in configuration loss.
¡ Device Type Check: Checks whether the device model matches the image file.
¡ Device Free Disk Space Check: Checks whether the remaining disk space on the device can meet the upgrade requirements.
The system checks all devices to be upgraded. After the check is complete, the check result is displayed, as shown in Figure 276.
Figure 276 Device check result
2. After device check, click Upgrade to create an upgrade task.
|
|
CAUTION: · If you do not perform device checks before upgrade or forcibly perform an upgrade without a successful upgrade check, the upgrade might fail or configuration loss might occur. Make sure you understand the potential impact before performing such an upgrade. · A tenant can synchronously upgrade up to 100 devices. · The batch upgrade operation needs to download version files for the upgraded devices. The download threads are allocated by hash and the system supports synchronously downloading version files for up to 20 devices. Version file download might fail if the system fails to push version files to the upgraded devices within 3 hours. To avoid this issue, when you perform a batch upgrade, determine the number of upgraded devices with caution according to the network condition. · Only batch upgrade is available for a patch version. You cannot patch devices with a patch version from the device list. When you patch devices, make sure the target device models are compatible with the patch version. |
Upgrade task
The system automatically starts upgrading after an upgrade task is created.
1. Check the remaining disk space. The upgrade cannot be performed if the remaining disk space is not enough. You cannot skip the check. If the space requirement is not satisfied, you must delete the file on the device, release the space, and then perform the upgrade again.
2. The devices automatically download the software version and all devices download the software version simultaneously.
3. After version download, you can select other devices, and then click Resume to perform upgrade for the selected devices, as shown in Figure 277.
After the associated upgrade command is
issued, the device saves the configuration and then automatically reboots to
complete the upgrade. When the upgrade fails, click 
to
restart the upgrade.
|
|
IMPORTANT: When an upgrade task fails, you can retry it directly. To re-upgrade a device with a new upgrade task, delete the failed upgrade task first. |
4. Navigate to the Automation > Branch Networks > Physical Networks > Devices > Maintenance Records page to view the associated upgrade task.
Backup restoration and replacement
You can perform manual backup or scheduled backup and restore configurations from a backup. If a device requires replacement, you can use the backup and restoration features to fast configure the new device. Devices use HTTPS to access TCP port 35000 of the controller at the unified northbound address to upload or download backup files.
For device configuration backup restoration and replacement workflow, see Figure 278.
Figure 278 Manual backup restoration and replacement workflow
|
|
CAUTION: · With a firewall deployed before the controller, the controller must open TCP port 35000 associated with the unified northbound IP address. · With a NAT device deployed before the controller to map the northbound IP address of the controller to the external network, you must add a mapping between the same public network address and TCP port 35000. |
Back up device configuration manually
1. Log in to Unified Platform by using the tenant administrator account sdwan.
2. Navigate to the Automation > Branch Networks > Physical Networks > Devices page.
3. Click the More > Backup in the Actions column for the target device, as shown in Figure 279.
4. To view backup files, click the 
icon in the Actions
column for a device, as shown in Figure 280.
Figure 280 Configuration files
5. Select a configuration file. To download a
configuration file, click the 
icon in the Actions column. To view the preview of a configuration
file, click the 
icon. You can also click Upload Configuration
File to upload a configuration file.
6. To view the configuration backup records, navigate to the Automation > Branch Networks > Physical Networks > Devices > Maintenance Records page, as shown in Figure 281.
Figure 281 Maintenance records
|
|
CAUTION: · The system can save a maximum of 30 backup files for a device. If the upper limit is reached, creating a new backup file deletes the oldest one. To save the previous backup files, download them manually. · A tenant can maintain a maximum of 3000 records. Exceeding records will overwrite oldest ones. |
Configure scheduled backup
1. Log in to Unified Platform as the tenant service administrator (sdwan).
2. Navigate to the Automation > Branch Networks > Parameter Settings > O & M Settings > Device Scheduled Backup Settings page.
3. Enable Scheduled Backup, as shown in Figure 282. By default, scheduled backup is enabled.
Figure 282 Configuring scheduled backup
Restore configuration
You can restore device configuration from a backup file.
1. Log in to Unified Platform as the tenant service administrator (sdwan).
2. Navigate to the Automation > Branch Networks > Physical Networks > Devices page.
3. In the Actions column, click 
to view backup configuration files for the device, as shown in Figure 283.
Figure 283 Configuration files
4. Click the 
icon for the
target configuration file to restore the configuration. In the dialog box that
opens, click OK, as shown in Figure 284.
Figure 284 Confirming configuration restoration
After restoration, the system displays the operation result and configuration restoration time, as shown in Figure 285.
|
|
CAUTION: · To restore configurations from a saved configuration file, the operation might fail if you have manually edited the file. · Configuration restoration uses configuration rollback commands, and restoration failure might occur out of various issues. Use this feature with caution. |
Replace a device
After backing up device configurations, if a device fails, you can back up the device configurations and replace the faulty one with a device of the same model.
Add and register a new device
1. Log in to Unified Platform as the tenant service administrator (sdwan).
2. Navigate to the Automation > Branch Networks > Physical Networks > Devices page.
3. Click Add to open the Add Device page, as shown in Figure 286. The device name and router ID are configured temporarily.
After replacement, the device name and router ID will be replaced by the settings of the faulty device. For the device to register successfully, make sure the SN is correct.
4. Configure device registration.
Remove cables from the faulty device and connect them to the new device in the same way. The new device will automatically use the configuration of the faulty one to register because they are connected the same way. Therefore, you do not must bind its site or import WAN details after adding the device. If the faulty device was configured from a URL or by using a USB disk, you can configure the new device in the same way. For more information, see "Deploy devices via USB/email." If you successfully replace the faulty device with a new device, the faulty device will be offline.
Execute device replacement
1. In the Actions column for the faulty device, click More > Replace.
2. Select the configuration file to use, as shown in Figure 287, and then click Next.
Figure 287 Configuring faulty device settings
3. Select the new device name, as shown in Figure 288, and then click Next.
Figure 288 Configuring new device settings
4. Check the following items before replacement:
a. Configuration file: Verify that the file exists on the server.
b. Faulty device state: Verify that the faulty device or faulty IRF member is offline.
c. New device management state: Verify that the new device is managed by the controller.
d. Device type: Verify that the new device and the faulty device are of the same model.
e. Software version: Verify that the new device and the faulty device use the same software version.
f. New device remaining disk space: Verify that the available disk space on the new device can meet the requirements.
As shown in Figure 289, after performing pre-replacement check, click Replace.
Figure 289 Performing pre-replacement check
5. The replacement task information is displayed. The controller pushes configurations to the new device, sets the configuration file as the startup file, and then restarts the device.
6. To view the replacement record, navigate to the Automation > Branch Networks > Physical Networks > Devices > Maintenance Records page.
|
|
CAUTION: · For a successful replacement, make sure the new device uses the factory configuration and is not added to any site when you replace a faulty device with a new one. · As a best practice, use a backup configuration file for device replacement and do not edit the content of that file. |
Configuration audit
The controller enables the configuration audit feature. The feature can compare device running configurations and configurations saved in the controller database and display the differences. You can view, manage (synchronize or ignore), or export the differences, and modify inconsistent configurations as needed.
Configuration audit
1. Log in to Unified Platform as the tenant service administrator (sdwan).
2. Navigate to the Automation > Branch Networks > Assurance > Configuration Audit page, as shown in Figure 290.
Figure 290 Configuration audit
3. To perform a configuration audit, click the Start Audit icon 
in the Actions column.
4. To view the result of the most recent audit
for a device, click the Audit Result icon 
in
the Actions column. You can filter the audit result
by data modules, data type, and data status, as shown in Figure 291.
The display and operation of the audit results are based on the configuration saved by the controller. The operation instructions are as follows:
¡ For configuration existing only on the controller, you can synchronize the configuration to the device. Select the configuration and click Synchronize to deploy the configuration to the device.
¡ For configuration existing only on a device, you can synchronize the configuration to the controller or ignore it. Select the configuration and click Synchronize to delete the configuration on the device. Click Ignore and the configuration on the device will be changed.
¡ For configuration inconsistency, you can synchronize configurations on the controller to the device. Select the configuration and click Synchronize to edit the configuration on the device to be consistent with that on the controller.
¡ For differences generated due to module errors, you can only view configurations affected by module soft deletion.
|
|
CAUTION: · Synchronizing configurations to a device might affect service operation. Please contact Technical Support first. · You cannot view the synchronization result immediately after configuration synchronization between the controller and devices. |
Configuration check
The controller enables configuration check. This feature enables you to obtain the specified configurations from devices or compare device configurations.
Obtain device configurations
1. Log in to Unified Platform as the tenant service administrator (sdwan).
2. Navigate to the Automation > Branch Networks > Assurance > Configuration Check > Obtain Configuration page.
3. Select devices, and then click Obtain Configuration, as shown in Figure 292.
The tab displays the most recent time at which device configuration was obtained and the operation result. You can view and dispose of the obtained configuration file on the Compare Configuration page. The system can save up to 5 device configuration files. If the limit is reached, you must first delete files on the Compare Configuration tab before obtaining more device configurations.
Figure 292 Obtaining device configuration
Compare configurations
Perform this task to download, delete, and edit remarks for configuration files and compare device configurations.
1. Log in to Unified Platform as the tenant service administrator (sdwan). Navigate to the Automation > Branch Networks > Assurance > Configuration Check > Compare Configuration page. On this page, select a device from the drop-down option box, and then you can view all the configuration files obtained by the device.
2. Click the 
icon in the Actions column, and then you can edit, delete, or
download the configuration files. To compare device configurations, select two
files, and then click Compare. Then, the comparison
result of the two configuration files pops up, as shown in Figure 293.
Figure 293 Configuration comparison result
Site Internet access
Site Internet access allows sites to access the Internet locally or via CPEs. The controller provides local Internet access, centralized Internet access, and hybrid Internet access services. Local or centralized Internet access is not available for certain applications.
Site Internet access configuration
Interface GE7/0 is added on device Spoke1-2 in Branch1 for access to the Internet.
Table 8 Site Internet access configuration
|
Site |
Site Internet access scheme |
Local Internet access interface |
Route priority |
Probing |
NAT |
|
HQ1 |
Local Internet access Centralized Internet access gateway |
GE2/0.2 (LAN interface) |
3 |
Required Probing IP address: Peer address |
Not required |
|
Branch1 |
Local Internet access Centralized Internet access gateway as backup |
GE7/0 (non-WAN and non-LAN interface) |
3 |
Not required |
Required |
|
Branch2 |
Local Internet access Centralized Internet access as backup |
GE5/0 (WAN interface) |
3 |
Required Probing IP address: 8.8.8.8 (public network address) |
Required |
|
Branch3 |
Centralized Internet access Local Internet access as backup |
GE4/0 (WAN interface) |
7 |
Not required |
Required |
Restrictions and guidelines
If an Internet access interface in one VPN provides local Internet access for another VPN, configure outbound dynamic NAT as a best practice. If you do not configure NAT, manually redistribute routes between the VPNs based on the network environment.
The Internet access interface must be a Layer 3 interface (an interface configured with IP addresses), for example, Dialer interface (corresponding to PPPoE dialup) or VLAN interface (corresponding to Layer 2 outgoing interface).
Local Internet access
Configure local Internet access on the controller
1. Log in to Unified Platform as the tenant service administrator (sdwan).
2. Navigate to the Automation > Branch Networks > Virtual Networks > VPNs > VPNs page.
3. Click the 
icon
in the Actions column for VPN1.
4. Click the Local Internet Access tab, and then click Add.
5. Select HQ1 from the site list, and then click Add. Select Hub1-1 from the device list, configure the following parameters, and then click OK.
¡ Internet Access Interface: Select an interface to provide Internet access. You can select a WAN interface, LAN interface, or non-WAN non-LAN interface. LAN interface GE2/0.2 is selected in this example.
¡ Internet Access Interface VPN: Select the VPN associated with the Internet access interface. VPN1 is selected in this example.
¡ Route Priority: Enter the priority of the static route to deploy for site Internet access. The smaller the value, the higher the priority. For local Internet access, make sure the route priority value is not greater than 5, priority of the IBGP routes deployed by the controller. The route priority is set to 3 in this example.
¡ Next Hop Type: Select DHCP or static IP. Skip this parameter for a dialer, serial, or Eth interface. The next hop type is set to static IP in this example.
¡ Next Hop IP: Enter the address of the peer gateway. The peer gateway address is 20.1.10.1 in this example.
¡ Probing: Configure whether to probe connectivity between the Internet access interface and the probing IP address. Probing is enabled in this example.
¡ Probing IP: Enter an IP address used to probe the connectivity between the local site and the public network. The probing IP address is 20.1.10.1 in this example.
¡ Outbound Dynamic NAT: Set the state of outbound dynamic NAT. Outbound dynamic NAT is disabled in this example.
Figure 294 Configuring site Internet access for Hub1-1
6. Configure local Internet access for Hub1-2 in the same way Hub1-1 is configured.
7. Select Branch1 from the site list, and then click Add. Select Spoke1-2 from the device list, configure the following parameters, and then click OK.
¡ Internet Access Interface: Select an interface to provide Internet access. You can select a WAN interface, LAN interface, or non-WAN non-LAN interface. Non-WAN non-LAN interface GE7/0 is selected in this example.
¡ Internet Access Interface VPN: Select the VPN associated with the Internet access interface. PublicInstance is selected in this example.
¡ Route Priority: Enter the priority of the static route to deploy for site Internet access. The smaller the value, the higher the priority. For local Internet access, make sure the route priority value is not greater than 5, priority of the IBGP routes deployed by the controller. The route priority is set to 3 in this example.
¡ Next Hop Type: Select DHCP or static IP. Skip this parameter for a dialer, serial, or Eth interface. The next hop type is set to static IP in this example.
¡ Next Hop IP: Enter the address of the peer gateway. The peer gateway address is 110.1.8.2 in this example.
¡ Probing: Configure whether to probe connectivity between the Internet access interface and the probing IP address. Probing is disabled in this example.
¡ Outbound Dynamic NAT: Set the state of outbound dynamic NAT. Outbound dynamic NAT is enabled in this example.
Figure 295 Configuring site Internet access for Spoke1-2
8. Select Branch2 from the site list, and then click Add. Select Spoke2 from the device list, configure the following parameters, and then click OK.
¡ Internet Access Interface: Select an interface to provide Internet access. You can select a WAN interface, LAN interface, or non-WAN non-LAN interface. WAN interface GE4/0 is selected in this example.
¡ Internet Access Interface VPN: Select the VPN associated with the Internet access interface. PublicInstance is selected in this example.
¡ Route Priority: Enter the priority of the static route to deploy for site Internet access. The smaller the value, the higher the priority. For local Internet access, make sure the route priority value is not greater than 5, priority of the IBGP routes deployed by the controller. The route priority is set to 3 in this example.
¡ Next Hop Type: Select DHCP or static IP. Skip this parameter for a dialer, serial, or Eth interface. The next hop type is set to static IP in this example.
¡ Next Hop IP: Enter the address of the peer gateway. The peer gateway address is 110.1.4.2 in this example.
¡ Probing: Configure whether to probe connectivity between the Internet access interface and the probing IP address. Probing is enabled in this example.
¡ Probing IP: Enter an IP address used to probe the connectivity between the local site and the public network. The probing IP address is 8.8.8.8 in this example.
¡ Outbound Dynamic NAT: Set the state of outbound dynamic NAT. Outbound dynamic NAT is enabled in this example.
Figure 296 Configuring site Internet access for Spoke2
Add GE5/0 as an Internet access interface for site Branch2 in the same way.
9. Select Branch3 from the site list, and then click Add. Select Spoke3 from the device list, configure the following parameters, and then click OK.
¡ Internet Access Interface: Select an interface to provide Internet access. You can select a WAN interface, LAN interface, or non-WAN non-LAN interface. WAN interface GE4/0 is selected in this example.
¡ Internet Access Interface VPN: Select the VPN associated with the Internet access interface. PublicInstance is selected in this example.
¡ Route Priority: Enter the priority of the static route to deploy for site Internet access. The smaller the value, the higher the priority. For local Internet access, make sure the route priority value is not greater than 5, priority of the IBGP routes deployed by the controller. The route priority is set to 7 in this example, because the static route is used for local Internet access backup.
¡ Next Hop Type: The next hop type is set to DHCP in this example. You do not need to specify a next hop IP address.
¡ Probing: Configure whether to probe connectivity between the Internet access interface and the probing IP address. Probing is disabled in this example.
¡ Outbound Dynamic NAT: Set the state of outbound dynamic NAT. Outbound dynamic NAT is enabled in this example.
Figure 297 Configuring site Internet access for Spoke3
10. Click Add, configure another local Internet access interface for Spoke3 in the same way GE4/0 is configured, and then click OK.
|
|
IMPORTANT: · For a site with one or two Internet access devices, you must configure the same Internet access type (local Internet access or local Internet access backup) for all Internet access interfaces. If local Internet access is prioritized, make sure the route priority value of all the Internet access interfaces is smaller than 5. For local Internet access backup, make sure the route priority value of all the Internet access interfaces is greater than 5. · When the Internet access interface is configured with outbound dynamic NAT, all VPNs that use this interface for Internet access must be configured with dynamic NAT, and you cannot disable NAT separately for a single VPN. |
Configure route synchronization
After you configure local Internet access for a site with two Internet gateways, manually synchronize the routes used for Internet access between the Internet access devices. Route consistency ensures uninterrupted Internet access upon failure of one of the Internet access interfaces. You can synchronize routes through LAN interfaces or over a manually set up synchronization link. In this example, HQ1 uses a LAN interface for route synchronization, and route synchronization is manually configured on Branch1.
To configure route synchronization:
1. Add interconnect interfaces as described in "Configure route synchronization." When you configure OSPF routes, you must enable default-route redistribution and set the redistribution method as Permit-Calculate-Other.
2. In the local Internet access scenario, the default route deployed by the controller for site Internet access is a static route. To redistribute the controller-deployed default route (static route) to OSPF, configure a route prefix and a routing policy.
a. Navigate to the Automation > Branch Networks > Physical Networks > Device Settings > Routing Policies page. On the route prefix management page, click Add to add a route prefix to match network 0.0.0.0/0.
Figure 298 Adding a route prefix
a. Click Add on top of the routing policy list and add a routing policy to match prefix list default.
Figure 299 Adding a routing policy
3. Navigate to the Automation > Branch Networks > Physical Networks > Device Settings > OSPF Routes page.
4. Click the 
icon
in the Redistribution Route column for the OSPF route of Spoke1-2.
Figure 300 OSPF route of Spoke1-2
5. Add a static route, associate the static
route with routing policy default, and then click the 
icon.
Figure 301 Redistributing a static route
6. Configure OSPF:
# To prioritize local Internet access for Branch1, configure OSPF to advertise the controller-deployed default route with a priority higher than that of BGP routes.
#
ospf 10 router-id 20.1.13.1 vpn-instance VPN1
preference ase 5 route-policy default //Use routing policy default to match the controller-deployed default route to ensure that the route priority of the default route is 5, higher than the priority of BGP routes
#
7. For endpoints at Branch1 to receive Internet traffic upon failure of the local LAN interface, redistribute the LAN-side direct route to OSPF as VRRP is configured on the LAN side:
a. Navigate to the Automation > Branch Networks > Physical Networks > Device Settings > OSPF Routes page.
b. Click the 
icon
in the Redistribution Route column for the OSPF route of Spoke1-1.
c. Add a direct route, associate the direct
route with routing policy DIRECT-VPN1-XXXX, and
then click the 
icon.
Figure 302 Redistributing a direct route
|
|
IMPORTANT: · Only IPv4 site Internet access is available. · For a site with two gateways, by default users visit the Internet via the local Internet access interface of the traffic ingress device. Internet traffic cannot be load shared between the gateways. |
Centralized Internet access
Configure Internet access gateway sites
1. Configure local Internet access for the gateway sites. Make sure each route used for local Internet access has a priority value smaller than 5.
2. Log in to Unified Platform as the tenant service administrator (sdwan).
3. Navigate to the Automation > Branch Networks > Tenant Network > VPNs page.
4. Click the 
icon
in the Actions column for VPN1.
5. Click the Centralized Internet Access tab, and then click Add.
6. Select HQ1 from the primary site list, and then click OK.
Figure 303 Configuring centralized Internet access
|
|
IMPORTANT: · Only IPv4 site Internet access is available. · In a VPN, do not delete the local Internet access sites that act as centralized Internet gateways. · Before you configure centralized Internet access, configure local Internet access for the gateway sites. Make sure each route used for local Internet access has a priority value smaller than 5. · An intermediate device forwards the Internet traffic of a site to the Internet rather than the Internet access gateway site when the following conditions exist: 1. If the Internet traffic of a site is forwarded by the intermediate device to the Internet access gateway site. 2. The intermediate device is configured with local Internet access (route priority smaller than 5). · When primary and backup Internet access gateway sites are configured in conjuction with area priority for a branch site in the area topology, the area priority configuration takes precedence over the configuration of Internet access gateway sites. The Internet traffic of the branch site prefers traffic forwarding via area topology and looks for an Internet access gateway site in the area topology. As a result, the preferrred Internet access gateway site might not be the expected one. |
Verify the configuration
Verify Internet access at HQ1
# Verify that traffic matching the Internet access route on Hub1-1 is forwarded via the local internal network and Hub1-1 can ping 8.8.8.8.
<Hub1-1> display ip routing-table vpn-instance VPN1 0.0.0.0
Summary count : 2
Destination/Mask Proto Pre Cost NextHop Interface
0.0.0.0/0 Static 3 0 20.1.10.1 GE2/0.2
0.0.0.0/32 Direct 0 0 127.0.0.1 InLoop0
<Hub1-1> ping -vpn-instance VPN1 8.8.8.8
Ping 8.8.8.8 (8.8.8.8): 56 data bytes, press CTRL_C to break
56 bytes from 8.8.8.8: icmp_seq=0 ttl=252 time=0.696 ms
56 bytes from 8.8.8.8: icmp_seq=1 ttl=252 time=0.310 ms
56 bytes from 8.8.8.8: icmp_seq=2 ttl=252 time=0.299 ms
56 bytes from 8.8.8.8: icmp_seq=3 ttl=252 time=0.301 ms
56 bytes from 8.8.8.8: icmp_seq=4 ttl=252 time=0.314 ms
--- Ping statistics for 8.8.8.8 in VPN instance VPN1 ---
5 packet(s) transmitted, 5 packet(s) received, 0.0% packet loss
round-trip min/avg/max/std-dev = 0.299/0.384/0.696/0.156 ms
Verify local Internet access at Branch1
# Verify that Spoke1-1 accesses the Internet via Spoke1-2 and Spoke1-1 can ping 8.8.8.8.
<Spoke1-1> display ip routing-table vpn-instance VPN1 0.0.0.0
Summary count : 3
Destination/Mask Proto Pre Cost NextHop Interface
0.0.0.0/0 O_ASE2 4 1 20.2.21.2 GE4/0.1
0.0.0.0/32 Direct 0 0 127.0.0.1 InLoop0
<Spoke1-1>ping -vpn-instance VPN1 8.8.8.8
Ping 8.8.8.8 (8.8.8.8): 56 data bytes, press CTRL_C to break
56 bytes from 8.8.8.8: icmp_seq=0 ttl=250 time=0.976 ms
56 bytes from 8.8.8.8: icmp_seq=1 ttl=250 time=0.437 ms
56 bytes from 8.8.8.8: icmp_seq=2 ttl=250 time=0.435 ms
56 bytes from 8.8.8.8: icmp_seq=3 ttl=250 time=0.423 ms
56 bytes from 8.8.8.8: icmp_seq=4 ttl=250 time=0.460 ms
--- Ping statistics for 8.8.8.8 in VPN instance VPN1 ---
5 packet(s) transmitted, 5 packet(s) received, 0.0% packet loss
round-trip min/avg/max/std-dev = 0.423/0.546/0.976/0.215 ms
Verify local Internet access at Branch2
# Verify that traffic matching the Internet access route on Spoke2-1 is forwarded via the local WAN interface and Spoke2-1 can ping 8.8.8.8.
<Spoke2>display ip routing-table vpn-instance VPN1 0.0.0.0
Summary count : 3
Destination/Mask Proto Pre Cost NextHop Interface
0.0.0.0/0 Static 3 0 110.1.4.2 GE4/0
Static 3 0 110.1.7.2 GE5/0
0.0.0.0/32 Direct 0 0 127.0.0.1 InLoop0
<Spoke2-1> ping -vpn-instance VPN1 8.8.8.8
Ping 8.8.8.8 (8.8.8.8): 56 data bytes, press CTRL_C to break
56 bytes from 8.8.8.8: icmp_seq=0 ttl=255 time=0.797 ms
56 bytes from 8.8.8.8: icmp_seq=1 ttl=255 time=0.145 ms
56 bytes from 8.8.8.8: icmp_seq=2 ttl=255 time=0.113 ms
56 bytes from 8.8.8.8: icmp_seq=3 ttl=255 time=0.123 ms
56 bytes from 8.8.8.8: icmp_seq=4 ttl=255 time=0.108 ms
--- Ping statistics for 8.8.8.8 in VPN instance VPN1 ---
5 packet(s) transmitted, 5 packet(s) received, 0.0% packet loss
round-trip min/avg/max/std-dev = 0.108/0.257/0.797/0.270 ms
Verify centralized Internet access at Branch3
# Verify that traffic matching the Internet access route on Spoke3 is forwarded via the local WAN interface and Spoke3 can ping 8.8.8.8.
<Spoke3>dis ip routing-table vpn-instance VPN1 0.0.0.0
Summary count : 3
Destination/Mask Proto Pre Cost NextHop Interface
0.0.0.0/0 BGP 5 100 7.1.1.11 Tun1
BGP 5 100 7.1.1.12 Tun3
BGP 5 100 7.1.1.12 Tun2
0.0.0.0/32 Direct 0 0 127.0.0.1 InLoop0
<Spoke3>ping -vpn-instance VPN1 8.8.8.8
Ping 8.8.8.8 (8.8.8.8): 56 data bytes, press CTRL_C to break
56 bytes from 8.8.8.8: icmp_seq=0 ttl=255 time=0.570 ms
56 bytes from 8.8.8.8: icmp_seq=1 ttl=255 time=0.248 ms
56 bytes from 8.8.8.8: icmp_seq=2 ttl=255 time=0.288 ms
56 bytes from 8.8.8.8: icmp_seq=3 ttl=255 time=0.226 ms
56 bytes from 8.8.8.8: icmp_seq=4 ttl=255 time=0.224 ms
--- Ping statistics for 8.8.8.8 in VPN instance VPN1 ---
5 packet(s) transmitted, 5 packet(s) received, 0.0% packet loss
round-trip min/avg/max/std-dev = 0.224/0.311/0.570/0.131 ms
Capacity management
An incorporated device might run out of its resources after the controller deploy excess services. The capacity management function can avoid this issue. Even when the controller has incorporated a large number of routers, the controller can monitor the usage of ACL, FIB, and memory resources on those routers and detect resource insufficiency in time.
|
|
CAUTION: · The controller deploys services by device. If a device has multiple modules and one of them is in major alarm state, service deployment to any of the normal modules on the device will be blocked. · The controller cannot distinguish between IPv4 FIB and IPv6 FIB capacities. As long as the IPv4 or IPv6 FIB capacity exceeds the threshold, configuration deployment from the controller will be blocked. · Only the modification operations on normal packets are limited, such as adding, deleting, and modifying packets. Deployment of the following itmes is not limited: 1. Configuration commands deployed in bulk. 2. Configuration commands deployed by the remote management module. 3. Query-type packets. 4. Packets for threshold updates on devices. · The firewall products compatible with the solution does not support the capacity management function for ACL resources and FIB resources. Configuration blocking cannot be implemented based on ACL resources and FIB resources. |
Access the capacity management page
Navigate to the Automation > Branch Networks > Assurance > Capacities page. This page supports the following operations:
· View the usage of ACL, FIB, and memory resources on devices.
After a device is onboarded, the controller obtains the usage of ACL, IPv4 FIB, IPv6 FIB, and memory resources from that device, and then displays the usage information on the page.
Figure 304 Capacity management page
· Synchronize resource usage information from devices to the controller.
¡ To synchronize resource usage information from multiple devices in bulk to the controller, select those devices, and then click the Sync button.
¡ To synchronize resource usage information from a single device to the controller, click the Sync icon in the Actions column for that device.
Figure 305 Synchronizing resource usage information
· Set alarm thresholds on the percentage of remaining ACL, FIB, and memory resources.
¡ To set resource alarm thresholds for multiple devices in bulk, select those devices, and then click the Edit button.
After threshold modification, the controller deploys the following commands to the selected devices:
resource-monitor resource acl_rule cpu 0 by-percent minor-threshold 99 severe-threshold 98 //Command deployed after the ACL resource alarm threshold is changed.
resource-monitor resource ipv4fib cpu 0 by-percent minor-threshold 99 severe-threshold 98 //Command deployed after the IPv4 FIB resource alarm threshold is changed.
Table 9 Setting resource alarm thresholds for devices
¡ To set resource alarm thresholds for a single device, click the Edit icon in the Actions column for that device. The threshold change takes effect on all modules of the device. All modules will use the new alarm thresholds on ACL and FIB resources.
¡ To set resource alarm thresholds for a single module on a device, unfold the device entry, and then click the Edit icon in the Actions column for that module.
Figure 306 Setting resource alarm thresholds for a module
|
|
NOTE: · When the percentage of remaining ACL, FIB, or memory resources is lower than the alarm threshold, the system will generate an alarm message. · The controller supports deploying the alarm thresholds on ACL and FIB resources to devices. To have the memory resource alarm threshold take effect on a device, you must manually configure it on that device. · When you edit the resource alarm thresholds for a device that has multiple modules with different resource alarm thresholds, the Edit window does not display resource alarm thresholds for the device. |
· View detailed resource usage information.
To view detailed resource usage information of a device, click the Details icon in the Actions column for that device.
Figure 307 Viewing detailed resource usage information
Configure scheduled sync of resource usage information
After a device is onboarded, the controller synchronizes resource usage information from that device every 10 minutes. The default sync interval is 10 minutes. To edit the sync interval, click the Scheduled Synchronize button.
Figure 308 Editing the sync interval
Block deployment upon threshold violations
On the capacity management page, you can select whether to enable this feature.
By default, this feature is disabled on the controller. When a device violates a Level 1 or Level 2 resource alarm threshold, it generates a minor or major alarm message and the controller does not block configuration deployment to the device.
After this feature is enabled, the following rules apply:
· If a device violates the Level 2 ACL resource alarm threshold, the device generates a major alarm message for this event. In this situation, the controller only blocks deployment of ACLs and ACL rules to the device.
· If a device violates the Level 2 alarm threshold on IPv4 FIB, IPv6 FIB, or memory resources, the device generates a major alarm message for this event. In this situation, all configuration deployments to the device triggered by add or edit operations will fail, because resource insufficiency causes configuration deployment blocking.
Blocking deployment upon threshold violations
Restrictions and guidelines
· When the controller is deploying services, the service deployment status does not refresh automatically. To view the service deployment status, manually refresh it.
· The routing module does not automatically redeploy the configurations that the controller has failed to deploy. You must manually redeploy the configurations.
· During LAN network details creation, if you create a subinterface on an interface, make sure the other subinterfaces on the interface are created by the controller.
· You must install the LIS-VSR1000-AD license for VSR routers. For more information about requesting and installing licenses, see the related guides for VSR routers.
· On a dual-gateway site network, after you confirm deployment for a single device without confirming deployment for the other device, the system will automatically start service deployment. However, service deployment might fail on the device for which deployment is not confirmed. To resolve this issue, manually retry service deployment on the service deployment page.
· After a device is onboarded, the controller reads interface information from the device. If the controller deploys services to the device before the interface information reading finishes, the deployment might fail. If the deployment fails, perform the following operations:
a. Find the device on the Automation > Branch Networks > Physical Networks > Devices page.
b. Manually synchronize interface information from the device to the controller.
c. Re-deploy the related services.
· Before deploying VSR routers in a dual-gateway site network, make sure those routers do not use E1000 NICs. E1000 NICs cannot correctly forward GRE-encapsulated packets, causing the dual-gateway site network to malfunction.
· You can import up to 1000 routing policies or policy prefixes at a time. The excess routing policies or policy prefixes cannot be imported.
· When you configure a device, route-related configurations does not support pre-deployment. When you configure routes, you can only select interfaces that have been recognized or added through LAN/WAN. If route deployment fails, the system does not automatically retry deployment. In this situation, you must manually retry deployment.
· Device upgrade, configuration backup, device replacement, and configuration restoration cannot be simultaneously performed on a device. A device can perform only one maintenance task at a time.
O&M monitoring
For more information, see H3C AD-WAN Branch Solution 6.5 O&M and Deployment Guide.
