Login
- Released At: 13-09-2023
- Page Views:
- Downloads:
- Table of Contents
- Related Documents
-
AD-Campus 6.2
Automation 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
Connection mode between the underlay network and the controller
Restoring the factory-default configuration and restart the device
Configuring automation parameters
Planning network resources and IP addresses
SeerEngine-Campus controller and Unified Platform using separate network adapters (recommended)
SeerEngine-Campus controller and Unified Platform using the same network adapter
Preparing for a three-tier or two-tier architecture deployment
Preparing for a single-leaf architecture deployment
Configuring IRF stacking for leaf devices
Onboarding a single spine device
Starting the spine device with the factory-default configuration
Spine device automated configuration
AC interface automated configuration
Verifying the deployment result on the spine device
Verifying the spine deployment on the controller
Complete deployment of the configuration
Spine IRF deployment restrictions and guidelines
Multiple links between spine and leaf devices
Onboarding a single leaf device
Restarting the leaf device with the factory-default configuration
Automatic configuration of the leaf interfaces
Verifying the deployment result
Onboarding multiple leaf devices
Leaf IRF deployment restrictions and guidelines
Adding redundant spine-leaf links
Adding redundant leaf-access links
Onboarding a single access device
Restarting the leaf device with the factory-default configuration
Automatic configuration of the access device
Verifying the deployment result on the access device
Verifying the access deployment on the controller
Onboarding an access IRF fabric
Deploying the access IRF fabric
Automatic leaf-access link aggregation
Deploying multiple tiers of access devices
Restarting a lower-tier access device with the factory-default configuration
Restrictions and guidelines
To ensure a successful automated underlay deployment, read the following information carefully and be compliant with the stated restrictions, requirements, and guidelines.
Licensing and DHCP server requirements
· Automation is license-based. To use the feature, you must install the required licenses on Unified Platform and the controller.
· Set up the vDHCP server correctly, which is required during automatic device onboarding.
Username and password requirements
· The device configuration template and the device control protocol template can use different usernames. If their usernames are the same, their passwords must be the same. The username and password in the device configuration template are used for spine device access to a leaf device. The username and password in the device control protocol template are used by the controller to access the device.
· Make sure the passwords in the deployment automation template for automated deployment are strong enough and compliant with the password policy. Automated deployment does not support weak passwords.
Generic deployment restrictions and guidelines
· Before you onboard a device, restore its configuration to factory defaults.
· When you onboard new devices or replacement devices, do that one by one, and tier by tier. Make sure one device is onboarded and operate correctly before you start onboarding the next one. This practice helps avoid deployment failure caused by network connectivity issues or other issues. For example, onboard a spine device before you onboard any leaf devices connected to it, and then onboard each of the leaf devices before you onboard the access devices connected to them. When you deploy multi-tier access devices, also do that tier by tier.
· If redundancy is desired, deploy IRF fabrics. This solution supports automated deployment of only dual-device IRF fabrics.
· When you onboard a spine/single-leaf IRF fabric, use the following procedure:
a. Connect the two devices to the controller.
b. Connect the two devices to each other.
c. As a best practice, onboard the device with a higher bridge MAC address first.
· When you onboard a leaf/access IRF fabric, use the following procedure:
a. Connect the two devices to the upstream device.
b. Connect the two devices to each other.
c. Clear the configuration of the two devices and restart them simultaneously.
· An AP's dual uplinks do not support automated aggregation.
· If the devices in same fabric are onboarded in different modes (manual and automation), make sure the devices onboarded in different modes use different IP addresses for VSI/VLAN 4094 and the underlay IP addresses and underlay VLANs of the manually onboarded devices are not in the underlay IP address range and underlay VLAN range defined in the automation template.
Spine/single-leaf device deployment
· Do not directly connect two spine devices or connect two leaf devices unless you are building them into an IRF fabric.
· On a spine or single-leaf device, the interface connects to the L3 switch is automatically configured as an attachment circuit (AC) interface. This interface can be a physical interface or an aggregate interface. If you enable IRF stacking, use the following procedure to deploy a spine or single-leaf IRF fabric:
a. In the spine or single leaf template, specify the uplink interface as an aggregate interface.
b. Connect one of the spine or single-leaf devices (the device with a higher bridge MAC address) to the L3 switch.
c. Manually configure downlink interface aggregation on the L3 switch.
d. Onboard the spine/single-leaf IRF fabric.
e. After the IRF fabric is onboarded and operates correctly, connect the other spine or single-leaf device in the fabric to the L3 switch, and manually aggregate the uplink interfaces.
· When you deploy a spine IRF fabric or deploy the leaf IRF fabric in a single-leaf deployment, onboard the device with a higher bridge MAC address first. If you onboard the device with a lower bridge MAC address first, its member ID will change, causing the name of the uplink interface to change. In this case, you need to manually modify the uplink interface name in the spine template/the uplink interface name of leaf device in the single-leaf template on the controller.
Access device deployment
· For automated deployment of access devices, you must set up access devices in compliance with the following requirements:
¡ The solution supports up to three access tiers, with access tier 1 directly connected to the leaf tier, access tier 2 connected to access tier 1, and so on.
¡ Use GE or Smartrate-Ethernet ports to connect the upper and lower access tiers. A lower-tier access device has two physical links with its higher-tier access device.
¡ You can deploy IRF fabrics only at access tier 1. Access tiers 2 and 3 do not support IRF fabrics.
¡ If you are deploying an IRF fabric at access tier 1, use 10-GE ports to connect its member devices. If the multi-tier access devices do not have IRF requirements, you can disable IRF automation in the automation template and use 10-GE ports to connect them.
¡ To use 40-GE ports to form an IRF fabric in access tier 1 and then connect it to the lower-tier access devices by using 10-GE ports, you can contact Technical Support to edit the automation template to implement the configuration.
· This solution does not support automated configuration of BFD MAD for IRF fabrics at the access tier. To manually set up BFD MAD, use the following procedure:
a. Ensure that the physical interfaces for BFD MAD are down, and then configure BFD MAD.
b. Connect the physical interfaces for BFD MAD, and verify that BFD MAD operates correctly.
S7500E and S10500 restrictions and guidelines
The S7500E switches and the S10500 switches that use the LSU1SUPB0 MPU have small storage space, which cannot meet the storage space required by automated deployment. As a result, upgrade the software of these device manually before automated deployment or from the Unified Platform after the devices are incorporated into the Unified Platform.
IRF fabric expansion
To expand a one-device IRF fabric:
1. Make sure the device in the IRF fabric has been online for more than two hours.
2. Clear the configuration of the new device and restart the device.
3. Connect the new device to the online device.
Deployment verification
After the devices are automatically onboarded, select Automation > Campus Network > Fabric > Auto Deployment > Auto Device Deployment Tasks, and pause the automation process. Then, the devices execute the vcf-fabric underlay pause command to stop the automation process.
Overview
Network automation includes underlay automation and overlay automation. This document focuses on underlay automation. The following information describes the underlay automation configuration procedure, the controller configuration procedure, and the automated device deployment process.
Device model and role matrix
Table 1 lists the device models supported in the AD-Campus solution for each network device role:
Table 1 Device model and role compatibility matrix
|
Default role |
Supported non-default roles |
|
|
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, also called EPG, not supported) |
Leaf |
Access |
|
S5560X-EI (microsegmentation, also called EPG, not supported) |
Leaf |
Access |
|
S6520X-SI |
Access |
None |
|
S5130-EI S5130-HI S5130S-EI S5130S-HI |
Access |
None |
Network architecture design
Three-tier architecture
A large campus typically uses a three-tier network architecture in which devices are deployed at the spine, leaf, and access tiers. The solution also supports access deployment of up to three tiers.
Depending on the redundancy requirements, you can deploy dual-device IRF fabrics at the spine, leaf, or access tier-1.
Figure 1 Three-tier network architecture
Two-tier architecture
A small- or medium-sized campus can use a two-tier network architecture in which devices are deployed at the spine and leaf tiers. No access tier is present. AP and wired users are connected to leaf devices.
Depending on the redundancy requirements, you can deploy dual-device IRF fabrics at the spine and leaf tiers.
Figure 2 Two-tier network architecture
Single-leaf architecture
A small-sized campus typically uses a two-tier network architecture in which devices are deployed at the leaf and access tiers.
Depending on the redundancy requirements, you can deploy a single leaf device or a dual-leaf IRF fabric to which each access device is dual homed.
You can cascade a maximum of three tiers of access devices. At access tier 1, you can deploy dual-device IRF fabrics as needed for redundancy.
Figure 3 Single-leaf network architecture
Connection mode between the underlay network and the controller
In this solution, the spine tier must have Layer 3 connectivity with the SeerEngine-Campus controller. This solution supports using the same network adapter or two separate network adapters for the SeerEngine-Campus controller and the Unified Platform. For more network connection information, see AD-Campus 6.2 Basic Configuration Guide.
Automated deployment workflow
Figure 4 shows the automated underlay deployment workflow for a device. The workflow includes the following primary phases:
1. Configure deployment automation parameters on the controller.
2. The device starts up with the factory-default configuration file, and automatically obtains the role configuration template to configure itself.
3. Specify the primary RR on the controller. The controller automatically deploys BGP configuration. An EVPN tunnel is set up between thee spine and leaf devices.
4. The controller automatically incorporates the device and adds the device to the corresponding device group and interface group.
Figure 4 Automated underlay deployment workflow
Restoring the factory-default configuration and restart the device
Execute the restore factory-default command to restore the device to the factory-default configuration.
<Sysname> restore factory-default
This command will restore the system to the factory default configuration and clear the operation data. Continue [Y/N]:y
Restoring the factory default configuration. This process might take a few minutes. Please wait..........................................................................................................Done.
Please reboot the system to place the factory default configuration into effect.
Configuring automation parameters
Planning network resources and IP addresses
Before an automated network deployment, plan the network architecture and resources properly. The SeerEngine-Campus controller and Unified Platform can share the same network adapter or each use a separate network adapter.
SeerEngine-Campus controller and Unified Platform using separate network adapters (recommended)
The SeerEngine-Campus controller and Unified Platform use different network adapters and different subnets. In this case, EIA and Unified Platform use the same subnet, and SeerEngine-Campus and vDHCP use the same subnet.
Figure 5 SeerEngine-Campus controller and Unified Platform using separate network adapters
As shown in the network diagram, the SeerEngine-Campus controller and the vDHCP server are deployed based on Unified Platform. The controller and the vDHCP server share the same physical adapter. The L3 switch and the vDHCP server are connected with a cable.
Add the server-connecting port of the L3 switch to VLAN 1010 (or any VLAN except VLAN 1 and VLAN 4094). It is the management VLAN for the controller and the vDHCP server, which ensures the L3 connectivity with the L3 switch. Its subnet is 110.1.0.0/24.
On the L3 switch, configure VLAN-interface 1 and VLAN-interface 4094 for communication with spine devices. Enable DHCP. Enable DHCP relay on VLAN-interface 1.
Table 2 shows the addressing scheme used when the SeerEngine-Campus controller and Unified Platform use separate network adapters.
|
Item |
Address |
Description |
|
VLAN 1 subnet (gateway IP) |
120.1.0.0/24 (120.1.0.1) |
Network for VLAN 1, used for automated onboarding. |
|
VLAN 4094 subnet (gateway IP) |
130.1.0.0/24 (130.1.0.1) |
Network for VLAN 4094, used for communication between the controller and the devices. |
|
VLAN 4093 subnet (gateway IP) |
30.0.3.0/24 (30.0.3.89) |
VLAN-interface 4093 is the Layer 3 interface for communication with the AP. |
|
VLAN 30 subnet (gateway IP) |
100.1.0.0/24 (100.1.0.1) |
Subnet for Unified Platform, used for communication between the PC and Unified Platform. |
|
VLAN 1010 subnet (gateway IP) |
110.1.0.0/24 (110.1.0.1) |
Subnet for the SeerEngine-Campus controller and vDHCP, used for the communication between the PC and the controller. |
|
Underlay IP subnet |
200.1.1.0/24 |
Subnet for the loopback interfaces of spine and leaf devices. |
|
Unified Platform northbound IP |
100.1.0.100 |
Address used to log in to Unified Platform. |
|
EIA |
100.1.0.100 |
EIA server address. |
|
SeerEngine-Campus cluster IP |
110.1.0.100 |
Address of the SeerEngine-Campus controller cluster. |
|
SeerEngine-Campus node IP |
Node1: 110.1.0.101 Node2: 110.1.0.102 Node3: 110.1.0.103 |
Addresses of three nodes in the SeerEngine-Campus controller cluster. |
|
vDHCP cluster IP |
110.1.0.104 |
Address of the vDHCP server cluster, which will not be used. |
|
vDHCP node IP |
Node1: 110.1.0.105 Node2: 110.1.0.106 |
Addresses of the two nodes in the vDHCP server cluster. |
|
|
NOTE: The SeerEngine-Campus and vDHCP addresses are automatically assigned by Unified Platform. |
SeerEngine-Campus controller and Unified Platform using the same network adapter
The SeerEngine-Campus controller and Unified Platform share one network adapter. In this case, the SeerEngine-Campus controller, vDHCP, and EIA servers use IP addresses in the same subnet.
Figure 6 SeerEngine-Campus controller and Unified Platform share one network adapter
Table 3 shows the addressing scheme used when the SeerEngine-Campus controller and Unified Platform use the same network adapter.
|
Item |
Address |
Description |
|
VLAN 1 subnet (gateway IP) |
120.1.0.0/24 (120.1.0.1) |
Network for VLAN 1, used for automated onboarding. |
|
VLAN 4094 subnet (gateway IP) |
130.1.0.0/24 (130.1.0.1) |
Network for VLAN 4094, used for communication between the controller and the devices. |
|
VLAN 30 subnet (gateway IP) |
100.1.0.0/24 (100.1.0.1) |
Subnet for the Unified Platform, SeerEngine-Campus controller, and vDHCP server. |
|
VLAN 4093 subnet (gateway IP) |
30.0.3.0/24 (30.0.3.89) |
VLAN-interface 4093 is the Layer 3 interface for communication with the AP. |
|
Underlay IP subnet |
200.1.1.0/24 |
Subnet for the loopback interfaces of spine and leaf devices. |
|
Unified Platform northbound IP |
100.1.0.100 |
Address used to log in to Unified Platform. |
|
EIA |
100.1.0.100 |
EIA server address. |
|
SeerEngine-Campus cluster IP |
100.1.0.200 |
Address of the SeerEngine-Campus controller cluster. |
|
SeerEngine-Campus node IP |
Node1: 100.1.0.201 Node2: 100.1.0.202 Node3: 100.1.0.203 |
Addresses of three nodes in the SeerEngine-Campus controller cluster. |
|
vDHCP cluster IP |
100.1.0.204 |
Address of the vDHCP server cluster, which will not be used. |
|
vDHCP node IP |
Node1: 100.1.0.205 Node2: 100.1.0.206 |
Addresses of the two nodes in the vDHCP server cluster. |
Planning user VLANs
SeerEngine-Campus has predefined three VLAN pools. Navigate to the Automation > Campus Network > Network Devices page. Click VNID Pools in the upper right corner to open the VNID pool configuration page. The VLANs tab displays all VLAN pools in the system.
The names of the system default campus access VLAN pool default_access, security group VLAN pool default_security_group, and campus authentication-free VLAN pool default_auth_free cannot be edited.
|
|
CAUTION: By default, the SeerEngine-Campus controller uses VLAN 100 for BFD of the automated IRF fabric, and uses VLAN 4092 through VLAN 4094 as reserved VLANs. |
The VLAN pools include the following types:
· Campus access VLAN—This type of VLAN pool is used to assign VLAN configuration to onboarded access devices. By default, the VLAN range is 101 to 3000.
· Security group VLAN—This type of VLAN pool is used to assign VLAN IDs to security groups in isolation domains, so as to implement user access. By default, the VLAN range is 3501 to 4000.
· Campus Auth-Free VLAN—This type of VLAN pool is used to assign VLAN IDs to authentication-free bindings in the isolation domains to deploy VLAN configuration to the access devices bound with auth-free settings. By default, the VLAN range is 4051 to 4060.
Figure 7 VLAN pools
To change the VLAN ranges for a VLAN pool,
click the Edit icon 
for the VLAN
pool. On the page that opens, click the Edit icon
for a VLAN range and edit it as needed.
Figure 8 Editing VLAN ranges
Preparing for a three-tier or two-tier architecture deployment
Follow the configuration in this section for a three-tier or spine-leaf two-tier architecture deployment.
Configuring the L3 switch
1. Configure VLAN-interface 1 and VLAN-interface 4094 for communication with the spine tier devices.
#
vlan 1
#
#
vlan 4094
#
#
interface Vlan-interface1
ip address 120.1.0.1 255.255.255.0
dhcp select relay
dhcp relay server-address 110.1.0.105 // vDHCP server IP
dhcp relay server-address 110.1.0.106 // vDHCP server IP
#
#
interface Vlan-interface4094 // The management address is assigned by the controller. DHCP relay is not required here.
ip address 130.1.0.1 255.255.255.0
#
2. Configure VLAN-interface 30 for communicating with Unified Platform.
#
vlan 30
#
#
interface Vlan-interface30
ip address 100.1.0.1 255.255.255.0
#
3. Configure VLAN-interface 1010 for communicating with the SeerEngine-Campus controller and vDHCP server.
#
vlan 1010
#
#
interface Vlan-interface1010
ip address 110.1.0.1 255.255.255.0
#
4. Enable DHCP.
#
dhcp enable
#
5. Enable STP.
#
stp global enable
#
6. Add a default route.
For users to get online, you must configure static routing or dynamic routing on the L3 switch to make sure they can communicate with the EIA server for authentication. If no route is available, users will be unable to authenticate to the EIA server after they obtain an IP address from their security group.
#
ip route-static 0.0.0.0 0 130.1.0.2 // Configure a default route with the next hop as the IP address of VSI 4094 on the Spine device.
#
7. Configure the interface connected to the spine device.
#
interface Ten-GigabitEthernet1/0/6
port link-mode bridge
description to_spine
port link-type trunk
port trunk permit vlan 1 4094
#
8. Configure the interface connected to Unified Platform.
#
interface GigabitEthernet1/0/7 //Connected to the management interface of Unified Platform.
port access vlan 30
stp edged-port
#
9. Configure the interface connected to the controller and vDHCP server.
#
interface GigabitEthernet1/0/3 // Connected to the management interface of the SeerEngine-Campus controller and vDHCP server.
port access vlan 1010
stp edged-port
#
Configuring the controller
Configuring basic settings
1. Log in to the SeerEngine-Campus controller. Navigate to Guide > Campus Wizard > Device Onboarding Plan > Configure Basic Info page.
Figure 9 Basic settings
2. Click Select Fabric to add a fabric, and then click OK.
¡ Name: Specify the fabric name, a case-sensitive string up to 255 characters.
¡ Network Type: Use the default network type VXLAN.
¡ AS Number: Enter the BGP AS number of the fabric, an integer in the range of 1 to 4294967295. In a multi-fabric network, each fabric must use a different AS number.
¡ Isolation Domain: Select the isolation domain to which the fabric belongs.
¡ Multicast Network: Option Off is selected by default. Select On as needed.
¡ QoS: Option Off is selected by default. Select On as needed.
¡ Lock Underlay: Option Off is selected by default. You cannot edit the setting when you add a fabric. This feature must be off during automated device onboarding. After the automation is completed, you can turn it on as needed.
¡ Delayed Access Interface PVID Assignment: Option Off is selected by default, and the controller automatically assigns a PVID when the device is activated. If you select the On option, the controller does not automatically assigns a PVID when the device is activated, and you can configure the PVID when needed.
¡ Virtual Auto Online And Business Follow: Option On is selected by default. The devices to be incorporated also require the virtual network auto online and business follow licenses if they require device series licenses. If the licenses are not enough, the devices cannot be incorporated. If you select the Off option, the incorporated devices do not occupy the corresponding licenses but they cannot add to isolation domains.
Figure 10 Adding a fabric
3. Use Optimized Automated Deployment: Option Yes is selected by default. For more information about the configuration, see AD-Campus 6.2 Optimized Automation Configuration Guide. This document describes the original automated deployment procedure, so select the No option.
4. Select Yes for TFTP Service.
Figure 11 Basic settings
5. In the RR MAC box, enter the bridge MAC address of the spine device. If the fabric uses the Single Leaf architecture, you can leave this field empty.
|
|
CAUTION: For a spine IRF fabric or a single spine device with multiple MPUs, you must enter the bridge MAC address of each MPU in the fabric in the RR MAC field. Separate each bridge MAC with a comma (,). |
To obtain the bridge MAC address of a spine device, use either of the following methods:
¡ Method 1: Use the display device manuinfo command.
[h3c]dis device manuinfo chassis 1 slot 0 //Specify the slot number of the MPU.
Chassis 1:
Slot 0 CPU 0:
DEVICE_NAME : LSUM1SUPC0
DEVICE_SERIAL_NUMBER : 210231A4B8H174000229
MAC_ADDRESS : 60DA-8309-E000
MANUFACTURING_DATE : 2017-04-13
VENDOR_NAME : H3C
[H3C]
¡ Method 2: Use the debug stack show memberinfo command in probe view.
[H3C-probe]debug stack show memberinfo chassis 1 slot 0 //Specify the slot number of the MPU.
=============================================================
Member Information of STACK Module
=============================================================
MemID:1, LocalSlotID:0, Priority:0, Mode:90
MaxMemNum:4, MaxPortMemberPort:16, StackCapability:5
BridgeMac:60:da:83:09:e0:00
[H3C-probe]
Configuring the address pools
1. Click DHCP Server and then select Add DHCP Server.
Figure 12 Configuring address pools
2. Configure the H3C vDHCP parameters.
¡ Management Mode: Select Tight. vDHCP supports only the tight mode.
¡ High Availability: Select this option in cluster environment. In standalone mode, you do not need to select this option.
¡ IPv4/IPv6 Dual Stack: Select this option if IPv6 automation is involved or users have enabled IPv6 services. For more information about IPv6 service configuration, see AD-Campus 6.2 IPv6 Service Configuration Guide.
¡ First IPv4 Address/Second IPv4 Address: Enter the IPv4 addresses assigned during deployment of the public
network. To obtain the IPv4 addresses, select System
> Deployment > Public
Service, and then click the Details icon 
to view
the IP addresses of the vDHCP server.
¡ Vendor: Select H3C.
Figure 13 Adding a DHCP server
|
|
NOTE: The DHCP server used for automatic device onboarding must be the H3C vDHCP server. |
3. Create the VLAN 1 address pool. Set its network to the network address planned for VLAN 1 (120.1.0.0/24) and set the gateway address to the IP address assigned to VLAN-interface 1 on the L3 switch.
Figure 14 Adding IP address pool for VLAN 1
4. Add the VLAN 4094 address pool. Set its network to the network address planned for VLAN 4094 (130.1.0.0/24) and set the gateway address to the IP address assigned to VLAN-interface 4094 on the L3 switch.
Figure 15 Adding IP address pool for VLAN 4094
5. Add subnets 110.1.0.0/24 and 100.1.0.0/24 for the controller, vDHCP server, and EIA server. Separate the subnets with commas (,).
|
|
NOTE: If the Unified Platform, controller, and EIA are in different subnets, add all these subnets. |
Figure 16 IPv4 management subnets
|
|
NOTE: Underlay automation does not have IPv6 services. You do not need to configure the VLAN4094 IPv6 address pool and its IPv6 network address. |
6. Click Next to open the device role templates configuration page.
Configuring device role templates
1. Device role template (automation template) configuration:
¡ Local Username and Local Password: If the local username is the same as the login username configured in Control Protocol Template, the local password must also be the same as the login password configured in Control Protocol Template. The username and password in the control protocol template are used by the controller to access a device. The local username and local password are used by a spine device to access a leaf device.
¡ NTP server: If an NTP server has been configured when Unified Platform is deployed, configure the NTP server here as the cluster northbound service IP of Unified Platform as a best practice. You can also enter the address of the NTP server on the user network. Make sure the NTP server is reachable on the network.
¡ Control Protocol Template: Select the default control protocol template, where the username and password are empty. To edit the username and password, navigate to Automation > Campus Network > Fabrics > Auto Deployment > Control Protocol Templates.
Figure 17 Creating a device role template
2. For three-tier architecture, select Spine Template, Leaf Template/Single Leaf Template, and Access Template. In the Leaf Template/Single Leaf Template area, select Leaf Template.
3. Configure the following template parameters:
¡ Support for Version Upgrade: By default, option No is selected and automation does not support software version upgrade. To upgrade software version during automation, select option Yes, and select the upgrade mode.
¡ Software Version: Select the software version to which the device will be upgraded. You can upgrade only same model devices.
Figure 18 Spine template
¡ Control Protocol Template: The initial control protocol template does not have username and password configured. Click Edit Template to configure the login username and password in the control protocol template. If the login username configured in the control protocol template is the same as the local username configured in the upper part of the page, the login password in the control protocol template must be also the same as the local password.
Figure 19 Editing the control protocol template
¡ Master Spine MAC: Specify the bridge MAC address of the spine device. The spine device at the master spine MAC will assign underlay IP addresses and underlay VLANs. If the spine device is in an IRF fabric, specify the bridge MAC address of the master in the IRF fabric as the master spine MAC.
¡ Underlay IP Range: Specify the address range for assigning IP addresses to the Loopback 0 interfaces on the spine and leaf devices.
¡ Auto-Allocate Underlay IP: Option Yes is selected by default.
- Yes—The controller automatically assigns IP addresses from the configured underlay IP range to the Loopback 0 interfaces on the spine and leaf devices.
- No—Manually assign IP addresses to the Loopback 0 interfaces on the spine and leaf devices. If you select No, you need to enable whitelist in the spine and leaf templates, and add the underlay IP addresses of the specified devices to the device list.
¡ Underlay VLAN Range: Specify the range of VLANs for establishing underlay OSPF neighbor relationships. As a best practice, use the default setting.
¡ Uplink Interface: Specify the full name of the uplink interface that connects the spine device to the L3 switch. During automatic underlay deployment, the controller automatically deploys the AC configuration for VLAN4094-VXLAN4094 on this interface for service traffic between the device and the controller. If the spine device is an IRF fabric that uses dual uplinks, specify the aggregate interface as the uplink interface.
¡ IRF Stacking: If you enable IRF stacking, the controller automatically configures the two devices to form an IRF fabric if it detects that the devices are correlated and of the same device model and device role.
¡ Enable Whitelist: Specify whether the controller uses the device list to identify devices to be deployed.
- If you select No, the controller does the following when it deploys a device:
If the serial number of the device is in the device list, the controller deploys the device based on the information specified in the device list, and incorporates the device with the tag specified for it.
If the serial number of the device is not in the device list, the controller deploys the device based on the default role of the device, and incorporates the device with its default tag in role + VLAN4094_IP format.
- If you select Yes, the controller does the following when it deploys a device:
If the serial number of the device is in the device list, the controller deploys the device based on the information specified in the device list, and incorporates the device with the tag specified for it.
If the serial number of the device is not in the device list, automated onboarding fails.
¡ Enable Olt: This parameter is available in the leaf template. You need to configure this parameter for EPON networking. For more information, see AD-Campus 6.2 EPON Configuration Guide.
¡ Enable Auto Aggregation: This parameter is available in the leaf template. Option Yes is selected by default. You must select No if DRNI is used in the network.
¡ Enable Auto Aggregation of Uplinks: This parameter is available in the access template. Option Yes is selected by default. You must select No if DRNI is used in the network.
|
|
NOTE: If the spine device is in an IRF fabric, specify the bridge MAC address of the master in the IRF fabric as the master spine MAC. To upgrade software during automatic underlay deployment, you can specify the target software version in the template. This method allows you to upgrade only same model devices in bulk. To upgrade different models, see "Upgrading software." |
Figure 20 Spine template
Figure 21 Leaf template
Figure 22 Access template
4. Click Next. The device list page opens.
Configuring the device list
In the device list, the device serial number uniquely identifies a device. Each entry in the device list records the device serial number and the device role mapping for a device. By using the device list, you can plan the role of each device in the network.
The device list is used for the device whitelist feature.
· If the whitelist feature is enabled for device automation, the controller does the following when it deploys a device:
¡ If the serial number of the device is in the device list, the controller obtains the corresponding device role template (automation template) to complete automated onboarding for the device.
¡ If the serial number of the device is not in the device list, automated onboarding for the device fails.
· If the whitelist feature is not enabled for device automation, the controller does the following when it deploys a device:
¡ If the serial number of the device is in the device list, the controller onboards the device based on the device role specified in the device list.
¡ If the serial number of the device is not in the device list, the controller onboards the device based on the default role of the device.
Figure 23 Device list
To add device list entries:
1. Click Add to add a device to the device list manually, or click Import to down the import template to add multiple devices in bulk. The following uses manual configuration as an example.
2. Configure the following parameters to add a device:
¡ Network Type: VXLAN by default.
¡ WebSocket: If you select Yes, the controller and the device use WebSocket communication. You must select Yes for optimized automation configuration. This document describes the original automated deployment procedure, so select the No option.
¡ Serial Number: Enter the SN of the device, which uniquely identifies the device. For a modular device, enter the SNs of the chassis and MPUs (semicolon separated). To obtain device SN information, use the following commands:
- On the S10500X/S10500 switch series, view chassis information and MPU information:
display device manuinfo chassis * slot *
- On the S7500E switch series, view MPU information.
display device manuinfo chassis * slot *
- On fixed-port devices (S6550XE/S6525XE/6520X/S5560X series), view information about slot 1:
display license device-id slot 1
- On the S7500X series, view MPU information.
display device manuinfo chassis * slot *
- On the fixed-port S51 series, view manufacturing information about slot 1:
display device manuinfo slot 1
|
|
NOTE: If you are not sure about the device series, contact Technical Support for help. |
¡ Device Role: Options are Spine, Leaf, Access, and Aggregation. The controller will configure a device with the role or roles you specify for the device in the device list.
¡ Device System Name: The sysname of the device. The controller changes the sysname of the device to the one specified for it in the device list during device onboarding.
· Management IP: Specifies the management IP address for the VSI-interface 4094 or VLAN-interface 4094 after the device is onboarded. This parameter is optional.
- If the management IP address is configured, the SeerEngine-Campus controller will assign the configured address to the device after the device is onboarded.
- If the management IP address is not configured, the SeerEngine-Campus controller will assign an address automatically selected from the VLAN4094 address pool.
¡ Underlay IP: Specifies the IP address for the Loopback 0 interface after the device is onboarded. This parameter is optional.
- If the underlay IP address is configured, the SeerEngine-Campus controller will assign the configured address to the device after the device is onboarded.
- If the underlay IP address is not configured, the SeerEngine-Campus controller will assign an address automatically selected from the underlay IP range.
¡ Site Name: Select the site to which the device belongs, or configure it as needed. You must specify this parameter if you are using the dashboard feature.
Figure 24 Adding a device list entry
Configuring a policy template
Policy templates are for service control and provisioning. They are not part of automatic device deployment. For more information about configuring policy templates, see AD-Campus 6.2 Basic Configuration Guide.
Preparing for a single-leaf architecture deployment
Configuring the L3 switch
See Configuring the L3 switch.
Configuring IRF stacking for leaf devices
The following only describes the configuration required for setting up a leaf fabric:
1. Connect one of the leaf devices to the L3 switch. Connect the leaf devices to each other.
2. In the single-leaf template, specify the uplink interface as an aggregate interface.
3. Manually configure downlink interface aggregation on the L3 switch.
#
interface Ten-GigabitEthernet0/0/48
port link-mode bridge
port link-type trunk
port trunk permit vlan all
port link-aggregation group 102
#
interface Ten-GigabitEthernet0/0/47
port link-mode bridge
port link-type trunk
port trunk permit vlan all
port link-aggregation group 102
#
interface Bridge-Aggregation102
port link-type trunk
port trunk permit vlan all
link-aggregation mode dynamic
#
4. Leaf devices obtain VLAN 1 and form a fabric successfully.
5. Connect the other leaf device in the fabric to the L3 switch, and manually aggregate the uplink interfaces (use the same aggregate interface as configured in the template).
Configuring the controller
The following only lists the single-leaf configuration different from the three-tier configuration.
1. On the basic info page, the RR MAC address is not required.
2. On the device role templates configuration page:
¡ Deselect the Spine Template, and select Leaf Template/Single Leaf Template and Access Template.
¡ In the Leaf Template/Single Leaf Template area, select Single Leaf Template.
¡ Configure the uplink interface as the interface that connects the leaf device to the L3 switch.
Figure 25 Single Leaf Template configuration
Automated onboarding
Onboarding a single spine device
Starting the spine device with the factory-default configuration
The spine device starts up with the factory-default configuration and automatically obtains an IP address and the spine configuration template.
Automatic configuration attempt: 10.
Interface used: Vlan-interface1.
Enable DHCP client on Vlan-interface1.
Set DHCP client identifier: 70f96dab1fdf-VLAN0001
Obtained an IP address for Vlan-interface1: 120.1.0.10.
Obtained configuration file name HJYQ.template and TFTP server name 110.1.0.100.
// TFTP server's address on the controller
Resolved the TFTP server name to 110.1.0.100.
INFO: Get device tag file device_tag.csv success.
INFO: Read role spine from tag file.
Successfully downloaded file HJYQ_spine.template.//Name of the spine template on the controller
Executing the configuration file. Please wait...
INFO: Read location spine123 from tag file.
Automatic configuration successfully completed.
Line aux1/0 is available.
Press ENTER to get started.
Spine device automated configuration
The spine device automatically configure itself based on the downloaded template (in this example, the template name is HJYQ_spine.template).
In this phase, the IP address of VSI-interface 4094 is not set yet.
[Spine]display vcf-fabric underlay autoconfigure
success command:
#
system
clock timezone beijing add 08:00:00
#
system
ip vpn-instance vpn-default
route-distinguisher 1:1
vpn-target 1:1 both
address-family evpn
vpn-target 1:1 import-extcommunity
vpn-target 1:1 export-extcommunity
address-family ipv6
vpn-target 1:1 import-extcommunity
vpn-target 1:1 export-extcommunity
#
system
lldp global enable
#
system
interface Vlan-interface1
ip address dhcp-alloc
#
system
ospf 1
non-stop-routing
area 0.0.0.0
#
system
interface LoopBack0
#
system
netconf soap https enable
netconf ssh server enable
restful https enable
#
system
telnet server enable
#
system
info-center loghost 192.168.1.2
#
system
AC interface automated configuration
After the device automatically configures the physical interface connected to the server as an AC interface based on the obtained template, it obtains an IP address for VSI-interface 4094.
#
interface Ten-GigabitEthernet1/1/0/1
port link-mode bridge
port link-type trunk
port trunk permit vlan all
#
service-instance 4094
encapsulation s-vid 4094
xconnect vsi vxlan4094
#
Verifying the deployment result on the spine device
During automatic underlay deployment, you can execute the display interface brief command to monitor the IP assignment status on the spine device.
[spine123]display int brief | in UP
InLoop0 UP UP(s) --
Loop0 UP UP(s) 200.1.1.254
NULL0 UP UP(s) --
REG0 UP -- --
Tun1 UP UP --
Tun2 UP UP --
Vlan1 UP UP 120.1.0.10
Vlan3498 UP UP 200.1.1.254
Vlan3499 UP UP 200.1.1.254
Vsi4092 UP UP 130.1.0.2 SDN_VRF_VSI_Interface_4092
Vsi4094 UP UP 130.1.0.2
XGE1/5/0/1 UP 10G(a) F(a) T 1
XGE1/5/0/13 UP 10G(a) F(a) T 1
XGE1/5/0/15 UP 10G(a) F(a) T 1
XGE1/5/0/19 UP 10G(a) F(a) T 1
In the following sample output, the device has obtained IP addresses for interfaces Loopback 0, VLAN-interface 1, and VSI-interface 4094. The device automatically created VLAN 3498 for one downlink port and created VLAN 3499 for another downlink port. The links are automatically configured as ECMP paths. The VLAN IDs were assigned by the controller from the underlay VLAN range configured in the automation template.
Verifying the spine deployment on the controller
After the spine device is onboarded, navigate to the Automation > Campus Network > Network Devices page of the controller. Verify that the device has been incorporated with the IP address of VSI-interface 4094, and has also been automatically added to the spine device group.
Figure 26 Spine device
Figure 27 Spine device group
Complete deployment of the configuration
The controller does not deploy dynamic BGP peer configuration when there is only one spine device is onboarded. Instead, the controller deploys BGP peer configuration only after a minimum of one leaf device is onboarded, establishes underlay OSPF neighbor relationships, and obtains an interface for its Loopback 0 interface.
The spine template contains only fixed BGP settings.
In user view, you can use the dir command to identify the template file named HJYQ_spine.template, and use the more HJYQ_spine.template command to view settings in the template.
For more information about the deployed configuration, see Spine automation template. The parameter values depend on the actual network conditions.
Onboarding a spine IRF fabric
Spine IRF deployment restrictions and guidelines
To automatically deploy a dual-spine IRF fabric, make sure the following requirements are met:
· Verify that the two devices can establish an IRF fabric.
· Connect the two devices through 10 GE (or higher speed) ports.
· The two devices have the same role.
When you deploy a spine IRF fabric, use the following procedure:
1. Connect the two devices to the L3 switch.
2. Connect the two devices to each other.
3. First onboard the device with a higher bridge MAC address.
|
|
NOTE: You need to connect the second IRF member device to the L3 switch only if an uplink aggregation is desired. In this situation, you must specify the uplink interface as an aggregate interface, and manually aggregate the links towards the spine device on the L3 switch. |
Spine1:
%Sep 30 10:43:06:700 2017 spine-0.137 VCF/5/VCF_IRF_FOUND: -MDC=1; In phase 2.0.1, device with MAC address 487a-dae0-ce00 found peer 50da-006d-6600 with the same role spine. Availability of IRF configuration is 0.
%Sep 30 10:43:46:745 2017 spine-0.137 VCF/5/VCF_IRF_START: -MDC=1; In phase 2.0.2, device with MAC address 487a-dae0-ce00 started IRF configuration: Current member ID 2, new member ID 2, priority 31, [None] bound to IRF-port 1, ['Ten-GigabitEthernet1/3/0/45'] bound to IRF-port 2.
%Sep 30 10:44:42:992 2017 spine-0.137 VCF/5/VCF_IRF_FINISH: -MDC=1; In phase 2.0.3, device with MAC address 487a-dae0-ce00 finished IRF configuration with peer 50da-006d-6600. The result is 0.
Spine2:
%Sep 30 09:21:32:258 2017 75inA301 VCF/5/VCF_IRF_FOUND: -MDC=1; In phase 2.0.1, device with MAC address 50da-006d-6600 found peer 487a-dae0-ce00 with the same role spine. Availability of IRF configuration is 0.
%Sep 30 10:43:23:942 2017 75inA301 VCF/5/VCF_IRF_START: -MDC=1; In phase 2.0.2, device with MAC address 50da-006d-6600 started IRF configuration: Current member ID 1, new member ID 1, priority 2, ['Ten-GigabitEthernet1/2/0/1'] bound to IRF-port 1, [None] bound to IRF-port 2.
%Sep 30 10:44:23:262 2017 75inA301 VCF/5/VCF_IRF_FINISH: -MDC=1; In phase 2.0.3, device with MAC address 50da-006d-6600 finished IRF configuration with peer 487a-dae0-ce00. The result is 0.
%Sep 30 10:44:30:055 2017 75inA301 VCF/5/VCF_IRF_REBOOT: -MDC=1; In phase 2.0.4, device with MAC address 50da-006d-6600 will reboot.
%Sep 30 10:45:35:113 2017 75inA301 DEV/5/SYSTEM_REBOOT: -MDC=1; System is rebooting now.
The standby device restarts to form an IRF fabric with the master device:
%Sep 30 11:51:34:904 2017 spine-0.137 VCF/5/VCF_IRF_ALREADY: -MDC=1; In phase 2.0.10, device with MAC address 487a-dae0-ce00 has been irf successfully, standby Mac 50da-006d-6600.
<spine-0.137>display irf
MemberID Slot Role Priority CPU-Mac Description
1 0 Standby 2 00e0-fc0a-15e0 ---
*+2 0 Master 31 00e0-fc0f-8c13 ---
--------------------------------------------------
* indicates the device is the master.
+ indicates the device through which the user logs in.
The bridge MAC of the IRF is: 487a-dae0-ce00
Auto upgrade : yes
Mac persistent : always
Domain ID : 0
Auto merge : yes
IRF mode : normal
After the IRF fabric is established, the IRF fabric automatically configures BFD MAD:
%Feb 28 05:08:12:592 2011 leaf-0.14 LLDP/5/LLDP_PVID_INCONSISTENT: PVID mismatch discovered on Ten-GigabitEthernet1/0/15 (PVID 100), with leaf-0.14 Ten-GigabitEthernet5/0/15 (PVID 1).
%Feb 28 05:08:12:592 2011 leaf-0.14 LLDP/6/LLDP_CREATE_NEIGHBOR: Nearest bridge agent neighbor created on port Ten-GigabitEthernet1/0/15 (IfIndex 15), neighbor's chassis ID is 9428-2eb8-afc4, port ID is Ten-GigabitEthernet5/0/15.
%Feb 28 05:08:12:753 2011 leaf-0.14 IFNET/3/PHY_UPDOWN: Physical state on the interface Vlan-interface100 changed to up.
%Feb 28 05:08:12:754 2011 leaf-0.14 IFNET/5/LINK_UPDOWN: Line protocol state on the interface Vlan-interface100 changed to up.
%Feb 28 05:08:17:143 2011 leaf-0.14 OPTMOD/5/RX_POW_NORMAL: -Slot=5; Ten-GigabitEthernet5/0/15: RX power is normal!
%Feb 28 05:08:18:290 2011 leaf-0.14 BFD/5/BFD_MAD_INTERFACE_CHANGE_STATE: BFD MAD function enabled on Vlan-interface100 changed to the normal state.
If there is more than one IRF link, the IRF fabric uses one of the links as the BFD MAD link, and configures the physical interface with the following settings:
#
interface Ten-GigabitEthernet1/0/15
port link-mode bridge
port access vlan 100
undo stp enable
#
interface Ten-GigabitEthernet5/0/15
port link-mode bridge
port access vlan 100
undo stp enable
#
The IRF fabric configures VLAN-interface 100, and assigns a MAD IP address for each of the devices on the interface:
#
interface Vlan-interface100
mad bfd enable
mad ip address 192.168.100.2 255.255.255.0 member 1
mad ip address 192.168.100.1 255.255.255.0 member 2
#
Manually enable BFD MAD on the device:
[spine] mad bfd enable
Multiple links between spine and leaf devices
If the spine device has multiple links to a leaf device, the links are automatically configured as ECMP paths.
[spine]display lldp neighbor-information list | in leaf2
XGE1/5/0/13 88df-9e62-ee50 Ten-GigabitEthernet1/0/11 leaf2
XGE1/5/0/19 88df-9e62-ee50 Ten-GigabitEthernet5/0/33 leaf2
[spine]display vcf-fabric underlay autoconfigure
Downlink interface:
Ten-GigabitEthernet1/5/0/13
Ten-GigabitEthernet1/5/0/19
LoopBack0 IP allocation:
Device_MAC Loopback_IP Management_IP State
88df-9e62-ee50 200.1.1.253 120.1.0.14 Up
70f9-6dab-1fdf 200.1.1.254 120.1.0.10 Up
0000-fc00-a001 200.1.1.249 120.1.0.13 Up
50da-0054-f400 200.1.1.251 120.1.0.12 Up
IRF allocation:
Self Bridge Mac: 70f9-6dab-1fdf
IRF Status: No
Member List: [1]
VLAN ID Allocation:
VLAN range: 3001-3500
VLAN exist and system reserved:
[1]
Interface VLAN ID
Ten-GigabitEthernet1/5/0/13 3500
Ten-GigabitEthernet1/5/0/19 3499
Verify that ECMP routes over the links have been generated in the routing table:
[spine]dis ip routing-table 200.1.1.253
Summary count : 2
Destination/Mask Proto Pre Cost NextHop Interface
200.1.1.253/32 O_INTRA 10 2 200.1.1.253 Vlan3500
200.1.1.253 Vlan3499
Onboarding a single leaf device
Restarting the leaf device with the factory-default configuration
On startup, the leaf device obtains an IP address and the leaf template. The following is the sample output:
Automatic configuration attempt: 14.
Interface used: Vlan-interface1.
Enable DHCP client on Vlan-interface1.
Set DHCP client identifier: 0000fc005eae-VLAN0001
Obtained an IP address for Vlan-interface1: 120.1.0.8.
Obtained configuration file name HJYQ.template and TFTP server name 110.1.0.100.
// TFTP server's address on the controller
Resolved the TFTP server name to 110.1.0.100.
INFO: Get device tag file device_tag.csv success.
INFO: Read role leaf from tag file.
Successfully downloaded file HJYQ_leaf.template. //Leaf template name on the controller
Executing the configuration file. Please wait...
INFO: Read location 6520X from tag file.
Automatic configuration successfully completed.
Line aux1/0 is available.
Press ENTER to get started.
The leaf device automatically configures itself based on the obtained leaf configuration template. In user view, you can use the dir command to identify the template file named HJYQ_leaf.template, and use the more HJYQ_leaf.template command to view settings in the template.
For more information about the template, see Leaf automation template. The parameter values depend on the actual network conditions.
Automatic configuration of the leaf interfaces
The leaf device automatically detects and configures the uplink and downlink ports.
Uplink port configuration
This example has only one spine-leaf link, which is assigned to VLAN 3498. If multiple links were deployed, each link would be assigned to one distinct VLAN and the links would be configured as ECMP paths.
#
interface Ten-GigabitEthernet1/1/0/23
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
#
Downlink port configuration
The downlink ports will be configured as trunk ports, on each of which service instance 4094 will be configured to match VLAN 4094 and associated with VSI vxlan4094 for traffic forwarding.
#
interface Ten-GigabitEthernet1/1/0/35
port link-mode bridge
port link-type trunk
port trunk permit vlan 1 101 to 3000 4094
#
service-instance 4094
encapsulation s-vid 4094
xconnect vsi vxlan4094
#
Verifying the deployment result
During the deployment, you can verify each phase of the deployment.
# Initially, verify that the leaf device has obtained an IP address for VLAN-interface 1 and interface Loopback 0. The leaf-spine link has been assigned to a VLAN (VLAN 3498 in this example, from the underlay VLAN range defined in the automation template) and assigned the IP address borrowed from Loopback 0.
[7503EM]display int brief | in UP
InLoop0 UP UP(s) --
Loop0 UP UP(s) 200.1.1.250
NULL0 UP UP(s) --
REG0 UP -- --
Tun1 UP UP --
Tun3 UP UP --
Vlan1 UP UP 120.1.0.8
Vlan3498 UP UP 200.1.1.250
Vsi4092 UP UP 130.1.0.3 SDN_VRF_VSI_Interface_4092
Vsi4094 UP UP 130.1.0.3
XGE1/1/0/23 UP 10G(a) F(a) T 1
XGE1/1/0/35 UP 10G(a) F(a) T 1
# Verify that the leaf and spine devices have established an OSPF neighbor relationship.
#
interface Vlan-interface 3498
ip address unnumbered interface LoopBack0
ospf network-type p2p
ospf 1 area 0.0.0.0
#
[7503EM]display ospf peer
OSPF Process 1 with Router ID 200.1.1.250
Neighbor Brief Information
Area: 0.0.0.0
Router ID Address Pri Dead-Time State Interface
200.1.1.254 200.1.1.254 1 40 Full/ - Vlan3498
# Verify that the spine and leaf devices have establishes a BGP peer relationship.
After the master RR detects the leaf device, the Director issues BGP settings (for BGP 100 in this example) to the spine and leaf devices for them to establish a BGP peer relationship.
The following is the deployed sample BGP configuration on the leaf device:
#
bgp 100
non-stop-routing
router-id 200.1.1.250
peer200.1.1.254 as-number 100
peer200.1.1.254 connect-interface LoopBack0
#
address-family l2vpn evpn
peer200.1.1.254 enable
#
ip vpn-instance vpn-default
#
address-family ipv4 unicast
import-route static
#
return
# Establish a BGP EVPN peer relationship between the leaf and spine devices:
[7503EM]display bgp peer l2vpn evpn
BGP local router ID: 200.1.1.250
Local AS number: 100
Total number of peers: 1 Peers in established state: 1
* - Dynamically created peer
Peer AS MsgRcvd MsgSent OutQ PrefRcv Up/Down State
200.1.1.254 100 99 44 0 14 00:28:30 Established
After the spine and leaf devices establish a BGP EVPN peer relationship and the VXLAN tunnel between them comes up, the leaf device obtains an IP address for VSI interface 4094.
# On the controller, navigate to the Automation > Campus Network > Network Devices page.
# Verify that the device has been incorporated with the IP address of VSI-interface 4094.
Figure 28 Leaf device
# Verify that the device has been automatically added to the leaf device group.
Figure 29 Leaf device group
# Verify that the leaf ports are automatically added to the leaf downlink interface group.
Figure 30 Leaf downlink interface group
# On the leaf device, verify that VLANs 101 through 3000 have been deployed on the leaf node.
[leaf1]display vlan
Total VLANs: 2913
The VLANs include:
1(default), 15, 101-3000, 4094
Onboarding multiple leaf devices
Because leaf deployment is automated, you only need to monitor and verify the deployment, especially the deployment of BGP settings.
On the controller, verify that the leaf devices are incorporated.
On the spine device, verify that the device has established BGP EVPN peer relationships with all leaf devices and the VXLAN tunnels between the spine device and each leaf device are up.
In the following sample output, three leaf devices are onboarded.
[spine123]display bgp peer l2vpn evpn
BGP local router ID:200.1.1.254
Local AS number: 100
Total number of peers: 3 Peers in established state: 3
* - Dynamically created peer
Peer AS MsgRcvd MsgSent OutQ PrefRcv Up/Down State
200.1.1.250 2222 48 101 0 6 00:31:56 Established
200.1.1.251 2222 1311 1376 0 5 20:10:17 Established
200.1.1.253 2222 12 21 0 4 00:04:45 Established
Onboarding a leaf IRF fabric
Leaf IRF deployment restrictions and guidelines
To deploy a dual-leaf IRF fabric, make sure the following requirements are met:
· Verify that the two devices can establish an IRF fabric.
· Connect the two devices through 10 GE (or higher speed) ports.
· The two devices have the same role.
When you deploy a spine IRF fabric, use the following procedure:
1. Connect the two devices (Leaf 1 and Leaf 2) to the spine tier.
2. Connect the two devices.
3. Clear the configuration of the two devices and restart them simultaneously.
Leaf 1 automatically establishes an IRF fabric with Leaf 2 when Leaf 1 detects that it has a 10 GE (or higher speed) port connected to Leaf 2, and they have the same role.
Leaf 1:
%Sep 30 14:30:24:708 2017 leaf-0.139 VCF/5/VCF_IRF_FOUND: In phase 2.0.1, device with MAC address 600b-038a-92d1 found peer 84d9-3190-0282 with the same role leaf. Availability of IRF configuration is 0.
%Sep 30 14:31:04:719 2017 leaf-0.139 VCF/5/VCF_IRF_START: In phase 2.0.2, device with MAC address 600b-038a-92d1 started IRF configuration: Current member ID 5, new member ID 5, priority 1, [None] bound to IRF-port 1, ['Ten-GigabitEthernet5/1/17'] bound to IRF-port 2.
%Sep 30 14:32:03:817 2017 leaf-0.139 VCF/5/VCF_IRF_FINISH: In phase 2.0.3, device with MAC address 600b-038a-92d1 finished IRF configuration with peer 84d9-3190-0282. The result is 0.
Leaf 2:
%Sep 30 14:30:53:272 2017 leaf-0.140 VCF/5/VCF_IRF_FOUND: In phase 2.0.1, device with MAC address 84d9-3190-0282 found peer 600b-038a-92d1 with the same role leaf. Availability of IRF configuration is 0.
%Sep 30 14:31:33:286 2017 leaf-0.140 VCF/5/VCF_IRF_START: In phase 2.0.2, device with MAC address 84d9-3190-0282 started IRF configuration: Current member ID 1, new member ID 1, priority 2, ['Ten-GigabitEthernet1/3/17'] bound to IRF-port 1, [None] bound to IRF-port 2.
%Sep 30 14:32:30:523 2017 leaf-0.140 VCF/5/VCF_IRF_FINISH: In phase 2.0.3, device with MAC address 84d9-3190-0282 finished IRF configuration with peer 600b-038a-92d1. The result is 0.
The standby device restarts to form an IRF fabric with the master device:
%Sep 30 14:32:08:402 2017 leaf-0.139 VCF/5/VCF_IRF_REBOOT: In phase 2.0.4, device with MAC address 600b-038a-92d1 will reboot.
%Sep 30 14:32:12:511 2017 leaf-0.139 DEV/5/SYSTEM_REBOOT: System is rebooting now.
%Sep 30 14:36:36:263 2017 leaf-0.140 VCF/5/VCF_IRF_ALREADY: In phase 2.0.10, device with MAC address 84d9-3190-0282 has been irf successfully, standby Mac 600b-038a-92d1.
<leaf-0.140>display irf
MemberID Role Priority CPU-Mac Description
*+1 Master 2 00e0-fc0f-8c02 ---
5 Standby 1 00e0-fc0f-8c06 ---
--------------------------------------------------
* indicates the device is the master.
+ indicates the device through which the user logs in.
The bridge MAC of the IRF is: 84d9-3190-0282
Auto upgrade : yes
Mac persistent : always
Domain ID : 0
After the IRF fabric is established, the IRF fabric automatically configures BFD MAD:
%Feb 28 05:08:12:592 2011 leaf-0.14 LLDP/5/LLDP_PVID_INCONSISTENT: PVID mismatch discovered on Ten-GigabitEthernet1/0/15 (PVID 100), with leaf-0.14 Ten-GigabitEthernet5/0/15 (PVID 1).
%Feb 28 05:08:12:592 2011 leaf-0.14 LLDP/6/LLDP_CREATE_NEIGHBOR: Nearest bridge agent neighbor created on port Ten-GigabitEthernet1/0/15 (IfIndex 15), neighbor’s chassis ID is 9428-2eb8-afc4, port ID is Ten-GigabitEthernet5/0/15.
%Feb 28 05:08:12:753 2011 leaf-0.14 IFNET/3/PHY_UPDOWN: Physical state on the interface Vlan-interface100 changed to up.
%Feb 28 05:08:12:754 2011 leaf-0.14 IFNET/5/LINK_UPDOWN: Line protocol state on the interface Vlan-interface100 changed to up.
%Feb 28 05:08:17:143 2011 leaf-0.14 OPTMOD/5/RX_POW_NORMAL: -Slot=5; Ten-GigabitEthernet5/0/15: RX power is normal!
%Feb 28 05:08:18:290 2011 leaf-0.14 BFD/5/BFD_MAD_INTERFACE_CHANGE_STATE: BFD MAD function enabled on Vlan-interface100 changed to the normal state.
If there is more than one IRF link, the IRF fabric uses one of the links as the BFD MAD link, and configures the physical interface with the following settings:
#
interface Ten-GigabitEthernet1/0/15
port link-mode bridge
port access vlan 100
undo stp enable
#
interface Ten-GigabitEthernet5/0/15
port link-mode bridge
port access vlan 100
undo stp enable
#
The IRF fabric configures VLAN-interface 100, and assigns a MAD IP address for each of the devices on the interface:
#
interface Vlan-interface100
mad bfd enable
mad ip address 192.168.100.2 255.255.255.0 member 1
mad ip address 192.168.100.1 255.255.255.0 member 2
#
4. Manually enable BFD MAD on the IRF fabric.
[leaf]mad bfd enable
Adding redundant spine-leaf links
The redundant links between a leaf IRF fabric and a spine device (or spine IRF fabric) are each assigned to a VLAN and are automatically configured as ECMP paths.
Execute the display lldp neighbor-information command to display the spine-leaf links:
[leaf2] display lldp neighbor-information list | in spine
XGE1/0/11 70f9-6dab-1fdf Ten-GigabitEthernet1/5/0/13 spine
XGE5/0/33 70f9-6dab-1fdf Ten-GigabitEthernet1/5/0/19 spine
<leaf2>display vlan
Total VLANs: 3407
The VLANs include:
1(default), 2,101-3500, 3498-3499, 4094 //VLAN 3498 was created for one uplink and VLAN 3499 for the other.
<leaf2>display vlan brief
5 VLAN 3498 BAGG1024 XGE1/0/15 XGE5/0/33 XGE5/0/47
8 VLAN 3499 BAGG1024 XGE1/0/11 XGE1/0/15 XGE5/0/47
Adding redundant leaf-access links
|
|
IMPORTANT: With automated underlay deployment, each aggregation can have only two physical links. |
Redundant leaf-access links are automatically aggregated.
The following are the sample messages during this process:
%Sep 30 15:05:51:383 2017 access-0.130 LAGG/6/LAGG_ACTIVE: Member port XGE1/0/50 of aggregation group BAGG1024 changed to the active state.
%Sep 30 15:05:51:390 2017 access-0.130 IFNET/5/LINK_UPDOWN: Line protocol state on the interface Ten-GigabitEthernet1/0/50 changed to up.
%Sep 30 15:05:51:478 2017 access-0.130 IFNET/3/PHY_UPDOWN: Physical state on the interface Bridge-Aggregation1024 changed to up.
%Sep 30 15:05:51:482 2017 access-0.130 IFNET/5/LINK_UPDOWN: Line protocol state on the interface Bridge-Aggregation1024 changed to up.
%Sep 30 15:05:55:437 2017 access-0.130 VCF/6/VCF_AGGR_CREATE: In phase 2.0.5, device with MAC address 741f-4aea-80d1 created aggregation group 1024. The member port list is Ten-GigabitEthernet1/0/50,Ten-GigabitEthernet1/0/49.
<access-0.130>display link-aggregation verbose
Loadsharing Type: Shar -- Loadsharing, NonS -- Non-Loadsharing
Port Status: S -- Selected, U -- Unselected, I -- Individual
Port: A -- Auto port, M -- Management port, R -- Reference port
Flags: A -- LACP_Activity, B -- LACP_Timeout, C -- Aggregation,
D -- Synchronization, E -- Collecting, F -- Distributing,
G -- Defaulted, H -- Expired
Aggregate Interface: Bridge-Aggregation1024
Aggregation Mode: Dynamic
Loadsharing Type: Shar
Management VLANs: None
System ID: 0x8000, 741f-4aea-80d1
Local:
Port Status Priority Index Oper-Key Flag
XGE1/0/49 S 32768 2 2 {ACDEF}
XGE1/0/50(R) S 32768 1 1 {ACDEF}
Remote:
Actor Priority Index Oper-Key SystemID Flag
XGE1/0/49 32768 2 2 0x8000, 84d9-3190-0282 {ACDEF}
XGE1/0/50 32768 1 1 0x8000, 84d9-3190-0282 {ACDEF}
After the aggregate interface is created, the controller automatically removes the original configuration of the aggregation member ports and reconfigures the downlink settings on the aggregate interface.
Onboarding a single access device
Before you onboard an access device, make sure its upstream leaf device has been onboarded and come online.
If you manually incorporate an access device, you must make sure its upstream leaf device has been incorporated in the controller and is online.
If automated onboarding of the device fails, clear the device configuration and try automated deployment again.
Restarting the leaf device with the factory-default configuration
Restart the access device after you restore its factory-default configuration.
On startup, the access device automatically obtains an IP address for VLAN-interface 1 and the access device configuration template. The following is the sample output:
Automatic configuration attempt: 2.
Interface used: Vlan-interface1.
Enable DHCP client on Vlan-interface1.
Set DHCP client identifier: 487ada2f7ad2-VLAN0001
Obtained an IP address for Vlan-interface1: 120.1.0.7.
Obtained configuration file name HJYQ.template and TFTP server name 110.1.0.100.
//TFTP server's address on the controller
Resolved the TFTP server name to 110.1.0.100.
INFO: Get device tag file device_tag.csv success.
INFO: Read role access from tag file.
Successfully downloaded file HJYQ_access.template. //Name of the access template on the controller
Executing the configuration file. Please wait...
INFO: Read location access3 from tag file.
Automatic configuration successfully completed.
Line aux4 is available.
Press ENTER to get started.
Automatic configuration of the access device
The access device automatically configures itself based on the obtained access device template (for example, HJYQ_access.template).
Each downlink port on the device will be assigned a unique PVID. If the access device is PoE capable, PoE will be enabled on all PoE-capable ports. If an AP device is attached to a port, VLAN 4093 will be deployed and set as the PVID of that port.
In user view, you can use the dir command to identify the template file named HJYQ_access.template, and use the more HJYQ_access.template command to view settings in the template.
For more information about the template, see Access automation template. The parameter values depend on the actual network conditions.
Verifying the deployment result on the access device
After the access device is configured, verify that the access device has obtained an IP address for VLAN-interface 1 and VLAN-interface 4094.
[acces3]display int brief | in UP
InLoop0 UP UP(s) --
NULL0 UP UP(s) --
Vlan1 UP UP 120.1.0.7
Vlan4094 UP UP 130.1.0.35
XGE1/0/25 UP 10G(a)
Verify that the uplink port on the access device is configured as a trunk port and permits all VLANs to pass through:
#
interface Ten-GigabitEthernet1/0/25
port link-type trunk
port trunk permit vlan all
#
Verify the settings on interfaces. In the following sample output, the interface is PoE enabled and assigned PVID 4093 because an AP is attached to it.
#
interface GigabitEthernet5/0/5
port link-type trunk
port trunk permit vlan all
port trunk pvid vlan 4093
poe enable
#
Verifying the access deployment on the controller
View devices on the controller. Verify that the access device has been incorporated as a managed device. Its management IP address has changed from the IP address of VLAN-interface 1 to that of VLAN-interface 4094.
Figure 31 Access device
Verify that the access device has been assigned to the access device group.
Figure 32 Access device group
Onboarding an access IRF fabric
Deploying the access IRF fabric
1. Connect the two devices (Access 1 and Access 2) to the leaf tier.
2. Connect the two devices.
3. Clear the configuration of the two devices and restart them simultaneously.
Access 1 automatically establishes an IRF fabric with Access 2 when it detects that it has a 10 GE port connected to Access 2, and they have the same role.
4. Verify that the IRF fabric has been established.
<access3>dis irf
MemberID Role Priority CPU-Mac Description
*+1 Master 2 00e0-fc0f-8c02 ---
5 Standby 1 00e0-fc0f-8c06 ---
--------------------------------------------------
* indicates the device is the master.
+ indicates the device through which the user logs in.
The bridge MAC of the IRF is: 50da-00ea-d9f8
Auto upgrade : yes
Mac persistent : always
Domain ID : 0
|
|
NOTE: This solution does not support automated configuration of BFD MAD for IRF fabrics at the access tier. |
5. Manually configure BFD MAD:
# Ensure that the physical interfaces for BFD MAD are down, and then configure BFD MAD.
#
vlan 100 //This VLAN is used for BFD MAD only.
#
#
interface GigabitEthernet1/0/20
port link-type trunk
undo port trunk permit vlan 1
port trunk permit vlan 100
undo stp enable
stp edged-port //If this command was not included, audit difference would be found with the controller.
undo lldp enable
#
#
interface GigabitEthernet5/0/20
port link-type trunk
undo port trunk permit vlan 1
port trunk permit vlan 100
undo stp enable
stp edged-port // If this command was not included, audit difference would be found with the controller.
undo lldp enable
#
#
interface Vlan-interface100
mad bfd enable
mad ip address 192.168.100.1 255.255.255.0 member 1
mad ip address 192.168.100.5 255.255.255.0 member 5
#
# Connect the physical interfaces for BFD MAD, and verify that BFD MAD operates correctly.
[5130s-hi-down]disp mad verbose
Multi-active recovery state: No
Excluded ports (user-configured):
Excluded ports (system-configured):
IRF physical interfaces:
Ten-GigabitEthernet1/0/25
Ten-GigabitEthernet5/0/25
BFD MAD interfaces:
Bridge-Aggregation1022
Bridge-Aggregation1024
GigabitEthernet1/0/2
GigabitEthernet1/0/20
GigabitEthernet5/0/1
GigabitEthernet5/0/20
Ten-GigabitEthernet1/0/26
Ten-GigabitEthernet5/0/26
Vlan-interface100
MAD ARP disabled.
MAD ND disabled.
MAD LACP disabled.
MAD BFD enabled interface: Vlan-interface99
MAD status : Normal
Member ID MAD IP address Neighbor MAD status
1 192.168.100.1/24 5 Normal
5 192.168.100.5/24 1 Normal
Automatic leaf-access link aggregation
|
|
IMPORTANT: With automated underlay deployment, each aggregation can have only two physical links. |
<access3> display lldp neighbor-information list | inc leaf
GE1/0/15 9428-2eb8-8742 Ten-GigabitEthernet1/0/17 leaf1
GE5/0/15 9428-2eb8-8742 Ten-GigabitEthernet1/0/25 leaf1
<access3>display vlan brief
Brief information about all VLANs:
Supported Minimum VLAN ID: 1
Supported Maximum VLAN ID: 4094
Default VLAN ID: 1
VLAN ID Name Port
1 VLAN 0001 BAGG1024 GE1/0/15 GE5/0/15
101 VLAN 0101 BAGG1024 GE1/0/1 GE1/0/15
Deploying multiple tiers of access devices
If you are deploying multiple tiers of access devices, use GE ports to cascade them.
The solution supports up to three access tiers, with access tier 1 directly connected to the leaf tier, access tier 2 connected to access tier 1, and so on.
|
|
NOTE: When a tier-1 device is deployed, its downlink ports are assigned PVIDs in the range of 101 to 3000. When a downlink port on the device comes up, its PVID changes to 1 if the port connects to an H3C switch. This change ensures automatic deployment of the lower-tier access device. If the tier-1 device is not an H3C device, you must manually change the PVID of the downlink port to 1. With automated deployment, a lower-tier access device can have a maximum of two physical links aggregated to connect to its higher-tier access device. |
Restarting a lower-tier access device with the factory-default configuration
On startup, the access device (for example, a tier-2 access device) automatically configures itself. The following sample output shows the automated onboarding process:
Automatic configuration attempt: 2.
Interface used: Vlan-interface1.
Enable DHCP client on Vlan-interface1.
Set DHCP client identifier: 487ada92a6cb-VLAN0001
Obtained an IP address for Vlan-interface1: 120.1.0.102.
Obtained configuration file name HJYQ.template and TFTP server name 110.1.0.100
// TFTP server's address on the controller
Resolved the TFTP server name to 110.1.0.100.
INFO: Get device tag file device_tag.csv success.
INFO: Read role access from tag file.
Successfully downloaded file HJYQ_access.template. //Name of the access template on the controller
Executing the configuration file. Please wait...
INFO: Read location access22 from tag file.
Automatic configuration successfully completed.
Line aux4 is available.
Press ENTER to get started.
Verifying the deployment
Verify that VLAN-interface 1 and VLAN-interface 4094 have each obtained an IP address:
[access22]dis int brief
Brief information on interfaces in route mode:
Link: ADM - administratively down; Stby - standby
Protocol: (s) - spoofing
Interface Link Protocol Primary IP Description
InLoop0 UP UP(s) --
NULL0 UP UP(s) --
Vlan1 UP UP 120.1.0.102
Vlan4094 UP UP 130.1.0.32
On the controller, verify that the tier-2 access device has been incorporated.
Figure 33 Access device
The tier-2 access device can be automatically added to the access device group.
Figure 34 Access device group
Automated IPv6 deployment
To automate IPv6 deployment, configure a VLAN4094 IPv6 address pool in the automation template. Then, the network devices will obtain IPv6 configuration from the template. For more information about IPv6 configuration, see AD-Campus 6.2 IPv6 Service Configuration Guide.
Upgrading software
You can upgrade same-model devices in bulk by specifying the target software version in the automation template (see "Configuring device role templates"). You can also upgrade devices on the Automation > Configuration Center > Software Library page.
|
|
NOTE: For successful software upgrade during automated deployment, the remaining space on the device side must be twice the size of the uploaded version. The S7500E switches and the S10500 switches that use the LSU1SUPB0 MPU cannot meet the requirement because of their small storage space. For these devices, upgrade their software manually before automated deployment or from Unified Platform after the devices are incorporated into Unified Platform. |
To upgrade software:
1. Select Automation > Configuration Center > Deploy Parameters > VPN Instances, and add the management VPN instance. The instance name is vpn-default.
Figure 35 Adding management VPN instance
2. Select Automation > Configuration Center > Software Library. Click Import, and then upload the software version file required for upgrade.
Figure 36 Import software
3. Click Deploy.
Figure 37 Deploying software
4. Select devices to upgrade, and then select the software to deploy.
Figure 38 Selecting devices and software
5. Check the device space.
Figure 39 Checking device space
6. Select Set Task Attributes, and select a schedule time as needed.
Figure 40 Setting task attributes
7. Review the deployment settings, and then click Finish.
Figure 41 Review settings
Figure 42 Software upgrade task
8. To view detailed information about specific steps, click Operation Result, and then select Details.
Figure 43 Operation result
Figure 44 View details
Figure 45 Step details
Replacing failed devices
For information about replacing failed devices, see AD-Campus Device Replacement Configuration Guide.
Appendix
Spine automation template
## Please note:The following variable names are used by the internal system,please do not use
## _underlayIntfUp _underlayIntfDown _all_leaf _master_spine
## _master_spine_mac _underlayIPRange
##
##NEW_VERSION
#USERDEF
##Template version
template_version = 5.0
##BACKUP_SERVER
##Local user: Username
_username = admin
##Local user: Password
_password = ******
## User roles
_rbacUserRole = network-admin
##ntp_server_begin_var
##IP address of the NTP server
_ntp_server_0 = 100.1.0.100
##ntp_server_end_var
##MAC address of the master spine device
_master_spine_mac = 586a-b1e5-2600
##MAC address of the master spine device and address range of loopback interfaces
##Format: 1122-3344-5566:10.100.0.0/16, AABB-CCDD-EEFF:10.101.0.0/16
_underlayIPRange = 586a-b1e5-2600:200.1.1.0/24
##MAC address and VLAN ID range of the spine device
##Format: 1122-3344-5566:2-100 ,AABB-CCDD-EEFF:101-200
_underlayVLANRange = 586a-b1e5-2600:3001-3500
##IP address of the log host
_loghost_ip = 110.1.0.100
##is_ipv6_begin_var
##Device is automatically online by ipv6
_is_ipv6 = false
##is_ipv6_end_var
##Out of band
_OOB = False
##SSH enabled
_SSH = True
##Disable automatic IRF setup
_irf_disable = false
##Enabling whitelist filtering (False by default)
_white_list_check = true
##Disabling automatic allocation of an underlay IP (False by default)
_ip_disable = false
##Enabling automatic IRF mode switching
_irf_mode_auto_convert = True
##MAD BFD
_mad_vlan = 100
_mad_ip = 192.168.100.1, 192.168.100.2
##BGP AS number
bgp_as_campus = 100
## OSPF router ID is the IP address of loopback 0
_ad_loopback0_routerid = True
[H3CS5560X]
driver = 5560X
_switch_mode = 1
[H3CS6520X]
driver = 6520X
_switch_mode = 1
[H3CS125??G-AF]
driver = 125GAF
_tcam_resource = arp
_vxlan_resource = l3gw
_routing_mode_resource = ipv6-128
##
#STATICCFG
#
clock timezone beijing add 08:00:00
#
ip vpn-instance vpn-default
route-distinguisher 1:1
vpn-target 1:1 both
##address_family_evpn_begin
address-family evpn
vpn-target 1:1 import-extcommunity
vpn-target 1:1 export-extcommunity
##address_family_evpn_end
##address_family_ipv6_begin
address-family ipv6
vpn-target 1:1 import-extcommunity
vpn-target 1:1 export-extcommunity
##address_family_ipv6_end
#
lldp global enable
#
interface Vlan-interface1
ip address dhcp-alloc
#
ospf 1
non-stop-routing
fast-reroute lfa
area 0.0.0.0
#
##loopback0_begin_all
interface LoopBack0
##loopback0_end_all
#
interface $$_underlayIntfDown
ip address unnumbered interface LoopBack0
ospf 1 area 0.0.0.0
ospf network-type p2p
#
netconf soap https enable
netconf ssh server enable
restful https enable
#
ssh server enable
#
info-center loghost $$_loghost_ip
#
stp mode pvst
stp vlan 1 enable
undo stp vlan 2 to 4094 enable
stp global enable
stp vlan 1 priority 0
#
local-user $$_username
password simple $$_password
service-type http https ssh
authorization-attribute user-role $$_rbacUserRole
#
line vty 0 63
authentication-mode scheme
user-role $$_rbacUserRole
#
bgp $$bgp_as_campus
non-stop-routing
address-family l2vpn evpn
ip vpn-instance vpn-default
##address_family_ipv4_unicast_begin
address-family ipv4 unicast
import-route static
##address_family_ipv4_unicast_end
##address_family_ipv6_unicast_begin
address-family ipv6 unicast
import-route static
##address_family_ipv6_unicast_end
#
l2vpn enable
#
vlan 4094
#
interface Vsi-interface4094
ip binding vpn-instance vpn-default
local-proxy-arp enable
##local-proxy-nd_enable_begin
local-proxy-nd enable
##local-proxy-nd_enable_end
arp proxy-send enable
arp send-gratuitous-arp interval 30000
#
interface Vsi-interface4092
ip binding vpn-instance vpn-default
ip address unnumbered interface Vsi-interface4094
##ipv6_address_auto_link_local_begin
ipv6 address auto link-local
##ipv6_address_auto_link_local_end
l3-vni 4092
description SDN_VRF_VSI_Interface_4092
#
vsi vxlan4094
gateway vsi-interface 4094
vxlan 4094
evpn encapsulation vxlan
mac-advertising disable
nd mac-learning disable
arp mac-learning disable
route-distinguisher auto
vpn-target auto export-extcommunity
vpn-target auto import-extcommunity
##ipv6_dhcp_snooping_trust_tunnel_begin
ipv6 dhcp snooping trust tunnel
##ipv6_dhcp_snooping_trust_tunnel_end
loopback-detection action block
loopback-detection enable vlan 4094
#
vxlan tunnel mac-learning disable
vxlan tunnel arp-learning disable
vxlan tunnel nd-learning disable
#
vcf-fabric topology enable
#
vxlan default-decapsulation source interface LoopBack 0
#
snmp-agent
snmp-agent community read ******
snmp-agent community write ******
snmp-agent sys-info version all
snmp-agent packet max-size 4096
#
telnet server enable
#
netconf soap https enable
netconf soap http enable
local-user admin
password simple ******
service-type telnet ssh http https
authorization-attribute user-role network-admin
#
##l3_static_route_begin_all
ip route-static 110.1.0.0 24 120.1.0.1
ip route-static vpn vpn-default 110.1.0.0 24 130.1.0.1
ip route-static 100.1.0.0 24 120.1.0.1
ip route-static vpn vpn-default 100.1.0.0 24 130.1.0.1
ip route-static 101.0.143.0 24 120.1.0.1
ip route-static vpn vpn-default 101.0.143.0 24 130.1.0.1
ip route-static 192.168.2.0 24 120.1.0.1
ip route-static vpn vpn-default 192.168.2.0 24 130.1.0.1
#
##l3_static_route_end_all
##ipv6_static_route_begin_all
ipv6 route-static vpn vpn-default 2020:130A:0:0:0:0:0:0 64 2020:1:0:0:0:0:0:1
ipv6 route-static vpn vpn-default 190:0:0:0:0:0:0:0 64 2020:1:0:0:0:0:0:1
#
##ipv6_static_route_end_all
#
##ntp_server_begin_cmd
ntp-service enable
ntp-service unicast-server $$_ntp_server_0 vpn-instance vpn-default
#
##ntp_server_end_cmd
Leaf automation template
##
## Please note:The following variable names are used by the internal system,please do not use
## _underlayIntfUp _underlayIntfDown _all_leaf _master_spine _backup_spine
## _master_spine_mac
##
##NEW_VERSION
#USERDEF
##Template version
template_version = 5.0
##Local user: Username
_username = admin
##Local user: Password
_password = ******
## User roles
_rbacUserRole = network-admin
##ntp_server_begin_var
##IP address of the NTP server
_ntp_server_0 = 100.1.0.100
##ntp_server_end_var
##master_leaf_mac_begin_var
##MAC address of the master leaf device
_master_leaf_mac =${master_leaf_mac}
##master_leaf_mac_end_var
##IP address of the log host
_loghost_ip = 110.1.0.100
##is_ipv6_begin_var
##Device is automatically online by ipv6
_is_ipv6 = false
##is_ipv6_end_var
##Out of band
_OOB = False
##Supporting aggregation (True by default)
_lagg_enable = True
##Enforcing aggregation
_lagg_force = True
##Do not delete aggregation group
_lagg_fake_delete = True
##SSH enabled
_SSH = True
##Disable automatic IRF setup
_irf_disable = false
##Enabling whitelist filtering (False by default)
_white_list_check = true
##Enabling automatic IRF mode switching
## Enable OLT interface
_olt = true
## OSPF router ID is the IP address of loopback 0
_ad_loopback0_routerid = True
## auto IRF mode convert
_irf_mode_auto_convert = True
##MAD BFD
_mad_vlan = 100
_mad_ip = 192.168.100.1, 192.168.100.2
##BGP AS number
bgp_as_campus = 100
##Disable lldp function when MAD BFD
_mad_undo_lldp=True
[H3CS5560X]
driver = 5560X
_switch_mode = 1
[H3CS6520X]
driver = 6520X
_switch_mode = 1
[H3CS125??G-AF]
driver = 125GAF
_tcam_resource = mix
_vxlan_resource = l3gw
_routing_mode_resource = ipv6-128
[UNISS5600X]
driver = 5560X
_switch_mode = 1
[UNISS6600X]
driver = 6520X
_switch_mode = 1
##
#STATICCFG
#
clock timezone beijing add 08:00:00
#
ip vpn-instance vpn-default
route-distinguisher 1:1
vpn-target 1:1 both
##address_family_evpn_begin
address-family evpn
vpn-target 1:1 import-extcommunity
vpn-target 1:1 export-extcommunity
##address_family_evpn_end
##address_family_ipv6_begin
address-family ipv6
vpn-target 1:1 import-extcommunity
vpn-target 1:1 export-extcommunity
##address_family_ipv6_end
#
lldp global enable
#
dhcp snooping enable vlan 2 to 4094
#
interface Vlan-interface1
ip address dhcp-alloc
#
ospf 1
non-stop-routing
fast-reroute lfa
area 0.0.0.0
#
##loopback0_begin_all
interface LoopBack0
##loopback0_end_all
#
stp mode pvst
stp vlan 1 enable
undo stp vlan 2 to 4094 enable
stp global enable
stp vlan 1 priority 8192
#
netconf soap https enable
netconf ssh server enable
restful https enable
#
ssh server enable
#
info-center loghost $$_loghost_ip
#
local-user $$_username
password simple $$_password
service-type http https ssh
authorization-attribute user-role $$_rbacUserRole
#
line vty 0 63
authentication-mode scheme
user-role $$_rbacUserRole
#
bgp $$bgp_as_campus
non-stop-routing
address-family l2vpn evpn
ip vpn-instance vpn-default
##address_family_ipv4_unicast_begin
address-family ipv4 unicast
##address_family_ipv4_unicast_end
##address_family_ipv6_unicast_begin
address-family ipv6 unicast
##address_family_ipv6_unicast_end
#
interface $$_underlayIntfUp
ip address unnumbered interface LoopBack0
ospf 1 area 0.0.0.0
ospf network-type p2p
#
interface $$_underlayIntfDown
port link-type trunk
port trunk permit vlan 1 4094
##_underlayIntfDown_undo_port_trunk_permit_vlan_mad_position
undo port trunk permit vlan $$_mad_vlan
stp tc-restriction
service-instance 4094
encapsulation s-vid 4094
xconnect vsi vxlan4094
#
interface $$_underlayIntfGe
poe enable
#
interface $$_underlayIntfONU
port link-type trunk
port trunk permit vlan all
undo port trunk permit vlan $$_mad_vlan
#
interface $$_underlayIntfRONU
port link-type trunk
port trunk permit vlan all
undo port trunk permit vlan $$_mad_vlan
#
l2vpn enable
#
vlan 4094
#
interface Vsi-interface4094
ip binding vpn-instance vpn-default
local-proxy-arp enable
##local-proxy-nd_enable_begin
local-proxy-nd enable
##local-proxy-nd_enable_end
arp proxy-send enable
#
interface Vsi-interface4092
ip binding vpn-instance vpn-default
ip address unnumbered interface Vsi-interface4094
##ipv6_address_auto_link_local_begin
ipv6 address auto link-local
##ipv6_address_auto_link_local_end
l3-vni 4092
description SDN_VRF_VSI_Interface_4092
#
vsi vxlan4094
gateway vsi-interface 4094
vxlan 4094
evpn encapsulation vxlan
mac-advertising disable
nd mac-learning disable
arp mac-learning disable
route-distinguisher auto
vpn-target auto export-extcommunity
vpn-target auto import-extcommunity
##ipv6_dhcp_snooping_trust_tunnel_begin
ipv6 dhcp snooping trust tunnel
##ipv6_dhcp_snooping_trust_tunnel_end
dhcp snooping trust tunnel
loopback-detection action block
loopback-detection enable vlan 4094
#
ip verify source exclude vlan 1
ip verify source exclude vlan 4094
#
vxlan tunnel mac-learning disable
vxlan tunnel arp-learning disable
vxlan tunnel nd-learning disable
#
vcf-fabric topology enable
#
vxlan default-decapsulation source interface LoopBack 0
#
#
snmp-agent
snmp-agent community read ******
snmp-agent community write ******
snmp-agent sys-info version all
snmp-agent packet max-size 4096
#
telnet server enable
#
netconf soap https enable
netconf soap http enable
local-user admin
password simple ******
service-type telnet ssh http https
authorization-attribute user-role network-admin
#
##l3_static_route_begin_all
ip route-static 110.1.0.0 24 120.1.0.1
ip route-static vpn vpn-default 110.1.0.0 24 130.1.0.1
ip route-static 100.1.0.0 24 120.1.0.1
ip route-static vpn vpn-default 100.1.0.0 24 130.1.0.1
ip route-static 101.0.143.0 24 120.1.0.1
ip route-static vpn vpn-default 101.0.143.0 24 130.1.0.1
ip route-static 192.168.2.0 24 120.1.0.1
ip route-static vpn vpn-default 192.168.2.0 24 130.1.0.1
#
##l3_static_route_end_all
##ipv6_static_route_begin_all
ipv6 route-static vpn vpn-default 2020:130A:0:0:0:0:0:0 64 2020:1:0:0:0:0:0:1
ipv6 route-static vpn vpn-default 190:0:0:0:0:0:0:0 64 2020:1:0:0:0:0:0:1
#
##ipv6_static_route_end_all
#
##ipv6_dhcp_snooping_enable_begin
ipv6 dhcp snooping enable vlan 2 to 4094
#
##ipv6_dhcp_snooping_enable_end
##ntp_server_begin_cmd
ntp-service enable
ntp-service unicast-server $$_ntp_server_0 vpn-instance vpn-default
#
##ntp_server_end_cmd
Access automation template
##
## Please note:The following variable names are used by the internal system,please do not use
## _underlayIntfUp _underlayIntfDown _all_leaf _master_spine _backup_spine
## _master_spine_mac
##
#USERDEF
##Template version
template_version = 5.0
## User roles
_rbacUserRole = network-admin
##ntp_server_begin_var
##IP address of the NTP server
_ntp_server_0 = 100.1.0.100
##ntp_server_end_var
##IP address of the log host
_loghost_ip = 110.1.0.100
##is_ipv6_begin_var
##Device is automatically online by ipv6
_is_ipv6 = false
##is_ipv6_end_var
##Out of band
_OOB = False
##Supporting aggregation (True by default)
_lagg_enable = True
##Enforcing aggregation
_lagg_force = True
##Do not delete aggregation group
_lagg_fake_delete = True
##lagg role limits
_lagg_role_limits = leaf,access
##SSH enabled
_SSH = True
##Disable automatic IRF setup
_irf_disable = false
##Enabling whitelist matching (False by default)
_white_list_check = true
##Disable lldp function when MAD BFD
_mad_undo_lldp=True
#STATICCFG
#
clock timezone beijing add 08:00:00
#
lldp global enable
#
stp global enable
#
netconf soap https enable
netconf ssh server enable
restful https enable
#
interface Vlan-interface1
ip address dhcp-alloc
#
ssh server enable
#
info-center loghost $$_loghost_ip
#
line vty 0 63
authentication-mode scheme
user-role $$_rbacUserRole
#
interface $$_underlayIntfUp
port link-type trunk
port trunk permit vlan all
#
interface $$_underlayIntfDown
port link-type trunk
undo port trunk permit vlan 1
port trunk pvid vlan 4093
port trunk permit vlan 2 to 4093
#
interface $$_underlayIntfGe
poe enable
#
vlan 4093
#
vlan 4094
#
interface Vlan-interface4094
#
#
vcf-fabric topology enable
#
#
snmp-agent
snmp-agent community read ******
snmp-agent community write ******
snmp-agent sys-info version all
snmp-agent packet max-size 4096
#
telnet server enable
#
netconf soap https enable
netconf soap http enable
local-user admin
password simple ******
service-type telnet ssh http https
authorization-attribute user-role network-admin
#
##l3_static_route_begin_all
ip route-static 110.1.0.0 24 130.1.0.1 preference 50
ip route-static 110.1.0.0 24 120.1.0.1
ip route-static 100.1.0.0 24 130.1.0.1 preference 50
ip route-static 100.1.0.0 24 120.1.0.1
ip route-static 101.0.143.0 24 130.1.0.1 preference 50
ip route-static 101.0.143.0 24 120.1.0.1
ip route-static 192.168.2.0 24 130.1.0.1 preference 50
ip route-static 192.168.2.0 24 120.1.0.1
#
##l3_static_route_end_all
##ipv6_static_route_begin_all
ipv6 route-static 2020:130A:0:0:0:0:0:0 64 2020:1:0:0:0:0:0:1
ipv6 route-static 190:0:0:0:0:0:0:0 64 2020:1:0:0:0:0:0:1
#
##ipv6_static_route_end_all
#
##ntp_server_begin_cmd
ntp-service enable
ntp-service unicast-server $$_ntp_server_0
#
##ntp_server_end_cmd
O&M monitoring
For information about O&M monitoring, see AD-Campus Operations Monitoring Deployment Guide.
