Login
- Released At: 13-09-2023
- Page Views:
- Downloads:
- Table of Contents
- Related Documents
-
|
|
|
AD-Campus 6.2 |
|
IP Policy Basics Configuration Guide |
|
|
|
|
Document version: 5W100-20230221
Copyright © 2023 New H3C Technologies Co., Ltd. All rights reserved.
No part of this manual may be reproduced or transmitted in any form or by any means without prior written consent of New H3C Technologies Co., Ltd.
Except for the trademarks of New H3C Technologies Co., Ltd., any trademarks that may be mentioned in this document are the property of their respective owners.
The information in this document is subject to change without notice.
Contents
Connections between servers and network devices
Software and hardware information
Resource and IP address planning
Logging in to the AD-Campus controller
Configuring user endpoint settings
Configuring AAA server settings
Configuring DHCP server settings
Enabling conventional forwarding entry learning for static Ethernet service instances
Optimized automated deployment
Managing access scenarios (optional)
Setting the maximum number of online endpoints supported by an account
User authentication and access
Configuring 802.1X authentication
Configuring MAC portal authentication
Creating the BYOD security group
Enabling MAC portal authentication
Initiating MAC portal authentication
Configuring MAC authentication
Configuring MAC authentication users
Configuring MAC authentication
Configuring the broadband IoT service
Fast online based on MAC address ranges
Fast online based on IP address ranges
Fast online based on endpoint identification
Retaining broadband IoT endpoints to stay online for a long time
Configuring authentication-free interfaces
Adding an authentication-free interface group
Adding a port isolation device group
Binding a security group to an authentication-free interface group
Configuration deployed to the devices
Guest online or authentication failure online
Permitting users that fail authentication to come online
Configuring a page push policy
Permission and domain management
Configuring permissions and domains
Verifying permission and domain management
Wizard > Campus Wizard > Device Onboarding Plan
Monitor > Topology > Campus Topology
Automation > Campus Network > Fabrics
Automation > Campus Network > Devices > Switch Devices
Automation > Campus Network > Isolation Domain > Isolation Domain
Configuring endpoints directly connected to leaf devices
Adding members to an interface group
Deploying a policy to an interface group
Configuring user critical solutions
Creating a critical Layer 2 network domain
Creating a critical security group
Configuring critical IT resource access settings
Configuring the critical DHCP server
Configuring a Microsoft tightly coupled DHCP server
Configuring a Microsoft loosely coupled DHCP server
Accessing the IT resource group
Accessing external networks through border devices (single-spine)
Creating a border device group
Adding a private network (optional)
Associating the egress gateway with a private network
Viewing egress gateway configuration deployed to devices
Configuration deployed to the interface connected to the external network on the border device
Manually configuring the L3 device connected to the border device
Associating border devices with an external route device (dual-border)
Configuring the L3 device connected to the border devices
Multicast service configuration
Manual configuration of the interface for connection between border and external network
Manual configuration on the Layer 3 multicast device connected to the border device
Adding an application classifier
Viewing the configuration deployed to a device
Restrictions and guidelines for leaf-access network models
Configuring redundant dual-spine uplinks
Configuring the Layer 3 switch
Connecting Spine 1 to the Layer 3 switch
Connecting Spine 2 to the Layer 3 switch
Connecting Spine 1 and Spine 2
Configuring routes from leaf devices and access devices to servers
Configuring routes from leaf devices to servers
Configuring static routes on access devices
Configuring DRNI for dual spine devices (manual)
Configuring the Layer 3 switch
Connecting Spine 1 to the Layer 3 switch
Connecting Spine 2 to the Layer 3 switch
Restrictions and guidelines
· The S5560X-EI, S5560X-HI, S6520X-EI, and S6520X-HI switches cannot act as edge devices (EDs).
· When the S5560X-EI, S5560X-HI, S6520X-EI, or S6520X-HI switches act as border devices with a shared gateway, you must configure PBR policies on the interfaces through which backward traffic passes to allow the backward traffic to pass through.
· For the S5560X or S6520X series switches, do not deliver specific protocol packets (including ARP and MLD protocol packets) received by VXLAN tunnel interfaces to the CPU for CPU protection. The configuration procedure is as follows:
a. Execute the undo mac-address static source-check enable command globally.
b. Use the flooding disable all or flooding disable broadcast command in VSI view. If the flooding disable all all-direction command or the flooding disable broadcast all-direction command has been used in VSI view, you must execute the undo flooding disable command to delete the configuration, and then use the flooding disable all or flooding disable broadcast command in VSI view.
c. Execute the forwarding vxlan-packet inner-protocol { ipv4 | ipv6 } command globally. If both IPv4 and IPv6 services are available, specify both the ipv4 and ipv6 keywords for this command.
d. Configure port isolation group settings globally and add all downlink interfaces of leaf devices to port isolation groups. If intercommunication for traditional VLAN services exists among some of the leaf downlink interfaces, you do not need to add these interfaces to port isolation groups. However, if port isolation is not configured, the leaf devices cannot isolate broadcast traffic, unknown multicast traffic, and unknown unicast traffic among these downlink interfaces.
· To use the BYOD security group, you must configure a vDHCP server.
· In the leaf-access scenario, the controller does not automatically assign addresses to loopback interfaces. To configure fabric interconnection, you can change the VTEP IP addresses of devices on the corresponding fabrics on the page.
· To attach a router to an access device, you must use a LAN interface rather than a WAN interface. In addition, you must disable DHCP and NAT on the router.
· In the public host scenario, the name-address binding feature supports only the 802.1X + iNode authentication mode. MAC portal authentication is not supported on a public host that is shared by multiple user accounts.
· The Microsoft DHCP server supports IPv6 address allocation only when it operates in standalone mode and uses the loose coupling method.
· The number of MAC-IP bindings in a single address pool of the Microsoft DHCP server must be smaller than 2000.
· When the active Microsoft DHCP server fails, the standby server can only allocate IP addresses and cannot generate binding entries. To generate binding entries for endpoints that come online when the active server fails, the endpoints must first go offline and then come online after the active server recovers.
· When the default policy of a group policy is configured as Deny, as a best practice, connect the physical servers of an IT resource group through spine devices and deploy the IT resource group on the private network named vpn-default. If the IT resource groups are deployed on the private network named vpn-default, all private networks are allowed to access all IT resource groups by default. By configuring the IT resource groups that are not allowed to be accessed in each private network and deploying a group policy with the deny action, you can prohibit access to resources. If an IT resource group is deployed in a service VPN, users in the service private network cannot access the IT resource group by default. To access the IT resource group, you must configure a policy with the permit action.
· On the Layer 3 switch connected to a server, you must configure the spanning tree feature to operate in MSTP mode rather than PVST mode.
· You must deploy a switch between the network port of a SeerBlade module and a spine device.
· In a non-standard network, especially in a network containing firewalls, you must open the required ports. For more information about the ports, see the port matrixes for this solution.
· Do not use the Bind User IP feature in an access policy for a user when the Layer 2 network domain to which the user belongs has a secondary subnet.
· 802.1X authentication and MAC/MAC portal authentication are supported. You can configure one of them or both of them as needed. As a best practice, do not configure both of them unless required. However, the campus network supports configuring both authentication modes.
· When you manually set up IRF fabrics by using spine, leaf, access, or AC devices, you must use the irf mac-address persistent always command to ensure that the IRF bridge MAC address remains unchanged after a master/subordinate switchover.
· You can attach a multicast source in VLAN mode only to the following devices:
¡ S12500G-AF switches.
¡ SH modules on the S10500 and S10500X switches.
¡ S6550XE switches.
¡ S6525XE switches.
· Changing the DHCP server binding is not allowed after a user has obtained an address from the DHCP server.
· Devices in the same group cannot be incorporated by multiple sets of controllers concurrently.
· A set of DHCP servers cannot be incorporated by multiple sets of controllers concurrently.
· In scenarios where ARP flooding exists, you can configure attack detection and prevention commands. For more information, see the manuals for your products.
· As a best practice, enable conversational forwarding entry learning for ACs on devices when a large number of security groups exist.
· When a DR system acts as a leaf device, use the arp send-gratuitous-arp interval command on VSI-interface 4094 of the spine device connected to the leaf device. As a best practice, set the interval to a value greater than 30 seconds.
· Navigate to the Automation > Campus Network > Network Parameters > vDHCP page. The syslog feature is required for endpoint IP collision detection on the DDI display page. For manually deployed leaf devices, add the info-center loghost vpn-instance vpn-default 100.1.0.100 command.
· When adding a spine or leaf device to the monitor list, you must add VPN parameters to the destination IP address of SNMP traps by using the following command:
snmp-agent target-host trap address udp-domain xx.xx.xx.xx vpn-instance vpn-default params securityname public v2c
· If a fabric includes devices deployed in both manual deployment mode and legacy automated deployment mode, the following restrictions and guidelines apply:
¡ Make sure VSI-interface 4094 or VLAN-interface 4094 on each device is assigned a unique IP address.
¡ Make sure the ranges of the underlay IPs and underlay VLANs used by the manually deployed device do not overlay with those configured for automatically deployed devices in the automation templates.
|
|
IMPORTANT: As a best practice, do not use this kind of mixed deployment. |
· When the controller adds or deletes a DR system that contains leaf devices, the leaf devices will be temporarily disconnected from the network. To resolve this issue, you can use the evpn irb asymmetric command to enable asymmetric IRB forwarding for the management network segment. When the connection is stable, use the undo evpn irb asymmetric command to disable asymmetric IRB forwarding.
· Name-address binding settings are mutually exclusive with IP source guard (IPSG) and ARP detection settings.
· In a DR system, you must specify a unique router ID for each DR member device to avoid conflicts.
Introduction
Overview
This document guides you to complete the basic deployment of the AD-Campus 6.2 solution, including the following items:
· Installation and deployment of software.
· Manual underlay configuration.
· Manual incorporation of physical devices.
· Basic service configuration and user configuration of the SeerEngine-Campus controller.
· Wired user authentication and onboarding.
H3C provides configuration guides for different features. For more information about configuring the features, see the configuration guides as shown in Table 1.
Table 1 Feature configuration guides
|
Feature |
Description |
Documentation |
|
Automation |
Automated device deployment. |
AD-Campus 6.2 Automation Configuration Guide AD-Campus 6.2 Optimized Automation Configuration Guide |
|
Half automation |
Spine or leaf devices are manually incorporated, and access devices are automatically incorporated. |
AD-Campus 6.2 Half Automation Configuration Guide |
|
Wireless |
AC incorporation and wireless user authentication. |
AD-Campus 6.2 Wireless Configuration Guide |
|
IPv6 |
Use IPv6 network to incorporate devices and allow users to obtain IPv6 addresses. |
AD-Campus 6.2 IPv6 Service Configuration Guide |
|
Multi-campus interconnection |
Isolation domain interconnection and multi-fabric interconnection in a single isolation domain. |
AD-Campus 6.2 Multi-Campus and Multi-Fabric Configuration Guide |
|
Service chain |
East-west and north-south service chains. |
AD-Campus 6.2 Service Chain Configuration Guide |
|
Microsoft DHCP |
Microsoft DHCP tightly coupled environment setup and configuration. |
AD-Campus 6.2 Microsoft DHCP Tight Coupling Solution Configuration Guide |
|
Security convergence |
Security incorporation services for users. |
AD-Campus 6.2 Security Convergence Configuration Guide |
|
EPON |
Setup and service configuration of EPON networking. |
AD-Campus 6.2 EPON Network Configuration Guide |
|
Replacement of faulty device |
Targeted replacement and heterogeneous replacement after device failure. |
AD-Campus 6.2 Configuration Guide for Replacement of Faulty Device |
Single-fabric network models
The AD-Campus solution supports the dual-spine and IRF network models. In the dual-spine network model, two spine devices form a DR system or the two spine devices are dual-homed for redundancy protection and traffic load sharing. In the IRF network model, two devices are virtualized into one device to offer processing power, interaction, unified management, and uninterrupted maintenance of multiple devices. The two models can be further divided by device architecture into the following network models.
· Spine-leaf-access network model—A typical campus network model that includes spine, leaf, and access devices. In this model, the spine, leaf, and access devices support IRF fabric setup, and the access devices also support multi-level cascading.
· Spine-leaf network model—Includes spine and leaf devices. In this model, no devices with the access role are deployed. Wireless APs and wired users are directly connected to leaf devices.
· Leaf-access network model—Includes leaf and access devices. In this model, no devices with the spine role are deployed. This model is mainly used in small-sized networks. The leaf devices can form two-chassis IRF fabrics. The access devices support IRF fabric setup and multi-level cascading.
This document covers spine-leaf-access, spine-leaf, and leaf-access network models only for a single fabric. For more information about the multi-fabric networking configurations, see AD-Campus 6.2 Multi-Campus and Multi-Fabric Configuration Guide.
Dual-spine network models
Spine-leaf-access network model
As shown in Figure 1:
· The spine devices must support VXLAN. They mainly act as route reflectors (RRs) and route forwarding devices to forward routes between different leaf devices, and provide communication services for various types of servers as border devices. The dual-spine network can be further divided into the DRNI and non-DRNI network models. In a wired scenario, DRNI configuration is not required for the dual spine devices. If a wireless AC is attached to the spine devices, you must use the spine devices to form a DR system and assign all interfaces connected to the AC to a DR interface.
· The leaf devices must support VXLAN. They are used for user authentication and route forwarding.
· The access devices are connected to APs and endpoints, and they support multi-level cascading.
Figure 1 Network diagram for the spine-leaf-access network model
In a dual-spine scenario, the spine devices must be incorporated manually. For more information, see "Configuring redundant dual-spine uplinks" or "Configuring DRNI for dual spine devices (manual)."
Spine-leaf network model
The spine-leaf network model is special in the AD-Campus solution, containing only spine and leaf devices. In this model, no access devices are deployed. Wireless APs and wired users are directly connected to leaf devices. You must manually configure the interfaces connecting leaf devices to APs and users.
As shown in Figure 2, the spine devices must support VXLAN. They mainly act as RRs and route forwarding devices to forward routes between different leaf devices, and provide communication services for various types of servers as border devices. The dual-spine network can be further divided into the DRNI and non-DRNI network models. In a wired scenario, DRNI configuration is not required for the dual spine devices. If a wireless AC is attached to the spine devices, you must use the spine devices to form a DR system and assign all interfaces connected to the AC to a DR interface.
Figure 2 Network diagram for the spine-leaf network model
Leaf-access network model
In this model, multiple access devices are connected to leaf devices. No spine devices are deployed. The network deployment is simple. This model is mainly applicable to small-size networks. The leaf devices provide communication services for various types of servers as border devices. If two leaf devices are deployed, use the leaf devices to set up a DR system as a best practice. If a wireless AC is attached to the leaf devices, you must use the leaf devices to set up a DR system and assign all interfaces connected to the AC to a DR interface.
Figure 3 shows a network diagram for the leaf-access network model.
Figure 3 Network diagram for the leaf-access network model
IRF network models
Spine-leaf-access network model
The spine-leaf-access network model includes spine, leaf, and access devices. This is a typical network model in the AD-Campus solution.
· Spine devices must support VXLAN. They mainly act as RRs and route forwarding devices to forward routes between different leaf devices, and provide communication services for various types of servers as border devices. Spine devices can operate in standalone mode or form IRF fabrics.
· Leaf devices must support VXLAN. They are used for user authentication and route forwarding.
· Access devices are connected to APs and endpoints, and they support multi-level cascading.
Figure 4 shows a network diagram for the spine-leaf-access network model.
Figure 4 Spine-leaf-access network model
Spine-leaf network model
The spine-leaf network model is special in the AD-Campus solution, containing only spine and leaf devices. No access devices are deployed. Wireless APs and wired users are directly connected to leaf devices. You must manually configure the interfaces connecting leaf devices to APs and users.
Spine devices must support VXLAN. They mainly act as RRs and route forwarding devices to forward routes between different leaf devices, and provide communication services for various types of servers as border devices. Spine devices can operate in standalone mode or form IRF fabrics.
Figure 5 shows a network diagram for the spine-leaf network model.
Figure 5 Spine-leaf network model
Leaf-access network model
In this model, multiple access devices are connected to leaf devices. No spine devices are deployed. The network deployment is simple. This model is mainly applicable to small-size networks. The leaf devices provide communication services for various types of servers as border devices. They can operate in standalone mode or form IRF fabrics.
Figure 6 shows a network diagram for the leaf-access network model.
Figure 6 Leaf-access network model
Spine-aggregation-leaf-access or spine-aggregation-leaf network model
As shown in Figure 7:
· Compared with the standard spine-leaf-access or spine-leaf network model, the aggregation network model adds aggregation Layer 3 switches between the spine and leaf devices. The aggregation Layer 3 switches do not need to support VXLAN or EVPN.
· All spine, leaf, and access devices can operate in standalone mode or form IRF fabrics.
· The aggregation devices have ECMP routes to reach the spine and leaf devices, and vice versa.
· Multichassis link aggregation is formed between the leaf and access devices.
Figure 7 Spine-aggregation-leaf-access network model
Connections between servers and network devices
This section describes the Layer 3 network connection method used to connect Unified Platform and its components (including SeerEngine-Campus, vDHCP server, and EIA) to network devices.
The Layer 3 network connection method is used when the management IP addresses of the controller and network devices are not on the same network segment. Make sure they can reach each other through Layer 3 routing.
The controller can be deployed at the remote end (it is not required that the controller and the devices belong to the same Layer 2 network domain). If you use one NIC for deployment, the SeerEngine-Campus and Unified Platform share the NIC. If you use two NICs for deployment, the SeerEngine-Campus and Unified Platform use separate NICs.
Dual-spine networking
Figure 8 Network diagram of connections between servers and devices in dual-spine networking
Spine IRF networking
Figure 9 Network diagram of connections between servers and devices in spine IRF networking
Network configuration
1. In the AD-Campus network, the SeerEngine-Campus, DHCP server, and network devices are interconnected at Layer 3. When an IRF fabric acts as a spine device, you must use the port trunk permit vlan1 4094 command on the uplink interfaces of the spine device.
2. Spine devices must support VXLAN. They mainly act as RRs and route forwarding devices to forward routes between different leaf devices, and provide communication services for various types of servers as border devices. The links between the spine devices and leaf devices are underlay links. You only need to make sure the spine and leaf devices have routes to reach each other.
3. On leaf devices, the interfaces connected to access devices are leaf downlink interfaces. Leaf downlink interfaces are configured as authentication interfaces for user authentication. When a user comes online on a leaf device, the leaf device uses the leaf downlink interface and VLAN ID of that user to identify the interface on the access device to which the user is connected. In addition, the leaf device can assign users to different user security groups according to their login accounts.
4. Access devices, acting as Layer 2 access devices, are mainly connected to endpoints. On access devices, the interfaces connected to leaf devices are access uplink interfaces. The uplink interfaces are configured as trunk ports permitting all VLANs by using the port trunk permit vlan all command. Access devices support cascading. Up to three tiers of cascading are supported. You must use the GE interfaces for cascading between access devices during automated deployment.
5. The SeerEngine-Campus controller assigns a VLAN ID to each downlink interface on the access devices to mark the location of each endpoint. The VLAN IDs start from VLAN ID 101 and increase sequentially on the multi-tier cascading access devices. For example, if two tiers of access devices are deployed, the downlink interfaces on the first tier of access devices are assigned VLAN IDs 101 to 152, and the downlink interfaces on the second tier of access devices are assigned VLAN IDs starting from 153. For access devices connected to different leaf downlink interfaces on the same leaf device, the VLAN IDs assigned to the access downlink interfaces on each access device are from VLAN ID 101.
6. Use the stp edged-port command to configure the interfaces connected to user endpoints on the access devices as spanning tree edge ports. For example:
#
interface GigabitEthernet1/0/31
port link-mode bridge
port access vlan 130
stp edged-port
#
|
|
IMPORTANT: The controller automatically deploys the stp edged-port command to the interfaces connected to endpoints on access devices after the access devices are incorporated into the controller. If you disconnect such an interface from an endpoint and connect it to a leaf device, the stp edged-port command that has been deployed on the interface cannot be deleted automatically. You must manually delete the command configuration. |
Configuration workflow
The AD-Campus 6.2 solution requires underlay configuration, device incorporation, overlay configuration, and user authentication configuration.
· The underlay configuration is the basis for the controller to incorporate devices, including the settings related to the physical connections between devices and the device automatic onboarding or manual onboarding configuration.
· The overlay configuration is related to user services, including settings that create private networks, Layer 2 network domains, and security groups, and settings that configure group policies and service chains.
· The user authentication configuration includes user management, access policies, and access services. The user authentication configuration is implemented through the EIA authentication server.
Figure 10 Configuration workflow
Both SeerEngine-Campus and EIA environments support standalone deployment and cluster deployment. For more information, see Unified Platform and Components Deployment Guide for AD-Campus 6.2 Solution.
|
|
NOTE: The underlay configuration supports device automated deployment and manual configuration. For information about automated deployment, see AD-Campus 6.2 Automation Configuration Guide or AD-Campus 6.2 Optimized Automation Configuration Guide. For information about manual configuration, see "Manual incorporation." |
Software and hardware information
Software information
Table 2 Software information
|
Name |
Feature description |
Remarks |
|
|
Unified Platform |
GlusterFS |
Provides the local shared storage function within the product. |
Required. |
|
Portal |
Portal, unified authentication, user management, service gateway, and help center. |
Required. |
|
|
Kernel |
Permissions, resource identity, licenses, configuration center, resource groups, and log services. |
Required. |
|
|
Kernel-base |
Alarms, access parameter templates, monitoring templates, reports, and email & SMS forwarding services. |
Required. |
|
|
Network |
Basic network management (network resources, network performance, network topology, and iCC). |
Required. |
|
|
Kernel-region |
Hierarchical management. |
Optional. |
|
|
Dashboard |
Provides a large screen framework. |
Required. |
|
|
Widget |
Provides widgets for the dashboard. |
Required. |
|
|
Syslog |
Provides syslog features and the log center. |
Optional. |
|
|
WebSocket |
Provides the legacy device automation function and optimized automation function. |
Required. |
|
|
Components for campus networks |
SeerEngine-Campus |
Campus network controller, which provides basic campus service configuration. |
Required. |
|
vDHCP |
DHCP server, which allocates addresses to automatically onboarded devices and to endpint users. |
Required. |
|
|
EIA |
Endpoint intelligent access, which provides user authentication service configuration. |
Required. |
|
|
WSM |
Wireless service management, which provides wireless access network services. |
Optional. |
|
|
EAD |
Endpoint admission defense, which controls and restricts endpoint access. |
Optional. |
|
|
EPS |
Endpoint profiling system, which actively identifies endpoints and detects endpoint access. |
Optional. |
|
|
SeerAnalyzer |
Supports network data collection and analysis. |
Optional. |
|
|
SMP |
Provides the firewall management function. |
Optional. |
|
|
DHCP servers supporting tight coupling mode |
vDHCP server |
H3C DHCP server. |
Required. |
|
Microsoft DHCP server |
Supports the tight and loose coupling modes. |
N/A |
Hardware information
Table 3 Hardware information
|
Device model |
Default role |
Other roles supported |
|
S12500G-AF |
Spine |
· Leaf · Access |
|
S10500X |
Spine |
· Leaf · Access |
|
S7500X |
Leaf |
· Spine · Access |
|
S6550XE-HI |
Leaf |
Access |
|
S6525XE-HI |
Leaf |
Access |
|
S6520X-HI |
Leaf |
Access |
|
S5560X-HI |
Leaf |
Access |
|
S6520X-EI (microsegmentation not supported) |
Leaf |
Access |
|
S5560X-EI (microsegmentation not supported) |
Leaf |
Access |
|
S6520X-SI |
Access |
None |
|
S5130-EI S5130-HI S5130S-EI S5130S-HI |
Access |
None |
Resource and IP address planning
Server resource planning
The intermediate switch between the servers and the network devices are a L3 switch. Whether devices are onboarded automatically or manually, manual configuration is required on the intermediate L3 switch to ensure connectivity between the devices and the controller.
You must plan the network before configuring it. The SeerEngine-Campus controller and Unified Platform can share a single NIC or use NICs separately.
|
|
IMPORTANT: As a best practice, use IP addresses in different subnets for the EIA and VLAN 4094 services. |
Dual-spine uplink networking
Scenario where the SeerEngine-Campus controller and Unified Platform share a single NIC
Figure 11 Network diagram for the scenario
Table 4 List of server IPs and L3 switch network segment planning
|
Item |
Example |
Remarks |
|
VLAN 1 network segment (gateway) |
120.1.0.0/24 (120.1.0.1) |
VLAN 1 network, used for automated deployment. |
|
VLAN 4094 network segment (gateway) |
130.1.0.0/24 (130.1.0.1) |
VLAN 4094 network, used for communication between the controller and devices. |
|
VLAN 10 network segment (gateway) |
10.0.0.0/24 (10.0.0.1) |
Used for Layer 3 communication with spine devices. |
|
VLAN 11 network segment (gateway) |
11.0.0.0/24 (11.0.0.1) |
Used for Layer 3 communication with spine devices. |
|
VLAN 30 network segment (gateway) |
100.1.0.0/24 (100.1.0.1) |
Network segment used by Unified Platform, SeerEngine-Campus, and vDHCP. |
|
Network segment of underlay IP addresses |
200.1.1.0/24 |
IP addresses for loopback interfaces on spine and leaf devices. |
|
Unified Platform northbound service IP address |
100.1.0.100 |
IP address for logging in to Unified Platform. |
|
EIA |
100.1.0.100 |
IP address of the EIA server. In converged deployment, the EIA server uses the northbound service IP address of Unified Platform. |
|
SeerEngine-Campus cluster IP address |
100.1.0.200 |
IP address of the SeerEngine-Campus controller cluster. |
|
SeerEngine-Campus node IP addresses |
Node 1: 100.1.0.201 Node 2: 100.1.0.202 Node 3: 100.1.0.203 |
IP addresses of the nodes in the SeerEngine-Campus controller cluster. |
|
vDHCP cluster IP address |
100.1.0.204 |
Cluster IP address of the vDHCP server (not in use). |
|
vDHCP node IP addresses |
Node 1: 100.1.0.205 Node 2: 100.1.0.206 |
IP addresses of the nodes on the vDHCP server. |
|
Microsoft DHCP IP address |
8.0.1.171 |
IP address of the Microsoft DHCP server. |
Scenario where the SeerEngine-Campus controller and Unified Platform use separate NICs
Figure 12 Network diagram for the scenario
In this example, the SeerEngine-Campus controller and Unified Platform use separate NICs. The address planning is as shown in Table 5.
Table 5 List of server IPs and L3 switch network segment planning
|
Item |
Example |
Remarks |
|
VLAN 1 network segment (gateway) |
120.1.0.0/24 (120.1.0.1) |
VLAN 1 network, used for automated deployment. |
|
VLAN 4094 network segment (gateway) |
130.1.0.0/24 (130.1.0.1) |
VLAN 4094 network, used for communication between the controller and devices. |
|
VLAN 10 network segment (gateway) |
10.0.0.0/24 (10.0.0.1) |
Used for Layer 3 communication with spine devices. |
|
VLAN 11 network segment (gateway) |
11.0.0.0/24 (11.0.0.1) |
Used for Layer 3 communication with spine devices. |
|
VLAN 30 network segment (gateway) |
100.1.0.0/24 (100.1.0.1) |
Network segment used by Unified Platform for communication with PCs. |
|
VLAN 1010 (gateway) |
110.1.0.0/24 (110.1.0.1) |
Network segment used by SeerEngine-Campus and vDHCP for communication between the controller and PCs (configured when SeerEngine-Campus uses an independent NIC). |
|
Network segment of underlay IP addresses |
200.1.1.0/24 |
IP addresses of loopback interfaces on spine and leaf devices. |
|
Unified Platform northbound service IP address |
100.1.0.100 |
IP address for logging in to Unified Platform. |
|
EIA |
100.1.0.100 |
IP address of the EIA server. |
|
SeerEngine-Campus cluster IP address |
110.1.0.100 |
IP address of the SeerEngine-Campus controller cluster. |
|
SeerEngine-Campus node IP addresses |
Node 1: 110.1.0.101 Node 2: 110.1.0.102 Node 3: 110.1.0.103 |
IP addresses of the nodes in the SeerEngine-Campus controller cluster. |
|
vDHCP cluster IP address |
110.1.0.104 |
Cluster IP address of the vDHCP server (not in use). |
|
vDHCP node IP addresses |
Node 1: 110.1.0.105 Node 2: 110.1.0.106 |
IP addresses of the nodes on the vDHCP server. |
|
Microsoft DHCP IP address |
8.0.1.171 |
IP address of the Microsoft DHCP server. |
Spine IRF uplink networking
Scenario where the SeerEngine-Campus controller and Unified Platform share a single NIC
In this scenario, Unified Platform, the SeerEngine-Campus controller, the vDHCP server, and the EIA server use IP addresses in the same network segment.
Figure 13 Network diagram for the scenario
Table 6 List of server IPs
|
Item |
Example |
Remarks |
|
VLAN 1 network segment (gateway) |
120.1.0.0/24 (120.1.0.1) |
VLAN 1 network, used for automated deployment. |
|
VLAN 4094 network segment (gateway) |
130.1.0.0/24 (130.1.0.1) |
VLAN 4094 network, used for communication between the controller and devices. |
|
VLAN 30 network segment (gateway) |
100.1.0.0/24 (100.1.0.1) |
Network segment used by Unified Platform, SeerEngine-Campus, and vDHCP. |
|
VLAN 91 network segment |
91.1.0.0/24 |
VLAN used for communication between spine and leaf devices during manual incorporation. |
|
Network segment of underlay IP addresses |
200.1.1.0/24 |
IP addresses of loopback interfaces on spine and leaf devices. |
|
Unified Platform northbound service IP address |
100.1.0.100 |
IP address for logging in to Unified Platform. |
|
EIA |
100.1.0.100 |
IP address of the EIA server. In converged deployment, the EIA server uses the northbound service IP address of Unified Platform. |
|
SeerEngine-Campus cluster IP address |
100.1.0.200 |
IP address of the SeerEngine-Campus controller cluster. |
|
SeerEngine-Campus node IP addresses |
Node 1: 100.1.0.201 Node 2: 100.1.0.202 Node 3: 100.1.0.203 |
IP addresses of the nodes in the SeerEngine-Campus controller cluster. |
|
vDHCP cluster IP address |
100.1.0.204 |
Cluster IP address of the vDHCP server (not in use). |
|
vDHCP node IP addresses |
Node 1: 100.1.0.205 Node 2: 100.1.0.206 |
IP addresses of the nodes on the vDHCP server. |
|
Microsoft DHCP IP address |
8.0.1.171 |
IP address of the Microsoft DHCP server. |
Scenario where the SeerEngine-Campus controller and Unified Platform use separate NICs
In this scenario, the SeerEngine-Campus controller and Unified Platform use IP addresses in different network segments. The EIA server and the Unified Platform cluster reside in the same network segment, and the SeerEngine-Campus controller and vDHCP server share the same network segment.
Figure 14 Network diagram for the scenario
In this example, the SeerEngine-Campus controller and Unified Platform use separate NICs. The address planning is as shown in Table 7.
|
Item |
Example |
Remarks |
|
VLAN 1 network segment (gateway) |
120.1.0.0/24 (120.1.0.1) |
VLAN 1 network, used for automated deployment. |
|
VLAN 4094 network segment (gateway) |
130.1.0.0/24 (130.1.0.1) |
VLAN 4094 network, used for communication between the controller and devices. |
|
VLAN 30 network segment (gateway) |
100.1.0.0/24 (100.1.0.1) |
Network segment used by Unified Platform for communication with PCs. |
|
VLAN 1010 network segment (gateway) |
110.1.0.0/24 (110.1.0.1) |
Network segment used by SeerEngine-Campus and vDHCP for communication between the controller and PCs (configured when SeerEngine-Campus uses an independent NIC). |
|
VLAN 91 network segment |
91.1.0.0/24 |
VLAN used for communication between spine and leaf devices during manual incorporation. |
|
Network segment of underlay IP addresses |
200.1.1.0/24 201.1.1.0/24 |
IP addresses of loopback interfaces on spine and leaf devices. |
|
Unified Platform northbound service IP address |
100.1.0.100 |
IP address for logging in to Unified Platform. |
|
EIA |
100.1.0.100 |
IP address of the EIA server. |
|
SeerEngine-Campus cluster IP address |
110.1.0.100 |
IP address of the SeerEngine-Campus controller cluster. |
|
SeerEngine-Campus node IP addresses |
Node 1: 110.1.0.101 Node 2: 110.1.0.102 Node 3: 110.1.0.103 |
IP addresses of the nodes in the SeerEngine-Campus controller cluster. |
|
vDHCP cluster IP address |
110.1.0.104 |
Cluster IP address of the vDHCP server (not in use). |
|
vDHCP node IP addresses |
Node 1: 110.1.0.105 Node 2: 110.1.0.106 |
IP addresses of the nodes on the vDHCP server. |
|
Microsoft DHCP IP address |
8.0.1.171 |
IP address of the Microsoft DHCP server. |
User resource planning
Table 8 shows the resource planning for user services.
Table 8 User service resource planning
|
Item |
Example |
Remarks |
|
Teacher security group network segment (gateway) |
20.0.0.0/16 (20.0.0.1) |
Used by users in the teacher security group. |
|
BYOD security group network segment (gateway) |
50.0.0.0/16 (50.0.0.1) |
Used by BYOD users. |
|
Guest network segment (gateway) |
22.2.2.0/24 (22.2.2.1) |
Used by guest users. |
|
Authentication-failed network segment (gateway) |
33.3.3.0/24 (33.3.3.1) |
Used by users who fail the user authentication. |
|
Critical segment (gateway) |
40.0.0.0/16 (40.0.0.1) |
Used by users assigned to critical segments for example, critical VLANs or VSIs. |
User VLAN planning
You must make VLAN resource planning in advance, because you cannot modify a VLAN pool after that VLAN pool is in use. The modification includes adding or deleting VLAN ranges and reserving VLAN ranges.
The following types of VLAN pools are supported:
· Campus access VLAN pool—Deploys VLAN settings to access devices after they are onboarded. The default VLAN range is 101 to 3000.
· Security group VLAN pool—Allocates VLAN IDs to security groups in an isolation domain for user access. The default VLAN range is 3501 to 4000.
· Campus auth-free VLAN pool—Allocates VLAN IDs to auth-free entities in an isolation domain and deploys VLAN settings to the access devices to which the auth-free entities are bound. The default VLAN range is 4051 to 4060.
· Wired service VLAN pool—Assigns VLAN IDs to wired users in an isolation domain of the VLAN network type. The default VLAN range is 101 to 3000.
· Wireless service VLAN pool—Assigns VLAN IDs to wireless users in an isolation domain of the VLAN network type. The default VLAN range is 3501 to 3600.
Restrictions and guidelines
The SeerEngine-Campus controller provides predefined VLAN pools. The names of the following prefefined VLAN pools cannot be modified:
· default_access, which is a campus access VLAN pool.
· default_security_group, which is a security group VLAN pool.
· default_auth_free, which is a campus auth-free VLAN pool.
· default_wireless, which is a wireless service VLAN pool.
· default_wired, which is a wired service VLAN pool.
You cannot modify a VLAN pool after that VLAN pool is in use. The modification includes adding or deleting VLAN ranges and reserving VLAN ranges.
VLANs in different VLAN pools cannot overlap.
An access VLAN pool supports the configuration of reserved VLAN ranges.
By default, the SeerEngine-Campus controller allocates VLAN 100 to automatically configured IRF fabrics for BFD MAD, and VLAN 4090 to VLAN 4094 are reserved VLANs.
By default, the controller deploys VLAN 2 to the DR member devices in a DR system for underlay route synchronization.
If the user environment is upgraded from a previous version to version 6.2, VLAN configuration differences might exist. To remove the differences, click Sync Data.
Procedure
To configure VLAN pools and view information about all VLAN pools in the system:
1. Navigate to the Automation > Campus Network > Devices page.
2. Click VNID Pools in the upper right corner of the page.
3. Click the VLANs tab to open the VLANs page.
Figure 15 VLANs page
To adjust the VLAN ranges of a VLAN pool,
click the Edit icon 
in the Actions
column for the VLAN pool. In the VLAN Range area, click the Edit
icon 
in the Actions column for a VLAN
range to modify the VLAN range.
Configuring AD-Campus
Logging in to the AD-Campus controller
1. After installation and deployment, open the login page of the AD-Campus controller by entering the login address of the controller in the address bar of a browser, as shown in Figure 16. The format of the login address is http://login-ip:30000/central. The login IP is the northbound service VIP of the Unified Platform cluster. In this example, the login IP is 100.1.0.100. The default login username and password are admin and Pwd@12345, respectively.
Figure 16 Login page
2. Enter the username and password, and then click Login to log in to the AD-Campus controller as shown in Figure 17.
3. Click the 
icon on the top
left of the page to view all the menus, as shown in Figure 18.
4. The automation module is used to configure campus network services. On the top navigation bar, click Automation to expand menus on the left navigation pane, as shown in Figure 19.
¡ Configuration Options: Configure settings for services, including device backup, configuration restoration, and software library.
¡ Campus Network: Mainly provide configuration menus related to SeerEngine-Campus controller services, including creation of automation templates for device onboarding and configuration of isolated domains, fabrics, security groups, user group policies, and service chains.
¡ User: The service configuration menu of the EIA authentication server, including configuration of access services, access policies, and access users.
Figure 19 Automation menu options
Registering licenses
About this task
After the controller installation and deployment, you must register licenses for SeerEngine-Campus, EIA, vDHCP, and Unified Platform. Before registering the licenses, configure a license server and purchase the licenses.
In the current software version, you can register formal licenses or use trial licenses.
This section describes only license registration on the Web interface of the AD-Campus controller. For information about setting up and configuring a license server, see the license server manuals.
Procedure
1. Navigate to the System > License Management > License Info page.
After the system is installed and deployed, trial licenses are available by default, as shown in Figure 20.
Figure 20 License server information
2. Configure the license server parameters in the License server Info area.
Parameters:
¡ IP Address: Enter the IP address of the license server. Make sure the northbound IP of the cluster and the license server can reach each other.
¡ Port: Enter the port number, 5555 in this example.
¡ Username: Enter the username used for accessing the license server (DEMO in this example).
¡ Password: Enter the password used for accessing the license server (admin@123 in this example).
3. Click Connect. After the system connects to the license server successfully, the license information page displays the available licenses, as shown in Figure 21.
Prerequisites
Before using the configuration wizard, you must configure user endpoint, authentication server, and DHCP server settings.
Configuring user endpoint settings
To configure user endpoint settings to enable VXLAN networking on the user authentication server:
1. Navigate to the Automation > User > Service Parameters > Access Parameters > System Settings page as shown in Figure 22.
Figure 22 Configuring user endpoint settings
2. Click the Edit
icon 
in the Configure column for the template named User Endpoint Settings to access the user
endpoint settings page, as shown in Figure 23.
Configure parameters in the User Endpoint Settings and Director
Controller Configuration areas.
Parameters in the User Endpoint Settings area:
¡ VXLAN Networking: Select Yes.
¡ MAC Portal Authentication: Select Enabled.
¡ Transparent Authentication: Select Enabled.
¡ Unbind IP for Duplicate Account: By default, the value is No.
- To disable IP preemption, select No. After one endpoint goes offline, its bound IP address cannot be bound to another endpoint that requests to come online.
- To enable IP preemption, select Yes. After one endpoint goes offline, its bound IP address can be bound to another endpoint that requests to come online.
¡ Max. Device for Single Account: Set the maximum number of endpoints that can use an account to come online. The default number is 10. For example, if you set this field to 10, a maximum of 10 endpoints can use this account to come online.
Figure 23 Configuring user endpoint settings
Parameters in the Director Controller Configuration area:
Embedded Controller: By default, the value is Yes. If the SeerEngine-Campus controller and EIA are deployed on the same platform, select Yes. You do not need to configure the parameters manually. If you select No, configure the following parameters:
¡ IP Address: Enter the address used to log in to the SeerEngine-Campus controller.
¡ Port: Enter the port number for logging in to Unified Platform. The port number is 30000 in this example.
¡ Username/Password: Enter the username and password. By default, the username is admin, and the password is Pwd@12345.
¡ Protocol: Select HTTP or HTTPS according to the protocol set when deploying Unified Platform. By default, HTTP is used.
Figure 24 Configuring the controller
Configuring AAA server settings
Supported AAA servers include H3C EIA V7 (iMC EIA), EIA V9 (containerized EIA), and third-party authentication servers.
To add an AAA server, navigate to the Automation > Campus Network > Network Parameters > AAA page and click Add.
Parameters:
· Name: Enter a name for the AAA server, which cannot be the same as the name of an existing AAA server in the current environment.
· Server Type:
¡ EIA V9: EIA server deployed on Unified Platform. It is an EIA cluster. EIA hierarchical deployment is not supported in the current software version.
¡ EIA V7: EIA server deployed on the iMC platform. EIA hierarchical deployment is supported.
¡ Third Party Authentication: Used to provide interfaces for MAC portal authentication.
· Protocol: Select the protocol used to log in to the EIA server. By default, it is HTTP.
· Ipv4: Enter the IP address of the EIA server.
· GUI Port: The system will automatically fill in this field according to the selected server type.
· Username: Enter the username used to log in to the EIA server.
· Password: Enter the password used to log in to the EIA server.
Figure 25 Adding an AAA server
EIA V9
EIA V9 uses containerized deployment. After you deploy an EIA component in the Unified Platform cluster environment, the system automatically adds the component to the AAA server list in the name of Default EIA.
EIA V7
An EIA V7 server is deployed on the iMC platform based on Window or Linux operating systems (OSs) and supports the single-host mode, cluster mode, and hierarchical deployment mode.
· Single-host mode: Requires a physical server or a VM that uses a Windows or Linux OS.
· Cluster mode: Requires two physical servers that use Windows or Linux operating systems. The two servers form a stateful failover cluster.
· Hierarchical deployment mode: Requires one higher-level EIA node and multiple lower-level EIA nodes. A maximum of 20 nodes are supported. Authentication settings including users and policies are configured on the higher-level EIA node. The lower-level EIA nodes synchronize the settings from the higher-level node. This mode is suitable for multi-campus scenarios. These EIA nodes act as backups for each other to improve service availability. At present, only EIA V7 supports the hierarchical deployment mode. In the current software version, only the Windows + Mysql or Linux + Mysql architecture is supported. Mysql database versions 5.5 to 5.8 are supported. As a best practice, use version 5.7.
Third-party authentication
A third-party authentication server is used for Web portal authentication. You only need to configure the IP address of the third-party server on the SeerEngine-Campus controller and make sure the third-party authentication server and the user access device can reach each other.
Configuring DHCP server settings
1. Navigate to the Automation > Campus Network > Network Parameters > DHCP page.
2. Click Add.
Figure 26 Adding a DHCP server
3. On the Add DHCP Sever page, select Tight or Loose for Management Mode.
Figure 27 Selecting a management mode
Tight coupling
H3C vDHCP servers and Microsoft DHCP servers support tight coupling.
In tight coupling mode, the SeerEngine-Campus controller requests the DHCP server to create an IP address pool according to the IP address segment configured on the page. IP address binding is supported.
For automated device deployment, the DHCP server must be an H3C vDHCP server.
Adding a vDHCP server
1. Configure the following parameters on the DHCP tab and click OK after completing the configuration:
¡ Management Mode: Select Tight. A vDHCP server supports only tight coupling.
¡ High Available: Select this option in cluster mode. In standalone mode, you do not need to select this option.
¡ IPv4/IPv6 Dual Stack: Select this option if IPv6 automated deployment or user IPv6 services are available. For more information about the configuration, see AD-Campus 6.2 IPv6 Service Configuration Guide.
¡ IPv4/IPv6
Address: Enter the address assigned when the vDHCP
server is deployed. To obtain the IP address, access the vDHCP deployment page by navigating to the System > Deployment Management page, expanding the Public Service item, and click the 
icon
to view the details.
¡ Vendor: Select H3C.
2. After adding the DHCP server, click 
in the Actions column to synchronize the DHCP server. The Audit
Status column displays Audit Succeeded after the synchronization is completed.
3. To view the address pool and IP address allocation information for the DHCP server, click the name of the DHCP server.
Adding a Microsoft DHCP server
1. Add a DHCP server.
a. On the Add DHCP Server page, select Microsoft for Vendor, configure the following parameters, and then click OK:
- Management Mode: Select Tight.
- High Available: Select this option for Microsoft DHCP HA in active/standby environment. In standalone mode, you do not need to select this option.
- IPv4 Address: Enter the IP address of the Microsoft DHCP server. In an HA environment, enter the IP addresses of the two DHCP servers.
- Vendor: Select Microsoft.
b. After adding the DHCP server, click 
in the Actions
column to synchronize the DHCP server. The Audit Status column displays Audit
Succeeded after the
synchronization is completed.
c. To monitor the Microsoft DHCP HA status, click the 
icon
in the upper right corner of the DHCP server list page. By default, HA monitor is enabled. The SeerEngine-Campus
controller monitors DHCP HA status periodically. The
controller automatically enables the backup Microsoft DHCP server when it
detects failure of the primary Microsoft DHCP server.
2. Configure the VXLAN 4094 address pool.
|
|
IMPORTANT: After adding a Microsoft DHCP server, you must manually create an address pool on the SeerEngine-Campus controller. Make sure the address pool is on the same network as VXLAN 4094 on devices. If you do not create such an address pool, the Microsoft DHCP server cannot respond to the DHCP requests sent by leaf devices. |
On the DHCP tab, click the name of the Microsoft DHCP server.
On the DHCP Pools tab, click Add to add an address pool and configure the following parameters:
¡ Subnet: Make sure the address pool is on the same network as VXLAN 4094 on devices. This address pool is not used for user services.
¡ Gateway: Enter an IP address in the same network segment as VXLAN 4094.
¡ For other parameters, use the default values.
After the Microsoft DHCP server is created and deployed successfully, you can see the created scope on the Microsoft DHCP server.
Loose coupling
Microsoft DHCP servers and WRD DHCP servers support loose coupling.
In loose coupling mode, the SeerEngine-Campus controller does not create any address pools on the DHCP server or synchronize address pool information from the DHCP server.
You must manually create all address pools and policies in the address pools for matching Option 82 information carried in DHCP Relay packets sent by leaf devices.
Different DHCP servers have different configuration methods. For more information about configuring a Microsoft DHCP server, see "Configuring the critical DHCP server."
A DHCP server in loose coupling mode cannot
be synchronized. No 
icon is available for the
DHCP server. The Audit Status column for the DHCP server displays three
hyphens (---).
Enabling conventional forwarding entry learning for static Ethernet service instances
If the networking includes S6520X series or S5560X series switches, enable conventional forwarding entry learning for static ACs as a best practice by navigating to the Automation > Campus Network > Network Parameters > Parameter page.
When conventional forwarding entry learning for static ACs is enabled, a device issues a forwarding entry to the hardware only when the forwarding entry is required for packet forwarding on an Ethernet service instance. The following configuration is deployed to a static Ethernet service instance on a leaf interface:
#
interface Bridge-Aggregation1024
port link-type trunk
port trunk permit vlan 1 101 to 3000 4094
link-aggregation mode dynamic
stp tc-restriction
mac-based ac
dot1x
undo dot1x multicast-trigger
dot1x unicast-trigger
dot1x critical vsi vsi9
dot1x critical eapol
mac-authentication
mac-authentication domain
port-security free-vlan 1 3501 to 3505 4094
#
service-instance 3501
encapsulation s-vid 3501
xconnect vsi vsi3 on-demand
arp detection trust
#
Device onboarding
Legacy automated deployment
In legacy automated deployment, the controller and devices cooperate to complete the automated deployment process. For more information, see AD-Campus 6.2 Automation Configuration Guide.
Optimized automated deployment
In optimized automated deployment, automated deployment is completely performed by the controller, without relying on the devices. For more information, see AD-Campus 6.2 Optimized Automation Configuration Guide.
Half automated deployment
In half automated deployment, the spine and leaf devices are incorporated manually, while the access devices are deployed automatically. For information about manually incorporating spine and leaf devices, see "Manual incorporation." For automated deployment of access devices and other settings related to haft automated deployment, see AD-Campus 6.2 Half Automation Configuration Guide.
Manual incorporation
This section describes the basic configuration procedures for manual configuration when spine devices, leaf devices, and access devices are not automatically deployed. After the underlay configuration is completed, the SeerEngine-Campus controller can incorporate the devices and deploy overlay settings to the devices.
|
|
NOTE: · This section describes only manual underlay deployment. For information about automated underlay deployment, see AD-Campus 6.2 Automation Configuration Guide. · In this section, the configuration of the Layer 3 switch is applicable to scenarios where the spine device is a standalone node or an IRF fabric. If dual-homed spine devices are deployed in the network, see "Configuring redundant dual-spine uplinks" for information about configuring the Layer 3 switch. · If no Layer 3 switch is available or the gateway of the VLAN 4094 network segment is on a spine device, you do not need to configure static routes destined for the network segment of the controller on the leaf devices. |
Configuring the Layer 3 switch
# Enable DHCP.
dhcp enable
#
# Enable the spanning tree feature globally.
stp global enable
#
# Create VLAN-interface 4094.
#
vlan 4094
#
#
interface Vlan-interface4094
ip address 130.1.0.1 255.255.255.0
#
# Configure VLAN-interface 1. VLAN-interface 1 is used for automatic device onboarding. If devices in the network are all manually incorporated, skip the configuration of VLAN-interface 1.
interface Vlan-interface1
ip address 120.1.0.1 255.255.255.0
dhcp select relay //DHCP relay related settings are used for automatic device onboarding. If spine, leaf, and access nodes are all manually incorporated, the DHCP relay related settings are not required.
dhcp relay server-address 110.1.0.105 //IP address of the vDHCP server node.
dhcp relay server-address 110.1.0.106
#
# Create VLAN-interface 30 and VLAN-interface 1010.
#
vlan 30
vlan 1010
#
#
interface Vlan-interface 30
ip address 100.1.0.1 255.255.255.0
#
#
interface Vlan-interface 1010
ip address 110.1.0.1 255.255.255.0
#
# Configure the interface connected to a spine device.
#
interface Ten-GigabitEthernet1/0/6
description to_spine
port link-type trunk
port trunk permit vlan 1 4094 //If all spine, leaf, and access devices in the network are onboarded through manual configuration, use the undo permit vlan 1 command.
#
# Add the interface connected to Unified Platform to VLAN 30.
#
interface GigabitEthernet1/0/7
port access vlan 30
stp edged-port //The port connecting the Layer 3 switch to the server is configured as an STP edge port.
#
# Add the interface connected to SeerEngine-Campus and vDHCP to VLAN 1010.
#
interface GigabitEthernet1/0/3
port access vlan 1010
stp edged-port //The port connecting the Layer 3 switch to the server is configured as an STP edge port.
#
# Add a default route. Configure the address of VSI-interface 4094 on the spine node as the next hop of the default route for communication between authentication users and EIA.
ip route-static 0.0.0.0 0 130.1.0.2 //The next hop of the default route is the address of VSI-interface 4094 on the spine node.
#
Configuring a spine device
Before incorporating a spine device into the SeerEngine-Campus controller, you must perform the following tasks:
1. Configure the spine role and system name:
# For the role configuration to take effect, you must reboot the device. Skip the role configuration if the default role of the device is spine.
vcf-fabric role spine
#
sysname spine
#
2. Configure LLDP to determine the topology.
#
lldp global enable
#
3. Configure the spanning tree feature.
#
stp ignored vlan 2 to 4094
stp global enable
stp root primary //Configure the spine device as the STP root.
#
4. Configure SNMP, NETCONF, Telnet, and SSH settings:
# Configure SNMP settings. The following configuration is the default configuration. You must configure the SNMP communities according to the actual network conditions.
snmp-agent
snmp-agent community write private
snmp-agent community read public
snmp-agent sys-info version all
snmp-agent packet max-size 4096
#
# Configure NETCONF settings.
netconf soap http enable
netconf soap https enable
netconf ssh server enable
restful https enable
#
# Configure Telnet settings.
telnet server enable //Required when Telnet is used.
#
# Configure SSH settings.
ssh server enable
#
5. Configure the username and password used by Telnet or SSH:
# Set the username to admin and password to H3C1234567.
local-user admin class manage
password simple H3C1234567 //The password must meet the password complexity requirements. A qualified password must be a string of 10 to 63 characters that contain a minimum of two characters types from digits, uppercase letters, lowercase letters, and special characters. The password cannot contain Chinese characters, question marks (?), spaces, or the username or reverse order of username characters.
service-type telnet http https ssh
authorization-attribute user-role network-admin
authorization-attribute user-role network-operator
#
#
line vty 0 63
authentication-mode scheme
user-role network-admin
user-role network-operator
#
6. Create VLAN 4094.
vlan 4094
#
7. Configure OSPF.
#
ospf 1 router-id 200.1.1.254
non-stop-routing
area 0.0.0.0
#
8. Configure Loopback 0.
#
interface LoopBack0
ip address 200.1.1.254 255,255,255,255
ospf 1 area 0.0.0.0 //Configure OSPF.
#
9. Configure the spine downlink interface. Create multiple VLAN interfaces if multiple downlink interfaces are available.
# Create a VLAN.
vlan 91
#
# Create a VLAN interface.
interface Vlan-interface91
ip address 91.1.0.1 24 //Depending on the actual planning, use an unused subnet address.
ospf network-type p2p
ospf 1 area 0.0.0.0
#
# Assign the spine downlink interfaces to the VLAN.
#
interface Ten-GigabitEthernet3/0/16
port link-mode bridge
port link-type trunk
port trunk permit vlan 1 91 //If all spine, leaf, and access devices in the network are onboarded through manual configuration, use the undo permit vlan 1 command.
#
|
|
IMPORTANT: As a best practice, use VLANs 3 to 99, VLANs 4001 to 4050, and VLANs 4061 to 4089 for VLAN interfaces in route advertisement. The SeerEngine-Campus controller by default automatically deploys the following VLANs to devices: · VLAN 2—This VLAN is used for underlay route synchronization between two DR member devices in a DR system. · VLAN 100—This VLAN is used for BFD MAD on automatically configured IRF fabrics. · VLANs 101 to 2800—The VLANs are used by access switches. · VLANs 2801 to 3000—The VLANs are used by static ACs. · VLANs 3001 to 3500—The VLANs are used for automated device deployment on the links interconnected spine and leaf devices. · VLANs 3501 to 4000—The VLANs are used by security groups. · VLANs 4090 to 4094—The VLANs are reserved. VLANs 3 to 99 and VLANs 4001 to 4089 cannot be assigned automatically. VLANs 4051 to 4060 are used as authentication-free VLANs. When spine and leaf nodes are connected through multiple links, the links are ECMP links. As VLAN 1 is enabled with the spanning tree feature, it is normal that the links between the spine and leaf nodes are in discarding state. |
10. Enable L2VPN.
#
l2vpn enable
#
11. For connectivity of the control channel, configure VPN instance vpn-default, VSI-interface 4094, and VSI interface IP address settings, and specify an L3 VXLAN ID:
# Create VPN instance vpn-default. Configure the RD and route targets manually. The RD and route targets are 1:1 in the whole network.
#
route-distinguisher 1:1
vpn-target 1:1 import-extcommunity
vpn-target 1:1 export-extcommunity
#
address-family ipv4
vpn-target 1:1 import-extcommunity
vpn-target 1:1 export-extcommunity
#
address-family evpn
vpn-target 1:1 import-extcommunity
vpn-target 1:1 export-extcommunity
#
# Configure VSI-interface 4094.
interface Vsi-interface4094
ip binding vpn-instance vpn-default
ip address 130.1.0.2 255.255.255.0
local-proxy-arp enable
arp proxy-send enable //Enable ARP request proxy to resolve the issue that an endpoint cannot connect to a server if no server ARP entry exists on the device because of network connection timeout.
#
# Configure VSI interface and L3 VXLAN ID settings for Layer 3 forwarding. In this example, create VSI-interface 4092 and configure L3 VXLAN ID 4092 for VPN instance vpn-default. The ip address unnumbered command is used to configure an interface to borrow the IP address of the specified interface. When a security group is created in VPN instance vpn-default, specify the IP of VSI-interface 4094 as the source IP of Layer 3 outgoing packets.
interface Vsi-interface4092
ip binding vpn-instance vpn-default
ip address unnumbered interface Vsi-interface4094
l3-vni 4092
#
# Configure VSI vxlan4094.
vsi vxlan4094
gateway vsi-interface 4094
vxlan 4094
mac-advertising disable
arp mac-learning disable
nd mac-learning disable
route-distinguisher auto
vpn-target auto export-extcommunity
vpn-target auto import-extcommunity
#
12. Configure BGP EVPN:
|
|
IMPORTANT: If multiple leaf nodes are available, you must configure multiple peers. Make sure the BGP AS number is the same as the AS number set for the fabric on the SeerEngine-Campus controller. |
#
bgp 100
non-stop-routing
router-id 200.1.1.254 //The router ID of each device cannot be the same.
peer 200.1.1.252 as-number 100 //Configure a BGP peer. The IP address is the loopback interface of a leaf device.
peer 200.1.1.252 connect-interface LoopBack0
#
address-family l2vpn evpn
reflector cluster-id 200.1.1.254 //Required in the dual-spine network environment and the cluster IDs of the two spine devices are the same.
undo policy vpn-target //Required to not filter the received VPNv4 routes.
peer 200.1.1.252 enable //Repeat this command to configure multiple peers if multiple leaf nodes exist.
peer 200.1.1.252 reflect-client //Configure the route reflector for forwarding routes between different leaf devices.
#
ip vpn-instance vpn-default
#
address-family ipv4 unicast
import-route direct //Import directly connected routes. The configuration is required if IPv4 conversational learning is enabled on the leaf device.
import-route static //Import static routes.
#
13. Configure the spine uplink interface (the interface connected to the Layer 3 switch) as an AC interface and bind it to VSI vxlan4094.
#
interface Ten-GigabitEthernet3/0/2
port link-mode bridge
port link-type trunk
port trunk permit vlan 1 4094 //If all spine, leaf, and access devices in the network are onboarded through manual configuration, use the undo permit vlan 1 command.
service-instance 4094 //Create Ethernet service instance 4094.
encapsulation s-vid 4094 //Match VLAN tag 4094.
xconnect vsi vxlan4094 //Bind the Ethernet service instance to VSI vxlan4094.
#
14. Configure static routes.
# When the connections between the spine node and SeerEngine-Campus, EIA, or other servers are Layer 3 connections, you must configure static routes destined for the servers. The next hop of the static routes is the IP address of VLAN-interface 4094 on the Layer 3 switch.
ip route-static vpn-instance vpn-default 110.1.0.0 24 130.1.0.1 //The destination IP is the subnet IP of the controller.
#
ip route-static vpn-instance vpn-default 100.1.0.0 24 130.1.0.1 //The destination IP is the subnet IP of the server.
#
# If the DHCP server and spine device belong to different subnets, you must add a static route destined for the DHCP server.
ip route-static vpn-instance vpn-default 132.0.0.0 24 130.1.0.1 //DHCP server subnet IP.
#
15. Disable remote-MAC entry learning and remote ARP and ND learning on the VXLAN tunnels:
# Disable remote ARP learning on VXLAN tunnels.
vxlan tunnel arp-learning disable
#
# Disable remote ND learning on VXLAN tunnels if IPv6 services are configured.
vxlan tunnel nd-learning disable
#
# Disable remote-MAC entry learning on VXLAN tunnels.
vxlan tunnel mac-learning disable
#
16. Configure NTP.
#
clock timezone beijing add 08:00:00
#
# If the IP address is that of the NTP server, Unified Platform is configured with a built-in NTP server by default, and the IP address is the cluster northbound IP.
ntp-service enable
ntp-service unicast-server 100.1.0.100 vpn-instance vpn-default
#
17. If the spine is an IRF fabric, configure the IRF bridge MAC address to remain unchanged after a master/subordinate switchover.
#
irf mac-address persistent always
#
Configuring a leaf device
|
|
IMPORTANT: Set the device operating mode to VXLAN if the device is an S5560X or S6520X switch. For the mode change to take effect, you must reboot the device. |
Before a leaf device is incorporated into the SeerEngine-Campus controller, perform the following tasks:
1. Set the device operating mode to VXLAN:
# Display the device operating mode and make sure the device is operating in VXLAN mode.
display switch-mode status
Switch-mode in use: VXLAN MODE.
Switch-mode for next reboot: VXLAN MODE.
#
# Display the supported device operating modes.
switch-mode ?
0 NORMAL MODE(default)
1 VXLAN MODE
2 802.1BR MODE
3 MPLS MODE
4 MPLS-IRF MODE
#
# Set the mode to VXLAN mode, and then restart the device for the configuration to take effect.
switch-mode 1
#
2. Configure the leaf role and system name:
# For the role configuration to take effect, you must reboot the device. Skip the role configuration if the default role of the device is leaf.
#vcf-fabric role leaf
#
# Configure the system name.
sysname leaf1
#
3. Configure LLDP to determine the topology.
#
lldp global enable
#
4. Configure the spanning tree feature.
#
stp ignored vlan 2 to 4094
stp global enable
#
5. On the leaf downlink interface, enable TC-BPDU transmission restriction.
int Ten-GigabitEthernet1/3/0/16
#
stp tc-restriction #
|
|
IMPORTANT: You must enable TC-BPDU transmission restriction on leaf downlink interfaces that are not connected to endpoints. If a leaf downlink interface is connected to an endpoint, you must configure the interface as a spanning tree edge port. |
6. Configure SNMP, NETCONF, Telnet, and SSH settings:
# Configure SNMP settings. The following configuration is the default configuration. You must configure the SNMP communities according to the actual network conditions.
snmp-agent
snmp-agent community write private
snmp-agent community read public
snmp-agent sys-info version all
snmp-agent packet max-size 4096
#
# Configure NETCONF settings.
#
netconf soap http enable
netconf soap https enable
netconf ssh server enable
restful https enable
#
# Configure Telnet settings.
telnet server enable
#
# Configure SSH settings.
ssh server enable
#
7. Configure the username and password used by Telnet or SSH:
# Set the username to admin and password to H3C1234567.
local-user admin class manage
password simple H3C1234567 //The password must meet the password complexity requirements. A qualified password must be a string of 10 to 63 characters that contain a minimum of two types of characters from digits, uppercase letters, lowercase letters, and special characters. The password cannot contain Chinese characters, question marks (?), spaces, or the username or reverse order of username characters.
service-type telnet http https ssh
authorization-attribute user-role network-admin
authorization-attribute user-role network-operator
#
#
line vty 0 63
authentication-mode scheme
user-role network-admin
user-role network-operator
#
8. Create VLAN 4094.
vlan 4094
#
9. Configure OSPF.
#
ospf 1 router-id 200.1.1.252
non-stop-routing
area 0.0.0.0
#
10. Configure Loopback 0.
#
interface LoopBack0
ip address 200.1.1.252 255.255.255.255 //Used to establish a BGP peer with the spine device.
ospf 1 area 0.0.0.0
#
11. Configure a VLAN interface for communicating with the spine node:
# Create a VLAN.
vlan 91 //The VLAN must be the same as that on the spine node.
#
# Create a VLAN interface.
interface Vlan-interface91
ip address 91.1.0.2 255.255.255.0
ospf network-type p2p
ospf 1 area 0.0.0.0
#
# Assign the leaf uplink interface to the VLAN.
#
interface Ten-GigabitEthernet1/2/0/13
port link-mode bridge
port link-type trunk
port trunk permit vlan 1 91
#
|
|
IMPORTANT: As a best practice, use VLANs 3 to 99, VLANs 4001 to 4050, and VLANs 4061 to 4089 for VLAN interfaces in route advertisement. The SeerEngine-Campus controller by default automatically deploys the following VLANs to devices: · VLAN 2—This VLAN is used for underlay route synchronization between two DR member devices in a DR system. · VLAN 100—This VLAN is used for BFD MAD on automatically configured IRF fabrics. · VLANs 101 to 2800—The VLANs are used by access switches. · VLANs 2801 to 3000—The VLANs are used by static ACs. · VLANs 3001 to 3500—The VLANs are used for automated device deployment on the links interconnected spine and leaf devices. · VLANs 3501 to 4000—The VLANs are used by security groups. · VLANs 4090 to 4094—The VLANs are reserved. VLANs 3 to 99 and VLANs 4001 to 4089 cannot be assigned automatically. VLANs 4051 to 4060 are used as authentication-free VLANs. When the spine and leaf nodes are connected through multiple links, the links are ECMP links. As VLAN 1 is enabled with the spanning tree feature, it is normal that the links between the spine and leaf nodes are in discarding state. |
12. Enable L2VPN.
l2vpn enable
#
13. For the connectivity of the control channel, perform the following tasks:
¡ Configure VPN instance vpn-default, VSI vxlan4094, and VSI interface IP address settings, and specify an L3 VXLAN ID.
¡ Configure an Ethernet service instance on the downlink AC interface (the interface connected to the access device), and map the Ethernet service instance to VSI vxlan4094.
# Create VPN instance vpn-default. Configure the RD and route targets manually. The RD and route targets are 1:1 in the whole network.
#
ip vpn-instance vpn-default
route-distinguisher 1:1
vpn-target 1:1 import-extcommunity
vpn-target 1:1 export-extcommunity
#
address-family ipv4
vpn-target 1:1 import-extcommunity
vpn-target 1:1 export-extcommunity
#
address-family evpn
vpn-target 1:1 import-extcommunity
vpn-target 1:1 export-extcommunity
#
# Configure the IP address of VSI-interface 4094.
#
interface Vsi-interface4094
ip binding vpn-instance vpn-default
ip address 130.1.0.3 255.255.255.0
local-proxy-arp enable
arp proxy-send enable //Enable ARP request proxy to resolve the issue that an endpoint cannot connect to a server if no server ARP entry exists on the device because of network connection timeout.
#
# Configure VSI interface and L3 VXLAN ID settings for Layer 3 forwarding. In this example, create VSI-interface 4092 and configure L3 VXLAN ID 4092 for VPN instance vpn-default. The ip address unnumbered command is used to configure an interface to borrow the IP address of the specified interface. When a security group is created in VPN instance vpn-default, specify the IP of VSI-interface 4094 as the source IP of Layer 3 outgoing packets.
#
interface Vsi-interface4092
ip binding vpn-instance vpn-default
ip address unnumbered interface Vsi-interface4094
l3-vni 4092
#
# Configure VSI vxlan4094.
#
vsi vxlan4094
gateway vsi-interface 4094
vxlan 4094
evpn encapsulation vxlan
mac-advertising disable
arp mac-learning disable
route-distinguisher auto
vpn-target auto export-extcommunity
vpn-target auto import-extcommunity
dhcp snooping trust tunnel
#
# Configure the leaf downlink interface connected to the access device as an AC interface.
interface Ten-GigabitEthernet1/2/0/9
port link-mode bridge
port link-type trunk
port trunk permit vlan 1 4094
stp tc-restriction
#
service-instance 4094
encapsulation s-vid 4094
xconnect vsi vxlan4094
#
14. Configure BGP EVPN:
# Configure BGP instance 100 and specify the spine device as a peer.
#
bgp 100
non-stop-routing
router-id 200.1.1.252 //The router ID of each device cannot be the same. Configure a loopback interface address as the router ID.
peer 200.1.1.254 as-number 100
peer 200.1.1.254 connect-interface LoopBack0
#
address-family l2vpn evpn
peer 200.1.1.254 enable
#
ip vpn-instance vpn-default
#
address-family ipv4 unicast
#
15. Configure static routes:
# When the connections between the spine device and servers are Layer 3 connections, you must configure static routes destined for the servers. The next hop of the static routes is the IP address of VLAN-interface 4094 on the Layer 3 switch.
ip route-static vpn-instance vpn-default 110.1.0.0 24 130.1.0.1 //The destination IP is the subnet IP of the controller.
#
ip route-static vpn-instance vpn-default 100.1.0.0 24 130.1.0.1 //The destination IP is the subnet IP of the server.
#
# If the DHCP server and spine device belong to different subnets, you must add a static route destined for the DHCP server.
ip route-static vpn-instance vpn-default 132.0.0.0 24 130.1.0.1 //DHCP server subnet IP.
#
16. Configure DHCP snooping.
#
dhcp snooping enable vlan 2 to 4094
#
17. Exclude IPv4 packets from VLAN 1 and VLAN 4094 from IPSG filtering.
# The configuration is required when IPSG is configured on the leaf downlink interface. If IPSG is not configured, the configuration in this step does not affect services.
ip verify source exclude vlan 1
ip verify source exclude vlan 4094
#
18. Disable remote-MAC entry learning and remote ARP learning on VXLAN tunnels:
# Disable remote ARP learning on VXLAN tunnels.
vxlan tunnel arp-learning disable
#
# Disable remote-MAC entry learning on VXLAN tunnels.
vxlan tunnel mac-learning disable
#
19. (Optional.) Enable conversational learning for forwarding entries. (By default, this feature is disabled. You can enable it as needed.)
If conversational learning for forwarding entries is enabled on the leaf device, you must import direct routes to BGP VPN instance vpn-default on the spine device, so as to import all private subnet routes of endpoints to the leaf and spine devices. This operation ensures reachability among the endpoints, servers, and external networks.
# To save hardware resources, the remote ARP entries synchronized through EVPN by fefault are not issued to the hardware immediately after the entries are received. Instead, the device issues the ARP entries to the hardware only when the entries are required for packet forwarding.
ip forwarding-conversational-learning //Enable conversational learning for host route FIB entries.
# Specify an aging timer for host route FIB entries. The default aging time is 60 minutes.
[leaf1]ip forwarding-conversational-learning aging ?
INTEGER<60-1440> Aging time in (minutes)
#
|
|
IMPORTANT: As a best practice, enable conversational learning for forwarding entries on the S5560X-HI and S6520X-HI switches. If a leaf device also atcs as a border device, do not enable conversational learning for forwarding entries as a best practice. |
20. Configure NTP.
#
clock timezone beijing add 08:00:00
#
# The IP address is the IP address of the NTP server.
ntp-service enable
ntp-service unicast-server 100.1.0.100 vpn-instance vpn-default
#
21. Verify the configuration.
[leaf1] display interface Vsi-interface brief
Brief information on interfaces in route mode:
Link: ADM - administratively down; Stby - standby
Protocol: (s) - spoofing
Interface Link Protocol Primary IP Description
Vsi4092 UP UP 130.1.0.3 //VSI-interface 4094 and VSI-interface 4092 are created successfully.
Vsi4094 UP UP 130.1.0.3
[leaf1]
[leaf1]dis l2vpn vsi
Total number of VSIs: 2, 1 up, 1 down, 0 admin down
VSI Name VSI Index MTU State
Auto_L3VNI4092_4092 0 1500 Down //Automatically generated.
vxlan4094 1 1500 Up
[leaf1]
[leaf1] display interface Tunnel brief
Brief information on interfaces in route mode:
Link: ADM - administratively down; Stby - standby
Protocol: (s) - spoofing
Interface Link Protocol Primary IP Description
Tun1 UP UP -- //The tunnel is up.
[leaf1]
[leaf1] display interface Tunnel
Tunnel1
Current state: UP
Line protocol state: UP
Description: Tunnel1 Interface
Bandwidth: 64 kbps
Maximum transmission unit: 1464
Internet protocol processing: Disabled
Last clearing of counters: Never
Tunnel source 200.1.1.252, destination 200.1.1.254
Tunnel protocol/transport UDP_VXLAN/IP
Last 300 seconds input rate: 0 bytes/sec, 0 bits/sec, 0 packets/sec
Last 300 seconds output rate: 0 bytes/sec, 0 bits/sec, 0 packets/sec
Input: 29 packets, 2064 bytes, 0 drops
Output: 8 packets, 720 bytes, 0 drops
[leaf1]
[leaf1]ping -vpn-instance vpn-default 100.1.0.100 //Ping the server successfully.
Ping 100.1.0.100 (100.1.0.100): 56 data bytes, press CTRL+C to break
56 bytes from 100.1.0.100: icmp_seq=0 ttl=63 time=3.646 ms
56 bytes from 100.1.0.100: icmp_seq=1 ttl=63 time=1.699 ms
56 bytes from 100.1.0.100: icmp_seq=2 ttl=63 time=2.058 ms
56 bytes from 100.1.0.100: icmp_seq=3 ttl=63 time=7.078 ms
56 bytes from 100.1.0.100: icmp_seq=4 ttl=63 time=1.680 ms
--- Ping statistics for 100.1.0.100 in VPN instance vpn-default ---
5 packet(s) transmitted, 5 packet(s) received, 0.0% packet loss
round-trip min/avg/max/std-dev = 1.483/1.620/1.991/0.189 ms
[leaf1]
22. Configure IRF bridge MAC persistence.
If the leaf is an IRF fabric, you must configure the IRF bridge MAC address to remain unchanged after a master/subordinate switchover.
#
irf mac-address persistent always
#
Configuring an access device
1. Configure the access role and system name:
# For the role configuration to take effect, you must reboot the device. Skip the role configuration if the default role of the device is access.
#
vcf-fabric role access
#
#
sysname access1
#
2. Configure LLDP to determine the topology.
#
lldp global enable
#
3. Configure the spanning tree feature.
#
stp global enable
#
4. Configure SNMP, NETCONF, Telnet, and SSH settings:
# Configure SNMP settings. The following configuration is the default configuration. You must configure the SNMP communities according to the actual network conditions.
#
snmp-agent
snmp-agent community write private
snmp-agent community read public
snmp-agent sys-info version all
snmp-agent packet max-size 4096
#
# Configure NETCONF settings.
netconf soap http enable
netconf soap https enable
netconf ssh server enable
restful https enable
#
# Configure Telnet settings.
telnet server enable
#
# Configure SSH settings.
ssh server enable
#
5. Configure the username and password used by Telnet or SSH:
# Set the username to admin and password to H3C1234567.
local-user admin class manage
password simple H3C1234567 //The password must meet the password complexity requirements. A qualified password must be a string of 10 to 63 characters that contain a minimum of two types of characters from digits, uppercase letters, lowercase letters, and special characters. The password cannot contain Chinese characters, question marks (?), spaces, or the username or reverse order of username characters.
service-type telnet http https ssh
authorization-attribute user-role network-admin
authorization-attribute user-role network-operator
#
#
line vty 0 63
authentication-mode scheme //Set to none if username and password are not used.
user-role network-admin
user-role network-operator
#
6. Assign the uplink interface that connects the access device to the leaf device to all VLANs.
interface Ten-GigabitEthernet1/0/52
port link-mode bridge
port link-type trunk
port trunk permit vlan all
#
7. Create VLANs.
#
vlan 4093 to 4094
#
8. (Optional.) Configure VLAN-interface 1.
# As a best practice, do not configure VLAN-interface 1 on the access device.
interface Vlan-interface1
ip address 120.1.0.4 255.255.255.0
#
9. Configure VLAN-interface 4094, through which SeerEngine-Campus can incorporate the access device.
#
interface Vlan-interface4094
ip address 130.1.0.4 255.255.255.0
#
10. Configure static routes.
# When the connections between the spine device and servers are Layer 3 connections, you must configure static routes destined for the servers. The next hop of the static routes is the IP address of VLAN-interface 4094 on the Layer 3 switch.
ip route-static 110.1.0.0 24 130.1.0.1 //The destination IP is the subnet IP of the controller.
ip route-static 100.1.0.0 24 130.1.0.1 //The destination IP is the subnet IP of the server.
11. Configure the NTP server.
#
clock timezone beijing add 08:00:00
#
# The IP address is the IP address of the NTP server.
ntp-service enable
ntp-service unicast-server 100.1.0.100
#
12. Configure interfaces connected to endpoints as spanning tree edge ports.
After the SeerEngine-Campus controller incorporates the access device, it automatically configures the interfaces connected to user endpoints on the access device as spanning tree edge ports, and assigns a VLAN ID to each of the interfaces. The controller automatically completes the configuration. No manual configuration is required. If the controller does not deliver the configuration, you can configure the configuration manually.
#
interface GigabitEthernet1/0/22
port access vlan 115
stp edged-port
#
13. Configure IRF bridge MAC persistence.
If the access is an IRF fabric, you must configure the IRF bridge MAC address to remain unchanged after a master/subordinate switchover.
#
irf mac-address persistent always
#
Configuring an aggregation device
An aggregation device connects spine and leaf devices. Its device role will not be evaluated when it is manually incorporated. Therefore, the device role does not need to be configured. To manually configure the aggregation device:
1. Configure the system name.
# The device role of the aggregation device will not be evaluated when it is manually incorporated. Therefore, the device role does not need to be configured.
#
sysname aggr1
#
2. Configure LLDP to determine the topology.
#
lldp global enable
#
3. Configure the spanning tree feature.
#
stp global enable
#
4. Configure SNMP, NETCONF, and SSH settings.
# Configure SNMP settings. The following configuration is the default configuration. You must configure the SNMP communities according to the actual network conditions.
#
snmp-agent
snmp-agent community write private
snmp-agent community read public
snmp-agent sys-info version all
snmp-agent packet max-size 4096
#
# Configure NETCONF settings.
netconf soap http enable
netconf soap https enable
netconf ssh server enable
restful https enable
#
# Configure SSH settings.
ssh server enable
#
5. Configure the username and password used by Telnet or SSH:
# Set the username to admin and password to H3C1234567.
local-user admin class manage
password simple H3C1234567 //The password must meet the password complexity requirements. A qualified password must be a string of 10 to 63 characters that contain a minimum of two types of characters from digits, uppercase letters, lowercase letters, and special characters. The password cannot contain Chinese characters, question marks (?), spaces, or the username or reverse order of username characters.
service-type http https ssh
authorization-attribute user-role network-admin
authorization-attribute user-role network-operator
#
#
line vty 0 63
authentication-mode scheme //Set to none if username and password are not used.
user-role network-admin
user-role network-operator
#
6. Configure OSPF.
#
ospf 1
non-stop-routing
area 0.0.0.0
#
7. Configure Loopback 0.
#
interface LoopBack0
ip address 200.1.1.200 255.255.255.0
ospf 1 area 0.0.0.0
#
8. Configure a VLAN interface for communicating with the spine node:
# Create a VLAN.
vlan 92 //Add the corresponding VLAN for the spine device and the VLAN is the same as the spine.
#
# Create a VLAN interface.
interface Vlan-interface92
ip address 91.2.0.2 255.255.255.0 //In the same subnet as the IP address of VLAN-interface 92 on the spine.
ospf network-type p2p
ospf 1 area 0.0.0.0
#
# Assign the aggregation uplink interface to the VLAN.
#
interface Ten-GigabitEthernet1/1/1
port link-mode bridge
port link-type trunk
port trunk permit vlan 1 92
#
9. Configure a VLAN interface for communicating with the leaf device:
# Create a VLAN.
vlan 93 //Add the corresponding VLAN for the leaf device and the VLAN is the same as the leaf.
# Create a VLAN interface.
interface Vlan-interface93
ip address 91.3.0.2 255.255.255.0 // In the same subnet as the IP address of VLAN-interface 92 on the leaf.
ospf network-type p2p
ospf 1 area 0.0.0.0
#
# Assign the aggregation uplink interface to the VLAN.
#
interface Ten-GigabitEthernet1/1/2
port link-mode bridge
port link-type trunk
port trunk permit vlan 1 93
#
10. Configure VLAN-interface 1. The controller incorporates the aggregation device through VLAN-interface 1. Make sure VLAN-interface 1 can reach the server that hosts the controller.
#
interface Vlan-interface1
ip address 120.1.0.20 255.255.255.0
#
11. Configure the NTP server.
#
clock timezone beijing add 08:00:00
#
# The IP address is the IP address of the NTP server.
ntp-service enable
ntp-service unicast-server 100.1.0.100
#
Configuring a fabric
1. Navigate to the Automation > Campus Network > Fabrics page, and click Add.
2. Configure a fabric on the Fabric Configuration page. Parameters are described as follows:
¡ Name: Enter a name for the fabric.
¡ AS Number: Enter an integer in the range of 1 to 4294967295. In manual incorporation mode, make sure the AS number set for the fabric is the same as the BGP AS number configured on the devices.
¡ Isolation Domain: Select an isolation domain for the fabric.
¡ Multicast Network: By default, the value is Off. You can enable it as required.
¡ QoS: By default, the value is Off. You can enable it as required.
¡ Lock Underlay: By default, the value is Off. You cannot modify this parameter when adding a fabric. Disable it during automated device deployment, and enable it as required after automated device deployment is completed.
¡ Delayed Access Interface PVID Assignment: By default, the value is Off and the controller will automatically assign PVIDs to interfaces on the device when the device is activated. If you select On, the controller will not assign PVIDs when the device is activated, and you can manually configure PVIDs after the device is activated.
¡ Virtual Auto Online And Business Follow: By default, the value is On. It is used to control authorization for the VXLAN network and access policies between security groups. Read the notice information carefully before operation.
3. Click OK. The added fabric is displayed on the Fabrics page. The system creates 11 general policy groups for each fabric.
Incorporating a device
You can manually add devices to the controller or configure the controller to automatically discover devices.
Manually adding devices
Navigate to the Guide > Add Device page, enter the device name, and configure parameters in the Basic Info and Control Protocol Template areas.
To add a spine or leaf device:
· In the Basic Information area:
¡ Host Fabric: The policy mode of the fabric must be IP based policy.
¡ Device Role: Select Spine, Leaf, Access, or Aggregation. Make sure the selected role is the same as that configured on the device. The aggregation role is used for aggregation network models. Compared with the original spine-leaf-access network model or spine-leaf network model, an aggregation network model adds aggregation Layer 3 switches between the spine and leaf devices. The aggregation Layer 3 switches do not need to support VXLAN or EVPN. For more information about the aggregation network models, see "Spine-aggregation-leaf-access or spine-aggregation-leaf network model." If you need to incorporate aggregation devices manually, contact H3C R&D.
¡ Management IP: Enter the IP address of VXLAN-interface 4094 (for spine and leaf devices) or VLAN-interface 4094 (for access devices).
¡ Underlay IP: Enter the IP address of the loopback interface on the device.
¡ Device Series: Select the product series corresponding to the device model.
¡ Control Protocol Template: Select the template that has the same settings as the device. Otherwise, the device cannot be activated.
¡ Other parameters: Use the default values.
After the device is added, the initial Device State is Inactivate because a period of time is needed for data synchronization. After the data is synchronized, click Refresh. If the Device State becomes Active, the device is successfully connected.
After the device is incorporated, you can use the display openflow instance 1 controller command to view detailed information about the devices connected to the SeerEngine-Campus controller.
[Leaf1]display openflow instance 1 controller
Instance 1 controller information:
Reconnect interval: 60 (s)
Echo interval : 5 (s)
Controller ID : 1
Controller IP address : 110.1.0.102
Controller port : 6633
Local IP address : 130.1.0.3
Local port : 20870
Controller role : Master
Connect type : TCP
Connect state : Established
Packets sent : 88
Packets received : 158
SSL policy : --
Control SSL policy : --
VRF name : vpn-default
Controller ID : 2
Controller IP address : 110.1.0.103
Controller port : 6633
Local IP address : 130.1.0.3
Local port : 20872
Controller role : Slave
Connect type : TCP
Connect state : Established
Packets sent : 84
Packets received : 154
SSL policy : --
Control SSL policy : --
VRF name : vpn-default
[Leaf1]
To add an access device:
For information about the device models that support the access role in the AD-campus solution, see "Hardware information."
· In the Basic Information area:
¡ Host Fabric: The policy mode of the fabric must be IP based policy.
¡ Device Role: Select access.
¡ Management IP: Enter the IP address of VLAN-interface 4094.
¡ Underlay IP: It is unnecessary to configure it for access devices.
¡ Device Series: Select the product series corresponding to the device model.
¡ Delayed Interface PVID Assignment: By default, the value is Off. The controller will automatically assign PVIDs to interfaces on the device when the device is activated. If you select On, the controller will not assign PVIDs when the device is activated, and you can manually configure PVIDs after the device is activated.
¡ Third-party Device: By default, the value is No. If your device is a third-party device, select Yes.
¡ Control Protocol Template: Select the template that has the same settings as the device. Otherwise, the device cannot be activated.
¡ Other parameters: Use the default values.
|
|
NOTE: Access devices are not incorporated through OpenFlow. You cannot view OpenFlow connection information on access devices. |
To add an aggregation device:
An aggregation device is an intermediate device between spine and leaf devices. Before incorporating an aggregation device, some basic configurations need to be configured. For information about the basic configuration of aggregation devices, see "Configuring an aggregation device."
For information about the basic configuration of leaf devices connected to the aggregation device, see "Configuring a leaf device."
On the Add Switching Device page, configure the following parameters:
· Device Role: Select aggregation. The controller does not check the role information of the device if you incorporate the aggregation device manually.
· Management IP: Enter the IP address of VLAN-interface 1.
· Underlay IP: Enter the IP address of the loopback interface on the device.
· Device Series: Select the device model of the device to be added.
· Control Protocol Template: You can either create a new template or use the default one.
After the aggregation device is incorporated successfully, the Device State is Active, and the Device Role is aggregation.
You can view the topology connection of the aggregation device by navigating to the Monitor > Topology > Campus Topo page.
Automatically discovering devices
Navigate to the Guide > Auto Find page.
Configure the IP address range and SNMP parameters, and then click Create Device Discovery Task to scan devices that are not incorporated. Then, the devices that are not incorporated appear in the Device List, as shown in the figure below:
If you configure both SNMP and NETCONF
parameters, the system discovers devices through NETCONF first. Select a device
in the Device List, and click the device incorporation icon 
to enter the Add Switching Device
page. For parameter configurations in this page, see "Manually adding devices."
Configuring a policy template
You can configure a policy template with the following two methods. This section introduces the configuration by taking the example of a campus wizard.
· Using the campus wizard—Navigate to the Guide > Campus Wizard > Device Onboarding Plan page, and in Step 5 Policy Template, configure a policy template.
· Not using the campus wizard—Navigate to the Automation > Campus Network > Device Groups > General Policy Groups page, and click Policy Template at the upper right corner of the page.
To configure a policy template:
1. On the General Policy Groups page, click Policy Template, as shown in the figure below.
2. On the Policy Template configuration page, the system has defined two default policies: interface_ipv4_binding and mac_migrating_enable, as shown in the figure below.
¡ interface_ipv4_binding: Apply this policy to the leaf interface group for port security. The ip verify source ip-address mac-address command will be deployed to an interface after this policy template is applied to the interface. As a best practice, do not use this policy in the current solution.
¡ mac_migrating_enable: Apply this policy to the leaf device group for MAC move. Configure this policy if users move on the same downlink interface of the same leaf device or move between different downlink interfaces of the same leaf device. That is, configure this policy if endpoints move between different interfaces or different VLANs on the same access device or move between different access devices. After the policy is configured, the port-security mac-move permit command will be deployed. It is required to use this policy in the current solution.
3. Click Add, and select Device Policy Template or Interface Policy Template from the drop-down list to add a policy template.
¡ Device Policy Template: A device policy template can be applied to a device group for AAA, 802.1X authentication, MAC authentication, and MAC move configuration.
¡ Interface Policy Template: An interface policy template can be applied to an interface group (mainly the leaf downlink interfaces) for 802.1X authentication and MAC authentication configuration.
The following section describes the configuration of a device policy template, interface policy template and user-defined policy template, and the method to view the policy templates.
Configuring a device policy template of the AAA type
1. Configure the following parameters:
¡ Template Name: Enter a unique name for the template.
¡ Template Type: Select AAA and then the configuration page for AAA appears.
¡ Auth Server Shared Key: Configure the key as required. The key information will be deployed to the device and synchronized to EIA for communication between the device and EIA. A key supports up to 64 characters and is case sensitive. Chinese characters, spaces, and special characters <>&? are not supported.
2. Configure RADIUS scheme settings:
Click Add in the Radius Scheme area, and then configure the following parameters:
¡ Primary Auth Server IP: Enter the IP address of the EIA server (either EIA V9 or EIA V7) for user authentication. For information about the parameters, see "Configuring AAA."
¡ Real-time Acct Interval (Minute): 15 by default.
¡ Carry ISP Domain Name: Select No by default.
- If it is set to No, it means that the username used in the RADIUS authentication packets does not carry the domain name. By default, the EIA does not carry the domain name suffix.
- If it is set to Yes, it means that the username in the RADIUS authentication packets carries the domain name, and the username must be followed by @domain name when the user comes online.
¡ Forcibly Stop Accounting When Clients Go Offline: If you select Yes, it means that the accounting stops immediately after the client goes offline. If you select No, it means that the accounting does not stop immediately after the client goes offline.
3. Configure ISP domain settings:
Click Add in the ISP Domain Settings area, and then configure the following parameters:
¡ Radius Scheme: Select a RADIUS scheme from the drop-down list. The name of the RADIUS scheme added in the preceding step is displayed here.
¡ Is A Default Domain: Select Yes.
¡ Is ONU Authentication: Select No.
|
|
IMPORTANT: Each AAA template must have one and only one default domain name. Multiple ISP domain names can be added. However, typically, you add one RADIUS scheme name and one ISP domain name. |
After the AAA template is configured, it is displayed as follows:
Configuring a device policy template of the 802.1X type
Configure the following parameters:
· Template Type: Select 802.1X.
· Authentication Method: Select an authentication method as needed. Options include EAP, CHAP, and PAP. As a best practice, select CHAP for wired authentication, and EAP for wireless authentication.
Configuring a device policy template of the MAC/MAC portal authentication type
Configure the following parameters:
· Template Type: Select MAC/MAC Portal Authentication.
· Portal Authentication: Select Yes to enable MAC portal authentication.
· Redirect to Port: Specify the listening port for HTTPS packet redirection. Do not specify a port used by well-known protocols, and make sure the port is not used by other services. If you do not specify a port, the default port number 6654 is used. You can execute the display tcp command to view the TCP port numbers that have been used.
· Authentication-Free IPs: You must specify the IP address of the EIA server as an authentication-free IP if portal authentication is enabled.
|
|
IMPORTANT: When the AAA template is configured with a primary and a secondary authentication server, you must configure the IP addresses of both the primary and secondary authentication servers as authentication-free IPs. |
Configuring an interface policy template of the 802.1X type
Configure the following parameters:
· Template Type: Select 802.1X.
· Enable The Escape Function: By default, the value is Yes. You can disable this feature as needed.
· Unicast Trigger: By default, the value is Yes. Use the default setting.
· Guest Access: By default, the value is No. For more information, see "Guest online or authentication failure online."
· Access on Authentication Failure: By default, the value is Yes. For more information, see "Guest online or authentication failure online." This feature and MAC portal authentication are mutually exclusive. If you need to configure MAC portal authentication, select No.
Configuring an interface policy template of the MAC/MAC portal authentication type
Configure the following parameters:
· Template Type: Select MAC/MAC Portal Authentication.
· ISP Domain: The domain name in the previous AAA configuration is displayed in the drop-down list. If no ISP domain name is selected, the global default domain name set in the AAA template is used.
· Enable The Escape Function: By default, the value is Yes. You can disable this feature as needed.
· Perform MAC Authentication in Parallel with 802.1X Authentication: Use the default setting.
· Include User IP Addresses in MAC Authentication Requests: By default, the value is No. If you set it to Yes, the system will deploy the mac-authentication carry user-ip command to interfaces. Enable this feature for interfaces connected to endpoints that use static IP addresses.
|
|
WARNING! Use the mac-authentication carry user-ip command only for By IP Range authentication and when Bind User IP authentication is configured in the access policy. In any other cases of user authentication, do not use this command. If an endpoint device needs to be configured with a static IP address for authentication, the controller delivers the static IP address to EIA by issuing ARP snooping settings. For more information about the restrictions of the mac-authentication carry user-ip command, see "Fast online based on IP address ranges." |
Configuring a user-defined policy template
Except for predefined templates, the system also supports user-defined device policy templates and interface policy templates. This section describes the configuration of a user-defined interface policy template.
Configure the following parameters:
· Template Type: Select User-Defined.
· Configuration Deployed When The Policy Is Added: Specify the commands to be deployed to the members in a group when the group is bound to the policy.
· Configuration Deployed When The Policy Is Removed: Specify the commands to be deployed to the members in a group when the group is unbound from the policy. This parameter must be configured. Otherwise, the configuration deployed cannot be removed when the policy is removed.
Viewing a policy template
After a policy template is configured, you
can click the 
icon in the Actions
column for the template to view its details, and click the 
icon to edit the template. Predefined
policy templates cannot be edited.
|
|
IMPORTANT: Configuring a policy template does not deploy any configuration to devices. To deploy the configuration to devices, you must apply the policy template to the group policies of general policy groups. |
After configuring policy templates, you must configure group policies in device groups. At present, in the AD-Campus solution, you only need to configure the group policies of the leaf device group and leaf downlink interface group.
Configuring the group policy settings of a device group
For the leaf device group, you can specify predefined device policy templates (including AAA, 802.1X authentication, MAC/MAC portal authentication, and MAC move with name mac_migrating_enable). You can also specify user-defined policy templates.
To configure the group policy settings of the leaf device group:
1. Click the Edit icon 
in
the Actions column for the device group named Leaf Device
Group in the device group list.
2. Click the Policy tab, and then click Add.
Port Isolation Device Group: By default, it is not selected.
3. Select a template type from the Available Policy Templates list, and then select a policy template from the Available AAA Policies list, and then click Add.
4. Repeat the previous step to add policy templates of the 802.1X, MAC/MAC Portal Authentication, and MAC Move types. Click OK to save the configuration.
Configuring the group policy settings of an interface group
You can apply policy templates (including 802.1X authentication, MAC/MAC portal authentication, and user-defined policy templates) to the leaf downlink interface group in the same way policy templates are applied to the leaf device group. Click OK to save the configuration.
|
|
Note: Configure 802.1X and MAC authentication on leaf downlink interfaces as needed. For example, if the endpoints use MAC authentication, you only need to apply the MAC/MAC portal authentication template to the interfaces. If the endpoints use 802.1X authentication, you must apply the 802.1X authentication policy template to the leaf downlink interface group. |
Configuring access networks
This section describes the configuration of access networks via campus wizard. Navigate to the Guide > Campus Wizard > Access Network Plan page. This page guides you to configure overlay settings, including the configuration of isolation domains, private networks, Layer 2 network domains, and security groups.
Configuring isolation domains
An isolation domain is used to isolate user networks. Each isolation domain has its own DHCP system, authentication system, and wireless AC.
An isolation domain can contain multiple fabrics, but a fabric can belong to only one isolation domain.
The following methods are available for configuring an isolation domain:
· Using the campus wizard—Navigate to the Guide > Campus Wizard > Access Network Plan page, and in Step 1 Isolation Domain, click the Isolation Domain tab to configure an isolation domain. In this section, this method is used.
· Not using the campus wizard—Navigate to the Automation > Campus Network > Isolation Domain > Isolation Domain page to configure an isolation domain.
By default, the system has an isolation domain named isolate_domain1 with the default policy mode of IP Based. You do not need to modify it. This section only introduces the isolation domain configuration in the single fabric scenario. For information about the interconnection configuration of isolation domains, see AD-Campus 6.2 Multi-Campus and Multi-Fabric Configuration Guide.
To configure an isolation domain:
1. Click the Edit icon 
in
the Actions column for that isolation domain, and configure the following parameters:
¡ DHCP Server: Specify a DHCP server for the isolation domain. DHCP servers include DHCPv4 servers and DHCPv6 servers. You can configure one as required.
- DHCPv4 servers support both tight coupling and loose coupling. In tight coupling mode, the security group address pool will be automatically deployed to the DHCP server. In loose coupling mode, the security group address pool will not be automatically deployed to the DHCP server. You must create the address pool manually on the DHCP server.
- DHCPv6 servers are required only for IPv6 services. For more information, see AD-Campus 6.2 IPv6 Service Configuration Guide.
¡ AAA Server: Specify an authentication server for users in the isolation domain.
¡ Policy Mode: By default, the value is IP Based.
¡ Add Fabric: Select fabrics for the isolation domain. Only fabrics that use the same policy mode as the isolation domain can be selected.
¡ Add Fabric Connection: It is applicable to multi-fabric networking. Different fabrics establish EBGP connections with each other. This parameter is not required in a single-fabric network.
¡ DNS: Specify the IP address of the DNS server for the isolation domain.
Configuring private networks
Creating a private network
The following methods are available for configuring a private network:
· Using the campus wizard—Navigate to the Guide > Campus Wizard > Access Network Plan page, and in Step 2 Private Network, click the Private Network tab to configure a private network. In this section, this method is used.
· Not using the campus wizard—Navigate to the Automation > Campus Network > Private Network > Private Network page to configure a private network.
To configure a private network:
1. After the configuration of the isolation domain is completed, click Next to access the private network configuration page. Click Add to enter the Add Private Network page.
2. On the Add Private Network page, configure the following parameters and then click OK to save the configuration:
¡ Share VRF: By default, the value is No. If the value is Yes, the private network can be used only when a shared gateway is created and an IT resource group used by a shared gateway is created.
¡ VXLAN ID: The L3VNI ID associated with the VPN instance. By default, the value is Auto.
¡ Default Action: The following options are supported:
- Permit: All users in the private network can access each other.
- Deny: No users in the private network can access each other.
¡ Multicast Network: Select No. You can enable it as required.
¡ Policy Mode: Select IP Based.
|
|
IMPORTANT: A private network and an isolation domain are bound to each other through a Layer 2 network domain. If a private network is not bound to an isolation domain, the configuration of the private network will not be deployed to devices in the isolation domain. |
Creating a Layer 2 network domain
The following methods are available for configuring a Layer 2 network domain:
· Using the campus wizard—Navigate to the Guide > Campus Wizard > Access Network Plan page, and in Step 2 Private Network, click the Layer 2 Network Domain tab to configure a Layer 2 network domain. In this section. This method is used.
· Not using the campus wizard—Navigate to the Automation > Campus Network > Private Network > Layer 2 Network Domain page to configure a Layer 2 network domain.
To configure a Layer 2 network domain:
1. After creating the private network, click the Layer 2 Network Domain tab to open the Layer 2 network domain configuration page.
2. Click Add. On the page that opens, configure the following parameters:
¡ Isolation Domain: Select the isolation domain where the private network is located.
¡ Private Network: Select the created private network. After the Layer 2 network domain is created, the configuration of the private network will be deployed to the devices in the specified isolation domain.
¡ Type:
- Normal: Select Normal for user services.
- Escape: Select Escape when configuring the escape service.
- Guest: Select Guest when configuring the guest service. For more information, see "Guest online or authentication failure online."
- Authentication Failure: This type is used in authentication failure-free scenarios. For more information, see "Guest online or authentication failure online."
¡ Security Group Associations: Only One can be selected under the IP-based policy, which means that a Layer 2 network domain can only be assigned to one security group.
¡ VXLAN ID: Configure the VXLAN ID of the Layer 2 network domain. By default, it is set to Auto, which means that the system automatically assigns the VXLAN ID. You can also set it to Manual and configure the VXLAN ID manually.
¡ VSI MAC: The default value is 0000-0000-0001. You can modify this parameter as required. Keep default settings for other parameters.
¡ IPv4 Address Allocation: Dynamic means that users obtain IP addresses from the DHCP server. Manual means that no DHCP address pool is configured and you need to manually configure static IP addresses for coming online.
|
|
IMPORTANT: When the IPv4 Address Allocation parameter is set to Dynamic and some user endpoints that use static IP addresses need to be authenticated for coming online, you must add the static IP addresses of the endpoints to the Network Parameters > DHCP Server > Prohibited IP Address Allocation page. |
¡ IPv6 Address Allocation: Options include Manual, SLACC, Stateful DHCPv6, and Stateless DHCPv6. For more information about IPv6 service configuration, see AD-Campus 6.2 IPv6 Service Configuration Guide.
¡ IPv4 Address Lease Duration: Configure the default lease duration for IPv4 addresses.
3. On the Subnets tab, click Add to open the Add Subnet page. Configure the parameters and select IPv4 for IP Version, and then click OK to save the configuration. For more information about IPv6 service configuration, see AD-Campus 6.2 IPv6 Service Configuration Guide.
The Secondary parameter on this page has the following options:
¡ No: If you select No, the subnet will be used as a primary network. If the IPv4 address allocation mode is dynamic, the system will create an address pool on the DHCP server based on the subnet address for user address allocation.
¡ Yes: If you select Yes, the subnet will be used as a secondary network. The system will not create an address pool on the DHCP server based on the subnet address. It is applicable when endpoints use static IP addresses. Before creating a secondary network, make sure a primary network has been created. In addition, the Bind User IP function cannot be used in the access policy when a secondary network is used.
|
|
WARNING! · A security group can have only one primary network and multiple secondary networks. Plan the IP addresses based on the actual network conditions. Different security groups require different IP address ranges. · Before creating a secondary network, make sure a primary network has been created. · The Bind User IP function cannot be used in the access policy when a secondary network is used. · A secondary network cannot overlap with the primary network. This feature is mainly used to keep the addresses of the endpoints (the printers) unchanged in the old network transformation scenario, to assign the segments of multiple endpoints into one security group, and to save ACL resources. |
For the DNS configuration in the Add Subnet page, you need to specify the DNS server IP address for the Layer 2 network domain.
4. Click OK to save the settings and return to the Add Layer 2 Network Domain page. Click the Advanced tab to configure the parameters as needed. In this example, the default settings are used.
¡ ARP Proxy: By default, the value is On, which means that ARP proxy is enabled.
¡ ARP Packet Validity Check: By default, the value is Off. This parameter is applicable to access devices. With this feature, access devices detect and discard the ARP packets of unauthorized users, preventing attacks from illegal users and gateways. If the IPv4 address allocation mode is Manual, this feature cannot be enabled.
¡ ARP Snooping: ARP snooping entries are set by listening to ARP packets to provide fast ARP responses. Select On if broadband IoT endpoints are not allowed to go offline.
¡ Allow Layer 2 Application: By default, the value is Off. If you select Yes, it means that the created security group supports Layer 2 application and Layer 2 interconnection within the security group is allowed.
¡ ARP Scan and Probe: By default, the value is Off. If the value is Yes, ARP broadcasts are not flooded to the entire network, ARP learning relies on local scanning of leaf devices, table entries are synchronized through EVPN, and switches do not forward ARP packets.
¡ IPv6 ND Detection: This feature is used to verify the legitimacy of users.
¡ IPv6 ND Snooping: The device creates ND snooping entries by listening to ND or data packets. If there is no IPv6 service, do not enable this parameter.
¡ ND Scan and Probe: By default, the value is Off. If the value is Yes, ND broadcasts are not flooded to the entire network, ND learning relies on local scanning of leaf devices, table entries are synchronized through EVPN, and switches do not forward ND packets.
¡ DHCPv6 Snooping: By default, the value is Off. Enable this feature to ensure that clients obtain IPv6 addresses or IPv6 prefixes from valid servers and record the mappings between IPv6 addresses/IPv6 prefixes and MAC addresses.
¡ DHCPv6 Relay Agent Support for Option 79: By default, the value is On. Enable this feature to ensure that the DHCPv6 server can obtain the MAC addresses of clients.
|
|
WARNING! · After you enable the Allow Layer 2 Application feature, the security group allows broadcast, unknown multicast, and unknown unicast packets to be forwarded to AC and tunnel interfaces and allows VXLAN MAC synchronization through EVPN. That is, the SeerEngine-Campus controller will not deploy the flooding disable all all-direction or mac-advertising disable command to devices when it deploys VSI settings to the devices. · After you enable the Allow Layer 2 Application feature, you must configure broadcast suppression on leaf downlink interfaces. The threshold is determined by the device model and packet quantity. For more information, contact the product R&D. |
When the Allow Layer 2 Application feature is enabled, flood suppression can be deployed to physical interfaces and cannot be deployed to aggregate interfaces. If the leaf downlink interfaces are aggregate interfaces, configure flood suppression as follows:
a. Configure a user-defined policy template.
Navigate to the Automation > Campus Network > Devices > General Device Groups page, and click Policy Templates. Click Add, and select Interface Policy Template from the drop-down list. Select User-Defined for Template Type and add the following commands to the corresponding text box:
Configuration deployed when the policy is added:
#
broadcast-suppression pps 100 //The threshold is determined by the device model and packet quantity. For more information, contact the product R&D.
multicast-suppression pps 100
unicast-suppression pps 100
#
Configuration deployed when the policy is removed:
#
undo broadcast-suppression
undo multicast-suppression
undo unicast-suppression
#
b. Configure a user-defined interface group.
Navigate to the Automation > Campus Network > Devices > General Device Groups page and click Add. Select Interface Group for Group Type, and Layer 2 Physical Interface Group for Subtype, as shown in the figure below.
On the Member tab, click Add to open the Add Interface page. Select the member interfaces of the leaf downlink aggregate interfaces that need to be configured with flood suppression, and then click Add. The selected interfaces are displayed in the interface list, as shown in the figure below.
After selecting the member interfaces, click OK to return to the Add General Policy Group page. Click the Policy tab, and then click Add to open the Add Interface Group Policy page. Add the user-defined flood suppression policy configured in the previous step and click OK after the configuration is completed.
Then, you can view the flood suppression related settings deployed to the member interfaces:
#
interface Ten-GigabitEthernet1/0/8
port link-mode bridge
port link-type trunk
port trunk permit vlan 1 101 to 3000 4094
broadcast-suppression pps 100
multicast-suppression pps 100
unicast-suppression pps 100
port link-aggregation group 1024
#
|
|
WARNING! On the Layer 2 network domain, VSI MAC, VXLAN ID, and parameters on the Advanced tab, including ARP Proxy, ARP Packet Validity Check, Allow Layer 2 Application, IPv6 ND Detection, cannot be edited once they are deployed. Therefore, before configuration, decide which features need to be enabled. |
Configuring security groups
The following methods are available for configuring a security group:
· Using the campus wizard—Navigate to the Guide > Campus Wizard > Access Network Plan page, and in Step 3 Security Group, click the User Security Group tab to configure a security group. In this section, this method is used.
· Not using the campus wizard—Navigate to the Automation > Campus Network > Security Group > User Security Group page to configure a security group.
To configure a security group:
1. After creating the private network, click Next to open the Add Security Group configuration page. Click User Security Group tab, and click Add. Enter a name for the security group, select a private network, and select Normal for the Type parameter.
The following security group types are supported:
¡ BYOD: A BYOD security group is used for MAC portal authentication. Before MAC authentication, a user will join the BYOD security group. Only one BYOD security group can be created on the User Security Group tab, and it must belong to private network vpn-default.
¡ Normal: A normal security group is used for user services. All basic services use normal security groups.
¡ Critical: An escape security group is used for escape services. When the EIA server fails, users can still come online and access the resources in a critical security group. Only one critical security group can be configured in an isolation domain.
¡ External Network: An external network security group is used for south-north service chains. For more information, see AD-Campus 6.2 Service Chain Configuration Guide.
¡ Guest: The guest security group is used for users to access certain resources without authentication. Usually, the group contains some servers where users download client software or other upgrade programs.
¡ Authentication Failure: The authentication failure security group is used for users to access certain resources in authentication failure scenarios. Authentication failure here means the server rejects user authentication due to certain reasons such as user password error rather than authentication timeout or network disconnection.
VLAN ID: The VLAN ID for the security group. You need to select an allocation method. If you select Manual, you must manually specify a VLAN ID.
2. Click Add on the Layer 2 Network
Domain Information tab to add a Layer 2 network domain. Select the Layer 2
network domain in the Available Layer 2 Network Domain field, and click
the 
icon to add it to the Selected Layer 2 Network Domain list.
Click OK and return to the Add Security Group page.
3. Click OK and you can view the added security group on the User Security Group page, as shown in the figure below.
Configuring network policies
The following methods are available for configuring a network policy:
· Using the campus wizard—Navigate to the Guide > Campus Wizard > Access Network Plan page, and in Step 4 Network Strategy, configure a network policy. In this section, this method is used.
· Not using the campus wizard—Navigate to the Automation > Campus Network > Network Policy page to configure a network policy.
The Group Policies page allows you to configure the access relationships between user security groups and between a user security group and a resource group by dragging the group policy templates to the matrix, which simplifies the configuration.
For example, to isolate the teacher security group and student security group, you can drag the Deny All policy template to the corresponding locations in the matrix, and then click OK.
Configuring a time range (optional)
Click the Time Ranges tab. You can configure a time range as needed.
Click Add and configure the
parameters on the Add Time Range page. After completing the
configuration, click the 
icon to save the
parameter configuration, and click OK to save the time range.
Configuring a policy template
1. Click the Policy Templates tab. The system provides predefined templates Permit All and Deny All.
2. Click Add. Enter a name for the policy template, and select Internal Network Policy for the Template Type parameter.
¡ Internal Network Policy: Select Internal Network Policy for group policies and east-west service chains.
¡ External Network Policy: Select External Network Policy for south-north service chains.
3. Click Add Rule to open the Add Rule page. Configure the following parameters and then click OK:
¡ Protocol Type: Options are IP, UDP, TCP, and ICMP.
¡ Time Range: By default, it is none, indicating that all time ranges are valid.
¡ Action: Options are Permit, Deny and Redirect. Select Permit or Deny for a group policy and Redirect for service chains.
4. After adding the policy template, click OK to save the template.
Configuring the default access policy
Click the Group Policies tab. In the drop-down list of the Default Policy field in the Access Policies area, you can set access permissions for users in the selected private network. When the group policy is configured, you must select a private network first and then set the default policy.
The Default Policy set on the Group Policies page is the same as the Default Group Policy set on the private network page. You can select one of the pages to set the group policy.
· Permit: All users in the private network can access each other.
· Deny: All users in the private network cannot access each other, security groups in the same private network cannot access each other, and different users in the same security group cannot access each other.
If you select Deny, the SeerEngine-Campus controller deploys the global deny PBR to the spine and leaf devices and deploys a permit IP policy to the L3VNI interfaces in the private network.
# Configure permit IP settings on the L3VNI interfaces in the private network on spine and leaf devices.
#
acl advanced name SDN_ACL_SC_PERMIT_ALL
description SDN_ACL_SC_PERMIT_ALL
rule 0 permit ip
#
#
policy-based-route SDN_GLOBAL_SC2 permit node 0
if-match acl name SDN_ACL_SC_PERMIT_ALL
#
#
interface Vsi-interface2 //L3VNI interface.//
description SDN_VRF_VSI_Interface_2
ip binding vpn-instance Teach
ip policy-based-route SDN_GLOBAL_SC2
l3-vni 2
#
# Deploy the global deny action to spine and leaf devices.
#
acl advanced name SDN_ACL_GLOBAL_SC_6ee86fb4-6139-4db6-8eee-b114ad328cc1
description SDN_ACL_GLOBAL_SC_6ee86fb4-6139-4db6-8eee-b114ad328cc1
rule 0 permit ip destination 20.0.0.0 0.0.255.255
rule 1 permit ip destination 30.0.0.0 0 0.0.255.255
#
#
policy-based-route SDN_GLOBAL_SC permit node 0
if-match acl name SDN_ACL_GLOBAL_SC_6ee86fb4-6139-4db6-8eee-b114ad328cc1
apply output-interface NULL0
#
#
ip global policy-based-route SDN_GLOBAL_SC //Globally deliver.//
#
Configuring a group policy
1. Click the Group Policies tab. Select the private network first and the matrix appears, as shown in the figure below.
2. Select an access policy on the right and drag it to the corresponding location to open the Policy Direction dialog box. Select an option as needed, and then click OK. Policy Direction has the following options:
¡ Unidirectional: Configure an access policy from source security group to destination security group.
¡ Bidirectional: Configure an access policy from source security group to destination security group and from destination security group to source security group.
3. In this example, configure Deny All with the source security group as Student Security Group and the destination security group as Teacher Group, as shown in the figure below. After the group policy is configured, click OK in the upper left corner to save the configuration.
4. The controller deploys PBR policies to spine and leaf devices. The commands are shown as follows:
#
acl advanced name SDN_ACL_SC_000002_4_3
description SDN_ACL_SC_000002_4_3
rule 0 permit ip destination 20.0.0.0 0.0.255.255
#
#
policy-based-route SDN_SC_4 permit node 0
if-match acl name SDN_ACL_SC_000002_4_3
apply output-interface NULL0
#
#
interface Vsi-interface4 //L2VNI interface corresponding to the student security group.//
description SDN_VSI_Interface_4
ip binding vpn-instance Teach
ip address 30.0.0.1 255.255.0.0
mac-address 0000-0000-0001
local-proxy-arp enable
ip policy-based-route SDN_SC_4
local-proxy-nd enable
distributed-gateway local
#
Configuring exception rules
You can configure exception rules to exclude specific traffic from the control of group policies.
1. Move the mouse to a location in the matrix, and click + to open the Edit Group Policy page.
2. If an access policy already exists in the location, click the 
icon to open the Edit Group Policy page.
3. Click Add on the Exceptions tab, configure the Protocol Type, Source Subnet, Destination Subnet, and Action fields, and then click OK.
4. The exception rule will be displayed on the Group Policies tab.
To view the deployed configuration on leaf devices:
[leaf]display ip policy-based-route
Policy name: SDN_SC_3
node 0 permit:
if-match acl name SDN_ACL_SC_100005_3_4
[leaf]acl name SDN_ACL_SC_100005_3_4
[leaf-acl-ipv4-adv-SDN_ACL_SC_100005_3_4]dis th
#
acl advanced name SDN_ACL_SC_100005_3_4
description SDN_ACL_SC_100005_3_4
rule 0 permit ip source 20.0.0.0 0.0.0.255 destination 50.0.0.0 0.0.0.255
#
return
[leaf10510-acl-ipv4-adv-SDN_ACL_SC_100005_3_4]
User onboarding
User Onboarding Plan guides you to configure the EIA server, including the configuration of user access policies, user access services, and access users. After the configuration of user access services, users can come online by passing access authentication.
Configuring access policies
The following methods are available for configuring an access policy:
· Using the campus wizard—Navigate to the Guide > Campus Wizard > User Onboarding Plan page, and in Step 1 Access Policy, configure an access policy. In this section, this method is used.
· Not using the campus wizard—Navigate to the Automation > User > Access Service > Access Policy page to configure an access policy.
To configure an access policy:
1. Click Add to open the access policy configuration page.
2. Configure the following parameters:
¡ Basic Information: Enter a name for the access policy and use the default user group setting (Ungrouped). To add a user group, navigate to the Automation > User > Access User page, click User Group, and then add the user group.
¡ Authorization Information: Typically, use the default values.
Pay attention to the configuration of the following parameters:
- Allocate IP: Select whether to allocate IP addresses to users. Select No for campus networks.
- Offline Check Period (Hours): Configure this parameter to prevent a switch from logging off dumb endpoints such as printers that do not send packets actively when the switch does not detect any packets from the endpoints within the offline detection period. The default offline detection period for MAC authentication on the switch is 5 minutes. The switch will log off an endpoint if it does not detect any packets from the endpoint within the offline detection period. Configure the offline check period together with ARP snooping to ensure that endpoints that pass the authentication will not be logged off. This parameter is an integer with a range of 0 to 596523. When it is set to 0, the endpoint never goes offline. When it is set to empty, the offline check period is 5 minutes.
Methods for handling inconsistent endpoint information:
- Log Conflict and Continue Authentication: When users use the same MAC address but different endpoints to come online, record logs and allow users to pass the authentication and come online.
- Reject Authentication: When users use the same MAC address but different endpoints to come online, deny the users' online requests.
- Deploy Blackhole MAC: It is used to prevent a counterfeiting MAC address. When users use the same MAC address but different endpoints to come online, prohibit the users' online requests and issue the MAC address to the silent MAC address list of MAC authentication.
If you set the offline check period to 1 hour, the following configuration will be deployed to a device:
<leaf-1>display mac-authentication connection
Total connections: 1
Chassis ID: 1
Slot ID: 4
User MAC address: 0000-0000-0010
Access interface: Ten-GigabitEthernet1/4/0/2
Username: 000000000010
User access state: Successful
Authentication domain: hz1
IPv4 address: 20.0.0.2
Initial VLAN: 149
Authorization untagged VLAN: N/A
Authorization tagged VLAN: N/A
Authorization VSI: vsi4
Authorization ACL ID: N/A
Authorization user profile: N/A
Authorization CAR: N/A
Authorization URL: N/A
Termination action: Default
Session timeout period: 86400 sec
Offline detection: 3600 sec (server-assigned) //Deployed offline check period.
Online from: 2019/06/03 10:56:15
Online duration: 0h 0m 5s
¡ Authentication Binding Information:
Pay attention to the following parameters:
- Bind User IP: Select this option to bind an online endpoint to its static IP address. If you select it, the endpoint device will record the bound static IP address to the user detailed information after the device comes online.
- Bind Dynamically Assigned IP: Select this option when the endpoint obtains IP address via the DHCP server. Select this option to bind the MAC address, DHCP-assigned IP address, and account information of an endpoint when the endpoint comes online for the first time. Then, the endpoint can obtain the same IP address every time it comes online.
|
|
WARNING! The Bind User IP and Bind Dynamically Assigned IP parameters cannot be selected at the same time. |
¡ User Client Configuration: Use the default settings.
3. After setting the parameters, click OK to save the configuration. The access policy will be displayed in the list.
To add more access policies, click Add and repeat the above steps.
4. After configuring the access policies, click Next to configure the access services.
Configuring access services
The following methods are available for configuring an access service:
· Using the campus wizard—Navigate to the Guide > Campus Wizard > User Onboarding Plan page, and in Step 2 Access Service, configure an access service. In this section, this method is used.
· Not using the campus wizard—Navigate to the Automation > User > Access Service > Access Service page to configure an access service.
To configure an access service:
1. Click Add to open the access service configuration page.
2. Configure the following parameters:
Enter a name for the service, select a default access policy and security group, use default settings for other parameters, and then click OK to save the configuration.
¡ Basic Information:
Descriptions for parameters:
- Default Access Policy: By default, it is Access Forbidden, which indicates that all users cannot come online. To allow users to come online, you must configure a default access policy. You can click Add to add new default access policies.
- Security Group: This parameter must be configured. Security groups created in "Configuring access networks" will be displayed in the drop-down list.
- Sub Security Group: In IP based policy mode, use the default do not use setting.
- MAC Portal Authentication/Transparent Authentication: By default, the two options are selected. To allow users that use MAC portal authentication to come online, you must select the MAC Portal Authentication option. The Transparent Authentication option is optional. To open the redirection page for a user only when the user comes online for the first time, select the Transparent Authentication option. To open the redirection page for a user every time it comes online, do not select the Transparent Authentication option.
¡ Access Scenario List: Configure access scenarios as needed. For more information, see "Managing access scenarios (optional)."
3. After configuring the access service, you can view the added access service.
To add more access services, click Add and repeat the above steps.
4. After configuring the access services, click Next to configure access users.
Managing access users
The following methods are available for configuring an access user:
· Using the campus wizard—Navigate to the Guide > Campus Wizard > User Onboarding Plan page, and in Step 3 Access User, configure an access user. In this section, this method is used.
· Not using the campus wizard—Navigate to the Automation > User > Access User page to configure an access user.
You can manually add access users or import users. After access users are configured, all settings required on the authentication server are completed. You can perform user authentication after automated device deployment.
Manually adding users
1. Click Add and then configure the following parameters:
¡ Basic Information: Specify the User Name and Identity Number. For other parameters, you can use the default values.
¡ Access Information: Enter the account name and password. For other parameters, you can use the default values.
- Max. Idle Time: By default, it is empty, which indicates the session never times out.
- Max. Concurrent Logins: The default value is 1. The maximum value is 255. This parameter specifies the number of endpoints that use the same account for login. For more information, see "Setting the maximum number of online endpoints supported by an account."
For higher security of user passwords, select Enable Password Strategy and Modify Password at Next Login. After selecting these options, the user must change the password every time the user logs in.
|
|
WARNING! The Modify Password at Next Login is a one-time option. If a user changes the password and logs in to the system successfully, this option is cleared automatically. |
As shown in the figure below, if you select Modify Password at Next Login, a user will enter the page for editing the password. After the password is edited successfully, the user must use the new password to log in to the system.
¡ Access Service: Each access user must be bound to an access service. After passing authentication, a user can access the network resources in the security group in the access service.
¡ EndpointBinding Information: By default, all fields are empty. You can use the default setting.
You can manually enter binding information. If you enter multiple values in a field, use carriage returns to separate the values.
The system can also fill in binding information automatically based on the access service and access policy configuration.
|
|
WARNING! The IP address set in the EndpointBinding Information area should be used with Bind User IP in "Configuring access policies." If you do not select Bind User IP, the IP address specified in the EndpointBinding Information area will not take effect. |
2. Click OK. On the Access User tab, you can view the successfully created users.
Importing users in bulk
1. On the Access User tab, click Batch Import, and then click the Account Import File Template link to download a template. You can use the TAB key or other separators such as commas (,) to separate columns.
In this example, the columns are separated by commas (,), as shown in the figure below.
2. Click Upload, select a file, select a separator, and select Normal for Imported User State, as shown in the figure below.
3. Click Next.
¡ In the Basic Information area, set user information and identity number.
¡ Select a user group as required. The default value is Ungrouped.
¡ In the Access Information area, set the Account Name and Password. The password can be selected from the file or you can directly enter the password. If you directly enter the password, all users use the same password.
¡ Select an access service in the Access Service area, which is a required operation.
4. Click OK to import users in bulk.
5. After users are successfully imported, you can view the imported users on the Access User page.
Managing access scenarios (optional)
1. To add an access scenario, navigate to the Automation > User > Access Service page.
¡ Click Add to open the Add Access Scenario page. Click Add in the Access Scenario List area and add the access scenario here.
¡ Click
the Modify icon 
corresponding to a service name. Click Add in the Access
Scenario List area and add the access scenario here.
If access scenarios are configured, when a user comes online, the system matches the user with the configured access scenarios and assigns the user to the security group specified in the matched scenario. If no match is found for the user, the system assigns the user to the security group specified in the default access policy.
2. On the Access Scenario configuration page, configure 5W1H, as shown in the figure below.
The access conditions based on Who, Whose, What, When, Where and How (5W1H) cover multiple scenarios. You can customize scenarios as required to meet individual demands.
For example, you can click Add for the Access Location Group (where, how) parameter to configure an access location group. You can select the access location of the switch (Where).
3. On the Add Access Location Group page, select access devices or access interfaces. Then, click OK to save the configuration and return to the access scenario configuration page.
Descriptions of the configuration of access devices or access interfaces:
¡ Access device: You can select leaf devices, access devices, or cascaded access devices. When you select a leaf device, you can select whether to include its cascaded access devices.
¡ Access interface: You can select specific interfaces on leaf and access devices. If you select a device as an access device, you cannot select interfaces on the device as access interfaces, and vice versa.
4. On the access scenario configuration page, configure the access policy parameters, and then click OK to finish the access scenario configuration. Then, the configured access scenario will be displayed in the Access Scenario List.
Setting the maximum number of online endpoints supported by an account
The Max. Concurrent Logins parameter is used to limit the number of online endpoints for a single account. To configure this parameter, navigate to the Automation > User > Access User > All Access Users page. As shown in the figure below, account a01 can allow for the login of three endpoints at the same time.
You can also navigate to the Automation > User > Access
Parameters > System Settings page to configure the Log Off
Duplicate Account parameter to control the maximum number of online
endpoints supported by an account. Click the 
icon
and enter the configuration page as follows.
The Log Off Duplicate Account parameter can be enabled and disabled. It is set to Enable by default and takes effect only when the value for the Max. Concurrent Logins parameter is 1.
· If you set the Log Off Duplicate Account parameter to Enable:
¡ When the Max. Concurrent Logins parameter is set to 1, the current endpoint will be forcibly logged off when a new endpoint uses the account to come online.
¡ When the Max. Concurrent Logins parameter is set to be greater than 1, the current endpoint will not be forcibly logged off when a new endpoint uses the account to come online.
· If you set the Log Off Duplicate Account parameter to Disable:
When the Max. Concurrent Logins parameter is set to 1, no endpoints can use the account to come online until the current endpoint logs off.
Managing online users
1. Navigate to the Monitor > Monitor List > Online User > Local page and all online users are displayed in the list. You can click the corresponding buttons to manage the online users, including sending messages, forcibly logging out, clearing online information, reauthenticating, customizing page, bulk exporting, viewing detailed information, collecting logs, and configuring blacklists.
2. You can click Custom Page to customize the information to display on the online user list.
Click Custom Page. To display a
field in the online user list, select the field in the Option List, and
then click the 
button. To hide a field in the online user list, select the field
in the Output List, and then click the 
button.
User authentication and access
Before passing the authentication to come online, you must complete the basic configuration as described in "Configuring AD-Campus." The configuration includes the following categories:
· Device policy templates (including AAA, MAC authentication, 802.1X authentication, and MAC move templates).
· Interface group templates (including MAC authentication and 802.1X authentication templates).
· Assignment of devices to the leaf device group and assignment of interfaces to the leaf downlink interface group.
· Configuration for private networks, Layer 2 network domains, security groups, access policies, and access users.
Configuring 802.1X authentication
Installing certificates
|
|
NOTE: · If you use the H3C iNode client to initiate 802.1X authentication, no certificate is required. · If you do not use the H3C iNode client, you need to install a certificate on the EIA authentication server. The certificate ensures that the non-H3C 802.1X client (for example, the Windows built-in 802.1X client and the mobile phone Wi-Fi client) can be authenticated successfully. |
1. To import the H3C built-in certificate, navigate to the Automation > User > Service Parameters > Access Parameters page, and click Import Built-in Certificates, as shown in the figure below.
2. After importing the built-in certificates, the non-H3C iNode client can be used to initiate 802.1X authentication successfully.
3. To import a certificate provided by a customer:
¡ Click Import EAP Root Certificate on the Root Certificate tab.
¡ Click Import EAP Server Certificate on the Server Certificate tab.
User authentication
iNode client
After finishing the above configuration, you can perform authentication for coming online via the iNode client.
1. Start up the iNode client and enter a username and password created or imported on the Access User page.
2. Configure the Properties parameter. Click the inverted triangle next to Connect, and then click Properties. In the Properties dialog box, configure the following parameters:
¡ Select Unicast or Multicast as the packet type to trigger authentication.
¡ Select Upload IPv4 address if the client uses a static IP address.
3. Click Connect and verify that the user can connect to the network on the endpoint PC. You can also view the online user information on the Monitor > Monitor List > User > Online Users page.
Non-H3C iNode client
1. Set the authentication method to EAP in the 802.1X device policy template. For details, see "Configuring a device policy template of the 802.1X type."
The default setting for the Preferred EAP Type parameter is EAP-PEAP
2. Disable the handshake function on the leaf downlink interface. For more information, see "Configuring a user-defined policy template."
#
interface Bridge-Aggregation1024
port link-type trunk
port trunk permit vlan1 101 to 3000 4094
link-aggregation mode dynamic
mac-based ac
dot1x
undo dot1x handshake //Disable the handshake function.
undo dot1x multicast-trigger
#
3. Configure the client and enable the Wired AutoConfig service in Services.
4. Navigate to the Network Adapter > Etherbet0 Properties > Authentication page, and select the Enable IEEE 802.1X authentication option and the Fallback to unauthorized network access option.
5. Navigate to the Network Adapter > Etherbet0 Properties > Authentication > Settings page, and clear the Verify the server's identity by validating the certificate option. Use default values for other parameters.
6. Navigate to the Network Adapter > Etherbet0 Properties > Authentication > Advanced Settings page, and select the Specify authentication mode option, select User authentication in the drop-down list box and click Save credentials. On the pop-up page, enter the username and password.
7. Click OK and then the user is successfully authenticated.
8. Some endpoints might fail to pass the authentication since they have prefix information and the system will show that the users do not exist. In such cases, you can add domains with suffixes. For more information, see "Configuring a device policy template of the AAA type." In addition, you can modify the Username Prefix Conversion Mode to Remove by navigating to the Automation > User > Service Parameters > Access Parameters > System Settings page.
Configuring MAC portal authentication
|
|
WARNING! Use Google Chrome browser on an endpoint to access the MAC portal authentication page. |
MAC portal authentication is mainly applicable to users without clients. You cannot directly enter a username or password for authentication. By pushing a MAC portal authentication page to a user when the user requests network access, the user can enter a username and password on the page for authentication.
MAC portal authentication includes the following stages:
· First stage—When a user's endpoint is connected to a port on the access switch and the port comes up, the endpoint sends packets carrying its MAC address to trigger MAC authentication. The switch identifies the user as the BYOD anonymous user and assigns the user to the BYOD security group. The user endpoint obtains an IP address from the subnets specified for the security group.
· Second stage—When the user opens a webpage, the access switch redirects it to the MAC portal authentication page. On the page, enter the username and password. After the user logs in successfully, the user is added to its associated user security group. Then, the user endpoint obtains an IP address from the subnets specified for the user security group.
The default lease time for IP addresses in the BYOD security group is 1 minute on the DHCP server, so the lease time of the IP address obtained by the endpoint at the first stage is 1 minute. When the user logs in by entering the username and password on the pushed web page, the user is assigned to its associated user security group. After the IP address obtained at the first stage expires, the endpoint requests another IP address. Then, the access switch obtains an IP address from the subnets specified for the user security group for the endpoint.
Creating the BYOD security group
To configure the BYOD security group on SeerEngine-Campus:
1. Navigate to the Automation > Campus Network > Private Network > Layer 2 Network Domain page, and click Add. On the Add Layer 2 Network Domain page, select vpn-default in the Private Network field and select BYOD in the Type field. The default lease time is 1 minute for IP addresses in a BYOD address pool. As a best practice, make sure the lease time is not shorter than 30 seconds. You can adjust the lease time as needed. You must select an H3C vDHCP server for the BYOD security group. For the description of other parameters, see "Creating a Layer 2 network domain."
2. On the Subnets tab, click Add. On the Add Subnet page, enter the Name, IP Version, CIDR and Gateway IP, and then click OK.
3. After the system returns to the Add Layer 2 Network Domain page, click OK. Then, you can view the new BYOD Layer 2 network domain in the Layer 2 network domain list.
4. After adding the BYOD Layer 2 network domain, navigate to the Automation > Campus Network > Security Group > User Security Group page, and click Add. On the Add Security Group page, select BYOD in the Type field, select vpn-default in the Private Network field. In the Layer 2 Network Domain Information area, click Add to add the BYOD Layer 2 network domain added before. Click OK and you can view the BYOD security group in the security group list.
Configuring ACL 3001
ACL 3001 has been configured in "Configuring a policy template."
In the Free IPs area of the device policy template, add the IP address of the EIA server. When the device policy template is applied to a device group, ACL 3001 is deployed to the devices in the device group. When you add, modify, or delete free IPs on the controller, the controller deploys the changes to the devices.
The ACL policy is deployed according to the device group policy configuration.
#
<Leaf1>display acl all
Advanced IPv4 ACL 3001, 2 rules,
SDN_ACL_AUTH
ACL's step is 5, start ID is 0
rule 0 permit udp destination-port eq dns
rule 1 permit ip destination 100.1.0.100 0
#
Enabling MAC portal authentication
1. To enable MAC portal authentication for EIA,
navigate to the Automation
> User > Service Parameters > Access Parameters
> System Settings page, and click the 
icon
corresponding to the template named User Endpoint Settings. In the User
Endpoint Settings area, select Enabled in the MAC Portal
Authentication field to open the MAC Portal Fast Configuration page.
If MAC portal authentication has been enabled, first disable it and then
re-enable it. In addition, enable Transparent Authentication.
2. On the MAC Portal Fast Configuration page, click OK.
The system automatically creates a set of settings as follows:
Automatically created access policy:
Automatically created access service, associated access policy, and security group:
Automatically created BYOD user:
Initiating MAC portal authentication
1. When the port connected to an endpoint is up, MAC authentication is triggered. The BYOD authentication is performed first. Use the anonymous account byodanonymous to log in. Verify that the user is assigned to the BYOD security group and the endpoint obtains an IP address from the subnets specified for the BYOD security group.
On the access switch (acts as the authenticator), display online MAC authentication user information as follows:
<Leaf1>display mac-authentication connection
Total connections: 1
Slot ID: 1
User MAC address: 000c-29b2-2f11
Access interface: Bridge-Aggregation1024
Username: 000c29b22f11
User access state: Successful
Authentication domain: isp
IPv4 address: 50.0.0.2
IPv4 address source: IP Source Guard
Initial VLAN: 111
Authorization untagged VLAN: N/A
Authorization tagged VLAN: N/A
Authorization VSI: vsi5
Authorization ACL number/name: 3001
Authorization user profile: N/A
Authorization CAR: N/A
Authorization URL: http://100.1.0.100:30004/byod/index.html?usermac=%m&userip=
%c&userurl=%o&original=%o
Start accounting: Successful
Real-time accounting-update failures: 0
Termination action: Default
Session timeout period: 86400 sec
Online from: 2020/10/20 11:38:07
Online duration: 0h 19m 53s
Port-down keep online: Disabled (offline)
2. On the user's PC, open the Web browser and enter any IP address such as 1.1.1.1. The PC automatically opens the following BYOD URL redirection page. If the user uses a domain name for accessing the redirection page, the following restrictions exist:
¡ If the user obtains an IP address through DHCP, you must set the DNS server IP on the isolation domain or Layer 2 network domain page.
¡ If the user uses a static IP address, the DNS server IP must be manually configured for the user.
In addition, ensure that the spine and leaf devices,have routes to reach the DNS server.
3. Enter the correct Account name and Password, and click Log In. The following page opens after successful authentication.
4. View the user online information on the EIA. Verify that the user has accessed its associated access service and the user endpoint has obtained an IP address from the subnets associated with the access service.
MAC authentication user information is displayed on the access device.
<leaf10510> dis mac-authentication connection user-name 000c29b22f11
Total connections: 1
Chassis ID: 2
Slot ID: 10
User MAC address: 000c-29b2-2f11
Access interface: Bridge-Aggregation1024
Username: 000c29b22f11
User access state: Successful
Authentication domain: hz1
IPv4 address: 20.0.0.7
IPv6 address: FE80::18AD:C0E3:497B:84BA
IPv4 address source: IP Source Guard
IPv6 address source: User packet
Initial VLAN: 120
Authorization untagged VLAN: N/A
Authorization tagged VLAN: N/A
Authorization VSI: vsi3
Authorization microsegment ID: N/A
Authorization ACL number/name: N/A
Authorization dynamic ACL name: N/A
Authorization user profile: N/A
Authorization CAR: N/A
Authorization URL: N/A
Authorization IPv6 URL: N/A
Start accounting: Successful
Real-time accounting-update failures: 0
Termination action: Default
Session timeout period: 86400 sec
Online from: 2021/08/24 10:36:48
Online duration: 0h 2m 5s
Port-down keep online: Disabled (offline)
Configuring MAC authentication
MAC authentication is mainly applicable to scenarios where a user does not have a client and intends to trigger authentication to come online directly through the endpoint MAC address.
Configuring MAC authentication users
To configure MAC authentication users, navigate to the Automation > User > Access User page, and click Add to manually add access users or import access users in bulk.
Manually adding an access user
1. Click Add on the Access User page. In the Access Information area, enter an account name and select the MAC Access User option. Then, the server automatically configures the password of the user. The account name is a MAC address in the format of xxxxxxxxxxxx, as shown in the figure below.
2. Select an access service for the user, and then click OK.
Importing access users in bulk
1. On the Access User page, click Batch Import. You can click the Account Import File Template link in the Tips area to download an import template. Fill in information of access users to be imported according to the downloaded template.
2. Click Upload and select the file to be uploaded. The usernames and passwords in the file must be MAC addresses in the format of xxxxxxxxxxxxx, as shown in the figure below.
3. After uploading the file, select the column separator used in the file, and click Next to open the access user configuration page. Make sure the Account Name and Password in the Access Information area are MAC addresses.
4. Select an access service and then click OK. You can view that two new users are imported successfully.
Configuring MAC authentication
After the port on the switch connecting to the PC comes up, the PC sends packets with its MAC address to trigger MAC authentication. After successful authentication, you can view information about the MAC authenticated online user on the Monitor > Monitor List > User > Online Users page.
Configuring the broadband IoT service
The broadband IoT service in the AD-Campus solution is authenticated through MAC addresses. A user triggers authentication through traffic. The EIA identifies the user and matches the rules configured for broadband IoT service. The system automatically creates an account and password based on the MAC address of the user, so that the user does not need to manually enter the username and password for authentication but comes online directly.
At present, three configuration modes are available: MAC address range, IP address range, and endpoint identification.
Navigate to the Automation > User > Access User > Mute Terminal User Config Profile page.
· By MAC Range: Set a MAC address range. If a user's MAC address matches the configured MAC address range, the system automatically creates an account for the user and authenticates the user with the account. Then, the system adds the authenticated user to a user security group and assigns the user the IP address of the user security group.
· By IP Range: Set an IP address range. Execute the mac-authentication carry user-ip exclude-ip acl *** command on the downlink interfaces of leaf devices. See "Configuring an interface policy template of the MAC/MAC portal authentication type" for enabling Include User IP Addresses in MAC Authentication Requests in an interface policy template.
· By Endpoint Identification: Set the endpoint device parameter information. The endpoint fingerprint information is carried when the client authenticates to come online. If the endpoint fingerprint information matches the configured endpoint device parameter information, the system automatically creates an account for the user and authenticates the user with the account. Then, the system adds the authenticated user to a user security group and assigns the user the IP address of the user security group.
|
|
WARNING! · The priorities of configured MAC address range and IP address range should be different. If a client matches both the MAC address range and the IP address range, the one with higher priority applies. The priority value can be set to a value from 0 to n. The smaller the priority value is, the higher the priority is. · Restrictions of the mac-authentication carry user-ip command: Use this command only for By IP Range authentication and when Bind User IP authentication is configured in the access policy. In any other cases of user authentication, do not use this command. If the endpoint device needs to be configured with a static IP address for authentication, the controller delivers the static IP address to EIA by issuing ARP snooping settings. |
Fast online based on MAC address ranges
On the Mute Terminal User Config Profile page, click Add and select By MAC Range. On the pop-up page, enter the profile name and user name prefix. The Priority parameter in the Basic Information area on this page can be set to a value from 0 to 999. The default value is 0. The smaller the value is, the higher the priority is.
In the MAC Address Range area, you can manually add MAC address ranges or import MAC addresses.
Manually adding an access user
Click Add to open Add MAC Address Range page. Enter the MAC address range, and click OK. You can add multiple MAC address ranges. Each address range can be configured according to the requirements.
Description of parameters on the Add MAC Address Range page:
· Auto Open Accounts: It can be set to Allow or Deny.
¡ Allow: If an endpoint matches the MAC address range, the system automatically creates an account to authenticate the user, adds the authenticated user to the corresponding security group and obtains an IP address for the user.
¡ Deny: No account is created automatically. The authenticated user triggers the MAC portal authentication to enter the BYOD security group. The administrator opens an account for the user on Monitor > Monitor List > Endpoint > Access Endpoint.
· aging: It can be set to Allow or Prohibit.
¡ Allow: EIA allows the authenticated mute endpoints to go offline after time out in the case of no traffic, NAS reboot, and NAS-Port-down.
¡ Prohibit: In the case of no traffic, NAS reboot, and NAS-Port-down, EIA does not allow the mute endpoint to age and the mute endpoint on the EIA stays online. When the leaf device recovers, it requests the online information from EIA to restore the online status of the mute endpoint.
Importing access users in bulk
1. Click Batch Import to open the Batch Import Mute Terminal MACs page. You can download an import template for batch importing. Click the Mute Terminal MAC Address Range Import Template link to download the import template. Fill in the MAC address ranges to be imported according to the downloaded template. The template format is as follows:
2. Click Upload and select the file to be uploaded. Then, select the column delimiter used in the file, and click Next. Configure the parameters on the Batch Import Mute Terminal MACs page, and then click OK. For more information about parameter configurations on this page, see "Manually adding an access user."
3. Select an access service in the Access Service area and click OK to save the configuration.
4. To make the added MAC address ranges take effect immediately, you need to select the MAC address ranges and click Validate. If you do not click Validate, the MAC address ranges do not take effect until the system polling time expires (within 10 minutes).
After the MAC address ranges are successfully configured, traffic from endpoint devices can trigger authentication. The system matches them with the MAC address ranges, automatically creates user accounts, and adds the authenticated users to the corresponding security groups to obtain IP addresses.
|
|
WARNING! A manual Validate operation can make about 2000 MAC addresses take effect at a time. If the number of MAC addresses is large, select the MAC address ranges and click Validate in multiple batches. |
Fast online based on IP address ranges
On the Mute Terminal User Config Profile page, click Add and select By IP Range. The Priority parameter in the Basic Information area on this page can be set to a value from 0 to 999. The default value is 0. The smaller the value is, the higher the priority is. The priorities of MAC address range and IP address range are compared and should be different.
In the IP Address Range area, you can manually add MAC address ranges or import MAC addresses.
Manually adding an access user
In the IP Address Range area, click Add to open the Add IP Address Range page. Configure the parameters on this page and then click OK to save the configuration.
|
|
WARNING! · The IP range entered needs to be the same as the subnet of the security group set in the Access Service. To view the subnet of the security group, log in to SeerEngine-Campus, navigate to the Automation > Campus Network > Private Network > Layer 2 Network Domain page, and click the subnet links in the Subnet column. · Multiple IP address ranges can be added. Each IP address range's parameters can be set as required. |
Importing access users in bulk
1. Click Batch Import. You can download an import template for batch importing. Click the Mute Terminal IP Address Range Import Template link to download the import template. Fill in the IP address ranges to be imported according to the downloaded template. The template format is as follows:
2. Click Upload and select the file to be uploaded. Then, select the column delimiter used in the file, and click Next. Configure the parameters on the Batch Import Mute Terminal MACs page, and then click OK. For more information about parameter configurations on this page, see "Manually adding an access user."
3. Select an access service on this page and click OK to save the configuration.
4. To make the added IP address ranges take effect immediately, you need to select the IP address ranges and click Validate. If you do not click Validate, the MAC address ranges do not take effect until the system polling time expires (within 10 minutes).
After the IP address ranges are successfully configured, traffic from endpoint devices can trigger authentication. The system matches them with the IP address ranges, automatically creates user accounts, and adds the authenticated users to the corresponding security groups.
5. Deploy the mac-authentication carry user-ip exclude-ip acl *** command to the downlink interface of the leaf device. When an client that uses a static IP address triggers authentication, if its IP address matches a configured IP address range, the system automatically creates a user account to authenticate the user, and adds the authenticated user to the configured access group. About the mac-authentication carry user-ip exclude-ip acl *** command:
¡ mac-authentication carry user-ip: Obtains the static IP address of the endpoint device and sends it to the EIA server to trigger authentication.
¡ exclude-ip acl ***: User packets from the specified segment of the ACL do not trigger MAC authentication.
The following commands are deployed to the leaf device:
# Create an ACL to match address fe80.
acl ipv6 basic 2000
rule deny source fe80:0::0:0 16
#
# Deploy the mac-authentication carry user-ip command to the leaf downlink interface.
interface gigabitethernet 1/0/1
mac-authentication carry user-ip exclude-ip acl 2000
#
|
|
WARNING! · In the current AD-Campus solution, the mac-authentication carry user-ip exclude-ip acl *** command is required to filter IPv6 link local addresses starting with fe80. · When an endpoint user uses a static IP address to access, the IP address carried in the user packets might not be the actual IP address of the user. For example, in IPv4 static address networking, the IP address carried in the user packets is the IPv6 link local address starting with fe80. After the mac-authentication carry user-ip command is used, the device initiates a MAC authentication request to the server with an IP address that is not the user's actual IP address. This causes the server to bind an incorrect IP address to the user or fails to match the user with its correct IP and MAC address binding. To avoid these issues, you can specify the exclude-ip acl parameter to prohibit MAC authentication for users in the network segment specified in the ACL. |
Fast online based on endpoint identification
On the Mute Terminal User Config Profile page, click Add and select By Endpoint Identification.
You can manually add or import endpoint identification items. This section only describes contents that need special attention. For configuration of other parameters, see "Fast online based on MAC address ranges."
· To manually add endpoint identification entries, click Add. On the Add Terminal Identity page, configure the endpoint identification items (OS, endpoint type, or vendor).
· To import endpoint identification entries in bulk, you can click Mute Terminal Endpoint Identification Import Template link to download the import template. The format of the import template is as follows:
· After completing the configuration, click Validate. If you do not click Validate, the configuration does not take effect until the system polling time expires (within 10 minutes).
Traffic from endpoint devices triggers authentication. The system matches the fingerprints of the endpoints with the endpoint identification entries. If matches are found, the system automatically creates user accounts and adds the authenticated users to the corresponding security groups.
Retaining broadband IoT endpoints to stay online for a long time
To retain IoT endpoints to stay online for a long time, use the offline check period (hours) in conjunction with ARP/ND snooping and trigger keepalive 30 seconds before the ARP/ND entries age. To retain the broadband IoT endpoints to stay online for 1 to 2 offline check periods, you only need to set the Offline Check Period (Hours) in the access policy of EIA. The configuration is as follows:
Navigate to the Automation > User
> Access Service > Access Policy page, and then
click the Edit icon 
to modify the Offline
Check Period (Hours) in the Authorization Information area. The
recommended value is 24 hours.
To retain broadband IoT endpoints to always stay online, select either of the following methods:
· Method 1: Set the offline check period to 0 and disable offline check. The endpoint is not aging with no traffic for a long time.
· Method 2: In addition to setting the offline check period to 0, enable ARP snooping on the SeerEngine-Campus controller and configure the offline check period on the device to cooperate with ARP snooping. This method is applicable to retain certain broadband IoT endpoints to always stay online. To enable ARP snooping:
a. Navigate to the Automation > Campus
Network > Private Network > Layer 2 Network Domain page, and click
the Edit icon 
for the target Layer 2 network domain.
b. On the Advanced tab of the Edit Layer 2 Network Domain page, select On in the ARP Snooping field, and then click OK.
The arp snooping enable command is deployed to the leaf device:
#
vsi vsi3
description SDN_VSI_3
gateway vsi-interface 3
statistics enable
arp snooping enable //Command deployed by the controller.
flooding disable all all-direction
vxlan 3
evpn encapsulation vxlan
mac-advertising disable
arp mac-learning disable
nd mac-learning disable
route-distinguisher auto
vpn-target auto export-extcommunity
vpn-target auto import-extcommunity
dhcp snooping binding record
#
In addition to the offline check period and ARP snooping settings, you need to manually configure the mac-authentication offline-detect mac-address xxxx-xxxx-xxxx timer xxxx check-arp-or-nd-snooping command to enable the cooperation between the offline check period and ARP/ND snooping, so as to trigger keepalive 30 seconds earlier than the aging of ARP/ND entries.
The command configuration is as follows:
The timer refers to the offline check period, which should be longer than the ARP aging timer, for example, 3600 seconds.
#
mac-authentication offline-detect mac-address 0001-0002-0003 timer 3600 check-arp-or-nd-snooping
#
|
|
WARNING! The mac-authentication offline-detect mac-address xxxx-xxxx-xxxx timer xxxx check-arp-or-nd-snooping command must be used for each authentication endpoint device. The mac-address keyword specifies the MAC address of an endpoint. If you do not used this command and only configure the offline check period, the collaboration between ARP snooping and offline check period cannot be realized. When the offline check period expires, the endpoint will go offline if no traffic is present. |
Configuring authentication-free interfaces
The controller can be configured with authentication-free interfaces. When a user comes online from an authentication-free interface, the user can join the set security group directly without authentication to obtain an IP address and access the corresponding network resources of the security group.
When setting an authentication-free interface, you need to create an authentication-free interface group first. By default, the system does not create an authentication-free interface group.
Adding an authentication-free interface group
To configure authentication-free in a security group, you need to manually configure an authentication-free interface group first.
1. Navigate to the Automation > Campus Network > Devices > General Device Groups page and click Add.
2. Create an authentication-free interface group and select the members of the group, as shown in the figure below.
¡ Group Type: Select Interface Group.
¡ Subtype: Select Authentication-Free Interface Group.
3. On the Member tab of the Add General Policy Group page, click Add. On the Add Interface page, select the devices and interfaces, click Add to add them to the Selected Interfaces list, and click OK. The system returns to the Add General Policy Group page.
4. Click OK to save the configuration. In the General Policy Groups list, you can view the authentication-free interface groups.
Adding a port isolation device group
|
|
WARNING! If an interface in an authentication-free interface group is on an access device, you need to add the access device to a port isolation device group. For multi-level cascaded access devices, you only need to add access devices that have interfaces in authentication-free interface groups to port isolation device groups. Skip this task if authentication-free interfaces are interfaces on leaf devices. |
1. Navigate to the Automation > Campus Network > Devices > General Device Groups page and click Add.
2. Create a port isolation device group, as shown in the figure below.
¡ Group Type: Select Device Group.
¡ Fabric: Select the fabric of the access device.
¡ Subtype: Select Port Isolation Device Group.
3. Click Add on the Member tab and select an access device that has configured authentication-free interface groups.
¡ Ports Outside Isolation Groups: All uplink interfaces connecting access devices to leaf devices must be added to the ports outside isolation groups. For multi-level cascaded access devices, the uplink interfaces connecting the upper level access devices to the lower level access devices must be added to the ports outside isolation groups.
4. Deploy configurations to access devices.
Deploy port isolation group globally:
#
#
Issue the port-isolate enable group 1 command to interfaces of the access devices (excluding ports outside isolation groups):
#
interface GigabitEthernet1/0/1
port link-mode bridge
port access vlan 101
port-isolate enable group 1
stp edged-port
poe enable
#
Binding a security group to an authentication-free interface group
Navigate to the Automation > Campus
Network > Security Group page, and click the Edit icon 
in the corresponding Actions column
of the security group.
1. On the Edit Security Group page, click the Auth-Free tab.
2. Select the Auth-Free Interface Groups on this page.
¡ ARP Detection Trust: By default, it is enabled. After enabling this parameter, the ARP detection trust configuration is deployed to the Ethernet service instances issued by auth-free services.
Configuration deployed to the devices
After the security group is bound to the authentication-free interface group, the following configuration is deployed to the devices:
· If the member in the authentication-free interface group is an interface on the access device:
# Configure Ethernet service instance 4051 on the leaf downlink interface connected to the access device.
#
interface Ten-GigabitEthernet1/2/0/13
port link-mode bridge
port link-type trunk
port trunk permit vlan 1 101 to 3000 4094
port-security free-vlan 1 4051 4094
#
service-instance 4051
encapsulation s-vid 4051
xconnect vsi vsi3
arp detection trust
#
return
#
Configure static VLAN settings on the authentication-free interface on the access device.
interface GigabitEthernet1/0/49
port access vlan 4051
stp edged-port
#
· If the member in the authentication-free interface group is an interface on the leaf device:
# Configure Ethernet service instance 4051 on the authentication-free interface on the leaf device.
interface Ten-GigabitEthernet1/2/0/14
port link-mode bridge
port link-type trunk
port trunk permit vlan 1 4051
port trunk pvid vlan 4051
port-security free-vlan 4051
#
service-instance 4051
encapsulation untagged
xconnect vsi vsi3
arp detection trust
#
return
#
Guest online or authentication failure online
|
|
WARNING! · Only 802.1X authentication supports guest online and authentication failure online. · You must enable unicast trigger when enabling the guest function. · Guest online and MAC portal authentication are mutually exclusive. |
Guest online
Guest online enables a user to visit guest-type security groups when the user comes online without configuring the authentication server.
Creating a guest-type Layer 2 network domain
Navigate to the Automation > Campus Network > Private Network > Layer 2 Network Domain page.
1. Click Add to open the Add Layer 2 Network Domain page, and configure the following parameters:
¡ Private Network: Select a private network.
¡ Type: Select Guest.
¡ IPv4 Address Allocation: Select Dynamic.
¡ DHCPv4 Server: Select a DHCPv4 server.
¡ IPv4 Address Lease Duration: By default, it is set to 30 minutes.
2. On the Subnets tab, click Add. On the Add Subnet page, select the IP Version, and configure CIDR and Gateway IP.
3. Click OK and the system returns to the Add Layer 2 Network Domain page. Then, click OK.
Creating a guest-type security group
Navigate to the Automation > Security Group > User Security Group page, and click Add to open the Add Security Group page.
Configure one guest-type security group for one isolation domain. If the isolation domain contains multiple fabrics, the guest-type security group is shared by all the fabrics. Select Guest for Type. Click the Layer 2 Network Domain Information tab, and click Add. On the Add Layer 2 Network Domain page, select the guest-type Layer 2 network domain configured before.
Enabling guest access in a policy template
Enable Guest Access in "Configuring an interface policy template of the 802.1X type."
The following configuration will be deployed when applying this policy template to the leaf downlink interface group:
[leaf105102-Ten-GigabitEthernet1/0/0/14]display this
#
interface Ten-GigabitEthernet1/0/0/14
port link-mode bridge
port link-type trunk
port trunk permit vlan 1 101 to 3000 4094
stp tc-restriction
mac-based ac
dot1x
undo dot1x multicast-trigger
dot1x unicast-trigger
dot1x guest-vsi vsi10
port-security free-vlan 1 4094
#
service-instance 4094
encapsulation s-vid 4094
xconnect vsi vxlan4094
#
Return
Authenticating a user to come online
When a user's PC is connected to the network, the user can obtain the IP address to access certain resources specified by the guest-type security group.
Permitting users that fail authentication to come online
This mode is used in authentication failure scenarios. When users fail to pass 802.1X authentication, they can still come online and access the resources in the security group with the type of Authentication Failure.
Creating an authentication failure Layer 2 network domain
Navigate to the Automation > Campus Network > Private Network > Layer 2 Network Domain page.
1. Click Add to open the Add Layer 2 Network Domain page, and configure the following parameters:
¡ Private Network: Select a private network.
¡ Type: Select Authentication Failure.
¡ IPv4 Address Allocation: Select Dynamic.
¡ DHCPv4 Server: Select a DHCPv4 server.
¡ IPv4 Address Lease Duration: By default, it is set to 1 day.
2. Click Add on the Subnets tab to open the Add Subnet page.
3. Click OK and the system returns to the Add Layer 2 Network Domain page. Then, click OK.
Creating an authentication failure security group
Navigate to the Automation > Security Group > User Security Group page, and click Add to open the Add Security Group page.
Configure one authentication failure security group for one isolation domain. If the isolation domain contains multiple fabrics, the authentication failure security group is shared by all the fabrics. Select Authentication Failure for Type. Click the Layer 2 Network Domain Information tab, and click Add. On the Add Layer 2 Network Domain page, select the authentication failure layer 2 network domain configured before.
Enabling access on authentication failure in a policy template
Enable Access on Authentication Failure in "Configuring an interface policy template of the 802.1X type."
The following configuration will be deployed when applying this policy template to the leaf downlink interface group:
[leaf105102-Ten-GigabitEthernet1/0/0/14]display this
#
interface Ten-GigabitEthernet1/0/0/14
port link-mode bridge
port link-type trunk
port trunk permit vlan 1 101 to 3000 4094
stp tc-restriction
mac-based ac
dot1x
undo dot1x multicast-trigger
dot1x unicast-trigger
dot1x guest-vsi vsi10
dot1x auth-fail vsi vsi12
dot1x critical vsi vsi11
dot1x critical eapol
port-security free-vlan 1 4094
#
service-instance 4094
encapsulation s-vid 4094
xconnect vsi vxlan4094
#
Authenticating a user to come online
When users fail to pass the 802.1X authentication on users' PCs, they can access resources in authentication failure security groups.
Guest services
A guest is also a MAC portal user. A guest is an external temporary user, and access rights are restricted. Temporary users do not have accounts; therefore, you need to configure Page Push Policy and BYOD Pages to realize the guest function and provide the guest registration function. A guest can submit the registration info to register automatically and log in to the system.
For guests, the following page push methods are available, as shown in the figure below:
· For PCs: Default WEB Login (PC), QR Code Registration and Authentication (PC), and SMS Message Registration and Authentication (PC).
· For phones: Default WEB Login (Phone), QR Code Registration and Authentication (Phone), and SMS Message Registration and Authentication (Phone).
If the user pre-registration is completed on the SMS authentication page, it is necessary to complete the SMS modem or SMS gateway configuration. On the authentication page opened, a guest enters the cell phone number, and then obtains the password through the SMS modem to open an account and log in.
If QR code method is used, a guest user can view a QR code on the Web page. The administrator scans the QR code and opens the URL to approve the user. The user can log in directly after the account is opened successfully.
If a guest user logs in via scanning a QR code, the guest user can scan the QR code set by the administrator to log in and access network resources for guest users.
The following information introduces the PC - Default Web Login (PC) method, and the guest is configured to Guest Auto-Registration. That is, without manual approval by the administrator, the guest can come online automatically after pre-registration.
Configuring guest management
Configuring the guest manager
Navigate to the Automation > User > Guest User page and click Guest Manager tab.
1. On the Guest Manager page, click Add to open the page for adding a guest manager. Click Select Access User to open the Select Access User page. You can view all the access user information. The guest manager is selected from access users. One guest must have one guest manager. You can also set the default guest manager.
2. Select an access user and click OK. The system returns to the Add Guest Manager page. Click OK and the system returns to the Guest Manager page. The guests are displayed on the guest manager list. You can click Yes or No in the Default Guest Manager column to configure the default guest manager feature. The Yes value indicates that the access user is the default guest manager.
Configuring a guest service
Before adding a guest service, you need to create the Layer 2 network domain, security group, access policy, and access service corresponding to the guest service. For more information about the configuration, see "Creating a Layer 2 network domain", "Configuring security group", "Configuring access policies", and "Configuring access services." For example, configure a Guest Security Group and set the corresponding access policy, and then configure the Guest Access Service to be associated with the Guest Security Group.
To configure a guest service:
1. Navigate to the Automation > User > Guest User > Guest Policy > Service page. Click Add.
2. On the guest services page, select one or multiple guest services and then click OK. On the page opened, click Back to return to the Service page. In the Default Guest Service column, click Yes or No to configure the default guest service. It should be noted that there must be a default guest service in the guest service list.
Configuring a guest policy
Navigate to the Automation > User > Guest User > Guest Policy > Guest Policy page.
1. By default, the system has a Default Guest Policy, as shown in the figure below.
2. Click the Edit icon 
to modify the policy.
Set Guest Auto-Registration to Enable. It indicates that a guest user can automatically come online after completing the pre-registration. If this function is disabled, a guest user can come online only after the approval of the guest manager.
After setting Guest Auto-Registration to Enable, select the Apply to QR Code Registration and Authentication Users check box. In this case, if QR Code Registration and Authentication is configured in "Configuring a page push policy", a guest user is registered automatically by scanning the QR code, without the approval of the guest manager.
3. Click OK to complete the configuration.
Configuring guest service parameters
Navigate to the Automation > User > Guest User > Guest Policy > Service Parameters page.
You can use the default settings or modify the settings as required. Once the settings are completed, guest users can be authenticated to come online. For more information, see "Guest online."
Configuring a page push policy
1. Navigate to the Automation > User > Access Service > Page Push Policy page.
2. Click Add and configure the following parameters on the pop-up page.
¡ Authentication Method: Select BYOD.
¡ Default Authentication Page: By default, it is PC - Default WEB Login (PC), which indicates login through the Web page. You can set the authentication method as required.
3. After setting, click OK to save the configuration. You can view the new push policy in the Page Push Policy List.
Guest online
User authentication and access
1. When an authentication device port comes up, MAC authentication is triggered. Guests come online by using an anonymous account (named byodanonymous). They obtain IP addresses from the network segment of the BYOD security group. You can see the anonymous account on the Monitor > Monitor List > User > Online Users page.
2. After a Web page is opened on the client, enter an IP address (any URL), such as 1.1.1.1.
Default Web page
1. The default page push policy is Default WEB page, that is, the user's PC automatically accesses the following BYOD default page: http://100.1.0.100:30004/byod/view/byod/byodLogin.html, as shown in the figure below.
2. Click Guest Preregistration to open the following page, enter required fields marked with *, including Account Name, Identity Number, Verify Code, and Guest Manager. Click OK to complete the pre-registration.
The guest manager is the default manager set earlier. The password is randomly populated if not set. You can also set your own password as well.
3. If you register successfully, the registration result information is displayed. Click Login to log in directly, and click Back to go to the BYOD login page. You can also enter the registered account and password, (that is, fa1/123456) to log in.
4. Navigate to the Monitor > Monitor List > User > Online Users page. You can view that the guest has successfully obtained an IP address in the guest security group.
5. Navigate to the Automation > User > Guest User > All Guests page. The newly registered guest user is displayed. Click the account name to view the details of the registered guest user.
QR code registration and authentication
1. If you select PC - QR Code Registration and Authentication in "Configuring a page push policy", the PC automatically goes to the QR code page.
2. Modify the Default Guest Policy in "Configuring a guest policy", and change the Guest Auto-Registration to prohibited. The guest user needs to be approved by the manager before the guest can come online.
3. After the client PC authentication port comes up and accesses the BYOD security group, enter any IP address on Google Chrome of the client PC. The QR code page opens, as shown in the figure below:
4. The guest manager can scan the QR code on this guest's PC by phone. Click Continue to visit the Web.
If the phone is not connected to the same network as the client, manually enter the URL displayed on the cell phone on the PC, and press Enter. The following page opens. Log in by using the guest manager account.
5. After login, the following page opens. The account shown below is the account given to the guest. The guest manager clicks To Approve.
6. After the approval page opens, click Accept to register the guest account. The Web page of the user jumps to a page showing that the registration is successful.
7. About 20 to 30 seconds later, the guest can automatically log in. The guest information of successful registration can be viewed on EIA. Navigate to the Automation > User > Guest User > All Guests page. You can see that the user logs in to the Guest Access Group and obtains an IP address from the IP segment of the guest access group.
SMS message registration and authentication page
1. If you select PC - SMS Message Registration and Authentication in "Configuring a page push policy", the user's PC automatically jumps to the default SMS page.
2. After the client PC authentication port comes up and joins the BYOD access group, enter any IP address on Google Chrome of the client PC. The following page opens:
If there is a corresponding SMS modem or SMS gateway, you can enter your phone number and then get a password to log in.
Scanning QR code to log in
The guest manager sets a QR code for guest login, and the user only needs to scan the QR code to log in to the network and access network resources for guest users.
1. The guest manager enters the IP address of the EIA server http://100.1.0.100:9066/ssvui/login.html in the browser to log in to the Self-Service Center page. Enter the guest manager's username and password. Then, click Login.
2. After logging in to the Self-Service Center, select Guest User > All guests. The guest information is displayed.
3. Click Add to add a guest, or select a
guest in the guest list, click the 
icon to modify
the Max. Concurrent Logins parameter. Set the number of users allowed to
scan QR code as needed. The maximum value is 999.
4. After Max. Concurrent Logins is set,
click the 
icon of the portal authentication QR code in the QR Code for
BYOD Login column to open a QR code page. If the users' endpoints are
connected to the internal network, users can scan the QR code to log in
successfully.
5. If you want to use WeChat to scan the guest QR code to complete the login, perform the following operations when the BYOD security group address cannot connect to the external network:
a. When the guest's phone is connected to the external network, use WeChat to scan the QR code generated by the guest manager to get the URL in the QR code.
b. Enter the received URL on the PC and log in.
Approving guests
When Guest Auto-Registration is set to Disable in "Configuring a guest policy", a guest needs to be approved by the guest manager. The guest can be an official guest user after approval.
1. The guest manager enters the IP address of the EIA server http://100.1.0.100:9066/ssvui/login.html in the browser to log in to the Self-Service Center page. Enter the guest manager's username and password. Then, click Login.
2. Select Guest User > All
Preregistered guests to query all the guest users waiting for approval.
Click the 
icon for approval.
During the approval, you can modify the access users of guests. All access services configured in "Configuring a guest service" are listed. Click Approve.
3. After approval, you can query the approved guest users on the Automation > Users > Guest Users > All Guests page.
Permission and domain management
Overview
The campus controller supports the permission and domain management function. It mainly refers to the functional permissions that the controller grants to an operator according to the role attribute after the operator logs in to the controller. Many functions are involved. This section mainly introduces isolation domains and fabric-related configurations.
Basic concepts
Groups
The system provides groups for hierarchical management of operators. A group can be configured with operator roles to control the permissions of operators in the group. The system is pre-configured with four default groups. You can also create groups as needed.
· System Manager Group: Group of user roles that with permissions to manage system settings.
· System Viewer Group: Group of user roles with permissions to view system settings.
· Service Manager Group: Group of roles with permissions to manage network devices and alarms.
· Service Viewer Group: Group of roles with permissions to view network devices and alarms.
To view the groups, navigate to the System > Authority Management > Organization Management page.
|
|
WARNING! · You cannot delete a group that is being used by an operator. · You cannot change the name of a group. · You cannot add a group that exists already. · Up to 10 levels of sub-groups can be created. · Due to the performance limit, a maximum of seven levels of groups can be imported. |
Roles
A role defines a set of permissions for a type of users. The system adopts role-based permission control, which can refine the grouping of user permissions and facilitate the management of user permissions. The system provides a series of roles by default, and you can also define roles as needed.
· Campus System Manager: Role with permissions to manage the information of the campus network.
· Campus System Viewer: Role with permissions to view the campus network information.
· Campus Area Manager: Role with permissions to manage specific campus network information.
· Campus Area Viewer: Role with permissions to view specific campus network information.
To view the roles, navigate to the System > Authority Management > Roles page.
|
|
WARNING! · The campus area roles do not contain isolation domain or fabric permissions by default, and you need to manually add area permissions as needed. · You cannot add a role that already exists. · After deleting a role, you can re-add a role with the same name as the deleted role. · Delete a role with caution. Deleting a role means that users with that role no longer have the permissions under that role. |
Permissions
A permission defines the permitted operations and data resources for a resource type. You can add, modify, delete, and view permissions. The system provides a series of permissions by default. You can also define permissions as needed. By default, a new user, group, or role permission has all the data resources under that permission by default.
The system also supports configuring the data resources for a permission. For example, an area manager can select its corresponding isolation domains and fabrics as the resources of the permission. Operations controlled by this permission can only deal with the resources specified in the permission.
To view permissions, navigate to the System > Authority Management > Permissions page.
|
|
WARNING! · The admin operator is the super administrator and has all permissions by default. · You cannot change the name of a permission when modifying it. · You cannot add a permission that already exists. · If there are permissions to modify or delete data with no permissions to view, the data is not displayed on the page. · If only part of the resource data is specified for a permission, the permission does not allow the user to view, modify, or delete the other data. · Delete the permission with caution. Deleting a permission means that users with that permission no longer have the corresponding operation permission or data permission. |
Configuring permissions and domains
Adding a permission
Adding sub-permission for area managers
1. Navigate to the System > Authority Management > Permissions page and click Add. Enter the permission name, select CAMPUS as the permission group, and select Isolated Domain as the resource type (you can enter a name to filter the desired resource type).
2. In the Select Actions area, select Read&write
isolation domains (for area managers) or Read isolation domains (for
area viewers) check box. Then, click the 
icon to add it to
the Selected list.
3. In the Select Scope area, select All or select. This section selects select as an example. Select Select Resources. In the dialog box that opens, select the corresponding isolation domain and click Select.
4. Click OK. A sub-permission for the area manager is added under the Isolation Domains permission (Path: System > Permissions > CAMPUS > Isolation Domains).
Adding sub-permission for area operators under a fabric
1. Navigate to the System > Authority Management > Permissions page and click Add. Enter the Permission Name, select CAMPUS as the Permission Group, and select Fabrics as the Resource Type.
|
|
WARNING! If both Campus and DC controllers are deployed, there are two fabrics permissions. The one that allows for scope configuration is the fabrics permission for Campus. |
2. In the Select Actions area, select Read&write
fabrics (for area managers) or Read fabrics (for area viewers) check
box. Then, click the 
icon to add it to the Selected list.
3. In the Select Scope area, select All or select. This section selects select as an example. Select Select Resources. In the dialog box that opens, select the corresponding fabrics and click Select.
4. Click OK. A sub-permission for the area manager is added under the Fabrics permission (Path: System > Permissions > CAMPUS > Fabrics).
Adding user-defined roles
1. Navigate to the System > Authority Management > Roles page, click Add, and enter the role name. Click Select to select permissions for the role. Permission filtering is supported. You can enter a permission name to obtain the desired permission.
2. Enter the name of the permission added in
"Adding a permission" and click the Search icon 
.
Select the permission and then click OK.
3. Click OK to complete the addition of the area role. Then, you can view the added area role on the System > Authority Management > Roles page.
Adding user-defined groups
1. Navigate to the System > Authority Management > Groups page and click Add. Enter the group name, mail, and contact information.
2. Select the role added in "Adding user-defined roles" and the default Campus Area Manager role (to ensure that the administrator has the necessary permissions for other basic modules of the campus network).
3. Click OK to complete the addition of the group. Then, you can view the added area group on the System > Authority Management > Groups page.
Adding an operator
1. Navigate to the System > Operator Management > Operators page and click Add.
2. Enter the operator name, select System from the Tenant list, and select the group added in "Adding user-defined groups" from the Group list. Select Simple Password Authentication as the authentication method, and enter the login password. The password must meet the complexity requirements. That is, the password must be a string of 8 to 30 characters that contain characters from digits, uppercase letters, lowercase letters, special characters (!"#$%&'()*+,-./:;^`<=>?@[]{}_|~) and spaces. The password cannot contain the operator username or reverse order of operator username characters. It cannot start or end with a space.
3. Click OK to complete the addition of the operator.
Verifying permission and domain management
Log in to the controller management page with the operator added in "Adding an operator" and check whether the operator has the permissions as configured.
|
|
WARNING! After a fabric is bound to an isolation domain, you need to add permissions to both the fabric and the corresponding isolation domain. Otherwise, the relevant pages are not displayed. |
Wizard > Campus Wizard > Device Onboarding Plan
The fabric available for the device onboarding configuration is only the authorized fabric. You can view its corresponding address pool configuration and role templates. You cannot select or view the information about other fabrics.
Monitor > Topology > Campus Topology
You can view the topology and device information of the permitted fabric, and cannot view the topology information of other fabrics.
Automation > Campus Network > Fabrics
You can view and modify the fabric information of the permitted fabric, and cannot view the information of other fabrics.
Automation > Campus Network > Devices > Switch Devices
You can view and modify the devices in only the authorized fabric, and cannot view the device information of other fabrics.
Automation > Campus Network > Isolation Domain > Isolation Domain
By default, you can view all isolation domains.
But you can view only the fabrics bound to the isolation domain to which the operator has permission.
Fabrics bound to other isolation domains cannot be viewed.
Public resources
Some of the public resources do not support area permission configurations for operators. All area managers only have the right to view and they do not have the right to edit the resources. All edit operations need to be operated by the system administrator. Mainly the following interfaces are involved:
· Navigate to the Automation > Campus Network > Devices > General Device Groups page, and click Policy Templates.
· Tabs such as DHCP, AAA, and Parameter on the Automation > Campus Network > Network Parameters page.
· Group Policies, Service Chains, Policy Templates, and Time Ranges tabs on the Automation > Campus Network > Network Strategy page.
· Parameters such as Device Replacement, IP Address Pools, VNID Pools on the Automation > Campus Network > Devices page.
Configuring endpoints directly connected to leaf devices
Leaf interfaces can also directly connect to endpoints in addition to access devices, and endpoints are authenticated and come online by directly connecting to the leaf interfaces.
Adding members to an interface group
1. Navigate to the Automation > Campus
Network > Devices > General Device Groups
page, and click the Edit
icon 
corresponding to the group named User Direct Connection - Leaf Interface Group to open the Edit
General Policy Group page.
2. On the Member tab, click Add. Select the interfaces connected to the endpoints on the leaf devices. Click Add to add the interfaces to the selected interface list and then click OK. After adding the interfaces, the page is shown as follows:
3. Click OK to complete the addition of the member.
Deploying a policy to an interface group
1. Navigate to the Automation > Campus Network > Devices > General Device Groups page, click Add, select a policy template configured in "Configuring a policy template", and add it to the group policy. You can deploy an 802.1X authentication template or MAC/MAC portal authentication template according to the actual situation. As a best practice, do not deploy both an 802.1X authentication template and a MAC/MAC portal authentication template to the same physical interface.
2. The configuration deployed to a leaf device is as follows:
Deploy an 802.1X authentication template or MAC/MAC portal authentication template to interfaces according to the actual situation. Only one of the templates can be selected. In this example, a MAC/MAC portal authentication template is deployed.
[Leaf11-Ten-GigabitEthernet5/0/22]display this //Interface directly connected to endpoints.
#
interface Ten-GigabitEthernet5/0/22
port link-mode bridge
port link-type trunk
port trunk permit vlan 1
mac-based ac
mac-authentication
mac-authentication domain isp
mac-authentication parallel-with-dot1x
mac-authentication critical vsi vsi167 url-user-logoff
#
3. After the configuration is completed, the endpoints connected to the leaf device can be authenticated.
Configuring user critical solutions
|
|
WARNING! · As a best practice, do not select the Enable Policy Server option if EAD function is not used. By default, the parameter is selected. If this option is selected, after the escape time exceeds 3 heartbeat intervals for an online 802.1X authenticated user that uses the iNode client, the user will automatically go offline. · Configure user critical solutions on the Automation > User > Access Parameters > Policy Server Parameters page. |
Creating a critical Layer 2 network domain
The critical scheme is mainly used to allow users to access resources in a specific security group when the EIA server fails and user authentication cannot be connected to the EIA server. The specific security group is the critical security group.
When configuring the critical service, a DHCP server needs to be set up for the critical service, and the subnet corresponding to the critical security group is delivered to the DHCP server. You can use either an H3C DHCP server or a third-party DHCP server.
|
|
WARNING! · An isolation domain allows only one critical security group to be configured. · The critical security group must be configured in a private network, and it is not supported to configure the critical security group in VPN instance vpn-default. · As a best practice, set up the critical DHCP server to a different server from the EIA server, BYOD DHCP server, and service DHCP server. Make sure the critical server and the network devices can reach each other. |
Navigate to the Automation > Campus Network > Private Network > Layer 2 Network Domain page.
1. Click Add to open the Add Layer 2 Network Domain page, and configure the following parameters:
¡ Private Network: Select the private network. You cannot select vpn-default.
¡ Type: Select Critical.
¡ IPv4 Address Allocation: Select Dynamic.
¡ DHCP Server: Select the critical DHCP server. For more information about the critical DHCP server configuration, see"Configuring the critical DHCP server."
¡ IPv4 Address Lease Duration: By default, it is set to 10 minutes.
2. On the Subnets tab, click Add. On the page that opens, set the Name and CIDR, and click OK. The system returns to the Layer 2 Network Domain page.
3. Click OK, and then you can view the new critical Layer 2 network domain on the Layer 2 Network Domain page.
Configuration deployed to a leaf device:
# The IP address of the DHCP server that deploys the VSI interface of the leaf device is the IP address of the critical DHCP server.
#
interface Vsi-interface167 //The VSI interface number corresponds to the VXLAN ID in the Layer 2 network domain ID.
description SDN_VSI_Interface_167
ip binding vpn-instance Teach
ip address 40.0.0.1 255.255.0.0
mac-address 0000-0000-0001
local-proxy-arp enable
dhcp select relay proxy
dhcp relay information circuit-id vxlan-port
dhcp relay information enable
dhcp relay server-address 192.168.2.210
dhcp relay source-address interface Vsi-interface4094
dhcp relay request-from-tunnel discard
#
Creating a critical security group
|
|
NOTE: Only one critical security group can be configured in an isolation domain. If there are multiple fabrics in an isolation domain, all the fabrics share one critical security group. |
Navigate to the Automation > Campus Network > Security Group > User Security Group page.
1. Click Add and configure the following parameters:
¡ Private Network: Select the private network.
¡ Type: Select Critical.
2. Select the Layer 2 Network Domain
Information tab, and click Add. On the Add Layer 2 Network
Domain page, select the configured critical domain and click the 
icon
to add the configured critical Layer 2 network domain to the Selected
Layer 2 Network Domain list. Click OK to save the configuration.
3. Click OK, and then you can view the new critical security group on the User Security Group page.
Configuring a policy template
You need to configure the critical function in a policy template, and apply the policy template to a leaf device interface group for the critical function to take effect. For more information, see "Configuring an interface policy template of the 802.1X type" and "Configuring an interface policy template of the MAC/MAC portal authentication type."
Navigate to the Automation > Campus Network > Devices > General Device Groups page, and click Policy Templates.
After the leaf downlink interface group is configured with a policy template, the controller deploys critical VSI related configuration to the leaf downlink interfaces.
#
interface Bridge-Aggregation1023
port link-type trunk
port trunk permit vlan 1 101 to 3000 4094
link-aggregation mode dynamic
stp tc-restriction
mac-based ac
dot1x
undo dot1x handshake
undo dot1x multicast-trigger
dot1x unicast-trigger
dot1x critical vsi vsi167
dot1x critical eapol
mac-authentication
mac-authentication domain isp
mac-authentication parallel-with-dot1x
mac-authentication critical vsi vsi167 url-user-logoff
port-security free-vlan 1 4094
#
service-instance 4094
encapsulation s-vid 4094
xconnect vsi vxlan4094
#
Configuring critical IT resource access settings
A critical security group cannot be set in private network vpn-default. The critical security groups configured in different isolation domains are different. As a best practice, deploy IT resource groups accessed by multiple private networks in the vpn-default private network. Then configure IT resource groups in the private networks and configure permissions for accessing the critical security groups and IT resource groups.
By default, a private network can communicate with the vpn-default private network, and the private network can access the IT resource groups associated with vpn-default regardless of whether the default access policy of the private network to vpn-default is set to Permit or Deny. Therefore, you need to configure IT resource groups in the private network, and then configure access policies to not allow the critical security group to access specific IT resource groups. For this purpose, deploy deny-mode group policies for the IT resource groups.
Configuring the critical DHCP server
When configuring the critical security group, you must specify a critical DHCP server.
· If the DHCP server configured in the isolation domain is a Microsoft DHCP server, you can use the server as the critical DHCP server.
· If the DHCP server configured in the isolation domain is an H3C vDHCP server, you must build a new DHCP server as the critical DHCP server.
The configurations of the critical DHCP server are as follows:
· If the critical DHCP server is an H3C vDHCP server, no authentication configuration is required. Select vDHCP directly when "Creating a critical Layer 2 network domain."
· If the critical DHCP server is a Microsoft DHCP server, you must configure the VXLAN 4094 address pool.
Configuring a Microsoft tightly coupled DHCP server
If you use a Microsoft DHCP server as the critical DHCP server, you must configure the VXLAN 4094 address pool. For information about configuring the VXLAN 4094 address pool, see "Adding a Microsoft DHCP server."
After the critical security group is created, an address pool for the critical service is created on the selected critical DHCP server, as shown in the figure below.
|
|
WARNING! If there are multiple fabrics in an isolation domain, you must configure the VXLAN 4094 address pool for multiple fabrics. |
Configuring a Microsoft loosely coupled DHCP server
In loose coupling mode, the SeerEngine-Campus controller does not deploy any configuration to the DHCP server. You must manually create the address pool that contains subnets in the critical security group on the DHCP server.
Creating a scope for VLAN 4094
On the Microsoft DHCP server, manually configure the scope of VLAN 4094.
The purpose of configuring this address scope is to allow users to obtain IP addresses from the IP address pool in the critical security group that is subsequently created. The VLAN 4094 scope must be configured. If not, users cannot obtain IP addresses from scopes created by other security groups.
|
|
WARNING! If there are multiple fabrics in an isolation domain, you must configure the VXLAN 4094 address pool for multiple fabrics. |
1. Right-click and select New Scope to open the New Scope Wizard page. Click Next and enter the name.
2. Click Next to access the IP Address Range page. Enter the IP address segment, which must be the same as the IP address segment of VXLAN 4094/VLAN 4094 on the device.
3. Click Next. On the page that opens, enter the IP address range to be excluded. This step is optional. You can set only the gateway IP. Click Add to add the address to the list.
4. Click Next. Set the lease duration to 1 day.
5. Click Next continuously. For parameters not described here, click Next. On the Activate Scope page, select Yes, I am activating the scope now.
6. Click Next, and then click Finish. After the configuration is completed, the VLAN 4094 scope is configured as follows.
Creating a critical security group scope
1. Right-click and select New Scope on the Microsoft DHCP server to open the New Scope Wizard page.
2. Enter a name to create a critical security group.
3. Click Next to access the IP Address Range page. Enter the IP range which must be the same as the subnet segment configured in "Creating a critical security group."
4. Click Next to access the Lease Duration page. Set the lease duration to 10 minutes since the critical solution lease duration needs to be set to 10 minutes.
5. Click Next until you finally finish the configuration.
6. Configure the policy of the scope. The other configurations are the same as the scope policy configuration of VLAN 4094. Therefore, the details are not to be described here.
7. Right-click Policies, select Add, and enter the policy name. Click Next to access the Configure Conditions for the policy page.
8. Click Add to access the Add/Edit Condition page. Select Relay Agent Information. Set Operator to Equals. The value of the relay agent is ASCII code, starting with 30303030, followed by 30313637 for VXLAN ID. It indicates that the VXLAN ID is 167, followed by *, which is a wildcard and can match any value. The VXLAN ID value is the VXLAN ID value of the critical security group.
9. Click OK to save the settings. Then, click Next to access the policy configuration setting page. Set the Configure IP address ranges for the policy parameter to No.
10. Click Next to access the Summary page. Click Finish. After the configuration is completed, the page is shown as follows.
Creating a superscope
1. Right-click and select New Superscope to open the New Superscope Wizard page.
2. Click Next, and enter a name.
3. Click Next to access the Select Scopes page. Click the Critical security group scope and VLAN4094 scope created earlier.
4. Click Next to complete the configuration of the superscope. Then, you can view that the superscope already contains the Critical security group scope and VLAN4094 scope created earlier.
5. All configurations of the critical solution are completed. When the EIA server is faulty in future, users automatically enter the critical security group and obtain IP addresses from the critical security group if they come online.
IT resource groups
Creating an IT resource group
An IT resource group contains network resources accessible to security group users. You can control access of security group users to the server resources in the IT resource group by deploying access policies.
|
|
WARNING! The number of IP address entries is not limited to an IT resource group. As a best practice, add no more than 20 IP address entries to an IT resource group. |
1. Navigate to the Automation > Campus Network > Security Group > IT Resource Group page.
2. Click Add, enter the name, select a private network to which the resource group belongs, and click Add Address Entry to add one or more subnets as resource entries.
3. Click OK and then the system returns to the Add Resource Group page. Click OK to save the configuration. Then, you can view the added IT resource group on the IT Resource Group page.
Accessing the IT resource group
As a best practice, mount the servers of the IT resource group on the spine device, instead of on the leaf devices. This can avoid unnecessary traffic especially when multiple leaf devices exist in the network, as shown in the following figure.
The spine device uses physical interface PortA to connect to the IT resource group. PortA is set to a static AC port.
On the Automation > Campus Network > Network Strategy > Group Policies page, you can select Permit or Deny for the Default Policy setting of the private network.
· If you select Permit, all users in the private network can access the resources in the IT resource group without the need to configure any group policies. To prohibit users from accessing the IT resource group, configure a deny-mode group policy.
· If you select Deny, all users in the private network cannot access the resources in the IT resource group by default. To enable users to access the IT resource group, configure a permit-mode group policy. To prohibit users from accessing the IT resource group, you do not need to configure any group policies.
As a best practice, connect public servers in the IT resource group through spine devices and deploy the servers in the vpn-default private network, regardless of the default access policy (Permit or Deny) for the private network.
When an IT resource group is deployed in the vpn-default private network, the security groups can communicate with the IT resource group regardless of the default access policy (Permit or Deny) for the private network. To prohibit access to the IT resource group from the private network, configure and deploy a deny-mode group policy.
Accessing external networks through border devices (single-spine)
To enable online users in specific VPNs to communicate with external networks, configure a border device to redistribute external routes.
In the current software version, you can specify a spine or any leaf device as the border device.
The figure below uses a spine device as the border device.
A campus network can have one or multiple VRFs. This section takes education network as an example, which describes route configuration and deployment through the controller to enable a user PC (at 20.0.0.3) in the private network to access the external network (at 20.1.1.0/24).
Creating a border device group
To add a border device group, navigate to the Automation > Campus Network > Devices > Border Device Groups page and click Add.
1. Select a fabric, and select Egress Gateway for Position.
2. On the Device Members tab, click Add. You can select a spine or leaf device as the border device. Take an example of selecting a spine device as the border device.
3. Click the Resources for External Connectivity tab to configure the egress network resources. You can specify the address pools and VLAN pools used for the automatic allocation of network resources. The Campus Egress Address Pool and Campus Egress VLAN Pool settings must be configured in pairs for resource allocation when the campus communicates with the external network. If you do not configure these settings, you must select Manual Configuration for Egress Network Resource Allocation Mode when adding an egress gateway member in "Adding a private network (optional)." The Security Egress Address Pool, Security Egress VLAN Pool, and Firewall Management Address Pool settings are used to configure the firewall network resource allocation. For more information, see AD-Campus 6.2 Security Convergence Configuration Guide. This section describes only the campus egress gateway resource configuration.
4. Click Campus Egress Address Pool, and select an existing address pool or create a new address pool. If you choose to create a new campus egress address pool, this campus egress address pool is used for allocating local and remote IP addresses to egress network resources, and supports both IPv4 and IPv6 addresses.
5. Click Campus Egress VLAN Pool to select an existing VLAN pool or create a new VLAN pool. If you choose to create a new campus egress VLAN pool, this campus egress VLAN pool is used for allocating VLANs to egress network resources for communication between the local and remote networks. The value range for a VLAN ID is 4001 to 4050.
6. Click OK after the egress network resource configuration is completed. Then, you can view the created border device group in the border device group list.
Adding a private network (optional)
Enable VRF sharing when adding a private network for egress gateway. To enable VRF sharing, navigate to the Automation > Campus Network > Private Network page and set the Share VRF to Yes.
Adding an egress gateway
When adding an egress gateway, select the gateway mode as needed. If you select a public gateway, you need to specify VRF. When adding a gateway member, select the previously created border device group.
· Public: A public gateway can be used by multiple private networks. If a public gateway is configured, you can select the network used by the public gateway in "Adding a private network (optional)" or manually add the VRF of the public gateway.
· Private: A private gateway can be used by only one private network.
Navigate to the Automation > Campus Network > Private Network > Export Gateway page.
1. Click Add to open the Add Gateway page and configure the Gateway Mode. Click Add Gateway Member.
2. On the page that opens, select the Isolation Domain, Fabric, Border Device Group, and IP version, and set the Egress Network Resource Allocation Mode to Automatic Allocation or Manual Allocation. The default value of Output Interface IPv4 Route Priority is set to 60. You can set it as required. The smaller the value is, the higher the priority is.
¡ If you select Automatic Allocation, the controller automatically assigns VLANs, egress network segments, and remote network segments to the border device according to the settings configured in "Creating a border device group."
¡ If you select Manual Configuration, you need to select the border device and egress network and manually configure the VLAN, Egress IPv4 Address, and Remote IPv4 Address. The Remote IPv4 Address must be in the same network segment as the Egress IPv4 Address.
¡ Select external network resources. You can specify the resources that the egress network can access.
¡ Select an interface. The output interface is the interface connecting the border device to external route devices.
3. Click OK and then the system returns
to the Add Gateway page. Click the Details icon 
in the Actions
column for the gateway member to view the VLAN and network segment information
for communication between the border device and the external device.
4. Click OK to save the configuration. Then, you can view the created egress gateway in the Export Gateway list.
Associating the egress gateway with a private network
Navigate to the Automation > Campus
Network > Private Network > Private Network page,
click the Edit icon 
in the Actions
column for the private network. Configure the egress gateways for the private
network that needs to communicate with the external network.
Viewing egress gateway configuration deployed to devices
You can view the egress gateway configuration deployed by the controller on the spine device.
Configuration deployed for the public gateway mode
· VLAN settings:
#
vlan 4001
#
· VLAN interface settings:
#
interface Vlan-interface4001
description SDN_VLAN_Interface_4001
ip binding vpn-instance VPN1 //Instance name of the public gateway.
ip address 192.168.10.10 255,255,255,254
#
· VPN instance settings:
#
ip vpn-instance VPN1
description SDN_VRF_fc248f21-f522-42b0-9882-cea78ee24a1dVPN1
#
address-family ipv4
route-replicate from vpn-instance Teach protocol direct
route-replicate from vpn-instance Teach protocol bgp 100
#
· Route redistribution settings for the VPN instance of the egress gateway:
#
bgp 100
#
ip vpn-instance Teach
#
address-family ipv4 unicast
default-route imported
import-route static
network 20.0.0.0 255.255.0.0
network 20.0.0.1 255.255.255.255
network 30.0.0.0 255.255.0.0
network 30.0.0.1 255.255.255.255
#
address-family ipv6 unicast
#
· Static route settings (with the address of the remote VLAN-interface 4001 as the next hop):
#
ip route-static vpn-instance Teach 0.0.0.0 0 vpn-instance VPN1 192.168.10.11 de
scription SDN_ROUTE
#
Configuration deployed for the private gateway mode
· Campus egress VLAN:
#
vlan 4001
#
· ACL rule settings:
#
acl advanced name SDN_ACL_SC_PERMIT_ALL
description SDN_ACL_SC_PERMIT_ALL
rule 0 permit ip
#
· PBR policy settings based on campus egress VLAN:
#
policy-based-route SDN_SC_VLAN_4001 permit node 65535
if-match acl name SDN_ACL_SC_PERMIT_ALL
#
· VLAN interface settings:
#
interface Vlan-interface4001
description SDN_VLAN_Interface_4001
ip binding vpn-instance Teach
ip address 192.168.10.10 255,255,255,254
ip policy-based-route SDN_SC_VLAN_4001 Apply the PBR policy.
#
· Default and static route redistribution into BGP:
#
bgp 100
non-stop-routing
router-id 200.1.1.254
peer 200.1.1.251 as-number 100
peer 200.1.1.251 connect-interface LoopBack0
peer 200.1.1.252 as-number 100
peer 200.1.1.252 connect-interface LoopBack0
#
address-family l2vpn evpn
peer 200.1.1.251 enable
peer 200.1.1.251 reflect-client
peer 200.1.1.252 enable
peer 200.1.1.252 next-hop-local
peer 200.1.1.252 reflect-client
#
ip vpn-instance Teach
#
address-family ipv4 unicast
default-route imported
import-route static
network 20.0.0.0 255.255.0.0
network 20.0.0.1 255.255.255.255
network 30.0.0.0 255.255.0.0
network 30.0.0.1 255.255.255.255
network 40.0.0.0 255.255.0.0
network 40.0.0.1 255.255.255.255
#
---- More ----
#
· Static route settings (with the address of the remote VLAN-interface 4001 as the next hop):
ip route-static vpn-instance Teach 0.0.0.0 0 192.168.10.11 description SDN_ROUTE
Configuration deployed to the interface connected to the external network on the border device
#
interface Ten-GigabitEthernet2/2/0/36
port link-mode bridge
port link-type trunk
port trunk permit vlan all
#
Manually configuring the L3 device connected to the border device
#
vlan 4001 //VLAN in egress gateway details.
#
#
interface Ten-GigabitEthernet1/0/9
port link-type trunk
port trunk permit vlan 4001
#
# Configure an IP address for communicating with the border device. //Remote IPv4 address in egress gateway details.
interface Vlan-interface 4001
ip address 192.168.10.11 255.255.0.0
#
# Configure a default route to interoperate with the private network and the next hop is the gateway address of the external network.
ip route-static 0.0.0.0 0 20.1.1.1
#
# The route from the public network to the private network needs to be configured for each network segment that communicates with the public network, and the next hop is the border device.
#
ip route-static 20.0.0.0 16 192.168.10.10
ip route-static 30.0.0.0 16 192.168.10.10
#
Associating border devices with an external route device (dual-border)
In the current version, the controller does not support the automatic deployment of dual border egresses. You need to manually configure the two border devices. This section introduces the configuration of the dual border devices.
Configuring border 1
· Create a VPN for public egress:
#
ip vpn-instance VPNa
description SDN_VRF_GW
#
address-family ipv4
route-replicate from vpn-instance vpn1 protocol direct //Replicate the VPN routes and repeat this command if multiple private networks exist.
route-replicate from vpn-instance vpn1 protocol bgp 100
#
· Create a VLAN interface:
# VLAN 4001 is used for connection between the border device and the egress of the external network.
vlan 4001
#
#
interface Vlan-interface4001
description SDN_VLAN_Interface_4001
ip binding vpn-instance VPNa //Bind VPNa of the public gateway.
ip address 192.168.10.10 255,255,255,250
#
· Assign the interface connected to the L3 device to VLAN 4001.
#
interface Ten-GigabitEthernet2/0/1
port link-type trunk
port trunk permit vlan 4001
#
· Configure BGP to import routes:
#
bgp 100
#
ip vpn-instance vpn1
#
address-family ipv4 unicast
default-route imported //Import default routes.
preference 240 240 130
import-route static //Import static routes.
network 20.0.0.0 255.255.0.0
network 20.0.0.1 255.255.255.255
network 30.0.0.0 255.255.0.0
network 30.0.0.1 255.255.255.255
#
address-family ipv6 unicast
#
· Configure VLAN-interface 4002 for border device connection.
#
interface Vlan-interface4002
description to_border2_Interface_4002
ip binding vpn-instance VPNa //Bind VPNa of the public gateway.
ip address 192.168.10.12 255,255,255,250
#
· Assign the interface connected to the other border device to VLAN 4002.
#
interface Ten-GigabitEthernet2/0/2
port link-type trunk
port trunk permit vlan 4002
#
· Configure NQA and track settings.
# Associate an NQA operation with the uplink of the border device.
nqa entry admin border1 //admin is the username and configure it the same as the username configured when a local user is created.
type icmp-echo
destination ip 192.168.10.11 //The destination IP is the IP address of VLAN-interface 4001 on the L3 device.
frequency 100
reaction 1 checked-element probe-fail threshold-type consecutive 3 action-type trigger-only
vpn-instance vpna //VPN bound to VLAN-interface 4001.
#
# Enable the NQA operation.
nqa schedule admin border1 start-time now lifetime forever
#
# Associate an NQA operation with the links between border devices.
nqa entry admin border2 //admin is the username and configure it the same as the username configured when a local user is created.
type icmp-echo
destination ip 192.168.11.11 //The destination IP is the IP address of VLAN-interface 4002 on the L3 device.
frequency 100
reaction 2 checked-element probe-fail threshold-type consecutive 3 action-type trigger-only
vpn-instance vpna //VPN bound to VLAN-interface 4002.
#
# Enable the NQA operation.
nqa schedule admin border2 start-time now lifetime forever
#
# Configure track-NQA collaboration.
Track 1 nqa entry admin border1 reaction 1
#
#
Track 2 nqa entry admin spine1 reaction 2
#
· Configure static routes:
# Configure a static route from VPN vpn1 to the public network and associate a track entry with the static route.
ip route-static vpn-instance vpn1 0.0.0.0 0 vpn-instance vpna 192.168.10.11 track 1
#
# Configure a backup static route from VPN vpn1 to the public network. The next hop of the backup route is border 2.
ip route-static vpn-instance vpn1 0.0.0.0 0 vpn-instance vpna 192.168.11.11 track 2 preference 61
#
# Configure a static route to forward the packets from border 2 to border 1 to the public network.
ip route-static vpn-instance vpna 0.0.0.0 0 192.168.10.11
#
Configuring border 2
· Create a VPN instance:
#
ip vpn-instance VPNa
description SDN_VRF_GW
#
address-family ipv4
route-replicate from vpn-instance vpn1 protocol direct //Replicate the routes of VPN vpn1.
route-replicate from vpn-instance vpn1 protocol bgp 100
#
· # Create a VLAN interface:
#
vlan 4002
#
#
interface Vlan-interface4002
description SDN_VLAN_Interface_4002
ip binding vpn-instance VPNa //Bind VPNa of the public gateway.
ip address 192.168.11.10 255,255,255,250
#
· Assign the interface connected to the L3 device to VLAN 4002.
#
interface Ten-GigabitEthernet2/0/1
port link-type trunk
port trunk permit vlan 4002
#
· Configure BGP to import routes:
#
bgp 100
#
ip vpn-instance vpn1
#
address-family ipv4 unicast
default-route imported //Import default routes.
preference 240 240 130
import-route static //Import static routes.
network 20.0.0.0 255.255.0.0
network 20.0.0.1 255.255.255.255
network 30.0.0.0 255.255.0.0
network 30.0.0.1 255.255.255.255
#
address-family ipv6 unicast
#
· Configure VLAN-interface 4001 for connection between border devices.
#
interface Vlan-interface4001
description to_border1_Interface_4001
ip binding vpn-instance VPNa //Bind VPNa of the public gateway.
ip address 192.168.10.12 255,255,255,250
#
· Assign the interface connected to the other border device to VLAN 3.
#
interface Ten-GigabitEthernet2/0/2
port link-type trunk
port trunk permit vlan 4001
#
· Configure NQA and track settings.
# Associate an NQA operation with the uplink of the border device.
nqa entry admin border2 //admin is the username and configure it the same as the username configured when a local user is created.
type icmp-echo
destination ip 192.168.11.11 //The destination IP is the IP address of VLAN-interface 4002 on the L3 device.
frequency 100
reaction 1 checked-element probe-fail threshold-type consecutive 3 action-type trigger-only
vpn-instance vpna //VPN bound to VLAN-interface 4002.
#
# Enable the NQA operation.
nqa schedule admin border2 start-time now lifetime forever
#
# Associate an NQA operation with the links between border devices.
nqa entry admin border1 //admin is the username and configure it the same as the username configured when a local user is created.
type icmp-echo
destination ip 192.168.10.11 //The destination IP is the IP address of VLAN-interface 4001 on the L3 device.
frequency 100
reaction 2 checked-element probe-fail threshold-type consecutive 3 action-type trigger-only
vpn-instance vpna //VPN bound to VLAN-interface 4001.
#
# Enable the NQA operation.
nqa schedule admin border1 start-time now lifetime forever
#
# Configure track-NQA collaboration.
Track 1 nqa entry admin border2 reaction 1
#
#
Track 2 nqa entry admin border1 reaction 2
#
· Configure static routes:
# Configure a static route from VPN vpn1 to the public network and associate a track entry with the static route.
ip route-static vpn-instance vpn1 0.0.0.0 0 vpn-instance vpna 192.168.11.11 track 1
#
# Configure a backup static route from VPN vpn1 to the public network. The next hop of the backup route is border 2.
ip route-static vpn-instance vpn1 0.0.0.0 0 vpn-instance vpna 192.168.10.11 track 2 preference 61
#
# Configure a static route to forward the packets from border 1 to border 2 to the public network.
ip route-static vpn-instance vpna 0.0.0.0 0 192.168.11.11
#
Configuring the L3 device connected to the border devices
· Create a VLAN interface:
#
vlan 4001
#
#
interface Vlan-interface4001
description SDN_VLAN_Interface_4001
ip address 192.168.10.11 255,255,255,254
#
#
vlan 4002
#
#
interface Vlan-interface4002
ip address 192.168.11.11 255,255,255,254
#
· Assign the interface connected to border 1 to VLAN 4001.
#
interface Ten-GigabitEthernet2/0/1
port link-type trunk
port trunk permit vlan 4001
#
· Assign the interface connected to border 2 to VLAN 4002.
#
interface Ten-GigabitEthernet2/0/2
port link-type trunk
port trunk permit vlan 4002
#
· Configure static routes:
# Configure a static route from the L3 device to the public network. The next hop is the public network gateway.
ip route-static 0.0.0.0 0 21.1.0.1
#
# Configure static routes from the public network to each private network that will communicate with the public network. The next hops of these routes are border 1 and border 2.
#
ip route-static 20.0.0.0 16 192.168.10.10
#
ip route-static 20.0.0.0 16 192.168.11.10
#
ip route-static 30.0.0.0 16 192.168.10.10
#
ip route-static 30.0.0.0 16 192.168.11.10
#
Multicast configuration
Both the controllers and the devices support the configuration of Layer 2 multicast and Layer 3 multicast, which enable the transmission of traffic from a single point to multiple points.
Multicast service configuration
Layer 2 multicast
Enabling Layer 2 multicast globally
To configure a Layer 2 multicast network, you must enable multicast globally and set the Multicast Network to On.
Navigate to the Automation > Campus
Network > Fabrics page, and click the Settings icon 
in the Actions column for the
fabric. Click the Settings tab, select On for Multicast
Network, and click OK to save the configuration. Then, the system
will deploy the IGMP snooping configuration to spine and leaf devices in the
fabric globally.
Configuring multicast services
You can configure multicast services as required.
Navigate to the Automation > Campus Network > Application Policy > Multicast > Layer 2 Multicast page and click Add. Then, configure the multicast services as required.
Parameters:
· Private Network: Select the private network that needs to enable multicast.
· Layer 2 Network Domain: Select the Layer 2 network domain that needs to enable multicast. When multicast is enabled, IGMP snooping will be enabled automatically in the corresponding VSI of the Layer 2 network domain.
· IGMP Snooping Version: Select an IGMP snooping version.
· IGMP Snooping Querier: Enabling this feature to automatically configure the querier function at the VSI corresponding to the Layer 2 network domain of the spine device. If the actual environment has a separate Layer 3 multicast device or querier, this feature is optional.
· IGMP Snooping Proxy: Enable IGMP snooping proxy on leaf devices for them to send reports and leave packets to upstream devices on behalf of downstream hosts. This feature can reduce the number of IGMP reports and leave packets received by upstream devices.
· IGMP Snooping Drop Unknown: This feature enables a Layer 2 device to forward unknown multicast data packets only to the router port instead of flooding them in a VXLAN. If the device does not have a router port, unknown multicast data packets will be dropped.
You can view the configuration of a VSI:
[Leaf7503-vsi-vsi3]display this
#
vsi vsi3
description SDN_VSI_3
gateway vsi-interface 3
statistics enable
ipv6 nd snooping enable global
ipv6 nd snooping enable link-local
flooding disable all all-direction
vxlan 3
evpn encapsulation vxlan
mac-advertising disable
arp mac-learning disable
nd mac-learning disable
route-distinguisher auto
vpn-target auto export-extcommunity
vpn-target auto import-extcommunity
igmp-snooping enable
igmp-snooping drop-unknown //Discard unknown multicast data packets.
dhcp snooping binding record
ipv6 dhcp snooping binding record
#
Configuring an AC interface on the spine device
Configure a static AC on the interface where the spine device connects to the egress router, and multicast packets are mapped to VXLANs through VLANs.
1. After configuring the Layer 2 network
domain, navigate to the Automation > Campus Network > Fabrics
page, and click the Settings icon 
in the Actions
column for the fabric.
2. Click the General Policy Groups
tab, click the Edit icon
in the Actions column for AP Non-Direct Access Interface
Group for Leafs.
3. Select the Member tab and click Add to add the interface to AP Non-Direct Access Interface Group for Leafs. The controller will automatically deliver the Ethernet service instance corresponding to the security group.
After the configuration is completed and endpoints join the multicast group, the endpoints can receive multicast traffic from the multicast source normally.
Layer 3 multicast
By binding a private network to a Layer 3 multicast network and configuring the RP address, MDT, PIM protocol and policy, and IGMP protocol and policy, Layer 3 multicast traffic can be exchanged in the same VPN.
Layer 3 multicast is based on Layer 2 multicast. The following configurations are required:
1. Navigate to the Automation > Campus Network > Application Policy > Multicast > Layer 3 Multicast page.
2. Click Add and configure the following parameters:
¡ Name: Enter a name for the Layer 3 multicast network.
¡ Distributed RP: In EVPN VXLAN networking, when multicast adopts PIM-SM mode, each leaf device in the network acts as the RP of the private network for multicast data forwarding.
¡ Private Network: Bind the private network to deploy the configuration.
You can view that the following configuration has been deployed to the leaf device:
#
pim vpn-instance Teach //Corresponding private network instance.
c-bsr 7.7.7.7
c-rp 7.7.7.7
#
MDT tab
The MDT tab allows you to specify parameters such as the default group, source port, and data group. The value range for the data group mask varies by device model.
· Default Group: The default group is an independent multicast group assigned by the multicast VPN on the public network, which is used to realize the transmission of private multicast data on the public network.
· Source Port: Specify the MVXLAN source interface. The MVXLAN source interface must be the same as the source interface used to establish BGP peer relationships. Otherwise, it cannot get the correct routing information. At present, only a loopback interface can be specified.
· Data Group: When this parameter is configured, the device will select the least referenced address from the data group to replace the default group to enable the transmission of the private multicast data on the public network.
· ACL: Configure it only if the data group is configured. When an ACL is configured, only traffic that matches the ACL will be transmitted on the public network by using the data group. Traffic that does not match the ACL is transmitted on the public network by using the default group.
· Switchover Delay (sec): The delay time for switching from the default group to the data group, which can be configured only if the data group is configured.
The following configuration can be viewed on the device:
[Spine10510]multicast-vpn vxlan vpn-instance Teach mode mdt
[Spine10510-mvxlan-vpn-instance-Teach]dis this
#
multicast-vpn vxlan vpn-instance Teach mode mdt //
address-family ipv4
source LoopBack0 //Source interface.
default-group 225.1.0.1 //Default group IP.
data-group 230.1.0.0 255.255.255.252 name SDN_ACL_MULTICAST_test //Deployed only when the data group and ACL have been configured.
data-delay 3
#
PIM protocol tab
· Protocol Type: Options include PIM-SM and PIM-SSM.
· Hello Interval (sec): After this parameter is configured, each interface running PIM protocol on the device sends hello packets to all PIM devices in this segment periodically to discover PIM neighbors and maintain the PIM neighbor relationship among devices.
The following configuration can be viewed on the device:
[Leaf7503]int Vsi-interface 3 //The VSI interface enabled in the Layer 2 network domain.
[Leaf7503-Vsi-interface3]dis th
#
interface Vsi-interface3
description SDN_VSI_Interface_3
ip binding vpn-instance Teach
ip address 20.0.0.1 255.255.0.0
pim sm //Protocol mode.
pim hello-option holdtime 105
pim hello-option lan-delay 500
pim hello-option override-interval 2500
pim holdtime join-prune 210
pim timer hello 30 //Hello packet sending frequency.
pim timer join-prune 60
pim distributed-dr
#
PIM policy tab
· Neighbor Policy: Ensure the security and normal traffic forwarding of a PIM domain by configuring a neighbor policy.
· Join Policy: By configuring a Join policy, you can prevent illegal devices from joining the PIM domain.
IGMP protocol tab
· IGMP Version: There are three versions of IGMP protocol, namely, IGMPv1, IGMPv2, and IGMPv3.
· SSM Mapping: When PIM-SSM mode with IGMPv1 and IGMPv2 is selected, since IGMPv1 and IGMPv2 do not support multicast receivers joining multicast groups, it is necessary to configure SSM static mapping rules on the device to achieve full PIM-SSM mode multicast forwarding.
· Querier's Robustness Variable: The querier's robustness variable is the number of packet retransmissions set to compensate for possible network packet loss.
You can view the following configuration under the VSI interface with multicast network enabled:
[Leaf7503]int Vsi-interface 3 //The VSI interface enabled with multicast in the Layer 2 network domain.
[Leaf7503-Vsi-interface3]display this
#
interface Vsi-interface3
description SDN_VSI_Interface_3
ip binding vpn-instance Teach
ip address 20.0.0.1 255.255.0.0
pim sm
pim hello-option holdtime 105
pim hello-option lan-delay 500
pim hello-option override-interval 2500
pim holdtime join-prune 210
pim timer hello 30
pim timer join-prune 60
pim distributed-dr
igmp enable
igmp other-querier-present-interval 255
igmp query-interval 125
igmp max-response-time 10
igmp robust-count 2
igmp last-member-query-interval 1
#
IGMP policy tab
Multicast Group Policy: Configure a multicast group filter on an interface to limit the multicast groups that hosts on that interface can join.
Protocol-specific multicast packet filtering
To avoid the traffic impact of specific protocol multicast packets on the device, filter out specific multicast group addresses on the device.
#
acl number 3000
rule 0 deny ip destination 239.255.255.250 0
rule 5 permit ip
#
# Configure a source policy in PIM view.
#
pim vpn-instance Teach
source-policy 3000
#
After all the above configurations are completed, Layer 3 multicast traffic can be transmitted under the same VPN instance.
|
|
WARNING! Only one private network can be bound to a Layer 3 multicast network. |
Configuration of multicast service when the spine is connected to a multicast source through a router
If the multicast source is connected to the spine through an external router, the external router needs to be configured for the transmission of the Layer 3 multicast traffic, as shown in the figure below.
Configuring an egress gateway
Before configuring settings related to multicast services, you need to configure the egress gateway. For information about configuring the egress gateway, see "Creating a border device group", "Adding an egress gateway" and "Viewing egress gateway configuration deployed to device." The Layer 3 multicast device acts as the external route device connected to the border device.
|
|
WARNING! Select an exclusive gateway when using the egress gateway in the multicast scenario. |
Manual configuration of the interface for connection between border and external network
#
interface Ten-GigabitEthernet2/2/0/36
port link-mode bridge
port link-type trunk
port trunk permit vlan all //Configuration deployed when the output interface is configured in the egress gateway.
#
#
interface Vlan-interface4001
description SDN_VLAN_Interface_4001
ip binding vpn-instance Teach
ip address 192.168.10.10 255,255,255,254
pim sm //Enable PIM SM manually on the VLAN interface.
ip policy-based-route SDN_SC_VLAN_4001
#
#
pim vpn-instance Teach
static-rp 192.168.10.11 //Manually configure a static RP and the address is the IP address of VLAN-interface 4001 on the L3 multicast device.
#
Manual configuration on the Layer 3 multicast device connected to the border device
#
vlan 4001 //VLAN in egress gateway details.
#
# Configure an IP address for communicating with the border device. //Remote IPv4 address in egress gateway details.
interface Vlan-interface 4001
ip address 192.168.10.11 255,255,255,254
pim sm
#
Configure a default route to interoperate with the private network.
ip route-static 0.0.0.0 0 192.168.10.10 //The next hop is the address of the egress local IPv4 in the egress gateway details.
Egress routers (devices supporting Layer 3 multicast) are globally configured with multicast routing:
#
multicast routing
#
Enable IGMP and PIM (PIM SM or PIM DM) on the VLAN interface. Take PIM SM as an example:
#
vlan 10
#
#
interface Vlan-interface10 //VLAN interconnecting with the multicast source.
ip address 10.1.0.1 255.255.255.0
pim sm //Or PIM DM.
#
#
#
Globally specify the RP address and configure the RPF check:
#
pim
static-rp 192.168.10.11
#
#
ip rpf-route-static 201.0.0.0 16 192.168.10.11
ip rpf-route-static 202.0.0.0 16 192.168.10.11 //Configure multicast static routes. Otherwise, RPF check failure might cause the multicast forwarding table to fail to be established. The addresses 201.0.0.0 and 202.0.0.0 are the user service segments, and 192.168.10.11 is the address of VLAN-interface 4001.
#
Configurations related to the multicast source interconnect interface and spine interconnect interface:
#
interface Ten-GigabitEthernet1/0/9 //Interface connected to the spine.
port link-mode bridge
port link-type trunk
port trunk permit vlan 1 4001
#
interface Ten-GigabitEthernet1/0/10 //Interface connected to the multicast source.
port link-mode bridge
port access vlan 10
#
QoS
QoS is short for Quality of Service. Network resources are always limited. When ensuring the quality of a certain type of service, there may be a compromise for the QoS of other services. Therefore, network managers need to make reasonable planning and allocation of network resources according to the characteristics of various services so that network resources can be used efficiently.
Users can control the allocation of network resources by configuring a QoS policy. It consists of:
· Class: Defines the rules for identifying packets.
· Traffic behavior: Defines a set of QoS actions to be taken on the packets identified by the class.
By associating a class with a traffic behavior, the QoS policy performs the actions defined in the traffic behavior for packets that match the classification rules.
|
|
WARNING! · In the current software version, the S5560X switch series and S6520X switch series do not support concurrent use of QoS and group policies. · At present, QoS does not support east-west traffic control. · The S5130EI and S5130HI switches do not support QoS-based DSCP remark. |
Enabling QoS globally
To enable QoS in a fabric, navigate to the Automation
> Campus Network > Fabrics page, and click the Settings
icon 
in the Actions column for the
fabric. Click the Settings tab, set the QoS parameter to On,
and click OK to save the configuration.
The following commands are deployed to all the devices in the fabric:
· Command globally deployed to spine and leaf devices:
#
qos trust tunnel-dscp
#
· Command deployed to the non-interconnected interfaces of spine, leaf, and access devices:
#
qos priority dscp 0
#
· Commands deployed to the interconnected interfaces of spine, leaf, and access devices:
#
qos trust dscp
qos wrr weight
qos wrr af4 group sp
qos wrr ef group sp
qos wrr cs6 group sp
qos wrr cs7 group sp
#
Adding an application classifier
1. Navigate to the Automation > Campus Network > Applications > QoS > Application Classifiers page and click Add.
2. Enter the name of the application classifier and click Add to configure the rule information corresponding to the application classifier. Configure the parameters of Name, Protocol, Source IP Address, Destination IP Address, Source Port, and Destination Port. All the packets that match this rule are automatically classified as one class.
3. Take the following rule as an example. All packets matching the source IP segment of 20.0.0.0/16 and destination IP segment of 225.0.0.1/32 are automatically classified as one class.
4. Click OK to return to the Add Application Classifier page. Click OK to save the configuration and return to the application classifier list. You can view the application classifier you just configured. The state of the application classifier is Ready when it is not referenced. Besides, you can view, edit, or delete the application classifier.
Adding an application policy
After configuring an application classifier, you need to configure an application policy to determine the action to be taken on the application classifier.
1. Navigate to the Automation > Campus Network > Applications > QoS > Application Policies page and click Add.
2. Enter the policy name and you can open or close the Dynamic Match setting. When it is opened, you do not need to configure Network Ranges since the packets corresponding to the application set are automatically identified and the traffic assurance policy is performed. By default, it is set to Close. Then, click Add on the Network Ranges tab and you can select Device or Interface in the pop-up drop-down box.
3. On the device or interface selection page, you can select devices or interfaces to which the application policy is deployed. Only the devices or interfaces to which the policy is applied will match the application classifier and then execute the policy action.
4. After the selection of devices is confirmed, click the Traffic Policies tab and click Add.
Parameters on this page:
¡ Name: Enter a policy name that is not the same as an existing traffic policy.
¡ Application Classifier: Select the application classifier for which you want to implement the traffic policy.
¡ Direction: Options include IN, OUT, BOTH, which indicates inbound direction, outbound direction, and both inbound and outbound directions, respectively. As a best practice, select IN to classify packets and take the action on matching packets in the inbound direction.
|
|
WARNING! The current solution needs to configure a QoS policy for packets matching in the inbound direction. |
¡ Block Traffic: By default, it is set to Off. If it is enabled, the traffic of the matched application classifier will be blocked and the application priority and traffic rate limiting cannot be configured.
¡ Apply Priority: Priorities vary with different applications. The device sends packets to different queues according to the priority of the packets. Generally, there are 8 queues (0-7). In the SP method, the higher the value is, the higher the priority is. The device sends packets from highest to lowest priority. That is, send packets in the lower priority queue when the higher priority queue is empty. In the WRR method, a weight is assigned to each priority queue. The device polls each queue according to its weight.
The following table lists the queue values for different applications: Queues 6 and 7 are reserved.
Table 9 Application priority
|
Application name |
Queue |
|
Network Control (Network control plane) |
5 |
|
Telephony (IP telephony service) |
5 |
|
Signaling (Broadcast TV, video surveillance) |
5 |
|
Multimedia Conferencing (Desktop multimedia conferencing) |
4 |
|
Real-time Interactive (Video conferencing and high-definition video) |
4 |
|
Multimedia Streaming (Streaming video and audio on demand) |
3 |
|
Broadcast Video (Broadcast TV & live events) |
3 |
|
Low-Latency Data (Client/server transactions Web-based ordering) |
1 |
|
OAM (OAM&P) |
1 |
|
High-Throughput Data (Store and forward applications) |
0 |
|
Standard (Undifferentiated applications) |
2 |
|
Low-Priority Data (Any flow that has no BW assurance) |
0 |
If you need to ensure the scheduling with certain priority for certain traffic, perform the configuration according to the following diagram: Select the application classifier corresponding to the traffic. Choose IN for the direction, and choose Network Control (Network control plane) for the application priority.
¡ Rate Limiting: A parameter configures the rate limit of the traffic. By default, it is set to Off. You can enable it as needed. When enabling rate limiting, you need to configure traffic policing parameters, including:
- CIR (kbit/s): It indicates the committed information rate. It is the average traffic rate in kbps.
- PIR (kbit/s): It indicates the peak information rate in kbps. The unit of PIR and CIR must be the same.
- CBS (byte): Committed burst size, in bytes.
- EBS (byte): Excess burst size, in bytes.
5. Click OK to return to the Add Application Policy page, and then click OK again to return to the Application Policy page. You can view the application policy you just added to the list. You can view, edit, or delete the policy.
6. Click the Application Classifiers tab and you can see that the state of the application classifier referenced in the application policy is switched to In use. The application classifier in In use state is not allowed to be deleted.
Viewing the configuration deployed to a device
· If the configuration is deployed to a device, the following commands can be viewed on the device:
<Leaf>dis current-configuration | in traffic
traffic classifier SDN4_UEF4NPODIEGU5HZQU2XL4E2MGY operator and
traffic behavior SDN_TOEWO6M6MOKCVBHITHF3TWSGPE
<Leaf>dis current-configuration | begin traffic
traffic classifier SDN4_UEF4NPODIEGU5HZQU2XL4E2MGY operator and //Traffic classifier.
if-match acl name SDN_SP_ACL_UEF4NPODIEGU5HZQU2XL4E2MGY
#
traffic behavior SDN_TOEWO6M6MOKCVBHITHF3TWSGPE //Traffic behavior.
remark dscp ef
remark dot1p 5
car cir 800 cbs 50176 pir 800 ebs 50176 green pass red discard yellow pass //Deployed when rate limiting is configured.
#
qos policy SDN_IN_qos
classifier SDN4_UEF4NPODIEGU5HZQU2XL4E2MGY behavior SDN_TOEWO6M6MOKCVBHITHF3TWS
GPE
#
· If the configuration is deployed to an interface, the following commands can be viewed on the interface:
[Leaf]interface Ten-GigabitEthernet1/2/0/16
port link-mode bridge
port link-type trunk
port trunk permit vlan 1 3504 3508 4002
qos apply policy SDN_OUT_test outbound (If select BOTH for direction in the traffic policy, two application policies will be deployed.)
#
return
[Leaf-Ten-GigabitEthernet1/2/0/16]
//Label the packets that match the policy and add the packets to the queue specified in the policy at the outbound direction. //
<Leaf11>display qos queue-statistics interface Ten-GigabitEthernet 5/0/4 outband
Interface: Ten-GigabitEthernet5/0/4 //Packet outbound interface.
Direction: outbound
Queue 0
Forwarded: 0 packets, 0 bytes, 0 pps, 0 bps
Dropped: 0 packets, 0 bytes
Current queue length: 0 packets
Queue 1
Forwarded: 0 packets, 0 bytes, 0 pps, 0 bps
Dropped: 0 packets, 0 bytes
Current queue length: 0 packets
Queue 2
Forwarded: 189 packets, 56511 bytes, 0 pps, 0 bps
Dropped: 0 packets, 0 bytes
Current queue length: 0 packets
Queue 3
Forwarded: 0 packets, 0 bytes, 0 pps, 0 bps
Dropped: 0 packets, 0 bytes
Current queue length: 0 packets
Queue 4
Forwarded: 0 packets, 0 bytes, 0 pps, 0 bps
Dropped: 0 packets, 0 bytes
Current queue length: 0 packets
Queue 5
Forwarded: 64728993 packets, 4265970097 bytes, 1503210 pps, 769643520 bps
Dropped: 64671339 packets, 4261944441 bytes
Current queue length: 0 packets
---- More ----
Queue 6
Forwarded: 0 packets, 0 bytes, 0 pps, 0 bps
Dropped: 0 packets, 0 bytes
Current queue length: 0 packets
Queue 7
Forwarded: 1 packets, 149 bytes, 0 pps, 0 bps
Restrictions and guidelines for leaf-access network models
Single leaf scenario
In the single leaf scenario, only one leaf device exists in the whole network. All endpoints are connected to this leaf device through access switches. The servers such as SeerEngine-Campus and DHCP server are also directly connected to this leaf device. You must add this leaf device to the leaf device group. The leaf configuration on this leaf device is different from the traditional leaf configuration. This section covers only the different settings. For information about the other settings, see the standard network models and their configurations described in the previous chapters.
· As the leaf device is enabled with DHCP snooping (the spine device is not enabled with DHCP snooping), you must specify the Ethernet service instance connected to the DHCP server as a DHCP snooping trusted port.
#
interface Ten-GigabitEthernet2/2/0/5
port link-mode bridge
port link-type trunk
port trunk permit vlan 1 4094
service-instance 4094
encapsulation s-vid 4094
xconnect vsi vxlan4094
dhcp snooping trust
#
· As only one leaf device exists in the network, you do not need to establish BGP peers for the leaf device. However, if a custom private network exists, you must configure inter-VPN route redistribution. The following methods can be used:
¡ Method 1:
#
bgp 100
non-stop-routing
address-family l2vpn evpn
#
ip vpn-instance vpn-default
#
address-family ipv4 unicast
import-route static
import-route direct
#
#
ip vpn-instance Teach
#
address-family ipv4 unicast
import-route static
import-route direct
#
#
¡ Method 2:
#
ip vpn-instance vpn-default
route-distinguisher 1:1
vpn-target 1:1 1:4 import-extcommunity
vpn-target 1:1 export-extcommunity
#
address-family ipv4
route-replicate from vpn-instance vpn1 protocol direct //Import the direct routes in VPN instance vpn1 to VPN instance vpn-default. Repeat this command if multiple VPN instances exist.
#
address-family evpn
vpn-target 1:1 1:4 import-extcommunity
vpn-target 1:1 export-extcommunity
#
ip vpn-instance Teach
route-distinguisher 1:4
vpn-target 1:1 1:4 import-extcommunity
vpn-target 1:4 export-extcommunity
#
address-family ipv4
route-replicate from vpn-instance vpn-default protocol direct
//You only need to import the direct routes in VPN instance vpn-default. Configure similar settings If communication to other VPN instances is required.
#
address-family evpn
vpn-target 1:1 1:4 import-extcommunity
vpn-target 1:4 export-extcommunity
#
· On the leaf device, configure the following spanning tree settings:
#
stp ignored vlan 2 to 4094
stp global enable
stp root primary
#
# On the leaf downlink interfaces, enable TC-BPDU transmission restriction.
stp tc-restriction
#
Multi-leaf scenario
The multi-leaf scenario exists in a network that has multiple campuses. In this scenario, you must also add the core devices (also act as RRs) connected to the servers such as SeerEngine-Campus to the leaf device group. Configure leaf settings on the core devices in the same way the leaf settings are configured on other leaf devices.
To ensure correct running of features in the network, you need to add additional configuration to all the leaf devices. This section covers only the additional configuration. For information about the other settings, see the standard network models and their configurations described in the previous chapters.
#
interface Vsi-interface4094
ip binding vpn-instance vpn-default
ip address 130.0.3.1 255.255.255.0
local-proxy-arp enable //Configure the ARP proxy.
#
The additional configuration is as follows:
· As a leaf device is enabled with DHCP snooping (a spine device is not enabled with DHCP snooping), you must specify the Ethernet service instance connected to the DHCP server as a DHCP snooping trusted port.
#
interface Ten-GigabitEthernet2/2/0/5
port link-mode bridge
port link-type trunk
port trunk permit vlan 1 4094
service-instance 4094
encapsulation s-vid 4094
xconnect vsi vxlan4094
dhcp snooping trust
#
· Endpoints (custom VPN instances) might exist on the core devices connected to the servers. They need to communicate with the servers in VPN instance vpn-default or the external network. You must configure BGP to import direct routes to the VPN instances on the core devices connected to the servers.
#
bgp 100
#
ip vpn-instance vpn-default
#
address-family ipv4 unicast
import-route direct
#
ip vpn-instance vpn1
#
address-family ipv4 unicast
import-route direct
#
· Add the following settings to each leaf device:
#
stp ignored vlan 2 to 4094
stp global enable
stp root primary
#
# On the leaf downlink interfaces, enable TC-BPDU transmission restriction.
stp tc-restriction
#
Configuring redundant dual-spine uplinks
Deploy redundant dual-spine uplinks for redundancy protection and traffic load balancing on spine devices. Figure 28 shows a network diagram for redundant dual-spine uplinks.
Figure 28 Redundant dual-spine uplinks
Table 10 IP planning for interfaces connecting the spine devices to the Layer 3 switch
|
Device |
Interface |
IP address |
Connected device |
Connected interface |
IP address |
|
Spine 1 |
TE2/0/31 |
10.0.0.11 |
Layer 3 switch |
TE1/0/49 |
10.0.0.1 |
|
Spine 2 |
TE2/0/31 |
11.0.0.12 |
Layer 3 switch |
TE1/0/50 |
11.0.0.1 |
|
Spine 1 |
Aggr1 (VLAN 10 and VLAN 11) |
10.0.0.11 11.0.0.11 |
Spine 2 |
Aggr1 (VLAN 10 and VLAN 11) |
10.0.0.12 11.0.0.12 |
The redundant dual-spine uplinks are connected to the Layer 3 switch. You can configure default ECMP routes destined for the dual spine devices on the Layer 3 switch. This section covers only the special configuration needed for redundant dual-spine uplink deployment. For information about the other configuration, see "Manual incorporation."
Configuring the Layer 3 switch
# Create VLAN 10 and VLAN 11.
#
vlan 10 to 11
#
# Configure the spanning tree feature.
#
stp global enable
#
# Enable VLAN Ignore for VLAN 10 and VLAN 11. The VLANs are connected to the spine devices.
stp ignored vlan 10 to 11
#
# Configure VLAN-interface 10 and VLAN-interface 11.
#
interface Vlan-interface10
ip address 10.0.0.1 255.255.255.0
#
interface Vlan-interface11
ip address 11.0.0.1 255.255.255.0
#
# Assign the interface connected to Spine 1 to VLAN 10.
#
interface Ten-GigabitEthernet1/0/49
port link-mode bridge
port link-type trunk
undo port trunk permit vlan 1
port trunk permit vlan 10 //Determine whether to add the interface to VLAN 1 according to the actual networking.
#
# Assign the interface connected to Spine 2 to VLAN 11.
#
interface Ten-GigabitEthernet1/0/50
port link-mode bridge
port link-type trunk
undo port trunk permit vlan 1
port trunk permit vlan 11 // Determine whether to add the interface to VLAN 1 according to the actual networking.
#
# Configure track.
#
track 1 interface Ten-GigabitEthernet1/0/49 physical
track 2 interface Ten-GigabitEthernet1/0/50 physical
#
# Configure two default routes with the next hops being the IP addresses of Spine 1 and Spine 2.
#
ip route-static 0.0.0.0 0 10.0.0.11 track 1
ip route-static 0.0.0.0 0 11.0.0.12 track 2
#
# Add 32-bit host routes destined for the spine devices. The routes protect traffic forwarding in case of inter-spine link failures or spine device failures.
#
ip route-static 130.1.0.101 32 10.0.0.11 //130.1.0.101 is the address of VSI-interface 4094 on Spine 1.
ip route-static 130.1.0.102 32 11.0.0.12 //130.1.0.102 is the address of VSI-interface 4094 on Spine 2.
#
Connecting Spine 1 to the Layer 3 switch
# Configure the spanning tree settings.
#
stp instance 0 root primary
stp ignored vlan 2 to 4094
stp global enable
#
# Create VLAN 10.
#
vlan 10
#
# Configure VLAN-interface 10 and associate VPN instance vpn-default with the VLAN interface.
#
interface Vlan-interface10
ip binding vpn-instance vpn-default
ip address 10.0.0.11 255.255.255.0
#
# Assign the interface connected to the Layer 3 switch to VLAN 10.
#
interface Ten-GigabitEthernet1/0/31
port link-mode bridge
port link-type trunk
undo port trunk permit vlan 1
port trunk permit vlan 10 // Determine whether to add the interface to VLAN 1 according to the actual networking.
#
# Configure static routes destined for servers with the next hops being the IP address of the Layer 3 switch.
#
ip route-static vpn-instance vpn-default 100.1.0.0 24 10.0.0.1
ip route-static vpn-instance vpn-default 110.1.0.0 24 11.0.0.1
#
Connecting Spine 2 to the Layer 3 switch
# Configure the spanning tree settings.
#
stp instance 0 root secondary
stp ignored vlan 2 to 4094
stp global enable
#
# Create VLAN 11.
#
vlan 11
#
# Configure VLAN-interface 11 and associate VPN instance vpn-default with the VLAN interface.
#
interface Vlan-interface11
ip binding vpn-instance vpn-default
ip address 11.0.0.12 255.255.255.0
#
# Assign the interface connected to the Layer 3 switch to VLAN 11.
#
interface Ten-GigabitEthernet1/0/31
port link-mode bridge
port link-type trunk
undo port trunk permit vlan 1
port trunk permit vlan 11 // Determine whether to add the interface to VLAN 1 according to the actual networking.
#
# Configure static routes destined for servers with the next hops being the IP address of the Layer 3 switch.
#
ip route-static vpn-instance vpn-default 100.1.0.0 24 11.0.0.1
ip route-static vpn-instance vpn-default 110.1.0.0 24 11.0.0.1
#
Connecting Spine 1 and Spine 2
Configuring Spine 1
# Configure fast rerouting.
#
ip route-static fast-reroute auto
#
# Create VLAN 11.
#
vlan 11
#
# Create VLAN-interface 11.
#
interface Vlan-interface11
ip binding vpn-instance vpn-default
ip address 11.0.0.11 255.255.255.0
#
# Create VLAN 3 for communicating with the underlay network.
#
vlan 3
#
# Create VLAN-interface 3.
#
interface Vlan-interface3
ip address 3.0.0.1 255.255.255.0
ospf network-type p2p
ospf 1 area 0.0.0.0
#
# Create an aggregation group.
#
interface Bridge-Aggregation1
link-aggregation mode dynamic
#
# Add interfaces to the aggregation group.
#
interface Ten-GigabitEthernet1/0/30
port link-mode bridge
port link-aggregation group 1
#
interface Ten-GigabitEthernet2/0/30
port link-mode bridge
port link-aggregation group 1
#
# Add the aggregate interface to VLAN 10, VLAN 11, and VLAN 3.
#
interface Bridge-Aggregation1
port link-type trunk
undo port trunk permit vlan 1 // Determine whether to add the interface to VLAN 1 according to the actual networking.
port trunk permit vlan 3 10 to 11
link-aggregation mode dynamic
#
//Since fast rerouting has been configured, the following NQA-track collaboration configuration is optional.
# Configure track for quick inter-leaf link failure detection and link switchover.
#
track 1 interface Bridge-Aggregation1 physical
#
# Configure a static route destined for VXLAN 4094 on Spine 2 (with the next hop being the IP address of VLAN-interface 10 or VLAN-interface 11).
#
ip route-static vpn-instance vpn-default 130.1.0.102 32 11.0.0.12 track 1
#
# Configure NQA-track collaboration and static routes destined for the server cluster. The next hops of the static routes are the gateway IP addresses of VLAN 10 and VLAN 11 on the Layer 3 switch. Associate the static routes with track entries for quick link failure detection and link switchover.
#
nqa entry admin server1
type icmp-echo
destination ip 10.0.0.1
frequency 100
reaction 3 checked-element probe-fail threshold-type consecutive 3 action-type trigger-only
vpn-instance vpn-default
#
nqa entry admin server2
type icmp-echo
destination ip 11.0.0.1
frequency 100
reaction 4 checked-element probe-fail threshold-type consecutive 3 action-type trigger-only
vpn-instance vpn-default
#
nqa schedule admin server1 start-time now lifetime forever
nqa schedule admin server2 start-time now lifetime forever
#
track 3 nqa entry admin server1 reaction 3
track 4 nqa entry admin server2 reaction 4
#
#
ip route-static vpn-instance vpn-default 100.1.0.0 24 10.0.0.1 track 3
ip route-static vpn-instance vpn-default 100.1.0.0 24 11.0.0.1 track 4 preference 61
ip route-static vpn-instance vpn-default 110.1.0.0 24 10.0.0.1 track 3
ip route-static vpn-instance vpn-default 110.1.0.0 24 11.0.0.1 track 4 preference 61
//Configuration of static routes when NQA-track collaboration is not configured.
#
ip route-static vpn-instance vpn-default 100.1.0.0 24 10.0.0.1
ip route-static vpn-instance vpn-default 100.1.0.0 24 11.0.0.1 preference 61
ip route-static vpn-instance vpn-default 110.1.0.0 24 10.0.0.1
ip route-static vpn-instance vpn-default 110.1.0.0 24 11.0.0.1 preference 61
#
#
# Configure BGP to import static routes to VPN instance vpn-default.
#
bgp 100
#
ip vpn-instance vpn-default
#
address-family ipv4 unicast
import-route direct
import-route static
#
Configuring Spine 2
# Configure fast rerouting.
#
ip route-static fast-reroute auto
#
# Create VLAN 10.
#
vlan 10
#
# Create VLAN-interface 10.
#
interface Vlan-interface11
ip binding vpn-instance vpn-default
ip address 10.0.0.12 255.255.255.0
#
# Create VLAN 3 for communicating with the underlay network.
#
vlan 3
#
# Create VLAN-interface 3.
#
interface Vlan-interface3
ip address 3.0.0.2 255.255.255.0
ospf network-type p2p
ospf 1 area 0.0.0.0
#
# Create an aggregation group.
#
interface Bridge-Aggregation1
link-aggregation mode dynamic
#
# Add interfaces to the aggregation group.
#
interface Ten-GigabitEthernet1/0/30
port link-mode bridge
port link-aggregation group 1
#
interface Ten-GigabitEthernet2/0/30
port link-mode bridge
port link-aggregation group 1
#
# Add the aggregate interface to VLAN 10, VLAN 11, and VLAN 3.
#
interface Bridge-Aggregation1
port link-type trunk
undo port trunk permit vlan 1 // Determine whether to add the interface to VLAN 1 according to the actual networking.
port trunk permit vlan 3 10 to 11
link-aggregation mode dynamic
#
//Since fast rerouting has been configured, the following NQA-track collaboration configuration is optional.
# Configure track for quick inter-leaf link failure detection and link switchover.
#
track 1 interface Bridge-Aggregation1 physical
#
# Configure a static route destined for VXLAN 4094 on Spine 1 (with the next hop being the IP address of VLAN-interface 10 or VLAN-interface 11).
#
ip route-static vpn-instance vpn-default 130.1.0.101 32 11.0.0.11 track 1
#
# Configure NQA-track collaboration and static routes destined for the server cluster. The next hops of the static routes are the gateway IP addresses of VLAN 10 and VLAN 11 on the Layer 3 switch. Associate the static routes with track entries for quick link failure detection and link switchover.
#
nqa entry admin server1
type icmp-echo
destination ip 10.0.0.1
frequency 100
reaction 3 checked-element probe-fail threshold-type consecutive 3 action-type trigger-only
vpn-instance vpn-default
#
nqa entry admin server2
type icmp-echo
destination ip 11.0.0.1
frequency 100
reaction 4 checked-element probe-fail threshold-type consecutive 3 action-type trigger-only
vpn-instance vpn-default
#
nqa schedule admin server1 start-time now lifetime forever
nqa schedule admin server2 start-time now lifetime forever
#
#
track 3 nqa entry admin server1 reaction 3
rack 4 nqa entry admin server2 reaction 4
#
ip route-static vpn-instance vpn-default 100.1.0.0 24 10.0.0.1 track 3 preference 61
ip route-static vpn-instance vpn-default 100.1.0.0 24 11.0.0.1 track 4
ip route-static vpn-instance vpn-default 110.1.0.0 24 10.0.0.1 track 3 preference 61
ip route-static vpn-instance vpn-default 110.1.0.0 24 11.0.0.1 track 4
#
//Configuration of static routes when NQA-track collaboration is not configured.
#
ip route-static vpn-instance vpn-default 100.1.0.0 24 10.0.0.1 preference 61
ip route-static vpn-instance vpn-default 100.1.0.0 24 11.0.0.1
ip route-static vpn-instance vpn-default 110.1.0.0 24 10.0.0.1 preference 61
ip route-static vpn-instance vpn-default 110.1.0.0 24 11.0.0.1
#
# Configure BGP to import static routes to VPN instance vpn-default.
#
bgp 100
#
ip vpn-instance vpn-default
#
address-family ipv4 unicast
import-route direct
import-route static
#
Configuring routes from leaf devices and access devices to servers
Configuring routes from leaf devices to servers
Do not configure static routes destined for the server network segment on the leaf devices. The spine devices will synchronize routes to the leaf devices through BGP.
Configuring static routes on access devices
# Configure two static routes destined for the servers on the access devices, and specify the VXLAN 4094 addresses on the spine devices as the gateway addresses.
#
ip route-static 100.1.0.0 24 130.1.0.101 //VXLAN 4094 address of Spine 1.
ip route-static 100.1.0.0 24 130.1.0.102 //VXLAN 4094 address of Spine 2.
ip route-static 110.1.0.0 24 130.1.0.101
ip route-static 110.1.0.0 24 130.1.0.102
#
Configuring DRNI for dual spine devices (manual)
In the current software version, the controller supports DRNI configuration only for leaf devices. You must manually configure DRNI for spine devices.
This chapter covers only the special configuration required in the dual-spine scenario on spine devices. For information about the other configuration, see "Manual incorporation."
Configuring the Layer 3 switch
# Create VLAN 10 and VLAN 11.
#
vlan 10 to 11
#
# Configure VLAN-interface 10 and VLAN-interface 11.
#
interface Vlan-interface10
ip address 10.0.0.1 255.255.255.0
#
interface Vlan-interface11
ip address 11.0.0.1 255.255.255.0
#
# Assign the interface connected to Spine 1 to VLAN 10.
#
interface Ten-GigabitEthernet1/0/25
port link-mode bridge
port link-type trunk
port trunk permit vlan 10 // Determine whether to add the interface to VLAN 1 according to the actual networking. If not required, execute the undo permit vlan 1 command to remove the interface from VLAN 1.
#
# Assign the interface connected to Spine 2 to VLAN 11.
#
interface Ten-GigabitEthernet1/0/26
port link-mode bridge
port link-type trunk
port trunk permit vlan 11 // Determine whether to add the interface to VLAN 1 according to the actual networking. If not required, execute the undo permit vlan 1 command to remove the interface from VLAN 1.
#
# Configure track.
#
track 1 interface Ten-GigabitEthernet1/0/25 physical
track 2 interface Ten-GigabitEthernet1/0/26 physical
#
# Configure two default routes with the next hops being the IP addresses of Spine 1 and Spine 2.
#
ip route-static 0.0.0.0 0 10.0.0.11 track 1
ip route-static 0.0.0.0 0 11.0.0.11 track 2
#
Connecting Spine 1 to the Layer 3 switch
# Create VLAN 10 and VLAN 11.
#
vlan 10 to 11
#
# Configure VLAN-interface 10 and VLAN-interface 11, and associate VPN instance vpn-default with the VLAN interfaces.
#
interface Vlan-interface10
ip binding vpn-instance vpn-default
ip address 10.0.0.11 255.255.255.0
#
#
interface Vlan-interface11
ip binding vpn-instance vpn-default
ip address 11.0.0.11 255.255.255.0
#
# Assign the interface connected to the Layer 3 switch to VLAN 10.
#
interface Ten-GigabitEthernet2/0/31
port link-mode bridge
port link-type trunk
port trunk permit vlan 10 // Determine whether to add the interface to VLAN 1 according to the actual networking. If not required, execute the undo permit vlan 1 command to remove the interface from VLAN 1.
#
# Configure NQA-track collaboration and static routes destined for the server cluster. The next hops of the static routes are the gateway IP addresses of VLAN 10 and VLAN 11 on the Layer 3 switch. Associate the static routes with track entries for quick link failure detection and link switchover.
#
nqa entry admin server1
type icmp-echo
destination ip 10.0.0.1
frequency 100
reaction 3 checked-element probe-fail threshold-type consecutive 3 action-type trigger-only
vpn-instance vpn-default
#
nqa entry admin server2
type icmp-echo
destination ip 11.0.0.1
frequency 100
reaction 4 checked-element probe-fail threshold-type consecutive 3 action-type trigger-only
vpn-instance vpn-default
#
nqa schedule admin server1 start-time now lifetime forever
nqa schedule admin server2 start-time now lifetime forever
#
track 3 nqa entry admin server1 reaction 3
track 4 nqa entry admin server2 reaction 4
#
#
ip route-static vpn-instance vpn-default 100.1.0.0 24 10.0.0.1 track 3
ip route-static vpn-instance vpn-default 100.1.0.0 24 11.0.0.1 track 4 preference 61
ip route-static vpn-instance vpn-default 110.1.0.0 24 10.0.0.1 track 3
ip route-static vpn-instance vpn-default 110.1.0.0 24 11.0.0.1 track 4 preference 61
#
Connecting Spine 2 to the Layer 3 switch
# Create VLAN 10 and VLAN 11.
#
vlan 10 to 11
#
# Configure VLAN-interface 10 and VLAN-interface 11, and associate VPN instance vpn-default with the VLAN interfaces.
#
interface Vlan-interface10
ip binding vpn-instance vpn-default
ip address 10.0.0.12 255.255.255.0
#
#
interface Vlan-interface11
ip binding vpn-instance vpn-default
ip address 11.0.0.12 255.255.255.0
#
# Assign the interface connected to the Layer 3 switch to VLAN 11.
#
interface Ten-GigabitEthernet2/0/31
port link-mode bridge
port link-type trunk
port trunk permit vlan 11 // Determine whether to add the interface to VLAN 1 according to the actual networking. If not required, execute the undo permit vlan 1 command to remove the interface from VLAN 1.
#
# Configure NQA-track collaboration and static routes destined for the server cluster. The next hops of the static routes are the gateway IP addresses of VLAN 10 and VLAN 11 on the Layer 3 switch. Associate the static routes with track entries for quick link failure detection and link switchover.
#
nqa entry admin server1
type icmp-echo
destination ip 10.0.0.1
frequency 100
reaction 3 checked-element probe-fail threshold-type consecutive 3 action-type trigger-only
vpn-instance vpn-default
#
nqa entry admin server2
type icmp-echo
destination ip 11.0.0.1
frequency 100
reaction 4 checked-element probe-fail threshold-type consecutive 3 action-type trigger-only
vpn-instance vpn-default
#
nqa schedule admin server1 start-time now lifetime forever
nqa schedule admin server2 start-time now lifetime forever
#
#
track 3 nqa entry admin server1 reaction 3
track 4 nqa entry admin server2 reaction 4
#
ip route-static vpn-instance vpn-default 100.1.0.0 24 10.0.0.1 track 3 preference 61
ip route-static vpn-instance vpn-default 100.1.0.0 24 11.0.0.1 track 4
ip route-static vpn-instance vpn-default 110.1.0.0 24 10.0.0.1 track 3 preference 61
ip route-static vpn-instance vpn-default 110.1.0.0 24 11.0.0.1 track 4
#
Configuring DRNI on Spine 1
# Configure fast rerouting for OSPF.
#
ospf 1 router-id 200.1.1.254 //Specify a unique router ID. The IP address of Loopback 0 is specified.
non-stop-routing
fast-reroute lfa
area 0.0.0.0
#
# Configure Loopback 2. Spine 1 and Spine 2 use the same IP address for Loopback 2.
#
interface LoopBack2
ip address 99.99.0.10 255,255,255,255
ospf 1 area 0.0.0.0
#
# Create VLAN 2 and configure VLAN-interface 2. Spine 1 and Spine 2 use different IP addresses for the VLAN interface. VLAN 2 is used to synchronize underlay routes between the two DR member devices.
#
vlan 2
#
interface Vlan-interface2
ip address 99.99.0.11 255.255.255.0
ospf network-type p2p
ospf 1 area 0.0.0.0
#
# Configure the MAC address of VSI-interface 4094. Spine 1 and Spine 2 use the same MAC address for the VSI interface.
#
interface Vsi-interface4094
ip binding vpn-instance vpn-default
ip address 120.0.0.1 255.255.255.0
mac-address 0001-0001-0005
local-proxy-arp enable
#
# Configure loop detection to eliminate loops in VSI vxlan4094.
#
vsi vxlan4094
loopback-detection action block
loopback-detection enable vlan 4094
#
# Configure EVPN distributed relay. The configurations on Spine 1 and Spine 2 are the same.
#
l2vpn drni peer-link ac-match-rule vxlan-mapping
evpn drni group 99.99.0.10 //Specify the IP address of Loopback 2 as the virtual VTEP address. The device will be reactivated.
evpn global-mac 0001-0001-0004 //MAC addresses on Spine 1 and Spine 2 are the same.
#
#
vxlan default-decapsulation source interface LoopBack0
#
# Enable the device to replace the next hop in advertised BGP EVPN routes with the virtual VTEP address.
#
bgp 1
address-family l2vpn evpn
nexthop evpn-drni group-address
#
# Configure the keepalive interface (a Layer 3 interface that can be a logical interface or a physical interface).
#
ip vpn-instance DRNI_KeepAlive //Configure the exclusive VPN instance for keepalive.
#
#
interface FortyGigE3/0/33
port link-mode route
ip binding vpn-instance DRNI_KeepAlive //Bind a VPN instance.
ip address 192.168.0.1 255.255.255.252 //Configure address mask 30. Specify different IP addresses for the keepalive interfaces on Spine 1 and Spine 2.
#
# Specify the destination and source IP addresses of keepalive packets.
#
drni keepalive ip destination 192.168.0.2 source 192.168.0.1 vpn-instance DRNI_KeepAlive
#
# Configure the DR system parameters. Configure the same system MAC and different system numbers for devices in a DR system.
#
drni restore-delay 180
drni system-mac 542b-de08-8200
drni system-number 1
drni system-priority 10
#
# Configure an IPP (it must be a layer 2 aggregate interface).
#
interface Bridge-Aggregation1
port link-type trunk
port trunk permit vlan all
port trunk pvid vlan 4094 //The PVID must be 4094.
link-aggregation mode dynamic
port drni intra-portal-port 1 //Configure the IPP.
undo mac-address static source-check enable //Disable source MAC address check.
#
#
interface Ten-GigabitEthernet2/0/1
port link-mode bridge
port link-type trunk
port trunk permit vlan all
port trunk pvid vlan 4094
port link-aggregation group 1
#
#
interface Ten-GigabitEthernet2/0/15
port link-mode bridge
port link-type trunk
port trunk permit vlan all
port trunk pvid vlan 4094
port link-aggregation group 1
#
# Configure DRNI MAD.
#
drni mad default-action none
#
track 1024 drni-mad-status
#
#
interface LoopBack2
ip address 99.99.0.10 255,255,255,255
ospf 1 area 0.0.0.0
ospf track 1024 adjust-cost max
#
# Set the MAC entry aging timer to a value no less than 20 minutes.
#
mac-address timer aging 1560
#
# Disable source MAC address check on the interface connected to leaf devices.
#
interface Ten-GigabitEthernet1/2/0/47
port link-mode bridge
port link-type trunk
port trunk permit vlan 1 3497
lldp source-mac vlan 3497
lldp management-address arp-learning vlan 3497
lldp tlv-enable basic-tlv management-address-tlv interface LoopBack0
undo mac-address static source-check enable
#
# Enable DR system auto-recovery and specify a reload delay time. To avoid incorrect role preemption, make sure the reload delay time is longer than the amount of time required for the device to restart.
drni auto-recovery reload-delay delay-value 600
#
Configuring DRNI on Spine 2
# Configure fast rerouting for OSPF.
#
ospf 1 router-id 200.1.1.253 // Specify a unique router ID. The IP address of Loopback 0 is specified.
non-stop-routing
fast-reroute lfa
area 0.0.0.0
#
# Configure Loopback 2. Spine 1 and Spine 2 use the same IP address for Loopback 2.
#
interface LoopBack2
ip address 99.99.0.10 255,255,255,255
ospf 1 area 0.0.0.0
#
# Create VLAN 2 and configure VLAN-interface 2. Spine 1 and Spine 2 use different IP addresses for the VLAN interface.
#
vlan 2
#
interface Vlan-interface2
ip address 99.99.0.12 2 55.255.255.0
ospf network-type p2p
ospf 1 area 0.0.0.0
#
# Configure the MAC address of VSI-interface 4094. Spine 1 and Spine 2 use the same MAC address for the VSI interface.
#
interface Vsi-interface4094
ip binding vpn-instance vpn-default
ip address 120.0.0.2 255.255.255.0
mac-address 0001-0001-0005
local-proxy-arp enable
#
# Configure loop detection to eliminate loops in VSI vxlan4094.
#
vsi vxlan4094
loopback-detection action block
loopback-detection enable vlan 4094
#
# Configure EVPN distributed relay. The configurations on Spine 1 and Spine 2 are the same.
#
l2vpn drni peer-link ac-match-rule vxlan-mapping
evpn drni group 99.99.0.10 // Specify the IP address of Loopback 2 as the virtual VTEP address. The device will be reactivated.
evpn global-mac 0001-0001-0004 // MAC addresses on Spine 1 and Spine 2 are the same.
#
#
vxlan default-decapsulation source interface LoopBack0
#
# Enable the device to replace the next hop in advertised BGP EVPN routes with the virtual VTEP address.
#
bgp 1
address-family l2vpn evpn
nexthop evpn-drni group-address
#
# Configure the keepalive interface (a Layer 3 interface that can be a logical interface or a physical interface).
#
ip vpn-instance DRNI_KeepAlive //Configure the exclusive VPN instance for keepalive.
#
#
interface FortyGigE3/0/33
port link-mode route
ip binding vpn-instance DRNI_KeepAlive //Bind a VPN instance.
ip address 192.168.0.2 255.255.255.252 //Configure address mask 30. Specify different IP addresses for the keepalive interfaces on Spine 1 and Spine 2.
#
# Specify the destination and source IP addresses of keepalive packets.
#
drni keepalive ip destination 192.168.0.1 source 192.168.0.2 vpn-instance DRNI_KeepAlive
#
# Configure the DR system parameters. Configure the same system MAC and different system numbers for devices in a DR system.
#
drni restore-delay 180
drni system-mac 542b-de08-8200
drni system-number 2
drni system-priority 10
#
# Configure an IPP (it must be a layer 2 aggregate interface).
#
interface Bridge-Aggregation1
description SDN_LAGG
port link-type trunk
port trunk permit vlan all
port trunk pvid vlan 4094 // The PVID must be 4094.
link-aggregation mode dynamic
port drni intra-portal-port 1 //Configure the IPP.
undo mac-address static source-check enable //Disable source MAC address check.
#
#
interface Ten-GigabitEthernet3/0/15
port link-mode bridge
port link-type trunk
undo port trunk permit vlan 1
port trunk permit vlan 2 to 4094
port trunk pvid vlan 4094
port link-aggregation group 1
#
#
interface Ten-GigabitEthernet3/0/22
port link-mode bridge
port link-type trunk
undo port trunk permit vlan 1
port trunk permit vlan 2 to 4094
port trunk pvid vlan 4094
port link-aggregation group 1
#
#
# Configure DRNI MAD.
#
drni mad default-action none
#
track 1024 drni-mad-status
#
#
interface LoopBack2
ip address 99.99.0.10 255,255,255,255
ospf 1 area 0.0.0.0
ospf track 1024 adjust-cost max
#
# Set the MAC entry aging timer to a value no less than 20 minutes.
#
mac-address timer aging 1560
#
# Disable source MAC address check on the interface connected to leaf devices.
#
interface Ten-GigabitEthernet1/2/0/47
port link-mode bridge
port link-type trunk
port trunk permit vlan 1 3498
lldp source-mac vlan 3498
lldp management-address arp-learning vlan 3498
lldp tlv-enable basic-tlv management-address-tlv interface LoopBack0
undo mac-address static source-check enable
#
# Enable DR system auto-recovery and specify a reload delay time. To avoid incorrect role preemption, make sure the reload delay time is longer than the amount of time required for the device to restart.
drni auto-recovery reload-delay delay-value 600
#
Configuring DRNI
DRNI networking
Distributed Resilient Network Interconnect (DRNI) is a cross-device link aggregation technology that virtualizes two physical devices into one device at the aggregation level to implement cross-device link aggregation. Hence, it can provide device-level redundancy protection and traffic load sharing.
The AD-Campus solution enables the configuration of DRNI on devices to form DR systems, for device redundancy protection and traffic load sharing. The network diagram of DRNI is shown in the figure below.
Figure 29 DRNI networking
Configuring a DR system
For the configuration of dual spine devices, see "Configuring redundant dual-spine uplinks." The dual spine devices are manually incorporated by the controller. After the leaf devices are incorporated by the controller, you can configure DRNI settings. For information about the incorporation of spine and leaf devices, see "Configuring AD-Campus."
This section covers only the configuration of DRNI after the leaf devices are incorporated by the controller.
|
|
NOTE: · To enable DRNI on a fabric, you must bind the VLAN 4094 address pool to that fabric for verification on DRNI virtual IP automatic allocation. · The dual spine devices must establish separate BGP peer relationships with the leaf devices. For more information about the configuration, see "Manual incorporation." · The keepalive link and IPL support the use of interfaces at different rates. Make sure the interfaces attached to the IPL are operating at the same rate. · Do not deploy multiple DR systems synchronously. Deploy one DR system each time. · Remove the uplink interfaces of access devices from the BFD MAD VLAN if the leaf devices connected to the access devices form a DR system, the access devices form an IRF fabric, and BFD MAD is configured on the IRF fabric. · To ensure that users can correctly access services when a DR system is used as a leaf device, make sure the DR system setup is completed before the users come online. · To expand a DR interface and intra-portal port (IPP), click the Edit icon for that DR interface or IPP to open the page for editing the DR interface or IPP, and then add the corresponding physical interfaces. |
1. Navigate to the Automation > Campus Network > Devices page, and click IP Address Pools in the upper right corner.
2. On the Add IP Address Pool page, select DRNI as the Type.
3. The DRNI IP address pool configures DRNI addresses, and three addresses need to be allocated to each DR system.
¡ The address of Loopback 2 (same for the two devices): Specify the virtual VTEP address.
¡ The address of the VLAN-interface 2 (one for each device): Used to synchronize underlay routes between the DR member devices.
4. Navigate to the Automation > Campus
Network > Devices page, and click DRNI in the upper right
corner. Click the DRNI Parameters tab, and then
click the 
icon to access the Edit DRNI Parameters page.
¡ DRNI State: Select Yes.
¡ DRNI Address Pool: Select the created DRNI address pool.
¡ DRNI Authentication Mode: Select Distributed.
5. Navigate to the Automation > Campus Network > Devices page, and click DRNI. Click Add.
Parameters are described as follows:
¡ Name: Enter a name for the DR system.
¡ Fabric: Select HJYQ.
¡ Device A Label/Device B Label: Enter the label of each DR member device.
¡ DRNI Virtual IP Allocation Method: It can be allocated automatically from the device management address pool by default. If manual allocation is required, specify an IP address from the same subnet as the device management IP addresses. Make sure no IP conflicts exist.
If no automation template is configured on the fabric and the automatic virtual IP allocation method is used, you must navigate to the Automation > Campus Network > Fabrics page. On the IP Pool Settings page, bind the subnet of VXLAN 4094 on the devices to the VLAN 4094 address pool. If you do not perform this operation, a notification message will pop up.
If automation templates have been configured on the fabric, you do not need to perform the above mentioned operations when the automatic virtual IP allocation method is used.
6. The controller will automatically create a DRNI IPP link. Click the DR System tab to view the automatically configured virtual IP addresses.
7. The deployment time of DR systems varies by device model. Wait until the deployment state changes to Deployed before proceeding to the next step. As a best practice, do not deploy multiple DR systems synchronously, and deploy them one by one.
8. Click Back to go back to the DR System page, and you can see that the DR system is created successfully.
9. Click the 
icon, and the DR member devices will automatically create DR groups for
interfaces connecting the DR member devices and access devices.
10. Before configuring DR groups, navigate to the Monitor > Topology View > Campus Topology to verify that the topology links between the leaf and access devices are activated and in correct state.
11. Click the 
icon in the Actions column for the added DR system to enter the DR system editing page.
12. Click the LAG Groups tab to verify that DR groups have been generated automatically.
13. Add an access device
and click the 
icon to create a DR group.
14. Click the 
icon in the Actions column for the DR system and view the new DR interfaces.
15. View the DRNI state.
<Leaf-S105A> display drni summary
Flags: A -- Aggregate interface down, B -- No peer DR interface configured
C -- Configuration consistency check failed
IPP: BAGG1
IPP state (cause): UP
Keepalive link state (cause): UP
DR interface information
DR interface DR group Local state (cause) Peer state Remaining down time(s)
BAGG2 1 UP UP -
BAGG3 2 UP UP -
BAGG4 3 UP UP -
<Leaf-S105A>
O&M monitoring
For more information, see AD-Campus 6.2 O&M, Monitoring, and Deployment Guide.
