01-02 Solution Design

CloudCampus Solution
Design and Deployment Guide Deployment Guide

for Large- and Medium-Sized Campus Networks
(Non-virtualization Scenario) 2 Solution Design
2 Solution Design
2.1 Network Architecture Design

2.2 Network Management Zone Design
2.3 Basic Network Service Design
2.4 Wireless Network Service Design
2.5 Egress Network Service Design
2.6 Network QoS Design
2.7 Network Reliability Design
2.8 Network Security Design
2.9 Network Deployment Design
2.10 Network O&M Design
2.1 Network Architecture Design
2.1.1 Network Topology

Large- and medium-sized campus networks often use the tree topology with the
core layer as the root. In Figure 2-1, the topology is stable and easy to expand
and maintain. A campus network can be divided into the following layers: access
layer, aggregation layer, core layer, and multiple zones. The zones include the
Internet zone, data center (DC) zone, network management zone, and
demilitarized zone (DMZ). Modules in each zone are clearly defined, and the
internal adjustment of each module is limited to a small scope, facilitating fault
location.
Issue 04 (2021-10-10) Copyright © Huawei Technologies Co., Ltd. 17

Figure 2-1 Topology of a large or midsize campus network
The functions of each layer and each zone are described as follows:
● Terminal layer
The terminal layer involves various terminals that access the campus network,
such as PCs, printers, IP phones, mobile phones, and cameras.
● Access layer
The access layer provides various access modes for users and is the first
network layer to which terminals connect. The access layer is usually
composed of access switches. There are a large number of access 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 APs need to be deployed at the access layer and
access the network through access switches.
● Aggregation layer
The aggregation layer sits between the core and access layers. It forwards
horizontal traffic (east-west traffic) between users and forwards vertical
traffic (north-south traffic) to the core layer. The aggregation layer can also
function as the switching core for a department or zone and connect the

department or zone to a dedicated server zone. In addition, the aggregation

layer can further extend the quantity of access terminals.
● Core layer
The core layer is the core of data exchange on a campus network. It connects
to various components of the campus network, such as the DC, aggregation
layer, and campus egress zone. 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.
For a wireless network, the core layer includes WACs, which manage APs by
using the Control and Provisioning of Wireless Access Points (CAPWAP)
protocol.
● Campus egress zone
The campus egress is the boundary that connects a campus network to an
external network. Internal users of the campus network can access the
external network through the campus egress zone, and external users can
access the internal network through the campus egress zone. 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.
● DC zone
In the DC zone, service servers such as the file server and email server are
managed, and services are provided for internal and external users.
● Network management zone
In the network management zone, network servers such as the network
management system (NMS) and authentication server are managed. The
NMS interacts with network devices through network management protocols
to provide configuration, management, and O&M functions. Mainstream
network management protocols include Simple Network Management
Protocol (SNMP) and Network Configuration Protocol (NETCONF). The
authentication server provides authentication, authorization, and accounting
functions for network access. Mainstream authentication protocols include
Remote Authentication Dial-In User Service (RADIUS) and Terminal Access
Controller Access Control System (TACACS).
● DMZ
The DMZ provides access services with strictly controlled security for external
guests (personnel other than enterprise employees). Public servers are usually
deployed in the DMZ.
2.1.2 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-2 shows two networking models depending on whether routers need to
be deployed. In networking 1, routers function as egress devices. In networking 2,
firewalls function as egress devices.

Figure 2-2 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), 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.
2.1.3 Hierarchical Architecture of the Intranet

In actual applications, you can choose the three-layer, two-layer, or single-layer
architecture based on the network scale or service requirements, as shown in
Figure 2-3.

Figure 2-3 Hierarchical physical network architecture
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.
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-4.

Figure 2-4 Layered network architecture design
● 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
In the preceding calculations, the calculation results need to be rounded up.

● 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 Network Management Zone Design
2.2.1 Networking 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, as demonstrated in Figure 2-5.
● A stacked Layer 3 switch functions as the server gateway and is directly
connected to software servers and a clustered core switch.
● 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-5 Basic networking of the network management zone

2.2.2 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 you are advised to add them to the VLAN of the
corresponding network plane in access mode. As shown in Figure 2-6, add
physical ports (GE1/0/1 and GE2/0/1) on the switch to VLAN 100 using the
following commands.
Figure 2-6 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
[Switch] interface gigabitethernet 2/0/1
[Switch-GigabitEthernet2/0/1] port link-type access
[Switch-GigabitEthernet2/0/1] port default vlan 100
[Switch-GigabitEthernet2/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-7, add Eth-
Trunk 1 on the switch to VLAN 100 using the following commands.

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

Management Zone and Campus Intranet
The network management zone needs to communicate with the device
management subnet and user service subnet. Table 2-1 lists the common
software systems that need to communicate with the campus intranet.
Table 2-1 Description about communication between common software systems

in the network management zone 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 service subnet
service subnet must be able to communicate with iMaster
on the overlay NCE-Campus.
network
DHCP server Dynamically assigns IP addresses to user
terminals. The user service 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
between the gateway in the network management zone and the core switch
cluster. As illustrated in Figure 2-8, 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, and the other (VLANIF 600 in the figure)
for communication between the network management zone and the user
service subnet.
● Communication between the network management zone and device
management subnet:
– 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. 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.
● Communication between the network management zone and user service
subnet:
– On the core switch: Create a private 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 the DHCP server in the figure) that need to communicate with the
user service subnet reside. The next hop of the route is the IP address of
VLANIF 600 on the gateway in the network management zone.
– On the gateway in the network management zone: Configure a static
route destined for the user service subnet. 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-8 Planning for communication between the network management zone
and the campus intranet

2.3 Basic Network Service Design
2.3.1 VLAN Design

VLAN assignment should comply with the following principles:
● Assign VLANs based on service zones.
● Assign VLANs based on service types (web, app, or database) in a service
zone.
● Allocate consecutive VLAN IDs to ensure proper use of VLAN resources.
● Reserve a specific number of VLANs for future use.
VLANs are classified into service, management, and interconnection VLANs. For
details about the design suggestions, see Table 2-2.

Table 2-2 VLAN design suggestions

Category Design Suggestion
Service VLAN Assign VLANs by logical area, geographical area, personnel

structure, or service type.
● Assign VLANs by logical area. For example, VLANs 100 to
199 are used in the core network zone, VLANs 200 to 999
are used in the server zone, and VLANs 2000 to 3499 are
used on the access network.
● Assign VLANs by geographical area. For example, VLANs
2000 to 2199 are used in area A, and VLANs 2200 to 2399
are used in area B.
● Assign VLANs by personnel structure. For example,
department A uses VLANs 2000 to 2009, and department
B uses VLANs 2010 to 2019.
● Assign VLANs by service type. For example, VLANs 200 to
299 are used in the web server zone, VLANs 300 to 399 are
used in the app server zone, and VLANs 400 to 499 are
used in the database server zone.
If users are sensitive to the voice latency, the voice service
must be preferentially guaranteed. It is recommended that
the voice VLAN be planned for the voice service. Huawei
switches can automatically identify voice data, transmit voice
data in the voice VLAN, and perform QoS guarantee. When
network congestion occurs, voice data can be preferentially
transmitted.
If different users have the same multicast data service, you
are advised to plan a multicast VLAN and bind the user
VLANs to the multicast VLAN. By doing this, the uplink
gateway does not copy multicast data in multiple user VLANs.

Category Design Suggestion
Management ● Egress network devices: Use Layer 3 service interfaces as

VLAN management interfaces, without the need to plan a
management VLAN.
● Core switches: Plan an independent management VLAN
and use the VLANIF interface of the management VLAN as
the management interface, through which iMaster NCE-
Campus manages core switches.
● Devices below the core layer: 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 the
devices through this 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 number of devices are deployed, it is recommended
that all aggregation and access switches use the same
management VLAN and all APs use the same
management VLAN.
– If a great number of devices are deployed, 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.
Interconnection An interconnection VLAN is usually configured between two

VLAN Layer 3 switches or between a Layer 3 switch and a router.
VLANIF interfaces are created for Layer 3 interconnection.
2.3.2 IP Address Design

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 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 type of 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.
The IP addresses of the campus network are classified into service, management,
and interconnection IP addresses, as shown in Table 2-3.
Table 2-3 Suggestions for the IP address design
Category Suggestion
Service IP address Service addresses are the IP addresses of servers, hosts,

and gateways. You are advised to use the same last
digits as the gateway address. For example, gateways
use IP addresses suffixed by .254.
The address range of each service and the address
range of the servers and clients must be clearly
separated. The addresses of each type of service
terminals must be contiguous and can be aggregated.
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.
Management IP A Layer 2 device uses the VLANIF interface's IP address

address as the management IP address. It is recommended that
all Layer 2 switches connected to a gateway be on the
same network segment.
It is recommended that a Layer 3 device use a Layer 3
interface for management and deployment. The
interface address is used as the management IP address
for local login and interworking with the controller.
Interconnection IP An interconnection address is the IP address of an

address interface connected to another device's interface. It is
recommended that the IP address with a 30-bit mask
be used as an interconnection 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.

2.3.3 DHCP Design

You are advised to plan an independent DHCP server for large- and medium-sized
campus networks. The DHCP design suggestions are as follows:
● A DHCP server is deployed on the entire campus network to simplify O&M.
● DHCP snooping is configured on access devices to ensure that clients obtain
IP addresses from valid DHCP servers to prevent attacks from unauthorized
users.
● IP addresses can be assigned dynamically or statically. Network administrators
can use either of the two mechanisms to allocate IP addresses to hosts based
on network requirements.
Dynamic allocation: An IP address with a lease is assigned to a host. This
mode applies to scenarios where hosts require temporary access or IP
addresses are insufficient. For example, IP addresses are allocated to portable
computers of employees on business trips and mobile terminals in cafes.
Static allocation: Fixed IP addresses are assigned to specified hosts. This mode
applies to hosts that have special requirements on IP addresses. For example,
the file server that provides services for external users and the DNS server
require fixed IP addresses.
In the address pool design, static IP addresses must be filtered out to prevent
reserved IP addresses from being allocated.
● The lease needs to be planned based on the online duration of a client. On
large- and medium-sized campus networks, a long lease needs to be planned
since users in the office zone are online for a long time.
Typically, the DHCP server and hosts on large- and medium-sized campus
networks are not on the same network segment. Therefore, you are advised to
enable the DHCP relay function on the gateway.
2.3.4 Gateway Design

In the two-layer networking architecture of large- and medium-sized campus
networks, gateways are deployed at the core layer.
In the three-layer networking architecture of large- and medium-sized campus
networks, gateways can be deployed at the core layer or aggregation layer.
● Gateways deployed at the aggregation layer: The Layer 2 broadcast scope is
small; the requirements for authentication, ARP entries, and MAC addresses
are low; flexible capacity expansion is supported. However, the configuration
and maintenance are complex due to a large number of gateways. This mode
is not suitable to wired and wireless convergence scenarios.
● Gateways deployed at the core layer: The Layer 2 broadcast scope is large; the
requirements for authentication, ARP entries, and MAC addresses are high;
flexible capacity expansion is not supported. This design can implement
centralized management and control of the campus network and prevent
large-scale wireless Layer 3 roaming. It applies to wired and wireless
convergence and free mobility scenarios.

2.3.5 Routing Design

The routing design includes internal and egress routing design of a campus
network.
The internal route design must meet communication requirements of devices and
terminals on the campus network and enable communication with the external
network. It is recommended that you design internal routes based on the gateway
location.
● If gateways are deployed at the core layer, you only need to configure routes
at the core layer. It is recommended that static routes be used preferentially.
● If gateways are deployed at the aggregation layer, routes need to be deployed
at the core and aggregation layers. Routing tables can be dynamically
updated along with network topology changes, so an Interior Gateway
Protocol (IGP), such as Open Shortest Path First (OSPF), is recommended.
The egress routing design must meet requirements of internal terminals for
accessing the Internet and WAN. A large or midsize campus network usually has a
large number of branches. The egress needs to support multiple links for Internet
access and mutual communication between enterprise branches. For this purpose,
a large number of routes need to be imported to the campus network. Therefore,
you are advised to plan a dynamic routing protocol such as OSPF.
It is recommended that OSPF be planned for a campus network. The OSPF design
precautions are as follows:
● It is recommended that the IP address of the loopback interface be used as
the router ID. The rules for selecting the router ID are as follows:
– The system preferentially selects the largest IP address among loopback
interface addresses as the router ID.
– If no loopback interface is configured, the system selects the largest IP
address among interface addresses as the router ID.
– The system reselects the router ID only when the interface address used
as the router ID is deleted or changed.
● Areas are divided according to the core, aggregation, and access layers. It is
recommended that egress routers and core switches be deployed in the
backbone area. The design of non-backbone areas depends on the
geographical location and device performance. If many low-end Layer 3
switching devices are deployed in a non-backbone area, the number of routes
should be minimized to reduce the area size or a special area can be used.
This is due to the positioning and performance limitations of these switching
devices.
In Figure 2-9 where the gateway is deployed at the aggregation layer, area 0
between the core layer and the egress area is deployed as the backbone area.
The egress routers function as Autonomous System Boundary Routers
(ASBRs) and core switches serve as Area Border Routers (ABRs). One pair of
aggregation and core switches are deployed in an OSPF area. The areas are
numbered 1, 2, 3, and so on.

Figure 2-9 OSPF area division on a campus network
● Using special areas can optimize routing entries on routers in non-backbone

areas. Typically, the number of routing entries on routers in a non-backbone
area needs to be reduced in the following scenarios:
– The non-backbone area has only one ABR used as the egress router and
all traffic for accessing external services outside the area passes through
this egress router. In this case, non-ABR routers in this non-backbone area
do not need to obtain detailed information about the external network,
and only an egress is required to send traffic out of this area.
– Some low-end Layer 3 switches are deployed in the non-backbone area
and their routing tables contain limited routing entries because of
performance limitations. Special areas can be configured to reduce the
number of routing entries on such devices.
It is recommended that non-backbone areas be planned as totally NSSAs. This
configuration significantly reduces the number of routing entries on internal
routers in the non-backbone areas and the number of OSPF packets
exchanged among these routers. In addition, route calculation and topology
adjustment in an area do not affect other areas. A network fault causes route
flapping only in the local area.
You are advised to plan the IP addresses of which routes can be summarized
when an OSPF network is built, and replan IP addresses if an OSPF network
needs to be expanded. Route summarization reduces the number of routing
entries in routing tables of routers in the backbone area and the number of
OSPF packets exchanged among these routers. After routes are summarized, a
single-point link failure or network flapping does not affect route update on
the entire network. Therefore, route summarization improves network
stability.

Route summarization reduces the number of routes and improves network

stability in many scenarios. However, route summarization may cause routing
loops. Blackhole routes can solve this problem. A router discards packets that
match a blackhole route and does not send any error information to the
packet sender. Therefore, route summarization and blackhole routes are often
used together in OSPF network design.
2.4 Wireless Network Service Design

A campus WLAN provides ubiquitous wireless access of data, voice, and video
services for employees, wireless Internet access services for guests, and connection
capabilities for IoT devices. Users in a campus can enjoy the same service
experience regardless of their locations.
This chapter describes design suggestions closely related to WLAN services,
including suggestions on WLAN planning, network architecture, AP management,
radio management, SSID design, roaming design, and location engine.
2.4.1 Suggestions on WLAN Planning

A WLAN uses wireless signals (high-frequency electromagnetic waves) to transmit
data. The strength of wireless signals becomes weaker as the transmission
distance increases. In addition, overlapping interference exists between adjacent
wireless signals. All these factors reduce the signal quality or even causes
unavailable network connection. To improve the WLAN quality and meet
customers' requirements on network construction, WLAN planning design is
required. 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.
The WLAN planning design consists of the following parts:
● Network coverage design: Determine the requirements and principles for
signal coverage.
● Network capacity design: Determine the bandwidth requirements of a single
user based on the service model and STA behavior, and then determine the
number of APs based on the AP capability.
● AP deployment design: Determine AP installation positions based on the
deployment principles.
● AP channel planning: Properly plan channels for APs in neighboring areas to
reduce co-channel and adjacent-channel interference.
● AP power supply and cabling design
For details about the WLAN planning design, see WLAN Network Planning
Guide.
2.4.2 Network Architecture Design

On a large or midsize campus network, the WLAN typically uses the "WAC + Fit
AP" networking architecture. Depending on the location of the WAC, two WAC
deployment modes are available: in-path and off-path. When a native WAC
(integrated on a switch) is used, only the in-path deployment mode can be
adopted. When a standalone WAC is used, the two deployment modes are both

supported (off-path mode recommended). Table 1 compares the two deployment

modes.
Table 2-4 Comparison of the deployment modes available for a standalone WAC
Netw Application Scenario Advantage Disadvantage
orkin
g
Type
In- ● A standalone WAC can ● The network is ● The network

path meet the network simple in scale relies on
mode requirements. structure and the capabilities
can provide of the
both WAC and standalone WAC
switching (for example,
capabilities. the number of
APs supported).
● Capacity
expansion is
difficult.
Off- ● The WAC only manages ● It is easy to In centralized

path the WLAN, APs, and STAs. deploy a forwarding mode is
mode ● The WAC does not need standalone used, much
to process service traffic WAC in off- bandwidth of the
(for example, local path mode for switch is
forwarding). a new WLAN. consumed.
● The network is large in ● Capacity
scale, for example, with expansion is
more than 10K APs on easy.
the network.
It is recommended that the standalone WAC be deployed at the core layer.

User data packets on a WLAN can be forwarded in tunnel (centralized) or direct
(local) mode, as described in Table 2. Centralized forwarding is recommended on
large- and medium-sized campus networks for central traffic management and
control.

Table 2-5 Forwarding mode comparison
Forwar Application Scenario Advantage Disadvanta

ding ge
Mode
Centrali The WAC centrally processes and The WAC Service

zed forwards user service data. forwards data data must
forwardi packets in be
ng centralized forwarded
manner, by the
ensuring high WAC,
security and reducing
facilitating packet
centralized forwarding
traffic efficiency
management and
and control. burdening
the WAC.
Local User data is directly forwarded Service data Service

forwardi without passing through the WAC, does not need data is
ng saving AP-WAC link bandwidth. to be forwarded difficult to
by the WAC, manage
improving and control
packet in a
forwarding centralized
efficiency and manner.
reducing the
burden on the
WAC.
2.4.3 AP Management Design

To manage a large number of APs, you need to select a proper WAC to manage
the APs by group so that you can configure and upgrade them in batches.
WAC Selection
WACs deployed on Huawei WLANs include native WACs (integrated WAC function
on switches for wired and wireless convergence) and standalone WACs (such as
AirEngine 9700-M). Select appropriate WACs based on the WAC performance
specifications and project requirements by considering the following factors:
● Number of managed APs

● Number of concurrent STAs
● Forwarding capability, especially in centralized forwarding mode
● Concurrent access rate. In higher-education scenarios, for example, this factor
is a key factor to consider, especially in the teaching area where a large
number of users may go online concurrently after class.

In addition to the preceding factors, you also need to consider key feature
differences between native WAC and standalone WAC, which are listed below.
Item Native WAC Standalone WAC
Navi WAC Not supported Supported

feature
DTLS Not supported Supported

encryption
for data
channels
PPSK Not supported Supported

authenticati
on
Application Supported by fixed Supported

identificatio switches, but not by
n modular switches
Reliability Stacking; dual-link cold Dual-device VRRP hot standby; dual-

standby link hot standby
Layer 3 Not supported Supported

roaming
Inter-WAC Not supported Supported

roaming
Scalability Poor. (Limited by the CPU Strong. Only standalone WACs need
processing capability of to be added, facilitating capacity
the switch's main control expansion.
board, so it is difficult to
perform capacity
expansion)
Free Supported Not supported

mobility
Wired and Supported Not supported

wireless
convergence
AP Group Division
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
● SN
AP Upgrade
To reduce the impact of the AP upgrade on the network, you can upgrade the APs
on the network in batches when the network services are not running.
By planning upgrade tasks, you can flexibly upgrade the "WAC + Fit AP" network.
● Upgrade scope: You can upgrade APs in batches or upgrade a single AP.
● AP type: You can upgrade APs of the specified model.
● AP group: You can upgrade APs in a specified group.
● Upgrade mode: Immediate upgrade, automatic in-service upgrade, and
scheduled upgrade are supported. You can also only download the upgrade
file, which requires manual AP reset.
2.4.4 Radio Management Design

On a WLAN, especially on the 2.4 GHz frequency band, out-of-band interference
and in-band co-channel/adjacent-channel interference exist. STAs of different
brands, types, and models behave differently. For optimal access services, radio
resources and user access need to be managed in a coordinated manner. The
specific radio resource management (RRM) capabilities include:
● Radio calibration
The radio calibration function can dynamically adjust channels and power of
APs managed by the same WAC to ensure that the APs work at the optimal
performance. 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.
● Band steering
Most STAs support both the 2.4 GHz and 5 GHz frequency bands. Generally,
the 2.4 GHz frequency band is selected by default, on which a smaller number
of channels are available. The 2.4 GHz frequency band is usually crowded and
heavily loaded, and suffers high interference. In contrast, the 5 GHz frequency
band with multiple channels and low interference cannot be brought into full
play. The band steering function enables an AP to steer STAs to the 5 GHz
radio first, which reduces traffic load and interference on the 2.4 GHz radio
and improves user experience. It is recommended that this function be
enabled by default.
● Smart roaming
Some outdated and dumb terminals 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 the STA is always
associated with the poor-signal AP. 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.
Smart roaming enables STAs to roam to neighboring APs with better signals
in a timely manner, improving user experience.
– Performance improvement
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. It is recommended that this capability
be enabled.
● STA steering
After a STA connects to an AP, the target AP selection algorithm is used to
comprehensively measure the dual-band capability of the STA, AP load, and
AP signal quality to steer the STA to the optimal AP. It is recommended that
this capability be enabled.
NOTE
If intelligent radio calibration with better effect is used, the local radio calibration
function provided by the WAC is not required. For more information about intelligent
radio calibration, see 2.10.2 Intelligent Network O&M.
2.4.5 SSID Design

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-10. 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-10 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-6.
Table 2-6 SSID:VLAN mapping

SSID:VLAN Usage Scenario
Mapping
SSID:VLAN An enterprise needs to provide WLAN coverage for hotspots A

= 1:1 and 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.
SSID:VLAN An enterprise needs to provide WLAN coverage for hotspots A

= 1:N and 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 or 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.4.6 Roaming Design

User mobility is a basic feature of a WLAN. Ensuring service experience when a
user moves between different APs is key to WLAN network quality. As shown in
Figure 2-11, WLAN roaming enables STAs to move from the coverage area of an
AP to that of another AP with nonstop service transmission.

Figure 2-11 WLAN roaming
WLAN roaming addresses the following issues:
● Retains users' IP addresses. After roaming, users can still access the initially
associated network and continue its services.
● Avoids packet loss or service interruption caused by long-term authentication.
WLAN roaming is classified into the following types based on the STA roaming
scope:
● Intra-WAC roaming
● Inter-WAC roaming at Layer 2 or Layer 3
In actual deployment, intra-WAC roaming is recommended. Inter-WAC roaming

can be avoided through proper AP group management. For services with high
latency requirements, such as automated guided vehicles (AGVs), in warehouses
and factories, it is recommended that a separate SSID or VLAN be planned to
implement Layer 2 roaming within the WAC.
In the scenario where aggregation switches serve as native WACs, if the number of
STAs is greater than or equal to 40,000, a maximum of four native WACs can be
deployed in each mobility group; if the number of STAs is less than 40,000, a
maximum of 16 native WACs can be deployed in each mobility group.
In addition to the preceding basic roaming functions, Huawei WLAN supports the
fast roaming function, including pairwise master key (PMK) fast roaming and
802.11r fast roaming. This function further reduces the handoff delay between
APs. Table 2-7 shows the handover delay of STAs in different roaming modes.
802.11r fast roaming supports an enhanced roaming mechanism based on device-

pipe synergy when working with Huawei terminals. This mechanism helps further

reduce the roaming handover delay and packet loss rate. Therefore, you are
advised to enable the mechanism when enabling 802.11r fast roaming.
Table 2-7 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.
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.
ly.
802.1X non-fast < 250 This is a NA

roaming: ms basic
function of
the system
which takes
effect
automatical
ly.
2.4.7 Wireless Location Design

Solution
Huawei provides three mainstream wireless location solutions: 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 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.
Deployment Suggestions
Table 2-8 describes the capabilities and application scenarios of the wireless
location solutions.
Table 2-8 Comparison of wireless location solutions

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

port plackb locatio ome location navigation el fencing
ed ack 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


m
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
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.5 Egress Network Service Design
2.5.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

In Figure 2-12, a campus network itself is considered to be secure and security
threats are mainly 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 and extranet 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.
Figure 2-12 Security zone division

2.5.2 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-13, 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-13.
Figure 2-13 Intelligent traffic steering

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-14, 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-14 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-15, 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-15 Using dynamic routing between the firewall and the core switch
2.5.3 Security Policy Design

After the area design is complete, you are advised to analyze security threats in
each area and deploy corresponding security policies.
Table 2-9 shows the recommended security policy design for common zones.
Table 2-9 Recommended security policy design for common zones
Access Access Source Trustworthiness Recommended Security

Zone Policy
Internet External users Untrusted Intrusion detection, URL

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

branch antivirus

Access Access Source Trustworthiness Recommended Security

Zone Policy
Intranet Enterprise High Intrusion detection and

employees antivirus
Guests Low
2.5.4 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-16, if firewalls function as egress devices, pay
attention to the following points when configuring NAT:
Figure 2-16 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.6 Network QoS Design
2.6.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-10 describes the key points of QoS requirement survey.
Table 2-10 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

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

Requ Key Point of Requirement Survey Survey Purpose

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.6.2 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-11.

Table 2-11 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

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
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.6.3 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.6.3.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.6.3.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.6.3.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-12 lists the typical QoS policy solutions formulated based
on engineers' experiences, which provide references for design personnel.
Table 2-12 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

Applicatio Typical Application or CoS Queue Sched Maximu

n Type Protocol (Priorit uling m
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.6.4 Intelligent HQoS Design
2.6.4.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.6.4.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-13 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 Online video Low or Very Low 10; burst

conferenci conferencing medium low
ng applications
APP3 and
APP4
VI Remote Remote Low or Very Low 20; burst

P2 desktop 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.6.2 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.6.4.3 Design of Customized Applications

After planning for VIP users and analyzing service traffic, you need to design rules
for defining applications. Applications on a campus network are classified into
predefined applications and customized ones.
● Predefined applications are those predefined in the Huawei Smart Application
Control (SAC) signature database. SAC-capable network devices can
automatically identify such applications. Administrators only need to select
applications from the SAC signature database and add them to an application
scheduling template. After an application scheduling policy is delivered to a
network device, the network device can use the SAC function to identify
applications. For details about the Huawei SAC signature database, visit
https://isecurity.huawei.com/sec/web/freesignature.do.
● Customized applications are not present in the SAC signature database. 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-14 Example design of customized applications

Applicatio Description Type (URL/IP) Protocol Port
n
APP1 Live streaming 172.16.33.22 UDP 6666
APP2 Database https:// - -

access database.compa
ny.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.
NOTE
Switches do not support application identification through SAC.
2.6.4.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.6.4.2
Planning of VIP Users and Applications . For typical scheduling policy
suggestions, see 2.6.3.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-15 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.6.4.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.
Networking User Gateway User WAC
Topology Authentication
Point
Independent WAC AirEngine 9700-M AirEngine 9700-M

wireless
network
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.
● 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.7 Network Reliability Design

2.7.1 Device Reliability
2.7.1.1 Switch Reliability

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-17,
two modular core switches SwitchA and SwitchB set up a CSS and back up
each other. In the event of a failure on SwitchA, SwitchB takes over services
from SwitchA to ensure service continuity.
Figure 2-17 Improving reliability
● Increasing the number of ports

As demonstrated in Figure 2-18, 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-18 Increasing the number of ports
● Simplifying the network topology

In Figure 2-19, 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-19 Simplifying the network topology
2.7.1.2 WAC Reliability

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-20, 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-20 Deploying WACs in HSB mode
2.7.1.3 Firewall Reliability

When firewalls function as egress devices, you are advised to deploy HSB to
improve firewall reliability. As illustrated in Figure 2-21, the firewalls act as egress
devices of the campus network and are directly connected to the clustered 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-21 Deploying firewalls in HSB mode
2.7.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-22, 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-22 Eth-Trunk networking
2.8 Network Security Design
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.5
Egress Network Service Design.

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.8.2.1 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.8.2.2 Aggregation Layer

For the network security design at the aggregation layer, refer to 2.8.2.3 Wired
Access Layer if terminals are connected to the aggregation switch, and refer to
2.8.2.1 Core Layer if the aggregation switch functions as the user gateway or
authentication point.
2.8.2.3 Wired Access Layer

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. As a result,
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 a fabric, the port isolation function is
automatically configured on the port.
2.8.2.4 Wireless Access Layer

On a WLAN, service data is transmitted through radio signals. Such open channels
are vulnerable to service data interception and tampering during transmission,
such as rogue STAs, spoofing APs, and denial of service (DoS) attacks of malicious
terminals. As shown in Figure 2-23, 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-23 WLAN security
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-24 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

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-16 Comparison of WLAN security policies

Secu Characteristics
rity
Mec
hani
sm
WEP WEP shared key authentication requires that the same static key be
preconfigured on the server and client. Both the encryption mechanism
and the encryption algorithm are vulnerable to security threats.
Therefore, this authentication mode is not recommended.
WPA WPA and WPA2 provide almost the same security. WPA/WPA2 has two
/ editions: enterprise edition and personal edition.
WPA WPA/WPA2-Enterprise requires an authentication server and is
2 recommended for employee access on large- and medium-sized campus
networks.
WPA/WPA2-Personal does not require an authentication server and is
recommended for guest access on large- and medium-sized campus
networks. The WPA/WPA2-PPSK (PPSK is short for Private PSK) enhances
network security while ensuring the convenience.
WAP WAPI is a WLAN security standard proposed in China and provides

I higher security than WEP and WPA.

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.8.3 Network Admission Security Design

Admission control is to authenticate and authorize users attempting to access the
network. This is to ensure that only authorized and qualified users can access the
network. After a user accesses the network, an access policy matching the user
identity can be formulated. This section describes the network admission security
design based on Huawei's intent-driven campus network.
2.8.3.1 Overall Admission Control Design

As shown in Figure 2-25, the entire authentication admission system consists of
the authentication client, authentication device, authentication server, and data
source server.
Figure 2-25 Authentication admission system
The overall working process is as follows:

1. An authentication client sends a network access request that contains
authentication information such as the account and password to an
authentication device.
2. The authentication device sends the received authentication information to an
authentication server through the standard AAA protocol (such as RADIUS).

3. The authentication server sends a request to a data source server for verifying
the account and password.
4. The data source server notifies the authentication server of the verification
result, and the authentication server then notifies the authentication device of the
authentication result.
5. The authentication device permits or denies network access of the
authentication client according to the received authentication result.
Authentication Device Role Selection

Campus network devices play the following roles in the admission control system:
● Authentication admission point: a device that controls the network access
rights of users. Generally, it is the access device of a user. A user can access
the network only after passing the authentication. In the policy association
solution, Layer 2 isolation is enabled on the authentication admission point by
default to prevent unauthenticated users from directly communicating with
each other at Layer 2. In addition, the authentication admission point
transparently transmits the received user authentication packets to the
authentication control point, which then initiates authentication to the
authentication server.
● Authentication control point: a device that initiates authentication to the
authentication server. The authentication control point interacts with the
authentication server to implement authentication, authorization, and
accounting. In the policy association solution, the authentication control point
and authentication admission point exchange user authentication requests
and synchronize user entries through a CAPWAP tunnel.
● Policy enforcement point: a device that enforces inter-group policies. In a
centralized authentication scenario, the authentication control point and
policy enforcement point are deployed on the same device. This allows the
policy enforcement point to directly obtain the source and destination security
group information from the authentication control point. If the authentication
control point cannot share a device with the policy enforcement point (for
example, a wireless authentication control point, a standalone WAC, does not
support free mobility and cannot function as a policy enforcement point),
configure IP-security group entry synchronization or enable VXLAN packets to
carry security group information. By doing so, the policy enforcement point
can obtain the security group information corresponding to the source and
destination IP addresses of packets.
In non-virtualization scenarios, it is recommended that the core device be used as
a centralized gateway. Figure 2-26 illustrates the recommended deployment of
authentication points.

Figure 2-26 User admission control in non-virtualization scenarios
Authentication Server Selection

iMaster NCE-Campus is recommended as the authentication server. Compared
with other authentication servers, iMaster NCE-Campus provides more 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.
If an enterprise has deployed a third-party authentication server, iMaster NCE-
Campus can work in relay mode. In this manner, campus authentication devices
can connect to the third-party authentication server through iMaster NCE-Campus
to obtain high-value features such as free mobility.
Data Source Server Selection

Common data source servers in enterprises include the AD server and LDAP server.
If an enterprise has no data source server available, Huawei iMaster NCE-Campus

is recommended as the data source server. If an enterprise uses an AD or LDAP

server as the data source server, AD or LDAP can continue to be used as the data
source. iMaster NCE-Campus can synchronize user information with the server and
then perform network authorization.
2.8.3.2 Admission Authentication Mode Selection

Common authentication technologies include 802.1X, MAC address, and Portal
authentication. Table 2-17 compares these authentication modes.
Table 2-17 Comparison between user authentication technologies

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

required
Disadvantag Inflexible MAC address Low security

e deployment registration
required, making
management
complex
Application Authentication of Authentication Authentication of

scenario office users in of dumb guests who move
scenarios with high terminals such as frequently and use
security printers and fax different types of
requirements machines terminals
Considering the characteristics of the preceding authentication technologies,

802.1X authentication is recommended for employees, Portal authentication for
guests, and MAC address authentication for dumb terminals on large- and
medium-sized campus networks.
If the customer wants to use more than one authentication mode on the same
access point, the mixed authentication mode is recommended. After the mixed
authentication mode is configured, terminals can access the network after passing
any authentication mode. This mode is applicable to scenarios where one port is
used for access of multiple types of users. For example, if a PC is connected to an
IP phone, you can configure MAC address and 802.1X authentication for the IP
phone and PC, respectively.
2.8.3.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. In the traditional NAC solution, VLANs and ACLs are
delivered to authentication devices to implement access control. Huawei's
innovative technical solution — free mobility solution — controls user network
access rights through topology-agnostic security groups. The Huawei solution

configures user policies based on the natural language, so users have no need to
focus on network concepts like IP addresses and VLANs. Additionally, user policies
are deployed by the controller in a unified manner, facilitating future
maintenance. Table 2-18 compares the two solutions.
Table 2-18 Policy control solution comparison

Policy Control Characteristics Application
Control Mode Scenario
Solutio
n
Traditio VLAN + ● The administrator needs to User access locations

nal ACL plan a large number of IP are fixed.
NAC addresses, VLANs, and ACL Permission policies
solution policies, making the are simple.
configuration workload
heavy and capacity
expansion or configuration
change complex.
● Access rights are difficult to
control when users move,
and the priority and
bandwidth cannot be
guaranteed.
Free Security ● Administrators do not need There are mobile

mobilit group + to pay attention to IP address office requirements,
y inter- and VLAN assignment. User and users with
solution group policies are configured on the different network
policy controller based on security permissions sit in the
groups and are automatically same place.
delivered to all Permission policies
authentication devices, are complex.
eliminating the need to
perform complex
configuration.
To sum up, it is recommended that free mobility be used as the policy control
solution for large- and medium-sized campus networks. If the customer's existing
campus networks do not support this solution, the traditional NAC solution is
used.
2.8.3.3.1 Traditional NAC Solution Design

● Access Policy Authorization Design
In the traditional NAC solution, policies are classified into two categories:
static ACL policies on local devices and dynamic ACL policies authorized by
the NAC server. The essence of configuring static ACL-based 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
policy approach applies to the scenario where the user network scale is small,

the locations of user terminals are fixed, and policy requirements are simple.
As the network scale increases and the policy requirements become more
complex, it makes the configuration difficult to set and maintain. Therefore,
for large- and medium-sized campus networks, you are advised to use the
authentication server to authorize dynamic ACL policies. In this manner,
terminals do not need to be strictly bound to IP addresses and VLAN
information, making IP and VLAN planning flexible. When users are divided
into multiple categories, you are advised to restrict the access locations of
users. Users with different permissions access the Internet in the areas
specified by the administrator. This approach ensures that only related policies
need to be configured on devices in the specified areas. Otherwise, policy
configuration and O&M will be difficult.
● Authentication Control Point and Authentication Admission Point

Selection
– If 802.1X or MAC address authentication (both are Layer 2 authentication
technologies) is used, the authentication point must be on the same
network segment as the user host.
– If Portal authentication (Layer 3 authentication technology) is used, the
Portal server and user host must be reachable to each other.
– It is recommended that policy association be deployed. With policy
association, the gateway functions as the authentication control point,
and the access device as the authentication admission point, which
simplifies policy deployment.
2.8.3.3.2 Free Mobility Solution Design

The free mobility solution allows a user to obtain the same network access policy
regardless of the user's location and IP address changes on a campus network.
When configuring a policy, the administrator does not need to pay attention to IP
address ranges of different users, but only needs to focus on the logical access
relationships between users and servers.
● Security Group Planning

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. An administrator can define
security groups to describe and organize the sources or destinations of
network traffic. Security group planning determines the number of security
groups to be created.
Security groups are divided into the following types based on network objects:
– Dynamic security group: It is comprised of users or terminals that can
access the network only after authentication.
– Static security group: It is comprised of terminals using fixed IP addresses,
including data center servers, interfaces of network devices, and users
who access the network using fixed IP addresses without authentication.
When a security group is bound to multiple authorization rules, it is a
dynamic security group; when a security group is bound to multiple IP
addresses or IP network segments, it is a static security group. Differences
between them are as follows:

– The IP addresses of users in dynamic security groups are not fixed and
are dynamically bound to security groups after user authentication. After
user accounts are de-registered, such binding relationships are
dynamically canceled. The mappings between user IP addresses and
security groups remain valid only when users are online. If the policy
enforcement point is also an authentication point, the mappings between
IP addresses and security groups can be dynamically generated based on
the authorized security group information. Alternatively, you can obtain
such mappings by configuring IP-security group entry subscription on the
controller. The mappings between IP addresses and security groups are
also called IP-security group entries.
– IP addresses of static security groups are fixed. Mappings between IP
addresses and security groups are defined by administrators on the
controller and then synchronized to the policy enforcement point.
The best solution for designing a server security group is to ensure that
servers of the same type or security level are deployed on the same network
segment based on proper IP address planning. In addition, ensure that ports
on the same server do not provide services of different security levels. For
example, do not use one server to provide public network services for the
Internet and provide limited resource storage services for the intranet.
Otherwise, security groups are hard to define and data leakage may occur.
● Security Group Policy Planning
A security group policy can directly reflect whether two security groups can
communicate with each other. When planning a security group policy, you
only need to set the security group policy between two groups to permit or
deny based on whether the two groups can communicate with each other.
The administrator can configure permission policies through an intuitive
policy matrix on the controller.
Take the policy direction into account when planning security group policies.
Generally, inbound and outbound packets are transmitted between two
terminals.
Traffic from A to B and traffic from B to A are not related to each other.
Huawei switches match policies for traffic from A to B and from B to A
separately to determine whether to forward the traffic. Therefore, only the
source and destination security groups of packets are checked during policy
enforcement. If access from A to B is permitted and from B to A is denied, all
packets sent from A to B will be permitted, and all packets sent from B to A
will be discarded regardless of whether A or B initiates the access. The default
policy of switches is permit.
Network access usually requires bidirectional communication. Therefore, to
simplify management, you only need to consider the permissions for user
security groups to access other users and servers when planning security
group policies.
– To prevent users from accessing a security group, you only need to
configure a unidirectional deny rule.
– To allow users to access a security group, you only need to configure a
unidirectional permit rule.
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-19. 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", you do not
need to configure the permit/deny rule. The default inter-group policy is used,
with the default rule "permit".
Table 2-19 Policy plan

Policy A B C D
A Permit Deny Permi Permit

t
B Empty NA Empty NA
C Deny Deny Permi Permit

t
D Empty NA Empty NA
The controller 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-19, 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.
● Location Selection for Authentication Points and Policy Enforcement
Points
Typically, the user gateway functions as the authentication point and policy
enforcement point with the free mobility function deployed. Major reasons
are as follows:
– There are a large number of access switches. Configuring the
authentication function on each access switch requires a heavy workload
and leads to difficulties in management.
– The controller needs to synchronize permission policies to policy
enforcement points. If access switches are used as authentication points,
the number of policy enforcement points will be greatly increased. This
increases the workload and difficulty of device management on the
controller and prolongs the policy synchronization time.
To prevent users on a Layer 2 network connected to an upstream user
gateway from communicating with each other, you can configure Layer 2
isolation. In this way, communication traffic of the users must pass through
the user gateway.
When the free mobility function is deployed, if multiple policy enforcement
points exist or authentication points are separated from policy enforcement
points, you need to configure IP-security group entry subscription to
synchronize IP-security group entries of authentication users between
different policy enforcement points and between authentication points and
policy enforcement points. For details about the planning, see Table 2-20.

Table 2-20 IP-security group entry subscription configuration plan

User WAC IP-Security Group Entry Description
Gatew Locatio Subscription
ay n
Locatio
n
Core Standal Recommended. If the authentication control

switch one Configure IP-security point connected to the user
WAC, group entry subscription gateway does not support
which related to wireless user free mobility, you can use
is groups on the core the controller to configure
connect switch through the IP-security group entry
ed to controller to implement subscription for the
the unified policy control for authentication users of the
core wired and wireless users authentication control point
device on the core switch. on the user gateway. This
in off- helps achieve unified policy
path control on the user
mode gateway.
Core Native Not required. The core

switch WAC, switch functions as the
which only authentication point
is and policy enforcement
integrat point and can
ed in synchronize all IP-
the security group entries.
core
switch
2.8.3.4 Terminal Admission Security 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. Thus, it becomes difficult to manage such a large number of terminals of
different types that access a campus network. 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 enables refined
management on terminals from multiple dimensions, for example, collecting and
displaying traffic statistics by terminal type and delivering specified authorization
policies. For dumb terminals using MAC address authentication, iMaster NCE-
Campus provides automatic admission based on terminal identification results.
This reduces the configuration workload for administrators.
2.8.3.4.1 Terminal Identification Method Design

To view 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 terminals are DHCP-assigned or statically
configured.
Based on the collected information, traverse the items one by one according to
Table 2-21 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. If the passive fingerprint-based
identification methods cannot meet terminal identification requirements, enable
the proactive scanning and identification methods, such as SNMP Query and
Nmap.
Table 2-21 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
device address assignment scenarios)
manufacturers)
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

The network administrator can enable terminal identification and its dependent
functions on corresponding devices through iMaster NCE-Campus. Refer to the
following table for more information.
Table 2-22 How to enable the terminal identification function
Identification Enabled On Function Enabled at the Same Time

Method
MAC OUI Access switches -

and APs
HTTP Portal -
UserAgent authentication
devices
DHCP Option Access switches DHCP snooping needs to be enabled on

and APs access switches. By default, DHCP
snooping is enabled on APs.
LLDP Access switches -

and APs
mDNS Access switches mDNS snooping needs to be enabled on

and APs access switches and APs.
SNMP Query Controller -

(enabling the
SNMP scanning
function)
Nmap Controller -
(enabling the
Nmap function
after installing the
Nmap plug-in)
NOTE
● In non-authentication scenarios, the controller can display information about wired

terminals only after the ARP snooping function is enabled on access devices.
● In the deployment scenario where iMaster NCE-Campus communicates with access
devices through a NAT device, the terminal identification methods SNMP Query and
Nmap are not supported.
● Ensure that iMaster NCE-Campus can communicate with terminals when deploying the
terminal identification methods SNMP Query and Nmap.
2.8.3.4.2 Terminal Admission 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-23 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-23 Example of policy control based on terminal identification results

Condition Admission Policy Authorization Policy
Operating system: Android User admission Authorize ACL 1
Operating system: iOS User admission Authorize ACL 2
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: ABC User admission Authorize ACL 100
Figure 2-27 illustrates the process of automatic policy delivery based on terminal
types.

Figure 2-27 Process of automatic policy delivery based on terminal types
On the iMaster NCE-Campus web UI, the administrator enables the terminal
identification function, selects terminal types, and specifies the corresponding
policies. When a terminal accesses the network, the network device can collect the
fingerprint information of the terminal and report the information to iMaster
NCE-Campus. Then iMaster NCE-Campus automatically matches the information
against the terminal fingerprint database, identifies the terminal type, and delivers
the corresponding admission and authorization policies to the terminal based on
the policies defined by the administrator.
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.
2.8.4 Intelligent Security Collaboration Design

Compared with traditional security defense, the big data-based intelligent security
collaboration solution shifts from discrete sample processing to holographic big
data analytics, from manual processing to automatic analysis, from static features
to dynamic features and full-path behavior and intent analysis. The solution
provides a comprehensive security defense system to ensure the security of
campus networks and services.
The intelligent security collaboration solution collects and processes the log
information from network and security devices using flow probes and log
collection technologies, extracts valuable information about security threat events
using big data correlation analysis technologies, displays network-wide security
situation on the HiSec Insight GUI, and supports manual or automatic response to
security threat events.
The intelligent security collaboration solution brings the following benefits to
customers:

● Detection of the network-wide security situation

The GUI intuitively presents the network-wide security situation. O&M
personnel can view risks specific to areas and key assets and obtain
suggestions for handling the risks. Maintenance personnel can quickly find
the regions and assets of which they are in charge, and take actions in terms
of security hardening according to security states and handling suggestions,
for example, upgrade the system or install patches.
● Rapid detection of security events
Based on powerful log collection and correlation analysis technologies and
scenarios that cover common security threats on campus networks, this
solution helps customers quickly detect security threat events on their
networks in real time.
● Fast response to security events
This solution helps greatly accelerate the security response speed and improve
response efficiency. Alarms are sent to notify O&M personnel of security
threats in a timely manner, and automatic security policy collaboration can be
implemented to control security threats and reduce and prevent the impact of
the threats on networks and services.
● Encrypted communication detection
Based on handshake information before traffic encryption, statistics about
encrypted traffic, and background traffic of encrypted traffic, the machine
learning algorithm is used to train traffic models, classify and identify normal
encrypted traffic and malicious encrypted traffic, and detect malicious C&C
communication in encrypted traffic.
● Proactive deception and collaborative forensics
Forged information, such as false responses, deliberate confusion, false
actions, and misleading, is used to block or overthrow the cognitive process of
attackers. By recording attack processes, powerful log correlation and big data
analytics technologies are used to extract the behavior features of attackers,
generate security policies, and broadcast the security policies to enforcers to
suppress the spread of attack behavior.
The intelligent security collaboration solution contains the following major
subsolutions: Encrypted Communication Analytics (ECA), threat deception, and
security collaboration. For details, see HUAWEI HiSec Solution Product
Documentation.
2.9 Network Deployment Design
2.9.1 Deployment Configuration Modes

Table 2-24 lists the network devices involved in the non-virtualization solution for
large- and medium-sized campus networks and the recommended deployment
configuration modes.

Table 2-24 Recommended deployment configuration modes for different network

devices
Zon Device Recommended Description
e/ Deployment
Lay Configuration
er 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 CLI 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 iMaster NCE-Campus through the
CLI, it can be used as the root
device of management subnets
below the core layer to implement
plug-and-play deployment 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's 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

Zon Device Recommended Description

e/ Deployment
Lay Configuration
er Mode
Agg Aggregation Centralized A large number of access switches

rega switch configuration on are deployed at scattered locations.
tion iMaster NCE- You are advised to onboard
laye Campus aggregation switches on iMaster
r NCE-Campus through DHCP Option
148 mode to implement plug-and-
play deployment.
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
through DHCP Option 148 mode to
implement plug-and-play
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 Option 43 mode to
implement plug-and-play
deployment.
2.9.2 Management Network Provisioning Design

Management VLAN Assignment
A great number of NEs are present on a large or midsize campus network. To
prevent a large broadcast domain from affecting the CPU processing performance
of NEs, you need to divide management VLANs by scenario. In normal cases, it is
recommended that the number of devices in a single broadcast domain be less
than or equal to 512. (The specific size of a broadcast domain can be evaluated
based on the capabilities of devices on the live network.)

Table 2-25 Management VLAN assignment modes

Management VLAN Recommended Application Scenario
Assignment Mode
One management VLAN for 1. Unified management of wired and wireless

wired and wireless NEs networks
2. Total number of wired and wireless NEs: < 512
One management VLAN for 1. Separate management of wired and wireless

wired NEs and one networks
management VLAN for 2. Number of wired NEs: < 512; number of
wireless NEs wireless NEs: < 512
One management VLAN for 1. Number of wired NEs: < 512

wired NEs and multiple 2. Number of wireless NEs: > 512
management VLANs for
wireless NEs
Multiple management Number of wired NEs: > 512; number of wireless

VLANs for both wired and NEs: > 512
wireless NEs
Management VLAN Deployment Modes

Manageme Overview Description

nt VLAN
Deployment
Mode
Manual NEs go online through VLAN 1 1. VLAN 1 has security risks

configuratio (default management VLAN). and, in most cases, needs
n of Then, the administrator sets a to be disabled after
managemen different management VLAN for network deployment.
t VLANs the NEs one by one and enables 2. The management VLAN
the uplinks of the NEs to allow needs to be configured on
packets from these management each NE one by one. In
VLANs. addition, there are
operation sequence
requirements. That is, the
management VLANs of
downstream devices can be
switched only after the
management VLANs of
upstream devices are
switched successfully.
Otherwise, downstream
devices may fail to go
online. Therefore, this
manual configuration
mode results in complex
operations.
In conclusion, this
deployment mode is not
recommended.
Managemen Only required auto-negotiated This mode is

t VLAN management VLANs (including recommended,
auto- wired and wireless management because it prevents security
negotiation VLANs) need to be configured on risks of VLAN 1 and greatly
the upstream devices in the reduces the configuration
management VLANs. Then workload.
downstream devices can
automatically go online through a
given management VLAN.
The following table describes the automatic management VLAN deployment

solutions in different management VLAN assignment scenarios.
Management VLAN Recommended Deployment Mode for

Assignment Scenario Management VLAN Auto-Negotiation
One management VLAN for Configure management VLAN auto-negotiation

wired and wireless NEs on core switches (unified management VLAN for
wired and wireless NEs).

Management VLAN Recommended Deployment Mode for

Assignment Scenario Management VLAN Auto-Negotiation
One management VLAN for Configure management VLAN auto-negotiation

wired NEs and one on core switches (configure wired and wireless
management VLAN for management VLANs separately).
wireless NEs
One management VLAN for 1. Configure an auto-negotiated management

wired NEs and multiple VLAN for wired devices on the core switch, so
management VLANs for that access and aggregation switches can go
wireless NEs online through this VLAN.
2. Configure different auto-negotiated
management VLANs for wireless devices on
different aggregation switches as planned, so
that APs can go online through these VLANs.
3. Configure the core and aggregation switches
to allow packets from the management VLANs
for wireless devices to pass through.
Note: All the preceding operations support
preconfiguration.
Multiple management 1. Configure the core and aggregation switches

VLANs for both wired and to allow packets from the management VLANs
wireless NEs for wired and wireless devices to pass through
based on the management VLAN plan.
2. Configure different management VLANs for
aggregation switches as planned.
3. Configure different auto-negotiated
management VLANs for wired and wireless
devices on different aggregation switches as
planned, so that access switches and APs can
go online through corresponding management
VLANs.
Note: All the preceding operations support
preconfiguration.
Management IP Address Deployment Modes

After proper management VLAN assignment is complete on the management
network of a large or midsize campus network, aggregation and access devices
usually implement plug-and-play deployment in DHCP mode. However, DHCP-
assigned IP addresses are unfixed, whereas devices with common service software
installed (such as the RADIUS server) on an enterprise network typically need
fixed IP addresses. A static IP address can be manually or automatically configured
for a device. The recommended usage scenarios of the two modes are described
below.

Static Description Recommended Application

Manageme Scenario
nt IP
Address
Deployment
Mode
Manually Configure a management IP This mode applies to

configuring address for each NE. scenarios where static IP
a static IP addresses are required and
address must be planned (for
example, IP addresses are
used to identify NE
locations).
Automaticall Reserve some IP addresses in the This mode applies to

y DHCP address pool of the scenarios where static IP
configuring management VLAN for the addresses are required but
a static IP controller to automatically assign do not need to be planned.
address static IP addresses to NEs. When
a device goes online using a
dynamic IP address, the
controller automatically delivers
a static IP address to the device.
NOTE
Planned static IP addresses cannot overlap with IP addresses in the dynamic IP address
pool. If the dynamic IP address pool contains a static IP address, you need to remove it
from the dynamic IP address pool.
2.9.3 Time Sequence Differences Between Deployment and

Planning
On a large or midsize campus network, two deployment modes are available:
Onboard devices and then determine the network topology
During network deployment, the administrator uses the methods described in
section 10.1 "Deployment Configuration Modes" to onboard devices. If there are
aggregated links between the devices, the redundant links will be blocked by STP
because link aggregation has not been configured when the devices are installed
and onboarded. After the devices go online and register with the controller, the
administrator checks the topology and deploys link aggregation and service
configurations on the controller.
Import the network plan and then onboard devices
During network deployment, the administrator enters device ESNs and specifies
stack members and aggregated links on the controller to complete network
topology planning. Alternatively, the administrator can import the preceding
planning information in batches using a template. Using a template to import
data in batches simplifies operations and is therefore recommended. Then, the

administrator uses the methods described in section 10.1 "Deployment

Configuration Modes" to onboard devices. After devices go online and register
with the controller, it automatically checks whether the actual topology of the
devices is the same as the planned one. If cables are incorrectly connected during
installation, the controller immediately notifies the administrator.
The administrator is advised to plan the network first and then onboard devices. If
the network cannot be planned in advance, the administrator can onboard devices
and then determine the network topology.
NOTE
The management port of modular switches does not support a default IP address.
Therefore, to log in to the web system of a modular switch through its management port,
you need to configure an IP address in advance.
2.10 Network O&M Design
2.10.1 Basic Network O&M

iMaster NCE-Campus provides comprehensive basic network management for
managed devices to meet basic customer network O&M requirements. Table 2-26
describes the major basic network O&M functions supported by iMaster NCE-
Campus.
Table 2-26 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 query and display of operation, security, Portal user

manageme login and logout, device login and logout, and RADIUS user
nt 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

Basic O&M Description

Function
Device ● Allows administrators to upload, download, and activate device

license license files.
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.10.2 Intelligent Network O&M
2.10.2.1 Overview of Intelligent O&M

The basic network O&M capabilities of iMaster NCE-Campus can satisfy routine
network O&M needs. However, basic network O&M cannot accommodate
networks with high network O&M requirements in the face of increasingly
complex network application traffic and large network scale. Basic network O&M
faces the following challenges:
1. Only device metrics are monitored. However, user experience may be poor
even though the metrics are normal. Basic O&M lacks means of correlatively
analyzing clients and the network.
2. Network faults can be detected only after receiving users' complaints. As a
result, faults cannot be effectively and proactively identified and analyzed.
Huawei's intelligent network analysis platform iMaster NCE-CampusInsight applies
AI to the O&M field and adopts Telemetry technology to collect performance
indicators and log data of network devices. By using big data, AI algorithms, and
more advanced analytics technologies as well as leveraging scenario-specific
continuous learning and expert experience accumulation, iMaster NCE-
CampusInsight frees O&M personnel from nerve-wracking alarms and noises,
making user network experience visualized and O&M automated and intelligent.
2.10.2.2 Intelligent O&M Solution Architecture

iMaster NCE-CampusInsight uses Huawei's big data analytics platform, receives
device data through Telemetry technology, and analyzes and displays network
data through intelligent algorithms.
Figure 1 Logical architecture of iMaster NCE-CampusInsight

The overall solution architecture contains three layers. The bottom layer is the
campus network device layer. It provides data collection capabilities in multiple
dimensions, such as client, radio, AP, switch, and user log, and sends the data to
iMaster NCE-CampusInsight through Telemetry technology. The middle layer is the
iMaster NCE-CampusInsight data analysis layer. It delivers big data storage (for
real-time traffic preprocessing, offline traffic distributed processing, and data
storage services) and data analysis services (for pattern recognition and intelligent
engine). The top layer is the service provisioning layer. It offers customers final
data analysis services, including network visibility, campus service analysis,
intelligent wireless network, and user application experience.
Table 2-27 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.
Wireless device in-service rate: Collect statistics on the
wireless device in-service rate, evaluate the overall wireless
network availability, and identify out-of-service issues of
wireless devices.


ry on
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.
Integra The integrated topology displays quality analysis and

ted horizontal comparison for each site based on the wireless
topolog service access success rate, intelligently analyzes issue
y patterns, identifies issue boundaries, and provides
preliminary analysis of root causes.
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
analysis indicators and logs, and displays information about affected
APs and clients based on each issue indicator.
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.


ry on
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.
Intellig Intellig iMaster NCE-CampusInsight collects KPIs and radio

ent ent parameters reported by devices and uses intelligent
wireless radio algorithms to calculate the load prediction information in
networ calibrat the next calibration period. In addition, it accurately
k ion identifies the network topology and edge AP list by utilizing
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.
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.

2.10.2.3 Deployment Design of the Intelligent O&M Solution

The intelligent O&M solution consists of iMaster NCE-CampusInsight,
CloudCampus@AC-Campus, and devices. Currently, iMaster NCE-CampusInsight
can manage and perform intelligent analysis on Huawei cloud switches and APs.
● Network bandwidth design
Devices need to periodically report data to iMaster NCE-CampusInsight.
Therefore, the campus network needs to reserve bandwidth for data
reporting. The average bandwidth consumed by each device is 3 kbit/s.
● Installation location design
iMaster NCE-CampusInsight and iMaster NCE-Campus can be deployed at
different locations. They can collaborate with each other as long as network
connectivity is achieved. To avoid the instability of the intermediate network,
you are advised to deploy them in the same location, for example, a DC.
● Server deployment and selection design
The iMaster NCE-CampusInsight server can be deployed in cluster or
standalone mode. Select the deployment mode and node type based on the
network scale and configure the corresponding software and hardware
resources. For details about the software and hardware requirements, see the
iMaster NCE-CampusInsight product documentation of the corresponding
version.
2.10.2.4 Precautions for Intelligent O&M Design

1. Precautions for network deployment design:
– During network deployment, ensure that APs are reachable to iMaster
NCE-CampusInsight so that they can send KPI performance data and logs
to it.
– During network deployment, make sure that the device clock is
synchronous with the clock of iMaster NCE-CampusInsight. You are
advised to deploy an NTP server on the network to synchronize the
system clock of the network.
2. Precautions for designing the integrated topology function:
– When group fault analysis is performed based on the integrated topology
function, only the common tree network topology is supported.
3. Precautions for designing the audio and video quality analysis function:
– The audio and video quality analysis function requires devices to send
related logs to iMaster NCE-CampusInsight. You are advised to configure
the same log sending interval for switches and WLAN devices. The
maximum difference between the log sending intervals cannot exceed
20s.
4. Precautions for designing the intelligent radio calibration function:
– Intelligent radio calibration and traditional radio calibration cannot be
deployed on APs in the same region at the same time.

01-02 Solution Design

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

01-02 Solution Design

Uploaded by

Copyright:

Available Formats

CloudCampus Solution

Design and Deployment Guide Deployment Guide

2.1 Network Architecture Design

2.1 Network Architecture Design

2.1.1 Network Topology

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

Figure 2-1 Topology of a large or midsize campus network

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

department or zone to a dedicated server zone. In addition, the aggregation

2.1.2 Egress Network Architecture

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

Figure 2-2 Egress network topologies

On a large or midsize campus network, the number of routes on the egress is

If one of the following conditions is met, networking 1 can be used:

● Egress link type

2.1.3 Hierarchical Architecture of the Intranet

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

Figure 2-3 Hierarchical physical network architecture

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

Figure 2-4 Layered network architecture design

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

In the preceding calculations, the calculation results need to be rounded up.

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

● Calculate the number of aggregation switches. If the number is greater than

2.2 Network Management Zone Design

2.2.1 Networking Design

Figure 2-5 Basic networking of the network management zone

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

2.2.2 Server and Gateway Interconnection Design

Figure 2-6 Server-switch interconnection in active-backup mode

Load balancing mode

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

Figure 2-7 Server-switch interconnection in load balancing mode

2.2.3 Design for Communication Between the Network

Table 2-1 Description about communication between common software systems

Communicatio Software Description

Communicatio iMaster NCE- Manages devices on the campus intranet,

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

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

2.3 Basic Network Service Design

2.3.1 VLAN Design

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

Table 2-2 VLAN design suggestions

Service VLAN Assign VLANs by logical area, geographical area, personnel

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

Category Design Suggestion

Management ● Egress network devices: Use Layer 3 service interfaces as

Interconnection An interconnection VLAN is usually configured between two

2.3.2 IP Address Design

● Uniqueness: Each host on an IP network must have a unique IP address. Even

Issue 04 (2021-10-10) Copyright © Huawei Technologies Co., Ltd. 29

● Easy maintenance: Device and service address segments need to be clearly

Table 2-3 Suggestions for the IP address design

Service IP address Service addresses are the IP addresses of servers, hosts,

Management IP A Layer 2 device uses the VLANIF interface's IP address

Interconnection IP An interconnection address is the IP address of an

Issue 04 (2021-10-10) Copyright © Huawei Technologies Co., Ltd. 30

2.3.3 DHCP Design

2.3.4 Gateway Design

Issue 04 (2021-10-10) Copyright © Huawei Technologies Co., Ltd. 31

2.3.5 Routing Design

Issue 04 (2021-10-10) Copyright © Huawei Technologies Co., Ltd. 32

Figure 2-9 OSPF area division on a campus network

● Using special areas can optimize routing entries on routers in non-backbone