NetEngine 8000 M14, M8 and M4 V800R023C00SPC500 Configuration Guide 04 Interface and Data Link

HUAWEI NetEngine 8100 M14/M8, NetEngine
8000 M14K/M14/M8K/M8/M4 & NetEngine 8000E

M14/M8 series
V800R023C00SPC500
Configuration Guide
Issue 01
Date 2023-09-30
HUAWEI TECHNOLOGIES CO., LTD.

Copyright © Huawei Technologies Co., Ltd. 2023. All rights reserved.
No part of this document may be reproduced or transmitted in any form or by any means without prior
written consent of Huawei Technologies Co., Ltd.
Trademarks and Permissions
and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd.
All other trademarks and trade names mentioned in this document are the property of their respective
holders.
Notice
The purchased products, services and features are stipulated by the contract made between Huawei and
the customer. All or part of the products, services and features described in this document may not be
within the purchase scope or the usage scope. Unless otherwise specified in the contract, all statements,
information, and recommendations in this document are provided "AS IS" without warranties, guarantees
or representations of any kind, either express or implied.
The information in this document is subject to change without notice. Every effort has been made in the
preparation of this document to ensure accuracy of the contents, but all statements, information, and
recommendations in this document do not constitute a warranty of any kind, express or implied.
Huawei Technologies Co., Ltd.

Address: Huawei Industrial Base
Bantian, Longgang
Shenzhen 518129
People's Republic of China
Website: https://www.huawei.com
Email: support@huawei.com
Issue 01 (2023-09-30) Copyright © Huawei Technologies Co., Ltd. i

HUAWEI NetEngine 8100 M14/M8, NetEngine 8000
M14K/M14/M8K/M8/M4 & NetEngine 8000E
M14/M8 series
Configuration Guide Contents
Contents
1 Configuration............................................................................................................................1
1.1 Interface and Data Link........................................................................................................................................................ 1
1.1.1 Interface Management Configuration.......................................................................................................................... 1
1.1.1.1 Interface Management Feature Description........................................................................................................... 1
1.1.1.1.1 Overview of Interface Management...................................................................................................................... 1
1.1.1.1.2 Understanding Interface Management................................................................................................................. 2
1.1.1.1.3 Interface Management Application..................................................................................................................... 50
1.1.1.2 Interface Management Configuration.................................................................................................................... 65
1.1.1.2.1 Overview of Interface Management.................................................................................................................... 66
1.1.1.2.2 Feature Requirements for Interface Management..........................................................................................78
1.1.1.2.3 Interface Basics Configuration............................................................................................................................... 78
1.1.1.2.4 Configuring the Physical Link Detection Function.......................................................................................... 88
1.1.1.2.5 Configuring MAC Accounting................................................................................................................................. 95
1.1.1.2.6 Configuring Strict Filter for EVC Sub-Interfaces.............................................................................................. 96
1.1.1.2.7 Enabling the Signal Sending Delay Function.................................................................................................... 97
1.1.1.2.8 Configuring an Interval for Updating Interface Statistics in the Cache...................................................98
1.1.1.2.9 Configuring a Trap Threshold for Sudden Changes in the Traffic Rate on Global Interfaces..........99
1.1.1.2.10 Enabling or Disabling the Optical Module Laser........................................................................................100
1.1.1.2.11 Configuring the Optical Module Mode of an Interface............................................................................102
1.1.1.2.12 Enabling the Optical Module Alarm Threshold Standardization Function........................................103
1.1.1.2.13 Disabling the Optical Module Alarm Function............................................................................................103
1.1.1.2.14 Managing Non-Huawei-Certified Optical Modules................................................................................... 104
1.1.1.2.15 Configuring SerDes Polarity Inversion............................................................................................................ 105
1.1.1.2.16 Configuring the Control-Flap Function.......................................................................................................... 105
1.1.1.2.17 Logical Interface Configuration........................................................................................................................ 107
1.1.1.2.18 FlexE Interface Configuration............................................................................................................................ 112
1.1.1.2.19 Interface Group Configuration.......................................................................................................................... 127
1.1.1.2.20 Configuring an Interface Monitoring Group................................................................................................ 128
1.1.1.2.21 Maintaining Interfaces......................................................................................................................................... 131
1.1.1.2.22 Configuration Examples for Interface Management................................................................................. 132
1.1.2 Transmission Alarm Customization and Suppression Configuration............................................................ 139
1.1.2.1 Transmission Alarm Customization and Suppression Feature Description..............................................140
1.1.2.1.1 Overview of Transmission Alarm Customization and Suppression.........................................................140
Issue 01 (2023-09-30) Copyright © Huawei Technologies Co., Ltd. ii

M14/M8 series
Configuration Guide Contents
1.1.2.1.2 Principles of Transmission Alarm Customization and Suppression.........................................................141

1.1.2.1.3 Terms and Abbreviations for Transmission Alarm Customization and Suppression......................... 144
1.1.2.2 Transmission Alarm Customization and Suppression Configuration ........................................................145
1.1.2.2.1 Overview of Transmission Alarm Customization and Suppression.........................................................145
1.1.2.2.2 Feature Requirements for Transmission Alarm Customization and Suppression...............................146
1.1.2.2.3 Configuring Transmission Alarm Customization........................................................................................... 146
1.1.2.2.4 Configuring Transmission Alarm Filtering Intervals..................................................................................... 149
1.1.2.2.5 Configuring Transmission Alarm Suppression................................................................................................ 151
1.1.2.2.6 Maintaining Transmission Alarm Customization and Suppression ....................................................... 152
1.1.3 Port Extension Configuration...................................................................................................................................... 153
1.1.3.1 Port Extension Feature Description....................................................................................................................... 153
1.1.3.1.1 Overview of Port Extension.................................................................................................................................. 153
1.1.3.1.2 Features Supported of Port Extension.............................................................................................................. 155
1.1.3.1.3 Understanding Port Extension............................................................................................................................. 156
1.1.3.1.4 Application Scenarios for Port Extension......................................................................................................... 166
1.1.3.1.5 Terminology for Port Extension........................................................................................................................... 167
1.1.3.2 Port Extension Configuration.................................................................................................................................. 167
1.1.3.2.1 Feature Requirements for Port Extension........................................................................................................ 168
1.1.3.2.2 Establishing a Port Extension System............................................................................................................... 169
1.1.3.2.3 Upgrading and Managing an AP........................................................................................................................ 180
1.1.3.2.4 Maintaining the Port Extension System........................................................................................................... 192
1.1.3.2.5 Configuration Examples for Port Extension.................................................................................................... 193
Issue 01 (2023-09-30) Copyright © Huawei Technologies Co., Ltd. iii

M14/M8 series
Configuration Guide 1 Configuration
1 Configuration
1.1 Interface and Data Link
1.1.1 Interface Management Configuration
1.1.1.1 Interface Management Feature Description
1.1.1.1.1 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
Issue 01 (2023-09-30) Copyright © Huawei Technologies Co., Ltd. 1

M14/M8 series
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.
1.1.1.1.2 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-1 lists the commands, views, and prompts of physical interfaces supported
by the NetEngine 8100 M, NetEngine 8000E M, NetEngine 8000 M. Table 1-2 lists
the commands, views, and prompts of logical interfaces supported by the
NetEngine 8100 M, NetEngine 8000E M, NetEngine 8000 M.

M14/M8 series
Table 1-1 Commands, views, and prompts of physical interfaces supported by the
NetEngine 8100 M, NetEngine 8000E M, NetEngine 8000 M
Interface Command View Oper Prompt
Name ation
GE interface GE interface view Run [~HUAWEI-

the GigabitEthernet0/2/0]
inter
face
giga
bitet
hern
et
0/2/0
com
mand
in the
syste
m
view.

M14/M8 series

Name ation
10GE interface 10GE interface view Run [~HUAWEI-

inter
face
giga
bitet
hern
et
0/1/0
com
mand
in the
syste
m
view.
NOTE
The
inte
rfac
es
mar
ked
with
10G
displ
aye
d in
the
disp
lay
inte
rfac
e
brie
f
com
man
d
outp
ut
indi
cate
GE
inte
rfac
es
who
se
ban
dwi
dth
is
10
Gbit
/s.

M14/M8 series

Name ation
25GE interface 25GE interface view Run [~HUAWEI-25GE0/2/0]

the
inter
face
25GE
0/2/0
com
mand
in the
syste
m
view.

the
inter
face
40GE
0/2/0
com
mand
in the
syste
m
view.

the
inter
face
100G
E
0/1/0
com
mand
in the
syste
m
view.

M14/M8 series

Name ation

the
inter
face
200G
E
0/1/0
com
mand
in the
syste
m
view.

NOTE the
This interface is not inter
supported on the face
NetEngine 8000 M8K or 400G
NetEngine 8000 M14K.
E
0/1/0
com
mand
in the
syste
m
view.
XGE interface XGE interface view Run [~HUAWEI-

the XGigabitEthernet0/1/0]
inter
face
XGig
abitE
thern
et
0/1/0
com
mand
in the
syste
m
view.

M14/M8 series

Name ation
CPOS interface CPOS interface view Run [~HUAWEI-Cpos0/3/0]

NOTE the
This interface is not contr
supported on the oller
NetEngine 8000 M4. cpos
0/3/0
com
mand
in the
syste
m
view.
POS interface POS interface view Run [~HUAWEI-Pos0/3/0]

NOTE the
NetEngine 8000 M4. pos
0/3/0
com
mand
in the
syste
m
view.

the
inter
face
50GE
0/1/0
com
mand
in the
syste
m
view.

M14/M8 series

Name ation
50|100GE 50|100GE interface view Run [~HUAWEI-50|

interface NOTE the 100GE0/1/0]
The default rate of this type inter
of interface is 50 Gbit/s and face
can be switched to 100 50|
Gbit/s.
100G
E
0/1/0
com
mand
in the
syste
m
view.
FlexE-50G FlexE-50G interface view Run [~HUAWEI-

interface the FlexE-50G0/1/0]
inter
face
FlexE
-50G
0/1/0
com
mand
in the
syste
m
view.

interface NOTE the FlexE-100G0/1/0]
NetEngine 8000 M8K or FlexE
-100
G
0/1/0
com
mand
in the
syste
m
view.

M14/M8 series

Name ation

inter
face
FlexE
-400
G
0/1/0
com
mand
in the
syste
m
view.

NetEngine 8000 M4, FlexE
NetEngine 8000 M8K, and
-10G
0/1/0
com
mand
in the
syste
m
view.
Table 1-2 Commands, views, and prompts of logical interfaces

Interface Command View Operation Prompt
Name
Sub-interface Sub-interface view Run the [~HUAWEI-

interface GigabitEthernet0/1/0.1]
gigabitethern
et 0/1/0.1
command in
the system
view.
Eth-Trunk Eth-Trunk Run the [~HUAWEI-Eth-Trunk2]

interface interface view interface eth-
trunk 2
command in
the system
view.

M14/M8 series

Name
VE interface VE interface view Run the [~HUAWEI-Virtual-

interface Ethernet0/1/0]
virtual-
ethernet
0/1/0
command in
the system
view.
Global VE Global VE Run the [~HUAWEI-Global-VE0]

interface interface view interface
global-ve 0
command in
the system
view.
VLANIF VLANIF interface Run the [~HUAWEI-Vlanif2]

interface view interface
vlanif 2
command in
the system
view.
Loopback Loopback Run the [~HUAWEI-LoopBack2]

loopback 2
command in
the system
view.
Null interface Null interface Run the [~HUAWEI-NULL0]

view interface null
0 command in
the system
view.
IP-Trunk IP-Trunk interface Run the [~HUAWEI-Ip-Trunk2]

interface view interface ip-
trunk 2
command in
the system
view.
Tunnel Tunnel interface Run the [~HUAWEI-Tunnel 2]

tunnel 2
command in
the system
view.

M14/M8 series

Name
NVE interface NVE interface Run the [~HUAWEI-Nve1]

view interface nve
1 command in
the system
view.
FlexE FlexE interface Run the [~HUAWEI-FlexE0/2/5]

FlexE 0/2/5
command in
the system
view.
Virtual serial Virtual serial Run the [~HUAWEI-Virtual-

interface interface view interface Serial0/2/0]
Virtual-Serial
0/2/0
command in
the system
view.
PW-VE PW-VE interface Run the [~HUAWEI-pw-ve1]

interface view interface pw-
ve 1
command in
the system
view.
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.

M14/M8 series
– 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.

M14/M8 series
Figure 1-1 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.

M14/M8 series
Figure 1-2 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.

M14/M8 series
The following two control modes are available.
Table 1-3 Flapping control modes

Control Mode Function Usage Scenario
control-flap Controls the frequent ● This control mode is

flappings of interfaces at interface-specific.
the network layer to ● This control mode
minimize the impact on suppresses interface
device and network flappings from the
stability. 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.
involves complex
algorithms and is
highly demanding to
use.

M14/M8 series
damp-interface Controls the frequent ● This function is

flappings of interfaces at supported globally or
the physical layer to on a specified
minimize the impact on interface.
device and network ● This control mode
stability. suppresses the
flappings from the
physical layer, thereby
improving link-layer
and network-layer
stability.
prevents the upper-
layer protocols from
frequently alternating
between enabled and
disabled, thereby
reducing the
consumption of CPU
and memory
resources.
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.

M14/M8 series
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-4 Flapping control parameter configuration recommendations
Configuration Recommendations
Objective
suppress reuse decay-ok decay-ng
To delay interface Increase N/A Decrease Decrease

suppression
To accelerate Decrease N/A Increase Increase

interface suppression
To accelerate N/A Increase Decrease Decrease

disabling interface
suppression
To delay disabling N/A Decrease Increase Increase

interface suppression
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:

M14/M8 series
Table 1-5 Example for setting the control-flap parameter

Parameter Examples for the Impact of Flapping Control Parameters
on Interface Suppression
suppress
reuse

M14/M8 series
Parameter Examples for the Impact of Flapping Control Parameters

on Interface Suppression
decay-ok and
decay-ng
Principles of interface flapping control:

In Figure 1-3, 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.

M14/M8 series
Figure 1-3 Principles of interface flapping control
● 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.

M14/M8 series
Figure 1-4 shows the relationship between the preceding parameters. To

facilitate understanding, figures in Figure 1-4 are all multiplied by 1000.
Figure 1-4 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.
NOTE
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-6 Logical interface list
Interface Name Usage Scenario and Interface Description
DCN serial After DCN is enabled globally, a DCN serial interface is

interface automatically created.

M14/M8 series
Virtual Ethernet When an L2VPN accesses multiple L3VPNs, VE interfaces

(VE) interface 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.

M14/M8 series
Flexible Ethernet A physical interface in standard Ethernet mode has fixed

(FlexE) interface 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 A channelized interface can strictly isolate interface

sub-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.

M14/M8 series
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.

M14/M8 series
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- An Ethernet sub-interface can be configured on a physical

interface 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.

M14/M8 series
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 An ATM bundle interface is used to forward one type of

interface 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 Serial interfaces are channelized from E1 or CPOS

interface 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.

M14/M8 series
Channelized serial Sub-interfaces can be created on serial interfaces that are

sub-interface 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 A CPOS-Trunk interface can have multiple CPOS interfaces

interface bundled to support APS.
Trunk serial A trunk serial interface is channelized from a CPOS-Trunk

interface 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 A protection channel can be configured to take over traffic

interface 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 When users access an ATM network at a rate between T1

interface 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.

M14/M8 series
Global IMA-group A protection channel can be configured to take over traffic

interface 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
?.1. 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-5). 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-5 Structures of standard Ethernet and FlexE

M14/M8 series
Purpose
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, private line access, and mobile bearer
services. These factors place increasingly higher requirements on
telecommunication network interfaces.
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.
?.2. General Architecture of FlexE

The FlexE standards define the client/group architecture, as shown in Figure 1-6.
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.

M14/M8 series
Figure 1-6 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.
?.3. 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-7, 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.

M14/M8 series
Figure 1-7 Bonding
Channelization
As shown in Figure 1-8, 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-8 Channelization
Sub-rating
As shown in Figure 1-9, 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-9 Sub-rating

M14/M8 series
?.4. 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-10, 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-10 FlexE shim mechanism
Calendar Mechanism
Figure 1-11 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.
NOTE
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-11.
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.

M14/M8 series
Figure 1-11 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-11. 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-12 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-12 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

M14/M8 series
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-7
describes the meaning of each field in an overhead frame.
Table 1-7 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.

M14/M8 series
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.

M14/M8 series
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.

M14/M8 series
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 - 64 A section management

Section channel is used to
transmit management
messages, such as DCN
and LLDP messages,
between adjacent FlexE
nodes.

M14/M8 series
Management Channel - 64 A shim-to-shim

Shim to Shim management channel is
used to transmit
management messages,
such as DCN and LLDP
messages, between E2E
FlexE nodes.
Synchronization 64 A synchronization
Messaging Channel messaging channel is
used to transmit clock
messages, such as
1588v2 messages,
between adjacent FlexE
nodes.
NOTE
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-13, 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.

M14/M8 series
Figure 1-13 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-14, 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.

M14/M8 series
Figure 1-14 Hitless bandwidth adjustment through timeslot table switching
As shown in Figure 1-15, the timeslot table switching process is as follows:

1. FlexE Client1 on Router1 uses timeslot table A to send packets based on 5
Gbit/s bandwidth.
2. 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.
3. 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.
4. 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.
5. 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.

M14/M8 series
Figure 1-15 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-16 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.
NOTE
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.

M14/M8 series
Figure 1-16 1 Gbit/s timeslot granularity mechanism
?.5. FlexE Mode Switching

As shown in Figure 1-17, 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:
1. Switch the uplink interface of the downstream NE to the FlexE mode.

2. 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-17 Switching standard Ethernet interfaces to the FlexE mode

M14/M8 series
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-18, the configuration restoration process is as follows:
1. 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.
2. FlexE clients are created based on the defined rules to carry the bandwidth of
the original standard Ethernet interfaces.
3. The configurations of the original standard Ethernet interfaces are restored to
the created FlexE clients.

M14/M8 series
Figure 1-18 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

M14/M8 series
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.
?.6. FlexE DCN Modes

As shown in Figure 1-19, 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-19 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

M14/M8 series
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-20, 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-20 Interconnection mode of a standard Ethernet interface and FlexE

physical interface
?.7. FlexE Time Synchronization Modes

As shown in Figure 1-21, 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.
NOTE
The time synchronization modes at the two ends of a FlexE link must be the same (either
the OH or Client mode).

M14/M8 series
Figure 1-21 FlexE time synchronization modes
?.8. 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-22, a
FlexE group consisting of 100GE PHYs is used as an example to describe the
working process of FlexE mux.
1. Each FlexE client is presented to the FlexE shim as a 64B/66B encoded bit
stream.
2. 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.
3. The 66B blocks from each FlexE client are sequentially distributed and
inserted into the calendar.
4. Error control blocks are generated for insertion into unused or unavailable
timeslots to ensure that the data in these timeslots is not considered valid.
5. The control function manages which timeslots each FlexE client is inserted
into and inserts the FlexE overhead on each PHY in the transmit direction.
6. 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

M14/M8 series
distribution mechanism. The sub-calendar then schedules the 66B blocks to

the corresponding PHYs in the FlexE group in polling mode.
7. 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-22 FlexE mux
?.9. 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-23,
a FlexE group consisting of 100GE PHYs is used as an example to describe the
working process of FlexE demux.
1. 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.
2. The calendar logically interleaves the sub-timeslots of each FlexE instance, re-
orders them, and extracts the FlexE overhead.
3. 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).
4. The control function manages the timeslots extracted by each FlexE client
from each FlexE instance in the receive direction.

M14/M8 series
5. The extracted timeslots are sent to each FlexE client based on the 66B blocks.
6. 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-23 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.

M14/M8 series
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-24 Interface monitoring group
In the example network shown in Figure 1-24, 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.
1.1.1.1.3 Interface Management Application
Sub-interface
In the network shown in Figure 1-25, multiple sub-interfaces are configured on
the physical interface of Device. Like a physical interface, each sub-interface can

M14/M8 series
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-25 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-26, 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-26 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.

M14/M8 series
Application of FlexE
?.1. 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-27, 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-27 Traditional LAG technology for interface bonding
FlexE Technology for Interface Bonding

As shown in Figure 1-28, 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-28 FlexE technology for interface bonding

M14/M8 series
?.2. 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-29,
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-29 FlexE technology for 5G network slicing
?.3. 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-30. 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.

M14/M8 series
Figure 1-30 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-31. 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-31 FlexE-OTN mapping in termination mode

M14/M8 series
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-32, 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-32 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-

M14/M8 series
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-33,
Port 1 and Port 3 indicate channelized interfaces, and Port 2 is a physical interface.
Figure 1-33 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.

M14/M8 series
● 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

M14/M8 series
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-34, 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.

M14/M8 series
Figure 1-34 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.

M14/M8 series
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.

M14/M8 series
Table 1-8 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.

M14/M8 series
MPLS TE tunnel An MPLS TE tunnel is An MPLS TE tunnel is

established through the uniquely identified by
cooperation of a series of the following
protocol components. parameters:
For details, see MPLS TE ● Tunnel interface: The
Fundamentals > interface type is
Technology Overview in "tunnel." The
the product manual. 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.

M14/M8 series
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-35, 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.

M14/M8 series
Figure 1-35 Networking diagram of interface group application
Application of 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.
In the network shown in Figure 1-36, 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.

M14/M8 series
Figure 1-36 Interface monitoring group application
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.
1.1.1.2 Interface Management Configuration

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

M14/M8 series
1.1.1.2.1 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.
NOTICE
The management network port of the main control board does not forward
services.
Interface Views and Prompts

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

M14/M8 series
Table 1-9 Commands, views, and prompts of physical interfaces supported by the
NetEngine 8100 M, NetEngine 8000E M, NetEngine 8000 M
Name ation
GE interface GE interface view Run [~HUAWEI-

inter
face
giga
bitet
hern
et
0/2/0
com
mand
in the
syste
m
view.

M14/M8 series

Name ation
10GE interface 10GE interface view Run [~HUAWEI-

inter
face
giga
bitet
hern
et
0/1/0
com
mand
in the
syste
m
view.
NOTE
The
inte
rfac
es
mar
ked
with
10G
displ
aye
d in
the
disp
lay
inte
rfac
e
brie
f
com
man
d
outp
ut
indi
cate
GE
inte
rfac
es
who
se
ban
dwi
dth
is
10
Gbit
/s.

M14/M8 series

Name ation

the
inter
face
25GE
0/2/0
com
mand
in the
syste
m
view.

the
inter
face
40GE
0/2/0
com
mand
in the
syste
m
view.

the
inter
face
100G
E
0/1/0
com
mand
in the
syste
m
view.

M14/M8 series

Name ation

the
inter
face
200G
E
0/1/0
com
mand
in the
syste
m
view.

NOTE the
NetEngine 8000 M8K or 400G
E
0/1/0
com
mand
in the
syste
m
view.
XGE interface XGE interface view Run [~HUAWEI-

the XGigabitEthernet0/1/0]
inter
face
XGig
abitE
thern
et
0/1/0
com
mand
in the
syste
m
view.

M14/M8 series

Name ation
CPOS interface CPOS interface view Run [~HUAWEI-Cpos0/3/0]

NOTE the
This interface is not contr
supported on the oller
NetEngine 8000 M4. cpos
0/3/0
com
mand
in the
syste
m
view.
POS interface POS interface view Run [~HUAWEI-Pos0/3/0]

NOTE the
NetEngine 8000 M4. pos
0/3/0
com
mand
in the
syste
m
view.

the
inter
face
50GE
0/1/0
com
mand
in the
syste
m
view.

M14/M8 series

Name ation
50|100GE 50|100GE interface view Run [~HUAWEI-50|

interface NOTE the 100GE0/1/0]
The default rate of this type inter
of interface is 50 Gbit/s and face
can be switched to 100 50|
Gbit/s.
100G
E
0/1/0
com
mand
in the
syste
m
view.

inter
face
FlexE
-50G
0/1/0
com
mand
in the
syste
m
view.

NetEngine 8000 M8K or FlexE
-100
G
0/1/0
com
mand
in the
syste
m
view.

M14/M8 series

Name ation

inter
face
FlexE
-400
G
0/1/0
com
mand
in the
syste
m
view.

NetEngine 8000 M4, FlexE
NetEngine 8000 M8K, and
-10G
0/1/0
com
mand
in the
syste
m
view.
Table 1-10 Commands, views, and prompts of logical interfaces

Name
Sub-interface Sub-interface view Run the [~HUAWEI-

interface GigabitEthernet0/1/0.1]
gigabitethern
et 0/1/0.1
command in
the system
view.
Eth-Trunk Eth-Trunk Run the [~HUAWEI-Eth-Trunk2]

interface interface view interface eth-
trunk 2
command in
the system
view.

M14/M8 series

Name
VE interface VE interface view Run the [~HUAWEI-Virtual-

interface Ethernet0/1/0]
virtual-
ethernet
0/1/0
command in
the system
view.
Global VE Global VE Run the [~HUAWEI-Global-VE0]

global-ve 0
command in
the system
view.
VLANIF VLANIF interface Run the [~HUAWEI-Vlanif2]

vlanif 2
command in
the system
view.
Loopback Loopback Run the [~HUAWEI-LoopBack2]

loopback 2
command in
the system
view.
Null interface Null interface Run the [~HUAWEI-NULL0]

view interface null
0 command in
the system
view.
IP-Trunk IP-Trunk interface Run the [~HUAWEI-Ip-Trunk2]

interface view interface ip-
trunk 2
command in
the system
view.
Tunnel Tunnel interface Run the [~HUAWEI-Tunnel 2]

tunnel 2
command in
the system
view.

M14/M8 series

Name
NVE interface NVE interface Run the [~HUAWEI-Nve1]

view interface nve
1 command in
the system
view.
FlexE FlexE interface Run the [~HUAWEI-FlexE0/2/5]

FlexE 0/2/5
command in
the system
view.
Virtual serial Virtual serial Run the [~HUAWEI-Virtual-

interface interface view interface Serial0/2/0]
Virtual-Serial
0/2/0
command in
the system
view.
PW-VE PW-VE interface Run the [~HUAWEI-pw-ve1]

interface view interface pw-
ve 1
command in
the system
view.
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.

M14/M8 series
– 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 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.

M14/M8 series
Table 1-11 Flapping control modes
control-flap Controls the frequent ● This control mode is

flappings of interfaces at interface-specific.
the network layer to ● This control mode
minimize the impact on suppresses interface
device and network flappings from the
stability. network layer and
reports the flappings
to the routing
management module,
thereby improving
network-layer
stability.
allows you to
precisely configure
parameters based on
service requirements.
involves complex
algorithms and is
highly demanding to
use.
damp-interface Controls the frequent ● This function is

flappings of interfaces at supported globally or
the physical layer to on a specified
minimize the impact on interface.
device and network ● This control mode
stability. suppresses the
flappings from the
physical layer, thereby
improving link-layer
and network-layer
stability.
prevents the upper-
layer protocols from
frequently alternating
between enabled and
disabled, thereby
reducing the
consumption of CPU
and memory
resources.
does not involve any
complex algorithms
and is easy to use.

M14/M8 series
1.1.1.2.2 Feature Requirements for Interface Management
1.1.1.2.3 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
Step 1 Run system-view
The system view is displayed.
Step 2 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.
Step 3 (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.
----End
(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).

M14/M8 series
Context
Table 1-12 describes the configurable parameters of an interface.
Table 1-12 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 You can calculate the bandwidth usage by setting the
that can be obtained interface bandwidth that can be obtained by the NMS
by the NMS through through the MIB.
the MIB
Whether the device You can enable the device to send a trap message to the
sends a trap NMS when the interface status changes. After this
message to the NMS function is enabled, the NMS monitors the interface
when the interface status in real time.
status changes 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 After setting the interval at which traffic statistics are
traffic statistics are collected for an interface, you can view the traffic
collected volumes and rates of the interface in different time
ranges.
Whether the Control-flap controls the frequency of interface status

control-flap function alternations between up and down, which minimizes the
is enabled impact on device and network stability.
NOTE
Loopback and NULL interfaces do not support the control-flap
function.
Procedure

M14/M8 series
In this command, interface-type specifies the type of the interface, and interface-
number specifies the number of the interface.
Step 3 Perform one or more operations in Table 1-13 to set the desired interface
parameters.
Table 1-13 Setting interface parameters

Operation Description
Configure a Run the description regular-expression command to

description for an configure a description for an interface.
interface.
Set an MTU for an Run the mtu mtu or ipv6 mtu mtu command to set an
interface. 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 Run the bandwidth command to set configuration

bandwidth for an bandwidth for an interface.
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 Run the enable snmp trap updown command to enable
the device sends a the device to send a trap message to the NMS when the
trap message to the interface status changes.
NMS when the NOTE
interface status If an interface alternates between up and down, the device will
changes. 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.

M14/M8 series
Operation Description
Set the interval at Run the set flow-stat interval interval command to set
which traffic the interval at which traffic statistics are collected.
statistics are NOTE
collected. ● 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- Run the control-flap [ suppress reuse ceiling decay-ok
flap function. 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 Run the signal-coding { dqpsk | qpsk } command to

to adjust the configure a modulation mode for an interface.
modulation mode of
an interface.
Step 4 Run commit
----End

M14/M8 series
Enabling an Interface
Physical interfaces on a device are initialized and started when the device is
powered on.
Context
NOTE
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:
a. Run system-view
b. Run interface interface-type interface-number
c. Run undo shutdown
The interface is started.
d. Run commit
----End
(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
Step 3 Run enable snmp trap physical-updown
The device is enabled to send a trap message to the NMS when the interface
physical status changes.
Step 4 Run commit

----End

M14/M8 series
(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
Step 3 Run statistic enable
IPv4 and IPv6 traffic statistics collection is enabled on the main interface.
Step 4 Run statistic mode forward
IPv4 and IPv6 traffic statistics collection is enabled on the main interface.
Step 5 (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.
Step 6 Run commit
----End
(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

M14/M8 series
Step 2 Perform either of the following configurations as required.

● Run the interface interface-type interface-number command to enter the
view of a specified interface.
Step 3 Run work-mode { agc agc-value | apc apc-value }
Power locking and gain locking are configured for the optical amplifier module.
Step 4 Run commit
----End
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
MP-group and global MP-group interfaces are supported.
Step 3 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.
Step 4 Run commit
----End
Configuring a Bandwidth Mode for an Interface

Different bandwidth modes can be configured for device interfaces.
Context
NOTE
This configuration applies only to the NetEngine 8000 M4.

M14/M8 series
Figure 1-37 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-37 Interface layout on a device panel
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-14 Bandwidth modes supported on interfaces 0 to 19
Bandwidth Mode Whether Whether a Breakout

Controlled by a Fiber or Breakout Box Is
License Required
1*100GE-4*GE mode (default 100GE/4*25GE No

mode). That is, interface 0 has interfaces are
100 Gbit/s bandwidth, and under license
interfaces 4, 6, 8, and 10 each control, but 1GE
have 1 Gbit/s bandwidth. interfaces are
not.
4*25GE-4*GE mode. That is, Yes
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.
4*10GE-4*10GE mode. That is, Yes. The license Yes

interface 0 is split into four 10GE needs to be
interfaces activated on
(GigabitEthernet0/5/0:0, interfaces 0 and
GigabitEthernet0/5/0:1, 4.
GigabitEthernet0/5/0:2, and
GigabitEthernet0/5/0:3), and
interfaces 4, 6, 8, and 10 each
have 10 Gbit/s bandwidth.

M14/M8 series
Bandwidth Mode Whether Whether a Breakout

Controlled by a Fiber or Breakout Box Is
License Required
1*40GE-4*10GE mode. That is, No

interface 0 has 40 Gbit/s
bandwidth, and interfaces 4, 6, 8,
and 10 each have 10 Gbit/s
bandwidth.
1*50GE-4*10GE mode. That is, Yes. The license No

interface 0 has 50 Gbit/s needs to be
bandwidth, and interfaces 4, 6, 8, activated on
and 10 each have 10 Gbit/s interfaces 0 and
bandwidth. 4.
null-4*25GE mode. That is, Yes. The license No

interface 0 does not exist, and needs to be
interfaces 4, 6, 8, and 10 each activated on
have 25 Gbit/s bandwidth. interface 4.
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
Step 2 Run license
The license view is displayed.
Step 3 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.
NOTE
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.
Step 4 Run port split dimension interface { { interface-name1 interface-type interface-

number1 } [ to { interface-name2 interface-type interface-number2 } ] } &<1–12>
split-type split-type

M14/M8 series
A bandwidth mode is configured for specified interfaces.

Step 5 Run commit
----End
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
Step 2 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.
Step 3 Run commit
----End
(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.
NOTE
In VS mode, this configuration process is supported only by the admin VS.
Procedure

M14/M8 series
Step 2 Run port split dimension interface { { interface-name1 | interface-type interface-

number1 } [ to { interface-name2 | interface-type interface-number2 } ] } &<1–
32> split-type split-type
Interface splitting is configured.
Step 3 Run commit
----End
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.
----End
1.1.1.2.4 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.

M14/M8 series
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
Step 2 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.
Step 4 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.

M14/M8 series
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.
NOTE
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.
NOTE
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
● 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

M14/M8 series
The upper and lower alarm thresholds for SDH errors as well as the
NOTE
You can run the trap-threshold slot slot-id card card-id sdh-error high-
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-
The upper and lower alarm thresholds for SDH errors as well as the
● Configure symbol alarm thresholds and a detection interval (for Ethernet
interfaces only).
– Run trap-threshold symbol-error high-threshold high-threshold low-
The upper and lower alarm thresholds for symbol errors as well as the
NOTE
You can run the trap-threshold slot slot-id card card-id symbol-error high-
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.
NOTE
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:

M14/M8 series
– 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.
Step 5 (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.
NOTE
● 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.
Step 6 Run commit

----End
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
The view of an interface is displayed.

M14/M8 series
Step 3 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.
Step 4 Run commit
----End
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
Step 3 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.
Step 4 Run commit
----End

M14/M8 series
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
Step 2 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.
Step 4 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.
Step 5 Run commit
----End

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.

M14/M8 series
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.
----End
1.1.1.2.5 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-38 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.

M14/M8 series
● 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
The user interface view is displayed.
Step 3 Run mac accounting enable
MAC accounting is enabled.
Step 4 Run commit
----End

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.
1.1.1.2.6 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.

M14/M8 series
Before configuring strict filter on an interface, configure physical attributes for
interfaces on the router.
Procedure
● Enable strict filter globally.
a. Run system-view

b. Run ethernet egress-strict-filter enable
Strict filter is enabled globally.

c. Run commit

● Enable strict filter on an EVC sub-interface.
a. Run system-view

b. Run interface interface-type interface-number.sub-interface-number
mode l2
The EVC sub-interface view is displayed.

c. Run ethernet egress-strict-filter enable
Strict filter is enabled for the EVC sub-interface.

d. Run commit
NOTE
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.
----End
1.1.1.2.7 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.

M14/M8 series
NOTE
● 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
Step 2 Run interface interface-type interface-number or controller interface-type
interface-number
The corresponding interface view is displayed.
Step 3 Run port-tx-enabling-delay port-tx-delay-time
The signal sending delay function is enabled, and the signal sending delay is
configured.
Step 4 Run commit

----End

After the configuration is complete, run the display port-tx-enabling-delay
command to check information about the signal sending delay on an interface.
1.1.1.2.8 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

M14/M8 series
Step 2 Run snmp-agent

The SNMP agent is enabled.
Step 3 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.
Step 4 Run commit
----End
1.1.1.2.9 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
Step 2 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

M14/M8 series
● PORT_1.3.6.1.4.1.2011.5.25.157.2.220
hwOutputRateChangeOverThresholdNotice
Step 3 Run commit
----End
1.1.1.2.10 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.
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
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.
Procedure
interface-number
Step 3 Perform either of the following operations:

M14/M8 series
● Configure the optical module to disable the laser automatically.

a. To configure the optical module to disable the laser automatically, run
the laser autoshutdown enable command.
b. (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.
NOTICE
Running the laser turn-off command interrupts services on the interface.

Therefore, do not run the command when the interface is working properly.
Step 4 Run commit
----End
(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

interface-number
Step 3 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.

M14/M8 series
Step 4 Run commit
----End
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.
----End
1.1.1.2.11 Configuring the Optical Module Mode of an Interface
Context
To switch the optical module mode of an interface, perform this configuration.
NOTE
Only the NetEngine 8100 M14/M8 series, NetEngine 8000E M14/M8 series, and NetEngine
8000 M14/M8/M4 series support this function.
Procedure
Step 3 Run optical-mode { osnr | hsen }
The optical module is configured to work in SNR mode or high-sensitivity mode.

M14/M8 series
Step 4 Run commit

----End
1.1.1.2.12 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.
NOTE
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
Step 2 Run optical-module alarm-threshold standardization enable
The alarm threshold standardization function is enabled for the optical module.
Step 3 Run commit
----End
1.1.1.2.13 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

M14/M8 series
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.
NOTE
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 the
alarm function for these optical modules to prevent these optical modules from frequently
reporting warnings by executing the following command.
Procedure
Step 3 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.
Step 4 Run commit
----End
1.1.1.2.14 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
Step 2 Run transceiver non-certified-alarm disable
The function of reporting an alarm for a non-Huawei-certified optical module is
disabled.

M14/M8 series
Step 3 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.
Step 4 Run commit
----End
1.1.1.2.15 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
Step 3 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.
Step 4 Run commit
----End
1.1.1.2.16 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.

M14/M8 series
Before configuring the control-flap function, configure the physical attributes for
the router interfaces.
Procedure
● Configure the control-flap function.
a. Run system-view
NOTE
The null interface and loopback interface do not support the control-flap
function.
c. 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.
d. Run commit
● Configure status flapping suppression on a physical interface.
a. Run system-view
b. (Optional) Run interface interface-type interface-number
The view of an interface is displayed.
c. Run damp-interface enable
Status flapping suppression is enabled on the interface.

M14/M8 series
d. (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.
e. (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.
f. Run commit
----End
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.
1.1.1.2.17 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.

M14/M8 series
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-15 Logical interface list

Feature Interface Name Configuration Guide
System DCN serial This interface is automatically created by

management interface the system.
Interface Virtual Ethernet Creating an L2VE Interface

management (VE) interface Creating an L3VE Interface
Interface Global VE interface Creating a Global VE Interface

management
Interface Loopback interface Creating a Loopback Interface and

management Configuring Its IP Address
Interface Null0 interface Entering the NULL Interface View

management
LAN access Ethernet sub- Configuring Ethernet Sub-interfaces to

and MAN interface Support Communication Between VLANs
access
LAN access Eth-Trunk interface Eth-Trunk Interface Configuration

and MAN
access
LAN access VLANIF interface Configuring Layer 3 Communication

and MAN Between VLANIF Interfaces
access
WAN access IP-Trunk interface Configuring an IP-Trunk Interface

NOTE
This interface is not
supported on the
NetEngine 8000
M8K or NetEngine
8000 M14K.
WAN access CPOS-Trunk Creating a CPOS-Trunk Interface

interface
WAN access MP-group interface Configuring MP
WAN access Global MP-group Creating a Global-MP-Group and Adding

interface a Trunk Serial Interface to It
WAN access IMA-group ATM IMA Configuration

interface

M14/M8 series
Feature Interface Name Configuration Guide
WAN access Global IMA-group Creating a Global-IMA-Group and

interface Adding a Trunk Serial Interface to It
MPLS Tunnel interface MPLS TE Configuration
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
Step 2 Run interface global-ve ve-number
A global VE interface is created and its view is displayed.
Step 3 Run commit
----End
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
Step 2 Run interface interface-type interface-number.subinterface-number
The view of a physical sub-interface is displayed.

M14/M8 series
Step 3 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.
Step 4 Run quit
Return to the system view.
Step 5 Run license
NOTE
The channelized sub-interface license does not need to be activated on GE interfaces.
Step 6 Run active port-slicing slot slotid card cardid port port-list
The license for channelized sub-interfaces is activated.
Step 7 Run quit
Step 8 Run interface interface-type interface-number.subinterface-number
The view of a physical sub-interface is displayed.
Step 9 Run mode channel enable
Channelization is enabled for the sub-interface.
Step 10 (Optional) Run mode channel bandwidth bwvalue
The bandwidth is configured for the channelized sub-interface.
Step 11 Run commit
----End
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

M14/M8 series
Step 2 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.
Step 3 Run ip address ip-address { mask | mask-length }
The IP address of the loopback interface is configured.
Step 4 Run commit
----End
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
Step 2 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.
----End
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.

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.

M14/M8 series
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.
----End
1.1.1.2.18 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.
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.

M14/M8 series
Before activating the FlexE interface license on a board, complete the following
tasks:
1. Run the license active file-name command to activate a specified license file
on the main control board.
2. Run the system-view command to enter the system view.
3. Run the license command to enter the license view.
Procedure
Step 2 Run license
Step 3 Run active port-slicing slot slotid card cardid port port-list
The FlexE interface license is activated on a specified board.
Step 4 Run commit
----End
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. If the Ethernet interface is an Eth-Trunk
interface's member interface, it is also deleted from the Eth-Trunk interface.
Procedure
Step 2 Run flexe enable port port-position
The working mode of the Ethernet interface is switched from standard Ethernet to
FlexE.
Step 3 Run commit
----End

M14/M8 series
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
The view of a specified FlexE physical interface (for example, FlexE-50G 0/9/1) is
displayed.
Step 3 Run phy-number phy-number
A PHY number is configured for the FlexE physical interface.
Step 4 (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.
Step 5 (Optional) Run down-filter disable
Down interrupt suppression is disabled on the FlexE physical interface.
Step 6 (Optional) Run switch-mode { manual | auto }
A switching mode is configured for the FlexE physical interface.
NOTE
This command can be run only on port 0 of a 2x50GE subcard.
Step 7 (Optional) Run port-speed { 50ge | 100ge }
A rate mode is configured for the FlexE physical interface.
NOTE
This command can be run only on port 0 of a 2x50GE subcard.
Step 8 Run commit
----End

M14/M8 series
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
Step 2 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.
Step 3 (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.
Step 4 Run binding interface interface-type interface-number
A specified FlexE physical interface is bound to the FlexE group.
Step 5 (Optional) Run padding enable
Padding is enabled.
Step 6 (Optional) Run timeslot-negotiation mode disable
Timeslot negotiation is disabled.
NOTE
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.
Step 7 Run commit
----End

M14/M8 series
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
Step 2 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.
Step 3 Run flexe-groupnum group-number
A group number is configured for the FlexE group.
Step 4 Run commit
----End
(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
Step 2 Run set flexe sub-time-slot granula slot slotid card cardid { 1g | 5g }
A sub-timeslot granularity is configured for a specified FlexE card.

M14/M8 series
Step 3 Run commit

----End
(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.
NOTE
By default, the bandwidth mode is used for a FlexE card.
Procedure
Step 2 Run slot slot-id
The slot view is displayed.
Step 3 Run flexe config-mode card cardid { bandwidth | timeslot }
The bandwidth or timeslot mode is configured for a specified FlexE card.
NOTE
This command does not apply to the NetEngine 8000 M8, NetEngine 8000 M8K, or
NetEngine 8000E M8.
Step 4 Run commit

----End
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.

M14/M8 series
Table 1-16 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 port-id Value Range
that Can Be Added to the
Same Group
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 0, 1 0-47, 1000-3000

(03033YVS)
CR5DE2NE4X14 0, 1 2-21, 1000-3000

(NetEngine 8000
M14M14K)
CR5DE2NE4X14 0 2-11, 1000-3000

(NetEngine 8000
M8M8K) 1 12-21, 1000-3000
CR8D00E2NBC1 0, 1 2-21, 1000-3000

(NetEngine 8000
M14M14K,
NetEngine 8100
M14M14K)
CR8D00E2NBC1 0 2-11, 1000-3000

(NetEngine 8000
M8M8K, 1 12-21, 1000-3000
NetEngine 8100
M8M8K)
CR8D00E2VBK1 0, 1 129-148, 1000-3000

(NetEngine 8000
M8KM14K)

M14/M8 series

Same Group
CR8D00E1NBC1 0, 1 129-148, 1000-3000

(NetEngine 8000
M8M14,
NetEngine 8100
M8M14)
(03033MNV)
CR8D00E2VBC1 0, 1 129-148, 1000-3000

(NetEngine 8000
M8M14,
NetEngine 8100
M8M14)
CR8D00E1NBC4 0 1000-3000
(NetEngine 8000
M8M14,
NetEngine 8100
M8M14)
DPE1E4NBIYFS 0, 2 1000-3000
(NetEngine 8000
M4) 1, 3 1000-3000
DPE1E4NBIYFS 0, 2 1000-3000
(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 0, 2 1000-3000
(NetEngine 8000
M4) 1, 3 1000-3000
CR8PM4BASDC3 0, 2 1000-3000
(NetEngine 8000
M4) 1, 3 1000-3000
CR8PM4BASAC2 0, 2 1000-3000
(NetEngine 8000
M4) 1, 3 1000-3000

M14/M8 series

Same Group
CR8PM4BASAC3 0, 2 1000-3000
(NetEngine 8000
M4) 1, 3 1000-3000
CR8PM4BASDC6 0, 2 1000-3000
(NetEngine 8000
M4) 1, 3 1000-3000
CR8PM4BASDC7 0, 2 1000-3000
(NetEngine 8000
M4) 1, 3 1000-3000
CR8PM4BASAC6 0, 2 1000-3000
(NetEngine 8000
M4) 1, 3 1000-3000
CR8PM4BASAC7 0, 2 1000-3000
(NetEngine 8000
M4) 1, 3 1000-3000
CR8DE1N8XFM0 0 1000-3000
Procedure
Step 2 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.
Step 3 Run flexe-clientid clientid
An ID is configured for the FlexE client.
Step 4 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.
Step 5 (Optional) Run minimal available bandwidth percent
The minimum available bandwidth percentage is configured for the FlexE client.
Step 6 Run commit

M14/M8 series
----End
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-39, 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-39 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.
a. Run the force-physical-mode ethernet command to forcibly switch the
underlying working mode of the FlexE physical interface to standard
Ethernet.
NOTE
By default, the underlying working mode of a FlexE physical interface

automatically switches from standard Ethernet back to FlexE after 20 minutes.
b. 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:

M14/M8 series
▪ 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
Step 1 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.
Step 2 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.
NOTE
In the preceding scenarios, the operations on DeviceB are the same as those on DeviceA.
----End
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.

M14/M8 series
Usage Scenario
● Adding a FlexE NE to a live network running FlexE services
As shown in Figure 1-40, DeviceA and DeviceB work in FlexE mode on the live
network, and the new NE DeviceC also works in FlexE mode.
Figure 1-40 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-41, DeviceA and DeviceB work in FlexE mode on the live
network, and the new NE DeviceC works in Ethernet mode.
Figure 1-41 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.
NOTE
In the following scenarios, the operations on DeviceB are the same as those on
DeviceA.

M14/M8 series
Procedure
● If DeviceA supports DCN auto-negotiation on FlexE physical interfaces, but
DeviceC does not:
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.
i. Run the system-view command to enter the system view.
ii. 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).
iii. Run the force-physical-mode ethernet command to forcibly switch
the underlying working mode of the FlexE physical interface to
standard Ethernet.
NOTE
By default, the underlying working mode of a FlexE physical interface

automatically switches from standard Ethernet back to FlexE after 20
minutes.
iv. 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:
a. 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.

M14/M8 series
b. 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.
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:
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:
a. 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.
b. Run the undo force-physical-mode command on DeviceA to restore the
underlying working mode of the FlexE physical interface to FlexE.
c. 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:

M14/M8 series
▪ 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.
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.
----End
(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.
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
The view of a specified FlexE physical interface (for example, FlexE-50G 0/1/0) is
displayed.
Step 3 Run clock binding flexe interface iftype ifnum
A specified FlexE interface carrying clock services is bound to the FlexE physical
interface.
Step 4 Run commit

M14/M8 series
----End

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.
----End
1.1.1.2.19 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.

M14/M8 series
● 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.
a. Run system-view

b. Run port-group port-group-name
A permanent interface group is created and the view of the permanent

interface group is displayed.
c. Run group-member { interface-type interface-number1 [ to interface-
type interface-number2 ] } &<1-10>
Specified interfaces are added to the permanent interface group.
d. Run commit

● Configure a temporary interface group.
a. Run system-view

b. 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.
NOTE
● 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.
c. Run commit
----End

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.
1.1.1.2.20 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.

M14/M8 series
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-42, 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-42 Typical application of an interface monitoring group

M14/M8 series
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.
Before configuring an interface monitoring group, configure physical attributes for
interfaces on the router.
Procedure
Step 2 Run monitor-group monitor-group-name
An interface monitoring group is created, and the interface monitoring group view
is displayed.
Step 3 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.
Step 4 Run quit
Exit from the interface monitoring group view.
The view of the specified interface on the user side is displayed.
Step 6 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

M14/M8 series
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.
Step 7 Run quit
Exit from the interface view.
Step 8 Run monitor-group monitor-group-name
The view of the created interface monitoring group is displayed.
Step 9 (Optional) Run trigger-up-delay trigger-up-delay-value
The delay after which a track interface goes Up is set.
Step 10 Run monitor enable
The monitoring function is enabled.
Step 11 Run commit
----End

Run the display monitor-group [ monitor-group-name ] command to view
information about an interface monitoring group.
1.1.1.2.21 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
NOTICE
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.
----End

M14/M8 series
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.
----End
1.1.1.2.22 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

M14/M8 series
Configuration Roadmap
The configuration roadmap is as follows:
1. Configure a description for an interface.
2. Set an MTU for the interface to ensure successful packet transmission over
the interface.
3. Set the interval at which traffic statistics (including the traffic volumes and
rates) are collected globally.
4. 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
Step 1 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
Step 2 Set an MTU for the interface.

[~HUAWEI-GigabitEthernet0/2/0] mtu 1000
[*HUAWEI-GigabitEthernet0/2/0] commit
[~HUAWEI-GigabitEthernet0/2/0] quit
Step 3 Set the interval at which traffic statistics are collected globally.
[~HUAWEI] set flow-stat interval 100
[*HUAWEI] commit
Step 4 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
----End
Configuration Files
#
set flow-stat interval 100
#
interface Gigabitethernet0/2/0
description for IFM
mtu 1000
#
interface Gigabitethernet0/2/0.1
mtu 800
#

M14/M8 series
return
Example for Configuring FlexE Interfaces

This section provides an example for configuring interfaces on two devices that
are connected using FlexE.
On the network shown in Figure 1-43, 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-43 Networking diagram for configuring FlexE interfaces

NOTE
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.
1. Activate the FlexE interface license on a board.
2. Configure a standard Ethernet interface to work in FlexE mode.
3. Configure a PHY number for a FlexE physical interface.
4. Create a FlexE group and bind the FlexE physical interface to it.

M14/M8 series
5. Configure a number for the FlexE group.

6. Configure a sub-timeslot granularity for a FlexE card.
7. Create a FlexE client and configure an ID and bandwidth for it.
8. Configure an IP address for each interface.
Data Preparation
● 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
Step 1 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
Step 2 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
Step 3 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
Step 4 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
Step 5 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
Step 6 Configure a sub-timeslot granularity for a FlexE card.

[~DeviceA] set flexe sub-time-slot granula slot 9 card 9 1g
[*DeviceA] commit
Step 7 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

M14/M8 series
[*DeviceA-flexe-client-1] flexe-bandwidth 4
[*DeviceA-flexe-client-1] commit
[~DeviceA-flexe-client-1] quit
Step 8 Configure an IP address for each interface. For configuration details, see
Configuration Files in this section.
Step 9 Repeat the preceding steps on DeviceB. For configuration details, see
Configuration Files in this section.
Step 10 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

M14/M8 series
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 -- -- --

M14/M8 series
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
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%
----End
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

M14/M8 series
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-clientid 2
flexe-bandwidth 5
#
flexe-clientid 3
flexe-bandwidth 15
#
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-clientid 1
flexe-bandwidth 4
#
flexe-clientid 2
flexe-bandwidth 5
#
flexe-clientid 3
flexe-bandwidth 15
#
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
1.1.2 Transmission Alarm Customization and Suppression

Configuration

M14/M8 series
1.1.2.1 Transmission Alarm Customization and Suppression Feature

Description
1.1.2.1.1 Overview of Transmission Alarm Customization and Suppression
Definition
Currently, carrier-class networks require high reliability for IP devices. As such,
devices on the networks are required to rapidly detect faults. After fast detection is
enabled on an interface, the alarm reporting speed is accelerated. As a result, the
physical status of the interface frequently alternates between up and down,
causing frequent network flapping. Therefore, alarms must be filtered and
suppressed to prevent frequent network flapping.
Transmission alarm suppression can efficiently filter and suppress alarm signals to
prevent interfaces from frequently flapping. In addition, transmission alarm
customization can control the impact of alarms on the interface status.
Transmission alarm customization and suppression provide the following

functions:
● Transmission alarm customization allows you to specify alarms that can cause
the physical status of an interface to change. This function helps filter out
unwanted alarms.
● Transmission alarm suppression allows you to suppress frequent network
flapping by setting thresholds and using a series of algorithms.
Purpose
Transmission alarm customization allows you to filter unwanted alarms, and
transmission alarm suppression enables you to set thresholds on customized
alarms, allowing devices to ignore burrs generated during transmission link
protection and preventing frequent network flapping.
On a backbone or metro network, IP devices are connected to transmission

devices, such as Synchronous Digital Hierarchy (SDH), Wavelength Division
Multiplexing (WDM), or Synchronous Optical Network (SONET) devices. If a
transmission device becomes faulty, the interconnected IP device receives an
alarm. The transmission devices then perform a link switchover. After the link of
the transmission device recovers, the transmission device sends a clear alarm to
the IP device. After an alarm is generated, a link switchover lasts 50 ms to 200 ms.
In the log information on IP devices, the transmission alarms are displayed as
burrs that last 50 ms to 200 ms. These burrs will cause the interface status of IP
devices to switch frequently. IP devices will perform route calculation frequently.
As a result, routes flap frequently, affecting the performance of IP devices.
From the perspective of the entire network, IP devices are expected to ignore such
burrs. That is, IP devices must customize and suppress the alarms that are
generated during transmission device maintenance or link switchovers. This can
prevent route flapping. Transmission alarm customization can control the impact
of transmission alarms on the physical status of interfaces. Transmission alarm
suppression can efficiently filter and suppress specific alarm signals to avoid
frequent interface flapping.

M14/M8 series
During the active/standby switchover, various transmission alarm signals can be

processed properly, and the transmission alarm configuration still takes effect.
1.1.2.1.2 Principles of Transmission Alarm Customization and Suppression
Basic Concepts
Network Flapping
Network flapping occurs when the physical status of interfaces on a network
frequently alternates between Up and Down.
Alarm Burrs
An alarm burr is a process in which alarm generation and alarm clearance signals
are received in a short period (The period varies with specific usage scenarios,
devices, or service types).
For example, if a loss of signal (LOS) alarm is cleared 50 ms after it is generated,

the process from the alarm generation to clearance is an alarm burr.
Alarm Flapping
Alarm flapping is a process in which an alarm is repeatedly generated and cleared
in a short period (The period varies with specific usage scenarios, devices, or
service types).
For example, if an LOS alarm is generated and cleared 10 times in 1s, alarm
flapping occurs.
Key Parameters in Flapping Suppression

● figure of merit: stability value of an alarm. A larger value indicates a less
stable alarm.
● penalty: penalty value. Each time an interface receives an alarm generation
signal. Each time an interface receives an alarm clearance signal, the figure
of merit value decreases exponentially.
● suppress: alarm suppression threshold. When the figure of merit value
exceeds this threshold, alarms are suppressed. This value must be smaller
than the ceiling value and greater than the reuse value.
● ceiling: maximum value of figure of merit. When an alarm is repeatedly
generated and cleared in a short period, figure of merit significantly
increases and, therefore, takes a long time to return to reuse. To avoid long
delays returning to reuse, a ceiling value can be set to limit the maximum
value of figure of merit. The figure of merit value does not increase when it
reaches the ceiling value.
● reuse: alarm reuse threshold. When this value is greater than that of figure
of merit, alarms are not suppressed. This value must be smaller than the
suppress value.
● half-time: time used by figure of merit of suppressed alarms to decrease to
half.

M14/M8 series
● decay-ok: time used by figure of merit to decrease to half when an alarm

clearance signal is received.
● decay-ng: time used by figure of merit to decrease to half when an alarm
generation signal is received.
Transmission Alarm Processing

Transmission alarms are processed as follows:
1. After a transmission device generates alarms, it determines whether to report
the alarms to its connected IP device based on the alarm types.
– If the alarms are b3tca, sdbere, or sfbere, the transmission device
determines whether the alarm threshold is reached.
If the threshold is reached, the transmission device reports the alarms to
the IP devices for processing.
If the threshold is not reached, the transmission device ignores these
alarms.
– For all other alarms, they are directly reported to the IP device for
processing.
2. If the recording function is enabled on the IP device, the alarms are recorded.
3. The IP device determines whether to change the physical status of the
interface based on customized alarm types.
– If no alarm types are customized to affect the physical status of the
interface, these alarms are ignored. The physical status of the interface
remains unchanged.
– If an alarm type is customized to affect the physical status of the
interface, the alarm is processed based on the transmission alarm
customization mechanism.
Transmission Alarm Customization Mechanism

When a transmission device reports alarm signals to an IP device, the IP device
determines whether to change the physical status of its interface based on the
transmission alarm customization function.
● When a certain type of alarms is customized to affect the interface status but
transmission alarm filtering or suppression is not configured:
– The physical status of the interface changes to Down if such an alarm is
generated
– The physical status of the interface changes to Up if such an alarm is
cleared.
● If a certain type of alarms is customized to affect the interface status and
transmission alarm filtering or suppression is configured, the IP device
processes the alarm according to the filtering mechanism or suppression
parameters.
Transmission Alarm Filtering Mechanism

Transmission alarm filtering enables an IP device to determine whether an alarm
signal is a burr.

M14/M8 series
If the interval between an alarm signal generation and clearance is smaller than
the filtering timer value, this alarm signal is considered a burr.
● If the alarm signal is a burr, it is ignored. The physical status of the interface
remains unchanged.
● If the alarm signal is not a burr:
– The physical status of the interface changes to Down if the signal is an
alarm generation signal.
– The physical status of the interface changes to Up if the signal is an
alarm clearance signal that is not suppressed.
Transmission Alarm Suppression Mechanism

Transmission alarm suppression enables an IP device to determine how to process
an alarm signal.
● When an alarm's figure of merit is smaller than suppress:
– If no alarm generation or clearance signal is received, figure of merit
decreases with time.
– If an alarm generation signal is received, the physical status of the
interface changes to Down, and figure of merit increases by the penalty
value.
– If an alarm clearance signal is received, the physical status of the
interface changes to Up, and figure of merit decreases exponentially.
● When an alarm's figure of merit reaches suppress, this alarm is suppressed.
The generation or clearance signal of this alarm does not affect the physical
status of the interface.
● When an alarm is frequently generated, figure of merit reaches ceiling. It
does not increase even if new alarm signals arrive. If no alarm signals arrive,
figure of merit decreases with time.
● When an alarm's figure of merit decreases to reuse, this alarm is free from
suppression.
After the alarm is free from suppression, the process repeats if this alarm is
generated again.

M14/M8 series
Figure 1-44 Alarm suppression attenuation
Figure 1-44 shows the correlation between a transmission device sending alarm
generation signals and how figure of merit increases and decreases.
1. At t1 and t2, figure of merit is smaller than suppress. Therefore, alarm
signals generated at t1 and t2 affect the physical status of the interface, and
the physical status of the interface changes to Down.
2. At t3, figure of merit exceeds suppress, and the alarm is suppressed. The
physical status of the interface is not affected, even if new alarm signals
arrive.
3. At t4, figure of merit reaches ceiling. If new alarm signals arrive, figure of
merit is recalculated but does not exceed ceiling.
4. At t5, figure of merit falls below reuse, and the alarm is free from
suppression.
1.1.2.1.3 Terms and Abbreviations for Transmission Alarm Customization and

Suppression
Terms
None
Acronyms and Abbreviations

Acronym and Full Name
Abbreviation
SDH Synchronous Digital Hierarchy
SONET Synchronous Optical Network
VRP Versatile Routing Platform

M14/M8 series
1.1.2.2 Transmission Alarm Customization and Suppression Configuration

Transmission alarm customization and suppression can reduce the impact of
transmission alarms on network stability.
1.1.2.2.1 Overview of Transmission Alarm Customization and Suppression

Transmission alarm customization can control the impact of alarms on interface
status. Transmission alarm suppression can efficiently suppress alarms, which
prevents interfaces from frequently flapping.
Definition
Currently, carrier-class networks require high reliability for IP devices. As such,
devices on the networks are required to rapidly detect faults. After fast detection is
enabled on an interface, the alarm reporting speed is accelerated. As a result, the
physical status of the interface frequently alternates between up and down,
causing frequent network flapping. Therefore, alarms must be filtered and
suppressed to prevent frequent network flapping.
Transmission alarm suppression can efficiently filter and suppress alarm signals to
prevent interfaces from frequently flapping. In addition, transmission alarm
customization can control the impact of alarms on the interface status.
Transmission alarm customization and suppression provide the following

functions:
● Transmission alarm customization allows you to specify alarms that can cause
the physical status of an interface to change. This function helps filter out
unwanted alarms.
● Transmission alarm suppression allows you to suppress frequent network
flapping by setting thresholds and using a series of algorithms.
Purpose
Transmission alarm customization allows you to filter unwanted alarms, and
transmission alarm suppression enables you to set thresholds on customized
alarms, allowing devices to ignore burrs generated during transmission link
protection and preventing frequent network flapping.
On a backbone or metro network, IP devices are connected to transmission

devices, such as Synchronous Digital Hierarchy (SDH), Wavelength Division
Multiplexing (WDM), or Synchronous Optical Network (SONET) devices. If a
transmission device becomes faulty, the interconnected IP device receives an
alarm. The transmission devices then perform a link switchover. After the link of
the transmission device recovers, the transmission device sends a clear alarm to
the IP device. After an alarm is generated, a link switchover lasts 50 ms to 200 ms.
In the log information on IP devices, the transmission alarms are displayed as
burrs that last 50 ms to 200 ms. These burrs will cause the interface status of IP
devices to switch frequently. IP devices will perform route calculation frequently.
As a result, routes flap frequently, affecting the performance of IP devices.
From the perspective of the entire network, IP devices are expected to ignore such
burrs. That is, IP devices must customize and suppress the alarms that are

M14/M8 series
generated during transmission device maintenance or link switchovers. This can

prevent route flapping. Transmission alarm customization can control the impact
of transmission alarms on the physical status of interfaces. Transmission alarm
suppression can efficiently filter and suppress specific alarm signals to avoid
frequent interface flapping.
During the active/standby switchover, various transmission alarm signals can be

processed properly, and the transmission alarm configuration still takes effect.
1.1.2.2.2 Feature Requirements for Transmission Alarm Customization and

Suppression
1.1.2.2.3 Configuring Transmission Alarm Customization

This section describes the usage scenario, pre-configuration tasks, and data
preparation for transmission alarm customization.
Usage Scenario
In the scenario where transmission devices are connected to IP devices, if the
network is unstable, a large number of burr alarms will be generated. As a result,
the physical status of interfaces on the transmission devices will switch between
Up and Down. To enable IP devices to ignore these burrs, configure transmission
alarm customization on the IP devices.
Before configuring the transmission alarm customization function, power on the
router and ensure that it is working properly.
Configuring the Types of Alarms that Affect the Physical Status of Interfaces
In the scenario where a router is connected to a transmission device, if the
network is unstable, a large number of burr alarms may be generated. As a result,
the physical status of interfaces will frequently change between up and down. To
specify the alarms that can trigger the physical status of an interface to go down,
you can configure transmission alarm customization.
Context
Transmission alarm customization can be used to control the impact of
transmission alarms on the physical interface status. Perform the following steps
globally or on the interface connected to a transmission device:
Transmission alarm filtering intervals can be configured globally or on an

interface. The global configuration takes effect on interfaces supporting the
function. The relationship is as follows:
● If the alarm customization is configured globally and a non-default alarm
customization configuration exists on an interface, the configuration on the
interface preferentially takes effect.
● If the alarm customization is configured globally but is not configured on an
interface, the global configuration takes effect on the interface.

M14/M8 series
NOTE
In VS mode, global transmission alarm customization is supported only by the admin VS.
Procedure
● Configure transmission alarm customization globally.
a. Run system-view
b. Run transmission-alarm down { wan | pos } { auais | b1tca | b2tca |
b3tca | lais | lcd | lof | lom | lop | los | lrdi | lrei | oof | pais | pplm | prdi |
prei | puneq | rdool | rrool | sdbere | sfbere | trool } *
The types of transmission alarms whose generation causes 10GE WAN
and POS interfaces to go down physically are customized globally.
c. Run commit
● Configure transmission alarm customization on an interface.
a. Run system-view
b. Run interface interface-type interface-number or controller interface-
type interface-number
c. Run the following commands as required:
▪ To customize the types of transmission alarms whose generation

causes the POS or 10GE WAN interface to go down physically, run
the transmission-alarm down { auais | b1tca | b2tca | b3tca | lais |
lcd | lof | lom | lop | los | lrdi | lrei | oof | pais | pplm | prdi | prei |
puneq | rdool | rrool | sdbere | sfbere | trool } * command.

causes the WDM interface to go down physically, run the
transmission-alarm down { odu-ais | odu-lck | odu-oci | otu-ais |
otu-lom | otu-sd-ber | otu-sf-ber | pm-bdi | pm-tim | r-lof | r-los |
r-oof | sm-bdi | sm-iae | sm-tim | prefec-tca | local-fault | remote-
fault } * command.

causes the CPOS interface to go down physically, run the
transmission-alarm down { los | lof | oof | lais | lrdi | lrei | b1tca |
b2tca | b3tca | sdbere | sfbere | rrool | pais | auais | prdi | prei | lop
| pplm | puneq | lom } * command.

causes the E1 interface to go down physically, run the transmission-
alarm down { lof | los | pais | prdi } * command.

causes the trunk serial interface or serial interface to go down

M14/M8 series
physically, run the transmission-alarm down { pais | prdi | oof } *
command.
NOTE
● Not all interfaces support the preceding alarms because the alarm types
supported may vary with subcards. If you attempt to customize an alarm type
that is not supported by an interface for the interface, the customization fails,
and a message is displayed, telling you which alarm types are not supported
by this interface.
● WLNK alarms can be viewed only and cannot be customized. The WLNK
alarms are always enabled, and their generation causes interfaces to go down
physically. To view the status and statistics on WLNK alarms, run the display
transmission-alarm command.
NOTICE
By default, the LAIS, LOF, and LOS alarms can change interface status. If
these alarms are disabled, forwarding of service data may be adversely
affected. Therefore, you are advised to keep these alarms enabled.
d. Run commit
----End
(Optional) Configuring b1tca, b2tca, b3tca, sdbere, and sfbere Alarm Thresholds
The b1tca, b2tca, b3tca, sdbere, and sfbere alarm thresholds can be configured. An
alarm is reported only when the threshold is reached.
Context
Perform the following steps on the interface that is connected to the transmission
device:
Procedure
interface-number
Step 3 Run transmission-alarm threshold { b1tca b1tca | b2tca b2tca | b3tca b3tca |
sdbere sdbere | sfbere sfbere } *
The thresholds for reporting the b1tca, b2tca, b3tca, sdbere, and sfbere alarms are
configured.
The alarm thresholds are in the format of 10-n, where n is specified in the
corresponding alarm parameter in the transmission-alarm threshold command.
The value of sdbere must not be less than that of sfbere.

M14/M8 series
Step 4 Run commit
----End
Verifying the Transmission Alarm Customization Configuration

After configuring transmission alarm customization, verify the configuration and
check the alarm status and statistics on an interface.
Prerequisites
Transmission alarm customization has been configured. The transmission alarm
suppression function has been enabled using the transmission-alarm damping
command.
Procedure
● To check the alarm configuration on a POS or 10GE WAN interface, run the
display transmission-alarm { pos | wan } interface-number [ auais | b1tca |
b2tca | b3tca | lais | lcd | lof | lom | lop | los | lrdi | lrei | oof | pais | prdi |
prei | pplm | puneq | rdool | rrool | sdbere | sfbere | trool | wlnk ] *
command.
● To check the alarm configuration on a WDM interface, run the display
transmission-alarm wdm interface-number [ odu-ais | odu-lck | odu-oci |
otu-ais | otu-lom | otu-sd-ber | otu-sf-ber | pm-bdi | pm-tim | r-lof | r-los |
r-oof | sm-bdi | sm-iae | sm-tim | prefec-tca | odu-sd-ber ] * command.
● To check the alarm configuration on an E1 interface, run the display
transmission-alarm e1 interface-number [ los | lof | pais | prai ] * command.
● To check the alarm configuration on a CPOS interface, run the display
transmission-alarm cpos interface-number [ auais | b1tca | b2tca | b3tca |
lais | lof | lom | lop | los | lrdi | lrei | oof | pais | pplm | prdi | prei | puneq |
rrool | sdbere | sfbere ] command.
----End
1.1.2.2.4 Configuring Transmission Alarm Filtering Intervals

This section describes the usage scenario of transmission alarm filtering intervals,
and the pre-configuration tasks and operation procedure for configuring the
transmission alarm filtering intervals. If the lifetime (interval between alarm
generation and alarm clearance) of an alarm is less than the generation alarm
filtering interval, the alarm is filtered out as a burr. Otherwise, the alarm is
considered as a normal alarm.
Usage Scenario
the physical status of interfaces will frequently change between up and down. If a
transmission alarm filtering interval is configured, the alarms whose lifetime is
shorter than the interval will be ignored.

M14/M8 series
Transmission alarm filtering intervals can be configured globally or on an

interface. The global configuration takes effect on interfaces supporting the
function. The relationship is as follows:
● If a transmission alarm filtering interval is configured globally and a non-
default transmission alarm filtering interval is configured on an interface, the
configuration on the interface preferentially takes effect.
● If no transmission alarm filtering interval is configured in the interface view,
the global configuration takes effect.
NOTE
In VS mode, global transmission alarm filtering intervals are supported only by the admin
VS.
Before configuring transmission alarm filtering intervals, complete the following
tasks:
● Power on the router and ensure that the router passes the self-check.
● Configure transmission alarm customization on the router's interface
connected to the transmission device by referring to 1.1.2.2.3 Configuring
Transmission Alarm Customization.
NOTE
The alarm filtering function on an interface takes effect only after transmission alarm
customization is configured on the interface.
Procedure
● Enable the global alarm filtering function and set global generation and
clearance alarm filtering intervals.
a. Run system-view
b. Run transmission-alarm holdup-timer holdup-time
Clearance alarm filtering is enabled globally, and an interval for filtering
clearance alarms is configured globally.
c. Run commit
● Configure the alarm filtering function on an interface and set generation and
clearance alarm filtering intervals for the interface.
a. Run system-view
b. Run the following commands as required:
▪ To enter the POS or 10GE WAN interface view, run the interface
interface-type interface-number command.
▪ To enter the CPOS interface view, run the controller cpos cpos-
number command.

M14/M8 series
▪ To enter the WDM interface view, run the controller wdm controller-
number command.
▪ To enter the E1 interface view, run the controller e1 controller-

number command.
c. Run transmission-alarm holdup-timer [ holdup-time ]
The clearance alarm filtering function is configured on the interface, and

a clearance alarm filtering interval is set for the interface.
d. Run commit
----End

After the configuration is complete, run the display transmission-alarm
command to check the interface configuration.
1.1.2.2.5 Configuring Transmission Alarm Suppression

This section describes the usage scenario, pre-configuration tasks, and
configuration procedure for transmission alarm suppression. If a transmission
alarm suppression threshold is configured, an alarm is reported only when the
threshold is reached.
Usage Scenario
the physical status of interfaces will frequently change between up and down. To
prevent these alarms from frequently flapping or configure the device to ignore
these burr alarms, you need to enable transmission alarm suppression.
Before configuring transmission alarm suppression, complete the following tasks:
● Power on the router and ensure that the router passes the self-check.
● Configure transmission alarm customization on the router's interface
connected to the transmission device by referring to 1.1.2.2.3 Configuring
Transmission Alarm Customization.
NOTE
Transmission alarm suppression takes effect on an interface only after transmission alarm
customization is configured on the interface.
Procedure

M14/M8 series
Step 2 Run the following commands as required:

1. To enter the POS or 10GE WAN interface view, run the interface interface-
type interface-number command.
2. To enter the CPOS interface view, run the controller cpos cpos-number
command.
3. To enter the WDM interface view, run the controller wdm interface-number
command.
4. To enter the E1 interface view, run the controller e1 controller-number
command.
Step 3 Run transmission-alarm damping [ ceiling ceiling | reuse reuse | suppress

suppress | decay-ok decay-ok | decay-ng decay-ng ] *
Transmission alarm suppression is enabled, and suppression parameters are set.
Step 4 Run commit
----End

After configuring transmission alarm suppression, verify the configuration.
Run the display transmission-alarm configuration command to check the

transmission alarm configuration on an interface.
1.1.2.2.6 Maintaining Transmission Alarm Customization and Suppression

This section describes how to check bit error rates and how to clear information
about transmission alarms.
Checking Bit Error Rates

When a bit error rate alarm is generated and the device sets the interface to
down, you can query the current bit error rates.
Procedure
● To query the current bit error rates of an interface, run the display
transmission-alarm bit-error-rate command in any view.
----End
Clearing the Information About Transmission Alarms

Before re-collecting information about transmission alarms on an interface, clear
the existing information about transmission alarms on the interface.

M14/M8 series
Context
NOTICE
After information about transmission alarms has been cleared, all statistics on
alarms will be reset. Exercise caution when running the reset transmission-alarm
statistics command.
Procedure
● To clear the information about transmission alarms on an interface, run the
reset transmission-alarm statistics command in the interface view.
----End
1.1.3 Port Extension Configuration
1.1.3.1 Port Extension Feature Description

NOTE
Currently, devices are used as masters and APs in a port extension system.
1.1.3.1.1 Overview of Port Extension
Definition
On an IP core network, to meet more and more service deployment requirements
on the access and network sides, PE devices need to provide high-density Ethernet
interfaces. To enable a device to provide high-density Ethernet interfaces without
increasing investments, Huawei implements port extension.
On the network shown in Figure 1-45, port extension enables a device with higher
performance to be configured as a master and a large number of low-end devices
that support Ethernet interfaces to be configured as APs. The APs' Ethernet
interfaces are then mapped to the master's port extension interfaces, so that the
master provides high-density Ethernet interfaces. Services only need to be
configured on the master's port extension interfaces.
● AP: an access node in a port extension system. An AP can be considered as a
master's board and is automatically discovered and managed by a master. An
AP receives configuration and forwarding entries delivered by a master and
provides external communication interfaces.
● Master: a control node in a port extension system. A master establishes a
tunnel, delivers services, controls traffic, and manages connected APs.
NOTE
Ensure that the software versions running on the master and APs are the same. If the
software versions are inconsistent, services may be unavailable after the APs go online.

M14/M8 series
Figure 1-45 Conceptual graph of port extension
Related Concepts
The following table describes basic concepts involved in port extension.
Concept Description
Internal An interface for connecting a master and AP. Port extension is

communicatio enabled on this interface.
n interface
External An interface through which an AP connects to an outside

communicatio network. This interface has the corresponding port extension
n interface interface on a master.
Port extension A virtual mapping interface that a master establishes for an

interface AP's external communication interface. A port extension
interface on a master corresponds to an external
communication interface on an AP.

M14/M8 series
Figure 1-46 Port extension system
Benefits
Port extension offers the following benefits:
● Reduced network construction costs
A master uses fewer slots to provide high-density Ethernet interfaces. Port
extension ensures that the existing devices that support Ethernet interfaces
are fully used (as APs) and prevents a large number of devices that support
Ethernet interfaces from being purchased, significantly reducing network
construction costs.
● Reduced network O&M costs
The control and management planes are centralized on a master, and services
are configured and queried on a master or network management system
(NMS). Therefore, customers do not need to configure or manage services on
APs, which significantly reduces network O&M costs.
1.1.3.1.2 Features Supported of Port Extension
Feature Description
AP plug-and-play A master automatically detects and manages APs

when APs go online, go offline, migrates, or restarts or
when the master restarts.
Internal trunk interface To increase the bandwidth or improve reliability, you

can configure Eth-Trunk interfaces between a master
and AP as internal trunk interfaces.
Port extension trunk To configure Eth-Trunk for an AP's external

interface communication interface, add the port extension
interface for the external communication interface to
a common Eth-Trunk interface as a port extension
trunk interface on a master.

M14/M8 series
Feature Description
Alarm and log A master and AP record their own alarm information
management in a port and independently send the alarm information to a
extension system network management system (NMS).
A syslog server can be specified on a master. A master
and AP record their own log information and
independently send the log information to the
specified syslog server.
1.1.3.1.3 Understanding Port Extension
Control Plane
The control plane of a port extension system is responsible for control channel and
internal forwarding channel.
Control Channel
In a port extension system, a control channel is established between an AP and
master. As shown in Figure 1-47, through the control channel:
● The master delivers forwarding entries to the AP, implementing data

transmission between the master and AP.
● The AP reports to the master an external communication interface's attributes
(including the physical and protocol states, MAC address, and bandwidth of
the interface). The attributes can be queried on the corresponding port
extension interface on the master.
Figure 1-47 Control channel

M14/M8 series
Internal Forwarding Channel

An internal forwarding channel must be established for a port extension system to
forward service traffic. An internal forwarding channel is established through
configuration. On the network shown in Figure 1-48, bind the internal
communication interfaces of the master and AP, and then bind the master's
internal communication interface and the AP's external communication interface.
After the configuration is complete, the master creates a port extension interface
for the AP's external communication interface. The system establishes a
bidirectional channel along the path: AP's external communication interface ->
AP's internal communication interface -> master's internal communication
interface -> master's port extension interface. The system automatically allocates
a label (called the NVTAG) to the channel. Packets transmitted within the channel
carry the NVTAG for packet identification.
Figure 1-48 Internal forwarding channel
Forwarding Plane
On the forwarding plane of a port extension system, an AP uses the internal
forwarding channel to send packets received from an external communication
interface to a master. The AP also receives packets from the master through the
internal forwarding channel and sends them through an external communication
interface. The AP is only responsible for data forwarding, and services are
processed on the master's port extension interface.
On the network shown in Figure 1-49, after the control plane is configured, the
master's port 1-1 becomes an internal communication interface, the AP2000's port
1 becomes an internal communication interface, and the AP2000's ports 2 to 4
become external communication interfaces. The master creates three port
extension interfaces port 2000-2, port 2000-3, and port 2000-4 for the AP2000's
three external communication interfaces. The master allocates three NVTAGs to
the AP2000's three external communication interfaces. The master and AP deliver
NVTAGs through forwarding entries. The master's forwarding entries record the
relationships among internal communication interfaces, port extension interfaces,
and NVTAGs. The AP's forwarding entries record the relationships among internal
communication interfaces, external communication interfaces, and NVTAGs.

M14/M8 series
After receiving a data packet from an external communication interface (for

example, port 2), the AP adds an NVTAG (for example, NVTAG2) to the packet
based on forwarding entries, and then forwards the packet to the AP's internal
communication interface port 1. The packet is finally transmitted to the master's
internal communication interface port 1-1. Based on the internal communication
interface of the packet and NVTAG2 carried in the packet, the master can find a
uniquely determined port extension interface (port 2000-2). The master forwards
the packet based on services configured on the port extension interface. The
transmission process for a master-to-AP data packet is similar to that for an AP-
to-master data packet.
Figure 1-49 Data forwarding in a port extension system
AP PnP
In AP plug-and-play (PnP) mode, a master automatically detects and manages
APs when APs go online, go offline, migrate, or restart or when the master
restarts. The port extension system supports AP PnP, which simplifies network
O&M and management. AP PnP involves the following processes:
● An AP Goes Online for the First Time

● An AP Restarts and Goes Online
● The Master Restarts
● An AP Goes Offline
● An AP Migrates
The following describes the AP PnP processes.
An AP Goes Online for the First Time

Figure 1-50 shows the PnP process after an AP goes online for the first time.

M14/M8 series
Figure 1-50 PnP process after an AP goes online for the first time
Table 1-17 describes the PnP process.
NOTE
Before deploying AP PnP, configure basic functions (port extension capability and master
role) on a master and enable DCN on the master's internal communication interface.
Table 1-17 PnP process

Step Description
1 A network administrator performs basic configurations required for AP

PnP on an NMS, including:
● AP's ESN
● AP's management IP address
● Login password and SFTP access directory for a user created on the
AP

M14/M8 series
Step Description
2 The AP starts with the default configuration, loads the pre-configuration

file, automatically enables the data communication network (DCN)
function, and uses OSPF to advertise its ESN and initial PnP status in the
port extension system.
3 Master uses the DCN function to detect the AP and identifies the initial
PnP status. Master reports the detected AP's information (such as the
ESN) to the NMS.
4 The NMS sends the basic configurations required for AP PnP (see Step 1)
to Master.
5 Master checks whether the AP's ESN has been locally configured. If the
AP's ESN has been locally configured, Master starts the PnP process.
Otherwise, Master stops the PnP process.
NOTE
To enable a master to manage an AP, configure the AP's ESN on the master.
6 Master uses the initial user name and password to establish STelnet
connections to the AP and issue a PnP start command to the AP.
7 The AP starts the PnP process and timer to wait for PnP process
completion.
8 Master delivers the following basic configurations (including

configurations that Master automatically generates and basic
configurations that the NMS delivers) to the AP:
● Port extension capability enabling
● AP role setting
● AP's management IP address
● Login password and SFTP access directory for a user created on the
AP
If the preceding basic configurations are complete, the master delivers a
PnP stop command. Otherwise, the master stops the PnP process.
9 The AP automatically performs the basic configurations.

If the AP receives a PnP stop command, it considers the basic
configurations completed and stops the timer. If the AP does not receive
a PnP stop command before the timer expires, it considers the basic
configurations incomplete and automatically restarts itself to begin the
PnP process again.
10 The AP uses OSPF to advertise the PnP stop status in the port extension
system.
11 Master detects the AP's PnP stop status and reports it to the NMS. The
PnP process ends, and the AP goes online successfully.

M14/M8 series
NOTE
The preceding AP PnP process involves an NMS. If your scenario does not involve an NMS,
you must perform basic configurations required for AP PnP on a master in advance. This
operation also applies to the following PnP processes.
An AP Restarts and Goes Online

Figure 1-51 shows the PnP process after an AP restarts and goes online.
Figure 1-51 PnP process after an AP restarts and goes online
Step Description
1 After the AP restarts, it reads the locally stored PnP status and uses
OSPF to advertise its own PnP status in the port extension system.
2 The master uses the DCN function to detect the AP and identify the AP's
PnP status.
● If the AP's PnP status is initial, the process described in An AP Goes
Online for the First Time starts.
● If the AP's PnP status is complete, the PnP process does not start.
NOTE
If the AP restarts for configuration recovery, its PnP status is complete. If the AP
restarts for configuration clearing and loads the pre-configuration file, its PnP
status is initial.

M14/M8 series
Step Description
3 The master notifies the NMS that the AP has completed the PnP process.
4 The AP establishes NETCONF and control channels to the master.
5 The master uses the NETCONF channel to reconcile configurations with

the AP so that services are restored.
NOTE
In configuration reconciliation, the master checks whether the AP configurations
on the master have been configured on the AP. If any configurations are missing,
the master uses the NETCONF channel to deliver the missing configurations to the
AP. If the AP has configurations that the master does not have, the configurations
are deleted.
The Master Restarts

Figure 1-52 shows the AP PnP process after the master restarts.
Figure 1-52 AP PnP process after the master restarts
Step Description
1 After the restart is complete, the master restores configurations. In this

situation, configurations on the AP have existed.

M14/M8 series
Step Description
2 The master uses the DCN function to detect the AP and identify the AP's
PnP status.
● If the AP's PnP status is initial, the process described in An AP Goes
Online for the First Time starts.
● If the AP's PnP status is complete, the PnP process does not start.
NOTE
In normal situations, the AP's PnP status is complete. If the AP restarts for
configuration clearing and loads the pre-configuration file, its PnP status is initial.
3 The AP establishes NETCONF and control channels to the master.
An AP Goes Offline
Figure 1-53 shows the AP going-offline process.
Figure 1-53 AP going-offline process
Table 1-20 describes the going-offline process.
Table 1-20 Going-offline process

Step Description
1 When the AP's routing information is deleted from the routing tables of
the master, the master detects that the AP has gone offline and
performs no action.
2 The master reports to the NMS information about the AP that goes
offline.
An AP Migrates
Figure 1-54 shows the PnP process after the AP migrates. The AP migrates from
Master 1 to Master 2.

M14/M8 series
Figure 1-54 PnP process after the AP migrates
Step Description
1 A user deletes the AP's ESN configuration from Master 1.
2 A user uses a master or the NMS to log in to the AP, delete basic
configurations, load the pre-configuration file, and delete the AP's PnP
status.
3 The AP starts a PnP process with Master 2. For details, see An AP Goes
Online for the First Time.
Network Management
Scenario in Which an NMS Exists

In this scenario, management channels in the port extension system are NETCONF
and SNMP channels, as shown in Figure 1-55.
● NETCONF channel

M14/M8 series
– NETCONF channel between master and the AP: The master establishes
NETCONF channel to the AP. A master uses a NETCONF channel to
deliver configurations, query commands (such as a command for
querying the status of the AP's external communication interface), and
maintenance commands (such as software package upgrade and AP
restart commands) to the AP.
– NETCONF channel between the NMS and master: The NMS uses this
channel to deliver configuration or query tasks to the master. After the
NETCONF channel between the NMS and master is connected to the
NETCONF channel between the master and AP, the NMS can also deliver
configuration or query tasks to the AP.
● SNMP channel
The master and the AP establish SNMP channels to the NMS and use the
SNMP channels to report alarms to the NMS.
SNMP channels use inband management. In inband management, the NMS
uses the forwarding paths provided by managed devices to manage network
devices. Services on a bearer network are usually carried over L3VPN to
achieve reliable transmission of network management information.
The principles are described as follows: A master communicates with the NMS
through an interface board's service interface. AP-to-NMS packets enter the
master's interface board and then are forwarded through the interface board.
Figure 1-55 Network management in the port extension system
The NMS provides the following functions in the port extension system:
● Participates in AP PnP. For details, see AP PnP.
● Provides configuration, maintenance, and information query for the master
and APs.
● Receives alarm information from the master and APs, helping network
administrators for troubleshooting.
Scenario in Which No NMS Exists

In this scenario, only the NETCONF channel between a master and AP is involved.
You can manage an AP on a master in either of the following modes:

M14/M8 series
● Configure, query, and maintain an AP directly on a master. The master uses

the NETCONF channel to deliver the operations to the AP.
● Use STelnet on a master to log in to an AP, and then query and maintain the
AP.
NOTE
When using STelnet on a master to log in to an AP, you can perform only query operations
(such as querying the status of the AP's external communication interface) and
maintenance operations (such as upgrading a software package and restarting the AP). You
can configure AP services directly on a master only.
1.1.3.1.4 Application Scenarios for Port Extension
Application of Port Extension on an IP Core Network
Service Overview
If a customer has limited budget for constructing an IP core network and has
many low-end devices that support Ethernet interfaces, the customer can
purchase only few high-end devices or use software to upgrade the original high-
and low-end devices to masters and APs, respectively. In this way, the customer
can establish a port extension system to provide high-density Ethernet interfaces.
Networking Description
On an IP core network, typical application of a port extension system is used as a
PE node. The typical network is shown in Figure 1-56.
Figure 1-56 Port extension system used as a PE node
Feature Deployment
1. Specify a master and AP for a port extension system.
2. Bind the internal communication interfaces on the AP and master.
3. Bind the master's internal communication interface to the AP's external
communication interface.

M14/M8 series
HQoS Implementation in Port Extension Scenarios
On the network shown in Figure 1-57, profile-based HQoS is configured on the

external communication interface of the router. After profile-based HQoS is
configured and applied to the port extension interface, HQoS is enabled in the
port extension system.
Figure 1-57 HQoS implementation in port extension scenarios
1.1.3.1.5 Terminology for Port Extension
Terms
Term Definition
Master A control node in a port extension system. A master

establishes a tunnel, delivers services, controls traffic,
and manages connected APs.
AP An access node in a port extension system. An AP can

be considered as a master's board and is
automatically discovered and managed by a master.
An AP receives configuration and forwarding entries
delivered by a master and provides external
communication interfaces.
Acronyms and Abbreviations

Acronym and Abbreviation Full Name
AP access point
ESN equipment serial number
PnP plug and play
DCN data communication network
1.1.3.2 Port Extension Configuration

You can configure port extension so that a device uses fewer slots to provide high-
density Ethernet interfaces.

M14/M8 series
Usage Scenario
NOTE
This feature is supported only on the Admin-VS.
On an IP core network, to meet more and more service deployment requirements

on the access and network sides, PE or P devices need to provide high-density
Ethernet interfaces. To meet this need, deploy a port extension system. In this
system, configure a device with higher performance as a master and a large
number of low-end devices that support Ethernet interfaces as APs, and map the
APs' Ethernet interfaces to the master's port extension interfaces, so that the
master provides high-density Ethernet interfaces. Services only need to be
configured on the master's port extension interfaces. This ensures that the existing
devices that support Ethernet interfaces are fully used and prevents a large
number of devices that support Ethernet interfaces from being purchased,
significantly reducing network construction costs. The port extension system can
implement AP plug-and-play (PnP). You can configure and manage all APs on a
master, which simplifies network and service deployment and reduces O&M
difficulties. Figure 1-58 shows the typical networking for port extension.
Figure 1-58 Typical networking for port extension
NOTE
After a port extension system is deployed, the scope of service features supported by the
master's port extension interfaces is the same as that supported by local common Ethernet
interfaces.
Deployment Guidance
To completely deploy a port extension system and maintain and manage the
system on demand, perform the following configurations on a master:
1.1.3.2.1 Feature Requirements for Port Extension

M14/M8 series
1.1.3.2.2 Establishing a Port Extension System

This section describes how to establish a port extension system.
Background
A port extension system consists of masters and APs. To simplify service
deployment and facilitate O&M and management, the control plane of the port
extension system is on a master. You can establish a port extension system on a
master. APs support plug-and-play (PnP). A master uses ESNs to automatically
identify APs and manage them, and delivers basic configurations to APs through
NETCONF channels. You do not need to perform configurations on APs.
Before establishing a port extension system, complete the following tasks:
● Retain the default configurations of the AP and load the pre-configuration
file.
● Obtain AP ESNs.
● Run the ssh client first-time enable command to enable SSH client first-time
authentication on a master.
Configuring Basic Master Functions

A master is a main device in a port extension system. You must configure a master
before establishing a port extension system.
Procedure
Step 2 Run virtual-access port-extend
Port extension is enabled, and the port extension view is displayed.
Step 3 Run role master
The node is configured as a master. After this step is performed:
● All local physical interfaces become four-dimensional interfaces. For example,
dimension 1 in GigabitEthernet 1/0/1/1 indicates that the interface is a local
interface.
● The node automatically enables global BFD capabilities and establishes an IS-
IS process inside the port extension system based on local feature
configurations. The following table describes IS-IS process establishment rules.

M14/M8 series
Scenario Sub-scenario IS-IS Process

Establishment Rules
No IS-IS process By default, no IS-IS An AP and a master

exists. process exists. automatically establish
an IS-IS process with the
ID of 65534.
One or more IS-IS The ID of 65534 has An AP and a master

processes exist. been used for an IS-IS search for an unused IS-
process. IS process ID in
descending order from
65534 and use the ID to
establish a port
extension IS-IS process.
The ID of 65534 has not An AP and a master

been used for an IS-IS automatically establish
process. an IS-IS process with the
ID of 65534.
Step 4 Run admin ip-address

A management IP address is configured for the master.
The management IP address of the master is advertised to an AP over IS-IS for
establishing internal control and management channels to the AP. After this step
is performed, the master automatically generates a loopback interface with the
management IP address specified by ip-address.
Step 5 Run the following commands as required to configure a username, password, and
slave password for the master to establish an STelnet connection with an AP.
● ap default login-user user-name { login-password password | slave slave-
password-value } *
● ap default login-user user-name login-password
● ap default login-user user-name slave-password
NOTE
The username and password must be set to the default username and password of an AP.
Step 6 (Optional) Run isis authentication-mode hmac-sha256 key-id key-id cipher

cipher-text [ send-only ]
IS-IS authentication is configured.
To improve the security of a port extension system, run the isis authentication-
mode command to authenticate received Hello, LSP, and SNP packets and to
encapsulate authentication information into sent Hello, LSP, and SNP packets.
Only authenticated or encrypted packets can be forwarded on a network,
preventing invalid packets from interfering with the network.
Step 7 (Optional) Run control-tunnel authentication keychain keychain-name
Keychain authentication is configured for a control channel.

M14/M8 series
An AP and master establish a control channel to exchange control information. To

improve control channel security, perform this step on a master to configure
keychain authentication for the control channel.
Before performing this step, you must have created a keychain.
Step 8 Run commit
----End
Configuring Basic AP Functions on a Master

An AP can be considered as a master's remote card. You can configure basic AP
functions on a master.
Context
In a port extension system, a master can manage multiple APs at the same time.
You can repeat the following steps on a master to configure basic functions for
multiple APs.
Procedure
Step 2 Run ap-id ap-id
An AP is configured on the master, and the AP view is displayed.
Step 3 Run esn esn-number
An ESN is configured for the AP.
The port extension system supports plug-and-play (PnP) for an AP. After an AP
starts, it automatically enables the data communication network (DCN) function
and uses OSPF to advertise its ESN and initial PnP status. After a master discovers
the AP and identifies the initial PnP status, the master checks whether the AP's
ESN has been locally configured. If the AP's ESN has been locally configured, the
master starts the PnP process. A master uses an ESN to uniquely identify an AP,
and therefore different APs' ESNs cannot be the same.
Step 4 (Optional) Run sysname host-name
A host name is specified for the AP.
Step 5 Run commit
Step 6 Run admin ip-address
A management IP address is configured for the AP.
The management IP address of the AP is used to establish internal control and
management channels to the master. This configuration is delivered by the master

M14/M8 series
to the AP in the AP plug-and-play process. Then, the AP automatically generates a

loopback interface with the IP address specified by ip-address.
The command takes effect immediately after being run.
----End
Configuring an Authentication Scheme for a Port Extension System

To ensure the security of a port extension system, you must configure an
authentication scheme.
Context
To establish a port extension system, you must establish channels (such as
STelnet, SFTP, and NETCONF channels) between a master and AP. To ensure
system security, you must configure an authentication scheme for AP login. The
current authentication scheme supports the following authentication modes:
● Local authentication: If no HWTACACS server is deployed on the current
network, you can use the local authentication mode. Local authentication
features fast processing and low operation costs, but the amount of
information that can be stored is limited by a device's hardware capacity.
● HWTACACS authentication: HWTACACS authentication can be used to prevent
unauthorized users from attacking a port extension system. Compared with
local authentication, HWTACACS authentication features more reliable
transmission and encryption.
Perform the following steps on a master.
Procedure
The AP view is displayed.
Step 3 Run login-user user-name login-password password
A username and password required for the master to log in to the AP are
configured.
Step 4 Run commit
Step 5 Run login-user user-name sftp-directory sftp-directory
A user name and SFTP directory required for the master to log in to the AP are
configured.
Step 6 Run authentication-mode { hwtacacs | local } *
An authentication mode is configured for the authentication scheme. To configure

local authentication, specify the local parameter. To configure HWTACACS

M14/M8 series
authentication, specify the hwtacacs parameter. By default, local authentication is

used.
You can configure both local and hwtacacs authentication modes in an
authentication scheme. The system performs authentication based on the
configuration sequence.
● When the authentication mode is configured as local authentication and then
HWTACACS authentication: If the user name in Step 3 is not created on the
AP, the system performs HWTACACS authentication. If the user name in Step
3 has been created on both the AP and HWTACACS server and a password
error causes local authentication to fail, the system does not perform
HWTACACS authentication.
● When the authentication mode is configured as HWTACACS authentication
and then local authentication:
If the user name in Step 3 is not created on the HWTACACS server but exists
on the AP, the system considers HWTACACS authentication failed and does
not perform local authentication. The system performs local authentication
only when the HWTACACS authentication server goes Down.
The authentication mode of HWTACACS authentication and then local
authentication is recommended.
Step 7 Perform operations based on the configured authentication mode.
● If HWTACACS authentication is configured, perform the following operations:
a. Run the hwtacacs command to enter the port extension HWTACACS
view.
b. Run the hwtacacs-server shared-key { cipher cipher-string | key-string }
command to configure a global shared key for the AP's HWTACACS
server for communicating with the master.
To improve the security of communication between the master and the
AP's HWTACACS server, configure a shared key.
c. Run the hwtacacs-server ip-address [ port ] [ shared-key { key-string |
cipher cipher-string } ] [ secondary ] command to configure primary and
secondary HWTACACS servers for the AP.
Where:
▪ If you do not specify shared-key { key-string | cipher cipher-string },

the global shared key is used.
▪ The IP addresses of the primary and secondary HWTACACS servers

must be different; otherwise, the configuration fails.
NOTE
If HWTACACS authentication is used, you must ensure that the user name and
password configured using the login-user command in Step 3 are the same as those
on the HWTACACS server. Otherwise, the AP cannot work normally.
● If local authentication is configured, perform the following operations:
a. Run the ap-user command to enter the virtual access AP-user view.
b. Run the local-user user-name password cipher password command to
create a local user name on the AP and configure a login password.

M14/M8 series
NOTE
If local authentication is used, you must ensure that the user name and password
configured using the login-user command in Step 3 are the same as those configured
using the local-user command. Otherwise, the AP cannot work normally.
Step 8 Run commit
----End
Configuring Internal Communication Interfaces

To establish a port extension system, you must configure internal communication
interfaces between a master and AP.
Context
In a port extension system, data traffic is transmitted through the internal
forwarding channel between internal communication interfaces on an AP and
master. To set up the channel, you must configure the directly connected physical
interfaces between the master and AP as physical internal communication
interfaces. To increase the bandwidth or improve reliability, you can also configure
the Eth-Trunk interfaces between the master and AP as internal trunk interfaces.
NOTE
Physical internal communication interfaces and internal trunk interfaces do not support
service configuration or sub-interface creation.
To view a physical internal communication interface on the AP connected to a physical
internal communication interface on a master, run the link detect interface interface-type
interface-number command in the user view to enable the master to send LAD packets.
Then, run the display link neighbor interface interface-type interface-number command
to view the neighbor information about the internal communication interfaces between the
master and AP.
Procedure
● Configure a physical internal communication interface.
a. Run system-view

The directly connected physical interface view is displayed.

c. Run virtual-access enable
Port extension is enabled on the interface, and the interface is configured

as a physical internal communication interface.
After this step is performed, an IS-IS process inside the port extension
system is automatically enabled on the interface and the isis circuit-type
p2p command is automatically run to simulate the interface as a P2P
interface.

M14/M8 series
NOTE
● If you manually run the isis enable process-id command and then run the
virtual-access enable command on the interface, the port extension IS-IS
process is not automatically enabled and the isis circuit-type p2p command
is not automatically run on the interface. In this situation, you need to ensure
that port extension has been enabled for the IS-IS process specified by
process-id and manually run the isis circuit-type p2p command on the
interface. This brings heavy configuration workloads. In this case, the
automatic configuration solution is recommended. Do not run the isis enable
process-id command before running the virtual-access enable command.
● After an AP automatically goes online, port extension is automatically
enabled on the AP's all Ethernet interfaces. In addition, the AP automatically
saves the virtual-access enable configuration on corresponding interfaces.
d. Run dcn
DCN is enabled on the internal communication interface.
e. Run commit
f. Run quit
g. Run ap-id ap-id
h. Run inner-connect ap-interface-type ap-interface-number binding
master-interface-type master-interface-number
The internal communication interfaces on the AP and master are bound.
Where:
▪ ap-interface-type ap-interface-number specifies the AP's physical

internal communication interface, and master-interface-type master-
interface-number specifies the master's physical internal
▪ The binding configured in this step must match the actual physical
connection.
i. Run commit
● Configure an internal trunk interface.
a. Configure an Eth-Trunk interface to work in manual load balancing
mode.
Configuration details are as follows:
▪ Configure a Layer 3 Eth-Trunk interface.
▪ Add a physical interface through which the master is directly

connected to the AP to the Eth-Trunk interface.
b. Run interface eth-trunk trunk-id
The Eth-Trunk interface view is displayed.

M14/M8 series
c. Run virtual-access enable
Port extension is enabled on the Eth-Trunk interface, and the interface is

configured as an internal trunk interface.
After this step is performed, a port extension IS-IS process is

automatically enabled on the Eth-Trunk interface and the isis circuit-type
p2p command is automatically run to simulate the Eth-Trunk interface as
a P2P interface. The Eth-Trunk interface's member interfaces
automatically inherit the attributes of the internal trunk interface.
NOTE
If you manually run the isis enable process-id command and then run the
virtual-access enable command on the Eth-Trunk interface, the port extension
IS-IS process is not automatically enabled and the isis circuit-type p2p
command is not automatically run on the Eth-Trunk interface. In this situation,
you need to ensure that port extension has been enabled for the IS-IS process
specified by process-id and manually run the isis circuit-type p2p command on
the Eth-Trunk interface. This brings heavy configuration workloads. Therefore, do
not manually run the isis enable process-id command before running the
virtual-access enable command.
d. Run commit

e. Run quit

f. Run ap-id ap-id

g. Run inner-connect ap-interface-type ap-interface-number binding
master-interface-type master-interface-number
The internal communication interfaces on the AP and master are bound.
Where:
▪ ap-interface-type ap-interface-number specifies the AP's physical

internal communication interface, and master-interface-type master-
interface-number specifies an internal trunk interface's member
interface on the master.
▪ The same internal trunk interface's member interface can only be

bound to the same AP's internal communication interface.
▪ The binding configured in this step must match the actual physical
connection.
After this step is performed, the AP automatically configures the

corresponding internal trunk interface.
h. Run commit
----End

M14/M8 series
Configuring a Port Extension Interface

You can configure a port extension interface to map an AP's external
communication interface to a master's virtual interface, increasing the master's
interface density.
Context
In a port extension system, an AP can be considered as a card for extending
master interfaces. An AP receives configurations and forwarding entries from a
master and provides an external communication interface. To improve interface
density on a master, bind an AP's external communication interface to the
master's internal communication interface and create a port extension interface.
To configure Eth-Trunk for an AP's external communication interface, add the port
extension interface for the external communication interface to a common Eth-
Trunk interface as a port extension trunk interface on a master.
Procedure
Step 3 Run remote-interface ap-interface-type ap-interface-number [ to max-port-

number ] binding master-interface-type master-interface-number
The AP's external communication interface is bound to the master's internal

communication interface, and a port extension interface is created.
Where:
● ap-interface-type ap-interface-number specifies an AP's external

communication interface, and master-interface-type master-interface-number
specifies a master's physical internal communication interface or internal
trunk interface.
● max-port-number specifies a maximum number for an external
communication interface on the AP. If this parameter is specified, the
command binds a group of external communication interfaces on an AP to a
master's internal communication interface, and creates a group of port
extension interfaces. The number range of external communication interfaces
bound is the last dimension of ap-interface-number to max-port-number.
A port extension interface is a four-dimensional interface, which is an extended

interface of an AP's external communication interface mapped on a master. For
example, GigabitEthernet 1025/0/1/1 indicates that the port extension interface
corresponds to AP 1025's external communication interface GigabitEthernet 0/1/1.
After creating a port extension interface, you can treat the AP's external
communication interface as the master's local interface for service configurations.

M14/M8 series
NOTE
After an AP goes online, port extension is automatically enabled on the AP's all Ethernet
interfaces. That is, the interfaces are internal communication interfaces by default. After
this step is performed on the master, port extension is automatically disabled on the AP's
external communication interface, because an interface cannot function as both an internal
communication interface and an external communication interface.
Step 4 Run commit
Step 5 (Optional) Run quit
Step 6 (Optional) Configure a port extension trunk interface. Perform any of the
following tasks based on service requirements:
● Configure an Eth-Trunk interface to work in manual load balancing
mode.
● Configure an Eth-Trunk interface to work in static LACP mode.
● Configure an Eth-Trunk interface to work in manual 1:1 master/backup
mode.
When you perform any task, you must add the created port extension interface to
the Eth-Trunk interface.
NOTE
Currently, port extension interfaces and local common interfaces cannot be added to the
same Eth-Trunk interface.
----End
(Optional) Configuring Route Import Between the Port Extension System and
External Network
To enable an NMS to directly manage masters and APs, configure route import
between the port extension system and external network.
Context
A port extension system uses the DCN function to implement AP PnP, but a DCN is
characterized by route isolation. Therefore, if an NMS is used to manage a master
and AP, you must configure route import between the port extension system and
external network on a master.
Procedure
The port extension view is displayed.

M14/M8 series
Step 3 Run import admin-ip to { bgp [ vpn-instance vpn-instance-name ] | isis process-

id [ level-1 | level-1-2 | level-2 ] | ospf process-id | public }
The routes to the management IP addresses of the master and AP are imported
into a specified routing protocol. After this step is performed, routes in the port
extension system are imported into the DCN's external network. Before this step is
performed, configure routing protocols into which routes are to be imported on
the master.
NOTE
If a route to a management IP address is imported into IS-IS or OSPF, ensure that the
process specified by process-id does not import other routes. Otherwise, the configuration
fails.
Step 4 Run import { bgp [ vpn-instance vpn-instance-name ] | static [ vpn-instance

vpn-instance-name ] | isis process-id | ospf process-id } to dcn-ospf [ route-policy
route-policy-name ]
A specified protocol's routes are imported into DCN. After this step is performed,
the route between the master and NMS is imported into DCN in the port
extension system. Before this step is performed, configure routing protocols whose
routes are to be imported into DCN and routing policies on the master.
Step 5 Run commit
----End
Verifying the Configuration of Establishing a Port Extension System

After establishing a port extension system, check the configurations on the master,
including basic AP information, AP statistics, AP interface information, port
extension interface information, and NVTAG allocation information.
Prerequisites
A port extension system has been established.
Procedure
● Run the display virtual-access ap [ ap-id ] command to check basic AP
information.
● Run the display virtual-access ap statistics command to check AP statistics.
● Run the display virtual-access ap-interface [ ap-id ap-id ] command to
check AP interface information.
● Run the display interface { interface-name | interface-type interface-
number } remote command to check information about a specified port
extension interface on the master corresponding to the external
● Run the display remote interface interface-type interface-number command
to check information about a specified port extension interface on the master.

M14/M8 series
● Run the display virtual-access bindinfo [ ap ap-id | interface interface-type

interface-number ] command to check the bindings between external
communication interfaces and port extension interfaces on the master.
----End
1.1.3.2.3 Upgrading and Managing an AP

This section describes how to upgrade and manage an AP.
Background
In the port extension solution, the control and management planes are centralized
on a master. You can upgrade and manage an AP on a master, including:
● Upgrade using a software package

● Patch installation
● AP restart
● Configuring APs to communicate with an NMS over SNMP
● Configuring APs to send information to a syslog server
● Setting an interval for collecting traffic statistics on an AP interface
● Configuring alarm thresholds for bandwidth usage on an AP interface
● Configuring a time format for AP information
● Configuring an AP information output mode
After you complete configurations, the master uses the NETCONF channel to
deliver the configurations to the AP and the AP automatically performs the
configurations.
NOTE
● During a software upgrade of the port extension system, upgrade APs and then masters.
The process for upgrading a master is the same as that for upgrading a common device.
● Ensure that the software versions running on the master and APs are the same. If the
software versions are inconsistent, services may be unavailable after the APs go online.
● You can also log in to an AP to upgrade and manage it.
Before upgrading and managing an AP on a master, complete the following tasks:
● Establish a port extension system.

● Upload a software package or patch file for an upgrade to a master or
specified server.
Using a Software Package to Upgrade an AP

A software package optimizes an AP's original functions, adds functions, and
resolves the issue that the running version cannot be promptly updated.

M14/M8 series
Procedure
Step 1 Upload a software package for an upgrade to an AP. The following table describes
upload methods.
Softw AP Command
are Range
Packa
ge
Sourc
e
Maste APs in a upgrade download-package packagename ap-id

r specified { startapid [ to endapid ] } &<1-10>
range
All APs upgrade download-package packagename all-ap
Specifi APs in a upgrade download-package packagename server-ip ip-

ed specified address server-port port-number ap-id { startapid [ to
server range endapid ] } &<1-10>
All APs upgrade download-package packagename server-ip ip-
address server-port port-number all-ap
NOTE
● After upgrade download-package is run, a user must enter an SFTP user name and
password as prompted for SFTP authentication between an AP and master or between
an AP and specified server.
● If the software package source is a specified server, configure the port extension system
and server to import each other's network segment route to implement connectivity
between the APs and server.
● To free up the system storage space, run the upgrade delete-package type command
on the master to delete unnecessary AP software packages.
Step 2 Run the display patch-information ap-id ap-id command to check whether any
running patch exists on the AP.
Step 3 (Optional) Run the patch delete all { all-ap | ap-id { startapid [ to endapid ] }
&<1-10> } command to delete the running patches on the AP.
Before using a software package to upgrade an AP, ensure that no patches are
running on the AP. If any patch is running on the AP, system software cannot be
upgraded. Perform this step if any patch is running on the AP. Otherwise, skip this
step.
Step 4 Run the startup system-software system-file { all-ap | ap-id { startapid [ to

endapid ] } &<1-10> } command to configure system software for the AP's next
startup.
Parameters are described as follows:
● all-ap: configures system software for the next startup of all APs managed by
the master.

M14/M8 series
● ap-id { startapid [ to endapid ] } &<1-10>: configures system software for the

next startup of the APs in the specified range.
Step 5 After a period of time, run the display startup ap-id ap-id command to check the
configuration result.
----End
Follow-up Procedure
Restart the AP for the software package to take effect immediately.
Installing a Patch
You can install a patch for an AP to optimize the AP's system functions or add
small requirements.
Procedure
Step 1 Upload a patch file to an AP. The following table describes upload methods.
Patch AP Command
File Range
Sourc
e
Maste APs in a upgrade download-package packagename ap-id

r specified { startapid [ to endapid ] } &<1-10>
range
All APs upgrade download-package packagename all-ap
Specifi APs in a upgrade download-package packagename server-ip ip-

ed specified address server-port port-number ap-id { startapid [ to
server range endapid ] } &<1-10>
All APs upgrade download-package packagename server-ip ip-
address server-port port-number all-ap
NOTE
● After upgrade download-package is run, a user must enter an SFTP user name and
password as prompted for SFTP authentication between an AP and master or between
an AP and specified server.
● If the software package source is a specified server, configure the port extension system
and server to import each other's network segment route to implement connectivity
between the APs and server.
● To free up the system storage space, run the upgrade delete-package type command
on the master to delete unnecessary AP patch packages.
Step 2 Install the patch for the AP.

● Install the patch without interrupting services.
a. Run the patch load file-name all run { all-ap | ap-id { startapid [ to
endapid ] } &<1-10> } command to install the patch for the AP.

M14/M8 series
Parameter Description
run The patch is in the running state after being

installed.
all-ap The patch is installed for all APs managed by the

master.
ap-id { startapid The patch is installed for the APs in a specified

[ to endapid ] } range.
&<1-10>
● Install the patch for the next startup.

a. Run the startup patch packagename all { all-ap | ap-id { startapid [ to
endapid ] } &<1-10> } command to configure the patch for the AP's next
startup.
After the AP restarts, the patch takes effect permanently.
----End
Follow-up Procedure
● When the patch is installed without interrupting services:
– To delete the installed patch that results in an exception, run the patch
delete all { all-ap | ap-id { startapid [ to endapid ] } &<1-10> }
command.
● When the patch is installed for the next startup:
– To clear the patch configuration for the next startup, run the reset patch-
configure next-startup { all-ap | ap-id { startapid [ to endapid ] }
&<1-10>} command.
– Restart the AP for the patch to take effect immediately.
Restarting an AP
After configuring a software package for an AP's upgrade or a patch for an AP's
next startup, restart the AP to immediately validate the software package or patch
and check whether the configuration is successful.
Procedure
Step 3 Run reboot
The AP is restarted.
----End

M14/M8 series
Configuring APs to Communicate with an NMS over SNMP

To use a network management system (NMS) to manage APs, configure the APs
to communicate with the NMS over SNMP on a master.
Context
In a port extension scenario, to use an NMS to manage APs, you need to configure
SNMP in the port extension view of a master. After the configuration, when the IP
route between the NMS and an AP is reachable:
● The AP uses a trap message to report a fault alarm to the NMS.
● The AP records active alarms, and the NMS can use the MIB to query or
synchronize the active alarms on the AP.
NOTE
● In a port extension system, all services are configured on a master. Therefore, the
master is responsible for service alarm reporting. If an AP fails, it independently reports
a fault alarm.
● A master communicates with an NMS over SNMP. The configuration procedure is the
same as that in a common scenario.
Before configuring APs to communicate with an NMS over SNMP:
When establishing a port extension system, you can configure route import
between the port extension system and external network so that the
routes between the NMS and APs are reachable.
Procedure
Step 3 Run snmp-agent
The SNMP agent service is started.
Step 4 Run snmp-agent sys-info version { v1 | v2c | v3 | all } *
An SNMP version is configured.

Step 5 Perform either of the following configurations based on the SNMP version. You
are advised to use SNMPv3 with higher security.
● For SNMPv1 or SNMPv2:
Run snmp-agent community { read | write } cipher community-name
[ mib-view view-name ]

M14/M8 series
A read/write community name and MIB view are configured for APs.
A community is a set of an NMS and SNMP agents and is identified using a
community name. The community name acts like a password to regulate
access to a managed device. An NMS can access a managed device only if the
community name carried in an SNMP request sent by the NMS is the same as
the community name configured on the managed device. Perform this step to
configure an SNMP community name for APs so that the NMS communicates
with the APs. You can also run the snmp-agent community command to set
a MIB view that is accessible using a community name.
● For SNMPv3:
a. Run snmp-agent group v3 group-name { authentication | privacy |
noauthentication } [ read-view read-view | write-view write-view |
notify-view notify-view ]
An SNMP user group is configured.
If an NMS and a device reside in an insecure network environment, for
example, they are prone to network attacks, you are advised to set
authentication or privacy to enable data authentication and encryption.
The available authentication and encryption modes are as follows:
▪ If neither authentication nor privacy is configured or

noauthentication is configured, authentication and encryption are
not performed. This mode is applicable to secure networks managed
by a specified administrator.
▪ If only authentication is configured, only authentication is

performed. This mode is applicable to secure networks managed by
many administrators who may frequently perform operations on the
same device. In this mode, only the authenticated administrators can
access the managed device.
▪ If both authentication and privacy are configured, both

authentication and encryption are performed. This mode is
applicable to insecure networks managed by many administrators
who may frequently perform operations on the same device. In this
mode, only the authenticated administrators can access the
managed device, and transmitted data is encrypted to guard against
tampering and data leaking.
If the NMS administrator needs the read permission in a specified view,
configure read-view in this command. For example, a low-level
administrator needs to read certain data.
If the NMS administrator needs the read and write permissions in a
specified view, configure write-view in this command. For example, a
high-level administrator needs to read and write certain data.
If the NMS administrator needs to filter out irrelevant alarms and
configure the managed device to send only the alarms of specified MIB
objects to the NMS, configure notify-view. If the parameter is
configured, only the alarms of the MIB objects specified by notify-view is
sent to the NMS.
b. Run snmp-agent usm-userv3 user-name [ group group-name ]
A USM user is added to the SNMP group.

M14/M8 series
c. Run snmp-agent usm-user

An authentication mode, encryption mode, and password are configured
for the SNMP USM user.
NOTE
The md5, sha, sha2-224, DES56, and 3DES168 algorithms in the snmp-agent
usm-user command are weak security algorithms. You are advised to use other
security algorithms. To prevent security risks, run the crypto weak-algorithm
disable command to disable the weak security algorithm function.
Step 6 Run snmp-agent target-host host-name host-name trap address udp-domain

ip-address params securityname cipher cipher-name [ [ v1 | v2c ] | private-
netmanager | ext-vb ] *
A destination is set for trap messages sent by APs.
Perform this step to set a destination NMS address for trap messages sent by APs.
If a target host that receives trap messages is a Huawei NMS, specify private-
netmanager. To enable trap messages to carry extended bound variables, specify
ext-vb.
Step 7 (Optional) Run snmp-agent extend error-code enable
The extended error code function is enabled for APs.
The extended error code function can be configured to extend standard error
codes only when an NMS is a Huawei NMS and managed APs are Huawei devices.
Extended error codes facilitate fault locating.
Step 8 (Optional) Run snmp-agent mib-view type view-name oid-tree
A MIB view is created, and MIB objects monitored and managed by an NMS are
specified.
● If there are only a few MIB objects that do not need to be managed by an
NMS when you create a MIB view or you want to remove some MIB objects
from an existing MIB view, specify excluded in the command.
● If there are only a few MIB objects that need to be managed by an NMS
when you create a MIB view or you want to add some MIB objects to an
existing MIB view, specify included in the command.
Step 9 (Optional) Run snmp-agent trap enable
An AP is enabled to send trap messages.
Enabling an AP to send trap messages to the NMS facilitates problem locating.
You can perform this step to enable all modules of an AP to send trap messages.
Step 10 Run commit
----End
Configuring APs to Send Information to a Syslog Server

To view AP running information on a syslog server, configure the APs managed by
the master to send information to the syslog server on a master.

M14/M8 series
Context
When an AP is running, the system records the AP's running status in real time
and generates related information. After the information management function is
enabled, configure the APs managed by the master to send information to a
syslog server for storage and query on a master. A network administrator can use
the information to monitor the running status of the APs and diagnose network
faults.
Before configuring APs to send information to a syslog server:
When establishing a port extension system, you can configure route import
between the port extension system and external network so that the
routes between the NMS and APs are reachable.
Procedure
Step 3 Run info-center loghost source interface-type interface-number
The source interface through which APs send information to a specified syslog
server is configured.
The syslog server can obtain the source interface address of received information
and determine which AP sends the information based on the source interface
address. This helps the syslog server properly retrieve the received information.
Step 4 Run info-center loghostipv4-address [ { local-time | utc } | facilitylocal-number |
port port-number | levellog-level | transport { udp | tcp } ] *
All the APs managed by the master are configured to send information to the
specified syslog server. Repeat this step to configure APs to send information to
multiple syslog servers, implementing information backup between the syslog
servers.
Step 5 (Optional) Run info-center source { module-name | default } channel { channel-
number | channel-name } [ log { state { off | on } | levelseverity } * | trap { state
{ off | on } | levelseverity } * | debug { state { off | on } | levelseverity } * ] *
A rule is configured for each AP to output information to an information channel.
Step 6 Run commit
----End

M14/M8 series
Configuring a Time Format for AP Information

This section describes how to configure a time format for AP information.
Usage Scenario
On a master, you can configure a time format for AP information to meet the time
requirements in different places. After the configuration is complete, new
information on APs is generated using the configured time format.
NOTE
In this section, AP information refers to log, trap, and debugging information.
Procedure
Step 3 Run one or more of the following commands to configure time formats for desired
information:
● Run the info-center timestamp log { boot | { date | short-date | format-
date | rfc-3339 } [ precision-time { tenth-second | millisecond | second } ] }
[ without-timezone ] command to configure the time format of log
information.
● Run the info-center timestamp trap { boot | { date | short-date | format-
date | rfc-3339 } [ precision-time { tenth-second | millisecond | second } ] }
[ without-timezone ] command to configure the time format of trap
information.
● Run the info-center timestamp debugging { boot | { date | short-date |
format-date | rfc-3339 } [ precision-time { tenth-second | second |
millisecond } ] } [ without-timezone ] command to configure the time
format of debugging information.
The following table describes the elements of the date format.
Table 1-22 Elements of the date format
Field Meaning Value
yyyy Year The value contains four digits.
mm Month Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct,
Nov, or Dec.
dd Date If the date value (such as 7) is smaller than 10,

a blank is added before the date.

M14/M8 series
Field Meaning Value
hh:mm:ss Local time in The value of hh ranges from 00 to 23 in 24-

hh:mm:ss format hour format, whereas the values of mm and ss
both range from 00 to 59.
Step 4 Run commit

----End
Configuring an AP Information Output Mode

This section describes how to configure an AP information output mode. This
configuration enables you to export AP information to a local file or display area,
and set attributes for the file and display area.
Context
APs log their operation information in real time. You can configure an AP
information output mode and log in to the desired AP to know its operation
information.
Procedure
● Output information to the display area.
a. Run system-view
b. Run virtual-access port-extend
c. (Optional) Run info-center logbuffer size buffersize
The maximum number of AP logs to be displayed is configured.
d. Run info-center source { module-name | default } channel { channel-
number | channel-name } log { state { off | on } | level severity } *
A rule is configured for each AP to output log information to an
information channel.
e. Run commit
● Output information to a file.
a. Run system-view
b. Run virtual-access port-extend

M14/M8 series
c. (Optional) Run info-center debugfile-name file-name

A name is configured for an AP debugging log file.
The default debugging log file name is debug.log on an AP. To configure
a name for a specified debugging log file, perform this step. You can
obtain the debugging log file based on the name.
d. (Optional) Run info-center max-debugfile-number max-debugfile-
number
The maximum number of AP debugging log files that can be saved to the
log directory is configured.
The debug.log file that is generated on an AP by default is compressed
into a debug_*.log.zip file if its size exceeds 8 MB.
You can perform this step to configure the maximum number of AP
debugging log files that can be saved to the log directory.
When the number of compressed log files exceeds the maximum number
configured, the system deletes earliest log files.
e. Run info-center source { module-name | default } channel { channel-
number | channel-name } [ log { state { off | on } | level severity } * |
trap { state { off | on } | level severity } * | debug { state { off | on } |
level severity } * ] *
A rule is configured for each AP to output information to an information
channel.
f. Run commit
----End
Setting an Interval for Collecting Traffic Statistics on an AP Interface

This section describes how to set an interval on a master for collecting traffic
statistics on one or more external communication interfaces of an AP.
Context
By default, traffic statistics collection is enabled on external communication
interfaces of an AP to monitor the running status of interfaces and services. To
adjust the interval for collecting traffic statistics on external communication
interfaces of an AP, perform either of the following operations on the master:
● Configure a global interval for collecting traffic statistics on an AP:
Run the set flow-stat interval command in the AP view. The configuration is
delivered to the corresponding AP and takes effect on the AP's external
communication interfaces mapped to the port extension interfaces with no
traffic statistics collection interval configured.
● Configure an interval for collecting traffic statistics on one or more specified
external communication interfaces of an AP:
Run the set flow-stat interval command in the view of a port extension
interface or port extension trunk interface. The configuration is delivered to

M14/M8 series
the corresponding AP and takes effect on the AP's external communication

interface mapped to the port extension interface or the AP's external
communication interfaces mapped to the port extension trunk member
interfaces. This configuration takes precedence over the global configuration.
Procedure
● Configure a global interval for collecting traffic statistics on an AP.
a. Run system-view
b. Run ap-id ap-id
c. Run set flow-stat interval interval
A global interval for collecting traffic statistics on the AP is set.
d. Run commit
● Configure an interval for collecting traffic statistics on one or more specified
external communication interfaces of an AP.
a. Run system-view
The port extension interface view or port extension trunk interface view is
displayed.
c. Run set flow-stat interval interval
An interval for collecting traffic statistics on one or more specified
external communication interfaces of the AP is set.
d. Run commit
----End
Configuring Alarm Thresholds for Bandwidth Usage on an AP Interface

This section describes how to configure alarm thresholds for bandwidth usage on
a master to take effect on an external communication interface of an AP.
Context
Monitoring bandwidth usage helps you keep track of the load on an AP. If
bandwidth usage exceeds a specified threshold, bandwidth resources are
insufficient on an AP. In this case, you need to expand the capacity of the AP or
migrate services to another AP. The default alarm threshold for bandwidth usage
on an external communication interface of an AP is 90%. If the bandwidth usage
exceeds 90%, an alarm is generated, indicating that bandwidth resources are
almost exhausted. As a result, packet loss may occur before the capacity is
expanded or services are migrated. To resolve the preceding problem, adjust the

M14/M8 series
alarm threshold for bandwidth usage on an external communication interface of

an AP. For example, you can set the alarm threshold for inbound bandwidth usage
to 80% so that an alarm is generated when the inbound bandwidth usage exceeds
80%.
Procedure
The port extension interface view is displayed.
Step 3 Run trap-threshold { input-rate | output-rate } bandwidth-in-use [ resume-rate

resume-threshold ]
An alarm threshold and a clear alarm threshold for inbound or outbound
bandwidth usage are set for the corresponding external communication interface
on the AP. When performing this step, note the following:
● The value of resume-threshold must be less than or equal to that of

bandwidth-in-use.
● If resume-rate resume-threshold is not specified, the system automatically
sets the clear alarm threshold for bandwidth usage to be the same as the
alarm threshold for bandwidth usage.
● To prevent alarms from being frequently generated or cleared, set a large
difference between the bandwidth-in-use and resume-threshold values.
Step 4 Run commit
----End
1.1.3.2.4 Maintaining the Port Extension System

This section describes how to maintain the port extension system.
Clearing Statistics About a Port Extension Interface

Before collecting traffic statistics about a port extension interface within a
specified period, you must clear the existing statistics on the port extension
interface.
Context
NOTICE
Statistics cannot be restored after being cleared. Therefore, exercise caution when
clearing statistics.

M14/M8 series
Procedure
● Run the reset counters [ if-mib ] interface { interface-name | interface-type
interface-number } remote command in the user view to clear remote
statistics or remote MIB statistics about a specified port extension interface or
port extension trunk interface.
----End
1.1.3.2.5 Configuration Examples for Port Extension

This section provides port extension system deployment examples.
Example for Configuring a Port Extension System

This section provides an example for configuring a port extension system.
NOTE
The NetEngine 8000 M14 is used as an example.
Figure 1-59 shows the typical networking of a port extension system, which is
used to provide devices with high-density Ethernet interfaces on the IP core
network. Port extension enables a device with higher performance to be
configured as a master and a large number of low-end devices that support
Ethernet interfaces to be configured as APs. The APs' Ethernet interfaces are then
mapped to the master's port extension interfaces, so that the master provides
high-density Ethernet interfaces. Services only need to be configured on the
master's port extension interfaces.
Figure 1-59 Typical networking of a port extension system

NOTE
Interfaces 1 through 3 in this example are GE 0/1/1, GE 0/1/2, and GE 0/1/3, respectively.

M14/M8 series
1. Configure basic master functions.

2. Configure basic AP functions on the master.
3. Configure an authentication scheme for the port extension system.
4. Configure internal communication interfaces.
5. Configure port extension interfaces.
Data Preparation
● Management IP address of the master: 1.1.1.1; management IP address of
AP1: 2.2.2.2; management IP address of AP2: 3.3.3.3
● IS-IS authentication key ID: 1; authentication password: YsHsjx_202206
● Default username and password for the master to establish an STelnet
connection with an AP: root; password: Changeme_123
● Internal communication interfaces between the master and AP1: GE 0/1/1;
internal communication interfaces between the master and AP2: GE 0/1/2
and GE 0/1/1
● AP1 ID: 2000; AP1 ESN: 391092333866236; AP1's external communication
interfaces: GE 0/1/2 and GE 0/1/3
● AP2 ID: 2001; AP2 ESN: 391092333000298; AP2's external communication
interfaces: GE 0/1/2 and GE 0/1/3
● Authentication mode between the master and AP1 and between the master
and AP2: local authentication; username required for the master to log in to
AP1 and AP2: sys-admin; password: YsHsjx_202207; SFTP directory: cfcard:/;
name of a user created for AP1 and AP2 on the master: sys-admin; password:
YsHsjx_202207
Procedure
Step 1 Retain the default configurations for APs.
When an AP goes online for the first time, the master delivers a root user
configuration to the AP to establish a connection with the AP.
● Before an AP goes online, if the AP is logged in to in STelnet mode for the
first time, or the AP is logged in to through the console port and then the
console port password is modified, the AP cannot go online. In this case, you
need to manually clear the configuration and load the pre-configuration file.
The following uses AP1 as an example.
<AP1> reset saved-configuration
Warning: The action will delete the saved configuration on the device.
The configuration will be erased to reconfigure.Continue? [Y/N]:y
Warning: Now clearing the configuration on the device.
Info: Succeeded in clearing the configuration on the device.
<AP1> startup default-configuration default-custom_XXX_V***R***C**SPC***.defcfg
Warning: The action will override and update the default configuration file on the device. Continue?
[Y/N]:y
...
Info: Succeeded in setting the configuration for booting system.
NOTE
Obtain the pre-configuration file default-custom_XXX_V***R***C**SPC***.defcfg of

the corresponding product version from Huawei.

M14/M8 series
● After an AP goes online, if the password of the root user on the AP is

modified, the AP cannot establish a connection with the master for
reconciliation.
Step 2 Configure basic master functions.
<Master> system-view
[~Master] ssh client first-time enable
[~Master] dcn
Warning: This operation will enable DCN function. Continue? [Y/N]:y
Info: The operation may take a few seconds. Please wait for a moment....done.
[*Master] commit
[~Master] virtual-access port-extend
[*Master-virtual-access-portextend] role master
[*Master-virtual-access-portextend] admin 1.1.1.1
[*Master-virtual-access-portextend] ap default login-user root login-password Changeme_123
[*Master-virtual-access-portextend] isis authentication-mode hmac-sha256 key-id 1 cipher
YsHsjx_202206
[*Master-virtual-access-portextend] commit
[~Master-virtual-access-portextend] quit
Step 3 Configure basic AP functions on the master.

[~Master] ap-id 2000
[*Master-ap2000] esn 391092333866236
[*Master-ap2000] commit
[~Master-ap2000] admin 2.2.2.2
[~Master-ap2000] quit
[*Master-ap2001] esn 391092333000298
[~Master-ap2001] admin 3.3.3.3
Step 4 Configure an authentication scheme for the port extension system.

[~Master-ap2000] login-user sys-admin login-password YsHsjx_202207
[~Master-ap2000] login-user sys-admin sftp-directory cfcard:/
[~Master-ap2000] ap-user
[~Master-ap2000-ap-user] local-user sys-admin password cipher YsHsjx_202207
[~Master-ap2000-ap-user] quit
[~Master-ap2000] authentication-mode local
[~Master-ap2001] login-user sys-admin login-password YsHsjx_202207
[~Master-ap2001] login-user sys-admin sftp-directory cfcard:/
[~Master-ap2001] ap-user
[~Master-ap2001-ap-user] local-user sys-admin password cipher YsHsjx_202207
[~Master-ap2001-ap-user] quit
[~Master-ap2001] authentication-mode local
Step 5 Configure internal communication interfaces.

[~Master] interface GigabitEthernet1/0/1/1
[~Master-GigabitEthernet1/0/1/1] virtual-access enable
[~Master-GigabitEthernet1/0/1/1] dcn
[*Master-GigabitEthernet1/0/1/1] quit
[*Master] interface GigabitEthernet1/0/1/2
[*Master-GigabitEthernet1/0/1/2] virtual-access enable
[*Master-GigabitEthernet1/0/1/2] dcn
[*Master-GigabitEthernet1/0/1/2] quit
[~Master-ap2000] inner-connect GigabitEthernet0/1/1 binding GigabitEthernet1/0/1/1
[*Master-ap2000] quit
[*Master] ap-id 2001
[*Master-ap2001] inner-connect GigabitEthernet0/1/1 binding GigabitEthernet1/0/1/2

M14/M8 series
Step 6 Configure port extension interfaces.

[~Master-ap2000] remote-interface GigabitEthernet0/1/2 binding GigabitEthernet1/0/1/1
[*Master-ap2000] remote-interface GigabitEthernet0/1/3 binding GigabitEthernet1/0/1/1
[*Master-ap2000] quit
[*Master] ap-id 2001
Step 7 Verify the configuration.
Run the display virtual-access ap command on the master to view basic

information about APs.
[~Master] display virtual-access ap
AP Information
-----------------------------------------------------------------------------------------------
AP Esn : 391092333866236
AP ID : 2000 Admin IP : 2.2.2.2
Master : 1.1.1.1
State : Online
Online Time : 2017-09-30 01:03:56
AP Esn : 391092333000298
AP ID : 2001 Admin IP : 3.3.3.3
Master : 1.1.1.1
State : Online
Online Time : 2017-09-30 01:31:26
-----------------------------------------------------------------------------------------------
Run the display virtual-access ap-interface command on the master to view

basic information about AP interfaces.
[~Master] display virtual-access ap-interface
Ap Interface Information
Total 20 record(s) found:
-----------------------------------------------------------------------------------------
APID APAdminIP Interface IfIndex State Type
-----------------------------------------------------------------------------------------
2000 2.2.2.2 GigabitEthernet0/1/1 8 Up inner
2000 2.2.2.2 GigabitEthernet0/1/2 9 Up outer
2001 3.3.3.3 GigabitEthernet0/1/1 8 Up inner
-----------------------------------------------------------------------------------------
Run the display virtual-access bindinfo command on the master to view the
bindings between internal communication interfaces and port extension interfaces
on the master.
[~Master] display virtual-access bindinfo
--------------------------------------------------------------------------------------
AP-ID Inner-interface Out-interface
--------------------------------------------------------------------------------------
2000 GigabitEthernet1/0/1/1 GigabitEthernet2000/0/1/2
----End

M14/M8 series
Configuration Files
● AP1 configuration file
#
sysname AP1
#
virtual-access
role ap
admin 2.2.2.2
master admin-ip primary 1.1.1.1
isis authentication-mode hmac-sha256 key-id 1 cipher %^%#OqaV.B&wk-eu\lD0(u:5ZWFN)r'k:2uIW.-/
9:NU%^%#
#
undo user-security-policy enable
#
ip dcn vpn-instance __dcn_vpn__
ipv4-family
#
bfd
#
aaa
local-user sys-admin password irreversible-cipher $1c$VW58EBdUe"$uXfj.2l)I#za`:6tJ,w$U|
([5}MsD#|):rU(cV/+$
local-user sys-admin service-type ssh
local-user sys-admin state block fail-times 3 interval 5
local-user sys-admin user-group manage-ug
#
authentication-scheme default0
#
#
authentication-scheme default
authentication-mode local
#
authorization-scheme default
#
accounting-scheme default0
#
#
domain default0
#
domain default1
#
domain default_admin
#
isis 65534
description auto-generated for virtual-access
is-level level-2
cost-style wide
virtual-access enable
network-entity 00.38ba.33bc.a402.00
binding interface GigabitEthernet0/1/1 down-weight 10
#
interface GigabitEthernet0/1/1
undo shutdown
isis enable 65534
isis circuit-type p2p
dcn
#
undo shutdown
#
undo shutdown
#
interface LoopBack2147483646

M14/M8 series
description virtual-access loopback interface

ip binding vpn-instance __dcn_vpn__
ip address 2.2.2.2 255.255.255.255
#
description DCN loopback interface
ip address 172.16.1.1 255.255.0.0
#
ospf 65534 vpn-instance __dcn_vpn__
description DCN ospf create by default
opaque-capability enable
hostname
vpn-instance-capability simple
area 0.0.0.0
network 0.0.0.0 255.255.255.255
#
!The DCN function implements the capability of plug-and-play for this device.
!A NE IP address based on the unique NE ID is automatically generated in VPN
!of DCN. It is recommended that the NE IP address be changed to the planned
!one by running the ne-ip X.X.X.X <mask> command after the device being online.
dcn
bandwidth ethernet 1024
bandwidth pos 1024
#
stelnet ipv4 server enable
sftp ipv4 server enable
snetconf ipv4 server enable
ssh user sys-admin
ssh user sys-admin authentication-type password
ssh user sys-admin service-type all
ssh user sys-admin sftp-directory cfcard:/
ssh authorization-type default aaa
#
ssh server cipher aes256_gcm aes128_gcm aes256_ctr aes192_ctr aes128_ctr
ssh server hmac sha2_512 sha2_256
ssh server key-exchange dh_group_exchange_sha256
#
ssh server publickey rsa_sha2_256 rsa_sha2_512
#
ssh server dh-exchange min-len 3072
#
ssh client first-time enable
sftp client-source -a 2.2.2.2 -vpn-instance __dcn_vpn__
#
user-interface con 0
#
user-interface vty 0 4
authentication-mode aaa
protocol inbound ssh
#
netconf
idle-timeout 0 0
#
local-aaa-server
#
return
● AP2 configuration file
#
sysname AP2
#
virtual-access
role ap
admin 3.3.3.3
master admin-ip primary 1.1.1.1
isis authentication-mode hmac-sha256 key-id 1 cipher %^%#gb0N3W.{o6QZelLT!#yIPjdj/

M14/M8 series
~Dk8$F&p73~P/x.%^%#
#
undo user-security-policy enable
#
ipv4-family
#
bfd
#
aaa
local-user sys-admin password irreversible-cipher $1c$2"iN;T!PrW$4H+g1J;+D>"[]=$i,Z/4(5"MWJ-Ld
%)']CO`l>Z9$
local-user sys-admin service-type ssh
local-user sys-admin state block fail-times 3 interval 5
local-user sys-admin user-group manage-ug
#
#
#
authentication-scheme default
#
#
#
#
domain default0
#
domain default1
#
domain default_admin
#
isis 65534
is-level level-2
cost-style wide
network-entity 00.38ba.33bc.a402.00
binding interface GigabitEthernet0/1/1 down-weight 10
#
undo shutdown
isis enable 65534
dcn
#
undo shutdown
#
undo shutdown
#
ip address 3.3.3.3 255.255.255.255
#
ip address 172.16.1.2 255.255.0.0
#

M14/M8 series
hostname
area 0.0.0.0
network 0.0.0.0 255.255.255.255
#
!one by running the ne-ip X.X.X.X <mask> command after the device being online.
dcn
#
ssh user sys-admin
ssh user sys-admin authentication-type password
ssh user sys-admin service-type all
ssh user sys-admin sftp-directory cfcard:/
#
ssh server cipher aes256_gcm aes128_gcm aes256_ctr aes192_ctr aes128_ctr
ssh server hmac sha2_512 sha2_256
ssh server key-exchange dh_group_exchange_sha256
#
ssh server publickey rsa_sha2_256 rsa_sha2_512
#
ssh server dh-exchange min-len 3072
#
sftp client-source -a 3.3.3.3 -vpn-instance __dcn_vpn__
#
#
user-interface vty 0 4
authentication-mode aaa
protocol inbound ssh
#
netconf
idle-timeout 0 0
#
local-aaa-server
#
return
● Master configuration file
#
sysname Master
#
virtual-access port-extend
role master
admin 1.1.1.1
ap default login-user root login-password %^%#gOTF'nZ=j7+odk7U&I%>xVl0+h.l8AuNHt2_Y*n~%^
%#
isis authentication-mode hmac-sha256 key-id 1 cipher %^%#RmQD<'UJ)/Nl3L6*
+L8=*&(P"e4H[B~JbRW!W>3A%^%#
#
rsa peer-public-key 2.2.2.2
public-key-code begin
3082010A
02820101
009FD60F 4245F341 C86A4717 BB17C282 CE090BB7 12E1A73F FFBF0D44 D51EF073
49A6CA0D 90077E7C BE173037 2851FDB5 A3390BB9 96EAE330 3F999B47 0A765780
C21BEA42 9A132975 D3A1D64B DEF6E5C2 4CD6A7F3 909F7574 9B84B0A8 BF744446
67B00D1D 440DD081 8ABDA172 F995C80C C2953A13 F8D6EECA E835A442 C650A464
BA4B96A2 15D21EBE DD71D5FC 06F559D9 7DC11AD7 3D538CFC FDD408C8 03AA4B3B
D93E4764 BBDE5FB8 9A2ACBCF 3E7188EE 81995DC4 5A2C8F63 8994F7DA 0094E410

M14/M8 series
96C3F70E 9AFBA22A 273F53A3 D152B245 636419BA 71B03A9A E488BA20 1FC18BFB

396A66A4 0F325E9C A2F1C0CD 9759E1AA ED9A27E6 68605CE2 D284F541 AAD00ED0
9F
0203
010001
public-key-code end
peer-public-key end
#
3082010A
02820101
00CFEC57 3531F1E0 97D6D719 5A4B3D2D 707EE3DD E3FDF9FA C4B73D47 E6D439B5
3ED2E12F C63D83B7 E76C9B25 125490F5 30AB7277 3BCCB159 F3C90881 32CCDEDC
E703EB64 5A46DDD2 969A2368 16CFF8FB DA1628D3 F8989A6B 135B66E5 CDC00157
68246295 C4670F50 BFD4F1C0 48A2C195 E4243F3A BD6BA3E3 32651930 F8A8E4B5
3020F373 2A58F15E DFE003B4 1B1ACF80 9E0490C1 BE5A2997 97D8B146 3FB16FF5
9F26DFF6 F83040AF 012D59EA 943F8AB8 71E21A07 5785537F F6523D9E C3050217
FD03E7B3 BA72AEEA FD108F6D 644EFABB 7C9F2971 065EE65F DDB61426 6ED5084B
CC7C99E3 C0B6A4BF 95181DBC E2DF89DD 29A24AD8 51E55CCA 8DB1F130 7CE0798F
83
0203
010001
public-key-code end
peer-public-key end
#
3082010A
02820101
009FD60F 4245F341 C86A4717 BB17C282 CE090BB7 12E1A73F FFBF0D44 D51EF073
49A6CA0D 90077E7C BE173037 2851FDB5 A3390BB9 96EAE330 3F999B47 0A765780
C21BEA42 9A132975 D3A1D64B DEF6E5C2 4CD6A7F3 909F7574 9B84B0A8 BF744446
67B00D1D 440DD081 8ABDA172 F995C80C C2953A13 F8D6EECA E835A442 C650A464
BA4B96A2 15D21EBE DD71D5FC 06F559D9 7DC11AD7 3D538CFC FDD408C8 03AA4B3B
D93E4764 BBDE5FB8 9A2ACBCF 3E7188EE 81995DC4 5A2C8F63 8994F7DA 0094E410
96C3F70E 9AFBA22A 273F53A3 D152B245 636419BA 71B03A9A E488BA20 1FC18BFB
396A66A4 0F325E9C A2F1C0CD 9759E1AA ED9A27E6 68605CE2 D284F541 AAD00ED0
9F
0203
010001
public-key-code end
peer-public-key end
#
3082010A
02820101
00CFEC57 3531F1E0 97D6D719 5A4B3D2D 707EE3DD E3FDF9FA C4B73D47 E6D439B5
3ED2E12F C63D83B7 E76C9B25 125490F5 30AB7277 3BCCB159 F3C90881 32CCDEDC
E703EB64 5A46DDD2 969A2368 16CFF8FB DA1628D3 F8989A6B 135B66E5 CDC00157
68246295 C4670F50 BFD4F1C0 48A2C195 E4243F3A BD6BA3E3 32651930 F8A8E4B5
3020F373 2A58F15E DFE003B4 1B1ACF80 9E0490C1 BE5A2997 97D8B146 3FB16FF5
9F26DFF6 F83040AF 012D59EA 943F8AB8 71E21A07 5785537F F6523D9E C3050217
FD03E7B3 BA72AEEA FD108F6D 644EFABB 7C9F2971 065EE65F DDB61426 6ED5084B
CC7C99E3 C0B6A4BF 95181DBC E2DF89DD 29A24AD8 51E55CCA 8DB1F130 7CE0798F
83
0203
010001
public-key-code end
peer-public-key end
#
ipv4-family
#
bfd
#
dcn
#

M14/M8 series
isis 65534
is-level level-2
cost-style wide
network-entity 00.38ba.1a42.1f01.00
binding interface GigabitEthernet1/0/1/1 down-weight 10
binding interface GigabitEthernet1/0/1/2 down-weight 10
#
interface GigabitEthernet1/0/1/1
undo shutdown
isis enable 65534
dcn
#
interface GigabitEthernet1/0/1/2
undo shutdown
isis enable 65534
dcn
#
ip address 1.1.1.1 255.255.255.255
#
ip address 10.1.1.1 255.255.0.0
#
ap-id 2000
sysname ap2000
esn 391092333866236
admin 2.2.2.2
login-user sys-admin login-password %^%#(p@y@~'n3/4m<"=;YyWDZIyvCQuK5D1JbuYk^ODQ%^%#
login-user sys-admin sftp-directory cfcard:/
#
ap-user
local-user sys-admin password cipher %^%#otll=pnt1#I_[1TE|k'F9-RT!@>rGAa%<&J@q9H&%^%#
inner-connect GigabitEthernet0/1/1 binding GigabitEthernet1/0/1/1
remote-interface GigabitEthernet0/1/2 binding GigabitEthernet1/0/1/1
#
ap-id 2001
sysname ap2001
esn 391092333000298
admin 3.3.3.3
login-user sys-admin login-password %^%#/md1*$flA+)0\t.0B"43,q{>+2*)f-k&PWLDzjcL%^%#
login-user sys-admin sftp-directory cfcard:/
#
ap-user
local-user sys-admin password cipher %^%#(1F!FQJ[FP&+-H@%pe)G5h9r:g$)DF&19m@N\T(9%^%#
inner-connect GigabitEthernet0/1/1 binding GigabitEthernet1/0/1/2
#
interface NULL0
#
hostname
area 0.0.0.0

M14/M8 series
network 0.0.0.0 255.255.255.255

#
!one by running the ne-ip X.X.X.X <MASK> command after the device being online.
dcn
bandwidth ethernet 1024
bandwidth pos 1024
#
#
ssh client publickey dsa ecc rsa rsa_sha2_256 rsa_sha2_512
#
ssh client cipher aes256_gcm aes128_gcm aes256_ctr aes192_ctr aes128_ctr
ssh client hmac sha2_512 sha2_256
ssh client key-exchange dh_group_exchange_sha256
#
ssh client 172.16.1.1 assign rsa-key 172.16.1.1
#
#
local-aaa-server
#
return

NetEngine 8000 M14, M8 and M4 V800R023C00SPC500 Configuration Guide 04 Interface and Data Link

Uploaded by

Copyright:

Available Formats

NetEngine 8000 M14, M8 and M4 V800R023C00SPC500 Configuration Guide 04 Interface and Data Link

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

NetEngine 8000 M14, M8 and M4 V800R023C00SPC500 Configuration Guide 04 Interface and Data Link

Uploaded by

Copyright:

Available Formats

HUAWEI NetEngine 8100 M14/M8, NetEngine

8000 M14K/M14/M8K/M8/M4 & NetEngine 8000E

HUAWEI TECHNOLOGIES CO., LTD.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Issue 01 (2023-09-30) Copyright © Huawei Technologies Co., Ltd. i

Issue 01 (2023-09-30) Copyright © Huawei Technologies Co., Ltd. ii

1.1.2.1.2 Principles of Transmission Alarm Customization and Suppression.........................................................141

Issue 01 (2023-09-30) Copyright © Huawei Technologies Co., Ltd. iii

1.1 Interface and Data Link

1.1.1 Interface Management Configuration

1.1.1.1 Interface Management Feature Description

1.1.1.1.1 Overview of Interface Management

A logical interface does not require additional hardware resources, thereby

Issue 01 (2023-09-30) Copyright © Huawei Technologies Co., Ltd. 1

interfaces in the interface group. In this manner, interfaces in a group are

1.1.1.1.2 Understanding Interface Management

Interface Numbering Rules

Interface Views and Prompts

Issue 01 (2023-09-30) Copyright © Huawei Technologies Co., Ltd. 2

GE interface GE interface view Run [~HUAWEI-

Issue 01 (2023-09-30) Copyright © Huawei Technologies Co., Ltd. 3

Interface Command View Oper Prompt

10GE interface 10GE interface view Run [~HUAWEI-

Issue 01 (2023-09-30) Copyright © Huawei Technologies Co., Ltd. 4

Interface Command View Oper Prompt

25GE interface 25GE interface view Run [~HUAWEI-25GE0/2/0]

40GE interface 40GE interface view Run [~HUAWEI-40GE0/2/0]

100GE interface 100GE interface view Run [~HUAWEI-100GE0/1/0]

Issue 01 (2023-09-30) Copyright © Huawei Technologies Co., Ltd. 5

Interface Command View Oper Prompt

200GE interface 200GE interface view Run [~HUAWEI-200GE0/1/0]

400GE interface 400GE interface view Run [~HUAWEI-400GE0/1/0]

XGE interface XGE interface view Run [~HUAWEI-

Issue 01 (2023-09-30) Copyright © Huawei Technologies Co., Ltd. 6

Interface Command View Oper Prompt

CPOS interface CPOS interface view Run [~HUAWEI-Cpos0/3/0]

POS interface POS interface view Run [~HUAWEI-Pos0/3/0]

50GE interface 50GE interface view Run [~HUAWEI-50GE0/1/0]

Issue 01 (2023-09-30) Copyright © Huawei Technologies Co., Ltd. 7

Interface Command View Oper Prompt

50|100GE 50|100GE interface view Run [~HUAWEI-50|

FlexE-50G FlexE-50G interface view Run [~HUAWEI-

FlexE-100G FlexE-100G interface view Run [~HUAWEI-

Issue 01 (2023-09-30) Copyright © Huawei Technologies Co., Ltd. 8

Interface Command View Oper Prompt

FlexE-400G FlexE-400G interface view Run [~HUAWEI-

FlexE-10G FlexE-10G interface view Run [~HUAWEI-

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

Sub-interface Sub-interface view Run the [~HUAWEI-

Eth-Trunk Eth-Trunk Run the [~HUAWEI-Eth-Trunk2]

Issue 01 (2023-09-30) Copyright © Huawei Technologies Co., Ltd. 9

Interface Command View Operation Prompt

VE interface VE interface view Run the [~HUAWEI-Virtual-

Global VE Global VE Run the [~HUAWEI-Global-VE0]

VLANIF VLANIF interface Run the [~HUAWEI-Vlanif2]

Loopback Loopback Run the [~HUAWEI-LoopBack2]

Null interface Null interface Run the [~HUAWEI-NULL0]

IP-Trunk IP-Trunk interface Run the [~HUAWEI-Ip-Trunk2]

Tunnel Tunnel interface Run the [~HUAWEI-Tunnel 2]