01-02 Design and Deployment Guide For The SD-WAN EVPN Interconnection Solution

CloudCampus Solution
Design and Deployment Guide for Multi-Campus 2 Design and Deployment Guide for the SD-WAN
Network Interconnection EVPN Interconnection Solution
2 Design and Deployment Guide for the

SD-WAN EVPN Interconnection Solution
2.1 Design and Deployment Process

2.2 Solution Design
2.3 Network Deployment
2.4 Deployment
2.5 Service Deployment
2.1 Design and Deployment Process

Logically, networks in the SD-WAN EVPN Interconnection Solution (EVPN
Interconnection Solution for short) can be divided into three layers from top to
bottom: service policy layer, logical network (overlay network) layer, and physical
network (underlay network) layer. During network design and deployment,
configure the physical network, deploy the logical network, and then deploy
service policies based on service requirements. You can refer to the design and
deployment process in the following figure to design and deploy the EVPN
Interconnection Solution.
Figure 2-1 Design and deployment process for the EVPN Interconnection Solution
Issue 02 (2021-10-10) Copyright © Huawei Technologies Co., Ltd. 13

NOTE
Before deploying a multi-campus network for an enterprise, you need to install iMaster
NCE-Campus and connect it to the network. For details about the design and deployment
of iMaster NCE-Campus, see the iMaster NCE-Campus installation guide. This document
describes the design and deployment of a multi-campus network for an enterprise.
2.2 Solution Design
2.2.1 Network Design
2.2.1.1 Network Model

Huawei EVPN Interconnection Solution uses the EVPN and IP tunneling
technologies to establish a logical network isolated from the carrier's physical
network. The physical network and logical network are the underlay and overlay
networks, respectively. Because user traffic is encapsulated in tunnels, only the
overlay network is involved in site interconnection. In this way, multiple WAN
service technologies can be flexibly applied, improving enterprise network
deployment efficiency and user experience.
To exchange overlay routes between sites, customer-premises equipment (CPE)

devices at sites need to establish routing neighbor relationships. Typically, an
enterprise has a large number of sites, and the number of neighbors of a CPE
cannot be estimated. To improve network scalability, route reflectors (RRs) are
introduced. RRs and CPEs at edge sites are managed by iMaster NCE-Campus. A
control channel is established between RRs and between an RR and edge site. RRs
work under the management of iMaster NCE-Campus and control the route
sending and receiving of edge sites based on the overlay network topology model.

In this way, sites can communicate with each other based on the planned overlay
topology model. Therefore, the EVPN Interconnection Solution involves two site
roles: RR site and edge site.
● CPE: AR device deployed at the egress of the campus network.

● RR site: A CPE functions as an RR and distributes EVPN routes to the CPE
gateway at the edge site based on the VPN topology policy.
● Edge site: The CPE is used as the edge router on the WAN side. A control
channel is established between the site and RR. The RR controls route
advertisement. Secure data channels are established between multiple sites. A
CPE at the edge site is the start or end of an EVPN tunnel and can be
considered as the border of an EVPN network.
NOTE
Whether a site is an edge site or an RR site depends on the device role configured when
egress CPEs are added to the site. If the role of the egress CPE is set to Gateway+RR, the
site is an RR site. If no device of the Gateway+RR role exists at the site, the site is an edge
site.
An edge site can establish IBGP peer relationships with two RRs. The two RRs back
up each other. Multiple RRs can be deployed under a tenant and are fully meshed
on the control plane. That is, a control channel is set up between any two RRs to
directly communicate with each other.
Data Planning and Design

Plan EVPN interconnection network models based on the scale and distribution of
enterprise sites, namely, the deployment relationship between the RR and edge
sites.
● RR site: Plan the edge sites that function as RR sites. Generally, stable edge
sites with high CPE performance and a large number of WAN links are used
as RR sites.
● Edge site: Plan the RR sites to which each edge site is connected. Generally,
edge sites are connected to RR sites that are physically close to the edge sites
and have good network connectivity. An edge site can connect to a maximum
of two RR sites, and a maximum of eight RR sites can be configured for a
tenant. If an edge site is not connected to any RR site, the edge site does not
participate in overlay networking and service deployment.
2.2.1.2 Global Configuration

Before establishing an EVPN interconnection network, you need to configure
global parameters of the network, including:
● Physical network: routing domain, transport network, IPSec encryption, device

activation security, link connectivity detection, traffic steering policy, default
management interface, and NTP parameters
● Virtual network: routes, address pools, and DNS

Routing domain

Configure a routing domain and determine whether to enable IPSec encryption for
the routing domain. The Internet and MPLS routing domains are provided by
default. If these routing domains cannot meet your requirements, create other
routing domains as required.
● Routing domain: A routing domain defines whether routes between different
transport networks are reachable. That is, physical links of different transport
networks that belong to the same routing domain are reachable to each
other. Generally, if the transport networks that are of the same type and are
provided by different carriers can communicate with each other, they are
defined in the same routing domain. For example, the Internet of carrier A
and that of carrier B can be defined in the same routing domain.
● Encryption: Configure whether to use IPSec to encrypt data transmitted over
tunnels. Generally, for network security purposes, encryption is required.
Transport Network
A transport network defines the information about the physical network between
the site and the WAN. The following lists the data to be planned for each
transport network. The defined transport network name can be directly referenced
when physical links are specified for site WAN links and policies.
● Transport network: The transport network defines the type of a physical link
on the WAN side of a site and is determined by the type of a WAN access
network provided by carriers. Generally, a type of network provided by a
carrier is defined as a transport network. For example, the Internet of carrier
A is defined as a transport network, and the Internet of carrier B is defined as
another transport network.
● Routing domain: Select the routing domain corresponding to each transport
network.
By default, the system provides the following transport networks: Internet,
Internet1, MPLS, and MPLS1. You can create other transport networks as needed.
IPSec Encryption Parameters
You need to set the following IPSec encryption parameters for a transport network
on which the encryption function is enabled:
● Protocol: Currently, only ESP is supported.
● Authentication algorithm: Select the authentication algorithm, which can be
SHA2-256 or SM3.
● Encryption algorithm: Specify the link encryption mode. The AES128, AES256,
and SM4 algorithms are supported. If the authentication algorithm is SM3,
the encryption algorithm can only be SM4. If the authentication algorithm is
SHA2-256, the AES256 encryption algorithm is recommended. This is because
the key length of AES256 is 256 bits, having a higher security level than
AES128.
● Life Time: Plan the global IPSec SA lifetime. The value is in the range from 60
to 43200, in minutes. When an IPSec SA is established through dynamic IKE
negotiation, you can configure the SA lifetime to update the SA in real time.
This reduces the risk of SA cracking and enhances security. When the IPSec SA
is about to expire, IPSec peers negotiate a new IPSec SA through IKE. After
the new IPSec SA is negotiated, the peers immediately use the new IPSec SA
to protect communication.

● IPSec SA generation mode: By default, the IPSec SA generation mode is

disabled. After the IPSec SA generation mode is enabled, you can select a DH
group (group 19, 20, or 21). The DH group key exchange mode cannot be
used at a dual-gateway site because the network may be disconnected and
EVPN channels may fail to be established. Therefore, do not enable the IPSec
SA generation mode if there are dual-gateway sites on the EVPN
interconnection network.
Device Activation Security Settings
● URL encryption key: Plan the key for encrypting the URL in the deployment
email and ZTP file. The key is a string of 6 to 12 digits and letters.
After the encryption key is set, you need to enter the correct encryption key
on the Portal page to perform email-based deployment for CPEs. Therefore,
the key must be correctly transmitted to deployment personnel before the
deployment.
● Validity period of the URL for email-based deployment: Plan the validity
period of the URL for email-based deployment, in days. The value is in the
range from 1 to 30, and is 7 by default.
When a CPE whose ESN is not recorded on iMaster NCE-Campus is deployed,
the system starts timing when sending a deployment email. After receiving
the CPE's registration information, iMaster NCE-Campus checks whether the
registration time of the CPE is in the validity period. If the registration time is
within the validity period, the CPE registers successfully. Otherwise, the
registration fails.
Link Failure Detection Parameter Configuration
After an overlay tunnel is established between two sites, the CPEs at both ends
automatically negotiate to be the master and slave devices. The master device
sends Keepalive packets, and the slave device replies with Keepalive packets to
detect and maintain the connectivity of the overlay tunnel. In this process, default
detection parameters are often used. If tenants have higher requirements on
overlay tunnel detection precision, you can modify the detection parameters.
● Interval for sending detection packets: The master device of an overlay tunnel
sends Keepalive packets at a specific interval. By default, the master device
sends a Keepalive packet at an interval of 1000 ms. The value range is from
10 to 2000, in milliseconds, and the value must be an integer multiple of 10.
● Number of detection failures: After sending a Keepalive packet, the master
device checks whether it receives a Keepalive packet from the slave device at
intervals. If the master device does not receive Keepalive packets from the
slave device for the consecutive number of times, the master device considers
the overlay tunnel faulty and sets the overlay tunnel status to Down. By
default, the number of detection failures is 6. The value range is from 3 to 10.
● Detection packet priority: The default priority of Keepalive packets is 7, and
the value range is from 0 to 7.
Traffic Steering Policy Configuration
● Switchover period: At a site where an intelligent traffic steering policy is
applied, when the system detects that the link quality does not meet service
requirements, the system does not perform a link switchover immediately.
Instead, the system performs a link switchover only when a switchover period

elapses and the link quality still does not meet service requirements. The
value range is from 1 to 65535, in seconds. The default value is 5.
● Statistics period: This parameter specifies the interval for checking the link
quality. The value is in the range from 1 to 65535 and must be less than or
equal to the switchover period.
● Flapping suppression period: Unstable network link quality may result in
frequent link switchovers at the sites where an intelligent traffic steering
policy is applied. To prevent this situation, the system requires that services be
transmitted on a new link for at least one flapping suppression period before
the services are switched back from the new link to the original link. The
value range is from 2 to 131070, and the default value is 30 seconds. The
value must be at least twice the switchover period.
● Maximum bandwidth utilization: This parameter is used for load balancing-
based intelligent traffic steering. If the service traffic of a link reaches the
maximum bandwidth utilization, traffic can be load balanced. The default
maximum bandwidth usage is 95%, and the value range is from 50% to
100%.
● Symmetric routing: In load balancing scenarios, the service receiving site
forwards services based on the route selection result of the sending site,
without proactively selecting a route. Symmetric routing is enabled by default.
Tenants can disable symmetric routing. After symmetric routing is disabled,
devices at both ends select routes based on route selection rules.
NTP
You can centrally configure NTP for all sites, which is disabled by default.
Routing
An overlay network is established between sites through EVPN tunnels. Routes on
the overlay network between sites use BGP to establish the IBGP peer relationship.
By default, the BGP AS number of a site is 65001, which can be modified.
● Routing protocol: Only BGP is supported.
● AS number: The default value is 65001. Generally, you do not need to change
the value. If the default value cannot be used due to reasons such as a
conflict with the BGP AS number planned for an existing device on the
network, use another value in the range from 1 to 65534. A value in the
range from 64512 to 65534 is recommended.
● Community attribute pool: A community pool is a resource management pool
where community attributes are configured. Currently, it is mainly used for
WAN IBGP, RR management, Internet access, mutual communication, area
management, and multi-tenant IWG.
● Dual-gateway interconnection protocol: For a dual-gateway site, the two CPEs
need to exchange routing information through a routing protocol, which can
be OSPF or IBGP.
IPv4 Pool
When iMaster NCE-Campus automatically orchestrates services such as overlay
tunnels, overlay WAN routes, and site Internet access, IP addresses need to be
allocated. Plan address pools based on the network scale. The number of required
addresses increases with the number of sites. For details about the relationship
between them, click Details.

The addresses to be configured include tunnel interface IP addresses, interworking

tunnel IP addresses, CPE IP addresses, and interface addresses of an interlink
between dual gateways.
After you enter a reserved address, iMaster NCE-Campus automatically allocates
an address segment based on the following rules:
You can configure one or more address pools. Addresses in the address pools are
automatically divided into multiple segments, which can be used by the following
interfaces:
● Loopback interface of the CPE
● Interworking tunnel interface
● Interlink interface between two gateways
● Tunnel interface
In EVPN mode, address pools can be configured in simple or advanced mode. In
simple mode, IP addresses are assigned from the same address pool. In advanced
mode, IP addresses can be assigned by setting IP pool, Interworking Tunnel, or
Interlink.
Address pool: Configure the mask length of the address pool according to the site
quantity listed in Table 2-1. The mask length determines the number of addresses
in the address pool.
For example, if the number of sites of a tenant is 150, the recommended mask
length is 19. If the planned address segment is 20.20.0.0, the address pool can be
set to 20.20.0.0/19. Ensure that the planned address segment does not conflict
with the planned public network segment and private network segment on the
tenant network.
Table 2-1 Mapping between the mask length and the network scale
Network Scale/Number of Sites Recommended Configuration (Single
Network Segment)
2-10 /23
11-30 /22
31-60 /21
61-120 /20
121-250 /19
251-500 /18
501-1000 /17
1000+ /16
DNS Server
Plan a DNS server used for network access. If the DNS servers used by multiple
sites are different, you can group these DNS servers. When configuring LAN

services on the overlay network, you can reference different DNS server group
names to specify the DNS servers used for network access.
● DNS server group name: Plan the DNS server group and specify the group
name, for example, DNS_Server1.
● DNS server IP address: Plan the IP addresses of the DNS servers in each group.
Port Configuration
● DTLS server port: A CPE registers with the RR through DTLS. The default DTLS
server port is 55100. You can change the port number to a value in the range
from 10000 to 65535.
● STUN server port: CPEs support Session Traversal Utilities for NAT (STUN),
and can communicate with the RR traversing NAT devices. When the RR
functions as the STUN server, the default STUN server port is 3478. You can
change the port number to a value in the range from 1024 to 65535.
● Connection Source Port: If there are special requirements for the source port
of the STUN client, you can set Scanning Start Port, Scanning Times, and
Scanning Increment to specify the source port.
2.2.1.3 Site Model
2.2.1.3.1 Site WAN Model
Site WAN Model Planning

During site planning, in addition to the planning of site roles mentioned in the
network model section, you also need to plan the site WAN model from the
following aspects to enhance network reliability:
● Network device redundancy
To enhance reliability, two egress routers in active-active mode are deployed
at a site. Each device controls different WAN links and provides WAN
connection services for each other.
● Network link redundancy
To improve the reliability of egress links, multiple network connection lines
are usually provided, that is, one active link and one standby link are used.
This design is simple and reliable. The standby link is usually in the backup
state and does not forward network traffic. Therefore, enterprise customers
need to pay extra line fees for reliability.
The EVPN Interconnection Solution provides link backup. In this solution,
multiple uplinks of a network site are active at the same time and services
can be load balanced among the links according to the preconfigured traffic
scheduling policy. If a link is faulty, the link fault or quality deterioration can
be detected within sub-seconds. In this manner, services can be switched from
the faulty link to an operational link. This mechanism ensures line reliability
and makes full use of enterprise access lines to provide high access bandwidth
and facilitate interconnection between enterprise sites.
– Device connecting to all egress links in full-mesh mode
Each device maintains its own egress link connection information. When
a fault occurs on an egress link, the device switches service traffic to

another egress link. This solution offers high reliability but requires more
egress links, resulting in high deployment costs.
– Device connecting to only one egress link
Each device has only one egress link and connects to another device
through the interlink. A device monitors the egress network connected to
it and notifies the other device of the monitoring result. When a fault
occurs on an egress link, the device notifies the other device. The other
device then adjusts packet forwarding policies based on the link status,
preventing traffic from being sent to the faulty uplink. This solution
provides basic egress link reliability at low deployment costs and is
recommended for small- and medium-sized campus networks.
WAN links are the basis for building an EVPN interconnection network. To prevent
repeated configuration of parameters for each site, configuration information such
as the number of gateways and WAN-side links is abstracted into a WAN link
template. The site WAN model is configured through the WAN link template.
Therefore, after creating sites, you need to plan a WAN link template for each site.
If multiple sites have the same WAN-side configurations, including the gateway
type, WAN link, and interconnection link between two gateways, the same WAN
link template can be used.
Table 2-2 lists the default WAN link templates provided by iMaster NCE-Campus.
If the default WAN link templates can meet your requirements, skip this step.
Otherwise, customize a WAN link template based on the site requirements. A
maximum of 10 WAN links can be configured for a single gateway, and a
maximum of 20 WAN links can be configured for dual gateways.
Table 2-2 Default link templates provided by iMaster NCE-Campus

Templ Templa WAN Link (Device, Inter-CPE Topology
ate te Port, Transport Link
Name Descrip Network) (Device,
tion Port)
Single Single Internet (Device1, -

_gate gateway GE0/0/0, Internet)
way_ with an MPLS (Device1,
mixed Internet GE0/0/1, MPLS)
_links link and
an
MPLS
link

Templ Templa WAN Link (Device, Inter-CPE Topology

ate te Port, Transport Link
Name Descrip Network) (Device,
tion Port)
Single Single MPLS (Device1, -

_gate gateway GE0/0/0, MPLS)
way_ with an
mpls_l MPLS
ink link
Single Single Internet (Device1, -

way_in with an
ternet Internet
_link link
Single Single Internet1 (Device1, -

way_d with Internet2 (Device1,
ual_int dual GE0/0/1, Internet)
ernet_l Internet
inks links
Dual_ Dual Internet (Device1, Device1:

gatew gateway GE0/0/0, Internet) GE0/0/1,
ays_mi s with MPLS (Device2, Device2:
xed_li an GE0/0/0, MPLS) GE0/0/1
nks MPLS
link and
an
Internet
link
respecti
vely

Site
Plan data for each site.
● Site name: The site name is a string of 1 to 64 characters, for example, Site1.
● Device type: Add device types to the site. You can only add device types but
cannot replace device types.

● Basic information such as the site location

Enter the site address information to facilitate subsequent network
management and maintenance.
● Device information
Plan information about devices to be deployed at the site.
– Number of devices: Plan the number of devices at each site, and deploy a
single or dual gateways at each site.
– Device model: Plan the device model. The two CPEs deployed at a dual-
gateway site must be of the same model.
– Device role: When adding a device, specify the device role. Configure roles
for devices based on the site requirements. For example, if a site needs to
function as an RR site, set the role of the CPE deployed at the egress to
Gateway+RR.
– Device name: To facilitate management and memorization, name the
devices at each site. For example, set the names of the two gateways at
Site1 to Site1_1 and Site1_2, respectively.
– ESN: If ESNs have been obtained, allocate the ESNs in the data planning
table. The device information must be consistent with that imported to
iMaster NCE-Campus and that at the site.
WAN link template
● Template name
The template name is a string of 1 to 64 characters.
● Gateway type at a site
A single gateway or dual gateways can be deployed at a specified site. For
sites with high reliability requirements, dual gateways can be deployed. If the
gateway service traffic is small and low requirements are imposed on
reliability, a single gateway can be deployed.
● Multiple sub-interfaces
Specify whether to enable multiple sub-interfaces on the device. After this
function is enabled, a maximum of 10 sub-interfaces can be created for a
single gateway, and a maximum of 20 sub-interfaces can be created for dual
gateways.
● WAN link at a site
– WAN link name: After specifying the gateway type, plan the number of
WAN links and specify a name for each link. The name can contain
information such as the network type and network provider.
– Device and interface: Specify the gateway and interface to which each
WAN link connects.
– Sub-interface: Specify whether to enable the sub-interface of the device.
– Overlay tunnel: Specify whether to enable the overlay tunnel function. If
this function is enabled, an overlay tunnel is created on the WAN link.
– Number: Specify the sub-interface number. This parameter is available
only after Sub-interface is enabled.
– Transport network: Specify the WAN-side network to be connected, which
depends on the transport network created in Global Configuration. For

details about the transport network data planning in global

configuration, see Transport Network in the Data Planning and Design.
– Role: When multiple WAN links are configured for a single gateway,
specify a WAN link as the primary or secondary link. At least one primary
link must be configured.
– iMaster NCE Southbound interface service: Specify the IP address that
iMaster NCE-Campus provides for CPEs deployed at a site to access.
During the installation, a southbound IP address is configured for CPEs to
communicate with iMaster NCE-Campus. If iMaster NCE-Campus and
some sites are on the same network while other sites are on another
network, two southbound IP addresses need to be configured for sites on
different networks to access iMaster NCE-Campus. As shown in the
following figure, iMaster NCE-Campus and site 1 are on the private
network, and site 2 is on the public network. iMaster NCE-Campus needs
to access the public network through the NAT device. Site 2 can
communicate only with a NATed public IP address. During iMaster NCE-
Campus installation, two southbound IP addresses need to be configured:
one is a private IP address, and the other is a NATed public IP address.
When configuring WAN links for site 1, specify the private IP address as
the southbound IP address of iMaster NCE-Campus. When configuring
WAN links for site 2, specify the post-NAT public IP address as the
southbound IP address of iMaster NCE-Campus.
● Interfaces connecting the two gateways

For a dual-gateway site, configure a Layer 3 or Layer 2 link to connect the
two CPEs. By default, a Layer 3 link is used. You need to specify the VLAN ID
for interconnection between two devices. For a Layer 3 link, the two devices
communicate with each other through Layer 3 sub-interfaces. For a Layer 2
link, the two devices communicate with each other through VLANIF
interfaces.
– Layer 3 link

▪ Single link: Specify the interfaces for interconnecting with each other
on the CPEs.
▪ Eth-Trunk: Specify two interfaces for interconnecting with each other

on the CPEs. The system automatically bundles the two interfaces
into an Eth-Trunk.
– Layer 2 link
▪ Layer 2 direct link: Similar to the situations of Layer 3 links, if only

one interface on each device is specified, the two devices are
connected through a single link; if two interfaces on each device are
specified, the system automatically bundles the two interfaces into
an Eth-Trunk to form a dual-link connection.
▪ LAN-side Layer 2 links: If a Layer 2 link is available between a CPE

and the LAN switch and no independent link is planned for the CPEs,
you can specify a VLAN ID so that two devices communicate with
each other through VLANIF interfaces and the LAN-side Layer 2 link
is used as the data forwarding channel between the CPEs. Data
between CPEs and the data from the LAN side to the CPE are
isolated through VLANs without affecting each other.
WAN link parameter configuration (ZTP)
After planning the model and network of a site, you need to plan the WAN link
parameters of the site and connect the site to the WAN network before
establishing the overlay network and configuring services. The WAN interface on
the CPE used by the site and the WAN link to be connected have been specified in
the WAN link template. This section describes how to plan the IP address and
interface parameters of the WAN interface. You must configure WAN links before
deploying a site.

● ZTP mode: The URL-, USB-, and DHCP-based deployment modes are
supported. The system selects an orchestration scheme based on the
deployment mode.
– During URL- or USB-based deployment, iMaster NCE-Campus generates a
deployment file and sends information such as IP address and VPN
information of WAN interfaces to the CPEs through the deployment file.
After a CPE registers with iMaster NCE-Campus, iMaster NCE-Campus
delivers information such as the public IP address and interface rate to
the CPE.
– During DHCP-based deployment, iMaster NCE-Campus does not need to
generate a deployment file. After a CPE registers with iMaster NCE-
Campus, iMaster NCE-Campus needs to re-deliver the IP address and VPN
information of WAN interfaces to the CPE.
● Link name: Specify the name of the current WAN link. If a WAN link is created
using the default WAN link template, the link name is Internet or MPLS. If a
WAN link is created using a customized WAN link template, the link name is
the one specified when the WAN link template is created.
● Transport network: type of the transport network to which the WAN link
belongs.
● Device: device where the WAN link resides.
● Interface: type and number of a physical interface or virtual interface used by
the current link. If iMaster NCE-Campus is deployed on the LAN side of a DC,
multiple physical interfaces and one virtual interface can be configured. The
physical interfaces are used to connect iMaster NCE-Campus to sites, and the
virtual interface is used to transmit overlay traffic. The VN instance of the
physical interfaces must be the same as that of the virtual interface.
NOTE
1. Ensure that the physical interfaces are Layer 3 interfaces. If an interface is not a
Layer 3 interface, switch the interface to a Layer 3 interface. Otherwise, the
configuration fails to be delivered.
2. If a virtual interface is configured, the overlay tunnel cannot be enabled for the
physical interface links in the same underlay VN as the virtual interface.
3. If a loopback interface is configured as the WAN link interface type, the bandwidth
trend of the overlay traffic links inside a site and between sites and the application
bandwidth usage trend are displayed as 0. This is because the uplink and downlink
bandwidths of the loopback interface cannot be set.
4. If the interface type of links is E1-IMA (ATM), Ima-group, or Serial, ZTP is not
supported, and the deployment can be performed only on the CLI.
● Sub-interface: whether to use a sub-interface. Currently, only dot1q sub-
interfaces are supported.
● Interface description
You can centrally plan the WAN links of a site and describe the CPE and site
to which the interface belongs. The deployment email can contain the
interface description so that deployment personnel can determine whether
the site is the same as the planned site based on the interface description
during deployment.
● NAT traversal
If a NAT device is deployed between the site on a private network and the
WAN side, enable the NAT traversal function to set up overlay tunnels with
other sites and RRs.

● Public IP address (This parameter needs to be set only for RR sites.)

This address is used by the edge site to access the RR.
● Uplink and downlink bandwidths of the interface
The uplink and downlink bandwidths of an interface are configured based on
the actual requirements. The unit is Mbit/s. If the configured value is less than
the actual bandwidth, packet loss occurs when the outgoing traffic exceeds
the configured value, affecting services.
● URL-based deployment
Specify whether to enable URL-based deployment for the current link. This
configuration item is available only when Select ZTP mode is set to URL/U
Disk. A maximum of three links are available for URL-based deployment on
each device. For a site that uses the URL-based deployment mode, at least
one link must be selected for URL-based deployment on a single gateway.
– If this function is enabled, the interface parameter settings are loaded to
the device through URL-based deployment.
– If this function is disabled, interface parameter settings are delivered to
devices through NETCONF.
● Link in email-based deployment
This parameter needs to be set only when URL-based deployment is enabled.
After this function is enabled, the primary IP address of the southbound
access service of iMaster NCE-Campus on the link is used as the southbound
IP address in the deployment email for the device to go online. If the
southbound access services of multiple links are different, email-based
deployment can be enabled for only one link. That is, only the primary IP
address of the southbound access service of one link can be used for
deployment.
● iMaster NCE-Campus southbound access service
Specify the IP address of the iMaster NCE-Campus southbound access service.
By default, the default southbound access service is used. If the system
administrator has enabled other southbound access services, other
customized access services can be selected for WAN links. The southbound
access service cannot be changed after deployment.
● Link ID
You can plan a unique ID for each link in an EVPN interconnection network.
This helps you query link information by ID during maintenance.
WAN interface attributes (WAN underlay)
When a CPE is interconnected with a network device on the WAN side, you need
to plan the interconnection mode and configuration of the physical interface.
● Link name: The link name of a WAN interface is specified when a WAN-side
link is created in the WAN link template.
● Interface negotiation mode: You need to pay attention to the negotiation
mode only for Ethernet interfaces.
– Auto-negotiation: The interface rate and duplex mode are determined
through negotiation with the peer interface.
– Non-auto-negotiation: In non-auto-negotiation mode, you can set the
working mode, duplex mode, and rate of the interface according to the
actual interface status.

● MTU: By default, the MTU of a serial interface is 1488 bytes, and the MTU of
Ethernet links, LTE links, xDSL links, E1-IMA links, G.SHDSL links, and IMA
group links is 1500 bytes. Adjust the MTU based on the link type. For
example, for a PPPoE link, set the MTU to 1492 because the PPPoE header is
added before the IP packet.
When the CPE forwards data packets, the data packet length and MTU are
compared at the IP layer. If a data packet is longer than the MTU, the data
packet needs to be fragmented at the IP layer. After fragmentation, the
packet length is shorter than the MTU. If the MTU is too small, the
transmission efficiency decreases due to a large number of fragments. If the
MTU is too large, packets on the network may be discarded.
● MSS: The default value is 1200. To prevent TCP packets from being
fragmented, you must configure a proper MSS based on the MTU. To properly
transmit a packet, ensure that the MSS value plus all the header lengths (TCP
header and IP header) does not exceed the MTU. For example, the default
MTU of an Ethernet interface is 1500 bytes. To prevent packets from being
fragmented, set the MSS to a value equal to or smaller than 1460 bytes (1500
- 20 - 20). In the preceding formula, the two 20s indicate the minimum length
of the TCP header and IP header, respectively. It is recommended that you set
the MSS to 1200 bytes.
2.2.1.3.2 Site LAN Model

The LAN-side model design adapts to the current LAN-side network. Huawei EVPN
Interconnection Solution can connect to the LAN at Layer 2 or Layer 3, which
depends on the actual network deployment.
Layer 2 Interconnection Scenario
Figure 2-2 Layer 2 interconnection on the LAN side
1. Single CPE: The CPE connects to STAs through Wi-Fi.

2. Single CPE: The CPE connects to an AP.
3. Single CPE: The CPE directly connects to a Layer 2 switch.
4. Dual CPEs: Dual CPEs running VRRP are connected to a single Layer 2 switch
or multiple switches that form a stack.
If only one CPE is deployed, the LAN connection is simple. For a small site (for
example, SOHO), the LAN-side interface can directly connect to terminals at the

site. If the CPE has insufficient LAN-side interfaces, an access switch can be
connected to the CPE in VLAN trunk mode.
If dual CPEs are deployed, VRRP is generally deployed on the CPEs to prevent
them from affecting the LAN. The VRRP virtual IP address is used as the gateway
address of the network to transparently provide the redundancy function. Multiple
switches can be deployed on the LAN side to form a stack. If two CPEs are
deployed at a site, they can be interconnected directly or through the LAN. If the
two CPEs are directly interconnected, the interconnection links can be added to an
Eth-Trunk.
In VRRP redundancy mode, the master device forwards service packets. However,
in the actual environment, service packets may need to be transmitted through
the link on the backup device. In this case, the master device needs to forward
service packets to the backup device first. Therefore, an interconnection link needs
to be set up between the master and backup devices to forward service packets
between them.
Layer 3 Interconnection Scenario
For a large site, the site network has a complex structure and complex network
facilities (for example, Layer 3 core devices). Therefore, the egress routers must
support the direct connection and dual-homing networking for interconnecting
with Layer 3 devices. BGP, OSPF, and static routing are supported.
NOTE
Currently, only firewalls support static routing.
Figure 2-3 Layer 3 interconnection on the LAN side
In the Layer 3 interconnection scenario, if only one gateway is deployed, only a

routing protocol needs to be configured on the LAN side based on requirements of
LAN-side devices. Layer 3 interconnection on the LAN side supports only
interconnection with a standalone device or a stack. Therefore, when multiple
devices need to be interconnected, you need to set up a stack of these devices
first.

Wired network deployed on the LAN side

If multiple VNs are planned for service isolation between departments, you need
to plan LAN-side configurations for sites in each VN and use Layer 3 interfaces or
VLANs to connect to LAN-side devices. The same Layer 3 interface, Layer 3 sub-
interface, or VLAN cannot be configured for the same site in different VNs. That is,
you need to plan different Layer 3 interfaces, Layer 3 sub-interfaces, or VLANs for
different VNs when planning configurations for sites to interconnect with LAN
devices in different VNs.
WAN-side gateway:
● Site name: Specify the name of the site where the LAN-side device is to be
interconnected.
● Gateway: Specify the CPE to be configured at a site, especially at a site where
two CPEs are deployed.
● Interconnection with the LAN side through Layer 3 interfaces or sub-interfaces
– Interface: Specify the interface on the CPE for connecting to the LAN-side
device. Ensure that the interface is a Layer 3 interface.
If an Eth-Trunk is used, you need to plan the following items:
▪ Eth-Trunk ID: The Eth-Trunk ID is in the range from 0 to 63. In a

dual-gateway scenario, if the two gateways are connected through
two Layer 3 physical links, the system automatically creates the Eth-
Trunk 0 interface for the two gateways. You cannot create an Eth-
Trunk interface with ID 0 on the two gateways.
▪ Eth-Trunk type: The planned interface type is Layer 3 interface.
▪ Physical interfaces: Plan the Eth-Trunk member interfaces for

connecting to the LAN side. A maximum of eight member interfaces
can be added. The Eth-Trunk member interfaces must be Layer 3
physical interfaces.
– VLAN ID of the sub-interface: If a sub-interface is used to connect to a
LAN-side device, plan a VLAN ID for the sub-interface. A Dot1q sub-
interface is created on the interface, and the terminated VLAN tag is the
VLAN ID. The VLAN ID must be the same as the VLAN tag configured on
the interconnected device.
● Interconnection with the LAN side through Layer 2 interfaces
– VLAN ID: Plan the VLAN ID used for Layer 2 communication between the
LAN and WAN at a site.
The system automatically creates VLANIF interfaces based on VLAN IDs.
For a dual-gateway site, if the CPE is directly connected to a Layer 2
switch in the downstream direction, to implement the VRRP function on
the LAN side, the two CPEs must use the VLANIF interface with the same
VLAN ID to communicate with the LAN side.
– Physical interface: Specify the interface on the CPE for connecting to the
LAN-side device. Ensure that the interface is a Layer 2 interface.
▪ Eth-Trunk ID: The Eth-Trunk ID is in the range from 0 to 63. In a

dual-gateway scenario, if the two gateways are connected through
two Layer 3 physical links, the system automatically creates the Eth-

Trunk 0 interface for the two gateways. You cannot create an Eth-
Trunk interface with ID 0 on the two gateways.
▪ Eth-Trunk type: The planned interface type is Layer 2 interface.
▪ Physical interfaces: Plan the Eth-Trunk member interfaces for

connecting to the LAN side. A maximum of eight member interfaces
can be added. The Eth-Trunk member interfaces must be Layer 2
● IP address: Plan the IP address of the interface. The IP address is configured
on the specified Layer 3 interface, sub-interface, or VLANIF interface. The
local IP address must be in the same network segment as the IP address of
the LAN side.
● Trust mode: Plan the type of a firewall security domain to which the interface
is added. You can add an interface to the trust or untrust zone of the firewall.
The trust mode takes effect only when the firewall is enabled with the
security policy. Generally, LAN-side interfaces are trusted because the LAN
side is the internal network of the site. If the LAN side is connected to a
network with poor security, you can set the trust mode to Untrust and
configure the interzone policy on the firewall to enhance service security.
● Secondary IP address: Generally, one interface only needs one primary IP
address. In some special cases, one interface needs additional secondary IP
addresses. For example, a CPE connects to a physical network through an
interface, and hosts on this network belong to two network segments. To
enable the CPE to communicate with all hosts on the physical network,
configure a primary IP address and a secondary IP address for this interface.
Each Layer 3 interface can be configured with one primary IP address and a
maximum of 31 secondary IP addresses.
● DHCP: Plan whether to enable the DHCP function on the device to
automatically assign IP addresses to clients on the LAN side. If DHCP is
enabled, you need to plan the following items:
– DHCP type: Select the DHCP server or DHCP relay agent to be used. If the
gateway of each site manages the IP addresses of clients on the LAN side,
use the DHCP server. If a dedicated DHCP server is planned to centrally
manage the IP addresses of clients on the LAN side of each site, use the
DHCP relay agent.
– DHCP server: If the DHCP server mode is selected, the DHCP server
function is enabled on the interface. The IP address pool uses the
interface IP address as the egress gateway address, and an IP address
segment can be assigned as the network segment where the interface IP
address resides. In DHCP server mode, you can also plan the following
data, which is optional:
▪ Exclude IP: Specify the address or address segment that is not

allowed to be assigned by the DHCP server. For example, some
addresses are already occupied by terminals and cannot be allocated
to other DHCP clients. These addresses can be included in the
excluded IP address list.
▪ Domain name: Plan the domain name suffix sent from the DHCP
server to the DHCP client.

▪ Lease time: By default, the lease time is one day. In locations where
clients often move and stay online for a short period of time, for
example, in cafes, Internet bars, and airports, plan a short lease time
to ensure that IP addresses are released quickly after the clients go
offline. In locations where clients seldom move and stay online for a
long period of time, for example, in office areas of an enterprise,
plan a long lease time to prevent system resources from being
occupied by frequent lease or address renewals.
▪ DNS server: Specify the DNS server group name to plan the DNS
server used by the DHCP client. The DNS server group is planned in
Global Parameters. For details, see the description of the DNS server
in "Data Planning and Design" in 2.2.1.2 Global Configuration.
After the DNS server group name is specified, the DHCP server sends
the IP addresses in the specified DNS server group to DHCP clients
when assigning IP addresses to the DHCP clients.
▪ NetBIOS node type (Option 46): Plan the NetBIOS node type for
DHCP clients. The options include: B-Node (node in broadcast
mode), P-Node (node in peer-to-peer mode), M-Node (node in
mixed mode), and H-Node (node in hybrid mode).
▪ NetBIOS server (Option 44): Plan the NetBIOS server address for
DHCP clients.
▪ Cloud platform address (DHCP Option 148): If LAN-side devices use

the egress AR as the gateway and the DHCP-based deployment
mode is used, enable the DHCP server on the egress AR and set the
DHCP Option 148 field.
▪ TFTP server (Option 150): When a TFTP server is planned on the

network, configure the TFTP server address on the DHCP server.
When a DHCP client requests an IP address, the DHCP server also
sends the TFTP server address to the DHCP client.
▪ Voice option (Option 184): Configure the network call handler IP

address, backup network call handler IP address, failover IP address,
and voice VLAN ID so that the DHCP server can send voice
parameters to IP phones connected to a CPE.
▪ Static binding: Plan IP addresses for DHCP clients that need to use
fixed IP addresses. For example, if a server functions as a DHCP client
to apply for an IP address from the DHCP server and needs to use a
fixed IP address to ensure stability, select an IP address from the
address pool and bind the IP address to the MAC address of the
server. The DHCP server then assigns a fixed IP address to the server
based on the MAC address.
– DHCP relay agent: If the DHCP relay agent mode is selected, plan the
DHCP server address for the DHCP relay agent. You can specify a
maximum of eight DHCP servers.
● VRRP: If two gateways are deployed at a site, VRRP can be configured. LAN
users access the WAN network through the master device by default. When
the master device fails, services are automatically switched to the backup

device. In this manner, redundancy is implemented between gateways to

enhance reliability.
– VRRP ID: Plan the VRRP ID, which is in the range from 1 to 255. The same
VRRP ID must be specified for the two gateways.
– Virtual IP address: Plan the virtual IP address of the VRRP group. The
virtual IP address must be in the same network segment as the gateway
interface address. It can be the same as the gateway interface address
but cannot be the same as the user host IP address. Otherwise, packets
from the local network segment will be sent to the user host. As a result,
data on the local network segment cannot be correctly forwarded.
– Default role: Specify the master gateway and backup gateway in the
dual-gateway scenario.
– Preemption delay: Specify the VRRP preemption delay. The value is in the
range from 0 to 3600, in seconds. The default value is 0. For the two
devices in a VRRP group, you are advised to set the preemption delay to 0
for the backup device and to 15 seconds or a larger value for the master
device. If the preceding settings are not used, two masters may coexist
and user devices may learn an incorrect master address, interrupting
traffic.
● ARP proxy: Configure whether to enable the ARP proxy. Only the routed ARP
proxy is supported.
The routed ARP proxy enables network devices on the same network segment
but on different physical networks to communicate.
As shown in the figure below, the IP addresses of Host_1 and Host_2 are
172.16.1.10/16 and 172.16.2.20/16, respectively, which are on the same
network segment. The CPE connects to two networks through VLAN 10 and
VLAN 20. The IP addresses of VLANIF10 and VLANIF20 are on different
network segments.
When Host_1 needs to communicate with Host_2, Host_1 broadcasts an ARP

Request packet, requesting the MAC address of Host_2. However, Host_1 and
Host_2 are on different physical networks (in different broadcast domains).
Host_2 cannot receive the ARP Request packet sent from Host_1 and
therefore cannot respond with an ARP Reply packet. If the routed ARP proxy is
enabled, the CPE queries the routing table after receiving the ARP Request
packet. Host_2 is directly connected to the CPE, so the CPE has the routing
entry of Host_2. The CPE then uses its MAC address to send an ARP Reply
packet to Host_1. Host_1 forwards data based on the MAC address of the
CPE. In this case, the CPE functions as the proxy of Host_2. The MAC address

corresponding to Host_2's IP address in the ARP table of Host_1 is the MAC

address of VLANIF10 on the CPE.
● MTU: The default value is 1500. Adjust the MTU based on the link type.
When the CPE forwards data packets, the data packet length and MTU are
compared at the IP layer. If a data packet is longer than the MTU, the data
packet needs to be fragmented at the IP layer. After fragmentation, the
packet length is shorter than the MTU. If the MTU is too small, the
transmission efficiency decreases due to a large number of fragments. If the
MTU is too large, packets on the network may be discarded.
● MSS: The default value is 1200. To prevent TCP packets from being
fragmented, you must configure a proper MSS based on the MTU. To properly
transmit a packet, ensure that the MSS value plus all the header lengths (TCP
header and IP header) does not exceed the MTU. For example, the default
MTU of an Ethernet interface is 1500 bytes. To prevent packets from being
fragmented, set the MSS to a value equal to or smaller than 1460 bytes (1500
- 20 - 20). In the preceding formula, the two 20s indicate the minimum length
of the TCP header and IP header, respectively. It is recommended that you set
the MSS to 1200 bytes.
Core device on the LAN side:
● Core: Specify the core device on the LAN side of a site.

● Gateway interface: This parameter has a fixed value of L2.
● VLAN ID: Plan the VLAN ID used for Layer 2 communication between the LAN
and WAN at a site.
● Physical ports: Plan the interface on the core device for connecting to the
WAN-side CPE.
● IP address: Plan the IP address of the interface. The IP address is configured
on the specified VLANIF interface. This IP address must be in the same
network segment as the IP address of the WAN side.
WLAN deployed on the LAN side
If the WLAN is deployed on the LAN side, STAs connect to the WLAN Fat AP-
capable CPE to access the network.
Table 2-3 lists the items for configuring the WLAN Fat AP function on the CPE.
Table 2-3 Items for configuring the WLAN Fat AP function on the CPE
Configur Description
ation
Item
VN If multiple VNs are configured, select a VN and plan the WLAN Fat
AP configurations for the sites in the VN.
Site Plan the site for which WLAN is to be configured.
Device Plan this item only when the device supports the WLAN Fat AP
function.

ation
Item
SSID Plan the service set identifier (SSID). SSIDs in different VNs must be
unique.
Frequenc Plan the frequency band, which can be 2.4 GHz or 5 GHz.
y band If 2.4 GHz is used, the transmit power level and channel can be
configured.
● Transmit power level: Transmit power levels 0 to 12 are available.
The configured transmit power level must be supported by radios,
which is subject to the laws and regulations and channels of the
corresponding country or region.
● Channel: Channels 1 to 13 are available.
The available channels and the maximum transmit power of radio
signals in the channels vary according to countries and regions.
Radio signals in different channels may have different signal
strengths. For details about the country codes and channels
compliance table, maximum transmit power of each channel,
channel number, and mapping between channels and frequencies,
search for "Country Codes & Channels Compliance" at Huawei
enterprise technical support website https://support.huawei.com/
enterprise. In the search result, N/A indicates that the
corresponding channel is not supported by a country or region.
VLAN ID Configure the service VLAN ID. WLAN service packets are
encapsulated with the VLAN ID and forwarded to the WLAN service
processing module of the CPE VLAN IDs in different VNs must be
unique and cannot conflict with those that have been configured.
Interface Configure the IP address of an interface.

IP The IP address cannot conflict with the IP addresses of other
Address interfaces on the device or other devices on the network.
NOTE
The specified IP address cannot be reserved in the global address pool.
Encryptio WPA1: Configure WPA1 authentication.

n mode WPA2: Configure WPA2 authentication.
PSK Configure the shared key for PSK authentication.
DHCP Configure whether to enable DHCP on the device to assign IP

addresses to downstream devices. For details about how to
configure the DHCP function, see DHCP in "Wired network deployed
on the LAN side".
Security STAs that access the wireless network can be authenticated using
authenti two modes: WPA1+PSK and WPA2+PSK. Select WPA1 or WPA2 based
cation on the security requirements and terminal encryption support, and
plan the PSK.

ation
Item
Hide Specify whether to hide an SSID.

SSID
Maximu Set the maximum number of STAs that can access the CPE through
m the WLAN Fat AP concurrently.
number
of access
STAs
Uplink Configure the upstream and downstream bandwidth limits to

and implement traffic policing for the upstream and downstream traffic
downlink of each STA connected to a CPE.
traffic
(kbit/s)
Transmit Configure the power level for a radio. A larger value indicates a
power higher power level and a lower transmit power of a radio. The
level default value is 0, indicating full power. This parameter is valid only
when the frequency band is set to 2.4 GHz.
Channel Specify the working channel for a radio. The channel is selected
based on the country code and radio mode. The default working
bandwidth is 20 MHz. This parameter is valid only when the
frequency band is set to 2.4 GHz.
2.2.1.4 Underlay Route
Function Description
After a site CPE connects to a WAN, the CPE must have reachable underlay
network (physical network) routes to the PE, so that an overlay network can be
normally established to forward services. BGP, OSPF, or static routes can be used
based on WAN access requirements.
Application Scenarios
One EVPN network can be configured with one or more types of underlay routes
based on network requirements.
● BGP route
If an MPLS VPN network is connected and BGP dynamic routing is used, the
CPE typically needs to use BGP to exchange routing information with the PE.
iMaster NCE-Campus can configure route filtering rules based on IP network
segments to control the advertisement and receiving of BGP routes.
● OSPF route
If a Layer 2 WAN network is used, OSPF routes can be used to exchange
routes. This can be implemented by creating OSPF processes. iMaster NCE-

Campus can configure the OSPF priority and control the advertisement and
receiving of routes through the blacklist and whitelist route filtering policies.
● Static route
Static routes are applicable to many scenarios, for example, Internet access,
wireless network access using the LTE link, and using blackhole routes to
prevent routing loops.
Static routes do not involve protocol interaction and cannot detect faults on
indirectly connected links of the WAN. This may cause service interruption. To
prevent this problem, you can track the IP address of a WAN network and use
an NQA test instance to detect the IP address. If the detection fails, the
system considers that the WAN network is faulty and automatically selects
another backup link for forwarding.

Typically, the underlay network uses static routes to communicate with the WAN.
If a site uses DHCP to obtain IP addresses, a UNR route is automatically generated
to instruct the CPE to communicate with the WAN. In this case, you do not need
to configure static routes.
Static Route
● Site: Plan the site where underlay routes need to be configured.
● Device: Select the CPE for which static routes are to be configured. In the
dual-gateway scenario, you need to configure static routes for both CPEs.
● Priority: Set the priority of static routes. The priority is in the range from 1 to
255 and is 60 by default. A smaller value indicates a higher priority.
If the same priority is configured for multiple static routes with the same
destination, traffic is load balanced among these static routes. If different
priorities are configured, the static routes back up each other.
● WAN link: Select the link for which static routes are to be configured. A CPE
can connect to a WAN through multiple links.
● Destination network segment and mask: Specify the destination network
segment and mask of a static route. If both the destination IP address and
mask are set to 0.0.0.0, a default route is configured.
● Next hop type: Plan the next hop, which can be an IP address, an outbound
interface, or a blackhole route.
Generally, you can set the next hop to an IP address. If the WAN interface
accesses the network through a P2P protocol (for example, PPPoE), set the
next hop to an outbound interface. If you want to forbid access to certain
network segments, set the next hop to black_hole, which means that packets
destined for the network segments will be discarded.
● Detection: Plan the address to be detected. Ensure that the address is
reachable through the configured static route.
If the next-hop IP address manually specified for a static route changes, the
device on which the static route is configured is unaware of the change. As a
result, traffic fails to be forwarded along the static route. After the address to
be detected is specified, the system associates the static route with an NQA
test instance and creates an ICMP NQA test instance to check whether the IP
address is reachable. If the NQA test instance fails, the static route is

withdrawn. In this way, invalid static routes can be detected in a timely

manner.
2.2.1.5 VN Service Isolation

In many cases, due to increasingly high security requirements, a network must be
divided into multiple departments to realize fine-grained service management and
enhance security. Services of users in different departments must be completely
isolated. The EVPN Interconnection Solution uses multiple VNs to isolate services
of multiple departments under a single tenant. Each VN is an independent IP
Layer 3 private network. Multiple VNs are logically isolated from each other in an
E2E manner, ranging from the tunnel for connecting to a site to the site CPE.
A VN is defined for each department to isolate services for multiple departments

of an enterprise. Each VN has an independent overlay topology (hub-spoke, full-
mesh, partial-mesh, or hierarchical topology). LAN-side settings, traffic policies,
and security policies of sites among which services are isolated are configured
based on VNs. Different policies can be configured for different VNs.
If departments of an enterprise do not need to be isolated from each other, only

one VN is required, and all sites are added to the VN to construct an overlay
topology.
NOTE
Currently, addresses of different departments cannot overlap.

● VN name: Plan VN names based on specific rules, for example, by
department.
● Site: Plan sites for each VN.
● IPSec encryption: Specify whether to perform IPSec tunnel encryption for each
VN.
● VN topology: Plan the overlay topology (hub-spoke or full-mesh) of each VN.
VNs are independent of each other and can use different topology models
even if they contain the same sites. For details about the overlay topology
planning, see "Data Planning and Design" in 2.2.1.6 Overlay Network.
● Configuration on the LAN side of the site: If multiple VNs are configured, plan
configurations for sites in each VN. For example, if Site1 belongs to both VN1
and VN2, you need to plan the configurations on the LAN side for Site1 in
both VN1 and VN2. For details about the planning of LAN-side configurations,
see "Data Planning and Design" in 2.2.1.3.2 Site LAN Model.

● Policy configuration: Plan service policies for sites in each VN if multiple VNs
are configured. For details, see 2.2.2.1 Internet Access, 2.2.2.2 Interworking
with Legacy Sites, and 2.2.2.3 Application Experience Optimization Policy.
2.2.1.6 Overlay Network
Topology
Based on users' service requirements, the EVPN Interconnection Solution supports
the following typical overlay topology models for inter-site interconnection. Table
2-4 lists the site roles in different topology modes.
Table 2-4 Site roles

Site Role Description
Hub site In the hub-spoke networking, branches do not

communicate with each other by default, and all
branches can access the hub site.
Branch-to-branch In the hub-spoke networking, traffic between branch

hub site sites must pass through the branch-to-branch hub site.
Branch site In the full-mesh networking, all user sites except the
hub site are called branch sites.
Redirect site In the full-mesh networking, if two sites cannot

communicate with each other directly, they can
communicate through a third site. The third site is
called a redirect site.
Border site A border site is a site through which sites in an area

communicate with sites in other areas.
● Hub-spoke: Generally, the headquarters and data center of an enterprise

functions as a hub site. Branch sites of the enterprise can communicate with
the hub site. To improve the data center reliability, some enterprises deploy
multiple data centers for disaster recovery. In this case, multiple hub sites with
different priorities can be configured for branch sites to access. By default,
branch sites do not communicate with each other. If branch sites need to
communicate with each other, you need to configure one or two hub sites as
the branch-to-branch hub sites, through which inter-branch traffic is
transmitted. The hub-spoke topology applies to scenarios where unified
security monitoring needs to be implemented for traffic from branches to the
headquarters or data centers.

● Full-mesh: All sites of an enterprise can communicate with each other. If

traffic needs to be transmitted between the headquarters and branches or
between branches, data is directly exchanged without traversing an
intermediate node. This model is applicable to scenarios where all sites of an
enterprise need to directly access each other. This model eliminates the delay
caused by traffic transmission through the headquarters.
● Partial-mesh: Most sites of an enterprise can directly communicate with each

other. However, the underlay WAN networks of a small number of sites
cannot directly communicate with each other. For example, in the following
figure, branch 2 and branch 4 need to communicate with each other through
the redirect site branch 1.

● Hierarchical topology: The hierarchical topology is applicable to large-scale

enterprises that span multiple areas. The entire overlay network is divided
into multiple areas. Traffic between sites in different areas is forwarded
through a border site. The hub-spoke, full-mesh, or partial-mesh topology can
be used in an area. For example, area 1 uses the hub-spoke topology, and
area 2 uses the full-mesh topology in the following figure.
● Customized topology: If the preceding overlay topologies cannot meet your

networking requirements, you can customize topology policies to adjust paths
between sites based on the preceding topologies as required. You can also
define a new overlay topology by customizing topology policies. This method
is complex and requires high planning and design capabilities. Therefore, you
are advised to use the first method.
A customized topology policy involves the following elements:
a. Matching mode: You can specify the IP prefix or site list. If both the IP
prefix list and site list are specified, the relationship between the IP prefix

list and site list is AND. That is, a rule is matched only when both the IP
prefix list and site list are matched.
b. Action after matching: The action can be permit or deny. When a rule is
matched, the specified action is performed. If the action is permit, you
can specify the next-hop site.
c. Attach sites: You can specify the sites to which a customized topology
policy is applied.
Based on the enterprise WAN service and internal management requirements, the
enterprise WAN has multiple topology models. The single-layer and hierarchical
network models are supported.
● Single-layer network model

The single-layer network model, also called the flat network model, enables
branches to directly connect to the headquarters, DCs, and other branches. In
this model, the overlay network can use the hub-spoke, full-mesh, or partial-
mesh topology. Generally, the single-layer network model is applicable to
small- and medium-sized enterprise networks that have a small number of
centrally distributed sites, as shown in Figure 2-4.
Figure 2-4 SME scenario
For large-scale enterprise networks that have a large service scale but a small
number of centrally distributed sites, the single-layer network model can also
be used, as shown in Figure 2-5.

Figure 2-5 Application scenario for large enterprises with a small number of
branches
● Hierarchical network model

According to the enterprise management structure, multiple areas are
created. Each area uses a single-layer network model and deploys one or
more sites as border sites. The border sites of each area constitute the
backbone area, namely, the level-1 network, for interconnection between
areas. Border sites of an area connect to both the level-2 area network and
level-1 backbone network. The hierarchical network model is typically
applicable to large enterprises that have large-scale networks and are widely
distributed, as shown in Figure 2-6.

Figure 2-6 Application scenario for large enterprises with a large number of
branches
If a large enterprise establishes branches or subsidiaries in multiple countries

and carries out transnational operations, a multinational enterprise
interconnection network needs to be set up. Based on experience of ICT
construction for multinational companies, national and international WAN
networks need to be rented and one or two global headquarters need to be
established with regional headquarters and branch sites deployed in each
country or region, as shown in Figure 2-7.

Figure 2-7 Multinational enterprise scenario
Topology Implementation
On iMaster NCE-Campus, you can specify the topology model between sites.
iMaster NCE-Campus then generates the corresponding network model based on
the topology model, converts the network model into BGP routing policies, and
delivers the policies to the RR. The RR controls the route sending and receiving of
different sites based on the routing policy delivered by iMaster NCE-Campus. In
this way, the sites can communicate with each other based on the specified
topology model.

1. Different overlay topologies are constructed in different VNs.

2. The overlay topology is implemented by controlling the route receiving and
sending of each site.
3. A routing policy is configured on the RR to guide route learning at sites. The
routing policy on the RR is automatically orchestrated by iMaster NCE-
Campus based on the configured topology model.
4. The routing policy is matched by site ID to filter routes or modify the next-
hop site ID.
5. Sites in different areas can use different networking modes.
6. Hub-spoke networking: When a spoke site learns a route from another spoke
site, the next hop of this route needs to be changed to the hub site.
7. Full-mesh networking: Routes advertised by all sites can be learned. If a
redirect site exists, all routes need to use the redirect site as the backup next
hop.
8. Hierarchical networking:
a. When a non-border site in an area learns routes advertised from other
areas, the site ID of the next hop needs to be changed to that of the
border site in the local area.
b. When a border site in an area learns routes advertised from other areas,
the next hop points to a border site in another area or the hub site which
resides in an area interconnected to the local area.

to plan an overlay topology for sites in each VN. The same site in different VNs
can use different overlay topologies.

● Network model: If there are a small number of sites and multinational

interconnection is not involved, use the single-layer network model. If there
are a large number of sites (for example, more than 500) or multinational
interconnection is involved, use the hierarchical network model.
● Overlay topology in the single-layer network model
In the single-layer network model, all sites in a VN belong to the same area.
Therefore, the entire network of a VN can use the hub-spoke or full-mesh
mode.
– Hub-spoke: The hub site needs to be specified. You can specify a
maximum of two hub sites that work in active/standby mode. Select a
site with a strong and stable network as the hub site. Generally, select the
enterprise headquarters or the site where the data center is located as
the hub site.
– Full-mesh: All sites in a VN can communicate with each other. If underlay
WAN networks of only a small number of sites cannot directly
communicate with each other, the partial-mesh mode can be used, which
is implemented by deploying the redirect site on the basis of the full-
mesh mode.
– Partial-mesh: On the full-mesh networking, if underlay WAN networks of
some sites cannot directly communicate with each other or the reliability
of interconnection between sites needs to be enhanced, you can
configure a redirect site. Generally, a site that can communicate with sites
on the underlay WAN networks, has good network connection quality,
and is physically close to each other is used as the redirect site. A
maximum of two redirect sites in active/standby mode can be configured
in an overlay topology.
For example, in the full-mesh topology shown in the following figure, the
underlay network to which site 1 connects is different from that of site 4
and site 7. As a result, no overlay tunnel can be established for direct
access. Site 2 and site 3 can communicate with all the other sites and
have excellent performance and therefore can be configured as redirect
sites in active/standby mode. Site 1 can communicate with site 4 and site
7 over the overlay network through site 2 and site 3. If the overlay tunnel
of other sites is faulty, they can access each other over the overlay
network through site 2 and site 3.

● Overlay topology in the hierarchical network model

In the hierarchical network model, sites on the network are divided into
multiple areas, which are level-1 areas and are also called leaf areas. Areas
are interconnected through one or two border sites. Sites 4, 5, 6.1, and 6.2 in
the figure are border sites of the corresponding areas. All border sites form an
area, which is a level-2 area and is also called the backbone area. A network
can have only one backbone area.

– Area name: Specify the name of each leaf area, for example, Area1.
– Area overlay topology: Specify the topology (hub-spoke or full-mesh) for
each area. Different overlay topologies can be specified for areas.
▪ Hub-spoke
○ Hub site: Similar to that in the hub-spoke mode in the single-
layer network model, the hub site needs to be specified in the
hierarchical network model.
○ Border site: The hub site functions as a border site, and no
border site needs to be specified again.
▪ Full-mesh networking
○ Redirect site: You can specify whether to configure a redirect site
based on actual requirements.
○ Border site: If an area using the full-mesh mode needs to
interconnect with other areas, you need to specify the border
site. The border site must be able to communicate with border
sites in other areas and have good network connections and

stability. You can configure a maximum of two border sites that

work in active/standby mode.
– Inter-area interconnection: Select hub-spoke or full-mesh for the
backbone area. If the hub-spoke mode is used, you need to specify the
hub site. If the full-mesh mode is used, you need to specify whether to
configure a redirect site as required.
– Customized topology policy: You can adjust the sites, matching rules, and
actions in policies for the overlay topology.
▪ Policy name: Name of a customized policy.
▪ Priority: The priorities of multiple policies must be different. If both

the predefined topology and customized topology policies are
configured, customized topology policies are executed before the
predefined topology. If multiple customized topology policies are
configured for a site, the policies are executed in sequence based on
their priorities.
▪ Matching mode: The IP prefix (including the IP address, mask, and

mask range) and site can be specified. Multiple IP prefixes and sites
can be specified, and the relationship OR is used between IP prefixes
and between sites. The relationship AND is used between the IP
prefixes and sites.
▪ Action: If permit is specified, the next hop can be specified. Multiple

next hops can be specified based on priorities. If the next hop with a
higher priority is unreachable, the site with a lower priority takes
effect. If the action is deny, access to any matched network segment
or site will be denied.
▪ Modification mode: The overwrite and additive modes are available.

○ Overwrite: A new policy overwrites the access path in the
original predefined topology, and access between the two sites is
implemented based on the customized topology policy.
○ Additive: A new access path is added based on the original
predefined topology. The priority of the customized topology
policy is higher than that of the predefined topology.
For example, in an EVPN interconnection network, if the overlay network
uses the hub-spoke model and branch 1 and branch 3 need to directly
communicate with each other without traversing a hub site, define the
following customized topology policies:
▪ Set the matching site to branch 3, action to permit, next hop to

branch 3, and modification mode to overwrite in a policy, and apply
the policy to enable branch 1 to directly access branch 3.
▪ Set the matching site to branch 1, action to permit, next hop to

branch 1, and modification mode to overwrite in another policy, and
apply the policy to enable branch 3 to directly access branch 1.

2.2.1.7 Overlay Route
Overall Routing Solution for EVPN Interconnection Networking

Figure 2-8 shows the routing solution of the underlay and overlay on the EVPN
Figure 2-8 Overall routing solution
1. Overlay LAN route: Static, OSPF, and BGP routes are supported. Currently,
LAN-side routes are manually configured by customers based on the
connection mode on the LAN side.

2. Interworking link route: OSPF is used for the interconnection between VNs on
the overlay and underlay networks. This route is automatically orchestrated
and configured by the system if Site-to-Internet or Site-to-Legacy Site is
enabled. This route will not be enabled if Site-to-Internet or Site-to-Legacy
Site is disabled.
3. Interconnection link route: OSPF or IBGP is used to exchange routes between
two CPEs in dual-CPE scenarios. The routes are automatically orchestrated
and configured by the system and do not need to be manually configured.
4. Overlay WAN route: BGP is used to advertise routes on the overlay network.
The routes are automatically orchestrated and configured by the system and
do not need to be manually configured.
5. Underlay WAN route: OSPF, BGP, and static routes are supported. The routes
are manually configured by customers based on the access conditions on the
WAN side.
Overlay Route
Overlay routes refer to the routes at the overlay network layer on the EVPN
interconnection network and are classified into WAN-side and LAN-side routes.
● Overlay WAN route
To enable sites on the EVPN interconnection network to communicate with
each other on the overlay network, configure overlay WAN routes. Based on
the topology model of the overlay network, iMaster NCE-Campus
automatically orchestrates overlay WAN routes. You only need to configure
the blacklist and whitelist policies on the WAN side of the overlay network to
filter overlay routes in the receive and transmit directions.
● Overlay LAN route
To enable the CPE at each site to communicate with the LAN, configure
overlay LAN routes. This ensures that services on the LAN side run properly.
For a large site, the network has a complex structure (hierarchical structure
and multi-network design) and complex network facilities (large number of
routers and switches). In Layer 3 interconnection scenarios, CPEs can establish
Layer 3 connections to the LAN through static or dynamic routes.

Overlay WAN Route
BGP routes on the overlay WAN side are automatically orchestrated by the system.
You can configure the blacklist and whitelist to control the advertisement and
receiving of BGP routes on the overlay WAN side. If multiple VNs are planned for
service isolation between departments, you need to plan overlay WAN routes for
sites in each VN.
● Filtering direction: Specify whether to filter the routes to be advertised or
received. For example, if some routes on the LAN side cannot be accessed by
other sites, you can use the blacklist to filter out the routes on the LAN side.
● Filtering mode: Specify whether to use the blacklist or whitelist for filtering. If
the blacklist is used, routes in the blacklist cannot be advertised or received
based on the filtering direction, and routes not contained in the blacklist can
be advertised or received normally. If the whitelist is used, routes in the

whitelist can be advertised or received normally, and routes not contained in

the whitelist cannot be advertised or received.
● IP address prefix list: Plan the IP address prefixes in the blacklist and whitelist
for filtering. You can specify the destination IP address/mask and mask range
for filtering. Multiple network segments can be configured.
– IP address/mask: Plan the IP addresses and masks for filtering. The
address prefix list filters routes by matching destination addresses.
Therefore, ensure that the destination addresses to be filtered are in the
specified IP address range. For example, if you do not want the
172.16.12.0/24 network segment on the overlay LAN side of the site to be
accessed by other sites, you can use the blacklist to filter the routes that
are advertised with the IP address being 172.16.12.0/24.
– Lower limit of the mask range: Specify the lower limit of the mask range.
The following condition must be met: Mask ≤ Lower limit of the mask
range ≤ Upper limit of the mask range. For example, if the mask of an
address prefix is set to 172.16.12.0/24, the lower limit is 25, and the
upper limit is 26, the 172.16.12.0/25 and 172.16.12.0/26 network
segments are filtered out. If the mask range is not specified, only
172.16.12.0/24 is filtered out.
– Upper limit of the mask range: Specify the upper limit of the mask range.
Overlay LAN Route
to plan overlay LAN routes for sites in each VN.
Static, BGP, and OSPF routes are supported on the LAN side of sites.
● OSPF
– Site: Plan the site where overlay LAN routes need to be configured.
– Device: Select the CPE or core device for which OSPF routes are to be
configured. In the dual-gateway scenario, you need to configure OSPF
routes for both CPEs.
– Process ID: Plan the ID of the OSPF process. In EVPN tunnel mode, the
process ID is in the range from 1 to 20000.
– General parameters: The following data is valid in the OSPF area of all
interfaces on the LAN side.
▪ Default route advertisement flag: Plan whether to advertise the

default route to common OSPF areas.
▪ Default route cost: Plan the default route cost for advertising the
default route. The default value is 1.
▪ Internal priority: Plan the priority of OSPF routes (excluding AS

external routes). A smaller value indicates a higher priority.
▪ ASE priority: Plan the priority of the OSPF AS external route. A

smaller value indicates a higher priority.
– Interface parameters: Plan data for all LAN-side interfaces on which OSPF
routes need to be enabled.
▪ Area ID: Plan the ID of an OSPF area.

▪ Interface name: Select the LAN-side interface on which OSPF routes

are to be enabled.
▪ Authentication mode: Plan the authentication mode used by the

OSPF area. The authentication modes and passwords of all the
devices must be the same in any given area, but can differ between
several areas.
The following authentication modes are supported:
○ None: Authentication is not performed on OSPF packets.
○ Simple: A password needs to be configured.
○ Cryptographic: The MD5, HMAC-MD5, or HMAC-SHA256
authentication mode can be selected.
▪ Key: Plan the authentication key identifier for interface ciphertext

authentication. This parameter needs to be set only when the
cryptographic authentication mode is used. The value must be the
same as the authentication key identifier of the peer end.
▪ Password: Specify the plain text or cipher text authentication key.

This parameter is supported only in Cryptographic or Simple
authentication mode.
▪ Hello packet interval: Plan the interval for sending Hello packets on
an interface, in seconds. The default value is 10. Hello packets are
periodically exchanged by OSPF interfaces to establish and maintain
neighbor relationships. A smaller interval means shorter time taken
to detect network topology changes but a higher route cost. The
interval must be the same as that of the neighbor.
▪ DR priority: Plan the priority of an interface during designated router

(DR) election. The default value is 0. The DR priority of an interface
determines whether the interface participates in DR election. If the
DR priority is 0, the router where the interface is located cannot be
elected as a DR or BDR.
▪ Cost: Plan the OSPF cost for the interface. By default, OSPF
automatically calculates the cost based on the interface bandwidth.
Load balancing can be performed among several LAN-side routes
with the same protocol type, cost, and destination address. You can
change the interface costs to change the load balancing mode to the
active/standby mode according to the actual networking.
– Route importing: Import routes discovered by other routing protocols to
enrich OSPF routing information. When OSPF imports external routes,
you can set the cost of imported routes.
▪ Protocol: Plan the source routing protocol. By default, WAN-side BGP

routes on the overlay network are imported to implement
communication on the entire network. Static and direct routes can
also be imported.
▪ Cost: Plan the cost of the imported route. The default value is 1. You
can change the cost to determine whether load balancing is achieved
for multiple routes destined for a network segment.

– Route filtering (supported only by AR routers): You can plan the following
parameters to use the blacklist and whitelist for route filtering to control
the advertisement and receiving of OSPF routes:
▪ Filtering direction: Specify whether to filter the routes to be

advertised or received.
▪ Policy: Specify whether to use the blacklist or whitelist for route

filtering. If the blacklist is used, routes in the blacklist cannot be
advertised or received based on the filtering direction, and routes not
contained in the blacklist can be advertised or received normally. If
the whitelist is used, routes in the whitelist can be advertised or
received normally, and routes not contained in the whitelist cannot
be advertised or received. You can specify the cost value when
advertising routes in the whitelist.
▪ IP address prefix list: Plan the IP address prefixes in the blacklist and
whitelist for filtering. You can specify the destination IP address/mask
and mask range for filtering. Multiple network segments can be
configured.
● BGP
– Advanced Settings
▪ Default route importing: Specify whether to import the existing

default route in the local routing table to the BGP routing table.
Generally, the default route importing function does not need to be
enabled. If the LAN side connects to the Internet and other sites
need to access the Internet through the LAN side of the site, the
default route importing function needs to be enabled.
▪ Route importing: Specify the source routing protocol. By default,

static and direct routes are imported.
▪ External priority (supported only by AR routers): Plan the priority of

EBGP routes. In the dual-gateway scenario, you can configure
different priorities for the two devices.
▪ Summarized route (supported only on AR routers): If routes need to

be summarized, plan the network segments of summarized routes.
You can specify the IP addresses and masks of the summarized
routes.
After the network segment of the summarized routes is specified, if
LAN-side routes are subnets of the specified network segment, these
subnets are summarized into one route and then advertised. If there
are too many LAN-side routes or the information about the LAN-side
routes need to be hidden, routes of multiple network segments can
be summarized into one network segment. This reduces the size of
the CPE routing table and hides the internal routing information of
the local site.
– Device: Select the CPE or core device for which BGP routes are to be
configured. In the dual-gateway scenario, you need to configure BGP
routes for both CPEs.

– Peer IP address: Plan the IPv4 address of the peer. The IPv4 address can
be the IP address of an interface that is directly connected to the peer or
the IP address of a loopback interface of the reachable peer.
– Peer AS: Specify the AS number of the peer device. The BGP AS number
must be the same as that of the peer device. Otherwise, the BGP peer
relationship cannot be established.
– Local AS: Configure the local end to establish a connection with a
specified peer by using a fake AS number. By default, the local end uses
the actual AS number to establish a connection.
– Keepalive time: Specify the BGP keepalive time, in seconds. The default
value is 60.
– Holdtime: Specify the BGP hold time, in seconds. The default value is 180.
The hold time must be at least three times the keepalive time.
▪ If short Keepalive time and hold time are set, BGP can detect a link
fault quickly. This speeds up BGP network convergence, but increases
the number of keepalive messages on the network and loads of
devices, and consumes more network bandwidth resources.
▪ If long Keepalive time and hold time are set, the number of
keepalive messages on the network is reduced, loads of devices are
reduced, and fewer network bandwidths are consumed. If the
keepalive time is too long, BGP is unable to detect link status
changes in a timely manner. This is unhelpful for implementing rapid
BGP network convergence and may cause many packets to be lost.
– MD5 encryption: Specify whether to use MD5 authentication between
BGP peers. If MD5 encryption is used, a ciphertext password must be
specified. The MD5 authentication configuration and the ciphertext
password must be the same as the BGP configuration of the peer device.
Otherwise, the BGP peer relationship fails to be established.
– Routing policy: You can configure route filtering to control the
advertisement and receiving of BGP routes. This parameter is available
only to AR routers.
▪ Filtering direction: Specify whether to filter the routes to be

advertised or received.
▪ IP address prefix list: Plan the IP address prefixes in the blacklist and
whitelist for filtering. You can specify the destination IP address/mask
and mask range for filtering. Multiple network segments can be
configured.
▪ Filtering mode: Specify whether to use the blacklist or whitelist for

filtering.
▪ MED: Specify the MED value of BGP routes corresponding to the

network segment specified in the IP address prefix list.
Similar to the metric of an IGP, the MED value is used to determine
the optimal route for the traffic to enter an AS. When a BGP-enabled
device obtains multiple routes to the same destination address but
with different next hops from EBGP peers, it selects the route with
the smallest MED value as the optimal route.

▪ Community: Specify the community attribute of BGP routes

corresponding to the network segment specified in the IP address
prefix list.
The community attribute is a private BGP route attribute. It is
transmitted between BGP peers and is not restricted to within an AS.
The community attribute allows a group of BGP-enabled devices in
multiple ASs to share the same routing policies. This allows routing
policies to be flexibly used and makes it simple to maintain and
manage routing policies.
▪ AS_Path: Specify the AS_Path of BGP routes corresponding to the

network segment specified in the IP address prefix list.
The AS_Path attribute records the numbers of all ASs that a route
passes through, from the source to the destination, in the vector
order. You can configure the AS_Path attribute to implement flexible
route selection.
● Static Route
– Device: Select the CPE for which static routes are to be configured. In the
dual-gateway scenario, you need to configure static routes for both CPEs.
– Priority: Set the priority of static routes. The priority is in the range from
1 to 255 and is 60 by default. A smaller value indicates a higher priority.
If the same priority is configured for multiple static routes with the same
destination, traffic is load balanced among these static routes. If different
priorities are configured, the static routes back up each other.
– Destination network segment and mask: Specify the destination network
segment and mask of a static route. If both the destination IP address
and mask are set to 0.0.0.0, a default route is configured.
– Next hop: Plan the next hop, which can be an IP address or blackhole
route.
Generally, you can set the next hop to an IP address. If you want to forbid
access to certain network segments, set the next hop to black_hole,
which means that packets destined for the network segments will be
discarded.
– Detection address: Plan the address to be detected. Ensure that the
address is reachable through the configured static route. This parameter
is available only to AR routers.
If the next hop manually specified for a static route changes, the device
on which the static route is configured is unaware of the change. As a
result, traffic fails to be forwarded along the static route. After the
address to be detected is specified, the system associates the static route
with an NQA test instance and creates an ICMP NQA test instance to
check whether the IP address is reachable. If the NQA test instance fails,
the static route is withdrawn. In this way, invalid static routes can be
detected in a timely manner.

2.2.2 Service Design

NOTE
The LAN-side service planning and deployment of the headquarters campus and branch
campus are the same as those in the single-campus scenario. For details, see the [Huawei
CloudCampus Solution] Small- and Medium-Sized Campus Network Deployment Guide,
[Huawei CloudCampus Solution] Large- and Medium-Sized Campus Network Deployment
Guide (Virtualization Scenario), and [Huawei CloudCampus Solution] Large- and Medium-
Sized Campus Network Deployment Guide (Non-virtualization).
2.2.2.1 Internet Access
Functions
The EVPN Interconnection Solution provides the following Internet access modes:
● Local Internet access: The Internet access traffic of a site is routed from the
local Internet link to the Internet. In local Internet access mode, NAT in Easy
IP mode is provided. You can determine whether to enable the NAT function
based on the outbound interface. After NAT is enabled, the system uses the IP
address of the outbound interface as the public IP address after NAT is
performed and translates the IP address of the traffic passing through the
interface.
Local Internet access is applicable to small-scale enterprises or scenarios
where centralized security control is not required for Internet access traffic
and links for accessing the Internet are available on the WAN side.
● Centralized Internet access: All sites in an enterprise access the Internet
through a centralized Internet gateway.
Centralized Internet access is applicable to scenarios where the site does not
have links for accessing the Internet or where Internet access traffic needs to
be centrally controlled. In this mode, a centralized Internet gateway is
configured. Traffic from other sites is forwarded to the centralized Internet
gateway through the overlay network to access the Internet.
● Hybrid Internet access: The system allows some applications to access the
Internet in local Internet access mode and other applications to access the
Internet in centralized Internet access mode. If local Internet access with the
default policies (Policy is set to All) is used and centralized Internet access is
enabled, local Internet access is preferred. If the local link is faulty, the
centralized Internet access mode is used. In hybrid Internet access mode, the
NAT function in Easy IP mode can also be enabled on the outbound interface
for local Internet access.
Hybrid Internet access is applicable to scenarios where Internet access traffic
needs to be managed centrally but the traffic of specified services (such as
Office 365) is routed out from the local site to minimize the access delay.
NAT ALG
Generally, a site uses a private IP address to access the Internet through the
gateway. To implement this, the NAT function needs to be enabled to translate a
private IP address into a public IP address. NAT translates only addresses in IP
packet headers and ports in TCP/UDP headers. For some special protocols such as

FTP, IP addresses or port numbers may be contained in the data field of the
protocol packets. NAT cannot translate such IP addresses or port numbers. A good
way to solve the NAT issue for these special protocols is to use the application
level gateway (ALG) function.
Currently, the following protocols support the NAT ALG function: DNS, FTP, SIP,
PPTP, and RTSP.

to plan the network access mode for sites in each VN.
● Centralized Internet access
– Internet gateway: Plan a site that functions as the centralized Internet
gateway. A maximum of two sites can be specified as the active gateway
and standby gateway, respectively. You can configure all areas to access
the network through the specified gateway or specify an Internet
gateway for each area.
● Local Internet access
– Site: Plan the site that uses the local Internet access mode.
– WAN link: Specify the WAN link name in the template to select the WAN
link used for local Internet access. A site can access the Internet through
the specified WAN link. For sites using the same WAN link template, only
the same WAN link can be used for Internet access.
– NAT: Plan whether to enable the NAT function. Generally, the NAT
function needs to be enabled for Internet access services at sites.
– Link priority: Plan the priority of a WAN link. If multiple WAN links are
available for Internet access, you can configure the link priorities so that
the WAN links can work in active/standby mode. The link priority is in the
range from 1 to 3. A smaller value indicates a higher priority.
– Bandwidth allocation: Specify the proportion of local breakout traffic to
the available bandwidth that has been allocated to overlay services in the
VN. If the available bandwidth for overlay services accounts for 30% of
the total bandwidth for the VN and 10% of the bandwidth is allocated to
the local breakout traffic, the available bandwidth of the local breakout
traffic accounts for 3% of the total bandwidth of the WAN link. That is, if
the total bandwidth of the interface is 100 Mbit/s, the bandwidth for
local breakout traffic is 3 Mbit/s.
– Policy: The following local Internet access policies are supported:
▪ All: All Internet access traffic from the LAN side of a site is routed
out by matching the WAN-side routes.
▪ by Application: The LAN-side Internet access traffic of a certain type

(defined using a traffic classifier template) is routed out matching
Policy-based Routing (PBR). PBRs are automatically created by
iMaster NCE-Campus and then delivered to gateways. Application
traffic that does not match the traffic classifier template is
transmitted to the Internet in centralized mode.
– Enable VAS: If the local site functions as an Internet gateway and needs
to connect to a third-party security system to which service traffic is

diverted to ensure service security, you need to enable the VAS and
configure the VAS connection. For details, see "Third-party security device
connected through VAS" in 2.2.2.4.2 Firewall. If you switch on Enable
VAS, Policy must be set to All.
● Hybrid Internet access
– Centralized Internet gateway: For details, see Centralized Internet
access.
– Local Internet access: For details, see Local Internet access. The
following parameters for hybrid Internet access are different from those
for local Internet access:
▪ Policy: Select All or Application. If All is selected, all services of a

site preferentially use local Internet access. If local Internet access is
unavailable, centralized Internet access is used. In this case,
centralized Internet access is a backup of local Internet access. If
Application is selected, traffic classifiers need to be configured so
that some services use local Internet access and other services use
centralized Internet access.
▪ Traffic classifier: If Policy is set to Application, plan the traffic

classifiers for the local Internet access service.
You can define local Internet access services by specifying the source
and destination IP addresses, and TCP or UDP source and destination
port numbers, or by matching the application group, VLAN ID, 802.1p
priority, source and destination MAC addresses, and Layer 2 protocol
type. For details about the traffic classifier, see the description in
"Data Planning and Design" in 2.2.2.3.2 Intelligent Traffic Steering.
▪ Detection IP address: If Policy is set to Application, you can plan a

detection IP address for the site. The system creates an NQA instance
to detect the IP address, test the network connectivity, and quickly
detect the network fault on the WAN side. When the detection fails,
services can switch to the centralized Internet access mode in a
timely manner. You can plan a public detection IP address (for
example, the DNS server address) that can be accessed by all sites or
a separate detection IP address (for example, gateway address of the
WAN link of the site) for each site.
● NAT ALG
– Site: Plan the sites where the NAT ALG function needs to be configured.
– NAT ALG–capable protocol: Plan the protocols for which the NAT ALG
function is to be enabled. Currently, only DNS, FTP, SIP, PPTP, and RTSP
are supported.
2.2.2.2 Interworking with Legacy Sites

Before deploying the EVPN Interconnection Solution, enterprises may have
multiple sites connected through legacy MPLS private lines. When new sites are
deployed or some legacy sites are reconstructed into EVPN sites, an enterprise has
two types of logical networks: EVPN and legacy MPLS network. These two types
of networks require communication between each other.
If the underlay network connected to an EVPN site can communicate with the
legacy MPLS network, the breakout technology can be used to transmit user

traffic from the EVPN site to the underlay MPLS network. Users at the EVPN site
can directly communicate with users at the legacy site through the underlay
network. This scenario is suitable for small- and medium-sized enterprises that
build EVPN interconnection networks on themselves without a dedicated IWG. The
network model is simple and configuration and maintenance are easy.
In this scenario, the following traffic models can be used for mutual access,
depending on service requirements:
● Distributed local access
This model can be used if all EVPN sites can access legacy underlay MPLS
network sites through local breakout. In this model, traffic of each site can be
offloaded locally.
● Centralized access
If some EVPN sites cannot access legacy sites through local breakout, you can
select one site that can communicate with the legacy sites as the centralized
access site. Traffic from other sites is sent to the centralized access site
through overlay tunnels, and then forwarded to the legacy sites through local
breakout.
● Hybrid access
If a centralized access site is deployed on the EVPN network, it can provide
the centralized access function for the sites that cannot access the legacy
network through local breakout. In addition, the distributed access function
can be configured for sites that support local breakout. Then traffic of these
distributed sites is preferentially forwarded to the legacy underlay MPLS sites
through local breakout. If the local link for accessing the MPLS network is
faulty, traffic can be transmitted to the centralized access site through the
overlay tunnel of other links, and then forwarded to the legacy site through
the centralized access site. This improves transmission reliability for traffic.
Figure 2-9 shows the hybrid access mode. EVPN Site3 and EVPN Site1
communicate with the MPLS network. EVPN Site3 functions as the IWG. EVPN
Site2 communicates with the MPLS network through EVPN Site3. The hybrid
access mode is configured for EVPN Site1. Traffic destined for the legacy
MPLS sites is preferentially forwarded to the underlay MPLS through local
breakout. If the MPLS link is faulty, the Internet link is used to communicate
with legacy sites through EVPN Site3.

Figure 2-9 EVPN site functioning as the IWG

to plan the legacy site access mode for sites in each VN.
● Centralized access
– Mutual access gateway: Plan a site that functions as the gateway for
centralized access. In EVPN tunnel mode, a maximum of two sites in
active/standby mode can be specified.
– IGW: Specify whether the IGW functions as the gateway for legacy sites
to access the Internet. If legacy sites access the Internet through the IGW,
you need to enable the IGW function of the sites.
– WAN link: Specify the WAN link name in a WAN link template to select
the WAN link used for MPLS network access. For sites using the same
WAN link template, only the same WAN link can be used for Internet
access.
available for MPLS network access, you can configure the link priorities
so that the WAN links can work in active/standby mode. The link priority
is in the range from 1 to 3. A smaller value indicates a higher priority.
You can configure multiple links to work in active/standby mode or load
balancing mode by configuring the priority.
▪ If links have different priorities, they work in active/standby mode,

and the link with the highest priority is the active link.

▪ If the links have the same priority, they work in load balancing mode.
● Local access
– Site: Plan the site that uses the local access mode to communicate with
legacy sites.
– IGW: Specify whether the IGW functions as the gateway for legacy sites
to access the Internet. If legacy sites access the Internet through the IGW,
you need to enable the IGW function of the sites.
– WAN link: Specify the WAN link name in a WAN link template to select
the WAN link used for MPLS network access. For sites using the same
WAN link template, only the same WAN link can be used for Internet
access.
available for MPLS network access, you can configure the link priorities
so that the WAN links can work in active/standby mode. The link priority
is in the range from 1 to 3. A smaller value indicates a higher priority.
You can configure multiple links to work in active/standby mode or load
balancing mode by configuring the priority.
▪ If links have different priorities, they work in active/standby mode,

and the link with the highest priority is the active link.
▪ If the links have the same priority, they work in load balancing mode.
● Hybrid access
– Centralized access: For details, see Centralized access.
– Local access: For details, see Local access.
2.2.2.3 Application Experience Optimization Policy
2.2.2.3.1 Application Identification

Precise identification of applications on a network is the prerequisite and basis for
network services such as intelligent traffic steering, QoS, application optimization,

and security. Service policies can be applied in subsequent service processes only
after applications are identified.
Figure 2-10 shows the application identification feature in the EVPN
Interconnection Solution. The following modes are supported: first packet
inspection (FPI) and service awareness (SA).
Figure 2-10 Application identification
● FPI
FPI can identify the application type at the first data flow of an application. It
can quickly identify applications and is mainly used for SaaS applications with
fixed destination addresses or port numbers.
● SA
SA performs deep packet analysis and accurately identifies common
applications based on the characteristics in application payloads.
When a packet reaches the application identification module, FPI is performed. If
an application can be identified through the first packet, SA is no longer
performed. If the application fails to be identified, SA is performed.
For the FPI and SA, the FPI signature database and SA signature database are
preconfigured on CPEs. The CPEs can identify common applications based on the
application definition (port, signature, and behavior) in the signature database. In
addition, the FPI and SA also support customized applications, so that users can
customize special applications.
FPI
FPI is realized by matching the first packet through 3-tuple information of the
packet, or the SA cache. The application is matched based on L3-L4 information of

the packet. Therefore, if multiple applications have the same L3-L4 information,
the applications may be incorrectly identified. In addition, the FPI process is
simple, so the processing performance of FPI is higher than that of SA.
Application Scenario
1. NAT must be configured on the path through which the application passes. If
the application cannot be identified, it may be discarded after traffic steering
because NAT is not configured for SYN and ACK packets.
2. As the pervasive use of clouds, customers want to send SaaS and trusted
network traffic directly from branches to the Internet instead of forwarding
data through DCs. This improves the bandwidth utilization and reduces the
transmission delay and costs.
3. When enterprises use their own applications or applications that run on the
Internet, the Internet traffic is known and trusted, but other HTTP/HTTPS
traffic is unknown or suspicious. If the specific application cannot be identified
through the first data packet, all HTTP/HTTPS traffic must be sent to the
Internet or to the security web gateway or headquarters for further check
through the enterprise firewall and IDS/IPS resources.
Applications can be identified in user-defined mode or through the pre-defined FPI
signature database.
● User-defined mode: Applications can be customized in 3-tuple mode. When 3-
tuple information is predefined, the source and destination do not need to be
specified. The system first matches an application based on the destination IP
address, destination port number, and protocol type. If no match is found, the
system matches the application based on the source IP address, source port
number, and protocol type. If no match is found, the system matches the
application based on SA. Some common applications are predefined in the
system based on the protocol number, port number, or domain name.
● FPI signature database: The FPI function is associated through the DNS. When
a client initiates a page access request, a DNS request is sent, requesting to
access the specific IP address. The DNS server sends back a DNS response
packet. When the packet traverses the CPE, the CPE parses it to obtain the IP
address. The application ID, port number, and protocol number are queried in
the FPI signature database based on the URL. The triplet information is then
associated with the IP address, and a DNS association entry is generated.
After receiving the DNS response packet, the client requests to access the
application. Then, when the packet traverses the CPE, the application is
identified based on the DNS association entry.
NOTE
FPI based on the domain name is not supported in the web proxy scenario. To use the FPI
function, add domain names to the proxy access exception list.
SA
Different applications use different protocols, each with its own characteristics,
called signatures, which can be a specific port, a character string, or a bit
sequence. SA determines an application by detecting characteristic codes in data
packets. Signatures of some protocols are contained in multiple packets, and
therefore the device must collect and analyze multiple packets to identify the
protocol type. The system analyzes service flows passing through a device, and

compares the analysis result with the signature database loaded to the device. It
identifies an application by detecting signatures in data packets, and implements
refined policy control based on the identification result.
Applications can be identified in customized mode or through the SA signature
database predefined on the CPE.
● User-defined mode: Applications are identified based on URLs or keywords.
On the CPE, rules can be created through triplet, keywords, or both triplet and
keywords. The triplet refers to the server IP address, protocol type, and port
number. The keywords are signatures of a data packet or a data flow
corresponding to the application and uniquely identify the application.
● SA signature database: Applications are identified based on the SA signature
database. The SA signature database can have 500+ or 6000+ records,
depending on the device type. The SA signature database can be upgraded
through Huawei Security Center Platform. The SA signature database needs to
be updated frequently because applications on the live network change
rapidly. Otherwise, some applications may fail to be identified.

● SAC configuration: Smart Application Control (SAC) is used to determine
whether to enable application identification. By default, application
identification is disabled for all sites of a tenant.
Application identification affects the forwarding performance to some extent.
You can determine whether to enable SAC based on the site traffic, service
requirements, and CPE performance. SAC configuration is classified into the
following types:
– Application identification: If both FPI and SA are enabled or disabled
together, the FPI is preferentially used for application identification of
packets passing through the CPE. You can enable application
identification on some or all sites.
– FPI: To enable or disable FPI, you can enable application identification on
some or all sites. To enable FPI on a site, you must enable application
identification on the site.
● Customized Application
When predefined applications cannot meet the identification requirements,
you can define new applications according to their signatures. Applications
can be customized based on application identification results, domain names,
and advanced rules. Each application can have multiple rules.
Table 2-5 Application customized based on application identification results

Configuration Description
Item
Application Specify the application name, which is a string of

Name characters including letters, digits, and underscores (_).

Item
Ru Rule Specify the rule name, which is a string of up to 64

le Name characters including letters, digits, underscores (_), and
hyphens (-). It cannot be any or all.
You can create a rule based on 3-tuple information
(including the destination IP address, port number, and
protocol).
You can also create a rule based on keywords (including
the destination IP address, protocol, and signature).
Destinatio Specify the destination IP address of packets for the

n IP customized application. In most cases, the IP address of
an application server is a fixed public IP address. This
allows the system to identify application packets based
on the specified destination IP address.
Protocol Specify the transport-layer protocol type of the

customized application rule. The options include ALL,
TCP, and UDP.
Destinatio Specify the destination port number of packets for the

n Port user-defined application.
Signature Specify signature information. Data packets of some

applications contain the same character string, which is
regarded as a signature.
● Content: You can select the packet- or flow-based
mode for signature identification.
In the packet-based mode, the system checks every
packet of applications. In flow-based mode, the
system only checks the first packet in the application
data flow and does not check the subsequent packets
if the system detects that the subsequent packets
belong to the same data flow based on the 5-tuple
information.
● Direction: Specify the direction of packets to be
identified.
You can configure a rule to identify signatures only in
request or response packets, or in both of them.
● Plaintext character string: Specify a character string
that can identify application packet signatures.

Table 2-6 Application customized based on domain names
Item


Domain Specify the domain name, which consists of letters, digits,

Name hyphens (-), periods (.), and at most two non-consecutive
asterisks (*).
Table 2-7 Application customized based on advanced rules
Item


Source IP/ Specify the source/destination IP address and mask in the

Destinatio rule.
n IP
DSCP Specify the DSCP value in the rule.
Protocol Specify the transport-layer protocol type of the

customized application rule. The options include ALL,
TCP, and UDP.
Source Specify the TCP or UDP source/destination port number

Port/ in the rule.
Destinatio
n port
● Application group
You can select an application group in a traffic classifier to identify
applications. Only an application group can be selected. Applications that are
not added to the application group are not displayed. You cannot select only
some applications in an application group. You need to plan application
groups properly.
– SA signature database: The SA signature database can have 500+ or
6000+ records, depending on the device type. The SA signature database
can be upgraded through Huawei Security Center Platform.

– Predefined applications (FPI): Select an application from the FPI signature

database and add it to the application group.
If the FPI application is selected, the corresponding SA application is also
selected by default.
– Predefined applications: Select an application from the signature
identification database and add it to the application group.
– User-defined application: Select a user-defined application. You can also
add a user-defined application to the application group after the
application is created.
2.2.2.3.2 Intelligent Traffic Steering

The EVPN Interconnection Solution supports traffic steering based on the
application quality, load balancing, application priority, and bandwidth.
● Traffic steering based on the application quality

Different applications have different requirements on the link quality. For
example, voice and video services are sensitive to delay and packet loss rate
and have high requirements on the link quality. Therefore, an MPLS link with
good quality can be configured as the primary link of voice and video services,
and an Internet link is configured as the backup link with service SLA
requirements. Intelligent traffic steering is performed based on link SLAs,
meeting the SLA and bandwidth requirements of applications.
● Traffic steering based on load balancing
When an enterprise has multiple links, load balancing–based traffic steering
can be configured to fully utilize the link bandwidth. During service
forwarding, hash-based load balancing is performed among multiple links
with the same priority, thus improving bandwidth utilization.
● Traffic steering based on the application priority
If multiple types of service packets are transmitted on the same link, traffic of
high-priority applications is preferentially processed when congestion occurs,
ensuring user experience of high-priority applications. In this case, application
priority-based traffic steering can be used. For example, voice, video, and file
transfer services are carried on an MPLS link. If the link bandwidth is
insufficient, the experience of the voice and video services is preferentially
guaranteed.
● Traffic steering based on the bandwidth
If traffic steering based on the bandwidth is performed, when the link
bandwidth reaches the threshold, this link is not selected for new traffic of
some applications, and other links that meet the requirements are preferred.
This mode ensures the bandwidth usage of high-priority services and prevents
application quality and link quality from deteriorating due to network
congestion.

Traffic Classifier Template
● Operation type: Set the relationship between rules in a traffic classifier to

AND or OR.

– AND
▪ If a traffic classifier contains ACL rules, packets match the traffic

classifier only when they match one ACL rule and all the non-ACL
rules.
▪ If the traffic classifier does not contain any ACL rule, packets match
the traffic classifier only when they match all the non-ACL rules.
– OR: Packets match the traffic classifier if they match one or more rules in
the classifier.
● L3 ACL: Define multiple ACL rules. Packets that meet specified conditions are
allowed to pass.
– Priority: Specify the priority of an ACL rule. Packets preferentially match
the Layer 3 ACL rule with a higher priority.
– Source IP address: Plan the source IP address of packets matching an ACL
rule. If no source IP address is specified, packets with any source IP
address are allowed to pass.
– Destination IP address: Plan the destination IP address of packets
matching an ACL rule. If no destination IP address is specified, packets
with any destination IP address are allowed to pass.
– DSCP: Specify the Differentiated Services Code Point (DSCP) of packets
matching an ACL rule.
– Protocol: Specify the protocol type of packets matching an ACL rule.
– Source port: Specify the source port of the UDP or TCP packets matching
an ACL rule. This parameter is valid only when the protocol of packets is
TCP or UDP. If no source port is specified, TCP or UDP packets with any
source port are matched.
– Destination port: Specify the destination port of the UDP or TCP packets
matching an ACL rule. This parameter is valid only when the protocol of
packets is TCP or UDP. If no destination port is specified, TCP or UDP
packets with any destination port are matched.
● Application: Select an application group that matches packets.
You can select an application group in a traffic classifier to identify
applications. Only an application group can be selected. Applications that are
not added to the application group are not displayed. You cannot select only
some applications in an application group. You need to plan application
groups properly.
● Advanced settings: Take effect only on policies on inbound interfaces.
– VLAN ID: Specify the start outer VLAN ID and end outer VLAN ID of
packets to be matched.
– 802.1p: Specify the 802.1p priority of packets to be matched.
– Source MAC address: Specify the source MAC address of packets to be
matched.
– Destination MAC address: Specify the destination MAC address of packets
to be matched.
– L2 protocol: Specify the Layer 2 protocol type of packets to be matched.
Effective Time Template

● Time type
– Periodic time range: Define a periodic time range based on days or
weeks. The associated traffic policy takes effect at an interval of one day
or week. For example, if the time range of a traffic policy is 08:00-12:00
every day or on every Monday, the traffic policy takes effect at
08:00-12:00 every day or on every Monday.
– Absolute time range: Define a time range from YYYY/MM/DD hh:mm:ss
to YYYY/MM/DD hh:mm:ss. The associated traffic policy takes effect only
within this period.
● Start time: Specify the time when the traffic policy starts to takes effect.
● End time: Specify the time when the traffic policy stops taking effect.
Intelligent Traffic Steering
● VN: Plan service policies for sites in each VN if multiple VNs are configured.
You need to first select the VN for which the policy needs to be configured.
● Traffic classifier: Select a traffic classifier to specify traffic to which intelligent
traffic steering needs to be applied.
NOTE
Intelligent traffic steering does not support the traffic classifier with advanced settings
or operation type being set to OR.
● Policy priority: Set the priority of an intelligent traffic steering policy. For the
same traffic, the intelligent traffic steering policy with the highest priority is
preferentially matched.
● Switchover condition: Refer to the delay, jitter, and packet loss rate of a link.
When the traffic or application quality does not meet the conditions, traffic or
applications are switched.
By default, switchover conditions of voice, real-time video, low-delay data,
and large-capacity data services are defined. You can also set the delay, jitter,
and packet loss rate to customize switchover conditions.
● Transport network priority: Set the primary and secondary transport networks.
– Primary transport network: Configure multiple transport networks as
primary transport networks. A maximum of eight transport networks can
be configured.
▪ For transport networks with the same priority, you are advised to set
Policy between TN to Loadbalance.
▪ For transport networks with different priorities, you are advised to

set Policy between TN to Prefer.
– Secondary transport network: Select a transport network as the
secondary transport network. Traffic is switched to the secondary
transport network only when all primary transport networks are
unavailable.
● Traffic behavior:
– Policy between TN: Specify the scheduling mode between primary
transport networks. The default value is Prefer.
▪ Prefer: The transport network with the highest priority is selected

first for forwarding application traffic. If any of the switchover

conditions exceeds the threshold or the bandwidth usage exceeds the

bandwidth upper limit, the traffic is switched to another transport
network with a lower priority. For services with high reliability
requirements and light traffic (such as payment and emergency call
services), you can enable the packet replication function to
implement dual-fed and selective receiving so as to improve service
reliability. In this way, if one link is faulty, no packet is lost and
important services are not affected.
▪ Loadbalance: Application traffic is load balanced between primary

transport networks with the same priority. Load balancing can be
implemented in either of the following modes:
○ Per flow: Services are load balanced among multiple links in per-
flow mode. This mode ensures that packets are transmitted in a
correct sequence.
○ Per packet: Services are load balanced among multiple links in
per-packet mode. For example, the first data packet is
transmitted on one link, and the second data packet is
transmitted on another link. This mode makes full use of link
bandwidth and improves transmission efficiency, which is
applicable to data backup and large file download scenarios.
– Action when conditions not met: Specify the action to take on traffic
when switchover conditions and bandwidth conditions are not met on
both the primary and secondary transport networks. The default action is
Discard.
▪ Discard: If the traffic does not meet the conditions, packets are
discarded.
▪ ECMP: If the traffic does not meet the conditions, packets are
forwarded continuously.
– Switchover mode: Specify whether traffic can be switched back to the
original link if the quality of the original link recovers after link
switchover occurs. The default value is Pre-emptive.
The link switchover consists of the switchover between primary transport
networks with different priorities and the switchover between primary
and secondary transport networks.
This parameter can be set for high-priority applications only when the
bandwidth of the primary link on which high-priority applications are
located is sufficient.
● Advanced settings: Set bandwidth conditions list, priority, and other
parameters. The system determines whether to switch traffic to another link
based on the current bandwidth usage, application priority, and switchover
threshold, and then determines the application traffic to be switched based
on the application priority.
– Switch upper/lower limit: Select links to transmit traffic based on the
bandwidth usage in addition to delay, jitter, and packet loss rate.
▪ If the link bandwidth usage is lower than the switch lower limit, all
application traffic, including new application traffic, is forwarded
through the current transport network.

▪ If the link bandwidth usage is greater than the switch lower limit and
lower than the switch upper limit, only the existing application traffic
is forwarded through the current transport network, and new
application traffic cannot be transmitted.
▪ If the link bandwidth usage is greater than the switch upper limit,
some existing application traffic is switched to another transport
network for transmission, and new application traffic cannot be
transmitted.
It is recommended that this parameter be configured only when the
bandwidth is sufficient.
– Bandwidth conditions list: Configure bandwidth switchover conditions for
a transport network by specifying the link bandwidth (bandwidth upper/
lower limit) and application bandwidth (maximum/minimum bandwidth).
– Priority: Specify the application priority. The default value is 8. Configure
multiple intelligent traffic steering policies to match different applications
and configure different application priorities to implement application-
based traffic steering based on application priorities.
– Gateway prioritization: After the IGW service is enabled, if two CPEs that
belong to different transport networks need to communicate with each
other through the IGW, you can enable the gateway prioritization
function. By default, this function is disabled. Overlay tunnels are
established between sites based on the configured topology so that the
sites can directly communicate with each other. After gateway
prioritization is enabled, CPEs preferentially communicate with each other
through the gateway by default and learn the routes of other sites
through the gateway.
● Effective time template: Select an effective time template to specify the time
range for the intelligent traffic steering policy to take effect.
● Site: Select a site with which an intelligent traffic steering policy is to be
associated. The policy takes effect only on the selected site.
2.2.2.3.3 QoS
QoS is a mainstream function that implements differentiated services. Data
packets are classified into different priorities or multiple CoSs through traffic
classification. These priorities and CoSs are the prerequisite and basis of the
DiffServ model. Different traffic policies can be configured based on packet
priorities and CoSs to provide different services.
The EVPN Interconnection Solution supports traffic classification based on the IP

5-tuple, application group, and DSCP, and supports QoS policies such as queue
priority scheduling, traffic policing, and traffic shaping. It also supports QoS
functions such as multi-dimensional bandwidth allocation and DSCP re-marking
through HQoS.
● Queue priority
Traffic classification is used to specify different QoS priorities for services.
Based on QoS priorities, services are forwarded through queues with different
priorities for differentiated QoS. If bandwidth resources are insufficient, the
forwarding bandwidth of high-priority services is preferentially guaranteed.

● Traffic policing
Traffic policing controls traffic by monitoring the bandwidth occupied by
service traffic, and discards excess traffic to limit the bandwidth within a
proper range, ensuring appropriate bandwidth resource allocation.
● Traffic shaping
Traffic shaping is a measure to adjust the traffic rate sent from an interface. If
traffic congestion occurs due to burst traffic, traffic shaping is performed to
make irregular traffic transmitted at an even rate, preventing traffic
congestion on the network.
● Bandwidth allocation
HQoS uses multi-level queues to implement bandwidth allocation between
VNs and within a VN. The bandwidth of a physical link is divided into
bandwidths of multiple logical links, and the bandwidth of each logical link is
used by different VNs. The bandwidth of the logical link used by each VN can
specify bandwidths of the overlay network and the local breakout network.
The bandwidth of the overlay network is used for communication between
the hub site, aggregation site, and branch site. The bandwidth of the local
breakout network is used for local access to the Internet or interconnection
between local and legacy sites.
● DSCP re-marking
– After the DSCP re-marking function is configured on the LAN interface,
the DSCP value in the IP header of a packet entering the CPE is modified.
If the packet enters the overlay tunnel for forwarding, the DSCP value in
the outer IP packet header is copied from the DSCP value in the inner IP
packet header by default. At last, the DSCP values in inner and outer IP
packet headers are re-marked. Based on re-marked values, traffic policies
can be deployed on the WAN-side overlay network to implement service
management and scheduling.
– If the DSCP re-marking function is configured on the WAN interface, the
DSCP value in the IP header of a packet sent by the outbound interface
on the underlay network is modified. If the IP packet header of the
overlay tunnel is added to the packet, only the DSCP value in the outer IP
packet header is modified. At last, the DSCP values in inner and outer IP
packet headers may be different, and the outer DSCP value is the re-
marked value.
– If the DSCP re-marking function is configured on both LAN and WAN
interfaces, the DSCP value in the IP header of a packet entering the CPE
is modified. If the packet is sent through the outbound interface on the
underlay network, the DSCP value in the outer IP packet header is
modified again. At last, for the packet that the IP header is encapsulated
in overlay tunnels, the DSCP value in the inner IP packet header is
remarked on the LAN interface and the DSCP value in the outer IP packet
header is remarked on the WAN interface. For the local breakout packet,
the DSCP value in the IP packet header is remarked on the WAN
interface.

VN QoS Group

You can create VN QoS groups and add multiple VNs to a VN QoS group.
Bandwidth allocation and QoS policy configuration can be performed based on VN
QoS groups. All VNs in a VN QoS group share bandwidth resources of the group.
Bandwidth Allocation
You can configure a traffic distribution policy to implement bandwidth allocation.

If no traffic distribution policy is configured for a site, all service VNs on the site
share the WAN link bandwidth. The total WAN link bandwidth on the site is 100%.
The maximum ratio of the bandwidth that can be manually allocated to overlay
services of each VN is 90%. At least 10% of the remaining bandwidth is reserved
for other traffic, such as protocol traffic on the underlay network.
● Traffic distribution policy name: Specify the name of a policy. Multiple traffic
distribution policies can be configured.
● VN bandwidth: Specify the bandwidth ratio of each VN or VN QoS group. For
example, the bandwidth ratios of VN1, VN2, VN_Group1, and remaining
bandwidth can be set to 30%, 20%, 30%, and 20%, respectively.
● Local breakout bandwidth ratio: Plan the local breakout bandwidth ratio if a
site accesses the Internet or communicates with a traditional site. For details,
see Bandwidth Allocation in "Data Planning and Design" in 2.2.2.1 Internet
Access and 2.2.2.2 Interworking with Legacy Sites.
● Site: Plan a site where the traffic distribution policy is applied and specify
different traffic distribution policies for different sites. One traffic distribution
policy can only be applied to one site.
Policy Behavior Template
Before configuring a traffic policy, you need to create policy behavior templates,
including the redirection and QoS policy templates. QoS policy templates are
classified into WAN policy behavior templates and LAN policy behavior templates
on different interfaces based on their functions.
For details, see Creating a Policy Behavior Template.
Traffic Classifier Template and Effective Time Template
For details, see Data Planning and Design in 2.2.2.3.2 Intelligent Traffic Steering.
QoS
To meet configuration requirements in different scenarios, two types of QoS

policies are provided: overlay network QoS and common QoS (QoS configured
based on CPEs at sites). The two types of QoS are implemented in the same
manner, and their difference lies in the application scope.
● Overlay network QoS: The same QoS policy is configured for one or more
sites in each VN. Different QoS policies can be deployed for the same site in
different VNs.
● Common QoS: QoS policies are configured based on CPEs at a site to specify
whether to apply a QoS policy to the LAN side (inbound direction) or WAN
side (outbound direction) of the CPE and specify to which interface the policy
is applied.

Table 2-8 Key configuration items of a QoS policy for the overlay network
Configuration Item Description
VN/VN QoS Group Plan service policies for sites in each VN if multiple
VNs are configured. You need to first select the VN for
which the policy needs to be configured.
Policy Name Set the QoS policy name.
Traffic Direction Set the direction in which a QoS policy is applied. A

QoS policy can be applied to the inbound or outbound
direction of an overlay network.
● WAN policy behaviors can be configured in the
inbound direction.
● Both WAN and LAN policy behaviors can be
configured in the outbound direction.
Traffic classifier Select a traffic classifier template to specify traffic to

template be matched against the QoS policy.
Policy priority Set the QoS policy priority. For the same traffic, the
QoS policy with the highest priority is preferentially
matched.
LAN Re-mark Set the DSCP value. The IP DSCP value of traffic
policy DSCP entering the CPE will be changed to this value.
behavior
Enable To view packet statistics collected before a traffic
Statistic policy is applied, enable LAN-side traffic statistics
collection and view the statistics on the CPE.
WAN Queue Set the priority of the queue into which traffic is to be
policy priority placed. The value can be Highest (LLQ queue), High
behavior (EF queue), or Medium (AF queue). After traffic is
in the placed into a queue, the guaranteed bandwidth of the
outboun queue can be assured for the traffic. Traffic that does
d not match the preceding policy enters the BE queue
direction (with a low priority).
The guaranteed bandwidth can be set to a specific
bandwidth value or a percentage. The percentage is
set based on the available bandwidth of a department
(VN). If the guaranteed bandwidth is set to a specific
bandwidth value, the value cannot exceed the
available bandwidth.
For example, if the bandwidth of a WAN interface is
100 Mbit/s and the bandwidth available to VN1 is 50
Mbit/s, value 20% of this parameter indicates that
packets matching the traffic classifier can occupy 10
Mbit/s bandwidth (50 Mbit/s x 20%).

Bandwidth Limit type:

limit ● Traffic policing discards excess traffic to limit traffic
within a proper range and to protect network
resources and enterprise users' interests. Traffic
policing is implemented using committed access
rate (CAR).
● Traffic shaping is a measure to adjust the traffic
rate sent from an interface. When the rate of an
inbound interface on a downstream device is lower
than that of an outbound interface on an upstream
device or burst traffic occurs, traffic congestion may
occur on the inbound interface of the downstream
device. Traffic shaping can be configured on the
outbound interface of the upstream device so that
outgoing traffic is sent at even rates and
congestion is avoided.
When the queue priority is set to Medium, you can
set Limit type to Shaping.
Limit bandwidth:
This parameter can be set to a specific bandwidth
value or a percentage. If this parameter is set and
traffic exceeds the specified value, excess traffic is
cached and sent later (when traffic shaping is
configured) or immediately discarded (when traffic
policing is configured). The percentage is set based on
the available bandwidth of a department (VN). If this
parameter is set to a specific bandwidth value, the
value cannot exceed the available bandwidth.
Theoretically, the bandwidth limit must be greater
than the guaranteed bandwidth.
Re-mark Specify the DSCP priority. The CPE changes the DSCP
DSCP priority in the outer IP header to this value. For details,
see DSCP re-marking.

Queue Specify the maximum number of bytes and packets

length that can be buffered in a queue.
The queue length affects queue traffic shaping,
congestion management, and congestion avoidance.
When the number of packets in a queue reaches the
maximum value or the total number of bytes in a
queue reaches the maximum value, the queue does
not receive packets. Instead, the queue discards the
excess packets.
A longer queue buffers more packets but introduces a
longer delay. If congestion occurs on a network
intermittently, buffering more packets prevents
unnecessary packet loss. If congestion always occurs
on a network, increasing the queue length cannot
solve the problem. You need to increase the
bandwidth.
The queue length can be configured only when the
queue priority is set to High or Medium.
Re-mark Re-mark 802.1p priorities of VLAN packets when you

8021P need to provide differentiated services based on the
802.1p priority of packets.
Enable Enable traffic statistics collection when you need to

Statistic view packet statistics on a CPE after a traffic policy is
applied.
Enable Re-mark the EXP priority of MPLS packets. A larger

Remark value indicates a higher priority. The value is an
Mpls Exp integer in the range from 0 to 7.
Enable Specify whether to enable a WRED drop profile to

Wred drop packets based on DSCP values.
WAN Cir Limit Limit the average rate of packets that can flow into a
policy bandwidth WAN interface. This parameter can be set to a specific
behavior bandwidth value or a percentage. The percentage is
in the set based on the available bandwidth of a department
inbound (VN). The available bandwidth cannot be exceeded
direction when this parameter is set to a specific bandwidth
value.
Pir Limit Limit the peak rate of packets that can flow into a
bandwidth WAN interface. You can set this parameter to a
specific bandwidth value or a percentage. The
percentage is set based on the available bandwidth of
a department (VN). If this parameter is set to a
specific bandwidth value, the value cannot exceed the
Effective time template Select an effective time template to specify the time
range for the QoS policy to take effect.

Site Specify the site with which the QoS policy is to be

associated. The policy takes effect only on the selected
site. A QoS policy takes effect in two modes:
● By site: The QoS policy is applied by site and takes
effect on all interfaces of the selected site.
● By link: The QoS policy is applied by link and takes
effect on one or more WAN links at the selected
site.
Table 2-9 Key configuration items of a common QoS policy

Policy Name Set the QoS policy name.
Traffic classifier Select a traffic classifier template to specify traffic to

template be matched against the QoS policy.
Policy priority Set the QoS policy priority. For the same traffic, the
QoS policy with the highest priority is preferentially
matched.
Device Select the device for which the QoS policy needs to be
configured.
LAN Interface Select the interface for which the QoS policy needs to
Name be configured.
Traffic The QoS policy can be configured only in the inbound

Direction direction.
Re-mark Set the DSCP value. The IP DSCP value of traffic

DSCP entering the CPE will be changed to this value.
Enable To view packet statistics collected before a traffic

Statistic policy is applied, enable LAN-side traffic statistics
collection and view the statistics on the CPE.
WAN Interface Select the interface for which the QoS policy needs to
Name be configured.
Traffic The QoS policy can be configured only in the

Direction outbound direction.

Queue Set the priority of the queue into which traffic is to be

priority placed. The value can be Highest (LLQ queue), High
(EF queue), or Medium (AF queue). After traffic is
placed into a queue, the guaranteed bandwidth of the
queue can be assured for the traffic. Traffic that does
not match the preceding policy enters the BE queue
(with a low priority).
The guaranteed bandwidth can be set to a specific
bandwidth value or a percentage. The percentage is
set based on the available bandwidth of a department
(VN). If the guaranteed bandwidth is set to a specific
bandwidth value, the value cannot exceed the
For example, if the bandwidth of a WAN interface is
100 Mbit/s and the bandwidth available to VN1 is 50
Mbit/s, value 20% of this parameter indicates that
packets matching the traffic classifier can occupy 10
Mbit/s bandwidth (50 Mbit/s x 20%).
Bandwidth Limit type:

limit ● Traffic policing discards excess traffic to limit traffic
within a proper range and to protect network
resources and enterprise users' interests. Traffic
policing is implemented using committed access
rate (CAR).
● Traffic shaping is a measure to adjust the traffic
rate sent from an interface. When the rate of an
inbound interface on a downstream device is lower
than that of an outbound interface on an upstream
device or burst traffic occurs, traffic congestion may
occur on the inbound interface of the downstream
device. Traffic shaping can be configured on the
outbound interface of the upstream device so that
outgoing traffic is sent at even rates and
congestion is avoided.
When the queue priority is set to Medium, you can
set Limit type to Shaping.

Limit bandwidth:
This parameter can be set to a specific bandwidth
value or a percentage. If this parameter is set and
traffic exceeds the specified value, excess traffic is
cached and sent later (when traffic shaping is
configured) or immediately discarded (when traffic
policing is configured). The percentage is set based on
the available bandwidth of a department (VN). If this
parameter is set to a specific bandwidth value, the
value cannot exceed the available bandwidth.
Theoretically, the bandwidth limit must be greater
than the guaranteed bandwidth.
Re-mark Specify the DSCP priority. The CPE changes the DSCP
DSCP priority in the outer IP header to this value. For details,
see DSCP re-marking.
Queue Specify the maximum number of bytes and packets

length that can be buffered in a queue.
The queue length affects queue traffic shaping,
congestion management, and congestion avoidance.
When the number of packets in a queue reaches the
maximum value or the total number of bytes in a
queue reaches the maximum value, the queue does
not receive packets. Instead, the queue discards the
excess packets.
A longer queue buffers more packets but introduces a
longer delay. If congestion occurs on a network
intermittently, buffering more packets prevents
unnecessary packet loss. If congestion always occurs
on a network, increasing the queue length cannot
solve the problem. You need to increase the
bandwidth.
The queue length can be configured only when the
queue priority is set to High or Medium.
Re-mark Re-mark 802.1p priorities of VLAN packets when you

8021P need to provide differentiated services based on the
802.1p priority of packets.
Enable Enable traffic statistics collection when you need to

Statistic view packet statistics on a CPE after a traffic policy is
applied.
Effective time template Select an effective time template to specify the time
range for the QoS policy to take effect.
Site Specify the site with which the QoS policy is to be

associated. The policy takes effect only on the selected
site.

NOTE
A common QoS policy cannot be configured together with a bandwidth allocation policy or
an overlay network QoS policy. That is, if a bandwidth allocation policy or overlay network
QoS policy is configured, a common QoS policy cannot be configured. If a common QoS
policy is configured, bandwidth allocation and overlay network QoS policies cannot be
configured.
2.2.2.3.4 NAT Policy

Network Address Translation (NAT) translates the IP address in an IP datagram
header to another IP address.
Huawei EVPN Interconnection Solution supports NAT policies of two types:
dynamic NAT and static NAT.
Dynamic NAT
In this type of NAT, the source IP address (a private IP address) in a packet header
is translated into a public IP address on an outbound interface to which the NAT
policy is applied.
Dynamic NAT can be implemented in three modes: Easy IP, Port Address
Translation (PAT), and No-Port Address Translation (No-PAT).
● In Easy IP mode, the IP address of the WAN interface on the router is used as
the translated public IP address. This mode is applicable to scenarios where a
small number of hosts are deployed on the intranet and the outbound
interface obtains a temporary public IP address through dial-up so that
intranet hosts can access the Internet. Easy IP translates multiple
combinations of IP addresses and port numbers into one public IP address and
port number, through which multiple users on the private network access the
Internet.
● PAT is similar to Easy IP. The difference between PAT and Easy IP lies in that
PAT specifies a public IP address pool and translates multiple combinations of
IP addresses and port numbers into the fixed public IP addresses and port
numbers in the public IP address pool. This mode is applicable to scenarios
where there are many hosts on the intranet, the outbound interfaces have
fixed public IP addresses, and multiple public IP addresses are available for
hosts on the intranet to access the Internet.
● No-PAT specifies a public IP address pool and maps one private IP address
into one public IP address, without translation of the TCP or UDP port
number. Different from Easy IP and PAT, No-PAT does not allow multiple
private network users to use the same public IP address to access the Internet.
Instead, intranet users must use different public IP addresses to access the
Internet. Therefore, this mode is seldom used.
Static NAT
In this type of NAT, the IP address of an intranet host is statically bound to one
public IP address, which can be used only by this intranet host to access the
Internet. Static NAT supports two modes: protocol translation and address
translation.

● Protocol translation refers to the process of statically binding the IP address,

protocol number, and port number of an intranet host to a combination of
the public IP address, protocol number, and port number. Multiple private IP
addresses can be bound to the same public IP address with different protocol
numbers and port numbers. Therefore, multiple intranet users can use one
public IP address to access the Internet.
● Address translation refers to the process of translating only the host IP
addresses in the specified private network range into different host IP
addresses in the specified public network range, without translation of the
protocol number and port number. One private IP address is translated into
one unique public IP address.
Static NAT can flexibly be applied to the inbound direction, outbound direction, or
both the inbound and outbound directions of an interface.
● Outbound direction: When an intranet host accesses the Internet, if the host
address is within the specified private network range, the private IP address of
the intranet host is translated into a public IP address. However, when a
public network host accesses the intranet, the host IP address is not translated
even if the host IP address is within the specified range.
● Inbound direction: When a public network host accesses an intranet host, if
the private IP address translated from the IP address of the public network
host using NAT is within the specified private network range, the public
network host can access the intranet host. However, when an intranet host
accesses the external network, the host address is not translated even if it is
within the specified range.
● Inbound and outbound directions: When an intranet host accesses the
Internet or the public network host accesses the intranet, the host address is
translated if it is within the specified address range.
NAT policies are typically used in the following scenarios:
● Intranet users access the Internet.
When an intranet user accesses the Internet, the source IP address is a private
IP address and the destination IP address is a public IP address. On the
outbound interface of the CPE, the LAN-side private IP address needs to be
translated into a public IP address. Generally, a dynamic NAT policy is used to
translate the source private IP address into a public IP address. In response
packets from the public network, the public destination IP address is
translated into a private IP address based on NAT entries generated in the
outbound direction. The response packets then are sent to intranet users.

● Internet users access intranet services.

A server is deployed on the intranet to provide services for users on the
Internet. The server uses a private IP address, which cannot be directly
accessed from the Internet. The private IP address of the server needs to be
translated into a public IP address on the CPE. When users on the Internet
access the server, the destination IP address in the packet header is the public
IP address of the server. In the inbound direction of the CPE interface, the
destination IP address in the packet header is translated into the private IP
address of the server through the static NAT policy. Packets then are sent to
the server on the LAN side. In response packets from the server, the source
private IP address is translated into a public IP address based on NAT entries.
Response packets then are sent to the Internet users. In this way, server access
is implemented.
● The intranet IP addresses of EVPN sites overlap those of legacy sites.

In such scenarios, static NAT needs to be configured to map an intranet IP
address to another unique intranet IP address. In this way, EVPN sites can
interoperate with legacy sites without changing the LAN-side user IP
addresses.

2.2.2.3.5 WAN Optimization

A growing number of enterprises use Internet links to access cloud services, data
centers, and mobile office applications, urgently requiring guaranteed Internet
service quality. Enterprise audio and video services are sensitive to delay and jitter
and vulnerable to poor network quality. Therefore, optimization of audio and
video applications is also necessary for enterprise services. Based on WAN
optimization technologies, Huawei EVPN Interconnection Solution uses built-in
application optimization functions of CPEs to improve user experience and reduce
network bandwidth costs.
Application Optimization
Huawei SD-WAN Solution uses forward error correction (FEC) technology to
perform optimization for scenarios with voice or video packet loss. FEC uses a
proxy to obtain data flows with the specified 5-tuple information, adds verification
information to packets, and performs verification at the receive end. If packet loss
or packet damage occurs on the network, the system attempts to restore packets
by decoding the verification information.
FEC is typically used in video surveillance and video conferencing scenarios.
● Video surveillance
Video surveillance is widely used. For example, for surveillance, storage, and
analysis purposes, a large number of cameras are deployed in cities and
connected to data centers, and chain enterprises use video surveillance to
send data back to the headquarters. In such scenarios, traffic of multiple sites
is aggregated to the same site, and only upstream traffic is involved. Packet
loss may occur on intermediate networks with unguaranteed quality, such as
the Internet, and will cause issues such as artifacts and frame freezing,
affecting video quality. In this case, WAN optimization can be deployed at
egresses of camera areas and data centers to ensure video quality.

● Video conferencing
Multiple sites (branches or headquarters) of an enterprise connect to the
servers in a data center. The conference server in the data center forwards
traffic between multiple sites connected to the same data center. In this
scenario, traffic is transmitted from sites to the data center and from the data
center to each site. Packet loss may occur on intermediate networks with
unguaranteed quality, such as the Internet, and will cause issues such as
artifacts and frame freezing, affecting video quality. In this case, WAN
optimization can be deployed at the egress of sites where video terminals are
deployed and the egress of the data center to mitigate packet loss and ensure
video quality.
2.2.2.4 Service Security
2.2.2.4.1 ACL-based Traffic Filtering
To control the traffic entering a CPE, you can configure ACL rules, classify packets
based on packet information including the source IP address, destination IP
address, source port number, destination port number, and application
information, and then filter packets that match the ACL rules.
In the EVPN Interconnection Solution, the ACL-based traffic filtering function is
implemented through ACL policies. Currently, ACL policies can be deployed on the
WAN or LAN interfaces of a CPE to control the traffic entering it. You can define
the priority of each ACL policy and set related parameters including the filtering
action (permit/deny) and validity time range.
ACL rules can be used to accurately identify packets on the network, and ACL
policies can be used to control the traffic entering the CPE and filter specific
traffic.
Figure 2-11 shows the typical application scenario of ACL-based traffic filtering.

Figure 2-11 Application scenario of ACL-based traffic filtering
● An ACL policy is deployed on the WAN side (1) to prevent specific traffic of
external networks from entering the CPE and the internal network.
● An ACL policy is deployed on the LAN side (2) to block specific traffic
accessing external networks. In addition, an ACL policy can be deployed
independently on each virtual network.

ACL Policy on the LAN Side (Overlay Network)
VN planning:
If multiple VNs are configured, select a VN and plan an ACL policy for the sites in
the VN.
Planning of ACL policy configuration parameters:
● Policy name: Specify the name of an ACL policy, for example,
test_bj_acl_class1.
● Traffic classifier: Plan a traffic classification rule, make a traffic classifier, and
apply the ACL policy to packets that match the traffic classification rule.
You can define local Internet access services by specifying the source and
destination IP addresses, and TCP or UDP source and destination port
numbers, or by matching the application group, VLAN ID, 802.1p priority,
source and destination MAC addresses, and Layer 2 protocol type. For details
about the traffic classifier, see the description in "Data Planning and Design"
in 2.2.2.3.2 Intelligent Traffic Steering.
● Policy priority: Specify the priority of the ACL policy. The value is in the range
from 1 to 5000 with the recommended step of 10.
If multiple ACL policies are applied to a site, the CPE matches the received
packets against the traffic classifiers in these ACL policies based on the
descending order of priority. If a match is found, the CPE performs traffic

filtering. If no match is found, the CPE continues to match the traffic classifier
in the next ACL policy.
● Interface: The value is LAN, indicating that the ACL policy of the overlay
network is applied to LAN interfaces. You do not need to specify interfaces. By
default, LAN interfaces (including Layer 3 interfaces, sub-interfaces, and
VLANIF interfaces) on the overlay network are included.
● Traffic filtering: Specify the action for traffic, which can be permit or deny.
– Deny: Packets matching a traffic classifier are not allowed to be
forwarded.
– Permit: Packets matching a traffic classifier are forwarded.
● Traffic direction: Specify whether the ACL policy takes effect on the traffic in
the inbound or outbound direction of an interface. Generally, the ACL policy
applied on a LAN-side interface takes effect on the traffic in the inbound
direction of the interface.
For a LAN-side interface, inbound traffic refers to traffic that enters a CPE
from an intranet host, and outbound traffic refers to traffic that is sent from a
CPE to an intranet host.
● Effective time template: Specify the time range in which the ACL policy takes
effect. If no time range is specified, the ACL policy takes effect at any time.
For details about the effective time template, see the description in "Data
Planning and Design" in 2.2.2.3.2 Intelligent Traffic Steering.
Planning of sites and interfaces to which the ACL policy is applied:
Specify the site where the ACL policy is to be applied. You can specify one or all
LAN-side interfaces of the selected site for which the ACL policy takes effect.
ACL Policy on the WAN Side (Underlay Network)
Planning of ACL policy configuration parameters:
● Policy name: Specify the name of an ACL policy, for example,
test_bj_acl_class2.
● Traffic classifier: Plan a traffic classification rule, make a traffic classifier, and
apply the ACL policy to packets that match the traffic classification rule.
You can define local Internet access services by specifying the source and
destination IPv4/IPv6 addresses, and TCP or UDP source and destination port
numbers, or by matching the application group, VLAN ID, 802.1p priority,
source and destination MAC addresses, and Layer 2 protocol type. For details
about the traffic classifier, see the description in "Data Planning and Design"
in 2.2.2.3.2 Intelligent Traffic Steering.
● Policy priority: Specify the priority of the ACL policy. The value is in the range
from 1 to 5000 with the recommended step of 10.
If multiple ACL policies are applied to a site, the CPE matches the received
packets against the traffic classifiers in these ACL policies based on the
descending order of priority. If a match is found, the CPE performs traffic
filtering. If no match is found, the CPE continues to match the traffic classifier
in the next ACL policy.
● Interface: The value is WAN, indicating that the ACL policy of the underlay
network is applied only to WAN interfaces.
● Traffic filtering: Specify the action for traffic, which can be permit or deny.

– Deny: Packets matching a traffic classifier are not allowed to be

forwarded.
– Permit: Packets matching a traffic classifier are forwarded.
● Traffic direction: Specify whether the ACL policy takes effect on the traffic in
the inbound or outbound direction of an interface. Generally, the ACL policy
applied on a WAN-side interface takes effect on the traffic in the inbound
direction of the interface.
For a WAN-side interface, inbound traffic refers to traffic that enters a CPE
from the WAN network, and outbound traffic refers to traffic that is sent from
a CPE to the WAN network.
● Effective time template: Specify the time range in which the ACL policy takes
effect. If no time range is specified, the ACL policy takes effect at any time.
For details about the effective time template, see the description in "Data
Planning and Design" in 2.2.2.3.2 Intelligent Traffic Steering.
Planning of sites and interfaces to which the ACL policy is applied:
Site: Specify the site where the ACL policy is to be applied. Specify a WAN link of
the site. Then, the ACL policy will be applied to the WAN interface of the site.
2.2.2.4.2 Firewall
The EVPN Interconnection Solution supports two firewall deployment schemes:
CPE's built-in firewall and third-party security devices connected through VAS.
CPE's built-in firewall
The firewall function provided by the CPE logically separates an internal network
from an external network to protect the internal network from unauthorized
access.
The firewall function involves the following two concepts:
● Security zone
A security zone consists of a single interface or a group of interfaces, and the
networks connected to these interfaces have the same security attributes.
Each security zone has a globally unique security priority.
● Interzone
Any two security zones constitute an interzone, and packets flow between
two security zones directionally (inbound and outbound). Inbound indicates
that packets are transmitted from a low-priority security zone to a high-
priority security zone, while outbound indicates that packets are transmitted
from a high-priority security zone to a low-priority security zone.
In the EVPN Interconnection Solution, the firewall function is implemented
through security policies, which are applied to the interzone. Firewall security
policies are deployed on CPEs to ensure security for Internet access services of
enterprise users and protect the internal network from unauthorized access. In
addition, the CPE provides the application specific packet filter (ASPF) function to
detect application-layer and transport-layer protocol information and dynamically
determine whether to allow packets to enter the internal network. The firewall
security policy and the ASPF function work together to provide more
comprehensive, service-based security protection for the internal network of
enterprises.

The built-in firewall of the CPE is generally used in the local Internet access
scenario. The Internet access traffic of a site is directly transmitted from the local
CPE to the Internet. The firewall function is deployed on the local CPE to ensure
security of Internet access services.
NOTE
If a site has only MPLS links for Internet access and legacy network access, the firewall
function does not take effect.
Third-party security device connected through VAS
In the EVPN Interconnection Solution, CPEs can be connected to a third-party

security device (for example, a hardware firewall) for security protection of an
enterprise's service traffic. This is a commonly used method to prevent a wide
variety of attacks on the enterprise network.
In this scenario, a hardware firewall is connected to the CPE at the headquarters

site in off-path mode when branch sites access the Internet in centralized mode.
The CPE connects to the firewall through the VAS connection function. The
firewall functions as a centralized security gateway to protect traffic of the
headquarters and branches. Figure 2-12 shows the centralized security protection
scheme.
Traffic from a branch site enters the CPE at the headquarters from the WAN side.
The CPE at the headquarters diverts the traffic to the firewall (ingress) according
to the configured route. After security protection is performed on the firewall, the
traffic is sent back to the CPE (egress) and then forwarded to the Internet through
the CPE. The return path is in a reverse order. That is, service traffic from the
Internet is forwarded by the CPE to the firewall and then forwarded back to the
CPE. The CPE then forwards the traffic to branch sites on the WAN side.

Figure 2-12 VAS-based centralized protection

If the built-in firewall needs to be deployed on the CPE, data planning listed in
Table 2-10 is required.
Table 2-10 Key configuration items of the built-in firewall on the CPE
Item
VN If multiple VNs are configured, select a VN and plan the

service policy for the sites in the VN.
Policy name Specify the name of a security policy. The value can contain
only letters, digits, underscores (_), and hyphens (-).
Internet-to-user Set the default action in the inbound direction to Permit or

default action Deny. The default action is taken for the data packets that
do not match the inbound Internet-to-user flow list. Inbound
traffic refers to traffic from a low-priority security zone to a
high-priority security zone, for example, from the untrusted
zone to the trusted zone.
Internet- Prio Specify the priority of an ACL rule. You can define multiple
to-user rity ACL rules. Packets preferentially match a rule with the
flow list highest priority. If the rule is matched, the action defined in
the rule is executed.
Acti ● Permit: Inbound packets that match the ACL rule are
on allowed to pass through.
● Deny: Inbound packets that match the ACL rule are
denied.

Item
Pro Plan the protocol type of packets matching an ACL rule. The
toc protocol can be TCP, UDP, ICMP, GRE, IGMP, IP, IPinIP, and
ol OSPF. You can also set the protocol number to specify other
protocols.
Sou Plan the source IP address of packets matching an ACL rule.

rce You can specify a host address or an address segment, or set
IP the value to any to match source IP addresses of all packets.
Sou Plan the TCP or UDP source port number of packets

rce matching an ACL rule. If this parameter is left blank, the
por source port number is not limited.
t
Des Plan the destination IP address of packets matching an ACL

tina rule. You can specify a host address or an address segment,
tion or set the value to any to match destination IP addresses of
IP all packets.
Des Plan the TCP or UDP destination port number of packets

tina matching an ACL rule. If this parameter is left blank, the
tion destination port number is not limited.
por
t
User-to-Internet Set the default action in the outbound direction to Permit or

default action Deny. The default action is taken for the data packets that
do not match the outbound user-to-Internet flow list.
Outbound traffic refers to traffic from a high-priority security
zone to a low-priority security zone, for example, from the
trusted zone to the untrusted zone.
User-to- Prio Specify the priority of an ACL rule. You can define multiple
Internet rity ACL rules. Packets preferentially match a rule with the
flow list highest priority. If the rule is matched, the action defined in
the rule is executed.
Acti ● Permit: Outbound packets that match the ACL rule are
on allowed to pass through.
● Deny: Outbound packets that match the ACL rule are
denied.
Pro Plan the protocol type of packets matching an ACL rule. The
toc protocol can be TCP, UDP, ICMP, GRE, IGMP, IP, IPinIP, and
ol OSPF. You can also set the protocol number to specify other
protocols.
Sou Plan the source IP address of packets matching an ACL rule.

rce You can specify a host address or an address segment, or set
IP the value to any to match source IP addresses of all packets.

Item
Sou Plan the TCP or UDP source port number of packets

rce matching an ACL rule. If this parameter is left blank, the
por source port number is not limited.
t
Des Plan the destination IP address of packets matching an ACL

tina rule. You can specify a host address or an address segment,
tion or set the value to any to match destination IP addresses of
IP all packets.
Des Destination port: Plan the TCP or UDP destination port

tina number of packets matching an ACL rule. If this parameter is
tion left blank, the destination port number is not limited.
por
t
Site Plan the site where firewall policies are applied.
If a third-party security device needs to be connected to the CPE for security

protection, plan the interface and routing policy for interconnection with the third-
party security device on the CPE, as described in Table 2-11.
Table 2-11 Key configuration items for connecting to a third-party security device
(VAS connection)
Config Description
uratio
n Item
VN If multiple VNs are configured, select a VN for which traffic protection

is to be performed and plan the connection configurations for the
sites in the VN.
Site Specify the site for which connections are to be configured.
Device Select a gateway to be connected. In the single-gateway scenario,

select the device that functions as the gateway. In the dual-gateway
scenario, the following situations may occur:
● Single egress: Only one gateway provides a WAN interface for
Internet access. In this case, you only need to configure
connections (including the ingress and egress directions) for this
gateway.
● Dual egresses: Both gateways provide WAN interfaces for Internet
access. In this case, you need to configure connections (including
the ingress and egress directions) on both gateways.

Config Description
uratio
n Item
Directi Two connections need to be configured for a site device: one in the
on ingress direction and the other in the egress direction.
● Ingress: Internet access traffic is sent from a site device to the
ingress interface of a third-party security device.
● Egress direction: A third-party security device processes and
forwards the traffic sent from the Internet to the site device
through the egress interface.
Access If the CPE is connected to a third-party security device through a

type: Layer 2 physical interface, set the access type to VLAN. Then,
VLAN configure the VLAN ID, tag mode, IP address, and trust mode. In each
VN, the ID of the VLAN used for communication between the devices
at a site and the third-party security device must be unique. The VLAN
ID in the ingress and egress directions cannot be the same.
● VLAN ID: The system automatically creates VLANIF interfaces
based on VLAN IDs.
● Physical interface: Plan the CPE interface for connecting to the
third-party device. The interface must be a Layer 2 interface,
including GE, FE, XGE, or Eth-Trunk.
– Eth-Trunk ID: The Eth-Trunk ID is in the range from 0 to 63. The
Eth-Trunk ID must be unique.
– Interface type: Plan a Layer 2 interface.
– Physical interface: Plan the Eth-Trunk member interfaces for
interconnection. A maximum of eight member interfaces can be
added. The Eth-Trunk member interfaces must be Layer 2
Access ● If the CPE is connected to a third-party security device through a

type: Layer 3 physical interface, set the access type to Layer 3 interface,
Layer 3 which can be a GE, FE, XGE, or Eth-Trunk interface.
interfac If an Eth-Trunk is used, you need to plan the following items:
e – Eth-Trunk ID: The Eth-Trunk ID is in the range from 0 to 63. The
Eth-Trunk ID must be unique.
– Interface type: Plan a Layer 3 interface.
– Physical interface: Plan the Eth-Trunk member interfaces for
interconnection. A maximum of eight member interfaces can be
added. The Eth-Trunk member interfaces must be Layer 3
● VLAN ID of the sub-interface: If a sub-interface is used for
interconnection, plan a VLAN ID for the sub-interface. A Dot1q
sub-interface is created on the interface, and the terminated VLAN
tag is the VLAN ID. The VLAN ID must be the same as the VLAN
tag configured on the interconnected device.

Config Description
uratio
n Item
IP Plan an IP address for the CPE's interconnection interface. The IP

address address is assigned to the specified Layer 3 interface, sub-interface, or
VLANIF interface.
Trust Plan the type of a firewall security domain to which the interface is
mode added. You can add an interface to the trust or untrust zone of the
firewall. By default, the trust zone is used. If the untrust zone is
configured, packets received by the interface need to be forwarded to
the security policy module for processing.
Static Static routes and OSPF routes can be configured in the ingress and
route egress directions. The following parameters need to be configured for
static routes:
● Destination network segment and mask: destination network
segment and mask of a static route.
● Next hop type: type of the next hop for a static route. Currently,
the next hop of a static route can only be set to an IP address.
● IP address: IP address of the next hop.
● Priority: preference of a static route. A smaller value indicates a
higher preference.
● Detection: whether to associate a static route with an NQA test
instance.
● Target: If a static route is associated with an NQA test instance,
only ICMP test instances can be used to check whether there are
reachable routes between the source and destination. This
parameter specifies the destination address of an NQA test
instance.
A route configured in the ingress direction is used to divert Internet
access traffic to a third-party security device. The destination network
segment can be set to 0.0.0.0, and the next hop can be set to the IP
address of the ingress interface on the third-party security device. For
the return path, a static route needs to be configured in the egress
direction, with the destination network segment being the address
segment of a branch site in the VN and the next hop being the IP
address of the egress interface on the third-party security device.

Config Description
uratio
n Item
OSPF Static routes and OSPF routes can be configured in the ingress and
route egress directions. The following parameters need to be configured for
OSPF routes:
● Process ID: ID of an OSPF process. The process ID of an OSPF route
used for VNF interconnection is in the range from 60000 to 61000.
● Default route advertisement flag: whether to advertise the default
route to common OSPF areas. After this function is enabled, the
device constantly advertises the default OSPF route. By default, this
function is disabled in the ingress direction and is enabled in the
egress direction. You are advised to use the default settings.
● Area ID: ID of an OSPF area.
● Authentication mode: If authentication is enabled, a neighbor
relationship can be established only when OSPF packets pass
authentication. The following authentication modes are supported:
– None: Authentication is not performed on OSPF packets.
– Simple: A password needs to be configured.
– Cryptographic: The encryption mode (MD5, HMAC-MD5, or
HMAC-SHA256), key, and password need to be configured.
For security purposes, the cryptographic mode using HMAC-
SHA256 is recommended.
2.2.2.4.3 Centralized Inter-Site Traffic Control Through the LAN-Side Firewall of

the Headquarters
To enhance network security, some enterprises require that traffic exchanged
between branches traverse the LAN-side firewall at the headquarters site to
control traffic between branches and between branches and legacy sites.
As shown in Figure 2-13, a firewall is deployed on the LAN side of the
headquarters. The redirection function is configured in the inbound direction to
divert traffic between branches or between a branch and a legacy site to the
firewall on the LAN side. The traffic is forwarded to the destination site after being
processed by the firewall.

Figure 2-13 Redirecting traffic to the LAN-side firewall
Table 2-12 Redirect policy

Parameter Description
Policy name Redirect policy name.
Device Redirect policy name delivered by iMaster NCE-Campus to the

Policy Name target device.
Device Device where the redirect policy applies.

Parameter Description
Interface Device interface where the redirect policy applies. A redirect

name policy can be configured on an EVPN tunnel interface (used for
communication between branch sites), interworking tunnel
interface (used for communication between legacy sites and SD-
WAN sites), and a LAN interface (used for forwarding LAN-side
traffic from the hub site to the LAN-side of a spoke site through
the firewall).
Interface where the redirect policy applies.
A redirect policy can be configured on the following interfaces:
● EVPN tunnel interface, used for communication between
spoke sites
● Interworking tunnel interface, used for communication
between legacy sites and SD-WAN sites
● LAN interface, used for forwarding traffic from the LAN side
of the hub site to the LAN-side of a spoke site through a
firewall
Interworking tunnel interfaces and LAN interfaces support traffic
redirection in only one direction. If both upstream and
downstream traffic need to be redirected, you need to configure
redirect policies on both of the interfaces.
Description Redirect policy description.
R Policy Priority of a rule in the redirect policy. You can configure multiple
ul priority rules with different priorities in a single redirect policy. The value
e is in the range from 1 to 5000, where a lower value indicates a
s higher priority.
T
a Traffic Traffic classifier template used to match packets that need to be
bl Classifie redirected. You can either select an existing traffic classifier
e r template from the drop-down list, or click to create a new one.
Templat In addition, you can click to view details about the traffic
e classifier template.
Policy Redirect policy behavior template used to redirect packets. You

Behavio can either select an existing redirect policy behavior template
r
Templat from the drop-down list, or click to create a new one. In
e
addition, you can click to view details about the redirect
policy behavior template.
2.2.2.4.4 Third-Party Cloud Security Gateway

To improve Internet access security, many enterprises connect their sites to third-
party cloud security gateways. This reduces security management costs and
prevents bandwidth waste and service delay caused by diverting traffic to the
centralized security gateway.

Figure 2-14 Interconnection with a third-party cloud security gateway
Currently, third-party cloud gateways can be connected through GRE tunnels. To

enhance reliability, service providers usually provide two security cloud gateways
that work in active/standby mode. If a single gateway is deployed at a site, it is
recommended that one active GRE tunnel and one standby GRE tunnel be
configured to connect to the two cloud security gateways that work in active/
standby mode. If two gateways are deployed at a site or a single gateway with
two uplink ports is deployed, you are advised to configure four GRE tunnels (two
pairs of active and standby GRE tunnels) to connect to the two cloud security
gateways.

The EVPN Interconnection Solution uses cloud security policies to configure GRE
tunnels for connecting to third-party cloud security gateways. Each cloud security
policy can define one active GRE tunnel and one standby GRE tunnel. If multiple
WAN links are available for connecting to third-party cloud security gateways,
multiple cloud security policies can be defined to specify different WAN links to
establish multiple pairs of tunnels. Table 2-13 describes the key items of cloud
security policies.
Table 2-13 Key items of cloud security policies
Site Site for which a cloud security policy is to be

configured.
Policy name Name of a cloud security policy.
Cloud security traffic Type of a cloud security traffic classifier template.

classifier template Packets matching this template are forwarded
through a GRE tunnel. In the cloud security policy
scenario, traffic classifier templates containing
advanced options or application groups cannot be
selected. For details about the traffic classifier
template, see "Data Planning and Design" in
2.2.2.3.2 Intelligent Traffic Steering.
Tunnel Device Name Name or ESN of a CPE connected to a cloud

informati (ESN) security gateway.
on

WAN link WAN link of a CPE. A WAN link can carry an active
and a standby GRE tunnel. When the active GRE
tunnel fails, traffic is switched to the standby GRE
tunnel.
Active GRE tunnel You can create tunnel interfaces on the CPE to
Tunnel source IP establish GRE tunnels to connect the CPE to a cloud
address security gateway.
GRE tunnel Source IP address of a GRE tunnel: IP address of the

destination local tunnel interface. Generally, this IP address
IP address needs to be configured based on the IP address or
IP network segment provided by the cloud security
gateway service provider.
Destination IP address of a GRE tunnel: destination
IP address of the GRE tunnel. Generally, this IP
address is provided by the cloud security gateway
service provider.
Cloud IP address of the third-party cloud security gateway

gateway IP interconnected with a GRE tunnel. Generally, this IP
address address is provided by the cloud security gateway
service provider.
GRE Key Key of the active GRE tunnel. You can configure a
GRE tunnel key on both ends of a GRE tunnel to
enhance security. This ensures that a device accepts
packets sent from only valid tunnel interfaces and
discards invalid packets. This parameter value must
be the same as that of the security cloud gateway.
GRE To enhance GRE tunnel security, you can enable the

checksum GRE checksum mechanism to perform an end-to-
end check on both ends of a GRE tunnel. This
ensures that a device accepts packets sent from
only valid tunnel interfaces and discards invalid
packets.
Standby Tunnel The standby tunnel is used to establish a GRE

tunnel with the standby cloud security gateway. The
parameters to be configured for the standby tunnel
are the same as those for the active tunnel,
including the GRE tunnel source IP address, GRE
tunnel destination IP address, cloud gateway IP
address, GRE key, and GRE checksum.
Packet MTU MTU on a tunnel interface. This parameter value

fragment takes effect on interfaces of both the active and
ation standby GRE tunnels.
MSS MSS of TCP packets on a tunnel interface. This

parameter value takes effect on interfaces of both
the active and standby GRE tunnels.

Keepalive Period (s) Interval at which a GRE tunnel sends Keepalive

packets. The default value is 5 seconds. The
unreachable counter increments by 1 every time a
Keepalive packet is sent. If the counter value
reaches the configured value of Retry Times, the
peer end is considered unreachable. This parameter
value takes effect on both the active and standby
GRE tunnels.
Retry times Number of Keepalive packets that are sent, after

which the peer end of a GRE tunnel is considered
unreachable. The default value is 3. This parameter
value takes effect on both the active and standby
GRE tunnels.
2.2.2.4.5 IPS
The intrusion prevention system (IPS) is a security mechanism that detects
intrusion behavior (such as buffer overflow attacks, Trojan horses, and worms) by
analyzing network traffic and terminates intrusion behavior in real time through
certain responses. IPS protects enterprise information systems and network
architectures against intrusions.
The IPS signature database is preconfigured on the CPE and defines common
intrusion behaviors. The IPS compares packets against the signature database. If a
match is found, the CPE considers it as an intrusion behavior and takes
corresponding prevention measures.
In the EVPN Interconnection Solution, the IPS is implemented through security
policies, which are applied to the interzone. IPS security policies are deployed on
CPEs to implement security protection for Internet access services of enterprise
users and block a variety of intrusion behaviors from the Internet.
In the EVPN Interconnection Solution, the IPS function is mainly used in the Site-
to-Internet scenario, that is, to implement security protection for Internet access
services, as shown in Figure 2-15.

Figure 2-15 Application scenarios of IPS
● Centralized Internet access scenario

In this scenario, the Internet access traffic of all sites is diverted to the
centralized Internet access site and is then forwarded to the Internet. The IPS
function is deployed on the centralized Internet access site to implement
security protection for Internet access services and block various intrusion
behaviors from the Internet.
● Local Internet access scenario
In this scenario, the Internet access traffic of all sites is directly transmitted
from the local CPE to the Internet. The IPS function is deployed on the local
CPE to implement security protection for Internet access services and block
various intrusion behaviors from the Internet.

● Policy name: Specify the name of a security policy. The value can contain only
letters, digits, underscores (_), and hyphens (-).
● IPS profile: Specify the IPS profile used by the security policy. iMaster NCE-
Campus presets multiple security profiles for different application scenarios.
The preset security profiles can be viewed or directly referenced by the IPS
profile, and cannot be modified or deleted. The following security profiles are
supported:
– strict: It contains all signatures and the action is block. It is applicable to
all protocols and all threat categories. This profile applies to scenarios
where all packets that match signatures need to be blocked.
– web_server: It contains all signatures and the default action is used. It is
applicable to the DNS, HTTP, and FTP protocols, as well as all threat
categories. This profile applies to scenarios where the device is deployed
in front of a web server.
– file_server: It contains all signatures and the default action is used. It is
applicable to the DNS, SMB, NetBIOS, NFS, SunRPC, MSRPC, file, and

Telnet protocols, as well as all threat categories. This profile applies to

scenarios where the device is deployed in front of a file server.
– dns_server: It contains all signatures and the default action is used. It is
applicable to the DNS protocol and all threat categories. This profile
applies to scenarios where the device is deployed in front of a DNS server.
– mail_server: It contains all signatures and the default action is used. It is
applicable to the DNS, IMAP4, SMTP, and POP3 protocols, as well as all
threat categories. This profile applies to scenarios where the device is
deployed in front of a mail server.
– inside_firewall: It contains all signatures and the default action is used. It
is applicable to all protocols and all threat categories. This profile applies
to scenarios where the device is deployed inside a firewall.
– dmz: It contains all signatures and the default action is used. It is
applicable to all protocols except NetBIOS, NFS, SMB, Telnet, and TFTP, as
well as all threat categories. This profile applies to scenarios where the
device is deployed in front of the DMZ.
– outside_firewall: It contains all signatures and the default action is used.
It is applicable to all protocols and all threats except Scanner. This profile
applies to scenarios where the device is deployed outside a firewall.
– default: It contains all signatures and the default action is used. It is
applicable to all protocols and all threat categories. This profile applies to
scenarios where the device is deployed in IPS (in-line) mode.
● Site: Specify the site where the IPS policy is applied.
2.2.2.4.6 URL Filtering
URL filtering regulates online behaviors by controlling URLs that users can access
and permitting or denying users' access to some web resources.
The CPE allows or denies user access to a URL or a type of URLs based on the pre-
defined categories and blacklist/whitelist. The CPE extracts the URL field from an
HTTP request packet and matches the value of this field against the blacklist/
whitelist or predefined categories. If a match is found, the CPE processes the HTTP
request packet according to the configured response action.
In the EVPN Interconnection Solution, URL filtering is implemented through
security policies, and the security policies are applied to the interzone. URL
filtering security policies are deployed on CPEs to control URLs accessed by
enterprise users.
In the EVPN Interconnection Solution, URL filtering can be applied in Site-to-
Legacy Site, Site-to-EVPN Site, and Site-to-Internet scenarios, as shown in Figure
2-16.

Figure 2-16 Application scenarios of URL filtering
● In the Site-to-Legacy Site scenario (1), URL filtering is deployed on the CPE to
regulate users' online behaviors by controlling URLs used by users to access
the legacy site.
● In the Site-to-EVPN Site scenario (2), URL filtering is deployed on the CPE to
the EVPN site.
● In the Site-to-Internet scenario (3), URL filtering is deployed on the CPE to
the Internet.

● Policy name: Specify the name of a security policy. The value can contain only
letters, digits, underscores (_), and hyphens (-).
● Policy type: Specify the action to be taken for URL filtering. After the device
queries a URL category matching an HTTP request packet, it processes the
HTTP request packet according to the action taken for the URL category. The
following policy types are supported:
– Blacklist

– Whitelist
● Blacklist/Whitelist: Add a URL filtering list.
– If a blacklist is added, URLs not in the blacklist can be accessed.
– If a whitelist is added, only URLs in the whitelist can be accessed.
● Enable pre-defined URL category: Specify the filtering level for the predefined
category and use the predefined category template of the system to perform
URL filtering. You can use the filtering level defined by the system or
customize the action for each predefined category template.
– Predefined URL filter level: The system defines high, medium, and low
filtering levels, and configures an initial action for each predefined URL
category according to each level. A high level indicates a strict action for
URL categories, for example, the device blocks requests matching porn,
P2P download, and video categories. A low level indicates a loose action
for URL categories, for example, the device blocks requests matching
porn categories only.
– Customized: Customize actions for each URL category. This method is
applicable to scenarios where URL categories need to be restricted.
● Site: Specify the site where the URL filtering policy is applied.
2.2.2.4.7 Automatic Security Policy Orchestration

In the EVPN Interconnection Solution, the firewall, IPS, and URL filtering functions
provided by the CPE are implemented through security policies. When deploying
these functions on the CPE, you need to consider the security zone planning and
the interzones to which the security policies are applied.
To implement these functions and simplify the configuration, iMaster NCE-
Campus automatically orchestrates security zones based on actual requirements in
the EVPN Interconnection Solution, as shown in Figure 2-17.

Figure 2-17 Networking diagram of automatic orchestration
The following table describes orchestration principles of security zones and

application principles of security policies applied in interzones.
Item Description
Division of security zones Zone1: trust zone (priority H)

Zone2: untrust zone (priority L)
Zone3: middle zone (priority M)
Mapping between security zones and LAN: trust zone (default). If an

interfaces Internet egress exists on the LAN, the
LAN can be configured as an untrust
zone (shown as 1 in the preceding
figure).
Overlay: middle zone
Interlink between dual gateways:
middle zone
Site-to-Internet: untrust zone
Site-to-Legacy Site: middle zone

Item Description
Security policy application in The firewall and IPS security policies

interzones are applied:
trust zone -> untrust zone
middle zone -> untrust zone
URL filtering security policies are

applied:
trust zone -> untrust zone
trust zone -> middle zone
NOTE
1. The firewall and IPS functions cannot be deployed for Site-to-Site.
2. When the same WAN link is used for Site-to-Legacy Site and Site-to-Internet (a legacy
site accesses the Internet), the link is added to a middle zone while a firewall is usually
deployed on a legacy site (shown as 2 in the preceding figure).
2.2.3 Deployment Design
2.2.3.1 Deployment Planning for Egress Devices on the WAN Side

In legacy site deployment, professional IT engineers are required to deploy devices
onsite. Misoperations may occur due to scattered devices and time-consuming
online operations, and errors may occur due to manual operations during initial
configuration. Huawei EVPN Interconnection Solution supports zero touch
provisioning (ZTP), including email-, DHCP-, USB-, and registration query center–
based deployment to solve such problems.
The following describes roles involved in the deployment and their responsibilities:
● Network administrator: plans network deployment, maintains the network,
and configures and sends a deployment email. The email must contain the
URL used to activate the deployment process. It is recommended that the
email contain instructions for deployment engineers.
● Device administrator: manages purchased devices and information about
device sites and delivered devices. The device administrator of the system
integrator performs USB-based deployment to import initial configurations
before device delivery.
● Deployment engineer (network installation or maintenance engineer) at the
site: connects terminals to gateways onsite after confirming that the
deployment email has been received, and performs email-based deployment.
Email-based deployment can be completed by onsite network installation or
maintenance engineers, eliminating the need of onsite deployment by
professional network engineers.

Deployment Planning and Procedure

1. Before the deployment, a southbound IP address needs to be planned for
iMaster NCE-Campus to ensure that CPEs can connect to iMaster NCE-
Campus through the public or private network.
iMaster NCE-Campus is deployed in the DC or HUAWEI CLOUD and translates

a private southbound IP address into a public IP address through NAT to
connect to the Internet. A CPE can access the public southbound IP address of
iMaster NCE-Campus through the Internet link. A CPE for which only MPLS
links are available connects to iMaster NCE-Campus through the private
southbound IP address reachable to the MPLS network.
2. The network administrator plans and designs the network, selects site devices,
configures the ZTP on iMaster NCE-Campus, and completes the deployment
preparations according to the deployment mode.
– Email-based deployment: After configuring the ZTP, the network
administrator needs to confirm that the deployment email has been sent
to the deployment engineer at the site.
– USB-based deployment: After configuring the ZTP, the network
administrator needs to download the ZTP deployment file and sends the
ZTP deployment file to the deployment engineer at the site.
– DHCP-based deployment: The network administrator needs to configure
DHCP Option 148 on the DHCP server to ensure that the deployment
configuration can be correctly delivered through DHCP messages.
– Deployment through the registration query center: The network
administrator needs to configure the interconnection with the registration
query center on iMaster NCE-Campus. The CPE automatically obtains a
WAN-side IP address from the DHCP server and resolves the domain
name of the registration query center through the DNS server. Then the

CPE sends a query request to the registration query center to obtain the
IP address and port number of iMaster NCE-Campus, implementing the
plug-and-play function.
3. The deployment engineer completes the deployment and checks whether the
deployment is successful onsite.
Email-based Deployment
Email-based deployment is also called URL-based deployment. After the network
administrator completes the ZTP configuration on iMaster NCE-Campus, iMaster
NCE-Campus automatically generates a deployment email. The URL parameters in
the deployment email carry the deployment information, and the deployment
email is sent to a specified deployment mailbox. After receiving the deployment
email, the deployment engineer clicks the URL in the email to start the
deployment process. Subsequently, devices automatically complete the
deployment.
Figure 2-18 Email-based deployment process
Email-based deployment is used when a CPE is installed at a site and deployment

needs to be performed onsite. Email-based deployment greatly simplifies the
operation process of a deployment engineer. The deployment engineer only needs
to start the deployment process on a web page by one click. In this way, the
deployment can be completed automatically. This does not impose requirements
on professional skills of the deployment engineer, greatly reducing the labor cost
and shortening the deployment time.
Automatic Recording of ESNs

Email-based deployment applies to the scenario where the ESN is not bound to
the CPE and is automatically recorded on iMaster NCE-Campus after deployment.
When a CPE is allocated to a site on iMaster NCE-Campus, only the CPE model is
specified but the ESN of the CPE is not specified. In this case, iMaster NCE-Campus
automatically allocates a token to the CPE when generating a deployment email
of the site. When the deployment engineer deploys the CPE, the CPE sends the
token, ESN, and other registration information to iMaster NCE-Campus for
registration. iMaster NCE-Campus then associates the CPE with the ESN based on
the token to complete the registration of the CPE that is not bound to the ESN.
USB-based Deployment
During the USB-based deployment, after the network administrator completes the
ZTP configuration on iMaster NCE-Campus, iMaster NCE-Campus automatically
generates the ZTP file that records the CPE deployment configuration. Then, the
deployment engineer uses a tool to generate a configuration file and imports the
configuration file to a USB flash drive for USB-based deployment.
Figure 2-19 USB-based deployment process
USB-based deployment is mainly used in batch deployment scenarios. The device

administrator of system integrators or enterprises uniformly imports deployment
configurations to CPEs in warehouses and distributes the CPEs for onsite
installation and deployment.

NOTE
During batch deployment using a USB flash drive, the ESN of the CPE that is distributed to
the site must be the same as the ESN of the CPE configured on iMaster NCE-Campus.
Otherwise, the deployment may fail.
DHCP-based Deployment
During DHCP-based deployment, the network administrator configures ZTP for a
site on iMaster NCE-Campus, and allocates the IP address, gateway, southbound
IP address of iMaster NCE-Campus, and port number to the WAN-side interface of
the CPE on the DHCP server. The WAN interface for deployment must apply to the
DHCP server for an IP address through DHCP. When allocating an IP address to
the CPE, the DHCP server sends iMaster NCE-Campus information to the CPE
through DHCP Option messages. After obtaining the IP address and accessing the
underlay network, the CPE automatically registers with iMaster NCE-Campus to
complete the deployment.
Figure 2-20 shows the DHCP-based deployment process.
Figure 2-20 DHCP-based deployment process
Deployment Through the Registration Query Center

During deployment through the registration query center, the network
administrator configures the interconnection with Huawei's registration query
center on iMaster NCE-Campus and configures the ZTP. The WAN interface of the
CPE at the site applies for an IP address from the DHCP server in DHCP mode. In
addition, the DNS server is used to resolve the domain name of the registration
query center. After obtaining an IP address and connecting to the underlay
network, the CPE sends a query request to the registration query center to obtain
the IP address and port number of iMaster NCE-Campus. Then, the CPE
automatically registers with iMaster NCE-Campus to complete the deployment.

This deployment mode is applicable to scenarios where iMaster NCE-Campus can

connect to the registration query center, including HUAWEI CLOUD and MSP self-
built public cloud scenarios.
Figure 2-21 shows the process of deployment through the registration query
center.
Figure 2-21 Process of deployment through the registration query center
NTP Clock Synchronization

When a CPE registers with iMaster NCE-Campus and reports performance data,
the timestamp is carried. If the time on the CPE is incorrect, the registration fails
and the time of the performance data is inconsistent with the actual time.
Therefore, NTP is configured on iMaster NCE-Campus to synchronize the time on
devices at the site.
NTP can be configured independently for each site in the following sequence:
external clock source > parent site > branch site.
On a network that requires high security, NTP authentication must be enabled.

Password authentication is configured between a client and a server to ensure
that the client only synchronizes with a server that is successfully authenticated,
improving network security.
NAT Traversal
When the EVPN interconnection network is set up, CPEs at sites may be on
different private networks. NAT devices are deployed on the WAN side to translate
private IP addresses into public IP addresses so that sites can properly access the
public network. However, when BGP is used to exchange routing information
between sites to set up an overlay tunnel, private IP addresses instead of public IP
addresses are contained in packets. As a result, tunnel establishment is affected.
Session Traversal Utilities for NAT (STUN) can effectively solve the problem.

STUN uses the client/server model and consists of the STUN server and STUN
clients. Figure 2-22 shows the typical STUN networking of the EVPN
Figure 2-22 Typical STUN networking
● STUN client: An edge site functions as a STUN client. It sends STUN binding
requests and receives STUN binding responses.
● STUN server: The RR functions as the STUN server. It sends STUN binding
responses and receives STUN binding requests.
Through packet exchange with a STUN server, a STUN client can detect a NAT
device and determine the IP address and port number allocated by the NAT
device. After a data channel is established between STUN clients, an overlay
tunnel can be established between sites.

DHCP-based deployment
● DHCP server:
During DHCP-based deployment, when configuring the DHCP server, in
addition to the information such as the IP address and gateway allocated to
the WAN interface of the CPE, the network administrator needs to configure
fields of Option 148 to transmit the iMaster NCE-Campus IP address,
southbound IP address, and port number to the CPE.
The value of Option 148 is in the following format:
agilemode=AGILEMODE;agilemanage-mode=AGILEMANAGE-
MODE;agilemanage-domain=AGILEMANAGE-DOMAIN;agilemanage-
port=AGILEMANAGE-PORT;

Table 2-14 Fields of Option 148
Item Description Value Configuration

Example
agilemode Agile mode. The value If the southbound

tradition IP address of
indicates the iMaster NCE-
traditional Campus is
mode. 10.1.1.1 and the
port number is
agilemanag Whether the Currently, this 10020, the value
e-mode agilemanage- field can be set of Option 148 is
domain field is set to only to an IP as follows:
an IP address or a address. agilemode=traditi
URL. on;agilemanage-
agilemanag Southbound IP The value of this mode=ip;agilema
e-domain address of iMaster field is an IP nage-
NCE-Campus. The address in the domain=10.1.1.1;a
CPE initiates format of x.x.x.x. gilemanage-
registration to port=10020;
iMaster NCE-Campus
through this IP
address.
agilemanag Port number used for The value of this

e-port registration with field is 10020.
iMaster NCE-
Campus.
● WAN interface: Be aware that the WAN interfaces used for DHCP-based
deployment must be Layer 3 interfaces in factory default settings and cannot
be Layer 2 interfaces whose working mode is changed to Layer 3 mode. For
details, see 4.4.4.1.4 DHCP-based Deployment
NTP Clock Synchronization
The following parameters are set for NTP clock synchronization at a site:
● Time zone
This parameter indicates the time zone to which a site gateway belongs. If
DST is observed in the time zone, you can choose whether to apply DST rules
to the time zone.
● NTP authentication
This parameter is optional and indicates whether to enable NTP
authentication when the gateway at a specified site functions as an NTP
server. If NTP authentication is enabled, you need to set the authentication
password and authentication ID. If the gateway at a specified site functions as
an NTP client, the authentication password and authentication ID must be the
same as those at the parent site of the NTP server. Otherwise, the
authentication fails and NTP clock synchronization fails.
● NTP client mode

– Manual configuration: An NTP server needs to be deployed on the

network to set the WAN link through which a site gateway accesses the
NTP server and NTP server address. If NTP authentication is enabled on
the NTP server, you can set the NTP authentication mode (MD5 or
HMAC-SHA256), authentication password, and authentication ID based
on requirements of the NTP server.
– Automatic synchronization with the parent site: The branch site
automatically synchronizes data from the aggregation site or hub site,
and the aggregation site automatically synchronizes data from the hub
site.
– Disabled: NTP clock synchronization is not performed.
NTP Server
If a site functions as an NTP client and an NTP server is manually configured, you
need to plan and deploy the NTP server on the network. If no dedicated NTP
server is available, you are advised to use FusionInsight in iMaster NCE-Campus as
the NTP server.
● IP address: IP address of the NTP server that can be accessed by the site.
● Authentication mode: If the authentication function is enabled on the NTP
server, the authentication mode on the NTP server must be MD5 or HMAC-
SHA256.
● Authentication password: authentication password required by the NTP server.
● Authentication ID: key ID for NTP authentication, which must be a number
other than 0. The authentication ID is irrelevant to the NTP server. The
authentication ID used when the site functions as a client must be different
from the authentication ID configured for the NTP server.
Email Server
● SMTP address: address of the email server used by iMaster NCE-Campus to
send emails. The email server must be accessible to iMaster NCE-Campus. You
can set an IP address or domain name, for example, [email protected].
● Port number: port number of the email server. In most cases, the port number
of the email server is 25, which must be the same as that provided by the
email server provider.
● Test email address: email address used to test whether the email server can
receive emails sent by iMaster NCE-Campus. The server with which the email
address is registered must be reachable or be an email address registered on
the email server.
2.2.3.2 Deployment Plan for Devices on the LAN Side

Table 2-15 lists the deployment modes for LAN-side devices. When AR routers are
deployed at network egresses, it is recommended that they be used as gateways
and allocate IP addresses to LAN-side devices. In addition, DHCP Option 148 needs
to be set so that LAN-side devices are registered and deployed using DHCP Option
148.

Table 2-15 Deployment modes for LAN-side devices

Deploy Description Supported Device Rec
ment Types om
Mode me
nde
d
or
Not
CloudCa The CloudCampus APP provides the Only APs Rec

mpus WLAN deployment function, including om
APP fast deployment, deployment through me
barcode scanning, and deployment nde
through the management SSID. d
Registrat After accessing the Internet, network Firewalls, switches, Rec

ion devices send a request to the and APs om
query registration query center to obtain the me
center IP address/URL and port number of nde
iMaster NCE-Campus, register with d
iMaster NCE-Campus, and go online.
Web The Internet to be accessed, cloud Firewalls, switches, Not

platform management mode, and IP and APs rec
address/URL and port number of om
iMaster NCE-Campus are configured me
on the web page. nde
d
CLI The CLI-based deployment is similar to Firewalls, switches, Not

deployment through the web platform. and APs rec
The difference lies in that devices are om
configured using the CLI through the me
console port. nde
d
DHCP If an independent upper-layer DHCP Switches and APs Rec

Option server is deployed on the campus om
148 network, you can configure the IP me
address pool and DHCP Option 148 on nde
the DHCP server. When the device to d
be deployed obtains an IP address from
the DHCP server, it also obtains the IP
address/URL and port number of
iMaster NCE-Campus to complete the
registration and online process.

2.3 Network Deployment

Context
Before deploying an EVPN interconnection network, you need to complete
network planning, including the site model, underlay network, VNs (service
isolation between multiple departments), and overlay networking and routing. For
details, see 2.2.1 Network Design.
Deployment Tasks
Task Description Procedure
Configure To use the EVPN Set the tunnel mode to EVPN.

the tunnel Interconnection Solution, set For details, see 4.4.1.6
mode. the tunnel mode to EVPN. By Configuring the Tunnel Mode.
default, iMaster NCE-Campus
uses the IPSecVPN tunnel
mode.

Configure Configure physical and virtual For details, see 4.4.3.13.1

global network parameters for WAN- Setting Global Parameters.
parameters. side network interconnection. 1. Configure the physical
For details about the global network.
parameter planning, see Data
Planning and Design. a. Configure the routing
domain.
b. Configure a transport
network. Define a unified
transport network type
for communication
between sites on the
entire network.
c. (Optional) Set IPSec
encryption parameters.
(Optional) If an IPSec
tunnel needs to be
encrypted, you need to
configure the encryption
mode and algorithm for
the IPSec tunnel.
d. Perform device activation
security configuration.
For email-based
deployment, you need to
configure the encryption
key and token validity
period.
e. (Optional) Set link
connectivity detection
parameters. To check the
link connectivity of a site,
set the link connectivity
detection parameters.
f. (Optional) Set the global
parameters for traffic
steering policies. Exercise
caution when you set the
global parameters for
traffic steering policies
because they affect the
real-time route selection
of the intelligent traffic
steering policy. You are
advised to modify these
parameters when no
service traffic is
transmitted.

g. (Optional) Configure the

default management
interface.
h. (Optional) Configure
global NTP parameters.
2. Configure the virtual
network.
a. Configure an AS number
for BGP routes.
b. Configure an address
pool.
c. (Optional) Configure the
DNS server group and IP
address.
Create sites Create a site, add devices, and 1. 4.4.3.1 Creating a Site
and add set device roles as planned. 2. 4.4.3.2 Adding Devices
devices to
the sites.
Configure Configure ZTP. In the EVPN 1. Set the WAN link template
the underlay Interconnection Solution, you for the site by referring to
network. need to configure WAN links 4.4.3.13.2 Configuring a
and activate sites before site WAN-side Site Template.
deployment. For details about 2. Set ZTP deployment
the planning of the WAN link parameters for CPEs by
template and parameters, see referring to 4.4.3.13.4
2.2.1.3.1 Site WAN Model. Configuring the Network
Access Mode for a Site.
3. Set NTP parameters for the
site by referring to
4.4.3.13.5 Configuring NTP.
4. Configure the template for
sending emails during
deployment by referring to
4.4.3.13.7 (Optional)
Customizing an Email
Template.
5. Choose Zero Touch
Provision > ZTP and click
Send Email or Download
ZTP File to activate the site.

Configure WAN interfaces and For details, see 4.4.9.1

underlay WAN routes. Configuring the Underlay
For details about WAN Network.
interface planning, see WAN 1. (Optional) Configure the
interface attributes in WAN interface.
2.2.1.3.1 Site WAN Model. 2. Configure WAN routes for
For details about WAN route the underlay.
planning for the underlay, see
Data Planning and Design.
Connect to Associate the edge site with an For details, see 4.4.3.13.8
the RR. RR site based on the planned Associating an Edge Site with
network model. an RR Site.
Configure Create a VN. If services of Create a management VN by

the overlay multiple departments of an referring to 4.4.11.2.1 Creating
network. enterprise need to be isolated VNs in LAN-WAN
from each other, multiple Interconnection Scenario.
overlay networks for EVPN
interconnection need to be
constructed through VNs.
Configure WAN services. For details, see 4.4.11.2.2

Provision VN channels for Configuring WAN Services.
interconnection between sites 1. Configure the overlay
based on the egress gateway. network topology.
For details about overlay 2. (Optional) Configure WAN
network planning, see Overlay routes for the overlay.
topology in Data Planning
and Design.
For details about overlay WAN
route planning, see Overlay
WAN route in Data Planning
and Design.
(Optional) Configure LAN For details, see 4.4.11.2.3

services. Wired and wireless Configuring LAN Services.
users are authenticated based
on the core, aggregation, and
access devices. LAN-side
services can also be configured
on a per-site basis. The
configuration method is the
same as that for a single
campus network.

Configure LAN-WAN For details, see 4.4.11.2.4

interconnection. Configure Configuring LAN-WAN
interfaces and routes between Interconnection.
the LAN-side border gateway 1. Configure LAN-WAN
and egress gateway to interconnection interfaces.
implement interconnection
between LAN and WAN 2. Configure LAN-side routes
services. for the overlay.
For details about 3. (Optional) Configure the

interconnection interface WLAN function for the
planning, see Data Planning gateway.
and Design.
For details about overlay LAN
route planning, see Overlay
LAN route in Data Planning
and Design.
2.4 Deployment
2.4.1 Deployment of Egress Devices on the WAN Side
Context
Huawei EVPN Interconnection Solution provides the following ZTP methods for
deploying egress devices on the WAN side:
● Email-based deployment: This deployment mode is recommended for

scenarios where installation and maintenance engineers need to be present at
the site to deploy CPEs.
● USB-based deployment: This deployment mode is recommended for scenarios
where the device administrator centrally processes a batch of CPEs and
deploys them in batches.
● DHCP-based deployment: This deployment mode is recommended for
scenarios where the CPE obtains the WAN-side IP address through the DHCP
server and the DHCP Option field can be set.
● Deployment through the registration query center: This deployment mode is
recommended for scenarios where iMaster NCE-Campus can be
interconnected with the registration query center (for example, HUAWEI
CLOUD). In this deployment mode, an AR router needs to obtain the WAN-
side IP address through the DHCP server and resolve the domain name of the
registration query center through the DNS server.
For details about the deployment modes and planning, see 2.2.3.1 Deployment
Planning for Egress Devices on the WAN Side.

Deployment Tasks
Task Procedure
Perform email-based Perform the following tasks as a system administrator or

deployment. an MSP administrator:
● System administrator: 4.2.1.5.4 Configuring an Email
Server
● MSP administrator: 4.3.1.4.2 Configuring an Email
Server
Perform the following tasks as a tenant administrator:
4.4.4.1.2 Email-based Deployment
Perform USB-based Perform the following tasks as a tenant administrator:

deployment. 4.4.4.1.3 USB-based Deployment
Perform DHCP- 1. Perform the following tasks as a system

based deployment. administrator:
Configure the DHCP server. Set the value of Option
148 as follows: ascii
agilemode=AGILEMODE;agilemanage-
mode=AGILEMANAGE-MODE;agilemanage-
domain=AGILEMANAGE-DOMAIN;agilemanage-
port=AGILEMANAGE-PORT.
● agilemode: device management mode. The value
tradition indicates the traditional mode.
● agilemanage-mode: whether the iMaster NCE-
Campus URL or IP address is obtained. Currently,
this field can be set only to an IP address.
● agilemanage-domain: southbound IP address of
iMaster NCE-Campus. A CPE initiates registration
to iMaster NCE-Campus through this IP address.
The value of this field is an IP address in the
format of x.x.x.x.
● agilemanage-port: port number used for
registration with iMaster NCE-Campus. The value
of this field is 10020.
2. Perform the following tasks as a tenant administrator:
4.4.4.1.4 DHCP-based Deployment
You do not need to configure the AR router to be
deployed, but ensure that the router is unconfigured,
has no console port input, and has no user login. If
the preceding conditions are met, AR routers
automatically obtain the iMaster NCE-Campus IP
address through DHCP after they are powered on and
connected to the network.

Task Procedure
Perform site 1. Perform the following tasks as a system

deployment through administrator:
the registration a. 4.2.1.5.3 Configuring the Registration Center
query center.
2. Perform the following tasks as a tenant administrator:
4.4.4.2 Deployment Through the Registration
Center
Egress AR routers must be unconfigured, have no
console port input, and have no user login. After an
egress AR router is powered on and connected to the
network, hold down the Reset button on the router
for more than 5 seconds. The AR router then
automatically accesses the registration query center
to obtain the iMaster NCE-Campus address.
NOTE
After a CPE is deployed, the site to which the CPE belongs cannot be changed. To change
the site to which the CPE belongs, perform the following operations:
1. Delete the CPE from the old site.
2. Restore the factory default settings for the CPE.
3. Add the CPE to the new site, deploy the CPE, and bring it online.
2.4.2 Deployment of LAN-Side Devices
Context
When an AR router is deployed at the network egress, it is recommended that the
AR be used as the gateway to assign IP addresses to LAN-side devices. In addition,
DHCP Option 148 needs to be set so that LAN-side devices can register with
iMaster NCE-Campus and be deployed. For details about the deployment modes
for LAN-side devices, see 2.2.3.2 Deployment Plan for Devices on the LAN Side.
Deployment Tasks
Enable the To ensure that LAN-side Enable Internet access for the
site to devices can automatically site to be deployed by referring
access the register with iMaster NCE- to Configuring an Internet
Internet. Campus and go online Access Policy for a Site.
during site deployment and
that they can access the
public network, enable the
Internet access function for
the site in the management
VN.

Configure It is recommended that LAN- For details, see "Site Deployment

LAN-side side devices be deployed > Registering Devices for
devices to through the registration Onboarding > Networking
go online. query center or DHCP Option Scenario Where an AR Serving as
148. the Egress Gateway >
Registration and Onboarding of
Devices Downstream from the
Egress Gateway" in the [Huawei
CloudCampus Solution] Small-
and Medium-Sized Campus
Network Deployment Guide.
2.5 Service Deployment

After the deployment (including basic network deployment), you can configure
interconnection services and policies such as Internet access, legacy MPLS network
access, intelligent traffic steering, QoS, and security policies. These services and
policies improve EVPN interconnection efficiency, optimize user service experience,
and ensure service security.
Deployment Tasks
Create service With the multi-VN function, Create VNs for different
VNs. the EVPN Interconnection departments based on the
Solution isolates services of service planning by referring to
multiple departments under 4.4.11.2.1 Creating VNs in
a single tenant. An LAN-WAN Interconnection
independent VN is Scenario.
configured for each service
department. For details, see
2.2.1.5 VN Service Isolation.

(Optional) If a site needs to access the Configuring an Internet

Configure Internet, configure an Access Policy for a Site
Internet Internet access policy for the
access. site. For details, see 2.2.2.1
Internet Access.
● Local Internet access
policy: Configure the site
to access the Internet
through local breakout.
● Centralized Internet
access policy: Configure
the site to access the
Internet through the
centralized Internet
gateway.
● Hybrid Internet access:
– Configure some sites to
access the Internet
through the centralized
Internet gateway and
the other sites to
access the Internet
through the local
Internet link.
– Configure certain
services of the site to
access the Internet
through the local
Internet link and the
other services to access
the Internet through
the centralized Internet
gateway.

(Optional) For details, see 2.2.2.2 Configuring a Mutual-Access

Configure Interworking with Legacy Policy for Traditional Sites
access to Sites.
legacy sites. ● Distributed local access:
Configure sites to
communicate with legacy
sites through the local
MPLS link.
● Centralized access:
Configure sites to
sites through the
gateway.
● Hybrid access: Configure
some sites to
sites through the
gateway and the other
sites to preferentially use
the local access mode to
sites.
Create an Precise identification of 1. Configuring SAC.

application applications on a network is 2. Check predefined
group. the prerequisite and basis for applications.
network services such as
intelligent traffic steering, 3. If predefined applications
QoS, application cannot meet the
optimization, and security. requirements, create
Service policies can be customized applications.
applied in subsequent service 4. Create customized
processes only after application groups.
applications are identified. a. FPI: Select a predefined
For details, see 2.2.2.3.1 or customized FPI
Application Identification. application.
b. SA: Select predefined or
customized SA
applications.

Configure Configure intelligent traffic 1. 4.4.12.1.1 Configuring a

traffic policies. steering policies. An Traffic Policy Template
intelligent traffic steering 2. Creating an Intelligent
policy automatically switches Traffic Steering Policy for
traffic between active links if the Overlay Network
congestion occurs on a link
and requirements of a
specified application cannot
be met. If active links are
unavailable, the traffic can
be switched to the escape
link. This ensures the
experience of key
applications. For details, see
2.2.2.3.2 Intelligent Traffic
Steering.
Configure QoS policies. To 1. Creating a Policy Behavior

limit the bandwidth of Template
applications or traffic, you 2. Creating a QoS Policy for
need to configure a QoS the Overlay Network
policy. For details, see
2.2.2.3.3 QoS.
Configure NAT policies. NAT Creating a NAT Policy for the

policies are configured to Underlay Network
enable internal networks Creating a NAT Policy for the
(private IP addresses) to Overlay Network
access external networks
(public IP addresses). For
details about NAT policy
planning, see 2.2.2.3.4 NAT
Policy.
Configure Configure ACL traffic filtering 1. 4.4.12.1.1 Configuring a

security policies. For details, see Traffic Policy Template
policies. 2.2.2.4.1 ACL-based Traffic 2. Creating an ACL Policy for
Filtering. the Underlay Network
3. Creating an ACL Policy for
the Overlay Network

● Configure the built-in Configure URL filtering, IPS,

firewall function of the third-party security cloud
CPE or connect the CPE to gateway, and firewall functions.
a third-party security For details, see 4.4.12.1.6
device. Firewall security Configuring a Security Policy.
policies are deployed on
CPEs or third-party
security devices are
interconnected to ensure
security for Internet
access services of
enterprise users and
protect the internal
network from
unauthorized access. For
details, see 2.2.2.4.2
Firewall.
● Configure the third-party
cloud security gateway
function. Configure a GRE
tunnel to connect the CPE
to the third-party cloud
security gateway and
divert service traffic to the
third-party cloud security
gateway. For details, see
2.2.2.4.4 Third-Party
Cloud Security Gateway.
● Configure IPS. IPS security
CPEs to implement
security protection for
Internet access services of
enterprise users and block
a variety of intrusion
behaviors from the
Internet. For details, see
2.2.2.4.5 IPS.
● Configure URL filtering.
URL filtering security
CPEs to control URLs
accessed by enterprise
users. For details, see
2.2.2.4.6 URL Filtering.

01-02 Design and Deployment Guide For The SD-WAN EVPN Interconnection Solution

Uploaded by

Copyright:

Available Formats

01-02 Design and Deployment Guide For The SD-WAN EVPN Interconnection Solution

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

01-02 Design and Deployment Guide For The SD-WAN EVPN Interconnection Solution

Uploaded by

Copyright:

Available Formats

CloudCampus Solution

2 Design and Deployment Guide for the

2.1 Design and Deployment Process

2.1 Design and Deployment Process

Issue 02 (2021-10-10) Copyright © Huawei Technologies Co., Ltd. 13

2.2 Solution Design

2.2.1 Network Design

2.2.1.1 Network Model

To exchange overlay routes between sites, customer-premises equipment (CPE)

Issue 02 (2021-10-10) Copyright © Huawei Technologies Co., Ltd. 14

● CPE: AR device deployed at the egress of the campus network.

Data Planning and Design

2.2.1.2 Global Configuration

● Physical network: routing domain, transport network, IPSec encryption, device

Data Planning and Design

Issue 02 (2021-10-10) Copyright © Huawei Technologies Co., Ltd. 15

Issue 02 (2021-10-10) Copyright © Huawei Technologies Co., Ltd. 16

● IPSec SA generation mode: By default, the IPSec SA generation mode is

Issue 02 (2021-10-10) Copyright © Huawei Technologies Co., Ltd. 17

Issue 02 (2021-10-10) Copyright © Huawei Technologies Co., Ltd. 18

The addresses to be configured include tunnel interface IP addresses, interworking

Issue 02 (2021-10-10) Copyright © Huawei Technologies Co., Ltd. 19

2.2.1.3 Site Model

2.2.1.3.1 Site WAN Model

Site WAN Model Planning

Issue 02 (2021-10-10) Copyright © Huawei Technologies Co., Ltd. 20

Table 2-2 Default link templates provided by iMaster NCE-Campus

Single Single Internet (Device1, -

Issue 02 (2021-10-10) Copyright © Huawei Technologies Co., Ltd. 21

Templ Templa WAN Link (Device, Inter-CPE Topology

Single Single MPLS (Device1, -

Single Single Internet (Device1, -

Single Single Internet1 (Device1, -

Dual_ Dual Internet (Device1, Device1:

Data Planning and Design

Issue 02 (2021-10-10) Copyright © Huawei Technologies Co., Ltd. 22

● Basic information such as the site location

WAN link template

Issue 02 (2021-10-10) Copyright © Huawei Technologies Co., Ltd. 23

details about the transport network data planning in global

● Interfaces connecting the two gateways

Issue 02 (2021-10-10) Copyright © Huawei Technologies Co., Ltd. 24

▪ Eth-Trunk: Specify two interfaces for interconnecting with each other

▪ Layer 2 direct link: Similar to the situations of Layer 3 links, if only

▪ LAN-side Layer 2 links: If a Layer 2 link is available between a CPE

WAN link parameter configuration (ZTP)

Issue 02 (2021-10-10) Copyright © Huawei Technologies Co., Ltd. 25

Issue 02 (2021-10-10) Copyright © Huawei Technologies Co., Ltd. 26

● Public IP address (This parameter needs to be set only for RR sites.)

Issue 02 (2021-10-10) Copyright © Huawei Technologies Co., Ltd. 27

2.2.1.3.2 Site LAN Model

Figure 2-2 Layer 2 interconnection on the LAN side

1. Single CPE: The CPE connects to STAs through Wi-Fi.

Issue 02 (2021-10-10) Copyright © Huawei Technologies Co., Ltd. 28

Layer 3 Interconnection Scenario

Currently, only firewalls support static routing.

Figure 2-3 Layer 3 interconnection on the LAN side

In the Layer 3 interconnection scenario, if only one gateway is deployed, only a

Data Planning and Design