HCIP-Datacom-Advanced Routing Switching Technology V1 0 Training Material

Prévia do material em texto

• 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 itselfand 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.
• 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 inboth 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 (").
• 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.
• 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.
1. CD
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 network segments: Net1, Net2, and Net3. R1 
advertises routes to the three network segments 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.
• Quiz:
• Type 1:
▫ ^a.$: matches a character string that starts with the character a and ends withany 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.
• Type 3:
▫ [abcd]: matches any character in the string abcd, for example, ax, b!, abc, d0, 
and so on.
▫ [a-c 1-2]$: matches a character string ending with any of a, b, c, 1, and 2, for 
example, a, a1, 62, xb, 7ac, and so on.
▫ [^act]$: matches a character string that does not end with a, c, or t, for example, 
ax, b!, d, and so on.
▫ [123].[7-9]: matches the character strings such as 1 7, 2x9, and 348.
• 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 match 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-Huaweidevice.
▫ 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 easily obtained by attackers. 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.
• 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
• 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 OSPFv3packets 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).
• 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: uses 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.
• HelloInterval: indicates the interval at which Hello packets are sent. This field occupies 
2 bytes.
• 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.
• Link State ID: indicates a local 32-bit identifier, which is irrelevant to an IPv6 address, 
and occupies 4 bytes. This field, together with the LS Type and Advertising Router 
fields, describes an LSA in the OSPFv3 domain. Compared with OSPFv2, OSPFv3 does 
not contain address information in the Link State ID field.
• 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 thedestination 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.
• 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.
▫ 1: A router-LSA is referenced.
▫ 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.
• 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-TopologyTLV:
▫ 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.
• [ Huawei-GigabitEthernet0/0/1] isis ipv6 cost { cost | maximum } [ level-1 | level-2 ]
▫ cost: specifies the link cost of an IPv6 interface. The value is an integer that varies 
according to the following cost styles:
▪ If the cost style is narrow, narrow-compatible, or compatible, the value 
ranges from 1 to 63.
▪ If the cost style is wide or wide-compatible, the value ranges from 1 to 
16777214.
▪ The default value is 10.
• 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
• Sub-VLANs share one gateway address to reduce the number of subnet addresses, 
subnet default gateway addresses, and directed broadcast IP addresses. The switch 
assigns IP addresses to hosts in sub-VLANs according to the number of hosts. This 
ensures that each sub-VLAN acts as an independent broadcast domain, conserves IP 
addresses, and implements flexible addressing.
• When hosts in different sub-VLANs communicate with each other, the hosts send ARP 
Request packets because IP addresses of the sub-VLANs belong to the same network 
segment. Actually, different sub-VLANs belong to different broadcast domains. As a 
result, ARP packets cannot be transmitted to other sub-VLANs, there is no response to 
ARP Request packets, and the device cannot learn the MAC address of the peer end. As 
a result, sub-VLANs cannot communicate with each other.
• To implement communication between sub-VLANs, enable proxy ARP on the VLANIF 
interface of the super-VLAN.
• An example of Layer 2 communication of a sub-VLAN is as follows:
▫ Packets sent from Host_1 to Switch_1 are tagged with VLAN 10. Although sub-
VLAN 10 belongs to super-VLAN 100, SW1 does not change VLAN 10 to VLAN 100 
in packets.
▫ Packets sent from GE0/0/0 on SW1 are still tagged with VLAN 10. SW1 does not 
send packets from VLAN 100. When another device sends packets from VLAN 100 
to SW1, SW1 discards the packets because there is no physical interface 
corresponding to super-VLAN 100 on SW1.
▫ For other devices, only sub-VLANs 10, 20, and 30 are valid and all packets are 
exchanged in the VLANs. The communication between SW1 configured with VLAN 
aggregation and other devices is similar to normal Layer 2 communication without 
the super-VLAN.
• When a PC in a sub-VLAN needs to communicate with other networks at Layer 3, the 
PC sends data to the default gateway, that is, the VLANIF interface corresponding to 
the super-VLAN, and then routes the data.
• Either the separate VLAN or group VLAN must be bound to a principle VLAN.
• Interfaces in a principal VLAN can communicate with other interfaces in the same MUX 
VLAN.
• The MUX VLAN function must be enabled to implement the following functions: The 
principal VLAN and subordinate VLAN can communicate with each other. Interfaces in 
a group VLAN can communicate with each other. Interfaces in a separate VLAN cannot 
communicate with each other.
• Tag Protocol Identifier (TPID): indicates the frame type. The value 0x8100 indicates an 
802.1Q-tagged frame. A device that does not support 802.1Q discards 802.1Q frames.
• For the inner 802.1Q tag, the value is set to 0x8100. For the outer 802.1Q tag, different 
vendors may use different values.
▫ 0x8100: is used by Huawei routers.
▫ 0x88A8: 802.1ad specifies that the TPID in the outer 802.1Q tag is 0x88a8.
• On a Huawei device, the default value of the outer 802.1Q tag is 0x8100, which can be 
changed using a command.
• The private VLANs of enterprise A and enterprise B are VLANs 1 to 10 and VLANs 1 to 
20, respectively. The public network allocates public VLANs 3 and 4 to enterprise A and 
enterprise B respectively. When tagged packets from enterprises A and B arrive at the 
public network, they are tagged with additional VLAN tags, that is, VLAN 3 for 
enterprise A's packets and VLAN 4 for enterprise B's packets. In this way, packets from 
enterprise networks are separately transmitted on the public network, even though the 
two networks have overlapping VLAN IDs. After packets traverse the public network, 
public VLAN tags of the packets at the receiving PE are removed. Then the packets are 
forwarded to the CE of their respective user network.
• Basic QinQ is implemented based on interfaces. When a packet arrives at an interface 
that has basic QinQ enabled, the device will tag itwith the interface's default VLAN 
tag, regardless of whether the packet is already tagged or untagged. After being 
processed by basic QinQ on an interface, single-tagged packets change into double-
tagged packets, and untagged packets change into single-tagged packets with the 
default VLAN tag of the interface.
• Interface-based QinQ inflexibly encapsulates the outer VLAN tag. The device on which 
interface-based QinQ is enabled cannot change the encapsulation method used for the 
outer VLAN tag based on service types.
• Selective QinQ allows the device to select whether to tag packets, or determine the 
type of outer VLAN tags to be encapsulated, according to the traffic classification 
result. Selective QinQ can classify traffic based on the VLAN tag, priority, MAC address, 
IP protocol, source IP address, destination IP address, or port number of an application 
program.
• VLAN ID-based selective QinQ: adds outer VLAN tags based on inner VLAN IDs.
• 802.1p priority-based selective QinQ: adds outer VLAN tags based on 802.1p priorities 
in inner VLAN tags.
• Traffic policy-based selective QinQ: adds different outer VLAN tags based on QoS
policies so that differentiated services can be provided based on service types.
• Selective QinQ is an extension of basic QinQ and is more flexible. The difference is as 
follows:
▫ Basic QinQ: adds the same outer VLAN tag to all packets arriving at a Layer 2 
interface.
▫ Selective QinQ: adds different outer VLAN tags to packets arriving at a Layer 2 
interface based on inner VLAN tags.
• Broadband Remote Access Server (BRAS): The BRAS aggregates and forwards service 
flows, meeting different user requirements for the transmission rate and broadband 
utilization. Therefore, it is the core device for broadband user access.
• Broadcast, unknown unicast, and multicast (BUM): The switch floods BUM packets.
• Selective QinQ must be configured on the hybrid interface and the qinq vlan-
translation enable command must have been executed to enable VLAN translation. 
Selective QinQ can only take effect on the interface in the inbound direction.
• When an interface configured with VLAN stacking needs to remove the outer tag from 
outgoing frames, the interface must join the VLAN specified by stack-vlan in untagged 
mode. If the outer VLAN does not need to be removed, the interface must join the 
VLAN specified by stack-vlan in tagged mode.
1. A
2. B
• 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.
• display port-isolate group { group-id | all }: displays the configuration of a port 
isolation group.
• clear configuration port-isolate: clears all the interface isolation configurations on 
the device.
• port-isolate exclude vlan: excludes a VLAN where port isolation needs to be disabled.
• 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 andto 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 
VLANview.
• 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.
• Run the display storm-control [ interface interface-type interface-number ] 
command to check the storm control configuration on an interface.
• min-rate min-rate-value
▫ Specify the lower threshold in packet rate limit mode. If the value of min-rate-value
(pps) is specified, packets received by an interface are forwarded when the rate of 
receiving packets is smaller than the value of min-rate-value in the storm detection 
interval.
• min-rate cir min-rate-value-cir
▫ Specify the lower threshold in byte rate limit mode. If the value of min-rate-value-
cir (kbit/s) is specified, packets received by an interface are forwarded when the rate 
of receiving packets is smaller than the value of min-rate-value-cir in the storm 
detection interval.
• min-rate percent min-rate-value-percent
▫ Specify the lower threshold in percentage rate limit mode. If the value of min-rate-
value-percent (percentage) is specified, packets received by an interface are 
forwarded when the rate of receiving packets is lower than the value of min-rate-
value-percent in the storm detection interval.
• No DHCP relay agent is deployed:
▫ 1. 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).
▫ 2. 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. 
▫ 3. 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.
▫ 4. 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
1. ABD
• 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.
▫ OpenRec: In this state, both the active and passive LSRs wait for a KeepAlive 
message from the peer end after they send KeepAlive messages. An LSR sets the 
session state to Operational state after receiving a KeepAlive message, but sets the 
session state to Non-Existent if a non-KeepAlive message is received or the 
KeepAlive message times out.
• 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 RFC 5036.
• 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 triggerpolicy 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 canbe 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.
• RFC 2547 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.
• For more information about inter-AS MPLS VPN, see materials of the related HCIE-
Datacom courses.
• 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:
1. Spoke-CE1 advertises a route to Spoke-PE1 through EBGP.
2. Spoke-PE1 advertises the route to the Hub-PE through IBGP.
3. 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.
4. 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.
5. The Hub-PE advertises the route with the export RT attribute of VPN_out to all 
Spoke-PEs.
6. Spoke-PE2 advertises the route to Spoke-CE2 through EBGP.
• The process of advertising routes from Spoke-CE1 to Spoke-CE2 is as follows:
1. Spoke-CE1 advertises a route to Spoke-PE1 through OSPF 100.
2. Spoke-PE1 advertises the route to the Hub-PE through IBGP.
3. 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.
4. 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.
5. 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.
6. 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:
1. Spoke-CE1 advertises a route to Spoke-PE1 through OSPF 100.
2. Spoke-PE1 advertises the route to the Hub-PE through IBGP.
3. 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.
4. 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.
5. The Hub-PE advertises the route with the export RT attribute of VPN_out to 
Spoke-PE2.
6. 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:
1. Spoke-CE1 advertises a route to Spoke-PE1 through EBGP.
2. Spoke-PE1 advertises the route to the Hub-PE through IBGP.
3. 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.
4. Hub-CE learns the route through OSPF 100 and advertises the route to the Hub-
PE through OSPF 200.
5. 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.
6. 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:
1. CE1 at site 1 advertises a route destined for 192.168.1.0/24 to PE1 using a Type 
3 LSA.
2. PE1 imports the route of the OSPF VPN1 process to BGP and advertises the 
route to PE2 and PE3 through MP-IBGP.
3. 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.
4. 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.
5. 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:
▪ PE1 withdraws the route to 192.168.1.0/24. If the link between PE1 and PE2 
is blocked, BGP Update messages cannot be sent to PE2. As a result, the 
route sent by PE3 to PE1 still exists. (In normal cases, the route is 
withdrawn when PE1 sends Update messages to PE2.) The next hop of the 
route from PE1 to 192.168.1.0/24 is PE3. Routing loops occur.
▪ If the priority of the MP-IBGP route on PE1 is higher than that of the OSPF 
route, PE1 preferentially selects the BGP route advertised by PE3. In this 
case, PE1 needs to withdraw the BGP route advertised to PE2. As a result, 
PE3 withdraws the BGP route advertised to PE1, and PE1 preferentially 
selects the OSPF route again. As a result, route flapping occurs.
• 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:
1. CE1 advertises a route destined for 192.168.1.0/24 to PE1 through EBGP. The 
AS_Path of the route is 65001.
2. PE1 advertises the route to PE2 and PE3 through MP-IBGP.
3. PE2 imports BGP routes to the OSPF VPN1 process and advertises a Type 5 LSA 
destined for 192.168.1.0/24 to CE2.
4. CE2 advertises the Type5 LSA to PE3.
5. PE3 preferentially selects an OSPF route (the OSPF route has a higher priority 
than the IBGP route) and advertisesan Update message to PE1 through MP-
IBGP.
6. 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.
7. 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
• 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.
• Storage space:
▫ Although most devices provide storage space of dozens of GBs or even hundreds 
of GBs, storage resources are consumed when some files, such as log files, are 
continuously generated during device running. In some abnormal situations, for 
example, when a device is attacked or device information changes frequently, the 
number of log files increases sharply. If this phenomenon persists, the storage 
space of the device may be exhausted, and as a result, key information may be 
lost.
• 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>
Jun 23 2020 10: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>Jun 23 2020 10:14:21.751.2-08:00 R1 RM/6/RMDEBUG: Source Address: 
10.0.12.1
<R1>Jun 23 2020 10:14:21.751.3-08:00 R1 RM/6/RMDEBUG: Destination Address: 
224.0.0.5
<R1>Jun 23 2020 10:14:21.751.4-08:00 R1 RM/6/RMDEBUG: Ver# 2, Type: 1 (Hello)
<R1>Jun 23 2020 10:14:21.751.5-08:00 R1 RM/6/RMDEBUG: Length: 48, Router: 
10.0.12.1
<R1>Jun 23 2020 10:14:21.751.6-08:00 R1 RM/6/RMDEBUG: Area: 0.0.0.0, Chksum: 
ae94
<R1>Jun 23 2020 10:14:21.751.7-08:00 R1 RM/6/RMDEBUG: AuType: 00
<R1>Jun 23 2020 10:14:21.751.8-08:00 R1 RM/6/RMDEBUG: Key(ascii): * * * * * * * *
<R1>Jun 23 2020 10:14:21.751.9-08:00 R1 RM/6/RMDEBUG: Net Mask: 
255.255.255.0
• 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
2. F
3. F
• Mapping between the preceding fault symptoms and categories varies according to 
scenarios.
• If an unstructured network troubleshootingis 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.
1. ABC
2. False
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. Theconfiguration 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.
	01 Advanced IGP Features
	02 Advanced BGP Features
	03 IPv6 Routing
	04 Advanced VLAN Technologies
	05 Ethernet Switching Security
	06 MPLS Implementation and Configuration
	07 LDP Principles and Configurations
	08 MPLS VPN Basics
	09 MPLS VPN Deployment and Application
	10 Network O M
	11 Network Fault Troubleshooting
	12 Network Migration