SupportDocumentationEnterprise Network SolutionHorizontal SolutionsCloudCampusConfiguration & CommissioningConfiguration Guide

CloudCampus Solution V100R021C00 Design and Deployment Guide for Multi-Campus Network Interconnection

Network Design

Network Design

Creating a Site

Application Scenario

Devices on the same tenant network can be deployed at the same site to facilitate device O&M and management and improve service deployment efficiency.

A tenant administrator can create different organizations and add a site to one organization. Currently, up to five-layer organizations can be created.

You can create sites on iMaster NCE-Campus for unified O&M and management. Either of the following modes is available for you to create a site:

  • Creating sites one by one: You can create sites one by one when a small number of sites need to be created.
  • Creating sites in batches: You can create sites in batches when a large number of sites need to be created. This mode is currently not applicable to cloud sites.

Feature Requirements

Up to 5000 devices can be deployed at a site.

Prerequisites

  1. Global parameters have been set. For details, see Setting Global Parameters.

Procedure

  1. Choose Design > Site Agile Deployment > Site Management from the main menu.
  2. Click Create and set parameters as prompted.
  3. Set parameters in the Basic Site Information area, such as Site Name, Location, and Device type.

    • After Device type is set, you can only add device types but cannot replace device types. For example, if only APs are deployed at a site, you can add firewalls to the site. However, you cannot change a site that contains only APs to a site that contains only firewalls. When LSWs are deployed as WACs, you need to select both LSW and WAC.
    • If OLTs and ONUs need to be managed by iMaster NCE-Campus, select PON network management when installing iMaster NCE-Campus, . Otherwise, iMaster NCE-Campus cannot manage OLTs and ONUs.
    • APs and WACs cannot be deployed together at a site.
    • If RR Source is set to MSP RR in global parameters, no RR site needs to be created for the tenant.

  4. Set parameters in the Site Configuration area.

    • Set Configuration mode.

      You can set this parameter to Default or Configuration File. If this parameter is set to Configuration File, you need to prepare device configuration files in advance, and choose Maintain > Device Maintenance > Configuration File Management to import and deliver the configuration files to the target devices.

      When you create a site in Configuration File mode, the following constraints apply:

      • Sites created in Configuration File mode do not support the following functions: site configuration, VXLAN fabric configuration, admission configuration, third-party server configuration, and device upgrade.
      • Devices at sites created in Configuration File mode can be switched to other sites created in this mode. You cannot switch devices at sites created in Configuration File mode to sites created in Default mode or move the devices out of the current site.
      • Devices at sites created in Configuration File mode cannot be added to stacks after being configured using configuration files.
      • Sites created in Configuration File mode can use only specific northbound interfaces.
    • Set Configuration source type.

      When Configuration mode is set to Default, you need to set Configuration source type. The options include the following:

      • Default settings: You can configure sites as needed.
      • Clone from an existing site: When creating a site, you can clone the configuration of an existing site for use with the new site, reducing repeated configurations. Currently, this function is available for the following features: domain, time zone, NTP, SNMP, local user, login restriction, HWTACACS, LLDP, HTTP service, public key-free upon first authentication of SSH clients, terminal location reporting, AP identity identification private key, IPv6, universal NETCONF, global CLI, global security compliance, global NAT (FW), ASPF, DNS, VLANIF (local Internet access), global interface management, SSID, global radio, Portal authentication, security policy, traffic policy, authentication and authorization policy, online user control policy, Portal page pushing rule, monitoring configuration, voice terminal OUI, VLAN information, WLAN security, attack defense, global IoT, Bluetooth, DHCP, storm suppression, MAC blacklist/whitelist, NAT logs, and SA upgrade policy.
      • Deep clone: Currently, only the sites containing firewalls only or containing APs and firewalls support the deep cloning function. On iMaster NCE-Campus, you can clone selected data of sites and devices from existing sites.

        In deep clone mode, sites can be cloned one by one or in batches. If a small number of sites need to be cloned, you can clone them one by one. When a large number of sites need to be cloned, you can clone them in batches.

        Table 4-115 Features that support deep cloning

        Device

        Feature

        FW

        Network (DHCP address pool, uplink management, NAT, and DNS)

        Physical interface

        IPsec VPN

        Security policy

        Traffic policy

        AP

        SSID (802.1X authentication)

        Radio (radio calibration, radio advanced settings, and channel planning on a per-device basis)

        Advanced blacklist and whitelist (MAC address filtering)

        Universal configuration

        NTP, SNMP, and local user management

        A site with less than 50 firewalls can be used as the source site for cloning.

  5. (Optional) In the Add Device area, add devices to the site.

    You can add devices to a site by device model or ESN. Alternatively, you can also add devices to a site after the site is created.

    When adding a device, you need to set the device role based on the site requirements. The recommended roles for each device type are as follows:

    • AP: Gateway, Access, or AP
    • LSW: Core, WAC, Aggregation, or Access
    • FW: Gateway, Gateway+Core, or Firewall
    • AR: Gateway, Gateway+Core, or Gateway+RR

      If the SD-WAN value-added feature has been installed and the GRE tunnel mode for SD-WAN scenarios has been set on the Design > Basic Network Design > Network Settings > Tunnel Mode page, sites can be classified into edge sites and RR sites.

      If the role of ARs is set to Gateway or Gateway+Core, the site to be created is an edge site. If the role of ARs is set to Gateway+RR, the site to be created is an RR site.
      • RR: A route reflector is an independent CPE. It distributes EVPN routes between CPEs based on VPN topology policies.
      • Edge: An edge site is a WAN-side router. It establishes secure data channels with multiple remote edge sites.
    • WAC: WAC

      If you do not set the device role when adding a device, the device role defaults to Access.

  6. Click OK. The site is created and configurations are delivered.

    You can click Apply and Deploy to go to the Branch Network page to perform deployment configurations. For details, see Branch Network.

Follow-up Procedure

  • Create sites in batches.

    You can click Batch Create, download the site configuration template, enter information about all sites in the template, and import the template to the system. Then you can create all required sites at a time.

  • Change the organization to which a site belongs.

    To change the organization to which a site belongs, select the target site and then click Change Organization.

  • Filter sites by organization.

    To create a lower-level organization of the current organization, click an organization name on the left and click . Currently, at most five-layer organizations can be created.

    You can click an organization name to view sites under the organization.

  • In EVPN tunnel mode, after a site is created and activated, by Importing and Exporting Site Configurations, you can:
    • Quickly configure a new site based on configured sites.

      You can export and modify the configuration of a deployed site and import the modified configuration to quickly deploy a new site. If the site name changes, you need to manually create a site with the changed name and import the configuration again.

    • Modify site configurations in batches.

      After exporting configurations of multiple sites, you can modify some parameters and import them to modify sites in batches. You can add, delete, and modify site configurations.

    • Restore site configurations.

      You can periodically export site configurations. If an error occurs during subsequent configuration, you can import the previous configuration to restore the site.

Parameter Description

Table 4-116 Key parameters for creating a site

Parameter

Description

Data Plan in Advance

Site Name

Name of the site to be created.

Y

Device type

Types of devices that can be added to the site. You can select one or more of the following: AP, AR, FW, LSW, WAC, OLT, ONU and NE.

Constraints:

  • After Device type is set, you can only add device types but cannot replace device types. For example, you can add firewalls to a site that contains only APs. However, you cannot change a site that contains only APs to a site that contains only firewalls. When LSWs are deployed as WACs, you need to select both LSW and WAC.
  • If OLTs and ONUs need to be managed by iMaster NCE-Campus, install the PON network management feature during iMaster NCE-Campus installation; otherwise, iMaster NCE-Campus cannot manage OLTs and ONUs.
  • APs and WACs cannot be deployed together at a site.

Y

Role

Constraints:

ARs configured with the Gateway or Gateway+Core role can be added only to edge sites. ARs configured with the Gateway+RR role can be added only to RR sites.

Value range:

  • For APs, the options include Gateway, Access, and AP.
  • For LSWs, the options include Core, WAC, Aggregation, and Access.
  • For firewalls, the options include Gateway, Gateway+Core, and Firewall.
  • For ARs, the options include Gateway, Gateway+Core, and Gateway+RR.
  • For WACs, Role can be set only to WAC.

    If you do not set the device role when adding a device, the system sets the device role to Access by default.

Y

Add Device
  • Select Device: Deploy existing devices to the site.
  • By Model: Add devices to the site by device model. After adding a device, you need to enter the device ESN. This mode is recommended.
  • By ESN: Add devices to the site by ESN.
  • Registration Center Synchronization: Information about added devices is synchronized to the registration center, implementing plug-and-play of all cloud managed devices.

Y

Configuration mode

Value range: The options include Default and Configuration File.

Constraints:

  • When you select the Configuration File mode, you need to prepare device configuration files in advance and then import and deliver the files to target devices on the Maintenance > Device Maintenance > Configuration File Management page to complete device configuration.
  • Sites created in Configuration File mode do not support the following functions: site configuration, VXLAN fabric configuration, admission configuration, third-party server configuration, and device upgrade.
  • Devices at sites created in Configuration File mode can be migrated to other sites created in the same mode. Such devices cannot be migrated to other sites created in Default mode or be removed from the current site.
  • Devices at sites created in Configuration File mode cannot be added to stacks after being configured using configuration files.
  • Sites created in Configuration File mode can use only specific northbound interfaces.

Y

Configuration source type
  • Default settings

    Meaning: With this option selected, you need to configure the site manually.

  • Clone from an existing site

    Meaning: With this option selected, you can clone the configuration of an existing site for use with the new site, reducing repeated configurations.

    Constraints: Currently, the following features can be cloned: Domain name, time zone, NTP, SNMP, local account, login restriction, HWTACACS, LLDP, HTTP service, public key exemption upon first authentication of the SSH client, terminal location information reporting, AP identity key, IPv6, NETCONF, global CLI, global security compliance, global NAT (firewall), ASPF, DNS, VLANIF (local Internet access), global interface management, SSID, global radio, Portal authentication, security policy, traffic policy, authentication and authorization policy, online control policy for users, portal page push rule, monitoring configuration, OUI for voice devices, VLAN information, wireless security, attack defense, global IoT, Bluetooth, DHCP, storm suppression, MAC blacklist/whitelist, NAT logging, and SA upgrade policy.

  • Deep clone

    Meaning: In deep clone mode, sites can be cloned one by one or in batches. If a small number of sites need to be cloned, you can clone them one by one. If a large number of sites need to be cloned, you can clone them in batches.

    Constraints: Currently, only the sites containing firewalls only or containing APs and firewalls support the deep cloning function. On iMaster NCE-Campus, you can clone selected site and device configurations from an existing site for use with the new site.

Y

Adding Devices

Introduction to SNMP

Overview of SNMP

Definition
SNMP is a standard network management protocol that is widely used on TCP/IP networks. The SNMP framework manages network elements using a central computer, known as a network management station (NMS), on which network management software is installed. SNMP offers simplicity and power.

  • Simplicity: SNMP uses a polling mechanism and provides basic network management functions, making it applicable to small-scale networks that are sensitive to speed and cost. Moreover, SNMP messages are carried in UDP packets, which are supported by most network devices.

  • Power: SNMP allows management information exchange between any two devices on a network, allowing network administrators to query information and locate faults anywhere on the network.

Purpose
As networks rapidly grow in scale and applications become more diversified, network administrators face the following problems:

  • The rapid growth in the number of network devices increases the workload for network administrators. In addition, networks' coverage areas are constantly being expanded, making real-time monitoring and fault location of network devices difficult.

  • Networks have many types of devices, and the management interfaces on devices of different vendors conform to different standards. This makes network management complex.

SNMP was developed to address these problems. SNMP supports batch management of network devices and implements unified management of devices of different types and vendors.

Version Evolution

SNMPv1 is the initial version of the SNMP protocol. It is defined in RFC 1157 drafted in May 1990. RFC 1157 provides a systematic method for monitoring and managing networks. However, SNMPv1 cannot ensure the security of networks because it is implemented based on community names and provides only a few error codes.

In 1996, the Internet Engineering Task Force (IETF) defined SNMPv2c in RFC 1901. SNMPv2c uses GetBulk and Inform operations and provides more error codes and data types (including Counter64 and Counter32) than SNMPv1.

To provide improved security protection measures, IETF released SNMPv3. SNMPv3 provides encryption and authentication based on the user-based security model (USM) and access control based on the view-based access control model (VACM).

Benefits

  • Improved work efficiency: A network administrator can use SNMP to query information, modify information, and locate faults on any device.

  • Reduced management costs: SNMP provides a basic function set to manage devices that have different management tasks, physical attributes, and network types.

  • Reduced impact of feature configuration operations on devices: SNMP is simple in terms of hardware/software installation, packet type, and packet format.

Understanding SNMP

SNMP Management Model

An SNMP system consists of four key components: network management station (NMS), agent, managed object, and Management Information Base (MIB).

The NMS manages network elements on a network.

Each managed device contains an agent process, MIB, and multiple managed objects. The NMS interacts with the agent on a managed device. When receiving a command from the NMS, the agent performs operations on the MIB in the managed device.

Figure 4-2 shows an SNMP management model.

Figure 4-2 SNMP management model

The following describes the components in an SNMP-managed system:

  • NMS

    The NMS is a network manager that uses SNMP to monitor and control network devices. The NMS software runs on NMS servers to implement the following functions:

    • Send requests to agents on managed devices to query or modify variables.
    • Receive traps from agents on managed devices to learn device status.

  • Agent

    The agent is a process running on a managed device. The agent maintains data on the managed device, responds to requests from the NMS, and returns management data to the NMS.

    • Upon receiving a request from the NMS, the agent performs the required operation on the MIB and sends the operation result to the NMS.
    • If a fault or an event occurs on the managed device, the agent sends a notification containing the current device status to the NMS.

  • Managed object

    A managed object is an object to be managed on a network device. A managed device may contain multiple managed objects, for example, a hardware component (such as an interface board) and parameters configured for the hardware or software (such as a routing protocol).

  • MIB

    A MIB contains the variables that the managed device maintains and can be queried or set by the agent. MIB defines the attributes of the managed device, including the name, status, access rights, and data type of managed objects.

    An agent can use the MIB to learn and set the device status.

    An SNMP MIB uses a tree structure similar to that of the Domain Name System (DNS), with an unnamed root at the top. Figure 4-3 shows a part of the MIB, called an object naming tree. Each object identifier (OID) identifies a managed object; for example, a system OID is 1.3.6.1.2.1.1 and an interface OID is 1.3.6.1.2.1.2.

    The OID tree facilitates information management and improves management efficiency. With the OID tree, the network administrator can query information in a batch.

    When configuring the agent, you can specify the MIB objects that the NMS can access in MIB views. A MIB view is a subset of a MIB.

    Figure 4-3 OID tree

SNMPv1/SNMPv2c

SNMPv1/SNMPv2c Packet Format

As shown in Figure 4-4, an SNMPv1/SNMPv2c packet is composed of the version, community name, and SNMP Protocol Date Unit (PDU) fields.

Figure 4-4 SNMPv1/SNMPv2c packet format

The following describes the fields in an SNMPv1/SNMPv2c packet:

  • Version: specifies the SNMP version. The value for SNMPv1 is 0 and for SNMPv2c is 1.

  • Community name: used for authentication between agents and NMSs. A community name is a configurable character string. There are two types of community names:
    • Read community names are used for the GetRequest and GetNextRequest operations.
    • Write community names are used for the Set operation.
  • SNMPv1/SNMPv2c PDU: includes the PDU type, request ID, and binding variable list.
    • SNMPv1 PDUs include the GetRequest PDU, GetNextRequest PDU, SetRequest PDU, Response PDU, and Trap PDU.
    • SNMPv2c PDUs include SNMPv1 PDUs and introduce the GetBulkRequest PDU and InformRequest PDU.

    For simplification, the SNMP operations are described as the Get, GetNext, Set, Response, Trap, GetBulk, and Inform operations.

SNMPv1/SNMPv2c Operations

As shown in Table 4-117, SNMPv1/SNMPv2c defines seven types of operations for exchanging information between the NMS and agents.

Table 4-117 SNMPv1/SNMPv2c operations

Operation

Description

Get

Retrieves one or several variables from the MIB of an agent process.

GetNext

Retrieves the next variables in alphabetic order from the MIB of the agent process.

Set

Sets one or several variables in the MIB of the agent process.

Response

Returns one or several variables. The agent performs this operation in response to the GetRequest, GetNextRequest, SetRequest, and GetBulkRequest operations. Upon receiving a Get or Set request from the NMS, the agent queries or modifies the variables in the MIB, and returns variables to the NMS.

Trap

Notifies the NMS of a fault or event occurring on a managed device. This operation is performed by the agent.

GetBulk

Batch queries variables on managed devices. This operation is performed by the NMS.

Inform

Notifies the NMS of a fault or event occurring on a managed device. After a managed device sends an inform request, the NMS must send an InformResponse packet as a response to the managed device.

SNMPv1 does not support the GetBulk and Inform operations.

Working Mechanisms of SNMPv1/SNMPv2c
The working mechanisms of SNMPv1 and SNMPv2c are similar, as shown in Figure 4-5.
Figure 4-5 Basic operations

  • Get

    In this example, the NMS intends to use the read community name public to obtain the value of the sysContact object on a managed device. The procedure is as follows:
    1. The NMS sends a GetRequest packet to the agent. The fields in the packet are as follows:
      • Version: SNMP version that the NMS is using
      • Community name: public
      • PDU type: Get
      • MIB object: sysContact

    2. The agent authenticates the SNMP version and community name in the packet. If authentication is successful, the agent queries the sysContact value from the MIB, encapsulates the sysContact value into the PDU of a response packet, and sends the response packet to the NMS. If the agent fails to obtain the sysContact value, the agent returns an error message to the NMS.

  • GetNext

    In this example, the NMS intends to use the community name public to obtain the value of the sysName object (next to sysContact) on a managed device. The procedure is as follows:
    1. The NMS sends a GetNextRequest packet to the agent. The fields in the packet are as follows:
      • Version: SNMP version that the NMS is using
      • Community name: public
      • PDU type: GetNext
      • MIB object: sysContact

    2. The agent authenticates the SNMP version and community name in the packet. If authentication is successful, the agent queries the sysName value from the MIB, encapsulates the sysName value into the PDU of a response packet, and sends the response packet to the NMS. If the agent fails to obtain the sysName value, the agent returns an error message to the NMS.

  • Set

    In this example, the NMS intends to use the read community name private to set the sysName object on a managed device to HUAWEI. The procedure is as follows:
    1. The NMS sends a SetRequest packet to the agent. The fields in the packet are as follows:
      • Version: SNMP version that the NMS is using
      • Community name: private
      • PDU type: Set
      • MIB object: sysName
      • Expected MIB object value: HUAWEI

    2. The agent authenticates the SNMP version and community name in the packet. If authentication is successful, the agent sets the sysName object to the expected value and sends a response packet to the NMS. If the setting fails, the agent returns an error message to the NMS.

  • Trap

    Trap is a spontaneous activity of a managed device. The Trap operation is not a basic operation that the NMS performs on the managed device. If a trap triggering condition is met, a managed device sends a trap to notify the NMS of the exception. For example, when a managed device completes a warm start, the agent sends a warmStart trap to the NMS.

    The agent sends a trap to the NMS only when a module on the managed device meets the trap triggering condition. This reduces management information exchange between the NMS and managed devices.

Figure 4-6 shows the operations that are added in SNMPv2c.
Figure 4-6 Operations added in SNMPv2c

  • GetBulk

    A GetBulk operation is equal to consecutive GetNext operations. You can set the number of GetNext operations to be included in one GetBulk operation.

  • Inform

    Inform is also a spontaneous activity of a managed device. In contrast to the trap operation, the inform operation requires an acknowledgement. After a managed device sends an inform request to the NMS, the NMS returns an InformResponse packet. If the managed device does not receive an acknowledgement, it performs the following operations:
    1. Saves the inform in the buffer.
    2. Repeatedly sends the inform request until the NMS returns an acknowledgement or the maximum number of retransmissions is reached.
    3. Records a log for the inform request.
    Therefore, the inform requests occupy more system resources than traps.

SNMPv3

SNMPv3 Packet Format

SNMPv3 defines a new packet format, as shown in Figure 4-7.

Figure 4-7 SNMPv3 packet format

The following describes the fields in an SNMPv3 packet:

  • Version: specifies the SNMP version. The value for SNMPv3 is 2.
  • Header: includes information such as the maximum message size that the transmitter supports and the security mode of messages.
  • Security parameters: includes the entity engine information, user name, authentication parameter, and encryption information.
  • Context EngineID: indicates the unique SNMP ID. The combination of this field and the PDU type determines to which application the PDUs are to be sent.
  • Context Name: determines the Context EngineID MIB view of the managed device.
  • SNMPv3 PDU: includes the PDU type, request ID, and binding variable list. The SNMPv3 PDU includes GetRequest PDU, GetNextRequest PDU, SetRequest PDU, Response PDU, Trap PDU, GetBulkRequest PDU, and InformRequest PDU.
SNMPv3 Architecture

SNMPv3 provides SNMPv3 entities through which all SNMP-enabled NMSs can manage SNMP-enabled network elements. An SNMPv3 entity consists of SNMPv3 engines and applications, which in turn consist of multiple modules.

The modular architecture of the SNMPv3 entity has the following advantages:
  • Strong adaptability: Adapts to both simple and complex networks.
  • Simple management: Consists of multiple independent sub-systems and applications. When a fault occurs in an SNMP system, it is easy to locate the sub-system where the fault originated according to the fault type.
  • Good expansibility: Supports addition of modules to extend an SNMP system. For example, a module can be added to the security subsystem to run a new security protocol.
SNMPv3 improves security through the User-based Security Model (USM) and view-based access control model (VACM):

  • USM: provides a shared key between the NMS and agents to authenticate user identities and encrypt data.

    • Identity authentication: a process in which an agent (or NMS) determines whether a received message is from an authorized NMS (or agent) and whether the message is modified during transmission. RFC 2104 defines Keyed-Hashing for Message Authentication Code (HMAC), which is a tool that uses the security hash function and key to generate message authentication codes and is widely used on the Internet. HMAC mechanisms that SNMP uses include HWAC-MD5-96 and HWAC-SHA-96. The hash function of HWAC-MD5-96 is MD5, which uses a 128-bit authKey to generate keys. The hash function of HWAC-SHA-96 is SHA-1, which uses a 160-bit authKey to generate keys.

    • Data encryption: Like identity authentication, data encryption also requires the network management station and the agent to use a shared key for encryption or decryption. ESP encrypts the IP packet contents to prevent them from being intercepted during transmission. Encryption algorithms are implemented using a symmetric key system, which uses the same key to encrypt and decrypt data. SNMP uses the following encryption algorithms:

      • Data Encryption Standard (DES): encrypts 64-bit plain text by using a 56-bit key.
      • Triple Data Encryption Standard (3DES): encrypts plain text by using three 56-bit DES keys (a 168-bit key).
      • Advanced Encryption Standard (AES): encrypts plain text by using a 128-bit, 192-bit, or 256-bit key.

      The following are the three encryption algorithms, listed from most to least secure: AES, 3DES, and DES. A more secure encryption algorithm requires more system resources, which slows down the computing speed. To ensure device security, it is advised to use the more secure encryption algorithms AES.

  • VACM: controls access of user groups or community names based on views. You must pre-configure a view and specify its authority. Then, when you configure a user, user group, or community, you must load this view to implement read/write restrictions or Inform/trap functions.

SNMPv3 Mechanism

SNMPv3 has a similar mechanism to SNMPv1 and SNMPv2c. The only difference is that SNMPv3 supports identity authentication and encryption. The following uses the Get operation as an example to describe the SNMPv3 mechanism.

As shown in Figure 4-8, an NMS intends to obtain the value of the sysContact object on a managed device in authentication and encryption mode.
Figure 4-8 Get operation of SNMPv3

  1. The NMS sends a GetRequest packet without security parameters to the agent and requests the values of Context EngineID, Context Name, and security parameter.

  2. The agent returns a response that contains the requested parameters.

  3. The NMS sends a GetRequest packet to the agent again. The fields in the packet are as follows:
    • Version: SNMPv3.
    • Header: authentication and encryption modes.
    • Security parameters: The NMS calculates the authentication and encryption parameters in accordance with the security parameters obtained from the agent. Then, the NMS fills the authentication, encryption, and security parameters in the corresponding fields.
    • PDU: The NMS fills the obtained Context EngineID and Context Name in the corresponding fields. The PDU type is set to Get, the MIB object name is sysContact, and the configured encryption algorithm is used to encrypt the PDU.

  4. The agent authenticates the GetRequest packet sent from the NMS. If authentication is successful, the agent decrypts the PDU. If decryption is successful, the agent obtains the value of sysContact and encapsulates it in the PDU of the response packet. The agent encrypts the PDU and sends the response packet to the NMS. If the query, authentication, or encryption operation fails, the agent sends an error message to the NMS.

Application Scenarios for SNMP

Device Management Through SNMP

Figure 4-9 illustrates an example network on which SNMP may be applied. On this network, the network administrator needs to configure and manage all devices. However, these devices are sparsely-located around the site, making it impossible for the network administrator to configure and manage them all. To make matters worse, these devices are from different vendors and provide different management interfaces, making network management complex. To reduce operation cost and improve work efficiency, the network administrator can use SNMP to remotely manage, configure, and monitor network devices.

Figure 4-9 Diagram for device management through SNMP

To configure SNMP on the network, configure the NMS program on the management end and an agent on each managed device.

SNMP allows:

  • The NMS to learn managed device status by sending requests to agents and control the devices remotely.

  • Each agent to report the managed device status and faults to the NMS in real time.

Interconnection with Huawei eSight

As shown in Figure 4-10, devices report alarms to eSight, a Huawei NMS, through SNMP. To quickly locate and rectify faults based on alarms, users want to the devices also to report the alarm type, alarm sequence number, and reporting time. In addition, for the alarms defined by common MIBs, users want to extend the alarms for alarm analysis.

As such, the parameters private-netmanager and ext-vb are defined for interconnection between Huawei devices and eSight. When the private-netmanager parameter is specified, the alarm information reported by the device contains the alarm type, alarm sequence number, and reporting time. When the ext-vb parameter is specified, the alarm information reported by the device contains Huawei-defined parameters.

Figure 4-10 Interconnection between devices and Huawei eSight

Introduction to NETCONF

Overview of NETCONF

Definition

Network Configuration Protocol (NETCONF) is a communication mechanism used between a network management system (NMS) and managed devices. A network administrator can use NETCONF to add, modify, and delete configurations of network devices, and obtain the configurations and status of network devices. Network devices provide standard application programming interfaces (APIs), through which the NMS can manage these devices using NETCONF. For details about APIs, see Getting Started with NETCONF and YANG.

Purpose

The Simple Network Management Protocol (SNMP) is not a configuration-oriented protocol. On a large-sized network with a complex topology, SNMP cannot meet network management requirements, especially the configuration management requirements. To meet such requirements, Extensible Markup Language (XML)-based NETCONF has been introduced.

NETCONF can be implemented by using the existing functional modules of a device. This reduces NETCONF development costs and allows easy access to new features. Table 4-118 lists the advantages of NETCONF over SNMP.

Table 4-118 Comparison between SNMP and NETCONF

Item

SNMP

NETCONF

Configuration protection

Not supported.

Supported. NETCONF provides a lock mechanism to prevent multi-user configuration conflicts.

Configuration backup

Not supported.

Supported. NETCONF provides multiple configuration databases (databases for short), which are backups of each other.

Configuration query

Supported. Querying one or more records in a table requires multiple times of interaction.

Supported. NETCONF can query all configuration data of one object based on filtering conditions. The batch data collection speed of NETCONF is 10 times faster than that of SNMP.

Scalability

Poor.
Good.
  • NETCONF uses a multi-layer model. Each layer is independent of other layers. The extension of one layer has no impact on other layers.
  • NETCONF is in XML encoding format. This format expands the management capability and system compatibility of NETCONF.

Security

Among the versions of SNMP, only SNMPv3 provides authentication and encryption. However, the authentication and encryption functions of SNMPv3 cannot be expanded.

NETCONF uses existing security protocols, such as Secure Shell (SSH) and Simple Object Access Protocol (SOAP), to ensure network security, and is not specific to any security protocols. NETCONF is more flexible than SNMP in security protection.

Understanding NETCONF

NETCONF Working Mechanism

NETCONF Modes
A switch supports the following NETCONF modes:
  • NETCONF over SSH Callhome: In this mode, the switch proactively sets up a NETCONF session with the network management system (NMS), which is Huawei's iMaster NCE-Campus.
  • NETCONF over SSH: In this mode, the NMS, which is a third-party NMS, proactively sets up a NETCONF session with the switch.
NETCONF System Model

A NETCONF system uses the client-server model, as shown in Figure 4-11. The NMS uses the NETCONF protocol to configure and manage network devices.

Figure 4-11 NETCONF system model
NETCONF Protocol Architecture

Similar to the OSI model, NETCONF includes four layers, as described in Table 4-119.

Table 4-119 NETCONF protocol architecture

Layer

Content

Description

Content

Configuration data, status data, statistics, notifications, etc.

The Content layer contains a set of managed objects, such as configuration data, status data, statistics, and notifications.

Operations

Databases, capabilities, and operations

The Operations layer defines the databases, capabilities, and operations supported by NETCONF. For details, see Databases Supported by NETCONF and Capabilities and Operations Supported by NETCONF.

Messages

<rpc>, <rpc-reply>, and <notification>
The Messages layer provides a simple remote procedure call (RPC) request and response mechanism independent of transport protocols, and a notification mechanism used by network devices to actively report alarms and events to the NMS.
  • The NMS uses the <rpc> element to encapsulate the operation request information and sends the information to network devices. The network devices use the <rpc-reply> element to encapsulate the RPC response information and send the information to the NMS. Normally, the <rpc-reply> element encapsulates the requested data or a configuration success message. If the NMS sends an incorrect request or the network device fails to process a request from the NMS, the <rpc-reply> element returned to the NMS contains a <rpc-error> element.
  • Network devices use the <notification> element to report alarms and events to the NMS.

Secure Transport

SSH, SOAP, etc.

The Secure Transport layer provides a communication path for interaction between the NMS and network devices.

NETCONF can be layered over any transport protocol that meets the following basic requirements:
  • Connection-oriented: NETCONF is connection-oriented, requiring a persistent connection between peers. This connection must provide reliable, sequenced data delivery.
  • Reliable: NETCONF connections must provide authentication, data integrity, confidentiality, and replay protection.
NOTE:

The switch supports only the SSH protocol as the transport protocol.

NETCONF Interaction Process

Figure 4-12 shows the NETCONF interaction process between an NMS and a switch.

Figure 4-12 NETCONF interaction process
  1. The switch sets up an SSH connection with the NMS.
  2. The switch and NMS exchange their supported capabilities by sending hello packets.
  3. After setting up a NETCONF session with the switch, the NMS sends an RPC request to the switch for configuration management.
  4. The switch parses and handles the received RPC request, and sends an RPC reply to the NMS.
  5. After the preceding operations are complete, the NMS sends an RPC request to close the NETCONF session. This reduces resource consumption on the switch and NMS.
  6. The switch closes the NETCONF session, and sends an RPC reply to the NMS.
# A sample of a hello packet sent by the switch is as follows. base and writable-running are the capabilities supported by the switch. For details, see Capabilities and Operations Supported by NETCONF.
<?xml version="1.0" encoding="UTF-8"?> 
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> 
  <capabilities> 
    <capability>urn:ietf:params:netconf:base:1.0</capability> 
    <capability>urn:ietf:params:netconf:capability:writable-running:1.0</capability> 
    <capability>urn:ietf:params:netconf:capability:candidate:1.0</capability> 
    <capability>urn:ietf:params:netconf:capability:confirmed-commit:1.0</capability> 
    <capability>urn:ietf:params:netconf:capability:rollback-on-error:1.0</capability> 
    <capability>urn:ietf:params:netconf:capability:validate:1.0</capability> 
    <capability>urn:ietf:params:netconf:capability:startup:1.0</capability> 
  </capabilities> 
  <session-id>1227</session-id> 
</hello> 
]]>]]>
# A sample of a hello packet sent by the NMS is as follows.
<?xml version="1.0" encoding="UTF-8"?> 
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> 
  <capabilities> 
    <capability>urn:ietf:params:netconf:base:1.0</capability> 
    <capability>urn:ietf:params:netconf:capability:writable-running:1.0</capability> 
    <capability>urn:ietf:params:netconf:capability:candidate:1.0</capability> 
    <capability>urn:ietf:params:netconf:capability:confirmed-commit:1.0</capability> 
    <capability>urn:ietf:params:netconf:capability:rollback-on-error:1.0</capability> 
    <capability>urn:ietf:params:netconf:capability:validate:1.0</capability> 
    <capability>urn:ietf:params:netconf:capability:startup:1.0</capability> 
  </capabilities> 
</hello> 
]]>]]>
# A sample of a session close RPC request sent by the NMS is as follows.
<?xml version="1.0" encoding="UTF-8"?> 
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> 
  <close-session/> 
</rpc> 
]]>]]>
# A sample of a session close RPC reply sent by the switch is as follows.
<?xml version="1.0" encoding="UTF-8"?> 
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> 
  <ok/>  
</rpc-reply> 
]]>]]>

Databases Supported by NETCONF

The NMS uses NETCONF to manage network devices. The configuration and status data is stored in three standard databases, as listed in Table 4-120.

Table 4-120 NETCONF databases

Database

Description

Relationship Among Three Databases

<running/>

Stores the effective running configurations delivered through NETCONF.The data in this database can be modified, and the modifications take effect immediately.

This is the only mandatory standard database.
  • The modifications on <candidate/> take effect only after the modified data is committed to the <running/> database.
  • When the system is starting, it automatically copies the data in <startup/> to <running/>.
  • The three databases can be replaced with each other by performing the <copy-config> operation.

<candidate/>

Stores ineffective candidate configurations on devices. The data in this database can be modified, and the modifications will not take effect immediately.

This database is supported by Candidate Configuration.

<startup/>

Stores the configuration that will take effect after next startup. The data in this database cannot be modified. You can only replace the database by performing the <copy-config> operation.

This database is supported by Distinct Startup.

Capabilities and Operations Supported by NETCONF

Device information is stored in databases. Therefore, the NETCONF protocol defines the basic capability base, which includes a set of operations that modify database configurations and obtain information from the databases. The operations included in base must be a minimal set of functions supported by NETCONF, but not all functions of NETCONF. Table 4-121 lists the operations included in base.

Table 4-121 Operations included in base

Operation

Description
<get-config>

Obtains some or all configuration data from the <running/>, <candidate/>, and <startup/> databases.
<get>

Obtains some or all running configuration data and status data from the <running/> database.
<edit-config>

Adds, modifies, and deletes configuration data in the <running/> or <candidate/> database.
<copy-config>

Replaces the target database with the source database. If no target database has been created, this operation creates a database and then replaces the database.
<delete-config>

Deletes a database. The <running/> database cannot be deleted.
<lock>

Locks a database. A locked database cannot be modified by other users, preventing multi-user configuration conflicts.
<unlock>

Unlocks a database. Users can unlock only the databases they have locked.
<close-session>

Closes a NETCONF session.
<kill-session>

Forcibly closes a NETCONF session. Only an administrator can perform this operation.

In addition to basic capabilities, NETCONF also provides a series of standard capabilities. These standard capabilities enhance the NETCONF functionality and strengthen the fault tolerance and scalability. They facilitate the implementation of the NETCONF-based open network management architecture, and provide an efficient method for equipment manufacturers to develop new functions. Table 4-122 lists the standard capabilities and operations of NETCONF.

Table 4-122 Standard capabilities and operations of NETCONF
Capability

Description

Operation

Writable-Running

This capability allows a device to perform the <edit-config> and <copy-config> operations on the <running/> database.

-

Candidate Configuration

This capability indicates that a device supports the <candidate/> database.

This capability allows a device to operate the <candidate/> database without affecting the <running/> database.

<commit>: commits all configuration data in the <candidate/> database. The committed data becomes the running configuration data.

<discard-changes>: discards uncommitted configuration data in the <candidate/> database. After this operation is performed, the configuration data in the <candidate/> database remains the same as that in the <running/> database.

Rollback on Error

This capability allows a device to perform a rollback. If an error occurs during the <edit-config> operation and the <rpc-error> element is generated, the NMS stops performing the <edit-config> operation and restores the specified configuration to the status before the <edit-config> operation is performed.

-

Distinct Startup

This capability indicates that a device is capable of starting independently and supports the <startup/> database.

-

Notification

This capability indicates that a device can send alarms and events to the NMS. The NMS manages the device based on the received alarms and events.

<notification>: actively sends alarms and events to the NMS.

Interleave

This capability indicates that a device supports NETCONF session reuse for multiple purposes. You can use the same NETCONF session to maintain the device and manage the alarms and events, improving management efficiency.

-

Interaction Between Huawei Switches and iMaster NCE-Campus

Basic Concepts

iMaster NCE-Campus

iMaster NCE-Campus is a core component in the Huawei CloudCampus Solution and centrally manages Huawei network devices, such as access points (APs), access routers (ARs), switches, and firewalls. iMaster NCE-Campus implements unified multi-tenant management, allows plug-and-play network devices, supports batch network service deployment, and provides Application Programming Interfaces (APIs) to interoperate with third-party platforms for value-added service expansion.

Registration Query Center

A registration query center is a main component in the Huawei CloudCampus Solution and allows devices to query the NETCONF enabling configuration and home iMaster NCE-Campus. iMaster NCE-Campus synchronizes the device information imported by administrators to the registration query center in real time. Switches then send requests to the registration query center, automatically enable the NETCONF function, obtain the iMaster NCE-Campus's address information, and become plug and play.

Management VLAN

A management VLAN is the VLAN to which the interface connecting a switch to a DHCP server belongs in the Huawei CloudCampus Solution, and is maintained and delivered to the switch by iMaster NCE-Campus.

PnP VLAN

A Plug and Play VLAN (PnP VLAN) is the VLAN used to implement plug and play of switches. This VLAN is preconfigured on and maintained by iMaster NCE-Campus. It is automatically delivered to a switch after the switch registers with iMaster NCE-Campus. There are two types of PnP VLANs: wired and wireless PnP VLANs, which are both preconfigured and maintained by iMaster NCE-Campus and are automatically delivered to switches after they register with iMaster NCE-Campus. Switches use the wired PnP VLAN to apply for management IP addresses, and change the PVID of interfaces connected to APs to the wireless PnP VLAN ID. The two VLANs can be the same or different.

Basic Procedure

In NETCONF over SSH Callhome mode, switches proactively set up NETCONF sessions with iMaster NCE-Campus. The procedure consists of three phases.

Phase 1: Switches Obtain the NETCONF Enabling Configuration and iMaster NCE-Campus's Address Information

Switches need to have the NETCONF function enabled, and obtain the URL/IP address and port number of iMaster NCE-Campus. Then these switches are ready to communicate with iMaster NCE-Campus. Table 4-123 describes the methods for switches to enable NETCONF and obtain iMaster NCE-Campus's address information.

Table 4-123 Methods to enable NETCONF and obtain iMaster NCE-Campus's address information

Method

Description

Scenario

Priority

Through a DHCP server

Option 148 is configured on a DHCP server to contain the NETCONF enabling configuration and iMaster NCE-Campus's address information. Switches obtain the information from the DHCP server.

This method applies to campus networks on which devices cannot communicate with the registration query center. iMaster NCE-Campus for these networks is often built by enterprises.

High priority. This method is preferred if switches can use multiple methods to enable NETCONF and obtain iMaster NCE-Campus's address information.

Through a registration query center

The DHCP server is configured with the DNS mapping between the URL and IP address of the registration query center. The switch accesses the registration query center using the registration query center URL and port number obtained through pre-configuration or software upgrade.

If a switch cannot obtain the NETCONF enabling status and iMaster NCE-Campus's address information through Option 148 from the DHCP server, the switch sends a query request to the registration query center to obtain the information based on its ESN.

This method applies to campus networks on which devices can communicate with the registration query center. The management platforms for these networks can be the iMaster NCE-Campus, Huawei public cloud, or other management platforms, such as MSP-built and enterprise-built management platforms.

Low priority.

Using commands or the web system

Users manually configure the iMaster NCE-Campus's address information on switches.

If switches cannot automatically enable the NETCONF function or dynamically obtain the iMaster NCE-Campus's address information using the preceding two methods, manually enable NETCONF and configure the iMaster NCE-Campus's address information on the switches through commands or the web system.

Medium priority.
Phase 2: Switches Register with iMaster NCE-Campus

Before a switch registers with iMaster NCE-Campus, iMaster NCE-Campus has imported the following information about each switch: chassis ESN, device type, binding between slots and card names, and CA certificate. Each switch has a local certificate and CA certificate configured before delivery.

After main control boards of a switch finish starting, the switch registers with iMaster NCE-Campus for authentication based on the obtained IP address or URL of iMaster NCE-Campus, and establishes a NETCONF transmission channel over SSH with iMaster NCE-Campus, ensuring data transmission security.

  • The switch uses its chassis ESN to register with iMaster NCE-Campus for authentication. If iMaster NCE-Campus does not have the switch's chassis ESN, the switch cannot register with iMaster NCE-Campus.
  • When an interface card finishes starting and registers with the main control card of the switch, the main control card instructs iMaster NCE-Campus to register the interface card. When the name of a card registered in a slot is consistent with the binding between the slot and card name preconfigured on iMaster NCE-Campus, the card can register with iMaster NCE-Campus. If information inconsistency occurs, the card cannot be registered.
  • If the binding between a slot and a card name is not preconfigured on iMaster NCE-Campus, the card can register with iMaster NCE-Campus and the binding between the slot and the card name is fixed after the registration. iMaster NCE-Campus delivers all the preconfigurations to the switch only when all the cards preconfigured on iMaster NCE-Campus are registered.

For details about registration authentication on switches, see "PKI Configuration" in the S12700, S12700E V200R020C20 Configuration Guide - Security.

After a switch registers with iMaster NCE-Campus:

  • If a user configures the iMaster NCE-Campus's IP address for redirection on the GUI of iMaster NCE-Campus, the switch immediately uses this IP address to re-register with iMaster NCE-Campus.
  • If a user reconfigures a management VLAN on the GUI of iMaster NCE-Campus, the switch immediately uses the new management VLAN to send a request to the DHCP server to obtain the iMaster NCE-Campus's IP address and re-registers with iMaster NCE-Campus for authentication.
Phase 3: Switches Are Centrally Managed by iMaster NCE-Campus

After NETCONF transmission channels are established, iMaster NCE-Campus can manage and operate the switches. All the data exchanged between iMaster NCE-Campus and switches will be encrypted.

For details about how iMaster NCE-Campus manages switches, see the Huawei CloudCampus Solution.

Obtaining the NETCONF Enabling Configuration and iMaster NCE-Campus's Address Information Through a DHCP Server

Procedure

In the Huawei CloudCampus Solution, a DHCP server helps implement plug-and-play deployment of switches, removing the need to manually enable NETCONF and configure iMaster NCE-Campus's address information on switches.

Figure 4-13 Obtaining the NETCONF enabling configuration and iMaster NCE-Campus's address information through a DHCP server

In Figure 4-13:

  1. An administrator deploys the DHCP server function on the egress gateway or deploys an independent DHCP server on the network, and then configures DHCP Option 148, which contains the NETCONF enabling configuration and iMaster NCE-Campus's IP address/URL and port number.
  2. An unconfigured switch starts and sends a request packet containing VLAN 1 to the DHCP server.
    • If the VLAN for the IP address pool of the DHCP server is VLAN 1, the switch can use VLAN 1 to communicate with the DHCP server and register with iMaster NCE-Campus. If the switch successfully negotiates a PnP VLAN with the upstream device, the switch uses this PnP VLAN to register with iMaster NCE-Campus again. For details about the PnP VLAN negotiation process, see PnP VLAN Auto-Negotiation.
    • If the VLAN for the IP address pool of the DHCP server is not VLAN 1, the switch cannot use VLAN 1 to communicate with the DHCP server. The switch then uses the upstream device's PnP VLAN negotiated through the Link Layer Discovery Protocol (LLDP) to initiate a request to the DHCP server again.
  3. The DHCP server receives the request and sends a DHCP packet containing Option 148 to the switch.
  4. Based on Option 148, the switch enables NETCONF and obtains the URL/IP address and port number of iMaster NCE-Campus. The switch then generates a configuration file for the management VLAN.
  5. The switch uses the obtained URL/IP address and port number of iMaster NCE-Campus to register with iMaster NCE-Campus.
  • If a management VLAN has been configured on a switch using iMaster NCE-Campus or a command, the switch directly uses this management VLAN to send requests to the DHCP server. Even if the requests fail, the switch will not use the PnP VLAN to send requests to the DHCP server. Therefore, ensure that the switch can communicate with the DHCP server in this management VLAN, so that the switch can go online properly.
  • If this is not the first time the switch registers with iMaster NCE-Campus, the switch preferentially uses the device IP address and iMaster NCE-Campus's URL/IP address and port number cached in the memory. To change the iMaster NCE-Campus's URL/IP address and port number through Option 148, you need to restart the switch to make it obtain the iMaster NCE-Campus's URL/IP address and port number again.
PnP VLAN Auto-Negotiation

There are two types of PnP VLANs: wired and wireless PnP VLANs. Switches use the wired PnP VLAN to apply for management IP addresses, and change the PVID of interfaces connected to APs to the wireless PnP VLAN ID.

For switches, PnP VLAN negotiation involves both the wired and wireless PnP VLANs. If only a wired PnP VLAN is configured, the PVID of the switch interfaces connected to APs is changed to the wired PnP VLAN ID.

In versions earlier than V200R020, the wired and wireless PnP VLANs are configured using the same command. In V200R020 and later versions, the wired and wireless PnP VLANs are configured using two different commands.

  • Background

    In Figure 4-14, assume that an administrator changes the management VLAN to a VLAN other than VLAN 1 (default VLAN) on iMaster NCE-Campus. The administrator also needs to change the VLAN for the IP address pool of the DHCP server to the management VLAN. An unconfigured switch, SwitchC, needs to connect to the network. After SwitchC is powered on and starts, it sends a request packet containing VLAN 1 to the DHCP server to obtain the NETCONF enabling configuration and iMaster NCE-Campus's address information. However, SwitchC fails to obtain the requested information and register with iMaster NCE-Campus. This is because the VLAN for the IP address pool of the DHCP server has been changed to a VLAN other than VLAN 1.

    To solve this problem, PnP VLAN auto-negotiation is used:

    1. If SwitchA has NETCONF enabled and has registered with iMaster NCE-Campus, iMaster NCE-Campus delivers a PnP VLAN to SwitchA based on the preconfiguration. If SwitchA does not have NETCONF enabled, manually configure a PnP VLAN on SwitchA using a command. SwitchA can use this wired PnP VLAN to communicate with the DHCP server normally.
    2. SwitchC connects to the network and auto-negotiates with the upstream device (SwitchA) to obtain the PnP VLAN.
    3. SwitchC uses the negotiated wired PnP VLAN to obtain the NETCONF enabling configuration and iMaster NCE-Campus's address information from the DHCP server. This process implements plug and play of new devices.
    4. SwitchB identifies that the downstream device is an AP and changes the PVID of the interface connected to the AP to the wireless PnP VLAN.
    Figure 4-14 CloudCampus networking

    Switches managed by iMaster NCE-Campus support PnP VLAN auto-negotiation, which has the following advantages:

    • A new device can connect to the network through any interface of an upstream device, and the upstream device can identify the access interface and adds the interface to the PnP VLAN.
    • If an upstream device and a downstream device are connected through multiple links, they can auto-negotiate the multiple links as an Eth-Trunk and auto-negotiate the working mode of the Eth-Trunk as LACP.

The auto-negotiated uplink Eth-Trunk of the downstream device is fixed as Eth-Trunk 0, whose working mode is also auto-negotiated with the upstream device. To manually change the working mode of Eth-Trunk 0, you need to first run the undo pnp startup-vlan receive enable command to disable the PnP VLAN auto-negotiation function on the downstream device.

  • Adding a new unconfigured switch to a campus network

    Figure 4-15 shows the process of adding a new unconfigured switch to a campus network, which is described as follows.

    1. A new unconfigured switch starts and sends LLDP packets to negotiate with the upstream device in an effort to obtain the PnP VLAN configured on the upstream device.
    2. The switch uses the negotiated wired PnP VLAN to obtain the NETCONF enabling configuration and iMaster NCE-Campus's address information from the DHCP server. The switch uses the negotiated wired PnP VLAN to send DHCP request packets regardless of whether it can use VLAN 1 to receive DHCP response packets. That is, a wired PnP VLAN takes precedence over VLAN 1.
    3. The switch enables NETCONF based on the NETCONF enabling configuration obtained from the DHCP server.
    4. The switch registers with iMaster NCE-Campus based on the iMaster NCE-Campus address information obtained from the DHCP server.
    5. iMaster NCE-Campus delivers the preset PnP VLAN configuration to the upstream switch of the new switch, so that the new switch can perform PnP VLAN auto-negotiation with the upstream switch. The PnP VLAN configuration includes: wired and wireless PnP VLAN IDs, enabling the function of transmitting a PnP VLAN to a downstream device, enabling the function of sending LLDP packets containing PnP VLAN information to a downstream device (this function is enabled by default).
    Figure 4-15 Adding a new unconfigured switch to a campus network
  • Processing a PnP VLAN switchover

    In Figure 4-16, when the upstream device has NETCONF enabled, iMaster NCE-Campus can modify the PnP VLAN of the upstream device to enable the downstream device to use the new PnP VLAN for re-registration. When the upstream device does not have NETCONF enabled, you can modify the PnP VLAN of the upstream device using a command to enable the downstream device to use the new PnP VLAN for re-registration.

    The upstream device's PnP VLAN and the management VLAN are two concepts. The two VLANs can be the same or different. If the two VLANs are different, the downstream device can register with iMaster NCE-Campus normally only when iMaster NCE-Campus communicates with the upstream device normally.

    When the upstream device has NETCONF enabled, changing the PnP VLAN enables only the downstream device but not the upstream device to register with iMaster NCE-Campus again. Whether the upstream device registers with iMaster NCE-Campus again depends on whether its management VLAN is changed.

    Figure 4-16 Processing a PnP VLAN switchover

Obtaining the NETCONF Enabling Configuration and iMaster NCE-Campus's Address Information Through the Registration Query Center

In addition to using DHCP, switches can obtain the NETCONF enabling configuration and iMaster NCE-Campus's address information through the registration query center. On the network shown in Figure 4-17, two types of HTTP/2 connections are established for interaction:

  1. iMaster NCE-Campus needs to set up an HTTP/2 connection with and synchronize information about to-be-managed devices to the registration query center.
  2. A switch first obtains its management IP address from the DHCP server (the egress gateway shown in Figure 4-17 can also function as a DHCP server). The switch then sets up an HTTP/2 connection with the registration query center, enables NETCONF, and obtains iMaster NCE-Campus's address information.

If this is not the first time a switch registers with iMaster NCE-Campus, the switch preferentially uses the device IP address and iMaster NCE-Campus's URL/IP address and port number recorded in a file. To enable the switch to obtain iMaster NCE-Campus's new URL/IP address and port number from the registration query center, you need to restore the switch to the factory settings.

Figure 4-17 Network with the registration query center

Interaction between iMaster NCE-Campus and the registration query center through an HTTP/2 connection

As shown in Figure 4-18, an administrator imports information about new devices, including the ESNs and device types, into iMaster NCE-Campus. iMaster NCE-Campus then initiates an HTTP request to the registration query center to upload the information. After receiving the request, the registration query center performs two-way authentication and sets up an HTTP/2 connection with iMaster NCE-Campus. After the connection is set up, iMaster NCE-Campus uploads its address information and the new devices' information (including ESNs) to the registration query center.

Figure 4-18 Interaction between iMaster NCE-Campus and the registration query center through an HTTP/2 connection

Interaction between a switch and the registration query center through an HTTP/2 connection

NETCONF-capable switches are preconfigured with the URL (register.naas.huawei.com) and port number (10020) of the registration query center. As shown in Figure 4-19, after a switch connects to a network, it initiates an HTTP request to the registration query center. The switch and registration query center then set up an HTTP/2 connection for bidirectional authentication. After the connection is set up, the switch sends a request packet carrying its ESN to the registration query center. After receiving the request packet, the registration query center finds the corresponding ESN in the system, and sends a response packet carrying iMaster NCE-Campus information to the switch. The switch enables NETCONF and obtains iMaster NCE-Campus information from the response packet, and then registers with iMaster NCE-Campus.

Figure 4-19 Interaction between a switch and the registration query center through an HTTP/2 connection

Process of Registering a Stack with iMaster NCE-Campus

Only multi-active detection (MAD) in relay mode can be configured for a stack on iMaster NCE-Campus.

A stack can only be registered with iMaster NCE-Campus after it is set up. Setting up a stack by delivering the stack configuration through iMaster NCE-Campus is not supported.

Stack members can be registered with iMaster NCE-Campus only when iMaster NCE-Campus has the chassis ESNs of the members.

Stack Registration
Figure 4-20 Registering a stack with iMaster NCE-Campus

A stack can only be registered successfully when information about stack members is consistent with that configured on iMaster NCE-Campus.

  • A stack cannot be registered if the stack status (standalone or stack mode) is different from that configured on iMaster NCE-Campus.
  • If the chassis ESN of a stack member does not exist on iMaster NCE-Campus, the stack cannot go online on iMaster NCE-Campus.
  • A stack cannot be registered if the chassis ID is different from that configured on iMaster NCE-Campus.
  • If the priority of a stack member is different from that configured on iMaster NCE-Campus, iMaster NCE-Campus delivers the configuration that exists on itself to the stack member, so that the stack member can be registered after restarting with the new configuration.
Stack Version Upgrade
Figure 4-21 Stack version upgrade flowchart

Application Scenarios for NETCONF

Application Scenario of the NETCONF over SSH Callhome Mode

In the Huawei CloudCampus Solution, switches are deployed at the access or aggregation layer of a campus network for data forwarding. In contrast with switches that have NETCONF disabled, NETCONF-enabled switches are plug-and-play and can automatically register with iMaster NCE-Campus over the Internet for zero touch deployment. Additionally, NETCONF-enabled switches support configurations delivered by iMaster NCE-Campus anytime, anywhere, achieving fast batch service configuration.

In Figure 4-22, the egress gateway functions as a DHCP server, which is configured with Option 148 containing the NETCONF enabling configuration and iMaster NCE-Campus's address information. Using DHCP, switches can automatically enable the NETCONF function, obtain the iMaster NCE-Campus's address information, and become plug and play. This networking applies to the enterprise-built cloud platforms that are not connected to the registration query center.

Figure 4-22 Obtaining iMaster NCE-Campus's address information through DHCP

In Figure 4-23, the registration query center is deployed in the Huawei CloudCampus Solution. iMaster NCE-Campus synchronizes the device information imported by administrators to the registration query center in real time. Switches then send requests to the registration query center, automatically enable the NETCONF function, obtain the iMaster NCE-Campus's address information, and become plug and play. This networking applies to the Huawei public cloud platform, MSP-built cloud platforms, and enterprise-built cloud platforms that are connected to the registration query center.

Figure 4-23 Enabling NETCONF and obtaining the iMaster NCE-Campus's address information through the registration query center
Application Scenario of the NETCONF over SSH Mode

Using NETCONF, third-party NMSs can provide unified network management through a GUI and improves the security, reliability, and scalability of device management. In Figure 4-24, the NMS sets up NETCONF sessions with all switches on the network. The administrator can manage these switches on the GUI provided by the NMS to improve O&M efficiency.

Figure 4-24 Application of the NETCONF over SSH mode

Introduction to Stacking

Using the Stack Assistant Tool to Quickly Obtain Information

Figure 4-25 shows the stack assistant tool page.
Figure 4-25 Stack assistant tool page
How to use this tool:

  1. Starting from Stack & SVF type, select S/E Switches iStack > Switch series > Switch sub-series > Switch model > Software version > Connection mode > Stack cable > Switch stacked together in sequence.

    Click behind Stack cable to view the images of cables.

    To check whether a switch supports service port stacking using dedicated stack cables, perform the following operations: Select Service port stacking, and then check whether you can select 0.5 m and 1.5 m SFP+ dedicated stack cable or 0.5 m and 1.5 m SFP+ dedicated stack cable (supported from V200R011C10) as stack cables. If so, switches of this model support service port stacking using dedicated stack cables.

  2. Click Query after finishing the selection. The stack precautions, connection rules, and software configuration are displayed. Set up a stack according to the information.

Stack Overview

Definition

A stack can have multiple stacking-capable switches connected through stack cables. These switches, also known as stack members, work together as a unified system. The entire stack works as a single entity to the network.

In Figure 4-26, SwitchA and SwitchB are connected through stack cables to set up a stack.

Figure 4-26 Stack
Application Scenarios

  • Improving reliability

    Multiple stack members work in redundancy mode. In Figure 4-26, SwitchA and SwitchB set up a stack and back up each other. When SwitchA fails, SwitchB assumes the role of SwitchA to ensure the normal running of the stack. In addition, the stack supports inter-device link aggregation and link redundancy.

  • Increasing the number of ports

    When a switch lacks the required number of ports to support the increasing number of users, new switches can be added to the original switch to meet this requirement, as shown in Figure 4-27.
    Figure 4-27 Increasing the number of ports

  • Increasing bandwidth

    When higher uplink bandwidth is required, add new stack members and bundle their physical links into a link aggregation group to increase the uplink bandwidth, as shown in Figure 4-28.
    Figure 4-28 Increasing uplink bandwidth

  • Simplifying network topology

    In Figure 4-29, multiple switches are virtualized into a single logical switch. This simplified network does not require MSTP, making network configuration much simpler. Additionally, inter-device link aggregation, speeds up network convergence and improves network reliability.
    Figure 4-29 Simplifying network topology

  • Implementing long-distance stacking

    In the network shown in Figure 4-30, users on each floor connect to the external network through corridor switches that are far from one another. Corridor switches in a building are connected using stack cables to form a stack. In this way, each building has only one virtual access switch, simplifying the network, as well as having multiple links to the core network, improving network robustness and reliability. The administrator only needs to configure stacks, as opposed to configuring corridor switches one by one. This reduces management and maintenance costs.
    Figure 4-30 Implementing long-distance stacking

Stack Connection Modes

Stack member switches must be directly connected without any other switches in between.

Switches can set up a stack through stack card connection and service port connection based on stack port types.

Stack Card Connection

The following scenarios are supported:

  • Member switches are connected using dedicated stack cards ES5D21VST000 and stack cables.
  • Stack cards are integrated into the rear panels of switches, and switches are connected using integrated stack ports and stack cables.
Service Port Connection

In this connection mode, member switches are connected through service ports, without requiring dedicated stack cards. These service ports are configured as stack member ports and bundled into a logical stack port. Figure 4-31 shows physical member ports and logical stack ports in a stack.

Figure 4-31 Service port connections

  • Physical member port

    A physical member port is a service port used to connect stack member switches. Physical member ports forward service packets or stack protocol packets between member switches.

  • Logical stack port

    A logical stack port is exclusively used for stacking and created by bundling physical member ports. Each member switch in a stack supports two stack ports: stack-port n/1 and stack-port n/2, where n is the stack ID of the member switch.

Service port connections are classified into ordinary and dedicated cable connections based on cable types.

  • Ordinary cable connection

    Ordinary stack cables include optical cables, network cables, and high-speed cables. When ordinary stack cables are used to set up a stack, logical stack ports must be manually configured. Otherwise, the stack cannot be set up.

  • Dedicated cable connection

    Figure 4-32 shows the appearance of a dedicated stack cable. Its two ends are the master end with the Master tag and the slave end without any tag. When dedicated stack cables are used to set up a stack, switches can automatically set up a stack after these cables are connected to ports according to connection rules.

    Figure 4-32 Dedicated stack cable

Table 4-124 compares the two stack connection modes.

Table 4-124 Comparisons between two stack connection modes

Item

Stack Card Connection

Service Port Connection

Investment

Stack cards and stack cables need to be purchased separately.

Stack cards do not need to be purchased.

Networking difficulty

A stack is set up after stack cards are installed and stack cables are connected correctly.

When ordinary stack cables are used to set up a stack, service ports need to be configured as stack member ports so that a stack can be set up.

Understanding Stacks

Stacking Member

Roles
In a stack, switches take on one of three roles: master, standby, and slave.

  • Master switch

    The master switch manages the stack. A stack has only one master switch.

  • Standby switch

    The standby switch is the backup of the master switch. A stack has only one standby switch. If the master switch becomes unavailable, the standby switch assumes the master role, and continues to the keep the stack operational.

  • Slave switch

    A slave switch forwards service traffic. A stack may have multiple slave switches. A high number of slave switches can increase forwarding bandwidth in a stack.

    Apart from the master and standby switches, all the other member switches are slave switches. If the standby switch becomes unavailable, a slave switch assumes the standby role.

Single-Switch Stack

A standalone device is a device stack with one stack member that also operates as the master switch. You can connect one standalone device to another to create a device stack containing two stack members, with one of them as the master switch. You can connect standalone devices to an existing device stack to increase the stack membership.

Stack ID

The stack ID (0–8) identifies a stack member and is a slot ID of the member. Each stack member must have a stack ID that is unique in the stack.

Displaying Stack IDs

  • Log in to a stack, and view stack IDs by using the display stack command. The Slot field in the command output displays the stack ID of a stack member.

Assignment
A new switch, a switch that has not joined a stack, or a switch that has not been manually assigned a stack ID ships with a default stack ID of 0. In a stack, the master switch manages stack IDs of stack members. If a new member switch joins the stack and its stack ID conflicts with that of another member, the master switch searches for the lowest available stack ID and assigns it to the new member switch. If stack IDs are not manually configured before stack setup, stack members are assigned random stack IDs. The stack IDs are assigned based on the stack members' startup sequence when a new stack is set up or when stack members change. You are advised to configure stack IDs for stack members before setting up a stack or perform certain operations to ensure that stack members use planned stack IDs after they start.

  • In a new stack, the following stack ID assignment methods are available.

    Method 1

    Method 2

    Method 3
    Configure stack IDs for stack members before setting up a stack.
    1. Place member switches.
    2. Change the stack IDs of stack members to the expected values.
    3. Connect stack members using stack cables.
    Set up a stack and then change stack IDs for stack members.
    1. Place member switches.
    2. Connect stack members using stack cables.
    3. Log in to the stack to change the stack IDs of stack members to the expected values and then restart the stack members.
    Power on stack members in a certain sequence to make them use the expected stack IDs.
    1. Place member switches.
    2. Connect stack members using stack cables.
    3. Power on stack members one by one.

  • In a stack requiring capacity expansion, the following stack ID assignment methods are available.

    Method 1

    Method 2

    Method 3
    Configure stack IDs for stack members before capacity expansion.
    1. Place stack members, log in to the stack, and configure stack IDs for new stack members.
    2. Power off the new stack members and then connect them to the stack using stack cables.
    3. Power on the new stack members.
    Add the new stack members to the stack and then change the stack IDs of the switches.
    1. Place member devices.
    2. Connect new stack members to the stack using stack cables, and power on the new stack members, which then join the stack and obtain auto-negotiated stack IDs.
    3. Log in to the stack to change the stack IDs of the new stack members to the expected values and then restart these switches.
    Connect new stack members using cables and then power on these switches.
    1. Place member devices.
    2. Connect the new stack members to the stack using cables.
    3. Power on the new stack members one by one.

If the stack is an AS of an SVF system, method 2 will affect AS login and logout. Therefore, method 1 and method 3 are recommended.

If the stack IDs of some stack members are not 0, method 3 cannot ensure that the actual stack IDs are the planned IDs. Therefore, method 1 and method 2 are recommended.

After a stack member is removed from a stack, the stack member retains its stack ID. Run the stack slot slot-id renumber new-slot-id command to restore the stack ID to the default value 0. Otherwise, the stack member is assigned the lowest available stack ID after it joins another stack and its stack ID is being used by a stack member in this stack.

Stack Priority

The stack priority determines the role of a stack member in role election. A higher priority value for a stack member increases the probability of it being elected stack master and retaining its stack ID. A higher numerical value represents a higher priority.

The following describes the process of electing the stack master: The switch startup time is compared first and then the stack priority. If the startup time of two stack members is less than 20s, the two members are considered to have the same startup time. In this case, the switch with a higher stack priority is elected as the stack master. Therefore, you are advised to set the highest stack priority for the switch that is expected to be the stack master. For details about how to set up a stack, see Stack Setup.

The stack priority value ranges from 1 to 255 and defaults to 100. You can view the stack member priority value by using the display stack command. To change the priority value for a stack member, use the stack slot slot-id priority priority command. The new priority value takes effect immediately but does not affect the current master switch. The new priority value helps determine which stack member is elected as the new master switch only after the current master switch or the stack resets.

Stack Setup

A stack is set up after the following stages:

  1. Physical connection setup

    Multiple switches are connected in a required topology using the appropriate connection mode to establish a stack network.

  2. Master election

    Member switches exchange stack competition packets and elect the master switch according to master election rules.

  3. Stack ID assignment and standby switch election

    The master switch collects topology information from other member switches and assigns them stack IDs; the standby switch is elected.

  4. Software version and configuration file synchronization

    The master switch synchronizes the topology of the stack to all member switches, and member switches synchronize their system software version and configuration files with the master switch. The stack is set up.

Physical Connection Setup
Member switches can be connected to form a stack using stack cards or service ports. For details about the two stack connection modes, see Stack Connection Modes. Whichever connection mode is used, member switches can be connected in a chain or ring topology, as shown in Figure 4-33. Member switches can be connected in a chain or ring topology, as shown in Figure 4-33. Table 4-125 compares the advantages and disadvantages of the two stack topologies.
Figure 4-33 Stack topologies
Table 4-125 Comparison of stack topologies

Topology

Advantage

Disadvantage

Usage Scenario

Chain topology

Applicable for long-distance stacking because the first and last member switches do not need to be physically connected.

  • Low reliability: If any stack link fails, the stack splits.

  • Low stack link utilization: The stack relies on a single path.

Member switches are far from one another and a ring topology is difficult to deploy.

Ring topology

  • High reliability: If a stack link fails, the topology changes from ring to chain, allowing the stack to function normally.

  • High link bandwidth efficiency: Data can be forwarded along the shortest path.

The first and last member switches need to be physically connected, which makes long-distance stacking difficult.

Member switches are located near one another.
Master Election

Determine the stack connection mode and topology, connect the member switches with physical links, and then power on all member switches. These member switches elect the master switch, which manages the stack. The master switch is elected based on the following rules (the election ends when a winning switch is found):

  1. The switch that starts first becomes the master switch.

    The master election timeout interval is 20 seconds. The startup process may take different lengths of time on different member switches. When stack member switches are powered on or restart, some member switches may not participate in the first master election. When a switch that starts 20s later joins the stack, the master switch is elected again. If the previous master switch fails the election, it restarts and then joins the stack as a non-master switch. If the switch that starts later fails the election, it can join the stack only as a non-master switch. For details, see Adding and Removing a Stack Member. If you want a specific switch to act as the master switch, power on that switch first, and power on the other switches after this switch starts.

    To ensure that master election is completed at a time, you are advised to use switches of the same model to set up a stack. If you want to set up a stack of different switch models, you are advised to connect switches of the same model together.

    For example, three switches A, B, and C set up a stack in a chain topology.
    • If A and B start first and C starts later, C joins the stack only as a non-master switch.
    • If A and C start first and become the master switches, A and C compete to be the master switch based on their startup time when B starts and joins the stack. The switch that fails the election restarts and joins the stack as a non-master switch.
    For example, four switches A, B, C, and D set up a stack in ring topology:
    • If A and B start first and C and D start later, C and D join the stack only as non-master switches.
    • If A and C start first and become the master switches, A and C compete to be the master switch based on their startup time when B and D start and join the stack. The switch that fails the election restarts and joins the stack as a non-master switch.

  2. If multiple switches complete startup at the same time, the switch with the highest stack priority becomes the master switch.

  3. If multiple switches complete startup at the same time and have the same stack priority, the switch with the smallest MAC address becomes the master switch.

Stack ID Assignment and Standby Switch Election
After the master switch is elected, it collects topology information from member switches. Based on the information, the master switch calculates forwarding entries, and sends the calculated information to member switches. The master switch also assigns a stack ID to every member switch. The standby switch is elected to operate as a backup for the master switch. The first switch that completes startup after the master switch becomes the standby switch. If multiple switches complete the startup at the same time, the standby switch is elected according to the following rules:
  1. The switch with the highest stack priority becomes the standby switch.
  2. If the switches have the same stack priority, the one with the smallest MAC address becomes the standby switch.

The election ends when a winning switch is found. After the standby switch is elected, all the other member switches join the stack as slave switches.

Software Version and Configuration File Synchronization
After role election and topology information collection are complete, member switches synchronize their system software and configuration files with the master switch.

  • Automatic software loading: If the standby and slave switches are running a different software version than the master switch, the standby and slave switches download the master switch system software, restart with the new system software, and rejoin the stack. Member switches must have compatible software versions with one another to set up a stack.

  • Configuration file synchronization: The master switch has the startup and running configuration files for the stack, the standby and slave switches download the master switch configuration file and apply it. This mechanism enables member switches to work like a single switch and ensures that other switches continue working normally if the master switch fails. For details about the configuration file, see Configuration File.

Stack Management and Configuration File

IP Address

A stack communicates with other network devices as a single device and has a unique IP address and MAC address.

The IP address is a system-level setting and is not specific to the master switch or to any other stack member. As long as there is IP connectivity, you can still manage the stack through the same IP address even if you remove the master switch or any other stack member from the stack.

The stack IP address is the IP address of the management interface or Layer 3 interface of any stack member. The management interface number in a stack is the same as that on a standalone switch, that is, MEth0/0/1.

After switches with management interfaces form a stack, the management interface on only one stack member takes effect and becomes the master management interface. After the stack starts, the management interface on the master switch is used as the master management interface by default. If this management interface is unavailable, the management interface on another stack member becomes the master management interface. In this situation, the stack IP address remains unchanged. If you connect your PC directly to a non-master management interface, you cannot log in to the stack.

MAC Address
Generally, the stack MAC address is the MAC address of the stack master. When the stack master leaves the stack, the stack MAC address may change. Figure 4-34 shows how the stack MAC address changes by default:
  • If the stack master joins the stack again within 10 minutes, the stack MAC address is still the MAC address of this switch. If the switch becomes a slave switch after joining the stack again, the stack MAC address is the MAC address of the slave switch.
  • If the stack master does not join the stack within 10 minutes, the stack MAC address is the MAC address of the new stack master.
Figure 4-34 How the stack MAC address changes

The stack MAC address switching delay defaults to 10 minutes and can be set using the stack timer mac-address switch-delay delay-time command. After the stack MAC address is changed, traffic will be lost. To reduce the impact on services, run the stack timer mac-address switch-delay 0 command to ensure that the current stack MAC address remains unchanged until the stack restarts. After the stack restarts, the MAC address of the new stack master is used as the stack MAC address.

Interface Numbering Rules

The stack ID determines the interface number. On a standalone switch, interfaces are numbered in the format slot ID/subcard ID/port sequence number, with the slot ID fixed as 0. After the switch joins a stack, its interfaces are numbered in the format stack ID/subcard ID/port sequence number, with an unchanged subcard ID and port sequence number. For example, an interface on a standalone switch is numbered GigabitEthernet0/0/1. After the switch joins a stack and is assigned stack ID 2, the interface number changes to GigabitEthernet2/0/1.

Login
You can log in to a stack using either of the following methods to manage the stack:

  • Log in from a terminal or PC through the console interface of any stack member.

  • Log in through the IP address of the stack master using Telnet, STelnet, web system, or SNMP, provided there is IP connectivity. Using the IP address of the stack, you can log in to the master switch only, instead of the standby and slave switches. After you log in to a stack, the master switch issues the user configurations to all the other stack members. In this way, resources of all stack members are managed consistently.

Configuration File

The master switch has the startup and running configuration files for the stack. The standby switch automatically receives the synchronized running configuration file. Stack members receive synchronized copies when the running configuration file is saved into the startup configuration file. The configuration file of a stack is backed up in the same way as that of a standalone switch. In this way, if the master switch becomes unavailable, the standby switch takes over with the current running configuration.

The root directory for storing files on the master switch is flash. The directories for storing files on the standby and slave switches are stack ID#flash, for example: slot2#flash is the root directory of the flash memory on the stack member with the stack ID 2.

The configuration files record these settings:

  • System-level (global) configuration settings such as IP, STP, VLAN, and SNMP settings that apply to all stack members.

    A new switch joining a stack uses the system-level settings of that stack. Likewise, if a device is moved to a different stack, that device loses its startup configuration file and uses the system-level configuration of the new stack.

  • Stack member interface-specific configuration settings that are specific for each stack member.

    The interface-specific configuration of each stack member is associated with its stack ID. Stack members retain their IDs unless they are manually changed or they are already used by another member in the same stack. If the stack ID changes, the new ID goes into effect after that stack member resets.
    • If an interface-specific configuration does not exist for that new ID, the stack member uses its default interface-specific configuration.
    • If an interface-specific configuration exists for that new ID, the stack member uses the interface-specific configuration associated with that ID.

    If you replace a failed member with an identical model, the replacement device automatically uses the same interface-specific configuration as the failed device, removing the need to reconfigure the interface settings. The replacement device must have the same stack ID as the failed device.

Adding and Removing a Stack Member

Adding a Stack Member
Figure 4-35 illustrates how a new switch is added to a running stack.

  • A switch can be added to a stack whether it is powered on or off. This section only describes how a member switch joins a stack after being powered off. For details on how a member switch joins a stack after being powered on, see Stack Merging.

  • It is not recommended to add a member switch to a stack while the power is on.

Figure 4-35 Member switch joins a stack
A new member switch joins a running stack after the following sequence of events:

  1. The new switch is connected to the stack, is powered on, and starts. It is elected as a slave switch, while the roles of other stack members remain unchanged.

  2. The master switch updates stack topology information, synchronizes the information to the other member switches, and assigns a stack ID to the new stack member (if it has no stack ID configured or the configured stack ID conflicts with that of another stack member).

  3. The new stack member updates its stack ID, synchronizes its configuration file and system software with the master switch, and then runs stably.

To add a new switch to a stack, perform the following operations:

  1. Examine the physical connections between the existing stack members and determine where to connect the new stack member.

    • If the stack has a chain topology, add the new switch to either end of the chain to minimize the impact on running services.
    • If the stack has a ring topology, tear down a physical link to change the ring topology to a chain topology, and add the new switch to either end of the chain. Then connect the switches at both ends to form a ring if required.

  2. Complete the stack configuration.

    • If the member switches are connected through service ports, configure the connected service ports on the new member switch as stack member ports of a logical stack port. If the stack has a chain topology, perform this configuration also at one or both ends of the chain.
    • If the member switches are connected through stack cards, enable the stacking function on the new member switch.
    • To facilitate device management, configure a stack ID for the new member switch. If no stack ID is configured for it, the master switch will assign a stack ID to it.

  3. Power off the new member switch, connect it to the stack through stack cables, and power it on.

  4. Repeat steps 1 through 3 to add more switches to the stack.

  5. Save the configuration.

Removing a Stack Member
Depending on the role of the switch that has left the stack, removing a stack member will affect the stack in one of the following ways:
  • If the master switch leaves the stack, the standby switch becomes the new master switch. It recalculates topology information, synchronizes updated topology information to the other member switches, and selects a new standby switch. The stack enters the running state.
  • If the standby switch leaves the stack, the master switch selects a new standby switch, recalculates topology information, and synchronizes updated topology information to the other member switches. The stack enters the running state.
  • If a slave switch leaves the stack, the master switch recalculates topology information and synchronizes updated topology information to the other member switches. The stack enters the running state.
A member switch leaves a stack after you disconnect its stack cables and remove it from the stack. When removing a member switch, pay attention to the following points:
  • In a ring topology, after removing the switch, use a stack cable to connect the two ports that were connected to this removed member switch to ensure network reliability.
  • In a chain topology, removing an intermediate switch will cause the stack to split. Avoid removing an intermediate switch if it will have a significant impact on services.

Stack Merging

Two running stacks can merge into a single stack. In Figure 4-36, after two stacks merge, both master switches compete to be the master switch of the new stack. After a new master switch is elected, the remaining stack members in the same stack as this new master switch retain their roles and configurations, without affecting services. Switches in the other stack restart and join the new stack as slave switches. The master switch assigns new stack IDs to these switches. Then these switches synchronize their configuration files and system software with the master switch. During this period, services on these switches are interrupted.

The stack merging process is similar to the process for adding a new stack member. For details, see Adding a Member Switch to a Stack. When two stacks merge, one of the two former master switches is elected as the new master switch. The master switch in the stack that enters the running state first becomes the new master switch. If the two stacks enter the running state at the same time, the master switch is elected based the same rules as stack setup.

Figure 4-36 Two stacks merge
Stack merging occurs in either of the following situations:
  • A stack splits because a stack link or member switch fails. After the stack link or member switch recovers, the two stacks merge into one.
  • A switch configured with the stacking function is connected to a running stack through stack cables after being powered on. Connecting a running switch to a running stack is not recommended because this may cause a restart of the stack and affect services.

Stack Split and MAD

Stack Split

If you remove some member switches from a running stack without powering off the switches or if multiple stack cables fail, the stack splits into multiple stacks.

Depending on whether the previous master and standby switches are in the same stack after a stack splits, switch roles are elected in either of the following ways:

  • If the previous master and standby switches are in the same stack after a stack splits: The previous master switch recalculates the stack topology after deleting topology information related to the removed member switches, and synchronizes updated topology information to the other member switches. When removed member switches detect that the timeout timer for stack protocol packets has expired, they restart and begin a new master election.

    In Figure 4-37, the previous master switch (SwitchA) and standby switch (SwitchB) are in the same stack after the stack split. SwitchA deletes topology information related to SwitchD and SwitchE and synchronizes topology information to SwitchB and SwitchC. After SwitchD and SwitchE restart, they set up a new stack.

    Figure 4-37 Previous master and standby switches in the same stack after a split

  • If the previous master and standby switches are in different stacks after a stack splits: The previous master switch selects a new standby switch in its stack, recalculates stack topology information, and synchronizes updated topology information to the other member switches. The previous standby switch becomes the new master switch in its stack, recalculates stack topology information, synchronizes stack topology information to the other member switches, and selects a new standby switch.

    As shown in Figure 4-38, the previous master switch (SwitchA) and standby switch (SwitchB) are in different stacks after the stack split. SwitchA specifies SwitchD as the new standby switch, calculates stack topology information, and synchronizes topology information to SwitchD and SwitchE. In the other stack, SwitchB becomes the master switch, calculates topology information, synchronizes topology information to SwitchC, and specifies SwitchC as the new standby switch.

    Figure 4-38 Previous master and standby switches in different stacks after a split
MAD

All member switches in a stack use the same IP address and MAC address (stack MAC address). After a stack splits, more than one stack may use the same IP address and MAC address. To prevent a network fault caused by this situation, a mechanism is required to check for IP address collision and MAC address collision after a split.

Multi-Active Detection (MAD) is a stack split detection and handling protocol. When a stack splits due to a link failure, MAD provides split detection, multi-active handling, and fault recovery mechanisms to minimize the impact of the stack split on services.

MAD Modes

MAD can be implemented in direct or relay mode. Direct and relay modes cannot be both configured in the same stack.

  • Direct mode

    In direct mode, stack members use MAD links over ordinary network cables. When the stack is running properly, member switches do not send MAD packets. After the stack splits, member switches each send a MAD packet every 1s over a MAD link to check whether more than one master switch exists.

    In direct mode, stack members can be directly connected to either an intermediate device or fully meshed with each other:

    • Directly connected to an intermediate device (Figure 4-39): Each member switch has at least one MAD link connected to the intermediate device.

    • Fully meshed with each other (Figure 4-40): In the full-mesh topology, at least one MAD link exists between any two member switches.

    The use of an intermediate device can shorten the MAD links between member switches. This topology applies to stacks with a long distance between member switches. The full-mesh topology prevents MAD failures caused by intermediate device failures, but full-mesh connections occupy many interfaces on the member switches. Therefore, this topology applies to stacks with only a few member switches.

    • After configuring MAD in direct mode on an interface, do not configure other services on the interface.
    • A maximum of eight direct MAD links can be configured between member switches to ensure reliability.
    Figure 4-39 Directly connected to an intermediate device
    Figure 4-40 Fully meshed with each other

  • Relay mode

    In relay mode, MAD relay detection is configured on an Eth-Trunk interface in the stack, and the MAD detection function is enabled on an agent. Each member switch must have a link to the agent, and these links must be added to the same Eth-Trunk. In contrast to the direct mode, the relay mode does not require additional interfaces because the Eth-Trunk interface can run other services while performing MAD relay detection.

    In relay mode, when the stack is running properly, member switches send MAD packets at an interval of 30s over the MAD links and do not process received MAD packets. After the stack splits, member switches send MAD packets at an interval of 1s over the MAD links to check whether more than one master switch exists.

    You can use an independent relay agent (as in Figure 4-41) or use two stacks as each other's relay agents (as in Figure 4-42).

    • The relay agent is a switch that supports the MAD relay function. Currently, all the S series switches support this function.

    • To implement MAD relay detection by using two stacks as each other's relay agent, configure different domain IDs for the two stacks. Member switches of a stack form a stack domain. A network may have multiple stack domains, with different domain IDs.

    Figure 4-41 Single switch as the MAD relay agent
    Figure 4-42 Two stacks as MAD relay agents of each other

Multi-Active Handling

After a stack splits, the MAD mechanism sets the new stacks to the Detect or Recovery state. The stack in Detect state still works, whereas the stack in Recovery state is disabled.

MAD handles a multi-active situation as follows: When multiple stacks in Detect state are detected by the MAD split detection mechanism, the stacks compete to retain the Detect state. The stacks that fail the competition enter the Recovery state, and all the physical ports except the reserved ports on the member switches in these stacks are shut down, so that the stacks in Recovery state no longer forward service packets.

MAD competition follows similar guidelines to master switch competition.
  1. The stack that completes its startup first enters the Detect state. If the difference in the time taken for multiple stacks to complete their startup is within 20 seconds, the stacks are considered to complete their startup at the same time.
  2. When the stacks complete their startup at the same time, the stack in which the master switch has the highest stack priority enters the Detect state.
  3. When the master switches in the stacks have the same stack priority, the stack with the smallest MAC address enters the Detect state.

MAD Fault Recovery

After the faulty link recovers, the stacks merge into one in either of the following ways:
  • The stack in Recovery state restarts and merges with the stack in Detect state, and the service ports that have been shut down are restored to Up state. The entire stack then recovers.
  • If the stack in Detect state becomes faulty before the faulty link recovers, you can remove this stack from the network and start the stack in Recovery state using a command to direct service traffic to this stack. Then rectify the stack fault and link fault. After the stack recovers, connect it to the network so that it can merge with the other stack.

Master/Standby Switchover

A master/standby switchover occurs in a stack when the master switch restarts or when a user runs the switchover command. Figure 4-43 illustrates how the roles of member switches change after a master/standby switchover.
Figure 4-43 Changes of member switch roles after a master/standby switchover
  1. The previous standby switch becomes the new master switch.
  2. The new master switch selects a standby switch.
  3. The previous master switch restarts and then rejoins the stack as a slave switch.

Stack Upgrade

A stack supports three upgrade methods: intelligent upgrade, traditional upgrade, and smooth upgrade.

Intelligent Upgrade

When a stack is set up or new member switches join a stack, the standby and slave switches or new member switches check whether their software versions are the same as that of the master switch. If not, they download the system software from the master switch, restart with the new system software, and rejoin the stack.

Traditional Upgrade

You can specify the startup system software on the master switch and restart the entire stack to upgrade the software of member switches. This upgrade method causes lengthy service interruptions, and is therefore not suitable for scenarios sensitive to the service interruption time.

Smooth Upgrade

A smooth upgrade can be performed in a stack that has uplinks and downlinks working in redundancy mode. In Figure 4-44, the stack is divided into an active area (with the master switch) and a backup area. Member switches in the two areas are upgraded in turn. When one area is being upgraded, traffic is transmitted through the other area, minimizing the impact on services. Use this upgrade method in scenarios that are sensitive to the service interruption time.

In a network with uplinks and downlinks working in redundancy mode, both upstream traffic and downstream traffic are forwarded through the active and backup areas. When member switches in the backup area are being upgraded, traffic is forwarded through the active area. Likewise, when member switches in the active area are being upgraded, traffic is forwarded through the backup area.

To implement smooth upgrade for a stack, the stack must have uplinks and downlinks working in redundancy mode. To ensure a successful upgrade, you are advised to add at least one link on each member switch to an inter-device Eth-Trunk.

Figure 4-44 Networking for a smooth upgrade
Requirements for a Smooth Upgrade

  • Uplinks and downlinks work in redundancy mode.

  • The system software for the next startup supports the smooth upgrade function.

  • Stack members are running the same system software, with the same software package name, version, and path.

  • Stack members have the same system software specified for next startup, with the same software package name, version, and path.

Rules for Defining Active and Backup Areas
  • The active and backup areas cannot have the same member switch, and both areas must have at least one member switch.
  • The backup area cannot contain the master switch.
  • Member switches in each area must be directly connected.
  • Member switches in the active and backup areas constitute the entire stack.
In the example shown in Figure 4-45, the switch with stack ID 1 is the stack master. If the stack ID range specified for the backup area is 4 to 3, the backup area contains member switches with stack IDs 4, 6, 5, and 3, and the active area contains member switches with stack IDs 1 and 2.
Figure 4-45 Defining active and backup areas

Smooth Upgrade Process

A smooth upgrade goes through three stages:
  1. The master switch issues the smooth upgrade command to the entire stack. Member switches in the backup area restart with the new system software.
  2. Member switches in the backup area set up an independent stack running the new system software and notify member switches in the active area. The master switch in the backup area starts to control the stack, and traffic is transmitted through the backup area. The active area then starts the upgrade.
  3. Member switches in the active area restart with the new system software and join the stack set up in the backup area. The master switch in the backup area displays the upgrade result depending on the stack setup result.

If errors or exceptions occur during a smooth upgrade, or the upgrade times out (the timeout interval is 70 minutes), member switches automatically roll back to the original system version and set up a stack again.

Inter-Device Link Aggregation and Local Preferential Forwarding

Inter-Device Link Aggregation

A stack supports inter-device link aggregation through Eth-Trunks. Physical Ethernet interfaces on different member switches can bundle into an Eth-Trunk, which connects the stack to an upstream or downstream device. If a member link of the Eth-Trunk or a member switch fails, traffic on this link or switch can be distributed to other member links through the stack cables connecting member switches. Inter-device link aggregation implements link and device backup and ensures reliable data traffic transmission.

In Figure 4-46, traffic sent to the core device on a network is evenly distributed to member links of an Eth-Trunk set up between stack member switches. If a member link fails, traffic on this link is distributed to the other link through the stack cables. This link backup mechanism improves network reliability.

Figure 4-46 Implementing link backup through inter-device Eth-Trunk

In Figure 4-47, traffic sent to the core device on a network is evenly distributed to member links of an Eth-Trunk set up between stack member switches. If a member switch fails, traffic toward this switch is distributed to the other switch. This device backup mechanism improves network reliability.

Figure 4-47 Implementing device backup through inter-device Eth-Trunk
Local Preferential Forwarding

Inter-device link aggregation implements reliable data traffic transmission and backup between stack member switches. Because stack cables provide limited bandwidth, inter-device forwarding increases the load on stack cables and reduces forwarding efficiency. To improve the forwarding efficiency and reduce traffic on stack cables, a switch provides the local preferential forwarding function. The function allows traffic reaching the local switch to be preferentially forwarded through a local interface. If the local device has no outbound interface or all outbound interfaces fail, traffic is forwarded through an interface on the other member switch.

In Figure 4-48, SwitchA and SwitchB form a stack, and their uplink and downlink interfaces bundle into Eth-Trunks. If local preferential forwarding is not configured, traffic reaching SwitchA is load balanced between the Eth-Trunk member links. Some traffic is forwarded from SwitchA to SwitchB through the stack cables and is sent out from a physical interface on SwitchB. If local preferential forwarding is configured, traffic reaching SwitchA is forwarded through a local physical interface and does not pass through the stack cables. By default, the local preferential forwarding function is enabled on the device.

Figure 4-48 Local preferential forwarding

Introduction to WLAN

Overview of WLAN

Definition

A wireless local area network (WLAN) is a network that uses high-frequency (2.4 GHz or 5 GHz) signals such as radio waves, lasers, and infrared rays to replace the traditional media used for transmission on a wired LAN. WLAN technology described in this document is implemented based on 802.11 standards.

802.11 was originally a wireless LAN communications standard defined by the Institute of Electrical and Electronics Engineers (IEEE) in 1997. The IEEE then made amendments to the standard, forming the 802.11 family, including 802.11, 802.11a, 802.11b, 802.11e, 802.11g, 802.11i, 802.11n (Wi-Fi 4), 802.11ac (Wi-Fi 5) and 802.11ax (Wi-Fi 6).

Purpose

WLAN technology allows you to easily access a wireless network and move around within the coverage of the wireless network. Wired LANs use wired cables or optical fibers as transmission media, which are expensive and have fixed locations. As further emphasis was placed on network mobility, wired LANs were unable to meet user's requirements. This led to the development of WLAN, which has become the most cost-efficient and convenient network access mode.

Benefits

  • High network mobility: WLANs are easily connected, and are not limited by cable and port positions. This makes WLANs great for scenarios where users are often moving, such as office buildings, airport halls, resorts, hotels, stadiums, and cafes.

    • Flexible network deployment: WLANs provide wireless network coverage in places where cables are difficult to deploy, such as subways and highways. WLANs reduce the number of required cables, offer low-cost, easy deployment, and have high scalability.

Understanding WLAN

Basic WLAN Concepts

  • Station (STA): a terminal that supports 802.11 standards, such as a PC that has a wireless network adapter or a mobile phone that supports WLAN, as shown in Figure 4-49.

    Figure 4-49 Centralized architecture

  • Access controller (AC): a device that controls and manages all of the access points (APs) on a WLAN in the centralized architecture. For example, an AC can connect to an authentication server to authenticate WLAN users, as shown in Figure 4-49.

  • Access point (AP): a device that provides 802.11-compliant wireless access for STAs. APs connect wired networks to wireless networks.

    • Fat AP: an AP that provides wireless access for STAs in the autonomous architecture. A Fat AP provides wireless connection, security, and management functions.
    • Fit AP: an AP that provides wireless access for STAs in the Fit AP architecture. A Fit AP provides only reliable, high-performance wireless connections and depends on an AC to provide other functions, as shown in Figure 4-49.

    • Central access point (AP): a device functions as the AC to provide centralized management and coordination of RUs in the agile distributed architecture, including STA login, configuration delivery, and STA roaming between RUs.

  • Control And Provisioning of Wireless Access Points (CAPWAP): an encapsulation and transmission mechanism. CAPWAP implements communication between APs and ACs, as shown in Figure 4-49.

  • Radio signal: a high-frequency electromagnetic wave that has long-distance transmission capabilities. Radio signals provide transmission media for 802.11-compliant WLANs. Radio signals described in this document are electromagnetic waves in the 2.4 GHz or 5 GHz frequency band.

  • Virtual access point (VAP): a WLAN service entity on an AP. You can create different VAPs on an AP to provide the wireless access service for different user groups.

  • Service set identifier (SSID): a unique identifier that identifies a wireless network. When you search for available wireless networks on your laptop, SSIDs are displayed to identify the available wireless networks.

    SSIDs are classified into two types:
    • Basic service set identifier (BSSID): the link-layer MAC address of a VAP on an AP. Figure 4-50 shows the relationship between VAP and BSSID.
      Figure 4-50 Relationship between VAP and BSSID
    • Extended service set identifier (ESSID): a chosen identifier for one or a group of wireless networks. For example, in Figure 4-50, SSID guest identifies one wireless network, and SSID internal identifies another wireless network. A STA scans all wireless networks and selects a wireless network based on the SSID. In general terms, an SSID refers to an ESSID.

      Multiple APs can use one ESSID to provide roaming service for users; however, their BSSIDs must be unique because the MAC address of each AP is unique.

  • Basic service set (BSS): an area covered by an AP. STAs in a BSS can communicate with each other.

  • Extend service set (ESS): a group of BSSs that share the same SSID.

    Figure 4-51 shows the relationship between SSID, BSSID, BSS, and ESS.

    Figure 4-51 Relationship between SSID, BSSID, BSS, and ESS

WLAN Architecture

A WLAN has a wired side and a wireless side. On the wired side, APs connect to the Internet using Ethernet. On the wireless side, a STA communicates with an AP using 802.11 standards and the autonomous WLAN architecture is used.

Autonomous Architecture

In autonomous architecture, Fat APs implement wireless access without requiring an AC, as shown in Figure 4-52.

Figure 4-52 WLAN autonomous architecture

The autonomous architecture was widely used in early stage of WLAN construction. Fat APs have powerful functions and can work independently of ACs; however, Fat APs have complex structure and are difficult to manage in a centralized manner. When an enterprise has a large number of APs deployed, AP configuration and software upgrade bring large workload and high costs. Therefore, the autonomous architecture is used less and less.

In autonomous architecture, STAs associate with a Fat AP to access a WLAN. For details, see STA Access.

AP Onboarding Process

In centralized architecture, Fit APs need to go online before being managed and controlled by an AC. The AP onboarding process includes the following steps:
  1. IP Address Allocation
  2. CAPWAP Tunnel Establishment
  3. AP Access Control
  4. AP Software Upgrade
  5. CAPWAP Tunnel Maintenance
  6. AC Configuration Delivery

An AP can go online in IPv4 or IPv6 mode, and the IPv4 mode takes precedence. CAPWAP tunnels support IPv4/IPv6 dual-stack, allowing an AC to manage APs in IPv4 and IPv6 modes. IPv4 and IPv6 packets can be simultaneously encapsulated in CAPWAP tunnels for transmission.

The process in which a central AP goes online on an AC is similar to that of a common AP.

IP Address Allocation
An AP can obtain an IP address in either of the following modes:
  • Static mode: A user logs in to the AP and configures its IP address.
  • DHCP mode: The AP serves as a DHCP client and requests an IP address from a DHCP server.
  • SLAAC mode: The AP obtains an IP address in stateless address autoconfiguration (SLAAC) mode, which supports only IPv6.
CAPWAP Tunnel Establishment
The AC manages and controls APs in a centralized manner through CAPWAP tunnels. CAPWAP tunnels provide the following functions:
  • Maintains the running status of the AC and APs.
  • Allows the AC to manage APs and deliver configurations to APs.
  • Transmits service data through CAPWAP tunnels to the AC for centralized forwarding.
Figure 4-53 shows the process of establishing a CAPWAP tunnel.
Figure 4-53 CAPWAP tunnel establishment process

  1. Discovery phase: An AP sends a Discovery Request packet to find an available AC. The AC determines whether to allow the AP. This process is similar to that in AP access and control phase. For details, see Figure 4-54. The AC does not respond to Discovery Request packets sent by the AP that is not allowed.

    An AP can discover an AC in static or dynamic mode.

    • Static mode

      An AC IP address list is preconfigured on the AP. When an AP goes online, the AP unicasts a Discovery Request packet to each AC whose IP address is specified in the preconfigured AC IP address list. After receiving the Discovery Request packet, the ACs send Discovery Response packets to the AP. The AP then selects an AC to establish a CAPWAP tunnel according to the received Discovery Response packets.

    • Dynamic mode

      An AP can dynamically discover an AC in DHCP, DNS, or broadcast mode. Details on each of the modes are as follows:

      • DHCP mode: An AP obtains the AC IP address through DHCP (The DHCP server is configured to carry Option 43 in the IPv4 DHCP Offer packet and carry Option 52 in the IPv6 DHCP Offer packet, and the options contain the AC IP address list.) After obtaining the AC IP address, the AP unicasts a Discovery Request packet to the AC. The AC then sends a Discovery Response packet to the AP.

      • DNS mode: An AP obtains the AC domain name and DNS server IP address through the DHCP (The DHCP server is configured to carry Option 15 in the IPv4 DHCP Offer packet and carry Option 24 in the IPv6 DHCP Offer packet, and the options contain an AC domain name.) and sends a request to the DNS server to obtain the IP address corresponding to the AC domain name. After obtaining the AC's IP address, the AP unicasts a Discovery Request packet to the AC. The AC then sends a Discovery Response packet to the AP.

        After receiving the DHCP Offer packet, the AP obtains the AC domain name carried in Option 15 or Option 24. The AP then automatically adds the prefix huawei-wlan-controller to the obtained domain name and sends it to the DNS server to obtain the IP address corresponding to the AC domain name. For example, after obtaining the AC domain name ac.test.com configured on the DHCP server, the AP adds the prefix huawei-wlan-controller to ac.test.com and sends huawei-wlan-controller.ac.test.com to the DNS server for resolution. The IP address corresponding to huawei-wlan-controller.ac.test.com must be configured on the DNS server.

      • Broadcast mode: An AP broadcasts a Discovery Request packet to automatically discover an AC in the same network segment and then selects an AC to establish a CAPWAP tunnel according to the Discovery Response packets received from available ACs. The broadcast mode is used when the following conditions are met:
        • If the AP fails to obtain the IP address of an AC, it sends a broadcast packet. If no AC responds to the broadcast packet for two times, a failure to discover an AC is determined. If the AC fails, the AP repeats the preceding process after waiting for a period of time.
        • After obtaining the IP address of an AC, the AP sends unicast packets to the AC. If the AC does not respond to the unicast packets for 3 times, the AP sends a broadcast packet. If no AC responds to the broadcast packet, the AP repeats the process of sending unicast and broadcast packets. If there is still no response, a failure to discover an AC is determined. If the AP fails to discover an AC, it repeats the preceding process after waiting for a period of time.

  2. The AP establishes CAPWAP tunnels with an AC.

    CAPWAP tunnels include data tunnels and control tunnels.
    • Data tunnel: transmits service data packets from APs to the AC for centralized forwarding. Datagram Transport Layer Security (DTLS) encryption can be enabled over data tunnels to ensure security of CAPWAP data packets. Subsequently, CAPWAP data packets will be encrypted and decrypted using DTLS.
    • Control tunnel: transmits control packets between the AC and APs. Datagram Transport Layer Security (DTLS) encryption can be enabled over control tunnels to ensure security of CAPWAP control packets. Subsequently, CAPWAP control packets will be encrypted and decrypted using DTLS.
AP Access Control

The AP sends a Join Request packet to an AC. The AC then determines whether to allow the AP access and sends a Join Response packet to the AP. The Join Response packet carries the AP software upgrade mode and AP version information configured on the AC.

Figure 4-54 shows the AP access control flowchart.

Figure 4-54 AP access control flowchart

AP Software Upgrade

The AP determines whether its system software version is the same as that specified on the AC according to parameters in the received Join Response packet. If the two versions are different, the AP updates its software version in AC, FTP, or SFTP mode.

After the software version is updated, the AP restarts and repeats steps 1 to 3.

CAPWAP Tunnel Maintenance

The AP and AC exchange Keepalive packets (through the UDP port 5247) to detect the data tunnel connectivity.

The AP and AC exchange Echo packets (through the UDP port 5246) to detect the control tunnel connectivity.

AC Configuration Delivery

The AC sends a Configuration Update Request packet to an AP, which then replies with a Configuration Update Response packet. The AC then delivers service configuration to the AP.

STA Access

STAs can access wireless networks after APs are logged in and CAPWAP tunnels are established. STA access involves the following steps:

  • Scanning
  • Link authentication
  • Association

A STA can access wireless networks in either IPv4 or IPv6 mode, with the IPv4 mode taking precedence.

STA access depends on the number of access users supported by the AC and a single AP.
  • If the number of STAs associated with an AP reaches the maximum limit of the AP but not the maximum limit of the AC, a new STA cannot connect to the current AP. However, the STA can associate with another AP on the network.
  • If the number of STAs associated with an AP reaches the maximum limit of the AC, a new STA cannot access the WLAN even though the maximum limit of the AP is not reached.
  • If the number of STAs associated with an AP does not reach the maximum limit of the AP or AC, a new STA can access the WLAN.
Scanning

A STA can actively or passively scan wireless networks.

Active scanning

In active scanning, a STA periodically searches for nearby wireless networks. The STA can send two types of Probe Request frames: probes containing an SSID and probes that do not contain an SSID.

  • Probes containing an SSID: The STA sends a Probe Request frame containing an SSID in each channel to search for the AP with the same SSID. Only the AP with the same SSID will respond to the STA. For example, in Figure 4-55, the STA sends a Probe Request frame containing the SSID wlan to search for the AP with the SSID wlan.

    This method applies to the scenario where a STA actively scans wireless networks to access a specified wireless network.

    Figure 4-55 Active scanning by sending a Probe Request frame containing an SSID

  • Probes that do not contain an SSID: The STA periodically broadcasts a Probe Request frame that does not contain an SSID in the supported channels, as shown in Figure 4-56. The APs return Probe Response frames to notify the STA of the wireless services they can provide.

    This method applies to the scenario where a STA actively scans wireless networks to determine whether wireless services are available.

    Figure 4-56 Active scanning by sending a Probe Request frame containing no SSID

Passive scanning

When passive scanning is enabled, a STA listens on the Beacon frames that an AP periodically sends in each channel to obtain AP information, as shown in Figure 4-57. A Beacon frame contains information including the SSID and supported rate.

To converse power, enable the STA to passively scan wireless networks. In most cases, VoIP terminals passively scan wireless networks.

Figure 4-57 Passive scanning process

Link Authentication
To ensure wireless link security, an AP needs to authenticate STAs that attempt to access the AP. IEEE 802.11 defines two authentication modes: open system authentication and shared key authentication.
  • Open system authentication requires no authentication. STAs that attempt to access the AP are successfully authenticated. An illustration of the open system authentication procedure is shown in Figure 4-58.
    Figure 4-58 Open system authentication

  • Shared key authentication requires that the STA and AP have the same shared key preconfigured. The AP checks whether the STA has the same shared key to determine whether the STA can be authenticated. If the STA has the same shared key as the AP, the STA is authenticated. Otherwise, STA authentication fails.
    Figure 4-59 Shared key authentication

    As shown in Figure 4-59, the shared key authentication process consists of the following steps:
    1. The STA sends an Authentication Request packet to the AP.
    2. The AP generates a challenge and sends it to the STA.
    3. The STA uses the preconfigured key to encrypt the challenge and sends it to the AP.
    4. The AP uses the preconfigured key to decrypt the encrypted challenge and compares the decrypted challenge with the challenge sent to the STA. If the two challenges are the same, the STA is authenticated. Otherwise, STA authentication fails.
Association

Client association is also known as link negotiation. After link authentication is complete, a STA initiates link negotiation using Association packets, as shown in Figure 4-60 and Figure 4-61 in the agile distributed architecture.

Figure 4-60 STA association in the agile distributed architecture (intra-central AP roaming)
Figure 4-61 STA association in the agile distributed architecture (non-intra-central AP roaming)
  • STA association in the agile distributed architecture consists of the following steps:
    1. The STA sends an Association Request packet to the RU. The Association Request packet carries the STA's parameters and the parameters that the STA selects according to the service configuration, including the transmission rate, channel, QoS capabilities, access authentication algorithm, and encryption algorithm.
    2. The RU receives the Association Request packet, encapsulates the packet into a CAPWAP packet, and sends the CAPWAP packet to the central AP.
    3. The central AP checks whether a local user entry matches.
      • If so, intra-central AP roaming occurs. The central AP performs local roaming and sends an Association Response packet to the RU.
      • If no, roaming is not intra-central AP roaming. The central AP forwards the Association Request packet to the AC. The AC then determines whether access authentication is required and sends an Association Response packet to the central AP.
After association, the STA determines whether it needs to be authenticated according to the received Association Response packet:
  • If the STA does not need to be authenticated, the STA can access the wireless network.
  • If the STA needs to be authenticated, the STA initiates user access authentication. After successful authentication, the STA can access the wireless network.

Data Forwarding Mode

Data on a WLAN involves control packets (management packets) and data packets. Control packets are forwarded through CAPWAP control tunnels. Data packets are forwarded in tunnel forwarding (centralized forwarding), direct forwarding (local forwarding), or soft GRE forwarding mode.

Tunnel Forwarding
In tunnel forwarding mode, APs encapsulate user data packets over a CAPWAP data tunnel and send them to an AC. The AC then forwards these packets to an upper-layer network, as shown in Figure 4-62.
Figure 4-62 Tunnel forwarding

Direct Forwarding
In direct forwarding mode, an AP directly forwards user data packets to an upper-layer network without encapsulating them over a CAPWAP tunnel, as shown in Figure 4-63.
Figure 4-63 Direct forwarding

Centralized Authentication in Direct Forwarding Mode

If direct forwarding is used, service data does not need to be forwarded by an AC. When user access authentication (for example, 802.1X authentication) is required on a wireless user access network and the access control point is deployed on an AC, user authentication packets cannot be managed by the AC in a centralized manner. This makes controlling users in a uniform manner difficult. In direct forwarding mode, an AP forwards user authentication packets to the AC over the CAPWAP tunnel, as shown in Figure 4-64.

Figure 4-64 Centralized authentication in direct forwarding mode

Soft GRE Forwarding

When carriers need to deploy a WLAN using the open security policy on the live network, they require that the legacy BRAS devices implement authentication and accounting for wireless users. The soft GRE forwarding mode allows a BRAS device to perform Portal or MAC address authentication, achieving unified authentication and accounting for wired and wireless users. In such scenarios, the AC is usually connected to the network in bypass mode and is only responsible for AP management and wireless service configuration. The AP forwards data packets from wireless users to BRAS devices over soft GRE tunnels. The BRAS devices then forwards the packets to upstream network devices.

Figure 4-65 shows how data packets are forwarded in soft GRE forwarding mode.

Figure 4-65 Soft GRE forwarding
Comparison of Tunnel Forwarding, Direct Forwarding, and Soft GRE Forwarding
Table 4-126 Comparison of tunnel forwarding, direct forwarding, and soft GRE forwarding

Data Forwarding Mode

Advantage

Disadvantage

Tunnel forwarding

An AC forwards data packets in a centralized manner, ensuring security and facilitating centralized management and control.

Service data must be forwarded by an AC, reducing packet forwarding efficiency and burdening the AC.

Direct forwarding

Service data packets do not need to be forwarded by an AC, improving packet forwarding efficiency and reducing the burden on the AC.

Service data packets cannot be centrally managed or controlled.

Soft GRE forwarding

In wired and wireless convergence, and centralized user authentication scenarios, data packets are forwarded to a convergence gateway through a soft GRE tunnel, without passing through an AC. This forwarding mode improves packet forwarding efficiency and reducing the burden on the AC.

Service data must be forwarded by a convergence gateway, burdening the gateway. The packet forwarding efficiency is lower than that in direct forwarding mode.
Direct Forwarding for Specified Packets in Tunnel Forwarding Mode

Users require that specified services be directly forwarded even in tunnel forwarding mode, without switching the SSID or interrupting the current service forwarding. As shown in Figure 4-66, to enable a STA connecting to an SSID in tunnel forwarding mode to use local network resources, configure ACL rules based on 5-tuple information about packets sent to the local network. In this way, packets that match the ACL rules are directly forwarded by the APs.

Figure 4-66 Direct forwarding for specified packets in tunnel forwarding mode

If an AP directly forwards packets from a STA using the STA's source IP address, the AP cannot directly communicate with the local network because the STA gateway is not on the local network. To solve this problem, the AP translates the IP address and port number of the STA into the IP address and port number of the AP, so that the STA can communicate with the local network.

WLAN Application Scenarios

WLAN Networking Application on Medium- and Large-sized Campus Networks

Medium and large campus networks are deployed in headquarters of large and medium enterprises, branches of large enterprises, colleges and universities, and airports. On a large campus network, a large number of APs are often deployed.

Most of these campus networks use the centralized WLAN architecture (AC+Fit AP) to facilitate network maintenance and enhance security. Based on the AC deployment mode, two AC solutions are available: centralized AC solution and distributed AC solution.

Centralized AC Solution

The centralized AC solution deploys independent ACs to manage APs on the network. An AC can be deployed in chain mode (between an AP and an aggregation or a core switch) or in off-path mode (the AC is connected only to an aggregation or a core switch).

  • The chain mode applies to new WLANs.
  • The off-path mode applies to the scenario where the existing network topology remains unchanged and only ACs are deployed to meet WLAN requirements.

Figure 4-67 shows the centralized AC solution on a medium or large campus network. In Figure 4-67, the off-path mode configured.

Figure 4-67 Centralized AC solution on a medium or large campus network
Distributed AC Solution

The distributed AC solution deploys multiple ACs in different areas to manage APs. This mode integrates AC functions on an aggregation switch to manage all the APs connected to the aggregation switch, without using an independent AC.

Figure 4-68 shows the distributed AC solution on a medium or large campus network.

Figure 4-68 Distributed AC solution on a medium or large campus network

WLAN Networking Application on Small Campus Networks

Small campus networks are deployed in small- and medium-scale enterprises. Its WLAN deployment scale is smaller than that on a large-scale campus network but is greater than that on a SOHO network.

To reduce costs, a small campus network does not use dedicated NMS devices or authentication servers, resulting in low reliability.

A small campus network often uses the centralized AC solution. You can use a standalone AC or a device integrating AC functions to implement the centralized AC solution. In Figure 4-69, the independent AC implements the centralized AC solution.

Figure 4-69 Small-scale campus network WLAN solution

WLAN Networking Application in Enterprise Branches

The enterprise branch WLAN networking can be used when an enterprise deploys WLANs in the headquarters and branches and the headquarters needs to manage WLANs in branches.

Large-scale and small-scale branch WLAN networking modes are defined based on the AC deployment mode, independent of the branch network size. In large-scale branch WLAN networking mode, the AC manages APs and wireless networks only in the branch, whereas in small-scale branch networking mode, the AC manages APs and wireless networks at the headquarters. Figure 4-70 and Figure 4-71 show the large-scale and small-scale branch WLAN networking modes, respectively.

Figure 4-70 Large-scale branch WLAN networking
Figure 4-71 Small-scale branch WLAN networking

Typical Application of an Agile Distributed WLAN

In scenarios with a high concentration of rooms, such as hotels, school dormitories, and hospitals, walls or other indoor objects may cause severe signal attenuation. Common indoor settled APs or distributed APs cannot meet the requirement of high-performance wireless coverage at low costs; therefore, Huawei develops the agile distributed WLAN architecture.

An agile distributed WLAN is composed of the AC, central AP, and RU. The RU receives and sends wireless packets. The central AP connects to the RUs through network cables. Compared with feeder cables used by common APs to connect to antennas, the network cables provide longer deployment distance, allowing RUs to be deployed further from the central AP.

The central AP directly connects to RUs and provides PoE power for RUs, as shown in Figure Figure 4-72. You can also connect the central AP to RUs through a PoE switch to increase the number of the connected RUs. A Layer 2 reachable tree network must be deployed between the RUs and central AP.

Figure 4-72 Agile distributed WLAN

In addition to RUs, the central AP can connect to wired terminals in the downlink direction. However, it cannot connect to common APs or other central APs, as shown in Figure 4-73. When the central AP connects to wired terminals, the wired terminals do not support 802.1X authentication because the central AP cannot transparently transmit EAP packets. Therefore, authentication packets of wired terminals cannot reach the uplink authentication point through the central AP.

Figure 4-73 Types of devices that can be connected to the central AP in the downstream direction

Application of Uninterrupted AP Operation After CAPWAP Tunnel Disconnection

In Figure 4-74, to reduce management and maintenance costs, some small- and medium-sized enterprises deploy the AC at the headquarters to manage APs and STAs in branches. In direct forwarding mode, service holding upon CAPWAP tunnel disconnection is configured. After the CAPWAP tunnels between the AP and AC are disconnected, online branch users can access local network resources (such as the local servers), and new branch users can still access the WLAN to obtain network resources.

Figure 4-74 Uninterrupted AP operation after CAPWAP tunnel disconnection

Precautions for Device Addition

Cloud Managed Device Models (NETCONF-managed)

You can use the Info-Finder tool to check whether a device can be managed by the controller through NETCONF (that is, cloud managed device).

Feature Requirements

  • The maximum number of devices that can be managed by iMaster NCE-Campus through NETCONF varies according to the deployment mode:
    • In a single-node system: 5000 devices
    • In a minimum cluster: 30,000 devices
    • In a 17-node distributed cluster: 250,000 devices
  • If you are on the site, you can use the barcode scanning function of the CloudCampus APP installed on your Android phone to record the ESNs of cloud managed devices (including cloud firewalls, switches, ARs, and APs) into iMaster NCE-Campus. In addition, the deployment function provided by the CloudCampus APP allows you to bring cloud APs online.
  • On the login page of iMaster NCE-Campus, you can scan the QR code to download the CloudCampus APP.
  • When you use iMaster NCE-Campus V300R020C00 or a later version for fresh deployment of APs running V200R007C10 and V200R008C00 on the network, you need to upgrade the APs to V200R019C00 or a later version after the APs are managed by iMaster NCE-Campus.
  • NETCONF is not recommended for iMaster NCE-Campus to manage switches directly connected to servers installed with iMaster NCE-Campus.
  • A device can be added to iMaster NCE-Campus either through SNMP or NETCONF.
  • The system time of SNMP-managed devices must be consistent with that of iMaster NCE-Campus. Otherwise, iMaster NCE-Campus cannot collect statistics about these devices.
    • For SNMP-managed Huawei network devices, only the following O&M functions are supported on iMaster NCE-Campus: device performance monitoring, device alarm reporting, device configuration file management, device upgrade, CLI-based service configuration, WLAN resource monitoring, and region monitoring, agile report, SLA management.
    • For SNMP-managed third-party devices, only the following functions are supported on iMaster NCE-Campus: device alarm reporting and basic information monitoring.

License Requirements

To obtain the iMaster NCE-Campus License Usage Guide:

Table 4-127 Deduction rules of device management licenses in different scenarios

License Item

Deduction Trigger Condition

Measurement Unit

Subscription License in the Huawei Public Cloud Scenario

Subscription License in the MSP-owned Cloud Scenario

Perpetual License + SnS in the On-Premises Scenario

Start Version

AR management on the LAN

Licenses for AR600, AR6100, AR6200, and AR6300 series devices when IPsec is enabled under a tenant

Per device

Deduction is supported.

Deduction is supported.

Deduction is supported.

V300R019C10

AR management in the LAN-WAN convergence scenario

Licenses for AR600, AR6100, AR6200, and AR6300 series devices when the GRE tunnel mode for SD-WAN scenario is configured

Per device

Deduction is supported.

Deduction is supported.

Deduction is supported.

V300R019C10

Third-party device management
  1. Third-party device management through SNMP
  2. CE and NE management

Per device

Deduction is not supported.

Deduction is not supported.

Deduction is supported.

V300R019C10

POL device management

ONU management through SNMP

Per ONU

Deduction is not supported.

Deduction is supported (expected to be supported in V3R20C00 patches)

Deduction is supported.

V300R020C00

Overview of Device Addition Tasks

Table 4-128 describes the tasks for adding devices based on device types. Table 4-129 describes the tasks for configuring the controller to automatically discover and add devices using different protocols.

Table 4-128 Adding devices by device type

Scenario

Protocol

Description

Task

Adding a cloud managed device

NETCONF

The following methods are supported for adding devices to iMaster NCE-Campus:

  • Manual addition: applies to the scenario where a small number of devices need to be added to the same site.
  • Batch import: applies to the scenario where a large number of devices need to be added. A maximum of 1000 devices can be imported at a time.
  • Automatic scanning: applies to the scenario where the controller automatically discovers and manages devices in batches free of device ESNs.

Adding NETCONF-managed Devices

Adding a traditional device

SNMP

The following methods are supported for adding devices to iMaster NCE-Campus:

  • Manual addition: applies to the scenario where a small number of devices need to be added to the same site.
  • Batch import: applies to the scenario where a large number of devices need to be added. A maximum of 500 devices can be imported at a time.
  • Automatic scanning: The system automatically scans traditional devices in every IP network segment at a specified interval.

Adding SNMP-managed Network Devices

Adding a PON device

SNMP

PON devices can be added to iMaster NCE-Campus for management.

Adding SNMP-Managed PON Devices

Adding a stack

NETCONF

Administrators can set up and configure a stack after the stack member devices are added to iMaster NCE-Campus based on their ESNs.

Creating a Stack

Creating a WAC group

NETCONF

A WAC group can be created on iMaster NCE-Campus.

Creating a WAC Group

Suggestions on AP grouping

-

There are specifications and group restrictions for adding APs to a site.

AP Grouping Recommendations
Table 4-129 Automatic device discovery and addition through different protocols

Scenario

Description

Task

Using SNMP to discover devices

This mode applies to the devices with which the controller proactively set up connections.

Discovering and Managing Devices Through SNMP

Using NETCONF to discover devices

This mode applies to the devices which proactively set up connections with the controller.

Discovering and Managing Devices Through NETCONF

Adding Devices by Device Type

Adding NETCONF-managed Devices

Feature Requirements
  • For APs and LSWs, the value of Device Name is delivered to the devices as the hostname (sysname). To prevent hostname delivery failures due to restrictions on the devices, the value of Device Name can contain only uppercase letters, lowercase letters, digits, spaces, and the following special characters !"#$%&'()*+,-./:;<=>@[\]^_`{|}~
  • To add more than 25 APs to a site, read AP Grouping Recommendations.
  • If you have selected a site when adding devices, you can manually modify the site for successfully added devices. On the device management page, select a device and click Switch Site to deploy the device at another site or remove the device from the current site. Note that a Fit AP will become a cloud AP after it is removed from a WAC site.
  • When there is no user currently online on a cloud AP or central AP that goes offline unexpectedly and remains offline for 24 hours, iMaster NCE-Campus restarts and restores the AP.
  • When the status of a device changes (for example, the device is deleted and then added again), wait for about 60 seconds and then trigger the device to perform authentication on access users. Otherwise, user authentication may fail.

  • Firewalls, switches, and APs can work in either the traditional mode or cloud management mode. These devices can be managed by iMaster NCE-Campus only after they are switched to the cloud management mode.

  • ARs can work only in traditional mode and are functional as long as they support management by iMaster NCE-Campus.

Prerequisites
  1. The device and iMaster NCE-Campus have reachable routes to each other. NETCONF has been configured.
  2. If a switch running V200R008C00 or an earlier version needs to be added to iMaster NCE-Campus through NETCONF, ensure that the port for legacy device certificates on the management plane of iMaster NCE-Campus. For details about how to enable the port for legacy device certificates, see (Optional) Enabling the Port for Legacy Device Certificates.
  1. Log in to the iMaster NCE-Campus management plane.
  2. Choose Product > Software Management > Deploy Product Software from the main menu, choose More > Modify Configurations, set DEVICE_OLD_CERT_ENABLE(enable device old cert or not) to true, and click OK.

  3. Click in the upper right corner to check whether the configuration is successful.

  4. Wait for about 10 minutes, choose Product > System Monitoring from the main menu, click the Service tab, and search for CampusBaseService. Check whether CampusBaseService is successfully restarted. Perform subsequent configurations after you have confirmed that the service is running properly.
Procedure
  1. Choose Design > Site Agile Deployment > Device Management from the main menu.
  2. Click Add Device on the Device page.
  3. Two methods for adding devices are available: Add and Import in batches.

    • Add cloud-managed devices manually.
      1. Select a desired site. You may also choose not to add devices to a site.
      2. Choose Add Device > Add.
      3. Select NETCONF protocol.
      4. Add devices by device model. Set Type, Model, Quantity, and Role. Then click OK.

      5. Enter device ESNs.
        1. Devices added by Device Model can go online after the device ESNs are added to iMaster NCE-Campus.
        2. If a device cannot be added because its ESN is occupied, contact the system administrator or MSP administrator to delete the device ESN.
      6. Click OK.

        For an online device, you can click the device name to view the device status. In addition, you can also lock the device's configuration, reboot the device, and log in to the device CLI.

        • The web UI display varies according to devices.
        • You can log in to the web system only of firewalls, ARs, WACs, and switches with native WACs through iMaster NCE-Campus. A maximum of 20 device's web systems can be opened together.
        • If a user opens the web system of a device through the Device Configuration function and then opens the web system of another device, the session information of the first device will be overwritten and the user will be logged out from the web system of the first device when the user opens the web system of the second device. This is because different devices use the same IP address to forward sessions using SSH. If you need to open the web system of two devices at the same time, open a non-trace page or use another browser to log in to iMaster NCE-Campus, and then log in to the web system of the devices.
    • Add cloud managed devices in batches.
      1. Select a desired site. You may also choose not to add devices to a site.
      2. Choose Add Device > Import in batches.
      3. Select NETCONF protocol.

      Download and fill in the device configuration template. After all settings are complete, upload the template. Select the devices to which the template will be uploaded in the Import Result window and click OK.

    • Configure the controller to automatically discover and manage devices in batches. For details, see Discovering and Managing Devices Through NETCONF.

  4. After the device is added, you can view the device information in the device list. Click next to the Operation column on the right of the device list to select the fields to be displayed in the device list.

    • Public IP address is the IP address used by a device to establish a NETCONF channel with iMaster NCE-Campus.
    • Devices that do not directly establish NETCONF channels with iMaster NCE-Campus, such as Fit APs and distributed APs, do not have public IP addresses.
    • Management IP address is used by users to manage a device through iMaster NCE-Campus. You can configure management IP addresses only for switches and APs. For details, see Configuring a Management VLAN.
    • In a stack, the standby and slave member switches do not have management IP addresses.

Follow-up Procedure

After devices are installed, cabled, and powered on, they need to register with and go online on iMaster NCE-Campus so that they can be managed by iMaster NCE-Campus. Then iMaster NCE-Campus can deploy services and deliver configurations to the devices, as well as monitoring them. It takes two steps for a device to register with and go online on iMaster NCE-Campus:

  1. The device connects to the Internet.

  2. The device switches to the cloud management mode, obtains the IP address or URL and port number of iMaster NCE-Campus, and registers with iMaster NCE-Campus.

Related Tasks
  1. Restart a device and restore the device configuration.

    After selecting an added device, you can use the Factory Reset, Reset to Deployment State (only for AR routers), and Reboot functions to restore default settings or restart the device.

    This operation has high risks and cannot be rolled back. Exercise caution when you perform this operation.

  2. Move a device to another site.

    Select a device and click Change Site to move the device to the selected site or remove the device from the current site. You can filter sites by organization.

    1. When moving a device between sites, you can decide whether to delete the device-specific configurations of the source site from the device, including subnets and interfaces.
    2. If an AP works in another mode after being moved between sites of different types, the controller will forcibly delete all original configurations from the AP and delivers service configurations of the destination site to it.
    3. Performing this operation will impact existing services and may take several minutes. Exercise caution when you perform this operation.

  3. View sites in an organization.

    Select the target organization from the Organization drop-down list on the Device page. Among the displayed sites, select the desired one and view devices at this site. You can also view sites not in any organization and devices at these sites.

Adding SNMP-Managed Devices

Configuring SNMP on Devices

This section describes how to set protocol parameters on a device before the device is connected to iMaster NCE-Campus. MA5600T V800R017C10 is used as an example. For other device types, see the corresponding device configuration manuals.

Configuring SNMP

Configure SNMP on devices so that the devices can be added to iMaster NCE-Campus for management..

  • SNMPv3 is recommended because it is more secure than SNMPv1 and SNMPv2c.
  • If SNMPv2c and SNMPv1 are configured, the read and write community names must be different. Otherwise, the write permission overrides the read permission, and the device cannot be discovered.
  • SNMP v3
    huawei(config)#snmp-agent sys-info version v3
    huawei(config)#snmp-agent mib-view View_ALL include iso   //View_ALL indicates the name of the MIB view. To ensure that iMaster NCE-Campus can properly manage devices (for example, discover device links using LLDP), the MIB view must contain the iso node.
     huawei(config)#snmp-agent group v3 snmpv3group privacy write-view View_ALL notify-view View_ALL   //snmpv3group indicates the configured user group. Set the name of the write view and notification view to View_ALL. By default, the write view has the read permission and you do not need to set read-view. The notification view is used to restrict the MIB node that sends alarms to iMaster NCE-Campus.
    huawei(config)#snmp-agent usm-user v3 snmpv3user group snmpv3group   //snmpv3user indicates the configured user name, which is the same as the iMaster NCE-Campus security name. The security level of a user cannot be lower than that of the user group to which the user belongs. Otherwise, the communication fails. For example, if the security level of user group snmpv3group is set to privacy, the security level of user snmpv3user must be authentication and encryption.
    huawei(config)#snmp-agent usm-user v3 snmpv3user authentication-mode sha   //Set the encryption protocol and password of the user. The encryption protocol and password must be the same as those on iMaster NCE-Campus. You need to enter the encryption protocol and password twice.
    huawei(config)#snmp-agent usm-user v3 snmpv3user privacy-mode aes128  // Set the encryption protocol and password of the user, which must be the same as those on iMaster NCE-Campus.
    huawei(config)#snmp-agent trap enable    
    huawei(config)#snmp-agent target-host trap-paramsname aaa v3 securityname snmpv3user privacy // Assume that the list name is aaa and the user name displayed on the iMaster NCE-Campus is snmpv3user. This command authenticates and encrypts packets.
    huawei(config)#snmp-agent target-host trap-hostname V3 address 10.10.10.10 udp-port 162 trap-paramsname aaa   //Assume 10.10.10.10 is the destination IP address of the target host that receives the trap packet, user is the host name, 162 is the port, and aaa is the name of the sending parameter list of the trap packet.
  • SNMP v2c
    huawei(config)#snmp-agent community read public123   //Set the read community.
    huawei(config)#snmp-agent community write private123   //Set the write community.
    huawei(config)#snmp-agent trap enable standard
    huawei(config)#snmp-agent target-host trap-paramsname aaa v2c securityname bbb   //Assume aaa is the list name, and bbb is the user name on iMaster NCE-Campus.
    huawei(config)#snmp-agent target-host trap-hostname user address 10.10.10.10 udp-port 162 trap-paramsname aaa   //Assume 10.10.10.10 is the destination IP address of the target host that receives the trap packet, user is the host name, 162 is the port, and aaa is the name of the sending parameter list of the trap packet.
  • SNMP v1
    huawei(config)#snmp-agent community read public123   //Set the read community.
    huawei(config)#snmp-agent community write private123   //Set the write community.
    huawei(config)#snmp-agent trap enable standard
    huawei(config)#snmp-agent target-host trap-paramsname aaa v1 securityname bbb   //Assume aaa is the list name, and bbb is the user name on iMaster NCE-Campus.
    huawei(config)#snmp-agent target-host trap-hostname user address 10.10.10.10 udp-port 162 trap-paramsname aaa   //Assume 10.10.10.10 is the destination IP address of the target host that receives the trap packet, user is the host name, 162 is the port, and aaa is the name of the sending parameter list of the trap packet.

Adding SNMP-managed Network Devices

Prerequisites

The device and iMaster NCE-Campus have reachable routes to each other and have SNMPv3 configured. For details about protocol parameter settings on a device, see Configuring SNMP on Devices.

Procedure
  1. Choose Design > Site Agile Deployment > Device Management from the main menu.
  2. Click Add Device on the Device page.
  3. The system provides three methods for device addition: Add, Import in batches and Automatic discovery.

    • Manually add devices to be managed by the controller through SNMP.
      1. Select an existing site. You may also choose not to add devices to a site.
      2. Choose Add Device > Add.
      3. Select SNMP protocol.
      4. Set basic information, SNMP parameters, and (optional) STelnet parameters.

        SNMP parameters can be set in either of the following ways:
        • Select an SNMP parameter template.

          Select an SNMP parameter template from the template list. If no proper template is available, choose Design > Basic Network Design > Template Management > SNMP Template to create a template as needed.

        • Set SNMP parameters.

          Set SNMP parameters based on the site requirements. The parameter settings must be the same as those on devices.

          Table 4-130 SNMP parameters

          Protocol Version

          Parameter

          Description

          SNMPv3

          NE port number

          Destination port of a network device.

          Username

          Username for logging in to a device.

          Authentication protocol

          Protocol used for message authentication. Select HMAC-SHA2-256.

          Authentication password

          Password used for message authentication.

          Encryption protocol

          Encryption protocol used for data encapsulation. Advanced encryption standards include AES_128, AES_192, and AES_256.

          Encryption password

          Encryption password if an encryption protocol is specified.

          Timeout interval (s)

          Timeout interval for a message sent to a device. A response to the message must be sent within the specified period. If no response is returned, a timeout occurs.
          Table 4-131 STelnet parameters

          Protocol Version

          Parameter

          Description

          STelnet

          NE port number

          Destination port of a network device.

          Username

          Username for logging in to a device.

          Authentication

          Authentication mode for accessing a network device. The options are as follows:

          • Password
          • Key
          • Password and key

          Password

          Password for logging in to a device.

          This parameter must be specified if Authentication is set to Password or Password and Key.

          Key

          Key for logging in to a device.

          This parameter must be specified if Authentication is set to Key or Password and Key.

          Timeout interval (s)

          Timeout interval for a message sent to a device. A response to the message must be sent within the specified period. If no response is returned, a timeout occurs.
      5. Click Confirm.
    • Batch import devices to be managed through SNMP.
    1. Select a desired site. You may also choose not to add devices to a site.
    2. Choose Add Device > Import in batches.
    3. Select SNMP protocol. Download and fill in the template. After all settings are complete, upload the template. Select the devices to which the template will be uploaded in the Import Result window and click OK.

Related Operations
  • Move a device to another site.

    Select a device and click Change Site to move the device to the selected site or remove the device from the current site. You can filter sites by organization.

    1. When moving a device between sites, you can decide whether to delete the device-specific configurations of the source site from the device, including subnets and interfaces. The controller will deliver service configurations of the new site to the device.
    2. If an AP works in another mode after being moved between sites of different types, the controller will delete all original configurations from the AP and delivers service configurations of the destination site to it.
    3. Performing this operation will impact existing services and may take several minutes. Exercise caution when you perform this operation.
  • View sites in an organization.

    Select the target organization from the Organization drop-down list on the Device page. Among the displayed sites, select the desired one and view devices at this site. You can also view sites not in any organization and devices at these sites.

  • Configure SNMP.

    On the Device page, select an SNMP-managed device and choose More Operations > Setting SNMP to manually set SNMP parameters or select an SNMP template. For details about the parameters, see Table 4-130.

  • Configure Telnet.

    On the Device page, select the device to configure and choose More Operations > Setting Telnet to manually set STelnet parameters. For details about the parameters, see Table 4-131.

  • Configure a standalone switch as a stack.

    On the Device page, select a standalone switch, click , enter stack information, and click OK. After a standalone switch sets up a single-switch stack, the switch goes offline.

Adding SNMP-Managed PON Devices

Adding an OLT

Prerequisites
  • eSight and devices can ping each other successfully.
  • Before adding an OLT, you need to obtain the IP address, subnet information, SNMP version, and protocol parameters of the OLT. The configuration on iMaster NCE-Campus must be the same as that on the device. For details about protocol parameter settings on the device, see Configuring SNMP on Devices.
Procedure
  1. Choose Design > Site Agile Deployment > Device Management from the main menu.
  2. Manually add OLT devices one by one.

    1. On the Device tab page, click Not in Any Sites or All Sites.
    2. Click Add Device and then Manually add.
    3. Click SNMP protocol and then PON Device.

  3. Configure basic device information and SNMP parameters based on the obtained information.

    • Set Basic Information, including OLT IP Address, Subnet, and Name.

    • You can manually select an SNMP parameter template or edit SNMP parameters.
      • Select an SNMP parameter template.

        Select a configured SNMP parameter template from the SNMP template list.

      • Set SNMP parameters.

        You can set SNMP parameters based on the site requirements. The parameter settings must be the same as those on the device.

  4. Click OK or Apply. The added device is displayed in the device list, indicating that the device is added successfully.

    • When Edit SNMP parameters is selected, the SNMP version can be SNMPv3, SNMPv1, or SNMPv2c. SNMPv3 is recommended because its security level is higher than those of SNMPv1 and SNMPv2c.
    • Devices cannot be added to iMaster NCE-Campus using an SNMP protocol template with the Security Level set to Without authentication and encryption.
    Table 4-132 Parameters for creating an SNMP template

    Parameter

    Description

    Template name

    Meaning: Name of an SNMP template, which can be customized.

    NE port number

    Meaning: Port used for communication between devices.

    Value range: 1 to 65535

    SNMP version

    SNMP version.

    Default value: SNMPv3

    Security level

    Security level of SNMP, the default value is With authentication and encryption.

    Authentication

    Meaning: Protocol used for message authentication.

    Value range:

    • SHA-512
    • SHA-384
    • SHA-256

    Authentication password

    The password must meet the following requirements:

    • Cannot contain the username.
    • Cannot contain the reverse of the username.
    • Contain 10 to 32 characters.
    • Cannot contain two consecutive identical characters.
    • Contain at least one of the following characters: spaces and special characters, including !"#$%&'()*+,-./:;<=>?@[\]^`{_|}~
    • Contain at least one uppercase letter (A to Z), one lowercase letter (a to z), and one digit (0 to 9).
    • Must be different from the latest 3 historical passwords.

    Data encryption

    Meaning: Encryption protocol used for data encapsulation.

    Value range:

    • AES-256
    • AES-192
    • AES-128

    Encryption password

    The password must meet the following requirements:

    • Cannot contain the username.
    • Cannot contain the reverse of the username.
    • Contain 10 to 32 characters.
    • Cannot contain two consecutive identical characters.
    • Contain at least one of the following characters: spaces and special characters, including !"#$%&'()*+,-./:;<=>?@[\]^`{_|}~
    • Contain at least one uppercase letter (A to Z), one lowercase letter (a to z), and one digit (0 to 9).
    • Must be different from the latest 3 historical passwords.

    Username

    Username for accessing the device.

    Context

    Name of the environment engine.

    Engine ID

    Unique ID of the SNMP engine.

    Timeout period (s)

    Meaning: Upper limit of the time that iMaster NCE-Campus takes to perform an SNMP operation on a device. If the time that iMaster NCE-Campus takes to perform an SNMP operation on a device reaches the value of this parameter, iMaster NCE-Campus abandons this operation.

    Constraints:

    If the quality of the network between iMaster NCE-Campus and the device is low, you can set this parameter to a large value to improve the success rate of SNMP operations.

    Default value: 10

    Polling interval (s)

    Meaning: Interval between two polling operations of SNMP.

    Default value: 1800

    Maximum retry times

    Meaning: Maximum number of times that iMaster NCE-Campus attempts to perform an SNMP operation on a device. If the number of times that iMaster NCE-Campus attempts to perform an SNMP operation on a device reaches the value of this parameter, iMaster NCE-Campus abandons this operation.

    Constraints:

    If the quality of the network between iMaster NCE-Campus and the device is low, you can set this parameter to a large value to improve the success rate of SNMP operations.

    Default value: 5

Related Tasks
  • Move a device to another site.

    Select a device and click Change Site to move the device to the selected site or remove the device from the current site. You can filter sites by organization.

    After a device is moved to another site, the ZTP policy and scenario-specific configuration template that have bound to this device do not take effect.

  • View sites in an organization.

    Select the target organization from the Organization drop-down list on the Device page. Among the displayed sites, select the desired one and view devices at this site. You can also view sites not in any organization and devices at these sites.

  • Configure SNMP.

    On the Device page, select an SNMP-managed device and choose More Operations > Setting SNMP to manually set SNMP parameters or select an SNMP template. For details about the parameters, see Table 4-130.

  • Configure Telnet.

    On the Device page, select the device to configure and choose More Operations > Setting Telnet to manually set STelnet parameters. For details about the parameters, see Table 4-131.

Configuring a Type B Dual-Homing Protection Group

You can create a type B dual-homing protection group by configuring a working OLT and a protection OLT. In this manner, services can fail over to the other OLT when the optical fiber connected to one OLT is faulty.

Prerequisites
  • An OLT has been added to eSight.
  • The device names, IP addresses, and port data of the working and protection OLTs have been obtained before protection groups are added.
Context
  • After a type B dual-homing protection group is configured, PON ports on two different OLTs protect each other. When one OLT is faulty, the system automatically switches services on the faulty OLT to the other OLT and services are not interrupted. The type B dual-homing protection mechanism improves the disaster redundancy capabilities of the OLT. Two OLTs in a protection group can locate in different regions. When the OLT connected to a working optical fiber is faulty, the system automatically switches services on the faulty OLT to the OLT connected to a protection optical fiber.
  • In a protection group, the working OLT and protection OLT must be different.
  • Only one protection group can be created for a port.
  • After an OLT is deleted from the system, the information about the protection group to which the OLT belongs is not displayed in the list. The protection group information is still on the device.
  • After a dual-homing protection group is configured for an OLT, the links in the protection group are displayed in the physical topology based on the protection networking. When an OLT switchover occurs, the ONU in the topology is deleted and redrawn, which does not affect services.
Procedure
  1. Choose Design > Site Agile Deployment > Device Management from the main menu.
  2. Click the Device Group tab and choose Dual-Homing Protection Group from the navigation pane.

    The type B dual-homing protection group information is displayed in a list, including the Name, Protection Mode, Working OLT Name, Working OLT IP Address, Protection OLT Name, Protection OLT IP Address, Protection Status, and Description.

    • When Protection Status of a type B dual-homing protection group is Unknown, check whether the information on the device is the same as that on the system, or synchronize the protection status.
    • On the type B dual-homing protection group page, click a protection group name. On the displayed protection group port configuration page, you can modify port configurations.

  3. Click to configure the basic information, working OLT, and protection OLT.

    A working OLT can be configured with a maximum of two peer nodes.

  4. Click Confirm. The basic information is created successfully.

    Click Cancel to return to the type B dual-homing protection group page. The new type B dual-homing protection group is displayed in the list.

  5. Click Confirm. The port configuration page is displayed. You can perform the operations in Table 4-133 to manage the port information of a protection group.

    Table 4-133 Port configuration operations

    Scenario

    Operation

    Refreshing a protection group

    Click to update the basic information and port data of the protection group.

    Adding port configurations
    1. Click to configure port information.

    2. Click OK. The configured port data is displayed in the port configuration list.

    Modifying port configurations

    Click to modify port configurations.

    NOTE:

    The information about the ports in a protection group referenced by a ZTP policy cannot be modified.

    Deleting port configurations

    Click to delete port configurations.

  6. On the Dual-homing Protection Group page, you can perform the operations in Table 4-134 to manage protection group information.

    Table 4-134 Dual-homing protection group operations

    Scenario

    Operation

    Synchronizing device information
    1. Click .
    2. Select Working OLT, Working OLT IP Address, Protection OLT, and Protect OLT IP Address.
    3. Click Confirm. The protection group information is displayed in the list.

    Modifying protection group information

    Click to edit the IP address, TCP port, communication key, and port configuration information.

    NOTE:

    If you modify a protection group that has been referenced by a ZTP policy, only devices bound to the policy after the modification are affected.

    Deleting protection group information

    Click to delete protection group information

    NOTE:

    A protection group cannot be deleted if it has been referenced by a ZTP policy and the ZTP policy has been bound to devices.

Configuring a Type C Single- or Dual-Homing Protection Group

The type C protection solution provides a dual-channel redundancy protection mechanism for two PON ports on an optical network unit (ONU), the backbone fiber, optical splitter, and distributed fiber on an xPON network. This protection mode improves the reliability of the ODN network and ensures that services are not interrupted.

Prerequisites
  • OLTs/ORHs have been added to eSight.
  • The device names, IP addresses, and port data of the working and protection OLTs/ORHs have been obtained before protection groups are added.
Context
  • After a type C dual-homing protection group is configured, PON ports on two different OLTs/ORHs protect each other. When one OLT/ORH is faulty, the system automatically switches services on the faulty OLT/ORH to the other OLT/ORH to prevent service interruption. The type C dual-homing protection mechanism improves the disaster redundancy capabilities of the OLT/ORH. Two OLTs/ORHs in a protection group can locate in different regions. When the OLT/ORH connected to a working optical fiber is faulty, the system automatically switches services to the OLT/ORH connected to a protection optical fiber.
  • After a type C single-homing protection group is configured, PON ports on OLTs/ORHs function as protection ports for each other. When the active optical fiber is faulty, the system automatically switches to the standby optical fiber.
  • In a type C dual-homing protection group, the working OLT/ORH and protection OLT/ORH must be different.
  • After an OLT/ORH is deleted from the system, the information about the protection group to which the OLT/ORH belongs is not displayed in the list. The protection group information is still on the device.
  • After a protection group is configured for an OLT/ORH, the links in the protection group are displayed in the physical topology based on the protection networking. When an OLT/ORH switchover occurs, the ONU in the topology is deleted and redrawn, which does not affect services.
Procedure
  1. Choose Design > Site Agile Deployment > Device Management from the main menu.
  2. Click the Device Group tab and choose Protection Group Management from the navigation pane.

    The type C dual-homing protection group information is displayed in a list, including the Name, Protection Mode, Working OLT/ORH Name, Working OLT/ORH IP Address, Protection OLT/ORH Name, Protection OLT/ORH IP Address, Protection Status, and Description.

    • When the Protection Status of a type C single- or dual-homing protection group is Unknown, check whether the information on the device is the same as that on the controller, or synchronize the protection status.
    • On the type C single- or dual-homing protection group page, click a protection group name. On the displayed protection group port configuration page, you can modify port configurations.

  3. Click to configure the basic information, working OLT/ORH, and protection OLT/ORH.

  4. Click Confirm. The basic information is created successfully.

    Click Cancel to return to the type C dual-homing protection group page. The new type C dual-homing protection group is displayed in the list.

  5. Click Confirm. On the displayed port configuration page, you can perform the operations in Table 4-135 to manage the port information of a protection group.

    • The protection group ONU list of the new type C single- or dual-homing protection group is empty.
    • If ONUs have been configured for devices in the type C single- or dual-homing protection group, the protection group ONU list displays information about the configured ONUs after device information is synchronized.
    • If a ZTP policy where the type C single-or dual-homing protection group is configured is successfully delivered, the protection group ONU list displays information about the successfully configured ONUs.
    Table 4-135 Port configuration operations

    Scenario

    Operation

    Refreshing a protection group

    Click to update the basic information, port data, and ONU data of a protection group.

    Adding port configurations
    1. Click to configure port information.

    2. Click OK. The configured port data is displayed in the port configuration list.

    Modifying port configurations

    Click to modify the port configurations.

    NOTE:

    The information about the ports in a protection group referenced by a ZTP policy cannot be modified.

    Deleting port configurations

    Click in the Protection Port Config Planning list to delete port configurations.

    NOTE:

    The information about the ports in a protection group referenced by a ZTP policy cannot be deleted.

    Deleting protection group ONUs

    Click in the Protection Group ONUs list to delete protection group ONUs from the list and delete the protection group information configured on devices.

  6. Go to the Protection Group Management page. you can perform the operations in Table 4-136 to manage protection group information.

    Table 4-136 Description of operations on the Protection Group Management page

    Scenario

    Operation

    Synchronizing device information
    1. Click .
    2. Select Working OLT/ORH, Working OLT/ORH IP Address, Protection OLT/ORH, and Protect OLT/ORH IP Address.
    3. Click Confirm. The protection group information is displayed in the list.
      NOTE:

      If ONUs have been configured for devices in the type C single- or dual-homing protection group, the protection group ONU list displays information about the configured ONUs after device information is synchronized.

      In a type C single-homing protection group, the working and protection OLTs/ORHs must be the same.

    Modifying protection group information

    Click . The basic information about the protection group cannot be modified. You can modify the port configuration information.

    Deleting protection group information

    Click to delete protection group information

    NOTE:
    • A protection group cannot be deleted if it has been referenced by a ZTP policy and the ZTP policy has been bound to devices.
    • After a protection group is deleted, the protection group information configured on devices is also deleted.

Device Management Configuration Examples

For details about how to add devices to iMaster NCE-Campus through NETCONF, see Examples for Configuring NETCONF-based Device Management.

For details about how to add devices to iMaster NCE-Campus through SNMP, see Examples for Configuring SNMP-based Device Management.

Configuring Automatic Device Discovery and Management by Protocol

Discovering and Managing Devices Through SNMP

Application Scenario

The system can automatically discover and manage traditional devices through SNMP. This reduces manual intervention and operation costs.

Procedure
  1. Choose Design > Site Agile Deployment > Device Management.
  2. On the Device tab page, choose Add Device > Automatic discovery, and then click Create Discovery Task. You can either select or not select a site when adding devices.
  3. Set the device discovery protocol to SNMP.
  4. In the Basic Settings area on the Set Parameters page, set the IP protocol version, start IP address, end IP address, and subnet where devices to be added are located.
  5. In the Task Settings area, set the task name, user group to which email notifications are sent, discovery frequency, and task description.

    • If you set Frequency to Hourly, Daily, Weekly, or Monthly but do not select Instant execution, the automatic discovery task will not run immediately after being created.
    • If you select Automatically add discovered devices and then click Next, the Results page is displayed.

  6. In the Protocol Settings area, select a protocol type.
  7. Click Next. The Discover Devices page is displayed. The system starts to discover devices.
  8. Add the discovered devices to the system.

    • To add all discovered devices, click Add All.
    • To add selected discovered devices, select desired devices and click Add Selected.

  9. On the Add Devices page, check the devices you have added to the system.
  10. Click Next. The Results page is displayed.

    The result of the automatic discovery task is displayed. Click Success or Fail in the Discovered Devices or Added Devices area to view details in the lower pane.

Related Tasks
  • On the Management Settings tab page, choose Discovery Task Management from the navigation pane and click the Task List tab. On the Task List tab page, you can start, create, modify, delete, and view automatic discovery tasks.
  • On the Management Settings tab page, choose Discovery Task Management from the navigation pane and click the Exclusion List tab. On the Exclusion List tab page, you can add and delete subnets or IP addresses excluded from device discovery.
    • When configuring an excluded subnet, set start and end IP addresses in the Add to Exclusion List dialog box.
    • When configuring an excluded IP address, set only a start IP address in the Add to Exclusion List dialog box.

Discovering and Managing Devices Through NETCONF

Application Scenario

After iMaster NCE-Campus manages a gateway or core device, it can automatically discover and collect information about the device's neighbors through NETCONF, including the ESN and device model. As such, the neighboring devices can be added to iMaster NCE-Campus in batches, implementing ESN-free deployment.

Feature Requirements
  • A gateway or core device has been managed by iMaster NCE-Campus.
  • Only APs and switches running V200R021C00 or later, AR routers running V300R021C00, and stacked devices support ESN-free deployment.
  • Central APs and Fit APs do not support ESN-free deployment.
  • If the device to be scanned is connected to an AR, check whether LLDP is enabled on the AR. If not, this AR cannot be discovered. To ensure that the AR can be discovered successfully, you can log in to the AR and run the lldp enable command to enable LLDP.
Procedure
  1. Choose Design > Site Agile Deployment > Device Management.
  2. On the Device tab page, click In Sites or Not in Any Sites, click Add Device, and choose Automatic discovery from the short-cut menu. On the displayed page, select the NETCONF protocol as the device discovery protocol. Then click Select Scan Device and select devices to be scanned.

  3. Wait for the scanning to complete, and click OK.

    • By default, Name new devices using ESNs is selected. If you deselect this option, newly discovered devices are displayed in device names.
    • Up to two device discovery tasks can be run simultaneously under a tenant. Device discovery tasks will be automatically stopped in half an hour.
    • Running tasks will be lost if you refresh the page or switch to another page.
    • Modified information will be lost after paging up, paging down, or changing search criteria.
    • If the number of discovered devices is different from that displayed in the discovery result, check whether the missing devices have been added to the controller.
    • Devices that have been added to iMaster NCE-Campus are not displayed in the automatic discovery result.

  4. Set a device name.

    Select a device and click Set Device Name. In the dialog box that is displayed, set a device name and click OK.

    When you select multiple devices, the system automatically adds sequence numbers, such as _0 and _1, to the end of the device names to differentiate the devices.

  5. Set the role of a device.

    Select a device, click Set Role, select a role from the drop-down list box, and then verify that the role has been set.

    The following roles can be set: gateway, core, gateway+core, gateway+RR, firewall, WAC, aggregation, access, AP, and regional aggregation.

  6. Set the site to which a device belongs.

    Select a device and click Set Site. In the dialog box that is displayed, select a site and click OK.

  7. Add selected devices to iMaster NCE-Campus.

    Select one or more devices to be added, click Add Selected Devices, and click OK.

  8. (Optional) Perform 3 again to scan and add more devices.

Creating a WAC Group

Application Scenario

You can add WACs to a WAC group to implement N+1 WAC backup. In N+1 backup mode, one WAC functions as a backup WAC to provide backup services for multiple master WACs. In normal cases, an AP sets up links only with the master WAC that it joins. When the master WAC fails or the link between the master WAC and AP is faulty, the backup WAC establishes a link with the AP to manage and provide services for the AP.

Feature Requirements

  • The WACs at different sites can be added to one WAC group. Only the WACs of the same model can be added to one WAC group.
  • A maximum of eight WACs can be added to a WAC group. You can configure Fit APs managed by a WAC member to join any other member in the WAC group. The controller delivers the same configuration to all members in a WAC group.
  • When a WAC is added to a WAC group, the existing configuration of the WAC is not cleared. If the WAC group already has member WACs, the configuration of the new member is combined with the configuration of the existing members, and then the combined configuration is delivered to all members in the WAC group. Before removing a member, clear its configuration. When a member is added, the controller automatically delivers full configurations to the new member.

Procedure

  1. Choose Design > Site Agile Deployment > Device Management from the main menu.
  2. Select the site to configure, click the Device Group tab, choose WAC Group from the navigation pane, and click Create.

    1. Set Name.
    2. Click Add to add member WACs to the WAC group.

    3. Click OK.

Creating a Stack

Application Scenario

A stack has two or more switches connected through cables to work as a logical device. After switches set up a stack, one switch is the master switch, and the others are slave switches. Each switch has an ID.

You can use the stacking function to combine multiple switches into a logical switch, improving network reliability and scalability.

Prerequisites

  1. A stack has been configured on devices.
  2. The configuration for devices to go online is complete. For details, see Huawei CloudCampus Solution Product Documentation.

Feature Requirements

  • When iMaster NCE-Campus is used to manage a stack, the core switches can be modular switches or fixed switches. A maximum of two modular switches can be stacked, a maximum of four fixed switches can be stacked, and a maximum of four aggregation and access switches can be stacked.
  • Currently, only switches can set up stacks. To check whether the models and versions of the switches managed by iMaster NCE-Campus can set up a stack or CSS:

    For fixed switches, see Stack Version and Model Requirements in the product documentation.

    For modular switches, see CSS Version Requirements in the product documentation.

    For details about how to configure stack or CSS on switches, see Stack & SVF Assistant.

Procedure

  1. Choose Design > Site Agile Deployment > Device Management from the main menu.
  2. Click Stack on the Device Group tab page, and click Create Stack.

    1. Set Stack Name and select the target site to which the stack belongs from the Site drop-down list box.
    2. Set Role. The role must be set to be the same as that set when a device is added.
    3. Set the mode for adding stack member devices.
      • Synchronize from detected stacks: The system automatically detects the stacks that have been set up on devices. You need to manually add member switches to a stack on the controller. If the stack member information fails to be obtained, click Synchronize from detected stacks again to refresh the stack member information.
      • Manual creation: Click Manual creation to add devices to the stack.
        • Only switches of the same series can be added to a stack.
        • All the switches that need to set up a stack must be added to the stack before they go online. Otherwise, the stack may fail to go online.
    4. (Optional) Click in the Member column to modify the stack ID and priority. Click to save the modification.

      The stack ID is in the range from 0 to 8 and cannot be the same as the ID of any member device in the stack. The stack ID of a stack consisting of modular switches can be 1 or 2.

      The priority is in the range from 1 to 255 and the default value is 100. A larger value indicates a higher priority.

      If switches have set up a stack and have services configured, it is recommended that the stack IDs and priorities of stack members specified on iMaster NCE-Campus be the same as those configured on the stack members. Otherwise, the stack IDs and priorities delivered by iMaster NCE-Campus will overwrite the original stack information of the stack members. As a result, the services that take effect on the stack members are inconsistent with those in configuration files. You can run the following commands to check original stack information:

      Run the display esn command to check the ESN and stack ID of each stack member.

      For a CSS set up by modular switches, run the display css configuration command to check the stack ID and stack priority of each CSS member.

      For a stack set up by fixed switches, run the display stack command to check the stack ID and stack priority of each stack member.

    5. Click OK.
      • When a stack goes online, iMaster NCE-Campus checks the status of the member switches in the stack, and delivers configurations only after all the member switches in the stack go online. This prevents the configuration delivery failure in the scenario where some member switches go offline.
      • If one of the member switches in a stack goes offline after the stack goes online, the stack configuration cannot be performed.
      • After a stack goes online, a member switch on which an uplink interface of the stack resides is removed from the stack and then added to the stack again. In this case, if the slot number of the member switch is changed, the member switch may fail to go online. To ensure that other member switches in the stack can go online, the stack must have other available uplinks before this member switch is removed from the stack.
      • When a master/standby switchover occurs in a stack, the member devices in the stack will go online again.

  3. View and manage stacks.

    Click next to a stack name to check stack members in the stack. You can also maintain the stack.

    • Maintain a stack member.

      Click Configure Stack Port. The Switch & Interface page is displayed. You can configure ports for member devices in a stack.

      Click next to a stack member to change its priority.

      Click next to a stack member to replace it with another device.

      Click next to the name of a stack member to remove it from the stack.

      In the Probe Stacked Members area, you can view the stacks that have been set up on devices. Then, you can create a stack on iMaster NCE-Campus, and directly add member devices to the stack based on the discovered stack.

    • Modify or delete a stack.

      Click next to the name of a stack to modify the stack name or stack role. Click to delete the stack.

    If the status of a stack is displayed as Unregistered or Offline, locate the fault based on device provisioning and disconnection logs. Possible causes are as follows:
    • The license is expired.

      When device licenses are insufficient, import a license file if a global perpetual license or global subscription license is used, or import a new activation code or entitlement ID if a tenant subscription license is used.

    • The stack status of member devices displayed on iMaster NCE-Campus is inconsistent with that displayed on the member devices. The following two situations may occur:
      • According to the query result on iMaster NCE-Campus, member devices have set up a stack. However, according to the query result on the devices, they do not set up a stack.
      • According to the query result on iMaster NCE-Campus, a certain device is not a stack member. However, the command output on this device shows that the device is a stack member.

        To rectify the fault, modify configurations on member devices or iMaster NCE-Campus to ensure that the stack status displayed is consistent on them. For details about related commands on devices, see "Configuration Examples for Stacks" in related switch product documentation.

    • Stack member information displayed on iMaster NCE-Campus is inconsistent with that on the device. The following two situations may occur:
      • The ID and priority of a stack member displayed on iMaster NCE-Campus and on the device are inconsistent. The information will be synchronized after the device goes online again.
      • Some devices are not added to the stack. In this case, check whether the stack members displayed on iMaster NCE-Campus are the same as those queried on stack members.

        If device provisioning and disconnection logs do not explain the reason why a device is offline, the possible cause is that the device has not registered with iMaster NCE-Campus. In this case, check the network between the device and iMaster NCE-Campus or check whether the device is added to the stack.

        To rectify the fault, modify configurations on devices or iMaster NCE-Campus to ensure that the stack information displayed on them is consistent. For details about related commands on devices, see "Configuration Examples for Stacks" in the corresponding switch product documentation.

    • The device is not in the whitelist.

      Using an ESN whitelist, you can restrict the devices that can register with iMaster NCE-Campus and go online. After this function is enabled, devices whose ESNs are not in the whitelist are regarded as unauthorized devices.

      In this case, the system administrator needs to check whether the ESN of a device is in the ESN whitelist. If not, add the device ESN to the ESN whitelist.

Related Tasks

  • Configure a standalone device as a stack.

    To configure a standalone device as a stack, click in the row of the desired device on the Device page.

    • This function is supported for fixed switches only.
    • Devices that are not added to a site cannot be configured as a stack, or created or added to a stack.
    • After a standalone device sets up a stack, the stack inherits the configuration of the original standalone device and the original device goes offline automatically. The device can go online successfully only after you configure the device as a stack on the device.

  • View stack information.

    Click Stack to view the stacks of all or one organization.

Parameter Description

Table 4-137 Parameters for creating a stack

Parameter

Description

Stack name

Name of a stack.

Role

Role reported to the system based on switch settings.

Slot ID

ID of a switch in a stack. The value is in the range from 0 to 8. The switch IDs in the same stack must be unique.

Priority

Meaning: Priority of a switch in the stack. A larger value indicates a higher priority.

Value range: 1 to 255

Default value: 100

AP Grouping Recommendations

Application Scenario

In normal cases, APs in the same site are automatically assigned to an automatically created management group. The APs provide radio calibration and load balancing functions based on settings for this management group. Due to limitations of the AP specifications, it is recommended that the number of APs to be added to a site do not exceed the number specified in Table 4-138. If APs of different models exist in a site, the recommended number for APs with higher performance takes effect.

Feature Requirements

When both the AD9430DN-24/12 and cloud APs are deployed on the same network, the following requirements must be met:

  • It is recommended that at least two AD9430DN-24/12 devices be deployed. In large-scale network deployment, at least four AD9430DN-24/12 devices are recommended.
  • It is recommended that the number of cloud APs does not exceed the upper limit in Table 4-138.
  • The total number of RUs and cloud APs is less than or equal to 300.

For example, on a network with AD9430DN-24 and AP6052DN, the number of AD9430DN-24 does not exceed 8, the number of AP6052DN does not exceed 128, and the number of AP6052DN and RUs does not exceed 300.

The AD9431DN-24X is responsible for roaming, radio calibration, and load balancing of RUs only in the management group to which it belongs.

Recommended Number of APs at a Site

Table 4-138 Recommended number of APs at a site

AP Model

Recommended maximum number of APs in a group

AP1050DN-S

51

AP2050DN

51

AP2050DN-E

51

AP2050DN-S

51

AP2051DN

51

AP2051DN-E

51

AP2051DN-S

51

AP4051DN-S

51

AP4050DN

51

AP4050DN-S

51

AP4050DN-E

51

AP4050DN-HD

51

AP4051DN

51

AP4151DN

51

AP5030DN-C

25

AP5050DN-S

129

AP6050DN

129

AP6150DN

129

AP7050DE

129

AP7050DN-E

129

AP8030DN

51

AP8050DN

51

AP8050DN-S

51

AP8130DN

51

AP8150DN

51

AD9430DN-12

The following requirements need to be met: the number of central APs does not exceed 8 and the number of RUs does not exceed 300.

AD9430DN-24

The following requirements need to be met: the number of central APs does not exceed 8 and the number of RUs does not exceed 300.

R230D

51

R240D

51

R250D

51

R250D-E

51

R251D

51

R251D-E

51

R450D

51

AP4051TN

51

AP6052DN

129

AP7052DN

129

AP7052DE

129

AP7152DN

129

AP8050TN-HD

51

AP8082DN

129

AP8182DN

129

AP100EC

51

AP200EC

51

AP300EC

51

AP3050DE

129

AP7060DN

129

WA375DD-CE

51

AP4050DE-M

129

AP5510-W-GP

51

AP9330DN

51

AD9431DN-24X

The following requirements need to be met: the number of central APs does not exceed 8 and the number of RUs does not exceed 300.

AP5030DN

51

AP4030DN

51

AP4130DN

51

AP2030DN

51

AP6010DN-AGN

51

AP3010DN-AGN

51

AP2010DN

51

AP6510DN-AGN

51

AP4050DE-M-S

129

AP4050DE-B-S

129

AP2051DN-L-S

51

AP5030DN-S

51

AirEngine5760-10

129

AP6750-10T

51

AP7030DE

51

AP4030DN-E

51

AP5130DN

51

AP4030TN

51

AP210

51

AP230

51

AP310

51

AP330

51

AP350

51

AP3010DN-V2

51

AirEngine9700D-M

The following requirements need to be met: the number of central APs does not exceed 8 and the number of RUs does not exceed 300.

AirEngine8760R-X1

129

AirEngine8760R-X1E

129

AirEngine6760R-51

129

AirEngine6760R-51E

129

AirEngine6760-X1

129

AirEngine6760-X1E

129

AirEngine5760-51

129

AirEngine5760-22WD

51

AirEngine8760-X1-PRO

129

AirEngine5760-22W

129

AirEngine6761S-21T

129

AirEngine6761-21T

129

AirEngine5761-11

129

AirEngine5761S-11

129

AirEngine5761-11W

129

AirEngine5761S-11W

129

AirEngine5761-11WD

51

AirEngine5761S-21

129

AirEngine5761-21

129

AirEngine5761-12W

129

AirEngine6760-51EI

129

Random AP Grouping

If more APs than recommended are deployed, they will be randomly assigned to multiple automatically created management groups. As a result, neighboring APs or APs in the same floor may be in different management groups, as shown in Figure 4-75. If this occurs, the expected radio calibration and load balancing effects cannot be achieved.

  • Radio calibration is performed in each management group separately. If neighboring APs belong to different management groups, radio calibration cannot achieve the optimal effect.
  • Load balancing cannot be implemented for APs in different management groups. If neighboring APs belong to different management groups, the number of access users cannot be balanced.

In Figure 4-75, 125 APs deployed in floors 1 to 3 are randomly assigned to multiple automatically created management groups. As a result, neighboring APs or APs in the same floor may be in different management groups. If this occurs, the expected radio calibration and load balancing effects cannot be achieved.

Figure 4-75 Random grouping example

AP Grouping by Management VLAN

If you need to add more APs than recommended to the same site, make more detailed network planning and manually divide the APs into different management groups according to the following principles. Figure 4-76 shows AP grouping by management VLAN.

  1. Determine the number of groups based on the number of floors or physical areas. (For details about the number of APs supported by each group, see Table 4-138.) Add APs in the same floor or physical area to the same group.
  2. Plan a management VLAN for each group. (Generally, configure PVIDs on the upstream access switch and use them as the management VLANs of the APs).

In Figure 4-76, three management groups are planned based on the AP floor distribution, and the corresponding management VLANs are planned. APs are added to the corresponding management group of each floor to which the APs belong by management VLAN. This approach improves radio calibration and load balancing effects.

Figure 4-76 Example of grouping by management VLAN
  • The division of management groups and management VLANs affects only radio calibration and load balancing services. It does not affect network division for Layer 2 and Layer 3 roaming.
  • Do not configure port isolation based on management VLANs for APs. Otherwise, APs in the same VLAN cannot create a management group using broadcast packets.
  • You are advised to configure broadcast rate limiting on the upstream access switch of the APs to prevent broadcast flooding.

Configuring a Network Plan

Application Scenario

A network plan defines the underlay network topology, such as devices, boards, and links at sites. After a network plan is imported to the system, related information is automatically imported, improving manual configuration efficiency.

Prerequisites

A site has been created. You can only plan the network topology of existing sites.

Feature Requirements

  • To add to a stack to a site, add stack members to the site first, and set up the stack. For details, see Stack & SVF Assistant. A stack can be added to a site only when the preceding conditions are met.
  • When you add a stack to a site on iMaster NCE-Campus by importing the stack information through a template, the stack restarts if the original stack information is different from the information in the template imported to iMaster NCE-Campus. Before the restart, iMaster NCE-Campus delivers new stack information (except the slot IDs of the modular switch members in the stack) to the stack.
  • For a CSS of modular switches that needs to go online on iMaster NCE-Campus using commands, you can run the display esn and display css status commands during local command configuration to record the mapping between the ESNs, stack IDs, and stack priorities of the switch members in the CSS. To prevent a CSS restart, ensure that the CSS information filled in the template is the same as that when the CSS is set up.
  • For a stack of fixed switches that achieves plug-and-play in DHCP mode, the stack needs to have empty configuration. In addition, you are advised to fill in the stack information in the template as planned due to the presence of many fixed switches on the campus network. If the stack information in the template is different from the original information, the stack can restart and go online again according to the planned information.
  • For modular switches, if link information needs to be imported, you must fill the information in the Card sheet to record the mappings between slot IDs and card models.

Procedure

  1. Choose Design > Basic Network Design > Import Network Plan. Click the template download link to download the template.

  2. Enter the device information and physical link data to be added based on the template requirements.

    Table 4-139 shows an example of the information entered on the Device worksheet; Table 4-140 shows an example of the information entered on the Board worksheet; and Table 4-141 shows an example of the information entered on the Link worksheet.

    When you add a stack to a site on iMaster NCE-Campus by importing the stack information through a template, the stack restarts if the original stack information is different from the information in the template imported to iMaster NCE-Campus. Before the restart, iMaster NCE-Campus delivers new stack information (except the slot IDs of the modular switch members in the stack) to the stack. As such,

    • For a stack of modular switches that needs to go online on iMaster NCE-Campus using commands, you can run the display esn and display css status commands during local command configuration to record the mapping between the ESNs, stack IDs, and stack priorities of the switch members in the stack. To prevent a stack restart, ensure that the stack information filled in the template is the same as that when the stack is set up.
    • For a stack of fixed switches that achieves plug-and-play in DHCP mode, the stack needs to have empty configuration. In addition, you are advised to fill in the stack information in the template as planned due to the presence of many fixed switches on the campus network. If the stack information in the template is different from the original information, the stack can restart and go online again according to the planned information.
    Table 4-139 Example values on the Device worksheet

    ESN

    Device Name

    Device Model

    Description

    Role

    Stack Name

    Slot ID

    Stack Priority

    210XXXXXXX54

    S12700E-1

    S12700E-12

    -

    Core

    Core

    1

    200

    210XXXXXXX55

    S12700E-2

    S12700E-12

    -

    Core

    Core

    2

    150
    • ESN: If the ESN is not specified, the device name and device model must be specified. If the ESN is specified, you are advised to specify the device model as well. Otherwise, the device may fail to be added.

      The ESNs of switches, APs, and WACs must be entered into the site to which the devices belong. You are advised to enter device ESNs using the network plan template.

    • Device Name: Mandatory
    • Device Model: Optional for device models with 20-digit ESNs, but mandatory for device models with 12-digit ESNs
    • Description: Optional
    • Role: Optional. Configure roles for devices based on the site requirements. If you do not set the device role when adding a device, the system sets the device role to Access by default.
    • Stack Name: Mandatory for stacked devices
    • Slot ID: Mandatory for stacked devices
    • Stack Priority: Optional If this parameter is not set for a stack, the default value 100 is used.

    Table 4-140 Example values on the Board worksheet

    Device Name

    Card Slot No./Slot ID

    Board Model

    S12700E-1

    slot1/1

    LST7X48SX6E0

    S12700E-1

    slot1/2

    LST7X48SX6E0
    • Device Name: Mandatory
    • Card Slot/Slot ID: Mandatory
    • Card Model: Mandatory

    For modular switches, if link information needs to be imported, you must fill the information in the Card sheet to record the mappings between slot IDs and card models.

    Table 4-141 Example values on the Link worksheet

    Upstream Device Name

    Physical Port Number of the Upstream Device

    Eth-Trunk on the Upstream Device

    Downstream Device Name

    Physical Port Number of the Downstream Device

    Eth-Trunk on the Downstream Device

    S12700E-1

    XGigabitEthernet1/1/0/1

    Eth-Trunk1

    S6730-H-a1

    XGigabitEthernet1/0/1

    Eth-Trunk1

    S12700E-1

    XGigabitEthernet1/1/0/2

    Eth-Trunk1

    S6730-H-a2

    XGigabitEthernet2/0/1

    Eth-Trunk1

    S12700E-2

    XGigabitEthernet2/1/0/1

    Eth-Trunk1

    S6730-H-a1

    XGigabitEthernet1/0/2

    Eth-Trunk1

    S12700E-2

    XGigabitEthernet2/1/0/2

    Eth-Trunk1

    S6730-H-a2

    XGigabitEthernet2/0/2

    Eth-Trunk1
    • Upstream Device Name: Mandatory
    • Physical Port Number of the Upstream Device: Mandatory The port number name and letter case must be the same as the actual values. Otherwise, an error may occur during the import.
    • Eth-Trunk on the Upstream Device: Mandatory for aggregated links The port number name and letter case must be the same as the actual values. Otherwise, an error may occur during the import.
    • Downstream Device Name: Mandatory
    • Physical Port Number of the Downstream Device: Mandatory The port number name and letter case must be the same as the actual values. Otherwise, an error may occur during the import.
    • Eth-Trunk on the Downstream Device: Mandatory for aggregated links The port number name and letter case must be the same as the actual values. Otherwise, an error may occur during the import.

    After the Eth-Trunk information is imported to the site using the network plan import template, the Eth-Trunk auto-negotiation function is pre-configured on the downlink Eth-Trunk interface of the upstream device by default. This is to ensure that the downstream device can go online on iMaster NCE-Campus through the Eth-Trunk.

  3. On iMaster NCE-Campus, click Select a file, select the template file, and click Upload. After the upload is complete, click Import to import the data in the file to the site.

    When new devices and links are added to the network, you can import a new template that contains information about the new devices, devices connected to the new devices, and new links.

Parameter Description

Table 4-142 Parameters on Device tab page

Parameter

Description

ESN

If the ESN is not specified, the device name and device model must be specified. If the ESN is specified, you are advised to specify the device model as well. Otherwise, the device may fail to be added.

Device Name

This parameter is mandatory.

Device Model

This parameter is optional for device models with 20-digit ESNs, but mandatory for device models with 12-digit ESNs

Description

This parameter is optional.

Role

This parameter is optional. Configure roles for devices based on the site requirements. If you do not set the device role when adding a device, the system sets the device role to Access by default.

Stack Name

This parameter is mandatory for stacks.

Slot ID

This parameter is mandatory for stacks.

Stack Priority

This parameter is optional. If this parameter is not set for a stack, the default value 100 is used.
Table 4-143 Parameters on the Board tab page

Parameter

Description

Device Name

This parameter is mandatory.

Card Slot No./Slot No.

This parameter is mandatory.

Board Model

This parameter is mandatory.
Table 4-144 Parameters on the Link tab page

Parameter

Description

Upstream Device

This parameter is mandatory.

Physical Port Number of the Upstream Device

This parameter is mandatory.

Eth-Trunk Interface on the Upstream Device

This parameter is mandatory for an Eth-Trunk.

Downstream Device

This parameter is mandatory.

Physical Port Number on the Downstream Device

This parameter is mandatory.

Eth-Trunk Interface on the Downstream Device

This parameter is mandatory for an Eth-Trunk.

Configuring a LAN Resource Pool

Application Scenario

In actual network configuration, a network may be planned on multiple IP address segments. Therefore, you need to plan IP resources in advance. The planned IP address segments can be applied to devices such as firewalls, routers, and switches at a site. Alternatively, you can create IP address segments when creating sites.

Procedure

  1. Choose Design > Basic Network Design > Network Settings from the main menu and click the LAN Resource Pool tab.
  2. Click Create and set parameters based on the network plan.

  3. Click in the Operation column to complete the configuration.

Parameter Description

Table 4-145 Parameters for configuring a LAN resource pool

Parameter

Description

Name

Resource pool name.

Description

Resource pool description.

Start Network Address

Meaning: Start network segment of the LAN subnet. The value is a unicast IP address in dotted decimal notation. The subnet that takes effect is the subnet where the network address of the start IP address resides.

Example: 192.168.3.0

End Network Address

Meaning: End network segment of the LAN subnet. The value is a unicast IP address in dotted decimal notation. The subnet that takes effect is the subnet where the network address of the start IP address resides.

Example: 192.168.4.0

Mask

Meaning: Subnet mask.

Value range: The value is an integer in the range from 17 to 30.

Reserved IP Segments

Meaning: Reserved network segment. Separate multiple network segments with commas (,).

Example: 192.168.3.10,192.168.3.100

Configuring a VXLAN Fabric Global Resource Pool

Fundamentals

Before creating virtual networks (VNs), you need to configure global resources, including the resource pools of VLANs, VXLAN Network Identifiers (VNIs), and bridge domains (BDs). When you create a VN, iMaster NCE-Campus automatically allocates resources from these resource pools.

The following figure shows the layers where VLANs, VNIs, and BDs are located on the network and the relationships among these resources.

Feature Requirements

Configure a service VLAN pool when you need to configure VLANs for interconnection with external gateways and network service resources, management VLANs for policy association, and access VLANs for virtual network access. When planning VLANs, ensure that the desired VLANs are not used by non-VXLAN fabric services. For example, the VLAN ID of the planned management VLAN cannot be included in the VLAN resource pool. Otherwise, services may be interrupted.

Procedure

  1. Choose Design > Basic Network Design > Network Settings and click the VXLAN Fabric Global Resource Pool tab.
  2. Set parameters and click to make the settings take effect.

    Configuration example: For the VLAN resource pool, enter 3000 - 4000 and 4012 - 4012. After each input, click for the setting to take effect. Then, set Bridge Domain (BD) to the default value (1 - 4095) and VXLAN Network Identifier (VNI) to the default value (1 - 4095).

Related Operations

  • Select the resource to be deleted and click to delete the resource.
  • Click to refresh resources displayed on the page.

Parameters Description

Table 4-146 Parameters for configuring the VXLAN fabric global resource pool

Parameter

Description

VLAN

Meaning: Service VLAN resource pool. VLANs in this pool will be configured as interconnection VLANs for external gateways, interconnection VLANs for network service resources, CAPWAP management VLANs, and VLANs for VN access, if these configurations are required.

For example, enter 3000 - 4000 and 4012 - 4012. After each input, click for the setting to take effect.

Bridge Domain (BD)

Meaning: VLANs are used to divide broadcast domains on a traditional network. Similarly, BDs are used to divide broadcast domains on a VXLAN network. On a VXLAN network, VNIs must be mapped to BDs in 1:1 mode. A BD represents a broadcast domain. Users in the same BD can communicate with each other at Layer 2.

For example, enter 3000 - 4000 and 4012 - 4012. After each input, click for the setting to take effect.

Default value: 1 to 4095

VXLAN Network Identifier (VNI)

Meaning: A VNI, similar to a VLAN ID, identifies a VXLAN segment. Tenants on different VXLAN segments cannot communicate at Layer 2. One tenant may have one or more VNIs. A VNI consists of 24 bits and supports up to 16 million tenants.

For example, enter 3000 - 4000 and 4012 - 4012. After each input, click for the setting to take effect.

Default value: 1 to 4095

Configuring an Underlay Automation Resource Pool

Fundamentals

When you create VXLAN fabric networks, you can enable automated underlay routing domain orchestration. This implements automatic deployment of the underlay network. After this function is enabled, iMaster NCE-Campus automatically provisions configurations using resources in the underlay automation resource pool, such as VLANIF interfaces, loopback interfaces, VTEP IP addresses, and routes, required for BGP-EVPN to devices on VXLAN fabric networks.

The hierarchy and relationship of loopback interface IP addresses, interconnection VLANs, and interconnection IP addresses in the network are shown in the figure below:

Feature Requirements

If multi-layer aggregation devices are deployed on the network, underlay automation is supported only for a single domain.

Application Scenario

Automated underlay routing domain orchestration supports automatic deployment of routes between border and edge nodes on VXLAN fabrics. The system configures interconnection links between border nodes and between border nodes and edge nodes to ensure that the VTEPs on the entire network are reachable to each other through OSPF routes.

  • Recommended scenario: A VXLAN fabric has one site with core, aggregation, and access devices.
    Figure 4-77 Three-layer VXLAN fabric networking 1

    Choose Design > Site Agile Deployment > Device Management from the main menu, configure the border node as Core, edge nodes as Aggregation, and access nodes as Access.

  • Other networking scenarios: If transparent transmission devices are deployed on the underlay network under a fabric network, it is recommended that the device role of border nodes be set to Core, that of edge nodes be set to Aggregation, that of transparent transmission devices (deployed on the fabric network) between border nodes and edge nodes be set to Regional aggregation. Currently, transparent transmission devices can be deployed only between border nodes and edge nodes. When a VXLAN fabric network spans multiple sites, ensure that device roles are set correctly and there are reachable OSPF routes between these sites.
    • Scenario 1: A VXLAN fabric network spans multiple sites, and only one site has a border node, as shown in the following figure.
      Figure 4-78 Multi-site scenario

      Perform the following operations to configure automatic underlay deployment:

      1. Choose Design > Site Agile Deployment > Device Management from the main menu and set the role of edge node 2 to Core.
      2. Check the OSPF areas automatically configured for the border node, choose Provision > Physical Network > Site Configuration from the main menu, choose Switch > Route from the navigation pane, and click the Interface OSPF tab, and manually configure routes for interconnection interfaces on the border node and Edge 2 to ensure that there are reachable routes between their interconnection interfaces.
    • Scenario 2: A VXLAN fabric network has three layers of devices, including a border node, edge nodes, and an access device, as shown in the following figure.
      Figure 4-79 Three-layer VXLAN fabric networking 2

      Perform the following operations to configure automatic underlay deployment:

      1. Choose Design > Site Agile Deployment > Device Management from the main menu and set the role of edge node 2 to Aggregation.
      2. Set the role of the access device on the VXLAN fabric network to an extended node.
    • Scenario 3: A VXLAN fabric network has multiple border nodes that form a ring network with downlink devices, as shown in the following figure.
      Figure 4-80 Multi-border ring networking

      Perform the following operations to configure automatic underlay deployment:

      1. Choose Design > Site Agile Deployment > Device Management, set the role of transparent transmission devices 1 and 2 to Regional aggregation.
      2. Choose Design > Site Agile Deployment > Device Management and set the role of edge nodes 1 and 2 to Aggregation.

Procedure

  1. Choose Design > Basic Network Design > Network Settings and click the Underlay Automation Resource Pool tab.
  2. Set parameters and click to make the settings take effect.

    Configuration example: For the interconnection VLAN resource pool, enter 100 - 200. After the input, click for the setting to take effect. Then set Interworking IP to 192.168.1.0 - 192.168.2.0/24 and Loopback interface IP to 192.168.3.0 - 192.168.4.0/24.

Related Operations

  • Select the resource to be deleted and click to delete the resource.
  • Click to refresh resources displayed on the page.

Parameters

Table 4-147 Parameters for configuring the underlay automation resource pool

Parameter

Description

Interconnection VLAN

Meaning: VLAN resource pool for interconnection between border and edge nodes. The system automatically selects a VLAN as the interconnection VLAN if border and edge nodes need to be interconnected on the underlay networks of VXLAN fabrics.

Example: Enter 3000 - 4000 and 4012 - 4012. After each input, click for the setting to take effect.

Interworking IP address

Meaning: IP address resource pool for interconnection between border and edge nodes. The system automatically selects an IP address as the interworking IP address if border and edge nodes need to be interconnected on the underlay networks of VXLAN fabrics.

Example: Set 192.168.1.0 and 192.168.2.0/24 as the start and end addresses. After input, click for the settings to take effect.

Constraints: The addresses planned on the underlay network cannot overlap with those planned on the WAN. Otherwise, unexpected network problems may occur.

Loopback interface IP address

Meaning: IP address resource pool for loopback interfaces. The system automatically selects IP addresses for loopback interfaces if routing domains need to be automatically configured on VXLAN fabrics.

Example: Set 192.168.1.0 and 192.168.2.0/24 as the start and end IP addresses. After input, click for the settings to take effect.

Constraints: The addresses planned on the underlay network cannot overlap with those planned on the WAN. Otherwise, unexpected network problems may occur.

Template Management

Customizing Policy Template

Context

To simplify configurations and unify management, iMaster NCE-Campus adds the following parameter sets into a template. When configuring related services, you can import a template and bind parameters in this template to the configuration object.

ACL Template

Fundamentals

ACLs are mainly applied to QoS, route filtering, and user access.

  • Limit data flows to improve network performance. For example, ACLs are configured on an enterprise network to limit video data flows, which lowers the network load and improves network performance.
  • Provide flow control. For example, ACLs are used to limit transmission of routing updates so that the bandwidth is saved.
  • Provide network access security. For example, ACLs are configured to allow specified users to access the human resource network.
Application Scenario

A user ACL defines rules based on information about IPv4 or IPv6 packets to implement packet filtering. Such information includes source IP addresses, destination IP addresses, IP protocol types, TCP source/destination port numbers, and UDP source/destination port numbers.

Procedure
  1. Choose Design > Basic Network Design > Template Management, from the main menu and click Policy Template., and choose ACL from the navigation pane.
  2. Click Create, click the IPv4 or IPv6 tab, set parameters, and click OK.

Parameter Description
Table 4-148 Policy Template (ACL)

Parameter

Description

Name

Meaning: Unique identifier of an ACL template.

ACL type

Value range:

  • User ACL: 6000 to 6031
  • Advanced ACL: 3001 to 3999

Constraints: If domain names are specified in matching rules in an ACL, a maximum of 128 rules can be configured in an ACL. If IP addresses are specified in matching rules in an ACL, a maximum of 32 rules can be configured in an ACL. User ACLs are supported only in IPv4.

ACL number

ACL number delivered to the target device.

Rule list

-

-

Click Add, create rules in the ACL template, and click OK.

User ACL

IP/Domain

IP address or domain name of the packets matching the ACL.

Protocol

Value range:

  • Any
  • TCP: This protocol is recommended.
  • UDP: This protocol is not secure and is not recommended.

Port

Meaning: Destination port number of the packets matching the ACL.

Constraints: This parameter is configurable only when Protocol is set to TCP or UDP.

Advanced ACL

Priority

Priority of a rule in the ACL template. A smaller value indicates a higher priority.

Action

Action to take on packets matching the rule.

  • Permit: permits the packets matching the rule.
  • Deny: denies the packets matching the rule.

Protocol

Protocol of the packets matching the rule.

Source IP Address

Source IP address of the packets matching the rule.

Source Port

Source port number of the packets matching the rule.

Destination IP Address

Destination IP address of the packets matching the rule.

Destination Port

Destination port number of the packets matching the rule.

Dynamic ACL Template

Procedure
  1. Choose Design > Basic Network Design > Template Management, from the main menu and click Policy Template. Choose Dynamic ACL from the navigation pane.
  2. Click Create, set parameters, and click OK.

Parameter Description
Table 4-149 Policy Template (dynamic ACL)

Parameter

Description

Name

Unique identifier of a dynamic ACL template.

Rule list

-

Click Add, create rules in the dynamic ACL template, and click OK.

Priority

Priority of a rule. The value must be an integer.

Destination IP Address

Destination IP address of the packets matching the ACL rule.

Protocol

Value range:

  • Any
  • TCP: This protocol is recommended.
  • UDP: This protocol is not secure and is not recommended.

Port

Destination port number of the packets matching the rule.

Control Type

Meaning: Action taken on the packets that match the rule.

Value range: The value can be Permit or Deny.

URL Category Template

Context

iMaster NCE-Campus uses preset URL category templates to classify common URLs. If the preset templates in the system do not meet requirements, you can create a user-defined category template to configure rules for matching URLs and domain names.

URLs and domain names can be matched either in fuzzy or exact matching mode. Table 4-150 compares the matching modes.

Table 4-150 Matching modes

Matching Mode

Definition

Example

Fuzzy match

Prefix matching

Matches all URLs starting with a specified character string, such as www.example*.

All URLs that start with www.example are matched, such as:

  • www.example.com
  • www.example.com/solutions.do

Suffix matching

Matches all URLs ending with a specified character string, such as *aspx.

All URLs ending with aspx are matched, such as:

  • www.example.com/news/solutions.aspx
  • www.example.com/it/price.aspx
  • 10.1.1.1/sports/abc.aspx

Keyword matching

Matches all URLs containing a specified character string, such as *sport*.

All URLs containing sport are matched, such as:

  • sports.example.com/news/solutions.aspx
  • sports.example.com/it/
  • 10.1.1.1/sports/

Exact match

The system checks whether a URL matches the specified string. If not, the system removes the last directory from the URL and matches the URL with the specified string. If the URL is still not matched, the system removes the last directory from the URL and matches the URL with the specified string. This process continues until the domain name is matched against the string.

The URL www.example.com matches the following items:

  • www.example.com
  • www.example.com/news
  • www.example.com/news/en/

This URL does not match the following items:

  • www.example.com.cn/news
  • www.example.org/news/www.example.com
Feature Requirements

You can create up to 64 URL category templates for a tenant.

Procedure
  1. Choose Design > Basic Network Design > Template Management, from the main menu and click Policy Template. Choose URL Category Template from the navigation pane.
  2. Click Create User-defined Category, set parameters as needed, and click OK.

    Enter the URLs and domain names to be filtered and separate them with line breaks. Duplicate items are ignored.

    1. Configure URL or domain name rules based on the application scenario.
      • For filtering URLs that are domain names (for example, www.example.com), both URL rules and domain name rules apply in most cases and have the same filtering effect.
      • For filtering URLs that contain a path or parameter information (for example, www.example.com/news), only URL rules apply.
    2. Configure a URL rule by specifying the URLs to be filtered. To filter URLs of the HTTPS protocol, enter only the domain names of the URLs. To filter URLs of the HTTP protocol, enter URLs starting with http://.
    3. Configure a domain name rule by specifying the domain names or IP addresses to be filtered.

Parameter Description
Table 4-151 LAN Policy Template (URL category template)

Parameter

Description

Name

Unique identifier of a URL category template.

URL

Meaning: List of the URLs to be filtered. Separate multiple URLs with line breaks.

Constraints:

  • Asterisks (*) can be used for fuzzy match of URLs. If URLs to be filtered do not contain asterisks, they are matched in exact match mode. You can configure a maximum of 32 fuzzy match rules and 512 exact match rules. Duplicate items are not counted.
  • If the filtering target is an address starting with https (for example, https://www.huawei.com), you need to enter only the domain name (www.huawei.com) of the URL.
  • If the filtering target is an address starting with http (for example, http://www.huawei.com), you need to enter a string starting with http://.
  • The default HTTP port number is 80, and the default HTTPS port number is 443. If the default port is used, you do not need to configure the port number in a URL filtering rule. If a non-default port is used, the port number is mandatory in a URL filtering rule.

Domain name

RADIUS Server Template

Application Scenario

This template specifies the RADIUS server for interconnection with devices.

Feature Requirements
  • When configuring an SSID for authentication using a RADIUS server, you can select a RADIUS template to specify the RADIUS server associated with the SSID. For details, see Configuring an SSID.
  • Only APs running V200R008C10 and later versions support the Disable RADIUS attributes parameter. The RADIUS attributes supported vary with the AP model. If this parameter is configured in the selected RADIUS template, ensure that the model and version of the target AP meet requirements. Otherwise, the SSID-related service configuration will fail to be delivered. To view RADIUS attributes supported by a device, run the display radius-attribute command in the system view of the device.
  • Only APs running V200R009C00 and later versions support the Set called-station-id attribute value parameter.
  • Real-time accounting is supported only on APs running V200R008C00 and later versions.
Procedure
  1. Choose Design > Basic Network Design > Template Management, from the main menu and click Policy Template. Choose RADIUS Server from the navigation pane.
  2. Click Create, set parameters, and click OK.

Parameter Description
Table 4-152 LAN Policy Template (RADIUS server)

Parameter

Description

Name

Unique identifier of a RADIUS server template.

Use the built-in server

Whether to configure iMaster NCE-Campus as a RADIUS server.

Authentication server

Meaning: Third-party authentication server. You need to specify the IP address, port number, and weight of the authentication server.

Value range:

  • When Server selection policy is set to Primary/Secondary, the server with the largest weight value is the primary server, and other servers are secondary servers.
  • When Server selection policy is set to Load balance, all authentication servers share tasks based on their weights.

Constraints: A maximum of eight authentication servers can be added.

Accounting server

Third-party accounting server. You need to specify the IP address, port number, and weight of the accounting server.

Value range:

  • When Server selection policy is set to Primary/Secondary, the server with the largest weight value is the primary server, and other servers are secondary servers.
  • When Server selection policy is set to Load balance, all authentication servers share tasks based on their weights.

Constraints: A maximum of eight accounting servers can be added.

Authentication component

This parameter needs to be set only when Use the built-in server is toggled on. You can configure either the Service Manager (SM) or a remote server as an authentication component. The SM is the controller deployed at the headquarters.

Server selection policy
  • Primary/Secondary: The authentication and accounting servers work in active/standby mode.
  • Load balance: The authentication and accounting servers work in load balancing mode.

Server selection algorithm
  • Based on the number of packets: Servers are selected based on the number of packets received on servers.
  • Based on the number of subscribers: Servers are selected based on the number of users on servers.

Real-time accounting

Whether to enable real-time accounting. After this function is enabled, you can configure an accounting reporting period. By default, this function is disabled.

Accounting reporting period

Real-time accounting interval.

Key

Shared key of the RADIUS server. You are advised to periodically change the shared key.

Disable RADIUS attributes

Whether to filter specific attributes in the packets exchanged between devices and the RADIUS server. This function is disabled by default, indicating that attributes are not filtered.

Disable attributes

-

Click Create and configure a filtering policy.

Attribute name

Click ... and select the attributes to be filtered in the displayed dialog box.

Disable Sending

The device is disabled from sending packets containing specified RADIUS attributes to the RADIUS server.

Disable Receiving

The device is disabled from receiving packets containing specified RADIUS attributes from the RADIUS server.

Service-Type

-

The value of the same RADIUS attribute may vary on RADIUS servers from different vendors. Therefore, RADIUS attribute values need to be modified, so that a Huawei device can successfully communicate with a third-party RADIUS server.

Attribute value

Specifies the value of service-type attribute to be modified.

Option

Sets the user authentication mode to MAC address authentication.

called-station-id

-

Meaning: After this item is toggled on, you can set the called-station-id attribute value, that is, the content encapsulated in the called-station-id attribute of RADIUS packets.

Constraints: Currently, only APs support this setting.

Default setting: disabled

Attribute value

Content encapsulated in the called-station-id attribute. The value can be ap-mac or ap-location.

Carry SSID attributes

After this function is enabled, the content encapsulated in the called-station-id attribute contains the SSID. By default, this function is disabled.

Attribute separator

Meaning: Delimiter before the SSID when the content encapsulated in the called-station-id attribute contains an SSID.

Constraints: The value is of the enumerated type. It can be one of the following:

\, /, :, <, &gt;, |, @, ', %, *, +, -, &, !, #, ^, and ~.

Default setting: colon (:)

Mac address format setting

MAC address format in RADIUS packets. The following parameters are configurable:

  • MAC address case
  • MAC address separator
  • MAC address format

Server status auto-detection

Username

After this function is enabled, the connectivity between the authentication device and RADIUS server can be detected. You need to set the username and password for automatic RADIUS server detection.

Password

Retransmit authentication requests

Retransmission count

Number of retransmission times if an authentication request times out.

Timeout interval

Timeout interval of an authentication request.

Server down duration

Period during which the authentication server remains Down.

Device source IP address

Meaning: After the function is enabled, you need to configure a device source IP address on the Provision > Physical Network > Site Configuration > Site Configuration > Switch > Advanced > Device Source IP Address Configuration page.

Constraints: This function is supported on switches only.

HWTACACS Server Template

Application Scenario

HWTACACS protects a network from unauthorized access and supports command-line authorization. Compared with RADIUS, HWTACACS is more reliable in transmission and encryption, and is more suitable for security control.

Procedure
  1. Choose Design > Basic Network Design > Template Management, from the main menu and click Policy Template. Choose HWTACACS Server from the navigation pane.
  2. Click Create, set parameters, and click OK.

Parameter Description
Table 4-153 Policy Template (HWTACACS server)

Parameter

Description

Name

Unique identifier of an HWTACACS server template.

Use the built-in server

Meaning: Whether to configure iMaster NCE-Campus as an HWTACACS server.

If this function is enabled, you can configure either the SM or a remote server as the primary or secondary authentication component. The SM is the controller deployed at the headquarters.

Primary authentication server address/Port

Meaning: IP addresses and port numbers of the primary and secondary authentication servers.

Constraints:

If only the address and port number of the primary authentication server are configured and those of the primary authorization server are not specified, authenticated users only have the default device permissions, which can be referred to in the corresponding device product documentation.

Secondary authentication server address/Port

Primary authorization server address/Port

IP addresses and port numbers of the primary and secondary authorization servers.

Secondary authorization server address/Port

Primary accounting server address/Port

IP addresses and port numbers of the primary and secondary accounting servers.

Secondary accounting server address/Port

Include domain names in usernames

Meaning: Whether to include domain names in usernames carried in request packets sent by devices to the TACACS server.

  • If this function is enabled, devices encapsulate domain names in usernames when sending packets to a TACACS server. The default domain name is default_admin.
  • If this function is disabled, devices do not encapsulate domain names in usernames when sending packets to a TACACS server.

Default setting: disabled

Device source IP address

After the function is enabled, you need to configure a device source IP address on the Provision > Physical Network > Site Configuration > Site Configuration > Switch > Advanced > Device Source IP Address Configuration page.

Key

Meaning: Shared key of the HWTACACS server.

Value range: The value is string of 1 to 16 characters, and can contain letters, digits, and special characters.

Constraints: The value cannot contain spaces and question marks (?), and cannot contain only asterisks (*). For security purposes, it is recommended that the key contain at least six characters and contain at least two types of the following: lowercase letters, uppercase letters, digits, and special characters.

Portal Server Template

Application Scenario

This template specifies the Portal server for interconnection with devices.

Procedure
  1. Choose Design > Basic Network Design > Template Management, from the main menu and click Policy Template. Choose Portal Server from the navigation pane.
  2. Click Create, set parameters, and click OK.

Parameter Description
Table 4-154 Policy Template (Portal server)

Parameter

Description

Name

Unique identifier of a Portal server template.

Use the built-in server

Meaning: Whether to configure iMaster NCE-Campus as a Portal server. If this function is enabled, you can configure either the SM or a remote server as an authentication component. The SM is the controller deployed at the headquarters.

The default protocol for pushing Portal pages is HTTPS.

Constraints:

To use HTTP for pushing Portal pages, enable the HTTP port.

Authentication protocol

The options include Portal and HTTP/HTTPS. By default, Portal is selected.

NOTE:

If Authentication protocol is set to HTTP/HTTPS, you need to set Submission mode and Password encoding mode.

  • Submission mode can be set to either POST or GET. By default, POST is selected.
    • Configure the device to allow users to submit username and password information using the GET method during Portal authentication.
    • By default, the device does not allow users to submit username and password information using the GET method during Portal authentication.
  • Password encoding mode can be set to either none or uam. By default, none is selected.
    • none: Passwords are not encoded.
    • uam: Passwords are encoded in ASCII format.

IP address

IP address of a third-party Portal server. Separate multiple IP addresses with commas (,).

Port

Port number of a third-party portal server.

URL

Interface URL of a third-party Portal server to which users requiring Portal authentication have access.

URL parameter profile

URL template to be associated with the Portal server template. If an SSID is associated with this Portal server template, the SSID is also associated with the URL template specified in the Portal server template.

Portal user synchronization

Meaning: Whether to synchronize user information between devices and iMaster NCE-Campus. You can enable this function when Portal 2.0 authentication is configured. The synchronization interval and maximum allowable number of synchronization failures can be set.

Value range: The synchronization interval is in the range from 30 to 65535, in seconds, and its default value is 300. The maximum allowable number of synchronization failures is in the range from 2 to 255 and its default value is 3.

Constraints:

The synchronization interval multiplied by the maximum allowable number of synchronization failures must be greater than the interval at which the Portal server sends synchronization packets to devices. Otherwise, devices will disconnect users if they do not receive any synchronization packet from the Portal server after the maximum allowable number of synchronization failures is reached. The built-in Portal server of iMaster NCE-Campus sends synchronization packets at an interval of 3600 seconds.

Key

Shared key of the Portal server.

Device source IP address

After the function is enabled, you need to configure a device source IP address on the Provision > Physical Network > Site Configuration > Site Configuration > Switch > Advanced > Device Source IP Address Configuration page.

URL Template

Feature Requirements

URL templates are configurable only on APs running V200R008C10 and later versions.

Procedure
  1. Choose Design > Basic Network Design > Template Management, from the main menu and click Policy Template. Choose URL Template from the navigation pane.
  2. Click Create, set parameters, and click Confirm.

Parameter Description
Table 4-155 Policy Template (URL)

Parameter

Description

Name

Unique identifier of a URL template.

Template Type

The options include Cloud platform-based relay authentication and Third-party authentication.

Parameters in template

Value Assignment Mode

Value range:

  • Replace the existing value of the controller: Select an existing parameter on iMaster NCE-Campus.
  • User-defined: Set a parameter as needed.

Constraints: The Value Assignment Mode setting takes effect only when Template Type is set to Cloud platform-based relay authentication.

Parameter
  • ap-mac: AP's MAC address
  • device-mac: MAC address of an authentication device. For common cloud APs, set ap-mac.
  • redirect-url: original URL that a user accesses before redirection
  • ssid: name of the SSID to which a user connects
  • user-ip: user's IP address
  • user-mac: user's MAC address
  • loginurl: user authentication URL provided by the controller
  • ap-location: AP's location information
  • device-ip: IP address of an authentication device. For common cloud APs, set ap-ip.
  • ap-ip: AP's IP address
  • sysname: system name of an authentication device
  • interface: user access interface
  • esn: ESN of an authentication device
  • login-url: login URL of an authentication device, which contains the following information:
    • url-key: identification keyword for the login URL sent to the Portal server during redirection
    • url: specified URL on the access device
NOTE:
  • When Template Type is set to Cloud platform-based relay authentication, Parameter Name is a string of 1 to 64 characters that can contain letters, digits, and underscores (_), and cannot start with a digit.
  • When Template Type is set to Third-party authentication, Parameter Name is a string of 1 to 16 single-byte characters without spaces. Parameter Name for the login-url parameter needs to contain a URL key and a URL separated by space, for example, XX Y.
    • url-key: identification keyword for the login URL sent to the Portal server during redirection. The value is a string of 1 to 16 case-sensitive characters and cannot contain spaces, question marks (?), single quotation marks ('), and equal signs (=).
    • url: specified URL on the access device. The value is a string of 1 to 247 case-sensitive characters without spaces.

Parameter Name

Parameters required for authentication through a third-party Portal server.

RADIUS Relay Server Template

Procedure
  1. Choose Design > Basic Network Design > Template Management, from the main menu and click Policy Template. Choose RADIUS Relay Server from the navigation pane.
  2. Click Create, set parameters, and click OK.

Parameter Description
Table 4-156 Policy Template (RADIUS relay server)

Parameter

Description

Name

Unique identifier of a RADIUS relay server template.

Portal authentication

Authentication server address

Click Add, and configure the priority, IP address, port, and key of an authentication server. You can add up to three authentication servers.

Authentication protocol

The options include Challenge Handshake Authentication Protocol (CHAP) and Password Authentication Protocol (PAP). CHAP is more secure and recommended.

NAS-Identifier

NAS identifier attribute carried in RADIUS relay packets.

  • Controller ID: When the controller relays RADIUS packets, the value of NAS-Identifier in the packets is Huawei Agile Controller-Campus.
  • Device MAC: When the controller relays RADIUS packets, the value of NAS-Identifier in the packets is the device MAC address.

Accounting server address

Click Add, and configure the priority, IP address, port, and key of an accounting server. You can add up to three accounting servers.

Timeout period

Negotiation time for connection to the authentication server and accounting server. After the timeout period expires, the current connection fails.

Resend tries

Number of times a client connects to the authentication server and accounting server.

Load balancing mode

Policy specifying the server to which clients connect if multiple authentication servers or accounting servers are configured.

  • Strict accordance with priority: Clients connect to servers strictly based on server priorities. Only when the server with a higher priority is unreachable, the server with a lower priority is connected.
  • Cycle: Clients connect to servers based on server priorities in cycle mode.

MAC address formatting

MAC address format in RADIUS packets. The following parameters are configurable:

  • MAC address case
  • MAC address separator
  • MAC address format

Source

This parameter needs to be set only when ENABLE_RADIUS_NORTH(enable listen radius relay port on north ip or not) is set to true on the management plane, which is used by the controller to relay messages to external and internal networks at the same time.

RADIUS authentication

Authentication server address

Click Add, and configure the priority, IP address, port, and key of an authentication server. You can add up to three authentication servers.

Accounting server address

Click Add, and configure the priority, IP address, port, and key of an accounting server. You can add up to three accounting servers.

Timeout period

Negotiation time for connection to the authentication server and accounting server. After the timeout period expires, the current connection fails.

Resend tries

Number of times a client connects to the authentication server and accounting server.

Load balancing mode

Policy specifying the server to which clients connect if multiple authentication servers or accounting servers are configured.

  • Strict accordance with priority: Clients connect to servers strictly based on server priorities. Only when the server with a higher priority is unreachable, the server with a lower priority is connected.
  • Cycle: Clients connect to servers based on server priorities in cycle mode.

MAC prioritization

In Portal 2.0 relay authentication scenarios, MAC address-prioritized Portal authentication can be configured in either of the following ways:

  • Forward MAC address-prioritized authentication packets to external RADIUS server
  • Forward MAC address-prioritized accounting packets to external RADIUS server

When MAC address-prioritized authentication packets are forwarded to an external RADIUS server, data source check for MAC address-prioritized Portal authentication can be configured. After MAC address-prioritized Portal authentication and the corresponding data source check are enabled, the controller checks whether the data source of an authentication packet is the same as that of the previously received one. If they are the same, the controller relays the packet to the target RADIUS server. If the data source check is not enabled, the controller sends authentication packets to the same data source as previous ones.

Constraints: MAC address-prioritized Portal authentication cannot be configured on third-party devices in RADIUS relay scenarios.

Advanced

When the controller functions as a relay agent for an external RADIUS server, the authorization information contains the authorization result delivered by the external RADIUS server. In this scenario, dynamic authorization is not supported on the controller and needs to be triggered on the external RADIUS server.

Transfer authorization results: The controller forwards authorization results from the external RADIUS server to target devices.

Incremental authorization: The controller uses the attributes in the packets returned by the external RADIUS server as conditions to match authorization rules, and then performs incremental authorization based on the matching authorization result.

Conditional authorization: The controller uses the attributes in the packets returned by the external RADIUS server as conditions to match authorization rules. If a match is found, the controller delivers the authorization result associated with the matching authorization rule to the target device.

Authentication Template

Application Scenario

By delivering and applying authentication templates to authentication points, the system can implement user access control. A RADIUS server template and a user access template must be bound to a user authentication template, and the authentication mode must be specified.

Feature Requirements

A RADIUS server template and a Portal server template have been created.

Procedure
  1. Choose Design > Basic Network Design > Template Management, from the main menu and click Policy Template. Choose Authentication Template from the navigation pane.
  2. Click Create and set the template name to Authen1. In this template, set the user authentication mode to Portal, MAC, or 802.1X, select the RADIUS server template iMaster_RADIUS, select the Portal server template iMaster_Portal, set the user domain to which the template is applied to Default, retain the default setting of dynamic RADIUS authorization, and select the most suitable bypass policy. If IP phones are connected to the authentication point where this authentication template applies, enable IP phone authentication in the authentication template. Click OK.

Parameter Description
Table 4-157 Policy Template (authentication)

Parameter

Description

Name

Name of an authentication template.

Authentication mode

Value range: The options include Portal, MAC, and 802.1X. You can set this parameter as needed.

Constraints: If Portal authentication with dynamic VLAN authorization is required, select both Portal and MAC.

MAC address bypass authentication

This function can be configured when both MAC and 802.1X are selected for Authentication mode.

Authentication protocol

Meaning: This function can be configured when MAC is selected for Authentication mode.

Value range:

  • CHAP
  • PAP

Carry URL parameters for redirection after authorization

Meaning: In multi-network Portal authentication scenarios, this function needs to be enabled when Portal 2.0 is selected.

RADIUS server template

Select a RADIUS server template.

Primary Portal server template/Secondary Portal server template

Select a Portal server template. This parameter is configurable only when Portal is selected for Authentication mode.

IPv6 terminal authentication

Enable this function if IPv6 terminals need to be authenticated. After this function is enabled, configure an IPv6 URL to be pushed by the Portal server, and disable pushing of IPv4 Portal pages.

Domain

You can use the default value.

IP Phone Authentication

Value range:

  • Enable: If access terminals include IP phones, you need to enable this function.
  • Disable

RADIUS dynamic authorization

Value range:

  • Default
  • Custom

RADIUS dynamic server address

Dynamic RADIUS server IP address. This parameter is configurable only when RADIUS dynamic authorization is set to Custom.

Key

Key for RADIUS dynamic authorization. This parameter is configurable only when RADIUS dynamic authorization is set to Custom.

User access mode

Meaning: User access mode of the interface.

Value range:

  • multi-authen: This is the default mode. The interface allows multiple users to go online. In this mode, the device authenticates each access user. If users pass authentication, the users are given individual network access rights. After a user goes offline, other users are not affected.
  • single-voice-with-data: The interface allows only one data user and one voice user to go online. This mode is used when a data user accesses the network through a voice terminal.
  • single-terminal: The interface allows only one user to go online.

RADIUS bypass policy

Set the RADIUS bypass policy and specify the VLAN or bypass policy template used by users to bypass.

VLAN

Bypass policy

Automatic re-authentication

Meaning: Whether to re-authenticate a terminal if the terminal failed to be authenticated. If this function is enabled, after the time period specified by Re-authentication interval, iMaster NCE-Campus re-authenticates terminals that failed to be authenticated previously.

Value range: The re-authentication interval is in the range from 30 to 7200, in seconds.

Configuring a Security Profile

Application Scenario

You need to create a security profile if you want to add it when creating a security policy.

Profile Type

Description

Antivirus

Antivirus profiles are used to inspect files transmitted on the network for viruses to protect internal networks from data breaches and system crashes caused by viruses.

When a firewall detects that the file transferred is a virus-infected file, it performs the following operations:

  1. Checks whether this virus is an exception. If so, the file is permitted.

    To prevent file transfer failures resulting from false positives, whitelist virus IDs that users identify as false positives are added to exceptions to disable the virus rules. If the detected virus matches a virus exception, the response action on the file is permit.

  2. If the virus does not match any virus exception, check whether it matches an application exception. If it matches an application exception, it is processed according to actions (permit, alert, or block) for application exceptions.

    The action of an application exception can be different from that for the protocol used by the application. Multiple applications may use a same protocol. For example, traffic of 163.com and 126.com is transmitted over HTTP.

    Actions for applications and protocols have different priorities:

    • If the action for a protocol is defined but no action is defined for any application, the action for the protocol applies to all applications that use the protocol.

    • If the response action for a protocol and the response action for an application that uses the protocol are both configured, the response action for the application takes precedence over that for the protocol.

  3. If the virus matches neither virus exceptions nor application exceptions, the action for protocol and transfer direction specified in the profile applies.

Intrusion prevention

Intrusion prevention is a security mechanism that detects intrusions (including buffer overflow attacks, Trojan horses, and worms) by analyzing network traffic, and terminates intrusion behavior in real time using certain response methods, protecting enterprise information systems and network architectures from being attacked.

The intrusion prevention function compares traffic with intrusion prevention signatures to prevent application-layer attacks.

URL filtering

A URL filtering profile permits or denies access to URLs to control the online behavior of users.

Feature Requirements

After a device is managed by the controller, the device does not have an audit administrator account in cloud-based management mode. Therefore, the attack evidence collection function of antivirus and intrusion prevention cannot be used in cloud-based management mode.

Procedure
  1. Choose Design > Basic Network Design > Template Management from the main menu.
  2. Click the Policy Template tab and choose Security Profiles from the navigation pane.
  3. Configure an antivirus profile.

    1. Click the Antivirus tab and click Create.
    2. Configure basic information.

    3. Set application exceptions and virus exceptions.

  4. Configure an intrusion prevention profile.

    1. Click the Intrusion Prevention tab and click Create.
    2. Set intrusion prevention parameters.

  5. Configure a URL filtering profile.

    1. Click the URL Filtering tab and click Create.
    2. Set basic parameters.

    3. Configure the URL filtering level.

Parameter Description
Table 4-158 Parameters for creating an antivirus profile

Parameter

Description

Basic Information

Attack Evidence Collection

If this parameter is set to Enable, the system captures infected data packets from the device upon detecting viruses and records packet content in the logs.

The attack evidence collection function relies on hard disks and available only when the hard disks are installed on the firewall.

File reputation detection

This function depends on the firewall-sandbox interworking function to detect malicious files. That is, after the file reputation detection function is enabled in the antivirus profile, the firewall processes malicious files detected by the sandbox.

Enabling file reputation detection deteriorates virus detection performance.

Protocol

Select target protocols for virus inspection. They include:

  • File transfer protocols: HTTP and FTP
  • Mail transfer protocols: SMTP, POP3, and IMAP
  • Share protocols: NFS and SMB

Upload

Upload traffic is inspected.

Download

Download traffic is inspected.

Action

Action taken by the firewall when a virus is detected. It can be:

  • Alert: The device permits virus-infected files and generates virus logs.

  • Block: The device blocks virus-infected files and generates virus logs.

  • Declare: For virus-infected email messages, the device permits them but adds information to their subjects to announce the detection of viruses and generates virus logs. This action applies only to SMTP, POP3, and IMAP.

  • Delete Attachment: For virus-infected email messages, the device deletes their attachments, adds information to their subjects to announce the detection of viruses, permits them, and generates virus logs. This action applies only to SMTP, POP3, and IMAP.

Application Exception List: The action for an application exception prevails if the application uses any protocol mentioned previously.

Available Application Exception

Select applications to be inspected.

Action

Action taken by the firewall when a virus is detected. It can be:

  • Allow: The device permits virus-infected files and does not generate virus logs.
  • Alert: The device permits virus-infected files and generates virus logs.
  • Block: The device blocks virus-infected files and generates virus logs.

Virus Exception List

ID

Exception virus ID to be added.

Operation

Lock

After a policy is locked, this policy can be modified only by the admin user or the user who locks the policy.

Unlock

Unlocks a policy.

Clean Unused

If a profile is not referenced, you can manually delete it. For the profiles that have been delivered to the firewall, you can delete them by delivering full configurations.

Delete

Deletes a profile. For the profiles that have been delivered to the firewall, you can delete them by delivering full configurations.
Table 4-159 Parameters for creating an intrusion prevention profile

Parameter

Description

Basic Information

Attack forensics

If this parameter is set to Enable, the system captures matched data packets from the device upon detecting threats and records packet content in the logs.

The attack evidence collection function depends on a firewall hard disk and is available only when a hard disk is available. A software firewall does not support this function.

Domain name check

If this parameter is set to Enable, the domain name–based filtering function compares domain names against the malicious domain name signature database. You can set the action to Alert or Block for matched domain names. Upon receiving a packet matching a malicious domain name, the device implements the specified action and logs the threats.

Signature Filter List: This parameter allows you to filter signatures that meet a specific need.

Target

Target object that matches the signatures to be added to the signature filter list.

  • Server: indicates the end that accepts the access. This parameter is used to detect attacks that exploit vulnerabilities of servers.
  • Client: indicates the end that initiates the access. This parameter is used to detect attacks that exploit vulnerabilities of clients, such as PCs.

Severity

Signatures are filtered by severity.

OS

Signatures are filtered by OS.

Action

Action for a signature filter.

  • Action of the matched signature: When a packet matches a signature in the signature filter, the action for the signature is performed.
  • Alert: The action for a signature filter is alert if a packet matches any signature in the signature filter. The actions for the signatures in the signature filter do not apply.
  • Block: The action for a signature filter is block if a packet matches any signature in the signature filter. The actions for the signatures in the signature filter do not apply.

Protocol

Signatures are filtered by protocol.

The protocols in predefined signatures are dynamically generated by the intrusion prevention signature database.

Category

Signatures are filtered by threat category.

The threat categories in predefined signatures are dynamically generated by the intrusion prevention signature database. The threat categories in user-defined signatures are dynamically generated by the system.

Signature Exception List: A separate action is specified in an exception signature for a specific signature. The priority of an exception signature is higher than that of the signature filter.

Available signatures

Enter or select the exception signature to be added and click OK.

Action

  • Default: The device permits the matched packets and does not generate logs.

  • Alert: The device permits the matched packets and generates logs.

  • Block: The device discards the matched packets, blocks the data flow to which the packets belong, and generates logs.

  • Block+Isolation (Source IP): The device discards the matched packets, blocks the data flow to which the packets belong, generates logs, and blacklists the source IP addresses of these packets.

  • Block+Isolation (Destination IP): The device discards the matched packets, blocks the data flow to which the packets belong, generates logs, and blacklists the destination IP addresses of these packets.

Operation

Lock

After a policy is locked, this policy can be modified only by the admin user or the user who locks the policy.

Unlock

Unlocks a policy.

Clean Unused

If a profile is not referenced, you can manually delete it. For the profiles that have been delivered to the firewall, you can delete them by delivering full configurations.

Delete

Deletes a profile. For the profiles that have been delivered to the firewall, you can delete them by delivering full configurations.
Table 4-160 Parameters for creating a URL filtering profile

Parameter

Description

Basic Information

Encrypted traffic filtering

If it is selected, URL filtering can be performed on encrypted HTTPS traffic.

Safe search

If it is selected, the safe search function on the search engine is enabled.

Action mode

Select Strict or Loose.

The priorities of URL matching modes are as follows: exact matching > suffix matching > prefix matching > keyword matching. In the same matching mode, a longer matching rule has a higher priority. If the matching rules have the same length, the configured action mode is used to determine the rule that a URL matches.

  • If the action mode is strict mode, the URL will match the category with a stricter action.

  • If the action mode is loose mode, the URL will match the category with a looser action.

Default action
  • Allow: The device permits virus-infected files and does not generate any virus filtering log.
  • Alert: The device permits virus-infected files and generates virus filtering logs.
  • Block: The device blocks virus-infected files and generates virus filtering logs.

Malicious URL detection

It is used to detect malicious URLs.

Type

The URL and HOST parameters are used as Whitelist or Blacklist.

URL Filtering Level

URL Filtering Level
  • High: strictly restricts access to all adult websites, illegal website activities, social networks, and video sharing websites.
  • Medium: controls access to all adult websites and illegal websites.
  • Low: controls access to pornography websites.
  • User-defined: customizes a priority.

User-defined Category

You can select Allow, Alert, and Block for this category. You can also select User-defined to configure separate actions.

Operation

Lock

After a policy is locked, this policy can be modified only by the admin user or the user who locks the policy.

Unlock

Unlocks a policy.

Clean Unused

If a profile is not referenced, you can manually delete it. For the profiles that have been delivered to the firewall, you can delete them by delivering full configurations.

Delete

Deletes a profile. For the profiles that have been delivered to the firewall, you can delete them by delivering full configurations.

Bypass Policy Template

Application Scenarios

You can configure a bypass policy to ensure basic network access of users in the case of a network fault or when the Huawei cloud platform is being upgraded.

Procedure
  1. Choose Design > Basic Network Design > Template Management, from the main menu and click Policy Template. Choose Bypass Policy Template from the navigation pane.
  2. Click Create, set parameters, and click OK.

Parameter Description
Table 4-161 Policy Template (bypass policy template)

Parameter

Description

Name

Name of a bypass policy template.

VLAN ID

VLAN used by users who bypass authentication.

Security Group

Security group authorized to users who bypass authentication.

IPv4/IPv6 rule

Protocol

Meaning: Network access rights granted to users who bypass authentication. Use ACL rules to define protocol types, IP addresses, and port numbers.

Constraints: The port number is configurable only when Protocol is set to TCP or UDP.

IP

Port
Table 4-162 Policy Template (security group)

Parameter

Description

Name

Name of a security group.

Description

Security group description.

Security Zone Profile

Procedure
  1. Choose Design > Basic Network Design > Template Management, from the main menu and click Policy Template. Choose Security Zone Profile from the navigation pane.
  2. Click Create, set parameters, and click OK.

Parameter Description
Table 4-163 Policy Template (security zone profile)

Parameter

Description

Name

Unique identifier of a security zone profile.

Description

Description of the security zone profile.

Priority

Meaning: Priority of a security zone. In a VPN instance, each security zone has a globally unique security priority. That is, two security zones with the same security priority do not exist in a VPN instance. The security priority ranges from 1 to 100. A larger value indicates a higher security priority.

Address Set Profile

Procedure
  1. Choose Design > Basic Network Design > Template Management, from the main menu and click Policy Template. Choose Address Set Profile from the navigation pane.
  2. Click Create, set parameters, and click OK.

Parameter Description
Table 4-164 Policy Template (address set profile)

Parameter

Description

Name

Unique identifier of an address set profile.

Description

Description of an address set profile.

Address type

Address object: An address set profile of this type can contain an IP address, a subnet, an IP address range, a MAC address, or a combination of any of these.

Address group: An address set profile of this type can contain not only an IP address, a subnet, an IP address range, or a combination of any of these, but also other address set profiles. The nested address set profiles can be either of the address object type or address group type.

IP address/MAC address

Address objects can be classified into the following types:

  • IP address: For example, 192.168.1.1 with the wildcard of 0 indicates a host.
  • Subnet: Subnets can be specified by subnet masks or wildcards.
    • Subnet mask: A subnet mask can be expressed in dotted decimal notation or mask length, such as 192.168.1.0 255.255.255.0 or 192.168.1.0 24.
    • Wildcard mask: A wildcard mask can be thought of as an inverted subnet mask. For example, in 192.168.1.0 0.0.0.255, 0.0.0.255 is the wildcard mask. A subnet mask of 255.255.255.0 (binary equivalent = 11111111.11111111.11111111.00000000) inverts to a wildcard mask of 0.0.0.255 (binary equivalent = 00000000.00000000.00000000.11111111). A wildcard mask in binary format is a matching rule. The rule for a wildcard mask is: 0 means that the equivalent bit must match (such as source IP addresses) and 1 means that the equivalent bit does not matter. Therefore, 192.168.1.0 0.0.0.255 indicates that packets whose source IP address is 192.168.1.* can be matched.
  • IP address range: An IP address range is specified by start and end IP address, and contains consecutive IP addresses.
  • MAC address: For example, 0018-8200-0111.

Traffic Classifier Template

Procedure
  1. Choose Design > Basic Network Design > Template Management, from the main menu and click Policy Template. Choose Traffic Classifier Template from the navigation pane.
  2. Click Create, set parameters, and click OK.

    You can use this template for configuring traffic policies on switches.

Parameter Description
Table 4-165 Policy Template (traffic classifier)

Parameter

Description

Name

Unique identifier of a traffic classifier.

Description

Description of the traffic classifier.

Operator

Value range:

And: indicates that the relationship between rules in a traffic classifier is AND. That is, packets match a traffic classifier only when they match all rules in the traffic classifier.

Or: indicates that the relationship between rules in a traffic classifier is OR. That is, packets match a traffic classifier as long as they match one or more rules in the traffic classifier.

IPv4 Rule

Priority

Rule priority in a traffic classifier. A smaller value indicates a higher priority. The priority value must be unique.

Protocol

Protocol of the packets matching the rule. The options include:

  • TCP
  • UDP
  • ICMP
  • Any

Source IP Address

Source IP address of the packets matching the rule.

Destination IP Address

Destination IP address of the packets matching the rule.

Source Port

Meaning: Source port number of the packets matching the rule.

Constraints: This parameter is configurable only when Protocol is set to TCP or UDP.

Destination Port

Meaning: Destination port number of the packets matching the rule.

Constraints: This parameter is configurable only when Protocol is set to TCP or UDP.

VLAN

Start VLAN ID

Start outer VLAN ID.

End VLAN ID

End outer VLAN ID. The end outer VLAN ID must be greater than the start outer VLAN ID.

DSCP Priority

DSCP priority.

Traffic Behavior Template

Procedure
  1. Choose Design > Basic Network Design > Template Management, from the main menu and click Policy Template. Choose Traffic Behavior Template from the navigation pane.
  2. Click Create, set parameters, and click OK.

    You can use this template for configuring traffic policies on switches.

Parameter Description
Table 4-166 Policy Template (traffic behavior)

Parameter

Description

Name

Unique identifier of a traffic behavior.

Description

Description of a traffic behavior.

Action

Traffic rate limiting

CIR(kbit/s)

Committed information rate (CIR): indicates the rate at which tokens are put into bucket C, that is, the average traffic rate that bucket C allows.

PIR(kbit/s)

Peak information rate (PIR): indicates the rate at which tokens are put into bucket P, that is, the maximum traffic rate that bucket P allows. The PIR is greater than the CIR.

CBS(Byte)

Committed Burst Size (CBS): indicates the capacity of bucket C, that is, the maximum volume of burst traffic that bucket C allows.

PBS(Byte)

Peak burst size (PBS): indicates the capacity of bucket P, that is, the maximum volume of burst traffic that bucket P allows.

Priority

Local priority

Internal precedence of the device, which identifies the class of service (CoS) of packets.

DSCP priority

DSCP precedence used to specify the QoS priority of packets on IP networks.

802.1p priority

802.1p priority used to specify the QoS priority of packets on VLAN networks.

Redirection

Next hop

Next-hop IP address.

Application Management

Procedure
  1. Choose Design > Basic Network Design > Template Management, from the main menu and click Policy Template. Choose Application Management from the navigation pane.
  2. (Optional) Click the HQoS Application tab, click Create, set parameters as needed, and click OK.

  3. (Optional) Click the Service Awareness Application tab, click Create, set parameters as needed, and click OK.

Parameter Description
Table 4-167 Policy Template (application management)

Parameter

Description

Name

Unique identifier of an application management template.

Description

Description of the application management template.

Rule list (HQoS Application)

IP/Domain

IP address or domain name of application packets matching the rule.

Protocol
  • TCP
  • UDP
  • ALL

Port

This parameter needs to be set when Protocol is set to TCP or UDP.

Rule list (SA Application)

Name

Unique identifier of an application management rule.

Destination IP Address/Destination Port

Destination IP address and port number of application packets matching the rule.

Protocol
  • TCP
  • UDP
  • ALL

Signature

If this function is enabled, Content, Direction, Plaintext String and Description need to be set.

Content
  • Flow
  • Packet

Direction
  • Both
  • Request
  • Response

Plaintext String

The value can contain 3 to 128 characters.

Description

Description of the application management rule.

Application Scheduling Template

Procedure
  1. Choose Design > Basic Network Design > Template Management, from the main menu and click Policy Template. Choose Application Scheduling Template from the navigation pane.
  2. Click Create, set parameters, select customized application management templates as needed, and click OK.

    You can use this template for configurations on the Admission > Admission Policy > Authentication and Authorization > Authorization Result page.

Parameter Description
Table 4-168 Policy Template (application scheduling)

Parameter

Description

Name

Unique identifier of an application scheduling template.

Description

Description of the application scheduling template.

Application scheduling queue

Guaranteed bandwidth

Minimum bandwidth assured for an application.

Soft GRE Template

Procedure
  1. Choose Design > Basic Network Design > Template Management, from the main menu and click Policy Template. Choose Soft GRE from the navigation pane.
  2. Click Create, set parameters, and click OK.

Parameter Description
Table 4-169 Parameters in a soft GRE template (LAN)

Parameter

Description

Name

Name of a soft GRE template.

Tunnel destination address

Destination IP address of the soft GRE tunnel, that is, the peer IP address of the soft GRE tunnel.

Tunnel heartbeat detection

Whether to enable keepalive detection for the soft GRE tunnel.

Tunnel heartbeat detection interval (s)

Interval for sending keepalive packets over the soft GRE tunnel.

This parameter is configurable only when Tunnel heartbeat detection is enabled.

Retry times upon detection failure

Maximum number of times that keepalive packets are retransmitted over the soft GRE tunnel.

This parameter is configurable only when Tunnel heartbeat detection is enabled.

Untagged VLAN

ID of the VLAN whose tag is to be removed from packets sent by APs over the soft GRE tunnel.

Signature Configuration Template

Feature Requirements

Pre-defined signatures are stored in the database and may contain Internet domain names or command examples. Signatures in the IPS signature database are used to deliver policies to devices for policy configuration.

Procedure
  1. Choose Design > Basic Network Design > Template Management, from the main menu and click Policy Template. Choose Signature from the navigation pane. Click the button in the red box and disable New Engine as prompted, and then set the IPS engine mode on the controller to the original IPS engine mode. This ensures that the IPS engine modes of the device and controller are consistent.

  2. Click Create and set parameters in the Basic Information and Basic Feature areas.

  3. Click Create in the Rule area to configure a signature rule. Click to view the online syntax manual for details about how to configure rules.

    If the new IPS engine mode is set on the controller, the page for configuring signature rules will be different from the following figure.

  4. Click OK.

IGMP Snooping Profile

Fundamentals

Internet Group Management Protocol Snooping (IGMP snooping) is an IPv4 Layer 2 multicast protocol. With IGMP snooping, a Layer 2 multicast device analyzes IGMP messages exchanged between an upstream router and user hosts to create and maintain a Layer 2 multicast forwarding table. The device uses then these entries to control multicast packet forwarding. In this way, it prevents multicast data from being broadcast on Layer 2 networks. This not only saves network bandwidth, but also ensures network security. To configure IGMP snooping in VNs, you need to define and deploy an IGMP snooping template.

IGMP snooping is a basic Layer 2 multicast function that forwards and controls multicast traffic at the data link layer. IGMP snooping runs on a Layer 2 device and analyzes IGMP messages exchanged between a Layer 3 device and hosts to create and maintain a Layer 2 multicast forwarding table. Based on this table, the Layer 2 device forwards multicast packets at the data link layer.

In the following figure, after receiving multicast packets from a Layer 3 multicast device (Router), a Layer 2 multicast device (Switch) at the edge of the access layer forwards the multicast packets to receiver hosts, so that the receivers can watch the ordered programs. If Switch does not run IGMP snooping, it broadcasts multicast packets at Layer 2. After IGMP snooping is configured, Switch forwards multicast packets only to specified hosts.

With IGMP snooping configured, Switch listens to IGMP messages exchanged between hosts and the upstream Layer 3 device. It analyzes packet information (such as the packet type, group address, and receiving interface) to set up and maintain a Layer 2 multicast forwarding table, based on which it forwards multicast packets at the data link layer.

Figure 4-81 Multicast packet forwarding before and after IGMP snooping is configured on a Layer 2 device
Procedure
  1. Choose Design > Basic Network Design > Template Management, from the main menu and click Policy Template. Choose IGMP Snooping Profile from the navigation pane.
  2. Click Create to create an IGMP snooping profile. Set the profile name to iMaster_IGMP_Snooping, enable Discard unknown multicast packets and Fast leave, set Aging time of dynamic router interfaces (s) to 180, set Query message sending interval (s) to 125, set IGMP robustness variable to 2, and set Maximum response time (s) to 10. Click OK.

Parameter Description
Table 4-170 Policy Template (IGMP snooping)

Parameter

Description

Name

Meaning: Name of an IGMP snooping profile.

Constraints:

  • The value is a character string.
  • The value can contain 1 to 32 characters.
  • The value can contain letters, digits, underscores (_), hyphens (-), at signs (@), and periods (.).

IGMP version

Meaning: Version of IGMP messages that can be processed.

  • Version 1: Only IGMPv1 messages can be processed.

  • Version 2: Both IGMPv1 and IGMPv2 messages can be processed.

  • Version 3: IGMPv1, IGMPv2, and IGMPv3 messages can be processed.

Discard unknown multicast packets

Meaning:

  • If this function is enabled, the device will discard unknown multicast packets upon receipt.
  • If this function is disabled, the device will broadcast unknown multicast packets upon receipt.

Fast leave

Meaning: Whether to allow member interfaces in a VLAN or BD to fast leave multicast groups.

The fast leave function enables the switch to delete the multicast forwarding entry of a multicast group from an interface immediately after the interface receives an IGMP Leave message for the group. This function saves bandwidth and system resources because the switch does not need to wait until the aging timer of the interface expires.

Suppress Report and Leave messages

Meaning: Whether to enable suppression of IGMP Report and Leave messages in a VLAN or BD.

Default setting: The default IGMP message suppression period is 10 seconds.

After this function is enabled on a Layer 2 device, during the suppression period, the device forwards only one IGMP Membership Report message to the upstream device in the following scenarios: When the first member joins a multicast group or a host sends a Report message in response to an IGMP Query message, the Layer 2 device forwards a Report message to the upstream device. When the last member of a multicast group leaves the group, the Layer 2 device forwards a Leave message to the upstream device. This reduces the number of IGMP messages on the network.

Router-Alert option check

Meaning: Whether to enable the device to check messages for the Router-Alert option and discard IGMP messages without the Router-Alert option.

The Router-Alert option identifies the protocol messages that need to be processed by upper-layer routing protocols.

Disable users from dynamically joining multicast groups

Meaning: Whether to disable devices from forwarding IGMP Report and Leave messages that are received in a VLAN or BD and contain a static group address to upstream Layer 3 devices configured with the static group address.

Constraints: If the upstream device is a non-Huawei device and has static multicast groups configured on interfaces, multicast users are not allowed to dynamically join or leave multicast groups. In this case, disable the Layer 2 device from sending IGMP Report and Leave messages carrying static group addresses to the upstream device.

Aging time of dynamic router interfaces (s)

Meaning: Aging time of dynamic routed interfaces in a VLAN or BD.

Value range: The value is an integer in the range from 1 to 1000, in seconds.

Query message sending interval (s)

Interval for sending IGMP General Query messages in a VLAN or BD. The value is an integer in the range from 1 to 65535, in seconds.

IGMP robustness variable

Meaning: IGMP robustness variable in a VLAN or BD, which indicates how many times IGMP Query messages are sent.

Value range: The value is an integer in the range from 2 to 5.

Maximum response time (s)

Meaning: Maximum response time for a host to respond to an IGMP General Query message.

Value range: The value is an integer in the range from 1 to 25, in seconds.

Default setting: 10 seconds

Configuring an SNMP Template

Fundamentals

  • Protocol template: Protocol parameters are configured in templates (for example, SNMP parameter template) so that iMaster NCE-Campus can uniformly configure protocol parameters for multiple devices.
  • Table 4-171 shows the mapping between authentication protocols and HMAC.
    Table 4-171 Mapping between the authentication protocol and HMAC

    Authentication Protocol

    HMAC

    SHA2-256

    HMAC192SHA256

    SHA2-384

    HMAC256SHA384

    SHA2-512

    HMAC384SHA512

Feature Requirements

  • Users with the admin permission can delete all protocol templates. Common users can delete the protocol templates created by themselves and the protocol templates whose access modes are public.
  • By default, only SNMPv3 and the corresponding security algorithm are enabled on iMaster NCE-Campus. After the insecure SNMP algorithm is enabled, you can select an insecure algorithm corresponding to SNMPv1, SNMPv2c, or SNMPv3. Insecure SNMP protocols or algorithms have security risks. Exercise caution when using them.

Prerequisites

  • The HMAC corresponding to the required authentication protocol is supported on the device. For example, if the SHA2-256 authentication protocol is required, HMAC192SHA256 is supported on the device.
  • You have obtained the information about NE port number, Authentication, Authentication password, Data encryption, Encryption password, Username, Context and Engine ID from devices.

Application Scenario

This section describes how to configure SNMP parameters for the communication between devices and iMaster NCE-Campus. You can use a template to configure SNMP parameters for multiple devices in a unified manner.

Procedure

  1. Choose Design > Basic Network Design > Template Management > SNMP Template from the main menu.
  2. Click Create.
  3. Set SNMP parameters according to Table 4-172.

    Table 4-172 Parameters for creating an SNMP template

    Parameter

    Description

    Template name

    Meaning: Name of an SNMP template, which can be customized.

    NE port number

    Meaning: Port used for communication between devices.

    Value range: 1 to 65535

    SNMP version

    SNMP version.

    Default value: SNMPv3

    Security level

    Security level of SNMP, the default value is With authentication and encryption.

    Authentication

    Meaning: Protocol used for message authentication.

    Value range:

    • SHA-512
    • SHA-384
    • SHA-256

    Authentication password

    The password must meet the following requirements:

    • Cannot contain the username.
    • Cannot contain the reverse of the username.
    • Contain 10 to 32 characters.
    • Cannot contain two consecutive identical characters.
    • Contain at least one of the following characters: spaces and special characters, including !"#$%&'()*+,-./:;<=>?@[\]^`{_|}~
    • Contain at least one uppercase letter (A to Z), one lowercase letter (a to z), and one digit (0 to 9).
    • Must be different from the latest 3 historical passwords.

    Data encryption

    Meaning: Encryption protocol used for data encapsulation.

    Value range:

    • AES-256
    • AES-192
    • AES-128

    Encryption password

    The password must meet the following requirements:

    • Cannot contain the username.
    • Cannot contain the reverse of the username.
    • Contain 10 to 32 characters.
    • Cannot contain two consecutive identical characters.
    • Contain at least one of the following characters: spaces and special characters, including !"#$%&'()*+,-./:;<=>?@[\]^`{_|}~
    • Contain at least one uppercase letter (A to Z), one lowercase letter (a to z), and one digit (0 to 9).
    • Must be different from the latest 3 historical passwords.

    Username

    Username for accessing the device.

    Context

    Name of the environment engine.

    Engine ID

    Unique ID of the SNMP engine.

    Timeout period (s)

    Meaning: Upper limit of the time that iMaster NCE-Campus takes to perform an SNMP operation on a device. If the time that iMaster NCE-Campus takes to perform an SNMP operation on a device reaches the value of this parameter, iMaster NCE-Campus abandons this operation.

    Constraints:

    If the quality of the network between iMaster NCE-Campus and the device is low, you can set this parameter to a large value to improve the success rate of SNMP operations.

    Default value: 10

    Polling interval (s)

    Meaning: Interval between two polling operations of SNMP.

    Default value: 1800

    Maximum retry times

    Meaning: Maximum number of times that iMaster NCE-Campus attempts to perform an SNMP operation on a device. If the number of times that iMaster NCE-Campus attempts to perform an SNMP operation on a device reaches the value of this parameter, iMaster NCE-Campus abandons this operation.

    Constraints:

    If the quality of the network between iMaster NCE-Campus and the device is low, you can set this parameter to a large value to improve the success rate of SNMP operations.

    Default value: 5

  4. Click OK.

Related Tasks

  • Modify an SNMP template.

    To modify an added SNMP template, click in the Operation column of the SNMP template.

  • Delete an SNMP template.

    To delete an added SNMP template, click in the Operation column of the SNMP template.

  • View the number of devices associated with the SNMP template and device information.

    To view the number of devices associated with an SNMP template and device information, click the value in the Associated Devices column of the SNMP template in the SNMP template list.

  • Enable insecure SNMP configuration items.

    Log in to iMaster NCE-Campus as the system administrator, choose System > System Management > Configuration Item Management from the main menu, choose SNMP Configuration from the navigation pane, and select Enable in the Operation column.

    By default, only the SNMPv3 protocol and corresponding security algorithms are enabled on the iMaster NCE-Campus. After the insecure SNMP algorithm is enabled, you can select an insecure algorithm corresponding to SNMPv1, SNMPv2c, or SNMPv3.

    Using insecure SNMP protocols or algorithms has security risks. Exercise caution when using them.

Configuring a NETCONF Template

Fundamentals

NETCONF

The Network Configuration Protocol (NETCONF) was defined by the IETF in 2006. It provides a set of approaches for Network Management Systems (NMSs) to query, add, modify, and delete network device configurations.

Compared with SNMP, NETCONF has the following advantages:

  • Uses XML as the encoding format for protocol messages and configuration data, which is extensible.
  • Supports multiple configuration data sets, for example, there can be two configuration data sets, one for device running and the other for device startup.
  • Verifies configuration data to ensure correctness.
  • Supports rollback and undo upon error.
  • Adopts an object-based modeling approach, and delivers multiple configurations over one interaction, which is efficient.
  • Supports multiple security protocols such as Secure Shell (SSH) and Transport Layer Security (TLS).

It is also convenient to develop an automated configuration management tool based on NETCONF.

Application Scenario

When an NE is manually created or automatically searched for, the specified NETCONF access protocol parameter template is used to adapt to the specified NE to determine the protocol parameters supported by the managed NE. The adapted NETCONF parameter template becomes the NETCONF parameter configuration of the NE. The NETCONF parameter is used to implement basic management functions such as service configuration data synchronization, fault management, and performance management of the NE.

Prerequisites

Ensure that NETCONF parameters with the same settings on iMaster NCE-Campus have been configured on the NE. For details about how to configure NETCONF on NEs, refer to the corresponding NE configuration manual.

Procedure

  1. Choose Design > Basic Network Design > Template Management and choose NETCONF Template from the navigation pane. Then click Create.
  2. Set NETCONF template parameters.

    Table 4-173 NETCONF template parameters

    Parameter

    Description

    Setting Method

    Template Name

    Name of a NETCONF parameter template.

    Enter the value manually.

    Template Type

    Specifies the type of the NETCONF parameter template.

    • Public indicates that all users can view and use the protocol template.
    • Private indicates that the template creator and users with the admin permission can view and use the protocol template.

    Set this parameter through the check box.

    Template Description

    Briefly describe the template.

    Enter the value manually.

    Port

    Port used by devices to communicate with iMaster NCE-Campus.

    Enter the value manually.

    Login timeout

    Timeout interval for logging in to the device.

    Enter the value manually.

    Response Timeout

    Device response timeout interval.

    Enter the value manually.

    Authentication Mode

    Meaning: Authentication mode used by iMaster NCE-Campus to communicate with devices.

    Value range: User authentication, key authentication, and key and password authentication are supported.

    Default value: user authentication

    Select an option from the drop-down list box.

    User name

    User name for logging in to the device.

    Enter the value manually.

    Password

    Meaning: Password for logging in to the device.

    Constraints:

    This parameter is valid only when Authentication Mode is set to User Authentication or Key and Password Authentication.

    Click .... In the dialog box that is displayed, enter the password and click OK.

    Private Key

    Meaning: Private key for logging in to the device.

    Constraints:

    This parameter is valid only when Authentication Mode is set to Key Authentication or Key and Password Authentication.

    Click .... In the dialog box that is displayed, enter the key or click Import to import the key file. If the private key has a password associated with it, click ... in the Set Private Key dialog box to set the password.

  3. Click Apply to save the template.

Related Tasks

  • Modify a NETCONF template: In the Operation column for the desired template, click and modify the template. The template name cannot be changed.
  • Delete a NETCONF template: In the Operation column for the desired template, click to delete the template. Alternatively, select one or more templates to be deleted and click Delete.

Configuring a PON Global Template

Traffic Template

The iMaster NCE-Campus allows you to configure a traffic profile to limit the upstream or downstream traffic rate.

Prerequisites

eSight is running properly.

Procedure
  1. Choose Design > Basic Network Design > Template Management from the main menu and click the Policy Template tab.
  2. Choose Traffic Template from the navigation pane.

    100M, 200M, 500M, and Voice_Traffic_Template are default traffic templates and cannot be deleted.

  3. Click Create. Set Template Name, Description, and parameters in the Speed Limit Configuration and Priority Configuration areas.

    • The value of PIR changes with the entered value of CIR and is twice the input value of CIR by default. Deselect Default before the PIR parameter to configure the parameter.
    • If the entered values of CIR and PIR are not multiples of 64, the system automatically adjusts the values to the nearest multiples of 64.

  4. Click Confirm. If the information about the added traffic template is displayed in the traffic template list, the traffic template is added successfully.
  5. On the Traffic Template page, you can perform the following operations:

    • Click in the Operation column to delete a single record.
    • Select the template to be deleted and click to delete the template information.
    • Click in the Operation column to modify traffic template parameters.
    • Click to copy the traffic template. You can modify the traffic template to create a traffic template.
      • Templates bound to devices or referenced by ZTP policies cannot be deleted.
      • Templates bound to devices or referenced by ZTP policies cannot be modified.

MxU Configuration Template

This section describes how to create an MxU configuration template to configure parameters, such as the MxU IP address pool and SNMP. To add an IP address segment to an ONU IP address pool, you can use an IP address from the IP address pool to automatically allocate an IP address to an MxU.

Prerequisites
  • eSight is running properly.
  • The start IP address, end IP address, ONU mask, ONU gateway, SNMP template, SNMP trap destination IP address, and SNMP trap destination port have been obtained before an MxU configuration template is added.
Procedure
  1. Choose Design > Basic Network Design > Template Management from the main menu and click the Policy Template tab.
  2. Choose MxU Configuration Template from the navigation pane.

    Click a template name to view details about the MxU configuration template.

  3. Click Create. Set parameters in the Template Information, IP Address Pool, and SNMP Settings areas.

    In MxU configurations, SNMP configurations do not support SNMP templates with Chinese names.

  4. Click Confirm. If the information about the added template is displayed in the MxU configuration template list, the template is added successfully.
  5. On the MxU Configuration page, you can perform the following operations:

    • Click in the Operation column to delete a single record.
    • Select the template to be deleted and click to delete the template information.
    • Click in the Operation column to modify traffic template parameters.
    • Click to copy the traffic template. You can modify the traffic template to create a traffic template.
      • Templates bound to devices or referenced by ZTP policies cannot be deleted.
      • Templates bound to devices or referenced by ZTP policies cannot be modified.

Voice User Configuration Template

The iMaster NCE-Campus uses voice VLAN channels to deliver voice user parameters to ONUs in polling mode.

Prerequisites

eSight is running properly.

Procedure
  1. Choose Design > Basic Network Design > Template Management from the main menu and click the Policy Template tab.
  2. Choose Configure Voice User from the navigation pane.
  3. Click Import.
  4. In the displayed Voice User Configuration dialog box, click to download the template to the local PC.
  5. Open the template, enter voice user configuration information, and save the file.
  6. In the Voice User Configuration dialog box, click and select the template to be uploaded.
  7. Click to upload a voice user configuration template.

  8. After the template is successfully uploaded, click Confirm.

    • If ONUs in the imported voice user data exist on eSight and the number of imported voice users does not exceed 10, the delivery task is started immediately after the voice user configuration is successful. If the delivery is successful, Succeeded is displayed in both the Configuration Status and Configuration Result columns. If the delivery fails, Failed, Partial success, or Not supported is displayed in the Configuration Status column. The detailed cause of the task delivery failure is displayed in the Configuration Result column.
    • If ONUs in the imported voice user data exist on eSight and the number of imported voice users exceeds 10, the delivery task is started immediately after the voice user configuration is successful. If the thread pool cannot be executed concurrently, To be configured is displayed in the Configuration Status column.
    • If ONUs in the imported voice user data do not exist on eSight, the delivery task is not started after the voice user configuration is successful. To be configured is displayed in the Configuration Status column.

  9. On the Voice User Configuration page, you can perform the following operations:

    • Click in the Operation column to delete a single record.
    • Select the voice user configuration template to be deleted and click to delete the template information.
    • Click in the Operation column to modify voice user parameters.
    • Click Export All to export the voice user information to an Excel file.

802.1X Configuration Template

802.1X configuration templates can be configured on eSight and delivered to OLTs in scenario templates. ONTs can be bound.

Prerequisites

eSight is running properly.

Procedure
  1. Choose Design > Basic Network Design > Template Management from the main menu.
  2. Choose 802.1X Configuration from the navigation pane.
  3. Click Create and set Template Name, Radius Authentication Server IP Address, RADIUS server authentication mode, Radius Authentication Server Port, Shared Secret Key of Authentication Server, and Ethernet Number.

    Click the Obtained from the model list box and select an ONT model. The number of Ethernet ports is automatically set to the number of Ethernet ports of this model.

  4. In the Port Configuration area, click . In the displayed Port 802.1X Configuration dialog box, set Authentication Switch, Authentication Method, Guest VLAN, Restrict VLAN, Critical VLAN, and Port authentication mode, and click Confirm.

    A maximum of seven different VLANs can be set for Guest VLAN, Restrict VLAN, and Critical VLAN.

  5. Click Fill Down. In the displayed Confirm dialog box, click Yes to overwrite the data of other ports with the data of the first port.
  6. Click Confirm. If the added template is displayed in the 802.1X template list, the template is added successfully.
  7. On the 802.1X Configuration page, you can perform the following operations:

    • Click in the Operation column to delete a single record.
    • Select the template to be deleted and click to delete the template information.
    • Click in the Operation column to modify 802.1X template parameters.
    • Click to copy the 802.1X template. You can modify the 802.1X template to create a new one.
      • The values of Template Name and Ethernet Number cannot be changed.
      • A template that has been referenced by a scenario template cannot be modified.
      • A template that has been referenced by a scenario template cannot be deleted.

Configuring a Device Configuration Template

Context

You can configure device configuration templates on iMaster NCE-Campus. After a device configuration template is bound to a device, the configurations specified in the template will be automatically delivered to the device, implementing automatic device configuration. When you need to perform same configurations on multiple devices, you can configure these devices in batches by binding them to the same device configuration template. This improves configuration efficiency.

Feature Requirements

  • A maximum of 100 device configuration templates can be configured under a tenant.
  • One device configuration template can be bound to a maximum of 2000 devices.

Procedure

  1. Choose Provision > Physical Network > Device Configuration Template from the main menu.
  2. On the Device Template page, click Create and configure the device configuration template name, type, device model, and template functions as prompted.

    If the device configuration template is displayed in the list on the Device Template page, the template is created successfully.

  3. Click a device configuration template name or in the row where the desired template is located to set parameters in this template.

    After the configuration is complete, click Apply. Then, click the icon above the device configuration template name in the upper left corner to return to the Device Template page.

  4. Bind devices to and unbind devices from a device configuration template.

    • Bind devices to a device configuration template.

      On the Device Configuration Template tab page, select the target template, and click Bind in the right pane. In the displayed dialog box, select the target sites and click OK. After the template is successfully bound, the system delivers configurations specified in the template to the target devices.

    • Unbind devices from a device configuration template.

      On the Device Configuration Template page, select the target template. In the right pane, select the device that needs to be unbound from the template, and click Unbind. Once unbound from the template, the device is restored to its default settings.

  5. On the Device Configuration Template page, you can perform the operations in Table 4-174 to manage device configuration templates.

    Table 4-174 Operations for managing device configuration templates

    Scenario

    Operation

    Modifying a device configuration template

    Click to modify a device configuration template.

    Deleting a device configuration template

    Click to delete a device configuration template.

    Cloning a device configuration template

    Click to clone a device configuration template. Users can create a template by modifying parameter settings in the cloned template.

Parameter Description

Table 4-175 Device Configuration Template

Parameter

Description

Template name

Device template name.

Constraints: The value is a string of 1 to 64 characters and must be unique.

Device type

Meaning: Type of devices to which the device configuration template applies. The options include FW, LSW, AP, and AR.

Device model

Meaning: Device models to which the device configuration template applies.

Constraints: Device configuration templates are not applicable to modular switches, stacked switches, and switches that can be installed with subcards.

Template function

Meaning: Services that can be configured through this device configuration template.

Configuring a LAN-side Site Configuration Template

Context

You can perform service configurations in site configuration template, such as the SSID, radio, SNMP parameters, and terminal privacy protection policies. After a site configuration template is bound to a site (collection of devices), the site inherits service data in this template. This realizes automatic configuration of sites. If you need to configure the same service configurations for multiple sites, you can use this method to improve efficiency.

Feature Requirements

  • After a site template is deleted, the binding relationship between site and site template is automatically removed. In this case, the service configurations of the site will be restored to default values.
  • A site template can be bound to a maximum of 2000 sites.
  • A maximum of 100 site templates can be configured for a tenant.
    • After a site template is bound to a site, the system automatically delivers the configurations specified in the site template to all devices at the site.
    • After a site template is unbound from a site, the system automatically restores the configurations of all devices at the site to default values.

Procedure

  1. Choose Provision > Physical Network > Site Configuration Template from the main menu.
  2. On the Site Template page, click Create to create a site template as prompted.

    Template function displays all features. If the SecoManager is not installed, Security Policy under FW will be unavailable.

    If the site template is displayed in the list on the Site Template page, the site template is created successfully.

  3. Click in the row of the desired site template or click the desired template name in the list to set parameters carried in the template.

    After the configuration is complete, click Apply to save the configuration. Then, click the icon of the site template in the upper left to return to the site template page.

  4. On the Site Template page, select the desired site template. In the window on the right, click Bind.

  5. In the displayed dialog box, select the sites to be bound with the site template, and click OK.

    If a device of any device type specified in the filter criteria is deployed at a site, the site will be filtered out and displayed in the list.

Related Operations

  • To delete a site template, click .
  • Click to create a site configuration template with a different name based on the selected site configuration template.

Follow-up Procedure

After a site template is bound to a site, the service configurations specified in the site template will be delivered to all devices of the selected types (FW, LSW, AR, or AP) at the target site.

  • You cannot select APs by tag when configuring an SSID based on a site template, and only one VLAN can be specified for the SSID.
  • You can only configure basic radio parameters in site templates. To configure radio calibration parameters, navigate to the AP > Radio page of the target site.

Parameter Description

Table 4-176 LAN-side site configuration template

Parameter

Description

Template name

Meaning: Name of a site template.

Constraints: The value is a string of 1 to 64 characters and must be unique.

Template type

Meaning: Type of devices to which the site template applies.

Value range: The options include FW, LSW, AP, and AR. One or more options can be selected.

Template function

Services that can be configured through the site template.
Table 4-177 Site > Device System Configuration > Basic Info

Parameter

Description

Time zone

Meaning: Time zone for all devices at the current site.

Constraints: This parameter is supported only on firewalls, switches, and APs.

DST

Meaning: Whether to enable daylight saving time (DST) for devices at the current site.

Constraints: This parameter is supported only on switches, APs, and ARs. Only some time zones support the DST.

NTP server IP address

Meaning: NTP server IP address.

Constraints: This parameter is supported only on firewalls, switches, and APs.
Table 4-178 Site > Device System Configuration > SNMP

Parameter

Description

Protocol version

Meaning: SNMP version.

Constraints: SNMPv3 is recommended, because it is more secure than SNMPv1 and SNMPv2c.

Configuration in the scenario where Version is set to V1 or V2C

Read community name

Group of NMSs and SNMP agents. A community name functions as the password for authentication when devices in the community communicate with each other. An NMS can access an SNMP agent only if the community name carried in the SNMP request sent by the NMS is the same as that configured on the SNMP agent. A community name consists of a read community name and a write community name. Currently, iMaster NCE-Campus can only interconnect with SNMP through the read community name.

The parameter value consists of 1 to 32 characters including digits, letters, or special characters.

Allowed IP addresses

IP address whitelist of NMS servers. The whitelist defines NMS servers' IP addresses, improving the system security. If the whitelist is left empty, an NMS server with any IP address can access devices.

Alarm Server

Meaning: Whether to configure alarm servers for devices. Through this function, alarms generated on a device can be sent to the NMS server in a timely manner, implementing effective management on devices.

Constraints:

The IP addresses must be of Class A, B, or C. Multiple IP addresses need to be separated with line breaks, and up to 20 IP addresses can be entered.

  • Class A IP addresses: 1.0.0.0-126.255.255.255
  • Class B IP addresses: 128.0.0.0-191.255.255.255
  • Class C IP addresses: 192.0.0.0-223.255.255.255

Alarm server list

Meaning:

Alarm server IP address.

Constraints:

The IP addresses must be of Class A, B, or C. Multiple IP addresses need to be separated with line breaks, and up to 20 IP addresses can be entered.

Alarms for interface link-layer status changes

Meaning: Whether to generate alarms when the link-layer status of interfaces changes. This function takes effect only when it is enabled globally and on interfaces at the same time.

Constraints: This function is supported on switches only.

Configuration in the scenario where Version is set to V3

User List

Application:

Click Add and add the account information. To implement the bidirectional communication in the following scenarios, ensure that the username, encryption password, and authentication password are the same as those on the NMS server:

Constraints:

  • When a device reports an alarm to the NMS server, the username and password set here are used for authentication and verification on the NMS server. The device can successfully report the alarm only after successful verification.
  • When the NMS server proactively accesses a device, the NMS server performs authentication and verification on the device. The NMS server can successfully access the device only after successful verification.

Allowed IP addresses

Meaning:

IP address whitelist of NMS servers. The whitelist defines NMS servers' IP addresses, improving the system security. If the whitelist is left empty, an NMS server with any IP address can access devices.

Constraints:

The IP addresses must be of Class A, B, or C. Multiple IP addresses need to be separated with line breaks, and up to 20 IP addresses can be entered.

Alarm Server

Meaning:

Whether to configure alarm servers for devices.

Application:

Through this function, alarms generated on a device can be sent to the NMS server in a timely manner, implementing effective management on devices.

Alarm server list

Application:

Click Add, add an alarm server, and select corresponding accounts from the drop-down list box.

Constraints:

The alarm server IP addresses must be Class A, B, or C. Up to 20 IP addresses can be added.

Alarms for interface link-layer status changes

Meaning:

Whether to generate alarms when the link-layer status of interfaces changes. This function takes effect only when it is enabled globally and on interfaces at the same time.

Constraints:

This function is supported on switches only.
Table 4-179 Parameters on the Site > Device Login Configuration page

Parameter

Description

Local User

Username

Meaning: Username for logging in to a device.

Constraints:

  • The value can contain 1 to 64 characters.
  • The value must be in the username or username@domain name format. The value is case-insensitive, and cannot contain asterisks (*), question marks (?), double quotation marks ("), or spaces. The username for logging in to a firewall cannot contain at signs (@).
  • If HWTACACS authentication bypass is enabled, an authentication account same as the local user account must be configured on the Admission > Admission Resources > User Management > User page.
  • The username for logging in to an AR8140 device can contain 6 to 64 characters.

Password
Constraints:
  • Contains 8 to 128 characters. The password used for logging in to a firewall can contain up to 64 characters. Therefore, if the site contains a firewall, set a password with no more than 64 characters.
  • Contains three types of the following: uppercase letters (A to Z), lowercase letters (a to z), digits (0 to 9), and special characters, such as !, @, #, $, and %. It cannot contain single quotation marks, question marks (?), or spaces.
    NOTE:

    The password for logging in to an AR8140 device must contain all of the following character types: uppercase letters (A to Z), lowercase letters (a to z), digits (0 to 9), and special characters (such as !, @, #, $, and %).

  • Cannot contain two or more consecutive identical characters.
  • Cannot be the same as the username or the reverse of the username.

Role

Meaning: Privilege level of the local user.

Constraints:

After a user logs in to a device, the user can only use commands at the user's privilege level or lower.

Value range:

  • Monitor: Level 1
  • Administrator: Level 15

Service type

Value range:

  • HTTP(S): If this option is selected, the user can log in to the device's web system using a browser through HTTP and HTTPS protocols.
  • SSH: If this option is selected, the user can log in to the device CLI using an SSH client.

Valid for distributed APs

Meaning: Whether distributed APs support user roles and service types.

Default setting: disabled

BootROM password

Meaning: BootROM password of switches or APs at sites.

Constraints:

If this password is not set, the device administrator and BootROM passwords set by the tenant administrator upon the first login to iMaster NCE-Campus take effect. To set device administrator and BootROM passwords as needed, choose Design > Site Agile Deployment > Device Management from the main menu, click Management Settings tab, and choose Device Password Configuration from the navigation pane.

NOTE:

If the system administrator disables The device BootROM password can be configured, tenant administrators cannot change the BootROM password. For details about how to disable tenant administrators from changing the BootROM password, see Device Security Policy Management.
Table 4-180 Parameters for creating a CLI whitelist

Parameter

Description

Device type

Type of the devices to which a CLI whitelist is applicable:

  • AP: The commands that can be configured in a CLI whitelist are listed in Table 4-450.
  • Switch: The commands that can be configured in a CLI whitelist are listed in Table 4-451.
  • Firewall: The commands that can be configured in a CLI whitelist are listed in Table 4-452.
  • AR: The commands that can be configured in a CLI whitelist are listed in Table 4-453.

Name

Name of the CLI whitelist.

CLI

If multiple commands need to be set, separate them with line breaks. Only template names, user names, and passwords can contain both uppercase and lowercase letters in CLI commands. Other information can only contain lowercase letters.
Table 4-181 Parameters on the AP > Wi-Fi > SSID > Basic Settings page

Parameter

Description

Data Plan in Advance

Basic Settings

SSID name

Wireless signal name when a terminal connects to a wireless network.

NOTE:

If the SSID name contains Chinese characters, it may be displayed as garbled characters on terminals running Windows.

Y

Working status

By default, this item is toggled on. If this item is toggled off, the SSID is unavailable.

-

Scheduled switch-on

Whether to enable the SSID in a specified time period. When this item is toggled on, you can select a time policy from the drop-down list so that the AP automatically disables the SSID beyond the specified time period. This improves network security and saves energy.

If the time policies preset in the system cannot meet your requirements, click to create a time template as needed.

NOTE:
  • If both scheduled radio switch-on and scheduled SSID switch-on are enabled on an AP, users can access the SSID only in the period when both the SSID and radio are enabled.
  • Only APs running V200R008C10 or a later version support scheduled SSID switch-on. On APs that do not support scheduled SSID switch-on, SSIDs are always enabled.

-

Effective radio

By default, three radios are enabled. You are advised to retain the default setting.

NOTE:

All the three radios are supported on the AP4051TN, AP6750-10T, AP8050TN-HD, AP350, AirEngine 8760R-X1E, AirEngine 8760-X1-PRO, AirEngine 6760-X1, AirEngine 6760-X1E, and AirEngine 5760-51. APs of other models support the radios other than 5G (wlan-radio 0/0/2). When three radios are required on the AirEngine 6760-X1, AirEngine 6760-X1E, and AirEngine 5760-51, select all of the 2.4G (wlan-radio 0/0/0), 5G (wlan-radio 0/0/1), and 5G (wlan-radio 0/0/2) options for Effective radio.

-

Data forwarding mode
  • Direct
  • Soft GRE: APs forward traffic of wireless users through soft GRE tunnels.

Y

Soft GRE template

A soft GRE template needs to be selected when Data forwarding mode is set Soft GRE.

-

Network connection mode
  • If terminals connect to the AP used only for Layer 2 forwarding, select Layer 2 forwarding.
  • If terminals connect to an AP used as the DHCP server, select NAT.

Y

Global DHCP address pool for allocation

With this function enabled, APs assign addresses from the global DHCP address pool. For details, see Configuring DHCP.

Y

VLAN

VLAN to which the wireless terminals connected to the SSID belong. The VLAN ID is assigned based on labels. This parameter is configurable only when Network connection mode is set to Layer 2 forwarding.

NOTE:

If an AP has multiple labels that correspond to different VLAN IDs, the VLAN ID with the smallest priority takes effect.

Y

Advanced

SSID hiding

By default, this function is disabled. After this function is enabled, SSIDs are invisible.

-

DAI

Whether to enable dynamic ARP inspection (DAI). This function prevents ARP packets of unauthorized users from accessing the external network through APs, protecting authorized users against interference or spoofing attacks.

   

IPSG

Whether to enable IP source guard (IPSG). After this function is enabled, source IP address spoofing attacks can be prevented.

   

DNS snooping

By default, this function is disabled. With this function enabled, the device parses the received DNS response packets to obtain IP addresses and generates mappings between the IP addresses and domain names.

NOTE:

Only APs running V200R020C10 and later versions support this function.

-

mDNS snooping

By default, this function is disabled. After this function is enabled, the access device can identify wireless terminals by parsing service information in mDNS packets sent by the terminals.

NOTE:

Only APs running V200R020C10 and later versions support this function.

-

Disable SSID after AP disconnection

By default, this item is toggled off. After this item is toggled on, SSIDs on an AP will be automatically disabled if the AP's uplink is disconnected. This ensures that terminals connected to the faulty AP can automatically connect to another AP.

-

Band steering (5G-prioritized)

By default, this function is enabled. The band steering function enables an AP to steer terminals to the 5 GHz frequency band preferentially, which reduces load and interference on the 2.4 GHz frequency band. User experience is therefore improved.

-

Transmit rate of 2.4G Beacon frames

Transmit rates of 2.4 GHz and 5 GHz Beacon frames, in Mbit/s. The parameters are supported only on APs running V200R008C10 and later versions.

-

Transmit rate of 5G Beacon frames

-

Limit access of traditional terminals

By default, this function is disabled. After this function is enabled, traditional terminals using 802.11a, 802.11b, and 802.11g standards are not allowed to connect to the SSID.

-

Maximum number of users

Maximum number of terminals that can be connected to the SSID at the same time.

-

Access threshold policy
  • New users are denied access to the network.

    When the number of terminals connected to the SSID reaches the threshold, new users are not allowed to access the network.

  • New users are denied access to the network and the SSID is hidden.

    When the number of terminals connected to the SSID reaches the threshold, new users are not allowed to access the network, and the SSID is automatically hidden.

  • VIP users preferentially access the network.

    When the number of terminals connected to the SSID reaches the threshold, VIP users preferentially access the network and replace common users. You can authorize VIP users on the Admission > Admission Policy > Authentication and Authorization Policy page.

-

User isolation

By default, this function is enabled. After this function is enabled, terminals connected to the same SSID of an AP are isolated from each other.

-

Isolation mode
  • All isolated
  • Layer 2 user isolation

-

IGMP snooping

By default, this function is disabled. After IGMP snooping is enabled, multicast data can be forwarded and controlled at the data link layer.

-

Disable broadcast or multicast

By default, this function is disabled. After this function is enabled, WLAN sharing and broadcast or multicast discovery is disabled, and the Bonjour transparent transmission parameter becomes configurable.

-

Multicast-to-unicast conversion

After this function is enabled on an AP, the AP checks Report and Leave messages to maintain multicast-to-unicast entries. When sending multicast packets to a terminal, the AP converts the multicast packets to unicast packets based on the multicast-to-unicast entries, thereby improving multicast stream transmission efficiency.

In addition, with adaptive multicast-to-unicast conversion enabled, when the air interface performance reaches its bottleneck during multicast-to-unicast conversion, an AP automatically switches the multicast group containing the minimum number of terminals to the multicast mode. After the air interface performance is improved and keeps improving for a period of time, the AP automatically switches the multicast group containing the maximum number of terminals to the unicast mode. In this way, the air interface performance is automatically adjusted without manual intervention, improving wireless user experience.

-

Bonjour transparent transmission

By default, this function is disabled. Bonjour is a zero-configuration networking solution proposed by Apple and applies to Layer 2 broadcast domains. It allows terminals in a Layer 2 broadcast domain to automatically obtain addresses and discover services.

-

U-APSD

By default, this function is disabled. U-APSD is a new energy saving mode defined for WMM, which can improve the energy-saving capability of terminals. Some terminals may not well support U-APSD. In this case, you need to disable U-APSD.

-

WMM scenario

Set the WMM parameter based on the network requirements to enable high-priority data packets to preferentially occupy wireless channels, namely, adjusting the forwarding priority of video and voice service traffic. To make the WMM function take effect, you need to enable WMM in the radio configuration. The options of this parameter are as follows:

  • Default: No priority is assigned.
  • Voice: Priority is assigned to voice service traffic.
  • Audio and video: Priority is assigned to voice and video service traffic.
  • Custom: You can set parameters as needed to assign priorities to data packets.
NOTE:

Only APs running V200R008C10 and later versions support the WMM function.

-

Terminal MAC address filtering

By default, this function is disabled. After this function is enabled, the system filters MAC addresses of the terminals connected to the SSID based on the configured blacklist or whitelist.

  • Blacklist: Terminals in the list are denied to access the network. Exact match is performed based on MAC addresses.
  • Whitelist: Terminals in the list are allowed to access the network. Exact match is performed based on either MAC addresses or OUIs. The OUI is the first 24 bits of the terminal's MAC address.

-

Audio quality analysis

By default, this function is disabled. If this function is enabled and the SIP port is configured, the system will enable the SIP protocol. In this case, devices can obtain SIP packets and analyze the service type of the packets, such as voice services.

If iMaster NCE-Campus allows devices to report performance data to the analyzer, the analyzer can obtain the performance data of voice services and analyze the voice call quality.

-

802.11r fast roaming

Whether to enable 802.11r fast roaming.

  • Enable: After this function is enabled, decide whether to enable 802.11r over the DS as needed. When 802.11r over the DS is enabled, only common roaming can be implemented for terminals that do not support the over-the-DS and over-the-air modes at the same time. Currently, most terminals support only the over-the-air mode. Exercise caution when enabling 802.11r over-the-DS.
  • Disable
    NOTE:

    Security policies supported by 802.11r include open system, WPA2+PSK+AES, WPA2+PPSK+AES, and WPA2+802.1X+AES.

-

802.11r over the ds

Whether to enable 802.11r over-the-DS for fast roaming.

  • If this item is toggled on, 802.11r fast roaming in over-the-DS mode is used.
  • If this item is toggled off, 802.11r fast roaming in over-the-air mode is used.

-

Reassociation timeout interval (s)

Timeout period for reassociation. The default value is 1 second.

-

Device-pipe collaborative roaming

Whether to enable device-pipe collaborative roaming. This function implements optimization on the network side and the terminal side to improve users' Internet access experience.

  • If this item is toggled on, 802.11r fast roaming in over-the-DS mode is used.
  • If this item is toggled off, 802.11r fast roaming in over-the-air mode is used.

-

Service assurance mode

The options include:

  • Performance first
  • Reliability first

-

Mobile gaming acceleration

Whether to enable mobile game acceleration. By default, this function is enabled. This function is supported on the following mobile games: PlayerUnknown's Battlegrounds (PUBG), PUBG Mobile, Crossfire, Knives Out, Honor of Kings, DNF, Fantasy Westward Journey, League of Legends, Fortnite, and Identity V. After this function is enabled, the uplink and downlink rates will be accelerated for the mobile games that support this function.

-

Prevent terminals from entering energy-saving mode

Whether to enable the function of preventing terminals from the entering energy-saving mode. After the function is enabled, terminals consume more power and extra bandwidth. If no terminal unexpectedly enters energy-saving state, you are advised to disable the function. This function is disabled by default.

-

MU-MIMO

Whether to enable MU-MIMO optimization. In an environment with less interference, the MU-MIMO optimization function meets user requirements for high downlink throughput of APs. This function is enabled by default.

-

Terminal association aging time (min)

Time period after which weak-signal terminals are disconnected. To prevent user experience deterioration when a large number of weak-signal terminals access the network, you can reduce the aging time of these terminals.

-

DHCP Option 82

Whether to insert the DHCP Option 82 field to DHCP request messages sent by terminals. With this function enabled, when a terminal connects to an AP SSID and sends a DHCP request message to apply for an IP address, the AP inserts DHCP Option 82 (carrying the AP's MAC address, SSID, name, and location) to the DHCP request message and then forwards it to the DHCP server. Upon the receipt of the DHCP request packet, the DHCP server authenticates the AP based on the AP information carried in DHCP Option 82 and allocates different IP addresses based on the preset address allocation policy.

-

Sub-option

circuit-id: Set the information to be carried in the circuit ID (CID) in the Option 82 field.

remote-id: Set the information to be carried in the remote ID (RID) in the Option 82 field.

-

Delimiter

By default, the delimiter is a colon (:). You can set the delimiter to a semicolon (;).

-

Content Type
  • ap-mac: AP's MAC address. After DHCP messages from a STA reach an AP, the AP inserts its MAC address into the Option 82 field of the DHCP messages.
  • ap-mac-ssid: MAC address and SSID of the AP. After DHCP messages from a STA reach an AP, the AP inserts its MAC address and SSID associated with the STA into the Option 82 field of the DHCP messages.
  • ap-name: AP name. After DHCP messages from a STA reach an AP, the AP inserts its name into the Option 82 field of the DHCP messages.
  • ap-name-ssid: AP name and SSID. After DHCP messages from a STA reach an AP, the AP inserts its name and associated SSID into the Option 82 field of the DHCP messages.
  • ap-location: AP location. After DHCP messages from a STA reach an AP, the AP inserts its location into the Option 82 field of the DHCP messages.
  • ap-location-ssid: Location and SSID of the AP. After DHCP messages from a STA reach an AP, the AP inserts its location and associated SSID into the Option 82 field of the DHCP messages.
  • user-defined: User-defined information to be carried.

-

Content Format

ASCII: Set the MAC address in ASCII format of XXXXXXXXXXXX.

Normal: Set the MAC address in the format of xx-xx-xx-xx-xx-xx.

Compact: Set the MAC address in the format of xxxx-xxxx-xxxx.

Hex: Set the MAC address in hexadecimal notation XXXXXXXXXXXX.

Colon: Set the MAC address in the format of xx:xx:xx:xx:xx:xx.

-

User-defined Content

You can enter characters as needed.

-
Table 4-182 AP > Wi-Fi > SSID > Security Authentication

Parameter

Description

Data Plan in Advance

WLAN security policy

Authentication mode for terminals connected to the SSID. The following modes are supported:

Open network: The options include Open, Open+Portal authentication, OWE, and OWE+Portal authentication.

Semi-open network: The options include PSK/PPSK/SAE/PSK-SAE authentication, MAC address authentication, PSK+MAC address authentication, and PSK+Portal authentication.

Secure network: 802.1X authentication is supported.

NOTE:

Opportunistic Wireless Encryption (OWE) is an enhanced open network that allows users to log in without a password and uses the AES algorithm to encrypt data streams.

Y

Encryption mode

Encryption mode for PSK and 802.1X authentication. This parameter is configurable only when WLAN security policy is set to Semi-open network or Secure network.

  • The following modes are supported when WLAN security policy is set to Semi-open network:
    • WEP
    • WPA
    • WPA2
    • WPA and WPA2
  • The following modes are supported when WLAN security policy is set to Secure network:
    • WPA
    • WPA2
    • WPA and WPA2

Y

Encryption algorithm

Encryption algorithm for 802.1X authentication. The options include:

  • AES
  • AES-TKIP
  • TKIP

Y

OWE transition mode

Currently, only a few terminal types support OWE. You are advised to enable the OWE transition mode.

Y

Transition SSID
  • Only the transition SSID is available to terminals. OWE-capable terminals connect to the OWE SSID and their traffic flows are encrypted. OWE-incapable terminals connect to the transition SSID and their traffic flows are not encrypted.
  • Only open network SSIDs can be configured as transition SSIDs.

Y

Secure network

RADIUS server

RADIUS servers run on central computers and workstations to maintain user authentication and network service access information. The servers receive connection requests from users, authenticate the users, and send the responses (to accept or reject the requests) to the clients.

-

Traffic statistics collection

Whether to enable traffic statistics collection.

-

CoA/DM in NAT scenarios

After this function is enabled, the system provides a mechanism for dynamically modifying the rights of online users or disconnecting online users. After you modify this setting, the modification takes effect only for subsequent online users.

-

iConnect terminal access

After this function is enabled, the device automatically scans iConnect terminals and brings them online.

-

Authentication protocol

Protocol for authentication between the device and the authentication server. The options include CHAP and PAP.

NOTE:
  • Huawei devices support both authentication protocols. If a third-party device that does not support CHAP is used, use the PAP protocol.
  • Only APs running V200R020C10 and later versions support this function.

-

MAC address bypass authentication

This parameter is configurable only when WLAN security policy is set to Secure network.

-

Automatic re-authentication

With this function enabled, if a user fails to be authenticated, the device automatically initiates re-authentication at the specified interval.

-

Re-authentication interval (s)

Interval for re-authenticating users who fail to be authenticated.

-

Bypass policy

The system grants specific network access rights to users to meet their basic network access requirements.

-
Table 4-183 AP > Wi-Fi > SSID > Policy Control

Parameter

Description

Data Plan in Advance

SSID-based Rate Limiting

Limits the uplink or downlink bandwidth of the SSID.

Y

Static Rate Limiting for Terminal Traffic

Whether to configure static rate limiting for a single terminal. You can configure limits for uplink and downlink bandwidths separately or configure a limit that takes effect in a specific time period.

If both static and dynamic rate limiting functions are enabled, static rate limiting takes effect. If both the default rate limit and the rate limit in a specified time period are configured, the latter takes precedence. If multiple rate limits are configured in the same time period, the lowest rate limit takes effect.

Y

Rate Limiting in Specific Periods

Set uplink and downlink bandwidth limits in a specific time period.

NOTE:

Only cloud APs support rate limiting in a specified period. Central APs do not support this function.

Y

Dynamic Rate Limiting for Terminal Traffic

Whether to enable dynamic rate limiting for a single terminal. If this function is enabled, the uplink and downlink bandwidths of each terminal can be limited separately. If both static and dynamic rate limiting functions are enabled for uplink or downlink traffic, only static rate limiting takes effect.

NOTE:

AirEngine series devices do not support dynamic rate limiting.

Y

Advanced

IPv6

Whether to enable IPv6 for the SSID.

Y

ACL

Configure ACL-based packet filtering to permit or reject the packets matching ACL rules. You can select an ACL from the drop-down list box.

NOTE:

You can choose Design > Basic Network Design > Template Management > Policy Template from the main menu to manage ACL templates in a centralized manner.

The ACL ID displayed on devices of the following device models may be different from that on the controller: AP1050DN-S, AP2050DN, AP2050DN-E, AP2050DN-S, AP2051DN, AP2051DN-E, AP2051DN-S, AP4051DN-S, AP4050DN, AP4050DN-S, AP4050DN-E, AP4050DN-HD, AP4051DN, AP4151DN, AP5030DN-C, AP5050DN-S, AP6050DN, AP6150DN, AP7050DE, AP7050DN-E, AP8030DN, AP8050DN, AP8050DN-S, AP8130DN, AP8150DN, AD9430DN-12, AD9430DN-24, R230D, R240D, R250D, R250D-E, R251D, R251D-E, R450D, AP4051TN, AP6052DN, AP7052DN, AP7052DE, AP7152DN, AP8050TN-HD, AP8082DN, AP8182DN, AP100EC, AP200EC, AP300EC, AP3050DE, AP7060DN, WA375DD-CE, AP4050DE-M, AP5510-W-GP, AP9330DN, AD9431DN-24X, AP5030DN, AP4030DN, AP4130DN, AP2030DN, AP6010DN-AGN, AP3010DN-AGN, AP2010DN, AP6510DN-AGN, AP4050DE-M-S, AP4050DE-B-S, AP2051DN-L-S, AP5030DN-S, AP6750-10T, and AirEngine5760-10.

The ACL ID displayed on devices of all other models is the same as that on the controller.

Y

Application traffic statistics collection

After this function is enabled, APs parse packets from users to collect the network usage statistics about each user application.

NOTE:

Application traffic statistics collection is not supported on the AP2050DN, AP2050DN-E, AP2050DN-S, AP4050DN-E, AP4050DN-HD, AP6050DN(256M), AP6150DN(256M), AP7050DE(256M), AP8030DN, AP8130DN, R230D, R240D, R250D, R250D-E, R251D, R251D-E, and R450D.

Y

Application filtering list

Configure blocking, CAR, and DSCP marking policies for network packets of certain applications.

If you want to learn supported applications in the AP signature database, visit https://support.huawei.com/enterprise/en/doc/EDOC1000183795?idPath=24030814|21782164|21782201|22318529|22039827.

NOTE:

Application filtering is not supported on the AP2050DN, AP2050DN-E, AP2050DN-S, AP4050DN-E, AP4050DN-HD, AP6050DN(256M), AP6150DN(256M), AP7050DE(256M), AP8030DN, AP8130DN, R230D, R240D, R250D, R250D-E, R251D, R251D-E, and R450D.

Y

URL filtering

By default, this function is disabled. After enabling this function, configure a URL filtering policy to limit network resources accessible to wireless terminals.

  • Blacklist: Deny access to the websites in the URL list.
  • Whitelist: Permit access only to the websites in the URL list.
NOTE:
  • Central APs do not support URL filtering.
  • If the browser used by the terminal accesses websites using the proxy, the blacklist and whitelist configurations do not take effect because the URLs in the data packets are not the URLs of the target websites.

Y

IPsec ACL

Use ACLs to configure IPsec policies to implement priority-based processing of data packets meeting related conditions.

Y
Table 4-184 AP > Wi-Fi > Radio > Basic Settings

Parameter

Description

Country/Region

Region where the tenant network belongs. After Country/Region is selected based on the region where the AP is deployed, the AP resets the working channel and power of the radio based on local laws and regulations and adjusts the configurable channel range and power.

Scheduled switch-on

Whether to enable the SSID in a specified time period. When this item is toggled on, you can select a time policy from the drop-down list so that the AP automatically disables the SSID beyond the specified time period. This improves network security and saves energy.

If the preset time policies cannot meet your requirements, click to create a time template as needed.

Calibration mode

Radio calibration mode. You are advised to use the scheduled mode and set the calibration start time to off-peak hours (for example, 00:00-06:00 at the local time).

  • Automatic: APs perform calibration based on the configured start time and interval. By default, an AP starts calibration at 03:00:00 at an interval of 1440 minutes.
  • Scheduled: APs perform calibration at the specified time point every day.
  • Manual: APs do not proactively perform calibration.

Calibration policy

The calibration policy takes effect only in automatic radio calibration mode.

  • Rogue AP: Select this policy when rogue APs (out of control by a WAC) exist on a network. The device then immediately takes actions to avoid interference. This policy may lead to frequency channel switchovers. You are advised to use this policy under the instruction of technical support personnel.
  • Noise floor: When the noise floor of APs is high due to special external interference, service experience may deteriorate. With this radio calibration policy, the device takes actions to avoid interference. When detecting that the noise floor of the current channel exceeds the threshold for three consecutive times, the AP switches its channel and does not switch back in 30 minutes.
  • Non Wi-Fi: When non-Wi-Fi interference occurs on a network, the device immediately takes actions to avoid interference.

AI-powered calibration

This function is enabled by default and takes effect when the system connects to CampusInsight. If the system is not connected to CampusInsight, the device automatically uses the original mode for optimization. After AI-powered calibration takes effect, the device performs automatic calibration using AI algorithms based on data from the past seven days. If the interference source around the device changes during the day and night, this function has good optimization effect.

Self-calibration
  • You are advised to enable this function for cloud APs that require self-calibration on a Layer 3 network to improve the optimization effect.
  • You are advised to enable this function when a large number of cloud APs cannot communicate with each other at Layer 2.

Radio mode

Radio mode of APs. Only the Wi-Fi 6 AirEngine APs support this parameter. The options are as follows:

  • Default mode.
  • Standard dual-radio mode
  • 2G enhanced dual-radio mode. The 2 GHz radio in this mode provides a larger capacity than the standard mode.
  • Triple-radio mode. Ensure that the third radio of the AP has WLAN service configuration. Otherwise, this radio fails to work.
  • Dual-radio+independent scanning radio mode.
    NOTE:

    Dual-radio+independent scanning radio mode. The AirEngine 6760-X1, AirEngine 6760-X1E, and AirEngine 5760-51 can switch to the dual-radio + independent scanning mode only after an RTU license is loaded.
Table 4-185 AP > Wi-Fi > Radio > Advanced Settings

Parameter

Description

2.4 GHz

Channel set (20 MHz)

Channel set used by an AP to transmit wireless signals at the 2.4 GHz frequency band. To reduce AP co-channel or adjacent-channel interference, the system selects a channel from the channel set based on the neighbor relationship between APs and allocates a channel to each AP based on Dynamic Channel Allocation (DCA). The calibration channel set contains channels 1 to 13.

Air scan

This function is enabled by default. If air scan is disabled on an AP, the AP stops scanning surrounding radio signals.

NOTE:

If air scan is disabled, functions such as radio calibration, spectrum analysis, terminal location, WIDS, smart roaming, and DFS smart selection cannot be used.

Guard Interval (GI)

Non-802.11ax guard interval (GI) mode. This parameter is applicable to APs running V200R009C00 or a later version.

  • Default: The default value is used.
  • Short: short GI (400 ns)
  • Normal: normal GI (800 ns)

802.11ax GI mode

GI mode for 802.11ax. The default value is 0.8 (µs). The options are as follows

  • 0.8 (µs)

  • 1.6 (µs)

  • 3.2 (µs)

A smaller GI indicates higher transmission efficiency. A larger GI indicates a higher anti-interference capability. A small GI is recommended for indoor areas with low interference, and a large GI is recommended for outdoor areas with high interference.

TPC range

Transmit power range after radio calibration, in dBm. By default, the upper transmit power control (TPC) threshold is 127 dBm and the lower TPC threshold is 1 dBm.

If the lower threshold is too low, the power may be low and cannot meet radio coverage requirements after radio calibration. If the upper threshold is too high, the power may be high and interferences occur between APs after radio calibration.

Access user count limit

Maximum number of terminals that can access the AP on the 2.4 GHz frequency band. The default value is 64.

The following access threshold policies are supported:

  • New users are denied access to the network.

    When the number of terminals connected to the radio reaches the threshold, new users are not allowed to access the network.

  • New users are denied access to the network and the SSID is hidden.

    When the number of terminals connected to the radio reaches the threshold, new terminals are not allowed to access the network, and all SSIDs of the radio are automatically hidden.

  • VIP users preferentially access the network.

    When the number of terminals connected to the radio reaches the threshold, VIP users preferentially access the network and replace common users.

    You can authorize VIP users on the Admission > Admission Policy > Authentication and Authorization > Authorization Rules page.

Upper threshold of access users

Access threshold policy

Radio coverage threshold

TPC threshold, in dBm. The default value is -60 dBm.

The threshold is adjusted based on the AP deployment height and distance to achieve optimal coverage after radio calibration is performed. A higher threshold indicates higher power adjusted by TPC.

Multicast transmission rate

The configured multicast transmit rate must be in the basic rate set or supported rate set, and supported by terminals. Otherwise, terminals cannot receive multicast data.

Basic rate (Mbit/s)

Basic rate of the 2.4 GHz frequency band.

Supported rate (Mbit/s)

Rate supported by the 2.4 GHz frequency band.

Forcible offline of weak-signal terminals

Whether to log out weak-signal terminals. After this function is enabled, an AP logs out detected weak-signal terminals.

Scenario
After Forcible offline of weak-signal terminals is enabled, APs check connected terminals based on SNR threshold and Detection interval.
  • If Scenario is set to Normal or High Density, SNR threshold and Detection interval values are preset on iMaster NCE-Campus. You do not need to set the two parameters. You can select a scenario as required.
  • If Scenario is set to Custom, you need to set SNR threshold and Detection interval.

SNR threshold (dB)

Detection interval (ms)

Dual-band dynamic adjustment

Whether to enable dual-band dynamic adjustment. This function is disabled by default.

Process redundant 2.4 GHz radios

(This parameter is valid only when Dual-band dynamic adjustment is enabled.) Processing mode of redundant 2.4 GHz radios.

  • Auto-switch to 5 GHz radios: The redundant 2.4 GHz radio is automatically switched to the 5G radio. If no channel is available on the 5 GHz radio or the current radio cannot switch to the 5G radio, switch to the monitor mode.
  • Auto-disable 2.4 GHz radios: The redundant 2.4 GHz radio is automatically shut down.

Ultimate power

If obstacles exist or signals are not covered, the signals with higher power are used to implement signal coverage. The options include:

  • Auto
  • Enable
  • Disable

Bandwidth reservation ratio for VIPs

Ratio of the bandwidth reserved for VIP users. If no VIP user is available, the reserved bandwidth can be consumed by common users. If VIP users are available, the reserved bandwidth is preferentially consumed by VIP users.

5 GHz

Calibration bandwidth

DCA channel bandwidth used by an AP to transmit wireless signals at the 5 GHz frequency band. A higher-bandwidth channel indicates a higher transmission rate.

Channel set

Channel set used by an AP to transmit wireless signals at the 5 GHz frequency band. To achieve optimal calibration, use three or more than three optional channels.

NOTE:
  • When configuring the calibration bandwidth, ensure that enough calibration channels are available for use.
  • When configuring optimization, you need to consider the matching relationship between the calibration bandwidth and the calibration channel.

Air scan

This function is enabled by default. If air scan is disabled on an AP, the AP stops scanning surrounding radio signals.

NOTE:

If air scan is disabled, functions such as radio calibration, spectrum analysis, terminal location, WIDS, smart roaming, and DFS smart selection cannot be used.

Basic rate (Mbit/s)

Supported basic rate set.

NOTE:

This setting takes effect only when the radio type is 802.11b or 802.11g, and does not take effect when the radio type is 802.11n or 802.11ax.

  • 1: 1 Mbps
  • 2: 2 Mbps
  • 5.5: 5.5 Mbps
  • 6: 6 Mbps
  • 9: 9 Mbps
  • 11: 11 Mbps
  • 12: 12 Mbps
  • 18: 18 Mbps
  • 24: 24 Mbps
  • 36: 36 Mbps
  • 48: 48 Mbps
  • 54: 54 Mbps

Supported rate (Mbit/s)

Supported rate set.

NOTE:

This setting takes effect only when the radio type is 802.11b or 802.11g, and does not take effect when the radio type is 802.11n or 802.11ax.

  • 1: 1 Mbps
  • 2: 2 Mbps
  • 5.5: 5.5 Mbps
  • 6: 6 Mbps
  • 9: 9 Mbps
  • 11: 11 Mbps
  • 12: 12 Mbit/s
  • 18: 18 Mbps
  • 24: 24 Mbps
  • 36: 36 Mbps
  • 48: 48 Mbps
  • 54: 54 Mbps

Guard Interval (GI)

Set the non-802.11ax guard interval (GI) mode. This parameter is applicable to APs running V200R009C00 or a later version.

  • Default: The default value is used.
  • Short: short GI (400 ns)
  • Normal: normal GI (800 ns)

802.11ax GI mode

GI mode for 802.11ax. The default value is 0.8 (µs). The options are as follows:

  • 0.8 (µs)

  • 1.6 (µs)

  • 3.2 (µs)

A smaller GI indicates higher transmission efficiency. A larger GI indicates a higher anti-interference capability. A small GI is recommended for indoor areas with low interference, and a large GI is recommended for outdoor areas with high interference.

Antennas model

Select omnidirectional antenna or directional antenna based on site requirements.

TPC range

Transmit power range after radio calibration, in dBm. By default, the upper TPC threshold is 127 dBm and the lower TPC threshold is 1 dBm.

If the lower threshold is too low, the power may be low and cannot meet radio coverage requirements after radio calibration. If the upper threshold is too high, the power may be high and interferences occur between APs after radio calibration.

Access user count limit

Set the maximum number of terminals that can access the AP on the 5 GHz frequency band. The default value is 64.

The following access threshold policies are supported:

  • New users are not allowed access to the network.

    When the number of terminals connected to a radio reaches the threshold, new users are not allowed to access the network.

  • New users are not allowed access to the network and the SSID is hidden.

    When the number of terminals connected to a radio reaches the threshold, new terminals are not allowed to access the network, and all SSIDs of the radio are automatically hidden.

  • VIP users preferentially access the network.

    When the number of terminals connected to the radio reaches the threshold, VIP users preferentially access the network and replace common users.

    You can authorize VIP users on the Admission > Admission Policy > Authentication and Authorization > Authorization Rules page.

Upper threshold of access users

Access threshold policy

Radio coverage threshold

TPC threshold, in dBm. The default value is -60 dBm.

The threshold is adjusted based on the AP deployment height and distance to achieve optimal coverage after radio calibration is performed. A higher threshold indicates higher power adjusted by TPC.

A-MSDU

Whether to enable the function of sending 802.11ac packets in A-MSDU mode.

Maximum number of subframes

Maximum number of subframes that can be aggregated into an A-MSDU at one time.

Multicast transmission rate

The configured multicast transmit rate must be in the basic rate set or supported rate set, and supported by terminals. Otherwise, terminals cannot receive multicast data.

Forcible offline of weak-signal terminals

Whether to log out weak-signal terminals. After this function is enabled, an AP logs out detected weak-signal terminals.

Scenario
After Forcible offline of weak-signal terminals is enabled, APs check connected terminals based on SNR threshold and Detection interval.
  • If Scenario is set to Normal or High Density, SNR threshold and Detection interval values are preset on iMaster NCE-Campus. You do not need to set the two parameters. You can select a scenario as required.
  • If Scenario is set to Custom, you need to set SNR threshold and Detection interval.

SNR threshold (dB)

Detection interval (ms)

Ultimate power

If obstacles exist or signals are not covered, the signals with higher power are used to implement signal coverage. The options include:

  • Auto
  • Enable
  • Disable

Bandwidth reservation ratio for VIPs

Ratio of the bandwidth reserved for VIP users. If no VIP user is available, the reserved bandwidth can be consumed by common users. If VIP users are available, the reserved bandwidth is preferentially consumed by VIP users.

General Parameters

Beacon interval (ms)

Interval at which an AP sends Beacon frames. The default value 100 ms is recommended.

An AP sends Beacon frames at intervals to notify terminals of an existing 802.11 network. After a terminal receives a Beacon frame, it can modify parameters used to connect to the 802.11 network.

A long interval for sending Beacon frames lengthens the dormancy time of terminals, while a short interval for sending Beacon frames increases air interface costs.

RTS-CTS mode

Working mode of Request To Send/Clear To Send (RTS-CTS). RTS-CTS prevents data transmission failures caused by channel conflicts. The default value cts-to-self is recommended.

  • cts-to-self: The sender notifies neighboring devices of stopping data sending before data transmission. This mode uses a small network cost to prevent data transmission conflicts. This mode applies to most application environments.
  • rts-cts: The sender and receiver notify neighboring devices of stopping data sending before data transmission. This mode can better prevent conflicts, but the network cost is high. Excess advertisement frames may occupy the channel bandwidth.
  • disable: Advertisement packets are not sent before data transmission. Data transmission may fail due to conflicts.

RTS-CTS threshold (Byte)

Set the RTS-CTS threshold to specify the length of the frame to be sent. If the length of the frame to be sent by the workstation is less than the threshold set by the RTS-CTS threshold, the RTS/CTS handshake is not performed. The default value is 1400.

NOTE:

If the threshold has been set using the CLI, delete the command configuration.

Airtime fair scheduling

Airtime fair scheduling preferentially schedules users who occupy the channel for a short time. In this way, each user is assigned equal time to occupy the channel, ensuring fairness in channel utilization. By default, this function is enabled.

Packet-based power control

Packet-based power control technology detects the signal strength of terminals in real time to conserve energy. If an AP detects that the signal strength of a terminal is strong (for example, the terminal is close to the AP), the AP reduces its transmit power when sending packets. If an AP detects that the signal strength of a terminal is weak (for example, the terminal is far away from the AP), the AP uses the normal transmit power to send radio signals. By default, this function is enabled.

Beamforming

Beamforming can enhance signals at an angle (for target users), attenuate signals at another angle (for non-target users or obstacles), and control the signal transmission direction and coverage area. By default, this function is disabled.

NOTE:

For details about beamforming requirements, see "beamforming enable" page in related AP product documentation.

Load balancing

In scenarios where APs are close to each other and there is a high degree of overlap between APs' coverage ranges, you can configure load balancing to evenly distribute user traffic to different APs and ensure wireless network experience of each terminal. When a terminal attempts to connect to a WLAN, the AP that receives the terminal's access request evaluates the current load based on the number of online terminals and its maximum capability. If the load is much higher than the average load of a neighboring AP in the same AP group, the AP rejects the access request.

Smart roaming

Whether to enable smart roaming.

When terminals connected to an AP have weak signals, their network access rates are low. In this situation, if many low-rate terminals connect to the AP, air interface occupation time of other terminals is reduced. As a result, the AP throughput decreases, degrading user experience. To prevent this situation, enable Forcible offline of weak-signal terminals. When detecting that the SNR or access rate of a terminal is lower than the specified threshold, the AP sends a Disassociation packet to the terminal to disconnect the terminal. The terminal can attempt to re-connect to the WLAN after being disconnected.

Full-channel detection

Whether to scan all the channels.

NOTE:

This function is supported only on cloud APs and central APs running V200R020C10 or a later version.

Spectrum analysis

Whether to enable WLAN devices to detect different types of interference sources in a WLAN. In spectrum analysis, the spectrum analysis server analyzes the characteristics of collected wireless signals to identify and locate non-Wi-Fi devices, eliminating the impact of interference on WLANs.

With this function enabled, APs collect and report related data.

NOTE:

This function is supported only on cloud APs and central APs running V200R020C10 or a later version.

Scan duration (ms)

Duration during which an AP continuously scans the air interface. The AP continuously scans surrounding radio signals during the duration. After the scanning is complete, the AP sends collected information to iMaster NCE-Campus for radio calibration and spectrum analysis.

A longer scanning time indicates more collected data and more accurate data analysis result. However, scanning for a long time consumes too many system resources, which may affect normal services. Therefore, you are advised to use the default value of 60 ms.

NOTE:

This parameter is configurable only after air scan is enabled.

Scan interval (ms)

Interval at which an AP scans the air interface. The default value of 10000 ms is recommended.

NOTE:

This parameter is configurable only after air scan is enabled.

Channel to scan

Channel set where an AP scans the air interface. The default value is Channel in region.

  • Channel in region: scans all channels supported by the selected country code in region.
  • Calibration Channel: scans all channels in the calibration channel set.
  • Working Channel: scans only the current working channel.
    NOTE:

    This parameter is configurable only after air scan is enabled.

WMM

Whether to enable the Wi-Fi Multimedia (WMM) function.

NOTE:

Only APs running V200R008C10 and later versions support the WMM function.

Channel contention parameters

WMM classifies packets into four access categories (ACs): AC_VO (voice), AC_VI (video), AC_BE (best effort), and AC_BK (background). Each AC queue defines a set of EDCA parameters, which determine the capability of occupying channels. These parameters ensure that a higher-priority AC queue has a higher probability to preempt channels than a lower-priority AC queue.

EDCA parameters are as follows:

  • Arbitration interframe spacing number (AIFSN): determines the channel idle time. A larger AIFSN value indicates a longer channel idle time and a lower priority.
  • Exponent form of CWmin (ECWmin): A larger value indicates a lower priority. The value of ECWmin must be smaller than that of ECWmax.
  • Exponent form of CWmax (ECWmax): A larger value indicates a lower priority.
  • Transmission opportunity limit (TXOPLimit): determines the maximum duration in which a terminal can occupy a channel. A larger value indicates a longer duration.

ACK policy:

  • Normal ACK: The receiver must return an ACK frame each time it receives a unicast packet.
  • No ACK: The receiver does not need to return ACK frames after receiving packets. This mode is applicable to environments with high communication quality and little interference.

Dynamic BE optimization

Dynamic optimization of the Best Effort (BE) service. After this function is enabled, the AP dynamically adjusts the air interface resources consumed by terminals based on the number of access users by using algorithm. This saves more resources for the BE service, improving user experience. In the BE service, packets arriving first are forwarded first. However, the BE service does not ensure the delay, jitter, packet loss rate, or reliability of transmission.

BE optimization threshold (packets/second)

Threshold for BE optimization algorithm. You are advised to retain the default value.

Multimedia dynamic optimization

After this function is enabled, the AP dynamically adjusts the air interface resources consumed by terminals based on the number of access users by using algorithm. This saves more resources for audio and video applications, improving user experience.

Audio optimization threshold (packets/second)

Optimization thresholds for audio and video applications. You are advised to retain the default value.

Video optimization threshold (packets/second)

Scenario

This parameter is configurable when both Dynamic BE optimization and Multimedia dynamic optimization are disabled.

Set the WMM parameter based on the network requirements to enable high-priority data packets to occupy wireless channels, namely, adjusting the forwarding priority of video and voice service traffic. To make the WMM function take effect, you need to enable WMM in the radio configuration. The options of this parameter are as follows:

  • Default: No priority is assigned.
  • Voice: Priority is assigned to voice service traffic.
  • Voice and Video: Priority is assigned to voice and video service traffic.
Table 4-186 AP > Security > WLAN Security

Parameter

Description

MAC address whitelist

If a rogue AP is detected but matches the authorized AP list, the AP is considered authorized and will not be contained. These parameters are configurable when Detect rogue devices is enabled.

OUI whitelist

SSID whitelist

MAC addresses of devices to be manually contained

MAC addresses of rogue devices that need to be manually contained. This parameter is configurable when Contain devices manually is enabled.

Alternatively, you can choose AP > Security under Monitor > Health > Devices 360, access the Risky Device Detection tab page, and click Add Manual Contain to add target devices to this list.

Rules for identifying spoofed SSIDs

Rules for identifying spoofed SSIDs. The rules need to be configured based on regular expressions. If an SSID matches a rule, the SSID is considered a spoofed one. These parameters are configurable when Detect rogue devices is enabled.

MAC addresses of terminals to be protected

MAC addresses of authorized terminals that need to be protected from getting connected to rogue APs. This parameter is configurable when Protect terminals is enabled.
Table 4-187 AP > Security > Attack Defense

Attack Defense Type

Description

Malformed packet attacks

An attacker sends malformed IP packets to the target system. Then the system may crash when processing such packets.

Packet fragment attacks

An attacker sends a large number of fragmented packets to the target system to consume memory resources of the target system. As a result, the target system cannot respond to normal IP packets.

ICMP flood attacks

An attacker sends a large number of ICMP packets to the attack target within a short period of time, exhausting sessions of network devices and leading to network breakdown. Attacks of oversized ICMP packets will also result in congestion of network links.

TCP SYN flood attacks

An attacker sends a large number of packets with forged IP addresses to the target system, so the target system cannot reply packets to the correct destination addresses, exhausting host resources.

UDP flood attacks

An attacker sends a large number of UDP packets to the target system in a short period of time and requests for responses. The target system then is overloaded and cannot process valid tasks.
Table 4-188 AP > Advanced > DHCP

Parameter

Description

DHCP

Enable DHCP and set DHCP parameters. This parameter is enabled by default.

IP address

Default gateway and subnet mask of the DHCP client. The gateway IP address and subnet mask determine the IP address range (DHCP address pool) that DHCP clients may obtain.

Mask

DNS server

System DNS setting: The default DNS server is used.

Custom: You need to configure primary and secondary DNS servers as needed.

Log record

This switch is turned off by default. When this switch is turned on, it takes effect when the system connects to the CampusInsight. This function is used to record DHCP Server configuration success or failure logs and report the logs to the CampusInsight for data analysis and display.

Third-party URL filtering

URL filtering by third-party software. After this function is enabled, third-party software can be used to implement URL filtering.

Lease

Lease of an IP address that a DHCP client automatically obtains. After the IP address lease expires, an IP address is assigned again.

Master WINS

Primary and secondary WINS server addresses assigned to a DHCP client.

Slave WINS

Static address binding

Binding between IP addresses and MAC addresses. A fixed IP address is assigned to a DHCP client with a specified MAC address.

VLAN ID

Specify a VLAN ID. The LAN-side VLAN ID must be different from configured service VLAN IDs, and changing the VLAN ID may cause NAT and IPsec users to go offline. The LAN-side VLAN ID cannot be the same as the management VLAN ID. Otherwise, the configuration delivery may fail.
Table 4-189 Firewall > Network > WAN > DNS

Parameter

Description

DNS Configuration

Whether to enable or disable the DNS function on the firewall: If both the DNS relay and DNS proxy are enabled, the DNS proxy takes effect.

  • DNS relay: The value ON indicates that the DNS relay is enabled.
  • DNS proxy: The value ON indicates that the DNS proxy is enabled.
  • Dynamic DNS: If the value is set to ON, the DNS server address is obtained from the uplink interface.

DNS server configurations

DNS server for the firewall. You can add a maximum of six DNS servers in descending order of priority. Multiple IP addresses need to be separated by line breaks. Duplicate IP addresses are invalid and automatically filtered out before being committed.

DNS Local Domain Configuration

Click Create to add the mapping between domain names and IP addresses in the local domain name cache table, and click OK to save the configuration.
Table 4-190 Firewall > Network > LAN

Parameter

Description

Subnet name

Subnet Name.

VLAN ID

VLAN ID. The value is the same as the VLAN ID of the firewall that is directly connected to intranet devices.

Address pool mode

You can select either the manual or automatic mode.

  • Manual: You need to manually configure the default gateway IP addresses and masks of DHCP clients.
  • Auto: The default gateway IP addresses of DHCP clients are allocated automatically from the address pool.

Address pool

You can select an available IP address pool or click to create an IP address pool.

IP address/Mask

IP address: specifies the IP address of the VLANIF interface, which is used as the default gateway address of DHCP clients.

Mask: specifies the subnet mask of an IP address that a DHCP client automatically obtains. The gateway IP address and subnet mask determine the IP address range (DHCP address pool) that DHCP clients may obtain.

Security domain

The default domain is the trust domain. You can choose or create a domain as needed.

Ping

Whether to enable the Ping function.

DHCP

Whether to enable the DHCP function.

DHCP mode

DHCP working mode of the firewall:

  • Server: The firewall functions as the DHCP server to dynamically assign IP addresses to intranet users.
  • Relay: The firewall functions as a DHCP relay agent.

DNS service

DNS server address specified for DHCP clients:

  • System DNS settings: The DNS server address is obtained from the uplink interface.
  • Custom: You need to set a DNS server address as needed.

Primary DNS/Secondary DNS

IP address of the DNS server. This parameter needs to be set when DNS service is set to Custom.

AP mode

Mode of an AP in the subnet. The options are Cloud AP and Fit AP.

NOTE:

Parameters, such as AP mode and Controller address auto-negotiation, are configurable when Internet selection is set to Multi-branch interconnection.

The AP mode of the current subnet can be specified only when the AP is managed by iMaster NCE-Campus for the first time. If the AP is not configured with the initial configuration or has been executed, the AP mode cannot be changed here.

Controller address auto-negotiation

When the function is enabled, the DHCP server of the current subnet automatically generates Option 148. Devices (switches or cloud-based APs) in the subnet can obtain the iMaster NCE-Campus address through Option 148 to register with iMaster NCE-Campus.

Controller address type

The value can be an IP address or a domain name.

If the iMaster NCE-Campus address is set to a domain name, ensure that the DNS function is configured on the live network to resolve the iMaster NCE-Campus domain name. Otherwise, devices fail to register with iMaster NCE-Campus.

DHCP option

DHCP option that is delivered to a DHCP client with an IP address.

When cloud platform address(148) is selected, the value of the text type should be set to agilemode=xxx;agilemanage-mode=xxx;agilemanage-domain=xxxx.xxx;agilemanage-port=xxx. When requesting IP addresses through DHCP, Intranet cloud devices can obtain the address and port of the iMaster NCE-Campus server through this option. For example, agilemode=agile-cloud;agilemanage-mode=domain;agilemanage-domain=device-naas.huawei.com;agilemanage-port=10020.

In this format:

  • agilemode: The value can be agile-cloud (default mode delivered by the controller.), tradition (mode that can be switched through Option 148 on an external DHCP server), or tradition-fit (special Fit mode for APs in WAC scenarios).
  • agilemanage-mode: The value can be ip or domain, which indicates that the value of agilemanage-domain is an IP address or a domain name.
  • agilemanage-domain: specifies the domain name or IP address of the controller.
  • agile-port: specifies the port number of the controller.

Lease period

IP addresses that are dynamically allocated by a DHCP server to DHCP clients have leases. When the lease expires, the server reclaims the IP address, which can then be allocated to other clients.

Primary WINS

Primary and secondary WINS server addresses assigned to DHCP clients.

Secondary WINS

Reserved IP address

Reserved IP address range. The firewall does not allocate IP addresses in the IP address range to intranet devices.

Static management IP address for switches

After this function is enabled, the controller automatically assigns a static management address to a switch when the switch applies for a management IP address from the address pool and goes online. This prevents frequent changes of the switch's management IP address. This parameter is configurable only when Address pool mode is set to Manual and switches are deployed on a multi-branch network. You can click to check static management IP addresses assigned to switches.

Static management IP address range

Range of the IP addresses that can be statically assigned to switches. The IP addresses that may be configured for VLANIF interfaces must be excluded from this range.

Static address binding

Fixed IP address allocated to a specified terminal.

DHCP server IP address

When the firewall functions as the DHCP relay agent, the third-party DHCP server must be specified.
Table 4-191 Firewall > Wi-Fi > SSID > Basic Settings

Parameter

Description

Name

Wireless signal name when a terminal connects to a wireless network.

Working status

This parameter is enabled by default. If this item is toggled off, the SSID is unavailable.

Effective radio

The default value is 2.4G/5G. You are advised to use the default setting.

VLAN ID

Service VLAN for terminal access. Ensure that the network with the same VLAN ID as that for the SSID has been created.

SSID hiding

By default, this function is disabled. After this function is enabled, SSIDs are invisible.

Maximum user count

Maximum number of terminals that can be connected to the SSID at the same time.
Table 4-192 Firewall > Authentication

Parameter

Description

Page pusher

Portal authentication is supported after Push page (Portal authentication) is enabled. The Portal page for user authentication can be pushed in the following modes:

  • Controller built-in authentication
  • Third-party authentication
  • Firewall built-in authentication

When Page pusher is set to Controller built-in authentication, you can set login modes as needed. Currently, the following login modes are supported: anonymous authentication, username and password authentication, SMS authentication, Facebook authentication, Twitter authentication, Sina Weibo authentication, QQ authentication, passcode authentication, one-click authentication, and public QR code authentication.

Source IP address-based page pushing

After this function is enabled, the Portal authentication page is pushed only to terminals whose IP addresses are specified in the source IP address list.

Portal protocol type

The following Portal protocols are supported:

  • HACA
  • Portal 2.0

Page push protocol

Protocol used to push a Portal page. The options include HTTPS and HTTP. This parameter is configurable when Portal protocol type is set to HACA. By default, HTTPS is used.

Bypass policy
A bypass policy ensures basic network access when a network fault occurs or the HUAWEI CLOUD platform is being upgraded. Currently, the following two bypass policies are supported:
  • Allows authenticated users to continue using the network and denies access of new users.
  • Allows user access without authentication.
Table 4-193 Security Authentication

Parameter

Description

Authentication mode

SSID authentication mode. The following modes are supported:

  • Open network (authentication-free)
  • Semi-open network (PSK authentication)
  • Secure network (802.1X authentication)

Encryption mode

Encryption mode for PSK or 802.1X authentication. This parameter is valid only when Authentication mode is set to Semi-open network or Secure network.

  • The following encryption modes are supported when Authentication mode is set to Semi-open network:
    • WEP
    • WPA
    • WPA2
    • WPA and WPA2
  • The following encryption modes are supported when Authentication mode is set to Secure network:
    • WPA
    • WPA2
    • WPA and WPA2

Key

PSK. This parameter is valid only when Authentication mode is set to PSK.

Encryption algorithm

Encryption algorithm for 802.1X authentication. This setting takes effect when Authentication mode is set to Secure network. The following options are supported:

  • AES
  • AES-TKIP
  • TKIP

RADIUS server

RADIUS server responsible for user authentication, authorization, and accounting. This setting takes effect when Authentication mode is set to Secure network.
Table 4-194 Firewall > Policy > Traffic Policy

Parameter

Description

Control conditions

The authenticated user matches the policy when matching all control conditions.

  • Source security zone: indicates the source security zone of traffic.
  • Destination security zone: indicates the destination security zone of traffic.
  • Source address: indicates the source address of traffic.
  • Destination address: indicates the destination address of traffic.
  • Service: list of permitted or denied service configurations. Click Create, enter a valid protocol, source port number, and destination port number, and click .
  • Application: type of the permitted or denied application, including some specific programs. Click Create and select multiple application types.
  • Time: indicates the time range during which the traffic policy takes effect.
  • Security group: indicates the security group where the policy takes effect.
NOTE:

Application-based control is supported on the following firewall models:

  • V500R001C30

    USG6320, USG6507, USG6530, USG6550, USG6570, USG6510, USG6510-WL, USG6330, USG6350, USG6360, USG6370, USG6380, USG6390, USG6390E, USG6305, USG6305-W, USG6310S, USG6310S-W, USG6310S-WL, USG6310S-WL-OVS, USG6306, USG6308, and USG6310

  • V500R001C60, V500R001C80, and V500R005C00

    USG6320, USG6507, USG6530, USG6550, USG6570, USG6510, USG6510-WL, USG6330, USG6350, USG6360, USG6370, USG6380, USG6390, USG6390E, USG6305, USG6305-W, USG6310S, USG6310S-W, USG6310S-WL, USG6310S-WL-OVS, USG6306, USG6308, USG6310, USG6620, USG6630, USG6650, USG6660, USG6670, and USG6680

  • V500R002C20, V500R002C30, and V500R005C00

    Eudemon200E-N1D, Eudemon200E-N1, Eudemon200E-N2, Eudemon200E-N3, Eudemon200E-N5, Eudemon1000E-N3, Eudemon1000E-N5, Eudemon1000E-N6, Eudemon1000E-N7, and Eudemon1000E-N7E

Traffic Policy

Parameters for configuring a traffic policy. The parameters are as follows:

  • Terminal rate limiting: The options are IP address and User.
  • Terminal rate limits: rate limits of uplink and downlink traffic of terminals.
  • Overall traffic rate limit: rate limit of the overall uplink and downlink traffic
  • DSCP: Set a DSCP policy.
  • Traffic forwarding priority: Set the forwarding priority of traffic.

Viewing the Device Topology

Application Scenario

iMaster NCE-Campus presents network information in topology views, marks NEs with different colors to present NE alarm statuses, and displays alarm statistics. This visualizes the running status of the entire network and facilitates real-time monitoring.

Prerequisites

The content on the device topology page is based on the physical topology, which is dynamically discovered through the LLDP protocol. Before enabling this function, ensure that LLDP has been enabled on devices. You can enable or disable LLDP in the Others area on the Site > Device System Configuration page.

Feature Requirements

Device versions which support this function:

  • Router: V200R010C10 and later versions
  • Firewall: V600R006C00 and later versions
  • Switch: V200R013C00 and later versions
  • AP: V200R010C00 and later versions
  • WAC: V200R010C00 and later versions

Procedure

  1. Choose Design > Basic Network Design > Physical Topology from the main menu.
  2. The physical topology of each level is displayed.

    iMaster NCE-Campus provides the following functions on the topology page:
    • Dynamically discovers and displays the physical topology of a site. Displays the site's network topology when you double-click a site.
    • Displays devices in different icons based on the device types, and displays device status in different colors.
    • Displays information about a device, including the device name, ESN, model, role, and status when the cursor is moved over the device icon.
    • Allows you to view details of online cloud-managed devices when you right-click a device, (on the displayed device details page), to view device alarms, or to set the device role when you right-click a device.
    • Allows you to view the terminal information, terminal access location, terminal status, and IP address when you right-click an AP.
    • Displays the information about links between devices, including the names of end devices, interfaces and link status if the cursor is moved over the links.

      If the upper-layer devices connected to Fit APs and distributed APs (RRUs) are not managed by iMaster NCE-Campus, their uplink and downlink rates of interfaces and links cannot be viewed in the WAC information displayed in the topology view.

      The uplink and downlink rates of interfaces on a WAC cannot be checked.

    • Allow you to create a connection between two devices, set the background image, and save the current topology as a Visio file or image when you right-click the topology background.

  3. (Optional) Click on the left to expand the left pane, and set the topology.

    • On the Resource Tree tab page, the collected structure of the organizations and sites of the current tenant is displayed.
    • On the Legend & Filter tab page, you can filter topology information by object name, subnet type, and device status.
    • On the Layout tab page, you can adjust the topology display layout.

  4. (Optional) Click icons on the toolbar in the upper right corner of the topology view to perform some shortcut operations.

    Move the cursor to the corresponding button to display the shortcut key.
    • : Create a link.
    • : Move the topology view.
    • : Refresh the topology view.
    • : Lock the topology view.
    • : Set the topology display style, such as the theme, node style, connection style, subnet style, network display settings, label display, and alarm display settings. You can also save the preceding settings by using this shortcut.
    • : Set the topology link display content.
    • : Print the topology view.
    • : Expand the view to the full screen.

Configuring the SD-WAN Value-Added Feature

Precautions

The pages for configuring global parameters, AR device addition, WAN templates, physical interfaces, network access mode of sites, NTP, site export and import, email templates, and association between edge sites with RR sites are available only when the SD-WAN value-added feature is installed and the GRE tunnel mode for SD-WAN scenarios is selected on the Design > Basic Network Design > Network Settings > Tunnel Mode page.

Setting Global Parameters

This section describes how to set global parameters related to a tenant network.

You can configure the following features only when the tunnel mode is set to GRE tunnel on the Design > Basic Network Design > Network Settings > Tunnel Mode page.

Context

Global configuration parameters related to a tenant network include:

  • Parameters for physical networks: routing domain, transport network, IPsec encryption parameters, device activation security configuration, link failure detection configuration, traffic steering policy configuration, NTP and device administrator passwords.
  • Parameters for virtual networks: routing configuration, IP address pool, DNS configuration and Port configuration.
  • Parameters for collection configuration: application traffic, application quality and WAN link traffic.

Procedure

  1. Choose Design > Basic Network Design > Network Settings > WAN Global Configuration from the main menu.
  2. Click the Physical Network tab, and set global parameters related to physical networks.

    1. Select the RR source.
      • Self-built RR: Select this option if only communication between SD-WAN sites is required and tenant's own RR site is used.
      • MSP RR: Select this option if the tenant requires communication between the SD-WAN network and legacy MPLS VPN network.
    2. In EVPN tunnel mode, configure a routing domain and check whether IPsec encryption is enabled for the routing domain. By default, IPsec encryption is enabled on iMaster NCE-Campus. In EVPN mode, Internet and MPLS routing domains are used by default. If the default routing domains cannot meet requirements, you can create a routing domain as required.

    3. Configure a transport network to define a unified transport network type for communication between sites on the entire network.

      In EVPN tunnel mode, iMaster NCE-Campus provides the following transport networks by default: Internet, Internet1, MPLS, and MPLS1.

      If the default transport networks cannot meet requirements, you can click Create to create a transport network as desired.

      When MSP RR is selected and a new transport network is created, tenants can view and apply user-defined routing domains created by the MSP from the Routing Domain drop-down list.

    4. (Optional) If packets forwarded by IPsec tunnels need to be encrypted, configure the IPsec tunnel encryption algorithm.

      After the configuration is complete, all IPsec tunnels that are configured to encrypt packets use the same encryption mode.

      In EVPN tunnel mode, set Authentication algorithm, Encryption algorithm, Life Time and IPSec SA Generation Mode in the IPSec Encryption Parameters area.

    5. Configure email-based deployment as needed.

      In the Device Activation Security Settings area, set URL encryption key and URL Opening validity period.

    6. (Optional) To detect link failures of a site, set link failure detection parameters.

      In EVPN tunnel mode, set Detection packet sending interval, Number of failed detections and Priority of detection packets.

    7. (Optical) Set traffic steering parameters.

      Exercise caution when setting traffic steering parameters because modifying these parameters affects the real-time intelligent traffic steering. You are advised to modify these parameters when no service traffic is transmitted.

      In EVPN tunnel mode, set Modify period parameters, Switching period, Statistics Period, Flapping suppression, Maximum bandwidth utilization, and Symmetric forward.

    8. Configure NTP.

      Set global NTP parameters, including Time zone, NTP Server IP Address, and NTP authentication. If Config Default NTP is enabled globally, all sites use the globally configured time zone. By default, Config Default NTP is disabled.

    9. Click OK.

  3. Click the Virtual Network tab, and set global parameters related to virtual networks.

    1. Set BGP parameters.

      In EVPN tunnel mode, set AS number, Community Pool and IPv4 Dual-Gateway Interconnection Protocol.

      If the MSP RR is selected as the RR source, the AS number configured by the tenant administrator must be the same as that configured by the MSP administrator.

    2. Configure an IP address pool. You can configure different address pool segments for different network segment scales.

      IP addresses of WAN interfaces cannot be included in the IP address pool.

      • In EVPN tunnel mode, you do not need to configure the network scale, and only configure IP Pool. IPv4 and IPv6 address pools can be configured. An IPv4 address pool can be configured either in simple mode or advanced mode.

        IPv4 Simple mode:

        IPv4 Advanced mode:

        IPv6 pool:

        If an IPv6 network is deployed, the IPv4 address pool cannot be empty.

    3. Configure a DNS server group and IP addresses for DNS servers.

      In the DNS area, set DNS Server Group Name and DNS server IP Address.

    4. Customize port configurations.

      Enable Port Configuration, configure DTLS Server Port and STUN Server Port, enable Connection Source Port, and configure Scanning Start Port, Scanning Times, and Scanning Increment.

      • If the listening port for the DTLS server has been configured on devices, before modifying this port number, you need to delete rdb files from the devices and restart them. In this case, the modification can take effect on the devices.
      • When modifying the listening port for the DTLS server, ensure that the port to be configured is not in use. You can run the following command in the diagnostic view on a device to check the listening port for the DTLS server:
        display adp-ipv4 port-info
      • The modified Connection Source Port setting will not take effect on devices at sites that have been activated.

    5. Click OK.

  4. Click the Collection Configuration tab and set global parameters for statistics collection.

    Set Application Traffic, Application Quality, and WAN Link Traffic.

    Click OK.

Parameter Description

Table 4-195 Parameters on the Global Parameters page

Parameter

Description

Physical Network

Select RR source

Self-built RR: Select this option if only communication between WAN sites is required and tenant's own RR site is used.

MSP RR: Select this option if the tenant requires communication between the WAN network and legacy MPLS VPN network.

Routing Domain

Routing domain

A routing domain is used to define whether routes between different transport networks are reachable. Transport networks can communicate with each other in the same routing domain.

WANs provided by different carriers are usually constructed independently and cannot communicate with each other. Sometimes, the WANs provided by different carriers can communicate with each other. In this case, the WANs belong to the same routing domain.

iMaster NCE-Campus provides the following types of routing domains by default:

  • MPLS: MPLS leased line, which carries normal services of users in wired mode.
  • Internet: public Internet, which carries normal services of users in wired mode.

If the default types of routing domains cannot meet requirements, set a routing domain according to actual situations.

IPSec encryption

Whether to enable IPsec encryption for the current routing domain. The options are as follows:

  • Off: IPsec encryption is disabled. In this case, enable protocol 47 of all devices on the firewall.
  • On: IPsec encryption is enabled. In this case, use the encryption algorithm and password that are set in IPSec Encryption Parameters for encryption.

Transport Network

Type of the transport network to which a WAN-side physical link belongs. This parameter describes the transport networks with the same link quality attributes. It is used to identify networks of the same type provided by an ISP. The network connected by each physical link on the WAN side of a site maps a transport network.

IPSec Encryption Parameters

Protocol

Security protocol. The default value is ESP.

Authentication algorithm

Authentication algorithm.

Both SHA2-256 and SM3 are supported. SHA2-256 is used by default.

Encryption algorithm

Encryption mode of a link. AES128, AES256, and SM4 are supported. When the authentication algorithm is set to SM3, the encryption algorithm can only be SM4. AES256 is recommended. The key length of the AES-256 encryption algorithm is 256 bits, and the security level is higher than AES-128.

Life time

The lifetime enables IPsec encryption to be updated in real time, reducing the risk of being cracked and improving security.

IPSec SA generation mode

Whether to enable the IPsec SA generation mode. By default, the mode is disabled.

DH group

Diffie-Hellman (DH) public key algorithm. It is used to dynamically negotiate encryption keys between two sites to prevent traffic monitoring between tenants in the same RR in multi-tenant scenarios.

After the IPSec SA generation mode is enabled, you can select the DH Group. Currently, this parameter can be set to GROUP19, GROUP20, or GROUP21. The DH Group security levels are as follows: GROUP21 > GROUP20 > GROUP19.

Device Activation Security Settings

URL encryption key

Key for encrypting the URL in a deployment email. Email-based deployment will be successful only after you click the URL in the received email on your PC and enter this key.

URL opening validity period

Validity period for a device to register its ESN with iMaster NCE-Campus. The timer starts once a deployment email is sent.

If the device ESN is not obtained, the device is added to iMaster NCE-Campus based on the device model. After a site is created and a deployment email is sent, the device checks whether the URL is valid. If so, the device registers its ESN with iMaster NCE-Campus.

Link Failure Detection Parameter Configuration

Modify detection parameters

Whether to modify detection parameters. Link detection is periodically performed between gateways of WAN sites under a certain tenant. In the EVPN tunnel mode, GRE packets are sent to detect link connectivity.

If this function is disabled, the device sends detection packets at the default interval. If the number of detection failures exceeds the default value, the link is considered faulty. If this function is enabled, you can define the interval for sending detection packets and the maximum number of detection failures permitted. Generally, you do not need to set this parameter. Use the default value.

Detection packet sending interval

Interval at which an AR sends detection packets, in milliseconds. The value is in the range 10 to 10000. The default value of this parameter is 1000 milliseconds.

NOTICE:

When the interval for sending probe packets is changed, the change may not take effect on all devices on the network at the same time. As a result, service flapping may occur within a short period of time. In addition, the change will affect the number of established EVPN connections, which may interrupt services if the number of EVPN connections cannot meet the network scale requirements. In normal cases, the default value is used.

For details about the mappings between the interval and EVPN connection specifications, see Mappings Between Probe Packet Sending Interval and Device EVPN Connection Specifications.xlsx. Before changing this setting, ensure that the EVPN connection specifications of all devices meet the requirements of the live network. The rules for establishing EVPN connections between sites on the live network are as follows:

  1. An EVPN connection is established between every two ports that belong to the same routing domain but different sites.
  2. An EVPN connection cannot be established between two ports that are not in the same routing domain.
  3. The number of EVPN connections on a device at a dual-gateway site is the total number of device connections at the site.

For example, if the default number of EVPN connections is 1000 and the required number of EVPN connections on a device is 512, ensure that the number of EVPN connections on the device is greater than or equal to 512 after the interval for sending probe packets is changed.

If the hub-spoke topology model is adopted, pay attention to the number of EVPN connections of the hub site. When the full-mesh topology model is adopted, pay attention to the number of EVPN connections of all sites.

Number of failed detections

Number of detection failures permitted before an AR automatically switches the link. The value is in the range 3 to 10.

If Modify detection parameters is disabled, the default value of this parameter is 6.

Priority of detection packets

Priority in the IP header of a detection packet. A numerically higher value indicates a higher priority. This parameter is available only when the EVPN tunnel mode is selected.

Traffic Steering Policy Configuration

Modify period parameters

Whether to customize the intelligent traffic steering policy.

Exercise caution when setting this parameter because the modification affects real-time route selection in the intelligent traffic steering policy. You are advised to modify this parameter when no service traffic is available.

Switching period

Period after which the traffic is switched to another link. If the quality of a link cannot meet requirements of a certain service or the bandwidth usage exceeds the threshold, the CPE starts the link switching timer. When the timer times out, the service traffic is switched to another link. The default value of the switching period is 5 seconds.

Statistics Period

Interval for checking link quality. The value of this parameter ranges from 1 to 3600 and must be less than or equal to the value of Switching period.

Flapping suppression

Unstable network link quality may result in frequent link switchovers at the sites where an intelligent traffic steering policy is applied. To prevent this situation, the system requires that services be transmitted on a new link for at least one flapping suppression period before the services are switched back from the new link to the original link. The value range is from 2 to 131070, and the default value is 30 seconds. The value must be at least twice the switching period.

Maximum bandwidth utilization

This parameter applies to the load balancing routing scenario of the intelligent traffic steering policy. When the service traffic of a link reaches the maximum bandwidth utilization, load balancing can be used for route selection.

You can set the maximum bandwidth usage as required. By default, the maximum bandwidth utilization is 95%. The value ranges from 50% to 100%. This parameter is available only when the EVPN tunnel mode is selected.

Symmetric forward

Check whether the paths selected during traffic sending and receiving are the same. This parameter is enabled by default. This parameter is available only when the EVPN tunnel mode is selected.

  • In symmetric routing mode, a packet traverses from a source to a destination in one path and takes the same path when it returns to the source. The master site selects a path for traffic forwarding, and the slave site follows the route selection result of the master site to ensure that the same service flow is forwarded along the same path. The master or slave role of a site is determined based on specific rules. By default, the site with a smaller TNP bandwidth assumes the master role; if two sites have the same TNP bandwidth, the site with a smaller site ID assumes the master role. The Smaller site ID prioritized function is enabled on the controller by default and can be configured as needed.
  • Asymmetric path selection means that the two sites that communicate with each other independently select a forwarding path. In this case, the transmit and receive paths of the same service flow between two sites are different. For example, during LB route selection, the MPLS line from site1 to site2 is not congested for the application of A, MPLS line transmission is selected. When the MPLS line between site2 and site1 is congested and the Internet is not congested, the Internet line is selected to transmit A traffic.
    NOTE:
    • This switch takes effect only in load balancing mode. In the IWG scenario, the route selection between the branch and IWG is irrelevant to this switch.
    • AR8000 series switches do not support symmetric uplink selection.

The same transmission network preferred.

By default, if a site has multiple TN connections, the secondary-priority line selected by the site with a small site ID may belong to different TNs. As a result, the link quality is poor. After this function is enabled, the eNodeB preferentially selects links with the same TN to ensure link quality.

Small site ID preferred

By default, the route selection priority is dominated by the site with a small site ID. In a Hub-Spoke scenario, the Hub site has a small site ID. If the Hub site takes the lead in route selection, the Spoke site may not be able to select different links for different applications. To use the Spoke site as the dominant route selection function, disable the Small Site ID Preferential Switch.

NTP

Time Zone

Time zone of devices at a site.

NTP client mode
  • Manual configuration: A site functions as an NTP client and the NTP server needs to be manually specified. In the DSVPN tunnel mode, you are advised to configure a hub site as an NTP client which synchronizes the clock with the NTP server on the public network. In the EVPN tunnel mode, you are advised to configure an RR as an NTP client and synchronize the clock with the NTP server on the public network.
  • Disabled: A site does not function as an NTP client and does not perform clock synchronization.

NTP server IP address

IP address of the NTP server.

NTP authentication

Whether to enable the authentication function. If NTP identity authentication is enabled on the NTP server, the authentication function must also be enabled on the NTP client. Otherwise, clock synchronization cannot be performed.

Authentication mode

Authentication mode, which can be MD5 or HMAC-SHA256. The authentication mode selected must be the same as that enabled on the NTP server. The MD5 authentication mode may pose potential security risks. As such, the HMAC-SHA256 authentication mode is recommended.

Authentication Password

Password used for NTP identity authentication.

Authentication key ID

Key ID used for NTP identity authentication.

Virtual Network

Routing

AS number

Local AS number. Under the same tenant account, the sites that are deployed using the iMaster NCE-Campus belong to the same AS.

Community pool

This is a resource management pool. You can configure community pool to assign the community attribute values to services.

The current community pool mainly involves WAN network iBGP, RR management, Internet access, mutual access, area management. When the community pool is insufficient, a maximum of 10 community attribute pools can be added. After the configuration, the community pool that has been used cannot be updated or deleted. The unused community pool can be deleted.

Dual-Gateway Interconnection Protocol

Protocol used to connect dual gateways. In the dual-gateway scenario, you can configure a routing protocol (OSPF or IBGP) for exchanging routing information between the two gateways.

NOTE:
  • Changing the dual-gateway interconnection protocol does not affect existing sites under the tenant, and applies only to newly created sites.
  • This configuration takes effect on devices when the sites where they belong are added to VPNs. Once a site is added to a VPN, iMaster NCE-Campus delivers the dual-gateway interconnection protocol specified in the global configuration to devices at the site. Changing this configuration does not affect sites that have been added to VPNs.

IP Pool

IPv4 pool

iMaster NCE-Campus needs to allocate IP addresses to sites when automatically orchestrating services such as overlay tunnels, overlay WAN routes, and site-to-Internet access.

Plan address pools based on the network scale. The number of required address pools increases with the number of sites. For details about the relationship between them, click Details.

After you set reserved IP addresses, iMaster NCE-Campus automatically assigns an IP address according to the following rules:

One or more IP address pools can be configured and the IP addresses in these address pools are automatically divided into multiple address segments, which are used by the following interfaces:

  • Loopback interface on a CPE.
  • Interface of an interworking tunnel.
  • Interface of an interlink between dual gateways.
  • Interface of an EVPN tunnel.

In EVPN mode, you can select Simple mode or Advanced mode for an IP address pool. If Simple mode is selected, all IP addresses are assigned from the same address pool. If Advanced mode is selected, IP addresses can be assigned from IP pool, Interworking Tunnel, and Interlink.

In advanced mode, IP pool is used to allocate IP addresses for loopback interfaces on CPEs and interfaces at both ends of EVPN tunnels; Interworking Tunnel is used to allocate IP addresses for interfaces at both ends of a tunnel connecting the underlay domain to the overlay domain on a single CPE; Interlink is used to allocate IP addresses to interfaces at both ends of a link connecting dual gateways.

IPv6 pool

IPv6 address pool. If IPv6 is required on CPEs, interworking tunnels, and internal links, you need to configure an IPv6 address pool.

  • Interworking address pool: allocates IP addresses to interfaces at both ends of interworking links.
  • Interlink address pool: allocates IP addresses to interfaces at both ends of interlinks.
  • Link-local address pool: allocates link-local addresses to CPEs.

The prefix of IP addresses in the interworking and interlink address pools must be FD00::/8, and the prefix of IP address in the link-local address pool must be FE80::/10.

DNS

DNS Server Group Name

Domain Name System (DNS) used for domain name resolution. The DNS server is usually deployed on a public network. A maximum of 16 DNS groups can be configured for a tenant, and each group can be configured with a maximum of six DNS server IP addresses.

DNS Server IP Address

You can plan multiple DNS server IP addresses. A DNS server IP address is used when a LAN interface is configured. If a CPE is enabled as the DHCP server, you can select a DNS server group name for the CPE. The DNS server address is sent to a client on the LAN side via a DHCP response.

Port Configuration

DTLS Server Port

Listening port for a DTLS server. An RR establishes a DTLS connection with a CPE to set up a control channel for TNP information exchange between them. When an RR goes online, iMaster NCE-Campus will deliver the command for configuring the listening port for the DTLS server to the RR for the RR to set up control channels with CPEs.

By default, the listening port for the DTLS server is 55100. You can modify this setting as needed.

STUN Server Port

Listening port for the STUN server. In most cases, an RR is configured as a STUN client and the branch gateway CPE is configured as a STUN server. To detect whether a NAT device is deployed between the RR and CPE, enable the STUN server function on the RR and configure the IP address and UDP port number listened by the STUN server.

By default, the listening port for the STUN server is 3478. You can modify this setting as needed.

Connection Source Port

Source port for sending NAT detection, hole punching, and KA packets. You can also configure the scanning times and an increment for port scanning.

Collection Configuration

Application traffic

Whether to enable global traffic statistics collection. After this function is enabled, inter-site traffic and inter-site application traffic at all sites are collected.

Application quality

Whether to enable application quality statistics collection. After this function is enabled, AQM distribution statistics of all applications are collected and worst 5 applications by AQM are listed.

WAN link traffic

Whether to enable inter-site traffic monitoring. After this function is enabled, traffic passing all inter-site links is monitored in real time.
Table 4-196 Mapping between mask lengths and network scales

Network Scale/Number of Sites

Recommended Configuration (Single Network Segment)

2-10

/23

11-30

/22

31-60

/21

61-120

/20

121-250

/19

251-500

/18

501-1000

/17

1000+

/16

Inter-Site Connection Diagram

Adding AR Devices

Context

An administrator can configure and manage devices only after adding the devices to iMaster NCE-Campus.

Procedure

  1. Choose Design > Site Agile Deployment > Device Management from the main menu.
  2. Click Add in Device Management.
  3. iMaster NCE-Campus provides two methods for device addition: Manual Creation and Batch Import.

    • Manual Creation is applicable to the scenarios where a small number of devices at the same site need to be added. You can select Device Model or ESN to add a device. The detailed operations are described below.
      • Device model mode
        1. Choose NETCONF protocol.
        2. Choose Site.
        3. Import device ESNs.
          • In the email deployment scenario, you do not need to enter the ESN of the device.
          • If the ESN of a device is used and the device cannot be added, contact the system administrator or MSP administrator to clear the ESN.
        4. Click OK.

          For an online device, you can click the device name to view the device status. In addition, you can also reboot the device or click Command Line to run commands on the device.

          After the remote DR switchover, the link between the original online device and iMaster NCE-Campus will be unavailable. iMaster NCE-Campus will bring the link offline, and the device will automatically go online again. It is expected that the device will be updated to the normal state after 10 to 20 minutes.

      • ESN mode

        1. Choose NETCONF protocol.
        2. Choose Site.
        3. Set Mode to ESN, and set ESN, Name, Role, Description, Asset ID and Performance. Then click OK.

    • Batch Import is applicable to scenarios where a large number of devices need to be added. A maximum of 1000 devices can be added at a time.

      1. Choose NETCONF protocol.
      2. Download and fill in the template, upload the template, select the devices whose ESNs need to be uploaded in the Result window, and click OK.

Follow-up Procedure

  • Restart a device and restore the device configuration.

    After selecting an online device, you can use the Reset to Deployment State and Restart functions to restore default settings or restart the device.

    This operation has high risks and cannot be rolled back. Exercise caution when you perform this operation.

Parameter Description

Table 4-197 Parameters on the Add Device page

Parameter

Description

Addition method

Method of adding a device. The options are as follows: Manually Creation and Batch Import.

Mode
Mode of adding a device. The following modes are supported:
  • ESN: If you have obtained the ESN of a device, add the device in ESN mode.
  • Device model: If you have not obtained the ESN of a device, add the device based on its model. This mode is generally used for pre-configuration. The selected device type must be consistent with the actual device type.

Device information

ESN

ESN of a device. It is the unique identifier of a device. You can obtain the ESN from the factory configuration list of the device or run the display esn command to obtain it.

Name

Unique name of a device. If you add a device to iMaster NCE-Campus based on its device model, the device name is automatically generated by iMaster NCE-Campus when you select the device model. If you add a device to iMaster NCE-Campus based on its ESN without setting a device name, the device ESN is used as the device name by default. A device name can contain a maximum of 64 characters.

Configuring a WAN Template

Configuring a WAN-side Site Template

You can configure the following features only when the tunnel mode is set to GRE tunnel on the Design > Basic Network Design > Network Settings > Tunnel Mode page.

Context

When creating multiple sites, generally, you need to configure the same gateway type, the same number of WAN links, and the same transport network for them. To improve efficiency, you can customize a link template to cover the repeated information and apply the link template to sites during site configuration. Sites can be classified based on link templates. When configuring a policy or a policy template, you can quickly find a site by specifying a link template. Once a link template is applied to a site, only the template name and description can be modified. You need to properly plan the data specified in a link template.

Table 4-198 describes the default link templates provided by iMaster NCE-Campus. If the default templates can meet your requirements, you do not need to customize a template by yourself. Otherwise, you can create a link template as desired.

The default template cannot be modified or deleted. You can only copy the template.

Table 4-198 Default link templates provided by iMaster NCE-Campus

Template Name

Template Description

WAN Link (Device, Port, Transport Network)

Inter-CPE Link (Device, Port)

Topology

Single_gateway_mixed_links

Single gateway with an Internet link and an MPLS link

Internet (Device1, GE0/0/0, Internet)

MPLS (Device1, GE0/0/1, MPLS)

-

Single_gateway_mpls_link

Single gateway with an MPLS link

MPLS (Device1, GE0/0/0, MPLS)

-

Single_gateway_internet_link

Single gateway with an Internet link

Internet (Device1, GE0/0/0, Internet)

-

Single_gateway_dual_internet_links

Single gateway with dual Internet links

Internet1 (Device1, GE0/0/0, Internet)

Internet2 (Device1, GE0/0/1, Internet)

-

Dual_gateways_mixed_links

Dual gateways with an MPLS link and an Internet link respectively

Internet (Device1, GE0/0/0, Internet)

MPLS (Device2, GE0/0/0, MPLS)

Device1: GE0/0/1, Device2: GE0/0/1

If you configure the same transport network for physical links, communicate with each other through the links. It is because that, after the same transport network is configured, iMaster NCE-Campus generates logical links for physical links of the same type between devices at parent and child sites, implementing site interconnection.

Prerequisites

Global parameters of sites have been configured. For details, see Setting Global Parameters.

Procedure
  1. Choose Design > Basic Network Design > Template Management from the main menu. Click WAN Template.
  2. Click WAN Link Template.
  3. Click Create to create a site template.
  4. Set Template name to the name of the site template to be created.
  5. Set Gateway to the desired gateway type.
  6. Specifies whether to enable the function of Multiple sub-interfaces.
  7. In the WAN Link area, click Create to create a link between a gateway and the WAN.

    The parameters that need to be set for the link between the gateway and WAN include the link name, device, port, transport network of the WAN link, and link role.

    At most 256 sub-interfaces can be created for a single gateway, and at most 512 sub-interfaces can be created for dual gateways.

    EVPN mode:

  8. If Gateway is set to Dual Gateways, configure an interlink between dual gateways. Otherwise, skip this step.

    1. If the LAN-side Layer 2 ports need to be reused for establishing an interlink between the dual gateways, set Use LAN-side L2 interface to .
      • STP is enabled on CPEs by default. If an interlink between dual gateways uses two Layer 2 ports, the two ports are added to the same VLAN. If a loop occurs, STP sets one port to the Block state. In this case, if a user uses this blocked port on the LAN side, the user traffic may be interrupted. Therefore, the ports used by the interlink between dual gateways must be different from those transmitting user service traffic on the LAN side.
      • If an interlink between dual gateways uses Layer 3 ports, you do not need to enable Use LAN-side L2 interface.
    2. Set a VLAN ID. This parameter specifies the VLAN to which Layer 2 ports at both ends of an interlink need to be added.
    3. Click Create, configure an interlink between dual gateways, and configure the ports at both ends of the interlink.

      At most two interlinks can be created between dual gateways.

  9. Click OK.
Follow-up Procedure
Table 4-199 Follow-up procedure of WAN link template configuration

Function

Operation Scenario and Constraint

Procedure

Modifying a WAN link template

The template name, gateway type, WAN link information need to be modified. The default templates provided by iMaster NCE-Campus cannot be modified.

Click in the Operation column of the WAN link template list to modify the target template.

Deleting a WAN link template

WAN link templates can be deleted. The default templates provided by iMaster NCE-Campus cannot be deleted.

Click in the Operation column of the WAN link template list to delete the target template.

Cloning a WAN link template

You can quickly create a WAN link template by cloning an existing template. This improves configuration efficiency.

If you perform the following operations after cloning a template, the cloned template may fail to be applied to sites associated with the source template:

  • Modify the gateway type.

  • Modify or delete WAN links.

  • Modify inter-CPE links.

Click in the Operation column of the WAN link template list to clone the target template.
Parameter Description
Table 4-200 Parameters on the Template > WAN Link Template tab page

Parameter

Description

Data Plan in Advance

Template name

Name of a template.

Y

Gateway

Type of the gateway at a site.

  • Single Gateway: If the gateway service traffic is small and low requirements are imposed on reliability, a single gateway can be deployed.
  • Dual Gateways: For sites with high reliability requirements, dual gateways can be deployed.

Y

Multiple sub-interfaces

Whether to enable the multiple sub-interfaces function. If multiple sub-interfaces need to be created on the WAN-side link of the gateway to connect to the WAN side, you need to enable multiple sub-interfaces on the device. After this function is enabled, a maximum of 256 sub-interfaces can be created on a single gateway, and a maximum of 512 sub-interfaces can be created on two gateways.

Y

WAN Link

Name

Name of a WAN link.

Y

Device

Name of the gateway at a site.

Y

Interface

Type and number of a physical interface used by a WAN-side link.

Type of a physical interface includes:

  • GE: Ethernet interface and Ethernet sub-interface, Layer 3 Eth-Trunk interface.
  • FE: Ethernet interface and Ethernet sub-interface, Layer 3 Eth-Trunk interface.
  • XGE: Ethernet interface and Ethernet sub-interface, Layer 3 Eth-Trunk interface.
  • LTE: G/LTE/5G interface.
  • xDSL (ATM): ADSL interface or G.SHDSL interface (working in ATM mode by default).
  • xDSL (PTM): VDSL interface (working in PTM mode by default).
  • E1-IMA (ATM): G.SHDSL interface (ATM mode) and E1-IMA interface, E1-IMA sub-interface.
  • Ima-group: G.SHDSL interface (ATM mode) and E1-IMA interface, Ima-group sub-interface.
  • Serial: serial interface, FR sub-interface.
  • Eth-Trunk
  • LoopBack
    NOTE:
    1. The loopback interface is used only as a transport network interface and is not configured with any services.
    2. By default, the overlay tunnel function is enabled on virtual links with loopback interfaces at both ends, and cannot be disabled.

Y

Sub Interface

Whether to enable the sub-interface of the device.

-

Overlay Tunnel

Whether to enable the overlay tunnel function. If this function is enabled, an overlay tunnel is created on the WAN link.

Y

Sub Interface Index

Index of the sub-interface.

This parameter is available only after Sub Interface is enabled.

-

Transport Network

Type of the transport network to which a WAN-side physical link belongs. Transport networks of the same type must have the same link quality attributes. It identifies a type of networks provided by the same ISP. The network connected by each physical link on the WAN side of a site maps a transport network.

Transport network. If the transport network type does not meet the requirements, create a transport network on the Global Parameters page.

Y

Role

Active or standby link. With the active and standby links are configured, data travels only along the active link by default. If the active link fails, data moves to the standby link.

When multiple WAN links are configured for a single gateway, specify a WAN link as the active or standby link. At least one active link must be configured. A maximum of one standby link (usually, an LTE/5G link, which has the lowest priority) can be used as the escape link. When both the active and standby links fail, traffic is forwarded through the escape link.

In the dual-gateway scenario, the role of all WAN links is active by default. The standby role can be configured only in the single gateway scenario and for only one WAN link, and the active role needs to be configured for at least one WAN link.

Y

Advanced parameters

Click Configuration to configure iMaster NCE Southbound interface service. The default options of iMaster NCE Southbound interface service are Southbound load balancing floating IP and Southbound service IP address configured during installation planning. If the system administrator has enabled customized other southbound access services, you can select other access services in the site template.

NOTICE:

In the NAT scenario, the file server IP address in the installation plan must be the same as the southbound service IP address. If the value of iMaster NCE Southbound interface service is set to be different from that of the file server, the system sends the IP address of iMaster NCE-Campus to the device based on the value of iMaster NCE Southbound interface service.

Y

Inter-CPE Link

Use LAN-side L2 interface

Whether to reuse Layer 2 physical interfaces on the LAN side as the physical interfaces of the interlinks between two gateways. This parameter is available only when Gateway is set to Dual Gateways.

  • If no direct link is configured between two gateways, links on the LAN side need to be reused as interlinks. iMaster NCE-Campus creates a logical link for each VPN.
  • If direct links are configured between two gateways, links on the LAN side do not need to be reused as interlinks.

Y

VLAN ID

VLAN for the interlinks between two gateways. This parameter is available only when Use LAN-side L2 interface is enabled. In the dual-gateway scenario, iMaster NCE-Campus creates a separate sub-interface for each VPN on the interfaces of the interlinks between the two gateways to isolate the VPNs. The number of VLANs must be the same as that of VPNs. The value ranges from 1-4086 to 9-4094, and the difference must be greater than or equal to 8 and less than or equal to 300. A maximum of 16 VLAN ranges can be configured, and the total number of VLANs cannot exceed 301.

-

Device1 Interface

Physical interface used by interlinks between two gateways. If two interfaces on a gateway are used to connect to the peer gateway, the two interfaces must be of the same type. The interface on a gateway and that on the peer gateway, which are used for connecting the two gateways, must be of the same type.

The interface type varies according to whether a direct link exists between two gateways:

  • If a direct link exists between two gateways (that is, Use LAN-side L2 interface is disabled), Layer 3 interfaces must be used. After two links are created, iMaster NCE-Campus automatically bundles the two links into an Eth-Trunk to ensure link reliability.
  • If no direct link exists between two gateways (that is, Use LAN-side L2 interface is enabled), Layer 2 interfaces must be used.

-

Device2 Interface

-

Configuring an HWTACACS Server Template

Procedure
  1. Choose Design > Basic Network Design > Template Management, from the main menu and click Policy Template. Choose HWTACACS Server from the navigation pane.
  2. Click Create, set parameters, and click OK.

Parameter Description
Table 4-201 Policy Template (HWTACACS server)

Parameter

Description

Name

Unique identifier of an HWTACACS server template.

Use the built-in server

Meaning: Whether to configure iMaster NCE-Campus as an HWTACACS server.

If this function is enabled, you can configure either the SM or a remote server as the primary or secondary authentication component. The SM is the controller deployed at the headquarters.

Primary authentication server address/Port

Meaning: IP addresses and port numbers of the primary and secondary authentication servers.

Constraints:

If only the address and port number of the primary authentication server are configured and those of the primary authorization server are not specified, authenticated users only have the default device permissions, which can be referred to in the corresponding device product documentation.

Secondary authentication server address/Port

Primary authorization server address/Port

IP addresses and port numbers of the primary and secondary authorization servers.

Secondary authorization server address/Port

Primary accounting server address/Port

IP addresses and port numbers of the primary and secondary accounting servers.

Secondary accounting server address/Port

Include domain names in usernames

Meaning: Whether to include domain names in usernames carried in request packets sent by devices to the TACACS server.

  • If this function is enabled, devices encapsulate domain names in usernames when sending packets to a TACACS server. The default domain name is default_admin.
  • If this function is disabled, devices do not encapsulate domain names in usernames when sending packets to a TACACS server.

Default setting: disabled

Device source IP address

After the function is enabled, you need to configure a device source IP address on the Provision > Physical Network > Site Configuration > Site Configuration > Switch > Advanced > Device Source IP Address Configuration page.

Key

Meaning: Shared key of the HWTACACS server.

Value range: The value is string of 1 to 16 characters, and can contain letters, digits, and special characters.

Constraints: The value cannot contain spaces and question marks (?), and cannot contain only asterisks (*). For security purposes, it is recommended that the key contain at least six characters and contain at least two types of the following: lowercase letters, uppercase letters, digits, and special characters.

Configuring Interconnection with a RADIUS Server

Context

To use a RADIUS server to authenticate access users, you need to configure interconnection between iMaster NCE-Campus and the RADIUS server.

Procedure
  1. Choose Design > Basic Network Design > Template Management and click the Police Template tab.
  2. Choose WAN RADIUS Server from the navigation pane and click Create. On the Create RADIUS Server page, set the IP address and port number of the primary authentication server. You are advised to set the IP address and port number of the secondary authentication server if a secondary server is available. Then, set the IP addresses and port numbers of the primary and secondary accounting servers, and decide whether to enable Include domain name as needed.

  3. Click Set next to Key to configure a key for the RADIUS server, and click OK.

  4. Click OK.
Follow-up Procedure

Configure 802.1X authentication. For details, see Configuring 802.1X Authentication.

Creating an IPsec Profile

Context

To configure an IPv6 over IPv4 GRE over IPsec tunnel for secure data transmission between the headquarters and branches or between branches, you need to create an IPsec profile first.

Procedure
  1. Choose Design > Basic Network Design > Template Management from the main menu. Click WAN Template.
  2. Click the WAN IPSec Template tab.
  3. Click Create.
  4. In the Create IPSec Profile dialog box, set parameters of an IPsec profile.

  5. Click OK.
Follow-up Procedure
Table 4-202 Follow-up procedure after an IPsec profile is created

Function

Operation Scenario and Constraint

Procedure

Deleting an IPsec profile

An IPsec profile that is not bound to any GRE tunnel can be deleted.

On the WAN IPSec Template tab page, select the IPsec profile to be deleted and click in the Operation column to delete it.

Modifying an IPsec profile

An IPsec profile that is not bound to any GRE tunnel can be modified.

On the WAN IPSec Template tab page, select the IPsec profile to be modified and click in the Operation column to modify it.
Parameter Description
Table 4-203 Parameters for creating a WAN IPsec profile

Parameter

Description

Data Plan in Advance

Template Name

Name of an IPsec profile.

Y

IKE Configuration

IKE Version

IKE version. Both IKEv1 and IKEv2 are supported.

NOTE:

IKEv2 is recommended.

Y

Authentication Mode

Authentication method used by IKE peers. Currently, only the pre-shared key (PSK) authentication is supported.

Y

Pre-shared Key

Pre-shared key used for authentication during IKE negotiation. You need to configure the same PSK on the local and remote devices.

Y

Key Confirm

Confirm the PSK used by IKE peers.

-

Authentication Algorithm
Authentication algorithm used in IKE negotiation. The options are as follows:
  • SHA1: indicates HMAC-SHA-1
  • SHA2-256
  • SHA2-384
  • SHA2-512
  • SM3
    NOTE:

    Only IKEv1 supports SM3.

SHA-1 uses a 160-bit key. SHA-256, SHA-384, and SHA-512 use 256-bit, 384-bit, and 512-bit keys, respectively. A larger number of key bits indicate a more secure algorithm but a slower calculation speed.

By default, the SHA2-256 authentication algorithm is used.

You are advised to use an authentication algorithm rather than SHA-1, because SHA-1 is not secure enough.

Y

Encryption Algorithm
Encryption algorithm used in IKE negotiation. The options are as follows:
  • AES-128: indicates that the IKE proposal uses the AES encryption algorithm with a 128-bit key.
  • AES-192: indicates that the IKE proposal uses the AES encryption algorithm with a 192-bit key.
  • AES-256: indicates that the IKE proposal uses the AES encryption algorithm with a 256-bit key.
  • SM4: SM4 is an encryption algorithm released by the State Encryption Administration of China.

By default, the AES-256 encryption algorithm is used.

Y

DH Group
Diffie-Hellman (DH) group used in IKE negotiation.
  • Group1: 768-bit Diffie-Hellman group.
  • Group2: 1024-bit Diffie-Hellman group.
  • Group5: 1536-bit Diffie-Hellman group.
  • Group14: 2048-bit Diffie-Hellman group.
  • Group 19: 256-bit Elliptic Curve Groups modulo a Prime (ECP) DH group

    Group20: 384-bit ECP Diffie-Hellman group.

  • Group21: 521-bit ECP Diffie-Hellman group.
  • Group 24: 2048-bit Diffie-Hellman group that includes a 256-bit sub-group is used during IKE negotiation.

Group1 provides the weakest encryption and Group14 provides the strongest encryption.You are advised to use a DH group with a high security level.

By default, Group14 is used.

Y

IPSec Configuration

Security Algorithm

Security protocol used by IPsec. Currently, only the ESP protocol is supported.

Y

ESP Authentication Algorithm
Authentication algorithm used by the ESP protocol. The options are as follows:
  • SHA1: SHA-1 authentication algorithm
  • SHA2-256: SHA-256 authentication algorithm
  • SHA2-384: SHA-384 authentication algorithm
  • SHA2-512: SHA-512 authentication algorithm
  • SM3: SM3 authentication algorithm
    NOTE:
    1. Only IKEv1 supports SM3.
    2. If the authentication algorithm is set to SM3 or SHA-1, the ESP encryption algorithm must be set to SM1 or SM4.

By default, the SHA2-256 authentication algorithm is used.

You are advised to use an authentication algorithm rather than SHA-1, because SHA-1 is not secure enough.

Y

ESP Encryption Algorithm
Encryption algorithm used by the ESP protocol. The options are as follows:
  • AES-128: indicates that the IKE proposal uses the AES encryption algorithm with a 128-bit key.
  • AES-192: indicates that the IKE proposal uses the AES encryption algorithm with a 192-bit key.
  • AES-256: indicates that the IKE proposal uses the AES encryption algorithm with a 256-bit key.
  • SM4: SM4 is an encryption algorithm released by the State Encryption Administration of China.
NOTE:
  1. SM4 algorithms is supported only in IKEv1.
  2. When the ESP encryption algorithm is set to SM4, the ESP authentication algorithm must be set to SHA-1 or SM3.

By default, the AES-256 encryption algorithm is used.

Y

(Optional) Configuring an Email Template

In the email-based deployment scenario, deployment emails need to be configured on multiple CPEs. That is, emails with the same content including the subject and body format need to be configured on different CPEs. To reduce repeated operations, you can customize an email template and apply an email template when setting email-based deployment parameters on a CPE. Then the parameters are set automatically.

iMaster NCE-Campus provides a default email template ZTP email template. If the default email template can meet the requirements or the email-based deployment scenario is not involved, you can skip this section. Otherwise, you need to customize an email template.

Procedure
  1. Choose Provision > Physical Network > ZTP from the main menu.
  2. Click Email Template.
  3. Click Create to create an email template.

    In normal cases, you only need to set Email Template, Subject, and Content. You can modify other parameters as needed.

  4. Click OK.
Parameter Description
Table 4-204 Parameters on the Email Template tab page

Parameter

Description

Email template

Name of an email template. If multiple CPEs need to be deployed, the personnel responsible for email-based deployment can create an email template to configure general information for the CPEs.

Subject

Title of a deployment email.

Content

Body of a deployment email. You are advised to change the default settings only when required.

To add a fixed field to a deployment email, click the label of the target field:

  • Site Name: specifies a site name.
  • Device Name: specifies a device name.
  • Device ESN: specifies the ESN of a device.
  • Link Information: indicates information about an interface for network connection.
  • Port Description: indicates description of a network connection interface. This field can be configured only after Link Information is configured.
  • Expiration Time: indicates expiration time of a deployment email.
    NOTE:

    The preceding fields are only displayed in the deployment email body, and they do not affect the information in the URL of the deployment configuration page in the email.

Default template

Whether to configure a template as the default email template. If this parameter is enabled, the current template is selected by default when you configure the Send Email function for a site.

Recipients

Recipient list. If a template is selected for a deployment email, the recipients of the deployment email are automatically set to those in the template. The recipients can be changed in the deployment email.

CC

CC list. If a template is selected for a deployment email, the CCs of the deployment email are automatically set to those in the template. The CCs can be changed in the deployment email.

Configuring a Physical Interface

When a site gateway connects to a WAN-side device, the interconnection mode of physical interfaces needs to be planned. When the site gateway connects to a LAN-side device and the connected device interface works in non-auto-negotiation mode, you need to configure the LAN interface of the gateway to work in non-auto-negotiation mode.

An Eth-Trunk is a logical interface that is formed by bundling multiple Ethernet interfaces to increase the link bandwidth and reliability.

Configure an Eth-Trunk for a site if the site is connected to a transport network through an Eth-Trunk. Eth-Trunks can be connected to LAN-side or WAN-side devices in different VNs of a site or directly connected to devices in a dual-gateway site. Eth-Trunks can be classified into Layer 2 Eth-Trunks and Layer 3 Eth-Trunks. You can configure Layer 2 or Layer 3 Eth-Trunks based on network applications.

Prerequisites

  1. Global parameters have been configured for the site. For details, see Setting Global Parameters.
  2. Devices have been added. For details, see Adding AR Devices.

Procedure (Configuring a Physical Interface)

  1. Choose Provision > Physical Network >WAN Underlay from the main menu.
  2. Click the Physical Interface tab.
  3. Select a device name from the device list on the left and click Create.
  4. On the Create Interface page, configure device interface information. You need to set parameters according to the interface type.

    If a GE combo port on an AR8000 series router is configured to work as an optical port in non auto-negotiation mode, the non auto-negotiation configuration as well as the specified port rate will not be delivered to the router.

  5. Click Confirm.

Procedure (Configuring an Eth-Trunk Interface)

  1. ChooseProvision > Physical Network >WAN Underlayfrom the main menu.
  2. Click the Eth-Trunk tab.
  3. Select a device name from the device list on the left and click Create.
  4. Enter basic information about the Eth-Trunk.

  5. Click OK.

Parameter Description

Table 4-205 Physical interface parameters

Parameter

Description

Device

Device name.

Port switch

Type of the LAN interface or WAN interface. The value can be L3 or L2. Only when the interface is GE/FE/XGE, you can select L3 or L2. For other interfaces, L3 is selected by default. LAN interfaces support only GE, FE, and XGE interfaces.

Interface

Type and number of the physical interface. This parameter value cannot be changed.

APN

Multi-APN function of an LTE cellular interface used to implement data and VoIP communication. This parameter is available only when Interface is set to LTE.

PVC(VPI/VCI)

PVC with a specified virtual path identifier (VPI) or VCI. This parameter is available only when Interface is set to xDSL (ATM).

Negotiation mode

Negotiation mode. This parameter is available only when Interface is set to GE, FE, or XGE. Interfaces at both ends of a link must use the same negotiation mode. If an interface frequently alternates between Up and Down with auto-negotiation enabled, disable auto-negotiation and set the same rate and duplex mode on both interfaces.

Working mode

Interface working mode. Only combo interfaces support both optical and electrical interface modes. You can select either of the two modes based on networking requirements. For the other types of interfaces, select a proper working mode supported by the interfaces. This parameter is available only when Negotiation mode is set to non-autonegotiation.

NOTE:

If an interface cannot work as an optical interface but Working mode is set to Fiber, the configuration fails to take effect after being delivered to the CPE.

Duplex mode

Duplex mode. Interfaces at both ends of a link must use the same duplex mode.

An optical interface works in full duplex mode by default. You can select the full-duplex or half-duplex mode for an electrical interface according to the actual specifications. This parameter is available only when Negotiation mode is set to non-autonegotiation.

Speed

Interface rate. Interfaces at both ends of a link must use the same rate. This parameter is available only when Negotiation mode is set to non-autonegotiation.

Optical Module Type

Type of an optical module. Set this parameter based on the transmission rate requirements. GE and 10GE types are available. A GE optical module transmits traffic at a rate of 1000 Mbit/s, and a 10GE optical module transmits traffic at a rate of 10,000 Mbit/s. If 10GE is selected, the negotiation mode cannot be configured. Ensure that the optical module types at both ends of the link are the same. This parameter is available only when Interface is set to XGE.

STP enable

Enable STP on the interface. This parameter is available only when interface type is set to L2.
Table 4-206 Parameters on the Eth-Trunk tab page

Parameter

Description

Device

Site gateway on which an Eth-trunk needs to be created.

Eth-Trunk ID

ID of an Eth-Trunk. In a dual-gateway scenario, if the two gateways are connected through two Layer 3 physical links, the system automatically creates Eth-Trunk 0 for the two gateways. In such scenario, you cannot create an Eth-Trunk with ID 0.

NOTE:

The value range of Eth-Trunk ID varies depending on the AR model. The options are as follows:

  • AR120 and AR160 series: 1 - 3
  • AR1200 series, AR2201-48FE, AR2204-27GE, AR2204-27GE-P, AR2204-51GE-P, AR2204-51GE, AR2204-51GE-R, AR2204E, AR2204E-D and AR2202-48FE: 1 - 7
  • AR2204, AR2220E, AR1610-X6, AR651-X8, AR651W-X4: 1 - 14
  • AR2220, AR2240C, AR2240, AR6140 series, AR3200 series, AR3600 series: 1 - 63
  • AR6300 series and AR6280 series: 1 - 31
  • AR6120 series, AR651, AR651C, AR651W, AR657, AR657W, AR651U-A4 and AR651F-Lite: 1 - 7
  • SRG1300 series: 1 - 7

Eth-Trunk type

Type of an Eth-Trunk interface, Layer 2 or Layer 3.

Physical interface

Physical member interface of an Eth-Trunk. A maximum of eight member interfaces can be added to an Eth-Trunk. The signal types of all member interfaces must be the same. If a Layer 2 Eth-Trunk is configured, its member interfaces must be Layer 2 physical interfaces. If a Layer 3 Eth-Trunk is configured, its member interfaces must be Layer 3 physical interfaces.

Configuring the Network Access Mode for a Site

Before email-based deployment, you have to configure WAN-side links at sites. After sites are configured or activated, you can add or delete WAN links as needed.

You can configure the following features only when the tunnel mode is set to GRE tunnel on the Design > Basic Network Design > Network Settings > Tunnel Mode page.

Context

Table 4-207 lists possible status of a site after the site is created based on a template.

Table 4-207 Site status

Site Status

Description

Configuration status

  • : Unconfigured
  • : Configured

Whether WAN-side links of the site have been configured.

Activation status

  • : Inactivated
  • : Activated

Whether a deployment email has been sent to the site gateway or whether the ZTP file of the site gateway has been downloaded.

Prerequisites

  1. A site has been created successfully. For details, see Creating a Site.
  2. Global parameters of the site have been configured. For details, see Setting Global Parameters.
  3. If you need to configure IPv6 addresses for interfaces at both ends of a WAN link, ensure that the southbound IPv6 address of the management plane has been configured.
    1. Log in to the management plane.
    2. Choose Product > Software Management > Deploy Product Software from the main menu and choose More > Modify Configurations. Set FILE_SERVER_IPV6(FILE_SERVER_IPV6) and SOUTH_ADDRESS_IPV6(SOUTH_ADDRESS_IPV6). The two parameters specify the file server IPv6 address and southbound IPv6 address, respectively.

    3. Choose Maintenance > Operation and Maintenance > Panoramic Monitoring from the main menu, choose Service Monitoring from the navigation pane, and click the Processes tab. On the displayed page, search for SDWANCfgService in the process list, select SDWANCfgService processes of all microservices, click Stop, and then click Start.

    4. Check the Status column of the SDWANCfgService process in the process list. Ensure that the process is in the running state.

Procedure

  1. Choose Provision > Physical Network > ZTP from the main menu.
  2. Click the ZTP tab. The WAN-side link configuration page is displayed.
  3. Select a site for which you need to configure the network access mode.

    1. Select Unconfigured from the drop-down list next to Site List.
    2. Click the site for which the network access mode needs to be configured.

  4. Configure WAN-side links for the site.

    1. Click the WAN Link tab, and click Click to Deploy.
    2. Click Select template. On the Select WAN Link Template page, select a site template and click OK.

      If the existing template does not meet requirements, click Create to create a WAN link.

      A maximum of two ARs can be deployed as gateways. Otherwise, ZTP will fail.

    3. If Gateway is set to Dual Gateways in the template, set Device1 and Device2.
    4. Complete the configuration required before site deployment by referring to Table 4-208.
      Table 4-208 Mapping between device models and functions

      Function/Device Model

      AR600 and AR6000 series

      AR6700 and AR8000 series

      AR1000V

      SRG

      ZTP mode

      URL/U Disk

      Supported

      Not supported

      Not supported

      Supported

      DHCP Option

      Supported

      Supported

      Not supported

      Supported

      Multiple sub-interfaces

      Supported

      Supported

      Supported

      Supported

      Advanced mode

      This function is disabled in USB-based deployment and manual deployment, and is optional in email-based deployment.

      This function must be enabled in manual deployment.

      This function is disabled in manual deployment.

      This function is disabled in USB-based deployment and manual deployment, and is optional in email-based deployment.
    5. Select the ZTP mode.
      • URL/U Disk: This mode is selected during URL-based or email-based deployment.
      • DHCP Option: This mode is selected during deployment based on DHCP option.
    6. Select whether to enable Sub-interface.
    7. Enable the Advanced mode.

      After the advanced mode is enabled, network parameters of IPv4 links for URL-based deployment can be modified online. After modification, you do not need to re-deploy sites.

      • By default, the advanced mode is disabled. This mode cannot be disabled once being enabled.
      • Only ARs running a version later than V300R019C13 support the advanced mode.
    8. Select the link to be configured, and click in the Operation column.
    9. On the Set WAN Link tab page, set parameters about the WAN-side link according to the interface type. Different interface types support different deployment modes. For details, see Table 4-209. To use Eth-Trunk interfaces at both ends of the WAN link, create Eth-Trunk interfaces in advance. For details, see Configuring a Physical Interface.
      Table 4-209 Device interface types and their supported deployment modes

      Deployment Mode/Interface Type

      Loopback interface

      Eth-Trunk interface

      Email-based deployment

      Not supported

      Not supported

      USB-based deployment

      Not supported

      Not supported

      DHCP-based deployment

      Supported

      Supported

      Manual deployment

      Not supported

      Supported
      • If a WAN link has been configured for a device and a new WAN link is added to the device, URL-based deployment is disabled on the new link by default and cannot be enabled.
      • When a site is activated for the first time, iMaster NCE-Campus cannot deliver the Eth-Trunk interface configuration of WAN links to devices at the site. You need to manually configure Eth-Trunk interfaces on the devices and then configure the interfaces in the same way on iMaster NCE-Campus. If you need to configure Eth-Trunk interfaces for WAN link expansion at an activated site, you only need to configure the interfaces on iMaster NCE-Campus which will then deliver the configuration to the target devices.

    10. (Optional) If the selected interface cannot meet your requirements, click next to the interface to access the physical interface configuration page and configure the interface. For details, see Configuring a Physical Interface.

    11. Click OK.
    12. Enable IPv4 or IPv6 and set related parameters based on the network plan. IPv4 and IPv6 can be enabled at the same time.
    13. Click Apply.

      After WAN links are configured, the icon on the right of the site is displayed as .

Follow-up Procedure

Table 4-210 Follow-up procedure of WAN link configuration after the site is activated

Function

Operation Scenario and Constraint

Procedure

Add a WAN link

After a site is activated, you can add WAN links by applying another link template to the site.
  1. Choose Provision > Physical Network > ZTP from the main menu. The WAN link configuration page is displayed.
  2. Click Create and set WAN link parameters.
  3. Click OK.

Delete a WAN Link

After a site is activated, you can add or delete WAN links by applying another link template to the site.

Before applying another link template, ensure that a new WAN link template has been created.

NOTE:
  • If a WAN link is used by a service (such as underlay route, NTP, underlay ACL, Internet access, or mutual access between sites), the WAN link cannot be deleted.
  • If a WAN link is manually configured for an NTP client, verification is required during the configuration, and the WAN link cannot be deleted. Otherwise, you can delete the WAN link. In this case, you need to clear the time synchronization configuration automatically generated on the NTP client corresponding to the WAN link to be deleted.
  • Adding or deleting WAN links at a site may cause ARs to be disconnected from the controller. If the link for URL-based deployment is deleted, the deployment needs to be re-performed. When deleting an Eth-Trunk, you need to manually delete the Eth-Trunk configurations on corresponding devices. Otherwise, a configuration conflict may occur. If all links are deleted, delete the site.
  1. Choose Provision > Physical Network > ZTP from the main menu. The WAN link configuration page is displayed.
  2. Select the link to be deleted and click Delete. In the displayed Warning dialog box. Click OK.

Switching the link used by a device for controller registration

You can switch the link used by a device to register with iMaster NCE-Campus if this device has multiple WAN links and the quality of the current link for controller registration is poor or a new link for controller registration needs to be selected.

NOTE:
  • Switching the registration link may cause the device to be disconnected for a period of time.
  • Only ARs running a version later than V300R019C13 support this function.
  1. Choose Provision > Physical Network > ZTP from the main menu. The WAN link configuration page is displayed.
  2. Select the current registration link and click Switch. In the dialog box that is displayed, select a new link and click OK.

Parameter Description

Table 4-211 Parameters on the WAN Link tab page

Parameter

Description

Link name

Name of a WAN link. If a WAN link is created using the default site template, the link name is Internet or MPLS. If a WAN link is created using a customized site template, the link name is specified when the template is created. The parameter value cannot be changed.

Transport Network

Type of the transport network to which a WAN-side physical link belongs.

Device

Device to which a WAN-side physical link belongs.

Interface

Type and number of a physical interface used by the current link. The parameter value cannot be changed. The interface can be configured as a physical interface or a virtual interface (that is, a loopback interface).

When iMaster NCE-Campus is deployed on the LAN side of a DC, multiple physical interfaces and one virtual interface can be configured. The physical interfaces are used to connect iMaster NCE-Campus to sites, and the virtual interface is used to transmit overlay traffic. In addition, physical and virtual interfaces must be configured with the same VN instance.

NOTICE:
  1. Ensure that the interface is a Layer 3 interface. If the interface is not a Layer 3 interface, switch the interface to a Layer 3 interface. Otherwise, the configuration fails to be delivered.
  2. When a virtual interface is enabled, the links with physical interfaces cannot be configured as overlay tunnels.
  3. If a loopback interface is used by a WAN link, the bandwidth usage trend of the overlay traffic transmitted through this link at a site or between sites along with the application bandwidth usage trend are displayed as 0 because uplink and downlink bandwidths of a loopback interface cannot be set.
  4. To use Eth-Trunk interfaces at both ends of a WAN link, create Eth-Trunk interfaces in advance. For details, see Configuring a Physical Interface.

Sub-interface (enabled only when Interface is set to GE, FE, XGE, LTE, xDSL (ATM), xDSL(PTM), E1-IMA (ATM), Ima-group, or Serial, and Interface protocol is set to FR)

Whether to use sub-interfaces. Currently, only dot1q sub-interfaces are supported.

  • When Interface is set to GE, FE, XGE, LTE, xDSL (ATM), or xDSL(PTM), configure a dot1q VLAN sub-interface.
  • When Interface is set to LTE, set Number as required.
  • When Interface is set to E1-IMA(ATM), Ima-group, or Serial and Interface protocol is set to FR, set the sub-interface number as required.

The value must be the same as the sub-interface number of the peer device.

Port description

Description of a port.

Number (configured only after Sub-interface is enabled)

Sub-interface number. The value is in the range from 1 to 4094.

VN instance

VN instance name.

Overlay tunnel

Whether to enable the overlay tunnel function. If this function is enabled, an overlay tunnel is created on the WAN link.

APN

Multi-APN function of an LTE cellular interface used to implement data and VoIP communication. This parameter is available only when Interface is set to LTE.

PVC

PVC with a specified virtual path identifier (VPI) or VCI. This parameter is available only when Interface is set to xDSL (ATM)/E1-IMA (ATM)/Ima-group.

VLAN ID

VLAN ID of a sub-interface. This parameter is available only when Sub Interface is enabled.

The value is in the range from 1 to 4094.

Interface protocol

Interface protocol type of the physical link between a CPE and the WAN. This parameter is available only when Interface is set to GE, FE, XGE, xDSL (PTM), xDSL (ATM), E1-IMA (ATM), Ima-group, Serial, Eth-trunk or LoopBack.

GE, FE, XGE, and xDSL (PTM) interfaces support the following protocols:

  • IPoE
  • PPPoE

xDSL (ATM), E1-IMA (ATM), and Ima-group interfaces support the following protocols:

  • IPoA
  • IPoEoA
  • PPPoA
  • PPPoEoA
Serial interfaces support the following protocols:
  • PPP
  • HDLC
  • FR

Eth-trunk interfaces support the following protocol:

  • IPoE

Loopback interfaces support the following protocol:

  • IPoE

Interface protocol

Interface protocol type of the physical link between a CPE and the WAN. This parameter is available only when Interface is set to GE, FE, XGE, xDSL (PTM), xDSL (ATM), E1-IMA (ATM), Ima-group, Serial, Eth-trunk or LoopBack.

GE, FE, XGE, and xDSL (PTM) interfaces support the following protocols:

  • IPoE
  • PPPoE

xDSL (ATM), E1-IMA (ATM), and Ima-group interfaces support the following protocols:

  • IPoA
  • IPoEoA
  • PPPoA
  • PPPoEoA
Serial interfaces support the following protocols:
  • PPP
  • HDLC
  • FR

Eth-trunk interfaces support the following protocol:

  • IPoE

LoopBack interfaces support the following protocol:

  • IPoE

IP address access mode

IP address assignment mode of the interface connecting a CPE to the WAN. This parameter is available only when Interface protocol is set to IPoE or IPoEoA. The options are as follows:

  • Static: static IP address configuration. This mode is recommended for a hub site or an aggregation site.
  • DHCP: dynamic IP address assignment mode using DHCP. This mode is recommended for a branch site.

IPv4 address

IP address statically assigned to the interface connecting a CPE to the WAN and corresponding subnet mask. In the NAT scenario, the IP address must be set to the private IP address (corresponding to Public IP) of the CPE for the RR or Edge site. These parameters are available only when Interface protocol is set to IPoE or IPoEoA and IP address access mode is set to Static or when Interface protocol is set to IPoA.

Subnet mask

IPv4 gateway

IP address of the interface used by a PE on the WAN side to communicate with a site. This parameter is available only when Interface protocol is set to IPoE or IPoEoA and IP address access mode is set to Static or when Interface protocol is set to IPoA.

NAT traversal

Whether NAT traversal is enabled.

After this parameter is enabled, external network users can access the internal server and internal network users can access the external network in the NAT scenario.

NOTE:

In NAT traversal scenarios, IPsec encryption must be enabled for transport networks in routing domains. For details about how to enable IPsec encryption, see Setting Global Parameters.

URL-based deployment

Whether to enable URL-based deployment for the current link.

  • If this function is enabled, the IPv4 configured parameters on interfaces need to be loaded to devices through URL-based deployment.
  • If this function is not enabled, the IPv4 configured parameters on interfaces are delivered to devices through NETCONF.
NOTE:
  1. This configuration item can be enabled only when the ZTP mode is set to URL/U Disk. URL-based deployment can be configured on a maximum of three links for each device.
  2. If a site in URL-based deployment mode is selected, at least one link must be selected for URL-based deployment on a single gateway.

URL-based deployment link

Whether to enable the URL-based deployment link. This parameter indicates whether to use the primary IP address of southbound access services on the link for URL-based deployment. If the southbound access services on multiple links are different, you can enable URL-based deployment link of only one link. That is, you can only use the primary IP address of southbound access services on one link for deployment.

Southbound interface service:

IP address of the southbound access service. The default southbound access service applies for WAN links in the pre-defined site template. If other southbound access services have been enabled, you can select other user-defined access services for the WAN link. This parameter cannot be changed after deployment.

Mapping peer IP

Peer IP address that is mapped to the PVC. An IP address cannot be mapped to different ATM interfaces on the device; otherwise, forwarding is interrupted. This parameter is available only when Interface is set to xDSL (ATM)/E1-IMA (ATM)/Ima-group and Interface protocol is set to IPoA.

User name

User name and password allocated by the carrier to connect to the WAN. These parameters are available only when Interface is set to LTE or Interface protocol is set to PPPoE, PPPoA, or PPPoEoA.

Password

Negotiation mode

Negotiation mode. This parameter is available only when Interface is set to GE, FE, or XGE. Interfaces at both ends of a link must use the same negotiation mode. If an interface frequently alternates between Up and Down with auto-negotiation enabled, disable auto-negotiation and set the same rate and duplex mode on both interfaces.

Working mode

Interface working mode. Only combo interfaces support both optical and electrical interface modes. You can select either of the two modes based on networking requirements. For the other types of interfaces, select a proper working mode supported by the interfaces.

NOTE:

If an interface cannot work as an optical interface but Working mode is set to Fiber, the configuration fails to take effect after being delivered to the CPE.

Duplex mode

Duplex mode. Interfaces at both ends of a link must use the same duplex mode.

An optical interface works in full duplex mode by default. You can select the full-duplex or half-duplex mode for an electrical interface according to the actual specifications.

Speed

Interface rate. Interfaces at both ends of a link must use the same rate. This parameter is available only when Negotiation mode is set to non-autonegotiation.

Optical Module Type

Type of an optical module. Set this parameter based on the transmission rate requirements. GE and 10GE types are available. A GE optical module transmits traffic at a rate of 1000 Mbit/s, and a 10GE optical module transmits traffic at a rate of 10,000 Mbit/s. If 10GE is selected, the negotiation mode cannot be configured. Ensure that the optical module types at both ends of the link are the same. This parameter is available only when Interface is set to XGE.

Public IP

IP address used by a CPE to connect to the WAN. In the DSVPN tunnel mode, only hub sites or aggregation sites need to be configured. In the EVPN tunnel mode, only RRs need to be configured.

The public IP address can be accessed by external systems. A branch site can register with a hub site or an aggregation site through this IP address. An edge site can register with an RR site through this address.

In the enterprise network scenario, an enterprise administrator selects one public IP address from the network segment assigned by the carrier.

In NAT scenarios, Public IP must be set.

Access type

Type of the sub-interface.

  • P2P: Point to point
  • P2MP: Point-to-multipoint

This parameter is available only when Interface is set to Serial, Sub Interface is enabled and Interface protocol is set to FR when you configure the site template.

Authentication mode

Authentication mode. The options are CHAP and PAP. This parameter needs to be set only when Interface is set to LTE and URL-based deployment is disabled, or Interface protocol is set to PPPoE, PPPoA, or PPPoEoA.

Uplink bandwidth

Maximum uplink and downlink transmission rates, which need to be configured based on the actual link bandwidths.

NOTE:

This limit does not take effect if overlay traffic allocation or overlay QoS is not configured.

Downlink bandwidth

Link ID

The ID of a WAN link.

Configuring NTP

Context

When an AR reports performance data, the timestamp is carried. If the system time of the AR is inconsistent with that of iMaster NCE-Campus, the actual time when performance data is reported is inconsistent with that displayed on iMaster NCE-Campus. As a result, the site traffic and quality data cannot be displayed. Therefore, you need to configure NTP on iMaster NCE-Campus so that the system time of devices at sites is consistent with that of iMaster NCE-Campus

In EVPN tunnel mode, an edge site synchronizes its clock with that of an RR site, and an RR site synchronizes its clock with the external clock source. An RR site can function as an NTP client or an NTP server.

Prerequisites

  1. A site has been created successfully. For details, see Creating a Site.
  2. Global parameters of the site have been configured. For details, see Setting Global Parameters.
  3. Site WAN links have been configured. For details, see Configuring the Network Access Mode for a Site.

Procedure

  1. Choose Provision > Physical Network > ZTP from the main menu.
  2. Click the ZTP tab.
  3. Select a site for which you need to configure time synchronization.
  4. Click the NTP tab.
  5. (Optional) Click Import default NTP to import the global NTP server information configured on the Design > Basic Network Design > Network Settings > WAN Global Configuration page for the RR site.

    Only the RR site can import default NTP information. If the default NTP configuration is enabled in the global configuration, the site uses the default time zone specified in the global configuration. Edge site synchronizes the clock with the associated RR sites, and the RR site synchronizes the clock with an external clock source.

  6. Select a time zone from the Time zone drop-down list.
  7. (Optional) Set whether to enable the DST of the time zone and select the configuration mode.

  8. When a site functions as an NTP server, set parameters of the NTP server, including NTP authentication.

  9. When a site functions as an NTP client, set parameters of the NTP client, including NTP client mode.

    • Automatic synchronization with parent node: A site functions as an NTP client and its parent site functions as the NTP server. This mode is the default setting. In the DSVPN tunnel mode, only aggregation and branch sites support this mode. In the EVPN tunnel mode, edge sites are enabled with this mode by default.
    • Manual configuration: A site functions as an NTP client and the NTP server needs to be manually specified. In the EVPN tunnel mode, you are advised to configure an RR as an NTP client and synchronize the clock with the NTP server on the public network.

    • Disabled: A site does not function as an NTP client and does not perform clock synchronization.

  10. Click Apply.

Parameter Description

Table 4-212 Parameters on the NTP tab page

Parameter

Description

Data Plan in Advance

Time zone

Time zone of devices at a site.

Y

DST

Daylight saving time (DST). This parameter specifies whether to set DST.

-

Configurations of a site when it functions as an NTP client

NTP client mode

Mode in which a site functions as an NTP client:

  • Manual configuration: A site functions as an NTP client and the NTP server needs to be manually specified. In the DSVPN tunnel mode, you are advised to configure a hub site as an NTP client which synchronizes the clock with the NTP server on the public network. In the EVPN tunnel mode, you are advised to configure an RR as an NTP client and synchronize the clock with the NTP server on the public network.
  • Automatic synchronization with parent node: A site functions as an NTP client and its parent site functions as the NTP server. This mode is the default setting. In the DSVPN tunnel mode, only aggregation and branch sites support this mode. In the EVPN tunnel mode, edge sites are enabled with this mode by default.
  • Disabled: A site does not function as an NTP client and does not perform clock synchronization.

Y

NTP client (These parameters are available only when NTP client mode is set to Manual Configuration.)

Device

CPE that functions as an NTP client.

-

Server Network

Network where the NTP server is located. You can select Underlay or Overlay based on the actual situation.

-

WAN Link (VN Instance)

WAN-side link connecting a site to the NTP server.

-

NTP Server Type

Type of the NTP server. The value can be IPv4.

-

NTP Server IP Address

IP address of the NTP server.

Y

Preferential NTP Server

Specifies the NTP server as the preferred server.

-

Source Interface

Source interface used by devices to sending NTP packets. (This parameter is configurable only when Server Network is set to Overlay.)

-

Authentication

Whether to enable the authentication function. If NTP identity authentication is enabled on the NTP server, the authentication function must also be enabled on the NTP client. Otherwise, clock synchronization cannot be performed.

-

Authentication Mode

Authentication mode, which can be MD5 or HMAC-SHA256. The authentication mode selected must be the same as that enabled on the NTP server. The MD5 authentication mode may pose potential security risks. As such, the HMAC-SHA256 authentication mode is recommended.

-

Authentication Password

Password used for NTP identity authentication.

Y

Authentication Key ID

Key ID used for NTP identity authentication.

Y

Y

Importing and Exporting Site Configurations

Context

You can import and export WAN-side physical link configuration and NTP configuration of sites in batches.

Procedure

  1. Choose Provision > Physical Network > ZTP from the main menu. Click the Export And Import tab.
  2. Click the Export tab.
  3. Click Click here to add site. Select the target sites whose configurations need to be exported and click OK.

    The configurations of up to 100 sites can be exported in batches.

  4. Click Export. Open the exported .xls file and modify the site configuration based on the site requirements. Currently, only the WAN link and NTP configurations can be modified.

  5. Save the modified .xls file. Click the Import tab on iMaster NCE-Campus.
  6. Select the site configuration file to be imported, and click Import next to Upload file.

    1. The configuration file for up to 100 sites can be imported in batches.
    2. If the site configuration to be imported contains Eth-Trunk interface configuration, you need to create Eth-Trunk interfaces first. Otherwise, the import fails. For details about how to create an Eth-Trunk interface, see 1.13 Configuring Physical Interfaces.
  7. Check the import result in the Import Result area, including the task name, task creation time, end time, status, total number of tasks, and number of successfully executed tasks.
    • If Success is displayed in the Task Status column, the site configuration file is imported successfully.
    • If Fail is displayed in the Task Status column, the site configuration file fails to be imported. You can check the specific failure cause.

    A maximum of 10 records can be displayed in Import Result.

Associating an Edge Site with a vRR

You can configure the following features only when the tunnel mode is set to GRE tunnel on the Design > Basic Network Design > Network Settings > Tunnel Mode page.

Context

In EVPN tunnel mode, an edge site needs to be associated with an RR site.

Tenant administrators need to associate an edge site with an RR site on iMaster NCE-Campus. After the configuration is complete, CPEs go online and automatically register with the target RRs under the orchestration of iMaster NCE-Campus. A public IP address needs to be assigned to each RR so that CPEs can communicate with target RRs. After the CPEs are registered, they establish IBGP peer relationships with a pair of target RRs, and the RRs reflect routes between the CPEs so that the CPEs can learn the routes from each other.

All RRs in an RR group are interconnected in full-mesh topology model by default. It is recommended that RR sites be deployed in different geographical areas.

When associating an edge site with an RR site, adhere to the following rules:

  1. An edge site can be associated with a maximum of two RR sites. If two RR sites are associated with an edge site, it is recommended that one RR site be deployed in the same physical area with the edge site to minimize delay, and the other RR site be deployed in another physical area to ensure service reliability through geographic redundancy.
  2. One RR site can manage multiple edge sites, and the number of edge sites associated with each RR site should be balanced.

Prerequisites

An edge site and an RR site have been created and activated successfully. For details, see Creating a Site and Configuring the Network Access Mode for a Site.

Procedure

  1. Choose Provision > Physical Network > WAN Underlay from the main menu. Click Connect to RR.
  2. Select an edge site, and click Connect.

  3. On the Connect page, select the RR site to be associated with the edge site.

  4. Click Detect.

  5. Click OK. The value Update succeeded is displayed in the result page.

  6. Click OK.

Configuring a Parameter Set

You can add variable parameters in a template to a parameter set. In this way, when applying the same template, you can directly use this parameter set, without the need to customize variable parameters repeatedly.

Creating a Parameter Set

  1. Choose Design > Basic Network Design > Template Management from the main menu, and click the Parameter Set Management tab.
  2. Click View in the Operation column of a template to view the template content. Parameters in {{}} in the template are variable parameters that can be customized.

  3. Click Create.

  4. Set Parameter set name.

  5. Click Add.

  6. Set Parameter and Value. After Encrypted is enabled, the parameter value is displayed as * on the page.

  7. Click OK.

Importing a Parameter Set

  1. Click Import.

  2. Set Parameter set name.

  3. Click template.xls to download a template, set parameters, and save the template to the local host.
  4. Click and select the local template.

  5. Click Upload.

  6. Click OK.

Exporting a Parameter Set

  1. Select the parameter set to export and click Export. The parameter set is exported to an .xls file.

Deleting Parameter Sets

  1. Click in the Operation column of a user-defined parameter set, or select multiple user-defined parameter sets and click Delete.

Modifying a Parameter Set

  1. Click Edit in the Operation column of a parameter set, and modify the parameters set.

Link Management

Fundamentals

Link management allows users to manage and maintain links in a unified manner. Links on the entire network can be managed in a unified manner through link management. Link management can automatically discover and allow users to manually create links between devices, and can display the links in a topology. You can monitor the link status to better understand the network topology and changes of the monitored network.

Discovering a Link

Application Scenario

iMaster NCE-Campus can discover only Layer 2 links between Link Layer Discovery Protocol (LLDP)-capable devices that are directly connected. Layer 2 link discovery requires that devices support Link Layer Discovery Protocol (LLDP) and have it enabled. If devices are directly connected to each other, iMaster NCE-Campus can automatically discover links between devices. If an automatically discovered link has been manually deleted from iMaster NCE-Campus, the link can still be displayed in the link list and physical topology after you perform automatic discovery.

Prerequisites

LLDP has been enabled on devices and on iMaster NCE-Campus. Perform the following operations to enable LLDP on iMaster NCE-Campus:

  1. Choose Provision > Physical Network > Site Configuration from the main menu.
  2. Select a site from the Site drop-down list in the upper left corner.
  3. Choose Site > Device System Configuration on the Site Configuration tab. In the Other area, enable LLDP.
  4. Click Apply to save the configuration.

Procedure

  1. Choose Design > Basic Network Design > Link Management from the main menu.
  2. Click Discover Link.

  3. Click Discover, select devices by device type or site, and click OK.

    After the discovery is complete, the links discovered are displayed in the list.

  4. Click Return to view link information in the link list.

Creating a Link

Application Scenario

When physical links between two devices cannot be discovered to iMaster NCE-Campus in automatic discovery mode (for example, the physical links are not layer 2 links, the devices do not support LLDP, LLDP is disabled on the devices, or other devices exist between the devices), you can manually add links between the devices to show the logical relationship between the devices.

Procedure

  1. Choose Design > Basic Network Design > Link Management from the main menu.
  2. Click Create Link.
  3. Set link information.

    • Name: Enter the link name as prompted.
    • Type: Select a link type from the drop-down list.
    • End A NE: Click and select the source NE of the link from the list.
    • End A Port: Click and select the source port of the link from the list.
    • End Z NE: Click and select the sink NE of the link from the list.
    • End Z Port: Click and select the destination port of the link from the list.

  4. Click OK to create a link.
  5. Click OK.

    After the link is successfully created, the link list displays the created link.

Parameter Description

Table 4-213 Creating the Link

Parameter

Description

Name

The link name.

Type

Cable

A cable connects two devices that form a link.

Layer 2 Link

Link between two physical ports

IP Link

The IP addresses for interfaces at both ends of an IP link contain a 30-bit subnet mask.

General Link

The links that are not of the preceding types.

Configuring a Link

Application Scenario

When a link between devices changes, you can adjust the link configuration as needed. This helps O&M personnel view and manage links in a timely manner.

Link configuration includes viewing and exporting link information, hiding links, viewing and restoring hidden links, deleting links, and configuring link name display rules.

Prerequisites

Links have been created.

Procedure

  1. Choose Design > Basic Network Design > Link Management from the main menu.
  2. Configure link information in the link list.

    • Viewing link information

      View the link details in the link list, for example, link status, name, type, names of NEs at both ends, and port names.

      You can click in the upper right corner of the list to set the fields to be displayed in the link list.

    • Exporting link information
      • Export Selected: In the link list, select the link to be exported and click Export link > Export Selected to export the selected link information.
      • Export All: Click Export link > Export All to export all link information in the list.
    • Hiding links

      Select the link to be hidden from the link list, click in the upper right corner, and select Hide. After a message is displayed indicating that the link is successfully hidden, the link information is not displayed in the link list or topology.

    • Viewing and restoring hidden links
      1. Click in the upper right corner of the page and choose View hidden link. The list of hidden links is displayed.
      2. Select the link to be restored and click Restore. After a message is displayed indicating the restoration is successful, the link information is displayed in the link list and topology.
    • Deleting links
      • Single deletion: Click in the Operation column of the link to be deleted.
      • Batch deletion: Select the links to be deleted and click Delete.
    • Configuring rules for link name display
      1. Click in the upper right corner of the page and select Name display rule.
      2. Select the fields to be displayed for the link name and click OK. After the operation is successful, the link names in the list are displayed according to the preset fields.

Viewing a Link

Application Scenario

You can monitor the running status of links in real time based on the link status icons displayed in the link list. This feature enables users to restore abnormal links in a timely manner, improving O&M efficiency.

The link status is affected by the device status and port status (normal or faulty) at both ends of the link. Table 4-214 shows the relationships between the link status, link icon colors, and port status.

Table 4-214 Relationships between link status, link status icons, and port status at both ends of a link

Link Status

Status Icon

End A Port Management Status

End A Port Operating Status

End Z Port Management Status

End Z Port Operating Status

Normal

Normal

Normal

Normal

Normal

Offline

When the device at one end is offline, the link is offline regardless of the port status.

Handling Link Status Exceptions

If the link status is abnormal, perform the following operations to rectify the fault:

  • If the link icon is , at least one device at the two ends of the link is offline. Further analysis is required. Table 4-215 lists the possible causes and solutions.
    Table 4-215 Possible causes and handling methods for offline devices

    Possible Cause

    Troubleshooting Method

    Power off the device.

    Power on the device again.

    The device IP address is changed.
    1. Remove the device.
    2. Add the device again.