05 NCE-Campus Scenario Baseline Introduction

iMaster NCE-Campus V300R023C00 Scenarios
Page 1 Copyright © 2024 Huawei Technologies Co., Ltd. All rights reserved.
Foreword
 With the rapid development of cloud computing, the on-demand cloud service mode becomes
more popular so that the traditional network management mode also experiences great changes.
In this situation, the cloud-based network management has been a tendency, as well as a new
model for enterprise network construction, operations and maintenance (O&M).
 This document mainly introduces the networking solutions and scenario-specific delivery
baselines of iMaster NCE-Campus.
Objectives
 On completion of this course, you will be able to:
 Understand all scenarios of iMaster NCE-Campus.
 Understand the networking solutions and deployment constraints of iMaster NCE-Campus in on-
premises scenarios.
 Understand the networking solutions and deployment constraints of iMaster NCE-Campus in MSP-
owned cloud scenarios.
 Understand the networking solutions and deployment constraints of iMaster NCE-Campus in Huawei
public cloud scenarios.
Contents
 iMaster NCE-Campus Scenario Overview
 On-Premises Scenario
 MSP-owned Cloud Scenario
 Huawei Public Cloud Scenario
iMaster NCE-Campus Scenario Overview Level-1
Level-2 Category Description
Category
Unified management of campus networks (VLAN
iMaster NCE-Campus VLAN campus networking), including the wireless network using WACs
scenario and Fit APs, wired VLAN, and access authentication
EasyBranch Network digital map Application/VIP user assurance services.
Access Unified management of campus networks (VXLAN
Device LAN VXLAN SD- SRv6 Traditional IoT VXLAN campus networking), including the wireless network using WACs
authentication
management management fabric WAN policy NMS service scenario and Fit APs, wired VLAN, and access authentication
service services.
iMaster NCE-Fabric iMaster NCE-FAN SecoManager iMaster NCE-IP eSight Agile Controller-IoT Cloud management Cloud management of small and midsize campus networks,
scenario for small including the wireless network using cloud APs, wired
On-premises MSP-owned Huawei public and midsize VLAN, AR/firewall as egress gateways, SD-WAN services,
scenario cloud scenario cloud scenario campus networks and access authentication services.
On-premises SD-WAN scenario SD-WAN services for multi-branch enterprise networks.
11 10 Traditional scenario
One enterprise
IoT management Traditional CE NE
ME60 Firewall
Third-party
network scenario
Management of one SRv6 WAN
NMS LSW switch router device
iMaster NCE-Campus functions only as an access
Authentication
IoT gateway
9 PON management 8 One SRv6 server scenario
authentication server and replaces Agile Controller-Campus
1.0.
Access
1 authentication network Traditional NMS
Traditional NMS capabilities are supported when traditional
switches and other non-cloud managed devices are deployed
service
2 Cloud Wi-Fi 4 VLAN management SRv6
scenario
on a campus.
management POL management is supported in campus networks using
Wired user PC NE routerAR Firewall IP+POL campus
the POL technology.
NE router IoT gateway management and service-oriented integration of
IoT management
Wireless
user
Laptop
Aggregation Core 7 SD-WAN IoT applications.
Cloud management of small and midsize campus networks,
Cloud AP SD-WAN Cloud management
Tablet Access switch switch including the wireless network using cloud APs, wired
scenario for small
switch VLAN, AR/firewall as egress gateways, SD-WAN services,
VPN remote
3 WAC/AP network
AR/ MSP-owned
and midsize
and access authentication services. MSPs can manage all
user
Phone management 5 VXLAN management
AR
vAR cloud scenario
campus networks
branch features or only some of them.
Guest
Printer
6Branch gateway MSP provides SD-WAN services for multi-branch enterprise
SD-WAN scenario networks, such as SD-WAN interconnection services and
Network POP WAN acceleration.
management IPsec Firewall Cloud management Cloud management of small and midsize campus networks,
Camera Aggregation Core
personnel scenario for small including the cloud Wi-Fi, cloud WAC, VLAN, egress
WAC & Fit AP Access switch switch switch POP/Private and midsize gateway/SD-WAN, and access authentication. Tenants can
User & Terminal AR Firewall cloud/Public Huawei public campus networks subscribe to all branch features or only some of them.
Campus/Branch cloud cloud scenario SD-WAN services for multi-branch enterprise networks.
Wireless network Wired network Egress network Tenants use the public cloud for self-O&M, or MSPs use the
network SD-WAN scenario
public cloud to provide MSP-managed O&M and POP WAN
acceleration.
Contents
 Service Scenario
 Controller Deployment

VLAN Campus VXLAN Campus Cloud Management SD-WAN WAN SRv6 Authentication Server Traditional NMS IP+POL
VLAN Campus: Recommended Wired authentication admission point

Wired authentication control point
Wireless authentication admission point
Wireless authentication control point
Networking GW
Wired policy enforcement point
Gateway
Wireless policy enforcement point
Native WAC
Networking Single-Layer Switch Two-Layer Switch Two-Layer Switch Networking + Three-Layer Switch Three-Layer Switch Networking + Standalone
Solution Networking + Native WAC Networking + Native WAC Standalone WAC Networking + Native WAC WAC
S7700 + S12700E
GW
S6730-H SRUHX + S8700 GW GW GW

AC6805
GW S12700E
X6E
S5735-L/
S5736-S/ S5735-L/ AirEngine
S6730-H/
Networking S5735-L/ S5731-S/ S5736-S/ 9700-M1 S6730-H/
S6730-H-V2
S5735-L-V2 S5735-L-V2 S5731-S/ S6730-H-V2
S5735-L-V2 S5735-L/
S5735-L/
S5736-S/ S5736-S/
S5731-S/ S5731-S/
S5731-L S5735-L-V2
S5735-L-V2
S5731-L
S5731-L
S5731-L S5731-L
Two-layer switch networking is Three-layer switch networking is used. A
Two-layer switch networking is Three-layer switch networking is
used. A standalone WAC is standalone WAC is connected to the core switch in
Single-layer switch networking used. The core switch functions used. The core switch functions
connected to the core switch in off- off-path mode, and policy association is deployed
is used, where remote units as the native WAC, and policy as the native WAC, and policy
path mode (the core switch can be a between the core switch and access switches
Description (RUs), APs, and native WACs association is deployed between association is deployed between
V600 model). Policy association is (access switches are not V600 models). The
can be connected directly to the the core switch and access the core switch and access
deployed between the core switch authentication point and policy enforcement point
core switch. switches (switches are not V600 switches (switches are not V600
and access switches (switches are are on the core switch, and the core switch needs
models). models).
not V600 models). to subscribe to IP-security group entries.
Number of < 2000 (dual-stack/single- < 10,000 (IPv4/IPv6 dual-stack); < 30,000 (IPv4/IPv6 dual-stack); < 50,000 (IPv4
< 5000 (IPv4/IPv6 dual-stack); < 10,000 (IPv4 single-stack)
terminals stack) < 30,000 (IPv4 single-stack) single-stack)
•Networking constraints:
1. V600 switches do not support the native WAC function. Therefore, standalone WACs must be deployed in off-path mode.
2. V600 switches do not support policy association. The core switches allow packets from aggregation/access switches in authentication-free mode. The access switches allow BPDU packets.
Page3.7 V600 switches do not
Copyright © 2024
support wired Huawei
Portal Technologies
authentication Co.,
or terminal Ltd. All rights reserved.
identification.
VLAN Campus: Typical Application Scenario

Overview: The office network reconstruction of a government office building involves Wi-
Government External Fi 6 reconstruction, IPv6 reconstruction for wired networks, and further optimization of the
Internet
network institution current access authentication, in order to meet the increasing service requirements of the
customer.
Controller:
Security protection • The controller is deployed in the management zone in minimum cluster mode. The
zone servers in the management zone are connected to the core switches through management
switches. The controller provides network management and access authentication
Management zone services.
Wireless network:
• Native WAC + Fit AP networking: Wireless APs are deployed in indoor and outdoor areas
VM of the office building and connected to the core switches through PoE access switches.
iMaster NCE-Campus
Core switch The core switches function as the native WACs to manage the wireless APs.
Wired network:
• Two-layer switch (core + access) networking is used. The core switches set up a stack,
and a stacked access switch is deployed on every two floors to improve device reliability
on a single node. Wired access switches and wireless access switches are separated.
Floor 2 Floor 4 Floor 20
User access authentication:
Stack
Stack Stack • Through interconnecting with the OA platform of the government system, the controller
implements access authentication for different types of users, including wired office
Access switch Access switch ... Access switch users, wireless users, guests, and dumb terminals. 802.1X authentication is used for wired
and wireless office access, with the AD server used to manage user accounts. MAC
address authentication is used for dumb terminals, such as printers, phones, and video
terminals. For guest access, Portal authentication (SMS authentication) is used.
Government office building
VLAN Campus: Main Functions and Constraints

(1/2)
Item Function and Constraint
1. If the number of online users is greater than 20,000, you are advised to deploy the minimum or distributed cluster with IAE nodes. The cluster provides network management and secondary authentication
services, and the IAE node provides the primary authentication service. Alternatively, the cluster provides only network management, and the IAE node provides authentication active/standby or load balancing.
Controller
2. If the number of online users is less than or equal to 20,000, a single-node system with IAE nodes can be used. The single-node system provides network management and secondary authentication services, and
deployment
the IAE node provides the primary authentication service.
3. For non-commercial customers, a single-node system can be used only when the number of users is less than 1000. No reliability is provided.
Device The controller can manage devices through NETCONF and SNMP. For details about managed devices and device management protocols, see the Device Mapping Panorama by clicking the following URL:
management https://support.huawei.com/enterprise/en/doc/EDOC1100331189?idPath=24030814|250382819|250382820|250987403|250852420
Traditional Huawei campus devices (LSWs and WACs) and network devices such as firewalls, CE series devices, NE series devices, and ME60 series devices are managed by the controller through SNMP. The
SNMP-based
following monitoring and O&M functions are supported: device performance monitoring, device alarm reporting, device configuration file management, device upgrade, CLI-based service configuration, WLAN
device management
resource monitoring, region monitoring, agile report, and SLA management. The traditional NMS also supports these functions.
Third-party network devices are managed through SNMP. The following functions are supported: device alarm reporting and basic information monitoring. For details about device mapping and specifications, see
Third-party device
the document by clicking the following URL:
management
https://support.huawei.com/enterprise/en/doc/EDOC1100331190?idPath=24030814%7C250382819%7C250382820%7C250987403%7C250852420
• In a VLAN campus scenario, you are advised to use network plan import for the overall deployment solution. Core switches and WACs are manually deployed, and aggregation switches, access switches, and
Device deployment
APs are managed through DHCP Option 148, management VLAN auto-negotiation, and Eth-Trunk auto-negotiation. You are advised not to use the default VLAN 1, which may cause broadcast storms.
mode
• SNMP-managed devices do not support the preceding plug-and-play deployment solution. Those devices can only be proactively managed through SNMP-based scanning.
1. Stacks must be manually set up and then managed by the controller. Stacks cannot be set up through the controller.
Switch stacking
2. When the controller manages a stack, it is recommended that the number of switches in the stack be less than or equal to four. In addition, only switches of the same series can be added to the stack.
VLAN Campus: Main Functions and Constraints (2/2)

Item Function and Constraint
1. V5 switches support the site configuration function of the controller, while only some functions of a V600 switch can be configured using site configuration. GND-based single-device configuration is recommended to
configure V600 switches, with hierarchical templates adopted to implement batch configuration.
Switch management
2. The functions of V5 switches that cannot be configured on the controller GUI can be configured in CLI over YANG mode on the controller. For the functions of V600 switches that cannot be configured using GND, you can
submit a requirement and incorporate it into the version development plan.
1. The controller supports only network monitoring for V5 WACs and Fit APs and cannot deliver configurations to these devices.
2. Two switches (native WACs) set up a stack to ensure reliability, instead of directly deploying two switches (the WACs on the two switches cannot be defined as a WAC group).
3. WACs do not involve switching to the cloud mode. When a WAC is managed by the controller, there is no need to clear its configurations or restart it.
WAC management
4. When an existing WAC is migrated to the cloud, the IDs of the Fit APs managed by the WAC can remain unchanged, and the original wireless service is not affected.
5. For a SNMP-managed WAC, the AP management license for WACs and the AP management license from the controller need to be purchased. For a NETCONF-managed WAC, only the AP management license from the
controller needs to be purchased.
1. New devices can be used to replace legacy devices and carry their services. However, this only applies to cloud managed devices of the same model. (Note: ACs and Fit APs cannot be replaced.)
Device replacement 2. In manual configuration scenarios, the controller can only re-deliver configurations on the controller to the replaced devices, while manually configured commands can only be manually restored or restored using a backup
configuration file.
New Project:
1. Service configurations are delivered all from NCE-Campus, preventing using local device commands.
2. If there are commands that are not supported by NCE-Campus:
For switches of the VRPv5 version, configure them on the Site CLI of NCE-Campus.
Recommended For switches of the V600 version, submit requirements based on projects for quick adaptation.
Configuration 3. If all devices in site are V600 version , you are recommended to use the new GND/hierarchical template to configure services and disable the site configuration.
Solution For commands that are not supported, submit requirements based on projects for quick adaptation.
Reconstruction of existing Project:
1. By default, SNMP is recommended for migrating devices to cloud.
2. If customers require free mobility, terminal identification, or analyzer interconnection, use NETCONF to manage devices and deliver the standard NETCONF management solution.
(Clear the configurations of the device and deliver the configurations from the controller again.)
• You are advised to use iMaster NCE-Campus as the authentication server. If a third-party authentication server exists on the live network, you can directly connect devices to the third-party authentication server. If free mobility
is required, you can deploy iMaster NCE-Campus as a relay agent and the devices can be connected to the third-party authentication server through iMaster NCE-Campus.
• 802.1X authentication is recommended for wireless access of employees, MAC address authentication for dumb terminals, and Portal authentication for guests. You are advised to set different SSIDs for employees and guests.
Access authentication
• You are advised to manage user accounts through local management by iMaster NCE-Campus or interconnection with the AD/LDAP server.
• If the customer's self-developed OA system and development customization are involved, single-point evaluation is required. In addition, the differentiated authorization function is restricted because iMaster NCE-Campus does
not have user group information.
iMaster NCE-Campus is preset with parameters for interconnection with some SMS platforms, and these parameters can be directly used. For details, click the following URL:
SMS authentication https://support.huawei.com/hedex/hdx.do?docid=EDOC1100350599&id=ZH-CN_TOPIC_0160050630
If interconnection parameters for an SMS platform are not preset, the customer needs to provide information about the SMS platform and specific format parameters, and purchase professional customization services.
For details about configuration capabilities, click the following URL （ Only Chinese Temporary ） :
Pagehttps://3ms.huawei.com/documents/docinfo/931375382333517824?bookstackId=337384633191337984&catalogId=286318974438756352
10 Copyright © 2024 Huawei Technologies Co., Ltd. All rights reserved.
VXLAN Campus: Networking Wired authentication

admission point
Wired authentication control
point
Wireless authentication
admission point
Peer-link
M-LAG
Solutions (1/2)
control point
Wired policy Wireless policy enforcement Eth-Trunk
enforcement point point
GW Gateway Native WAC
GW Wireless gateway
Centralized Gateway + VXLAN Centralized Gateway + VXLAN Deployed

Networking Distributed Gateway + VXLAN Deployed Distributed Gateway + VXLAN Deployed Across
Deployed Across Core and Access Across Core and Aggregation Layers + Native
Solution Across Core and Access Layers Core and Aggregation Layers
Layers + Native WAC WAC
Egress
Core AC6805 AC6805

S12700E S12700E
S12700E (border) S12700E
Core GW
GW
GW GW
(border)
WAC
Aggregation
VXLAN S6730-H
VXLAN S77 VXLAN
(edge)
S6730-H-V2
Networking VXLAN S12700E S5735-L S6730-H
S5731-H S6730-H-V2
S8700 S5736-S GW GW
S5732-H S5735-L S8706/10
S5731-H S5731-S
Access S5732-H-V2 S5736-S
Access S5732-H S5735-L-V2
(edge) S5755-H S5731-S GW GW
S5732-H-V2 S5735I-L-V2
S5735-L-V2
S5735I-L-V2 S5755-H
RU AP RU AP RU AP RU AP
S5731-L Wi-Fi 6/7 RU AP RU AP RU AP
S5731-L Wi-Fi 6/7 RU AP
1. Two-layer or three-layer switch

1. Three-layer switch networking: The core switch 1. Two-layer or three-layer switch networking: The 1. Three-layer switch networking: The core switch
networking: The core switch functions as
functions as the border node, aggregation switches core switch functions as the border node, access functions as the border node, aggregation switches
the border node, access switches function
function as edge nodes, and the centralized gateway switches function as edge nodes, distributed function as edge nodes, and a standalone WAC is
as edge nodes, and the centralized gateway
is deployed on the core switch. gateways are used, and authentication points are connected to the core switch in off-path mode.
is deployed on the core switch.
2. Select standalone or native WACs as required. deployed on access switches. Distributed gateways are used.
2. Select standalone or native WACs as
Description 3. Policy association is configured between the 2. Standalone WACs are used. 2. Standalone WACs are used.
required.
aggregation switches and access switches (non- 3. Authentication points are deployed on access 3. Policy association is configured between the
3. Authentication points are deployed on
V600 models). switches. aggregation switches and access switches (non-V600
access switches.
4. Layer 2 VXLAN networking can be deployed 4. Layer 2 VXLAN networking can be deployed models).
4. Layer 2 VXLAN networking can be
together, with gateways deployed outside the together, with gateways deployed outside the 4. Layer 2 VXLAN networking can be deployed together,
deployed together, with gateways deployed
campus. campus. with gateways deployed outside the campus.
outside the campus.
Number of
< 10,000 (IPv4/IPv6 dual-stack); < 30,000 (IPv4 single-stack) < 30,000 (IPv4/IPv6 dual-stack); < 100,000 (IPv4 single-stack)
terminals
VXLAN Campus: Networking Wired authentication admission point

Wired authentication control point
admission point
control point
Peer-link
M-LAG
Solutions (2/2)
Wired policy enforcement point Wireless policy
enforcement point Eth-Trunk
GW Gateway Native WAC
GW Wireless gateway
Distributed Gateway + VXLAN Deployed Distributed Gateway + VXLAN Deployed Distributed Gateway + VXLAN
Networking Centralized Gateway + VXLAN Deployed Across
Across Core and Access Layers (Dual Across Core and Aggregation Layers (Dual Deployed Across Core and Aggregation
Solution Core and Aggregation Layers (M-LAG)
Border Nodes) Border Nodes) Layers (M-LAG)
Networking AC6805 AirEngine 9700-M1
AC6805 Egress
AC6805
S16704/08 Core
(border) S16700
S12700E GW GW
GW GW
S12700E GW GW GW GW
S16704/08 S16704/08
S6730-H-V2 M-LAG M-LAG
S12700E+MPUE+X6H S8706/10 Aggregation (edge) S6730-H-V2
S77 S6730-H GW GW
GW GW
S12700E S6730-H-V2
S5731-H S5735-L S5736-S
S5736-S
S8700 GW GW
S8706/10 S5735-L-V2
S5732-H S5736-S S5735-L/S-V2
S5735I-L-V2
S5732-H-V2 S5735I-L-V2
S5731-S S12700E+MPUE+X6E Access
S5755-H GW
S5735-L-V2
GW
S5735-S-V2
S5735I-L-V2
RU AP
RU AP RU
SDN-based automatic orchestration is SDN-based automatic orchestration is

1. Three-layer switch networking: The core switch
not supported. not supported.
1. Three-layer switch networking: The core switch functions as the border node, aggregation
1. Three-layer switch networking: The core switch functions as
1. Two-layer or three-layer switch networking: The functions as the border node, aggregation switches switches function as edge nodes, and
the border node, aggregation switches function as edge
core switch functions as the border node, access function as edge nodes, and a standalone WAC is distributed gateways are used.
nodes, and centralized gateways are used.
switches function as edge nodes, and distributed connected to the core switch in off-path mode. 2. The standalone WAC is connected to the core
2. The standalone WAC is connected to the core switch in off-
gateways are used. Distributed gateways are used. switch in off-path mode.
Description path mode, and native WACs are not supported.
2. The standalone WAC is connected to the core switch 2. The standalone WAC is connected to the core switch in 3. Access switches function as authentication
3. Access switches function as authentication points (M-LAG
in off-path mode. off-path mode. points (M-LAG aggregation switches do not
aggregation switches do not support policy association).
3. Access switches function as authentication points. 3. Policy association is configured between the support policy association).
4. Layer 2 VXLAN networking can be deployed together, with
aggregation switches and access switches (non-V600 4. Layer 2 VXLAN networking can be deployed
gateways deployed outside the campus.
models). together, with gateways deployed outside the
campus.
1. < 30,000 (IPv4/IPv6 dual-stack); < 100,000 (IPv4
single-stack)
Number of < 30,000 (IPv4/IPv6 dual-stack); < 100,000 (IPv4 single- < 30,000 (IPv4/IPv6 dual-stack); < 100,000 (IPv4
2. Core switches: S12700E + MPUE + X6H; Number of < 10,000 (IPv4/IPv6 dual-stack); < 30,000 (IPv4 single-stack)
terminals stack) single-stack)
terminals: < 100,000 (IPv4/IPv6 dual-stack and IPv4
single-stack users)
VXLAN Campus: Typical Application

Out-of-band
Scenario (1/2)
O&M management zone Traditional zone
management zone
Overview: A manufacturing enterprise builds a new campus with less than 10,000
terminals. Considering the solution advancement and cost, the enterprise plans to build the
Production
DC zone zone office network through deploying the SDN VXLAN across core and aggregation layers,
with access switches using traditional VLAN access.
... Campus network architecture:
• The campus network consists of the office zone, production zone, data center (DC)
zone, and egress zone, and those zones are interconnected through the campus core.
The network in the office zone uses the SDN VXLAN campus solution.
Campus core • The campus has an independent O&M management zone where software such as
iMaster NCE-Campus/iMaster NCE-CampusInsight is deployed. In addition, the
campus has an out-of-band management network, to which all network devices are
Core connected through management interfaces.
(office) USG6680E SDN VXLAN design:
AirEngine 9700-M (WAC)
S12704E VTE
CSS
 Core: Two S12704E switches set up a stack to function as a core switch of the entire
P office network. Two USG6680E devices are connected to the core switch in off-path
mode to isolate user services. Two AirEngine9700-M devices (WACs) are connected
VXLAN to the core switch in off-path mode to manage wireless APs, and they are deployed in
a two-node system (active/standby). Wireless service traffic is forwarded in a
iStack centralized manner.
CSS CSS
VTE VTE
Aggregation VTE  Aggregation: Each building deploys two S12700E switches at the aggregation layer
(office)
P S12700E-8 P S6730
P S12700E-4 for wired and wireless switches.
iStack
 Access: S5731 switches are used for wired office access, and S5736 switches provide
S5736
...
PoE power supply for wireless office APs.
S5731 ...
iStack iStack iStack iStack Access authentication solution design:
...
• Access authentication includes wired access authentication and wireless access
Terminal access AP access authentication. MAC address authentication is used for wired and wireless access,
and the MAC address whitelist is strictly controlled. Some dumb terminals do not
require authentication.
AP5760-51
Office building 1 Office building 2 Office building 3
VXLAN Campus: Typical Application Scenario

(2/2) Overview: A university reconstructs its campus network, and the number of terminals is estimated to be less than
30,000.
Internet DC Campus network structure:
• The campus network of the university covers its multiple campuses. Two neighboring campuses are directly
connected to each other through optical fibers. If a campus is far away from another campus, they are
interconnected through the education MAN.
Online behavior • The campus egress core is deployed on each campus. Based on the campus size, aggregation and access
management switches, or only access switches are deployed within the campus.
Firewall
• The campus network is connected to the gateways (ME60) through the egress core of the central campus,
CE12808 and then connected to the Internet through the gateways. Firewalls, online behavior management devices, anti-
DDoS devices, and SSL VPN devices are deployed at the Internet egress zone of the central campus to
ME60 O&M management implement secure access.
zone • The campus DC is connected to the egress gateways (ME60) in off-path mode. Campus applications access the
DC through the ME60 gateways.
• WACs are connected to the egress core in off-path mode to implement wireless network control.
WAC CSS
AC6805 VTE Campus ... • The controller connects independent switches to the egress core in off-path mode to manage the entire campus
P egress core network.
S12708E SDN VXLAN design:
iMaster NCE-Campus
• The Layer 2 VXLAN is deployed across core and aggregation layers, the intermediate network is allowed to
traverse the education MAN, and two-layer access switches can be connected to aggregation switches. In
addition, ME60 gateways serve as access gateways for students and teachers, while only some gateways for
Core on dumb terminals are deployed on campus switches.
campus A
VTE Building aggregation
Access authentication solution design:
S12704E P S6730
CSS CSS Education • Authentication protocol: MAC address authentication is used for smart terminals and dumb terminals,
VTE VTE
MAN 802.1X authentication for employee office, and Portal authentication for guests and Internet access services.
P P • Authentication point: ME60 gateways serve as authentication point devices, and Portal authentication is used.
Core on iStack iStack • Authentication server:
campus B VTE Core on campus
VTE • iMaster NCE-Campus serves as an authentication server to implement user authentication.
S12704E P C
S6730 P • iMaster NCE-Campus interconnects with online behavior management devices and synchronizes user
information to the devices.
Central campus • iMaster NCE-Campus interconnects with servers of Srun or Dr.COM to implement authentication and
accounting for students.
VXLAN Campus: Main Functions and

Constraints (1/3)
Category Function and Constraint
1. If the number of online users is greater than 20,000, you are advised to deploy the minimum or distributed cluster with IAE nodes. The cluster provides network management and secondary authentication services,
and the IAE node provides the primary authentication service. Alternatively, the cluster provides only network management, and the IAE node provides authentication active/standby or load balancing.
Controller deployment 2. If the number of online users is less than or equal to 20,000, a single-node system with IAE nodes can be used. The single-node system provides network management and secondary authentication services, and the
IAE node provides the primary authentication service.
1. VXLAN deployment is supported in on-premises scenarios, and is not supported in Huawei public cloud and MSP-owned cloud scenarios.
2. Centralized fabric, distributed fabric, and Layer 2 VXLAN transparent transmission are supported, and controller deployment modes are selected according to these three networking modes. For capacity
VXLAN networking
specifications of the deployment modes, click the following URL:
https://support.huawei.com/hedex/hdx.do?docid=EDOC1100331205&id=EN-US_TOPIC_0159670496
Device model check For details about device models supporting VXLANs, see the LSW sheet in iMaster NCE-Campus V300R023C00 Device Mapping and System Versions.
A VXLAN fabric network supports two networking modes:

1. VXLAN deployed across core and aggregation layers: In a campus network reconstruction scenario, low-end access switches or third-party switches that do not support VXLANs can be reused.
2. VXLAN deployed across core and access layers: In a campus network construction scenario, the entire network is virtualized to implement automatic overlay network deployment.
The device roles on the fabric network are as follows:
3. Border node: is a border gateway. It transmits traffic between the VXLAN fabric network and external networks. Centralized fabric networking supports one group, and distributed fabric networking supports eight
Fabric device role
groups.
4. Edge node: can be a Layer 2 VXLAN gateway or Layer 3 VXLAN gateway. In a cluster deployment scenario, centralized fabric networking supports 1000 groups, and distributed fabric networking supports 512
groups.
5. Access node (wired): is used for wired access. A wired access node can be combined with an edge node (VXLAN deployed across core and access layers). If not combined, it can be an extended node.
6. Route reflector (RR): is a BGP EVPN RR on the VXLAN and is usually deployed on a border gateway. By default, two RRs are supported.
Three types of global resources can be planned for tenants: VLAN, VXLAN Network Identifier (VNI), and bridge domain (BD). During fabric network orchestration, related resources are automatically allocated from
Fabric resource
the global resource pool. Note that VLAN resources are globally managed by tenants and cannot be reused between multiple fabrics. If VLAN resources are reused between multiple fabrics, it is
management
recommended that the multi-tenant mode be used.
The controller supports automatic deployment of fabric underlay networks and automatic provisioning of VLANIF interfaces, loopback interfaces, VTEP IP addresses, and routes required for establishing BGP EVPNs
on VXLAN fabrics.
1. Underlay interconnection resource planning, including the interconnection VLAN resource pool, interconnection IP address pool, and loopback interface IP address pool. The interconnection resource pools are
Underlay network global resources of tenants and cannot be reused between multiple fabrics. If the resource pools need to be reused, the multi-tenant mode is recommended.
automation 2. Underlay OSPF automation: Single-area and multi-area orchestration is supported. The restrictions are as follows:
• Automatic OSPF orchestration is supported at a site only when there are only NETCONF-managed devices. Cross-site OSPF does not support automatic orchestration, and OSPF needs to be configured for each site.
• The controller interconnection interface for automatic orchestration uses a VLANIF interface by default, and a VLAN and an IP address are automatically allocated for the VLANIF interface. The multi-area model
generates areas for each edge node. If the customer does not want automatic orchestration, it is recommended that automatic routing domain configuration be disabled.

Constraints (2/3)
Layer 3 shared egress, Layer 3 exclusive egress, and Layer 2 shared egress are supported.
1. When an external network with a Layer 3 exclusive egress is created, the controller are deployed on devices only when a virtual network (VN) is bound to the external network.
2. External gateway egresses connect to external networks via static routes, OSPF, or BGP. In static routing scenarios, NQA can be associated with static routes for detection.
External Dynamic routing does not support routing policy filtering. If routing policies are required, run commands to add them.
gateway 3. In dual-border networking, two border nodes can be added to the external gateway as egress devices. Forwarding path selection can be implemented through load balancing,
device active/standby, and service active/standby configured on fabrics.
4. In IPv6 scenarios, dynamic routes cannot be configured for external gateways.
5. A Layer 2 shared egress does not support multiple border nodes.
1. Based on where network service resources are deployed, the controller can be directly connected to a server, directly connected to a switch, or connected to a remote server.
Network service resources support DHCP, third-party RADIUS servers, third-party Portal servers, and other types of servers.
2. A centralized or distributed fabric gateway cannot function as the DHCP server for terminals. The DHCP server needs to be deployed by the customer independently, while the
Network service fabric network provides a DHCP relay agent to obtain IP addresses from the DHCP server.
resource 3. Currently, the DHCPv4 relay function is implemented via rerouting in distributed gateway scenarios, with VXLAN tunnels deployed between edge nodes.
4. If the DHCP server is deployed outside the campus, configure the controller to connect to a remote server, insteading of directly connecting to a switch.
5. In dual-stack scenarios, Portal authentication servers support IPv4/IPv6 dual stack, with IPv6 addresses used for accessing Portal pages. In addition, Portal servers use IPv4
addresses to interact with devices, while RADIUS authentication servers use only IPv4 addresses to interact with devices.
1. Subnets can be deployed on VNs as user gateways. A single VN supports a maximum of 300 subnets, and subnets support IPv4/IPv6 dual stack. The constraints are as follows:
a. Switching between single-stack and dual-stack is not supported.
b. Terminals supporting static IP addresses and terminals supporting DHCP cannot be both configured on a subnet. Otherwise, IP address conflicts may occur (especially when
Overlay VN Layer 2 isolation is enabled, because terminals cannot detect address conflicts through gratuitous ARP broadcast packets).
2. A single VN can be bound to a maximum of 16 external gateways, and IP addresses configured for these external gateways must be unique.
3. A maximum of eight network service resources can be bound to a VN, and only one DHCP network service resource can be bound to a VN. DHCP network service resources
cannot be configured for all subnets.

Constraints (3/3)
1. The multicast source is located outside the fabric, and the requesters are located inside the fabric.
1) Layer 2 multicast is supported: The requesters and multicast source are in the same Layer 2 forwarding domain.
VXLAN 2) Layer 3 multicast is supported. The requesters and multicast source are in the Layer 3 forwarding domain. Layer 3 multicast packets are converted to Layer 2 packets on border nodes and forwarded as Layer 2
multicast multicast packets inside the fabric. Only the gateways of the Layer 3 exclusive egress type support Layer 3 multicast, and V600 devices do not support Layer 3 multicast.
2. When the multicast source and requesters are inside the fabric, only Layer 2 multicast is supported.
3. IPv6 subnets do not support IGMP snooping.
By default, VNs cannot access each other. If VNs need to access each other, use the following methods:
VN 1. Configure border nodes to implement mutual access between Layer 3 VNs.
communication 2. Configure routes between VNs through an external network to implement mutual access. The external network can be accessed through the Layer 3 exclusive egress (usually a firewall).
Policy Orchestration of policy association is supported. In centralized scenarios, core or aggregation devices can be used as control points. In distributed scenarios, aggregation devices are used as control points by default. V600
association devices do not support policy association. When V600 devices are used as access points, aggregation switches function as both authentication control points and enforcement points.
Free mobility can be configured based on fabrics.

1. The policy matrix can be associated with a VN. In this case, all policies in the policy matrix take effect only on this VN. Only one policy control matrix can be created for a VN.
Free mobility 2. A policy can take effect on all authentication control point devices on a VN. You can also configure the policy to take effect on a certain authentication control point device.
3. You do not need to configure IP-security group entry subscription for all network devices on a VXLAN fabric. VXLAN packets carry security group information, so that a destination device can decapsulate VXLAN
packets and identify the security group of the source user for policy matrix matching.
M-LAG The controller does not support automatic VXLAN orchestration when devices use M-LAG networking. If M-LAG networking is used on a fabric, the underlay and overlay networks must be manually deployed. In this
networking case, the controller provides only plug-and-play and device monitoring and O&M functions.
• It is recommended that iMaster NCE-Campus be used as the authentication server. If a third-party authentication server exists on the live network, iMaster NCE-Campus can serve as a relay agent and devices can be
connected to the third-party authentication server through iMaster NCE-Campus. In this way, free mobility can be implemented.
• 802.1X authentication is recommended for wireless access of employees, MAC address authentication for dumb terminals, and Portal authentication for guests. You are advised to set different SSIDs for employees and
Access guests.
authentication • You are advised to manage user accounts through local management by iMaster NCE-Campus or interconnection with the AD/LDAP server.
• If the customer's self-developed OA system and development customization are involved, single-point evaluation is required. In addition, the differentiated authorization function is restricted because iMaster NCE-
Campus does not have user group information.
• In VXLAN scenarios, Portal authentication supports only Portal 2.0 and does not support HACA. Therefore, the API relay function is limited.
Cloud Management Branch: Networking Solutions

AR + Layer 3 Switch + Layer 2 AR + Layer 3 Switch + Layer 2
Networking Single-Device AR + Cloud AP AR/Firewall + Layer 2 Switch AR + Layer 3 Switch+ Layer 2
Switch + Native WAC Switch+ Standalone WAC
Solution Networking Networking + Cloud AP Networking Switch + Cloud AP Networking
Networking Networking
AR651W-8P (PoE power AR6280 USG6525E AR8140
AR6121E (egress > 1 Gbit/s) AR6280 USG6525E AR
supply) AR8140 USG6525F AR8700
AR651 (egress < 1 Gbit/s) AR8140 USG6525F
AR651 (local power AR5710-H (egress < 1 USG6650E
AR611W-LTE4CN supply) Gbit/s) Firewall USG6655F
USG6525E AirEngine
AR617VW-LTE4EA AR5710-S8P (PoE power AR6710 (egress > 1 USG6525F AR Firewall
AR Firewall S77 9700-M1
supply) Gbit/s)
Wi-Fi 6/7 S6730-H S8700
AR5710-S (local power
S6730-H Core switch S6730-H-V2 Native WAC S12700E
supply)
AR Firewall
Networking AR S6730-H-V2
S5735-L
S5735-L 6735-S
AP AR Switch S5735-L-V2 S6730-H-V2
S5731-S S5735-L S5731-S
Switch S5731-S
S5731-S Switch S5735-L-V2
AP S5735-L-V2
S5736-S
AP AP Switch
AP
AP
Single-cloud AP Two-layer switch networking: Provides Two-layer switch networking: Provides

AR + cloud AP Single-layer switch networking: Three-layer switch networking: Native
networking provides both wired and wireless access, with ARs both wired and wireless access, with ARs
networking: Provides Provides both wired and wireless WACs or standalone WACs are
wireless access. Single-AR or firewalls as user gateways. Cloud APs or firewalls as user gateways. Native
both wired and wireless access, with ARs or firewalls as user deployed at sites. The user gateway is
networking provides wired are deployed at sites. If ARs are used as WACs are deployed at sites. If ARs are
Description access, with ARs as gateways. If ARs are used as gateways, deployed on the core LSW. Firewalls are
and wireless access, and gateways, egresses support SD-WAN used as gateways, egresses support SD-
gateways. Egresses egresses support SD-WAN services. deployed to provide security protection.
the AR as an egress device services. Firewalls can be used if WAN services. Firewalls can be used if
support SD-WAN Firewalls can be used if customers have ARs function as egress devices and
supports SD-WAN customers have strong security customers have strong security
services. strong security requirements. support SD-WAN services.
services. requirements. requirements.
Small branch
Number of Mini branch Small branch Small or midsize branch Midsize branch
Number of terminals <
terminals Number of terminals < 50 Number of terminals < 1000 Number of terminals < 2000 Number of terminals < 10,000
200
Cloud Management Branch: Typical Application

Scenario
 A large chain supermarket has stores in more than 30 European countries
DC
and in the United States. The number of its network devices is expected
to reach 200,000.
 Store networking: Huawei switches and cloud APs are used to provide
DHCP RADIUS iMaster NCE- SNAP
Campus NMS (Nagios) wired and wireless terminal access in stores. Network egress firewalls
server server
and routers are not provided by Huawei. VPN tunnels are established
between the stores and HQ DC. The network management traffic between
l
ne
VPN tunnel
n VP iMaster NCE-Campus and the stores is transmitted over the VPN tunnels.
tu N
N
VP
tu
nn  Controller deployment: iMaster NCE-Campus is deployed in a 17-node
el
distributed cluster in the customer's HQ DC, and DR is deployed to
ensure reliability. iMaster NCE-Campus provides cloud NMS functions
LSW- LSW- LSW- such as batch configuration, monitoring, and O&M, instead of
LAN1 LAN2 LAN2
authentication services.
 Network access authentication: 802.1X and MAC address authentication
are used for wired networks, and Portal authentication for wireless
Employee Wi-Fi Guest Wi-Fi Employee Wi-Fi Guest Wi-Fi networks. The customer provides Portal servers and RADIUS servers,
PC 1 Cashier
which are connected to switches and APs.
Germany France United States
Cloud Management Branch: Main Functions and

Constraints (1/2)
Controller Based on the number of sites, number of network devices, and number of end users, the controller can be deployed in a minimum cluster or a distributed cluster (6-node, 9-node, and 17-
deploymen node).
t DR should be deployed in multi-branch cloud management scenarios. If nearby authentication or distributed authentication is required, remote authentication nodes should be deployed.
1. The southbound and northbound bandwidths for external access depend on the number of managed devices. Every 10,000 devices can consume 35 Mbit/s bandwidth. In this case, a
minimum cluster that manages 30,000 devices requires 105 Mbit/s bandwidth.
Latency If the batch device upgrade function is used, a maximum of 150 devices can be upgraded concurrently. In this case, the bandwidth must be at least 400 Mbit/s. If the bandwidth is
and insufficient, a few authentication services may fail.
The latency for accessing the southbound network must be less than or equal to 200 ms, and the latency for accessing the northbound network must be less than or equal to 100 ms.
bandwidth
2. In access control scenarios, the communication latency between iMaster NCE-Campus and external data sources (such as AD/LDAP and RADIUS servers) must be less than or equal
to 5 ms. Otherwise, the concurrent authentication performance may deteriorate.
3. In remote authentication scenarios, the latency between the primary cluster and remote authentication nodes is less than 200 ms.
1. If the networking between the HQ/DC and a branch network requires passing through the Internet, the post-NAT public IP addresses need to be provided during the controller
NAT installation and deployment.
2. It is recommended that the northbound management IP address and southbound service IP address be translated into different IP addresses through NAT, in order to separate
scenario northbound and southbound traffic. When public IP addresses are insufficient, the northbound and southbound IP addresses can be translated into one IP address through NAT. In this
case, policies and QoS control need to be configured at the network egress based on IP addresses and interfaces.
Sites are divided based on physical locations.
Site design 1.
Cloud APs and WACs/Fit APs cannot co-exist at the same site.
2. In cloud AP mode, after an SSID is configured for a site, the configuration is delivered to all APs at the site by default. After the delivery, users can roam within the site. In some
special scenarios, you can set different tags to group APs at a site and configure SSIDs by group. Users can roam only within a group.
Device deployment modes include web/CLI-based manual deployment, registration query center-based deployment, app-based deployment, DHCP Option 148-based deployment, USB-
based deployment, and email-based deployment.
1. Deployment modes supported by different devices:
AR router: registration query center-based, DHCP Option 148-based, USB-based, web/CLI-based, and email-based (in SD-WAN scenarios) deployment
Device Firewall: registration query center-based, USB-based, and web/CLI-based deployment (DHCP Option 148-based deployment is not supported).
LSW (campus switch): registration query center-based, DHCP Option 148-based, and web/CLI-based deployment
deployment WAC: web/CLI-based deployment (manual switching to the cloud mode for DHCP-based deployment, or manually configuring WACs to interconnect with iMaster NCE-Campus)
mode
AP: registration query center-based, DHCP Option 148-based, and web/CLI-based deployment
2. Recommended deployment modes in branch scenarios:
Egress gateway: web/CLI-based, registration query center-based (obtaining egress IP addresses through DHCP), or email-based (in SD-WAN scenarios) deployment
Switch/AP in branches: DHCP Option 148-based (Huawei egress gateways are used, and VLAN 1 is used by default) or registration query center-based deployment
WAC: web/CLI-based manual deployment
Cloud Management Branch: Main Functions and

Constraints (2/2)
1. The number of cloud APs at a single site should be less than or equal to 128. If the number exceeds 128, managing APs by group is required to improve radio calibration and load
Cloud AP balancing.
management 2. In cloud AP mode, all configurations are delivered by the controller. For the configurations that cannot be delivered, submit a requirement and incorporate it into the version
development plan.
The controller uses NETCONF to manage firewalls only in cloud management scenarios (firewalls as branch egress gateways). In other scenarios, the controller uses SNMP to manage
firewalls by default. Constraints for NETCONF-managed firewalls:
1. When a V300 firewall (V5) is switched to the cloud mode, its configurations are cleared and the firewall is restarted. In addition, only the uplink ports, default routes, and controller
registration parameters can be configured using local CLIs. Other service configurations cannot be configured using local CLIs. This constraint does not apply to V600 firewalls.
2. Only the HSB group (mirroring mode) and single-node system are supported. A maximum of two firewalls of the same model can be added to an HSB group (mirroring mode).
Firewall
3. In mirroring mode, configuration synchronization between the active and standby firewalls is disabled by default. For V5 firewalls, the controller delivers configurations to the
management
active and standby firewalls by default. For V600 firewalls, you need to bind hierarchical templates to the active and standby firewalls to implement unified configuration.
4. V5 firewalls support site configuration on the controller. V600 firewalls use site configuration on the controller only to configure security policies; and for other configurations,
single-device configuration (GND) is used, and hierarchical templates can be used to implement batch configuration.
5. For the functions that cannot be configured on the controller GUI, the controller supplements the missing functions of V5 firewalls through CLI over YANG, while for V600
firewalls, you need to submit a requirement and incorporate it into the version development plan.
1. AR management supports cloud management and SD-WAN scenarios. Note that the purchased licenses for these two scenarios are different.
2. In a cloud management scenario, V5 AR routers do not involve switching to the cloud mode. Before an AR is managed by the controller, the configurations of the AR are not
cleared and the AR are not restarted. However, once the AR is managed by the controller, the save operation cannot be performed using local CLIs. (The configurations of the AR
AR
before the management are used as deployment configurations, and the AR can be restored to its deployment configurations.)
management
3. V5 ARs support site configuration on the controller, while V600 ARs uses single-device configuration (GND) and implements batch configuration through hierarchical templates.
4. For the functions that cannot be configured on the controller GUI, the controller supplements the missing functions of V5 ARs through CLI over YANG, while for V600 ARs, you
need to submit a requirement and incorporate it into the version development plan.
In a LAN-WAN convergence scenario, iMaster NCE-Campus uses public virtual IP addresses to manage egress ARs and private virtual IP addresses to manage LAN-side devices.
Authentication packets between LAN-side devices and iMaster NCE-Campus are transmitted through SD-WAN tunnels.
Access In a LAN scenario, VPNs or SD-WANs are provided by third-party vendors. It is recommended that authentication packets between LAN-side devices and iMaster NCE-Campus be
authentication transmitted through tunnels.
In a WAN scenario without VPNs or SD-WANs, if authentication traffic between LAN-side devices and iMaster NCE-Campus passes through the Internet, Portal authentication
(HACA) is recommended.
Automatic configuration capabilities of the controller （ Only Chinese Temporary ） :

https://3ms.huawei.com/documents/docinfo/931375382333517824?bookstackId=337384633191337984&catalogId=286318974438756352
SD-WAN: Networking Solutions (1/2)

Networking
Hub-Spoke Networking Full-Mesh Networking
Scenario
Networking Service A Service B
1.1.1.1/24 HQ site
1.1.1.1/24 4.4.4.4/24
HQ site 1 HQ site 2
advertisement
advertisement
Route
Route
VRRP VRRP
OSPF OSPF VRRP
t
en Service traffic
em
Rou
rtis
ve
ad
te ad
Internet access
ute Service traffic
Ro service (active)
vert
Internet access
is
Service A
eme
(active) service (standby)

nt
Service B (active) Branch & HQ

services
Route advertisement
Mutual access between Communication

branch sites between branches
Routing Transmission
Transmission Routing
Domain Network
Network Domain
2.2.2.2/24 3.3.3.3/24 ISP 1 ISP 1
Internet 2.2.2.2/24 3.3.3.3/24 Internet
Description Site
In the hub-spoke B
topology, the enterprise HQSite
andCDCs function as hub
ISPsites;
2 Site B
In the full-mesh ISPeach
Site C communicate with
topology, branches can directly 2 other,
enterprise branches function as spoke sites and centrally access server applications without the need to divert traffic through intermediate nodes. The full-mesh
deployed at the HQ or DCs through WANs. If enterprise branches need to topology is applicable to small enterprises with a small number of sites or large
communicate with each other, traffic between them is transmitted through the hub enterprises whose branches need to collaborate with each other.
sites. A maximum of 200 sites (400 CPEs)
Number of sites on a single network ≤ 2000 (2000 CPEs)
SD-WAN: Networking Solutions (2/2)

Networking
Hierarchical Networking Customized Networking
Scenario
Area 1
Internet access
HQ site Branch & HQ
site A services Hub 1 Hub 2
Communication between
branches
Backbone area
Networking Level-2
Level-2 branch
branch
site C
site B Global centralized
Internet access site
Site 1 Site 4
Centralized
Internet
access site in
area 2
Level-3 Level-3 Site 2 Site 3
Level-3 branch branch branch
site B1 site B2 site C1
Area 2 Area 3 Customized networking mainly applies to irregular networking.
The hierarchical networking model can be considered as a combination of single- • No tunnel is established between some sites in full-mesh networking. Specifically, the controller
layer networking models. A WAN is divided into multiple areas, which are blocks tunnels between some sites.
interconnected through a centralized backbone area. In this way, a large number of • Tunnels are added between some sites in hub-spoke networking. Specifically, tunnels between
sites can communicate with each other across areas. The hierarchical network some sites are configured on the controller. In addition, priorities can be set the tunnels at the
Description
model features a clear network structure and excellent scalability and is therefore next-hop sites.
applicable to large enterprises and multinational enterprises that have a large As shown in the preceding figure, a hub-spoke network is created for four sites and two hubs. A
number of sites or sites widely distributed. direct tunnel needs to be created between site 3 and site 4. Mutual access through the direct tunnel is
This networking mode is not recommended. Flat networking is recommended. preferred. If the direct tunnel cannot be used, site 3 and site 4 can communicate with each other
through the hubs.
SD-WAN: Typical Application Scenario

The applications of a bank are mainly deployed in its DCs. The services flow passes
iMaster DCI through the central equipment room and intra-city equipment room, and then is sent to the
NCE-Campus IDC 2
IDC 1 backbone network. Most traffic is north-south traffic from branches to DCs. Branches do
not need to communicate with each other. Even if they need to communicate with each
other, the communication traffic needs to pass through hubs.
Hub 2
Hub 1
(standby)
Solution design
(active)
• Networking: The network between the sub-branches and tier-1 branch is flattened and
Hub
uses the hub-spoke networking topology. The tier-1 branch is configured as an SD-WAN
*5G LNS hub site, and the sub-branches are spoke sites.
Central equipment room Intra-city equipment room • O&M: Each tier-1 branch independently manages its own SD-WAN sites and networks.
Different tier-1 branches are independent of each other.
Tier-1 branch Management component deployment
• Controller: For DR, the controller is deployed in the active and standby equipment
rooms of the tier-1 branch. The active and standby equipment rooms are interconnected
with each other at Layer 3.
ISP 1 ISP 2 LTE/5G • Downlink router: It is recommended that the existing traditional routers be retained, or
new NE routers or switches be added to terminate MSTP links. Ensure that the WAN-
side interfaces between the sub-branches, and the underlay IP address of the tier-1 branch
are reachable.
• Hub: Multiple hub nodes are independently deployed in the tier-1 branch, and are
connected to underlay egress gateways in off-path mode. The egress gateways
communicate with LAN-side devices directly through the underlay network.
Sub-branch Spoke • RR: The RRs are co-deployed with the hub site and are deployed in the central
Sub-branch 1 Sub-branch 2 equipment room and intra-city equipment room of the tier-1 branch. In addition, the RR
can communicate with all link routers.
• Two devices are deployed in each sub-branch, which is a spoke site.
CPE 1 CPE 2 CPE 1 CPE 2
SD-WAN: Main Functions and Constraints

Based on the number of sites, number of network devices, and number of end users, the controller can be deployed in a minimum cluster or a distributed cluster (6-node, 9-
Controller node, and 17-node).
deployment DR of the controller is recommended only when SD-WAN services are involved.
If network access authentication is required and nearby authentication or distributed authentication is needed, remote authentication nodes should be deployed.
Single cluster with
Devices can connect to the controller deployed in single-cluster mode through multiple southbound addresses. Some devices are connected to the Internet and managed using
multiple
public virtual IP addresses, while some devices are connected only to the MPLS VPN and managed using private virtual IP addresses.
southbound
Constraint: NAT devices are required for a single cluster with multiple southbound interfaces. Multiple southbound NICs cannot be directly configured on the controller.
addresses
The southbound and northbound bandwidths for external access depend on the number of managed devices. Every 10,000 devices can consume 35 Mbit/s bandwidth. In this
case, a minimum cluster that manages 30,000 devices requires 105 Mbit/s bandwidth.
Latency and If the batch device upgrade function is used, a maximum of 150 devices can be upgraded concurrently. In this case, the bandwidth must be at least 400 Mbit/s. If the bandwidth
bandwidth is insufficient, a few authentication services may fail.
The latency for accessing the southbound network must be less than or equal to 200 ms, and the latency for accessing the northbound network must be less than or equal to 100
ms.
Site design A site supports a single gateway or dual gateways. If dual gateways are used, these two gateways must be of the same model.
Device deployment Supports registration query center-based deployment, DHCP-based deployment, USB-based deployment, and email-based deployment.
mode The controller does not generate deployment configurations for E1-IMA (ATM), IMA-Group, Eth-Trunk, and serial interfaces. You need to manually deploy these interfaces.
WAN topology Supports hub-spoke and full-mesh. For special networking, you can customize the topology as required.
Supports local breakout, centralized Internet access, and hybrid Internet access.
Site-to-Internet Constraints:
solution 1. For local access to the Internet, load balancing can be performed only on a single device, but not for multiple links between dual gateways.
2. By default, multiple VPNs cannot communicate with each other. However, after local Internet access is enabled for multiple VPNs, they can communicate with each other.
Supports QoS policies, traffic steering policies, and WAN optimization policies.
Traffic policy Constraint: The traffic classifier and traffic behavior templates cannot be modified because they are referenced. To modify these templates, you can switch the traffic classifier
template of the policies.
Analyzes network-wide applications as well as intra-site and inter-site performance data.
Traffic monitoring
Constraint: Monitoring performance data by VPN (department) is not supported.
One SRv6 WAN for City Commercial Banks and

Rural Credit Cooperatives
DC-P31 DC-PE31 Project background
HQ DC
between the DC-PEs and BR-PEs of the

SRv6 centralized path computation and
China has released the related policy documents to propose to accelerate innovation
optimization is performed for the paths

DC-PE32
Remote equipment of IPv6 Enhanced network technologies, such as SRv6. China wants to develop
1 .Core backbone network

DC-P32 room C industry standards in terms of IPv6 monitoring and evaluation, new IPv6 Enhanced
DC-PE11 DC-P11 DC-P21 DC-PE21 technologies, and IPv6 single-stack applications, and actively promote the
development of related national standards. This involves IPv6 Enhanced
tier-1 branch.
SRv6 policy reconstruction in 17 key industries, including the finance industry.
Tunnel
SRv6
Centralized path computation
iMaster NCE-Campus
and optimization
DC-P12 DC-P22
DC-PE12 DC-PE22
Networking solution
WAN-P1 WAN-P2
Intra-city equipment room A Intra-city equipment room B  Unified and automatic management and control
MSTP private line of the
ISP
Centrally manage and control the core backbone network and WAN access
network, orchestrate network services, automatically provision services, and
BR-PE1 BR-PE2 perform SRv6 policy-based centralized path computation and optimization.
User domain of the Tunnel termination  Core backbone network
tier-1 branch Service
Branch core The core backbone network is a dual-plane network consisting of DC-PEs, DC-
Branch switch Service domain of implementation
the tier-1 branch Ps, and WAN-Ps of the DC, and BR-PEs of the tier-1 branch. It carries DCI
services and services between the DC and tier-1 branch. NE8000-M8, NE8000-
WAN access: policy-based

Downlink Downlink
traffic steering for an

router hub 1 router hub 2 M6, and NE8000-M1C are used.
2. WAN access
SRv6 tunnel
SRv6
 Access WAN
network
MSTP private line of the ISP Tunnel Egress routers of a sub-branch connect to the downlink routers of the tier-1
branch through at least two ISP private lines, and SRv6-based SPR intelligent
traffic steering is implemented, improving the reliability and utilization of
Sub- private line links. NE8000-M6 and NE8000-M1C are recommended for hub
Spoke 1 Spoke 2 Spoke 3 Spoke 4
branch Sub-branch Sub-branch sites, and AR6710 for spoke sites.
Network Solution Deployment and Maintenance Guide on Huawei Smart WAN for City Commercial
Banks and Rural Credit Cooperatives （ Only Chinese Temporary ） :
Page 26 https://support.huawei.com/enterprise/zh/doc/EDOC1100285825
Copyright © 2024 Huawei Technologies Co., Ltd. All rights reserved.
One SRv6 WAN for District/County Governments

e-Government
Project background
Internet access
extranet egress Internet egress
• Devices on district/county e-Government extranets are outdated, leading to
Municipal
zone
insufficient bandwidth and reliability. This severely limits the development of e-
WAN
Government extranet services and smart cities. Therefore, the live network needs to
be upgraded and reconstructed, implementing broadband upgrade or private line
access for district/county and township-/village-level government agencies, and
villagers' committees.
NetEngine 8000 M8 Solution

District/County
switching zone
management
• Use NE series routers to implement access for government agencies and villagers'
Security
Situational
zone
iMaster NCE
core
Log audit awareness committees. In addition, the routers integrate security capabilities such as firewall,
IPS, and antivirus to provide value-added services.
• Perform security hardening for the security management zone and Internet access
S7703/7706 SDP controller IOC screen
zone based on China's Classified Protection 2.0.
IPv6 Enhanced • Upgrade and reconstruct the secure access platform to provide secure and convenient
NetEngine A821E/822E/813E access for external organizations such as enterprises.
District/County
access zone
Customer benefits
• One network for all services: Allows an e-Government extranet to cover the entire
District/County District/County Township-/Village-level Villagers' committee district, implement information sharing for the e-Government information system,
government campus government agency government agency and improves e-Government service capabilities. This enables one network for all
government services, improves the business environment, and supports economic
Network Solution Deployment and Maintenance Guide for Huawei Intelligent e-Government Extranet development.
Across District/County （ Only Chinese Temporary ） : • Rural revitalization: Provides important network support, in order to facilitate rural
https://support.huawei.com/enterprise/zh/doc/EDOC1100338137/1cc2abd2?idPath=24030814|250421931| revitalization and the reform of streamlining administration and delegating power,
250422062|251755406 and enable people to handle services nearby.
One SRv6 WAN: Comparison Between SD-WAN and SRv6

Currently, this SRv6 solution is in trial commercial use in China. Therefore, it is not recommended for projects outside China.
Item Sub-feature SD-WAN One WAN (SRv6)

Industry scenario On-premises/ISP/MSP scenarios NE co-deployment network for industries such as finance and government
No new routing protocol needs to be deployed. Ensure that IP routes of WAN interfaces
Underlay route IS-ISv6 and BGP4+ for SRv6 protocols are deployed for IPv6 networks.
are reachable, and both IPv4 and IPv6 networks are supported.
Overlay route BGP EVPN for SD-WAN (carrying TNP/IPsec SA information) BGP EVPN for SRv6
BGP LS/SR Policy is added for the controller to collect topology information and deliver path
Path control protocol No need to deploy path control protocols. Automatic path computation is available.
computation results.
GRE tunnels are automatically generated by forwarders, with high encapsulation Static planning of local SRv6 BE/TE tunnels is supported. The controller computes and delivers
Overlay tunnel
efficiency. path policies.
Networking Supports interconnection with SD-WAN in loose coupling mode, with CPEs
SR traffic steering IPv6 SR is supported.
encapsulating BSIDs.
No independent IKE needs to be deployed. IPsec encryption is automatically enabled
Data encryption Independent link encryption and IKE-based IPsecv6 VPNs (being planned) are required.
for tunnels.
The local Internet access, centralized Internet access, and hybrid Internet access are
Site-to-Internet access Not supported
supported.
Site to Legacy network Supports interconnection with legacy networks through IWGs. Not supported
POP networking Supports hierarchical POP networking. Not supported
Supports automatic cloud migration to AWS, Huawei Cloud, and Alibaba Cloud.
Connection to public clouds Not supported
Microsoft Azure and e-Cloud are also supported.
Intelligent traffic steering Supports application-, priority-, and bandwidth-based traffic steering. MQC + SPR TE Policy
Experience
Path SLA detection IFIT (keepalive) Enhanced IFIT + BFD
FEC/TCP optimization/Dual fed and
WOC selective receiving/ Per-packet load Supported Not supported
balancing
Advantages: Supports underlay IPv6 programmable paths and interconnection with NE

Advantages: Applicable to hybrid WANs, featuring flexible networking, automatic routers.
tunnel creation, and comprehensive features and covering more than 90% of on- Disadvantages: High complexity (ISISv6, BGP LS/SR Policy, BGP EVPN, BFD/IFIT/TWAMP).
Advantages and
premises, ISP, and MSP scenarios. The transmission network strongly depends on the underlay network to advertise locator routes
disadvantages
Disadvantages: E2E overlay tunnels, without directly detecting or affecting underlay using IPv6 dynamic routing protocols and collect network topology information. Underlay
networks and traffic steering. IPsec/GRE tunnels need to be deployed on public networks (such as the Internet/5G). This leads to
low transmission encapsulation efficiency.
Authentication Server: Functions

Social media
authentication Authentication mode
Third-party MDM server
• Portal authentication: username and password, anonymous, SMS,
Email, and social media account
QQ Sina Weibo WeChat
Other
• 802.1X authentication: PAP, CHAP, and EAP (EAP-MD5, EAP-
Ivanti Leagsoft
User Portal page TLS, EAP-TTLS, and PEAP)
management customization
Facebook Twitter Google • MAC address authentication, PPSK authentication, and DPSK
Third-party RADIUS server authentication
Third-party Idp server • Mixed authentication: MAC address-prioritized Portal
authentication and MAC address bypass authentication
MAC
802.1X Portal
address
Portal server RADIUS server
AD server LDAP server Other Transmission protocol
• HTTP/2 and RADIUS for authentication data transmission
• NETCONF for configuration data transmission
NETCONF HTTP/2 RADIUS Radius/TSM
configuration authentication authentication Open authentication
• Third-party access devices: Cisco, H3C, and Aruba
• Third-party RADIUS server: RADIUS relay, supporting ISE and
ClearPass
• Third-party Portal server: Portal API relay/RADIUS relay
Switch AP Firewall AR Third-party ASG
• Third-party user identity source: AD/LDAP server, third-party IdP
device Single sign-on (SAML), and third-party HTTP server (API)
Authentication device
(SSO) • Social media: QQ, WeChat, Weibo, DingTalk, Facebook, Twitter,
Google account, etc
• MDM system: Ivanti, Leagsoft, QAX, Wanda, VRV, MobileIron,
etc.
• Online behavior management: Huawei, Sangfor, etc.
Authentication Server: Main Functions and

Constraints (1/2)
As an authentication server, iMaster NCE-Campus mainly interconnects with Huawei campus devices. Converged deployment of networks and authentication is recommended. Do not simply use iMaster NCE-Campus as a
Sales scenarios
RADIUS server.
It is recommended that IAE nodes be deployed to provide protocol-level reliability protection.
1. If the number of online users is greater than 20,000, you are advised to deploy the minimum or distributed cluster with IAE nodes. The cluster provides network management and secondary authentication services, and the
Controller
IAE node provides the primary authentication service. Alternatively, the cluster provides only network management, and the IAE node provides authentication active/standby or load balancing.
deployment
2. If the number of online users is less than or equal to 20,000, a single-node system with IAE nodes can be used. The single-node system provides network management and secondary authentication services, and the IAE node
provides the primary authentication service.
•The combination of IPv6 addresses (for terminals) and IPv4 addresses (for devices) is recommended. That is, iMaster NCE-Campus uses IPv4 addresses to interconnect with network devices (with RADIUS and
Portal protocols), and uses IPv4/IPv6 dual-stack Portal authentication to implement IPv4 or IPv6 access for terminals.
IPv6 networking
• IPv6 user policies (user parameter binding and terminal IPv6 address range) are not supported. Anonymous authentication cannot be configured for IPv6 terminals.
• If free mobility, online behavior management, and accounting devices are involved, separate evaluation is required based on different device capabilities.
Authentication devices managed by iMaster NCE-Campus support Portal authentication, 802.1X authentication, and MAC address authentication.
Third-party devices (tested):
Authentication
• Cisco: All series support 802.1X authentication and MAC address authentication. Only WLC series supports CWA Portal authentication.
device
• H3C: Supports 802.1X authentication, MAC address authentication, and Portal 2.0 authentication (authentication URL templates must carry device IP addresses).
• Ruijie and Aruba: Supports 802.1X authentication and MAC address authentication.
• 802.1X authentication is recommended for wireless access of employees, MAC address authentication for dumb terminals, and Portal authentication for guests. You are advised to set different SSIDs for employees and
guests.
Authentication
• It is recommended that wired authentication points be deployed on access switches for small and midsized networks, and on core or aggregation switches for large networks. Policy association is configured between the
Mode
access and aggregation switches. Currently, V600 switches do not support policy association.
• It is recommended that wireless authentication points be deployed on APs in cloud AP networking, and on WACs in WAC networking.
You are advised to manage users through local management by iMaster NCE-Campus or interconnection with the AD/LDAP server. In this way, differentiated authorization can be implemented by user group or role.
The RADIUS relay mode can be used for interconnection with the authentication server on the customer's live network.
For interconnection with the customer's self-developed OA system, the interconnection modes are as follows:
• The customer's OA system is developed based on the northbound API of iMaster NCE-Campus and configures user/user group information for the controller.
• HTTP interconnection: When a user initiates an authentication request, the controller extracts the username and password and invokes the API of the OA system for verification. (Constraint: Only Portal authentication is
supported, and all users belong to the same user group.)
User
• SAML-based SSO: The OA system provides Portal authentication. iMaster NCE-Campus redirects a user request to the OA system through the SAML protocol. After verifying the request, the OA system sends the request
management
back to the controller through the SAML protocol. (Constraint: Only Portal authentication is supported, and all users belong to the same user group.)
• API relay: The OA system provides Portal authentication. iMaster NCE-Campus redirects a user request to the OA system. After verifying the request, the OA system invokes the API of the controller to notify the
authorization result. (Constraint: Only Portal HACA authentication is supported, and all users belong to the same user group.)
• RADIUS relay: The OA system provides Portal authentication. iMaster NCE-Campus redirects a user request to the OA system. After the authentication information is entered on the Portal page of the OA system, the OA
system sends the information back to the controller. Then, the controller interconnects with the customer's RADIUS server through a RADIUS relay agent.
If the customer has social media accounts, see the list supported social media list. (Constraint: Only Portal authentication is supported, and all users belong to the same user group.)
Authentication Server: Main Functions and

Constraints (2/2)
EAP-TLS certificate authentication is supported. A terminal certificate can be obtained through the NCE Boarding function or other methods.
Certificate
The Boarding function supports single-SSID and dual-SSID, supports Android, Windows PC, and iOS OSs, and supports interconnection with built-in and
authentication
external CA certificate servers.
Supported terminal types: mobile phone (802.1X/Portal/MAC address authentication), PC (802.1X/Portal/MAC address authentication), and dumb terminal
(depending on whether the 802.1X client or browser is carried) Other terminals with 802.1X clients support 802.1X authentication, and terminals with browsers
Terminal type
support Portal authentication. MAC address authentication is used for dumb terminals that do not support 802.1X or Portal authentication. Authentication of
other terminals needs to be evaluated separately.
• Terminal identification is classified into proactive identification and passive identification.

Source of passive identification:
(1) Terminal fingerprints extracted from Portal authentication packets
(2) Terminal fingerprints extracted from DHCP and mDNS packets sent by terminals
Terminal (3) Terminal fingerprints extracted from terminal MAC addresses
management Proactive identification: Nmap-based scanning and SNMP-based scanning
• Terminal identification can easily identify terminals that use Portal authentication or dynamically obtain IP addresses through DHCP. Terminal plug-and-
play can be implemented based on the identification result.
• In scenarios where static terminals are used or Portal authentication is not performed on iMaster NCE-Campus, you need clarify the customer's expectation
and perform tests in advance. You can also inform the customer that identification precision depends on fingerprints and authentication modes.
iMaster NCE-Campus can interconnect with Ivanti, QAX, Leagsoft, Wanda TSM, VRV, and HiSec Insight. The controller can only synchronize the terminal
MDM system
compliance status to MDM systems and perform authorization control based on the compliance status. Information about other terminals cannot be
interconnection
synchronized.
Traditional NMS: Typical Application Scenarios

Type Application Scenario
LSWs are traditional campus devices and cannot be managed by NETCONF due to their outdated models or versions. The controller uses the traditional SNMP protocol to manage LSWs, and monitors and
LSW
maintains the managed devices.
WACs are traditional campus devices and cannot be managed by NETCONF due to their outdated models or versions. The controller uses the traditional SNMP protocol to manage WACs, and monitors and
WAC
APs are traditional campus devices and cannot be managed by NETCONF due to their outdated models or versions. The controller uses the traditional SNMP protocol to manage APs, and monitors and
AP
AR routers as campus egress routers are deployed in the egress zone. They are connected to the WAN of the customer, external organizations, and the Internet. The controller uses the traditional SNMP
AR router
protocol to manage AR routers, and centrally monitors the managed devices.
Campus firewalls are connected to core switches in in-path or off-path mode for security protection. The controller uses the traditional SNMP protocol to manage firewalls, and centrally monitors the managed
Firewall
devices.
ME60 ME60 devices are commonly used as campus egress gateways in universities. The controller uses the traditional SNMP protocol to manage ME60 devices, and centrally monitors the managed devices.
NE routers serve as egress devices for midsized and large campuses, and the deployment scenario is similar to AR routers. The controller uses the traditional SNMP protocol to manage NE routers, and
NE router
centrally monitors the managed devices. The price for managing an NE router is the same as managing a third-party device.
CE switches are commonly used in the scenario where a small DC is also deployed on the customer's campus. If no other NMS is available on the campus, the controller can manage CE switches, and centrally
CE switch
monitor the managed devices. The price for managing a CE switch is the same as managing a third-party device.
Traditional NMS: Comparison Between SNMP and

eSight in Managing Huawei Devices
eSight network iMaster NCE-Campus/eSight
Topology/Performance/ Device software Topology/Performance/ Device software
Smart configuration tool Smart configuration tool
Alarm/Resource management Alarm/Resource management
Configuration file Configuration file

SLA management WLAN management SLA management WLAN management
management management
Report management
Report management
Security policy
management SecoManager
Security policy
management
Network traffic analysis WLAN locating

iMaster NCE-CampusInsight
Network traffic analysis WLAN locating
Unsupported features • Customized agile reports do not support year-on-year and period-
IPsec VPN MPLS VPN Mobile on-period comparison.
• Device performance reports, link management reports, and QoS
ZTP SVF management IP topology
traffic reports are not supported.
• Compliance audit cannot be configured using CLIs.
• NETCONF can be used for device management instead.
Traditional NMS: SNMP-based Management of

Third-Party Devices
The third-party network device management solution uses SNMP and standard Management Information Base (MIB) for
adaptation management and conforms to Request for Comments (RFC), meeting the requirements for simplicity,
versatility, and standardization. Network devices from each vendor support the standard SNMP MIB. For network
devices of mainstream vendors (such as H3C, Ruijie, Cisco, and ZTE) that are pre-integrated and adapted, iMaster NCE-
Campus with the built-in eSight component gains insights into the devices, interfaces and links, and implement
performance monitoring and alarm management for the network devices. For details, see the lists in the following table.
Item URL
https://support.huawei.com/enterprise/en/doc/EDOC1100331190?
Device list
idPath=24030814%7C250382819%7C250382820%7C250987403%7C250852420
Alarm list https://support.huawei.com/enterprise/en/doc/EDOC1100341132?idPath=8221819|8221821|8221823|9184477
Performance indicator list https://support.huawei.com/enterprise/en/doc/EDOC1100341132?idPath=8221819|8221821|8221823|9184477
Feature list https://support.huawei.com/enterprise/en/doc/EDOC1100341132?idPath=8221819|8221821|8221823|9184477
IP+POL: Typical Application Scenario

 Scenario description: A European government customer builds a new
government campus and plans to use IP networking in offices to ensure high
bandwidth and reliable access. For employee dormitories, the customer plans
to use POL networking, which is free of power supply or ELV room, and is
iMaster NCE- without 100 m limit. In this manner, the advantages of IP and optical
Campus Core switch
products can be taken.
 Controller deployment: iMaster NCE-Campus manages switches, APs,
Office zone Dormitory
OLTs, and ONTs in a unified manner. This enables central device
OLT management and monitoring, display of the network-wide topology, unified
query of IP and POL device lists, and export of user-defined performance
ODN statistics reports, facilitating O&M.
Stack Stack
 Key features: Unified management of tenants and sites, unified entry for
Access switch Access switch ONU device management, and unified network topology display
 Technical description: Switches and APs are managed based on
NETCONF/YANG and support offline configuration. PON devices are
configured online using SNMP, and traditional datacom network elements
are configured using CLIs.
IP+POL: Main Functions and Constraints

1. iMaster NCE-Campus is available only in IP+POL scenarios, while iMaster NCE-FAN is recommended in POL scenarios.
Sales Scenarios 2. It is recommended that iMaster NCE-Campus be deployed in minimum cluster mode, while distributed cluster deployment
is not supported.
OLTs and ONUs can be managed. For details, click the following URL to see the list of device models that can be managed
POL device according to the controller version:
management https://support.huawei.com/enterprise/en/doc/EDOC1100331189?
idPath=24030814%7C250382819%7C250382820%7C250987403%7C250852420
Cross-public network iMaster NCE-Campus uses SNMP to manage POL devices. Therefore, the controller needs to communicate with POL private
constraints networks. Cross-public network management is not supported.
1. Currently, the POL network solution supports only Layer 2 pipes and automatic configuration of interfaces, VLANs, and
POL network WLANs.
solution 2. Currently, Layer 3 pipes and policy association are not supported.
3. The POL network solution is limited by iMaster NCE-FAN planning.
1. Supports 360-degree view of OLTs and ONUs, centralized display of device models, versions, and status, statistics of KPIs
such as CPU and memory, statistics of received and sent packets on interfaces, network topology display, and device alarm
POL device O&M
management
2. Supports device system software upgrade using patches.
Contents
 Service Scenario
 Controller Deployment

iMaster NCE-Campus Deployment in On-
Premises Scenarios
Basic Basic Value-added Feature Advanced Value-added Feature
Network Scale Reliability
Features (Optional) (Optional, New Resources Required)
Maximum Number of WAN Devices

Maximum Number of LAN Devices
Maximum Number of Online Users
AI-based Terminal Identification

Maximum Number of Devices
+ DR & Authentication Node

Security Policy Management
Advanced Security Feature

Configuration Verification
Terminal Identification
+ Authentication Node
LAN Management
PON Management
Physical
SRv6 TE Policy
Scenario Deployment Server
No. Application Scenario
SD-WAN
VXLAN
Category Mode Quantity
+ DR
1 x server
Single-node Network management and authentication
1
lite
(prepared by the 500 500 3000  N N N
for small and mini campuses
customer)
Network management and authentication
New: 1 x 128 GB for small campuses. For customers who
Single-node physical machine Y have high requirements on user
2
system (LAN)
1 x 128 GB 5,000 5,000 20,000      (PM)/virtual (recommended)
Y Y
authentication reliability, an extra
machine (VM)
authentication component should be
deployed as a backup.
Unified management of multi-branch
networks for small enterprises.
Single-node
New: 1 x 128 GB In multi-branch scenarios, the single-node
3 system (LAN- 1 x 256 GB 5,000 5,000 1,000 20,000       PM/VM
« Y Y Y
system is not recommended. Cluster
WAN)
deployment is required to ensure
On- reliability.
premises New: 3 x 64
Minimum New: 1 x 128 GB Network management and authentication
scenario 4
cluster (LAN)
3 x 128 GB 30,000 30,000 100,000       PM/VM
GB Y Y Y
for midsized and large campuses
PMs/VMs
Minimum New: 3 x 64 Unified management and authentication of

New: 1 x 128 GB
5 cluster (LAN- 3 x 128 GB 15,000 15,000 3,000 50,000        PM/VM
GB Y Y Y multi-branch networks for large and
WAN) PMs/VMs midsized enterprises
6-node New: 2 x 48
New: 2 x 48 GB New: 3 x 64 Unified management and authentication of
6 distributed 3 x 256 GB 30,000 30,000 6,000 100,000       VMs
GB VMs + 2 x
GB VMs Y Y Y
large campus networks
cluster 32 GB VMs
Page 38 Copyright © 2024

9-node Huawei Technologies Co., Ltd. All rights reserved. New: 2 x 48 Unified management and authentication of
New: 2 x 64 GB New: 3 x 64
7 distributed 5 x 256 GB 60,000 60,000 12,000 300,000       GB VMs + 2 x Y Y Y multi-branch networks and large campus
Distributed Cluster Architecture of the Controller
The controller uses a cluster architecture and consists of the service cluster, support cluster, big data analytics cluster, advanced feature cluster, and proxy and load balancing. This
provides high reliability and load balancing capabilities. In actual deployment, the service nodes and support nodes of iMaster NCE-Campus can be deployed independently or
together. The controller supports single-node deployment, minimum cluster deployment, and distributed cluster deployment, meeting the requirements of different customer
networks
Category Description
Support cluster
Management service that mainly provides functions such as tenant

management, configuration management, system management, and
GaussDB, etc O&M monitoring.
Advanced feature Service node Data collection service that mainly provides southbound channels for
Service cluster Big data analytics cluster cluster (optional) performance data, data preprocessing, data importing, and data analysis.
Authentication service that mainly provides functions such as user
authentication and authorization.
...
ACM/ACC/ACA Big data analytics AI-based terminal
identification Support node Database, distributed lock, distributed cache, distributed message
queue, etc
Authentication and authorization, Portal, device and tenant
data collection, software upgrade management
Advanced feature AI terminal identification, remote attestation, security situational
cluster (optional) awareness, etc
Proxy and load balancing
Big data analytics Big data analytics node that provides data storage and data aggregation
cluster functions.
LVS & Nginx High-performance HTTP proxy server that forwards concurrent
Proxy and load connection requests.
Cluster system balancing Load balancing component that improves north-south traffic reliability
of egresses.
IAE Authentication Component for Enhancing
Authentication Reliability
The IAE authentication component is an independent node of iMaster NCE-Campus that is dedicated to implementing access authentication. It provides RADIUS
authentication, Portal authentication, and HWTACACS authentication. IAE authentication components can be deployed for each campus to implement nearby authentication and
reduce authentication delay. The IAE component is deployed in single-node mode. Each IAE node supports a maximum of 30,000 online users.
• When the central controller is deployed in single-node mode, a maximum of five IAE nodes can be deployed. When the central controller is deployed in cluster mode, a
maximum of 20 IAE nodes can be deployed.
• When IAE nodes and the central controller work in active/standby mode to provide authentication, the number of authentication users on all IAE nodes cannot exceed the
maximum number of authentication users in the central cluster.
• Authentication components are independent of each other and can function as active/standby authentication servers. However, online user information cannot be synchronized
between active/standby authentication components.
Single-campus scenario Multi-campus scenario
Central cluster IAE component Central cluster

Primary cluster as a
standby authentication
Primary cluster as an standby IAE nodes as a active
server
authentication server authentication server
Campus 1 Campus 2
IAE component
IAE nodes as an active
authentication
server
Controller Deployment Networking - Single
Cluster
For a simple campus network, the controller can connect access switches to core switches (border For networking on a large campus with a DC, the customer deploys the controller in the DC and
node) in off-path mode to implement nearby management. manages campus devices through the campus network.
• iMaster NCE-Campus is deployed on PMs and connects a group of access switches to a core • iMaster NCE-Campus is deployed in the DC on a PM or VM. You are advised to use the two-
switch in off-path mode. You are advised to use the two-plane deployment solution. That is, one plane deployment solution. That is, one plane is used for southbound and northbound external
plane is used for southbound and northbound external communication, and the other plane is used communication, and the other plane is used for communication between cluster nodes.
for communication between cluster nodes. • Determine whether to deploy IAE authentication nodes based on reliability requirements. The
• Determine whether to deploy IAE authentication nodes based on reliability requirements. The primary cluster and IAE authentication nodes work in active/standby mode. When the primary
primary cluster and IAE authentication nodes work in active/standby mode. When the primary cluster is faulty or being upgraded, the IAE nodes provide authentication backup.
cluster is faulty or being upgraded, the IAE nodes provide authentication backup. The Notes:
authentication component is deployed on one plane and can communicate with the southbound • If a firewall is deployed between the DC and campus, the IP address and interface of the
plane of the primary cluster through Layer 2 or Layer 3 routes. controller must be allowed on the firewall. For details, see iMaster NCE-Campus
Notes: V300R023C00 Communication Matrix (Ports Enabled on Firewalls).
• Access switches directly connected to the controller cannot be managed by the controller using
NETCONF. This misoperation must be prevented.
• The controller cannot be directly connected to the core switch, preventing the core switch from
being affected by heavy internal communication traffic of the controller.
Office zone Access switch in the Office DC zone

stack management zone zone
iMaster NCE- IAE node on iMaster

CSS CSS
Campus NCE-Campus
Management zone
CSS CSS iStack iStack
iStack iStack iMaster NCE- IAE node on iMaster

Campus NCE-Campus
Internal communication of the controller (Layer 2)

Communication between the controller cluster and devices (Layer 3)
Page 41 Copyright © 2024 Huawei Technologies Co., Ltd. All rights reserved. Communication between the primary cluster and IAE nodes (Layer 3)
DR Solution for the Controller
In a scenario where multiple campuses are centrally managed, you are advised to deploy DR clusters for the controller to ensure
reliability. If automatic switchover between DR clusters is required, an arbitration node must be deployed for arbitration. If a user wants
nearby authentication, IAE authentication nodes can be deployed on the campuses. The IAE authentication nodes function as active
authentication nodes, and the controller clusters function as backup authentication nodes.
iMaster NCE-Campus iMaster NCE-Campus (standby)

PM/VM PM/VM
Arbitration
DC (active) DC (standby)
Enterprise intranet
Internal communication of the controller (Layer 2)
Campus 1 Campus 2 Communication between DR clusters (Layer 2)
IAE node on Communication between the DR cluster and arbitration node
IAE node on iMaster NCE- (Layer 2)
iMaster NCE- Campus
Campus Communication between the controller cluster and devices
CSS CSS CSS CSS (Layer 3)
Communication between the primary cluster and IAE nodes
iStack iStack iStack iStack (Layer 3)
DR Solution for the Controller: Layer 2 + Floating
IP Address
• DR clusters communicate with each other at layer 2 and provide floating IP addresses for external systems. Only the primary cluster
sends ARP packets carrying the floating IP address for locating the floating IP address.
IP address planning: The primary and secondary clusters are on the same network
segment. Internal communication is at Layer 2, and floating IP addresses are used
for southbound and northbound communication.
iMaster NCE- iMaster NCE-

Campus Internal channel data Campus
synchronization
Virtual IP address Virtual IP address for

for internal internal
communication: communication:
172.16.1.11 172.16.1.12 Southbound virtual IP address:
172.16.2.12
Southbound virtual IP
Unified southbound virtual IP
address: 172.16.2.11
address: 172.16.2.100
Enterprise intranet
Device Controller-IP: 172.16.2.100
DR Solution for the Controller: Layer 3 + Floating
IP Address
DR clusters communicate with each other at Layer 3 and provide floating IP addresses for external systems. Configure static IP
floating routes for the gateways connected to the controller, and NQA is associated with the static routes for detection. Only the IP
floating route of the primary cluster is advertised to the network.
IP address planning: The primary and secondary clusters are in different network segments. Internal communication is at Layer 3,
and floating IP addresses are used for southbound and northbound communication.
Internal channel data Campus
Campus
synchronization
Virtual IP address for Virtual IP address

internal for internal
Southbound virtual IP 172.16.1.11 173.16.1.12 Southbound virtual IP
address: 172.16.2.11 address: 173.16.2.12
Firewall/Router Firewall/Router
Static route: Unified southbound virtual IP Static route:
Prefix 174.16.2.100 address: 174.16.2.100 Prefix 174.16.2.100
nexthop 172.16.2.11 nexthop 173.16.2.12
track nqa test_172.16.2.11 track nqa test_173.16.2.12
Enterprise intranet
DR Solution for the Controller: Layer 3 + Dual
Southbound IP Addresses
• In a scenario where multiple campuses are centrally managed, you are advised to deploy DR clusters for the controller to ensure reliability. If automatic
switchover between DR clusters is required, an arbitration node must be deployed for arbitration.
• DR clusters communicate with each other at Layer 3. The primary and secondary clusters provide different controller IP addresses for external systems.
Configure IP addresses for the active and standby controllers on network devices. When the primary cluster is faulty, devices are automatically switched
to the secondary cluster.
IP address planning: The primary and secondary clusters are on different network segments. Internal communication is at Layer 3, and
active/standby IP addresses are used for southbound and northbound communication.

Internal channel data
Campus Campus
synchronization
This solution is not supported when the following
Virtual IP address Virtual IP address for functions are used.
for internal internal
• Free mobility
Southbound virtual IP 172.16.1.11 173.16.1.12 Southbound virtual IP • HWTACACS authentication
address: 172.16.2.11 address: 173.16.2.12
• Authentication components
Firewall/Router Firewall/Router • Traditional device management (SNMP)
• V600 switch
• V600 WAC
• V5 or V600 AR in non-SD-WAN scenarios
Enterprise intranet
• V5 or V600 firewall
Controller-IP: 172.16.2.11 (active)

Device Controller-IP: 173.16.2.12 (standby)
DR Solution for the Controller in Cloud
Management Scenarios
In multi-branch cloud management scenarios, management traffic between the controller and network devices may need to traverse the Internet. In this case,
NAT needs to be deployed for the network egress firewall where the controller resides to translate the internal IP address of the controller into a public IP
address. If a user wants nearby authentication, IAE authentication nodes can be deployed in branches. The IAE authentication nodes function as an active
authentication node, and the controller cluster functions as a backup authentication node.
iMaster NCE-Campus iMaster NCE-Campus (standby)

PM/VM PM/VM
DC DCI
DC
(active) (standby)
Internet
Branch 1 Branch 2
IAE node on
IAE node on iMaster NCE-
iMaster NCE- Campus
Campus
CSS CSS CSS CSS
iStack iStack iStack iStack
Controller Deployment Networking - DR (Layer 2
+ NAT + Floating IP Address)
• If Layer 2 communication is implemented for the active and standby DCs, Layer 2 floating IP addresses are configured for the primary and secondary
controller clusters and then translated into public floating IP addresses through NAT. In addition, the priority for advertising southbound public virtual IP
addresses needs to be set in the active and standby DCs.
• The NAT policy on the firewalls cannot be used to monitor the active/standby status of the controller clusters and control route advertisement. Therefore,
manual switchover is performed for the controller. If automatic switchover is required, the DC where the controller is located must support cross-DC
Layer 2 floating IP address convergence. As shown in the following figure, if the primary cluster is faulty, the egress is still on the left, but the traffic can
be diverted to the standby DC from the active DC.
iMaster NCE-Campus Internal channel data iMaster NCE-Campus
synchronization
Virtual IP address Virtual IP address
for internal for internal
172.16.1.11 172.16.1.12
Southbound private virtual IP
VBDIF: 172.16.1.1 24 address: 172.16.2.11 VBDIF: 172.16.1.1 24
It depends on host route convergence. DC gateway DC gateway It depends on host route convergence.
1:1 NAT policy:

1:1 NAT policy: Firewall Firewall 172.16.2.11 is mapped to 110.16.2.100.
172.16.2.11 is mapped to 110.16.2.100. Southbound public virtual IP
address: 110.16.2.100
Internet
Controller Deployment Networking - DR (Layer 3
+ NAT + Floating IP Address)
• If only Layer 3 communication is allowed for the active and standby DCs, Layer 3 floating IP addresses are configured for the primary and secondary controller clusters and then
translated into public floating IP addresses through NAT. In addition, the priority for advertising southbound public virtual IP addresses needs to be set in the active and standby
DCs.
• The NAT policy on the firewalls cannot be used to monitor the active/standby status of the controller clusters and control route advertisement. Therefore, manual switchover is
performed for controller. If automatic switchover is required, the DC where the controller is located must support detection through association between static routes and NQA. As
shown in the following figure, if the primary cluster is faulty, the egress is still on the left, but the traffic can be diverted to the standby DC from the active DC.

synchronization
Virtual IP address Virtual IP address
for internal for internal
172.16.1.11 173.16.1.12
Southbound virtual IP Southbound virtual IP
Static route: Inter-DC interconnection address: 173.16.2.12
address: 172.16.2.11 Static route:
• Prefix 174.16.2.100 nexthop 172.16.2.11 track nqa address: 177.1.1.0
• Prefix 174.16.2.100 nexthop 173.16.2.12 track
test_172.16.2.11 DC gateway DC gateway
nqa test_173.16.2.12
• Prefix 174.16.2.100 nexthop 177.1.1.2 track nqa Southbound private virtual IP • Prefix 174.16.2.100 nexthop 177.1.1.1 track nqa
test_173.16.2.12 address: 174.16.2.100
test_172.16.2.11
It depends on static route convergence. Firewall Firewall It depends on static route convergence.
Southbound public virtual IP
address: 110.16.2.100 1:1 NAT policy:
1:1 NAT policy:
174.16.2.100 is mapped to 110.16.2.100.
174.16.2.100 is mapped to 110.16.2.100.
Internet
Controller Deployment Networking - Unified
LAN-WAN Management
For unified LAN-WAN management, the controller uses southbound public virtual IP addresses to manage ARs; and uses southbound private virtual IP
addresses to manage LSWs and APs in branches. Management traffic is forwarded through SD-WAN tunnels on the overlay network.

synchronization
Virtual IP address for Virtual IP address for
internal internal
Static route: Southbound virtual IP 172.16.1.11 Southbound virtual IP
173.16.1.12
Prefix 174.16.2.100 address: 172.16.2.11 address: 173.16.2.12 Static route:
nexthop 172.16.2.11 Prefix 174.16.2.100
track nqa test_172.16.2.11 Firewall Southbound private virtual IP Firewall nexthop 173.16.2.12
1:1 NAT policy: address: 174.16.2.100 track nqa test_173.16.2.12
174.16.2.100 is mapped to 110.16.2.100. 1:1 NAT policy:
Southbound public virtual IP 174.16.2.100 is mapped to
AR address: 110.16.2.100 AR 110.16.2.100.
SD
-W
ne l
AN Internet un
tu A Nt
n ne -W
l SD
AR Controller-IP: 110.16.2.100
Constraint: A single cluster with dual southbound addresses
(private/public virtual IP addresses) and a DR system with
LSW Controller-IP: 174.16.2.100 dual southbound addresses cannot be used together.
Controller Deployment: All Functions and Constraints
1. Select the deployment mode based on the number of devices and terminals to be installed. For details, click the following URL.
2. Single-node deployment in active/standby mode is required to ensure reliability. In a single campus scenario, if the customer is cost-sensitive, a single-node system
Controller deployment mode
with authentication components is required at least.
https://support.huawei.com/hedex/hdx.do?docid=EDOC1100331205&id=EN-US_TOPIC_0000001606700656
In on-premises scenarios, the reliability solution is selected based on the importance of network services.
1. In a VLAN/VXLAN campus without authentication, a single-node system in active/standby mode or a cluster needs to be deployed.
2. In a VLAN/VXLAN campus with authentication, remote authentication nodes are recommended to improve the reliability of access authentication services.
Reliability
3. In an SD-WAN scenario, DR is recommended.
4. In multi-campus scenarios or cloud management/multi-branch scenarios for small and midsized campuses, DR combined with remote authentication nodes is
recommended.
Software and hardware for PM deployment:
Software and hardware 1. 2288X (EulerOS) and TaiShan (EulerOS) delivered by Huawei. For non-standard Huawei servers, their models need to be specified for separate evaluation.
2. Third-party servers (x86) cannot be deployed on PMs. Virtualization installation based on VMware is required.
Two-plane deployment (recommended): plane 1 (internal communication plane), and plane 2 (the service plane, southbound plane, and northbound plane are integrated).
Plane deployment
The default gateway is on plane 2.
1. Member nodes in a cluster or distributed cluster must use the same platform (ARM or x86), the same virtualization software, and the same OS.
2. In a DR scenario where the controller is newly deployed, the primary cluster/secondary cluster/arbitration node should use the same server specifications, the same
Deployment requirements
platform, the same virtualization software, and the same OS. However, there is no strict consistency requirement when a single cluster is expanded to a DR system.
3. For authentication components and the HQ controller, server specifications, platforms, virtualization software, and OSs are not required to be the same.
1. The bandwidth for internal communication between nodes must reach 1 Gbit/s, and the latency must be less than or equal to 1 ms.
2. The southbound and northbound bandwidths for external access depend on the number of managed devices. Every 10,000 devices can consume 35 Mbit/s bandwidth.
Batch device upgrade requires at least 400 Mbit/s bandwidth. The latency for accessing the southbound network must be less than or equal to 200 ms, and the latency
Latency and bandwidth for accessing the northbound network must be less than or equal to 100 ms.
3. In access control scenarios, the communication latency between iMaster NCE-Campus and external data sources (such as AD/LDAP and RADIUS servers) must be
less than or equal to 5 ms. Otherwise, the concurrent authentication performance may deteriorate.
4. In remote authentication scenarios, the latency between the primary cluster and remote authentication nodes is less than 200 ms.
• The controller server cannot be connected to the core switch (managed by the controller) in off-path mode. A management switch (a low-end switch that runs stably)
needs to be added. The controller is connected to the management switch and then connected to the core switch at Layer 3.
Networking requirements
• Devices and the controller must communicate with each other at Layer 3, while they cannot communicate with each other at Layer 2 on the same network. (In some
Layer 2 communication scenarios, LVS load balancing does not take effect.)
A single cluster does not support
A single controller cluster requires single-center deployment, and does not support remote deployment of cluster nodes.
remote node deployment
Controller Deployment: Main Functions and
Constraints (1/2)
1. Single-node systems for DR, minimum clusters for DR, and distributed clusters for DR are supported. Single-node lite does not support DR deployment.
DR deployment 2. DR supports automatic switchover and manual switchover, and automatic switchover requires deployment of arbitration nodes.
3. Arbitration nodes are recommended for customers who require fast switchover.
Latency and 1. The latency between the primary and secondary clusters is less than 20 ms, and the bandwidth is greater than or equal to 100 Mbit/s.
bandwidth in 2. In a DR scenario with an arbitration node, the communication latency between the arbitration node and the primary or secondary site must be less than or equal to 50 ms,
DR scenarios the NTP configuration must be synchronized between them, and the bandwidth between them must be greater than or equal to 10 Mbit/s.
Constraints in 1. DR nodes communicate with each other through private networks. NAT is not supported.
DR scenarios 2. DR systems cannot be deployed in IPv6 scenarios. Primary/Secondary cluster DR is supported only in IPv4 single-stack scenarios.
Based on the customer's network environment, DR networking supports the following solutions to manage network devices through the intranet:
• Layer 2 network interconnection between the active and standby controllers: The active and standby controllers use floating IP addresses in the southbound and northbound
directions. During normal operation, only the active controller enable the floating IP addresses. Arbitration nodes can be deployed to implement automatic switchover.
• Layer 3 network interconnection between the active and standby controllers: The southbound and northbound IP addresses of the active and standby controllers are in different
network segments, and routes need to be configured on the egress routers of the active and standby controllers. For the network supporting NQA, you can enable NQA to detect
the LVS floating IP addresses of the primary and secondary clusters and associate routes with NQA. In this way, the secondary cluster does not advertise the southbound and
DR networking northbound floating IP addresses, and implements automatic switchover through NQA association.
requirements • Different southbound and northbound IP addresses are enabled for the active and standby controllers, and the IP addresses of the active and standby controllers can be
configured on devices. For details about the constraints, click https://support.huawei.com/hedex/hdx.do?docid=EDOC1100331202&id=EN-US_TOPIC_0000001309222898.
Managing network devices through public networks: The active and standby controllers communicate with each other at Layer 2 or Layer 3, and manual active/standby switchover
is supported. The priority for configuring public floating IP address routes is manually set on an egress firewall, and then NAT is configured on the firewall to map private service
IP addresses to public floating IP addresses. In addition, the controller cannot use the post-NAT public IP addresses to manage network devices on the network where the controller
is located. Otherwise, after the device management traffic of the standby DC reaches the firewall and translated through NAT, the post-NAT traffic uses local direct routes by
default and therefore cannot reach the primary cluster.
1. Single cluster with multiple southbound IP addresses
Other • SD-WAN ARs can select public or private networks by device.
constraints on • Other intra-site devices can only select public or private networks by site.
multiple • A device cannot have multiple communication addresses. For example, it is not allowed that management traffic of the device passes through a public network, while its
controller authentication traffic passes through a private network.
southbound 2. DR system with multiple southbound IP addresses
addresses • A single cluster with multiple southbound addresses and a DR system with multiple southbound addresses cannot be both configured. That is, the controller cannot provide
four southbound IP addresses for external systems.
Controller Deployment: Main Functions and
Constraints (2/2)
1. In a single-campus scenario, independent authentication components are deployed to improve access authentication
reliability.
2. In a multi-campus scenario, independent authentication components are deployed to implement nearby authentication and
improve authentication reliability.
3. Authentication components are supported only in the global perpetual license mode.
4. iMaster NCE-Campus can interconnect with a maximum of five authentication components in a single-node deployment
Authentication scenario, 20 in a minimum cluster deployment (without the SD-WAN function) scenario,10 in a minimum cluster
components deployment (with the SD-WAN function) scenario, and 20 in a distributed cluster deployment scenario.
5. A single authentication component supports a maximum of 30,000 online users. If authentication components and the HQ
back up each other, the total number of online users of all authentication components cannot exceed the maximum number
supported by the HQ controller.
6. Currently, interconnection with an email server, guest account approval, or PPSK authentication is not supported when an
authentication component is deployed.
7. An authentication component does not support built-in CA authentication when the HQ controller is faulty.
Contents
MSP-owned Cloud Scenario
Manager + Controller + Analyzer
Wi-Fi optimization Application analysis SD-WAN
Cloud-based Cloud-based Cloud-based Cloud-based
WLAN planning deployment admission monitoring
Multi-tenant cloud SD-WAN networking service and WAN
management network POP acceleration service
Internet Internet Internet MSP RR

MSP RR
AR8140 Active IWG
AR AR8700 Firewall AR Active IWG
USG6650E
USG6655F LAN
Firewall
AirEngine Switch MPLS Customer A's site
S77 9700-M1 LAN
AP AP AR
S8700 LAN
S12700E Customer A's HQ Standby IWG Customer B's HQ
S5735-L 6735-S Standby IWG
S5735-L-V2 S6730-H-V2
S5731-S
Active IWG Standby IWG
S5736-S Active IWG
Switch
AP
LAN LAN
Tenant 1 Tenant 2 Tenant n Customer A's site Customer B's site
If you want to select a cloud management networking baseline for tenants, please refer to page 17.
An MSP provides SD-WAN networking services for tenants and support, and hub-spoke, full-mesh, and customized networking are supported. For details about the networking solutions,
see page 21 and 22.
PageFor
54 tenants who have
Copyright © 2024requirements
cross-border Huawei Technologies Co., Ltd.
and bandwidth All rights the
requirements, reserved.
MSP can also operate POP networks to provide bandwidth acceleration services.
MSP-owned Cloud Scenario: iMaster NCE-
Campus Deployment Specifications
Basic Value-added Feature Advanced Value-added Feature
Network Scale Basic features Reliability
(Optional) (Optional, New Resources Required)
AI-based Terminal Identification
+ DR & Authentication Node

Security policy management
Advanced Security Feature

Configuration Verification
Terminal Identification
+ Authentication Node
LAN Management
PON Management
Physical
SRv6 TE Policy
Maximu Maximu Maximu
Scenario Deployment Server Maximum m m m
SD-WAN
No. Application Scenario
VXLAN
Category Mode Quantity Number of Number
+ DR
Number Number
Devices of LAN of WAN of Online
Devices Devices Users
MSPs in trial scenarios. Smooth

Single-node upgrade to distributed cluster
1 system 1 x 256 GB 5,000 5,000 500 20,000 « « « « Y deployment is not supported.
(LAN-WAN) Instead, the controller needs to be
reconfigured.
upgrade to distributed cluster
Minimum deployment is not supported.
2
cluster (LAN)
3 x 128 GB 30,000 30,000 100,000 « « « « Y
Instead, the controller needs to be
reconfigured. In addition, servers
cannot be reused.
MSP- Minimum upgrade to distributed cluster
owned 3 cluster (LAN- 3 x 128 GB 15,000 15,000 3,000 50,000 « « « « « Y deployment is not supported.
Cloud WAN) Instead, the controller needs to be
Scenario reconfigured.
6-node
MSPs in the expansion phase, or
4 distributed 3 x 256 GB 30,000 30,000 6,000 100,000 « « « « Y
small and midsized MSPs
cluster
9-node
Mature MSPs, or midsized and
5 distributed 5 x 256 GB 60,000 60,000 12,000 300,000 « « « « Y
large MSPs
cluster
17-node
Typical 6 distributed deployment:
multi-cluster 9 x 256 GB 200,000 200,000(3-node)
global cluster 20,000 + multiple «
700,000 regional « «
clusters (9-node) « Y Large MSPs
cluster
Page 55 Copyright © 2024Elastic
Huawei Technologies
Elastic ElasticCo.,Elastic
Ltd. All rights reserved.
7 Multi-cluster
scaling scaling scaling scaling « « « « Y Ultra-large MSPs
MSP-owned Cloud: Typical Application Scenarios
System administrator:
System • MSP management
• Tenant migration
view System administrator • System bulletin
… • Signature database update
• Software package management
System auditor System operator • NCE server alarm & log management
• NCE interface management
MSP administrator:
MSP • Tenant management
view MSP administrator • Device management
… • MSP dashboard
• Alarm/Log management
MSP auditor MSP operator • Third-party service (email/SMS)
Tenant administrator: End customer

Customer UI
• Network design • Overlay VPN management
• Site design • Traffic policy
Tenant view Tenant Tenant • ZTP • Security policy
... • Overlay VPN management
administrator administrator • Tenant monitoring
of tenant A of tenant B • Traffic policy • Alarm/Log management
Tenant auditor of Tenant B • Security policy • Diagnosis
tenant B account • Tenant monitoring
Tenant B • Alarm/Log management
account • Diagnosis
• Certificate management
MSP-owned Cloud: Main Functions and Constraints
An MSP plans the controller deployment modes according to the expected total number of tenants/devices in the next year. It is recommended that a 6-node distributed cluster be
Controller deployment deployed in the first phase. As the number of tenants increases, the 6-node distributed cluster can be expanded to a 9-node distributed cluster, and then to a multi-cluster system.
For MSPs, DR is recommended to ensure reliability as remote authentication components cannot be deployed.
Generally, iMaster NCE-Campus communicates with multi-tenant network devices through the Internet. During installation and deployment, the post-NAT public IP address of the
NAT scenario platform need to be provided. LAN and WAN devices on campuses are connected to the controller through a southbound public floating IP address. Some dedicated MSPs
communicate with tenants through private networks, eliminating the need for NAT.
The latency and bandwidth for deploying iMaster NCE-Campus are the same as those described in the preceding slides. In MSP multi-tenant scenarios, as the scale of the managed
Controller networking
network expands, bandwidth expansion is required.
For details about the devices modes that can be managed by iMaster NCE-Campus, click
Device management https://support.huawei.com/enterprise/en/doc/EDOC1100331189?idPath=24030814|250382819|250382820|250987403|250852420.
SNMP-managed Huawei devices and third-party devices are not supported.
The global subscription license mode is used. If a user enables license redistribution, the user will be rewarded with a one-year iMaster NCE-Campus license and license resources
License management
of 30,000 device x days.
• Supports interconnection with Huawei devices for access authentication, including 802.1X authentication, MAC address authentication, and Portal (HACA) authentication. If
interconnection with third-party access devices is involved, ensure that the device IP addresses are not translated using NAT.
• Local management of the controller is recommended for user management.
• If interconnection with the users' AD/LDAP servers is involved (such as using 802.1X MSCHAPv2), the controller needs to be added to AS domains (maximum: 64 AS
Access authentication
domains). For MSPs, this function is used with restrictions.
• If interconnection with the OA system provided by an end user is involved, iMaster NCE-Campus provides the RADIUS relay (50 RADIUS servers can be connected to the
controller, and this function is used by MSPs with restrictions), API relay, SAML SSO (50 IdP servers can be connected to the controller, and this function is used by MSPs
with restrictions), and HTTPS functions for interconnection. Single-point evaluation is required to determine whether these functions can meet interconnection requirements.
The IP+POL networking solution is sold to MSPs with restrictions. POL management components can be deployed only when the controller is deployed in minimum cluster mode.
IP+POL networking
As POL devices are managed through SNMP, ensure that the IP addresses of the POL devices are not translated using NAT.
Restrictions on advanced
VXLAN, single-network SRv6 networking, free mobility, and IoT integration are not supported.
features
System-level scale The maximum number of tenants is 10,000, and the maximum number of sites is 60,000. When the number of tenants and sites reaches the upper limit, new clusters need to be
constraints added.
In multi-tenant scenarios, tenants need to preempt performance, such as performance for concurrent reporting of device monitoring information and concurrent access
Performance constraints
authentication.
Contents
Huawei Public Cloud Scenario
(China) (Outside China)
Manager + Controller + Analyzer Manager + Controller + Analyzer

Wi-Fi optimization Application analysis SD-WAN Wi-Fi optimization Application analysis SD-WAN
Cloud-based Cloud-based Cloud-based Cloud-based Cloud-based Cloud-based Cloud-based Cloud-based
WLAN planning deployment admission monitoring WLAN planning deployment admission monitoring
Multi-tenant cloud SD-WAN networking service and WAN

management network POP acceleration service
Internet Internet Internet
AR Firewall AR
Firewall Switch
AP AP AR
Switch
AP
Tenant 1 Tenant 2 Tenant n
The tenant networking baseline is selected by referring to page 17.

For details about capabilities, see the version capabilities of iMaster NCE-Campus 22.1 (in China) and iMaster NCE-Campus 22.0 (outside China).
Huawei Public Cloud Scenario: Global Deployment of
the Cloud Management Platform
Deployment Deployment
Current Version Northbound Access Address
France Zone Location
Europe France V300R022C00SPC826 weu.naas.huawei.com
Hong Kong V300R022C00SPC826 naas-intl.huaweicloud.com

Asia Pacific
Chinese mainland Singapore V300R022C00SPC151 sg.naas.huaweicloud.com
Mexico V300R022C00SPC823 mx.naas.huaweicloud.com

Latin America
Brazil V300R022C00SPC826 br.naas.huaweicloud.com
Hong Kong
Mexico naas.huaweicloud.com
Singapore naas1.huaweicloud.com
Huawei naas3.huaweicloud.com
V300R022C00SPC821
Brazil Cloud
cn1.naas.huaweicloud.com
Chinese
mainland cn5.naas.huaweicloud.com
e-Cloud V300R022C00SPC1B0 cn1.naas.ctyun.cn
Huawei
V300R022C10 qiankun-saas.huawei.com
Qiankun
Huawei Public Cloud Scenario: Main Functions
and Constraints
Currently, click https://qiankun-saas.huawei.com/dm-web/#/eu to access the official website of Huawei public cloud. You can leave your contact information
Public cloud access on the web page and wait for Operation personnel to contact you.
Click https://qiankun-saas.huawei.com/dm-web/#/ to access the official website of Huawei Qiankun.
• The device models that can be managed by the cloud management platform lag behind the latest version of iMaster NCE-Campus. If the new models
Device management supported in iMaster NCE-Campus 23.0 (compared with 22.0) are not supported on the Huawei public cloud, please contact operations personnel.
• By default, Huawei public cloud uses NETCONF to manage devices. SNMP-based management and third-party device management are not supported.
License management The tenant subscription license mode is used.
• Supports interconnection with Huawei devices for access authentication, including 802.1X authentication, MAC address authentication, and Portal
(HACA) authentication. Portal (HACA) authentication is recommended.
• Local management of the cloud management platform is recommended for user management.
• If interconnection with the users' AD/LDAP servers is involved (such as using 802.1X MSCHAPv2), the controller needs to be added to AS domains
(maximum: 64 AS domains). In Huawei public cloud scenarios, this function is used with restrictions.
• If interconnection with the OA system provided by an end user is involved, the cloud management platform provides the RADIUS relay (50 RADIUS
Access authentication servers can be connected to the controller, and this function is used with restrictions), API relay, and SAML SSO (50 IdP servers can be connected to the
controller, and this function is used with restrictions) functions for interconnection. Single-point evaluation is required to determine whether these
functions can meet interconnection requirements.
• If the AD/LDAP server or customer's OA system is deployed on the customer's intranet, it is recommended that the customer prepare a local authentication
server to avoid security problems.
• Huawei public cloud does not support TACACS authentication, and interconnection with third-party access devices, MDM systems, online behavior
management devices, and RADIUS accounting devices.
Restrictions on VXLAN, single-network SRv6 networking, free mobility through IP-security group entry subscription, IoT integration, intelligent verification, proactive
advanced features scanning for terminal identification, and POL management are not supported.
Summary
 This document describes all scenarios of iMaster NCE-Campus.
 This document describes the networking solutions and deployment restrictions of iMaster NCE-Campus in on-
premises, MSP-owned cloud, and Huawei public cloud scenarios.
 Through these introductions, you should have a deep understanding of the main application scenarios and constraints
of iMaster NCE-Campus.
Thank You
www.huawei.com

05 NCE-Campus Scenario Baseline Introduction

Uploaded by

Copyright:

Available Formats

You might also like

05 NCE-Campus Scenario Baseline Introduction

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

05 NCE-Campus Scenario Baseline Introduction

Uploaded by

Copyright:

Available Formats

iMaster NCE-Campus V300R023C00 Scenarios

 MSP-owned Cloud Scenario

VLAN Campus: Recommended Wired authentication admission point

S6730-H SRUHX + S8700 GW GW GW

VLAN Campus: Typical Application Scenario

VLAN Campus: Main Functions and Constraints

VLAN Campus: Main Functions and Constraints (2/2)

VXLAN Campus: Networking Wired authentication

Centralized Gateway + VXLAN Centralized Gateway + VXLAN Deployed

Core AC6805 AC6805

1. Two-layer or three-layer switch

VXLAN Campus: Networking Wired authentication admission point

SDN-based automatic orchestration is SDN-based automatic orchestration is

VXLAN Campus: Typical Application

VXLAN Campus: Typical Application Scenario

VXLAN Campus: Main Functions and

A VXLAN fabric network supports two networking modes:

VXLAN Campus: Main Functions and

VXLAN Campus: Main Functions and

Free mobility can be configured based on fabrics.

Cloud Management Branch: Networking Solutions

Single-cloud AP Two-layer switch networking: Provides Two-layer switch networking: Provides

Cloud Management Branch: Typical Application

Cloud Management Branch: Main Functions and

Cloud Management Branch: Main Functions and

Automatic configuration capabilities of the controller （ Only Chinese Temporary ） :

SD-WAN: Networking Solutions (1/2)

(active) service (standby)

Service B (active) Branch & HQ

Mutual access between Communication

SD-WAN: Networking Solutions (2/2)

SD-WAN: Typical Application Scenario

SD-WAN: Main Functions and Constraints

One SRv6 WAN for City Commercial Banks and

between the DC-PEs and BR-PEs of the

optimization is performed for the paths

1 .Core backbone network

WAN access: policy-based

traffic steering for an

One SRv6 WAN for District/County Governments

NetEngine 8000 M8 Solution

One SRv6 WAN: Comparison Between SD-WAN and SRv6

Item Sub-feature SD-WAN One WAN (SRv6)

Advantages: Supports underlay IPv6 programmable paths and interconnection with NE

Authentication Server: Functions

Authentication Server: Main Functions and

Authentication Server: Main Functions and

• Terminal identification is classified into proactive identification and passive identification.

Traditional NMS: Typical Application Scenarios

Traditional NMS: Comparison Between SNMP and

Configuration file Configuration file

Network traffic analysis WLAN locating

Network traffic analysis WLAN locating

• NETCONF can be used for device management instead.

Traditional NMS: SNMP-based Management of

Alarm list https://support.huawei.com/enterprise/en/doc/EDOC1100341132?idPath=8221819|8221821|8221823|9184477

Performance indicator list https://support.huawei.com/enterprise/en/doc/EDOC1100341132?idPath=8221819|8221821|8221823|9184477

Feature list https://support.huawei.com/enterprise/en/doc/EDOC1100341132?idPath=8221819|8221821|8221823|9184477