• Note: On Huawei devices, OSPF PRC is enabled by default.

• If the interval for triggering route calculation is long, the network convergence
speed is affected.

• The first timeout period of the intelligent timer is fixed. Before the intelligent
timer expires, if an event that triggers the timer occurs, the next timeout period
of the intelligent timer becomes longer.
• Command: [Huawei-ospf] lsa-originate-interval { 0 | { intelligent-timer max-
interval start-interval hold-interval | other-type interval } }
▫ 0: sets the interval for updating LSAs to 0s, that is, cancels the interval of 5s
for updating LSAs.

▫ intelligent-timer: uses the intelligent timer to set the update interval for
router-LSAs and network-LSAs.

▫ max-interval: specifies the maximum interval for updating OSPF LSAs. The
value is an integer ranging from 1 to 120000, in milliseconds. The default
value is 5000.

▫ start-interval: specifies the initial interval for updating OSPF LSAs. The value
is an integer ranging from 0 to 60000, in milliseconds. The default value is
500.

▫ hold-interval: specifies the hold interval for updating OSPF LSAs. The value
is an integer ranging from 1 to 60000, in milliseconds. The default value is
1000.

▫ other-type: sets an update interval for OSPF LSAs except router-LSAs and
network-LSAs.

▫ interval: specifies the interval for updating LSAs. The value is an integer
ranging from 0 to 10, in seconds. The default value is 5.
• Command: [Huawei-ospf-1] lsa-arrival-interval { interval | intelligent-timer
max-interval start-interval hold-interval }
▫ interval: specifies the interval for receiving LSAs. The value is an integer
ranging from 0 to 10000, in milliseconds.

▫ intelligent-timer: uses the intelligent timer to set the receive interval for
LSAs.

▫ max-interval: specifies the maximum interval for receiving OSPF LSAs. The
value is an integer ranging from 1 to 120000, in milliseconds. The default
value is 1000.

▫ start-interval: specifies the initial interval for receiving OSPF LSAs. The value
is an integer ranging from 0 to 60000, in milliseconds. The default value is
500.

▫ hold-interval: specifies the hold interval for receiving OSPF LSAs. The value
is an integer ranging from 1 to 60000, in milliseconds. The default value is
500.
• Command: [Huawei-ospf-1] spf-schedule-interval { interval1 | intelligent-timer
max-interval start-interval hold-interval | millisecond interval2 }
▫ interval1: specifies an interval for OSPF SPF calculation. The value is an
integer ranging from 1 to 10, in seconds.

▫ intelligent-timer: uses the intelligent timer to set the interval for OSPF SPF
calculation.

▫ max-interval: specifies the maximum interval for OSPF SPF calculation. The
value is an integer ranging from 1 to 120000, in milliseconds. The default
value is 10000.

▫ start-interval: specifies the initial interval for OSPF SPF calculation. The
value is an integer ranging from 1 to 60000, in milliseconds. The default
value is 500.

▫ hold-interval: specifies the hold interval for OSPF SPF calculation. The value
is an integer ranging from 1 to 60000, in milliseconds. The default value is
1000.

▫ millisecond interval2: specifies an interval for OSPF SPF calculation. The

value is an integer ranging from 1 to 10000, in milliseconds.
• Node-and-link protection:

▫ As shown in the right figure, traffic flows from node S to node D. The link
cost satisfies the node-and-link protection inequality. If the primary link
fails, node S switches the traffic to the backup link. This ensures that the
traffic interruption time is less than 50 ms.

• OSPF IP FRR protects traffic against either a link failure or a node-and-link

failure.

▫ Link protection takes effect when the traffic to be protected flows along a
specified link.

▫ Node-and-link protection takes effect when the traffic to be protected

flows along a specified device. Node-and-link protection takes precedence
over link protection.
• OSPF periodically sends Hello packets to neighbors to detect faults. It takes more
than 1s to detect a fault. By default, when the OSPF Dead timer expires, the
neighbor is considered invalid. The default value of the OSPF Dead timer is 40s.
With the development of technologies, voice, video, and video on demand (VOD)
services are widely used. These services are sensitive to the packet loss rate and
delay. When the traffic rate reaches gigabit per second (Gbit/s), long-time fault
detection causes a large number of packets to be lost. This cannot meet high
reliability requirements of the carrier-class network.

• BFD for OSPF is introduced to resolve this problem. After BFD for OSPF is
configured in a specified process or on a specified interface, the link status can be
rapidly detected and fault detection can be completed in milliseconds. This
speeds up OSPF convergence when the link status changes.
• Prerequisites:
▫ Before using BFD to quickly detect link faults, run the bfd command in the
system view to enable BFD globally.
• The BFD configuration on an interface takes precedence over that in a process. If
BFD is enabled on an interface, the BFD parameters on the interface are used to
establish BFD sessions.
• OSPF IP FRR can be associated with BFD.
▫ During the OSPF IP FRR configuration, the underlying layer needs to fast
respond to a link status change so that traffic can be switched to the
backup link immediately.
▫ OSPF IP FRR and BFD can be bound to rapidly detect link faults. This
ensures that traffic is rapidly switched to the backup link in the case of link
failures.
• Command: [Huawei-ospf-1] bfd all-interfaces { min-rx-interval receive-
interval | min-tx-interval transmit-interval | detect-multiplier multiplier-
value | frr-binding }
▫ min-rx-interval receive-interval: specifies an expected minimum interval for
receiving BFD packets from the peer. The value is an integer ranging from
10 to 2000, in milliseconds. The default value is 1000.
▫ min-tx-interval transmit-interval: specifies a minimum interval for sending
BFD packets to the peer. The value is an integer ranging from 10 to 2000, in
milliseconds. The default value is 1000.
▫ detect-multiplier multiplier-value: specifies a local detection multiplier.
The value is an integer ranging from 3 to 50. The default value is 3.
▫ frr-binding: binds the BFD session status to the link status of an interface.
If a BFD session goes down, the physical link of the bound interface also
goes down, triggering traffic to be switched to the backup link.
• This course describes only equal-cost routes, default routes, and LSA filtering. For
other information, see HCIP-Datacom-Core Technology.
• Command: [Huawei-ospf-1] maximum load-balancing number

▫ number: specifies the maximum number of equal-cost routes for load

balancing. The value range varies according to the device model. For
details, see the product documentation of the corresponding device.
• Default routes have all 0s as the destination address and mask. A device uses a
default route to forward packets when no matching route is available.
Hierarchical management of OSPF routes prioritizes the default route carried in
Type 3 LSAs over the default route carried in Type 5 or Type 7 LSAs.

• Common area:

▫ By default, routers in a common OSPF area do not generate default routes.

To enable a router in a common OSPF area to advertise a default route to
OSPF, run the default-route-advertise command on the router. After the
command is run, the router generates a default ASE LSA (Type 5 LSA) and
advertises it to the entire OSPF AS.

• Stub area:

▫ Type 5 LSAs cannot be advertised within a stub area. All routers within a
stub area can learn AS external routes only through an ABR.

▫ The ABR in a stub area automatically generates a default Type 3 LSA and
advertises it to the entire stub area. The ABR uses the default route to
divert traffic destined for a destination outside the AS to itself and then
forwards the traffic.
• Command: [Huawei-ospf-1] default-route-advertise [[always | permit-
calculate-other] | cost cost | type type | route-policy route-policy-name
[match-any]]
▫ always: An LSA that describes the default route is generated and advertised
regardless of whether the local device has an active default route that does
not belong to the current OSPF process.
▪ If always is configured, the device does not calculate the default
routes from other devices.
▪ If always is not configured, an LSA that describes the default route
can be generated only if an active default route that does not belong
to the current OSPF process exists in the routing table of the local
device.
▫ permit-calculate-other: An LSA that describes the default route is
generated and advertised only if the device has an active default route that
does not belong to the current OSPF process, and the device still calculates
the default routes from other devices.
▫ type type: specifies the type of an external route. The value is 1 or 2. The
default value is 2.
▪ 1: Type 1 external route
▪ 2: Type 2 external route
▫ route-policy route-policy-name: specifies the name of a route-policy. The
device advertises default routes according to the configuration of the route-
policy when the routing table of the device contains a default route that
matches the route-policy but does not belong to the current OSPF process.
The value is a string of 1 to 40 case-sensitive characters. If spaces are used,
the string must start and end with double quotation marks (").
• Command: [Huawei-GigabitEthernet0/0/1] ospf filter-lsa-out { all | { summary
[ acl { acl-number | acl-name } ] | ase [ acl { acl-number | acl-name } ] | nssa [
acl { acl-number | acl-name } ] } }

▫ all: filters all outgoing LSAs, except grace LSAs.

▫ summary: filters outgoing network-summary-LSAs (Type 3).

▫ ase: filters outgoing AS-external-LSAs (Type 5).

▫ nssa: filters outgoing NSSA-LSAs (Type 7).

▫ acl acl-number: specifies the number of a basic ACL. The value is an integer
ranging from 2000 to 2999.

▫ acl acl-name: specifies the name of an ACL. The value is a string of 1 to 32

case-sensitive characters. It cannot contain spaces and must start with a
letter (a to z or A to Z).
• Command: [ Huawei-ospf-1-area-0.0.0.1 ] filter { acl-number | acl-name acl-
name | ip-prefix ip-prefix-name | route-policy route-policy-name } export
▫ acl-number: specifies the number of a basic ACL. The value is an integer
ranging from 2000 to 2999.
• When the number of external LSAs (Type 5 and Type 7) imported by OSPF
exceeds the maximum number supported, excessive external LSAs cannot be
processed properly and are discarded. To address this issue, you can set a proper
upper limit for the number of non-default external LSAs in the LSDB, so as to
adjust and optimize the OSPF network.

• Command: [Huawei-ospf-1] lsdb-overflow-limit number

▫ number: specifies the maximum number of non-default external LSAs

allowed in the LSDB. The value is an integer ranging from 1 to 1000000.
• Data forwarding requirements of the marketing department:

▫ As long as the border-2 router and its uplink work properly, the data flows
of the marketing department are forwarded only through the border-2
router.

▫ As long as the core-2 router and its uplink work properly, the data flows of
the marketing department are forwarded only through the core-2 router.

• This case uses the data forwarding path of the finance department as an
example. The data forwarding path of the marketing department is not described
here.
• Type 2 external route:

▫ Because a Type 2 external route offers low reliability, its cost is considered
to be much greater than the cost of any internal route to an ASBR.

▫ Cost of a Type 2 external route = Cost of the route from an ASBR to the
destination
• The internal path cost to each ASBR is not considered during traffic egress
control.
• VPN: virtual private network

• If a VPN instance is specified for an OSPF process that is to be created, the OSPF
process belongs to this instance. Otherwise, the OSPF process belongs to the
global instance.
• Command: [Huawei-ospf-1] stub-router [ on-startup [ interval ] ]

▫ on-startup [ interval ]: specifies the interval for a device to remain as a

stub router when the device restarts or fails. The value is an integer ranging
from 5 to 65535, in seconds. The default value is 500s.

▪ If on-startup is not configured, the device is always a stub router. That

is, the cost of all routes sent by this device is 65535.

▪ If on-startup is specified, the device remains as a stub router only

when it restarts or fails. The duration is determined by interval. If
interval is not specified, the default value of 500s is used.
• Type 7 LSAs in an NSSA are translated into Type 5 LSAs.

▫ To advertise external routes imported by an NSSA to other areas, Type 7

LSAs must be translated into Type 5 LSAs. By default, the translator is the
ABR with the largest router ID in an NSSA.

▫ The propagate bit (P-bit) in the Options field of an LSA header is used to
notify a translator whether the Type 7 LSA needs to be translated into a
Type 5 LSA. A Type 7 LSA can be translated into a Type 5 LSA only when
the P-bit is set to 1 and the FA is not 0.

▫ The P-bit is not set for Type 7 LSAs generated by an ABR.

• Note: All OSPF LSAs have the same LSA header, and the P-bit is in the Options
field of the LSA header.
• As shown in the figure:

▫ Configure R5 to import direct external routes and set the IP address of the
FA to 10.1.45.5, which is used by R5 to access the destination network
segment 10.1.5.0/24.

▫ R3 translates Type 7 LSAs into Type 5 LSAs and the LSAs continue to carry
the FA 10.1.45.5.

▫ Upon receipt, R1 searches its OSPF routing table for a route to the FA and
uses the next hop address of the route as the next hop address of the
external route.

▫ Therefore, R1 will finally access the destination network segment

10.1.5.0/24 through the path R1 -> R2 -> R4 -> R5.
• GR is a fault-tolerant redundancy technique and has been widely used to ensure
non-stop forwarding of key services during an active/standby switchover or
system upgrade.
• GR reasons:
▫ Unknown: GR is triggered for an unknown reason.
▫ Software restart: GR is triggered by a command.
▫ Software reload/upgrade: GR is triggered by a software reloading or
upgrade.
▫ Switch to redundant control processor: GR is triggered by an unexpected
active/standby switchover.
• GR classification:
▫ Totally GR: When a neighbor of a router does not support GR, the router
exits the GR state.
▫ Partial GR: When a neighbor does not support GR, only the interface
associated with this neighbor exits GR, whereas the other interfaces
perform GR processing normally.
▫ Planned GR: Triggered by a command, a device is restarted or performs an
active/standby switchover. Before the device restarts or performs an
active/standby switchover, the Restarter sends Grace-LSAs.
▫ Unplanned GR: Different from the implementation of a planned GR, the
implementation of an unplanned GR is as follows: A router restarts or
performs an active/standby switchover due to a fault or other reasons,
without sending Grace-LSAs first, and enters GR after the original standby
main control board goes up. The following procedure is the same as that in
a planned GR.
• On the Restarter:
▫ In planned GR mode, after a command is run to trigger an active/standby
switchover on the Restarter, the Restarter sends a Grace-LSA to each
neighbor to notify them of the GR period and reason, and then performs an
active/standby switchover. This prevents an interruption of the neighbor
relationships due to the long time taken for the original standby main
control board to go up, which would otherwise cause a GR failure.
▫ After the original standby main control board goes up, the router notifies
the routing management (RM) module that the GR starts. After the
interfaces previously enabled with OSPF on the original standby main
control board recover, a Grace-LSA is sent immediately to notify neighbors
that the local device has started a GR. Then, another five Grace-LSAs are
sent consecutively to each neighbor to ensure reception. This
implementation is defined by vendors, but not in the protocol. The router
does not age FIB entries in this case. Therefore, the communication is
normal. If GR is not supported, the router directly ages FIB entries. As a
result, routing is interrupted. In this case, the router restarts normally (non-
GR process). The Grace-LSAs sent by the Restarter are used to notify
neighbors that the Restarter enters GR. During GR, the neighbors retain
neighbor relationships with the Restarter so that other routers are unaware
of the switchover on the Restarter.
▫ The Restarter negotiates with its neighbors to enter the standard adjacency
establishment process. The neighbor states change as follows: Down → Init
→ Exstart. Then, DD packets are exchanged to complete LSDB
synchronization. During the update of LSAs, if the LSAs (Type 1 LSAs and
Type 2 LSAs) received from a Helper do not contain the link to the local
device, it indicates that the network topology has changed or the neighbor
does not support the Helper mode. In this case, GR fails, and the local
router exits GR and restarts normally.
• Before configuring OSPF GR, complete the following tasks:

▫ Configure an IP address for each involved interface to ensure that

neighboring devices can communicate with each other at the network layer.

▫ Configure basic OSPF functions.

• NSR and GR:

▫ The system in which an AMB/SMB switchover is performed supports two

types of high-reliability protection: NSR and GR.

▫ NSR and GR, however, are mutually exclusive. That is, for a specific
protocol, only one of them can be used after a switchover.

▫ When NSR is deployed on a device, the device can still function as a GR

Helper to support the GR process of its neighbor, ensuring high reliability of
services on all nodes on the network to the greatest extent.

• Application scenario:

▫ NSF can be used if a network has low requirements for the packet loss rate
and route convergence.

▫ NSR can be used if a network has high requirements for the packet loss
rate and route convergence.

• System-level NSR is triggered in the following situations:

▫ A system fault triggers an AMB/SMB switchover.

▫ The network administrator manually triggers an AMB/SMB switchover

during a software upgrade or maintenance.

• Note: NSR fundamentals are the same in OSPF, IS-IS, and BGP. This course uses
OSPF as an example.
• High availability (HA): implements data backup from the AMB to the SMB.

• AMB and SMB: implement control plane processes.

• Line processing unit (LPU): implements forwarding plane processes.

• The functions, including PRC, intelligent timer, and FRR of IS-IS are similar to
those of OSPF and therefore not detailed here.
• SPF for route calculation: If a node on a network changes, SPF recalculates routes
for all the nodes on the network, which takes a long time, consumes a large
number of CPU resources, and consequently reduces the network-wide
convergence speed.

• I-SPF is an improvement of SPF. Unlike SPF that calculates all nodes, I-SPF
calculates only affected nodes. The SPT generated using I-SPF is the same as that
generated using SPF. This significantly decreases CPU usage and speeds up
network convergence.

• I-SPF and PRC are used together on an IS-IS network.

▫ If the SPT calculated by I-SPF changes, PRC processes all the leaves (routes)
of only the changed node.

▫ If the SPT calculated by I-SPF does not change, PRC processes only the
changed leaves (routes). For example, if IS-IS is newly enabled on an
interface of a node, the SPT on the network remains unchanged. In this
case, PRC updates only the routes of this interface, which consumes less
CPU resources.
• Command: [Huawei-isis-1] flash-flood [ lsp-count | max-timer-interval interval
| [ level-1 | level-2 ] ]

▫ lsp-count: specifies the maximum number of LSPs that can be flooded on

each interface at a time. The value is an integer ranging from 1 to 15. The
default value is 5.

▫ max-timer-interval interval: specifies the maximum interval at which LSPs

are flooded. The value is an integer ranging from 10 to 50000, in
milliseconds. The default value is 10.

▫ level-1: enables the LSP flash-flood function in the Level-1 area. If no level
is specified in the command, this function is enabled in both Level-1 and
Level-2 areas.

▫ level-2: enables the LSP flash-flood function in the Level-2 area. If no level
is specified in the command, this function is enabled in both Level-1 and
Level-2 areas.
• This course involves only equal-cost and default routes. For details about other
control methods, see HCIP-Datacom-Core Technology.
• Command: [Huawei-isis-1] maximum load-balancing number

▫ number: specifies the maximum number of equal-cost routes that

participate in load balancing. The value varies according to the device
model.

• Command: [Huawei-isis-1] nexthop ip-address weight value

▫ ip-address: specifies the IP address of the next hop. The value is in dotted
decimal notation.

▫ weight value: specifies the weight of the next hop. A smaller value
indicates a higher preference. The value is an integer ranging from 1 to 254.
• Command: [Huawei-isis-1] attached-bit advertise { always | never }

▫ always: indicates that the ATT bit is set to 1. After receiving an LSP with
ATT bit 1, a Level-1 device generates a default route.

▫ never: indicates that the ATT bit is set to 0. This prevents the Level-1 device
from generating default routes and reduces the size of the routing table.

• Although the ATT bit is defined in both Level-1 and Level-2 LSPs, it is set to 1
only in Level-1 LSPs advertised by Level-1-2 devices. Therefore, this command
takes effect only on Level-1-2 devices.

• To prevent Level-1 devices from advertising default routes to their routing tables,
perform either of the following operations:

▫ Run the attached-bit advertise never command on Level-1-2 devices to

disable them from advertising LSPs with ATT bit 1.

▫ Run the attached-bit avoid-learning command on Level-1 devices that

connect to Level-1-2 devices.

• The difference between the preceding commands lies in that the attached-bit
avoid-learning command applies to specified Level-1 devices.
• Command: [Huawei-isis-1] default-route-advertise [ always | match default |
route-policy route-policy-name ] [ cost cost | tag tag | [ level-1 | level-1-2 |
level-2 ] ] [ avoid-learning ]

▫ always: configures an IS-IS device to unconditionally advertise the default

route and set itself as the next hop in the route.

▫ match default: advertises the default route generated by another routing

protocol or IS-IS process through LSPs if such a route already exists in the
routing table.

▫ route-policy route-policy-name: specifies the name of the route-policy. A

Level-1-2 device advertises the default route to the IS-IS routing domain
only when external routes matching the route-policy exist in the routing
table of the device. This prevents routing blackholes caused by the
advertisement of the default route when link faults make some important
external routes unavailable. This route-policy does not affect the import of
external routes into IS-IS. The value is a string of 1 to 40 case-sensitive
characters, spaces not supported. If spaces are used, the string must start
and end with double quotation marks (").

▫ cost cost: specifies the cost of the default route. The value is an integer. The
value range depends on cost-style. When cost-style is narrow, narrow-
compatible, or compatible, the value ranges from 0 to 63. When cost-style
is wide or wide-compatible, the value ranges from 0 to 4261412864.
• IS-IS multi-process and multi-instance have the following characteristics:

▫ In IS-IS multi-process, processes share the same global routing table. IS-IS
multi-instance, however, uses the routing tables of VPNs, with each VPN
having a separate routing table.

▫ IS-IS multi-process allows a set of interfaces to be associated with a

specified IS-IS process. This ensures that the protocol operations in the
specified IS-IS process are confined only to this set of interfaces. In this way,
multiple IS-IS processes can work on a single router, with each process
responsible for a unique set of interfaces.

▫ When creating an IS-IS process, you can bind it to a VPN instance. The IS-IS
process then accepts and processes only the events related to the VPN
instance. When the bound VPN instance is deleted, the IS-IS process is also
deleted.

• Command: [Huawei] isis [ process-id ] [ vpn-instance vpn-instance-name ]

▫ process-id: specifies the ID of an IS-IS process. If no IS-IS process is

specified, IS-IS process 1 is started. The value is an integer ranging from 1
to 65535. The default value is 1.

▫ vpn-instance vpn-instance-name: specifies the name of a VPN instance. If

this parameter is not specified, no VPN instance is associated with the IS-IS
process. The value is a string of 1 to 31 case-sensitive characters. If spaces
are used, the string must start and end with double quotation marks (").
• After LSP fragment extension is configured, the system prompts you to restart
the IS-IS process if information is lost because LSPs overflow. After the IS-IS
process is restarted, the originating system loads as much routing information as
possible to its LSPs. The information that cannot be loaded is placed in the LSPs
of virtual systems for transmission. The originating system then notifies other
routers of its relationship with the virtual systems through TLV 24.

• Note: the additional and normal system IDs must be unique throughout a routing
domain.
• Mode-1 implementation:
▫ Virtual systems participate in SPF calculation. The LSPs advertised by the
originating system contain information about links to each virtual system.
Similarly, the LSPs advertised by each virtual system contain information
about links to the originating system. In this way, virtual systems function
like physical routers that connect to the originating system.
▫ Mode-1 is a transitional mode used to support earlier versions that are
incapable of LSP fragment extension. In these earlier versions, IS-IS cannot
identify TLV 24. As a result, the LSPs sent by a virtual system must look like
LSPs sent by an originating system.
▫ Precautions:
▪ The LSPs sent by a virtual system must contain the same area address
and overload bit as those in LSPs sent by an originating system. Other
TLVs must also be the same.
▪ The neighbor of a virtual system must point to an originating system,
and the metric is the maximum value minus 1. The neighbor of the
originating system must point to the virtual system, and the metric
must be 0. This ensures that the virtual system is the downstream
node of the originating system when other routers calculate routes.
• Mode-2 implementation:
▫ Virtual systems do not participate in SPF calculation. All the routers on the
network know that the LSPs generated by the virtual systems actually
belong to the originating system.
▫ IS-IS working in mode-2 can identify TLV 24, which is used as the basis for
calculating an SPT and routes.
• Note: In both modes, the originating system and virtual systems must include
TLV 24 in their LSPs whose LSP Number is 0 to indicate which is the originating
system.
• Command: [Huawei-isis-1] lsp-fragments-extend [ [ level-1 | level-2 | level-1-
2 ] | [ mode-1 | mode-2 ] ]

▫ level-1: enables LSP fragment extension in Level-1.

▫ level-2: enables LSP fragment extension in Level-2.

▫ level-1-2: enables LSP fragment extension in Level-1-2.

▫ mode-1: allows routers to be compatible with other routers running earlier

versions that are incapable of LSP fragment extension.

▫ mode-2: requires all routers to support LSP fragment extension.

• Command: [Huawei-isis-1] virtual-system virtual-system-id

▫ virtual-system-id: specifies a virtual system ID of an IS-IS process. The

length is 6 bytes (48 bits), and the format is XXXX.XXXX.XXXX.
• Background:

▫ After an active/standby switchover is performed on a device, because the

device has not stored any information about the neighbor relationships
established before the restart, the initial Hello packets sent by the device
carry an empty neighbor list. After receiving the Hello packets, a neighbor
(Helper device) performs the two-way neighbor relationship check. After
the neighbor detects that it is not in the neighbor list in the Hello packets
sent by the Restarter, the neighbor tears down the neighbor relationship.
The neighbor then generates new LSPs and floods the topology changes to
all other devices in the area. The other devices in the area then calculate
routes based on their new LSDBs, leading to routing interruptions or
routing loops.

▫ The IETF defined the GR standard (RFC 3847) for IS-IS. The protocol
restarts in which the FIB is retained and the protocol restarts in which the
FIB is not retained are both processed, preventing route flapping and traffic
interruptions caused by protocol restarts.
• Notes:

▫ In Step 2, if the neighbor does not have the GR Helper capability, it ignores
the Restart TLV and resets the adjacency with the GR Restarter according to
normal IS-IS processing.

▫ In Step 3, the Restarter sets the value of the T3 timer to the Holdtime of
the neighbor, preventing neighbor disconnection during the GR, which
would otherwise cause routes to be recalculated on the whole network.
• During the restarting, the Restarter starts the T1, T2, and T3 timers at the same
time after the protocol restart. The value of the T1 timer indicates the longest
time during which the GR Restarter waits for the Hello packet used for GR
acknowledgement from the GR Helper. The value of the T2 timer indicates the
longest time during which the system waits for the LSDB synchronization. The
value of the T3 timer indicates the longest time allowed for a GR. The device
cancels the T3 timer after synchronization of Level-1 and Level-2 LSDBs
completes during the GR. If LSDB synchronization has not completed when the
T3 timer expires, the GR fails.
• Additional remarks for Step 1:

▫ If RR is cleared, starting has completed.

▫ The IIH packet in which SA is set indicates that the Restarter requests its
neighbor to suppress the advertisement of their adjacency until the
neighbor receives an IIH packet in which SA is cleared from the Restarter.

• Additional remarks for Step 2:

▫ If GR is supported, the neighbor re-initiates the adjacency with the GR

Restarter and deletes the description of the adjacency from the LSPs to be
sent. In addition, the neighbor ignores the link connected to the GR
Restarter when performing SPF calculation until it receives an IIH packet in
which SA is cleared from the GR Restarter.

▫ If GR is not supported, the neighbor ignores the Restart TLV, resets the
adjacency with the GR Restarter, replies with an IIH packet that does not
contain the Restart TLV, and returns to normal IS-IS processing. In this case,
the neighbor does not suppress the advertisement of the adjacency with the
GR Restarter. In the case of a P2P link, the neighbor also sends a CSNP.
• Usage scenario of the graceful-restart no-impact-holdtime command:

▫ On an IS-IS network, if GR is configured on a device, its IS-IS neighbors may

automatically update corresponding neighbor Holdtimes. Specifically, the
Holdtimes are changed to 60s if they are less than 60s, and remain
unchanged if they are greater than or equal to 60s. Consequently, the
minimum Holdtime value is 60s after the update. If one of the neighbors
fails in non-GR scenarios, it takes at least 60s for the other end to detect
the failure. As a result, a large number of packets may be discarded within
this period, reducing network security and reliability.

▫ To resolve this problem, you can run the graceful-restart no-impact-

holdtime command so that the Holdtimes of neighbors remain unchanged
in an IS-IS GR scenario. In this way, neighbor status can be fast detected,
implementing rapid network convergence.

• graceful-restart interval interval-value and graceful-restart t2-interval

interval-value commands
▫ interval interval-value: specifies a value of the GR T3 or T2 timer. The value
is an integer that ranges from 30 to 1800, in seconds.

▫ It is recommended that the value of the T3 timer is greater than that of the
T2 timer. Otherwise, the GR may fail.
• Usage scenario of the graceful-restart suppress-sa command:

▫ A router does not maintain the forwarding status when it starts for the first
time (excluding the post-GR cases). If it is not the first time that a router
has started, the LSPs generated when the router ran last time may still exist
in the LSP database of other routers on the network.

▫ Because the sequence numbers of LSP fragments are also reinitialized when
the router starts, the LSP copies stored on other routers seem to be newer
than the LSPs generated after the local router starts. This leads to a
temporary "blackhole" on the network, and the blackhole persists until the
router regenerates its own LSPs and advertises them with the largest
sequence number.

▫ If the neighbors of the router are suppressed from advertising adjacencies

to the router during the startup of the router until the router advertises
updated LSPs, the preceding problem can be prevented. Therefore, you can
run the graceful-restart suppress-sa command to suppress the SA bit in
the Restart TLV.
1. ACD

2. B
3. A
• As shown in the figure:

▫ R1 and R2 reside in AS 101, and establish an IBGP peer relationship with

each other. R3 and R4 reside in AS 102, and each establishes an EBGP peer
relationship with R2.

▫ R1 is directly connected to three subnets: Net1, Net2, and Net3. R1

advertises routes to the three subnets to its BGP routing table.

▫ R2 can filter out the Net2 route through BGP route control so that R2's BGP
routing table does not contain the Net2 route.

▫ R3 and R4 can implement BGP route control by modifying the attributes of

the Net1 and Net3 routes, respectively. In this way, when a device in AS 102
accesses Net1, R3 is preferentially selected as the egress device; when the
device accesses Net3, R4 is preferentially selected as the egress device.

• Note: For details about the ACL, IP prefix list, filter-policy, route-policy, and BGP
path attributes, see the "HCIP-Datacom-Core Technology" course.
• A regex has the following functions:

▫ Checks and obtains the sub-character string that matches a specific rule in
the character string.

▫ Replaces the character string based on matching rules.

• Note: The parentheses () can be used to define the scope and priority of an
operator. For example, gr(a|e)y is equivalent to gray|grey.
• Type 1:

▫ ^a.$: matches a character string that starts with the character a and ends
with any single character, for example, a0, a!, ax, and so on.

▫ ^100_: matches a character string starting with 100, for example, 100, 100
200, 100 300 400, and so on.

▫ ^100$: matches only 100.

▫ 100$|400$: matches a character string ending with 100 or 400, for example,
100, 1400, 300 400, and so on.

▫ ^\(65000\)$: matches (65000) only.

• Type 2:

▫ abc*d: matches the character c zero or multiple times, for example, abd,
abcd, abccd, abcccd, abccccdef, and so on.

▫ abc+d: matches the character c once or multiple times, for example, abcd,
abccd, abcccd, abccccdef, and so on.

▫ abc?d: matches the character c zero times or once, for example, abd, abcd,
abcdef, and so on.

▫ a(bc)?d: matches the character string bc zero times or once, for example,
ad, abcd, aaabcdef, and so on.
• The AS_Path attribute is a well-known mandatory attribute of BGP. All BGP
routes must carry this attribute. This attribute records the numbers of all the ASs
that a BGP route traversed during transmission.

• The value of the AS_Path attribute can be 0, 1, or a set of multiple AS numbers.

• Multiple matching rules (each in permit or deny mode) can be specified in an
AS_Path filter. These rules are in the OR relationship, which means that if a route
matches one of the matching rules, the route is considered to match the AS_Path
filter.

• Command: [Huawei] ip as-path-filter {as-path-filter-number | as-path-filter-

name} {deny | permit} regular-expression
▫ as-path-filter-number: specifies the number of an AS_Path filter. The value
is an integer ranging from 1 to 256.

▫ as-path-filter-name: specifies the name of an AS_Path filter. The value is a

string of 1 to 51 case-sensitive characters. It cannot be comprised of only
digits. If spaces are used, the string must start and end with double
quotation marks (").

▫ deny: sets the matching mode of the AS_Path filter to deny.

▫ permit: sets the matching mode of the AS_Path filter to permit.

▫ regular-expression: specifies a regex for the AS_Path filter. The value is a

string of 1 to 255 characters and can contain spaces.

• The default behavior of an AS_Path filter is deny. That is, if a route is not
permitted in a filtering, the route fails to match the AS_Path filter. If all matching
rules in an AS_Path filter work in deny mode, all BGP routes are denied by the
filter. To prevent this problem, configure a matching rule in permit mode after
one or more matching rules in deny mode so that the routes except for those
denied by the preceding matching rules can be permitted by the filter.
• The community attribute is an optional transitive attribute. It can identify the
routes with the same characteristics, regardless of the scattered route prefixes
and various AS numbers. That is, a specific community value can be assigned to
some routes so that these routes can be matched against the community value
instead of the network number or mask. Then, a corresponding routing policy
can be applied to the matched routes.
• Command: [Huawei-route-policy] apply community { community-number |
aa:nn | internet | no-advertise | no-export | no-export-subconfed } [ additive ]

▫ community-number | aa:nn: specifies a community number for a

community attribute. A maximum of 32 community numbers can be
specified at a time using this command. The value of community-number is
an integer ranging from 0 to 4294967295. The values of aa and nn are also
integers ranging from 0 to 65535.

▫ internet: allows the matched routes to be advertised to any peers. By

default, all routes belong to the Internet community.

▫ no-advertise: prevents the matched routes from being advertised to any

peer. After a device receives a route with this attribute, it cannot advertise
this route to any other BGP peers.

▫ no-export: prevents the matched routes from being advertised outside the
local AS but allows them to be advertised to other sub-ASs in the local AS.
After a device receives a route with this attribute, it cannot advertise this
route outside the local AS.

▫ no-export-subconfed: prevents the matched routes from being advertised

outside the local AS or to other sub-ASs in the local AS. After a device
receives a route with this attribute, it cannot advertise this route to any
other sub-ASs.

▫ additive: adds community attributes to the routes that match the filtering
conditions.
• Command: [Huawei] ip community-filter { basic comm-filter-name | basic-
comm-filter-num } { permit | deny } [ community-number | aa:nn | internet |
no-export-subconfed | no-advertise | no-export ]
▫ basic comm-filter-name: specifies the name of a basic community filter.
The value is a string of 1 to 51 case-sensitive characters. It cannot be
comprised of only digits.
▫ basic-comm-filter-num: specifies the number of a basic community filter.
The value is an integer ranging from 1 to 99.
▫ deny: sets the matching mode of the community filter to deny.
▫ permit: sets the matching mode of the community filter to permit.
▫ community-number: specifies a community number. The value is an integer
ranging from 0 to 4294967295.
▫ aa:nn: specifies a community number. A maximum of 20 community
numbers can be specified at a time using this command. The values of aa
and nn are integers ranging from 0 to 65535.
▫ internet: allows the matched routes to be advertised to any peers.
▫ no-export-subconfed: prevents the matched routes from being advertised
outside the local AS. If a confederation is used, the matched routes will not
be advertised to the other sub-ASs in the confederation.
▫ no-advertise: prevents the matched routes from being advertised to any
other peers.
▫ no-export: prevents the matched routes from being advertised outside the
local AS. If a confederation is used, the matched routes will not be
advertised outside the confederation but will be advertised to the other
sub-ASs in the confederation.
• Command: [Huawei-route-policy] if-match community-filter { basic-comm-
filter-num [ whole-match ] | adv-comm-filter-num }
• Command: [Huawei-route-policy] if-match community-filter comm-filter-name
[ whole-match ]

▫ basic-comm-filter-num: specifies the number of a basic community filter.

The value is an integer ranging from 1 to 99.

▫ adv-comm-filter-num: specifies the number of an advanced community

filter. The value is an integer ranging from 100 to 199.

▫ comm-filter-name: specifies the name of a community filter. The value is a

string of 1 to 51 case-sensitive characters. It cannot be comprised of only
digits. If spaces are used, the string must start and end with double
quotation marks (").

▫ whole-match: indicates complete matching. That is, all the community

attributes in the specified community filter must be matched. This
parameter applies only to basic community filters.
• Command: [R1] route-policy Community permit node 20

• Run this command to allow the route 10.1.2.2/32 to be advertised properly.

• Command: [Huawei-bgp-af-ipv4] peer { group-name | ipv4-address } ip-prefix
ip-prefix-name { import | export }

▫ import: applies the routing policy to the routes received from the peer or
peer group.

▫ export: applies the routing policy to the routes to be advertised to the peer
or peer group.
• Command: [Huawei-bgp] peer { group-name | ipv4-address } capability-
advertise orf [ non-standard-compatible ] ip-prefix { both | receive | send }
[ standard-match ]

▫ non-standard-compatible: indicates that the ORF capability supported by

the Huawei device is compatible with that supported by a non-Huawei
device.

▫ both: enables the local device to both send and accept ORF packets.

▫ receive: enables the local device to only accept ORF packets.

▫ send: enables the local device to only advertise ORF packets.

▫ standard-match: matches routes according to the prefix matching rules

defined in an RFC standard.
• Each peer in a peer group can be configured with its own policies for route
advertisement and acceptance.
• Command: [Huawei-bgp] group group-name [ external | internal ]

▫ group-name: specifies the name of a peer group. The value is a string of 1

to 47 case-sensitive characters. If spaces are used, the string must start and
end with double quotation marks (").

▫ external: creates an EBGP peer group.

▫ internal: creates an IBGP peer group.

• As shown in the figure, assume that static routes are used or OSPF is used to
ensure internal network reachability in AS 102. The configuration details are not
provided here.
• BGP uses TCP as its transport layer protocol and considers a TCP packet valid
only if the source IP address, destination IP address, source port number,
destination port number, and TCP sequence number in the packet are correct.
Most of the preceding parameters in a TCP packet can be obtained by attackers
without much difficulty. To protect BGP from attacks, use MD5 authentication or
keychain authentication between BGP peers to reduce the possibility of attacks.

▫ The MD5 algorithm is easy to configure and generates a single password,

which can only be manually changed.

▫ The keychain algorithm is complex to configure and generates a set of

passwords. Keychain authentication allows passwords to be changed
automatically based on configurations. Therefore, keychain authentication
is applicable to networks requiring high security.

• Note: BGP MD5 authentication and BGP keychain authentication are mutually
exclusive.
• As shown in the figure, if BGP GTSM is not enabled, the device finds that the
received numerous bogus BGP messages are destined for itself, and directly sends
them to the control plane for processing. As a result, the control plane has to
process a large number of bogus messages, causing the CPU usage to go
excessively high and the system to be unexpectedly busy.
• Command: [Huawei-bgp] peer { group-name | ipv4-address | ipv6-address }
keychain keychain-name

▫ keychain-name: specifies the name of a keychain. The value is a string of 1

to 47 case-insensitive characters. It cannot contain question marks (?). If
spaces are used, the string must start and end with double quotation marks
(").
• Command: [Huawei-bgp] peer { group-name | ipv4-address | ipv6-address }
valid-ttl-hops [ hops ]

▫ hops: specifies the number of TTL hops to be checked. The value is an

integer ranging from 1 to 255. The default value is 255. If you specify hops,
the valid range of TTL values in the messages to be checked is [255 – hops
+ 1, 255].

• Command: [Huawei] gtsm default-action { drop | pass }

▫ drop: indicates that the messages that do not match the GTSM policy
cannot pass filtering and are dropped.

▫ pass: indicates that the messages that do not match the GTSM policy can
pass filtering.

• Command: [Huawei] gtsm log drop-packet all

▫ all: indicates all boards.

• As shown in the figure:

▫ Assume that static routes are used or OSPF is used to ensure internal
network reachability in AS 101. The configuration details are not provided
here.

▫ R1 advertises the route destined for the IP address of its loopback0

interface to the BGP routing table.
• 4-byte AS numbers are extended from 2-byte AS numbers. BGP peers use a new
capability code and new optional transitive attributes to negotiate the 4-byte AS
number capability and transmit 4-byte AS numbers. This mechanism enables
communication between new speakers as well as between old speakers and new
speakers.

▫ To support 4-byte AS numbers, an open capability code 0x41 is defined in a

standard protocol for BGP connection capability negotiation. 0x41 indicates
that the BGP speaker supports 4-byte AS numbers.

▫ In addition, two new optional transitive attributes AS4_Path and

AS4_Aggregator are defined in the standard protocol to transmit 4-byte AS
information in old sessions.

▫ To set up a BGP connection between a new speaker with an AS number

greater than 65535 and an old speaker, the peer AS number on the old
speaker must be set to AS_TRANS, which is a reserved AS number with the
value being 23456.

• NetEngine 8000 series routers support configuration of 4-byte AS numbers in

either format. The formats of 4-byte AS numbers displayed in the configuration
file are the same as those used by users during configuration.
• Note: When transmitting routing information to an old speaker, a new speaker
encapsulates both the AS_Path and AS4_Path attributes to help transmit 4-byte
AS numbers. The AS4_Path attribute is transitive. Therefore, when the old
speaker receives the AS4_Path attribute, it transmits the AS4_Path attribute to
other speakers.
• When a new speaker sends an Update message carrying an AS number greater
than 65535 to an old speaker, the new speaker uses the AS4_Path attribute to
assist the AS_Path attribute in transferring 4-byte AS numbers. The AS4_Path
attribute is transparent to the old speaker.

▫ On the network shown in this figure, before the new speaker in AS 2.2
sends an Update message to the old speaker in AS 65002, the new speaker
replaces each 4-byte AS number (1.1 and 2.2) with 23456 (AS_TRANS) in
AS_Path; therefore, the AS_Path carried in the Update message is (23456,
23456, 65001), and the carried AS4_Path is (2.2, 1.1, 65001). Upon receiving
the Update message, the old speaker in AS 65002 transparently transmits
AS4_Path (2.2, 1.1, 65001) to another AS.

• When a new speaker receives an Update message carrying the AS_Path and
AS4_Path attributes from an old speaker, the new speaker obtains the actual
AS_Path attribute based on the reconstruction algorithm.

▫ In the figure, after the new speaker in AS 65003 receives an Update

message carrying AS_Path (65002, 23456, 23456, 65001) and AS4_Path (2.2,
1.1, 65001) from the old speaker in AS 65002, the new speaker obtains the
actual AS_Path (65002, 2.2, 1.1, 65001) through reconstruction.
• In the figure:

▫ Assume that static routes are configured or OSPF is used to ensure internal
network reachability in AS 1.1. The configuration details are not provided
here.

▫ Configure R1 to advertise the route to Loopback0's address to BGP. The

configuration details are not provided here.

• Notes:

▫ This slide uses NetEngine 8000 series routers as an example. For the 4-byte
AS number configuration on any other type of product, see the
corresponding product documentation.

▫ If you adjust the display format of 4-byte AS numbers, the matching results
in the case of filtering using AS_Path regular expressions or extended
community filters are affected. Specifically, after the display format of 4-
byte AS numbers is changed when an AS_Path regular expression or
extended community filter has been used in an export or import policy, the
AS_Path regular expression or extended community filter needs to be
reconfigured. If reconfiguration is not performed, routes may fail to match
the export or import policy, leading to a network fault.
• RR-related roles:
▫ RR: BGP device that reflects the routes learned from an IBGP peer to other
IBGP peers. An RR is similar to the designated router (DR) on an OSPF
network.
▫ Client: IBGP peer whose routes are reflected by the RR to other IBGP peers.
In an AS, clients only need to be directly connected to the RR.
▫ Non-client: IBGP device that is neither an RR nor a client. In an AS, full-
mesh connections still must be established between non-clients and RRs,
and between all non-clients.
▫ Originator: device that originates routes in an AS. The Originator_ID
attribute is used to prevent routing loops in a cluster.
▫ Cluster: a set of RRs and their clients. The Cluster_List attribute is used to
prevent routing loops between clusters.
• When configuring a BGP router as an RR, you also need to specify a client of the
RR. A client does not need to be configured because it is not aware that an RR
exists on the network.
• Rules for an RR to advertise routes:
▫ After learning routes from non-clients, the RR selects and advertises the
optimal route to all its clients.
▫ After learning routes from clients, the RR selects and advertises the optimal
route to all its non-clients and clients (except the originating client).
▫ After learning routes learned from EBGP peers, the RR selects and
advertises the optimal route to all its clients and non-clients.
• The route advertisement rules for hierarchical RR networking are the same as
those for single-cluster RR networking.

• The following factors need to be considered for hierarchical RR design:

▫ Size of the top-layer full-mesh topology: If the number of full-mesh IBGP

connections has exceeded the management capacity, hierarchical RR
networking can be deployed.

▫ Number of alternate paths: This factor affects load balancing and resource
consumption. More layers reduce the number of links for load balancing
but require fewer router resources.
1. D
2. A

3. A
• When Layer 2 isolation and Layer 3 interworking are used, you can enable intra-
VLAN proxy ARP on the VLANIF interface and configure arp-proxy inner-sub-
vlan-proxy enable to implement communication between hosts in the same
VLAN.
• A MAC address table is used by the switch to record the mappings between
learned MAC addresses of other devices and interfaces on which MAC addresses
are learned, as well as VLANs to which the interfaces belong.

• When performing Layer 2 switching, the device searches the MAC address table
according to the destination MAC address of the packet. If the MAC address table
contains the entry corresponding to the destination MAC address of the packet
and the interface that receives the packet is different from the interface
corresponding to the entry, the packet is directly forwarded through the
outbound interface in the entry. If they are the same, the packet is discarded.

• If the MAC address table does not contain the entry matching the destination
MAC address of the packet, the device broadcasts the packet through all the
interfaces in the VLAN except the interface that receives the packet.
• To prevent unauthorized users from modifying MAC address entries of some key
devices (such as servers or uplink devices), you can configure the MAC address
entries of these devices as static MAC address entries. Static MAC address entries
take precedence over dynamic MAC address entries and can hardly be modified
by unauthorized users.
• To prevent useless MAC address entries from occupying the MAC address table
and prevent hackers from attacking user devices or networks using MAC
addresses, you can configure untrusted MAC addresses as blackhole MAC
addresses. In this way, when the device receives a packet with the destination or
source MAC address as the blackhole MAC address, the device discards the
packet without modifying the original MAC address entry or adding a MAC
address entry.
• To reduce manual configuration of static MAC address entries, Huawei S series
switches are enabled with dynamic MAC address learning by default. The aging
time needs to be set properly for dynamic MAC address entries so that the switch
can delete unneeded MAC address entries.
• To improve network security and prevent the device from learning invalid MAC
addresses and incorrectly modifying the original MAC address entries in the MAC
address table, you can disable MAC address learning on a specified interface or
all interfaces in a specified VLAN so that the device does not learn new MAC
addresses from these interfaces.
• You can limit the number of MAC address entries that can be learned on the
device. When the number of learned MAC address entries reaches the limit, the
device does not learn new MAC address entries. You can also configure an action
to take when the number of learned MAC address entries reaches the limit. This
prevents MAC address entries from being exhausted and improves network
security.
• Dynamic secure MAC addresses can be aged out using two modes: absolute
aging and relative aging.

▫ Absolute aging time: If the absolute aging time is set to 5 minutes, the
system calculates the lifetime of each MAC address every minute. If the
lifetime is larger than or equal to 5 minutes, the secure dynamic MAC
address is aged immediately. If the lifetime is smaller than time minutes,
the system determines whether to delete the secure dynamic MAC address
after 1 minute.

▫ Relative aging time: If the value is set to 5 minutes, the system checks
whether there is traffic from a specified dynamic secure MAC address every
1 minute. If no traffic is received from the secure dynamic MAC address,
this MAC address is aged out 5 minutes later.

• By default, an interface in error-down state can be restored only after the restart
command is run in the interface view.

• To enable an interface in error-down state to automatically go Up after a period

of time, run the error-down auto-recovery cause port-security interval
interval-value command in the system view. In this command, interval-value
specifies the period of time after which an interface in error-down state can
automatically go Up.
• You can configure port security and set the maximum number of secure MAC
addresses learned by an interface on networks demanding high access security.
Port security enables the switch to convert MAC addresses learned by an
interface into secure MAC addresses and to stop learning new MAC addresses
after the maximum number of learned MAC addresses is reached. In this case,
the switch can only communicate with devices with learned MAC addresses. If
the switch receives packets with a nonexistent source MAC address after the
number of secure MAC addresses reaches the limit, the switch considers that the
packets are sent from an unauthorized user, regardless of whether the
destination MAC address of packets is valid, and takes the configured action on
the interface. This prevents untrusted users from accessing these interfaces,
improving security of the switch and the network.

• Port security enables the switch to convert MAC addresses learned by an

interface into secure MAC addresses and to stop learning new MAC addresses
after the maximum number of learned MAC addresses is reached. In this case,
the switch can only communicate with devices with learned MAC addresses. If
the number of access users changes, you can restart the device or set the aging
time of secure MAC address entries to update the MAC address entries. If you do
not want to change the MAC address entries of stable access users, you can
enable the sticky MAC function on the interface. After the configuration is saved,
the MAC address entries will not be updated or lost.
• The port-security protect-action command configures the protection action to be
used when the number of learned MAC addresses on an interface exceeds the
upper limit or static MAC address flapping is detected.

▫ protect

▪ Discards packets with new source MAC addresses when the number
of learned MAC addresses exceeds the limit.

▪ When static MAC address flapping occurs, the interface discards the
packets with this MAC address.

▫ restrict

▪ Discards packets with new source MAC addresses and sends a trap
message when the number of learned MAC addresses exceeds the
limit.

▪ When static MAC address flapping occurs, the interface discards the
packets with this MAC address and sends a trap.

▫ shutdown

▪ Sets the interface state to error-down and generates a trap when the
number of learned MAC addresses exceeds the limit.

▪ Sets the interface state to error-down and generates a trap when

static MAC address flapping occurs.
• Check secure MAC addresses.

▫ Run the display mac-address security [ vlan vlan-id | interface-type

interface-number ] * [ verbose ] command to check dynamic secure MAC
address entries.

▫ Run the display mac-address sec-config [ vlan vlan-id | interface-type

interface-number ] * [ verbose ] command to check static secure MAC
address entries.

▫ Run the display mac-address sticky [ vlan vlan-id | interface-type

interface-number ] * [ verbose ] command to check sticky MAC address
entries.
• By default, the MAC address learning priority of an interface is 0. A larger priority
value indicates a higher MAC address learning priority. If the same MAC address
is learned on interfaces that have different priorities, the MAC address entry on
the interface with the highest priority overrides that on the other interfaces.

• When the device is configured to prevent MAC address entries from being
overridden on interfaces with the same priority, if the authorized device is
powered off, the MAC address entry of the bogus device is learned. After the
authorized device is powered on again, its MAC address cannot be learned.
Exercise caution when using this feature. If a switch interface is connected to a
server, when the server is powered off, other interfaces can learn the same MAC
address as the server. When the server is powered on again, the switch cannot
learn the correct MAC address.
• Whether all Huawei switches support MAC address flapping detection depends
on the switch model.
• After MAC address flapping occurs, the following actions are performed: 1. A trap
is generated and reported. 2. GE0/0/2 on SW1 is disabled from sending and
receiving packets. 3. GE0/0/2 on SW1 is disabled from sending and receiving
packets with a specified MAC address.

• When an interface is blocked:

▫ When detecting MAC address flapping in VLAN 2, the device blocks the
interface where MAC address flapping occurs.

▫ The interface will be blocked for 10s (specified by the block-time keyword).
The blocked interface cannot receive or send data.

▫ After 10 seconds, the interface is unblocked and starts to send and receive
data. If MAC address flapping is not detected within 20 seconds, the
interface is unblocked. If MAC address flapping is detected again on the
interface within 20 seconds, the switch blocks the interface again. If the
switch still detects MAC address flapping on the interface, the switch
permanently blocks the interface. The retry-times parameter specifies the
number of times that MAC address flapping is detected.
• By default, global MAC address flapping detection is enabled on a Huawei switch.
Therefore, the switch performs MAC address flapping detection in all VLANs by
default.

• In some scenarios, MAC address flapping detection needs to be disabled in some

VLANs. You can configure a VLAN whitelist for MAC address flapping detection.

• If an interface is set to enter the Error-Down state due to MAC address flapping,
the interface does not automatically restore to the Up state by default.

• To enable an interface in Error-Down state to automatically go Up, run the

error-down auto-recovery cause mac-address-flapping interval time-value
command in the system view.

• If MAC address flapping occurs on an interface and the interface is removed from
the VLAN, you can run the following command in the system view to implement
automatic recovery of the interface:

▫ mac-address flapping quit-vlan recover-time time-value

• Insecure networks are vulnerable to MAC address attacks. If attackers send large
numbers of forged packets with different source MAC addresses to the switch, its
MAC address table will be filled with unwanted address entries. As a result, the
device is unable to learn the source MAC addresses of valid packets.

• You can limit the number of MAC address entries that can be learned on the
device. When the number of learned MAC address entries reaches the limit, the
device does not learn new MAC address entries. You can also configure an action
to take when the number of learned MAC address entries reaches the limit. This
prevents MAC address entries from being exhausted and improves network
security.
• When Switch3 and Switch4 are incorrectly connected, the MAC address of
GE0/0/1 on Switch2 is learned by GE0/0/2, causing GE0/0/2 to enter the Error-
Down state.

• You can run the display mac-address flapping record command to check MAC
address flapping records.
• A CAK is not directly used to encrypt data packets. Instead, the CAK and other
parameters derive the encryption key of data packets. The CAK can be delivered
during 802.1X authentication or statically configured.

• MKA is used for negotiation of MACsec data encryption keys.

• The SAK is derived based on the CAK using an algorithm and is used to encrypt
data transmitted over secure channels. The MKA limits the number of packets
that can be encrypted by each SAK. When the PNs encrypted by a SAK are
exhausted, the SAK is updated. For example, on a 10 Gbit/s link, the SAK can be
updated every 4.8 minutes.

• The key server determines the encryption scheme and the MKA entity that
distributes the key.
• In the outbound direction of an interface, the device can block broadcast packets,
unknown multicast packets, and unknown unicast packets.
• Traffic suppression can also rate-limit ICMP packets by setting a threshold. A
large number of ICMP packets may be sent to the CPU without traffic
suppression. When this happens, other service functions may become abnormal.
• The threshold can be configured for incoming packets on interfaces. The system
discards the traffic exceeding the threshold and forwards the traffic within the
threshold. In this way, the system limits the traffic rate in an acceptable range.

• Note that traffic suppression can also block outgoing packets on interfaces.

• In storm control, rate thresholds are configured for incoming packets only on
interfaces. When the traffic exceeds the threshold, the system rejects the packets
of this particular type on the interface or shuts down the interface.
• Run the display flow-suppression interface interface-type interface-number
command to check the traffic suppression configuration.

• When traffic suppression is configured in both the interface view and VLAN view,
the configuration in the interface view takes precedence over the configuration in
the VLAN view.
• The difference between traffic suppression and storm control is as follows: The
storm control function can take the punishment action (block or shutdown) for
an interface, whereas the traffic suppression function only limits the traffic on an
interface.
• In traffic suppression, rate thresholds are configured for incoming packets on
interfaces. When the traffic exceeds the threshold, the system discards excess
traffic and allows the packets within the threshold to pass through. In this way,
the traffic is limited within a proper range. Note that traffic suppression can also
block outgoing packets on interfaces.

• In storm control, rate thresholds are configured for incoming packets only on
interfaces. When the traffic exceeds the threshold, the system rejects the packets
of this particular type on the interface or shuts down the interface.
• No DHCP relay agent is deployed:
▫ In the discovery stage, the DHCP client broadcasts a DHCP Discover
message to discover DHCP servers. Information carried in a DHCP Discover
message includes the client's MAC address (Chaddr field), parameter
request list (Option 55), and broadcast flag (Flags field, determining
whether the response should be sent in unicast or broadcast mode).
▫ In the offer stage, a DHCP server selects an address pool on the same
network segment as the IP address of the interface receiving the DHCP
Discover message, and selects an idle IP address from the address pool. The
DHCP server then sends a DHCP Offer message carrying the allocated IP
address to the DHCP client.
▫ In the request stage, if multiple DHCP servers reply with a DHCP Offer
message to the DHCP client, the client accepts only the first received DHCP
Offer message. The client then broadcasts a DHCP Request message
carrying the selected DHCP server identifier (Option 54) and IP address
(Option 50, with the IP address specified in the Yiaddr field of the accepted
DHCP Offer message). The DHCP Request message is broadcast so as to
notify all the DHCP servers that the DHCP client has selected the IP address
offered by a DHCP server. Then the other servers can allocate IP addresses
to other clients.
▫ In the acknowledgement stage, after receiving the DHCP ACK message, the
DHCP client broadcasts a gratuitous ARP packet to check whether any
other terminal on the network segment uses the IP address allocated by the
DHCP server.
• After the dhcp snooping enable command is run on an interface, the interface
forwards received DHCP Request messages to all trusted interfaces and discards
received DHCP Reply messages.

• After an interface on which the dhcp snooping trusted command is run receives a
DHCP Request message, it forwards the message to all other trusted interfaces. If
there are no other trusted interfaces, it discards the message. After receiving a
DHCP Reply message, it forwards the message only to the interfaces that are
connected to clients and have the dhcp snooping enable command configured. If
such interfaces cannot be found, it discards the DHCP Reply message.
• DHCP snooping binding entries are aged out when the DHCP release expires, or
the entries are deleted when users send DHCP Release messages to release IP
addresses.
• In a DHCP starvation attack, an attacker continuously applies for a large number
of IP addresses from the DHCP server to exhaust IP addresses in the address pool
of the DHCP server. As a result, the DHCP server cannot allocate IP addresses to
authorized users. The DHCP message contains the Client Hardware Address
(CHADDR) field. This field is filled in by a DHCP client, indicating the hardware
address of the client, that is, the MAC address of the client. The DHCP server
assigns IP addresses based on the CHADDR field, and assigns different IP
addresses if values of the CHADDR field are different. The DHCP server cannot
distinguish valid CHADDR field. By exploiting this vulnerability, an attacker fills a
different value in the CHADDR field of a DHCP message each time the attacker
applies for an IP address. In this way, the attacker forges different users to
request IP addresses.
• In a DHCP starvation attack, an attacker continuously applies for a large number
of IP addresses from the DHCP server to exhaust IP addresses in the address pool
of the DHCP server. As a result, the DHCP server cannot allocate IP addresses to
authorized users. The DHCP message contains the Client Hardware Address
(CHADDR) field. This field is filled in by a DHCP client, indicating the hardware
address of the client, that is, the MAC address of the client. The DHCP server
assigns IP addresses based on CHADDR values. The DHCP server cannot
distinguish valid CHADDR values. By exploiting this vulnerability, an attacker fills
a different value in the CHADDR field of a DHCP message each time the attacker
applies for an IP address. In this way, the attacker forges different users to
request IP addresses.

• To prevent starvation attacks, DHCP snooping checks whether the source MAC
address of a DHCP Request message is the same as the CHADDR value on an
interface. If they are the same, the interface forwards the DHCP Request
message. If they are different, the interface discards the message. To check the
consistency between the source MAC address and the CHADDR field on an
interface, run the dhcp snooping check dhcp-chaddr enable command on the
interface.

• An attacker may continuously change both the MAC address and CHADDR value
simultaneously, and uses the same CHADDR value as the MAC address each
time. In this way, the consistency check between the source MAC address and the
CHADDR can be avoided.
• As shown in the figure, the attacker uses the ARP mechanism to enable PC1 to
learn the mapping between IP-S and MAC2 and enable the server to learn the
mapping between IP1 and MAC2. When PC1 sends an IP packet to the DHCP
server, the destination IP address is IP-S and the source IP address is IP1. The
destination MAC address of the frame in which the IP packet is encapsulated is
MAC2 and the source MAC address is MAC1, so the frame reaches PC2 first. After
receiving the frame, the attacker changes the destination MAC address to MAC-S
and the source MAC address to MAC2, and then sends the frame to the server.
When the DHCP server sends an IP packet to PC1, the destination IP address is
IP1 and the source IP address is IP-S. The destination MAC address of the frame
in which the IP packet is encapsulated is MAC2 and the source MAC address is
MAC-S, so the frame reaches PC2 first. After receiving the frame, the attacker
changes the destination MAC address to MAC1 and the source MAC address to
MAC2, and then sends the frame to PC1.

• The IP packets transmitted between PC1 and the DHCP server traverse the
attacker's device (man-in-the-middle). Therefore, the attacker can easily obtain
some information in the IP packets and use the information to perform other
damage operations. The attacker can easily tamper with the DHCP messages
transmitted between PC1 and the DHCP server. These messages are encapsulated
in UDP packets, and UDP packets are encapsulated in IP packets. In this way, the
attacker can directly attack the DHCP server.
• A DHCP man-in-the-middle attack is a spoofing IP/MAC attack. Preventing DHCP
man-in-the-middle attacks is equivalent to preventing spoofing IP/MAC attacks.

• The switch running DHCP snooping listens to DHCP messages exchanged

between the client and the DHCP server, and obtains the MAC address of the
client from the DHCP messages. The MAC address (value of the CHADDR field in
the DHCP messages, client's IP address (IP address allocated by the DHCP server
to the corresponding CHADDR), and other information are stored in a database,
which is also called the DHCP snooping binding table. The switch running DHCP
snooping creates and dynamically maintains the DHCP snooping binding table.
The binding table contains the MAC address, IP address, IP address lease, and
VLAN ID of each client.

• As shown in the figure, if the DHCP server assigns IP address IP1 to PC1 and IP
address IP2 to PC2, IP1 is bound to MAC1 and IP2 is bound to MAC2. These
bindings are stored in the DHCP snooping binding table. To enable the server to
learn the mapping between IP1 and MAC2, the attacker sends an ARP Request
packet in which the source IP address is set to IP1 and the source MAC address is
set to MAC2. After receiving the ARP Request packet, the switch checks the
source IP address and source MAC address in the packet and finds that the IP-
MAC (IP1-MAC2) mapping does not match any entry in the DHCP snooping
binding table. Therefore, the switch discards the ARP Request packet, this
effectively prevents spoofing IP/MAC attacks.

• To prevent IP/MAC spoofing attacks, run the arp dhcp-snooping-detect enable

command in the system view of the switch.
• If the unauthorized host forges the IP address of an authorized host to obtain
network access rights, configure IPSG on the switch's user-side interface or VLAN.
The switch then checks the IP packets received by the interface and discards the
packets from unauthorized hosts to prevent IP address spoofing attacks.

• Generally, IPSG is configured on the interfaces or VLANs of the access device

connected to users.
• After the binding table is generated, the IPSG-enabled device delivers ACL rules
to the specified interface or VLAN according to the binding table, and then
checks all IP packets against the ACL rules. The switch forwards the packets from
hosts only when the packets match binding entries, and discards the packets that
do not match binding entries. When the binding table is modified, the IPSG-
enabled device delivers the ACL rules again.
• By default, if IPSG is enabled in the scenario where no binding table is generated,
the switch rejects all IP packets except DHCP Request messages.
• A static binding entry contains the MAC address, IP address, VLAN ID, and
inbound interface. IPSG checks received packets against all options in a static
binding entry.
• A dynamic binding entry contains the MAC address, IP address, VLAN ID, and
inbound interface. You can specify the options to be checked, and IPSG filters the
packets received by interfaces according to the specified options. By default, the
IPSG-enabled device checks packets against all the four options.
▫ Common check items:
▪ Source IP address
▪ Source MAC address
▪ Source IP address + Source MAC address
▪ Source IP address + Source MAC address + Interface
▪ Source IP address + Source MAC address + Interface + VLAN
• With the rapid development of services such as mobile office, online shopping,
instant messaging, Internet finance, and Internet education, the network needs to
carry a growing number of services and the services carried are more and more
important. As such, uninterrupted transmission of service data urgently needs to
be fulfilled in the network development process.

• In this example, the firewall is deployed at the egress of the enterprise network,
and services between the intranet and external network are forwarded by the
firewall. Such services will be all interrupted if the firewall is faulty. Therefore, if
only one device is deployed in a key position of the network, the network may be
interrupted due to a single point of failure, regardless of the reliability of this
single device. Therefore, in network architecture design, a key position on the
network usually has two network devices planned for high availability.

• A firewall is a stateful inspection device. It inspects the first packet of a flow and
establishes a session to record packet status information (including the source IP
address, source port number, destination IP address, destination port number,
and protocol). Subsequent packets of the flow are then forwarded according to
the session entry. Only those matching this entry will be forwarded. Packets that
do not match this entry will be discarded by the firewall.
• Each firewall has a VGMP group. A VGMP group can be in any of the following
states:

▫ Initialize: indicates the temporary initial status of a VGMP group after hot
standby is enabled.

▫ Load Balance: When the priority of the local VGMP group is the same as
that of the peer VGMP group, the VGMP groups at both ends are in the
Load Balance state.

▫ Active: When the priority of the local VGMP group is higher than that of the
peer VGMP group, the local VGMP group is in Active state.

▫ Standby: When the priority of the local VGMP group is lower than that of
the peer VGMP group, the local VGMP group is in Standby state.

• After two firewalls are deployed in hot standby mode, the VGMP groups on them
have the same priority, and both are in Load Balance state. In this case, the two
firewalls are in load balancing state.

• You can configure VRRP or manually specify a standby device to enable the two
firewalls to work in active/standby mode. The VRRP configuration method applies
to networks where the firewalls connect to Layer 2 switches, and the method of
manually specifying a standby device applies to other hot standby networks.

• A firewall has an initial VGMP group priority. When an interface or a card on the
firewall becomes faulty, the initial VGMP group priority is decreased by a specific
value.

• This course uses USG6000 V500R001 as an example.

• To ensure successful switchover, key configuration commands and status
information (such as session table information) must be synchronized between
the active and standby firewalls.

• To achieve this, Huawei firewalls use HRP to back up dynamic status data and
key configuration commands between the active and standby firewalls.

• In active/standby backup mode, the active firewall synchronizes configuration

commands and status information to the standby firewall.

• In load balancing mode, both firewalls are active. Therefore, if both firewalls
synchronize commands to each other, command overwrite or conflict problems
may occur. To centrally manage the configurations of the two firewalls, you need
to configure the designated active and standby devices.
• The firewall implements virtualization in the following aspects:

▫ Resource virtualization: Each virtual system has dedicated resources,

including interfaces, VLANs, policies, and sessions. The resources are
assigned by the public system administrator and managed by virtual system
administrators.

▫ Configuration virtualization: Each virtual system has its own virtual system
administrator and configuration interface. Virtual system administrators can
only manage their own virtual systems.

▫ Security function virtualization: Each virtual system has independent

security policies and other security functions, which apply only to packets of
the virtual system.

▫ Route virtualization: Virtual systems maintain separate routing tables,

independent and isolated from each other. Currently, only static routes can
be virtualized.

• With the preceding virtualization techniques, each virtual system can function as
a dedicated firewall that is exclusively managed by its administrator.
• As shown in the figure, virtual interfaces of virtual systems and the public system
are connected to form virtual links. You can consider virtual systems and the
public system as independent devices, and virtual interfaces as communication
interfaces between them. Virtual systems can communicate with each other and
with the public system after their virtual interfaces are added to security zones
and routes and policies are configured for device communications.
• Communication between a virtual system and the public system involves two
scenarios: from a virtual system to the public system, and from the public system
to a virtual system. The packet forwarding processes in the two scenarios are
slightly different.

• This slide uses the access from a virtual system to the public system as an
example. Packets are processed in both the virtual system and public system
according to the firewall's packet forwarding process. As such, you must perform
key configurations such as security policies and routes in both the virtual system
and public system.
• On a firewall, virtual systems are isolated by default. As such, hosts attached to
different virtual systems cannot communicate with each other. To enable
communication between two hosts attached to different virtual systems,
configure security policies and routes. In this example, virtual system A initiates
an access request to virtual system B. The request packet enters virtual system A,
which then processes the packet according to the firewall's packet forwarding
process. Then, the request packet enters virtual system B, which also processes
the packet according to the firewall's forwarding process.

• As both virtual systems need to process the packet according to the firewall's
packet forwarding process, you must perform key configurations such as security
policies and routes in both virtual systems.
• The preceding configuration allows only the unidirectional communication from
vsysa to vsysb. If hosts in vsysb need to access hosts in vsysa, you must configure
the routes and security policies for access from vsysb to vsysa.
1. ABD

2. A
• MPLS is derived from the Internet Protocol version 4 (IPv4). Core MPLS
technologies can be extended to support multiple network protocols, such as the
Internet Protocol version 6 (IPv6), Internet Packet Exchange (IPX), Appletalk,
DECnet, and Connectionless Network Protocol (CLNP). MPLS uses label-based
forwarding to replace IP forwarding. A label is a short connection identifier of
fixed length that is meaningful only to a local end.
• MPLS label operations will be introduced in following courses.
• In traditional IP forwarding that uses the longest match algorithm, all packets
that match the same route belong to the same FEC.

• In MPLS, the most common example of FEC is: Packets whose destination IP
addresses match the same IP route are considered to belong to the same FEC.
• An LSP is composed of an ingress LSR, an egress LSR, and a variable number of
transit LSRs. Therefore, an LSP can be considered as an ordered set of these LSRs.

• An LSP must be established before a packet is forwarded; otherwise, the packet

fails to traverse an MPLS domain.

• LSPs can be established in static or dynamic mode.

• An LSP is a unidirectional path from the start point to the end point. If
bidirectional data communication is required, an LSP for return traffic needs to
be established between the two ends.
• The EXP field is defined in early MPLS standards and is an experimental field.
Actually, this field is mainly used for CoS. To avoid ambiguity, this field is
renamed Traffic Class in RFC 5462.
• When the upper layer is the MPLS label stack, the Type field in the Ethernet
header is 0x8847, and the Protocol field in the PPP header is 0x8281.
• The label spaces of different LSRs are independent of each other, indicating that
each router can use the entire label space.
• If the ingress LSRs of packets belonging to the same FEC are different, the LSPs
for forwarding the packets are different.

• An LSR uses the same way to process packets in the same FEC, regardless of
where the packets' inbound interfaces are the same.

• An LSP is composed of the forwarding actions of LSRs, and the label forwarding
table determines the forwarding action. Therefore, establishing a label
forwarding table can also be considered as establishing an LSP.

• As shown in the figure, the three packets belong to the same FEC, FEC1, because
they have the same destination. However, as their ingress LSRs are different, the
packets are forwarded along different LSPs (LSP1, LSP2, and LSP3, respectively).
The labels assigned by different LSRs to the same FEC can be the same or
different, because labels are valid only on their local LSRs.
• Control plane:

▫ The control plane is connectionless. It generates and maintains routing and

label information.

▫ The control plane includes:

▪ Routing information base (RIB): stores static routes, direct routes, and
routes generated by IP routing protocols. Routes can be selected from
the RIB to guide packet forwarding.

▪ Label information base (LIB): stores and manages labels statically

configured and dynamically generated by label switching protocols
(such as LDP and RSVP).

• Forwarding plane

▫ The forwarding plane, also called the data plane, is connection-oriented. It

forwards common IP packets and MPLS labeled packets.

▫ The forwarding plane includes:

▪ Forwarding information base (FIB): stores forwarding information

that is generated based on the routing information extracted from
the RIB. The forwarding information is used to guide common IP
packet forwarding.

▪ Label forwarding information base (LFIB): stores label-based

forwarding information to guide MPLS labeled packet forwarding.
• Static LSP:

▫ A static LSP is meaningful only to the local node, and the local node cannot
be aware of the entire LSP.

• Dynamic LSP:

▫ Other label distribution protocols:

▪ Resource Reservation Protocol-Traffic Engineering (RSVP-TE): an

extension based on RSVP. RSVP-TE is used to establish constraint-
based routed LSPs (CR-LSPs). Unlike LDP LSPs, CR-LSPs support
parameters, such as bandwidth reservation requests, bandwidth
constraints, link colors, and explicit paths.

▪ Multiprotocol Border Gateway Protocol (MP-BGP): an extension based

on BGP. MP-BGP distributes labels to MPLS VPN routes and inter-AS
VPN labeled routes.
• Tunnel ID: an ID automatically allocated to a tunnel, providing a unified interface
for upper-layer applications (such as VPN and route management) that use the
tunnel. A tunnel ID is 32 bits long and is valid only on the local device. During
MPLS forwarding, LSRs find matching FIB entries, ILMs, and NHLFEs based on
tunnel IDs.
• An ingress LSR searches the FIB table (to learn FTN information) and NHLFE
table to guide packet forwarding.

• When an IP packet enters an MPLS domain, the ingress searches the FIB to check
whether the tunnel ID corresponding to the destination IP address is 0x0.

▫ If the tunnel ID is 0x0, the ingress LSR performs IP forwarding for the
packet.

▫ If the tunnel ID is not 0x0, the ingress LSR performs MPLS forwarding for
the packet.
• A transit LSR searches for ILMs and NHLFEs to guide MPLS packet forwarding.
• The egress LSR searches the ILM table to guide MPLS packet forwarding.
• An outgoing label occupies the label space of the downstream LSR, but the label
distribution mode used by the downstream space is uncertain. As such, the value
of an outgoing label ranges from 16 to 1048575.

• An incoming label occupies the label space of the current LSR. When a static LSP
is used, the value of an incoming label ranges from 16 to 1023.
1. AC

2. B
• LDP mentioned in this course refers to that defined in RFC 3036 for the first time.
This protocol has been replaced by RFC 5036.

• Other label distribution protocols include MP-BGP and RSVP.

• This course takes the device-based label space as an example.
• LDP messages are classified into four types by function: discovery, session,
advertisement, and notification.

▫ Discovery messages: announce and maintain the presence of LSRs on a

network. Hello messages belong to this category.

▫ Session messages: establish, maintain, and terminate sessions between LDP

peers. Initialization and KeepAlive messages belong to this category.

▫ Advertisement messages: generate, change, and delete label mappings for

FECs.

▫ Notification messages: provide advisory information and signal error

information.

• LDP messages are carried over UDP or TCP, with the port number being 646.
Discovery messages, which are used to discover peers, are carried over UDP.
Other LDP messages must be transmitted in a reliable and ordered manner.
Therefore, LDP uses TCP to establish sessions. Session, advertisement, and
notification messages are transmitted over TCP.
• An LDP header is 10 bytes long. It consists of three parts: Version, PDU Length,
and LDP Identifier.
▫ The Version field occupies 2 bytes. It indicates the LDP version number. The
current version number is 1.
▫ The PDU Length field occupies 2 bytes. It indicates the packet length in
bytes, excluding the Version and PDU Length fields.
▫ The LDP Identifier field (that is, LDP ID) occupies 6 bytes. The first 4 bytes
uniquely identify an LSR, and the last 2 bytes identify the label space of the
LSR.
• An LDP message consists of five parts.
▫ The U field occupies 1 bit, which is an unknown message. When an LSR
receives an unknown message, the LSR returns a notification message to
the message originator if the U field is 0, but ignores the message and does
not respond with a notification message if the U field is 1.
▫ Message Length occupies 2 bytes. It indicates the total length of Message
ID, Mandatory Parameters, and Optional Parameters, in bytes.
▫ Message ID occupies 32 bits. It identifies a message.
▫ Each of the Mandatory Parameters and Optional Parameters fields has a
variable length.
▫ Message Type indicates a specific message type. Currently, common
messages defined by LDP include Notification, Hello, Initialization,
KeepAlive, Address, Address Withdraw, Label Mapping, Label Request, Label
Abort Request, Label Withdraw, and Label Release.
• The LDP session negotiation process can be described through the state machine.
As shown in the figure, there are five states. They are Non-Existent, Initialized,
OpenRec, OpenSent, and Operational.

▫ Non-Existent: It is the initial state of an LDP session. In this state, both LSRs
send Hello messages to elect the active LSR. After a TCP connection
establishment success event is received, the state changes to Initialized.

▫ Initialized: In this state, the active LSR sends an Initialization message to the
passive LSR, sets the session state to OpenSent, and waits for an
Initialization message. The passive LSR waits for the Initialization message
sent by the active LSR. If the parameters in the received Initialization
message are accepted, the passive LSR sends Initialization and KeepAlive
messages, and sets the session state to OpenRec. When the active and
passive LSRs receive any non-initialization message or the waiting period
times out, both of them set the session state to Non-Existent.

▫ OpenSent: It is a state after the active LSR sends an Initialization message.

In the OpenSent state, the active LSR waits for the passive LSR to respond
to the Initialization and KeepAlive messages. If the parameters in the
received Initialization message are accepted, the active LSR sets the session
state to OpenRec. However, if the parameters are not accepted or the
Initialization message times out, the active LSR tears down the TCP
connection and sets the session state to Non-Existent.
• In addition to the basic discovery mechanism, the extended discovery mechanism
is supported, which can be used to discover indirectly connected remote
adjacencies. For details, see RFC5036.

• LDP transport addresses are used to establish TCP connections with peers.

▫ Before establishing an LDP session, two LSRs need to establish a TCP

connection to exchange LDP packets.

▫ A transport address of an LSR is contained in LDP Hello messages, through

which an LSR can learn the transport addresses of its peers.

▫ After two LSRs discover each other and learn each other's transport address
through Hello messages, the LSRs attempt to perform the TCP three-way
handshake (based on the transport addresses), and exchange LDP
Initialization messages, Label Mapping messages, and so on. All these
messages use the transport addresses of the two ends as source and
destination IP addresses.

▫ An LSR must have a route to the transport address of its peer.

▫ By default, the transport address for a device on a public network is the LSR
ID of the device, and the transport address for a device on a private
network is the primary IP address of an interface on the device.

▫ The mpls ldp transport-address command can be run in the interface view
to change a transport address.
• LDP session states:

▫ NonExistent: initial state of an LDP session. In this state, the two ends send
Hello messages to each other. After the TCP connection establishment
success event is triggered, the session enters the Initialized state.

▫ Initialized: The LDP session is being initialized.

▫ OpenSent: The active LSR sends an Initialization message to the passive LSR
and waits for a reply.

▫ Open Recv: LDP peers at both ends of the LDP session wait for a KeepAlive
message from each other after the session enters the initialization state. If
they receive each other's KeepAlive message, the LDP session enters the
Operational state.

▫ Operational: The LDP session is established successfully.

• Label assignment: An LSR assigns a label from the local label space and binds it
with a FEC.

• Label distribution: An LSR notifies the upstream LSR of the binding between
labels and FECs.

• When the DU label advertisement mode is used, an LSR can assign labels to all
its peers by default. Specifically, each LSR can distribute label mappings to all its
peers, regardless of whether the LSR is an upstream or a downstream one. If an
LSR distributes labels only to upstream peers, it must identify its upstream and
downstream nodes based on routing information before sending Label Mapping
messages. An upstream node cannot send Label Mapping messages to its
downstream node.
• An LSR advertises label mappings to an upstream peer only after receiving Label
Request messages from the upstream peer.
• The label distribution control mode works with the label advertisement mode:

▫ If the network shown in the figure uses the DU label advertisement mode,
R2 and R3 can actively notify the upstream LSR of the label binding for the
FEC 192.168.4.0/24 even if the upstream LSR does not send Label Request
messages and R2 and R3 do not receive label binding information from the
downstream LSR.

▫ If the network uses the DoD label advertisement mode, R2 and R3 can
notify the upstream LSR of the label binding for the FEC 192.168.4.0/24
given that R2 and R3 have received Label Request messages from the
upstream LSR, regardless of whether R2 and R3 have received label binding
information from the downstream LSR.
• In ordered label distribution control mode, an LSR can send a Label Mapping
message to its upstream node only when the LSR receives Label Mapping
messages of a FEC from the downstream of the FEC or when the LSR is the
egress of an LSP.

▫ If the network shown in the figure uses the DU label advertisement mode,
an LSR sends the label binding information of the FEC 192.168.4.0/24 to its
upstream node only after the LSR receives the label binding information of
the FEC from its downstream node, even if the upstream node has sent
Label Request messages. Therefore, the initiator for LSP establishment must
be an egress LSR (R4 in this example).

▫ If the network uses the DoD label advertisement mode, an LSR advertises
the label binding information of the FEC 192.168.4.0/24 to the upstream
node only after the LSR receives Label Request messages from the
upstream node as well as the label binding information of the FEC from the
downstream node. Therefore, a Label Request message can be initiated by
the ingress LSR (R1) only. After a Label Request is sent hop by hop to the
egress LSR (R4), R4 advertises a Label Mapping message to the upstream
LSR to establish an LSP.
• If MPLS is deployed on an IP network, an LSR uses the IP routing table to
determine whether a label mapping is received from the next hop.

• In liberal mode, a new LSP can be quickly established when routes change,
because all received labels are retained, which is the biggest advantage of this
mode. The disadvantage is that unnecessary label mappings are distributed and
maintained.

▫ In DU label advertisement mode, if the liberal label retention mode is used,

R3 retains the labels of the FEC 192.168.1.0/24 sent by all LDP peers (R2
and R5 in this example), regardless of whether R2 and R5 are the next hops
of the routes to 192.168.1.0/24 in the IP routing table.

▫ In DoD label advertisement mode, if the liberal label retention mode is

used, an LSR requests labels from all LDP peers. However, the DoD label
advertisement mode is generally used together with the conservative label
retention mode.
• The advantage of the conservative mode is that only the labels that will be used
to forward data are retained and maintained, thereby saving the label space.

▫ In DU label advertisement mode, an LSR may receive Label Mapping

messages for the same network segment (FEC) from multiple LDP peers. As
shown in the figure, R3 receives Label Mapping messages for the network
segment 192.168.1.0/24 from both R2 and R5. If the conservative label
retention mode is used, R3 retains only the label sent by the next hop R2
and discards the label sent by the non-next hop R5.

▫ In DoD label advertisement mode, an LSR uses routing information to

determine its next hop and requests labels only from the next hop.

• If the next hop of a FEC changes, either of the following situations occurs:

▫ In liberal label retention mode, the LSR can use an existing label advertised
by a non-next hop LSR to quickly establish an LSP. The liberal mode
requires more memory and label space.

▫ In conservative label retention mode, the LSR retains the labels advertised
by the next hop only. This mode saves memory and label space but
consumes more time to reestablish the LSP.

▫ An LSR that has a limited label space usually uses the conservative mode
and DoD mode.
• During label advertisement, R3 is the egress of the FEC 192.168.3.0/24. During
label distribution, R3 assigns label 3 to the FEC and advertises the label binding
information to R2.

• During data forwarding, R2, as the penultimate hop to 192.168.3.0, finds that the
outgoing label value is 3. Then, R2 removes the label header and forwards the IP
packet to R3. R3 only needs to query the FIB once to obtain the corresponding
forwarding information, improving the forwarding efficiency.
• Run the label advertise { explicit-null | implicit-null | non-null } command in the
MPLS view to configure the label to be assigned to the penultimate hop.

• You can specify one of the following parameters:

▫ implicit-null: is the default value. If this parameter is set, an egress assigns

an implicit null label with the value of 3 to the penultimate hop.

▫ explicit-null: If this parameter is set, an egress assigns an explicit null label

with the value of 0 to the penultimate hop. The explicit-null parameter can
be set if MPLS QoS attributes need to be used.

▫ non-null: If this parameter is set, an egress assigns a common label with a

value greater than or equal to 16 to the penultimate hop.
• Currently, Huawei devices use the DU + Ordered + Liberal modes by default.

• For a packet that enters the MPLS domain from R1 and is destined for
192.168.4.0/24, R1 is the ingress LSR, and R4 is the egress LSR.
• Note: By default, 32-bit host IP routes are used to trigger LSP establishment. You
can manually trigger the establishment of an LSP with non-32-bit host IP routes.
• Note: If R2 fails, OSPF routes re-converge. The next hop of the route
192.168.4.0/24 in the routing table of R1 is switched to R3. In this case, R1 uses
the label advertised by R3 for 192.168.4.0/24.
• When R1 receives an IP packet destined for 192.168.4.1, it searches the FIB for a
forwarding entry matching the destination IP address of the packet, and finds
that the tunnel ID in the matching entry is not 0. As such, R1 continues to search
for an NHLFE matching the tunnel ID, pushes a label to the IP packet, and
forwards the packet. The outbound interface is GE 0/0/0, the next hop is R2, and
the outgoing label is 1021. Therefore, R1 adds a label header to the packet and
forwards the packet.
• When R2 receives a packet with label 1021, it searches for a matching ILM entry
and an NHLFE matching the ILM entry. Then, R2 changes the label of the packet
to 1041 and forwards the packet through the matching outbound interface.
• When R4 receives a packet with label 1041, it searches for a matching ILM entry
and finds that the operation type is pop. R4 then performs a pop operation to
remove the outer label from the packet. The packet then becomes a standard IP
packet, and therefore R4 performs the standard IP forwarding on the packet.

• When R4 forwards the packet, it searches the LFIB and FIB. How can the
forwarding efficiency be improved on the egress LSR (R4)?
• BGP routes can also be used to trigger LDP LSP establishment. This trigger policy
is not covered in this course.
1. C

2. B
• Unless otherwise specified, MPLS VPN refers to BGP/MPLS IP VPN.
• MPLS VPN backbone networks can also be constructed by enterprises themselves,
with technical implementation similarly to that of carriers. This course focuses on
the scenario where enterprises purchase MPLS VPN services from carriers.
• CE: an edge device on a user network. A CE provides interfaces that are directly
connected to a carrier network. A CE can be a router, switch, or host. CEs are
usually unaware VPNs and do not need to support MPLS.
• PE: an edge device on a carrier network and directly connected to a CE. On an
MPLS network, PEs process all VPN services, and therefore PEs must have high
performance.
• P: a backbone router on a carrier network and not directly connected to a CE. P
devices need only to provide basic MPLS forwarding capabilities and do not
maintain VPN information.
• The meaning of a site can be understood from the following aspects:
▫ A site is a group of IP systems that can communicate without using carrier
networks.
▫ Sites are classified based on topological relationships between devices
rather than the geographical locations of devices. In the preceding figure,
the networks in provinces X and Y of company A need to communicate
through the backbone network of the carrier. Therefore, the two networks
are considered as two sites. If a physical private line is added between the
CEs on the networks of provinces X and Y, the two networks can
communicate without the need of the carrier network. In this case, the two
networks are considered as one site.
• Relationship between sites and VPNs:
▫ Sites connected to the same service provider network can be classified into
different collections based on configured policies. Only sites that belong to
the same collection can access each other, and this collection is defined as a
VPN.
▫ Devices at a site can belong to multiple VPNs. In other words, a site can
belong to more than one VPN.
• Multiprotocol Extensions for BGP (MP-BGP): an extended BGP protocol that
supports multiple address families. For details, see related courses.
• MPLS traffic engineering (MPLS TE): steers traffic to constrained LSPs for
forwarding so that the traffic is transmitted along specified paths. MPLS TE fully
uses network resources and provides bandwidth and QoS guarantee without the
need for hardware upgrades. It minimizes network costs.
• Intranet networking is the simplest and most typical MPLS VPN networking
scheme. The following technical implementation of MPLS VPN will be described
based on this networking scheme.
• A VPN is a private network. Different VPNs independently manage their own
address ranges, which are also called address spaces. Address spaces of different
VPNs may overlap. For example, in the preceding figure, both user X and user Y
use 192.168.1.0/24, indicating that the address spaces overlap. VPNs can use
overlapping address spaces in the following situations:

▫ They do not share the same site.

▫ They share a same site, but devices at the site do not communicate with
devices using overlapping address spaces at the other sites of the VPNs.
• For details about VRFs, see the related HCIP-Datacom-Core course.
• When configuring an RD, you need to specify only the Administrator and
Assigned Number subfields in the RD.

• Four types of RD configuration formats are available. The following two types are
commonly used:

▫ 16-bit AS number:32-bit user-defined number (for example 100:1)

▫ 32-bit IPv4 address:16-bit user-defined number (for example, 172.1.1.1:1)

• The RD structure enables each carrier to allocate RDs independently. In some

application scenarios, however, RDs must be globally unique to ensure normal
routing.
• NLRI: Network Layer Reachability Information
• For the values of address families, see RFC 3232 (Assigned Numbers).
• MP_REACH_NLRI is used to advertise reachable routes and next hop information.
It consists of one or more 3-tuples <Address Family Information, Next Hop
Network Address Information, NLRI>.
▫ Address Family Information: consists of a 2-byte Address Family Identifier
(AFI) and a 1-byte Subsequent Address Family Identifier (SAFI).
▪ The AFI identifies the network layer protocol, corresponding to the
address family value defined by "Address Family Number" in RFC
3232. For example, 1 indicates IPv4 and 2 indicates IPv6.
▪ The SAFI indicates the NLRI type. If the AFI value is 1 and the SAFI
value is 128, the address in the NLRI is an MPLS-labeled VPN-IPv4
address.
▫ Next Hop Network Address Information: consists of the 1-byte length of the
next hop network address and the variable-length next hop network
address.
▫ NLRI: consists of one or more 3-tuples <length, label, prefix>. This part will
be described in detail in the following slides.
• MP_UNREACH_NLRI is used to instruct a peer to delete unreachable routes. The
format of this attribute is as follows:
▫ AFI: same as that in the MP_REACH_NLRI attribute
▫ SAFI: NLRI type, same as that in the MP_REACH_NLRI attribute
▫ Withdrawn Routes: an unreachable route list, consisting of one or more
NLRI fields A BGP speaker can withdraw a route by adding the NLRI same
as that in a previously advertised reachable route to the Withdrawn Routes
field.
• Similar to an RD, an RT consists of three fields: Type, Administrator, and Assigned
Number. The length of an RT is also 8 bytes.

• When configuring a VPN target, you need to specify only the Administrator and
Assigned Number subfields in the VPN target. VPN targets have the same
configuration formats as RDs.
• A PE device distributes MPLS labels in either of the following ways:

▫ One label per route: Each route in a VRF is assigned one label. When many
routes exist on the network, the Incoming Label Map (ILM) maintains these
entries, requiring high router capacity.

▫ One label per instance: Each VPN instance is assigned one label. All the
routes of a VPN instance share the same label, reducing the number of
labels required.

• VPN route leaking: a process of matching VPNv4 routes against the VPN targets
of local VPN instances. After a PE receives a VPNv4 route, the PE directly matches
the route against the VPN targets of local VPN instances, without selecting the
optimal route or checking whether a desired tunnel exists.

• Tunnel recursion: A public network tunnel is required to transmit VPN traffic from
one PE to the other PE over the public network. After VPN route leaking, the
route must be successfully recursed to an LSP based on the destination IPv4
prefix before the route is added to the routing table of the corresponding VPN
instance. This means that the next hop of the IPv4 route must match an LSP.
• By default, only the peer relationships in the BGP IPv4 unicast address family
view are automatically enabled. In other words, after the peer as-number
command is run in the BGP view, the system automatically configures the peer
enable command. In other address family views, however, peering must be
enabled manually.
1. A

2. ABCD
• Note: Unless otherwise specified, MPLS VPN in this document indicates
BGP/MPLS IP VPN.
• The advantages of MPLS VPN include but are not limited to the following:

▫ One-hop access and network-wide connectivity can be implemented, and

heterogeneous media interconnection is supported. Unlike the traditional
leased line, which uses the same medium for a connection between each
pair of user devices, the MPLS VPN can provide universal services
conveniently.

▫ Elastic bandwidth can be implemented. Traffic policing technology is used

to ensure the required minimum bandwidth of users and implements best
effort scheduling for burst traffic. In addition, the basic bandwidth can be
soft expanded. That is, the basic bandwidth can be expanded within a
range based on user requirements.

▫ The MPLS VPN technology ensures the dedicated bandwidth of each VPN
to meet the requirements of different users, traffic models, and QoS of
various services.
• RFC2547 defines three inter-AS VPN solutions:

▫ Inter-AS VPN Option A (inter-provider backbones Option A) mode: The

inter-AS VPN manages its own VPN routes through dedicated interfaces
between AS boundary routers (ASBRs). This mode is also called VRF-to-VRF.

▫ Inter-AS VPN Option B (inter-provider backbones Option B) mode: ASBRs

use MP-EBGP to advertise labeled VPNv4 routes. This mode is also called
EBGP redistribution of labeled VPN-IPv4 routes.

▫ Inter-AS VPN Option C (inter-provider backbones Option C): PEs use multi-
hop MP-EBGP to advertise VPNv4 routes, which are also called multi-hop
EBGP redistribution of labeled VPN-IPv4 routes.
• Note: This course describes only the non-inter-AS MPLS VPN deployment.
• Note: 192.168.100.1 and 192.168.200.1 are the IP addresses of the interfaces on
CE1 and CE3, respectively, that are used to set up the BGP peer relationship with
PE1.
• The process of advertising routes from Spoke-CE1 to Spoke-CE2 is as follows:

▫ Spoke-CE1 advertises a route to Spoke-PE1 through EBGP.

▫ Spoke-PE1 advertises the route to the Hub-PE through IBGP.

▫ The Hub-PE imports the route into the VPN_in routing table through the
import RT attribute of the VPN instance (VPN_in), and then advertises the
route to the Hub-CE through EBGP.

▫ The Hub-CE learns the route through the EBGP connection and advertises
the route to the VPN instance (VPN_out) of the Hub-PE through another
EBGP connection.

▫ The Hub-PE advertises the route with the export RT attribute of VPN_out to
all Spoke-PEs.

▫ Spoke-PE2 advertises the route to Spoke-CE2 through EBGP.

• The process of advertising routes from Spoke-CE1 to Spoke-CE2 is as follows:

▫ Spoke-CE1 advertises a route to Spoke-PE1 through OSPF 100.

▫ Spoke-PE1 advertises the route to the Hub-PE through IBGP.

▫ The Hub-PE imports the route to the VPN_in routing table through the
import RT attribute of the VPN instance (VPN_in). After the BGP route is
imported into OSPF 100, the route transmitted from Spoke-PE1 is
advertised to the Hub-CE.

▫ The Hub-CE receives the route through OSPF 100. After route import is
configured, the route is advertised to OSPF 200, and then OSPF 200
advertises the route to the Hub-PE.

▫ The VPN instance (VPN_out) of the Hub-PE imports the route of OSPF 200
multi-instance and advertises the route with the export RT attribute to all
Spoke-PEs.

▫ Spoke-PE2 advertises the route to Spoke-CE2 through OSPF 100.

• The process of advertising routes from Spoke-CE1 to Spoke-CE2 is as follows:

▫ Spoke-CE1 advertises a route to Spoke-PE1 through OSPF 100.

▫ Spoke-PE1 advertises the route to the Hub-PE through IBGP.

▫ The Hub-PE imports the route into the VPN_in routing table through the
import RT attribute of the VPN instance (VPN_in), and then advertises the
route to the Hub-CE through EBGP.

▫ The Hub-CE learns the route through the EBGP connection and advertises
the route to the VPN instance (VPN_out) of the Hub-PE through another
EBGP connection.

▫ The Hub-PE advertises the route with the export RT attribute of VPN_out to
Spoke-PE2.

▫ Spoke-PE2 advertises the route to Spoke-CE2 through OSPF 100.

• The following takes the advertisement of the route destined for 192.168.1.0/24
from Spoke-CE1 to Spoke-CE2 as an example. The process is as follows:

▫ Spoke-CE1 advertises a route to Spoke-PE1 through EBGP.

▫ Spoke-PE1 advertises the route to the Hub-PE through IBGP.

▫ The Hub-PE imports the route to the VPN_in routing table through the
import RT attribute of the VPN instance (VPN_in) and advertises the route
to the Hub-CE through OSPF 100.

▫ Hub-CE learns the route through OSPF 100 and advertises the route to the
Hub-PE through OSPF 200.

▫ The VPN instance (VPN_out) of the Hub-PE imports the route of OSPF 200
and advertises the route with the export RT attribute of VPN_out to all
Spoke-PEs.

▫ The VPN instance on Spoke-PE2 imports the route based on the import RT.
Spoke-PE2 advertises the route to Spoke-CE2 through EBGP.

• The VPN instance (VPN_out) on the Hub-PE advertises the route to Spoke-PE2
and Spoke-PE1 at the same time with the export RT. The route is imported by the
Hub-PE through an IGP (OSPF 200). Because the IGP route does not carry the
AS_Path attribute, the AS_Path attribute is null. The AS_Path of the route
destined for 192.168.1.0/24 from Spoke-CE1 is not null. Therefore, the route
returned by the Hub-PE takes precedence over the route from Spoke-CE1. As a
result, route flapping occurs.
• In actual applications, if two sites that need to communicate are in the same AS,
each site should consider the route of the other site as an inter-area route rather
than an AS external route.
• The domain ID can be configured using the domain-id command in the view of
the OSPF process bound to the VRF instance.

▫ By default, the domain ID is 0 (NULL). If different OSPF domains use NULL

as the domain ID, these OSPF domains cannot be distinguished.
Consequently, the routes between different OSPF domains are considered
as intra-area routes.

▫ If an OSPF domain is configured with a non-zero domain ID, NULL is no

longer the domain ID of the OSPF domain.

• It is recommended that all OSPF instances related to the same VPN use the same
domain ID or the default domain ID.
• The loop generation process is as follows:

▫ CE1 at site 1 advertises a route destined for 192.168.1.0/24 to PE1 using a

Type 3 LSA.

▫ PE1 imports the route of the OSPF VPN1 process to BGP and advertises the
route to PE2 and PE3 through MP-IBGP.

▫ PE2 is configured to import routes from BGP to OSPF. Therefore, PE2

generates Type 3 LSAs and sends them to CE2. CE2 then advertises the Type
3 LSAs received from PE2 to PE3.

▫ PE3 receives two routes destined for 192.168.1.0/24. One is advertised by

PE1, and the other is imported by PE2. By default, IGP (OSPF) routes have a
higher priority than IBGP routes. Therefore, PE3 selects OSPF routes.

▫ PE3 advertises the optimal route learned from OSPF to PE1 through MP-
IBGP.

▫ In this case, PE1 has two routes to the destination network segment
192.168.1.0/24. One is learned from CE1 through OSPF, and the other is
learned from PE3 through MP-IBGP. The following problems may occur:
• By default, the DN bit in LSAs generated by OSPF is set to 1. You can run the dn-
bit-set disable command to disable OSPF from setting the DN bit in LSAs.
• The loop generation process is as follows:
▫ CE1 advertises a route destined for 192.168.1.0/24 to PE1 through EBGP.
The AS_Path of the route is 65001.
▫ PE1 advertises the route to PE2 and PE3 through MP-IBGP.
▫ PE2 imports BGP routes to the OSPF VPN1 process and advertises a Type 5
LSA destined for 192.168.1.0/24 to CE2.
▫ CE2 advertises the Type5 LSA to PE3.
▫ PE3 preferentially selects an OSPF route (the OSPF route has a higher
priority than the IBGP route) and advertises an Update message to PE1
through MP-IBGP.
▫ PE1 receives the MP-IBGP Update message from PE3. The MP-IBGP route
advertised by PE3 has a higher priority than the EBGP route advertised by
CE1 because the MP-IBGP route is an IGP (OSPF) route imported by BGP on
PE3 and its AS_Path is null. PE1 prefers the route advertised by PE3.
▫ In this case, a routing loop is formed: PE3 -> CE2 -> PE2 -> PE1 -> PE3.
• Because PE1 does not preferentially select the route learned from CE1, PE1
withdraws the route advertised to PE2. The imported BGP route is also
withdrawn in the OSPF VPN instance process on PE2. Then, both CE2 and PE3
withdraw the OSPF routes. The BGP route advertised by PE3 to PE1 is also
withdrawn. On PE1, the route learned from CE1 becomes the optimal route. As a
result, route flapping occurs.
• The generation and elimination of Type 7 LSA-related loops are similar to those
of Type 5 LSA-related loops, and are not described here.
• The VPN route tag is not transmitted in the BGP extended community attribute.
The VPN route tag is valid only on the PEs that receive BGP routes and generate
OSPF LSAs.

• By default, the VPN route tag is calculated based on the AS number of BGP. If
BGP is not configured, the default value is 0.

• You can run the route-tag command to set a VPN route tag.
• Multiple sham links of the same OSPF process can share the same endpoint
address, but different OSPF processes cannot have two sham links with the same
endpoint address.
• When configuring a sham link, you can specify the route cost of the sham link.
The default value is 1.
1. BCD

2. B
• To facilitate understanding, the devices connecting ASs in the original AS are
called ASBR-PEs, and P devices are numbered differently. In addition, CE3 and
CE4 will not be discussed.
• The numbers in this example are only for ease of understanding, and do not
represent the actual processing sequence on the devices.
• The LDP PHP behavior is not considered in data forwarding.
• In the inter-AS VPN scenario, it is recommended that independent RRs be
deployed to transmit routes only without forwarding traffic.
• If the P device of each AS knows the routes to the PEs of other ASs, the data
forwarding process will be relatively simple. But if the P device does not know
these routes, then when a PE receives VPN data from a CE, the PE will add three
labels. The bottom label is the VPN label that is allocated by the peer PE and
associated with VPN routes, the middle label is the label allocated by an ASBR
and associated with the route to the peer PE, and the outer label is the label
associated with the route to the next-hop ASBR.

• Note: For convenience, as shown in the figure above, a symmetric LSP is used for
illustration, but in fact, in the working process of the control plane and the data
plane, the LSP of the ASs at both ends is asymmetric.
1. C

2. C
• Common VPLS PW creation modes:

▫ Static configuration: A large number of manual configurations are required.

▫ LDP signaling (Martini)

▫ BGP signaling (Kompella)

• For details about the terms, see RFC7432.
• Currently, ESIs of Type 2, Type 3, Type 4 and Type 5 are not used on Huawei
devices.
• Up to now, 11 route types have been defined in the RFC and draft. Type 1 to
Type 5 are relatively mature. Type 5 is in the draft phase. Type 6 to Type 11 are
used for multicast traffic optimization and are not mature.
• The CE all-active access scenario uses Huawei NE series routers as an example.
An Eth-Trunk is configured on CE1 to connect to PE1 and PE2, and an inter-
device link aggregation enhanced trunk (E-Trunk) needs to be configured on PE1
and PE2. E-Trunk will not be marked in the following figures.
• The backbone network consisting of P devices involves only outer tunnel
forwarding, which will not be described in later sections.
• The DF election mode can be set to interface-based or VLAN-based DF election
on Huawei devices. By default, interface-based DF election is enabled, which may
cause traffic unbalance among multi-homing links. You can configure VLAN-
based DF election so that BUM traffic from a PE to a CE can be evenly distributed
to multi-homing links based on VLANs.
• The data packets sent by the CEs do not carry any label. Therefore, the incoming
label in the MAC-VRF table of PEs is NULL.
• PE1 forwards the ARP packet to all members based on the BUM traffic
forwarding table.
• Only the router that is elected as the DF forwards BUM traffic to CEs.
• ESI labels are used to prevent CE traffic from being looped back.
• PE3 searches the MAC-VRF table based on the destination MAC address (1-1-1)
of the packet and finds that there are two next hops: PE1 and PE2. PE3 uses a
load balancing algorithm to select an appropriate next hop (for example, PE1)
for packet forwarding.

• After receiving the ARP reply, PE1 searches the MAC-VRF table and sends the
packet through Port1.
• CE1 sends traffic to PE1 and PE2 over two active paths for load balancing.
Because PE1 and PE2 each have established two paths to CE2, traffic can be load
balanced between the two paths. Finally, four service data flows are sent to CE2
over different paths.
• After receiving the Type 1 route, PE4 becomes a DF.

• After receiving the Type 1 route, PE1 and PE2 update their MAC labels and
withdraw the MAC routes to ES2. Traffic is automatically switched to PE4.

• If a CE is connected to multiple PEs and a connectivity fault occurs between a

specific PE and the CE, the PE must send an Ethernet A-D per ES route to
withdraw all the MAC addresses previously advertised.
• When a peer PE receives a MAC/IP advertisement route, it needs to check
whether the advertised MAC address is reachable through other PEs. Therefore,
the PE checks the address reachability based on the Ethernet A-D per EVI route.

• Note: The peer PE may first receive the Ethernet A-D per EVI route and then the
Ethernet A-D per ES route. To prevent this problem, the peer PE forwards traffic
only when it receives the Ethernet A-D per EVI route and Ethernet A-D per ES
route at the same time.

• When a CE is multi-homed to PEs in single-active mode, the PE establishes a

backup path using the Ethernet A-D per EVI route and Ethernet A-D per ES route.
• MAC address migration will be described based on VXLAN in the following
sections.
• DF election rules:

▫ A PE discovers the ES and ESI of the local connection and advertises the
Type 4 route carrying the ES-Import.

▫ The PE starts the timer. The default value of the timer is 3 seconds, within
which ES routes can be received.

▫ After the timeout, the PE generates an ordered list. The list contains the IP
addresses of all PEs and information about their connections to the ES. The
sequence number of the list starts from 0 in ascending order. The sequence
number is used to determine the DF.

▫ The PE elected as the DF forwards BUM traffic to CEs. When a link fault
occurs, the PE withdraws its ES routes, which triggers a re-election process.
• For more details about Type 5 routes, see the RFC draft.
• In this service mode, the sub-interface, VLAN, BD, and EVI are exclusively used by
a user to access the network, and a separate MAC forwarding table is used on
the forwarding plane for each user. Although this mode effectively ensures
service isolation, it consumes a large amount of EVI resources because each user
requires one EVI.
• When EVPN peers send routes to each other, a BD tag is encapsulated into the
Ethernet Tag ID field of Ethernet A-D route packets, MAC/IP advertisement route
packets, and inclusive multicast route packets.
• This course describes inter-AS EVPN L3VPN.
• E-Line, E-Tree, and E-LAN are three types of Ethernet virtual connection (EVC),
which are point-to-point EVC, multipoint-to-multipoint EVC, and rooted-
multipoint EVC.

▫ E-Line: A point-to-point EVC associates two user-network interfaces (UNIs).

▫ E-LAN: A multipoint-to-multipoint EVC can associate two or more UNIs.

Users or carriers can add any number of UNIs to the EVC or delete some
UNIs from the EVC without affecting other UNIs.

▫ E-Tree: This EVC is similar to the hub-spoke model in L3VPN. It consists of

one or more root UNIs and several leaf UNIs. The root UNI can directly
communicate with all UNIs in the EVC, whereas a leaf UNI can only directly
communicate with the root UNI in the EVC. Two leaf UNIs cannot
communicate with each other directly.
• This example describes the configuration commands on Huawei NE20E-S2
(V800R012C10) series routers. For the configuration commands of other models,
see the corresponding product manuals.
• The features required in an EVPN dual-homing scenario, such as fast
convergence, split horizon, and DF election, all become invalid in a single-homing
scenario. In such a scenario, configuring an ESI is optional on a single-homing PE.
• For details about the E-Trunk configuration, see the corresponding product
documentation.
1. A

2. B
• IPv6 static routes and IPv4 static routes differ mainly in destination and next-hop
IP addresses. IPv6 static routes use IPv6 addresses, whereas IPv4 static routes use
IPv4 addresses.
• [Huawei] ipv6 route-static dest-ipv6-address prefix-length { interface-type
interface-number [ nexthop-ipv6-address ] | nexthop-ipv6-address | vpn-instance
vpn-destination-name nexthop-ipv6-address } [ preference
preference][ permanent | inherit-cost ] [ description text ]
▫ preference preference: specifies a preference value for the route. The value
is an integer ranging from 1 to 255. The default value is 60.

▫ permanent: enables the function of permanently advertising the IPv6 static

route.

▫ inherit-cost: enables the static route to inherit the cost of the recursive
route.

▫ description text: specifies a description for the static route. The value is a
string of 1 to 80 characters and can contain spaces.

• [Huawei] ipv6 route-static vpn-instance vpn-instance-name dest-ipv6-address

prefix-length { [ interface-type interface-number [ nexthop-ipv6-address ] ] |
nexthop-ipv6-address [ public ] | vpn-instance vpn-destination-name nexthop-
ipv6-address } [ preference preference ] [ permanent | inherit-cost ]
[ description text ]

▫ public: indicates that nexthop-ipv6-address is a public network address

instead of an address in the source VPN instance.
• Similarities also include support for special areas, support for virtual links, and
multi-process support.

• For details, see the "HCIP-Datacom-Core Technology" course.

• On broadcast, NBMA, P2P, and P2MP networks, OSPFv2 uses IPv4 interface
addresses to identify neighbors. On virtual-link networks, however, OSPFv2 uses
router IDs to identify neighbors.
• IPv6 emphasizes the link concept. Multiple IPv6 prefixes that indicate different IP
subnets can be allocated to the same link. Different from IPv4, IPv6 allows two
nodes on the same link to communicate even if they do not have the same IPv6
prefix. This greatly changes the OSPF behavior.

• In OSPFv3, the concepts "link" and "prefix" are frequently used, which however
are independent of each other. The terms "network" and "subnet" used in
OSPFv2 should be replaced with the term "link" when OSPFv3 is discussed.
• In multi-instance, each instance is differentiated by adding a specific instance ID
to the OSPFv3 packet header. If an instance is assigned a specific instance ID, the
OSPFv3 packets that do not match the instance ID are discarded.
• IPv6 implements neighbor discovery and automatic configuration using link-local
addresses. Routers running IPv6 do not forward IPv6 packets whose destination
addresses are link-local addresses. Such packets are valid only on the local link.

• OSPFv3 is a routing protocol running on IPv6 and uses link-local addresses to

send OSPFv3 packets.

▫ OSPFv3 assumes that each router has been assigned a link-local address on
each link. All OSPFv3 interfaces except virtual-link interfaces use the
associated link-local addresses as the source addresses to send OSPFv3
packets.

▫ A router learns the link-local addresses of all the other routers attached to
the same link and uses these addresses as the next-hop addresses to
forward packets.

▫ Note: Description of link-local addresses is only contained in link-LSAs (new

type of LSA supported in OSPFv3).

• Note: On a virtual link, the global unicast address or a site's local address must
be used as the source address of OSPFv3 packets.
• OSPFv3 packets have the following functions:

▫ Hello packet: Hello packets are sent periodically to discover, establish, and
maintain OSPFv3 neighbor relationships.

▫ DD packet: A DD packet describes the summary of a local LSDB and is used

for LSDB synchronization between two devices.

▫ LSR packet: An LSR packet is used to request the required LSAs from a
neighbor. An OSPFv3 device sends LSR packets to its neighbor only after DD
packets have been successfully exchanged between them.

▫ LSU packet: An LSU packet is sent to a neighbor to provide required LSAs.

▫ LSAck packet: An LSAck packet is used to acknowledge the received LSAs.

• Version: indicates the OSPF version, and occupies 1 byte. For OSPFv3, the value is
3.

• Type: indicates the type of an OSPFv3 packet and occupies 1 byte. The following
types are available:

▫ 1: Hello packet

▫ 2: DD packet

▫ 3: LSR packet

▫ 4: LSU packet

▫ 5: LSAck packet

• Packet length: indicates the total length of an OSPFv3 packet, including the
packet header. The field occupies 2 bytes.

• Router ID: indicates the router ID of the router that originates the packet, and
occupies 4 bytes.

• Area ID: indicates the area in which the packet is sent, and occupies 4 bytes.

• Checksum: indicates the standard 16-bit IPv6 checksum and occupies 2 bytes.

• 0: Occupying 1 byte, this field is reserved and must be set to 0.

• Rot Pri: indicates the router's router priority, which is used for DR election. This
field occupies 1 byte, and the default value is 1. If it is set to 0, the router cannot
participate in DR or BDR election.

• Options: indicates the optional capabilities supported by the router and occupies
3 bytes.

▫ AT: indicates whether OSPFv3 authentication is supported. This option

occupies 1 bit. If the AT bit is 1, an authentication tail field containing
authentication information is added to the OSPFv3 packet.

▫ DC: indicates whether the capability of processing demand circuits is

supported. This option occupies 1 bit.

▫ R: indicates whether the originator is a valid router. This option occupies 1

bit.

▫ NP: indicates whether the area to which the originating router interface
belongs is a not-so-stubby area (NSSA). This option occupies 1 bit.

▫ MC: indicates whether multicast data packets can be forwarded. This option
occupies 1 bit.

▫ E: indicates whether external routes are supported. This option occupies 1

bit.

▫ V6: indicates whether the router or link can participate in route calculation.
This option occupies 1 bit. If it is set to 0, the router or link does not
participate in IPv6 route calculation.
• LS Age: indicates the time elapsed since the LSA was generated, in seconds. This
field occupies 2 bytes. The value of this field continually increases regardless of
whether the LSA is transmitted over a link or saved in an LSDB.

• LS Type: indicates the LSA type. This field occupies 2 bytes. The high-order three
bits of this field identify generic properties of the LSA, whereas the remaining bits
identify the LSA's specific function.

▫ The U-bit indicates how to process an unknown LSA, that is, how a router
that does not recognize an LSA's function code should process this LSA.

▪ 0: The LSA is treated as if it had the link-local flooding scope.

▪ 1: The LSA is stored and flooded as if its type had been understood.

▫ The S2 and S1 bits indicate the flooding scope of the LSA.

▪ S2 S1 = 0 0: link-local flooding scope. The LSA is flooded only on the

originating link.

▪ S2 S1 = 0 1: area flooding scope. The LSA is flooded to all routers in

the originating area.

▪ S2 S1 = 1 0: AS flooding scope. The LSA is flooded to all routers in the

local AS.

▪ S2 S1 = 1 1: reserved.
• As shown in the figure, the U-bit in the LS Type field of the OSPFv3 LSA header is
0 by default. Except the Type 5 and Type 8 LSAs, the other types of LSAs all have
the area flooding scope (S2 S1 = 0 1).

▫ Link-local flooding scope: LSAs, including link-LSAs, are flooded only on the
local link.

▫ Area flooding scope: The following types of LSAs are flooded in a single
OSPF area: router-LSA, network-LSA, inter-area-prefix-LSA, inter-area-
router-LSA, NSSA-LSA, and intra-area-prefix-LSA.

▫ AS flooding scope: LSAs, including AS-external-LSAs, are flooded in an

entire routing domain (AS).
• The fields in an OSPFv3 router-LSA are described as follows:

▫ W: wildcard receiver. The value 1 indicates that the router supports

multicast routes.

▫ V: virtual link. The value 1 indicates that the router that generates the LSA
is at one end of the virtual link.

▫ E: external. The value 1 indicates that the router that generates the LSA is
an ASBR.

▫ B: border. The value 1 indicates that the router that generates the LSA is an
ABR.

▫ Options: indicates the optional capabilities supported by the router and

occupies 3 bytes.

▪ DC: indicates whether the capability of processing demand circuits is

supported. This option occupies 1 bit.

▪ R: indicates whether the originator is a valid router. This option

occupies 1 bit.

▪ NP: indicates whether the area to which the originating router

interface belongs is a not-so-stubby area (NSSA). This option occupies
1 bit.
• The fields in an OSPFv3 network-LSA are described as follows:

▫ Options: same as the Options field in a router-LSA.

• The fields in an OSPFv3 inter-area-prefix-LSA are described as follows:

▫ Metric: indicates the cost of the route to the destination address and
occupies 3 bytes.

▫ PrefixOptions: Each prefix advertised by an LSA has its own PrefixOptions

field.

▪ P-bit: propagate bit. This bit needs to be set to 1 if the prefix of an

NSSA needs to be advertised by an ABR.

▪ MC-bit: multicast bit. If this bit is set to 1, the prefix is used for
multicast route calculation. Otherwise, the prefix is not used for
multicast route calculation.

▪ LA-bit: local address capability bit. If this bit is set to 1, the prefix is an
interface address of the router.

▪ NU-bit: no unicast capability bit. If this bit is set to 1, the prefix is not
used for IPv6 unicast route calculation.

• Note: The prefix length of the default route is 0. An ABR can also originate an
inter-area Type 3 LSA to advertise a default route to a stub area.
• The fields in an OSPFv3 inter-area-router-LSA are described as follows:

▫ Options: This field describes the optional capabilities supported by the

destination router instead of those supported by the source router.
Therefore, the value of this field should equal that of the Options field in
the router-LSA generated by the destination router.

▫ Metric: indicates the cost of the route to the destination address and
occupies 3 bytes.
• The fields in an OSPFv3 AS-external-LSA are described as follows:
▫ Bit E: indicates the cost type of an AS external route and occupies 1 bit.
▪ The value 1 indicates the cost of a Type 2 external route. This cost
does not increase during route transmission.
▪ The value 0 indicates the cost of a Type 1 external route. This cost
increases during route transmission.
▫ Bit F: occupies 1 bit. The value 1 indicates that the Forwarding Address field
(optional) is included.
▫ Bit T: occupies 1 bit. The value 1 indicates that the External Route Tag field
(optional) is included.
▫ Metric: indicates the cost of the route to the destination address and
occupies 3 bytes.
▫ PrefixLength, PrefixOptions, and Address Prefix are triplets that describe a
prefix and have the same meanings as those in an inter-area-prefix-LSA.
▫ Forwarding Address: is an optional 128-bit IPv6 address and occupies 4
bytes. This field is included if bit F is 1. In this case, a data packet needs to
be forwarded to this address before reaching its destination.
▫ External Route Tag: an optional flag, which occupies 4 bytes. It can be used
for communication between ASBRs. In a typical scenario where each of two
ASBRs imports an AS external route, the imported routes can be tagged
differently to facilitate route filtering.
▫ Referenced Link State ID: occupies 4 bytes. This field is included if the
Referenced LS Type field is not 0, indicating the link state ID of the
referenced LSA.
• The fields in an OSPFv3 link-LSA are described as follows:

▫ Rtr Pri: indicates the router priority of the interface attaching the
originating router to the link and occupies 1 byte.

▫ Options: indicates a collection of Options bits that the router sets in the
network-LSA and occupies 3 bytes.

▫ Number of Prefixes: indicates the number of IPv6 address prefixes carried in

the LSA, and occupies 4 bytes.

▫ PrefixLength, PrefixOptions, and Address Prefix are triplets that describe a

prefix and have the same meanings as those in an inter-area-prefix-LSA.
• The fields in an OSPFv3 intra-area-prefix-LSA are described as follows:
▫ Number of Prefixes: indicates the number of IPv6 address prefixes carried in
the LSA, and occupies 4 bytes. If necessary, prefixes can be carried in
multiple intra-area-prefix-LSAs to limit the size of each Type 9 LSA.
▫ Referenced LS Type: indicates whether the LSA references a router-LSA or a
network-LSA, and occupies 4 bytes.
▪ Type=1: A router-LSA is referenced.
▪ Type=2: A network-LSA is referenced.
▫ Referenced Link State ID: 4 bytes.
▪ If the LSA references a router-LSA, this field is set to 0.
▪ If the LSA references a network-LSA, this field is set to the interface ID
of the DR on the attached link.
▫ Referenced Advertising Router: 4 bytes.
▪ If the LSA references a router-LSA, this field is set to the router ID of
the associated router.
▪ If the LSA references a network-LSA, this field is set to the router ID
of the DR on the attached link.
▫ PrefixLength, PrefixOptions, and Address Prefix are triplets that describe a
prefix and have the same meanings as those in an inter-area-prefix-LSA.
▫ Metric: indicates the prefix cost and occupies 2 bytes. This field has the
same unit as the interface cost of a router-LSA.
• In OSPFv3, when a link or its prefix changes, the attached router sends an intra-
area-prefix-LSA, which however does not trigger SPF calculation.
• As shown in the figure, R1, R2, R3, and R4 run OSPFv3 and are all deployed in the
backbone area.

• After the network becomes stable, check the LSDB of R2. The command output
shows information about the following types of LSAs: router-LSA (Type 1),
network-LSA (Type 2), Link-LSA (Type 8), and intra-area-prefix-LSA (Type 9).
• The command output is described as follows:

▫ LS Age: aging time of the LSA.

▫ LS Type: LSA type, which can be any of the following:

▪ Router-LSA, Network-LSA, Inter-Area-Prefix-LSA, Inter-Area-Router-

LSA, AS-external-LSA, NSSA-LSA, Link-LSA, or Intra-Area-Prefix-LSA

▫ Link State ID: link state ID in the LSA header.

▫ Originating Router: router that generates the LSA.

▫ LS Seq Number: sequence number of the LSA. This field is carried in the LSA
header.

▫ Checksum: checksum of the LSA.

▫ Length: length of the LSA.

▫ Priority: priority of the interface attached to the link.

▫ Options: optional capabilities of the link.

▫ Link-Local Address: link-local address.

▫ Number of Prefixes: number of IPv6 prefixes contained in the LSA.

▫ Prefix: IPv6 prefix.

▫ Prefix Options: optional capabilities associated with the prefix.

• The configuration commands and methods of OSPFv3 are similar to those of
OSPFv2. For details, see the "HCIP-Datacom-Core Technology" course.
• [Huawei] display ospfv3 [ process-id ] lsdb [ area area-id ] [ originate-router
advertising-router-id | self-originate ] [ { router | network | inter-router [ asbr-
router asbr-router-id ] | { inter-prefix | nssa } [ ipv6-address prefix-length ] |
link | intra-prefix | grace } [ link-state-id ]]

▫ process-id: specifies the ID of an OSPFv3 process. The value is an integer

ranging from 1 to 65535.

▫ area area-id: specifies the ID of an area. The area ID can be a decimal

integer or in the IPv4 address format. For a decimal integer, the value
ranges from 0 to 4294967295. For the IPv4 address format, the value is in
dotted decimal notation.

▫ external: displays information about AS-external LSAs in the LSDB.

▫ inter-prefix: displays information about inter-area-prefix LSAs in the LSDB.

▫ inter-router: displays information about inter-area-router LSAs in the

LSDB.

▫ intra-prefix: displays information about intra-area-prefix LSAs in the LSDB.

▫ nssa: displays information about NSSA LSAs in the LSDB.

▫ link: displays information about link-LSAs in the LSDB.

▫ network: displays information about network-LSAs in the LSDB.

▫ router: displays information about router-LSAs in the LSDB.

▫ link-state-id: specifies a link state ID. The value is in dotted decimal

notation.
• You can run the display ospf peer command to check OSPFv2 neighbor
information.

• By comparing OSPFv2 neighbor information and OSPFv3 neighbor information,

you will find that the elected DR and BDR are the same, indicating that the DR
election modes between OSPFv2 and OSPFv3 are the same.
• You can run the display ospf routing command to check the routing information
on the OSPFv2 network.

• By comparing OSPFv2 routing information and OSPFv3 routing information, you

will find that the paths to the same network segment are the same, indicating
that the route calculation methods between OSPFv2 and OSPFv3 are the same.
• You can run the display ospf lsdb command to check the OSPFv2 LSDB. You will
find that the LSDB contains the Type 1, Type 2, and Type 3 LSAs.
• Fields in TLV 232 (IPv6 Interface Address) are described as follows:
▫ Type: indicates the TLV type and occupies 8 bits. The value is 232 (0xE8).
▫ Length: indicates the length of the Value field in the TLV and occupies 8
bits.
▫ Interface Address: indicates a 128-bit IPv6 address.
• Fields in TLV 236 (IPv6 Reachability) are described as follows:
▫ Type: indicates the TLV type and occupies 8 bits. The value is 236 (0xEC).
▫ Length: indicates the length of the Value field in the TLV and occupies 8
bits.
▫ Metric: a 32-bit field indicating the cost.
▫ U: up/down bit. This 1-bit field indicates whether the prefix is advertised
from a higher level to a lower level.
▫ X: external original bit. This 1-bit field indicates whether the prefix was
imported into IS-IS from another routing protocol.
▫ S: sub-TLV present bit. This 1-bit field is optional.
▫ R: This 5-bit field is reserved.
▫ Prefix Length: indicate the prefix length and occupies 8 bits.
▫ Prefix: indicates an IPv6 address prefix.
▫ Sub-TLV Length: indicates the length of a sub-TLV and occupies 8 bits. If
the S-bit is set to 1, this field is included.
▫ Sub-TLV: If the S-bit is set to 1, this field is included.
• IS-IS single-topology has the following disadvantages:

▫ Network deployment is not suitable for topology separation.

▫ To maintain the same topology, each interface must run both IS-IS (IPv4)
and IS-IS (IPv6), which is not flexible.

▫ IPv4 areas cannot be used to connect different IPv6 areas. That is, IPv4
networks cannot be used to address IPv6 network isolation.
• The IS-IS MT feature can overcome the disadvantages of IS-IS single topology.
• To support MT, IS-IS defines multiple types of TLVs, including Multi-Topology
TLV, MT Intermediate Systems TLV, Multi-Topology Reachable IPv4 Prefixes TLV,
and Multi-Topology Reachable IPv6 Prefixes TLV. This course focuses on the
Multi-Topology TLV and does not elaborate on the other ones.

• Multi-Topology TLV:

▫ This TLV is contained only in IIH PDUs and fragment zero LSPs.

▫ Reserved MT IDs:

▪ MT ID=0, equivalent to the standard IPv4 topology.

▪ MT ID=2, reserved for the IPv6 routing topology.

• The basic configuration commands and methods of IS-IS (IPv6) are the same as
those of IS-IS (IPv4). For details, see the "HCIP-Datacom-Core Technology"
course.

• [Huawei-isis-1] ipv6 enable [ topology { ipv6 | standard } ]

▫ topology: sets a network topology type.

▫ ipv6: sets the topology type to IPv6. That is, the IPv6 capability for the IS-IS
process is enabled in an IPv6 topology. Links on the network can be
configured as IPv4 or IPv6 links. SPF calculation is performed separately in
IPv4 and IPv6 topologies.

▫ standard: sets the topology type to standard. That is, the IPv6 capability for
the IS-IS process is enabled in an integrated topology. A network
administrator must ensure that all links on the network support the same
topology type. By default, the standard type is used when the IPv6
capability is enabled for an IS-IS process.
• To support IPv6, BGP needs to map IPv6 routing information to the NLRI
attributes.
• Update message:

▫ An Update message can be used to advertise multiple routes with the same
path attribute. These routes are stored in the NLRI attribute. An Update
message can also carry multiple unreachable routes, which are stored in the
Withdrawn Routes field, to instruct peers to withdraw these routes.
• Fields in the MP_REACH_NLRI attribute are described as follows:

▫ Address Family Information: consists of a 2-byte address family identifier

(AFI) and a 1-byte subsequent address family identifier (SAFI).

▫ Length of Next Hop Network Address: indicates the length of the next-hop
address and occupies 1 byte. Generally, the value is 16.

▫ Network Address of Next Hop: The length is variable and depends on the
preceding field. Generally, the value is a global unicast address.

▫ Reserved: 1 byte. The value must be 0.

▫ Network Layer Reachability Information: contains information about the

routes with the same attributes. The value 0 indicates the default route.

• Fields in the MP_UNREACH_NLRI field are described as follows:

▫ Withdrawn Routes: indicates the routes to be withdrawn. The value is in the

<mask length, route prefix> format. If the mask length is 0, the associated
route is a default route.
• The basic configuration commands and methods of BGP4+ are the same as those
of BGP. For details, see the "HCIP-Datacom-Core Technology" course.

• [Huawei-bgp] ipv6-family [ unicast | vpnv6 | vpn-instance vpn-instance-name ]

▫ unicast: enters the IPv6 unicast address family view.

▫ vpnv6: enters the BGP-VPNv6 address family view.

▫ vpn-instance vpn-instance-name: associates a specified VPN instance with

the IPv6 address family and enters the BGP-VPN instance IPv6 address
family view. The value is a string of 1 to 31 case-sensitive characters. If
spaces are used, the string must start and end with double quotation marks
(").

• [Huawei-bgp-af-ipv6] network ipv6-address prefix-length [ route-policy route-

policy-name ]
▫ ipv6-address: specifies the IPv6 address advertised by BGP. The value is a
32-digit hexadecimal number, in the format of X:X:X:X:X:X:X:X.

▫ prefix-length: specifies the prefix length of the IPv6 address advertised by

BGP. The value is an integer ranging from 0 to 128.

▫ route-policy route-policy-name: specifies the name of the route-policy

applied to route advertisement. The value is a string of 1 to 40 case-
sensitive characters. If spaces are used, the string must start and end with
double quotation marks (").
1. ABD

2. A
• Disadvantages of IPv4:
▫ The IPv4 address space is insufficient. IPv4 addresses are 32 bits long.
Theoretically, 4.3 billion IPv4 addresses can be provided. However, the
number of IPv4 addresses that are actually available cannot reach this
number due to various address assignment reasons. Additionally, IPv4
address resources are unevenly assigned. IPv4 addresses in U.S. account for
almost half of all addresses, leaving insufficient addresses for Europe and
even fewer for the Asia-Pacific region. The shortage of IPv4 addresses limits
further development of mobile IP and broadband technologies that require
an increasing number of IP addresses.
▫ A large number of routing entries on devices need to be maintained. At
the initial stage of IPv4 development, many discontinuous IPv4 addresses
are assigned. As a result, routes cannot be effectively summarized. The
increasingly large routing table consumes a lot of memory resources and
affects forwarding efficiency. Device vendors must continually upgrade
devices to improve route addressing and forwarding performance.
▫ Address autoconfiguration and readdressing cannot be easily
performed. IPv4 addresses are only 32 bits long, and they are unevenly
assigned. As a result, IP addresses need to be reassigned during network
expansion or reconstruction, increasing the maintenance workload.
• Advantages of IPv6:
▫ Easy to deploy.
▫ Compatible with various applications.
▫ Smooth transition from IPv4 networks to IPv6 networks.
• The IPv6 header is also called fixed header, which contains eight fields in 40
octets. The fields are Version, Traffic Class, Flow Label, Payload Length, Next
Header, Hop Limit, Source Address, and Destination Address.

▫ Version: This field indicates the version of IP and its value is 6. The length is
4 bits.

▫ Traffic Class: This field indicates the class or priority of an IPv6 packet and
its function is similar to that of the ToS field in an IPv4 header. The length
is 8 bits.

▫ Flow Label: An IPv4 header does not contain this field. It is a new field. It is
used by a source to label sequences of packets for which the label requests
special handling by IPv6 routers. The length is 20 bits. Generally, the flow
label, together with the source and destination IPv6 addresses, can
determine a flow.

▫ Payload Length: This field indicates the length of the IPv6 payload. The
payload refers to the extension header and upper-layer protocol data unit
that follow the IPv6 header. This field is 16 bits long and can specify a
maximum length of 65535 octets for the payload. If the payload size
exceeds 65535 octets, the field is set to 0, and the Jumbo Payload option in
the Hop-by-Hop Options header is used to express the actual payload
length.
• Global unicast address (GUA): It is also known as an aggregatable GUA. This type
of address is globally unique and is used by hosts that need to access the
Internet. It is equivalent to a public IPv4 address.

• Unique local address (ULA): It is a private IPv6 address that can be used only on
an intranet. This type of address cannot be routed on an IPv6 public network and
therefore cannot be used to directly access a public network.

• Link-local address (LLA): It is another type of IPv6 address with a limited

application scope.
• General rules for IPv6 address planning:

▫ Hierarchical design: The large address space of IPv6 imposes higher

requirements on route summarization. Specifically, network address
fragments need to be reduced and route summarization needs to be
enhanced to improve routing efficiency. The hierarchical design helps
reduce the size of routing tables, ease IP address expansion and
configuration, and facilitate fault locating, management, and capacity
planning. In the hierarchical design, an IPv6 address is divided into several
independent fields. Each field can be planned individually to implement
route summarization. For example, a user-defined prefix can be divided into
multiple fields, with each field representing a different meaning.

▫ Semantics: Different fields are defined and assigned with meanings such as
service type and physical location, facilitating O&M and fault locating.

▫ Security: Services with shared attributes have the same security

requirements. Mutual access between services needs to be controlled.
Services with shared attributes are assigned addresses in the same address
space, facilitating security design and policy management.

▫ Continuity: It is recommended that IPv6 addresses in or between address

segments be contiguous. This avoids wasting addresses and facilitates
address management and summarization. This also eases route
summarization, reduces the size of routing tables, and improves routing
efficiency.

▫ Extensibility: Some IP addresses should be reserved for future network

expansion.
• IPv4 address exhaustion fuels the urgency to transition to IPv6, but this requires
existing IPv4 devices to be replaced as these devices are incompatible with IPv6
networks. The main issue is that replacing a large number of IPv4 devices will
incur huge costs and interrupt services on the live networks. Therefore, the
transition from IPv4 to IPv6 must be a gradual process. During the early stage of
IPv4-to-IPv6 transition, IPv6 networks are scattered across a large number of IPv4
networks. Therefore, IPv6 transition technologies are required to implement IPv6
service interworking.

• Note: The VXLAN and SRv6 technologies will be described in detail in subsequent
courses.
• Manual IPv6 over IPv4 tunnel:

▫ Devices at both ends of a tunnel must support the IPv4/IPv6 dual stack.
Other devices only need to support a single protocol stack.

▫ The source and destination addresses of a manual tunnel are manually

configured on devices. If a border device needs to establish tunnels with
several devices, manually configuring multiple tunnels on the device is
complex. Therefore, manual tunnels apply when two border routers connect
only two IPv6 networks.

▫ Tunnel forwarding mechanism: When receiving a packet from an IPv6

network, a border device searches its routing table for an entry matching
the destination address of the IPv6 packet. If the outbound interface is a
virtual tunnel interface, the border device encapsulates the IPv6 packet into
an IPv4 packet based on the source and destination IPv4 addresses
configured on the interface. The resulting IPv4 packet is then forwarded to
the remote end of the tunnel over an IPv4 network. When receiving this
IPv4 packet, the remote end decapsulates the packet to obtain the original
IPv6 packet and processes it using the IPv6 protocol stack.

• IPv6 over IPv4 GRE tunnel:

▫ Tunnel forwarding mechanism: Same as that of the manual IPv6 over IPv4
tunnel.
• The data forwarding process of an automatic IPv4-compatible IPv6 tunnel is as
follows:

▫ When receiving an IPv6 packet, R1 searches for an IPv6 route destined for
::A01:102 and finds that the next hop of the route is a virtual tunnel
interface.

▫ R1 encapsulates the IPv6 packet into an IPv4 packet. The source address of
the IPv4 packet is the source IPv4 address 10.1.1.1 of the tunnel, and the
destination IPv4 address is the last 32 bits (10.1.1.2) of the IPv4-compatible
IPv6 address ::A01:102.

▫ R1 sends the resulting IPv4 packet out from its tunnel interface. Then, the
packet is routed to the destination node R2 at 10.1.1.2 over the IPv4
network. When receiving this packet, R2 decapsulates the packet to obtain
the original IPv6 packet, and processes the IPv6 packet using the IPv6
protocol stack.

▫ The response packet returned by R2 is processed in a similar way as the

IPv6 packet sent by R1.

• 6to4 tunnel:

▫ The network prefix of a 6to4 address is 64 bits long.

▪ The first 48 bits (2002: a.b.c.d) are determined by the IPv4 address
assigned to a router and cannot be changed.

▪ The last 16 digits (SLA) are defined by users.

• Advantages of 6PE:

▫ Easy maintenance: All configurations are performed on PEs. IPv6 services

are carried over the existing IPv4 networks, simplifying network
maintenance. Additionally, users on IPv6 networks are unaware of the IPv4
networks.

▫ Low network construction costs: Carriers can provide IPv6 services to

users over existing MPLS networks without upgrading the networks. 6PE
devices can also provide various types of services, such as IPv6 VPN and
IPv4 VPN.
• The route transmission process in an intra-AS 6PE scenario is as follows:

1. CE2 sends an intra-AS IPv6 route to its EBGP peer 6PE2.

2. Upon receipt, 6PE2 changes the next hop of the IPv6 route to itself, and
assigns an inner label to the IPv6 route. Then, 6PE2 sends the labeled IPv6
route to its IBGP peer 6PE1.

3. When receiving the labeled IPv6 route, 6PE1 recurses the route to a tunnel,
and adds the route to the local forwarding table. Then, 6PE1 changes the
next hop of the IPv6 route to itself, removes the label from the route, and
sends the route to its EBGP peer CE1.

• The packet transmission process in an intra-AS 6PE scenario is as follows:

1. CE1 sends an ordinary IPv6 packet to 6PE1 over an IPv6 link on the public
network.

2. Upon receipt of the IPv6 packet, 6PE1 looks up the destination address of
the packet in its forwarding table, and encapsulates the packet with inner
and outer labels. Then, 6PE1 sends the resulting IPv6 packet to 6PE2 over a
public network tunnel.

3. When receiving the IPv6 packet, 6PE2 removes the inner and outer labels
and forwards the resulting IPv6 packet to CE2 based on the destination
address over an IPv6 link.
• When 6PE routes are configured to share the same explicit null label on 6PE2,
6PE2 advertises 6PE routes with an explicit null label to 6PE1 without applying
for labels for the routes.

• When forwarding data to 6PE2, 6PE1 adds two labels to the data. The outer label
is distributed by LDP pointing to 6PE2, and the inner label is an explicit null label
distributed by MP-BGP.

• When the IPv6 data packet arrives at 6PE2, 6PE2 pops out the explicit null label
and forwards the packet to CE2.
• In 6VPE, IPv6 routing protocols run between PEs and CEs. The following IPv6
routing protocols can be used to provide IPv6 VPN services:

▫ BGP4+

▫ Static IPv6 routing

▫ OSPFv3

▫ IS-IS for IPv6

• Note: This course uses a Huawei NetEngine 8000 series router as an example to
describe how to configure 6VPE.

• Command: <HUAWEI>system-view [ immediately ]

▫ immediately: indicates that the configuration takes effect immediately.

• Note: For details about route exchange between PEs and CEs, see the
corresponding product documentation.
• Packet processing on an IPv4 over IPv6 tunnel:

1. IPv4 packet forwarding: Host 1 sends an IPv4 packet destined for Host 2 to
R1.

2. Tunnel encapsulation: When receiving the IPv4 packet from Host 1, R1

discovers that the destination address of the IPv4 packet is not its own and
the next hop is a tunnel interface, so R1 attaches an IPv6 header to the
IPv4 packet. Specifically, in the IPv6 header, R1 encapsulates both its own
and R2's IPv6 addresses into the Source Address and Destination Address
fields, respectively, sets the Version field to 6 and the Next Header field to
4, and encapsulates the fields that ensure effective transmission of the
packet along the tunnel based on the configuration.

3. Tunnel forwarding: R1 searches its IPv6 routing table for an entry

matching the destination address in the IPv6 header, and forwards the
IPv6 packet to R2. Other nodes on the IPv6 network are unaware of the
tunnel and process the IPv6 packet as an ordinary IPv6 packet.

4. Tunnel decapsulation: Upon receipt of the IPv6 packet, R2 discovers that

the destination address is its own IPv6 address and the encapsulated
packet is an IPv4 packet based on the Next Header field, and then
decapsulates the IPv6 packet by removing the IPv6 header based on the
Version field.

5. IPv4 packet forwarding: R2 searches its IPv4 routing table for an entry
matching the destination address of the IPv4 packet and forwards the
packet to Host 2.
• Scenario where IPv6 users access IPv4 servers:

▫ At the early stage of IPv4-to-IPv6 evolution, carriers provide users with

single-stack IPv6 access. However, lots of Internet servers still use IPv4 and
do not support dual stack. This requires carriers to provide NAT64 devices
for single-stack IPv6 users to access IPv4 servers.

▫ The carriers only need to assign IPv6 addresses to users, with

communication between IPv6 devices implemented based on IPv6 routes.
Access from IPv6 users to IPv4 services is implemented through NAT64
devices that support dual stack.

▫ There are two NAT64 modes: static and dynamic. Static NAT64 is
recommended when a small number of IPv6 users use fixed IP addresses,
while dynamic NAT64 is recommended when a large number of IPv6 users
use unfixed IP addresses.

• Scenario where IPv4 users access IPv6 servers:

▫ At the late stage of IPv4-to-IPv6 evolution, many service providers have

begun to provide IPv6 services. However, there are still many single-stack
IPv4 users on the Internet. To retain these users, the service providers
deploy NAT64 devices, which allow these users to access IPv6 servers.

▫ In this scenario, service providers only need to assign IPv6 addresses to

servers, without the need to upgrade access devices. NAT64 devices, which
must support dual stack, are deployed at the egresses, and communication
between IPv6 devices is implemented based on IPv6 routes. IPv4-to-IPv6
access is implemented using the static NAT64 technology.
• NAT64 types:

▫ PAT-based NAT64: translates both addresses and port numbers by mapping

[IPv6 address, port number] into [IPv4 address, port number]. Multiple
IPv6 addresses can be translated into the same IPv4 address. The mappings
are differentiated by port number. This mode is commonly used.

▫ No-PAT–based NAT64: translates only addresses by mapping [IPv6

address] into [IPv4 address]. There are one-to-one mapping relationships
between IPv6 and IPv4 addresses.
• Dynamic NAT64 mapping process:
1. A single-stack IPv6 user sends an AAAA DNS request for a remote service
(example.huawei.com).
2. After receiving the request, the DNS64 server parses the AAAA request. If
no IPv6 address is found, it sends an A request, and parses the received
reply packet to obtain the service IPv4 address (1.1.1.1). The DNS64 server
then combines the IPv4 address and the preconfigured NAT64 prefix 64::/n
(64:FF9B::/96) into the IPv6 address 64:FF9B::101:101, and sends this IPv6
address to the user.
3. When receiving the DNS64 reply from the DNS64 server, the user sends a
packet with the IPv6 address as the destination address to the remote
server.
4. After receiving the IPv6 packet from the user, the NAT64 device extracts
the IPv4 address (1.1.1.1) from the IPv6 packet using the address
translation algorithm, changes the destination address of the packet to
this IPv4 address, changes the source address of the packet to an IPv4
address (2.1.1.10) from the NAT address pool based on the address
mapping configured in the NAT64 policy, and converts the IPv6 packet into
an IPv4 packet. The NAT64 device then sends the IPv4 packet to the
remote server on the IPv4 network, and generates a session table with the
address mapping.
5. Upon receipt of the IPv4 packet, the IPv4 server returns a reply packet.
6. After receiving the reply packet from the IPv4 server, the NAT64 device
converts the IPv4 packet into an IPv6 packet according to the session table,
and sends the IPv6 packet to the IPv6 user.
• DNS AAAA and A records:
▫ AAAA record: maps a host name or domain name to an IPv6 address.
▫ A record: maps a domain name to an IPv4 address.
• Static NAT64 mapping process:

1. An IPv4 user sends request A (example.huawei.com) to the DNS server.

2. After receiving the request, the DNS server parses the request to obtain the
IPv4 address (2.1.1.10) corresponding to the domain name, and sends a
reply containing the IPv4 address to the user. In this scenario, the mapping
between the domain name and IPv4 address has been predefined on the
DNS server. If the DNS A request does not contain any IPv4 address, the
packet is discarded.

3. After receiving the DNS reply, the user sends a packet with the obtained
IPv4 address as the destination address to the remote server.

4. Upon receipt of the IPv4 packet, the NAT64 device translates the
destination IPv4 address into an IPv6 address (2001:DB8::2) according to
the preconfigured static address mapping (based on which a server
mapping table is generated), combines the source IPv4 address and the
preconfigured NAT64 prefix into a source IPv6 address (64:FF9B::101:101),
and converts the IPv4 packet into an IPv6 packet. The NAT64 device then
sends the IPv6 packet to the remote server on the IPv6 network, and
generates a session table.

5. Upon receipt of the IPv6 packet, the server returns a reply packet.

6. After receiving the reply packet from the IPv6 server, the NAT64 device
converts the IPv6 packet into an IPv4 packet according to the session table,
and sends the IPv4 packet to the IPv4 user.
• NAT64 prefix configuration:

▫ A NAT64 prefix must be different from the IPv6 address prefix of any
interface on the device. Otherwise, the device considers the packets whose
destination IPv6 addresses are on the same network segment as the
interfaces to be NAT64 packets, and starts NAT64 processing for these
packets.

▫ When multiple NAT64 prefixes are configured and dynamic NAT64 is used,
all of these NAT64 prefixes can be used for NAT64 translation of IPv6-to-
IPv4 traffic. On the other hand, if static NAT64 is used, the device randomly
selects one of these prefixes.

• Note: This course uses a Huawei USG6000 series firewall as an example to

describe how to configure NAT64.
• Command: mode { pat | full-cone { global | local } [ no-reverse ] }

▫ pat: specifies the PAT mode.

▫ full-cone: specifies the 3-tuple NAT mode.

▫ global: specifies the global 3-tuple NAT mode. The generated server
mapping table does not contain security zone parameters and is not subject
to restrictions of interzone relationships.

▫ local: specifies the local 3-tuple NAT mode. The generated server mapping
table contains security zone parameters and is subject to restrictions of
interzone relationships.

▫ no-reverse: specifies that no reverse server mapping table will be

generated.
• The destination address of IPv6 packets sent by the IPv6 PC is the NAT64 address
2001:DB8:1::101:102/96.

• Other configurations:

▫ Configure the DNS64 server.

▪ Set the IPv6 prefix of the DNS64 server to 2001:DB8:1::/96, which is

the NAT64 prefix of Firewall 1.

▪ Configure reachable routes from the DNS64 server to the PC and

server.

▫ Configure the IPv6 address, route, and DNS server for the PC. (The method
of configuring an IPv6 address and a route for the PC varies according to
the PC operating system. The detailed configuration procedure is not
provided here.)

▪ Set the PC IPv6 address to 2001:DB8::1/64, which is on the same

network segment as GE1/0/1 of Firewall 1.

▪ Configure a static route from the PC to the destination network

segment 2001:db8:1::/96, with the next hop address set to 2001:db8::2.

▪ Configure the DNS64 server IPv6 address on the PC.

▫ Configure an IPv4 address for the server. (The configuration method varies
according to the server operating system. The detailed configuration
procedure is not provided here.)

▪ Set the IPv4 address of the server to 1.1.1.2/24, which is on the same
network segment as GE1/0/2 of Firewall 1.
• IVI supports communication requests initiated by both IPv6 and IPv4 hosts.

• The following uses access from an IVI6 host to a global IPv4 host as an example:

1. In this scenario, stateless IPv6 address autoconfiguration cannot be used

due to the special IVI6 address format. Therefore, the IVI6 host obtains the
IVI6 address, default gateway address, and DNS server address through
static configuration or DHCPv6 Options.

2. The IVI6 host sends an AAAA query request to the dual-stack IVI DNS
server. This DNS server stores the IVI4 addresses of IVI servers and their
corresponding IVI6 addresses. When receiving the AAAA query request, the
IVI DNS server sends an AAAA query request to the target network. If no
AAAA record exists, the IVI DNS server sends an A query request, converts
the obtained A record into an AAAA record according to the IVI mapping
rule, and returns the AAAA record to the IVI6 host.

3. The IVI6 host sends a data packet. When receiving this data packet, the IVI
gateway statelessly converts the packet into an IPv4 packet. During
address translation, the IPv4 address embedded in the IVI6 address is
extracted and used as the source address in the IPv4 header. During
header encapsulation, the Stateless IP/ICMP Translation (SIIT) algorithm is
used.

4. The resulting IPv4 data packet is routed to the IPv4 network, thereby
implementing access from the IVI6 host to the IPv4 host.

• IVI restrictions: The IPv6 addresses of hosts and servers must be planned and
configured in compliance with the IVI format.
1. ABD
QoS Fundamentals
 Foreword
⚫ With continuous development of networks, the network scale and traffic types increase continuously.
As a result, Internet traffic increases sharply, network congestion occurs, the forwarding delay
increases, and even packet loss occurs. In this case, the service quality deteriorates or even services are
unavailable. To deploy real-time and non-real-time services on the IP network, network congestion
must be resolved. The commonly used solution is to increase the network bandwidth. However, this
solution is not ideal considering the network construction cost.
⚫ Quality of service (QoS) is introduced in this situation. At limited bandwidth, QoS uses a "guaranteed"
policy to manage network traffic and provides different priority services for different traffic.
⚫ This course describes QoS fundamentals.

1 Huawei Confidential
 Objectives

⚫ On completion of this course, you will be able to:

 Describe the QoS background.
 Describe QoS types.
 Describe the implementation of the QoS DiffServ model.
 Describe application scenarios of different QoS functions.
 Describes basic configuration of QoS.
 Describe HQoS fundamentals.
 Describe basic configuration of HQoS.

2 Huawei Confidential
 Contents

1. Introduction to QoS

2. Traffic Classification and Marking

3. Traffic Limiting Technology

4. Congestion Avoidance Technology

5. Congestion Management Technology

6. Introduction to HQoS

3 Huawei Confidential
 "Best-Effort" Traditional Network
⚫ When the IP network emerges, there is no QoS guarantee.
⚫ You only know that the packets have been sent out. Whether the packets can be received
and when the packets can be received are unknown.

Undifferentiated
treatment
First In First Out (FIFO)

4 Huawei Confidential

• On the traditional IP network, each network device handles all packets in an

undifferentiated manner and follows the First In First Out (FIFO) rule to transmit
packets. The devices transmit packets to the destination in best-effort (BE) mode,
but the BE mode cannot ensure the performance such as delay and reliability.
 QoS Background
⚫ With continuous technology improvement and fierce product competition, users have
increasingly higher requirements on the network quality.

High-definition image quality Poor image quality, low network

and high network speed speed, and frame freezing
Good signal quality Poor signal quality

5 Huawei Confidential

• With the emergence of new applications on IP networks, new requirements are

raised to QoS of IP networks.
 Overview of QoS

Live QoS:
streaming
QoS is designed to provide different service
quality according to networking requirements.
Video
communication

Factors affecting QoS:

Email

Bandwidth Latency Jitter Packet Availability

FTP loss rate

6 Huawei Confidential

• To support voice, video, and data services of different requirements, the network
is required to distinguish different communication types before providing
corresponding QoS.
▫ For example, real-time services such as Voice over IP (VoIP) demand shorter
latency. A long latency for packet transmission is unacceptable. Email and
the File Transfer Protocol (FTP) services are comparatively insensitive to the
latency.

• To support voice, video, and data services of different requirements, the network
is required to distinguish different communication types before providing
corresponding QoS.
▫ The BE mode of traditional IP networks cannot identify and distinguish
various communication types on the networks. This distinguishing capability
is the premise for providing differentiated services. The BE mode cannot
satisfy application requirements, so QoS is introduced.

• What is QoS?
QoS Service Models

Best-Effort (BE) model

QoS provides
three Integrated Services (IntServ)
service models: model

Differentiated Services
(DiffServ) model

8 Huawei Confidential
 BE Model
⚫ An application can send any number of packets at any time.
⚫ The network then makes the best effort to transmit the packets.

！ No guarantee of performance in
terms of delay and reliability

Undifferentiated
treatment
FIFO

9 Huawei Confidential

• The BE model is the simplest service model in which an application can send any
number of packets at any time without obtaining approval or notifying the
network.

• The network then makes the best effort to transmit the packets but provides no
guarantee of performance in terms of delay and reliability.

• The BE model is the default service model for the Internet and applies to various
network applications, such as the File Transfer Protocol (FTP) and email. It uses
FIFO queues.
 IntServ Model
⚫ Before sending packets, an application needs to apply for specific services through signaling.
⚫ After receiving a resource request from an application, the network reserves resources for
each information flow by exchanging RSVP signaling information.

！Complex implementation
and waste of resources
I require 1 Mbit/s
bandwidth.

Live
streaming Reserve 1 Mbit/s Reserve 1 Mbit/s
bandwidth bandwidth

Video
communication

……

10 Huawei Confidential

• The IntServ model is a comprehensive service model to meet various QoS

requirements.
• Before sending packets, an application needs to apply for specific services
through signaling. This request is sent through RSVP. RSVP applies for network
resources for an application before the application starts to send packets.
• Once the network determines to allocate resources to the application, the
network maintains a state for each flow (determined by IP addresses, port
numbers, and protocol numbers at both ends), and performs packet
classification, traffic policing, queuing, and scheduling based on the state. After
receiving the acknowledgment message from the network (the application
confirms that the network has reserved resources for the packets of the
application), the application starts to send packets. As long as packets of the
application are controlled within the range described by traffic parameters, the
network promises to meet QoS requirements of the application.
• Example: If you want to reserve a vehicle, you need to apply for a service in
advance and reserve resources when resources are sufficient.
• However, the vehicle service vendor has to maintain a large number of booking
information.
• Disadvantage: The implementation of the IntServ model is complex. When no
traffic is transmitted, the bandwidth is still exclusively occupied, and the usage is
low. This solution requires that all end-to-end nodes support and run the RSVP
protocol.
 DiffServ Model
⚫ Traffic on a network is classified into multiple classes, and a corresponding processing
behavior is defined for each class, so that the traffic has different forwarding priorities,
packet loss rates, and delays.

Live 1
Traffic classification Live
3
streaming and marking Queue streaming
scheduling

Video Video
communication DS edge node DS node communication
CoS Mapping DS domain
2

FTP FTP
Branch HQ

11 Huawei Confidential

• DiffServ is a multi-service model and can satisfy different QoS requirements.

Currently, this model is widely used on IP networks.

• Before sending a packet, the application does not need to notify the network to
reserve resources for it. In the DiffServ model, the network does not need to
maintain the status of each flow. Instead, it provides specific services based on
precedence fields of packets (for example, the DS field in the IP header).

• The DiffServ model classifies network traffic into multiple classes for
differentiated processing. To be specific, the DiffServ model implements traffic
classification first and allocates different identifiers to different classes of packets.
After a network node receives these packets, it simply identifies these identifiers
and processes packets based on the actions corresponding to these identifiers.

• There is an analogy between the DiffServ model and train ticket service system. A
train ticket marks the service that you book: soft sleeper, hard sleeper, hard seat,
or no seat. You get on a train and enjoy the specific service marked in your ticket.
On an IP network, an identifier is to a packet as a train ticket is to a passenger.

• In addition to traffic classification and marking, the DiffServ model provides the
queuing mechanism. When network congestion occurs on a device, the device
buffers packets in queues. The device sends the packets out of queues when
network congestion is relieved.
 Common QoS Technologies (DiffServ Model)

Traffic limiting
Traffic policing and traffic shaping are used to
monitor the rate of traffic entering the network
and limit the usage of traffic and resources.

Congestion avoidance
Common It adjusts the network traffic to relieve
technologies network overload.

Congestion management
It adjusts the scheduling sequence of packets
to meet high QoS requirements of delay-
sensitive services.

12 Huawei Confidential

• Rate limiting: Traffic policing and traffic shaping monitor the rate of traffic
entering the network to limit the traffic and resource usage, providing better
services for users.

• Congestion avoidance and congestion management: When congestion occurs on

a network, the device determines the sequence in which packets are forwarded
according to a certain scheduling policy so key services are processed first. Or, the
device proactively adjusts traffic to relieve network overload by discarding
packets.
 QoS Data Processing (DiffServ Model)

Token

Video
Queue 0
Inbound interface

Outbound interface
Queue 1

Scheduling
Other
Traffic Re-
Token CAR processing WRED GTS
classification marking Queue 2
bucket …
Voice …
Congestion Traffic
Traffic policing
avoidance shaping
Queue N

Congestion management

Data

13 Huawei Confidential

• QoS technology provides the following functions:

▫ Traffic classification and marking: identify objects based on certain

matching rules, which is the prerequisite for implementing differentiated
services. They are usually applied to the inbound direction of an interface.

▫ Token bucket: is used to check whether traffic meets packet forwarding

conditions.

▫ Traffic policing: monitors the volume of specific data traffic that arrives at
network devices, and is usually applied to incoming traffic. When the traffic
volume exceeds the maximum value, traffic limiting or punishment
measures are taken to protect business interests and network resources of
service providers.

▫ Congestion avoidance: Excessive congestion may damage network

resources. Congestion avoidance monitors the usage of network resources.
When congestion aggravates, congestion avoidance proactively adjusts
traffic to relieve network overload by discarding packets. Congestion
avoidance is generally applied to the outbound direction of an interface.

▫ Congestion management: is taken to solve the problem of resource

competition. Packets are buffered in queues and a scheduling algorithm is
used to determine the forwarding sequence of packets. Congestion
management is usually applied to the outbound direction of an interface.
 Quiz

1. (Multiple-answer question) Which of the following service models are provided by

QoS?（ ）
A. DiffServ model

B. IntServ model

C. BE model

D. Network service model

15 Huawei Confidential

1. ABC
 Section Summary

⚫ QoS service models include the DiffServ, IntServ, and BE models.

⚫ The DiffServ model is the most commonly used QoS model. It provides rate
limiting, congestion avoidance, and congestion management.

16 Huawei Confidential
 Contents

1. Introduction to QoS

2. Traffic Classification and Marking

3. Traffic Limiting Technology

4. Congestion Avoidance Technology

5. Congestion Management Technology

6. Introduction to HQoS

17 Huawei Confidential
 QoS Data Processing

Token

Video
Queue 0
Inbound interface

Outbound interface
Scheduling
Queue 1
Other
Traffic Re-
CAR processing WRED GTS
classification marking Queue 2
…
Voice …

Queue N

Data

18 Huawei Confidential

• Traffic classification and marking: identify objects based on certain matching

rules, which is the prerequisite for implementing differentiated services. They are
usually applied to the inbound direction of an interface.
 Why Are Traffic Classification and Traffic Marking Required?
⚫ Traffic classification and marking are the basis of QoS and the prerequisite for implementing
differentiated services.

Traffic marking
Packets with different Queue
Video priorities
Inbound interface

Traffic
classification

Voice

Data

19 Huawei Confidential

• To implement differentiated services, the traffic entering a DS domain needs to

be classified according to certain rules, and then different services are provided
for different types of traffic.
• After packets are classified at the DS domain edge, intermediate nodes provide
differentiated services for classified packets. The downstream node can accept
the classification result of its upstream node or classifies packets based on its
own criteria.
• Traffic classification and marking are prerequisites for differentiated services.
▫ Traffic classification technology classifies packets into different types, and
does not modify the data packets.

▫ Marking technology marks packets with different priorities, and modifies

the data packets. Marking is classified into internal and external marking.

▪ Internal marking

▪ Sets the CoS and drop precedence of packets for internal processing
on a device so that packets can be placed directly in specific queues.

▪ Setting the drop precedence of packets is also called coloring packets.

When traffic congestion occurs, packets in the same queue are
provided with differentiated buffer services based on colors.
 Behavior Aggregate Classification

BA classification Uplink direction

SFU
VLAN packet 802.1p
Service class
MPLS packet MPLS EXP Mapping Color

IP packet DSCP 802.1p

Service class
Mapping MPLS EXP
Color
DSCP

Downlink direction
Packet header
Service class Color
priority
Different packets
CoS Drop priority
use
of packets of packets
different QoS
on the device on the device
priorities.

External priority Internal priority Drop priority

21 Huawei Confidential

• BA classification allows the device to classify packets based on related values as

follows: IP priority or DSCP value of IPv4 packets, TC value of IPv6 packets, EXP
value of MPLS packets, and 802.1p value of VLAN packets. It is used to simply
identify the traffic that has the specific priority or service classes for mapping
between external and internal priorities.

• BA classification confirms that the priority of incoming packets on a device is

trusted and mapped to the service class and color based on a priority mapping
table. The service class and color of outgoing packets are then mapped back to
the priority.

• Packets carry different types of precedence field depending on the network type.
For example, packets carry the 802.1p value on a VLAN network, the EXP value
on an MPLS network, and the DSCP value on an IP network. To provide
differentiated services for different packets, the device maps the QoS priority of
incoming packets to the scheduling precedence (also called service class) and
drop precedence (also called color), and then performs congestion management
based on the service-class and congestion avoidance based on the color. Before
forwarding packets out, the device maps the service class and color of the
packets back to the QoS priority, which provides a basis for other devices to
process the packets.
 External Priority: VLAN Packet

BA classification Uplink direction Downlink direction

SFU
VLAN packet 802.1p
Service class
MPLS packet MPLS EXP Mapping Color

IP packet DSCP 802.1p

Service class
Mapping MPLS EXP
Color
DSCP

Packet header VLAN packet

priority
Different
Dest add Sour add 802.1Q (PRI) Length/Type Data FCS
packets
use different
QoS priorities.
TPID PRI (3 bits) CFI VLAN ID
External priority
Value range: 0–7

22 Huawei Confidential

• Eight service priorities (PRIs) are defined in the VLAN tag of the Ethernet frame
header.
 External Priority: MPLS Packet

BA classification Uplink direction Downlink direction

SFU
VLAN packet 802.1p
Service class
MPLS packet MPLS EXP Mapping
Color

IP packet DSCP 802.1p

Service class
Mapping MPLS EXP
Color
DSCP

Packet header MPLS packet

priority
Different
Link layer header Label (EXP) Layer 3 header Layer 3 payload
packets
use different
QoS priorities
Label EXP (3 bits) S TTL
External priority
Value range: 0–7

23 Huawei Confidential

• The EXP field in the label is used as the external priority of MPLS packets to
differentiate service classes of data traffic.
 External Priority: IP Packet

BA classification Uplink direction Downstream direction

SFU
VLAN packet 802.1p
Service Class
MPLS packet MPLS EXP Mapping
Color

IP packet DSCP 802.1p

Service Class
Mapping MPLS EXP
Color
DSCP

Packet header IP packet

priority
Different ToS (IP
Version Len … Protocol FCS IP-SA IP-DA Data
packets Precedence/DSCP)
use different
QoS priorities. IP precedence 7 6 5 4 3 2 1 0 Value range: 0–7

External priority
DSCP 7 6 5 4 3 2 1 0 Value range: 0–63

24 Huawei Confidential

• Eight IP service types are defined in the Precedence field of the ToS field in an
IPv4 packet header.

• The ToS field in the IPv4 packet header is redefined as the Differentiated Services
(DS) field. That is, the IP Precedence field is extended.
Mapping Between External Priorities

802.1P MPLS Exp IP-Precedence DSCP DSCP Name

descending order

7 7 7 56-63 CS7 (56)

CS
6 6 6 48-55 CS6 (48)
Priority in

5 5 5 40-47 EF EF (46)
4 4 4 32-39 AF4 AF41 (34) AF42 (36) AF43 (38)
3 3 3 24-31 AF3 AF31 (26) AF32 (28) AF33 (30)
AF
2 2 2 16-23 AF2 AF21 (18) AF22 (20) AF23 (22)
1 1 1 8-15 AF1 AF11 (10) AF12 (12) AF13 (14)
0 0 0 0-7 BE BE (0)

25 Huawei Confidential
 Service Class
BA classification Uplink direction Downlink direction
SFU
VLAN packet 802.1p
Service class
MPLS packet MPLS EXP Mapping
Color

IP packet DSCP 802.1p

Service Class
Mapping MPLS EXP
Color
DSCP

Queue CS7
Service class CS

Priority in descending order

CS6

Service class EF EF Service class

of packets determines the types of queues
AF4
on the device to which packets belong.
AF3
AF
AF2
Internal priority
AF1
BE BE

26 Huawei Confidential

• Service class, that is, queue

• Service classes refer to the internal priorities of packets. Eight service class values
are available: class selector 7 (CS7), CS6, expedited forwarding (EF), assured
forwarding 4 (AF4), AF3, AF2, AF1, and best-effort (BE). Service classes determine
the types of queues to which packets belong.

• The priority of queues with a specific service class is calculated based on

scheduling algorithms.

▫ If queues with eight service classes all use priority queuing (PQ) scheduling,
queues are displayed in descending order of priority: CS7 > CS6 > EF > AF4
> AF3 > AF2 > AF1 > BE.

▫ If the BE queue uses PQ scheduling (this configuration is rare on live

networks) but all the other seven queues use weighted fair queuing (WFQ)
scheduling, the BE queue is of the highest priority.

▫ If the queues of eight service classes all use WFQ scheduling, their priorities
are the same.
 Color
BA classification Uplink direction Downlink direction
SFU
VLAN packet 802.1p
Service class
MPLS packet MPLS EXP Mapping
Color

IP packet DSCP 802.1p

Service class
Mapping MPLS EXP
Color
DSCP

Priority in descending order

Color Green
Drop priority Color
of packets The color of packets determines the order in
on the device Yellow which packets are dropped in a congested queue.

Red

27 Huawei Confidential

• Color, referring to the drop priority of packets on a device, determines the order
in which packets in one queue are dropped when traffic congestion occurs.

• As defined by the Institute of Electrical and Electronics Engineers (IEEE), the color
of a packet can be green, yellow, or red.

• Drop priorities are compared based on the configured parameters. For example,
if a maximum of 50% of the buffer is configured to store packets colored green,
whereas a maximum of 100% of the buffer is configured to store packets colored
red, the drop priority of packets colored green is higher than that of packets
colored red.
 Mapping
BA classification Uplink direction Downlink direction
SFU
VLAN packet 802.1p
Service class
MPLS packet MPLS EXP Mapping
Color
IP packet DSCP 802.1p
Service class
Mapping MPLS EXP
Color
DSCP

Uplink mapping Downlink mapping

DSCP Service Class/Color Service Class/Color DSCP

32-39 34 36 38 AF41 AF42 AF43 AF41 AF42 AF43 32-39 34 36 38

24-31 26 28 30 AF31 AF32 AF33 AF31 AF32 AF33 24-31 26 28 30
AF AF
16-23 18 20 22 AF21 AF22 AF23 AF21 AF22 AF23 16-23 18 20 22
8-15 10 12 14 AF11 AF12 AF13 AF11 AF12 AF13 8-15 10 12 14

• Mapping from external priorities to internal priorities • Mapping from internal priorities to external priorities

28 Huawei Confidential

• A device maps the QoS priority to the service class and color for incoming
packets and maps the service class and color back to the QoS priority for
outgoing packets.
 Multi-field Classification
Real-time services such
as voice and video
services are given the
highest priority.
Live streaming Live streaming

Video Video
communication communication
DS edge node

MF classification Configure a traffic

classifier
FTP FTP
MF classification classifies packets based on complex
HQ rules in a fine-grained manner, such as the 5-tuple Configure a traffic Branch
behavior
(source IP address, source port number, protocol number,
destination address, and destination port number).
Configure a traffic
policy
Template-based QoS
Apply the traffic
policy

29 Huawei Confidential

• As networks rapidly develop, services on the Internet become increasingly

diversified. Various services share limited network resources. In particular,
multiple services use port number 80. Because of this increasing demand,
network devices are required to possess a high degree of sensitivity for services,
including an in-depth parsing of packets and a comprehensive understanding of
any packet field at any layer. This level of sensitivity rises far beyond what BA
classification can offer. MF classification can be deployed to help address this
sensitivity deficit.

• MF classification classifies packets based on complex rules in a fine-grained

manner, such as the 5-tuple (source IP address, source port number, protocol
number, destination address, and destination port number).
Traffic Policy Overview
⚫ Modular QoS command line interface (MQC) uses traffic policies.
⚫ A traffic policy is often bound to traffic classifiers and traffic behaviors. A traffic classifier is used to
match data packets, and a traffic behavior is used to modify data packets.
Execution in sequence

Traffic policy Traffic policy 1 Traffic policy 2

Traffic classifier Traffic behavior Traffic classifier Traffic behavior

OR Modification in OR Modification in
sequence sequence
Traffic matching Traffic modification Traffic matching Traffic modification
rule 1 rule 1 rule 1 rule 1
Data flow
Traffic matching Traffic modification Traffic matching Traffic modification
rule 2 rule 2 rule 2 rule 2

Traffic matching Traffic modification Traffic matching Traffic modification

rule 3 rule 3 rule 3 rule 3

30 Huawei Confidential
 Traffic Classification Process
Real-time services such
as voice and video
services are given the
highest priority.

Live streaming MF BA Live streaming

classification classification

Video Video
communication communication
DS edge node DS node DS node DS edge node

FTP FTP

HQ Branch

31 Huawei Confidential

• Requirement: The highest forwarding priority must be provided for real-time

services such as voice and video services.

• Implementation: The DS edge node obtains service traffic such as voice and video
traffic through MF classification and maps the traffic to the corresponding
priorities. It processes the remaining traffic through BA classification.
Configuring MF Classification
DS edge node DS node system-view
traffic classifier [classifier-name] //Create a traffic classifier.
if-match [acl | vlan-id | …. ] //Match traffic based on traffic
DS domain characteristics.

• Typically, the traffic received by the DS edge system-view

node is not classified, so complex traffic traffic behavior [behavior-name] //Create a traffic behavior.
remark [dscp-name | 8021p-value | EXP | … ] //Re-mark the
classification is configured on the DS edge node. QoS field of traffic.
The configuration roadmap is as follows:
system-view
▫ Configure a traffic classifier to match traffic.
traffic policy [policy-name] //Create a traffic policy.
▫ Configure a traffic behavior to define an action taken classifier [classifier-name] behavior [behavior-name] //Bind
the traffic classifier to the traffic behavior.
on the matched traffic.

▫ Bind the traffic classifier and traffic behavior to a system-view

traffic policy. interface [interface-type interface-num] //Enter the interface
view.
▫ Apply the traffic policy to the inbound direction of traffic-policy [policy-name] [inbound | outbound] //Apply the
the interface on the DS edge node. traffic policy to the inbound direction of an interface.

32 Huawei Confidential
Checking the MF Classification Configuration
⚫ After MF classification is configured, you can run the following commands to check the configuration.

system-view
display traffic classifier user-defined [ classifier-name ] //Check the traffic classifier configuration.
display traffic behavior [ system-defined | user-defined ] [ behavior-name ] //Check the traffic behavior configuration.
display traffic policy user-defined [ policy-name ] classifier [classifier-name ] //Check the traffic policy configuration.
display traffic-policy applied-record [ policy-name ] //Check the record of the specified traffic policy.

33 Huawei Confidential
(Optional) Modifying the BA Classification Configuration
⚫ Specify the packet priority trusted on an
DS edge node DS node
interface.
system-view
interface [interface-type interface-num] //Enter the
DS domain
interface view.
trust [8021p | dscp] //Specify the priority to be trusted.
• Based on the priority mapping table, BA
classification maps data with the specific QoS ⚫ Configure a priority mapping table.
system-view
field to the internal priority. qos map-table [ dot1p-dot1p | dot1p-dscp | dot1p-lp | dscp-
dot1p | dscp-dscp | dscp-lp ] //Enter the priority mapping table
• The priority mapping table can be modified as view.
input [input-value1] output [output-value] //Configure
required. The roadmap is as follows: mappings in the priority mapping table.

▫ Specify the packet priority trusted on an interface.

▫ Configure a priority mapping table.

34 Huawei Confidential
Checking the Priority Mapping Configuration
⚫ After the priority mapping configuration is modified, you can run the following commands to check the
configuration.

system-view
display qos map-table [ dot1p-dot1p | dot1p-dscp | dot1p-lp | dscp-dot1p | dscp-dscp | dscp-lp ]
//Check the mapping between priorities.

35 Huawei Confidential
 Quiz

1. (True or false) MF classification is generally deployed in the inbound direction of the DS

edge node.( )
A. True

B. False

2. (Multiple-answer question) Which of the following parameters are used to mark the QoS
priority of data packets?( )
A. EXP

B. 802.1p

C. DSCP

D. IP precedence

36 Huawei Confidential

1. A

2. ABCD
 Section Summary

⚫ The DiffServ model must mark packets for differentiating them. Generally, MF
classification is used to mark incoming traffic on edge devices in a DS domain, and
BA classification is used to mark incoming traffic on devices in a DS domain.
⚫ Tags can be added to multiple types of data packet headers.
 The Pri bit (802.1p priority) in the VLAN header is used to mark the QoS priority.
 The EXP bit in the MPLS header is used to mark the QoS priority.
 The TOS bit (DSCP/IP precedence) in the IP header is used to mark the QoS priority.

37 Huawei Confidential
 Contents

1. Introduction to QoS

2. Traffic Classification and Marking

3. Traffic Limiting Technology

4. Congestion Avoidance Technology

5. Congestion Management Technology

6. Introduction to HQoS

38 Huawei Confidential
 Traffic Limiting Token Bucket Traffic Policing Traffic Shaping

QoS Data Processing

Video Queue 0

Outbound interface
Inbound interface

Queue 1

Scheduling
Other
Traffic
CAR Re-marking processing WRED GTS
classification Queue 2
…
Voice …
Traffic policing Traffic
shaping
Queue N

Data

Traffic policing Traffic shaping

• Function
Monitors the traffic Controls the rate of
• Monitor network traffic at the network edge.
entering the device outgoing packets so
• Specify the bandwidth usage for different
to ensure that that packets are sent
incoming and outgoing traffic so that different
network resources at an even rate.
services are allocated different bandwidths.
are not abused.

39 Huawei Confidential

• This course describes two rate limiting technologies: traffic policing and traffic
shaping.
• Traffic policing: If the traffic rate of a connection exceeds the specifications on an
interface, traffic policing allows the interface to drop excess packets or re-mark
the packet priority to protect network resources and protect carriers' profits. An
example of this process is restricting the rate of HTTP packets to 50% of the
network bandwidth.
• Traffic shaping: allows the traffic rate to match that on the downstream device.
When traffic is transmitted from a high-speed link to a low-speed link or a traffic
burst occurs, the inbound interface of the low-speed link is prone to severe data
loss. To prevent this problem, traffic shaping must be configured on the
outbound interface of the device connecting to the high-speed link.
 Traffic Limiting Token Bucket Traffic Policing Traffic Shaping

Traffic Limiting Technology

Video Queue 0

Outbound interface
Inbound interface

Scheduling
Queue 1
Other
Traffic Re-
CAR processing WRED GTS
classification marking Queue 2
…
Voice …
Traffic
Traffic policing
shaping
Queue N

Data Token bucket

technology
Token

Token
bucket

40 Huawei Confidential

• Both traffic policing and traffic shaping use the token bucket technology.

▫ Token bucket: A token bucket is used to check whether traffic meets packet
forwarding conditions.
 Traffic Limiting Token Bucket Traffic Policing Traffic Shaping

Single-Rate-Single-Bucket Mechanism
• Committed Information Rate (CIR):
 indicates the rate at which tokens are put into
bucket C, in kbit/s.
Token
• Committed burst size (CBS):
Discard packets
 indicates the maximum volume of burst traffic that in the case of
bucket C allows before the rate of some traffic CIR overflow
exceeds the CIR, that is, the capacity of bucket C.
The value is expressed in bytes.

Initial
Bucket CBS number of
• The single-rate-single-bucket mechanism does C
tokens (Tc)
not allow burst traffic. Only committed traffic is = CBS
allowed. The data packet is marked green
Yes (Tc = Tc-B) and forwarded by default.
B < Tc?
Size of an arriving
packet (B) No (Tc remains unchanged)
The data packet is marked red
and discarded by default.

41 Huawei Confidential

• When a packet arrives, the device compares the packet with the number of
tokens in the bucket. If there are sufficient tokens, the packet is forwarded (one
token is associated with 1-bit forwarding permission). If there are no enough
tokens, the packet is discarded or buffered.

• Tc and Te refer to the numbers of tokens in buckets C and E, respectively. The

initial values of Tc and Te are respectively the CBS and EBS.

• In color-blind mode (B indicates the size of an arriving packet):

▫ If B is less than or equal to Tc, the packet is marked green, and Tc

decreases by B.

▫ If B is greater than Tc, the packet is marked red, and Tc remains

unchanged.
 Traffic Limiting Token Bucket Traffic Policing Traffic Shaping

Single-Rate-Two-Bucket Mechanism
Initial number of tokens
• CIR:
Token Bucket C: Tc = CBS
 Indicates the rate at which tokens are put into Bucket E: Te = EBS
bucket C, in kbit/s. Token overflow
• CBS: CIR
 Indicates the maximum volume of burst traffic that
bucket C allows before the rate of some traffic
exceeds the CIR, that is, the capacity of bucket C.
The value is expressed in bytes. Bucket Bucket
CBS EBS
C E

• Excess burst size (EBS):

 Indicates the maximum volume of excess burst The data packet is marked green
traffic that bucket E allows. The value is expressed and forwarded by default.
Yes (Tc = Tc-B)
in bytes. B < Tc ?

Size of an arriving The data packet is marked yellow

packet (B) No
• The single-rate-two-bucket mechanism allows and forwarded by default.
Yes (Te = Te-B)
transient burst traffic. Tc<B<Te?

No (Tc and Te remain unchanged)

The data packet is marked red
and discarded by default.

42 Huawei Confidential

• When a packet arrives, the device compares the packet with the number of
tokens in the bucket. If there are sufficient tokens, the packet is forwarded (one
token is associated with 1-bit forwarding permission). If there are no enough
tokens, the packet is discarded or buffered.

• Tc and Te refer to the numbers of tokens in buckets C and E, respectively. The

initial values of Tc and Te are respectively the CBS and EBS.

• In color-blind mode (B indicates the size of an arriving packet):

▫ If B is less than or equal to Tc, the packet is marked green and Tc decreases
by B.

▫ If B is greater than Tc and less than or equal to Te, the packet is marked
yellow and Te decreases by B.

▫ If B is greater than Te, the packet is marked red, and Tc and Te remain
unchanged.
 Traffic Limiting Token Bucket Traffic Policing Traffic Shaping

Two-Rate-Two-Bucket Mechanism
• Peak Information Rate (PIR): Initial number of tokens
 Indicates the rate at which tokens are put into Token Token Bucket P: Tp = PBS
Bucket C: Tc = CBS
bucket P, that is, the maximum traffic rate that Discard packets in the
bucket P allows. The PIR is greater than the CIR. The PIR case of overflow Discard packets in the
value is expressed in kbit/s. case of overflow
• Peak burst size (PBS): CIR
 Indicates the capacity of bucket P, that is, the
maximum volume of burst traffic that bucket P
allows. The PBS is greater than the CBS. The value is
Bucket Bucket
expressed in bytes. PBS CBS
P C

• CIR:
 Indicates the rate at which tokens are put into Yes (Tc and Tp The data packet is marked red
bucket C, in kbit/s. remain unchanged) and discarded by default.
B > Tp?
• CBS:
 Indicates the maximum volume of burst traffic that Size of an arriving The data packet is marked
packet (B) No
bucket C allows before the rate of some traffic Yes (Tp = Tp-B) yellow and forwarded by default.
exceeds the CIR, that is, the capacity of bucket C.
Tp > B > Tc?
The value is expressed in bytes.

No (Tc = Tc-B)
• The two-rate-two-bucket mechanism allows
The data packet is marked green
long-term burst traffic. and forwarded by default.

43 Huawei Confidential

• The two rate three color marker (trTCM) algorithm focuses on the traffic burst
rate and checks whether the traffic rate conforms to the specifications. Therefore,
traffic is measured based on bucket P and then bucket C.

• Tc and Tp refer to the number of tokens in buckets C and P, respectively. The

initial values of Tc and Tp are respectively the CBS and PBS.

• In color-blind mode (B indicates the size of an arriving packet):

▫ If B is greater than Tp, the packet is marked red and Tc and Tp remain
unchanged.

▫ If B is greater than Tc and less than or equal to Tp, the packet is marked
yellow and Tp decreases by B.

▫ If B is less than or equal to Tc, the packet is marked green, and Tp and Tc
decrease by B.
 Traffic Limiting Token Bucket Traffic Policing Traffic Shaping

What Is Traffic Policing?

• Traffic policing
Data flow:
100 Mbit/s • By monitoring the specifications of a certain type of
LAN WAN traffic that enters the network, you can limit the traffic
High- Low-
speed link speed link within an allowed range. If the traffic of a connection is
Configure traffic policing too heavy, the packets are discarded or the priority of the
Interface
in the inbound direction bandwidth is packets is re-set to protect network resources. Traffic
of the interface. only 2 Mbit/s. policing can be configured in inbound and outbound
directions of an interface.
When traffic policing is used,
packets exceeding the rate
Packet rate limit may be discarded or their
priorities may be lowered.
Traffic policing
• Implementation of traffic policing
not configured
• Traffic policing uses the committed access
CIR rate (CAR) to control traffic. CAR uses the
token bucket algorithm to evaluate the
traffic rate and implements preset policing
actions based on the evaluation result.
Time

44 Huawei Confidential

• In the figure:

▫ An edge network device connects a wide area network (WAN) and a local
area network (LAN). The LAN bandwidth (100 Mbit/s) is higher than the
WAN bandwidth (2 Mbit/s).

▫ When a LAN user attempts to send a large amount of data to a WAN, the
edge network device is prone to traffic congestion. Traffic policing can be
configured on the edge network device to restrict the traffic rate,
preventing traffic congestion.

• Characteristics of traffic policing:

▫ Drops excess traffic over the specifications or re-marks such traffic with a
lower priority.

▫ Consumes no additional memory resources and brings no delay or jitter.

▫ Packet loss may result in packet retransmission.

▫ Traffic can be re-marked.

 Traffic Limiting Token Bucket Traffic Policing Traffic Shaping

CAR
⚫ CAR uses token buckets to measure traffic and determines whether a packet conforms to the specification.
Packets are forwarded at the original rate.
(Traffic policing is not required.)

Traffic policing actions

Packets do not match rules.

Packets Remark
match rules.
Compliant Forward
Traffic
Arriving packets classification
Discard
Token bucket

• Token bucket modes • The device marks the packet red, yellow, or green based on
the metering result using the token bucket.
1. Single-rate-single-bucket
1. Green indicates that the packets comply with the specifications
2. Single-rate-two-bucket
and are directly forwarded.
3. Two-rate-two-bucket
2. Yellow indicates that temporary burst traffic is allowed although it
does not comply with specifications. After the traffic is re-marked,
the priority is reduced and the traffic is forwarded in BE mode.
3. Red indicates that the packet rate is high and does not comply
with the specifications. Therefore, the packets are discarded.

45 Huawei Confidential

• Traffic policing uses CAR to control traffic. CAR uses token buckets to measure
traffic and determines whether a packet conforms to the specification.

• CAR has the following two functions:

▫ Rate limiting: Only packets allocated enough tokens are allowed to pass so
that the traffic rate is restricted.

▫ Traffic classification: Packets are marked internal priorities, such as the

service class and drop priority, based on the measurement performed by
token buckets.

• CAR process:

▫ When a packet arrives, the device matches the packet against matching
rules. If the packet matches a rule, the device uses token buckets to meter
the traffic rate.

▫ The device marks the packet red, yellow, or green based on the metering
result using the token bucket. Red indicates that the traffic rate exceeds the
specifications. Yellow indicates that the traffic rate exceeds the
specifications but is within an allowed range. Green indicates that the
traffic rate is conforming to the specifications.

▫ The device drops packets marked red, re-marks and forwards packets
marked yellow, and forwards packets marked green.
 Traffic Limiting Token Bucket Traffic Policing Traffic Shaping

Application Scenario of Traffic Policing

It is generally used to control incoming

traffic and prevent excess traffic from
entering the device.
It is recommended for delay-sensitive
traffic (such as video and voice traffic).
App 1
Video
Traffic
• Application of traffic policing direction

1. Interface-based traffic policing LAN WAN

2. Class-based traffic policing Voice
Configure traffic policing
Data in the inbound direction
of the interface.

47 Huawei Confidential

• Voice, video, and data services are transmitted on an enterprise network. When a
large amount of traffic enters the network, congestion may occur due to
insufficient bandwidth. Different guaranteed bandwidth must be provided for the
voice, video, and data services in descending order of priority. In this situation,
traffic policing can be configured to provide the highest guaranteed bandwidth
for voice packets and lowest guaranteed bandwidth for data packets. This
configuration ensures preferential transmission of voice packets during
congestion.

• Interface-based traffic policing

▫ Interface-based traffic policing controls all traffic that enters an interface

and does not identify the packet types. (based on the interface)

• Class-based traffic policing

▫ Class-based traffic policing controls the rate of one or more types of

packets that enter an interface. (based on traffic classification)
 Traffic Limiting Token Bucket Traffic Policing Traffic Shaping

Configuring Interface-based Traffic Policing

⚫ Configure interface-based traffic policing.
DS edge device DS node

DS domain
system-view
interface [interface-type interface-num] //Enter the
interface view.
• Typically, traffic policing is performed in the inbound qos car [ inbound | outbound ] [ acl acl-number |
direction of a device. Traffic policing can be deployed destination-ip-address | source-ip-address ] cir [cir-value] [ pir pir-
value ] [ cbs cbs-value pbs pbs-value ] //Configure traffic
on the terminal side or in the inbound direction of an policing for specific traffic in the inbound or outbound direction of
an interface. The CIR must be configured. The CIR indicates the
egress device as required. Traffic policing can be maximum committed rate of traffic policing. If the PIR is not
configured based on interfaces or MQC. configured, it is equal to the CIR. In this case, the traffic rate
cannot be higher than the CIR.
• The configuration roadmap of interface-based traffic
policing is as follows:
▫ Set the maximum bandwidth for traffic policing on an
interface, select the traffic to be policed, and adjust the
behavior to be taken on the excess traffic.

48 Huawei Confidential
 Traffic Limiting Token Bucket Traffic Policing Traffic Shaping

Configuring MQC-based Traffic Policing

DS edge device DS node system-view
traffic classifier [classifier-name] //Create a traffic
DS domain classifier.
if-match [acl | vlan-id | …. ] //Match traffic based on
• MQC can be used to implement traffic policing in traffic characteristics.

a more refined manner. The device can control system-view

traffic and allocate different bandwidths based traffic behavior [behavior-name] //Create a traffic
behavior.
on the 5-tuple and QoS value of the data packet. car cir [cir-value] [ pir pir-value ] [ cbs cbs-value pbs pbs-
value ] //Set the CIR and PIR.
• The configuration roadmap is as follows:
system-view
▫ Configure a traffic classifier to match traffic.
traffic policy [policy-name] //Create a traffic policy.
▫ Configure a traffic behavior to define actions taken classifier [classifier-name] behavior [behavior-name]
//Bind the traffic classifier to the traffic behavior.
for packets.

▫ Bind the traffic classifier and traffic behavior to a system-view

interface [interface-type interface-num] //Enter the
traffic policy. interface view.
traffic-policy [policy-name] [inbound | outbound] //Apply
▫ Apply the traffic policy to an interface.
the traffic policy to the inbound direction of an interface.

49 Huawei Confidential
 Traffic Limiting Token Bucket Traffic Policing Traffic Shaping

Checking the Traffic Policing Configuration

⚫ After interface-based traffic policing is configured, you can run the following commands to check the
configuration.
system-view
display qos car statistics interface [interface-type interface-num] [inbound | outbound] //Check statistics on forwarded and
discarded packets on the interface.

⚫ After MQC-based traffic policing is configured, you can run the following commands to check
the configuration.

system-view
display traffic classifier user-defined [ classifier-name ] //Check the traffic classifier configuration.
display traffic behavior [ system-defined | user-defined ] [ behavior-name ] //Check the traffic behavior configuration.
display traffic policy user-defined [ policy-name ] classifier [classifier-name ] //Check the traffic policy configuration.
display traffic-policy applied-record [ policy-name ] //Check the record of the specified traffic policy.

50 Huawei Confidential
 Traffic Limiting Token Bucket Traffic Policing Traffic Shaping

What Is Traffic Shaping?

Outbound direction
of the interface • Traffic shaping
Data flow: Traffic shaping
100 Mbit/s • Traffic shaping is a measure to adjust the traffic rate
LAN WAN
sent from an interface.
High- Low-speed
• Traffic shaping is configured on the outbound interface
speed link link
Interface Interface of an upstream device so that irregular traffic can be
bandwidth bandwidth transmitted at an even rate, preventing transient traffic
is 1 Gbit/s. is only 2 Mbit/s.
congestion on the downstream device.

Packet rate Traffic shaping

not deployed • Implementation of traffic shaping
• Traffic shaping is implemented using the
Traffic shaping
deployed buffer and token bucket.
CIR
• Token bucket mode: single-rate-single-bucket
• Assessment result: compliant (green),
non-compliant (red)
Time

51 Huawei Confidential

• Generic Traffic Shaping (GTS)

▫ When traffic is transmitted from a high-speed link to a low-speed link or a

traffic burst occurs, the inbound interface of the low-speed link is prone to
severe data loss. To prevent this problem, configure traffic shaping on the
outbound interface of the device connecting to the high-speed link.

▫ When packets are sent at a high speed, they are cached and then evenly
sent through the token bucket.

• Characteristics of traffic shaping:

▫ Buffers excess traffic over the specifications.

▫ Consumes memory resources for buffering excess traffic and brings delay
and jitter.

▫ Packet loss rarely occurs, so packets are seldom retransmitted.

▫ Traffic re-marking is not supported.

• Token bucket mode: single-rate-single-bucket — The evaluation result can be

either green or red.
 Traffic Limiting Token Bucket Traffic Policing Traffic Shaping

Implementation of Traffic Shaping (1)

Queue-based traffic shaping

• Queue-based traffic shaping

• Applies to each queue on an

Scheduling
Leave a No outbound interface.
Queue queue Shaping? Forward

Yes

Compliant
Token bucket The data packets
that are leaving
queues are still
forwarded.
When packets in a queue are Exceeding
transmitted at a rate exceeding the
specifications, the queue is marked
unscheduled and will be scheduled
when the bandwidth is available.

52 Huawei Confidential

• When packets leave queues, the packets that do not need to be shaped are
forwarded. The packets that need to be shaped are measured against token
buckets.

▫ If the packet rate conforms to the rate limit, the packet is marked green
and forwarded.

▫ If the rate of a data packet exceeds the threshold, the data packet is still
forwarded. In this case, the status of the queue where the data packet is
located is changed to unscheduled, and the queue is scheduled when the
token bucket is filled with new tokens. After the queue is marked
unscheduled, more packets can be put into the queue, but excess packets
over the queue capacity are dropped. Therefore, traffic shaping allows
traffic to be sent at an even rate but does not provide zero-packet-loss
guarantee.
 Traffic Limiting Token Bucket Traffic Policing Traffic Shaping

Implementation of Traffic Shaping (2)

Interface-based traffic shaping

• Interface-based traffic shaping
• Limits the total rate of all packets sent by
Queue 1
Token bucket an interface. Traffic shaping is performed
All queues on

Queue 2 on the outbound interface, regardless of

Scheduling
an interface

Leave a packet priorities.

Queue 3 queue
…
Forward the packet if
Queue N the packet conforms
to the rate limit

If the packet rate exceeds the rate limit,

the interface stops scheduling and waits
for sufficient tokens to continue
scheduling.

53 Huawei Confidential

• When packets leave queues, all queues are measured together against token
buckets.

▫ If the packet rate conforms to the rate limit, the packet is marked green
and forwarded.

▫ If the packet rate exceeds the threshold (that is, tokens in the token bucket
are insufficient), the packet is marked red. In this case, the interface stops
scheduling and continues to schedule the packets when there are sufficient
tokens.
 Traffic Limiting Token Bucket Traffic Policing Traffic Shaping

Application Scenario of Traffic Shaping

⚫ On an enterprise network, the enterprise headquarters is connected to branches through private lines on an ISP network. Branches connect to the Internet
through the headquarters.

⚫ If all branches connect to the Internet at the same time, a large amount of web traffic sent from the headquarters to the Internet causes network
congestion. As a result, some web traffic is discarded.. As shown in the figure, to prevent web traffic loss, traffic shaping can be configured before traffic
sent from enterprise branches enters the enterprise headquarters.

Uplink mapping

Traffic direction

Configure
traffic shaping in the
Branch 1 outbound direction of
an interface.

ISP HQ Internet

Branch 2

• Traffic shaping is generally used in the outbound direction of an interface and is mainly used to limit the traffic rate. It
is recommended for packet loss-sensitive traffic (such as Internet access and service download).

54 Huawei Confidential
Configuring Interface-based Traffic Shaping
⚫ Configure interface-based traffic shaping.
DS edge node DS node
system-view
DS domain interface [interface-type interface-num] //Enter the
interface view.
qos gts cir [cir-value] [ cbs cbs-value ] //Configure traffic
shaping in the outbound direction of an interface. The CIR
• Traffic shaping can be configured only in the indicates the maximum traffic shaping rate. You can configure the
CBS as required to control the size of the token bucket. The CIR
outbound direction of a device. It falls into interface-
must be configured.
based, queue-based, and MQC-based traffic shaping.

• Interface-based traffic shaping has a large

granularity. The configuration roadmap is as follows:
▫ Deploy traffic shaping in the outbound direction of an
interface and configure the maximum bandwidth.

55 Huawei Confidential
Configuring Queue-based Traffic Shaping
⚫ Create a queue profile and configure queue shaping.
DS edge node DS node
system-view
interface [interface-type interface-num] //Enter the
DS domain interface view.
qos queue-profile [queue-profile-name] //Create a queue
profile.
• To shape packets in each queue on an interface, queue [start-queue-index] to [end-queue-index ] gts cir
[cir-value] [ cbs cbs-value ] //Configure traffic shaping for a
configure a queue profile and apply it to the interface. specified queue in the outbound direction and set the CIR.

• You can set different traffic shaping parameters for ⚫ Apply the queue profile to an interface.
queues with different priorities to provide system-view
differentiated services. The configuration roadmap is interface [interface-type interface-num] //Enter the
interface view.
as follows: qos queue-profile [queue-profile-name] //Apply the queue
profile to the interface.
▫ Create a queue profile.

▫ Configure queue shaping.

▫ Apply the queue profile to an interface.

56 Huawei Confidential
Configuring MQC-based Traffic Shaping
DS edge node DS node system-view
traffic classifier [classifier-name] //Create a traffic
classifier.
DS domain if-match [acl | vlan-id | …. ] //Match traffic based on
traffic characteristics.

system-view
• MQC-based traffic policing uses traffic classifiers to traffic behavior [behavior-name] //Create a traffic
implement differentiated services. behavior.
gts cir [cir-value] | pct [pct-value] //Configure traffic shaping
based on the maximum traffic rate or the percentage of the
• The configuration roadmap is as follows:
occupied interface bandwidth.
▫ Configure a traffic classifier to match traffic. system-view
traffic policy [policy-name] //Create a traffic policy.
▫ Configure a traffic behavior to define an action for packets.
classifier [classifier-name] behavior [behavior-name]
▫ Bind the traffic classifier and traffic behavior to a traffic //Bind the traffic classifier to the traffic behavior.
policy. system-view
interface [interface-type interface-num] //Enter the
▫ Apply the traffic policy to an interface in the outbound interface view.
direction. traffic-policy [policy-name] [inbound | outbound] //Apply
the traffic policy to the interface in the outbound direction.

57 Huawei Confidential
Checking the Traffic Shaping Configuration
⚫ After queue-based traffic shaping is configured, you can run the following commands to check the
configuration.
system-view
display qos queue-profile [ queue-profile-name ] //Check the queue profile configuration.

⚫ After MQC-based traffic shaping is configured, you can run the following commands to check the
configuration.

system-view
display traffic classifier user-defined [ classifier-name ] //Check the traffic classifier configuration.
display traffic behavior [ system-defined | user-defined ] [ behavior-name ] //Check the traffic behavior configuration.
display traffic policy user-defined [ policy-name ] classifier [classifier-name ] //Check the traffic policy configuration.
display traffic-policy applied-record [ policy-name ] //Check the record of the specified traffic policy.

58 Huawei Confidential
 Quiz

1. (True or false) Traffic shaping caches excess traffic by default, and traffic policing discards
excess traffic by default.( )
A. True

B. False

2. (Multiple-answer question) How many modes of token buckets are used to measure
traffic?( )
A. Single-rate-single-bucket

B. Three-rate-two-bucket

C. Single-rate-two-bucket

D. Two-rate-two-bucket

59 Huawei Confidential

1. A

2. ACD
 Section Summary
⚫ There are two traffic limiting technologies: traffic policing and traffic shaping.
⚫ Traffic policing discards excess traffic by default. It can be deployed in inbound and outbound
directions of a device.
⚫ Traffic shaping caches excess traffic by default. It can be deployed only in the outbound direction of a
device.
⚫ The device uses token buckets to measure traffic. There are three modes of token buckets:
 The single-rate-single-bucket mechanism can be used together with traffic policing and traffic shaping.
 The single-rate-two-bucket mechanism can be used only with traffic policing, and is mainly used in scenarios where
burst traffic occurs occasionally.
 The two-rate-two-bucket can be used only with traffic policing, and is mainly used in scenarios with long-term
burst traffic.

60 Huawei Confidential
 Contents

1. Introduction to QoS

2. Traffic Classification and Marking

3. Traffic Limiting Technology

4. Congestion Avoidance Technology

5. Congestion Management Technology

6. Introduction to HQoS

61 Huawei Confidential
 QoS Data Processing

Token

Video Queue 0

Outbound interface
Inbound interface

Queue 1

Scheduling
Other
Traffic Re-
Token CAR processing WRED GTS
classification marking Queue 2
bucket …
Voice …
Congestion
avoidance
Queue N
What is
Data congestion?

62 Huawei Confidential

• Congestion avoidance: Excessive congestion may damage network resources.

Congestion avoidance monitors the usage of network resources. When
congestion aggravates, congestion avoidance adjusts traffic to relieve network
overload by discarding packets. Congestion avoidance is generally applied to the
outbound direction of an interface.
 Background of Congestion Occurrence

Bandwidth mismatch
100 Mbit/s 10 Mbit/s

WAN High- Low-speed

speed link link

Congestion point
Aggregation problem
Data flow
10 Mbit/s

100 Mbit/s 100 Mbit/s

LAN LAN

63 Huawei Confidential

• Traffic congestion occurs when multiple users compete for the same resources
(such as the bandwidth and buffer) on the shared network.

▫ For example, a user on a LAN sends data to a user on another LAN through
a WAN. The WAN bandwidth is lower than the LAN bandwidth. Therefore,
data cannot be transmitted at the same rate on the WAN as that on the
LAN. Traffic congestion occurs on the router connecting the LAN and WAN.

• Congestion often occurs in the following situations:

▫ Traffic rate mismatch: Packets are transmitted to a device through a high-

speed link and are forwarded out through a low-speed link.

▫ Traffic aggregation: Packets are transmitted from multiple interfaces to a

device and are forwarded out through a single interface without enough
bandwidth.
 Impact of Congestion

• Traffic congestion has the following adverse impacts on network traffic:

1. Traffic congestion intensifies delay and jitter.
2. Overlong delays lead to packet retransmission.
Impact 3. Traffic congestion lowers the network throughput and damages network resources.
4. Intensified traffic congestion consumes a large number of network resources
(especially storage resources). Unreasonable resource allocation may cause
resources to be locked and the system to break down.

Solution 1. Congestion avoidance

2. Congestion management

64 Huawei Confidential

• Impact of congestion:

▫ Congestion prevents traffic from obtaining resources immediately, which

causes service deterioration. However, congestion often occurs in a complex
networking environment where packet transmission and provisioning of
various services are both required. Therefore, effective methods are
required to avoid congestion or prevent congestion from aggravating.

• Solutions:

▫ The solutions need to make full use of network resources on the premise of
meeting users' requirements for service quality. Congestion management
and congestion avoidance are commonly used to relieve traffic congestion.

▫ Congestion management provides means to manage and control traffic

when traffic congestion occurs.

▫ Congestion avoidance is a flow control technique used to relieve network

overload. By monitoring the usage of network resources in queues or
memory buffer, a device automatically drops packets on the interface that
shows a sign of traffic congestion. Congestion avoidance prevents queues
from being overflowed due to network overload. The following will
introduce congestion avoidance technology.
Congestion Avoidance Technology
⚫ Congestion avoidance is a flow control technique used to relieve network overload. By monitoring the
usage of network resources for queues or memory buffers, a device automatically drops packets that
shows a sign of traffic congestion.

Data sending queue

Monitor
Queue 0

Queue 1
1. Tail drop: traditional processing
Congestion Drop
avoidance Queue 2 2. Random Early Detection (RED)
policies
… 3. Weighted Random Early Detection (WRED)

Queue N

• If congestion becomes severe, the packets that

do not enter queues are discarded.

65 Huawei Confidential
 Policy 1: Tail Drop
⚫ When the length of a queue reaches the maximum value, the device enabled with tail drop discards all
new packets buffered at the tail of the queue.

Six packets per second Four packets per second

6 5 4 3 2 1

Subsequent packets sent to the The queue is full.

queue are directly discarded.

66 Huawei Confidential

• Due to the limited length of each queue, when a queue is full, the traditional
processing method discards all the packets sent to the queue until the congestion
is relieved. This processing method is called tail drop.
 Disadvantage 1: Global TCP Synchronization
⚫ When the length of a queue reaches the maximum value, the device enabled with tail drop discards all
new packets buffered at the tail of the queue.
Problem
Global TCP
synchronization
The TCP connection
cannot be established.
• Process:
Traffic
1. TCP starts.
2. Traffic is too heavy. As a result, the queue is full and tail
2
3 drop occurs.
Maximum 3. The TCP ACK packet returned by the server is discarded
value due to congestion. Therefore, the sender does not receive
the TCP ACK packet and considers that the network is
4 congested. In this case, the TCP sliding window size is
reduced, and the overall traffic is also reduced.
4. At this time, network congestion is eliminated, and the
sender can receive the TCP ACK packet. Therefore, the
sender considers that the network is not congested, and
1
Time enters the TCP slow start process. This process is repeated.

67 Huawei Confidential

• As shown in the following figure, three colors indicate three TCP connections.

• Global TCP synchronization:

▫ In tail drop mechanism, all newly arrived packets are dropped when
congestion occurs, causing all TCP sessions to simultaneously enter the slow
start state and the packet transmission to slow down.

▫ When packets of multiple TCP connections are discarded in a queue, TCP

connections enter the congestion avoidance and slow start state to adjust
and reduce traffic. This is called TCP global synchronization. Then all TCP
sessions restart their transmission at roughly the same time and then
congestion occurs again, causing another burst of packet drops, and all TCP
sessions enter the slow start state again. The behavior cycles constantly,
severely reducing the network resource usage.
 Disadvantage 2: Undifferentiated Drop
⚫ When the length of a queue reaches the maximum value, the device enabled with tail drop
discards all new packets buffered at the tail of the queue.

Problem
Undifferentiated drop

• Tail drop may cause a large amount of

non-key data to be forwarded and a large
Key Key Key Non-key Key amount of key data to be discarded.
Non-key Non-key
data data data data data • Cause:
data 4 data 3
7 6 5 2 1
 Tail drop cannot differentiate traffic.

All subsequent packets sent to the queue The queue is full.

will be discarded.

68 Huawei Confidential

• Tail drop cannot differentiate services and discard traffic in the same way.
 Policy 2: RED
⚫ Random early detection (RED) randomly discards data packets.

Drop probability
• Process:
No drop Random drop Tail drop 1. When the queue length is less than the lower
100% Drop probability curve threshold, no packets are discarded.

3 2. When the queue length is between the upper

Maximum threshold and the lower threshold, newly
drop
probability arrived packets are randomly discarded. The
longer the queue is, the higher the drop
2 probability is.
Actual
queue length 3. All coming packets are discarded if the queue
1 Lower Upper Maximum
threshold threshold queue length length is greater than the upper threshold.

69 Huawei Confidential

• RED defines upper and lower thresholds for the length of each queue:

▫ When the queue length is less than the lower threshold, no packets are
discarded.

▫ When the queue length is greater than the upper drop threshold, all
packets are discarded.

▫ Coming packets are dropped randomly if the queue length is between

upper and lower thresholds. RED generates a random number for each
incoming packet and compares it with the drop probability of the current
queue. If the random number is greater than the drop probability, the
packet is discarded. A longer queue indicates a higher drop probability.
 Relieving Global TCP Synchronization
⚫ RED randomly discards packets so that rates of TCP connections are reduced at different
times. This prevents global TCP synchronization.

Traffic

Maximum • Symptom:
value
Global TCP  Global TCP synchronization may still occur,
synchronization but the link usage is greatly increased.

• Disadvantage:
 RED cannot distinguish traffic.

Time

70 Huawei Confidential

• RED is used to avoid global TCP synchronization that occurs with tail drop. It
does this by randomly discarding packets so that the transmission speed of
multiple TCP connections is not reduced simultaneously. This results in more
stable rates of TCP traffic and other network traffic. — Do not adjust TCP sliding
window sizes simultaneously.
 Policy 3: WRED
⚫ Weighted Random Early Detection (WRED) sets different drop policies for data packets or
queues with different priorities to discard different types of traffic.

Drop • Example:
probability (%)
1. The lower threshold is 20 and the upper threshold
is 40 for the traffic whose IP precedence is 0.
100%
2. The lower threshold is 35 and the upper threshold
is 40 for the traffic whose IP precedence is 2. The
Maximum traffic whose IP precedence is 2 is discarded later
drop probability
than the traffic whose IP precedence is 0.
1 2
• Advantage:
Actual
queue 1. Do not adjust TCP sliding window sizes
20 30 35 40 length simultaneously to avoid global TCP
IP precedence used as an example: synchronization.
The corresponding precedences are Traffic 1
as follows: 0 1 2 Traffic 2
2. Different traffic is discarded based on weights.

Traffic 3

71 Huawei Confidential

• The device provides WRED based on RED technology.

• WRED discards packets in queues based on DSCP priorities or IP priorities. The

upper and lower thresholds, and drop probability can be set for each priority.
When the number of packets of a priority reaches the lower threshold, the device
starts to discard packets. When the number of packets reaches the upper
threshold, the device discards all the packets. As the queue length increases, the
packet loss rate increases. The maximum packet loss rate does not exceed the
preset packet loss rate. WRED discards packets in queues based on the drop
probability, thereby preventing congestion to a certain degree. — Do not adjust
TCP sliding window sizes simultaneously.
 WRED Drop Priority
Uplink direction
SFU Downlink direction
VLAN packet 802.1p Service class
MPLS packet MPLS EXP Mapping 802.1p
Color Service
IP packet DSCP class MPLS EXP
Mapping
Color
DSCP

Color Color/Drop Probability

Green
Priority in descending order
Service Class/Color
Example: AF AF41 AF42 AF43
Drop priority
AF41 AF42 AF43
of packets Lower threshold 70 50 30
AF31 AF32 AF33
on the device Yellow AF Upper threshold 80 60 40
AF21 AF22 AF23
AF11 AF12 AF13 Drop probability 70% 80% 90%

Red

72 Huawei Confidential

• Color：

▫ The color of packets determines the order in which packets are dropped in
a congested queue.

• Application:

▫ The WRED lower threshold is recommended to start from 50% and change
with the drop priority. The lowest drop probability and highest lower and
upper thresholds are recommended for green packets; a medium drop
probability and medium lower and upper thresholds are recommended for
yellow packets; the highest drop probability and smallest lower and upper
thresholds are recommended for red packets.

▫ When traffic congestion aggravates, red packets are first dropped due to
the smallest lower threshold and high drop probability. As the queue length
increases, the device drops green packets at last. If the queue length
reaches the upper threshold for red/yellow/green packets, red/yellow/green
packets start to be tail dropped.
 Curve of the WRED Drop Probability

Drop Differentiated drop

probability for different traffic
Color/Drop Probability
100%
Example: AF AF41 AF42 AF43
Red packet discard
Lower threshold 70 50 30 probability
Yellow packet
Upper threshold 80 60 40 discard probability
Green packet
Drop probability 70% 80% 90% discard probability

Actual
Red Red Yellow Yellow Green Green Maximum queue length
Lower Upper Upper Upper Upper Upper queue
threshold threshold threshold threshold threshold threshold length

73 Huawei Confidential

• Color：

▫ The color of packets determines the order in which packets are dropped in
a congested queue.

• Application:

▫ The WRED lower threshold is recommended to start from 50% and change
with the drop priority. The lowest drop probability and highest lower and
upper thresholds are recommended for green packets; a medium drop
probability and medium lower and upper thresholds are recommended for
yellow packets; the highest drop probability and smallest lower and upper
thresholds are recommended for red packets.

▫ When traffic congestion aggravates, red packets are first dropped due to
the smallest lower threshold and high drop probability. As the queue length
increases, the device drops green packets at last. If the queue length
reaches the upper threshold for red/yellow/green packets, red/yellow/green
packets start to be tail dropped.
 Application of Congestion Avoidance

Traffic direction

Configure congestion
avoidance
in the outbound
direction of the interface
Video flow Video

Voice flow Voice

Data flow
Data
LAN WAN LAN

74 Huawei Confidential

• Example:

▫ Users in different LANs may upload data to the same server, so data
exchanged between users and the server passes the WAN. Because WAN
bandwidth is lower than LAN bandwidth, congestion may occur on the
edge device between the WAN and LANs. Congestion avoidance can be
configured on the edge device to discard low-priority packets such as data
packets, reducing network overload and ensuring forwarding of high-
priority services.
Configuring Queue-based WRED
DS edge device DS node
system-view
drop-profile [drop-profile-name] //Create a drop profile.
DS domain wred [dscp | ip-precedence] //Configure a WRED drop
profile based on DSCP or IP priorities.
dscp [dscp-value] low-limit [low-limit-percentage] high-limit
[high-limit-percentage] discard-percentage [discard-percentage]
• The device supports WRED based on DSCP priorities or //Configure WRED parameters based on DSCP priorities.
IP priorities. The configuration roadmap is as follows: ip-precedence [ip-precedence-value] low-limit [low-limit-
percentage] high-limit [high-limit-percentage] discard-
▫ Configure a drop profile. percentage [discard-percentage] //(Optional) Configure WRED
parameters based on IP priorities.
▫ Configure WRED parameters. qos queue-profile [queue-profile-name] //Enter the queue
profile view.
▫ Reference the drop profile to a queue profile. queue [queue-index] drop-profile [drop-profile-name]
//Bind the drop profile to the specified queue in the queue profile.
▫ Apply the queue profile to the outbound direction of the interface [interface-type interface-num] //Enter the
interface. interface view.
qos queue-profile [queue-profile-name] //Apply the queue
profile to the interface.

75 Huawei Confidential
Configuring MQC to Implement Congestion Avoidance (1)
DS edge device DS node
system-view
drop-profile [drop-profile-name] //Create a drop profile.
DS domain wred [dscp | ip-precedence] //Configure a WRED drop
profile based on DSCP or IP priorities.
• After a drop profile is bound to a traffic behavior, dscp [dscp-value] low-limit [low-limit-percentage] high-limit
[high-limit-percentage] discard-percentage [discard-percentage]
associate the traffic behavior with the corresponding //Configure WRED parameters based on DSCP priorities.
traffic classifier in the traffic policy and apply the ip-precedence [ip-precedence-value] low-limit [low-limit-
percentage] high-limit [high-limit-percentage] discard-
traffic policy to an interface to implement percentage [discard-percentage] //(Optional) Configure WRED
congestion avoidance for traffic matching the traffic parameters based on IP priorities.

classifier. The configuration roadmap is as follows:

▫ Configure a drop profile.

▫ Configure a traffic classifier and a traffic behavior.

▫ Bind the traffic classifier and traffic behavior to a traffic

policy.

▫ Apply the traffic policy to the outbound direction of the

device interface.

76 Huawei Confidential
Configuring MQC to Implement Congestion Avoidance (2)
DS edge device DS node system-view
traffic classifier [classifier-name] //Create a traffic
classifier.
DS domain
if-match [acl | vlan-id | …. ] //Match traffic based on
• After a drop profile is bound to a traffic behavior, traffic characteristics.

associate the traffic behavior with the corresponding system-view

traffic behavior [behavior-name] //Create a traffic
traffic classifier in the traffic policy and apply the
behavior.
traffic policy to an interface to implement drop-profile [drop-profile-name] //Bind the created drop
profile to the traffic behavior.
congestion avoidance for traffic matching the traffic
classifier. The configuration roadmap is as follows: system-view
traffic policy [policy-name] //Create a traffic policy.
▫ Configure a drop profile. classifier [classifier-name] behavior [behavior-name]
//Bind the traffic classifier to the traffic behavior.
▫ Configure a traffic classifier and a traffic behavior.
system-view
▫ Bind the traffic classifier and traffic behavior to a traffic interface [interface-type interface-num] //Enter the
policy. interface view.
traffic-policy [policy-name] outbound //Apply the traffic
▫ Apply the traffic policy to the outbound direction of the policy to the outbound direction of the interface.
device interface.

77 Huawei Confidential
Checking the Congestion Avoidance Configuration
⚫ Checking the queue-based congestion avoidance configuration
system-view
interface [interface-type interface-num]
display this //Check the queue profile bound to the interface.
qos queue-profile [queue-profile-name]
display this //Check the drop profile bound to the queue profile.
display drop-profile [ drop-profile-name ] //Check the drop profile configuration.

⚫ Checking the MQC-based congestion avoidance configuration

system-view
display traffic classifier user-defined [ classifier-name ] //Check the traffic classifier configuration.
display traffic behavior [ system-defined | user-defined ] [ behavior-name ] //Check the traffic behavior configuration.
display traffic policy user-defined [ policy-name ] classifier [classifier-name ] //Check the traffic policy configuration.
display traffic-policy applied-record [ policy-name ] //Check the record of the specified traffic policy.

78 Huawei Confidential
 Quiz

1. (Multiple-answer question) Which of the following mechanisms are used by QoS

to proactively discard packets?( )
A. Tail drop

B. RED

C. MRED

D. WRED

79 Huawei Confidential

1. ABD
 Section Summary

⚫ Congestion avoidance technology cannot avoid congestion, but prevents

problems caused by congestion. For example, tail drop causes global TCP
synchronization, interface traffic is unstable, and UDP traffic preempts the
bandwidth used by TCP traffic.
⚫ RED/WRED randomly discards data packets to prevent problems such as
global TCP synchronization.

80 Huawei Confidential
 Contents

1. Introduction to QoS

2. Traffic Classification and Marking

3. Traffic Limiting Technology

4. Congestion Avoidance Technology

5. Congestion Management Technology

6. Introduction to HQoS

81 Huawei Confidential
 QoS Data Processing

Token

Video Queue 0

Outbound interface
Inbound interface

Queue 1

Scheduling
Other
Traffic Re-
Token CAR processing WRED GTS
classification marking Queue 2
…
bucket
Voice …

Queue N

Congestion management
Data

82 Huawei Confidential

• Congestion management: It is a measure that must be taken to solve the

problem of resource competition. Packets are buffered in queues and a
scheduling algorithm is used to determine the forwarding sequence of packets.
Congestion management is usually applied to the outbound direction of an
interface.
 Congestion Management Technology
⚫ Congestion management technology manages and controls different types of service traffic
when network congestion occurs.
⚫ It uses queue scheduling technology to handle traffic congestion.

Data sending queue Congestion

management
Queue 0

Queue 1
Scheduling

Queue 2 • Packets are scheduled based on the

… priority of each queue.

Queue N

83 Huawei Confidential

• Congestion Management Technology

• Congestion management defines a policy that determines the order in which

packets are forwarded and specifies drop principles for packets. The queuing
technology is used.

• The queue scheduling algorithm determines the order in which packets are
leaving a queue and the relationships between queues.

• Queuing technology

• Packets sent from one interface are placed into many queues which are identified
with different priorities. The packets are then sent based on the priorities.
Different queue scheduling mechanisms are designed for different situations and
lead to varying results.
 What Is a Queue?
⚫ The queuing technology orders packets in the buffer.

• Each interface has eight downlink queues, which are

Queue called class queues (CQs) or port queues.
• They are EF, AF1, AF2, AF3, AF4, BE, CS6, and CS7.

84 Huawei Confidential

• What is a queue?

▫ The queuing technology orders packets in the buffer. When the packet rate
exceeds the interface bandwidth or the bandwidth configured for packets,
the packets are buffered in queues and wait to be forwarded.

▫ Each interface on the NE20E or NE40E stores eight downlink queues, which
are called CQs or port queues. The eight queues are BE, AF1, AF2, AF3, AF4,
EF, CS6, and CS7.
 Queue Scheduling Algorithms
⚫ Congestion management uses the queuing technology.

1. First In First Out (FIFO)

Queue
scheduling 2. Strict Priority (SP)
algorithms 3. Weighted Fair Queuing (WFQ)

85 Huawei Confidential

• Queuing technology places packets sent from one interface into multiple queues
with different priorities. These packets are then sent based on the priorities.
Different queue scheduling mechanisms are designed for different situations and
lead to varying results.
 FIFO
⚫ The FIFO mechanism is used to transfer packets in a queue. Resources used to forward
packets are allocated based on the arrival order of packets.

FIFO FIFO
Enter a queue Leave a queue

Scheduling
FIFO
Packet 3 Packet 2 Packet 1 Queue Packet 3 Packet 2 Packet 1

86 Huawei Confidential

• FIFO does not classify packets.

• FIFO allows the packets that come earlier to enter the queue first. On the exit of
a queue, FIFO allows the packets to leave the queue in the same order as that in
which the packets enter the queue.

• Characteristics:

▫ Advantage: The implementation mechanism is simple and the processing

speed is fast.

▫ Disadvantage: Packets with different priorities cannot be processed in

differentiated ways.
 SP
⚫ SP schedules packets strictly based on queue priorities.

Packet 6 Packet 5 Packet 4 Packet 3 Packet 2 Packet 1

Classifica
tion
Enter a queue

High-priority queue Packet 6 Packet 2

Leave a

Scheduling
queue
Packet 1 Packet 5 Packet 4 Packet 3 Packet 6 Packet 2

SP
Medium-priority queue Packet 5 Packet 4 Packet 3

Low-priority queue Packet 1

87 Huawei Confidential

• SP: Packets in queues with a low priority can be scheduled only after all packets
in queues with a higher priority are scheduled.

• As shown in the figure, three queues with a high, medium, and low priorities
respectively are configured with SP scheduling. The number indicates the order in
which packets arrive.

• When packets leave queues, the device forwards the packets in descending order
of priority. Packets in the higher-priority queue are forwarded preferentially. If
packets in the higher-priority queue come in between packets in the lower-
priority queue that is being scheduled, the packets in the high-priority queue are
still scheduled preferentially. This implementation ensures that packets in the
higher-priority queue are always forwarded preferentially. As long as there are
packets in the high-priority queue, no other queue will be served.

• Characteristics:

▫ Advantage: High-priority packets are preferentially forwarded.

▫ Disadvantage: Low-priority queues may be starved out. That is, when

congestion occurs, packets in lower-priority queues are not processed until
all the higher-priority queues are empty. As a result, a congested higher-
priority queue causes all lower-priority queues to starve out.
 WFQ
⚫ WFQ allocates outbound bandwidth to flows on an interface based on weights of queues.

Packet 6 Packet 5 Packet 4 Packet 3 Packet 2 Packet 1

Classific
ation
Enter a queue

High-priority queue: 50% 4-bit packet

Leave a
Bit-by-bit

Scheduling
queue

WFQ
Medium-priority queue: 25% 6-bit packet

Packet assembly
Low-priority queue: 25% 8-bit packet

8-bit packet 6-bit packet 4-bit packet

Leaving packet

88 Huawei Confidential

• WFQ allocates bandwidths to flows based on weights of queues. In addition, to

fairly allocate bandwidths to flows, WFQ schedules packets bit by bit.
• Characteristics:
▫ Advantages:

▪ Packets in different queues are scheduled fairly, and the flow delays
have slight differences.

▪ If many large and small packets in different queues need to be sent,

small packets are scheduled first, reducing the total jitter of each
flow.

▪ The smaller the weight, the less the allocated bandwidth. Flows with
larger weights are allocated higher bandwidth.

▫ Disadvantage: Low-latency services cannot be scheduled in a timely

manner. User-defined classification rules cannot be implemented.
 Queue Scheduling Mode of an Interface
⚫ You can configure SP scheduling or WFQ scheduling for eight queues on an interface.
⚫ Eight queues can be classified into three groups, priority queuing (PQ) queues, WFQ queues,
and low priority queuing (LPQ) queues, based on scheduling algorithms.

Eight interface 1. PQ queue: uses the SP scheduling algorithm.

queues
are classified into 2. WFQ queue: uses the WFQ scheduling algorithm.
three groups 3. LPQ queue: uses the SP scheduling algorithm.

90 Huawei Confidential

• PQ queue
▫ SP scheduling applies to PQ queues. Packets in high-priority queues are
scheduled preferentially. Therefore, services that are sensitive to delays
(such as VoIP) can be configured with high priorities.

▫ In PQ queues, however, if the bandwidth of high-priority packets is not

restricted, low-priority packets cannot obtain bandwidth and are starved
out.

▫ Generally, services that are sensitive to delays are put into PQ queues.
• WFQ queue
▫ WFQ queues are scheduled based on weights. The WFQ scheduling
algorithm can be used to allocate the remaining bandwidth based on
weights.
• LPQ queue
▫ LPQ is a queue scheduling mechanism that is implemented on a high-speed
interface (such as an Ethernet interface). LPQ is not supported on a low-
speed interface (such as a serial interface or MP-group interface).

▫ SP scheduling applies to LPQ queues. The difference is that when

congestion occurs, the PQ queue can preempt the bandwidth of the WFQ
queue whereas the LPQ queue cannot. After packets in the PQ and WFQ
queues are all scheduled, the remaining bandwidth can be assigned to
packets in the LPQ queue.
 Scheduling Order of Three Types of Queues
Interface queue scheduling order Interface queue scheduling process

Queue 1
SP Start
PQ ……
scheduling
queue
Queue m
Is the PQ No Perform a round of
queue empty? PQ scheduling

Destination
Queue 1

interface
Yes
WFQ SP
WFQ …
scheduling scheduling
queue No
Is the WFQ Perform a round of
Queue i queue empty? WFQ scheduling

Yes

Queue 1 Is the LPQ No Perform a round of

queue empty? LPQ scheduling
LPQ … SP
queue scheduling
Yes
Queue k

92 Huawei Confidential

• Interface queue scheduling order:

▫ If PQ, WFQ, and LPQ queues use SP scheduling. PQ, WFQ, and LPQ queues
are scheduled in sequence.

• Interface queue scheduling process:

▫ Packets in PQ queues are preferentially scheduled, and packets in WFQ

queues are scheduled only when no packets are buffered in PQ queues.
When all PQ queues are empty, WFQ queues start to be scheduled. Packets
in PQ queues are preferentially scheduled,

▫ and packets in WFQ queues are scheduled only when no packets are
buffered in PQ queues. Bandwidths are preferentially allocated to PQ
queues to guarantee the PIR of packets in PQ queues.

▫ Packets in LPQ queues are scheduled only after all packets in WFQ queues
are sent.

• Scheduling result:

▫ The PIR of PQ queues is guaranteed first, and the remaining bandwidth is

allocated among WFQ queues based on weights.

▫ When the PIR of all WFQ queues is guaranteed, the remaining bandwidth is
allocated to LPQ queues.
 Application of Congestion Management

Traffic direction

Configure congestion
management
in the outbound
direction of the
interface
Video flow Video

Voice flow Voice

Data flow Data

93 Huawei Confidential

• Example:

▫ On a network, when multiple services compete for the same resources

(such as the bandwidth and buffer), traffic congestion may occur and high-
priority services may be not processed in a timely manner. Packets can be
sent to different queues according to the priority mapping result, as shown
in the figure. Different scheduling modes are set in the outbound direction
to implement differentiated services.
QoS Processing Review

Token

Video
Queue 0
Inbound interface

Outbound interface
Queue 1

Scheduling
Other
Traffic Re-
Token CAR processing WRED GTS
classification marking Queue 2
bucket …
Voice …
Congestion Traffic
Traffic policing
avoidance shaping
Queue N

Congestion management

Data

94 Huawei Confidential
Configuring Queue-based Congestion Management
DS edge device DS node system-view
qos queue-profile [queue-profile-name] //Create a queue
DS domain profile.
schedule pq [queue-index] | wfq [queue-index] //Configure
scheduling modes for queues on a WAN interface.
• WAN interfaces support three scheduling interface [interface-type interface-num] //Enter the
interface view.
modes: PQ, WFQ, and PQ+WFQ. The qos queue-profile [queue-profile-name] //Apply the queue
profile to the interface.
configuration roadmap is as follows:
▫ Create a queue profile.

▫ Configure scheduling modes.

▫ Apply the queue profile to the interface.

95 Huawei Confidential
 Configuring MQC to Implement Congestion Management
(1)
DS edge device DS node system-view
traffic classifier [classifier-name] //Create a traffic
classifier.
DS domain if-match [acl | vlan-id | …. ] //Match traffic based on
• MQC provides three types of queues: traffic characteristics.

▫ Assured Forwarding (AF) queues system-view

traffic behavior [behavior-name] //Create a traffic
▫ Expedited Forwarding (EF) or LLQ queues behavior.
queue af bandwidth [bandwidth | pct percentage]
▫ BE queues //Configure the minimum bandwidth for AF queues in the traffic
behavior.
• The configuration roadmap is as follows: queue ef bandwidth [bandwidth | pct percentage]
//Configure the minimum bandwidth for EF queues in the traffic
▫ Configure a traffic classifier and a traffic behavior.
behavior.
▫ Bind the traffic classifier and traffic behavior to a traffic queue llq bandwidth [bandwidth | pct percentage]
//Configure the maximum bandwidth for LLQ queues in the traffic
policy. behavior.
queue wfq queue-number [total-queue-number]
▫ Apply the traffic policy to the outbound direction of the //Configure WFQ scheduling parameters for BE queues in the
device interface. traffic behavior.

96 Huawei Confidential

• AF queue: AF queues ensure that service traffic is forwarded when the traffic rate
does not exceed the minimum bandwidth.

• EF/LLQ queue: After packets matching certain rules enter EF or LLQ queues, they
are scheduled in SP mode. Packets in other queues are scheduled only after all
the packets in EF or LLQ queues are scheduled. In addition, EF queues can use
the available bandwidth in AF or BE queues. The latency of LLQ queues is lower
than that of common EF queues.

• BE queue: The remaining packets that do not enter AF or EF queues enter BE

queues. BE queues are scheduled using the WFQ algorithm.

• The total bandwidth used by AF queues and EF queues cannot exceed 100% of
the interface bandwidth.

• EF queues are provided with bandwidth preferentially. AF queues share the

remaining bandwidth based on their weights.
 Configuring MQC to Implement Congestion Management
(2)
DS edge device DS node system-view
traffic policy [policy-name] //Create a traffic policy.
classifier [classifier-name] behavior [behavior-name]
DS domain
//Bind the traffic classifier to the traffic behavior.
• MQC provides three types of queues:
▫ AF queues system-view
interface [interface-type interface-num] //Enter the
▫ EF/LLQ queues interface view.
traffic-policy [policy-name] outbound //Apply the traffic
▫ BE queues policy to the outbound direction of the interface.

• The configuration roadmap is as follows:

▫ Configure a traffic classifier and a traffic behavior.

▫ Bind the traffic classifier and traffic behavior to a traffic

policy.

▫ Apply the traffic policy to the outbound direction of the

device interface.

97 Huawei Confidential

• AF queue: AF queues ensure that service traffic is forwarded when the traffic rate
does not exceed the minimum bandwidth.

• EF/LLQ queue: After packets matching certain rules enter EF or LLQ queues, they
are scheduled in SP mode. Packets in other queues are scheduled only after all
the packets in EF or LLQ queues are scheduled. In addition, EF queues can use
the available bandwidth in AF or BE queues. The latency of LLQ queues is lower
than that of common EF queues.

• BE queue: The remaining packets that do not enter AF or EF queues enter BE

queues. BE queues are scheduled using the WFQ algorithm.

• The total bandwidth used by AF queues and EF queues cannot exceed 100% of
the interface bandwidth.

• EF queues are provided with bandwidth preferentially. AF queues share the

remaining bandwidth based on their weights.
Checking the Congestion Management Configuration
⚫ Checking the queue-based congestion management configuration
system-view
interface [interface-type interface-num]
display this //Check the queue profile bound to the interface.
display qos queue-profile [queue-profile-name] //Check the queue profile configuration.

⚫ Checking the traffic classifier-based congestion management configuration

system-view
display traffic classifier user-defined [ classifier-name ] //Check the traffic classifier configuration.
display traffic behavior [ system-defined | user-defined ] [ behavior-name ] //Check the traffic behavior
configuration.
display traffic policy user-defined [ policy-name ] classifier [classifier-name ] //Check the traffic policy
configuration.
display traffic-policy applied-record [ policy-name ] //Check the record of the specified traffic policy.

98 Huawei Confidential
 Quiz
1. (Single-answer question) How many queues are there on an interface?( )
A. 6
B. 7
C. 8
D. 9

2. (Multiple-answer question) Which of the following is a queue scheduling technology?( )

A. PQ
B. WFQ
C. WRED
D. FIFO

99 Huawei Confidential

1. C

2. ABD
 Section Summary

⚫ After a data packet enters a queue, the device sends the data packet
according to the queue scheduling mechanism.
⚫ Common queue scheduling technologies include FIFO, PQ, and WFQ.
⚫ PQ scheduling is performed before WFQ scheduling and FIFO. Queues
scheduled in WFQ mode can transmit data only when queues scheduled in
PQ mode have no data to transmit. The queue scheduled in FIFO mode can
transmit data only when queues scheduled in PQ and WFQ mode have no
data to transmit.

100 Huawei Confidential

 Contents

1. Introduction to QoS

2. Traffic Classification and Marking

3. Traffic Limiting Technology

4. Congestion Avoidance Technology

5. Congestion Management Technology

6. Introduction to HQoS

101 Huawei Confidential

Limitations of QoS
⚫ Traditional QoS distributes a flow into only eight queues for scheduling and control. Therefore, it has great limitations in multi-
tenant scenarios.
QoS limitations in home broadband scenarios

14 households rent
different bandwidths
and services.

Internet

User-based QoS cannot

be implemented on the
egress. Only eight
queues can be used to
differentiate traffic.

• In home broadband scenarios, different families may rent different network bandwidths and network services.
Therefore, QoS cannot manage these families in a refined manner.

102 Huawei Confidential

HQoS Overview
⚫ Traditional QoS schedules traffic based on interfaces. An interface can only differentiate service
priorities. The traffic of the same priority uses the same interface queue and competes for the same
queue resources. Therefore, traditional QoS technology cannot provide differentiated services based on
types of traffic and users.
⚫ HQoS meets this requirement by implementing hierarchical scheduling based on multiple levels of
queues, differentiating both services and users to provide refined QoS guarantee.
⚫ Different devices provide different HQoS features. This section describes HQoS features supported by
the CPE (AR series router).

103 Huawei Confidential

 Introduction to HQoS Queues
⚫ The CPE supports three-level queues: flow queue (level 3), subscriber queue (level 2), and port queue
(level 1).

Voice flow Level 3 flow queue

Level 2 subscriber queue

…
Video flow Level 3 flow queue
Tenant 1
Sub-
interface

…
Level 1 port queue
and
tunnel
Internet interface
access traffic Physical

…
interface
Gaming flow
Tenant 2
…

Video flow

Other traffic
Tenant N

104 Huawei Confidential

• Flow queue

▫ The same type of services of a user is taken as a service flow. HQoS

schedules queues based on service flows. Flow queues correspond to service
types and are classified into EF, AF, and BE queues. You can set scheduling
modes for flow queues.

• Subscriber queue

▫ Services from a user are placed into a subscriber queue. HQoS allows all
services in the subscriber queue to share the bandwidth.

• Port queue

▫ Each port corresponds to a queue and port queues are scheduled in RR

mode. You can configure only interface-based traffic shaping, but cannot
configure scheduling modes.
 Introduction to HQoS Queue Scheduling
⚫ The flow queue and subscriber queue support PQ scheduling, WFQ scheduling, and PQ+WFQ
scheduling. The port queue uses RR scheduling.
HQoS queue scheduling

PQ/WFQ
…

Level 2 subscriber
queue Level 1 port queue

PQ/WFQ
Level 3 flow
…

...
queue

RR
...
PQ/WFQ
…

105 Huawei Confidential

• HQoS deployment for enterprise users is used as an example. Enterprise users

have VoIP, video conference, and data services. Each subscriber queue
corresponds to one enterprise user and each flow queue corresponds to a type of
services. By deploying HQoS, the device can control the following items:

▫ Traffic scheduling among three types of services of a single enterprise user

▫ Total bandwidth of three types of services of a single enterprise user

▫ Bandwidth allocation between multiple enterprise users

▫ Total bandwidth of multiple enterprise users

Introduction to HQoS Traffic Shaping
⚫ The HQoS shaper buffers packets and limits the rate of packets. The device supports three levels of
shapers, that is, flow queue shaper, subscriber queue shaper, and port queue shaper. After packets
enter the device, the device buffers the packets in queues and sends the packets at the limited rate.
Shapers can ensure the CIR and limit the maximum rate of packets by using the rate limiting
algorithm.
Level 3 flow queue shaping Level 2 subscriber queue Level 1 port queue shaping
shaping
…

Data from multiple Data from multiple

flow queues is subscriber queues is
buffered in a buffered in a port
subscriber queue and queue and waits to be
Data is buffered in
waits to be sent. sent.
a flow queue and
waits to be sent.

106 Huawei Confidential

Introduction to the HQoS Dropper
⚫ The HQoS dropper discards packets based on a drop policy before packets are sent to queues.
⚫ The three types of queues supported by HQoS support different drop modes. The port queue and
subscriber queue support tail drop; the flow queue supports tail drop and WRED.

Level 3 flow queue Level 2 subscriber Level 1 port queue

queue

WRED or … Tail Tail

tail drop drop drop

Discard
packets Discard packets based
Discard packets based
based on on drop policies
on drop policies
drop
policies

107 Huawei Confidential

HQoS Application Example
⚫ Assume that there are three families in a building. Family A purchases 10 Mbit/s bandwidth and enables the VoIP,
IPTV, and High Speed Internet (HSI) services. Family B purchases 20 Mbit/s bandwidth and enables the IPTV and
HSI services. Family C purchases 30 Mbit/s bandwidth and enables only the HSI service. HQoS can meet these
requirements.
HQoS deployment solution

VoIP (PQ scheduling)

Family A Total bandwidth of
IPTV (PQ scheduling)
family A (10 Mbit/s)

HSI (WFQ scheduling)

Level 1 port queue
IPTV (PQ scheduling)
Total bandwidth of Total bandwidth of the

WFQ
family B (20 Mbit/s) building (60 Mbit/s)
Family B Deploy HSI (WFQ scheduling)
HQoS at Level 2 subscriber queue
the egress Level 3 flow queue

Total bandwidth of
HSI (WFQ scheduling) family C (30 Mbit/s)
Family C

108 Huawei Confidential

HQoS Configuration Roadmap
⚫ The HQoS configuration is complex. Generally, the MQC mode is used.
⚫ When HQoS is configured, the policy nesting mode is used.
 The parent traffic policy differentiates users, and the child traffic policy differentiates traffic.
 A parent traffic policy can have multiple child traffic policies.
 A parent traffic policy applies to an interface.

Level 3 flow queue Level 2 subscriber queue Level 1 port queue

Child traffic policy Parent traffic policy Interface or sub-interface queue

109 Huawei Confidential

Configuring a Child Traffic Policy
system-view
traffic classifier [classifier-name] //Create a traffic
Internet classifier.
if-match [acl | vlan-id | …. ] //Match traffic based on
service characteristics.

system-view
traffic behavior [behavior-name] //Create a traffic
• Child traffic policies are used to differentiate services. You can behavior.
configure multiple child traffic policies based on services when queue [af | ef | llq] bandwidth [bandwidth | pct percentage]
//Configure AF, EF, or LLQ queue parameters in the traffic
configuring HQoS. behavior.
drop-profile [drop-profile-name] //Bind the created drop
• The configuration of HQoS child traffic policies is the same as
profile to the traffic behavior.
that of common MQC. The configuration roadmap is as follows:
system-view
▫ Configure a traffic classifier where traffic is matched based on service
traffic policy [policy-name] //Create a traffic policy.
characteristics. classifier [classifier-name] behavior [behavior-name]
▫ Configure a traffic behavior where the queue scheduling mode and
//Bind the traffic classifier to the traffic behavior.
queue bandwidth are defined.

▫ Bind the traffic classifier and traffic behavior to a traffic policy.

110 Huawei Confidential

Configuring a Parent Traffic Policy
system-view
traffic classifier [classifier-name] //Create a traffic
Internet classifier.
if-match [acl | vlan-id | …. ] //Match traffic based on user
characteristics.

system-view
• A parent traffic policy is used to differentiate users. When traffic behavior [behavior-name] //Create a traffic
behavior.
configuring HQoS, you can bind multiple child traffic policies queue [af | ef | llq] bandwidth [bandwidth | pct percentage]
to a parent traffic policy. //(Optional) Configure AF, EF, or LLQ queue parameters in the
traffic behavior.
• The configuration roadmap is as follows: traffic-policy [policy-name] //Bind the sub traffic policy to
the traffic behavior.
▫ Configure a traffic classifier to match traffic based on user
characteristics.
system-view
▫ Configure a traffic behavior that needs to invoke a child traffic policy. traffic policy [policy-name] //Create a parent traffic policy.
▫ Bind the traffic classifier and traffic behavior to a traffic policy. classifier [classifier-name] behavior [behavior-name]
//Bind the traffic classifier to the traffic behavior.

111 Huawei Confidential

Applying the Parent Traffic Policy
system-view
interface [interface-type interface-num] //Enter the
Internet interface view.
traffic-policy [policy-name] outbound //Apply the parent
traffic policy to the outbound direction of the interface.

• After configuring a parent traffic policy, bind it to an interface or

sub-interface.

• If the parent traffic policy is bond to a sub-interface, traffic

between different sub-interfaces is sent from the physical
interface in polling mode.

• The configuration roadmap is as follows:

▫ Apply the parent traffic policy to the outbound direction of the interface.

112 Huawei Confidential

Checking the HQoS Configuration
⚫ After configuring HQoS, you can run the following commands to check the configuration.

system-view
display traffic classifier user-defined [ classifier-name ] //Check the traffic classifier configuration.
display traffic behavior [ system-defined | user-defined ] [ behavior-name ] //Check the traffic behavior configuration.
display traffic policy user-defined [ policy-name ] classifier [classifier-name ] //Check the traffic policy configuration.
display traffic-policy applied-record [ policy-name ] //Check the record of the specified traffic policy.

113 Huawei Confidential

 Quiz

1. (True or false) HQoS cannot distinguish users or services.( )

A. True

B. False

2. (Multiple-answer question) What are three types of HQoS queues?( )

A. Flow queue

B. Subscriber queue

C. Data queue

D. Port queue

114 Huawei Confidential

1. B

2. ABD
 Section Summary

⚫ HQoS can ensure services with finer granularities.

⚫ HQoS has three levels of queues: flow queue, subscriber queue, and port
queue. Traffic shaping can be deployed for the three types of queues. Flow
queues are scheduled in PQ+WFQ mode, subscriber queues are scheduled
in PQ+WFQ mode, and interface queues are scheduled in RR mode.

115 Huawei Confidential

 Summary

⚫ QoS is an important means to ensure service quality. Generally, the

DiffServ model is used on the live network.
⚫ This model uses rate limiting, congestion avoidance, and congestion
management.
⚫ HQoS is used in complex scenarios with finer granularity. Flow queues,
subscriber queues, and port queues can be used to distinguish different
users and different services of the same user.

116 Huawei Confidential

Thank you. 把数字世界带入每个人、每个家庭、
每个组织，构建万物互联的智能世界。
Bring digital to every person, home, and
organization for a fully connected,
intelligent world.

Copyright©2021 Huawei Technologies Co., Ltd.

All Rights Reserved.

The information in this document may contain predictive

statements including, without limitation, statements regarding
the future financial and operating results, future product
portfolio, new technology, etc. There are a number of factors that
could cause actual results and developments to differ materially
from those expressed or implied in the predictive statements.
Therefore, such information is provided for reference purpose
only and constitutes neither an offer nor an acceptance. Huawei
may change the information at any time without notice.
• Maintenance is also called "O&M", "operation", or "operation and maintenance."

• Network planning is the starting point of a project. Complete and detailed

planning will lay a solid foundation for subsequent project implementation.
Specific tasks in network planning are as follows:

▫ In the project planning phase, investigate and understand the project

background. Properly prepare for project implementation, which ensures
the smooth progress of the project.

▫ In the project planning phase, the implementation scope of the network

project must be specified.

▫ Draw up the project budget based on the project objective, project scope,
and work content.

▫ In the project planning phase, the network design guidelines must be

specified to provide guidance and basis for subsequent network design.
• A proper running environment is the prerequisite for the proper running of a
device.

• Temperature and humidity easily affect the proper running of devices. Standard
equipment rooms should be equipped with thermometers and hygrometers, and
check and record of the temperature and humidity should be performed on a
daily basis.

• The cleanness and neatness of the equipment room also affect the proper
running of the equipment.

▫ Cleanness affects heat dissipation.

▫ Tidiness refers to the proper layout of devices and cables. Devices must be
installed and cables must be routed according to installation and
deployment requirements. However, during network operation, temporary
adjustments, such as temporary jumper tests, are often made. After such
activities are taken for a period of time, the equipment room becomes
disordered. The purpose of checking the equipment environment is to find
out and rectify these problems in time.

• For nonstandard equipment rooms, checking the equipment environment more

carefully. For example, check the cleanness and heat dissipation of equipment
rooms on floors.

• The preceding check items may vary according to devices. For details, see the
product documentation of each type of device.
• Software version running on a device:

▫ The running software version of a device should be confirmed in project

implementation. In normal cases, the version information does not change.
Pay attention to any change in version information. This situation is usually
caused by nonstandard management.

▫ If a device is newly added, the software version may be different from the
existing software version. Some devices may be upgraded or downgraded
due to other reasons. Especially on a large-scale network, the same type of
device may run different versions. In this case, verify that different versions
can meet the same network function requirements.

• Startup information:

▫ Multiple software packages of different versions or configuration files may

be stored on a device. In this case, changing startup information may cause
great risks to the proper running of the network. Once the device is
restarted (for example, if power supply is faulty), the running of the entire
network may be adversely affected.

• License information:

▫ License rules vary according to devices. The licenses of some devices have
validity periods.
• You can configure information output rules as needed to control the output of
various types and levels of information along information channels in different
output directions.

• A remote terminal is used to log in to a device through a VTY interface to receive

logs, traps, and debugging information, facilitating remote maintenance.
• Enable a device to send information to a log host.

▫ [HUAWEI] info-center loghost ip-address { source-ip source-ip-address } |

transport { udp | tcp ssl-policy policy-name } ]
• To facilitate display, the debugging information displayed on this page is
adjusted.

• The content of the Hello packet sent by R1 through GE 0/0/0 is as follows:

<R1>

YY-MM-DD10:14:21.751.1-08:00 R1 RM/6/RMDEBUG:

FileID: 0xd0178025 Line: 559 Level: 0x20

OSPF 1: SEND Packet. Interface: GigabitEthernet0/0/0

<R1>YY-MM-DD 10:14:21.751.2-08:00 R1 RM/6/RMDEBUG: Source Address:

10.0.12.1

<R1>YY-MM-DD 10:14:21.751.3-08:00 R1 RM/6/RMDEBUG: Destination

Address: 224.0.0.5

<R1>YY-MM-DD 10:14:21.751.4-08:00 R1 RM/6/RMDEBUG: Ver# 2, Type: 1

(Hello)

<R1>YY-MM-DD 10:14:21.751.5-08:00 R1 RM/6/RMDEBUG: Length: 48,

Router: 10.0.12.1

<R1>YY-MM-DD10:14:21.751.6-08:00 R1 RM/6/RMDEBUG: Area: 0.0.0.0,

Chksum: ae94

<R1>YY-MM-DD 10:14:21.751.7-08:00 R1 RM/6/RMDEBUG: AuType: 00

<R1>YY-MM-DD10:14:21.751.8-08:00 R1 RM/6/RMDEBUG: Key(ascii): * * * * * *

**
• Only one packet information obtaining instance can run at a time. That is, if a
previous process is not complete, a next process cannot be started.

• The rate of packets whose information is to be obtained is limited. If burst traffic

exceeds the rate limit configured for obtained packet information, packet loss
may occur.

• The capture-packet command obtains header information in the service packets

that match the configured rules and sends the obtained information to the
terminal for display or saves the obtained information on a local device.

▫ capture-packet interface interface-type interface-number [ acl acl-number ]

destination { terminal | file file-name } * [ car cir car-value | time-out time |
packet-num number | packet-len { length | total-packet } ] *

▪ terminal: sends the obtained information to the terminal for display.

▪ file file-name: saves the obtained information in a specified file.

1. ABD
1. B

2. B
• Mapping between the preceding fault symptoms and categories varies according
to scenarios.
• If an unstructured network troubleshooting is carried out, steps are performed
repeatedly, leading to low efficiency even though a solution to the fault is found.

• In a complex network environment, a new fault may be caused due to an

unstructured network fault rectification process, making network fault
rectification more difficult.
• Why do we need to know the positions and work content of users?

▫ In an enterprise environment, network access permissions to be granted

vary according to positions. Even users of the same position may have only
the permission to use network services related to their work content.
• Why do we need to confirm a fault?

▫ The user description may be ambiguous, and the reported fault may not be
the actual faulty point. In this situation, experienced engineers have to
confirm the fault.
• A temporary network environment may need to be built for fault evaluation.

▫ If a complex network fault cannot be rectified within a short period of time

after being evaluated and a user wants to immediately restore network
availability, you advise the user to temporarily skip the faulty node and
build an alternative network environment.

▫ When building a temporary network environment, fully consider the

urgency of solving problems and the risk of bypassing certain security
restrictions. Fully communicate with users and implement the environment
only after obtaining permissions.
1. ABC

2. False
• R3 and SW5 are connected through Layer 3 sub-interfaces.
• This section describes common troubleshooting methods and tools, providing
guidance for network maintenance personnel. The processing sequence in actual
scenarios can be different from that in the example.
• This section uses the Windows 10 OS as an example to describe how to check the
physical connection status of a PC.

• InUti: input bandwidth utilization

• OutUti: output bandwidth utilization

• GE 0/0/10 belongs to VLAN 12 and VLAN 34 and works in tagged mode,
indicating that the interface is configured as a trunk interface and the PVID is not
12.
• A Layer 2 loop causes the following failures:

▫ An attempt to remotely log in to a device fails.

▫ An interface receives a large number of broadcast packets, which can be

viewed in the display interface command output.

▫ An attempt to log in to a device through the serial port is time consuming.

▫ CPU usage exceeds 70%.

▫ High packet loss occurs when a ping command is used.

▫ The indicator of the VLAN interface with the loop occurring frequently
blinks.

▫ A PC receives a large number of broadcast packets.

▫ A loop alarm is generated if loop detection is configured on a switch.

• After receiving STP TC BPDUs, the STP-enabled switch clears the MAC address
table and re-learns MAC addresses. During this period, data forwarding is
interrupted for a short period, causing packet loss.
• The capture-packet command obtains information in service packets that match
a configured rule. The obtained information is saved in a local file.

▫ capture-packet { interface interface-type interface-number | acl acl-

number } * [ vlan vlan-id | cvlan cvlan-id ] * destination terminal [ car cir
car-value | time-out time-out-value | packet-num number | packet-len
length ] *
▫ Information in packets on the management interface cannot be obtained.

▫ This command can only obtain information received by an interface, not

information sent by an interface.
• The VRRP group numbers on SW3 and SW4 are different. After the VRRP group
on SW3 detects a downlink fault, the VRRP status on SW4 does not change. The
VRRP status on SW4 remains in the Master state. In this situation, sending
gratuitous ARP messages is not triggered for an ARP entry update on the
terminal.

• The destination MAC address of data frames sent from PC1 to a gateway is still
00 00 5e 00 01 03.

• After the link between SW1 and SW3 is disconnected, SW1 cannot forward
packets to SW2, because SW1 does not have the MAC address entry of 00 00 5e
00 01 03.
• The debugging information on R1 shows that the OSPF router ID carried in the
Hello packets sent from 10.0.12.2 is the same as the OSPF router ID on R1.
• On R3, the command output shows that the route to 192.168.56.0/24 has been
imported into the BGP routing table.
• Possible causes for the failure to establish an IS-IS neighbor relationship are as
follows:

▫ Area IDs do not match on both ends. (The inconsistency adversely affects
only level-1 neighbor relationships.)

▫ IS-IS levels do not match on both ends. (Note that on Huawei devices if the
system level differs from the interface circuit level, the system level takes
effect.)

▫ Interface authentication settings do not match on both ends.

▫ System ID lengths do not match or system ID conflict occurs.

▫ The IP addresses are on different network segments. (Source check is

enabled for IS-IS on a broadcast network, and can be disabled.)
• After the configuration of R2 is modified, the route to 10.0.3.3/32 is displayed on
R1.
• After R1 learns the route, PC1 still cannot access the FTP service provided by
server 6. In this case, run the traceroute command to check connectivity between
R1 and server 6.
• Based on traffic statistics, the analysis is as follows:
▫ Check whether the traffic reaches the inbound interface of the device and
determine whether packet loss occurs on the upstream device.
▫ Check whether the traffic is forwarded to the outbound of the device and
determine whether packet loss occurs on the device.
▫ Check whether Layer 2 and Layer 3 information about traffic on the
inbound interface of the device is correct and determine whether the
upstream device forwards and encapsulates packets properly.
▫ Check whether the Layer 2 and Layer 3 information about the outbound
interface is correct and determine whether the device forwards and
encapsulates packets properly.
▫ Check whether transient traffic flapping occurs due to MAC address
flapping, route changes, or IP address conflicts.
• Procedure for configuring traffic statistics collection:
▫ Configure an ACL rule to match traffic to be collected.
▫ Configure a traffic classifier.
▫ Configure a traffic behavior and configure traffic statistics collection in the
traffic behavior.
▫ Configure a traffic policy; bind the traffic classifier and behavior to the
traffic policy; apply the traffic policy to the inbound direction of the switch
to collect statistics on packets of different users.
• If the client and server are on different network segments and a relay agent is
deployed between them

▫ The link between the DHCP relay agent and server becomes faulty.

▫ The DHCP function is not enabled globally on a device. As a result, the

DHCP function does not take effect.

▫ No DHCP server is specified on the DHCP relay agent.

▫ The DHCP relay agent and server are unreachable.

1. ABC

2. B

3. ABCD
• The optical distribution frame (ODF) is mainly used on backbone networks,
metropolitan area networks (MANs), and optical fiber and cable networks. It
connects, terminates, distributes, splits, and schedules backbone optical cables.
• Time arrangement preparation:

▫ Negotiate the time arrangement with the customer and obtain customer's
approval.

▫ Make an overall time schedule.

▫ Specify actions to be performed in each time segment.

▫ In the migration phase, time arrangement should be accurate to minutes.

▫ Reserve some time for major operations to avoid engineering accidents due
to timeout.

▫ Do not perform migration in peak hours (such as holidays and off-duty

time).
• Type A service: service demanding low latency and bandwidth. These services are
carried over leased lines.

• Type B service: service that has low requirements on the latency but occupies
much bandwidth. These services are carried over IPsec VPNs.

• Static return routes are manually specified for the headquarters, and NQA is used
to switch services to the standby path upon faults. This case focuses on the
branch network and does not involve the headquarters network.
1. We can set up a local pilot office and simulate the customer's network to verify
the feasibility of the entire migration solution.

2. The configuration of the live network needs to be backed up. To verify the
network status before and after the migration, collect dynamic data of the live
network, including the port status, traffic, status of each routing protocol,
number of routes, STP status, and ARP/MAC address entries of each port.
• DCNs do not have a fixed zone division mode. Different industries and enterprises
have different area division modes.

• The zone division in the slide uses the financial industry as an example:

▫ WAN access zone: connects to the WAN built by the enterprise.

▫ Campus access zone: accesses traffic from enterprise campus users.

▫ Extranet access zone: connects to external networks, such as networks of

other enterprises and partners.

▫ Internet access zone: accesses user traffic from the Internet.

▫ Production environment zone: runs services.

▫ Test environment zone: provides services for external systems informally.

Before a service is brought online to the production environment zone, the
service is developed, tested, and verified in the test environment zone.
• Different network security solutions can be used to cope with different network
security problems.

▫ Deploying firewalls in the server area of a data center: implements security

isolation, access control, and intrusion prevention between servers and VMs
in the data center.

▫ Deploying Web Application Firewalls (WAFs) in the server area of a data

center: protects website servers and prevents website text and images from
being tampered with.

▫ Deploying anti-DDoS abnormal traffic detecting and cleaning devices:

mitigates various DDoS attacks from the Internet.

▫ Deploying egress firewalls: performs security protection, such as NAT,

application protocol identification and control, security isolation, and access
control, to prevent unauthorized access.

▫ Implementing O&M auditing in the management area: centrally manages

and controls accounts, authentication, authorization, and audit of various IT
resources such as core service systems, hosts, databases, and network
devices to comply with related laws and standards and implement unified
access management and O&M audit of core resources.
• China Education and Research Network (CERNET): a nationwide education and
research computer network that is funded by the Chinese government and
directly managed by the Chinese Ministry of Education. It is constructed and
operated by Tsinghua University and the other leading Chinese universities.
• Generally, the regional nodes of the backbone network are deployed in the
equipment rooms of each railway bureau.

• GSM-R: Global System for Mobile Communications - Railway

• CTC: Centralized Traffic Control

• RBC: Radio Block Center

• PIS: Passenger Information System

• TCC: Track Communications Center

• InfiniBand (IB): an input/output (I/O) switching technology that uses a central
InfiniBand switch to establish a single link between remote storage devices,
networks, and servers as well as to direct traffic. It has a compact structure,
greatly improving system performance, reliability, and effectiveness, and relieving
data traffic congestion between hardware devices.

• Remote Direct Memory Access over Converged Ethernet (RoCE): a network

protocol that allows remote direct memory access (RDMA) over the Ethernet.
There are two RoCE versions: RoCEv1 and RoCEv2. RoCEv1 is a data link layer
protocol that allows any two hosts in the same Ethernet broadcast domain to
communicate with each other. RoCEv2 is a network layer protocol and its packets
can be routed.
• Service Level Agreement (SLA): an agreement between a service provider and a
user. The SLA defines the service type and quality provided by the service provider
for the user, and the commitment to the performance and reliability of the user
assurance service. For example, the SLA ensures that the service reliability is
higher than 99.99%, the fault response time is within 30 minutes.

• Operating Expense (OPEX): the sum of the maintenance cost, marketing expense,
labor cost, and depreciation expense during the enterprise operations.
• In the campus network scenario, iMaster NCE-Campus is used as the iMaster NCE
controller.
• In the data center scenario, iMaster NCE-Fabric is used as the iMaster NCE
controller.
• In this scenario, iMaster NCE-IP is used as the iMaster NCE controller.
1. AB
• CIO: Chief Information Officer
• 1st-generation campus network:

▫ In 1980, IEEE released the IEEE 802.3 standard, signaling the birth of
Ethernet technology. By using twisted pair connections, Ethernet was more
cost-effective and easier to implement than previous networking
technologies. Consequently, Ethernet quickly became the mainstream
technology for campus networks. During the early days, campus networks
used hubs as access devices. A hub was a shared-medium device that
worked at the physical layer. It was limited in the number of users it could
support for concurrent access. If many users connected to a hub
simultaneously, network performance degraded severely due to the
expanded collision domain. In the late 1980s, Ethernet switches emerged.
Due to their more advantageous working scheme than hubs, Ethernet
switches therefore quickly replaced hubs to become the standard
components of campus networks.
• Huawei CloudCampus Solution integrates service configuration and management
models across LAN and WAN. It achieves LAN-WAN convergence by not only
configuring and managing LAN services, but also managing WAN interconnection
services.
• In addition to interface-based VLAN assignment, you can also use the following
methods to assign VLANs:

▫ MAC address-based assignment: assigns VLANs based on the source MAC

addresses of frames. This mode applies to small-scale networks where
physical locations of user terminals frequently change but their network
adapters seldom change.

▫ IP subnet-based assignment: assigns VLANs based on the source IP

addresses of frames. This mode applies to scenarios where there are high
requirements for mobility and simplified management and low
requirements for security.

▫ Protocol-based assignment: assigns VLANs based on the protocol (suite)

types and encapsulation formats of frames. This mode applies to networks
running multiple protocols.

▫ Policy-based assignment: assigns VLANs based on a specified policy, which

means VLANs are assigned based on combinations of interfaces, MAC
addresses, and IP addresses. This mode applies to complex networks.
• A device configured with voice VLAN can identify voice flows in either of the
following modes:

▫ MAC address-based identification: A device identifies voice flows based on

the source MAC addresses of received data packets. If a source MAC
address of a packet matches the organizationally unique identifier (OUI) of
a voice device, the packet is considered a voice packet. OUIs must be
preconfigured and are used in scenarios where IP phones send untagged
voice packets.

▫ VLAN-based identification: Configuring OUIs for a large number of IP

phones is time-consuming. In this case, you can configure a switch to
identify voice packets based on VLAN IDs. If the VLAN ID of a received
packet matches the configured voice VLAN ID, the packet is considered a
voice packet. This simplifies configuration when a large number of IP
phones are connected to the switch. However, the IP phones must be able
to obtain voice VLAN information from the switch.
• How is an STP tree generated?

▫ STP compares four parameters: root bridge ID, root path cost (RPC), bridge
ID (BID), and port ID (PID). A smaller value indicates a higher priority. All
these parameters are BPDU fields.

▪ Root bridge election: The device with the smallest root bridge ID is
elected as the root bridge.

▪ Root port election: A device compares the RPC, peer BID, peer PID,
and local PID of its ports in sequence. The port with the smallest
value is elected as the root port.

▪ Designated port election: A device compares the RPC, local BID, and
local PID of its ports in sequence. The port with the smallest value is
elected as the root port.

▪ After the root port and designated port are determined, all the non-
root ports and non-designated ports on the switch will be blocked.
• PBR is used in agile campus service orchestration, multi-egress, and anti-DDoS
off-path deployment scenarios.

• MQC: Modular QoS Command Line Interface

• Generally, all hosts on the same network segment are configured with the same
default route with the gateway address as the next-hop address. The hosts use
the default route to send packets to the gateway, which then forwards the
packets to other network segments, enabling hosts to communicate with external
networks. If the gateway fails, hosts using this gateway address as the next hop
of their default route cannot communicate with external networks.
• The Virtual Router Redundancy Protocol (VRRP) virtualizes several routing
devices into a virtual router and uses the IP address of the virtual router as the
default gateway address for the communication between users and external
networks. If a gateway fails, VRRP selects another gateway to forward traffic,
thereby ensuring reliable communication.
▫ Redundancy: Multiple routing devices enabled with VRRP constitute a VRRP
group and the VRRP group is used as the default gateway. When a single
point of failure (SPOF) occurs, services are transmitted through the backup
link. This reduces the possibility of network faults and ensures non-stop
transmission of services.
▫ Load balancing: VRRP enables multiple available routers to share the load,
reducing the traffic burden on the master.
▫ Association: VRRP can monitor faults on uplinks. When the uplink interface
or uplink is faulty, the priority of the original master decreases, and an
optimal backup becomes the master, ensuring proper traffic forwarding.
Association between VRRP and BFD speeds up the active/standby
switchover. To speed up the active/standby switchover in the VRRP group,
configure a BFD session between the master and backup and associate the
BFD session with the VRRP group. This is because BFD can fast detect
faults. When the link between the master and backup becomes Down, the
backup immediately switches to the master and takes over traffic.
• NQA measures the performance of various protocols running on networks, which
helps users collect statistics about network operation indexes in real time.
• Port isolation provides more secure and flexible networking solutions.

• In some scenarios, data exchanged between terminals in a VLAN needs to be

forwarded by an upper-layer device instead of an access switch. This ensures that
traffic is forwarded by the upper-layer device instead of the access switch, so that
traffic management and control policies can be deployed on the upper-layer
device. This mode is called centralized forwarding mode. In this mode, port
isolation is configured for all downstream Layer 2 devices. Therefore, proxy ARP
should be configured on the gateway. In most cases, intra-VLAN proxy ARP is
used.
• Configuring port security on an interface of a switch can limit the number of
MAC addresses learned by the interface. Then punishment measures can be
taken when a violation occurs.

• The interface configured with port security can convert the learned MAC
addresses into secure MAC addresses, preventing devices with other MAC
addresses from accessing the network through the interface.
• The DHCP snooping-enabled device forwards DHCP Request messages of users
(DHCP clients) to an authorized DHCP server through the trusted interface, and
then generates DHCP snooping binding entries based on the DHCP ACK
messages received from the DHCP server. When receiving DHCP messages from
users through the DHCP snooping-enabled interfaces, the device checks the
messages against the binding table, thereby preventing attacks initiated by
unauthorized users. In addition, DHCP snooping supports multiple security
features, such as limiting the rate for sending DHCP messages.
• An MITM attacker establishes independent connections with two parties that
intend to communicate and relays messages between them. The two parties
consider that they are directly communicating with each other over a private
connection, but the entire conversation is in fact controlled by the attacker. In an
MITM attack, the attacker can intercept all packets exchanged between the two
parties and insert new ones.
• To defend against MITM attacks, configure DAI on a switch.
▫ DAI defends against MITM attacks using a DHCP snooping binding table.
When the switch receives an ARP packet, it compares the source IP address,
source MAC address, VLAN ID, and interface number of the ARP packet
with those in DHCP snooping binding entries. If the ARP packet matches a
binding entry, the switch considers the ARP packet valid and allows the
packet to pass through. If the ARP packet does not match any binding
entry, the switch considers the ARP packet invalid and discards the packet.
▫ DAI is available only when DHCP snooping is configured. A DHCP snooping-
enabled switch automatically generates DHCP snooping binding entries
when DHCP users go online. If a user is configured with a static IP address,
you need to manually configure a static binding entry for the user.
▫ When an attacker connected to the DAI-enabled switch sends bogus ARP
packets, the switch detects the attack based on the binding entries and
discards the bogus ARP packets. If the packet discarding alarm function is
also enabled on the DAI-enabled switch, the switch will generate an alarm
when the number of ARP packets discarded due to failure to match any
binding entry exceeds the alarm threshold.
• As networks continue to increase in scale, a growing number of attackers are
forging source IP addresses to initiate network attacks (IP address spoofing
attacks). Some attackers forge IP addresses of authorized users to obtain
network access rights and access networks. As a result, authorized users are
unable to access networks or sensitive information may be intercepted.

• IPSG provides a mechanism to effectively defend against IP address spoofing

attacks.

▫ The binding table can be a static binding table or a dynamic DHCP

snooping binding table.

▫ IPSG only checks the IP packets from hosts. It does not check non-IP
packets such as ARP packets.
• In addition to using NAC to authenticate access users and control their rights, a
campus network also needs to authenticate and control rights of administrators
(also called login users) who can log in to devices through FTP, HTTP, SSH,
Telnet, or console ports.
• DHCP dynamically configures and uniformly manages IP addresses of hosts.
DHCP is defined in RFC 2131 and uses the client/server communication mode. A
DHCP client requests configuration information from a DHCP server, and the
DHCP server returns the configuration information allocated to the DHCP client.
▫ Instead of statically specifying an IP address for a host, DHCP enables a
host to obtain an IP address dynamically.
▫ DHCP can allocate other configuration parameters, such as the startup
configuration file of a client, so that the client can obtain all the required
configuration information by using only one message.
▫ DHCP supports dynamic and static IP address allocation. A network
administrator can select different address allocation modes for hosts as
required.
▪ Dynamic allocation: DHCP allocates an IP address with a limited
validity period (known as a lease) to a client. This mechanism applies
to scenarios where hosts temporarily access the network or the
number of idle IP addresses is less than the total number of hosts that
do not require permanent connections.
▪ Static allocation: DHCP allocates fixed IP addresses to clients.
Compared with manual IP address configuration, DHCP static
allocation prevents manual configuration errors and enables unified
maintenance and management.
• DHCP has the following benefits:
▫ Reduced client configuration and maintenance cost.
▫ Centralized management of limited IP addresses.
• The plug-and-play of a device is implemented by establishing a NETCONF session
between the device and the controller, so that the controller can deliver
configurations to the device.
• LLDP is a standard Layer 2 topology discovery protocol defined in IEEE 802.1ab.
LLDP collects local device information including the management IP address,
device ID, and port ID and advertises the information to neighboring devices.
Neighboring devices save the received information in their management
information bases (MIBs). The NMS can query required information in MIBs to
determine link status.

• As networks grow in scale, network devices are increasing in diversity with

complex configurations, posing higher requirements on network management
capabilities. Most NMSs can detect Layer 3 network topologies, but they cannot
detect detailed Layer 2 topologies or configuration conflicts. To address the
network management problems, a standard protocol is required to exchange
Layer 2 information between network devices.

• LLDP provides a standard link-layer discovery method. By obtaining Layer 2

information from devices, LLDP allows users to detect the topology of
neighboring devices, and display paths between clients, switches, routers,
application servers, and network servers. The information also helps detect
configuration conflicts between network devices and identify causes of network
failures. Enterprise users can use an NMS to monitor the link status on devices
running LLDP and quickly locate network faults.
• B/S: Browser/Server
• ERP: Enterprise Resource Planning
1. BCD

2. A
• After servers are virtualized, services are encapsulated in VMs. VMs can be live
migrated to any host in a cluster. One of the features of live migration is that the
network status does not change. As a result, the IP addresses of service VMs may
be in different network locations. Therefore, a large Layer 2 network is required
to solve this problem.
• VXLAN is used to meet requirements of DCNs. On traditional enterprise campus
networks, VXLAN is used to construct virtual networks instead of solving some
urgent problems.
• VXLAN solves the following problems on traditional networks:
▫ For VM quantity limited by entry specifications of devices.
▪ VXLAN encapsulates original data packets sent from VMs in the same
domain into UDP packets, with the IP and MAC addresses used on the
physical network in outer headers. Devices on the VXLAN network are
aware of only the encapsulated parameters but not the inner data.
▪ Except VXLAN edge devices, other devices on the network do not need
to identify MAC addresses of VMs. This reduces the burden of learning
MAC addresses and improves device performance.
▫ For limited network isolation capabilities.
▪ VXLAN uses a VXLAN Network Identifier (VNI) field similar to the
VLAN ID field to identify users. The VNI field has 24 bits and can
identify up to 16 million VXLAN segments, effectively isolating a large
number of tenants.
▫ For limited VM migration scope.
▪ VMs using IP addresses in the same network segment are in a Layer 2
domain logically, even if they are on different physical Layer 2
networks. VXLAN technology constructs a virtual large Layer 2
network over a Layer 3 network.
• Underlay network: a physical network, which serves as the basic layer of the
upper-layer logical network.
• Overlay network: a logical network established on the underlay network using
tunneling technologies.
• The virtualization technology is introduced to create multiple virtual networks
(VNs) on a physical network on a campus network. Different VNs are used for
different services, such as OA, videoconferencing, and security protection.
• The preceding packet format is a standard VXLAN packet format. Huawei
CloudEngine S series switches use customize reserved fields based on the
standard one.
• A pair of VTEP IP addresses identifies a VXLAN tunnel.

• The source VTEP encapsulates packets and sends the encapsulated packets to the
destination VTEP through the VXLAN tunnel. After receiving the encapsulated
packets, the destination VTEP decapsulates the packets.

• Generally, the IP address of a loopback interface on a device is used as the VTEP

address.
• After traffic from a traditional network enters a VXLAN network, a Layer 2 sub-
interfaces or VLAN is bound to a BD. A VXLAN VNI is specified in the BD to
implement mapping from the traditional VLAN network to the VXLAN network.
• Centralized gateway:

▫ Advantage: Inter-subnet traffic is managed in a centralized manner,

simplifying gateway deployment and management.

▫ Disadvantage: The forwarding path is not optimal. The ARP entry

specification is a bottleneck. Because a centralized Layer 3 gateway is
deployed, ARP entries must be generated on the gateway for terminals
whose traffic is forwarded through the gateway.

• Distributed gateways:

▫ Advantage: VTEPs only need to learn ARP entries of terminals connected to

them, which eliminates the ARP entry specification bottleneck in the
centralized Layer 3 gateway scenario and improves the network scalability.

▫ Disadvantage: Gateway deployment in this scenario is more complex than

that in the centralized gateway scenario.
• Communication between PC1 and PC2 is as follows:

1. To communicate with PC2, PC1 broadcasts an ARP Request packet to

obtain the MAC address of PC2.

2. After receiving the packet, SW1 determines the BD ID, destination VXLAN
tunnel, and VNI of the traffic based on VAP information. In addition, SW1
learns the MAC address of PC1 and records the BD ID and the interface
that receives the packet in the corresponding MAC address entry.

3. SW1 performs VXLAN encapsulation for the ARP Request packet and
forwards the encapsulated packet based on the ingress replication list.

4. After receiving the VXLAN packet, SW2 decapsulates the packet to obtain
the original data frame. In addition, SW2 learns the MAC address of PC1
and records the BD ID and the VTEP address of SW1 in the corresponding
MAC address entry.

5. SW2 floods the ARP packet in the local BD. PC2 then receives the packet
and learns the ARP information of PC1.
 6. PC2 sends a unicast ARP Reply packet.

7. SW2 has the MAC address entry of PC1; therefore, SW2 unicasts the packet
and learns the source MAC address of PC2 in the MAC address entry.

8. SW2 encapsulates the ARP Reply packet with a VXLAN header and sends it
to the remote VTEP at 1.1.1.1.

9. After SW1 receives the VXLAN packet, it decapsulates the packet and
records the source MAC address of PC2 in the MAC address table. The
outbound interface is the remote VTEP.

10. SW1 forwards the packet to PC1.

• By doing this, PC1 and PC2 learn ARP entries of each other, and SW1 and SW2
learn MAC addresses of each other.
• PC1 wants to communicate with Server2. When finding that Server2 is on a
different subnet, PC1 sends the packet to the gateway.

• PC1 sends a data packet to Server2. The destination MAC address of the data
packet is 00AB-09FF-1111 (gateway MAC address). After receiving the data
packet, SW1 searches the Layer 2 forwarding table and finds that the outbound
interface is a remote VTEP (Layer 3 gateway). Therefore, SW1 adds a VXLAN
header (VNI = 1000) to the data packet. Then the packet is sent to SW3.

• After receiving the packet, SW3 decapsulates the VXLAN packet and finds that
the destination MAC address of the internal original data packet is 00AB-09FF-
1111, which is the MAC address of its own interface VBDIF10. Then SW3 needs to
search the Layer 3 forwarding table.

• SW3 searches the routing table and finds that the destination IP address
192.168.2.1 matches the direct route generated by VBDIF 20. SW3 then searches
the ARP table for the destination MAC address of the packet and searches the
MAC address table for the outbound interface of the packet. On SW3, the
outbound interface for the MAC address corresponding to 192.168.2.1 is the
remote VTEP at 2.2.2.2. SW3 encapsulates the packet into a VXLAN packet and
sends it to SW2.

• After receiving the packet, SW2 decapsulates the VXLAN packet and finds that
the destination MAC address is not the MAC address of any local interface. SW2
then searches the Layer 2 forwarding table and forwards the packet through the
local interface based on the MAC address table.
1. SW1 provides Layer 2 sub-interface access, and SW2 uses the VLAN binding
mode.

2. Create a VBDIF interface as the gateway for terminals in the BD.

• On SW3, configure NVE interfaces to connect to SW1 and SW2, and create VBDIF
100 and VBDIF 200 as gateways of terminals in BD 100 and BD 200.
• Configure GE1/0/1 of SW2 as a trunk interface to allow packets from VLAN 20 to
pass through (you can also configure the interface as an access interface and the
default VLAN as VLAN 20), and bind VLAN 20 to BD 200.
• The static VXLAN solution does not have a control plane. VTEP discovery and
learning of host information (including IP addresses, MAC addresses, VNIs, and
gateway VTEP IP addresses) are performed through traffic flooding on the data
plane. As a result, there is a lot of flooded traffic on VXLAN networks. To address
this problem, VXLAN uses EVPN as the control plane protocol. EVPN allows VTEPs
to exchange BGP EVPN routes to implement automatic VTEP discovery and host
information advertisement, preventing unnecessary traffic flooding.

• Problems in configuring VXLAN in static mode:

▫ If N devices need to establish VXLAN tunnels, you need to manually

configure the ingress replication list a maximum of N(N-1)/2 times.

▫ A static VXLAN tunnel only has the data forwarding plane.

▫ Remote MAC addresses can be learned only through broadcast ARP

packets.
• In a network virtualization overlay (NVO) scenario, BGP EVPN is used together
with VXLAN as the control plane protocol for VXLAN.
• For details about the RD and RT, see the HCIP-Advanced Routing Switching - 08
MPLS VPN Principles and Configuration.
• The first three fields (RD, Ethernet Segment Identifier, and Ethernet Tag ID) of a
Type 2 route are the same in different scenarios, and only the last six fields are
different.
• Intra-subnet host MAC address advertisement:

1. PC1 generates data traffic and sends the traffic to SW1.

2. SW1 obtains the MAC address of PC1 and creates an entry in the MAC
address table to record the MAC address, BD ID, and inbound interface.

3. SW1 generates a BGP EVPN route based on this entry and sends the route
to SW2. The route carries the RT value of the local EVPN instance and Type
2 route (MAC route). In the MAC route, the MAC address of PC1 is stored
in the MAC Address field and the L2VNI is stored in the MPLS Label1 field.

4. After receiving the BGP EVPN route from SW1, SW2 checks the RT (similar
to the RT concept in MPLS VPN) carried in the route. If the RT is the same
as the import RT of the local EVPN instance, SW2 accepts the route.
Otherwise, SW2 discards the route. After accepting the route, SW2 obtains
the MAC address of PC1 and the mapping between the BD ID and the
VTEP IP address (next hop network address in MP_REACH_NLRI) of SW1,
and generates the MAC address entry of PC1 in the local MAC address
table. Based on the next hop, the outbound interface of the MAC address
entry recurses to the VXLAN tunnel destined for SW1.
• A MAC/IP route can carry both the MAC and IP addresses of a host, and
therefore can be used to advertise ARP entries between VTEPs. The MAC Address
and MAC Address Length fields identify the MAC address of the host, whereas
the IP Address and IP Address Length fields identify the IP address of the host.
This type of MAC/IP route is called the ARP route. ARP advertisement applies to
the following scenarios:
▫ ARP broadcast suppression. After a Layer 3 gateway learns the ARP entries
of a host, it generates host information that contains the host IP and MAC
addresses, Layer 2 VNI, and gateway's VTEP IP address. The Layer 3
gateway then transmits an ARP route carrying the host information to a
Layer 2 gateway. When the Layer 2 gateway receives an ARP request, it
checks whether it has the host information corresponding to the
destination IP address of the packet. If such host information exists, the
Layer 2 gateway replaces the broadcast MAC address in the ARP request
with the destination unicast MAC address and unicasts the packet. This
implementation suppresses ARP broadcast packets.
▫ VM migration in distributed gateway scenarios. After a VM migrates from
one gateway to another, the new gateway learns the ARP entry of the VM
(after the VM sends gratuitous ARP packets) and generates host
information that contains the host IP and MAC addresses, Layer 2 VNI, and
gateway's VTEP IP address. The new gateway then transmits an ARP route
carrying the host information to the original gateway. After the original
gateway receives the ARP route, it detects a VM location change and
triggers ARP probe. If ARP probe fails, the original gateway withdraws the
ARP and host routes of the VM.
• ARP advertisement is mainly used in the centralized VXLAN gateway+BGP EVPN
scenario. In BGP EVPN, ARP or IRB advertisement to peers is mutually exclusive.
Only one of these routes can be configured to advertise. Generally, ARP
advertisement is selected in the centralized VXLAN gateway+BGP EVPN scenario,
in the distributed VXLAN gateway+BGP EVPN scenario, IRB routes are advertised.
• In distributed gateway networking, VTEPs function as both Layer 2 and Layer 3
gateways. In this networking, inter-subnet communication is implemented in
multiple modes. According to the processing mode of ingress VTEPs, inter-subnet
communication can be implemented through asymmetric and symmetric
Integrated Routing and Bridging (IRB).

• Inter-subnet forwarding in a VLAN through a VLANIF interface:

▫ Based on the local IP address, local mask, and peer IP address, PC1 finds
that the destination device PC2 is on a different network segment from
itself. Therefore, PC1 determines Layer 3 communication and sends the
traffic destined for PC2 to the gateway. In the data packet sent by PC1, the
source MAC address is MAC1 and the destination MAC address is MAC2.

▫ After receiving the packet sent from PC1 to PC2, the switch decapsulates
the packet and finds that the destination MAC address is the MAC address
of VLANIF 10. Therefore, the switch considers that the packet is sent to
itself and sends the packet to the routing module for further processing.

▫ The routing module parses the packet and finds that the destination IP
address is 192.168.20.2, which is not the IP address of the local interface.
Therefore, the routing module needs to forward the packet at Layer 3.
When the routing module searches the routing table, it matches the direct
route generated by VLANIF 20 against the packet.
• During asymmetric IRB, VTEPs do not transmit host IP routes between each
other. That is, VTEP1 and VTEP2 do not transmit the 32-bit host route (generated
through an ARP entry) of the connected PC. Therefore, VTEP1 searches the
routing table in step 2, and matches the packet against the direct route
generated by VBDIF 10.

• In step 5, VTEP2 decapsulates the VXLAN packet and finds that the destination
MAC address is not the MAC address of the local VBDIF interface corresponding
to the BD. Therefore, VTEP2 searches the Layer 2 forwarding table for the MAC
address entry of the corresponding BD based on the VNI carried in the packet
and then forwards the packet at Layer 2.
• On Huawei devices, Symmetric IRB is used.
• In a BGP EVPN scenario, if you want to control the sending and receiving of EVPN
routes based on the RT value of the IP VPN instance, run the vpn-target evpn
command to configure the RT value. In this case, the ERT is carried in EVPN
routes and sent to the remote BGP EVPN peer, the IRT matches the RT carried in
an EVPN route to determine which EVPN routes can be added to the routing
table of the local VPN instance address family.

• Note: The RT configured using the vpn-target evpn command is called an RT

(EVPN), which is different from common RTs.
• VTEP1 sends a Type 2 BGP EVPN route (IRB type), which carries the ERT (20:1) of
the EVPN instance bound to the BD.

• After receiving the BGP Update message, VTEP2 checks the RT value (20:1)
carried in the BGP Update message and compares it with the IRT in the local
EVPN instance and the IRT (EVPN) in the IP VPN instance. VTEP2 finds that the
IRT of the EVPN instance bound to BD 20 and IRT of the IP VPN instance bound
to VBDIF 20 are the same, adds the EVPN routes to the EVPN routing table of BD
20, and adds the IP routes contained in the EVPN routes to the routing table of
the IP VPN instance bound to VBDIF 20.
• In symmetric IRB mode, VTEPs transmit 32-bit host routes generated using ARP
entries. Therefore, VTEP1 matches the 32-bit host routes transmitted from VTEP2
during route lookup. Even if VTEP1 has the direct route generated by VBDIF 10, it
still forwards packets based on 32-bit host routes according to the longest match
rule.

• In step 4, VTEP2 decapsulates the VXLAN packet and finds that the destination
MAC address of the inner data of a packet is the router MAC address (MAC B) of
VTEP2. VTEP2 determines that it needs to forward the packet based on the
routing table, finds the corresponding IP VPN instance based on VNI 1000, and
searches the routing table of the IP VPN instance for the route, finds the direct
route generated by VBDIF 10, searches the local MAC address table, and sends
the packet to PC2.
• The Provider Multicast Service Interface (PMSI) is an optional transitive BGP
attribute. In VXLAN scenarios, Tunnel Type has a fixed value of 6, which is used
to carry the VTEP's IP address and L2VNI of the sender.
• Similar to Type 2 IRB routes, Type 5 routes carry the router MAC address of the
VTEP through the EVPN router's MAC extended community attribute during
route transmission. In addition, Type 5 routes carry only the L3VNI. Therefore, the
forwarding process is also called IRB forwarding.
• ARP broadcast suppression is an effective method to relieve the burden of a
gateway in processing ARP packets. When receiving an ARP Request packet, the
gateway searches the ARP broadcast suppression table for the mapping between
the IP address and MAC address of the destination device. If the ARP Request
packet matches an entry in the table, the gateway replaces the broadcast MAC
address in the ARP Request packet with the MAC address of the destination
device. Then, the gateway sends the ARP Request packet through the interface
corresponding to the destination MAC address.
• An ARP route carries the following valid information: host MAC address, host IP
address, and L2VNI. An IRB route carries the following valid information: host
MAC address, host IP address, L2VNI, and L3VNI. As a result, an IRB route
includes an ARP route and can be used to advertise both the host IP route and
host ARP entry.
• On a VXLAN network, a bridge domain (BD) is a Layer 2 broadcast domain. After
a VTEP receives BUM packets, it broadcasts the packets in the BD. To reduce
broadcast traffic, a network administrator usually configures access-side isolation
or port isolation to isolate access users in a BD. However, as services become
more diverse and keep increasing, users have growing needs for intra-BD
communication. To allow isolated users in a BD to communicate, configure local
proxy ARP on the VBDIF interface of the BD.
• Generally, the same MAC address is configured for VBDIF interfaces with the
same interface number on different VTEPs. After the distributed gateway function
is enabled, VBDIF interfaces with the same IP address and MAC address do not
report ARP conflicts. In addition, when hosts and VMs are migrated to different
VTEPs, the gateway does not need to resolve ARP entries again.
• The MAC Mobility extended attribute is used to announce the location change of
a host or VM when the host or VM is migrated from one VTEP to another VTEP.
• VXLAN allows a virtual Layer 2 or Layer 3 network (overlay network) to be built
over a physical network (underlay network). The overlay network transmits
packets between different sites through Layer 3 forwarding paths provided by the
underlay network.

• In technical applications, different overlay networks are created for different

services. Services are aware of the overlay network only. The underlay network is
transparent to services.
• L4-L7 security policy: The firewall supports security control from Layer 4 to Layer
7.
• An overlay network is a logical network that is constructed based on a physical
network using a tunneling technology and with separated forwarding and control
planes.
1. A

2. D
• Currently, the intranets of most campus networks are faced with the following
security issues:

▫ Antivirus software is not managed in a centralized manner, and patch

management is disordered. Even if enterprises purchase antivirus software,
it is difficult to ensure that the virus signature databases of all terminals are
the latest. As a result, once a terminal is infected with viruses or malicious
code, the virus will soon spread on the intranet.

▫ User identities cannot be verified. Therefore, unauthorized access cannot be

prevented, posing security risks to the network.

▫ Access control for terminals is not implemented. A user can access all
network resources as long as the user successfully connects to the network.
• A terminal agent (also known as client software) is usually installed on a user
terminal. It works with an admission server to implement user identity
authentication, terminal security check, system repair and upgrade, and terminal
behavior monitoring and audit.
• Admission devices, which can be switches, routers, APs, or other network devices,
provide the following functions:
▫ User identity verification.
▫ User authentication. Admission devices can implement the commonly used
802.1X authentication, MAC address authentication, and Portal
authentication by working with the client software and admission server.
▫ User permission control.
• Admission servers include the security control server, security management
server, virus signature database server, and patch server.
▫ A security control server authenticates users, performs security audit,
executes security policies, and works with admission devices to deliver user
permissions.
▫ A security management server manages user information (including adding,
deleting, or modifying user permissions and departments), and defines and
manages security policies.
▫ A virus signature database server controls automatic update of the virus
signature database in antivirus software on terminals.
▫ A patch server controls patch installation and update for terminals'
operating systems and applications.
• User identity authentication request: A terminal sends the user credential to an
admission device.

• User identity authentication: The admission device sends the user credential to
the admission server for authentication.

• User identity verification: The admission server stores user identity information
and provides user management functions. After receiving the user credential, the
admission server determines whether the terminal identity is valid and delivers
the verification result and corresponding policy to the admission device.

• User policy authorization: The admission device executes the policy based on the
authorization result received from the admission server. For example, the
admission device permits or denies access from the terminal. The admission
device can also perform more complex policy-based control on the terminal, for
example, increasing or decreasing the forwarding priority or limiting the network
access rate.
• The basic NAC process is as follows:

1. User can access the network and have the pre-authentication domain
network permission before authentication, including access to the access
control server, DHCP, and DNS.

2. After terminals are successfully authenticated, the admission server

delivers network access rights to the admission device to allow users to
access resources in the post-authentication domain. For authorized but
insecure users, they are granted the rights to access resources in the
isolation domain. Only after network vulnerabilities on the terminals are
fixed, the admission server grants the rights to access resources in the
post-authentication domain to the users. In the isolation domain, users can
access resources in the pre-authentication domain to install and upgrade
terminal agent software, patches, and antivirus software.

3. Unauthorized users and users who have not completed authentication are
allowed to access resources only in the pre-authentication domain or
isolation domain.
• The EAP packets transmitted between the client and access device are
encapsulated in EAPoL format and transmitted across the LAN.

• Users can determine the authentication mode between the access device and
authentication server based on the client support and network security
requirements.

▫ EAP termination mode: The access device terminates EAP packets and
encapsulates them into RADIUS packets. The authentication server then
uses the standard RADIUS protocol to implement authentication,
authorization, and accounting.

▫ EAP relay mode: The access device directly encapsulates the received EAP
packets into EAP over RADIUS (EAPoR) packets, and then transmits these
packets over a complex network to the authentication server.

• EAPoL defines EAP encapsulation on IEEE 802 (such as 802.3 and 802.11)
networks. EAPoL only transmits EAP packets between 802.1X clients and access
devices, and does not implement authentication.

• Typical EAP authentication protocols include Extensible Authentication Protocol

Transport Layer Security (EAP-TLS), EAP Tunneled Transport Layer Security (EAP-
TTLS), EAP Protected Extensible Authentication Protocol (EAP-PEAP), and EAP
Message-Digest Algorithm 5 (EAP-MD5).
• EAP relay mode

▫ This mode simplifies the processing on the access device and supports
various authentication methods. However, the authentication server must
support EAP and have high processing capability.

▫ The commonly used authentication modes include EAP-TLS, EAP-TTLS, and

EAP-PEAP. EAP-TLS has the highest security because it requires a certificate
to be loaded on both the client and authentication server. EAP-TTLS and
EAP-PEAP are easier to deploy since the certificate needs to be loaded only
on the authentication server, but not the client.

• EAP termination mode

▫ This mode is advantageous in that mainstream RADIUS servers support PAP

authentication and CHAP authentication, eliminating the need of server
upgrade. However, the workload on the access device is heavy because it
needs to extract the client authentication information from the EAP packets
sent by the client and encapsulate the information using the standard
RADIUS protocol. In addition, the access device does not support other EAP
authentication methods except MD5-Challenge.

▫ The major difference between PAP and CHAP is that passwords in CHAP
authentication are transmitted in cipher text, whereas passwords in PAP
authentication are transmitted in plain text. In this aspect, CHAP provides
higher security and is recommended.
• EAP relay authentication process:

1. When a user needs to access an external network, the user starts the
802.1X client, enters the applied and registered user name and password,
and initiates a connection request. The client then sends an authentication
request packet (EAPoL-Start) to the access device to start the
authentication process.

2. After receiving the authentication request packet, the access device returns
an EAP-Request/Identity packet, requesting the client to send the
previously entered user name.

3. In response to the request sent by the access device, the client sends an
EAP-Response/Identity packet containing the user name to the access
device.

4. The access device encapsulates the EAP-Response/Identity packet into a

RADIUS Access-Request packet and sends the RADIUS packet to the
authentication server.

5. After receiving the user name forwarded by the access device, the RADIUS
server searches the user name table in the local database for the
corresponding password, encrypts the password with a randomly
generated MD5 challenge, and sends a RADIUS Access-Challenge packet
containing the MD5 challenge to the access device.
• Dumb terminal: Compared with other terminals, dumb terminals have limited
functions and simple interaction modes. In this document, dumb terminals refer
to terminals whose authentication information such as user names and
passwords cannot be entered.
• By default, a MAC address without hyphens (-) is used as the user name and
password for MAC address authentication, for example, 0005e0112233.
• Passwords of MAC address authentication users can be processed using PAP or
CHAP. The following MAC address authentication process uses PAP as an
example:
1. When a terminal accesses the network, the access device detects and
learns the MAC address of the terminal, triggering MAC address
authentication.
2. The access device generates a random value (MD5 challenge), arranges
the user MAC address, password, and random value in sequence, encrypts
them using the MD5 algorithm, encapsulates the encryption results into a
RADIUS authentication request packet, and sends the packet to the
RADIUS server.
3. The RADIUS server arranges the user MAC address, password saved in the
local database, and received random value in sequence, and uses the
random value to encrypt them using the MD5 algorithm. If the encrypted
password is the same as that received from the access device, the RADIUS
server sends an authentication accept packet to the access device,
indicating that MAC address authentication is successful and the terminal
is allowed to access the network.
• Different from PAP, CHAP arranges CHAP ID，the user MAC address, and
random value in sequence, encrypts them using the MD5 algorithm.
• Client: In most cases, a client is a host where an HTTP/HTTPS-capable browser is
installed.

• Access device: a network device such as a switch or router, which provides the
following functions:

▫ Redirects all HTTP and HTTPS requests of users on authentication subnets

to the Portal server before authentication is performed.

▫ Interacts with the Portal server and authentication server to implement user
authentication, authorization, and accounting.

▫ Grants users access to specified network resources upon successful

authentication.

• Portal server: a server system that receives authentication requests from clients,
provides Portal services and authentication pages, and exchanges client
authentication information with access devices.

• Authentication server: interacts with access devices to implement user

authentication, authorization, and accounting.
• Select a Portal authentication mode based on the actual network requirements.

▫ When Layer 2 authentication is used, the device can learn users' MAC
addresses and identify the users based on their MAC addresses and IP
addresses. Layer 2 authentication provides a simple authentication process
while ensuring high security. However, users must be in the same network
segment as the access device, causing inflexible networking.

▫ When Layer 3 authentication is used, the device cannot obtain the MAC
address of a client, so it identifies the user based only on the client IP
address. Layer 3 authentication allows for flexible networking and
facilitates remote control. However, users can only be identified based on
their IP addresses, leading to poor security.

• The Portal authentication process is as follows:

1. Before authentication, the client establishes a pre-connection with the

access device. The access device creates a user online entry for the client
and grants the client access to certain network resources. The Layer 3
authentication process is similar to the Layer 2 authentication process,
except that no pre-connection is established between the client and access
device.

2. The client initiates an HTTP connection request.

• The following uses CHAP authentication as an example to describe the Portal-
based Portal authentication process:

7. After receiving the Portal authentication request, the Portal server sends a
Portal challenge request packet to the access device. This step is performed
only when CHAP authentication is used between the Portal server and
access device. If PAP authentication is used, steps 7 and 8 are not
performed.

8. The access device sends a Portal challenge response packet to the Portal
server.

9. The Portal server encapsulates the entered user name and password into a
Portal authentication request packet and sends the packet to the access
device.

10. The access device and RADIUS server exchange user information to
authenticate the user, including:

▪ The access device encapsulates the entered user name and password
into a RADIUS authentication request packet and sends the packet to
the RADIUS server.
• HTTPS is a secure HTTP and also known as HyperText Transfer Protocol over
Transport Layer Security (HTTP over TLS) or HyperText Transfer Protocol over
Secure Socket Layer (HTTP over SSL). HTTPS uses HTTP for communication and
SSL/TLS for data encryption.
• A URL is a concise representation of the location and access method of a
resource that can be obtained from the Internet. It is the address of a standard
resource on the Internet. Each file on the Internet has a unique URL. The URL
contains information about the location of the file and how a browser should
process the file.
• When HTTP/HTTPS-based Portal authentication is used, the authentication
process is as follows:
1. The Portal server instructs the client to send a Portal authentication
request to the access device.
2. The client sends a Portal authentication request to the access device.
3. After receiving the Portal authentication request, the access device parses
the packet according to parameter names to obtain parameters such as
the user name and password, and then sends the obtained user name and
password to the RADIUS server for authentication. The process is similar to
the Portal-based Portal authentication.
4. The access device returns the Portal authentication result to the client and
adds the user to the local online user list.
• As shown in the figure, an HTTP request is sent in Get mode:
https://Portal.example.com/login?userName=test&password=Huawei@123. You
can see that the user name and password are in plain text and are separated
from the URL by a question mark (?).
• After passing Portal authentication, terminals may be disconnected from the
wireless network when they move from one wireless signal coverage area to
another or when the wireless signal is unstable. In this case, users need to enter
their user names and passwords for identity authentication every time the
terminals go online, leading to poor network access experience. MAC address-
prioritized Portal authentication is used to resolve this problem. Generally, there
is no need to enable MAC address-prioritized Portal authentication on wired
networks that provide stable signals.
• When the RADIUS server is used, the authentication accept packet also contains
user authorization information because RADIUS authorization is combined with
authentication.

• VLAN-based authorization by the RADIUS server:

▫ After a user is authenticated, the RADIUS server delivers an authorized

VLAN to the user. The access device then changes the VLAN to which the
user belongs to the authorized VLAN, with the interface configuration
remaining unchanged. The authorized VLAN has a higher priority than the
VLAN configured on the interface. That is, the authorized VLAN takes effect
after the authentication succeeds, and the configured VLAN takes effect
when the user is offline.

• The RADIUS server can assign an authorized ACL to a user in either of the
following modes:

▫ Static ACL assignment: The RADIUS server uses the standard RADIUS
attribute Filter-Id to assign an ACL ID to the user. In this mode, the ACL
and corresponding rules are configured on the access device in advance.

▫ Dynamic ACL assignment: The RADIUS server uses the Huawei extended
RADIUS attribute HW-Data-Filter to assign an ACL ID and corresponding
rules to the user. In this mode, the ACL ID and ACL rules are configured on
the RADIUS server.
• When an authentication-free rule is configured using an ACL, the ACL number is
in the range from 6000 to 6031.

• The NAC escape mechanism grants specified network access rights to users when
the authentication server is Down or to users who fail the authentication or are
in pre-connection state. The escape solutions vary according to the
authentication modes. Some escape solutions are shared by all authentication
modes, while some are supported only in specific authentication modes. For
details, see "NAC Escape Mechanism" in the product documentation.
• Note:

▫ MAC address authentication supports only user logout control by the access
device and server.

▫ Portal authentication allows both the authentication server and Portal

server to control user logout.
• VAP indicates a virtual access point.

• VAP profile: Configure WLAN parameters in a VAP profile, and bind the VAP
profile to an AP group or AP. Then, a VAP is generated on the AP to provide
wireless access services for STAs.
• After a static user is configured, the device preferentially uses the user name and
password of the static user to authenticate the user when detecting that the user
information matches the parameters such as the IP address range and domain
name configured for the static user. If the authentication fails, the device
performs 802.1X, MAC address, or Portal authentication on the user.

• You can run the static-user username macaddress format command to specify
the MAC address of a terminal as the user name and password for
authentication, as well as the user name format. This command has a higher
priority than the static-user username format-include and static-user
password cipher password commands.

• The static-user username format-include and static-user password commands

are used to configure the user name and password of a static user respectively.

• By default (the S5731 is used as an example):

▫ The user name of a static user is a combination of [system-name] and [ip-

address]. For example, when the system name of an access device is
huawei and the user IP address is 1.1.1.1, then the static user name is
huawei1.1.1.1.

▫ The password of a static user is not configured.

• In this example, SW3 and SW4 are deployed between the authentication switch
SW2 and users. Therefore, transparent transmission of 802.1X packets must be
configured on SW3 and SW4 so that SW2 can perform 802.1X authentication on
users.
• Devices at the access layer must transparently transmit BPDUs. Otherwise, 802.1X
authentication fails. The reason is as follows:

▫ EAP packets transmitted in 802.1X authentication are BPDUs. By default,

Huawei switches do not perform Layer 2 forwarding for BPDUs. If a Layer 2
switch exists between the 802.1X-enabled device and users, Layer 2
transparent transmission must be enabled on the Layer 2 switch. Otherwise,
the EAP packets sent by users cannot reach the 802.1X-enabled device,
causing authentication failures.
• After policy association is configured, access devices can transparently transmit
BPDUs and report user logout and user access positions in real time. In addition,
authentication control devices request authentication access devices to execute
user access policies, thus controlling user access to the network.

• Roles involved in policy association:

▫ Authentication access device: an authentication execution point that

executes network access policies for users. When an authenticated user
accesses the network, the device executes the corresponding access policy,
such as a policy defining the VLAN, ACL, or UCL group to which the user
belongs.

▫ Authentication control device: an authentication control point that

authenticates users and controls their access policies. The device
authenticates the identities of users who attempt to access the network and
specifies their network access rights, that is, accessible resources.
• User login process:

1. The control device and access device establish a CAPWAP tunnel with each
other.

2. When detecting the access of a new user, the access device creates a user
association entry to record basic information such as the user and access
interface.

3. The access device sends a user association request to the control device.

4. The control device creates a user association entry to save the mapping
between the user and access device, and returns a user association
response to notify the access device of successful association.

5. The user initiates an authentication request to the control device. The

access device forwards the authentication packets between the user and
control device.

6. The control device deletes the user association entry. When the
authentication succeeds, the control device generates a complete user
entry, and sends a user authorization request to the access device, and
delivers the network access policy of the user to the access device.

7. The access device updates the user association entry, grants the specified
network access rights to the user, and sends a user authorization response
to the control device.

8. The user accesses the specified network resources.

• Authentication:

▫ The user exchanges information with the authentication point. The

authentication point directly exchanges authentication information with the
authentication server. When the authentication succeeds, the authentication
server delivers the user rights to the authentication point. The interface on
the authentication point then executes the corresponding user policy.

• Policy association:

▫ The user exchanges information with the authentication execution point.

The authentication execution point transmits the user credential to the
authentication control point through a CAPWAP tunnel. The authentication
control point exchanges authentication information with the authentication
server.

▫ When the authentication succeeds, the authentication server delivers user

rights to the authentication control point, which further forwards the user
rights to the authentication execution point through the CAPWAP tunnel.
Finally, the interface on the authentication execution point executes the
corresponding user policy.
• [Huawei-GigabitEthernet0/0/1] authentication access-point [ open ]

▫ open: Disables right control of the access point.

• [Huawei-GigabitEthernet0/0/1] authentication control-poin [ open ]

▫ open: Enables the forwarding function of the control point.

• Configure access authentication for access devices.

▫ By default, access devices can connect to a control device only after passing
authentication. The control device authenticates access devices using a
blacklist and whitelist. Blacklisted access devices cannot connect to the
control device, whereas whitelisted access devices can. The control device
does not authenticate access devices out of the blacklist and whitelist, and
you need to manually specify allowed access devices. You can also
configure none authentication for access devices. As a result of this
configuration, an access device can connect to the control device regardless
of whether the access device is in the blacklist or whitelist.

▫ For details about how to configure this function, see the product
documentation.
1. D
2. ACD
• With the construction and promotion of wireless networks, the boundaries of
enterprise campus networks are disappearing, and office locations of enterprise
employees become more flexible.

• The large-scale movement of employees' access locations improves enterprise

production efficiency, but also brings challenges to enterprise network
management and security. Mobile working causes the IP addresses of employees'
hosts to change frequently. However, traditional campus networks cannot adapt
to this change because employees' rights are controlled based on their IP
addresses.
• Mobile working requires that these defects be removed and employees obtain
consistent network access rights when accessing the network from any place, any
VLAN, or any IP network segment. In addition, administrators want to have a
simple policy control approach that is decoupled from network topologies and IP
addresses.
• Decoupling of service policies from IP addresses
▫ Using iMaster NCE-Campus, administrators can divide users and resources
on the entire network into different security groups based on diverse
dimensions. In addition, network devices in the free mobility solution use an
innovative software and hardware design. Such a device can match source
and destination security groups based on the source and destination IP
addresses of packets, and then find the matching inter-group policy based
on these security groups.
▫ Through the innovative designs, all the user- and IP address–based service
policies on traditional networks can be transformed into security group–
based policies. When predefining service policies, administrators no longer
need to consider user IP addresses. This achieves decoupling of service
policies from IP addresses.
• Centralized management of user information
▫ Administrators can use iMaster NCE-Campus to centrally manage user
authentication and login information and obtain the mappings between
network-wide users and their IP addresses.
• Centralized policy management
▫ iMaster NCE-Campus is not only the authentication center on a campus
network, but also the management center of service policies. Administrators
can use iMaster NCE to centrally manage service policies on policy
enforcement devices on the entire network. After being configured for once,
service policies can be automatically delivered to policy enforcement devices
on the campus network. These policies include permission control policies
(for example, group A is forbidden to access group B) and experience
guarantee policies (for example, the bandwidth and priority for forwarding
traffic of group A are controlled).
• Free mobility introduces the concept of security group. Security groups are
related only to user identities and are completely decoupled from network
information such as user VLANs and IP addresses.

• User policy management and permission control are implemented based on

security groups.
• Additional information about the policy enforcement point:

▫ The policy enforcement point is responsible for enforcing security group–

based service policies. To enforce these policies, the policy enforcement
point must be able to identify the source and destination security groups of
packets. It can obtain the mappings between IP addresses and security
groups during the authentication process or from iMaster NCE-Campus.

▫ The authentication point and policy enforcement point are two device roles.
Based on the administrator's configuration and device capabilities, a
physical device can play either or both of the two roles.
• Security group:

▫ An administrator can define security groups on iMaster NCE-Campus to

describe and organize the sources or destinations of network traffic, and
then configure policies to control mutual access between the security
groups.

▫ An administrator can add network objects that have the same access
requirements to the same security group, and configure a policy for this
security group. In this way, these network objects obtain the same
permissions as configured for the security group. For example, an
administrator can define the following security groups: R&D group (a
collection of individual hosts), printer group (a collection of printers), and
database server group (a collection of server IP addresses and ports).
Compared with the solution in which access control policies are deployed
for each user, the security group–based access control solution greatly
reduces the administrator's workload.
• Classification of security groups:

▫ A security group can be both a dynamic security group and a static security
group. That is, it is bound to both multiple authorization rules to represent
dynamic users and multiple IP addresses or IP network segments to
represent static resources. The differences are as follows:

▪ The IP addresses of users in dynamic security groups are not fixed,

and are dynamically bound to security groups after the users are
authenticated. After users log out, the bindings are dynamically
canceled. These mappings remain valid only when users are online.
Network devices can obtain the mappings between IP addresses and
security groups (also known as IP-security group entries) by acting as
authentication points, or iMaster NCE-Campus delivers the mappings
to network devices.

▪ The IP addresses of static resources are fixed. An administrator needs

to bind these IP addresses to static security groups on iMaster NCE-
Campus, which then synchronizes the bindings to policy enforcement
points. Static security group members can be any network objects that
use fixed IP addresses, such as terminals, servers, interfaces of
network devices, and authentication-free users.

▫ If an IP address is added to different groups both in static mode and upon

successful authentication, the dynamic security group assigned during
authentication takes effect.

▫ An IP address can belong to only one security group.

• Dumb terminals, data center server resources, and authentication-free users do
not need to be authenticated when accessing the network. Therefore, they
cannot be authorized by the AAA server. In this case, you can bind their static IP
addresses to resource groups.

• Note: When resource groups are used, a policy enforcement point generates a
policy by IP address, instead of based on each resource group. As such, the device
may have a large number of policies.
• When multiple policies are configured to control access from a source security
group to multiple destination groups, an administrator needs to configure
priorities of the policies to determine the sequence in which policies are matched.
For example, if the destination groups are resource groups with overlapping IP
addresses, the administrator can set a high priority for a policy so that the policy
can be matched preferentially.
• For unknown users:
▫ If a policy enforcement device does not find any security group
corresponding to an IP address, it considers that the IP address belongs to
the default security group named unknown, and enforces the matching
security group policy (default policy: permit).
• The following uses the traffic from the sales group to the server group as an
example to describe policy matching in the policy control matrix:
▫ The device (policy enforcement point) first searches for the policy of
controlling access from the sales group to the server group. If no such inter-
group policy is found in the policy control matrix, the device continues
matching policies.
▫ The device then searches for the policy of controlling access from the sales
group to the any group. If no such inter-group policy is found in the policy
control matrix, the device continues matching policies.
▫ Finally, the device matches traffic with the policy of controlling access from
the any group to the any group. By default, this policy exists in the policy
control matrix and defines the permit action. That is, traffic is permitted by
default if no policy is matched.
• A policy enforcement point can obtain IP-security group entries in either of the
following ways:

▫ The policy enforcement point obtains IP-security group entries during user
authentication when it is located on the same device as the authentication
point.

▫ iMaster NCE-Campus pushes IP-security group entries to the policy

enforcement point through an HTTP/2.0 channel. This scenario is known as
IP-security group entry subscription.

• In the IP-security group entry subscription scenario, iMaster NCE-Campus must

have already generated IP-security group entries during user authentication.
Therefore, IP-security group entry subscription has the following requirements:

▫ iMaster NCE-Campus functions as the RADIUS server to perform end user

authentication. In this way, it can generate IP-security group entries during
user authentication, and synchronize the entries to the free mobility
component.

▫ iMaster NCE-Campus functions as a RADIUS relay agent when a third-party

RADIUS server is used for user authentication. In this way, iMaster NCE-
Campus can obtain security group information during the authentication
process to generate IP-security group entries.
• Free mobility deployment based on iMaster NCE-Campus:

▫ Create users and security groups.

▪ An administrator can define users and security groups on iMaster

NCE-Campus in a unified manner. Security groups can be defined
based on network services for configuring inter-group control policies.

▫ Define and deploy a policy control matrix.

▪ The administrator defines inter-group policies in a policy control

matrix on iMaster NCE-Campus, and delivers the policy control matrix
to policy enforcement points.

▫ A user initiates authentication.

▪ When a user is being authenticated, iMaster NCE-Campus associates

the user with a security group based on the user login information.
After the user is authenticated successfully, iMaster NCE-Campus
delivers the authorization result containing the security group to
which the user belongs to the authentication point. During 802.1X
authentication, if a terminal has not obtained an IP address, the
authentication point automatically detects the actual IP address of the
user after the user is successfully authenticated and obtains an IP
address, and reports the user's actual IP address to iMaster NCE-
Campus. iMaster NCE-Campus collects IP addresses of all online users
and synchronizes all user information to policy enforcement points.
• To manually specify a device as a policy enforcement point managed by iMaster
NCE-Campus, enable the free mobility function by running the following
command:

• [HUAWEI] group-policy controller ip-address1 [ port-number1 ] password

password [ src-ip ip-address2 ]
▫ ip-address1 [ port-number1 ]: specifies the IP address of a controller and
the port number used by the device to exchange packets with the controller.
If no port number is configured, the default port number 5222 is used.

▫ password password: specifies the password used by the device to connect

to the controller. The password configured on the device must be the same
as that configured on the controller.

▫ src-ip ip-address2: specifies the source IP address used by the device to

communicate with the controller. If this parameter is not configured, the
device selects one of its own IP addresses to communicate with the
controller.
• A security group policy reflects whether two security groups can communicate
with each other. The administrator can configure policies to permit or deny
communication between every two security groups in a policy control matrix on
iMaster NCE-Campus. If no control policy is created for a source group and a
destination group, they can communicate with each other by default.

• When planning security group policies, pay attention to the direction of policies.
Generally, packets are transmitted in both directions between two terminals.

▫ For Huawei switches, traffic from switch A to switch B and traffic from
switch B to switch A match different policies. Whether traffic is permitted or
denied depends on the source and destination groups of the traffic. If the
permit action is configured for the A-to-B traffic and the deny action for
the B-to-A traffic, all packets sent from switch A to switch B are allowed to
pass through, but the packets sent from switch B to switch A are discarded,
regardless of which device initiates the request. If no matching policy is
found, a switch performs the default action — permit.

• Generally, network access involves bidirectional communication. Therefore, to

simplify management, you only need to consider the access permissions from
user security groups to other users and servers when designing permission
control policies.

▫ To prevent users from accessing a security group, you only need to

configure a unidirectional deny rule.

▫ To allow users to access a security group, you only need to configure a

unidirectional permit rule.
• If the authentication point and policy enforcement point are located on different
devices, the IP-security group entries of authenticated users need to be pushed to
the specified policy enforcement point. An administrator can configure
subscription on iMaster NCE-Campus to specify the entries of which network
segments or security groups to be pushed to which policy enforcement points.
1. B

2. B
• By integrating the user authentication, user management, and policy association
functions, the CloudCampus Solution provides unified authentication and access
policy control for both wired and wireless users. Administrators can have a
consistent user management experience, with simplified O&M for wired and
wireless networks.
• CPE: Customer Premises Equipment

• GUI: Graphical User Interface

• Application identification:

▫ Precise identification of applications on a network is the prerequisite and

basis for network services such as intelligent traffic steering, QoS,
application optimization, and security. Service policies can be applied in
subsequent service processes only after applications are identified.

▫ Two application identification methods are available in the SD-WAN EVPN

Interconnection Solution: first packet inspection (FPI) and service awareness
(SA).

• Intelligent traffic steering:

▫ The SD-WAN EVPN Interconnection Solution supports traffic steering based

on the application quality, load balancing, application priority, and
bandwidth.
• Managed service provider (MSP): delivers and manages network-based services,
applications, and devices. The serviced objects include enterprises, residential
areas, and other service providers.

• Perpetual license + SnS: The perpetual license is sold together with SnS services,
such as software patches, software upgrades (including new features of new
releases), and remote support. In the perpetual license + SnS mode, a customer
needs to pay SnS fee for a certain period of time, in addition to purchasing the
license upon the first purchase. If the customer does not renew the SnS annual
fee after it expires, the customer can only use functions provided in the license
for the current version and cannot use the service functions covered in the SnS
annual fee.

• SaaS mode: MSPs are responsible for deploying or leasing hardware

infrastructure, and O&M and management of the hardware and software.
Software is provided for customers as cloud services and customers need to
periodically pay for the cloud services.

• Term Based License (TBL) mode: This mode differs from the perpetual license +
SnS mode in that the licenses purchased by customers have limited validity
periods. If a customer does not renew the subscription after the license expires,
the customer can no longer use the software product.

• SnS: refers to Subscription and Support. It consists of two parts: software support
and software subscription. The complete software charging mode consists of the
annual software SnS fee and software license fee.

• Note: This course uses the on-premise deployment as an example.

• Using algorithms to improve efficiency and leveraging scenario-specific
continuous learning and expert experience, intelligent O&M frees O&M personnel
from nerve-wracking alarms and noises, making O&M automated and intelligent.
• Efficiently supports WLAN network planning:

▫ No installation: Cloud-based tool, without the need of software installation.

▫ All-scenario: All scenarios supported, including indoor, outdoor, agile

distributed, and high-density scenarios.

▫ Efficient: Improved simulation efficiency when compared with the

traditional standalone deployment.

▫ High quality: Supports tens of thousands of WLAN projects.

• For more information about the WLAN, such as WLAN planning, SSID planning,
and radio calibration, see the Small- and Medium-Sized Cloud-Managed Campus
Network Design or HCIX-WLAN series courses.
• Network layer

▫ Virtualization technologies are introduced to divide the network layer into a

physical network and a virtual network.

▪ Physical network: is also called the underlay network and provides

basic connection services for a campus network. To meet access
requirements of multiple types of terminals, the physical network
provides converged access for three networks, allowing simultaneous
access of wired, wireless, and IoT terminals.

▪ Virtual network: is also called the overlay network. Virtualization

technology is used to construct one or more overlay networks on top
of the underlay network. Service policies are deployed on the overlay
networks and are separated from the underlay network, decoupling
services from networks. Multiple overlay networks can serve different
services or customer segments.
• On a large- or medium-sized campus network, the virtualization solution may
need to be used to decouple services from the network, so as to build a multi-
purpose network and achieve flexible, fast service deployment without changing
the basic network infrastructure. Using such a solution means that the virtualized
campus network architecture must be different from the traditional network
architecture.

• This slide presents the virtualized campus network architecture. The underlay is
the physical network layer, and the overlay is the virtual network layer
constructed on top of the underlay using the Virtual Extensible LAN (VXLAN)
technology.
• On a fabric network, a VXLAN tunnel endpoint (VTEP) can function as either a
border or edge node:

▫ Border node: It corresponds to a physical network device and forwards data

between the fabric and external networks. In most cases, border nodes are
VXLAN-capable core switches.

▫ Edge node: It corresponds to a physical network device. User traffic enters

the fabric from the edge node. Typically, edge nodes are VXLAN-capable
access or aggregation switches.

• Policy association:

▫ Policy association provides a solution to contradiction between policy

strengths and complexity on large campus networks. In the solution, user
access policies are centrally managed on the gateway devices and enforced
by gateway and authentication access devices.

▫ After policy association is configured, authentication access devices can

transparently transmit BPDUs and report user logout and user access
positions in real time. In addition, the authentication control device requests
authentication access devices to enforce user access policies, thus
controlling user access to the network.
1. Request for user identity authentication: The terminal sends its identity
credential to the admission device.

2. User identity authentication: The admission device sends the identity credential
to the admission server for identity authentication.

3. User identity verification: The admission server stores user identity information
and manages users. After receiving the identity credential of the terminal, the
admission server verifies the identity of the terminal, determines whether the
terminal identity is valid, and delivers the verification result and policy to the
admission device.

4. User policy authorization: As a policy enforcement device, the admission device

implements policy control over the terminal based on the authorization result
provided by the admission server, for example, permitting or denying network
access, or performing more complex policy control on the terminal. Complex
policy control can be increasing or decreasing the forwarding priority of the
terminal, or restricting the network access rate of the terminal.
• CAPWAP: Control and Provisioning of Wireless Access Points
• Free mobility introduces the concept of security group. Security groups are
related only to user identities and are completely decoupled from network
information such as user VLANs and IP addresses.

• User policy management and permission control are performed based on security
groups.
• On large- and medium-sized campus networks, access terminals include smart
terminals (such as PCs and mobile phones) and dumb terminals (such as IP
phones, printers, and IP cameras). Currently, terminal management on campus
networks faces the following challenges:

▫ The network management system (NMS) can only display the IP and MAC
addresses of access terminals, but cannot identify the specific terminal type.
As a result, the NMS cannot provide refined management for network
terminals.

▫ Network service configurations and policies vary according to the terminal

type. Consequently, administrators need to manually configure different
services and policies for each type of service terminals, complicating service
deployment and operations.

• To address these challenges, Huawei provides the automatic terminal

identification and policy delivery solution, which delivers the following functions:

▫ iMaster NCE-Campus can display the network-wide terminal types and

operating systems, for example, dumb terminals including printers, IP
cameras, smart all-in-one card, and access control system. iMaster NCE-
Campus can also collect statistics and display traffic by terminal type.

▫ Administrators do not need to manually configure different services and

policies for different types of dumb terminals such as IP phones, printers,
and IP cameras on the campus network. Instead, iMaster NCE-Campus can
automatically identify these terminals and deliver the corresponding
admission policies and service configurations to them.
• Passive fingerprint-based identification: Network devices collect fingerprints of
packets sent by terminals and report the fingerprints to iMaster NCE-Campus,
which matches the fingerprints against its fingerprint database for terminal type
identification. In this mode, terminals can be identified through a MAC
organizationally unique identifier (OUI), HTTP User-Agent, DHCP Option, LLDP,
and multicast DNS (mDNS).

• Proactive scanning and identification: iMaster NCE-Campus proactively detects or

scans terminals, and identifies terminal types based on fingerprint information of
the terminals. In this mode, terminals can be identified through SNMP query or
network mapper (Nmap).
• When terminals access the network, network devices can collect terminal
information and report the information to iMaster NCE-Campus. Alternatively,
iMaster NCE-Campus can proactively scan terminals to identify the terminal type,
OS, and manufacturer.
• Using virtualization technologies, multiple virtual networks (VNs) can be created
on top of a physical network. Different VNs are used for different services, such
as OA, videoconferencing, and security protection.

• VC: Video Conference

• Large- and medium-sized campus networks often use the tree topology with the
core layer as the root, as shown in the figure. This topology is stable and easy to
expand and maintain. A campus network can be divided into the following layers:
access layer, aggregation layer, core layer, and multiple zones including the
egress zone, DC zone, and O&M zone. Internal changes within a module have
limited impact on other modules, facilitating fault location.
• Terminal layer
▫ The terminal layer involves various types of terminals that access the
campus network, such as PCs, printers, IP phones, mobile phones, and
cameras.
• Access layer
▫ The access layer provides various access modes for users and is the first
network layer for terminals to access a campus network. The access layer is
usually composed of access switches. There are a large number of access
switches that are sparsely distributed in different places on the network. In
most cases, an access switch is a simple Layer 2 switch. If the terminal layer
has wireless terminals, the access layer provides APs that access the
network through access switches.
• Aggregation layer
▫ The aggregation layer connects the access layer to the core layer. The
aggregation layer forwards horizontal traffic between users and forwards
vertical traffic to the core layer. It can also function as the switching core
for a department or zone and connect the department or zone to the
exclusive server zone. In addition, the aggregation layer can further extend
the quantity of access terminals.
• Layered design:

▫ Each layer can be considered a well-structured module with specific roles

and functions. This layered structure is easy to expand and maintain,
reducing the design complexity and difficulty.

• Modular design:

▫ Each module corresponds to a department, function, or service area.

Modules can be expanded flexibly based on the network scale, and
adjustment in a department or area does not affect other departments or
areas, which facilitates fault locating.

• Redundancy design:

▫ Dual-node redundancy design can ensure device-level reliability.

Appropriate redundancy improves reliability, but excessive redundancy
makes O&M difficult. If dual-node redundancy cannot be implemented, you
may consider card-level redundancy, such as dual main control boards or
switch fabric units (SFUs), for modular core switches or egress routers. In
addition, Eth-Trunk can be deployed for important links to ensure link-level
reliability.

• Symmetric design:

▫ A symmetric network structure makes the topology clearer and facilitates

service deployment, protocol design and analysis.
• Design method of the hierarchical model for common network architectures:

1. Determine the number of access switch ports based on the network scale.
Typically, one port corresponds to one terminal or one network access
point (for example, AP).

2. Select switches based on the port rates of terminals' NICs.

3. Calculate the number of access switches.

▪ Number of access switches required = Number of access

ports/Number of downlink ports on a switch

▪ If the calculation result is greater than 1, aggregation switches need

to be deployed. Otherwise, use the single-layer architecture.

4. Select aggregation switches based on the uplink port rates of access

switches.

5. Calculate the number of uplinks of access switches using either of the

following methods:

▪ Based on the network bandwidth: Number of uplinks = Network

bandwidth/Uplink port rate of an access switch

▪ Based on the network scale: Number of uplinks = (Number of access

ports x Access port rate x Bandwidth oversubscription ratio)/Uplink
port rate of an access switch
• Service VLAN:

▫ Assign VLANs by logical area, geographical area, personnel structure, or

service type.

▪ Assign VLANs by logical area. For example, VLANs 100 to 199 are
used in the core network zone, VLANs 200 to 999 are used in the
server zone, and VLANs 2000 to 3499 are used on the access network.

▪ Assign VLANs by geographical area. For example, VLANs 2000 to 2199

are used in area A, and VLANs 2200 to 2399 are used in area B.

▪ Assign VLANs by personnel structure. For example, department A uses

VLANs 2000 to 2009, and department B uses VLANs 2010 to 2019.

▪ Assign VLANs by service type. For example, VLANs 200 to 299 are
used in the web server zone, VLANs 300 to 399 are used in the app
server zone, and VLANs 400 to 499 are used in the database server
zone.

▫ If users are sensitive to the voice latency, the voice service must be
preferentially guaranteed. It is recommended that the voice VLAN be
planned for the voice service. Huawei switches can automatically identify
voice data, transmit voice data in the voice VLAN, and perform QoS
guarantee. When network congestion occurs, voice data can be
preferentially transmitted.
• IP address planning complies with the following principles:

▫ Unique: Each host on an IP network must have a unique IP address.

▫ Contiguous: Node addresses of the same service must be contiguous to

facilitate route planning and summarization. Contiguous addresses facilitate
route summarization, thereby reducing the size of the routing table and
speeding up route calculation and convergence.

▫ Scalable: Some IP addresses need to be reserved at each layer, so that no

address segments or routing entries need to be added when the network is
expanded.

▫ Easy to maintain: Device and service address segments need to be clearly

distinguished from each other, facilitating subsequent statistics monitoring
and security protection based on address segments. IP addresses can be
planned based on VLANs.
• The routing design includes internal and egress routing design for a campus
network.

▫ Internal routing design:

▪ The routing design must support communication between devices,

between terminals, and between devices and terminals on the campus
network, as well as communication between these devices/terminals
and the external network.

▪ It is recommended that you design internal routes based on the

gateway location.

− If gateways are deployed at the aggregation layer, routes need

to be deployed at core and aggregation layers. Routing tables
can be dynamically updated along with network topology
changes, so an Interior Gateway Protocol (IGP), such as Open
Shortest Path First (OSPF), is recommended.

− If gateways are deployed at the core layer, you only need to

configure routes at the core layer. It is recommended that static
routes be used preferentially.
• Typically, egress and core devices on large- and medium-sized campus networks
are centrally deployed in a core equipment room. Services transmitted on these
devices are complex and their locations on the network are important. In most
cases, network engineers need to commission devices onsite during the
deployment. Therefore, you are advised to use the web system or CLI to deploy
devices at the core layer and upper layers (including core devices, standalone ACs
connected in off-path mode, and egress devices).

• A large number of devices (including aggregation devices, access devices, and

APs) are deployed at lower layers of the core layer, and service configurations of
these devices are similar. Therefore, you are advised to use the DHCP option
mode to achieve plug-and-play of devices, thereby simplifying the deployment.

• Note: Core switches obtain basic configurations such as IP addresses using the
CLI. Once they establish management channels with iMaster NCE-Campus,
iMaster NCE-Campus will automatically deliver services to them.
• The DHCP server pushes PnP VLAN information to its downstream devices
through LLDP. Note that:

▫ If NETCONF is not enabled on the core switch (DHCP server), the core
switch cannot be onboarded on iMaster NCE-Campus. In this case, the
administrator needs to manually configure the PnP VLAN on the core
switch. Then the switch to be deployed can negotiate with the core switch
through LLDP to obtain the configured PnP VLAN.

• Note: The PnP VLAN and management VLAN of a switch can be the same or
different.

• LLDP: Link Layer Discovery Protocol

• This deployment process applies to scenarios with scattered installation time.
• This deployment process is applicable to scenarios with concentrated installation
time. The administrator is advised to plan the network before onboarding
devices. If the network cannot be planned in advance, the administrator can
onboard devices first and then determine the network topology.

• Network planning before device deployment and onboarding.

▫ During network deployment, the administrator plans the network topology

by entering device ESNs and specifying stack members and aggregated
links on iMaster NCE-Campus.

▫ Alternatively, the administrator can import the preceding planning

information in batches using a template. Using a template to import data
in batches simplifies operations and is therefore recommended.

▫ Then, the administrator uses the recommended method to deploy and

onboard devices.

▫ After devices register with iMaster NCE-Campus, iMaster NCE-Campus

automatically checks whether the actual topology of the devices is the
same as the planned one. If cables are incorrectly connected during
installation, iMaster NCE-Campus immediately notifies the administrator.

• Note: Parameters can be planned for an Eth-Trunk interface. After a device is

onboarded, it automatically obtains the corresponding Eth-Trunk configuration.
• Automatic routing domain configuration: After this function is enabled, the
underlay network can be automatically configured. You can specify sites for
automatic routing domain configuration and specify OSPF routing parameters.
Currently, the following parameters are supported:

▫ Area: In the single-area scenario, all devices belong to Area 0. In the multi-
area scenario, border nodes belong to Area 0, and each edge node and its
connected border node belong to an area.

▫ Network type: You can set the OSPF network type to broadcast, P2MP, or
P2P.

▫ Encryption: You can set the encryption mode between adjacent devices to
HMAC-SHA256, MD5, or none.

▫ OSPF GR: You can enable OSPF GR.

• Before enabling the automatic routing domain configuration function, you need
to plan network resources required for underlay network automation.

▫ Underlay devices (corresponding network scope of the fabric) are

connected through VLANIF interfaces at Layer 3, and you need to assign a
VLAN to each interconnection link.

▫ The VLANIF interfaces for connecting devices are automatically assigned

interconnection IP addresses with a 30-bit subnet mask.
• Fabric network resource planning:

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

▫ Interconnection VLAN: When creating the external network resource for a

fabric, configure an interconnection VLAN to interconnect the fabric with
the egress network. When creating the network service resource on a fabric,
configure an interconnection VLAN to interconnect the fabric with the
network management zone.

▫ BD: BDs are used to create Layer 2 broadcast domains in a VN. Typically,
BDs have a one-to-one mapping relationship with service VLANs. Therefore,
a sufficient number of BD resources need to be planned to match the
number of service VLANs. The default BD range is 1-4095.

▫ VNI: VNIs are similar to VLAN IDs. They are used to identify VXLAN
segments and range from 1 to 4095 by default.
• In large- and medium-sized campus networks, the virtualization solution is
classified into the centralized gateway solution and distributed gateway solution
based on the user gateway location. You can select a gateway solution when
creating a fabric on iMaster NCE-Campus.

• In the centralized gateway solution, a border node functions as the gateway of

all users, and all inter-subnet traffic is forwarded by the border node. In the
distributed gateway solution, multiple edge nodes function as user gateways, and
inter-subnet traffic is forwarded through these edge nodes.
• When designing the CloudCampus network virtualization solution, first determine
the gateway solution to be used. Then you can perform end-to-end design for
the entire campus network based on the selected gateway solution.

• The centralized gateway solution supports only one border node, whereas the
distributed gateway solution supports multiple border nodes.
• An Ethernet Network Processor (ENP) card is embedded with the Huawei-
developed ENP. The card can function as a common LPU to provide data access
and switching services and also as a WLAN AC to provide wireless access control
functions. In this way, the card achieves wired and wireless convergence.
• When the campus intranet needs to communicate with an external network, for
example, the Internet, data center, or another branch, traffic must pass through
the border node.
• There are three interconnection modes between the fabric network and egress
device:
▫ L3 shared egress:
▪ The external gateway connects to and accesses external networks via
VLANIF or VBDIF interfaces. VNs can access the public network or
private network specified by another site through the shared VRF
egress, and service traffic can be diverted to the firewall through the
shared VRF egress. When configuring a multi-border fabric, you can
configure multiple core devices in one external network.
▪ The L3 shared egress mode is applicable to the scenario where the
firewall does not need to perform security check on VNs, there are
low requirements on security control policies between VNs, and traffic
of all VNs is transmitted in the same security zone.
▪ To enable communication between VNs and external networks, you
must configure return routes to service subnets on the firewall. As a
result, service subnets of different VNs can communicate with each
other on the firewall. To isolate VNs on the firewall, configure policies
based on service network segments in the VNs.
▪ As shown in the figure, a shared VRF is created on the border node,
the shared L3 egress is bound to the VRF, and routes are configured
to enable the communication with external networks.
• Multiple network service resources can be created, or a network service resource
can have access addresses for multiple network service resources.

• When the border node is directly connected to a server:

▫ As shown in the figure, a VRF on the border node is allocated to each

network service resource. After a network service resource is selected during
VN creation, a static route pointing to the network service resource address
will be created on the border node, with the next hop being the network
service resource address.

• When the border node is directly connected to a switch:

▫ If the DHCP server, iMaster NCE-Campus, and other network service

resources are all deployed in the network management zone, the border
node communicates with these network service resources through the
directly connected switch (gateway) in the network management zone. If
only a small number of network service resources are deployed, it is
recommended that these resources be planned in the same network service
resource model. This saves interconnection VLAN and IP address resources
and simplifies route configuration in the network management zone.

▫ As shown in the figure, a VRF on the border node is allocated to each

network service resource. After a network service resource is selected during
VN creation, a static route pointing to the network service resource address
will be created on the border node, with the next hop being the address of
the gateway in the network management zone.
• "Fabric extended AP" and "Fabric extended switch": The two types of connections
are used to enable communication between the authentication control point and
authentication enforcement point through the policy association management
VLAN. In this scenario, the fabric extended switch functions as the authentication
enforcement point and can be connected to fabric extended APs and terminals.

• Terminal (PCs, phones, dumb terminals, and non-fabric extended access

switches/APs): If this type of interface is connected to a terminal, you can
associate an authentication profile specific to that terminal type with the
terminal based on the user authentication mode design in the access control
design. Binding the authentication profile facilitates access control of the
terminal.
• VN design:

▫ VNs are generally divided based on services on a campus network. An

independent service is assigned a VN, and VNs are isolated from each other
by default. For example, on a school campus network, guest, teaching, IoT,
and video surveillance services can each be assigned a separate VN. On an
enterprise campus network, office network services, production network
services, and R&D services can be allocated to different VNs.

• Policy design:

▫ Some isolation requirements caused by different user roles can be fulfilled

by deploying policy control technologies (such as free mobility).

▫ VNs are isolated by default. To enable mutual access between user groups
within a VN, additional VN interworking configuration is required.

• VN access design:

▫ Service data enters from a physical network to a VN through an edge node.

Service data of users enters different VNs depending on the VLANs to which
users belong. Therefore, during network design, you need to plan the
mappings between VLANs of physical networks and BDs of VNs, and
configure VLANs for wired and wireless users.
• Application scenarios:
▫ The static VLAN mode applies when terminals access the network at fixed
locations and do not need to be authenticated. This access mode is more
secure but lacks flexibility. When the locations of terminals change, you
need to configure static VLANs for them again.
▫ The dynamically authorized VLAN mode applies when terminals need to
access the network from any place and need to be authenticated based on
the VLAN information delivered during user authentication. This access
mode is flexible and the configuration does not need to be modified when
the locations of terminals change. Dynamic access is more automated, easy
to manage and use, and is therefore recommended.
• VN access design for wireless users:
▫ If distributed gateways are used and the border nodes have the native AC
function deployed, traffic of wireless users is forwarded to the native AC
through CAPWAP tunnels. After the native AC decapsulates CAPWAP
packets, the decapsulated packets enter different VNs depending on the
VLANs to which the wireless users belong.
▫ If centralized gateways are used and the border nodes have the native AC
function deployed, it is recommended that traffic of wireless users be
directly forwarded to the native AC through CAPWAP tunnels. After the
native AC decapsulates CAPWAP packets, the decapsulated packets enter
different VNs depending on the VLANs to which the wireless users belong.
The administrator needs to configure different VLAN ranges for wired and
wireless terminals. The VLANs of wired terminals are bound to BDs on the
edge nodes, whereas the VLANs of wireless terminals are bound to BDs on
the border nodes.
• Note: 802.1X authentication and MAC address authentication both support
dynamically authorized VLANs.
• Inter-VN communication can be implemented through a border node or an
external gateway.

▫ Through a border node

▪ If two VNs belong to the same security zone and have low security
control requirements, devices on the two VNs can directly
communicate with each other through a border node. In addition,
permission control can be implemented based on the free mobility
policy. To implement communication between VNs, the border node
needs to import their respective network segment routes that are
reachable to each other.

▫ Through an external gateway

▪ If two VNs belong to different security zones and have high security
control requirements, it is recommended that devices on the two VNs
communicate through an external gateway (a firewall) and that a
security zone policy be configured on the firewall for permission
control.
• Each VN corresponds to a VRF.

• Each VN corresponds to multiple subnets, and each subnet corresponds to a BD

and VNI.

• Traffic from a terminal enters the VN based on the VLAN to which the terminal
belongs.
• If 802.1X or MAC address authentication (Layer 2 authentication technologies) is
used, the authentication point must be on the same network segment as the user
host. It is recommended that the access device function as the authentication
point.

▫ If a large number of access devices are deployed, the aggregation or core

device needs to be deployed as the authentication point. You can also
deploy policy association. The gateway functions as the authentication
control point, and the access device functions as the authentication
enforcement point, thereby simplifying policy deployment.

• If Portal authentication is used, the authentication point can be deployed

anywhere as long as it is routable to the user host. Layer 2 Portal authentication
is recommended.
• An inter-group policy directly reflects whether two security groups can
communicate with each other. When planning an inter-group policy, simply set
the inter-group policy to permit or deny based on whether the two groups can
communicate with each other. The administrator can configure inter-group
policies through an intuitive policy control matrix on iMaster NCE-Campus. If no
inter-group policy is created between source and destination security groups, the
default policy between them is permit.

• Take the policy direction into account when planning inter-group policies.
Typically, packets are transmitted in two directions between two terminals.

▫ Huawei switches consider that traffic from A to B is unrelated to traffic

from B to A, so they match policies for the two types of traffic separately
and determine whether to forward the traffic based on the corresponding
policies. This means that a Huawei switch enforces policies on a packet by
considering only the source and destination security groups of that packet.
For example, the policy "A ->B permit, B -> A deny" means that all packets
sent from A to B will be permitted, whereas all packets sent from B to A
will be discarded, regardless of whether A or B initiates the access. The
default inter-group policy on a switch is permit.
• If an authentication point and policy enforcement point are deployed on different
devices, the IP-security group entries of authenticated users need to be pushed to
the specified policy enforcement point. To achieve this, the administrator needs
to configure IP-security group entry subscription, that is, specify to which policy
enforcement point the IP-security group entries of a certain network segment or
security group need to be pushed.
• L2 shared egress mode: The border node is not the user gateway, and the user
gateway is a device outside the fabric. The border node connects to the egress
device through a Layer 2 interface, and the user gateway is deployed on the
egress device for access to the external network.
• In this slide, "general scenarios" refer to authentication, non-authentication, and
dynamic/static IP address assignment scenarios.

• In non-authentication scenarios, iMaster NCE-Campus can display information

about wired terminals only after the ARP snooping function is enabled on access
devices.
• It is recommended that admission and authorization policies be automatically
delivered to dumb terminals (such as printers, IP phones, and IP cameras) based
on terminal types. This helps implement automatic service provisioning and plug-
and-play for dumb terminals.
• Control packets between an AC and AP are forwarded through a CAPWAP tunnel.
APs forward service packets of wireless users to the wired side in tunnel
forwarding (centralized forwarding) or direct forwarding (local forwarding)
mode.

▫ Tunnel forwarding:

▪ Application scenario: Service packets of wireless users are centrally

processed and forwarded by the AC.

▪ Advantages: The AC centrally forwards service traffic, ensuring high

security and facilitating centralized traffic management and control.

▪ Disadvantages: Service packets must be forwarded by the AC,

resulting in low forwarding efficiency and a heavy load on the AC.

▫ Direct forwarding:

▪ Application scenario: Service packets of wireless users are directly

forwarded without passing through the AC, saving link bandwidth
between the AP and AC.

▪ Advantages: Service packets are forwarded without passing through

the AC, which is efficient and reduces the load on the AC.

▪ Disadvantages: Service data is difficult to manage and control in a

centralized manner.

▫ The tunnel forwarding mode is recommended for the native AC solution.

• Description of the centralized gateway scenario:

▫ User gateway: border node

▫ Authentication point: edge node for wired users; border node (native AC)
for wireless users

▫ Forwarding model:

▪ Wired traffic: Traffic enters VNs through the edge node, and free
mobility policies are enforced on the edge node.

▪ Wireless traffic: Free mobility policies are enforced on the border

node. The tunnel forwarding mode is recommended. Traffic enters
VNs through the border node (native AC).

• Description of the distributed gateway scenario:

▫ User gateway: edge node for wired users; border node for wireless users

▫ Authentication point: edge node for wired users; border node (native AC)
for wireless users

▫ Forwarding model:

▪ Wired traffic: Traffic enters VNs through the edge node, and free
mobility policies are enforced on the edge node.

▪ Wireless traffic: Free mobility policies are enforced on the border

node. The tunnel forwarding mode is recommended. Traffic enters
VNs through the border node (native AC).
• Description of the centralized gateway scenario:

▫ User gateway: border node

▫ Authentication point: edge node for wired users; standalone AC for wireless
users

▫ Forwarding model:

▪ Wired traffic: Traffic enters VNs through the edge node, and free
mobility policies are enforced on the edge node.

▪ Wireless traffic: Free mobility policies are enforced on the border node
(the border node needs to subscribe to IP-security group entries). The
tunnel forwarding mode is recommended. Traffic enters VNs through
the border node (traffic is forwarded from the standalone AC to the
border node and then enters VNs).

• Description of the distributed gateway scenario:

▫ User gateway: edge node for wired users; border node for wireless users
when tunnel forwarding mode is used

▫ Authentication point: edge node for wired users; AC for wireless users
• To ensure reliability, routers and firewalls are usually deployed in redundancy
mode. It is recommended that devices be deployed in redundancy mode at the
egress of a large- or medium-sized campus network.

• WAN-side connection design:

▫ Egress link type

▪ Ethernet: Select routers (NE or AR series) or firewalls as egress

devices.

▪ For non-Ethernet links, such as EI, CE1, and CPOS links, select routers
as egress devices.

▫ SD-WAN requirements:

▪ If there are SD-WAN requirements, select AR routers as egress

devices.

▪ If there is no SD-WAN requirement, select firewalls or NE routers as

egress devices.

▫ Protocol interconnection requirements:

▪ If BGP runs between egress devices and external networks, it is

recommended that routers be used as the egress devices. This is
because routers have a larger number of routing table entries and
higher performance and many routing policies need to be deployed
on egress devices.
• Routes for the traffic from intranet users to the Internet:

▫ [Border] ip route-static vpn-instance vpn1 0.0.0.0 0 10.11.0.1

▫ [vsys1] ip route-static 0.0.0.0 0 public

▫ [FW] ip route-static 0.0.0.0 0 1.2.3.4

• Return route:

▫ [vsys1] ip route-static 10.11.0.0 24 10.11.0.254

▫ Note: No return route needs to be configured for the return traffic in the
public system. After a return packet matches the session table in the public
system, the packet is directly forwarded to vsys1 for processing.
• Routes for the traffic from intranet users to the Internet:

▫ [Border] ip route-static vpn-instance vpn1 0.0.0.0 0 10.11.0.1

▫ [vsys1] ip route-static 0.0.0.0 0 public

▫ [FW] ip route-static 0.0.0.0 0 10.10.0.254

• Return routes:

▫ [Border] ip route-static 10.11.0.0 24 10.10.0.1

▫ [vsys1] ip route-static 10.11.0.0 24 10.11.0.254

▫ Note: No return route needs to be configured for the return traffic in the
public system. After a return packet matches the session table in the public
system, the packet is directly forwarded to vsys1 for processing.
• On a virtualized campus network, when the user gateways are located inside the
fabric, each Layer 3 egress interface for connecting the fabric to an external
network corresponds to a Layer 3 logical interface on the firewall. Each logical
interface can be bound to a security zone. If the user gateways are located
outside a fabric, you need to bind the gateways to security zones based on the
security policies of these gateways.

• Most security policies are implemented based on security zones. Each security
zone identifies a network, and a firewall connects networks. Firewalls use security
zones to divide networks and mark the routes of packets. When packets travel
between security zones, security check is triggered and corresponding security
policies are enforced. Security zones are isolated by default.
• As shown in the figure, after security policies are configured, VNs on the intranet
can communicate with each other, and the external networks can access servers
in the DMZ. In addition, different security protection policies can be applied to
traffic in different security zones.
• On a traditional campus network, the intranet is often considered secure, and
threats mainly come from external networks. Firewalls are often deployed to
ensure security on campus borders. As security challenges increase, border
defense at the egress cannot meet requirements. The security model needs to
shift from passive into proactive and the security scope needs to be expanded
from external networks to the intranet to solve security problems from the
source (terminals), improving enterprise-wide information security level.
• Security measures:
▫ Enable traffic suppression and storm control.
▪ Control broadcast, multicast, and unknown unicast packets to prevent
broadcast storms. Traffic suppression limits the traffic using the
configured threshold, and storm control blocks the traffic by shutting
down interfaces.
▫ Enable DHCP snooping and configure uplink interfaces as trusted interfaces.
▪ DHCP snooping defends against bogus DHCP server attacks, DHCP
server DoS attacks, bogus DHCP packet attacks, and other DHCP
attacks. DHCP snooping allows administrators to configure trusted
and untrusted interfaces, so DHCP clients can obtain IP addresses
from authorized DHCP servers. A trusted interface forwards the DHCP
packets it receives, whereas an untrusted interface discards the DHCP
ACK packets and DHCP Offer packets received from a DHCP server.
▪ An interface directly or indirectly connected to the DHCP server
trusted by the administrator needs to be configured as a trusted
interface, and other interfaces are configured as untrusted interfaces.
This ensures that DHCP clients obtain IP addresses only from
authorized DHCP servers and prevents bogus DHCP servers from
assigning IP addresses to DHCP clients.
▫ Enable IPSG and DAI.
▪ IPSG prevents unauthorized hosts from using IP addresses of
authorized hosts or specified IP addresses to access or attack the
network.
• Wireless air interface security design:

▫ The Wireless Intrusion Detection System (WIDS) can detect rogue and
interfering APs, bridges, and STAs, as well as ad-hoc devices.

▫ The Wireless Intrusion Prevention System (WIPS) can disconnect authorized

users from rogue APs, disconnect rogue and interfering devices from the
WLAN, and contain such devices.

▫ Attack detection: The WIDS and WIPS can also detect attacks such as flood
attacks, weak initialization vector (IV) attacks, spoofing attacks, brute force
WPA/WPA2/WAPI pre-shared key (PSK) cracking, and brute force WEP
shared key cracking in a timely manner. The two systems then record logs,
statistics, and alarms to notify network administrators of such attacks. The
WLAN device adds devices that initiate flood attacks and brute force key
cracking attacks to the dynamic blacklist and rejects packets from such
devices within the aging time of the dynamic blacklist.

▫ PMF: Management frames on a WLAN are not encrypted, which may cause
security problems. The PMF standard is released by the Wi-Fi Alliance based
on IEEE 802.11w. It aims to apply security measures defined in WPA2 to
unicast and multicast management action frames to improve network
trustworthiness.
• Service category examples:

▫ Network protocols: STP, OSPF, IGMP, etc.

▫ Management protocols: ICMP, SNMP, Telnet, etc.

▫ Voice signaling: signaling protocols such as SIP, H.323, H.248, and Media
Gateway Control Protocol (MGCP).
• Service category examples:

▫ Gaming: for example, online games that transmit operation instructions

through RTP or UDP, which poses higher requirements on the network.

▫ Low-latency data services: for example, long delay on an online ordering

system may reduce the revenue and efficiency of enterprises.

▫ Large-volume data services: for example, FTP, database backup, and file
dump.

▫ Common services: for example, mail and web browsing.

▫ Low-priority services: for example, network applications irrelevant to work,

such as social networking and entertaining videos.
• Scheduling policy design for wired networks:

▫ Traffic identification at the access layer: Access switches function as

boundary switches. The switches identify, classify, and mark data flows at
the user side. In actual deployments, different interfaces on access switches
are connected to different terminals, and different priorities can be
allocated to different services on the access switches. Then traffic of the
services can be scheduled based on the priorities.

▫ DiffServ deployment at the aggregation or core layer: Interfaces on

aggregation and core switches are configured to trust DSCP or 802.1p
priorities and enforce QoS policies based on priorities marked at the access
layer. This ensures that high-priority services are scheduled first. A switch
interface trusts 802.1p priorities by default.

▫ Bandwidth control on the egress device: Egress devices are also located in
the DiffServ domain and are configured to trust DSCP or 802.1p priorities of
packets and implement QoS policies. Due to egress bandwidth limits, you
need to consider differences when setting bandwidth parameters for WAN
interfaces of egress devices. Additionally, QoS policies of egress devices vary
according to the enterprise WAN construction mode.
1. ADF
• Managed service provider (MSP): delivers and manages network-based services,
applications, and devices. The serviced objects include enterprises, residential
areas, and other service providers.

• Perpetual license + SnS: The perpetual license is sold together with SnS services,
such as software patches, software upgrades (including new features of new
releases), and remote support. In the perpetual license + SnS mode, a customer
needs to pay SnS fee for a certain period of time, in addition to purchasing the
license upon the first purchase. If the customer does not renew the SnS annual
fee after it expires, the customer can only use functions provided in the license
for the current version and cannot use the service functions covered in the SnS
annual fee.

• SaaS mode: MSPs are responsible for deploying or leasing hardware

infrastructure, and O&M and management of the hardware and software.
Software is provided for customers as cloud services and customers need to
periodically pay for the cloud services.

• Term Based License (TBL) mode: This mode differs from the perpetual license +
SnS mode in that the licenses purchased by customers have limited validity
periods. If a customer does not renew the subscription after the license expires,
the customer can no longer use the software product.

• SnS: refers to Subscription and Support. It consists of two parts: software support
and software subscription. The complete software charging mode consists of the
annual software SnS fee and software license fee.

• Note: This course uses the on-premise deployment as an example.

• On a fabric, VXLAN tunnel endpoints (VTEPs) are further divided into the
following roles:

▫ Border: is a physical network device and provides data forwarding between

the fabric and external networks. In most cases, VXLAN-capable core
switches function as border nodes.

▫ Edge: is a physical network device. Access user traffic enters the fabric from
an edge node. Generally, VXLAN-capable access or aggregation switches
function as edge nodes.
• Note: In this lab, the native AC is deployed on the border node to manage APs.
The border node also serves as the DHCP server to allocate IP addresses to APs.
• Policy Control Matrix:

▫ Sales personnel and marketing personnel cannot communicate with each

other. Only marketing personnel using wired terminals and R&D personnel
can communicate with each other.

▫ R&D personnel cannot access the E_mail resource group.

▫ In the policy control matrix, only the communication that is allowed should
be permitted and other communication should be denied.
• VXLAN-based large- and medium-sized virtualized campus networks have
complex services. Therefore, the deployment process is complex. The deployment
process provided in this slide is the general process for you reference.

• The following part of this course focuses on key operations in the deployment
process.
• When creating sites, pay attention to the following points:

▫ To facilitate device management and improve service deployment

efficiency, add devices on the same network of a tenant to the same site.

▫ You can create sites on iMaster NCE-Campus for unified O&M

management. Two methods are available to create sites:

▪ Create sites one by one: You can create sites one by one when a small
number of sites need to be added.

▪ Create sites in a batch: You can create sites in a batch when a large
number of sites need to be added.

• When adding devices, pay attention to the following points:

▫ On a VXLAN-based virtualized campus network, managed devices are

typically LSWs (switches) and ACs (wireless access controllers).

▫ To add devices manually, select By Model or By ESN.

▫ On large- and medium-sized virtualized campus networks, the WLAN

typically adopts the architecture of "AC + Fit AP". In this architecture, Fit
APs are centrally managed and configured by the native AC. After the
native AC is managed by iMaster NCE-Campus, you can be redirected from
iMaster NCE-Campus to the web platform of the native AC to manage Fit
APs.
• Device plug-and-play:

▫ Customer pain points: In traditional network deployment, engineers need to

commission network devices one by one onsite, resulting in heavy
configuration workload and low efficiency.

▫ Solution:

▪ This lab demonstrates the plug-and-play function of network devices

in the CloudCampus Solution. The DHCP Option solution is used to
implement plug-and-play of switches. In this example, the DHCP
service and related parameters must be preconfigured on AR3.

▪ In this step, switches on the campus network can be directly deployed

using factory settings and get managed by iMaster NCE-Campus,
greatly reducing the configuration workload.
• Parameters in the fabric global resource pool:

▫ VLAN: Configure a service VLAN pool when you need to configure VLANs
for connecting to external networks, VLANs for connecting to network
service resources, CAPWAP management VLAN, and terminal access VLANs.

▫ Bridge Domain (BD): On a VXLAN network, VNIs can be mapped to BDs in

1:1 mode so that a BD can function as a VXLAN network entity to transmit
traffic. A BD is a Layer 2 broadcast domain used to forward data packets on
a VXLAN network.

▫ VXLAN Network Identifier (VNI): A VNI is similar to a VLAN ID and

identifies a VXLAN.
• Parameters for configuring the underlay automation resource pool:

▫ Interconnection VLAN: Configure an interconnection VLAN pool when

border and edge nodes on a fabric need to communicate on the underlay
network.

▫ Interworking IP address: Configure an interconnection IP address pool when

border and edge nodes on a fabric need to communicate on the underlay
network.

▫ Loopback interface IP: If automatic routing domain configuration is

required on a fabric, configure an IP address pool for the loopback
interfaces.
• A fabric consists of core, aggregation, and access devices. An access device
supports access of different network services, reducing costs while improving
network device utilization.

• A virtualized campus network uses the overlay virtualization technology (VXLAN)

to create multiple virtual networks on the same fabric and allow flexible service
deployment.

• The networking type specifies the network deployment mode of a fabric:

▫ Centralized: The fabric uses a centralized gateway, which transmits traffic

accessing external networks and the intranet. In this networking mode, only
the border node can function as the centralized gateway.

▫ Distributed: The fabric uses distributed gateways. Traffic accessing external

networks and the intranet passes through different gateways. In this
networking mode, both border nodes and edge nodes can function as
gateways.

• iMaster NCE-Campus allows you to specify a BGP route reflector (RR) and
automatically deploy BGP EVPN configurations on all edge nodes in a fabric.

▫ AS number: specifies the BGP AS number used in a fabric.

▫ RR cluster ID: specifies the cluster ID of an RR. If there are multiple RRs in a
fabric, for example, if two RRs are configured on a dual-border network,
you need to configure a cluster ID for the RRs to prevent BGP routing loops.
The value is an integer ranging from 1 to 4294967295 or an IPv4 address.
• Role: specifies the role of a device in the fabric, including the border node, edge
node, and extended node. By default, the role of a device is an extended node.

• Route reflector: In a fabric, border devices are typically used as route reflectors,
which simplify full-mesh connections required by IBGP and reduce network and
CPU loads.
• Automatic routing domain configuration: After this function is enabled, the
underlay network is automatically configured. You can specify sites for automatic
routing domain configuration and specify OSPF route parameters. Currently, the
following parameters are supported:

▫ Domain: In single-domain mode, all devices belong to area 0. In multi-

domain mode, all edge nodes are located in their respective non-backbone
areas, and border nodes are interconnected through the backbone area
(area 0).

▫ Network type: You can specify the OSPF network type to broadcast, P2MP,
or P2P.

▫ Encryption: You can set the encryption mode between adjacent devices to
HMAC-SHA256, MD5, or None.

▫ Key: It refers to the authentication key ID used for ciphertext authentication

on an interface, and must be consistent with that of the peer device. The
value is an integer in the range from 1 to 255.

▫ Password: It specifies the ciphertext authentication key. The value is a

string of 1 to 255 characters and cannot contain spaces.

▫ Confirm password: You need to enter the ciphertext authentication key

again for confirmation.

▫ OSPF graceful: You can enable OSPF GR.

• After a fabric is created, the underlay network can be automatically deployed,
and configurations such as VLANIF interfaces, loopback interfaces, VTEP IP
addresses, and routes required for establishing a BGP EVPN can be automatically
provisioned. iMaster NCE-Campus allocates resources from the fabric global
resource pool and underlay automation resource pool to devices.
• Basic information:

▫ If Internet connection is enabled, iMaster NCE-Campus uses a default

route to direct traffic to the corresponding external network. If Internet
connection is disabled, you need to specify a route prefix.
• Interconnection information:

▫ Select the border device to be connected to the external network, and

select the interconnection interface, interconnection IP address, and
interconnection VLAN.

▫ Note: The configured interconnection IP address cannot conflict with IP

addresses in the underlay automation resource pool. The configured
interconnection VLAN belongs to the global resource pool of the fabric.

• Routing information:

▫ After you click Apply, iMaster NCE-Campus creates a static route to the
external network for the border device. (The static route is delivered to the
border device only when the external network is invoked by the virtual
network.)
• Server configuration:

▫ Server type: server resource specified by the network service resource. In

this example, the defined network service resource are a DHCP server and a
E-mail server.

▫ DHCP server: IPv4 and/or IPv6 address of a DHCP server.

▫ Server interconnection address pool: If an IPv6 address pool is configured

for the DHCP server, this parameter is mandatory. If only an IPv4 address
pool is configured for the DHCP server, this parameter is optional.
• Device configuration:

▫ If Directly connected to a switch is selected, the border node adds the

interconnection port to the interconnection VLAN in tagged mode to
connect to network resources. If Directly connected to a server is selected,
the switch adds the interconnection port to the interconnection VLAN in
untagged mode.

▫ Interconnection device: Select the border node (Border). The device

functions as a border node that connects the fabric to the external network
service resource.

▫ Interconnection port: Select the port used by the border node to connect
to the network service resource.

▫ Interconnection VLAN: Select the VLAN used by the border node to

connect to the network service resource.

▫ Interconnection IPv4 address: Select the IP address of the port used by the
border node to connect to the network service resource.

▫ Peer IPv4 address: Select the IP address of the peer device.

▫ Mask: Select the network mask.

• Note: The configured interconnection IP address cannot conflict with the IP

address in the underlay automation resource pool. The configured
interconnection VLAN belongs to the fabric global resource pool.
• Policy association:

▫ Configure the management VLAN and management IP address for policy

association.

▫ The configured management IP address cannot conflict with the IP

addresses in the underlay automation resource pool. The configured
management VLAN belongs to the global resource pool of the fabric.
• User access is configured on the access points of the current virtual network.

• Wired access: Users on the OA virtual network need to access the network
through ACC_1 and ACC_2 and they all need to be authenticated. Therefore, in
the wired access configuration, you need to select the interfaces on which
authentication has been enabled on the two switches.
• Wireless access: Select the border device in the wireless access configuration. The
border device is a switch that provides the native AC, through which it manages
APs and provides the wireless access service.
• When multiple policies are configured to control access from a source security
group to multiple destination groups, the sequence in which these policies are
matched can be determined based on the policy priority. For example, if the
destination groups are resource groups, in which case the destination IP
addresses may be the same, you need to manually adjust the policy priorities to
ensure that a specific policy is matched first.
• For example, when creating an account named kris (RD user), deselect Change
password upon next login. As this user belongs to the RD user group, which
does not require Portal authentication, deselect Portal in the Available login
mode area.
• After configuring authorization results, you need to bind the results to created
sites.

• iMaster NCE-Campus provides two default authorization results: permit access

and deny access. Once selected, the default authorization result takes effect for
all sites and cannot be modified or deleted.
• An authorization rule defines authorization conditions. A user that matches the
conditions can obtain the corresponding authorization result. That is, an
authorization result specifies the permissions that a user can be granted after the
user is authenticated successfully.

• iMaster NCE-Campus provides a default authorization rule named default, in

which the authorization result is deny access. The default authorization result can
be modified to allow the use of another authorization result.
• This example shows the wireless service configuration of sales personnel.
1. Create sites one by one or in a batch.

▫ Create sites one by one: This mode applies when a small number of sites
need to be added.

▫ Create sites in a batch: This mode applies when a large number of sites
need to be added.

2. ACD
• In this slide, CloudCampus Network refers to Huawei's CloudCampus Cloud-
Managed Network Solution for Small- and Medium-Sized Campus Networks.
• Huawei's CloudCampus Solution applies to three deployment scenarios: Huawei
public cloud, MSP-owned cloud, and on-premises. The on-premises scenario
applies to large- and medium-sized campus networks. The Huawei public cloud
and MSP-owned cloud scenarios apply to small- and medium-sized campus
networks. This document focuses on the Huawei public cloud scenario, which is a
cloud management scenario.

• Huawei's CloudCampus Solution for small- and medium-sized campus networks

uses cloud computing technology to implement automatic and centralized
network management, and provides data collection and analysis capabilities that
are unavailable on traditional networks, so as to achieve network (LAN/WLAN)
as a service (NaaS).

• There are three layers in the architecture of Huawei CloudCampus Solution for
small- and medium-sized campus networks: multi-tenant network, cloud
management platform, and value-added SaaS platform.

• Multi-tenant network: It consists of over one hundred network devices, including

APs, switches, firewalls, and ARs, and is deployed at the customer side to provide
user access.
• ServiceTurbo-Cloud (https://serviceturbo-cloud.huawei.com/) is an enterprise tool
service cloud platform. It provides one-stop tool services for Huawei, partners,
and customer service engineers in government and enterprise service scenarios.
• AS-IS: the current status

• TO-BE: future ideal status

• Efficiently supports WLAN network planning:

▫ No installation: Cloud-based tool, without the need of software installation.

▫ All-scenario: All scenarios supported, including indoor, outdoor, agile

distributed, and high-density scenarios.

▫ Efficient: Improved simulation efficiency when compared with the

traditional standalone deployment.

▫ High quality: Supports tens of thousands of WLAN projects.

• The public cloud management mode can be Huawei public cloud management
mode or MSP-owned cloud management mode. The two modes are essentially
the same. The only difference lies in the operational entity and the provider that
offers cloud management services.

• Unless otherwise specified, the Huawei public cloud management mode is used
as an example in this document.
• With certain IT capabilities, a tenant administrator can deploy and maintain a
campus network. This scenario is called tenant-managed construction and
maintenance. The tenant administrator is the main implementer, and the MSP
administrator only provides simple deployment assistance. The tenant
administrator can apply to the MSP for the managed construction and
maintenance services. After being authorized, the MSP constructs and maintains
the campus network for the tenant. This scenario is called MSP-managed
construction and maintenance, in which the MSP administrator is the main
implementer.

• The following lists the differences between the deployment processes in the
tenant-managed construction and maintenance and MSP-managed construction
and maintenance scenarios:

• Tenant-managed construction and maintenance:

▫ The tenant administrator installs cloud managed devices onsite and

registers the cloud managed devices.

▫ The tenant administrator logs in to iMaster NCE using their own account
and deploys services.
• For small- and medium-sized campus networks, the co-termination licensing
model is recommended, facilitating device management and operations. If the
license validity periods of devices of different types need to be precisely
controlled, use the non-co-termination licensing model.
• Hub-spoke: Generally, the enterprise headquarters or DC functions as a hub site.
Each branch site of an enterprise can communicate with the hub site and can
communicate with other branch sites through the hub site. This model is
applicable to scenarios where traffic between all branch sites of an enterprise
must pass through the headquarters for centralized security monitoring.

• Full-mesh: All sites of an enterprise can communicate with each other. If traffic
needs to be transmitted between the headquarters and branches or between
branches, data is directly exchanged without traversing an intermediate node.
This model is applicable to scenarios where all sites of an enterprise need to
directly access each other. This model eliminates the delay caused by traffic
transmission through the headquarters.

• Partial-mesh: Most sites of an enterprise can directly communicate with each

other. However, the underlay WAN networks of a small number of sites cannot
directly communicate with each other. For example, in the figure, branch 1 and
branch 3 need to communicate with each other through the headquarters.
• Cloud management for small- and medium-sized campus networks applies to
small- and medium-sized enterprises (SMEs) and branches, such as shopping
malls/supermarkets, retail stores, hotels, educational institutions, and financial
services organizations. Different networking models are used based on different
network scales.
• Device reliability: Fixed-configuration devices are generally used on small- and
medium-sized campus networks.

• Device reliability design includes the following two aspects:

• Redundant components are used to improve device reliability.

▫ In addition to selecting devices with high reliability, you can further improve
the reliability of the devices by using dual power supplies or redundant
components (e.g. boards).

• Joint networking is used to provide device reliability.

▫ Multiple devices are deployed together to improve device reliability, for

example, active/standby or stacking.

▫ Two devices are deployed in the egress zone of the campus network to
work in active/standby mode. Currently, in a two-node system, firewalls
support only the hot standby mirroring mode. ARs support dual-CPE
networking, and the two devices and two egress links can work
concurrently.

▫ Intranet network devices, such as LAN switches at the core or aggregation

layer, are stacked to implement device-level backup. Currently, only
switches can be stacked.
• The multi-campus network interconnection solution is a sub-solution provided in
the CloudCampus Solution for the interconnection between branch campuses and
between branches and the HQ or DCs. With the SD-WAN solution integrated, the
multi-campus network interconnection solution provides two models for WAN
interconnection: static IPsec VPN and EVPN.

• An IPsec VPN is a type of static VPN, in which IPsec tunnels are established
between devices at different sites to create VPN tunnels. Traffic is diverted to the
VPN tunnels based on the configured static routes so that services between sites
can be accessed through the VPN tunnels.

• An EVPN is a type of dynamic VPN that can establish tunnels between sites and
dynamically advertise routes on demand. EVPN establishes GRE tunnels between
sites to establish VPN tunnels and supports IPsec encryption on GRE tunnels to
ensure tunnel encryption security. In addition, the EVPN solution offers
application- and policy-based intelligent traffic steering, allowing high-quality
links to be selected based on applications and policies for data transmission.
• The single-layer network model is also called the flat network model. In this
model, WAN sites of an enterprise can be directly connected or connected
through one or more hub sites. Typically, this model is used by small- and
medium-sized enterprises as well as large enterprises with fewer than 100 sites.
The single-layer network model can be further classified into hub-spoke, full-
mesh, and partial-mesh.

• The hierarchical network model is applicable to large enterprises that span

multiple areas. In this model, the entire overlay network is divided into multiple
areas. Traffic between sites in different areas is forwarded through a border site.
The hub-spoke, full-mesh, or partial-mesh topology can be used in an area.
• Traditional network deployment requires the participation of engineering
installation personnel and network commissioning personnel. This results in long
installation and commissioning periods and slow service provisioning, and
consumes a large amount of manpower. The CloudCampus Cloud-Managed
Network Solution supports automated network deployment.
• A scenario template includes the following contents and functions related to
network deployment:

▫ Various networking modes: typical networking models of small- and

medium-sized campus networks.

▫ Automated DHCP server configuration.

▫ Dual uplinks (active/standby mode by default) on the firewall egress for

higher reliability.

▫ Automated Eth-Trunk configuration.

▫ Automated configuration of network services, including SSID, PSK password,

QoS, access authentication, traffic monitoring, and application monitoring.
• After WLAN signal coverage requirements are determined based on scenarios, AP
deployment can be planned using the WLAN Planner.

▫ This tool can be used to create network planning projects based on

drawings or Amap.

▫ This tool supports region settings, obstacle generation, automated or

manual AP deployment with one click, and WLAN signal coverage
simulation.

▫ This tool can generate network planning files and allows users to export the
files. Users can import network planning results on the tenant management
page of iMaster NCE to display AP locations and help tenants install APs.

▫ CampusInsight allows users to import network planning files. After network

deployment, users can view the actual signal heatmap of the network.
• SSIDs are used to represent WLANs. They are WLAN names displayed on a STA
such as a mobile phone when you search for WLANs available for access on the
STA. You can select an SSID to access the corresponding WLAN.

• Generally, SSIDs are planned based on user roles or services. Different

authentication modes, network access rights, and control policies can be
deployed for different SSIDs.

• Portal authentication can be used on open networks (for example, networks for
external user access). PSK or PPSK authentication can be used on semi-open
networks (such as guest room networks of hotels). 802.1X authentication can be
used on secure networks (such as office networks). MAC address authentication
can be used for dumb terminals such as printers.

• For an SSID that is not intended for end users, for example, the SSID planned for
printers and scanners, you can hide this SSID to prevent it from being detected by
end users.
• Definition of Layer 2 roaming: When a STA moves between APs, the STA
smoothly switches from the original AP to a new AP. This process is called
roaming. The SSID, service VLAN, and gateway of the STA remain unchanged
before and after roaming.

• Implementation of Layer 2 roaming:

▫ Roaming neighbor: An AP detects neighboring APs at the same site through

the air interface. If SSIDs of the APs are the same as that of the local AP,
and they can detect each other, these APs are considered roaming
neighbors of the local AP. (An AP can establish a maximum of 64 roaming
neighbors.).

▫ Each AP establishes a wired CAPWAP tunnel (control plane tunnel) with a

roaming neighbor to transmit roaming information.

▫ The establishment of roaming neighbors is irrelevant to the calibration

group. The calibration group is divided based on the management VLAN.
Layer 2 roaming neighbors are established based on whether service VLANs
are the same.
• Design points of Layer 3 roaming

▫ Layer 3 roaming traffic will be detoured to the HAP. Therefore, a large

Layer 2 domain needs to be planned at the entrance of the entrance hall so
that the detoured traffic can be distributed to different APs during roaming.

▫ Each AP supports up to 64 Layer 3 roaming STAs. When there are a large

number of Layer 3 roaming STAs, the roaming fails and the STAs need to
go offline and go online again. (In actual deployment scenarios, you are
advised to deploy Layer 2 roaming on the same floor or in the same area
based on the service VLAN planning.)
• A cloud AP is essentially a Fat AP and is independent of each other. Some WLAN
services, such as radio calibration, need to be processed centrally. However, no
WAC is deployed. To ensure high network reliability and performance and meet
local computing requirements, a global control role similar to a WAC is required.

• A leader AP is an AP with strong capabilities in an AP group. It is responsible for

global calibration of the entire group (automatically elected in a Layer 2 domain).

• The calibration region is automatically divided based on the management VLAN.

On a small network, a leader AP can manage all APs (no more than 128 high-
performance APs and no more than 50 low-performance APs). In this case, only
one management VLAN needs to be planned for APs.

• When the number of APs exceeds the management specifications of the leader
AP, you can divide multiple management VLANs to manage the network. You are
advised to plan management VLANs based on floors or physical continuous
coverage areas to ensure the continuity of the calibration regions.

• Port isolation cannot be configured on the uplink access switch of the cloud AP.
(The calibration group is negotiated through wired-side broadcasting.)
• During scheduled radio calibration, you can enable intelligent radio calibration
and use the analyzer to analyze historical data of the WLAN and predict
interference sources on the network. During network optimization, APs can avoid
possible interference sources on the network in advance to improve the quality of
the entire WLAN.

• During deployment, you are advised to perform manual calibration to

automatically plan the channels and power of APs after APs are deployed and go
online.
• Deployment mode recommendation:

▫ It is recommended that iMaster NCE functions as an authentication server

to implement authentication and policy control.

▫ If an enterprise has its own authentication server, the authentication server

can interconnect with a third-party server in proxy mode. In addition,
iMaster NCE can also implement user management and some policy
management functions.

▫ If an enterprise uses a third-party authentication server to provide the

access authentication function, the device that functions as an
authentication point can directly interconnect with the third-party
authentication server.
• Open capabilities at all layers, for all services, and in all scenarios help MSPs, VAS
application partners, and customers quickly implement system interconnection,
service convergence, and data monetization.
1. ABC

2. B
• Customer benefits: The transformation is to improve efficiency by using
algorithms. With scenario-based continuous learning and expert experience,
intelligent O&M frees O&M personnel from complex alarms and noises, making
O&M more automatic and intelligent.
• ProtoBuf: Protocol Buffers
• SaaS: software as a service
• IaaS: infrastructure as a service
• RSSI: Received Signal Strength Indicator
• KQI: key quality indicator
• Wireless Network Health Evaluation Model:

▫ Access Experience

▪ Access success rate: Association/Authentication/DHCP success rate.

▪ Access duration: Association/Authentication/DHCP duration.

▫ Roaming Experience

▪ Roaming fulfillment rate: Roaming success rate/Roaming duration.

▫ Throughput Experience

▪ Signal and interference: STA signal strength and interference rate.

▪ Capacity fulfillment rate: Channel utilization/Number of users.

▪ Throughput fulfillment rate: Interference rate/Non-5G-prior access/Air

interface congestion fulfillment rate.

• Wired Network Health Evaluation Model:

▫ Device Environment: Fault of a device, board, fan, power supply, or file

system.

▫ Device Capacity: ARP/MAC/FIB entry capacity, ACL resources, storage

capacity.

▫ Network status: Intermittent port disconnection, port suspension, optical

module exception.

▫ Network performance: Port congestion, queue congestion, port error

packets.
• CampusInsight provides professional evaluation report services. Specifically,
network quality evaluation reports on the network overview, indicator details,
and rectification suggestions are generated in real time or periodically. These
deliver measurable network experience.
• The service topology collects statistics on the status, access, congestion, and error
packet issues, displays the number of clients and traffic volume based on sites,
regions, buildings, and floors. This allows administrators to quickly search for and
view the buildings that users pass by, helping administrators quickly identify
campus network issues.

• In the Service Topology of CampusInsight, you can access WLAN Topology to

view the radio heat map of the network.
• The Spectrum Analysis tab page displays the channel status and surrounding
interference of APs, including the channel utilization, current working channel,
historical trend of channel status, non-Wi-Fi interference sources, Wi-Fi
interference sources, and Wi-Fi interference source distribution, facilitating device
status analysis.

• The spectrum analysis process is as follows:

1. APs scan all channels in real time, including co-channel interference, non-
Wi-Fi interference, and normal usage ratio of channels.

2. The APs report channel scanning data to CampusInsight.

3. CampusInsight monitors the status of all channels by AP in real time and

allows administrators to view the historical trend chart, non-Wi-Fi
interference source types, and RSSI.
• Note: Intranet servers are required for testing the intranet speed, intranet file
download rate, and video experience.
• CampusInsight provides comparison reports of networks built by different
vendors, comprehensively evaluate the overall user experience of Wi-Fi networks,
analyze network issues, and provide network optimization guidance.

• Zero-cost rapid deployment:

▫ Network reachability can be tested.

▫ Analysis reports are immediately generated.

• Note: The process of viewing wired user experience visibility is the same as that
of viewing wireless user experience visibility.
• Note: The procedure for locating wired access problems is the same as that for
locating wireless access problems.
• Use Case Benefits:

▫ Using protocol tracing, CampusInsight can analyze the protocol interaction

details in the three phases (association, authentication, and DHCP) for a
client to access the wireless network in a fine-grained manner, and provide
root causes and rectification suggestions. This facilitates the resolution of
connection issues.
• Application analysis:

▫ Application analysis monitors network-wide applications and supports

NetStream and service awareness (SA) data sources. This module displays
overview data such as the number of applications and traffic, and sorts
applications by traffic in ascending or descending order. In wired scenarios,
SA can be configured only on access switches, and the incoming and
outgoing traffic displayed on the page is the incoming and outgoing traffic
over the data reporting devices.

• eMDI: Enhanced Media Delivery Index

• RTP: Real-time Transport Protocol

• iPCA: Packet Conservation Algorithm for Internet

• The application details page displays the application experience awareness and
poor-QoE analysis.

▫ The Metric Overview area displays the average packet loss rate, average
jitter, disorder rate, packet rate, and byte rate of the session.

▫ If the device role is correctly set on the resource side and LLDP is enabled,
the Analysis and Demarcation area displays the full link topology of the
session from the initiator to the responder. You can view devices such as
APs, switches, and ACs that the session passes through. When a device is
faulty, the device is marked in red and displayed as a poor-quality device.

▫ Application quality and air interface: You can click a device to view the
performance metrics of the device and its interface or air interface in the
session.

▪ The device metrics include the MOS value, packet loss rate, maximum
number of consecutively lost packets, jitter, disorder rate, and
deterioration time ratio.

▪ The metrics of an interface or air interface include the signal strength,

channel utilization, interference rate, latency, and retransmission rate.

• MOS: Mean opinion score. It is used to measure quality of voices, especially

voices over the Internet, at the line termination.
• Use Case Benefits:

▫ Application quality awareness and fault demarcation allow administrators

to view the quality of specific application flows. If an application encounters
a poor-QoE issue, the system can directly demarcate the issue. If the issue
occurs inside the campus network, and we could troubleshoot it based on
the packet loss location. If the issue occurs outside the campus network,
who is responsible can be clarified.
• The statistics of the "Number of Clients & Authentication Failure Ratio”:

▫ Noise reduction for abnormal terminals: The authentication failure rate

increases sharply in some time periods. The analysis result shows that the
abnormal terminals initiate a large number of authentication requests, and
the failure rate is 100%. This issue is not caused by network faults, and
noise data needs to be removed. (The client revisit shows that these clients
are new employees and the terminals are not installed with Huawei Wi-Fi
certificate. In this manner, frequent re-authentication causes a large
number of failure events.)

▫ Intelligent identification of issues with a large number of failed clients and

a large failure rate: When the number of wireless access users increases
sharply at 6:00 a.m., the authentication failure rate reaches 30%. (The
RADIUS server cannot respond to authentication requests in a timely
manner due to its limited performance.) This is a typical issue with a large
number of failed clients and a large failure rate, indicating that a group
fault occurs.

▫ Connection failure but not a fault: Due to the instability of wireless client
access (for example, when a client moves or passes through a coverage
hole), the user authentication failure persists in each time segment, but
does not affect user experience. The fault is rectified after the user
automatically accesses the network again.
• Use Case Benefits:

▫ Due to factors such as signal coverage, obstacles in physical environments,

and radio interference, user access failures persist on the wireless network.
CampusInsight analyzes client access data to identify abnormal clients and
eliminate invalid failure events. In addition, CampusInsight uses the
machine learning algorithm to intelligently identify issues with a large
number of failed clients and a large failure rate, accurately identify group
connection faults on the network in a timely manner, and provide proper
rectification suggestions based on expert experience.
• Use Case Benefits:

▫ Weak-signal coverage issues easily occur on Wi-Fi networks due to

improper network planning and configuration. Such issues lead to poor RSSI
of clients and deteriorate Wi-Fi experience. Using weak-signal coverage
issue analysis, CampusInsight can automatically identify weak-signal
coverage issues, analyze data such as the RSSI and radio power, and
provide possible causes and rectification suggestions.
• Use Case Benefits:

▫ High interference issues easily occur on Wi-Fi networks. These issues affect
user experience and cause problems such as long network delay and
congested network access. As a result, user experience on the Wi-Fi network
deteriorates. Using correlation analysis and big data analytics,
CampusInsight can detect high interference issues on the network, find the
most possible causes, and provide rectification suggestions.
• Key Technologies:

▫ To improve network reliability, redundant devices and links are usually used
on an Ethernet switching network. However, due to network adjustment,
configuration modification, upgrade, and cutover, data or protocol packets
are often forwarded in a ring, which inevitably leads to loops.

▫ Topology-based loop path display: Restores the loop path of a Layer 2 loop
based on the switch neighbor relationship.
• Use Case Benefits:

▫ The Layer 2 loop issue function of CampusInsight proactively detects Layer

2 loops on the network, restores the loop topology based on switch link
information, and locates the loop location.
• Issue Identification:

▫ Outlier detection algorithm typical scenario: The negotiated rate supported

by a terminal is different from that supported by the switch port connected
to the terminal. As a result, the bit error rate of the port is significantly
higher than that of other switch ports.

▫ Time series anomaly detection algorithm typical scenario: Aged physical

components such as Ethernet cables and RJ45 connectors can cause the bit
error rate to gradually and continuously increase over a long period of time.

• Root cause analysis

1. Check whether error packets are caused by inconsistent configurations

(such as the negotiated rate) at both ends of a link.

2. Guide customers to test port cables in order to figure out whether error
packets are caused by cable aging or internal crosstalk.
• Use Case Benefits:

▫ CampusInsight continuously monitors the number of error packets on ports,

detects any substantial increase in error packets based on the dynamic
baseline, and automatically generates corresponding issues. This approach
accurately identifies error packet issues on the network in a timely manner,
and provides expert suggestions.
• Root cause analysis:

▫ When the port alternates between Up and Down states, the negotiated rate
of the port changes multiple times. As a result, the port repeatedly
performs rate negotiation, causing intermittent disconnection.

▫ Troubleshooting suggests that the virtual-cable-test command is run to

check the Ethernet cable connected to the port. The command output
indicates that the Ethernet cable has only 4 wires in 2 pairs. (A typical
Ethernet cable has 8 wires in 4 pairs.) As a result, the port rate changes,
causing intermittent disconnection. A further check indicates that the RJ45
connector of the Ethernet cable is faulty. The fault is rectified after the RJ45
connector is remade.

• Use Case Benefits:

▫ CampusInsight continuously monitors the Down event of each port and can
accurately detect any intermittent port disconnection on the network in a
timely manner, providing expert suggestions.
• Simulation feedback: CampusInsight evaluates the radio score and the number of
APs waiting for calibration based on the radio and neighbor information of APs,
displays the calibration simulation effect through the AI algorithm, and provides
channel adjustment suggestions. The APs with this function must be deployed on
the floor.

• Intelligent radio calibration: Historical big data is analyzed using the AI algorithm.
Network devices periodically request big data and the analytics results based on
the calibration policy to implement intelligent radio calibration.
• Use Case Benefits:

▫ Using intelligent radio calibration, CampusInsight continuously collects

massive data of real clients, identifies high-load APs and edge APs through
AI algorithms, and provides decision-making data for differentiated system
optimization, enabling the network to follow clients.
• Note:

▫ This version supports only RSSI-based wireless location, and other location
methods are not supported.

▫ Wireless location is applicable only to indoor scenarios.

▫ Location accuracy: within 10 m, 60% of accuracy (independent RF scanning),

50% of accuracy (non-independent RF scanning); location delay: within 20s.

▫ Wireless location data can be stored for up to 7 days.

• CampusInsight supports the display of heat maps, terminal locations, and
walking paths.

▫ Displays the people distribution heat map based on the specified time
period.

▫ Displays the locations of all Wi-Fi-enabled terminals, the location of a

single user, and the walking path within a specified time segment.

▫ Supports terminal MAC address anonymization.

1. ABCD
• LAN

▫ A local area network (LAN) is a computer network that connects

computers, peripheral devices, databases, and other devices in a limited
geographical area (such as a campus, factory, or organization) within
thousands of meters.

• WAN

▫ WANs provide wider coverage than LANs and metropolitan area networks
(MANs). The communication subnet of a WAN mainly uses the packet
switching technology. The communication subnet of a WAN can use the
public packet switching network, satellite communication network, and
wireless packet switching network to interconnect the LANs or computer
systems in different areas for resource sharing.

▫ The Internet is the largest WAN in the world.

• Relationship between the LAN and WAN:

▫ A LAN is located in an area, whereas a WAN spans a larger area. For

example, the headquarters of a large company is located in Beijing, and its
branches are distributed all over the country. If the company connects all its
branches through a network, a branch is a LAN, and the company network
is a WAN.
• SLA is an agreement between the network service provider and the customer. It
defines terms such as service type, service quality, and customer payment.

• According to the SLA requirements, the service provider uses multiple

technologies and solutions to monitor and manage the network performance
and traffic so as to meet the requirements defined in the SLA and generate
reports about customers' network performance.
• SDH is a TDM system and a traditional circuit scheduling mode.

• The multi-service transport platform (MSTP) receives, processes, and transmits

TDM, ATM, and Ethernet services.

• WDM uses multiple lasers to transmit multiple beams of lasers with different
wavelengths over a single optical fiber. The transmission bandwidth of WDM
devices is high, and the live-network bandwidth can reach up to 8 Tbit/s.
• There are three types of inter-AS MPLS L3VPN solutions: Option A, Option B, and
Option C.

• Option A applies to small inter-AS MPLS L3VPNs. Option B applies to midsize and
large inter-AS MPLS L3VPNs. Option C applies to large or super-large inter-AS
MPLS L3VPNs.
• By service usage:

▫ Access VPN: enables mobile employees, remote office employees, and

remote small offices to establish private network connections with
enterprise intranet and extranet through a public network. There are two
types of access VPN connections: client-initiated and NAS-initiated.

▫ Intranet VPN: Intranet VPN is an extension or replacement of traditional

private lines or other enterprise networks to connect distribution points
within an enterprise through a public network.

▫ Extranet VPN: extends enterprise networks to suppliers, partners, and even

clients over a public network.

• According to the layers of tunnels in the OSI model:

▫ Layer 2 tunneling protocol: encapsulates PPP frames into a tunnel. Layer 2

tunneling protocols include the Point-to-Point Tunneling Protocol (PPTP),
Layer 2 Forwarding (L2F), and Layer 2 Tunneling Protocol (L2TP).

▫ Layer 3 tunneling protocol: Only Layer 3 packets are carried in a tunnel.

Existing Layer 3 tunneling protocols include Generic Routing Encapsulation
(GRE) and IPsec. IPsec includes the Authentication Header (AH) protocol
and Encapsulating Security Payload (ESP) protocol.
• VPDN is implemented by using a tunneling technology. That is, data of an
enterprise network is encapsulated in a tunnel for transmission. On an interface
between the source LAN and public network, the tunneling technology
encapsulates data as a payload in a data format that can be transmitted on a
public network. On an interface between the destination LAN and the public
network, it decapsulates data to extract the payload. The logical path through
which encapsulated data packets are transmitted on the Internet is called a
tunnel. To ensure that data is encapsulated, transmitted, and decapsulated
smoothly, the communication protocol is the core.

• VPDN provides three common tunneling technologies:

▫ Point-to-Point Tunneling Protocol (PPTP)

▫ Layer 2 Forwarding (L2F)

▫ Layer 2 Tunneling Protocol (L2TP)

• Intranet VPN mainly uses the following technologies:

▫ GRE

▫ GRE over IPsec

▫ DSVPN

▫ DSVPN IPsec
• GRE is a Layer 3 tunneling technology. A GRE tunnel is a virtual P2P connection
that transmits encapsulated data packets.

• The two ends of a GRE tunnel are tunnel interfaces which encapsulate and
decapsulate data packets. The tunnel interface that sends encapsulated packets is
called the tunnel source interface, and the one that receives these packets on the
peer end is called the tunnel destination interface.

• The packet encapsulation process in the figure is as follows:

▫ After receiving an IP packet, RTA's interface that connects to the enterprise

branch sends a packet to the IP protocol module.

▫ The IP protocol module checks the destination address in the packet header
to determine how to forward this packet. If the packet is destined for the
other end of the GRE tunnel, the IP protocol module sends the packet to
the tunnel interface.

▫ After receiving the packet, the tunnel interface encapsulates the packet
using GRE and delivers the packet to the IP protocol module.
• GRE encapsulates multicast data to allow data to be transmitted through GRE
tunnels. Currently, IPsec can encrypt only unicast data. If multicast data, such as
routing protocol, voice, and video data, needs to be transmitted over IPsec
tunnels, a GRE tunnel can be established to encapsulate multicast data, and then
IPsec encrypts the encapsulated packets. In this way, multicast data is encrypted
and transmitted in the IPsec tunnel.

• GRE over IPsec combines advantages of both GRE and IPsec. It enables a network
to support multiple upper-layer protocols and multicast packets, as well as
packet encryption, identity authentication, and data integrity check.

• GRE over IPsec encapsulates packets using GRE, and then IPsec.

• GRE over IPsec supports the following encapsulation modes:

▫ Tunnel mode

▫ Transport mode
• DSVPN resolves the following defects of GRE over IPsec:

▫ All traffic must pass through the hub.

▫ The hub configuration needs to be modified when a site is added.

▫ If spokes use dynamic addresses, problems may occur when P2P GRE is
deployed.
• SSL VPN is a VPN remote access technology based on SSL. Mobile users (referred
to as remote users in SSL VPN) can use SSL VPN to securely and conveniently
access enterprise intranets and intranet resources, improving work efficiency.

• Before SSL VPN is developed, VPN technologies such as IPsec and L2TP are used
to enable remote user access. However, these VPN technologies have the
following disadvantages:

▫ Remote users need to install specific client software on their terminals,

leading to difficult network deployment and maintenance.

▫ The IPsec or L2TP VPN configuration is complex.

▫ Network management personnel cannot perform fine-tuned control over

the remote users' access permission to enterprise intranet resources.
• Only one BFD session can be established in a data path. If different applications
need to use different BFD parameters on the same data path, use the BFD
parameters that can meet the requirements of all applications to configure a
unique BFD session and enable the status changes of the BFD session to be
reported to all the applications bound with the BFD session.
• Additionally, NQA measures the performance of different protocols running on
the network. This facilitates real-time collection of network performance
counters, such as the total HTTP connection delay, TCP connection delay, DNS
resolution delay, file transfer rate, FTP connection delay, and DNS resolution
error rate.
• TLP is short for Target Logical Port.

▫ TLPs are interfaces on the edge nodes of the network and provide the
following functions:

▪ Collect statistics about the packet loss rate and delay.

▪ Generate statistics, such as the number of packets sent and received,

volume of traffic sent and received, and timestamp.

▫ An In-Point-TLP collects statistics about service flows it receives. An Out-

Point-TLP collects statistics about service flows it sends.

• DCP is short for Data Collecting Point.

▫ DCPs are edge nodes on the network and provide the following functions:

▪ Manage and control TLPs.

▪ Collect the statistics generated by TLPs.

▪ Report the statistics to an MCP.

• After a packet enters an SAC-enabled device, the device determines whether the
corresponding application has been identified based on the 5-tuple information
carried in the packet. If the application has been identified, the device forwards
the packet at Layer 3 without identifying the application again. If the application
has not been identified, the device performs SAC application identification. The
device then processes the packet based on the SAC identification result and
forwards the packet at Layer 3. The SAC application identification process is as
follows: The device identifies an application based on the ACL rules defined in FPI.
If the application cannot be identified, the device identifies the application based
on the DNS entries defined in FPI. If the application still cannot be identified, the
device identifies the application based on the protocol and port mapping table
defined in FPI. If the application still cannot be identified, the device starts the SA
identification process.
• To meet SLA requirements of different services (such as audio, video, and data
services), the network is required to distinguish different communication modes
before providing corresponding QoS guarantee.

▫ For example, real-time services such as voice over IP (VoIP) demand a

shorter delay. A long delay for packet transmission is unacceptable. Email
and File Transfer Protocol (FTP) services are comparatively insensitive to
the delay.

▫ Conventional IP networks provide the best-effect mode, which cannot help

identify or differentiate the communication types on the network. The
capability of differentiating communication types is the prerequisite for
providing differentiated services. Therefore, the best-effect mode cannot
meet the requirements of the emerging applications. This is where QoS
comes in.

• QoS is designed to provide differentiated services based on application

requirements. For example:

▫ The bandwidth used by the FTP service on the backbone network can be
limited, and a higher priority can be assigned to database access.
• VoIP: voice over IP service

• IPTV: Internet protocol TV service

• HSI: high-speed Internet service

• Error control technologies are classified into forward error correction (FEC) and
backward error correction (BEC).

▫ Automatic repeat request (ARQ) is an on-demand retransmission

mechanism. The sender uses a "sending-acknowledgement" mechanism to
detect whether the receiver receives data packets. If the sender does not
receive any acknowledgment packet from the receiver, the sender
retransmits the corresponding packet. In this error correction mode, packets
need to be sent repeatedly. As a result, an extra delay is introduced. In this
mode, the sender retransmits packets to implement error correction. This is
why this mode is called BEC.

▫ In FEC, both FEC redundant packets and data packets are sent to the
receiver. If an error is found, the receiver directly restores the lost data
packets by using the FEC redundant packets. In this mode, error correction
is performed on the receiver. This is why this mode is called FEC.

▪ The error correction capability of FEC is limited. For example, if three

out of four packets are lost, FEC cannot restore these three packets
based on the remaining packet.
1. AC

2. A
• Description of fields in a GRE header:

Field Description
Checksum verification bit.
The value 1 indicates that the Checksum field is inserted into the GRE
C header.
The value 0 indicates that the GRE header does not contain the
checksum field.
Key bit.
The value 1 indicates that the Key field is inserted into the GRE header.
K
The value 0 indicates that the GRE header does not contain the
keyword field.
Number of layers where GRE packets are encapsulated. The value of
this field is increased by 1 after one GRE encapsulation is complete. If
Recursion the number of encapsulation layers is greater than 3, the packet is
discarded. This field is used to prevent packets from being encapsulated
continuously.
Flags Reserved field. The value must be 0.
Version Version. The value must be 0.
Type of the passenger protocol. A common passenger protocol is the
Protocol
IPv4 protocol, with the value of 0800.
Type
The protocol number of Ethernet over GRE is 0x6558.
Checksum Checksum of the GRE header and the payload.
Key Key used to authenticate the packet at the receive end.
• Keepalive detection functions as follows:

▫ After being enabled on the source end of a GRE tunnel, the source end starts a
timer to periodically send and count keepalive messages. The number of sent
keepalive messages increases by one each time a keepalive message is sent.

▫ The destination end sends a response message to the source end each time it
receives a keepalive message from the source end.

▫ If the source end receives a reply packet before the counter value reaches the
preset value, it considers the remote end reachable. If the source end does not
receive any response message before the counter reaches the preset value,
specifically, the retry count, the source end considers the peer end unreachable
and resets the counter. Then, the source end terminates the tunnel connection.
In this case, the source interface still sends Keepalive messages to the remote
interface. When the remote interface becomes Up, the source interface
becomes Up and sets up a tunnel with the remote interface.
• You can enable or disable checksum verification on both ends of a tunnel in
actual applications. If checksum verification is enabled on the local end and
disabled on the remote end, the local end does not check checksum values of
received packets, but checks checksum values of packets to be sent. If checksum
verification is disabled on the local end and enabled on the remote end, the local
end checks checksum values of received packets, but does not check checksum
values of packets to be sent.
• This field identifies traffic in a tunnel. Packets of the same traffic use the same
key. During packet decapsulation, GRE identifies data packets of the same traffic
based on the key. Packets will pass verification only when the two ends of the
tunnel use the same Key field. If packets fail the verification, they will be
discarded. Successful authentication requires that both ends are either configured
with the same Key field or not configured with the Key field.
• NAS
▫ A network access server (NAS) is maintained by an ISP and connects to a
dialup network. It is the nearest access point for PPP terminals. An NAS is
used on a traditional dialup network. An ISP deploys an LAC on an NAS to
provide L2TP services for remote dialup users and to establish tunnel
connections with the enterprise headquarters.
• LAC
▫ An L2TP access concentrator (LAC) provides PPP and L2TP processing
capabilities on a packet switched network. An LAC establishes an L2TP
tunnel connection with an L2TP network server (LNS) based on the user
name or domain name carried in PPP packets to extend PPP negotiation to
the LNS. Different networking environments can have different devices
functioning as an LAC.
▪ NAS-initiated scenario: On a traditional dialup network, an ISP deploys
an LAC on an NAS. Alternatively, on the Ethernet of an enterprise
branch, the ISP deploys a gateway for PPP terminals. The gateway
functions as both a PPPoE server and an LAC.
▪ L2TP client-initiated scenario: In an enterprise branch, an L2TP client
functioning as an LAC is configured on the gateway to initiate an L2TP
tunnel establishment request to an LNS. In this case, no dialup is
required in the remote system to trigger L2TP tunnel establishment.
▪ Client-initiated scenario: An employee on the go uses a PC or mobile
terminal to access the Internet and uses the L2TP dialup software on the
PC or mobile terminal. In this scenario, the PC or mobile terminal
functions as an LAC.
▫ An LAC can establish multiple L2TP tunnels to isolate data flows. That is, it
can carry multiple L2TP connections.
• Control message

▫ Control messages are used to establish, maintain, and tear down L2TP tunnels
and sessions. During the transmission of control messages, mechanisms such
as retransmission of lost messages and periodic detection of tunnel
connectivity are used to ensure the reliability of control message transmission.
Traffic control and congestion control on control messages are supported.

▫ Control messages are transmitted over an L2TP control channel. The control
channel encapsulates control messages with L2TP headers and transmits them
over an IP network.

• Data message

▫ Data messages are used to encapsulate PPP frames, which are transmitted
over tunnels, but such tunnels are unreliable. That is, a lost data message is
not retransmitted, and traffic control and congestion control on data
messages are not supported.

▫ Data messages carrying PPP frames are transmitted over unreliable data
channels. PPP frames are encapsulated using L2TP and then transmitted over
the IP network.
• Establishing an L2TP tunnel

▫ After receiving a PPP negotiation request from a remote user, the LAC sends
an L2TP tunnel establishment request to the LNS. The LAC and the LNS
exchange L2TP control messages to negotiate the tunnel ID and tunnel
authentication information. After the negotiation succeeds, an L2TP tunnel is
established between them and identified by the tunnel ID.

• Establishing an L2TP session

▫ If an L2TP tunnel exists, the LAC and the LNS exchange control messages to
negotiate the session ID. If no L2TP tunnel exists, the LAC and the LNS
establish an L2TP tunnel first. The L2TP session carries LCP negotiation
information and user authentication information of the LAC. After
authenticating such information, the LNS notifies the LAC of the session
establishment. The L2TP session is identified by a session ID.

• Transmitting PPP packets

▫ After the L2TP session is established, the PPP terminal sends data packets to
the LAC. The LAC encapsulates the L2TP packets based on information such as
the L2TP tunnel and session ID and sends the packets to the LNS. The LNS
decapsulates the L2TP packets and sends the packets to the destination host
based on the routing and forwarding table.
• Employees on the go may need to communicate with the headquarters and
access intranet resources of the headquarters at any time. Although they can
access the headquarters gateway through the Internet, the headquarters
gateway cannot identify and manage access users. To address this issue,
configure the headquarters gateway as an LNS, so that virtual point-to-point
connections can be established between the employees on the go and the
headquarters gateway when the employees use the L2TP dialup software on the
PC to initiate L2TP connections.
• An enterprise has some branches located in other cities, and its branches use the
Ethernet and have gateways deployed for branch users to access the Internet.
The headquarters provides access services for branches. VPDN connections need
to be established between branches and the headquarters gateway. Any branch
user is allowed to access the headquarters network, and only the branch
gateways need to be authenticated. In this case, the headquarters gateway
functions as the LNS, and the branch gateways function as the L2TP clients.
Virtual dialup is created on the branch gateways to trigger L2TP tunnel
connections to the headquarters network. A virtual point-to-point connection is
established between an L2TP client and the LNS. After IP packets of branch users
reach an L2TP client, the L2TP client forwards the packets to the virtual dialup
interface. The virtual dialup interface forwards the packets to the LNS, which
then forwards the packets to the destination host.
• An enterprise has some branches located in other cities, and its branches use the
Ethernet and have gateways deployed for branch users to access the Internet.
Headquarters users need to communicate with branch users, and the
headquarters uniformly manages access of branch users. Therefore, L2TP is used
to deploy the headquarters gateway as an LNS. Dialup packets of branch users
cannot be transmitted directly over the Ethernet. Therefore, PPPoE dialup
software needs to be deployed as a PPPoE client on the terminal that initiates the
dialup packets, and the branch gateway functions as a PPPoE server and an LAC
to forward call requests of branch users to the headquarters.
• The symmetric encryption algorithm is also called traditional cryptographic
algorithm, in which the encryption key can be calculated from the decryption key.
The sender and receiver share the same key, which is used for both encryption
and decryption. Symmetric key encryption is an effective method for encrypting a
large amount of data. There are many algorithms for symmetric key encryption,
and all of them aim to convert between cleartext (unencrypted data) and
ciphertext. Because symmetric key encryption uses the same key for data
encryption and decryption, data security depends on whether unauthorized users
obtain the symmetric key. If two communicating parties want to use the
symmetric key to encrypt data, they must exchange the key securely before
exchanging the encrypted data.

• An asymmetric algorithm is also called public key algorithm, in which a public

key is used for encryption and a private key for decryption. The two keys are
mathematically related. In public key encryption, the public key can be publicly
transmitted between two communicating parties or released in the public
repository, but the private key is confidential. The data encrypted using the public
key can be decrypted only using the private key. The data encrypted using the
private key can be decrypted only using the public key.
• IPsec technology supports multiple data encryption, authentication, and
encapsulation algorithms. When devices at both ends use IPsec for secure
communication, they must use the same encryption and authentication
algorithms. Therefore, a mechanism is required to help the devices negotiate
these parameters.

• An IPsec SA can be established in either of the following ways:

▫ Manual configuration: The management cost of manually established IPsec

SAs is high. This is because the encryption and authentication modes need to
be manually configured, SAs need to be manually updated, and SA
information permanently exists, resulting in low security. This mode applies to
small-scale networks.

▫ IKE negotiation: The management cost of IPsec SAs established through IKE
negotiation is low. The encryption and authentication modes are generated
using the Diffie-Hellman (DH) algorithm, SA information is generated
periodically, and SAs are dynamically updated. This mode applies to small-,
medium-, and large-sized networks.

• An SA is uniquely identified by three parameters: security parameter index (SPI),

destination IP address, and security protocol ID (AH or ESP).

• An IKE SA is used to establish a secure channel for exchanging IPsec SAs.

• IKE supports the following authentication algorithms including MD5, Secure Hash
Algorithm 1 (SHA1), SHA2-256, SHA2-384, SHA2-512, and Senior Middle 3
(SM3).

• IKE supports the following encryption algorithms: DES, 3DES, AES-128, AES-192,
AES-256, SM1, and SM4.

• ISAKMP is defined in RFC 2408, which defines the procedures for negotiating,
establishing, modifying, and deleting SAs and defines the ISAKMP message
format. ISAKMP provides a general framework for SA attributes and the methods
of negotiating, modifying, and deleting SAs, without defining the specific SA
format.

• ISAKMP messages can be transmitted using UDP or TCP through port 500. In
most cases, ISAKMP messages are transmitted using UDP.
• Integrity check value (ICV) is used by the receiver for integrity check. Available
authentication algorithms are MD5, SHA1, SHA2, and SM3.

• Common symmetric encryption algorithms used by IPsec include Data Encryption

Standard (DES), Triple Data Encryption Standard (3DES), Advanced Encryption
Standard (AES), and algorithms approved by State Cryptography Administration,
such as SM1 and SM4. DES and 3DES are not recommended because they are
insecure and pose security risks.

• Common authentication algorithms used by IPsec include MD5, SHA1, SHA2, and
SM3. MD5 and SHA1 are not recommended because they are insecure and pose
security risks.

• IPsec encryption cannot verify the authenticity or integrity of information after

decryption. IPsec uses the HMAC function to compare digital signatures to check
integrity and authenticity of data packets. In most cases, encryption and
authentication are used together. The IPsec sender uses the authentication
algorithm and symmetric key to generate a digital signature for the encrypted
packet and sends the IP packet and digital signature to the receiver. The receiver
uses the same authentication algorithm and symmetric key to process the
encrypted packet and then generates a digital signature. Then the receiver
compares the received and generated digital signatures to verify the data
integrity and authenticity. If the packet passes the verification, the receiver
decrypts it. Otherwise, the receiver discards it.
• AH provides only authentication but no encryption capabilities. According to the
AH protocol, an AH header is appended to the standard IP header in each packet.
The sender performs hash calculation on packets and an authentication key.
After packets carrying the calculation result arrive at the receiver, the receiver
also performs hash calculation and compares the calculation result with the
received calculation result. Any changes to the data during transmission will
make the calculation result invalid. This implements data origin authentication
and integrity verification. AH provides data integrity check on an entire IP packet.

• ESP provides both authentication and encryption. An ESP header is appended to

the standard IP header in each data packet, and the ESP Trailer and ESP Auth
data fields are appended to each data packet. In contrast to AH, ESP encrypts the
payload before encapsulating it into a data packet to ensure data confidentiality,
and protects the IP header only in tunnel mode.

• Key fields:

▫ Sequence Number: This field is a counter that monotonically increases from 1.

It uniquely identifies a packet to prevent replay attacks.

▫ SPI: This field uniquely identifies an IPsec SA.

▫ Authentication Data: This field contains the Integrity Check Value (ICV) and is
used by a receiver for data integrity check. Available authentication algorithms
are MD5, SHA1, SHA2, and SM3.
• In transport mode, an AH or ESP header is added between an IP header and a
transport-layer protocol (TCP, UDP, or ICMP) header to protect the TCP, UDP, or
ICMP payload. As no additional IP header is added, IP addresses in the original
packets are visible in the IP header of the post-encrypted packet.

• In tunnel mode, an AH or ESP header is added before the raw IP header and then
encapsulated into a new IP packet with a new IP header to protect the IP header
and payload.
• The IPsec mechanism is as follows:

▫ An IKE SA is negotiated in the first phase of IKE negotiation.

▫ The IKE SA is used to encrypt the packets in the second phase of IKE
negotiation. That is, IPsec SAs are negotiated in the second phase of IKE
negotiation.

▫ IPsec SAs are used to encrypt data.

• The main mode requires three exchanges between the peers, totaling six ISAKMP
messages. The three exchanges are described as follows:
▫ Messages 1 and 2 are used for IKE proposal exchange.
▪ The initiator sends one or more IKE proposals to the responder. The
responder searches for the first matching IKE proposal and then sends it to
the initiator. IKE proposals of the initiator and responder match if they have
the same encryption algorithm, authentication algorithm, authentication
method, and DH group identifier.
▫ Messages 3 and 4 are used for key information exchange.
▪ The initiator and responder exchange the DH public value and nonce value
to generate the IKE SA authentication key and encryption key.
▫ Messages 5 and 6 are used for identity and authentication information
exchange. (Both parties use the generated keys to exchange information.)
▪ The initiator and responder use the generated keys to authenticate each
other and the information exchanged in main mode.
• The aggressive mode uses only three messages. Messages 1 and 2 are used to
negotiate IKE proposals and exchange the DH public value, mandatory auxiliary
information, and identity information. Message 2 also contains the identity
information sent by the responder to the initiator for authentication. Message 3
is used by the responder to authenticate the initiator.
• Compared with the main mode, the aggressive mode reduces the number of
exchanged messages and speeds up the negotiation. However, the aggressive
mode does not encrypt identity information.
• In IKEv1 phase 2, two IPsec SAs are established through three ISAKMP messages:

▫ Message 1 is used by the initiator to send local security parameters and

identity authentication information to the responder.

▪ Security parameters include protected data flows and parameters to be

negotiated, such as an IPsec proposal. Identity authentication information
includes the keys generated in phase 1 and keying materials generated in
phase 2, and can be used to authenticate the peer again.

▫ Message 2 is used by the responder to send acknowledged security

parameters and identity authentication information, and to generate new
keys.

▪ The encryption key and authentication key used for secure data
transmission over IPsec SAs are generated based on the keys generated in
phase 1 and parameters such as the SPI and protocol. This ensures that
each IPsec SA has unique encryption and authentication keys.

▫ Message 3 is used by the initiator to send acknowledged information to

communicate with the responder. IKEv1 negotiation then ends and IPsec SAs
are established.
• Messages 1 and 2 are used in exchange 1 (called IKE_SA_INIT). In exchange 1,
IKE SA parameters are negotiated in plain text, including the encryption key,
authentication key, random number, and DH key. After IKE_SA_INIT is complete,
shared keying material is generated, from which all keys used by IPsec SAs are
derived.

• Messages 3 and 4 are used in exchange 2 (called IKE_AUTH). In exchange 2,

identities of the two parties and the first two messages are authenticated, and
IPsec SA parameters are negotiated. IKEv2 supports Rivest-Shamir-Adleman
(RSA) signature authentication, pre-shared key (PSK) authentication, and
Extensible Authentication Protocol (EAP) authentication. The initiator omits the
AUTH payload in message 3 to indicate that EAP authentication is required.
• The method of using routes has the following advantages:

▫ Simplifies the IPsec configuration: IPsec-protected data flows are routed to

tunnel interfaces, without the need to use ACLs to define the characteristics of
traffic to be encrypted or decrypted.

▫ Supports dynamic routing protocols.

▫ Protects multicast traffic through GRE over IPsec.

• GRE over IPsec supports encapsulation in both tunnel and transport modes. An
IPsec header needs to be added to packets if GRE over IPsec in tunnel mode is
used, resulting in longer packets. In this case, packets are more likely to be
fragmented. Therefore, GRE over IPsec in transport mode is recommended.

• In the IP header added during IPsec encapsulation, the source and destination
addresses are the IP addresses of the local interface and remote interface to
which an IPsec policy is applied.

• IPsec protects data flows from the GRE tunnel source to the GRE tunnel
destination. In the IP header added during GRE encapsulation, the source and
destination addresses are the source and destination addresses of a GRE tunnel.
• L2TP encapsulation and then IPsec encapsulation are performed on packets
transmitted over an L2TP over IPsec tunnel. In the IP header added during IPsec
encapsulation, the source and destination addresses are the IP addresses of the
local interface and remote interface to which an IPsec policy is applied.
• IPsec needs to protect the data flows from the L2TP tunnel source to the L2TP
tunnel destination. In the IP header added to packets during L2TP encapsulation,
the source and destination addresses are the source and destination addresses of
an L2TP tunnel. When a branch connects to the headquarters, the source address
of the L2TP tunnel is the IP address of the outbound interface on the L2TP access
concentrator (LAC), and the destination address is the IP address of the inbound
interface on the L2TP network server (LNS).
• A public IP header is added to packets during L2TP encapsulation, and another
public IP header is added to packets if L2TP over IPsec in tunnel mode is used,
resulting in longer packets, which are prone to being fragmented. Therefore,
L2TP over IPsec in transport mode is recommended.
• The L2TP over IPsec negotiation process and packet encapsulation process are
similar when traveling employees are remotely connected to the headquarters
and when branch employees are connected to the headquarters. The difference is
that, L2TP and IPsec encapsulation is performed on clients when traveling
employees are remotely connected to the headquarters. The L2TP tunnel source
address is the private address assigned to a client and can be any address in the
IP address pool configured on the LNS. The L2TP tunnel destination address is the
address of the inbound interface on the LNS.
• NAPT enables a public IP address to map multiple private IP addresses through
ports. In this mode, both IP addresses and transport-layer ports are translated so
that different private IP addresses with different source port numbers are
mapped to the same public IP address with different source port numbers.

• Due to a limited number of TCP/UDP ports (0–65535), an address can be

mapped to a limited number of private network sessions. Based on the NAT
address pool, NAPT can randomly map a private network session to an address in
the address pool, reducing the number of private network sessions.

• A NAT mapping entry is triggered by the first packet. When no traffic is

transmitted for a period of time, the NAT mapping entry is automatically deleted
to ensure security.

• NAPT and Easy IP are also known as source NAT because they change only the
source address and port number of a packet.
• There are four types of NAT:

▫ Full cone NAT

▫ Restricted cone NAT

▫ Port restricted cone NAT

▫ Symmetric NAT
• NAPT and Easy IP are also known as source NAT because they change only the
source address and port number of a packet.
• In RFC 3489, STUN is a complete NAT traversal solution and its full name is
Simple Traversal of UDP Through NATs.

• In the new RFC 5389 revision, STUN is positioned to provide a tool for NAT
traversal rather than a complete solution. The full name of STUN is changed to
Session Traversal Utilities for NAT. Besides the full name difference, STUN in RFC
5389 differs from STUN in RFC 3489 in that STUN in RFC 5389 supports NAT
traversal for TCP.
• A STUN client sends a STUN binding request to the STUN server.

• After receiving the STUN binding request, the STUN server obtains the source IP
address and port number, constructs a STUN binding response, and sends the
response to the client.

• The STUN client obtains an IP address and port number from the binding
response, and compares the obtained IP address and port number with the
source IP address and port number carried in the binding request. If they are
different, a NAT device is used in front of the STUN client.

• STUN clients use BGP to learn each other's NAT information (IP addresses and
port numbers before and after NAT).

• The local STUN client uses the local pre-NAT IP address and port number and the
pre-NAT IP address and port number of the peer STUN client to construct a
STUN binding request and sends it to the peer STUN client. In addition, the local
STUN client uses the local pre-NAT IP address and port number and the post-
NAT IP address and port number of the peer STUN client to construct a STUN
binding request and sends it to the peer STUN client. The peer STUN client
performs the same operations.

• After receiving the STUN binding request, the peer STUN client sends a STUN
binding response to the local STUN client. The local STUN client performs the
same operations.

• After the preceding STUN messages are exchanged, a data channel is established
between the STUN clients so that packets can traverse the NAT devices.
• The SAC signature database file can only be updated through upgrades and
cannot be manually modified.

• The SAC signature database can be updated in either of the following modes:

▫ Online update: The SAC signature database can be updated through the
security center platform or intranet update server.

▫ Local update: The upgrade package is downloaded from the security center
platform and uploaded to the device through FTP for the update of the SAC
signature database.
• After a packet enters the device, the device determines whether the
corresponding application has been identified based on the 5-tuple information
carried in the packet. If the application has been identified, the device forwards
the packet at Layer 3 without identifying the application again. If the application
has not been identified, the device performs the SAC application identification
process. The device then processes the packet based on the SAC identification
result and forwards the packet at Layer 3. The SAC application identification
process is as follows: The device identifies an application based on the ACL rules
defined in FPI. If the application cannot be identified, the device identifies the
application based on the DNS entries defined in FPI. If the application still cannot
be identified, the device identifies the application based on the protocol and port
mapping table defined in FPI. If the application still cannot be identified, the
device starts the SA identification process.
• FPI applications are classified into the following types:
▫ Predefined and user-defined FPI applications based on the protocol and port
number: These two types of applications are identified using entries that are
generated based on the protocol and port number carried in packets. The
difference is as follows: Packets of a predefined FPI application contain
common protocols and port numbers, while packets of a user-defined FPI
application contain the protocols and ports that you define.
▫ Predefined and user-defined FPI applications based on the DNS domain name:
These two types of applications are identified using DNS entries generated
through association between FPI and DNS. The difference is as follows:
Packets of a predefined FPI application contain common DNS domain names,
while packets of a user-defined FPI application contain the DNS domain
names that you define.
▫ User-defined FPI application based on 5-tuple and DSCP information. This
application is identified based on the user-defined 5-tuple and DSCP
information using advanced ACL rules.
• Identification process of FPI applications based on the DNS domain name
▫ FPI applications based on the DNS domain name are identified using DNS
entries generated through association between FPI and DNS. The FPI signature
database contains the mappings between domain names and applications.
DNS response packets contain the mappings between domain names and IP
addresses. Based on the mappings, a device generates DNS entries, which
contain the mappings between IP addresses and applications. The device
searches for DNS entries based on the IP address carried in the application
protocol packets to identify the corresponding application.
• SPR classifies services based on the following attributes:

▫ Protocol types: IP, TCP, UDP, GRE, IGMP, IPINIP, OSPF, and ICMP

▫ Packet applications: DSCP, ToS, IP precedence, fragment, VPN, and TCP-flag

▫ Packet fields: Source IP Address, Destination IP Address, Protocol, Source Port,

Destination Port, Source IP Prefix, Destination IP Prefix

• When SPR selects routes for services based on the NQA detection result, the CMI
is calculated using the following formula:

▫ CMI = 9000 – CMI-method. The default value of CMI-method is D + J + L.

▫ If NQA is used, a larger CMI value indicates better link quality.

• When SPR selects routes for services based on the IP FPM detection result, the
CMI is calculated using the following formula:

▫ CMI = D + J + L

▫ If IP FPM is used, a smaller CMI value indicates better link quality.

• When a network is unstable, SPR triggers link switchovers frequently, which
degrades service experience. SPR provides the flapping suppression function to
address this problem.

• The flapping suppression function is disabled by default, and the flapping

suppression period is configurable. After traffic is switched to a new link, SPR
starts the flapping suppression timer. Within a flapping suppression period, SPR
does not perform a link switchover even if it does not obtain the NQA test result
indicating that the link meets service requirements within a switchover period.
After the flapping suppression timer expires, if SPR still does not obtain the NQA
test result indicating that the link meets service requirements within a switchover
period, SPR performs a link switchover. If SPR obtains the NQA test result
indicating that the link meets service requirements within a switchover period,
SPR retains traffic on the link without performing a link switchover.
1. AC

2. A
• ONUG: refers to Open Networking User Group. ONUG is an influential user
organization led by large enterprises and comprised mainly of IT users. It was
founded by IT technical executives of well-known large enterprises in North
America and is dedicated to driving IT implementation and network technology
transformation for large enterprises. ONUG members include large enterprises in
industries such as finance, insurance, medical care, and retail. ONUG serves as a
platform for high-end customers in North America to discuss and communicate
IT requirements.

• Gartner: It is the world's most authoritative IT research and advisory company. Its
research scope covers all IT industries. It provides objective and fair
demonstration reports and market research reports for customers in terms of IT
research, development, evaluation, application, and market, thereby assisting
customers in market analysis, technology selection, project demonstration, and
investment decision-making.
• The overall architecture of the SD-WAN solution consists of the network layer,
control layer, and orchestration layer. The layers are associated with each other
through standard interfaces and communication protocols.

▫ Layer: The Agile Controller-Campus manages enterprise interconnection

services in a refined manner. The Agile Controller-Campus manages
network devices through NETCONF in the southbound direction. The Agile
Controller-Campus provides standard RESTful interfaces to interwork with
third-party applications in the northbound direction.

▫ Control layer: The controller works with distributed control components to

transfer routes between sites in an area and implement inter-area network
interconnection.

▫ Network layer: Cost-effective network devices and overlay technologies are

used between branches, headquarters, and cloud platforms to build on-
demand full-network connections based on any link, such as the Internet
and traditional private lines.

• iMaster NCE-WAN/iMaster NCE-Campus can be used as Huawei SD-WAN

controllers.

• Enterprise branches, headquarters, data centers, and IT infrastructure deployed

on the cloud are collectively referred to as enterprise sites.
• Multiple virtual networks can be deployed to provide different services for the
same tenant (for example, services for multiple departments) or provide different
services for different tenants.

• In terms of network device functions, the network layer of the SD-WAN Solution
consists of two types of NEs: CPE and gateway (GW).
• RR site: The CPE at the site functions as an RR and distributes EVPN routes
between CPE gateways at edge sites based on VPN topology policy.

• If the tenant administrator assigns the role of "gateway + RR" to an egress CPE
when adding the CPE, the site where the CPE resides is an RR site. If no device at
a site is assigned the "gateway + RR" role, the site is an edge site.

• An edge site can establish IBGP peer relationships with two RRs that back up
each other.

• Multiple RRs can be deployed for a tenant. All RRs are connected in full-mesh
mode on the control plane.
• A gateway has different roles in different service scenarios. For example, a
gateway connected to a legacy site may be referred to as an interworking
gateway (IWG), and a gateway connected to the cloud may be called a cloud
gateway. These gateways can extend functions by interconnecting with each
other to establish a Point of Presence (PoP) network, where these gateways are
referred to as PoP gateways.
• ZTP: Multiple ZTP modes are available to enable EDGEs to quickly register with
iMaster NCE-WAN.

• Forwarding-control separation enables flexible networking: Each EDGE

establishes a management channel with iMaster NCE-WAN through NETCONF,
and iMaster NCE-WAN delivers configurations to EDGEs to establish IP overlay
tunnels between the EDGEs.

• Application optimization for service controllability and visibility: The service

awareness (SA) technology is used to identify applications. TCP Flow
Performance Measurement (FPM) and IP FPM technologies are used to
implement application-based quality measurement. The IP FPM technology can
also be used for link quality measurement. Smart Policy Routing (SPR)
technology provides intelligent link switchover based on the application quality.

• Complete security protection system ensures service security: Multiple VPN

technologies, such as IPsec and MPLS, are leveraged to provide end-to-end
protection. The firewall function is supported to provide comprehensive security
protection at the hardware, pipe, and application levels.

• Visualized O&M for quick fault locating: iMaster NCE-WAN collects network-wide
data and displays key indicators, helping O&M personnel quickly locate faults.
• Huawei SD-WAN Solution supports the following ZTP modes:

▫ Email-based deployment

▫ DHCP-based deployment

▫ USB-based deployment
• Files for USB-based, email-based, and DHCP-based deployment can be generated
through iMaster NCE-WAN.

• For details about each deployment mode, learn the course Management and
O&M.
• Management channel:

▫ iMaster NCE-WAN sets up management channels with all devices through

NETCONF, so as to manage NEs and orchestrate services on the entire
network.

• Control channel:

▫ EDGEs set up control channels with the RR.

▫ The RR centrally controls and distributes service routes between branch

sites.

▫ The enhanced BGP EVPN protocol is used to implement separate

transmission of tenants' VPN route and next hop information, and IPsec SA
negotiation.

• Data channel:

▫ EDGEs set up data channels with each other.

▫ EDGEs forward data based on GRE or GRE over IPsec tunnels. The extended
GRE header carries VN IDs to differentiate tenants or departments, thereby
transmitting data of multiple VNs over the same tunnel.
• A TNP is a WAN port on a CPE used for connecting to a transport network. The
key TNP information includes the site ID, CPE router ID, transport network ID,
public IP address, private IP address, and tunnel encapsulation mode.
• For details about SAC and SPR, learn the course HA Technologies.
• An SD-WAN site can be deployed with a single CPE or dual CPEs. For small sites,
a single CPE can be deployed. For sites with high reliability requirements, dual
CPEs are recommended to provide device-level redundancy.

• It is recommended that multiple links be deployed on the WAN side of a CPE.

These links can back up each other, offering link-level reliability. In addition,
services can easily select the active and standby links among these WAN-side
links with differentiated quality.

• A maximum of 10 WAN links can be deployed for each CPE at an SD-WAN site.
During actual deployments, to enhance reliability and facilitate O&M, it is
recommended that a maximum of three WAN links be deployed for a single CPE
at a site, and a maximum of six WAN links be deployed for a site with two CPEs.
• LAN side connected to Layer 2 networks:

▫ At small sites with a simple intranet structure, and CPEs typically connect to
the intranet of the site at Layer 2.

• LAN side connected to Layer 3 networks:

▫ In Layer 3 interconnection scenarios, SD-WAN routers support the direct

connection, dual-homing, and partial-ring networking.

▫ In such scenarios, routing protocols simply need to be configured for CPEs

based on the requirements of the LAN device.
• In the single-CPE structure, the LAN connection is simple.

▫ For small sites, for example, SOHO sites, LAN-side interfaces can be directly
connected to terminals at the sites.

▫ If the number of required LAN-side interfaces is beyond the CPE

specifications, access switches can be connected to the CPE. In this case,
access switches can be connected to the CPE in one-armed mode.

• In the dual-CPE architecture, VRRP is usually configured for the CPEs to prevent
the dual-CPE architecture from affecting the LAN side.

▫ Multiple switches can be deployed on the LAN side to form a stack. If two
CPEs are deployed at a site, they can be interconnected directly or through
the LAN.

▫ CPEs can be directly connected through an Eth-Trunk link. In addition, an

interlink needs to be established between the active and standby CPEs to
forward service packets between the CPEs.
• For large enterprise sites, the network structure is complex as Layer 3 core
devices are deployed on the network. Therefore, egress routers must support
interconnection with Layer 3 devices. They can be connected to a Layer 3 network
directly or in dual-homing mode. BGP, OSPF, and static routes are supported.

• In the Layer 3 interconnection scenario, if only one CPE is deployed, the network
structure is simple. In such a scenario, only the routing protocol needs to be
configured on the LAN side based on requirements of LAN-side devices.
• Solution 1 is recommended. In this solution, the interlink and service links are
independent of each other. When WAN-side links are adjusted, the interlink will
not be affected, and the service flow direction is clear.
• The TN and RD are used to set up overlay tunnels in enumerated mode.

• The site ID is used as the next hop of a routing entry.

• The CPE router ID is used to establish BGP peer relationships between different
sites.

• TNPs are used to establish tunnels.

• TNs and RDs are mainly used to enumerate tunnels.

▫ Tunnel enumeration: All tunnels that can be established are enumerated.

• Router IDs are mainly used to establish control channels.

• A site ID is used as the next hop for data forwarding.

• A TNP ID can be considered as the interface number.

• The public and private IP addresses are used as the source or destination IP
addresses of control and data channels.

▫ Some CPEs are deployed behind the NAT device. To establish data channels
between CPEs, you need to know the post-NAT public IP address.

▪ CPEs typically use the Session Traversal Utilities for NAT (STUN)
technology to detect public IP addresses.
• Data tunnels are enumerated before being established to ensure that all
available data tunnels are established.

• Tunnels can be enumerated only when the following conditions are met:

▫ The CPE has learned service routes of the peer site.

▫ The CPE has learned the TNP information of the peer site.
• The management channel is used to establish control channels and deliver basic
configurations.

• Control channels are used to establish data channels.

▫ Datagram Transport Layer Security (DTLS) is a security protocol for the

packet transport layer, which is used to ensure TCP data security.

• Data channels are used to transfer user data.

• TNP information is exchanged twice:

▫ During the control channel establishment phase, TNP information is

exchanged to exchange information about channel establishment between
RRs and EDGEs.

▫ During the data channel establishment phase, TNP information is

exchanged to exchange information about channel establishment between
EDGEs.
• RR deployment suggestions are as follows:

▫ To prevent site network adjustment from affecting the stability of RRs, you
are advised to use method 2, that is, independent deployment of RRs.

▫ Use high-performance devices as RRs. For details about the devices that can
function as RRs, see the specifications list.

▫ Configure a public IP address for an RR, or deploy a NAT device before the
RR. Only 1:1 static NAT is supported.

▫ An EDGE site can connect to a maximum of two RR sites. Two EDGEs can
be deployed at each RR site deployed for a tenant. If there are a large
number of EDGEs, multiple RRs can be deployed, and each RR serves some
EDGE sites.

▫ When one EDGE is connected to two RR sites, the EDGE establishes a BGP
connection with each RR at the RR sites.

▫ If a branch site has a standby link, for example, the branch or the RR has a
standby link, and the active link is normal, no control channel is established
for the standby link. When all active links from the branch site to the RR
are down, the standby link is involved in the establishment of control
channels.
• A EDGE can be connected to a maximum of two RR sites (four RRs).

• For small networks (for example, a network with fewer than 50 sites), RRs and
hubs can be deployed in co-located mode.

• RRs require strong BGP connection capabilities (number of BGP peers), large
number of EVPN connections, and high route reflection capability and efficiency.
In actual deployments, select the RR models recommended in the specifications
list, for example, AR6300/AR6280.
• An MSP administrator deploys independent RRs as a service provided by carriers
or MSPs for enterprise users to access. Two RR service modes are available:
sharing and exclusive. In sharing mode, one RR is shared by multiple tenants. In
exclusive mode, one RR is exclusively used by a tenant.

▫ MSP RR sharing by multiple tenants: For small and midsize enterprises, it is

recommended that one RR be shared by multiple tenants, if there are a
small number of sites. Sites of different enterprise tenants are connected to
the same multi-tenant RR, which carries the control plane.

▫ MSP RR exclusive to a tenant: Carriers can specify an independent RR in an

access area for a large enterprise with a large number of sites to use
exclusively. Based on actual scenarios, carriers or MSPs can deploy RRs in
co-deployment mode, independently, and based on areas for tenants.
• Different device models have different BGP peer specifications and tunnel
specifications.

• For details about the product specifications, see the product documentation.
• Area-based networking:

▫ Multiple areas are created under a tenant, and multiple hub sites are
deployed in the HQ/DC. Each area is associated with one or two hub sites.

▫ Branch sites are added to corresponding hub sites by area.

▫ RRs can be independently deployed. Each pair of RRs are associated with
sites in an area.

▫ Traffic between inter-area sites is transmitted through the LAN side of the
hub.

• Tenant-based networking:

▫ The MSP administrator creates multiple tenants, and multiple hub sites are
deployed in the HQ/DC. Each tenant is associated with one or two hub
sites.

▫ Branch sites are grouped by their geographical areas and are added to
different tenants.

▫ RRs can be independently deployed. Each pair of RRs are associated with
sites in an area.

▫ Traffic between inter-area sites is transmitted through the LAN side of the
hub.
• Hub-spoke:

▫ Generally, the enterprise HQ/DC functions as a hub site, and enterprise

branches function as spoke sites. Server applications deployed in the HQ/DC
are accessed through the WAN in a centralized manner.

• Full-mesh:

▫ In the topology, different branches can directly communicate with each other,
without the need to divert traffic through intermediate nodes.

• Partial-mesh:

▫ Partial-mesh can be considered as a special type of full-mesh networking. If

an underlay network is available between two sites, traffic can be directly
transmitted between the two sites. Otherwise, the two sites communicate with
each other through a redirect site.

• Hierarchical networking:

▫ The hierarchical networking model can be considered as the combination of

the single-layer networking model. A WAN is divided into multiple areas,
which are interconnected through a centralized backbone area to implement
inter-area communication between sites.
• After a packet enters the device, the device determines whether the
corresponding application has been identified based on the 5-tuple information
carried in the packet. If the application has been identified, the device forwards
the packet at Layer 3 without identifying the application again. If the application
has not been identified, the device performs the SAC application identification
process. The device then processes the packet based on the SAC identification
result and forwards the packet at Layer 3.

• SAC identifies an application as follows: SAC first identifies an application

according to ACL rules in FPI. If the application fails to be identified, the
application is identified according to the DNS association table in FPI. If the
application fails to be identified, the device identifies the application based on the
protocol port table in the FPI. If the application still fails to be identified, the
device attempts to identify the application using SA.
• An enterprise usually has multiple departments of different importance. Traffic of
each department needs to be isolated, and different bandwidths need to be
allocated to each department.

▫ A specified bandwidth quota is assigned to each department to meet its

service requirements.

▫ If some departments do not fully use their bandwidth quotas, the idle
bandwidth resources can be used by other departments with insufficient
bandwidth.

▫ Internet access traffic and traffic for communication with legacy sites needs
to be controlled separately.
• Traffic cannot be transmitted to the Internet through multiple links in load
balancing mode. The links can work only in active/standby mode based on their
priorities.

• If local Internet access is configured for specified application traffic and

centralized Internet access is also configured, local Internet access for specified
application traffic is implemented by orchestrating policy-based routing (PBR).

• If local Internet access is enabled, the default route on the underlay WAN needs
to be configured. The default route can be a static route (mainly for Internet
access through the Internet network interface) or BGP/OSPF route (mainly for
Internet access through the MPLS network interface).
• A dedicated link is established between user-side interfaces on both the legacy
CPE and SD-WAN CPE. The dedicated link runs a protocol such as BGP or OSPF
to exchange routes between the legacy MPLS network and SD-WAN network. In
this way, users on the two networks can communicate with each other through
the dedicated link.
• Multiple traffic models are supported in this scenario, and you can choose one
based on your service requirements.

▫ Distributed local access: This model applies if all SD-WAN sites can access
legacy sites over the underlay MPLS network through local breakout. In this
model, traffic of each site is directly forwarded through the local site,
without the need of being forwarded through overlay tunnels.

▫ Centralized local access: If some SD-WAN sites cannot access legacy sites
through local breakout, you can configure a site that can communicate
with the legacy sites as the centralized access site. Traffic from other SD-
WAN sites is sent to the centralized access site through overlay tunnels, and
then forwarded to the legacy sites through local breakout.

▫ Hybrid local access: The SD-WAN Solution enables multi-link sites using the
distributed local access model to use local access preferentially, with
centralized local access as a backup. This enhances reliability. Traffic from a
site that uses the distributed local access model is preferentially transmitted
to a legacy site through local breakout. If the MPLS link for local access
fails, traffic is automatically switched to the overlay tunnel of another link
and transmitted to the centralized access site. The centralized access site
then forwards the traffic to legacy sites.
• Active-active hub site networking based on service network segments:

▫ If branch sites' access to DCs can be distinguished based on service network

segments, active-active hub sites can be implemented based on the service
network segments. Each of the hub sites functions as the active hub site for
one service or standby hub site for another different service.

• Active-active hub site networking based on spoke sites:

▫ If an enterprise's WAN spans a large physical distance and the enterprise's

two DCs are far away from each other, active-active hub sites based on
spoke sites are recommended. Each spoke site connects to both hub sites
deployed in the DCs and preferentially accesses the nearer hub site for a
better DC service access experience. The nearer hub site is the primary one,
while the farther hub site is the backup one.
• The active controller is deployed in the primary DC, and the standby controller in
the backup DC. A heartbeat tunnel is established between the active and standby
controllers to synchronize data and verify the controller status.

• The active and standby controllers use the same southbound and northbound IP
addresses. In public network scenarios, the same NAT address must also be
configured.
1. ABCD

2. A
• Internet:

▫ Site-to-Internet private line: Ethernet private line/xPON private line/xDSL

private line. The access is restricted by geographic locations. It applies to
inter-enterprise communication over Internet-based encrypted tunnels.

▫ Dial-up connection: low bandwidth and low tariff. The access is not
restricted by geographical locations. It applies to individual users.

▫ BGP: applies to data center Internet egresses.

• As technologies are constantly developing, historical WAN technologies such as

T1/E1, PSTN, ATM, and frame relay are not described here.
• BGP Labeled Unicast (BGP-LU) (RFC 3017) is both an inter-AS and an intra-AS
routing protocol.
• In the past, most of our networks were siloed private networks, such as education,
healthcare, and government private networks. These networks were independent
physical private networks and could not communicate with each other. The
handling of some services may involve multiple private networks. Moreover, a
service may be deployed segment by segment even on one private network. For
example, multiple ASs may exist on a network due to the division of
administrative domains, and one network service may be deployed across ASs
(on a common network, service data is generally carried over MPLS). In this
situation, a large number of device configurations and personnel communication
are required. The network administrator needs to perform a large number of
configurations on AS boundary devices, and it takes a long time to migrate the
service to the cloud. The acceleration of enterprise digital transformation drives
alignment between networks and clouds.
• Now, increasingly more industries are deploying data to the cloud, making it
easier to converge or share data. The introduction of SRv6 can remove process
barriers and accelerate service provisioning. Simply put, SRv6 can be deployed on
both ends of an SRv6 tunnel to implement one-hop cloud access.
• In the MPLS era, a large number of control-plane protocols, such as IGP, BGP,
LDP, and RSVP-TE, are required to carry VPN services on a network or implement
traffic engineering. On the forwarding plane, there are protocols such as MPLS,
GRE, and L2TP or native IP. The network configuration and configuration
modification are complex. Huawei's CloudWAN solution simplifies network
deployment by replacing multiple network protocols with SRv6+IGP/BGP. SRv6
uses IPv6 as the forwarding plane protocol. On a WAN where IPv6 is deployed, it
is easy to deploy an end-to-end tunnel, even in inter-AS scenarios. The SDN
controller can be used to implement automated SRv6 service provisioning within
minutes.
• Huawei uses the hierarchical slicing technology to power IP-based production
networks, ensuring deterministic SLAs for production services.

• In the past, production and office services were carried over multiple independent
private networks. Repeated network construction resulted in high investment
costs and complex O&M of multiple networks. By deploying multiple slices on
one IP bearer network, production services such as remote industrial control and
video surveillance are directly isolated from office services, delivering 100%
bandwidth guarantee for mission-critical services.
• iFIT integrates the RFC 8321 coloring technology and in-band detection
technology to directly measure service packets. It works with second-level
telemetry data collection and iMaster NCE for unified management, computation,
and visualization. In this way, it implements real-time visualization and proactive
monitoring of network quality SLAs and fast fault demarcation and locating.
• Quick Network Adjustment upon Cloud Changes, Integrated Service Provisioning,
Cloud-based Data Sharing.
1. B
• The Ps for intra-city data center are directly connected using WDM or bare
optical fibers. The link bandwidth can reach 10 Gbit/s. To reduce costs, consider
connecting local data centers with remote data centers through carriers' MSTP
links.
• For more information about MPLS, see HCIP-Datacom-Advanced Routing &
Switching Technology.
• Based on MPLS and IPv6 forwarding technologies, SR Policies can be classified
into SR-MPLS and SRv6 Policies.
• Traditional switching networks, such as asynchronous transfer mode (ATM) and
frame relay (FR) networks, are integrated with IP or MPLS networks. As a result,
Layer 2 virtual private network (L2VPN) emerges. L2VPN includes Virtual Pseudo
Wire Service (VPWS) and Virtual Private LAN Service (VPLS):

▫ VPWS is a P2P L2VPN technology that emulates the basic behaviors and
characteristics of services such as ATM and frame relay.

▫ VPLS provides P2MP L2VPN services so that sites are connected as if they
were on the same LAN.

• Virtual Private Dial-up Network (VPDN) is a virtual private network constructed

on the public network. It uses a dedicated network encryption communication
protocol to provide access services for international organizations and mobile
workforce of enterprises. There are multiple VPDN tunneling protocols, among
which Layer Two Tunneling Protocol (L2TP) is the most widely used. Strictly
speaking, L2TP is also a type of L2VPN, but its network structure and protocol
design are quite different from those of other types of L2VPN. In addition, L2TP
uses the dial-up mode. Therefore, L2TP is classified as VPDN.

• L3VPN is also called Virtual Private Routing Network (VPRN), including RFC
2547-based BGP/MPLS IP VPN as well as IPsec VPN and GRE VPN carried over
IPsec or GRE tunnels.
• A traditional L2VPN does not have any control plane and does not transmit
service route information (MAC addresses). It uses BGP as the signaling protocol
to establish VCs.

• For details about VPN classification, see the book SRv6 Network Programming:
Ushering in a New Era of IP Networks.
• VCs are also called pseudo wires (PWs) in some documents.
• GRE: GRE can be applied to both L2VPN and L3VPN. Generally, the bearer WAN
for MPLS VPN uses LSPs as public network tunnels. If the bearer WAN (P devices)
has only IP functions but not MPLS functions, and the PEs at the network edge
have MPLS functions, the LSPs cannot be used as public network tunnels. In this
case, GRE tunnels can be used to replace LSPs to provide L3VPN or L2VPN
solutions on the bearer WAN.

• SR-MPLS Policy: a type of SR-MPLS tunnel.

• SRv6 Policy: a type of SRv6 tunnel.

• You can configure tunnel policies or tunnel policy selectors for tunnel
management. This course uses tunnel policy configuration as an example. Tunnel
policy selectors apply to inter-AS VPN scenarios. For details, see the product
documentation for NetEngine products.
• The configuration of tunnel policy parameters involves many details. For example,
CR-LSP-based tunnels include RSVP-TE tunnels and SR-MPLS TE tunnels. The
system determines the priorities of these tunnels based on their up time. For
details, see "VPN Tunnel Management Configuration" in the product
documentation for Huawei NetEngine routers.
• For the application of other types of VPN, such as VPNv6, L2VPN, and EVPN, see
the product documentation for NetEngine routers.
• For details, see "SR Policy" in 2. Terminology in RFC 8402.

• SR Policy traffic diversion can be based on the binding SID, color, and DSCP value.
Details are not provided here.
• Different collection protocols may be used in different solutions. For example,
PCEP is used to collect TE tunnel information on Huawei MPLS networks, and
BGP SR Policy is used to collect TE tunnel information on SRv6 networks.
• Bandwidth-balanced path: path with more remaining bandwidth among all paths
that meet the constraints and have the same cost.

• Maximum-availability path: path with the maximum availability among all paths
that meet the constraints.
• For the basic packet forwarding process, see HCIP-Datacom-Core Technology-01
Introduction to Network Devices.

• Behavior aggregate classification: Packets are roughly classified based on the IP

precedence or DSCP value of IP packets, TC value of IPv6 packets, EXP value of
MPLS packets, and 802.1p value of VLAN packets to identify traffic with different
priorities or service levels and implement internal-external priority mapping for
the traffic.

• Multi-field classification elaborately classifies packets based on complex rules,

such as the 5-tuple (source address, source port number, protocol number,
destination address, and destination port number).

• Packet Forwarding Engine (PFE): After a router is powered on, it runs a routing
protocol to learn the network topology and generate a routing table. If the
interface board registers successfully, the main control board can generate
forwarding entries according to the routing table and deliver entries to the
interface board. In this manner, the router can forward packets according to the
forwarding table. The component that forwards data packets is a chip located on
an interface board and is called a packet forwarding engine (PFE).
• Weighted Random Early Detection (WRED): The system discards packets based
on the drop policies configured for data packets or queues with different
priorities. WRED is a congestion avoidance mechanism used to discard packets to
prevent queues from being congested. For details, see the product
documentation for Huawei NetEngine products.

• FIFO: FIFO does not classify packets. FIFO allows packets to be queued and
forwarded in the same order as they arrive at an interface.

• SP: Queues are scheduled strictly according to their priorities. Packets in queues
with a low priority can be scheduled only after all packets in queues with a
higher priority are scheduled.

• WFQ: The egress bandwidth is allocated to each flow according to the queue
weight.

• Other scheduling algorithms, such as RR polling, WRR weighted polling, and DRR
differential polling, are not described here.
• PQ queue

▫ PQ queues use the SP scheduling algorithm. That is, the packets in the
queue with the highest priority are scheduled first. In this way, an absolute
priority can be provided for different service data, the delay of delay-
sensitive applications such as VoIP can be guaranteed, and the use of
bandwidth by high-priority services can be absolutely prioritized.

▫ Disadvantage: If the bandwidth of high-priority packets is not limited, low-

priority packets may fail to obtain bandwidth and be scheduled.

▫ Generally, only delay-sensitive services enter PQ queues.

• WFQ queue

▫ WFQ queues are scheduled based on weights. The WFQ scheduling

algorithm can be used to allocate the remaining bandwidth based on
weights.
• If the CE or the downstream device of the CE does not have the traffic marking
capability, deploy multi-field classification on the ingress PE on the bearer WAN
to mark traffic for queuing. This, however, affects the forwarding performance of
the bearer WAN.
• Different VLANs are used for service access. Logical interfaces correspond to VPN
instances VRF1, VRF2, VR3... on the network slice.

• The ingress PE encapsulates the VPN SID and SRv6 Policy information into the
service flow on the network slice with the slice ID being 2, and inserts an
extension header with the Hop By Hop Slice ID being 2 between the IPv6 header
and SRH of each packet.

• Each transit node queries the SRv6 SID in the SRH hop by hop to obtain the
physical outbound interface, and then queries the specific "resource reservation"
sub-interface of the physical outbound interface based on the slice ID. The Hop
By Hop Slice ID remains unchanged throughout this process.

• The egress PE pops the Hop By Hop extension header and forwards the packet to
the AC interface of the corresponding VPN instance based on the VPN SID.

• By default, the slice ID is 0, and the IPv6 Hop By Hop extension header does not
need to be inserted. The packet format on the forwarding plane is the same as
that of traditional L3VPN over SRv6 Policy.
• Because different WAN VPN technologies use different terms, this section briefly
describes various protection mechanisms, but does not describe specific
protection technologies.
• MPLS TE E2E protection is classified into HSB and ordinary backup. In HSB
protection, the backup path and primary path are created at the same time.

• Segment Routing adopts Topology Independent-Loop Free Alternate (TI-LFA), an

enhancement of FRR, for local protection.

• Fast detection mechanism: Fast detection mechanisms represented by BFD

support fast detection of communication faults between devices.
• In a distributed network architecture, each device independently calculates paths,
and there is no consensus on the shortest path when a fault occurs. As a result,
traditional LFA cannot form a backup path.
• This figure does not show protocols related to tunneling and traffic statistics
collection.
• TWAMP Light is a lightweight version of TWAMP defined based on standard
protocols. Compared with TWAMP, TWAMP Light simplifies the control protocol
used to establish performance measurement sessions.
• The standard TWAMP version uses TCP for control plane negotiation, and test
packets are based on UDP. The reflector needs to know the session status so that
devices of different vendors can communicate with each other.

• TWAMP Light does not involve control plane negotiation, and test packets are
also based on UDP. The implementation and configuration are simple, and the
reflector does not need to know the session status.
• iFIT measures E2E service packets to obtain performance indicators of an IP
network, such as the packet loss rate and delay. iFIT adds a color flag to the
packet header in the service flow. Telemetry is used to periodically collect
information. Features such as E2E delay measurement and packet loss
measurement are supported.
• An End.DT4 SID (PE endpoint SID) identifies an IPv4 VPN instance on a network.

• For MPLS packets, the iFIT header is inserted between the MPLS label and MPLS
payload.
1. A

2. ABCD
• In essence, MPLS is a tunneling technology used to guide data forwarding and
has complete tunnel creation, management, and maintenance mechanisms. For
the preceding mechanisms, networks are driven by network operation and
management requirements, not by applications.
• Traditionally, IP data packet forwarding is implemented based on IP addresses
reachable to the destination over the shortest path. To meet the reliability
requirements of services such as voice, online gaming, and video conferencing,
the FRR technology is introduced. To meet the high bandwidth requirements of
private line services such as group customer services, the TE technology is
introduced. These technologies all represent network adaptation to services.

• The increasing types of services pose a variety of network requirements. For

example, real-time Unified Communications and Collaboration (UC&C)
applications usually prefer to paths with low latency and jitter, and big data
applications prefer to high-bandwidth tunnels with a low packet loss rate. In this
situation, the model that requires networks to adapt to services cannot keep up
with rapid service development and even complicates network deployment and
maintenance.

• The solution to this issue is to enable services to drive networks and define the
network architecture. Specifically, after an application raises requirements (e.g.
latency, bandwidth, and packet loss rate), a controller is used to collect
information (e.g. network topology, bandwidth usage, and latency) and compute
an explicit path according to the requirements.
• https://datatracker.ietf.org/doc/rfc8402/
• The label values used in this course are only examples. For details about the label
allocation scope, see the corresponding product documentation.
• For SR-capable IGP instances, all IGP-enabled outbound interfaces are allocated
with SR adjacency labels, which are propagated to the entire network through an
IGP.

• In Huawei's early solutions, an IGP can also be used to collect network topology
information. Due to IGP area-related restrictions, BGP-LS is mainly used at
present.
• Before SR-MPLS TE tunnel creation, IS-IS/OSPF neighbor relationships must be
established between forwarders to implement network layer connectivity,
allocate labels, and collect network topology information. In addition, the
forwarders need to report label and network topology information to a controller
for path computation. If no controller is available, CSPF can be enabled on the
ingress of the SR-MPLS TE tunnel so that forwarders can compute paths using
CSPF.
• For SR-MPLS TE tunnel configuration on a forwarder, in addition to manually
specifying an explicit path, you can also use the function of path computation by
the ingress.
• Currently, the mainstream solution is strict-path forwarding based on adjacency
labels.
• https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/

• An SR Policy is a framework that enables instantiation of an ordered list of

segments on a node for implementing a source routing policy with a specific
intent for traffic steering from that node.
• There are three mainstream methods for SR Policy implementation.

▫ BGP: BGP-LS is used to collect topology information, so that no new

interface protocol needs to be introduced for customer-developed
controllers. BGP SR Policy is used to deliver route information.

▫ PCEP: PCEP is a mature southbound protocol used in SR-MPLS TE scenarios.

However, the tunnel implementation models of vendors are different and
cannot interwork, and the interaction process of PCEP is more complex than
that of BGP. As such, BGP extension is recommended.

▫ NETCONF/YANG: delivers tunnel paths to forwarders as configurations. This

method is not recommended because it delivers configurations in essence
and offers the poorest performance. In a comprehensive solution, NETCONF
is used to deliver configurations other than tunnel configurations.

• For details about SR Policy, see [I-D.ietf-spring-segment-routing-policy].

(https://datatracker.ietf.org/doc/draft-ietf-idr-segment-routing-te-policy/)
• BGP-LS connection:

▫ Collects tunnel topology information for SR Policy path computation.

▫ BGP-LS supports the collection of SR Policy status information, based on

which the controller displays tunnel status.
https://datatracker.ietf.org/doc/draft-ietf-idr-te-lsp-distribution/

▫ BGP-LS supports SRLB information encapsulation and decapsulation, so

that the controller can obtain the SRLB information for binding SID
allocation. (The backup path of each SR Policy corresponds to a binding
SID.)

• BGP SR Policy connection:

▫ The controller delivers SR Policy information to forwarders to generate SR

Policies.

▫ BGP routes delivered by the controller carry the color community attribute,
and this attribute can be transmitted. The ingress finds a matching BGP
route and recurses it to an SR Policy based on the color and endpoint
information.

▫ In the SR Policy solution, path computation constraints of each application

need to be planned in a unified manner on the controller based on SLAs,
different colors are used to identify SR Policies. An SR Policy is uniquely
identified by <headend, color, endpoint>. The BGP route of services to be
steered into an SR Policy needs to carry the corresponding color attribute.

• Huawei SR-MPLS Policy solution also uses PCEP for tunnel status query.
• An SR Policy can contain multiple candidate paths (e.g. CP1 and CP2). Each of
the paths is uniquely determined by the triplet <protocol, origin, discriminator>.

• CP1 is the primary path because it is valid and has the highest preference. The
two SID lists of CP1 are delivered to the forwarder, and traffic is balanced
between the two paths based on weights. For SID-List <SID11...SID1i>, traffic is
balanced according to W1/(W1+W2). In the current mainstream implementation,
a candidate path has only one segment list.
• Source of BSIDs: SRLB or SRGB

• Each candidate path of an SR Policy has a BSID. The BSIDs of different candidate
paths of the same SR Policy are generally the same. The BSIDs of different SR
Policies must be different. Generally, the BSID range needs to be planned and
cannot be shared with other services.

• The headend of an SR Policy forwards packets over the SR Policy based on the
BSID. For example, when the headend receives a packet carrying a BSID, it uses
the corresponding SR Policy to forward the packet.

• BSIDs are used in label-based traffic steering scenarios, especially label stitching
scenarios and tunnel protocol interworking scenarios, such as LDP over SR.

• For details, see draft-ietf-spring-segment-routing-policy-6.Binding SID.

• Preparations:

1. Controller planning: You can plan the color attribute and the mapping
between the color attribute and SR tunnels' SLA requirements (path
computation constraints) on the controller based on the SLA requirements
of services.

2. Enable SR on involved devices.

3. Create a BGP session between the ingress and egress to advertise BGP VPN
route information.

4. Check that the BGP peer relationship is established successfully and a

reachable route carrying the color attribute exists between the ingress and
egress.
• The steps in this document do not represent the actual configuration sequence.
They are only used to help you understand the implementation process. In real-
world situations, the controller may deliver SR Policies and use NETCONF to
deliver configurations at the same time.
• DSCP-based traffic steering does not support color-based route recursion.
Instead, it recurses a route to an SR-MPLS Policy based on the next-hop address
in the route. Specifically, it searches for the SR-MPLS Policy group matching
specific endpoint information and then finds the corresponding SR-MPLS Policy
based on the DSCP value of packets. For details, see the corresponding product
documentation.
• Path Computation Element Communication Protocol (PCEP) Extensions for SR:
https://datatracker.ietf.org/doc/rfc8664/?include_text=1
• In a distributed network architecture, each device independently computes a
path, and there is no consensus on the shortest path when a fault occurs. As a
result, a backup path cannot be formed using traditional LFA.
• For details about TI-LFA FRR, see the "TI-LFA FRR" section in NE series product
documentation.
• The cost values of the links from R4 and R5 to the virtual node are both 0.
However, the cost values of the links from the virtual node to R4 and R5 are
infinite.
• In traditional TE tunnel protection technologies, if a PE fails, services can recover
only through E2E route convergence and LSP convergence. The service
convergence time is closely related to the number of internal MPLS VPN routes
and the number of hops on the bearer network. The greater the number of VPN
routes, the longer the service convergence time.

• In VPN FRR, service convergence time depends on only the time required to
detect remote PE failures and change tunnel status, making service convergence
time irrelevant to the number of VPN routes on the bearer network.

• In this example, VPN FRR primary and backup paths exist from PE1 to PE3. They
are not all displayed in the figure.
• Fault detection in hot standby and VPN FRR scenarios depends on detection
mechanisms such as BFD or SBFD.
• Because the state machine has only Up and Down states, the initiator can send
packets carrying only the Up or Down state and receive packets carrying only the
Up or Admin Down state. The initiator starts by sending an SBFD packet carrying
the Down state to the reflector. The destination and source port numbers of the
packet are 7784 and 4784, respectively; the destination IP address is a user-
configured address on the 127 network segment; the source IP address is the
locally configured LSR ID.

• The reflector runs no SBFD state machine or detection mechanism. For this
reason, it does not proactively send SBFD Echo packets. Instead, it only reflects
back received SBFD packets. The destination and source port numbers in the
looped-back SBFD packet are 4784 and 7784, respectively; the source IP address
is the locally configured LSR ID; the destination IP address is the source IP
address of the initiator.
• PCEP was first proposed in the optical transport field. It is seldom deployed on
enterprises' production networks due to its few applications on IP networks,
difficult interoperability between vendors, and poor performance. Therefore, BGP
SR-Policy is recommended on an SR-MPLS network.
• Before configuring an SR-MPLS BE tunnel, you need to enable MPLS on each
device in the SR-MPLS domain. The configuration procedure is as follows:

▫ Run the system-view command to enter the system view.

▫ Run the mpls lsr-id lsr-id command to configure an LSR ID for the local
device.

▪ Note the following during LSR ID configuration:

− Configuring LSR IDs is the prerequisite for all MPLS

configurations.

− LSRs do not have default LSR IDs, and such IDs must be
manually configured.

− Using the address of a loopback interface as the LSR ID is

recommended for an LSR.

▫ Run the mpls command to enable MPLS.

• Basic SR-MPLS BE function configurations mainly involve enabling SR globally,

specifying an SRGB, and configuring an SR prefix SID.

▫ Enable SR globally.

▪ Run the system-view command to enter the system view.

▪ Run the segment-routing command to enter the Segment Routing

view.

▪ Run the commit command to commit the configuration.

▪ Run the quit command to return to the system view.

• Configure a tunnel policy and tunnel selection sequence.

▫ Run the system-view command to enter the system view.

▫ Run the tunnel-policy policy-name command to create a tunnel policy and

enter the tunnel policy view.

▫ Run the tunnel select-seq sr-lsp load-balance-number load-balance-

number [ unmix ] command to configure a tunnel selection sequence and
the number of tunnels for load balancing.

▫ Run the commit command to commit the configuration.

▫ Run the quit command to return to the system view.

• Configure BGP L3VPN service recursion to SR-MPLS BE tunnels.

▫ Run the ip vpn-instance vpn-instance-name command to enter the VPN

instance view.

▫ Run the ipv4-family command to enter the VPN instance IPv4 address
family view.

▫ Run the tnl-policy policy-name command to apply a tunnel policy to the

VPN instance IPv4 address family.

▫ Run the commit command to commit the configuration.

• Before configuring an SR-MPLS TE tunnel, you need to enable MPLS TE on each
device in the SR-MPLS domain.

▫ Run the system-view command to enter the system view.

▪ Run the mpls lsr-id lsr-id command to configure an LSR ID for the
local device.

▪ Run the mpls command to enter the MPLS view.

▪ Run the mpls te command to enable MPLS TE globally on the local

device.

▫ (Optional) Enable interface-specific MPLS TE. In a scenario where the

controller or ingress performs path computation, interface-specific MPLS TE
must be enabled. In a static explicit path scenario, this step can be ignored.

▪ Run the quit command to return to the system view.

▪ Run the interface interface-type interface-number command to enter

the view of an interface on an MPLS TE link.

▪ Run the mpls command to enable MPLS on the interface.

▪ Run the mpls te command to enable MPLS TE on the interface.

▫ Run the commit command to commit the configuration.

• In this example, an explicit path is established by specifying prefix SIDs.

• An explicit path is a vector path comprised of a series of nodes that are arranged
in the configuration sequence. The path through which an SR-MPLS TE LSP
passes can be planned by specifying next-hop labels or next-hop IP addresses on
an explicit path. Generally, the IP addresses involved in an explicit path are
interface IP addresses. An explicit path that is in use can be updated. To configure
an explicit path, perform the following steps:

▫ Run the system-view command to enter the system view.

▫ Run the explicit-path path-name command to create an explicit path and

enter the explicit path view.

▫ Run the next sid label label-value type { adjacency | prefix | binding-sid }
command to specify a next-hop SID for the explicit path.

▫ Run the commit command to commit the configuration.

• In this example, adjacency SIDs are configured statically. The values of adjacency
SIDs are shown in the figure.
• SR-MPLS Policies are used to direct traffic to traverse an SR-MPLS TE network.
Each SR-MPLS Policy can have multiple candidate paths with different
preferences. A valid candidate path with the highest preference is selected as the
primary path, and a valid candidate path with the second highest preference as
the backup path. The SR-MPLS Policy configuration procedure is as follows:

▫ Configure a segment list.

▪ Run the system-view command to enter the system view.

▪ Run the segment-routing command to enable SR globally and enter

the Segment Routing view.

▪ Run the segment-list (Segment Routing view) list-name command to

configure a segment list for an SR-MPLS TE candidate path and enter
the segment list view.

▪ Run the index index sid label label command to specify a next-hop
SID for the segment list.

− You can run the command multiple times. The system generates
a label stack for the segment list by index in ascending order. If
a candidate path in an SR-MPLS Policy is preferentially selected,
traffic is forwarded using the segment list of the candidate path.
A maximum of 10 SIDs can be configured for each segment list.
• The color attribute is added to a route through a route-policy. This enables the
route to recurse to an SR-MPLS Policy based on the color value and next-hop
address in the route.

▫ Configure a route-policy.

▪ Run the system-view command to enter the system view.

▪ Run the route-policy route-policy-name { deny | permit } node node

command to create a route-policy and enter the route-policy view.

▪ (Optional) Configure if-match clauses for the route-policy. The

community attributes of routes can be added or modified only if the
routes match specified if-match clauses.

▪ Run the apply extcommunity color color command to configure a

BGP extended community, that is, the color attribute.

▪ Run the commit command to commit the configuration.

1. D
2. AD
SRv6 Fundamentals and Configuration
 Foreword

⚫ At the beginning of the Segment Routing (SR) architecture design, two

implementation modes were designed for the data plane. One is Segment Routing-
Multiprotocol Label Switching (SR-MPLS), which reuses the MPLS data plane and can
be incrementally deployed on the existing IP/MPLS network. The other is Segment
Routing IPv6 (SRv6), which uses the IPv6 data plane and implements extension based
on the IPv6 Routing header.
⚫ This document describes the concepts and fundamentals of SRv6 and its applications
for Huawei NetEngine series routers.

1 Huawei Confidential
 Objectives

⚫ On completion of this course, you will be able to:

 Describe the background of SRv6.
 Describe the technical advantages of SRv6.
 Describe the basic concepts and fundamentals of SRv6.
 Describe the concepts and fundamentals of SRv6 high reliability.
 Describe how to configure SRv6 BE and static SRv6 Policies.
 Describe how to deploy SRv6 using iMaster NCE-IP.

2 Huawei Confidential
 Contents

1. SRv6 Overview

2. SRv6 Fundamentals

3. SRv6 High Reliability

4. Basic SRv6 Configuration

5. SRv6 Deployment Using iMaster NCE-IP

3 Huawei Confidential
 IP/MPLS Network Introduction
⚫ As a Layer 2.5 technology that runs between Layer 2 and Layer 3, MPLS adds connection-oriented attributes to connectionless IP networks. Traditional
MPLS label-based forwarding improves the forwarding efficiency of IP networks. However, as hardware capabilities continue to improve, MPLS no
longer features distinct advantages in forwarding efficiency. Nevertheless, MPLS provides good QoS guarantee for IP networks through connection-
oriented label forwarding and also supports TE, VPN, and FRR.

⚫ IP/MPLS networks have gradually replaced dedicated networks, such as ATM, frame relay (FR), and X.25. Ultimately, MPLS is applied to various
networks, including IP backbone, metro, and mobile transport, to support multi-service transport and implement the Internet's all-IP transformation.

IP header-based MPLS label-based MPLS label-based IP header-based

forwarding forwarding forwarding forwarding
Destination:
IP network 10.1.1.1 IP network
10.1.1.0/24

IP/MPLS network

Ethernet MPLS IP
Header Header Packet

4 Huawei Confidential

• In the initial stage of network development, multiple types of networks, such as X.25, FR,
ATM, and IP, co-existed to meet different service requirements. These networks could not
interwork with each other, and on top of that, also competed, with mainly ATM and IP
networks taking center stage. ATM is a transmission mode that uses fixed-length cell
switching. It establishes paths in connection-oriented mode, and can provide better QoS
capabilities than IP. The design philosophy of ATM involves centering on networks and
providing reliable transmission, and its design concepts reflect the reliability and
manageability requirements of telecommunications networks. This is the reason why ATM
was widely deployed on early telecommunications networks. The design concepts of IP
differ greatly from those of ATM. To be more precise, IP is a connectionless communication
mechanism that provides the best-effort forwarding capability, and the packet length is not
fixed. On top of that, IP networks mainly rely on the transport-layer protocols (e.g., TCP) to
ensure transmission reliability, and the requirement for the network layer involves ease of
use. The design concept of IP networks embodies the "terminal-centric and best-effort"
notion of the computer network, enabling IP to meet the computer network's service
requirements. The competition between the two can essentially be represented as a
competition between telecommunications and computer networks. As the network scale
expanded and network services increased in number, ATM networks became more
complex than IP networks, while also bearing higher management costs. Within the context
of costs versus benefits for telecom carriers, ATM networks were gradually replaced by IP
networks.
• Although IP is more suitable for the development of computer networks than ATM,
computer networks require a certain level of QoS guarantee. To compensate for the IP
network's insufficient QoS capabilities, numerous technologies integrating IP and ATM, such
as local area network emulation (LANE) and IP over ATM (IPoA), have been proposed.
However, these technologies only addressed part of the issue, until 1996 when MPLS
technology was proposed to provide a better solution to this issue.
Issues with MPLS LDP and RSVP-TE
MPLS LDP RSVP-TE

R2 R2

R1 R1

R3 R3
R4 R4

• RSVP-TE configuration is complex and load balancing is not

• LDP itself does not have the path computation capability and supported.
requires an IGP for path computation. • To implement TE, devices need to exchange a large number of
• Both the IGP and LDP need to be deployed for the control plane, RSVP packets to maintain neighbor relationships and path states,
and devices need to exchange a large number of packets to wasting link bandwidth and device resources.
maintain neighbor relationships and path states, wasting link • RSVP-TE uses a distributed architecture, so that each device only
bandwidth and device resources. knows its own state and needs to exchange signaling packets with
• If LDP-IGP synchronization is not achieved, data forwarding may other devices.
fail.

6 Huawei Confidential
 SR Origin and Solution
⚫ The SDN concept has a great impact on the network industry, and many protocols used for SDN implementation emerge in the
industry, including OpenFlow, Protocol Oblivious Forwarding (POF), Programming Protocol-independent Packet Processors (P4), and
SR. Compared with revolutionary protocols, SR considers compatibility with the existing network and smooth evolution, and also
provides programmability. It is a de facto SDN standard.

Advantages Disadvantages Solutions

ECMP Lack of the path planning

IP capability SR-MPLS
Incremental deployment on the existing
Simple
LDP-IGP synchronization issue IP/MPLS network
configuration
Label-based LDP Lack of the load balancing
forwarding capability
Bandwidth Complex
reservation configuration/maintenance SRv6
RSVP-TE
No support for large-scale Extension based on the IPv6
Path planning Routing header
deployment

7 Huawei Confidential

• SR resolves many issues on IP/MPLS networks through two solutions: SR-MPLS (based on
MPLS forwarding) and SRv6 (based on IPv6 forwarding).
 From MPLS to SRv6
⚫ MPLS causes isolated network islands. SRv6 provides a unified forwarding plane and has advantages such as
simplified protocols, high scalability, and programmability.

Classic MPLS SR-MPLS SRv6

LDP
IGP + SR extension IGP + SR extension
Control plane RSVP-TE
IGP

Forwarding
plane Push Swap Pop Push Continue Next
MPLS 2004 MPLS 1368 MPLS 222
MPLS 1949 MPLS 1949 MPLS 111 MPLS 111 IPv6 + SRH IPv6 + SRH
Payload Payload Payload Payload Payload Payload Payload Payload Payload Payload Payload Payload

✓ Simplified protocols
✓ High scalability
Control plane simplification Forwarding plane simplification ✓ Programmability

8 Huawei Confidential

• Although MPLS plays an important role in the all-IP transformation of networks, it causes
isolated network islands. On the one hand, it increases the complexity of cross-domain
network interconnection. For example, solutions such as the MPLS VPN Option A/B/C
solution are complex to deploy and involve difficult E2E service deployment. On the other
hand, as the Internet and cloud computing develop, more and more cloud data centers are
built. To meet tenants' networking requirements, multiple overlay technologies have been
proposed, among which VXLAN is a typical example. In the past, quite a few attempts were
made to provide VPN services by introducing MPLS to data centers. However, these
attempts all wound up in failure due to multiple factors, including numerous network
boundaries, complex management, and insufficient scalability. As such, the traffic from an
end user to a service in a data center may typically need to pass through the VLAN, IP
network, IP/MPLS network, and VXLAN network.

• The combination of MPLS and SR is intended to provide programmability for networks as a

practice of SDN implementation. However, this cannot satisfy services (such as SFC and
IOAM) that need to carry metadata, as MPLS encapsulation has poor scalability. Nowadays,
the IPv4 address space is almost exhausted. IPv6 and SR are combined, promoting the
advent of SRv6.
Technical Benefits of SRv6
⚫ SRv6 simplifies existing network protocols and network management. In addition, SRv6 supports native IPv6 and provides the network programming
capability, making SRv6 more advantageous.
 Thanks to the native IPv6 attribute, SRv6 can better promote cloud-network convergence, be compatible with existing networks, and improve inter-AS experience.

 Thanks to the network programming capability, SRv6 can not only better implement path programming to meet service SLAs but also connect networks and applications
to build intelligent cloud-networks.
Promotion of
Controller cloud-network
Compatibility convergence
with existing
networks
Path programming to
Common IPv6 router meet service SLAs

SRv6 router
Data
download
Improved inter-
Video AS experience
Ingress

AS 65000 AS 65001

9 Huawei Confidential
 Contents

1. SRv6 Overview

2. SRv6 Fundamentals
◼ Basic Concepts of SRv6

▫ SRv6 Policy Path Establishment and Traffic Steering

▫ Typical SRv6 Applications

3. SRv6 High Reliability

4. Basic SRv6 Configuration

5. SRv6 Deployment Using iMaster NCE-IP

10 Huawei Confidential
SRv6 Fundamentals
⚫ SRv6 adds a Segment Routing header (SRH) to data on the ingress to guide data forwarding.
⚫ Without changing the original encapsulation format of IPv6 packets, SRv6 packets are still IPv6 ones and can be identified by
common IPv6 devices. As such, SRv6 is a native IPv6 technology.
⚫ SRv6's native IPv6 attribute enables SRv6 devices to interwork with common IPv6 devices, offering excellent compatibility on an
existing network. IPv6 Header IPv6 Header
D D
SRH C C
IPv6 Header
B B
D
Payload Payload
C
B
IPv6 Header Payload
Payload B C

Ingress D

11 Huawei Confidential
 SRv6 SRH SRv6 Node SRv6 Forwarding

IPv6 SRH
⚫ RFC 8754 defines the IPv6 SRH added to IPv6 packets. The SRH format is as follows:

IPv6 SRH (IPv6 Extension

IPv6 Header IPv6 Payload The value 43 indicates a routing extension header.
Header)

The recommended value of Routing Type for a routing extension header is

4, indicating an SR header (called SR extension header or SRH).
Version Traffic Class Flow Label
Payload Length Next=43 Hop Limit
Source Address ⚫ An SRH contains the following fields:

Destination Address  Segment List: an ordered list of SRv6 segment identifiers (SIDs).

Routing
 Segments Left (SL): number of remaining SRv6 segments. The SL value
Next Header Hdr Ext Len Segments Left is decremented and the destination IP address (DIP) is changed to an
Type=4 active SID to complete traffic forwarding segment by segment.
Last Entry Flags Tag  Tag: tags a packet as part of a class or group of packets to implement
Segment List [0] (128-bit IPv6 address) group-based policies.
Active
Segment List [1] (128-bit IPv6 address)  SRH TLVs (e.g. NSH metadata, HMAC TLV, and Padding TLV): can be
segment used as global parameters of SIDs in segment lists.
Segment List [2] (128-bit IPv6 address)
Optional TLV objects (variable)
IPv6 Payload

12 Huawei Confidential

• The biggest difference between SRv6 and SR-MPLS lies in the IPv6 SRH. SRv6 uses IPv6
extension headers to implement Segment Routing.

• For details, see https://datatracker.ietf.org/doc/rfc8754.

 SRv6 SRH SRv6 Node SRv6 Forwarding

SRv6 Segment
⚫ SRv6 segments are expressed using IPv6 addresses and usually called SRv6 SIDs.
⚫ As shown in the figure, an SRv6 SID usually consists of three fields: Locator, Function, and Arguments. They are
expressed in the Locator:Function:Arguments format. Note that the total length (Locator + Function + Arguments) is
less than or equal to 128 bits. If the total length is less than 128 bits, the reserved bits are padded with 0.
⚫ If the Arguments field does not exist, the format is Locator:Function. The Locator field occupies the most significant
bits of an IPv6 address, and the Function field occupies the remaining part of the IPv6 address.

IPv6 SRH (IPv6 Extension Header)

IPv6 Header IPv6 Payload
128 bits 128 bits 128 bits

SRv6 segment: IPv6 address

Locator Function Arguments
format

13 Huawei Confidential
 SRv6 SRH SRv6 Node SRv6 Forwarding

SRv6 Segment: Locator

128 bits Locator Function Arguments

IPv6 prefix
⚫ The Locator field identifies the location of a network node, and is used for other nodes to route and forward packets to this
identified node so as to implement network instruction addressing.
⚫ A locator has two important characteristics: routable and aggregatable. After a locator is configured for a node, the system
generates a locator route and propagates the route throughout the SR domain using an IGP, allowing other nodes to locate the
node based on the received locator route information. In addition, all SRv6 SIDs advertised by the node are reachable through the
route.
⚫ In the following example, a locator with the 64-bit prefix 2001:DB8:ABCD:: is configured for a Huawei device.

[Huawei] segment-routing ipv6

[Huawei-segment-routing-ipv6] locator srv6_locator1 ipv6-prefix 2001:DB8:ABCD:: 64

14 Huawei Confidential

• The locator is routable and therefore usually unique in an SR domain. In some scenarios,
such as an anycast protection scenario, multiple devices may be configured with the same
locator.
 SRv6 SRH SRv6 Node SRv6 Forwarding

SRv6 Segment: Function & Arguments

128 bits Locator Function Arguments

Opcode Optional

⚫ The Function field identifies the forwarding behavior to be performed. In SRv6 network programming, forwarding behaviors are
identified using different functions. For example, RFC defines End, End.X, End.DX4, and End.DX6 behaviors.
⚫ An End.X SID is similar to an adjacency SID in SR-MPLS and is used to identify a link. A configuration example is as follows:

[Huawei-segment-routing-ipv6] locator srv6_locator1 ipv6-prefix 2001:DB8:ABCD:: 64

[Huawei-segment-routing-ipv6] opcode ::1 end-x interface G3/0/0 next-hop 2001:DB8:200::1

⚫ The opcode corresponding to the function is ::1. In this example, the Arguments field is not carried, and the
SRv6 SID is 2001:db8:abcd::1.

⚫ This function guides packet forwarding from the specified interface (G3/0/0) to the corresponding neighbor
(2001:DB8:200::1).

15 Huawei Confidential

• In some scenarios, an SRv6 endpoint behavior may require additional actions. In this case,
the Arguments field must be encapsulated. For example, in an EVPN VPLS scenario where
CE multi-homing is deployed for BUM traffic forwarding, the Function field is set to
End.DT2M, and the Arguments field is used to provide local ESI mapping to implement split
horizon.

• The Function and Arguments fields can both be defined by engineers, resulting in an SRv6
SID structure that improves network programmability. In most scenarios, the Arguments
field is not configured.
 SRv6 SRH SRv6 Node SRv6 Forwarding

SRv6 Segment Types

Category Function Description Protocol Type
Indicates an endpoint SID that identifies a destination node. The corresponding function is to update the IPv6 DA
End IGP Path SID
and then search the IPv6 forwarding information base (FIB) for packet forwarding.
Indicates a Layer 3 cross-connect endpoint SID that identifies a link. The corresponding function is to update the
End.X IGP Path SID
IPv6 DA and then forward packets through the outbound interface bound to the End.X SID.
Indicates a PE-specific endpoint SID that identifies an IPv4 VPN instance. The corresponding function is to
Service
End.DT4 decapsulate packets and then search the routing table of the involved IPv4 VPN instance for packet forwarding. BGP
SID
This SID is equivalent to an IPv4 VPN label and used in L3VPNv4 scenarios.
Indicates a PE-specific endpoint SID that identifies an IPv6 VPN instance. The corresponding function is to
Service
End.DT6 decapsulate packets and then search the routing table of the involved IPv6 VPN instance for packet forwarding. BGP
SID
This SID is equivalent to an IPv6 VPN label and used in L3VPNv6 scenarios.
Indicates a PE-specific Layer 3 cross-connect endpoint SID that identifies an IPv4 CE. The corresponding function is
Service
End.DX4 to decapsulate packets and then forward the resulting IPv4 packets through the Layer 3 interface bound to the BGP
SID
SID. This SID is equivalent to a label identifying an adjacency to a CE and used in L3VPNv4 scenarios.
Indicates a PE-specific Layer 3 cross-connect endpoint SID that identifies an IPv6 CE. The corresponding function is
Service
End.DX6 to decapsulate packets and then forward the resulting IPv6 packets through the Layer 3 interface bound to the BGP
SID
SID. This SID is equivalent to a label identifying an adjacency to a CE and used in L3VPNv6 scenarios.

16 Huawei Confidential

• In addition to L3VPN services, SRv6 can carry L2VPN services. L2VPN-related SIDs are as
follows:

▫ End.DX2: Indicates a Layer 2 cross-connect endpoint SID that identifies an endpoint.

The corresponding function is to decapsulate packets, remove the IPv6 header (along
with all its extension headers), and then forward the remaining packet data to the
outbound interface associated with the SID. This SID can be used in EVPN VPWS
scenarios. If a bypass tunnel exists on the network, an End.DX2L SID is generated
automatically.

▫ End.DT2U: Indicates a Layer 2 cross-connect endpoint SID that requires unicast MAC
table lookup and identifies an endpoint. If a bypass tunnel exists on the network, an
End.DT2UL SID is generated automatically. This SID can be used to guide unicast
traffic forwarding over the bypass tunnel when a CE is dual-homed to PEs. The
corresponding function is to remove the IPv6 header (along with all its extension
headers), search the MAC address table for a MAC entry based on the exposed
destination MAC address, and then forward the remaining packet data to the
corresponding outbound interface based on the entry. This SID can be used in EVPN
VPLS unicast scenarios.
 ▫ End.DT2M: Indicates a Layer 2 cross-connect endpoint SID that requires broadcast-
based flooding and identifies an endpoint. The corresponding function is to remove
the IPv6 header (along with all its extension headers) and then broadcast the
remaining packet data in the Bridge Domain (BD). This SID can be used in EVPN VPLS
BUM scenarios.

• SRv6 SID mainly used for SRv6 O&M:

▫ End.OP (OAM Endpoint with Punt): Indicates an OAM SID. The corresponding
function is to send OAM packets to the OAM process. This SID is mainly used in
ping/tracert scenarios.
 SRv6 SRH SRv6 Node SRv6 Forwarding

Naming Rules for SRv6 Segments

⚫ SRv6 segments are named according to certain rules. You can quickly determine the corresponding instruction function based on
the naming rule combination.
 End: the most basic instruction executed by a segment endpoint node, directing the node to terminate the current instruction and start the next
instruction. The corresponding forwarding behavior is to decrement the SL field by 1 and copy the SID pointed by the SL field to the DA field in
the IPv6 header.

 X: forwards packets through one or a group of Layer 3 outbound interfaces.

 T: searches a specified routing table and forwards packets.

 D: decapsulates packets by removing the IPv6 header and related extension headers.

 V: searches a specified table for packet forwarding based on virtual local area network (VLAN) information.

 U: searches a specified table for packet forwarding based on unicast MAC address information.

 M: searches a Layer 2 forwarding table for multicast forwarding.

 B6: applies a specified SRv6 Policy.

 BM: applies a specified SR-MPLS Policy.

18 Huawei Confidential
 SRv6 SRH SRv6 Node SRv6 Forwarding

SRv6 Segment Examples

⚫ An End SID identifies a destination node. It is similar to a node SID in SR-MPLS. After an End SID is generated on a node, the node propagates the SID to all the other nodes in
the SRv6 domain through an IGP. All nodes in the SRv6 domain know how to implement the instruction bound to the SID.

⚫ An End.X SID is a Layer 3 cross-connect endpoint SID that identifies a link. It is similar to an adjacency SID in SR-MPLS. After an End.X SID is generated on a node, the node
propagates the SID to all the other nodes in the SRv6 domain through an IGP. Although the other nodes can all obtain the SID, only the node generating the SID knows how to
implement the instruction bound to the SID.

⚫ An End.DT4 SID is a PE-specific endpoint SID that identifies an IPv4 VPN instance. The instruction bound to the End.DT4 SID is to decapsulate packets and search the routing
table of the corresponding IPv4 VPN instance for packet forwarding. The End.DT4 SID is equivalent to an IPv4 VPN label and used in L3VPNv4 scenarios. It can be either
manually configured or automatically allocated by BGP within the dynamic SID range of the specified locator.

End SID End SID End SID

2001:DB8:1000::111 2001:DB8:2000::222 2001:DB8:3000::333
PE1 P PE2
End.X SID End.X SID End.X SID End.X SID
2001:DB8:1000::12 2001:DB8:2000::21 2001:DB8:2000::23 2001:DB8:3000::32

VPNA: End.DT4 SID AS 65000 VPNA: End.DT4 SID

2001:DB8:1000::1:0:1E 2001:DB8:3000::1:0:1E

Loopback1 Loopback1
10.1.4.4/32 10.1.5.5/32
CE1 AS 65001 AS 65002 CE2

19 Huawei Confidential
 SRv6 SRH SRv6 Node SRv6 Forwarding

SRv6 Flavors
⚫ Flavors are additional behaviors defined for SRv6 segment enhancement. These behaviors are optional and used to
enhance SRv6 segment-based actions in order to meet diverse service requirements.
⚫ SRv6-Network-Programming defines the following additional behaviors: penultimate segment pop of the SRH (PSP),
ultimate segment pop of the SRH (USP), and ultimate segment decapsulation (USD).

Flavor Function Description Attached End Instruction

End, End.X, End.DT2, End.DT4, and

PSP Removes the SRH on the penultimate endpoint node.
End.DT6

End, End.X, End.DT2, End.DT4, and

USP Removes the SRH on the ultimate endpoint node.
End.DT6

End, End.X, End.DT2, End.DT4, and

USD Decapsulates the outer IPv6 header on the ultimate endpoint node.
End.DT6

20 Huawei Confidential

• Different flavors can be combined. For example, if an End SID carries PSP and USP flavors,
the PSP action is performed on the penultimate node, and the USD action is performed on
the ultimate node.
 SRv6 SRH SRv6 Node SRv6 Forwarding

SRv6 Locator Configuration Commands

1. Enable SRv6 and enter the SRv6 view.
[Huawei] segment-routing ipv6
After running the segment-routing ipv6 command, you can configure a locator and SRv6 SID in the SRv6 view so that an SRv6
local SID forwarding entry can be generated.
2. Configure an SRv6 SID locator.
[Huawei-segment-routing-ipv6] locator locator-name [ ipv6-prefix ipv6-address prefix-length [ [ static static-length ] | [ args
args-length ] ] * ]

An SRv6 SID is a 128-bit IPv6 address expressed in the Locator:Function:Arguments format.

• The Locator field corresponds to the ipv6-prefix ipv6-address parameter and its length is determined by the prefix-length
parameter.
• The Function field is also called opcode, which can be dynamically allocated using an IGP or be configured using the opcode
command. When configuring a locator, you can use the static static-length parameter to specify the static segment length,
which determines the number of static opcodes that can be configured in the locator. In dynamic opcode allocation, the IGP
allocates opcodes outside the range of the static segment, so that no SRv6 SID conflict occurs.
• The Args field is determined by the args args-length parameter. It is optional in SRv6 SIDs and depends on command
configurations.

21 Huawei Confidential

• static static-length: specifies the static segment length in the Function field. This length
determines the number of static opcodes that can be configured in the specified locator.

• args args-length: specifies the length of the Arguments field. The Arguments field is located
at the end of a SID. If args args-length is configured, the Arguments field is reserved and
will not be occupied by configured static SIDs or generated dynamic SIDs.
 SRv6 SRH SRv6 Node SRv6 Forwarding

SRv6 SID Configuration Commands

1. Configure a static End SID opcode.

[Huawei-segment-routing-ipv6-locator] opcode func-opcode end [no-flavor | psp | psp-usp-usd ]

An End SID identifies an SRv6 node.

2. Configure a static End.X SID opcode.

[Huawei-segment-routing-ipv6-locator] opcode func-opcode end-x interface {interface-name | interface-type interface-number}

nexthop nexthop-address [no-flavor | psp | psp-usp-usd]

An End.X SID identifies a Layer 3 adjacency of an SRv6 node. Therefore, you need to specify an interface and the next hop
address of the interface during the configuration.

22 Huawei Confidential
 SRv6 SRH SRv6 Node SRv6 Forwarding

SRv6 Locator Configuration Example

⚫ SRv6 SIDs can be statically configured or dynamically allocated. In dynamic allocation mode, only the locator command needs to be run, and the
required opcode is dynamically allocated by an IGP. In static configuration mode, you need to manually configure an opcode for the SIDs of the
corresponding type.

⚫ The relationship of parameters in the locator command is as follows:

|--Locator--|--Dynamic Opcode--|--Static Opcode--|--Args--|

[Huawei-segment-routing-ipv6] locator srv6_locator1 ipv6-prefix 2001:DB8:ABCD:: 64 static 32

⚫ In static configuration mode, SIDs occupy only the static segment with values starting from 1, and the dynamic segment is set to 0. In dynamic
allocation mode, SIDs occupy both the dynamic segment and static segment. The values in the dynamic segment start from 1, and those in the static
segment start from 0.

⚫ In this example, the locator 2001:DB8:ABCD:: is configured, and its length is 64 bits. The static segment occupies 32 bits, the dynamic segment 32 bits,
and the Args field 0 bits. The value range is as follows:
 Static segment: The start value is 2001:DB8:ABCD:0000:0000:0000:0000:0001, and the end value is 2001:DB8:ABCD:0000:0000:0000:FFFF:FFFF.

 Dynamic segment: The start value is 2001:DB8:ABCD:0000:0000:0001:0000:0000, and the end value is 2001:DB8:ABCD:0000:FFFF:FFFF:FFFF:FFFF.

Statically configuring End and End.X SIDs is recommended. Dynamically allocated SIDs will change after a device
restart, adversely affecting maintenance.

23 Huawei Confidential
 SRv6 SRH SRv6 Node SRv6 Forwarding

SRv6 Node
⚫ RFC 8754 defines three types of SR nodes:
 SR source node: a source node that encapsulates packets with SRv6 headers.
 Transit node: an IPv6 node that forwards SRv6 packets but does not perform SRv6 processing.
 SRv6 segment endpoint node: a node that receives and processes SRv6 packets in which the destination IPv6
address is a local SID or local interface address of the node.

Source Node Transit Node Endpoint Node Endpoint Node

FC01:: /96 FC02:: /96 FC03:: /96 FC04:: /96
FC01::1 FC02::2 FC03::3 FC04::4

CE2: End.DT4
CE1 R1 R2 R3 R4 FC04::400 CE2

FC01:: /96 Locator

FC01::1 End SID

24 Huawei Confidential
 SRv6 SRH SRv6 Node SRv6 Forwarding

SRv6 Source Node

⚫ An SRv6 source node steers a packet using an SRv6 segment list. If the SRv6 segment list contains only one SID, and
no Type Length Value (TLV) or other information needs to be added to the packet, the DA field of the packet is set to
this SID.
⚫ An SRv6 source node can be either an SRv6-capable host where IPv6 packets originate or an edge device in an SRv6
domain.
Source Node Transit Node Endpoint Node Endpoint Node
FC01:: /96 FC02:: /96 FC03:: /96 FC04:: /96
FC01::1 FC02::2 FC03::3 FC04::4

CE2: End.DT4
CE1 R1 R2 R3 R4 FC04::400 CE2
IPv6 Header
SRH (SL = 2) FC01:: /96 Locator
FC04::400 FC04::4 FC03::3 FC01::1 End SID
Payload

SRv6 Policy

25 Huawei Confidential
 SRv6 SRH SRv6 Node SRv6 Forwarding

Source Node Behaviors

⚫ An SRv6 source node steers packets into an SRv6 Policy and, if possible, encapsulates SRHs into the packets. The
following table lists the behaviors of an SRv6 source node.
Source Node
Function Description
Behavior
Inserts an SRH into a received IPv6 packet and searches the IPv6 Header
H.Insert Insert
corresponding routing table for packet forwarding. IPv6 Header
SRH
Payload
Inserts a reduced SRH into a received IPv6 packet and searches the Payload
H.Insert.Red
corresponding routing table for packet forwarding.

Encapsulates an outer IPv6 header and SRH for a received IP packet, and
H.Encaps
searches the corresponding routing table for packet forwarding.
IPv6 Header
Encapsulates an outer IPv6 header and reduced SRH for a received IP IPv6 Header Encaps
SRH
H.Encaps.Red packet, and searches the corresponding routing table for packet Payload
forwarding. IPv6 Header
Payload
Encapsulates an outer IPv6 header and SRH for a received Layer 2 frame,
H.Encaps.L2
and searches the corresponding routing table for forwarding.

Encapsulates an outer IPv6 header and reduced SRH for a received Layer
H.Encaps.L2.Red
2 frame, and searches the corresponding routing table for forwarding.

26 Huawei Confidential

• The difference between a reduced SRH and an SRH is that the segment list in a reduced SRH
does not contain the first segment in an existing IPv6 DA.
 SRv6 SRH SRv6 Node SRv6 Forwarding

Transit Node
⚫ A transit node is an IPv6 node that does not participate in SRv6 processing on the SRv6 packet forwarding path. That is, the transit
node just performs ordinary IPv6 packet forwarding.

⚫ After receiving an SRv6 packet, the node parses the IPv6 DA field in the packet. If the IPv6 DA is neither a locally configured SRv6
SID nor a local interface address, the node considers the SRv6 packet as an ordinary IPv6 packet and searches the routing table for
packet forwarding without processing the SRH.
⚫ A transit node can be either an ordinary IPv6 node or an SRv6-capable node.
Source Node Transit Node Endpoint Node Endpoint Node
FC01:: /96 FC02:: /96 FC03:: /96 FC04:: /96
FC01::1 FC02::2 FC03::3 FC04::4

CE2: End.DT4
CE1 R1 R2 R3 R4 FC04::400 CE2

IPv6 Header
FC01:: /96 Locator
SRH (SL = 2)
FC01::1 End SID
FC04::400 FC04::4 FC03::3
Payload

27 Huawei Confidential
 SRv6 SRH SRv6 Node SRv6 Forwarding

Endpoint Node
⚫ An endpoint node is a node that receives an SRv6 packet destined for itself (a packet of which the IPv6 destination address is a local SID).

⚫ For example, R3 searches its local SID table based on the IPv6 DA FC03::3 of the packet and finds a matching End SID. Then, R3 decrements the SL
value by 1, uses the SID whose SL value is 1 as the destination IPv6 address, searches the routing table, and forwards the packet.

⚫ There may be multiple endpoint nodes on the data forwarding path. Each endpoint node provides services such as packet forwarding, encapsulation,
and decapsulation.

Source Node Transit Node Endpoint Node Endpoint Node

FC01:: /96 FC02:: /96 FC03:: /96 FC04:: /96
FC01::1 FC02::2 FC03::3 FC04::4
CE2: End.DT4
FC04::400
CE1 R1 R2 R3 R4 CE2
IPv6 Header
SRH (SL = 1)
FC01:: /96 Locator
FC04::400 FC04::4 FC03::3
FC01::1 End SID
Payload

28 Huawei Confidential

• Each SRv6 node maintains a local SID table that contains all SRv6 SIDs generated on the
node, and an SRv6 FIB can be generated based on the table. The local SID table provides the
following functions:

▫ Defines locally generated SIDs, such as End.X SIDs.

▫ Specifies instructions bound to the SIDs.

▫ Stores forwarding information related to the instructions, such as outbound interface

and next hop information.
 SRv6 SRH SRv6 Node SRv6 Forwarding

SRv6 Forwarding Modes

⚫ SRv6 supports two forwarding modes: SRv6 Policy and SRv6 BE.
 In addition to implementing traffic engineering, SRv6 Policy can work with a controller to meet differentiated service
requirements more effectively, achieving a service-driven network.
 SRv6 BE is a simplified implementation of SRv6. Typically, it can provide only best-effort forwarding and does not involve SRHs.

⚫ In the initial phase of SRv6 deployment, SRv6 BE can be used to quickly provision services based on IPv6 route
reachability, offering unparalleled advantages. During future evolution, transit nodes can be upgraded on demand
and SRv6 Policy can be deployed to meet the requirements of high-value services.

29 Huawei Confidential
 SRv6 SRH SRv6 Node SRv6 Forwarding

SRv6 Locator Information Propagation

⚫ No matter whether traffic is forwarded in SRv6 BE or SRv6 Policy mode, a router can forward SRv6 packets only after
obtaining SRv6 locator-related routing information.
⚫ SRv6 nodes usually use an extended IGP (extended OSPFv3 or IS-IS) to propagate locator-related routing information
to network nodes, including the source, transit, and endpoint nodes.
Source Node Transit Node Endpoint Node Endpoint Node Endpoint Node
FC01:: /96 FC02:: /96 FC03:: /96 FC04:: /96 FC05:: /96
FC01::1 FC02::2 FC03::3 FC04::4 FC05::5

IGP IGP IGP IGP

R1 R2 R3 R4 R5
IPv6 Routing Table IPv6 Routing Table IPv6 Routing Table IPv6 Routing Table IPv6 Routing Table
Dest Len NHP Dest Len NHP Dest Len NHP Dest Len NHP Dest Len NHP
FC01:: 96 Local FC01:: 96 R1 FC01:: 96 R2 FC01:: 96 R3 FC01:: 96 R4
FC03:: 96 R2 FC03:: 96 R3 FC03:: 96 Local FC03:: 96 R3 FC03:: 96 R4
FC04:: 96 R2 FC04:: 96 R3 FC04:: 96 R4 FC04:: 96 Local FC04:: 96 R4
FC05:: 96 R2 FC05:: 96 R3 FC05:: 96 R4 FC05:: 96 R5 FC05:: 96 Local

FC01:: /96 Locator

FC01::1 End SID

30 Huawei Confidential
 SRv6 SRH SRv6 Node SRv6 Forwarding

Forwarding in SRv6 BE Mode

⚫ Traditional MPLS involves two control protocols: LDP and RSVP-TE. The former uses IGP path computation results to
establish LDP LSPs and guide traffic forwarding, but it does not support traffic engineering. Similar to LDP, SRv6 BE
uses only one service SID to guide packet forwarding on an IP network in best-effort mode.
⚫ In SRv6 BE mode, the forwarding path is computed based on the IGP cost.

Source Node Transit Node Endpoint Node Endpoint Node Endpoint Node
FC01:: /96 FC02:: /96 FC03:: /96 FC04:: /96 FC05:: /96
FC01::1 FC02::2 FC03::3 FC04::4 FC05::5

R1 R2 R3 R4 R5
DIPv6: FC05::5 DIPv6: FC05::5 DIPv6: FC05::5 DIPv6: FC05::5
SIPv6: FC01::1 SIPv6: FC01::1 SIPv6: FC01::1 SIPv6: FC01::1
Payload Payload Payload Payload
FC01:: /96 Locator
FC01::1 End SID

31 Huawei Confidential
 SRv6 SRH SRv6 Node SRv6 Forwarding

Forwarding in SRv6 Policy Mode

⚫ In SRv6 forwarding, each time a packet passes through an SRv6 endpoint node, the SL field is decremented by 1 and the IPv6 DA in the IPv6 header
changes. The SL and Segment List fields are both used to determine an IPv6 DA.
Source Node Transit Node Endpoint Node Endpoint Node Endpoint Node
FC01:: /96 FC02:: /96 FC03:: /96 FC04:: /96 FC05:: /96
FC01::1 FC02::2 FC03::3 FC04::4 FC05::5

R1 R2 R3 R4 R5
DIPv6: FC03::3 DIPv6: FC03::3 DIPv6: FC04::4 DIPv6: FC05::5 DIPv6: FC05::5
SIPv6: FC01::1 SIPv6: FC01::1 SIPv6: FC01::1 SIPv6: FC01::1 SIPv6: FC01::1
SRH (SL = 2) SRH (SL = 2) SRH (SL = 1) SRH (SL = 0) Payload
FC05::5 FC05::5 FC05::5 FC05::5
FC04::4 FC04::4 FC04::4 FC04::4 If the type of the SID whose SL value is 0
FC03::3 FC03::3 FC03::3 FC03::3 is End, End.X, or End.DT, the SRH is
removed on the penultimate segment by
Payload Payload Payload Payload
default.
FC01:: /96 Locator
FC01::1 End SID
⚫ Different from SR-MPLS label processing, SRv6 SRH processing is implemented from the bottom up, and segments in the SRv6 SRH are not popped
after being processed by a node. Therefore, the SRv6 header can be used for path backtracking.

32 Huawei Confidential

• In MPLS, different removal options are defined using the Implicit-Null and Non-null options.
Penultimate hop popping (PHP) in the MPLS data plane refers to the process in which the
outermost label of the MPLS label stack is removed by an LSR before the packet reaches the
adjacent label edge router (LER). If PHP is not enabled on the MPLS network, the LER is
responsible for removing the label.

• These behaviors are defined as two functions in SRv6: PSP and USP.
 Contents

1. SRv6 Overview

2. SRv6 Fundamentals
▫ Basic Concepts of SRv6
◼ SRv6 Policy Path Establishment and Traffic Steering

▫ Typical SRv6 Applications

3. SRv6 High Reliability

4. Basic SRv6 Configuration

5. SRv6 Deployment Using iMaster NCE-IP

33 Huawei Confidential
 SRv6 Policy Overview
⚫ SRv6 Policy is a new traffic steering technology developed based on SRv6.
⚫ An SRv6 Policy is a set of candidate paths consisting of one or more segment lists, that is, SID
lists. Each SID list identifies an E2E path from the source to the destination, instructing a device
to forward traffic through the path rather than the shortest path computed using an IGP.
⚫ If a packet is steered into an SRv6 Policy, the headend adds a SID list into the packet, and other
devices receiving the packet execute the instructions encapsulated into the list.

34 Huawei Confidential

• https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/
 SRv6 Policy Identification
⚫ An SRv6 Policy is identified by the tuple <headend, color, endpoint>.
⚫ For an SRv6 Policy with a specified headend, it is identified only using <color, endpoint>.
 Headend: node where an SRv6 Policy is originated. Generally, it is a globally unique IP address.
 Color: 32-bit extended community attribute. It is used to identify a type of service intent (e.g. low delay).
 Endpoint: destination address of an SRv6 Policy. Generally, it is a globally unique IPv6 address.

⚫ On the specified headend, the color and endpoint are used to identify the forwarding path of the corresponding
SRv6 Policy.
Color 15
SRv6 Policy 1 <color 15, endpoint 1>
Color 20 Endpoint 1

SRv6 Policy 2 <color 20, endpoint 2>

Color 20 Endpoint 2
SRv6 Policy 3 <color 25, endpoint 2>
Color 25

35 Huawei Confidential

• An endpoint in an SRv6 Policy is different from an endpoint node in SRv6.

▫ The endpoint node in SRv6 refers to the type of the device that processes the SRH.

▫ The endpoint in an SRv6 Policy refers to the policy's egress, which is generally
expressed using an IPv6 address.
 SRv6 Policy Path Establishment Traffic Steering to SRv6 Policies

SRv6 Policy Path Model

⚫ One SRv6 Policy may contain multiple candidate paths with the preference attribute. The valid candidate path with the highest preference functions
as the primary path of the SRv6 Policy, and the valid candidate path with the second highest preference functions as a backup path.

⚫ A candidate path is an SRv6 Policy's basic unit that is manually configured or is sent to the headend through BGP IPv6 SR Policy.

⚫ Weights can be configured for segment lists to control load balancing among SRv6 paths.

Segment list 1
SR Policy P1 <headend, color, endpoint>
Weight Candidate-path CP1 <protocol, origin, discriminator>
Primary path Preference 200
SRv6 Policy Candidate path 1 Segment list 2 Weight W1, SID-List1 <SID11...SID1i>
Weight W2, SID-List2 <SID21...SID2j>
Preference 200 Weight Candidate-path CP2 <protocol, origin, discriminator>
<Headend, color,
Preference 100
endpoint>
Weight W3, SID-List3 <SID31...SID3i>
Candidate path 2 Segment list 1 Weight W4, SID-List4 <SID41...SID4j>

Preference 100 Weight

Backup path

36 Huawei Confidential

• SR Policy P1 is uniquely determined by the triplet <headend, color, endpoint>.

• An SR Policy can contain multiple candidate paths (e.g. CP1 and CP2). Each of the paths is
uniquely determined by the triplet <protocol, origin, discriminator>.

• CP1 is the primary path because it is valid and has the highest preference. The two SID lists
of CP1 are delivered to the forwarder, and traffic is balanced between the two paths based
on weights. For the SID list <SID11...SID1i>, traffic is balanced according to W1/(W1+W2).
 SRv6 Policy Path Establishment Traffic Steering to SRv6 Policies

Overview of SRv6 Policy Path Establishment

⚫ In Huawei's SRv6 Policy solution architecture, the controller (iMaster NCE-IP) is used to establish SRv6 Policy paths.
 The controller uses BGP-LS to collect topology information collected through an extended IGP to compute SRv6 Policy paths and display state information.

 The controller uses BGP IPv6 SR Policy to deliver SRv6 Policy information (e.g. headend, color, and endpoint) to the headend.

⚫ Huawei's SRv6 Policy solution also uses NETCONF to deliver other configurations, such as service interfaces and route-policies (with the color
attribute).

⚫ In addition to delivering SRv6 Policies through iMaster NCE-IP, you can also manually deploy SRv6 Policies.

Extended IS-IS
1. BGP-LS
Color
2. BGP IPv6 SR Policy

3. NETCONF
Headend Endpoint

37 Huawei Confidential

• Mainstream methods for SRv6 Policy implementation:

▫ BGP: BGP-LS is used to collect topology information, so that no new interface

protocol needs to be introduced for customer-developed controllers. BGP IPv6 SR
Policy is used to deliver route information.

▫ PCEP: is a mature southbound protocol used in SR-MPLS TE scenarios. However, the

tunnel implementation models of vendors are different and cannot interwork, and
the interaction process of PCEP is more complex than that of BGP. As such, BGP
extension is recommended.

▫ NETCONF/YANG: delivers tunnel paths to forwarders as configurations. This method

is not recommended because it delivers configurations in essence and offers the
poorest performance. In a comprehensive solution, NETCONF is used to deliver
configurations other than tunnel configurations.

• Huawei devices mainly use BGP to deploy SRv6 Policies.

 SRv6 Policy Path Establishment Traffic Steering to SRv6 Policies

Information Collection Through BGP-LS

⚫ In Huawei's SRv6 Policy solution architecture, BGP-LS mainly provides the following functions:
 Advertises the topology, prefix, SRv6 locator, and SID information collected by IS-IS/OSPFv3 to iMaster NCE-IP through BGP-LS routes.

 Advertises the SRv6 Policy status through BGP-LS routes.

[~PE1]display bgp link-state unicast routing-table

Total Number of Node Routes: 36

*> Network : [NODE][ISIS-LEVEL-2][IDENTIFIER0][LOCAL[as65001][bgp-ls-identifier1.0.0.1][ospf-
area-id0.0.0.0][igp-router-id0010.0000.0001.00]] //Topology node information
BGP-LS
IS-IS System ID
0010.0000.0001.00
PE1 RR PE3 *> Network : [LINK][ISIS-LEVEL-2][IDENTIFIER0][LOCAL[as65001][bgp-ls-identifier1.0.0.1][ospf-
area-id0.0.0.0][igp-router-id0010.0000.0001.00]][REMOTE[as65001][bgp-ls-identifier1.0.0.1][ospf-
area-id0.0.0.0][igp-router-id0010.0000.0002.00]][LINK[if-address10.0.0.26][peer-address10.0.0.25][if-
Color 16 address::][peer-address::]] //Topology link information

*> Network : [SRV6-SID][ISIS-LEVEL-2][IDENTIFIER0][LOCAL[as65001][bgp-ls-identifier1.0.0.1][ospf-

area-id0.0.0.0][igp-router-id0010.0000.0006.00]][SID[mt-id2][sidFC00:6::1]] //SRv6 SID information

*> Network : [TEPOLICY][SEGMENT-ROUTING][IDENTIFIER0][LOCAL[as65001][bgp-ls-

PE2 P1 PE4 identifier1.0.0.1][bgp-router-id1.0.0.1][ipv4-router-id0.0.0.0][ipv6-router-idFC01::1]][TE[protocol-
IS-IS System ID End SID Loopback origin2][Flag128][endpointFC01::4][color16][originator-as65001][originator-
0010.0000.0002.00 FC00:6::1 FC01::4 address172.21.17.102][discriminator49]] //SRv6 Policy status

SRv6 Policy
BGP-LS peer

38 Huawei Confidential

• BGP-LS connection:

▫ Collects tunnel topology information for SR Policy path computation.

▫ BGP-LS supports the collection of SR Policy status information, based on which the
controller displays tunnel status. https://datatracker.ietf.org/doc/draft-ietf-idr-te-lsp-
distribution/

▫ BGP-LS supports SRLB information encapsulation and decapsulation, so that the

controller can obtain the SRLB information for binding SID allocation. (The backup
path of each SR Policy corresponds to a binding SID.)

▫ BGP-LS also needs to be deployed on the headend to advertise the SRv6 Policy status.
 SRv6 Policy Path Establishment Traffic Steering to SRv6 Policies

Path Delivery Through BGP IPv6 SR Policy

⚫ iMaster NCE-IP can deliver an SRv6 Policy to the specified headend through the BGP IPv6 SR Policy peer relationship.
⚫ An SRv6 Policy is represented as [distinguisher][color][endpoint] in the BGP routing table.

[~PE1]display bgp sr-policy ipv6 routing-table [49][16][FC01::4]

BGP local router ID : 1.0.0.1

End SID Local AS number : 65001
FC00:5::1 Paths: 2 available, 1 best, 1 select, 0 best-external, 0 add-path
PE1 RR PE3 BGP routing table entry information of [49][16][FC01::4]:
Headend ...
Tunnel Encaps Attribute (23):
DIPv6: FC00:5::1 Color 16 Tunnel Type: SR Policy (15)
SIPv6: FC00:1::1 Preference: 10
SRH (SL = 2) Binding SID: FC00:1::1:1, s-flag(0), i-flag(0)
End.X SID Segment List
FC00:6::1:60
FC00:6::1:60 Weight: 1
FC00:6::1
FC00:5::1 Path MTU: 9600
PE2 P1 PE4 Segment: type:2, SID: FC00:5::1
Payload End SID Loopback Segment: type:2, SID: FC00:6::1
FC00:6::1 FC01::4 Segment: type:2, SID: FC00:6::1:60
Template ID: 4294967278
SRv6 Policy Not advertised to any peer yet
BGP SR-Policy peer

39 Huawei Confidential

• BGP IPv6 SR Policy connection:

▫ The controller delivers SRv6 Policy information to forwarders for SRv6 Policy
generation.

▫ BGP routes delivered by the controller carry the color community attribute, which
can be transmitted. The headend finds a matching BGP route and recurses it to the
corresponding SRv6 Policy based on the color and endpoint information.

▫ In Huawei's SRv6 Policy solution, path computation constraints of each application

need to be uniformly planned on the controller based on SLAs, and different colors
are used to identify SRv6 Policies. An SRv6 Policy is uniquely identified by <headend,
color, endpoint>. The BGP route of services to be steered into an SRv6 Policy needs
to carry the corresponding color attribute.

• Binding SIDs are mainly used for path stitching.

 SRv6 Policy Path Establishment Traffic Steering to SRv6 Policies

Inter-AS SRv6 Policy Path Establishment

⚫ SRv6 devices need to obtain network-wide SIDs to implement E2E data forwarding.

⚫ In an AS, devices can use an extended IGP (extended OSPFv3 or IS-IS) to obtain intra-AS SID information. In inter-AS scenarios, however, BGP egress
peer engineering (EPE) needs to be used to transmit SID information.

IGP route (carrying BGP route (carrying

Mutual route SRv6-related route Mutual route IGP route (carrying
SRv6-related route import between import between
information) SRv6-related route
information) IS-IS and BGP IS-IS and BGP
BGP EPE information)
processes processes
AS 65001 IS-IS IS-IS AS 65002
FC02::1B FC03::1B

FC02::1C FC03::1C
FC01::1 FC02::2 FC03::3 FC04::4

DIPv6: FC02::2 DIPv6: FC02::1C DIPv6: FC03::3 DIPv6: FC04::4

SIPv6: FC01::1 SIPv6: FC01::1 SIPv6: FC01::1 SIPv6: FC01::1
SRH (SL = 3) SRH (SL = 2) SRH (SL = 1) SRH (SL = 0)
FC04::4 FC04::4 FC04::4 FC04::4
FC03::3 FC03::3 FC03::3 FC03::3
FC02::1C FC02::1C FC02::1C FC02::1C FC02::1C End.X SID
FC02::2 FC02::2 FC02::2 FC02::2
FC02::2 End SID
Payload Payload Payload Payload

40 Huawei Confidential

• BGP EPE can allocate BGP peer SIDs to inter-AS paths. Peer SIDs are classified into the
following types:

▫ A Peer-Node SID identifies a peer node. The peers at both ends of each BGP session
are allocated with Peer-Node SIDs. An EBGP peer relationship established based on
loopback interfaces may traverse multiple physical links. In this case, the Peer-Node
SID of a peer is mapped to multiple outbound interfaces. Peer-Node SIDs are End
SIDs.

▫ A Peer-Adj SID identifies an adjacency to a peer. An EBGP peer relationship

established based on loopback interfaces may traverse multiple physical links. In this
case, each adjacency is allocated with a Peer-Adj SID. Only the specified link (mapped
to the specified outbound interface) can be used for forwarding. Peer-Adj SIDs are
End.X SIDs.

• BGP EPE allocates SIDs only to BGP peers and links, but cannot be used to construct a
forwarding path. BGP peer SIDs must be used with IGP SIDs to form an E2E path.
 SRv6 Policy Path Establishment Traffic Steering to SRv6 Policies

SRv6 Policy Path Stitching (1)

⚫ Due to the restrictions on the stack depth in the SRv6 SRH, SRv6 path stitching can be deployed on large networks.

⚫ Path stitching is mainly implemented using stitching SIDs and nodes.

 A stitching SID (also called binding SID) can be used to represent an SRv6 Policy's forwarding path.

 A stitching node, which is generally an ABR or ASBR, is responsible for processing the binding SID and adding SRH information.
Assume that the
stack depth CE1 PE1 AS 65001 ASBR1 ASBR2 AS 65002 PE2 CE2
supported by the FC03::1C
device is 4. The stack depth FC04::100
cannot accommodate FC02::1C FC03::100
CE1->CE2 FC01::1 the E2E segment list. FC02::2 FC03::3 FC04::4 CE1->CE2

IPv6 Header IPv6 Header IPv6 Header IPv6 Header IPv6 Header
SRH (SL = 3)
SRH (SL = 3) SRH (SL = 2) SRH (SL = 1) SRH (SL = 0) SRH (SL = 0)
Segment List (0)
Stack FC04::100 FC04::100 FC04::100 FC04::4 FC04::100
Segment List (1)
depth FC03::100 FC03::100 FC03::100 FC03::100
Segment List (2) SRH (SL = 0)
FC02::1C FC02::1C FC02::1C FC02::1C
Segment List (3) FC04::100
FC02::2 FC02::2 FC02::2 FC02::2
FC03::100
FC02::1C End.X SID CE1->CE2 CE1->CE2 CE1->CE2 FC02::1C CE1->CE2
FC03::4 End SID FC02::2
Internal Internal
Internal
FC03::100 Binding SID Sent from PE1 processing on processing on CE1->CE2
processing on PE2 Insert mode
FC04::100 ASBR1 ASBR1
End.DT4 SID
Sent from ASBR2

41 Huawei Confidential

• On a large network, the SRv6 SRH may be of a large size. Considering device limitations and
forwarding efficiency, the number of SIDs in the SRH must be limited.

• Generally, there are two methods for reducing the SRH size:

▫ SRv6 header compression

▪ Huawei mainly uses the G-SRv6 solution for SRv6 header compression,
reducing the SRH size and improving the forwarding efficiency without
sacrificing SID information.

▪ This course will not cover relevant header compression technologies.

▫ SRv6 path stitching

▪ Binding SIDs are used to stitch different SRv6 paths together, so that the SRH
of each SRv6 path is not too large.

• The SRv6 stack depth is generally determined by device capabilities.

• SRv6 mainly supports the following four types of binding SIDs:

▫ End.B6.Insert

▫ End.B6.Insert.Red

▫ End.B6.Encaps

▫ End.B6.Encaps.Red
 SRv6 Policy Path Establishment Traffic Steering to SRv6 Policies

SRv6 Policy Path Stitching (2)

⚫ Main encapsulation modes supported by SRv6 stitching labels:
 Insert mode: inserts an SRH after the original IPv6 header so that the packet is forwarded based on the original IPv6 header and the new SRH.

 Encaps mode: inserts an outer IPv6 header and SRH before the original IPv6 header so that the packet is forwarded based on the outer IPv6 header and SRH.
Assume that the
stack depth ASBR2
CE1 PE1 AS65001 ASBR1 AS65002 PE2 CE2
supported by the
device is 4. FC03::1C
The stack depth FC04::100
cannot accommodate FC02::1C FC03::100
CE1->CE2 FC01::1 the E2E segment list. FC02::2 FC03::3 FC04::4 CE1->CE2

IPv6 Header IPv6 Header IPv6 Header IPv6 Header IPv6 Header
SRH (SL = 3) SRH (SL = 3) SRH (SL = 1) SRH (SL = 0)
SRH (SL = 2) SRH (SL = 0)
Segment List (0)
Stack FC04::100 FC04::100 FC04::100 FC04::4 FC04::100
Segment List (1)
depth FC03::100 FC03::100 FC03::100 FC03::100
Segment List (2) IPv6 Header
FC02::1C FC02::1C FC02::1C FC02::1C
Segment List (3)
FC02::2 FC02::2 FC02::2 SRH (SL = 0) FC02::2
FC04::100
FC02::1C End.X SID CE1->CE2 CE1->CE2 CE1->CE2 CE1->CE2
FC03::100
FC03::4 End SID Internal Internal FC02::1C
Internal
FC03::100 Binding SID Sent from PE1 processing on processing on FC02::2
processing on PE2
FC04::100 ASBR1 ASBR1
End.DT4 SID CE1->CE2 Encaps mode
Sent from ASBR2

42 Huawei Confidential

• The End.B6.Encaps instruction used in Encaps mode can be disassembled into End + B6 +
Encaps, where B6 indicates the application of an SRv6 Policy and Encaps indicates the
encapsulation of an outer IPv6 header and SRH. This instruction includes the following
operations: decrements the SL value of the inner SRH by 1, copies the SID to which the SL
field is pointing to the DA field of the inner IPv6 header, encapsulates an IPv6 header and
SRH (including segment lists), sets the source address to the address of the current node
and the destination address to the first SID of the involved SRv6 Policy, sets other fields in
the outer IPv6 header, looks up the corresponding table, and forwards the new IPv6 packet
accordingly.
 SRv6 Policy Path Establishment Traffic Steering to SRv6 Policies

Color-based Traffic Steering to SRv6 Policies

⚫ SRv6 Policies support color-based traffic steering, enabling traffic to be steered to an SRv6 Policy through route
recursion that is implemented based on the color value and destination address in the route.
BGP Route
Use route-policies to specify
Prefix NHP Ext-Community
color values (extended
Net1 PE2 0:15
community attribute) for
Net2 PE2 0:20
specific BGP routes.
Alternatively,
IGP Route deploy an IGP Route
Alternatively,
Prefix NHP import route- Color: 15 deploy an export Prefix NHP
Net1 PE1 policy. route-policy. Net1 CE2
Net2 PE1 Net2 CE2

When forwarding a packet, the PE

DIP: Net1 determines the SRv6 Policy to which the
corresponding route recurses based on the
DIP: Net2 destination address of the packet and the
CE1 PE1 next hop of the route. PE2 CE2
Alternatively, PE1
specify color
values for specific
VRF1 15 SRv6 Policy
VRFs. Color: 20
VRF2 20 SRv6 Policy

43 Huawei Confidential

• Configure a tunnel policy on PE1. After receiving the BGP routes (Net1 and Net2), PE1
recurses the routes to different SRv6 Policies based on the color values (0:15 and 0:20) and
the next hop (PE2). Before forwarding packets to specified subnets (Net1 and Net2), PE1
adds specific SRv6 SID stacks to the packets.

• The color attribute in route entries can be modified before the local router (for example,
PE2) sends routes or after the peer router (for example, PE1) receives routes.

• You can also directly configure the color attribute for the VPN instance of the originating
router (for example, PE1), so that all traffic of the VPN instance is forwarded over the
specified SRv6 Policy.
 SRv6 Policy Path Establishment Traffic Steering to SRv6 Policies

DSCP-based Traffic Steering to SRv6 Policies

⚫ Color-based traffic steering causes different traffic (such as HTTP and FTP traffic) destined for the same address to recurse to the
same forwarding path, leading to a failure to implement refined traffic control. In this case, DSCP-based traffic steering can be
performed to recurse traffic to different forwarding paths.
BGP Route Use a route-policy to specify a color
Alternatively, PE1 value (extended community
Prefix NHP Ext-Community
specify a color VRF1 1000 SRv6 Policy attribute) for the specific BGP route.
Alternatively, Net1 PE2 0:1000
value for the
deploy an
specific VRF. Color: 15 Alternatively, IGP Route
IGP Route import route-
policy. deploy an export Prefix NHP
Prefix NHP route-policy. Net1 CE2
Net1 PE1
FTP
PE1 finds a matching mapping policy
service
(color 1000) based on the packet
DIP: Net1, DSCP: 46
destination address and next hop, and Net1
then recurses the packets to different
DIP: Net1, DSCP: 23 HTTP
CE1 forwarding paths based on DSCP CE2
PE1 values. PE2 service

PE1 DSCP 24 SRv6 Policy 1

Destination (Color 15)
Mapping policy
address
(Color 1000) Color: 20
Next hop
SRv6 Policy 2
DSCP 28 (Color 20)

44 Huawei Confidential

• In DSCP-based traffic steering, the color attribute in route entries is mainly used to find a
matching mapping policy.

• The color attribute in route entries can be modified in the outbound direction of the
originating router (for example, PE2) or in the inbound direction of the receiving router (for
example, PE1).

• You can also directly configure the color attribute for the VPN instance of the originating
router (for example, PE1), so that all traffic of the VPN instance is forwarded over the
specified SRv6 Policy.
 Contents

1. SRv6 Overview

2. SRv6 Fundamentals
▫ Basic Concepts of SRv6

▫ SRv6 Policy Path Establishment and Traffic Steering

◼ Typical SRv6 Applications

3. SRv6 High Reliability

4. Basic SRv6 Configuration

5. SRv6 Deployment Using iMaster NCE-IP

45 Huawei Confidential
 L3VPN over SRv6 Policy
⚫ If an SRv6 Policy is used to carry VPN traffic, the last-hop SRv6 device processes data in a way slightly different from that of a
common SRv6 device. MP-BGP Route
Prefix NHP Ext-Community
IGP Route Net2 PE2 FC03::300 + 0:15 + RT IGP Route
Prefix NHP 65000 Prefix NHP
Net2 PE1 FC01:: /96 FC02:: /96 FC03:: /96 Net2 CE2
FC01::1 FC02::2 FC03::3
Net2
End.DT4
VPNA FC03::300 VPNA
Color 15
CE1 PE1 P1 PE2 CE2
DIP: Net2 DIPv6: FC02::2 Forwards the DIPv6: FC03::3 DIPv6: FC03::300 DIP: CE2
SIP: CE1 SIPv6: FC01::1 packet based on SIPv6: FC01::1 SIPv6: FC01::1 SIP: CE1
the outer IPv6
Payload SRH (SL = 2) header. SRH (SL = 1) SRH (SL = 0) Payload
FC03::300 FC03::300 FC03::300
Removes the outer IPv6
FC03::3 FC03::3 FC03::3
Forwards the IP packet header and forwards
FC02::2 FC02::2 FC02::2
over the corresponding the packet as a
SRv6 Policy based on the DIP: Net2 DIP: Net2 DIP: Net2 common IP one.
color value. SIP: CE1 SIP: CE1 SIP: CE1
Payload Payload Payload
The last-hop SRv6 router looks up FC01:: /96 Locator
the routing table twice. FC01::1 End SID

46 Huawei Confidential

• Route advertisement process:

▫ SRv6 and SRv6 VPN are configured on each PE, and IPv6 or SRv6 is enabled on the
transit node.
▫ PE2 advertises an SRv6 locator route to PE1.
▫ CE-to-PE route advertisement: CE2 advertises its route to PE2. Either a static route or
a routing protocol (RIP, OSPFv3, IS-IS, or BGP) can be deployed between the CE and
PE.
▫ After learning the route advertised by CE2, PE2 installs it in the routing table of the
corresponding VPN instance and converts the route into an MP-BGP one.
▫ Inter-PE route advertisement: Configure a BGP or VPN export policy on PE2 (or a BGP
or VPN import policy on PE1), and set a color value for the route (next hop: PE2).
Then, configure PE2 to send routing information to PE1 through a BGP peer
relationship using update messages with RT and SRv6 VPN SID attributes.
▫ After PE1 receives the VPN route, if the next hop in the route is reachable and the
route matches the BGP import policy, PE1 performs a series of actions to determine
whether to install the route in the routing table of the corresponding VPN instance.
These actions include VPN route leaking, route recursion to an SRv6 path, and route
selection. In this example, PE1 installs the VPN route, which is associated with the
SRv6 VPN SID.
▫ PE-to-CE route advertisement: CE1 can learn the VPN route from PE1 through a static
route or a routing protocol (RIP, OSPFv3, IS-IS, or BGP). The route advertisement
process is similar to that from CE2 to PE2.
• Packet forwarding process:

▫ After receiving a common unicast packet from CE1, PE1 searches the routing table of
the corresponding VPN instance and finds that the outbound interface of the route is
an SRv6 Policy interface. PE1 then inserts an SRH carrying the SID list of the SRv6
Policy and encapsulates an IPv6 header into the packet. After completing these
operations, PE1 forwards the packet to P1.

▫ The transit node P1 forwards the packet hop by hop based on SRH information.

▫ After receiving the packet, the endpoint PE2 searches the My Local SID Table and
finds an End SID that matches the IPv6 DA FC03::3 in the packet. According to the
instruction bound to the SID, PE2 decrements the SL value of the packet by 1 and
updates the IPv6 DA to the VPN SID FC03::300.

▫ Based on the VPN SID FC03::300, PE2 searches the My Local SID Table and finds a
matching End.DT4 SID. According to the instruction bound to the SID, PE2
decapsulates the packet, removes the SRH and IPv6 header, searches the routing
table of the VPN instance corresponding to the VPN SID FC03::300 according to the
DA in the inner packet, and forwards the packet to CE2.
 L3VPN over SRv6 BE
⚫ When SRv6 BE is used to carry VPN traffic, the P between PEs does not function as an endpoint.

MP-BGP Route
Prefix NHP Ext-Community
Net2 PE2 FC03::300 + RT
IGP Route IGP Route
Prefix NHP 65000 Prefix NHP
Net2 PE1 Net2 CE2
FC01:: /96 FC02:: /96 FC03:: /96
FC01::1 FC02::2 FC03::3
Net2
End.DT4
VPNA FC03::300 VPNA
CE1 PE1 P1 PE2 CE2
DIP: Net2 DIPv6: FC03::300 DIPv6: FC03::300 DIP: Net2
SIP: CE1 SIPv6: FC01::1 SIPv6: FC01::1 SIP: CE1
Forwards the
Payload DIP: Net2 packet based on DIP: Net2 Payload
SIP: CE1 the outer IPv6 SIP: CE1
Forwards the IP header. PE2 removes the
Payload Payload
packet over an outer IPv6 header and
SRv6 Policy. FC01:: /96 Locator
forwards the packet
as a common IP one. FC01::1 End SID

48 Huawei Confidential

• Route advertisement process:

▫ SRv6 and SRv6 VPN are configured on each PE, and IPv6 is enabled on the transit
node.
▫ PE2 advertises an SRv6 locator route to PE1.
▫ CE-to-PE route advertisement: CE2 advertises its route to PE2. Either a static route or
a routing protocol (RIP, OSPFv3, IS-IS, or BGP) can be deployed between the CE and
PE.
▫ After learning the route advertised by CE2, PE2 installs it in the routing table of the
corresponding VPN instance and converts the route into an MP-BGP one.
▫ Inter-PE route advertisement: PE2 advertises the VPN route to egress node PE1
through MP-BGP using update messages with RT and SRv6 VPN SID attributes.
▫ After PE1 receives the VPN route, if the next hop in the route is reachable and the
route matches the BGP import policy, PE1 performs a series of actions to determine
whether to install the route in the routing table of the corresponding VPN instance.
These actions include VPN route leaking, route recursion to an SRv6 BE path, and
route selection. In this example, PE1 installs the VPN route, which is associated with
the SRv6 VPN SID.
▫ PE-to-CE route advertisement: CE1 can learn the VPN route from PE1 through a static
route or a routing protocol (RIP, OSPFv3, IS-IS, or BGP). The route advertisement
process is similar to that from CE2 to PE2.
• Packet forwarding process:

▫ After receiving a common unicast packet from CE1, PE1 searches the routing table of
the corresponding VPN instance and finds that the outbound interface of the route is
an SRv6 Policy interface. PE1 then inserts an SRH carrying the SID list of the SRv6
Policy and encapsulates an IPv6 header into the packet. After completing these
operations, PE1 forwards the packet to P1.

▫ The transit node P1 forwards the packet hop by hop based on SRH information.

▫ After receiving the packet, the endpoint PE2 searches the My Local SID Table and
finds an End SID that matches the IPv6 DA FC03::3 in the packet. According to the
instruction bound to the SID, PE2 decrements the SL value of the packet by 1 and
updates the IPv6 DA to the VPN SID FC03::300.

▫ Based on the VPN SID FC03::300, PE2 searches the My Local SID Table and finds a
matching End.DT4 SID. According to the instruction bound to the SID, PE2
decapsulates the packet, removes the SRH and IPv6 header, searches the routing
table of the VPN instance corresponding to the VPN SID FC03::300 according to the
DA in the inner packet, and forwards the packet to CE2.
 Native IPv6 over SRv6 Policy
⚫ Common IPv6 data can also be carried using SRv6.
BGP Route
Prefix NHP Ext-Community
Net2 PE2 0:15
IGP Route IGP Route
Prefix NHP 65000 Prefix NHP
Net2 PE1 FC01:: /96 FC02:: /96 FC03:: /96 Net2 CE2
FC01::1 FC02::2 FC03::3
Net2

Color 15
CE1 PE1 P1 PE2 CE2
DIPv6: Net2 DIPv6: FC02::2 Forwards the DIPv6: FC03::3 DIPv6: Net2 DIPv6: Net2
SIPv6: CE1 SIPv6: CE1 packet based on SIPv6: CE1 SIPv6: CE1 SIPv6: CE1
the outer IPv6
Payload SRH (SL = 2) SRH (SL = 1) SRH (SL = 0) Payload
header.
Net2 Net2 Net2
FC03::3 FC03::3 FC03::3 Removes the SRH and
Forwards the IPv6 packet FC02::2 FC02::2 FC02::2 forwards the packet as
over the corresponding a common IPv6 one.
SRv6 Policy based on the Payload Payload Payload
color value.
FC01:: /96 Locator
FC01::1 End SID

50 Huawei Confidential

• Route advertisement process:

▫ SRv6 and SRv6 VPN are configured on each PE, and IPv6 or SRv6 is enabled on the
transit node.

▫ PE2 advertises an SRv6 locator route to PE1.

▫ CE-to-PE route advertisement: CE2 advertises its route to PE2. Either a static route or
a routing protocol (RIP, OSPFv3, IS-IS, or BGP) can be deployed between the CE and
PE.

▫ Inter-PE route advertisement: Configure a BGP export policy on PE2 (or a BGP import
policy on PE1), and set a color value for the route (next hop: PE2). Then, configure
PE2 to send routing information to PE1 through a BGP peer relationship.

▫ After PE1 receives the IPv6 route, if the next hop in the route is reachable and the
route matches the BGP import policy, PE1 performs a series of actions, including
route recursion to an SRv6 path and route selection.

▫ PE-to-CE route advertisement: CE1 can learn the IPv6 route from PE1 through a static
route or a routing protocol (RIP, OSPFv3, IS-IS, or BGP). The route advertisement
process is similar to that from CE2 to PE2.
• Packet forwarding process:

▫ After receiving a unicast IPv6 packet from CE1, PE1 searches the IPv6 routing table
and finds that the outbound interface of the route is an SRv6 Policy interface. PE1
then inserts an SRH carrying the SID list of the SRv6 Policy and encapsulates an IPv6
header into the packet. After completing these operations, PE1 forwards the packet
to P1.

▫ The transit node P1 forwards the packet hop by hop based on SRH information.

▫ After receiving the packet, the endpoint PE2 searches the My Local SID Table and
finds an End SID that matches the IPv6 DA FC03::3 in the packet. According to the
instruction bound to the SID, PE2 decrements the SL value of the packet by 1 and
updates the IPv6 DA to the End SID Net2.

▫ Based on the End SID Net2, PE2 searches the My Local SID table, finds a matching
End SID, removes the SRH and IPv6 header, and forwards the packet to CE2.
 Contents

1. SRv6 Overview

2. SRv6 Fundamentals

3. SRv6 High Reliability

◼ Overview of SRv6 High Reliability

▫ SRv6 Tunnel Status Detection and Tunnel Protection

▫ SRv6 Egress Protection and Access Protection

4. Basic SRv6 Configuration

5. SRv6 Deployment Using iMaster NCE-IP

52 Huawei Confidential
WAN Bearer Networks' Requirements for High Reliability
⚫ Fault recovery within 50 ms has become a basic requirement of WAN bearer networks.
 Voice services: have high requirements for real-time performance. If fault recovery is completed within milliseconds, the fault is imperceptible or
only slightly perceptible to users, without much impacts on services. However, if the fault recovery time reaches seconds, the corresponding
session is interrupted.

 IPTV services: If fault recovery is completed within milliseconds, IPTV services may encounter transient pixelation.

Voice user
experience
Impact of network faults on voice services Impact of network faults on IPTV services

GOP
Imperceptible
Slightly
perceptible Obviously I B B P B B P B B I
perceptible Session
interrupted
0 50 ms 500 ms 2s
Reference standard: I-frame damage caused by packet loss is the key cause of erratic display.
YD/T 1071-2000 <IP Telephone Gateway technical specification>

53 Huawei Confidential
Overview of Multi-Layer Reliability Solutions
⚫ WAN bearer networks require high reliability to be provided at device, network, and service layers to achieve E2E
high availability of 99.999% and fast protection switching of all services within 50 ms.

• VPN FRR
EVPN L3VPN

Service layer

• TI-LFA, midpoint protection (TE FRR), and

SRv6 tunnel candidate path protection (HSB)

Tunnel layer IGP

• Highly reliable hardware architecture: Key
components, such as main control boards, SFUs,
interface boards, power supply modules, and fans,
adopt redundancy design.
• Highly reliable networking architecture: effective
redundant paths, reliable networking mode (e.g. ring,
Physical layer spine-leaf, or dual-plane networking), and sufficient
protection bandwidth reserved.

54 Huawei Confidential
Overview of Reliability Technologies for Multi-Layer Networks

Detection Protection
Detection Object Technology Technology

VPN FRR
VPN BFD for locator

HSB
SBFD for
LSP SRv6 Policy
Mixed VPN FRR

Midpoint
BFD for IGP protection
IGP

TI-LFA

Physical link BFD for interface Microloop

avoidance

55 Huawei Confidential
Usage Scenarios of Reliability Technologies for Multi-Layer Networks

CE PE P P PE CE
2 4 6 8 10

Access network
Access network
1 3 5 7 9 11

CE PE P P PE CE
Intermediate network
Bearer network

Service Category Protection Type Tunnel Type Failure Point Detection Technology Protection Technology Specification

1. TI-LFA (SRv6 BE + SRv6 Policy)

4 to 8 BFD for interface 50 ms
Local protection, 2. Midpoint TI-LFA (SRv6 Policy)
Common SRv6 BE, SRv6
E2E protection
services Policy 3 and 9 BFD for locator VPN FRR 50 ms
1, 2, 10, and 11 BFD for interface VPN mixed FRR, IP FRR 50 ms
4 to 8 SBFD for SRv6 Policy HSB 50 ms
Services with
Local protection,
high SLA SRv6 Policy 3 and 9 SBFD for SRv6 Policy VPN FRR 200 ms/50 ms
E2E protection
requirements
1, 2, 10, and 11 BFD for interface VPN mixed FRR, IP FRR 50 ms

56 Huawei Confidential
 Contents

1. SRv6 Overview

2. SRv6 Fundamentals

3. SRv6 High Reliability

▫ Overview of SRv6 High Reliability
◼ SRv6 Tunnel Status Detection and Tunnel Protection

▫ SRv6 Egress Protection and Access Protection

4. Basic SRv6 Configuration

5. SRv6 Deployment Using iMaster NCE-IP

57 Huawei Confidential
 SRv6 Tunnel Detection Technologies
⚫ SRv6 tunnel connectivity can be detected using multiple technologies, such as SBFD, ping, and tracert.

SBFD Ping/Tracert

Tracert

SBFD
SRv6 tunnel

SRv6 tunnel

Ping

• SBFD can be used to detect tunnel connectivity in an E2E manner. • SRv6 SID ping is mainly used to check network connectivity and
• However, SBFD cannot detect the specific fault location on the host reachability.
network. As such, it is usually used with HSB or VPN FRR.  Ping tests are classified into segment-by-segment tests and non-
segment-by-segment tests.
• In addition to checking network connectivity and host reachability,
SRv6 SID tracert can be used to analyze the specific fault location
on the network.

58 Huawei Confidential

• Seamless bidirectional forwarding detection (SBFD) is a simplified BFD mechanism. With a

simplified BFD state machine, SBFD shortens the negotiation time and improves network-
wide flexibility.

▫ The IPv6 address of the SBFD reflector must be the same as the endpoint of the
corresponding SRv6 Policy.

• As SRv6 simply adds a new type of routing extension header to implement forwarding
based on the IPv6 data plane, ICMPv6 ping and tracert can be directly used on an SRv6
network for connectivity check based on common IPv6 addresses, without requiring any
changes to hardware or software. ICMPv6 ping and tracert both support packet forwarding
to a destination address over the shortest path, thereby checking the reachability to the
destination. If the destination address is an SRv6 SID, the check can be performed through
either ICMPv6 ping & tracert or SRv6 OAM extensions. Currently, SRv6 OAM can be
extended in either of the following ways:

▫ Set the O-bit (OAM bit) in the SRH.

▫ Insert an End.OP SID into the SRH.

 SBFD Implementation

Detection end SBFD State Machine on

(Initiator) Reflector the Initiator
Admin Down
(Timer) Up

SBFD Control packet

Down Up
Down Up
Down -> Up
Admin Down
(Timer)
SBFD Control packet

• The loopback packet constructed by the reflector carries the Admin Down or
Up field.
• Before link detection, an SBFD initiator and an SBFD reflector exchange SBFD Control • After receiving a reflected packet carrying the Up state, the initiator sets the
packets to notify each other of SBFD parameters (for example, discriminators). In local state to Up. After receiving a reflected packet carrying the Admin Down
link detection, the initiator proactively sends an SBFD packet, and the reflector loops state, it sets the local state to Down. It also sets the local state to Down if it
this packet back. The initiator then determines the local status based on the looped does not receive any reflected packet before the timer expires.
packet.

59 Huawei Confidential

• Because the state machine has only Up and Down states, the initiator can send packets
carrying only the Up or Down state and receive packets carrying only the Up or Admin
Down state. The initiator starts by sending an SBFD packet carrying the Down state to the
reflector. The destination and source port numbers of the packet are 7784 and 4784,
respectively; the destination IP address is a user-configured address on the 127 network
segment; the source IP address is the locally configured LSR ID.

• The reflector does not have any SBFD state machine or detection mechanism. For this
reason, it does not proactively send SBFD Echo packets, but rather, it only reflects SBFD
packets. The destination and source port numbers in the looped-back packet are 4784 and
7784, respectively; the source IP address is the locally configured LSR ID; the destination IP
address is the source IP address of the initiator.
 Introduction to SRv6 Ping and Tracert

Version Traffic Class Flow Label

Format of the Flags
Field
Payload Length Next Header=43 Hop Limit
O Reserved
Solution 2: End.OP SID
IPv6 source address (SA)
00100000 IPv6 destination address (DA)
The End.OP SID can instruct data
packets to be sent to the control
plane for OAM processing.
Solution 1: Next Header Hdr Ext Len Routing Type=4 Segments Left=2
O-bit in the SRH In the case of an SRv6 Policy test, the
Because the O-bit is carried Last Entry Flags Tag headend encodes an End.OP SID into
in the SRH, each SRv6 the segment list.
endpoint node needs to Segment List [0]
process and respond to Because only the SRv6 endpoint that
Segment List [1]
ICMPv6 ping and tracert has generated an End.OP SID can
requests. Therefore, Segment List [2] process ICMPv6 ping and tracert
segment-by-segment tests request packets, E2E tests can be
can be implemented based Optional TLV objects
implemented based on End.OP SIDs.
on the O-bit.
L2/L3 Payload

60 Huawei Confidential

• Currently, SRv6 ping and tracert can be implemented using the following two methods:

▫ One method is to use the O-bit (OAM bit) in the SRH. Because the O-bit is carried in
the SRH, each SRv6 endpoint node needs to process and respond to ICMPv6 ping and
tracert requests. Therefore, segment-by-segment tests can be implemented based
on the O-bit. You can run the ping ipv6-sid and tracert ipv6-sid commands to initiate
tests based on one or more SIDs.

▫ The other method is to introduce End.OP SIDs, which instruct data packets to be sent
to the control plane for OAM processing. In the case of an SRv6 Policy test, the
headend encodes an End.OP SID into the segment list. Because only the SRv6
endpoint that has generated an End.OP SID can process ICMPv6 ping and tracert
request packets, E2E tests can be implemented based on End.OP SIDs.

▪ For SID stack-based tests, specify one or more End.OP SIDs in the ping ipv6-sid
and tracert ipv6-sid commands.

▪ For SRv6 Policy-based tests, specify the end-op parameter in the ping srv6-te
policy and tracert srv6-te policy commands.
 SRv6 Ping Implementation
⚫ SRv6 ping can be classified into segment-by-segment ping and non-segment-by-segment ping.

PE1 P1 PE2 PE1 P1 PE2

FC01::1 FC02::2 FC03::3 FC01::1 FC02::2 FC03::3

DIPv6: FC02::2 DIPv6: FC03::3 DIPv6: FC02::2 DIPv6: FC03::3

SIPv6: FC01::1 SIPv6: FC01::1 SIPv6: FC01::1 SIPv6: FC01::1
SRH (SL = 1) SRH (SL = 0) SRH (SL = 1) SRH (SL = 0)
FC03::3 FC03::3 FC03::3 FC03::3
FC02::2 FC02::2 FC02::2 FC02::2
ICMPv6 Request ICMPv6 Request ICMPv6 Request ICMPv6 Request

DIPv6: FC01::1 DIPv6: FC01::1

SIPv6: FC02::2 SIPv6: FC03::3
ICMPv6 Reply ICMPv6 Reply

DIPv6: FC01::1
SIPv6: FC03::3
Segment-by-segment ping ICMPv6 Reply Non-segment-by-segment ping
test test

61 Huawei Confidential

• For a segment-by-segment test:

▫ PE1 initiates a ping operation to PE2. Specifically, it constructs an ICMPv6 Request

packet carrying the SRv6 SIDs (End and End.X SIDs) of P1 and the End SID of PE2 and
then forwards the packet.

▫ After receiving the ICMPv6 Request packet, P1 sends an ICMPv6 Reply packet to PE1
and forwards the ICMPv6 Request packet to PE2.

▫ After receiving the ICMPv6 Request packet, PE2 sends an ICMPv6 Reply packet to
PE1.

• For a non-segment-by-segment test:

▫ PE1 initiates a ping operation to PE2. Specifically, it constructs an ICMPv6 Request

packet carrying the End SID of PE2 and then forwards the packet.

▫ After receiving the ICMPv6 Request packet, P1 forwards it to PE2.

▫ After receiving the ICMPv6 Request packet, PE2 sends an ICMPv6 Reply packet to
PE1. In this case, you can view detailed information about the ping operation on PE1.
 SRv6 Tracert Implementation
⚫ SRv6 tracert can be classified into overlay tracert and non-overlay tracert.
PE1 P1 PE2
FC01::1 FC02::2 FC03::3
PE1 P1 PE2
FC01::1 FC02::2 FC03::3
DIPv6: FC02::2
SIPv6: FC01::1
DIPv6: FC02::2 DIPv6: FC03::3 TTL=0
SIPv6: FC01::1 SIPv6: FC01::1 SRH (SL = 1)
TTL=63 TTL=62 FC03::3
SRH (SL = 1) SRH (SL = 0) FC02::2
FC03::3 FC03::3 UDP DIPv6: FC01::1
FC02::2 FC02::2 SIPv6: FC02::2
UDP UDP ICMPv6 Time Exceeded
DIPv6: FC02::2 DIPv6: FC03::3
DIPv6: FC01::1
SIPv6: FC01::1 SIPv6: FC01::1
SIPv6: FC02::2
TTL=1 TTL=0
ICMP Port-Unreachable
SRH (SL = 1) SRH (SL = 0)
FC03::3 FC03::3
DIPv6: FC01::1
FC02::2 FC02::2
SIPv6: FC03::3
UDP UDP DIPv6: FC01::1
ICMP Port-Unreachable
Overlay Non-overlay SIPv6: FC03::3

tracert test tracert test ICMP Port-Unreachable

62 Huawei Confidential

• For an overlay test:

▫ PE1 initiates a tracert operation to PE2. Specifically, it constructs a UDP packet

carrying the SRv6 SIDs (End and End.X SIDs) of P1 and the End SID of PE2,
encapsulates an SRH into the packet, and then forwards the packet. In this case, the
value of the Hop Limit field (equal to the TTL field in IPv4) in the IPv6 header is set to
64 and decrements by 1 each time the packet passes through a device. When the
value of the Hop Limit field is 0, the packet is discarded, and then an ICMPv6 Time
Exceeded message is sent to PE1.

▫ After receiving the UDP packet, P1 changes the value of the Hop Limit field to 63,
sends an ICMPv6 Port Unreachable message to PE1, and forwards the UDP packet to
PE2.

▫ After receiving the UDP packet, PE2 changes the value of the Hop Limit field to 62
and sends an ICMPv6 Port Unreachable message to PE1.
• For a non-overlay test:

▫ PE1 initiates a tracert operation to PE2. Specifically, it constructs a UDP packet

carrying the SRv6 SID of P1 and the End SID of PE2, encapsulates an SRH into the
packet, and then forwards the packet. In this case, the value of the Hop Limit field in
the IPv6 header is set to 1 and decrements by 1 each time the packet passes through
a device. When the value of the Hop Limit field is 0, the packet is discarded, and then
an ICMPv6 Time Exceeded message is sent to PE1.

▫ After receiving the UDP packet, P1 changes the value of the Hop Limit field to 0 and
sends an ICMPv6 Time Exceeded message to PE1.

▫ After receiving the ICMPv6 Time Exceeded message from P1, PE1 increments the
value of the Hop Limit field by 1 (the value now becomes 2) and continues to send
the UDP packet.

▫ After receiving the UDP packet, P1 changes the value of the Hop Limit field to 1 and
forwards the packet to PE2.

▫ After receiving the UDP packet, PE2 changes the value of the Hop Limit field to 0,
determines that the SID type is End SID, and checks whether the upper-layer protocol
header is a UDP or an ICMPv6 header.
Overview of Tunnel Protection Technologies
⚫ SRv6 tunnel protection can be classified into local protection and E2E protection.

Egress
TI-LFA FRR
Local Protection Midpoint TI-LFA FRR
• Fast switching Microloop avoidance
• Only links and Ingress
nodes protected

E2E protection
Egress
• Detection-dependent HSB
fast switching
• E2E paths protected ECMP

Ingress Best-effort path

64 Huawei Confidential
 Local Protection Technology E2E Protection Technology

TI-LFA FRR
⚫ TI-LFA FRR provides link and node protection for SRv6 tunnels. It enables traffic to be rapidly switched to the backup path if a link or
node failure occurs.
PE1 PE2 ⚫ As shown in the figure, the shortest path from PE1 to PE2 is PE1 -> P1 -> P4 -> PE2,
DIPv6: FC05::5 FC01::1 FC06::6 DIPv6: FC06::6 which is the primary path. P1 needs to compute a TI-LFA backup path to PE2 through
SIPv6: FC01::1 SIPv6: FC01::1 the following operations:
SRH (SL = 1) SRH (SL = 0) 1. Excludes the primary next hop (link P1 -> P4) and computes the post-convergence
FC06::6 FC06::6 shortest path: P1 -> P2 -> P3 -> P4 -> PE2.
FC05::5 FC05::5
2. Computes the P space and Q space, which are (P1, P2) and (P3, P4, PE2),
FC02::2 FC05::5 Payload respectively.
Payload P1 P4
3. Computes the TI-LFA backup path. In this case, any path can be represented as a
DIPv6: FC05::5 multi-segment path (source node <-> P <-> Q <-> destination node). Both the
segments from the source node to the P node and from the Q node to the
DIPv6: FC03::C4 SIPv6: FC01::1
destination node are loop-free. The P-to-Q path is expressed using a strict explicit
SIPv6: FC01::1 P2 FC03::3 FC04::4 P3 SRH (SL = 1) path (End.X SID), ensuring that the entire TI-LFA strict explicit path is loop-free. To
SRH (SL = 0) FC06::6 simplify repair path computation, P2 (which is farthest from the source node and
FC03::C4 End.X FC05::5 resides in the P space), P3 (which is farthest from the destination node and resides
P space FC03::C4 Q space Payload in the Q space), and a link between the P and Q spaces are selected.
SRH (SL = 1)
FC06::6 DIPv6: FC05::5 4. After detecting that the P1-to-PE2 link goes down, P1 uses backup forwarding
FC05::5 SIPv6: FC01::1 entries and encapsulates a new SRH into the packet, with the segment list being
<FC03::C4, FC06::6>. In addition, the node changes the IPv6 destination address to
Payload SRH (SL = 1) FC03::C4 and then forwards the packet to the backup outbound interface in the B-
FC06::6 to-C direction.
FC05::5
Payload

65 Huawei Confidential

• P space and Q space:

▫ P space: is a set of nodes reachable from the source node of a protected link using
the shortest path tree (SPT) rooted at the source node without traversing the
protected link.

▫ Extended P space: is a set of nodes reachable from all the neighbors of a protected
link's source node using SPTs rooted at the neighbors without traversing the
protected link.

▫ Q space: is a set of nodes reachable from the destination node of a protected link
using the reverse SPT rooted at the destination node without traversing the
protected link.

• Advantages of TI-LFA:

▫ Provides protection for all topologies, preventing cost planning from affecting
protection path computation.

▫ Simplifies deployments. Backup paths are computed based on an IGP, eliminating the
need to deploy additional protocols for reliability purposes.

▫ Preferentially uses the post-convergence path as the backup path, reducing the
number of path switchovers and facilitating bandwidth planning.
• TI-LFA computation rules

▫ Priority: SRLG disjoint > Node protection > Link protection > Minimum cost

▫ TI-LFA computes a backup path that meets both the SRLG disjoint and node
protection conditions. If multiple backup paths meet the two conditions, TI-LFA
selects the path with the minimum cost.

▫ If no qualified backup path is available, TI-LFA computes a backup path that meets
both the SRLG disjoint and link protection conditions. If multiple backup paths meet
the two conditions, TI-LFA selects the path with the minimum cost.

▫ If no qualified backup path is available, TI-LFA computes a backup path that meets
the node protection condition with the minimum cost.

▫ If no qualified backup path is available, TI-LFA computes a backup path that meets
the link protection condition with the minimum cost.
 Local Protection Technology E2E Protection Technology

Limitations of TI-LFA FRR

⚫ In SRv6 Policy scenarios, the forwarding path of data packets usually needs to be constrained by specifying the nodes or links they
need to traverse. However, if some nodes or links that must be traversed are faulty, TI-LFA FRR cannot provide protection.

DIPv6: FC03::3
SIPv6: FC01::1
Using TI-LFA, P1
SRH (SL = 1)
computes the backup
FC06::6 P2 fails, causing a data
path to P3: P1 -> P2 ->
FC03::3 forwarding failure.
P4 -> P3.
Payload
PE1 P1 P2
FC01::1 FC02::2 FC03::3

Cost: 10
DIPv6: FC04::C4
SIPv6: FC0::1
SRH (SL = 1) Cost: 10 Cost: 10
FC03::3
FC04::C4
SRH (SL = 1) FC04::4 FC05::5 FC06::6
Cost: 100 Backup path
FC06::6
FC03::3
End.X FC04::C4 Primary path
P3 P4 PE2
Payload

67 Huawei Confidential
 Local Protection Technology E2E Protection Technology

Overview of Midpoint Protection

⚫ In SRv6 Policy scenarios, strict node constraints may result in a TI-LFA FRR protection failure. To resolve this issue, a proxy forwarding node (a node
upstream to the failed midpoint) takes over from the failed midpoint to complete the forwarding.

⚫ Specifically, after detecting that the next-hop interface of the packet fails, the next-hop address is the destination address of the packet, and the SL
value is greater than 0, the proxy forwarding node performs the End behavior on behalf of the midpoint. The behavior involves decrementing the SL
value by 1, copying the next SID to the DA field in the outer IPv6 header, and then forwarding the packet according to the instruction bound to the
SID. In this way, the failed midpoint is bypassed, achieving SRv6 midpoint protection.
PE1 P1 P2
FC01::1 FC02::2 FC03::3

Cost: 10
DIPv6: FC03::3
SIPv6: FC01::1
SRH (SL = 1) Cost: 10 Cost: 10
FC06::6
FC03::3
Payload FC04::4 FC05::5 FC06::6
Cost: 100 Backup path

Proxy forwarding Primary path

node P3 P4 PE2
The backup path
does not pass
through P2.

68 Huawei Confidential
 Local Protection Technology E2E Protection Technology

Midpoint Protection Implementation

DIPv6: FC03::3 ⚫ Midpoint protection is implemented as follows:
SIPv6: FC01::1 Backup path  Typically, P1 computes the shortest IGP path and TI-LFA backup path to each
SRH (SL = 1) Primary path node, such as PE2.
FC06::6  After midpoint TI-LFA is configured for P1 and P2 fails, P1 detects that the
FC03::3
PE1 P1 P2 outbound interface of P2 is faulty. The destination address of the packet is P2,
FC01::1 Payload which is a neighbor directly connected to P1. In addition, the SL value in the
SRH is greater than 0. In this case, the midpoint TI-LFA action is triggered.
DIPv6: FC06::6 FC02::2 FC03::3  P1 performs proxy forwarding. Specifically, it decrements the SL value by 1,
SIPv6: FC01::1 copies the next SID FC06::6 to the IPv6 destination address, and forwards the
traffic to PE2 based on the destination address. In this way, the traffic can
SRH (SL = 0)
successfully reach PE2 through the P1 -> P3 -> P4 path.
FC06::6
FC03::3  If P1 finds that the next hop to PE2 is still P2 after performing proxy
TI-LFA is forwarding, P1 forwards the traffic to the TI-LFA backup path. In other words,
Payload FC04::4 FC05::5
implemented after implementing midpoint TI-LFA, P1 implements basic TI-LFA processing to
again. enable the traffic to be switched to the correct backup path.
DIPv6: FC06::6  After completing IGP convergence, PE1 deletes the FIB entries destined for P2.
SIPv6: FC01::1 P3 P4
In this case, if iMaster NCE-IP delivers the segment list of a new policy, PE2
SRH (SL = 1) DIPv6: FC06::6 also performs proxy forwarding: decrementing the SL value by 1, using the
FC06::6 SIPv6: FC01::1 next SID FC06::6 as the IPv6 destination address, and forwarding the traffic to
FC04::C4 SRH (SL = 0) PE2 PE2.
SRH (SL = 0) FC06::6
FC06::6 FC03::3
FC03::3 Payload FC06::6
Payload

69 Huawei Confidential
 Local Protection Technology E2E Protection Technology

Microloop Introduction
⚫ TI-LFA FRR and midpoint protection can maintain data forwarding for a short time before IGP convergence is complete. After IGP
convergence, however, data is forwarded through IGP routes instead of FRR (tunnel mode).

⚫ However, the convergence speed of devices on the live network may be different. As a result, a temporary loop, which is called a
microloop, may be generated. The loop disappears only after all routers on the forwarding path complete convergence.
PE1 PE2
DIP: A
SIP: B
P1 completes IGP
Payload If the primary path convergence and
fails, traffic is does not forward
DIPv6: C forwarded along the traffic based on FRR. P1 P4
SIPv6: A FRR path.
P1 considers that the packet
SRH (SL=1) DIP: PE2
FRR path D
destined for PE2 should be
SIP: PE1 sent to P2, but P2 considers
C
Payload that the packet destined for
Payload After IGP PE2 should be sent to P1.
convergence, data is
P2 does not complete Cost: 1000
DIP: A forwarded along the P2 P3
IGP convergence and
SIP: B primary path.
forwards data based on
Payload the original routing
table.

70 Huawei Confidential
 Local Protection Technology E2E Protection Technology

Local Microloop in a Traffic Switchover Scenario

⚫ In a traffic switchover scenario, a local microloop occurs when
a node adjacent to the failed node converges earlier than the
other nodes on the network.
PE1 PE2
 When the link between P1 and P4 fails, traffic is first forwarded
P1 completes IGP
convergence and along the TI-LFA backup path.
does not forward
traffic based on  After P1 completes convergence, the next hop becomes P2, so that
P1 P4
FRR.
P1 forwards the traffic to P2 along the post-convergence path.
P1 considers that the packet
DIP: PE2 destined for PE2 should be  Because P2 and other nodes on the network have not converged,
SIP: PE1 sent to P2, but P2 considers
that the packet destined for the next hop for the traffic from P2 to PE2 is still P1. In this case, a
Payload
PE2 should be sent to P1.
loop is formed between P1 and P2 until P2 completes
P2 does not complete P2 P3 convergence.
IGP convergence and Cost: 1000
forwards data based on
the original routing
table.

71 Huawei Confidential
 Local Protection Technology E2E Protection Technology

Local Microloop Avoidance in a Traffic Switchover Scenario

⚫ The microloop avoidance measure is to deliver the corresponding

PE1 PE2
forwarding path after the involved node has already completed
FC01::1 FC06::6 convergence for a period of time. This prevents the loop caused by IGP

DIPv6: FC06::6 DIPv6: FC06::6

convergence on the node adjacent to the failed node. The detailed process
SIPv6: FC01::1 SIPv6: FC01::1 is as follows:
Payload Payload
 After P1 detects the fault of the link connected to P4, it enters the TI-LFA process
FC02::2 FC05::5 and forwards the packet to PE2 along the TI-LFA backup path.
P1 P4
DIPv6: FC03::C4 P1 starts a timer. Before the timer expires, the forwarding table retains
The P1 continues to 
SIPv6: FC01::1
forward traffic along DIPv6: FC06::6 unchanged, and the TI-LFA backup path continues to be used for packet
SRH (SL = 1) the TI-LFA backup path SIPv6: FC01::1
FC06::6 before the timer forwarding.
Payload
FC03::C4 expires.
 When the timer expires, other nodes on the network have completed
Payload FC03::3 FC04::4
convergence. P1 can now perform convergence and then forward the packet along
P2 P3
End.X FC03::C4 the post-convergence path.

DIPv6: FC06::6 ⚫ Because each TI-LFA backup path is loop-free, the packet can be forwarded
SIPv6: FC01::1 along a TI-LFA backup path for a period of time, and then the TI-LFA process
Payload
can exit after the other nodes complete convergence.

72 Huawei Confidential
 Local Protection Technology E2E Protection Technology

Remote Microloop in a Traffic Switchover Scenario

⚫ If a remote fault occurs, a loop may also be formed between nodes.
⚫ A loop may occur if the node closer to the failure point converges earlier
PE1 PE2
P1 does not complete
than the node farther from the failure point on the packet forwarding path.
IGP convergence and
forwards data based on
 After detecting a fault on the P3 -> P4 link, a node (for example, P3) performs
the original routing delayed convergence and forwards traffic along a TI-LFA backup path. In this case,
table. P1 P5
Cost: 1000 only P3 performs delayed convergence, and the other nodes on the network still
DIP: PE2 perform normal IGP convergence.
SIP: PE1
Payload  P2 converges first and computes the P2 -> P1 -> P5 -> PE2 path as the new path to
PE2. As such, after arriving at P2, the traffic is sent back to P1 instead of being
P2
P2 completes IGP
convergence and forwarded to P3.
forwards data based on
the post-convergence
 Because P1 has not completed convergence, it still forwards the traffic along the
P3 P4
routing table. P1 -> P2 -> P3 -> P4 -> P5 -> PE2 path. As a result, the traffic is sent back to P2,
forming a loop.

73 Huawei Confidential
 Local Protection Technology E2E Protection Technology

Remote Microloop Avoidance in a Traffic Switchover Scenario

⚫ A network node can pre-compute a loop-free backup path only when a directly connected link or node fails. That is, no loop-free path can be pre-computed against any other
potential fault on the network. As such, a loop-free path needs to be computed after node convergence is completed, thereby resolving the microloop issue.

⚫ As shown in the following figures, the loop-free TI-LFA path P2 -> P1 -> P5 -> PE2 is computed after P2 converges. The loop-free path computed by P3 can be either a strict
explicit one or a loose one.
PE1 PE2
PE1 PE2 FC01::1 FC07::7
FC01::1 FC07::7 DIPv6: FC07::7
DIPv6: FC07::7 SIPv6: FC01::1
SIPv6: FC01::1
Payload FC02::2 FC06::6
Payload FC02::2 FC06::6 End.X FC02::C4
End.X FC02::C4 P1 P5
P1 P5
DIPv6: FC03::C4
DIPv6: FC03::C4 SIPv6: FC01::1
FC03::C4

SIPv6: FC01::1
SRH (SL = 1)
End.X

SRH (SL = 2) FC07::7 P2

FC07::7 P2 FC02::C4 FC03::3
FC02::C4 FC03::3
FC03::C4 Payload

FC04::4 FC05::5 FC04::4 FC05::5

Payload
P3 P4 P3 P4

Strict explicit path Loose path

74 Huawei Confidential
 Local Protection Technology E2E Protection Technology

Microloop in a Traffic Switchback Scenario

⚫ Due to the lack of a convergence order in distributed
computing, a microloop may occur in a traffic switchback
PE1 PE2 scenario.
The faulty
P1 does not complete link  Assume that the link between P1 and P4 fails, and the path from
convergence and considers recovers.
PE1 to PE2 is PE1 -> P1 -> P2 -> P3 -> P4 -> PE2.
that the traffic destined for
PE2 should be sent to P2. P1 P4
 If the link between P1 and P4 recovers and P2 completes
A loop is convergence, the path from P2 to PE2 is P2 -> P1 -> P4 -> PE2. In this
DIP: PE2
formed
SIP: PE1
between P1 case, P2 forwards traffic to P1.
Payload and P2.

Cost: 1000
 If P1 has not completed IGP convergence due to some reasons, for
P2 completes convergence P2 P3
and considers that the example, a large number of services are running or CPU usage is
traffic destined for PE2
should be sent to P1. high, the node still forwards the traffic back to P2 through the
original path, forming a loop.

75 Huawei Confidential
 Local Protection Technology E2E Protection Technology

Microloop Avoidance in a Traffic Switchback Scenario

⚫ The method of microloop avoidance in a traffic switchback scenario is similar to that of remote microloop avoidance in a traffic switchover scenario.

⚫ As shown in the following figures, after P2 completes convergence, it encapsulates a new SRH into the packet, enabling traffic to be forwarded along
the post-convergence path (which is a strict explicit path) to the destination address. After P1 converges, it forwards the traffic to PE2 along the post-
convergence path.

PE1 PE2 PE1 PE2

FC01::1 FC06::6 FC01::1 FC06::6
DIPv6: FC06::6 DIPv6: FC06::6
The faulty link
SIPv6: FC01::1 SIPv6: FC01::1 The faulty link
recovers.
recovers.
Payload FC02::2 FC05::5 Payload FC02::2 FC05::5
End.X End.X
P1 P4 P1 P4
FC02::C4 FC02::C4
DIPv6: FC03::C4 DIPv6: FC03::C4
SIPv6: FC01::1 SIPv6: FC01::1
SRH (SL = 2) SRH (SL = 1)
FC06::6 FC06::6
FC03::C4

FC02::C4 FC02::C4
End.X

FC03::C4
Payload
Payload FC03::3 FC04::4 FC03::3 FC04::4
P2 P3 P2 P3

Strict explicit path Loose path

76 Huawei Confidential
 Local Protection Technology E2E Protection Technology

SRv6 Policy HSB

⚫ E2E SRv6 Policy protection can be implemented by configuring two candidate paths with different preferences for an SRv6 Policy. The path with a
higher preference is the primary and that with a lower preference is the backup. SBFD is enabled for the two paths.

⚫ When SBFD on the primary path detects a fault, traffic is switched from the primary path to the backup path.

⚫ If some devices on an SRv6 network do not support SRv6, local protection cannot be implemented. In this case, HSB can be used to provide high
reliability.
SRv6 policy PE1toPE3
endpoint PE3 color 100
candidate-path preference 200 //Primary
segment-list <PE1.End, PE3.End>
candidate-path preference 100 //Backup
segment-list <PE2.End, P2.End, PE4.End, PE3.End >
PE1 P1 P3 PE3

SRv6-
incapable
CE1 CE2

Primary path

Backup path
PE2 P2 P4 PE4

77 Huawei Confidential
 Local Protection Technology E2E Protection Technology

SRv6 Policy ECMP

⚫ During SRv6 Policy deployment, two segment lists can be configured in a candidate path to implement SRv6 Policy
load balancing. In this way, data is load balanced between two paths.
⚫ If one of the paths fails, data can still be forwarded over the other path.

SRv6 policy PE1toPE3

endpoint PE3 color 100
candidate-path preference 200
segment-list <PE1.End, PE3.End> //ECMP
segment-list <PE2.End, P2.End, PE4.End , PE3.End > //ECMP
PE1 P1 P3 PE3

CE1 CE2

ECMP path
PE2 P2 P4 PE4

78 Huawei Confidential
 Local Protection Technology E2E Protection Technology

Best-Effort Paths for SRv6 Policies

⚫ If SBFD on PE1 detects that both the primary and backup paths fail, PE1 forwards traffic over an SRv6 BE tunnel.

BGP 100
ipv6-family vpn-instance vpn1
segment-routing ipv6 traffic-engineer best-effort

PE1 P1 P3 PE3

The primary
path fails. The backup
CE1 CE2
path fails.

Primary path
PE2 P2 P4 Traffic is carried PE4
over SRv6 BE. Backup path

Best-effort path

79 Huawei Confidential
 Contents

1. SRv6 Overview

2. SRv6 Fundamentals

3. SRv6 High Reliability

▫ Overview of SRv6 High Reliability

▫ SRv6 Tunnel Status Detection and Tunnel Protection

◼ SRv6 Egress Protection and Access Protection

4. Basic SRv6 Configuration

5. SRv6 Deployment Using iMaster NCE-IP

80 Huawei Confidential
 Overview of SRv6 Egress Protection
⚫ The tunnels of an SRv6 Policy have the same headend. In this case, the specific tunnel is determined using <Color, Endpoint>. If the endpoint of the
tunnel fails, data cannot be sent to the destination network segment.

⚫ As such, local protection and E2E protection technologies commonly used for SRv6 tunnels can protect only the source PE and transit nodes (Ps), but
not the SRv6 endpoint.

⚫ If a fault occurs on the endpoint, it is mainly rectified through VPN FRR. In addition, it can also be rectified through anycast FRR or mirror protection.

A fault on a transit link or node can be

rectified through both local protection A fault on the endpoint
and E2E protection. cannot be rectified through
local protection or E2E
PE1 P1 P3 PE3 protection.

Local protection
CE1 path CE2

Primary path

Local protection path

PE2 P2 E2E protection P4 PE4
path E2E protection path

81 Huawei Confidential

• Anycast FRR and mirror protection technologies are complex and therefore rarely used on
live networks.
VPN FRR
⚫ VPN FRR helps rectify endpoint faults by directly forming VPN backup routes. It is implemented as follows:
 The source PE pre-computes primary and backup routes based on the two learned VPN routes with different next-hop PEs and then delivers the
computed routes to the FIB table. In addition, after detecting a remote PE fault through BFD, the source PE switches VPN traffic to the backup
path before VPN route convergence.

BGP Route
Prefix NHP
PE1's BGP Route Net2 PE2
Prefix NHP
Net2 PE2
Backup PE3
P1 PE2

PE1 Net2
CE1 CE2
P2 PE3

BGP Route Primary path

Prefix NHP
Net2 PE3 Backup path

82 Huawei Confidential
 Anycast FRR
⚫ Anycast FRR implements SRv6 egress protection by deploying the same locator and VPN SID on the PEs to which a CE
is dual-homed.
P1 where TI-LFA is
DIPv6: FC05::100 deployed pre-
SIPv6: FC01::1 computes a backup
path to FC05:: /96.
Payload PE3
PE1 P1 FC05:: /96
FC01:: /96

CE1 CE2

Payload: Payload:
CE1 -> CE2 CE1 -> CE2
End.X
PE2 P2 FC04::C4 FC05:: /96
DIPv6: FC04::C4 PE4
SIPv6: FC01::1
SRH (SL = 1) Primary path
FC05::100
FC04::C4 Local protection path
Payload

83 Huawei Confidential

• Anycast FRR can be used in both egress protection and local protection scenarios.

• Although anycast FRR can provide protection against PE failures, it has the following
drawbacks:

▫ VPN SIDs must be manually configured to ensure that the two PEs configured with
the same VPN instance have the same VPN SID.

▫ Only IGP route selection (not VPN route selection) can be performed. For example, if
VPN services need to be load-balanced between PE3 and PE4 or the route advertised
by PE3 needs to be preferentially selected, VPN route selection cannot be performed
if the route advertised by PE4 is preferentially selected through an IGP on the path to
FC05::.

▫ If there is a PE-CE link interface failure, such as a failure on the link between PE3 and
CE2, traffic is still forwarded to PE3 and then to PE4, resulting in a traffic loop that
cannot be eliminated.
SRv6 Access Protection
⚫ When a CE is dual-homed to PEs, if the link between the CE and endpoint PE fails, traffic may be lost. In this case, mixed FRR can be
used to resolve this problem.
PE2's BGP Route
Prefix NHP Out-Int
Net2 CE2 PE2 -> CE2 link interface
Backup PE3 SRv6 Tunnel When the path from PE2 to
CE2 fails, the forwarding path
becomes PE2 -> PE3 -> CE2.

P1 PE2
PE3 advertises
CE1 PE1 a VPN route to Net2
PE2.
CE2
P2 PE3 CE2 advertises Primary path
common routes to
PE2 and PE3. Backup path
⚫ PE2 receives a VPN route from CE2 and another VPN route from PE3, forming FRR protection. When the link between PE2 and CE2
fails, PE2 detects the fault and steers all relevant traffic to the backup path to PE3. In this case, the next hop of the primary path is
an access interface and the backup path is an SRv6 tunnel, forming mixed FRR protection.

84 Huawei Confidential
 Contents

1. SRv6 Overview

2. SRv6 Fundamentals

3. SRv6 High Reliability

4. Basic SRv6 Configuration

◼ SRv6 BE

▫ SRv6 Policy

5. SRv6 Deployment Using iMaster NCE-IP

85 Huawei Confidential
 L3VPNv4 over SRv6 BE (1)

AS 100
Loopback0 Loopback0 Loopback0
2001:DB8:1::1/128 2001:DB8:2::2/128 2001:DB8:3::3/128
PE1 P PE2 Configuration roadmap:
:1 2001:DB88:12::/96 :2 :2 2001:DB88:23::/96 :3
1. Configure interface IPv6 addresses and IS-IS. (Configuration details are
10.0.14.0/24 10.0.35.0/24 not provided.)

Loopback1 Loopback1 2. Establish an MP-BGP peer relationship between PE1 and PE2.
10.1.4.4/32 10.1.5.5/32 3. Enable SR and establish an SRv6 BE path on the backbone network.
CE1 AS 65000 AS 65001 CE2
4. Enable the VPN instance IPv4 address family on each PE.
Networking requirements: 5. Establish an MP-IBGP peer relationship between the PEs for them to
exchange routing information.
1. Connect PE1 and PE2 to different CEs that belong to VPN instance
6. Verify the configuration.
vpna.

2. Deploy L3VPN service recursion to SRv6 BE paths on the

backbone network to enable CE1 and CE2 to communicate
through Loopback1.

86 Huawei Confidential

• The experiment configuration is based on the NE20E-S2F (software version: NE20E

V800R012C10SPC300). The configuration roadmaps for different devices are similar. For
details, see the corresponding product documentation.
L3VPNv4 over SRv6 BE (2)

AS 100 Establish an MP-IBGP peer relationship between the PEs. The

Loopback0 Loopback0 Loopback0
2001:DB8:1::1/128 2001:DB8:2::2/128 2001:DB8:3::3/128 configuration on PE1 is used as an example.
PE1 P PE2
[~PE1] bgp 100
:1 2001:DB88:12::/96 :2 :2 2001:DB88:23::/96 :3 [~PE1-bgp] peer 2001:DB8:3::3 as-number 100
[*PE1-bgp] peer 2001:DB8:3::3 connect-interface loopback 0
10.0.14.0/24 10.0.35.0/24 [*PE1-bgp] ipv4-family vpnv4
[*PE1-bgp-af-vpnv4] peer 2001:DB8:3::3 enable
Loopback1 Loopback1 [*PE1-bgp-af-vpnv4] commit
10.1.4.4/32 10.1.5.5/32 [~PE1-bgp-af-vpnv4] quit
[~PE1-bgp] quit
CE1 AS 65000 AS 65001 CE2
Check the VPNv4 peer relationship on PE1.
Configuration roadmap:
1. Configure interface IPv6 addresses and IS-IS. (Configuration details are <PE1>display bgp vpnv4 all peer
not provided.)
BGP local router ID : 10.0.1.1
2. Establish an MP-BGP peer relationship between PE1 and PE2. Local AS number : 100
3. Enable SR and establish an SRv6 BE path on the backbone network. Total number of peers : 1 Peers in established state : 1
4. Enable the VPN instance IPv4 address family on each PE.
5. Establish an MP-IBGP peer relationship between the PEs for them to Peer V AS MsgRcvd MsgSent Up/Down State
exchange routing information. 2001:DB8:3::3 4 100 3 4 00:00:04 Established
6. Verify the configuration.

87 Huawei Confidential
 L3VPNv4 over SRv6 BE (3)

AS 100 Establish an SRv6 BE path between the PEs. PE1 configurations are as
Loopback0 Loopback0 Loopback0
2001:DB8:1::1/128 2001:DB8:2::2/128 2001:DB8:3::3/128 follows: (PE2 configurations are not provided here, and the P does not
require such configurations.)
PE1 P PE2
:1 2001:DB88:12::/96 :2 :2 2001:DB88:23::/96 :3 [~PE1] segment-routing ipv6
[*PE1-segment-routing-ipv6] encapsulation source-address 2001:DB8:1::1
[*PE1-segment-routing-ipv6] locator as100 ipv6-prefix 2001:DB8:100:: 64 static
10.0.14.0/24 10.0.35.0/24
32
Loopback1 Loopback1 [*PE1-segment-routing-ipv6-locator] quit
10.1.4.4/32 10.1.5.5/32 [*PE1-segment-routing-ipv6] quit
[*PE1] bgp 100
CE1 AS 65000 AS 65001 CE2
[*PE1-bgp] ipv4-family vpnv4
Configuration roadmap: [*PE1-bgp-af-vpnv4] peer 2001:DB8:3::3 prefix-sid
[*PE1-bgp-af-vpnv4] quit
1. Configure interface IPv6 addresses and IS-IS. (Configuration details are
[~PE1-bgp] quit
not provided.) [~PE1] isis 1
2. Establish an MP-BGP peer relationship between PE1 and PE2. [~PE1-isis-1] segment-routing ipv6 locator as100
3. Enable SR and establish an SRv6 BE path on the backbone network. [*PE1-isis-1] commit
4. Enable the VPN instance IPv4 address family on each PE. [~PE1-isis-1] quit
5. Establish an MP-IBGP peer relationship between the PEs for them to
exchange routing information.
6. Verify the configuration.

88 Huawei Confidential

• Configure basic SRv6 functions as follows:

1. Run the segment-routing ipv6 command to enable SRv6 and enter the SRv6 view.
2. Run the encapsulation source-address ipv6-address [ ip-ttl ttl-value ] command to
configure a source address for SRv6 VPN encapsulation.
▪ When traffic enters an SRv6 VPN tunnel, the address configured using this
command functions as the source address in the IPv6 header. The source
address must be an existing interface address on the device.
3. Run the locator locator-name [ ipv6-prefix ipv6-address prefix-length [ static static-
length | args args-length ] * ] command to configure an SRv6 locator.
▪ The Locator field corresponds to the ipv6-prefix ipv6-address parameter and
its length is determined by the prefix-length parameter. A locator identifies an
IPv6 subnet on which all IPv6 addresses can be allocated as SRv6 SIDs. After a
locator is configured for a node, the system generates a locator route through
which other nodes can locate this node. In addition, all SIDs advertised by the
node are reachable through the route.
▪ The Function field is also called opcode, which can be dynamically allocated
using an IGP or be configured using the opcode command. When configuring a
locator, you can use the static static-length parameter to specify the static
segment length, which determines the number of static opcodes that can be
configured in the locator. In dynamic opcode allocation, the IGP allocates
opcodes outside the range of the static segment, so that no SRv6 SID conflict
occurs.
 4. (Optional) Run the opcode func-opcode end-dt4 vpn-instance vpn-instance-name
command to configure a static SID opcode.
▪ An End.DT4 SID can be dynamically allocated by BGP or be manually
configured. If you want to use the segment-routing ipv6 locator locator-name
command to enable dynamic End.DT4 SID allocation by BGP in the future, skip
this step.
5. Run the quit command to exit the SRv6 locator view.
6. Run the quit command to exit the SRv6 view.
• Enable IS-IS SRv6.
1. Run the isis [ process-id ] command to enter the IS-IS view.
2. Run the ipv6 enable topology ipv6 command to enable the IPv6 capability for the
IS-IS process in the IPv6 topology.
3. Run the segment-routing ipv6 locator locator-name [ auto-sid-disable ] command
to enable IS-IS SRv6.
▪ segment-routing ipv6 locator locator-name: enables IS-IS SRv6 and dynamic
SID allocation. SIDs must be allocated within the locator range.
▪ segment-routing ipv6 locator locator-name auto-sid-disable: enables IS-IS
SRv6 and disables dynamic SID allocation so that SIDs are statically allocated
within the locator range.
▪ During SRv6 SID allocation, if a static opcode is configured, the static opcode is
preferentially used to form a static SID. If no static opcode is configured, a SID
is dynamically allocated. The process of dynamic SRv6 SID allocation using IS-IS
is as follows:
▪ Configure a locator in the SRv6 view, and run the segment-routing ipv6
locator command in the IS-IS process view to enable SRv6 and reference the
locator. An IS-IS process can reference multiple locators. However, only one
locator can be used to advertise End/End.X SIDs.
▪ IS-IS allocates an End SID to each locator in the range of the dynamic segment
based on locator configurations. Both PSP and non-PSP SIDs can be allocated.
▪ Configure IPv6 addresses for interfaces and enable IS-IS IPv6. IS-IS allocates
both PSP and non-PSP End.X SIDs to the interfaces in the range of the dynamic
segment based on locator configurations.
4. Run the quit command to exit the IS-IS view.
• Configure the device to add SIDs to VPN routes.
▫ Run the peer ipv6-address prefix-sid command to enable the device to exchange IPv4
prefix SID information with the specified IPv6 peer.
 L3VPNv4 over SRv6 BE (4)

AS 100 Enable the VPN instance IPv4 address family on each PE. PE1
Loopback0 Loopback0 Loopback0
2001:DB8:1::1/128 2001:DB8:2::2/128 2001:DB8:3::3/128 configurations are as follows: (PE2 configurations are not
provided.)
PE1 P PE2
:1 2001:DB88:12::/96 :2 :2 2001:DB88:23::/96 :3 [~PE1] ip vpn-instance vpna
[*PE1-vpn-instance-vpna] ipv4-family
10.0.14.0/24 10.0.35.0/24 [*PE1-vpn-instance-vpna-af-ipv4] route-distinguisher 100:1
[*PE1-vpn-instance-vpna-af-ipv4] vpn-target 111:1 both
Loopback1 Loopback1 [*PE1-vpn-instance-vpna-af-ipv4] quit
10.1.4.4/32 10.1.5.5/32 [*PE1-vpn-instance-vpna] quit
[~PE1] bgp 100
CE1 AS 65000 AS 65001 CE2
[*PE1-bgp] ipv4-family vpn-instance vpna
[*PE1-bgp-vpna] peer 10.0.14.4 as-number 65000
Configuration roadmap: [*PE1-bgp-vpna] segment-routing ipv6 best-effort
1. Configure interface IPv6 addresses and IS-IS. (Configuration details are [*PE1-bgp-vpna] segment-routing ipv6 locator as100
not provided.) [*PE1-bgp-vpna] commit
2. Establish an MP-BGP peer relationship between PE1 and PE2. [~PE1-bgp-vpna] quit
[~PE1-bgp] quit
3. Enable SR and establish an SRv6 BE path on the backbone network.
4. Enable the VPN instance IPv4 address family on each PE.
5. Establish an MP-IBGP peer relationship between the PEs for them to
exchange routing information.
6. Verify the configuration.

90 Huawei Confidential

• Configure VPN routes to recurse to SRv6 BE paths based on the carried SIDs.

1. Run the bgp { as-number-plain | as-number-dot } command to enter the BGP view.

2. Run the ipv4-family vpn-instance vpn-instance-name command to enter the BGP-

VPN instance IPv4 address family view.

3. Run the segment-routing ipv6 best-effort command to enable VPN route recursion
based on the SIDs carried by routes.

4. Run the segment-routing ipv6 locator locator-name [ auto-sid-disable ] command

to enable the device to add SIDs to VPN routes.

5. If auto-sid-disable is not specified, dynamic SID allocation is supported. If there are

static SIDs in the range of the locator specified using locator-name, the static SIDs
are used. Otherwise, dynamically allocated SIDs are used. If auto-sid-disable is
specified, BGP does not dynamically allocate SIDs.

6. Run the commit command to commit the configuration.

L3VPNv4 over SRv6 BE (5)

AS 100
Loopback0 Loopback0 Loopback0 Check the local SID table containing all types of SRv6 SIDs on PE2.
2001:DB8:1::1/128 2001:DB8:2::2/128 2001:DB8:3::3/128 <PE2>display segment-routing ipv6 local-sid forwarding
PE1 P PE2
My Local-SID Forwarding Table
:1 2001:DB88:12::/96 :2 :2 2001:DB88:23::/96 :3 -------------------------------------
SID : 2001:DB8:300::1:0:0/128 FuncType : End
10.0.14.0/24 10.0.35.0/24 LocatorName: as100 LocatorID: 2

Loopback1 Loopback1 SID : 2001:DB8:300::1:0:1/128 FuncType : End

10.1.4.4/32 10.1.5.5/32 LocatorName: as100 LocatorID: 2
CE1 AS 65000 AS 65001 CE2
SID : 2001:DB8:300::1:0:2/128 FuncType : End.X
LocatorName: as100 LocatorID: 2
Configuration roadmap:
1. Configure interface IPv6 addresses and IS-IS. (Configuration details are SID : 2001:DB8:300::1:0:3/128 FuncType : End.X
not provided.) LocatorName: as100 LocatorID: 2
2. Establish an MP-BGP peer relationship between PE1 and PE2.
3. Enable SR and establish an SRv6 BE path on the backbone network. SID : 2001:DB8:300::1:0:20/128 FuncType : End.DT4
4. Enable the VPN instance IPv4 address family on each PE. LocatorName: as100
5. Establish an MP-IBGP peer relationship between the PEs for them to
exchange routing information. PE2 locally generates an End.DT4 SID and advertises the SID to PE1.
6. Verify the configuration.

91 Huawei Confidential
L3VPNv4 over SRv6 BE (6)

AS 100
Loopback0 Loopback0 Loopback0 Check VPNv4 routing information on PE1.
2001:DB8:1::1/128 2001:DB8:2::2/128 2001:DB8:3::3/128 <PE1>display bgp vpnv4 al routing-table 10.1.5.5
PE1 P PE2 BGP local router ID : 10.0.1.1
Local AS number : 100
:1 2001:DB88:12::/96 :2 :2 2001:DB88:23::/96 :3 Total routes of Route Distinguisher(100:1): 1
BGP routing table entry information of 10.1.5.5/32:
10.0.14.0/24 10.0.35.0/24 Label information (Received/Applied): 3/NULL
From: 2001:DB8:3::3 (10.0.3.3)
Loopback1 Loopback1 Route Duration: 0d00h15m54s
10.1.4.4/32 10.1.5.5/32 Relay IP Nexthop: FE80::DE99:14FF:FE7A:C301
CE1 AS 65000 AS 65001 CE2 Relay IP Out-Interface: GigabitEthernet0/3/0.12
Relay Tunnel Out-Interface:
Original nexthop: 2001:DB8:3::3
Configuration roadmap:
Qos information : 0x0
1. Configure interface IPv6 addresses and IS-IS. (Configuration details are Ext-Community: RT <111 : 1>
not provided.) Prefix-sid: 2001:DB8:300::1:0:20
2. Establish an MP-BGP peer relationship between PE1 and PE2. AS-path Nil, origin incomplete, MED 0, localpref 100, pref-val 0, valid, internal,
3. Enable SR and establish an SRv6 BE path on the backbone network. best, select, pre 255, IGP cost 20
4. Enable the VPN instance IPv4 address family on each PE. Not advertised to any peer yet
5. Establish an MP-IBGP peer relationship between the PEs for them to
exchange routing information. IPv6 address of the peer; SID corresponding to 10.1.5.5 (the same
6. Verify the configuration. as that locally allocated on PE2)

92 Huawei Confidential
L3VPNv4 over SRv6 BE (7)

AS 100
Loopback0 Loopback0 Loopback0 Check vpna's routing information on PE1.
2001:DB8:1::1/128 2001:DB8:2::2/128 2001:DB8:3::3/128 <PE1> display ip routing-table vpn-instance vpna 10.1.5.5 verbose
PE1 P PE2 Route Flags: R - relay, D - download to fib, T - to vpn-instance, B - black hole
route
:1 2001:DB88:12::/96 :2 :2 2001:DB88:23::/96 :3 ------------------------------------------------------------------------------
Routing Table : vpna
10.0.14.0/24 10.0.35.0/24 Summary Count : 1

Loopback1 Loopback1 Destination: 10.1.5.5/32

10.1.4.4/32 10.1.5.5/32 Protocol: IBGP Process ID: 0
CE1 AS 65000 AS 65001 CE2 Preference: 255 Cost: 0
NextHop: 2001:DB8:300::1:0:20 Neighbour: 2001:DB8:3::3
State: Active Adv Relied Age: 00h17m40s
Configuration roadmap:
Tag: 0 Priority: low
1. Configure interface IPv6 addresses and IS-IS. (Configuration details Label: 3 QoSInfo: 0x0
are not provided.) IndirectID: 0x1000177 Instance:
2. Establish an MP-BGP peer relationship between PE1 and PE2. RelayNextHop: 2001:DB8:300::1:0:20 Interface: SRv6 BE
3. Enable SR and establish an SRv6 BE path on the backbone network. TunnelID: 0x0 Flags: RD
4. Enable the VPN instance IPv4 address family on each PE.
5. Establish an MP-IBGP peer relationship between the PEs for them to Interface type: SRv6 BE
exchange routing information.
6. Verify the configuration. PE1 uses this IPv6 address as the next-hop address to forward
packets destined for 10.1.5.5.

93 Huawei Confidential
L3VPNv4 over SRv6 BE (8)

AS 100
Loopback0 Loopback0 Loopback0
2001:DB8:1::1/128 2001:DB8:2::2/128 2001:DB8:3::3/128 Verify the configuration on CE1.
<CE1>ping -a 10.1.4.4 10.1.5.5
PE1 P PE2
PING 10.1.5.5: 56 data bytes, press CTRL_C to break
:1 2001:DB88:12::/96 :2 :2 2001:DB88:23::/96 :3 Reply from 10.1.5.5: bytes=56 Sequence=1 ttl=254 time=1 ms
Reply from 10.1.5.5: bytes=56 Sequence=2 ttl=254 time=1 ms
10.0.14.0/24 10.0.35.0/24 Reply from 10.1.5.5: bytes=56 Sequence=3 ttl=254 time=1 ms
Reply from 10.1.5.5: bytes=56 Sequence=4 ttl=254 time=1 ms
Loopback1 Loopback1 Reply from 10.1.5.5: bytes=56 Sequence=5 ttl=254 time=1 ms
10.1.4.4/32 10.1.5.5/32
CE1 AS 65000 AS 65001 CE2

Configuration roadmap:
1. Configure interface IPv6 addresses and IS-IS. (Configuration details are
not provided.)
2. Establish an MP-BGP peer relationship between PE1 and PE2.
3. Enable SR and establish an SRv6 BE path on the backbone network.
4. Enable the VPN instance IPv4 address family on each PE.
5. Establish an MP-IBGP peer relationship between the PEs for them to
exchange routing information.
6. Verify the configuration.

94 Huawei Confidential
 Contents

1. SRv6 Overview

2. SRv6 Fundamentals

3. SRv6 High Reliability

4. Basic SRv6 Configuration

▫ SRv6 BE
◼ SRv6 Policy

5. SRv6 Deployment Using iMaster NCE-IP

95 Huawei Confidential
L3VPNv4 over SRv6 Policy (1)

AS 100
Loopback0 Loopback0 Loopback0
2001:DB8:1::1/128 2001:DB8:2::2/128 2001:DB8:3::3/128 Configuration roadmap:
PE1 P PE2
1. Configure interface IPv6 addresses and IS-IS. (Configuration
:1 2001:DB88:12::/96 :2 :2 2001:DB88:23::/96 :3
details are not provided.)
10.0.14.0/24 10.0.35.0/24 2. Establish an MP-BGP peer relationship between PE1 and PE2.
Loopback1 Loopback1 3. Enable SR and establish an SRv6 Policy on the backbone
10.1.4.4/32 10.1.5.5/32
network.
CE1 AS 65000 AS 65001 CE2
4. Enable the VPN instance IPv4 address family on each PE and
Networking requirements: establish an MP-IBGP peer relationship between the PEs for

1. Connect PE1 and PE2 to different CEs that belong to VPN instance them to exchange routing information.

vpna. 5. Configure a tunnel policy and import VPN traffic.

6. Verify the configuration.
2. Deploy L3VPN service recursion to SRv6 Policies on the backbone
network to enable CE1 and CE2 to communicate through Loopback1.

96 Huawei Confidential
 L3VPNv4 over SRv6 Policy (2)

AS 100 Establish an MP-IBGP peer relationship between the PEs.

End End End
2001:DB8:1000::111 2001:DB8:2000::222 2001:DB8:3000::333 [~PE1] bgp 100
PE1 P PE2 [~PE1-bgp] peer 2001:DB8:3::3 as-number 100
[*PE1-bgp] peer 2001:DB8:3::3 connect-interface loopback 0
:1 2001:DB88:12::/96 :2 :2 2001:DB88:23::/96 :3 [*PE1-bgp] ipv4-family vpnv4
[*PE1-bgp-af-vpnv4] peer 2001:DB8:3::3 enable
10.0.14.0/24 10.0.35.0/24 [*PE1-bgp-af-vpnv4] commit
[~PE1-bgp-af-vpnv4] quit
Loopback1 Loopback1 [~PE1-bgp] quit
10.1.4.4/32 10.1.5.5/32
CE1 AS 65000 AS 65001 CE2 Check the VPNv4 peer relationship on PE1.
Configuration roadmap: <PE1>display bgp vpnv4 all peer
1. Configure interface IPv6 addresses and IS-IS. (Configuration details are
BGP local router ID : 10.0.1.1
not provided.)
Local AS number : 100
2. Establish an MP-BGP peer relationship between PE1 and PE2. Total number of peers : 1 Peers in established state : 1
3. Enable SR and establish an SRv6 Policy on the backbone network.
4. Enable the VPN instance IPv4 address family on each PE and establish an Peer V AS MsgRcvd MsgSent Up/Down State
MP-IBGP peer relationship between the PEs for them to exchange 2001:DB8:3::3 4 100 3 4 00:00:04 Established
routing information.
5. Configure a tunnel policy and import VPN traffic.
6. Verify the configuration.

97 Huawei Confidential

• The SIDs of PE1, the P, and PE2 are 2001:DB8:1000::111, 2001:DB8:2000::222, and
2001:DB8:3000::333, respectively.

• In this experiment, the SRv6 Policy is established based on specified End SIDs.
 L3VPNv4 over SRv6 Policy (3)

AS 100 Configure an SRv6 SID. PE1 configurations are as follows: (P and

End End End
2001:DB8:1000::111 2001:DB8:2000::222 2001:DB8:3000::333 PE2 configurations are not provided.)
PE1 P PE2 [~PE1] segment-routing ipv6
:1 2001:DB88:12::/96 :2 :2 2001:DB88:23::/96 :3 [*PE1-segment-routing-ipv6] encapsulation source-address 2001:DB8:1::1
[*PE1-segment-routing-ipv6] locator as1000 ipv6-prefix 2001:DB8:1000:: 64
static 32
10.0.14.0/24 10.0.35.0/24 [*PE1-segment-routing-ipv6-locator] opcode ::111 end
[*PE1-segment-routing-ipv6-locator] quit
Loopback1 Loopback1
[*PE1-segment-routing-ipv6] quit
10.1.4.4/32 10.1.5.5/32
[*PE1] bgp 100
CE1 AS 65000 AS 65001 CE2 [*PE1-bgp] ipv4-family vpnv4
[*PE1-bgp-af-vpnv4] peer 2001:DB8:3::3 prefix-sid
Configuration roadmap: [*PE1-bgp-af-vpnv4] quit
1. Configure interface IPv6 addresses and IS-IS. (Configuration details are [~PE1-bgp] quit
not provided.) [~PE1] isis 1
2. Establish an MP-BGP peer relationship between PE1 and PE2. [~PE1-isis-1] segment-routing ipv6 locator as1000 auto-sid-disable
3. Enable SR and establish an SRv6 Policy on the backbone network. [*PE1-isis-1] commit
[~PE1-isis-1] quit
4. Enable the VPN instance IPv4 address family on each PE and establish
an MP-IBGP peer relationship between the PEs for them to exchange
routing information.
Manually configure an SRv6 End SID.
5. Configure a tunnel policy and import VPN traffic.
6. Verify the configuration.

98 Huawei Confidential

• SRv6 paths are established using SIDs. Static SRv6 SIDs are recommended. The
configuration procedure is as follows:

1. Run the locator locator-name [ ipv6-prefix ipv6-address prefix-length [ static static-

length | args args-length ] * ] command to configure an SRv6 locator.

2. Run the opcode func-opcode end command to configure a static End SID opcode.

3. Run the opcode func-opcode end-x interface interface-name nexthop nexthop-

address [ no-psp ] command to configure a static End.X SID opcode.

4. Run the quit command to exit the SRv6 locator view.

 L3VPNv4 over SRv6 Policy (4)
Configure an SRv6 Policy. PE1 configurations are as follows: (PE2
AS 100 configurations are not provided.)
End End End
2001:DB8:1000::111 2001:DB8:2000::222 2001:DB8:3000::333 [~PE1] segment-routing ipv6
[~PE1-segment-routing-ipv6] segment-list list1
PE1 P PE2 [*PE1-segment-routing-ipv6-segment-list-list1] index 5 sid ipv6
:1 2001:DB88:12::/96 :2 :2 2001:DB88:23::/96 :3 2001:DB8:2000::222
[*PE1-segment-routing-ipv6-segment-list-list1] index 10 sid ipv6
10.0.14.0/24 10.0.35.0/24 2001:DB8:3000::333
[*PE1-segment-routing-ipv6-segment-list-list1] commit
Loopback1 Loopback1 [~PE1-segment-routing-ipv6-segment-list-list1] quit
10.1.4.4/32 10.1.5.5/32 [~PE1-segment-routing-ipv6] srv6-te-policy locator as1000
[*PE1-segment-routing-ipv6] srv6-te policy policy1 endpoint 2001:DB8:3::3 color
CE1 AS 65000 AS 65001 CE2 101
Configuration roadmap: [*PE1-segment-routing-ipv6-policy-policy1] binding-sid 2001:DB8:1000::100
[*PE1-segment-routing-ipv6-policy-policy1] candidate-path preference 100
1. Configure interface IPv6 addresses and IS-IS. (Configuration details
[*PE1-segment-routing-ipv6-policy-policy1-path] segment-list list1
are not provided.) [*PE1-segment-routing-ipv6-policy-policy1-path] commit
2. Establish an MP-BGP peer relationship between PE1 and PE2. [~PE1-segment-routing-ipv6-policy-policy1-path] quit
3. Enable SR and establish an SRv6 Policy on the backbone network. [~PE1-segment-routing-ipv6-policy-policy1] quit
4. Enable the VPN instance IPv4 address family on each PE and establish [~PE1-segment-routing-ipv6] quit
an MP-IBGP peer relationship between the PEs for them to exchange
routing information.
5. Configure a tunnel policy and import VPN traffic. Specify SRv6 End SIDs for the P and PE2 in sequence.
6. Verify the configuration.
Specify the color and endpoint.

99 Huawei Confidential

• Configure a segment list.

1. Run the system-view command to enter the system view.

2. Run the segment-routing ipv6 command to enable SRv6 and enter the SRv6 view.

3. Run the segment-list list-name command to configure a segment list (an explicit
path) for an SRv6 Policy candidate path and enter the segment list view.

4. Run the index index sid ipv6 ipv6address command to specify a next-hop SID for the
segment list.

▪ You can run the command multiple times. The system generates a SID stack for
the segment list by index index in ascending order. If a candidate path in the
SRv6 Policy is preferentially selected, traffic is forwarded using the segment
lists of the candidate path. A maximum of 10 SIDs can be configured for each
segment list.

5. Run the commit command to commit the configuration.

• Configure an SRv6 Policy.

1. Run the system-view command to enter the system view.

2. Run the segment-routing ipv6 command to enable SRv6 and enter the SRv6 view.

3. Run the srv6-te-policy locator locator-name command to associate a locator with

the SRv6 Policy to be created. This configuration allows you to specify a binding SID
for the SRv6 Policy in the locator range.

4. Run the srv6-te policy name-value endpoint endpoint-ip color color-value command
to create an SRv6 Policy and enter the SRv6 Policy view.

5. (Optional) Run the binding-sid binding-sid command to configure a binding SID for
the SRv6 Policy.

▪ The value of binding-sid must be within the range of the static segment
specified using the locator locator-name [ ipv6-prefix ipv6-address prefix-
length [ static static-length | args args-length ] * ] command.

6. Run the candidate-path preference preference command to configure a candidate

path and its preference for the SRv6 Policy.

▪ Each SRv6 Policy supports multiple candidate paths. A larger preference value
indicates a higher candidate path preference. If multiple candidate paths are
configured, the one with the highest preference takes effect.

7. Run the segment-list list-name [ weight weight-value | path-mtu mtu-value ] *

command to configure a segment list for the candidate path of the SRv6 Policy.

▪ The segment list must have been created using the segment-list (SRv6 view)
command.

8. Run the commit command to commit the configuration.

 L3VPNv4 over SRv6 Policy (5)

AS 100 Enable the VPN instance IPv4 address family on each PE. PE1
End End End
2001:DB8:1000::111 2001:DB8:2000::222 2001:DB8:3000::333 configurations are as follows: (PE2 configurations are not
provided.)
PE1 P PE2
:1 2001:DB88:12::/96 :2 :2 2001:DB88:23::/96 :3 [~PE1] ip vpn-instance vpna
[*PE1-vpn-instance-vpna] ipv4-family
10.0.14.0/24 10.0.35.0/24 [*PE1-vpn-instance-vpna-af-ipv4] route-distinguisher 100:1
[*PE1-vpn-instance-vpna-af-ipv4] vpn-target 111:1 both
Loopback1 Loopback1 [*PE1-vpn-instance-vpna-af-ipv4] quit
10.1.4.4/32 10.1.5.5/32 [*PE1-vpn-instance-vpna] quit
CE1 AS 65000 AS 65001 CE2 [*PE1-bgp] ipv4-family vpn-instance vpna
[*PE1-bgp-vpna] segment-routing ipv6 traffic-engineer best-effort
Configuration roadmap: [*PE1-bgp-vpna] segment-routing ipv6 locator as1000
1. Configure interface IPv6 addresses and IS-IS. (Configuration details are [*PE1-bgp-vpna] commit
not provided.) [~PE1-bgp-vpna] quit
[~PE1-bgp] quit
2. Establish an MP-BGP peer relationship between PE1 and PE2.
3. Enable SR and establish an SRv6 Policy on the backbone network.
4. Enable the VPN instance IPv4 address family on each PE and establish
an MP-IBGP peer relationship between the PEs for them to exchange
routing information.
5. Configure a tunnel policy and import VPN traffic.
6. Verify the configuration.

101 Huawei Confidential

• segment-routing ipv6 traffic-engineer best-effort //If an SRv6 BE path exists on the

network, you can set the best-effort parameter, allowing the SRv6 BE path to function as a
best-effort path in the case of an SRv6 Policy fault.
L3VPNv4 over SRv6 Policy (6)

AS 100 Configure a tunnel policy and import VPN traffic. PE1

End End End
2001:DB8:1000::111 2001:DB8:2000::222 2001:DB8:3000::333 configurations are as follows: (PE2 configurations are not
provided.)
PE1 P PE2
:1 2001:DB88:12::/96 :2 :2 2001:DB88:23::/96 :3
[~PE1] route-policy p1 permit node 10
10.0.14.0/24 10.0.35.0/24 [*PE1-route-policy] apply extcommunity color 0:101
[*PE1-route-policy] quit
Loopback1 Loopback1 [*PE1] bgp 100
10.1.4.4/32 10.1.5.5/32 [*PE1-bgp] ipv4-family vpnv4
CE1 AS 65000 AS 65001 CE2 [*PE1-bgp-af-vpnv4] peer 2001:DB8:3::3 route-policy p1 import
[*PE1-bgp-af-vpnv4] quit
Configuration roadmap: [*PE1-bgp] quit
1. Configure interface IPv6 addresses and IS-IS. (Configuration details are [*PE1] tunnel-policy p1
not provided.) [*PE1-tunnel-policy-p1] tunnel select-seq ipv6 srv6-te-policy load-balance-
2. Establish an MP-BGP peer relationship between PE1 and PE2. number 1
[*PE1-tunnel-policy-p1] quit
3. Enable SR and establish an SRv6 Policy on the backbone network.
[*PE1] ip vpn-instance vpna
4. Enable the VPN instance IPv4 address family on each PE and establish [*PE1-vpn-instance-vpna] ipv4-family
an MP-IBGP peer relationship between the PEs for them to exchange [*PE1-vpn-instance-vpna-af-ipv4] tnl-policy p1
routing information. [*PE1-vpn-instance-vpna-af-ipv4] commit
5. Configure a tunnel policy and import VPN traffic. [~PE1-vpn-instance-vpna-af-ipv4] quit
6. Verify the configuration. [~PE1-vpn-instance-vpna] quit

102 Huawei Confidential

L3VPNv4 over SRv6 Policy (7)

AS 100
End End End Check SRv6 Policy information on PE1.
2001:DB8:1000::111 2001:DB8:2000::222 2001:DB8:3000::333 <PE1>display srv6-te policy
PE1 P PE2 PolicyName : policy1
Color : 101 Endpoint : 2001:DB8:3::3
:1 2001:DB88:12::/96 :2 :2 2001:DB88:23::/96 :3 TunnelId :1 Binding SID : 2001:DB8:1000::100
TunnelType : SRv6-TE Policy DelayTimerRemain :
10.0.14.0/24 10.0.35.0/24 Policy State : Up
Admin State : UP Traffic Statistics : Disable
Loopback1 Loopback1 Candidate-path Count : 1
10.1.4.4/32 10.1.5.5/32 Candidate-path Preference : 100
CE1 AS 65000 AS 65001 CE2 Path State : Active Path Type : Primary
Protocol-Origin : Configuration(30) Originator : 0, 0.0.0.0
Configuration roadmap: Discriminator : 100 Binding SID : 2001:DB8:1000::100
1. Configure interface IPv6 addresses and IS-IS. (Configuration details GroupId :1 Policy Name : policy1
are not provided.) DelayTimerRemain :- Segment-List Count : 1
2. Establish an MP-BGP peer relationship between PE1 and PE2. Segment-List : list1
Segment-List ID : 1 XcIndex :1
3. Enable SR and establish an SRv6 Policy on the backbone network. List State : Up DelayTimerRemain : -
4. Enable the VPN instance IPv4 address family on each PE and establish Weight :1 BFD State :-
an MP-IBGP peer relationship between the PEs for them to exchange SID :
routing information. 2001:DB8:2000::222
5. Configure a tunnel policy and import VPN traffic. 2001:DB8:3000::333
6. Verify the configuration.
Color of the specified SRv6 Policy

103 Huawei Confidential

L3VPNv4 over SRv6 Policy (8)

AS 100
End End End Check VPNv4 routing information on PE1.
2001:DB8:1000::111 2001:DB8:2000::222 2001:DB8:3000::333 <PE1> display bgp vpnv4 all routing-table 10.1.5.5
PE1 P PE2 BGP local router ID : 10.0.1.1
Local AS number : 100
:1 2001:DB88:12::/96 :2 :2 2001:DB88:23::/96 :3 Total routes of Route Distinguisher(100:1): 1
BGP routing table entry information of 10.1.5.5/32:
10.0.14.0/24 10.0.35.0/24 Label information (Received/Applied): 3/NULL
From: 2001:DB8:3::3 (10.0.13.3)
Loopback1 Loopback1 Route Duration: 0d00h03m30s
10.1.4.4/32 10.1.5.5/32 Relay IP Nexthop: FE80::DE99:14FF:FE7A:C301
CE1 AS 65000 AS 65001 CE2 Relay IP Out-Interface: GigabitEthernet0/3/0.12
Relay Tunnel Out-Interface:
Configuration roadmap: Original nexthop: 2001:DB8:3::3
1. Configure interface IPv6 addresses and IS-IS. (Configuration details are Qos information : 0x0
not provided.) Ext-Community: RT <111 : 1>, Color <0 : 101>
Prefix-sid: 2001:DB8:3000::1:0:1E
2. Establish an MP-BGP peer relationship between PE1 and PE2.
AS-path 65000, origin incomplete, MED 0, localpref 100, pref-val 0, valid,
3. Enable SR and establish an SRv6 Policy on the backbone network. internal, best, select, pre 255, IGP cost 20
4. Enable the VPN instance IPv4 address family on each PE and establish an Not advertised to any peer yet
MP-IBGP peer relationship between the PEs for them to exchange routing
information.
5. Configure a tunnel policy and import VPN traffic. The route recurses to the corresponding
6. Verify the configuration. SRv6 Policy based on the color attribute.

104 Huawei Confidential

L3VPNv4 over SRv6 Policy (9)

AS 100 Check vpna's routing information on PE1.

End End End
2001:DB8:1000::111 2001:DB8:2000::222 2001:DB8:3000::333 <PE1>display ip routing-table vpn-instance vpna 10.1.5.5 verbose
PE1 P PE2 Routing Table : vpna
Summary Count : 1
:1 2001:DB88:12::/96 :2 :2 2001:DB88:23::/96 :3 Destination: 10.1.5.5/32
Protocol: IBGP Process ID: 0
10.0.14.0/24 10.0.35.0/24 Preference: 255 Cost: 0
NextHop: 2001:DB8:3::3 Neighbour: 2001:DB8:3::3
Loopback1 Loopback1 State: Active Adv Relied Age: 00h08m38s
10.1.4.4/32 10.1.5.5/32 Tag: 0 Priority: low
CE1 AS 65000 AS 65001 CE2 Label: 3 QoSInfo: 0x0
IndirectID: 0x1000174 Instance:
Configuration roadmap: RelayNextHop: :: Interface: policy1
1. Configure interface IPv6 addresses and IS-IS. (Configuration details TunnelID: 0x000000003400000001 Flags: RD
are not provided.)
2. Establish an MP-BGP peer relationship between PE1 and PE2. The outbound interface is an
Verify the configuration on CE1. SRv6 Policy interface.
3. Enable SR and establish an SRv6 Policy on the backbone network.
4. Enable the VPN instance IPv4 address family on each PE and establish <CE1>ping -a 10.1.4.4 10.1.5.5
an MP-IBGP peer relationship between the PEs for them to exchange PING 10.1.5.5: 56 data bytes, press CTRL_C to break
Reply from 10.1.5.5: bytes=56 Sequence=1 ttl=254 time=1 ms
routing information. Reply from 10.1.5.5: bytes=56 Sequence=2 ttl=254 time=1 ms
5. Configure a tunnel policy and import VPN traffic. Reply from 10.1.5.5: bytes=56 Sequence=3 ttl=254 time=1 ms
6. Verify the configuration. Reply from 10.1.5.5: bytes=56 Sequence=4 ttl=254 time=1 ms
Reply from 10.1.5.5: bytes=56 Sequence=5 ttl=254 time=1 ms

105 Huawei Confidential

 Contents

1. SRv6 Overview

2. SRv6 Fundamentals

3. SRv6 High Reliability

4. Basic SRv6 Configuration

5. SRv6 Deployment Using iMaster NCE-IP

106 Huawei Confidential

 SRv6 Deployment Using iMaster NCE-IP
⚫ Static SRv6 deployment on the live network poses great challenges to network O&M. For example, static SRv6 deployment takes a
long period and does not support global path planning or network quality-based SRv6 forwarding path adjustment.

⚫ Deploying SRv6 through iMaster NCE-IP can avoid the problems faced by static SRv6 deployment.
⚫ iMaster NCE-IP uses the following protocols to deploy SRv6 tunnels and VPN services:
 BGP-LS

 BGP IPv6 SR Policy iMaster NCE-IP

 NETCONF

R2

R1 R4 R3

107 Huawei Confidential

• IGP: generates network topology information, such as bandwidth, delay, and SID
information, on a router.

• BGP-LS: collects topology information and reports collected information to the controller. If
an RR exists on the network, you only need to deploy BGP-LS on the RR and establish a
BGP-LS peer relationship between the RR and controller.

• BGP IPv6 SR Policy: Such a peer relationship is established between the controller and
forwarder, so that the controller can deliver an SRv6 Policy to the forwarder through the
peer relationship to direct traffic forwarding. To reduce the number of peer relationships,
you can deploy an RR and configure PEs and the controller to function as RR clients.

• NETCONF: delivers service configurations from the controller to forwarders. This document
does not describe service delivery or NETCONF-related configuration.
 SRv6 Policy Advertisement Process
⚫ To facilitate configuration, the controller provides the
3 Automatic path
following functions: planning by the
controller 2
Requirement
 Directly creates a bidirectional tunnel between the ingress input
and egress. In other words, a tunnel from the egress to
4 Network
the ingress is automatically created when a tunnel from Network
1 administrator
Forwarding path
topology

BGP-LS
the ingress to the egress is created. deployment
reporting
PE1 RR PE3
 Allows you to configure tunnel and color templates to
simplify the configuration of some parameters.
Tunnel status
reporting
⚫ In Huawei's CloudWAN solution:
5
 The SRv6 Policy configurations are delivered by BGP IPv6
PE2 P1 PE4
SR Policy, and the tunnel status is reported by BGP-LS.
SRv6 Policy
BGP-LS peer
BGP SR-Policy peer

108 Huawei Confidential

• The process of planning and deploying forwarding paths through iMaster NCE-IP is as
follows:

▫ Devices use BGP-LS to report network topology information to the controller, which
then generates forwarding paths based on requirements.

▫ The controller delivers the computed paths to the devices through BGP IPv6 SR
Policy.

▫ Target traffic travels along the delivered paths.

Key Information Required for SRv6 Policy Path Computation
⚫ iMaster NCE-IP uses an IGP to collect the following key information
for SRv6 Policy path computation:
 SID information: End and End.X SIDs.

 Locator information: After a locator is configured for a node, the system

generates a locator route and propagates the route throughout the SR
iMaster NCE-IP
domain using an IGP. Other nodes on the network can locate this node
through the locator route.

 Interface bandwidth information: physical bandwidth and reservable

bandwidth.

 Interface delay and packet loss rate.

IGP
 Network topology information.

⚫ BGP-LS advertises the information collected by an IGP to iMaster R1 R3

NCE-IP.

R2

109 Huawei Confidential

Basic IGP Configurations
⚫ In Huawei's SRv6 solution, it is recommended that extended IS-IS be used as an IGP for the collection of basic network information.

⚫ Basic IGP configurations are as follows:

 Global IS-IS configurations
[P1]isis 1
[P1-isis-1] is-level level-2
[P1-isis-1] cost-style wide //TE information (such as bandwidth information) required in TE scenarios cannot be carried in narrow mode. Therefore, the wide type needs to be set.
[P1-isis-1] network-entity 49.0001.0010.0000.0005.00
[P1-isis-1] is-name P1
[P1-isis-1] ipv6 enable topology ipv6
[P1-isis-1] ipv6 bgp-ls enable level-2 //The device is enabled to send topology information collected by IS-IS to the controller through BGP-LS. This function only needs to be
configured on the RR. That is, only one device in the IGP domain needs to send topology information to the controller through BGP-LS.
[P1-isis-1] ipv6 advertise link attributes //The device is enabled to carry link attribute-related TLVs in LSPs. TLV information includes the IPv6 addresses and indexes of interfaces.
[P1-isis-1] ipv6 metric-delay advertisement enable level-1-2 //The device is enabled to advertise IPv6 delay information. Intra-domain IPv4 link delay information is collected and
flooded through IS-IS and then reported to the controller through BGP-LS. Based on the delay information, the controller computes the optimal path on the P2P network.
[P1-isis-1] ipv6 traffic-eng level-2 //IS-IS TE is enabled so that link bandwidth information is reported to the TE module.

 Interface-specific IS-IS configurations

[P1]interface GigabitEthernet0/3/0
[P1-GigabitEthernet0/3/0] isis ipv6 enable 1
[P1-GigabitEthernet0/3/0] isis circuit-type p2p //The IS-IS interface's network type must be set to P2P. Otherwise, the required network topology cannot be formed on the
controller.

110 Huawei Confidential

Topology Information Reporting to the Controller Through BGP-LS

⚫ Each router maintains one or more LSDBs. Each LSDB contains multiple link attributes, such as the interface IP
address, link metric, TE metric, link bandwidth, and reservable bandwidth. The BGP process of a router obtains
information from these LSDBs and carries the information in the extended NLRI attribute.

R1's link state R1's link state Node NLRI

information information
Link NLRI
R2's link state R2's link state
information Extraction information NLRI Topology Prefix NLRI Reporting Controller
R3's link state R3's link state (IPv4)
information information Topology Prefix NLRI
R2's LSDB R2's BGP process (IPv6)

Advertised to the BGP-LS peer

111 Huawei Confidential

BGP-LS Deployment
⚫ BGP-LS is mainly used to upload network topology and tunnel information. As such, iMaster NCE-IP needs to establish BGP-LS peer relationships with
at least two types of devices:
 Establishes a BGP-LS peer relationship with an intra-AS network node, which is usually a BGP RR, in order to obtain network topology information.

 Establishes a BGP-LS peer relationship with the ingress of the involved tunnel in order to obtain SRv6 Policy status.

⚫ BGP-LS deployment solutions:

iMaster NCE-IP
iMaster NCE-IP

BGP-LS
PE1 RR PE2
PE1 P1 PE2

CE1 CE2
CE1 CE2
⚫ Solution 2: Establish BGP-LS peer relationships between iMaster NCE-IP
⚫ Solution 1: Establish BGP-LS peer relationships between and RRs and between the RRs and other devices.
iMaster NCE-IP and all PEs and between iMaster NCE-IP and all ⚫ Solution 2 is recommended to reduce the number of BGP peers
Ps. maintained by iMaster NCE-IP.

112 Huawei Confidential

 BGP-LS Peer Relationship Establishment

BGP-LS
2000::102 FC01::5

[P1]display bgp link-state unicast peer

[P1]bgp 65001
BGP local router ID : 1.0.0.5
[P1-bgp]peer 2000::102 as-number 65001 Local AS number : 65001
[P1-bgp]peer 2000::102 connect-interface LoopBack0 Total number of peers : 1 Peers in established state : 1
[P1-bgp]link-state-family unicast
[P1-bgp-af-ls]peer 2000::102 enable Peer V AS MsgRcvd MsgSent OutQ Up/Down State PrefRcv
2000::102 4 65001 72877 72106 0 1039h31m Established 0

113 Huawei Confidential

• BGP-LS peer relationships can be established using IPv4 or IPv6 addresses. This course uses
IPv6 addresses to establish such relationships.
 SRv6 Policy Path Computation and Deployment
⚫ With the SRv6 Policy path computation algorithm, the controller can provide the following path computation results if specified constraints are met:
 Minimum cost: path with the minimum cost among all qualified paths

 Minimum delay: path with the minimum delay among all qualified paths

 Bandwidth balancing: path with the most remaining bandwidth among all qualified paths that have the same cost

⚫ During SRv6 Policy creation, you need to specify a color value for each SRv6 Policy.

114 Huawei Confidential

• Optional constraints:

▫ Bandwidth constraint: ensures that the bandwidth configured for a service does not
exceed the remaining bandwidth of the link that the service traverses.

▫ PIR constraint: ensures that the peak bandwidth does not exceed the BC0 bandwidth
of the link that the service traverses. PIR refers to the peak bandwidth of a service.

▫ Delay limit constraint: ensures that the path delay of a service does not exceed the
configured delay limit.

▫ Hop limit constraint: ensures that the number of links that a service traverses does
not exceed the configured hop limit.

▫ Affinity constraint: determines which types of links are allowed and which types of
links are not allowed for services.
BGP IPv6 SR Policy Deployment
⚫ BGP IPv6 SR Policy is mainly used to deliver SRv6 tunnel information. As such, iMaster NCE-IP needs to establish a BGP IPv6 SR
Policy peer relationship with the ingress of the involved tunnel.

⚫ BGP IPv6 SR Policy deployment solutions:

iMaster NCE-IP
iMaster NCE-IP

BGP IPv6 SR Policy

PE1 RR PE2
PE1 P1 PE2

CE1 CE2
CE1 CE2

⚫ Solution 2: Establish BGP IPv6 SR Policy peer relationships

⚫ Solution 1: Establish BGP IPv6 SR Policy peer relationships between iMaster NCE-IP and RRs and between the RRs and other
between iMaster NCE-IP and all PEs. devices.
⚫ Solution 2 is recommended to reduce the number of BGP peers
maintained by iMaster NCE-IP.

115 Huawei Confidential

 BGP IPv6 SR Policy Peer Relationship Establishment

BGP IPv6
2000::102 FC01::5
SR Policy

[P1]display bgp sr-policy ipv6 peer

[P1]bgp 65001
BGP local router ID : 1.0.0.5
[P1-bgp]peer 2000::102 as-number 65001 Local AS number : 65001
[P1-bgp]peer 2000::102 connect-interface LoopBack0 Total number of peers : 7 Peers in established state : 5
[P1-bgp]ipv6-family sr-policy
[P1-bgp-af-ls]peer 2000::102 enable Peer V AS MsgRcvd MsgSent OutQ Up/Down State PrefRcv
2000::102 4 65001 11286 11195 0 0160h44m Established 2

116 Huawei Confidential

• BGP IPv6 SR Policy peer relationships can be established using IPv4 or IPv6 addresses. This
course uses IPv6 addresses to establish such relationships.
VPN Service Forwarding over SRv6 Policies
⚫ The following types of VPNs are available in enterprise network scenarios:
 L2VPN: Customer IP addresses are on the same network segment.
L2VPN L3VPN EVPN
 L3VPN: Customer IP addresses are on different network segments.

 EVPN: Customer IP addresses are either on the same network segment (L2VPN scenario) or
Tunnel policy-based tunnel type
on different network segments (L3VPN scenario).
selection
⚫ A tunnel policy is used by an application module to select tunnels for services. There
are two types of tunnel policies:
SRv6 Policy SRv6 Policy Group
 (Preferred mode) Tunnel type prioritizing policy: recurses services to a tunnel based on the
tunnel type priority and the number of tunnels participating in load balancing.

 Tunnel binding policy: binds a destination address to a tunnel, so that the traffic of VPN A forwarding path is selected among
tunnels of the same type in either of
services referencing the policy and destined for this address will be transmitted over the
the following modes:
tunnel.

⚫ VPN services first select tunnels in the up state based on the tunnel policy, and then
select a forwarding path from qualified tunnels.
Color DSCP

117 Huawei Confidential

 Quiz

1. (Short-answer question) An SRv6 SID has 128 bits. What are the three fields of an SRv6 SID?

2. (Short-answer question) In SIDs corresponding to SRv6 endpoint behaviors, which types of

SIDs are similar to the node segments and adjacency segments in SR-MPLS?

118 Huawei Confidential

1. An SRv6 SID has 128 bits and consists of the Locator, Function, and Arguments fields.

2. End SIDs and End.X SIDs.

 Summary
⚫ This course describes the concept of SRv6 network programming, SRv6 instruction sets (endpoint node behaviors,
source node behaviors, and flavors), SRv6 Policy, and basic SRv6 SID configurations on Huawei NetEngine series
routers.
⚫ Leveraging the programmability of 128-bit IPv6 addresses, SRv6 enriches the network functions expressed by SRv6
instructions. For example, in addition to identifying an instruction that can indicate a forwarding path, a network
function can identify a VAS (e.g. firewall, application acceleration gateway, user gateway). To deploy a new network
function, you only need to define a new instruction, without the need to change the protocol mechanism or
deployment.
⚫ SRv6 Policy information is carried by extending new NLRIs based on MP-BGP. The controller establishes BGP IPv6 SR
Policy peer relationships with forwarders to deliver SRv6 Policies to them.

119 Huawei Confidential

 More Information

⚫ SRv6 Network Programming: Ushering in a New Era of IP Networks

⚫ https://datatracker.ietf.org/doc/rfc8754/
⚫ https://datatracker.ietf.org/doc/rfc8986/

120 Huawei Confidential

Thank you. 把数字世界带入每个人、每个家庭、
每个组织，构建万物互联的智能世界。
Bring digital to every person, home, and
organization for a fully connected,
intelligent world.

Copyright©2021 Huawei Technologies Co., Ltd.

All Rights Reserved.

The information in this document may contain predictive

statements including, without limitation, statements regarding
the future financial and operating results, future product
portfolio, new technology, etc. There are a number of factors that
could cause actual results and developments to differ materially
from those expressed or implied in the predictive statements.
Therefore, such information is provided for reference purpose
only and constitutes neither an offer nor an acceptance. Huawei
may change the information at any time without notice.
• This course is based on Huawei's CloudWAN solution.
• The bearer WAN mentioned in this course mainly refers to the IP bearer WAN.
• Multi-network convergence:

▫ The bearer network uses one physical network to carry production, office,
and other services. Powerful BGP routing policies are used to control traffic
on the bearer network. Traffic diversion policies are deployed based on
service attributes so that different types of services, such as production and
office services, can run on different paths based on the customized policies.

• Flexible multi-service bearer:

▫ As multiple services are migrated to the cloud and multiple networks are
converged, issues such as low network resource utilization and unbalanced
traffic distribution become more prominent. The segment routing
technology can be used to flexibly plan paths to carry traffic, improving
network utilization.

• High reliability:

▫ Reliability is classified into network reliability and service reliability.

▫ Network reliability is ensured from aspects such as network architecture and

network stability.

▫ Service reliability is mainly ensured by optimizing network bandwidth, delay,

and packet loss rate based on service requirements.
• Multi-service isolation:

▫ Due to the convergence of multiple networks, the originally physically

isolated production and office networks are now carried on the same
network. The service isolation requirements of some enterprises can be met
using the VPN technology. However, for other enterprises, services need to
be isolated using hard pipes.

• Network resource and traffic path planning:

▫ To make full use of network resources (mainly bandwidth), network traffic

needs to be planned. Traditional traffic engineering (mainly MPLS-TE) has
many disadvantages, such as complex configuration and flawed path
computation mechanism. Therefore, it cannot effectively solve the problem
in multi-service bearing.

• Fast network convergence and service SLA assurance:

▫ Traditional networks usually use FRR to shorten the convergence time.

However, FRR based on the LFA or RLFA algorithm has restrictions in
application scenarios and may fail to meet the high reliability of some
networks.
• TI-LFA: Topology-Independent Loop-free Alternate

• BNG: broadband network gateway

• TTM: time to market

• Based on the cloud platform, iMaster NCE-IP provides three logical modules
(Manager, Controller, and Analyzer) and various scenario-specific applications to
achieve flexible modular deployment based on customer requirements.
• Huawei has all-scenario SRv6 product capabilities and can provide access, metro,
and backbone network routers for carriers and enterprises.
• BGP-LS is a new method of collecting network topology information, which
makes topology information collection simpler and more efficient. Using BGP-LS
to report topology information has the following advantages:

▫ Requirements on the computing capability of the upper-layer controller are

lowered, and there is no requirement on the IGP capability of the controller.

▫ BGP summarizes the topology information of each process or AS and

directly sends the complete topology information to the controller,
facilitating path selection and calculation.

▫ All topology information on the network is sent to the controller through

BGP, unifying the protocols for sending topology information.

• BGP SR-Policy delivers data forwarding path information to the headend through
the BGP route. The headend then directs traffic to a specific SR Policy. Segment
lists in SR Policies are used to guide traffic forwarding. A segment list is calculated
based on a series of optimization objectives and constraints, such as delay, affinity,
and SRLG.

• SR Policy is the mainstream SR implementation mode.

• TWAMP is a standard protocol and can be deployed on IP, MPLS, and L3VPN
networks. TWAMP is easy to obtain and deploy and does not require clock
synchronization.

• iFIT measures the packet loss rate and delay of service packets transmitted on an
IP network to determine network performance. It is easy to deploy and provides
an accurate assessment of network performance.
• Channelized sub-interfaces provide a mechanism to isolate different types of
services. Different types of service traffic can be forwarded to different VLAN
channelized sub-interfaces that use different dot1q encapsulation modes. Each
channelized sub-interface can implement independent HQoS scheduling to isolate
different types of services.

• FlexE is an Ethernet-based bearer technology for multi-rate sub-interfaces on

multiple PHY links. FlexE supports bundling, channelization, and sub-rating.

• SQ: subscriber queue

• GQ: group queue

• VI: virtual interface

• DP: data plane

• TM: traffic manager

• PIC: physical interface card

• The service volume involves two aspects. The first is the service flow direction,
that is, where the services concentrate. The second is the service volume size. The
two aspects are complementary to each other. Generally, a greater concentration
indicates a larger service volume. The core nodes must be nodes where services
concentrate and the service volume is large.

• Core nodes in the same city are interconnected through WDM, and core nodes in
different cities are interconnected through inter-provincial or inter-metro carrier
private lines. The number of core nodes must be comprehensively considered and
cannot be too large.
• Uniformity: All IP addresses on the entire network are planned in a unified
manner, including service addresses, platform addresses, and network addresses.

• Uniqueness: Each address is unique throughout the entire network.

• Hierarchy: The massive IPv6 address space poses higher requirements on the
route summarization capability. The primary task of IPv6 address planning is to
reduce network address fragments, enhance the route summarization capability,
and improve the network routing efficiency.

• Security: Services with shared attributes have the same security requirements.
Mutual access between services needs to be controlled. Services with shared
attributes are allocated with addresses in the same address space, which
facilitates security design and policy management.

• Contiguity: IPv6 addresses in an IPv6 address segment must be contiguous to

prevent address wastes.

• Scalability: IP addresses must be planned and allocated based on network

development requirements to reserve space for future capacity expansion. The
addition of a small number of subnets does not require large-scale architecture or
policy adjustment.
• The locator is an IPv6 network segment. All IPv6 addresses in this network
segment can be allocated as SRv6 SIDs. After a locator is configured for a node,
the system generates a locator route. The node can be located based on the
locator route. In addition, all SIDs advertised by the node can reach the node
through the locator route.

• The Function field is also called opcode, which can be dynamically allocated using
an IGP or statically configured using the opcode command. When configuring a
locator, you can use the static static-length parameter to specify the length of
the static segment, which determines the number of static opcodes that can be
configured in the locator. When an IGP dynamically allocates opcodes, it applies
for opcodes outside of the static segment range to ensure that SRv6 SIDs do not
conflict.

• The Args field is determined by the args args-length parameter. The Args field is
optional in SRv6 SIDs and is determined by the command configuration.
• End.DT SIDs can be classified into End.DT4 SIDs and End.DT6 SIDs.

▫ An End.DT4 SID (PE endpoint SID) identifies an IPv4 VPN instance on a

network.

▫ An End.DT6 SID (PE endpoint SID) identifies an IPv6 VPN instance on a

network.

• In SRv6, End.OP SIDs are used to implement operation, administration and

maintenance (OAM).

▫ End.OP SIDs are mainly used in ping/tracert scenarios.

• It is recommended that some IGP parameters be set as follows:

▫ IGP process ID: It is recommended that the IS-IS or OSPF process ID of a

device on the backbone network be the same as the BGP AS number.

▫ IS-IS NET: The recommended format is aa.bbbb.cccc.dddd.00. The loopback0

address of the device is used for NET derivation. For example, if the
loopback0 address is 21.231.232.1, then the derived NET is
21.0231.0232.0001.00.

▫ OSPF router ID: The global router ID is used. Generally, the router ID is the
same as the loopback0 address.

▫ Interface type: To speed up convergence, all interfaces are of the P2P type.

▫ Route advertisement: IGP is mainly used to ensure the reachability of

internal addresses on the WAN. Therefore, IGP advertises only
interconnection interface addresses and device management addresses.
• In BGP peer relationship establishment, IBGP peer relationships are established
using Loopback0 addresses, and EBGP peer relationships are established using
interface addresses.

• AS: The bearer WAN can be classified as an independent AS.

• IBGP: PEs use loopback addresses to establish IBGP peer relationships with all RRs
and use MP-IBGP to exchange VPN routes.

• EBGP: PEs use interface IP addresses to establish EBGP peer relationships with CEs.
In inter-AS VPN route exchange scenarios, Option A is generally used.

• BGP-LS: The controller establishes BGP-LS peer relationships with all RRs to
collect logical topology information on the backbone network.

• Deploy independent RRs and establish IBGP peer relationships for RRs on the
backbone network.

• In addition to EBGP, IGPs such as OSPF, IS-IS, and RIP can also be used between
PEs and CEs on the bearer network. Static routes can also be used to meet the
requirements of flexible access in various scenarios.
• PE3 changes the MED value to 100 for the route whose next hop is PE1 (a PE on
the same plane) and changes the MED value to 200 for the route whose next hop
is PE2 (a PE on a different plane).

• PE4 changes the MED value to 100 for the route whose next hop is PE2 (a PE on
the same plane) and changes the MED value to 200 for the route whose next hop
is PE1 (a PE on a different plane).

• If PE1 and PE2 on the left learn the same VPN route and advertise the route to
PE3 and PE4 on the right through the RR, PE3 and PE4 preferentially select the
VPN route on the same plane as them. After the route is advertised to the CE,
traffic from the CE preferentially travels along the route advertised by PE3
(because the MED value of the route advertised by PE3 is only increased by 10).
• MPLS is a tunneling technology that guides data forwarding in essence and has
complete tunnel creation, management, and maintenance mechanisms. The
preceding mechanisms are driven by network operation and management
requirements, not by applications.
• The process of forwarding VPN traffic based on SR-MPLS BE is similar to the
process of forwarding BGP/MPLS IP VPN traffic based on LDP.

▫ After PE1 receives a VPN packet from CE1, PE1 searches the routing table
and pushes two layers of labels into the packet. The outer label is a public
network label, and the inner label is a private network label.

▫ PE1 then sends the packet to P1, which swaps the outer label of the packet
based on the SR-MPLS BE tunnel entry and sends the packet to P2. The
process on P2 is similar to that on P1.

▫ Upon receipt of the packet, PE2 sends the packet to a specific VPN site
based on the inner label (PHP is not considered in this case).

• When an SR-MPLS Policy is used to carry VPN traffic, the forwarding path must
be pre-computed and delivered to the ingress (PE1) as a segment list.

▫ After receiving a VPN packet from CE1, PE1 searches the corresponding
table and pushes the related segment list into the packet.

▫ PE1 then sends the packet to P1, which determines the forwarding path
based on the outer label, pops out the outer label, and sends the packet to
P2.

▫ After receiving the packet, P2 determines the forwarding path based on the
outer label, pops out the outer label, and sends the packet to PE2.

▫ PE2 sends the packet to the specified VPN site according to the inner label.
• When SRv6 BE is used to carry VPN traffic, data packets carry two layers of IPv6
headers. The outer IPv6 header address is used to identify the VPN to which the
data belongs, and the inner IPv6 header identifies the actual destination address
of the data.

▫ The outer IPv6 address is generated by the locator of PE2 and advertised to
PE1 through BGP. PE2 advertises the locator to other devices in the form of
a route.

▫ After PE1 receives a packet destined for the destination network segment
(2001:: 64), PE1 encapsulates the packet with an outer IPv6 header and
forwards the packet based on the routing table.

▫ Ps (P1 and P2) forward the packet based on the outer IPv6 header.

▫ After receiving the packet, PE2 matches the packet with the corresponding
VPN instance based on the outer IPv6 header and forwards the packet
based on the routing table.

• When SRv6 Policy is used to carry VPN traffic, data packets carry two layers of
IPv6 headers. The outer IPv6 header address is replaced by each hop based on the
SRH information, and the inner IPv6 header identifies the actual destination
address of the data.

▫ Upon receipt of a packet destined for 2001:: 64, PE1 adds an outer IPv6
header (including the SRH) to the packet and sends the packet to the next
hop based on the header.
• SR-MPLS BE tunnels are similar to LDP tunnels. Tunnel establishment depends on
IGP design. Therefore, after IGP design is complete, SR-MPLS BE design is
complete.

• This section mainly focuses on SR-MPLS Policy design.

• End-to-end deployment has the following characteristics:

▫ Strong path control can be implemented through the planning of end-to-

end paths (especially explicit paths).

▫ Path visualization is relatively good.

▫ If the network is large (for example, a network with multiple data centers
and dozens of branches) and has 5,000 to 10,000 TE tunnels, the
maintenance workload is heavy.

▫ The scalability is fair. If a new data center or branch is added, a large

number of end-to-end tunnels need to be added.
• If iFIT is used to measure the network delay, 1588v2 must be enabled on the
entire network. Therefore, there are restrictions on application scenarios.

• TWAMP requires only NTP in network delay measurement.

• For a tunnel planned based on bandwidth, the actual traffic volume of the tunnel
cannot be limited on devices after the tunnel is delivered. The traffic volume of a
tunnel needs to be limited on the ingress, and the QoS or network slicing
technology needs to be used.
• In color-based traffic diversion, different tunnels (including primary and backup
tunnels) can only be selected based on endpoints. If different service traffic (such
as HTTP and FTP traffic) is destined for the same address, color-based traffic
diversion diverts the traffic to the same tunnel. As a result, the quality of some
services deteriorates.

• In DSCP-based traffic diversion, different tunnels can be selected based on

endpoint + DSCP information. If different service traffic (such as HTTP and FTP
traffic) is destined for the same address, DSCP-based traffic diversion will steer
different services into different tunnels based on the configuration, thereby
ensuring the service quality.
• An SR-MPLS Policy can have multiple candidate paths, such as CP1 and CP2. Each
path is uniquely identified by a 3-tuple <protocol, origin, discriminator>.

• CP1 is the activated path because it is valid and has a higher priority. The two SID
lists (also called segment lists) of CP1 are delivered to the forwarder, and traffic is
balanced between the two tunnel paths based on weight. For example, traffic
along the SID list <SID11, SID12> is balanced based on W1/(W1+W2). In the
current mainstream implementation, a candidate path has only one segment list.

• If a controller is used to generate SR-MPLS Policies, only primary and backup

tunnels can be established, and load balancing cannot be implemented for the
primary tunnel.
• Similar to LDP tunnels, SRv6 BE tunnels are calculated based on IGP/BGP optimal
paths. Unlike label-featured MPLS, SRv6 BE uses the shortest path first (SPF)
algorithm to calculate forwarding paths based on SRv6 SIDs in an IGP domain.
SRv6 BE requires only one segment to identify a forwarding path and the carried
services. Traffic forwarding along paths depends on cost planning. Traffic is
forwarded based on the least-cost route.

• This section describes SRv6 TE Policy design.

• If iFIT is used to measure the network delay, 1588v2 must be enabled on the
entire network. Therefore, there are restrictions on application scenarios.

• TWAMP requires only NTP in network delay measurement.

• For a tunnel planned based on bandwidth, the actual traffic volume of the tunnel
cannot be limited on devices after the tunnel is delivered. The traffic volume of a
tunnel needs to be limited on the ingress, and the QoS or network slicing
technology needs to be used.
• RPO: recovery point objective

• RTO: recovery time objective

• During the operation of the DR system, NCE monitors the association status of
the primary and secondary sites over the heartbeat link and synchronizes data
over the replication link. If the heartbeat or replication link between the primary
and secondary sites is abnormal, the controller reports an alarm. The fault can be
either manually rectified or automatically processed by the arbitration service.

• The DRMgr service is developed by Huawei. Customers do not need to purchase

third-party HA management software.
• Currently, the active/standby switchover of iMaster NCE-IP can be completed
within 10 minutes. Therefore, the GR time cannot be less than 20 minutes.

• GR: graceful restart

• NSR: non-stop routing
• The transit network may fail to meet service requirements due to insufficient
bandwidth or long delay. To detect the network bandwidth or delay, network
quality detection technologies such as TWAMP or iFIT need to be deployed.
• Automatic optimization:

▫ Scheduled optimization: You can set the interval for automatically

optimizing network paths to 5 minutes or longer to ensure that the current
service paths are optimal.

▫ Automatic optimization upon bandwidth threshold crossing: You can set the
link threshold. Then, when the bandwidth usage of a link exceeds the
threshold, the system automatically adds tunnels over the link to the path
computation queue and performs optimization when the optimization
period arrives.

▫ Maintenance window-triggered optimization: You can maintain a node or

link. During the maintenance, the node or link is unavailable. After the
maintenance starts or ends, the controller automatically recomputes the
paths of tunnels that pass through the node or link.

▫ The automatic optimization interval is an integer multiple of 5 minutes, for

example, 10 minutes or 15 minutes.

• Optimization policy:

▫ Traffic-based optimization: In this mode, the link threshold must be set. If

the bandwidth usage of links exceeds the threshold, the controller
determines whether to perform local or global optimization based on the
number of threshold-crossing links.
1. ABCD
• After more than 40 years of development, IP networks have actually gone
through three eras.

▫ The first era is the Internet era. The iconic technology of this era is best-
effort forwarding represented by IPv4.

▫ The second era is the all-IP era. The core technology of this era is MPLS,
which supports applications such as TE and E2E VPN.

▫ Currently, we are experiencing the intelligence era of Internet of Everything,

and the core technology of this era is IPE. This era is featured by the shift
from human-to-human and human-to-machine communication to the
Internet of Everything. There are huge bandwidth demands, large numbers
of connections, and flexible connection models. The requirements for
Service Level Agreement (SLA) assurance extend from providing only
connectivity to providing comprehensive capabilities (such as strict delay,
jitter, and packet loss guarantee capabilities), and O&M complexity
increases accordingly. As a result, a new technology is required to empower
this era, and the heavy responsibility of leading networks into the IPE era
falls onto the SRv6 technology family.
• IPE technologies are innovations to the network technology system, represented
by Segment Routing over IPv6 (SRv6), network slicing (FlexE), deterministic
network (DetNet), in-band flow measurement (iFIT), new multicast (BIERv6), and
application-aware IPv6 networking (APN6), and more.

• The IPE technology system is classified into the following three categories:

▫ The first category provides basic connectivity and is represented by SRv6

(used to carry unicast services) and BIERv6 (used to carry multicast
services). Both protocols carry and forward traffic based on the native IPv6
architecture, which eliminates the need of MPLS on the control and
forwarding planes and takes advantage of IPv6's inherent scalability and
other benefits.

▫ The second category provides experience assurance and is represented by

technologies used to reserve network resources, deliver slice-based
deterministic network capabilities, and provide in-band flow measurement.

▫ The third category comprises APN6 and SFC. APN6 provides application-
level network service capabilities from the application perspective, and SFC
provides flexible programming of network capabilities.

• FlexE: Flexible Ethernet

• DetNet: Deterministic Networking

• iFIT: in-situ Flow Information Telemetry

• BIERv6: Bit Index Explicit Replication IPv6 Encapsulation

• APN6: Application-aware IPv6 Networking

• Phase 1:
▫ SRv6 is used to simplify protocols, resolve the low efficiency problem caused
by segment-based configuration and manual cross-domain configuration
on traditional MPLS networks, and achieve fast E2E service provisioning
across domains.
▫ In addition, SRv6 Policies can quickly adjust and optimize paths, improving
network-wide flexibility and laying a foundation for autonomous networks.
• Phase 2:
▫ Network slicing and FlexE are introduced to provide deterministic
forwarding and differentiated dedicated network experience. Layer 2 FlexE
and Layer 3 network slicing provide dedicated network resources for
different services, E2E service isolation, and manageable and controllable
paths. In this way, different services can be transmitted on the same
network. Abundant slices ensure that each service can enjoy dedicated
network experience and deterministic forwarding with controllable delay
and jitter.
▫ Moreover, the in-band flow measurement mechanism reports service traffic
status in real time, enabling network experience visualization. This allows us
to determine whether service quality deteriorates in a timely manner. If
service quality deteriorates, we can adjust service configurations in a timely
manner to ensure optimal user experience.
• Phase 3:
▫ In this phase, we not only need to ensure service experience, but also need
to deliver experience assurance at a finer granularity (application level).
▫ IPv6 apps can directly carry application information in IPv6 extension
headers, enabling the network to identify user and application information
and provide fine-grained differentiated network channels.
• This figure shows a typical SRv6 deployment case. A carrier provides network
security services for customers. To prevent DDoS attacks, the traffic to the DC
needs to be cleaned by the DDoS cleaning center first. Such traffic traverses the
backbone network.

▫ The carrier has two backbone networks. Network A has high bandwidth but
does not have the VPN service capability. As a result, cleaned traffic may be
sent back to the cleaning center if network A is used.

▫ Network B has the VPN service capability but does not have high
bandwidth. It is unable to support the cleaning of all service traffic.

▫ The volume of to-be-cleaned traffic is large. If such traffic is diverted

through network A (without VPN isolation), cleaned traffic may be diverted
back to the cleaning center, causing a loop. If such traffic is diverted
through network B, the bandwidth resources of network B become a
bottleneck as the service scale expands.

• In this situation, SRv6 can be deployed on network A to direct traffic to this high-
bandwidth backbone network. This implementation can provide protection for
hundreds of DCs. SRv6 is easy to deploy and supports fast service provisioning.
• Currently, large numbers of enterprises are deploying their services on the cloud.
Carriers must consider how to quickly provision site-to-cloud private lines for
enterprises.

▫ Traditional private lines, such as MPLS private lines, may involve multiple
ASs. Different ASs are managed and maintained by different management
teams. The provisioning of a private line for one-hop cloud access involves
collaboration and coordination among multiple departments.

▫ With SRv6, the deployment is easy. An E2E SRv6 logical private line can be
established between the enterprise CPE and cloud PE to carry cloud-based
services, achieving one-hop cloud access. Moreover, private line provisioning
is very fast in this case.

• As shown in the figure, carriers want to build a cloud backbone network to

enhance their market competitiveness in the cloud era by delivering one-hop
cloud access and cloud-network convergence capabilities to enterprises.
• As shown in the figure, the backbone network of a carrier is a native IP network,
which provides best-effort IP forwarding for services. The carrier's DC provides
cloud services for users, and some of these services are delay-sensitive. The
current network does not differentiate delay-sensitive services from common
services during service transmission, resulting in poor user experience of delay-
sensitive services. Moreover, because services are forwarded along least-cost
paths, network loads are uneven, and network management and maintenance
are complex. Against this backdrop, the carrier wants to provide differentiated
services for customers and increase revenue by improving the user experience of
delay-sensitive services.

• The iMaster NCE + SRv6 solution measures the delay of each link on the network
and computes paths based on the shortest delay. This solution allows public
cloud-based services to travel along the shortest-delay paths, improving the
competitiveness of the public cloud.
• WAMS: Wide Area Measurement System
• One WAN for all services is a technology that provides cross-domain network
services through coordination among different networks. In the financial industry,
tier-2 banks, outlets, subsidiaries, and external organizations access the head
office DC through tier-1 banks, which aggregate service traffic and forward
aggregated traffic to the bank core network.

• The financial industry has high requirements on SLA performance. With the
development of banking services, diversified service types have emerged in
outlets. In addition to traditional production and office services, there are also
security protection, IoT, public cloud, and other services. This poses higher O&M
requirements on the one-financial-WAN-for-all-services scenario. Against this
backdrop, Huawei proposes the iFIT tunnel-level measurement solution.
• BIER overview:
▫ This multicast technology encapsulates a set of destination nodes of
multicast packets in a BitString in the packet header before sending the
packets. With this multicast technology, transit nodes do not need to
establish a multicast distribution tree (MDT) for each multicast flow, or
maintain the states of multicast flows. Instead, the transit nodes replicate
and forward packets according to the BitString in the packet header.
▫ In BIER, each destination node is a network edge node. For example, on a
network with no more than 256 edge nodes, each node needs to be
configured with a unique value ranging from 1 to 256. In this case, the set
of destinations is represented by a 256-bit (32-byte) BitString, and the
position or index of each bit in the BitString indicates an edge node. This
explains the meaning of Bit Index Explicit Replication.
• Advantages of BIER:
▫ Supports large-scale multicast service scenarios and reduces resource
consumption as BIER does not need to establish an MDT for each multicast
flow or maintain the states of multicast flows.
▫ Improves multicast group joining efficiency of multicast users in SDN
network scenarios because requests of the multicast users do not need to
be forwarded along the MDT hop by hop, and instead their requests are
directly sent by leaf nodes to the ingress node. This is more suitable for the
controller on an SDN network to directly deliver the set of destinations to
which multicast packets are to be sent after collecting the set.
• BIERv6 inherits the advantages of BIER and uses IPv6 to program paths,
functions, and objects, facilitating multicast forwarding on SRv6-based networks.
• Bit allocation fundamentals: BIER floods the mapping between bit positions (BFR-
IDs) of nodes and prefixes through IS-IS LSPs (IS-IS for BIER is used as an
example). Devices learn the complete BIFT (BIER neighbor table) through
flooding. The BIFT has the following characteristics:

▫ In the neighbor table, each directly connected neighbor has one entry.

▫ Each entry contains information about the edge nodes that are reachable
to a neighbor.

• BIFT: Bit Index Forwarding Table

• Advantages of BIERv6:

▫ Simplified network protocols:

▪ BIERv6 uses IPv6 addresses to carry Multicast VPN (MVPN) and GTM
services, further simplifying protocols and eliminating the need to
allocate, manage, and maintain MPLS labels.

▪ BIERv6 has high extensibility as it complies with the design concept of

SDN and network programming.

▫ Simplified deployment and O&M:

▪ BIERv6 uses an IPv6 extension header to carry BIER forwarding

instructions, eliminating the need for MPLS label-based forwarding.
IPv6 extensibility facilitates the evolution and addition of new
features.

▪ Because BIERv6 is deployed only on the ingress and egresses, transit

nodes are unaware of multicast service changes. When the network
topology changes, there is no need to withdraw or re-establish
numerous MDTs, thereby greatly simplifying O&M.
• IPTV: Internet Protocol Television

• OLT: Optical Line Termination

• Enterprise services can be classified into Internet services, DMZ services, and
enterprise-built service systems. Internet services and DMZ services depend on
external network applications and user environments and require long-term
coexistence of IPv4 and IPv6 user access. This factor must be considered during
IPv6 reconstruction of enterprise networks.
• DCN:

▫ Based on the service scope, enterprise DC services can be classified into

external services and internal applications.

▪ The front-end servers for external services are generally deployed in

the DMZ of the DC and connect to external user devices through the
Internet egress zone.

▪ Internal applications mainly involve the DC's internal service networks

(such as networks in the WAN egress zone and service zone).

▫ From the perspective of service reconstruction, the DCN can be classified

into the internal application network, DMZ (for external services), Internet
egress, and internal service network during IPv6 evolution and upgrade
planning.

• WAN:

▫ Multiple backhaul solutions are available for interconnection between

enterprise branches, such as enterprise-built WAN, carrier MPLS
L2VPN/L3VPN, and Internet private line.

▫ The IPv6 evolution of enterprise WANs mainly considers the WAN upgrade
policy.
• The overall IPv4-to-IPv6 network migration principle is "DCN first, WAN second,
and campus network reconstruction on-demand".

▫ Phase 1: Deploy dual-stack services in the DC's public service and test zones
and IPv4 single-stack services on the WAN's underlay network and dual-
stack services on the WAN's overlay network, and pilot dual-stack services
on the campus network .

▫ Phase 2: Gradually apply dual-stack to the DC's internal applications and

the campus network's office campus part and apply dual-stack to the
campus network's production campus part.

▫ Phase 3: Comprehensively apply IPv6 single stack to the DC's internal

applications and ensure that the WAN gradually evolves to IPv6-only
networks.
• DCN:

▫ The reconstruction solutions for the Internet access zone include NAT64, IVI,
and dual-stack reconstruction. It is recommended to use the dual-stack
solution to provide IPv6 addresses and service capabilities.

▪ NAT64 is limited by session table specifications and consumes a lot of

resources. With the increase of IPv6 terminals, NAT64 will become a
performance bottleneck for IPv6 service development. Therefore,
NAT64 is applicable only to the early deployment of IPv6 services and
is not recommended to be a target solution.

▪ The IPv6 address structure of the IVI is limited and does not meet the
IPv6 address planning principles. Therefore, the IVI is not
recommended for large-scale deployment.

▫ Internal network resource pool reconstruction mainly uses dual-stack

solutions, including VXLAN underlay IPv4 + overlay dual stack and VXLAN
underlay IPv6 + overlay dual stack.

▪ VXLAN underlay IPv4 + overlay dual stack can be used for initial dual-
stack reconstruction to quickly provide IPv6 service bearer capabilities.

▪ VXLAN underlay IPv6 + overlay dual stack can be used for new DCN
deployment and existing DCN reconstruction. This facilitates gradual
evolution to IPv6-only networks.
• DCN architecture:

▫ The underlay network refers to the physical network or infrastructure

network. It is required that any two nodes on the physical network be
routable to each other. The spine-leaf architecture is recommended for
underlay networking.

▪ A spine node is a core node on a VXLAN fabric network, which

provides high-speed IP forwarding and connects to leaf nodes using
high-speed interfaces.

▪ A leaf node is an access node on a VXLAN fabric network, which

connects various network devices to the VXLAN network. Different
access objects are classified into border leaf nodes, server leaf nodes,
and service leaf nodes.

▫ The overlay network is a virtualized network built on the underlay network

to carry applications over the physical network while remaining isolated
from other service networks.
• Internet zone evolution strategies:
▫ Solution 1: Deploy NAT64 at the egress of the Internet access zone. If
existing DC services remain in IPv4 single-stack mode but IPv6 services need
to be quickly provided due to other factors, NAT64 can be deployed for IPv4
servers in the DC's DMZ to temporarily provide IPv4/IPv6 dual-stack services
through the NAT64 gateway.
▫ Solution 2: Perform dual-stack reconstruction in the Internet access zone
and DMZ. If the Internet zone (including the DMZ) supports IPv6 well and
devices are far from reaching the end of their lifecycle, it is recommended
that these devices be reused. You can deploy the dual-stack solution in the
existing Internet access zone and DMZ to complete the reconstruction at a
low cost.
▫ Solution 3: Deploy a new Internet access zone and DMZ. Reusing existing
devices during IPv6 network reconstruction may involve software and
hardware upgrades or partial hardware replacement, which affects IPv4
services. To ensure enterprise DMZ service continuity and zero impact on
live network IPv4 services, deploy an IPv6-only Internet access zone and
DMZ. IPv4 users access the IPv4 DMZ through the IPv4 Internet access zone,
and IPv6 users access the IPv6 DMZ through the IPv6 Internet access zone.
• Egress route selection:
▫ Single-egress Internet access: Static routes are preferred.
▫ Multi-egress Internet access: BGP routes are preferred. To ensure load
balancing and reliability, BGP route attributes can be used to control route
selection.
• Resource pool/server deployment:

▫ A general way to prevent production accidents and service interruption

caused by the upgrade of original IPv4 services is to deploy new IPv6
resource pools/servers.

▫ If the DC is a traditional DC, it is recommended that new technologies, such

as SDN, be deployed in the new resource pools.
• Overall strategy: Deploy IPE single stack to carry both IPv4 and IPv6 services, and
gradually evolve office, production, management, and other services from IPv4 to
IPv6.

• Step 1: Prepare for the evolution.

▫ Address application: Apply for IPv6 addresses based on enterprise

requirements from address management organizations or carriers.

▫ Live network evaluation: Evaluate live network conditions, covering the

network infrastructure, security infrastructure, service support systems, and
service applications.

▫ Integration verification: Design and verify the IPE evolution solution and
prepare a feasibility report.

▫ Network planning: Formulate the IPE network construction specifications

and evolution solution to support smooth evolution to IPv6-only networks.

• Step 2: Construct the network and cut over services.

▫ Network construction: Build an IPE network based on the network plan and
deploy capabilities such as SRv6, network slicing, in-band flow
measurement, and SDN.

▫ Security construction: Security devices must support IPv6 security protection.

Network devices interwork with security devices to ensure that IPv6 has the
same or even stronger security protection capabilities compared with IPv4.
• Overall strategy: Upgrade and replace nodes one by one from the edge to the
core. Gradually deploy IPE features (simple features first, then complex features)
and cut over services (common services first, then critical services).

• Step 1: Prepare for the evolution.

▫ Address application: Apply for IPv6 addresses based on enterprise

requirements from address management organizations or carriers.

▫ Live network evaluation: Evaluate live network conditions, covering the

network infrastructure, security infrastructure, service support systems, and
service applications.

▫ Integration verification: Design and verify the IPE evolution solution and
prepare a feasibility report.

▫ Network planning: Formulate the IPE network construction specifications

and evolution solution to support smooth evolution to IPv6-only networks.

• Step 2: Reconstruct the edge and enable basic IPE capabilities.

▫ Edge device upgrade: Upgrade edge devices (cloud, Internet egress, and
campus egress PEs preferred) to support IPE.

▫ IPE basic capability deployment: Deploy both SRv6 and traditional IP/MPLS
on upgraded devices. Configure new and old devices to interwork through
IP/MPLS, and use SRv6 between new devices. Deploy a controller for
network-wide management and control.
• Overlay service deployment suggestions:

▫ Layer 2 services: Use SRv6 EVPN as the bearer protocol to provide P2P and
P2MP connection models. Compared with traditional Virtual Switching
Instances (VSIs) and Pseudo Wires (PWs), EVPN features simple
deployment, high bandwidth utilization, and fast convergence. EVPN is the
best choice for L2VPN service bearer.

▫ Layer 3 IPv4 services: Use either SRv6 L3VPN or SRv6 EVPN L3VPN. Using
SRv6 EVPN L3VPN is recommended.

▫ Layer 3 IPv6 services: Use either SRv6 L3VPNv6 or SRv6 EVPN L3VPNv6.
Using SRv6 EVPN L3VPNv6 is recommended.
• Loopback routes and SRv6 locator routes need to be advertised in an IGP domain.
Loopback routes are used for network management or BGP peer relationship
establishment. Locator routes are used to guide the forwarding of data traffic
over SRv6 tunnels in an IGP domain.

• BGP Egress Peer Engineering (EPE) is used to allocate SRv6 SIDs to BGP peers
between ASs in inter-AS scenarios.
• Route advertisement:

1. PE2 generates an End SID based on the configured SRv6 locator.

2. PE2 advertises the locator route 2002:1::/64 corresponding to the specified

End SID to PE1 through an IGP. PE1 installs the route to its IPv6 routing
table.

3. A VPN End.DT6 SID 2002:1::D100 within the locator range is configured on

PE2, which then generates Local SID Table.

4. After receiving the VPN IPv6 route advertised by CE2, PE2 converts it into
an EVPN IP prefix route and advertises it to PE1 through the BGP EVPN
peer relationship. The route carries an SRv6 VPN SID — VPN End.DT6 SID
2002:1::D100.

5. After receiving the EVPN route, PE1 leaks it to the IPv6 routing table of the
corresponding VPN instance, converts it into a common IPv6 route, and
advertises it to CE1.
• Campus networks mainly involve large- and medium-sized office campuses,
small-sized branch office campuses, and industrial production campuses. There
are three scenarios for intra-campus mutual access: mutual access between
internal office systems, Internet access, and mutual access between production
systems.

▫ During dual-stack reconstruction for large- and medium-sized office

campus networks, the original IPv4 network architecture and configurations
are retained, and IPv6 configurations and IPv6-related support systems are
added.

▫ In large- and medium-sized virtualized campus scenarios, underlay IPv4 +

overlay VXLAN dual stack can be used to evolve VXLAN to IPv6 based on
live network device capabilities.

▫ When a small office campus network is upgraded to IPv4/IPv6 dual-stack,

services from terminals inside the campus to the enterprise HQ need to be
transmitted through WAN dual-stack channels. Considering the campus
network scale and WAN line leasing solution, we can determine which
option to choose based on live network conditions:

▪ In the scenario where only a single Internet private line is leased for
backhaul, the campus egress generally connects to the intranet over
an IPsec tunnel. One of the following solutions can be used: dual-
stack traffic over IPsec6, dual-stack traffic over IPsec4, and dual-stack
traffic over GRE over IPsec6/4.
• Phase 1 evolution strategy: Perform IPv6 and SDN evolution concurrently to
achieve two objectives at one time.

▫ Overall solution roadmap: Create a core network that supports SDN and
IPv6 network virtualization, and connect the core network to the campus
egress network. Reconstruct the existing network building by building
(aggregation + access) and connect the network to the new core network.
Use the SDN controller for automated deployment in reconstructed
buildings.

▫ Solution advantages: Operations are simple, the deployment pace is

controllable, and the impact on live network services is minimized.
• Large- and medium-sized traditional campus networks generally use Layer 3 IP
forwarding and use Layer 2 VLANs to isolate broadcast domains. If Layer 3
isolation is required, ACLs can be deployed. For external services such as Internet
access and enterprise WAN interconnection, intra-campus support systems
include AAA authentication servers and DHCP servers. During dual-stack
reconstruction for large- and medium-sized traditional campus networks, the
original IPv4 network architecture and configurations are retained, and IPv6
configurations and IPv6-related support systems are added.

• GUA: global unicast address

• The PI address space is a block of IPv6 addresses assigned by a regional Internet

registry to enterprises.
• Interconnection with external networks:

▫ For example, if the campus network IPv6 addresses are PI addresses

independently applied for, static routes can be used for interconnection
with external networks and IGPs can be used to advertise default routes on
the internal network. Carrier networks advertise specific routes to the
campus network, and default egress routes are configured on the campus
network.

▫ If multiple egresses are involved, BGP can be used for interconnection with
external networks and IGPs can be used to advertise default routes on the
internal network. The campus network internally advertises default egress
routes to ensure that internal service packets can reach egress routers. The
egress routers connect to the Internet using BGP to implement optimal
path selection and load balancing.
• Service forwarding:
▫ The overlay IPv6 design is similar to the original overlay IPv4 design. The
underlay configuration from the access layer to the core layer remains
unchanged. The VXLAN control plane uses BGP EVPN, and core switches are
configured as RRs. Enable IPv6 on the centralized gateway and configure an
IPv6 address for the VBDIF interface to ensure Layer 2 IPv6 communication.
▫ Edge nodes on the access side can associate forwarded packets with overlay
BDs based on interface VLANs, enabling terminals to be assigned to
different gateway areas. In VXLAN Layer 3 forwarding, terminal packets are
first advertised to the centralized gateway, and horizontal and vertical
traffic are forwarded by the gateway in a unified manner.
▫ For design details about internal network interconnection and external
network interconnection involved in the network egress zone, see the
traditional campus network solution.
• Access authentication:
▫ Edge nodes on the campus network provide access for dual-stack users.
Single authentication and dual-stack service policy association needs to be
implemented for dual-stack users. This helps prevent dual-stack terminals
from undergoing two separate authentications when accessing IPv4 and
IPv6 services.
▫ A campus network with VXLAN underlay IPv4 + overlay dual stack must
support various authentication modes (such as 802.1x, Portal, and MAC
address authentication) for IPv6 users, so that authentication schemes can
be implemented flexibly based on user terminals (such as Portal
authentication for guest terminals and 802.1x authentication for internal
office terminals). The deployment of network authentication points, policy
enforcement points, and access points in the IPv6 solution is consistent with
that in the original IPv4 solution. The authentication server uses a unified
controller to provide authentication policy services.
• Wireless terminal access solution:

▫ The core switches or AC functions as the gateway for wireless access of

office terminals. The SLAAC hybrid solution can be used to configure IPv6
addresses for terminals, and 802.1x authentication can be used.

▫ Different VLANs are configured for guest SSIDs. The core switches or AC
functions as the gateway for wireless access of guest terminals. The SLAAC
hybrid solution is used to allocate IPv6 addresses. Portal authentication is
recommended.

• AP management solution:

▫ The CAPWAP tunnel supports both IPv4 and IPv6. However, only IPv4 or
IPv6 can be selected at one time. That is, the AC can manage APs only in
either IPv4 or IPv6 mode. The default mode is IPv4.

▫ APs can go online in either IPv4 or IPv6 mode. That is, an AP can obtain
only one IP address. The AC's IP address is manually configured. The AC can
use DHCPv6 or SLAAC to assign IP addresses to APs.

• Note: You can run the capwap ipv6 enable command to enable the IPv6
function for the CAPWAP tunnel.
• NMS IPv6 reconstruction:
▫ The NMS is not user-oriented and requires only a small number of IP
addresses. Therefore, IPv4 addresses can still be reserved for internal
communication, and IPv6 addresses are only optional.
▫ Through reconstruction, the NMS can also provide the following functions:
▪ Identifies and manages various IPv6 address types.
▪ Supports DNS resolution monitoring in IPv6.
▪ Collects performance, resource, and fault data of IPv6 and dual-stack
devices, and provides functions such as performance management,
resource management, and fault management and analysis for these
devices.
▪ Associates IPv4 with IPv6 for dual-stack devices, so that the resource,
performance, and fault data of these devices can be smoothly
associated with historical data.
▪ Accesses the IPv6 MIBs of devices through IPv4-based SNMP and
obtains IPv6 configuration, traffic, and other information from the
IPv6 MIBs.
• IPv6 reconstruction for server operating systems:
▫ Common Linux versions that support IPv6 are as follows (IPv6 installed by
default):
▪ Fedora 13, Red Hat Enterprise Linux 6, Ubuntu 12.04, Oracle Solaris
10, SUSE Linux Enterprise Server 11, etc.
▫ Windows Server supports IPv6 as follows:
▪ Windows Server 2003 supports IPv6, but IPv6 is not installed by
default and needs to be manually installed.
▪ Windows Server 2008 and later versions have IPv6 installed by
default.
1. ABC

2. A
• There are different device management modes, such as SNMP, CLI, IPFIX, and Web UI.
• Orchestration application layer: implements various upper-layer applications of user
intents. Typical orchestration applications include OSS and OpenStack. The OSS is
responsible for service collaboration on the entire network. The OpenStack is used for
network, computing, and storage service collaboration in a data center. There are
other orchestration-layer applications. For example, a user wants to deploy a security
application. The security application does not care about the device deployment
location but invokes a controller NBI, for example, Block (Source IP, DestIP). Then the
controller delivers an instruction to network devices. This instruction varies according
to the southbound protocol.

• Controller layer: The entity at the controller layer is the SDN controller, which is the
core of the SDN network architecture. The control layer is the brain of the SDN system.
Its core function is to implement network service orchestration.

• Device layer: The network devices receive instructions from the controller and forward
the instructions.

• NBIs: NBIs are used by the controller to interconnect with the orchestration application
layer. The main NBIs are RESTful interfaces.

• SBIs: SBIs are protocols used for interaction between the controller and devices,
including NETCONF, SNMP, OpenFlow, and OVSDB.
• Network automation tools implement basic network automation. That is, tools connect
to devices through SSH to implement batch operation and management.
• Unstructured data can be easily understood by humans, but it is difficult for machines
to understand and difficult for automatic data collection.
• iMaster NCE is not only a controller, but also provides analysis and network
management functions.
• Network automation developers may need to have more professional knowledge, such
as database, algorithm, cryptography, software development lifecycle management,
development framework, big data, cloud computing, and artificial intelligence (AI),
depending on the specific work content and scenario.
• Part 1 of this course module describes how to use Python modules, including
paramiko, pysnmp, ncclient, requests, and grpc, to communicate with devices.

• Part 2 focuses on the OPS. The OPS refers to open programmability provided by
Huawei devices. You can upload Python code to a device, and the device runs the code
to implement specified functions.
• An SND abstracts device capabilities based on a device YANG model. A user can
generate an SND based on device YANG files and a few Python code. After the SND is
uploaded to NCE, device management and service provisioning can be implemented.
SND types include NETCONF SNDs, CLI SNDs, and customized SNDs.

▫ NETCONF SND: provides the capability of converting YANG files into NETCONF
files.

▫ CLI SND: provides the conversion capability from YANG to CLI.

▫ Customized SND: provides the capability of converting YANG to other protocols

such as RESTCONF.

• An SSP allows user to customize network services (apps), for example, quickly
provision L3VPN services. These types of services or application involve multiple devices
and protocols and are presented as an SSD. To compile an SSD, an engineer needs to
compile service YANG files, Python scripts (service callback logic) for service mapping,
and Jinja2 template. The basic principles are as follows (from north to south):

▫ A service model automatically generates northbound interfaces or UIs, which are

invoked by an external system to initiate a service request.
• General Purpose Technology (GPT) is the main driving force for economic and social
transformation. From the agricultural society to the industrial society and then to the
information society, the production mode, life mode, and management mode of the
human society have undergone tremendous changes and experienced unprecedented
economic and social transformation. For a long time, people have been thinking and
exploring the drivers of economic and social development and transformation. From
the first technological revolution represented by steam engine to the second
technological revolution represented by electricity technology, looking at the industrial
and technological revolution of the past 300 years, we can see that science and
technology are important sources for promoting sustained economic growth. AI has
become a new general purpose technology. Currently, popular AI technologies are
being implemented, enabling a wide range of industries.

• https://en.wikipedia.org/wiki/General_purpose_technology

• Richard G. Lipsey, etc., Economic Transformations: General Purpose Technologies and

Long-Term Economic Growth.
• Technically, AI case training requires joint development across domains (such as data,
algorithm, and expert experience). Model optimization requires continuous iterative
training, which has the following difficulties:

▫ The success of AI projects requires the cooperation of service experts and AI

experts.

▫ It is difficult for service experts to transform into AI experts.

▫ There are many data issues, such as a few data sources and the requirement for
data governance (labor-intensive).

▫ There are many algorithm engineering issues, such as conversion from paper to
code and the efficiency of open-source algorithms.

▫ The computing power is difficult to obtain. The computing power is used during
peak hours. (Nvida does not allow the use of G series GPUs in data centers.)

• Essentially, AI will bring about organizational transformation, from human resources

to human-machine coexistence in the AI Ops phase.
• The final objective of the experiment is to deploy the trained model in a real
environment. Therefore, it is expected that the trained model can obtain a good
prediction effect on real data. That is, it is expected that a smaller error between a
prediction result of the model and the real result on real data is better. The best
method is to divide real data into a training dataset and a test dataset. We can use the
training dataset to train the model, and then use the error of the test dataset as the
error of the final model in actual scenarios. With the test dataset, to verify the final
effect of the model, we can calculate the error of the trained model only based on the
test dataset. A smaller error indicates a better algorithm model.

• For detailed operations, see the following website:

https://devstar.developer.huaweicloud.com/devstar/code-
templates/e9078ee2d7024ffabbac3f8fd1bad806

• For more information about AI, refer to Huawei AI certification documents.

1. ABC
• Perfect Forward Secrecy (PFS) is a property of secure communication protocols. PFS
was proposed by Christoph G. Gunther in 1990. PFS is essentially defined as the
cryptographic property of a key-establishment protocol in which the compromise of a
session key or long-term private key after a given session does not cause the
compromise of any earlier session. PFS ensures that any future disclosure of passwords
or keys cannot be used to decrypt any communications sessions recorded in the past,
even if the attacker proactively intervenes.

• The SSH transport layer protocol uses the Diffie-Hellman key exchange algorithm to
implement PFS.

• For details, see section 9.3.7 "Forward Secrecy" in RFC 4251

(https://www.ietf.org/rfc/rfc4251.txt).
• A public key is used to decrypt information to ensure message authenticity and
integrity. Therefore, the receiver knows that the information comes from someone
who has a private key. The encrypted information is called a digital signature. The
public key is in the form of a digital certificate.

• When the SSH user authentication protocol is started, it receives a session ID from the
SSH transport layer protocol. The session ID uniquely identifies a session and is a part
of the digital signature to indicate the ownership of the private key.
• A TCP/IP connection can forward network data of other TCP ports through SSH
channels, ensuring security.

• Data of Telnet, SMTP, IMAP, and other TCP/IP-based insecure protocols can be
forwarded through SSH, which prevents the transmission of user names, passwords,
and privacy information in plaintext and therefore enhances security. In addition, if the
firewall restricts the use of some network ports but allows the SSH connection,
communication can be implemented through the SSH TCP/IP connection.

• In X11, X refers to the X protocol, and 11 is the eleventh version of the X protocol. The
Linux graphical user interface (GUI) is based on the X protocol at the bottom layer.
When remote interaction with graphical applications on the Linux server is required, a
method for enhancing communication security is to use SSH to display the GUI on the
local client through the X11 tunnel.

• A session is a remote execution of a program. A program can be a shell, an

application, a system command, or some built-in subsystems. Multiple session channels
can be active at the same time. An interactive login session can be implemented using
the invoke_shell() method, and the remote command can be implemented using the
exec_command() method, which will be described in detail later.
• Port 22 is enabled on the server, waiting for the client to connect. The client initiates a
TCP connection to the server. The two parties complete the handshake and establish a
connection. The client sends a packet to the server. The packet contains the version
field, in the format of Major version number.Secondary version number-Software
version number. After receiving the packet, the server parses it to obtain the protocol
version number. If the protocol version number of the client is earlier than that of the
server and the server supports the earlier version of the client, the server uses the
protocol version number of the client. Otherwise, the server uses its own protocol
version number.
• The algorithm negotiation process is as follows: The server obtains the first algorithm
from the algorithm list of the client and searches its own algorithm list for the same
algorithm. If the same algorithm is found, the negotiation succeeds, and the server
continues to negotiate the algorithm of the next type. Otherwise, the server searches
its own algorithm list for the next algorithm in the client's algorithm list until a match
is found.
• The client and the server first agree on two public prime numbers p and g.

• The client and server each randomly generate a private key Xc and Xs, respectively.

• The client and server each calculate their own public key Yc and Ys, respectively.

• The client and server exchange their own public key.

• The client and server calculate the session key for encryption based on the public and
private keys.

• The Diffie-Hellman key exchange algorithm is used for key exchange, which is based
on the mathematical discrete logarithm and is not described in this course. During key
exchange, the private keys Xc and Xs are not transferred and, due to the difficulty in
computing discrete logarithms, they cannot be decrypted by other users even if p, g,
Yc, and Ys are obtained. This ensures the confidentiality of the session keys.

• Note that the public and private keys generated in this phase are used only to
generate session keys and are irrelevant to subsequent user authentication. After the
key exchange phase is complete, all subsequent packets are encrypted based on the
session keys.
• The digital signature is encrypted by client’s private key. To see the content, we need
public key to decrypt it.
• The channel types include session, x11, forwarded-tcpip, and direct-tcpip.

• For details, see section 4.9.1 "Connection Protocol Channel Types" in RFC4250 at
https://www.ietf.org/rfc/rfc4250.txt.

• Different ssh logical channels can multiplex one ssh session.

• In HCIA courses, we learned how to use the telnetlib module for Telnet remote
connections. In the production environment, the more secure Paramiko module is
recommended for SSH remote connections.
• The Channel class provides methods for executing commands, requesting X11 sessions,
sending data, and opening interactive sessions. Generally, these common methods
from the Channel class have been packaged in the SSHClient class.

• The Message class provides methods for writing bytes to a stream and extracting
bytes.

• The Packetizer class provides methods for checking handshakes and obtaining channel
IDs.

• The Transport class provides methods such as public key authentication, private key
authentication, and channel opening.

• The SSHClient class provides methods for establishing connections and opening
interactive sessions.

• The SFTPClient class provides methods such as file upload and download.
• OpenSSH is a free open-source implementation of the SSH protocol. It provides server
programs and client tools. OpenSSH is integrated in all Linux operating systems.
OpenSSH records the public key of each computer that a user has accessed in
~/.ssh/known_hosts. When the same computer is accessed next time, OpenSSH checks
the public key. If the public keys are different, OpenSSH generates a warning to
prevent man-in-the-middle attacks.
• This course describes methods of four classes: Transport, key handling, SSHClient, and
SFTPClient.

• This process uses the Paramiko SFTP session as an example. Because the SSHClient
class integrates the Transport, Channel, and SFTPClient classes, the preceding methods
can be implemented by the SSHClient class. This is especially true for SSH sessions.
• For ease of use, you can use an address (as a tuple) or a host string as the sock
parameter. The host string is the host name with an optional port, separated by a
colon (:). If a port is transferred, it is converted to a tuple in the format (host name,
port).
• OpenSSH records the public key of each computer that a user has accessed in
~/.ssh/known_hosts. When the same computer is accessed next time, OpenSSH checks
the public key. If the public keys are different, OpenSSH generates a warning to
prevent man-in-the-middle attacks. Generally, when a client connects to the SSH
server for the first time, you need to enter Yes or No for confirmation.
• For details about the commands, refer to the product documentation at
https://support.huawei.com/enterprise/en/doc/EDOC1000097293/466984de?idPath=24
030814|21432787|21430822|22318704|9794900.
• For details about the commands, refer to the product documentation at
https://support.huawei.com/enterprise/en/doc/EDOC1000097293/466984de?idPath=24
030814|21432787|21430822|22318704|9794900.
1. ABCDE
• SNMP is based on UDP and is stateless, unordered, and unreliable for configuration
management.

• SNMP can be configured for only one object, not for one service. During the concurrent
configuration of multiple objects, if some objects are successfully configured but some
objects fail to be configured, unknown impacts will be caused on the network.

• The SNMP interface is difficult to understand.

• For details, see RFC3535.

• Different IETF work groups and drafts gradually meet 14 requirements.

• The IETF gradually implements the conclusions of the IAB meeting. Different work
groups gradually improve the 14 requirements.

• NETCONF 1.0 has no requirements on the model language. The combination between
NETCONF 1.1 and YANG is determined.
• This example is not a real example. The YANG model does not take the entire device
as one YANG file. Instead, the YANG model splits it into multiple YANG files by
function.
• For details, see RFC 6241.
• <config> may contain the optional attribute <operation>, which is used to specify an
operation type for a configuration item. If the <operation> attribute is not carried, the
<merge> operation is performed by default. The <operation> attribute values are as
follows:

▫ merge: In the database, modify the existing data or create data that does not
exist. This is the default operation.

▫ create: Add configuration data to the configuration database only when the
configuration data to be created does not exist in the configuration database. If
the configuration data exists, <rpc-error> is returned, in which the <error-tag>
value is data-exists.

▫ delete: Delete a specified configuration data record from the configuration

database. If the data record exists, the data record is deleted. If the data record
does not exist, <rpc-error> is returned, in which the <error-tag> value is data-
missing.

▫ remove: Delete a specified configuration data record from the configuration

database. If the data exists, the data is deleted. If the data does not exist, a
success message is returned.
• Schema is a language that Huawei extends private syntax based on the W3C XML
standard. Before the NETCONF standard is bound to the YANG model, VRPV8 has
implemented Schema.

• Huawei-YANG has the most abundant content.

• For details, see the NETCONF YANG API Reference released at the official website.
• YANG originates from NETCONF but is not only used for NETCONF. Although the
YANG modeling language is unified, YANG files are not unified.

• YANG files can be classified into three types: vendor-specific YANG files, IETF-defined
YANG files, and OpenConfig YANG files.

• The Config&Status Data, Notification Data, and bottom-layer RPC messages in

NETCONF can be modeled using the YANG model. YANG model files can be converted
into XML/JSON files using a tool and then encapsulated into NETCONF/RESTCONF
messages.

• For details, see RFC 7950.

• For details, see RFC 7950.
• For more information, see RFC 7950.
• For details, see RFC 7950.
• NETCONF and RESTCONF can coexist.

• CRUD: Create, Remove, Update, Delete.

• NETCONF and RESTCONF can coexist.
• A request header may contain multiple fields, such as Accept, Authorization, Host, and
From. For details, see RFC 2916.
• Header information contains details about Response Header and Entity Header. For
details, see sections 6.2 and 7.1 in RFC 2916.
• For details, see 6 Response Status Code in RFC 7231.
1. Huawei uses SSH as the transport layer protocol. Before enabling the NETCONF
function on a device, you need to create an SSH user as the NETCONF user for login.

2. YANG is a modeling language used to describe the content layer of NETCONF and
RESTCONF. The difference between NETCONF and RESTCONF is as follows:
RESTCONF constructs the transport layer, messages layer, and operations layer based
on HTTP, while NETCONF has defined the operations layer and uses SSH as the
transport layer and RPC as the messages layer.
• A microburst refers to a situation in which a large amount of burst data is received
within a very short time (milliseconds), so that the burst data rate is tens or hundreds
times higher than the average rate or even exceeds the port bandwidth. The NMS or
network performance monitoring software calculates the real-time network bandwidth
at an interval of seconds to minutes. At such an interval, the network traffic seems to
be stable. However, packet loss may have occurred due to microbursts.
• SNMP queries are performed in a question-answer manner. If 1000 interactions are
performed within 1 minute, SNMP parses 1000 query request packets. Telemetry
avoids repeated queries. This is because subscription needs to be performed only once
and then devices can continuously push data to the NMS.
• There is also a view in the industry that SNMP is considered as a traditional telemetry
technology, and telemetry is currently referred to as streaming telemetry or model-
driven telemetry.

• Telemetry packs the data to be sent, improving transmission efficiency.

• The collector in the data center collects device performance data through telemetry
and collects device flow mirroring data through ERSPAN.
• For details about the framework, see the corresponding RFC draft at
https://tools.ietf.org/html/draft-song-ntf-02.

• Google Remote Procedure Call (gRPC) is an open-source remote procedure call (RPC)
system developed by Google.

• User Datagram Protocol (UDP) provides a method for an application to send

encapsulated IP packets without establishing a connection.

• Protocol buffers (Protobuf) is a mechanism for serializing structured data.

• A YANG model is similar to a menu for a fast-food restaurant. If a customer wants to
eat a hamburger or fried chicken, the customer writes an A4 paper purchase list with
one hamburger and two fried chickens according to the menu, folds the list into a
stamp-sized note, puts it in the GPB envelope, and gives the envelope to the
messenger gRPC at the door. The gRPC then rides on an HTTP/2 electric motorcycle
and goes to the fast food restaurant. The messenger gRPC gives the GPB envelope to
the restaurant boss, and the restaurant manager opens the envelope to check whether
the items that the customer orders are on the restaurant menu.
• For more information about the YANG model, visit
https://datatracker.ietf.org/doc/rfc7895/.
• gRPC is a RPC system developed by Google.
• GPB transmits data in binary mode with a small number of bytes for each
transmission, and therefore stands out from other encoding methods, such as XML and
JSON, in terms of transmission efficiency. Data collection efficiency is a key concern of
Telemetry.

• For more information, see https://developers.google.com/protocol-buffers/.

• The collector functions as the gRPC client, and the device functions as the gRPC server.

• The collector constructs data in GPB or JSON format based on the subscribed event,
compiles a .proto file through Protocol Buffers, establishes a gRPC channel with the
device, and sends a request message to the device using gRPC.

• After receiving the request, the device parses the .proto file using Protocol Buffers to
restore the data for processing.

• After data sorting is complete, the device re-compiles the data using Protocol Buffers
and sends a response to the collector using gRPC.

• The collector receives the response message. So far, the gRPC interaction ends.
• After the files are compiled successfully, multiple Python files are generated in the
current folder.
• The gRPC module is installed by running the pip install grpc command.

• The huawei_grpc_dialout_pb2_grpc and huawei_telemetry_pb2 modules are generated

after the .proto files are compiled.
1. BC

2. Static subscription and dynamic subscription.

• Traditional network devices are relatively closed and cannot meet flexible and
differentiated network management requirements.
• With the OPS, you can compile scripts based on their requirements and import the
scripts to network devices for running, which is flexible and efficient.
• The VRP system is developed by Huawei based on years of research and network
application experience and its intellectual property rights is owned by Huawei.

• Managed object (MO): an object that can be used to manage network devices by
invoking RESTful APIs, such as CPU information, system information, and interface
information.

• Uniform Resource Identifier (URI): identifies a specific resource. In the OPS, URIs are
used to identify MOs. For example, the URI of the CPU information is
/devm/cpuInfos/cpuInfo, which uniquely identifies the CPU information.

• Uniform resource locator (URL): A URL is a URI that can be used to present a resource
and specify how to locate the resource, for example, http://www.ietf.org/rfc/rfc2396.txt
and ftp://ftp.is.co.za/rfc/rfc1808.txt.

• Huawei network devices that support the OPS provides a running environment for
Python scripts. Scripts in Java and C/C++ languages are not supported.
• An API is a particular set of rules and specifications that are used for communication
between software programs.

• For more information about RESTful, see the HCIP Programming and Automation
Course — RESTful Fundamentals and Practices.
• The OPS allows you to compile Python scripts, install the scripts on network devices,
and send HTTP requests when the scripts are running to manage network devices.
• Currently, the implementation of RESTful APIs uses the HTTP standard specifications.
Therefore, this section briefly describes HTTP.
• <headers> and <entity-body> are the header field and body of the packet on the
previous page.
• Header field:
▫ Host: contains host name and port number of the web server.
▫ User-Agent: contains information about the user agent originating the request.
▫ Accept: specifies response media types that are acceptable.
▫ Accept-Language: indicate the set of natural languages that are preferred in the
response.
▫ Date: represents the date and time at which the message was originated.
▫ Server: contains information about the software used by the origin server to
handle the request.
▫ Last-Modified: last modified date for the requested object.
▫ ETag: specifies an identifier for a specific version of a resource, often a message
digest.
▫ Accept-Ranges: allows a server to indicate that it supports range requests for the
target resource.
▫ Vary: describes what parts of a request message, aside from the method, Host
header field, and request target, might influence the origin server's process for
selecting and representing this response.
▫ Content-Length: indicates length of the response body in octets.
▫ Content-Type: indicates Multipurpose Internet Mail Extensions (MIME) type of
content.
• For details about the header fields, see RFC 2616.
• The formats of the OPS RESTful API request and response packets are similar to those
of the HTTP request and response packets described in the previous slide.

• Extensible Markup Language (XML) is designed to transmit and store data.

• Currently the OPS RESTful APIs use the XML format to transmit data. In a later version,
the APIs can use the JavaScript Object Notation (JSON) format to transmit data.
Therefore, the body of the OPS RESTful API request and response packets is in XML
format.

• You can download RESTful API Reference on the network device page of
http://support.huawei.com.
• The maintenance assistant is a function of Huawei network devices. You can set the
trigger conditions and the Python script to be executed when the conditions are met.
The system monitors device running in real time. When the specified trigger condition
is met, the network device system automatically executes the Python script to
complete the actions defined in the script. For more information about the
maintenance assistant, see the Huawei network device product documentation.
• DHCP server: allocates the temporary IP address, default gateway, and script file server
address to the device to be automatically deployed.

• DHCP relay agent: forwards packets exchanged between the device to be

automatically deployed and the DHCP server when they are located on different
network segments.

• Script file server: stores scripts (Python) required for automatic network device
deployment. By running the script files, a network device can obtain information such
as the IP address of the software and configuration file server, version file, and
configuration file.

• Software and configuration file server: stores system software, configuration files, and
patch files required for automatic network device deployment.
• A Python script can be compiled to deliver commands. When the network is
disconnected, the execution result is temporarily stored on the device. After the
network is recovered, the execution result is transmitted to the server. Therefore, the
impact of network disconnection can be mitigated.
• After knowing the format of the response message, you can parse the response
message in the Python script. In this case, the response message is only displayed. You
can try to parse the response message to implement more complex functions.
• For details about how to enable the FTP server on the local PC, you can easily search
the way from a search engine.
1. ABCD
• The REST software architecture was first mentioned by Roy Fielding in his doctoral
paper. Roy Fielding is one of the major authors of the HTTP specifications.
• OpenFlow was defined in the initial phase of SDN. With technology development,
many other southbound interface (SBI) protocols are defined between the controller
and network devices.
• SDN is a broader concept, not limited to OpenFlow. Separation between the control
and data planes is a method rather than the essence of SDN.
• Application layer: provides various upper-layer applications for service intents, such as
OSS and OpenStack. The OSS is responsible for service orchestration of the entire
network, and OpenStack is used for service orchestration of network, compute, and
storage resources in a DC. There are also other applications at this layer. For example,
a user deploys a security app. This app invokes NBIs of the controller, such as Block
(Source IP，DestIP), regardless of the device locations. Then the controller delivers
different instructions to network devices based on different southbound protocols.

• Control layer: The SDN controller is deployed at this layer and is the core of the SDN
network architecture. The control layer is the brain of the SDN system and implements
network service orchestration.

• Infrastructure layer: A network device receives instructions from the controller and
performs data forwarding.

• NBI: NBIs, mainly RESTful APIs, are used by the controller to interconnect with the
application layer.

• SBI: SBIs are used by the controller to interact with devices through protocols such as
NETCONF, SNMP, OpenFlow, and OVSDB.
• Cloud platform: resource management platform in a cloud DC. The cloud platform
manages network, compute, and storage resources. OpenStack is the most mainstream
open-source cloud platform.

• The Element Management System (EMS) manages one or more telecommunication

network elements (NEs) of a specific type.

• Container-based orchestration: The container-based orchestration tool can also provide

the network service orchestration function. Kubernetes is a mainstream tool.

• MTOSI or CORBA is used to interconnect with the BSS or OSS. Kafka or SFTP can be
used to connect to a big data platform.
• iMaster NCE effectively connects physical networks with business intents and
implements centralized management, control, and analysis of global networks. It
enables resource cloudification, full lifecycle automation, and data analytics-driven
intelligent closed-loop management according to business and service intents and
provides open network APIs for rapid integration with IT systems.

• Huawei iMaster NCE can be used in the enterprise data center network (DCN),
enterprise campus, and enterprise branch interconnection (SD-WAN) scenarios to
make enterprise networks simpler, smarter, open, and secure, accelerating enterprise
service transformation and innovation.
• The operation support system (OSS) is a necessary support platform for telecom
services.

• MTOSI: Multi-Technology Operations System Interface

• Common Object Request Broker Architecture (CORBA) is a standard object-oriented

application program system specification formulated by Object Management Group
(OMG).
• Stateful request: A server generally needs to save and maintain the status information
of previous requests. Each request can use information about the previous requests by
default.

• Stateless request: The processing result on the server must be based on the
information carried in the same request.
• An API is a set of predefined functions or methods for connecting different
components of a software system. It is a set of routines that can be accessed by
applications and developers based on software or hardware without having to access
the source code or understand the details of the internal working mechanism. For
example, if a computer needs to invoke information in a mobile phone, we simply
need to connect the computer and the mobile phone by using a data cable. In this
example, the interfaces on the computer and mobile phone at both ends of the data
cable.
• Rendering refers to the process of transforming views such as HTML into visual images
that can be seen by human eyes.

• For web applications of early days, a view is a graphical user interface (GUI) composed
of HTML elements. For today's web applications, the GUI incorporates new elements
such as Adobe Flash, XHTML, XML/XSL, and WML.

• The Model-View-Controller (MVC) is a pattern for creating web applications and

consists of three parts: controller, model, and view.

▫ The controller is responsible for processing user interaction in an application.

Generally, the controller reads data from the view, controls user input, and sends
data to the model.

▫ The model is responsible for processing the data logic of an application.

Generally, the model stores and reads data from the database.

▫ The view is responsible for processing data display. Generally, a view is created
based on model data.
• An API is a set of predefined functions or methods for connecting different
components of a software system. It is a set of routines that can be accessed by
applications and developers based on software or hardware without having to access
the source code or understand the details of the internal working mechanism.

• Separation between the frontend and backend has become an industry standard for
the Internet projects in the industry. It lays a solid foundation for the large-scale
distributed architecture, elastic computing architecture, microservice architecture, and
multi-terminal services (such as browsers, vehicle-mounted terminals, Android, and
iOS). The key to separation between the frontend and backend is that the frontend
page invokes the RESTful API of the backend for data interaction.
• Abstract of Roy's doctoral dissertation Architectural Styles and the Design of Network-
based Software Architectures:

▫ This dissertation explores a junction on the frontiers of two research disciplines in

computer science: software and networking. Software research has long been
concerned with the categorization of software designs and the development of
design methodologies, but has rarely been able to objectively evaluate the
impact of various design choices on system behavior. Networking research, in
contrast, is focused on the details of generic communication behavior between
systems and improving the performance of particular communication techniques,
often ignoring the fact that changing the interaction style of an application can
have more impact on performance than the communication protocols used for
that interaction. My work is motivated by the desire to understand and evaluate
the architectural design of network-based application software through
principled use of architectural constraints, thereby obtaining the functional,
performance, and social properties desired of an architecture.
• REST is short for Representational State Transfer, in which the main entity — resource
— is not presented.
• A URI represents only a resource entity but not its presentation.
• YANG defines the storage content and configuration of data.
• Relationship between the URI and URL.

▫ The URL is a subset of the URI. The former must be an absolute path, while the
latter can be an absolute path or a relative path. For example,
http://127.0.01:8080/AppName/rest/product/1 is a URL, and
AppName/rest/product/1 is a URI.
• As mentioned earlier, REST makes full use or heavily relies on HTTP. Next, we will
move on to HTTP.
• SPeeDY (SPDY) is a TCP-based application-layer protocol developed by Google. Its
objective is to optimize the performance of HTTP and shorten the loading time of web
pages and improve security by using technologies such as compression, multiplexing,
and priority. The core idea of SPDY is to minimize the number of TCP connections.
SPDY is an enhancement to HTTP, instead of a protocol for replacing HTTP.

• Quick UDP Internet Connection (QUIC) is a UDP-based low-delay Internet transport

layer protocol developed by Google. In November 2016, the IETF convened the first
meeting of the QUIC working group, which attracted wide attention from the industry.
This means that QUIC starts its standardization process and will become a next-
generation transport layer protocol.
• The data transmitted using HTTP can be HTML, images, texts, and so on.
• An HTTP client is usually a browser. A web server can be an Apache server or an
Internet Information Services (IIS) server.

• When a TCP connection is released, if the value of the Connection field in the packet
header is close, the server proactively closes the TCP connection, and the client
passively closes and releases the TCP connection. If the value of Connection is
keepalive, the connection lasts for a period of time and can continue to receive
requests.
• The browser differentiates the displayed content such as HTML, XML, GIF, and flash
based on MIME-type.

• Advantages of the connectionless feature: This mode saves the transmission time and
improves the concurrent performance. No persistent connection is established. Instead,
one response is made to each request. However, if a connection is repeatedly
established and torn down, the efficiency is affected. In HTTP/1.1, a TCP connection is
maintained between the browser and the server for a period of time and will not be
disconnected immediately after a request ends.

• Stateless means that, if the processing of subsequent packets requires the previously
exchanged information, the information must be retransmitted. Although HTTP/1.1 is
a stateless protocol, cookies are introduced to implement the function of maintaining
status information.

• A cookie is a text file stored on a client. This file is associated with a specific web page
and saves the information about the web page accessed by the client.
• HTTP/1.1 has been widely used since it was proposed in 1999 and has become a
mainstream standard for more than 20 years. In the following part, we will introduce
HTTP packets, which are based on HTTP/1.1.
• In HTTP 1.0, each connection involves only one request and response and is closed
after the request is processed. HTTP 1.0 does not have the Host field. In HTTP 1.1,
multiple requests and responses can be transmitted in the same connection, and
multiple requests can be processed concurrently.

• WWW-Authenticate is a simple and effective user identity authentication technology in

the early stage.

• The browser differentiates the displayed content such as HTML, XML, GIF, and flash
based on MIME-type.

• For more information, refer to RFC HTTP 1.1 at https://www.ietf.org/rfc/rfc2616.html.

• The response header describes the basic information about the server and data. The
server uses the response header to notify the client of how to process the data that it
replies to.
• The HTTP response header is often combined with the status code. For example, the
status code 302 (indicating that the location has changed) is usually used together
with the Location header, and the status code 401 (Unauthorized) must be used
together with a WWW-Authenticate header. The response header can be used to set
the cookie, specify the date, instruct the client to refresh the page at the specified
interval, and so on.
• HTTP transmits information in plaintext, which may pose risks of information
interception, tampering, and hijacking. Transport Layer Security (TLS) provides identity
authentication, information encryption, and integrity check functions, and therefore
can prevent such problems.
• For more information, refer to the RFC document at
https://www.ietf.org/rfc/rfc5246.html.
• SPDY is a TCP-based application-layer protocol developed by Google. SPDY aims to
optimize the performance of HTTP and shorten the loading time of web pages and
improve security by using technologies such as compression, multiplexing, and priority.
The core idea of SPDY is to minimize the number of TCP connections. SPDY is an
enhancement to HTTP, instead of a protocol for replacing HTTP.
• Enhancements to HTTP/2:

• Header compression: The HPACK algorithm is used to compress headers to reduce the
header size and improve performance.

• Multiplexing: A request message can be divided into frames, which are sent in
sequence and are reassembled at the other end. In HTTP/1.1, when a client sends
multiple requests through a TCP connection, the server can only respond to the
requests in sequence. Subsequent requests may be blocked.

• Resource pushing: In addition to responding to client requests, the server can push
additional resources to clients.

• Priority: HTTP/2 defines complex priority rules. A browser can request multiple
resources at a time and specify priorities to help the server determine how to process
these resources, avoiding resource competition.
• In this case, two objects are involved in the networking: CloudIDE and iMaster NCE.

• CloudIDE is a cloud-based development environment provided by HUAWEI CLOUD.

The local environment can also be used to write code.

• A sandbox environment is available to iMaster NCE in the datacom developer

community.

• A token is a character string used for authentication on APIs.

• For details, see HCIP-Datacom-Northbound Openness Lab Guide.

• For more operations, see the CodeHub guide at
https://support.huaweicloud.com/codehub/index.html.
• Code in DevCloud on HUAWEI CLOUD: https://devcloud.cn-north-
4.huaweicloud.com/codehub/project/68494a8ad06b4eea9a1c3f18be115161/codehub/6
20653/home
• Website for reserving a sandbox environment:
https://devzone.huawei.com/openecosystem/experienceView/campus.html
• To run the code, right-click setup.py and choose Run Python File in Terminal from the
shortcut menu.
1. B
• iMaster NCE-Campus is Huawei's next-generation autonomous driving network
management and control system for campus networks. It is a network automation and
intelligent platform integrating manager, controller, analyzer, and AI functions. As
such, this platform drives enterprise cloudification and digital transformation, and
creates a shortcut to more automated network management and intelligent network
O&M.
• Application layer: It focuses on mainstream scenarios and provides industry-wide
applications. At this layer, network service data is shared, meeting value-added data
and operation requirements.

• Platform layer: It provides four types of APIs and supports industry-standard network
interconnection protocols.

• Network layer: It provides various open interfaces, such as NETCONF, YANG, and
Telemetry, improving device manageability. APs are compatible with third-party IoT
cards to implement IoT.

• Terminal layer: It supports access of IoT terminals (such as ZigBee, RFID, and BLE), and
access of wired and wireless terminals (such as mobile phones, IP phones, tablets, and
cameras).
• The tenant or MSP wants to use an existing or third-party authentication platform to
authenticate user identities and authorize users for network access authentication
through the web page (authentication portal). For example, an MSP provides a unified
access authentication page for tenants.
• To access the Internet, a user connects to the SSID of a Wi-Fi network and logs in to
the portal pushed by a developer app. The developer app calls the authorization API of
Huawei iMaster NCE-Campus to deliver the user's Wi-Fi access permission to the AP.
The user then can access the Internet.

• NAC is short for network access control.

• Huawei Agile Cloud Authentication (HACA) is based on the mobile Internet protocol
HTTP/2.
• For more information about API-based authentication and authorization, visit
https://devzone.huawei.com/cn/enterprise/campus/apiSolution.html.
• For details about RADIUS-based authentication, visit
https://devzone.huawei.com/cn/enterprise/campus/radiusSolution.html.
• Location-based service (LBS) uses various locating technologies to obtain the current
locations of devices and pushes information and basic service for these devices through
mobile Internet.

• iMaster NCE-Campus aggregates the terminal location data collected by cloud APs and
periodically sends the data to the third-party LBS platform. After parsing and analyzing
the location data with a series of algorithms, the LBS platform provides VASs, such as
heatmap, tracking, and customer flow analysis, for customers.

• Remarks: Partners need to meet related standards based on application scenarios, such
as EU General Data Protection Regulation (GDPR).
• iMaster NCE-Campus can directly report terminal location data to a third-party LBS
platform. In this solution, iMaster NCE-Campus function as a relay agent.

• For details about this process, see "Wi-Fi Terminal Location Practice in Huawei
CloudCampus Solution" in the HCIP-Datacom-NCE Northbound Openness Lab Guide.
• The validator value is in UUID format and is generated by iMaster NCE-Campus.

• For more examples, visit

https://developer.huaweicloud.com/techfield/network.html#CloudCampus.
• For more about the AP location reporting solution, see
https://devzone.huawei.com/cn/enterprise/campus/lbsWiFiSolution.html#Wi-Fi
Terminal Data Reporting Process.
• For more about the Bluetooth API solution, see
https://devzone.huawei.com/cn/enterprise/campus/lbsBluetoothSolution.html.
• For more about VAS APIs, visit
https://devzone.huawei.com/cn/enterprise/campus/valueAddedApi.html.
• For more basic network solutions, visit
https://devzone.huawei.com/cn/enterprise/cloudcampus/quickStart.html#network.
• For more about the smart IoT solution, visit
https://devzone.huawei.com/cn/enterprise/cloudcampus/quickStart.html#iot.
1. ABCD
• First, let's take carriers as an example. Globally, most carriers face the problems of
revenue decrease and OPEX increase. Moreover, as OTT providers continue to preempt
market shares, more and more carriers take OTT providers as their competitors. These
factors drive carriers to transform their networks. In this case, carriers are faced with
the following problems: how to implement multi-network convergence, multi-vendor
collaboration, and fast and efficient management of converged networks.

• In the 5G era, everyone predicts that 5G will lead to new businesses and services.
However, carriers raise requirements for the rollout of new services, and device
vendors implement the requirements. The rollout period is half a year or several years.
It takes only a few months for OTT providers to launch new services, which makes it
impossible for carriers and OTT providers to compete equally. There are many reasons
for slow service rollout. One of the reasons is that there is a gap between carriers and
vendors. That is, carriers do not understand devices, and vendors do not understand
carrier services. It is an urgent issue to eliminate the impact of this gap and enable
carriers and vendors to play their roles in the fields they are familiar with and quickly
provision new services.

• Finally, the products provided by vendors are universal, that is, they are applicable to
most operators. Carriers want systems to match their service requirements and
enterprise cultures. Therefore, they have customization requirements. For example, a
carrier writes the customization capability into its bidding document or customizes
enterprise specifications. From the perspective of vendors, customization requirements
of customers generate high costs. Therefore, the best solution is to provide the
customization capability and let customers complete customization by themselves.
• On traditional networks, network automation refers to the process of generating
command line scripts based on the template mechanism and enabling devices to run
the received command line scripts through the network management protocol. It does
not change the way it interacts with network devices. During device adaptation,
network management engineers use Python or Perl to compile a specific function with
a narrow application scope to implement a series of automatic operations, or use
automation tools such as Ansible and Puppet to implement more complex automation
tasks. Network management engineers need to adapt to network devices to be
supported one by one, regardless of whether they write scripts or use automation tools.
As the script scale becomes larger and larger, script maintainability decreases
continuously, and the time required for adding a new version increases accordingly.
With the advent of the Internet of Everything (IoE) era, the time to market (TTM) of
new services has become a core indicator for enterprises to survive.

• With the great success of the commercialization of cloud computing, the concept of
software-defined networking (SDN, sometimes referred to as “software-driven
network”), which was popular only in the academic circle, has begun to flourish. On an
SDN network, the separation between the control and forwarding planes is highly
recommended. In an ideal SDN network, a centralized controller becomes an
indispensable basis. As the brain of the entire network, it collects information about
the network topology, calculates an optimal path globally based on service
requirements, and notifies devices along the path. When receiving a service packet,
these devices forward the packet according to a path determined by the centralized
controller.
• iMaster NCE is an innovative network cloudification engine developed by Huawei.
Positioned as the brain of future cloud-based networks, NCE integrates functions such
as network management, service control, and network analysis. It is the core
enablement system for network resource pooling, network connection automation, and
O&M automation. NCE aims to build an intent-driven network (IDN) that is first
automated, then self-adapting, and finally autonomous.

• The overall openness and programmability of NCE include automation, analytics, and
intent. The goal is to build a full-lifecycle open and programmable architecture to
satisfy customer needs. The OPS, as a part of the automation engine, are crucial for
the entire open programming system of NCE to form a closed loop. Equivalent to the
limbs of the human body, the OPS is an executor, which needs to be flexible to support
the automatic closed-loop capability driven by the brain of an intent-driven network.
• The open architectures of different industries are similar. Similar to the operating
system on a computer, NCE service openness and programmability are crucial to
networks.

• To connect the operating system to managed hardware, such as the mouse and
keyboard, you need to install corresponding drivers. The drivers enable the operating
system to recognize the hardware. NCE service openness and programmability have
similar functions. The difference is that switches and routers are managed in the
datacom industry. First, we need to understand and manage these switches and
routers. That is, load device drivers first, and then add and understand the specific
capabilities of the devices.

• At the upper layer, the operating system implements hardware management,

specifically, managing the status of the mouse and keyboard. NCE service openness
and programmability implement device management, such as managing device status
and configurations.

• At the top layer, the operating system provides program management to manage
various applications, such as Word and Excel. Note that the mouse and keyboard
capabilities are required for using these programs. NCE service openness and
programmability implement service management at the top layer, that is, building
network service capabilities based on application scenarios. In addition, NCE provides
capabilities such as rollback up on a transaction failure and automatic detection of
device configuration changes to improve O&M.
• NCE service openness and programmability depend on two software packages: SND
and SSP.

▫ Specific NE Driver (SND): provides a data model for the iMaster NCE OPS to
interact with NEs.

▫ Specific Service Plugin (SSP): defines a data model for completing network
service configuration.

• Engineers compile SND packages and load them to iMaster NCE to quickly
interconnect with new devices. Then, engineers compile SSP packages and load them
to iMaster NCE to quickly construct new services.
• NE YANG model: YANG files generated by abstracting atomic capabilities (such as
creating sub-interfaces) at the device layer. They are provided by device vendors.

• Service YANG model: YANG files generated by abstracting service models can be used
to generate northbound interfaces and configuration GUIs.

• Easymap: a mapping logic algorithm that decomposes network-layer services into NE-
layer services.
• The design state is used to establish the mapping between the service YANG model
and NE YANG model. The system provides the mapping logic algorithm to decompose
network-layer services into NE-layer services. Currently, the NCE service openness and
programmability framework supports two layers of mapping logic: 1. Mapping from
the service model to the device model, which is processed by the SSP package. 2.
Mapping from the device model to protocol packets, which is processed by the SND
package.

• The running state uses the mappings established in the design state to manage devices
and provision services. Specifically:

▫ Service management automatically generates a service management GUI based

on the service YANG model to add, delete, modify, and query services.

▫ Device management automatically generates an NE management GUI based on

the NE YANG model to add, delete, modify, and query NE resources, achieving
functions such as difference comparison, data synchronization, and configuration
reconciliation.

▫ API gateway automatically generates northbound RESTCONF interfaces based on

the service and device YANG models and works with the mapping between the
two models to add, delete, modify, and query services and NE resources.

• The running state provides the dryRun function to help users preview the results of the
current operation and the modification of related device configurations.

• Jinja2 is a Python template engine. NCE service openness and programmability use
Jinja2 to quickly complete the template-based processing of SSP packages.
• The development process of NCE service openness and programmability is as follows:

▫ First, analyze requirements based on service scenarios and output the high level
design (HLD). In this phase, analyze the configuration commands to be delivered
and the involved device types, and then start the development of a Specific NE
Driver (SND) package. The SND package is developed as required. If the SND
package of a device exists and the SND package to be delivered is supported, you
do not need to develop the SND package again.

▫ Then, develop a Specific Service Plugin (SSP) package. Step 1: Develop the
southbound Jinja2 template. The southbound Jinja2 template can be considered
as the tailoring of the open interfaces of the device. There are many open
capabilities of devices. However, we only need to use some of them. Therefore,
find and select the required ones. Step 2: Define the service YANG model and
determine northbound input parameters. Step 3: Develop the service logic. This
step is optional. If the service layer can directly map and use the southbound
template, skip this step.

▫ Finally, perform commissioning and verification. After the commissioning and

verification are completed, the use in the production environment is formally
started. If there are incremental requirements, follow the incremental design
process and perform incremental development with reference to the preceding
steps.
• Easymap: a mapping logic algorithm that decomposes network-layer services into NE-
layer services. Currently, the NCE service openness and programmability framework
supports two layers of mapping logic: 1. Mapping from the service model to the device
model, which is processed by the SSP package. 2. Mapping from the device model to
protocol packets, which is processed by the SND package.
• The SND package of the CLI driver is also a YANG file.
• Currently, the NCE service openness and programmability framework supports two
layers of mapping logic: 1. Mapping from the service model to the device model, which
is processed by the SSP package. 2. Mapping from the device model to protocol
packets, which is processed by the SND package.

• For SND package processing, if the device is a NETCONF device, NCE service openness
and programmability automatically convert the model data into NETCONF packets.
• For more information about NETCONF, see NETCONF/YANG Principles and Practices.
• In this example, the service YANG module hbng is customized.

• description describes the functions of the hbng module.

• revision is 2018-04-20, indicating the initial version of the hbng module.

• import and include introduce two modules for subsequent node definition.

• augment "/app:applications" { ... } indicates that the current module hbng is extended
to the /app:applications directory of the app module.
• In this example, a container node named system is created, including the login
container sub-node for recording login information.

• The container sub-node login contains the following:

▫ A leaf node named message, which records the login prompt information.

▫ A leaf-list node named prohibited-users, which records the blacklist of users

who are not allowed to log in to the system.

▫ A list node named user. In the list node, the unique key is defined as name and
its type is character string; level is defined as user level and its type is number.
• In this example, the list interface is defined. config true indicates that the list is
configuration data, and config false in observed-speed indicates that this leaf is status
data.

• The leaf node name is a character string. The leaf node speed provides three options.
type enumeration indicates that the enumerated values are 10m, 100m, and auto.
The leaf node observed-speed is a positive integer of the uint32 type.
• In this example, a group node named ip-port is defined, including two leaf sub-nodes:
ip and port.

• The container quadruple contains the source and destination information containers,
both of which use the IP address and port information. The group node ip-port is
reused.

• The container transfer-protocol is used to indicate the transmission protocol. The UDP
and TCP protocols are provided. Either of them can be selected using the choice
function. case a indicates that the UDP protocol is used, and case b indicates that the
TCP protocol is used.
• In this example, an RPC interface named reset-specified-servers is defined for
resetting services. input indicates that the input parameter is the IP address of the
server to be restarted. If output is not defined, the HTTP status is used to determine
the returned result.

• The servers list node defines action reset to restart the corresponding service. Input
defines the leaf node reset-at, which indicates that the input parameter is the restart
time. Output defines the leaf node complete-at, which indicates that the returned
result is the restart completion time.
• The Jinja2 template is only a text file, which can be based on any text format (HTML,
XML, CSV, etc.). In this example, the XML format is used.

• A template contains variables and expressions. The variables and expressions are
converted to corresponding values when the template is used. It has the following
common syntaxes:

▫ {% ... %} contains Control Structures. In this example, {% for dev in

nesInterfacesCfg.nes %} indicates that the for loop starts, and {% endfor %}
indicates that the loop ends.

▫ {{...}} contains an expression, which can be a constant, variable, mathematical

formula, or logical statement.

▫ {# ... #} indicates the comment.

• The variables in {{...}} can be modified using filters. Filters and variables are separated
by vertical bars (|). For example, {{ 'abc' | capitalize }} indicates that the first letter is
capitalized and the filtering result is Abc. In this example, {{dev.neName | to_ne_id}}:
to_ne_id is a user-defined filter, indicating that the variable device name dev.neName
is converted to the device ID.

• For more information, see the Template Designer Document at

https://jinja.palletsprojects.com/en/2.11.x/.
• NCE uses the Specific NE Driver (SND) package to quickly interconnect and manage
Huawei and third-party devices and open device configuration capabilities. To manage
third-party devices, you need to obtain the YANG file of the device from the vendor's
website. If third-party devices support only command lines and do not support
NETCONF interconnection, Huawei can customize interconnection capabilities.

• Key capabilities:

1. Quickly manage Huawei and third-party devices.

2. Open device configuration capabilities.

3. Automatically generate the configuration GUIs and northbound interfaces of

new devices.
• In this example, the service openness capability is used. Similar to the device atomic
capability openness, the system is developed based on the standard NETCONF protocol.
The internal data model uses the YANG modeling language to automatically generate
configuration GUIs and northbound interfaces based on the YANG model of services. In
addition, the Easymap algorithm is provided for customers to write only the creation
process, and the update and deletion are calculated by comparing algorithms. This
simplifies customer programming.

• The service layer shields differences between devices, supports interconnection with
different device types, and delivers configurations through different protocols. The
maintenance personnel or upper-layer system only needs to view corresponding
services. They do not need to know the specific vendor and protocol of the device. This
feature improves interconnection efficiency and reduces the pressure on maintenance
personnel.

• Key capabilities:

1. Open service capabilities.

2. Shield differences between underlying devices at the service layer.

3. Automatically generate southbound and northbound interfaces based on the

YANG model.
• Devices with the same configuration can be grouped. A preset template can be applied
to the system for batch configuration delivery. Currently, more than 60 templates are
preset in the enterprise DCN for users to apply.
• Before service configurations are delivered, the OPS provides the dryRun function to
check the correctness of delivered configurations in advance. If an error occurs, modify
the dryRun function. After the configurations are correct, commit the configurations
again. The system provides a transaction mechanism to ensure data consistency
between the device and controller. If the data fails to be synchronized, the system
automatically rolls back the data to ensure that no residual data exists. For a service
that is successfully delivered, you can view the delivered configurations of the
associated device. In addition, you can view the delivered configurations in historical
records. You can roll back the configurations based on the rollback point.

• Key capabilities:

1. Use the dryRun function to check whether the delivered configurations are
correct in advance.

2. Provide a transaction mechanism to ensure data consistency between the device

and controller. If a failure occurs, automatic rollback will be performed.

3. Provide the visualized display of service association data and historical

configurations.
1. Specific NE Driver (SND) and Specific Service Plugin (SSP) packages.

2. ACD