Solution Design

CloudCampus Solution
Design and Deployment Guide for Large- and

Medium-Sized Campus Networks (Virtualization
Scenario) 2 Solution Design
2 Solution Design
2.1 Networking Solution Selection

2.2 Centralized Gateway Solution Design
2.3 Distributed Gateway Solution Design
2.4 Multi-Campus Fabric VXLAN Interconnection Solution Design
2.1 Networking Solution Selection

On large and midsize campus networks, the virtualization solution is classified into
the centralized gateway solution and distributed gateway solution based on the
user gateway location. You can select a gateway solution when creating a fabric
on iMaster NCE-Campus. In the centralized gateway solution, a border node
functions as the gateway of all users, and all inter-subnet traffic is forwarded by
the border node. In the distributed gateway solution, the border node and
multiple edge nodes function as user gateways, and inter-subnet traffic is
forwarded through the edge nodes, as shown in Figure 2-1.
Issue 01 (2022-11-17) Copyright © Huawei Technologies Co., Ltd. 17

Figure 2-1 Inter-subnet traffic forwarding between different edge nodes in the
two gateway solutions
When designing the virtualization solution, first determine the gateway solution to
be used. After the gateway solution is determined, you can perform end-to-end
design on the entire campus network based on the selected gateway solution.
Table 2-1 compares the two gateway solutions, and Table 2-2 provides their
recommended networking and application scenarios.
NOTE
The centralized gateway solution supports only one border node, whereas the distributed
gateway solution supports multiple border nodes.
Table 2-1 Comparison of two gateway solutions
Item Centralized Gateway Distributed Gateway
User Border node Wired user gateways are on edge

gatewa nodes, and wireless user gateways
y are on the border node.
locatio
n
O&M The border node functions as the User gateways are deployed on
deploy gateway of all users, and the edge nodes, and the native WAC
ment native WAC function is typically function is typically enabled on the
enabled on the border node to border node to support wireless
support wireless services. services.

Table 2-2 Recommended networking planning for the two gateway solutions
(WAC)
Num Nu Sol Networking Characteristics
ber mb uti Solution
of er on
Ter of Sel
min Du ecti
als al- on
Sta
ck
Ter
mi
nal
s
Sin 30,0 0 Pref Centralized VXLAN 1. User traffic is centrally

gle 00 erre gateway + native processed by the border node,
- d WAC (border node) posing high requirements on the
sta border node performance and
ck low requirements on the
sce performance of other devices.
nar 2. Fault locating is easier in the
io centralized VXLAN gateway
solution.
3. The highly-integrated native
WAC saves installation spaces
and is easy to deploy. Tunnel
forwarding is recommended in
the native WAC scenario.

Num Nu Sol Networking Characteristics

ber mb uti Solution
of er on
Ter of Sel
min Du ecti
als al- on
Sta
ck
Ter
mi
nal
s
> 0 Pref Distributed VXLAN 1. The pressure on the control

30,0 erre gateway + and forwarding planes is shared
00 d standalone WAC by multiple gateways. This
(connected to the networking solution is suitable
border node in off- for ultra-large campuses and
path mode) provides good network
performance.
2. Dual border nodes can be
deployed in the distributed
VXLAN gateway solution, where
services are not interrupted
during upgrade of core switches,
ensuring high reliability.
3. Standalone WACs are
connected to the core switch
and reduce the pressure on the
core switch, supporting better
wireless roaming in tunnel
forwarding mode.
NOTE
To ensure host routes are
synchronized across the network,
make sure edge devices have
sufficient entry specifications.
Sin 10,0 10, Pref Centralized VXLAN The characteristics are the same
gle 00 00 erre gateway + native as those of the preceding
- 0 d WAC (border node) centralized VXLAN gateway +
sta native WAC solution.
ck
an > > Pref Distributed VXLAN The characteristics are the same
d 10,0 10, erre gateway + as those of the preceding
du 00 00 d standalone WAC distributed VXLAN gateway +
al- 0 (connected to the standalone WAC solution.
sta border node in off-
ck path mode)
sce
nar
io

Networking solution selection description:

● On an ultra-large campus network, the distributed gateway solution is
preferred to ensure better network performance. (Influencing factors: the
number of gateway routes, DHCP relay message forwarding, IP-security group
entry synchronization, host routing table synchronization, and automatic
onboarding through PnP negotiation)
● Standalone WACs are preferred. On smaller campus networks, the native WAC
function can be used. (Influencing factors: concurrent authentication of
terminals, wireless data forwarding, roaming, and AP management functions
such as calibration)
● Tunnel forwarding is recommended for wireless traffic so that wireless users
can have better inter-edge roaming experience.
● In actual projects, VXLAN deployed across core and aggregation layers is
adopted the most.
● The table above lists only recommended solutions. You can upgrade the
solutions above, including using standalone WACs to replace the native WAC,
and using distributed VXLAN gateway networking to replace centralized
VXLAN gateway networking. Solution downgrade (reverse adjustment) is not
recommended.
2.2 Centralized Gateway Solution Design
2.2.1 Overall Design
2.2.1.1 General Guidelines
2.2.1.1.1 Basic Design Guidelines

As a network infrastructure, campus networks provide users with network
communications services and resource access rights. Complicated access
relationships and diversified service types pose the needs for good design ideas
and guidelines. The following design guidelines apply to campus network design:
● Reliable: Campus networks must run stably and reliably without service
interruptions, ensuring service experience. This requires a redundant or
backup architecture for key components that can be used to quickly recover
from faults.
● Trustworthy: Campus networks must be secure and trustworthy to guarantee
network and service security. This requires comprehensive security protection
measures to prevent malicious damages, protecting data and network
security.
● Scalable: Campus networks must be able to be smoothly upgraded and
expanded to meet service requirements in the next 3 to 5 years, fully create
network values, reduce investment, and avoid waste of resources. This
requires for on-demand deployment of new services and smooth network
expansion.

● Manageable: Campus networks must be easy to manage, maintain, and

perform network diagnosis and fault locating, reducing the O&M difficulty
and improving customer experience. This requires intelligent, proactive, and
integrated management of multiple services over the entire network, real-
time network health analysis, proactive prevention, and fast fault locating to
reduce losses.
● Operational: Campus networks must support flexible deployment of new
services, such as Voice over Internet Protocol (VoIP), Unified Communications
(UC), Telepresence, and desktop cloud.
● Economic: The return on investment (ROI) should be maximized and the
investment costs should be reduced.
2.2.1.1.2 Device Naming Conventions

It is recommended that a device name consist of multiple fields to accurately
describe the physical location and role of the device on the campus network, as
shown in Figure 2-2. To prevent a long device name, the abbreviation of each
field is used, for example, A_B-4F_CSW_HW_S12700E-12_a.
Figure 2-2 Example of a device name
Table 2-3 Device naming conventions

Ide Description
ntif
ier
A Name of a campus site.
B Physical location of a device on a campus network. Generally, the location

is in the format of equipment room name + floor.
C Role of a device on a campus network.
D Device brand. For example, HW in the example indicates Huawei.
E Device model.
F Device number, which can be listed in alphabetical order or ascending

order.
2.2.1.1.3 Interface Description Conventions

It is recommended that the description command be configured for physical
interfaces to help you learn about interface connections. It is recommended that
the description contain three parts, as shown in Figure 2-3.

Figure 2-3 Example of an interface description
Table 2-4 Interface description conventions

Ide Description
ntif
ier
A Direction of a local connection, for example, an interface connected to a

downstream device.
B Name of a peer device.
C Interface of the peer device.
2.2.1.2 Network Architecture Design
2.2.1.2.1 Virtual Campus Network Architecture Overview

On a large or midsize campus network, the virtualization solution can be used to
decouple services from the network, construct a multi-purpose network, and
achieve flexible, fast service deployment without changing the basic network
infrastructure. In this solution, the virtual campus network architecture poses
requirements different from those on traditional network architecture. Figure 2-4
illustrates the virtual campus network architecture. The underlay is the physical
network layer, and the overlay is the virtual network layer constructed on top of
the underlay based on the Virtual Extensible LAN (VXLAN) technology.

Figure 2-4 Virtual campus network architecture
The overlay consists of the fabric and VN.

● Fabric: a network with pooled resources abstracted from the underlay
network. When creating an instantiated virtual network (VN), you can select
the pooled network resources on the fabric.
On a fabric network, VXLAN tunnel endpoints (VTEPs) are further divided into
the following roles:
– Border: border node of the fabric network. It corresponds to a physical
network device and provides data forwarding between the fabric and
external networks. Generally, VXLAN-capable core switches function as
border nodes.
– Edge: edge node of the fabric network, which corresponds to a physical
network device. User traffic enters the fabric network from the edge
node. Generally, VXLAN-capable access or aggregation switches are used
as edge nodes.
● VN: logically isolated virtual network instances (VN 1 and VN 2 in the figure)
that are constructed by instantiating a fabric. One VN corresponds to one
isolated network (service network), for example, R&D network.
Table 2-5 lists the resource pools on a fabric and how to invoke these resources
during VN creation.

Table 2-5 Resource pools on a fabric and resource invoking methods during VN
creation
Resource Pool on a Fabric How to Invoke Resources in a
Resource Pool During VN Creation
VN resource pool, which contains the Each time a VN is created, a VN

number of VNs that can be created on resource is used.
an overlay.
VLAN resource pool, which is used in When creating a user gateway in a

scenarios where terminals are VN, you can select a resource from the
connected to VNs and VNs fabric global resource pool to
communicate with external network configure a user VLAN.
resources. The VLAN resource pool is
planned when configuring the fabric
global resource pool.
BD/VNI resource pool, which is used When a user gateway is created in a

when dividing Layer 2 broadcast VN, resources in the BD/VNI resource
domains in a VN and configuring pool are automatically invoked to
corresponding VBDIF interfaces that create a BD and the corresponding
function as the gateway interfaces of VBDIF interface.
user subnets. The BD/VNI resource
pool is planned when configuring the
fabric global resource pool.
User access point resource pool, which When configuring user access in a VN,
is planned during access management you can select planned access point
configuration for a fabric. This resource resources.
pool includes the authentication
modes that can be bound to access
points.
Egress pool, which contains the When creating a VN, you can select
external resources that can be used by external networks and network service
VNs. Two types of external resources resources.
are created during fabric configuration:
● External networks: used for VNs to
communicate externally
● Network service resources: used for
VNs to communicate with the
authentication server and DHCP
server
2.2.1.2.2 Underlay Network Architecture Design

In the virtualization solution for large- and medium-sized campus networks, the
physical network uses the network planning for traditional large- and medium-
sized campus networks, and typically adopts a tree-type network architecture with
the core layer as the root. This type of architecture features stable topology and is
easy to expand and maintain. As illustrated in Figure 2-5, the campus network is
composed of the access layer, aggregation layer, and core layer, as well as some

functional zones. Modules in each functional zone are clearly defined, and the
internal adjustment of each module is limited to a small scope, facilitating fault
location.
Figure 2-5 Physical network in the virtualization solution for large- and medium-
sized campus networks
In office, education, and hospitality scenarios, central switches and remote units
(RUs) are deployed together to build simplified all-optical campus networks. The
three-layer networking (core, aggregation, and access) for ELV rooms is changed
to the two-layer (core and aggregation) networking. At the access layer, RUs are
deployed to enable access to the desktop. The three-layer networking is also
supported, where access switches function as central switches and RUs are
connected to the access switches.

Figure 2-6 Simplified all-optical networking topology for large and midsize
campus networks
Table 2-6 Physical network layers and functional zones

Na Description
me
Ter The terminal layer involves various terminals that access the campus
min network, such as PCs, printers, IP phones, mobile phones, and cameras.
al
laye
r
RU On a simplified all-optical campus network, RUs need to work together

with central switches and can be remotely deployed on desktops.
Acce The access layer provides various access modes for users and is the first
ss network layer to which terminals connect. The access layer is usually
laye composed of access switches. There are a large number of access
r switches that are sparsely distributed in different places on the network.
In most cases, an access switch is a simple Layer 2 switch. If wireless
terminals are present at the terminal layer, wireless access points (APs)
need to be deployed at the access layer and access the network through
access switches.
On a three-layer simplified all-optical campus network, access switches
are deployed as central switches to manage the connected RUs.
Agg The aggregation layer sits between the core and access layers. It
rega forwards horizontal traffic (east-west traffic) between users and forwards
tion vertical traffic (north-south traffic) to the core layer. The aggregation
laye layer can also function as the switching core for a department or zone
r and connect the department or zone to a dedicated server zone. In
addition, the aggregation layer can further extend the quantity of access
terminals.
On a two-layer simplified all-optical campus network, aggregation
switches are deployed as central switches to manage the connected RUs.

Na Description
me
Core The core layer is the core of data exchange on a campus network. It
laye connects to various components of the campus network, such as the DC/
r network management zone, aggregation layer, and campus egress. The
core layer is responsible for high-speed interconnection of the entire
campus network. High-performance core switches need to be deployed
to meet network requirements for high bandwidth and fast convergence
upon network faults. It is recommended that the core layer be deployed
for any campus with more than three departments.
Egre The campus egress is the boundary that connects a campus network to
ss an external network. Internal users of the campus network can access
net the external network through the campus egress zone, and external
wor users can access the internal network through the campus egress zone.
k Firewalls need to be deployed in the campus egress zone to provide
perimeter security protection.
DC In the DC zone, service servers such as the file server and email server
zon are managed, and services are provided for internal and external users.
e
Net The network management zone is the server zone where the O&M and
wor management systems are deployed. In the virtualization solution for
k large- and medium-sized campus networks, the following systems are
man deployed:
age ● iMaster NCE-Campus: campus network automation engine. It is used
men to provision service configurations for network devices; provides open
t APIs for integration with third-party platforms; and can function as an
zon authentication policy server to deliver authentication, authorization,
e accounting (AAA) and free mobility services.
● iMaster NCE-CampusInsight: intelligent campus network analytics
engine, which provides intelligent O&M services by utilizing Telemetry,
big data, and intelligent algorithms.
● DHCP server: dynamically assigns IP addresses to user clients.
DM The demilitarized zone (DMZ) provides access services with strictly

Z controlled security for external guests (personnel other than the
enterprise employees). Public servers are usually deployed in the DMZ.
Hierarchical Physical Network Architecture Planning

In practice, you can flexibly select the two-layer or three-layer architecture for the
physical network based on the network scale or service requirements, as shown in
Figure 2-7.
The campus network involving one building usually uses the two-layer
architecture, that is, only the access layer and aggregation layer are required. A
large-scale campus network (such as a university campus network) that involves
multiple buildings usually uses the three-layer architecture that consists of the
access, aggregation, and core layers.

Figure 2-7 Hierarchical physical network architecture
During network design, you can use the bottom-up method to determine the
layered architecture depending on the network scale, as illustrated in Figure 2-8.
Figure 2-8 Layered network architecture design

NOTE
In the preceding calculations, the calculation results need to be rounded up.
2.2.1.2.3 Egress Network Architecture

Routers and firewalls need to be deployed in the campus egress zone. Routers
enable communication between internal and external networks, whereas firewalls
provide border security protection. To ensure reliability, routers and firewalls are
deployed in redundancy mode. Device redundancy at the egress is recommended
for large- and medium-sized campus networks.
Figure 2-9 shows three networking models depending on whether routers need to
be deployed. In networking 1, routers function as the egress devices with firewalls
connected in in-path mode. In networking 2, firewalls function as the egress
devices in in-path mode. In networking 3, routers function as the egress devices
with firewalls connected in off-path mode.
Figure 2-9 Egress network topologies
On a large or midsize campus network, the number of routes on the egress is

small (usually less than 1,000 routes). Therefore, the routing table size of the
router does not need to be considered. To reduce network construction costs,
networking 2 is recommended. That is, firewalls function as egress devices.
If one of the following conditions is met, networking 1 can be used:
● Egress link type
If the carrier deploys non-Ethernet links (such as EI, CE1, and CPOS) in the
egress zone, it is recommended that networking 1 be used and routers be
deployed as egress devices because they support more port types than
firewalls.
● Port quantity and density
Egress devices are connected to not only the Internet but also enterprise
branches or partners through leased lines. In this scenario, considering that
routers can provide more interfaces with higher density, it is recommended
that networking 1 be used and routers be deployed as egress devices.
● Protocol type
If egress devices and external networks run a dynamic routing protocol (for
example, BGP) or work in SD-WAN scenarios, it is recommended that

networking 1 be used and routers function as egress devices. This is because

routers provide a large routing table size and high performance and multiple
routing policies need to be deployed on egress devices.
● QoS
If QoS policies need to be deployed on egress devices, it is recommended that
networking 1 be used and routers be deployed as egress devices. This is due
to the powerful QoS functionality on routers.
● Network traffic
To reduce the impact on live network traffic or ensure security for only some
services, networking 3 is recommended, where firewalls are deployed in off-
path mode.
2.2.1.2.4 Hierarchical Architecture of the Intranet

On a large or midsize campus network, the three-layer or two-layer architecture
can be flexibly selected based on the network scale or service requirements, as
illustrated in Figure 2-10.
architecture, that is, only the access layer and core layer are required. A large-scale
campus network (such as a university campus network) that involves multiple
buildings usually uses the three-layer architecture that consists of the access,
aggregation, and core layers.
During network design, you can use the bottom-up method to determine the type
of architecture required based on the network scale, as shown in Figure 2-11.

● Determine the number of interfaces on access switches based on the network

scale. Generally, one interface corresponds to one terminal or one network
access point (for example, AP).
● Select switches based on the interface rate of terminal network adapters.
● Calculate the number of access switches. If the calculation result is greater
than 1, aggregation switches need to be deployed. Otherwise, use the single-
layer architecture. Number of access switches = Number of access interfaces/
Downlink interface density of an access switch
● Select aggregation switches based on the uplink interface rate of access
switches.
● Calculate the number of uplinks of an access switch using either of the
following methods:
– Based on the network bandwidth: Number of uplinks = Network
bandwidth/Uplink interface rate of an access switch
– Based on the network scale: Number of uplinks = Number of access
interfaces x Access interface rate x Bandwidth convergence ratio/Uplink
interface rate of an access switch
NOTE

● Calculate the number of aggregation switches. If the number is greater than
1, select the three-layer architecture. Otherwise, use the two-layer
architecture. Number of aggregation switches = Number of uplinks of access
switches/Downlink interface density of an aggregation switch

2.2.1.2.5 Overlay Network Architecture Design

The overlay network architecture design is to design the fabric network. As
demonstrated in Figure 2-12, a fabric network can adopt a two-layer or three-
layer network architecture based on physical network layers. The three-layer
network architecture supports two VXLAN networking types: VXLAN deployed
across core and aggregation layers and VXLAN deployed across core and access
layers.
Figure 2-12 Fabric networking
In the centralized gateway solution, different fabric networking types can be

selected based on the following campus network scenarios:
● Campus network reconstruction: VXLAN is recommended to be deployed

across core and aggregation layers. In such scenario, existing low-end access
switches that do not support VXLAN can be used.
● New campus network deployments: VXLAN is recommended to be deployed
across core and access layers. In such scenario, virtualization can be deployed
on the entire network to implement automatic overlay deployment.
2.2.1.3 Network Resource Planning
2.2.1.3.1 VLAN/BD Planning
BD Resource Planning
In a VN, a Layer 2 broadcast domain is constructed based on bridge domains
(BDs). In a BD, user terminals in different geographical locations can communicate
with each other. In the virtualization solution for large- and medium-sized campus
networks, BD resource planning guidelines are as follows:
● 1:1 mapping between BDs and user service VLANs is recommended, as shown
in Figure 2-13.
● In a VN, each time a VXLAN user gateway is created, a BD is automatically
invoked from the global BD resource pool of the fabric in sequence. You do
not need to consider how to divide a BD. Instead, you only need to consider
how to assign user service VLANs.

● BD resources in the BD resource pool must be sufficient to support user

service VLAN assignment.
Figure 2-13 Association between a BD and a service VLAN
VLAN Resource Planning

In the virtualization solution for large- and medium-sized campus networks, a
large Layer 2 broadcast domain can be constructed based on BDs. However, user
terminals still connect to campus networks through VLANs, and the VLANs are
bound to BDs. In addition, campus networks need to be interconnected through
VLANs. The virtualization solution for large- and medium-sized campus networks
complies with the VLAN planning guidelines of traditional campus networks:
● Assign VLANs based on service zones.
● Assign a VLAN to each service type.
● Allocate consecutive VLAN IDs to ensure proper use of VLAN resources.
● Reserve a specific number of VLANs for future use.
VLANs are classified into management, interconnection, and service VLANs. For
details about the design suggestions, see Table 2-7.

Table 2-7 VLAN resource planning recommendations

Cate Recommendations
gory
Man A management VLAN is used to manage network devices on the campus

age network. The following describes the management VLAN planning for
men network devices at different layers and in different functional zones:
t ● Servers in the network management zone: If the network is not a
VLA data center network and has a small number of servers, it is
N recommended that all servers be added to the same management
VLAN.
● Switches in the network management zone: If the network is not a
data center network and has a small number of switches, you are
advised to use physical management interfaces to manage these
switches, removing the need to plan a management VLAN.
● Egress network devices: You are advised to use Layer 3 service
interfaces as management interfaces, removing the need to plan a
management VLAN.
● Core switches: You are advised to plan a separate management VLAN
and use the VLANIF interface of the management VLAN as the
management interface. iMaster NCE-Campus manages core switches
through the management interface.
● Devices below the core layer: You are advised to plan one or more
management VLANs based on the device scale and use the VLANIF
interface of the management VLAN as the management interface.
iMaster NCE-Campus manages devices through the management
interface.
– If a small number of devices are deployed, it is recommended that
all aggregation switches, access switches, and APs use the same
management VLAN.
– If a large number of devices are deployed, it is recommended that
all aggregation switches and access switches use the same
management VLAN and all APs use the same management VLAN.
– If a large number of devices are deployed, you are advised to plan
device groups based on network layers. Each device group uses the
same management VLAN. For example, each aggregation switch
and its connected downstream devices are grouped into a device
group and use the same management VLAN.

Cate Recommendations
gory
Inter In the virtualization solution for large- and medium-sized campus

conn networks, VLANs are required for interconnection on both the underlay
ectio and overlay networks.
n ● Underlay network: involves the VLAN for interconnection between
VLA core switches and the network management zone (in most cases, the
N interconnection VLAN is the management VLAN of core switches),
VLAN for interconnection between egress devices and other devices,
and VLAN for interconnection between devices at the core layer and
lower layers (used for automatic OSPF route orchestration).
● Overlay network: involves the VLAN for interconnection between the
core switches functioning as border nodes and external networks and
the VLAN for interconnection between border nodes and network
service resources.
Servi Assign VLANs based on logical areas, organizational structures, and

ce service types.
VLA ● Assign VLANs based on logical areas. For example, VLANs 200 to 999
N are used in the server zone, and VLANs 2000 to 3499 are used on the
access network.
● Assign VLANs based on organizational structures. For example,
department A uses VLANs 2000 to 2499, and department B uses
VLANs 2500 to 2999.
● Assign VLANs based on service types. For example, employees in
department A use VLANs 2000 to 2099, and dumb terminals in
department A use VLANs 2100 to 2199.
NOTE
In 2.2.7 Access Control Design, if policy association is required between the authentication
control point and authentication enforcement point, you need to plan a management VLAN
for policy association to establish a Control and Provisioning of Wireless Access Points
(CAPWAP) tunnel between the authentication control point and authentication
enforcement point.
2.2.1.3.2 IP Address Planning

IP address planning should comply with the following guidelines:
● Uniqueness: Each host on an IP network must have a unique IP address. Even

if the Multiprotocol Label Switching (MPLS) or Virtual Private Network (VPN)
is used, it is recommended that different virtual routing and forwarding (VRF)
instances use different IP addresses.
● Contiguousness: Node addresses of the same service must be contiguous to
facilitate route planning and summarization. Contiguous addresses facilitate
route summarization, reducing the size of the routing table and speeding up
route calculation and convergence. An aggregation switch may connect to
multiple network segments. When allocating IP addresses, ensure that routes

of these network segments can be summarized to reduce the number of

routes on core devices.
● Scalability: IP addresses need to be reserved for devices at each layer. When
the network is expanded, no address segments or routes need to be added.
● Easy maintenance: Device and service address segments need to be clearly
distinguished from each other, facilitating subsequent statistics collection,
monitoring and security protection based on address segments. If an IP
address is planned properly, you can determine the device to which the IP
address belongs. IP address planning and VLAN planning can be associated.
For example, the third byte of an IP address can be the same as the last three
digits of a VLAN ID, which is easy to remember and facilitates management.
● It is recommended that internal hosts on a campus network use private IP
addresses, and NAT devices be deployed at the campus egress to translate
private IP addresses into public IP addresses so that internal hosts can access
public networks. A few devices in the DMZ and the Internet zone use public IP
addresses.
IP addresses on a campus network include management IP addresses,
interconnection IP addresses, service IP addresses, and loopback interface
addresses, as shown in Table 2-8.
Table 2-8 IP address planning recommendations

Categor Recommendation
y
Manage Used for communication with iMaster NCE-Campus or for a local

ment IP login. It is recommended that devices in the same management
address VLAN use IP addresses on the same IP address segment. The
management IP addresses of network devices at different layers and
in different functional zones are planned as follows:
● Management IP addresses of servers in the network management
zone, which are configured on the iBMC management interface
● Management IP addresses of switches in the network
management zone
● Management IP addresses of egress devices. It is recommended
that a service interface be used as the management interface,
removing the need to plan the management interface separately.
● Management IP addresses of core switches
● Management IP addresses of devices below the aggregation layer

Categor Recommendation
y
Intercon An interconnection address is the IP address of an interface

nection connected to another device's interface. It is recommended that the
IP IP address with a 30-bit mask be used as an interconnection address.
address A core device uses a smaller IP address. An interconnection address
is usually summarized and advertised. During IP address planning,
consider the use of contiguous IP addresses that can be summarized.
In the virtualization solution for large- and medium-sized campus
networks, IP address interconnection is required on both the
underlay and overlay networks.
● Underlay network: includes the IP addresses for interconnection
between core switches and the network management zone, IP
addresses for interconnection between egress devices and other
devices, and IP addresses for interconnection between devices at
the core layer and devices at lower layers (for automatic OSPF
route orchestration). Generally, an interconnection VLANIF
interface is the management VLANIF interface of a core switch.
● Overlay network: includes the IP addresses for interconnection
between the core switches functioning as border nodes and
external networks and IP addresses for interconnection between
the core switches functioning as border nodes and network
service resources.
Service A service address is the IP address of a server, service terminal, or

IP gateway. You are advised to use the same last digits as the gateway
address address. For example, gateways use IP addresses suffixed by .254.
The IP address range of each service must be clearly distinguished.
The IP addresses of each type of service terminals must be
contiguous and can be summarized. Considering the scope of a
broadcast domain and easy planning, it is recommended that an
address segment with a 24-bit mask be reserved for each service. If
the number of service terminals exceeds 200, an extra address
segment with a 24-bit mask is assigned.
Loopbac A loopback interface address is often specified as the source address

k of packets to improve network reliability. The virtualization solution
interface for large- and medium-sized campus networks uses the VXLAN
address technology. The control plane of VXLAN uses BGP EVPN for
interaction, requiring loopback interfaces to be used to establish BGP
peer relationships between VTEPs (border or edge nodes).
NOTE
control point and authentication enforcement point, you need to plan a management VLAN
for policy association to establish a CAPWAP tunnel between the authentication control
point and authentication enforcement point.

2.2.1.3.3 DHCP Planning

DHCP function is required for management subnet design during device
deployment and for user subnet design in a VN, as shown in Figure 2-14.
Figure 2-14 Application scenario for DHCP
DHCP Planning for the Management Subnet

A large or midsize campus network often has a large number of devices below the
core layer. During device deployment, you are advised to plan a DHCP server
dedicated to management address allocation of devices. DHCP planning for the
management subnet is as follows:
● It is recommended that a core switch be used as the DHCP server of the
management subnet and an IP address pool be configured on the gateway
interface of the management subnet.
● Configure DHCP Option 148 to contain iMaster NCE-Campus address
information.
● If the gateway interface of the management subnet also functions as the
gateway interface of the AP management subnet, you are advised to
configure DHCP Option 43 to contain WAC address information.
DHCP Planning for the User Subnet

It is recommended that a separate DHCP server be planned for large- and
medium-sized campus networks to allocate IP addresses to user terminals. DHCP
planning for the user subnet is as follows:
● It is recommended that a DHCP server be planned for the entire campus
network to simplify O&M.
● In most cases, the DHCP server and hosts on a large or midsize campus
network are on different network segments. You are advised to enable the
DHCP relay function on user gateways.

● You are advised to configure DHCP snooping in the BD where a user gateway
belongs to ensure that user terminals obtain IP addresses from a valid DHCP
server and prevent attacks. In addition, if DHCP options are used for terminal
identification, DHCP snooping also needs to be configured.
● In dynamic IP address allocation provided by DHCP, the lease period of IP
addresses needs to be planned based on the online duration of user terminals.
In large- and medium-sized campus networks, the online duration of user
terminals in the office area are long, so a long lease period needs to be
planned for IP addresses of these user terminals.
If a fixed IP address needs to be allocated to a specific user terminal, this IP
address must be excluded from the DHCP address pool during DHCP address
pool planning. This is to prevent this IP address from being allocated.
2.2.1.4 Routing Protocol Planning

In the virtualization solution for large- and medium-sized campus networks,
routing protocols need to be deployed on both the underlay and overlay networks
to implement different Layer 3 interconnection requirements, as shown in Figure
2-15. Table 2-9 describes the scenarios where routing protocols need to be
deployed on the underlay and overlay networks and routing protocol planning.
Figure 2-15 Routing protocol planning in the virtualization solution for large- and
medium-sized campus networks

Table 2-9 Routing protocol planning in different scenarios of the virtualization

solution for large- and medium-sized campus networks
Routi Route Planning in Different Description
ng Scenarios
Protoc
ol
Deplo
yment
Scena
rio
1. ● Routing protocols are used for

Comm communication between
unicati iMaster NCE-Campus and
on network devices to implement
betwe configuration, management,
en the and intelligent O&M on these
netwo devices.
rk ● If the network management
manag zone is a simple network where
ement software systems such as
zone iMaster NCE-Campus are
and installed, you are advised to
device configure static routes on the
manag gateway in the network
ement management zone and the
subnet core switch.
● If the network management
zone is a data center, you need
to flexibly configure routes for
the gateway in the network
management zone and the
core switch based on the
routing protocol used by the
data center network.


ng Scenarios
Protoc
ol
Deplo
yment
Scena
rio
2. ● Routing protocols are mainly

Comm used for Layer 3
unicati communication on the
on underlay network as the basis
betwe for overlay network
en deployment.
core, ● Routing tables can be
aggreg dynamically updated based on
ation, the network topology.
and Therefore, it is recommended
access that an IGP, such as OSPF, be
switch planned. It is recommended
es that OSPF routes be
automatically orchestrated
through iMaster NCE-Campus,
removing the need to manually
configure routes.
● Automatic OSPF route
orchestration enables devices
to import the network
segments of BGP source
interfaces (such as loopback
interfaces) into the OSPF
routing domain so that the
BGP source interfaces can
communicate with each other.
3. ● In most cases, BGP is deployed

Comm between border and edge
unicati nodes and between edge
on on nodes. BGP EVPN is used to
the implement functions on the
VXLAN VXLAN control plane, including
control dynamic VXLAN tunnel
plane establishment, ARP entry
transmission, and routing
information transmission.
● It is recommended that a
border node be configured as a
route reflector (RR) to simplify
BGP peer configuration.


ng Scenarios
Protoc
ol
Deplo
yment
Scena
rio
4. ● Routing protocols are used on

Inter- a border node for
VN communication between
comm different user subnets of VNs.
unicati ● Different user subnets of VNs
on can also communicate with
each other through firewalls.
● To implement such
communication on a border
node, configure the border
node through iMaster NCE-
Campus. After the
configuration is complete, the
border node uses BGP to
import routes to user subnets
between VRF instances of
different VNs.


ng Scenarios
Protoc
ol
Deplo
yment
Scena
rio
5. ● Routing protocols are used by

Comm devices on user subnets of a
unicati VN to access the Internet and
on WANs.
betwe ● If two firewalls implement HSB
en a using VRRP, one as the VRRP
VN master and the other VRRP
and an backup, static routes are
extern recommended between the
al firewall and border node. If
netwo VRRP is not deployed on
rk firewalls, dynamic routes need
to be used between the firewall
and border node. During
active/standby firewall
switchover, dynamic routes can
be used to implement
automatic switching of the
service traffic paths.
● On the border node, you can
create external network
resources for the fabric through
iMaster NCE-Campus and
configure an interface and
routing protocol for
interconnection with the
firewall.
After the VN selects external
network resources, the border
node imports routes between
the VRF instance of the
external network resources and
the VRF instance of the VN.
● You can log in to the web UI or
CLI of the firewall to configure
the firewall.


ng Scenarios
Protoc
ol
Deplo
yment
Scena
rio

Comm communication between user
unicati subnets in a VN and network
on service resources such as the
betwe DHCP server and network
en a access control (NAC) server.
VN ● Static routes are recommended.
and
the ● Network service resources of
netwo the fabric are created for the
rk border node through iMaster
manag NCE-Campus. During the
ement creation, the interface for
zone connecting the border node to
the network management zone
is configured, and a static route
to the network service
resources is automatically
created.
After a VN selects a network
service resource, the border
network service resource and
CLI of a gateway in the
network management zone to
configure the gateway.
2.2.2 iMaster NCE-Campus Installation Planning

Flexible installation of iMaster NCE-Campus can be provided based on project
requirements. For details about the installation planning and design of iMaster
NCE-Campus, see section "Installation".
2.2.3 Underlay Network Design
2.2.3.1 Network Management Zone Design

If an independent data center equipment room is present on a large or midsize
campus network, software systems such as iMaster NCE-Campus can be directly

installed on servers in the equipment room. During the installation, make sure
that the egress gateway can communicate with the campus intranet. This section
describes the basic server networking design for communication between these
software systems and the campus intranet.
● A stacked Layer 3 switch functions as the server gateway and is directly

connected to software servers and the core switch cluster.
● iMaster NCE-Campus and iMaster NCE-CampusInsight use the minimum
cluster size and two network planes.
● On the stacked Layer 3 switch, VLANs are created to isolate all network
planes on the servers. The gateway interface of each network plane is the
VLANIF interface of the given VLAN.
Figure 2-16 Basic networking of the network management zone
Server and Gateway Interconnection Design

To ensure network reliability, multiple NICs are bonded on servers, which are
connected to the server gateway through one bonded interface. NIC bonding
modes include active-backup and load balancing. The configurations for
connecting servers to their gateway vary slightly in the two modes.
Active-backup mode
In this mode, one NIC interface in the bonded interface is in the active state, and
the other is in the backup state. All data is transmitted through the active NIC
interface. In the event of a failure on the link corresponding to the active NIC
interface, data is transmitted through the backup NIC interface. In this case, the

Layer 3 switch functioning as the server gateway connects to the two NIC
interfaces on a server through two physical ports. The physical ports do not need
to be aggregated, and are recommended to be added to the VLAN of the
corresponding network plane in access mode. As shown in Figure 2-17, add
physical ports (GE1/0/1 and GE2/0/1) on the switch to VLAN 100 using the
following commands.
Figure 2-17 Server-switch interconnection in active-backup mode
<Switch> system-view
[Switch] vlan batch 100
[Switch] interface gigabitethernet 1/0/1
[Switch-GigabitEthernet1/0/1] port link-type access
[Switch-GigabitEthernet1/0/1] port default vlan 100
[Switch-GigabitEthernet1/0/1] quit
Load balancing mode

In this mode, multiple NICs of a server transmit data packets based on the
specified hash policy. To enable server-switch interconnection, you need to
configure an Eth-Trunk interface in manual mode on the Layer 3 switch
functioning as the server gateway, connect the Eth-Trunk interface to the bonded
interface on the server, and then add the Eth-Trunk interface to the VLAN of the
corresponding network plane in access mode. As shown in Figure 2-18, add Eth-
Trunk 1 on the switch to VLAN 100 using the following commands.

Figure 2-18 Server-switch interconnection in load balancing mode
<Switch> system
[Switch] interface eth-trunk 1
[Switch-Eth-Trunk1] trunkport gigabitethernet 1/0/1 2/0/1
[Switch-Eth-Trunk1] port link-type access
[Switch-Eth-Trunk1] port default vlan 100
[Switch-Eth-Trunk1] quit
Design for Communication Between the Network Management Zone and

Campus Intranet
network management zone needs to communicate with the device management
subnet on the underlay network and the user subnet on the overlay network. This
is to ensure that each software system can manage devices on the campus
intranet and communicate with the user subnet to implement a service function.
Table 2-10 lists the common software systems that need to communicate with
the campus intranet in this solution.
Table 2-10 Description for communication between common software systems

and the campus intranet
Communicatio Software Description

n Type System
Communicatio iMaster NCE- Manages devices on the campus intranet,

n with the Campus and configures and provisions services.
device Devices need to interconnect with iMaster
management NCE-Campus.
subnet on the
underlay iMaster NCE- Performs intelligent O&M on the campus
network CampusInsight intranet. Devices need to interconnect with
iMaster NCE-CampusInsight and report
performance data to it.
Communicatio iMaster NCE- Functions as the NAC server for user access
n with the user Campus authentication. The user subnet must be
subnet on the able to communicate with iMaster NCE-
Campus.


n Type System
overlay DHCP server Dynamically assigns IP addresses to user

network terminals. The user subnet must be able to
communicate with the DHCP server.
The network management zone adopts the basic networking design, the topology
between the gateway in the network management zone and the core switch
cluster is stable, and only a few network segments are required for
communication. If this is the case, you are advised to configure static routes
cluster. As illustrated in Figure 2-19, the planning of static routes is as follows:
● Two VLANIF interfaces are separately planned on the gateway in the network
management zone as well as on the core switch. One (VLANIF 500 in the
figure) is used for communication between the network management zone
and the device management subnet on the underlay network, and the other
(VLANIF 600 in the figure) for communication between the network
management zone and the user subnet on the overlay network.
● For communication between the network management zone and the device
management subnet on the underlay network:
– On the core switch: Configure a static route destined for the network
management zone. The destination network segment is the network
segment where the software systems (for example, iMaster NCE-Campus
and iMaster NCE-CampusInsight in the figure) that need to communicate
with the device management subnet resides. The next hop of the static
route is the IP address of VLANIF 500 on the gateway in the network
management zone.
– On the gateway in the network management zone: Configure a route
destined for the device management subnet on the underlay network.
The destination network segment is the device management network
segment, and the next hop is the IP address of VLANIF 500 on the core
switch.
● For communication between the network management zone and the user
subnet on the overlay network:
– On the core switch: When creating network service resources for a fabric,
configure the IP addresses of the connected network service resources as
well as the VLANs and IP addresses for interconnecting with the gateway
in the network management zone on the core switch that functions as
the border node. After the configuration is complete, the core switch
imports routes between the virtual routing and forwarding (VRF) instance
that represents the network service resource and the VRF instance that
represents a VN. In addition, the core switch creates a private static route
destined for the network management zone in the VRF instance that
represents the network service resource. The destination network
segment of this static route is the network segment where the software
system that needs to communicate with the user subnet resides, such as
iMaster NCE-Campus or the DHCP server in the figure.

– On the gateway in the network management zone: Configure a static

route destined for the user subnet on the overlay network. The
destination network segment is the user network segment, and the next
hop is the IP address of VLANIF 600 on the core switch.
Figure 2-19 Planning for communication between the network management zone
2.2.3.2 Deployment Design
Deployment Configuration Mode Planning

Table 2-11 lists the network devices involved in the virtualization solution for a
large or midsize campus network and the recommended deployment
configuration modes.

Table 2-11 Recommended deployment configuration modes for different network

devices
Loc Device Recommended Description
atio Deployment
n Configuration
Mode
Net Switch Local CLI or web Generally, you need to configure the
wor (gateway in system switch before installing software
k the network systems in the network
man management management zone.
age zone)
men
t
zone
Egre Firewall Local CLI or web Generally, firewalls are deployed in

ss system a core equipment room and have
net complex service configurations.
wor Therefore, local configuration is
k recommended.
Core Core switch Centralized Generally, core switches are

laye configuration on deployed in a core equipment room.
r iMaster NCE- After a core switch goes online on
Campus after iMaster NCE-Campus through the
going online on CLI, it can be used as the root
it through the device of management subnets
CLI below the core layer to implement
plug-and-play of devices below the
core layer.
● Native Local CLI or web Generally, WACs are deployed in a

WAC, which system core equipment room to manage
is APs in a centralized manner. After a
integrated WAC goes online on iMaster NCE-
in the core Campus through the CLI, you can
switch switch to the WAC CLI or web
● Standalone system through iMaster NCE-
WAC, which Campus and configure wireless
is services.
connected
to the core
device in
off-path
mode


atio Deployment
n Configuration
Mode
Agg Aggregation Centralized A large number of aggregation

rega switch configuration on switches are deployed at scattered
tion iMaster NCE- locations. You are advised to
laye Campus onboard aggregation switches on
r iMaster NCE-Campus through DHCP
to implement plug-and-play
deployment.
Acce Access switch Centralized A large number of aggregation

ss configuration on switches are deployed at scattered
laye iMaster NCE- locations. You are advised to
r Campus onboard aggregation switches on
iMaster NCE-Campus through DHCP
deployment.
AP Centralized Generally, the "WAC + Fit AP"

configuration on architecture is used for the WLAN of
the WAC a large or midsize campus network
and APs are managed by the WAC
in a centralized manner. A large
number of APs are deployed at
scattered locations. You are advised
to onboard APs on the WAC
through DHCP to implement plug-
and-play deployment.
Management VLAN Communication Design for Devices Below the Core

Layer Plug-and-Play for the First Time
On a large or midsize campus network, you are advised to deploy devices below
the core layer in plug-and-play mode through DHCP to onboard aggregation and
access switches on iMaster NCE-Campus and APs on the WAC. Management VLAN
communication is critical for onboarding devices below the core layer. The
following methods are available:
Using default VLAN 1 as the management VLAN
As shown in Figure 2-20, the process for devices below the core layer to go online
on iMaster NCE-Campus using the default VLAN 1 is as follows:
1. The core switch goes online on iMaster NCE-Campus through the CLI. If a
standalone WAC is used, it also goes online on iMaster NCE-Campus through
the CLI.
2. On iMaster NCE-Campus, configure VLANIF 1 on the core switch as the
gateway interface of the management subnet, configure a DHCP address
pool, and configure DHCP Option 148 to carry the southbound address of
iMaster NCE-Campus and DHCP Option 43 to carry the WAC address.

3. By default, all interfaces on a device are added to VLAN 1 before delivery.

Therefore, devices at the core, aggregation, and access layers can
communicate with each other in VLAN 1. If a standalone WAC is used, the
core switch can also communicate with the standalone WAC through VLAN 1.
4. APs obtain the WAC address through DHCP Option 43. After APs are
associated with the WAC and VLANIF 1 is configured as the CAPWAP source
interface, APs successfully join the WAC.
Figure 2-20 Using default VLAN 1 for plug-and-play deployment of devices below
the core layer
Using an auto-negotiated management VLAN
If VLAN 1 is used as the management VLAN, broadcast storms may occur. To avoid
this, you can enable management VLAN auto-negotiation to configure another
VLAN as the management VLAN. In addition, wired and wireless devices can share
an auto-negotiated management VLAN or use separate auto-negotiated
management VLANs.
● Wired and wireless devices sharing an auto-negotiated management

VLAN
If the number of wireless APs is small, wired and wireless devices can share an
auto-negotiated management VLAN. As demonstrated in Figure 2-21, assume
that VLAN 100 is the auto-negotiated management VLAN. The process for
devices below the core layer to go online on iMaster NCE-Campus is as
follows:

a. The core switch goes online on iMaster NCE-Campus through the CLI. If a
standalone WAC is used, it also goes online on iMaster NCE-Campus
through the CLI.
b. On iMaster NCE-Campus, configure VLANIF 100 on the core switch as the
pool, and configure DHCP Option 148 to carry the southbound IP address
of iMaster NCE-Campus and DHCP Option 43 to carry the WAC address.
c. Configure the core switch as the root device and use the management
VLAN auto-negotiation function to enable management VLAN
communication for devices below the core layer. The process is as follows:
i. On iMaster NCE-Campus, enable the management VLAN auto-
negotiation function on the core switch and configure VLAN 100 as
the auto-negotiated management VLAN.
ii. After the core switch is configured, aggregation switches
automatically add their interfaces to VLAN 100 through protocol
packet auto-negotiation.
iii. After the management channels between the core and aggregation
switches are established, access switches automatically add their
interfaces to VLAN 100 through protocol packet auto-negotiation. In
addition, access switches' interfaces connected to APs change the
PVID to VLAN 100 through auto-negotiation.
d. The aggregation and access switches obtain the southbound address of
iMaster NCE-Campus through VLAN 100 and go online on iMaster NCE-
Campus.
e. APs obtain the WAC address through DHCP Option 43. After APs are
associated with the WAC and the CAPWAP source interface is configured,
APs successfully join the WAC.

Figure 2-21 Wired and wireless devices using the same auto-negotiated
management VLAN for plug-and-play deployment
● Wired and wireless devices using different auto-negotiated management

VLAN
If a large number of APs are deployed, and wired and wireless devices share
the same management VLAN, broadcast storms may probably occur. To avoid
this, you can plan an auto-negotiated management VLAN for the wired and
wireless devices, respectively. As shown in Figure 2-22, VLAN 4080 is used as
the auto-negotiated management VLAN for wired switches, and VLAN 4081
as the auto-negotiated management VLAN for wireless APs. The switches and
APs go online through their respective auto-negotiated management VLAN. In
this case, when the downstream interface of an access switch identifies an
access AP, the PVID is changed to the auto-negotiated management VLAN for
wireless devices (APs) through auto-negotiation, but not changed to the auto-
negotiated management VLAN for wired devices (switches).

Figure 2-22 Wired and wireless devices using different auto-negotiated

management VLAN for plug-and-play deployment
Management VLAN Switching Design After Devices Below the Core Layer Go
Online
Sometimes, there are a large number of network devices on a campus network.
After these devices go online in plug-and-play mode for the first time, broadcast
storms may still occur even if an auto-negotiated management VLAN is planned
separately for wired and wireless devices. In this case, you are advised to plan
multiple management VLANs. After devices go online in plug-and-play mode for
the first time, switch the management VLAN to isolate the broadcast domains of
these devices.
You are advised to plan device groups based on network layers, with each device
group assigned one management VLAN. For example, each aggregation switch
and its connected downstream devices are grouped into one device group and use
the same management VLAN, as illustrated in Figure 2-23.

Figure 2-23 Management VLAN switching planning
Note: Before switching the management VLAN, add the interconnection interfaces
on the core switch and devices below the core layer to the new management
VLAN. In this way, devices below the core layer will not fail to go online due to
communication failures with the core switch on the new management VLAN.
iMaster NCE-Campus-based Deployment Process Design

On a large or midsize campus network, there are a large number of switches and
APs. Two iMaster NCE-Campus-based deployment roadmaps apply to this
scenario, as shown in Figure 2-24. It is recommended that the administrator plan
the network first, import planning information to iMaster NCE-Campus, and then
configure device onboarding modes for deployment. This reduces the deployment
workload. If the network cannot be planned in advance, the administrator can
onboard devices and then determine the network topology.

Figure 2-24 iMaster NCE-Campus-based deployment process for switches and APs
Onboard devices and then determine the network topology

In this mode, configure device information such as ESNs on iMaster NCE-Campus
first, bring devices online, and then configure physical links. If these devices need
to be connected through aggregated links (Eth-Trunks), you can manually create
such links. The process of deploying switches and APs in this mode is as follows:
1. Create a site that represents the campus network.
2. Enter device ESNs to add devices to this site. Enter AP ESNs and associate APs
with the WAC on iMaster NCE-Campus.
3. Configure device management to bring devices online.
– Connect the core switch to iMaster NCE-Campus through the CLI.
– Deploy aggregation and access switches in plug-and-play mode through
DHCP and bring them online on iMaster NCE-Campus.
– Deploy APs in plug-and-play mode through DHCP and bring them online
on the WAC.
Set up required switch stacks in advance, add the stacks to this site, and
synchronize information such as stack IDs and priorities. Stacks can be
manually configured before device management or added to a site by active
detection of iMaster NCE-Campus after device management.
4. After devices go online, you can manually create Eth-Trunk interfaces on
iMaster NCE-Campus as required if aggregated links (Eth-Trunk) are needed
for interconnection between the devices.
Import the network plan and then onboard devices
In this mode, you can plan the network first and then import the planned basic
network information, including device ESNs, stack information, and Eth-Trunk

information, to iMaster NCE-Campus in a batch using a network plan import

template. In this way, the network topology can be pre-configured, reducing the
deployment workload. The process of deploying switches and APs in this mode is
as follows:
2. Fill in the network plan import template to import the following device, stack,
and link information to this site in a batch.
– Switch and AP information, including device ESNs, models, and roles
– Switch stack information, including stack system names, stack IDs, and
priorities
– Switch Eth-Trunk information, including the upstream and downstream
switch names, upstream and downstream physical member port
numbers, and upstream and downstream Eth-Trunk interface names
During the import, iMaster NCE-Campus automatically enables the Eth-
Trunk auto-negotiation function for the downstream Eth-Trunk interfaces
preconfigured on switches.
on the WAC.
After the switches go online, iMaster NCE-Campus automatically delivers the
imported Eth-Trunk preconfiguration to them and performs Eth-Trunk auto-
negotiation. Once the Eth-Trunk auto-negotiation is successful, the
management VLAN is automatically renegotiated. Finally, the aggregation
and access switches come back online on iMaster NCE-Campus through Eth-
Trunks.
2.2.3.3 Automatic Intranet Route Orchestration Design

The virtualization solution for large- and medium-sized campus networks supports
the automatic underlay route orchestration function. With this function, iMaster
NCE-Campus can automatically configure OSPF routes, divide OSPF areas, and
deliver interface configurations for access to core layer based on the physical
network topology. The physical network topology is imported to iMaster NCE-
Campus based on the configuration plan or automatically learned by iMaster
NCE-Campus.
Automatic underlay route orchestration falls in to single-area orchestration and
multi-area orchestration, as shown in Figure 2-25.

Figure 2-25 Automatic underlay route orchestration
When there are fewer than 100 switches in a network area where routes need to
be deployed on the underlay network, single-area orchestration is recommended.
● All switches between the border and edge nodes on the fabric support
automatic orchestration of OSPF routes. These devices refer to all aggregation
and core switches if VXLAN is deployed across the core and aggregation
layers, and refer to all core, aggregation, and access switches if VXLAN is
deployed across the core and access layers.
● All switches between the border and edge nodes on the fabric are planned in
area 0.
● Different VLANIF interfaces are planned on all switches for interconnection
through OSPF. The interconnected Layer 2 interfaces allow packets from the
corresponding VLANs to pass through.
● When configuring a fabric, you need to create loopback interfaces on the
switches that function as border and edge nodes for establishing BGP EVPN
peer relationships. Routes on the network segments where the loopback
interface IP addresses reside are also advertised to area 0.
When there are more than 100 switches in a network area where routes need to
be deployed on the underlay network, multi-area orchestration is recommended.
● The core switch is planned in area 0. Each downlink VLANIF interface on the
core switch, as well as the aggregation and access switches connected to
these VLANIF interfaces are planned in the same area.
through OSPF. The interconnected Layer 2 interfaces are added to the
corresponding VLANs in trunk mode.

● On the core switch that functions as a border node, routes on the network
segment where its loopback interface IP address resides are advertised to area
0. On an edge node, routes on the network segment where its loopback
interface IP address resides are advertised to the area to which the edge node
belongs.
● If a Layer 2 switch is required for interconnection between the border and
edge nodes and performs transparent transmission between them, this Layer
2 switch cannot be the aggregation switch. (When adding a switch to a site
on iMaster NCE-Campus, you can set the switch role.) You can select Core or
Regional aggregation as the switch role. After the automatic OSPF route
orchestration function is enabled, interfaces connecting this Layer 2 switch to
the border and edge nodes allow packets from the corresponding VLAN to
pass through.
2.2.3.4 Loop Prevention Design for the Underlay Network

physical architecture of the underlay network is a loop-free tree topology with the
core switch being the root bridge. However, network loops, such as those caused
by incorrect cable connections, still exist on the live network. Network loops lead
to broadcast storms and instability of MAC address tables. As a result,
communication on the network may deteriorate or even be interrupted.
Switches employ multiple protocols, such as rapid spanning tree protocol (RSTP),
multiple spanning tree protocol (MSTP), and VLAN-based spanning tree (VBST), to
detect loops on the network and block certain interfaces to trim the ring topology
into a loop-free tree topology. Furthermore, if an active link fails and a redundant
link exists, RSTP, MSTP, or VBST activates the redundant link to ensure network
connectivity.
underlay network is large in scale. Therefore, when deploying loop prevention
protocols such as RSTP, MSTP, and VBST, you need to consider the convergence
time and impact scope so as to perform loop prevention design accordingly.
Design Guidelines
In the virtualization solution for large- and medium-sized campus networks, to
reduce the impact of topology changes on the entire network, you are advised to:
● Select a device with higher reliability as the root bridge.
● Divide the entire underlay network into multiple loop detection domains.
Figure 2-26 shows the underlay network in a virtualization scenario on a large or
midsize campus. When no loop exists between core and aggregation switches, the
loop prevention design can be implemented as follows:

Figure 2-26 Loop prevention design on an underlay network
1. Disable the loop prevention function, such as STP, on the interconnection

interfaces between core and aggregation switches.
2. To minimize the impact of topology changes, add core switches to a single
loop detection domain, and add each aggregation switch and its connected
access switches to multiple loop detection domains.
3. Configure the core and aggregation switches as the root bridges of their
respective loop detection domains to reduce the probability of root bridge re-
election.
NOTE
● When a loop exists between core and aggregation switches, do not disable the loop
prevention function between them. You can only configure the core switch as a root
bridge to improve root bridge robustness.
● Currently, the controller allows you to increase the priority of core or aggregation
switches so that they can be preferentially selected as root bridges.
● To perform VLAN-based loop prevention design for inter-VLAN load balancing, see the
MSTP or VBST design in the switch product documentation.
2.2.4 Overlay Network Design
2.2.4.1 Overlay Network Overview

An overlay network consists of the fabric and multiple virtual networks (VNs). A
fabric is a network on which all resources are pooled. These resources can be
selected as required during VN creation, decoupling the overlay network from the
underlay network. Creating a VN is equivalent to creating an instance on the
fabric. One VN instance can represent a virtual network dedicated to one type of
service.
For details about concepts related to the overlay network, see 2.2.1.2.5 Overlay
Network Architecture Design.

2.2.4.2 Overlay Network Resource Planning

VLAN/BD resources of the overlay network are planned in the fabric global
resource pool. Table 2-12 lists the resource items to be planned. For details about
VLAN/BD planning, see "VLAN/BD Planning" in 2.2.1.3 Network Resource
Planning.
Table 2-12 VLAN/BD resource plan for the fabric global resource pool
Reso Description
urce
Item
Broa ● Layer 2 broadcast domains are isolated in a VN. Generally, one-to-

dcast one mapping is configured between BDs and user service VLANs.
dom ● The planned BD resource pool needs to accommodate the number of
ain user service VLANs. By default, the value ranges from 1 to 4095.
(BD)
Servi ● User terminals access the campus network through service VLANs,
ce which are bound to BDs.
VLA ● You are advised to assign service VLANs based on logical areas,
N organizational structures, and service types of campus networks.
Inter ● When creating external network resources on a fabric, configure

conn interconnection VLANs to interconnect with an egress network.
ectio ● When creating network service resources on a fabric, configure
n interconnection VLANs to interconnect with a network management
VLA zone.
N

Only IP addresses of loopback interfaces need to be planned in the fabric global
resource pool. Other IP addresses on an overlay network do not need to be
planned. Table 2-13 lists the IP address resource items to be planned for an
overlay network. For details about IP address planning, see "IP Address Planning"
in 2.2.1.3 Network Resource Planning.
Table 2-13 IP address plan for the fabric global resource pool
Resource Description
Item
Loopback Configure loopback interface IP addresses to establish BGP EVPN

interface peer relationships between border and edge nodes, which also
IP address function as the VXLAN tunnel endpoints (VTEPs).

Item
Service IP ● Configure IP addresses of servers, service terminals, and

address gateways.
● You are advised to use the same last digits as the gateway
address. For example, gateways use IP addresses suffixed by .
254.
● The IP address range of each service must be clearly
distinguished. The IP addresses of each type of service terminals
must be contiguous and can be summarized.
● Considering the scope of a broadcast domain and easy planning,
it is recommended that an address segment with a 24-bit mask
be reserved for each service. If the number of service terminals
exceeds 200, an extra address segment with a 24-bit mask is
assigned.
Interconn ● When creating external network resources on a fabric, configure

ection IP interconnection IP addresses to interconnect with an egress
address network.
● When creating network service resources on a fabric, configure
interconnection IP addresses to interconnect with a network
management zone.
2.2.4.3 Fabric Network Design
2.2.4.3.1 Fabric Role Design

Figure 2-27 shows fabric roles in the centralized gateway solution using different
fabric networking modes.
● Two-layer single-device fabric networking: The core switch functions as both
border and edge nodes, and access switches function as fabric extended
nodes.
● Two-layer networking with VXLAN deployed across core and access layers:
The core switch functions as the border node, and access switches function as
edge nodes.
● Three-layer networking with VXLAN deployed across core and access layers:
The core switch functions as the border node, access switches function as
edge nodes, and aggregation switches function as transparent nodes.
● Three-layer networking with VXLAN deployed across core and aggregation
layers: The core switch functions as the border node, aggregation switches
function as edge nodes, and access switches function as fabric extended
nodes. Policy association can be deployed between edge and fabric extended
nodes to implement access control of user terminals on access switches.

In non-single-device fabric networking scenarios, BGP EVPN peer relationships

need to be established between border and edge nodes that function as VTEPs.
You are advised to configure the route reflector (RR) function. If no RR is
configured, BGP peer relationships need to be established between edge nodes,
and between edge and border nodes. The configuration is complex and many BGP
connections consume CPU resources. Border and edge nodes can function as RRs.
The border node used as the RR has the strongest processing capability, so it is
recommended that border nodes be used as RRs.

2.2.4.3.2 External Network Design

In the resource model design for the fabric network, external networks are created
on the border node so that terminals on the campus network can access the
Internet. For each external network resource created on the border node, a VRF
instance is allocated. After an external network resource is selected during VN
creation, the VRF instances of the created VN and external network resource
import routes from each other. In this way, service subnets in the VN can
communicate with the external network, as shown in Figure 2-28.
Figure 2-28 External network resource model design for a fabric
Egress Types of External Networks

Three types of external network resources are defined: L3 shared egress, L3
exclusive egress, and L2 shared egress. If the user gateway is located in the fabric,
the L3 shared egress or L3 exclusive egress is used, as shown in Figure 2-29.
● L3 shared egress: Multiple VNs on the fabric network share an L3 egress to
communicate with the egress device. To enable communication between VNs
and external networks, you must configure return routes to service subnets on
the firewall. As a result, service subnets of different VNs can communicate
with each other on the firewall. To isolate different VNs on the firewall,
configure policies based on service network segments in the VNs.
The L3 shared egress helps save VLAN and IP resources for interconnection
and applies to scenarios where there are low requirements on security control
policies between VNs.
● L3 exclusive egress: Each VN on the fabric network exclusively uses an L3
egress to communicate with the egress device. In this case, multiple security
zones are configured on the firewall, each corresponding to one L3 exclusive
egress. Thus, the traffic between service subnets of different VNs is isolated
when reaching the firewall. To enable inter-VN communication through the
firewall, you can configure security policies between security zones.
Configuring security policies can also control the application ports used for
communication and limit the bandwidth.
The L3 exclusive egress applies to scenarios where there are high
requirements on security control policies between VNs.

Figure 2-29 Traffic models for L3 shared egress and L3 exclusive egress on a fabric
Route Planning for External Networks

When interconnecting VNs with external networks, pay attention to the following
points: (1) On the border node, static routes are configured for the VRF instances
of VNs and external network resources to communicate with each other. (2)
Routing protocols are configured for the border node and firewall to communicate
with each other. In Figure 2-30, routes between the border node and firewall are
configured based on the route design principles for communication between
campus intranets and external networks.
● Routes from the campus intranet to external networks on the border node:
Generally, default routes are used to prevent a huge number of external
network routes from affecting intranets.
● Configure routes from external networks to the campus intranet on the
firewall: Generally, specific routes are used.
Figure 2-30 Route planning between the border node and firewall
When creating external network resources on the border node, you can use any of
the following routing protocols to interconnect the border node with the firewall.

According to the route design principles described above, Table 2-14 lists the
recommended configurations for the three routing protocols.
Table 2-14 Configurations of different routing protocols between the border node
and firewall
Rou Default Routes Return Routes Interconnection Between the
ting from VNs to from External Border Node and Firewall
Prot External Networks to VNs
ocol Networks on the on the Firewall
Border Node
Stat 1. On the border 1. On the

ic node, firewall,
rout manually manually
ing configure a configure
default route specific routes
whose next of service
hop is the IP subnets whose
address of an next hop is the
interface on IP address of
the firewall. an interface on
the border
node. Route
summarization
can be used to
reduce the
number of
routes to be
configured.


Border Node
OSP 1. On the 1. On the border

F firewall, node, VN1-
configure a Outer imports
common area specific routes
in the OSPF of service
process to subnets from
advertise VN1 through
default routes. BGP.
Active default 2. On the border
routes must node, the OSPF
exist in the process in
local routing VN1-Outer
table of the imports BGP
firewall. routes.
2. On the border 3. On the
node, the OSPF firewall, the
process of OSPF process
VN1-Outer learns the
learns the imported
advertised specific routes
default routes of service
through LSA subnets
updates. through LSA
updates.


Border Node
BGP 1. On the 1. On the border

firewall, node, VN1-
configure the Outer imports
BGP process to specific routes
import default of service
routes or subnets from
advertise such VN1 through
routes using BGP.
the network 2. The firewall
command. learns the
Active default imported
routes must specific routes
exist in the of service
local routing subnets
table of the through BGP.
firewall.
2. On the border
node, VN1-
Outer learns
the default
routes through
BGP.
When selecting a routing protocol between the firewall and border node, you
need to consider how to switch the service traffic path in active/standby
switchover scenarios when firewalls are deployed in HSB mode. For details, see the
egress route design in 2.2.6 Egress Network Design.
NOTE
You can configure routes on the border node when creating external network resources on
iMaster NCE-Campus, and configure routes on the firewall by logging in to the web system
or CLI.
2.2.4.3.3 Network Service Resource Design

In the resource model design for the fabric network, network service resources are
created on the border node so that service terminals on the campus network can
access service resources in the network management zone, such as the DHCP
server and NAC server. Three network service resource design models are available
based on the resource deployment locations on a fabric network.

Directly Connecting to Servers
Figure 2-31 Design model of network service resources on a fabric (border node
directly connected to servers)
As shown in Figure 2-31, for each network service resource created on the border
node, a VRF instance is allocated. After a network service resource is selected
during VN creation, the VRF instances of the created VN and network service
resource import routes from each other. In this way, service subnets in the VN can
communicate with the network service resource. Static routes are configured on
the border node based on the addresses for accessing these network service
resources.
In this scenario, the border node is directly connected to network service resources,
and the physical interfaces that connect the border node to the resources are
added to VLANs in access mode.
Directly Connecting to a Switch
directly connected to a switch)
As shown in Figure 2-32, for each network service resource created on the border
node, a VRF instance is allocated. After a network service resource is selected
during VN creation, the VRF instances of the created VN and network service
resource import routes from each other. In this way, service subnets in the VN can
communicate with the network service resource. Static routes are configured on
the border node based on the addresses for accessing these network service
resources.

In this scenario, the border node is connected to network service resources

through a switch, and the physical interfaces that connect the border node to the
resources are added to VLANs in trunk mode.
This design model is typically used if a DHCP server, iMaster NCE-Campus, and
other network service resources are deployed in the network management zone.
The border node is directly connected to the gateway switch in the network
management zone and then communicates with network service resources
through the switch. If only a small number of network service resources are
deployed, it is recommended that these resources be planned in the same network
service resource model. This saves interconnection VLAN and IP address resources
and simplifies route configuration for the network management zone, as shown in
Figure 2-33.
Figure 2-33 Traffic model for communication between the VN and network
service resource
NOTE
Routes on the border node are automatically delivered when network service resources are
created on iMaster NCE-Campus. To configure routes on the gateway in the network
management zone, log in to the web system or CLI of the device.
Deploying Network Service Resources on an External Network
Figure 2-34 Design model of network service resources on a fabric (servers

deployed on an external network)
This design model is selected only when a DHCP server is deployed on an external
network, as shown in Figure 2-34. In this scenario, the VN and DHCP server
communicate with each other based on an external network design model of the
fabric. This network service resource model is mainly used for obtaining the DHCP
server address. When this model is used, the gateway of the VN subnet can

function as the DHCP relay agent and automatically configure the DHCP server
address after the gateway is created.
NOTE
Currently, this model is not supported by DHCPv6 servers.
2.2.4.3.4 Access Management Design

When creating a fabric network, you need to plan authentication control points,
including access point resource pools, for user access. The wired access point
resource refers to switch interfaces connected by terminals, and the wireless
access point resource refers to SSIDs connected by terminals. In the centralized
gateway solution:
● You are advised to deploy the authentication control points for wired user
access on edge nodes and plan them on the Access Management tab page
of a fabric.
● The authentication control point for wireless user access is deployed on the
WAC. The design and planning of the authentication control point depend on
the WAC type. For details, see "WLAN Admission Design" in 2.2.5 WLAN
Design.
Access Interface Design

During access management configuration for a fabric network, three connection
types are defined for access interfaces on switches, as shown in Figure 2-35.
● Fabric extended AP: allows Huawei Fit APs to access. This type is used when
configuring policy association.
● Fabric extended switch: allows Huawei switches to access. This type is used
when configuring policy association.
● Terminal (PCs, phones, dumb terminals, and non-fabric extended access
switches or APs): allows terminals or switches/APs (when policy association is
not deployed) to access. If terminals are connected, bind authentication
profiles to terminals based on terminal types to control terminal access. For
details, see "User Access Authentication Design" in 2.2.7 Access Control
Design.

Figure 2-35 Connection types of fabric access interfaces
The connection types "fabric extended AP" and "fabric extended switch" are
mainly used for configuring a management VLAN for policy association and
forwarding data between the authentication control point and authentication
enforcement point. In this scenario, the fabric extended switch functions as the
authentication enforcement point and can be connected to fabric extended APs
and terminals.
In policy association, the authentication control point is moved up to the
aggregation or core layer. Devices at the aggregation or core layer and those at
the access layer can complete policy association through Control and Provisioning
of Wireless Access Points (CAPWAP) tunnels. In this way, the number of
authentication control points is reduced, and access control of terminals can be
implemented at the access layer.
Policy association is designed based on the traditional "WAC + Fit AP" architecture
for access control. In this architecture, WACs function as authentication control
points and APs as authentication enforcement points. User authentication
information is synchronized between WACs and APs through CAPWAP tunnels.
Therefore, policy association applies to scenarios where aggregation or core
devices function as unified authentication control points for wired and wireless
users.
In the centralized gateway solution, wired and wireless authentication control
points are deployed separately. Therefore, pay attention to the following points
when configuring fabric access management:
● If VXLAN is deployed across core and access layers for the fabric network,
policy association is not deployed.
● If VXLAN is deployed across core and aggregation layers for the fabric
network, policy association can be deployed between edge nodes and access
switches for wired access authentication, and the authentication enforcement
point for wired access can be moved down to the access switches.

NOTE
In the centralized gateway scenario, it is recommended that the border node with the
native WAC function be deployed, or standalone WACs be connected to the border
node in off-path mode. In this scenario, do not select Extended AP for interfaces
connecting access switches to APs. If this connection type is selected, the APs cannot
communicate with the border node through management VLAN auto-negotiation. You
don't need to configure the connection type for the interfaces connecting access
switches to APs.
RU Access Design
In the simplified all-optical campus solution, central switches and RUs are
launched as combinations. The following figure shows the networking and
connection types of fabric access interfaces.
Figure 2-36 RU networking and connection types of fabric access interfaces
RUs do not support VLAN configuration or policy association and are used only as
the remote ports of a central switch. In addition, RUs (without management IP
addresses) are managed by the central switch in a unified manner and are not
displayed as independent NEs on iMaster NCE-Campus. Therefore, during fabric
access network design, you only need to configure port isolation for RUs through
the central switch on iMaster NCE-Campus when deploying policy control (see
Policy Control Solution Design).
An RU provides multiple extension interfaces that can connect to terminals or APs.
During access authentication configuration, it is recommended that authentication
be configured on the interfaces connecting to terminals and non-authentication
be configured on the interfaces connecting to APs. In this case, the authentication
policies for the two access types are different. Therefore, it is not recommended
that an RU be connected to APs and terminals at the same time. When an RU is
connected to both terminals and APs, terminal authentication needs be enabled
on the corresponding interface on the central switch, and APs need to be
authenticated on the central switch to access the network.
NOTE
1. Port isolation for RUs cannot be configured based on unified fabric orchestration and
needs to be configured site by site.
2. RUs must be deployed together with and directly connected to a central switch.

2.2.4.4 VN Design
2.2.4.4.1 VN Division Principles

In the virtualization solution for a large or midsize campus network, each VN is a
VPN instance, and one VN can contain multiple subnets. By default, users in the
same VN can communicate with each other at Layer 3, and users in different VNs
are isolated from each other. VNs can be planned based on the following
principles:
● Allocate an independent service department or service network to a VN. For
example, on a campus network, services such as guest, teaching, IoT, and
video surveillance services, each is allocated to an independent VN.
● VNs are not used to fulfill the requirements for isolating users of different
levels in the same service department or service network. Instead, access
policies can be implemented to achieve this.
2.2.4.4.2 VN Access Design
VN Access of User Subnets

In the centralized gateway solution shown in Figure 2-37, if WLAN traffic is
forwarded in the recommended tunnel forwarding mode and the border node
functions as the native WAC and wireless subnet gateway, then:
● Traffic of wired users enters a VN through an edge node, and is forwarded in
the VN based on the BD associated with the user VLAN. Implement this when
configuring a user gateway in the VN on iMaster NCE-Campus.
● Traffic of wireless users is forwarded to the border node through the CAPWAP
tunnel. The border node decapsulates CAPWAP packets and then forwards the
decapsulated packets. If the traffic needs to be forwarded out by entering a
particular VN, you can bind the gateway interface of the corresponding
wireless subnet to a VN instance. The gateway interface can be a VLANIF or
VBDIF interface. The binding process is performed on the border node using
commands.

Figure 2-37 VN access of user subnets in the centralized gateway solution
User VLAN Access Modes

VLAN access modes for users include the static VLAN mode and dynamically
authorized VLAN mode. You need to select a mode when configuring a user
gateway in a VN. Table 2-15 lists the two access modes.
Table 2-15 Comparison between the static VLAN mode and dynamically
authorized VLAN mode
VLAN Implementation Application Scenario
Access
Mode
Static ● Wired access: Configure a The static VLAN mode applies when
VLAN static VLAN on the switch terminals access the VLAN at fixed
interface connected to locations and do not need to be
wired user terminals. authenticated. This access mode is
● Wireless access: Configure more secure but lacks flexibility.
a static service VLAN for When the locations of terminals
an SSID. change, you need to perform the
configuration again.


Access
Mode
Dynami ● Wired access: After a user The dynamically authorized VLAN

cally is authenticated mode applies when terminals access
authoriz successfully, the the VLAN anywhere and need to be
ed authorization result, authenticated based on the VLAN
VLAN including authorized VLAN information delivered during user
information, is delivered to authentication. This access mode is
the corresponding access flexible and the configuration does
interface. not need to be changed when the
● Wireless access: After a locations of terminals change.
user is authenticated
successfully, the
authorization result,
including authorized VLAN
information, is delivered to
the corresponding SSID.
● If a downlink interface is connected to an IP phone, you can configure a voice

VLAN on the interface for the IP phone.
● The dynamically authorized VLAN mode is applicable to the scenario where
the authentication control point resides on the access switch or policy
association is deployed between the authentication control point and access
switch.
● The dynamically authorized VLAN mode applies to MAC address
authentication and 802.1X authentication. The dynamically authorized VLAN
mode requires users to go online again during Portal authentication, so this
mode is not recommended in Portal authentication.
● The dynamically authorized VLAN mode can be implemented based on VLAN
pools. In this mode, the authentication control point automatically calculates
and allocates a VLAN in the VLAN pool to the access interface or SSID based
on authorized VLAN pool information. Subnets of VLANs in a VLAN pool are
connected to the same VN.
The VLAN pool-based authorization mode applies to scenarios where there
are a large number of user subnets. In the centralized gateway solution, all
downlink interfaces on edge nodes are isolated at Layer 2 by default. In this
case, you are advised to create subnets with VLANs instead of a VLAN pool.
2.2.4.4.3 VN User Gateway Design

In the centralized gateway solution, the user gateway for the VN sits on the
border node. You can use the following methods to perform the VN configuration
on iMaster NCE-Campus:
● Automatic allocation: After the number of user subnets and start VLAN and IP
address of the subnet are specified, the user subnet gateway is automatically
configured. This mode applies to scenarios where a large number of subnets
are deployed and automatic gateway configuration is required.

● Manual configuration: Manually configure the user access VLAN and the IP
address of the gateway interface. This mode applies to scenarios where a few
subnets are deployed and automatic gateway configuration is not required.
You are advised to perform the following configurations on iMaster NCE-Campus:
● Deploy an independent DHCP server to dynamically allocate IP addresses to

user terminals. Generally, the DHCP server and user terminals are on different
network segments. It is recommended that the DHCP relay function be
enabled on the user gateway.
● You are advised to enable DHCP snooping in the corresponding BD of the user
gateway to ensure that user terminals obtain IP addresses from authorized
DHCP servers and prevent attacks. In addition, DHCP snooping should be
enabled for terminal identification in DHCP mode.
● If the multicast DNS (mDNS) mode is used for terminal identification, mDNS
snooping should be enabled in the corresponding BD of the user gateway.
2.2.4.4.4 VN Communication Design
Intra-VN Subnet Communication
Communication Within a Subnet in a VN

Users on the same subnet in a VN communicate with each other at Layer 2, as
shown in Figure 2-38.
Figure 2-38 Traffic model for communication between users on the same subnet
in a VN

● Users on the same subnet connected to the same edge node can directly
communicate with each other through the edge node.
a. Host 1 and Host 2 are on the same subnet. When Host 1 accesses Host 2,
the destination MAC address of the packet sent by Host 1 to Host 2 is the
MAC address of Host 2.
b. After the packet arrives at Edge 1, Edge 1 searches for the MAC address
entry of Host 2. The entry belongs to VLAN 10 and is learned from
GE0/0/2. Edge 1 then forwards the packet.
c. Host 2 receives the packet from Host 1 through GE0/0/2.
● Users on the same subnet connected to different edge nodes
communicate with each other through the VXLAN tunnel between the edge
nodes.
entry of Host 2. The entry belongs to BD 10 and is learned from the
tunnel source interface (displayed as the IP address) of Edge 2. Edge 1
then encapsulates the packet into a VXLAN packet.
c. After the encapsulation, the outer source and destination IP addresses of
the packet are the IP addresses of tunnel source interfaces of Edge 1 and
Edge 2, respectively. Then the packet is forwarded based on the underlay
route.
d. After the packet arrives at Edge 2, Edge 2 performs VXLAN decapsulation,
searches for the MAC address entry of Host 2, determines the outbound
interface GE0/0/1, and forwards the packet.
e. Host 2 receives the packet from Host 1 through GE0/0/1.
Communication Between Subnets in a VN

In a VN, traffic between subnets needs to be forwarded by the gateway. In the
centralized gateway solution, the border node function as the gateway, as shown
in Figure 2-39.

Figure 2-39 Traffic model for communication between users on different subnets
in a VN
● Users on different subnets connected to the same edge node

node and border node. Mutual access traffic is sent to the border node first,
then forwarded at Layer 3 based on direct routes in the VN.
a. Host 1 and Host 2 are on different subnets. When Host 1 accesses Host 2,
the packet is sent to the gateway first. The destination MAC address of
the packet is the MAC address of VBDIF 10 on the gateway.
entry of VBDIF 10. The entry belongs to BD 10 and is learned from the
tunnel source interface (displayed as the IP address) of the border node.
Edge 1 then encapsulates the packet into a VXLAN packet.
the border node, respectively. Then the packet is forwarded based on the
underlay route.
d. After the packet arrives at the border node, the border node performs
VXLAN decapsulation and searches for the direct route to Host 2 in the
VN 1 routing table. The next hop is the IP address of the tunnel source
interface of Edge 1. The border node then encapsulates the packet into a
VXLAN packet. The inner destination MAC address of the packet is the
e. After the encapsulation, the outer source and destination IP addresses of
the packet are the IP addresses of tunnel source interfaces of the border
node and Edge 1, respectively. Then the packet is forwarded based on the
underlay route.
f. After the packet arrives at Edge 1, Edge 1 performs VXLAN decapsulation
and searches for the MAC address entry of Host 2. The entry belongs to
VLAN 20 and is learned from GE0/0/2. Edge 1 then forwards the packet.
g. Host 2 receives the packet from Host 1 through GE0/0/2.
● Users on different subnets connected to different edge nodes
communicate with each other through the VXLAN tunnels between the edge

nodes and border node. Mutual access traffic is sent to the border node first,
then forwarded at Layer 3 based on direct routes in the VN.
underlay route.
VXLAN decapsulation and searches for the direct route to Host 2 in the
VN 1 routing table. The next hop is the IP address of the tunnel source
interface of Edge 2. The border node then encapsulates the packet into a
underlay route.
Inter-VN Subnet Communication

In the virtualization solution for a large or midsize campus network, VNs are
isolated by VPNs at Layer 3. By default, VNs cannot communicate with each other.
Subnets in different VNs can communicate with each other through a border node
or firewall. Table 2-16 lists the application scenarios of the two communication
modes.
Table 2-16 VN communication modes and application scenarios
Communicat Application Scenario

ion Mode
Communicati Communication between VNs does not require advanced

on through a security policy control by the firewall. In this case, implement
border node policy control based on the free mobility solution, and import
the network segment routes that can be reachable between
devices added to the VNs on the border node.
Communicati Communication between VNs requires advanced security policy

on through a control by the firewall.
firewall

Subnet Communication Between VNs Through a Border Node

To implement communication between VNs through a border node, import the
network segment routes that can be reachable between devices added to the VNs
on the border node. After mutual access traffic arrives at the border node, the
border node forwards the traffic between VNs based on the imported routes, as
Figure 2-40 Traffic model for subnet communication between VNs through a
border node
● Users on subnets of different VNs connected to the same edge node

then forwarded between VNs based on the imported routes of the VNs.
underlay route.
VXLAN decapsulation and searches for the route to the network segment
of Host 2 in the VN 1 routing table. Because the VPN routing tables of
VN 1 and VN 2 import routes from each other, the direct route to the
network segment of Host 2 can be found in the VN 1 routing table. The
next hop of the packet is the IP address of the tunnel source interface of
Edge 1. The border node then encapsulates the packet into a VXLAN
packet. The inner destination MAC address of the packet is the MAC
address of Host 2.


underlay route.
● Users on subnets of different VNs connected to different edge nodes
underlay route.
VN 1 and VN 2 import routes from each other, the direct route to the
network segment of Host 2 can be found in the VN 1 routing table. The
next hop is the IP address of the tunnel source interface of Edge 2. The
border node then encapsulates the packet into a VXLAN packet. The
inner destination MAC address of the packet is the MAC address of Host
2.
underlay route.
Subnet Communication Between VNs Through a Firewall

To implement communication between VNs through a firewall, configure mutual
access control policies between security zones of the firewall. After mutual access
traffic arrives at the firewall, the firewall forwards the traffic between VNs based
on the mutual access policies, as shown in Figure 2-41.

firewall

then forwarded to the firewall based on the imported routes of external
networks. The firewall then forwards the traffic between VNs based on
mutual access control policies between security zones.
underlay route.
VN 1 and the external network resource model VN1-Outer import routes
from each other, the route to the network segment of Host 2 can be
found in the VN 1 routing table. The next hop of the packet is the IP
address of GE1/0/1.1 on the firewall. The destination MAC address of the
packet is the MAC address of GE1/0/1.1, and the packet is not
encapsulated into a VXLAN packet.
e. After the packet arrives at the firewall, the firewall allows VN 1 to access
VN 2 based on the mutual access policies and searches for the route to
the network segment of Host 2. The next hop of the packet is the IP
address of VLANIF 12 on the border node. The destination MAC address

of the packet is the MAC address of VLANIF 12, and the packet is not
f. After the packet arrives at the border node, the border node searches for
the direct route to Host 2 in the VN 2 routing table. The next hop of the
packet is the IP address of the tunnel source interface of Edge 1. The
border node then encapsulates the packet into a VXLAN packet. The
inner destination MAC address of the packet is the MAC address of Host
2.
g. After the encapsulation, the outer source and destination IP addresses of
underlay route.
h. After the packet arrives at Edge 1, Edge 1 performs VXLAN decapsulation
i. Host 2 receives the packet from Host 1 through GE0/0/2.
underlay route.
the direct route to the network segment of Host 2 in the VN 2 routing

table. The next hop is the IP address of the tunnel source interface of
Edge 2. The border node then encapsulates the packet into a VXLAN
packet. The inner destination MAC address of the packet is the MAC
address of Host 2.
underlay route.
h. After the packet arrives at Edge 2, Edge 2 performs VXLAN decapsulation
Communication Between VNs and External Networks

In the virtualization solution for a large or midsize campus network, two resource
models are designed for the fabric network: external network resources and
network service resources. For each resource created, a VRF instance is allocated.
During VN creation and resource selection, VNs and external network resources
(or network service resources) automatically import routes from each other to
enable mutual access, as shown in Figure 2-42.
Figure 2-42 Traffic model for communication between VNs and external networks

● Users in a VN access the Internet through the VXLAN tunnel between the
edge node and border node. Traffic is sent to the border node first, then
forwarded to the firewall based on the imported routes of external networks.
The firewall then forwards the packet to the Internet.
a. Host 1 and the Internet are on different subnets. When Host 1 accesses
the Internet, the packet is sent to the gateway first. The destination MAC
address of the packet is the MAC address of VBDIF 10 on the gateway.
underlay route.
VXLAN decapsulation and searches for the route to the Internet in the VN
1 routing table. Because the VPN routing tables of VN 1 and the external
network resource model VN1-Outer import routes from each other, the
route to the Internet can be found in the VN 1 routing table. The next
hop of the packet is the IP address of GE1/0/1.1 on the firewall. The
destination MAC address of the packet is the MAC address of GE1/0/1.1,
and the packet is not encapsulated into a VXLAN packet.
the Internet based on the mutual access policies and searches for the
route to Internet. The firewall then forwards the packet.
● Users in a VN access network service resources through the VXLAN tunnel
between the edge node and border node. Traffic is sent to the border node
first, then forwarded to the gateway in the network management zone based
on the imported routes of the network management zone. The gateway in
the network management zone then forwards the packet to the network
management zone.
a. Host 1 and the network service resource are on different subnets. When
Host 1 accesses the network service resource, the packet is sent to the
gateway first. The destination MAC address of the packet is the MAC
address of VBDIF 10 on the gateway.
underlay route.
VXLAN decapsulation and searches for the route to the network service
resource in the VN 1 routing table. Because the VPN routing tables of VN
1 and the network service resource model VN1-Server import routes from
each other, the route to the network service resource can be found in the
VN 1 routing table. The next hop of the packet is the IP address of

VLANIF 11 on the gateway in the network management zone. The

destination MAC address of the packet is the MAC address of VLANIF 11,
e. After the packet arrives at the gateway in the network management
zone, the gateway searches for the route to the network service resource
and forwards the packet.
2.2.4.5 Multicast Overlay Service Design

The current virtualization solution for large- and medium-sized campus networks
supports Layer 2 multicast deployment on the overlay network. If multicast data
needs to be transmitted over the overlay network, it is recommended that the
Layer 2 multicast function be deployed in BDs corresponding to user subnets. This
prevents multicast data from being broadcast in the BD and the data is forwarded
only to multicast receivers, reducing bandwidth consumption. Currently, two types
of networking scenarios are available based on the access location of the
multicast source, as shown in Figure 2-43.
Figure 2-43 Networking diagram of multicast sources at different locations
Table 2-17 describes the design of Layer 2 multicast services in the BDs
corresponding to user subnets based on the locations of multicast sources.
NOTE
For switches running V600R022C00 or later versions, Layer 2 multicast cannot be deployed
using dynamically authorized VLANs.

Table 2-17 Layer 2 multicast service design in BDs corresponding to user subnets
Multica Layer 2 Multicast Service Design Description
st
Source
Locatio
n
Outside ● On the border node, add the interface When the border
the connected to the multicast source to the node is
fabric subnet VLAN where the multicast receivers connected to a
reside, and associate the VLAN with the Layer 3 multicast
corresponding BD. You can specify the interface device that is not
for the border node to connect to devices enabled with
outside the fabric when configuring IGMP IGMP, you need
snooping in the BD on iMaster NCE-Campus. to configure the
● In this scenario, IGMP is typically enabled on interface
the Layer 3 multicast device connected to the connecting the
border node. Therefore, you do not need to border node to
specify an IGMP snooping querier in the BD. the Layer 3
multicast device
● To prevent unknown multicast traffic from as a static router
being broadcast in the BD corresponding to the port to ensure
user subnet, which wastes bandwidth, it is that IGMP
recommended that the function of dropping Report/Leave
unknown multicast packets be enabled in the messages can be
IGMP snooping profile. forwarded to the
● Wireless multicast traffic optimization: When upstream Layer 3
an AP sends multicast packets to a multicast multicast device.
receiver, multicast-to-unicast conversion can be In addition, you
used to improve the transmission efficiency of need to specify
multicast data flows. In addition, adaptive the border node
multicast-to-unicast conversion can be enabled as an IGMP
to automatically adjust air interface snooping querier.
performance and improve wireless multicast
experience.

Multica Layer 2 Multicast Service Design Description

st
Source
Locatio
n
Inside ● On the device connected to the multicast If the multicast

the source, add the interface connected to the source is inside
fabric multicast source to the subnet VLAN where the the fabric, it can
multicast receivers reside, and associate the be connected
VLAN with the corresponding BD. You can add through a border
the device interface connected to the multicast or edge node. If
source to the subnet VLAN where the multicast VXLAN is
receivers reside when creating a subnet for the deployed across
multicast receivers on iMaster NCE-Campus. core and
● Configure the device connected to the aggregation
multicast source as an IGMP snooping querier. layers on a fabric
and access
● To prevent unknown multicast traffic from switches are
being broadcast in the BD corresponding to the used as fabric
user subnet, which wastes bandwidth, it is extended access
recommended that the function of dropping nodes, the
unknown multicast packets be enabled in the multicast source
IGMP snooping profile. can be
● Wireless multicast traffic optimization: When connected
an AP sends multicast packets to a multicast through the
receiver, multicast-to-unicast conversion can be access switches.
used to improve the transmission efficiency of
multicast data flows. In addition, adaptive
multicast-to-unicast conversion can be enabled
to automatically adjust air interface
experience.
2.2.5 WLAN Design
2.2.5.1 Suggestions on WLAN Planning

A WLAN transmits data through high-frequency electromagnetic waves over the
air interface. As the transmission distance increases, the strength of radio signals
becomes weaker, resulting in poor service experience of STAs at the edge of radio
signal coverage. In addition, all wireless devices share air interface resources. As a
result, if the working channels of neighboring wireless devices are adjacent or the
same, co-channel or adjacent-channel interference exists. The interference
problems deteriorate the WLAN signal quality and even cause a WLAN to be
unavailable. To improve the WLAN quality and meet customers' requirements on
network construction, WLAN planning design is required. Proper WLAN planning
helps reduce the probability of WLAN signal coverage holes and signal
interference. In addition, to meet the bandwidth requirements of each STA and
provide better WLAN experience, select appropriate AP types and properly plan

the number of STAs connected to APs. If WLAN planning design is not performed
in the early stage, rework may be required after APs are installed. This is because
network optimization after APs are installed may require AP reinstallation and re-
cabling.
2.2.5.1.1 WLAN Engineering and Planning Design

Before WLAN planning design, determine the deployment scenarios, such as
enterprise offices, education, stadiums, hotels, and shopping malls/supermarkets.
In such scenarios, service requirements vary, and different device models, network
coverage, and network capacity are needed. Therefore, perform WLAN planning
design as required. For details about the scenarios and corresponding design
solutions, see the WLAN Engineering and Planning Design Guide.
2.2.5.1.2 AP Power Supply and Cabling Design

AP power supply modes include:
● Power supply by PoE devices (recommended)

The PoE switch transmits data and supplies power to APs, and serves as the
main power supply for APs. If the distance between an AP and a switch is
shorter than 80 m, you are advised to use a common PoE switch for power
supply. If the distance between an AP and a switch is longer than 80 m but
shorter than 300 m, you are advised to use a hybrid optical-electrical switch
to supply power to the AP (APs connected to a switch using hybrid cables are
supported).
● Local power supply
An independent power supply is used to supply power to APs. In most cases, a
local AC power supply can be used to supply power to APs if an upstream
switch does not support PoE power supply.
● Power supply by PoE adapters
Typically, outdoor APs use optical fibers for data transmission and support
only PoE power supply. In this case, PoE adapters are used to supply power to
APs. In outdoor scenarios, PoE adapters must be installed in an equipment
container or cabinet to meet the operating temperature, waterproof, and
surge protection requirements.
Figure 2-44 AP power supply modes
During AP cabling design, pay attention to the following points:

● During AP deployment, reserve around 5 m network cable for adjusting AP
installation positions due to interference or poor signal coverage in the future.
● Keep network cables far away from strong electromagnetic interference.

● Confirm with customers about the cabling design in advance to prevent

customers from disallowing construction for the property or appearance
reason.
NOTE
Wi-Fi 6 APs need to be powered by PoE++ switches. Therefore, select appropriate access
switches for power supply based on AP models.

On a large or midsize campus network, the WLAN typically adopts the "WAC + Fit
AP" architecture. Under this architecture, APs work in Fit mode and are centrally
managed by the WAC. As shown in Figure 2-45, in the virtualization solution, you
are advised to use the border node that comes with the native WAC functionality.
In campus network reconstruction scenarios where an existing standalone WAC
needs to be used, you are advised to connect the WAC to the border node in off-
path mode.
Figure 2-45 WLAN architecture in the virtualization solution
Control packets between the WAC and APs are forwarded through a CAPWAP
tunnel. APs forward service packets of wireless users to the wired side in tunnel
forwarding (centralized forwarding) or direct forwarding (local forwarding) mode.
Tunnel Forwarding
In tunnel forwarding mode, an AP encapsulates the service packets of wireless
users over a CAPWAP tunnel and sends them to the WAC. The WAC then forwards
these packets to other networks. Figure 2-46 shows the traffic forwarding model
adopted when the tunnel forwarding mode is used in this solution.

In tunnel forwarding mode, switches on the links between the WAC and APs do
not need to allow service VLANs, and interfaces on the switches do not need to be
added to such VLANs. This facilitates centralized control and management.
However, the disadvantage is that the service traffic of all wireless users is
centrally forwarded by the WAC, which imposes a heavy workload on the WAC.
Figure 2-46 Service traffic model of wireless users (tunnel forwarding mode)
Direct Forwarding
In direct forwarding mode, an AP directly forwards users' service packets to other
networks without encapsulating them over a CAPWAP tunnel. Figure 2-47 shows
the traffic forwarding model adopted when the direct forwarding mode is used in
this solution.
In direct forwarding mode, the east-west service traffic of local wireless users can
be directly forwarded by the local access switch without passing through the WAC.
However, switches on the links between the WAC and APs need to allow service
VLANs, and interfaces on the switches need to be added to such VLANs, making it
difficult to perform centralized control and management.

Figure 2-47 Service traffic model for wireless users (direct forwarding mode)
Table 2-18 compares the tunnel forwarding mode with the direct forwarding
mode. In the virtualization solution for a large or midsize campus network, the
tunnel forwarding mode that can provide centralized traffic management and
control is recommended, irrespective of which gateway solution is selected. The
subsequent WLAN planning following this section is also designed based on the
tunnel forwarding mode.
Table 2-18 Forwarding mode comparison

Forwar Application Scenario Advantage Disadvantage
ding
Mode
Tunnel Wireless user service The WAC forwards Service traffic must
forwardi traffic is processed and service traffic in a be forwarded by the
ng forwarded by the WAC centralized manner, WAC, reducing packet
in a centralized ensuring high forwarding efficiency
manner. security and and burdening the
facilitating WAC.
centralized traffic
management and
control.


ding
Mode
Direct Service traffic of Service traffic does Service traffic cannot

forwardi wireless users is not need to be be managed and
ng directly forwarded forwarded by the controlled in a
without passing WAC, which centralized manner.
through the WAC, improves packet
saving AP-WAC link forwarding
bandwidth. efficiency and
reduces the burden
on the WAC.
2.2.5.3 AP Onboarding Design

In the "WAC + Fit AP" architecture, to enable APs to join the WAC, you need to
configure a DHCP server for the AP management network first. Thus, each AP can
automatically obtain a management IP address through DHCP, establishing a
management channel with the WAC. Then, associate APs with the WAC and
configure the CAPWAP source interface. If an AP tries to access the network, the
WAC verifies the MAC address or ESN of the AP. If the WAC finds it an authorized
AP, it establishes a CAPWAP tunnel with the AP. In this way, the AP successfully
joins the WAC.
Management IP Address Planning for APs

In the "WAC + Fit AP" architecture, to improve deployment efficiency, an AP
usually obtains an IP address in DHCP mode. After a DHCP server is configured, an
AP acts as a DHCP client to request a management IP address from the DHCP
server, and obtains the IP address of the WAC through the Option 43 field in
DHCP packets. In this solution, the border node functions as the DHCP server of
the wired and wireless management subnets to automatically assign management
IP addresses to access and aggregation switches as well as APs. The AP's first
onboarding in plug-and-play mode and management VLAN switching can be
planned by referring to the plan for switch onboarding. For details, see 2.2.3.2
Deployment Design.
Planning for AP Association with the WAC

Associating APs with the WAC is to ensure that associated APs are authorized. If
the information about an AP that connects to the network does not match that on
the associated WAC, the AP is not allowed to come online. In this solution, the
following operations for associating APs with the WAC need to be performed on
iMaster NCE-Campus:
1. First, enter the ESNs of APs when adding devices to a campus site. There are a
large number of APs on a large or midsize campus network. Therefore, you
are advised to use the network plan import function to add the ESNs of APs
to a site when importing physical link data using a template.
2. After the ESNs of APs are recorded, you can view the APs that can be
associated with the WAC on the Manage Fit AP tab of the Network

Configuration page on iMaster NCE-Campus. In the WAC list, select the row
where the WAC resides, and click Add in the lower right corner to add APs for
management by the WAC.
CAPWAP Source Interface Planning

In the virtualization solution for a large or midsize campus network that uses the
"WAC + Fit AP" architecture, APs' wireless services are centrally configured
through the web system or CLI of the WAC, including the configuration of the
CAPWAP source interface used to establish a CAPWAP tunnel between the WAC
and AP.
2.2.5.4 AP Group Design

An AP group is used to configure and manage APs in batches so that the APs
inherit the configurations of the group to which they belong.
You can create an AP group based on the following items:
● Physical location (For example, APs on the same floor can be added to the
same AP group. This mode is preferred.)
● Device model
● IP or MAC address
● Serial number (SN)
2.2.5.5 SSID and Service VLAN Design
SSID Planning
In most cases, service set identifiers (SSIDs) are planned based on user roles or
service types. For example, three SSIDs can be planned for three types of wireless
services in a large-scale business scenario, as shown in Figure 2-48. Employee is
used for wireless office access of employees. Guest is used for Internet access of
guests. Dumb is used for wireless access of dumb terminals such as printers. For
an SSID that is not intended for end users, for example, the SSID used for access
of printers, you can configure SSID hiding to prevent the SSID from being detected
by end users.
Figure 2-48 SSID planning

Wireless Service VLAN Planning

When an AP receives service data from wireless users and forwards the data to the
wired side, a wireless service VLAN needs to be planned to distinguish different
wireless service types or user groups on the wired side. On the wireless side, SSIDs
also differentiate wireless service types or user groups. Therefore, mappings
between VLANs and SSIDs must be considered during WLAN planning. Two
mapping relationships are applicable to different scenarios: 1:1 and 1:N, as
described in Table 2-19.
Table 2-19 Mappings between VLANs and SSIDs
SSID:VLA Usage Scenario

N
Mapping
SSID:VLA An enterprise needs to provide WLAN coverage for hotspots A and

N=1:1 B. To allow users to detect only one SSID and use the same data
forwarding control policy, plan only one SSID and one VLAN, that
is, SSID:VLAN = 1:1.

N = 1:N B. To allow users to detect only one SSID but use different data
forwarding control policies for the two hotspots. In this case, plan
one SSID and two VLANs to differentiate the hotspots, that is,
SSID:VLAN = 1:2.
On a large and midsize campus network, a large number of STAs exist and require
area-specific policies. Typically, the SSID:VLAN = 1:N mapping policy is used.
The range of a radio broadcast domain is determined by an SSID. Therefore, in

case of SSID:VLAN = 1:N, you are advised to enable broadcast-to-unicast
conversion to avoid the generation of a radio broadcast domain.
2.2.5.6 WLAN Admission Design
NAC Authentication Control Point Design

Network Access Control (NAC) solution is applicable to both wired and wireless
users. In this solution, common authentication technologies include 802.1X, MAC
address, and Portal authentication. Generally, access control is performed for wired
users based on access interfaces of switches, and for wireless users based on
SSIDs. The roadmap for selecting authentication modes for wireless users is the
same as that for wired users. That is, you need to take into account different user
roles or terminal types. For details, see "User Authentication Mode Design" in
2.2.7 Access Control Design.
On a WLAN using the "WAC + Fit AP" architecture, the WAC serves as the wireless
authentication control point. In this solution, the deployment process of the
wireless authentication control point varies according to the WAC type.
● Standalone WAC (connected to a border node in off-path mode)

In the centralized gateway solution, if a standalone WAC is connected to a

border node in off-path mode, you need to log in to the WAC's web system to
centrally perform settings on the wireless authentication control point, as
demonstrated in Figure 2-49. The following describes the configuration
process:
a. Configure authentication, authorization, and accounting (AAA) profile
resources on the WAC, including the RADIUS server template, Portal
server template, and access authentication profiles.
b. Associate the configured access authentication profiles with the
corresponding SSIDs on APs.
Figure 2-49 Configuration on the wireless authentication control point

(standalone WAC connected to a border node in off-path mode)
● Native WAC (integrated with a border node)

If the border node serves as the native WAC in this solution, you can log in to
the WAC's web system to configure authentication profiles. Alternatively, you
can configure these profiles on iMaster NCE-Campus and deliver them to the
native WAC on the Site Configuration tab page, as shown in Figure 2-50.
The following describes the configuration process:
a. Create profiles on the Site Configuration tab page of iMaster NCE-
Campus and deliver them to the WAC.
corresponding SSIDs on APs. You can only log in to the web system of the
WAC to configure wireless services on APs.

Figure 2-50 Configuration on the wireless authentication control point (native

WAC integrated with a border node)
NOTE
In this solution, access authentication is configured on the Site Configuration tab

page. If the native WAC is used, you can deliver authentication profiles to the WAC. If
the built-in authentication server of iMaster NCE-Campus is used for wireless access
authentication, access authentication must be configured to enable iMaster NCE-
Campus to record the mapping between authentication control points, SSIDs, and
authentication profiles.
Security Policy Design

In addition to the traditional NAC solution, four WLAN security policies are
available: Wired Equivalent Privacy (WEP), Wi-Fi Protected Access (WPA), WPA2,
WLAN Authentication and Privacy Infrastructure (WAPI). Each security policy has a
series of security mechanisms, including link authentication used to establish a
wireless link, user authentication used when users attempt to connect to a
wireless network, and data encryption used during data transmission. Table 2-20
compares these WLAN security policies.
Table 2-20 Comparison between WLAN security policies
Secu Characteristics
rity
Polic
y
WEP The original 802.11 security mechanism, WEP, is vulnerable to security

threats due to the limitations of its encryption algorithm. Therefore, WEP
is not recommended.

rity
Polic
y
WPA WPA and WPA2 provide almost the same security. WPA/WPA2 has two
/ editions: enterprise edition and personal edition.
WPA ● WPA/WPA2-Enterprise: uses a RADIUS server and the Extensible
2 Authentication Protocol (EAP) to provide IEEE 802.1X network access
control. Users provide authentication information, including the user
name and password, and are authenticated by an authentication
server (generally a RADIUS server). This edition applies to scenarios
that have high requirements on network security.
● WPA/WPA2-Personal: adopts a simpler mechanism, that is, WPA/
WPA2 pre-shared key (WPA/WPA2-PSK) mode. This edition does not
require an authentication server and applies to scenarios that have
low requirements on network security.
WAP WAPI is a WLAN security standard proposed in China and provides

I higher security than WEP and WPA.
NAC is typically considered in conjunction with security policies to form combined

network access control solutions suited to diverse scenarios. Table 2-21 lists
WLAN security policies, recommended NAC authentication modes, and application
scenarios.
Table 2-21 Recommendations on configuring a WLAN security policy

Security Recommended Application Scenario
Policy NAC
Authentication
Mode
Open (no Portal/MAC ● An open WLAN that has no security policy

security address configured and allows any STA to connect.
policy authentication You are advised to configure both Portal
configured) authentication and MAC address
authentication.
● Public places with high user mobility, such
as airports, stations, business centers,
conference halls, and sports stadiums. This
security policy should be configured
together with Portal authentication, which
supports user authentication, accounting,
authorization, and information pushing.
WEP - ● This security policy is not recommended

due to its low security.
● Individual or home networks


Policy NAC
Authentication
Mode
WPA/WPA2- - ● This security policy has higher security than

PSK WEP. Additionally, no third-party server is
authenticati required and the cost is low.
on ● Individual or home networks
WPA/ 802.1X ● This security policy provides high security

WPA2-802.1 authentication and requires a third-party server.
X (only this ● Scenarios with fixed users and requiring
authenticati authentication high security and centralized user
on mode can be management and authorization, such as
selected) mobile office, campus networks, and
mobile administration
WAPI-PSK - This security policy provides higher security

authenticati than WEP and requires no third-party server.
on Only some STAs support the protocol.
WAPI- - This security policy provides high security and

certificate requires a third-party server. Only some STAs
authenticati support the protocol.
on
2.2.5.7 Radio Resource Management Design

WLAN technology uses radio signals (such as 2.4 GHz or 5 GHz radio waves) as
transmission medium. Due to environment interference, radio signals will
attenuate when transmitted over the air, degrading service quality for wireless
users. Radio resource management enables APs to check the surrounding radio
environment, dynamically adjust working channels and transmit power, and evenly
distribute access users. This function helps reduce radio signal interference and
adjust radio signal coverage to enable a wireless network to quickly adapt to radio
environment changes. With the radio resource management function, the wireless
network can provide high service quality for wireless users and maintain an
optimal radio resource utilization.
2.2.5.7.1 Radio Calibration
Traditional Radio Calibration

On a WLAN, the operating performance of APs is affected by the radio
environment. For example, a high-power AP can interfere with adjacent APs if
they work on overlapping channels. In this case, the radio calibration function can
be deployed to dynamically adjust channels and power of APs managed by the
same WAC to ensure that the APs work at the optimal performance.
Depending on the scope of radio calibration, two radio calibration modes are
available:

● Global radio calibration: A WAC dynamically allocates channels and power to

all the APs managed by it. This calibration mode is used when a new WLAN is
established or the radio environment of a WLAN deteriorates on a large scale.
● Partial radio calibration: A WAC dynamically allocates channels and power to
specified APs. This calibration mode is used when new APs are added to the
network or signal interference exists in some areas.
Radio calibration can be triggered in any of the following modes:
● Automatic mode: APs perform global calibration periodically based on the
specified calibration interval.
● Manual mode: Radio calibration is not automatically implemented but
manually triggered through commands.
● Scheduled mode: APs perform global calibration at a scheduled time every
day.
The three modes cannot be configured simultaneously. You can choose any of the
modes as required. For example, if burst strong interference sources exist in some
areas of a network, you are advised to manually perform partial radio calibration
for interfered APs. During radio calibration, the working channel of an AP is
adjusted. As a result, STAs associated with the AP go offline, causing service
interruption. Therefore, it is recommended that scheduled radio calibration be
configured so that APs perform radio calibration in off-peak hours, for example,
between 00:00 am and 06:00 am.
Intelligent Radio Calibration

Traditional radio calibration is implemented in a periodic and passive manner,
which relies on radio detection for environment awareness. This mode focuses on
detecting radio interference but lacks insights into the actual services. An ideal
radio calibration mode is demanded, in which the network load is considered, the
number of STAs and traffic volume on a network can be intelligently predicted,
the optimal radio parameters can be calculated based on historical data, and
optimal transmitting and receiving efficiency of air interfaces can be ensured.
When scheduled radio calibration is triggered in the early morning (off-peak
hours), the network is unaware of the actual service load of APs in the daytime
(peak hours) and cannot detect fixed interference sources that exist periodically in
the daytime. In this case, radio calibration is performed based only on the real-
time network status. As a result, the calibration effect cannot be guaranteed, and
radio resources cannot be fully utilized.
In the intelligent radio calibration solution, iMaster NCE-CampusInsight accurately
identifies the network topology and the list of edge APs by analyzing a large
amount of data reported by devices, and predicts the load in the next calibration
period by analyzing historical data. When starting radio calibration, the system
uses the latest prediction data as the input data of the calibration algorithm and
performs calibration calculation based on the real-time network quality to achieve
the optimal calibration effect. Figure 2-51 demonstrates the framework of the
intelligent radio calibration solution.

Figure 2-51 Framework of the intelligent radio calibration solution
NOTE
1. Intelligent radio calibration and traditional radio calibration cannot be deployed for the
APs in the same calibration region at the same time.
2. Intelligent radio calibration needs to be used together with iMaster NCE-CampusInsight.
Ensure that APs can communicate with iMaster NCE-CampusInsight.
3. AP load prediction is applicable to scenarios where service traffic is relatively stable and
historical data is regular, such as the office automation (OA) scenario. When there is a
sudden increase or decrease in service traffic, for example, when network expansion or
large-scale personnel relocation occurs (such as in stadiums), AP load prediction cannot be
implemented.
4. Only the 5 GHz frequency band is supported when increasing the channel bandwidth of
high-load APs. In addition, if the number of available channels is less than six (for example,
in some countries, the number of available 5 GHz channels is small; if dual-5G is enabled,
the 40 MHz or higher channel bandwidth cannot be completely staggered), the channel
bandwidth cannot be increased on high-load APs.
Comparison Between Traditional Radio Calibration and Intelligent Radio

Calibration
Table 2-22 compares traditional radio calibration and intelligent radio calibration.
Traditional radio calibration applies to more scenarios and can effectively handle
burst strong interference sources on the network. Intelligent radio calibration
achieves better calibration effects based on historical data analysis in scheduled
radio calibration scenarios. Select a proper calibration mode based on actual
service requirements.

Table 2-22 Comparison between traditional radio calibration and intelligent radio
calibration
Calib Application Scenario Advantage Disadvantage
ratio
n
Mode
Tradit 1. Scenarios where ● When burst strong ● When scheduled

ional iMaster NCE- interference sources radio calibration
radio CampusInsight is not exist, you can is used, the
calibr deployed on the perform partial network
ation customer's network calibration to reduce topology is lost,
2. Automatic, manual, the impact of the the impact of
and scheduled interference source. nomadic STAs
calibration scenarios cannot be
reduced, and the
impact of
network load on
network
performance
cannot be
predicted.
Intelli 1. Scenarios where ● The network ● Burst strong

gent iMaster NCE- topology is more interference
radio CampusInsight is complete thanks to sources cannot
calibr deployed on the big data learning. be avoided.
ation customer's network Nomadic STAs can
2. Scenarios where be effectively
scheduled radio identified, reducing
calibration is their impact on the
periodically performed network. The impact
of network load on
network
performance can be
accurately predicted.
2.2.5.7.2 Load Balancing

Load balancing can evenly distribute traffic loads to APs to ensure sufficient
bandwidth of each STA. The load balancing function applies to high-density
WLANs to ensure proper access of STAs.
This function is applicable to scenarios where there is a high degree of overlapping
between APs' coverage ranges. If APs engaged in load balancing are far from each
other, a STA may connect to a distant AP, which affects wireless experience of
users.
Depending on whether a load balancing group needs to be manually created, load
balancing is classified into static and dynamic load balancing:
● Static load balancing: APs providing the same services are manually added to
the same load balancing group. After a STA connects to a WLAN, the WAC

uses the load balancing algorithm to measure the dual-band capability of the
STA, AP load, and AP signal quality, and steers the STA to a better AP.
● Dynamic load balancing: After a STA connects to an AP, the WAC checks
whether the number of STAs on this AP reaches the load balancing threshold.
Then, the WAC determines whether to steer the STA to a neighboring AP that
meets the load balancing conditions based on the load balancing algorithm.
Static load balancing limits the maximum number of AP radios to 16 and allows
only radios on the same frequency band to join a load balancing group.
Additionally, a load balancing group needs to be manually specified. In practice,
dynamic load balancing is recommended. In this mode, APs collect neighbor
information and steer STAs to proper APs based on the load balancing status,
dynamically implementing better STA access.
2.2.5.7.3 Band Steering

On live networks, most STAs support both 2.4 GHz and 5 GHz frequency bands
but usually associate with the 2.4 GHz radio by default when connecting to the
network. As a result, the 2.4 GHz frequency band with fewer channels is
congested, heavily-loaded, and has severe interference. The 5 GHz frequency band
with more channels and less interference is not well used. When the 2.4 GHz
frequency band is overloaded or has severe interference, the 5 GHz frequency
band can provide better access service for wireless users. To connect to the 5 GHz
radio, users need to select the 5 GHz radio on STAs.
The band steering function allows an AP to steer STAs to the 5 GHz radio first.
This reduces the traffic load and interference on the 2.4 GHz frequency band and
improves user experience.
It is recommended that the band steering function be enabled by default. This
function, together with the load balancing function, can evenly distribute STAs on
one and multiple APs and improve user experience across the entire network.
NOTE
1. The two frequency bands of an AP enabled with the band steering function must use the
same SSID and security policy. The band steering function cannot be deployed on a single-
radio AP.
2. To allow STAs to preferentially associate with the 5 GHz radio and achieve better access
effect, configure larger power for the 5 GHz radio than the 2.4 GHz radio.
2.2.5.8 Wireless Roaming Design

On a WLAN network, STAs are devices with mobile communication capabilities.
However, the coverage area of a single AP is limited. As users move out of range
of one AP, they usually roam to another AP. Therefore, ensuring a smooth service
experience when a user moves between different APs is key to the WLAN network
quality. As shown in Figure 2-52, WLAN roaming enables STAs to move from the
coverage area of an AP to that of another AP with nonstop service transmission.

Figure 2-52 WLAN roaming
WLAN roaming is mainly used to:

● Retain users' IP addresses. In this way, users can still access the initially
associated network and continue their services after roaming.
● Avoid packet loss or service interruption caused by long-term authentication.
Layer 2/3 Roaming and Inter-WAC Roaming

Depending on whether the service VLAN of STAs changes before and after
roaming, WLAN roaming can also be classified into Layer 2 roaming and Layer 3
roaming. Depending on the roaming range of STAs, WLAN roaming is classified
into intra-WAC roaming and inter-WAC roaming.

Figure 2-53 Layer 2 roaming
In Layer 2 roaming, the service VLAN and gateway remain unchanged after STA
roaming, and traffic can be directly forwarded on the new AP. During WLAN
deployment, Layer 2 roaming is recommended. In the case of a single WAC, the
user gateway can be deployed on the WAC or a core switch at an upper layer. In
the case of multiple WACs (deployed in off-path or in-path mode), it is
recommended that the gateway be deployed on a core switch at an upper layer,
and inter-WAC roaming (still Layer 2 roaming) be used. During Layer 2 roaming,
the gateway remains unchanged, and either tunnel forwarding or direct
forwarding can be adopted. Select a forwarding mode based on service
requirements.

In Layer 3 roaming, the VLAN and gateway of a STA both change after roaming,
and the STA moves between Layer 3 networks. If different VLANs and gateways
are deployed in different buildings or areas, Layer 3 roaming is used. After
roaming, the STA IP address remains unchanged. On the new network, this IP
address cannot directly communicate with the corresponding gateway, and thus
traffic cannot be forwarded. Therefore, a tunnel must be established between
WACs to forward traffic of the roaming STA to the original gateway. In this case,
an inter-WAC mobility group must be configured, with a tunnel established
between WACs to forward STA traffic. If Layer 3 roaming is required on the
network, the tunnel forwarding mode is recommended because this mode does
not require the setup for a large number of tunnels between APs and allows
traffic to be forwarded only through the roaming tunnel between WACs.
During inter-WAC roaming, especially inter-WAC Layer 3 roaming, service traffic
generated by a STA needs to be redirected to the home WAC through the tunnel
between WACs for forwarding. This complicates STA roaming, and consumes more
WAC resources and inter-WAC link resources. Therefore, in actual deployments,

you are advised to properly plan the WLAN to avoid possible inter-WAC roaming.
For example, configure APs in the same building or at the same site to be
managed by the same WAC. If inter-WAC roaming is inevitable, properly plan the
number of members in the mobility group to reduce resource consumption caused
by user information synchronization between mobility group members.
Key Points in Designing the In-Roaming Packet Loss Rate and Handover
Delay
Apart from the basic roaming functions, the packet loss rate and handover delay
during STA roaming are also important indicators to consider. For example, in
industrial manufacturing scenarios, the automated guided vehicles (AGVs) used in
warehouses and factories require the network system to deliver a packet loss rate
less than 1% and a roaming delay less than 100 ms.
To this end, when designing wireless roaming, you are advised to:
● Ensure signal coverage continuity. That is, ensure no coverage hole exists in
areas where roaming is required. Keep a 10% to 15% signal overlap between
the coverage areas of neighboring APs to ensure smooth STA roaming
between the APs.
● Enable fast roaming function in order to reduce the handover delay and
minimize the packet loss probability.
Huawei WLAN supports pairwise master key (PMK) fast roaming and 802.11r fast
roaming. Table 2-23 lists the handover delay of STAs in different roaming modes.
Fast roaming can be enabled as required.
Table 2-23 STA handover delay in different roaming modes

Roaming Mode Hand Suggestion Description
over
Dela
y
(ms)
Open or 802.11r < 50 If the ● 802.11r fast roaming requires

roaming ms Protected that STAs also support this
Manageme function. Currently, mainstream
nt Frame models support 802.11r fast
(PMF) roaming.
function is ● The 802.11r fast roaming and
not PMF functions are mutually
required, it exclusive. If the 802.11r fast
is roaming function has been
recommend configured, the PMF function
ed that the cannot be configured.
802.11r fast
roaming
function be
enabled.


over
Dela
y
(ms)
WPA-PSK/WPA2- < 100 This PMK fast roaming requires that

PSK/802.1X fast ms function STAs also support this function.
roaming (PMK) takes effect Currently, almost all STAs support
automatical PMK fast roaming, which delivers
ly. better compatibility than 802.11r
fast roaming.
802.1X non-fast < 250 This is a N/A

roaming: ms basic
function of
the system
which takes
effect
automatical
ly.
● Enable the device-pipe synergy function. The 802.11r roaming enhancement

mechanism between Huawei APs and Huawei STAs can reduce the roaming
delay to about 10 ms.
Smart Roaming
Dumb terminals and some outdated STAs have low roaming aggressiveness. As a
result, they stick to the initially connected APs regardless of the long distance from
the APs, weak signals, or low rates. The STAs do not roam to neighboring APs with
better signals. Such STAs are generally called sticky STAs. The negative impact of
sticky STAs is described as follows:
● The service experience of a sticky STA is poor, and such a STA is always
associated with an AP with poor signal strength. As a result, the channel rate
decreases significantly.
● The overall performance of wireless channels is affected. A sticky STA may
encounter frequent packet loss or retransmission caused by poor signal
quality and low rates, and therefore occupies the channel for a long time. As
a result, other STAs cannot obtain sufficient channel resources.
To reduce the impact of sticky STAs on a WLAN, you are advised to enable smart
roaming. The smart roaming function intelligently identifies sticky STAs on the
network and proactively directs them to APs with better signals in a timely
manner. This function improves user experience in terms of the following aspects:
● Better performance: Smart roaming can direct poor-signal STAs to APs with
better signals, improving user service experience and overall channel
performance.
● Load balancing: Smart roaming ensures that each STA is associated with the
nearest AP, achieving inter-AP load balancing.

AI Roaming
In smart roaming, APs scan STAs on their operating channels, which may lead to
the following problems that affect the roaming effect:
● The operating radio of an AP is used to scan STAs. If no STA is scanned, the
generated roaming neighbor information may be incomplete, affecting
roaming steering.
● A unified roaming steering mechanism is used during smart roaming, without
distinguishing STAs. As the roaming sensitivity varies with different STAs, the
mechanism may fail in some cases.
● During smart roaming, the Received Signal Strength Indicator (RSSI) of a STA
is detected by the AP, but not in the opposite way. Therefore, the roaming
neighbor to which the STA is steered may not be the optimal one.
The AI roaming feature can be deployed to resolve the preceding problems. As
illustrated in Figure 2-55, AI roaming utilizes intelligent analysis algorithms to
profile the roaming capabilities of STAs, identify such capabilities of different STA
types and operating system versions, and provide targeted roaming steering for
the STAs, improving the roaming steering success rate. Combined with the
independent scanning radio (a third radio) feature, AI roaming uses a fixed radio
for real-time STA scanning to obtain the AP's RSSI that STAs detect through STAs'
RSSI measurement packets. In this way, more complete and effective information
about roaming neighbors is available, so that the optimal AP to which a STA is to
roam can be identified, enhancing user experience during roaming.
Figure 2-55 AI roaming process

When deploying AI roaming, ensure that roaming profiles of STAs are available,
which are used to obtain STAs' roaming characteristics for differentiated steering.
The system has built-in STA profile files and can dynamically generate roaming
profiles of STAs on the live network through online real-time learning. In addition,
AI roaming depends on terminal identification. That is, the roaming profile of a
STA can be matched only after the STA is identified. The WAC has a built-in
terminal fingerprint database, which can help identify STAs, without the need to
work with iMaster NCE-Campus.
AI roaming depends on hardware and feature deployment. Pay attention to the
following when deploying this feature:
● AI roaming depends on the terminal identification capability of the WAC. The
WAC has a built-in terminal identification database that cannot be upgraded
currently. Therefore, some new STAs may not be identified.
● AI roaming needs to work with the independent scanning radio (a third
radio), that is, the AP with this feature deployed must support such a radio.
Some AP models support an independent scanning radio only after they have
a right-to-use (RTU) license loaded. Therefore, this feature can be deployed
only when the hardware conditions are met.
● AI roaming supports roaming steering only for STAs working on the 5 GHz
frequency band. Therefore, a 5 GHz SSID must be deployed on the network.
● AI roaming is mutually exclusive with the PMF feature, and therefore cannot
work for a device with the PMF feature enabled.
2.2.5.9 Wireless Location Design
2.2.5.9.1 Wireless Location Solution Overview

Three mainstream wireless location solutions are available: Wi-Fi location,
Bluetooth location, and ultra-wideband (UWB) location. The Wi-Fi location and
Bluetooth location solutions can locate both Wi-Fi and Bluetooth tags and
terminals. The UWB location solution currently can locate only UWB tags.
Wireless tag location technology uses radio frequency identification (RFID) devices
and a location system to locate a specific target via a WLAN. This technology
involves locating Wi-Fi, Bluetooth, and UWB tags. To implement wireless tag
location, an AP collects and sends tag information to a location server. The
location server then calculates the physical location of the tag and sends the
calculated data to a third-party device so that the user can view the location of
the target tag through a map or table. Huawei's end-to-end wireless tag location
solution is provided in cooperation with third-party vendors in the industry.
Wireless terminal location involves locating Wi-Fi and Bluetooth terminals.
● Wi-Fi terminal location technology locates terminals based on wireless signal
strength information in the surrounding environment collected by APs. To be
specific, an AP reports the collected wireless signal information transmitted by
a Wi-Fi terminal to a location server. The location server calculates the
location of the terminal according to the obtained wireless signal information
as well as the AP's location, and then displays the terminal's location to the
user. The Wi-Fi terminal location solution can be implemented by using
Huawei WLAN devices (the location engine of iMaster NCE-CampusInsight
serves as the location server) or by cooperating with third-party partners.

● Bluetooth terminal location includes two location methods: terminal-side

location and network-side location. In terminal-side location, a Bluetooth base
station or a built-in Bluetooth module of an AP actively broadcasts an
iBeacon frame. After scanning and obtaining the iBeacon frame, a terminal
interacts with a location engine for calculating the location through a
particular location algorithm. (Typically, the location engine provides the SDK
to calculate the location on the terminal) In network-side location, the built-
in Bluetooth module of an AP scans and collects Bluetooth iBeacon broadcast
frames and signal strength information in the surrounding environment, and
reports them to a location server. With the obtained signal strength and AP
location, the location server can calculate the location of a specific terminal.
2.2.5.9.2 Deployment Suggestions for Wireless Location

Table 2-24 describes the capabilities and application scenarios of the wireless
location solutions.
Table 2-24 Comparison of wireless location solutions

Ite Wi-Fi Location Bluetooth Location UWB Location
m
Sup Trail Asset Cust Asset Indoor Personn Geo-

port playbac locatio ome location navigation el fencing
ed k n r location
app flow
lica anal
tion ysis
s
Loc Networ Networ Net Network- STA-side Network Network

atio k-side k-side wor side location -side -side
n locatio locatio k- location location location
met n n side
hod loca
tion
Loc 5m@ 10 m 5m 10 m @ 5m@ 50 cm @ 50 cm @

atio 90% @ 90% @ 90% 90% 90% 90%
n 90
acc %
ura
cy
Loc 10 60 60 60 seconds 3 seconds 1 second 60

atio second second seco seconds
n s s nds
upd
ate
del
ay


m
STA Mobile Wi-Fi Mo Bluetooth Mobile UWB tag UWB tag

typ phone tag bile tag phone
e pho
ne
Coo Locatio Locatio Loc Location Location Location Location

per n n atio engine engine engine engine
ativ engine engine n Map Map Asset Asset
e Map Map engi engine engine manage manage
com engine engine ne ment ment
pon BI server BI server
BI BI Ma server server
ent p BLE tag BLE
s server server beacon UWB UWB
engi card card
Wi-Fi ne
tag UWB tag UWB tag
BI
serv
er


m
Net ● The AP installation ● The AP ● The AP ● The distance

wor height is no more installat installat between UWB
k than 5 m. ion ion anchors is no
dep ● The spacing between height height less than 3 m.
loy APs is no more than is no is no ● It is
me 20 m. more more recommended
nt than 3 than 5 that the area
sug ● All APs have m. m.
omnidirectional length and width
gest ● The ● The ratio be less than
ions antennas.
spacing spacing 3:1.
● At least three APs in betwee betwee
each location can ● The distance
n APs is n APs is between
collect packets from no more no
STAs. adjacent UWB
than 15 more anchors does not
● No obstacle exists m. than 8 exceed the
between APs and ● At least m. maximum
STAs. three ● A STA distance of
APs can can signal coverage.
collect collect ● The AP
packets packets installation
from from at height is smaller
Bluetoo least than 5 m.
th tags. three
● No APs.
obstacle ● No
exists obstacle
betwee exists
n APs betwee
and n APs
STAs. and
STAs.
For details about the principles of the cooperation solution between Huawei and
third-party location vendors as well as device selection, see related documents at:
https://e.huawei.com/en/material/bookshelf/bookshelfview/202004/03160039
2.2.5.9.3 Wireless RSSI-based Location Engine

The wireless location solution can work with the location engine provided by
iMaster NCE-CampusInsight to locate and display STAs, Wi-Fi interference sources,
and non-Wi-Fi interference sources. Figure 2-56 demonstrates Huawei's wireless
RSSI-based location solution architecture.

Figure 2-56 Wireless RSSI-based location solution architecture
Precautions for wireless RSSI-based location solution design:

● You are advised to use a professional WLAN planning tool to assist in
selecting and deploying APs. Deploy APs in W-shaped pattern and at a height
of less than or equal to 5 m to ensure that STAs can be scanned by more than
three APs at any position
● Ensure that APs are reachable to iMaster NCE-CampusInsight so that location
data can be sent to its location engine.
● Make sure that the device clock is synchronous with the clock of iMaster NCE-
CampusInsight. An NTP server is recommended for network system clock
synchronization.
● To use the location engine for locating non-Wi-Fi interference sources, you
need to enable spectrum analysis on the device. When there are two or more
non-Wi-Fi interference sources of the same type in a region, the number of
them cannot be displayed on iMaster NCE-CampusInsight.
● In the case that the network needs to work with a third-party location system,
iMaster NCE-CampusInsight needs to directly provide the map and terminal
location information needed by the location system through unified
northbound APIs; the third-party location system needs to parse the data
calculated by iMaster NCE-CampusInsight.
2.2.6 Egress Network Design
2.2.6.1 Security Zone Design
Security Zone Overview

A security zone is a collection of networks connected through one or more
interfaces. Users on the networks in a security zone have the same security
attributes. Most security policies are implemented based on security zones. Each

security zone identifies a network, and a firewall connects networks. Firewalls use
security zones to divide networks and mark the routes of packets. When packets
travel between security zones, security check is triggered and corresponding
security policies are enforced. Security zones are isolated by default.
Generally, there are three types of security zones: trusted, DMZ, and untrusted.
● Trusted zone: refers to the network of internal users.
● DMZ: demilitarized zone, which refers to the network of internal servers.
● Untrusted zone: refers to untrusted networks, such as the Internet.
Security Zone Planning

A campus network itself is considered secure, but is faced with security threats
from the outside. Therefore, allocate the Internet to the untrusted zone and the
campus network to the trusted zone. Deploy security devices at the campus
network egress to isolate the intranet from the Internet and defend against
external threats. Allocate the data center to the DMZ, and deploy firewalls in the
DMZ to isolate traffic between the campus intranet and servers in the data center.
In the virtualized campus network solution, when user gateways are located inside
the fabric, each egress of the fabric's external network resources corresponds to a
Layer 3 logical interface on the firewall. During egress planning for external
network resources, VNs with the same security policy have been divided according
to different logical egresses. Therefore, in this solution, security zones can be
divided based on the interfaces of external network resources, and each logical
interface is assigned a security zone, as shown in Figure 2-57. If user gateways are
located outside the fabric, you need to bind the gateways to security zones based
on the security policies of the gateways.
Figure 2-57 Firewall security zone division when user gateways are located inside
the fabric

2.2.6.2 Hot Standby Design

When firewalls function as egress devices, you are advised to deploy hot standby
(HSB) to improve firewall reliability. As illustrated in Figure 2-58, the firewalls act
as egress devices of the campus network and are directly connected to the stacked
core switch. The two firewalls are configured to work in HSB mode, and the
member links in their interconnected Eth-Trunk are in active/standby mode. When
the active firewall is faulty, the standby firewall takes over services and forwards
service packets.
Figure 2-58 Deploying firewalls in HSB mode
2.2.6.3 Egress Route Design

Egress routes of the campus network are used for north-south communication
between the campus intranet and external networks. When a firewall is used as
the egress device, you need to consider the routes from the firewall to external
networks and those between the firewall and the core switch.
Routes from the Firewall to External Networks: Intelligent Traffic Steering

If the campus network connects to only one Internet Service Provider (ISP)
network, you do not need to perform refined control on the routes to the external
network. In this case, you can configure a default route on the firewall and set the
next hop of the route to the PE on the ISP network.
If the campus network connects to multiple ISP networks, users can access
Internet resources through different ISP networks. To properly utilize egress links
and ensure egress access quality, you are advised to configure the intelligent
traffic steering function on the firewall. In this scenario, it is recommended that
you deploy the ISP-based traffic steering function. This function routes traffic
destined for a specific ISP network out through the corresponding outbound
interface, ensuring that traffic is forwarded on the shortest path.
As shown in Figure 2-59, the firewalls each have two ISP links to the Internet. If a
campus network user accesses Server 1 on ISP 2 network and the firewall has

equal-cost multi-path routing (ECMP) routes, the firewall can forward the access
traffic from two different paths to Server 1. Apparently, path 1 is not the best
path, and path 2 is the most desired path. After you configure ISP-based traffic
steering, when an intranet user accesses Server 1, the firewall selects an outbound
interface based on the ISP network where the destination address resides to
enable the access traffic to reach Server 1 through the shortest path, that is, path
2 in Figure 2-59.
Figure 2-59 Intelligent traffic steering
Routes from the Firewalls to External Networks (Off-Path Deployment of

Firewalls)
Figure 2-60 shows the egress networking of a large or midsize campus where
firewalls are deployed in off-path mode. The intranet traffic from the core switch
passes through the firewalls and then returns to the core switch, and then is
forwarded to the egress routers to access the external network. The path of the
outbound traffic of users on the campus network is as follows: core switch ->
firewall -> core switch -> egress router. In this case, the traffic is sent to the
external network through the egress routers.
The network configuration consists of two parts: core switch -> firewall and
firewall -> core switch -> egress router.
● Core switch -> firewall: On the core switch, L3 egress is configured for the
fabric for interconnection with the southbound interfaces of the firewalls. The
firewalls are deployed in VRRP hot standby (HSB) mode and connect to the
core switch through the southbound interfaces. It is recommended that static
routes be used between firewalls' southbound interfaces and the core switch.
● Firewall -> core switch > egress router: It is recommended that OSPF be
configured to implement communication. When configuring OSPF on
firewalls, you need to import the static routes from the firewalls destined for
the campus intranet. When configuring OSPF on egress routers, you need to
import the default routes from the egress routers destined for the external
network. Interfaces connecting the core switch to the firewalls and egress

routers need to be added to additional VPN instances for isolation from other
traffic.
Figure 2-60 Egress network diagram (firewalls deployed in off-path mode)
Routes Between the Firewall and the Core Switch

North-south routes are present between the firewall and the core switch, including
routes from the campus intranet to external networks on the core switch as well
as return routes from external networks to the campus intranet on the firewall. In
the virtualization solution for large- and medium-sized campus networks, under
the external network resource model designed for the fabric, the routing protocol
used for Layer 3 connectivity between the firewall and the core switch (border
node) can be static routing, OSPF, or BGP. Generally, two firewalls are deployed in
HSB mode to ensure reliability. When selecting a routing protocol, take into
consideration how to switch the service traffic path in an active/standby
switchover scenario.
● Static routing
If two firewalls implement HSB by operating as a VRRP master and a VRRP
backup, static routing is recommended. As illustrated in Figure 2-61, a default
static route is configured on the core switch, with the next hop being the
virtual IP address of the VRRP group. When the master firewall in the VRRP
group is in the master state, it responds to the ARP request containing a
virtual IP address sourcing from the core switch. In this way, the service traffic
on the core switch can be diverted to the master firewall for processing.
In the event of a failure on the master firewall, the backup firewall in the
VRRP group becomes the new master and broadcasts a gratuitous ARP packet
that carries the virtual IP address of the VRRP group and the MAC address of
the corresponding interface (virtual MAC address is carried if the virtual MAC

address function is enabled on the interface). After receiving the gratuitous

ARP packet, the core switch updates its ARP table. Thus, the service traffic
path is switched to the backup firewall.
Figure 2-61 Using static routing between the firewall and the core switch
● Dynamic routing
If VRRP is not deployed on firewalls, dynamic routing can be used to
implement automatic switching of the service traffic path. In this case, you
need to run the hrp standby-device command on the standby firewall to set
it to the standby state. As shown in Figure 2-62, OSPF is used as an example.
When both the active and standby firewalls work properly, the active firewall
advertises routes based on the OSPF configuration, and the cost of the OSPF
routes advertised by the standby firewall is adjusted to 65500 (default value,
which can be changed). In such a scenario, the core switch selects a path with
a smaller cost to forward traffic, and all service traffic is diverted to the active
firewall for forwarding.
If the active firewall is faulty, the standby firewall converts to the active state.
In addition, the VRRP Group Management Protocol (VGMP) adjusts the cost
of the OSPF routes advertised by the active firewall to 65500 and that of the
OSPF routes advertised by the standby firewall to 1. After route convergence
is complete, the service traffic path is switched to the standby firewall.
Figure 2-62 Using dynamic routing between the firewall and the core switch

For details about the deployment when using different routing protocols between
the firewall and the core switch, see the external network design in 2.2.4.3 Fabric
Network Design.
2.2.6.4 Security Policy Design

After security zones are divided on the firewall based on source interfaces, the
security zones are isolated by default. To allow communication between two
security zones, for example, to enable users within the campus intranet to access
the Internet, Layer 3 routes need to be configured on the firewall. In addition, you
need to create security policies on the firewall to allow the traffic between the
security zones. Security policies also provide advanced security protection
functions to analyze security threats in each zone and ensure secure, trustworthy
access sources.
As shown in Figure 2-63, with security policies configured, VNs on the campus
network can communicate with each other, and the external network can access
servers in the DMZ. In addition, different security protection policies can be
implemented for traffic in different security zones.
Figure 2-63 Applying security policies
Table 2-25 describes the recommended security policy design for common zones.

Table 2-25 Recommended security policy design for common zones

Access Network Access Source Trustworthiness Recommended
Represented by Security Policy
the Security
Zone
Internet External users Untrusted Intrusion

detection, URL
Employees on the Medium filtering, and
go antivirus
WAN Enterprise branch Medium Intrusion

detection and
antivirus
Intranet Enterprise High Intrusion

employees detection and
antivirus
Guests Low
2.2.6.5 NAT Design

Network Address Translation (NAT) is an address translation technology that
translates both the source and destination IP addresses of packets. To allow
campus intranet users using private IP addresses to access the Internet, configure
NAT. As demonstrated in Figure 2-64, if firewalls function as egress devices, pay
attention to the following points when configuring NAT:
Figure 2-64 NAT design

● If private IP addresses are used on the intranet, source NAT technology needs
to be used to translate source IP addresses of packets to public IP addresses
when user traffic destined for the Internet passes through the firewall.
Network Address Port Translation (NAPT) is recommended to translate both
IP addresses and port numbers, which enables multiple private addresses to
share one or more public addresses. NAPT applies to scenarios with a few
public addresses but many private network users who need to access the
Internet.
● If intranet servers are used to provide server-related services for public
network users, destination NAT technology is required for translating
destination IP addresses and port numbers of the access traffic of public
network users into IP addresses and port numbers of the servers in the
intranet environment.
● When two firewalls operate in VRRP hot standby (master/backup) mode, IP
addresses in the NAT address pool may be on the same network segment as
the virtual IP addresses of the VRRP group configured on the uplink interfaces
of the firewalls. If this is the case, after the return packets from the external
network arrive at the PE, the PE broadcasts ARP packets to request the MAC
address corresponding to the IP address in the NAT address pool. The two
firewalls in the VRRP group have the same NAT address pool configuration.
Therefore, the two firewalls send the MAC addresses of their uplink interfaces
to the PE. In this case, you need to associate the hot standby status (master/
backup) of the firewalls with the NAT address pool on each firewall, so that
only the master firewall in the VRRP group responds to the ARP requests
initiated by the PE.
2.2.7 Access Control Design
2.2.7.1 Overall Access Control Design

In the traditional NAC solution, NAC authentication and ACL policies are
implemented. For a campus network, an authentication control point is defined to
perform access authentication and policy control on user terminals connected to
the campus network. Huawei's access control solution combines the traditional
NAC solution with policy association and free mobility to refine the division of
device roles in campus network access control.
● Authentication control point: authenticates users and interacts with an

authentication server to implement authentication, authorization, and
accounting. In the policy association solution, a CAPWAP tunnel is established
between the authentication control point and authentication enforcement
point to exchange user authentication requests and synchronize user entries.
● Authentication enforcement point: controls user access in the policy
association solution. Users can access the network only after being
authenticated successfully. In addition, the authentication enforcement point
transparently transmits user authentication packets to the authentication
control point. The authentication control point can be configured to deliver
user authorization policies to the authentication enforcement point.
● Policy enforcement point: is a device that enforces control policies. Generally,
the authentication control point functions as the policy enforcement point.
For example, in the traditional NAC solution based on NAC authentication

and ACL policies, an authentication server authorizes ACL information to

authenticated users. The authentication control point then performs policy
control on users accessing the network based on the authorized ACL
information. The authentication control point and policy enforcement point
can be deployed separately. In the following example, a standalone WAC is
connected to the core switch in off-path mode; the standalone WAC functions
as the wireless authentication control point, and the core switch functions as
the wireless policy enforcement point.
Figure 2-65 shows the user access control design for the centralized gateway
solution using the recommended networking modes.

Figure 2-65 User access control in the centralized gateway solution
NAC Server Selection

In the centralized gateway solution, iMaster NCE-Campus delivers service
configurations to campus network devices and implements automatic network
deployment. iMaster NCE-Campus can also function as a NAC server, removing
the need to deploy an additional NAC server for network access control. When

iMaster NCE-Campus functions as a NAC server, it provides the following access

control functions:
● Built-in RADIUS server and Portal server components: These components

support 802.1X authentication, Portal authentication, MAC address
authentication, and MAC address-prioritized Portal authentication.
● Multiple Portal authentication modes: Portal authentication supports user
name and password authentication, SMS authentication, and third-party
social media authentication.
● Terminal identification: iMaster NCE-Campus can implement automatic MAC
address authentication based on terminal identification.
● Free mobility: iMaster NCE-Campus can deliver security group policies to the
policy enforcement point, removing the need to configure security group
policies on the policy enforcement point. iMaster NCE-Campus can also
function as a RADIUS server and allows administrators to specify security
group information when configuring authorization results.
Authentication Control Point Selection

In the centralized gateway solution, the authentication control point is deployed
as follows:
● It is recommended that the authentication control point for wired user access
be deployed on the edge node. When configuring access management for a
fabric, you need to configure the authentication control point for wired user
access. For details, see "Access Management Design" in 2.2.4.3 Fabric
Network Design.
WAC. For details about the planning and design of the authentication control
point for wireless user access, see "WLAN Admission Design" in 2.2.5 WLAN
Design.
In the centralized gateway solution, you are advised to deploy a VXLAN across
core and access layers for fabric networking. If the VXLAN is deployed across core
and aggregation layers (for example, in the device reuse and reconstruction
scenario), policy association can be deployed between an aggregation switch
(functioning as an edge node) and access switch.
● The edge node functions as the authentication control point to authenticate

users and control access switches on executing user access policies.
● The access switch functions as the authentication enforcement point to
control user access. Users can access the network only after being
authenticated successfully.
Authentication Enforcement Point Selection

In the centralized gateway solution, the authentication enforcement point is
deployed as follows:
● It is recommended that the wired authentication enforcement point be

deployed on an access switch on the campus network so that the access
switch can control access of wired user terminals. In the centralized gateway
solution, you are advised to deploy a VXLAN across core and access layers for

fabric networking. In this way, the edge node can function as both the
authentication control point and authentication enforcement point. In a few
network device reuse scenarios, the VXLAN is deployed across core and
aggregation layers, and an aggregation switch functions as the edge node. In
this deployment mode, policy association can be deployed between the edge
node and access switch. In this way, the wired authentication control point
does not need to be moved down from the edge node to the access switch,
the number of wired authentication control points does not increase, and the
wired authentication enforcement point that controls access of wired user
terminals still sits on the access switch.
● Policy association is designed based on the traditional "WAC + Fit AP"
architecture for access control. In this architecture, WACs function as wireless
authentication control points and APs as wireless authentication enforcement
points. Wireless user authentication information is synchronized between
WACs and APs through CAPWAP tunnels. The AP prevents unauthorized users
from accessing the campus network.
Policy Enforcement Point Selection

In the centralized gateway solution, the policy enforcement point is deployed as
follows:
● It is recommended that the edge node be configured as both the wired
authentication control point and wired policy enforcement point to deploy
security group policies for free mobility. iMaster NCE-Campus can dynamically
generate IP-security group entries and deliver the entries to the edge node
based on the security group information configured in the authorization result
of wired users. The edge node then enforces security group policies for
authorized wired users based on the IP-security group entries.
On a traditional non-virtualized network where multiple authentication
control points exist, configure IP-security group entry subscription to
synchronize IP-security group entry information between different
authentication control points. This ensures that the authentication control
points can implement access control based on security group policies across
authentication control points when they function as policy enforcement
points. On a virtualized network, you do not need to configure IP-security
group entry subscription because the VXLAN header encapsulated in user
packets carries security group information when user packets are forwarded
across authentication control points.
● It is recommended that the border node be used as the wireless policy
enforcement point for deploying security group policies for free mobility.
– In the recommended networking where the border node functions as the
native WAC, you should configure the border node as both the wireless
authentication control point and wireless policy enforcement point for
deploying security group policies for free mobility. iMaster NCE-Campus
can dynamically generate IP-security group entries and deliver the entries
to the border node based on the security group information configured in
the authorization result of wireless users. The border node then enforces
security group policies for authorized wireless users based on the IP-
security group entries.
– In device reuse scenarios, if the existing WAC does not support the free
mobility function, the border node to which the WAC connects in off-path

mode can be used as the wireless policy enforcement point for deploying
security group policies for free mobility. When the border node functions
as the wireless policy enforcement point, it is not a wireless
authentication control point and cannot obtain IP-security group entry
information through user authentication and authorization. Therefore,
you need to enable IP-security group entry subscription on the border
node.
2.2.7.2 User Authentication Mode Selection

Common authentication technologies include 802.1X, MAC address, and Portal
authentication. Table 2-26 compares these authentication modes and describes
their applicable terminal types.
Table 2-26 Different user authentication technologies and applicable terminal

types
Item 802.1X Authentication MAC Address Portal Authentication
Authentication
Client Required Not required Not required
Advanta High security ● No client Flexible deployment

ge required
● No need to
manually
enter the user
name and
password
Disadvan Inflexible deployment MAC address Low security

tage registration
required, making
management
complex
Applicabl Employees' terminals Dumb terminals Guest terminals:

e that need to access the such as printers Generally, guests move
terminal office network and and fax frequently, and
type have high security machines terminal types are
requirements complex.
MAC address-prioritized Portal authentication: After a user terminal passes

Portal authentication, the authentication server caches the user terminal address
within a specified period. During this period, the user can directly access the
network, without entering the user name and password, as long as they pass MAC
address authentication.
Use MAC address-prioritized Portal authentication for guest terminals to improve
network experience of guests.

2.2.7.3 Policy Control Solution Design

Policy control is to control the permissions of users on network resource access.
Currently, the traditional NAC solution and Huawei's free mobility solution are
available for policy control. Table 2-27 compares the two solutions.
Table 2-27 Policy control solution comparison

Polic Contro Characteristics Application Scenario
y l Mode
Cont
rol
Solut
ion
Tradit VLAN ● The administrator needs to ● Users access the

ional + ACL plan a large number of IP network at fixed
NAC addresses, VLANs, and ACLs, locations.
soluti making the configuration ● Permission policies are
on workload heavy and capacity simple.
expansion or configuration
change complex.
● It is difficult to control the
access permissions of users as
well as ensure consistent user
priority and bandwidth when
they move.
Free Securit Administrators do not need to ● Mobile working is

mobil y pay attention to IP address and required, and users can
ity group VLAN assignment. User policies access the network at
soluti + are configured on the controller any location.
on inter- based on security groups and are ● Permission policies are
group automatically delivered to all complex.
policy authentication devices,
eliminating the need to perform
complex configuration.
The free mobility solution is recommended for policy control on large- and
medium-sized campus networks. If the existing campus network of the customer
does not support the free mobility solution, use the traditional NAC solution.
Traditional NAC Solution Design

In the traditional NAC solution, policies fall into two categories: static ACL policies
on local devices and dynamic ACL policies authorized by the NAC server.
Essentially, configuring static ACL policies on local devices is to map user policies
to user IP addresses and plan ACL rules based on these IP addresses for
management and control over user permissions. This type of policy applies to the
scenario where the user network scale is small, locations of user terminals are
fixed, and policy requirements are simple. As the network scale increases and
policy requirements become complex, configuring such policies can be very

complex and difficult to maintain. Therefore, for large- and medium-sized campus
networks, you are advised to use the NAC server to authorize dynamic ACL
policies. With this approach, terminals do not need to be strictly bound to IP
addresses and VLANs, making IP and VLAN planning flexible, as shown in Figure
2-66. When different types of users are present, you are advised to restrict access
locations of the users. That is, users with different permissions access the Internet
from their respective areas specified by the administrator. This ensures that only
related policies need to be configured on devices in these areas. Otherwise, it will
be difficult to configure policies and perform O&M.
Figure 2-66 Policy control based on the traditional NAC solution
Free Mobility Solution Design

Different from the traditional IP address-based ACL mode, free mobility is a user
language-based solution that logically divides different types of network objects
with distinct permissions into different security groups. Each security group maps
one user type and one server type. Then, you can define policies for users in
different security groups to communicate for access control, as shown in Figure
2-67.

Figure 2-67 Policy control based on the free mobility solution
iMaster NCE-Campus provides an intuitive policy matrix to allow the administrator

to configure security group policies and deliver the policies to policy control points.
Assume that A and C are user groups, and B and D are server groups. Members in
group A can communicate with those in groups C and D, while members in group
C can only communicate with those in group D. Members of group A or group C
can communicate within their groups. The corresponding policy design is shown in
Table 2-28. The communication between B and D does not pass through the
campus network and does not need to be planned. In this case, the policy design
between B and D is displayed as NA in the following table. In cells filled with
Empty, no policy is configured, or the permit/deny policy is configured, which does
not influence the control effect.
Table 2-28 Security group policy plan

Source/ A B C D
Destination
Security
Group
A Permit Deny Permit Permit
B Empty NA Empty NA
C Deny Deny Permit Permit
D Empty NA Empty NA
iMaster NCE-Campus allows administrators to configure a rule from a group to

the Any group (that is, default permissions of the group), reducing the number of

policies that need to be defined and thereby simplifying policy configuration. For
example, as described in Table 2-28, an administrator simply needs to configure a
policy for denying access from group A to group B so that access from group A to
the Any group is permitted.
2.2.7.4 Authentication Bypass Design

The bypass mechanism grants specified network access rights to users when the
authentication server goes Down, when users fail the authentication, or when
users are in pre-connection state. Authorization for users who fail to be
authenticated is also known as authentication bypass. With this mechanism, users
can obtain necessary rights (such as downloading the authentication client) before
being authenticated. In addition, when the authentication server is faulty or the
network between the authentication device and authentication server is abnormal,
users can still have certain network access rights. The authentication bypass
function supports MAC address authentication, 802.1X authentication, and Portal
authentication.
Bypass Design in Scenarios Where the Server Goes Down

When the authentication server or Portal server is faulty, or the communication
between the authentication device and authentication server or Portal server fails,
the authentication device can detect that the authentication server or Portal
server goes Down through server status detection. In this case, the following two
bypass policies are available:
● Policy 1: Authenticated users can continue accessing the network, and new
users are not allowed to access the network.
● Policy 2: New users are allowed to access the network, and a bypass policy is
applied.
If the customer requires high network security, policy 1 is recommended. If the
customer requires low network security or high network reliability, policy 2 is
recommended.
After the authentication device identifies that the authentication server or Portal
server is Up, you are advised to configure the device to re-authenticate the users
in authentication bypass state so that the users can obtain network access rights
properly.

Table 2-29 User authentication bypass capabilities

User Type MAC Address 802.1X Portal Authentication
Authentication Authentication
Wired user ● Supports bypass ● Supports bypass ● Supports bypass

to be when the when the when the Portal
authenticat authentication authentication server goes Down.
ed by server goes server goes ● Supports
switches Down. Down. configuration on
● Supports ● Supports NCE-Campus.
configuration on configuration on ● Bypass policies
NCE-Campus. NCE-Campus. support security
● Bypass policies ● Bypass policies group and ACL
support VLAN, support VLAN, authorization.
security group, security group,
and ACL and ACL
authorization. authorization.
Wireless ● Supports bypass ● Bypass when ● Supports bypass

users to be when the the when the Portal
ed by the server goes server goes ● Supports
switch's Down. Down is not configuration on
native ● Supports supported. NCE-Campus.
WAC configuration on ● Bypass policies
NCE-Campus. support security
● Bypass policies group and ACL
support VLAN, authorization.
security group,
and ACL
authorization.
Wireless ● Supports bypass ● Bypass when ● Supports bypass

users to be when the the when the Portal
ed by the server goes server goes ● Supports web/CLI-
standalone Down. Down is not based
WAC ● Supports web/ supported. configuration.
CLI-based ● Bypass policies
configuration. support user group
● Bypass policies authorization.
support user
group
authorization.

NOTE
● Only bypass in wired user authentication and wireless user authentication (native WAC)
scenarios can be configured on NCE-Campus. In wireless user authentication
(standalone WAC) scenarios, bypass can be configured through the web UI or CLI.
● The Portal server needs to support the heartbeat detection function.
● Bypass policies do not support VLAN authorization for online Portal users.
● Bypass when the authentication server goes Down is not supported for wireless users
using 802.1X authentication In this case, new users are not allowed to access the
network. In standalone WAC scenarios, you can configure an SSID in open-system
authentication mode which is automatically enabled when the authentication server
goes Down. This SSID allows users to access the temporary bypass network.
● In 802.1X authentication for wired users, when the RADIUS server goes Down, some
new clients will fail to go online because they do not have bypass rights. For example,
when a Windows client receives a Success packet from the device, but does not receive
the authentication packets exchanged with the RADIUS server, the client fails the
authentication and cannot go online. Currently, the following clients have bypass rights
when they go online after the user bypass function is configured: H3C iNode clients
using EAP-MD5 and PEAP, and Cisco AnyConnect clients using EAP-FAST and PEAP. For a
Windows client (for example, Windows 7 client), choose Local Area Connection >
Properties > Authentication > Fallback to unauthorized network access to grant
bypass rights to the client.
● NCE-Campus does not support configuration of re-authentication for users in
authentication bypass state after the authentication server or Portal server comes Up.
Bypass Design Before Successful Authentication

Before being successfully authenticated, some users may need certain basic
network access rights to download client software and update the antivirus
database. Bypass policies before successful authentication are as follows:
● Network access rights for users who fail to be authenticated.

● Network access rights for users who are in the pre-connection phase.
NCE-Campus supports the configuration of bypass VLAN authorization. During

web/CLI-based bypass configuration for wireless users in standalone WAC
scenarios, you can configure bypass VLAN authorization for users in the pre-
connection phase, and configure bypass VLAN or user group authorization when
authentication fails.
NOTE
● Only bypass in wired user authentication and wireless user authentication (native WAC)
scenarios can be configured on NCE-Campus. In wireless user authentication
(standalone WAC) scenarios, bypass can be configured through the web UI or CLI.
● Bypass before successful authentication cannot be configured for wireless users using
802.1X authentication
Bypass Design for the NCE-Campus Authentication Server

● Bypass when the third-party data source server goes Down
1. NCE-Campus uses a third-party AD/LDAP server as the data source and

synchronizes account information with the server in AD synchronization mode.
After the bypass function is enabled, if the third-party AD/LDAP server fails to
respond, NCE-Campus does not need to verify the username and password on the

third-party AD/LDAP server. Instead, authentication is successful when the

username and password are successfully verified locally.
2. NCE-Campus functions as the Portal authentication server and uses a third-
party HTTP server as the data source. After the bypass function is enabled,
authentication can still be performed even if the third-party HTTP server is
unreachable.
3. When NCE-Campus interconnects with an MDM server, you can configure "If
the MDM server failed to connect or the query timed out, ignore MDM conditions.
By default, consider the MDM check as having passed" in the authorization rule to
implement the bypass function of the MDM server.
● User license bypass
When NCE-Campus functions as the authentication server and user license
resources are insufficient, you can enable the license emergency mode to
implement 7-day user license bypass within the license validity period. Within the
seven days of user license bypass, NCE-Campus can authenticate new users even if
the number of online users exceeds the user license specifications.
NOTE
● If EAP-PEAP-MSCHAPv2 is used, the third-party AD/LDAP server does not support the
bypass function.
● If NCE-Campus is not in AD synchronization mode, the third-party AD/LDAP server does
not support the bypass function.
● When NCE-Campus functions as both an authentication server and a RADIUS relay
agent in the multi-mode authentication scenario, bypass when the third-party
authentication server goes Down is not supported. It is recommended that all
authentication be deployed on the third-party server.
2.2.7.5 Terminal Identification Design

On large- and medium-sized campus networks, access terminals include PCs,
mobile phones, as well as dumb terminals such as IP phones, printers, and IP
cameras. A large number of terminals of different types need to access the
campus network, making it difficult to manage them. To ease terminal
management, the terminal identification solution offers diversified terminal
identification methods. With iMaster NCE-Campus, you can view the summary
information about terminals on the entire campus network, including their
terminal type and operating system. Based on this information, iMaster NCE-
Campus can perform refined management on terminals from multiple dimensions,
for example, collecting statistics on and displaying traffic by terminal type and
delivering specified authorization policies. Additionally, dumb terminals that
usually use MAC address authentication can be automatically admitted through
terminal identification, reducing manual configuration workload.
2.2.7.5.1 Terminal Identification Method Design

To display terminal types and perform access management based on the terminal
types through iMaster NCE-Campus, the network administrator needs to perform
the following operations:
● Collect the types of terminals on the network, such as PCs, mobile phones,
printers, IP cameras, and access control devices.

● Check whether Portal authentication is deployed on the network.

● Check whether the IP addresses of the terminals are dynamically assigned by
the DHCP server or statically assigned.
Based on the collected information, traverse the items one by one according to
Table 2-30 and select the required terminal identification method. Multiple
methods can be selected to identify terminals. You are advised to enable the
following passive fingerprint-based identification methods: MAC OUI, HTTP
UserAgent, DHCP option, LLDP, and mDNS. It is recommended that Nmap be
disabled by default because its identification period is long. If the preceding
passive fingerprint-based identification methods cannot meet requirements,
enable Nmap.
Table 2-30 Terminal identification methods

Identification Identifiable Application Scenario
Method Terminal Type
MAC OUI All IP terminals Common scenarios (authentication, non-

(identifying only authentication, and dynamic/static IP
the device address assignment scenarios)
manufacturer)
HTTP Mobile phone, Portal authentication scenarios

UserAgent tablet, PC,
workstation
Intelligent audio/
video terminal
DHCP Option Mobile phone, Dynamic IP address assignment scenarios

tablet, PC,
workstation
IP camera, IP
phone, printer
LLDP IP phone, IP Common scenarios (authentication, non-

camera, network authentication, and dynamic/static IP
device address assignment scenarios)
mDNS Apple device, Common scenarios (authentication, non-

printer, IP camera authentication, and dynamic/static IP
address assignment scenarios)
SNMP Query Network device, On-premises scenarios

printer
NMAP PC, workstation On-premises scenarios

Printer, phone, IP
camera
Table 2-31 describes the configuration process of each terminal identification

method in the virtualization solution for large- and medium-sized campus
networks.

Table 2-31 Configuration process of each terminal identification method

Identification iMaster NCE-Campus Network Side
Method Side
MAC OUI Enable the terminal -

identification function.
HTTP UserAgent Enable the terminal Enable the terminal

identification function. identification information
reporting function.
DHCP Option Enable the terminal 1. Enable the terminal

reporting function.
2. Enable DHCP snooping.
LLDP Enable the terminal This function is enabled by

identification function. default.
mDNS Enable the terminal 1. Enable the terminal

reporting function.
2. Enable mDNS snooping.
SNMP Query 1. Enable the terminal -

identification
function.
2. Enable the SNMP
scanning function.
Nmap 1. Enable the terminal -

identification
function.
2. Install the Nmap
plug-in.
2.2.7.5.2 Terminal Control Policy Design

Terminal identification enables iMaster NCE-Campus to deliver control policies to
different types of terminals based on information such as the terminal type,
operating system, or manufacturer. The administrator needs to perform the
following operations:
1. Enable the terminal identification function for the network.
2. Configure user access authentication. Authentication and authorization rules
are matched based on the identified terminal type.
3. Plan authorization policies on iMaster NCE-Campus based on terminal types
and deliver corresponding policies after users are authenticated.
Table 2-32 shows an example of policy authorization based on the terminal type,
operating system, or manufacturer. For dumb terminals that use MAC address
authentication, such as printers, IP phones, and IP cameras, the automatic

admission function based on terminal identification can be used. With this

function enabled, dumb terminals can be plug-and-play and automatically access
the network, eliminating the need to manually enter their MAC addresses on
iMaster NCE-Campus.
Table 2-32 Example of policy control Based on terminal identification results
Condition Admission Policy Authorization Policy
Operating system 1 User admission Authorize ACL 1
Terminal type: printer Automatic admission Authorize VLAN 10
Terminal type: IP camera Automatic admission Authorize VLAN 20
Terminal type: IP phone Automatic admission Authorize VLAN 30; DSCP

48
Terminal type: access Automatic admission Authorize VLAN 40

control device
Manufacturer 1 User admission Authorize ACL 100
NOTE
When terminal identification is used together with the VLAN authorization policy, you can
disable pre-connection in 802.1X and MAC address authentication scenarios to prevent IP
address re-assignment to terminals.
2.2.7.6 Terminal Anomaly Detection and Anti-spoofing Design

Terminal anomaly detection is a technology that determines whether a terminal is
abnormal by identifying whether the traffic of the terminal connected to the
campus network complies with the traffic behavior model for the same type of
terminals. A traffic behavior model defines the characteristics of traffic sent from
terminals to the campus network, such as the access IP address set, TCP/UDP port
set, number of TCP connections, and packet transmission frequency.
Application Scenarios of Device Anomaly Detection

On a large or midsize campus network, dumb terminals, such as IP phones, IP
cameras, and printers, are more likely to be attacked or spoofed than other
terminals. This is because:
● Dumb terminals do not support strong authentication modes such as 802.1X

and Portal authentication. Generally, such terminals use MAC address
authentication or an IP address whitelist to access the network, so they are
easily spoofed by attackers.
● Dumb terminals usually do not have a scheduled antivirus mechanism, and
therefore may be easily implanted with viruses or Trojan horses by network
attackers.

As a result, in dumb terminal access scenarios, you can deploy the terminal
anomaly detection function to detect dumb terminals that are spoofed or attacked
in real time and block their access to the network. This prevents dumb terminals
from being spoofed or attacked, ensuring network security.
Terminal Anomaly Detection Solution Design

The terminal anomaly detection solution consists of terminal information
management, terminal anomaly detection, and terminal anomaly control, as
Table 2-33 Terminal anomaly detection solution
Function Description
Terminal information Basic terminal information, including the MAC

management address, IP address, access location, and terminal
type, is stored on a switch.
Terminal anomaly The switch collects traffic behavior characteristics of

detection terminals and detects terminal anomalies based on
the traffic behavior model.
A switch has a default traffic behavior model for
dumb terminals, including IP phones, IP cameras, and
printers.
Device anormaly control ● The switch identifies abnormal terminals and

reports alarms to iMaster NCE-Campus.
● After an abnormal terminal is identified, you can
configure an isolation policy on the switch to
prevent the terminal from accessing the network.
NOTE
● The terminal anomaly detection function can be configured only on switches using
commands, but not on iMaster NCE-Campus.
● The terminal anomaly detection function applies only to wired access terminals.
● The terminal anomaly detection function supports three types of dumb terminals: IP
phones, IP cameras, and printers.
2.2.7.7 Access Control Design for Huawei iConnect Terminals
2.2.7.7.1 Introduction to Huawei iConnect Terminals

Huawei iConnect terminals are IoT terminals that comply with Huawei iConnect
ecosystem standards.
For example, in the Huawei CloudCampus Solution, Huawei iConnect terminals
that wirelessly connect to the campus network can automatically associate with
the iConnect SSID. The wireless protocol packets exchanged between the Huawei
iConnect terminals and APs contain electronic identity information in a unified

format that meets Huawei iConnect ecosystem standards. The exchanged wireless
protocol packets trigger the first access authentication for Huawei iConnect
terminals. In addition, the authentication packets sent from the WAC to iMaster
NCE-Campus (functioning as the NAC server) also carry electronic identity
information. With this information, iMaster NCE-Campus is able to identify
terminals, and then re-authenticates them and delivers authorization policies
when the terminals access the service SSID.
2.2.7.7.2 Network Deployment Architecture

IoT applications and terminals have been deployed in growing numbers in
campuses due to rapid advances in IoT technologies. To simplify network
infrastructure deployment and improve system O&M capabilities, IoT terminals
access networks in IP mode and IoT services are uniformly carried by campus
networks, which has become a trend of smart campus network construction.
As shown in Figure 2-68, in the Huawei iConnect terminal access control solution,
IoT terminals that comply with Huawei iConnect ecosystem standards access the
campus network through Wi-Fi, and the campus network provides IP transmission
services for these IoT terminals. To ensure secure campus network access, Huawei
iConnect terminals also need to be authenticated and authorized before accessing
the campus network. After the authentication and authorization are complete, the
IoT platform delivers thing model operation instructions to the IoT gateway via
the campus network. The gateway then orchestrates and delivers the instructions
to Huawei iConnect terminals through the campus network.
Figure 2-68 Huawei iConnect terminals accessing the campus network

2.2.7.7.3 Control Policy Design
Related Products
Table 2-34 lists the related products involved in the Huawei iConnect terminal
access control solution in the current version of the CloudCampus Solution.
Table 2-34 Products involved in the Huawei iConnect terminal access control
solution
IoT Terminal Authentica PKI IoT Platform
tion Server Serv
er
● Building direct digital Huawei Serve HUAWEI CLOUD ROMA The

controller (DDC) that iMaster r HUAWEI CLOUD WeLink client
meets Huawei's NCE- provi can be installed on mobile
iConnect ecosystem Campus ded phones and PCs to report IoT
standards by terminal information to the
● IoT terminals that Jilin ROMA platform.
support only MAC Unive
address rsity
authentication and Infor
802.1X authentication mati
on
● IoT terminals that Tech
support only Wi-Fi nolog
access ies
Co.,
Ltd.
Network Access Control Design for Huawei iConnect Terminals

In campus building control scenarios, design the solution based on the following
roadmap if you want to display Huawei iConnect terminal information on iMaster
NCE-Campus and perform network access control based on terminal information:
1. Determine the phase when Huawei iConnect terminals access the campus
network
You need to determine the phase when a Huawei iConnect terminal accesses
the campus network, which can be the building system commissioning phase
or the phase when IoT terminals attempt to access the campus network.
Table 2-35 describes the two phases.

Table 2-35 Different phases when Huawei iConnect terminals access the
campus network
Phase Introduction iMaster iConnect Service Pol

NCE- SSID SSID icy
Campu Authenti Authent Co
s cation ication ntr
Involve Mode Mode ol
d or Inv
Not olv
ed
or
No
t
Buildin The building system is Not No Not No

g deployed earlier than the involved authentic involved t
system campus network. ation inv
commi Therefore, a temporary olv
ssionin local area network (LAN) ed
g is required to support the
phase local commissioning of
the building system.
Phase After the entire campus Involved MAC 802.1X Inv

when network is deployed, the address authenti olv
IoT temporary LAN authentic cation ed
termin configurations that took ation/
als effect in the building 802.1X
attemp system commissioning authentic
t to phase will be replaced by ation
access planned network
the configurations. Huawei
campu iConnect terminals need
s to be re-authenticated
networ and re-authorized to
k access the campus
network in this phase.
2. Perform access control design for Huawei iConnect terminals in the

building system commissioning phase.
In this phase, the building automation system is commissioned only on the
temporary LAN, which does not have high security requirements. Therefore,
you can configure "no authentication" for the iConnect SSID. In this way, after
an IoT terminal accesses the iConnect SSID:
– The WAC can identify whether the terminal is a Huawei iConnect
terminal based on the electronic identity information carried in wireless
protocol packets. If the WAC receives such a packet, the terminal is
identified as a Huawei iConnect terminal and is successfully
authenticated.
– If not, the terminal is identified as a non-Huawei iConnect terminal and
cannot access the network.

3. Select a desired approval mode for Huawei iConnect terminals to access

the campus network.
– Access without approval: Use the WeLink app to scan the QR code on a
Huawei iConnect terminal and enter the MAC address of the Huawei
iConnect terminal on the ROMA platform. The ROMA platform then
synchronizes other information about the terminal to iMaster NCE-
Campus. After the Huawei iConnect terminal accesses the iConnect SSID,
802.1X authentication is triggered by wireless protocol packets carrying
electronic identity information sent by the terminal. Because other
information about the terminal has been synchronized to iMaster NCE-
Campus, the terminal is authenticated successfully.
– Access after the administrator's approval: On the ROMA platform or
iMaster NCE-Campus, the administrator can approve whether a Huawei
iConnect terminal can access the campus network. The terminal
information will be automatically added to the list of terminals to be
approved during MAC address authentication when the terminal accesses
the iConnect SSID for the first time. After approved, the terminal accesses
the iConnect SSID again and triggers MAC address re-authentication.
Table 2-36 compares the two approval modes.
Table 2-36 Comparison between the two approval modes

Appro Method of iConnect SSID Service SSID
val Recording Huawei Authentication Authentication
Mode iConnect Terminal Mode Mode
Information on
the ROMA
Platform
Acces Scanning the QR 802.1X 802.1X

s code of a Huawei authentication authentication
witho iConnect terminal (using EAP-PEAP- (using EAP-TLS)
ut using the WeLink MSCHAPv2)
appro app
val
Acces Using a MAC MAC address 802.1X

s after address whitelist authentication authentication
the (using EAP-TLS)
admin
istrato
r's
appro
val
4. Select a scheme for Huawei iConnect terminals that attempt to access

the campus network to automatically apply for digital certificates.
To ensure the security of IoT terminals and prevent forgery, digital certificates
issued by enterprises need to be installed on terminals. When terminals access
the network, 802.1X authentication is performed to ensure that the terminals
are valid. However, it is cumbersome and time-consuming to install digital
certificates on numerous IoT terminals. Huawei iConnect terminals can

automatically apply for and load digital certificates. Table 2-37 describes the
schemes for Huawei iConnect terminals to automatically apply for digital
certificates in different scenarios.
Table 2-37 Schemes for Huawei iConnect terminals to automatically apply for
digital certificates in different scenarios
Terminal IP Address Method for a Terminal Remarks

Type to Obtain the
Certificate Application
URL
Dynamic IP address The URL is carried in None

(DHCP) sub-option 5 of DHCP
Option 43 configured
on the DHCP server.
Static IP address The URL is obtained by When a terminal

using the authorization accesses the gateway,
redirection ACL for the the terminal is
first access redirected to the URL
for applying for a
certificate on iMaster
NCE-Campus.
5. Perform policy control solution design for Huawei iConnect terminals

that attempt to access the campus network.
After a Huawei iConnect terminal applies for a digital certificate through the
iConnect SSID, the terminal can access the service SSID for 802.1X
authentication. The service authorization policy design for Huawei iConnect
terminals is the same as the management and control policy design in
terminal identification.
Currently, no Huawei iConnect terminal type information is available on
iMaster NCE-Campus. You need to synchronize such information from the
ROMA platform to iMaster NCE-Campus or add the information on iMaster
NCE-Campus before configuring authorization policies based on terminal
types.
2.2.7.8 5G Terminal Access Control Design
2.2.7.8.1 5G Terminal Access to Campus Networks

5G networks featuring high-speed mobility and wide coverage can effectively
supplement campus networks in enterprise campus scenarios. To ensure 5G
terminals' (any devices with 5G modules) secure access to a campus network, the
authentication server of the campus network needs to perform second
authentication on 5G terminals. In addition, the authentication server works with
the multi-service control gateway (MSCG) of the campus network to perform
unified policy control on connected 5G terminals.
Figure 2-69 shows the access process of a 5G terminal to a campus network.

Figure 2-69 Access process of a 5G terminal to a campus network
1. The campus administrator purchases SIM cards and 5G IoT terminals, and
then manually imports information such as the international mobile
subscriber identity (IMSI) and international mobile equipment identity (IMEI)
of the terminals to iMaster NCE-Campus (functioning as the authentication
server), or synchronizes such information from the IoT platform deployed by
the enterprise to iMaster NCE-Campus.
2. 5G terminals equipped with SIM cards access the 5G core network after
successful 5G-AKA authentication, and then create PDU sessions.
3. The session management function (SMF) module on the 5G core network
triggers RADIUS PAP or CHAP authentication and terminal information such
as the IMSI and IMEI carried in RADIUS packets is reported to iMaster NCE-
Campus for authentication. The communication between the SMF and
iMaster NCE-Campus involves sensitive information. Therefore, data flows
between the SMF and iMaster NCE-Campus are transmitted through the
private line and are encrypted by IPsec tunnels.
4. After the authentication is successful on iMaster NCE-Campus, the 5G
terminal can access the enterprise's intranet resources through the 5G
network.
5. After the authentication is successful, iMaster NCE-Campus delivers the
security policy for 5G terminals to the MSCG.
NOTE
● Currently, only iMaster NCE-Campus can function as the authentication server to work
with the carrier's SMF to perform second authentication on 5G terminals and work with
the MSCG.
● 5G terminals in the current solution refer to IoT terminals only and cannot roam
between 5G base stations.
● In the current solution, 5G terminals cannot smoothly switch from a carrier network to
a campus Wi-Fi network.
2.2.7.8.2 MSCG Security Policy Association Design

After successfully authenticating a 5G terminal for the second time, iMaster NCE-
Campus works with the MSCG on the campus network to control the access
permission of the 5G terminal. It is recommended that the MSCG be deployed on
a core switch and then interconnect with iMaster NCE-Campus. The roadmap is as
follows:

1. iMaster NCE-Campus delivers security group policy configurations to the core

switch.
2. After a 5G terminal goes online, iMaster NCE-Campus synchronizes the
mapping between the terminal's IP address and security group to the core
switch through the IP-group entry subscription function. Then the core switch
enforces the security group policy.
2.2.8 Security Design
2.2.8.1 Egress Network Security Design

External network services provided by the intranet, such as the enterprise website
access service and email service, may have potential security risks, threatening the
security of the campus network. It is recommended that the following security
services be deployed on the egress firewall of the campus network to secure the
network perimeter:
1. Assign employees, servers, and the extranet to different security zones to
inspect and protect interzone traffic.
2. Enable the content security protection function based on types of network
services provided by enterprises. For example, enable antivirus and intrusion
prevention for all servers.
3. If employees need to access the Internet, enable functions such as URL
filtering and antivirus to defend against Internet threats and prevent
information leaks to ensure enterprise network security.
Deploying these security services depends on the design of two key functions of
the firewall: security zone and security policy. For more information, see 2.2.6
Egress Network Design.
2.2.8.2 Intranet Security Design

A typical large or midsize campus network uses a three-layer architecture,
consisting of the core layer, aggregation layer, and access layer. Simplified
networks may use a two-layer architecture, consisting of only the core layer and
access layer, which has no difference in network security design. The following
sections will provide guidance on the network security design.
2.2.8.2.1 Access Layer (Access Switch)

The access layer is the edge of a campus network, which provides diverse access
modes to PCs, network cameras, printers, IP phones, and wireless terminals. It is
the first tier of the campus network, and needs to meet access demands of
various terminals. The access layer also needs to protect the entire network
against access of unauthorized users and applications, so it must provide enough
security without compromising network availability. You are advised to enable the
following security functions on the access switch:
● Broadcast storm control
When a Layer 2 Ethernet interface on a device receives broadcast, unknown-
unicast, and multicast (BUM) packets, the device forwards these packets to
other Layer 2 Ethernet interfaces in the same VLAN if the outbound interfaces

cannot be determined based on the destination MAC addresses of these

packets. As a result, a broadcast storm may be generated, degrading
forwarding performance of the device. On downlink interfaces of the access
layer (access switch), configure suppression of BUM packets to effectively
reduce broadcast storms.
● DHCP snooping, with the uplink interfaces that directly or indirectly connect
the access switch to the DHCP server configured as trusted interfaces
DHCP snooping defends against bogus DHCP server attacks, DHCP server DoS
attacks, bogus DHCP packet attacks, and other DHCP attacks. DHCP snooping
allows administrators to configure trusted interfaces and untrusted interfaces,
so DHCP clients can obtain IP addresses from authorized DHCP servers. A
trusted interface forwards DHCP messages it receives whereas an untrusted
interface discards DHCP ACK messages and DHCP Offer messages received
from a DHCP server.
An interface directly or indirectly connected to the DHCP server trusted by the
administrator needs to be configured as the trusted interface, and other
interfaces are configured as untrusted interfaces. This ensures that DHCP
clients only obtain IP addresses from authorized DHCP servers and prevents
bogus DHCP servers from assigning IP addresses to DHCP clients.
● IP source guard and dynamic ARP inspection (DAI)
Unauthorized users often send bogus packets with the source IP address and
MAC address of authorized users to access or attack the network. Then
authorized users cannot access stable and secure networks. To address this
problem, you can configure IP source guard. IP source guard prevents
unauthorized hosts from using IP addresses of authorized hosts or specified IP
addresses to access or attack the network.
You can configure DAI to defend against Man in The Middle (MITM) attacks,
preventing theft of authorized user information. When a device receives an
ARP packet, it matches the source IP address, source MAC address, VLAN ID,
and interface number of the ARP packet against binding entries. If a match is
found, the device considers the ARP packet valid and allows it to pass
through. Otherwise, the device discards the packet.
● Port isolation
You are advised to configure port isolation on the interfaces connecting the
access switch to terminals. This configuration secures user communication
and prevents invalid broadcast packets from affecting user services.
Note: If the connection type "terminal" is selected for a port during access
management configuration for the fabric, the port isolation function is
automatically configured on the port.
2.2.8.2.2 Access Layer (WLAN Access)

On a WLAN, service data is transmitted through radio signals. Such open channels
are vulnerable to service data eavesdropping and tampering during transmission,
such as rogue STAs, spoofing APs, and denial of service (DoS) attacks of malicious
terminals. As shown in Figure 2-70, WLAN security design covers the following
aspects:
● Air interface security: Identifies and defends against attacks such as rogue
APs, rogue STAs, unauthorized ad-hoc networks, and DoS attacks.

● STA access security: Ensures the validity and security of STAs' access to the
WLAN.
● Service security: Protects service data of authorized users from being
intercepted by unauthorized users during transmission.
Figure 2-70 WLAN security diagram
Air Interface Security Design

● To prevent intrusion of unauthorized devices or interference devices, enable
the Wireless Intrusion Detection System (WIDS) and Wireless Intrusion
Prevention System (WIPS) functions of the WLAN to detect and contain rogue
devices.
● Enable the WLAN spectrum analysis function to identify interference sources
on the network, locate them, and eliminate interference on the network.
The spectrum analysis architecture is composed of the spectrum sampling
engine, spectrum analyzer, and interference visualization module. The
function of each component is as follows:
– Spectrum sampling engine: Collects spectrum information on the WLAN
and forwards the information to the spectrum analyzer.
– Spectrum analyzer: Analyzes spectrum data, identifies interference
resource types, and sends the report on interference devices to the
interference visualization module.
– Interference visualization module: Displays interference resource
information in graphs, including real-time spectrum graphs.

Figure 2-71 Spectrum analysis system
● To prevent unauthorized attacks, you are advised to enable the illegal attack
detection function in public areas and student dormitories with high security
requirements to detect flood, weak-vector, and spoofing attacks,
automatically add attackers to the dynamic blacklist, and alert the
administrator through alarms.
STA Access Security Design

The STA access security solution is designed based on the combination of different
access authentication modes in NAC and WLAN security policies, and needs to
ensure both security and convenience. For example, in scenarios where users do
not need to communicate, it is recommended that user isolation be configured.
For details about the planning and design of STA access security, see "WLAN
Admission Design" in 2.2.5 WLAN Design.
Service Security Design

The wired network between APs and WACs also faces common security threats,
for example, interception, tampering, and spoofing, on IP networks. To improve
data transmission security, the CAPWAP tunnel between the WAC and AP supports
DTLS encryption, including:
● DTLS encryption for management packets in the CAPWAP tunnel
● DTLS encryption for service data packets in the CAPWAP tunnel
● Sensitive information encryption: When sensitive information is transmitted
between an AP and a WAC, the information can be encrypted to ensure
security. Sensitive information includes the FTP user name, FTP password, AP
login user name, AP login password, and service configuration key. The
sensitive information encryption function can also be configured to protect
data transmitted between WACs.
● Integrity check: When CAPWAP packets are transmitted between an AP and a
WAC, these packets may be forged, tampered with, or used by attackers to
construct malformed packets to launch attacks. Integrity check can protect
CAPWAP packets between the AP and WAC.
If the AP and WAC are both located on the internal network, this security
function does not need to be enabled. It is recommended that this function be
enabled when the AP is connected to the WAC across the Internet or the
WACs are located across the Internet.
2.2.8.2.3 Aggregation Layer

For the network security design at the aggregation layer, refer to 2.2.8.2.1 Access
Layer (Access Switch) if terminals are connected to the aggregation switch, and

refer to 2.2.8.2.4 Core Layer if the aggregation switch functions as the user
gateway or authentication point.
2.2.8.2.4 Core Layer

Core switches are located at key positions of the network, and thus the security of
core switches is crucial. When the core switch functions as a centralized
authentication point, its CPU performance must be able to support protocol
packet processing when a large number of users access the network. When the
core switch functions as a user gateway, ARP security must be considered.
To protect the CPU and ensure that the CPU processes and responds to normal
services, the core switch provides local attack defense functions. In the event of an
attack, these functions ensure uninterrupted service transmission and minimize
the impact of the attack on network services.
Local attack defense functions include CPU attack defense, attack source tracing,
port attack defense, and user-level rate limiting. By default, the core switch is
enabled with these functions.
● CPU attack defense
CPU attack defense enables the device to rate limit the packets sent to the
CPU within a specified period of time, protecting the CPU and ensuring
normal service processing.
The key to CPU attack defense is the Control Plane Committed Access Rate
(CPCAR). CPCAR limits the rate of protocol packets sent to the control plane
to ensure security of the control plane.
● Attack source tracing
Attack source tracing defends against denial of service (DoS) attacks. The
device enabled with attack source tracing analyzes packets sent to the CPU,
collects statistics about the packets, and specifies a threshold for the packets.
Excess packets are considered to be attack packets. The device finds the
source user address or source interface of the attack by analyzing the attack
packets and generates logs or alarms. Accordingly, the network administrator
can take measures to defend against the attacks or configure the device to
discard packets from the attack source.
● Port attack defense
Port attack defense is an anti-DoS attack method. It defends against attacks
based on ports and prevents protocol packets on ports from occupying
bandwidth and causing other packets to be discarded.
By default, port attack defense is enabled on the device for common user
protocol packets, such as ARP, ICMP, DHCP, and IGMP packets. If a user attack
occurs, the device restricts the attack impact within the port, reducing the
impact on other ports.
● User-level rate limiting
User-level rate limiting identifies users based on MAC addresses, and rate-
limits specified protocol packets, such as ARP, ND, DHCP Request, DHCPv6
Request, IGMP, 802.1X, and HTTPS-SYN packets. If a user undergoes a DoS
attack, other users are not affected. The core of user-level rate limiting is host
CAR. By default, user-level rate limiting is enabled.
When a switch functions as an access gateway, it receives a large number of ARP
packets requesting the interface MAC address of the switch. If all these ARP

Request packets are sent to the main control board for processing, the CPU usage
of the main control board will increase and other services cannot be processed
promptly.
The optimized ARP reply function addresses this issue. After this function is
enabled, the interface card directly responds to ARP requests if the ARP Request
packets are destined for the local interface of the switch, helping defend against
ARP flood attacks. This function is applicable to the scenario where a modular
switch is configured with multiple interface cards or fixed switches are stacked.
By default, the optimized ARP reply function is enabled on a switch. Do not

disable the function.
2.2.8.3 NE Security Design

Network devices are the foundation of a campus network, and thus their security
is critical and also requires particular attention. So far, many countries and
organizations have posed specific requirements to NE security. For example,
government laws and regulations, such as the UK's Telecoms Security
Requirements (TSR), German Telecommunications Act, and China's Classified
Protection 2.0 (level 3 and above), have set the hardware root of trust (RoT),
measured boot, and remote attestation as mandatory trusted computing
requirements. In addition, Vodafone, Orange, Telefonica, Germany BSI's CC
certification, and UK CSEC have all raised requirements on secure boot and remote
attestation.
Currently, the CloudCampus solution provides the following NE security

capabilities:
● Remote attestation
Remote attestation for NE software package integrity is provided to ensure
secure NE running.
● NE situational awareness
Based on AI algorithms, the NE log analysis helps determine the overall NE
security situation and predict the future trend, enabling security O&M
personnel to quickly obtain and understand a large amount of network
security data and locate threat sources in a timely manner. Security O&M
personnel can thereby quickly respond to various attacks, threats, and
exceptions on network devices, ensuring service continuity.
The NE situational awareness function can detect the following exceptions:
Brute force cracking, login using a blacklisted IP address, an unusual IP
address, an unauthorized account, a compromised account, or a zombie
account; login through an uncommon path or at unusual time, abnormal
number of login accounts, abnormal login frequency, unauthorized account
creation, unauthorized password change, unauthorized account activation
(detected when the product has activation logs), password change violation,
unauthorized account deletion, unauthorized user permission change,
unauthorized operation attempt, file permission escalation, key file
tampering, Rootkit attack, unauthorized superuser, and shell file tampering.
● Security configuration check
The security configuration check function provides visualized NE security
management capabilities. The function supports the checking of device

configuration security status (mainly checking insecure algorithms and

protocols) and provides risk warnings and security hardening guidance to
ensure that secure algorithms and protocols are used in NE configurations
and protect NEs against network attacks.
NOTE
● Remote attestation, security configuration check, and NE situational awareness are

supported only by devices running V600R021C10 and later versions.
● A physical server or three VMs (3 x 64 GB) need to be added to deploy the remote
attestation, security configuration check, and NE situational awareness functions.
● Only HTM devices support remote attestation. (If HTM is included in the component
description of a device or card, the component supports HTM. Otherwise, the
component does not support HTM.)
● iMaster NCE-Campus does not support domain-based configuration for remote
attestation, security configuration check, or NE situational awareness.
● The NE situational awareness function supports only a single tenant.
2.2.9 QoS Design
2.2.9.1 QoS Requirement Survey

Before deploying QoS, you must be familiar with various services as well as the
traffic model and QoS requirements of each service. In this way, QoS policies can
be correctly designed and QoS guarantee can be provided for each service. Table
2-38 describes the key points of QoS requirement survey.
Table 2-38 QoS requirement survey

Requ Key Point of Requirement Survey Survey Purpose
irem
ent
Type
Netw Traffic models of various services and E2E Determine the network
ork forwarding paths of each service, including location where a QoS
statu forwarding paths in normal and abnormal policy is to be deployed.
s conditions
Bandwidth bottleneck points on the network Determine whether to

and interface bandwidth of each bandwidth adopt the QoS policy or
bottleneck point expand the network
capacity.
QoS Control services, multimedia services, and Understand traffic types

requi other important services that need to be and QoS requirements of
reme focused on each traffic type.
nts


irem
ent
Type
Characteristics of various types of traffic that

can be identified by network devices. For
example, check whether voice traffic uses a
proprietary protocol such as the Session
Initiation Protocol (SIP) or H.323, whether
traffic is destined for or from a specific
interface of a specific server, and whether
traffic is from or destined for a specific host
network segment.
Bandwidth requirements of important

services. For example, multimedia services
from different vendors at different bit rates
require different bandwidths so that the
audio or video services can be smoothly
transmitted.
Processing policies for different multimedia

applications. For example, for online videos,
some enterprises consider that online videos
on intranets need to be guaranteed and
work-irrelevant online videos on the Internet
do not need to be guaranteed.
2.2.9.2 Application Analysis Design
2.2.9.2.1 Application Identification and Experience Analysis

With the increasingly wide use of broadband networks, broadband data services
are developing rapidly. On the one hand, administrators need to learn about the
traffic usage of various applications on the network. On the other hand, certain
network control measures are needed, for example, ensuring that service flows of
mission-critical applications are processed preferentially and preventing resource
abuse. Therefore, the network needs to be able to support intelligent application
identification and allow for network policy control based on application
identification results.
Application Identification Technology

Smart Application Control (SAC) is an intelligent application identification and
classification engine. It detects and identifies Layer 4 to Layer 7 information in
packets as well as some protocols such as HTTP, FTP, and RTP. SAC is a basic
technology of service awareness (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. Signature identification
determines an application by detecting signatures in data packets. Signatures of
some protocols are contained in multiple packets, and therefore a device must

collect and analyze multiple packets to identify the protocol type. The system
analyzes traffic flowing through the device, and compares the analysis result with
the signature database file loaded on the device. It identifies an application by
detecting signatures in data packets, and performs further application quality
analysis and QoS policies based on the identification result.
Figure 2-72 shows the deployment position of the SAC function on a large or
midsize campus network. Application traffic of wired users is identified by access
switches, and that of wireless users is identified by APs.
Figure 2-72 Deployment positions of SAC on a large or midsize campus network
The applications that can be identified by the SAC function depend on the
signature database supported by a device. The device can accurately identify some
mainstream applications that are covered by its signature database.
However, private applications of enterprises are used in actual scenarios. If these
private applications are not covered by the signature database supported by the
device, the device cannot effectively identify these applications. In this case, you
can define application identification rules to identify private applications based on
key 5-tuple or URL information. The following figure is an example of customizing
an application identification rule.

NOTE
● If user-defined rules conflict with the rules in the signature database, the device uses
the user-defined rules for application identification.
Application Experience Analysis

Network services are provided for applications. You can better optimize the
network only by learning about the experience of applications. Application
experience analysis uses eMDI technology to collect statistics on KPIs (packet loss,
delay, and jitter) of 5-tuple flows of applications and calculate the MOS based on
the KPIs. Currently, only UDP or RTP applications (packet loss and jitter can be
calculated, but delay cannot be calculated) and TCP applications (packet loss and
delay can be calculated, but jitter cannot be calculated) are supported. According
to RFC 4594, the requirements on packet loss, delay, and jitter vary with different
application types. Therefore, different MOS values are calculated.
● Application experience analysis based on application identification
You can enable application experience analysis for a specified application based on
the SAC signature database or user-defined rules. As shown in Figure 2-73,
application experience analysis can be deployed only on edge interfaces of access
switches and on APs. If APs are connected to access switches, application
experience analysis must be deployed on APs.

Figure 2-73 Deployment of application experience analysis on a large or midsize

campus network
● Application experience analysis based on security groups and applications

The customer wants to preferentially guarantee experience of key applications
(such as video conferencing and email) for VIP users (such as executives and
student union members) in key places (such as conference rooms, exam rooms
and surrounding places) at key moments (such as exams). In this case, experience
analysis based on application identification mentioned above cannot meet the
requirements, because the specifications may be insufficient to support experience
analysis for all key applications. To this end, experience analysis based on security
groups or both security groups and applications is provided. Security groups are
used to authorize authenticated users based on 5W1H, so that information
including user identities, access locations (switches the users connect to), and
access time can be identified.
NOTE
Security groups are supported for wireless users only in native WAC scenarios.
Application Fault Demarcation

● Hop-by-hop fault demarcation based on 5-tuple information
If experience exceptions are detected on applications with fixed IP addresses (for
example, locally deployed applications), iPCA 2.0 can help perform end-to-end in-
band flow measurement for fault demarcation. In traditional iPCA, to perform

measurement for all flows sent to a server on a per-flow basis, you need to
configure the 5-tuple information of each flow separately. By contrast, iPCA 2.0
requires only two configurations: one any-to-server DIP rule configured for
upstream flows, and the other server SIP-to-any rule for downstream flows. Then,
a 5-tuple flow table is automatically generated for each flow that matches either
of the two rules for further iPCA 2.0 measurement.
iPCA 2.0 uses the color bit (bit 0 in the IP Flags field is recommended) to measure
packet loss and delay.
As shown in Figure 2-74, iPCA 2.0 defines three types of measurement points: in-
point, out-point, and mid-point. The in-point is used for coloring and
measurement, the out-point for decoloring and measurement, and the mid-point
for measurement. For a bidirectional flow, the upstream (terminal-to-server) and
downstream (server-to-terminal) traffic on the same interface of a device passes
through the in-point and out-point, respectively. iPCA 2.0 needs to be configured
on the interfaces through which all flows may pass.
Figure 2-74 Deployment of fault demarcation based on 5-tuple information on a

large or midsize campus network

NOTE
The preceding figure shows only the monitoring of traffic in one direction. The monitoring
of traffic in the other direction needs to be configured in the reverse direction using the
same logic.
iPCA 2.0 depends on time synchronization of NTP and supports only two-way delay
measurement, which requires that the upstream and downstream flows be transmitted
along the same path.
iPCA 2.0-based delay measurement is inaccurate in the presence of out-of-order packets.
Only the S5731-H, S5731-H-K, S5731-S, S5731S-S, S5731S-H, S5732-H, S5732-H-K, S6730-
H, S6730-H-K, S6730S-H, S6730-S, S6730S-S, and modular switches installed with X series
cards support delay measurement.
iPCA 2.0 is not applicable to multicast scenarios.
● Fault demarcation based on application identification

Regarding applications without fixed IP addresses, for example, SaaS applications
like Tencent Meeting and DingTalk, 5-tuple information cannot be configured for
iPCA 2.0 fault demarcation. In this case, the iPCA 2.0 function based on application
identification is required.
Figure 2-75 Deployment of fault demarcation based on application identification

on a large or midsize campus network
As illustrated in the preceding figure, when deploying iPCA 2.0, you are advised to
specify mid-points and out-points in advance and enable AutoDetect on them. In
this way, when adding an application flow measurement task, you only need to
specify the application name on in-points, but not on mid-points or out-points.

Application identification must be deployed on the node where the in-point for
flow measurement resides. In this manner, application identification data can be
used to associate an application name with 5-tuple information, which is then
used for traffic matching.
Without application identification data, the nodes where the mid-point and out-
point reside need to automatically identify the packets to be measured and trigger
flow creation and measurement based on the packets colored by the node where
the in-point resides.
If two-way measurement is performed on the node where the out-point resides,
the received reverse flow is not colored because no application identification data
is available. The 5-tuple information in the reverse flow can be obtained only
based on the forward flow. After such information is obtained, the ACL is
automatically delivered for a 5-tuple match and trigger flow coloring, creation,
and measurement.
The colored reverse flow is processed in the same way as the forward flow.
Subsequent nodes identify the color bit in the flow to trigger flow creation and
measurement.
Nodes enabled with AutoDetect can provide sufficient entry resources to
implement automatic in-band flow measurement only after the resource mode of
the nodes is switched to iPCA. In this mode, the number of IPv4/IPv6 dual-stack
STAs on a fabric cannot exceed 30,000.
NOTE
The fault demarcation capability based on application identification can be used only for
long flows. The duration of a long flow must be longer than two iPCA 2.0 reporting periods.
As the minimum reporting period can be set to 10 seconds, only flows with longer than 20-
second duration can be displayed on the analyzer.
cards support fault demarcation based on application identification.
The application identification and traffic statistics collection functions cannot be configured
on a switch interface where iPCA 2.0 is configured. Therefore, the in-point can be
configured only on the uplink interface. As a result, packet loss on access switches cannot
be detected.
Other constraints are the same as those for 5-tuple-based fault demarcation.
● Hop-by-hop fault demarcation based on security groups and applications
and surrounding places) at key moments (such as exams). In this case, fault
demarcation based on application identification mentioned above cannot meet
the requirements, because the specifications may be insufficient to support fault
demarcation for all key applications. To this end, fault demarcation based on
security groups or both security groups and applications is provided. Security
groups are used to authorize authenticated users based on 5W1H, so that
information including user identities, access locations (switches the users connect
to), and access time can be identified.
NOTE

2.2.9.2.2 Precautions for Co-deployment of Application Experience Analysis and

If the application fault demarcation function needs to be deployed together with
the application experience analysis function on a switch, the application fault
demarcation function can be deployed only on the uplink ports of the switch
because the two functions are mutually exclusive on the switch port. In addition,
tunnel packets can only be measured based on inner 5-tuples and cannot be
colored or decolored. Therefore, the VXLAN tunnel-side interface cannot be
configured as an iPCA 2.0 in-point. Also, in the scenario where VXLAN is deployed
across core and access layers, wired user traffic does not support co-deployment
of application experience analysis and application fault demarcation. Figure 2-76
shows the deployment positions of application experience analysis and application
fault demarcation in the scenario where VXLAN is deployed across core and
aggregation layers.
Figure 2-76 Co-deployment positions of application experience analysis and

application fault demarcation on a large or midsize campus network
2.2.9.3 Traffic Classification Design

Services carried on a large or midsize campus network include voice, video, and
data services and network protocol control signaling required for transmitting
service data. QoS indicators of various services include the bandwidth, packet loss
rate, latency, and jitter. Bandwidth can be controlled by configuring parameters,

but packet loss rate, latency, and jitter cannot. In practice, QoS is deployed based
on engineering experience, as shown in Table 2-39.
Table 2-39 Features and QoS requirements of common services

Servic Typical Application or Protocol Pac Lat Jitt
e ket enc er
Categ Los y Tol
ory s Tol era
Tol era nce
era nce
nce
Netwo Link-layer loop prevention protocols for network Low Lo Per

rk interconnection and interoperability, routing w mit
protoc protocols, and multicast group management
ol protocols, such as STP, OSPF, and IGMP.
Manag Protocols used by network administrators for Low Lo Per

ement monitoring network devices, delivering w mit
protoc configurations, and diagnosing faults, for example,
ol ICMP, SNMP, Telnet, and XMPP.
VoIP Real-time voice calls over IP networks. The network Ver Ver Ver
data must provide low latency and low jitter to ensure y y y
flow service quality. low low low
Voice Signaling protocols for controlling VoIP calls and Low Lo Per
signali establishing communication channels, for example, w mit
ng SIP, H.323, H.248, and Media Gateway Control
Protocol (MGCP).
Signaling protocols have a lower priority than VoIP
data flows because call failure is often considered
worse than intermittent voices.
Multi Multiple parties can share camera feeds and screens Low Ver Lo
media over IP networks. Protocols or applications can or y w
confer adapt to different network quality levels by me low
encing adjusting the bitrate (image definition) to ensure diu
the smoothness. m
Gamin The network is required to provide online interactive Low Ver Lo

g applications with low packet loss rate, latency, and y w
jitter to ensure fast and accurate response during low
gaming. For example, online games that transmit
operation instructions through RTP or UDP pose
higher requirements on the network.
Strea Online audio and video streaming. Audio and video Low Me Per
ming programs are made in advance and then cached on or diu mit
media local terminals before being played. Therefore, the me m
requirements on the network latency, packet loss, diu
and jitter are reduced. m


e ket enc er
Categ Los y Tol
ory s Tol era
Tol era nce
era nce
nce
Online Unlike streaming media, data of online live Ver Me Lo

live broadcast is sent and received in real time. Though y diu w
broadc terminals provide the cache mechanism, the low m
ast network is required to provide the low packet loss
rate and jitter to meet real-time requirements and
ensure good experience.
Delay- Data services that are sensitive to delay. For Low Lo Per
sensiti example, long delay on an online ordering system w mit
ve may reduce the revenue and efficiency of or
data enterprises. me
service diu
s m
Bandw Network services that involve the transmission of a Low Me Per

idth- large amount of data for a long period of time, such diu mit
intensi as File Transfer Protocol (FTP), database backup, m
ve and file dump. or
service hig
s h
Comm Basic services that have no special requirements on No No No

on enterprise networks, such as email and web req req req
service browsing. uire uire uire
s me me me
nt nt nt
Low- Services that are not important to enterprises, such Hig Hig Per
priorit as social network and entertainment applications. h h mit
y
service
s
2.2.9.4 QoS Scheduling Policy Design

You are advised to design traditional QoS scheduling policies respectively for wired
networks and WLANs. The design for WLANs focuses on policies related to STA
services.
For details about user- and application-based scenario-specific QoS scheduling
policy design, see section "Intelligent HQoS Design."
2.2.9.4.1 QoS Scheduling Policy Design for Wired Networks

The basic principle of traditional QoS design for wired networks is to mark or re-
mark packets at boundaries of different DiffServ domains and perform bandwidth

control. Devices in the same DiffServ domain only need to schedule packets in
queues based on the priorities marked on boundary nodes. Typically, service
deployment involves traffic identification at the access layer, DiffServ model
deployment at the aggregation or core layer, and bandwidth control on egress
firewalls.
● Traffic identification at the access layer

Access switches function as boundary switches. The switches identify, classify,
and mark data flows at the user side. In actual deployments, different
interfaces on access switches are connected to different terminals. Different
priorities can be allocated to different services on access switches. Then traffic
of the services can be scheduled based on the priorities.
● DiffServ model deployment at the aggregation or core layer
Interfaces on aggregation and core switches are configured to trust DSCP or
802.1p priorities and enforce QoS policies based on priorities marked at the
access layer, to ensure that high-priority services are scheduled first. A switch
interface trusts 802.1p priorities by default.
● Bandwidth control on egress devices
Egress devices are also located in the DiffServ domain and are configured to
trust DSCP or 802.1p priorities of packets and implement QoS policies. Due to
egress bandwidth limits, you need to consider differences when setting
bandwidth parameters for WAN interfaces of egress devices. Additionally, QoS
policies of egress devices vary according to the enterprise WAN construction
mode.
– WAN QoS policies can be managed by an enterprise itself in the
following scenarios: enterprise-built WAN, private line construction using
leased fibers, and customized enterprise QoS policies applied to the
carrier WAN. In this case, egress or PE devices on the campus network do
not need to re-mark traffic.
– The WAN QoS policies are not controlled by an enterprise itself. The
enterprise leases the private line network of a carrier, and the carrier
does not trust the packet marking on the enterprise network or the two
parties have different definitions of the same packet marking. Thus,
egress devices on the campus network need to re-mark traffic.
2.2.9.4.2 QoS Scheduling Policy Design for WLANs

The network efficiency of WLANs is lower than that of wired networks, and STAs
are more sensitive to user experience. Therefore, you are advised to consider the
following aspects when designing the QoS policies for STAs:
● The maximum bandwidth of a single user can be limited based on service

requirements. If multiple SSIDs are planned, the total bandwidth of non-
critical SSIDs can be limited.
● In high-density scenarios, many users preempt channel resources. As a result,
the Internet access quality of each user deteriorates. You are advised to
enable the following functions:
– The call admission control (CAC) function is used to control STA access
based on the radio channel utilization and number or signal-to-noise
ratio (SNR) of online STAs to ensure the Internet access quality of online
STAs.

– The dynamic enhanced distributed channel access (EDCA) parameter

adjustment function allows APs to adjust EDCA parameters flexibly by
detecting the number of STAs to reduce the possibility of collisions,
improve the throughput, and enhance user experience.
● To enable STAs (especially sticky STAs) to re-associate or roam to APs with
better signals, enable the function of quickly disconnecting STAs to force low-
SNR or low-rate STAs to go offline.
● In scenarios requiring high multicast service experience, you are advised to
enable the multicast-to-unicast conversion function to improve multicast
service experience (for example, HD video on demand) to prevent the impact
of low-rate STAs on multicast services.
● In scenarios where VIP user experience needs to be guaranteed, you are
advised to enable preferential access of VIP users to ensure preferential
access, scheduling, and bandwidth guarantee for VIP users.
In WLAN QoS design, you need to consider priority mapping between wired and
wireless network packets. For example, 802.11 packets sent by WLAN clients carry
user priorities or DSCP priorities, VLAN packets on wired networks carry 802.1p
priorities, and IP packets carry DSCP priorities. To ensure consistent QoS
scheduling of packets on wired and wireless networks, you need to configure
priority mapping on network devices.
NOTE
Only 802.11ax (Wi-Fi 6) APs support bandwidth guarantee.
2.2.9.4.3 Recommended Scheduling Policy Suggestions

The definition of important data services varies with enterprises. For a portal
website, Internet access and gaming traffic is important; for the financial services
industry, real-time transaction is more important than voice services and Internet
access and gaming traffic is unwanted. Therefore, the QoS policy solution must be
designed and deployed based on actual service types and QoS requirements of
each enterprise. Table 2-40 lists the typical QoS policy solutions formulated based
on engineers' experiences, which provide references for design personnel.
Table 2-40 Scheduling model design suggestions
Applicatio Typical Application or CoS Queue Sched Maximu

n Type Protocol (Priorit uling m
y) Algorit Bandwid
hm th
Signaling ● Routing protocol CS6 6 PQ Unlimite

and control ● NMS, multimedia, and d
signaling protocols
Real-time ● VoIP EF 5 PQ Available

interactive ● Multimedia interface
multimedia conferencing bandwidt
h x 30%
● Online gaming
● Desktop cloud


y) Algorit Bandwid
hm th
On- ● Online video EF 4 DRR Unlimite

demand ● Video live broadcast or weight: d
subscriptio multicast 20
n of
multimedia ● Delay-sensitive and
or key mission-critical
services enterprise services, such
as ERP and online
ordering systems
Other ● Common Internet BE 0 DRR Unlimite

services access services such as weight: d
email and web 20
browsing
2.2.9.5 Intelligent HQoS Design
2.2.9.5.1 HQoS Solution Overview

The growing popularity of wireless terminals makes wireless access anytime and
anywhere a basic requirement for large- and medium-sized campus networks.
However, as the number of wireless users rapidly increases and wireless terminals
are getting more sensitive to the service quality, the existing QoS capability of
campus networks cannot ensure high-quality experience of wireless users. The
following are two urgent problems that need to be addressed immediately:
● The network administrator cannot provide differentiated services to
applications based on users. As a result, the traffic of common users preempts
the bandwidth of VIP users, so VIP users cannot be guaranteed with an
experience of absolute priority.
● The traditional QoS technology only supports the global application traffic
scheduling model. That is, only one type of QoS policy can be configured on
the entire network, and differentiated application scheduling policies cannot
be configured based on users or user types.
To address the preceding issues, Huawei launches the intelligent HQoS solution,
which is a scenario-specific QoS solution that supports multi-level scheduling and
application identification. With this solution, a network administrator can use the
following functions to perform QoS design and deployment for campus networks:
● Define VIP users through iMaster NCE-Campus.
● Define private applications of campus networks through iMaster NCE-
Campus.
● Define different application scheduling templates through iMaster NCE-
Campus.
● Authorize different application scheduling templates to users of different
categories through iMaster NCE-Campus.

To deploy the intelligent HQoS solution, a network administrator needs to

complete the planning of VIP users and applications, design of customized
applications, and design of application scheduling templates.
2.2.9.5.2 Planning of VIP Users and Applications

To implement application planning for VIP users, the network administrator needs
to complete the following tasks:
● Identify user terminals whose traffic needs to be preferentially guaranteed
and record VIP user information on iMaster NCE-Campus. The VIP attributes
of user terminals are automatically synchronized to network devices through
the authentication and authorization process.
● Analyze service traffic of VIP users, identify mission-critical and non-critical
services, and classify key service traffic based on indicators such as the packet
loss rate, latency, and jitter.
The following table describes an example plan for VIP users, providing a reference
for network administrators.
Table 2-41 Example plan for VIP users
VI Key Typical Packet Latenc Jitter Bandwidth

P Service Application Loss y Tolera (Mbit/s;
Us Category or Protocol Toleranc Tolera nce Burst or
er e nce Not)
VI VoIP Instant Very low Very Very 2; no burst

P1 messaging low low
applications
APP1 and
APP2
Internet_C Online video Low or Very Low 10; burst

onferencin conferencing medium low
g applications
APP3 and
APP4
VI Remote_D Remote Low or Very Low 20; burst

P2 esktop desktop medium low
application
APP5
Database Database Low Mediu Permit 1; no burst

applications m or
APP6 and high
APP7
This example defines two VIP users (VIP1 and VIP2) and analyzes indicators of
mission-critical applications of the VIP users, including the packet loss rate,
latency, jitter, and bandwidth requirements. For details about traffic classification,
see 2.2.9.3 Traffic Classification Design.

The VIP users and applications in the preceding table are for reference only, and
used to demonstrate the planning and design methods and logic. Therefore, the
indicator data cannot be recommended in actual deployments.
2.2.9.5.3 Design of Customized Applications

After planning for VIP users and analyzing service traffic, you need to design rules
for defining applications.
● The intelligent HQoS solution supports application customization by
specifying URLs or combinations of service IP addresses and ports. The
following table lists an example of designing customized applications.
Table 2-42 Example design of customized applications
Appli Description Type (URL/IP) Protocol Port

catio
n
APP1 Live 172.16.33.22 UDP 6666

streaming
APP2 Database https:// - -

access database.company.com
You are advised to customize applications using the preceding two methods. After
customizing applications on iMaster NCE-Campus as an administrator, you can
add the customized applications to an application scheduling template.
2.2.9.5.4 Design of Application Scheduling Templates

After completing the design of application identification for VIP users, you need to
design application scheduling templates. In the intelligent HQoS solution,
differentiated application scheduling templates are authorized to VIP users to
implement differentiated traffic scheduling policies. This ensures that key service
traffic of VIP users can be forwarded properly. After designing application
scheduling templates, you need to complete the following tasks:
● Define the priorities of key services based on the analysis results in 2.2.9.5.2
Planning of VIP Users and Applications. For typical scheduling policy
suggestions, see 2.2.9.4.3 Recommended Scheduling Policy Suggestions.
● It is recommended that a shaping bandwidth be configured for applications
that may have burst traffic. For example, if the average bandwidth of a video
application is less than 10 Mbit/s and the peak bandwidth is 100 Mbit/s, the
shaping bandwidth can be set to 10 Mbit/s.
● A maximum of 31 application scheduling templates can be defined through
iMaster NCE-Campus. The following table describes the configuration logic for
reference.
● Application scheduling templates cannot be defined for common users.
Application traffic of common users can only be scheduled based on the
default configuration of network devices, requiring no additional
configuration.

Table 2-43 Example design of an application scheduling template (for VIP users
VIP1, VIP3, and VIP5)
Application Priority (a Higher Shaping Bandwidth of Burst Traffic
Value Indicates a (Mbit/s)
Higher Priority)
Other applications 1 -
Non-critical 2 -
service application
APP6
Non-critical 3 -
service application
APP5
Customized 4 20
application APP4
Video 5 10
conferencing
application APP3
Customized 6 -
application APP2
Instant messaging 7 -
application APP1
Since the service traffic models of VIP users VIP1, VIP3, and VIP5 are similar, the
same application scheduling template is defined for the three VIP users. After the
application scheduling templates of all VIP users are designed, you can authorize
these templates to respective VIP users on the controller. Scheduling policies will
be automatically delivered to network devices.
2.2.9.5.5 Design Precautions

When deploying the intelligent HQoS solution, pay attention to the following
points:
● APs on a wireless network must be configured to work in tunnel forwarding
mode, and wireless traffic must be centrally forwarded by the WAC.
● The following table describes the recommended campus network
architectures.
Network User Gateway User WAC
Topology Authentication
Point
Independent WAC AirEngine 9700-M AirEngine 9700-M

wireless
network

Network User Gateway User WAC

Topology Authentication
Point
Wired and S12700E (core S12700E (core Native WAC

wireless switch) switch) (S12700E)
converged
network
● To support HQoS, the S12700E must be equipped with LST7Y40SX6H0-40-Port

25GE SFP28 interface cards. The number of VIP user terminals that can be
configured depends on the number of interface cards. Each interface card
supports a maximum of 16,000 VIP user terminals, including up to 12,000
wireless terminals.
● When the AirEngine 9700-M functions as a wireless user gateway, a
maximum of 1800 VIP user terminals can be configured.
● In the centralized gateway networking of the virtualization solution, the
S12700E functioning as a border node provides the native WAC function and
is used as the wired and wireless user gateway. In this scenario, HQoS is
supported only for wireless terminals, but not for wired terminals.
● When a core switch functions as the user gateway, the network administrator
needs to enable application identification and priority remarking on the
egress firewall and configure uplink ports of the core switch to trust DSCP
values.
● To avoid excessive resource competition among VIP users, it is recommended

that the proportion of VIP users be within 10% of the total number of users.
● The network administrator can configure a maximum of 31 application
scheduling templates on iMaster NCE-Campus.
● To configure application scheduling templates through the WAC, the network
administrator needs to switch to the WAC's web system from iMaster NCE-
Campus.
2.2.10 Reliability Design
2.2.10.1 Device Reliability
2.2.10.1.1 Switch Reliability Design

Two or more fixed switches can be virtualized into one logical switch using
stacking technology, whereas two modular switches can be virtualized into one
logical switch using clustering technology. When the master member switch in a
stack or Cluster Switch System (CSS) fails, the backup member switch takes over
all the services without interrupting services. On a large or midsize campus
network, deploying switches using the stacking or clustering technology is
recommended for higher reliability. The stacking or clustering technology has the
following advantages:
● Improving reliability

Member switches in a stack or CSS work in redundancy mode. In Figure 2-77,

two modular core switches Switch A and Switch B set up a CSS and back up
each other. In the event of a failure on Switch A, Switch B takes over services
from Switch A to ensure service continuity.
Figure 2-77 Improving reliability
● Increasing the number of ports

As demonstrated in Figure 2-78, if the port density of the original switch
cannot meet the access requirements of users, you can set up a stack by
attaching new switches to the original switch to increase the number of ports.
Figure 2-78 Increasing the number of ports
● Simplifying the network topology

In Figure 2-79, two switches at each network layer set up a stack or CSS,
which is similar to a single logical device. Eth-Trunks are used between stacks
and between a stack and a CSS. Such deployment approach increases link
bandwidth and reliability, and avoids using loop prevention protocols such as
MSTP. On a Layer 3 network, members in a stack or CSS share one routing
table. This shortens the route convergence time upon a network fault and
makes it easy to manage, maintain, and expand a network.

Figure 2-79 Simplifying the network topology
2.2.10.1.2 WAC Reliability Design

If switches with the native WAC function serve as WACs, the clustering or stacking
technology is used to ensure the WAC reliability. If standalone WACs are used, you
are advised to deploy them in HSB mode to improve the WAC reliability. In HSB
mode, there are two devices, one acting as the active and the other the standby.
The active device forwards services and the standby device monitors the
forwarding. In addition, the active device sends the standby device the status
information and information that needs to be backed up in real time. In the case
that the active device becomes faulty, the standby device takes over services. As
shown in Figure 2-80, two standalone WACs working in HSB mode are connected
to the core switches that set up a CSS in off-path mode. The Eth-Trunks between
the WACs and core switches work in active/standby mode. When the active WAC
fails, the standby WAC takes over services to forward WLAN packets.

Figure 2-80 Deploying WACs in HSB mode
2.2.10.1.3 Firewall Reliability Design

When firewalls function as egress devices, you are advised to deploy HSB to
improve firewall reliability. As illustrated in Figure 2-81, the firewalls act as egress
devices of the campus network and are directly connected to the stacked core
switch. The two firewalls are configured to work in HSB mode, and the member
links in their interconnected Eth-Trunk are in active/standby mode. When the
active firewall is faulty, the standby firewall takes over services and forwards
service packets.
2.2.10.2 Link Reliability

On a campus network, two uplinks are usually used to improve the reliability of
links between devices. In addition, for redundant links, Link Aggregation Control

Protocol (LACP) is commonly used to virtualize multiple physical links into a

logical Eth-Trunk. The interfaces on the Eth-Trunk are called Eth-Trunk interfaces.
As shown in Figure 2-82, link aggregation has the following advantages:
● Increasing bandwidth: The maximum bandwidth of a link aggregation group
(LAG) is the sum of bandwidth of the member interfaces in the LAG.
● Improving reliability: When an active link fails, the traffic carried over this
failed link is switched to another functional active link, improving LAG
reliability.
● Achieving load balancing: In a LAG, traffic is load balanced among all
functional active links.
Figure 2-82 Eth-Trunk networking
2.2.11 O&M Design
2.2.11.1 Basic Network O&M Design

In the virtualization solution for a large or midsize campus network, iMaster NCE-
Campus provides comprehensive basic network management, NE management,
service management, and system management functions for managed devices.
These functions include user, log, resource, topology, alarm, and performance
management. In addition, common protocols used in traditional network O&M
can be delivered to network devices through iMaster NCE-Campus or applied on
iMaster NCE-Campus, as shown in Table 2-44. iMaster NCE-Campus provides
comprehensive basic network management for managed devices to meet basic
customer network O&M requirements. Table 2-45 describes the major basic
network O&M functions supported by iMaster NCE-Campus.

Table 2-44 Common protocols used in traditional network O&M that can be
configured on iMaster NCE-Campus
Proto Configuration Supported by iMaster NCE-Campus
col
SNMP ● Configures interconnection between network devices and an SNMP

server.
● Manages traditional devices through SNMP. Traditional devices refer
to network devices that are not NETCONF capable.
NTP Configures interconnection between network devices and an NTP

server.
Syslog ● Configures interconnection between iMaster NCE-Campus and a

syslog server. After the configuration, iMaster NCE-Campus uploads
the logs obtained from network devices to the syslog server.
● Configures interconnection between network devices and a syslog
server.
SSH ● Configures local accounts for login over SSH on network devices.
● Logs in to the CLI of a network device from iMaster NCE-Campus
using SSH.
LLDP Enables LLDP on network devices. This function is enabled on iMaster

NCE-Campus by default. iMaster NCE-Campus can also learn the
network topology information through LLDP.
Table 2-45 Basic network O&M functions supported by iMaster NCE-Campus

Basic O&M Description
Function
Basic ● Monitors the basic status of sites, devices, and terminals, such
service as the online rate, CPU usage, and memory status of devices at
monitoring a site.
● Provides traffic statistics analysis and reports from multiple
dimensions (site, terminal, application, and SSID).
● Monitors user information, including the online status and
traffic statistics.
Log ● Allows administrators to configure log upload policies and the

manageme IP address of a third-party log server. The logs that can be
nt uploaded include operation, security, Portal user login and
logout, device login and logout, RADIUS user login and logout,
and HWTACACS logs.
● Allows administrators to query and view device login and
logout logs.


Function
Alarm ● Monitors network-wide alarms and events.

manageme ● Provides alarm management functions such as alarm severity
nt setting, alarm event acknowledgment and clearance, and
alarm rule customization.
Device ● Supports installation of system software packages and patches.

version
manageme
nt
Device ● Allows administrators to upload, download, and activate device

license license files.
manageme
nt
Device ● Supports the discovery and handling (verification and

configurati synchronization) of inconsistent configurations on the
on controller and devices. (This function is supported only by
consistency devices running V600R021C00 and later versions.)
manageme
nt
Device ● Allows administrators to back up, compare, and restore device

configurati configuration files.
on file
manageme
nt
Device ● Provides common network diagnosis tools, such as ping and

diagnosis trace.
● Obtains packet headers based on ports.
● Allows 5-tuple-based packet path tracing.
● Collects diagnosis and fault information.
2.2.11.2 Intelligent O&M Design

Huawei's intelligent O&M solution uses Telemetry technology to enable network
devices to send O&M data (such as device performance indicators and terminal
logs) to Huawei's intelligent network analysis platform iMaster NCE-
CampusInsight (CampusInsight for short). CampusInsight then utilizes big data,
artificial intelligence (AI) algorithms, and advanced analysis technologies to
digitize user experience on the network, helping detect network issues promptly
and improving user experience.
Table 2-46 lists the major O&M functions provided by CampusInsight.

Table 2-46 Main O&M functions provided by iMaster NCE-CampusInsight

Catego Functi Description
ry on
Networ Wireles Wireless client access experience: Analyze the access

k s success rate and time consumption fulfillment rate of
visibilit networ wireless clients from the association, authentication, and
y k DHCP phases to measure the access performance of the
health wireless network.
Wireless client roaming experience: Measure the roaming
quality of wireless clients based on the roaming success rate
and time consumption fulfillment rate, and identify wireless
roaming issues.
Wireless client throughput experience: Analyze the
coverage, capacity health, and fulfillment rate of
throughput to check whether the signal coverage meets
requirements, whether the wireless network is overloaded,
and whether the throughput decreases.
Wired The wired network health intuitively displays wired network

networ quality from four dimensions: device environment, device
k capacity, network status, and network performance.
health Wired device environment analysis: Monitor and analyze
device, card, fan, and power supply faults, and detect
whether the status of physical components is abnormal.
Wired device capacity analysis: Monitor and analyze the
capacity of ARP, MAC, FIB, ACL, and other entries, and
detect whether device resources are abnormal.
Wired network status analysis: Monitor and analyze issues
such as intermittent disconnection and optical module
exceptions, and detect whether interface links are abnormal.
Wired network performance analysis: Monitor and
analyze traffic statistics, and detect issues such as interface
congestion, queue congestion, error packets on interfaces,
and data transmission exceptions.
Wired network protocol analysis: Monitor and analyze
whether the STP, OSPF, and BGP protocol status is
abnormal.
Campu Issue iMaster NCE-CampusInsight analyzes, identifies, and collects

s analysi statistics on connection, air interface performance, roaming,
service s and device issues based on data such as performance
analysi indicators and logs, and displays information about affected
s APs and clients based on each issue indicator.


ry on
Access The Connectivity module evaluates the overall network

analysi connection quality from aspects such as the client access
s fault event trend.
Client access fault event statistics: includes the number of
association failures, number of authentication failures,
number of DHCP failures, and total number of access times.
Client access fault event trend: supports time range
selection, displays the distribution of devices and clients
that fail to be connected in the trend chart, and displays the
distribution of devices and clients with issues in an area
chart.
Perfor The performance experience module evaluates user

mance experience based on RSSI, negotiated rate, and packet loss
analysi rate, displays the number and trend of clients with good
s and poor experience at each time point within a period of
time, and analyzes the client distribution trend by single
indicator. Poor experience analysis based on APs and clients
helps administrators identify APs and clients with the
poorest experience.
User A client access information list can be displayed, and poor-

analysi QoE clients can be analyzed correlatively, including the
s overview, client latency trend, client issue analysis, poor-QoE
duration distribution, and related metrics. In addition, the
client journey information can be viewed, including the
client information, metric overview, access trend statistics,
DNS interaction statistics, audio and video application
statistics, experience metric trend, journey summary, and
access history.
Protoco Client access phases including association, authentication,

l trace and DHCP are displayed in terms of different protocols.
Refined analysis for individual faults that occur during client
access is provided based on the protocol interaction result
and duration at each phase. The analysis includes the most
possible root causes and rectification suggestions for client
access failures.
Currently, protocol trace supports the following user
authentication methods: 802.1X, Portal (Portal 2.0/HTTPS),
HACA, and MAC address authentication.


ry on
Intellig Intellig iMaster NCE-CampusInsight collects KPIs and radio

ent ent parameters reported by devices and uses intelligent
wireles radio algorithms to calculate the load prediction information in
s calibrat the next calibration period. In addition, it accurately
networ ion identifies the network topology and edge AP list by utilizing
k the big data analytics algorithm, and pushes information to
devices in response to their requests. Wireless devices
perform intelligent radio calibration based on the
information delivered by iMaster NCE-CampusInsight and
the network information collected in real time. After the
radio calibration is complete, the devices periodically report
the KPI information and calibration logs of the current
network to iMaster NCE-CampusInsight. iMaster NCE-
CampusInsight then compares and displays the wireless
network parameters before and after the radio calibration.
WLAN Network plan import: After the network plan file made by
topolog the WLAN Planner is imported, iMaster NCE-CampusInsight
y displays data such as sites, pre-deployed APs, obstacles,
background images, and scale planned in the file.
Network comparison: After pre-deployed APs are
associated with real APs, the planned data and actual data
are compared in terms of the power, channel, frequency
bandwidth, number of clients, negotiated rate, and signal
strength, and the comparison result is displayed.
Wi-Fi heatmap display: The radio heatmap can be
displayed based on the AP location.
Spectru iMaster NCE-CampusInsight collects and analyzes channel

m scanning data sent by devices to implement the following
analysi functions:
s ● Displays the real-time status of all channels by AP.
● Allows you to view the historical trend chart of the
channel status, which includes the idle channel
proportion, normal usage proportion, co-channel
interference proportion, and non-Wi-Fi interference
proportion.
● Displays the types of non-Wi-Fi interference sources
detected on the network, affected working channels,
radio types, and RSSI strength.
● Displays the locations of non-Wi-Fi interference sources
and the scope of affected APs. (This function must be
used together with the RSSI-based location function.)


ry on
RSSI- iMaster NCE-CampusInsight collects and analyzes terminal

based location data sent by devices to implement the following
locatio functions:
n ● Displays real-time location information about a single
terminal or all terminals.
● Displays the walking path of a single terminal.
● Displays the heat map of terminal location distribution.
● Displays the locations of Wi-Fi interference sources.
User Applica Based on the monitoring and analysis of audio and video
applica tion service sessions, the SIP session statistics, service traffic
tion analysi trend, and session details list can be displayed, helping users
experie s quickly learn about the quality status of audio and video
nce services.
Intelligent O&M Deployment Planning

Figure 2-83 shows the deployment process of Huawei intelligent O&M solution,
which involves the following two aspects:
● Interconnection between iMaster NCE-Campus and CampusInsight: iMaster
NCE-Campus allows for unified O&M and management, and CampusInsight
can be invoked as a proxy service. iMaster NCE-Campus can synchronize site
and device information to CampusInsight.
● Collection of data such as syslogs and performance data of network devices:
The network devices must be enabled to collect and report O&M data to
CampusInsight.
NOTE
● The time on network devices must be synchronous with that on CampusInsight. If the
time difference between the network devices and CampusInsight is greater than 10
minutes, CampusInsight cannot display the data reported by the network devices.
Typically, you need to configure an NTP server with the same source to ensure time
synchronization between network devices and CampusInsight. During the installation of
CampusInsight, you need to enter the IP address of the external NTP clock source. In
addition, you need to configure the same IP address of the external NTP clock source on
the network devices.
● The wireless network uses the "WAC + Fit AP" architecture, and the performance data
collection function of the Fit APs must be enabled on the web system of the WAC. This
function cannot be enabled on iMaster NCE-Campus.
● To log in to CampusInsight through iMaster NCE-Campus as a proxy service, you need
to enable the intelligent analyzer agent feature on iMaster NCE-Campus in advance.

Figure 2-83 Configuring intelligent O&M
2.3 Distributed Gateway Solution Design

NOTE
In the distributed gateway solution, multiple border nodes are supported. Generally, it is
recommended that a single border node be deployed. If high reliability is needed on the
core layer, multi-border node networking is recommended. The following sections describe
the overall design process based on the single-border node solution. For details about the
differences between the multi-border node solution and the single-border node solution,
see 2.3.10.3 Multi-Border Node Reliability.
2.3.1 Overall Design
2.3.1.1 General Guidelines
2.3.1.1.1 Basic Design Guidelines

As a network infrastructure, campus networks provide users with network
communications services and resource access rights. Complicated access
relationships and diversified service types pose the needs for good design ideas
and guidelines. The following design guidelines apply to campus network design:
● Reliable: Campus networks must run stably and reliably without service
interruptions, ensuring service experience. This requires a redundant or
backup architecture for key components that can be used to quickly recover
from faults.
● Trustworthy: Campus networks must be secure and trustworthy to guarantee
network and service security. This requires comprehensive security protection
measures to prevent malicious damages, protecting data and network
security.

● Scalable: Campus networks must be able to be smoothly upgraded and

expanded to meet service requirements in the next 3 to 5 years, fully create
network values, reduce investment, and avoid waste of resources. This
requires for on-demand deployment of new services and smooth network
expansion.
● Manageable: Campus networks must be easy to manage, maintain, and
perform network diagnosis and fault locating, reducing the O&M difficulty
and improving customer experience. This requires intelligent, proactive, and
integrated management of multiple services over the entire network, real-
time network health analysis, proactive prevention, and fast fault locating to
reduce losses.
● Operational: Campus networks must support flexible deployment of new
services, such as Voice over Internet Protocol (VoIP), Unified Communications
(UC), Telepresence, and desktop cloud.
● Economic: The return on investment (ROI) should be maximized and the
investment costs should be reduced.
2.3.1.1.2 Device Naming Conventions

It is recommended that a device name consist of multiple fields to accurately
describe the physical location and role of the device on the campus network, as
shown in Figure 2-84. To prevent a long device name, the abbreviation of each
field is used, for example, A_B-4F_CSW_HW_S12700E-12_a.
Figure 2-84 Example of a device name
Table 2-47 Device naming conventions

Ide Description
ntif
ier
A Name of a campus site.
B Physical location of a device on a campus network. Generally, the location

is in the format of equipment room name + floor.
C Role of a device on a campus network.
D Device brand. For example, HW in the example indicates Huawei.
E Device model.
F Device number, which can be listed in alphabetical order or ascending

order.

2.3.1.1.3 Interface Description Conventions

It is recommended that the description command be configured for physical
interfaces to help you learn about interface connections. It is recommended that
the description contain three parts, as shown in Figure 2-85.
Figure 2-85 Example of an interface description
Table 2-48 Interface description conventions

Ide Description
ntif
ier
A Direction of a local connection, for example, an interface connected to a

downstream device.
B Name of a peer device.
C Interface of the peer device.
2.3.1.2.1 Virtual Campus Network Architecture Overview

On a large or midsize campus network, the virtualization solution can be used to
decouple services from the network, construct a multi-purpose network, and
achieve flexible, fast service deployment without changing the basic network
infrastructure. In this solution, the virtual campus network architecture poses
requirements different from those on traditional network architecture. Figure 2-86
illustrates the virtual campus network architecture. The underlay is the physical
network layer, and the overlay is the virtual network layer constructed on top of
the underlay based on the Virtual Extensible LAN (VXLAN) technology.

Figure 2-86 Virtual campus network architecture
The overlay consists of the fabric and VN.

● Fabric: a network with pooled resources abstracted from the underlay
network. When creating an instantiated virtual network (VN), you can select
the pooled network resources on the fabric.
On a fabric network, VXLAN tunnel endpoints (VTEPs) are further divided into
the following roles:
– Border: border node of the fabric network. It corresponds to a physical
network device and provides data forwarding between the fabric and
external networks. Generally, VXLAN-capable core switches function as
border nodes.
– Edge: edge node of the fabric network, which corresponds to a physical
network device. User traffic enters the fabric network from the edge
node. Generally, VXLAN-capable access or aggregation switches are used
as edge nodes.
● VN: logically isolated virtual network instances (VN 1 and VN 2 in the figure)
that are constructed by instantiating a fabric. One VN corresponds to one
isolated network (service network), for example, R&D network.
Table 2-49 lists the resource pools on a fabric and how to invoke these resources
during VN creation.

Table 2-49 Resource pools on a fabric and resource invoking methods during VN
creation
Resource Pool on a Fabric How to Invoke Resources in a
Resource Pool During VN Creation
VN resource pool, which contains the Each time a VN is created, a VN

number of VNs that can be created on resource is used.
an overlay.
VLAN resource pool, which is used in When creating a user gateway in a

scenarios where terminals are VN, you can select a resource from the
connected to VNs and VNs fabric global resource pool to
communicate with external network configure a user VLAN.
resources. The VLAN resource pool is
planned when configuring the fabric
global resource pool.
BD/VNI resource pool, which is used When a user gateway is created in a

when dividing Layer 2 broadcast VN, resources in the BD/VNI resource
domains in a VN and configuring pool are automatically invoked to
corresponding VBDIF interfaces that create a BD and the corresponding
function as the gateway interfaces of VBDIF interface.
user subnets. The BD/VNI resource
pool is planned when configuring the
fabric global resource pool.
User access point resource pool, which When configuring user access in a VN,
is planned during access management you can select planned access point
configuration for a fabric. This resource resources.
pool includes the authentication
modes that can be bound to access
points.
Egress pool, which contains the When creating a VN, you can select
external resources that can be used by external networks and network service
VNs. Two types of external resources resources.
are created during fabric configuration:
● External networks: used for VNs to
communicate externally
● Network service resources: used for
VNs to communicate with the
authentication server and DHCP
server
2.3.1.2.2 Underlay Network Architecture Design

physical network uses the network planning for traditional large- and medium-
sized campus networks, and typically adopts a tree-type network architecture with
the core layer as the root. This type of architecture features stable topology and is
easy to expand and maintain. As illustrated in Figure 2-87, the campus network is
composed of the access layer, aggregation layer, and core layer, as well as some

functional zones. Modules in each functional zone are clearly defined, and the
internal adjustment of each module is limited to a small scope, facilitating fault
location.
Figure 2-87 Physical network in the virtualization solution for large- and medium-
sized campus networks
In office, education, and hospitality scenarios, central switches and remote units
(RUs) are deployed together to build simplified all-optical campus networks. The
three-layer networking (core, aggregation, and access) for ELV rooms is changed
to the two-layer (core and aggregation) networking. At the access layer, RUs are
deployed to enable access to the desktop. The three-layer networking is also
supported, where access switches function as central switches and RUs are
connected to the access switches.

Figure 2-88 Simplified all-optical networking topology for large and midsize
campus networks
Table 2-50 Physical network layers and functional zones

Na Description
me
Ter The terminal layer involves various terminals that access the campus
min network, such as PCs, printers, IP phones, mobile phones, and cameras.
al
laye
r
RU On a simplified all-optical campus network, RUs need to work together

with central switches and can be remotely deployed on desktops.
Acce The access layer provides various access modes for users and is the first
ss network layer to which terminals connect. The access layer is usually
laye composed of access switches. There are a large number of access
r switches that are sparsely distributed in different places on the network.
In most cases, an access switch is a simple Layer 2 switch. If wireless
terminals are present at the terminal layer, wireless access points (APs)
need to be deployed at the access layer and access the network through
access switches.
On a three-layer simplified all-optical campus network, access switches
are deployed as central switches to manage the connected RUs.
Agg The aggregation layer sits between the core and access layers. It
rega forwards horizontal traffic (east-west traffic) between users and forwards
tion vertical traffic (north-south traffic) to the core layer. The aggregation
laye layer can also function as the switching core for a department or zone
r and connect the department or zone to a dedicated server zone. In
addition, the aggregation layer can further extend the quantity of access
terminals.
On a two-layer simplified all-optical campus network, aggregation
switches are deployed as central switches to manage the connected RUs.

Na Description
me
Core The core layer is the core of data exchange on a campus network. It
laye connects to various components of the campus network, such as the DC/
r network management zone, aggregation layer, and campus egress. The
core layer is responsible for high-speed interconnection of the entire
campus network. High-performance core switches need to be deployed
to meet network requirements for high bandwidth and fast convergence
upon network faults. It is recommended that the core layer be deployed
for any campus with more than three departments.
Egre The campus egress is the boundary that connects a campus network to
ss an external network. Internal users of the campus network can access
net the external network through the campus egress zone, and external
wor users can access the internal network through the campus egress zone.
k Firewalls need to be deployed in the campus egress zone to provide
perimeter security protection.
DC In the DC zone, service servers such as the file server and email server
zon are managed, and services are provided for internal and external users.
e
Net The network management zone is the server zone where the O&M and
wor management systems are deployed. In the virtualization solution for
k large- and medium-sized campus networks, the following systems are
man deployed:
age ● iMaster NCE-Campus: campus network automation engine. It is used
men to provision service configurations for network devices; provides open
t APIs for integration with third-party platforms; and can function as an
zon authentication policy server to deliver authentication, authorization,
e accounting (AAA) and free mobility services.
● iMaster NCE-CampusInsight: intelligent campus network analytics
engine, which provides intelligent O&M services by utilizing Telemetry,
big data, and intelligent algorithms.
● DHCP server: dynamically assigns IP addresses to user clients.
DM The demilitarized zone (DMZ) provides access services with strictly

Z controlled security for external guests (personnel other than the
enterprise employees). Public servers are usually deployed in the DMZ.
Hierarchical Physical Network Architecture Planning

In practice, you can flexibly select the two-layer or three-layer architecture for the
physical network based on the network scale or service requirements, as shown in
Figure 2-89.
architecture, that is, only the access layer and aggregation layer are required. A
large-scale campus network (such as a university campus network) that involves
multiple buildings usually uses the three-layer architecture that consists of the
access, aggregation, and core layers.

During network design, you can use the bottom-up method to determine the
layered architecture depending on the network scale, as illustrated in Figure 2-90.

NOTE
2.3.1.2.3 Overlay Network Architecture Design

The overlay network architecture design is to design the fabric network. As
demonstrated in Figure 2-91, a fabric network can adopt a two-layer or three-
layer network architecture based on physical network layers. The three-layer
network architecture supports two VXLAN networking types: VXLAN deployed
across core and aggregation layers and VXLAN deployed across core and access
layers.
The distributed gateway solution is recommended to be deployed on a large-scale

three-layer physical network. For a small-scale two-layer network, the centralized
gateway solution is recommended, because the border node can act as the user
gateway for unified management and simplified O&M. In addition, it is
recommended that VXLAN be deployed across core and aggregation layers for the
fabric network. If VXLAN is deployed across core and access layers, access switches
function as edge nodes as well as wired user gateways, greatly increasing the
O&M and management workload.
2.3.1.3 Network Resource Planning
BD Resource Planning
In a VN, a Layer 2 broadcast domain is constructed based on bridge domains
(BDs). In a BD, user terminals in different geographical locations can communicate
with each other. In the virtualization solution for large- and medium-sized campus
networks, BD resource planning guidelines are as follows:
● 1:1 mapping between BDs and user service VLANs is recommended, as shown
in Figure 2-92.
● In a VN, each time a VXLAN user gateway is created, a BD is automatically
invoked from the global BD resource pool of the fabric in sequence. You do

not need to consider how to divide a BD. Instead, you only need to consider
how to assign user service VLANs.
● BD resources in the BD resource pool must be sufficient to support user
service VLAN assignment.
Figure 2-92 Association between a BD and a service VLAN
VLAN Resource Planning

In the virtualization solution for large- and medium-sized campus networks, a
large Layer 2 broadcast domain can be constructed based on BDs. However, user
terminals still connect to campus networks through VLANs, and the VLANs are
bound to BDs. In addition, campus networks need to be interconnected through
VLANs. The virtualization solution for large- and medium-sized campus networks
complies with the VLAN planning guidelines of traditional campus networks:
● Assign VLANs based on service zones.
● Assign a VLAN to each service type.
● Allocate consecutive VLAN IDs to ensure proper use of VLAN resources.
● Reserve a specific number of VLANs for future use.
VLANs are classified into management, interconnection, and service VLANs. For
details about the design suggestions, see Table 2-51.

Table 2-51 VLAN resource planning recommendations

Cate Recommendation
gory
Man A management VLAN is used to manage network devices on the campus

age network. The following describes the management VLAN planning for
men network devices at different layers and in different functional zones:
t ● Servers in the network management zone: If the network is not a
VLA data center network and has a small number of servers, it is
N recommended that all servers be added to the same management
VLAN.
● Switches in the network management zone: If the network is not a
data center network and has a small number of switches, you are
advised to use physical management interfaces to manage these
switches, removing the need to plan a management VLAN.
● Egress network devices: You are advised to use Layer 3 service
interfaces as management interfaces, removing the need to plan a
management VLAN.
● Core switches: You are advised to plan a separate management VLAN
and use the VLANIF interface of the management VLAN as the
management interface. iMaster NCE-Campus manages core switches
through the management interface.
● Devices below the core layer: You are advised to plan one or more
management VLANs based on the device scale and use the VLANIF
interface of the management VLAN as the management interface.
iMaster NCE-Campus manages devices through the management
interface.
– If a small number of devices are deployed, it is recommended that
all aggregation switches, access switches, and APs use the same
management VLAN.
– If a large number of devices are deployed, it is recommended that
all aggregation switches and access switches use the same
management VLAN and all APs use the same management VLAN.
– If a large number of devices are deployed, you are advised to plan
device groups based on network layers. Each device group uses the
same management VLAN. For example, each aggregation switch
and its connected downstream devices are grouped into a device
group and use the same management VLAN.

Cate Recommendation
gory
Inter In the virtualization solution for large- and medium-sized campus

conn networks, VLANs are required for interconnection on both the underlay
ectio and overlay networks.
n ● Underlay network: involves the VLAN for interconnection between
VLA core switches and the network management zone (in most cases, the
N interconnection VLAN is the management VLAN of core switches),
VLAN for interconnection between egress devices and other devices,
and VLAN for interconnection between devices at the core layer and
lower layers (used for automatic OSPF route orchestration).
● Overlay network: involves the VLAN for interconnection between the
core switches functioning as border nodes and external networks and
the VLAN for interconnection between border nodes and network
service resources.
Servi Assign VLANs based on logical areas, organizational structures, and

ce service types.
VLA ● Assign VLANs based on logical areas. For example, VLANs 200 to 999
N are used in the server zone, and VLANs 2000 to 3499 are used on the
access network.
● Assign VLANs based on organizational structures. For example,
department A uses VLANs 2000 to 2499, and department B uses
VLANs 2500 to 2999.
● Assign VLANs based on service types. For example, employees in
department A use VLANs 2000 to 2099, and dumb terminals in
department A use VLANs 2100 to 2199.
NOTE
point and policy enforcement point, you need to plan a management VLAN for policy
association to establish a CAPWAP tunnel between the authentication point and policy
enforcement point. In the distributed gateway solution, if VXLAN is deployed across core
and aggregation layers (recommended) on the fabric network, policy association is usually
deployed on the aggregation switches (edge nodes) and access switches. If edge nodes also
function as native WACs, APs connected to access switches can establish CAPWAP tunnels
with the edge nodes through the management VLAN for policy association and go online
on the edge nodes. In this case, no additional management VLAN needs to be planned.

IP address assignment needs to comply with the following rules:
● Uniqueness: Each host on an IP network must have a unique IP address. Even
if the Multiprotocol Label Switching (MPLS) or Virtual Private Network (VPN)
is used, it is recommended that different virtual routing and forwarding (VRF)
instances use different IP addresses.
● Contiguousness: Node addresses of the same service must be contiguous to
facilitate route planning and summarization. Contiguous addresses facilitate
route summarization, reducing the size of the routing table and speeding up

route calculation and convergence. An aggregation switch may connect to

multiple network segments. When allocating IP addresses, ensure that routes
of these network segments can be summarized to reduce the number of
routes on core devices.
● Scalability: IP addresses need to be reserved at each layer. When the network
is expanded, no address segments or routes need to be added.
● Easy maintenance: Device and service address segments need to be clearly
distinguished from each other, facilitating subsequent statistics monitoring
and security protection based on address segments. If an IP address is
planned properly, you can determine the device to which the IP address
belongs. IP address planning and VLAN planning can be associated. For
example, the third byte of an IP address can be the same as the last three
digits of a VLAN ID, which is easy to remember and facilitates management.
● It is recommended that internal hosts on a campus network use private IP
addresses, and NAT devices be deployed at the campus egress to translate
private IP addresses into public IP addresses so that internal hosts can access
public networks. A few devices in the DMZ and the Internet zone use public IP
addresses.
IP addresses on a campus network include management IP addresses,
interconnection IP addresses, service IP addresses, and loopback interface
addresses, as shown in Table 2-52.
Table 2-52 IP address planning recommendations

Categor Suggestion
y
Manage Used for communication with iMaster NCE-Campus or for a local

ment IP login. It is recommended that devices in the same management
address VLAN use IP addresses on the same IP address segment. The
management IP addresses of network devices at different layers and
in different functional zones are planned as follows:
● Management IP addresses of servers in the network management
zone, which are configured on the iBMC management interface
● Management IP addresses of switches in the network
management zone
● Management IP addresses of egress devices. It is recommended
that a service interface be used as the management interface,
removing the need to plan the management interface separately.
● Management IP addresses of core switches
● Management IP addresses of devices below the aggregation layer

Categor Suggestion
y
Intercon An interconnection address is the IP address of an interface

nection connected to another device's interface. It is recommended that the
IP IP address with a 30-bit mask be used as an interconnection address.
address A core device uses a smaller IP address. An interconnection address
is usually summarized and advertised. During IP address planning,
consider the use of contiguous IP addresses that can be summarized.
In the virtualization solution for large- and medium-sized campus
networks, both the underlay network and overlay network need to
use IP addresses for interconnection.
● Underlay network: includes the IP addresses for interconnection
between core switches and the network management zone, IP
addresses for interconnection between egress devices and other
devices, and IP addresses for interconnection between devices at
the core layer and devices at lower layers (for automatic OSPF
route orchestration). Generally, an interconnection VLANIF
interface is the management VLANIF interface of a core switch.
● Overlay network: includes the IP addresses for interconnection
between the core switches functioning as border nodes and
external networks and IP addresses for interconnection between
the core switches functioning as border nodes and network
service resources.
Service A service address is the IP address of a server, service terminal, or

IP gateway. You are advised to use the same last digits as the gateway
address address. For example, gateways use IP addresses suffixed by .254.
The IP address range of each service must be clearly distinguished.
The IP addresses of each type of service terminals must be
contiguous and can be summarized. Considering the scope of a
broadcast domain and easy planning, it is recommended that an
address segment with a 24-bit mask be reserved for each service. If
the number of service terminals exceeds 200, an extra address
segment with a 24-bit mask is assigned.
Loopbac A loopback interface address is often specified as the source address

k of packets to improve network reliability. The virtualization solution
interface for large- and medium-sized campus networks uses the VXLAN
address technology. The control plane of VXLAN uses BGP EVPN for
interaction, requiring loopback interfaces to be used to establish BGP
peer relationships between VTEPs (border or edge nodes).

NOTE
point and policy enforcement point, you need to plan a management VLAN for policy
association to establish a CAPWAP tunnel between the authentication point and policy
enforcement point. In the distributed gateway solution, if VXLAN is deployed across core
and aggregation layers (recommended) on the fabric network, policy association is usually
deployed on the aggregation switches (edge nodes) and access switches. If edge nodes also
function as native WACs, after management IP addresses for policy association are
configured on the edge nodes, APs connected to access switches can go online on the edge
nodes. In this case, no additional management IP address needs to be planned.
2.3.1.3.3 DHCP Planning

DHCP function is required for management subnet design during device
deployment and for user subnet design in a VN, as shown in Figure 2-93.
Figure 2-93 Application scenario for DHCP
DHCP Planning for the Management Subnet

A large or midsize campus network often has a large number of devices below the
core layer. During device deployment, you are advised to plan a DHCP server
dedicated to management address allocation of devices. DHCP planning for the
management subnet is as follows:
● It is recommended that a core switch be used as the DHCP server of the

management subnet and an IP address pool be configured on the gateway
interface of the management subnet.
● Configure DHCP Option 148 to contain iMaster NCE-Campus address
information.
● If the gateway interface of the management subnet also functions as the
gateway interface of the AP management subnet, you are advised to
configure DHCP Option 43 to contain WAC address information.

DHCP Planning for the User Subnet

It is recommended that a separate DHCP server be planned for large- and
medium-sized campus networks to allocate IP addresses to user terminals. DHCP
planning for the user subnet is as follows:
● It is recommended that a DHCP server be planned for the entire campus

network to simplify O&M.
● In most cases, the DHCP server and hosts on a large or midsize campus
network are on different network segments. You are advised to enable the
DHCP relay function on user gateways.
● You are advised to configure DHCP snooping in the BD where a user gateway
belongs to ensure that user terminals obtain IP addresses from a valid DHCP
server and prevent attacks. In addition, if DHCP options are used for terminal
identification, DHCP snooping also needs to be configured.
● In dynamic IP address allocation provided by DHCP, the lease period of IP
addresses needs to be planned based on the online duration of user terminals.
In large- and medium-sized campus networks, the online duration of user
terminals in the office area are long, so a long lease period needs to be
planned for IP addresses of these user terminals.
If a fixed IP address needs to be allocated to a specific user terminal, this IP
address must be excluded from the DHCP address pool during DHCP address
pool planning. This is to prevent this IP address from being allocated.
2.3.1.4 Routing Protocol Planning

In the virtualization solution for large- and medium-sized campus networks,
routing protocols need to be deployed on both the underlay and overlay networks
to implement different Layer 3 interconnection requirements, as shown in Figure
2-94. Table 2-53 describes the scenarios where routing protocols need to be
deployed on the underlay and overlay networks and routing protocol planning.
Figure 2-94 Routing protocol planning in the virtualization solution for large- and
medium-sized campus networks

Table 2-53 Routing protocol planning in different scenarios of the virtualization

solution for large- and medium-sized campus networks
ng Scenarios
Protoc
ol
Deplo
yment
Scena
rio

Comm communication between
unicati iMaster NCE-Campus and
on network devices to implement
betwe configuration, management,
en the and intelligent O&M on these
netwo devices.
rk ● If the network management
manag zone is a simple network where
ement software systems such as
zone iMaster NCE-Campus are
and installed, you are advised to
device configure static routes on the
manag gateway in the network
ement management zone and the
subnet core switch.
● If the network management
zone is a data center, you need
to flexibly configure routes for
the gateway in the network
management zone and the
core switch based on the
routing protocol used by the
data center network.


ng Scenarios
Protoc
ol
Deplo
yment
Scena
rio
2. ● Routing protocols are mainly

Comm used for Layer 3
unicati communication on the
on underlay network as the basis
betwe for overlay network
en deployment.
core, ● Routing tables can be
aggreg dynamically updated based on
ation, the network topology.
and Therefore, it is recommended
access that an IGP, such as OSPF, be
switch planned. It is recommended
es that OSPF routes be
automatically orchestrated
through iMaster NCE-Campus,
removing the need to manually
configure routes.
● Automatic OSPF route
orchestration enables devices
to import the network
segments of BGP source
interfaces (such as loopback
interfaces) into the OSPF
routing domain so that the
BGP source interfaces can
communicate with each other.
3. ● In most cases, BGP is deployed

Comm between border and edge
unicati nodes and between edge
on on nodes. BGP EVPN is used to
the implement functions on the
VXLAN VXLAN control plane, including
control dynamic VXLAN tunnel
plane establishment, ARP entry
transmission, and routing
information transmission.
● It is recommended that a
border node be configured as a
route reflector (RR) to simplify
BGP peer configuration.


ng Scenarios
Protoc
ol
Deplo
yment
Scena
rio
4. ● Routing protocols are used on

Inter- a border node for
VN communication between
comm different user subnets of VNs.
unicati ● Different user subnets of VNs
on can also communicate with
each other through firewalls.
● To implement such
communication on a border
node, configure the border
node through iMaster NCE-
Campus. After the
configuration is complete, the
border node uses BGP to
import routes to user subnets
between VRF instances of
different VNs.


ng Scenarios
Protoc
ol
Deplo
yment
Scena
rio
5. ● Routing protocols are used by

Comm devices on user subnets of a
unicati VN to access the Internet and
on WANs.
betwe ● If two firewalls implement HSB
en a using VRRP, one as the VRRP
VN master and the other VRRP
and an backup, static routes are
extern recommended between the
al firewall and border node. If
netwo VRRP is not deployed on
rk firewalls, dynamic routes need
to be used between the firewall
and border node. During
active/standby firewall
switchover, dynamic routes can
be used to implement
automatic switching of the
service traffic paths.
● On the border node, you can
create external network
resources for the fabric through
iMaster NCE-Campus and
configure an interface and
routing protocol for
interconnection with the
firewall.
After the VN selects external
network resources, the border
external network resources and
CLI of the firewall to configure
the firewall.


ng Scenarios
Protoc
ol
Deplo
yment
Scena
rio

Comm communication between user
unicati subnets in a VN and network
on service resources such as the
betwe DHCP server and network
en a access control (NAC) server.
VN ● Static routes are recommended.
and
the ● Network service resources of
netwo the fabric are created for the
rk border node through iMaster
manag NCE-Campus. During the
ement creation, the interface for
zone connecting the border node to
the network management zone
is configured, and a static route
to the network service
resources is automatically
created.
After a VN selects a network
service resource, the border
network service resource and
CLI of a gateway in the
network management zone to
configure the gateway.
2.3.2 iMaster NCE-Campus Installation Planning

Flexible installation of iMaster NCE-Campus can be provided based on project
requirements. For details about the installation planning and design of iMaster
NCE-Campus, see section "Installation".
2.3.3 Underlay Network Design
2.3.3.1 Network Management Zone Design

If an independent data center equipment room is present on a large or midsize
campus network, software systems such as iMaster NCE-Campus can be directly

installed on servers in the equipment room. During the installation, make sure
that the egress gateway can communicate with the campus intranet. This section
describes the basic server networking design for communication between these
software systems and the campus intranet.
● A stacked Layer 3 switch functions as the server gateway and is directly

connected to software servers and the core switch cluster.
● iMaster NCE-Campus and iMaster NCE-CampusInsight use the minimum
cluster size and two network planes.
● On the stacked Layer 3 switch, VLANs are created to isolate all network
planes on the servers. The gateway interface of each network plane is the
VLANIF interface of the given VLAN.
Figure 2-95 Basic networking of the network management zone
Server and Gateway Interconnection Design

To ensure network reliability, multiple NICs are bonded on servers, which are
connected to the server gateway through one bonded interface. NIC bonding
modes include active-backup and load balancing. The configurations for
connecting servers to their gateway vary slightly in the two modes.
Active-backup mode
In this mode, one NIC interface in the bonded interface is in the active state, and
the other is in the backup state. All data is transmitted through the active NIC
interface. In the event of a failure on the link corresponding to the active NIC
interface, data is transmitted through the backup NIC interface. In this case, the

Layer 3 switch functioning as the server gateway connects to the two NIC
interfaces on a server through two physical ports. The physical ports do not need
to be aggregated, and are recommended to be added to the VLAN of the
corresponding network plane in access mode. As shown in Figure 2-96, add
physical ports (GE1/0/1 and GE2/0/1) on the switch to VLAN 100 using the
following commands.
Figure 2-96 Server-switch interconnection in active-backup mode
<Switch> system-view
Load balancing mode

In this mode, multiple NICs of a server transmit data packets based on the
specified hash policy. To enable server-switch interconnection, you need to
configure an Eth-Trunk interface in manual mode on the Layer 3 switch
functioning as the server gateway, connect the Eth-Trunk interface to the bonded
interface on the server, and then add the Eth-Trunk interface to the VLAN of the
corresponding network plane in access mode. As shown in Figure 2-97, add Eth-
Trunk 1 on the switch to VLAN 100 using the following commands.

Figure 2-97 Server-switch interconnection in load balancing mode
<Switch> system
[Switch] interface eth-trunk 1
[Switch-Eth-Trunk1] trunkport gigabitethernet 1/0/1 2/0/1
[Switch-Eth-Trunk1] port link-type access
[Switch-Eth-Trunk1] port default vlan 100
[Switch-Eth-Trunk1] quit
Design for Communication Between the Network Management Zone and

Campus Intranet
network management zone needs to communicate with the device management
subnet on the underlay network and the user subnet on the overlay network. This
is to ensure that each software system can manage devices on the campus
intranet and communicate with the user subnet to implement a service function.
Table 2-54 lists the common software systems that need to communicate with
the campus intranet in this solution.
Table 2-54 Description for communication between common software systems


n Type System
Communicatio iMaster NCE- Manages devices on the campus intranet,

n with the Campus and configures and provisions services.
device Devices need to interconnect with iMaster
management NCE-Campus.
subnet on the
underlay iMaster NCE- Performs intelligent O&M on the campus
network CampusInsight intranet. Devices need to interconnect with
iMaster NCE-CampusInsight and report
performance data to it.
Communicatio iMaster NCE- Functions as the NAC server for user access
n with the user Campus authentication. The user subnet must be
subnet on the able to communicate with iMaster NCE-
Campus.


n Type System
overlay DHCP server Dynamically assigns IP addresses to user

network terminals. The user subnet must be able to
communicate with the DHCP server.
The network management zone adopts the basic networking design, the topology
cluster is stable, and only a few network segments are required for
communication. If this is the case, you are advised to configure static routes
cluster. As illustrated in Figure 2-98, the planning of static routes is as follows:
● Two VLANIF interfaces are separately planned on the gateway in the network
management zone as well as on the core switch. One (VLANIF 500 in the
figure) is used for communication between the network management zone
and the device management subnet on the underlay network, and the other
(VLANIF 600 in the figure) for communication between the network
management zone and the user subnet on the overlay network.
● For communication between the network management zone and the device
management subnet on the underlay network:
– On the core switch: Configure a static route destined for the network
management zone. The destination network segment is the network
segment where the software systems (for example, iMaster NCE-Campus
and iMaster NCE-CampusInsight in the figure) that need to communicate
with the device management subnet resides. The next hop of the static
route is the IP address of VLANIF 500 on the gateway in the network
management zone.
– On the gateway in the network management zone: Configure a route
destined for the device management subnet on the underlay network.
The destination network segment is the device management network
segment, and the next hop is the IP address of VLANIF 500 on the core
switch.
● For communication between the network management zone and the user
subnet on the overlay network:
– On the core switch: When creating network service resources for a fabric,
configure the IP addresses of the connected network service resources as
well as the VLANs and IP addresses for interconnecting with the gateway
in the network management zone on the core switch that functions as
the border node. After the configuration is complete, the core switch
imports routes between the virtual routing and forwarding (VRF) instance
that represents the network service resource and the VRF instance that
represents a VN. In addition, the core switch creates a private static route
destined for the network management zone in the VRF instance that
represents the network service resource. The destination network
segment of this static route is the network segment where the software
system that needs to communicate with the user subnet resides, such as
iMaster NCE-Campus or the DHCP server in the figure.

– On the gateway in the network management zone: Configure a static

route destined for the user subnet on the overlay network. The
destination network segment is the user network segment, and the next
hop is the IP address of VLANIF 600 on the core switch.
Figure 2-98 Planning for communication between the network management zone
2.3.3.2 Deployment Design
Deployment Configuration Mode Planning

Table 2-55 lists the network devices involved in the virtualization solution for a
large or midsize campus network and the recommended deployment
configuration modes.

Table 2-55 Recommended deployment configuration modes for different network

devices
atio Deployment
n Configuration
Mode
Net Switch Local CLI or web Generally, you need to configure the
wor (gateway in system switch before installing software
k the network systems in the network
man management management zone.
age zone)
men
t
zone
Egre Firewall Local CLI or web Generally, firewalls are deployed in

ss system a core equipment room and have
net complex service configurations.
wor Therefore, local configuration is
k recommended.
Core Core switch Centralized Generally, core switches are

laye (If a native configuration on deployed in a core equipment room.
r WAC is iMaster NCE- After a core switch goes online on
required for Campus after iMaster NCE-Campus through the
deploying going online on it CLI, it can be used as the root
wireless through the CLI device of management subnets
services, it is below the core layer to implement
recommende plug-and-play of devices below the
d that the core layer.
core switch
be used as
the native
WAC.)
Agg Aggregation Centralized A large number of aggregation

rega switch configuration on switches are deployed at scattered
tion iMaster NCE- locations. You are advised to
laye Campus onboard aggregation switches on
r iMaster NCE-Campus through DHCP
deployment.
When aggregation switches
function as native WACs, you can
log in to the web system or CLI of
the aggregation switch to configure
wireless services.


atio Deployment
n Configuration
Mode
Acce Access switch Centralized A large number of access switches

ss configuration on are deployed at scattered locations.
laye iMaster NCE- You are advised to onboard access
r Campus switches on iMaster NCE-Campus
AP Centralized Generally, the "WAC + Fit AP"

configuration on architecture is used for the WLAN of
the WAC a large or midsize campus network
and APs are managed by the WAC
in a centralized manner. A large
number of APs are deployed at
scattered locations. You are advised
to onboard APs on the WAC
Management VLAN Communication Design for Devices Below the Core

Layer Plug-and-Play for the First Time
NOTE
In the distributed gateway solution, if the fabric uses the recommended networking of
VXLAN deployed across core and aggregation layers and edge nodes that provide the native
WAC function are used, policy association is deployed between aggregation switches (edge
nodes) and access switches. In this way, an AP connected to an access switch can establish
a CAPWAP tunnel with an edge node through the management VLAN for policy association
and go online on the edge node. No additional management VLAN is required. For details
about the AP join process design, see "AP Join Process Design" in 2.3.5 WLAN Design.
On a large or midsize campus network, you are advised to deploy devices below
the core layer in plug-and-play mode through DHCP to onboard aggregation and
access switches on iMaster NCE-Campus and APs on the WAC. How to implement
management VLAN communication is critical for onboarding devices below the
core layer. In the distributed gateway solution, the management VLANs of
aggregation and access switches can communicate with each other in the
following modes:
Using default VLAN 1 as the management VLAN
As shown in Figure 2-99, the process for onboarding aggregation and access
switches on iMaster NCE-Campus using VLAN 1 (default VLAN) is as follows:
1. The core switch goes online on iMaster NCE-Campus through the CLI.
pool, and configure DHCP Option 148 to carry the southbound IP address of
iMaster NCE-Campus.

3. By default, all interfaces on a device are added to VLAN 1 before delivery.

Therefore, devices at the core, aggregation, and access layers can
communicate with each other in VLAN 1.
4. The aggregation and access switches obtain the southbound IP address of
iMaster NCE-Campus through VLAN 1 and go online on iMaster NCE-Campus.
Figure 2-99 Using default VLAN 1 for plug-and-play deployment of devices below
the core layer
Using an auto-negotiated management VLAN
If VLAN 1 is used as the management VLAN, broadcast storms may occur. To avoid
this, you can enable management VLAN auto-negotiation to configure another
VLAN as the management VLAN. As shown in Figure 2-100, assume that VLAN
100 is used as the auto-negotiated management VLAN. The process for
onboarding aggregation and access switches in plug-and-play mode is as follows:
1. The core switch goes online on iMaster NCE-Campus through the CLI.
pool, and configure DHCP Option 148 to carry the southbound IP address of
iMaster NCE-Campus.
3. Configure the core switch as the root device and use the management VLAN
auto-negotiation function to enable management VLAN communication for
devices below the core layer. The process is as follows:
a. On iMaster NCE-Campus, enable the management VLAN auto-
negotiation function on the core switch and configure VLAN 100 as the
auto-negotiated management VLAN.
b. After the core switch is configured, aggregation switches automatically
add their interfaces to VLAN 100 through protocol packet auto-
negotiation.

c. After the management channels between the core and aggregation

switches are established, access switches automatically add their
interfaces to VLAN 100 through protocol packet auto-negotiation.
4. The aggregation and access switches obtain the southbound IP address of
iMaster NCE-Campus through VLAN 100 and go online on iMaster NCE-
Campus.
Figure 2-100 Using an auto-negotiated management VLAN for plug-and-play

deployment of devices below the core layer
Management VLAN Switching Design After Devices Below the Core Layer Go
Online
Sometimes, there are a large number of network devices on a campus network.
After these devices go online in plug-and-play mode for the first time, broadcast
storms may still occur even if an auto-negotiated management VLAN is used. In
this case, you are advised to plan multiple management VLANs. After devices go
online in plug-and-play mode for the first time, switch the management VLAN to
isolate the broadcast domains of these devices.
In the distributed gateway solution, management VLAN switching is not required
for APs that go online through a management VLAN for policy association, which
is different from the management VLAN for switch onboarding. For switches, if
the broadcast storm risk is still high without the presence of APs, you are advised
to plan device groups based on network layers and configure each device group to
use the same management VLAN during VLAN switching. For example, each
aggregation switch and its connected downstream devices are grouped into a
device group and use the same management VLAN, as shown in Figure 2-101.

Figure 2-101 Management VLAN switching planning
Note: Before switching the management VLAN, add the interconnection interfaces
on the core switch and devices below the core layer to the new management
VLAN. In this way, devices below the core layer will not fail to go online due to
communication failures with the core switch on the new management VLAN.
iMaster NCE-Campus-based Deployment Process Design

On a large or midsize campus network, there are a large number of switches and
APs. Two iMaster NCE-Campus-based deployment roadmaps apply to this
scenario, as shown in Figure 2-24. It is recommended that the administrator plan
the network first, import planning information to iMaster NCE-Campus, and then
configure device onboarding modes for deployment. This reduces the deployment
workload. If the network cannot be planned in advance, the administrator can
onboard devices and then determine the network topology.

Figure 2-102 iMaster NCE-Campus-based deployment process for switches and

APs
Onboard devices and then determine the network topology

In this mode, configure device information such as ESNs on iMaster NCE-Campus
first, bring devices online, and then configure physical links. If these devices need
to be connected through aggregated links (Eth-Trunks), you can manually create
such links. The process of deploying switches and APs in this mode is as follows:
2. Enter device ESNs to add devices to this site. Enter AP ESNs and associate APs
with the WAC on iMaster NCE-Campus.
on the WAC.
Set up required switch stacks in advance, add the stacks to this site, and
synchronize information such as stack IDs and priorities. Stacks can be
manually configured before device management or added to a site by active
detection of iMaster NCE-Campus after device management.
4. After devices go online, you can manually create Eth-Trunk interfaces on the
devices as required.
Import the network plan and then onboard devices
In this mode, you can plan the network first and then import the planned basic
network information, including device ESNs, stack information, and Eth-Trunk

information, to iMaster NCE-Campus in a batch using a network plan import

template. In this way, the network topology can be pre-configured, reducing the
deployment workload. The process of deploying switches and APs in this mode is
as follows:
2. Fill in the network plan import template to import the following device, stack,
and link information to this site in a batch.
– Switch and AP information, including device ESNs, models, and roles
– Switch stack information, including stack system names, stack IDs, and
priorities
– Switch Eth-Trunk information, including the upstream and downstream
switch names, upstream and downstream physical member port
numbers, and upstream and downstream Eth-Trunk interface names
During the import, iMaster NCE-Campus automatically enables the Eth-
Trunk auto-negotiation function for the preconfigured downstream Eth-
Trunk interfaces.
on the WAC.
After the switches go online, iMaster NCE-Campus automatically delivers the
imported Eth-Trunk preconfiguration to them and performs Eth-Trunk auto-
negotiation. Once the Eth-Trunk auto-negotiation is successful, the
management VLAN is automatically renegotiated. Finally, the aggregation
and access switches come back online on iMaster NCE-Campus through Eth-
Trunks.
2.3.3.3 Automatic Intranet Route Orchestration Design

the automatic underlay route orchestration function. With this function, iMaster
NCE-Campus can automatically configure OSPF routes, divide OSPF areas, and
deliver interface configurations for access to core layer based on the physical
network topology. The physical network topology is imported to iMaster NCE-
Campus based on the configuration plan or automatically learned by iMaster
NCE-Campus.
Automatic underlay route orchestration falls in to single-area orchestration and
multi-area orchestration, as shown in Figure 2-103.

Figure 2-103 Automatic underlay route orchestration
When there are fewer than 100 switches in a network area where routes need to
be deployed on the underlay network, single-area orchestration is recommended.
● All switches between the border and edge nodes on the fabric are planned in
area 0.
through OSPF. The interconnected Layer 2 interfaces allow packets from the
corresponding VLANs to pass through.
● When configuring a fabric, you need to create loopback interfaces on the
switches that function as border and edge nodes for establishing BGP EVPN
peer relationships. Routes on the network segments where the loopback
interface IP addresses reside are also advertised to area 0.
When there are more than 100 switches in a network area where routes need to
be deployed on the underlay network, multi-area orchestration is recommended.
● The core switch is planned in area 0. Each downlink VLANIF interface on the
core switch, as well as the aggregation and access switches connected to
these VLANIF interfaces are planned in the same area.
through OSPF. The interconnected Layer 2 interfaces are added to the
corresponding VLANs in trunk mode.

● On the core switch that functions as a border node, routes on the network
segment where its loopback interface IP address resides are advertised to area
0. On an edge node, routes on the network segment where its loopback
interface IP address resides are advertised to the area to which the edge node
belongs.
● If a Layer 2 switch is required for interconnection between the border and
edge nodes and performs transparent transmission between them, this Layer
2 switch cannot be the aggregation switch. (When adding a switch to a site
on iMaster NCE-Campus, you can set the switch role.) You can select Core or
Regional aggregation as the switch role. After the automatic OSPF route
orchestration function is enabled, interfaces connecting this Layer 2 switch to
the border and edge nodes allow packets from the corresponding VLAN to
pass through.
2.3.3.4 Loop Prevention Design for the Underlay Network

physical architecture of the underlay network is a loop-free tree topology with the
core switch being the root bridge. However, network loops, such as those caused
by incorrect cable connections, still exist on the live network. Network loops lead
to broadcast storms and instability of MAC address tables. As a result,
communication on the network may deteriorate or even be interrupted.
Switches employ multiple protocols, such as rapid spanning tree protocol (RSTP),
multiple spanning tree protocol (MSTP), and VLAN-based spanning tree (VBST), to
detect loops on the network and block certain interfaces to trim the ring topology
into a loop-free tree topology. Furthermore, if an active link fails and a redundant
link exists, RSTP, MSTP, or VBST activates the redundant link to ensure network
connectivity.
underlay network is large in scale. Therefore, when deploying loop prevention
protocols such as RSTP, MSTP, and VBST, you need to consider the convergence
time and impact scope so as to perform loop prevention design accordingly.
Design Guidelines
In the virtualization solution for large- and medium-sized campus networks, to
reduce the impact of topology changes on the entire network, you are advised to:
● Select a device with higher reliability as the root bridge.
● Divide the entire underlay network into multiple loop detection domains.
Figure 2-104 shows the underlay network in a virtualization scenario on a large
or midsize campus. When no loop exists between core and aggregation switches,
the loop prevention design can be implemented as follows:

Figure 2-104 Loop prevention design on an underlay network
1. Disable the loop prevention function, such as STP, on the interconnection

interfaces between core and aggregation switches.
2. To minimize the impact of topology changes, add core switches to a single
loop detection domain, and add each aggregation switch and its connected
access switches to multiple loop detection domains.
3. Configure the core and aggregation switches as the root bridges of their
respective loop detection domains to reduce the probability of root bridge re-
election.
NOTE
● When a loop exists between core and aggregation switches, do not disable the loop
prevention function between them. You can only configure the core switch as a root
bridge to improve root bridge robustness.
● Currently, the controller allows you to increase the priority of core or aggregation
switches so that they can be preferentially selected as root bridges.
● To perform VLAN-based loop prevention design for inter-VLAN load balancing, see the
MSTP or VBST design in the switch product documentation.
2.3.4 Overlay Network Design
2.3.4.1 Overlay Network Overview

An overlay network consists of the fabric and multiple virtual networks (VNs). A
fabric is a network on which all resources are pooled. These resources can be
selected as required during VN creation, decoupling the overlay network from the
underlay network. Creating a VN is equivalent to creating an instance on the
fabric. One VN instance can represent a virtual network dedicated to one type of
service.
For details about concepts related to the overlay network, see 2.3.1.2.3 Overlay
Network Architecture Design.

2.3.4.2 Overlay Network Resource Planning

VLAN/BD resources of the overlay network are planned in the fabric global
resource pool. Table 2-56 lists the resource items to be planned. For details about
VLAN/BD planning, see "VLAN/BD Planning" in 2.3.1.3 Network Resource
Planning.
Table 2-56 VLAN/BD resource plan for the fabric global resource pool
Reso Description
urce
Item
BD ● Layer 2 broadcast domains are isolated in a VN. Generally, one-to-

one mapping is configured between BDs and user service VLANs.
● The planned BD resource pool needs to accommodate the number of
user service VLANs. By default, the value ranges from 1 to 4095.
Servi ● User terminals access the campus network through service VLANs,
ce which are bound to BDs.
VLA ● You are advised to assign service VLANs based on logical areas,
N organizational structures, and service types of campus networks.
Inter ● When creating external network resources on a fabric, configure

conn interconnection VLANs to interconnect with an egress network.
ectio ● When creating network service resources on a fabric, configure
n interconnection VLANs to interconnect with a network management
VLA zone.
N

Only IP addresses of loopback interfaces need to be planned in the fabric global
resource pool. Other IP addresses on an overlay network do not need to be
planned. Table 2-57 lists the IP address resource items to be planned for an
overlay network. For details about IP address planning, see "IP Address Planning"
in 2.3.1.3 Network Resource Planning.
Table 2-57 IP address plan for the fabric global resource pool
Item
Loopback Configure loopback interface IP addresses to establish BGP EVPN

interface peer relationships between border and edge nodes, which also
IP address function as the VXLAN tunnel endpoints (VTEPs).

Item
Service IP ● Configure IP addresses of servers, service terminals, and

address gateways.
● You are advised to use the same last digits as the gateway
address. For example, gateways use IP addresses suffixed by .
254.
● The IP address range of each service must be clearly
distinguished. The IP addresses of each type of service terminals
must be contiguous and can be summarized.
● Considering the scope of a broadcast domain and easy planning,
it is recommended that an address segment with a 24-bit mask
be reserved for each service. If the number of service terminals
exceeds 200, an extra address segment with a 24-bit mask is
assigned.
Interconn ● When creating external network resources on a fabric, configure

ection IP interconnection IP addresses to interconnect with an egress
address network.
● When creating network service resources on a fabric, configure
interconnection IP addresses to interconnect with a network
management zone.
2.3.4.3 Fabric Network Design
2.3.4.3.1 Fabric Role Design

As demonstrated in Figure 2-105, in the distributed gateway solution where
VXLAN is deployed across core and aggregation layers, it is recommended that the
core switch be used as the border node, the aggregation switch as the edge node,
and the access switch as the fabric extended node. Policy association can be
deployed between edge and fabric extended nodes to implement access control of
user terminals on access switches.

Border and edge nodes also function as VTEPs. You are advised to configure the
route reflector (RR) function on the nodes to establish BGP EVPN peer
relationships. If no RR is configured, BGP peer relationships need to be established
between edge nodes, and between edge and border nodes. The configuration is
complex and many BGP connections consume CPU resources. Border and edge
nodes can function as RRs. The border node used as the RR has the strongest
processing capability, so it is recommended that border nodes be used as RRs.
2.3.4.3.2 External Network Design

In the resource model design for the fabric network, external networks are created
on the border node so that terminals on the campus network can access the
Internet. For each external network resource created on the border node, a VRF
instance is allocated. After an external network resource is selected during VN
creation, the VRF instances of the created VN and external network resource
import routes from each other. In this way, service subnets in the VN can
communicate with the external network, as shown in Figure 2-106.
Figure 2-106 External network resource model design for a fabric

Egress Types of External Networks

Three types of external network resources are defined: L3 shared egress, L3
exclusive egress, and L2 shared egress. If the user gateway is located in the fabric,
the L3 shared egress or L3 exclusive egress is used, as shown in Figure 2-107.
● L3 shared egress: Multiple VNs on the fabric network share an L3 egress to
communicate with the egress device. To enable communication between VNs
and external networks, you must configure return routes to service subnets on
the firewall. As a result, service subnets of different VNs can communicate
with each other on the firewall. To isolate different VNs on the firewall,
configure policies based on service network segments in the VNs.
The L3 shared egress helps save VLAN and IP resources for interconnection
and applies to scenarios where there are low requirements on security control
policies between VNs.
● L3 exclusive egress: Each VN on the fabric network exclusively uses an L3
egress to communicate with the egress device. In this case, multiple security
zones are configured on the firewall, each corresponding to one L3 exclusive
egress. Thus, the traffic between service subnets of different VNs is isolated
when reaching the firewall. To enable inter-VN communication through the
firewall, you can configure security policies between security zones.
Configuring security policies can also control the application ports used for
communication and limit the bandwidth.
The L3 exclusive egress applies to scenarios where there are high
requirements on security control policies between VNs.
Figure 2-107 Traffic models for L3 shared egress and L3 exclusive egress on a
fabric
Route Planning for External Networks

When interconnecting VNs with external networks, pay attention to the following
points: On the border node, the VRF instances of VNs communication with those
of external network resources through static routes. The border node and firewall

communicate with each other through routing protocols. In Figure 2-108, routes
between the border node and firewall are configured based on the route design
principles for communication between campus intranets and external networks.
● Routes from the campus intranet to external networks on the border node:
Generally, default routes are used to prevent a huge number of external
network routes from affecting intranets.
● Configure routes from external networks to the campus intranet on the
firewall: Generally, specific routes are used.
Figure 2-108 Route planning between the border node and firewall
When creating external network resources on the border node, you can use any of
the following routing protocols to interconnect the border node with the firewall.
According to the route design principles described above, Table 2-58 lists the
recommended configurations for the three routing protocols.

Table 2-58 Configurations of different routing protocols between the border node
and firewall
Border Node
Stat 1. On the border 1. On the

ic node, manually firewall,
rout configure a manually
ing default route configure
whose next hop specific routes
is the IP address of service
of an interface subnets whose
on the firewall. next hop is the
IP address of
an interface on
the border
node. Route
summarization
can be used to
reduce the
number of
routes to be
configured.
OSP 1. On the firewall, 1. On the border

F configure a node, VN1-
common area in Outer imports
the OSPF specific routes
process to of service
advertise subnets from
default routes. VN1 through
Active default BGP.
routes must 2. On the border
exist in the local node, the
routing table of OSPF process
the firewall. in VN1-Outer
2. On the border imports BGP
node, the OSPF routes.
process of VN1- 3. On the
Outer learns the firewall, the
advertised OSPF process
default routes learns the
through LSA imported
updates. specific routes
of service
subnets
through LSA
updates.


Border Node
BGP 1. On the firewall, 1. On the border

configure the node, VN1-
BGP process to Outer imports
import default specific routes
routes or of service
advertise such subnets from
routes using the VN1 through
network BGP.
command. 2. The firewall
Active default learns the
routes must imported
exist in the local specific routes
routing table of of service
the firewall. subnets
2. On the border through BGP.
node, VN1-
Outer learns the
default routes
through BGP.
When selecting a routing protocol between the firewall and border node, you
need to consider how to switch the service traffic path in active/standby
switchover scenarios when firewalls are deployed in HSB mode. For details, see the
egress route design in 2.3.6 Egress Network Design.
NOTE
You can configure routes on the border node when creating external network resources on
iMaster NCE-Campus, and configure routes on the firewall by logging in to the web system
or CLI.
2.3.4.3.3 Network Service Resource Design

In the resource model design for the fabric, network service resources are created
on the border node so that service terminals on the campus network can access
service resources in the network management zone, such as the DHCP server and
NAC server. Three network service resource design models are available based on
the resource deployment locations on a fabric network.

Directly Connecting to Servers
directly connected to servers)
As shown in Figure 2-109, for each network service resource created on the
border node, a VRF instance is allocated. After a network service resource is
selected during VN creation, the VRF instances of the created VN and network
service resource import routes from each other. In this way, service subnets in the
VN can communicate with the network service resource. Static routes are
configured on the border node based on the addresses for accessing these
network service resources.
In this scenario, the border node is directly connected to network service resources,
and the physical interfaces that connect the border node to the resources are
added to VLANs in access mode.
Directly Connecting to a Switch
directly connected to a switch)
As shown in Figure 2-110, for each network service resource created on the
border node, a VRF instance is allocated. After a network service resource is
selected during VN creation, the VRF instances of the created VN and network
service resource import routes from each other. In this way, service subnets in the
VN can communicate with the network service resource. Static routes are
configured on the border node based on the addresses for accessing these
network service resources.

In this scenario, the border node is connected to network service resources

through a switch, and the physical interfaces that connect the border node to the
resources are added to VLANs in trunk mode.
This design model is typically used if a DHCP server, iMaster NCE-Campus, and
other network service resources are deployed in the network management zone.
The border node is directly connected to the gateway switch in the network
management zone and then communicates with network service resources
through the switch. If only a small number of network service resources are
deployed, it is recommended that these resources be planned in the same network
service resource model. This saves interconnection VLAN and IP address resources
and simplifies route configuration for the network management zone, as shown in
Figure 2-111.
Figure 2-111 Traffic model for communication between a VN and network service
resources
NOTE
Routes on the border node are automatically delivered when network service resources are
created on iMaster NCE-Campus. To configure routes on the gateway in the network
management zone, log in to the web system or CLI of the device.
Deploying Network Service Resources on an External Network
Figure 2-112 Design model of network service resources on a fabric (servers

deployed on an external network)
This design model is selected only when a DHCP server is deployed on an external
network, as shown in Figure 2-112. In this scenario, the VN and DHCP server
communicate with each other based on an external network design model of the
fabric. This network service resource model is mainly used for obtaining the DHCP
server address. When this model is used, the gateway of the VN subnet can

function as the DHCP relay agent and automatically configure the DHCP server
address after the gateway is created.
NOTE
Currently, this model is not supported by DHCPv6 servers.
2.3.4.3.4 Access Management Design

When creating a fabric network, you need to plan authentication control points,
including access point resource pools, for user access. The wired access point
resource refers to switch interfaces connected by terminals, and the wireless
access point resource refers to SSIDs connected by terminals. In the distributed
gateway solution, if the fabric network adopts the recommended networking of
VXLAN deployed across core and aggregation layers and the border node serves as
the native WAC on the WLAN, then:
● You are advised to deploy the authentication control points for wired user
access on edge nodes and plan them on the Access Management tab page
of a fabric.
WAC. The design and planning of the authentication control point depend on
the WAC type. For details, see "WLAN Admission Design" in 2.3.5 WLAN
Design.
Access Interface Design

During access management configuration for a fabric network, three connection
types are defined for access interfaces on switches, as shown in Figure 2-113.
● Fabric extended AP: allows Huawei Fit APs to access. This type is used when
configuring policy association.
● Fabric extended switch: allows Huawei switches to access. This type is used
when configuring policy association.
● Terminal (PCs, phones, dumb terminals, and non-fabric extended access
switches or APs): allows terminals or switches/APs (when policy association is
not deployed) to access. If terminals are connected, bind authentication
profiles to terminals based on terminal types to control terminal access. For
details, see User Authentication Mode Selection.

Figure 2-113 Connection types of fabric access interfaces
NOTE
In the distributed gateway scenario, it is recommended that the border node with the
native WAC function be deployed, or standalone WACs be connected to the border node in
off-path mode. In this scenario, do not select Extended AP for interfaces connecting access
switches to APs. If this connection type is selected, the APs cannot communicate with the
border node through management VLAN auto-negotiation. You don't need to configure the
connection type for the interfaces connecting access switches to APs.
RU Access Design
In the simplified all-optical campus solution, central switches and RUs are
launched as combinations. The following figure shows the networking and
connection types of fabric access interfaces.
Figure 2-114 RU networking and connection types of fabric access interfaces
RUs do not support VLAN configuration or policy association and are used only as
the remote ports of a central switch. In addition, RUs (without management IP
addresses) are managed by the central switch in a unified manner and are not
displayed as independent NEs on iMaster NCE-Campus. Therefore, during fabric
access network design, you only need to configure port isolation for RUs through

the central switch on iMaster NCE-Campus when deploying policy control (see
Policy Control Solution Design).
An RU provides multiple extension interfaces that can connect to terminals or APs.
During access authentication configuration, it is recommended that authentication
be configured on the interfaces connecting to terminals and non-authentication
be configured on the interfaces connecting to APs. In this case, the authentication
policies for the two access types are different. Therefore, it is not recommended
that an RU be connected to APs and terminals at the same time. When an RU is
connected to both terminals and APs, terminal authentication needs be enabled
on the corresponding interface on the central switch, and APs need to be
authenticated on the central switch to access the network.
NOTE
1. Port isolation for RUs cannot be configured based on unified fabric orchestration and
needs to be configured site by site.
2. RUs must be deployed together with and directly connected to a central switch.
Policy Association Design

Policy association moves the authentication control point up towards the
aggregation or core layer. In this manner, devices at the aggregation or core layer
can implement policy association with devices at the access layer through
CAPWAP tunnels. This helps reduce the number of authentication control points
configured and allows terminal access control at the access layer. In the scenario
where wired and wireless users share the authentication control point, APs can
also join the WAC functioning as the wireless authentication control point over the
CAPWAP tunnel established through policy association.
In the distributed gateway solution, VXLAN is recommended to be deployed across
core and aggregation layers. In such scenario, you are advised to plan the policy
association function in the access management design for the fabric network. As
shown in Figure 2-115, policy association is deployed between the aggregation
switches (edge nodes) and access switches.
Figure 2-115 Planning policy association in fabric access management design

Perform the following operations when configuring policy association during

access management configuration for the fabric network:
● On the edge node, configure the management VLAN and management IP
address for policy association.
● On the edge node, set the connection type of the port connected to an access
switch to "fabric extended switch". This connection type can enable the
management VLAN for policy association between the edge node and access
switch.
● On the access switch, set the connection type of the port connected to an AP
to "fabric extended AP". This connection type can enable the management
VLAN for policy association between the access switch and AP.
After the configuration is complete, a CAPWAP tunnel can be established between
the edge node and access switch. Wired user access authentication is still
performed on the edge node, but wired authentication enforcement points are
moved downwards to the access layer (access switches). Wired users can access
the network through the access switches only after passing authentication.
2.3.4.4 VN Design
2.3.4.4.1 VN Division Principles

In the virtualization solution for a large or midsize campus network, each VN is a
VPN instance, and one VN can contain multiple subnets. By default, users in the
same VN can communicate with each other at Layer 3, and users in different VNs
are isolated from each other. VNs can be planned based on the following
principles:
● Allocate an independent service department or service network to a VN. For
example, on a campus network, services such as guest, teaching, IoT, and
video surveillance services, each is allocated to an independent VN.
● VNs are not used to fulfill the requirements for isolating users of different
levels in the same service department or service network. Instead, access
policies can be implemented to achieve this.
2.3.4.4.2 VN Access Design
VN Access of User Subnets

As demonstrated in Figure 2-116, in the distributed gateway solution, the fabric
typically adopts the recommended networking of VXLAN deployed across core and
aggregation layers, and the border node functions as the native WAC. In such
scenarios, wireless user traffic (CAPWAP packets) is decapsulated after reaching
the border node. That is, wired user traffic and wireless user traffic enter a VN
through edge nodes and the border node, respectively, and are forwarded in the
corresponding VN based on the BD associated with the user VLAN.

Figure 2-116 VN access of user subnets in the distributed gateway solution
User VLAN Access Modes

VLAN access modes for users include the static VLAN mode and dynamically
authorized VLAN mode. You need to select a mode when configuring a user
gateway in a VN. Table 2-59 lists the two access modes.
Table 2-59 Comparison between the static VLAN mode and dynamically
authorized VLAN mode
Access
Mode
Static ● Wired access: Configure a The static VLAN mode applies when
VLAN static VLAN on the switch terminals access the VLAN at fixed
interface connected to locations and do not need to be
wired user terminals. authenticated. This access mode is
● Wireless access: Configure more secure but lacks flexibility.
a static service VLAN for When the locations of terminals
an SSID. change, you need to perform the
configuration again.


Access
Mode
Dynami ● Wired access: After a user The dynamically authorized VLAN

cally is authenticated mode applies when terminals access
authoriz successfully, the the VLAN anywhere and need to be
ed authorization result, authenticated based on the VLAN
VLAN including authorized VLAN information delivered during user
information, is delivered to authentication. This access mode is
the corresponding access flexible and the configuration does
interface. not need to be changed when the
● Wireless access: After a locations of terminals change.
user is authenticated
successfully, the
authorization result,
including authorized VLAN
information, is delivered to
the corresponding SSID.
● If a downlink interface is connected to an IP phone, you can configure a voice

VLAN on the interface for the IP phone.
● The dynamically authorized VLAN mode applies to MAC address
authentication and 802.1X authentication. The dynamically authorized VLAN
mode requires users to go online again during Portal authentication, so this
mode is not recommended in Portal authentication.
● The dynamically authorized VLAN mode can be implemented based on VLAN
pools. In this mode, the authentication control point automatically calculates
and allocates a VLAN in the VLAN pool to the access interface or SSID based
on authorized VLAN pool information. Subnets of VLANs in a VLAN pool are
connected to the same VN.
The VLAN pool-based authorization mode applies to scenarios where there
are a large number of user subnets. In the distributed gateway solution, edge
nodes are not isolated at Layer 2, and therefore, this mode is recommended.
However, uneven assignment may occur when users are assigned to VLANs in
a VLAN pool. If this is the case, certain VLANs are assigned a large number of
users, and thus some users in these VLANs may fail to obtain IP addresses due
to insufficient IP addresses planned for the VLAN pool. You are advised to
enable DHCP snooping and VLAN re-allocation when configuring the VLAN
pool. If IP addresses fail to be assigned to users due to insufficient IP address
resources in a VLAN, the users are re-authorized to another VLAN.
2.3.4.4.3 VN User Gateway Design

In the distributed gateway solution, the user gateway for the VN sits on the edge
node. You can use the following methods to perform the VN configuration on
iMaster NCE-Campus:
● Automatic allocation: After the number of user subnets and start VLAN and IP
address of the subnet are specified, the user subnet gateway is automatically

configured. This mode applies to scenarios where a large number of subnets

are deployed and automatic gateway configuration is required.
● Manual configuration: Manually configure the user access VLAN and the IP
address of the gateway interface. This mode applies to scenarios where a few
subnets are deployed and automatic gateway configuration is not required.
You are advised to perform the following configurations on iMaster NCE-Campus:
● Deploy an independent DHCP server to dynamically allocate IP addresses to
user terminals. Generally, the DHCP server and user terminals are on different
network segments. It is recommended that the DHCP relay function be
enabled on the user gateway.
● You are advised to enable DHCP snooping in the corresponding BD of the user
gateway to ensure that user terminals obtain IP addresses from authorized
DHCP servers and prevent attacks. In addition, if DHCP options are used to
obtain terminal information for terminal identification, DHCP snooping also
needs to be configured.
● If the multicast DNS (mDNS) mode is used for terminal identification, mDNS
snooping should be enabled in the corresponding BD of the user gateway.
2.3.4.4.4 VN Communication Design
Intra-VN Subnet Communication
Communication Within a Subnet in a VN

Users on the same subnet in a VN communicate with each other at Layer 2, as
Figure 2-117 Traffic model for communication between users on the same subnet
in a VN
● Users on the same subnet connected to the same edge node can directly

entry of Host 2. The entry belongs to VLAN 10 and is learned from
GE0/0/2. Edge 1 then forwards the packet.
● Users on the same subnet connected to different edge nodes
nodes.
entry of Host 2. The entry belongs to BD 10 and is learned from the
tunnel source interface (displayed as the IP address) of Edge 2. Edge 1
then encapsulates the packet into a VXLAN packet.
route.
d. After the packet arrives at Edge 2, Edge 2 performs VXLAN decapsulation,
searches for the MAC address entry of Host 2, determines the outbound
interface GE0/0/1, and forwards the packet.
Communication Between Subnets in a VN

In a VN, traffic between subnets needs to be forwarded by the gateway, as shown
in Figure 2-118.
Figure 2-118 Traffic model for communication between users on different subnets
in a VN

● Users on different subnets connected to the same edge node can directly
b. After the packet arrives at Edge 1, Edge 1 searches the VN 1 routing table
for the direct route to Host 2 and then forwards the packet based on the
ARP entry.
● Users on different subnets connected to different edge nodes
nodes.
b. After the packet arrives at Edge 1, Edge 1 searches for the route to Host
2 in the VN 1 routing table. The next hop is the IP address of the tunnel
source interface of Edge 2. Edge 1 then encapsulates the packet into a
route.
d. After the packet arrives at Edge 2, Edge 2 performs VXLAN decapsulation
Inter-VN Subnet Communication

In the virtualization solution for a large or midsize campus network, VNs are
isolated by VPNs at Layer 3. By default, VNs cannot communicate with each other.
Subnets in different VNs can communicate with each other through a border node
or firewall. Table 2-60 lists the application scenarios of the two communication
modes.
Table 2-60 VN communication modes and application scenarios

ion Mode
Communicati Communication between VNs does not require advanced

on through a security policy control by the firewall. In this case, implement
border node policy control based on the free mobility solution, and import
the network segment routes that can be reachable between
devices added to the VNs on the border node.


ion Mode
Communicati Communication between VNs requires advanced security policy

on through a control by the firewall.
firewall
Subnet Communication Between VNs Through a Border Node

To implement communication between VNs through a border node, import the
network segment routes that can be reachable between devices added to the VNs
on the border node. After mutual access traffic arrives at the border node, the
border node forwards the traffic between VNs based on the imported routes, as
border node

b. After the packet reaches Edge 1, Edge 1 searches the VN 1 routing table
for the route to the network segment of Host 2. Because routes have
been imported between the VPN routing tables of VN 1 and VN 2 on the
border node, Edge 1 can learn the VPN route of VN 2 imported by the
border node from its BGP peer. Then, Edge 1 finds that the next hop is
the IP address of the tunnel source interface of the border node and
encapsulates the packet into a VXLAN packet.

underlay route.
VN 1 and VN 2 import routes from each other, the route to the network
segment of Host 2 can be found in the VN 1 routing table. The next hop
of the packet is the IP address of the tunnel source interface of Edge 1.
The border node then encapsulates the packet into a VXLAN packet. The
inner destination MAC address of the packet is the MAC address of VBDIF
20 on Edge 1.
underlay route.
f. After the packet reaches Edge 1, Edge 1 decapsulates the packet by
removing its VXLAN header and searches the VN 2 routing table for the
direct route to the network segment of Host 2. Then Edge 1 directly
forwards the packet out.
been imported between the VPN routing tables of VN 1 and VN 2 on the
border node, Edge 1 can learn the VPN route of VN 2 imported by the
border node from its BGP peer. Then, Edge 1 finds that the next hop is
the IP address of the tunnel source interface of the border node and
encapsulates the packet into a VXLAN packet.
underlay route.
VN 1 and VN 2 import routes from each other, the route to the network
segment of Host 2 can be found in the VN 1 routing table. The next hop
of the packet is the IP address of the tunnel source interface of Edge 2.
The border node then encapsulates the packet into a VXLAN packet. The
inner destination MAC address of the packet is the MAC address of VBDIF
20 on Edge 2.

underlay route.
f. After the packet reaches Edge 2, Edge 2 decapsulates the packet by
Subnet Communication Between VNs Through a Firewall

To implement communication between VNs through a firewall, configure mutual
access control policies between security zones of the firewall. After mutual access
traffic arrives at the firewall, the firewall forwards the traffic between VNs based
on the mutual access policies, as shown in Figure 2-120.
firewall

been imported between the VPN routing tables of VN 1 and the external
network resource model VN1-Outer on the border node, Edge 1 can learn
the VPN route of VN1-Outer imported by the border node from its BGP
peer. Then, Edge 1 finds that the next hop is the IP address of the tunnel

source interface of the border node and encapsulates the packet into a
VXLAN packet.
underlay route.
the route to Host 2 in the VN 2 routing table. The next hop of the packet
is the IP address of the tunnel source interface of Edge 1. The border
node then encapsulates the packet into a VXLAN packet. The inner
destination MAC address of the packet is the MAC address of VBDIF 20
on Edge 1.
underlay route.
h. After the packet reaches Edge 1, Edge 1 decapsulates the packet by
been imported between the VPN routing tables of VN 1 and the external
network resource model VN1-Outer on the border node, Edge 1 can learn
the VPN route of VN1-Outer imported by the border node from its BGP

peer. Then, Edge 1 finds that the next hop is the IP address of the tunnel
VXLAN packet.
underlay route.
the route to Host 2 in the VN 2 routing table. The next hop of the packet
is the IP address of the tunnel source interface of Edge 2. The border
node then encapsulates the packet into a VXLAN packet. The inner
destination MAC address of the packet is the MAC address of VBDIF 20
on Edge 2.
underlay route.
h. After the packet reaches Edge 2, Edge 2 decapsulates the packet by
Communication Between VNs and External Networks

In the virtualization solution for a large or midsize campus network, two resource
models are designed for the fabric network: external network resources and
network service resources. For each resource created, a VRF instance is allocated.
During VN creation and resource selection, VNs and external network resources
(or network service resources) automatically import routes from each other to
enable mutual access, as shown in Figure 2-121.

Figure 2-121 Traffic model for communication between VNs and external
networks
● Users in a VN access the Internet through the VXLAN tunnel between the
edge node and border node. Traffic is sent to the border node first, then
forwarded to the firewall based on the imported routes of external networks.
The firewall then forwards the packet to the Internet.
a. Host 1 and the Internet are on different subnets. When Host 1 accesses
the Internet, the packet is sent to the gateway first. The destination MAC
address of the packet is the MAC address of VBDIF 10 on the gateway.
for the route to the Internet. Because routes have been imported
between the VPN routing tables of VN 1 and the external network
resource model VN1-Outer on the border node, Edge 1 can learn the VPN
route of VN1-Outer imported by the border node from its BGP peer.
Then, Edge 1 finds that the next hop is the IP address of the tunnel
VXLAN packet.
underlay route.
VXLAN decapsulation and searches for the route to the Internet in the VN

1 routing table. Because the VPN routing tables of VN 1 and the external
network resource model VN1-Outer import routes from each other, the
route to the Internet can be found in the VN 1 routing table. The next
hop of the packet is the IP address of GE1/0/1.1 on the firewall. The
destination MAC address of the packet is the MAC address of GE1/0/1.1,
the Internet based on the mutual access policies and searches for the
route to Internet. The firewall then forwards the packet.
● Users in a VN access network service resources through the VXLAN tunnel
between the edge node and border node. Traffic is sent to the border node
first, then forwarded to the gateway in the network management zone based
on the imported routes of the network management zone. The gateway in
the network management zone then forwards the packet to the network
management zone.
a. Host 1 and the network service resource are on different subnets. When
Host 1 accesses the network service resource, the packet is sent to the
gateway first. The destination MAC address of the packet is the MAC
address of VBDIF 10 on the gateway.
for the route to the Internet. Because routes have been imported
between the VPN routing tables of VN 1 and the external network
resource model VN1-Server on the border node, Edge 1 can learn the
VPN route of VN1-Server imported by the border node from its BGP peer.
Then, Edge 1 finds that the next hop is the IP address of the tunnel
VXLAN packet.
underlay route.
VXLAN decapsulation and searches for the route to the network service
resource in the VN 1 routing table. Because the VPN routing tables of VN
1 and the network service resource model VN1-Server import routes from
each other, the route to the network service resource can be found in the
VN 1 routing table. The next hop of the packet is the IP address of
VLANIF 11 on the gateway in the network management zone. The
destination MAC address of the packet is the MAC address of VLANIF 11,
e. After the packet arrives at the gateway in the network management
zone, the gateway searches for the route to the network service resource
and forwards the packet.
2.3.4.5 Multicast Overlay Service Design

When IP multicast services such as live streaming, video conferencing, and online
gaming are present on a campus network, multicast data sent by these multicast
sources can reach multicast receivers only after being transmitted through a
VXLAN overlay network. Generally, multicast receivers are located inside a fabric,

whereas multicast sources are located inside or outside a fabric, as shown in

Figure 2-122.
Figure 2-122 Multicast source location
The following table describes related design considerations according to the

location of a multicast source.

Multica Multicast Overlay Solution Description

st
Source
Locatio
n
Outside ● Create a multicast subnet based on the subnet ● If IGMP is not

a fabric of multicast receivers and add the interface enabled on
connecting the border node to the multicast the external
source to the multicast subnet. (The controller multicast
automatically generates IGMP snooping router, you
configurations based on the multicast subnet need to
and delivers the configurations to network specify a
devices.) static router
● Typically, IGMP is enabled on an external port on the
multicast router. Therefore, you do not need to border node
specify an IGMP querier inside the fabric. and configure
the border
● To prevent unknown multicast traffic from node as an
being broadcast in the subnet, which wastes IGMP
bandwidth, it is recommended that the snooping
function of dropping unknown multicast querier.
packets be enabled in the IGMP snooping
profile.
● Wireless multicast traffic optimization: When
an AP sends multicast packets to a multicast
receiver, multicast-to-unicast conversion can be
experience.
● In dual-border networking, the two border
nodes and the egress zone can be
interconnected in dual-homed (recommended),
single-homed, or triangle networking mode. In
dual-homed and triangle networking, dual-link
active/standby backup needs to be deployed
on egress network devices. This is to prevent
multicast traffic from entering the same BD
from the two border nodes and being
transmitted in two copies on the overlay
network. The dual-link reliability technologies
include Smart Link, Ethernet Ring Protection
Switching (ERPS), and Smart Ethernet
Protection (SEP), and can be selected based on
the capabilities of the egress network devices.
You are advised to use Smart Link to configure
two links in active/standby mode. If ERPS is
used, the port on one link needs to be specified
as the RPL owner port. If SEP is used, the


st
Source
Locatio
n
interfaces connected to the border nodes need

to be specified as no-neighbor primary and
secondary edge interfaces.


st
Source
Locatio
n
Inside a ● Create a multicast subnet based on the subnet ● The multicast

fabric of multicast receivers and add the interface source can
connecting the device inside the fabric to the connect to
multicast source to the multicast subnet. (The the fabric
controller automatically generates IGMP through
snooping configurations based on the border nodes,
multicast subnet and delivers the edge nodes,
configurations to network devices.) or extended
● Configure the device nearest to the multicast nodes, with
source as an IGMP snooping querier. the same
multicast
● To prevent unknown multicast traffic from overlay
being broadcast in the subnet, which wastes solution.
bandwidth, it is recommended that the
function of dropping unknown multicast
packets be enabled in the IGMP snooping
profile.
● Wireless multicast traffic optimization: When
an AP sends multicast packets to a multicast
receiver, multicast-to-unicast conversion can be
experience.
● In dual-border networking, when a multicast
source accesses the fabric through the border
nodes, dual-link active/standby backup needs
to be deployed on the intermediate network
devices. This is to prevent multicast traffic from
entering the same BD from the two border
nodes and being transmitted in two copies on
the overlay network. The dual-link reliability
technologies include Smart Link, ERPS, and
SEP, and can be selected based on the
capabilities of the intermediate network
devices. You are advised to use Smart Link to
configure two links in active/standby mode. If
ERPS is used, the port on one link needs to be
specified as the RPL owner port. If SEP is used,
the interfaces connected to the border nodes
need to be specified as no-neighbor primary
and secondary edge interfaces.

NOTE
Currently, the overlay network supports only Layer 2 multicast. If Layer 3 multicast is
required, you are advised to deploy multicast services on the underlay network.
For switches running V600R022C00 or later versions, Layer 2 multicast cannot be deployed
using dynamically authorized VLANs.
In dual-border networking, PIM priority needs to be configured to ensure the DR and IGMP
querier are the same device. Otherwise, a large number of multicast packets are lost when
a link switchover occurs.
2.3.5 WLAN Design
2.3.5.1 Suggestions on WLAN Planning

A WLAN transmits data through high-frequency electromagnetic waves over the
air interface. As the transmission distance increases, the strength of radio signals
becomes weaker, resulting in poor service experience of STAs at the edge of radio
signal coverage. In addition, all wireless devices share air interface resources. As a
result, if the working channels of neighboring wireless devices are adjacent or the
same, co-channel or adjacent-channel interference exists. The interference
problems deteriorate the WLAN signal quality and even cause a WLAN to be
unavailable. To improve the WLAN quality and meet customers' requirements on
network construction, WLAN planning design is required. Proper WLAN planning
helps reduce the probability of WLAN signal coverage holes and signal
interference. In addition, to meet the bandwidth requirements of each STA and
provide better WLAN experience, select appropriate AP types and properly plan
the number of STAs connected to APs. If WLAN planning design is not performed
in the early stage, rework may be required after APs are installed. This is because
network optimization after APs are installed may require AP reinstallation and re-
cabling.
2.3.5.1.1 WLAN Engineering and Planning Design

Before WLAN planning design, determine the deployment scenarios, such as
enterprise offices, education, stadiums, hotels, and shopping malls/supermarkets.
In such scenarios, service requirements vary, and different device models, network
coverage, and network capacity are needed. Therefore, perform WLAN planning
design as required. For details about the scenarios and corresponding design
solutions, see the WLAN Engineering and Planning Design Guide.
2.3.5.1.2 AP Power Supply and Cabling Design

AP power supply modes include:
● Power supply by PoE devices (recommended)

The PoE switch transmits data and supplies power to APs, and serves as the
main power supply for APs. If the distance between an AP and a switch is
shorter than 80 m, you are advised to use a common PoE switch for power
supply. If the distance between an AP and a switch is longer than 80 m but
shorter than 300 m, you are advised to use a hybrid optical-electrical switch
to supply power to the AP (APs connected to a switch using hybrid cables are
supported).

● Local power supply

An independent power supply is used to supply power to APs. In most cases, a
local AC power supply can be used to supply power to APs if an upstream
switch does not support PoE power supply.
● Power supply by PoE adapters
Typically, outdoor APs use optical fibers for data transmission and support
only PoE power supply. In this case, PoE adapters are used to supply power to
APs. In outdoor scenarios, PoE adapters must be installed in an equipment
container or cabinet to meet the operating temperature, waterproof, and
surge protection requirements.
Figure 2-123 AP power supply modes
During AP cabling design, pay attention to the following points:

● During AP deployment, reserve around 5 m network cable for adjusting AP
installation positions due to interference or poor signal coverage in the future.
● Keep network cables far away from strong electromagnetic interference.
● Confirm with customers about the cabling design in advance to prevent
customers from disallowing construction for the property or appearance
reason.
NOTE
Wi-Fi 6 APs need to be powered by PoE++ switches. Therefore, select appropriate access
switches for power supply based on AP models.

On a large or midsize campus network, the WLAN typically adopts the "WAC + Fit
AP" architecture. Under this architecture, APs work in Fit mode and are centrally
managed by the WAC. As shown in Figure 2-124, in the virtualization solution,
you are advised to use the border node that comes with the native WAC
functionality. In campus network reconstruction scenarios where an existing
standalone WAC needs to be used, you are advised to connect the WAC to the
border node in off-path mode.

Figure 2-124 WLAN architecture in the virtualization solution
Control packets between the WAC and APs are forwarded through a CAPWAP
tunnel. APs forward service packets of wireless users to the wired side in tunnel
forwarding (centralized forwarding) or direct forwarding (local forwarding) mode.
Tunnel Forwarding
In tunnel forwarding mode, an AP encapsulates the service packets of wireless
users over a CAPWAP tunnel and sends them to the WAC. The WAC then forwards
these packets to other networks. Figure 2-125 shows the traffic forwarding model
adopted when the tunnel forwarding mode is used in this solution.
In tunnel forwarding mode, switches on the links between the WAC and APs do
not need to allow service VLANs, and interfaces on the switches do not need to be
added to such VLANs. This facilitates centralized control and management.
However, the disadvantage is that the service traffic of all wireless users is
centrally forwarded by the WAC, which imposes a heavy workload on the WAC.

Figure 2-125 Service traffic model of wireless users (tunnel forwarding mode)
Direct Forwarding
In direct forwarding mode, an AP directly forwards users' service packets to other
networks without encapsulating them over a CAPWAP tunnel. Figure 2-126 shows
the traffic forwarding model adopted when the direct forwarding mode is used in
this solution.
In direct forwarding mode, the east-west service traffic of local wireless users can
be directly forwarded by the local access switch without passing through the WAC.
However, switches on the links between the WAC and APs need to allow service
VLANs, and interfaces on the switches need to be added to such VLANs, making it
difficult to perform centralized control and management.

Figure 2-126 Service traffic model for wireless users (direct forwarding mode)
Table 2-61 compares the tunnel forwarding mode with the direct forwarding
mode. In the virtualization solution for a large or midsize campus network, the
tunnel forwarding mode that can provide centralized traffic management and
control is recommended, irrespective of which gateway solution is selected. The
subsequent WLAN planning following this section is also designed based on the
tunnel forwarding mode.
Table 2-61 Forwarding mode comparison

ding
Mode
Tunnel Wireless user service The WAC forwards Service traffic must
forwardi traffic is processed and service traffic in a be forwarded by the
ng forwarded by the WAC centralized manner, WAC, reducing packet
in a centralized ensuring high forwarding efficiency
manner. security and and burdening the
facilitating WAC.
centralized traffic
management and
control.


ding
Mode
Direct Service traffic of Service traffic does Service traffic cannot

forwardi wireless users is not need to be be managed and
ng directly forwarded forwarded by the controlled in a
without passing WAC, which centralized manner.
through the WAC, improves packet
saving AP-WAC link forwarding
bandwidth. efficiency and
reduces the burden
on the WAC.
2.3.5.3 AP Onboarding Design

In the "WAC + Fit AP" architecture, to enable APs to join the WAC, you need to
configure a DHCP server for the AP management network first. Thus, each AP can
automatically obtain a management IP address through DHCP, establishing a
management channel with the WAC. Then, associate APs with the WAC and
configure the CAPWAP source interface. If an AP tries to access the network, the
WAC verifies the MAC address or ESN of the AP. If the WAC finds it an authorized
AP, it establishes a CAPWAP tunnel with the AP. In this way, the AP successfully
joins the WAC.
Management IP Address Planning for APs

In the "WAC + Fit AP" architecture, to improve deployment efficiency, an AP
usually obtains an IP address in DHCP mode. After a DHCP server is configured, an
AP acts as a DHCP client to request a management IP address from the DHCP
server, and obtains the IP address of the WAC through the Option 43 field in
DHCP packets. In this solution, the border node functions as the DHCP server of
the wired and wireless management subnets to automatically assign management
IP addresses to access and aggregation switches as well as APs. The AP's first
onboarding in plug-and-play mode and management VLAN switching can be
planned by referring to the plan for switch onboarding. For details, see 2.2.3.2
Deployment Design.
Planning for AP Association with the WAC

Associating APs with the WAC is to ensure that associated APs are authorized. If
the information about an AP that connects to the network does not match that on
the associated WAC, the AP is not allowed to come online. In this solution, the
following operations for associating APs with the WAC need to be performed on
iMaster NCE-Campus:
1. First, enter the ESNs of APs when adding devices to a campus site. There are a
large number of APs on a large or midsize campus network. Therefore, you
are advised to use the network plan import function to add the ESNs of APs
to a site when importing physical link data using a template.
2. After the ESNs of APs are recorded, you can view the APs that can be
associated with the WAC on the Manage Fit AP tab of the Network

Configuration page on iMaster NCE-Campus. In the WAC list, select the row
where the WAC resides, and click Add in the lower right corner to add APs for
management by the WAC.
CAPWAP Source Interface Planning

In the virtualization solution for a large or midsize campus network that uses the
"WAC + Fit AP" architecture, APs' wireless services are centrally configured
through the web system or CLI of the WAC, including the configuration of the
CAPWAP source interface used to establish a CAPWAP tunnel between the WAC
and AP.
2.3.5.4 AP Group Design

An AP group is used to configure and manage APs in batches so that the APs
inherit the configurations of the group to which they belong.
You can create an AP group based on the following items:
● Physical location (For example, APs on the same floor can be added to the
same AP group. This mode is preferred.)
● Device model
● IP or MAC address
● Serial number (SN)
2.3.5.5 SSID and Service VLAN Design
SSID Planning
In most cases, service set identifiers (SSIDs) are planned based on user roles or
service types. For example, three SSIDs can be planned for three types of wireless
services in a large-scale business scenario, as shown in Figure 2-127. Employee is
used for wireless office access of employees. Guest is used for Internet access of
guests. Dumb is used for wireless access of dumb terminals such as printers. For
an SSID that is not intended for end users, for example, the SSID used for access
of printers, you can configure SSID hiding to prevent the SSID from being detected
by end users.
Figure 2-127 SSID planning

Wireless Service VLAN Planning

When an AP receives service data from wireless users and forwards the data to the
wired side, a wireless service VLAN needs to be planned to distinguish different
wireless service types or user groups on the wired side. On the wireless side, SSIDs
also differentiate wireless service types or user groups. Therefore, mappings
between VLANs and SSIDs must be considered during WLAN planning. Two
mapping relationships are applicable to different scenarios: 1:1 and 1:N, as
Table 2-62 Mappings between VLANs and SSIDs
SSID:VLA Usage Scenario

N
Mapping

N=1:1 B. To allow users to detect only one SSID and use the same data
forwarding control policy, plan only one SSID and one VLAN, that
is, SSID:VLAN = 1:1.

N = 1:N B. To allow users to detect only one SSID but use different data
forwarding control policies for the two hotspots. In this case, plan
one SSID and two VLANs to differentiate the hotspots, that is,
SSID:VLAN = 1:2.
On a large and midsize campus network, a large number of STAs exist and require
area-specific policies. Typically, the SSID:VLAN = 1:N mapping policy is used.
The range of a radio broadcast domain is determined by an SSID. Therefore, in

case of SSID:VLAN = 1:N, you are advised to enable broadcast-to-unicast
conversion to avoid the generation of a radio broadcast domain.
2.3.5.6 WLAN Admission Design
NAC Authentication Control Point Design

Network Access Control (NAC) solution is applicable to both wired and wireless
users. In this solution, common authentication technologies include 802.1X, MAC
address, and Portal authentication. Generally, access control is performed for wired
users based on access interfaces of switches, and for wireless users based on
SSIDs. The roadmap for selecting authentication modes for wireless users is the
same as that for wired users. That is, you need to take into account different user
roles or terminal types. For details, see "User Authentication Mode Design" in
2.2.7 Access Control Design.
On a WLAN using the "WAC + Fit AP" architecture, the WAC serves as the wireless
authentication control point. In this solution, the deployment process of the
wireless authentication control point varies according to the WAC type.
● Standalone WAC (connected to a border node in off-path mode)

In the centralized gateway solution, if a standalone WAC is connected to a

border node in off-path mode, you need to log in to the WAC's web system to
centrally perform settings on the wireless authentication control point, as
demonstrated in Figure 2-128. The following describes the configuration
process:
a. Configure authentication, authorization, and accounting (AAA) profile
resources on the WAC, including the RADIUS server template, Portal
server template, and access authentication profiles.
corresponding SSIDs on APs.

(standalone WAC connected to a border node in off-path mode)
● Native WAC (integrated with a border node)

If the border node serves as the native WAC in this solution, you can log in to
the WAC's web system to configure authentication profiles. Alternatively, you
can configure these profiles on iMaster NCE-Campus and deliver them to the
native WAC on the Site Configuration tab page, as shown in Figure 2-129.
The following describes the configuration process:
a. Create profiles on the Site Configuration tab page of iMaster NCE-
Campus and deliver them to the WAC.
corresponding SSIDs on APs. You can only log in to the web system of the
WAC to configure wireless services on APs.


(native WAC integrated with a border node)
NOTE
In this solution, access authentication is configured on the Site Configuration tab

page. If the native WAC is used, you can deliver authentication profiles to the WAC. If
the built-in authentication server of iMaster NCE-Campus is used for wireless access
authentication, access authentication must be configured to enable iMaster NCE-
Campus to record the mapping between authentication control points, SSIDs, and
authentication profiles.
Security Policy Design

In addition to the traditional NAC solution, four WLAN security policies are
available: Wired Equivalent Privacy (WEP), Wi-Fi Protected Access (WPA), WPA2,
WLAN Authentication and Privacy Infrastructure (WAPI). Each security policy has a
series of security mechanisms, including link authentication used to establish a
wireless link, user authentication used when users attempt to connect to a
wireless network, and data encryption used during data transmission. Table 2-63
compares these WLAN security policies.
Table 2-63 Comparison between WLAN security policies
rity
Polic
y
WEP The original 802.11 security mechanism, WEP, is vulnerable to security

threats due to the limitations of its encryption algorithm. Therefore, WEP
is not recommended.

rity
Polic
y
WPA WPA and WPA2 provide almost the same security. WPA/WPA2 has two
/ editions: enterprise edition and personal edition.
WPA ● WPA/WPA2-Enterprise: uses a RADIUS server and the Extensible
2 Authentication Protocol (EAP) to provide IEEE 802.1X network access
control. Users provide authentication information, including the user
name and password, and are authenticated by an authentication
server (generally a RADIUS server). This edition applies to scenarios
that have high requirements on network security.
● WPA/WPA2-Personal: adopts a simpler mechanism, that is, WPA/
WPA2 pre-shared key (WPA/WPA2-PSK) mode. This edition does not
require an authentication server and applies to scenarios that have
low requirements on network security.
WAP WAPI is a WLAN security standard proposed in China and provides

I higher security than WEP and WPA.
NAC is typically considered in conjunction with security policies to form combined

network access control solutions suited to diverse scenarios. Table 2-64 lists
WLAN security policies, recommended NAC authentication modes, and application
scenarios.
Table 2-64 Recommendations on configuring a WLAN security policy

Policy NAC
Authentication
Mode
Open (no Portal/MAC ● An open WLAN that has no security policy

security address configured and allows any STA to connect.
policy authentication You are advised to configure both Portal
configured) authentication and MAC address
authentication.
● Public places with high user mobility, such
as airports, stations, business centers,
conference halls, and sports stadiums. This
security policy should be configured
together with Portal authentication, which
supports user authentication, accounting,
authorization, and information pushing.
WEP - ● This security policy is not recommended

due to its low security.
● Individual or home networks


Policy NAC
Authentication
Mode
WPA/WPA2- - ● This security policy has higher security than

PSK WEP. Additionally, no third-party server is
authenticati required and the cost is low.
on ● Individual or home networks
WPA/ 802.1X ● This security policy provides high security

WPA2-802.1 authentication and requires a third-party server.
X (only this ● Scenarios with fixed users and requiring
authenticati authentication high security and centralized user
on mode can be management and authorization, such as
selected) mobile office, campus networks, and
mobile administration
WAPI-PSK - This security policy provides higher security

authenticati than WEP and requires no third-party server.
on Only some STAs support the protocol.
WAPI- - This security policy provides high security and

certificate requires a third-party server. Only some STAs
authenticati support the protocol.
on
2.3.5.7 Radio Resource Management Design

WLAN technology uses radio signals (such as 2.4 GHz or 5 GHz radio waves) as
transmission medium. Due to environment interference, radio signals will
attenuate when transmitted over the air, degrading service quality for wireless
users. Radio resource management enables APs to check the surrounding radio
environment, dynamically adjust working channels and transmit power, and evenly
distribute access users. This function helps reduce radio signal interference and
adjust radio signal coverage to enable a wireless network to quickly adapt to radio
environment changes. With the radio resource management function, the wireless
network can provide high service quality for wireless users and maintain an
optimal radio resource utilization.
2.3.5.7.1 Radio Calibration
Traditional Radio Calibration

On a WLAN, the operating performance of APs is affected by the radio
environment. For example, a high-power AP can interfere with adjacent APs if
they work on overlapping channels. In this case, the radio calibration function can
be deployed to dynamically adjust channels and power of APs managed by the
same WAC to ensure that the APs work at the optimal performance.
Depending on the scope of radio calibration, two radio calibration modes are
available:

● Global radio calibration: A WAC dynamically allocates channels and power to

all the APs managed by it. This calibration mode is used when a new WLAN is
established or the radio environment of a WLAN deteriorates on a large scale.
● Partial radio calibration: A WAC dynamically allocates channels and power to
specified APs. This calibration mode is used when new APs are added to the
network or signal interference exists in some areas.
Radio calibration can be triggered in any of the following modes:
● Automatic mode: APs perform global calibration periodically based on the
specified calibration interval.
● Manual mode: Radio calibration is not automatically implemented but
manually triggered through commands.
● Scheduled mode: APs perform global calibration at a scheduled time every
day.
The three modes cannot be configured simultaneously. You can choose any of the
modes as required. For example, if burst strong interference sources exist in some
areas of a network, you are advised to manually perform partial radio calibration
for interfered APs. During radio calibration, the working channel of an AP is
adjusted. As a result, STAs associated with the AP go offline, causing service
interruption. Therefore, it is recommended that scheduled radio calibration be
configured so that APs perform radio calibration in off-peak hours, for example,
between 00:00 am and 06:00 am.
Intelligent Radio Calibration

Traditional radio calibration is implemented in a periodic and passive manner,
which relies on radio detection for environment awareness. This mode focuses on
detecting radio interference but lacks insights into the actual services. An ideal
radio calibration mode is demanded, in which the network load is considered, the
number of STAs and traffic volume on a network can be intelligently predicted,
the optimal radio parameters can be calculated based on historical data, and
optimal transmitting and receiving efficiency of air interfaces can be ensured.
When scheduled radio calibration is triggered in the early morning (off-peak
hours), the network is unaware of the actual service load of APs in the daytime
(peak hours) and cannot detect fixed interference sources that exist periodically in
the daytime. In this case, radio calibration is performed based only on the real-
time network status. As a result, the calibration effect cannot be guaranteed, and
radio resources cannot be fully utilized.
In the intelligent radio calibration solution, iMaster NCE-CampusInsight accurately
identifies the network topology and the list of edge APs by analyzing a large
amount of data reported by devices, and predicts the load in the next calibration
period by analyzing historical data. When starting radio calibration, the system
uses the latest prediction data as the input data of the calibration algorithm and
performs calibration calculation based on the real-time network quality to achieve
the optimal calibration effect. Figure 2-130 demonstrates the framework of the
intelligent radio calibration solution.

Figure 2-130 Framework of the intelligent radio calibration solution
NOTE
1. Intelligent radio calibration and traditional radio calibration cannot be deployed for the
APs in the same calibration region at the same time.
2. Intelligent radio calibration needs to be used together with iMaster NCE-CampusInsight.
Ensure that APs can communicate with iMaster NCE-CampusInsight.
3. AP load prediction is applicable to scenarios where service traffic is relatively stable and
historical data is regular, such as the office automation (OA) scenario. When there is a
sudden increase or decrease in service traffic, for example, when network expansion or
large-scale personnel relocation occurs (such as in stadiums), AP load prediction cannot be
implemented.
4. Only the 5 GHz frequency band is supported when increasing the channel bandwidth of
high-load APs. In addition, if the number of available channels is less than six (for example,
in some countries, the number of available 5 GHz channels is small; if dual-5G is enabled,
the 40 MHz or higher channel bandwidth cannot be completely staggered), the channel
bandwidth cannot be increased on high-load APs.
Comparison Between Traditional Radio Calibration and Intelligent Radio

Calibration
Table 2-65 compares traditional radio calibration and intelligent radio calibration.
Traditional radio calibration applies to more scenarios and can effectively handle
burst strong interference sources on the network. Intelligent radio calibration
achieves better calibration effects based on historical data analysis in scheduled
radio calibration scenarios. Select a proper calibration mode based on actual
service requirements.

Table 2-65 Comparison between traditional radio calibration and intelligent radio
calibration
Calib Application Scenario Advantage Disadvantage
ratio
n
Mode
Tradit 1. Scenarios where ● When burst strong ● When scheduled

ional iMaster NCE- interference sources radio calibration
radio CampusInsight is not exist, you can is used, the
calibr deployed on the perform partial network
ation customer's network calibration to reduce topology is lost,
2. Automatic, manual, the impact of the the impact of
and scheduled interference source. nomadic STAs
calibration scenarios cannot be
reduced, and the
impact of
network load on
network
performance
cannot be
predicted.
Intelli 1. Scenarios where ● The network ● Burst strong

gent iMaster NCE- topology is more interference
radio CampusInsight is complete thanks to sources cannot
calibr deployed on the big data learning. be avoided.
ation customer's network Nomadic STAs can
2. Scenarios where be effectively
scheduled radio identified, reducing
calibration is their impact on the
periodically performed network. The impact
of network load on
network
performance can be
accurately predicted.
2.3.5.7.2 Load Balancing

Load balancing can evenly distribute traffic loads to APs to ensure sufficient
bandwidth of each STA. The load balancing function applies to high-density
WLANs to ensure proper access of STAs.
This function is applicable to scenarios where there is a high degree of overlapping
between APs' coverage ranges. If APs engaged in load balancing are far from each
other, a STA may connect to a distant AP, which affects wireless experience of
users.
Depending on whether a load balancing group needs to be manually created, load
balancing is classified into static and dynamic load balancing:
● Static load balancing: APs providing the same services are manually added to
the same load balancing group. After a STA connects to a WLAN, the WAC

uses the load balancing algorithm to measure the dual-band capability of the
STA, AP load, and AP signal quality, and steers the STA to a better AP.
● Dynamic load balancing: After a STA connects to an AP, the WAC checks
whether the number of STAs on this AP reaches the load balancing threshold.
Then, the WAC determines whether to steer the STA to a neighboring AP that
meets the load balancing conditions based on the load balancing algorithm.
Static load balancing limits the maximum number of AP radios to 16 and allows
only radios on the same frequency band to join a load balancing group.
Additionally, a load balancing group needs to be manually specified. In practice,
dynamic load balancing is recommended. In this mode, APs collect neighbor
information and steer STAs to proper APs based on the load balancing status,
dynamically implementing better STA access.
2.3.5.7.3 Band Steering

On live networks, most STAs support both 2.4 GHz and 5 GHz frequency bands
but usually associate with the 2.4 GHz radio by default when connecting to the
network. As a result, the 2.4 GHz frequency band with fewer channels is
congested, heavily-loaded, and has severe interference. The 5 GHz frequency band
with more channels and less interference is not well used. When the 2.4 GHz
frequency band is overloaded or has severe interference, the 5 GHz frequency
band can provide better access service for wireless users. To connect to the 5 GHz
radio, users need to select the 5 GHz radio on STAs.
The band steering function allows an AP to steer STAs to the 5 GHz radio first.
This reduces the traffic load and interference on the 2.4 GHz frequency band and
improves user experience.
It is recommended that the band steering function be enabled by default. This
function, together with the load balancing function, can evenly distribute STAs on
one and multiple APs and improve user experience across the entire network.
NOTE
1. The two frequency bands of an AP enabled with the band steering function must use the
same SSID and security policy. The band steering function cannot be deployed on a single-
radio AP.
2. To allow STAs to preferentially associate with the 5 GHz radio and achieve better access
effect, configure larger power for the 5 GHz radio than the 2.4 GHz radio.
2.3.5.8 Wireless Roaming Design

On a WLAN network, STAs are devices with mobile communication capabilities.
However, the coverage area of a single AP is limited. As users move out of range
of one AP, they usually roam to another AP. Therefore, ensuring a smooth service
experience when a user moves between different APs is key to the WLAN network
quality. As shown in Figure 2-131, WLAN roaming enables STAs to move from the
coverage area of an AP to that of another AP with nonstop service transmission.

Figure 2-131 WLAN roaming
WLAN roaming is mainly used to:

● Retain users' IP addresses. In this way, users can still access the initially
associated network and continue their services after roaming.
● Avoid packet loss or service interruption caused by long-term authentication.
Layer 2/3 Roaming and Inter-WAC Roaming

Depending on whether the service VLAN of STAs changes before and after
roaming, WLAN roaming can also be classified into Layer 2 roaming and Layer 3
roaming. Depending on the roaming range of STAs, WLAN roaming is classified
into intra-WAC roaming and inter-WAC roaming.

In Layer 2 roaming, the service VLAN and gateway remain unchanged after STA
roaming, and traffic can be directly forwarded on the new AP. During WLAN
deployment, Layer 2 roaming is recommended. In the case of a single WAC, the
user gateway can be deployed on the WAC or a core switch at an upper layer. In
the case of multiple WACs (deployed in off-path or in-path mode), it is
recommended that the gateway be deployed on a core switch at an upper layer,
and inter-WAC roaming (still Layer 2 roaming) be used. During Layer 2 roaming,
the gateway remains unchanged, and either tunnel forwarding or direct
forwarding can be adopted. Select a forwarding mode based on service
requirements.

In Layer 3 roaming, the VLAN and gateway of a STA both change after roaming,
and the STA moves between Layer 3 networks. If different VLANs and gateways
are deployed in different buildings or areas, Layer 3 roaming is used. After
roaming, the STA IP address remains unchanged. On the new network, this IP
address cannot directly communicate with the corresponding gateway, and thus
traffic cannot be forwarded. Therefore, a tunnel must be established between
WACs to forward traffic of the roaming STA to the original gateway. In this case,
an inter-WAC mobility group must be configured, with a tunnel established
between WACs to forward STA traffic. If Layer 3 roaming is required on the
network, the tunnel forwarding mode is recommended because this mode does
not require the setup for a large number of tunnels between APs and allows
traffic to be forwarded only through the roaming tunnel between WACs.
During inter-WAC roaming, especially inter-WAC Layer 3 roaming, service traffic
generated by a STA needs to be redirected to the home WAC through the tunnel
between WACs for forwarding. This complicates STA roaming, and consumes more
WAC resources and inter-WAC link resources. Therefore, in actual deployments,

you are advised to properly plan the WLAN to avoid possible inter-WAC roaming.
For example, configure APs in the same building or at the same site to be
managed by the same WAC. If inter-WAC roaming is inevitable, properly plan the
number of members in the mobility group to reduce resource consumption caused
by user information synchronization between mobility group members.
Key Points in Designing the In-Roaming Packet Loss Rate and Handover
Delay
Apart from the basic roaming functions, the packet loss rate and handover delay
during STA roaming are also important indicators to consider. For example, in
industrial manufacturing scenarios, the automated guided vehicles (AGVs) used in
warehouses and factories require the network system to deliver a packet loss rate
less than 1% and a roaming delay less than 100 ms.
To this end, when designing wireless roaming, you are advised to:
● Ensure signal coverage continuity. That is, ensure no coverage hole exists in
areas where roaming is required. Keep a 10% to 15% signal overlap between
the coverage areas of neighboring APs to ensure smooth STA roaming
between the APs.
● Enable fast roaming function in order to reduce the handover delay and
minimize the packet loss probability.
Huawei WLAN supports pairwise master key (PMK) fast roaming and 802.11r fast
roaming. Table 2-66 lists the handover delay of STAs in different roaming modes.
Fast roaming can be enabled as required.
Table 2-66 STA handover delay in different roaming modes

over
Dela
y
(ms)
Open or 802.11r < 50 If the ● 802.11r fast roaming requires

roaming ms Protected that STAs also support this
Manageme function. Currently, mainstream
nt Frame models support 802.11r fast
(PMF) roaming.
function is ● The 802.11r fast roaming and
not PMF functions are mutually
required, it exclusive. If the 802.11r fast
is roaming function has been
recommend configured, the PMF function
ed that the cannot be configured.
802.11r fast
roaming
function be
enabled.


over
Dela
y
(ms)
WPA-PSK/WPA2- < 100 This PMK fast roaming requires that

PSK/802.1X fast ms function STAs also support this function.
roaming (PMK) takes effect Currently, almost all STAs support
automatical PMK fast roaming, which delivers
ly. better compatibility than 802.11r
fast roaming.
802.1X non-fast < 250 This is a N/A

roaming: ms basic
function of
the system
which takes
effect
automatical
ly.
● Enable the device-pipe synergy function. The 802.11r roaming enhancement

mechanism between Huawei APs and Huawei STAs can reduce the roaming
delay to about 10 ms.
Smart Roaming
Dumb terminals and some outdated STAs have low roaming aggressiveness. As a
result, they stick to the initially connected APs regardless of the long distance from
the APs, weak signals, or low rates. The STAs do not roam to neighboring APs with
better signals. Such STAs are generally called sticky STAs. The negative impact of
sticky STAs is described as follows:
● The service experience of a sticky STA is poor, and such a STA is always
associated with an AP with poor signal strength. As a result, the channel rate
decreases significantly.
● The overall performance of wireless channels is affected. A sticky STA may
encounter frequent packet loss or retransmission caused by poor signal
quality and low rates, and therefore occupies the channel for a long time. As
a result, other STAs cannot obtain sufficient channel resources.
To reduce the impact of sticky STAs on a WLAN, you are advised to enable smart
roaming. The smart roaming function intelligently identifies sticky STAs on the
network and proactively directs them to APs with better signals in a timely
manner. This function improves user experience in terms of the following aspects:
● Better performance: Smart roaming can direct poor-signal STAs to APs with
better signals, improving user service experience and overall channel
performance.
● Load balancing: Smart roaming ensures that each STA is associated with the
nearest AP, achieving inter-AP load balancing.

AI Roaming
In smart roaming, APs scan STAs on their operating channels, which may lead to
the following problems that affect the roaming effect:
● The operating radio of an AP is used to scan STAs. If no STA is scanned, the
generated roaming neighbor information may be incomplete, affecting
roaming steering.
● A unified roaming steering mechanism is used during smart roaming, without
distinguishing STAs. As the roaming sensitivity varies with different STAs, the
mechanism may fail in some cases.
● During smart roaming, the Received Signal Strength Indicator (RSSI) of a STA
is detected by the AP, but not in the opposite way. Therefore, the roaming
neighbor to which the STA is steered may not be the optimal one.
The AI roaming feature can be deployed to resolve the preceding problems. As
illustrated in Figure 2-134, AI roaming utilizes intelligent analysis algorithms to
profile the roaming capabilities of STAs, identify such capabilities of different STA
types and operating system versions, and provide targeted roaming steering for
the STAs, improving the roaming steering success rate. Combined with the
independent scanning radio (a third radio) feature, AI roaming uses a fixed radio
for real-time STA scanning to obtain the AP's RSSI that STAs detect through STAs'
RSSI measurement packets. In this way, more complete and effective information
about roaming neighbors is available, so that the optimal AP to which a STA is to
roam can be identified, enhancing user experience during roaming.
Figure 2-134 AI roaming process

When deploying AI roaming, ensure that roaming profiles of STAs are available,
which are used to obtain STAs' roaming characteristics for differentiated steering.
The system has built-in STA profile files and can dynamically generate roaming
profiles of STAs on the live network through online real-time learning. In addition,
AI roaming depends on terminal identification. That is, the roaming profile of a
STA can be matched only after the STA is identified. The WAC has a built-in
terminal fingerprint database, which can help identify STAs, without the need to
work with iMaster NCE-Campus.
AI roaming depends on hardware and feature deployment. Pay attention to the
following when deploying this feature:
● AI roaming depends on the terminal identification capability of the WAC. The
WAC has a built-in terminal identification database that cannot be upgraded
currently. Therefore, some new STAs may not be identified.
● AI roaming needs to work with the independent scanning radio (a third
radio), that is, the AP with this feature deployed must support such a radio.
Some AP models support an independent scanning radio only after they have
a right-to-use (RTU) license loaded. Therefore, this feature can be deployed
only when the hardware conditions are met.
● AI roaming supports roaming steering only for STAs working on the 5 GHz
frequency band. Therefore, a 5 GHz SSID must be deployed on the network.
● AI roaming is mutually exclusive with the PMF feature, and therefore cannot
work for a device with the PMF feature enabled.
2.3.5.9 Wireless Location Design
2.3.5.9.1 Wireless Location Solution Overview

Three mainstream wireless location solutions are available: Wi-Fi location,
Bluetooth location, and ultra-wideband (UWB) location. The Wi-Fi location and
Bluetooth location solutions can locate both Wi-Fi and Bluetooth tags and
terminals. The UWB location solution currently can locate only UWB tags.
Wireless tag location technology uses radio frequency identification (RFID) devices
and a location system to locate a specific target via a WLAN. This technology
involves locating Wi-Fi, Bluetooth, and UWB tags. To implement wireless tag
location, an AP collects and sends tag information to a location server. The
location server then calculates the physical location of the tag and sends the
calculated data to a third-party device so that the user can view the location of
the target tag through a map or table. Huawei's end-to-end wireless tag location
solution is provided in cooperation with third-party vendors in the industry.
Wireless terminal location involves locating Wi-Fi and Bluetooth terminals.
● Wi-Fi terminal location technology locates terminals based on wireless signal
strength information in the surrounding environment collected by APs. To be
specific, an AP reports the collected wireless signal information transmitted by
a Wi-Fi terminal to a location server. The location server calculates the
location of the terminal according to the obtained wireless signal information
as well as the AP's location, and then displays the terminal's location to the
user. The Wi-Fi terminal location solution can be implemented by using
Huawei WLAN devices (the location engine of iMaster NCE-CampusInsight
serves as the location server) or by cooperating with third-party partners.

● Bluetooth terminal location includes two location methods: terminal-side

location and network-side location. In terminal-side location, a Bluetooth base
station or a built-in Bluetooth module of an AP actively broadcasts an
iBeacon frame. After scanning and obtaining the iBeacon frame, a terminal
interacts with a location engine for calculating the location through a
particular location algorithm. (Typically, the location engine provides the SDK
to calculate the location on the terminal) In network-side location, the built-
in Bluetooth module of an AP scans and collects Bluetooth iBeacon broadcast
frames and signal strength information in the surrounding environment, and
reports them to a location server. With the obtained signal strength and AP
location, the location server can calculate the location of a specific terminal.
2.3.5.9.2 Deployment Suggestions for Wireless Location

Table 2-67 describes the capabilities and application scenarios of the wireless
location solutions.
Table 2-67 Comparison of wireless location solutions

m
Sup Trail Asset Cust Asset Indoor Personn Geo-

port playbac locatio ome location navigation el fencing
ed k n r location
app flow
lica anal
tion ysis
s
Loc Networ Networ Net Network- STA-side Network Network

atio k-side k-side wor side location -side -side
n locatio locatio k- location location location
met n n side
hod loca
tion
Loc 5m@ 10 m 5m 10 m @ 5m@ 50 cm @ 50 cm @

atio 90% @ 90% @ 90% 90% 90% 90%
n 90
acc %
ura
cy
Loc 10 60 60 60 seconds 3 seconds 1 second 60

atio second second seco seconds
n s s nds
upd
ate
del
ay


m
STA Mobile Wi-Fi Mo Bluetooth Mobile UWB tag UWB tag

typ phone tag bile tag phone
e pho
ne
Coo Locatio Locatio Loc Location Location Location Location

per n n atio engine engine engine engine
ativ engine engine n Map Map Asset Asset
e Map Map engi engine engine manage manage
com engine engine ne ment ment
pon BI server BI server
BI BI Ma server server
ent p BLE tag BLE
s server server beacon UWB UWB
engi card card
Wi-Fi ne
tag UWB tag UWB tag
BI
serv
er


m
Net ● The AP installation ● The AP ● The AP ● The distance

wor height is no more installat installat between UWB
k than 5 m. ion ion anchors is no
dep ● The spacing between height height less than 3 m.
loy APs is no more than is no is no ● It is
me 20 m. more more recommended
nt than 3 than 5 that the area
sug ● All APs have m. m.
omnidirectional length and width
gest ● The ● The ratio be less than
ions antennas.
spacing spacing 3:1.
● At least three APs in betwee betwee
each location can ● The distance
n APs is n APs is between
collect packets from no more no
STAs. adjacent UWB
than 15 more anchors does not
● No obstacle exists m. than 8 exceed the
between APs and ● At least m. maximum
STAs. three ● A STA distance of
APs can can signal coverage.
collect collect ● The AP
packets packets installation
from from at height is smaller
Bluetoo least than 5 m.
th tags. three
● No APs.
obstacle ● No
exists obstacle
betwee exists
n APs betwee
and n APs
STAs. and
STAs.
For details about the principles of the cooperation solution between Huawei and
third-party location vendors as well as device selection, see related documents at:
https://e.huawei.com/en/material/bookshelf/bookshelfview/202004/03160039
2.3.5.9.3 Wireless RSSI-based Location Engine

The wireless location solution can work with the location engine provided by
iMaster NCE-CampusInsight to locate and display STAs, Wi-Fi interference sources,
and non-Wi-Fi interference sources. Figure 2-135 demonstrates Huawei's wireless
RSSI-based location solution architecture.

Figure 2-135 Wireless RSSI-based location solution architecture
Precautions for wireless RSSI-based location solution design:

● You are advised to use a professional WLAN planning tool to assist in
selecting and deploying APs. Deploy APs in W-shaped pattern and at a height
of less than or equal to 5 m to ensure that STAs can be scanned by more than
three APs at any position
● Ensure that APs are reachable to iMaster NCE-CampusInsight so that location
data can be sent to its location engine.
● Make sure that the device clock is synchronous with the clock of iMaster NCE-
CampusInsight. An NTP server is recommended for network system clock
synchronization.
● To use the location engine for locating non-Wi-Fi interference sources, you
need to enable spectrum analysis on the device. When there are two or more
non-Wi-Fi interference sources of the same type in a region, the number of
them cannot be displayed on iMaster NCE-CampusInsight.
● In the case that the network needs to work with a third-party location system,
iMaster NCE-CampusInsight needs to directly provide the map and terminal
location information needed by the location system through unified
northbound APIs; the third-party location system needs to parse the data
calculated by iMaster NCE-CampusInsight.
2.3.6 Egress Network Design
2.3.6.1 Security Zone Design
Security Zone Overview

A security zone is a collection of networks connected through one or more
interfaces. Users on the networks in a security zone have the same security
attributes. Most security policies are implemented based on security zones. Each

security zone identifies a network, and a firewall connects networks. Firewalls use
security zones to divide networks and mark the routes of packets. When packets
travel between security zones, security check is triggered and corresponding
security policies are enforced. Security zones are isolated by default.
Generally, there are three types of security zones: trusted, DMZ, and untrusted.
● Trusted zone: refers to the network of internal users.
● DMZ: demilitarized zone, which refers to the network of internal servers.
● Untrusted zone: refers to untrusted networks, such as the Internet.
Security Zone Planning

A campus network itself is considered secure, but is faced with security threats
from the outside. Therefore, allocate the Internet to the untrusted zone and the
campus network to the trusted zone. Deploy security devices at the campus
network egress to isolate the intranet from the Internet and defend against
external threats. Allocate the data center to the DMZ, and deploy firewalls in the
DMZ to isolate traffic between the campus intranet and servers in the data center.
In the virtualized campus network solution, when user gateways are located inside
the fabric, each egress of the fabric's external network resources corresponds to a
Layer 3 logical interface on the firewall. During egress planning for external
network resources, VNs with the same security policy have been divided according
to different logical egresses. Therefore, in this solution, security zones can be
divided based on the interfaces of external network resources, and each logical
interface is assigned a security zone, as shown in Figure 2-136. If user gateways
are located outside the fabric, you need to bind the gateways to security zones
based on the security policies of the gateways.
Figure 2-136 Firewall security zone division when user gateways are located
inside the fabric

2.3.6.2 Hot Standby Design

When firewalls function as egress devices, you are advised to deploy hot standby
(HSB) to improve firewall reliability. As illustrated in Figure 2-137, the firewalls
act as egress devices of the campus network and are directly connected to the
stacked core switch. The two firewalls are configured to work in HSB mode, and
the member links in their interconnected Eth-Trunk are in active/standby mode.
When the active firewall is faulty, the standby firewall takes over services and
forwards service packets.
2.3.6.3 Egress Route Design

Egress routes of the campus network are used for north-south communication
between the campus intranet and external networks. When a firewall is used as
the egress device, you need to consider the routes from the firewall to external
networks and those between the firewall and the core switch.
Routes from the Firewall to External Networks: Intelligent Traffic Steering

If the campus network connects to only one Internet Service Provider (ISP)
network, you do not need to perform refined control on the routes to the external
network. In this case, you can configure a default route on the firewall and set the
next hop of the route to the PE on the ISP network.
If the campus network connects to multiple ISP networks, users can access
Internet resources through different ISP networks. To properly utilize egress links
and ensure egress access quality, you are advised to configure the intelligent
traffic steering function on the firewall. In this scenario, it is recommended that
you deploy the ISP-based traffic steering function. This function routes traffic
destined for a specific ISP network out through the corresponding outbound
interface, ensuring that traffic is forwarded on the shortest path.
As shown in Figure 2-138, the firewalls each have two ISP links to the Internet. If
a campus network user accesses Server 1 on ISP 2 network and the firewall has

equal-cost multi-path routing (ECMP) routes, the firewall can forward the access
traffic from two different paths to Server 1. Apparently, path 1 is not the best
path, and path 2 is the most desired path. After you configure ISP-based traffic
steering, when an intranet user accesses Server 1, the firewall selects an outbound
interface based on the ISP network where the destination address resides to
enable the access traffic to reach Server 1 through the shortest path, that is, path
2 in Figure 2-138.
Figure 2-138 Intelligent traffic steering
Routes from the Firewalls to External Networks (Off-Path Deployment of

Firewalls)
Figure 2-139 shows the egress networking of a large or midsize campus where
firewalls are deployed in off-path mode. The intranet traffic from the core switch
passes through the firewalls and then returns to the core switch, and then is
forwarded to the egress routers to access the external network. The path of the
outbound traffic of users on the campus network is as follows: core switch ->
firewall -> core switch -> egress router. In this case, the traffic is sent to the
external network through the egress routers.
The network configuration consists of two parts: core switch -> firewall and
firewall -> core switch -> egress router.
● Core switch -> firewall: On the core switch, L3 egress is configured for the
fabric for interconnection with the southbound interfaces of the firewalls. The
firewalls are deployed in VRRP hot standby (HSB) mode and connect to the
core switch through the southbound interfaces. It is recommended that static
routes be used between firewalls' southbound interfaces and the core switch.
● Firewall -> core switch > egress router: It is recommended that OSPF be
configured to implement communication. When configuring OSPF on
firewalls, you need to import the static routes from the firewalls destined for
the campus intranet. When configuring OSPF on egress routers, you need to
import the default routes from the egress routers destined for the external
network. Interfaces connecting the core switch to the firewalls and egress

routers need to be added to additional VPN instances for isolation from other
traffic.
Figure 2-139 Egress network diagram (firewalls deployed in off-path mode)
Routes Between the Firewall and the Core Switch

North-south routes are present between the firewall and the core switch, including
routes from the campus intranet to external networks on the core switch as well
as return routes from external networks to the campus intranet on the firewall. In
the virtualization solution for large- and medium-sized campus networks, under
the external network resource model designed for the fabric, the routing protocol
used for Layer 3 connectivity between the firewall and the core switch (border
node) can be static routing, OSPF, or BGP. Generally, two firewalls are deployed in
HSB mode to ensure reliability. When selecting a routing protocol, take into
consideration how to switch the service traffic path in an active/standby
switchover scenario.
● Static routing
If two firewalls implement HSB by operating as a VRRP master and a VRRP
backup, static routing is recommended. As illustrated in Figure 2-140, a
default static route is configured on the core switch, with the next hop being
the virtual IP address of the VRRP group. When the master firewall in the
VRRP group is in the master state, it responds to the ARP request containing a
virtual IP address sourcing from the core switch. In this way, the service traffic
on the core switch can be diverted to the master firewall for processing.
In the event of a failure on the master firewall, the backup firewall in the
VRRP group becomes the new master and broadcasts a gratuitous ARP packet
that carries the virtual IP address of the VRRP group and the MAC address of
the corresponding interface (virtual MAC address is carried if the virtual MAC

address function is enabled on the interface). After receiving the gratuitous

ARP packet, the core switch updates its ARP table. Thus, the service traffic
path is switched to the backup firewall.
Figure 2-140 Using static routing between the firewall and the core switch
● Dynamic routing
If VRRP is not deployed on firewalls, dynamic routing can be used to
implement automatic switching of the service traffic path. In this case, you
need to run the hrp standby-device command on the standby firewall to set
it to the standby state. As shown in Figure 2-141, OSPF is used as an
example. When both the active and standby firewalls work properly, the
active firewall advertises routes based on the OSPF configuration, and the
cost of the OSPF routes advertised by the standby firewall is adjusted to
65500 (default value, which can be changed). In such a scenario, the core
switch selects a path with a smaller cost to forward traffic, and all service
traffic is diverted to the active firewall for forwarding.
If the active firewall is faulty, the standby firewall converts to the active state.
In addition, the VRRP Group Management Protocol (VGMP) adjusts the cost
of the OSPF routes advertised by the active firewall to 65500 and that of the
OSPF routes advertised by the standby firewall to 1. After route convergence
is complete, the service traffic path is switched to the standby firewall.
Figure 2-141 Using dynamic routing between the firewall and the core switch

For details about the deployment when using different routing protocols between
the firewall and the core switch, see the external network design in 2.2.4.3 Fabric
Network Design.
2.3.6.4 Security Policy Design

After security zones are divided on the firewall based on source interfaces, the
security zones are isolated by default. To allow communication between two
security zones, for example, to enable users within the campus intranet to access
the Internet, Layer 3 routes need to be configured on the firewall. In addition, you
need to create security policies on the firewall to allow the traffic between the
security zones. Security policies also provide advanced security protection
functions to analyze security threats in each zone and ensure secure, trustworthy
access sources.
As shown in Figure 2-142, with security policies configured, VNs on the campus
network can communicate with each other, and the external network can access
servers in the DMZ. In addition, different security protection policies can be
implemented for traffic in different security zones.
Figure 2-142 Applying security policies
Table 2-68 describes the recommended security policy design for common zones.

Table 2-68 Recommended security policy design for common zones

Access Network Access Source Trustworthiness Recommended
Represented by Security Policy
the Security
Zone
Internet External users Untrusted Intrusion

detection, URL
Employees on the Medium filtering, and
go antivirus
WAN Enterprise branch Medium Intrusion

detection and
antivirus
Intranet Enterprise High Intrusion

employees detection and
antivirus
Guests Low
2.3.6.5 NAT Design

Network Address Translation (NAT) is an address translation technology that
translates both the source and destination IP addresses of packets. To allow
campus intranet users using private IP addresses to access the Internet, configure
NAT. As demonstrated in Figure 2-143, if firewalls function as egress devices, pay
attention to the following points when configuring NAT:
Figure 2-143 NAT design

● If private IP addresses are used on the intranet, source NAT technology needs
to be used to translate source IP addresses of packets to public IP addresses
when user traffic destined for the Internet passes through the firewall.
Network Address Port Translation (NAPT) is recommended to translate both
IP addresses and port numbers, which enables multiple private addresses to
share one or more public addresses. NAPT applies to scenarios with a few
public addresses but many private network users who need to access the
Internet.
● If intranet servers are used to provide server-related services for public
network users, destination NAT technology is required for translating
destination IP addresses and port numbers of the access traffic of public
network users into IP addresses and port numbers of the servers in the
intranet environment.
● When two firewalls operate in VRRP hot standby (master/backup) mode, IP
addresses in the NAT address pool may be on the same network segment as
the virtual IP addresses of the VRRP group configured on the uplink interfaces
of the firewalls. If this is the case, after the return packets from the external
network arrive at the PE, the PE broadcasts ARP packets to request the MAC
address corresponding to the IP address in the NAT address pool. The two
firewalls in the VRRP group have the same NAT address pool configuration.
Therefore, the two firewalls send the MAC addresses of their uplink interfaces
to the PE. In this case, you need to associate the hot standby status (master/
backup) of the firewalls with the NAT address pool on each firewall, so that
only the master firewall in the VRRP group responds to the ARP requests
initiated by the PE.
2.3.7 Access Control Design
2.3.7.1 Overall Access Control Design

In the traditional NAC solution, NAC authentication and ACL policies are
implemented. For a campus network, an authentication control point is defined to
perform access authentication and policy control on user terminals connected to
the campus network. Huawei's access control solution combines the traditional
NAC solution with policy association and free mobility to refine the division of
device roles in campus network access control.
● Authentication control point: authenticates users and interacts with an

authentication server to implement authentication, authorization, and
accounting. In the policy association solution, a CAPWAP tunnel is established
between the authentication control point and authentication enforcement
point to exchange user authentication requests and synchronize user entries.
● Authentication enforcement point: controls user access in the policy
association solution. Users can access the network only after being
authenticated successfully. In addition, the authentication enforcement point
transparently transmits user authentication packets to the authentication
control point. The authentication control point can be configured to deliver
user authorization policies to the authentication enforcement point.
● Policy enforcement point: is a device that enforces control policies. Generally,
the authentication control point functions as the policy enforcement point.
For example, in the traditional NAC solution based on NAC authentication

and ACL policies, an authentication server authorizes ACL information to

authenticated users. The authentication control point then performs policy
control on users accessing the network based on the authorized ACL
information. The authentication control point and policy enforcement point
can be deployed separately. In the following example, a standalone WAC is
connected to the core switch in off-path mode; the standalone WAC functions
as the wireless authentication control point, and the core switch functions as
the wireless policy enforcement point.
In the distributed gateway solution, it is recommended that VXLAN be deployed

across core and aggregation layers and the border node functions as the native
WAC. Figure 2-144 illustrates the overall user access control design.
Figure 2-144 User access control in the distributed gateway solution
NAC Server Selection

In the distributed gateway solution, iMaster NCE-Campus delivers service
configurations to campus network devices and implements automatic network
deployment. iMaster NCE-Campus can also function as a NAC server, removing
the need to deploy an additional NAC server for network access control. When
iMaster NCE-Campus functions as a NAC server, it provides the following access
control functions:
● Built-in RADIUS server and Portal server components: These components

support 802.1X authentication, Portal authentication, MAC address
authentication, and MAC address-prioritized Portal authentication.

● Multiple Portal authentication modes: Portal authentication supports user

name and password authentication, SMS authentication, and third-party
social media authentication.
● Terminal identification: iMaster NCE-Campus can implement automatic MAC
address authentication based on terminal identification.
● Free mobility: iMaster NCE-Campus can deliver security group policies to the
policy enforcement point, removing the need to configure security group
policies on the policy enforcement point. iMaster NCE-Campus can also
function as a RADIUS server and allows administrators to specify security
group information when configuring authorization results.
Authentication Control Point Selection

● In the distributed gateway solution, it is recommended that wired and
wireless authentication control points be centrally deployed on edge nodes.
When configuring access management for the fabric, you can plan wired and
wireless authentication control points in a unified manner. However, to bind
authentication profiles to wireless SSIDs on APs, you need to log in to the web
system of the WAC (edge node) to configure this.
● In the distributed gateway solution, VXLAN is usually deployed across core
and aggregation layers for the fabric. You are advised to deploy policy
association between aggregation switches (edge nodes) and access switches/
APs. An access switch can serve as the wired authentication enforcement
point. Wired users can access the network only after passing authentication
on the edge node. An AP can establish a CAPWAP tunnel using the
management VLAN for policy association, go online on an edge node, and
function as the authentication enforcement point for wireless users. No
additional management VLAN is needed.
● For more information about the authentication control point design in the
distributed gateway solution, see "Access Management Design" in 2.3.4.3
Fabric Network Design.
Authentication Enforcement Point Selection

In the distributed gateway solution, the authentication enforcement point is
deployed as follows:
● It is recommended that the wired authentication enforcement point be
deployed on an access switch on the campus network so that the access
switch can control access of wired user terminals. VXLAN is recommended to
be deployed across core and aggregation layers in the distributed gateway
solution. In such scenario, policy association can be deployed between the
edge node (aggregation switch) and access switch. Thus, the wired
authentication control point does not need to be moved down from the edge
node to the access switch, the number of wired authentication control points
does not increase, and the wired authentication enforcement point that
controls access of user terminals still sits on the access switch.
● Policy association is designed based on the traditional "WAC + Fit AP"
architecture for access control. In this architecture, WACs function as wireless
authentication control points and APs as wireless authentication enforcement
points. Wireless user authentication information is synchronized between
WACs and APs through CAPWAP tunnels. The AP prevents unauthorized users
from accessing the campus network.

Policy Enforcement Point Selection

It is recommended that the edge node be configured as both the wired and
wireless authentication control point as well as wired and wireless policy
enforcement point to deploy security group policies for free mobility. iMaster NCE-
Campus can dynamically generate IP-security group entries and deliver the entries
to the edge node based on the security group information configured in the
authorization result of users. The edge node then enforces security group policies
for authorized users based on the IP-security group entries.
On a traditional non-virtualized network where multiple authentication control
points exist, configure IP-security group entry subscription to synchronize IP-
security group entry information between different authentication control points.
This ensures that the authentication control points can implement access control
based on security group policies across authentication control points when they
function as policy enforcement points. On a virtualized network, you do not need
to configure IP-security group entry subscription because the VXLAN header
encapsulated in user packets carries security group information when user packets
are forwarded across authentication control points.
2.3.7.2 User Authentication Mode Selection

Common authentication technologies include 802.1X, MAC address, and Portal
authentication. Table 2-69 compares these authentication modes and describes
their applicable terminal types.
Table 2-69 Different user authentication technologies and applicable terminal

types
Item 802.1X Authentication MAC Address Portal Authentication

Authentication
Client Required Not required Not required
Advanta High security ● No client Flexible deployment

ge required
● No need to
manually
enter the user
name and
password
Disadvan Inflexible deployment MAC address Low security

tage registration
required, making
management
complex
Applicabl Employees' terminals Dumb terminals Guest terminals:

e that need to access the such as printers Generally, guests move
terminal office network and and fax frequently, and
type have high security machines terminal types are
requirements complex.

MAC address-prioritized Portal authentication: After a user terminal passes

Portal authentication, the authentication server caches the user terminal address
within a specified period. During this period, the user can directly access the
network, without entering the user name and password, as long as they pass MAC
address authentication.
Use MAC address-prioritized Portal authentication for guest terminals to improve

network experience of guests.
2.3.7.3 Policy Control Solution Design

Policy control is to control the permissions of users on network resource access.
Currently, the traditional NAC solution and Huawei's free mobility solution are
available for policy control. Table 2-27 compares the two solutions.
Table 2-70 Policy control solution comparison
Polic Contro Characteristics Application Scenario

y l Mode
Cont
rol
Solut
ion
Tradit VLAN ● The administrator needs to ● Users access the

ional + ACL plan a large number of IP network at fixed
NAC addresses, VLANs, and ACLs, locations.
soluti making the configuration ● Permission policies are
on workload heavy and capacity simple.
expansion or configuration
change complex.
● It is difficult to control the
access permissions of users as
well as ensure consistent user
priority and bandwidth when
they move.
Free Securit Administrators do not need to ● Mobile working is

mobil y pay attention to IP address and required, and users can
ity group VLAN assignment. User policies access the network at
soluti + are configured on the controller any location.
on inter- based on security groups and are ● Permission policies are
group automatically delivered to all complex.
policy authentication devices,
eliminating the need to perform
complex configuration.
The free mobility solution is recommended for policy control on large- and
medium-sized campus networks. If the existing campus network of the customer
does not support the free mobility solution, use the traditional NAC solution.

Traditional NAC Solution Design

In the traditional NAC solution, policies fall into two categories: static ACL policies
on local devices and dynamic ACL policies authorized by the NAC server.
Essentially, configuring static ACL policies on local devices is to map user policies
to user IP addresses and plan ACL rules based on these IP addresses for
management and control over user permissions. This type of policy applies to the
scenario where the user network scale is small, locations of user terminals are
fixed, and policy requirements are simple. As the network scale increases and
policy requirements become complex, configuring such policies can be very
complex and difficult to maintain. Therefore, for large- and medium-sized campus
networks, you are advised to use the NAC server to authorize dynamic ACL
policies. With this approach, terminals do not need to be strictly bound to IP
addresses and VLANs, making IP and VLAN planning flexible, as shown in Figure
2-66. When different types of users are present, you are advised to restrict access
locations of the users. That is, users with different permissions access the Internet
from their respective areas specified by the administrator. This ensures that only
related policies need to be configured on devices in these areas. Otherwise, it will
be difficult to configure policies and perform O&M.
Figure 2-145 Policy control based on the traditional NAC solution
Free Mobility Solution Design

Different from the traditional IP address-based ACL mode, free mobility is a user
language-based solution that logically divides different types of network objects
with distinct permissions into different security groups. Each security group maps
one user type and one server type. Then, you can define policies for users in

different security groups to communicate for access control, as shown in Figure

2-67.
Figure 2-146 Policy control based on the free mobility solution
iMaster NCE-Campus provides an intuitive policy matrix to allow the administrator

to configure security group policies and deliver the policies to policy control points.
Assume that A and C are user groups, and B and D are server groups. Members in
group A can communicate with those in groups C and D, while members in group
C can only communicate with those in group D. Members of group A or group C
can communicate within their groups. The corresponding policy design is shown in
Table 2-28. The communication between B and D does not pass through the
campus network and does not need to be planned. In this case, the policy design
between B and D is displayed as NA in the following table. In cells filled with
Empty, no policy is configured, or the permit/deny policy is configured, which does
not influence the control effect.
Table 2-71 Security group policy plan
Source/ A B C D
Destination
Security
Group
A Permit Deny Permit Permit
B Empty NA Empty NA

Source/ A B C D
Destination
Security
Group
C Deny Deny Permit Permit
D Empty NA Empty NA
iMaster NCE-Campus allows administrators to configure a rule from a group to

the Any group (that is, default permissions of the group), reducing the number of
policies that need to be defined and thereby simplifying policy configuration. For
example, as described in Table 2-28, an administrator simply needs to configure a
policy for denying access from group A to group B so that access from group A to
the Any group is permitted.
2.3.7.4 Terminal Identification Design

On large- and medium-sized campus networks, access terminals include PCs,
mobile phones, as well as dumb terminals such as IP phones, printers, and IP
cameras. A large number of terminals of different types need to access the
campus network, making it difficult to manage them. To ease terminal
management, the terminal identification solution offers diversified terminal
identification methods. With iMaster NCE-Campus, you can view the summary
information about terminals on the entire campus network, including their
terminal type and operating system. Based on this information, iMaster NCE-
Campus can perform refined management on terminals from multiple dimensions,
for example, collecting statistics on and displaying traffic by terminal type and
delivering specified authorization policies. Additionally, dumb terminals that
usually use MAC address authentication can be automatically admitted through
terminal identification, reducing manual configuration workload.
2.3.7.4.1 Terminal Identification Method Design

To display terminal types and perform access management based on the terminal
types through iMaster NCE-Campus, the network administrator needs to perform
the following operations:
● Collect the types of terminals on the network, such as PCs, mobile phones,
printers, IP cameras, and access control devices.
● Check whether Portal authentication is deployed on the network.
● Check whether the IP addresses of the terminals are dynamically assigned by
the DHCP server or statically assigned.
Based on the collected information, traverse the items one by one according to
Table 2-72 and select the required terminal identification method. Multiple
methods can be selected to identify terminals. You are advised to enable the
following passive fingerprint-based identification methods: MAC OUI, HTTP
UserAgent, DHCP option, LLDP, and mDNS. It is recommended that Nmap be
disabled by default because its identification period is long. If the preceding
passive fingerprint-based identification methods cannot meet requirements,
enable Nmap.

Table 2-72 Terminal identification methods
Identification Identifiable Application Scenario

Method Terminal Type
MAC OUI All IP terminals Common scenarios (authentication, non-

(identifying only authentication, and dynamic/static IP
the device address assignment scenarios)
manufacturer)
HTTP Mobile phone, Portal authentication scenarios

UserAgent tablet, PC,
workstation
Intelligent audio/
video terminal
DHCP Option Mobile phone, Dynamic IP address assignment scenarios

tablet, PC,
workstation
IP camera, IP
phone, printer
LLDP IP phone, IP Common scenarios (authentication, non-

camera, network authentication, and dynamic/static IP
device address assignment scenarios)
mDNS Apple device, Common scenarios (authentication, non-

printer, IP camera authentication, and dynamic/static IP
address assignment scenarios)
SNMP Query Network device, On-premises scenarios

printer
NMAP PC, workstation On-premises scenarios

Printer, phone, IP
camera
Table 2-73 describes the configuration process of each terminal identification

method in the virtualization solution for large- and medium-sized campus
networks.
Table 2-73 Configuration process of each terminal identification method

Method Side
MAC OUI Enable the terminal -

identification function.
HTTP UserAgent Enable the terminal Enable the terminal

reporting function.


Method Side
DHCP Option Enable the terminal 1. Enable the terminal

reporting function.
2. Enable DHCP snooping.
LLDP Enable the terminal This function is enabled by

identification function. default.
mDNS Enable the terminal 1. Enable the terminal

reporting function.
2. Enable mDNS snooping.
SNMP Query 1. Enable the terminal -

identification
function.
2. Enable the SNMP
scanning function.
Nmap 1. Enable the terminal -

identification
function.
2. Install the Nmap
plug-in.
2.3.7.4.2 Terminal Control Policy Design

Terminal identification enables iMaster NCE-Campus to deliver control policies to
different types of terminals based on information such as the terminal type,
operating system, or manufacturer. The administrator needs to perform the
following operations:
1. Enable the terminal identification function for the network.
2. Configure user access authentication. Authentication and authorization rules
are matched based on the identified terminal type.
3. Plan authorization policies on iMaster NCE-Campus based on terminal types
and deliver corresponding policies after users are authenticated.
Table 2-74 shows an example of policy authorization based on the terminal type,
operating system, or manufacturer. For dumb terminals that use MAC address
authentication, such as printers, IP phones, and IP cameras, the automatic
admission function based on terminal identification can be used. With this
function enabled, dumb terminals can be plug-and-play and automatically access
the network, eliminating the need to manually enter their MAC addresses on
iMaster NCE-Campus.

Table 2-74 Example of policy control Based on terminal identification results
Condition Admission Policy Authorization Policy
Terminal type: printer Automatic admission Authorize VLAN 10
Terminal type: IP camera Automatic admission Authorize VLAN 20
Terminal type: IP phone Automatic admission Authorize VLAN 30; DSCP

48
Terminal type: access Automatic admission Authorize VLAN 40

control device
Manufacturer 1 User admission Authorize ACL 100
NOTE
When terminal identification is used together with the VLAN authorization policy, you can
disable pre-connection in 802.1X and MAC address authentication scenarios to prevent IP
address re-assignment to terminals.
2.3.7.5 Terminal Anomaly Detection and Anti-spoofing Design

Terminal anomaly detection is a technology that determines whether a terminal is
abnormal by identifying whether the traffic of the terminal connected to the
campus network complies with the traffic behavior model for the same type of
terminals. A traffic behavior model defines the characteristics of traffic sent from
terminals to the campus network, such as the access IP address set, TCP/UDP port
set, number of TCP connections, and packet transmission frequency.
Application Scenarios of Device Anomaly Detection

On a large or midsize campus network, dumb terminals, such as IP phones, IP
cameras, and printers, are more likely to be attacked or spoofed than other
terminals. This is because:
● Dumb terminals do not support strong authentication modes such as 802.1X

and Portal authentication. Generally, such terminals use MAC address
authentication or an IP address whitelist to access the network, so they are
easily spoofed by attackers.
● Dumb terminals usually do not have a scheduled antivirus mechanism, and
therefore may be easily implanted with viruses or Trojan horses by network
attackers.
As a result, in dumb terminal access scenarios, you can deploy the terminal
anomaly detection function to detect dumb terminals that are spoofed or attacked
in real time and block their access to the network. This prevents dumb terminals
from being spoofed or attacked, ensuring network security.

Terminal Anomaly Detection Solution Design

The terminal anomaly detection solution consists of terminal information
management, terminal anomaly detection, and terminal anomaly control, as
Table 2-75 Terminal anomaly detection solution
Function Description
Terminal information Basic terminal information, including the MAC

management address, IP address, access location, and terminal
type, is stored on a switch.
Terminal anomaly The switch collects traffic behavior characteristics of

detection terminals and detects terminal anomalies based on
the traffic behavior model.
A switch has a default traffic behavior model for
dumb terminals, including IP phones, IP cameras, and
printers.
Device anormaly control ● The switch identifies abnormal terminals and

reports alarms to iMaster NCE-Campus.
● After an abnormal terminal is identified, you can
configure an isolation policy on the switch to
prevent the terminal from accessing the network.
NOTE
● The terminal anomaly detection function can be configured only on switches using
commands, but not on iMaster NCE-Campus.
● The terminal anomaly detection function applies only to wired access terminals.
● The terminal anomaly detection function supports three types of dumb terminals: IP
phones, IP cameras, and printers.
2.3.7.6 Access Control Design for Huawei iConnect Terminals
2.3.7.6.1 Introduction to Huawei iConnect Terminals

Huawei iConnect terminals are IoT terminals that comply with Huawei iConnect
ecosystem standards.
For example, in the Huawei CloudCampus Solution, Huawei iConnect terminals

that wirelessly connect to the campus network can automatically associate with
the iConnect SSID. The wireless protocol packets exchanged between the Huawei
iConnect terminals and APs contain electronic identity information in a unified
format that meets Huawei iConnect ecosystem standards. The exchanged wireless
protocol packets trigger the first access authentication for Huawei iConnect
terminals. In addition, the authentication packets sent from the WAC to iMaster
NCE-Campus (functioning as the NAC server) also carry electronic identity
information. With this information, iMaster NCE-Campus is able to identify

terminals, and then re-authenticates them and delivers authorization policies

when the terminals access the service SSID.
2.3.7.6.2 Network Deployment Architecture

IoT applications and terminals have been deployed in growing numbers in
campuses due to rapid advances in IoT technologies. To simplify network
infrastructure deployment and improve system O&M capabilities, IoT terminals
access networks in IP mode and IoT services are uniformly carried by campus
networks, which has become a trend of smart campus network construction.
As shown in Figure 2-147, in the Huawei iConnect terminal access control
solution, IoT terminals that comply with Huawei iConnect ecosystem standards
access the campus network through Wi-Fi, and the campus network provides IP
transmission services for these IoT terminals. To ensure secure campus network
access, Huawei iConnect terminals also need to be authenticated and authorized
before accessing the campus network. After the authentication and authorization
are complete, the IoT platform delivers thing model operation instructions to the
IoT gateway via the campus network. The gateway then orchestrates and delivers
the instructions to Huawei iConnect terminals through the campus network.
Figure 2-147 Huawei iConnect terminals accessing the campus network
2.3.7.6.3 Control Policy Design
Related Products
Table 2-76 lists the related products involved in the Huawei iConnect terminal
access control solution in the current version of the CloudCampus Solution.

Table 2-76 Products involved in the Huawei iConnect terminal access control
solution
IoT Terminal Authentica PKI IoT Platform
tion Server Serv
er
● Building direct digital Huawei Serve HUAWEI CLOUD ROMA The

controller (DDC) that iMaster r HUAWEI CLOUD WeLink client
meets Huawei's NCE- provi can be installed on mobile
iConnect ecosystem Campus ded phones and PCs to report IoT
standards by terminal information to the
● IoT terminals that Jilin ROMA platform.
support only MAC Unive
address rsity
authentication and Infor
802.1X authentication mati
on
● IoT terminals that Tech
support only Wi-Fi nolog
access ies
Co.,
Ltd.
Network Access Control Design for Huawei iConnect Terminals

In campus building control scenarios, design the solution based on the following
roadmap if you want to display Huawei iConnect terminal information on iMaster
NCE-Campus and perform network access control based on terminal information:
1. Determine the phase when Huawei iConnect terminals access the campus
network
You need to determine the phase when a Huawei iConnect terminal accesses
the campus network, which can be the building system commissioning phase
or the phase when IoT terminals attempt to access the campus network.
Table 2-77 describes the two phases.

Table 2-77 Different phases when Huawei iConnect terminals access the
campus network
Phase Introduction iMaster iConnect Service Pol

NCE- SSID SSID icy
Campu Authenti Authent Co
s cation ication ntr
Involve Mode Mode ol
d or Inv
Not olv
ed
or
No
t
Buildin The building system is Not No Not No

g deployed earlier than the involved authentic involved t
system campus network. ation inv
commi Therefore, a temporary olv
ssionin local area network (LAN) ed
g is required to support the
phase local commissioning of
the building system.
Phase After the entire campus Involved MAC 802.1X Inv

when network is deployed, the address authenti olv
IoT temporary LAN authentic cation ed
termin configurations that took ation/
als effect in the building 802.1X
attemp system commissioning authentic
t to phase will be replaced by ation
access planned network
the configurations. Huawei
campu iConnect terminals need
s to be re-authenticated
networ and re-authorized to
k access the campus
network in this phase.
2. Perform access control design for Huawei iConnect terminals in the

building system commissioning phase.
In this phase, the building automation system is commissioned only on the
temporary LAN, which does not have high security requirements. Therefore,
you can configure "no authentication" for the iConnect SSID. In this way, after
an IoT terminal accesses the iConnect SSID:
– The WAC can identify whether the terminal is a Huawei iConnect
terminal based on the electronic identity information carried in wireless
protocol packets. If the WAC receives such a packet, the terminal is
identified as a Huawei iConnect terminal and is successfully
authenticated.
– If not, the terminal is identified as a non-Huawei iConnect terminal and
cannot access the network.

3. Select a desired approval mode for Huawei iConnect terminals to access

the campus network.
– Access without approval: Use the WeLink app to scan the QR code on a
Huawei iConnect terminal and enter the MAC address of the Huawei
iConnect terminal on the ROMA platform. The ROMA platform then
synchronizes other information about the terminal to iMaster NCE-
Campus. After the Huawei iConnect terminal accesses the iConnect SSID,
802.1X authentication is triggered by wireless protocol packets carrying
electronic identity information sent by the terminal. Because other
information about the terminal has been synchronized to iMaster NCE-
Campus, the terminal is authenticated successfully.
– Access after the administrator's approval: On the ROMA platform or
iMaster NCE-Campus, the administrator can approve whether a Huawei
iConnect terminal can access the campus network. The terminal
information will be automatically added to the list of terminals to be
approved during MAC address authentication when the terminal accesses
the iConnect SSID for the first time. After approved, the terminal accesses
the iConnect SSID again and triggers MAC address re-authentication.
Table 2-78 compares the two approval modes.
Table 2-78 Comparison between the two approval modes

Appro Method of iConnect SSID Service SSID
val Recording Huawei Authentication Authentication
Mode iConnect Terminal Mode Mode
Information on
the ROMA
Platform
Acces Scanning the QR 802.1X 802.1X

s code of a Huawei authentication authentication
witho iConnect terminal (using EAP-PEAP- (using EAP-TLS)
ut using the WeLink MSCHAPv2)
appro app
val
Acces Using a MAC MAC address 802.1X

s after address whitelist authentication authentication
the (using EAP-TLS)
admin
istrato
r's
appro
val
4. Select a scheme for Huawei iConnect terminals that attempt to access

the campus network to automatically apply for digital certificates.
To ensure the security of IoT terminals and prevent forgery, digital certificates
issued by enterprises need to be installed on terminals. When terminals access
the network, 802.1X authentication is performed to ensure that the terminals
are valid. However, it is cumbersome and time-consuming to install digital
certificates on numerous IoT terminals. Huawei iConnect terminals can

automatically apply for and load digital certificates. Table 2-79 describes the
schemes for Huawei iConnect terminals to automatically apply for digital
certificates in different scenarios.
Table 2-79 Schemes for Huawei iConnect terminals to automatically apply for
digital certificates in different scenarios
Terminal IP Address Method for a Terminal Remarks

Type to Obtain the
Certificate Application
URL
Dynamic IP address The URL is carried in None

(DHCP) sub-option 5 of DHCP
Option 43 configured
on the DHCP server.
Static IP address The URL is obtained by When a terminal

using the authorization accesses the gateway,
redirection ACL for the the terminal is
first access redirected to the URL
for applying for a
certificate on iMaster
NCE-Campus.
5. Perform policy control solution design for Huawei iConnect terminals

that attempt to access the campus network.
After a Huawei iConnect terminal applies for a digital certificate through the
iConnect SSID, the terminal can access the service SSID for 802.1X
authentication. The service authorization policy design for Huawei iConnect
terminals is the same as the management and control policy design in
terminal identification.
Currently, no Huawei iConnect terminal type information is available on
iMaster NCE-Campus. You need to synchronize such information from the
ROMA platform to iMaster NCE-Campus or add the information on iMaster
NCE-Campus before configuring authorization policies based on terminal
types.
2.3.7.7 5G Terminal Access Control Design
2.3.7.7.1 5G Terminal Access to Campus Networks

5G networks featuring high-speed mobility and wide coverage can effectively
supplement campus networks in enterprise campus scenarios. To ensure 5G
terminals' (any devices with 5G modules) secure access to a campus network, the
authentication server of the campus network needs to perform second
authentication on 5G terminals. In addition, the authentication server works with
the multi-service control gateway (MSCG) of the campus network to perform
unified policy control on connected 5G terminals.
Figure 2-148 shows the access process of a 5G terminal to a campus network.

Figure 2-148 Access process of a 5G terminal to a campus network
1. The campus administrator purchases SIM cards and 5G IoT terminals, and
then manually imports information such as the international mobile
subscriber identity (IMSI) and international mobile equipment identity (IMEI)
of the terminals to iMaster NCE-Campus (functioning as the authentication
server), or synchronizes such information from the IoT platform deployed by
the enterprise to iMaster NCE-Campus.
2. 5G terminals equipped with SIM cards access the 5G core network after
successful 5G-AKA authentication, and then create PDU sessions.
3. The session management function (SMF) module on the 5G core network
triggers RADIUS PAP or CHAP authentication and terminal information such
as the IMSI and IMEI carried in RADIUS packets is reported to iMaster NCE-
Campus for authentication. The communication between the SMF and
iMaster NCE-Campus involves sensitive information. Therefore, data flows
between the SMF and iMaster NCE-Campus are transmitted through the
private line and are encrypted by IPsec tunnels.
4. After the authentication is successful on iMaster NCE-Campus, the 5G
terminal can access the enterprise's intranet resources through the 5G
network.
5. After the authentication is successful, iMaster NCE-Campus delivers the
security policy for 5G terminals to the MSCG.
NOTE
● Currently, only iMaster NCE-Campus can function as the authentication server to work
with the carrier's SMF to perform second authentication on 5G terminals and work with
the MSCG.
● 5G terminals in the current solution refer to IoT terminals only and cannot roam
between 5G base stations.
● In the current solution, 5G terminals cannot smoothly switch from a carrier network to
a campus Wi-Fi network.
2.3.7.7.2 MSCG Security Policy Association Design

After successfully authenticating a 5G terminal for the second time, iMaster NCE-
Campus works with the MSCG on the campus network to control the access
permission of the 5G terminal. It is recommended that the MSCG be deployed on
a core switch and then interconnect with iMaster NCE-Campus. The roadmap is as
follows:

1. iMaster NCE-Campus delivers security group policy configurations to the core

switch.
2. After a 5G terminal goes online, iMaster NCE-Campus synchronizes the
mapping between the terminal's IP address and security group to the core
switch through the IP-group entry subscription function. Then the core switch
enforces the security group policy.
2.3.8 Security Design
2.3.8.1 Egress Network Security Design

External network services provided by the intranet, such as the enterprise website
access service and email service, may have potential security risks, threatening the
security of the campus network. It is recommended that the following security
services be deployed on the egress firewall of the campus network to secure the
network perimeter:
1. Assign employees, servers, and the extranet to different security zones to
inspect and protect interzone traffic.
2. Enable the content security protection function based on types of network
services provided by enterprises. For example, enable antivirus and intrusion
prevention for all servers.
3. If employees need to access the Internet, enable functions such as URL
filtering and antivirus to defend against Internet threats and prevent
information leaks to ensure enterprise network security.
Deploying these security services depends on the design of two key functions of
the firewall: security zone and security policy. For more information, see 2.2.6
Egress Network Design.
2.3.8.2 Intranet Security Design

A typical large or midsize campus network uses a three-layer architecture,
consisting of the core layer, aggregation layer, and access layer. Simplified
networks may use a two-layer architecture, consisting of only the core layer and
access layer, which has no difference in network security design. The following
sections will provide guidance on the network security design.
2.3.8.2.1 Access Layer (Access Switch)

The access layer is the edge of a campus network, which provides diverse access
modes to PCs, network cameras, printers, IP phones, and wireless terminals. It is
the first tier of the campus network, and needs to meet access demands of
various terminals. The access layer also needs to protect the entire network
against access of unauthorized users and applications, so it must provide enough
security without compromising network availability. You are advised to enable the
following security functions on the access switch:
● Broadcast storm control
When a Layer 2 Ethernet interface on a device receives broadcast, unknown-
unicast, and multicast (BUM) packets, the device forwards these packets to
other Layer 2 Ethernet interfaces in the same VLAN if the outbound interfaces

cannot be determined based on the destination MAC addresses of these

packets. As a result, a broadcast storm may be generated, degrading
forwarding performance of the device. On downlink interfaces of the access
layer (access switch), configure suppression of BUM packets to effectively
reduce broadcast storms.
● DHCP snooping, with the uplink interfaces that directly or indirectly connect
the access switch to the DHCP server configured as trusted interfaces
DHCP snooping defends against bogus DHCP server attacks, DHCP server DoS
attacks, bogus DHCP packet attacks, and other DHCP attacks. DHCP snooping
allows administrators to configure trusted interfaces and untrusted interfaces,
so DHCP clients can obtain IP addresses from authorized DHCP servers. A
trusted interface forwards DHCP messages it receives whereas an untrusted
interface discards DHCP ACK messages and DHCP Offer messages received
from a DHCP server.
An interface directly or indirectly connected to the DHCP server trusted by the
administrator needs to be configured as the trusted interface, and other
interfaces are configured as untrusted interfaces. This ensures that DHCP
clients only obtain IP addresses from authorized DHCP servers and prevents
bogus DHCP servers from assigning IP addresses to DHCP clients.
● IP source guard and dynamic ARP inspection (DAI)
Unauthorized users often send bogus packets with the source IP address and
MAC address of authorized users to access or attack the network. Then
authorized users cannot access stable and secure networks. To address this
problem, you can configure IP source guard. IP source guard prevents
unauthorized hosts from using IP addresses of authorized hosts or specified IP
addresses to access or attack the network.
You can configure DAI to defend against Man in The Middle (MITM) attacks,
preventing theft of authorized user information. When a device receives an
ARP packet, it matches the source IP address, source MAC address, VLAN ID,
and interface number of the ARP packet against binding entries. If a match is
found, the device considers the ARP packet valid and allows it to pass
through. Otherwise, the device discards the packet.
● Port isolation
You are advised to configure port isolation on the interfaces connecting the
access switch to terminals. This configuration secures user communication
and prevents invalid broadcast packets from affecting user services.
Note: If the connection type "terminal" is selected for a port during access
management configuration for the fabric, the port isolation function is
automatically configured on the port.
2.3.8.2.2 Access Layer (WLAN Access)

On a WLAN, service data is transmitted through radio signals. Such open channels
are vulnerable to service data eavesdropping and tampering during transmission,
such as rogue STAs, spoofing APs, and denial of service (DoS) attacks of malicious
terminals. As shown in Figure 2-149, WLAN security design covers the following
aspects:
● Air interface security: Identifies and defends against attacks such as rogue
APs, rogue STAs, unauthorized ad-hoc networks, and DoS attacks.

● STA access security: Ensures the validity and security of STAs' access to the
WLAN.
● Service security: Protects service data of authorized users from being
intercepted by unauthorized users during transmission.
Figure 2-149 WLAN security diagram
Air Interface Security Design

● To prevent intrusion of unauthorized devices or interference devices, enable
the Wireless Intrusion Detection System (WIDS) and Wireless Intrusion
Prevention System (WIPS) functions of the WLAN to detect and contain rogue
devices.
● Enable the WLAN spectrum analysis function to identify interference sources
on the network, locate them, and eliminate interference on the network.
The spectrum analysis architecture is composed of the spectrum sampling
engine, spectrum analyzer, and interference visualization module. The
function of each component is as follows:
– Spectrum sampling engine: Collects spectrum information on the WLAN
and forwards the information to the spectrum analyzer.
– Spectrum analyzer: Analyzes spectrum data, identifies interference
resource types, and sends the report on interference devices to the
interference visualization module.
– Interference visualization module: Displays interference resource
information in graphs, including real-time spectrum graphs.

Figure 2-150 Spectrum analysis system
● To prevent unauthorized attacks, you are advised to enable the illegal attack
detection function in public areas and student dormitories with high security
requirements to detect flood, weak-vector, and spoofing attacks,
automatically add attackers to the dynamic blacklist, and alert the
administrator through alarms.
STA Access Security Design

The STA access security solution is designed based on the combination of different
access authentication modes in NAC and WLAN security policies, and needs to
ensure both security and convenience. For example, in scenarios where users do
not need to communicate, it is recommended that user isolation be configured.
For details about the planning and design of STA access security, see "WLAN
Admission Design" in 2.2.5 WLAN Design.
Service Security Design

The wired network between APs and WACs also faces common security threats,
for example, interception, tampering, and spoofing, on IP networks. To improve
data transmission security, the CAPWAP tunnel between the WAC and AP supports
DTLS encryption, including:
● DTLS encryption for management packets in the CAPWAP tunnel
● DTLS encryption for service data packets in the CAPWAP tunnel
● Sensitive information encryption: When sensitive information is transmitted
between an AP and a WAC, the information can be encrypted to ensure
security. Sensitive information includes the FTP user name, FTP password, AP
login user name, AP login password, and service configuration key. The
sensitive information encryption function can also be configured to protect
data transmitted between WACs.
● Integrity check: When CAPWAP packets are transmitted between an AP and a
WAC, these packets may be forged, tampered with, or used by attackers to
construct malformed packets to launch attacks. Integrity check can protect
CAPWAP packets between the AP and WAC.
If the AP and WAC are both located on the internal network, this security
function does not need to be enabled. It is recommended that this function be
enabled when the AP is connected to the WAC across the Internet or the
WACs are located across the Internet.
2.3.8.2.3 Aggregation Layer

For the network security design at the aggregation layer, refer to 2.2.8.2.1 Access
Layer (Access Switch) if terminals are connected to the aggregation switch, and

refer to 2.2.8.2.4 Core Layer if the aggregation switch functions as the user
gateway or authentication point.
2.3.8.2.4 Core Layer

Core switches are located at key positions of the network, and thus the security of
core switches is crucial. When the core switch functions as a centralized
authentication point, its CPU performance must be able to support protocol
packet processing when a large number of users access the network. When the
core switch functions as a user gateway, ARP security must be considered.
To protect the CPU and ensure that the CPU processes and responds to normal
services, the core switch provides local attack defense functions. In the event of an
attack, these functions ensure uninterrupted service transmission and minimize
the impact of the attack on network services.
Local attack defense functions include CPU attack defense, attack source tracing,
port attack defense, and user-level rate limiting. By default, the core switch is
enabled with these functions.
● CPU attack defense
CPU attack defense enables the device to rate limit the packets sent to the
CPU within a specified period of time, protecting the CPU and ensuring
normal service processing.
The key to CPU attack defense is the Control Plane Committed Access Rate
(CPCAR). CPCAR limits the rate of protocol packets sent to the control plane
to ensure security of the control plane.
● Attack source tracing
Attack source tracing defends against denial of service (DoS) attacks. The
device enabled with attack source tracing analyzes packets sent to the CPU,
collects statistics about the packets, and specifies a threshold for the packets.
Excess packets are considered to be attack packets. The device finds the
source user address or source interface of the attack by analyzing the attack
packets and generates logs or alarms. Accordingly, the network administrator
can take measures to defend against the attacks or configure the device to
discard packets from the attack source.
● Port attack defense
Port attack defense is an anti-DoS attack method. It defends against attacks
based on ports and prevents protocol packets on ports from occupying
bandwidth and causing other packets to be discarded.
By default, port attack defense is enabled on the device for common user
protocol packets, such as ARP, ICMP, DHCP, and IGMP packets. If a user attack
occurs, the device restricts the attack impact within the port, reducing the
impact on other ports.
● User-level rate limiting
User-level rate limiting identifies users based on MAC addresses, and rate-
limits specified protocol packets, such as ARP, ND, DHCP Request, DHCPv6
Request, IGMP, 802.1X, and HTTPS-SYN packets. If a user undergoes a DoS
attack, other users are not affected. The core of user-level rate limiting is host
CAR. By default, user-level rate limiting is enabled.
When a switch functions as an access gateway, it receives a large number of ARP
packets requesting the interface MAC address of the switch. If all these ARP

Request packets are sent to the main control board for processing, the CPU usage
of the main control board will increase and other services cannot be processed
promptly.
The optimized ARP reply function addresses this issue. After this function is
enabled, the interface card directly responds to ARP requests if the ARP Request
packets are destined for the local interface of the switch, helping defend against
ARP flood attacks. This function is applicable to the scenario where a modular
switch is configured with multiple interface cards or fixed switches are stacked.
By default, the optimized ARP reply function is enabled on a switch. Do not

disable the function.
2.3.9 QoS Design
2.3.9.1 QoS Requirement Survey

Before deploying QoS, you must be familiar with various services as well as the
traffic model and QoS requirements of each service. In this way, QoS policies can
be correctly designed and QoS guarantee can be provided for each service. Table
2-80 describes the key points of QoS requirement survey.
Table 2-80 QoS requirement survey

irem
ent
Type
Netw Traffic models of various services and E2E Determine the network
ork forwarding paths of each service, including location where a QoS
statu forwarding paths in normal and abnormal policy is to be deployed.
s conditions
Bandwidth bottleneck points on the network Determine whether to

and interface bandwidth of each bandwidth adopt the QoS policy or
bottleneck point expand the network
capacity.
QoS Control services, multimedia services, and Understand traffic types

requi other important services that need to be and QoS requirements of
reme focused on each traffic type.
nts
Characteristics of various types of traffic that
can be identified by network devices. For
example, check whether voice traffic uses a
proprietary protocol such as the Session
Initiation Protocol (SIP) or H.323, whether
traffic is destined for or from a specific
interface of a specific server, and whether
traffic is from or destined for a specific host
network segment.


irem
ent
Type
Bandwidth requirements of important

services. For example, multimedia services
from different vendors at different bit rates
require different bandwidths so that the
audio or video services can be smoothly
transmitted.
Processing policies for different multimedia

applications. For example, for online videos,
some enterprises consider that online videos
on intranets need to be guaranteed and
work-irrelevant online videos on the Internet
do not need to be guaranteed.
2.3.9.2 Application Analysis Design
2.3.9.2.1 Application Identification and Experience Analysis

With the increasingly wide use of broadband networks, broadband data services
are developing rapidly. On the one hand, administrators need to learn about the
traffic usage of various applications on the network. On the other hand, certain
network control measures are needed, for example, ensuring that service flows of
mission-critical applications are processed preferentially and preventing resource
abuse. Therefore, the network needs to be able to support intelligent application
identification and allow for network policy control based on application
identification results.
Application Identification Technology

Smart Application Control (SAC) is an intelligent application identification and
classification engine. It detects and identifies Layer 4 to Layer 7 information in
packets as well as some protocols such as HTTP, FTP, and RTP. SAC is a basic
technology of service awareness (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. Signature identification
determines an application by detecting signatures in data packets. Signatures of
some protocols are contained in multiple packets, and therefore a device must
collect and analyze multiple packets to identify the protocol type. The system
analyzes traffic flowing through the device, and compares the analysis result with
the signature database file loaded on the device. It identifies an application by
detecting signatures in data packets, and performs further application quality
analysis and QoS policies based on the identification result.
Figure 2-151 shows the deployment position of the SAC function on a large or
midsize campus network. Application traffic of wired users is identified by access
switches, and that of wireless users is identified by APs.

Figure 2-151 Deployment positions of SAC on a large or midsize campus network
The applications that can be identified by the SAC function depend on the
signature database supported by a device. The device can accurately identify some
mainstream applications that are covered by its signature database.
However, private applications of enterprises are used in actual scenarios. If these
private applications are not covered by the signature database supported by the
device, the device cannot effectively identify these applications. In this case, you
can define application identification rules to identify private applications based on
key 5-tuple or URL information. The following figure is an example of customizing
an application identification rule.
NOTE
● If user-defined rules conflict with the rules in the signature database, the device uses
the user-defined rules for application identification.

Application Experience Analysis

Network services are provided for applications. You can better optimize the
network only by learning about the experience of applications. Application
experience analysis uses eMDI technology to collect statistics on KPIs (packet loss,
delay, and jitter) of 5-tuple flows of applications and calculate the MOS based on
the KPIs. Currently, only UDP or RTP applications (packet loss and jitter can be
calculated, but delay cannot be calculated) and TCP applications (packet loss and
delay can be calculated, but jitter cannot be calculated) are supported. According
to RFC 4594, the requirements on packet loss, delay, and jitter vary with different
application types. Therefore, different MOS values are calculated.
● Application experience analysis based on application identification
You can enable application experience analysis for a specified application based on
the SAC signature database or user-defined rules. As shown in Figure 2-152,
application experience analysis can be deployed only on edge interfaces of access
switches and on APs. If APs are connected to access switches, application
experience analysis must be deployed on APs.
Figure 2-152 Deployment of application experience analysis on a large or midsize

campus network
● Application experience analysis based on security groups and applications


and surrounding places) at key moments (such as exams). In this case, experience
analysis based on application identification mentioned above cannot meet the
requirements, because the specifications may be insufficient to support experience
analysis for all key applications. To this end, experience analysis based on security
groups or both security groups and applications is provided. Security groups are
used to authorize authenticated users based on 5W1H, so that information
including user identities, access locations (switches the users connect to), and
access time can be identified.
NOTE

● Hop-by-hop fault demarcation based on 5-tuple information
If experience exceptions are detected on applications with fixed IP addresses (for
example, locally deployed applications), iPCA 2.0 can help perform end-to-end in-
band flow measurement for fault demarcation. In traditional iPCA, to perform
measurement for all flows sent to a server on a per-flow basis, you need to
configure the 5-tuple information of each flow separately. By contrast, iPCA 2.0
requires only two configurations: one any-to-server DIP rule configured for
upstream flows, and the other server SIP-to-any rule for downstream flows. Then,
a 5-tuple flow table is automatically generated for each flow that matches either
of the two rules for further iPCA 2.0 measurement.
iPCA 2.0 uses the color bit (bit 0 in the IP Flags field is recommended) to measure
packet loss and delay.
As shown in Figure 2-153, iPCA 2.0 defines three types of measurement points: in-
point, out-point, and mid-point. The in-point is used for coloring and
measurement, the out-point for decoloring and measurement, and the mid-point
for measurement. For a bidirectional flow, the upstream (terminal-to-server) and
downstream (server-to-terminal) traffic on the same interface of a device passes
through the in-point and out-point, respectively. iPCA 2.0 needs to be configured
on the interfaces through which all flows may pass.

Figure 2-153 Deployment of fault demarcation based on 5-tuple information on a

large or midsize campus network
NOTE
The preceding figure shows only the monitoring of traffic in one direction. The monitoring
of traffic in the other direction needs to be configured in the reverse direction using the
same logic.
iPCA 2.0 depends on time synchronization of NTP and supports only two-way delay
measurement, which requires that the upstream and downstream flows be transmitted
along the same path.
iPCA 2.0-based delay measurement is inaccurate in the presence of out-of-order packets.
cards support delay measurement.
iPCA 2.0 is not applicable to multicast scenarios.
● Fault demarcation based on application identification

Regarding applications without fixed IP addresses, for example, SaaS applications
like Tencent Meeting and DingTalk, 5-tuple information cannot be configured for
iPCA 2.0 fault demarcation. In this case, the iPCA 2.0 function based on application
identification is required.

Figure 2-154 Deployment of fault demarcation based on application identification

on a large or midsize campus network
As illustrated in the preceding figure, when deploying iPCA 2.0, you are advised to
specify mid-points and out-points in advance and enable AutoDetect on them. In
this way, when adding an application flow measurement task, you only need to
specify the application name on in-points, but not on mid-points or out-points.
Application identification must be deployed on the node where the in-point for
flow measurement resides. In this manner, application identification data can be
used to associate an application name with 5-tuple information, which is then
used for traffic matching.
Without application identification data, the nodes where the mid-point and out-
point reside need to automatically identify the packets to be measured and trigger
flow creation and measurement based on the packets colored by the node where
the in-point resides.
If two-way measurement is performed on the node where the out-point resides,
the received reverse flow is not colored because no application identification data
is available. The 5-tuple information in the reverse flow can be obtained only
based on the forward flow. After such information is obtained, the ACL is
automatically delivered for a 5-tuple match and trigger flow coloring, creation,
and measurement.
The colored reverse flow is processed in the same way as the forward flow.
Subsequent nodes identify the color bit in the flow to trigger flow creation and
measurement.

Nodes enabled with AutoDetect can provide sufficient entry resources to

implement automatic in-band flow measurement only after the resource mode of
the nodes is switched to iPCA. In this mode, the number of IPv4/IPv6 dual-stack
STAs on a fabric cannot exceed 30,000.
NOTE
The fault demarcation capability based on application identification can be used only for
long flows. The duration of a long flow must be longer than two iPCA 2.0 reporting periods.
As the minimum reporting period can be set to 10 seconds, only flows with longer than 20-
second duration can be displayed on the analyzer.
cards support fault demarcation based on application identification.
The application identification and traffic statistics collection functions cannot be configured
on a switch interface where iPCA 2.0 is configured. Therefore, the in-point can be
configured only on the uplink interface. As a result, packet loss on access switches cannot
be detected.
Other constraints are the same as those for 5-tuple-based fault demarcation.
● Hop-by-hop fault demarcation based on security groups and applications
and surrounding places) at key moments (such as exams). In this case, fault
demarcation based on application identification mentioned above cannot meet
the requirements, because the specifications may be insufficient to support fault
demarcation for all key applications. To this end, fault demarcation based on
security groups or both security groups and applications is provided. Security
groups are used to authorize authenticated users based on 5W1H, so that
information including user identities, access locations (switches the users connect
to), and access time can be identified.
NOTE
2.3.9.2.2 Precautions for Co-deployment of Application Experience Analysis and

If the application fault demarcation function needs to be deployed together with
the application experience analysis function on a switch, the application fault
demarcation function can be deployed only on the uplink ports of the switch
because the two functions are mutually exclusive on the switch port. In addition,
tunnel packets can only be measured based on inner 5-tuples and cannot be
colored or decolored. Therefore, the VXLAN tunnel-side interface cannot be
configured as an iPCA 2.0 in-point. Also, in the scenario where VXLAN is deployed
across core and access layers, wired user traffic does not support co-deployment
of application experience analysis and application fault demarcation. Figure 2-155
shows the deployment positions of application experience analysis and application
fault demarcation in the scenario where VXLAN is deployed across core and
aggregation layers.

Figure 2-155 Co-deployment positions of application experience analysis and

application fault demarcation on a large or midsize campus network
2.3.9.3 Traffic Classification Design

Services carried on a large or midsize campus network include voice, video, and
data services and network protocol control signaling required for transmitting
service data. QoS indicators of various services include the bandwidth, packet loss
rate, latency, and jitter. Bandwidth can be controlled by configuring parameters,
but packet loss rate, latency, and jitter cannot. In practice, QoS is deployed based
on engineering experience, as shown in Table 2-81.
Table 2-81 Features and QoS requirements of common services

e ket enc er
Categ Los y Tol
ory s Tol era
Tol era nce
era nce
nce
Netwo Link-layer loop prevention protocols for network Low Lo Per

rk interconnection and interoperability, routing w mit
protoc protocols, and multicast group management
ol protocols, such as STP, OSPF, and IGMP.


e ket enc er
Categ Los y Tol
ory s Tol era
Tol era nce
era nce
nce
Manag Protocols used by network administrators for Low Lo Per

ement monitoring network devices, delivering w mit
protoc configurations, and diagnosing faults, for example,
ol ICMP, SNMP, Telnet, and XMPP.
VoIP Real-time voice calls over IP networks. The network Ver Ver Ver
data must provide low latency and low jitter to ensure y y y
flow service quality. low low low
Voice Signaling protocols for controlling VoIP calls and Low Lo Per
signali establishing communication channels, for example, w mit
ng SIP, H.323, H.248, and Media Gateway Control
Protocol (MGCP).
Signaling protocols have a lower priority than VoIP
data flows because call failure is often considered
worse than intermittent voices.
Multi Multiple parties can share camera feeds and screens Low Ver Lo
media over IP networks. Protocols or applications can or y w
confer adapt to different network quality levels by me low
encing adjusting the bitrate (image definition) to ensure diu
the smoothness. m
Gamin The network is required to provide online interactive Low Ver Lo

g applications with low packet loss rate, latency, and y w
jitter to ensure fast and accurate response during low
gaming. For example, online games that transmit
operation instructions through RTP or UDP pose
higher requirements on the network.
Strea Online audio and video streaming. Audio and video Low Me Per
ming programs are made in advance and then cached on or diu mit
media local terminals before being played. Therefore, the me m
requirements on the network latency, packet loss, diu
and jitter are reduced. m
Online Unlike streaming media, data of online live Ver Me Lo

live broadcast is sent and received in real time. Though y diu w
broadc terminals provide the cache mechanism, the low m
ast network is required to provide the low packet loss
rate and jitter to meet real-time requirements and
ensure good experience.


e ket enc er
Categ Los y Tol
ory s Tol era
Tol era nce
era nce
nce
Delay- Data services that are sensitive to delay. For Low Lo Per
sensiti example, long delay on an online ordering system w mit
ve may reduce the revenue and efficiency of or
data enterprises. me
service diu
s m
Bandw Network services that involve the transmission of a Low Me Per

idth- large amount of data for a long period of time, such diu mit
intensi as File Transfer Protocol (FTP), database backup, m
ve and file dump. or
service hig
s h
Comm Basic services that have no special requirements on No No No

on enterprise networks, such as email and web req req req
service browsing. uire uire uire
s me me me
nt nt nt
Low- Services that are not important to enterprises, such Hig Hig Per
priorit as social network and entertainment applications. h h mit
y
service
s
2.3.9.4 QoS Scheduling Policy Design

You are advised to design traditional QoS scheduling policies respectively for wired
networks and WLANs. The design for WLANs focuses on policies related to STA
services.
For details about user- and application-based scenario-specific QoS scheduling

policy design, see section "Intelligent HQoS Design."
2.3.9.4.1 QoS Scheduling Policy Design for Wired Networks

The basic principle of traditional QoS design for wired networks is to mark or re-
mark packets at boundaries of different DiffServ domains and perform bandwidth
control. Devices in the same DiffServ domain only need to schedule packets in
queues based on the priorities marked on boundary nodes. Typically, service
deployment involves traffic identification at the access layer, DiffServ model
deployment at the aggregation or core layer, and bandwidth control on egress
firewalls.

● Traffic identification at the access layer

Access switches function as boundary switches. The switches identify, classify,
and mark data flows at the user side. In actual deployments, different
interfaces on access switches are connected to different terminals. Different
priorities can be allocated to different services on access switches. Then traffic
of the services can be scheduled based on the priorities.
● DiffServ model deployment at the aggregation or core layer
Interfaces on aggregation and core switches are configured to trust DSCP or
802.1p priorities and enforce QoS policies based on priorities marked at the
access layer, to ensure that high-priority services are scheduled first. A switch
interface trusts 802.1p priorities by default.
● Bandwidth control on egress devices
Egress devices are also located in the DiffServ domain and are configured to
trust DSCP or 802.1p priorities of packets and implement QoS policies. Due to
egress bandwidth limits, you need to consider differences when setting
bandwidth parameters for WAN interfaces of egress devices. Additionally, QoS
policies of egress devices vary according to the enterprise WAN construction
mode.
– WAN QoS policies can be managed by an enterprise itself in the
following scenarios: enterprise-built WAN, private line construction using
leased fibers, and customized enterprise QoS policies applied to the
carrier WAN. In this case, egress or PE devices on the campus network do
not need to re-mark traffic.
– The WAN QoS policies are not controlled by an enterprise itself. The
enterprise leases the private line network of a carrier, and the carrier
does not trust the packet marking on the enterprise network or the two
parties have different definitions of the same packet marking. Thus,
egress devices on the campus network need to re-mark traffic.
2.3.9.4.2 QoS Scheduling Policy Design for WLANs

The network efficiency of WLANs is lower than that of wired networks, and STAs
are more sensitive to user experience. Therefore, you are advised to consider the
following aspects when designing the QoS policies for STAs:
● The maximum bandwidth of a single user can be limited based on service

requirements. If multiple SSIDs are planned, the total bandwidth of non-
critical SSIDs can be limited.
● In high-density scenarios, many users preempt channel resources. As a result,
the Internet access quality of each user deteriorates. You are advised to
enable the following functions:
– The call admission control (CAC) function is used to control STA access
based on the radio channel utilization and number or signal-to-noise
ratio (SNR) of online STAs to ensure the Internet access quality of online
STAs.
– The dynamic enhanced distributed channel access (EDCA) parameter
adjustment function allows APs to adjust EDCA parameters flexibly by
detecting the number of STAs to reduce the possibility of collisions,
improve the throughput, and enhance user experience.

● To enable STAs (especially sticky STAs) to re-associate or roam to APs with

better signals, enable the function of quickly disconnecting STAs to force low-
SNR or low-rate STAs to go offline.
● In scenarios requiring high multicast service experience, you are advised to
enable the multicast-to-unicast conversion function to improve multicast
service experience (for example, HD video on demand) to prevent the impact
of low-rate STAs on multicast services.
● In scenarios where VIP user experience needs to be guaranteed, you are
advised to enable preferential access of VIP users to ensure preferential
access, scheduling, and bandwidth guarantee for VIP users.
In WLAN QoS design, you need to consider priority mapping between wired and
wireless network packets. For example, 802.11 packets sent by WLAN clients carry
user priorities or DSCP priorities, VLAN packets on wired networks carry 802.1p
priorities, and IP packets carry DSCP priorities. To ensure consistent QoS
scheduling of packets on wired and wireless networks, you need to configure
priority mapping on network devices.
NOTE
Only 802.11ax (Wi-Fi 6) APs support bandwidth guarantee.
2.3.9.4.3 Recommended Scheduling Policy Suggestions

The definition of important data services varies with enterprises. For a portal
website, Internet access and gaming traffic is important; for the financial services
industry, real-time transaction is more important than voice services and Internet
access and gaming traffic is unwanted. Therefore, the QoS policy solution must be
designed and deployed based on actual service types and QoS requirements of
each enterprise. Table 2-82 lists the typical QoS policy solutions formulated based
on engineers' experiences, which provide references for design personnel.
Table 2-82 Scheduling model design suggestions

y) Algorit Bandwid
hm th
Signaling ● Routing protocol CS6 6 PQ Unlimite

and control ● NMS, multimedia, and d
signaling protocols
Real-time ● VoIP EF 5 PQ Available

interactive ● Multimedia interface
multimedia conferencing bandwidt
h x 30%
● Online gaming
● Desktop cloud


y) Algorit Bandwid
hm th
On- ● Online video EF 4 DRR Unlimite

demand ● Video live broadcast or weight: d
subscriptio multicast 20
n of
multimedia ● Delay-sensitive and
or key mission-critical
services enterprise services, such
as ERP and online
ordering systems
Other ● Common Internet BE 0 DRR Unlimite

services access services such as weight: d
email and web 20
browsing
2.3.10 Reliability Design
2.3.10.1 Device Reliability
2.3.10.1.1 Switch Reliability Design

Two or more fixed switches can be virtualized into one logical switch using
stacking technology, whereas two modular switches can be virtualized into one
logical switch using clustering technology. When the master member switch in a
stack or Cluster Switch System (CSS) fails, the backup member switch takes over
all the services without interrupting services. On a large or midsize campus
network, deploying switches using the stacking or clustering technology is
recommended for higher reliability. The stacking or clustering technology has the
following advantages:
● Improving reliability
Member switches in a stack or CSS work in redundancy mode. In Figure
2-156, two modular core switches Switch A and Switch B set up a CSS and
back up each other. In the event of a failure on Switch A, Switch B takes over
services from Switch A to ensure service continuity.

Figure 2-156 Improving reliability
● Increasing the number of ports

As demonstrated in Figure 2-157, if the port density of the original switch
cannot meet the access requirements of users, you can set up a stack by
attaching new switches to the original switch to increase the number of ports.
Figure 2-157 Increasing the number of ports
● Simplifying the network topology

In Figure 2-158, two switches at each network layer set up a stack or CSS,
which is similar to a single logical device. Eth-Trunks are used between stacks
and between a stack and a CSS. Such deployment approach increases link
bandwidth and reliability, and avoids using loop prevention protocols such as
MSTP. On a Layer 3 network, members in a stack or CSS share one routing
table. This shortens the route convergence time upon a network fault and
makes it easy to manage, maintain, and expand a network.

Figure 2-158 Simplifying the network topology
2.3.10.1.2 WAC Reliability Design

If switches with the native WAC function serve as WACs, the clustering or stacking
technology is used to ensure the WAC reliability. If standalone WACs are used, you
are advised to deploy them in HSB mode to improve the WAC reliability. In HSB
mode, there are two devices, one acting as the active and the other the standby.
The active device forwards services and the standby device monitors the
forwarding. In addition, the active device sends the standby device the status
information and information that needs to be backed up in real time. In the case
that the active device becomes faulty, the standby device takes over services. As
shown in Figure 2-159, two standalone WACs working in HSB mode are
connected to the core switches that set up a CSS in off-path mode. The Eth-Trunks
between the WACs and core switches work in active/standby mode. When the
active WAC fails, the standby WAC takes over services to forward WLAN packets.

Figure 2-159 Deploying WACs in HSB mode
2.3.10.1.3 Firewall Reliability Design

When firewalls function as egress devices, you are advised to deploy HSB to
improve firewall reliability. As illustrated in Figure 2-160, the firewalls act as
egress devices of the campus network and are directly connected to the stacked
core switch. The two firewalls are configured to work in HSB mode, and the
member links in their interconnected Eth-Trunk are in active/standby mode. When
the active firewall is faulty, the standby firewall takes over services and forwards
service packets.
2.3.10.2 Link Reliability

On a campus network, two uplinks are usually used to improve the reliability of
links between devices. In addition, for redundant links, Link Aggregation Control

Protocol (LACP) is commonly used to virtualize multiple physical links into a

logical Eth-Trunk. The interfaces on the Eth-Trunk are called Eth-Trunk interfaces.
As shown in Figure 2-161, link aggregation has the following advantages:
● Increasing bandwidth: The maximum bandwidth of a link aggregation group
(LAG) is the sum of bandwidth of the member interfaces in the LAG.
● Improving reliability: When an active link fails, the traffic carried over this
failed link is switched to another functional active link, improving LAG
reliability.
● Achieving load balancing: In a LAG, traffic is load balanced among all
functional active links.
Figure 2-161 Eth-Trunk networking
2.3.10.3 Multi-Border Node Reliability

When the distributed gateway solution is used to deploy a virtual network,
multiple border nodes can be deployed to improve the reliability of the core layer.
The deployment of two border nodes is used as an example to describe the design
of the multi-border node solution.
Figure 2-162 Ring networking for multiple border nodes

NOTE
● In the multi-border node scenario, border nodes can be deployed in ring networking
mode, as described in Figure 2-162. If a non-border node exists on a ring network, the
non-border node cannot function as an external gateway to connect to the external
network.
● In the multi-border node scenario, only two border nodes can share the same egress.
2.3.10.3.1 Networking Design

Figure 2-163 shows the recommended dual-border node networking in
distributed VXLAN gateway scenarios.
Figure 2-163 Dual-border node networking in distributed VXLAN gateway

scenarios
The following table describes the recommended networking modes depending on

the zone or devices connected to the border nodes.
Zone or Recommende Recommended Reliability Technologies

Devices d Networking
Connected to Mode
Border Nodes
Egress zone Dual-homed It is recommended that egress devices be

(firewall/ networking deployed in VRRP HSB mode. You can
router) configure multiple VRRP groups to
implement load balancing. The forward and
return paths of traffic may be inconsistent
when firewalls work in load balancing mode,
which may affect the security check
performance of the firewalls. To prevent this
problem, you can configure the firewalls to
work in active/standby mode.

Zone or Recommende Recommended Reliability Technologies

Devices d Networking
Connected to Mode
Border Nodes
Network Dual-homed It is recommended that switches in the

management networking network management zone be stacked and
zone (server with Layer 3 dual-homed to core switches to implement
zone) switches ECMP load balancing.
Standalone Single-homed It is recommended that the WACs be

WAC networking deployed in VRRP HSB mode.
Aggregation Dual-homed It is recommended that the aggregation

switch in a networking switches be stacked and dual-homed to core
fabric switches to implement ECMP load balancing.
NOTE
● In distributed VXLAN gateway scenarios, if wireless traffic is forwarded in a centralized

manner, it is recommended that border nodes be used as wireless service gateways. In
this case, the standalone WACs working in HSB mode cannot be deployed in dual-
homed networking mode, and a standalone WAC cannot be dual-homed to two border
nodes.
● In a distributed gateway scenario where two border nodes used as WACs are deployed,
the CAPWAP tunnels between Fit APs and WACs do not support dual-link cold backup.
● It is recommended that Eth-Trunks be deployed between the border nodes and between
the border nodes and edge nodes. This prevents long traffic forwarding paths when link
faults occur between the edge nodes and border nodes.
● Modify the configuration of rate limiting for ARP Miss messages based on source IP
addresses on the core switch. You are advised to change the rate limit to at least 100
ARP Miss messages per second and set the processing mode to none-block. (The rate
limit can be configured based on the number of APs and heartbeat timeout period.)
This prevents APs from going offline due to rate limiting for ARP Miss messages during
switchover of core switches.
In the scenario where distributed VXLAN gateways are deployed and 802.1X users
go online in batches, you are advised to configure CAR for protocol packets
according to Table 2-84 to prevent the impact of excess user login on the network
and ensure network reliability.
(1) IPv4 services only: You are advised to perform configurations to allow a
maximum of 150 users (recommended: 60 wired users and 90 wireless users) to
go online per second. The numbers of users can be configured according to the
service requirements on the live network.
(2) IPv4/IPv6 dual-stack services: You are advised to perform configurations to
allow a maximum of 100 users (recommended: 40 wired users and 60 wireless
users) to go online per second. The numbers of users can be configured according
to the service requirements on the live network.

Table 2-83 Calculating CAR values in the concurrency scenario

Scenario Single-Stack Dual-Stack Scenario
Scenario
DHCPv4 (kbit/s) DHCPv4 (kbit/s) DHCPv6 (kbit/s)
CAR on a core 400 x 8 x 400 x 8 x 180 x 8 x

switch Concurrent Concurrent Concurrent
onboarding rate/ onboarding rate/ onboarding rate/
1000 (The result 1000 (The result 1000 (The result
is rounded up.) is rounded up.) is rounded up.)
CAR on an 400 x 8 x 400 x 8 x 180 x 8 x

aggregation Concurrent Concurrent Concurrent
switch onboarding rate/ onboarding rate/ onboarding rate/
1000 (The result 1000 (The result 1000 (The result
is rounded up.) is rounded up.) is rounded up.)
Table 2-84 Recommended CAR configurations in the concurrency scenario

Sc Border Nodes Serving as Gateways Edge Nodes Serving as
en Gateways
ari
o Main Control LPU Main Control LPU
Board Board
Sin cpu-defend policy cpu-defend policy cpu-defend cpu-defend

gle main_car lpu_car policy main_car policy lpu_car
- car packet-type car packet-type car packet-type car packet-
sta dhcp-request-first dhcp-request-first dhcp-request- type dhcp-
ck cir 480 cir 240 first cir 128 request-first
sce cir 64
nar cpu-defend-policy cpu-defend-policy cpu-defend-
io main_car lpu_car global policy main_car cpu-defend-
policy lpu_car
global
Du cpu-defend policy cpu-defend policy cpu-defend cpu-defend

al- main_car main_car policy lpu_car policy
sta car packet-type car packet-type car packet-type main_car
ck dhcp-request-first dhcp-request-first dhcp-request- car packet-
sce cir 192 cir 192 first cir 96 type dhcp-
nar request-first
io car packet-type car packet-type car packet-type
dhcpv6-request- dhcpv6-request- dhcpv6-request- cir 128
first cir 145 first cir 145 first cir 73 car packet-
cpu-defend-policy cpu-defend-policy cpu-defend- type dhcpv6-
main_car main_car policy lpu_car request-first
global cir 58
cpu-defend-
policy
main_car

2.3.10.3.2 Deployment Design
Context
On a large or midsize campus network, core switches are managed by the
controller using commands. It is recommended that aggregation and access
switches be managed in DHCP mode and WACs go online using commands. The
following describes the precautions for the deployment of aggregation/access
switches and WACs in the dual-border node scenario. For other details, see 2.3.3.2
Deployment Design.
Precautions for Deploying Aggregation and Access Switches

As described in 2.3.3.2 Deployment Design, in a scenario where dual core
switches (Border_1 and Border_2) are deployed, the core switches function as
DHCP servers on the management network. To ensure DHCP service reliability, it is
recommended that both core switches function as DHCP servers on the
management network. Therefore, you need to configure a VRRP group for the
core switches based on the auto-negotiated management VLAN subnet, as shown
in Figure 2-164. The address pool of the management subnet needs to be evenly
divided into three parts: a DHCP address pool for the management VLAN subnet
of Border_1, a DHCP address pool for the management VLAN subnet of Border_2,
and a static management address pool for the aggregation/access switches. Table
2-85 lists the subnet planning for management VLANs.
Figure 2-164 VRRP group for dual core switches based on the auto-negotiated
management VLAN subnet

Table 2-85 Subnet planning for management VLANs

D Auto Subnet IP IP DH Con Reserve Stat Static IP
ev - Name Obta Addre CP troll d IP ic Address
ic neg ining ss er Address Man Range
e otiat Mod Add age
ed e ress men
Man Aut t IP
age o- Add
men neg ress
t otia for
VLA tion Swit
N ches
Co 4080 Manag Manu 192.16 DH ON 192.168. ON 192.168.

re e_Net al 8.100. CP 100.2– 100.87–
_1 1/24 serv 192.168. 192.168.
er 100.3 100.169
mo 192.168.
de 100.170–
192.168.
100.252
Co 4080 Manag Manu 192.16 DH ON 192.168. OFF -

re e_Net al 8.100. CP 100.1–
_2 3/24 serv 192.168.
er 100.2
mo 192.168.
de 100.4–
192.168.
100.169
It is recommended that full-mesh networking be used between two core switches,

an Eth-Trunk be created, and interconnected interfaces be added to the auto-
negotiated management VLAN. In this case, a Layer 2 loop occurs in the auto-
negotiated management VLAN between the core switches and aggregation
switches. It is recommended that VLAN-based Spanning Tree (VBST) be configured
on the core switches and aggregation switches to prevent the loop and the core
switches be configured as the primary and secondary root bridges for the auto-
negotiated management VLAN, as shown in Figure 2-165. Plan the loop blocking
point on the interconnection link between core switches.

Figure 2-165 Layer 2 loop on the auto-negotiated management VLAN between

dual core switches
The core devices function as the gateways of the management network to

communicate with various servers (such as iMaster NCE-Campus and iMaster
NCE-CampusInsight) in the network management zone at Layer 3. The following
uses iMaster NCE-Campus as an example. If the route between core switch 1 and
iMaster NCE-Campus is unreachable, you need to switch the VRRP master/backup
status of the management VLAN so that NEs can connect to iMaster NCE-Campus
through other core switches. Therefore, it is recommended that the VRRP group of
the auto-negotiated management VLAN be associated with the route of the
network management zone.
Precautions for Deploying WACs

In the dual-border node scenario, two standalone WACs are deployed in VRRP HSB
mode to improve reliability. Figure 2-166 shows a networking example: two WACs
back up data and services through VLANIF 4021.
Figure 2-166 Networking plan for deploying WACs in HSB mode
In the dual-border node scenario, standalone WACs are connected to core switches
in off-path mode, and the single-homed networking is used. The WACs are
brought online using commands, management gateways are deployed on the core
switches, and VRRP is used to enhance reliability. When deploying VRRP on the
management gateways, you need to associate the VRRP group with the uplink
route to the southbound network segment of the network management zone.
Figure 2-167 shows a networking example. For details about how to prevent a
Layer 2 loop on a single-homed network, see Precautions for Deploying
Aggregation and Access Switches.

Figure 2-167 Networking plan for deploying WACs in the dual-border node
scenario
Fit AP Deployment Design

In the dual-border node scenario, management VLANs of APs are assigned based
on uplink aggregation switches. In this scenario, deploy auto-negotiated
management VLANs for wireless devices on aggregation switches, and establish
Layer 2 links between Fit APs and aggregation switches through the PnP VLANs as
well as the Layer 2 links between aggregation and core switches one after the
other through the controller. Gateways of management subnets for wireless
devices are deployed on the core switches. To deploy DHCP servers on the core
switches and configure VRRP for them, refer to the deployment of gateways on
aggregation/access switches. For details about how to prevent a Layer 2 loop in
the dual-homed networking at the aggregation layer, see Precautions for
Deploying Aggregation and Access Switches.
Figure 2-168 shows an example of Fit AP deployment:
1. VLAN 4030 and VLAN 4031 are planned as the auto-negotiated management
VLANs for APs connected to the aggregation switch Aggre_1 and APs
connected to the aggregation switch Aggre_2, respectively. In this way,
aggregation switches can communicate with the connected APs.
2. The interfaces belong to the wireless management VLANs between
aggregation and core switches are configured one by one to allow packets
from the VLANs to pass through.
3. The gateways of management subnets for Fit APs are deployed on the core
switches, VRRP is configured to improve the gateway reliability, and DHCP
servers are deployed on the interfaces of the core switches to dynamically
assign management IP addresses to the Fit APs. For details about address
pool planning, see Precautions for Deploying Aggregation and Access
Switches.

4. The VLANIF 4023 interfaces on the WACs are the CAPWAP source interfaces.
In the WAC hot standby scenario, a VRRP group needs to be configured on
VLANIF 4023 with WAC_1 being the master device.
5. The core switches communicate with the WACs at Layer 3 through VLANIF
4024 and VLANIF 4025 respectively. The routes destined for the network
segments where the CAPWAP source interface addresses reside need to be
configured on the core switches, and the routes to the network segments
where the gateways of the Fit AP management subnets reside need to be
configured on the WACs.
6. The master device of the VRRP group is associated with the uplink route to
the network segment of the WAC CAPWAP source interface address.
Figure 2-168 Networking plan for deploying Fit APs
2.3.10.3.3 Automatic Underlay Route Orchestration Design

As described in 2.3.3.3 Automatic Intranet Route Orchestration Design, the
underlay route orchestration in the dual-border node scenario can be classified
into single-area or multi-area orchestration, as shown in Figure 2-169.

Figure 2-169 Route orchestration in the dual-border node scenario
The following table describes recommended application scenarios of each route

orchestration mode.
Route Description Recommended Application Scenario

Orche
stratio
n
Mode
Single- All edge devices and The number of edge devices is less than
area connected devices in the or equal to 100.
upstream direction are
assigned to Area 0.
Multi- The interconnection The number of edge devices is greater

area interfaces between the two than 100.
core switches are assigned
to Area 0. The upstream and
downstream interconnection
interfaces of each
aggregation switch are
assigned to an independent
area.
To enhance reliability of OSPF, you are advised to enable the functions described
in the following table.

Functi Description
on
Associa OSPF periodically sends Hello packets to neighbors to detect faults,

tion which takes more than 1s. BFD for OSPF can rapidly detect the link
with status and complete fault detection in milliseconds. BFD for OSPF
BFD speeds up OSPF convergence when the link status changes.
FRR OSPF IP FRR calculates a backup link in advance. With this function,
devices can fast switch traffic to the backup link without interrupting
traffic if the primary link fails. This protects traffic and thus greatly
improves OSPF network reliability.
Gracef GR can be enabled to prevent route flapping caused by a traffic

ul interruption or active/standby switchover. This speeds up OSPF
restart convergence and maintains a stable network topology.
(GR)
2.3.10.3.4 Fabric Network Design
Context
In the distributed gateway solution, northbound traffic forwarding from edge
nodes to border nodes on the overlay network and BGP configuration vary
depending on dual-border node networking and single-border node networking
scenarios, which are described as follows. For other information, see 2.3.4.3 Fabric
Network Design.
Egress Traffic Forwarding Mode Design from Edge Nodes to Border Nodes
On a fabric network with dual border nodes deployed in the distributed gateway
solution, it is recommended that the dual-homed networking be used between
core and aggregation devices so that Layer 3 VXLAN tunnels are established
between the border nodes and edge nodes. In this scenario, three solutions are
available to improve the reliability of egress traffic:
● Provide two uplink traffic paths of the edge node to implement ECMP-based
load balancing.
● Select different active egresses for different edge devices.
● Select different active egresses for different uplink network segments.
Figure 2-170 shows the overlay traffic forwarding path in the dual-border node
networking scenario.

Figure 2-170 Overlay traffic forwarding path in the dual-border node networking
scenario
You are advised to deploy two uplink traffic paths of the edge node to implement
ECMP load balancing. You can select the other two solutions based on service
requirements.
BGP Design on the Fabric Network

When deploying a virtual network, you are advised to configure core switches as
BGP route reflectors (RRs) to prevent unnecessary performance consumption
caused by full-mesh configuration between edge nodes. In the dual-border node
networking scenario, if there are multiple core switches, you are advised to
configure a BGP RR cluster to further improve BGP network reliability, as shown in
Figure 2-171.
Figure 2-171 BGP design on the fabric network
2.3.10.3.5 Multicast Overlay Network Design

Layer 2 multicast deployment on the overlay network. As described in 2.3.4.5

Multicast Overlay Service Design, when a border device is connected to a Layer

3 multicast device that is not enabled with IGMP, you need to configure the
interface connecting the border device to the Layer 3 multicast device as a static
router port to ensure that IGMP Report/Leave messages can be forwarded to the
upstream Layer 3 multicast device. In addition, you need to specify the border
node as an IGMP snooping querier. In the multi-border node scenario, perform the
following operations to improve reliability:
● When the multicast source is on a fabric network and is connected to two
border nodes, configure all border nodes as IGMP snooping queriers. This
ensures that the querier is available on the Layer 2 multicast network if a
border node fails, thus improving multicast network reliability.
● When a multicast server is connected to two border nodes through an
intermediate network device, dual links in active/standby mode need to be
deployed on the intermediate network device. This prevents multicast traffic
from entering the same BD through the two border nodes, and also prevents
two copies of multicast traffic from being transmitted on the overlay network.
Reliability technologies, including Smart Link, Ethernet Ring Protection
Switching (ERPS), and Smart Ethernet Protection (SEP), can be used based on
the capabilities of the intermediate network device. You are advised to use
Smart Link to configure the two links in active/standby mode. If ERPS is used,
the port on one link needs to be specified as the RPL owner port. If SEP is
used, interfaces connected to border nodes need to be specified as primary
and secondary edge interfaces that do not have neighbors.
2.3.11 O&M Design
2.3.11.1 Basic Network O&M Design

In the virtualization solution for a large or midsize campus network, iMaster NCE-
Campus provides comprehensive basic network management, NE management,
service management, and system management functions for managed devices.
These functions include user, log, resource, topology, alarm, and performance
management. In addition, common protocols used in traditional network O&M
can be delivered to network devices through iMaster NCE-Campus or applied on
iMaster NCE-Campus, as shown in Table 2-86. iMaster NCE-Campus provides
comprehensive basic network management for managed devices to meet basic
customer network O&M requirements. Table 2-87 describes the major basic
network O&M functions supported by iMaster NCE-Campus.
Table 2-86 Common protocols used in traditional network O&M that can be
configured on iMaster NCE-Campus

col
SNMP ● Configures interconnection between network devices and an SNMP

server.
● Manages traditional devices through SNMP. Traditional devices refer
to network devices that are not NETCONF capable.


col
NTP Configures interconnection between network devices and an NTP

server.
Syslog ● Configures interconnection between iMaster NCE-Campus and a

syslog server. After the configuration, iMaster NCE-Campus uploads
the logs obtained from network devices to the syslog server.
● Configures interconnection between network devices and a syslog
server.
SSH ● Configures local accounts for login over SSH on network devices.
● Logs in to the CLI of a network device from iMaster NCE-Campus
using SSH.
LLDP Enables LLDP on network devices. This function is enabled on iMaster

NCE-Campus by default. iMaster NCE-Campus can also learn the
network topology information through LLDP.
Table 2-87 Basic network O&M functions supported by iMaster NCE-Campus

Function
Basic ● Monitors the basic status of sites, devices, and terminals, such
service as the online rate, CPU usage, and memory status of devices at
monitoring a site.
● Provides traffic statistics analysis and reports from multiple
dimensions (site, terminal, application, and SSID).
● Monitors user information, including the online status and
traffic statistics.
Log ● Allows administrators to configure log upload policies and the

manageme IP address of a third-party log server. The logs that can be
nt uploaded include operation, security, Portal user login and
logout, device login and logout, RADIUS user login and logout,
and HWTACACS logs.
● Allows administrators to query and view device login and
logout logs.
Alarm ● Monitors network-wide alarms and events.

manageme ● Provides alarm management functions such as alarm severity
nt setting, alarm event acknowledgment and clearance, and
alarm rule customization.
Device ● Supports installation of system software packages and patches.

version
manageme
nt


Function
Device ● Allows administrators to upload, download, and activate device

license license files.
manageme
nt
Device ● Supports the discovery and handling (verification and

configurati synchronization) of inconsistent configurations on the
on controller and devices. (This function is supported only by
consistency devices running V600R021C00 and later versions.)
manageme
nt
Device ● Allows administrators to back up, compare, and restore device

configurati configuration files.
on file
manageme
nt
Device ● Provides common network diagnosis tools, such as ping and

diagnosis trace.
● Obtains packet headers based on ports.
● Allows 5-tuple-based packet path tracing.
● Collects diagnosis and fault information.
2.3.11.2 Intelligent O&M Design

Huawei's intelligent O&M solution uses Telemetry technology to enable network
devices to send O&M data (such as device performance indicators and terminal
logs) to Huawei's intelligent network analysis platform iMaster NCE-
CampusInsight (CampusInsight for short). CampusInsight then utilizes big data,
artificial intelligence (AI) algorithms, and advanced analysis technologies to
digitize user experience on the network, helping detect network issues promptly
and improving user experience.
Table 2-88 lists the major O&M functions provided by CampusInsight.

Table 2-88 Main O&M functions provided by iMaster NCE-CampusInsight

ry on
Networ Wireles Wireless client access experience: Analyze the access

k s success rate and time consumption fulfillment rate of
visibilit networ wireless clients from the association, authentication, and
y k DHCP phases to measure the access performance of the
health wireless network.
Wireless client roaming experience: Measure the roaming
quality of wireless clients based on the roaming success rate
and time consumption fulfillment rate, and identify wireless
roaming issues.
Wireless client throughput experience: Analyze the
coverage, capacity health, and fulfillment rate of
throughput to check whether the signal coverage meets
requirements, whether the wireless network is overloaded,
and whether the throughput decreases.
Wired The wired network health intuitively displays wired network

networ quality from four dimensions: device environment, device
k capacity, network status, and network performance.
health Wired device environment analysis: Monitor and analyze
device, card, fan, and power supply faults, and detect
whether the status of physical components is abnormal.
Wired device capacity analysis: Monitor and analyze the
capacity of ARP, MAC, FIB, ACL, and other entries, and
detect whether device resources are abnormal.
Wired network status analysis: Monitor and analyze issues
such as intermittent disconnection and optical module
exceptions, and detect whether interface links are abnormal.
Wired network performance analysis: Monitor and
analyze traffic statistics, and detect issues such as interface
congestion, queue congestion, error packets on interfaces,
and data transmission exceptions.
Wired network protocol analysis: Monitor and analyze
whether the STP, OSPF, and BGP protocol status is
abnormal.
Campu Issue iMaster NCE-CampusInsight analyzes, identifies, and collects

s analysi statistics on connection, air interface performance, roaming,
service s and device issues based on data such as performance
analysi indicators and logs, and displays information about affected
s APs and clients based on each issue indicator.


ry on
Access The Connectivity module evaluates the overall network

analysi connection quality from aspects such as the client access
s fault event trend.
Client access fault event statistics: includes the number of
association failures, number of authentication failures,
number of DHCP failures, and total number of access times.
Client access fault event trend: supports time range
selection, displays the distribution of devices and clients
that fail to be connected in the trend chart, and displays the
distribution of devices and clients with issues in an area
chart.
Perfor The performance experience module evaluates user

mance experience based on RSSI, negotiated rate, and packet loss
analysi rate, displays the number and trend of clients with good
s and poor experience at each time point within a period of
time, and analyzes the client distribution trend by single
indicator. Poor experience analysis based on APs and clients
helps administrators identify APs and clients with the
poorest experience.
User A client access information list can be displayed, and poor-

analysi QoE clients can be analyzed correlatively, including the
s overview, client latency trend, client issue analysis, poor-QoE
duration distribution, and related metrics. In addition, the
client journey information can be viewed, including the
client information, metric overview, access trend statistics,
DNS interaction statistics, audio and video application
statistics, experience metric trend, journey summary, and
access history.
Protoco Client access phases including association, authentication,

l trace and DHCP are displayed in terms of different protocols.
Refined analysis for individual faults that occur during client
access is provided based on the protocol interaction result
and duration at each phase. The analysis includes the most
possible root causes and rectification suggestions for client
access failures.
Currently, protocol trace supports the following user
authentication methods: 802.1X, Portal (Portal 2.0/HTTPS),
HACA, and MAC address authentication.


ry on
Intellig Intellig iMaster NCE-CampusInsight collects KPIs and radio

ent ent parameters reported by devices and uses intelligent
wireles radio algorithms to calculate the load prediction information in
s calibrat the next calibration period. In addition, it accurately
networ ion identifies the network topology and edge AP list by utilizing
k the big data analytics algorithm, and pushes information to
devices in response to their requests. Wireless devices
perform intelligent radio calibration based on the
information delivered by iMaster NCE-CampusInsight and
the network information collected in real time. After the
radio calibration is complete, the devices periodically report
the KPI information and calibration logs of the current
network to iMaster NCE-CampusInsight. iMaster NCE-
CampusInsight then compares and displays the wireless
network parameters before and after the radio calibration.
WLAN Network plan import: After the network plan file made by
topolog the WLAN Planner is imported, iMaster NCE-CampusInsight
y displays data such as sites, pre-deployed APs, obstacles,
background images, and scale planned in the file.
Network comparison: After pre-deployed APs are
associated with real APs, the planned data and actual data
are compared in terms of the power, channel, frequency
bandwidth, number of clients, negotiated rate, and signal
strength, and the comparison result is displayed.
Wi-Fi heatmap display: The radio heatmap can be
displayed based on the AP location.
Spectru iMaster NCE-CampusInsight collects and analyzes channel

m scanning data sent by devices to implement the following
analysi functions:
s ● Displays the real-time status of all channels by AP.
● Allows you to view the historical trend chart of the
channel status, which includes the idle channel
proportion, normal usage proportion, co-channel
interference proportion, and non-Wi-Fi interference
proportion.
● Displays the types of non-Wi-Fi interference sources
detected on the network, affected working channels,
radio types, and RSSI strength.
● Displays the locations of non-Wi-Fi interference sources
and the scope of affected APs. (This function must be
used together with the RSSI-based location function.)


ry on
RSSI- iMaster NCE-CampusInsight collects and analyzes terminal

based location data sent by devices to implement the following
locatio functions:
n ● Displays real-time location information about a single
terminal or all terminals.
● Displays the walking path of a single terminal.
● Displays the heat map of terminal location distribution.
● Displays the locations of Wi-Fi interference sources.
User Applica Based on the monitoring and analysis of audio and video
applica tion service sessions, the SIP session statistics, service traffic
tion analysi trend, and session details list can be displayed, helping users
experie s quickly learn about the quality status of audio and video
nce services.
Intelligent O&M Deployment Planning

Figure 2-172 shows the deployment process of Huawei intelligent O&M solution,
which involves the following two aspects:
● Interconnection between iMaster NCE-Campus and CampusInsight: iMaster
NCE-Campus allows for unified O&M and management, and CampusInsight
can be invoked as a proxy service. iMaster NCE-Campus can synchronize site
and device information to CampusInsight.
● Collection of data such as syslogs and performance data of network devices:
The network devices must be enabled to collect and report O&M data to
CampusInsight.
NOTE
● The time on network devices must be synchronous with that on CampusInsight. If the
time difference between the network devices and CampusInsight is greater than 10
minutes, CampusInsight cannot display the data reported by the network devices.
Typically, you need to configure an NTP server with the same source to ensure time
synchronization between network devices and CampusInsight. During the installation of
CampusInsight, you need to enter the IP address of the external NTP clock source. In
addition, you need to configure the same IP address of the external NTP clock source on
the network devices.
● The wireless network uses the "WAC + Fit AP" architecture, and the performance data
collection function of the Fit APs must be enabled on the web system of the WAC. This
function cannot be enabled on iMaster NCE-Campus.
● To log in to CampusInsight through iMaster NCE-Campus as a proxy service, you need
to enable the intelligent analyzer agent feature on iMaster NCE-Campus in advance.

Figure 2-172 Configuring intelligent O&M
2.4 Multi-Campus Fabric VXLAN Interconnection

Solution Design
As described above, when VXLAN virtual networks are required to achieve one
network for multiple purposes, a customer network can be divided into different
VNs based on service types. Because multiple campuses may have the same
service type, the same VN needs to be planned for the campuses. In this manner,
users enjoy consistent service experience on the same VN regardless of the
campus they reside. To achieve this objective, VXLAN can be used to implement
multi-campus interconnection. Multi-campus interconnection through VXLAN
brings the following benefits:
1. VN consistency: The VN to which a data flow belongs can be identified based
on the L3 VNI carried in the VXLAN packet header, so that service control can be
performed based on the VN.
2. Policy consistency: The security group information carried in VXLAN packet
headers can be used to determine the security group to which the data flow
belongs, so that service control can be performed based on the security group.
To ensure stability and reliability of a VXLAN network between campuses, the
campuses must be directly connected through carriers' private lines or optical
fibers. The round-trip time (RTT) between the border nodes of two campuses
must be less than or equal to 20 ms.
Figure 2-173 shows two types of campus interconnection scenarios based on the
campus network scale: interconnection between large campus networks (with
more than 2000 terminals and 128 APs) and interconnection between large and
small/midsize campus networks (with less than 2000 terminals and 128 APs).

Figure 2-173 Multi-campus interconnection through VXLAN
VXLAN interconnection between large campuses (HQ and branch) is different

from that between a large campus (HQ) and small/midsize campus (branch) as
follows:
1. The three-segment VXLAN solution is used for interconnection between large
campuses. Each campus is an independent fabric, and the border nodes of the two
fabrics are interconnected through VXLAN.
2. The single-fabric architecture is used for interconnection between a large
campus (HQ) and a small/midsize campus (branch). The core devices of the
branch function as edge devices and connect to the border nodes of the HQ to
build a single fabric.
The following sections describe the design considerations for the two
interconnection scenarios.
NOTE
iMaster NCE-Campus supports only single-fabric overlay network orchestration for multiple
campuses, and does not support automatic orchestration for multi-fabric VXLAN
interconnection of multiple campuses. You need to manually configure VXLAN
interconnection through the CLI. Manually configuring VXLAN interconnection services is
complex. You are advised to use the multi-campus single-fabric networking.

2.4.1 Design Considerations for Interconnection Between

Large Campuses
● Site planning: Create sites for each large campus.
● IP address planning: Allocate different IP network segments for different
campuses, and ensure that IP addresses of the campuses do not overlap.
● Fabric planning: Create an independent fabric for each campus.
● Interconnection link: Directly connect border nodes of multiple fabrics
through carriers' private lines or optical fibers, and ensure that the RTT is less
than 20 ms.
● VN deployment: Independently deploy the underlay and overlay networks for
each campus.
● VXLAN interconnection design: The following describes the key design
points of multi-fabric VXLAN interconnection shown in Figure 2-174.
Figure 2-174 Multi-fabric VXLAN interconnection
1. Configure VLANIF interfaces for interconnection between border nodes of

multiple fabrics so that the border nodes can communicate with each other
through the underlay network.
2. Determine the VNs that need to be interconnected on each fabric based on
service types, and create an interconnection VPN for each VN. In this example,
VN1 is created for each fabric, and an interconnection VPN (vpn-instance
gvn1) is created for interconnection between VN1 of the two fabrics. Note
that the eIRT, eERT, and L3VNI in the interconnection VPN must be the same.
3. Determine the service network segments that need to communicate with
each other in VN1, and import the network segments to the service VPN and
interconnection VPN through static routes. In this example, the network
segment 10.1.1.0/24 of VN1 at the HQ needs to communicate with the

network segment 10.1.2.0/24 of VN1 at the branch. Therefore, in the service

VPN, you need to configure a static route with the destination network
segment of 10.1.2.0/24 and the next hop of the interconnection VPN (vpn-
instance gvn1). In the interconnection VPN, configure a static route with the
destination network segment of 10.1.1.0/24 and the next hop of the service
VPN (vpn-instance vn1).
4. Enable BGP EVPN between the border nodes of multiple fabrics to
dynamically establish VXLAN tunnels. Run the import-route static command
to import the static routes are imported to the service VPN and
interconnection VPN, and run the advertise l2vpn evpn command to
advertise BGP EVPN prefix routes.
● Free mobility: It is recommended that the same free mobility policy matrix be
configured for the same VN in each fabric to ensure policy consistency
between the fabrics. You are advised to configure IP-group entry subscription
for the border nodes and configure the border nodes as policy enforcement
points.
● Network scale: Manually configuring VXLAN interconnection between
campuses is complex. The increasing number of interconnected campuses
leads to higher configuration complexity. Therefore, it is recommended that a
maximum of 10 campuses be interconnected through VXLAN.
NOTE
Multi-fabric interconnection through VXLAN does not support multicast overlay, cross-fabric
Layer 2 service access, and cross-fabric IPv6 service access.
2.4.2 Design Considerations for Interconnection Between

Large and Small/Midsize Campuses
● Site planning: Create sites for each campus.
● IP address planning: Allocate different IP network segments for different
campuses, and ensure that IP addresses of the campuses do not overlap.
● Fabric planning: The small/midsize campus (branch) and the large campus
(HQ) share one fabric, and core devices of the branch are added to the fabric
as edge devices. It is recommended that policy association be enabled
between core devices and access devices of the branch.
● Interconnection link: Directly connect the core devices of multiple campuses
through carriers' private lines or optical fibers, and ensure that the RTT is less
than 20 ms.
● VN deployment:
– Underlay network: The HQ uses automatic underlay route orchestration.
You need to manually configure underlay routes to achieve
interconnection between the HQ and branch.
– Overlay network: The overlay network deployment mode is the same as
that in single-fabric scenarios.
● Free mobility: The configuration is the same as that in single-fabric scenarios.
● Network scale: Because the core devices of the branch are added to the HQ
fabric as edge nodes and the number of edge nodes on the HQ fabric is
limited (1000 in centralized gateway scenarios and 500 in distributed gateway

scenarios), you need to consider the number of edge nodes at the HQ when
adding core devices of the branch to the fabric.
NOTE
1. When the core devices of the branch are added to the HQ fabric as edge nodes, they can
connect to external networks only through the border nodes of the HQ.
2. In the distributed gateway scenario where a single fabric is deployed, the branch core
switch can be used as the border node, and the branch can directly connect to the external
network. A single fabric supports a maximum of eight border nodes.
3. The controller does not support automatic underlay route orchestration for a cross-site
fabric.

Solution Design

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

Solution Design

Uploaded by

Copyright:

Available Formats

CloudCampus Solution

Design and Deployment Guide for Large- and

2.1 Networking Solution Selection

2.1 Networking Solution Selection

Issue 01 (2022-11-17) Copyright © Huawei Technologies Co., Ltd. 17

Table 2-1 Comparison of two gateway solutions

Item Centralized Gateway Distributed Gateway

User Border node Wired user gateways are on edge

Issue 01 (2022-11-17) Copyright © Huawei Technologies Co., Ltd. 18

Sin 30,0 0 Pref Centralized VXLAN 1. User traffic is centrally

Issue 01 (2022-11-17) Copyright © Huawei Technologies Co., Ltd. 19

Num Nu Sol Networking Characteristics

> 0 Pref Distributed VXLAN 1. The pressure on the control

Issue 01 (2022-11-17) Copyright © Huawei Technologies Co., Ltd. 20

Networking solution selection description:

2.2 Centralized Gateway Solution Design

2.2.1 Overall Design

2.2.1.1 General Guidelines

2.2.1.1.1 Basic Design Guidelines

Issue 01 (2022-11-17) Copyright © Huawei Technologies Co., Ltd. 21

● Manageable: Campus networks must be easy to manage, maintain, and

2.2.1.1.2 Device Naming Conventions

Figure 2-2 Example of a device name

Table 2-3 Device naming conventions

A Name of a campus site.

B Physical location of a device on a campus network. Generally, the location

C Role of a device on a campus network.

D Device brand. For example, HW in the example indicates Huawei.

F Device number, which can be listed in alphabetical order or ascending

2.2.1.1.3 Interface Description Conventions

Issue 01 (2022-11-17) Copyright © Huawei Technologies Co., Ltd. 22

Figure 2-3 Example of an interface description

Table 2-4 Interface description conventions

A Direction of a local connection, for example, an interface connected to a

B Name of a peer device.

C Interface of the peer device.

2.2.1.2 Network Architecture Design

2.2.1.2.1 Virtual Campus Network Architecture Overview

Issue 01 (2022-11-17) Copyright © Huawei Technologies Co., Ltd. 23

Figure 2-4 Virtual campus network architecture

The overlay consists of the fabric and VN.

Issue 01 (2022-11-17) Copyright © Huawei Technologies Co., Ltd. 24

VN resource pool, which contains the Each time a VN is created, a VN

VLAN resource pool, which is used in When creating a user gateway in a

BD/VNI resource pool, which is used When a user gateway is created in a

2.2.1.2.2 Underlay Network Architecture Design

Issue 01 (2022-11-17) Copyright © Huawei Technologies Co., Ltd. 25

Issue 01 (2022-11-17) Copyright © Huawei Technologies Co., Ltd. 26

Table 2-6 Physical network layers and functional zones

RU On a simplified all-optical campus network, RUs need to work together

Issue 01 (2022-11-17) Copyright © Huawei Technologies Co., Ltd. 27

DM The demilitarized zone (DMZ) provides access services with strictly

Hierarchical Physical Network Architecture Planning

Issue 01 (2022-11-17) Copyright © Huawei Technologies Co., Ltd. 28

Figure 2-7 Hierarchical physical network architecture

Figure 2-8 Layered network architecture design

Issue 01 (2022-11-17) Copyright © Huawei Technologies Co., Ltd. 29

In the preceding calculations, the calculation results need to be rounded up.

2.2.1.2.3 Egress Network Architecture

Figure 2-9 Egress network topologies

On a large or midsize campus network, the number of routes on the egress is

Issue 01 (2022-11-17) Copyright © Huawei Technologies Co., Ltd. 30

networking 1 be used and routers function as egress devices. This is because