NetEngine 8000 M14, M8 and M4 V800R023C00SPC500 Configuration Guide

Interface Management Configuration

Interface Management Feature Description
Interface Management Configuration

Interface Management Feature Description

Overview of Interface Management

Definition

An interface is a point of interaction between devices on a network. Interfaces are classified into physical and logical interfaces.

Physical interfaces physically exist on boards.
Logical interfaces are manually configured interfaces that do not exist physically. They are used to exchange data.

Purpose

A physical interface connects a device to another device using a transmission medium (for example, a cable). The physical interface and transmission medium together form a transmission channel that transmits data between the devices. Before data reaches a device, it must pass through the transmission channel. In addition, sufficient bandwidth must be provided to reduce channel congestion.

A logical interface does not require additional hardware resources, thereby reducing investment costs.

Generally, a switching device provides multiple interfaces, many of which have the same configuration. To simplify the configuration of interfaces, create an interface group and add interfaces to the interface group. When you run a command in the interface group view, the system automatically applies the command to all the interfaces in the interface group. In this manner, interfaces in a group are configured in batches.

Benefits

Interface management brings the following benefits to users:

Data can be transmitted properly over a transmission channel that a physical interface and a transmission medium form, therefore enabling communication between users.
Data communication can be implemented using logical interfaces, without additional hardware requirements.
An interface group can be used to implement batch interface configurations, simplifying interface configurations and reducing management costs.

Understanding Interface Management

Basic Concepts

Interface Types

Devices exchange data and interact with other devices on a network through interfaces. Interfaces are classified into physical and logical interfaces.

Physical Interfaces

Physical interfaces physically exist on boards. They are divided into the following types:
- LAN interfaces: interfaces through which the router can exchange data with other devices on a LAN.
- WAN interfaces: interfaces through which the router can exchange data with remote devices on external networks.
Logical Interfaces

Logical interfaces are manually configured interfaces that do not exist physically. Logical interfaces can be used to exchange data.

Interface Numbering Rules

For details, see Hardware Description > Boards > Overview > Rules for Numbering Slots and Interfaces.

Interface Views and Prompts

Table 1-328 lists the commands, views, and prompts of physical interfaces supported by the NetEngine 8100 M, NetEngine 8000E M, NetEngine 8000 M. Table 1-329 lists the commands, views, and prompts of logical interfaces supported by the NetEngine 8100 M, NetEngine 8000E M, NetEngine 8000 M.

Table 1-328 Commands, views, and prompts of physical interfaces supported by the NetEngine 8100 M, NetEngine 8000E M, NetEngine 8000 M

Interface Name	Command View	Operation	Prompt
GE interface	GE interface view	Run the interface gigabitethernet 0/2/0 command in the system view.	[~HUAWEI-GigabitEthernet0/2/0]
10GE interface	10GE interface view	Run the interface gigabitethernet 0/1/0 command in the system view. NOTE: The interfaces marked with 10G displayed in the display interface brief command output indicate GE interfaces whose bandwidth is 10 Gbit/s.	[~HUAWEI-GigabitEthernet0/1/0]
25GE interface	25GE interface view	Run the interface 25GE 0/2/0 command in the system view.	[~HUAWEI-25GE0/2/0]
40GE interface	40GE interface view	Run the interface 40GE 0/2/0 command in the system view.	[~HUAWEI-40GE0/2/0]
100GE interface	100GE interface view	Run the interface 100GE 0/1/0 command in the system view.	[~HUAWEI-100GE0/1/0]
200GE interface	200GE interface view	Run the interface 200GE 0/1/0 command in the system view.	[~HUAWEI-200GE0/1/0]
400GE interface	400GE interface view NOTE: This interface is not supported on the NetEngine 8000 M8K or NetEngine 8000 M14K.	Run the interface 400GE 0/1/0 command in the system view.	[~HUAWEI-400GE0/1/0]
XGE interface	XGE interface view	Run the interface XGigabitEthernet 0/1/0 command in the system view.	[~HUAWEI-XGigabitEthernet0/1/0]
CPOS interface	CPOS interface view NOTE: This interface is not supported on the NetEngine 8000 M4.	Run the controller cpos 0/3/0 command in the system view.	[~HUAWEI-Cpos0/3/0]
POS interface	POS interface view NOTE: This interface is not supported on the NetEngine 8000 M4.	Run the interface pos 0/3/0 command in the system view.	[~HUAWEI-Pos0/3/0]
50GE interface	50GE interface view	Run the interface 50GE 0/1/0 command in the system view.	[~HUAWEI-50GE0/1/0]
50\|100GE interface	50\|100GE interface view NOTE: The default rate of this type of interface is 50 Gbit/s and can be switched to 100 Gbit/s.	Run the interface 50\|100GE 0/1/0 command in the system view.	[~HUAWEI-50\|100GE0/1/0]
FlexE-50G interface	FlexE-50G interface view	Run the interface FlexE-50G 0/1/0 command in the system view.	[~HUAWEI-FlexE-50G0/1/0]
FlexE-100G interface	FlexE-100G interface view NOTE: This interface is not supported on the NetEngine 8000 M8K or NetEngine 8000 M14K.	Run the interface FlexE-100G 0/1/0 command in the system view.	[~HUAWEI-FlexE-100G0/1/0]
FlexE-400G interface	FlexE-400G interface view	Run the interface FlexE-400G 0/1/0 command in the system view.	[~HUAWEI-FlexE-400G0/1/0]
FlexE-10G interface	FlexE-10G interface view NOTE: This interface is not supported on the NetEngine 8000 M4, NetEngine 8000 M8K, and NetEngine 8000 M14K.	Run the interface FlexE-10G 0/1/0 command in the system view.	[~HUAWEI-FlexE-10G0/1/0]

Table 1-329 Commands, views, and prompts of logical interfaces

Interface Name	Command View	Operation	Prompt
Sub-interface	Sub-interface view	Run the interface gigabitethernet 0/1/0.1 command in the system view.	[~HUAWEI-GigabitEthernet0/1/0.1]
Eth-Trunk interface	Eth-Trunk interface view	Run the interface eth-trunk 2 command in the system view.	[~HUAWEI-Eth-Trunk2]
VE interface	VE interface view	Run the interface virtual-ethernet 0/1/0 command in the system view.	[~HUAWEI-Virtual-Ethernet0/1/0]
Global VE interface	Global VE interface view	Run the interface global-ve 0 command in the system view.	[~HUAWEI-Global-VE0]
VLANIF interface	VLANIF interface view	Run the interface vlanif 2 command in the system view.	[~HUAWEI-Vlanif2]
Loopback interface	Loopback interface view	Run the interface loopback 2 command in the system view.	[~HUAWEI-LoopBack2]
Null interface	Null interface view	Run the interface null 0 command in the system view.	[~HUAWEI-NULL0]
IP-Trunk interface	IP-Trunk interface view	Run the interface ip-trunk 2 command in the system view.	[~HUAWEI-Ip-Trunk2]
Tunnel interface	Tunnel interface view	Run the interface tunnel 2 command in the system view.	[~HUAWEI-Tunnel 2]
NVE interface	NVE interface view	Run the interface nve 1 command in the system view.	[~HUAWEI-Nve1]
FlexE interface	FlexE interface view	Run the interface FlexE 0/2/5 command in the system view.	[~HUAWEI-FlexE0/2/5]
Virtual serial interface	Virtual serial interface view	Run the interface Virtual-Serial 0/2/0 command in the system view.	[~HUAWEI-Virtual-Serial0/2/0]
PW-VE interface	PW-VE interface view	Run the interface pw-ve 1 command in the system view.	[~HUAWEI-pw-ve1]

Commonly-used Link Protocols and Access Technologies

The link layer is responsible for accurately sending data from a node to a neighboring node. It receives packets from the network layer, encapsulates the packets in frames, and then sends the frames to the physical layer.

Major link layer protocols supported by the NetEngine 8100 M, NetEngine 8000E M, NetEngine 8000 M are listed as follows:

Ethernet

Currently, the LAN mostly refers to the Ethernet. The Ethernet is a broadcast network, which is flexible and simple in configuration as well as easy to expand. For these reasons, the Ethernet is widely used.
Trunk

Trunks can be classified into Eth-Trunks and IP-Trunks. An Eth-Trunk must be composed of Ethernet links, and an IP-Trunk must be composed of POS links.

The trunk technology has the following advantages:
- Bandwidth increase: The bandwidth of a trunk is the total bandwidth of all member interfaces.
- Reliability enhancement: When a link fails, other links in the same trunk automatically take over the services on the faulty link to prevent traffic interruption.
PPP

The Point-to-Point Protocol (PPP) is used to encapsulate IP packets on serial links. It supports both the asynchronous transmission of 8-bit data without the parity check and the bit-oriented synchronous connection.

PPP consists of the Link Control Protocol (LCP) and the Network Control Protocol (NCP). LCP is used to create, configure, and test links; NCP is used to control different network layer protocols.
HDLC

The High-Level Data Link Control (HDLC) is a suite of protocols that are used to transmit data between network nodes. HDLC is widely used at the data link layer.

In HDLC, the receiver responds with an acknowledgment when it receives frames transmitted over the network. In addition, HDLC manages data flows and the interval at which data packets are transmitted.

MTU

The maximum transmission unit (MTU) is the size (in bytes) of the longest packet that can be transmitted on a physical network. The MTU is very important for interworking between two devices on a network. If the size of a packet exceeds the MTU supported by a transit node or a receiver, the transit node or receiver may fragment the packet before forwarding it or may even discard it, increasing the network transmission loads. MTU values must be correctly negotiated between devices to ensure that packets reach the receiver.

If fragmentation is disallowed, packet loss may occur during data transmission at the IP layer. To ensure that long packets are not discarded during transmission, configure forcible fragmentation for long packets.
When an interface with a small MTU receives long packets, the packets have to be fragmented. Consequently, when the quality of service (QoS) queue becomes full, some packets may be discarded.
If an interface has a large MTU, packets may be transmitted at a low speed.

Loopback

The physical interface of the router supports loopback local and loopback remote. The following figure shows the two loopback paths.

Figure 1-617 Local loopback

loopback local

The differences between local loopback and optical fiber loopback based on optical modules are as follows: In the local loopback mode, service traffic does not pass through the Framer's optical module driver circuit. During the forwarding tests, only a few boards inserted with optical modules perform optical fiber loopback to test the Framer's optical module driver circuit. Local loopback can be configured on the interfaces to test the forwarding performance and stability, which saves materials.

Redirection is a class behavior of a QoS policy. Redirection can change the IP packets' next-hop IP addresses and outbound interfaces, and apply to specific interfaces to change the IP service forwarding destination. When redirection works with interface loopback, you can use the interface connected to the tester to test all the interfaces on the board. If only loopback local is configured on the interface and redirection is not configured or the configured policy is not matched, the system does not forward packets.

Local loopback can also verify system functions. Take the mirroring function as an example. Due to limited materials, you can run the loopback local command on the observing interface to monitor the traffic and verify whether the function takes effect.
loopback remote

Remote loopback is used for fault diagnosis at the physical layer. You can check physical link quality through the subcard statistics, interface status, or other parameters.

Figure 1-618 Remote loopback

As shown in the preceding figure, after the interface with loopback remote configured receives a packet from A, B does not forward the packet based on the destination address. Instead, B directly returns the packet through another interface (Layer 2 or Layer 3 interface) to A.

The processing on A when A receives the returned packet from B is as follows:
- If the interface on A is a Layer 3 interface, Ping packets looped back from B is discarded by A because the destination MAC address is different from the MAC address of the interface on End A. However, interface statistics exist on the subcard. You can check physical link quality by the Input and Output fields on the interface.
- If the interface on A is a Layer 2 interface, the interface cannot successfully transmit Ping packets. If a tester or other methods are used for A to transmit a packet, A does not check the MAC address of the packet looped back from B, and instead, A directly forwards the packet based on the MAC address.
  - If A sends the packet with the MAC address of the peer device as the destination MAC address, the packet is repeatedly looped back between the two devices.
  - If A sends the packet whose destination MAC address is a broadcast MAC address, the packet is repeatedly looped back between two devices and is broadcast to the broadcast domain.
This method causes broadcast storms. Therefore, exercise caution when using this method.

Control-Flap

The status of an interface on a device may alternate between up and down for various reasons, including physical signal interference and incorrect link layer configurations. The changing status causes routing protocols and Multiprotocol Label Switching (MPLS) to flap. As a result, the device may break down, causing network interruption. Control-flap controls the frequency of interface status alternations between up and down to minimize the impact on device and network stability.

The following two control modes are available.

Table 1-330 Flapping control modes

Control Mode	Function	Usage Scenario
control-flap	Controls the frequent flappings of interfaces at the network layer to minimize the impact on device and network stability.	This control mode is interface-specific. This control mode suppresses interface flappings from the network layer and reports the flappings to the routing management module, thereby improving network-layer stability. This control mode allows you to precisely configure parameters based on service requirements. This control mode involves complex algorithms and is highly demanding to use.
damp-interface	Controls the frequent flappings of interfaces at the physical layer to minimize the impact on device and network stability.	This function is supported globally or on a specified interface. This control mode suppresses the flappings from the physical layer, thereby improving link-layer and network-layer stability. This control mode prevents the upper-layer protocols from frequently alternating between enabled and disabled, thereby reducing the consumption of CPU and memory resources. This control mode does not involve any complex algorithms and is easy to use.

control-flap

Interface flapping control controls the frequency of interface status alternations between Up and Down to minimize the impact on device and network stability.

Interface flapping suppression involves the following concepts:

Penalty value and threshold

An interface is suppressed or freed from suppression based on the penalty value.
- Penalty value: This value is calculated based on the status of the interface using the suppression algorithm. The penalty value increases with the changing times of the interface status and decreases with the half life.
- Suppression threshold (suppress): The interface is suppressed when the penalty value is greater than the suppression threshold.
- Reuse threshold (reuse): The interface is no longer suppressed when the penalty value is smaller than the reuse threshold.
- Ceiling threshold (ceiling): The penalty value no longer increases when the penalty value reaches the ceiling threshold.
The parameter configuration complies with the following rule: reuse threshold (reuse) < suppression threshold (suppress) < maximum penalty value (ceiling).
Half life

When an interface goes down for the first time, the half life starts. A device matches against the half life based on the actual interface status. If a specific half life is reached, the penalty value decreases by half. Once a half life ends, another half life starts.
- Half life when an interface is up (decay-ok): When the interface is up, if the period since the end of the previous half life reaches the current half life, the penalty value decreases by half.
- Half life when an interface is down (decay-ng): When the interface is down, if the period since the end of the previous half life reaches the current half life, the penalty value decreases by half.
Maximum suppression time: The maximum suppression time of an interface is 30 minutes. When the period during which an interface is suppressed reaches the maximum suppression time, the interface is automatically freed from suppression.

You can set the preceding parameters to restrict the frequency at which an interface alternates between up and down.

Comply with the following rules when configuring parameters.

Table 1-331 Flapping control parameter configuration recommendations

Configuration Objective	Recommendations
Configuration Objective	suppress	reuse	decay-ok	decay-ng
To delay interface suppression	Increase	N/A	Decrease	Decrease
To accelerate interface suppression	Decrease	N/A	Increase	Increase
To accelerate disabling interface suppression	N/A	Increase	Decrease	Decrease
To delay disabling interface suppression	N/A	Decrease	Increase	Increase

decay-ok and decay-ng can be configured separately:

If an interface remains up for a long period and the interface needs to be used as soon as it goes up, decreasing decay-ok is recommended.
If an interface remains down for a long period and the interface needs to be suppressed as soon as it goes down, increasing decay-ng is recommended.

Example:

Table 1-332 Example for setting the control-flap parameter

Parameter	Examples for the Impact of Flapping Control Parameters on Interface Suppression
suppress
reuse
decay-ok and decay-ng

Principles of interface flapping control:

In Figure 1-619, the default penalty value of an interface is 0. The penalty value increases by 400 each time the interface goes down. When an interface goes down for the first time, the half life starts. The system checks whether the specific half life expires at an interval of 1s. If the specific half life expires, the penalty value decreases by half. Once a half life ends, another half life starts.

If the penalty value exceeds the interface suppressing threshold, the interface is suppressed. When the interface is suppressed, the outputs of the display interface, display interface brief, and display ip interface brief commands show that the protocol status of the interface remains DOWN(dampening suppressed) and does not change with the physical status.
If the penalty value falls below the interface reuse threshold, the interface is freed from suppression. When the interface is freed from suppression, the protocol status of the interface is in compliance with the actual status and does not remain Down (dampening suppressed).
If the penalty value reaches ceiling, the penalty value no longer increases.

Figure 1-619 Principles of interface flapping control
Click to enlarge

damp-interface

Related concepts:
- penalty value: a value calculated by a suppression algorithm based on an interface's flappings. The suppression algorithm increases the penalty value by a specific value each time an interface goes down and decreases the penalty value exponentially each time the interface goes up.
- suppress: An interface is suppressed if the interface's penalty value is greater than the suppress value.
- reuse: An interface is no longer suppressed if the interface's penalty value is less than the reuse value.
- ceiling: calculated using the formula of reuse x 2 ^{(MaxSuppressTime/HalfLifeTime)}. ceiling is the maximum penalty value. An interface's penalty value no longer increases when it reaches ceiling.
- half-life-period: period that the penalty value takes to decrease to half. A half-life-period begins to elapse when an interface goes Down for the first time. If a half-life-period elapses, the penalty value decreases to half, and another half-life-period begins.
- max-suppress-time: maximum period during which an interface's status is suppressed. After max-suppress-time elapses, the interface's actual status is reported to upper layer services.
Figure 1-620 shows the relationship between the preceding parameters. To facilitate understanding, figures in Figure 1-620 are all multiplied by 1000.

Figure 1-620 Suppression on physical interface flappings

At t1, an interface goes down, and its penalty value increases by 1000. Then, the interface goes up, and its penalty value decreases exponentially based on the half-life rule. At t2, the interface goes down again, and its penalty value increases by 1000, reaching 1600, which has exceeded the suppress value 1500. At this time if the interface goes up again, its status is suppressed. As the interface keeps flapping, its penalty value keeps increasing until it reaches the ceiling value 10000 at tA. As time goes by, the penalty value decreases and reaches the reuse value 750 at tB. The interface status is then no longer suppressed.

Loopback interfaces, Layer 2 interfaces that are converted from Layer 3 interfaces using the portswitch command, and Null interfaces do not support MTU or control-flap configuration.

Logical Interface

A single physical interface can be virtually split into multiple logical interfaces. Logical interfaces can be used to exchange data.

Table 1-333 Logical interface list

Interface Name	Usage Scenario and Interface Description
DCN serial interface	After DCN is enabled globally, a DCN serial interface is automatically created.
Virtual Ethernet (VE) interface	When an L2VPN accesses multiple L3VPNs, VE interfaces are used to terminate the L2VPN for L3VPN access. Because a common VE interface is bound to only one board, services will be interrupted if the board fails.
Global VE interface	When an L2VPN accesses multiple L3VPNs, global VE interfaces are used to terminate the L2VPN for L3VPN access. A common VE interface is bound to only one board. If the board fails, services on the common VE interface will be interrupted. Unlike common VE interfaces, global VE interfaces support global L2VE and L3VE. Services on global VE interfaces will not be interrupted if some boards fail. The loopback function on global VE interfaces works properly even when a board is powered off or damaged. The loopback process has been optimized on global VE interfaces to enhance the interface forwarding performance. Global VE interfaces can be created on a device if the device is powered on.
Flexible Ethernet (FlexE) interface	A physical interface in standard Ethernet mode has fixed bandwidth. However, FlexE technology enables one or more physical interfaces to work in FlexE mode and adds them to a group. The total bandwidth of this group can be allocated on demand to logical interfaces in the group. The group to which physical interfaces are added is referred to as a FlexE group. The logical interfaces that share bandwidth of the physical interfaces in the FlexE group are called FlexE interfaces (also referred to as FlexE service interfaces). FlexE interface bandwidth varies, which allows services to be isolated. Compared with traditional technologies, FlexE technology permits bit-level interface bundling, which solves uneven per-flow or per-packet hashing that challenges traditional trunk technology. In addition, each FlexE interface has a specific MAC address, and forwarding resources between interfaces are isolated. This prevents head-of-line blocking (HOL blocking) that occurs when traditional logical interfaces such as VLAN sub-interfaces are used for forwarding. FlexE interface technology especially fits scenarios in which high-performance interfaces are required for transport, such as mobile bearer, home broadband, and leased line access. Services of different types are carried on specific FlexE interfaces, and are assigned specific bandwidth. FlexE technology achieves service-specific bandwidth control, and meets network slicing requirements in 5G scenarios.
VLAN channelized sub-interface	A channelized interface can strictly isolate interface bandwidth. A VLAN channelized sub-interface is a channelization-enabled sub-interface of an Ethernet physical interface. Different types of services are carried on different channelized sub-interfaces. Specific bandwidth values are configured on channelized sub-interfaces to strictly isolate bandwidth among different channelized sub-interfaces on the same physical interface. This allows each service to be assigned specific bandwidth and prevents bandwidth preemption among different sub-interfaces.
Loopback interface	A loopback interface can be either of the following: Loopback interface If you need the IP address of an interface whose state is always up, you can select the IP address of a loopback interface. A loopback interface has the following advantages: Once a loopback interface is created, its physical status and data link protocol status always stay up, regardless of whether an IP address is configured for the loopback interface. The IP address of a loopback interface can be advertised immediately after being configured. A loopback interface can be assigned an IP address with a 32-bit mask, which reduces address consumption. No link layer protocol can be configured for a loopback interface. Therefore, no data link layer negotiation is required, allowing the link layer protocol status of the interface to stay up. The device drops the packet with a non-local IP address as its destination IP address and a local loopback interface as its outbound interface. The advantages of a loopback interface help improve configuration reliability. The IP address of a loopback interface can be used as follows: As the source address of a packet to improve network reliability. Can be used to control an access interface and filter logs to simplify information displaying. NOTE: When a loopback interface monitors an interface monitoring group, the loopback interface may go down. In other cases, the physical status and link protocol status of the loopback interface are up. InLoopBack0 interface An InLoopBack0 interface is a fixed loopback interface that is automatically created at the system startup. An InLoopBack0 interface uses the fixed loopback address 127.0.0.1/8 to receive data packets destined for the host where the InLoopBack0 interface resides. The loopback address of an InLoopBack0 interface is not advertised.
Null0 interface	A Null0 interface, similar to a null device supported in some operating systems, is automatically created by the system. All data packets sent to a Null0 interface are discarded. Therefore, you only need to ensure that the data packets to be filtered out are forwarded to a Null0 interface without the need of configuring any ACL. A Null0 interface is used as follows: Routing loop prevention A Null0 interface can be used to prevent routing loops. For example, a route to a Null0 interface is created when a set of routes are summarized. Traffic filtering A Null0 interface can filter packets without an ACL. No IP address or data link layer protocol can be configured on a Null0 interface.
Ethernet sub-interface	An Ethernet sub-interface can be configured on a physical interface or logical interface. It has Layer 3 features and can be configured with an IP address to implement inter-VLAN communication. An Ethernet sub-interface shares the physical layer parameters of the main interface but has independent link layer and network layer parameters. Enabling or disabling an Ethernet sub-interface does not affect the main interface where the sub-interface resides, whereas a change in the main interface status affects the Ethernet sub-interface. Specifically, the Ethernet sub-interface can work properly only if the main interface is up.
Eth-Trunk interface	An Eth-Trunk interface can have multiple physical interfaces bundled to increase bandwidth, improve reliability, and implement load balancing. For more information, see Trunk.
VLANIF interface	A VLANIF interface belongs to a Layer 3 interface and can be configured with an IP address. A VLANIF interface that has an IP address configured enables a Layer 2 device to communicate with a Layer 3 device. Layer 3 switching combines routing and switching and improves overall network whole performance. After a Layer 3 switch transmits a data flow using a routing table, it generates a mapping between a MAC address and IP address. When the Layer 3 switch receives the same data flow, it transmits the data flow over Layer 2 instead of Layer 3. The routing table must have correct routing entries, so that the Layer 3 switch can transmit the data flow for the first time. A VLANIF interface and a routing protocol must be configured on a Layer 3 switch to ensure Layer 3 route reachability.
ATM bundle interface	An ATM bundle interface is used to forward one type of service from base stations to a base station controller over the same PW. In the scenarios where multiple base stations connect to a CSG through E1, CE1, or CPOS links, each base station may have voice, video, and data services, which require the CSG to create three PVCs for each base station. If one PW is used to transmit one type of service on each base station, a large number of PWs must be configured on the CSG. The growing number of base stations and service types increasingly burdens the CSG. To address this problem, sub-interfaces that connect base stations to the CSG and transmit the same type of service can be bound to one ATM bundle interface. A PW is then set up on the ATM bundle interface to transmit the services to the base station controller. In this way, each type of service requires one ATM bundle interface and one PW on a CSG, thereby reducing the number of PWs, alleviating the burden on the CSG, and improving service scalability.
Channelized serial interface	Serial interfaces are channelized from E1 or CPOS interfaces to carry services. The number of a serial interface channelized from an E1 interface is in the format of E1 interface number:channel set number. For example, the serial interface channelized from channel set 1 of E1 2/0/0 is serial 2/0/0:1. The number of a serial interface channelized from a CPOS interface is in the format of CPOS interface number/E1 interface number:channel set number. For example, the serial interface channelized from channel 3 of CPOS 2/0/0's E1 channel 2 is serial 2/0/0/2:3.
Channelized serial sub-interface	Sub-interfaces can be created on serial interfaces that are channelized from E1 or CPOS interfaces. If the ATM link type is configured for a serial interface, P2P and P2MP sub-interfaces can be created.
IP-Trunk interface	To improve communication capabilities of links, you can bundle multiple POS interfaces to form an IP-Trunk interface. An IP-Trunk interface obtains the sum of bandwidths of member interfaces. You can add POS interfaces to an IP-Trunk interface to increase the bandwidth of the interface. To prevent traffic congestion, traffic to the same destination can be balanced among member links of the IP-Trunk interface, not along a single path. You can configure an IP-Trunk interface to improve link reliability. If one member interface goes Down, traffic can still be forwarded by the remaining active member interfaces. An IP-Trunk interface must have HDLC encapsulated as its link layer protocol. For more information, see IP-Trunk.
CPOS-Trunk interface	A CPOS-Trunk interface can have multiple CPOS interfaces bundled to support APS.
Trunk serial interface	A trunk serial interface is channelized from a CPOS-Trunk interface to support APS.
MP-group interface	An MP-group interface that has multiple serial interfaces bundled is exclusively used by MP to increase bandwidth and improve reliability. For more information, see MP Principles.
Global MP-group interface	A protection channel can be configured to take over traffic from one or more working channels in case the working channels fail, which improves network reliability. Two CPOS interfaces are added to a CPOS-Trunk interface, which is then channelized into trunk serial interfaces. A global MP-group interface can have multiple trunk serial interfaces bundled to carry PPP services. If one CPOS link fails, the other CPOS link takes over the PPP traffic.
IMA-group interface	When users access an ATM network at a rate between T1 and T3 or between E1 and E3, it is cost-ineffective for the carrier to directly use T3 or E3 lines. In this situation, an IMA-group interface can have multiple T1 or E1 interfaces bundled to carry ATM services. The bandwidth of an IMA-group interface is approximately the total bandwidth of all member interfaces. For more information, see ATM IMA.
Global IMA-group interface	A protection channel can be configured to take over traffic from one or more working channels in case the working channels fail, which improves network reliability. Before ATM services are deployed on CPOS interfaces, two CPOS interfaces must be added to a CPOS-Trunk interface, which is then channelized into trunk serial interfaces. A global IMA-group interface can have multiple trunk serial interfaces bundled to carry ATM services. If one CPOS link fails, the other CPOS link takes over the ATM traffic.
Tunnel interface	A tunnel interface is used by an MPLS TE tunnel to forward traffic. For more information, see Tunnel Interface.

FlexE

Overview of FlexE

Definition

Flexible Ethernet (FlexE) is an interface technology that implements service isolation and network slicing on a bearer network. Based on the standard Ethernet technology defined in IEEE 802.3, FlexE decouples the MAC layer from the PHY layer by adding a FlexE shim layer between them (for its implementation, see Figure 1-621). With FlexE, the one-to-one mapping between MACs and PHYs is not a must any more, and M MACs can be mapped to N PHYs, thereby implementing flexible rate matching. For example, one 100GE PHY can be divided into a pool of twenty 5 Gbit/s timeslots, and service interfaces can flexibly apply for separate bandwidth from this pool.

Figure 1-621 Structures of standard Ethernet and FlexE

Purpose

When standard Ethernet interfaces are used as telecommunication network interfaces, the following issues exist:

More flexible bandwidth granularities are not supported: Diverse services and application scenarios require Ethernet interfaces to provide more flexible bandwidth granularities without being restricted by the rate ladder (10 Gbit/s–25 Gbit/s–40 Gbit/s–50 Gbit/s–100 Gbit/s–200 Gbit/s–400 Gbit/s) defined by IEEE 802.3. It may take years for IEEE 802.3 to define a new interface standard, which cannot meet the requirements of application changes. Furthermore, formulating an interface standard for each bandwidth requirement is impossible, and therefore other interface solutions are required.
The Ethernet interface capability of IP devices depends on the capability of optical transmission devices, and their development is not synchronous: For example, optical transmission devices do not have 25GE or 50GE interfaces. However, when IP and optical transmission devices are interconnected, the link rate of the optical transmission device must strictly match the Ethernet rate of the corresponding User-to-Network Interface (UNI).
Enhanced QoS capability for multi-service bearing is not supported: Standard Ethernet interfaces perform scheduling based on QoS packet priorities. As a result, long packets will block the pipe, increasing the latency of short packets. In this case, services affect each other.

FlexE resolves these issues by:

Supporting more flexible bandwidth granularities: FlexE supports the flexible configuration of interface rates, which may or may not correspond to the interface rates defined in the existing IEEE 802.3 standard. This meets the requirement for diverse services and application scenarios.
Decoupling from the capability of optical transmission devices: The Ethernet interface rate of IP devices is decoupled from the link rate of optical transmission devices, meaning that the link rate of optical transmission devices does not need to strictly match the Ethernet rate of a UNI. In this way, the existing optical transmission network (OTN) can be utilized to the maximum extent to support Ethernet interfaces with new bandwidths.
Supporting the enhanced QoS capability for multi-service bearing: FlexE provides channelized hardware isolation on physical-layer interfaces to implement hard slicing for SLA assurance and isolated bandwidth for services.

General Architecture of FlexE

The FlexE standards define the client/group architecture, as shown in Figure 1-622. Multiple FlexE clients can be mapped to a group of PHYs (FlexE group) for data transmission. Owing to the IEEE 802.3-defined Ethernet technology, the FlexE architecture provides enhanced functions based on existing Ethernet MAC and PHY layers.

Figure 1-622 General architecture of FlexE

FlexE involves three concepts: FlexE client, FlexE shim, and FlexE group.

FlexE client: corresponds to an externally observed user interface that functions in the same way as traditional service interfaces on existing IP/Ethernet networks. FlexE clients can be configured flexibly to meet specific bandwidth requirements. They support Ethernet MAC data streams of various rates (including 10 Gbit/s, 40 Gbit/s, N x 25 Gbit/s, and even non-standard rates), and the Ethernet MAC data streams are transmitted to the FlexE shim layer as 64B/66B encoded bit streams.
FlexE shim: functions as a layer that maps or demaps the FlexE clients carried over a FlexE group. It decouples the MAC and PHY layers and implements key FlexE functions through calendar timeslot distribution.
FlexE group: consists of various Ethernet PHYs defined in IEEE 802.3. By default, the PHY bandwidth is divided based on the 5 Gbit/s timeslot granularity.

FlexE Functions

According to the mappings between FlexE clients and groups, FlexE can provide three main functions: bonding, channelization, and sub-rating. Through these functions, FlexE clients can flexibly provide bandwidth not constrained to the rates of Ethernet PHYs to upper-layer applications.

Based on these three functions, FlexE implements on-demand interface bandwidth allocation and hard pipe isolation, and can be used on IP networks to implement ultra-high bandwidth interfaces, 5G network slicing, and interconnection with optical transmission devices.

Bonding

As shown in Figure 1-623, bonding means that multiple PHYs are bonded to support a higher rate. For example, two 100GE PHYs can be bonded to provide a MAC rate of 200 Gbit/s.

Figure 1-623 Bonding

Channelization

As shown in Figure 1-624, channelization allows multiple low-rate MAC data streams to share one or more PHYs. For example, channelization allows two MAC data streams (75 Gbit/s and 25 Gbit/s) to be carried over one 100GE PHY or allows three MAC data streams (150 Gbit/s, 125 Gbit/s, and 25 Gbit/s) to be carried over three 100GE PHYs.

Figure 1-624 Channelization

Sub-rating

As shown in Figure 1-625, sub-rating allows MAC data streams with a single low rate to share one or more PHYs, and uses a specially defined error control block to reduce the rate. For example, a 100GE PHY carries only 50 Gbit/s MAC data streams.

Sub-rating is a subset of channelization in a certain sense.

Figure 1-625 Sub-rating

FlexE Shim

The core functions of FlexE are implemented through the FlexE shim. The following uses a FlexE group that consists of 100GE PHYs as an example.

FlexE Shim Mechanism

As shown in Figure 1-626, the FlexE shim divides each 100GE PHY in a FlexE group into 20 timeslots for data transmission, with each timeslot providing bandwidth of 5 Gbit/s. A FlexE client can be flexibly assigned bandwidth that is an integer multiple of 5 Gbit/s. The Ethernet frames of FlexE clients are partitioned into 64B/66B blocks, which are then mapped and distributed to timeslots of a FlexE group according to the calendar mechanism of the FlexE shim, thereby implementing strict isolation between the blocks.

Figure 1-626 FlexE shim mechanism

Calendar Mechanism

Figure 1-627 shows the calendar mechanism of the FlexE shim. Twenty blocks (corresponding to timeslots 0 to 19) are used as a logical unit, and 1023 "twenty blocks" are then used as a calendar component. The calendar components are distributed in a specified order into timeslots, each of which has a bandwidth granularity of 5 Gbit/s for data transmission.

In terms of bit streams, each 64B/66B block is carried over a timeslot (basic logical unit carrying the 64B/66B block), as shown in Figure 1-627.

FlexE allocates available timeslots in a FlexE group based on bandwidth required by each FlexE client to form a mapping from the FlexE client to one or more timeslots. In addition, the calendar mechanism is used to carry one or more FlexE clients in the FlexE group.

Figure 1-627 Calendar mechanism

Overhead Frame and Multiframe

To transmit configuration and management information between two interconnected FlexE clients, implement link auto-negotiation, and establish client-timeslot mappings, the FlexE shim defines overhead frames to provide in-band management channels. An overhead frame consists of blue overhead blocks shown in Figure 1-627. Eight overhead blocks form an overhead frame, and 32 overhead blocks form an overhead multiframe. An overhead block is also a 64B/66B block and appears every 1023 "twenty blocks." Fields contained in each overhead block are different.

Figure 1-628 shows the format of an overhead frame, which consists of eight overhead blocks. The first three overhead blocks carry the mappings between timeslots and FlexE clients and between timeslots and FlexE groups, and the remaining ones carry management messages, such as DCN and 1588v2 messages.

Figure 1-628 Overhead frame format

The SH is a synchronization header field added after 64B/66B encoding is performed on the data, and its bit width is 2 bits. If the value is 10, the carried data is a control block; if the value is 01, the carried data is a data block; if the value is 00 or 11, the field is invalid; and if the value is ss, the synchronization header is valid and may be 10 or 01.

In an overhead frame, the first overhead block is a control block, the second and third overhead blocks are data blocks, and the fourth to eighth overhead blocks are allocated to management or synchronization messaging channels. Table 1-334 describes the meaning of each field in an overhead frame.

Table 1-334 Meaning of each field in an overhead frame

Field	Bit Width (Bits)	Meaning
0x4B	8	Indicates the control field, which is used to lock data synchronization in the receive direction.
C	1	Indicates the calendar configuration in use. The value 0 indicates that calendar A is used, and the value 1 indicates that calendar B is used. Two calendars are configured to establish timeslot tables A and B for hitless bandwidth adjustment.
OMF	1	Indicates the overhead multiframe. This field is set to 0 for the first 16 overhead frames of an overhead multiframe or 1 for the last 16 overhead frames.
RPF	1	Indicates the remote PHY fault.
SC	1	Indicates the synchronization configuration. The value 0 indicates that the shim-to-shim management channel occupies the sixth to eighth overhead blocks of the overhead frame; the value 1 indicates that the shim-to-shim management channel occupies the seventh and eighth overhead blocks of the overhead frame (the sixth overhead block is allocated to the synchronization messaging channel).
FlexE Group Number	20	Indicates the group ID defined by the protocol, which must be planned in advance.
0x5	4	Indicates the "O" code, which is used to lock data synchronization in the receive direction.
0x000_0000	28	Reserved and displayed as all 0s.
FlexE Map	8 x 32	Indicates the mapping between PHYs and a FlexE group, in bit map format. If a bit is 1, the corresponding PHY belongs to the FlexE group; if a bit is 0, the corresponding PHY does not belong to the FlexE group. A FlexE group formed by 100GE PHYs is used as an example. Because 32 overhead frames form an overhead multiframe, the bit width is 256 (8 x 32) bits, where bits 0 and 255 are reserved and the markable range is 1 to 254. When a PHY ID is 3, only the third bit is 1 and the other bits are all 0 among the 256 bits.
FlexE Instance Number	8	Indicates a PHY ID, identifying the PHY to which timeslots belong. The PHY IDs must be unique in the same group but can be the same in different groups.
Reserved	N/A	Indicates the reserved field, which is used for possible extension of the protocol in the future.
Client Calendar	16 x 20	Indicates the correspondence between a client and timeslot. The Client Calendar A and Client Calendar B fields are used to respectively establish timeslot tables A and B for hitless bandwidth adjustment. A FlexE group formed by 100GE PHYs is used as an example. This group has 20 timeslots, and the client IDs occupy the Client Calendar fields of the first 20 overhead frames.
CR	1	Indicates a calendar switch request.
CA	1	Indicates a calendar switch acknowledge.
CRC-16	16	Indicates the CRC field of the overhead frame. It is mainly used to prevent the timeslot configuration from being damaged in the case of bit errors. The overhead frame is protected by CRC, which is calculated based on the first three overhead blocks. Except the CRC-16 field, other fields with content are used for the calculation, whereas the reserved bits are not.
Management Channel - Section	64	A section management channel is used to transmit management messages, such as DCN and LLDP messages, between adjacent FlexE nodes.
Management Channel - Shim to Shim	64	A shim-to-shim management channel is used to transmit management messages, such as DCN and LLDP messages, between E2E FlexE nodes.
Synchronization Messaging Channel	64	A synchronization messaging channel is used to transmit clock messages, such as 1588v2 messages, between adjacent FlexE nodes.

Synchronous framing involves the SH, 0x4B, 0x5, and OMF fields in the data receive direction, and is used to identify the first overhead block of the overhead frame. If the SH, 0x4B, and 0x5 fields do not match the expected positions for five times, the FlexE overhead multiframe is unlocked, indicating that the received 32 overhead frames are not from the same overhead multiframe. As a result, the restored timeslot information is incorrect. In addition, if the OMF field passes the CRC, the overhead multiframe is locked when the bit changes from 0 to 1 or from 1 to 0. If an error occurs in a frame, the overhead multiframe is unlocked.

Timeslot Table Establishment

As shown in Figure 1-629, a FlexE group consisting of 100GE PHYs has twenty 5 Gbit/s timeslots. FlexE Client1 and FlexE Client2 are configured with 5 Gbit/s bandwidth and 20 Gbit/s bandwidth, respectively. The blue timeslot in the figure is allocated to FlexE Client1, and the green timeslots in the figure are allocated to FlexE Client2. In addition, timeslot tables are established using the FlexE Group Number, FlexE Map, FlexE Instance Number, Client Calendar A, and Client Calendar B fields that are carried in the overhead frame. The transmit or receive end then sends or receives packets based on the mappings in the timeslot tables.

According to the timeslot tables, the client IDs, PHY IDs, and group IDs of the interfaces on the two interconnected devices must be consistent.

Figure 1-629 Timeslot table establishment

Hitless Bandwidth Adjustment Through Timeslot Table Switching

Each FlexE client has two timeslot tables. Only one timeslot table takes effect at any time. When the bandwidth of a FlexE client is adjusted, the timeslot tables need to be switched.

As shown in Figure 1-630, the bandwidth of FlexE Client1 is adjusted from 5 Gbit/s to 10 Gbit/s. In normal cases, timeslot table A is used for packet sending and receiving, and timeslot table B is used as a backup. During bandwidth adjustment, timeslot table B is used for packet sending and receiving, implementing hitless bandwidth adjustment.

Figure 1-630 Hitless bandwidth adjustment through timeslot table switching

As shown in Figure 1-631, the timeslot table switching process is as follows:

FlexE Client1 on Router1 uses timeslot table A to send packets based on 5 Gbit/s bandwidth.
After the bandwidth of FlexE Client1 is adjusted to 10 Gbit/s, Router1 establishes timeslot table B in the transmit direction and sends a CR message to Router2.
After receiving the CR message from Router1, Router2 establishes timeslot table B in the receive direction and sends a CA message to Router1, indicating that timeslot table B in the receive direction has been established.
After receiving the CA message from Router2, Router1 sends a CCC message for timeslot table switching to Router2. After this and in the next timeslot period, both Router1 and Router2 use timeslot table A for packet sending and receiving.
Router1 uses timeslot table B to send packets after the next timeslot period after Router1 sends the CCC message. After receiving an overhead frame that identifies the next timeslot period, Router2 uses timeslot table B to receive packets.

Similarly, after the bandwidth of FlexE Client1 is adjusted to 10 Gbit/s on Router2, the timeslot table is also changed to timeslot table B in the receive direction of Router1. In this case, both ends use timeslot table B to send and receive packets.

Figure 1-631 Timeslot table switching process

1 Gbit/s Timeslot Granularity Mechanism

The FlexE standards define a default timeslot granularity of 5 Gbit/s. However, Huawei devices support 1 Gbit/s timeslot granularity to better support applications, such as smart grid and mobile edge computing (MEC), in 5G vertical industries. Figure 1-632 shows how 1 Gbit/s timeslots are provided: if the time of a 5 Gbit/s timeslot is expanded, five 1 Gbit/s data blocks can occupy one standard FlexE 5 Gbit/s timeslot using TDM (blocks of five colors are transmitted in turn to implement five 1 Gbit/s sub-timeslots). In this way, small-granularity sub-timeslots are provided, without breaking the main architecture defined in the FlexE standards.

The 1 Gbit/s timeslot granularity is a sub-timeslot of a 5 Gbit/s timeslot and takes effect only in the 5 Gbit/s timeslot. If the bandwidth exceeds 5 Gbit/s, the 5 Gbit/s timeslot granularity is used.

Figure 1-632 1 Gbit/s timeslot granularity mechanism

FlexE Mode Switching

As shown in Figure 1-633, the upstream and downstream NEs on the live network are connected through standard Ethernet interfaces, and the DCN function works normally. The NMS can manage these NEs. You need to perform the following steps to switch the standard Ethernet interfaces to FlexE-based physical interfaces:

Switch the uplink interface of the downstream NE to the FlexE mode.
Switch the downlink interface of the upstream NE to the FlexE mode.

After the interfaces are switched to the FlexE mode, the link connection is automatically added to the topology of the NMS. In addition, the DCN function is enabled by default to allow the NMS to manage the devices.

Figure 1-633 Switching standard Ethernet interfaces to the FlexE mode

After a standard Ethernet interface is switched to the FlexE mode, the original standard Ethernet interface disappears. A FlexE client needs to be determined based on the defined rules to carry the bandwidth and configuration of the original standard Ethernet interface, implementing configuration restoration. As shown in Figure 1-634, the configuration restoration process is as follows:

The configurations of the standard Ethernet interfaces are saved on the NMS, and the standard Ethernet interfaces of the upstream and downstream NEs are switched to the FlexE mode.
FlexE clients are created based on the defined rules to carry the bandwidth of the original standard Ethernet interfaces.
The configurations of the original standard Ethernet interfaces are restored to the created FlexE clients.

Figure 1-634 Configuration restoration after the standard Ethernet interfaces are switched to the FlexE mode

The bandwidth of a FlexE client can be configured in either of the following modes:

Set the bandwidth of a FlexE client to the bandwidth of an original standard Ethernet interface. For example, set the bandwidth of a FlexE client to 100 Gbit/s for a 100GE interface. This mode applies to existing network reconstruction scenarios. Before creating a slice, switch the standard Ethernet interface to a FlexE client with the same bandwidth. After the reconstruction is complete, adjust the bandwidth of the FlexE client according to the slice bandwidth requirement and create new slicing interfaces.
Configure the default slice's bandwidth as the bandwidth of a FlexE client, and reserve other bandwidth for new slices. For example, set the bandwidth of a FlexE client to 50 Gbit/s as the default slice's bandwidth for a 100GE interface, and reserve the remaining 50 Gbit/s bandwidth for new slices.

FlexE DCN Modes

As shown in Figure 1-635, standard Ethernet interfaces extract or insert DCN messages from or to the MAC layer (mode 1). The FlexE standards define two DCN modes: overhead (OH) and Client. The OH mode indicates that DCN messages are transmitted over FlexE overhead timeslots (mode 2); the Client mode indicates that DCN messages are transmitted over FlexE clients (mode 3). Currently, devices support both modes. By default, the OH mode is enabled. If both modes are enabled, that is, the DCN function is configured on both the FlexE physical interfaces and FlexE clients, devices preferentially select the DCN channel in Client mode.

Therefore, the DCN communication between the standard Ethernet interfaces and FlexE physical interfaces fails.

Figure 1-635 FlexE DCN modes

To enable devices to be managed by the NMS when standard Ethernet interfaces are connected to FlexE physical interfaces, four modes are designed for the FlexE physical interfaces. This implements DCN communication between the standard Ethernet interfaces and FlexE physical interfaces.

FlexE_DCN_Auto (Init State): default mode when a board goes online. It indicates that the FlexE mode is used and services can be configured on FlexE physical interfaces. The underlying forwarding plane can directly communicate with the peer FlexE physical interface through DCN.
FlexE_DCN_Auto (ETH State): After the "PCS Link Up && Shim LOF" state is detected, the forwarding plane is auto-negotiated to the standard Ethernet mode so that this interface can communicate with the peer interface through DCN.
FlexE_Lock_Mode: FlexE lock mode. The forwarding plane does not perform mode negotiation to prevent auto-negotiation exceptions.
ETH_Mode: standard Ethernet mode, which cannot be auto-negotiated to the FlexE mode.

As shown in Figure 1-636, when a standard Ethernet interface is connected to a FlexE physical interface, the initial status of the FlexE physical interface is FlexE_DCN_Auto (Init State) and the FlexE physical interface starts auto-negotiation. The standard Ethernet interface works in ETH_Mode mode. After the negotiation is complete, the control and management planes of the FlexE physical interface remain in FlexE mode and related configurations are retained, but the forwarding plane uses the standard Ethernet mode for forwarding, implementing the DCN connectivity between the standard Ethernet interface and FlexE physical interface.

Figure 1-636 Interconnection mode of a standard Ethernet interface and FlexE physical interface

FlexE Time Synchronization Modes

As shown in Figure 1-637, the FlexE standards define two 1588v2 message transmission modes: OH and Client. By default, 1588v2 messages are transmitted in OH mode.

OH mode: Clock messages are transmitted using FlexE overhead timeslots. The configuration related to clock synchronization is the same as the configuration on a standard Ethernet interface.
Client mode: Clock messages are transmitted using FlexE clients. In this mode, the FlexE interface that carries clock services must be bound to a FlexE physical interface that has clock services deployed.

The time synchronization modes at the two ends of a FlexE link must be the same (either the OH or Client mode).

Figure 1-637 FlexE time synchronization modes

FlexE Mux

The FlexE mux function defined in the FlexE standards refers to the FlexE shim function in the transmit direction of an interface. That is, the FlexE client is mapped to the FlexE group in the transmit direction. As shown in Figure 1-638, a FlexE group consisting of 100GE PHYs is used as an example to describe the working process of FlexE mux.

Each FlexE client is presented to the FlexE shim as a 64B/66B encoded bit stream.
A FlexE client is rate-adapted in idle insertion/deletion mode to match the clock of the FlexE group. The rate of the adapted signal is slightly less than the nominal rate of the FlexE client to allow room for the alignment markers on the PHYs of the FlexE group and insertion of the FlexE overhead.
The 66B blocks from each FlexE client are sequentially distributed and inserted into the calendar.
Error control blocks are generated for insertion into unused or unavailable timeslots to ensure that the data in these timeslots is not considered valid.
The control function manages which timeslots each FlexE client is inserted into and inserts the FlexE overhead on each PHY in the transmit direction.
Calendar distribution is responsible for allocating the 66B blocks of different FlexE clients in the calendar to a sub-calendar according to the TDM timeslot distribution mechanism. The sub-calendar then schedules the 66B blocks to the corresponding PHYs in the FlexE group in polling mode.
The stream of 66B blocks of each PHY is distributed to the PCS lanes of that PHY with the insertion of alignment markers, and the layers below the PCS continues to be used intact as specified for the standard Ethernet defined by IEEE 802.3.

Figure 1-638 FlexE mux

FlexE Demux

The FlexE demux function defined in the FlexE standards refers to the FlexE shim function in the receive direction of an interface. That is, the FlexE client is demapped from the FlexE group in the receive direction. As shown in Figure 1-639, a FlexE group consisting of 100GE PHYs is used as an example to describe the working process of FlexE demux.

The lower layers of the PCS of the PHYs are used according to the standard Ethernet defined by IEEE 802.3. The PCS lanes complete operations such as deskewing and alignment marker removal, and send traffic to the FlexE shim.
The calendar logically interleaves the sub-timeslots of each FlexE instance, re-orders them, and extracts the FlexE overhead.
If any PHY in the FlexE group fails or overhead frame/multiframe locking is not implemented for any FlexE instance, all FlexE clients in the FlexE group generate local faults (LFs).
The control function manages the timeslots extracted by each FlexE client from each FlexE instance in the receive direction.
The extracted timeslots are sent to each FlexE client based on the 66B blocks.
The rate of a FlexE client is adjusted in idle insertion/deletion mode when necessary, and the stream of 66B blocks is extracted to the FlexE client at the adaptation rate. Similarly, because the alignment marker on a PHY of the FlexE group and the FlexE overhead occupy space, the rate of the FlexE client after the adaptation is slightly lower than the nominal rate of the FlexE client.

Figure 1-639 FlexE demux

Interface Group

Generally, a device provides multiple interfaces, many of which have the same configuration. To simplify the configuration of interfaces, create an interface group and add interfaces to the interface group. When you run a command in the interface group view, the system automatically applies the command to all the interfaces in the interface group. In this manner, interfaces in a group are configured in batches.

Interface groups are classified into permanent and temporary interface groups. Multiple interfaces can be added to a permanent or temporary interface group to enable batch command configurations for the interfaces. The differences between permanent and temporary interface groups are described as follows:

After a user exits the view of a temporary interface group, the system automatically deletes the temporary interface group. A permanent interface group, however, can be deleted only by using a command.
Information about a permanent interface group can be viewed, whereas information about a temporary interface group cannot.
After a permanent interface group is configured, a configuration file is generated. However, no configuration file is generated after a temporary interface group is configured.

Interface Monitoring Group

Network-side interfaces can be added to an interface monitoring group. Each interface monitoring group is identified by a unique group name. The network-side interface to be monitored is a binding interface, and the user-side interface associated with the group is a track interface, whose status changes with the binding interface status. The interface monitoring group monitors the status of all binding interfaces. When a specific proportion of binding interfaces goes Down, the track interface associated with the interface monitoring group goes Down, which causes traffic to be switched from the master link to the backup link. When the number of Down binding interfaces falls below a specific threshold, the track interface goes Up, and traffic is switched back to the master link.

Figure 1-640 Interface monitoring group

In the example network shown in Figure 1-640, ten binding interfaces are located on the network side, and two track interfaces are located on the user side. You can set a Down weight for each binding interface and a Down weight threshold for each track interface. For example, the Down weight of each binding interface is set to 10, and the Down weight thresholds of track interfaces A and B are set to 20 and 80, respectively. When the number of Down binding interfaces in the interface monitoring group increases to 2, the system automatically instructs track interface A to go Down. When the number of Down binding interfaces in the interface monitoring group increases to 8, the system automatically instructs track interface B to go Down. When the number of Down binding interfaces in the interface monitoring group falls below 8, track interface B automatically goes Up. When the number of Down binding interfaces in the interface monitoring group falls below 2, track interface A automatically goes Up.

Interface Management Application

Sub-interface

In the network shown in Figure 1-641, multiple sub-interfaces are configured on the physical interface of Device. Like a physical interface, each sub-interface can be configured with one IP address. The IP address of a sub-interface must be on the same network segment as the IP address of a remote network, and the IP address of each sub-interface must be on a unique network segment.

Figure 1-641 GE Sub-interface

With these configurations, a virtual connection is established between a sub-interface and a remote network. This allows the remote network to communicate with the local sub-interface and consequently communicate with the local network.

Eth-Trunk

In the network shown in Figure 1-642, an Eth-Trunk that bundles two full-duplex 1000 Mbit/s interfaces is established between Device A and Device B. The maximum bandwidth of the trunk link is 2000 Mbit/s.

Figure 1-642 Networking diagram of Eth-Trunk

Backup is enabled within the Eth-Trunk. If a link fails, traffic is switched to the other link to ensure link reliability.

In addition, network congestion can be avoided because traffic between Device A and Device B is balanced between the two member links.

The application and networking diagram of IP-Trunk are similar to those of Eth-Trunk.

Application of FlexE

FlexE Bonding for Ultra-high Bandwidth Interfaces

The interface rate defined in IEEE 802.3 is fixed and periodic, which cannot meet the requirements of flexible bandwidth-based networking. FlexE bonding can be combined with interface rates to construct links with higher bandwidth.

Traditional LAG Technology for Interface Bonding

As shown in Figure 1-643, the traditional LAG technology uses the hash algorithm to distribute data flows to physical interfaces. As a result, load imbalance occurs and the bandwidth utilization cannot reach 100%. For example, two 100GE physical interfaces are bonded into a LAG. Assume that there are four groups of data flows. 80 Gbit/s data flows are hashed to the upper link, and 40 Gbit/s and 30 Gbit/s data flows are hashed to the lower link. In this case, the bandwidth utilization cannot reach 100%, regardless of whether 50 Gbit/s data flows are hashed to either the upper or lower link.

Figure 1-643 Traditional LAG technology for interface bonding

FlexE Technology for Interface Bonding

As shown in Figure 1-644, FlexE can bond multiple physical interfaces to provide ultra-high bandwidth. In addition, FlexE can evenly distribute data flows to all physical interfaces through timeslot-based scheduling, achieving 100% bandwidth utilization and ensuring the 200GE forwarding capability. Customers do not need to wait for new interface standards, and using the existing interface rates is cost-effective.

Figure 1-644 FlexE technology for interface bonding

FlexE Channelization for 5G Network Slicing

5G network slicing involves the management, control, and forwarding planes. FlexE is an important technology for implementing forwarding-plane slicing. In standard Ethernet, all services share interfaces, whereas in FlexE, channelization provides physical-layer service hard isolation between different FlexE clients at the interface level and provides different service SLAs. As shown in Figure 1-645, enhanced Mobile Broadband (eMBB), ultra-reliable low-latency communication (URLLC), and Massive Machine-Type Communications (mMTC) services on a 5G network can be carried on the same IP network through slicing.

Figure 1-645 FlexE technology for 5G network slicing

Interconnection Between FlexE and Optical Transmission Devices

FlexE interfaces function as UNIs connecting routers to optical transmission devices. Flexible rate matching can be used to implement a one-to-one correspondence between the bandwidth of data flows actually carried by the UNIs and the bandwidth of the links of NNIs on the optical transmission devices. This greatly simplifies the mapping of the FlexE interfaces of the routers on the optical transmission devices, reducing device complexity as well as cutting capital expenditure (CAPEX) and operating expense (OPEX).

The FlexE standards define three modes for interconnection with optical transmission devices: unaware, termination, and aware. Currently, the unaware mode is recommended.

Unaware Mode

Optical transmission devices carry mappings according to the bit transparent transmission mechanism, as shown in Figure 1-646. The unaware mode applies to scenarios where the Ethernet rate is the same as the wavelength rate of colored optical modules. It provides FlexE support without requiring hardware upgrades, fully utilizing legacy optical transmission devices. In addition, it can use FlexE bonding to provide E2E ultra-high bandwidth channels across OTNs.

Figure 1-646 FlexE-OTN mapping in unaware mode

Termination Mode

FlexE is terminated on the ingress interfaces of optical transmission devices. The OTN detects FlexE UNIs, restores the FlexE client data flows, and further maps the data flows to the optical transmission devices for transmission, as shown in Figure 1-647. This mode is the same as the mode in which standard Ethernet interfaces are carried over the OTN, and can implement traffic grooming for different FlexE clients on the OTN.

Figure 1-647 FlexE-OTN mapping in termination mode

Aware Mode

The aware mode mainly uses the FlexE sub-rating function and is applicable to scenarios where the single-wavelength rate of colored optical modules is lower than the rate of an Ethernet interface. As shown in Figure 1-648, 150 Gbit/s data flows need to be transmitted between routers and optical transmission devices. In this case, two 100GE PHYs can be bonded to form a FlexE group. The PHYs in the FlexE group are configured based on 75% valid timeslots, and the remaining 25% timeslots are filled with special error control blocks to indicate that they are invalid.

When FlexE UNIs map data flows to the OTN in aware mode, the OTN directly discards invalid timeslots, extracts the data to be carried based on the bandwidth of the original data flows, and then maps these data flows to the optical transmission devices with matching rates. The configurations of the optical transmission devices must be the same as those of the FlexE UNIs, so that the optical transmission devices can detect the FlexE UNIs for data transmission.

Figure 1-648 FlexE-OTN mapping in aware mode

Application Scenarios for Channelized Sub-Interfaces

The 5G network carries three types of services: Enhanced Mobile Broadband (eMBB), Massive Machine-type Communications (mMTC), and Ultra reliable and low latency communications (URLLC). Services of different types need to be carried through different network slices.

To prevent services from affecting each other, a mechanism to isolate different types of services is needed. Physical bandwidth isolation is the simplest way to differentiate services. With the continuous evolution of high-performance ports on routers, no service traffic of any type exclusively consumes bandwidth of a high-performance port in a short period. Therefore, the channelization technology can be used for high-performance ports to isolate different types of services.

Different service flows are forwarded through channelized sub-interfaces with specific encapsulation. Each channelized sub-interface implements independent HQoS scheduling to isolate services of different types. As shown in Figure 1-649, Port 1 and Port 3 indicate channelized interfaces, and Port 2 is a physical interface.

Figure 1-649 Channelized interfaces

Channelized sub-interfaces are mainly used to isolate downstream traffic on the backbone aggregation network and downstream traffic on the PE network side.

Currently, channelized sub-interfaces support the following types:

VLAN-type dot1q sub-interface
QinQ VLAN tag termination sub-interface
POS FR sub-interface

Loopback Interface

Improving Reliability

IP address unnumbered

When an interface will only use an IP address for a short period, it can borrow an IP address from another interface to save IP address resources. Usually, the interface is configured to borrow a loopback interface address to remain stable.
Router ID

Some dynamic routing protocols require that routers have IDs. A router ID uniquely identifies a router in an autonomous system (AS).

If OSPF and BGP are configured with router IDs, the system needs to select the maximum IP address as the router ID from the local interface IP addresses. If the IP address of a physical interface is selected, when the physical interface goes Down, the system does not reselect a router ID until the selected IP address is deleted.

Because a loopback interface is stable and usually up, the IP address of the loopback interface is recommended as the router ID of the router.
BGP

To prevent BGP sessions from being affected by physical interface faults, you can configure a loopback interface as the source interface that sends BGP packets.

When a loopback interface is used as the source interface of BGP packets, note the following:
- The loopback interface address of the BGP peer must be reachable.
- In the case of an EBGP connection, EBGP is allowed to establish neighbor relationships through indirectly connected interfaces.
MPLS LDP

In MPLS LDP, a loopback interface address is often used as the transmission address to ensure network stability. This IP address could be a public network address.

Classifying information

SNMP

To ensure the security of servers, a loopback interface address is used as the source IP address rather than the outbound interface address of SNMP trap messages. In this manner, packets are filtered to protect the SNMP management system. The system allows only the packets from the loopback interface address to access the SNMP port. This facilitates reading and writing trap messages.
NTP

The Network Time Protocol (NTP) synchronizes the time of all devices. NTP specifies a loopback interface address as the source address of the NTP packets sent from the local router.

To ensure the security of NTP, NTP specifies a loopback interface address rather than the outbound interface address as the source address. In this situation, the system allows only the packets from the loopback interface address to access the NTP port. In this manner, packets are filtered to protect the NTP system.
Information recording

During the display of network traffic records, a loopback interface address can be specified as the source IP address of the network traffic to be output.

In this manner, packets are filtered to facilitate network traffic collection. This is because only the packets from the loopback interface address can access the specified port.
Security

Identifying the source IP address of logs on the user log server helps to locate the source of the logs rapidly. It is recommended that you configure a loopback address as the source IP address of log messages.
HWTACACS

After Huawei Terminal Access Controller Access Control System (HWTACACS) is configured, the packets sent from the local router use the loopback address as the source address. In this manner, packets are filtered to protect the HWTACACS server.

This is because only the packets sent from the loopback interface address can access the HWTACACS server. This facilitates reading and writing logs. There are only loopback interface addresses rather than outbound interface addresses in HWTACACS logs.
RADIUS authentication

During the configuration of a RADIUS server, a loopback interface address is specified as the source IP address of the packets sent from the router.

This ensures the security of the server. In this situation, packets are filtered to protect the RADIUS server and RADIUS agent. This is because only the packets from a loopback interface address can access the port of the RADIUS server. This facilitates reading and writing logs. There are only loopback interface addresses rather than outbound interface addresses in RADIUS logs.

Null0 Interface

The Null0 interface does not forward packets. All packets sent to this interface are discarded. The Null0 interface is applied in two situations:

Loop prevention

The Null0 interface is typically used to prevent routing loops. For example, during route aggregation, a route to the Null0 interface is always created.

In the example network shown in Figure 1-650, DeviceA provides access services for multiple remote nodes.

DeviceA is the gateway of the local network that uses the Class B network segment address 172.16.0.0/16. DeviceA connects to three subnets through DeviceB, DeviceC, and DeviceD, respectively.

Figure 1-650 Example for using the Null0 interface to prevent routing loops

Normally, the routing table of DeviceA contains the following routes:
- Routes to three subnets: 172.16.2.0/24, 172.16.3.0/24, and 172.16.4.0/24
- Network segment routes to DeviceB, DeviceC, and DeviceD
- Default route to the ISP network
If routerDeviceE on the ISP network receives a packet with the destination address on the network segment 172.16.10.0/24, it forwards the packet to DeviceA.

If the destination address of the packet does not belong to the network segment to which DeviceB, DeviceC, or DeviceD is connected, DeviceA searches the routing table for the default route, and then sends the packet to DeviceE.

In this situation, the packets whose destination addresses belong to the network segment 172.16.10.0/24 but not the network segment to which DeviceB, DeviceC, or DeviceD is connected are repeatedly transmitted between DeviceA and DeviceE. As a result, a routing loop occurs.

To address this issue, a static route to the Null0 interface is configured on DeviceA. Then, after receiving the packet whose destination network segment does not belong to any of the three subnets, DeviceA finds the route whose outbound interface is the Null0 interface according to exact matching rules, and then discards the packet.

Therefore, configuring a static route on DeviceA whose outbound interface is the Null0 interface can prevent routing loops.
Traffic filtering

The Null0 interface provides an optional method for filtering traffic. Unnecessary packets are sent to the Null0 interface to avoid using an Access Control List (ACL).

Both the Null0 interface and ACL can be used to filter traffic as follows.
- Before the ACL can be used, ACL rules must be configured and then applied to an interface. When a router receives a packet, it searches the ACL.
  - If the action is permit, the router searches the forwarding table and then determines whether to forward or discard the packet.
  - If the action is deny, the router discards the packet.
- The Null0 interface must be specified as the outbound interface of unnecessary packets. When a router receives a packet, it searches the forwarding table. If the router finds that the outbound interface of the packet is the Null0 interface, it discards the packet.
Using a Null0 interface to filter traffic is more efficient and faster than using an ACL. For example, if you do not want a router to accept packets with a specified destination address, use the Null0 interface for packet filtering. This only requires a route to be configured. Using an ACL for packet filtering requires an ACL rule to be configured and then applied to the corresponding interface on a router. However, the Null0 interface can filter only router-based traffic, whereas an ACL can filter both router-based and interface-based traffic. For example, if you do not want Serial 1/0/0 on a router to accept traffic with the destination address 172.18.0.0/16, you can only configure an ACL rule and then apply it to Serial 1/0/0 for traffic filtering.

Tunnel Interface

A tunnel interface is a virtual logical interface. To apply certain types of tunnels, you must create a tunnel interface first.

The destination address specified on the local tunnel interface is the IP address of the peer interface that receives packets. This address must be the same as the source address specified on the peer tunnel interface. In addition, routes to the peer interface that receives packets must be reachable. The same source or destination address cannot be configured for two or more tunnel interfaces that use the same encapsulation protocol.

Different encapsulation modes can be configured for tunnel interfaces depending on the utilities of the interfaces. The following table lists the types of tunnels for which tunnel interfaces can be created.

Table 1-335 Tunnel types supported by tunnel interfaces

Tunnel Type	Encapsulation Protocol	Usage Scenario
IPv6 over IPv4 tunnel	IPv4	An IPv6 over IPv4 manual tunnel is manually configured between the two border routing devices. The source and destination IPv4 addresses of the tunnel need to be statically specified. A manual tunnel can be used for communication between IPv6 networks and can also be configured between a border routing device and host. A manual tunnel offers the point-to-point service.
6to4 tunnel	IPv4	A 6to4 tunnel can connect multiple IPv6 networks through an IPv4 network. A 6to4 tunnel can be a P2MP connection, whereas a manual tunnel is a P2P connection. Therefore, routing devices on both ends of the 6to4 tunnel are not configured in pairs.
MPLS TE tunnel	An MPLS TE tunnel is established through the cooperation of a series of protocol components. For details, see MPLS TE Fundamentals > Technology Overview in the product manual.	An MPLS TE tunnel is uniquely identified by the following parameters: Tunnel interface: The interface type is "tunnel." The interface number is expressed in the format of SlotID/CardID/PortID. Tunnel ID: a decimal number that identifies an MPLS TE tunnel and facilitates tunnel planning and management. A tunnel ID must be specified before an MPLS TE tunnel interface is configured.
GRE tunnel	GRE	GRE provides a mechanism of encapsulating packets of a protocol into packets of another protocol. This allows packets to be transmitted over heterogeneous networks. The channel for transmitting heterogeneous packets is called a tunnel.
IPsec tunnel	IPSec	A security policy group is applied to tunnel interfaces to protect different data flows. Only one security policy group can be applied to a tunnel interface.
IPv4 over IPv6 tunnel	IPv6	An IPv4 over IPv6 manual tunnel is manually configured between the two border routing devices. The source and destination IPv6 addresses of the tunnel need to be statically specified. A manual tunnel can be used for communication between IPv4 networks and can also be configured between a border routing device and host. A manual tunnel offers the point-to-point service.
6RD tunnel	IPv4	A 6RD tunnel is a point-to-multipoint tunnel that connects to IPv6 sites through a carrier's IPv4 network. A tunnel interface must be created before the tunnel encapsulation type is set to 6RD.

Interface Group Application

Generally, a switching device provides multiple interfaces, many of which have the same configuration. If these interfaces are configured one by one, the operations are complex and errors may occur. To resolve this problem, create an interface group and then add the interfaces that require the same configuration command to the interface group. When you run the configuration command in the interface group view, the system automatically executes this command on all the member interfaces in the interface group, implementing batch configuration. As shown in Figure 1-651, a large number of interfaces exist on the aggregation and access switches. Many of these interfaces have the same configurations. If they are configured separately, the management cost is high. Therefore, you can create interface groups on these switches.

Figure 1-651 Networking diagram of interface group application

Application of Interface Monitoring Group

In the network shown in Figure 1-652, PE2 backs up PE1. NPE1 through NPEM on the user side are dual-homed to the two PEs to load-balance traffic, and the two PEs are connected to Router A through Router N on the network side. When only the link between PE1 and Router N is available and all the links between PE1 and all the other routers fail, the NPEs do not detect the failure and continue sending packets to Router N through PE1. As a result, the link between PE1 and Router N becomes overloaded.

Figure 1-652 Interface monitoring group application
Click to enlarge

To resolve this problem, you can configure an interface monitoring group and add multiple network-side interfaces on the PEs to the interface monitoring group. When a link failure occurs on the network side and the interface monitoring group detects that the status of a certain proportion of network-side interfaces changes, the system instructs the user-side interfaces associated with the interface monitoring group to change their status accordingly and allows traffic to be switched between the master and backup links. Therefore, the interface monitoring group can be used to prevent traffic overloads or interruptions.

Interface Management Configuration

Interface management helps to provide quick and accurate communication between devices.

Overview of Interface Management

This section provides the physical and logical interfaces supported by the NetEngine 8100 M, NetEngine 8000E M, NetEngine 8000 M and describes the interface views and prompts and common link protocols and access technologies.

Interface Types

Devices exchange data and interact with other devices on a network through interfaces. Interfaces are classified into physical and logical interfaces.

Physical Interfaces

Physical interfaces physically exist on boards. They are divided into the following types:
- LAN interfaces: interfaces through which the router can exchange data with other devices on a LAN.
- WAN interfaces: interfaces through which the router can exchange data with remote devices on external networks.
Logical Interfaces

Logical interfaces are manually configured interfaces that do not exist physically. Logical interfaces can be used to exchange data.

The management network port of the main control board does not forward services.

Interface Views and Prompts

Table 1-336 lists the commands, views, and prompts of physical interfaces supported by the NetEngine 8100 M, NetEngine 8000E M, NetEngine 8000 M. Table 1-337 lists the commands, views, and prompts of logical interfaces supported by the NetEngine 8100 M, NetEngine 8000E M, NetEngine 8000 M.

Table 1-336 Commands, views, and prompts of physical interfaces supported by the NetEngine 8100 M, NetEngine 8000E M, NetEngine 8000 M

Interface Name	Command View	Operation	Prompt
GE interface	GE interface view	Run the interface gigabitethernet 0/2/0 command in the system view.	[~HUAWEI-GigabitEthernet0/2/0]
10GE interface	10GE interface view	Run the interface gigabitethernet 0/1/0 command in the system view. NOTE: The interfaces marked with 10G displayed in the display interface brief command output indicate GE interfaces whose bandwidth is 10 Gbit/s.	[~HUAWEI-GigabitEthernet0/1/0]
25GE interface	25GE interface view	Run the interface 25GE 0/2/0 command in the system view.	[~HUAWEI-25GE0/2/0]
40GE interface	40GE interface view	Run the interface 40GE 0/2/0 command in the system view.	[~HUAWEI-40GE0/2/0]
100GE interface	100GE interface view	Run the interface 100GE 0/1/0 command in the system view.	[~HUAWEI-100GE0/1/0]
200GE interface	200GE interface view	Run the interface 200GE 0/1/0 command in the system view.	[~HUAWEI-200GE0/1/0]
400GE interface	400GE interface view NOTE: This interface is not supported on the NetEngine 8000 M8K or NetEngine 8000 M14K.	Run the interface 400GE 0/1/0 command in the system view.	[~HUAWEI-400GE0/1/0]
XGE interface	XGE interface view	Run the interface XGigabitEthernet 0/1/0 command in the system view.	[~HUAWEI-XGigabitEthernet0/1/0]
CPOS interface	CPOS interface view NOTE: This interface is not supported on the NetEngine 8000 M4.	Run the controller cpos 0/3/0 command in the system view.	[~HUAWEI-Cpos0/3/0]
POS interface	POS interface view NOTE: This interface is not supported on the NetEngine 8000 M4.	Run the interface pos 0/3/0 command in the system view.	[~HUAWEI-Pos0/3/0]
50GE interface	50GE interface view	Run the interface 50GE 0/1/0 command in the system view.	[~HUAWEI-50GE0/1/0]
50\|100GE interface	50\|100GE interface view NOTE: The default rate of this type of interface is 50 Gbit/s and can be switched to 100 Gbit/s.	Run the interface 50\|100GE 0/1/0 command in the system view.	[~HUAWEI-50\|100GE0/1/0]
FlexE-50G interface	FlexE-50G interface view	Run the interface FlexE-50G 0/1/0 command in the system view.	[~HUAWEI-FlexE-50G0/1/0]
FlexE-100G interface	FlexE-100G interface view NOTE: This interface is not supported on the NetEngine 8000 M8K or NetEngine 8000 M14K.	Run the interface FlexE-100G 0/1/0 command in the system view.	[~HUAWEI-FlexE-100G0/1/0]
FlexE-400G interface	FlexE-400G interface view	Run the interface FlexE-400G 0/1/0 command in the system view.	[~HUAWEI-FlexE-400G0/1/0]
FlexE-10G interface	FlexE-10G interface view NOTE: This interface is not supported on the NetEngine 8000 M4, NetEngine 8000 M8K, and NetEngine 8000 M14K.	Run the interface FlexE-10G 0/1/0 command in the system view.	[~HUAWEI-FlexE-10G0/1/0]

Table 1-337 Commands, views, and prompts of logical interfaces

Interface Name	Command View	Operation	Prompt
Sub-interface	Sub-interface view	Run the interface gigabitethernet 0/1/0.1 command in the system view.	[~HUAWEI-GigabitEthernet0/1/0.1]
Eth-Trunk interface	Eth-Trunk interface view	Run the interface eth-trunk 2 command in the system view.	[~HUAWEI-Eth-Trunk2]
VE interface	VE interface view	Run the interface virtual-ethernet 0/1/0 command in the system view.	[~HUAWEI-Virtual-Ethernet0/1/0]
Global VE interface	Global VE interface view	Run the interface global-ve 0 command in the system view.	[~HUAWEI-Global-VE0]
VLANIF interface	VLANIF interface view	Run the interface vlanif 2 command in the system view.	[~HUAWEI-Vlanif2]
Loopback interface	Loopback interface view	Run the interface loopback 2 command in the system view.	[~HUAWEI-LoopBack2]
Null interface	Null interface view	Run the interface null 0 command in the system view.	[~HUAWEI-NULL0]
IP-Trunk interface	IP-Trunk interface view	Run the interface ip-trunk 2 command in the system view.	[~HUAWEI-Ip-Trunk2]
Tunnel interface	Tunnel interface view	Run the interface tunnel 2 command in the system view.	[~HUAWEI-Tunnel 2]
NVE interface	NVE interface view	Run the interface nve 1 command in the system view.	[~HUAWEI-Nve1]
FlexE interface	FlexE interface view	Run the interface FlexE 0/2/5 command in the system view.	[~HUAWEI-FlexE0/2/5]
Virtual serial interface	Virtual serial interface view	Run the interface Virtual-Serial 0/2/0 command in the system view.	[~HUAWEI-Virtual-Serial0/2/0]
PW-VE interface	PW-VE interface view	Run the interface pw-ve 1 command in the system view.	[~HUAWEI-pw-ve1]

Commonly-used Link Protocols and Access Technologies

Major link layer protocols supported by the NetEngine 8100 M, NetEngine 8000E M, NetEngine 8000 M are listed as follows:

Ethernet

Currently, the LAN mostly refers to the Ethernet. The Ethernet is a broadcast network, which is flexible and simple in configuration as well as easy to expand. For these reasons, the Ethernet is widely used.
Trunk

Trunks can be classified into Eth-Trunks and IP-Trunks. An Eth-Trunk must be composed of Ethernet links, and an IP-Trunk must be composed of POS links.

The trunk technology has the following advantages:
- Bandwidth increase: The bandwidth of a trunk is the total bandwidth of all member interfaces.
- Reliability enhancement: When a link fails, other links in the same trunk automatically take over the services on the faulty link to prevent traffic interruption.
PPP

The Point-to-Point Protocol (PPP) is used to encapsulate IP packets on serial links. It supports both the asynchronous transmission of 8-bit data without the parity check and the bit-oriented synchronous connection.

PPP consists of the Link Control Protocol (LCP) and the Network Control Protocol (NCP). LCP is used to create, configure, and test links; NCP is used to control different network layer protocols.
HDLC

The High-Level Data Link Control (HDLC) is a suite of protocols that are used to transmit data between network nodes. HDLC is widely used at the data link layer.

In HDLC, the receiver responds with an acknowledgment when it receives frames transmitted over the network. In addition, HDLC manages data flows and the interval at which data packets are transmitted.

Interface Flapping Control

The following two control modes are available.

Table 1-338 Flapping control modes

Control Mode	Function	Usage Scenario
control-flap	Controls the frequent flappings of interfaces at the network layer to minimize the impact on device and network stability.	This control mode is interface-specific. This control mode suppresses interface flappings from the network layer and reports the flappings to the routing management module, thereby improving network-layer stability. This control mode allows you to precisely configure parameters based on service requirements. This control mode involves complex algorithms and is highly demanding to use.
damp-interface	Controls the frequent flappings of interfaces at the physical layer to minimize the impact on device and network stability.	This function is supported globally or on a specified interface. This control mode suppresses the flappings from the physical layer, thereby improving link-layer and network-layer stability. This control mode prevents the upper-layer protocols from frequently alternating between enabled and disabled, thereby reducing the consumption of CPU and memory resources. This control mode does not involve any complex algorithms and is easy to use.

Configuration Precautions for Interface Management

Feature Requirements

Table 1-339 Feature requirements

Feature Requirements	Series	Models
Dual-stack statistics collection on VLANIF interfaces does not support multicast statistics collection.	NetEngine 8000 M	NetEngine 8000 M14/NetEngine 8000 M14K/NetEngine 8000 M4/NetEngine 8000 M8/NetEngine 8000 M8K/NetEngine 8000E M14/NetEngine 8000E M8/NetEngine 8100 M14/NetEngine 8100 M8
During an independent NP reset, the VE interface status does not change accordingly, and services that depend on the VE interface status change do not take effect.	NetEngine 8000 M	NetEngine 8000 M14/NetEngine 8000 M14K/NetEngine 8000 M4/NetEngine 8000 M8/NetEngine 8000 M8K/NetEngine 8000E M14/NetEngine 8000E M8/NetEngine 8100 M14/NetEngine 8100 M8
For Ethernet and Eth-Trunk interfaces, channelized sub-interfaces support only VLAN-type dot1q sub-interfaces and QinQ VLAN tag termination sub-interfaces. For POS interfaces, channelized sub-interfaces support only POS FR sub-interfaces. Other types of main interfaces do not support channelized sub-interfaces.	NetEngine 8000 M	NetEngine 8000 M14/NetEngine 8000 M14K/NetEngine 8000 M4/NetEngine 8000 M8/NetEngine 8000 M8K/NetEngine 8000E M14/NetEngine 8000E M8/NetEngine 8100 M14/NetEngine 8100 M8
1. If the number of FlexE physical interfaces, FlexE physical interface numbers, FlexE number ranges and groups, and FlexE sub-timeslot granularity capabilities are the same before and after the replacement, the FlexE configuration is retained after the replacement. 2. If the new board or subcard does not support FlexE, the existing FlexE configuration on the board or subcard will be deleted. 3. If the original subcard is configured with a 1.25 Gbit/s FlexE sub-timeslot granularity and the new subcard does not support the 1.25 Gbit/s FlexE sub-timeslot granularity, all FlexE configurations except the timeslot or bandwidth mode on the subcard will be deleted. 4. If a pass-through or non-pass-through card is replaced, the existing FlexE configuration will be deleted. 5. If the port ID used by a FlexE client is not supported after the replacement, the FlexE client and FlexE interface will be deleted. 6. If a FlexE physical interface bound to a FlexE group does not exist, does not support FlexE, or cannot be bound to each other after the replacement, the FlexE group, FlexE clients created in the FlexE group, and FlexE interfaces will be deleted. 7. In subcard replacement scenarios, if the number of FlexE clients created in the FlexE group to which the bound FlexE physical interfaces belong exceeds the capability of the new board or subcard, the interface with a larger port ID in the FlexE clients is preferentially deleted.	NetEngine 8000 M	NetEngine 8000 M14/NetEngine 8000 M14K/NetEngine 8000 M4/NetEngine 8000 M8/NetEngine 8000 M8K/NetEngine 8000E M14/NetEngine 8000E M8/NetEngine 8100 M14/NetEngine 8100 M8
The commands used to query information about interfaces do not support offline interfaces.	NetEngine 8000 M	NetEngine 8000 M14/NetEngine 8000 M14K/NetEngine 8000 M4/NetEngine 8000 M8/NetEngine 8000 M8K/NetEngine 8000E M14/NetEngine 8000E M8/NetEngine 8100 M14/NetEngine 8100 M8
The interface fixed index function is dependent on device.sys files. When the data in device.sys files is deleted, the interface index may change after the device restart.	NetEngine 8000 M	NetEngine 8000 M14/NetEngine 8000 M14K/NetEngine 8000 M4/NetEngine 8000 M8/NetEngine 8000 M8K/NetEngine 8000E M14/NetEngine 8000E M8/NetEngine 8100 M14/NetEngine 8100 M8
When switching the working rate of a 25GE interface on a CR5D00L4XF91/CR5D00E4XM25 subcard, pay attention to the following restrictions: Before switching the working rate (including manual and adaptive bandwidth switching modes), check whether the interface is added to a VS. If the interface is added to a VS, the bandwidth mode cannot be switched.	NetEngine 8000 M	NetEngine 8000 M14/NetEngine 8000 M8/NetEngine 8100 M14/NetEngine 8100 M8
1. The default rate of a GE electrical interface is 1000 Mbit/s and the interface works in auto-negotiation mode. You can forcibly change the rate, but ensure that the rate is the same as that of the peer end. When the rate is set to 10 Mbit/s or 100 Mbit/s, the auto-negotiation mode is canceled. 2. After an Ethernet electrical interface is removed from a GE interface card with both optical and electrical interfaces and an Ethernet optical interface is inserted into the interface card, the system automatically clears the configuration commands related to the electrical interface on the electrical interface.	NetEngine 8000 M	NetEngine 8000 M14/NetEngine 8000 M4/NetEngine 8000 M8/NetEngine 8000E M14/NetEngine 8000E M8/NetEngine 8100 M14/NetEngine 8100 M8
1. Before configuring the GE optical/electrical interface mode, delete all configurations on the interface. 2. After an Ethernet electrical interface is removed from an 8-port 100/1000Base-X-SFP service interface card and an Ethernet optical interface is inserted into the interface card, the system automatically clears the configuration commands related to the electrical interface.	NetEngine 8000 M	NetEngine 8000 M14/NetEngine 8000 M4/NetEngine 8000 M8/NetEngine 8000E M14/NetEngine 8000E M8/NetEngine 8100 M14/NetEngine 8100 M8
XGE interfaces are under PAF control. A 10GE interface is renamed as an XGE interface after the PAF is installed on the device and the device is restarted. The original 10GE interface configurations are lost, and reconfiguration needs to be performed on the XGE interface. After the AP for interface extension is installed with the PAF and restarted, if the external communication interface is a 10GE interface, the external communication interface needs to be reconfigured.	NetEngine 8000 M	NetEngine 8000 M14/NetEngine 8000 M14K/NetEngine 8000 M4/NetEngine 8000 M8/NetEngine 8000 M8K/NetEngine 8000E M14/NetEngine 8000E M8/NetEngine 8100 M14/NetEngine 8100 M8
When SQ-based rate limiting is configured on an eTM subcard and the traffic rate exceeds the SQ bandwidth, statistics about outgoing traffic on the interface are inaccurate. In this case, statistics about outgoing traffic on the sub-interface are greater than the actual traffic statistics after rate limiting. You can run the "display port-queue statistics interface" {<interface-type interface-number> \| <interface-name>} [<cos-value>] "outbound" command to obtain the actual statistics about outgoing traffic.	NetEngine 8000 M	NetEngine 8000 M14/NetEngine 8000 M14K/NetEngine 8000 M4/NetEngine 8000 M8/NetEngine 8000 M8K/NetEngine 8000E M14/NetEngine 8000E M8/NetEngine 8100 M14/NetEngine 8100 M8
When a router is directly connected to a non-Huawei device, if the router is powered off and restarted and sends signals immediately after the interface is initialized, some data may be lost because the configuration restoration of the router is not complete. To prevent this problem, run the port-tx-enabling-delay <port-tx-delay-time> command in the interface view to enable the interface to send signals after a delay and set the delay.	NetEngine 8000 M	NetEngine 8000 M14/NetEngine 8000 M14K/NetEngine 8000 M4/NetEngine 8000 M8/NetEngine 8000 M8K/NetEngine 8000E M14/NetEngine 8000E M8/NetEngine 8100 M14/NetEngine 8100 M8
When VPN QoS is configured for a VSI or VLL, a channelized sub-interface cannot be created for the VS. After a channelized sub-interface is created, VPN QoS cannot be configured for any VSI or VLL of the VS.	NetEngine 8000 M	NetEngine 8000 M14/NetEngine 8000 M14K/NetEngine 8000 M4/NetEngine 8000 M8/NetEngine 8000 M8K/NetEngine 8000E M14/NetEngine 8000E M8/NetEngine 8100 M14/NetEngine 8100 M8
When switching the working rate of 25GE or 10GE ports 0 to 23, pay attention to the following restrictions: Before switching the working rate (including manual and adaptive bandwidth switching modes), check whether the interface is added to a VS. If the interface is added to a VS, the bandwidth mode cannot be switched.	NetEngine 8000 M	NetEngine 8000 M14/NetEngine 8000 M8/NetEngine 8100 M14/NetEngine 8100 M8
The configuration restrictions on interfaces 24 to 43 are as follows: 1. After interface splitting is configured or canceled, the configuration takes effect immediately and the original interface configuration is lost. Therefore, exercise caution when performing this operation. 2. Before executing the interface splitting configuration, check whether the interface whose configuration needs to be deleted is added to a VS. If an interface is added to a VS, the interface splitting configuration cannot be executed.	NetEngine 8000 M	NetEngine 8000 M14/NetEngine 8000 M8/NetEngine 8100 M14/NetEngine 8100 M8
On eTM boards and subcards, when the egress traffic on a channelized sub-interface exceeds the configured bandwidth of the channelized sub-interface, the egress traffic is limited to the bandwidth of the channelized sub-interface. In this case, the number of packets, the number of bytes, and the rate in the outbound direction are incorrect. However, the statistics on unicast, broadcast, multicast, and IPv4/IPv6 dual-stack traffic are the egress traffic before the rate limit.	NetEngine 8000 M	NetEngine 8000 M14/NetEngine 8000 M14K/NetEngine 8000 M4/NetEngine 8000 M8/NetEngine 8000 M8K/NetEngine 8000E M14/NetEngine 8000E M8/NetEngine 8100 M14/NetEngine 8100 M8
The POS subcard CR5D00P4CFC1 has the following restrictions: 1. POS interfaces on the subcard support only the SDH frame format. 2. POS interfaces on the subcard support only PPP encapsulation. 3. The maximum MTU of a POS interface on the subcard is 1920 bytes. Before adding a POS interface to a POS-Trunk interface, change the MTU of the POS-Trunk interface to a value less than 1920 bytes. Otherwise, the POS interface cannot be added to the POS-Trunk interface. If a POS-Trunk interface contains POS interfaces on the subcard, the maximum MTU that can be configured is 1920. 4. PPP-encapsulated POS interfaces on the subcard cannot receive or send LLDP packets whose protocol field in the PPP header is 0x88cc (not complying with the PPP standard), but can receive or send LLDP packets whose protocol field in the PPP header is 0x88cb.	NetEngine 8000 M	NetEngine 8000 M14/NetEngine 8000 M14K/NetEngine 8000 M8/NetEngine 8000 M8K/NetEngine 8000E M14/NetEngine 8000E M8/NetEngine 8100 M14/NetEngine 8100 M8
The E1 subcard DPE1MDE1 does not support ATM or IMA.	NetEngine 8000 M	NetEngine 8000 M14/NetEngine 8000 M8/NetEngine 8000E M14/NetEngine 8000E M8/NetEngine 8100 M8
A 50G or 100G interface automatically configures an FEC mode based on the type of the installed optical module to ensure normal service running. If the FEC modes of multiple FlexE physical interfaces in a FlexE group are different, an hwFlexEGrpFecModeMismatch alarm is reported. After the alarm is generated, the FEC configuration on the interface remains unchanged even if the optical module is removed. In this case, the alarm cannot be cleared. To clear the alarm, perform the following steps: Install an optical module with the same FEC mode. Delete the physical interfaces with different FEC modes. Run the fec-eth command to configure the same FEC mode for the interfaces. (Only 100G interfaces support this command. If the optical module does not match the FEC mode, services on the interfaces may be affected.)	NetEngine 8000 M	NetEngine 8000 M14/NetEngine 8000 M14K/NetEngine 8000 M4/NetEngine 8000 M8/NetEngine 8000 M8K/NetEngine 8000E M14/NetEngine 8000E M8/NetEngine 8100 M14/NetEngine 8100 M8
The display counters rate command displays only the rates at which interfaces in Up state send and receive packets.	NetEngine 8000 M	NetEngine 8000 M14/NetEngine 8000 M14K/NetEngine 8000 M4/NetEngine 8000 M8/NetEngine 8000 M8K/NetEngine 8000E M14/NetEngine 8000E M8/NetEngine 8100 M14/NetEngine 8100 M8
After IP address conflict detection is disabled and the preemption function for conflicting IP addresses is enabled: 1. If the preemption function for conflicting IP addresses is disabled, the same IP address may take effect on a different interface after a device restart. 2. The preemption function for conflicting IP addresses does not take effect for VRRP virtual addresses. 3. If the IP address of the source interface specified for a service takes effect on another interface with a higher priority, the protocol status of the source interface is Down, which may cause service interruption. 4. After a conflicting IP address takes effect on an interface with a higher priority, traffic may be temporarily interrupted due to interface switchover.	NetEngine 8000 M	NetEngine 8000 M14/NetEngine 8000 M14K/NetEngine 8000 M4/NetEngine 8000 M8/NetEngine 8000 M8K/NetEngine 8000E M14/NetEngine 8000E M8/NetEngine 8100 M14/NetEngine 8100 M8
The remaining bandwidth of a main interface displays only the traffic rate of the main interface and does not include the traffic rate of sub-interfaces (regardless of channelized and non-channelized sub-interfaces). For example, the channelized sub-interface GigabitEthernet 2/1/11.1 is created on the physical interface GigabitEthernet 2/1/11 that is configured with an IP address and carries services. In this case, the remaining bandwidth of the channelized main interface queried on the physical interface is the rate of traffic carried on the physical interface. If a non-channelized sub-interface GE 2/1/11.2 is created (this scenario does not exist), the remaining bandwidth of the channelized main interface queried on the physical interface is still the rate of traffic carried on the physical interface and does not include the traffic rate of the non-channelized sub-interface GE 2/1/11.2. The corresponding query command is as follows: display interface GigabitEthernet2/1/11 externsive Remaining bandwidth deducted from channelized sub-interface: 1000 Mbits/sec Last 300 seconds input remaining rate: 5000 bits/sec, 200 packets/sec Last 300 seconds output remaining rate: 5000 bits/sec, 200 packets/sec Input remaining bandwidth utilization: 0.00% Output remaining bandwidth utilization: 0.00%	NetEngine 8000 M	NetEngine 8000 M14/NetEngine 8000 M14K/NetEngine 8000 M4/NetEngine 8000 M8/NetEngine 8000 M8K/NetEngine 8000E M14/NetEngine 8000E M8/NetEngine 8100 M14/NetEngine 8100 M8
Statistics about downstream protocol packets are not collected on VE main interfaces (including global VE main interfaces). Cause: Downstream protocol packets are transparently transmitted in the forwarding process and cannot be collected on the forwarding plane.	NetEngine 8000 M	NetEngine 8000 M14/NetEngine 8000 M14K/NetEngine 8000 M4/NetEngine 8000 M8/NetEngine 8000 M8K/NetEngine 8000E M14/NetEngine 8000E M8/NetEngine 8100 M14/NetEngine 8100 M8

Interface Basics Configuration

Learning about interface basics, including common interface types and configurable interface parameters, helps with interface management.

Usage Scenario

To ensure better communication between devices on the network, physical and logical interfaces must be used together. In addition, you need to set parameters for each interface as required, such as the description, MTU, alarm thresholds for the inbound and outbound bandwidth usage of each interface, interval for collecting traffic statistics, trap reporting to the NMS when the protocol status of an interface changes, and control-flap.

Pre-configuration Tasks

Before performing interface basics configurations, verify that the device has been powered on and started properly.

Entering the Interface View

The command for entering the view of an interface varies with the physical attribute of the interface.

Procedure

Run system-view
The system view is displayed.
Run interface interface-type interface-number
The interface view is displayed.

In this command, interface-type specifies the type of the interface, and interface-number specifies the number of the interface.
(Optional) Run commit
The configuration is committed.

If the interface of the specified type and number exists in the preceding step, you do not need to run the commit command.

(Optional) Setting Interface Parameters

This section describes how to set parameters for an interface based on the actual service requirements. The parameters include the description and maximum transmission unit (MTU).

Context

Table 1-340 describes the configurable parameters of an interface.

Table 1-340 Configurable parameters of an interface

Parameter	Description
Interface description	When you maintain a large number of interfaces, an interface description helps identify an interface easily.
Interface MTU	After the MTU is configured for an interface, the device fragments a packet transmitted on the interface if the size of the packet exceeds the MTU. NOTE: Loopback and NULL interfaces do not support the MTU.
Interface bandwidth that can be obtained by the NMS through the MIB	You can calculate the bandwidth usage by setting the interface bandwidth that can be obtained by the NMS through the MIB.
Whether the device sends a trap message to the NMS when the interface status changes	You can enable the device to send a trap message to the NMS when the interface status changes. After this function is enabled, the NMS monitors the interface status in real time. However, if an interface alternates between up and down, the device will frequently send trap messages to the NMS, which increases the processing load on the NMS. In this situation, you can disable the device from sending trap messages to the NMS to avoid adverse impact on the NMS.
Interval at which traffic statistics are collected	After setting the interval at which traffic statistics are collected for an interface, you can view the traffic volumes and rates of the interface in different time ranges.
Whether the control-flap function is enabled	Control-flap controls the frequency of interface status alternations between up and down, which minimizes the impact on device and network stability. NOTE: Loopback and NULL interfaces do not support the control-flap function.

Procedure

Run system-view
The system view is displayed.
Run interface interface-type interface-number
The interface view is displayed.

In this command, interface-type specifies the type of the interface, and interface-number specifies the number of the interface.

Perform one or more operations in Table 1-341 to set the desired interface parameters.

Table 1-341 Setting interface parameters

Operation	Description
Configure a description for an interface.	Run the description regular-expression command to configure a description for an interface.
Set an MTU for an interface.	Run the mtu mtu or ipv6 mtu mtu command to set an MTU for an interface. Run the mtu mtu spread or ipv6 mtu mtu spread command to set an MTU for an interface and apply the MTU to all the sub-interfaces on the interface. NOTE: After changing the MTU on a POS interface using the mtu or mtu spread command, run the shutdown and undo shutdown commands in the interface view for the change to take effect. Alternatively, you can run the restart command in the interface view to restart the interface for the change to take effect. If IPv4 attributes are configured on an interface, run the mtu or mtu spread command to set an MTU for the IPv4 packets to be sent by the interface. If IPv6 attributes are configured on an interface, run the ipv6 mtu or ipv6 mtu spread command to set an MTU for the IPv6 packets to be sent by the interface.
Set configuration bandwidth for an interface.	Run the bandwidth command to set configuration bandwidth for an interface. NOTE: To view the command configurations, you can check the ifSpeed and ifHighSpeed objects in the IF-MIB on the NMS. By default, services typically use only the physical bandwidth for protocol route selection calculation. You can run the bandwidth-config effect service enable command to use the configuration bandwidth for protocol route selection calculation.
Configure whether the device sends a trap message to the NMS when the interface status changes.	Run the enable snmp trap updown command to enable the device to send a trap message to the NMS when the interface status changes. NOTE: If an interface alternates between up and down, the device will frequently send trap messages to the NMS, which increases the processing load on the NMS. In this situation, you can run the undo enable snmp trap updown command to disable the device from sending trap messages to the NMS to avoid adverse impact on the NMS.
Set the interval at which traffic statistics are collected.	Run the set flow-stat interval interval command to set the interval at which traffic statistics are collected. NOTE: To set a global interval at which traffic statistics are collected, run the set flow-stat interval interval command in the system view, and you do not need to run the interface interface-type interface-number command. You can configure a global traffic statistic collection interval, which takes effect on all interfaces, including the interfaces on which no traffic statistic collection interval has been set. The new interval takes effect after the original interval expires. If the interface is logical, traffic statistics about the interface are updated when the new interval takes effect for the second time. If the interface is physical, traffic statistics about the interface are updated immediately after the new interval takes effect.
Enable the control-flap function.	Run the control-flap [ suppress reuse ceiling decay-ok decay-ng ] command to enable the control-flap function on an interface. The value of suppress is 1000 times the interface suppression threshold. It ranges from 1 to 20000. The default value is 2000. The value of suppress must be greater than the value of reuse and less than the value of ceiling. The value of reuse is 1000 times the interface reuse threshold. It ranges from 1 to 20000. The default value is 750. The value of reuse must be less than the value of suppress. The value of ceiling is 1000 times the maximum interface suppression penalty value. It ranges from 1001 to 20000. The default value is 6000. The value of ceiling must be greater than the value of suppress. decay-ok specifies the half life for the penalty value when an interface is up. It ranges from 1 to 900, in seconds. The default value is 54. decay-ng specifies the half life for the penalty value when an interface is down. It ranges from 1 to 900, in seconds. The default value is 54.
Configure whether to adjust the modulation mode of an interface.	Run the signal-coding { dqpsk \| qpsk } command to configure a modulation mode for an interface.

Run commit
The configuration is committed.

Enabling an Interface

Physical interfaces on a device are initialized and started when the device is powered on.

Context

This configuration process is supported only by the admin VS.

Procedure

By default, interfaces are started.
If an interface is shut down, perform the following steps to start the interface:
1. Run system-view
  The system view is displayed.
2. Run interface interface-type interface-number
  The interface view is displayed.
3. Run undo shutdown
  The interface is started.
4. Run commit
  The configuration is committed.

(Optional) Configuring a Device to Send a Trap Message to an NMS When an Interface Physical Status Changes

You can enable a device to send a trap message to an NMS when the interface physical status changes. After this function is enabled, the NMS monitors the interface status in real time.

Procedure

Run system-view
The system view is displayed.
Run interface interface-type interface-number
The interface view is displayed.
Run enable snmp trap physical-updown
The device is enabled to send a trap message to the NMS when the interface physical status changes.
Run commit
The configuration is committed.

(Optional) Configuring IPv4 and IPv6 Traffic Statistics Collection on a Main Interface

You can configure IPv4 and IPv6 traffic statistics collection for all main interfaces.

Context

Do as follows on the router that needs to be configured with IPv4 and IPv6 traffic statistics collection.

Procedure

Run system-view
The system view is displayed.
Run interface interface-type interface-number
The interface view is displayed.
Run statistic enable
IPv4 and IPv6 traffic statistics collection is enabled on the main interface.
Run statistic mode forward
IPv4 and IPv6 traffic statistics collection is enabled on the main interface.
(Optional) Run statistic accelerate enable
Statistics acceleration is enabled on the interface.

If dual-stack statistics collection is enabled on a main interface, you can run this command to improve the forwarding performance of the main interface.
Run commit
The configuration is committed.

(Optional) Configuring Power Locking and Gain Locking for an Optical Amplifier Module

You can configure power locking and gain locking for an optical amplifier module to amplify the optical power.

Context

Perform the following steps on the router where power locking and gain locking need to be configured for an optical amplifier module.

Procedure

Run system-view
The system view is displayed.
Perform either of the following configurations as required.
- Run the interface interface-type interface-number command to enter the view of a specified interface.
Run work-mode { agc agc-value | apc apc-value }
Power locking and gain locking are configured for the optical amplifier module.
Run commit
The configuration is committed.

Setting Thresholds for Generating and Clearing Packet Loss Rate Alarms on an MP-group or Global MP-group Interface

To allow the device to generate and clear packet loss rate alarms on an MP-group or global MP-group interface, set packet loss alarm thresholds.

Context

When an interface discards packets frequently, the link is in the poor condition, affecting service transmission. If you want to monitor the link quality, set thresholds for generating and clearing packet loss rate alarms on the MP-group interface or global MP-group interface.

Procedure

Run system-view
The system view is displayed.
Run interface interface-type interface-number
The interface view is displayed.

MP-group and global MP-group interfaces are supported.
Run trap-threshold mp-lospkt-exc trigger-threshold coefficient-value power-value [ resume-threshold resume-coefficient-value resume-power-value ]
The thresholds for generating and clearing packet loss rate alarms are set.
Run commit
The configuration is committed.

Configuring a Bandwidth Mode for an Interface

Different bandwidth modes can be configured for device interfaces.

Context

This configuration applies only to the NetEngine 8000 M4.

Figure 1-653 shows interface layout on a device panel.

The interfaces are arranged into four groups: (0, 4, 6, 8, 10), (1, 5, 7, 9, 11), (2, 12, 14, 16, 18), and (3, 13, 15, 17, 19). Each group shares 100 Gbit/s bandwidth.
Each of interfaces 20 to 35 exclusively occupies 25 Gbit/s bandwidth.

Figure 1-653 Interface layout on a device panel
Click to enlarge

Bandwidth modes supported on interfaces 0 to 19

The bandwidth mode of interfaces 0 to 19 can be switched. The following table uses the group (0, 4, 6, 8, 10) as an example to show the supported bandwidth modes.

Table 1-342 Bandwidth modes supported on interfaces 0 to 19

Bandwidth Mode	Whether Controlled by a License	Whether a Breakout Fiber or Breakout Box Is Required
1100GE-4GE mode (default mode). That is, interface 0 has 100 Gbit/s bandwidth, and interfaces 4, 6, 8, and 10 each have 1 Gbit/s bandwidth.	100GE/4*25GE interfaces are under license control, but 1GE interfaces are not.	No
425GE-4GE mode. That is, interface 0 is split into four 25GE interfaces (25GE0/5/0:0, 25GE0/5/0:1, 25GE0/5/0:2, and 25GE0/5/0:3), and interfaces 4, 6, 8, and 10 each have 1 Gbit/s bandwidth.		Yes
410GE-410GE mode. That is, interface 0 is split into four 10GE interfaces (GigabitEthernet0/5/0:0, GigabitEthernet0/5/0:1, GigabitEthernet0/5/0:2, and GigabitEthernet0/5/0:3), and interfaces 4, 6, 8, and 10 each have 10 Gbit/s bandwidth.	Yes. The license needs to be activated on interfaces 0 and 4.	Yes
140GE-410GE mode. That is, interface 0 has 40 Gbit/s bandwidth, and interfaces 4, 6, 8, and 10 each have 10 Gbit/s bandwidth.		No
150GE-410GE mode. That is, interface 0 has 50 Gbit/s bandwidth, and interfaces 4, 6, 8, and 10 each have 10 Gbit/s bandwidth.	Yes. The license needs to be activated on interfaces 0 and 4.	No
null-4*25GE mode. That is, interface 0 does not exist, and interfaces 4, 6, 8, and 10 each have 25 Gbit/s bandwidth.	Yes. The license needs to be activated on interface 4.	No

Bandwidth modes supported on interfaces 20 to 35

Interfaces 20 to 35 work in 25GE mode by default. If the license is not activated, the default bandwidth is 100 Mbit/s. If the license is activated, the default bandwidth is 25 Gbit/s. You can configure the interfaces to work in 10GE mode. In this case, the bandwidth is not controlled by the license.

Procedure

Run system-view
The system view is displayed.
Run license
The license view is displayed.
Run active port-basic slot slot-id card card-id port port-list
The interface-specific basic hardware license is activated.

To deactivate an interface-specific basic hardware license, run the undo active port-basic slot slot-id card card-id [ port port-list ] command in the license view. After the preceding command configuration is committed, the corresponding license resource is released.

When configuring the bandwidth mode for interfaces 0 to 19, configure interface splitting on interfaces 0 to 3, and activate the license on interfaces 0 to 3, 4, 5, 12, and 13.
Run port split dimension interface { { interface-name1 interface-type interface-number1 } [ to { interface-name2 interface-type interface-number2 } ] } &<1–12> split-type split-type
A bandwidth mode is configured for specified interfaces.
Run commit
The configuration is committed.

Configuring the Working Mode of an Optical Module

By configuring the working mode of the optical module on an interface, you can switch the bandwidth mode of the interface.

Context

To switch the bandwidth mode of an interface, configure the working mode of the interface's optical module. This not only makes networking more flexible, but also reduces purchase costs. If this configuration is performed for an optical module whose working mode cannot be switched, an error message is displayed, indicating that the configuration cannot be delivered.

Procedure

Run system-view
The system view is displayed.
Run optical-module interface { interface-name | interface-type interface-number } client-mode { zr-dwdm | zr-single | zr-plus }
The working mode of the optical module on an interface is configured.
Run commit
The configuration is committed.

(Optional) Configuring an Interface Splitting Mode

By configuring an interface splitting mode, you can switch the bandwidth mode of the split interface.

Context

To switch an interface bandwidth mode, configure an interface splitting mode, which increases the networking flexibility and saves interface costs.

In VS mode, this configuration process is supported only by the admin VS.

Procedure

Run system-view
The system view is displayed.
Run port split dimension interface { { ifName1 | ifType ifNum1 } [ to { ifName2 | ifType ifNum2 } ] } &<1–32> split-type splitType
Interface splitting is configured.
Run commit
The configuration is committed.

Verifying the Configuration

After the configurations are complete, check the status of the interface, statistics on the interface, and the control-flap operation.

Procedure

Run the display interface [ interface-type interface-number ] command to check the status of the interface and statistics on the interface.
Run the display control-flap interface interface-type interface-number command to check the configuration and running status of the control-flap function on interfaces.
Run the display counters [ bit ] [ inbound | outbound ] [ interface interface-type [ interface-number ] ] [ slot slot-id ] command to check the interface traffic statistics.
Run the display counters [ bit ] rate [ inbound | outbound ] [ interface interface-type [ interface-number | slot slot-id ] | slot slot-id ] command to check the interface traffic rates.
Run the display port split or display port split slot command to check the splitting status of the interface.
Run the display interface neighbor [ interface-type interface-number | slot slot-id [ card card-number ] ] command to check information about the neighboring devices and interfaces of a physical interface on the device.
Run the display interface description [ interface-type [ interface-number ] | slot slot-id [ card card-number ] ][ full-name ] command to check the interface description.

Configuring the Physical Link Detection Function

The physical link detection function helps reduce the number of alarms generated on links and avoid system performance degradation caused by plenty of alarms that would be otherwise generated.

Usage Scenario

When plenty of alarms are generated on links, system performance deteriorates because the system has to process the huge number of alarms. You can set thresholds for different types of alarms, so that alarms are generated only when the alarm thresholds are reached. In addition, measures can be taken when necessary to remove faults and guarantee the transmission of normal traffic.

Pre-configuration Tasks

Before configuring physical link detection, complete the following tasks:

Powering on the router, ensuring that the router works properly and completes self-check successfully.
Configure physical attributes for interfaces on the router.

Configuring the Alarm Function for CRC Errors, SDH Errors, Input Errors, Output Errors, or Optical Module Power Exceptions

This section describes how to configure the alarm function for CRC errors, SDH errors, input errors, output errors, or optical module power exceptions.

Context

If the alarm function for CRC errors, SDH errors, input errors, output errors, or optical module power exceptions is enabled on an interface, the system generates an alarm when the number of errors or exceptions exceeds or falls below the threshold set on the interface. If a large number of alarms are generated on links, the system will be busy processing them, which causes performance deterioration. To prevent this problem, properly configure the type of interface alarm, alarm thresholds, and detection interval.

Procedure

Run system-view
The system view is displayed.
Run snmp-agent trap enable port { crcexc-error | input-error | output-error | sdh-error-rising | optical-module-abnormal }
The alarm function is enabled on interfaces.

The configuration takes effect on all physical interfaces supporting the alarm function.

You can set a type of alarm as required.
- crcexc-error: Enables the alarm function for CRC errors.
- sdh-error-rising: Enables the alarm function for SDH errors.
- optical-module-abnormal: Enables the alarm function for optical module power exceptions.
In VS mode, this command is supported only by the admin VS.
Run interface interface-type interface-number
The interface view is displayed.
Configure alarm thresholds and a detection interval.
- Configure alarm thresholds for inbound and outbound bandwidth usage:
  - Run trap-threshold { input-rate | output-rate } bandwidth-in-use [ resume-rate resume-threshold ]
    
    The inbound and outbound bandwidth usage threshold is set.
    
    To prevent alarms from being generated frequently, keep a large difference between bandwidth-in-use and resume-threshold.
  - Run set flow-stat interval interval
    
    The traffic statistic collection interval is set for the interface, in seconds.
    
    The new interval takes effect after the original interval expires. If the interface is logical, traffic statistics about the interface are updated when the new interval takes effect for the second time. If the interface is physical, traffic statistics about the interface are updated immediately after the new interval takes effect.
    
    The traffic statistic collection interval set on an interface is effective only on the interface.
    
    You can configure a global traffic statistic collection interval, which takes effect on all interfaces, including the interfaces on which no traffic statistic collection interval has been set. To configure a global traffic statistic collection interval, run the set flow-stat interval interval command in the system view. The traffic statistic collection interval of an interface takes preference over a global traffic statistic collection interval.
- Configure CRC alarm thresholds and a detection interval (for Ethernet interfaces and POS interfaces using either of the following methods):
  - Run trap-threshold crc-error threshold interval-second interval
    
    An alarm threshold and a detection interval are set for CRC errors.
  - Run trap-threshold crc-error high-threshold high-threshold low-threshold low-threshold interval-second interval [ shutdown ]
    
    The upper and lower alarm thresholds for CRC errors as well as the detection interval are set.
    
    You can run the trap-threshold slot slot-id card card-id crc-error high-threshold high-threshold low-threshold low-threshold interval-second interval command in the system view to configure global values for all interfaces on the specified subcard.
- Configure CRC alarm thresholds and a detection interval (for Serial interfaces and Trunk-Serial interfaces using either of the following methods):
  - Run trap-threshold crc-error threshold interval-second interval [ shutdown ]
    
    An alarm threshold and a detection interval are set for CRC errors.
  - Run trap-threshold crc-error high-threshold high-threshold low-threshold low-threshold interval-second interval [ shutdown ]
    
    The upper and lower alarm thresholds for CRC errors as well as the detection interval are set.
- Configure SDH alarm thresholds and a detection interval (for 10GE WAN interfaces and POS interfaces using either of the following methods):
  - Run trap-threshold sdh-error threshold interval-second interval
    
    An alarm threshold and a detection interval are set for SDH errors.
  - Run trap-threshold sdh-error high-threshold high-threshold low-threshold low-threshold interval-second interval
    
    The upper and lower alarm thresholds for SDH errors as well as the detection interval are set.
    
    You can run the trap-threshold slot slot-id card card-id sdh-error high-threshold high-threshold low-threshold low-threshold interval-second interval command in the system view to configure global values for all interfaces on the specified subcard.
- Configure SDH alarm thresholds and a detection interval (for POS interfaces using either of the following methods):
  - Run trap-threshold sdh-error threshold interval-second interval
    
    An alarm threshold and a detection interval are set for SDH errors.
  - Run trap-threshold sdh-error high-threshold high-threshold low-threshold low-threshold interval-second interval
    
    The upper and lower alarm thresholds for SDH errors as well as the detection interval are set.
- Configure symbol alarm thresholds and a detection interval (for Ethernet interfaces only).
  - Run trap-threshold symbol-error high-threshold high-threshold low-threshold low-threshold interval-second interval
    
    The upper and lower alarm thresholds for symbol errors as well as the detection interval are set.
    
    You can run the trap-threshold slot slot-id card card-id symbol-error high-threshold high-threshold low-threshold low-threshold interval-second interval command in the system view to configure global values for all interfaces on the specified subcard.
- Configure input/output alarm thresholds and a detection interval (for Ethernet interfaces and POS interfaces).
  - Run trap-threshold { input-error | output-error } high-threshold high-threshold low-threshold low-threshold interval-second interval
    
    The upper and lower alarm thresholds for interface input or output errors are set.
    
    You can run the trap-threshold slot slot-id card card-id { input-error | output-error } high-threshold high-threshold low-threshold low-threshold interval-second interval command in the system view to configure global values for all interfaces on the specified subcard.
- Configure an alarm threshold and a clear alarm threshold for the CRC error packet ratio:
  - Run trap-threshold crc-error packet-error-ratio alarm-threshold alarm-coefficient-value alarm-power-value [ resume-threshold resume-coefficient-value resume-power-value ] [ trigger-lsp | trigger-section ]
    An alarm threshold and a clear alarm threshold are configured for the CRC error packet ratio.
- Configure parameters for the algorithm to calculate the CRC packet error ratio:
  - Run crc-error packet-error-ratio algorithm-parameter sample-window-factor child-window-max-number child-window-alarm-number child-window-resume-number
    
    Parameters are configured for the algorithm to calculate the CRC packet error ratio.
  - Run crc-error packet-error-ratio algorithm-parameter realtime-factor template-number
    
    A template number is specified for factors affecting the algorithm used to calculate the CRC packet error ratio on the interface.
- Configure CRC alarm threshold in percentages:
  - Run trap-threshold crc-error percent percent-value
    The CRC alarm threshold in percentages is set.
(Optional) Run port-alarm down { crc-error | sdh-error | symbol-error | input-error | output-error }
An interface is configured to go Down upon receiving the alarms.
- You can run the port-alarm down slot slot-id card card-id { crc-error | sdh-error | symbol-error | input-error | output-error } command in the system view to apply the configurations to all interfaces on the subcard.
- After the association function is enabled, you can run the port-alarm clear { crc-error | sdh-error | symbol-error | input-error | output-error } command to clear the alarms on the interface.
Run commit
The configuration is committed.

Configuring the Alarm Function for Pause-Frame Errors Received on an Interface

This section describes how to configure the alarm function for pause-frame errors received on an interface.

Context

A device generates an alarm and sends it to an NMS only when the number of pause-frame error packets sent or received by the device reaches the upper threshold for three consecutive detection intervals. The device sends a clear alarm to the NMS only when the number of pause-frame error packets sent or received by the device falls below the lower threshold for three consecutive detection intervals.

Procedure

Run system-view
The system view is displayed.
Run interface interface-type interface-number
The view of an interface is displayed.
Run trap-threshold pause-frame high-threshold high-threshold low-threshold low-threshold interval-second interval
The upper threshold, lower threshold, and detection interval for the pause-frame error alarm are set.
Run commit
The configuration is committed.

Configuring the Alarm Function in Case the Number of SDH B1 or SDH B2 Error Packets That an Interface Receives Exceeds an Alarm Threshold

You can configure the alarm function in case the number of SDH B1 or SDH B2 error packets exceeds an alarm threshold. If such an alarm is generated, the link is in a poor condition.

Context

If an interface receives a large number of SDH B1 or SDH B2 error packets, the link is in a poor condition, affecting service transmission. In this situation, you can configure the alarm function, alarm threshold, and detection interval on an interface. The system then detects the number of SDH B1 or SDH B2 error packets that the interface receives at the configured interval. If the number of SDH B1 or SDH B2 error packets exceeds the configured alarm threshold, the system generates an alarm and sends it to the NMS, prompting the administrator to perform maintenance on the interface and troubleshoot the fault. When the number of SDH B1 or SDH B2 error packets falls below the alarm threshold, the system generates a clear alarm and sends it to the NMS, notifying the administrator that the alarm has been cleared.

Procedure

Run system-view
The system view is displayed.
Run interface interface-type interface-number
The interface view is displayed.
Run trap-threshold { sdh-b1-error | sdh-b2-error } threshold interval-second interval
A threshold and detection interval for the SDH B1 or SDH B2 error alarm on an interface are set.
Run commit
The configuration is committed.

Configuring the Alarm Function in Case the Number of Bytes of Error Packets That an Interface Receives Exceeds an Alarm Threshold

You can configure the alarm function in case the number of bytes of error packets exceeds a threshold. If such an alarm is generated, the link is in a poor condition.

Context

If an interface receives a large number of bytes of error packets, the link is in a poor condition, affecting service transmission. In this situation, you can configure the alarm function, alarm threshold, and detection interval on an interface. The system then detects the number of bytes of error packets that the interface receives at the configured interval. If the number of bytes of error packets exceeds the configured alarm threshold, the system generates an alarm and sends it to the NMS, prompting the administrator to perform maintenance on the interface and troubleshoot the fault. When the number of bytes of error packets falls below the alarm threshold, the system generates a clear alarm and sends it to the NMS, notifying the administrator that the alarm has been cleared.

Procedure

Run system-view
The system view is displayed.
Run snmp-agent trap enable port bad-bytes
The alarm function is configured in case the number of bytes of error packets exceeds an alarm threshold.
Run interface interface-type interface-number
The interface view is displayed.
Run trap-threshold bad-bytes trap-threshold interval-second interval
An alarm threshold is configured for the number of bytes of error packets that the interface receives, and an interval is configured for the system to detect the number of bytes of error packets.
Run commit
The configuration is committed.

Verifying the Configuration

You can check the interface configuration and state information after configuring the physical link detection function.

Context

The physical link detection function has been configured.

Procedure

Run the display trap-info command in the interface view or run the display trap-info { interface-type interface-number | interface-name | slot slot-id card card-id } command in the system view to check alarm configurations on the specified interface, including the alarm function status, alarm thresholds, detection interval, alarm blocking status, current alarm state, and the number of current alarms.
Run the display port-error-info interface { interface-type interface-number | interface-name } command in the interface view to check the trap information about error codes/error packets of an interface.

Configuring MAC Accounting

If the MAC accounting function is enabled on an interface of a device, the device collects IPv4 or IPv6 traffic statistics corresponding to MAC addresses learned by the interface.

Usage Scenario

Figure 1-654 MAC accounting usage scenario

MAC accounting can be used in either of the following scenarios:

When a Huawei device on an ISP network functions as an Internet exchange point (IXP), the networks connected to the IXP are provided by other carriers. When the ISP leases the other carriers' networks, for example, Network1 and Network2, they charge the ISP by traffic volume. To check traffic of MAC addresses, run the mac accounting enable command to enable the MAC accounting function on the IXP's interface, so that traffic of the peer routers can be obtained. This facilitates the ISP to verify or analyze traffic.
If the IXP is under DDoS attacks, the MAC accounting function helps the ISP to check the traffic of peer routers with specified MAC addresses. If traffic of a specified MAC address is huge, the attack traffic may be from this device with the specified MAC address.

Procedure

Run system-view
The system view is displayed.
Run interface interface-type interface-number
The user interface view is displayed.
Run mac accounting enable
MAC accounting is enabled.
Run commit
The configuration is committed.

Verifying the Configuration

After MAC accounting is enabled, run the display mac accounting command to check MAC accounting statistics on the interface or its sub-interfaces.

If you need to re-check MAC accounting statistics after a period, run the reset mac accounting command to delete the existing statistics and then run the display mac accounting command. This ensures statistics accuracy.

Configuring Strict Filter for EVC Sub-Interfaces

This section describes how to configure strict filter for EVC sub-interfaces.

Usage Scenario

On a BD scenario, the router has two sub-interfaces configured in a main interface, one with the Dot1q encapsulation type and the other with the default encapsulation type. Once the sub-interface encapsulated Dot1q receives traffic, the sub-interface with the default encapsulation type also sends out the traffic. This may cause the illusion of return current. Besides, the router has two interfaces configured on a BD scenario. The first interface has a sub-interface that is configured with the Dot1q encapsulation type. The second interface has two sub-interfaces that are configured with the Dot1q and default encapsulation types respectively. Once traffic passes through the sub-interface on the first interface, the second interface also sends two copied traffic from each of its sub-interfaces. This causes traffic to be replicated, wasting resources and reducing the board's forwarding efficiency. To allow traffic to be sent through specific interfaces, enable strict filter.

Pre-configuration Tasks

Before configuring strict filter on an interface, configure physical attributes for interfaces on the router.

Procedure

Enable strict filter globally.
1. Run system-view
  The system view is displayed.
2. Run ethernet egress-strict-filter enable
  Strict filter is enabled globally.
3. Run commit
  The configuration is committed.
Enable strict filter on an EVC sub-interface.
1. Run system-view
  The system view is displayed.
2. Run interface interface-type interface-number.sub-interface-number mode l2
  The EVC sub-interface view is displayed.
3. Run ethernet egress-strict-filter enable
  Strict filter is enabled for the EVC sub-interface.
4. Run commit
  The configuration is committed.
  
  The strict filter configuration on an EVC sub-interface takes precedence over that configured in the system view. The strict filter configuration on an EVC sub-interface takes effect, regardless of whether strict filter is configured globally.

Enabling the Signal Sending Delay Function

This section describes how to configure the signal sending delay function.

Usage Scenario

After a device is restarted or a board is replaced, if an interface sends signals immediately after initialization before the link completes a switchover or configuration restoration, data loss may occur. To prevent data loss, configure the signal sending delay function.

Only physical interfaces can be configured with signal sending delays. Logical interfaces do not support this function.
Configuring a signal sending delay does not affect an interface that has sent signals to the peer, and the configuration takes effect after the interface is initialized.

Procedure

Run system-view
The system view is displayed.
Run interface interface-type interface-number or controller interface-type interface-number
The corresponding interface view is displayed.
Run port-tx-enabling-delay port-tx-delay-time
The signal sending delay function is enabled, and the signal sending delay is configured.
Run commit
The configuration is committed.

Verifying the Configuration

After the configuration is complete, run the display port-tx-enabling-delay command to check information about the signal sending delay on an interface.

Configuring an Interval for Updating Interface Statistics in the Cache

By configuring an interval for updating interface statistics in the cache, you can ensure that the cache holds the latest statistics.

Usage Scenario

An NMS can obtain interface statistics in get-next or get mode. In get-next mode, a device receives a request for interface statistics from the NMS, obtains the interface statistics from the cache, and then reports the statistics to the NMS. By default, the interval for updating statistics in the cache is 50 seconds.

When obtaining statistics on packets received or sent on an interface through the ifTable and ifXTable objects in the MIB table, you can reduce the interval for updating interface statistics in the cache to ensure that the cache holds the latest statistics.

Procedure

Run system-view
The system view is displayed.
Run snmp-agent
The SNMP agent is enabled.
Run snmp-agent get-next-cache if-mib age-time time-value
An interval for updating interface statistics in the cache is configured in scenarios where an NMS obtains the statistics in get-next mode.
Run commit
The configuration is committed.

Configuring a Trap Threshold for Sudden Changes in the Traffic Rate on Global Interfaces

You can configure a trap threshold for sudden changes in the traffic rate to adjust the frequency of triggering traps.

Usage Scenario

To detect sudden changes in the traffic rate, you can configure a trap threshold for them on interfaces. After the configuration is complete, the device reports a trap if the percentage of change in the traffic rate exceeds the trap threshold. To prevent the device from frequently reporting traps, do not set the trap threshold too low.

The formula for calculating the percentage of change in the traffic rate on interfaces is as follows:

Percentage of change in the traffic rate = Difference between the interface rates in the current and previous traffic statistics collection intervals/Interface rate in the previous traffic statistics collection interval

To configure a traffic statistics collection interval on an interface, run the set flow-stat interval command. The default interval is 300 seconds.

Procedure

Run system-view
The system view is displayed.
Run set flow-change-ratio { input-threshold | output-threshold } upper-limit threshold
A trap threshold is configured for sudden changes in the traffic rate on interfaces.

After this command is run, if you enable the trap function for sudden changes in the traffic rate (configured using the snmp-agent trap enable feature-name port trap-name hwinputratechangeoverthresholdnotice or snmp-agent trap enable feature-name port trap-name hwoutputratechangeoverthresholdnotice command) and the percentage of change in the traffic rate exceeds the configured trap threshold, the following traps are generated:
- PORT_1.3.6.1.4.1.2011.5.25.157.2.219 hwInputRateChangeOverThresholdNotice
- PORT_1.3.6.1.4.1.2011.5.25.157.2.220 hwOutputRateChangeOverThresholdNotice
Run commit
The configuration is committed.

Enabling or Disabling the Optical Module Laser

This section describes how to enable or disable the optical module laser.

Usage Scenario

Before locating or troubleshooting a link failure, maintenance engineers should ensure that the optical module laser is disabled so that it cannot cause injury. The optical module can be configured to disable the laser automatically if it detects a link failure. The laser can also be disabled manually. If the optical module is configured to disable the laser automatically, the laser is not immediately re-enabled when the link failure is cleared. However, maintenance engineers can enable the optical module laser manually to check whether services have recovered.

Pre-configuration Tasks

Before enabling or disabling the optical module laser, complete the following tasks:

Power on the router.
Ensure that the optical module has been installed and that the interface is Up.

Disabling the Optical Module Laser

Disabling the optical module laser before troubleshooting a link failure protects maintenance engineers from the laser.

Context

Procedure

Run system-view
The system view is displayed.
Run interface interface-type interface-number or controller interface-type interface-number
The corresponding interface view is displayed.
Perform either of the following operations:
- Configure the optical module to disable the laser automatically.
  1. To configure the optical module to disable the laser automatically, run the laser autoshutdown enable command.
  2. (Optional) To configure intervals at which the optical module laser is disabled or enabled and the system checks for link failures, run the laser auto-shutdown-interval { open opentime-interval | close closetime-interval } command.
- Disable the optical module laser manually.
  
  To disable the optical module laser manually, run the laser turn-off command.
  
  Running the laser turn-off command interrupts services on the interface. Therefore, do not run the command when the interface is working properly.
Run commit
The configuration is committed.

(Optional) Enabling the Optical Module Laser

After enabling the optical module laser, you can check whether the link failure is cleared.

Context

If the optical module is configured to disable the laser automatically, the laser is not immediately re-enabled when the link failure is cleared. However, maintenance engineers can enable the optical module laser manually to check whether services have recovered.

Procedure

Run system-view
The system view is displayed.
Run interface interface-type interface-number or controller interface-type interface-number
The corresponding interface view is displayed.
Run laser turn-on [ duration duration ]
The optical module laser is enabled, and the duration for which the optical module laser will be temporarily enabled is configured.

The duration takes effect only after the laser autoshutdown enable command is run.
Run commit
The configuration is committed.

Verifying the Configuration of Enabling or Disabling the Optical Module Laser

After enabling or disabling the optical module laser, check its status.

Prerequisites

The optical module laser has been enabled or disabled as required.

Context

The following operations affect the status of the optical module laser:

Run the laser turn-on command to enable the optical module laser.
Run the laser turn-off command to disable the optical module laser.
Run the laser autoshutdown enable command to configure the optical module to disable the laser automatically if it detects a link failure.
Run the shutdown command to deactivate the interface.

Procedure

Run the display laser status command in any view to check the laser status of the optical module.

Configuring the Optical Module Mode of an Interface

Context

To switch the optical module mode of an interface, perform this configuration.

Only the NetEngine 8100 M14/M8 series, NetEngine 8000E M14/M8 series, and NetEngine 8000 M14/M8/M4 series support this function.

Procedure

Run system-view
The system view is displayed.
Run interface interface-type interface-number
The interface view is displayed.
Run optical-mode { osnr | hsen }
The optical module is configured to work in SNR mode or high-sensitivity mode.
Run commit
The configuration is committed.

Enabling the Optical Module Alarm Threshold Standardization Function

You can enable the alarm standardization function for an optical module to prevent the optical module from reporting alarms when its optical power exceeds the threshold.

Context

The system automatically obtains the vendor-defined power threshold of an optical module and compares it with the actual power. If the actual power exceeds the vendor-defined threshold, an alarm will be generated. However, the vendor-defined power threshold of an optical module may not meet user requirements. If the alarm standardization function is enabled, a unified power threshold is used, and the threshold is calculated based on the optical module transmission distance and bandwidth.

The device has two types of optical module power alarms: warning and alarm. A warning is reported when the difference between the actual power and vendor-defined threshold is not great. It can also be considered as a precaution. Some optical modules can continue working properly when the actual optical power is at the warning level. You can disable warning detection as required.

Procedure

Run system-view
The system view is displayed.
Run optical-module alarm-threshold standardization enable
The alarm threshold standardization function is enabled for the optical module.
Run commit
The configuration is committed.

Disabling the Optical Module Alarm Function

You can disable the alarm function for an optical module to prevent the optical module from reporting alarms when its optical power exceeds the threshold.

Context

The system automatically obtains the vendor-defined power threshold of an optical module and compares it with the actual power. If the actual power exceeds the vendor-defined threshold, an alarm will be generated. Generally, the actual power is greater than the vendor-defined threshold, which means frequent alarm reporting. It is unfeasible to install an attenuator on each optical module to prevent frequent reporting of such power alarms. You can disable the alarm function for the optical module by executing the following command.

Procedure

Run system-view
The system view is displayed.
Run interface interface-type interface-number
The interface view is displayed.
Run port-alarm disable optical-module { rx-power-high-warning | rx-power-low-warning | tx-power-high-warning | tx-power-low-warning | voltage-high-warning | voltage-low-warning } ^*
The alarm function is disabled for the optical module.
Run commit
The configuration is committed.

Managing Non-Huawei-Certified Optical Modules

To manage non-Huawei-certified optical modules, you can suppress the alarms for non-Huawei-certified optical modules and enable the function of setting interfaces with the optical modules inserted to Down.

Context

When an interface is inserted with a non-Huawei-certified optical module, the system automatically reports an alarm. If you want to suppress the alarm, you can disable the function of reporting the alarm for the non-Huawei-certified optical module. If you do not want to use the interface with the optical module inserted, you can enable the function of setting the interface to Down.

Procedure

Run system-view
The system view is displayed.
Run transceiver non-certified-alarm disable
The function of reporting an alarm for a non-Huawei-certified optical module is disabled.
Run transceiver non-certified-alarm port-down enable
The function of setting an interface with a non-Huawei-certified optical module inserted to Down is enabled.
Run commit
The configuration is committed.

Configuring SerDes Polarity Inversion

Context

If a 100GE 80 km optical module of a Huawei device cannot connect to that of a non-Huawei device, configure SerDes polarity inversion. This configuration will trigger SerDes polarity inversion on an interface, causing service interruptions. Therefore, exercise caution when configuring SerDes polarity inversion.

Procedure

Run system-view
The system view is displayed.
Run interface interface-type interface-number
The interface view is displayed.
Run optical pn-reverse enable
SerDes polarity inversion is configured so that a 100GE 80 km optical module on the device can connect to that of a non-Huawei device.
Run commit
The configuration is committed.

Configuring the Control-Flap Function

This section describes how to configure the control-flap function.

Usage Scenario

The flapping of routing protocols, MPLS, and other protocols caused by the frequent change of the interface status may influence the stability of the whole network. To resolve this problem, you can configure the control-flap function.

The function controls the frequency of interface status alternations between up and down, which minimizes the impact on device and network stability.

For related concepts and fundamentals, see Interface Flapping Control.

Pre-configuration Tasks

Before configuring the control-flap function, configure the physical attributes for the router interfaces.

Procedure

Configure the control-flap function.
1. Run system-view
  The system view is displayed.
2. Run interface interface-type interface-number
  The interface view is displayed.
  
  The null interface and loopback interface do not support the control-flap function.
3. Run control-flap [ suppress reuse ceiling decay-ok decay-ng ]
  The control-flap function is enabled on the interface.
  
  The value of suppress is 1000 times the suppress threshold of the interface. It ranges from 1 to 20000. The default value is 2000. The value of suppress must be greater than the value of reuse and smaller than the value of ceiling.
  
  The value of reuse is 1000 times the reuse threshold of the interface. It ranges from 1 to 20000. The default value is 750. The value of reuse must be smaller than the value of suppress.
  
  The value of ceiling is 1000 times the suppress penalty value of the interface. It ranges from 1001 to 20000. The default value is 6000. The value of ceiling must be greater than the value of suppress.
  
  The value of decay-ok is the time taken to decay the penalty value to half when the interface is Up. It ranges from 1 to 900 seconds. The default value is 54 seconds.
  
  The value of decay-ng is the time taken to decay the penalty value to half when the interface is Down. It ranges from 1 to 900 seconds. The default value is 54 seconds.
4. Run commit
  The configuration is committed.
Configure status flapping suppression on a physical interface.
1. Run system-view
  The system view is displayed.
2. (Optional) Run interface interface-type interface-number
  The view of an interface is displayed.
3. Run damp-interface enable
  Status flapping suppression is enabled on the interface.
4. (Optional) Run damp-interface level { light | middle | heavy | manual { half-life-period suppress reuse max-suppress-time } }
  A suppression level is configured for status flapping suppression.
  - light: If light suppression is configured, the system triggers suppression only when an interface's status flaps frequently and rapidly. The light suppression level is the default setting and applies to flappings that have the maximum impact on the system.
  - heavy: If heavy suppression is configured, the system triggers suppression when detecting an interface's status begins to flap, even if the flapping is not severe. At the heavy suppression level, an interface is prone to be suppressed. This level applies to services that are sensitive to flappings. Enabling heavy suppression prevents service interruptions or resource waste caused by interface flappings.
  - middle: Intensity of middle suppression is between the light and heavy levels.
  - manual: If light, middle, or heavy suppression cannot meet your requirement, you can specify manual.
5. (Optional) Run damp-interface mode tx-off
  The interface is disabled from sending signals if it is under status flapping suppression.
  
  If an interface is under status flapping suppression, the interface can be disabled from sending signals, so that the remote interface can detect that the local interface is unavailable.
  
  If the local interface is disabled from sending signals, the remote interface considers it Down.
  
  If status flapping suppression on the local interface is canceled, this interface automatically begins to send signals to the remote interface. The remote interface then considers this interface Up.
6. Run commit
  The configuration is committed.

Checking the Configuration

Run the display control-flap interface interface-type interface-number command to check the previous configuration.

Run the display damp-interface [ interface interface-type interface-number ] command to check the status and statistics about status flapping suppression on the interface.

Logical Interface Configuration

This section describes how to configure logical interfaces. Logical interfaces are manually configured interfaces, which are used to exchange data. Logical interfaces do not exist physically.

Usage Scenario

For usage scenarios of logical interfaces, see "Logical Interface" in NetEngine 8100 M, NetEngine 8000E M, NetEngine 8000 M-Feature Description-Interface Management.

Table 1-343 Logical interface list

Feature	Interface Name	Configuration Guide
System management	DCN serial interface	This interface is automatically created by the system.
Interface management	Virtual Ethernet (VE) interface	Creating an L2VE Interface Creating an L3VE Interface
Interface management	Global VE interface	Creating a Global VE Interface
Interface management	Loopback interface	Creating a Loopback Interface and Configuring Its IP Address
Interface management	Null0 interface	Entering the NULL Interface View
LAN access and MAN access	Ethernet sub-interface	Configuring Ethernet Sub-interfaces to Support Communication Between VLANs
LAN access and MAN access	Eth-Trunk interface	Eth-Trunk Interface Configuration
LAN access and MAN access	VLANIF interface	Configuring Layer 3 Communication Between VLANIF Interfaces
WAN access	IP-Trunk interface NOTE: This interface is not supported on the NetEngine 8000 M8K or NetEngine 8000 M14K.	Configuring an IP-Trunk Interface
WAN access	CPOS-Trunk interface	Creating a CPOS-Trunk Interface
WAN access	MP-group interface	Configuring MP
WAN access	Global MP-group interface	Creating a Global-MP-Group and Adding a Trunk Serial Interface to It
WAN access	IMA-group interface	ATM IMA Configuration
WAN access	Global IMA-group interface	Creating a Global-IMA-Group and Adding a Trunk Serial Interface to It
MPLS	Tunnel interface	MPLS TE Configuration

Pre-configuration Tasks

Before configuring logical interfaces, connect interfaces and set their physical parameters to ensure that these interfaces are physically up.

Creating a Global VE Interface

Global VE interfaces are independent of boards. You can create global VE interfaces only if the router is powered on.

Procedure

Run system-view
The system view is displayed.
Run interface global-ve ve-number
A global VE interface is created and its view is displayed.
Run commit
The configuration is committed.

Configuring a Channelized Sub-interface

This section describes how to configure a channelized sub-interface.

Context

To prevent services from affecting each other, a mechanism to isolate different types of services is needed. Different service flows are forwarded through different VLAN channelized sub-interfaces with dot1q encapsulation, and each channelized sub-interface implements independent HQoS scheduling to isolate services of different types.

Procedure

Run system-view
The system view is displayed.
Run interface interface-type interface-number.subinterface-number
The view of a physical sub-interface is displayed.
Configure the sub-interface as required.
- If the sub-interface is an Ethernet one:
  - Run the vlan-type dot1q vlanid command to set the encapsulation mode of the sub-interface to dot1q.
  - Run the encapsulation qinq-termination and qinq termination pe-vid pe-vlanid ce-vid ce-vlanid commands to set the encapsulation mode of the sub-interface to QinQ termination.
- If the sub-interface is a POS one, run the fr dlci dlci-value command to set its encapsulation mode to POS FR. This command depends on the link-protocol fr command configuration on the POS main interface.
Run quit
Return to the system view.
Run license
The license view is displayed.

The channelized sub-interface license does not need to be activated on GE interfaces.
Run active port-slicing slot slotid card cardid port port-list
The license for channelized sub-interfaces is activated.
Run quit
Return to the system view.
Run interface interface-type interface-number.subinterface-number
The view of a physical sub-interface is displayed.
Run mode channel enable
Channelization is enabled for the sub-interface.
(Optional) Run mode channel bandwidth bwvalue
The bandwidth is configured for the channelized sub-interface.
Run commit
The configuration is committed.

Creating a Loopback Interface and Configuring an IP Address for It

IP addresses need to be configured for loopback interfaces that are always up so that these interfaces can be used to communicate with other devices.

Procedure

Run system-view
The system view is displayed.
Run interface loopback loopback-number
A loopback interface is created.

You can create or delete loopback interfaces as required. Once a loopback interface is created, it remains up all the time unless it monitors an interface monitoring group and may go down.
Run ip address ip-address { mask | mask-length }
The IP address of the loopback interface is configured.
Run commit
The configuration is committed.

Entering the NULL Interface View

The system automatically creates a NULL0 interface. The NULL interface is used for preventing routing loops and filtering traffic.

Procedure

Run system-view
The system view is displayed.
Run interface null 0
The NULL interface view is displayed.

The NULL interface is always in the Up state but does not forward any data packets. In addition, IP addresses cannot be configured on the NULL interface, and data link layer protocol cannot be encapsulated on the NULL interface.

Follow-up Procedure

The NULL interface is used to prevent routing loops and filtering traffic. If the ip route-static 192.168.0.0 255.255.0.0 NULL 0 command is run, the device will discard all packets destined for the network segments 192.168.0.1 to 192.168.255.255.

Verifying the Configuration

After the configuration is completed on the Global-VE interface, FlexE interface license, FlexE interface, loopback interface, and Null interface, check the configurations.

Prerequisites

The Global-VE interface, FlexE interface license, FlexE interface, loopback interface, and NULL interface have been configured.

Procedure

Run the display interface global-ve [ ve-number ] command to check the status of the Global-VE interface.
Run the display license resource usage port-slicing { all | slot slot-id } [ active | deactive ] command to check authorization information about the port slicing license on boards.
Run the display interface loopback [ loopback-number ] command to check the status of the Loopback interface.
Run the display interface null [ 0 ] command to check the status of the Null interface.
Run the display flexe group information slot slot-id card card-id command to check information about groups, FlexE physical interfaces added to the groups, and timeslot allocation in the groups on a FlexE subcard.

FlexE Interface Configuration

FlexE interfaces refer to FlexE clients, which correspond to various externally observed user interfaces on networks. Each FlexE client can be flexibly allocated bandwidth from a group resource pool, and the bandwidth can be adjusted. In VS mode, this feature is supported only by the admin VS.

Usage Scenario

The need for higher mobile bearer bandwidth is increasing as 5G networks continue to evolve. In addition, customers want a unified network to transmit various services, such as home broadband, leased line access, and mobile bearer services. These factors place increasingly higher requirements on telecommunication network interfaces. FlexE isolates services by isolating the bandwidth resources of interfaces. FlexE interfaces are isolated from each other so that traffic is isolated at the physical layer and network slicing is performed for services on the same physical network.

FlexE applies to the access, aggregation, and core layers. As 5G services transition through the initial, development, and maturity phases, the service volume increases gradually. FlexE allows the bearer network to be smoothly upgraded.

Pre-configuration Tasks

Before configuring FlexE interfaces, complete the following tasks:

Power on the device and ensure that it passes the self-check.
Install a FlexE-capable board on the device.
Activate the FlexE interface license on the board.

Activating the FlexE Interface License on a Board

To configure FlexE services on a board, you must activate the FlexE interface license on the board first.

Pre-configuration Tasks

Before activating the FlexE interface license on a board, complete the following tasks:

Run the license active file-name command to activate a specified license file on the main control board.
Run the system-view command to enter the system view.
Run the license command to enter the license view.

Procedure

Run system-view
The system view is displayed.
Run license
The license view is displayed.
Run active port-slicing slot slotid card cardid port portlist
The FlexE interface license is activated on a specified board.
Run commit
The configuration is committed.

Configuring a Standard Ethernet Interface to Work in FlexE Mode

The bandwidth of a standard Ethernet interface is fixed. To flexibly specify the bandwidth of an interface, you need to switch its working mode from standard Ethernet to FlexE.

Context

After a standard Ethernet interface is switched to the FlexE mode, the system automatically creates a FlexE physical interface and deletes the services configured on the original interface.

Procedure

Run system-view
The system view is displayed.
Run flexe enable port posStr
The working mode of the Ethernet interface is switched from standard Ethernet to FlexE.
Run commit
The configuration is committed.

Configuring a PHY Number for a FlexE Physical Interface

To ensure normal communication between interconnected devices, you need to configure the same PHY number for the FlexE physical interfaces on both of them.

Context

Different FlexE physical interfaces can be configured with the same PHY number. However, the FlexE physical interfaces with the same PHY number cannot be added to the same FlexE group, and a FlexE physical interface can be added to only one FlexE group.

Procedure

Run system-view
The system view is displayed.
Run interface interface-type interface-number
The view of a specified FlexE physical interface (for example, FlexE-50G 0/9/1) is displayed.
Run phy-number phyNum
A PHY number is configured for the FlexE physical interface.
(Optional) Run management-channel mode { union | section | shim-to-shim | shim-to-shim-op2 }
A management channel mode is configured for the FlexE physical interface.
(Optional) Run down-filter disable
Down interrupt suppression is disabled on the FlexE physical interface.
(Optional) Run switch-mode { manual | auto }
A switching mode is configured for the FlexE physical interface.

This command can be run only on port 0 of a 2x50GE subcard.
(Optional) Run port-speed { 50GE | 100G }
A rate mode is configured for the FlexE physical interface.

This command can be run only on port 0 of a 2x50GE subcard.
Run commit
The configuration is committed.

Creating a FlexE Group and Binding a FlexE Physical Interface to It

After a FlexE group is created, you can bind a group of FlexE physical interfaces to it, flexibly allocating bandwidth to FlexE clients based on the sub-timeslot granularity.

Procedure

Run system-view
The system view is displayed.
Run flexe group group-index
A FlexE group is created and its view is displayed, or the view of a specified existing FlexE group is displayed.
(Optional) Run description text
A description is configured for the FlexE group.

To facilitate memorization and management, you can perform this step to describe a specific FlexE group.
Run binding interface interface-type interface-number
A specified FlexE physical interface is bound to the FlexE group.
(Optional) Run padding enable
Padding is enabled.
(Optional) Run timeslot-negotiation mode disable
Timeslot negotiation is disabled.
If the timeslot mode has been configured on the FlexE card where the PHYs bound to a FlexE group reside, ensure that the FlexE clients in the group are not bound to any sub-timeslots before disabling timeslot negotiation.
- If the peer device does not support timeslot negotiation, you need to disable it in the FlexE group view of the local device.
- The same timeslot negotiation mode must be configured for the FlexE groups on both ends. Otherwise, the FlexE interfaces may fail to go up or fail to forward traffic after a reliability operation (such as an active/standby switchover, subcard reset, or interface shutdown/startup) is performed.
- After timeslot negotiation is disabled for the FlexE groups on both ends, the same timeslot number must be configured for the corresponding FlexE clients. Otherwise, the FlexE interfaces may fail to go up or fail to forward traffic.
Run commit
The configuration is committed.

Configuring a Number for a FlexE Group

To ensure normal communication between interconnected devices, you need to configure the same group number for the FlexE groups to which the FlexE physical interfaces on both devices are added.

Procedure

Run system-view
The system view is displayed.
Run flexe group group-index
A FlexE group is created and its view is displayed, or the view of a specified existing FlexE group is displayed.
Run flexe-groupnum groupNum
A group number is configured for the FlexE group.
Run commit
The configuration is committed.

(Optional) Configuring a Sub-timeslot Granularity for a FlexE Card

The sub-timeslot granularity of a FlexE card restricts the bandwidth configuration of a FlexE client. By default, the sub-timeslot granularity of a FlexE card is 5 Gbit/s.

Context

To configure a bandwidth lower than 5 Gbit/s for a FlexE client, set the sub-timeslot granularity of the FlexE client to 1 Gbit/s first.

Bandwidth configuration rules for FlexE clients based on different sub-timeslot granularities are as follows:

If the sub-timeslot granularity is 5 Gbit/s (default value), the bandwidth of a FlexE client can be set to an integer multiple of 5 Gbit/s, such as 5 Gbit/s, 10 Gbit/s, or 15 Gbit/s.
If the sub-timeslot granularity is 1 Gbit/s, the bandwidth of a FlexE client can be set to 1 Gbit/s, 2 Gbit/s, 3 Gbit/s, 4 Gbit/s, or an integer multiple of 5 Gbit/s.

Procedure

Run system-view
The system view is displayed.
Run set flexe sub-time-slot granula slot slotid card cardid { 1G | 5G }
A sub-timeslot granularity is configured for a specified FlexE card.
Run commit
The configuration is committed.

(Optional) Configuring a Mode for a FlexE Card

FlexE cards support timeslot and bandwidth modes. The bandwidth mode is recommended.

Context

Timeslot mode: A timeslot number to be allocated to a FlexE client is statically specified when the client is configured.
Bandwidth mode: Only the needed bandwidth is specified when a FlexE client is configured, and the device automatically allocates the corresponding timeslot.

By default, the bandwidth mode is used for a FlexE card.

Procedure

Run system-view
The system view is displayed.
Run slot slot-id
The slot view is displayed.
Run flexe config-mode card cardid { bandwidth | timeslot }
The bandwidth or timeslot mode is configured for a specified FlexE card.

This command does not apply to the NetEngine 8000 M8, NetEngine 8000 M8K, or NetEngine 8000E M8.
Run commit
The configuration is committed.

Creating a FlexE Client and Configuring an ID and Bandwidth for It

FlexE clients correspond to externally observed user interfaces. Each FlexE client can be flexibly allocated bandwidth from a group resource pool, and the bandwidth can be adjusted.

Context

To ensure that the FlexE clients on both ends can communicate with each other, you need to configure the same ID and bandwidth for them.

Table 1-344 Numbers of physical ports that can be added to the same group and port-id value ranges for different subcard models

Model	Numbers of Physical Ports that Can Be Added to the Same Group	port-id Value Range
CR8D00E4XFC1	0	1000-3000
	1	1000-3000
	2	1000-3000
	3	1000-3000
CR8D00E1KBC0	1	0-47, 1000-3000
CR8DE1NEKB11	1	0-47, 1000-3000
CR5D0E5XMF94	0, 1	129-148, 1000-3000
CR8DE1NE2VC1	0, 1	0-47, 1000-3000
CR8D00E1NBC1	0, 1	0-47, 1000-3000
CR8D00E2VBC1	0, 1	0-47, 1000-3000
CR8D00E1NBC1 (03033YVS)	0, 1	0-47, 1000-3000
CR5DE2NE4X14 (NetEngine 8000 M14M14K)	0, 1	2-21, 1000-3000
CR5DE2NE4X14 (NetEngine 8000 M8M8K)	0	2-11, 1000-3000
CR5DE2NE4X14 (NetEngine 8000 M8M8K)	1	12-21, 1000-3000
CR8D00E2NBC1 (NetEngine 8000 M14M14K, NetEngine 8100 M14M14K)	0, 1	2-21, 1000-3000
CR8D00E2NBC1 (NetEngine 8000 M8M8K, NetEngine 8100 M8M8K)	0	2-11, 1000-3000
CR8D00E2NBC1 (NetEngine 8000 M8M8K, NetEngine 8100 M8M8K)	1	12-21, 1000-3000
CR8D00E2VBK1 (NetEngine 8000 M8KM14K)	0, 1	129-148, 1000-3000
CR8D00E1NBC1 (NetEngine 8000 M8M14, NetEngine 8100 M8M14) (03033MNV)	0, 1	129-148, 1000-3000
CR8D00E2VBC1 (NetEngine 8000 M8M14, NetEngine 8100 M8M14)	0, 1	129-148, 1000-3000
CR8D00E1NBC4 (NetEngine 8000 M8M14, NetEngine 8100 M8M14)	0	1000-3000
DPE1E4NBIYFS (NetEngine 8000 M4)	0, 2	1000-3000
DPE1E4NBIYFS (NetEngine 8000 M4)	1, 3	1000-3000
DPE1E4NBIYFS (NetEngine 8000 M4)	0, 2	1000-3000
DPE1E4NBIYFS (NetEngine 8000 M4)	1, 3	1000-3000
CR8D00E2NBC4	0, 1	2-21, 1000-3000
CR8D00E4XFC4	0	1000-3000
	1	1000-3000
	2	1000-3000
	3	1000-3000
CR8D00E1NBC2	0, 1	129-148, 1000-3000
CR8PM4BASDC2 (NetEngine 8000 M4)	0, 2	1000-3000
CR8PM4BASDC2 (NetEngine 8000 M4)	1, 3	1000-3000
CR8PM4BASDC3 (NetEngine 8000 M4)	0, 2	1000-3000
CR8PM4BASDC3 (NetEngine 8000 M4)	1, 3	1000-3000
CR8PM4BASAC2 (NetEngine 8000 M4)	0, 2	1000-3000
CR8PM4BASAC2 (NetEngine 8000 M4)	1, 3	1000-3000
CR8PM4BASAC3 (NetEngine 8000 M4)	0, 2	1000-3000
CR8PM4BASAC3 (NetEngine 8000 M4)	1, 3	1000-3000
CR8PM4BASDC6 (NetEngine 8000 M4)	0, 2	1000-3000
CR8PM4BASDC6 (NetEngine 8000 M4)	1, 3	1000-3000
CR8PM4BASDC7 (NetEngine 8000 M4)	0, 2	1000-3000
CR8PM4BASDC7 (NetEngine 8000 M4)	1, 3	1000-3000
CR8PM4BASAC6 (NetEngine 8000 M4)	0, 2	1000-3000
CR8PM4BASAC6 (NetEngine 8000 M4)	1, 3	1000-3000
CR8PM4BASAC7 (NetEngine 8000 M4)	0, 2	1000-3000
CR8PM4BASAC7 (NetEngine 8000 M4)	1, 3	1000-3000
CR8DE1N8XFM0	0	1000-3000

Procedure

Run system-view
The system view is displayed.
Run flexe client-instance clientIndex [ flexe-group groupIndex flexe-type full-function [ port-id portId ] ]
A FlexE client is created and its view is displayed.
Run flexe-clientid clientid
An ID is configured for the FlexE client.
Configure bandwidth for the FlexE client.
- If the bandwidth mode is configured for the FlexE card, run the flexe-bandwidth { 1 | 2 | 3 | 4 | bandwidth-value } command to configure bandwidth for the FlexE client.
- If the timeslot mode is configured for the FlexE card, run the binding interface interface-type interface-number time-slot timeslot-list [ sub-time-slot subtime-slot ] command to bind one or more sub-timeslots to the FlexE client. The bound sub-timeslots constitute the bandwidth of the FlexE client.
(Optional) Run minimal available bandwidth bandPercent
The minimum available bandwidth percentage is configured for the FlexE client.
Run commit
The configuration is committed.

Adding a FlexE NE in an Ethernet Service Scenario

Adding a FlexE NE to a live network running Ethernet services involves the connection between a FlexE physical interface and standard Ethernet interface. If DCN auto-negotiation is enabled on the FlexE physical interface, the two interfaces can automatically communicate with each other, and the NMS can manage the FlexE NE.

Usage Scenario

As shown in Figure 1-655, DeviceA and DeviceB on the live network work in standard Ethernet mode and do not support DCN auto-negotiation on FlexE physical interfaces. The new NE DeviceC works in FlexE mode and supports DCN auto-negotiation on FlexE physical interfaces.

Figure 1-655 Adding a FlexE NE to a live network running Ethernet services

After DeviceC is added, the underlying working mode of the FlexE physical interfaces automatically switches from FlexE to standard Ethernet within about 10s because DCN auto-negotiation is enabled on them by default. The NMS can then manage DeviceC.

If you run the following commands on DeviceC within 20 minutes of being added, the configuration takes effect immediately to ensure DCN continuity.
1. Run the force-physical-mode ethernet command to forcibly switch the underlying working mode of the FlexE physical interface to standard Ethernet.
  
  By default, the underlying working mode of a FlexE physical interface automatically switches from standard Ethernet back to FlexE after 20 minutes.
2. To change the time for switching the underlying working mode of a FlexE physical interface from standard Ethernet back to FlexE, or to disable a FlexE physical interface from switching from the standard Ethernet mode back to the FlexE mode, perform the following operations:
  - Run the phyautoclear forcephysicalmode enable cleartime command to set the time for switching the underlying working mode of the FlexE physical interface from standard Ethernet back to FlexE.
  - Run the phyautoclear forcephysicalmode disable command to disable the underlying working mode of the FlexE physical interface from switching from standard Ethernet back to FlexE.
If the preceding commands are not run on DeviceC within 20 minutes of being added, the underlying working mode of the FlexE physical interfaces on DeviceC is switched from the standard Ethernet mode to the FlexE mode at the 20-minute mark. DCN auto-negotiation is then performed 10 seconds later to implement DCN connectivity. As a result, the NMS cannot manage DeviceC for about 10 seconds, and the process repeats.

If you want to change the services on the live network to the FlexE mode, perform the following steps:

Procedure

Run the flexe enable port port-position command on DeviceA to switch the working mode of the Ethernet interface from standard Ethernet to FlexE. Because the underlying working mode of the FlexE physical interface on DeviceC has been switched to standard Ethernet, the DCN channel between DeviceA and DeviceC is interrupted, and DeviceC is disconnected from the NMS.
Change the status of the FlexE physical interface on DeviceA manually, triggering the underlying working mode of DeviceC's FlexE physical interface connected to the FlexE physical interface on DeviceA to quickly switch back to the FlexE mode. You can perform the following operations:
- Run the laser turn-off command on DeviceA to disable the optical module laser, and then run the laser turn-on command to enable the optical module laser.
- Run the shutdown command on DeviceA to disable the interface, and then run the undo shutdown command to enable the interface.
After the preceding operations are complete, the FlexE physical interface connecting DeviceC to DeviceA is switched back to the FlexE mode. The two devices are now successfully connected using FlexE, and the NMS can continue to manage DeviceC.

In the preceding scenarios, the operations on DeviceB are the same as those on DeviceA.

Adding a FlexE or Ethernet NE in a FlexE Service Scenario

Adding an Ethernet NE to a live network running FlexE services involves the connection between a FlexE physical interface and standard Ethernet interface. If DCN auto-negotiation is enabled on the FlexE physical interface, the two interfaces can automatically communicate with each other, and the NMS can manage the FlexE NE.

Usage Scenario

Adding a FlexE NE to a live network running FlexE services
As shown in Figure 1-656, DeviceA and DeviceB work in FlexE mode on the live network, and the new NE DeviceC also works in FlexE mode.

Figure 1-656 Adding a FlexE NE to a live network running FlexE services

After DeviceC is added, it successfully connects to DeviceA and DeviceB because they all work in FlexE mode. In this case, the NMS can directly manage DeviceC.
Adding an Ethernet NE to a live network running FlexE services
As shown in Figure 1-657, DeviceA and DeviceB work in FlexE mode on the live network, and the new NE DeviceC works in Ethernet mode.

Figure 1-657 Adding an Ethernet NE to a live network running FlexE services

For different scenarios, you can perform the corresponding operations to ensure that the new Ethernet NE can be successfully connected and managed by the NMS.

In the following scenarios, the operations on DeviceB are the same as those on DeviceA.

Procedure

If DeviceA supports DCN auto-negotiation on FlexE physical interfaces, but DeviceC does not:
After DeviceC is added, the underlying working mode of the FlexE physical interface on DeviceA automatically switches from FlexE to standard Ethernet within about 10s because DCN auto-negotiation is enabled on the FlexE physical interface by default. The NMS can then manage DeviceC.
- If you run the following commands on DeviceA within 20 minutes of being added, the configuration takes effect immediately to ensure DCN continuity.
  1. Run the system-view command to enter the system view.
  2. Run the interface interface-type interface-number command to enter the view of a specified FlexE physical interface (for example, FlexE-50G 0/9/1).
  3. Run the force-physical-mode ethernet command to forcibly switch the underlying working mode of the FlexE physical interface to standard Ethernet.
    
    By default, the underlying working mode of a FlexE physical interface automatically switches from standard Ethernet back to FlexE after 20 minutes.
  4. To change the time for switching the underlying working mode of a FlexE physical interface from standard Ethernet back to FlexE, or to disable a FlexE physical interface from switching from the standard Ethernet mode back to the FlexE mode, perform the following operations:
    - Run the phyautoclear forcephysicalmode enable cleartime command to set the time for switching the underlying working mode of the FlexE physical interface from standard Ethernet back to FlexE.
    - Run the phyautoclear forcephysicalmode disable command to disable the underlying working mode of the FlexE physical interface from switching from standard Ethernet back to FlexE.
- If the preceding commands are not run on DeviceA within 20 minutes of being added, the underlying working mode of the FlexE physical interface on DeviceA is switched from the standard Ethernet mode to the FlexE mode at the 20-minute mark. DCN auto-negotiation is then performed 10 seconds later to implement DCN connectivity. As a result, the NMS cannot manage DeviceC for about 10 seconds, and the process repeats.
If you want to continue to run FlexE services on the live network, perform the following operations:
1. Run the flexe enable port port-position command on DeviceC to switch the working mode of the Ethernet interface from standard Ethernet to FlexE. Because the underlying working mode of the FlexE physical interface on DeviceA has been switched to standard Ethernet, the DCN channel between DeviceC and DeviceA is interrupted, and DeviceC is disconnected from the NMS.
2. Change the status of the FlexE physical interface on DeviceC manually, triggering the underlying working mode of DeviceA's FlexE physical interface connected to the FlexE physical interface on DeviceC to quickly switch back to the FlexE mode. You can perform the following operations:
  - Run the laser turn-off command on DeviceC to disable the optical module laser, and then run the laser turn-on command to enable the optical module laser.
  - Run the shutdown command on DeviceC to disable the interface, and then run the undo shutdown command to enable the interface.
After the preceding operations are complete, the FlexE physical interface connecting DeviceA to DeviceC is switched back to the FlexE mode. The two devices are now successfully connected using FlexE, and the NMS can continue to manage DeviceC.
If both DeviceA and DeviceC support DCN auto-negotiation on FlexE physical interfaces:
After DeviceC is added, the underlying working mode of the FlexE physical interface on DeviceA automatically switches from FlexE to standard Ethernet within about 10s because DCN auto-negotiation is enabled on the FlexE physical interface by default. The NMS can then manage DeviceC.

DeviceC supports DCN auto-negotiation on FlexE physical interfaces, and this function is enabled by default. To continue to run FlexE services on the live network, run the flexe enable port port-position command on DeviceC to switch the working mode of the Ethernet interface from standard Ethernet to FlexE.
If DeviceA does not support DCN auto-negotiation on FlexE physical interfaces, but DeviceC does:
After DeviceC is added, run the force-physical-mode ethernet command on DeviceA to forcibly switch the underlying working mode of the FlexE physical interface to standard Ethernet. In this case, DeviceC can communicate with DeviceA and can be managed by the NMS.

If you want to continue to run FlexE services on the live network, perform the following operations:
1. Run the flexe enable port port-position command on DeviceC to switch the working mode of the Ethernet interface from standard Ethernet to FlexE. DeviceC supports DCN auto-negotiation on FlexE physical interfaces, and this function is enabled by default. Therefore, the underlying working mode of the FlexE physical interfaces automatically switches from FlexE to standard Ethernet within about 10s.
2. Run the undo force-physical-mode command on DeviceA to restore the underlying working mode of the FlexE physical interface to FlexE.
3. Change the status of the FlexE physical interface on DeviceA manually, triggering the underlying working mode of DeviceC's FlexE physical interface connected to the FlexE physical interface on DeviceA to quickly switch back to the FlexE mode. You can perform the following operations:
  - Run the laser turn-off command on DeviceA to disable the optical module laser, and then run the laser turn-on command to enable the optical module laser.
  - Run the shutdown command on DeviceA to disable the interface, and then run the undo shutdown command to enable the interface.
After the preceding operations are complete, the FlexE physical interface connecting DeviceC to DeviceA is switched back to the FlexE mode. The two devices are now successfully connected using FlexE, and the NMS can continue to manage DeviceC.

(Optional) Configuring a Time Synchronization Mode for a FlexE Physical Interface

The FlexE standards define two 1588v2 message transmission modes: Overhead (OH) and Client. By default, 1588v2 messages are transmitted in OH mode.

Context

OH mode: Clock messages are transmitted using FlexE overhead timeslots. The configuration related to clock synchronization is the same as that on a standard Ethernet interface.
Client mode: Clock messages are transmitted using FlexE clients. In this mode, the FlexE interface that carries clock services must be bound to a FlexE physical interface that has clock services deployed.

Pre-configuration Tasks

1588v2 has been configured, no matter which mode is used to transmit 1588v2 messages. For details, see HUAWEI NetEngine 8100 M14/M8, NetEngine 8000 M14K/M14/M8K/M8/M4 & NetEngine 8000E M14/M8 series Router Configuration Guide > System Management.

After 1588v2 is configured on a FlexE physical interface, 1588v2 messages are transmitted in OH mode by default. To change the transmission mode of 1588v2 messages to Client, perform the following steps.

Procedure

Run system-view
The system view is displayed.
Run interface interface-type interface-number
The view of a specified FlexE physical interface (for example, FlexE-50G 0/1/0) is displayed.
Run clock binding flexe interface iftype ifnum
A specified FlexE interface carrying clock services is bound to the FlexE physical interface.
Run commit
The configuration is committed.

Verifying the Configuration

After configuring a FlexE interface, verify the configuration.

Prerequisites

A FlexE interface has been configured.

Procedure

Run the display flexe group information slot slot-id card card-id command to check the group information of a FlexE card.
Run any of the following commands to check information about FlexE service interfaces, FlexE physical interfaces, and physical interfaces bound to a FlexE group:
- display flexe client information [ interface { interface-type interface-number | interface-name } ]
- display flexe client information [ index clientindex ]
- display flexe physical-interface information [ interface { interface-type interface-number | interface-name } } ]
Run the display interface ethernet brief command to check brief information about FlexE interfaces.
Run the display interface flexe interface-number command to check the running status and statistics of a FlexE interface.
Run the display lldp neighbor brief command to check brief information about LLDP neighbors of FlexE interfaces.

Interface Group Configuration

An interface group can be used to perform interface configuration in batches, simplifying interface configurations and reducing management costs.

Context

Interface groups are classified into permanent and temporary interface groups. Multiple interfaces can be added to the same permanent or temporary interface group to enable batch command configurations for the interfaces. The differences between permanent and temporary interface groups are described as follows:

After a user exits the view of a temporary interface group, the system automatically deletes the temporary interface group. A permanent interface group, however, can be deleted only by using the undo port-group command.
Information about a permanent interface group can be viewed using the display port-group command, whereas information about a temporary interface group cannot.
After a permanent interface group is configured, a configuration file is generated. However, no configuration file is generated after a temporary interface group is configured.

Procedure

Configure a permanent interface group.
1. Run system-view
  The system view is displayed.
2. Run port-group port-group-name
  A permanent interface group is created and the view of the permanent interface group is displayed.
3. Run group-member { interface-type interface-number1 [ to interface-type interface-number2 ] } &<1-10>
  Specified interfaces are added to the permanent interface group.
4. Run commit
  The configuration is committed.
Configure a temporary interface group.
1. Run system-view
  The system view is displayed.
2. Run port-group group-member { interface-type-start interface-number-start [ to interface-type-end interface-number-end ] } &<1-10>
  A temporary interface group is created, and specified interfaces are added to the group.
  - If the shutdown or undo shutdown command is run for a permanent interface group and the configuration is committed, the configuration is not recorded in the configuration file.
3. Run commit
  The configuration is committed.

Verifying the Configuration

After the configuration is complete, run the display port-group [ all | port-group-name ] command to view information about a specified permanent interface group or all permanent interface groups.

Configuring an Interface Monitoring Group

You can configure an interface monitoring group in a dual-device backup scenario to allow the user-side interface status to change with the network-side interface status so that traffic can be switched between the master and backup links.

Usage Scenario

When a network-side interface goes Down in a dual-device backup scenario, user-side devices cannot detect the Down event and therefore do not switch traffic to the backup link. As a result, traffic overloads or interruptions occur. To prevent these problems, you can configure an interface monitoring group to monitor the network-side interface status and instruct the user-side interface to change its status accordingly. An interface monitoring group allows traffic to be switched between the master and backup links and prevents traffic overloads or interruptions.

On the network shown in Figure 1-658, PE2 backs up PE1. NPE1 through NPEM on the user side is dual-homed to the two PEs to load-balance traffic, and the two PEs are connected to DeviceA through DeviceN on the network side. When only the link between PE1 and DeviceN is available and all the links between PE1 and all the other routers fail, the NPEs do not detect the failure and continue sending packets to DeviceN through PE1. As a result, the link between PE1 and DeviceN becomes overloaded.

Figure 1-658 Typical application of an interface monitoring group
Click to enlarge

Pre-configuration Tasks

Before configuring an interface monitoring group, configure physical attributes for interfaces on the router.

Procedure

Run system-view
The system view is displayed.
Run monitor-group monitor-group-name
An interface monitoring group is created, and the interface monitoring group view is displayed.
Run binding interface interface-type interface-number [ down-weight down-weight-value ]
An interface is added to the interface monitoring group.

The interface added to an interface monitoring group is called a binding interface. A binding interface is located on the network side and a track interface on the user side. An interface monitoring group monitors the binding interface status and allows the track interfaces to change their status accordingly.

You can repeat this step to add multiple binding interfaces to an interface monitoring group.
Run quit
Exit from the interface monitoring group view.
Run interface interface-type interface-number
The view of the specified interface on the user side is displayed.
Run track monitor-group monitor-group-name [ trigger-down-weight trigger-down-weight-value ]
The interface is associated with an interface monitoring group.

The user-side interface associated with an interface monitoring group is called a track interface.

You can repeat steps 5 and 6 to associate multiple track interfaces to an interface monitoring group.

If the down weight sum of all the binding interfaces in the monitoring group is greater than or equal to the value specified using trigger-down-weight-value on the track interface, the track interface goes down, and service traffic is switched to the backup link. Otherwise, the track interface goes up, and service traffic is switched back to the primary link.
Run quit
Exit from the interface view.
Run monitor-group monitor-group-name
The view of the created interface monitoring group is displayed.
(Optional) Run trigger-up-delay trigger-up-delay-value
The delay after which a track interface goes Up is set.
Run monitor enable
The monitoring function is enabled.
Run commit
The configuration is committed.

Verifying the Configuration

Run the display monitor-group [ monitor-group-name ] command to view information about an interface monitoring group.

Maintaining Interfaces

The reset commands help locate faults on interfaces.

Clearing Interface Statistics

Before collecting traffic statistics within a specified period of time on an interface, you must clear existing statistics on the interface.

Context

Statistics cannot be restored after being cleared. Exercise caution when running the following commands.

Procedure

To clear the traffic statistics on an interface, run the reset counters interface command in the user view.
To clear the historical peak rate of an interface and obtain the peak rate in subsequent periods, run the reset counters peak-rate interface command in the user view.

Monitoring Interface Information

Monitoring interface statistics helps you analyze network information based on traffic statistics and rates.

Procedure

Run the monitor interface-statistics interface-type interface-number &<1-5> [ interval interval-value | times { times-value | infinity } ] ^* command in any view to check traffic statistics on a specified interface.
Run the monitor interface-statistics batch [ interface-type [ interface-number-begin [ to interface-number-end ] ] ] [ interval interval-value | times { times-value | infinity } ] ^* [ main ] command in any view to check traffic statistics on interfaces in a batch.
Run the monitor interface-information interface interface-type interface-number [ interval interval-value | times { times-value | infinity } ] ^* command in any view to check detailed information, including the running status and traffic statistics, on a specified interface.
Run the monitor counters bit [ rate ] interface interface-type interface-number [ interval interval-value | times { times-value | infinity } ] ^* command in any view to monitor traffic statistics on an interface. The traffic statistics include the number of unicast, multicast, and broadcast packets sent or received by the interface and the packet transmission rate.

Configuration Examples for Interface Management

This section provides interface management examples.

Example for Managing Interfaces

This section uses an example to describe how to configure interface parameters, such as the interface description, maximum transmission unit (MTU), and interval at which traffic statistics are collected.

Networking Requirements

To ensure smooth communication between devices on a network, you need to configure both physical and logical interfaces properly and set the following parameters:

Interface description
MTU
Trap threshold for the outbound and inbound bandwidth usage on a specified interface
Interval at which traffic statistics are collected
Whether the device sends a trap message to the network management system (NMS) when the interface status changes
Whether the control-flap function is enabled

Configuration Roadmap

The configuration roadmap is as follows:

Configure a description for an interface.
Set an MTU for the interface to ensure successful packet transmission over the interface.
Set the interval at which traffic statistics (including the traffic volumes and rates) are collected globally.
Create a sub-interface and set an MTU for the sub-interface so that packets can reach the receiver.

Data Preparation

To complete the configuration, you need the following data:

Interface name
Interface description
Interface MTU
Interval at which traffic statistics are collected globally
Sub-interface MTU

Procedure

Configure a description for an interface.

<HUAWEI> system-view

[~HUAWEI] interface gigabitethernet 0/2/0

[~HUAWEI-GigabitEthernet0/2/0] description for IFM

[*HUAWEI-GigabitEthernet0/2/0] commit

Set an MTU for the interface.

[~HUAWEI-GigabitEthernet0/2/0] mtu 1000

[*HUAWEI-GigabitEthernet0/2/0] commit

[~HUAWEI-GigabitEthernet0/2/0] quit

Set the interval at which traffic statistics are collected globally.
```
[~HUAWEI] set flow-stat interval 100
```
```
[*HUAWEI] commit
```

Create a sub-interface and set the MTU of the sub-interface.

[~HUAWEI] interface gigabitethernet 0/2/0.1

[*HUAWEI-GigabitEthernet0/2/0.1] mtu 800

[*HUAWEI-GigabitEthernet0/2/0.1] commit

Configuration Files

set flow-stat interval 100

interface Gigabitethernet0/2/0

 description for IFM

 mtu 1000

interface Gigabitethernet0/2/0.1

 mtu 800

return

Example for Configuring FlexE Interfaces

This section provides an example for configuring interfaces on two devices that are connected using FlexE.

Networking Requirements

On the network shown in Figure 1-659, FlexE clients need to be created on DeviceA and DeviceB for communication. Different bandwidths are configured for the FlexE clients to meet requirements for diversified services and applications. The bandwidths of FlexE Client1, FlexE Client2, FlexE Client3, and FlexE Client4 need to be set to 4 Gbit/s, 5 Gbit/s, 15 Gbit/s, and 20 Gbit/s, respectively.

Figure 1-659 Networking diagram for configuring FlexE interfaces

In this example, interface 0, interface 1, interface 2, interface 3, and interface 4 represent FlexE-50G 0/9/1, FlexE 0/9/129, FlexE 0/9/130, FlexE 0/9/131, and FlexE 0/9/132, respectively.

Precautions

When you configure FlexE interfaces, note the following:

To ensure normal communication between interconnected devices, you need to configure the same PHY number for the FlexE physical interfaces on both of them.
To ensure normal communication between interconnected devices, you need to configure the same group number for the FlexE groups to which the FlexE physical interfaces on both devices are added.
To ensure that the FlexE clients on both ends can communicate with each other, you need to configure the same ID and bandwidth for them.

Configuration Roadmap

The configuration roadmap is as follows:

Activate the FlexE interface license on a board.
Configure a standard Ethernet interface to work in FlexE mode.
Configure a PHY number for a FlexE physical interface.
Create a FlexE group and bind the FlexE physical interface to it.
Configure a number for the FlexE group.
Configure a sub-timeslot granularity for a FlexE card.
Create a FlexE client and configure an ID and bandwidth for it.
Configure an IP address for each interface.

Data Preparation

To complete the configuration, you need the following data:

PHY number of a FlexE physical interface: 5
Index of a FlexE group: 1
Number of a FlexE group: 2345
Sub-timeslot granularity of a FlexE card: 1 Gbit/s
IDs of four FlexE interfaces: port numbers of interface 1, interface 2, interface 3, and interface 4
IDs of four FlexE clients: 1, 2, 3, and 4 (corresponding to 4 Gbit/s, 5 Gbit/s, 15 Gbit/s, and 20 Gbit/s bandwidths, respectively)

Procedure

Activate the FlexE interface license on a board.

<DeviceA> license active XXXXX.dat
<DeviceA> system-view
[~DeviceA] license
[~DeviceA-license] active port-slicing slot 9 card       9      port 1
[*DeviceA-license] commit
[~DeviceA-license] quit

Configure a standard Ethernet interface to work in FlexE mode.

[~DeviceA] flexe enable port 0/9/1
Warning: This operation will delete interface 50G0/9/1 and related services. Continue? [Y/N]:y
[*DeviceA] commit

Configure a PHY number for a FlexE physical interface.

[~DeviceA] interface FlexE-50G 0/9/1
[~DeviceA-FlexE-50G0/9/1] phy-number 5
Warning: The traffic on this interface may be interrupted if the operation is performed. Continue? [Y/N]:y
[*DeviceA-FlexE-50G0/9/1] commit
[~DeviceA-FlexE-50G0/9/1] quit

Create a FlexE group and bind the FlexE physical interface to it.

[~DeviceA] flexe group 1
[*DeviceA-flexe-group-1] binding interface FlexE-50G0/9/1

Configure a number for the FlexE group.

[*DeviceA-flexe-group-1] flexe-groupnum 2345
Warning: The traffic on related clients may be interrupted if the operation is performed. Continue? [Y/N]:y
[*DeviceA-flexe-group-1] commit
[~DeviceA-flexe-group-1] quit

Configure a sub-timeslot granularity for a FlexE card.

[~DeviceA] set flexe sub-time-slot granula slot 9 card       9      1g
[*DeviceA] commit

Create a FlexE client and configure an ID and bandwidth for it.

[~DeviceA] flexe client-instance 1 flexe-group 1 flexe-type full-function port-id 129
[*DeviceA-flexe-client-1] flexe-clientid 1
Warning: The traffic on this interface may be interrupted if the operation is performed. Continue? [Y/N]:y
[*DeviceA-flexe-client-1] flexe-bandwidth 4
[*DeviceA-flexe-client-1] commit
[~DeviceA-flexe-client-1] quit
[~DeviceA] flexe client-instance 2 flexe-group 1 flexe-type full-function port-id 130
[*DeviceA-flexe-client-2] flexe-clientid 2
Warning: The traffic on this interface may be interrupted if the operation is performed. Continue? [Y/N]:y
[*DeviceA-flexe-client-2] flexe-bandwidth 5
[*DeviceA-flexe-client-2] commit
[~DeviceA-flexe-client-2] quit
[~DeviceA] flexe client-instance 3 flexe-group 1 flexe-type full-function port-id 131
[*DeviceA-flexe-client-3] flexe-clientid 3
Warning: The traffic on this interface may be interrupted if the operation is performed. Continue? [Y/N]:y
[*DeviceA-flexe-client-3] flexe-bandwidth 15
[*DeviceA-flexe-client-3] commit
[~DeviceA-flexe-client-3] quit
[~DeviceA] flexe client-instance 4 flexe-group 1 flexe-type full-function port-id 132
[*DeviceA-flexe-client-4] flexe-clientid 4
Warning: The traffic on this interface may be interrupted if the operation is performed. Continue? [Y/N]:y
[*DeviceA-flexe-client-4] flexe-bandwidth 20
[*DeviceA-flexe-client-4] commit
[~DeviceA-flexe-client-4] quit

Configure an IP address for each interface. For configuration details, see Configuration Files in this section.
Repeat the preceding steps on DeviceB. For configuration details, see Configuration Files in this section.

Verify the configuration.

After completing the preceding configuration, run the display flexe group information command on DeviceA and DeviceB to check group information of FlexE cards. The command output on DeviceA is used as an example.

[~DeviceA] display flexe group information slot 9 card       9     
FlexE Card Info:
=============================================================
FlexE Config Mode                : Bandwidth
=============================================================

FlexE Group Info:
=============================================================
GroupID    Total Bandwidth(M)    Valid Bandwidth(M)
------------------------------------------------------
1                50000                50000  
=============================================================

FlexE Group Binding Interfaces Capability:
=============================================================
-------------------------------------------------------------
GroupID   Interfaces already bound  Interfaces can be bound  
-------------------------------------------------------------
1         FlexE-50G0/9/1                                                       
-------------------------------------------------------------
=============================================================

FlexE Phy Info:
=============================================================
Port No             : FlexE-50G0/9/1
Active Status       : 1
Cfg Group ID        : 1
Cfg Group No        : 2345
Real TX Group No    : 2345
Real RX Group No    : 2345
Remote Group No     : 2345
Cfg Phy No          : 5
Real TX Phy No      : 5
Real RX Phy No      : 5
Remote Phy No       : 5
=============================================================

FlexE Time Slot Info:
=============================================================

------------------------------------------------------
port-no             : FlexE-50G0/9/1
ts-num              : 20
sub-ts-num          : 5
-------------------------------------------------------
  time-slot-id      ts-port-map
-------------------------------------------------------
   0:               [129][129][129][129][130]
   1:               [130][130][130][130][131]
   2:               [131][131][131][131][131]
   3:               [131][131][131][131][131]
   4:               [131][131][131][131][132]
   5:               [132][132][132][132][132]
   6:               [132][132][132][132][132]
   7:               [132][132][132][132][132]
   8:               [132][132][132][132][-]
   9:               [-][-][-][-][-]
  10:               [-][-][-][-][-]
  11:               [-][-][-][-][-]
  12:               [-][-][-][-][-]
  13:               [-][-][-][-][-]
  14:               [-][-][-][-][-]
  15:               [-][-][-][-][-]
  16:               [-][-][-][-][-]
  17:               [-][-][-][-][-]
  18:               [-][-][-][-][-]
  19:               [-][-][-][-][-]
=============================================================

FlexE Client Info:
=============================================================
---------------------------------------------------
Instance Index            Port Name                
---------------------------------------------------
129                        FlexE0/9/129  
130                        FlexE0/9/130 
131                        FlexE0/9/131
132                        FlexE0/9/132
---------------------------------------------------
=============================================================

Run the display interface ethernet brief command on DeviceA and DeviceB to check brief information about FlexE interfaces. The command output on DeviceA is used as an example.

[~DeviceA] display interface ethernet brief
PHY: Physical
*down: administratively down
^down: standby
(l): loopback
(b): BFD down
(d): Dampening Suppressed
(p): port alarm down
InUti/OutUti: input utility/output utility
Interface                   PHY   Auto-Neg Duplex Bandwidth  InUti OutUti Trunk
FlexE0/9/129                up    -        full          4G  0.01%  0.01%    --
FlexE0/9/130                up    -        full          5G  0.01%  0.01%    --
FlexE0/9/131                up    -        full         15G  0.01%  0.01%    --
FlexE0/9/132                up    -        full         20G  0.01%  0.01%    --
FlexE-50G0/9/1              up    -        full         50G     --     --    --

Run the display lldp neighbor brief command on DeviceA and DeviceB to check brief information about LLDP neighbors of FlexE interfaces. The command output on DeviceA is used as an example.

[~DeviceA] display lldp neighbor brief
Local Intf                     Neighbor Dev         Neighbor Intf        Exptime (sec)
--------------------------------------------------------------------------------------
FlexE0/9/129                   DeviceB              FlexE0/9/129                   114
FlexE0/9/130                   DeviceB              FlexE0/9/130                   114
FlexE0/9/131                   DeviceB              FlexE0/9/131                   114
FlexE0/9/132                   DeviceB              FlexE0/9/132                   114
FlexE-50G0/9/1                 DeviceB              FlexE-50G0/9/1                 95

Run the display interface flexe interface-number command on DeviceA and DeviceB to check the running status and statistics of a FlexE interface. The following example uses the command output on FlexE 0/9/129 of DeviceA.

[~DeviceA] display interface flexe 0/9/129
FlexE0/9/129 current state : UP (ifindex: 285)
Line protocol current state : UP 
Last line protocol up time : 2021-03-11 09:11:24
Link quality grade : GOOD
Description: 
Route Port,The Maximum Transmit Unit is 1500 
Internet Address is 10.1.1.1/24
IP Sending Frames' Format is PKTFMT_ETHNT_2, Hardware address is 00e0-fc12-3456
Port BW: 4G
Pause Flowcontrol: Receive Enable and Send Enable
Client-id Match State: Match
Last physical up time   : 2021-03-10 15:11:46
Last physical down time : 2021-03-10 15:11:29
Current system time: 2021-03-11 11:36:52
Statistics last cleared:never
    Last 300 seconds input rate: 10031 bits/sec, 1 packets/sec
    Last 300 seconds output rate: 10041 bits/sec, 1 packets/sec
    Input peak rate 125150137 bits/sec, Record time: 2021-03-10 09:25:57
    Output peak rate 125757954 bits/sec, Record time: 2021-03-10 09:25:57
    Input: 7006191780 bytes, 52343200 packets
    Output: 7024402448 bytes, 52482810 packets
    Input:
      Unicast: 52334185 packets, Multicast: 9010 packets
      Broadcast: 5 packets, JumboOctets: 0 packets
      CRC: 0 packets, Symbol: 0 packets
      Overrun: 0 packets, InRangeLength: 0 packets
      LongPacket: 0 packets, Jabber: 0 packets, Alignment: 0 packets
      Fragment: 0 packets, Undersized Frame: 0 packets
      RxPause: 0 packets
    Output:
      Unicast: 52473465 packets, Multicast: 9334 packets
      Broadcast: 11 packets, JumboOctets: 0 packets
      Lost: 0 packets, Overflow: 0 packets, Underrun: 0 packets
      System: 0 packets, Overruns: 0 packets
      TxPause: 0 packets
    Last 300 seconds input utility rate:  0.01%
    Last 300 seconds output utility rate: 0.01%

Configuration Files

DeviceA configuration file

#
sysname DeviceA
#
set flexe sub-time-slot granula slot 9 card       9      1g
flexe enable port 0/9/1
#
flexe group 1
 flexe-groupnum 2345
 binding interface FlexE-50G0/9/1
#
flexe client-instance 1 flexe-group 1 flexe-type full-function port-id 129
 flexe-clientid 1
 flexe-bandwidth 4
#
flexe client-instance 2 flexe-group 1 flexe-type full-function port-id 130
 flexe-clientid 2
 flexe-bandwidth 5
#
flexe client-instance 3 flexe-group 1 flexe-type full-function port-id 131
 flexe-clientid 3
 flexe-bandwidth 15
#
flexe client-instance 4 flexe-group 1 flexe-type full-function port-id 132
 flexe-clientid 4
 flexe-bandwidth 20
#
license
 active port-slicing slot 9 card       9      port 1
#
interface FlexE-50G0/9/1
 undo shutdown
 undo dcn
 phy-number 5
#
return

DeviceB configuration file

#
sysname DeviceB
#
set flexe sub-time-slot granula slot 9 card       9      1g
flexe enable port 0/9/1
#
flexe group 1
 flexe-groupnum 2345
 binding interface FlexE-50G0/9/1
#
flexe client-instance 1 flexe-group 1 flexe-type full-function port-id 129
 flexe-clientid 1
 flexe-bandwidth 4
#
flexe client-instance 2 flexe-group 1 flexe-type full-function port-id 130
 flexe-clientid 2
 flexe-bandwidth 5
#
flexe client-instance 3 flexe-group 1 flexe-type full-function port-id 131
 flexe-clientid 3
 flexe-bandwidth 15
#
flexe client-instance 4 flexe-group 1 flexe-type full-function port-id 132
 flexe-clientid 4
 flexe-bandwidth 20
#
license
 active port-slicing slot 9 card       9      port 1
#
interface FlexE-50G0/9/1
 undo shutdown
 undo dcn
 phy-number 5
#
return

Interface Management Feature Description
Interface Management Configuration

Translation

Favorite

Download

Update Date：2024-04-01

Document ID：EDOC1100335691

Downloads：659

Average rating：5.0Points

Digital Signature File

digtal sigature tool