HCIE Routing and Switching Material

HCIE-R&S Material Confidentiality Level
HCIE-R&S Material
Chapter 1 RIP..........................................................................................................................4
1.1 Principles ...........................................................................................................4
1.2 RIPv2 Enhanced Features ..................................................................................6
1.3 Split Horizon and Poison Reverse ......................................................................7
1.4 Multi-process and Mult-instance .....................................................................9
1.5 RIP and BFD Association....................................................................................9
1.6 Hot Standby.....................................................................................................11
1.7 Examples for Configuring RIP ..........................................................................11
Chapter 2 IS-IS......................................................................................................................20
2.1 IS-IS Basic Concepts.........................................................................................20
2.2 IS-IS Basic Principles ........................................................................................27
2.3 IS-IS Authentcation.........................................................................................33
2.4 IS-IS Route Leaking ..........................................................................................34
2.5 IS-IS Overload ..................................................................................................35
2.6 IS-IS Route Management .................................................................................36
2.7 IS-IS LSP Fragment Extension ..........................................................................40
2.8 IS-IS Host Name Mapping................................................................................43
2.9 IS-IS Reliability .................................................................................................43
2.10 IS-IS GR ............................................................................................................45
2.11 BFD for IS-IS .....................................................................................................50
2.12 IS-IS Auto FRR ..................................................................................................53
2.13 IS-IS Multi-Instance and Mult-Process ...........................................................56
2.14 IS-IS IPv6 ..........................................................................................................57
2.15 Examples for Configuring of ISIS......................................................................59
Chapter 3 OSPF .................................................................................................................. 112
3.1 OSPF Summary ..............................................................................................112
3.2 Fundamentals of OSPF ..................................................................................112
3.3 BFD for OSPF .................................................................................................122
3.4 OSPF GTSM....................................................................................................124
3.5 OSPF Smart-discover .....................................................................................125
3.6 OSPF VPN.......................................................................................................125
3.7 OSPF NSSA .....................................................................................................132
3.8 OSPF Fast Convergence .................................................................................133
3.9 OSPF IP FRR ...................................................................................................135
3.10 Advertising Host Routes ................................................................................136
3.11 OSPF-BGP Association ...................................................................................137
3.12 OSPF GR.........................................................................................................138
3.13 OSPF-LDP Association....................................................................................141
2016-1-11 Huawei Confidential Page 1 of 1210

3.14 OSPF Database Overflow...............................................................................143
3.15 OSPF Mesh-Group .........................................................................................144
3.16 Example for Configuring of OSPF ..................................................................146
Chapter 4 BGP ....................................................................................................................192
4.1 BGP Concepts ................................................................................................192
4.2 BGP Working Principles .................................................................................194
4.3 Interaction between BGP and an IGP ............................................................197
4.4 BGP Security ..................................................................................................198
4.5 BGP Route Selection Rules and Load Balancing ............................................199
4.6 Examples for Configuring of BGP...................................................................203
Chapter 5 BGP Extension Technique ................................................................................234
5.1 Route Reflector..............................................................................................234
5.2 BGP Confederation ........................................................................................238
5.3 Route Summarization ....................................................................................240
5.4 Route Dampening..........................................................................................240
5.5 Association between BGP and BFD ...............................................................241
5.6 BGP Tracking..................................................................................................242
5.7 BGP Auto FRR ................................................................................................243
5.8 BGP GR and NSR ............................................................................................244
5.9 Dynamic Update Peer-Groups.......................................................................245
5.10 Examples for Configuring of BGP Extension Technique.................................248
Chapter 6 Router Import and Control ..............................................................................267
6.1 Routing Policy ................................................................................................267
6.2 Policy-based Routing .....................................................................................270
6.3 Examples for Configuring of Route Import and Control ................................273
Chapter 7 VLAN .................................................................................................................310
7.1 Basic Concepts of VLAN.................................................................................310
7.2 VLAN Assignment ..........................................................................................314
7.3 Principle of VLAN Communication ................................................................318
7.4 VLAN Aggregation .........................................................................................324
7.5 MUX VLAN .....................................................................................................331
7.6 Examples for Configuring of VLAN ................................................................332
Chapter 8 Layer 2 Ethernet Technologies.........................................................................347
8.1 ARP ................................................................................................................347
8.2 MAC Address Table........................................................................................349
8.3 Link Aggregation............................................................................................354
8.4 GVRP..............................................................................................................358
8.5 Example for Configuration.............................................................................360
Chapter 9 Layer 2 WAN Technologies ..............................................................................401
9.1 PPP ................................................................................................................401
9.2 MP .................................................................................................................409
9.3 PPPoE.............................................................................................................412
9.4 Frame Relay ...................................................................................................417
9.5 Examples for Configuring of Layer 2 WAN Technologies ...............................426
Chapter 10 STP ...................................................................................................................453
10.1 STP/RSTP........................................................................................................453
10.2 MSTP Principles .............................................................................................477
10.3 Examples for Configuring of STP ...................................................................502
Chapter 11 Multicast...........................................................................................................537
11.1 IP Multicast Basics .........................................................................................537
11.2 IGMP..............................................................................................................552
11.3 Layer 2 Multicast ...........................................................................................561
11.4 PIM ................................................................................................................580
11.5 Multicast Route Management.......................................................................602
11.6 Configuration Examples.................................................................................620
Chapter 12 IPv6 ..................................................................................................................734
12.1 IPv6 Addresses ..............................................................................................734
12.2 IPv6 Packet Format........................................................................................740
12.3 ICMPv6 ..........................................................................................................744
12.4 Neighbor Discovery .......................................................................................746
12.5 Path MTU.......................................................................................................752
12.6 Dual Protocol Stack .......................................................................................753
12.7 IPv6 over IPv4 Tunnel ....................................................................................755
12.8 IPv4 over IPv6 Tunnel ....................................................................................762
12.9 RIPng .............................................................................................................763
12.10 OSPFv3 ..........................................................................................................763
12.11 MP-BGP .........................................................................................................772
12.12 Examples for Configuring of IPv6 ..................................................................773
Chapter 13 MPLS VPN ......................................................................................................822
13.1 MPLS Basics ...................................................................................................822
13.2 MPLS LDP.......................................................................................................837
13.3 BGP/MPLS IP VPN ..........................................................................................858
13.4 Configuration Examples.................................................................................874
Chapter 14 Other Technologies........................................................................................ 1042
14.1 BFD ..............................................................................................................1042
14.2 URPF ............................................................................................................1049
14.3 IPSG .............................................................................................................1050
14.4 ARP Security ................................................................................................1051
14.5 QoS Technology Description........................................................................1062
14.6 SNMP...........................................................................................................1089
14.7 NQA .............................................................................................................1097
14.8 NTP ..............................................................................................................1101
14.9 Examples for Configuring Other Technologies ............................................1110
Chapter 1 RIP
1.1 Principles
RIP is based on the Distance-Vector (DV) algorithm. RIP uses hop count (HC) to measure the
distance to the destination. The distance is called the metric value. In RIP, the default HC from a
router to its directly connected network is 0, and the HC from a router to a reachable network through
another router is 1, and so on. That is to say, the HC equals the number of routers passed from the
local
network to the destination network. To speed up network convergence, RIP defines the HC as an
integer that ranges from 0 to 15. An HC 16 or greater is defined as infinity, that is, the
destination network or the host is unreachable.
1.1.1 RIP Routing Table
When RIP starts on a router, the RIP routing table contains only the routes to the directly connected
interfaces. After neighboring routers on different network segments learn the routing entries from
each other, they can communicate with each other.
Figure 1-1-1 RIP routing table generation
As shown in Figure 1-1-1, the process of RIP routing table generation.
 RIP starts, and then RouterA broadcasts Request packets to neighboring routers.
 When receiving the Request packet, RouterB encapsulates its own routing table into the
Response packet and broadcasts the Response packet to the network segment connected to
the interface receiving the Request packet.
 RouterA generates a routing table based on the Response packet sent from RouterB.
1.1.2 RIP Update and Maintenance
RIP uses four timers to update and maintain routing information:
 Update timer: When this timer expires, a router immediately sends an Update packet.
 Age timer: If a RIP device does not receive an Update packet from a neighbor within the
aging time, the RIP device considers the route to this neighbor unreachable.
 Garbage-collect timer: If a RIP device does not receive an Update packet of an unreachable
route within the timeout interval, the device deletes the routing entry from the routing table.
 Suppress timer: When a RIP device receives an Update packet with the Cost field being 16 from
a neighbor, the route is suppressed and the suppress timer starts. To avoid route flapping, the
RIP device does not accept any Update packet before the suppress timer expires even if the Cost
field in an Update packet is smaller than 16. After the suppress timer expires, the RIP device
accepts new Update packets.
Relationships between RIP routes and timers:
 The interval for sending Update packets is determined by the Update timer, which is 30
seconds by default.
 Each routing entry has two timers: age timer and Garbage-collect timer. When a RIP device
adds a learned route to the local routing table, the age timer starts for the routing entry. If the
RIP device does not receive an Update packet from the neighbor within the age time, the RIP
device sets the Cost value of the route to 16 (unreachable) and starts the Garbage-collect timer.
If the RIP device still does not receive an Update packet within the Garbage-collect timer, the
RIP device deletes the routing entry from the routing table.
1.1.2 Triggered Update
When routing information changes, a device immediately sends an Update packet to its
neighbors, without waiting for Update timer expiration. This function avoids loops.
Figure 1-1-2 Triggered update

As shown in Figure 1-1-2, RouterC first learns that network 11.4.0.0 is unreachable.
 If RouterC does not support triggered update when detecting a link fault, it has to wait until the
Update timer expires. If RouterC receives an Update packet from RouterB before its Update
timer expires, RouterC learns a wrong route to network 11.4.0.0. In this case, the next hops of
the routes from RouterB or RouterC to network 11.4.0.0 are RouterC and RouterB
respectively. A routing loop is generated.
 If RouterC supports triggered update when detecting a link fault, RouterC immediately
sends an Update packet to RouterB so that a routing loop is prevented.
1.2 RIPv2 Enhanced Features
Two versions are available for RIP: RIPv1 and RIPv2. RIPv2 is an extension to RIPv1.
1.2.1 Comparison between RIPv1 and RIPv2
RIP version 1 (RIPv1) is a classful (as opposed to classless) routing protocol. It supports the
advertisement of protocol packets only in broadcast mode. Figure 1-2-1 shows the packet format. The
RIPv1 protocol packet does not carry any mask, so it can identify only the routes of the natural
network segment such as Class A, Class B, and Class C, and does not support route aggregation or
discontinuous subnet.
RIP version 2 (RIPv2), is a classless routing protocol. Figure 1-2-2 shows the packet format.
Figure 1-2-1 RIPv1 packet format
Figure 1-2-2 RIPv2 packet format

Compared with RIPv1, RIPv2 has the following advantages:
 Supports route tag and can flexibly control routes on the basis of the tag in the routing policy.
 Has packets that contain mask information and supports route summarization and Classless
Inter-domain Routing (CIDR).
 Supports the next hop address and can select the optimal next hop address in the
broadcast network.
 Supports sending update packets in multicast mode. Only RIPv2 routers can receive
protocol packets. This reduces resource consumption.
 Provides two authentication modes to enhance security: plain-text authentication and

MD5 authentication.
1.2.2 RIPv2 Route Summarization
When different subnet routes in the same natural network segment are transmitted to other network
segments, these routes are summarized into one route of the same segment. This process is called
route summarization.
RIPv1 packets do not carry mask information, so RIPv1 can advertise only the routes with
natural masks. Because RIPv2 packets carry mask information, RIPv2 supports subnetting.
RIPv2 route summarization improves extensibility and efficiency and minimizes the routing
table size of a large-sized network.
Route summarization is classified into two types:
 RIP process-based classful summarization
Summarized routes are advertised using nature masks. For example, route 10.1.1.0/24
(metric=2) and route 10.1.2.0/24 (metric=3) are summarized as a route 10.0.0.0/8 (metric=2) in
the natural network segment. RIPv2 supports classful summarization to obtain the optimal
metric.
 Interface-based summarization
A user can specify a summarized address. For example, a route 10.1.0.0/16 (metric=2) can
be configured on the interface as a summarized route of route 10.1.1.0/24 (metric=2) and
route
10.1.2.0/24 (metric=3).
1.3 Split Horizon and Poison Reverse
1.3.1 Split Horizon
Split horizon ensures that a route learned by RIP on an interface is not sent to neighbors from
the interface. This feature reduces bandwidth consumption and avoids routing loops.
Split horizon provides two models for different networks: interface-based split horizon and
neighbor-based split horizon. Broadcast, P2P, and P2MP networks use interface-based split horizon,
as shown in Figure 1-3-1.
Figure 1-3-1 Interface-based split horizon
RouterA sends routing information destined for 10.0.0.0/8 to RouterB. If split horizon is not
configured, RouterB sends the route learned from RouterA back to RouterA. Thus RouterA can learn
two routes destined for 10.0.0.0/8: a direct route with hop count 0 and a route with the next hop
RouterB and hop count 2.
However, only the direct route in the RIP routing table on RouterA is active. When the route from
RouterA to network 10.0.0.0 is unreachable, RouterB does not receive the unreachable message
immediately and still notifies RouterA that network 10.0.0.0/8 is reachable. Therefore, RouterA
receives incorrect routing information that network 10.0.0.0/8 is reachable through RouterB, and
RouterB considers that network 10.0.0.0/8 is reachable through RouterA. A routing loop is thus
generated. With the split horizon feature, RouterB does not send the route destined for 10.0.0.0/8
back to RouterA. Routing loops are avoided.
On a Non-Broadcast Multiple Access (NBMA) network, an interface connects to multiple neighbors;

therefore, split horizon is performed based on neighbors. Routes are advertised in unicast mode. The
routes received by an interface are differentiated by neighbors. The route learned from a neighbor is
not sent back through the same interface.
Figure 1-3-2 Neighbor-based split horizon

As shown in Figure 1-3-2, after split horizon is configured on an NBMA network, RouterA
sends route 10.0.0.0/8 learned from RouterB to RouterC, but does not send it to RouterB.
1.3.2 Poison Reverse
Poison reverse ensures that RIP sets the cost of the route learned from an interface of a neighbor to
16 (unreachable) and then sends the route from the same interface back to the neighbor. This feature
deletes useless routes from the routing table and avoids routing loops.
Poison reverse prevents loops, as shown in Figure 1-3-3.
Figure 1-3-3 Poison reverse

After receiving a route from RouterA, RouterB sends an unreachable message (with the route Cost
being 16) to RouterA. RouterA then does not learn the route from RouterB. A routing loop is
avoided.
1.4 Multi-process and Multi-instance
The multi-process feature associates a RIP process with multiple interfaces, ensuring that the
specific process performs all the protocol-related operations only on these interfaces. With the
multi-process feature, multiple RIP processes can run on a device independently. Route exchange
between RIP processes is similar to route exchange between routing protocols.
RIP multi-instance associates a VPN instance with a RIP process so that the VPN instance can
be associated with all interfaces on this process.
1.5 RIP and BFD Association
A link fault or topology change causes routers to recalculate routes. Therefore, route convergence
must be quick enough to ensure network performance. A solution to speed up route convergence is to
quickly detect faults and notify routing protocols of the faults.
Bidirectional Forwarding Detection (BFD) detects faults on links between neighboring routers.
Associated with a routing protocol, BFD can rapidly detect link faults and report the faults to the
protocol so that the protocol quickly triggers route convergence. Traffic loss caused by topology
changes is minimized. After RIP is associated with BFD, BFD rapidly detects link faults and
reports the faults to RIP so that RIP quickly responds to network topology changes.
Table 1-5-1 lists the link fault detection mechanisms and convergence speed before and after BFD
is associated with RIP.
Table 1-5-1 lists the features of RIP and BFD Association

RIP and BFD Link Fault Detection Mechanism Convergence Speed
Association
Feature
Disabled
Enabled
1.5.1 Principle
BFD is classified into static BFD and dynamic BFD:
 Static BFD
In static BFD, BFD session parameters (including local and remote discriminators) are
set manually using commands, and BFD session setup requests are manually delivered.
 Dynamic BFD
In dynamic BFD, BFD session setup is triggered by routing protocols. The local discriminator
is dynamically allocated and remote discriminator is obtained from the peer. A routing protocol
notifies BFD of the neighbor parameters (including destination and source addresses), and then
BFD sets up a session based on the received parameters. When a link fault occurs, the protocol
associated with BFD quickly detects that the BFD session is Down, and switches traffic to the
backup link. This feature minimizes data loss.
A device can implement static BFD even if the peer device does not support BFD. Dynamic BFD
is more flexible than static BFD.
1.5.2 Application
After RIP is associated with BFD, BFD reports link faults to RIP within several milliseconds. The
RIP router then deletes the faulty links from the local routing table and starts the backup link. This
feature increases route convergence speed.
Figure 1-5-1 RIP and BFD association network

Implementation of RIP and BFD association:
 As shown in Figure 1-5-1, RouterA, RouterB, RouterC, and RouterD set up RIP neighbor
relationships. RouterB is the next hop on the route from RouterA to RouterD. RIP and
BFD association is configured on RouterA and RouterB.
 When the link between RouterA and RouterB has a faulty, BFD quickly detects the fault and
notifies RouterA of the fault. RouterA deletes the route with RouterB as the next hop, and
then recalculates a route. The new route passes RouterC and RouterB and reaches RouterD.
 When the link between RouterA and RouterB recovers, a session is set up again. RouterA
receives routing information from RouterB and selects the optimal route.
1.6 Hot Standby
Devices with distributed architecture support the RIP hot standby feature.
During hot standby, a device backs up RIP data from the active main board (AMB) to the standby
main board (SMB). When the AMB becomes faulty, the SMB becomes active and takes over the
AMB's tasks. This prevents RIP from being affected and ensures normal data forwarding.
1.7 Examples for Configuring RIP
1.7.1 Example for Configuring Basic RIP Functions
Networking Requirements
As shown in Figure 1-7-1, RouterA, RouterB, RouterC, and RouterD are located on a small-
sized network, and they need to communicate with each other.
Figure 1-7-1 Network diagram of basic RIP functions
Configuration Roadmap
The network size is small, so RIPv2 is recommended. The configuration roadmap is as follows:
1. Configure IP address for each interface to ensure network reachability.
2. Enable RIP on each router to implement network connections between processes.
3. Configure RIPv2 on each router to improve RIP performance.
Procedure
1. Configure IP address for each interface.

# Configure RouterA.
[RouterA] interface gigabitethernet 1/0/0

[RouterA-GigabitEthernet1/0/0] ip address 192.168.1.1 24
The configurations of RouterB, RouterC, and RouterD are similar to the configuration of
RouterA, and are not mentioned here.
2. Configure basic RIP functions.
[RouterA] rip
[RouterA-rip-1] network 192.168.1.0
[RouterA-rip-1] quit
# Configure RouterB.
[RouterB] rip
[RouterB-rip-1] network 192.168.1.0
[RouterB-rip-1] quit
# Configure RouterC.
[RouterC] rip
[RouterC-rip-1] network 172.16.0.0
[RouterC-rip-1] quit
# Configure RouterD.
[RouterD] rip
[RouterD-rip-1] network 10.0.0.0
[RouterD-rip-1] quit
# Check the RIP routing table of RouterA.
[RouterA] display rip 1 route

Route Flags: R - RIP
A - Aging, S - Suppressed, G - Garbage-collect
-------------------------------------------------------------------------
Peer 192.168.1.2 on GigabitEthernet1/0/0
Destination/Mask
10.0.0.0/8
172.16.0.0/16
The preceding display shows that the routes advertised by RIPv1 carry natural masks.
3. Configure the RIP version.

# Configure RIPv2 on RouterA.
[RouterA] rip
[RouterA-rip-1] version 2
# Configure RIPv2 on RouterB.
[RouterB] rip
[RouterB-rip-1] version 2
# Configure RIPv2 on RouterC.
[RouterC] rip
[RouterC-rip-1] version 2
# Configure RIPv2 on RouterD.
[RouterD] rip
[RouterD-rip-1] version 2
[RouterD-rip-1] quit
4. Verify the configuration.
# Check the RIP routing table of RouterA.
[RouterA] display rip 1 route

Route Flags: R - RIP
A - Aging, S - Suppressed, G - Garbage-collect
-------------------------------------------------------------------------
Peer 192.168.1.2 on GigabitEthernet1/0/0
Destination/Mask
10.1.1.0/24
172.16.1.0/24
The preceding display shows that the routes advertised by RIPv2 carry subnet masks.
Configuration Files
 Configuration file of RouterA
#
sysname RouterA
#
interface GigabitEthernet1/0/0
ip address 192.168.1.1 255.255.255.0
#
rip 1
version 2
network 192.168.1.0
#
return
 Configuration file of RouterB
#
sysname RouterB
#
ip address 192.168.1.2 255.255.255.0
#
ip address 172.16.1.1 255.255.255.0
#
ip address 10.1.1.1 255.255.255.0
#
rip 1
version 2
network 192.168.1.0
network 172.16.0.0
network 10.0.0.0
#
return
 Configuration file of RouterC
#
sysname RouterC
#
ip address 172.16.1.2 255.255.255.0
#
rip 1
version 2
network 172.16.0.0
#
return
 Configuration file of RouterD
#
sysname RouterD
#
ip address 10.1.1.2 255.255.255.0
#
rip 1 version 2
network 10.0.0.0
#
return
1.7.2 Example for Importing Routes to RIP
As shown in Figure 1-7-2, two RIP processes, RIP100 and RIP200, run on RouterB. RouterA needs
to communicate with network segment 192.168.3.0/24.
Figure 1-7-2 Network diagram of configuring RIP to import external routes
The configuration roadmap is as follows:
1. Enable RIP on each router to implement network connections between processes.
2. Import routes between RIP100 and RIP200 on RouterB and set the default metric of
routes imported from RIP200 to 3.
3. Configure an ACL on RouterB to filter route 192.168.4.0/24 imported from RIP200 so that
RouterA can only communicate with network segment 192.168.3.0/24.
Procedure
1. Configure an IP address for each interface.

The configurations of RouterB, and RouterC are similar to the configuration of RouterA,
and are not mentioned here.
2. Configure the basic RIP functions.
# Enable RIP process 100 on RouterA.
[RouterA] rip 100

# Enable RIP processes 100 and 200 on RouterB.
[RouterB] rip 100

[RouterB] rip 200
# Enable RIP process 200 on RouterC.
[RouterC] rip 200

# View the routing table on RouterA.
[RouterA] display ip routing-table

Route Flags: R - relay, D - download to fib
------------------------------------------------------------------------------
Routing Tables: Public
Destinations : 7 Routes : 7
Destination/Mask
127.0.0.0/8
127.0.0.1/32
192.168.0.0/24 Direct 0 0 D 192.168.0.1
GigabitEthernet2/0/0
192.168.0.1/32 Direct 0 0 D 127.0.0.1 InLoopBack0
192.168.1.0/24 Direct 0 0 D 192.168.1.1
192.168.1.2/32 Direct 0 0 D 192.168.1.2
3. Configure RIP to import external routes.
# On RouterB, set the default metric of imported routes to 3 and configure the RIP processes
to import routes into each other's routing table.
[RouterB] rip 100

[RouterB-rip-100] default-cost 3
[RouterB-rip-100] import-route rip 200
[RouterB] rip 200
[RouterB-rip-200] import-route rip 100
# View the routing table of RouterA after the routes are imported.

------------------------------------------------------------------------------
Destination/Mask Proto Pre Cost Flags NextHop Interface
192.168.0.0/24 Direct 0 0 D 192.168.0.1
192.168.1.0/24 Direct 0 0 D 192.168.1.1
192.168.1.2/32 Direct 0 0 D 192.168.1.2
192.168.2.0/24 RIP 100 4 D 192.168.1.2
192.168.3.0/24 RIP 100 4 D 192.168.1.2
192.168.4.0/24 RIP 100 4 D 192.168.1.2
4. Configure RIP to filter imported routes.
# Configure an ACL on RouterB and add a rule to the ACL. The rule denies the packets
sent from 192.168.4.0/24.
[RouterB] acl 2000

[RouterB-acl-basic-2000] rule deny source 192.168.4.0 0.0.0.255
[RouterB-acl-basic-2000] rule permit
[RouterB-acl-basic-2000] quit
# Configure RouterB to filter route 192.168.4.0/24 imported from RIP200.
[RouterB] rip 100

[RouterB-rip-100] filter-policy 2000 export
# Display the RIP routing table of RouterA after the routes are filtered.

------------------------------------------------------------------------------
192.168.0.0/24 Direct 0 0 D 192.168.0.1
192.168.1.0/24 Direct 0 0 D 192.168.1.1
192.168.1.2/32 Direct 0 0 D 192.168.1.2
192.168.2.0/24 RIP 100 4 D 192.168.1.2
192.168.3.0/24 RIP 100 4 D 192.168.1.2
Configuration Files
#
sysname RouterA
#
ip address 192.168.1.1 255.255.255.0
#
ip address 192.168.0.1 255.255.255.0
#
rip 100
network 192.168.0.0
network 192.168.1.0
#
return
#
sysname RouterB
#
acl number 2000
rule 5 deny source 192.168.4.0 0.0.0.255
rule 10 permit
#
ip address 192.168.1.2 255.255.255.0
#
ip address 192.168.2.1 255.255.255.0
#
rip 100
default-cost 3 network
192.168.1.0 filter-policy
2000 export import-
route rip 200
#
rip 200
network 192.168.2.0
import-route rip 100
#
return
#
sysname RouterC
#
ip address 192.168.2.2 255.255.255.0
#
ip address 192.168.3.1 255.255.255.0
#
ip address 192.168.4.1 255.255.255.0
#
rip 200
network 192.168.2.0
network 192.168.3.0
network 192.168.4.0
#
return
Chapter 2 IS-IS
2.1 IS-IS Basic Concepts
2.1.1 IS-IS Topology Structure
IS-IS uses a two-level hierarchy (backbone area and non-backbone area) to support large-scale
routing networks. Generally, Level-1 routers are deployed in non-backbone areas, whereas Level-2
and
Level-1-2 routers are deployed in backbone areas. Each non-backbone area connects to the
backbone area through a Level-1-2 router.
Figure 2-1-1 shows a network that runs IS-IS. The network is similar to an OSPF network topology
with multiple areas. The backbone area contains all the routers in Area 1 and Level-1-2 routers in
other areas.
Figure 2-1-1 IS-IS topology I
Figure 2-1-2 shows another type of IS-IS topology. In this topology, Level-2 routers belong to
different areas. All the physically contiguous Level-1-2 and Level-2 routers form the backbone area
of IS-IS.
Figure 2-1-2 IS-IS topology II

The two types of topologies show the differences between IS-IS and OSPF:
 In IS-IS, each router belongs to only one area. In OSPF, different interfaces of a router
may belong to different areas.
 In IS-IS, no area is defined as the backbone area. In OSPF, Area 0 is defined as the
backbone area.
 In IS-IS, Level-1 and Level-2 routes are calculated using the SPF algorithm to generate the
shortest path tree (SPT). In OSPF, the SPF algorithm is used only in the same area, and inter-
area routes are forwarded by the backbone area.
2.1.2 IS-IS Router Types
Level-1 router
A Level-1 router manages intra-area routing. It establishes neighbor relationships with only the Level-
1 and Level-1-2 routers in the same area and maintains a Level-1 link state database (LSDB). The
LSDB contains intra-area routing information. A packet to a destination outside this area is forwarded
to the nearest Level-1-2 router.
Level-2 router
A Level-2 router manages inter-area routing. It can establish neighbor relationships with Level-2
or Level-1-2 routers in different areas and maintains a Level-2 LSDB. The LSDB contains inter-
area routing information.
All Level-2 routers form the backbone network of the routing domain. They establish Level-2
neighbor relationships and are responsible for inter-area communication. Level-2 routers in the
routing domain must be physically contiguous to ensure the continuity of the backbone network. Only
Level-2 routers can exchange data packets or routing information with routers outside the routing
domain.
Level-1-2 router
A router that belongs to both a Level-1 area and a Level-2 area is called a Level-1-2 router. It can
establish Level-1 neighbor relationships with Level-1 and Level-1-2 routers in the same area. It can
also establish Level-2 neighbor relationships with Level-2 and Level-1-2 routers in different areas.
A Level-1 router must be connected to other areas through a Level-1-2 router.
A Level-1-2 router maintains two LSDBs: a Level-1 LSDB and a Level-2 LSDB. The Level-1 LSDB
saves for intra-area routing and the Level-2 LSDB saves for inter-area routing.
2.1.3 IS-IS Network Types
IS-IS supports only two types of networks. In terms of physical links, IS-IS networks can be
classified into the following link types:
 Broadcast: such as Ethernet and Token-Ring
 Point-to-point: such as PPP and HDLC
NOTE:
For a Non-Broadcast Multi-Access (NBMA) network such as the ATM, you should configure
its sub-interfaces as P2P interfaces.
IS-IS cannot run on Point to MultiPoint (P2MP) networks.
DIS and Pseudonode
In a broadcast network, IS-IS needs to elect a Designated Intermediate System (DIS) from all the
routers. DISs are used to create and update pseudonodes and generate link state protocol data
units (LSPs) of pseudonodes to describe available network devices.
The pseudonode is used to simulate the virtual node in the broadcast network and is not an actual
router. In IS-IS, a pseudonode is identified by the system ID of the DIS and the 1-byte Circuit ID (its
value is not 0).
Figure 2-1-3 Pseudonode

The use of pseudonodes simplifies the network topology and shortens LSPs. When the
network changes, the number of generated LSPs is reduced, and the SPF consumes fewer
resources.
You can configure different priorities for DISs of different levels. The router with the highest priority
is elected as the DIS. If there are multiple routers with the same highest priority on a broadcast
network, the one with the highest MAC address is chosen. The DISs of different levels can be the
same router or different routers.
DIS election in IS-IS differs from designated router (DR) election in OSPF:
 On an IS-IS broadcast network, the router with priority 0 also takes part in DIS election. In
OSPF, the router with priority 0 does not take part in DR election.
 In IS-IS, when a new router that meets the requirements of being a DIS connects to a
broadcast network, the router is elected as the new DIS, and the previous pseudonode is
deleted. This causes a new flooding of LSPs. In OSPF, when a new router connects to a
network, it is not immediately elected as the DR even if it has the highest DR priority.
 On an IS-IS broadcast network, routers (including non-DIS routers) of the same level on a
network segment set up adjacencies. In OSPF, routers set up adjacencies with only the DR
and backup designated router (BDR).
NOTE:
On an IS-IS broadcast network, although all the routers set up adjacencies with each other, the
LSDBs are synchronized by the DISs.
2.1.4 IS-IS Address Structure
The network service access point (NSAP) is an address defined by the OSI to locate resources. Figure
2-1-4 shows the NSAP address structure. The NSAP is composed of the initial domain part (IDP)
and the domain specific part (DSP). The lengths of the IDP and the DSP are variable. The maximum
length of the NSAP is 20 bytes and its minimum length is 8 bytes.
 The IDP is similar to the network ID in an IP address. It is defined by the ISO and consists of the
authority and format identifier (AFI) and the initial domain identifier (IDI). The AFI indicates
the address allocation authority and address format, and the IDI identifies a domain.
 The DSP is similar to the subnet ID and host address in an IP address. The DSP consists of the
High Order DSP (HODSP), system ID, and NSAP Selector (SEL). The HODSP is used to
divide areas, the system ID identifies a host, and the SEL indicates the service type.
Figure 2-1-4 IS-IS address structure
Area Address
The IDP and the HODSP of the DSP identify a routing domain and the areas in a routing domain.
Therefore, the combination of the IDP and HODSP is called an area address, which is similar to an
area number in OSPF. The area addresses of routers in the same Level-1 area must be the same, while
the area addresses of routers in the Level-2 area can be different.
In general, a router can be configured with only one area address. The area address of all nodes in
an area must be the same. In the implementation of a device, an IS-IS process can be configured
with a maximum of three area addresses to support seamless combination, division, and
transformation of areas.
System ID
A system ID uniquely identifies a host or a router in an area. In the device, the fixed length of
the system ID is 48 bits (6 bytes).
In actual applications, a router ID corresponds to a system ID. If a router takes the IP address
168.10.1.1 of Loopback 0 as its router ID, its system ID used in IS-IS can be obtained in the
following way:
 Extend each part of IP address 168.10.1.1 to 3 bits and add 0 to the front of any part that
is shorter than 3 bits. Then the IP address is extended as 168.010.001.001.
 Divide the extended address 168.010.001.001 into three parts, each of which consists of
four decimal digits. Then system ID 1680.1000.1001 is obtained.
You can specify a system ID in many ways. You need to ensure that the system ID uniquely
identifies a host or a router.
SEL
The role of an SEL is similar to that of the "protocol identifier" of IP. A transport protocol matches an
SEL. The SEL is always "00" in IP.
A network entity title (NET) indicates network layer information about an IS. A NET can be regarded
as a special NSAP. The NET length is the same as the NSAP length. Its maximum length is 20 bytes
and minimum length is 8 bytes. When configuring IS-IS on a router, you only need to configure a
NET but not an NSAP.
Assume that there is a NET: ab.cdef.1234.5678.9abc.00. In the NET, the area address is ab.cdef,
the system ID is 1234.5678.9abc, and the SEL is 00.
2.1.5 IS-IS PDU Types
IS-IS PDUs include Hello PDUs, link state PDUs (LSPs), and sequence number PDUs (SNPs).
Hello PDU
Hello packets, also called IS-IS Hello PDUs (IIH), are used to set up and maintain neighbor
relationships. Among them, Level-1 LAN IIHs apply to the Level-1 routers on broadcast
LANs; Level-2 LAN IIHs apply to the Level-2 routers on broadcast LANs; and P2P IIHs apply
to
non-broadcast networks. Hello packets on different networks have different formats. Compared to a
LAN IIH, a P2P IIH does not have the Priority and LAN ID fields, but has a Local Circuit ID field.
The Priority field indicates the DIS priority on a broadcast network, the LAN ID field indicates the
system ID of the DIS and pseudonode, and the Local Circuit ID indicates the local link ID.
LSP
LSPs are used to exchange link-state information. There are two types of LSPs: Level-1 and Level-2.
Level-1 IS-IS transmits Level-1 LSPs; Level-2 IS-IS transmits Level-2 LSPs; and Level-1-2 IS-IS
can transmit both Level-1 and Level-2 LSPs.
The meanings of major fields in an LSP are as follows:

 ATT field: When a Level-1-2 IS-IS transmits Level-1 LSPs in a Level-1 area, Level-1 IS-IS in
the area can communicate with devices in other areas through the Level-1-2 IS-IS if the ATT
bit is set in the Level-1 LSPs.
 OL field: indicates the LSDB overload.
LSPs with the overload bit are still flooded on the network, but these LSPs are ignored during
the calculation of the routes that pass through a router in overload state. After the overload bit is
set on a router, other routers ignore the router when performing SPF calculation and consider
only the direct routes of the router. For details, see "IS-IS Overload" in Principles.
 IS Type field: indicates the type of IS-IS that generates the LSP. The value 01 indicates Level-
1, and the value 11 indicates Level-2.
SNP
SNPs describe the LSPs in all or some databases to help synchronize and maintain all LSDBs.
SNPs include complete SNPs (CSNPs) and partial SNPs (PSNPs). They are further classified
into
Level-1 CSNPs, Level-2 CSNPs, Level-1 PSNPs, and Level-2 PSNPs.
A CSNP contains the summary of all LSPs in an LSDB. This maintains LSDB synchronization
between neighboring routers. On a broadcast network, the DIS periodically sends CSNPs. The
default interval for sending CSNPs is 10 seconds. On a point-to-point link, CSNPs are sent only
when the neighbor relationship is established for the first time.
A PSNP lists only the sequence number of recently received LSPs. A PSNP can acknowledge multiple
LSPs at one time. If an LSDB is not updated, the PSNP is also used to request a neighbor to send a
new LSP.
The variable length fields in an IS-IS PDU are multiple type-length-values (TLVs). Figure 2-1-5
shows the TLV format. A TLV is also called a code-length-value (CLV).
Figure 2-1-5 TLV format

TLVs vary according to PDU types, as shown in Table 2-1-1.
Table 2-1-1 PDU types and TLV names
TLV Type
2
Table 2-1-1 PDU types and TLV names
TLV Type
10
128
129
130
131
132
TLVs with the type value ranging from 1 to 10 are defined in ISO 10589, and the other TLVs
are defined in RFC 1195.
2.2 IS-IS Basic Principles
IS-IS is a link-state routing protocol. Each router generates an LSP that contains link state
information about all the IS-IS interfaces on the router. The router can establish IS-IS neighbor
relationships with neighboring devices and update its LSDB to synchronize the local LSDB with the
LSDBs of all the other devices on the IS-IS network. Based on the local LSDB, the router uses the
SPF algorithm to calculate IS-IS routes. If the router finds that an IS-IS route is the optimal route to a
destination, the router adds the route to the local IP routing table to guide packet forwarding.
2.2.1 Establishment of IS-IS Neighbor Relationship
Two IS-IS routers need to establish a neighbor relationship before exchanging packets to
implement routing. On different networks, the modes for establishing IS-IS neighbors are different.
Establishment of a neighbor relationship on a broadcast link
Figure 2-2-1 uses Level-2 routers as an example to describe the process of establishing a neighbor
relationship on a broadcast link. The process of establishing a neighbor relationship between Level-
1 routers is the same as the process of establishing a neighbor relationship between Level-2 routers.
Figure 2-2-1 Process of establishing a neighbor relationship on a broadcast link
1. RouterA broadcasts a Level-2 LAN IS-IS Hello PDU (IIH) with no neighbor ID specified.
2. RouterB receives this packet and sets the status of the neighbor relationship with RouterA to
Initial. RouterB then responds to RouterA with a Level-2 LAN IIH, indicating that RouterA is
a neighbor of RouterB.
3. RouterA receives this packet and sets the status of the neighbor relationship with RouterB to
Up. RouterA then sends RouterB a Level-2 LAN IIH indicating that RouterB is a neighbor
of RouterA.
4. RouterB receives this packet and sets the status of the neighbor relationship with RouterA to
Up. RouterA and RouterB establish a neighbor relationship successfully.
The network is a broadcast network, so a DIS needs to be elected. After the neighbor relationship
is established, routers wait for two intervals before sending Hello packets to elect the DIS. The IIH
packets exchanged by the routers contain the Priority field. The router with the highest priority is
elected as the DIS. If the routers have the same priority, the router with the largest interface MAC
address is elected as the DIS.
Establishment of a neighbor relationship on a P2P link
Unlike the establishment of a neighbor relationship on a broadcast link, the establishment of a

neighbor relationship on a P2P link is classified into two modes: two-way mode and three-way mode.
 Two-way mode
Upon receiving a P2P IIH from a neighbor, a router considers the neighbor Up and establishes
a neighbor relationship with the neighbor.
 Three-way mode
A neighbor relationship is established after P2P IIHs are sent for three times. The
establishment of a neighbor relationship on a P2P link is similar to that on a broadcast link.
Two-way mode has distinct disadvantages. For example, when two or more links exist between two
routers, the two routers can still establish a neighbor relationship if one link is Down and th e other
is
Up in the same direction. The parameters of the link in Up state are used in SPF calculation. As a
result, the router that does not detect the fault of the link in Down state still tries to forward packets
over this link. Three-way mode addresses such problems on unreliable P2P links. In three-way mode, a
router considers the neighbor Up only after confirming that the neighbor receives the packet sent by
itself, and then establishes a neighbor relationship with the neighbor.
Basic rules for establishing an IS-IS neighbor relationship are as follows:
 Only neighboring routers of the same level can set up the neighbor relationship with each other.
 For Level-1 routers, their area IDs must be the same
 Network types of IS-IS interfaces on both ends of a link must be consistent.
NOTE:
Ethernet interfaces can be simulated as P2P interfaces to establish a neighbor relationship on a P2P
link.
 IP addresses of IS-IS interfaces on both ends of a link must be on the same network segment.
IS-IS runs on the data-link layer and was initially designed for CLNP. Therefore, the
establishment of an IS-IS neighbor relationship is not related to IP addresses. In the
implementation of a device, IS-IS runs only over IP. Therefore, IS-IS needs to check the IP
address of its neighbor. If secondary IP addresses are assigned to the interfaces, the routers
can still set up the IS-IS neighbor relationship, but only when either the primary IP addresses
or secondary IP addresses are on the same network segment.
NOTE:
When IP addresses of IS-IS interfaces on both ends of a link are on different network segments,
a neighbor relationship can still be established on the two interfaces if the interfaces are
configured not to check the IP addresses in received Hello packets. You can configure P2P
interfaces not to check the IP addresses in received Hello packets. Before configuring Ethernet
interfaces not to check the IP addresses, simulate Ethernet interfaces as P2P interfaces.
2.2.2 Process of Exchanging IS-IS LSPs
Causes of LSP generation
All routers in the IS-IS routing domain can generate LSPs. The following events trigger the
generation of a new LSP:
 Neighbor is Up or Down.
 Related interface goes Up or Down.
 Imported IP routes change.
 Inter-area IP routes change.
 Interface is assigned a new metric value.

 Periodic updates occur.
Processing of a new LSP received from a neighbor
1. The router installs the LSP to its LSDB and marks it for flooding.
2. The router sends the LSP to all interfaces except the interface that initially received the LSP.
3. The neighbors flood the LSP to their neighbors.
LSP flooding
In LSP flooding, a router sends an LSP to its neighbors and then the neighbors send the received LSP
to their respective neighbors except the router that first sends the LSP. In this manner, the LSP is
flooded among the routers of the same level. LSP flooding allows each router of the same level to
have the same LSP information and synchronize its LSDB with each other.
Each LSP has a 4-byte sequence number. When a router is started, the sequence number of the first
LSP sent by the router is 1. When a new LSP is generated, the sequence number of the LSP is equal
to the sequence number of the previous LSP plus 1. The greater the sequence number, the newer the
LSP.
Process of synchronizing LSDBs between a newly added router and DIS on a broadcast link
Figure 2-2-2 Process of updating LSDBs on a broadcast link
1. A new router (RouterC) sends a Hello packet to establish neighbor relationships with the
other routers in the broadcast domain.
2. RouterC establishes neighbor relationships with RouterA and RouterB, waits for the timeout
of the LSP refresh timer, and then sends its LSP to a multicast address (01-80-C2-00-00-1 in a
Level-1 area and 01-80-C2-00-00-15 in a Level-2 area). All neighbors on the network can
receive the LSP.
3. The DIS on the network segment adds the received LSP to its LSDB. After the CSNP
timer expires, the DIS sends CSNPs to synchronize the LSDBs on the network.
4. RouterC receives the CSNPs from the DIS, checks its LSDB, and sends a PSNP to request the
LSPs it does not have.
5. The DIS receives the PSNP and sends RouterC the required LSPs for LSDB
synchronization. The process of updating the LSDB of the DIS is as follows:
1. When the DIS receives an LSP, it searches the LSDB to check whether the same LSP exists.
If the DIS does not find the same LSP in its LSDB, the DIS adds the LSP to its LSDB and
broadcasts the content of the new LSDB.
2. If the sequence number of the received LSP is greater than that of the corresponding LSP in
the LSDB, the DIS replaces the existing LSP with the received LSP and broadcasts the
contents of the new LSDB. If the sequence number of the received LSP is smaller than that of
the corresponding LSP in the LSDB, the DIS sends its LSP in the LSDB through the inbound
interface of the received LSP.
3. If the sequence number of the received LSP is the same as that of the corresponding LSP in
the LSDB, the DIS compares the remaining lifetime of the two LSPs. If the remaining lifetime
of the received LSP is smaller than that of the corresponding LSP in the LSDB, the DIS
replaces the existing LSP with the received LSP and broadcasts the contents of the new
LSDB. If the remaining lifetime of the received LSP is greater than that of the corresponding
LSP, the DIS sends its LSP in the LSDB through the inbound interface of the received LSP.
4. If the sequence number and remaining lifetime of the received LSP are the same as those of
the corresponding LSP in the LSDB, the DIS compares the checksum of the two LSPs. If the
checksum of the received LSP is greater than that of the corresponding LSP in the LSDB, the
DIS replaces the existing LSP with the received LSP and broadcasts the content of the new
LSDB. If the checksum of the received LSP is smaller than that of the corresponding LSP, the
DIS sends its LSP in the LSDB through the inbound interface of the received LSP.
5. If the sequence number, remaining lifetime, and checksum of the received LSP are the same
as those of the corresponding LSP in the LSDB, the DIS does not forward the received LSP.
Process of synchronizing the LSDB on a P2P link
Figure 2-2-3 Process of updating LSDBs on a P2P link

1. RouterA establishes a neighbor relationship with RouterB.
2. RouterA and RouterB send a CSNP to each other. If the LSDB of the neighbor and the received
CSNP are not synchronized, the neighbor sends a PSNP to request the required LSP.
3. Figure 2-2-3 assumes that RouterB requests the required LSP from RouterA. RouterA sends the
required LSP to RouterB, starts the LSP retransmission timer, and waits for a PSNP from
RouterB as an acknowledgement for the received LSP.
4. If RouterA does not receive a PSNP from RouterB after the LSP retransmission timer
expires, RouterA resends the LSP until it receives a PSNP from RouterB.
NOTE:
A PSNP on a P2P link is used as follows:
 An ACK packet to acknowledge the received LSP.
 A request packet to acquire LSPs.
The process of updating LSDBs on a P2P link is as follows:
1. If the sequence number of the received LSP is smaller than that of the corresponding LSP in the
LSDB, the router directly sends its LSP to the neighbor and waits for a PSNP from the
neighbor. If the sequence number of the received LSP is greater than that of the corresponding
LSP in the LSDB, the router adds the received LSP to its LSDB, sends a PSNP to acknowledge
the
received LSP, and then sends the received LSP to all its neighbors except the neighbor
that sends the LSP.
2. If the sequence number of the received LSP is the same as that of the corresponding LSP in the
LSDB, the router compares the remaining lifetime of the two LSPs. If the received LSP has a
smaller remaining lifetime than that of the corresponding LSP in the LSDB, the router adds the
received LSP to its LSDB, sends a PSNP to acknowledge the received LSP, and then sends the
received LSP to all its neighbors except the neighbor that sends the LSP. If the received LSP
has
a greater remaining lifetime than that of the corresponding LSP in the LSDB, the router
directly sends its LSP to the neighbor and waits for a PSNP from the neighbor.
3. If the sequence number and remaining lifetime of the received LSP are the same as those of
the corresponding LSP in the LSDB, the router compares the checksum of the two LSPs. If
the received LSP has a greater checksum than that of the corresponding LSP in the LSDB, the
router adds the received LSP to its LSDB, sends a PSNP to acknowledge the received LSP,
and then sends the received LSP to all its neighbors except the neighbor that sends the LSP. If
the received LSP has a smaller checksum than that of the corresponding LSP in the LSDB, the
router directly sends its LSP to the neighbor and waits for a PSNP from the neighbor.
4. If the sequence number, remaining lifetime, and checksum of the received LSP and the
corresponding LSP in the LSDB are the same, the router does not forward the received
LSP.
2.3 IS-IS Authentication
To ensure network security, IS-IS authentication encrypts IS-IS packets by adding the
authentication field to packets. When a local router receives IS-IS packets from a remote router, the
local router discards the packets if the authentication passwords do not match. This protects the
local router.
Authentication Types
Based on the types of packets, the authentication is classified as follows:
 Interface authentication: authenticates Level-1 and Level-2 Hello packets sent and received on
IS-IS interfaces using the specified authentication mode and password.
NOTE:
You can configure a router to perform interface authentication in the following ways:
 A router sends authentication packets carrying the authentication TLV and verifies
the authentication information about the received packets.
 A router sends authentication packets carrying the authentication TLV but does not verify
the authentication information about the received packets.
 Area authentication: authenticates Level-1 LSPs and Level-1 SNPs transmitted in an IS-IS
area using the specified authentication mode and password.
 Routing domain authentication: authenticates Level-2 LSPs and Level-2 SNPs transmitted in an
IS-IS routing domain using the specified authentication mode and password.
NOTE:
In area authentication and routing domain authentication, you can configure a router to authenticate
LSPs and SNPs separately in the following ways:
 A router sends LSPs and SNPs carrying the authentication TLV and verifies the
authentication information about the received LSPs and SNPs.
 A router sends LSPs carrying the authentication TLV and verifies the authentication
information about the received LSPs. The router sends SNPs carrying the authentication
TLV
but does not verify the authentication information about the received SNPs.
 A router sends LSPs carrying the authentication TLV and verifies the authentication
information about the received LSPs. The router sends SNPs without the authentication
TLV
and does not verify the authentication information about the received SNPs.
 A router sends LSPs and SNPs carrying the authentication TLV but does not verify
the authentication information about the received LSPs and SNPs.
Based on the authentication modes of packets, authentication is classified into the following types:
 Plain text authentication: is a simple authentication mode in which passwords are directly
added to packets. This authentication is insecure.
 MD5 authentication: uses the MD5 algorithm to encrypt passwords before they are added
to packets, which improves password security.
 Keychain authentication: further improves network security with configurable key chain
that changes with time.
Mode in Which Authentication Information Is Carried
IS-IS provides a TLV to carry authentication information, with the type of the TLV specified as 10.
 Type: is defined by the ISO as 0, with a length of 1 byte.
 Length: indicates the length of the authentication TLV, which is 1 byte.
 Value: indicates the authentication contents of 1 to 254 bytes, including the authentication
type and password.
The authentication type is 1 byte:
 Type 0 is reserved.
 Type 1 indicates plain text authentication.
 Type 54 indicates MD5 authentication.
 Type 255 indicates routing domain private authentication methods.
2.4 IS-IS Route Leaking
Normally, Level-1 routers manage routes in Level-1 areas. All Level-2 and Level-1-2 routers form a
contiguous backbone area. Level-1 areas can only connect to the backbone area, but cannot connect
to each other.
A Level-1-2 router encapsulates learned Level-1 routing information into a Level-2 LSP and floods
the Level-2 LSP to other Level-2 and Level-1-2 routers. Then Level-1-2 and Level-2 routers know
routing information about the entire IS-IS routing domain. To reduce the size of routing tables, a
Level-1-2
router, by default, does not advertise the learned routing information of other Level-1 areas and the
backbone area to its Level-1 area. In this case, Level-1 routers cannot know routing information
outside the local area. As a result, Level-1 routers cannot select the optimal route to the destination
outside the local area.
IS-IS route leaking can solve this problem. You can configure access control lists (ACLs) and
routing policies and mark routes with tags on Level-1-2 routers to select eligible routes. Then a
Level-1-2 router can advertise routing information of other Level-1 areas and backbone area to its
Level-1 area.
Figure 2-4-1 IS-IS route leaking

In Figure 2-4-1, RouterA sends a packet to RouterF. The selected optimal route should be
RouterA->RouterB->RouterD->RouterE->RouterF. This is because the cost of this route is 40, which
is smaller than the cost (70) of the other route (RouterA->RouterC->RouterE->RouterF). However,
when you check the route on RouterA to view the path of the packets sent to RouterF, the selected
route is RouterA->RouterC->RouterE->RouterF but not the optimal route from RouterA to RouterF.
RouterA (Level-1 router) does not know routes outside its area, so it sends packets outside its area
through the default route generated by the nearest Level-1-2 router. Therefore, the optimal route is
not used to forward the packets.
If route leaking is enabled on Level-1-2 routers (RouterC and RouterD), Level-1 routers in Area 10 can
know routes outside Area 10 and passing through the two Level-1-2 routers. After route calculation,
the forwarding path becomes RouterA->RouterB->RouterD->RouterE->RouterF, which is the optimal
route from RouterA to RouterF.
2.5 IS-IS Overload
IS-IS Overload allows a device to use the IS-IS overload bit to identify the overload state. The IS-IS
overload bit is the OL field in an IS-IS LSP. After the overload bit is set on a device, other devices
ignore this device when performing SPF calculation and consider only the direct routes of the
device.
Figure 2-5-1 IS-IS Overload
As shown in Figure 2-5-1, RouterB forwards the packets sent from RouterA to network segment
1.1.1.0/24. If the overload bit in the LSP sent from RouterB is set to 1, RouterA considers the LSDB
of RouterB incomplete and sends packets to 1.1.1.0/24 through RouterD and RouterE. This process
does not affect the packets sent to the directly connected network segment of RouterB.
If a device cannot store new LSPs and fails to synchronize the LSDB, the routes calculated by this
device are incorrect. In this situation, the device enters the overload state and does not calculate
the routes passing through this device; however, the direct routes of the device are still valid.
A device may enter the overload state because of device abnormalities or is manually configured
to enter the overload state. When an IS-IS device on the network needs to be upgraded or maintained,
isolate this device from the network temporarily and set the overload bit on the device to prevent
other devices from using this device to forward traffic.
NOTE:
 If the system enters the overload state because of an abnormality, the system deletes all
the imported or leaked routes.
 If the system is configured to enter the overload state, the system determines whether to delete
all the imported or leaked routes based on the configuration.
2.6 IS-IS Route Management
Fast convergence and priority-based convergence can improve IS-IS network convergence.
Fast convergence speeds up network convergence by fast calculating routes, while priority-
based convergence sets different convergence priorities for routes to improve network
convergence.
2.6.1 Fast Convergence
IS-IS fast convergence is an extended feature of IS-IS that is implemented to speed up the
convergence of routes. Fast convergence includes the following:
 Incremental SPF (I-SPF): recalculates only the routes of the changed nodes rather than all
the nodes when the network topology changes. This speeds up the calculation of routes.
In ISO 10589, the SPF algorithm is used to calculate routes. When a node changes on the
network, this algorithm is used to recalculate all routes. The calculation takes a long time
and consumes too many CPU resources, which affects the convergence speed.
I-SPF improves this algorithm. Except for the first time, only changed nodes instead of all
nodes are involved in calculation. The shortest path tree (SPT) generated is the same as that
generated by the previous algorithm. This decreases CPU usage and speeds up network
convergence.
 Partial Route Calculation (PRC): calculates only the changed routes when the routes on
the network change.
Similar to I-SPF, PRC calculates only the changed routes, but it does not calculate the
shortest path. It updates routes based on the SPT calculated by I-SPF.
In route calculation, a leaf represents a route, and a node represents a router. If the SPT changes
after I-SPF calculation, PRC processes all the leaves only on the changed node. If the SPT
remains unchanged, PRC processes only the changed leaves. For example, if IS-IS is enabled
on an interface of a node, the SPT calculated by I-SPF remains unchanged. PRC updates only
the routes of this interface, consuming less CPU resources.
PRC working with I-SPF further improves the convergence performance of the network. It is
an improvement of the original SPF algorithm.
 Intelligent timer: applies to LSP generation and SPF calculation. 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 increases.
Although the route calculation algorithm is improved, the long interval for triggering route
calculation affects the convergence speed. Frequent network changes also consume too many
CPU resources. The SPF intelligent timer addresses both of these problems. In general, an IS-IS
network is stable under normal conditions. The probability of the occurrence of many network
changes is very minimal, and IS-IS does not calculate routes frequently. The period for
triggering the route calculation is very short (milliseconds). If the topology of the network
changes very often, the intelligent timer increases the interval for the calculation times to avoid
too much CPU consumption. The original mechanism uses a timer with uniform intervals,
which makes fast convergence and low CPU consumption impossible to achieve.
The LSP generation intelligent timer is similar to the SPF intelligent timer. When the LSP
generation intelligent timer expires, the system generates a new LSP based on the current
topology. The LSP generation timer is designed as an intelligent timer to respond to
emergencies (such as the interface is Up or Down) quickly and speed up the network
convergence.
 LSP fast flooding: speeds up the flooding of LSPs.
In most cases, when an IS-IS router receives new LSPs from other routers, it updates the LSPs
in its LSDB and periodically floods the updated LSPs according to a timer.
LSP fast flooding speeds up LSDB synchronization because it allows a device to flood fewer
LSPs than the specified number before route calculation when the device receives one or
more new LSPs. This mechanism also speeds up network convergence.
 Priority-based Convergence
Priority-based IS-IS convergence ensures that specific routes are converged first when a great
number of routes need to be converged. You can assign a high convergence priority to routes
for
key services so that these routes are converged quickly. This reduces the impact of route
convergence on key services. Different routes can be set with different convergence priorities
so that important routes can be converged first. This improves network reliability.
2.6.2 IS-IS Administrative Tag
Administrative tags control the advertisement of IP prefixes in an IS-IS routing domain to simplify
route management. You can use administrative tags to control the import of routes of different
levels and different areas and control IS-IS multi-instances running on the same router.
Figure 2-6-1 IS-IS networking
In Figure 2-6-1, RouterA in Area 4 needs to communicate with RouterB in Area 5, RouterC in Area
3, and RouterD in Area 2. To ensure information security, it is required that other routers in Level-1
areas (Areas 2, 3, and 5) should not receive the packets sent from RouterA. To meet this requirement,
configure the same administrative tag for IS-IS interfaces on RouterB, RouterC, and RouterD and
configure the Level-1-2 router in Area 4 to leak only the routes matching the configured
administrative tag from Level-2 to Level-1 areas. This allows RouterA to communicate with only
RouterB, RouterC, and RouterD. Figure 2-6-2 shows the topology formed on RouterA.
Figure 2-6-2 IS-IS administrative tag application
The value of an administrative tag is associated with certain attributes. If the cost style is wide,
wide-compatible or compatible, when IS-IS advertises an IP address prefix with these attributes, IS-
IS adds the administrative tag to the TLV in the prefix. The tag is flooded along with the prefix
throughout the routing domain.
2.6.3 IS-IS Wide Metric
In ISO 10589, the maximum IS-IS interface metric value can only be 63 and the IS-IS cost style is
narrow. A small range of metrics cannot meet the requirements on large-scale networks. Therefore, in
RFC 3784, the maximum IS-IS interface metric value can reach 16777215, and the maximum IS-
IS route metric value can reach 4261412864; in this case, the IS-IS cost style is wide.
 The following lists the TLVs used in narrow mode:
 TLV 128 (IP Internal Reachability TLV): carries IS-IS routes in a routing domain.
 TLV 130 (IP External Reachability TLV): carries IS-IS routes outside a routing domain.
 TLV 2 (IS Neighbors TLV): carries neighbor information.
 The following lists the TLVs used in wide mode:
 TLV 135 (Extended IP Reachability TLV): replaces the earlier IP reachability TLV
and carries IS-IS routing information. This TLV expands the route metric and carries
sub-TLVs.
 TLV 22 (IS Extended Neighbors TLV): carries neighbor information.
Table 2-6-1 lists the cost styles of received and sent IS-IS routing information. The cost styles of
received and sent IS-IS routing information vary according to the cost style configured on a
device.
Table 2-6-1 Cost styles of received and sent IS-IS routing information
Cost Style Configured on a Cost Style for Received IS-IS Cost Style for Sent IS-IS Routing
Device Routing Information Information
narrow narrow narrow
narrow-compatible narrow&wide narrow
compatible narrow&wide narrow&wide
wide-compatible narrow&wide wide
wide wide wide

NOTE:
When the cost-style is set to compatible, IS-IS sends the information in narrow mode and then in
wide mode.
IS-IS in wide mode and IS-IS in narrow mode cannot communicate. If IS-IS in wide mode and IS-IS in
narrow mode need to communicate, you must change the mode to enable all routers on the network to
receive packets sent by other routers.
2.7 IS-IS LSP Fragment Extension
When an IS-IS router needs to advertise the LSPs that contain much information, the IS-IS
router generates multiple LSP fragments to carry more IS-IS information.
IS-IS LSP fragments are identified by the LSP Number field in their LSP IDs. This field is of 1 byte.
An IS-IS process can generate a maximum of 256 LSP fragments; therefore, only a limited number
of routes can be carried.
As defined in RFC 3786, virtual system IDs can be configured and virtual LSPs that carry
routing information can be generated for IS-IS.
2.7.1 Concepts
 Originating system: is a router that runs the IS-IS protocol. A single IS-IS process can function
as multiple virtual routers to advertise LSPs, and the originating system refers to the IS-IS
process.
 Normal system ID: is the system ID of the originating system.
 Virtual system: is the system identified by the additional system ID to generate extended LSP
fragments. These fragments carry additional system IDs in their LSP IDs.
 Additional system ID: is assigned by network administrators to identify a virtual system. A

maximum of 256 extended LSP fragments can be generated for each additional system ID.
NOTE:
Like a normal system ID, an additional system ID must be unique in a routing domain.
 TLV 24 (IS Alias ID TLV): describes the relationship between the originating system and
virtual system.
2.7.2 Principles
In IS-IS, each system ID identifies a system, which can generate a maximum of 256 LSP
fragments. With more additional system IDs (up to 50 virtual systems can be configured), an IS-IS
process can generate a maximum of 13,056 LSP fragments.
After LSP fragment extension is configured, the system prompts you to restart the IS-IS process if
information is lost because LSPs overflow. After being restarted, the originating system loads as
much routing information to LSPs, adds the overloaded information to the LSPs of the virtual system
for transmission, and uses TLV 24 to notify other routers of its relationship with the virtual system.
Operating Modes
An IS-IS router can run the LSP fragment extension feature in two modes.
Figure 2-7-1 IS-IS LSP fragment extension
Table 2-7-1 ISIS Routers Operating Modes
Operating Usage Principles Example Precautions

Mode Scenario
Virtual systems In Figure 2-7-1, RouterB The LSP sent by a

Mode-1 Some does not support LSP
routers on participate in SPF virtual system contains
calculation. The fragment extension, and the same area address
the RouterA is configured to
network originating system and overload bit as
advertises LSPs support LSP fragment those in a common LSP.
do not extension in mode-1.
support containing information If the LSPs sent by a
about links to each RouterA1 and RouterA2 virtual system contain
LSP are virtual systems of
fragment virtual system. TLVs specified in other
Similarly, each virtual RouterA and send LSPs features, these TLVs
extension. carrying some routing
system advertises LSPs must be the same as
containing information information of RouterA. those in common LSPs.
about links to the After receiving LSPs The virtual system
originating system. from RouterA, carries neighbor
Table 2-7-1 ISIS Routers Operating Modes
Operating Usage Principles Example Precautions

Mode Scenario
Virtual systems look RouterA1, and information indicating

like the physical routers RouterA2, RouterB that the neighbor is the
that connect to the considers that there are originating system, with
originating system. three individual routers the metric equal to the
Mode-1 is a transitional at the remote end and maximum value minus
mode for the earlier calculates routes. 1. The originating
versions that do not Because the cost of the system carries neighbor
support LSP fragment route from RouterA to information indicating
extension. In earlier RouterA1 and the cost of that the neighbor is the
versions, IS-IS cannot the route from RouterA virtual system, with the
identify the IS Alias ID to RouterA2 are both 0, metric 0. This ensures
TLV and processes the the cost of the route from that the virtual system is
received LSP that is RouterB to RouterA is the downstream node of
advertised by a virtual the same as the cost of the originating system
system as an LSP the route from RouterB when other routers
advertised by an IS-IS to RouterA1. calculate routes.
process.
Mode-2 All the Virtual systems do not In Figure 2-7-1, RouterB -

routers on participate in SPF supports LSP fragment
the calculation. All the extension, and RouterA
network routers on the network is configured to support
support know that the LSPs LSP fragment extension
LSP generated by virtual in mode-2. RouterA1 and
fragment systems actually belong RouterA2 are virtual
extension. to the originating systems of RouterA and
system. send LSPs carrying some
An IS-IS router working routing information of
in mode-2 can identify RouterA. When receiving
the IS Alias ID TLV, LSPs from RouterA1 and
which is used as a RouterA2, RouterB
reference for calculating obtains the IS Alias ID
the SPT and routes. TLV and knows that the
originating system of
RouterA1 and RouterA2
is RouterA. RouterB then
considers that
information advertised
by RouterA1 and
RouterA2 belongs to
RouterA.
NOTE:
When the originating system and virtual system send the LSPs with fragment number 0, the LSPs
must carry the IS Alias ID TLV to indicate the originating system regardless of the operation mode
(mode-1 or mode-2).
2.8 IS-IS Host Name Mapping
The IS-IS host name mapping mechanism maps host names to system IDs for IS-IS devices, including
dynamic host name mapping and static host name mapping. Dynamic host name mapping takes
precedence over static host name mapping. When both a dynamic host name and a static host name
are configured, the dynamic host name takes effect.
On an IS-IS router where host name exchange is disabled, information about IS-IS neighbors and
LSDBs shows that each device in an IS-IS routing domain is identified by a system ID with 12-digit
hexadecimal number, for example, aaaa.eeee.1234. This device identification method is complex
and not easy to use. The host name exchange mechanism facilitates IS-IS network management and
maintenance.
The system ID is replaced by a host name in the following situations:
 When an IS-IS neighbor is displayed, the system ID of the IS-IS neighbor is replaced by its
host name. When the neighbor is the DIS, the system ID of the DIS is also replaced by its host
name.
 When an LSP in the IS-IS LSDB is displayed, the system ID in the LSP ID is replaced by
the host name of the IS-IS device that advertises the LSP.
 When details about the IS-IS LSDB are displayed, the Host Name field is added to the LSP
generated by the device where dynamic host name exchange is enabled, and the system ID in
the Host Name field is replaced by the dynamic host name of the device that generates the LSP.
Dynamic Host Name Mapping
On a device where dynamic host name mapping is enabled, dynamic host name information is
advertised as TLV 137 (Dynamic Hostname TLV) in LSPs. When you run IS-IS commands on other
devices to view IS-IS information, the system ID of the local device is replaced by the configured
host name. The host name is easier to identify and memorize than the system ID.
The Dynamic Hostname TLV is optional and can be inserted anywhere in an LSP. The value of this
TLV cannot be empty. A device can determine whether to send LSPs carrying TLV 137, while the
device that receives LSPs can determine whether to ignore TLV 137 or whether to obtain TLV 137
for its mapping table.
Static Host Name Mapping
Static host name mapping allows you to configure the mapping between host names and system IDs
of other IS-IS devices on a device. Static host name mapping takes effect only on the local device and
is not advertised using LSPs.
2.9 IS-IS Reliability
As networks develop, services have higher network requirements. IS-IS provides high reliability to
ensure uninterrupted service forwarding when a network fault occurs or when network devices
need maintenance.
IS-IS reliability includes hot standby, non-stop routing (NSR), batch backup, and real-time
backup, IS-IS GR, BFD for IS-IS, and IS-IS Auto FRR.
In hot standby, IS-IS backs up data from the Active Main Board (AMB) to the Standby Main
Board (SMB). Whenever the AMB fails, the SMB becomes active and takes over the tasks of the
AMB to ensure normal IS-IS running. This improves IS-IS reliability.
IS-IS information backup includes data backup and command line backup:
 Data backup: The system backs up data of processes and interfaces.
Data backup ensures the same IS-IS data on the AMB and SMB. When an AMB/SMB
switchover occurs, neighbors do not detect the switchover.
 Command line backup: The system backs up the command lines that are successfully
executed on the AMB to the SMB.
Whether to send command lines to the SMB for processing is determined by the the execution
results of command lines on the AMB. If command lines are successfully executed on the
AMB, the command lines are sent to the SMB for processing. Otherwise, the command lines
are not sent to the SMB and the command line execution failure is logged. If the command
lines fail to be executed on the SMB, this failure is logged.
The AMB sends only the successfully executed command lines to the SMB for processing. If a
fault occurs on the AMB, IS-IS neighbor relationships on the device need to be established
again after the AMB/SMB switchover is performed.
Hot Standby
Devices with distributed architecture support IS-IS hot standby.
In IS-IS hot standby, IS-IS configurations on the AMB and SMB are consistent. When an
AMB/SMB switchover occurs, the new AMB performs GR and resends a request for establishing
neighbor relationships to neighbors to synchronize its LSDB. This prevents traffic transmission from
being affected.
NSR
NSR ensures continuous service forwarding on a device when a hardware or software failure occurs
on the device. NSR uses data backup to ensure that a neighbor of a device does not detect the fault on
the AMB of the device that provides the SMB. NSR ensures that the neighbor relationships
established using routing protocols, MPLS, and other protocols that transmit services are not
interrupted when a device fault occurs.
IS-IS NSR ensures that data is synchronized in real time between the AMB and SMB. When the
AMB/SMB switchover occurs, the SMB can rapidly take over services on the AMB. This ensures
that neighbors do not detect device faults.
Batch Backup
 Batch data backup
When the SMB is installed, all data of the AMB is backed up to the SMB at a time.
No configuration can be changed during batch backup.
 Batch command line backup
When the SMB is installed, all configurations of the AMB are backed up to the SMB at a
time. No configuration can be changed during batch backup.
Real-time Backup
 Real-time data backup
Changed data of processes and interfaces are backed up in real time to the SMB.
 Real-time command line backup
The command lines that are executed successfully on the AMB are backed up to the SMB.
2.10 IS-IS GR
IS-IS graceful restart (GR) is a high availability technology that implements non-stop data
forwarding. After the master/slave switchover, no neighbor information is stored on the restarted
router. The first

Hello packets sent by the router after restart do not contain the neighbor list. After receiving the Hello
packets, the neighbor checks the two-way neighbor relationship and detects that it is not in the
neighbor list of the Hello packets sent by the router. The neighbor relationship is interrupted. The
neighbor then generates new LSPs and floods the topology changes to all other routers in the area.
Routers in the area calculate routes based on the new LSDBs, which leads to route interruption or
routing loops.
The IETF defined the GR standard, RFC 3847, for IS-IS. The restart of the protocol is processed for
both the reserved FIB tables and unreserved FIB tables. Therefore, the route flapping and
interruption of the traffic forwarding caused by the restart can be avoided.
2.10.1 Concepts
IS-IS GR involves two roles, namely, GR restarter and GR helper.
 GR restarter: is a device that has the GR capability and restarts in GR mode.
 GR helper: is a device that has the GR capability and helps the GR restarter complete the GR
process. The GR restarter must have the GR helper capability.
To implement GR, IS-IS uses TLV 211 (restart TLV) and three timers, T1, T2, and T3.
Restart TLV
The restart TLV is an extended part of an IS-to-IS Hello (IIH) PDU. All IIH packets of the router
that supports IS-IS GR contain the restart TLV. The restart TLV carries the parameters for the
protocol restart. Figure 2-10-1 shows the format of the restart TLV.
Figure 2-10-1 Restart TLV
Table 2-10-1 describes the fields of the restart TLV.
Table 2-10-1 Restart TLV fields
Field
Type 1b
Length 1b
RR 1b
RA 1b
SA 1b
Remaining 2b
Time
2.10.2 Timers
Three timers are introduced to enhance IS-IS GR: T1, T2, and T3.
 T1: If the GR restarter has already sent an IIH packet with RR being set but does not receive any
IIH packet that carries the restart TLV and the RA set from the GR helper even after the T1
timer expires, the GR restarter resets the T1 timer and continues to send the restart TLV. If the
ACK packet is received or the T1 timer expires three times, the T1 timer is deleted. The default
value
of a T1 timer is 3 seconds.
Any interface enabled with IS-IS GR maintains a T1 timer. On a Level-1-2 router,
broadcast interfaces maintain a T1 timer for Level-1 and Level-2 neighbor relationships.
 T2: is the time from when the GR restarter restarts until the LSDBs of all devices of the same
level are synchronized. T2 is the maximum time that the system waits for synchronization of
all LSDBs. T2 is generally 60 seconds.
Level-1 and Level-2 LSDBs maintain their respective T2 timers.
 T3: is the maximum time during which the GR restarter performs GR. The T3 initial value is
65535 seconds. After the IIH packets that carry the RA are received from neighbors, the T3
value becomes the smallest value among the Remaining Time fields of the IIH packets. If the T3
timer expires, GR fails.
The entire system maintains a T3 timer.
2.10.3 Session Mechanism
For differentiation, GR triggered by the master/slave switchover or the restart of an IS-IS process is
referred to as restarting. In restarting, the FIB table remains unchanged. GR triggered by router
restart is referred to as starting. In starting, the FIB table is updated.
The following describes the process of IS-IS GR in restarting and starting modes:
 Figure 2-10-2 shows the process of IS-IS restarting.
Figure 2-10-2 IS-IS restarting

1. After performing the protocol restart, the GR restarter performs the following actions:
 Starts T1, T2, and T3 timers.

 Sends IIH packets that contain the restart TLV from all interfaces. In such a
packet, RR is set to 1, and RA and SA are set to 0.
2. After receiving an IIH packet, the GR helper performs the following actions:
 Maintains the neighbor relationship and refreshes the current Holdtime.
 Replies with an IIH packet containing the restart TLV. In the packet, RR is set to
0; RA is set to 1, and the value of the Remaining Time field indicates the period
from the current moment to the timeout of the Holdtime.
 Sends CSNPs and all LSPs to the GR restarter.
NOTE:
On a P2P link, a neighbor must send CSNPs.

On a LAN link, only the neighbor of the DIS sends CSNPs. If the DIS is restarted, a
temporary DIS is elected from the other routers on the LAN.
If the neighbor does not have the GR helper capability, it ignores the restart TLV
and resets the adjacency with the GR restarter according to normal IS-IS processing.
3. After the GR restarter receives the IIH response packet, in which RR is set to 0 and RA
is set to 1, from the neighbor, it performs the following actions:
 Compares the current value of the T3 timer with the value of the Remaining
Time field in the packet. The smaller value is taken as the value of the T3 timer.
 Deletes the T1 timer maintained by the interface that receives the ACK packet and
CSNPs.
 If the interface does not receive the ACK packet or CSNPs, the GR restarter
constantly resets the T1 timer and resends the IIH packet that contains the restart
TLV. If the number of timeouts of the T1 timer exceeds the threshold value, the
GR restarter forcibly deletes the T1 timer and turns to the normal IS-IS processing
to complete LSDB synchronization.
4. After the GR restarter deletes the T1 timers on all interfaces, the synchronization with
all neighbors is complete when the CSNP list is cleared and all LSPs are collected. The
T2 timer is then deleted.
5. After the T2 timer is deleted, the LSDB of the level is synchronized.
 In the case of a Level-1 or Level-2 router, SPF calculation is triggered.
 In the case of a Level-1-2 router, determine whether the T2 timer on the router of
the other level is also deleted. If both T2 timers are deleted, SPF calculation is
triggered. Otherwise, the router waits for the T2 timer of the other level to
expire.
6. After all T2 timers are deleted, the GR restarter deletes the T3 timer and updates the
FIB table. The GR restarter re-generates the LSPs of each level and floods them.
During LSDB synchronization, the GR restarter deletes the LSPs generated before
restarting.
7. At this point, the IS-IS restarting of the GR restarter is complete.

 The starting device does not retain the FIB table. The starting device depends on the neighbors,
whose adjacency with itself is Up before it starts, to reset their adjacency and suppress the
neighbors from advertising their adjacency. The IS-IS starting process is different from the IS-
IS restarting process, as shown in Figure 2-10-3.
Figure 2-10-3 IS-IS starting
1. After the GR restarter is started, it performs the following actions:
 Starts the T2 timer for the synchronization of LSDBs of each level.
 Sends IIH packets that contain the restart TLV from all interfaces.
If RR in the packet is set to 0, a router is started.
If SA in the packet is set to 1, the router requests its neighbor to suppress the
advertisement of their adjacency before the neighbor receives the IIH packet in
which SA is set to 0.
2. After the neighbor receives the IIH packet that carries the restart TLV, it performs
the following actions depending on whether GR is supported:
 GR is supported.
Re-initiates the adjacency.

Deletes the description of the adjacency with the GR restarter from the sent LSP.
The neighbor also ignores the link connected to the GR restarter when performing
SPF calculation until it receives an IIH packet in which SA is set to 0.
 GR is not supported.
Ignores the restart TLV and resets the adjacency with the GR restarter.
Replies with an IIH packet that does not contain the restart TLV. The neighbor then
returns to normal IS-IS processing. In this case, the neighbor does not suppress the
advertisement of the adjacency with the GR restarter. On a P2P link, the neighbor
also sends a CSNP.
3. After the adjacency is re-initiated, the GR restarter re-establishes the adjacency with the
neighbors on each interface. When an adjacency set on an interface is in the Up state, the
GR restarter starts the T1 timer for the interface.
4. After the T1 timer expires, the GR restarter sends an IIH packet in which both RR and SA
are set to 1.
5. After the neighbor receives the IIH packet, it replies with an IIH packet, in which RR is
set to 0 and RA is set to 1, and sends a CSNP.
6. After the GR restarter receives the IIH ACK packet and CSNP from the neighbor, it
deletes the T1 timer.
If the GR restarter does not receive the IIH packet or CSNP, it constantly resets the T1
timer and resends the IIH packet in which RR and SA are set to 1. If the number of the
timeouts of the T1 timer exceeds the threshold value, the GR restarter forcibly deletes the
T1 timer and turns to the normal IS-IS processing to complete LSDB synchronization.
7. After receiving the CSNP from the helper, the GR restarter synchronizes the LSDB.
8. After the LSDB of this level is synchronized, the T2 timer is deleted.
9. After all T2 timers are deleted, the SPF calculation is started and LSPs are regenerated
and flooded.
10. At this point, the IS-IS starting of the GR restarter is complete.
2.11 BFD for IS-IS
In IS-IS, the interval for sending Hello packets is 10s, and the holddown time for keeping the
neighbor relationship is three times the interval for sending Hello packets. If a router does not receive
a Hello packet from its neighbor within the holddown time, the router deletes the corresponding
neighbor relationship. This indicates that the router detects neighbor faults in seconds. Second-level
fault detection, however, may result in heavy packet loss on high-speed networks.
Bidirectional forwarding detection (BFD) provides light-load and millisecond-level link fault
detection to prevent heavy packet loss. BFD is not used to substitute the Hello mechanism of IS-IS but
helps
IS-IS rapidly detect the faults on neighbors or links and instructs IS-IS to recalculate routes for
packet forwarding.
In Figure 2-11-1, basic IS-IS functions are configured on every router, and BFD for IS-IS is
enabled on RouterA and RouterB.
Figure 2-11-1 BFD for IS-IS

When a fault occurs on the primary link (RouterA->RouterD->RouterB), BFD fast detects the fault
and reports it to IS-IS. IS-IS sets the neighbors of the interface on the faulty link to Down, which
triggers topology calculation, and updates LSPs so that neighbors such as RouterC can receive the
updated
LSPs from RouterB. This process implements fast network convergence.
2.11.1 Classification of BFD for IS-IS
BFD for IS-IS includes static BFD for IS-IS and dynamic BFD for IS-IS.
Table 2-11-1 Two implementation modes for BFD for IS-IS
Implementation
Mode
Static BFD for

IS-IS
Dynamic BFD
for IS-IS
Table 2-11-1 Two implementation modes for BFD for IS-IS
Implementation Principles Differences
Mode
When detecting faults, BFD informs trigger the setup of BFD sessions,
IS-IS of the faults through the preventing the configuration errors caused
routing management (RM) module. by manual configuration. Dynamic BFD is
IS-IS then turns the neighbors Down, easy to configure and applies to the
rapidly advertises the changed LSPs, scenarios where BFD needs to be configured
and performs incremental SPF. This on the entire network.
implements fast route convergence.
NOTE:
BFD uses local and remote discriminators to differentiate multiple BFD sessions between the same
pair of systems.
Because IS-IS establishes only single-hop neighbors, BFD for IS-IS detects only single-hop
links between IS-IS neighbors.
2.11.2 Establishment and Deletion of BFD Sessions
The RM module provides related services for association with the BFD module for IS-IS. Through
RM, IS-IS prompts BFD to set up or tear down BFD sessions by sending notification messages. In
addition, BFD events are transmitted to IS-IS through RM.
Conditions for setting up a BFD session
 Basic IS-IS functions are configured on each router and IS-IS is enabled on the interfaces of
the routers.
 BFD is globally enabled on each router, and BFD is enabled on a specified interface or process.
 BFD is enabled on interfaces or processes, and the neighbors are Up. A DIS needs to be
elected on a broadcast network.
Process of setting up a BFD session
 P2P network
After the conditions for setting up a BFD session are satisfied, IS-IS instructs BFD through RM
to directly set up a BFD session between neighbors.
 Broadcast network
After the conditions for establishing BFD sessions are met, and the DIS is elected, IS-IS instructs
BFD through RM to establish a BFD session between the DIS and each router. No BFD
session is established between non-DISs.
NOTE:
On a broadcast network, routers (including non-DIS routers) of the same level on a

network segment can establish neighbor relationships. In the implementation of BFD for IS-IS,
however, BFD sessions are established only between a DIS and a non-DIS. On a P2P network,
BFD sessions are directly established between neighbors.
If a Level-1-2 neighbor relationship is set up between two routers on a link, IS-IS sets up two BFD
sessions for the Level-1 and Level-2 neighbors on a broadcast network, but sets up only one BFD
session on a P2P network.
Conditions for tearing down a BFD session
 P2P network
When a neighbor relationship that was set up on P2P interfaces by IS-IS is down (that is, the
neighbor relationship is not in the Up state) or when the IP protocol type of a neighbor is
deleted, IS-IS tears down the BFD session.
 Broadcast network
When a neighbor relationship that was set up on P2P interfaces by IS-IS is torn down (that is,
the neighbor relationship is not in the Up state), when the IP protocol type of a neighbor is
deleted,
or when the DIS is re-elected, IS-IS tears down the BFD session.
NOTE:
After dynamic BFD is globally disabled in an IS-IS process, the BFD sessions on all the interfaces
in this IS-IS process are deleted.
2.11.3 IS-IS Responding to BFD Session Down Event
When detecting a link failure, BFD generates a Down event, and then notifies RM of th e event.
RM then instructs IS-IS to deletes the neighbor relationship. IS-IS recalculates routes to speed up
route convergence on the entire network.
When both the local router and its neighbor are Level-1-2 routers, they establish two neighbors of
different levels. Then IS-IS establishes two BFD sessions for the Level-1 neighbor and Level-2
neighbor respectively. When BFD detects a link failure, it generates a Down event and informs the
RM module of the event. The RM module then instructs IS-IS to delete the neighbor relationship of a
specific level.
2.12 IS-IS Auto FRR
With the development of networks, the services such as Voice over IP (VoIP) and online video
services require high-quality real-time transmission. Nevertheless, if an IS-IS link fault occurs, traffic
can be switched to a new link only after the processes, including fault detection, LSP update, LSP
flooding, route calculation, and FIB entry delivery, are complete. As a result, it takes much more than
50ms to rectify the fault, which cannot meet the requirement for real-time transmission services on the
network.
Complying with RFC 5286 (Basic Specification for IP Fast Reroute Loop-Free Alternates), IS-IS
Auto FRR protects traffic when links or nodes become faulty. IS-IS Auto FRR allows the forwarding
system to rapidly detect such faults and take measures to restore services as soon as possible.
In most cases, you can bind BFD to IS-IS Auto FRR to ensure that the fault recovery time is within
50ms. When BFD detects a link fault on an interface, the BFD session goes Down, triggering FRR
on the interface. Subsequently, traffic is switched from the faulty link to the backup link, which
protects services.
2.12.1 Principles
IS-IS Auto FRR pre-computes a backup link by using the Loop-Free Alternate (LFA) algorithm, and
then adds the backup link and the primary link to the forwarding table. In the case of an IS-IS network
failure, IS-IS Auto FRR can fast switch traffic to the backup link before routes on the control plane
converge. This ensures normal transmission of traffic and improves the reliability of the IS-IS
network.
The backup link is calculated through the LFA algorithm. With the neighbor that can provide the
backup link being the root, the shortest path to the destination node is calculated by a device through
the SPF algorithm. Then, the loop-free backup link is calculated according to the inequality defined
in RFC 5286.
IS-IS Auto FRR can filter backup routes that need to be added to the IP routing table. Only the
backup routes matching the filtering policy are added to the IP routing table. In this manner, users
can flexibly control the addition of IS-IS backup routes to the IP routing table.
2.12.2 Applications
IS-IS Auto FRR support traffic engineering (TE) links, including the following types:
 IP protecting TE
As shown in Figure 2-12-1, the TE tunnel has the smallest IS-IS cost among the paths from
Router S to Router D. Therefore, Router S selects the TE tunnel as the primary path to Router
D. The path Router S->Router N->Router D has the second smallest cost. According to the LFA
algorithm, Router S selects the path Router S->Router N->Router D as the backup path. The
outbound interface of the backup path is the interface that connects Router S to Router N.
NOTE:
If the outbound interface of the backup link is the actual outbound interface of the TE tunnel, IP
protecting TE fails.
Figure 2-12-1 IP protecting TE
 TE protecting IP
As shown in Figure 2-12-2, the physical path Router S-->Router N-->Router D has the smallest
IS-IS metric among the paths from Router S to Router D. Therefore, Router S prefers the path
Router S-->Router N-->Router D as the primary path from Router S to Router D. The IS-IS cost
of the TE tunnel is 12, and the explicit path of the TE tunnel is the direct link from Router S to
Router D. The IS-IS metric of the direct link from Router S to Router D is 13, which is greater
than the IS-IS metric of the TE tunnel. Therefore, IS-IS selects the TE tunnel as the backup
path. TE protecting IP is implemented.
Figure 2-12-2 TE protecting IP

IS-IS Auto FRR traffic protection is classified into link protection and link-node dual protection.
Figure 2-12-3 IS-IS Auto FRR link protection
Figure 2-12-4 IS-IS Auto FRR link-node dual protection

Table 2-12-1 IS-IS Auto FRR traffic protection
Traffic Object Condition Application Example
Protection Protected
Type
Link Traffic The link cost must satisfy the following In Figure 2-12-3, traffic is
protection passing inequality: transmitted from RouterS to
through a Distance_opt(N,D) < Distance_opt(N,S) + RouterD. The link cost
specific Distance_opt(S,D) satisfies the link protection
link inequality. When the primary
link fails, RouterS switches the
traffic to the backup link
RouterS->RouterN so that the
traffic can be further
transmitted along downstream
paths. This ensures that the
traffic interruption time is
within 50 ms.
Link-node Next-hop Link-node dual protection must satisfy the
In Figure 2-12-3, traffic is
dual node or following conditions: transmitted along the path
protection link from
 The link cost must satisfy the RouterS->RouterE->RouterD.
the local The link cost satisfies the link
node to the following inequality: protection inequality. When
next-hop Distance_opt(N,D) < RouterE or the link between
node. Distance_opt(N,S) + RouterS and RouterE fails,
Node Distance_opt(S,D) RouterS switches the traffic to
protection the backup link
takes  The interface cost of the router
RouterS->RouterN so that the
precedence must satisfy the following traffic can be further
over link transmitted along downstream
inequality:
protection. paths. This ensures that the
Distance_opt(N,D) < traffic interruption time is
Distance_opt(N,E) + within 50 ms.
Distance_opt(E,D)
NOTE:
In Table 2-12-1 Distance_opt(X,Y) indicates the cost of the optimal path between node X and node
Y. S indicates the source node of traffic; E indicates the faulty node; N indicates the node on the
backup link; D indicates the destination node of traffic.
2.13 IS-IS Multi-Instance and Multi-Process
On a VPN-supporting device, you can associate multiple VPN instances with multiple IS-IS processes
to implement IS-IS multi-instance. IS-IS multi-process allows you to create multiple IS-IS processes
in the same VPN (or on the public network). These IS-IS processes are independent of each other.
Route exchange between IS-IS processes is similar to route exchange between routing protocols.
Each IS-IS process can be bound to a specified VPN instance. A typical application is as follows: In
a VPN, IS-IS runs between PEs and CEs and also runs on the VPN backbone network. On the PEs,
the two IS-IS processes are independent of each other.
IS-IS multi-instance and multi-process have the following characteristics:
 IS-IS multi-processes share an RM routing table. IS-IS multi-instances use the RM routing
tables in VPNs, and each VPN has its own RM routing table.
 IS-IS multi-process allows a set of interfaces to be associated with a specified IS-IS process.
This ensures that the specified IS-IS process performs all the protocol operations only on this set
of interfaces. In this manner, multiple IS-IS processes can work on a single router and each
process is responsible for managing a unique set of interfaces.
 When creating an IS-IS process, you can bind it to a VPN instance to associate the IS-IS
process with the VPN instance. The IS-IS process 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.
2.14 IS-IS IPv6
IS-IS is a link-state dynamic routing protocol initially designed by the OSI. To support IPv4
routing, IS-IS is applied to IPv4 networks and called as Integrated IS-IS.
As IPv6 networks are built, IS-IS also needs to provide accurate routing information for IPv6
packet forwarding. IS-IS has good scalability, supports IPv6 network layer protocols, and is
capable of discovering, generating, and forwarding IPv6 routes.
Extended IS-IS for IPv6 is defined in the draft-ietf-isis-ipv6-05.txt of the IETF. To process and
calculate IPv6 routes, IS-IS uses two new TLVs and one network layer protocol identifier
(NLPID).
The two TLVs are as follows:
 TLV 236 (IPv6 Reachability): describes network reachability by defining the route prefix
and metric.
 TLV 232 (IPv6 Interface Address): is similar to the IP Interface Address TLV of IPv4,
except that it changes a 32-bit IPv4 address to a 128-bit IPv6 address.
The NLPID is an 8-bit field that identifies the protocol packets of the network layer. The NLPID of
IPv6 is 142 (0x8E). If IS-IS supports IPv6, it advertises routing information through the NLPID value.
2.14.1 IS-IS MT
During the transition from IPv4 networks to IPv6 networks, IPv4 topologies and IPv6 topologies
must coexist for a long time. The IPv4/IPv6 dual stack is a widely used technology that is applicable
to IPv4 networks and IPv6 networks. The function is that a router that supports only IPv4 or IPv6 can
communicate with a router that supports both IPv4 and IPv6.
Background
IS-IS implements IPv6 by extending TLV and complies with the rules for establishing and
maintaining neighbor databases and topology databases as defined in ISO 10589 and RFC 1195. As a
result, IPv4 networks and IPv6 networks have the same topology. The mixed topology of IPv4 and
IPv6 is
considered as an integrated topology, which utilizes the SPT to perform the SPF calculation.
This requires that IPv6 and IPv4 topology information should be consistent.
In actual applications, the deployment of IPv4 and IPv6 may be different on the network; therefore,
information about IPv4 topologies may be different from information about IPv6 topologies. Some
routers and links in a mixed topology do not support IPv6. However, routers that support the
IPv4/IPv6 dual stack in the mixed topology cannot sense the routers or links, and still forward IPv6
packets to them. As a result, the IPv6 packets are discarded. Similarly, when routers and links that do
not support IPv4 exist in the topology, IPv4 packets cannot be forwarded.
IS-IS multi-topology (MT) can be used to solve the preceding problems. IS-IS MT is an extension of
IS-IS to support multiple topologies, complying with draft-ietf-IS-IS-wg-multi-topology. IS-IS MT
defines new TLVs in IS-IS packets, transmits MT information, and performs separate SPF
calculation in different topologies.
Principles
IS-IS MT refers to multiple separate IP topologies that are run in an IS-IS AS, such as IPv4 topology
and IPv6 topology. The separate IP topologies are not considered as an integrated and single
topology. This is helpful for calculating IS-IS routes of separate IPv4 networks and IPv6 networks.
Based on the IP protocols supported by links, separate SPF calculation is performed in different
topologies to shield networks from each other.
Figure 2-14-1 shows the IS-IS MT. Values in Figure 2-14-1 indicate link costs. RouterA, RouterC,
and RouterD support the IPv4/IPv6 dual stack. RouterB supports only IPv4 and cannot forward
IPv6 packets.
If RouterA does not support IS-IS MT, only the single topology is considered during SPF
calculation. The shortest path from RouterA to RouterC is RouterA->RouterB->RouterC. However,
RouterB does not support IPv6. IPv6 packets sent from RouterA cannot be forwarded by RouterB to
RouterC.
If IS-IS MT is enabled on RouterA, RouterA performs SPF calculation in different topologies.

When RouterA needs to send IPv6 packets to RouterC, RouterA chooses only IPv6 links to forward
IPv6 packets. The shortest path from RouterA to RouterC changes to RouterA->RouterD->RouterC.
IPv6 packets are then forwarded.
Figure 2-14-1 IS-IS MT networking
IS-IS MT is implemented as follows:
1. Setting up topologies: Neighbors are set up by exchanging various packets for setting up
MTs.
2. Performing the SPF calculation: The SPF calculation is performed for different MTs.
2.15 Examples for Configuring of ISIS
2.15.1 Example for Configuring Basic IS-IS Functions
As shown in Figure 2-15-1, there are four routers (RouterA, RouterB, RouterC, and RouterD) on
the network. The four routers need to communicate with each other. RouterA and RouterB can only
process a small amount of data because they have lower performance than the other two routers.
Figure 2-15-1 Networking diagram of configuring basic IS-IS functions
1. Enable IS-IS on each router so that the routers can be interconnected. Configure RouterA
and
RouterB as Level-1 routers to enable them to maintain less data.
Procedure
1. Configure IP addresses for interfaces on each router.


The configurations of RouterB, RouterC and RouterD are similar to the configuration of
2. Configure basic IS-IS functions.
[RouterA] isis 1
[RouterA-isis-1] is-level level-1
[RouterA-isis-1] network-entity 10.0000.0000.0001.00
[RouterA-isis-1] quit
[RouterA-GigabitEthernet1/0/0] isis enable 1
[RouterA-GigabitEthernet1/0/0] quit
[RouterB] isis 1
[RouterB-isis-1] is-level level-1
[RouterB-isis-1] network-entity 10.0000.0000.0002.00
[RouterB-isis-1] quit
[RouterB] interface gigabitethernet 1/0/0
[RouterB-GigabitEthernet1/0/0] isis enable 1
[RouterB-GigabitEthernet1/0/0] quit
[RouterC] isis 1
[RouterC-isis-1] network-entity 10.0000.0000.0003.00
[RouterC-isis-1] quit
[RouterC] interface gigabitethernet 1/0/0
[RouterC-GigabitEthernet1/0/0] isis enable 1
[RouterC-GigabitEthernet1/0/0] quit
[RouterD] isis 1
[RouterD-isis-1] is-level level-2
[RouterD-isis-1] network-entity 20.0000.0000.0004.00
[RouterD-isis-1] quit
[RouterD] interface gigabitethernet 2/0/0
[RouterD-GigabitEthernet2/0/0] isis enable 1
[RouterD-GigabitEthernet2/0/0] quit
# View the IS-IS LSDB of each Router to check whether the IS-IS LSDBs of the Routers
are synchronized.
[RouterA] display isis lsdb
Database information for ISIS(1)

--------------------------------
Level-1 Link State Database
LSPID Seq Num Checksum Holdtime Length

ATT/P/OL
-------------------------------------------------------------------------
0000.0000.0001.00-00* 0x00000006 0xbf7d 649 68 0/0/0
0000.0000.0001.01-00* 0x00000002 0xcfbb 1157 55 0/0/0
0000.0000.0002.00-00 0x00000003 0xef4d 545 68 0/0/0
0000.0000.0003.00-00 0x00000008 0x3340 582 111 1/0/0
Total LSP(s): 4
*(In TLV)-Leaking Route, *(By LSPID)-Self LSP, +-Self LSP(Extended),
ATT-Attached, P-Partition, OL-Overload
[RouterB] display isis lsdb

--------------------------------

ATT/P/OL
-------------------------------------------------------------------------
2016-1-11 Huawei Confidential Page 6161 of

1210
0000.0000.0001.00-00 0x00000006
0000.0000.0002.00-00* 0x00000003
0000.0000.0002.01-00* 0x00000003
0000.0000.0003.00-00 0x00000008
Total LSP(s): 4
[RouterC] display isis lsdb

--------------------------------

ATT/P/OL
-------------------------------------------------------------------------
0000.0000.0001.00-00
0000.0000.0001.01-00
0000.0000.0002.00-00
0000.0000.0003.00-00*
Total LSP(s): 4


ATT/P/OL
-------------------------------------------------------------------------
0000.0000.0003.00-00* 0x00000008 0x55bb 650 100 0/0/0
0000.0000.0004.00-00 0x00000005 0x6510 629 84 0/0/0
0000.0000.0004.01-00 0x00000001 0xee95 803 55 0/0/0
Total LSP(s): 3
[RouterD] display isis lsdb

--------------------------------

ATT/P/OL
-------------------------------------------------------------------------
0000.0000.0003.00-00 0x00000008 0x55bb 644 100 0/0/0
0000.0000.0004.00-00* 0x00000005 0x6510 624 84 0/0/0
0000.0000.0004.01-00* 0x00000001 0xee95 700 55 0/0/0
Total LSP(s): 3
# View the IS-IS routing information of each Router. The routing table of a Level-1 router
contains a default route with the next hop as a Level-1-2 router. The routing table of a Level-
2 router contains all Level-1 and Level-2 routes.
[RouterA] display isis route
Route information for ISIS(1)

-----------------------------
ISIS(1) Level-1 Forwarding Table

--------------------------------
IPV4 Destination IntCost ExtCost ExitInterface NextHop Flags

-------------------------------------------------------------------------
10.1.1.0/24
10.1.2.0/24
192.168.0.0/24
0.0.0.0/0
Flags: D-Direct, A-Added to URT, L-Advertised in LSPs, S-IGP Shortcut,

U-Up/Down Bit Set
[RouterB] display isis route

-----------------------------
--------------------------------

-------------------------------------------------------------------------
10.1.2.0/24
10.1.1.0/24
192.168.0.0/24
0.0.0.0/0

U-Up/Down Bit Set
[RouterC] display isis route

-----------------------------

--------------------------------

-------------------------------------------------------------------------
10.1.1.0/24
10.1.2.0/24
192.168.0.0/24

U-Up/Down Bit Set

--------------------------------

-------------------------------------------------------------------------
10.1.1.0/24
10.1.2.0/24
192.168.0.0/24
172.16.0.0/16 20 NULL GE3/0/0 192.168.0.2 A/-/-/-

U-Up/Down Bit Set
[RouterD] display isis route

-----------------------------

--------------------------------
--------------------------------------------------------------------------
192.168.0.0/24
10.1.1.0/24
10.1.2.0/24
172.16.0.0/16
Flags: D-Direct, A-Added to URT, L-Advertised in LSPs, S-IGP

Shortcut, U-Up/Down Bit Set
Configuration Files
#
sysname RouterA
#
isis 1
is-level level-1
network-entity 10.0000.0000.0001.00
#
ip address 10.1.1.2 255.255.255.0
isis enable 1
#
return
#
sysname RouterB
#
isis 1
is-level level-1
network-entity 10.0000.0000.0002.00
#
ip address 10.1.2.2 255.255.255.0
isis enable 1
#
return
#
sysname RouterC
#
isis 1
network-entity 10.0000.0000.0003.00
#
ip address 10.1.1.1 255.255.255.0
isis enable 1
#
ip address 10.1.2.1 255.255.255.0
isis enable 1
#
ip address 192.168.0.1 255.255.255.0
isis enable 1
#
return
#
sysname RouterD
#
isis 1
is-level level-2
network-entity 20.0000.0000.0004.00
#
ip address 192.168.0.2 255.255.255.0
isis enable 1
#
ip address 172.16.1.1 255.255.0.0
isis enable 1
#
return
2.15.2 Example for Configuring IS-IS Route Summarization
As shown in Figure 2-15-2, three routers run IS-IS to communicate with each other. RouterA is a
Level-2 router, RouterB is a Level-1-2 router, and RouterC is a Level-1 router. RouterA is heavily
loaded because there are too many routing entries on the IS-IS network. Therefore, system
resource consumption of RouterA needs to be reduced.
Figure 2-15-2 Networking diagram of configuring IS-IS route summarization
1. Configure IP addresses for interfaces and enable IS-IS on each router so that the routers can
be interconnected.
2. Configure route summarization on RouterB to reduce the routing table size of RouterA
without affecting data forwarding so that the system resource consumption of RouterA can be
reduced.
Procedure

The configurations of RouterB and RouterC are similar to the configuration of RouterA, and
are not mentioned here.
[RouterA] isis 1
[RouterB] isis 1
[RouterC] isis 1
[RouterC-isis-1] is-level level-1
The configurations of GigabitEthernet2/0/0, GigabitEthernet3/0/0, and GigabitEthernet4/0/0

are similar to the configuration of GigabitEthernet1/0/0, and are not mentioned here.
3. Check the IS-IS routing table of RouterA.

-----------------------------
--------------------------------
----------------------------------------------------------------------------
172.1.1.0/24 30 NULL GE2/0/0 172.2.1.2 A/-/L/-
172.1.2.0/24 30 NULL GE2/0/0 172.2.1.2 A/ -/L/-
172.1.3.0/24 30 NULL GE2/0/0 172.2.1.2 A/ -/L/-
172.1.4.0/24 20 NULL GE2/0/0 172.2.1.2 A/ -/L/-
172.2.1.0/24 10 NULL GE2/0/0 Direct D/
-/L/- Flags: D-Direct, A-Added to URT, L-Advertised in LSPs, S-IGP Shortcut,
U-Up/Down Bit Set
4. Configure route summarization on RouterB.
# Summarize 172.1.1.0/24, 172.1.2.0/24, 172.1.3.0/24, and 172.1.4.0/24 into 172.1.0.0/16 on

RouterB.
[RouterB] isis 1
[RouterB-isis-1] summary 172.1.0.0 255.255.0.0 level-1-2
# Check the routing table of RouterA, you can see that routes 172.1.1.0/24, 172.1.2.0/24,
172.1.3.0/24 and 172.1.4.0/24 are summarized into one route 172.1.0.0/16.
-----------------------------
--------------------------------
----------------------------------------------------------------------------
172.1.0.0/16 20 NULL GE2/0/0 172.2.1.2 A/ -/L/-
172.2.1.0/24 10 NULL GE2/0/0 Direct D/
U-Up/Down Bit Set
Configuration Files
#
sysname RouterA
#
isis 1
is-level level-2
network-entity 20.0000.0000.0001.00
#
ip address 172.2.1.1 255.255.255.0
isis enable 1
#
return
#
sysname RouterB
#
isis 1
network-entity 10.0000.0000.0002.00
summary 172.1.0.0 255.255.0.0 level-1-2
#
ip address 172.1.4.2 255.255.255.0
isis enable 1
#
ip address 172.2.1.2 255.255.255.0
isis enable 1
#
return
#
sysname RouterC
#
isis 1
is-level level-1
network-entity 10.0000.0000.0003.00
#
ip address 172.1.4.1 255.255.255.0
isis enable 1
#
ip address 172.1.1.1 255.255.255.0
isis enable 1
#
ip address 172.1.2.1 255.255.255.0
isis enable 1
#
ip address 172.1.3.1 255.255.255.0
isis enable 1
#
return
2.15.3 Example for Configuring IS-IS DIS Election
As shown in Figure 2-15-3, four routers on the broadcast network communicate using IS-IS.
RouterA and RouterB are Level-1-2 routers, RouterC is a Level-1 router, and RouterD is a Level-2
router. RouterA with high performance needs to be configured as a Level-2 DIS.
Figure 2-15-3 Networking diagram of configuring IS-IS DIS election
1. Configure IS-IS to enable network interconnectivity.
2. Configure the DIS priority of RouterA to 100 so that RouterA can be elected as a Level-2 DIS.
Procedure

2. View the MAC address of the GE interface on each router.
# View the MAC address of GigabitEthernet1/0/0 on RouterA.
[RouterA] display arp interface gigabitethernet 1/0/0

IP ADDRESS MAC ADDRESS EXPIRE(M) TYPE INTERFACE
VPN-INSTANCE
VLAN/CEVLAN PVC
-------------------------------------------------------------------------
10.1.1.1 00e0-fc10-afec I- GE1/0/0
-------------------------------------------------------------------------
Total:1 Dynamic:0 Static:0 Interface:1
# View the MAC address of GigabitEthernet1/0/0 on RouterB.

[RouterB] display arp interface gigabitethernet 1/0/0
VPN-INSTANCE
VLAN/CEVLAN PVC
-------------------------------------------------------------------------
10.1.1.2 00e0-fccd-acdf I- GE1/0/0
-------------------------------------------------------------------------
# View the MAC address of GigabitEthernet1/0/0 on RouterC.
[RouterC] display arp interface gigabitethernet 1/0/0

VPN-INSTANCE
VLAN/CEVLAN PVC
-------------------------------------------------------------------------
10.1.1.3 00e0-fc50-25fe I- GE1/0/0
-------------------------------------------------------------------------
# View the MAC address of GigabitEthernet1/0/0 on RouterD.
[RouterD] display arp interface gigabitethernet 1/0/0

VPN-INSTANCE
VLAN/CEVLAN PVC
-------------------------------------------------------------------------
10.1.1.4 00e0-fcfd-305c I- GE1/0/0
-------------------------------------------------------------------------
3. Enable IS-IS
[RouterA] isis 1
[RouterB] isis 1
[RouterC] isis 1
[RouterD] isis 1
[RouterD-isis-1] is-level level-2
# View IS-IS neighbor information on RouterA.

[RouterA] display isis peer
Peer information for ISIS(1)
----------------------------
System Id Interface Circuit Id State HoldTime Type PRI
-----------------------------------------------------------------------------
0000.0000.0002 GE1/0/0
0000.0000.0003 GE1/0/0
0000.0000.0002 GE1/0/0
0000.0000.0004 GE1/0/0
Total Peer(s): 4
# View IS-IS interface information on RouterA.
[RouterA] display isis interface

Interface information for ISIS(1)
---------------------------------
Interface Id IPV4.State IPV6.State MTU Type DIS
GE1/0/0 001 Up Down 1497 L1/L2
No/No
# View IS-IS interface information on RouterB.
[RouterB] display isis interface

---------------------------------
GE1/0/0 001 Up Down 1497 L1/L2
Yes/No
# View IS-IS interface information on RouterD.
[RouterD] display isis interface

---------------------------------
GE1/0/0 001 Up Down 1497 L1/L2
No/Yes
NOTE:
As shown in the preceding interface information, when the default DIS priority is used,
the IS-IS interface on RouterB has the largest MAC address among all the interfaces on the
Level-1 routers. Therefore, RouterB is elected as the Level-1 DIS. The IS-IS interface on
RouterD has the largest MAC address among all the interfaces on Level-2 routers. Therefore,
RouterD is elected as the Level-2 DIS. Level-1 and Level-2 pseudonodes are
0000.0000.0002.01 and
0000.0000.0004.01
respectively.
4. Set the DIS priority of RouterA.

[RouterA-GigabitEthernet1/0/0] isis dis-priority 100
# View IS-IS neighbor information on RouterA.

----------------------------
-----------------------------------------------------------------------------
0000.0000.0002 GE1/0/0
0000.0000.0003 GE1/0/0
0000.0000.0002 GE1/0/0
0000.0000.0004 GE1/0/0
Total Peer(s): 4
# View IS-IS interface information on RouterA.
[RouterA] display isis interface

---------------------------------
GE1/0/0 001 Up Down 1497 L1/L2
Yes/Yes
NOTE:
As shown in the preceding information, after the DIS priority of the IS-IS interface is changed,
RouterA becomes a Level-1-2 DIS (DR) immediately and its pseudonode is
0000.0000.0001.01.
# View IS-IS neighbor and interface information on RouterB.

[RouterB] display isis peer
----------------------------
-----------------------------------------------------------------------------
0000.0000.0001 GE1/0/0
0000.0000.0003 GE1/0/0
0000.0000.0001 GE1/0/0
0000.0000.0004 GE1/0/0
Total Peer(s): 4
[RouterB] display isis interface
---------------------------------
GE1/0/0 001 Up Down 1497 L1/L2
No/No
# View IS-IS neighbor and interface information on RouterD.

[RouterD] display isis peer
----------------------------
-----------------------------------------------------------------------------
0000.0000.0001 GE1/0/0
0000.0000.0002 GE1/0/0
Total Peer(s): 2
[RouterD] display isis interface
---------------------------------
GE1/0/0 001 Up Down 1497 L1/L2
No/No
Configuration Files
#
sysname RouterA
#
isis 1
network-entity 10.0000.0000.0001.00
#
ip address 10.1.1.1 255.255.255.0
isis enable 1
isis dis-priority 100
#
return
#
sysname RouterB
#
isis 1
network-entity 10.0000.0000.0002.00
#
ip address 10.1.1.2 255.255.255.0
isis enable 1
#
return
#
sysname RouterC
#
isis 1
is-level level-1
network-entity 10.0000.0000.0003.00
#
ip address 10.1.1.3 255.255.255.0
isis enable 1
#
return
#
sysname RouterD
#
isis 1
is-level level-2
network-entity 10.0000.0000.0004.00
#
ip address 10.1.1.4 255.255.255.0
isis enable 1
#
return
2.15.4 Example for Configuring IS-IS to Interact with BGP
As shown in Figure 2-15-4, RouterA and RouterB belong to the same AS, and the IS-IS neighbor
relationship is established between RouterA and RouterB. An EBGP connection is established
between RouterB and RouterC. RouterA, RouterB, and RouterC need to communicate with each
other. Besides, the metric of routes need to be changed when AS 65009 sends the routes to AS 65008.
Figure 2-15-4 Networking diagram of configuring IS-IS to interact with BGP
1. Configure IP addresses for interfaces, and enable IS-IS and BGP to ensure that there
are reachable routes inside each AS.
2. Configure IS-IS and BGP to import routes from each other on RouterB to ensure that there
are routes on each network segment. Configure a route-policy to change the metric of
imported routes when IS-IS imports BGP routes.
Procedure

2. Configure IS-IS.
[RouterA] isis 1
[RouterB] isis 1
3. Configure BGP.
[RouterB] bgp 65008

[RouterB-bgp] router-id 1.1.1.1
[RouterB-bgp] peer 10.2.1.2 as-number 65009
[RouterB-bgp] ipv4-family unicast
[RouterB-bgp-af-ipv4] network 10.2.1.0 255.255.255.0
[RouterC] bgp 65009

[RouterC-bgp] router-id 2.2.2.2
[RouterC-bgp] peer 10.2.1.1 as-number 65008
[RouterC-bgp] ipv4-family unicast
[RouterC-bgp-af-ipv4] network 10.2.1.0 255.255.255.0
4. Configure IS-IS to import BGP routes.
# Configure a static route on RouterC.
[RouterC] ip route-static 200.1.1.1 32 NULL 0
# On RouterC, configure BGP to import the static route.
[RouterC] bgp 65009

[RouterC-bgp] import-route static
# On RouterB, configure IS-IS to import the BGP route.
[RouterB] isis 1
[RouterB-isis-1] import-route bgp
# View the routing table of RouterA, and you can see that IS-IS successfully imports BGP route
200.1.1.1/32.

------------------------------------------------------------------------------
10.1.1.0/24 Direct 0 0 D 10.1.1.1
10.1.1.1/32 Direct 0 0 D 127.0.0.1
200.1.1.1/32 ISIS-L2 15 74 D 10.1.1.2
# On RouterB, configure the AS_Path filter, and apply the filter in route-policy RTC.
[RouterB] ip as-path-filter 1 permit 65009

[RouterB] route-policy RTC permit node 0
[RouterB-route-policy] if-match as-path-filter 1
[RouterB-route-policy] apply cost 20
[RouterB-route-policy] quit
# On RouterB, configure IS-IS to import the BGP route.
[RouterB] isis 1
[RouterB-isis-1] import-route bgp route-policy RTC
# View the routing table of RouterA, and you can see that the AS_Path filter is
successfully applied and the cost of imported route 200.1.1.1/32 changes from 74 to 94.

------------------------------------------------------------------------------
10.1.1.0/24 Direct 0 0 D 10.1.1.1
10.1.1.1/32 Direct 0 0 D 127.0.0.1
10.1.1.1/32 Direct 0 0 D 127.0.0.1
200.1.1.1/32 ISIS-L2 15 94 D 10.1.1.2
5. Configure BGP to import IS-IS routes.

[RouterB] bgp 65008
[RouterB-bgp] import-route isis 1
[RouterB-bgp] quit
# View the routing table of RouterC, and you can see that BGP successfully imports IS-IS route
10.1.1.0/24.
[RouterC] display ip routing-table

------------------------------------------------------------------------------

10.1.1.0/24 EBGP 255 0 D 10.2.1.1
10.2.1.0/24
10.2.1.2/32
10.2.1.2/32
127.0.0.0/8
127.0.0.1/32
200.1.1.1/32
Configuration Files
#
sysname RouterA
#
isis 1
network-entity 10.0000.0000.0001.00
#
ip address 10.1.1.1 255.255.255.0
isis enable 1
#
return
#
sysname RouterB
#
isis 1
network-entity 10.0000.0000.0002.00
import-route bgp route-policy RTC
#
ip address 10.1.1.2 255.255.255.0
isis enable 1
#
ip address 10.2.1.1 255.255.255.0
#
interface LoopBack0
ip address 1.1.1.1 255.255.255.255
#
bgp 65008
router-id 1.1.1.1
peer 10.2.1.2 as-number 65009
#
ipv4-family unicast
undo synchronization
network 10.2.1.0 255.255.255.0
import-route isis 1
peer 10.2.1.2 enable
#
route-policy RTC permit node 0
if-match as-path-filter 1
apply cost 20
#
ip as-path-filter 1 permit 65009
#
return
#
sysname RouterC
#
ip address 10.2.1.2 255.255.255.0
#
interface LoopBack0
ip address 2.2.2.2 255.255.255.255
#
bgp 65009
router-id 2.2.2.2
#
ipv4-family unicast
network 10.2.1.0 255.255.255.0
import-route static
#
ip route-static 200.1.1.1 255.255.255.255 NULL0
#
return
2.15.5 Example for Configuring IS-IS Fast Convergence
As shown in Figure 2-15-5, two Routers are connected through a Layer 2 switch. The two routers
communicate with each other through the IS-IS protocol. The convergence speed of the two
routers need to be improved.
Figure 2-15-5 Networking diagram for configuring IS-IS fast convergence
1. Configure the IP addresses of interfaces and the IS-IS route-policy on each router so that
routes on the two routers are reachable.
2. Configure BFD sessions on RouterA and RouterB to improve the link fault detection speed
of the routers.
3. Set the time parameters of fast convergence on RouterA and RouterB to implement IS-IS
fast convergence.
Procedure

The configuration of RouterB is similar to the configuration of RouterA, and is not

mentioned here.
[RouterA] isis 1
[RouterB] isis 1
3. Configure BFD.
[RouterA] bfd
[RouterA-bfd] quit
[RouterA] bfd atob bind peer-ip 100.1.1.2 interface gigabitethernet 1/0/0
[RouterA-bfd-session-atob] discriminator local 1
[RouterA-bfd-session-atob] discriminator remote 2
[RouterA-bfd-session-atob] commit
[RouterA-bfd-session-atob] quit
[RouterA-GigabitEthernet1/0/0] isis bfd static
[RouterB] bfd
[RouterB-bfd] quit
[RouterB] bfd btoa bind peer-ip 100.1.1.1 interface gigabitethernet 1/0/0
[RouterB-bfd-session-btoa] discriminator local 2
[RouterB-bfd-session-btoa] discriminator remote 1
[RouterB-bfd-session-btoa] commit
[RouterB-bfd-session-btoa] quit
[RouterB-GigabitEthernet1/0/0] isis bfd static
4. Set the time parameters of fast convergence.
[RouterA] isis 1
[RouterA-isis-1] flash-flood
[RouterA-isis-1] timer spf 1 20 100
[RouterA-isis-1] timer lsp-generation 1 1 120
[RouterB] isis 1
[RouterB-isis-1] timer spf 1 20 100
[RouterB-isis-1] timer lsp-generation 1 1 120
NOTE:
 In IS-IS, if the LSDB changes, routes are calculated and a new LSP is generated to
report this change. Frequent route calculations consume a lot of system resources and
decrease the system performance. Delaying SPF calculation and LSP generation and
speeding up LSP flooding can improve the efficiency in route calculation and reduce the
consumption
of system resources.
 The flash-flood command enables LSP fast flooding to speed up IS-IS network
convergence.
 The timer spf command sets the interval for SPF calculation. The default interval is
5 seconds.
 The timer lsp-generation command sets the delay in generating an LSP. The
default interval is 2 seconds.

# Run the shutdown command on GE1/0/0 of RouterB to shut down the link.

[RouterB-GigabitEthernet1/0/0] shutdown
# View the information about neighbors of RouterA.
<RouterA> display isis peer
Information about neighbors of RouterA does not exist.
When BFD detects that the link goes Down, it notifies the routing management (RM)
module immediately. IS-IS then deletes the neighbor relationship immediately and triggers
route calculation. This implements fast convergence of the network.
Configuration Files
#
sysname RouterA
#
bfd
#
isis 1
is-level level-2
timer lsp-generation 1 1 120 level-1
flash-flood level-1
flash-flood level-2
network-entity 10.0000.0000.0001.00
timer spf 1 20 100
#
ip address 100.1.1.1 255.255.255.0
isis enable 1
isis bfd static
#
bfd atob bind peer-ip 100.1.1.2 interface
GigabitEthernet1/0/0 discriminator local 1
discriminator remote 2
commit
#
return
#
sysname RouterB
#
bfd
#
isis 1
is-level level-2
flash-flood level-1
flash-flood level-2
network-entity 10.0000.0000.0002.00
timer spf 1 20 100
#
ip address 100.1.1.2 255.255.255.0
isis enable 1
isis bfd static
#
bfd btoa bind peer-ip 100.1.1.1 interface
commit
#
return
2.15.6 Example for Configuring IS-IS Auto FRR (IP Protecting
IP) Networking Requirements
As shown in Figure 2-15-6, four routers (RouterA, RouterB, RouterC, and RouterD)
communicate using IS-IS. Reliability of data forwarding from RouterA to RouterD needs to be
improved so that uninterrupted traffic transmission is ensured when a fault occurs on the network.
Figure 2-15-6 Networking diagram of configuring IS-IS Auto FRR
1. Configure IP addresses for interfaces and enable IS-IS on each router to ensure reachable
routes between the routers.
2. Set a larger link cost (in compliance with the traffic protection inequality of IS-IS Auto FRR)
on GigabitEthernet2/0/0 of RouterA to ensure that Link T functions as the primary link to
forward data from RouterA to RouterD.
3. Configure IS-IS Auto FRR on RouterA to allow traffic to be fast switched to the backup
link without waiting for route convergence when a fault occurs on Link T. This ensures
uninterrupted traffic transmission.
Procedure

[RouterA] isis 1
[RouterA-isis-1] is-level level-1-2
[RouterB] isis 1
[RouterB-isis-1] is-level level-1-2
[RouterC] isis 1
[RouterC-isis-1] is-level level-1-2
[RouterD] isis 1
[RouterD-isis-1] is-level level-1-2
3. Set the cost of GigabitEthernet2/0/0 on RouterA to 30, and check routing information.
# Set the cost of GigabitEthernet2/0/0 on RouterA to 30.

[RouterA-GigabitEthernet2/0/0] isis cost 30
# Check information about the link from RouterA to RouterD. Link T has a lower cost, and so
IS-IS selects Link T to send traffic forwarded by RouterA.
<RouterA> display isis route 100.1.1.1 verbose

-----------------------------

--------------------------------
IPV4 Dest : 100.1.1.0/24 Int. Cost : 30 Ext. Cost : NULL

Admin Tag : - Src Count : 1 Flags : A/-/L/-
Priority : Low
NextHop : Interface : ExitIndex :
1.0.0.2 GE1/0/0 0x00000003

U-Up/Down Bit Set

--------------------------------
IPV4 Dest : 100.1.1.0/24

Admin Tag : -
Priority : Low

U-Up/Down Bit Set
# Run the display fib 100.1.1.1 verbose command on RouterA to check the forwarding entry of
traffic from RouterA to RouterD.
<RouterA> display fib 100.1.1.1 verbose
Route Entry Count: 1

Destination: 100.1.1.0
Nexthop : 1.0.0.2
LocalAddr : 1.0.0.1 LocalMask: 0.0.0.0
Flags
ATIndex
LspFwdFlag : 0 LspToken : 0x0
InLabel : NULL OriginAs : 0
BGPNextHop : 0.0.0.0 PeerAs :0
QosInfo : 0x0 OriginQos: 0x0
NexthopBak : 0.0.0.0 OutIfBak : [No Intf]
LspTokenBak: 0x0 InLabelBak : NULL
LspToken_ForInLabelBak : 0x0
EntryRefCount : 0
VlanId : 0x0
LspType :0 Label_ForLspTokenBak :0
MplsMtu :0 Gateway_ForLspTokenBak : 0
NextToken :0 IfIndex_ForLspTokenBak : 0
Label_NextToken : 0 Label : 0
LspBfdState :0
As shown in the command output, traffic from RouterA to RouterD is only forwarded through
Link T.
4. Enable IS-IS Auto FRR on RouterA, and check routing information.
# Enable IS-IS Auto FRR on RouterA.
[RouterA] isis
[RouterA-isis-1] frr
[RouterA-isis-1-frr]loop-free-alternate
# Check information about the routes from RouterA to RouterD. The information shows that
IS-IS generates a backup link after IS-IS Auto FRR is enabled.
<RouterA> display isis route 100.1.1.1 verbose

-----------------------------

--------------------------------
IPV4 Dest : 100.1.1.0/24 Int. Cost : 30 Ext. Cost : NULL

Admin Tag : -
Priority : Low
NextHop :
1.0.0.2
(B)2.0.0.2

U-Up/Down Bit Set

--------------------------------
IPV4 Dest : 100.1.1.0/24

Admin Tag : -
Priority : Low

U-Up/Down Bit Set
# Check the protection type for the traffic forwarded from RouterA to RouterD.
<RouterA> display isis spf-tree systemid 0000.0000.0004 verbose
Shortest Path Tree for ISIS(1)

------------------------------
ISIS(1) Level-1 Shortest Path Tree

----------------------------------
0000.0000.0004.00
Distance : 20
Distance-URT : 20
Flags : SPT/V6_Islt
IPv4 Nexthops-URT :1
(1) 1.0.0.2 IF:GE1/0/0 NBR:0000.0000.0003.00
(B) 2.0.0.2 IF:GE2/0/0 NBR:0000.0000.0002.00
TYPE:LOOP-FREE PROTECT:LINK-NODE
IPv6 Nexthops :0
Neighbors: 2 (Children:1 Parents:1
Others:0) (1)
0000.0000.0003.02
Cost : 10
Flags : Parent
(2) 0000.0000.0004.03
Cost : 10
Flags : Child
ISIS(1) Level-2 Shortest Path Tree

----------------------------------
0000.0000.0004.00
Distance : 20
Distance-URT : 20
Flags : SPT/V6_Islt
IPv4 Nexthops-URT :1
(1) 1.0.0.2 IF:GE1/0/0 NBR:0000.0000.0003.00
(B) 2.0.0.2 IF:GE2/0/0 NBR:0000.0000.0002.00
TYPE:LOOP-FREE PROTECT:LINK-NODE
IPv6 Nexthops :0
Neighbors: 2 (Children:1 Parents:1
Others:0) (1)
0000.0000.0003.02
Cost : 10
Flags : Parent
(2) 0000.0000.0004.03
Cost : 10
Flags : Child
As shown in the preceding command output, link-node dual protection is performed on

the traffic from RouterA to RouterD.
# Run the display fib 100.1.1.1 verbose command on RouterA to check the forwarding entry of
traffic from RouterA to RouterD.

Destination: 100.1.1.0 Mask : 255.255.255.0
Nexthop : 1.0.0.2 OutIf : GigabitEthernet1/0/0
Flags : DGU Age : 6sec
ATIndex :0 Slot :0
NexthopBak : 2.0.0.2 OutIfBak : GigabitEthernet2/0/0
EntryRefCount : 0
VlanId : 0x0
MplsMtu :0 Gateway_For LspTokenBak : 0
LspBfdState :0
As shown in the command output, the primary link from RouterA to RouterD is Link T,
the backup link follows the route with outbound interface GigabitEthernet2/0/0 and next
hop
2.0.0.2.
# Run the shutdown command on GigabitEthernet2/0/0 of RouterC to shut down the link.

[RouterC-GigabitEthernet2/0/0] shutdown
# Run the display fib 100.1.1.1 verbose command on RouterA to check information about
the route from RouterA to RouterD.

Destination: 100.1.1.0 Mask : 255.255.255.0
Nexthop : 2.0.0.2 OutIf : GigabitEthernet2/0/0
Flags : DGU Age : 124sec
ATIndex :0 Slot :0
NexthopBak : 0.0.0.0 OutIfBak : [No Intf]
EntryRefCount : 0
VlanId : 0x0
MplsMtu :0 Gateway_ForLspTokenBak : 0
LspBfdState :0
As shown in the command output, the traffic forwarded by the RouterA is switched to
the backup link with outbound interface GigabitEthernet2/0/0 and next hop 2.0.0.2.
Configuration Files
#
sysname RouterA
#
isis 1
frr
loop-free-alternate level-1
loop-free-alternate level-2
network-entity 10.0000.0000.0001.00
#
interface GigabitEthernet 1/0/0
ip address 1.0.0.1 255.255.255.0
isis enable 1
#
ip address 2.0.0.1 255.255.255.0
isis enable 1
isis cost 30
#
return
#
sysname RouterB
#
isis 1
network-entity 10.0000.0000.0002.00
#
ip address 2.0.0.2 255.255.255.0
isis enable 1
#
ip address 3.0.0.1 255.255.255.0
isis enable 1
#
return
#
sysname RouterC
#
isis 1
network-entity 10.0000.0000.0003.00
#
ip address 1.0.0.2 255.255.255.0
isis enable 1
#
shutdown
ip address 4.0.0.1 255.255.255.0
isis enable 1
#
return
#
sysname RouterD
#
isis 1
network-entity 10.0000.0000.0004.00
#
ip address 4.0.0.2 255.255.255.0
isis enable 1
#
ip address 3.0.0.2 255.255.255.0
isis enable 1
#
ip address 100.1.1.1 255.255.255.0
isis enable 1
#
return
2.15.7 Example for Configuring Static BFD for IS-IS
As shown in Figure 2-15-7, three routers are interconnected using IS-IS, and RouterA and RouterB
communicate with each other through a Layer 2 switch. When the link between RouterA and
RouterB is faulty, the two routers need to rapidly respond to the fault and reestablish a neighbor
relationship.
Figure 2-15-7 Networking diagram of configuring static BFD for IS-IS
NOTE:
BFD for IS-IS cannot be used to detect the multi-hop link between RouterA and RouterC, because the
IS-IS neighbor relationship cannot be established between RouterA and RouterC.
2. Enable static BFD for IS-IS on RouterA and RouterB so that routers can rapidly detect
link faults.
Procedure

[RouterA] isis 1
[RouterA-isis-1] network-entity aa.1111.1111.1111.00
[RouterB] isis 1
[RouterB-isis-1] network-entity aa.2222.2222.2222.00
[RouterC] isis 1
[RouterC-isis-1] network-entity aa.3333.3333.3333.00
# After the preceding configurations, you can see that the neighbor relationship is
established between RouterA and RouterB.
----------------------------
System Id Interface Circuit Id State HoldTime Type
PRI
2222.2222.2222 GE1/0/0 2222.2222.2222.00 Up 23s
L2 64
The IS-IS routing table of RouterA contains the routes to RouterB and RouterC.
-----------------------------
--------------------------------
-------------------------------------------------------------------------
100.1.1.0/24 10 NULL GE1/0/0 Direct D/-/L/-
100.2.1.0/24 20 NULL GE1/0/0 100.1.1.2 A/
U-Up/Down Bit Set
3. Configure BFD.
# Enable BFD on RouterA and configure a BFD session.
[RouterA] bfd
[RouterA-bfd] quit
[RouterA] bfd atob bind peer-ip 100.1.1.2 interface gigabitethernet 1/0/0
[RouterA-bfd-session-atob] discriminator local 1
[RouterA-bfd-session-atob] discriminator remote 2
[RouterA-bfd-session-atob] commit
[RouterA-bfd-session-atob] quit
# Enable BFD on RouterB and configure a BFD session.
[RouterB] bfd
[RouterB-bfd] quit
[RouterB] bfd btoa bind peer-ip 100.1.1.1 interface gigabitethernet 1/0/0
[RouterB-bfd-session-btoa] discriminator local 2
[RouterB-bfd-session-btoa] discriminator remote 1
[RouterB-bfd-session-btoa] commit
[RouterB-bfd-session-btoa] quit
After the preceding configurations, run the display bfd session command on RouterA or
RouterB, and you can see that the status of the BFD session is Up.
The following uses the display on RouterA as an an example.
[RouterA] display bfd session all

--------------------------------------------------------------------------------
Local Remote PeerIpAddr State Type InterfaceName
--------------------------------------------------------------------------------
1 2 100.1.1.2 Up S_IP_IF GE1/0/0
--------------------------------------------------------------------------------
Total UP/DOWN Session Number : 1/0
4. Enable IS-IS fast detect.

[RouterA-GigabitEthernet1/0/0] isis bfd static

[RouterB-GigabitEthernet1/0/0] isis bfd static
# Enable log information display on RouterA.
<RouterA> terminal logging

<RouterA> terminal monitor
# Run the shutdown command on GigabitEthernet1/0/0 on RouterB to simulate a link fault.
# On RouterA, you can view the following log and debugging information, which indicates that
IS-IS deletes the neighbor relationship with RouterB after being notified by BFD of the fault.
ISIS/4/PEER_DOWN_BFDDOWN/1880166931 UL/R "ISIS 1 neighbor

2222.2222.2222 was Down on interface GE1/0/0
because the BFD node was down. The Hello packet was received at 11:32:10 last
time; the maximum interval for sending Hello packets was 9247;the local router sent 426
Hello
packets and received 61 packets;the type of the Hello packet was Lan Level-2."
Run the display isis route command or the display isis peer command on RouterA, and
you can see that no information is displayed. This indicates that the IS-IS neighbor
relationship between RouterA and RouterB is deleted.
Configuration Files
#
sysname RouterA
#
bfd
#
isis 1
is-level level-2
network-entity aa.1111.1111.1111.00
#
ip address 100.1.1.1 255.255.255.0
isis enable 1
isis bfd static
#
bfd atob bind peer-ip 100.1.1.2 interface
commit
#
return
#
sysname RouterB
#
bfd
#
isis 1
is-level level-2
#
ip address 100.1.1.2 255.255.255.0
isis enable 1
isis bfd static
#
ip address 100.2.1.1 255.255.255.0
isis enable 1
#
bfd btoa bind peer-ip 100.1.1.1 interface
commit
#
return
#
sysname RouterC
#
isis 1
is-level level-2
#
ip address 100.2.1.2 255.255.255.0
isis enable 1
#
return
2.15.8 Example for Configuring Dynamic BFD for IS-IS
As shown in Figure 2-15-8, three routers are interconnected using IS-IS, and RouterA and RouterB
communicate with each other through a Layer 2 switch. When the link that passes through the switch
between RouterA and RouterB fails, the two routers need to rapidly respond to the fault, and traffic
can be switched to the link that passes through RouterC for forwarding.
Figure 2-15-8 Networking diagram of configuring dynamic BFD for IS-IS
2. Set the IS-IS interface cost to control route selection of the routers to make the link that
passes through the switch from RouterA to RouterB as the primary link and the link that
passes through RouterC as the backup link.
3. Configure dynamic BFD for IS-IS on RouterA, RouterB, and RouterC so that link faults can
be detected rapidly and traffic can be switched to the backup link for forwarding.
Procedure

[RouterA] isis
[RouterB] isis
[RouterC] isis
[RouterC] interface gigabitEthernet 1/0/0
# After the preceding configurations, run the display isis peer command. You can see that the
neighbor relationships are established between RouterA and RouterB, and between RouterA
and
RouterC. The following uses the configuration of RouterA as an example.
----------------------------
0000.0000.0002
0000.0000.0003
Total Peer(s): 2
# Routers have learned routes from each other. The following uses the routing table of RouterA
as an example.

------------------------------------------------------------------------------
1.1.1.0/24 Direct 0 0 D 1.1.1.1
1.1.1.1/32 Direct 0 0 D 127.0.0.1
2.2.2.0/24 ISIS-L2 15 20 D 1.1.1.2
3.3.3.0/24 Direct 0 0 D 3.3.3.1
3.3.3.1/32 Direct 0 0 D 127.0.0.1
172.16.1.0/24 ISIS-L2 15 20 D 3.3.3.2
As shown in the routing table, the next-hop address of the route to 172.16.1.0/24 is 3.3.3.2,
and traffic is transmitted on the primary link RouterA→RouterB.
3. Set the interface cost.

[RouterA-GigabitEthernet1/0/0] isis cost 5

[RouterB-GigabitEthernet1/0/0] isis cost 5
4. Configure BFD for IS-IS processes.
# Enable BFD for IS-IS on RouterA.
[RouterA] bfd
[RouterA-bfd] quit
[RouterA] isis
[RouterA-isis-1] bfd all-interfaces enable
# Enable BFD for IS-IS on RouterB.
[RouterB] bfd
[RouterB-bfd] quit
[RouterB] isis
[RouterB-isis-1] bfd all-interfaces enable
# Enable BFD for IS-IS on RouterC.
[RouterC] bfd
[RouterC-bfd] quit
[RouterC] isis
[RouterC-isis-1] bfd all-interfaces enable
# After the preceding configurations, run the display isis bfd session all command on
RouterA, RouterB, and RouterC. You can see that the BFD session status is Up.
The following uses the display on RouterA as an example.
[RouterA] display isis bfd session all

BFD session information for ISIS(1)
-----------------------------------
Peer System ID : 0000.0000.0002 Interface : GE2/0/0
RX : 1000 LocDis : 8193 Local IP Address: 3.3.3.1
Multiplier : 3 RemDis : 8192 Type : L2
Diag : No diagnostic information
Total BFD session(s): 2
As shown in the preceding display, the status of the BFD session between RouterA and RouterB
and that between RouterA and RouterC is Up.
5. Configure BFD for IS-IS interfaces.
# Configure BFD on GE2/0/0 of RouterA, set the minimum interval for sending packets to
100 ms, the minimum interval for receiving packets to 100 ms, and the local detection
multiplier to
4.

[RouterA-GigabitEthernet2/0/0] isis bfd enable
[RouterA-GigabitEthernet2/0/0] isis bfd min-tx-interval 100 min-rx-interval
100 detect-multiplier 4
# Configure BFD on GE2/0/0 of RouterB, set the minimum interval for sending packets to
100 ms, the minimum interval for receiving packets to 100 ms, and the local detection
multiplier to
4.
[RouterB] bfd
[RouterB-bfd] quit
[RouterB-GigabitEthernet2/0/0] isis bfd enable
[RouterB-GigabitEthernet2/0/0] isis bfd min-tx-interval 100 min-rx-interval
# After the preceding configurations, run the display isis bfd session all command on RouterA
or RouterB. You can see that the BFD parameters have taken effect. The following uses
the display on RouterB as an example.
[RouterB] display isis bfd session all

-----------------------------------
TX : 100 BFD State : up Peer IP Address : 3.3.3.1
TX : 100 BFD State : up Peer IP Address : 2.2.2.1

# Run the shutdown command on GigabitEthernet2/0/0 of RouterB to simulate a primary link
failure.

7. # View the routing table of RouterA.

------------------------------------------------------------------------------
Destination/Mask
1.1.1.0/24
1.1.1.1/32
1.1.1.1/32
2.2.2.0/24 ISIS-L2 15 20 D 1.1.1.2
3.3.3.0/24 Direct 0 0 D 3.3.3.1
3.3.3.1/32
3.3.3.1/32
127.0.0.0/8
127.0.0.1/32
172.16.1.0/24
As shown in the routing table, the backup link RouterA→RouterC→RouterB takes effect
after the primary link fails, and the next-hop address of the route to 172.16.1.0/24 becomes
1.1.1.2.
# Run the display isis bfd session all command on RouterA. You can see that the status of the
BFD session between RouterA and RouterC is Up.
[RouterA] display isis bfd session all

-----------------------------------
TX : 100
RX : 100
Multiplier : 3
Configuration Files
#
sysname RouterA
#
bfd
#
isis 1
is-level level-2
bfd all-interfaces enable
network-entity 10.0000.0000.0001.00
#
ip address 1.1.1.1 255.255.255.0
isis enable 1
#
ip address 3.3.3.1 255.255.255.0
isis enable 1
isis cost 5
isis bfd enable
isis bfd min-tx-interval 100 min-rx-interval 100 detect-multiplier 4
#
return
#
sysname RouterB
#
bfd
#
isis 1
is-level level-2
network-entity 10.0000.0000.0002.00
#

1210
ip address 2.2.2.2 255.255.255.0
isis enable 1
#
ip address 3.3.3.2 255.255.255.0
isis enable 1
isis cost 5
isis bfd enable
isis bfd min-tx-interval 100 min-rx-interval 100 detect-multiplier 4
#
ip address 172.16.1.1 255.255.255.0
isis enable 1
#
return
#
sysname RouterC
#
bfd
#
isis 1
is-level level-2
network-entity 10.0000.0000.0003.00
#
ip address 1.1.1.2 255.255.255.0
isis enable 1
#
ip address 2.2.2.1 255.255.255.0
isis enable 1
#
return
Chapter 3 OSPF
3.1 OSPF Summary
The Open Shortest Path First (OSPF) protocol, developed by the Internet Engineering Task Force
(IETF), is a link-state Interior Gateway Protocol (IGP).
As a link-state protocol, OSPF can solve many problems encountered by RIP. Additionally, OSPF
features the following advantages:
 Receives or sends packets in multicast mode to reduce load on the router that does not run OSPF.
 Supports Classless Inter-domain Routing (CIDR).
 Supports load balancing among equal-cost routes.
 Supports packet encryption.
3.2 Fundamentals of OSPF
OSPF has the following functions:
 Divides an Autonomous System (AS) into one or multiple logical areas.
 Advertises routes by sending Link State Advertisements (LSAs).
 Exchanges OSPF packets between devices in an OSPF area to synchronize routing information.
 Encapsulates OSPF packets into IP packets and sends the packets in unicast or multicast mode.
3.2.1 Packet Type
Table 3-2-1 Packet type
Packet Type
Hello packet
Database Description (DD) packet
Link State Request (LSR) packet
Link State Update (LSU) packet
Link State Acknowledgement (LSAck)

packet
3.2.2 LSA Type
Table 3-2-2 LSA type
LSA Type
Router-LSA (Type 1)
Network-LSA (Type 2)
Network-summary-LSA (Type
3)
ASBR-summary-LSA (Type 4)
AS-external-LSA (Type 5)
NSSA-LSA (Type7)
Opaque-LSA (Type 9/Type

10/Type 11)
3.2.3 Router Type
Figure 3-2-1 lists common Router types used in OSPF.

Figure 3-2-1 Router type
Table 3-2-3 Router type
Router Type
Internal router
Area Border Router (ABR)
Backbone router
ASBR (AS Boundary Router)
3.2.4 Route Type
Inter-area and intra-area routes in an AS describe the AS's network structure. AS external routes
describe the routes to destinations outside an AS. OSPF classifies the imported AS external routes
into Type 1 and Type 2 external routes.
Table 3-2-4 lists route types in descending priority order.
Table 3-2-4 Route type
Route Type Description
Intra-area route Indicates routes within an area.

Table 3-2-4 Route type
Route Type
Inter-area route
Type 1 external route
Type 2 external route
3.2.5 OSPF Network Type
Table 3-2-5 lists four OSPF network types that are classified based on link layer protocols.
Table 3-2-5 OSPF network type
Network Type Description
Broadcast A network with the link layer protocol of Ethernet or Fiber Distributed
Data Interface (FDDI) is a broadcast network by
default. On a broadcast network:
 Hello packets, LSU packets, and LSAck packets are usually
transmitted in multicast mode. 224.0.0.5 is an IP multicast
address reserved for an OSPF device. 224.0.0.6 is an IP multicast
address reserved for an OSPF DR or backup designated router
(BDR).
 DD and LSR packets are transmitted in unicast mode.
Non-Broadcast A network with the link layer protocol of frame relay (FR), X.25 is
Multi-Access (NBMA) an
NBMA network by default.
On an NBMA network, protocol packets such as Hello packets,
DD packets, LSR packets, LSU packets, and LSAck packets are
sent in unicast mode.
Point-to-Multipoint No network is a P2MP network by default, no matter what type of link

(P2MP) layer protocol is used on the network. A network can be changed to a
P2MP network. The common practice is to change a non-fully meshed
NBMA network to a P2MP network.
On a P2MP network:
 Hello packets are transmitted in multicast mode using the
multicast address 224.0.0.5.
Table 3-2-5 OSPF network type
Network Type
Point-to-point (P2P)
3.2.6 Area Type
Table 3-2-6 Area type
Area Type
Common area
Stub area
Totally stub area
NSSA area
Table 3-2-6 Area type
Area Type
Totally NSSA area
Stub Area
Stub areas are specific areas where ABRs do not flood the received AS external routes. In stub
areas, Routers maintain fewer routing entries and less routing information.
Configuring a stub area is optional. Not every area can be configured as a stub area. A stub area
is usually a non-backbone area with only one ABR and is located at the AS border.
To ensure the reachability of the routes to destinations outside an AS, the ABR in the stub
area generates a default route and advertises the route to the non-ABRs in the same stub area.
Note the following points when configuring a stub area:
 The backbone area cannot be configured as a stub area.
 Before configuring an area as a stub area, you must configure stub area attributes on all Routers
in the area.
 There should be no ASBR in a stub area, meaning that AS external routes cannot be transmitted
in the stub area.
 Virtual connections cannot cross a stub area.
NSSA Area
NSSA areas are a special type of OSPF areas. There are many similarities between an NSSA area and
a stub area. Both of them do not advertise the external routes received from the other OSPF areas. The
difference is that a stub area cannot import AS external routes, whereas an NSSA area can import AS
external routes and advertise the imported routes to the entire AS.
After an area is configured as an NSSA area, an ABR in the NSSA area generates a default route
and advertises the route to the other Routers in the NSSA area. This is to ensure the reachability of
the routes to the destinations outside an AS.
Note the following points when configuring an NSSA area:
 The backbone area cannot be configured as an NSSA area.

 Before configuring an area as an NSSA area, you must configure NSSA area attributes on all
Routers in the area.
 Virtual connections cannot cross an NSSA area.
3.2.7 Neighbor State Machine
OSPF has eight state machines: Down, Attempt, Init, 2-way, Exstart, Exchange, Loading and Full.
 Down: It is in the initial stage of setting up sessions between neighbors. The state machine
is Down when a router fails to receive Hello packets from its neighbor before the dead
interval expires.
 Attempt: It occurs only on an NBMA network. The state machine is Attempt when a neighbor
does not reply with Hello packets after the dead interval has expired. The local router,
however, keeps sending Hello packets to the neighbor at every poll interval.
 Init: The state machine is Init after a router receives Hello packets.
 2-way: The state machine is 2-way when the Hello packets received by a router contain its
own router ID. The state machine will remain in the 2-way state if no neighbor relationship is
established, and will become Exstart if a neighbor relationship is established.
 Exstart: The state machine changes from Init to Exstart when the neighbor relationship is
established. The two neighbors then start to negotiate the master/slave status and determine
the sequence numbers of DD packets.
 Exchange: The state machine is Exchange when a router starts to exchange DD packets with
its neighbor after the master/slave status negotiation is completed.
 Loading: The state machine is Loading after a router has finished exchanging DD packets with
its neighbor.
 Full: The state machine is Full when the LSA retransmission list is empty.
3.2.8 OSPF Packet Authentication
OSPF supports packet authentication. Only the OSPF packets that have been authenticated can
be received. If OSPF packets are not authenticated, a neighbor relationship cannot be
established.
The Router supports two authentication methods:
 Area-based authentication
 Interface-based authentication
When both area-based and interface-based authentication methods are configured, interface-
based authentication takes effect.
3.2.9 OSPF Route Summarization
Route summarization means that an ABR in an area summarizes the routes with the same prefix
into one route and advertises the summarized route to the other areas.
Route summarization between areas reduces the amount of routing information to be
transmitted, reducing the size of routing tables and improving device performance.
Route summarization can be carried out by an ABR or an ASBR:
 Route summarization on an ABR:
When an ABR in an area advertises routing information to other areas, it generates Type 3 LSAs
by network segment. If this area contains consecutive network segments, you can run a command
to summarize these network segments into one network segment. The ABR only needs to send one
summarized LSA, and will not send the LSAs that belong to the summarized network segment
specified in the command.
 Route summarization on an ASBR:
If the local device is an ASBR and route summarization is configured, the ASBR will summarize
the imported Type 5 LSAs within the aggregated address range. After an NSSA area is configured,
the ASBR needs to summarize the imported Type 7 LSAs within the aggregated address range.
If the local device is an ASBR and ABR, the device will summarize the Type 5 LSAs that
are translated from Type 7 LSAs.
3.2.10 OSPF Default Route
A default route is a route of which the destination address and mask are all 0s. If a router cannot find
a route in its routing table for forwarding packets, it can forward packets using a default route. Due to
hierarchical management of OSPF routes, the priority of default Type 3 routes is higher than the
priority of default Type 5 or Type 7 routes.
OSPF default routes are usually used in the following cases:
 An ABR advertises default Type 3 Summary LSAs to instruct routers within an area to
forward packets between areas.
 An ASBR advertises default Type 5 ASE LSAs or default Type 7 NSSA area LSAs to
instruct routers in an AS to forward packets to other ASs.
Principles for advertising OSPF default routes are described below:
 An OSPF router can advertise LSAs carrying default route information only when it has
an interface connected to an upper-layer network.
 If an OSPF router has advertised an LSA carrying information about a type of default route, the
OSPF router does not learn this type of default routes advertised by other routers. This means
that the OSPF router no longer calculates routes based on the LSAs carrying information about
the same type of the default routes advertised by other routers, but stores these LSAs in its
LSDB.
 The route on which default external route advertisement depends cannot be a route in the local
OSPF AS. This means that the route cannot be the one learned by the local OSPF process. This
is because default external routes are used to guide packet forwarding outside an AS, whereas
the routes within an AS have the next hop pointing to the devices within the AS.
Table 3-2-7 Principles for advertising OSPF default routes
Area Type
Common area
STUB area
Totally STUB area
NSSA area

Totally NSSA area
3.2.11 OSPF Route Filtering
OSPF supports route filtering using routing policies. By default, OSPF does not filter
routes. Routing policies used by OSPF include the route-policy, access-list, and prefix-list.
OSPF route filtering can be used for:
 Importing routes
OSPF can import routes learned by other routing protocols. You can configure routing policies to
filter the imported routes to allow OSPF to import only the routes that match specific conditions.
 Advertising imported routes
OSPF advertises the imported routes to its neighbors.
You can configure filtering rules to filter the routes to be advertised. The filtering rules can
be configured only on ASBRs.
 Learning routes
Filtering rules can be configured to allow OSPF to filter the received intra-area, inter-area, and AS
external routes.
After receiving routes, an OSPF device adds only the routes that match the filtering rules to the
local routing table, but can still advertise all routes from the OSPF routing table.
 Learning inter-area LSAs
You can run a command to configure an ABR to filter the incoming Summary LSAs. This
configuration takes effect only on ABRs because only ABRs can advertise Summary
LSAs.
Table 3-2-8 Differences between inter-area LSA learning and route learning
Inter-area LSA Learning
Directly filters the incoming LSAs.

1210
 Advertising inter-area LSAs
You can run a command to configure an ABR to filter the outgoing Summary LSAs. This
configuration takes effect only on ABRs.
3.2.12 OSPF Multi-Process
OSPF supports multi-process. Multiple OSPF processes can run on the same Router, and they are
independent of each other. Route exchanges between different OSPF processes are similar to
route exchanges between different routing protocols.
Each interface on the Router belongs to only one OSPF process.
A typical application of OSPF multi-process is that OSPF runs between PEs and CEs in a VPN,
whereas OSPF is used as an IGP on the backbone of the VPN. Two OSPF processes on the same
PE are independent of each other.
3.2.13 OSPF RFC 1583 Compatibility
RFC 1583 is an earlier version of OSPFv2.
When OSPF calculates external routes, routing loops may occur because RFC 2328 and RFC 1583
define different route selection rules. To prevent routing loops, both communication ends must use
the same route selection rules.
 After RFC 1583 compatibility is enabled, OSPF use the route selection rules defined in RFC
1583.
 When RFC 1583 compatibility is disabled, OSPF uses the route selection rules defined in RFC
2328.
OSPF calculates external routes based on Type 5 LSAs. If the Router enabled with RFC
1583 compatibility receives a Type 5 LSA:
 The Router selects a route to the ASBR that originates the LSA, or to the forwarding address (FA)
described in the LSA.
 The Router selects external routes to the same destination.
By default, OSPF uses the route selection rules defined in RFC 1583.
3.3 BFD for OSPF
3.3.1 Definition
Bidirectional Forwarding Detection (BFD) is a mechanism to detect communication faults

between forwarding engines.
To be specific, BFD detects connectivity of a data protocol on a path between two systems. The
path can be a physical link, a logical link, or a tunnel.
In BFD for OSPF, a BFD session is associated with OSPF. The BFD session quickly detects a link
fault and then notifies OSPF of the fault. This speeds up OSPF's response to the change of the
network topology.
3.3.2 Purpose
The link fault or the topology change may cause devices to re-calculate routes. Therefore, the
convergence of routing protocols must be as quick as possible to improve the network
performance.
Link faults are unavoidable. Therefore, a feasible solution is required to detect faults faster and
notify the faults to routing protocols immediately. If BFD is associated with OSPF, once a fault
occurs on a link between neighbors, BFD can speed up the OSPF convergence.
Table 3-3-1 Comparison before and after BFD for OSPF is enabled
Associated with
BFD or Not
Not associated with BFD
Associated with
BFD
3.3.3 Principle
Figure 3-3-1 BFD for OSPF
The principle of BFD for OSPF is shown in Figure 3-3-1.
1. OSPF neighbor relationships are established between these three routers.
2. After a neighbor relationship becomes Full, this triggers BFD to establish a BFD session.
3. The outbound interface on RouterA connected to RouterB is GE 2/0/0. If the link fails, BFD
detects the fault and then notifies RouterA of the fault.
4. RouterA processes the event that a neighbor relationship becomes Down and re-calculates
routes. After calculation, the outbound interface is GE1 /0/0 passes through RouterC and
then reaches RouterB.
3.4 OSPF GTSM
3.4.1 Definition
GTSM is short for Generalized TTL Security Mechanism, a mechanism that protects the services
over the IP layer by checking whether the TTL value in the IP packet header is within a pre-defined
range.
3.4.2 Purpose
On the network, an attacker may simulate valid OSPF packets and keeps sending them to a device.
After receiving these packets, the device identifies the destination of the packets. The forwarding
plane of the device then directly sends the packets to the control plane for processing without
checking the validity of the packets. As a result, the device is busy processing these "valid" packets,
resulting in high CPU usage.
In applications, the GTSM is mainly used to protect the TCP/IP-based control plane from
CPU-utilization based attacks, for example, attacks that cause CPU overload.
3.4.3 Principle
Devices enabled with GTSM check the TTL values in all the received packets according to the
configured policies. The packets that fail to pass the policies are discarded or sent to the control
plane. This prevents devices from possible CPU-utilization based attacks. A GTSM policy involves
the following items:
 Source address of the IP packet sent to the device
 VPN instance to which the packet belongs
 Protocol number of the IP packet (89 for OSPF, and 6 for BGP)
 Source interface number and destination interface number of protocols above TCP/UDP
 Valid TTL range
The method of implementing GTSM is as follows:
 For the directly connected OSPF neighbors, the TTL value of the unicast protocol packets
to be sent is set to 255.
 For multi-hop neighbors, a reasonable TTL range is
defined. The applicability of GTSM is as follows:
 GTSM is effective with unicast packets rather than multicast packets. This is because the
TTL file of multicast packets can only be 255, and therefore GTSM is not needed to protect
against multicast packets.
 GTSM does not support tunnel-based neighbors.
3.5 OSPF Smart-discover
3.5.1 Definition
Generally, Routers periodically send Hello packets through OSPF interfaces. That is, a Router
sends Hello packets at the Hello interval set by a Hello timer. Because Hello packets are sent at a
fixed interval, the speed at which OSPF neighbor relationship is established is lowered.
Enabling Smart-discover can speed up the establishment of OSPF neighbor relationships in

specific scenarios.
Table 3-5-1 OSPF Smart-discover
Smart-discover Configured or Not
Smart-discover is not configured
Smart-discover is configured
3.5.2 Principle
In the following scenarios, the interface enabled with Smart-discover can send Hello packets
to neighbors without having to wait for the Hello timer to expire:
 The neighbor status becomes 2-way for the first time.
 The neighbor status changes from 2-way or a higher state to Init.
3.6 OSPF VPN
3.6.1 Definition
As an extension of OSPF, OSPF VPN multi-instance enables Provider Edges (PEs) and Customer
Edges (CEs) in VPNs to run OSPF for interworking and use OSPF to learn and advertise routes.
3.6.2 Purpose
As a widely used IGP, in most cases, OSPF runs in VPNs. If OSPF runs between PEs and CEs, and
PEs advertise VPN routes to CEs using OSPF, CEs do not need to support other routing protocols
for interworking with PEs. This simplifies management and configuration of CEs.
3.6.3 Running OSPF between PEs and CEs
In BGP/MPLS VPN, routing information is transmitted between PEs using Multi-Protocol

BGP (MP-BGP), whereas routes are learned and advertised between PEs and CEs using OSPF.
Running OSPF between PEs and CEs has the following benefits:
 OSPF is used in a site to learn routes. Running OSPF between PEs and CEs can reduce
the protocol types that CEs must support, reducing the requirements for CEs.
 Similarly, running OSPF both in a site and between PEs and CEs simplifies the workload of
network administrators. In this manner, network administrators do not have to be familiar
with multiple protocols.
 When a network using OSPF but not VPN on the backbone network begins to use
BGP/MPLS VPN, running OSPF between PEs and CEs facilitates the transition.
As shown in Figure 3-6-1, CE1, CE3, and CE4 belong to VPN 1, and the numbers following OSPF
refer to the process IDs of multiple OSPF instances running on PEs.
Figure 3-6-1 Running OSPF between PEs and CEs

The process of advertising routes of CE1 to CE3 and CE4 is as follows:
1. PE1 imports OSPF routes of CE1 into BGP and forms BGP VPNv4 routes.
2. PE1 advertises BGP VPNv4 routes to PE2 using MP-BGP.
3. PE2 imports BGP VPNv4 routes into OSPF, and then advertises these routes to CE3 and
CE4. The process of advertising routes of CE4 or CE3 to CE1 is the same as the preceding process.
3.6.4 Configuring OSPF Areas between PEs and CEs
OSPF areas between PEs and CEs can be either non-backbone areas or backbone areas (Area 0). A PE
can only be an area border router (ABR).
In the extended application of OSPF VPN, the MPLS VPN backbone network serves as Area 0. OSPF
requires that Area 0 be contiguous. Therefore, Area 0 of all VPN sites must be connected to the
MPLS VPN backbone network. If a VPN site has OSPF Area 0, the PEs that CEs access must be
connected to the backbone area of this VPN site through Area 0. If no physical link is available to
directly connect PEs to the backbone area, a virtual link can be used to implement logical connection
between the PEs and the backbone area, as shown in Figure 3-6-2.
Figure 3-6-2 Configuring OSPF areas between PEs and CEs

A non-backbone area (Area 1) is configured between PE1 and CE1, and a backbone area (Area 0) is
configured in Site 1. As a result, the backbone area in Site 1 is separated from the VPN backbone
area. Therefore, a virtual link is configured between PE1 and CE1 to ensure that the backbone area is
contiguous.
3.6.5 OSPF Domain ID
If inter-area routes are advertised between local and remote OSPF areas, these areas are considered
to be in the same OSPF domain.
 Domain IDs identify and differentiate different domains.
 Each OSPF domain has one or more domain IDs, one of which is a primary ID with the
others being secondary IDs.
 If an OSPF instance does not have a specific domain ID, its ID is considered as null.
Before advertising the remote routes sent by BGP to CEs, PEs need to determine the type of OSPF
routes (Type 3, Type 5 or Type 7) to be advertised to CEs according to domain IDs.
 If local domain IDs are the same as or compatible with remote domain IDs in BGP routes,
PEs advertise Type 3 routes.
 Otherwise, PEs advertise Type 5 or Type 7 routes.

Table 3-6-1 Domain ID
Both the local and remote domain IDs are null.
The remote domain ID is the same as the local primary domain ID or one of the local secondary domain IDs.
The remote domain ID is different from the local primary domain ID or any of the local secondary domain IDs.
3.6.6 Disabling Routing Loop Prevention
CAUTION:
Disabling routing loop prevention may cause routing loops. Exercise caution when performing
this operation.
During BGP or OSPF route exchanges, routing loop prevention prevents OSPF routing loops in
VPN
sites.
In the inter-AS VPN Option A scenario, if OSPF is running between ASBRs to transmit VPN
routes, the remote ASBR may be unable to learn the OSPF routes sent by the local ASBR due to the
routing loop prevention mechanism.
As shown in Figure 3-6-3, inter-AS VPN Option A is deployed. OSPF is running between PE1
and
CE1. CE1 sends VPN routes to CE2.
Figure 3-6-3 Networking diagram for inter-AS VPN Option A
1. PE1 learns routes to CE1 using the OSPF process in a VPN instance, and imports these
routes into MP-BGP, and sends the MP-BGP routes to ASBR1.
2. After having received the MP-BGP routes, ASBR1 imports the routes into the OSPF process
in a VPN instance and generates Type 3, Type 5, or Type 7 LSAs in which the DN bit is set to
1.
3. ASBR2 learns these LSAs using OSPF and checks the DN bit of each LSA. After learning that
the DN bit in each LSA is set to 1, ASBR2 does not add the routing information carried in
these LSAs to its routing table.
Due to the routing loop prevention mechanism, ASBR2 cannot learn the OSPF routes sent from
ASBR1, causing CE1 to be unable to communicate with CE3.
To address the preceding problem, use either of the following methods:
 A device does not set the DN bit to 1 in the LSAs when importing BGP routes into OSPF. For
example, ASBR1 does not set the DN bit to 1 when importing MP-BGP routes into OSPF.
After ASBR2 receives these routes and checks that the DN bit in the LSAs carrying these
routes is 0, ASBR2 adds the routes to its routing table.
 A device does not check the DN bit after having received LSAs. For example, ASBR1 sets
the DN bit to 1 in LSAs when importing MP-BGP routes into OSPF. ASBR2, however, does
not check the DN bit after having received these LSAs.
The preceding methods can be used more flexibly based on specific types of LSAs. For Type 3
LSAs, you can configure a sender to determine whether to set the DN bit to 1 or configure a receiver
to determine whether to check the DN bit in the Type 3 LSAs based on the router ID of the device
that generates the Type 3 LSAs.
In the inter-AS VPN Option A scenario shown in Figure 3-6-4, the four ASBRs are fully meshed
and run OSPF. ASBR2 may receive the Type 3, Type 5, or Type 7 LSAs generated on ASBR4. If
ASBR2 is not configured to check the DN bit in the LSAs, ASBR2 will accept the Type 3 LSAs, and
routing loops will occur, as described in Figure 3-6-4. ASBR2 will deny the Type 5 or Type 7 LSAs,
because
the VPN route tags carried in the LSAs are the same as the default VPN route tag of the OSPF
process on ASBR2.
To address the routing loop problem caused by Type 3 LSAs, configure ASBR2 not to check the DN
bit in the Type 3 LSAs that are generated by devices with the router ID 1.1.1.1 and the router ID
3.3.3.3. After the configuration is complete, if ASBR2 receives Type 3 LSAs sent by ASBR4 with the
router ID 4.4.4.4, ASBR2 will check the DN bit and deny these Type 3 LSAs because the DN bit is
set to 1.
Figure 3-6-4 Networking diagram for full-mesh ASBRs in the inter-AS VPN Option A
scenario
3.6.7 Routing Loop Prevention
Between PEs and CEs, routing loops may occur when OSPF and BGP learn routes from each other.
Figure 3-6-5 OSPF VPN routing loops
As shown in Figure 3-6-5, on PE1, OSPF imports a BGP route whose destination address is
10.1.1.1/32, and then generates and advertises a Type 5 or Type 7 LSA to CE1. Then, CE1 learns an
OSPF route with the destination address and next hop being 10.1.1.1/32 and PE1 respectively, and
advertises the route to PE2. In this manner, PE2 learns an OSPF route with the destination address
and next hop being 10.1.1.1/32 and CE1 respectively.
Similarly, CE1 also learns an OSPF route with the destination address and next hop being
10.1.1.1/32 and PE2 respectively. PE1 learns an OSPF route with the destination address and next
hop being
10.1.1.1/32 and CE1 respectively.
1210
As a result, CE1 has two equal-cost routes with next hops being PE1 and PE2 respectively, and
the next hops of the routes from PE1 and PE2 to 10.1.1.1/32 are CE1. Thus, a routing loop occurs.
In addition, the preference of an OSPF route is higher than that of a BGP route. Therefore, on PE1 an
d PE2, BGP routes to 10.1.1.1/32 are replaced by the OSPF route. That is, the OSPF route with the
destination address and next hop being 10.1.1.1/32 and CE1 respectively is active in the routing
tables of PE1 and PE2.
The BGP route then becomes inactive, and thus the LSA generated when this route is imported by
OSPF is deleted. This causes the OSPF route to be withdrawn. As a result, there is no OSPF route
in the routing table, and the BGP route becomes active again. This cycle causes route flapping.
OSPF VPN provides a solution to this problem, as shown in Table 3-6-2.
Table 3-6-2 Routing loop prevention
Feature
DN-bit
VPN Route Tag
Default Route
3.6.8 Multi-VPN-Instance CE
OSPF multi-instance generally runs on PEs. The devices that run OSPF multi-instance within the
LANs of users are called Multi-VPN-Instance CEs (MCEs), that is, multi-instance CEs.
Compared with OSPF multi-instance running on PEs, MCEs have the following
characteristics:
 MCEs do not need to support OSPF-BGP synchronization.
 MCEs establish different OSPF instances for different services. Different virtual CEs
transmit different services. This solves the security issue of the LAN at a low cost.
 MCEs implement different OSPF multi-instances on a CE. The key to implementing MCEs is
to disable loop detection and calculate routes directly. MCEs also need to use the received
LSAs with the ND-bit for route calculation.
3.7 OSPF NSSA
3.7.1 Definition
As defined in OSPF, stub areas cannot import external routes. This prevents a large number of
external routes from consuming bandwidth and storage resources of the Routers in stub areas. To
import
external routes and to prevent external routes from consuming resources, NSSAs are used, because
stub areas cannot meet requirements.
NSSAs are a new type of OSPF areas.
There are many similarities between NSSAs and stub areas. The difference between NSSAs and stub
areas is that NSSAs can import AS external routes into the entire OSPF AS and advertise the
imported routes in the OSPF AS, but do not learn external routes from other areas on the OSPF
network.
Figure 3-7-1 NSSA
N-bit
All Routers in an area must be configured with the same area type. In OSPF, the N-bit is carried in a
Hello packet and is used to identify the area type supported by the Router. OSPF neighbor
relationships cannot be established between Routers configured with different area types.
Some manufacturers do not comply with the standard and set the N-bit in both OSPF Hello and
DD packets. To allow Huawei devices to interwork with these manufacturers' devices, set the N-
bit in OSPF DD packets on Huawei devices.
Type 7 LSA
 Type 7 LSAs are a new type of LSAs that can only be used in NSSAs and describe the
imported external routes.
 Type 7 LSAs are generated by ASBRs in an NSSA and flooded only in the NSSA where the
ASBRs reside.
 When the ABRs in the NSSA receive these Type 7 LSAs, they translate some of the Type 7
LSAs into Type 5 LSAs to advertise AS external routes to the other areas on the OSPF network.
Translating Type 7 LSAs into Type 5 LSAs
To advertise the external routes imported by an NSSA to other areas, Type 7 LSAs need to be
translated into Type 5 LSAs so that the external routes can be advertised on the entire OSPF
network.
 The Propagate bit (P-bit) in a Type 7 LSA is used to instruct the Router whether to translate Type
7 LSAs into Type 5 LSAs.
 By default, the ABR with the largest router ID in an NSSA is responsible for translating Type 7
LSAs into Type 5 LSAs.
 Only the Type 7 LSAs in which the P-bit is set to 1 and the FA is not 0 can be translated into
Type 5 LSAs. The FA indicates that the packet to a specific destination address will be
forwarded to the address specified by the FA.
 The P-bit in the Type 7 LSAs generated by ABRs is not set to 1.
Preventing Loops Caused by Default Routes
There may be multiple ABRs in an NSSA. To prevent routing loops, these ABRs not to
calculate default routes advertised by each other.
3.8 OSPF Fast Convergence
OSPF fast convergence is an extended feature of OSPF to speed up route convergence.

The characteristics of OSPF fast convergence are as follows:
 Priority-based OSPF Convergence
 When certain routes on the network change, only the changed routes are recalculated. This
is called Partial Route Calculation (PRC).
 An intelligent timer is used to implement LSA management (the generating and receiving of
LSAs). With the intelligent timer, infrequent changes are responded to quickly, whereas
frequent changes are suppressed as desired.
To avoid excessive consumption of device resources by network connections or due to

frequent route flapping, RFC 2328 maintains that:
 After an LSA is generated, it cannot be generated again in five seconds. That is, the
interval for updating LSAs is one second.
 The interval for receiving LSAs is one second.
On a stable network where routes need to be fast converged, you can use the intelligent timer to
set the interval for receiving LSAs to 0 seconds. This ensures that topology or route changes
can be advertised to the network or be immediately sensed, thus speeding up route convergence
on the network.
 Route calculation is controlled through the intelligent timer.
When the network topology changes, devices need to recalculate routes according to OSPF.
This means that frequent changes in the network topology affect the performance of devices. To
address issue, RFC 2328 requires the use of a delay timer in route calculation so that route
calculation is performed only after the specified delay. But the delay suggested by RFC is a
fixed value, and cannot ensure both fast response to topology changes and effective suppression
of flapping.
By means of the intelligent timer, the delay in route calculation can be flexibly set as desir ed. As
a result, infrequent changes are responded to quickly, whereas frequent changes are suppressed
as desired.
 OSPF Smart-discover
3.8.1 OSPF NSR
Non-Stop Routing (NSR) is a routing technique that prevents a neighbor from sensing the fault on
the control plane of a device that provides a slave control plane. With NSR, when the control plane
of the device becomes faulty, the neighbor relationship set up through specific routing protocols,
MPLS, and other protocols that carry services are not interrupted.
As networks develop at a fast pace, operators are having increasingly higher requirements for
reliability of IP networks. NSR, as a high availability (HA) solution, is introduced to ensure that
services transmitted by a device are not affected when a hardware or software failure occurs on the
device.
OSPF NSR synchronizes the protocol data on the master MPU/SRU to the slave MPU/SRU in
real time. When the master MPU/SRU becomes faulty or needs to be upgraded, the slave
MPU/SRU rapidly takes over services from the master MPU/SRU without being sensed by the
neighbor. OSPF NSR synchronizes the real-time data between the master and slave MPUs/SRUs
in the following manners:
 OSPF backs up configuration data and dynamic data, including information about
interfaces, neighbors, and LSDBs.
 OSPF does not back up routes, shortest path trees (SPTs), and Traffic Engineering DataBases (TEDBs).
All these can be restored through the source data by using the database backup process.
 When the master-slave switchover occurs, the new master MPU/SRU restores the operation data
and takes over services from the former master MPU/SRU without being sensed by the neighbor.
3.8.2 Priority-based OSPF Convergence

Priority-based OSPF convergence ensures that specific routes converge first when a great number
of routes need to converge. Different routes can be set with different convergence priorities. This
allows important routes to converge first and therefore improves network reliability.
By using priority-based OSPF convergence, you can assign a higher convergence priority to routes
for key services so that those routes can converge fast. By so doing, the impact on key services is
reduced.
3.9 OSPF IP FRR
OSPF IP Fast Reroute (FRR) is dynamic IP FRR in which a backup link is pre-computed by an OSPF
based on the LSDBs on the entire network. The backup link is stored in the forwarding table to
protect traffic in the case of failures. In this manner, the failure recovery time can be reduced to less
than
50ms.
OSPF IP FRR complies with RFC 5286, that is, Basic Specification for IP Fast Reroute Loop-Free
Alternates, which protects traffic when links or nodes become faulty.
3.9.1 Background
With the development of networks, Voice over IP (VoIP) and online video services require high-
quality real-time transmission. Nevertheless, if an OSPF fault occurs, multiple processes, including
fault detection, LSP update, LSP flooding, route calculation, and FIB entry delivery, must be
performed to switch traffic to a new link. As a result, the fault recovery time is much greater than 50
ms, the time for users to sense traffic interruption, which cannot meet the requirement for real-time
services.
3.9.2 Implementation Principle
OSPF IP FRR pre-computes a backup link by using the Loop-Free Alternate (LFA) algorithm, and
then adds the backup link and the primary link to the forwarding table. In the case of failures, OSPF IP
FRR can fast switch traffic to the backup link before routes on the control plane converge. This
prevents traffic interruption and thus protects traffic and improves reliability of an OSPF network. The
Router supports IPv4 OSPF IP FRR.
In the LFA algorithm, considering a neighbor that can provide a backup link as the root node, the
neighbor computes the shortest path from itself to the destination of the primary link by using the
SPF algorithm. The neighbor then computes a loop-free backup link with the smallest cost by using
the inequality defined in RFC 5286.
OSPF IP FRR can filter backup routes that need to be added to the IP routing table. Only the
backup routes that are filtered through the filtering policy are added to the IP routing table. In this
manner, users can flexibly manage the addition of OSPF backup routes to the IP routing table.
3.9.3 Application Environment
OSPF IP FRR is classified into link protection and link-node dual protection. Distance_opt(X,Y)
indicates the shortest path between node X and node Y.
Link protection: indicates that the object to be protected is the traffic passing through an OSPF IP
FRR-enabled link. The link cost must satisfy the inequality Distance_opt(N, D) < Distance_opt(N, S) +
Distance_opt(S, D). S indicates the source node of traffic; N indicates the node on the backup link; D
indicates the destination node of traffic.
As shown in Figure 3-9-1, traffic is transmitted from Router S to RouterD. The link cost satisfies the
link protection inequality. When the primary link fails, Router S switches the traffic to the backup
link Router S -> Router N so that the traffic can be further transmitted along downstream paths. This
ensures that traffic interruption is less than 50ms.
Figure 3-9-1 OSPF IP FRR link protection

Link-node dual protection: Figure 3-9-2 shows link-node dual protection of OSPF IP FRR.
Node protection takes precedence over link protection.
Link-node dual protection must satisfy the following situations:
The link cost must satisfy the inequality Distance_opt(N, D) < Distance_opt(N, S) +
Distance_opt(S, D).
The interface cost of the router must satisfy the inequality Distance_opt(N, D) < Distance_opt(N, E)
+ Distance_opt(E, D).
S indicates the source node of traffic; E indicates the faulty node; N indicates the node on the
backup link; D indicates the destination node of traffic.
Figure 3-9-2 OSPF IP FRR link-node dual protection
3.10 Advertising Host Routes
Unlike in a data communication network, in an optical network, IP addresses of the same network
can be configured as belonging to different physical networks. As a result of this kind of IP address
planning, some host addresses may become unreachable. By configuring OSPF to advertise the
corresponding host routes (routes whose destinations are hosts) of interfaces in addition to
advertising network segment routes (routes whose destinations are network segments), you can
ensure that these host addresses are reachable.
Figure 3-10-1 IP address planning on a typical optical network
As shown in Figure 3-10-1, if the function of advertising host routes is not enabled, all routes
are advertised on the network in the form of 10.0.0.0/24. The next hop of the route from
RouterG to
10.0.0.0/24 is RouterE. As a result, 10.0.0.3, 10.0.0.4, and 10.0.0.6 become unreachable. To solve
this problem, you can configure OSPF to advertise host routes so that routes are advertised as host
addresses (such as 10.0.0.1/32).
3.11 OSPF-BGP Association
3.11.1 Definition
When a new device is deployed in the network or a device is restarted, network traffic may be
lost during BGP convergence. This is because IGP convergence is faster than BGP convergence.
This problem can be solved through the synchronization between OSPF and BGP.
3.11.2 Purpose
If a backup link exists, during traffic switchback, BGP traffic is lost because BGP route convergence
is slower than OSPF route convergence.
As shown in Figure 3-11-1, RouterA, RouterB, RouterC and RouterD run OSPF and establish IBGP
connections. RouterC functions as the backup of RouterB. When the network is stable, BGP and
OSPF routes converge completely on the device.
Normally, traffic from RouterA to 10.3.1.0/30 passes through RouterB. When RouterB becomes
faulty, traffic is switched to RouteC. After RouterB recovers, traffic is switched back to RouterB.
During this process, packet loss occurs.
This is because when traffic is switched back to RouterB, IGP route convergence is faster than
BGP route convergence. Consequently, convergence of OSPF routes is already complete when
BGP route convergence is still going on. As a result, RouterB does not know the route to
10.3.1.0/30.
Therefore, when packets from RouterA to 10.3.1.0/30 arrive at RouterB, they are discarded because
RouterB does not have the route to 10.3.1.0/30.
Figure 3-11-1 OSPF-BGP synchronization
3.11.3 Principle
The device enabled with OSPF-BGP synchronization remains as a stub router within the set
synchronization period. That is, the link metric in the LSA advertised by the device is the
maximum value 65535. Therefore, the device instructs other OSPF devices not to use it for data
forwarding.
As shown in Figure 3-11-1, OSPF-BGP synchronization is enabled on RouterB. In this situation,

before BGP route convergence is complete, RouterA continues to use the backup link RouterC
rather than forward traffic to RouterB until BGP route convergence on RouterB is complete.
3.12 OSPF GR
Routers generally operate with separation of the control plane and forwarding plane. When the
network topology remains stable, a restart of the control plane does not affect the forwarding plane,
and the forwarding plane can still forward data properly. This separation ensures non-stop service
forwarding.
In graceful restart (GR) mode, the forwarding plane continues to direct data forwarding after a
restart occurs. The actions on the control plane, such as re-establishment of neighbor relationships
and route calculation, do not affect the forwarding plane. Network reliability is improved because
service interruption caused by route flapping is prevented.
3.12.1 Basic Concepts of OSPF GR
As mentioned in chapter 4, Graceful Restart (GR) is a technology used to ensure normal

traffic forwarding and non-stop forwarding of key services during the restart of routing
protocols.
Unless otherwise stated, GR described in this section refers to the GR technology defined in RFC 3623.
GR is one of the high availability (HA) technologies, which comprise a set of comprehensive
technologies, such as fault-tolerant redundancy, link protection, faulty node recovery, and
traffic engineering. As a fault-tolerant redundancy technology, GR is widely used to ensure
non-stop forwarding of key services during master/slave switchover and system upgrade.
The following concepts are involved in GR:
 Grace-LSA
OSPF supports GR by flooding grace LSAs. Grace LSAs are used to inform the neighbor of the
GR time, cause, and interface address when the GR starts and ends.
 Role of a router during GR
 Restarter: is the router that restarts. The Restarter can be configured to support totally GR
or partly GR.
 Helper: is the router that helps the Restarter. The Helper can be configured to support
planned GR or unplanned GR or to selectively support GR through the configured
policies.
 Conditions that cause GR
 Unknown: indicates that GR is triggered for an unknown reason.
 Software restart: indicates that GR is triggered by commands.
 Software reload/upgrade: indicates that GR is triggered by software restart or upgrade.
 Switch to redundant control processor: indicates that GR is triggered by the

abnormal master/slave switchover.
 GR period
The GR period cannot exceed 1800 seconds. OSPF routers can exit from GR regardless
of whether GR succeeds or fails, without waiting for GR to expire.
3.12.2 Classification of OSPF GR
 Totally GR: indicates that when a neighbor of a router does not support GR, the router exits from
GR.
 Partly GR: indicates that when a neighbor does not support GR, only the interface associated
with this neighbor exits from GR, whereas the other interfaces perform GR normally.
 Planned GR: indicates that a router restarts or performs the master/slave switchover using
a command. The Restarter sends a grace LSA before restart or master/slave switchover.
 Unplanned GR: indicates that a router restarts or performs the master/slave switchover because
of faults. A router performs the master/slave switchover, without sending a grace LSA, and
then enters GR after the slave board goes Up. The process of unplanned GR is the same as that
of planned GR.
3.12.3 GR Process
 A router starts GR.
In planned GR mode, after master/slave switchover is triggered through a command, the

Restarter sends a grace LSA to all neighbors to notify them of the start, period, and cause of
GR, and then performs the master/slave switchover.
In unplanned GR, the Restarter does not send the grace LSA.
In unplanned GR mode, the Restarter sends a grace LSA immediately after the slave board
goes Up, informing neighbors of the start, period, and cause of GR. The Restarter then sends a
grace LSA to each neighbor five times consecutively. This ensures that neighbors receive the
grace LSA. This operation is proposed by manufacturers but not defined by the OSPF
protocol.
The Restarter sends a grace LSA to notify neighbors that it enters GR. During GR, neighbors
keep neighbor relationships with the Restarter so that other routers cannot detect the
switchover of the Restarter.
 The GR process runs, as shown in Figure 3-12-1
Figure 3-12-1 OSPF GR process
 The router exits from GR.
Table 3-12-1 Reasons that a router exits GR
Execution of GR
GR Before GR expires, t
succeeds.
GR fails.  GR expires, an
 Router LSA or

1210
Table 3-12-1 Reasons that a router exits GR
Execution of GR
 Status of the in
Restarter chang
 Restarter receiv
 The Restarter r
 On the same ne
3.12.4 Comparison between GR Mode and Non-GR Mode
Table 3-12-2 Comparison of master/slave switchover in the GR mode and non-GR mode
Switchover in Non-GR Mode
 OSPF neighbor relationships are re-established.
 Routes are recalculated.
 Forwarding table changes.
 Entire network detects route changes, and route flapping occurs for a short period of time.
 Packets are lost during forwarding, and services are interrupted.
3.13 OSPF-LDP Association
3.13.1 Definition
In the networking that uses primary and backup links, when the faulty primary link recovers, traffic
is switched from the backup link back to the primary link.
IGP route convergence completes before an LDP session is established. Consequently, the old LSP
is deleted before the new LSP is established and LSP traffic is interrupted.
3.13.2 Purpose
As shown in Figure 3-13-1, the primary link adopts the path PE1→P1→P2→P3→PE2, and
the backup link adopts the path PE1→P1→P4→P3→PE2.
When the primary link is faulty, traffic is switched to the backup link. After the primary link
recovers, traffic is switched back to the primary link. During this process, traffic is interrupted for a
long period of time.
Figure 3-13-1 OSPF-LDP association

Synchronizing LDP and IGP on P1 and P2 can shorten traffic interruption caused by traffic
switchover from the backup link to the primary link.
Table 3-13-1 OSPF-LDP association
Enabling Status of OSPF-LDP Association Traffic Interruption Time
Not enabled. Seconds level
Enabled. Milliseconds level
3.13.3 Principle
The principle of LDP-IGP synchronization is to delay route switchback by suppressing the

establishment of IGP neighbor relationships until LDP convergence is complete. That is, before an
LSP on the primary link is established, the backup link continues to forward traffic. Then the link is
deleted after the LSP is established.
Synchronization of LDP and IGP involves three timers:
 Hold-down
 Hold-max-cost
 Delay
After the primary link recovers, a router responds as follows:
1. Starts the hold-down timer. The IGP interface does not establish IGP neighbors but waits
for establishment of an LDP session. The Hold-down timer specifies the period that the IGP
interface waits.
2. Starts the hold-max-cost timer after the hold-down timer expires. The hold-max-cost timer
specifies the interval for advertising the maximum link metric of the interface in the Link
State Advertisement (LSA) to the primary link.
3. Starts the Delay timer to allow time for establishment of an LSP after an LDP session
is re-established for the faulty link.
After the Delay timer expires, LDP notifies IGP that synchronization is complete regardless
of the status of IGP.
3.14 OSPF Database Overflow
3.14.1 Definition
OSPF requires that routers in the same area have the same Link State Database (LSDB).
With the continuous increase in routes on the network, some routers fail to carry the additional
routing information because of limited system resources. This situation is called OSPF database
overflow.
3.14.2 Purpose
You can configure stub areas or NSSAs to solve the problem of the continuous increase in routing
information that causes the exhaustion of system resources of routers. However, configuring stub
areas or NSSAs cannot solve the problem when the unexpected increase in dynamic routes causes
database overflow. Setting the maximum number of external LSAs in the LSDB can dynamically
limit the LSDB capacity, to avoid the problems caused by database overflow.
3.14.3 Principle
To prevent database overflow, you can set the maximum number of non-default external routes on
a router.
All routers on the OSPF network must be set with the same upper limit. If the number of external
routes on a router reaches the upper limit, the router enters the Overflow state and starts an overflow
timer. The router automatically exits from the overflow state after the timer expires, By default, it is
5 seconds.
Table 3-14-1 OSPF database overflow
Overflow Phase
Entering overflow state
Staying in overflow state
Exiting from the overflow state
3.15 OSPF Mesh-Group
3.15.1 Definition
In the scenario where there are multiple concurrent links, you can deploy OSPF mesh-group to
classify links into a mesh group. Then, OSPF floods LSAs to only a link selected from the mesh
group. Using OSPF mesh-group prevents unnecessary burden on the system caused by repetitive
flooding.
The mesh-group feature is disabled by default.
3.15.2 Purpose
After receiving or generating an LSA, an OSPF process floods the LSA. When there are
multiple concurrent links, OSPF floods the LSA to each link and sends Update messages.
In this scenario, if there are 2000 concurrent links, OSPF floods each LSA 2000 times. Only
one flooding, however, is valid. The other 1999 times are useless repetition.
To prevent burden on the system caused by repetitive flooding, you can enable mesh -group to
classify multiple concurrent links between a router and its neighbor into a group and then select a
primary link to use for flooding.
3.15.3 Principles
As shown in Figure 3-15-1, RouterA and RouterB, which are connected through three links,
establish an OSPF neighbor relationship. After receiving a new LSA from interface 4, RouterA
floods the LSA to RouterB through interfaces 1, 2, and 3.
This flooding causes a heavy load on the concurrent links. For the neighbor with concurrent links,
only a primary link is selected to flood the LSA.
Figure 3-15-1 LSA flooding with OSPF mesh-group disabled
When multiple concurrent links exist between a device enabled with OSPF mesh-group and its
neighbor, the device selects primary link to flood the received LSAs, as shown in Figure 3-15-
2.
As defined in OSPF, LSAs can be flooded to a link only when the neighbor status is not lower than
Exchange. In this case, when the status of the interface on the primary link is lower than Exchange,
OSPF reselects a primary link from the concurrent links and then floods the LSA. After receiving the
LSA flooded by RouterA from link 1, RouterB no longer floods the LSA to RouterA through
interfaces
2 and 3.
Figure 3-15-2 LSA flooding with OSPF mesh-group enabled
As defined by the mesh-group feature, the Router ID of a neighbor uniquely identifies the mesh
group. Interfaces connected to the same neighbor that have a status greater than Exchange belong to
the same mesh group.
In Figure 3-15-3, a mesh group of RouterA resides in Area 0, which contains the links of interface
1 and interface 2. More than one neighbor of interface 3 resides on the broadcast link. Therefore,
interface 3 cannot be defined as part of the mesh group.
Figure 3-15-3 Interface not added to mesh group
NOTE:
After a router is enabled with mesh-group, if the Router IDs of the router and its directly connected
neighbor are the same, LSDBs cannot be synchronized and routes cannot be calculated correctly. In
this case, you need to reconfigure the Router ID of the neighbor.
3.16 Example for Configuring of

OSPF
3.16.1 Example for Configuring Basic OSPF Functions
As shown in Figure 3-16-1, all routers run OSPF, and the entire AS is divided into three
areas. RouterA and RouterB serve as ABRs to forward routes between areas.
After the configuration, each router should learn the routes from the AS to all network
segments.
Figure 3-16-1 Networking diagram of configuring basic OSPF functions
1. Enable OSPF on each router.
2. Specify network segments in different areas.
Procedure
The configuration details are not mentioned here.
2. Configure basic OSPF functions.
[RouterA] router id 1.1.1.1

[RouterA] ospf
[RouterA-ospf-1] area 0
[RouterA-ospf-1-area-0.0.0.0] network 192.168.0.0 0.0.0.255
[RouterA-ospf-1-area-0.0.0.0] quit
[RouterB] router id 2.2.2.2

[RouterB] ospf
[RouterB-ospf-1] area 0
[RouterB-ospf-1-area-0.0.0.0] network 192.168.0.0 0.0.0.255
[RouterB-ospf-1-area-0.0.0.0] quit
[RouterC] router id 3.3.3.3

[RouterC] ospf
[RouterC-ospf-1] area 1
[RouterC-ospf-1-area-0.0.0.1] network 192.168.1.0 0.0.0.255
[RouterC-ospf-1-area-0.0.0.1] quit
[RouterD] router id 4.4.4.4

[RouterD] ospf
[RouterD-ospf-1] area 2
[RouterD-ospf-1-area-0.0.0.2] network 192.168.2.0
0.0.0.255 [RouterD-ospf-1-area-0.0.0.2] network 172.17.1.0
0.0.0.255 [RouterD-ospf-1-area-0.0.0.2] quit
# Configure RouterE.
[RouterE] router id 5.5.5.5

[RouterE] ospf
[RouterE-ospf-1] area 1
[RouterE-ospf-1-area-0.0.0.1] network 172.16.1.0 0.0.0.255
[RouterE-ospf-1-area-0.0.0.1] quit
# Configure RouterF.
[RouterF] router id 6.6.6.6

[RouterF] ospf
[RouterF-ospf-1] area 2
[RouterF-ospf-1-area-0.0.0.2] network 172.17.1.0 0.0.0.255
[RouterF-ospf-1-area-0.0.0.2] quit
# View OSPF neighbors of RouterA.
[RouterA] display ospf peer

OSPF Process 1 with Router ID 1.1.1.1
Neighbors
Area 0.0.0.0 interface 192.168.0.1(GigabitEthernet1/0/0)'s neighbors
Router ID: 2.2.2.2 Address: 192.168.0.2
State: Full Mode:Nbr is Master Priority: 1
DR: 192.168.0.2 BDR: 192.168.0.1 MTU: 0
Dead timer due in 36 sec
Retrans timer interval: 5
Neighbor is up for 00:15:04
Authentication Sequence: [ 0 ]
Neighbors
DR: 192.168.1.2 BDR: 192.168.1.1 MTU: 0
# View the OSPF routing information of RouterA.
[RouterA] display ospf routing

Routing Tables
Routing for Network
Destination Cost Type NextHop AdvRouter Area
172.16.1.0/24 2 Transit 192.168.1.2 3.3.3.3 0.0.0.1
172.17.1.0/24 3 Inter-area 192.168.0.2 2.2.2.2 0.0.0.0
192.168.0.0/24 1 Transit 192.168.0.1 1.1.1.1 0.0.0.0
192.168.1.0/24 1 Transit 192.168.1.1 1.1.1.1 0.0.0.1
192.168.2.0/24 2 Inter-area 192.168.0.2 2.2.2.2 0.0.0.0
Total Nets: 5
Intra Area: 3 Inter Area: 2 ASE: 0 NSSA: 0
# View the LSDB of RouterA.

[RouterA] display ospf lsdb
Link State Database
Area: 0.0.0.0
Type LinkState ID AdvRouter Age Len Sequence Metric
Router 2.2.2.2
Router 1.1.1.1
Network 192.168.0.2
Sum-Net 172.16.1.0
Sum-Net 172.17.1.0
Sum-Net 192.168.2.0
Sum-Net 192.168.1.0
Type LinkState ID
Router 5.5.5.5
Router 3.3.3.3
Router 1.1.1.1
Network 192.168.1.1
Network 172.16.1.1
Sum-Net 172.17.1.0
Sum-Net 192.168.2.0
Sum-Net 192.168.0.0
# View the routing table of RouterD and test connectivity by using the ping command.
[RouterD] display ospf routing

Routing Tables
Routing for Network
172.16.1.0/24 4 Inter-area 192.168.2.1 2.2.2.2 0.0.0.2
172.17.1.0/24 1 Transit 172.17.1.1 4.4.4.4 0.0.0.2
192.168.0.0/24 2 Inter-area 192.168.2.1 2.2.2.2 0.0.0.2
192.168.1.0/24 3 Inter-area 192.168.2.1 2.2.2.2 0.0.0.2
192.168.2.0/24 1 Transit 192.168.2.2 4.4.4.4 0.0.0.2
Total Nets: 5
[RouterD] ping 172.16.1.1
PING 172.16.1.1: 56 data bytes, press CTRL_C to break
Reply from 172.16.1.1: bytes=56 Sequence=1 ttl=253 time=62 ms

1210
--- 172.16.1.1 ping statistics ---
5 packet(s) transmitted
5 packet(s) received
0.00% packet loss
round-trip min/avg/max = 16/59/94 ms
Configuration Files
#
sysname RouterA
#
ip address 192.168.0.1 255.255.255.0
#
ip address 192.168.1.1 255.255.255.0
#
ospf 1
area 0.0.0.0
network 192.168.0.0 0.0.0.255
area 0.0.0.1
network 192.168.1.0 0.0.0.255
#
return
#
sysname RouterB
#
router id 2.2.2.2
#
ip address 192.168.0.2 255.255.255.0
#
ip address 192.168.2.1 255.255.255.0
#
ospf 1
area 0.0.0.0
network 192.168.0.0 0.0.0.255
area 0.0.0.2
network 192.168.2.0 0.0.0.255
#
return
#
sysname RouterC
#
router id 3.3.3.3
#
ip address 192.168.1.2 255.255.255.0
#
ip address 172.16.1.1 255.255.255.0
#
ospf 1
area 0.0.0.1
network 192.168.1.0 0.0.0.255
network 172.16.1.0 0.0.0.255
#
return
#
sysname RouterD
#
router id 4.4.4.4
#
ip address 192.168.2.2 255.255.255.0
#
ip address 172.17.1.1 255.255.255.0
#
ospf 1
area 0.0.0.2
network 192.168.2.0 0.0.0.255
network 172.17.1.0 0.0.0.255
#
return
 Configuration file of RouterE
#
sysname RouterE
#
router id 5.5.5.5
#
ip address 172.16.1.2 255.255.255.0
#
ospf 1
area 0.0.0.1
network 172.16.1.0 0.0.0.255
#
return
 Configuration file of RouterF
#
sysname RouterF
#
router id 6.6.6.6
#
ip address 172.17.1.2 255.255.255.0
#
ospf 1
area 0.0.0.2
network 172.17.1.0 0.0.0.255
#
return
3.16.2 Example for Configuring OSPF Virtual Links
As shown in Figure 3-16-2, Area 2 does not connect to the backbone area directly. Area 1 serves as
a transit area to connect Area 2 and Area 0. A virtual link is configured between RouterA and
RouterB.
Figure 3-16-2 Configuring OSPF virtual links
1. Configure basic OSPF functions on each router.
2. Configure virtual connections on RouterA and RouterB to connect the backbone area with
the non-backbone area.
Procedure
[RouterA] ospf 1 router-id 1.1.1.1

[RouterB] ospf 1 router-id 2.2.2.2

[RouterC] ospf 1 router-id 3.3.3.3

[RouterD] ospf 1 router-id 4.4.4.4

[RouterD-ospf-1-area-0.0.0.2] network 172.16.0.0 0.0.255.255
[RouterD-ospf-1-area-0.0.0.2] quit
# View the OSPF routing table of RouterA.

NOTE:
The routing table of RouterA does not contain routes in Area 2 because Area 2 is not
directly connected to Area 0.
Routing Tables
Routing for Network
10.0.0.0/8 1 Transit 10.1.1.1 1.1.1.1 0.0.0.0
192.168.1.0/24 1 Transit 192.168.1.1 1.1.1.1 0.0.0.1
Total Nets: 2
3. Configure virtual links.
[RouterA] ospf 1
[RouterA-ospf-1-area-0.0.0.1] vlink-peer 2.2.2.2
[RouterB] ospf 1
[RouterB-ospf-1-area-0.0.0.1] vlink-peer 1.1.1.1
# View the OSPF routing table of RouterA.

Routing Tables
Routing for Network
172.16.0.0/16 2 Inter-area 192.168.1.2 2.2.2.2 0.0.0.2
10.0.0.0/8 1 Transit 10.1.1.1 1.1.1.1 0.0.0.0
192.168.1.0/24 1 Transit 192.168.1.1 1.1.1.1 0.0.0.1
Total Nets: 3
Configuration Files
#
sysname RouterA
#
ip address 192.168.1.1 255.255.255.0
#
ip address 10.1.1.1 255.0.0.0
#
ospf 1 router-id 1.1.1.1
area 0.0.0.0
network 10.0.0.0 0.255.255.255
area 0.0.0.1
network 192.168.1.0 0.0.0.255
vlink-peer 2.2.2.2
#
return
#
sysname RouterB
#
ip address 192.168.1.2 255.255.255.0
#
ip address 172.16.1.1 255.255.0.0
#
area 0.0.0.1
network 192.168.1.0 0.0.0.255
vlink-peer 1.1.1.1
area 0.0.0.2
network 172.16.0.0 0.0.255.255
#
return
#
sysname RouterC
#
ip address 10.1.1.2 255.0.0.0
#
area 0.0.0.0
network 10.0.0.0 0.255.255.255
#
return
#
sysname RouterD
#
ip address 172.16.1.2 255.255.0.0
#
area 0.0.0.2
network 172.16.0.0 0.0.255.255
#
return
3.16.3 Example for Configuring DR Election of OSPF
As shown in Figure 3-16-3, RouterA has the highest priority (100) in the network and is elected as
the DR. RouterC has the second highest priority, and is elected as the BDR. The priority of RouterB
is 0, and RouterB cannot be elected as the DR or BDR. The priority of RouterD is not configured and
its default value is 1.
Figure 3-16-3 Configuring DR election of OSPF
1. Configure the router ID on each router, enable OSPF, and specify the network segment.
2. Check the DR/BDR status of each router with the default priority.
3. Configure the DR priority of the interface and check the DR/BDR status.
Procedure

[RouterA] ospf

[RouterB] ospf

[RouterC] ospf

[RouterD] ospf
# View the DR/BDR status.
[RouterA] display ospf peer

Neighbors
DR: 192.168.1.4 BDR: 192.168.1.3 MTU: 0
DR: 192.168.1.4 BDR: 192.168.1.3 MTU: 0
DR: 192.168.1.4 BDR: 192.168.1.3 MTU: 0
# View the neighbor information of RouterA. You can see the priority of DR and the
neighbor status. The RouterD is the DR, and RouterC is the BDR.
NOTE:
When the priority is the same, the router with a higher router ID is elected as the DR. If a new
router is added after the DR/BDR election is complete, the new router cannot become the DR
even if it has the highest priority.
3. Configure DR priorities on interfaces.

[RouterA-GigabitEthernet1/0/0] ospf dr-priority 100

[RouterB-GigabitEthernet1/0/0] ospf dr-priority 0

[RouterC-GigabitEthernet1/0/0] ospf dr-priority 2

# View the DR/BDR status.
[RouterD] display ospf peer

Neighbors
State: Full Mode:Nbr is Slave Priority: 100
DR: 192.168.1.4 BDR: 192.168.1.3 MTU: 0
DR: 192.168.1.4 BDR: 192.168.1.3 MTU: 0
DR: 192.168.1.4 BDR: 192.168.1.3 MTU: 0
4. Restart OSPF processes.
In the user view of each router, run the reset ospf 1 process command to restart the OSPF
process.
5. View the configuration.
# View the status of OSPF neighbors.
[RouterD] display ospf peer

Neighbors
DR: 192.168.1.1 BDR: 192.168.1.3 MTU: 0

1210
DR: 192.168.1.1 BDR: 192.168.1.3 MTU: 0
DR: 192.168.1.1 BDR: 192.168.1.3 MTU: 0
# View the status of the OSPF interface.
[RouterA] display ospf interface

Interfaces
Area: 0.0.0.0
IP Address Type State Cost Pri DR BDR
192.168.1.1 Broadcast DR 1 100 192.168.1.1 192.168.1.3
[RouterB] display ospf interface
Interfaces
Area: 0.0.0.0
IP Address Type State Cost Pri DR BDR
192.168.1.2 Broadcast DROther 1 0 192.168.1.1 192.168.1.3
If all neighbors are in the Full state, it indicates that RouterA establishes the neighbor
relationship with its neighbor. If the neighbor stays "2-Way", it indicates both of them are
not the DR or BDR. They need not exchange LSAs.
If the status of the OSPF interface is DROther, it indicates that it is neither DR nor BDR.
Configuration Files

#
sysname RouterA
#
router id 1.1.1.1
#
ip address 192.168.1.1 255.255.255.0
ospf dr-priority 100
#
ospf 1
area 0.0.0.0
network 192.168.1.0 0.0.0.255
#
return
#
sysname RouterB
#
router id 2.2.2.2
#
ip address 192.168.1.2 255.255.255.0
ospf dr-priority 0
#
ospf 1
area 0.0.0.0
network 192.168.1.0 0.0.0.255
#
return
#
sysname RouterC
#
router id 3.3.3.3
#
ip address 192.168.1.3 255.255.255.0
ospf dr-priority 2
#
ospf 1
area 0.0.0.0
network 192.168.1.0 0.0.0.255
#
return
#
sysname RouterD
#
router id 4.4.4.4
#
ip address 192.168.1.4 255.255.255.0
#
ospf 1
area 0.0.0.0
network 192.168.1.0 0.0.0.255
#
return
3.16.4 Example for Configuring OSPF Stub Areas
As shown in Figure 3-16-4, all routers run OSPF, and the entire AS is divided into three areas.
RouterA and RouterB serve as ABRs to forward routes between areas. RouterD serves as an ASBR
to import external routes (static routes).
It is required to configure Area 1 as a stub area to reduce the LSAs advertised to this area
without affecting the route reachability.
Figure 3-16-4 Configuring OSPF stub areas
1. Enable OSPF on each router, and configure basic OSPF functions.
2. Configure static routes on RouterD, and import them into OSPF.
3. Configure Area 1 as a stub area, and check the OSPF routing information on RouterC.
4. Stop RouterA from advertising Type 3 LSAs to the stub area, and check the OSPF
routing information on RouterC.
Procedure
2. Configure basic OSPF functions (see Example for Configuring Basic OSPF Functions).
3. Configure RouterD to import static routes.
[RouterD] ip route-static 200.0.0.0 8 null 0

[RouterD] ospf
[RouterD-ospf-1] import-route static type 1
[RouterD-ospf-1] quit
# View ABR/ASBR information on RouterC.
[RouterC] display ospf abr-asbr

Routing Table to ABR and ASBR
RtType
Intra-area
Inter-area
# View the OSPF routing table of RouterC.

NOTE:
When RouterC is in a common area, there are AS external routes in the routing
table. [RouterC] display ospf routing

Routing Tables
Routing for Network
172.16.1.0/24 1 Transit
172.17.1.0/24 4 Inter-area
192.168.0.0/24 2 Inter-area
192.168.1.0/24 1 Transit
192.168.2.0/24 3 Inter-area
Routing for ASEs
Destination Cost Type
200.0.0.0/8 4 Type1
Total Nets: 6
Intra Area: 2 Inter Area: 3 ASE: 1
4. Configure Area 1 as a stub area.
[RouterA] ospf
[RouterA-ospf-1-area-0.0.0.1] stub
[RouterC] ospf

1210
[RouterC-ospf-1-area-0.0.0.1] stub
[RouterE] ospf
[RouterE-ospf-1] area 1
[RouterE-ospf-1-area-0.0.0.1] stub
[RouterE-ospf-1-area-0.0.0.1] quit
# View the routing table of RouterC.

NOTE:
After the area where RouterC resides is configured as a stub area, AS external routes
are invisible. Instead, there is a default route.
[RouterC] display ospf routing
Routing Tables
Routing for Network
0.0.0.0/0 2 Inter-area 192.168.1.1 1.1.1.1 0.0.0.1
172.16.1.0/24 1 Transit 172.16.1.1 3.3.3.3 0.0.0.1
172.17.1.0/24 4 Inter-area 192.168.1.1 1.1.1.1 0.0.0.1
192.168.0.0/24 2 Inter-area 192.168.1.1 1.1.1.1 0.0.0.1
192.168.1.0/24 1 Transit 192.168.1.2 3.3.3.3 0.0.0.1
192.168.2.0/24 3 Inter-area 192.168.1.1 1.1.1.1 0.0.0.1
Total Nets: 6
5. # Stop RouterA from advertising Type 3 LSAs to the stub area.
[RouterA] ospf
[RouterA-ospf-1-area-0.0.0.1] stub no-summary
# View the OSPF routing table of RouterC.

Routing Tables
Routing for Network
0.0.0.0/0 2 Inter-area 192.168.1.1 1.1.1.1 0.0.0.1
172.16.1.0/24
192.168.1.0/24
Total Nets: 3
NOTE:
After the advertisement of summary LSAs to a stub area is disabled, the routing entries of the
stub router are further reduced, and only the default route to a destination outside the AS is
reserved.
Configuration Files
NOTE:
The configuration files of RouterB and RouterF are the same as those in the Example for Configuring
Basic OSPF Functions, and are not mentioned here.
#
sysname RouterA
#
router id 1.1.1.1
#
ip address 192.168.0.1 255.255.255.0
#
ip address 192.168.1.1 255.255.255.0
#
ospf 1
area 0.0.0.0
network 192.168.0.0 0.0.0.255
area 0.0.0.1
network 192.168.1.0 0.0.0.255
stub no-summary
#
return
#
sysname RouterC
#
router id 3.3.3.3
#
ip address 192.168.1.2 255.255.255.0
#
ip address 172.16.1.1 255.255.255.0
#
ospf 1
area 0.0.0.1
network 192.168.1.0 0.0.0.255
network 172.16.1.0 0.0.0.255
stub
#
return
#
sysname RouterD
#
router id 4.4.4.4
#
ip address 192.168.2.2 255.255.255.0
#
ip address 172.17.1.1 255.255.255.0
#
ospf 1
import-route static type 1
area 0.0.0.2
network 192.168.2.0 0.0.0.255
network 172.17.1.0 0.0.0.255
#
#
return
#
sysname RouterE
#
router id 5.5.5.5
#
ip address 172.16.1.2 255.255.255.0
#
ospf 1
area 0.0.0.1
network 172.16.1.0 0.0.0.255
stub
#
return
3.16.5 Example for Configuring OSPF NSSAs
As shown in Figure 3-16-5, all routers run OSPF, and the entire AS is divided into two areas.
RouterA and RouterB serve as ABRs to forward routes between areas. RouterD serves as an ASBR to
import external routes (static routes).
It is required to configure Area 1 as an NSSA. Configure RouterA and RouterB as translators in the
NSSA, configure RouterD as an ASBR to import external routes (static routes) and correctly
transmit routing information inside the AS.
Figure 3-16-5 Configuring an OSPF NSSA

1210
1. Enable OSPF on each router, and configure basic OSPF functions.
2. Configure Area 1 as an NSSA (run the nssa command on all routers in Area 1), and check the
OSPF routing information and LSDB of RouterC.
3. Configure static routes on RouterD, and import them into OSPF.
4. Configure translators in the NSSA.
Procedure
3. Configure Area 1 as an NSSA.
[RouterA] ospf
[RouterA-ospf-1-area-0.0.0.1] nssa
[RouterB] ospf
[RouterB-ospf-1-area-0.0.0.1] nssa
[RouterD] ospf
[RouterD-ospf-1-area-0.0.0.1] nssa
4. Configure RouterD to import static routes.
[RouterD] ip route-static 100.0.0.0 8 null 0

[RouterD] ospf
[RouterD-ospf-1] import-route static
[RouterD-ospf-1] quit
# Display the OSPF routing table of RouterC.
NOTE:
 On RouterC, you can view that the router ID of the advertising router that imports AS
external routes in the NSSA, that is, the router ID of RouterB is 2.2.2.2.
 OSPF selects the ABR with larger router ID as a
translator. [RouterC] display ospf routing

Routing Tables
Routing for Network

Destination
192.168.3.0/24
192.168.4.0/24
192.168.0.0/24
192.168.1.0/24
192.168.1.0/24
192.168.2.0/24
Routing for ASEs

Destination
100.0.0.0/8
Total Nets: 7
# Display the OSPF LSDB of RouterC.
[RouterC] display ospf lsdb

Link State Database
Type LinkState ID
Router 3.3.3.3
Router 2.2.2.2
Router 1.1.1.1
Network 192.168.0.2
Network 192.168.2.2
Sum-Net 192.168.4.0
Sum-Net 192.168.
Sum-Net 192.168.
Sum-Net 192.168.
Sum-Net 192.168.
Sum-Net 192.168.
AS External Database
External 100.0.0.0 2.2.2.2 257 36 80000002 1
5. Configure RouterA as a translator.
[RouterA] ospf
[RouterA-ospf-1-area-0.0.0.1] nssa default-route-advertise no-summary translator-always
[RouterA-ospf-1] quit
# Display the OSPF routing table of RouterC.

NOTE:
On RouterC, an AS external route is imported.


Routing Tables
Routing for Network

Destination
192.168.3.0/24
192.168.4.0/24
192.168.0.0/24
192.168.1.0/24
192.168.1.0/24
192.168.2.0/24
Routing for ASEs

Destination
100.0.0.0/8
Total Nets: 7
NOTE:
 On RouterC, the router ID of the advertising router that imports AS external routes to the
NSSA changes to 1.1.1.1. That is, RouterA becomes the translator.
 By default, the new translator, together with the former translator, acts as the translator for
40s. After 40s, only the new translator continues to work as a translator.
# Display the OSPF LSDB of RouterC.
[RouterC] display ospf lsdb

Link State Database
Type LinkState ID
Router 3.3.3.3
Router 2.2.2.2
Router 1.1.1.1
Network 192.168.0.2
Network 192.168.2.2
Sum-Net 192.168.4.0
Sum-Net 192.168.4.0
Sum-Net 192.168.3.0
Sum-Net 192.168.3.0
Sum-Net 192.168.1.0
Sum-Net 192.168.1.0
AS External Database
External 100.0.0.0 1.1.1.1 248 36 80000001 1
Configuration Files
#
sysname RouterA
#
router id 1.1.1.1
#
ip address 192.168.0.1 255.255.255.0
#
ip address 192.168.3.1 255.255.255.0
#
ip address 192.168.1.1 255.255.255.0
#
ospf 1
area 0.0.0.0
network 192.168.0.0 0.0.0.255
area 0.0.0.1
network 192.168.1.0 0.0.0.255
network 192.168.3.0 0.0.0.255
nssa default-route-advertise no-summary translator-always
#
return
#
sysname RouterB
#
router id 2.2.2.2
#
ip address 192.168.1.2 255.255.255.0
#
ip address 192.168.2.1 255.255.255.0
#
ip address 192.168.4.2 255.255.255.0
#
ospf 1
area 0.0.0.0
network 192.168.2.0 0.0.0.255
area 0.0.0.1
network 192.168.1.0 0.0.0.255
network 192.168.4.0 0.0.0.255
nssa
#
return
#
sysname RouterC
#
router id 3.3.3.3
#
ip address 192.168.0.2 255.255.255.0
#
ip address 192.168.2.2 255.255.255.0
#
ospf 1
area 0.0.0.0
network 192.168.0.0 0.0.0.255
network 192.168.2.0 0.0.0.255
#
return
#
sysname RouterD
#
router id 4.4.4.4
#
ip address 192.168.3.2 255.255.255.0
#
ip address 192.168.4.1 255.255.255.0
#
ospf 1
import-route static
area 0.0.0.1
network 192.168.3.0 0.0.0.255
network 192.168.4.0 0.0.0.255
nssa
#
#
return
3.16.6 Example for Configuring OSPF IP FRR
When a fault occurs on the network, OSPF IP FRR can fast switch traffic to the backup link
without waiting for route convergence. This ensures uninterrupted traffic transmission.
As shown in Figure 3-16-6:
 OSPF runs on the four routers in the same area.
 If the link between RouterA and RouterC becomes faulty, the traffic forwarded by RouterA
is rapidly switched to the backup link and forwarded through RouterB.
Figure 3-16-6 Networking diagram for configuring OSPF IP FRR
1. Configure basic OSPF functions on each router.
2. Set the cost to ensure that the link from RouterA to RouterC is preferred.
3. Enable OSPF IP FRR on RouterA to protect the traffic forwarded by RouterA.

Procedure
1. Configure an IP address and the cost for each interface. This example assumes that you
know the configuration method and no details are provided here.

[RouterA] ospf

[RouterB] ospf

[RouterC] ospf

[RouterD] ospf
3. Enable OSPF IP FRR on RouterA.
# Enable OSPF IP FRR on RouterA.
[RouterA] ospf
[RouterA-ospf-1] frr
[RouterA-ospf-1-frr] loop-free-alternate

# View information about the route from RouterA to RouterD. You can find that OSPF
generates a backup route because OSPF IP FRR is enabled.
<RouterA> display ospf routing router-id 4.4.4.4
Destination : 4.4.4.4 Route Type : Intra-area

Area : 0.0.0.1 AdvRouter : 4.4.4.4
Type : Normal Age : 00h31m27s
URT Cost : 59
NextHop : 1.3.1.3 Interface : GigabitEthernet1/0/2
Backup Nexthop : 1.2.1.2 Backup Interface : GigabitEthernet1/0/1
Backup Type : LFA LINK
The preceding display shows that a backup route is generated on RouterA.
Configuration Files
#
sysname RouterA
#
router-id 1.1.1.1
#
ip address 1.2.1.1 255.255.255.0
ospf cost 9
#
ip address 1.3.1.1 255.255.255.0
ospf cost 4
#
ospf 1
frr
loop-free-alternate
area 0.0.0.1
network 1.2.1.0 0.0.0.255
network 1.3.1.0 0.0.0.255
#
return
#
sysname RouterB
#
router-id 2.2.2.2
#
ip address 1.2.1.2 255.255.255.0
ospf cost 9
#
ip address 2.3.1.2 255.255.255.0
ospf cost 5
#
ospf 1
area 0.0.0.1
network 2.3.1.0 0.0.0.255
network 1.2.1.0 0.0.0.255
#
return
#
sysname RouterC
#
router-id 3.3.3.3
#
ip address 1.3.1.3 255.255.255.0
ospf cost 4
#
ip address 3.4.1.3 255.255.255.0
ospf cost 55
#
ip address 2.3.1.3 255.255.255.0
ospf cost 5
#
ospf 1

1210
area 0.0.0.1
network 2.3.1.0 0.0.0.255
network 1.3.1.0 0.0.0.255
network 3.4.1.0 0.0.0.255
#
return
#
sysname RouterD
#
router-id 4.4.4.4
#
ip address 3.4.1.4 255.255.255.0
ospf cost 55
#
ospf 1
area 0.0.0.1
network 3.4.1.0 0.0.0.255
#
return
3.16.7 Example for Configuring BFD for OSPF
As shown in Figure 3-16-7, it is required as follows:
 Run OSPF between RouterA, RouterB, and RouterC.
 Enable BFD of the OSPF process on RouterA, RouterB, and RouterC.
 Traffic is transmitted on the active link RouterA → RouterB. The link RouterA → RouterC →
RouterB acts as the standby link.
 BFD of the interface is configured on the link between RouterA and RouterB. When a fault
occurs on the link, BFD can quickly detect the fault and notify OSPF of the fault; therefore,
the traffic is transmitted on the standby link.
Figure 3-16-7 Networking diagram for configuring BFD for OSPF
1. Enable the basic OSPF functions on each router.
2. Enable global BFD.
3. Enable the detection mechanism on RouterA and RouterB.
Procedure
1. Assign an IP address to each router interface.
The detailed configuration is not mentioned here.
2. Configure the basic OSPF functions.

[RouterA] ospf

[RouterB] ospf
[RouterB-ospf-1] quit

[RouterC] ospf
[RouterC-ospf-1] quit
# After the preceding configurations are complete, run the display ospf peer command. You
can view that the neighboring relationship is set up between RouterA, RouterB, and
RouterC.
Take the display of RouterA as an example:
<RouterA> display ospf peer

Neighbors
DR: 1.1.1.1 BDR: 1.1.1.2 MTU: 0
Neighbors
DR: 3.3.3.1 BDR: 3.3.3.2 MTU: 0
# Display the information in the OSPF routing table on RouterA. You can view the routing
entries to RouterB and RouterC. The next hop address of the route to 172.16.1.0/24 is
3.3.3.2
and traffic is transmitted on the active link RouterA → RouterB.
<RouterA> display ospf routing

Routing Tables
Routing for Network
172.16.1.0/24 2 Transit 3.3.3.2 2.2.2.2 0.0.0.0
3.3.3.0/24 1 Transit 3.3.3.1 1.1.1.1 0.0.0.0
2.2.2.0/24 2 Transit 3.3.3.2 2.2.2.2 0.0.0.0
2.2.2.0/24 2 Transit 1.1.1.2 2.2.2.2 0.0.0.0
1.1.1.0/24 1 Transit 1.1.1.1 1.1.1.1 0.0.0.0
Total Nets: 5
3. Configure OSPF BFD.
# Enable global BFD on RouterA.
[RouterA] bfd
[RouterA-bfd] quit
[RouterA] ospf
[RouterA-ospf-1] bfd all-interfaces enable
# Enable global BFD on RouterB.
[RouterB] bfd
[RouterB-bfd] quit
[RouterB] ospf
[RouterB-ospf-1] bfd all-interfaces enable
# Enable global BFD on RouterC.
[RouterC] bfd
[RouterC-bfd] quit
[RouterC] ospf
[RouterC-ospf-1] bfd all-interfaces enable
# After the preceding configurations are complete, run the display ospf bfd session all
command on RouterA or RouterB. You can view that the status of the BFD session is
Up. Take the display of RouterA as an example:

[RouterA] display ospf bfd session all
Area 0.0.0.0 interface 1.1.1.1(GigabitEthernet1/0/0)'s BFD Sessions
NeighborId:3.3.3.3 AreaId:0.0.0.0 Interface:GigabitEthernet1/0/0
BFDState:up rx :1000 tx :1000
Multiplier:3 BFD Local Dis:8195 LocalIpAdd:1.1.1.1
RemoteIpAdd:1.1.1.2 Diagnostic Info:No diagnostic information
NeighborId:2.2.2.2 AreaId:0.0.0.0 Interface:GigabitEthernet2/0/0
4. Configure BFD of the interface.
# Configure BFD on GE 2/0/0 of RouterA, set the minimum interval for sending the packets
and the minimum interval for receiving the packets to 500 ms, and set the local detection time
multiple to 4.

[RouterA-GigabitEthernet2/0/0] ospf bfd enable
[RouterA-GigabitEthernet2/0/0] ospf bfd min-tx-interval 500 min-rx-interval
# Configure BFD on GE 2/0/0 of RouterB, set the minimum interval for sending the packets
and the minimum interval for receiving the packets to 500 ms, and set the local detection time
multiple to 4.

[RouterB-GigabitEthernet2/0/0] ospf bfd enable
[RouterB-GigabitEthernet2/0/0] ospf bfd min-tx-interval 500 min-rx-interval
# After the preceding configurations are complete, run the display ospf bfd session all
command on RouterA or RouterB. You can view that the status of the BFD session is Up.
Take the display of RouterB as an example:
[RouterB] display ospf bfd session all

NeighborId:1.1.1.1 AreaId:0.0.0.0 Interface: GigabitEthernet2/0/0

# Run the shutdown command on GE 2/0/0 of RouterB to simulate the active link failure.

# Display the routing table on RouterA. The standby link RouterA → RouterC → RouterB
takes effect after the active link fails. The next hop address of the route to 172.16.1.0/24
becomes
1.1.1.2.
<RouterA> display ospf routing

Routing Tables
Routing for Network
172.16.1.0/24 3 Transit 1.1.1.2 2.2.2.2 0.0.0.0
3.3.3.0/24 1 Transit 3.3.3.1 1.1.1.1 0.0.0.0
2.2.2.0/24 2 Transit 1.1.1.2 2.2.2.2 0.0.0.0
1.1.1.0/24 1 Transit 1.1.1.1 1.1.1.1 0.0.0.0
Total Nets: 4
Configuration Files
#
sysname RouterA
#
router id 1.1.1.1
#
bfd
#
ip address 1.1.1.1 255.255.255.0
#
ip address 3.3.3.1 255.255.255.0
ospf bfd enable
ospf bfd min-tx-interval 500 min-rx-interval 500 detect-multiplier 4
#
ospf 1
bfd all-interface enable
area 0.0.0.0
network 3.3.3.0 0.0.0.255
network 1.1.1.0 0.0.0.255
#
return
#
sysname RouterB
#
router id 2.2.2.2
#
bfd
#
ip address 2.2.2.2 255.255.255.0
#
ip address 3.3.3.2 255.255.255.0
ospf bfd enable
ospf bfd min-tx-interval 500 min-rx-interval 500 detect-multiplier 4
#
ip address 172.16.1.1 255.255.255.0
#
ospf 1
area 0.0.0.0
network 3.3.3.0 0.0.0.255
network 2.2.2.0 0.0.0.255
network 172.16.1.0 0.0.0.255
#
return
#
sysname RouterC
#
router id 3.3.3.3
#
bfd
#
ip address 1.1.1.2 255.255.255.0
#
ip address 2.2.2.1 255.255.255.0
#
ospf 1
area 0.0.0.0
network 1.1.1.0 0.0.0.255
network 2.2.2.0 0.0.0.255
#
return
3.16.8 Example for Configuring OSPF GTSM
As shown on the network shown in Figure 3-16-8, routers run OSPF and GTSM is enabled on
RouterA, RouterB and RouterC
Figure 3-16-8 Networking diagram of OSPF GTSM

1. Configure OSPF.
2. Enable GTSM on each router and specify a valid TTL range for packets.
Procedure
3. Configure OSPF GTSM.
# On RouterA, set the maximum valid TTL range for packets from RouterA to other routers is
255 to 255.
[RouterA] ospf valid-ttl-hops 1
# On RouterB, set the maximum valid TTL range for packets from RouterB to other routers is
254 to 255.
[RouterB] ospf valid-ttl-hops 2
# On RouterC, set the maximum valid TTL range for packets from RouterC to other routers is
254 to 255.
[RouterC] ospf valid-ttl-hops 2
# Check whether OSPF neighbor relationships between routers are successfully established.
Take the display on RouterC as an example. The neighbor relationship is Full, indicating
that
the neighbor relationship is successfully established.
[RouterC] display ospf peer

Neighbors
DR: 192.168.2.2 BDR: 192.168.2.1 MTU: 0
# On RouterC, run the display gtsm statistics all command. You can view GTSM statistics on
RouterC. The default behavior is pass, no illegal packets exist, and the number of
discarded packets is 0.
<RouterC> display gtsm statistics all

GTSM Statistics Table
----------------------------------------------------------------
SlotId Protocol Total Counters Drop Counters Pass Counters
----------------------------------------------------------------
0 BGP 0 0 0
0 BGPv6 0 0 0
0 OSPF 0 0 0
0 LDP 0 0 0
1 BGP 0 0 0
1 BGPv6 0 0 0
1 OSPF 0 0 0
1 LDP 0 0 0
2 BGP 0 0 0
2 BGPv6 0 0 0
2 OSPF 0 0 0
2 LDP 0 0 0
3 BGP 0 0 0
3 BGPv6 0 0 0
3 OSPF 0 0 0
3 LDP 0 0 0
----------------------------------------------------------------
Configuration files
#
sysname RouterA
#
router id 1.1.1.1
#
ip address 192.168.1.1 255.255.255.0
#
ip address 192.168.2.1 255.255.255.0

1210
#
ip address 10.1.1.1 255.0.0.0
#
ospf 1
area 0.0.0.0
network 10.0.0.0 0.255.255.255
area 0.0.0.1
network 192.168.1.0 0.0.0.255
network 192.168.2.0 0.0.0.255
#
ospf valid-ttl-hops 1
#
return
#
sysname RouterB
#
router id 2.2.2.2
#
ip address 192.168.1.2 255.255.255.0
#
ospf 1
area 0.0.0.1
network 192.168.1.0 0.0.0.255
#
#
return
#
sysname RouterC
#
router id 3.3.3.3
#
ip address 192.168.2.2 255.255.255.0
#
ospf 1
area 0.0.0.1
network 192.168.2.0 0.0.0.255
#
#
return
#
sysname RouterD
#
router id 4.4.4.4
#
ip address 10.1.1.2 255.0.0.0
#
ospf 1
area 0.0.0.0
network 10.0.0.0 0.255.255.255
#
return
Chapter 4 BGP
4.1 BGP Concepts
This section describes BGP concepts to help you better understand BGP functions.
4.1.1 Autonomous System
An Autonomous System (AS) is a group of Internet Protocol (IP) networks that are controlled by
one entity, typically an Internet Service Provider (ISP), and that have the same routing policy. Each
AS is assigned a unique AS number, which identifies an AS on a BGP network. Two types of AS
numbers are available: 2-byte AS numbers and 4-byte AS numbers. A 2-byte AS number ranges
from 1 to
65535, and a 4-byte AS number ranges from 1 to 4294967295. Devices supporting 4-byte AS
numbers are compatible with devices supporting 2-byte AS numbers.
4.1.2 BGP Classification
As shown in Figure 4-1-1, BGP is classified into two types according to where it runs: Internal BGP
(IBGP) and External BGP (EBGP). When BGP runs between two peers in the same AS, BGP is
called IBGP. When BGP runs between ASs, BGP is called EBGP.
Figure 4-1-1 BGP operating mode
 EBGP: runs between ASs. To prevent routing loops between ASs, a BGP device discards
the routes with the local AS number when receiving the routes from EBGP peers.
 IBGP: runs within an AS. To prevent routing loops within an AS, a BGP device does not
advertise the routes learned from an IBGP peer to the other IBGP peers and establishes full-
mesh connections with all the IBGP peers. To address the problem of too many IBGP
connections between IBGP peers, BGP uses Route Reflector and BGP Confederation.
NOTE:
If a BGP device needs to advertise the route received from an EBGP peer outside an AS
through another BGP device, IBGP is recommended.
4.1.3 Device Roles in BGP Message Exchange
There are two device roles in BGP message exchange:
 Speaker: The device that sends BGP messages is called a BGP speaker. The speaker receives
and generates new routes, and advertises the routes to other BGP speakers.
 Peer: The speakers that exchange messages with each other are called BGP peers. A group
of peers sharing the same policies can form a peer group.
4.1.4 BGP Router ID
The BGP router ID is a 32-bit value that is often represented by an IPv4 address to identify a BGP
device. It is carried in the Open message sent during the establishment of a BGP session. When two
BGP peers need to establish a BGP session, they each require a unique router ID. Otherwise, the
two peers cannot establish a BGP session.
The BGP router ID of a device must be unique on a BGP network. It can be manually configured or
selected from IPv4 addresses on the device. By default, an IPv4 address of a loopback interface on a
device is used as the BGP router ID. If no loopback interface is configured on the device, the system
selects the largest IPv4 address from all IPv4 addresses of interfaces as the BGP router ID. Once the
BGP router ID is selected, the system retains this router ID even if a larger IPv4 address is
configured on the device later. The system changes the BGP router ID only when the corresponding
IPv4 address is deleted.
4.2 BGP Working Principles
BGP peer establishment, update, and deletion involve five types of messages, six state machine,
and five route exchange rules.
4.2.1 BGP Messages
BGP peers exchange the following messages, among which Keepalive messages are periodically
sent and other messages are triggered by events.
 Open message: is used to establish BGP peer relationships.
 Update message: is used to exchange routes between BGP peers.
 Notification message: is used to terminate BGP connections.
 Keepalive message: is used to maintain BGP connections.
 Route-refresh message: is used to request the peer to resend routes if routing policies are changed.
Only the BGP devices supporting route-refresh can send and respond to Route-refresh messages.
4.2.2 BGP State Machine
As shown in Figure 4-2-1, a BGP device uses a finite state machine (FSM) to determine its
operations with peers. The FSM has six states: Idle, Connect, Active, OpenSent, OpenConfirm, and
Established.
Three common states are involved in BGP peer establishment: Idle, Active, and
Established.
Figure 4-2-1 BGP state machine
1. The Idle state is the initial BGP state. In Idle state, the BGP device refuses all connection
requests from neighbors. The BGP device initiates a TCP connection with its BGP peer
and
changes its state to Connect only after receiving a Start event from the system.
NOTE:
 The Start event occurs when an operator configures a BGP process or resets an existing
BGP process or when the router software resets a BGP process.
 If an error occurs at any state of the FSM, for example, the BGP device receives a
Notification packet or TCP connection termination notification, the BGP device returns
to the Idle state.
2. In Connect state, the BGP device starts the ConnectRetry timer and waits to establish a TCP
connection.
 If the TCP connection is established, the BGP device sends an Open message to the
peer and changes to the OpenSent state.
 If the TCP connection fails to be established, the BGP device moves to the Active state.
 If the BGP device does not receive a response from the peer before the ConnectRetry
timer expires, the BGP device attempts to establish a TCP connection with another
peer and stays in Connect state.
3. In Active state, the BGP device keeps trying to establish a TCP connection with the peer.
 If the TCP connection is established, the BGP device sends an Open message to the
peer, closes the ConnectRetry timer, and changes to the OpenSent state.
 If the TCP connection fails to be established, the BGP device stays in the Active state.
 If the BGP device does not receive a response from the peer before the
ConnectRetry timer expires, the BGP device returns to the Connect state.
4. In OpenSent state, the BGP device waits an Open message from the peer and then checks
the validity of the received Open message, including the AS number, version, and
authentication password.
 If the received Open message is valid, the BGP device sends a Keepalive message
and changes to the OpenConfirm state.
 If the received Open message is invalid, the BGP device sends a Notification message
to the peer and returns to the Idle state.
5. In OpenConfirm state, the BGP device waits for a Keepalive or Notification message from the
peer. If the BGP device receives a Keepalive message, it transitions to the Established state. If
it receives a Notification message, it returns to the Idle state.
6. In Established state, the BGP device exchanges Update, Keepalive, Route-refresh, and
Notification messages with the peer.
 If the BGP device receives a valid Update or Keepalive message, it considers that the
peer is working properly and maintains the BGP connection with the peer.
 If the BGP device receives a valid Update or Keepalive message, it sends a

Notification message to the peer and returns to the Idle state.
 If the BGP device receives a Route-refresh message, it does not change its status.
 If the BGP device receives a Notification message, it returns to the Idle state.
 If the BGP device receives a TCP connection termination notification, it terminates the
TCP connection with the peer and returns to the Idle state.
4.2.3 Route Exchange Rules
A BGP device adds optimal routes to the BGP routing table to generate BGP routes. After
establishing a BGP peer relationship with a neighbor, the BGP device follows the following rules to
exchange routes with the peer:
 Advertises the BGP routes received from IBGP peers only to its EBGP peers.
 Advertises the BGP routes received from EBGP peers to its EBGP peers and IBGP peers.
 Advertises the optimal route to its peers when there are multiple valid routes to the
same destination.
 Sends only updated BGP routes when BGP routes change.
 Accepts all the routes sent from its peers.
4.3 Interaction between BGP and an IGP
BGP and IGPs use different routing tables. To enable different ASs to communicate, you need to
configure interaction between BGP and IGPs so that BGP routes can be imported into IGP
routing tables and IGP routes can also be imported to BGP routing tables.
4.3.1 Importing IGP Routes to BGP Routing Tables
BGP does not discover routes and so needs to import the routes discovered by IGPs to BGP routing
tables so that different ASs can communicate. When an AS needs to advertise routes to another AS,
an Autonomous System Boundary Router (ASBR) imports IGP routes to its BGP routing table. To
better plan the network, you can use routing policies to filter routes and set route attributes when
BGP imports IGP routes. Alternatively, you can set the multi-exit discriminator (MED) to help EBGP
peers select the best path for traffic entering an AS.
BGP imports routes in either import or network mode:
 In import mode, BGP imports IGP routes, including RIP, OSPF, and IS-IS routes, into BGP
routing tables based on protocol type. To ensure the validity of imported IGP routes, BGP
can also import static routes and direct routes in import mode.
 In network mode, BGP imports the routes in the IP routing table one by one to BGP
routing tables. The network mode is more accurate than the import mode.
4.3.2 Importing BGP Routes to IGP Routing Tables
When an AS needs to import routes from another AS, an ASBR imports BGP routes to its IGP
routing table. To prevent a large number of BGP routes from affecting devices within the AS, IGPs
can use routing policies to filter routes and set route attributes when importing BGP routes.
4.3.3 Applications
As shown in Figure 4-3-1, an OSPF network is deployed in AS 100 where the Overseas Market
Department of a company resides, and an IS-IS network is deployed in AS 200 where the Domestic
R&D Department of the company resides. AS 100 and AS 200 communicate using BGP. The
company requires that the Overseas Market Department can send files to the Domestic R&D
Department but the Domestic R&D Department cannot send files to the Overseas Market Department.
Figure 4-3-1 IGPs importing BGP routes
According to the preceding requirement of the company, devices in AS 100 must know routes of AS
200, but devices in AS 200 do not know routes of AS 100. To meet this requirement, configure BGP
to import IS-IS routes on RouterC. Then RouterC has routes of AS 200 in the BGP routing table and
advertises these routes to RouterB. In addition, configure OSPF to import BGP routes on RouterB.
Devices in AS 100 can know routes of AS 200, but devices in AS 200 do not know routes of AS 100.
4.4 BGP Security
BGP uses authentication and Generalized TTL Security Mechanism (GTSM) to ensure
exchange security between BGP peers.
4.4.1 BGP Authentication
BGP authentication includes Message Digest 5 (MD5) authentication and keychain authentication,
which improves communication security between BGP peers. In MD5 authentication, you can only
set the authentication password for a TCP connection. In keychain authentication, you can set the
authentication password for a TCP connection and authenticate BGP messages.
4.4.2 BGP GTSM
BGP GTSM checks whether the time-to-live (TTL) value in the IP packet header is within a
predefined range and permits or discards the packets of which the TTL values are out of the
predefined range to protect services above the IP layer. BGP GTSM enhances system security.
Assume that the TTL value range of packets from BGP peers is set to 254-255. When an attacker
forges valid BGP packets and keeps sending these packets to attack a device, the TTL values of these
packets are smaller than 254. If BGP GTSM is not enabled on the device, the device finds that these
packets are destined for itself and sends the packets to the control plane for processing. Then the
control layer needs to process a large number of such attack packets, causing high CPU usage. If BGP
GTSM is enabled on the device, the system checks the TTL values in all BGP packets and discards
the attack packets of which the TTL values are smaller than 254. This prevents network attack
packets from consuming CPU resources.
4.5 BGP Route Selection Rules and Load Balancing
There may be multiple routes to the same destination in a BGP routing table. BGP will select one
route as the optimal route and advertise it to peers. To select the optimal route among these routes,
BGP compares the BGP attributes of the routes in sequence based on route selection rules.
4.5.1 BGP Attributes
Route attributes describe routes. BGP route attributes are classified into the following types. Table
4-5-1 lists common BGP attributes.
 Well-known mandatory attribute
All BGP devices can identify this type of attributes, which must be carried in Update
messages. Without this type of attributes, errors occur in routing information.
 Well-known discretionary attribute
All BGP devices can identify this type of attributes, which are optional in Update
messages. Without this type of attributes, errors do not occur in routing information.
 Optional transitive attribute
BGP devices may not identify this type of attributes but still accepts them and advertises them
to peers.
 Optional non-transitive attribute
BGP devices may not identify this type of attributes. If a BGP device does not identify this
type of attributes, it ignores them and does not advertise them to peers.
Table 4-5-1 Common BGP attributes
Origin
AS_Path
Next_Hop
Local_Pref
Community
MED
Table 4-5-1 Common BGP attributes
Originator_ID
Cluster_List
The following describes common BGP route attributes:
 Origin
The Origin attribute defines the origin of a route and marks the path of a BGP route. The
Origin attribute is classified into three types:
 IGP
A route with IGP as the Origin attribute is of the highest priority. The Origin attribute
of the routes imported into a BGP routing table using the network command is IGP.
 EGP
A route with EGP as the Origin attribute is of the secondary highest priority. The
Origin attribute of the routes obtained through EGP is EGP.
 Incomplete
A route with Incomplete as the Origin attribute is of the lowest priority. The Origin
attribute of the routes learned by other means is Incomplete. For example, the Origin
attribute of the routes imported by BGP using the import-route command is
Incomplete.
 AS_Path
The AS_Path attribute records all the ASs that a route passes through from the source to the
destination in the vector order. To prevent inter-AS routing loops, a BGP device does not
receive the routes of which the AS_Path list contains the local AS number.
When a BGP speaker advertises an imported route:
 If the route is advertised to EBGP peers, the BGP speaker creates an AS_Path
list containing the local AS number in an Update message.
 If the route is advertised to IBGP peers, the BGP speaker creates an empty AS_Path list
in an Update message.
When a BGP speaker advertises a route learned in the Update message sent by another BGP
speaker:
 If the route is advertised to EBGP peers, the BGP speaker adds the local AS number to
the leftmost of the AS_Path list. According to the AS_Path list, the BGP speaker that
receives the route can learn about the ASs through which the route passes to reach the
1210
destination. The number of the AS that is nearest to the local AS is placed on the top of
the AS_Path

1210
list. The other AS numbers are listed according to the sequence in which the route
passes through ASs.
 If the route is advertised to IBGP peers, the BGP speaker does not change the
AS_Path attribute of the route.
 Next_Hop
The Next_Hop attribute records the next hop that a route passes through. The Next_Hop
attribute of BGP is different from that of an IGP because it may not be the neighbor IP address.
A BGP speaker processes the Next_Hop attribute based on the following rules:
 When advertising a route to an EBGP peer, a BGP speaker sets the Next_Hop attribute
of the route to the address of the local interface through which the BGP peer relationship
is established with the peer.
 When advertising a locally originated route to an IBGP peer, the BGP speaker sets the
Next_Hop attribute of the route to the address of the local interface through which the
BGP peer relationship is established with the peer.
 When advertising a route learned from an EBGP peer to an IBGP peer, the BGP
speaker does not change the Next_Hop attribute of the route.
 Local_Pref
The Local_Pref attribute indicates the BGP preference of a device and helps determine the
optimal route when traffic leaves an AS. When a BGP device obtains multiple routes to the
same destination address but with different next hops from different IBGP peers, the BGP
device prefers the route with the highest Local_Pref. The Local_Pref attribute is exchanged
only
between IBGP peers and is not advertised to other ASs. The Local_Pref attribute can be
manually configured. If no Local_Pref attribute is configured for a route, the Local_Pref attribute
of the route uses the default value 100.
 MED
The multi-exit discriminator (MED) attribute helps determine the optimal route when traffic
enters an AS. When a BGP device obtains multiple routes to the same destination address
but with different next hops from EBGP peers, the BGP device selects the route with the
smallest MED value as the optimal route.
The MED attribute is exchanged only between two neighboring ASs. The AS that receives the
MED attribute does not advertise it to any other ASs. The MED attribute can be manually
configured. If no MED attribute is configured for a route, the MED attribute of the route uses
the default value 0.
 Community
The Community attribute identifies the BGP routes with the same characteristics, simplifies
the applications of routing policies, and facilitates route maintenance and management.
The Community attribute includes self-defined community attributes and well-known

community attributes. Table 4-5-2 lists well-known community attributes.
Table 4-5-2 Well-known community attributes
Community Attribute
Internet
No_Advertise
No_Export
No_Export_Subconfed
 Originator_ID and Cluster_List
The Originator_ID attribute and Cluster_List attribute help eliminate loops in route
reflector scenarios. For details, see Route Reflector.
4.5.2 BGP Route Selection Policies
When there are multiple routes to the same destination, BGP compares the following attributes
in sequence to select the optimal route:
1. Prefers the route with the largest PrefVal value.
The PrefVal attribute is a Huawei proprietary attribute and is valid only on the device where it
is configured.
2. Prefers the route with the highest Local_Pref.
If a route does not have the Local_Pref attribute, the Local_Pref attribute of the route uses
the default value 100.
3. Prefers the manually summarized route, automatically summarized route, route imported
using the network command, route imported using the import-route command, and route
learned from peers. These routes are in descending order of priority.
4. Prefers the route with the shortest AS_Path.
5. Prefers the route with the lowest origin type. IGP is lower than EGP, and EGP is lower than
Incomplete.
6. Prefers the route with the lowest MED if routes are received from the same AS.
7. Prefers EBGP routes, IBGP routes, LocalCross routes, and RemoteCross routes, which
are listed in descending order of priority.
LocalCross allows a PE to add the VPNv4 route of a VPN instance to the routing table of the
VPN instance if the export RT of the VPNv4 route matches the import RT of another VPN
instance on the PE. RemoteCross allows a local PE to add the VPNv4 route learned from a
remote PE to the routing table of a VPN instance on this local PE if the export RT of the
VPNv4 route matches the import RT of the VPN instance.
8. Prefers the route with the lowest IGP metric to the BGP next hop.
NOTE:
If there are multiple routes to the same destination, an IGP calculates the route metric using
its routing algorithm.
9. Prefers the route with the shortest Cluster_List.
10. Prefers the route advertised by the device with the smallest router ID.
NOTE:
If a route carries the Originator_ID attribute, BGP prefers the route with the smallest
Originator_ID without comparing the router ID.
11. Prefers the route learned from the peer with the lowest IP address.
4.5.3 BGP Load Balancing
When there are multiple equal-cost routes to the same destination, you can perform load balancing
among these routes to load balance traffic. Equal-cost BGP routes can be generated for traffic load
balancing only when the first eight route attributes described in "BGP Route Selection Policies" are
the same.
4.6 Examples for Configuring of BGP
4.6.1 Example for Configuring Basic BGP Functions
As shown in Figure 4-6-1, BGP runs between Routers; an EBGP connection is established
between RouterA and RouterB; IBGP full-mesh connections are established between RouterB,
RouterC, and RouterD.
Figure 4-6-1 Networking diagram of configuring basic BGP functions
1. Configure IBGP connections between RouterB, RouterC, and RouterD.
2. Configure an EBGP connection between RouterA and RouterB.
Procedure
<RouterA> system-view
2. Configure IBGP connections.
[RouterB] bgp 65009

[RouterC] bgp 65009

[RouterD] bgp 65009

[RouterD-bgp] router-id 4.4.4.4
[RouterD-bgp] peer 9.1.1.1 as-number 65009
3. Configure an EBGP connection.
[RouterA] bgp 65008

[RouterA-bgp] router-id 1.1.1.1
[RouterA-bgp] peer 200.1.1.1 as-number 65009
# View the status of BGP peers.
[RouterB] display bgp peer

BGP local router ID : 2.2.2.2
Local AS number : 65009
Total number of peers : 3
Peer V AS PrefRcv
9.1.1.2 4 65009
9.1.3.2 4 65009
200.1.1.2 4 65008
The preceding command output shows that BGP connections have been established between
RouterB and other Routers.
4. Configure RouterA to advertise route 8.0.0.0/8.
# Configure RouterA to advertise a route.
[RouterA-bgp] ipv4-family unicast

[RouterA-bgp-af-ipv4] network 8.0.0.0 255.0.0.0
# View the routing table of RouterA.
[RouterA] display bgp routing-table

BGP Local router ID is 1.1.1.1
Status codes: * - valid, > - best, d - damped,
h - history, i - internal, s - suppressed, S - Stale
Origin : i - IGP, e - EGP, ? - incomplete
Total Number of Routes: 1
Network NextHop MED LocPrf PrefVal
Path/Ogn
*> 8.0.0.0 0.0.0.0 0 0 i
# View the routing table of RouterB.
[RouterB] display bgp routing-table


Path/Ogn
*> 8.0.0.0 200.1.1.2 0 0 65008i
[RouterC] display bgp routing-table


Path/Ogn
i 8.0.0.0 200.1.1.2 0 100 0 65008i

NOTE:
The preceding command output shows that RouterC has learned the route to destination
8.0.0.0 in AS 65008. The route, however, is invalid because the next hop 200.1.1.2 of this
route is unreachable.
5. Configure BGP to import direct routes.


[RouterB-bgp-af-ipv4] import-route direct
# View the BGP routing table of RouterA.


Path/Ogn
*> 8.0.0.0
*> 9.1.1.0/24
*> 9.1.3.0/24
200.1.1.0
# View the BGP routing table of RouterC.
[RouterC] display bgp routing-table


Path/Ogn
*>i 8.0.0.0
*>i 9.1.1.0/24
i 9.1.3.0/24
*>i 200.1.1.0
The preceding command output shows that the route to destination 8.0.0.0 becomes
valid because the next-hop address of this route is the address of RouterA.
# Run the ping command on RouterC.
[RouterC] ping 8.1.1.1

0.00% packet loss
Configuration Files
#
sysname RouterA
#
ip address 8.1.1.1 255.0.0.0
#
ip address 200.1.1.2 255.255.255.0
#
bgp 65008
router-id 1.1.1.1
#
ipv4-family unicast
network 8.0.0.0
#
return
#
sysname RouterB
#
ip address 9.1.1.1 255.255.255.0
#
ip address 200.1.1.1 255.255.255.0
#
ip address 9.1.3.1 255.255.255.0
#
bgp 65009
router-id 2.2.2.2
#
ipv4-family unicast
import-route direct
peer 9.1.1.2 enable
peer 9.1.3.2 enable
#
return
#
sysname RouterC
#
ip address 9.1.2.1 255.255.255.0
#
ip address 9.1.3.2 255.255.255.0
#
bgp 65009
router-id 3.3.3.3
#
ipv4-family unicast
peer 9.1.2.2 enable
peer 9.1.3.1 enable
#
return
#
sysname RouterD
#
ip address 9.1.1.2 255.255.255.0
#
ip address 9.1.2.2 255.255.255.0
#
bgp 65009
router-id 4.4.4.4
#
ipv4-family unicast
peer 9.1.1.1 enable
peer 9.1.2.1 enable
#
return
4.6.2 Example for Configuring BGP to Interact with an IGP
The network shown in Figure 4-6-2 is divided into AS 65008 and AS 65009. In AS 65009, an IGP
is used to calculate routes. In this example, OSPF is used as an IGP. The two ASs need to
communicate with each other.

1210
Figure 4-6-2 Networking diagram for configuring BGP to interact with an IGP
1. Configure OSPF on Routers B and C so that these devices can access each other.
2. Establish an EBGP connection between Routers A and B so that these devices can
exchange routing information.
3. Configure BGP and OSPF to import routes from each other on RouterB so that the two ASs
can communicate with each other.
4. (Optional) Configure BGP route summarization on RouterB to simplify the BGP routing table.
Procedure
Configure an IP address to each interface as shown in Figure 4-6-2. For details about
the configuration, see the following configuration files.
2. Configuring OSPF
[RouterB] ospf 1
[RouterC] ospf 1
3. Establish an EBGP connection.
[RouterA] bgp 65008

[RouterA-bgp-af-ipv4] network 8.1.1.0 255.255.255.0
[RouterB] bgp 65009

4. Configure BGP to interact with an IGP
# On RouterB, configure BGP to import OSPF routes.

[RouterB-bgp-af-ipv4] import-route ospf 1
[RouterB-bgp-af-ipv4] quit
[RouterB-bgp] quit

Path/Ogn
*> 8.1.1.0/24
*> 9.1.1.0/24
*> 9.1.2.0/24
# On RouterB, configure OSPF to import BGP routes.
[RouterB] ospf
[RouterB-ospf-1] import-route bgp

------------------------------------------------------------------------------
8.1.1.0/24 O_ASE 150 1 D 9.1.1.1

9.1.1.0/24 Direct 0 0 D 9.1.1.2
9.1.1.2/32 Direct 0 0 D 127.0.0.1
9.1.2.0/24 Direct 0 0 D 9.1.2.1
9.1.2.1/32 Direct 0 0 D 127.0.0.1
127.0.0.0/8
127.0.0.1/32
5. (Optional) Configure automatic route summarization.
BGP is used to transmit routing information on large-scale networks. BGP route

summarization can be configured to simplify routing tables of devices on these networks.
[RouterB] bgp 65009

[RouterB-bgp-af-ipv4] summary automatic
# View the BGP routing table of RouterA.

Path/Ogn
*> 8.1.1.0/24
*> 9.0.0.0
# Run the ping -a 8.1.1.1 9.1.2.1 command on RouterA.
[RouterA] ping -a 8.1.1.1 9.1.2.1

Reply from 9.1.2.1: bytes=56 Sequence=1 ttl=254 time=15
ms Reply from 9.1.2.1: bytes=56 Sequence=2 ttl=254
time=31 ms Reply from 9.1.2.1: bytes=56 Sequence=3
ttl=254 time=47 ms Reply from 9.1.2.1: bytes=56 Sequence=4
ttl=254 time=47 ms
0.00% packet loss
Configuration Files
#
sysname RouterA
#
ip address 8.1.1.1 255.255.255.0
#
ip address 3.1.1.2 255.255.255.0
#
bgp 65008
router-id 1.1.1.1
#
ipv4-family unicast
network 8.1.1.0 255.255.255.0
peer 3.1.1.1 enable
#
return
#
sysname RouterB
#
ip address 9.1.1.1 255.255.255.0
#
ip address 3.1.1.1 255.255.255.0
#
bgp 65009
router-id 2.2.2.2
#
ipv4-family unicast
summary automatic
import-route ospf 1
peer 3.1.1.2 enable
#
ospf 1
import-route bgp
area 0.0.0.0
network 9.1.1.0 0.0.0.255
#
return
#
sysname RouterC
#
ip address 9.1.1.2 255.255.255.0
#
ip address 9.1.2.1 255.255.255.0
#
ospf 1
area 0.0.0.0
network 9.1.1.0 0.0.0.255
network 9.1.2.0 0.0.0.255
#
return
4.6.3 Example for Configuring AS_Path Filters
On the network shown in Figure 4-6-3, RouterB establish EBGP connections with Routers A and
C. The user wants to disable the devices in AS 10 from communicating with devices in AS 30.
Figure 4-6-3 Networking diagram for configuring AS_Path filters
1. Establish EBGP connections between Routers A and B and between Routers B and C and
configure these devices to import direct routes so that the ASs can communicate with each
other through these EBGP connections.
2. Configure AS_Path filters on RouterB and use filtering rules to prevent AS 20 from
advertising routes of AS 30 to AS 10 or routes of AS 10 to AS 30.
Procedure
1. Configure an IP address for each interface. The configuration details are not provided here.
2. Establish EBGP connections.
[RouterA] bgp 10
[RouterA-bgp] import-route direct
[RouterB] bgp 20
[RouterB-bgp] import-route direct
[RouterB-bgp] quit
[RouterC] bgp 30
[RouterC-bgp] import-route direct
[RouterC-bgp] quit
# View routes advertised by RouterB. Routes advertised by RouterB to RouterC are used as
an example. You can see that RouterB advertises the direct route imported by AS 10.
<RouterB> display bgp routing-table peer 200.1.3.2 advertised-routes


Path/Ogn
*> 9.1.1.0/24
*> 10.1.1.0/24
*> 200.1.2.0
*> 200.1.2.1/32
*> 200.1.3.0/24
View the routing table of RouterC. You can see that RouterC has learned the direct route from
RouterB.
<RouterC> display bgp routing-table


Path/Ogn
*> 9.1.1.0/24
*> 10.1.1.0/24
*> 10.1.1.1/32
*> 127.0.0.0
*> 127.0.0.1/32
*> 200.1.2.0
*> 200.1.3.0/24
*
*> 200.1.3.2/32
3. Configure AS_Path filters on RouterB and apply the AS_Path filters to routes to be
advertised by RouterB.
# Create AS_Path filter 1 to deny the routes carrying AS number 30. The regular expression
"_30_" indicates any AS list that contains AS 30 and "*" matches any character.
[RouterB] ip as-path-filter path-filter1 deny _30_

[RouterB] ip as-path-filter path-filter1 permit .*
# Create AS_Path filter 2 to deny the routes carrying AS 10.
[RouterB] ip as-path-filter path-filter2 deny _10_

[RouterB] ip as-path-filter path-filter2 permit .*
# Apply the AS_Path filters to routes to be advertised by RouterB.
[RouterB] bgp 20
[RouterB-bgp] peer 200.1.2.1 as-path-filter path-filter1 export
[RouterB-bgp] peer 200.1.3.2 as-path-filter path-filter2 export
[RouterB-bgp] quit
4. # View routes advertised by RouterB.
# View routes advertised by RouterB to AS 30. You can see that RouterB does not advertise
the direct route imported by AS 10.


Path/Ogn
*> 200.1.2.0
*> 200.1.3.0/24
The route does not exist in the BGP routing table of RouterC.
<RouterC> display bgp routing-table


Path/Ogn
*> 10.1.1.0/24
*> 10.1.1.1/32
*> 127.0.0.0
*> 127.0.0.1/32
*> 200.1.2.0
*> 200.1.3.0/24
*
*> 200.1.3.2/32
# View routes advertised by RouterB to AS 10. You can see that RouterB does not advertise
the direct route imported by AS 30.

Network NextHop MED LocPr f PrefVal
Path/Ogn
*> 200.1.2.0
*> 200.1.3.0/24
The route does not exist in the BGP routing table of RouterA.
<RouterA> display bgp routing-table


Path/Ogn
*> 9.1.1.0/24
*> 9.1.1.1/32
*> 127.0.0.0
*> 127.0.0.1/32
*> 200.1.2.0
*
*> 200.1.2.1/32
*> 200.1.3.0/24
Configuration Files
#
sysname RouterA

1210
#
ip address 9.1.1.1 255.255.255.0
#
ip address 200.1.2.1 255.255.255.0
#
bgp 10
router-id 1.1.1.1
#
ipv4-family unicast
import-route direct
#
return
#
sysname RouterB
#
ip address 200.1.3.1 255.255.255.0
#
ip address 200.1.2.2 255.255.255.0
#
bgp 20
router-id 2.2.2.2
#
ipv4-family unicast
import-route direct
peer 200.1.2.1 as-path-filter path-filter1
export peer 200.1.3.2 enable
peer 200.1.3.2 as-path-filter path-filter2 export
#
ip as-path-filter path-filter1 deny _30_
ip as-path-filter path-filter1 permit .*
ip as-path-filter path-filter2 deny _10_
ip as-path-filter path-filter2 permit .*
#
return
#
sysname RouterC
#
ip address 10.1.1.1 255.255.255.0
#
ip address 200.1.3.2 255.255.255.0
#
bgp 30
router-id 3.3.3.3
#
ipv4-family unicast
import-route direct
#
return
4.6.4 Example for Configuring MED Attributes to Control BGP Route Selection
As shown in Figure 4-6-4, BGP is configured on all routeres; RouterA resides in AS 65008; RouterB
and RouterC reside in AS 65009. EBGP connections are established between RouterA and RouterB,
and between RouterA and RouterC. An IBGP connection is established between RouterB and
RouterC. After a period, traffic from AS 65008 to AS 65009 needs to first pass through RouterC.
Figure 4-6-4 Networking diagram for configuring MED attributes of routes to control route selection
1. Establish EBGP connections between RouterA and RouterB and between RouterA and
RouterC, and establish an IBGP connection between RouterB and RouterC.
2. Apply a routing policy to increase the MED value of the route sent by RouterB to RouterA
so that RouterA will send traffic to AS 65009 through RouterC.
Procedure
2. Establish BGP connections.
[RouterA] bgp 65008

[RouterA-bgp] quit
[RouterB] bgp 65009

[RouterB-bgp-af-ipv4] network 9.1.1.0 255.255.255.0
[RouterB-bgp-af-ipv4] quit
[RouterB-bgp] quit
[RouterC] bgp 65009

[RouterC-bgp-af-ipv4] network 9.1.1.0 255.255.255.0
[RouterC-bgp-af-ipv4] quit
[RouterC-bgp] quit
[RouterA] display bgp routing-table 9.1.1.0 24

Paths: 2 available, 1 best, 1 select
BGP routing table entry information of
9.1.1.0/24: From: 200.1.1.1 (2.2.2.2)
Route Duration: 00h00m56s
Direct Out-interface: GigabitEthernet1/0/0
Original nexthop: 200.1.1.1
Qos information : 0x0
AS-path 65009, origin igp, MED 0, pref-val 0, valid, external, best, select, pre 255
Advertised to such 2 peers:
200.1.1.1
200.1.2.1

9.1.1.0/24: From: 200.1.2.1 (3.3.3.3)
AS-path 65009, origin igp, MED 0, pref-val 0, valid, external, pre 255, not preferred
for router ID
Not advertised to any peer yet
The preceding command output shows that there are two valid routes to destination
9.1.1.0/24. The route with the next-hop address of 200.1.1.1 is the optimal route because the
router ID of Router is smaller.
3. Set MED attributes for routes.
# Apply a routing policy to set an MED value for the route advertised by RouterB to
RouterA (the default MED value of a route is 0).
[RouterB] route-policy policy10 permit node 10

[RouterB] bgp 65009
[RouterB-bgp] peer 200.1.1.2 route-policy policy10 export

9.1.1.0/24: From: 200.1.2.1 (3.3.3.3)
AS-path 65009, origin igp, MED 0, pref-val 0, valid, external, best, select, pre 255
200.1.1.1
200.1.2.1

9.1.1.0/24: From: 200.1.1.1 (2.2.2.2)
AS-path 65009, origin igp, MED 100, pref-val 0, valid, external, pre 255, not preferred for
MED
The preceding command output shows that the MED value of the route with the next-hop
address of 200.1.2.1 (RouterB) is 100 and the MED value of the route with the next-hop
address of 200.1.1.1 is 0. The route with the smaller MED value is selected.
Configuration Files
#
sysname RouterA
#
ip address 200.1.1.2 255.255.255.0
#
ip address 200.1.2.2 255.255.255.0
#
bgp 65008
router-id 1.1.1.1
#
ipv4-family unicast
#
return
#
sysname RouterB
#
ip address 9.1.1.1 255.255.255.0
#
ip address 200.1.1.1 255.255.255.0
#
bgp 65009
router-id 2.2.2.2
#
ipv4-family unicast
network 9.1.1.0 255.255.255.0
peer 9.1.1.2 enable
peer 200.1.1.2 route-policy policy10 export
#
route-policy policy10 permit node 10
apply cost 100
#
return
#
sysname RouterC
#
ip address 9.1.1.2 255.255.255.0
#
ip address 200.1.2.1 255.255.255.0
#
bgp 65009
router-id 3.3.3.3
#
ipv4-family unicast
network 9.1.1.0 255.255.255.0
peer 9.1.1.1 enable
#
return
4.6.5 Example for Configuring BGP Load Balancing
On the network shown in Figure 4-6-5, BGP is configured on all routers. RouterA is in AS 100.
RouterB and RouterC are in AS 300. RouterD is in AS 200. Network congestion from RouterA to
destination address 8.1.1.0/24 needs to be relieved and network resources need to be fully
utilized.
Figure 4-6-5 Networking diagram of configuring BGP load balancing
1. Establish EBGP connections between RouterA and RouterB and between RouterA and
RouterC, between RouterD and RouterB and between RouterD and RouterC to enable ASs to
communicate with each other using BGP.
2. Configuring load balancing on RouterA so that RouterA can send traffic to RouterD
through either RouterB or RouterC.
Procedure
2. Establish BGP connections.
[RouterA] bgp 100

[RouterA-bgp] quit
[RouterB] bgp 300

[RouterB-bgp] quit
[RouterC] bgp 300

[RouterC-bgp] quit
[RouterD] bgp 200

[RouterD-bgp] ipv4-family unicast
[RouterD-bgp-af-ipv4] network 8.1.1.0 255.255.255.0
[RouterD-bgp-af-ipv4] quit
[RouterD-bgp] quit

Paths : 2 available, 1 best, 1 select
8.1.1.0/24: From: 200.1.1.2 (2.2.2.2)
AS-path 300 200, origin igp, pref-val 0, valid, external, best, select, active, pre 255
200.1.1.2
200.1.2.2

8.1.1.0/24: From: 200.1.2.2 (3.3.3.3)
AS-path 300 200, origin igp, pref-val 0, valid, external, pre 255, not preferred for router
ID Not advertised to any peer yet
The preceding command output shows that there are two valid routes from RouterA to
destination 8.1.1.0/24. The route with the next-hop address of 200.1.1.2 is the optimal
route because the router ID of RouterB is smaller.
3. Configure BGP load balancing.
# Configure load balancing on RouterA.
[RouterA] bgp 100

[RouterA-bgp-af-ipv4] maximum load-balancing 2
[RouterA-bgp-af-ipv4] quit
[RouterA-bgp] quit

1210
Paths : 2 available, 1 best, 2 select
8.1.1.0/24: From: 200.1.1.2 (2.2.2.2)
AS-path 300 200, origin igp, pref-val 0, valid, external, best, select, active, pre 255
Advertised to such 2 peers
200.1.1.2
200.1.2.2

8.1.1.0/24: From: 200.1.2.2 (3.3.3.3)
AS-path 300 200, origin igp, pref-val 0, valid, external, select, active, pre 255,
not preferred for router ID
The preceding command output shows that BGP route 8.1.1.0/24 has two next hops:
200.1.1.2 and 200.1.2.2. Both of them are optimal routes.
Configuration Files
#
sysname RouterA
#
ip address 200.1.1.1 255.255.255.0
#
ip address 200.1.2.1 255.255.255.0
#
interface LoopBack0
ip address 1.1.1.1 255.255.255.255
#
bgp 100
router-id 1.1.1.1
#
ipv4-family unicast undo
synchronization maximum
load-balancing 2 peer
200.1.1.2 enable
#
return
#
sysname RouterB
#
ip address 200.1.1.2 255.255.255.0
#
ip address 200.1.3.2 255.255.255.0
#
interface LoopBack0
ip address 2.2.2.2 255.255.255.255
#
bgp 300
router-id 2.2.2.2
#
ipv4-family unicast
#
return

#
sysname RouterC
#
ip address 200.1.4.2 255.255.255.0
#
ip address 200.1.2.2 255.255.255.0
#
interface LoopBack0
ip address 3.3.3.3 255.255.255.255
#
bgp 300
router-id 3.3.3.3
#
ipv4-family unicast
#
return
#
sysname RouterD
#
ip address 200.1.4.1 255.255.255.0
#
ip address 200.1.3.1 255.255.255.0
#
ip address 8.1.1.1 255.255.255.0
#
interface LoopBack0
ip address 4.4.4.4 255.255.255.255
#
bgp 200
router-id 4.4.4.4
#
ipv4-family unicast
network 8.1.1.0 255.255.255.0
#
return
Chapter 5 BGP Extension Technique
5.1 Route Reflector
To ensure connectivity between IBGP peers, you need to establish full-mesh connections between
IBGP peers. If there are n devices in an AS, n(n-1)/2 IBGP connections need to be established.
When there are a large number of devices, many network resources and CPU resources are
consumed. A Route Reflector (RR) can be used between IBGP peers to solve this problem.
5.1.1 Roles in RR
As shown in Figure 5-1-1, the following roles are involved in RR scenarios in an AS.
Figure 5-1-1 Networking diagram of the RR

 Route reflector (RR): a BGP device that can reflect the routes learned from an IBGP peer to other
IBGP peers. An RR is similar to a Designated Router (DR) on an OSPF network.
 Client: an IBGP device of which routes are reflected by the RR to other IBGP devices. In an
AS, clients only need to directly connect to the RR.
 Non-client: an IBGP device that is neither an RR nor a client. In an AS, a non-client

must establish full-mesh connections with the RR and all the other non-clients.
 Originator: is a device that originates routes in an AS. The Originator_ID attribute

helps eliminate routing loops in a cluster.
 Cluster: is a set of the RR and clients. The Cluster_List attribute helps eliminate routing
loops between clusters.
5.1.2 RR Principles
Clients in a cluster only need to exchange routing information with the RR in the same cluster.
Therefore, clients only need to establish IBGP connections with the RR. This reduces the number of
IBGP connections in the cluster. As shown in Figure 5-1-1, in AS 65000, Cluster1 is comprised of
an RR and three clients. The number of IBGP connections in AS 65000 is then reduced from 10 to 4,
which simplifies the device configuration and reduces the loads on the network and CPU.
The RR allows a BGP device to advertise the BGP routes learned from an IBGP peer to other
IBGP peers, and uses the Cluster_List and Originator_ID attributes to eliminate routing loops. The
RR advertises routes to IBGP peers based on the following rules:
 The RR advertises the routes learned from a non-client to all the clients.
 The RR advertises the routes learned from a client to all the other clients and all the non-clients.
 The RR advertises the routes learned from an EBGP peer to all the clients and non-clients.
5.1.3 Cluster_List Attribute
An RR and its clients form a cluster, which is identified by a unique cluster ID in an AS. To prevent
routing loops between clusters, an RR uses the Cluster_List attribute to record the cluster IDs of all
the clusters that a route passes through.
 When a route is reflected by an RR for the first time, the RR adds the local cluster ID to the
top of the cluster list. If there is no cluster list, the RR creates a Cluster_List attribute.
 When receiving an updated route, the RR checks the cluster list of the route. If the cluster
list contains the local cluster ID, the RR discards the route. If the cluster list does not
contain the local cluster ID, the RR adds the local cluster ID to the cluster list and then
reflects the route.
5.1.4 Originator_ID Attribute

The originator ID identifies the originator of a route and is generated by an RR to prevent routing
loops in a cluster. Its value is the same as the router ID.
 When a route is reflected by an RR for the first time, the RR adds the Originator_ID attribute
to this route. The Originator_ID attribute identifies the originator of the route. If the route
contains the Originator_ID attribute, the RR retains this Originator_ID attribute.
 When a device receives a route, the device compares the originator ID of the route with the
local router ID. If they are the same, the device discards the route.
5.1.5 Backup RR
To ensure network reliability and prevent single points of failures, redundant RRs are required in a
cluster. An RR allows a BGP device to advertise the routes received from an IBGP peer to other
IBGP peers. Therefore, routing loops may occur between RRs in the same cluster. To solve this
problem, all the RRs in the cluster must use the same cluster ID.
Figure 5-1-2 Backup RR
As shown in Figure 5-1-2, RR1 and RR2 reside in the same cluster and have the same cluster ID
configured.
 When Client1 receives an updated route from an EBGP peer, Client1 advertises this route to
RR1 and RR2 using IBGP.
 After RR1 and RR2 receive this route, they add the local cluster ID to the top of the cluster list
of the route and then reflect the route to other clients (Client2 and Client3) and to each other.
 After RR1 and RR2 receive the reflected route from each other, they check the cluster list of the
route, finding that the cluster list contains their local cluster IDs. RR1 and RR2 discard this
route to prevent routing loops.
5.1.6 RRs of Multiple Clusters in an AS
There may be multiple clusters in an AS. RRs of the clusters establish IBGP peer relationships.
When RRs reside at different network layers, an RR at the lower network layer can be configured as
a client to implement hierarchical RR. When RRs reside at the same network layer, RRs of different
clusters can establish full-mesh connections to implement flat RR.
5.1.7 Hierarchical RR
Figure 5-1-3 Hierarchical RR

In practice, hierarchical RR is often used. As shown in Figure 5-1-3, the ISP provides Internet
routes to AS 100. AS 100 is divided into two clusters, Cluster1 and Cluster2. Four devices in
Cluster1 are core routers and use a backup RR to ensure reliability.
5.1.8 Flat RR
Figure 5-1-4 Flat RR
As shown in Figure 5-1-4, the backbone network is divided into multiple clusters. RRs of the clusters
are non-clients and establish full-mesh connections with each other. Although each client only
establishes an IBGP connection with its RR, all the RRs and clients can receive all routing
information.
5.2 BGP Confederation
In addition to a route reflector, the confederation is another method that reduces the number of
IBGP connections in an AS. A confederation divides an AS into sub-ASs. Full-mesh IBGP
connections are established in each sub-AS. EBGP connections are established between sub-ASs.
ASs outside a confederation still consider the confederation as an AS. After a confederation divides
an AS into
sub-ASs, it assigns a confederation ID (the AS number) to each router within the AS. This brings two
benefits. First, original IBGP attributes are retained, including the Local_Pref attribute, MED
attribute, and Next_Hop attribute. Secondly, confederation-related attributes are automatically
deleted when being advertised outside a confederation. Therefore, the administrator does not need to
configure the rules for filtering information such as sub-AS numbers at the egress of a confederation.
Figure 5-2-1 Networking diagram of a confederation
As shown in Figure 5-2-1, AS 100 is divided into three sub-ASs after a confederation is configured:
AS65001, AS65002, and AS65003. The AS number AS 100 is used as the confederation ID. The
number of IBGP connections in AS 100 is then reduced from 10 to 4, which simplifies the device
configuration and reduces the loads on the network and CPU. In addition, BGP devices outside AS
100 only know the existence of AS 100 but not the confederation within AS 100. Therefore, the
confederation does not increase the CPU load.
5.2.1 Comparisons between a Route Reflector and a Confederation
Table 5-2-1 compares a route reflector and a confederation in terms of the configuration,
device connection, and applications.
Table 5-2-1 Comparisons between a route reflector and a confederation
Route Reflector
Retains the existing network topology and ensures compatibility.
Requires only a route reflector to be configured because clients do not need to know that they are clients of a route reflector.
Requires full-mesh connections between clusters.
Applies to medium and large networks.

5.3 Route Summarization
The BGP routing table of each device on a large network is large. This burdens devices, increases
the route flapping probability, and affects network stability.
Route summarization is a mechanism that combines multiple routes into one route. This mechanism
allows a BGP device to advertise only the summarized route but not all the specific routes to peers,
therefore reducing the size of the BGP routing table. If the summarized route flaps, the network is
not affected, so network stability is improved.
BGP supports automatic summarization and manual summarization on IPv4 networks, and
supports only manual summarization on IPv6 networks.
 Automatic summarization: summarizes the routes imported by BGP. After automatic

summarization is configured, BGP summarizes routes based on the natural network segment
and advertises only the summarized route to peers. For example, BGP summarizes 10.1.1.1/24
and
10.2.1.1/24 (two Class A addresses with non-natural mask) into 10.0.0.0/8 (Class A address
with natural mask).
 Manual summarization: summarizes routes in the local BGP routing table. Manual
summarization can help control the attributes of the summarized route and determine whether
to advertise specific routes.
To prevent routing loops caused by route summarization, BGP uses the AS_Set attribute. The
AS_Set attribute is an unordered set of all ASs that a route passes through. When the summarized
route enters an AS in the AS_Set attribute again, BGP finds that the local AS number has been
recorded in the AS_Set attribute of the route and discards this route to prevent a routing loop.
5.4 Route Dampening
When BGP is used on complex networks, route flapping occurs frequently. To prevent frequent
route flapping, BGP uses route dampening to suppress unstable routes.
Route flapping is a process of adding a route to an IP routing table and then withdrawing this route.
When route flapping occurs, a BGP device sends an Update message to its neighbors. The devices
that receive the Update message need to recalculate routes and modify routing tables. Frequent route
flapping consumes lots of bandwidths and CPU resources and even affects normal network operation.

1210
Figure 5-4-1 Diagram of BGP route dampening
Route dampening measures the stability of a route using a penalty value. A larger penalty value
indicates a less stable route. As shown in Figure 5-4-1, each time route flapping occurs, BGP
increases the penalty of this route by a value of 1000. When the penalty value of a route exceeds the
suppression threshold, BGP suppresses this route, and does not add it to the IP routing table or
advertise any Update message to peers. After a route is suppressed for a period of time (half-life), the
penalty value is
reduced by half. When the penalty value of a route decreases to the suppression threshold, the route is
reusable and is added to the routing table. At the same time, BGP advertises an Update message to
peers. The suppression time is the period from when a route is suppressed to when the route is
reusable.
Route dampening applies only to EBGP routes but not IBGP routes. IBGP routes may include the
routes of the local AS, and an IGP network requires that the routing tables of devices within an AS be
the same. If IBGP routes were dampened, routing tables on devices are inconsistent when these
devices have different dampening parameters. Therefore, route dampening does not apply to IBGP
routes.
5.5 Association between BGP and BFD
BGP periodically sends messages to peers to detect the status of the peers. It takes more than 1 minute
for this detection mechanism to detect a fault. When data is transmitted at gigabit rates, long-time
fault detection will cause packet loss. This cannot meet high reliability requirements of networks.
Association between BGP and bidirectional forwarding detection (BFD) uses the millisecond-level
fault detection of BFD to improve network reliability.
Figure 5-5-1 Networking diagram of association between BGP and BFD
As shown in Figure 5-5-1, RouterA belongs to AS 100 and RouterB belongs to AS 200. RouterA and
RouterB are directly connected and establish the EBGP peer relationship. Association between BGP
and BFD is configured on RouterA and RouterB. When a fault occurs on the link between RouterA and
RouterB, BFD can rapidly detect that the BFD session changes from Up to Down and notify this
fault to RouterA and RouterB. RouterA and RouterB process the neighbor Down event and select
routes again using BGP.
5.6 BGP Tracking
BGP tracking provides fast link fault detection to speed up network convergence. When a fault
occurs on the link between BGP peers that have BGP tracking configured, BGP tracking can quickly
detect peer unreachability and instruct the routing management module to notify BGP of the fault,
implementing rapid network convergence.
Compared to BFD, BGP tracking is easy to configure because it needs to be configured only on the
local device. BGP tracking is a fault detection mechanism at the routing layer, whereas BFD is a fault
detection mechanism at the link layer. BGP route convergence on a network where BGP tracking is
configured is slower than that on a network where BFD is configured. Therefore, BGP tracking
cannot meet the requirements of voice services that require fast convergence.
5.6.1 Applications
As shown in Figure 5-6-1, RouterA and RouterB, and RouterB and RouterC establish IGP
connections. RouterA and RouterC establish an IBGP peer relationship. BGP tracking is configured on
RouterA. When a fault occurs on the link between RouterA and RouterB, IGP performs fast
convergence. Subsequently, BGP tracking detects the unreachability of the route to RouterC and
notifies the fault to
BGP on RouterA, which then interrupts the BGP connection with RouterC.
Figure 5-6-1 Networking diagram of BGP tracking

NOTE:
If establishing an IBGP peer relationship requires IGP routes, the interval between peer
unreachability discovery and connection interruption needs to be configured, and this interval must be
longer than the IGP route convergence time. Otherwise, the BGP peer relationship may have been
interrupted before IGP route flapping caused by transient interruption is suppressed, causing
unnecessary BGP
convergence.
5.7 BGP Auto FRR
BGP Auto Fast Reroute (FRR) is a protection measure against link failures. It applies to the
network topology with primary and backup links and provides sub-second-level switching between
two BGP peers or two next hops.
After BGP Auto FRR is enabled on a device, the device selects the optimal route from the routes that
carry the same prefix and are learned from multiple peers as the primary link to forward packets, and
uses the second optimal route as the backup link. When the primary link becomes faulty, the system
rapidly responds to the notification that the BGP route becomes unreachable, and then switches traffic
from the primary link to the backup link. After BGP convergence is complete, BGP Auto FRR uses
the optimal route selected by BGP to guide traffic forwarding.
5.7.1 Applications
As shown in Figure 5-7-1, RouterD advertises a learned BGP route to RouterB and RouterC in AS
100; RouterB and RouterC then advertise the BGP route to RouterA through a route reflector. RouterA
receives two routes whose next hops are RouterB and RouterC respectively. Then RouterA selects a
route according to the configured policy. Assume that the route sent from RouterB, namely LinkB, is
preferred. The route sent from RouterC, namely LinkC, then functions as the backup link.
Figure 5-7-1 Networking diagram of BGP Auto FRR

When a router along LinkB fails or faults occur on LinkB, the next hop of the route from RouterA
to RouterB becomes invalid. If BGP Auto FRR is enabled on RouterA, the forwarding plane
quickly switches traffic sent from RouterA to RouterD to LinkC. This prevents traffic loss. In
addition, RouterA reselects the route sent from RouterC and updates the FIB table.
5.8 BGP GR and NSR
BGP graceful restart (GR) and non-stop routing (NSR) are high availability solutions that minimize
the impact of device failures on user services.
5.8.1 BGP GR
BGP GR ensures that the forwarding plane continues to guide data forwarding during a device
restart or active/standby switchover. The operations on the control plane, such as reestablishing peer
relationships and performing route calculation, do not affect the forwarding plane. This mechanism
prevents service interruptions caused by route flapping and improves network reliability.
GR concepts are as follows:
 GR restarter: is the device that is restarted by the administrator or triggered by failures to perform
GR.
 GR helper: is the neighbor that helps the GR restarter to perform GR.
 GR time: is the time during which the GR helper retains forwarding information after
detecting the restart or active/standby switchover of the GR restarter.
BGP GR process is as follows:
1. Using the BGP capability negotiation mechanism, the GR restarter and helper know each other's
GR capability and establish a GR session.
2. When detecting the restart or active/standby switchover of the GR restarter, the GR helper
does not delete the routing information and forwarding entries of the GR restarter or notify
other neighbors of the restart or switchover, but waits to reestablish a BGP connection with
the GR restarter.
3. The GR restarter reestablishes neighbor relationships with all GR helpers before the GR
time expires.
5.8.2 BGP NSR
NSR is a reliability technique that prevents neighbors from detecting the control plane switchover. It
applies to the devices that have the active and standby MPUs configured. Compared to GR, NSR
does not require the help of neighbors and does not need to deal with interoperability issues.
Table 5-8-1 Comparisons between active/standby switchovers with and without GR and NSR
Act
W
The BGP peer relationship is reestablished.

Table 5-8-1 Comparisons between active/standby switchovers with and without GR and NSR
Act
W
Routes are recalculated.
The forwarding table changes.
Traffic is lost during forwarding, and services are interrupted.
The network detects route changes, and route flapping occurs for a short period of time.
5.9 Dynamic Update Peer-Groups
Currently, the rapid growth in the size of the routing table and the complexity of the network
topology require BGP to support more peers. Especially in the case of a large number of peers and
routes,
high-performance grouping and forwarding are required when a router needs to send routes to a
large number of BGP peers, most of which share the same outbound policies.
The dynamic update peer-groups feature treats all the BGP peers with the same outbound policies as
an update-group. In this case, routes are grouped uniformly and then sent separately. That is, each
route to be sent is grouped once and then sent to all peers in the update-group, improving grouping
efficiency exponentially. For example, a route reflector (RR) has 100 clients and needs to reflect
100,000 routes
to these clients. If the RR sends the routes grouped per peer to 100 clients, the total number of times
that all routes are grouped is 10,000,000 (100,000 x 100). After the dynamic update peer-groups
feature is used, the total number of grouping times changes to 100,000 (100,000 x 1), improving
grouping performance by a factor of 100.
5.9.1 Applications
BGP uses the dynamic update peer-groups technology when a large number of peers and routes
exist and most peers share the same outbound policies, improving BGP route grouping and
forwarding performance. The dynamic update peer-groups feature applies to the following
scenarios:
 International gateway
As shown in Figure 5-9-1, the Internet gateway (IGW) router sends routes to all neighboring
ASs. If the IGW router supports the dynamic update peer-groups feature, its BGP
route forwarding performance will be greatly improved.
Figure 5-9-1 Networking diagram of the international gateway
 RR
As shown in Figure 5-9-2, RRs send routes to all clients. If the RRs support the dynamic
update peer-groups feature, their BGP route forwarding performance will be greatly improved.
Figure 5-9-2 Networking diagram of RRs
 ASBR
As shown in Figure 5-9-3, RouterB, as an Autonomous System Boundary Router (ASBR),

sends all the routes received from an EBGP neighbor RouterA to all IBGP neighbors. If RouterB
supports the dynamic update peer-groups feature, its BGP route forwarding performance will be
greatly improved.
Figure 5-9-3 Networking diagram of a PE connecting to multiple IBGP neighbors

5.10 Examples for Configuring of BGP Extension Technique
5.10.1 Example for Configuring a BGP Route Reflector
As shown in Figure 5-10-1, eight Routers need to form an IBGP network. Full-mesh BGP
connections have been established between RouterB, RouterD, and RouterE. Users require that the
IBGP network be formed without interrupting full-mesh BGP connections between RouterB,
RouterD, and RouterE and require simplified device configuration and management.
Figure 5-10-1 Networking diagram of configuring a BGP RR
Device
RouterA
Router B
RouterC
1. Configure RouterB as the route reflector of Cluster1 and RouterD and RouterE as the clients
of RouterB. Prohibit communication between the clients to form an IBGP network without
interrupting full-mesh BGP connections between RouterB, RouterD, and RouterE.
2. Configure RouterC as the route reflector of Cluster2 and RouterF and RouterG as the clients of
RouterC to simplify device configuration and management.
Procedure
1. Configure an IP address for each interface. The configuration details are not mentioned here.
2. Configure the IBGP connections between the clients and the RR and between the non-
clients and the RR. The configuration details are not mentioned here.
3. Configure the RR.
[RouterB] bgp 65010 [RouterB–bgp]

router-id 2.2.2.2 [RouterB–bgp] group
in_rr internal [RouterB–bgp] peer
10.1.4.2 group in_rr [RouterB–bgp] peer
10.1.5.2 group in_rr [RouterB–bgp]
ipv4-family unicast
[RouterB–bgp-af-ipv4] peer in_rr reflect-client
[RouterB–bgp-af-ipv4] undo reflect between-clients
[RouterB–bgp-af-ipv4] reflector cluster-id 1
[RouterB–bgp-af-ipv4] quit
[RouterC] bgp 65010

[RouterC-bgp] group in_rr internal
[RouterC-bgp] peer 10.1.7.2 group in_rr
[RouterC-bgp] peer 10.1.8.2 group in_rr
[RouterC-bgp-af-ipv4] peer in_rr reflect-client
[RouterC-bgp-af-ipv4] reflector cluster-id 2
[RouterC-bgp-af-ipv4] quit
# Display the routing table of RouterD.
[RouterD] display bgp routing-table 9.1.1.0

9.1.1.0/24: From: 10.1.4.1 (2.2.2.2)
Relay IP Nexthop: 0.0.0.0
Relay IP Out-Interface:
AS-path Nil, origin igp, MED 0, localpref 100, pref-val 0, internal, pre 255
Originator: 1.1.1.1
Cluster list: 0.0.0.1
You can view that RouterD has learned the route advertised by RouterA from RouterB.
For details, see the Originator and Cluster_ID attributes of the route.
Configuration Files
#
sysname RouterA
#
ip address 10.1.1.2 255.255.255.0
#
ip address 10.1.3.2 255.255.255.0
#
ip address 9.1.1.1 255.255.255.0
#

1210
bgp 65010
router-id 1.1.1.1
#
ipv4-family unicast
network 9.1.1.0 255.255.255.0
#
return
#
sysname RouterB
#
ip address 10.1.1.1 255.255.255.0
#
ip address 10.1.4.1 255.255.255.0
#
ip address 10.1.5.1 255.255.255.0
#
ip address 10.1.2.1 255.255.255.0
#
bgp 65010
router-id 2.2.2.2
group in_rr internal
peer 10.1.4.2 group in_rr
#
ipv4-family unicast
undo reflect between-clients
reflector cluster-id 1
peer in_rr enable
peer in_rr reflect-client
#
return
#
sysname RouterC
#
ip address 10.1.2.2 255.255.255.0
#
ip address 10.1.3.1 255.255.255.0
#
ip address 10.1.7.1 255.255.255.0
#
ip address 10.1.8.1 255.255.255.0
#
bgp 65010
router-id 3.3.3.3
group in_rr internal
#
ipv4-family unicast
reflector cluster-id 2
peer in_rr enable
peer in_rr reflect-client
#
return
#
sysname RouterD
#
ip address 10.1.4.2 255.255.255.0
#
ip address 10.1.6.1 255.255.255.0
#
bgp 65010
router-id 4.4.4.4
#
ipv4-family unicast
#
return
NOTE:
The configuration file of other routers is similar to that of RouterD and is omitted here.
5.10.2 Example for Configuring a BGP Confederation
As shown in Figure 5-10-2, there are multiple BGP routers in AS 200. It is required that the number of
IBGP connections be reduced.
Figure 5-10-2 Networking diagram of configuring the confederation
1. Configure a BGP confederation on each router in AS 200 to divide AS 200 into three sub-
ASs: AS 65001, AS 65002, and AS 65003. Three routers in AS 65001 establish full-mesh
IBGP connections to reduce the number of IBGP connections.
Procedure
1. Configure an IP address to each interface. The configuration details are not mentioned
here.
2. Configure the BGP confederation.
[RouterA] bgp 65001

[RouterA-bgp] confederation id 200
[RouterA-bgp] confederation peer-as 65002 65003
[RouterA-bgp-af-ipv4] peer 10.1.1.2 next-hop-local
[RouterB] bgp 65002

[RouterB-bgp] router-id 2.2.2.2 [RouterB-
bgp] confederation id 200 [RouterB-bgp]
confederation peer-as 65001
[RouterB-bgp] quit
[RouterC] bgp 65003

[RouterC-bgp] router-id 3.3.3.3 [RouterC-
bgp] confederation id 200 [RouterC-bgp]
confederation peer-as 65001
[RouterC-bgp] quit
3. Configure IBGP connections inside AS 65001.
[RouterA] bgp 65001

[RouterD] bgp 65001

[RouterD-bgp] confederation id 200
[RouterD-bgp] quit
[RouterE] bgp 65001

[RouterE-bgp] router-id 5.5.5.5
[RouterE-bgp] confederation id 200
[RouterE-bgp] peer 10.1.4.1 as-number 65001
[RouterE-bgp] peer 10.1.5.1 as-number 65001
[RouterE-bgp] quit
4. Configure the EBGP connection between AS 100 and AS 200.
[RouterA] bgp 65001

[RouterA-bgp] quit
# Configure RouterF.
[RouterF] bgp 100

[RouterF-bgp] router-id 6.6.6.6
[RouterF-bgp] peer 200.1.1.1 as-number 200
[RouterF-bgp] ipv4-family unicast
[RouterF-bgp-af-ipv4] network 9.1.1.0 255.255.255.0
[RouterF-bgp-af-ipv4] quit
# Check the routing table of RouterB.
[RouterB] display bgp routing-table

Path/Ogn
*>i 9.1.1.0/24 10.1.1.1 0 100 0 (65001)
100i
[RouterB] display bgp routing-table 9.1.1.0
9.1.1.0/24: From: 10.1.1.1 (1.1.1.1)
Relay IP Out-Interface: GigabitEthernet1/0/0
AS-path (65001) 100, origin igp, MED 0, localpref 100, pref-val 0, valid, external-
confed, best, select, active, pre 255
# Check the BGP routing table of RouterD.
[RouterD] display bgp routing-table

Path/Ogn
*>i 9.1.1.0/24 10.1.3.1 0 100 0 100i
[RouterD] display bgp routing-table 9.1.1.0
9.1.1.0/24: From: 10.1.3.1 (1.1.1.1)
Relay IP Out-Interface: GigabitEthernet1/0/0
AS-path 100, origin igp, MED 0, localpref 100, pref-val 0, valid, internal-confed,
best, select, pre 255
Configuration Files
#
sysname RouterA
#
ip address 10.1.4.1 255.255.255.0
#
ip address 200.1.1.1 255.255.255.0
#
ip address 10.1.1.1 255.255.255.0
#
ip address 10.1.2.1 255.255.255.0
#
ip address 10.1.3.1 255.255.255.0
#
bgp 65001
router-id 1.1.1.1
confederation id 200
confederation peer-as 65002 65003
#
ipv4-family unicast
peer 10.1.1.2 next-hop-local
#
return
#
sysname RouterB
#
ip address 10.1.1.2 255.255.255.0
#
bgp 65002
router-id 2.2.2.2 confederation
id 200 confederation peer-as
65001 peer 10.1.1.1 as-number
65001
#
ipv4-family unicast
#
return
NOTE:
The configuration file of RouterC is similar to that of RouterB, and is not mentioned here.
#
sysname RouterD
#
ip address 10.1.3.2 255.255.255.0
#
ip address 10.1.5.1 255.255.255.0
#
bgp 65001
router-id 4.4.4.4
confederation id 200
#
ipv4-family unicast
#
return
NOTE:
The configuration file of RouterE is similar to that of RouterD, and is not mentioned here.
#
sysname RouterF
#
ip address 200.1.1.2 255.255.255.0
#
ip address 9.1.1.1 255.255.255.0
#
bgp 100
router-id 6.6.6.6
#
ipv4-family unicast
network 9.1.1.0 255.255.255.0
#
return
5.10.3 Example for Associating BGP with BFD
As shown in Figure 5-10-3, RouterA belongs to AS 100, RouterB and RouterC belong to AS 200.
EBGP connections are established between RouterA and RouterB, and between RouterA and
RouterC.
Service traffic is transmitted along the primary link RouterA→RouterB. The link
RouterA→RouterC→RouterB functions as the backup link. Fast fault detection is required to
allow traffic to be fast switched from the primary link to the backup link.

1210
Figure 5-10-3 Networking diagram of configuring BFD for BGP
1. Configure basic BGP functions on each router.
2. Configure the MED attribute to control route selection.
3. Enable BFD on RouterA and RouterB.

NOTE:
If two routers establish an EBGP peer relationship over a direct link, BFD for BGP does not need to
be configured. This is because the ebgp-interface-sensitive command is enabled by default for
directly-connected EBGP peers.
Procedure
Configure an IP address to each interface as shown in Figure 5-10-3. For details about
the configuration, see the following configuration files.
2. Configure basic BGP functions. Establish EBGP peer relationships between RouterA and
RouterB, and between RouterA and RouterC and an IBGP peer relationship between
RouterB and RouterC.
[RouterA] bgp 100

[RouterA-bgp] peer 200.1.1.2 ebgp-max-hop
[RouterA-bgp] peer 200.1.2.2 ebgp-max-hop
[RouterA-bgp] quit
[RouterB] bgp 200

[RouterB-bgp] peer 200.1.1.1 ebgp-max-hop
[RouterB-bgp] network 172.16.1.0 255.255.255.0
[RouterB-bgp] quit
[RouterC] bgp 200

[RouterC-bgp] peer 200.1.2.1 ebgp-max-hop
[RouterC-bgp] quit
# Check the status of BGP peer relationships on RouterA. The command output shows that the
BGP peer relationships are in the Established state.
<RouterA> display bgp peer

Total number of peers : 2 Peers in established state : 2
Peer V AS MsgRcvd MsgSent OutQ Up/Down State

PrefRcv
200.1.1.2
200.1.2.2
3. Configure the MED attribute.
Set the MED value for the route sent from RouterC or RouterB to RouterA by using a
routing policy.
[RouterB] route-policy 10 permit node 10

1210
[RouterB] bgp 200
[RouterB-bgp] peer 200.1.1.1 route-policy 10 export
[RouterC] route-policy 10 permit node 10

[RouterC-route-policy] apply cost 150
[RouterC-route-policy] quit
[RouterC] bgp 200
[RouterC-bgp] peer 200.1.2.1 route-policy 10 export
# Check BGP routing information on RouterA.


Path/Ogn
*> 172.16.1.0/24
*
As shown in the BGP routing table, the next-hop address of the route to 172.16.1.0/24 is
200.1.1.2, and service traffic is transmitted on the primary link between RouterA and RouterB.
4. Configure BFD, and set the interval for transmitting BFD packets, the interval for
receiving
BFD packets, and the local detection multiplier.
# Enable BFD on RouterA. Set the minimum intervals for transmitting and receiving BFD
packets to 100ms and the local detection multiplier to 4.
[RouterA] bfd
[RouterA-bfd] quit
[RouterA] bgp 100
[RouterA-bgp] peer 200.1.1.2 bfd enable
[RouterA-bgp] peer 200.1.1.2 bfd min-tx-interval 100 min-rx-interval 100
detect-multiplier 4
# Enable BFD on RouterB. Set the minimum intervals for transmitting and receiving BFD
packets to 100ms and the local detection multiplier to 4.
[RouterB] bfd
[RouterB-bfd] quit
[RouterB] bgp 200
[RouterB-bgp] peer 200.1.1.1 bfd enable
[RouterB-bgp] peer 200.1.1.1 bfd min-tx-interval 100 min-rx-interval 100
detect-multiplier 4
# Display all BFD sessions on RouterA.
<RouterA> display bgp bfd session all

Local_Address Peer_Address LD/RD Interface
200.1.1.1 200.1.1.2 8201/8201 GigibitEth ernet1/0/0
Tx-interval(ms) Rx-interval(ms) Multiplier Session-State
100 100 4 Up
Wtr-interval(m)
0
# Run the shutdown command on GE 2/0/0 of RouterB to simulate a fault on the primary link.

[RouterB-Gigabitethernet2/0/0] shutdown
# Check the BGP routing table on RouterA.


Path/Ogn
*> 172.16.1.0/24 200.1.2.2 150 0 200i
As shown in the BGP routing table, the backup link of RouterA -> RouterC -> RouterB
takes effect after the primary link fails, and the next-hop address of the route to
172.16.1.0/24 is
200.1.2.2.
Configuration Files
#
sysname RouterA
#
bfd
#
interface Gigabitethernet1/0/0
ip address 200.1.2.1 255.255.255.0
#
ip address 200.1.1.1 255.255.255.0
#
bgp 100
router-id 1.1.1.1
peer 200.1.1.2 ebgp-max-hop 255
peer 200.1.1.2 bfd min-tx-interval 100 min-rx-interval 100 detect-multiplier
4 peer 200.1.1.2 bfd enable
#
ipv4-family unicast
#
return
#
sysname RouterB
#
bfd
#
ip address 9.1.1.1 255.255.255.0
#
ip address 200.1.1.2 255.255.255.0
#
ip address 172.16.1.1 255.255.255.0
#
bgp 200
router-id 2.2.2.2
peer 200.1.1.1 bfd min-tx-interval 100 min-rx-interval 100 detect-multiplier
4 peer 200.1.1.1 bfd enable
#
ipv4-family unicast
network 172.16.1.0 255.255.255.0
peer 9.1.1.2 enable
peer 200.1.1.1 route-policy 10 export
#
route-policy 10 permit node 10
apply cost 100
#
return
#
sysname RouterC
#
bfd
#
ip address 200.1.2.2 255.255.255.0
#
ip address 9.1.1.2 255.255.255.0
#
bgp 200
router-id 3.3.3.3
#
ipv4-family unicast
peer 9.1.1.1 enable
peer 200.1.2.1 route-policy 10 export
#
route-policy 10 permit node 10
apply cost 150
#
return
Chapter 6 Router Import and Control
6.1 Routing Policy
6.1.1 Summary
Routing policies are used to filter routes and set attributes for routes. By changing route attributes
(including reachability), a route policy changes the path that network traffic passes through.
Purpose
When advertising, receiving, and importing routes, routing protocols implement certain policies
based on actual networking requirements to filter routes and change the attributes of the routes.
Routing policies serve the following purposes:
 To control route receiving and advertising
Only the required and valid routes are received or advertised. This reduces the size of the
routing table and improves network security.
 To control route importing
A routing protocol may import routes discovered by other routing protocols. Only routes
that satisfy certain conditions are imported to meet the requirements of the protocol.
 To modify attributes of specified routes
Attributes of the routes that are filtered by a routing policy are modified to meet the
requirements of the local device.
Benefits
This feature brings the following benefits:
 Controls the size of the routing table, saving system resources.
 Controls route receiving, advertising and importing, improving network security.

 Modifies attributes of routes for proper traffic planning, improving network performance.
6.1.2 Principle
A routing policy uses different matching rules and modes to select routes and change route
attributes. Six filters in the routing policy can be used independently to filter routes in special
scenarios. If the device supports the BGP to IGP function, the private attributes of BGP can serve as
matching rules when the IGP imports BGP routes.
Figure 6-1-1 Working mechanism of the routing policy
As shown in Figure 6-1-1, a routing policy consists of N nodes (N ≥ 1). The system checks routes
in the nodes of a routing policy with the node ID in ascending order. The If-match clauses define
matching rules related to route attributes and six filters.
When a route matches all If-match clauses in a node, the route enters the matching mode
without being checked in other nodes. The following two matching modes are supported:
 permit: A route is permitted, and actions defined by the Apply clauses are performed on
the route to set its attributes.
 deny: A route is denied.
If a route does not match one If-match clause in a node, the route enters to the next node. If a
route does not match any one of the nodes, the route is filtered out.
6.1.3 Filters
The six filters specified in If-match clauses in a routing policy are access control list (ACL), IP prefix
list, AS_Path filter, community filter, extended community filter, and RD filter. The six filters have
their own matching rules and modes. Therefore, they can be used independently to filter routes in
some special situations.
ACL
ACLs check inbound interface, source or destination IP address, source or destination port number,
and protocol of packets to filter routes. ACLs can be used independently when routing protocols
advertise and receive routes. The If-match clauses in a routing policy support only basic ACLs.
ACLs can be used in not only a routing policy but other scenarios. For details, see the Feature
Description - Security - ACL.
IP prefix list
IP prefix lists check IP prefixes of the source IP address, destination IP address, and next hop
address to filter routes. They can be used independently when routing protocols advertise and
receive routes.
Each IP prefix list consists of multiple indexes, and each index matches a node. An IP prefix list
checks routes in all nodes with the indexes in ascending order. If a route matches one node, the route is
no longer checked by other nodes. If a route does not match any one of the nodes, the route is filtered
out.
The IP prefix list supports exact matching or matching within a specified mask length.
NOTE:
When the IP address is 0.0.0.0, a wildcard address, all routes in the mask length range are permitted
or denied.
AS_Path filter
The AS_Path filter uses the AS_Path attribute of BGP to filter routes. It can be used
independently when BGP advertises and receives routes.
The AS_Path attribute records all ASs that a route passes through. For details about the
AS_Path attribute, see "Introduction to BGP" in the Feature Description - IP Routing - BGP.
Community filter
The community filter uses the community attribute of BGP to filter routes. It can be used
independently when BGP advertises and receives routes.
The community attribute identifies a group of routes with the same properties. For details about
the community attribute, see "Introduction to BGP" in the Feature Description - IP Routing -
BGP.
Extended community filter

The extended community filter uses the extended community attribute of BGP to filter routes. It can
be used independently when VPN targets are used to identify routes in a VPN.
Currently, the extended community filter applies only to the VPN target attribute in a VPN. On a
BGP/MPLS IP VPN, VPN targets are used to control the advertising and receiving of VPN routing
information between sites. For details about the VPN target attribute, see "Introduction to
BGP/MPLS IP VPN" in the Feature Description - VPN - BGP/MPLS IP VPN.
Route Distinguisher (RD) filter
The RD filter uses the RD attribute in a VPN to filter routes. It can be used independently when the RD
attribute is used to identify routes in a VPN.
A VPN instance uses RDs to separate address spaces and distinguish the IP prefixes with the
same address space. For details about the RD attribute, see "Introduction to BGP/MPLS IP VPN"
in the Feature Description - VPN - BGP/MPLS IP VPN.
6.1.4 BGP to IGP function
The BGP to IGP function enables IGP to identify private attributes of BGP such as the
community, extended community, and AS-Path attributes.
Routing policies can be used when an IGP imports BGP routes. BGP private attributes can be used
as matching rules in routing policies only when the device supports the BGP to IGP function. When
the device does not support the BGP to IGP function, the IGP cannot identify private attributes of
BGP routes. Therefore, the matching rule does not take effect.
6.2 Policy-based Routing
6.2.1 Summary
Policy-based routing (PBR) is a mechanism that makes routing decisions based on user-
defined policies. PBR includes local PBR, interface PBR, and smart policy routing (SPR).
NOTE:
The differences between PBR and routing policy are as

follows:
PBR implements routing based on packets. It routes data packets based on user-defined policies
instead of following the routes in the existing routing table.
Routing policies implement routing based on routing information. Routing policies are used to filter
routes and set route attributes. You can change route attributes (including reachability) to change
a route over which network traffic is transmitted.
Purpose
Traditionally, devices searches routing tables for routes of packets based on their destination
addresses and then forward the packets. Currently, more users require that devices route packets
based on

1210
user-defined policies. PBR allows network administrators to make user-defined policies to
change

1210
packet routes based on source addresses, packet size, and link quality in addition to
destination addresses.
Benefits
PBR has the following advantages:
 Allows network administrators to make user-defined policies for routing packets, which
improves flexibility of route selection.
 Allows different data flows to be forwarded on different links, which increases link usage.
 Uses cost-effective links to transmit service data without affecting service quality, which
reduces the cost of enterprise data services.
6.2.2 Local PBR
Local PBR applies only to locally generated packets, such as ping packets.
Local PBR on a device can have multiple local PBR nodes. Each local PBR node has a priority.
The device attempts to match locally generated packets with rules bound with local PBR nodes in
descending order of priority.
Implementation
When sending locally generated packets, a device attempts to match the packets with rules bound
with local PBR nodes in descending order of priority. Local PBR supports rules based on access
control list (ACL) and packet length.
 If the device finds a matching local PBR node, it performs the following steps:
1. Checks whether the priority of the packets has been set.
 If so, the device applies the configured priority to the packets and
performs the next step.
 If not, the device performs the next step.
2. Checks whether an outbound interface has been configured for local PBR.
 If so, the device sends the packets through the outbound interface.
 If not, the device performs the next step.
3. Checks whether next hops have been configured for local PBR.
NOTE:
Two next hops can be configured for load balancing.
 If a next hop is configured for packet forwarding in PBR and the next hop
is reachable, the device checks whether association between next hop and
route is configured.
 If association between next hop and route is configured, the
device detects whether the configured IP address of the route
associated with the next hop in PBR is reachable.
 If the IP address is reachable, the configured next hop
takes effect, and the device forwards packets to the
next hop.
 If the IP address is unreachable, the configured next hop
does not take effect, and the device checks whether a
backup next hop has been configured. If a backup next
hop has been configured and is reachable, the device
forwards packets to the backup next hop. If no backup
next hop is configured or the configured backup next
hop is unreachable, the device searches the routing table
for a
route according to the destination of packets. If no route
is available, the device performs the next step.
 If association between next hop and route is not configured,
the device sends packets to the next hop.
 If a next hop is configured in PBR but the next hop is unreachable, the
device checks whether a backup next hop has been configured. If a backup
next hop has been configured and is reachable, the device forwards
packets to the backup next hop. If no backup next hop is configured or the
configured backup next hop is unreachable, the device searches the
routing table for a route according to the destination of packets. If no route
is available, the device performs the next hop.
 If a next hop is configured for packet forwarding in PBR and the next hop
is reachable, the device sends packets to the next hop.
 If the next hop is not configured, the device searches the routing table for
a route based on the destination addresses of the packets. If no route is
available, the device performs the next hop.
4. Checks whether a default outbound interface has been configured for local PBR.
 If so, the device sends the packets through the default outbound interface.
 If not, the device performs the next hop.
5. Checks whether default next hops have been configured for local PBR.
 If so, the device sends the packets to the default next hops.
 If not, the device performs the next hop.
6. Discards the packets and generates ICMP_UNREACH messages.
 If the device does not find a matching local PBR node, it searches the routing table for a
route based on the destination addresses of the packets and then sends the packets.
6.2.3 Interface PBR
Interface PBR applies only to packets received from other devices, but not to locally generated
packets such as local ping packets.
Implementation
Interface PBR is implemented based on the redirect action configured in a traffic behavior and takes
effect only on the inbound packets. By default, a device forwards packets to the next hop found in
the routing table. If interface PBR is configured, the device forwards packets to the next hop
specified by interface PBR.
When the device forwards packets to the next hop specified by interface PBR, the device triggers
ARP learning if it has no ARP entry corresponding to the IP address of the specified next hop. If the
device cannot learn this ARP entry, it forwards packets to the next hop found in the routing table. If
the device has this ARP entry, it forwards packets to the next hop specified by interface PBR.
6.3 Examples for Configuring of Route Import and Control
6.3.1 Example for Filtering Received and Advertised Routes
As shown in Figure 6-3-1, on the network where OSPF runs, RouterA receives routes from the
Internet, and provides these routes for the OSPF network. Users want devices on the OSPF network to
access
only the network segments 172.1.17.0/24, 172.1.18.0/24, and 172.1.19.0/24, and RouterC to
access only the network segment 172.1.18.0/24.
Figure 6-3-1 Networking diagram for filtering received and advertised routes
1. Configure a routing policy on RouterA and apply the routing policy during route
advertisement.
When routes are advertised, the routing policy allows RouterA to provide routes from
network segments 172.1.17.0/24, 172.1.18.0/24, and 172.1.19.0/24 for RouterB, and allows
devices on the OSPF network to access these three network segments.
2. Configure a routing policy on RouterC and apply the routing policy during route importing.
When routes are imported, the routing policy allows RouterC to receive only the routes from
the network segment 172.1.18.0/24 and access this network segment.
Procedure
1. Assign an IP address to each interface.
[RouterA] ospf
[RouterB] ospf
[RouterC] ospf
[RouterD] ospf
3. Configure five static routes on RouterA and import these routes to OSPF.
[RouterA] ip route-static 172.1.16.0 24 NULL 0

[RouterA] ospf
[RouterA-ospf-1] import-route static
# Check the IP routing table on RouterB. You can view that the five static routes are imported to
OSPF.
[RouterB] display ip routing-table

------------------------------------------------------------------------------
172.1.16.0/24 O_ASE 150 1 D 192.168.1.1
172.1.17.0/24 O_ASE 150 1 D 192.168.1.1
172.1.18.0/24 O_ASE 150 1 D 192.168.1.1
172.1.19.0/24 O_ASE 150 1 D 192.168.1.1
172.1.20.0/24 O_ASE 150 1 D 192.168.1.1
192.168.1.0/24 Direct 0 0 D 192.168.1.2
192.168.1.1/32 Direct 0 0 D 192.168.1.1
192.168.2.0/24 Direct 0 0 D 192.168.2.1
192.168.2.2/32 Direct 0 0 D 192.168.2.2
192.168.3.0/24 Direct 0 0 D 192.168.3.1
192.168.3.2/32 Direct 0 0 D 192.168.3.2
4. Configure the policy for advertising routes.
# Configure the IP prefix list named a2b on RouterA.
[RouterA] ip ip-prefix a2b index 10 permit 172.1.17.0 24

# Configure the policy for advertising routes on RouterA and use the IP prefix list named a2b
to filter routes.
[RouterA] ospf
[RouterA-ospf-1] filter-policy ip-prefix a2b export static
# Check IP routing table on RouterB, and you can view the three routes received by RouterB
from a2b.
[RouterB] display ip routing-table

------------------------------------------------------------------------------
172.1.17.0/24 O_ASE 150 1 D 192.168.1.1
172.1.18.0/24 O_ASE 150 1 D 192.168.1.1
172.1.19.0/24 O_ASE 150 1 D 192.168.1.1
192.168.1.0/24 Direct 0 0 D 192.168.1.2
192.168.1.1/32 Direct 0 0 D 192.168.1.1
192.168.2.0/24 Direct 0 0 D 192.168.2.1
192.168.2.2/32 Direct 0 0 D 192.168.2.2
192.168.3.0/24 Direct 0 0 D 192.168.3.1
192.168.3.2/32 Direct 0 0 D 192.168.3.2
5. Configure the policy for receiving routes.
# Configure the IP prefix list named in on RouterC.
[RouterC] ip ip-prefix in index 10 permit 172.1.18.0 24
# Configure the policy for receiving routes on RouterC, and use IP prefix list named in to
filter routes.
[RouterC] ospf
[RouterC-ospf-1] filter-policy ip-prefix in import
# Check the IP routing table on RouterC, and you can find that RouterC in the local core
routing table receives only one route from the IP prefix list named in.

------------------------------------------------------------------------------
172.1.18.0/24 O_ASE 150 1 D 192.168.2.1
192.168.2.0/24 Direct 0 0 D 192.168.2.2
192.168.2.1/32 Direct 0 0 D 192.168.2.1
# Check the IP routing table on RouterD, and you can find that RouterD in the local core
routing table receives all the routes advertised by RouterB.
[RouterD] display ip routing-table

------------------------------------------------------------------------------

127.0.0.0/8
127.0.0.1/32
172.1.17.0/24
172.1.18.0/24 O_ASE 150 1 D 192.168.3.1
172.1.19.0/24 O_ASE 150 1 D 192.168.3.1
192.168.1.0/24 OSPF 10 1 D 192.168.3.1
192.168.2.0/24 OSPF 10 1 D 192.168.3.1
192.168.3.0/24 Direct 0 0 D 192.168.3.2
192.168.3.1/32 Direct 0 0 D 192.168.3.1
192.168.3.2/32 Direct 0 0 D 127.0.0.1
# Check the OSPF routing table of RouterC. You can find that three routes defined by the IP
prefix list named a2b are in the OSPF routing table. In the link state protocol, you can run the
filter-policy import command to filter the routes that join the local core routing table from
the
protocol routing table.

Routing Tables
Routing for Network

192.168.2.0/24 1 Stub 192.168.2.2 192.168.2.2 0.0.0.0
192.168.1.0/24 2 Stub 192.168.2.1 192.168.2.1 0.0.0.0
192.168.3.0/24 2 Stub 192.168.2.1 192.168.2.1 0.0.0.0
Routing for ASEs

Destination Cost Type Tag NextHop
AdvRouter
172.1.17.0/24
172.1.18.0/24
172.1.19.0/24
Total Nets: 6
Configuration Files
#
sysname RouterA
#
ip address 192.168.1.1 255.255.255.0
#
ospf 1
filter-policy ip-prefix a2b export static
import-route static
area 0.0.0.0
network 192.168.1.0 0.0.0.255
#
ip ip-prefix a2b index 10 permit 172.1.17.0 24
#
#
return
#
sysname RouterB
#
ip address 192.168.1.2 255.255.255.0
#
ip address 192.168.3.1 255.255.255.0
#
ip address 192.168.2.1 255.255.255.0
#
ospf 1
area 0.0.0.0
network 192.168.1.0 0.0.0.255
network 192.168.2.0 0.0.0.255
network 192.168.3.0 0.0.0.255
#
return
#
sysname RouterC
#
ip address 192.168.2.2 255.255.255.0
#
ospf 1
filter-policy ip-prefix in import
area 0.0.0.0
network 192.168.2.0 0.0.0.255
#
ip ip-prefix in index 10 permit 172.1.18.0 24
#
return
#
sysname RouterD
#
ip address 192.168.3.2 255.255.255.0
#
ospf 1
area 0.0.0.0
network 192.168.3.0 0.0.0.255
#
return

1210
6.3.2 Example for Applying a Routing Policy for Importing Routes
As shown in Figure 6-3-2, RouterB exchanges routing information with RouterA through OSPF and
with RouterC through IS-IS. Users want RouterB to import IS-IS routes into the OSPF network.
Users also want that the route to 172.17.1.0/24 on the OSPF network has a low preference and the
route to
172.17.2.0/24 has a tag, which makes it easy to reference by a routing policy.
Figure 6-3-2 Networking diagram for applying a routing policy for importing routes
1. Configure a routing policy on RouterB, set the cost of the route to 172.17.1.0/24 to 100, and
apply the routing policy when OSPF imports IS-IS routes. The routing policy allows the route
to
172.17.1.0/24 have a low preference.
2. Configure a routing policy on RouterB, set the tag of the route to 172.17.2.0/24 is 20, and
apply the routing policy when OSPF imports IS-IS routes. In this way, the tag of the route to
172.17.2.0/24 can take effect, which makes it easy to reference by a routing policy.
Procedure
1. Assign an IP address to each interface.
2. Configure IS-IS.
[RouterC] isis
[RouterC-GigabitEthernet4/0/0] isis enable
[RouterB] isis
[RouterB-GigabitEthernet2/0/0] isis enable
3. Configure OSPF and import routes.
# Configure RouterA and enable OSPF.
[RouterA] ospf
# Configure RouterB. Enable OSPF and import IS-IS routes.
[RouterB] ospf
[RouterB-ospf-1] import-route isis 1
# Check the OSPF routing table of RouterA. You can view the imported routes.

Routing Tables
Routing for Network
192.168.1.0/24 1 Stub 192.168.1.1 192.168.1.1 0.0.0.0
Routing for ASEs
AdvRouter
172.17.1.0/24 1 Type2 1 192.168.1.2 192.168.1.2
172.17.2.0/24 1 Type2 1 192.168.1.2 192.168.1.2
172.17.3.0/24 1 Type2 1 192.168.1.2 192.168.1.2
192.168.2.0/24 1 Type2 1 192.168.1.2 192.168.1.2
Total Nets: 5
4. Configure the filtering list.
# Configure ACL 2002 to match 172.17.2.0/24.
[RouterB] acl number 2002

[RouterB-acl-basic-2002] rule permit source 172.17.2.0 0.0.0.255
# Configure the IP prefix list named prefix-a to match 172.17.1.0/24.
[RouterB] ip ip-prefix prefix-a index 10 permit 172.17.1.0 24
5. Configure the Route-Policy.
[RouterB] route-policy isis2ospf permit node 10

[RouterB-route-policy] if-match ip-prefix prefix-a
[RouterB-route-policy] if-match acl 2002
[RouterB-route-policy] apply tag 20
6. Apply the Route-Policy when the route is imported.
# Configure RouterB and apply the Route-Policy as the route is imported.
[RouterB] ospf
[RouterB-ospf-1] import-route isis 1 route-policy isis2ospf
# Check the OSPF routing table of RouterA. You can view the cost of the route with the
destination address as 172.17.1.0/24 is 100. The tag of the route with the destination address
as
172.17.2.0/24 is 20. Other routing attributes do not change.

Routing Tables
Routing for Network
192.168.1.0/24 1 Stub 192.168.1.1 192.168.1.1 0.0.0.0
Routing for ASEs
AdvRouter
172.17.1.0/24 100 Type2 1 192.168.1.2 192.168.1.2
172.17.2.0/24 1 Type2 20 192.168.1.2 192.168.1.2
172.17.3.0/24 1 Type2 1 192.168.1.2 192.168.1.2
192.168.2.0/24 1 Type2 1 192.168.1.2 192.168.1.2
Total Nets: 5
Configuration Files
#
sysname RouterA
#
ip address 192.168.1.1 255.255.255.0
#
ospf 1
area 0.0.0.0
network 192.168.1.0 0.0.0.255
#
return
#
sysname RouterB
#
acl number 2002
rule 5 permit source 172.17.2.0 0.0.0.255
#
isis 1
is-level level-2
network-entity 10.0000.0000.0002.00
#
ip address 192.168.1.2 255.255.255.0
#
ip address 192.168.2.2 255.255.255.0
isis enable 1
#
ospf 1
import-route isis 1 route-policy isis2ospf
area 0.0.0.0
network 192.168.1.0 0.0.0.255
#
route-policy isis2ospf permit node 10
if-match ip-prefix prefix-a
apply cost 100
#
if-match acl 2002
apply tag 20
#
#
ip ip-prefix prefix-a index 10 permit 172.17.1.0 24
#
return
#
sysname RouterC
#
isis 1
is-level level-2
network-entity 10.0000.0000.0001.00
#
ip address 172.17.1.1 255.255.255.0
isis enable 1
#
ip address 172.17.2.1 255.255.255.0
isis enable 1
#
ip address 172.17.3.1 255.255.255.0
isis enable 1
#
ip address 192.168.2.1 255.255.255.0
isis enable 1
#
return
6.3.3 Example for Configuring Local PBR
As shown in Figure 6-3-3, RouterA and RouterB are connected by two links.
Users want locally generated packets with different lengths to be sent to different next hop addresses.
 Packets with 64 to 1400 bytes are sent to next hop address 192.168.1.2.
 Packets with 1401 to 1500 bytes are sent to next hop address 192.168.2.2.
 Packets with other lengths are routed based on destination addresses.
Figure 6-3-3 Networking diagram of configuring local PBR
1. Configure a matching rule of IP packet length on RouterA so that locally generated

packets with different lengths match different PBR nodes.
2. Configure actions of the local PBR on RouterA so that locally generated packets with
different lengths are sent to different next hop addresses.
3. Enable local PBR.
Procedure
1. Configure IP addresses for interfaces.
# Configure IP addresses for all interfaces of RouterA.
<Huawei> system-view
[Huawei] sysname RouterA
[RouterA-GigabitEthernet1/0/0] ip address 192.168.1.1 255.255.255.0
[RouterA] interface loopback 0
[RouterA-LoopBack0] ip address 10.1.1.1 255.255.255.0
[RouterA-LoopBack0] quit
# Configure IP addresses for all interfaces of RouterB.
[Huawei] sysname RouterB
[RouterB-GigabitEthernet1/0/0] ip address 192.168.1.2 255.255.255.0
[RouterB] interface loopback 0
[RouterB-LoopBack0] ip address 10.1.2.1 255.255.255.0
[RouterB-LoopBack0] quit
2. Configure static routes.
# Configure a static route on RouterA.
[RouterA] ip route-static 10.1.2.0 24 192.168.1.2

[RouterA] ip route-static 10.1.2.0 24 192.168.2.2
# Configure a static route on RouterB.

[RouterB] ip route-static 10.1.1.0 24 192.168.1.1
[RouterB] ip route-static 10.1.1.0 24 192.168.2.1
3. Configure a PBR route.
# Configure a PBR route named lab1.
[RouterA] policy-based-route lab1 permit node 10

[RouterA-policy-based-route-lab1-10] if-match packet-length 64 1400
[RouterA-policy-based-route-lab1-10] apply ip-address next-hop 192.168.1.2
[RouterA-policy-based-route-lab1-10] quit
[RouterA] policy-based-route lab1 permit node 20
[RouterA-policy-based-route-lab1-20] if-match packet-length 1401 1500
[RouterA-policy-based-route-lab1-20] apply ip-address next-hop 192.168.2.2
[RouterA-policy-based-route-lab1-20] quit
# Enable local PBR.
[RouterA] ip local policy-based-route lab1
4. Verify the configurations.
# Clear interface statistics on RouterB.
<RouterB> reset counters interface gigabitethernet 1/0/0

# View interface statistics on RouterB.
<RouterB> display interface gigabitethernet 1/0/0

GigabitEthernet1/0/0 current state : UP
Line protocol current state : UP
Last line protocol up time : 2012-07-30 11:23:24
Description:HUAWEI, AR Series, GigabitEthernet1/0/0 Interface
Route Port,The Maximum Transmit Unit is 1500
Internet Address is 192.168.1.2/24
IP Sending Frames' Format is PKTFMT_ETHNT_2, Hardware address is 0819-a6ce-7d4c
Last physical up time : 2012-07-30 11:23:24
Last physical down time : 2012-07-24 16:54:19
Current system time: 2012-07-30 14:57:28
Port Mode: COMMON COPPER Speed
: 1000, Loopback: NONE Duplex:
FULL, Negotiation: ENABLE Mdi
: AUTO
Last 300 seconds input rate 40 bits/sec, 0 packets/sec
Last 300 seconds output rate 0 bits/sec, 0 packets/sec
Input peak rate 7568 bits/sec,Record time: 2012-07-30 12:57:02
Output peak rate 1008 bits/sec,Record time: 2012-07-30 12:42:42
Input: 4 packets, 1543 bytes

Unicast:
Broadcast:
Discard:
CRC:
Jabbers:
Runts:
Symbols:
Frames:
Output: 0 packets, 0 bytes

Unicast:
Broadcast:
Discard:
Collisions:
Late Collisions:
Buffers Purged:
Input bandwidth utilization threshold : 100.00%

Output bandwidth utilization threshold: 100.00%
Input bandwidth utilization : 0.01%
Output bandwidth utilization : 0.00%
IP Sending Frames' Format is PKTFMT_ETHNT_2, Hardware address is 0819-a6ce-7d4d
: AUTO

Unicast:
Broadcast:
Discard:
CRC:
Jabbers:
Runts:
Symbols:
Frames:

Unicast:
Broadcast:
Discard:
Collisions: 0, ExcessiveCollisions: 0
Late Collisions:
Buffers Purged:

# On RouterA, ping the IP address of Loopback0 on RouterB and set the packet length to
80 bytes.
<RouterA> ping -s 80 10.1.2.1


1210

0.00% packet loss

: AUTO

Unicast:
Broadcast:
Discard:
CRC:
Jabbers:
Runts:
Symbols:
Frames: 0

Unicast:
Broadcast:
Discard:
Collisions:
Late Collisions:
Buffers Purged:

: AUTO

Unicast:
Broadcast:
Discard:
CRC:
Jabbers:
Runts:
Symbols:
Frames:

Unicast:
Broadcast:
Discard:
Collisions:
Late Collisions:
Buffers Purged:

Compare statistics about interfaces of RouterB before and after you run the ping -s 80
10.1.2.1 command on RouterA. You can find that GigabitEthernet 1/0/0 of RouterB sends
five packets, that is, GigabitEthernet 1/0/0 of RouterB sends five ICMP reply packets to
RouterA after receiving five ICMP requests from RouterA. RouterA determines that the next
hop address is 192.168.1.2 based on the PBR.
# Clear interface statistics on RouterB.


: AUTO

Unicast:
Broadcast:
Discard:
CRC:
Jabbers:
Runts:
Symbols:
Frames:

Unicast:
Broadcast:
Discard:
Collisions:
Late Collisions:
Buffers Purged:

: AUTO

Unicast:
Broadcast:
Discard:
CRC:
Jabbers:
Runts:
Symbols:
Frames:

Unicast:
Broadcast:
Discard:
Collisions:
Late Collisions:
Buffers Purged:

# On RouterA, ping the IP address of Loopback0 on RouterB and set the packet length to
1401 bytes.
<RouterA> ping -s 1401 10.1.2.1

ms

0.00% packet loss

: AUTO

Unicast:
Broadcast:
Discard:
CRC:
Jabbers:
Runts:
Symbols:
Frames:

Unicast:
Broadcast:
Discard:
Collisions:
Late Collisions:
Buffers Purged:

: AUTO

Unicast:
Broadcast:
Discard:
CRC:
Jabbers:
Runts:
Symbols:
Frames:

Unicast:
Broadcast:
Discard:
Collisions:
Late Collisions:
Buffers Purged:

Compare statistics about interfaces of RouterB before and after you run the ping -s 1401
10.1.2.1 command on RouterA. You can find that GigabitEthernet 2/0/0 of RouterB sends
five packets, that is, GigabitEthernet 2/0/0 of RouterB sends five ICMP reply packets to
RouterA after receiving ICMP requests from RouterA. RouterA determines that the next hop
address is
192.168.2.2 based on the PBR.
Configuration Files
#
sysname RouterA
#
ip address 192.168.1.1 255.255.255.0
#
ip address 192.168.2.1 255.255.255.0
#
interface LoopBack0
ip address 10.1.1.1 255.255.255.0
#
ip route-static 10.1.2.0 255.255.255.0 192.168.1.2
ip route-static 10.1.2.0 255.255.255.0 192.168.2.2
#
policy-based-route lab1 permit node 10
if-match packet-length 64 1400
apply ip-address next-hop 192.168.1.2
policy-based-route lab1 permit node 20
apply ip-address next-hop 192.168.2.2
#
ip local policy-based-route lab1
#
sysname RouterB
#
ip address 192.168.1.2 255.255.255.0
#
ip address 192.168.2.2 255.255.255.0
#
interface LoopBack0
ip address 10.1.2.1 255.255.255.0
#
ip route-static 10.1.1.0 255.255.255.0 192.168.1.1
ip route-static 10.1.1.0 255.255.255.0 192.168.2.1
6.3.4 Example for Configuring Interface PBR
As shown in Figure 6-3-4, two departments VLAN 10 and VLAN 20 connect to GE1/0/0 and
GE2/0/0 of RouterA. HOSTA at 192.168.1.2/24 and HOSTB at 192.168.1.3/24 belong to one
department and are located on network segment 192.168.1.0/24. HOSTC at 192.168.2.2/24 and
HOSTD at
192.168.2.3/24 belong to another department and are located on network segment 192.168.2.0/24.
RouterA can connect to the Internet through the link RouterA→RouterB→RouterD or
RouterA→RouterC→RouterD. The requirements are as follows:
 Packets from the two departments reach the Internet through the two links when the two
links are running properly.
 When a link is faulty, packets from the two departments are forwarded on the other link.
This prevents service interruption for a long time.
 When the link fault is rectified, packets reach the Internet through the two links.
Figure 6-3-4 Networking diagram of configuring interface PBR
RouterA
RouterB
RouterC
RouterD

1210
GE3/0/0 192.168.7.1/24
Association between redirection and an NQA test instance is used to implement PBR.
1. Configure IP addresses and routing protocols for interfaces so that users can access the
Internet through RouterA.
2. Configure an NQA test instance to detect whether the links RouterA→RouterB→RouterD and
RouterA→RouterC→RouterD are running properly.
3. Configure association between NQA and static routes so that traffic can be switched to
the other link when one link is faulty.
4. Configure traffic classifiers and configure matching rules based on the source IP address
of packets.
5. Configure traffic behaviors in which redirection is associated with an NQA test instance.
When the NQA test instance detects that the link RouterA→RouterB→RouterD is
running properly, packets matching the traffic classifier are redirected to 192.168.3.2/24.
When the NQA test instance detects that the link RouterA→RouterC→RouterD is
running properly, packets matching the traffic classifier are redirected to 192.168.4.2/24.
6. Configure traffic policies, bind the traffic classifier and traffic behavior to the traffic
policies, and apply the traffic policies to an interface to implement interface PBR.
Procedure
1. Configure devices to communicate with each other.
# Configure IP addresses for all interfaces of the Router. This example describes the
configuration on RouterA. Configurations of other device are similar to that of RouterA.
For details, see corresponding configuration files.
NOTE:
Configure SwitchA and SwitchB so that they can communicate with RouterA.
# Configure static routes.
[RouterA] ip route-static 192.168.7.0 255.255.255.0 192.168.3.2

[RouterB] ip route-static 192.168.7.0 255.255.255.0 192.168.5.1
[RouterC] ip route-static 192.168.7.0 255.255.255.0 192.168.6.1
[RouterD] ip route-static 192.168.1.0 255.255.255.0 192.168.5.2
2. Configure NQA test instances.
# Configure an NQA test instance on RouterA.
[RouterA] nqa test-instance admin vlan10

[RouterA-nqa-admin-vlan10] test-type icmp
[RouterA-nqa-admin-vlan10] destination-address ipv4 192.168.5.1
[RouterA-nqa-admin-vlan10] frequency 10
[RouterA-nqa-admin-vlan10] probe-count 2
[RouterA-nqa-admin-vlan10] start now
[RouterA-nqa-admin-vlan10] quit
# Configure a NQA test instance on RouterD.
[RouterD] nqa test-instance admin vlan10

[RouterD-nqa-admin-vlan10] test-type icmp
[RouterD-nqa-admin-vlan10] destination-address ipv4 192.168.3.1
[RouterD-nqa-admin-vlan10] frequency 10
[RouterD-nqa-admin-vlan10] probe-count 2
[RouterD-nqa-admin-vlan10] start now
[RouterD-nqa-admin-vlan10] quit
[RouterD] nqa test-instance admin vlan20
[RouterD-nqa-admin-vlan20] test-type icmp
[RouterD-nqa-admin-vlan20] destination-address ipv4 192.168.4.1
[RouterD-nqa-admin-vlan20] frequency 10
[RouterD-nqa-admin-vlan20] probe-count 2
[RouterD-nqa-admin-vlan20] start now
[RouterD-nqa-admin-vlan20] quit
3. Configure association between NQA and static routes.
# Configure association between NQA and static routes on RouterA.
[RouterA] ip route-static 192.168.7.1 255.255.255.0 192.168.3.2 track nqa admin

vlan10 [RouterA] ip route-static 192.168.7.1 255.255.255.0 192.168.4.2 track nqa admin
vlan20 [RouterA] quit
# Configure association between NQA and static routes on

RouterD.
[RouterD] ip route-static 192.168.1.0 255.255.255.0 192.168.5.2 track nqa admin vlan10

[RouterD] quit
4. Configure traffic classifiers.
# Create traffic classifiers vlan10 and vlan20 on RouterA to match packets with source
IP
addresses on network segments 192.168.1.0/24 and 192.168.2.0/24.
[RouterA] acl number 2000

[RouterA-acl-basic-2000] rule 10 permit source 192.168.1.0 0.0.0.255
[RouterA-acl-basic-2000] quit
[RouterA-acl-basic-2001] rule 20 permit source 192.168.2.0 0.0.0.255
[RouterA] traffic classifier vlan10
[RouterA-classifier-vlan10] if-match acl 2000
[RouterA-classifier-vlan10] quit
[RouterA-classifier-vlan20] if-match acl 2001
# Create traffic classifiers vlan10 and vlan20 on RouterD to match packets with destination IP
addresses on network segments 192.168.1.0/24 and 192.168.2.0/24.
[RouterD] acl number 3000

[RouterD-acl-adv-3000] rule 10 permit ip destination 192.168.1.0 0.0.0.255
[RouterD-acl-adv-3000] quit
[RouterD] acl number 3001
[RouterD-acl-adv-3001] rule 20 permit ip destination 192.168.2.0 0.0.0.255
[RouterD-acl-adv-3001] quit
[RouterD] traffic classifier vlan10
[RouterD-classifier-vlan10] if-match acl 3000
[RouterD-classifier-vlan10] quit
[RouterD] traffic classifier vlan20
[RouterD-classifier-vlan20] if-match acl 3001
[RouterD-classifier-vlan20] quit
5. Configure traffic behaviors.
# Create traffic behavior vlan10 on RouterA and associate the NQA test instance admin
vlan10 with redirection to the next hop 192.168.3.2/24. When the NQA test instance detects
that the link is running properly, redirection takes effect. When the NQA test instance
detects
a link fault, packets are forwarded along the original path.
[RouterA] traffic behavior vlan10

[RouterA-behavior-vlan10] redirect ip-nexthop 192.168.3.2 track nqa admin vlan10
[RouterA-behavior-vlan10] quit
# Create traffic behavior vlan20 on RouterA and associate the NQA test instance admin
detects

# Create traffic behavior vlan10 on RouterD and associate the NQA test instance admin
vlan10 with redirection to the next hop 192.168.5.2/24. When the NQA test instance
detects
that the link is running properly, redirection takes effect. When the NQA test instance detects
[RouterD] traffic behavior vlan10

[RouterD-behavior-vlan10] redirect ip-nexthop 192.168.5.2 track nqa admin vlan10
[RouterD-behavior-vlan10] quit
# Create traffic behavior vlan20 on RouterD and associate the NQA test instance admin
detects
[RouterD] traffic behavior vlan20

[RouterD-behavior-vlan20] redirect ip-nexthop 192.168.6.2 track nqa admin vlan20
[RouterD-behavior-vlan20] quit
6. Configure traffic policies and apply the traffic policies.
# Create traffic policies vlan10 and vlan20 on RouterA and bind the traffic classifier and
the traffic behavior to the traffic policy.
[RouterA] traffic policy vlan10

[RouterA-trafficpolicy-vlan10] classifier vlan10 behavior vlan10
[RouterA-trafficpolicy-vlan10] quit
# Apply the traffic policy vlan10 to GE1/0/0 in the inbound direction and the traffic policy
vlan20 to GE2/0/0 in the inbound direction.

[RouterA-GigabitEthernet1/0/0] traffic-policy vlan10 inbound
# Create traffic policy vlan10 on RouterD and bind the traffic classifier and the
traffic behavior to the traffic policy.
[RouterD] traffic policy vlan10

[RouterD-trafficpolicy-vlan10] classifier vlan10 behavior vlan10
[RouterD-trafficpolicy-vlan10] classifier vlan20 behavior vlan20
[RouterD-trafficpolicy-vlan10] quit
# Apply the traffic policy vlan10 to GE3/0/0 in the inbound

direction.
[RouterD-GigabitEthernet3/0/0] traffic-policy vlan10 inbound
# View the interface configuration on RouterA.

[RouterA-GigabitEthernet1/0/0] display this
#
ip address 192.168.1.1 255.255.255.0
traffic-policy vlan10 inbound
#
return
#
ip address 192.168.2.1 255.255.255.0
#
return
# View the traffic policy configuration.
[RouterA] display traffic policy user-defined
User Defined Traffic Policy Information:
Policy: vlan10
Classifier: vlan10
Operator: OR
Behavior: vlan10
Redirect:
Redirect ip-nexthop 192.168.3.2 track nqa admin vlan10
Policy: vlan20
Classifier: vlan20
Operator: OR
Behavior: vlan20
Redirect:
Configuration Files
#
sysname RouterA
#
acl number 2000
acl number 2001
#
traffic classifier vlan10 operator or
if-match acl 2000
if-match acl 2001
#
traffic behavior vlan10
redirect ip-nexthop 192.168.3.2 track nqa admin
vlan10 traffic behavior vlan20
redirect ip-nexthop 192.168.4.2 track nqa admin vlan20
#
traffic policy vlan10
classifier vlan10 behavior vlan10
#
ip address 192.168.1.1 255.255.255.0
#
ip address 192.168.2.1 255.255.255.0
#
ip address 192.168.3.1 255.255.255.0
#
ip address 192.168.4.1 255.255.255.0
#
ip route-static 192.168.5.0 255.255.255.0 192.168.3.2
ip route-static 192.168.6.0 255.255.255.0 192.168.4.2
ip route-static 192.168.7.0 255.255.255.0 192.168.3.2 track nqa admin vlan10
#
nqa test-instance admin vlan10
test-type icmp
destination-address ipv4 192.168.5.1
frequency 10
probe-count 2
start now
test-type icmp
frequency 10
probe-count 2
start now
#
return
#
sysname RouterB
#
ip address 192.168.3.2 255.255.255.0
ip address 192.168.5.2 255.255.255.0
#
ip route-static 192.168.1.0 255.255.255.0 192.168.3.1
ip route-static 192.168.2.0 255.255.255.0 192.168.3.1
ip route-static 192.168.7.0 255.255.255.0 192.168.5.1
#
return
#
sysname RouterC
#
ip address 192.168.4.2 255.255.255.0
ip address 192.168.6.2 255.255.255.0
#
ip route-static 192.168.1.0 255.255.255.0 192.168.4.1
ip route-static 192.168.2.0 255.255.255.0 192.168.4.1
ip route-static 192.168.7.0 255.255.255.0 192.168.6.1
#
return
#
sysname RouterD
#
acl number 3000
rule 10 permit ip destination 192.168.1.0 0.0.0.255
acl number 3001
rule 20 permit ip destination 192.168.2.0 0.0.0.255
#
if-match acl 3000
if-match acl 3001
#
#
#
ip address 192.168.5.1 255.255.255.0
ip address 192.168.6.1 255.255.255.0
ip address 192.168.7.1 255.255.255.0
#
ip route-static 192.168.3.0 255.255.255.0 192.168.5.2
ip route-static 192.168.4.0 255.255.255.0 192.168.6.2
#
return
Chapter 7 VLAN
7.1 Basic Concepts of VLAN
7.1.1 VLAN frame format
A conventional Ethernet frame is encapsulated with the Length/Type field for an upper -layer
protocol following the Destination address and Source address fields, as shown in Figure 7-1-1.
Figure 7-1-1 Conventional Ethernet frame format

IEEE 802.1Q is an Ethernet networking standard for a specified Ethernet frame format. It adds a 4-
byte field between the Source address and the Length/Type fields of the original frame, as shown in
Figure
7-1-2.
Figure 7-1-2 802.1Q frame format
Table 7-1-1 describes the fields contained in a 802.1Q tag.

1210
Table 7-1-1 Fields contained in an 802.1Q tag
Field Length
TPID 2 bytes
PRI 3 bits
CFI 1 bit
VID 12 bits
Each frame sent by an 802.1Q-capable switch carries a VLAN ID. In a VLAN, Ethernet frames are
classified into the following types:
 Tagged frames: frames with 4-byte 802.1Q tags.
 Untagged frames: frames without 4-byte 802.1Q tags.
7.1.2 Link Types
As shown in Figure 7-1-3, there are the following types of VLAN links:
 Access link: connects a host to a switch. Generally, a host does not know which VLAN it
belongs to, and host hardware cannot distinguish frames with VLAN tags. Therefore, hosts
send and receive only untagged frames.
 Trunk link: connects a switch to another switch or to a router. Data of different VLANs are
transmitted along a trunk link. The two ends of a trunk link must be able to distinguish
frames with VLAN tags. Therefore, only tagged frames are transmitted along trunk links.
Figure 7-1-3 Link types
NOTE:
 A host does not need to know the VLAN to which it belongs. It sends only untagged frames.
 After receiving an untagged frame from a host, a switching device determines the VLAN to
which the frame belongs. The determination is based on the configured VLAN assignment
method such as port information, and then the switching device processes the frame
accordingly.
 If the frame needs to be forwarded to another switching device, the frame must be
transparently transmitted along a trunk link. Frames transmitted along trunk links must carry
VLAN tags to allow other switching devices to properly forward the frame based on the
VLAN information.
 Before sending the frame to the destination host, the switching device connected to the
destination host removes the VLAN tag from the frame to ensure that the host receives
an untagged frame.
Generally, only tagged frames are transmitted on trunk links; only untagged frames are transmitted
on access links. In this manner, switching devices on the network can properly process VLAN
information and hosts are not concerned about VLAN information.
7.1.3 Port Types

After the 802.1Q defines VLAN frames, some ports on the device can identify VLAN frames, while
others cannot. According to whether VLAN frames can be identified, ports can be classified into
four types:
 Access port
As shown in Figure 7-1-3, the access port on a switch connects to the port on a host. The
access port can only connect to an access link. Only the VLAN whose ID is the same as the
default VLAN ID is allowed on the access port. Ethernet frames sent from the access port are
untagged frames.
 Trunk port
As shown in Figure 7-1-3, a trunk port on a switch connects to another switch. It can
only connect to a trunk link. Multiple tagged VLAN frames are allowed on the trunk
port.
 Hybrid port
As shown in Figure 7-1-4, a hybrid port on a switch can connect either to a host or to
another switch. A hybrid port can connect either to an access link or to a trunk link. The
hybrid port
allows multiple VLAN frames and removes tags from some VLAN frames on the outbound port.
Figure 7-1-4 Port types
 QinQ port
QinQ ports are enabled with the IEEE 802.1 QinQ protocol. A QinQ port adds a tag to a
single-tagged frame and supports a maximum of 4094 x 4094 VLAN tags (Different
products support different specifications), which meets the requirement for the VLAN
quantity.
Figure 7-1-5 shows the format of a QinQ frame. The outer tag usually called the public
tag carries the public VLAN ID. The inner tag usually called the private tag carries the
private VLAN ID.
Figure 7-1-5 Format of a QinQ frame

7.1.4 Default VLAN
Each port can be configured with a default VLAN with a port default VLAN ID (PVID). The
meaning of the default VLAN varies according to the port type.
7.2 VLAN Assignment
VLANs can be assigned based on ports, MAC addresses, IP subnets, network protocols, and
matching policies.
Table 7-2-1 describes differences between VLAN assignment modes.
Table 7-2-1 Differences between VLAN assignment modes
VLAN Assignment Mode
VLAN
assignment
based on port numbers
VLAN
assignment
based on MAC
addresses
VLAN
assignment
based on IP
subnets
VLAN
assignment
based on protocols

VLAN
assignment
based on policies (MAC addresses, IP addresses, and interfaces)

If the switch supports multiple VLAN assignment modes, the priority is of policy-based
VLAN assignment, MAC address-based VLAN assignment, IP subnet-based VLAN
assignment, protocol-based VLAN assignment, and port-based VLAN assignment in a
descending order.
 MAC address-based VLAN assignment and IP subnet-based VLAN assignment have the
same priority.
By default, MAC address-based VLAN assignment is preferentially adopted. Alternatively,

you can run commands to change priorities of these two VLAN assignment modes to select a
VLAN assignment mode.
 Port-based VLAN assignment has the lowest priority and is the most common VLAN
assignment mode.
 Policy-based VLAN assignment has the highest priority and is the least useful VLAN
assignment mode.
Figure 7-2-1 shows the process of classifying VLANs.

1210
Figure 7-2-1 Process of assigning VLANs
7.3 Principle of VLAN Communication
7.3.1 Basic Principle of VLAN Communication
To improve the efficiency in processing frames, frames within a switch all carry VLAN tags for
uniform processing. When a data frame reaches a port of the switch, if the frame carries no VLAN
tag
and the port is configured with a PVID, the frame is marked with the port's PVID. If the frame has
a VLAN tag, the switch will not mark a VLAN tag for the frame regardless of whether the port is
configured with a PVID.
The switch processes frames differently according to the type of port receiving the frames.
The following describes the frame processing according to the port type.
Table 7-3-1 Frame processing based on the port type
Port Type Untagged Frame Pro
Access port Accepts an untagged fram
Trunk port  Adds a tag with the de
 Adds a tag with the de
Hybrid port  Adds a tag with the de

Table 7-3-1 Frame processing based on the port type
Port Type Untagged Frame Pro
VLAN ID.
 Adds a tag with the de
QinQ port QinQ ports are enabled with
7.3.2 Intra-VLAN Communication
Sometimes VLAN hosts are connected to different switches, in which case the VLAN spans multiple
switches. Since ports between these switches must recognize and send packets belonging to the
VLAN, the trunk link technology becomes helpful in simplifying this solution.
The trunk link plays the following two roles:
 Trunk line
The trunk link transparently transmits VLAN packets between switches.
 Backbone line
The trunk link transmits packets belonging to multiple VLANs.
Figure 7-3-1 Trunk link communication
As shown in Figure 7-3-1, the trunk link between DeviceA and DeviceB must both support the
intra-communication of VLAN 2 and the intra-communication of VLAN 3. Therefore, the ports at both

1210
ends of the trunk link must be configured to belong to both VLANs. That is, Port2 on DeviceA and
Port1 on DeviceB must belong to both VLAN 2 and VLAN 3.
Host A sends a frame to Host B in the following process:
1. The frame is first sent to Port4 on DeviceA.
2. A tag is added to the frame on Port4. The VID field of the tag is set to 2, that is, the ID of the
VLAN to which Port4 belongs.
3. DeviceA queries its MAC address table for the MAC forwarding entry with the destination
MAC address of Host B.
 If this entry exists, DeviceA sends the frame to the outbound interface
Port2.
 If this entry does not exist, DeviceA sends the frame to all interfaces bound to VLAN
2 except for Port4.
4. Port2 sends the frame to DeviceB.
5. After receiving the frame, DeviceB queries its MAC address table for the MAC
forwarding entry with the destination MAC address of Host B.
 If this entry exists, DeviceB sends the frame to the outbound interface Port3.
 If this entry does not exist, DeviceB sends the frame to all interfaces bound to VLAN
2 except for Port1.
6. Port3 sends the frame to Host B.
The intra-communication of VLAN 3 is similar, and is not mentioned here.
7.3.3 Inter-VLAN Communication
After VLANs are configured, hosts in different VLANs cannot directly communicate with each
other. To implement communication between VLANs, use either of the following methods:
 Sub-interface
As shown in Figure 7-3-2, DeviceA is a Layer 3 switch supporting sub-interface, and DeviceB
is a Layer 2 switch. LANs are connected using the switched Ethernet interface on DeviceB and
the routed Ethernet interface on DeviceA. User hosts are assigned to VLAN2 and VLAN3. To
implement inter-VLAN communication, configure as follows:
 On DeviceA, create two sub-interfaces Port1.1 and Port2.1 on the Ethernet

interface connecting to DeviceB, and configure 802.1Q encapsulation on sub-
interfaces corresponding to VLAN2 and VLAN3.
 Configure IP addresses for sub-interfaces.
 Set types of Ethernet interfaces connecting DeviceB and DeviceA to Trunk or Hybrid,
to allow VLAN2 and VLAN3 frames.
 Set the default gateway address to the IP address of the sub-interface mapping the VLAN
to which the user host belongs.
Figure 7-3-2 Inter-VLAN communication using sub-interfaces

Host A communicates with Host C as follows:
 Host A checks the IP address of Host C and determines that Host C is in another VLAN.
 Host A sends an ARP request packet to DeviceA to request DeviceA's MAC address.
 After receiving the ARP request packet, DeviceA returns an ARP reply packet in
which the source MAC address is the MAC address of the sub-interface mapping
VLAN2.
 Host A obtains DeviceA's MAC address.
 Host A sends a packet whose destination MAC address is the MAC address of
the sub-interface and destination IP address is Host C's IP address to DeviceA.
 After receiving the packet, DeviceA forwards the packet and detects that the route to Host
C is a direct route. The packet is forwarded by the sub-interface mapping VLAN3.
 Functioning as the gateway of hosts in VLAN3, DeviceA broadcasts an ARP

packet requesting Host C's MAC address.
 After receiving the packet, Host C returns an ARP reply packet.
 After receiving the reply packet, DeviceA sends the packet from Host A to Host C.
All packets sent from Host A to Host C are sent to DeviceA first to implement Layer
3 forwarding.
 VLANIF interface
Layer 3 switching combines routing and switching techniques to implement routing on a switch,
improving the overall performance of the network. After sending the first data flow, a Layer 3
switch generates a mapping table on which it records the mapping between the MAC address
and the IP address for the data flow. If the switch needs to send the same data flow again, it
directly
sends the data flow at Layer 2 based on the mapping table. In this manner, network delays
caused by route selection are eliminated, and data forwarding efficiency is improved.
In order for new data flows to be correctly forwarded, the routing table must have the correct
routing entries. Therefore, VLANIF interfaces are used to configure routing protocols on Layer
3 switches to reach Layer 3 routes.
A VLANIF interface is a Layer 3 logical interface, which can be configured on either a Layer
3 switch or a router.
As shown in Figure 7-3-3, hosts connected to the switch are assigned to VLAN 2 and VLAN
3. To implement inter-VLAN communication, configure as follows:
 Create two VLANIF interfaces on the device, and configure IP addresses for them.
 Set the default gateway address to the IP address of the VLANIF interface mapping the
VLAN to which the user host belongs.
Figure 7-3-3 Inter-VLAN communication through VLANIF interfaces

Host A communicates with Host C as follows:
 Host A checks the IP address of Host C and determines that Host C is in another subnet.
 Host A sends an ARP request packet to Device to request Device's MAC address.
 After receiving the ARP request packet, Device returns an ARP reply packet in which
the source MAC address is the MAC address of VLANIF2.
 Host A obtains Device's MAC address.
 Host A sends a packet whose destination MAC address is the MAC address of the
VLANIF interface and destination IP address is Host C's IP address to
Device.
 After receiving the packet, Device forwards the packet and detects that the route to Host C
is a direct route. The packet is forwarded by VLANIF3.
 Functioning as the gateway of hosts in VLAN3, Device broadcasts an ARP

packet requesting Host C's MAC address.
 After receiving the packet, Host C returns an ARP reply packet.
 After receiving the reply packet, DeviceA sends the packet from Host A to Host C.
All packets sent from Host A to Host C are sent to Device first to implement Layer 3
forwarding.
 VLAN Switch
VLAN switch allows hosts in different VLANs to communicate with each other.
7.4 VLAN Aggregation
7.4.1 Background of VLAN Aggregation
VLAN is widely applied to switching networks because of its flexible control of broadcast domains
and convenient deployment. On a Layer-3 switch, the interconnection between the broadcast domains
is implemented using one VLAN to correspond to one Layer-3 logic interface. However, this can
waste
IP addresses. Figure 7-4-1 shows the VLAN division in the device.
Figure 7-4-1 Diagram of a common VLAN
Table 7-4-1 Example of Assigning Host Addresses on a common VLAN
VLAN Sub-network
2 1.1.1.0/28
3 1.1.1.16/29
4 1.1.1.24/30
As show in Table 7-4-1, VLAN 2 requires 10 host addresses. The sub network 1.1.1.0/28 with the
mask length as 28 bits is assigned for VLAN 2. 1.1.1.0 is the address of the sub network, and
1.1.1.15
is the directed broadcast address. These two addresses cannot serve as the host address. In addition,
as the default address of the network gateway of the sub network, 1.1.1.1 cannot be used as the host
address. The other 13 addresses ranging from 1.1.1.2 to 1.1.1.14 can be used by the hosts. In this
way, although VLAN 2 needs only ten addresses, 13 addresses need to be assigned for it according
to the division of the sub network.
VLAN 3 requires five host addresses. The sub network 1.1.1.16/29 with the mask length as 29 bits
needs to be assigned for VLAN 3. VLAN 4 requires only one address. The sub network
1.1.1.24/30 with the mask length as 30 bits needs to be assigned for VLAN 4.
In above, 16 (10+5+1) addresses are needed for all the preceding VLANs. However, 28 (16+8+4)
addresses are needed according to the common VLAN addressing mode even if the optimal scheme
is used. Nearly half of the addresses is wasted. In addition, if VLAN 2 is accessed to three hosts
instead of ten hosts later, the extra addresses will not be used by other VLANs and will be wasted.
This division is inconvenient for the later network upgrade and expansion. Assume that two more
hosts need to be added to VLAN 4 and VLAN 4 does not want to change the assigned IP addresses,
and the addresses after 1.1.1.24 has been assigned to others, a new sub network with the mask length
as 29 bits and a new VLAN need to be assigned for the new customers of VLAN 4. Therefore, the
customers of VLAN 4 have only three hosts, but the customers are assigned to two sub networks and
are not in the same VLAN. As a result, this is inconvenient for network management.
In above, many IP addresses are used as the addresses of sub networks, directional broadcast
addresses of sub networks, and default addresses of network gateways of sub networks. These IP
addresses cannot be used as the host addresses in the VLAN. The limit on address assignation reduces
the addressing flexibility, so that many idle addresses are wasted. To solve this problem, VLAN
aggregation is used.
7.4.2 Principle
The VLAN aggregation technology, also known as the super-VLAN, provides a mechanism that
partitions the broadcast domain using multiple VLANs in a physical network so that differen t
VLANs can belong to the same subnet. In VLAN aggregation, two concepts are involved, namely,
super-VLAN and sub-VLAN.
 Super-VLAN: It is different from the common VLAN. In the super-VLAN, only Layer 3
interfaces are created and physical ports are not contained. The super-VLAN can be viewed as
a logical Layer 3 concept. It is a collection of many sub-VLANs.
 Sub-VLAN: It is used to isolate broadcast domains. In the sub-VLAN, only physical ports
are contained and Layer 3 VLAN interfaces cannot be created. The Layer 3 switching with
the external network is implemented through the Layer 3 interface of the super-VLAN.
A super-VLAN can contain one or more sub-VLANs retaining different broadcast domains. The
sub-VLAN does not occupy an independent subnet segment. In the same super-VLAN, IP addresses
of hosts belong to the subnet segment of the super-VLAN, regardless of the mapping between hosts
and sub-VLANs.
The same Layer 3 interface is shared by sub-VLANs. Some subnet IDs, default gateway addresses of
the subnets, and directed broadcast addresses of the subnets are saved and different broadcast
domains can use the addresses in the same subnet segment. As a result, subnet differences are
eliminated, addressing becomes flexible and idle addresses are reduced.
Take the Table 7-4-1 to explain the implementation theory. Suppose that user demands are
unchanged. In VLAN 2, 10 host addresses are demanded; in VLAN 3, 5 host addresses are demanded;
in VLAN 4,
1 host address is demanded.
According to the implementation of VLAN aggregation, create VLAN 10 and configure VLAN 10 as
a super-VLAN. Then assign a subnet address 1.1.1.0/24 with the mask length being 24 to VLAN 10;
1.1.1.0 is the subnet ID and 1.1.1.1 is the gateway address of the subnet, as shown in Figure 7-4-
2. Address assignments of sub-VLANs (VLAN 2, VLAN 3, and VLAN 4) are shown in Table 7-
4-2.
Figure 7-4-2 Schematic diagram of VLAN aggregation
Table 7-4-2 Example for assigning Host addresses in VLAN aggregation mode
VLAN Subnet
2 1.1.1.0/24
4
In VLAN aggregation implementation, sub-VLANs are not divided according to the previous
subnet border. Instead, their addresses are flexibly assigned in the subnet corresponding to the
super-VLAN according to the required host number.
As the Table 7-4-2 shows that VLAN 2, VLAN 3, and VLAN 4 share a subnet (1.1.1.0/24), a
default gateway address of the subnet (1.1.1.1), and a directed broadcast address of the subnet
(1.1.1.255). In this manner, the subnet ID (1.1.1.16, 1.1.1.24), the default gateway of the subnet
(1.1.1.17, 1.1.1.25), and the directed broadcast address of the subnet (1.1.1.5, 1.1.1.23, and 1.1.1.24)
can be used as IP addresses of hosts.
Totally, 16 addresses (10 + 5 + 1 = 16) are required for the three VLANs. In practice, in this subnet, a
total of 16 addresses are assigned to the three VLANs (1.1.1.2 to 1.1.1.17). A total of 19 IP addresses
are used, that is, the 16 host addresses together with the subnet ID (1.1.1.0), the default gateway of
the subnet (1.1.1.1), and the directed broadcast address of the subnet (1.1.1.255). In the network
segment,
236 addresses (255 - 19 = 236) are available, which can be used by any host in the sub-
VLAN.
7.4.3 Communications between VLANs
 Introduction
VLAN aggregation ensures that different VLANs use the IP addresses in the same subnet
segment. This, however, leads to the problem of Layer 3 forwarding between sub-
VLANs.
In common VLAN mode, the hosts of different VLANs can communicate with each other
based on the Layer 3 forwarding through their respective gateways. In VLAN aggregation
mode, the hosts in a super-VLAN uses the IP addresses in the same network segment and share
the same gateway address. The hosts in different sub-VLANs belong to the same subnet.
Therefore, they communicate with each other based on the Layer 2 forwarding, rather than the
Layer 3
forwarding through a gateway. In practice, hosts in different sub-VLANs are separated in Layer
2. As a result, sub-VLANs fail to communicate with each other.
To solve the preceding problem, you can use ARP proxy.
 Layer 3 Communications between Different Sub-VLANs
As shown in Figure 7-4-3, the super-VLAN, namely, VLAN 10, contains the sub-
VLANs, namely, VLAN 2 and VLAN 3.
Figure 7-4-3 Networking diagram of Layer 3 communications between different sub-
VLANs based on ARP proxy
Suppose that the ARP table of Host A has no corresponding entry of Host B, and the gateway
is enabled with the ARP proxy between sub-VLANs. Then the communication process
between Host A in VLAN 2 and Host B in VLAN 3 is shown as below:
1. After comparing the IP address of Host B 1.1.1.3 with its IP address, Host A finds that
both IP addresses are in the same network segment 1.1.1.0/24, and its ARP table has
no corresponding entry of Host B.
2. Host A initiates an ARP broadcast to request for the MAC address of Host B.
3. Host B is not in the broadcast domain of VLAN 2, and cannot receive the ARP request.
4. The gateway is enabled with the ARP proxy between sub-VLANs. Therefore, after
receiving the ARP request from Host A, the gateway finds that the IP address of Host
B
1.1.1.3 is the IP address of a directly-connected interface. Then the gateway initiates
an ARP broadcast to all the other sub-VLAN interfaces to request for the MAC
address of Host B.
5. After receiving the ARP request, Host B offers an ARP response.
6. After receiving the ARP response from Host B, the gateway replies its MAC address to
Host A.
7. The ARP tables in both the gateway and Host A have the corresponding entries of Host B.
8. To send packets to Host B, Host A first sends packets to the gateway, and then
the gateway performs the Layer 3 forwarding.
The process that Host B sends packets to Host A is just the same, and is not mentioned here.
 Layer 2 Communications between a Sub-VLAN and an External Network

As shown in Figure 7-4-4, in the Layer 2 VLAN communications based on ports, the received
or sent frames are not tagged with the super-VLAN ID.
Figure 7-4-4 Networking diagram of Layer 2 communications between a sub-VLAN and

an external network
The frame that accesses Switch 1 through Port1 on Host A is tagged with the ID of VLAN 2. The
VLAN ID, however, is not changed to the ID of VLAN 10 on Switch 1 even if VLAN 2 is
the sub-VLAN of VLAN 10. After passing through Port3, which is the trunk type, this frame
still carries the ID of VLAN 2.
That is to say, Switch 1 itself does not send the frames of VLAN 10. In addition, switch 1
discards the frames of VLAN 10 that are sent to Switch 1 by other devices because switch 1
has no corresponding physical port for VLAN 10.
A super-VLAN has no physical port. This limitation is obligatory, as shown below:
 If you configure the super-VLAN and then the trunk interface, the frames of a
super-VLAN are filtered automatically according to the VLAN range set on the
trunk interface.
As shown in Figure 7-4-4, no frame of the super-VLAN 10 passes through Port3 on

Switch 1, even though the interface allows frames from all VLANs to pass through.
 If you finish configuring the trunk interface and allow all VLANs to pass through, you
still cannot configure the super-VLAN on Switch 1. The root cause is that any VLAN with
physical ports cannot be configured as the super-VLAN, and the trunk interface allows
only the frames tagged with VLAN IDs to pass through. Therefore, no VLAN can
be configured as a super-VLAN.
As for Switch 1, the valid VLANs are just VLAN 2 and VLAN 3, and all frames are forwarded
in these VLANs.
 Layer 3 Communications between a Sub-VLAN and an External Network
Figure 7-4-5 Networking diagram of Layer 3 communications between a sub-VLAN and

an external network
As shown in Figure 7-4-5, Switch 1 is configured with super-VLAN 4, sub-VLAN 2, sub-VLAN
3, and a common VLAN 10. Switch 2 is configured with two common VLANs, namely,
VLAN
10 and VLAN 20. Suppose that Switch 1 is configured with the route to the network
segment
1.1.3.0/24, and Switch 2 is configured with the route to the network segment 1.1.1.0/24.
Then
Host A in sub-VLAN 2 that belongs to the super-VLAN 4 needs to access Host C in Switch 2.
1. After comparing the IP address of Host C 1.1.3.2 with its IP address, Host A finds that
two
IP addresses are not in the same network segment 1.1.1.0/24.
2. Host A initiates an ARP broadcast to its gateway to request for the MAC address of
the gateway.
3. After receiving the ARP request, Switch 1 identifies the correlation between
the sub-VLAN and the super-VLAN, and offers an ARP response to Host A
through
sub-VLAN 2. The source MAC address in the ARP response packet is the MAC
address of VLANIF4 for super-VLAN 4.
4. Host A learns the MAC address of the gateway.

1210
5. Host A sends the packet to the gateway, with the destination MAC address as the
MAC
address of VLANIF4 for super-VLAN 4, and the destination IP address as 1.1.3.2.

1210
6. After receiving the packet, Switch 1 performs the Layer 3 forwarding and sends
the packet to Switch 2, with the next hop address as 1.1.2.2, the outgoing interface
as VLANIF10.
the packet to Host C through the directly-connected interface VLANIF20.
8. The response packet from Host C reaches Switch 1 after the Layer 3 forwarding on
Switch 2.
the packet to Host A through the super-VLAN.
7.5 MUX VLAN
7.5.1 Background
Multiplex VLAN (MUX VLAN) controls network resources by VLAN.
For example, on an enterprise network, enterprise employees and enterprise customers can access the
enterprise server. The enterprise requires that enterprise employees are able to communicate with
each other whereas enterprise customers are not able to communicate with each other.
To allow all users to access the enterprise server, configure communication between VLANs. If there
are a large number of users in an enterprise, assign VLANs to users that cannot communicate with
each other. This wastes VLAN IDs and requires great workload on network configuration and
maintenance.
The Layer 2 traffic isolation mechanism provided by MUX VLAN meets the preceding requirement.
7.5.2 Basic Concepts
As shown in Table 7-5-1, a MUX VLAN is classified into principal VLANs and subordinate VLANs;
a subordinate VLAN is classified into separate VLANs and group VLANs.
Table 7-5-1 Classification of a MUX VLAN
MUX VLAN
Principal VLAN
Subordinate
VLAN
Table 7-5-1 Classification of a MUX VLAN
MUX VLAN
7.5.3 Principle of Communication in MUX VLAN
As shown in Figure 7-5-1, the principal port connects to the enterprise server; separate ports connect
to enterprise customers; group ports connect to enterprise employees. In this manner, enterprise
customers and enterprise employees can access the enterprise server, enterprise employees can
communicate with each other, enterprise customers cannot communicate with each other, and
enterprise customers and enterprise employees cannot communicate with each other.
Figure 7-5-1 Application scenario of MUX VLAN
7.6 Examples for Configuring of VLAN
7.6.1 Example for Configuring Interface-based VLAN Assignment
An enterprise requires departments in charge of the same service to communicate with each other
while isolating departments in charge of different services.
As shown in Figure 7-6-1, an enterprise has four departments. Department 1 is connected to

RouterA, which is connected to Ethernet 2/0/1 of the Router. Department 2 is connected to RouterB,
which is connected to Ethernet 2/0/2 of the Router. Department 3 is connected to RouterC, which is
connected to Ethernet 2/0/3 of the Router. Department 4 is connected to RouterD, which is connected
to Ethernet
2/0/4 of the Router. The requirements are as follows:
 Department 1 and Department 2 in VLAN 2 are isolated from Department 3 and Department 4 in
VLAN 3.
 Department 1 and Department 2 in VLAN 2 can communicate with each other.
 Department 3 and Department 4 in VLAN 3 can communicate with each other.
Figure 7-6-1 Network diagram of interface-based VLAN assignment
1. Create VLANs.
2. Add interfaces to the VLAN.
Procedure
1. Configure the Router.
# Create VLAN 2.
[Huawei] vlan 2
[Huawei-vlan2] quit
# Set the link type of Ethernet 2/0/1 to trunk and add Ethernet 2/0/1 to VLAN 2.
[Huawei] interface ethernet 2/0/1

[Huawei-Ethernet2/0/1] port link-type trunk
[Huawei-Ethernet2/0/1] port trunk allow-pass vlan 2
[Huawei-Ethernet2/0/1] quit
[Huawei]interface ethernet 2/0/2

# Create VLAN 3.
[Huawei] vlan 3
[Huawei-vlan3] quit


Ping any host in VLAN 3 from a host in VLAN 2. The ping operation fails, indicating that
Department 1 and Department 2 are isolated from Department 3 and Department 4.
Ping any host in Department 2 from a host in Department 1. The ping operation is
successful, indicating that Department 1 and Department 2 can communicate with each
other.
Ping any host in Department 4 from a host in Department 3. The ping operation is
successful, indicating that Department 3 and Department 4 can communicate with each
other.
Configuration Files
Configuration file of the Router
#
vlan batch 2 to 3
#
interface Ethernet2/0/1
port link-type trunk
port trunk allow-pass vlan 2
#
#
#
#
return
7.6.2 Example for Implementing Inter-VLAN Communication Using VLANIF Interfaces
Users in an enterprise use different services and locate at different network segments. Users who
use the same service belong to different VLANs and they want to communicate with each other.
As shown in Figure 7-6-2, User 1 and User 2 use the same service but belong to different VLANs
and locate at different network segments. User 1 wants to communicate with User 2.
Figure 7-6-2 Networking diagram for implementing inter-VLAN communication using VLANIF
interfaces
1. Create VLANs on the switches for different users.
2. Add interfaces to VLANs so that packets of the VLANs can pass through the interfaces.
3. Create VLANIF interfaces and configure IP addresses for the VLANIF interfaces to implement
Layer 3 communication.
NOTE:
To implement communication between VLANs, hosts in each VLAN must use the IP address of
the corresponding VLANIF interface as the gateway address.
Procedure
1. Configure the Switch.
# Create VLANs.
<HUAWEI> system-view
[HUAWEI] vlan batch 10 20
# Add interfaces to VLANs.
[HUAWEI] interface gigabitethernet 0/0/1

[HUAWEI-GigabitEthernet0/0/1] port link-type access
[HUAWEI-GigabitEthernet0/0/1] port default vlan 10
[HUAWEI-GigabitEthernet0/0/1] quit
# Assign IP addresses to the VLANIF interfaces.
[HUAWEI] interface vlanif 10

[HUAWEI-Vlanif10] ip address 10.10.10.2 24
[HUAWEI-Vlanif10] quit
Configure the IP address 10.10.10.3/24 on user 1's host, configure the VLANIF 10 interface IP
address 10.10.10.2/24 as the gateway address.
Configure the IP address 20.20.20.3/24 on user 1's host, configure the VLANIF 10 interface IP
address 20.20.20.2/24 as the gateway address.
After the preceding configurations are complete, User 1 in VLAN 10 and User 2 in VLAN
20 can communicate.
Configuration Files
Configuration file of the Switch
#
sysname HUAWEI
#
vlan batch 10 20
#
interface Vlanif10
ip address 10.10.10.2 255.255.255.0
#
interface Vlanif20
ip address 20.20.20.2 255.255.255.0
#
port link-type access
port default vlan 10
#
#
return
7.6.3 Example for Configuring VLAN Aggregation
Multiple departments in an enterprise locate at the same network segment. To improve the
service security, assign departments to different VLANs. Some departments need to
communicate.
As shown in Figure 7-6-3, departments in VLAN 2 and VLAN 3 want to communicate with
each other.
You can configure VLAN aggregation on the switch to isolate VLAN 2 from VLAN 3 at Layer 2 and
allow them to communicate at Layer 3. VLAN 2 and VLAN 3 use the same subnet segment, saving
IP addresses.
NOTE:
The S2750, S5700LI and S5700S-LI do not support VLAN aggregation.

Figure 7-6-3 Networking diagram for configuring VLAN aggregation
1. Add interfaces of the Switch to sub-VLANs to isolate sub-VLANs at Layer 2.
2. Add the sub-VLANs to a super-VLAN.
3. Configure the IP address for the VLANIF interface.
4. Configure proxy ARP for the super-VLAN to allow sub-VLANs to communicate at Layer 3.
Procedure
1. Set the interface type.
# Configure GE 0/0/1 as an access interface.
Configurations of GE0/0/2, GE0/0/3, and GE0/0/4 are the same as that of GE0/0/1.
2. Create VLAN 2 and add GE0/0/1 and GE0/0/2 to VLAN 2.
[HUAWEI] vlan 2
[HUAWEI-vlan2] port gigabitethernet 0/0/1 0/0/2
[HUAWEI-vlan2] quit
3. Create VLAN 3 and add GE0/0/3 and GE0/0/4 to VLAN 3.
[HUAWEI] vlan 3
[HUAWEI-vlan3] port gigabitethernet 0/0/3 0/0/4
[HUAWEI-vlan3] quit
4. Configure VLAN 4.
# Configure the super-VLAN.
[HUAWEI] vlan 4
[HUAWEI-vlan4] aggregate-vlan
[HUAWEI-vlan4] access-vlan 2 to 3
[HUAWEI-vlan4] quit
# Configure the VLANIF interface.

[HUAWEI-Vlanif4] ip address 100.1.1.12 255.255.255.0
5. Configure the PCs.
Configure an IP address for each PC. Ensure that the PC IP addresses are in the same
network segment as VLAN 4.
When the configuration is complete, the PCs and the Switch can ping each other, but the PCs
in VLAN 2 and the PCs in VLAN 3 cannot ping each other. You need to configure proxy ARP
on the switch.
6. Configure proxy ARP.
7. [HUAWEI] interface vlanif 4

8. [HUAWEI-Vlanif4] arp-proxy inter-sub-vlan-proxy enable
When the configuration is complete, the PCs in VLAN 2 and VLAN 3 can ping each other.
Configuration Files
#
sysname HUAWEI
#
vlan batch 2 to 4
#
vlan 4
aggregate-vlan
access-vlan 2 to 3
#
interface Vlanif4
ip address 100.1.1.12 255.255.255.0
arp-proxy inter-sub-vlan-proxy enable
#
port default vlan 2
#
port default vlan 2
#
port default vlan 3
#
port default vlan 3
#
return
7.6.4 Example for Configuring MUX VLAN (Access Devices)
On an enterprise network, all users can access the enterprise server. Some users need to
communicate with each other, whereas some users must be isolated each other.
As shown in Figure 7-6-4, MUX VLAN can be configured on the Switch to meet the enterprise's
requirements using fewer VLAN IDs. In addition, MUX VLAN reduces the configuration workload
of the network administrator, and facilitates network maintenance.

1210
Figure 7-6-4 MUX VLAN configuration
1. Configure the principal VLAN.
2. Configure the group VLAN.
3. Configure the separate VLAN.
4. Add interfaces to the VLANs and enable the MUX VLAN function.
Procedure
1. Configure the MUX VLAN.
# Create VLAN 2, VLAN 3, and VLAN 4.
[HUAWEI] vlan batch 2 3 4
# Configure the Group VLAN and Separate VLAN in the MUX VLAN.
[HUAWEI] vlan 2
[HUAWEI-vlan2] mux-vlan
[HUAWEI-vlan2] subordinate group 3
[HUAWEI-vlan2] subordinate separate 4
[HUAWEI-vlan2] quit
# Add interfaces to the VLANs and enable the MUX VLAN function on the interfaces.

[HUAWEI-GigabitEthernet0/0/1] port mux-vlan enable vlan 2
[HUAWEI-GigabitEthernet0/0/2] port mux-vlan enable vlan
3 [HUAWEI-GigabitEthernet0/0/2] quit
 Server can ping Hosts B to E. Hosts B to E can also ping Server.
 Host B and Host C can ping each other.
 Host D and Host E cannot ping each other.
 Host B and Host C cannot ping Host D or host E. Host D and Host E cannot ping Host B
or Host C.
Configuration Files
#
sysname HUAWEI
#
vlan batch 2 to 4
#
vlan 2
mux-vlan
subordinate separate 4
subordinate group 3
#
port default vlan 2
port mux-vlan enable vlan 2
#
port default vlan 3
#
port default vlan 3
#
port default vlan 4
#
port default vlan 4
#
return
7.6.5 Example for Configuring MUX VLAN (Aggregate Devices)
In the enterprise network, every employees need to access servers. But to the enterprise, some of
the employees are allowed to communicate with each other, whereas some of the employees are
not.
As shown in Figure 7-6-5, Switch1 is located at aggregate layer, works as gateway for access
terminals. Switch2, Switch3, Switch4, Switch5 and Switch6 are access layer devices. At this point, it
can apply MUX VLAN on Switch1. MUX VLAN not only can realize the needs of enterprise, can
solve the lack
of VLAN ID, but also can simplify maintenance for administrator.
Figure 7-6-5 MUX VLAN configuration
1. Configure the principal VLAN, configure the VLANIF interface and apply ip address
to gateway address for hosts and servers.
2. Configure the group VLAN.
3. Configure the separate VLAN.
4. Add interfaces to the VLANs and enable the MUX VLAN function.
5. Configure interfaces of access devices and add interfaces to VLAN.
Procedure
1. Configure the Switch1.
# Create VLAN2, VLAN3 and VLAN4, configure the VLANIF interface of VLAN2 and
apply ip address to gateway address for hosts and servers.
[HUAWEI] vlan batch 2 3 4
# Configure the Group VLAN and Separate VLAN in the MUX VLAN.
[HUAWEI] vlan 2
[HUAWEI-vlan2] mux-vlan
[HUAWEI-vlan2] subordinate group 3
[HUAWEI-vlan2] subordinate separate 4
[HUAWEI-vlan2] quit
# Add interfaces to the VLANs and enable the MUX VLAN function on the interfaces.

2. Configure interfaces of access devices and add interfaces to VLAN, and is not mentioned here.
 Server can ping Hosts B to E. Hosts B to E can also ping Server.
 Host B and Host C can ping each other.
 Host D and Host E cannot ping each other.

 Host B and Host C cannot ping Host D or host E. Host D and Host E cannot pin g Host B
or Host C.
Configuration Files
Configuration file of the Switch1
#
sysname HUAWEI
#
vlan batch 2 to 4
#
vlan 2
mux-vlan
subordinate separate 4
subordinate group 3
#
interface Vlanif2
ip address 192.168.100.100 255.255.255.0
#
#
#
#
#
#
return
Chapter 8 Layer 2 Ethernet Technologies
8.1 ARP
As the basis of Ethernet network communication, ARP maps IP addresses to MAC

addresses.
On a local area network (LAN), a host or a network device must learn the IP address of the
destination host or device before sending data to it. Additionally, the host or network device
must learn the physical address of the destination host or device because IP packets must be
encapsulated into frames for transmission over a physical network. Therefore, the mapping from an
IP address into a physical address is required. ARP is used to map IP addresses into physical
addresses.
8.1.2 ARP Feature
ARP can be a dynamic ARP or a static ARP. ARP provides some extended functions, such as
proxy
ARP, ARP-Ping, ARP EAI and ARP forwarding after port
isolated.
Comparison between dynamic ARP and static

ARP
ARP entries are classified into static and dynamic ARP

entries.
Table 8-1-1 Comparison between dynamic ARP and static ARP
Item Concept
Dynamic ARP Dynamic ARP entr

generated and main
automatically usin
ARP protocol
Table 8-1-1 Comparison between dynamic ARP and static ARP
Item Conc
Static ARP Static ARP
Mappings between IP They cannot be aged and  Direct the packets whose
addresses and MAC overridden by dynamic ARP
destination IP addresses are not
addresses are fixed and entries.
cannot be changed on NOTE: on the local network segment to
hosts or routers. Static ARP entries improve a gateway on the local network
communication security. segment so that the packets can
However, a large number of
ARP entries increase be forwarded by the gateway.
configuration and  Bind destination IP addresses of
maintenance costs. illegal packets to a nonexistent
MAC address so that illegal
packets are filtered out.
Static ARP entries can be configured on

important network devices such as
servers to specify member devices that
they can communicate with. In this way,
mappings between IP addresses and
MAC addresses of these member devices
cannot be modified by forged ARP
packets and illegal ARP replies can be
prevented. This protects servers against
network attacks.
8.1.3 ARP Extended Functions
ARP provides extended functions in the following Table 8-1-2.

Table 8-1-2 ARP extended functions and their usage scenarios
Function Concept Usage Scenario

Table 8-1-2 ARP extended functions and their usage scenarios
Function Concept Usage Scenario

Proxy ARP The router can function as a proxy Proxy ARP is classified into the following three
of the destination host to reply an types:
ARP
Request message.
1. Routed Proxy ARP: Routed Proxy ARP
enables network devices on the same
network segment but on different
physical networks to communicate.
2. Intra-VLAN Proxy ARP: Intra-VLAN Proxy
ARP enables isolated network devices in a
VLAN to communicate.
3. Inter-VLAN Proxy ARP: Inter-VLAN Proxy
ARP enables network devices in different
VLANs or network devices in different
sub-VLANs but on the same network
segment to communicate.
8.2 MAC Address Table
Each device maintains a MAC address table. A MAC address table records the MAC address,
VLAN ID and outbound interfaces learned from other devices. When forwarding a data frame, the
device searches the MAC table for the outbound interface according to the destination MAC
address and VLAN ID in the frame. This helps the device reduce broadcasting.
Packet Forwarding Based on the MAC Address

Table
The device forwards packets based on the MAC address table in either of the following
modes:
 Unicast mode: If the destination MAC address of a packet can be found in the MAC address
table, the device forwards the packet through the outbound interface specified in the
matching entry.
 Broadcast mode: If a packet is a broadcast or multicast packet or its destination MAC address
cannot be found in the MAC address table, the device broadcasts the packet to all
the interfaces in the VLAN except the inbound interface.
Categories of MAC Address Entries
The MAC address entry can be classified into the dynamic entry, the static entry and the
blackhole entry.
 The dynamic entry is created by learning the source MAC address. It has aging time.
 The static entry is set by users and is delivered to each SIC. It does not age.
 The blackhole entry is used to discard the frame with the specified source MAC address or
destination MAC address. Users manually set the blackhole entries and send them to each
SIC. Blackhole entries have no aging time.
The dynamic entry will be lost after the system is reset or the interface board is hot swapped or
reset. The static entry and the blackhole entry, however, will not be lost.
Generation of a MAC address entry
MAC address entries are generated automatically or configured manually.
 Automatically Generated MAC Address Entries
MAC address entries are learned by the system automatically. For example, RouterA and
RouterB are connected. When RouterB sends a frame to RouterA, RouterA obtains the
source MAC address (the MAC address of RouterB) from the frame and adds the source
MAC address and the interface number to the MAC address table. When RouterA receives a
frame sent to RouterB again, RouterA can search the MAC address table to find the correct
outbound interface.
The entries in the MAC table will not be valid all the time. Each entry has its own lifetime.
If the entry has not been refreshed at the expiration of its lifetime, the device will delete that
entry from the MAC table. That lifetime is called aging time. If the entry is refreshed before
its lifetime expires, the device resets the aging time for it.
 Manually Configured MAC Address Entries
When creating MAC address entries by itself, the device cannot identify whether the
packets are from the legal users or the hackers. This threatens the network safety.
Hackers can fake the source MAC address in attack packets. The packet with a forged
address enters the device from the other port. Then the device learns a fault MAC table
entry. That is why the packets sent to the legal users are forwarded to the hackers.
For security, the network administrator can add static entries to the MAC table manually
to bind the user's device and the port of the device. In this way, the device can stop the
illegal users from stealing data.

1210
By configuring blackhole MAC address entries, you can configure the specified user
traffic not to pass through a switch to prevent attacks from unauthorized users.
The priority of MAC entries set up by users is higher than that generated by the device itself.
Aging Time of MAC Addresses
To adapt to the changes of networks, the MAC table needs to be updated constantly. The dynamic
entries automatically created in a MAC address table are not always valid. Each entry has a life
cycle. The entry that has never been updated till its life cycle ends will be deleted. This life cycle is
called aging time. If the entry is updated before its life cycle ends, the aging time of the entry is
recalculated.
Figure 8-2-1 Aging of MAC addresses
As shown in the preceding figure, the aging time of MAC addresses is set to T. At t1, packets with
the source MAC address 00e0-fc00-0001 and VLAN ID 1 reach an interface. Assume that the
interface is added to VLAN 1. If no entry with the MAC address as 00e0-fc00-0001 and the VLAN
ID as 1 exists in the MAC address table, the MAC address is added to the MAC address table as a
dynamic MAC address entry and the flag of the matching entry is set to 1.
The switch checks all learned dynamic MAC address entries at an interval of T. For example, at t 2, if
the switch discovers that the flag of the matching dynamic MAC address entry with the MAC address
as 00e0-fc00-0001 and the VLAN ID as 1 is 1, the flag of the matching MAC address entry is set to 0
and the MAC address entry is not deleted. If packets with the source MAC address as 00e0-fc00-0001
and the VLAN ID as 1 enter the switch between t2 and t3, the flag of the matching MAC address entry
is set to 1 again. If no packet with the source MAC address as 00e0-fc00-0001 and the VLAN ID as 1
enters the switch between t2 and t3, the flag of the matching MAC address entry is always 0. At t 3,
after discovering that the flag of the matching MAC address entry is 0, the switch assumes that the
aging time of the MAC address entry expires and deletes the MAC address entry.
As stated above, the minimum holdtime of a dynamic MAC address entry in the MAC address
table ranges from the aging time T to 2 T configured on the switch through automatic aging.
The aging time of MAC addresses is configurable. By setting the aging time of MAC addresses, you
can flexibly control the holdtime of learned dynamic MAC address entries in the MAC address
table.
8.2.2 Features of MAC Address Table
Disabling MAC Address Learning and Limiting the Number of MAC Addresses
The capacity of a MAC address table is limited. Therefore, when hackers forge a large quantity of
packets with different source MAC addresses and send the packets to a device, the MAC address
table of the device may reach its full capacity. When the MAC address table is full, the device cannot
learn source MAC addresses of valid packets.
A device limits the number of learned MAC addresses in one of the following
modes: Disabling MAC address learning on an interface or a VLAN
Limiting the number of MAC addresses on an interface or a VLAN
After MAC address learning is disabled on an interface or a VLAN, no MAC address entry can be
learned on the interface or VLAN. The system deletes the previously learned dynamic MAC
entries after the aging time expires. You can also manually delete these entries.
You can limit the maximum number of dynamic MAC address entries on a specified VLAN or
interface. After the number of MAC address entries learned by the VLAN or interface reaches the
limit, no MAC address entry can be learned on the VLAN or interface until the previously learned
MAC address entries age out.
In most cases, attack packets sent by a hacker enter a switch through the same interface. Therefore,
you can set the limit on the number of MAC address entries or disable MAC address learning on an
interface to prevent attack packets from exhausting the MAC address table.
Port Security
The port security function changes MAC addresses learned on an interface into secure MAC
addresses (including secure dynamic MAC addresses and sticky MAC addresses). Only hosts using
secure MAC addresses or static MAC addresses can communicate with the device through the
interface. This function enhances security of the device.
MAC Address Anti-flapping
MAC address flapping occurs on a network when the network has a loop or is
attacked. MAC address flapping can be prevented in the following two modes:
 Increasing the MAC address learning priority of an interface: When the same MAC address
entries are learned by interfaces of different priorities, the MAC address entries learned by
the interface with the highest priority overrides the MAC address entries learned by other
interfaces.
 MAC address flapping between interfaces with the same priority is forbidden. If the priority of
the interface on the forged device is the same as that on the authorized device, the MAC
address of the forged device learned later does not replace the correct MAC address. If the
device powers off, the MAC address of the forged device is learned. After the device
powers on, the device cannot learn the correct MAC address.
Figure 8-2-2 Networking diagram of MAC address anti-flapping
MAC Address Flapping Detection
The device can detect MAC address flapping. When MAC address flapping occurs, the device
can provide diagnosis information, including the flapping MAC address, interfaces between
which the MAC address flaps, and VLAN that the interfaces belong to. A loop may exist on the
interfaces between which the MAC address flaps. You will know how the loop is generated by
checking interfaces where MAC addresses are flapping.
Figure 8-2-3 MAC address flapping detection

8.3 Link Aggregation
Ethernet link aggregation, also called Eth-Trunk, bundles multiple physical links to form a logical
link to increase link bandwidth. The bundled links back up each other, increasing reliability.
As the network scale expands increasingly, users propose increasingly higher requirements on
Ethernet backbone network bandwidth and reliability. Traditional technologies often use high-speed
cards or devices supporting high-speed interface cards to increase the bandwidth. This solution,
however, is costly and inflexible.
Link aggregation helps increase bandwidth by bundling a group of physical interfaces into a
single logical interface, without having to upgrade hardware. In addition, link aggregation
provides link backup mechanisms, greatly improving link reliability.
As shown in Figure 8-3-1, DeviceA and DeviceB are connected through three Ethernet physical
links. These three Ethernet physical links are bundled into an Eth-Trunk link. The bandwidth of the
Eth-Trunk link is the sum of bandwidth of the three Ethernet physical links, so bandwidth is
increased. The three Ethernet physical links back up each other, which improves reliability.
NOTE:
Both devices of the Eth-Trunk must use the same number of physical interfaces, interface rate,
duplex mode, jumbo, and flow control mode.
Figure 8-3-1 Eth-Trunk networking
8.3.2 Features of Link Aggregation
Link aggregation can work in manual load balancing mode and LACP mode. In stack scenario, it can
support preferentially forwarding local traffic on an Eth-Trunk, and also support E-Trunk between
two devices.
Link Aggregation in Manual Load Balancing Mode
In manual load balancing mode, you need to manually create an Eth-Trunk interface and add member
interfaces to the Eth-Trunk interface, without the assistance of the LACP protocol. In this mode, all
the member interfaces of an LAG share the traffic evenly. If an active link fails, the other active links
share the traffic evenly. If a high link bandwidth between two directly connected devices is required
but the peer device does not support the LACP protocol, you can use the manual load balancing mode.
Figure 8-3-2 Eth-Trunk in manual load balancing mode

Link Aggregation in LACP Mode
Eth-Trunk in manual load balancing mode, as a link aggregation technology, can increase the
bandwidth. However, this mode can only detect link disconnections, but cannot detect other faults
such as link layer faults and incorrect link connections.
The Link Aggregation Control Protocol (LACP) is used, which can improve fault tolerance of the
Eth-Trunk and ensure high reliability of the member links.
LACP uses a standard negotiation mechanism for switching devices, ensuring that switching devices
automatically create and enable aggregated links based on their configurations. After aggregated
links are created, LACP maintains link status. If an aggregated link's status changes, LACP
automatically adjusts or disables the link.
 M:N backup
In LACP mode, LACP is used to negotiate parameters to determine active member links in an
LAG. This mode is also called the M:N mode, where M refers to the number of active links
and N refers to the number of backup links. This mode guarantees high reliability and allows
load balancing to be carried out across M active links.
As shown in Figure 8-3-3, M+N links with the same attributes (in the same LAG) are set up
between two devices. When data is transmitted over the aggregated link, load balancing is
performed on the M active links; no data is transmitted over the N backup links. Therefore,
the actual bandwidth of the aggregated link is the sum of the M links'bandwidth, and the
maximum bandwidth of the aggregated link is the sum of the M+N links'bandwidth.
If one of the M links fails, LACP selects a link from the N backup links to replace the faulty
link. In such a situation, the actual bandwidth of the aggregated link is still the sum of M
links'bandwidth; the maximum bandwidth of the aggregated link, however, becomes the sum of
the M+N-1 links'bandwidth.
Figure 8-3-3 M:N backup network diagram

M:N backup is mainly applied in situations where the bandwidth of M links must be assured,
and a fault tolerance mechanism in place. If an active link fails, the system selects the backup
link with the highest priority and this backup link becomes the active link.
If no available backup link is found, and the number of active links is smaller than the
lower threshold for the number of active interfaces, the system shuts down the LAG.
Inter-Device Eth-Trunk Supporting Preferential Forwarding of Local Traffic
In a stack, an Eth-Trunk is configured to be the outbound interface of traffic to ensure reliable

transmission. Member interfaces of the Eth-Trunk are located on different devices. When the stack
device forwards traffic, the Eth-Trunk may select an inter-device member interface based on the
hash algorithm. This occupies bandwidth resources between devices and reduces traffic forwarding
efficiency.
Figure 8-3-4 Inter-device Eth-Trunk preferential forwarding of local traffic

As shown in Figure 8-3-4, DeviceB and DeviceC constitute a stack, and the stack connects to
DeviceA through an Eth-Trunk. After the Eth-Trunk in the stack is configured to preferentially
forward local traffic, the following functions are implemented:
 Forwarding received traffic by the local device
When DeviceB has member interfaces of the Eth-Trunk and the member interfaces function
properly, the Eth-Trunk forwarding table of DeviceB contains only local member interfaces.
In this manner, the hash algorithm selects a local member interface, and traffic is only
forwarded through DeviceB.
 Forwarding received traffic by another device

When DeviceB does not have any member interface of the Eth-Trunk or all member interfaces
are faulty, the Eth-Trunk forwarding table of DeviceB contains all available member
interfaces. In this manner, the hash algorithm selects a member interface on DeviceC, and
traffic is forwarded through DeviceC.
NOTE:
 This function is only valid for known unicast packets, and is invalid for unknown unicast
packets, broadcast packets and multicast packets.
 Before configuring an Eth-Trunk to preferential forward local traffic, ensure that member
interfaces of the local Eth-Trunk have sufficient bandwidth to forward local traffic;
otherwise, traffic may be discarded.
E-Trunk
Enhanced Trunk (E-Trunk), an extension from the Link Aggregation Control Protocol (LACP), is a
mechanism that controls and implements link aggregation among multiple devices. E-Trunk
implements device-level link reliability, instead of board-level link reliability implemented by
LACP.
E-Trunk is mainly applied to a scenario where a CE is dual-homed to a VPLS, VLL, or PWE3

network. In this scenario, E-Trunk can be used to protect PEs and links between the CE and PEs.
Without
E-Trunk, a CE can be connected to only one PE by using an Eth-Trunk link. If the Eth-Trunk link or
PE fails, the CE cannot communicate with the PE. By using E-Trunk, the CE can be dual-homed to
PEs, establishing device-level protection.
As show in Figure 8-3-5, E-Trunk (Enhanced Trunk) is applied to between CE and double PE
connecting, to protect link stability. CE connects PE1 and PE2 through one LACP mode Eth-
Trunk. This two Eth-Trunk compose one E-Trunk, is used to link aggregation group backup, to
enhance network reliability.
Figure 8-3-5 E-Trunk network

8.4 GVRP
The Generic Attribute Registration Protocol (GARP) provides a mechanism to propagate attributes
so that a protocol entity can register and deregister attributes. By filling different attributes into
GARP packets, GARP supports different upper-layer applications.
The GARP VLAN Registration Protocol (GVRP) is used to register and deregister VLAN
attributes. GARP identifies applications through destination MAC addresses. IEEE Std 802.1Q
assigns
01-80-C2-00-00-21 to the VLAN application (GVRP).
To deploy certain VLANs on all devices on a network, the network administrator needs to manually
create these VLANs on each device. As shown in Figure 8-4-1, three routers are connected
through trunk links. VLAN 2 is configured on Router A, and VLAN 1 is configured on Router B and
Router C. To forward packets of VLAN 2 from Router A to Router C, the network administrator
must manually create VLAN 2 on Router B and Router C.
Figure 8-4-1 Networking of GVRP application
8.4.2 Registration Modes
A manually configured VLAN is a static VLAN, and a VLAN created through GVRP is a dynamic
VLAN. GVRP provides three registration modes. Static VLANs and dynamic VLANs are processed
differently in each registration mode as follows:
 Normal mode: Dynamic VLANs can be registered on a port, and the port can send declarations
of static VLANs and dynamic VLANs.
 Fixed mode: Dynamic VLANs cannot be registered on a port, and the port can send
only declarations of static VLANs.
 Forbidden mode: Dynamic VLANs cannot be registered on a port. All VLANs except VLAN
1 are deleted from the port, and the port can send only the declaration of VLAN 1.
8.4.3 GARP Timers
The GARP protocol defines four timers:
 Join timer
The Join timer controls sending of Join messages including JoinIn messages and
JoinEmpty messages.
After sending the first Join message, a participant starts the Join timer. If the participant
receives a JoinIn message before the Join timer expires, it does not send the second Join
message. If the participant does not receive any JoinIn message, it sends the second Join
message when the Join timer expires. This ensures that the Join message can be sent to other
participants. Each port maintains an independent Join timer.
 Hold timer
The Hold timer controls sending of Join messages (JoinIn messages and JoinEmpty messages)
and Leave messages (LeaveIn messages and LeaveEmpty messages).
After a participant is configured with an attribute or receives a message, it does not send the
message to other participants before the Hold timer expires. The participant encapsulates
messages received within the hold time into a minimum number of packets, reducing the
packets sent to other participants. If the participant does not use the Hold timer but forwards a
message immediately after receiving one, a large number of packets are transmitted on the
network. This makes the network unstable and wastes data fields of packets.
Each port maintains an independent Hold timer. The Hold timer value must be equal to or
smaller than half of the Join timer value.
 Leave timer
The Leave timer controls attribute deregistration.
A participant starts the Leave timer after receiving a Leave or LeaveAll message. If the
participant does not receive any Join message of the corresponding attribute before the
Leave timer expires, the participant deregisters the attribute.
A participant sends a Leave message if one of its attributes is deleted, but this attribute may
still exist on other participants. Therefore, the participant receiving the Leave message cannot
deregister the attribute immediately and needs to wait for messages from other participants.
For example, an attribute has two sources on the network: participant A and participant B.
Other participants register the attribute through GARP. If the attribute is deleted from
participant A, participant A sends a Leave message to other participants. After receiving the
Leave message, participant B sends a Join message to other participants because the attribute
still exists on participant B. After receiving the Join message from participant B, other
participants retain the attribute. Other participants deregister the attribute only if they do not
receive any Join message of the attribute within a period longer than two times the Join timer
value. Therefore, the Leave timer value must be greater than two times the Join timer value.
Each port maintains an independent Leave timer.
 LeaveAll timer
When a GARP participant starts, it starts the LeaveAll timer. When the LeaveAll timer
expires, the participant sends a LeaveAll message and restarts the LeaveAll timer.
After receiving a LeaveAll message, a participant restarts all GARP timers. The participant
sends another LeaveAll message when its LeaveAll timer expires. This reduces LeaveAll
messages sent in a period of time.
If LeaveAll timers of multiple devices expire at the same time, they send LeaveAll messages at
the same time, which causes unnecessary LeaveAll messages. To solve this problem, each
device uses a random value between the LeaveAll timer value and 1.5 times the LeaveAll timer
value as its LeaveAll timer value. When a LeaveAll event occurs, all attributes on the entire
network are deregistered. The LeaveAll event affects the entire network; therefore, you need to
set the LeaveAll timer to a proper value, at least greater than the Leave timer value.
Each device maintains a global LeaveAll timer.
8.5 Example for Configuration
8.5.1 Example for Configuring ARP
As shown in Figure 8-5-1, GE0/0/1 on the switch connects to hosts through the LAN Switch (LSW).
GE0/0/2 connects to a server. Requirements are as follows:
 GE0/0/1 belongs to VLAN2 and GE0/0/2 belongs to VLAN3.

 Dynamic ARP parameters should be configured for VLANIF2 of the switch so that
packets are transmitted correctly regardless of network topology change.
 To protect the server and defend against attack ARP packets sent from bogus servers, a
static ARP entry is added to GE0/0/2 of the switch. In this ARP entry, the IP address is
10.2.2.3 and the MAC address is 00e0-fc01-0000.
Figure 8-5-1 Networking diagram for configuring ARP

1210
1. Create VLANs and add interfaces to the VLANs.

2. Set dynamic ARP parameters for the user-side VLANIF interface.
3. Configure a static ARP entry.
Procedure
# Create VLAN2 and VLAN3.
[HUAWEI] vlan batch 2 3
# Add GE0/0/1 to VLAN2 and GE0/0/2 to VLAN3.

[HUAWEI-GigabitEthernet0/0/1] port link-type trunk
[HUAWEI-GigabitEthernet0/0/1] port trunk allow-pass vlan 2
2. Set dynamic ARP parameters for the VLANIF interface.
# Create VLANIF2.
# Configure an IP address for VLANIF2.
# Set the aging time of ARP entries to 60s.
[HUAWEI-Vlanif2] arp expire-time 60
# Set the number of probes to ARP entries to 2.
[HUAWEI-Vlanif2] arp detect-times 2

# Create VLANIF3.
# Configure an IP address for VLANIF3.

3. Configure a static ARP entry.
# Configure a static ARP entry with IP address 10.2.2.3, MAC address 00e0-fc01-
0000, VLAN ID 3, and outbound interface GE0/0/2.
[HUAWEI] arp static 10.2.2.3 00e0-fc01-0000 vid 3 interface gigabitethernet 0/0/2

[HUAWEI] quit
# Run the display current-configuration command to check the aging time, number
of probes, and ARP mapping entries.
<HUAWEI> display current-configuration | include arp

arp detect-times 2
arp expire-time 60
arp static 10.2.2.3 00e0-fc01-0000 vid 3 interface GigabitEthernet0/0/2
Configuration Files
Configuration file of the switch
#
sysname HUAWEI
#
vlan batch 2 to 3
#
interface Vlanif2
arp detect-times 2
arp expire-time 60
ip address 2.2.2.2 255.255.255.0
#
interface Vlanif3
ip address 10.2.2.2 255.255.255.0
#
#
port default vlan 3
#
arp static 10.2.2.3 00e0-fc01-0000 vid 3 interface GigabitEthernet0/0/2
#
return
8.5.2 Example for Configuring Routed Proxy ARP
In Figure 8-5-2, Ethernet interfaces GE0/0/1 and GE0/0/2 connect to two LANs respectively. The
two LANs are at the same network segment 172.16.0.0/16. HostA and HostB have no default
gateway. Routed proxy ARP is required to be configured on the switch so that hosts on two LANs
can communicate.
Figure 8-5-2 Networking diagram for configuring routed proxy ARP

2. Enable routed proxy ARP on interfaces.
Procedure
1. Create VLAN2 and add GE0/0/1 to VLAN2.
[HUAWEI] vlan 2
[HUAWEI-vlan2] quit
2. Create and configure VLANIF2.

3. Enable routed proxy ARP on VLANIF2.
[HUAWEI-Vlanif2] arp-proxy enable

4. Create VLAN3 and add GE0/0/2 to VLAN3.
[HUAWEI] vlan 3
[HUAWEI-vlan3] quit
5. Create and configure VLANIF3.

6. Enable routed proxy ARP on VLANIF3.
[HUAWEI-Vlanif3] arp-proxy enable

7. Configure hosts.
# Configure IP address 172.16.1.2/16 for HostA.
# Configure IP address 172.16.2.2/16 for HostB.

# Ping Host B from Host A. Host A can ping Host B successfully.
Configuration Files
#
sysname HUAWEI
#
vlan batch 2 to 3
#
interface Vlanif2
ip address 172.16.1.1 255.255.255.0
arp-proxy enable
#
interface Vlanif3
ip address 172.16.2.1 255.255.255.0
arp-proxy enable
#
port default vlan 2
#
port default vlan 3
#
return
8.5.3 Example for Configuring Layer 2 Topology Detection
As shown in Figure 8-5-3, two GE interfaces are added to VLAN100. IP addresses of the switch
that two GE interfaces connect.
Figure 8-5-3 Networking diagram for configuring Layer 2 topology detection
1. Add two GE interfaces to VLAN100.

2. Enable Layer 2 topology detection to view changes of ARP entries.
Procedure
1. Create VLAN100 and add two GE interfaces on the switch to VLAN100.
# Create VLAN100 and configure an IP address for the VLANIF interface.
[HUAWEI] vlan 100
[HUAWEI-vlan100] quit
# Add two GE interfaces to VLAN100.

2. Enable Layer 2 topology detection.

[HUAWEI] l2-topology detect enable
3. Restart GE0/0/1 and view changes of ARP entries and aging time.
# Ping host IP addresses on network segments 10.1.1.1 and 10.1.1.3 from the switch, and
then check the ARP entries on the switch. You can see that the switch has learned MAC
addresses of the hosts.
[HUAWEI] ping 10.1.1.1


0.00% packet loss

0.00% packet loss
[HUAWEI] display arp all
VPN-INSTANCE
VLAN
-----------------------------------------------------------------------------
10.1.1.2
10.1.1.1
100
10.1.1.3 00e0-de24-bf04 20 D-0 GE0/0/2
100
-----------------------------------------------------------------------------
# Run the shutdown and undo shutdown commands on GE0/0/1 and view the aging time of
ARP entries.
o Run the shutdown command on GE0/0/1 to view the aging time of ARP entries.

[HUAWEI-GigabitEthernet0/0/1] shutdown
[HUAWEI-GigabitEthernet0/0/1] display arp all
IP ADDRESS
INTERFACE
VLAN
----------------------------------------------------------------------------
10.1.1.2 00e0-c01a-4900 I- Vlanif100
10.1.1.3 00e0-de24-bf04 18 D-0 GE0/0/2
100
------------------------------------------------------------------------------
o Run the undo shutdown command on GE0/0/1. Ping a host IP address on the
network segment 10.1.1.1 from the switch, and then check the aging time of the
ARP
entries on the switch.

[HUAWEI-GigabitEthernet0/0/1] undo shutdown

0.00% packet loss
[HUAWEI] display arp all
IP ADDRESS
INTERFACE
VLAN
-----------------------------------------------------------------------------
10.1.1.2 00e0-c01a-4900 I- Vlanif100
10.1.1.1 00e0-c01a-4901 20 D-0 GE0/0/1
100
10.1.1.3 00e0-de24-bf04 20 D-0 GE0/0/2
100
-----------------------------------------------------------------------------
NOTE:
The preceding command output shows that the ARP entries learned from GE 0/0/1 are deleted after
GE 0/0/1 is shut down. After the undo shutdown command is run on GE 0/0/1 and GE 0/0/1 goes
Up, the ARP entry learned from GE 0/0/2 is aged, and then the device sends an ARP probe packet
for updating ARP entry. After the entry is updated, the aging time restores the default value, 20
minutes.
Configuration Files
#
sysname HUAWEI
#
l2-topology detect enable
#
vlan batch 100
#
interface Vlanif100
ip address 10.1.1.2 255.255.255.0
#
#
#
return
8.5.4 Example for Configuring Multi-interface ARP
As shown in Figure 8-5-4, Switch connects to an NLB server cluster which works in unicast mode.
Switch connects to three servers in the cluster through three interfaces GE0/0/1, GE0/0/2, and
GE0/0/3 in VLAN10. The IP address and MAC address of the NLB server cluster are 192.168.1.1/24
and
02bf-fc01-0000 respectively. Switch needs to send packets destined for 192.168.1.1 to all the servers
in the cluster.
Figure 8-5-4 Configuring multi-interface ARP
1. Configure a multi-interface MAC address table and a static ARP entry, so IP packets can
be sent to three servers simultaneously.
Procedure
1. Create a VLAN and add interfaces to the VLAN.
# Create VLAN10.
[HUAWEI] sysname Switch
[Switch] vlan 10
1210
[Switch-vlan10] quit
# Add interfaces GE0/0/1, GE0/0/2, and GE0/0/3 to VLAN10.
[Switch] interface gigabitethernet 0/0/1

[Switch-GigabitEthernet0/0/1] port link-type access
[Switch-GigabitEthernet0/0/1] port default vlan 10
[Switch-GigabitEthernet0/0/1] quit
2. Create VLANIF10 and assign an IP address to VLANIF10.
[Switch] interface vlanif 10

[Switch-Vlanif10] ip address 192.168.1.2 24
[Switch-Vlanif10] quit
3. Configure a multi-interface MAC address entry and a static ARP entry.
Configure a multi-interface MAC address table. In this entry, the MAC address is
02bf-fc01-0000, the VLAN ID is VLAN10, and the corresponding outbound interfaces are
GE0/0/1, GE0/0/2, and GE0/0/3.
[Switch] mac-address multiport 02bf-fc01-0000 interface gigabitethernet 0/0/1 to

gigabitethernet 0/0/3 vlan 10
Configure a static ARP entry that maps the IP address 192.168.1.1 to the MAC address
02bf-fc01-0000.
[Switch] arp static 192.168.1.1 02bf-fc01-0000

[Switch] quit
# Run the display mac-address multiport vlan 10 command on Switch to view the entries
in the multi-interface MAC address table.
<Switch> display mac-address multiport vlan 10

--------------------------------------------------------------------------------
MAC Address VLANID Out-Interface
--------------------------------------------------------------------------------
02bf-fc01-0000 10 GigabitEthernet0/0/1
3 port(s)
--------------------------------------------------------------------------------
Total Group(s) : 1
# Run the display arp command on Switch to view the ARP entry.
<Switch> display arp

VPN-INSTANCE
VLAN
------------------------------------------------------------------------------
192.168.1.1 02bf-fc01-0000 S-- Multi-port:3
------------------------------------------------------------------------------
Configuration Files
Configuration file of Switch
#
sysname Switch
#
vlan batch 10
#
interface Vlanif10
ip address 192.168.1.2 24
#
mac-address multiport 02bf-fc01-0000 vlan 10
#
#
#
arp static 192.168.1.1 02bf-fc01-0000
#
return
8.5.5 Example for Configuring the MAC Address Table
As shown in Figure 8-5-5, the MAC address of the user host PC1 is 0002-0002-0002 and that of
the user host PC2 is 0003-0003-0003. PC1 and PC2 are connected to the Switch through the LSW.
The LSW is connected to GE0/0/1 of the Switch, which belongs to VLAN 2. The MAC address of
the server is 0004-0004-0004. The server is connected to GE0/0/2 of the Switch. GE0/0/2 belongs
to VLAN 2.
 To prevent hackers from using MAC addresses to attack the network, configure two
static
MAC address entries for each user host on the Switch.
 To prevent hackers from stealing user information by forging the MAC address of the
server, configure a static MAC address entry on the Switch for the server.
Figure 8-5-5 Configuring the MAC address table

1. Create a VLAN and add an interface to the VLAN to implement Layer 2 forwarding.
2. Configure static MAC address entries to prevent MAC address attacks.
3. Configure the aging time of dynamic MAC address entries to update the entries.
Procedure
1. Configure static MAC address entries.
# Create VLAN 2 and add GigabitEthernet0/0/1 and GigabitEthernet0/0/2 to VLAN 2.
[Switch] vlan 2
[Switch-vlan2] quit
[Switch-GigabitEthernet0/0/1] port hybrid pvid vlan 2
[Switch-GigabitEthernet0/0/1] port hybrid untagged vlan 2
# Configure a static MAC address entry.
[Switch] mac-address static 2-2-2 GigabitEthernet 0/0/1 vlan 2

2. Set the aging time of a dynamic MAC address entry.
[Switch] mac-address aging-time 500
# Run the display mac-address static command in any view to check whether the static MAC
address entries are successfully added to the MAC address table.
[Switch] display mac-address static vlan 2

-------------------------------------------------------------------------------
MAC Address VLAN/VSI Learned-From Type
-------------------------------------------------------------------------------
0002-0002-0002
0003-0003-0003
0004-0004-0004 2/- GE0/0/2 static
-------------------------------------------------------------------------------
Total items displayed =3
# Run the display mac-address aging-time command in any view to check whether the aging
time of dynamic entries is set successfully.
[Switch] display mac-address aging-time
Aging time: 500 second(s)
Configuration Files
#
sysname Switch
#
vlan batch 2
#
mac-address aging-time 500
#
port hybrid pvid vlan 2
port hybrid untagged vlan 2
#
#
mac-address static 0002-0002-0002 GigabitEthernet0/0/1 vlan 2
mac-address static 0003-0003-0003 GigabitEthernet0/0/1 vlan 2
mac-address static 0004-0004-0004 GigabitEthernet0/0/2 vlan
2
#
return
8.5.6 Example for Configuring MAC Address Learning in a
VLAN Networking Requirements
As shown in Figure 8-5-6, user network 1 is connected to Switch on the GigabitEthernet0/0/1

through an LSW. User network 2 is connected to Switch on the GigabitEthernet0/0/2 through another
LSW. Both GigabitEthernet0/0/1 and GigabitEthernet0/0/2 belong to VLAN 2. To prevent MAC
address
attacks and limit the number of access users on the device, limit MAC address learning on all
the interfaces in VLAN 2.
Figure 8-5-6 Networking diagram for MAC address limiting in a VLAN
2. Limit MAC address learning on all the interfaces in the VLAN to prevent MAC
address attacks and limit the number of access users.
Procedure
1. Limit MAC address learning.
# Add GigabitEthernet0/0/1 and GigabitEthernet0/0/2 to VLAN 2.
[Switch] vlan 2
[Switch-vlan2] quit
# Configure the following MAC address limiting rule in VLAN 2: A maximum of 100
MAC addresses can be learned. When the number of learned MAC addresses reaches the
limit, the device and sends an alarm.
[Switch] vlan 2
[Switch-vlan2] mac-limit maximum 100 alarm enable
[Switch-vlan2] return
# Run the display mac-limit command in any view to check whether the MAC
address limiting rule is successfully configured.
<Switch> display mac-limit

MAC limit is enabled
Total MAC limit rule count : 1
PORT VLAN/VSI SLOT Maximum Rate(ms) Action Alarm

----------------------------------------------------------------------------
- 2 - 100 - forward enable
Configuration Files
The following lists only the configuration file of Switch.
#
sysname Switch
#
vlan batch 2
#
vlan 2
mac-limit maximum 100
#
#
#
return
8.5.7 Example for Configuring MAC Address Anti-flapping
Employees of an enterprise need to access the enterprise server. If an attacker uses the server
MAC address as the source MAC address to send packets to another interface, the server MAC
address is learned on the interface. Packets sent to the server are sent to unauthorized users. In
this case, employees cannot access the server, and important data will be intercepted by the
attacker.
As shown in Figure 8-5-7, MAC address anti-flapping can be configured to protect the server
from attacks.
Figure 8-5-7 Networking diagram of MAC address anti-flapping
2. Configure MAC address anti-flapping on the server-side interface.
Procedure
1. Create a VLAN and add the interfaces to the VLAN.
# Add GigabitEthernet0/0/1 and GigabitEthernet0/0/2 to VLAN 10.
[Switch] vlan 10
[Switch-GigabitEthernet0/0/2] port link-type trunk
[Switch-GigabitEthernet0/0/2] port trunk allow-pass vlan 10
2. # Set the MAC address learning priority of GigabitEthernet0/0/1 to 2.
[Switch-GigabitEthernet0/0/1] mac-learning priority 2

# Run the display current-configuration command in any view to check whether the MAC
address learning priority of the interface is set correctly.
[Switch] display current-configuration interface gigabitethernet 0/0/1

#
mac-learning priority 2
#
return
Configuration Files
#
sysname Switch
#
vlan batch 10
#
mac-learning priority 2
#
#
return
8.5.8 Example for Configuring MAC Address Flapping Detection
As shown in Figure 8-5-8, a loop occurs on a user network because network cables between two
LSWs are incorrectly connected. The loop causes MAC address flapping and bridge table flapping.
You can enable MAC address flapping detection on the Switch to detect MAC address flapping
and discover loops.
Figure 8-5-8 Networking diagram of MAC address flapping detection

1210
1. Enable MAC address flapping detection.
2. Set the aging time of flapping MAC addresses.
3. Configure the action performed on the interface when MAC address flapping is detected
on the interface to prevent loops.
Procedure
1. Enable MAC address flapping detection.
[Switch] mac-address flapping detection
2. Set the aging time of flapping MAC addresses.
[Switch] mac-address flapping aging-time 500
3. Shut down GE0/0/1 and GE0/0/2 when MAC address flapping is detected.

[Switch-GigabitEthernet0/0/1] mac-address flapping action error-down
[Switch-GigabitEthernet0/0/2] mac-address flapping action error-down
4. Configure automatic recovery and set the automatic recovery time for the shutdown interface.
[Switch] error-down auto-recovery cause mac-address-flapping interval 500
After the configuration is complete, when the MAC address on GE0/0/1 flaps to GE0/0/2,
GE0/0/2 is shut down. Run the display mac-address flapping record command to view
the
flapping records.
[Switch] display mac-address flapping record

S : start time
E : end time
(Q) : quit vlan
(D) : error down
-------------------------------------------------------------------------------
Move-Time VLAN MAC-Address Original-Port Move-Ports
MoveNum
-------------------------------------------------------------------------------
S:2012-04-01 17:22:36 1 0000-0000-0007 GE0/0/1 GE0/0/2(D) 83
E:2012-04-01 17:22:44
-------------------------------------------------------------------------------
Total items on slot 0: 1
Configuration Files
#
sysname Switch
#
error-down auto-recovery cause mac-address-flapping interval 500
#
mac-address flapping aging-time 500
#
mac-address flapping action error-down
#
mac-address flapping action error-down
#
return
8.5.9 Example for Configuring Link Aggregation in Manual Load Balancing Mode
As shown in Figure 8-5-9, RouterA and RouterB connect to devices in VLAN 10 and VLAN
20 through Ethernet links, and heavy traffic is transmitted between RouterA and RouterB.
RouterA and RouterB can provide higher link bandwidth to implement inter-VLAN
communication. Reliability of data transmission needs to be ensured.
Figure 8-5-9 Networking diagram for configuring link aggregation in manual load balancing mode
1. Create an Eth-Trunk and add member interfaces to the Eth-Trunk to increase link bandwidth.
3. Set the load balancing mode to ensure that traffic is load balanced between member
interfaces of the Eth-Trunk.
Procedure
1. Create an Eth-Trunk on RouterA and add member interfaces to the Eth-Trunk. The
configuration of RouterB is similar to the configuration of RouterA, and the
configuration details are not mentioned here.
<Huawei> system-view [Huawei]

sysname RouterA [RouterA]
interface Eth-Trunk1
[RouterA-Eth-Trunk1] trunkport ethernet 1/0/1 to 1/0/3
[RouterA-Eth-Trunk1] quit
2. Create VLANs and add interfaces to the VLANs. The configuration of RouterB is similar to
the configuration of RouterA, and the configuration details are not mentioned here.
# Create VLAN 10 and VLAN 20, and add interfaces to VLAN 10 and VLAN 20.
[RouterA] vlan batch 10 20

[RouterA] interface ethernet 1/0/4
[RouterA-Ethernet1/0/4] port link-type trunk
[RouterA-Ethernet1/0/4] port trunk allow-pass vlan 10
[RouterA-Ethernet1/0/4] quit
# Configure Eth-Trunk 1 to allow packets from VLAN 10 and VLAN 20 to pass through.
[RouterA] interface Eth-Trunk1

[RouterA-Eth-Trunk1] port link-type trunk
[RouterA-Eth-Trunk1] port trunk allow-pass vlan 10 20
3. Set the load balancing mode of Eth-Trunk 1. The configuration of RouterB is similar to
the configuration of RouterA, and the configuration details are not mentioned here.
[RouterA-Eth-Trunk1] load-balance src-dst-mac

Run the display eth-trunk 1 command in any view to check whether the Eth-Trunk is
created and whether member interfaces are added.
[RouterA] display eth-trunk 1

Eth-Trunk1's state information is:
WorkingMode: NORMAL Hash arithmetic: According to SIP-XOR-DIP
Least Active-linknumber: 1 Max Bandwidth-affected-linknumber: 8
Operate status: up Number Of Up Ports In Trunk: 3
--------------------------------------------------------------------------------
PortName
Ethernet1/0/1
Ethernet1/0/2
Ethernet1/0/3
The preceding command output shows that Eth-Trunk 1 has three member interfaces:
Ethernet1/0/1, Ethernet1/0/2, and Ethernet1/0/3. The member interfaces are both in Up
state.
Configuration Files
Configuration file of RouterA
#
sysname RouterA
#
vlan batch 10 20
#
port trunk allow-pass vlan 10 20
load-balance src-dst-mac
#
eth-trunk 1
#
eth-trunk 1
#
eth-trunk 1
#
#
#
return
Configuration file of RouterB
#
sysname RouterB
#
vlan batch 10 20
#
port trunk allow-pass vlan 10 20
load-balance src-dst-mac
#
eth-trunk 1
#
eth-trunk 1
#
eth-trunk 1
#
#
#
return
8.5.10 Example for Configuring Link Aggregation in LACP Mode
To increase the bandwidth and improve the connection reliability, you can configure a link
aggregation group on two directly connected Routers, as shown in Figure 8-5-10. The requirements
are as follows:
 The link aggregation group contains three member links. Two links function as active links
to implement load balancing, and the other link functions as the backup link.
 When a fault occurs on an active link, the backup link replaces the faulty one to help
ensure uninterrupted data.
Figure 8-5-10 Network diagram of link aggregation in LACP mode
1. Create an Eth-Trunk on each Router and configure the Eth-Trunk to work in LACP mode.
2. Add member interfaces to the Eth-Trunk.
3. Set the system priority and determine the Actor.
4. Set the maximum number of active interfaces in the Eth-Trunk.
5. Set the priority of the interface and determine the active link.
Procedure
1. Create Eth-Trunk 1 and set the load balancing mode of the Eth-Trunk to LACP mode.
[RouterA] interface eth-trunk 1
[RouterA-Eth-Trunk1] mode lacp-static
[RouterB] interface eth-trunk 1
[RouterB-Eth-Trunk1] mode lacp-static
[RouterB-Eth-Trunk1] quit
2. Add member interfaces to the Eth-Trunk.

[RouterA-Ethernet2/0/1] eth-trunk 1
[RouterB] interface ethernet 2/0/1

[RouterB-Ethernet2/0/1] eth-trunk 1
[RouterB-Ethernet2/0/1] quit
3. Set the system priority on RouterA to 100 so that RouterA becomes the Actor.
[RouterA] lacp priority 100
4. Set maximum number of active interfaces in the Eth-Trunk on RouterA to 2.
[RouterA] interface eth-trunk 1

[RouterA-Eth-Trunk1] max active-linknumber 2
5. Set the priority of the interface and determine active links on RouterA.

[RouterA-Ethernet2/0/1] lacp priority 100
[RouterA-Ethernet2/0/2] lacp priority 100
# Check information about the Eth-Trunk of the Routers and check whether the negotiation
is successful on the link.
[RouterA] display eth-trunk 1

Local:
LAG ID: 1 WorkingMode: STATIC
Preempt Delay: Disabled Hash arithmetic: According to SA-XOR-
DA System Priority: 100 System ID: 00e0-fca8-0417
Least Active-linknumber: 1 Max Active-linknumber: 2
Operate status: Up Number Of Up Port In Trunk: 2
------------------------------------------------------------------------------
ActorPortName Status PortType PortPri PortNo PortKey PortState
Weight
Ethernet2/0/1
11111100
Ethernet2/0/2
11111100
Ethernet2/0/3
11100000
Partner:
------------------------------------------------------------------------------
PartnerPortName SysPri SystemID PortPri PortNo PortKey PortState
Ethernet2/0/1 32768 00e0-fca6-7f85 32768 6145 2609
11111100
Ethernet2/0/2 32768 00e0-fca6-7f85 32768 6146 2609
11111100
Ethernet2/0/3 32768 00e0-fca6-7f85 32768 6147 2609
11110000
[RouterB] display eth-trunk 1

Local:
LAG ID: 1 WorkingMode: STATIC
Preempt Delay: Disabled Hash arithmetic: According to SA-XOR-DA
System Priority: 32768 System ID: 00e0-fca6-7f85
Least Active-linknumber: 1 Max Active-linknumber: 8
Operate status: Up Number Of Up Port In Trunk: 2
------------------------------------------------------------------------------
ActorPortName Status PortType PortPri PortNo PortKey PortState
Weight
Ethernet2/0/1
11111100
Ethernet2/0/2
11111100
Ethernet2/0/3
11100000
Partner:
------------------------------------------------------------------------------
PartnerPortName SysPri SystemID PortPri PortNo PortKey
PortState
Ethernet2/0/1 100 00e0-fca8-0417 100 6145 2865
11111100
Ethernet2/0/2 100 00e0-fca8-0417 100 6146 2865
11111100
Ethernet2/0/3 100 00e0-fca8-0417 32768 6147 2865
11110000
The preceding information shows that the system priority of RouterA is 100, which is higher
than the system priority of RouterB. Member interfaces Ethernet2/0/1 and Ethernet2/0/2 are
active interfaces and are in Selected state. Interface Ethernet2/0/3 is in Unselect state. You
can also see that load balancing and redundancy are implemented.
Configuration Files
#
sysname RouterA
#
lacp priority 100
#
mode lacp-static
max active-linknumber 2
#
eth-trunk 1
lacp priority 100
#
eth-trunk 1
lacp priority 100
#
eth-trunk 1
#
return
#
sysname RouterB
#
mode lacp-static
#
eth-trunk 1
#
eth-trunk 1
#

1210
eth-trunk 1
#
return
8.5.11 Example for Configuring an Inter-Chassis Eth-Trunk Interface to Forward Traffic

Preferentially Through Local Member Interfaces(Stack)
NOTE:
The S5700S-LI and S5710HI do not support this configuration.

On the network shown in Figure 8-5-11, Switch 3 and Switch 4 are connected through CSS cables to
increase the total capacity. The two switches are considered as one logical switch. To improve
reliability, physical interfaces on the two switches are added to an Eth-Trunk interface. When the
network runs properly, check member interface information on PE. Traffic from VLAN 2 is
forwarded through GE1/0/1 and GE1/0/2, and traffic from VLAN 3 is forwarded through GE1/0/1 and
GE1/0/2. This increases bandwidth use efficiency between devices and reduces traffic forwarding
efficiency.
To improve traffic forwarding efficiency, traffic from VLAN 2 should be forwarded through GE
1/0/1 and traffic from VLAN 3 should be forwarded through GE1/0/2. To achieve this goal,
configure the Eth-Trunk interface to forward traffic preferentially through the local member
interface.
Figure 8-5-11 Preferentially forwarding traffic through the local member interface
1. Create an Eth-Trunk interface.
2. Add member interfaces to the Eth-Trunk interface.
NOTE:
An interface is added to VLAN1 by default. To avoid broadcast storm, shut down the
interface or remove the interface from VLAN1 before adding it to an Eth-Trunk interface.
3. Configure the Eth-Trunk interface to forward traffic preferentially through the local
member interface.
4. Configure the Layer 2 forwarding function.

Procedure
1. Create an Eth-Trunk interface and configure the Eth-Trunk interface to allow packets all
VLANs to pass through.
# Configure the CSS.
[HUAWEI] sysname CSS
[CSS] interface eth-trunk 10
[CSS-Eth-Trunk10] port link-type trunk
[CSS-Eth-Trunk10] port trunk allow-pass vlan all
[CSS-Eth-Trunk10] quit
# Configure the PE.
[HUAWEI] sysname PE
[PE] interface eth-trunk 10
[PE-Eth-Trunk10] port link-type trunk
[PE-Eth-Trunk10] port trunk allow-pass vlan all
[PE-Eth-Trunk10] quit
2. Add member interfaces to the Eth-Trunk interface.
[CSS] interface gigabitethernet 1/0/4

[CSS-GigabitEthernet1/0/4] eth-trunk 10
[CSS-GigabitEthernet1/0/4] quit
[CSS-GigabitEthernet2/0/4] eth-trunk 10
# Configure the PE.
[PE] interface gigabitethernet 1/0/1

[PE-GigabitEthernet1/0/1] eth-trunk 10
[PE-GigabitEthernet1/0/1] quit
[PE-GigabitEthernet1/0/2] eth-trunk 10
3. In the CSS view, configure the Eth-Trunk interface to forward traffic preferentially through
the local member interface.
[CSS] interface eth-trunk 10

[CSS-Eth-Trunk10] local-preference enable
[CSS-Eth-Trunk10] quit
NOTE:
By default, an Eth-Trunk is enabled to preferentially forward local traffic. If you run
the local-preference enable command, the message "Error: The local preferential forwarding
mode has been configured." is displayed.
4. Configure the Layer 2 forwarding function.
[CSS] vlan batch 2 3

[CSS-GigabitEthernet1/0/3] port link-type trunk
[CSS-GigabitEthernet1/0/3] port trunk allow-pass vlan 2
[CSS-GigabitEthernet2/0/3] port link-type trunk
[CSS-GigabitEthernet2/0/3] port trunk allow-pass vlan 3
# Configure Switch 1.
[HUAWEI] sysname Switch1
[Switch1] vlan 2
[Switch1-vlan2] quit
[Switch1] interface gigabitethernet 0/0/1
[Switch1-GigabitEthernet0/0/1] port link-type trunk
[Switch1-GigabitEthernet0/0/1] port trunk allow-pass vlan
2 [Switch1-GigabitEthernet0/0/1] quit
# Configure Switch 2.
[HUAWEI] sysname Switch2
[Switch2] vlan 3
[Switch2-vlan3] quit
[Switch2-GigabitEthernet0/0/1] port trunk allow-pass vlan 3
[Switch2-GigabitEthernet0/0/1] quit
Run the display trunkmembership eth-trunk command in any view to check

information about Eth-Trunk member interface.
The output on the CSS is used as an example.
<CSS> display trunkmembership eth-trunk 10

Trunk ID: 10
Used status: VALID
TYPE: ethernet
Working Mode : Normal
Number Of Ports in Trunk = 2
Number Of Up Ports in Trunk = 2
Operate status: up
Interface GigabitEthernet1/0/4, valid, operate up, weight=1
Interface GigabitEthernet2/0/4, valid, operate up, weight=1
Configuration Files
 Configuration file of the CSS
#
sysname CSS
#
vlan batch 2 3
#
port trunk allow-pass vlan 2 to 4094
#
#
#
eth-trunk 10
#
eth-trunk 10
#
return
 Configuration file of the PE
#
sysname PE
#
#
eth-trunk 10
#
eth-trunk 10
#
return
 Configuration file of Switch 1
#
sysname Switch1
#
vlan batch 2
#
#
#
return
 Configuration file of Switch 2
#
sysname Switch2
#
vlan batch 3
#
#
#
return
8.5.12 Example for Configuring GVRP
As shown in Figure 8-5-12, company A, a branch of company A, and company B are connected
using switches. To implement dynamic VLAN registration, enable GVRP. The branch of company A
can communicate with the headquarters using RouterA and RouterB. Company B can communicate
with company A using RouterB and RouterC. Interfaces connected to company A allow only the
VLAN to which company B belongs to pass.
Figure 8-5-12 Networking diagram of GVRP configuration

1. Enable GVRP to implement dynamic VLAN registration.
2. Configure GVRP on all switche devices of company A and set the registration mode to
normal for the interfaces to simplify configurations.
3. Configure GVRP on all switche devices of company B and set the registration mode to fixed
for the interfaces connecting to company A to allow only the VLAN to which company B
belongs to pass.
Procedure
1. Create VLAN 101 to VLAN 200 on RouterA.
[RouterA] vlan batch 101 to 200
2. Configure GVRP on RouterA.
# Enable GVRP globally.
[RouterA] gvrp
# Set the link type of Eth 2/0/1 and Eth 2/0/2 to trunk, and configure the interfaces to allow all

[RouterA-Ethernet2/0/1] port trunk allow-pass vlan all
[RouterA-Ethernet2/0/2] port trunk allow-pass vlan all
# Enable GVRP on the interfaces and set the registration modes for the interfaces.

[RouterA-Ethernet2/0/1] gvrp
[RouterA-Ethernet2/0/1] gvrp registration normal
[RouterA-Ethernet2/0/2] gvrp
[RouterA-Ethernet2/0/2] gvrp registration normal
The configuration of RouterB is similar to that of RouterA.
3. Configure RouterC.
# Create VLAN 101 to VLAN 200.
<RouterC> system-view
[RouterC] vlan batch 101 to 200
# Enable GVRP globally.
[RouterC] gvrp
# Set the link type of Eth 2/0/1 and Eth 2/0/2 to trunk, and configure the interfaces to allow all
[RouterC] interface ethernet 2/0/1

[RouterC-Ethernet2/0/1] port link-type trunk
[RouterC-Ethernet2/0/1] port trunk allow-pass vlan all
[RouterC-Ethernet2/0/1] quit
[RouterC-Ethernet2/0/2] port link-type trunk
[RouterC-Ethernet2/0/2] port trunk allow-pass vlan all
# Enable GVRP on the interfaces and set the registration modes for the interfaces.

[RouterC-Ethernet2/0/1] gvrp
[RouterC-Ethernet2/0/1] gvrp registration fixed
[RouterC-Ethernet2/0/2] gvrp
[RouterC-Ethernet2/0/2] gvrp registration normal
After the configuration is complete, the branch of Company A can communicate with the
headquarters, and users of Company A in VLAN 101 to VLAN 200 can communicate
with users in Company B.
Run the display gvrp status command on RouterA to check whether GVRP is enabled
globally. The following information is displayed:
<RouterA> display gvrp status

Info: GVRP is enabled.
Run the display gvrp statistics command on RouterA to view GVRP statistics, including the
GVRP state of each interface, number of GVRP registration failures, source MAC address
of the last GVRP PDU, and registration mode of each interface.
<RouterA> display gvrp statistics interface ethernet 2/0/1

GVRP statistics on port Ethernet2/0/1
GVRP status : Enabled
GVRP registrations failed :0
GVRP last PDU origin : 0001-0001-0001
GVRP registration type : Normal
Verify the configurations of RouterB and RouterC in the same way.
Configuration Files
#
sysname RouterA
#
vlan batch 101 to 200
#
gvrp
#
interface ethernet2/0/1
gvrp
#
gvrp
#
return
#
sysname RouterB
#
gvrp
#

1210
gvrp
#
gvrp
#
return
#
sysname RouterC
#
vlan batch 101 to 200
#
gvrp
#
gvrp
gvrp registration fixed
#
gvrp
#
return
Chapter 9 Layer 2 WAN Technologies
9.1 PPP
9.1.1 PPP Overview
Point-to-Point Protocol (PPP) is a link-layer protocol used to transmit point-to-point data

over full-duplex synchronous and asynchronous links.
PPP is built upon the Serial Line Internet Protocol (SLIP). SLIP supports only the
asynchronous transfer mode (ATM), transmits only IP packets, and does not support
negotiation. Due to these disadvantages, SLIP is gradually being replaced by PPP.
PPP has the following advantages:
 PPP supports both synchronous and asynchronous links, other data link-layer protocols
such as X.25 and Frame Relay (FR) support only synchronous links, and SLIP supports
only asynchronous links.
 PPP features high extensibility. For example, PPP is extended as Point-to-Point Protocol over
Ethernet (PPPoE) when PPP packets need to be transmitted over an Ethernet.
 PPP uses Link Control Protocol (LCP) to negotiate link-layer attributes.
 PPP uses the Network Control Protocol (NCP) such as the IP Control Protocol (IPCP)
and Internetwork Packet Exchange Control Protocol (IPXCP) to negotiate network-layer
parameters.
 PPP provides the Challenge Handshake Authentication Protocol (CHAP) and Password
Authentication Protocol (PAP) to ensure network security.
 PPP has no retransmission mechanism, reducing the network cost and speeding up
packet transmission.
9.1.2 Basic PPP Architecture
PPP is used at the data link layer of the TCP/IP protocol suite for point-to-point data transmission
over full-duplex synchronous and asynchronous links.
Figure 9-1-1 Location of PPP in the protocol suite

PPP consists of three types of protocols:
 LCP: is used to establish, monitor, and tear down PPP data links.
 NCP: is used to negotiate the format and type of packets transmitted on data links.
 CHAP and PAP: are used for network security authentication.
9.1.3 PPP-Encapsulated Packet Format
Figure 9-1-2 shows the PPP packet format.

Figure 9-1-2 PPP packet format
The meanings of the fields are as follows:
 Flag field
The Flag field identifies the start and end of a physical frame and is always 0x7E.
 Address field
The Address field identifies a peer. Two communicating devices connected by using PPP do
not need to know the data link layer address of each other because PPP is used on P2P links.
This field must be filled with a broadcast address of all 1s and is of no significance to PPP.
 Control field
The Control field value defaults to 0x03, indicating an unsequenced frame. By default, PPP
does not use sequence numbers or acknowledgement mechanisms to ensure transmission
reliability.
The Address and Control fields identify a PPP packet, so the PPP packet header value is FF03.
 Protocol field
The Protocol field identifies the datagram encapsulated in the Information field of a PPP
data packet.
The structure of this field complies with the ISO 3309 extension mechanism for address fields.
All Protocol field values must be odd; the least significant bit of the least significant byte must
be "1"; the least significant bit of the most significant byte must be "0".
If a receiver receives a data packet that does not comply with these rules from a sender, the
receiver considers the packet unrecognizable and sends a Protocol-Reject packet padded with
the protocol code of the rejected packet to the sender.
Table 9-1-1 Common protocol codes
Protocol Code Protocol Type

Protocol Code
0021
002b
002d
002f
8021
802b
8031
C021
C023
C223
 Information field
The Information field contains the datagram for the protocol specified in the Protocol field.
The maximum length for the Information field, including the Padding field, is the maximum
receive unit (MRU). The MRU defaults to 1500 bytes and can be negotiated.
In the Information field, the Padding field is optional. If there is the Padding field in the
Information field, two communicating parties can communicate only when they can identify
the padding information and information to be transmitted.
 FCS field
The frame check sequence (FCS) field checks the correctness of PPP packet transmission.
Some mechanisms are used to ensure data packet transmission, increasing the cost and delay
in
data exchange at the application layer.
9.1.4 PPP Link Establishment Process
The following figure shows the PPP link establishment process.

Figure 9-1-3 PPP link establishment process
The PPP link establishment process is as follows:
1. Two communicating devices enter the Establish phase if one of them initiates a PPP
connection request.
2. In the Establish phase, the two devices perform an LCP negotiation to negotiate the
following items: working mode (SP or MP), MRU (Maximum Receive Unit), authentication
mode, and magic number (SP is short for single-link PPP). If the LCP negotiation succeeds,
LCP turns Opened, which indicates that a lower-layer link has been established.
3. If authentication is configured, the two devices enter the Authenticate phase and perform
CHAP or PAP authentication. If no authentication is configured, the two devices enter the
Network phase.
4. In the Authentication phase, if CHAP or PAP authentication fails, the devices enter the
Terminate phase. The link is removed and LCP turns Down. If CHAP or PAP
authentication succeeds, the devices enter the Network phase and LCP remains Opened.
5. In the Network phase, the two devices perform an NCP negotiation to select and configure a
network protocol and to negotiate network-layer parameters. After the two devices succeed
in negotiating a network protocol, packets can be sent over this PPP link using the network
protocol.
Various control protocols such as IPCP and Multiprotocol Label Switching Control Protocol
(MPLSCP) can be used in NCP negotiation. IPCP mainly negotiates the IP addresses of the
two devices.
6. After NCP negotiation succeeds, packets can be sent over the PPP link. If the PPP connection is
interrupted during PPP operation, the two devices enter the Termination phase, the physical
link is disconnected, the PPP authentication fails, or the negotiation timer expires.
7. In the Termination phase, the two devices enter the Dead phase after all resources are
released.
The two devices remain in the Dead phase until a new PPP connection is established
between them.
The following describes the phases involved in PPP negotiation.

Dead Phase
The physical layer is unavailable during the Dead phase. A PPP link begins and ends with this phase.
When two communicating devices detect that the physical link between them is activated (for
example,
carrier signals are detected on the physical link), PPP enters the Establish phase from the Dead
phase. After the link is terminated, PPP enters the Dead phase.
Establish Phase
In the Establish phase, the two devices perform an LCP negotiation to negotiate the following items:
working mode (SP or MP), MRU, authentication mode, and magic number. After the LCP
negotiation is complete, PPP enters the next phase.
In the Establish phase, the LCP status changes as follows:
 When the link is unavailable (in the Dead phase), LCP is in the Initial or Starting state. When
detecting that the link is available, the physical layer sends an Up event to the link layer. After
receiving the Up event, the link layer changes the LCP status to Request-Sent. Then the
devices at both ends send Configure-Request packets to configure a data link.
 If the local device first receives a Configure-Ack packet from the peer, the LCP status changes
from Request-Sent to Ack-Received. After the local device sends a Configure-Ack packet to
the peer, the LCP status changes from Ack-Received to Opened.
 If the local device first sends a Configure-Ack packet to the peer, the LCP status changes from
Request-Sent to Ack-Sent. After the local device receives a Configure-Ack packet from the
peer, the LCP status changes from Ack-Sent to Opened.
 After LCP enters the Opened state, PPP enters the next phase.
The next phase is the Authentication or Network phase, depending on whether authentication
is required.
Authentication Phase
The Authentication phase is optional. By default, PPP does not perform authentication during PPP
link establishment. If authentication is required, the authentication protocol must be specified in the
Establish phase.
PPP authentication is performed on links between hosts and devices that are connected through PPP
network servers, switched circuits or dial-up lines, or on dedicated links.
PPP provides two password authentication modes: PAP authentication and CHAP authentication.
Two CHAP authentication modes are available: unidirectional CHAP authentication and
bidirectional CHAP authentication. In unidirectional CHAP authentication, the device on one end
functions as the authenticating device, and the device on the other end functions as the authenticated
device. In
bidirectional CHAP authentication, each device functions as both the authenticating device
and authenticated device. In practice, only unidirectional CHAP authentication is used.
Network Phase
In the Network phase, NCP negotiation is performed to select and configure a network protocol and
to negotiate network-layer parameters. Each NCP may be in Opened or Closed state at any time.
After an NCP enters the Opened state, network-layer data can be transmitted over the PPP link.
Termination Phase
PPP can terminate a link at any time. A link can be terminated manually by an administrator, or
be terminated due to the loss of carrier, an authentication failure, or other causes.
9.1.5 PAP Authentication

Process
PAP is a two-way handshake authentication protocol that transmits passwords in plain

text.
Figure 9-1-4 shows the PAP authentication process.
Figure 9-1-4 PAP authentication process
 The authenticated device sends the local user name and password to the authenticating device.
 The authenticating device checks whether the received user name is in the local user table.
 If the received user name is in the local user table, the authenticating device checks
whether the received password is correct. If so, the authentication succeeds. If not,
the authentication fails.
 If the received user name is not in the local user table, the authentication
fails.
9.1.6 CHAP Authentication Process
CHAP is a three-way handshake authentication protocol. CHAP transmits only user names but
not passwords, so it is more secure than PAP.
Figure 9-1-5 shows the CHAP authentication process.
Figure 9-1-5 CHAP authentication process
Unidirectional CHAP authentication is applicable to two scenarios:
 The authenticating device is configured with a user name.
 The authenticating device is not configured with a user name.
It is recommended that the authenticating device be configured with a user name.
 When the authenticating device is configured with a user name:
 The authenticating device initiates an authentication request by sending a Challenge

packet that carries the local user name to the authenticated device.
 After receiving the Challenge packet at an interface, the authenticated device checks
whether the ppp chap password command is used on the interface. If this command is
used, the authenticated device encrypts the Challenge packet with the packet ID and
password configured by the command by using the Message Digest 5 (MD5) algorithm.
Then the authenticated device sends a Response packet carrying the generated cipher text
and local user name to the authenticating device. If the ppp chap password command is
not configured, the authenticated device searches the local user table for the password
matching the user name of the authenticating device in the received Challenge packet,
and
encrypts the Challenge packet with the packet ID and user password by using the MD5
algorithm. Then the authenticated device sends a Response packet carrying the
generated cipher text and local user name to the authenticating device.
 The authenticating device encrypts the Challenge packet with the saved password of the
authenticated device by using the MD5 algorithm. Then the authenticating device
compares the generated cipher text with that carried in the received Response packet, and
returns a response based on the result of the check.
 When the authenticating device is not configured with a user name:
 The authenticating device initiates an authentication request by sending a Challenge packet.
 After receiving the Challenge packet, the authenticated device encrypts the Challenge
packet with the packet ID and password configured by the ppp chap password
command by using the Message Digest 5 (MD5) algorithm. Then the authenticated
device sends a Response packet carrying the generated cipher text and local user name to
the authenticating device.
 The authenticating device encrypts the Challenge packet with the saved password of the
authenticated device by using the MD5 algorithm. Then the authenticating device
compares the generated cipher text with that carried in the received Response packet, and
returns a response based on the result of the check.
9.1.7 Comparison Between CHAP and PAP Authentication Processes
 In PAP authentication, passwords are sent over links in plain text. After a PPP link is
established, the authenticated device repeatedly sends the user name and password until
authentication finishes. This mode cannot ensure high security, so it is used on networks that do
not require high security.
 CHAP is a three-way handshake authentication protocol. In CHAP authentication, the

authenticated device sends only the user name to the authenticating device. Compared with
PAP, CHAP features higher security because passwords are not transmitted. On networks
requiring high security, CHAP authentication is used to establish a PPP connection.
9.2 MP
9.2.1 MP Overview
Multilink PPP (MP) is a technique that binds multiple PPP links together to increase bandwidth
and ensure link reliability.
MP provides the following functions:
 Increases bandwidth.
 Implements load balancing.
 Provides link backup.
 Reduces delay using fragments.
9.2.2 MP Implementation
MP can be implemented using a virtual template interface or an MP-Group interface. Table 9-2-1
lists the MP implementation types and principles.
Type Subtype Principle

Using a virtual Binding PPP links to a Multiple physical interfaces are bound to a
template interface virtual template interface virtual template interface to implement MP.
Authentication is optional.
NOTE:
A virtual template  If none authentication is configured,
interface is used
to configure a interface binding takes effect after the
virtual access LCP status of the physical interfaces
interface. After becomes Up.
multiple PPP
links are bundled  If authentication is configured,
into an MP link, a interface binding takes effect only
virtual access after the physical interfaces are
interface needs to
be created to authenticated.
exchange data
with the peer.
Searching for a virtual The system searches for the bound virtual
template interface using the template interface using the authenticated
user name of a PPP link remote user name. Multiple physical interfaces
with the same user name are bound to the same
virtual template interface and inherit the
configuration of the virtual template interface to
form an MP bundle. An MP bundle is
represented by a channel of the virtual template
interface and corresponds to one MP link. This
MP binding mode requires PPP authentication.
MP binding takes effect only after the physical
interfaces are authenticated.
Using an Binding PPP links to an An MP-Group interface is dedicated to MP

MP-Group MP-Group interface applications. MP binding cannot be
interface implemented by specifying the remote user
name and endpoint discriminator on an
MP-Group interface, and one MP-Group
interface cannot be used to form multiple MP
bundles. Compared with MP implementation
using a virtual template interface, MP
implementation using an MP-Group interface is
easier to configure.
If a virtual template interface is used to implement MP, multiple MP bundles can be formed and each
MP bundle corresponds to one MP link, regardless of how MP binding is implemented. To
differentiate MP bundles formed by using a virtual template interface, specify the binding mode using
the ppp mp binding-mode command in the virtual template interface view. The command supports
three binding modes: authentication, descriptor, and both. The default binding mode is both.

1210
 If the MP binding mode is authentication, links with the same remote user name are bound
to the same MP bundle.
 If the MP binding condition is descriptor, links with the same remote endpoint
discriminator through LCP negotiation are bound to the same MP bundle.
 If the MP binding mode is both, links with the same remote user name and remote
endpoint discriminator are bound to the same MP bundle.
9.2.3 MP Link Establishment and Negotiation Processes
In the MP link establishment process, the Dead and Terminate phases are the same as those in the PPP
link establishment process. The differences in other phases are as follows:
 In the Establish phase, LCP negotiation is performed to check whether the remote interface
also works in MP mode in addition to negotiating LCP parameters. If they work in different
working modes, LCP negotiation fails. After LCP becomes Up, the two devices enter the
Authentication phase if authentication is configured. After authentication succeeds, the two
devices enter the Network phase. If no authentication is configured, the two devices enter
the Network phase.
 In the Authenticate phase, neither the virtual template interface nor the MP-Group interface
support authentication. Authentication must be configured on a physical
interface.
 In the Network phase, the local device searches for an MP bundle according to the binding
mode. When no MP bundle is found, the local device creates an MP bundle corresponding to
an MP link. When an MP bundle is found, a physical interface on the local device is bound
to the MP bundle. IPCP negotiation is then performed on the MP bundle. After IPCP
negotiation succeeds, packets can be sent over the MP link.
9.2.4 LFI
As increasing network services are emerging and people are demanding higher network quality,
limited bandwidth cannot meet network requirements. As a result, the delay and signal loss occur
because of congestion. When a network is congested intermittently and delay-sensitive services
require higher
QoS than services not as susceptible to the delay, congestion management is required. If congestion
persists on the network after congestion management is configured, the bandwidth needs to be
increased. Congestion management often uses queue scheduling technologies such as Priority
Queuing (PQ) and Weighted Fair Queueing (WFQ) to send packet flows in queues.
On low-speed serial links, even if queue scheduling technologies are used to implement congestion
management, real-time interactive communication such as Telnet and VoIP is often delayed due to
transmission of oversized packets. For example, if a voice packet arrives when an oversized packet
is being scheduled, the voice packet can be scheduled only after the oversized packet is transmitted,
which deteriorates the voice communication quality.
The interactive voice communication requires that the end-to-end delay should be less than or equal to
150 ms. If it takes 215 ms to transmit a 1500-byte packet over a 56 kbit/s link, this is unacceptable.
To shorten the delay in transmitting packets of a real-time application on low-speed links, a method
is
required to fragment oversized packets and place fragmented packets in the same queues as
other packets.
Link fragmentation and interleaving (LFI) fragments oversized packets. Then the fragmented
packets
are sent together with other packets. In this manner, the delay and jitter on a low-speed link are
reduced. The fragmented packets are reassembled at the destination.
Figure 9-2-1 shows the LFI process. When oversized packets and small voice packets arrive at an
interface simultaneously, the oversized packets are fragmented. If weighted fair queuing (WFQ) is
configured on the interface, the voice packets and the fragmented packets are placed into the WFQ
queues in interleaving mode. Voice packets are transmitted first because they have a higher
priority than the other packets in the queues.
Figure 9-2-1 LFI process
9.3 PPPoE
9.3.1 PPPoE Overview
PPP over Ethernet (PPPoE) is a network protocol that encapsulates Point-to-Point Protocol
(PPP) frames into Ethernet frames. PPPoE enables multiple hosts on an Ethernet to connect to a
broadband remote access server (BRAS).
Carriers want to connect multiple hosts at a site to the same remote access device. The access device
is expected to provide access control and accounting for these hosts in a manner similar to dial-up
access using PPP. Using PPPoE, carriers can achieve this goal at lower cost because Ethernet is the
most
cost-effective among all access technologies and PPP implements access control and
accounting.
PPPoE allows a large number of hosts on an Ethernet to connect to the Internet using a remote
access device and controls each host using PPP. PPPoE features a large application scale, high
security, and convenient accounting.
The PPPoE technology implements practical applications such as Internet access accounting and
is widely used by broadband access carriers.
9.3.2 PPPoE Networking
PPPoE uses the client/server model. A PPPoE client sends a connection request to the PPPoE
server, and the PPPoE server provides access control and authentication functions for the PPPoE
client.
Two PPPoE network structures are available based on the start and end points of PPPoE sessions.
 Figure 9-3-1 shows the first PPPoE network structure. In the network, a PPPoE session is
established between Router A and Router B. Router A functions as a PPPoE client and forwards
data from all hosts to Router B using the PPPoE session. No PPPoE client dialing software is
installed on the hosts. The hosts, which are users in an enterprise or company, share one
account.
As shown in Figure 9-3-1, the PPPoE client is deployed in an enterprise or company, and the
PPPoE server is a carrier's device.
Figure 9-3-1 PPPoE networking diagram (1)
 Figure 9-3-2 shows the second PPPoE network structure. In the network, a PPPoE session is
established between the carrier's router and each host. The router functions as the PPPoE server,
and each host functions as a PPPoE client. Each host has a unique account, which facilitates
user accounting and control by the carrier. The PPPoE client software must be installed on the
hosts.
Figure 9-3-2 PPPoE networking diagram (2)

9.3.3 PPPoE Packet Format
Figure 9-3-3 shows the format of a PPPoE packet, that is, a PPP packet encapsulated in an
Ethernet frame.
Figure 9-3-3 Format of a PPPoE packet

Each field is described as follows:
 Destination_Address: indicates an Ethernet unicast destination address or Ethernet

broadcast address 0xFFFFFFFF.
 At the Discovery stage, the value is a unicast destination address or broadcast address. In a
Discovery packet sent when a PPPoE client searches for the PPPoE server, the value is a
broadcast address. In a Discovery packet sent after the PPPoE client finds the PPPoE
server, the value is a unicast destination address.
 At the PPPoE Session stage, the value must be the unicast destination address
determined at the Discovery stage.
 Source_Address: indicates the Ethernet MAC address of the source device.
 Ethernet_Type:
 The value is 0x8863 at the Discovery stage.
 The value is 0x8864 at the PPPoE Session stage.
 VER: indicates the PPPoE version number. This field is 4 bits in length and must be set to 0x01.
 Type: indicates the PPPoE type. This field is 4 bits in length and must be set to 0x01.
 Code: indicates the PPPoE packet type. This field is 8 bits in length.
The value 0x00 indicates session data; the value 0x09 indicates PPPoE Active Discovery
Initiation (PADI) packets; the value 0x07 indicates PPPoE Active Discovery Offer (PADO)
packets; the value 0x19 indicates PPPoE active discovery request (PADR) packets; the value
0x65 indicates PPPoE Active Discovery Session-confirmation (PADS) packets; the value 0xa7
indicates PPPoE Active Discovery Terminate (PADT) packets. For details about PPPoE packet
structure, see PPPoE Packet Structure.
 Session_ID: indicates the session ID. It is an unsigned number in network byte order. This
field is 16 bits in length.
The value is fixed for a given PPPoE session and defines a PPPoE session along with Ethernet
Source_address and Destination_address.
The value 0xFFFF is reserved.
 Length: indicates the length of the PPPoE payload. This field is 16 bits in length. It does
not include the length of the Ethernet or PPPoE packet header.
 Tag_Type: indicates the network byte order. This field is 16 bits in length.
 Tag_Length: indicates the number of bytes of the Tag_Value field. It is an unsigned number
in network byte order. This field is 16 bits in length.
 Checksum: checks the validity of packets.
9.3.4 PPPoE Session Establishment Process
Figure 9-3-4 shows the process of establishing a PPPoE session.
Figure 9-3-4 PPPoE session establishment process

The PPPoE session establishment process includes three stages: Discovery, Session, and Terminate.
Discovery Stage
The Discovery stage consists of the following steps:
1. A PPPoE client broadcasts a PADI packet that contains service information required by the
PPPoE client.
2. After receiving the PADI packet, all PPPoE servers compare the requested service with the
services they can provide. The PPPoE servers that can provide the requested service
unicast PADO packets to the PPPoE client.
3. Based on the network topology, the PPPoE client may receive PADO packets from more
than one PPPoE server. The PPPoE client selects the PPPoE server from which the first
PADO packet is received and unicasts a PADR packet to the PPPoE server.
4. The PPPoE server generates a unique session ID to identify the PPPoE session with the
PPPoE client. The PPPoE server sends a PADS packet containing this session ID to the
PPPoE client. When the PPPoE session is established, the PPPoE server and PPPoE client
enter the PPPoE Session stage.
When the PPPoE session is established, the PPPoE server and PPPoE client share the unique PPPoE
session ID and learns the peer Ethernet address.
Session Stage
The PPPoE Session stage involves PPP negotiation and PPP packet transmission.
PPP negotiation at the PPPoE Session stage is the same as common PPP negotiation, which
includes the LCP, authentication, and NCP phases.
1. In the LCP phase, the PPPoE server and PPPoE client establish and configure a data link,
and verify the data link status.
2. When LCP negotiation is complete, authentication starts. The authentication protocol

depends on the LCP negotiation result. The authentication protocol can be Challenge
Handshake Authentication Protocol (CHAP) or Password Authentication Protocol (PAP).
3. When authentication succeeds, PPP enters the Network Control Protocol (NCP) phase. NCP is
a protocol suite used to configure network–layer protocols. A commonly used network-layer
protocol is IP Control Protocol (IPCP), which is responsible for configuring IP addresses for
users and the domain name server (DNS).
When PPP negotiation succeeds, PPP data packets can be forwarded.
At the PPPoE Session Stage, the PPPoE server and PPPoE client unicast all Ethernet data packets.
Terminate Stage
The PPPoE server and PPPoE client use PPP protocol packets to terminate the PPPoE session.
When the PPP protocol packets are unavailable, PPP communicating parties can use PADT packets
to terminate the PPPoE session.
After a PPPoE session is established, the PPPoE client or the PPPoE server can unicast a PADT
packet to terminate the PPPoE session at any time. After transmitting or receiving the PADT packet,
the PPPoE server and PPPoE client is not allowed to use this session to send any PPP traffic.
9.4 Frame Relay
9.4.1 FR Overview
Working at the data link layer of the Open System Interconnection (OSI) model, Frame Relay (FR) is
a technique that uses simple methods to transmit and exchange data.
A distinct feature of FR is that FR simplifies processes of error control, confirmation and

re-transmission, traffic control, and congestion prevention on an X.25 packet switch network, thus
reducing processing time. This is quite important to effective use of high-speed digital
transmission channels.
NOTE:
The delay of packet switching on an X.25 network is tens to hundreds milliseconds, whereas the
delay of packet switching on an FR network can be reduced to several milliseconds.
Data communications devices such as routers are connected through private lines, which results
in many disadvantages.
 Firstly, private lines use fixed bandwidth and interfaces. It is inconvenient for users to
change bandwidth or expand capacity.
 Secondly, the cost of connecting the networks by the private lines is high and user rental
is also high.
 In addition, if the private lines are used to construct a fully-connected network and the
number of users is n, n (n-1) / 2 circuits are thus needed, which causes a lot of trouble to the
management and application of the network resources.
FR is mainly used on Wide Area Networks (WANs) and it supports multiple types of data services. FR
can address the following problems:
 In the initial stage of applications, it is quite easy to realize FR by upgrading software on

existing X.25 interfaces. FR is implemented based on X.25. Therefore, hardware of an
existing X.25 device does not need reconstruction and the device can provide FR
services after its software is upgraded.
 The flexible charging of FR is suitable for burst transmission. At present, many carriers adopt
Committed Information Rate (CIR) for accounting, thus reducing the communication
charge of CIR users.
 FR can dynamically allocate the network resources. Users can use the superfluous
bandwidth and share network resources even if telecom carriers do not reinvest.
9.4.2 Basic Concepts of FR
An FR network uses the VC to connect FR devices on two ends of the network. Every VC uses Data
Link Connection Identifier (DLCI) to define an FR channel.
Data Link Connection Identifier
FR is a statistical multiplexing protocol. It provides multiple VCs on a single physical line.
DLCI is applied to differentiate VCs. It is valid only on the local interface and the directly-connected
peer interface but not valid globally. On an FR network, the same DLCI on different physical
interfaces does not indicate the same VC.
A user interface on an FR network supports multiple VCs. The available DLCI ranges from 16 to
1022 among which DLCIs 1007 to 1022 are reserved. Because the FR VC is connection-oriented,
different local DLCIs are connected to different remote devices. Therefore, the local DLCI can be
considered as the "FR address" of the remote device.
The FR address mapping associates the peer protocol address with the FR address (local DLCL).
Thus, the upper-layer protocol can locate the remote device.
When transmitting IP packets over FR links, a router searches for the next-hop address in the
routing table first, and then it finds the corresponding DLCI in the address mapping table of FR.
This table maintains the mapping information between remote IP address and next hop DLCL. The
address mapping table can be configured manually or maintained dynamically by Inverse ARP.
DTE, DCE, UNI, and NNI
FR networks allow devices to exchange data. Devices and interfaces on FR networks play one of
the following roles:
 DTE: data terminal equipment

 DCE: data communication equipment, providing access services for DTE devices
 UNI: user-network interface, interconnecting a DTE device and a DCE device
 NNI: network-network interface, interconnecting DCE devices
An FR network can be a public network, a private network of an enterprise, or a network formed

by directly connected devices.
On the FR network shown in Figure 9-4-1, two DTE devices RouterA and RouterD at the access
layer are connected over the switch layer formed by two DCE devices, RouterB and RouterC. DTE
and DCE devices are connected through UNIs, which must be configured with the same DLCI.
UNIs are applicable to only the FR access scenario. A PVC is established between the two DTE
devices, and each PVC segment can be configured with a different DLCI.
Figure 9-4-1 Roles of devices and interfaces on FR networks
NOTE:
The device functions as a DTE or DCE. When functioning as a DCE, the device only provides
UNIs for FR termination.
Virtual Circuit
A VC is the logical circuit built on the shared network between two network devices. VCs can
be divided into the Permanent VC (PVC) and Switching VC (SVC).
 PVC: refers to the manually created VC.
 SVC: refers to the VC that can be created or cleared automatically through
negotiation. At present, PVCs are often used on FR networks.
The device supports only PVCs.
The PVC status of the DTE is determined by the DCE, and the PVC status of the DCE is determined
by the network.
If two network devices are connected directly, the VC status on DCE side is configured by
the administrator.
The Local Management Interface (LMI) protocol maintains the link and PVC status of the Frame
Relay through the status enquiry packet and status packet.
9.4.3 LMI Protocol
Introduction to LMI
In the PVC, both the network devices and user devices need to know the current status of PVC.
The protocol that monitors the PVC status is called the Local Management Interface (LMI)
protocol.
The LMI protocol maintains the link and PVC status of the Frame Relay through the status
enquiry packet and status packet. The LMI module is used to manage the PVC, including the
adding and deleting of the PVC, the detecting of the PVC link integrity, and the PVC status.
The system supports three LMI protocols:
 LMI complying with ITU-T Q.933 Appendix A.

 LMI complying with ANSI T1.617 Appendix D.
 Nonstandard compatible protocol.
For details, refer to the protocol text. The LMI protocol belongs to the functions on the control
layer. Q.933 Appendix A is used most in the LMI protocol.Q.933 Appendix A defines the
information unit
and the realized procedures of the LMI protocol.
LMI Protocol Procedure
LMI protocol procedure includes as follows:
 Adding the PVC notification
 Deleting the PVC detection
 Notifying the configured PVC available or unavailable status
 Authenticating the link integrity
Types of LMI Protocol Message
The LMI protocol message can be divided into two types:
 Status enquiry message
The DTE side sends a status enquiry message to request the DCE side for the VC status or
the link integrity verification.
 Status message
The status message is a response message sent from DCE to DTE after DCE receives the
status request message. This packet can transfer the VC status or verify the link integrity.
Types of LMI Protocol Packets
The LMI protocol packets can be divided into three types as follows:
 Link integrity verification packet: It is used only to verify the link integrity.
 Full status packet: It is used to both verify the link integrity and transfer the PVC status.
 Asynchronous PVC status packet: It does not contain the status request message, only used
to timely notify the PVC status on the DTE side when the PVC status changes.
Q.933 Appendix A uses the VC whose DLCI is 0 to transmit the status or status request packets.

1210
Status Packet
Status message is used to reply the status request message, notifying the PVC status and link
integrity detection.
On a UNI interface, the PVC status of DTE is completely decided by DCE that notifies all PVCs
status of DTE. Therefore, DTE has to only query DCE at a fixed time, and then it can obtain the
current PVC status on this interface. The PVC status of DCE is determined by the network devices.
On a NNI interface, the network devices on both sides exchange the PVC status at a fixed time
by
using the LMI protocol. Different from UNI, the network devices on both sides of a NNI interface
send request packets to their peers. After receiving the request packets, the two ends of the NNI
interface
can respond to the packets.
Brief Process of the LMI Protocol
The brief process of the LMI protocol is as

follows:
1. DTE sends a status request packet and the timer T391 begins to time. The interval of T391 is
the interval of a polling. That is, DTE sends a status request packet in every other T391.At the
same time, the counter V391 of DTE begins to count.
 When V391 is less than N391, the status request packet sent by DTE queries only the
link integrity.
 When V391 is equal to N391, V391 is set to 0, and the status request packet sent by
DTE queries both the link integrity and the status of all PVCs, this status request packet
is called a full status request packet.
Therefore, N391 defines the time of a period, and DTE sends a full status request packet
in every other a period. Both N392 and N393 can use the default value or set manually.
2. After receiving the polling message, DCE uses the status message to respond the status
request message. At the same time, the polling of DCE proves that the timer T392 begins to
time, waiting for the next status request message. After T392 times out, DCE does not receive
the status request message, and DCE records this error and the times of error increases by 1.
3. DTE reads the received the status response message to know the link integrity and PVC status.
DCE responds to the status that DTE needs to know. If the PVC status changes or the added
or deleted PVC exists in local network, DCE must respond to the status message of all PVCs
no matter DTE queries the PVC status or not. By doing so, DTE can know the changes of
DCE timely and renew the previous record.
4. After T391 times out, the DTE devices do not receive the status response message, and DTE
records this error and the number of errors increases by 1.
5. In N393 events, if the number of errors exceeds N392, DTE or DCE reckons that this
physical channel and all the VCs are unavailable. N393 indicates the total observed events.
N392
indicates the error threshold. Both N392 and N393 can be set manually or are set to the
default value.
9.4.4 InARP
The main function of InARP (Inverse ARP) is to solve the IP addresses of the remote device that
is connected to every VC.
If the protocol address of the remote device that is connected to a VC is known, the mapping between
the remote protocol address and DLCI can be created on the local end, which can avoid configuring
the address mapping manually.
The basic process is as follows:
1. When a new VC is found, InARP sends a request packet to the remote end on this VC if the
local interface is configured with the protocol address. This request packet contains the
local protocol address. When the remote device receives this request packet, the local
protocol address can be obtained to create the address mapping and an InARP response
packet is sent. The address mapping is thus created on the local end.
2. If the static mapping is configured manually or dynamic mapping is created, the InARP
request packet is not sent to the remote end on this VC regardless of whether the remote
address in the dynamic mapping is correct. An InARP request packet is sent to the remote end
only when no mapping exists.
3. If the receiver of the InARP request packet finds the remote protocol address is the same as
that in the local configured mapping, it does not create the dynamic mapping.
The format of an InARP packet is the same as that of a standard ARP packet.
9.4.5 Basic Principles of FR
LMI Negotiation Process
As shown in Figure 9-4-2, two routers are directly connected through serial interfaces.
 FR interfaces on RouterA work in DCE mode.
 FR interfaces on RouterB work in DTE mode.
Figure 9-4-2 Networking diagram of LMI negotiation process

The LMI negotiation process is as follows:
1. The interface in DTE mode periodically sends status enquiry messages to the interface in DCE
mode.
2. The interface in DCE mode, after receiving a status enquiry message, replies with a
status message to the interface in DTE mode.
3. The interface in DTE mode determines the link status and PVC status according to the
received status messages.
4. If interfaces in DCE and DTE modes can normally exchange LMI negotiation messages,
the link status changes to Up and the PVC status changes to Active.
5. The FR LMI negotiation succeeds.
InARP Negotiation Process
After the FR LMI negotiation succeeds and the PVC status changes to Active, the InARP
negotiation starts.
The InARP negotiation process is as follows:
1. If the interface on the local device has been configured with a protocol address, the PVC of
the interface on the local device can send Inverse ARP Request packets to the remote device.
The request packet carries the protocol address of the interface on the local device.
2. After receiving the request packet, the remote device generates an address mapping table
based on the local address carried in the request packet and sends an Inverse ARP Response
packet to the local device.
3. The local device obtains the remote address from the received Inverse ARP Response
packet and then generates an address mapping table.
4. Address mapping tables are generated on RouterA and RouterB. For example, in the address
mapping table on RouterA, the DLCI value corresponding to the IP address 10.1.1.2 is 100; in
the address mapping table on RouterB, the DLCI value corresponding to the IP address
10.1.1.1 is 100.
After the LMI and InARP negotiations, the protocol status of the FR interface goes Up and
address mapping tables are generated, which enable the PVC to transmit IP packets.
9.4.6 FR Sub-Interfaces
Origins of FR Sub-Interfaces
An FR network can connect the networks that are in different places. The possible network
structures are star structure, partial-connected and full-connected network structures.
From the aspect of economy, the star structure is the excellent network structure because it uses
the least PVCs and the primary node connects the multiple dispersive branch nodes by using
multiple PVCs on one interface. This structure is mainly used for the headquarters to connect
multiple
subdivisions. The disadvantage of this structure is that the communication between branch nodes
needs to be transmitted through a primary node.
In the full-connected structure, all nodes are connected to other nodes through the PVCs and a node
does not need other nodes to transmit the communication. In addition, this structure has high
flexibility. When the directly-connected PVC is Down, the communication can be transmitted through
other nodes. The disadvantage of this structure is that many PVCs are needed, and the number of PVCs
needed increases sharply when the number of nodes increases in the network.
In the partial-connected structure, not all nodes have PVCs to access other nodes. Its advantage and
disadvantage are intervenient between the star and full-connected structure. The defaulted network of
FR is Non-broadcast Multi-access (NBMA). Different from the Ethernet, the NBMA network does
not support the broadcast, though nodes are connected in an FR network. If one node obtains the
routing information, it generates many copies of the information and then sends the information to
the connected multiple nodes through the PVCs.
To decrease the routing loop, the split horizon mechanism does not allow the router to send out
the updated information through the interface that receives this information.
Figure 9-4-3 FR and the split horizon

As shown in Figure 9-4-3, RouterB advertises RouterA a piece of router information, but RouterA
cannot advertise this information to RouterC or RouterD through Serial 1/0/0 that receives this
router information according to the split horizon. The methods to solve this problem are as follows:
 Using multiple physical interfaces to connect multiple adjacent nodes: This requires the router
to have multiple physical interfaces, and increases the cost of users.
 Using the sub-interfaces (that is, configuring multiple logical interfaces on one
physical interface): Like a physical interface, every sub-interface has its network
address.
 Deleting the split horizon: This needs the support from the routing protocol, and increases
the probability of routing loop.
FR Sub-Interfaces
Figure 9-4-4 FR Sub-Interfaces

You can define these logical sub-interfaces on the serial line. Every sub-interface uses one or
multiple DLCIs to connect to the remote device. After a DLCI is configured on a sub-interface, the
mapping between the destination protocol address and this DLCI needs to be created.
In this way, the DLCI on Serial 1/0/0.1 is defined to access RouterB, the DLCI on Serial 1/0/0.2 is
defined to access RouterC, and the DLCI on Serial 1/0/0.3 is defined to access RouterD on
Serial1/0/0, though only one physical serial port, Serial 1/0/0, exists on RouterA.
After a logical sub-interface is defined on a physical interface, the FR connection can become the
partial-connected connection. routers can interconnect and forward the updated information by
configuring the sub-interfaces. In this way, multiple sub-interfaces on one physical interface are
not affected by the split horizon.
This connection of multiple sub-interfaces on one physical interface is different from the point-to-
point (P2P) connection in NBMA. In the configuration of NBMA, all routers are on the same subnet,
using the PVCs of the full-connected connection.
However, only the sub-interfaces of two connected routers are on the same subnet, when the P2P
sub-interface of FR is used. This FR configuration contains many subnets.
Classification of FR Sub-interfaces
FR sub-interfaces can be classified into the following types:
 Point-to-point sub-interface: used to connect a single remote device. Each point-to-point sub-
interface can be configured with only one PVC. In this case, the remote device can be
determined uniquely without the static address mapping. Thus, when the PVC is configured
for the sub-interface, the peer address is identified.
 Point-to-multipoint sub-interface: used to connect multiple remote devices. Each sub-

interface can be configured with multiple PVCs. Each PVC maps the protocol address of its
connected remote device. In this way, different PVCs can reach different remote devices. The
address
mapping must be configured manually or dynamically set up through the Reverse Address
Resolution Protocol (RARP).
9.5 Examples for Configuring of Layer 2 WAN Technologies
9.5.1 Example for Configuring Unidirectional PAP Authentication (Local
Authentication) Networking Requirements
As shown in Figure 9-5-1, Serial1/0/0 of RouterA connects to Serial1/0/0 of RouterB.
Users want that RouterA performs simple authentication on RouterB while RouterB does
not authenticate RouterA.
Figure 9-5-1 Networking diagram of PAP

authentication
1. Configure PAP authentication because PAP authentication meets user's requirements of

simple authentication and low security.
2. Configure RouterA as the PAP authenticator and RouterB as the PAP authenticated party to
meet the unidirectional authentication requirement.
Procedure
1. Configure RouterA
# Assign an IP address to Serial1/0/0 and configure PPP as the link layer protocol of Serial1/0/0.
[RouterA] interface serial 1/0/0
[RouterA-Serial1/0/0] link-protocol ppp
[RouterA-Serial1/0/0] ip address 10.10.10.9 30
# Set the PPP authentication mode to PAP authentication and specify an authentication
domain named system.
[RouterA-Serial1/0/0] ppp authentication-mode pap domain system

[RouterA-Serial1/0/0] quit
# Configure a local user and specify the authentication domain for the local user.
[RouterA] aaa
[RouterA-aaa] authentication-scheme system_a
[RouterA-aaa-authen-system_a] authentication-mode local
[RouterA-aaa-authen-system_a] quit
[RouterA-aaa] domain system
[RouterA-aaa-domain-system] authentication-scheme system_a
[RouterA-aaa-domain-system] quit
[RouterA-aaa] local-user user1@system password cipher huawei
[RouterA-aaa] local-user user1@system service-type ppp
[RouterA-aaa] quit
2. Configure RouterB
[RouterB] interface serial 1/0/0
[RouterB-Serial1/0/0] link-protocol ppp
[RouterB-Serial1/0/0] ip address 10.10.10.10 30
# Configure the user name and password sent from RouterB to RouterA in PAP authentication.
[RouterB-Serial1/0/0] ppp pap local-user user1@system password simple huawei
Run the display interface serial 1/0/0 command to check the interface configuration. The
command output shows that both the physical layer status and link layer status of the
interface are Up and that both LCP and IPCP are in Opened state. This indicates that PPP
negotiation
succeeds and that RouterA and RouterB can ping each other successfully.
[Huawei] display interface serial 1/0/0

Serial1/0/0 current state : UP
Description:HUAWEI, AR Series, Serial1/0/0 Interface
Route Port,The Maximum Transmit Unit is 1500, Hold timer is
0(sec) Internet Address is 10.10.10.9/30
Link layer protocol is PPP
LCP opened, IPCP opened
1210
Physical layer is synchronous, Virtualbaudrate is 64000 bps
Interface is DTE, Cable type is V35, Clock mode is RC
Last 10 seconds input rate 7 bytes/sec 56 bits/sec 0 packets/sec
Last 10 seconds output rate 7 bytes/sec 56 bits/sec 0
packets/sec Input: 7343762 packets, 463499285 bytes
broadcasts: 0, multicasts: 0
errors: 0, runts: 0, giants: 0
CRC: 0, align errors: 0, overruns: 0
dribbles: 0, aborts: 0, no buffers: 0
frame errors: 0
errors: 0, underruns: 0, collisions: 0
deferred: 0
DCD=UP DTR=UP DSR=UP RTS=UP CTS=UP

Configuration Files
#
sysname RouterA
#
aaa
authentication-scheme system_a
domain system
local-user user1@system password cipher %$%$04b=C9LzqIsL.w)N+pU<,g^U%$%$
local-user user1@system service-type ppp
#
interface Serial1/0/0
link-protocol ppp
ppp authentication-mode pap domain system
ip address 10.10.10.9 255.255.255.252
#
return
#
sysname RouterB
#
link-protocol ppp
ppp pap local-user user1@system password simple
huawei ip address 10.10.10.10 255.255.255.252
#
return
9.5.2 Example for Configuring Unidirectional CHAP Authentication (Local
Authentication) Networking Requirements
As shown in Figure 9-5-2, Serial1/0/0 of RouterA connects to Serial1/0/0 of RouterB.
Users want that RouterA performs reliable authentication on RouterB while RouterB does
not authenticate RouterA.
Figure 9-5-2 Networking diagram of CHAP authentication
1. Configure CHAP authentication and the user name for CHAP authentication because CHAP
authentication meets user's requirements of reliable authentication and high security.
2. Configure RouterA as the CHAP authenticator and RouterB as the CHAP authenticated party
to meet the unidirectional authentication requirement.
Procedure
1. Configure RouterA.
[RouterA-Serial1/0/0] link-protocol ppp
[RouterA-Serial1/0/0] ip address 10.10.10.9 30
# Set the PPP authentication mode to CHAP authentication, user name to user1@system, and
authentication domain to system.
[RouterA-Serial1/0/0] ppp authentication-mode chap domain system

[RouterA-Serial1/0/0] ppp chap user user1@system
# Configure a local user and specify the authentication domain for the local user.
[RouterA] aaa
[RouterA-aaa] local-user user2@system password cipher huawei
[RouterA-aaa] local-user user2@system service-type ppp
[RouterA-aaa] quit
2. Configure RouterB.
[RouterB-Serial1/0/0] link-protocol ppp
[RouterB-Serial1/0/0] ip address 10.10.10.10 30
# Configure the user name and password sent from RouterB to RouterA in CHAP
authentication.
[RouterB-Serial1/0/0] ppp chap user user2@system
# Configure a local user.
[RouterB] aaa
[RouterB-aaa] local-user user1@system password cipher huawei
[RouterB-aaa] local-user user1@system service-type ppp
[RouterB-aaa] quit
Run the display interface serial 1/0/0 command to check the interface configuration. The
command output shows that both the physical layer status and link layer status of the
interface are Up and that both LCP and IPCP are in Opened state. This indicates that PPP
negotiation succeeds and that RouterA and RouterB ping each other successfully.

1210
[Huawei] display interface serial 1/0/0
Serial1/0/0 current state : UP
Description:HUAWEI, AR Series, Serial3/0/0 Interface
Route Port,The Maximum Transmit Unit is 1500, Hold timer is
10(sec) Internet Address is 10.10.10.9/30
Physical layer is synchronous, Virtualbaudrate is 64000 bps
Interface is DTE, Cable type is V35, Clock mode is TC
Last 300 seconds input rate 8 bytes/sec 64 bits/sec 0 packets/sec
Last 300 seconds output rate 7 bytes/sec 56 bits/sec 0
packets/sec Input: 20239 packets, 465621 bytes
Broadcast:
Errors:
Giants:
Alignments:
Dribbles:
No Buffers:

Total Error:
Collisions:
DCD=UP DTR=UP DSR=UP RTS=UP CTS=UP

Configuration Files
#
sysname RouterA
#
aaa
domain system
#
link-protocol ppp
ppp authentication-mode chap domain system
ppp chap user user1@syst em
ip address 10.10.10.9 255.255.255.252
#
return
#
sysname RouterB
#
aaa
#
link-protocol ppp
ip address 10.10.10.10 255.255.255.252
#
return
9.5.3 Example for Implementing MP by Binding PPP Links to a
VT Networking Requirements
As shown in Figure 9-5-3, serial interfaces on RouterA respectively connects to the serial interfaces on
RouterB.
On a large-scale enterprise network, a single link cannot transmit a large volume of service traffic.
Users want to increase bandwidth to ensure data transmission in a simple way and do not require
high security.
Figure 9-5-3 Networking diagram for implementing MP by binding PPP links to a VT
1. Bind PPP links into an MP-Group to increase data transmission bandwidth.

2. Directly bind PPP links to a VT to implement MP in a simple way.
3. PPP authentication is not required because users do not require high security.
Procedure
# Create and configure a VT interface.
[RouterA] interface virtual-template 1
[RouterA-Virtual-Template1] ip address 10.10.10.9 30
[RouterA-Virtual-Template1] quit
# Bind Serial1/0/0 and Serial1/0/1 to the VT interface so that the physical interfaces work in
MP mode.

[RouterA-Serial1/0/0] ppp mp virtual-template 1
[RouterA-Serial1/0/0] restart
[RouterA-Serial1/0/1] ppp mp virtual-template 1
# Create and configure a VT interface.
[RouterB] interface virtual-template 1
[RouterB-Virtual-Template1] ip address 10.10.10.10 30
[RouterB-Virtual-Template1] quit
# Bind Serial1/0/0 and Serial1/0/1 to the VT interface so that the physical interfaces work in
MP mode.

[RouterB-Serial1/0/0] ppp mp virtual-template 1
[RouterB-Serial1/0/0] restart
[RouterB-Serial1/0/0] quit
[RouterB-Serial1/0/1] ppp mp virtual-template 1
[RouterB-Serial1/0/1] restart
# Run the display ppp mp command on RouterA to view the MP binding information.
[RouterA] display ppp mp

Template is Virtual-Template1
Bundle 10cd6d925ac6, 2 members, slot 0, Master link is Virtual-Template1:0
0 lost fragments, 0 reordered, 0 unassigned, 0
interleaved, sequence 0/0 rcvd/sent
The bundled sub channels are:
Serial1/0/0
Serial1/0/1
Bundle 10cd6d925ac6 indicates that the MP binding is implemented using a VT interface.

10cd6d925ac6 is the endpoint discriminator of the remote device. The MP link contains
two links Serial1/0/0 and Serial1/0/1.
# Run the display virtual-access command on RouterA to view the VA interface status.
[RouterA] display virtual-access

Virtual-Template1:0 current state : UP
Description:HUAWEI, AR Series, Virtual-Template1:0 Interface
LCP opened, MP opened, IPCP opened
Physical is MP
Realtime 0 seconds input rate 0 bits/sec, 0 packets/sec
Realtime 0 seconds output rate 0 bits/sec, 0 packets/sec
Input: 0 packets,0 bytes
0 unicast,0 broadcast,0 multicast
0 errors,0 unknownprotocol
Output:0 packets,0 bytes
0 unicast,0 broadcast,0 multicast
0 errors
You can obtain similar MP binding information on RouterB.
# Ping RouterA on RouterB.
[RouterB] ping 10.10.10.9

ms Reply from 10.10.10.9: bytes=56 Sequence=2 ttl=255
time=50 ms Reply from 10.10.10.9: bytes=56 Sequence=3
ttl=255 time=50 ms
ms

0.00% packet loss
RouterB can ping RouterA successfully.
Configuration Files
#
sysname RouterA
#
interface serial 1/0/0
link-protocol ppp
ppp mp Virtual-Template 1
#
link-protocol ppp
#
interface Virtual-Template1
ip address 10.10.10.9 255.255.255.252
#
return
#
sysname RouterB
#
link-protocol ppp
#
link-protocol ppp
#
ip address 10.10.10.10 255.255.255.252
#
return
9.5.4 Example of Implementing MP by Binding PPP Links to an MP-Group
As shown in Figure 9-5-4, serial interfaces on RouterA respectively connects to the serial interfaces on
RouterB.
On a large-scale enterprise network, a single link cannot transmit a large volume of service traffic.
Users want to increase bandwidth to ensure data transmission in a simple and quick way and
require high data security.
Figure 9-5-4 Networking diagram of implementing MP by adding a PPP link to the MP-Group
1. Bind PPP links to an MP-Group interface to implement MP in a simple and quick way and
to increase data transmission bandwidth.
2. Configure bidirectional CHAP authentication on physical interfaces to ensure high security.
Procedure
# Create and configure an MP-Group interface.

sysname RouterA [RouterA]
interface mp-group 0/0/1
[RouterA-Mp-group0/0/1] ip address 100.10.10.9 30
[RouterA-Mp-group0/0/1] quit
# Add Serial1/0/0 and Serial1/0/1 to the MP-Group interface and use CHAP
authentication. Configure the local user if the device functions as the authenticator, or the
user name and
password for CHAP authentication if the device functions as the authenticated party.
[RouterA] aaa
[RouterA-aaa] local-user userb password
Please configure the login password (8-128)
It is recommended that the password consist of at least 2 types of characters,
i ncluding lowercase letters, uppercase letters, numerals and special
characters. Please enter password:
Please confirm password:
Info: Add a new user.
Warning: The new user supports all access modes. The management user access
mode s such as Telnet, SSH, FTP, HTTP, and Terminal have security risks. You are
advi
sed to configure the required access modes only.
[RouterA-aaa] local-user userb service-type ppp
[RouterA-aaa] quit
[RouterA-Serial1/0/0] ppp chap user usera
[RouterA-Serial1/0/0] ppp chap password cipher usera@123
[RouterA-Serial1/0/0] ppp mp mp-group 0/0/1
[RouterA-Serial1/0/1] ppp chap user usera
[RouterA-Serial1/0/1] ppp chap password cipher usera@123
[RouterA-Serial1/0/1] ppp mp mp-group 0/0/1
# Create and configure an MP-Group interface.

sysname RouterB [RouterB]
interface mp-group 0/0/1
[RouterB-Mp-group0/0/1] ip address 100.10.10.10 30
[RouterB-Mp-group0/0/1] quit
# Add Serial1/0/0 and Serial1/0/1 to the MP-Group interface and use CHAP
authentication. Configure the local user if the device functions as the authenticator, or the
user name and
password for CHAP authentication if the device functions as the authenticated party.
[RouterB] aaa
[RouterB-aaa] local-user usera password
Please configure the login password (8-128)
It is recommended that the password consist of at least 2 types of characters,
i ncluding lowercase letters, uppercase letters, numerals and special
characters. Please enter password:
Please confirm password:
Info: Add a new user.
Warning: The new user supports all access modes. The management user access
mode s such as Telnet, SSH, FTP, HTTP, and Terminal have security risks. You are
advi
sed to configure the required access modes only.
[RouterB-aaa] local-user usera service-type ppp
[RouterB-aaa] authentication-scheme system_b
[RouterB-aaa-authen-system_b] authentication-mode local
[RouterB-aaa-authen-system_b] quit
[RouterB-aaa] domain system
[RouterB-aaa-domain-system] authentication-scheme system_b
[RouterB-aaa-domain-system] quit
[RouterB-aaa] quit
[RouterB-Serial1/0/0] ppp authentication-mode chap domain system
[RouterB-Serial1/0/0] ppp chap user userb
[RouterB-Serial1/0/0] ppp chap password cipher userb@123
[RouterB-Serial1/0/0] ppp mp mp-group 0/0/1
[RouterB-Serial1/0/1] ppp authentication-mode chap domain system
[RouterB-Serial1/0/1] ppp chap user userb
[RouterB-Serial1/0/1] ppp chap password cipher userb@123
[RouterB-Serial1/0/1] ppp mp mp-group 0/0/1
3. Restart member interfaces on RouterA.

4. Restart member interfaces on RouterB. Use the commands in step 3 to restart

member interfaces.
NOTE:
To make the configuration take effect, restart all the member interfaces after the configuration
is complete.

# Run the display ppp mp command on RouterA to view the MP binding information.
[RouterA] display ppp mp interface Mp-group 0/0/1

Mp-group is Mp-group0/0/1
===========Sublinks status begin======
Serial1/0/0 physical UP,protocol UP
Serial1/0/1 physical UP,protocol UP
===========Sublinks status end========
Bundle Multilink, 2 members, slot 0, Master link is Mp-group0/0/1
0 lost fragments, 0 reordered, 0 unassigned, 0
interleaved, sequence 0/0 rcvd/sent
The bundled sub channels are:
Serial1/0/0
Serial1/0/1
The command output provides the physical status and protocol status of member lin ks,
the number of member links, and member interfaces of the MP-Group interface.
# Run the display interface mp-group command on RouterA to view the MP

binding information.
[RouterA] display interface mp-group 0/0/1

Mp-group0/0/1 current state : UP
Description:HUAWEI, AR Series, Mp-group0/0/1 Interface
LCP opened, MP opened, IPCP opened
Physical is MP, baudrate is 64000 bps
Last 300 seconds input rate 0 bytes/sec, 0 packets/sec
Last 300 seconds output rate 0 bytes/sec, 0 packets/sec
Realtime 0 seconds input rate 0 bytes/sec, 0 packets/sec
Realtime 0 seconds output rate 0 bytes/sec, 0 packets/sec
6 packets input, 84 bytes, 0 drops
6 packets output, 84 bytes, 0 drops
As shown in the preceding information, the MP-Group interface is Up, the link layer
protocol is PPP, and the status of LCP negotiation, MP negotiation, and IPCP negotiation is
Opened.
1210
You can obtain similar MP binding information on RouterB.
# Ping RouterA on RouterB.
[RouterB] ping 100.10.10.9


0.00% packet loss
RouterB can ping RouterA successfully.
Configuration Files
#
sysname RouterA
#
aaa
domain system
local-user userb password cipher %@%@3k`38}:/##N~BmPHev|;;rdS%@%@
local-user userb service-type ppp
#
interface Mp-group0/0/1
ip address 100.10.10.9 255.255.255.252
#
link-protocol ppp
ppp chap user usera
ppp chap password cipher %@%@57:3#5ir.Q.zAI4:=pJY*a@E%@%@
ppp mp mp-group 0/0/1
#
link-protocol ppp
ppp chap user usera
ppp chap password cipher %@%@57:3#5ir.Q. zAI5:=pJY*a@E%@%@
#
return
#
sysname RouterB
#
aaa
authentication-scheme system_b
domain system
authentication-scheme system_b
local-user usera password cipher %@%@wSj=##g9INJIZ$Ip'6f7;rd!%@ %@
local-user usera service-type ppp
#
interface Mp-group0/0/1
ip address 100.10.10.10 255.255.255.252
#
link-protocol ppp
ppp chap user userb
#
link-protocol ppp
ppp chap user userb
#
return
9.5.5 Example for Configuring the PPPoE Server
As shown in Figure 9-5-5, hosts in the LAN are connected to the device functioning as the PPPoE
server. Hosts on the enterprise network need to dial up to the Internet using PPPoE.
PPPoE client software needs to be installed on each host so that the host can use a unique account
to dial up to the Internet. Service requirements are as follows:
 The PPPoE server dynamically assigns IP addresses to the hosts.
 The PPPoE server uses AAA local authentication to authenticate users.
Figure 9-5-5 Networking diagram of the device functioning as the PPPoE server
1. Configure the global IP address pool so that the PPPoE server can dynamically assign IP
addresses to hosts.
2. Configure a PPPoE user so that the PPPoE server can authenticate the user.
Procedure
1. Configure the global IP address pool pool1.
[Huawei] ip pool pool1
[Huawei-ip-pool-pool1] network 192.168.10.10 mask 255.255.255.0
[Huawei-ip-pool-pool1] gateway-list 192.168.10.1
[Huawei-ip-pool-pool1] quit
2. Create and configure a VT.
[Huawei] interface virtual-template 1
[Huawei-Virtual-Template1] ppp authentication-mode chap domain system
[Huawei-Virtual-Template1] ip address 192.168.10.1 255.255.255.0
[Huawei-Virtual-Template1] remote address pool pool1
[Huawei-Virtual-Template1] quit
3. Enable PPPoE on GE1/0/0 of the PPPoE server.
[Huawei] interface gigabitethernet 1/0/0

[Huawei-GigabitEthernet1/0/0] pppoe-server bind virtual-template 1
[Huawei-GigabitEthernet1/0/0] quit
4. Configure a PPPoE user.
[Huawei] aaa
[Huawei-aaa] authentication-scheme system_a
[Huawei-aaa-authen-system_a] authentication-mode local
[Huawei-aaa-authen-system_a] quit
[Huawei-aaa] domain system
[Huawei-aaa-domain-system] authentication-scheme system_a
[Huawei-aaa-domain-system] quit
[Huawei-aaa] local-user user1@system password cipher huawei
[Huawei-aaa] local-user user1@system service-type ppp
[Huawei-aaa] quit
After the configurations are complete, verify the configurations on both the PPPoE server
and client.
a. PPPoE client
Install PPPoE client software on a host and configure the user name user1@system
and password huawei on the host. Dial up to the PPPoE server.
b. PPPoE server
Run the display pppoe-server session all command to check the PPPoE session status
and configuration. The following command output shows that the PPPoE session
status
is Up and the session configuration is correct.
<Huawei> display pppoe-server session all

SID Intf State OIntf RemMAC
LocMAC
10 Virtual-Template1:0 UP GE1/0/0 0011.0914.1bd3
00e0.fc99.9999
Run the display virtual-access command to view the VA status. The LCP and IPCP
negotiation status is Opened.
<Huawei> display virtual-access

Virtual-Template1:0 current state : UP
Description:HUAWEI, AR Series, Virtual-Template1:0 Interface
Configuration Files
 Configuration file of the PPPoE server
#
ip pool pool1
network 192.168.10.0 mask 255.255.255.0
gateway-list 192.168.10.1
#
aaa
domain system
#
remote address pool pool1
ip address 192.168.10.1 255.255.255.0
#
pppoe-server bind Virtual-Template 1
#
return
9.5.6 Example for Configuring the PPPoE Client
As shown in Figure 9-5-6, the device functioning as the PPPoE client connects to hosts in the LAN
using GE1/0/0 and connects to the PPPoE server using GE2/0/0.
Users want the hosts to share an account. If the account is authenticated successfully on the PPPoE
server, a PPPoE session is established. Service requirements are as follows:
 The device establishes a PPPoE session with the PPPoE server using PPP authentication.
 When no data needs to be transmitted within the specified period, the PPPoE client terminates
the PPPoE session. When data needs to be transmitted, the PPPoE client establishes a PPPoE
session with the PPPoE server again.
Figure 9-5-6 Networking diagram of the device functioning as the PPPoE client
1. Configure Challenge Handshake Authentication Protocol (CHAP) authentication on the

dialer interface so that the device can establish a PPPoE session with the PPPoE server using
PPP authentication.
2. Set the packet triggered mode so that the PPPoE client terminates the PPPoE session when
no data is transmitted within the specified period and establishes the PPPoE session again
when data needs to be transmitted.
Procedure
1. Configure the PPPoE server.

Configure the authentication mode, IP address allocation mode, and IP address or IP address
pool for the PPPoE client. For details about the configuration procedure, see the
documentation of the PPPoE server. If the device functions as the PPPoE server, see Example
for Configuring the PPPoE Server.
2. Configure a dialer interface.
[Huawei] dialer-rule
[Huawei-dialer-rule] dialer-rule 1 ip permit
[Huawei-dialer-rule] quit [Huawei]
interface dialer 1 [Huawei-
Dialer1] dialer user user2
[Huawei-Dialer1] dialer-group 1
[Huawei-Dialer1] dialer bundle 1
[Huawei-Dialer1] ppp chap user user1@system
[Huawei-Dialer1] ppp chap password cipher huawei
[Huawei-Dialer1] dialer timer idle 300
INFO: The configuration will become effective after link reset.
[Huawei-Dialer1] dialer queue-length 8
[Huawei-Dialer1] ip address ppp-negotiate
[Huawei-Dialer1] quit
3. Create a PPPoE session.
[Huawei] interface gigabitethernet 2/0/0

[Huawei-GigabitEthernet2/0/0] pppoe-client dial-bundle-number 1 on-demand
[Huawei-GigabitEthernet2/0/0] quit
4. Configure a static route from the local host to the PPPoE server.
Assume that the IP address of the PPPoE server is 10.10.10.3.
[Huawei] ip route-static 0.0.0.0 0 dialer 1
Run the display pppoe-client session summary command to check the PPPoE session
status and configuration. The following command output shows that the PPPoE session
status is Up
and the session configuration is correct.
<Huawei> display pppoe-client session summary

PPPoE Client Session:
ID Bundle Dialer Intf
1 1 1 GE2/0/0
Configuration Files
 Configuration file of the PPPoE client
#
dialer-rule
dialer-rule 1 ip permit
#
interface Dialer1
link-protocol ppp
ip address ppp-negotiate
dialer user user2
ppp chap password cipher huawei
dialer bundle 1
dialer queue-length 8
dialer timer idle 300
dialer-group 1
#
pppoe-client dial-bundle-number 1 on-demand
#
ip route-static 0.0.0.0 0.0.0.0 Dialer1
#
return
9.5.7 Example for Configuring IPoFR
On the FR network, RouterA, RouterB, and RouterC function as DTEs to transmit IP packets. A public
FR network connects local area networks (LANs).
Figure 9-5-7 Example for configuring IPoFR (single link)
1. Configure FR as the link-layer protocol on the router.
2. Set the operation mode of the interface connecting the router to the public FR network.
3. Configure the virtual circuit ID for each network segment.
4. Configure address mapping for each sub-interface.
Procedure
1. Configure routerRouterA.
# Configure FR as the link-layer protocol on the interface.
[RouterA-Serial1/0/0] link-protocol fr
Warning: The encapsulation protocol of the link will be changed. Continue? [Y/N]
:y
[RouterA-Serial1/0/0] fr interface-type dte
# Configure static address mapping.
[RouterA] interface serial 1/0/0.1

[RouterA-Serial1/0/0.1] fr dlci 50
[RouterA-fr-dlci-Serial1/0/0.1-50] quit
[RouterA-Serial1/0/0.1] ip address 202.38.163.251 24
[RouterA-Serial1/0/0.1] fr map ip 202.38.163.252 50
[RouterA-Serial1/0/0.1] quit
[RouterA] interface serial 1/0/0.2
[RouterA-Serial1/0/0.2] fr dlci 60
[RouterA-fr-dlci-Serial1/0/0.2-60] quit
[RouterA-Serial1/0/0.2] ip address 202.38.164.251 24
[RouterA-Serial1/0/0.2] fr map ip 202.38.164.252 60
[RouterA-Serial1/0/0.2] quit
2. Configure routerRouterB.
[RouterB-Serial1/0/0] link-protocol fr
:y
[RouterB-Serial1/0/0] fr interface-type dte
[RouterB] interface serial 1/0/0.1

[RouterB-Serial1/0/0.1] fr dlci 70
[RouterB-fr-dlci-Serial1/0/0.1-70] quit
[RouterB-Serial1/0/0.1] ip address 202.38.163.252 24
[RouterB-Serial1/0/0.1] fr map ip 202.38.163.251 70
[RouterB-Serial1/0/0.1] quit
3. Configure routerRouterC.
[Huawei] sysname RouterC
[RouterC] interface serial 1/0/0
[RouterC-Serial1/0/0] link-protocol fr
:y
[RouterC-Serial1/0/0] fr interface-type dte
[RouterC-Serial1/0/0] quit

1210
[RouterC] interface serial 1/0/0.1

[RouterC-Serial1/0/0.1] fr dlci 80
[RouterC-fr-dlci-Serial1/0/0.1-80] quit
[RouterC-Serial1/0/0.1] ip address 202.38.164.252 24
[RouterC-Serial1/0/0.1] fr map ip 202.38.164.251 80
[RouterC-Serial1/0/0.1] quit
RouterA can ping the interface of RouterB.
[RouterA] ping 202.38.164.252

--- 202.38.164.252 ping statistics ---
0.00% packet loss
RouterB can ping the interface of RouterA. RouterA and RouterC can ping each other.
Configuration Files
#
sysname RouterA
#
link-protocol fr
#
interface Serial1/0/0.1
fr map ip 202.38.163.252 50
fr dlci 50
ip address 202.38.163.251 255.255.255.0
#
fr map ip 202.38.164.252 60
fr dlci 60
ip address 202.38.164.251 255.255.255.0
#
return
#
sysname RouterB
#
link-protocol fr
#
fr map ip 202.38.163.251 70
fr dlci 70
ip address 202.38.163.252 255.255.255.0
#
return
#
sysname RouterC
#
link-protocol fr
#
fr map ip 202.38.164.251 80
fr dlci 80
ip address 202.38.164.252 255.255.255.0
#
return
Chapter 10 STP
10.1 STP/RSTP
10.1.1 Background
STP is used to prevent loops in the LAN. The switching devices running STP discover loops on
the network by exchanging information with one another, and block certain interfaces to cut off
loops. Along with the growth of the LAN scale, STP has become an important protocol for the
LAN.
Figure 10-1-1 Networking diagram for a typical LAN

On the network shown in Figure 10-1-1, the following situations may occur:
 Broadcast storms render the network unavailable.
It is known that loops lead to broadcast storms. In Figure 10-1-1, assume that STP is not
enabled on the switching devices. If Host A broadcasts a request, the request is received by port
1 and forwarded by port 2 on S1 and S2. Then, again on S1 and S2, port 2 receives the request
broadcast by the other and port 1 forwards the request. As such transmission repeats, resources
on the entire network are exhausted, causing the network unable to work.
 Flapping of MAC address table damages MAC address entries.
As shown in Figure 10-1-1, even update of MAC address entries upon the receipt of
unicast packets damages the MAC address table.
Assume that no broadcast storm occurs on the network. Host A unicasts a packet to Host B. If
Host B is temporarily removed from the network at this time, the MAC address entries of Host B
on S1 and S2 are deleted. The packet unicast by Host A to Host B is received by port 1 on S1.
S1, however, does not have associated MAC address entries. Therefore, the unicast packet is
forwarded to port 2. Then, port 2 on S2 receives the unicast packet from port 2 on S1 and sends it
out through port 1. As such transmission repeats, port 1 and port 2 on S1 and S2 continuously
receive unicast packets from Host A. Therefore, S1 and S2 modify the MAC address entries
continuously, causing the MAC address table to flap. As a result, MAC address entries
are damaged.
One Root Bridge
A tree topology must have a root. Therefore, the root bridge is introduced by STP.
There is only one root bridge on the entire STP-capable network. The root bridge is the logical
center of but is not necessarily at the physical center of the entire network. The root bridge changes
dynamically with the network topology.
After the network converges, the root bridge generates and sends out configuration BPDUs at
specific intervals. Other devices process the configuration BPDUs so that the configuration BPDUs
are advertised to the entire network, ensuring a stable network.
Two Types of Measurements
The spanning tree is calculated based on two types of measurements: ID and path cost.
 ID
IDs are classified into Bridge IDs (BIDs) and Port IDs (PIDs).
 BID
IEEE 802.1D defines that a BID is composed of a 16-bit bridge priority and a bridge
MAC address. The bridge priority occupies the leftmost 16 bits and the MAC address
occupies the rightmost 48 bits.
On an STP-capable network, the device with the smallest BID is selected to be the
root bridge.
 PID
The PID is composed of a 4-bit port priority and a 12-bit port number. The port
priority occupies the left most 4 bits and the port number occupies remaining bits on
the right.
The PID is used to select the designated port.

NOTE:
The port priority affects the role of a port in a specified spanning tree instance. For
details, see STP Topology Calculation.
 Path cost
The path cost is a port variable and is used to select a link. STP calculates the path cost to select
a robust link and blocks redundant links to trim the network into a loop-free tree topology.
On an STP-capable network, the accumulative cost of the path from a certain port to the
root bridge is the sum of the costs of all the segment paths into which the path is separated
by the ports on the transit bridges.
Three Elements
There are generally three elements used when a ring topology is to be trimmed into a tree topology:
root bridge, root port, and designated port. Figure 10-1-2 shows the three elements.
Figure 10-1-2 STP network architecture
 Root bridge
The root bridge is the bridge with the smallest BID. The smallest BID is discovered
by exchanging configuration BPDUs.
 Root port
The root port is the port with the smallest root path to the root bridge. The root port is
determined based on the path cost. Among all STP-capable ports on a network bridge, the port
with the smallest root path cost is the root port. There is only one root port on an STP-capable
device, but there is no root port on the root bridge.
 Designated port
For description of the designated bridge and designated port, see Table 10-1-1.
Table 10-1-1 Description of the designated bridge and designated port

Object
Device
LAN
As shown in Figure 10-1-3, AP1 and AP2 reside on S1; BP1 and BP2 reside on S2; CP1 and
CP2 reside on S3.
 S1 sends configuration BPDUs to S2 through AP1. S1 is the designated bridge of S2, and
AP1 on S1 is the designated port.
 Two devices, S2 and S3, are connected to the LAN. If S2 is responsible for forwarding
configuration BPDUs to the LAN, S2 is the designated bridge of the LAN and BP2 on
S2 is the designated port.
Figure 10-1-3 Networking diagram of the designated bridge and designated port
After the root bridge, root port, and designated port are selected successfully, the entire tree topology
is set up. When the topology is stable, only the root port and the designated port forward traffic. All
the other ports are in the Blocking state and receive only STP protocol packets instead of forwarding
user traffic.
Four Comparison Principles
STP has four comparison principles that form a BPDU priority vector { root BID, total path
costs, sender BID, port ID }.
Table 10-1-2 shows the port information that is carried in the configuration BPDUs.
Table 10-1-2 Four important fields
Root BID
Root path cost
Sender BID
Port ID
After a device on the STP-capable network receives configuration BPDUs, it compares the fields
shown in Table 10-1-2 with that of the configuration BPDUs on itself. The four comparison
principles are as follows:
NOTE:
During the STP calculation, the smaller the value, the higher the priority.
 Smallest BID: used to select the root bridge. Devices running STP select the smallest BID as
the root BID shown in Table 10-1-2.
 Smallest root path cost: used to select the root port on a non-root bridge. On the root bridge,
the path cost of each port is 0.
 Smallest sender BID: used to select the root port when a device running STP selects the root
port between two ports that have the same path cost. The port with a smaller BID is selected as
the root port in STP calculation. Assume that the BID of S2 is smaller than that of S3 in Figure
10-1-2. If the path costs in the BPDUs received by port A and port B on S4 are the same, port B
becomes the root port.
 Smallest PID: used to block the port with a greater PID but not the port with a smaller PID when
the ports have the same path cost. The PIDs are compared in the scenario shown in Figure 10-1-
4. The PID of port A on S1 is smaller than that of port B. In the BPDUs that are received on port
A and port B, the path costs and BIDs of the sending devices are the same. Therefore, port B with
a greater PID is blocked to cut off loops.
Figure 10-1-4 Topology to which PID comparison is applied
Five Port States
Table 10-1-3 shows the port status of an STP-capable device.
Table 10-1-3 Port states
Port State Purpose Description

Forwarding A port in Forwarding state can Only the root port and designated port can
forward user traffic and process BPDUs. enter the Forwarding state.
Learning When a device has a port in the Learning This is a transitional state, which is
state, the device creates a MAC address designed to prevent temporary loops.
table based on the received user traffic but
does not forward user traffic.
Listening All ports are in the Listening state This is a transitional state.
when STP calculation is being
implemented to determine port roles.
Blocking A port in the Blocking state receives This is the final state of a blocked port.
and forwards only BPDUs, not user traffic.
Disabled A port in Disabled state does not process The port is Down.
BPDUs or forward user traffic.
Figure 10-1-5 shows the process of the state transition of a port.

Figure 10-1-5 State transition of a port
CAUTION:
A Huawei datacom device uses MSTP by default. After a device transitions from the MSTP mode
to the STP mode, its STP-capable port supports the same port states as those supported by
an MSTP-capable port, including the Forwarding, Learning, and Discarding states. For details, see
Table
10-1-4.
Table 10-1-4 Port status
Port
Status
Forwarding A port in Forwardin
Learning A port in the Learni

address table.
A port in Learning s
Discarding A port in the Discar
The following parameters affect the STP-capable port states and convergence.
 Hello time
The Hello timer specifies the interval at which an STP-capable device sends configuration
BPDUs and Hello packets to detect link faults.
When the network topology becomes stable, the change made on the interval takes effect
only after a new root bridge takes over. The new root bridge adds certain fields in BPDUs to
inform non-root bridges of the change in the interval. After a topology changes, TCN BPDUs
will be sent. This interval is irrelevant to the transmission of TCN BPDUs.
 Forward Delay
The Forward Delay timer specifies the delay for interface status transition. When a link fault
occurs, STP recalculation is performed, causing the structure of the spanning tree to change.
The configuration BPDUs generated during STP recalculation cannot be immediately
transmitted
over the entire network. If the root port and designated port forward data immediately after
being selected, transient loops may occur. Therefore, an interface status transition mechanism is
introduced by STP. The newly selected root port and designated port do not forward data un til
an amount of time equal to twice the forward delay has past. In this manner, the newly generated
BPDUs can be transmitted over the network before the newly selected root port and designated
port forward data, which prevents transient loops.
NOTE:
The Forward Delay timer specifies the duration of a port spent in both the Listening and
Learning states. The default value is 15 seconds. This means that the port stays in the Listening
state for 15 seconds and then stays in the Learning state for another 15 seconds. The port in the
Listening or Learning state is blocked, which is key to preventing transient loops.
 Max Age
The Max Age time specifies the aging time of BPDUs. The Max Age time can be
manually configured on the root bridge.
Configuration BPDUs are transmitted over the entire network, ensuring a unique Max Age
value. After a non-root bridge running STP receives a configuration BPDU, the non-root
bridge compares the Message Age value with the Max Age value in the received configuration
BPDU.
 If the Message Age value is smaller than or equal to the Max Age value, the non-
root bridge forwards the configuration BPDU.
 If the Message Age value is larger than the Max Age value, the configuration BPDU ages
and the non-root bridge directly discards it. In this case, the network size is considered
too large and the non-root bridge disconnects from the root bridge.
NOTE:
If the configuration BPDU is sent from the root bridge, the value of Message Age is 0.
Otherwise, the value of Message Age indicates the total time during which a BPDU is sent
from the root bridge to the local bridge, including the delay in transmission. In real world
situations, each time a configuration BPDU passes through a bridge, the value of Message Age
increases by 1.
Table 10-1-5 shows the timer values defined in IEEE 802.1D.
Table 10-1-5 Values of STP parameters (in centisecond)

1210
Parameter Default Value Value Range

1210
Table 10-1-5 Values of STP parameters (in centisecond)
Parameter
Hello time
Max Age
Forward Delay
10.1.3 BPDU Format
The BID, path cost, and PID that are described in the previous sections are all carried in BPDUs.
 Configuration BPDUs are heartbeat packets. STP-enabled designated ports send BPDUs
at intervals specified by the Hello timer.
 TCN BPDUs are sent only after the device detects network topology changes.
A BPDU is encapsulated into an Ethernet frame. Its destination MAC address is a multicast MAC
address 01-80-C2-00-00-00. The value of the Length/Type field is the MAC data length. The
Length/Type field is followed by the LLC header and BPDU header. Figure 10-1-6 shows the
Ethernet frame format.
Figure 10-1-6 Format of an Ethernet frame
Configuration BPDU
Configuration BPDUs are most commonly used.
During initialization, each bridge actively sends configuration BPDUs. After the network topology
becomes stable, only the root bridge actively sends configuration BPDUs. Other bridges send
configuration BPDUs only after receiving configuration BPDUs from upstream devices. A
configuration BPDU is at least 35 bytes long, including the parameters such as the BID, path cost,
and PID. A BPDU is discarded if both the sender BID and Port ID field values are the same as those
of the local port. Otherwise, the BPDU is processed. In this manner, BPDUs containing the same
information as that of the local port are not processed.
A configuration BPDU is generated in one of the following scenarios:
 Once the ports are enabled with STP, the designated ports send configuration BPDUs at
intervals specified by the Hello timer.
 When a root port receives configuration BPDUs, the device where the root port resides sends
a copy of the configuration BPDUs to the specified ports on itself.
 When receiving a configuration BPDU with a lower priority, a designated port immediately
sends its own configuration BPDUs to the downstream device.
Table 10-1-6 shows the format of a BPDU.
Table 10-1-6 BPDU format
Field
Protocol Identifier
Protocol Version
Identifier
BPDU Type
Flags
Root Identifier
Root Path Cost
Bridge Identifier
Port Identifier
Message Age
Max Age
Hello Time
Forward Delay
Figure 10-1-7 shows the Flags field. Only the leftmost and rightmost bits are used in STP.
Figure 10-1-7 Format of the Flags field
TCN BPDU
The contents of TCN BPDUs are quite simple, including only three fields: Protocol ID, Version,
and
Type, as shown in Table 10-1-6. The value of the Type field is 0x80, four bytes in
length.
TCN BPDUs are transmitted by each device to its upstream device to notify the upstream device of
changes in the downstream topology, until they reach the root bridge. A TCN BPDU is generated in
one of the following scenarios:
 Where the port is in the Forwarding state and at least one designated port resides on the device
 Where a designated port receives TCN BPDUs and sends a copy to the root bridge
10.1.4 STP Topology Calculation
After all devices on the network are enabled with STP, each device considers itself the root bridge.
Each device only transmits and receives BPDUs but does not forward user traffic. All ports are in
the Listening state. After exchanging configuration BPDUs, all devices participate in the selection
of the root bridge, root port, and designated port.
BPDU Exchange
As shown in Figure 10-1-8, the quadruple marked with {} indicates a set of ordered vectors: root
BID (S1_MAC and S2_MAC indicates the BIDs of two devices), total path costs, sender BID, and
Port ID. Configuration BPDUs are sent at intervals set by the Hello timer.
Figure 10-1-8 Exchange of initialization messages
STP algorithm implementation
1. Initialization
As each bridge considers itself the root bridge, the value of the root BID field in the BPDU
sent by each port is recorded as its BID. The value of the Root Path Cost field is the
accumulative
cost of all links to the root bridge; the sender BID is the ID of the local bridge; the Port ID is the
PID of the local bridge port that sends the BPDU.
2. Root bridge selection
During network initialization, every device considers itself as the root bridge and the root
bridge ID as the device ID. Devices exchange configuration BPDUs to compare the root bridge
IDs. The device with the smallest BID is elected as the root bridge.
3. Root port and designated port selection
Table 10-1-7 lists the process of selecting the root port and designated port.
Table 10-1-7 Selecting the root port and designated port
No. Procedure
1 The non-bridge device uses the port that receives the optimal configuration BPDU as the root
port. Table 10-1-8 lists the process of selecting the optimal configuration BPDU.
2 The device calculates a BPDU for each designated port based on the BPDU and path cost of
the root port.
 The root bridge ID is replaced with the root bridge ID of the BPDU on the root interface.
 The root path cost is replaced with the root path cost in the BPDU on the root
interface plus the path cost of the root interface.
 The sender BID is replaced with the device ID.
 The designated port ID is replaced with the port ID.
3 The device compares the calculated BPDU with the BPDU on the port:
 If the calculated BPDU is of higher priority, the port is selected as the designated port
and its BPDU is replaced by the calculated BPDU. The port periodically sends the
calculated BPDU.
 If the BPDU of the port is of higher priority, the BPDU on the port is not updated and
the port is blocked. The port only receives BPDUs, and does not forward data or send
BPDUs.
Table 10-1-8 Selecting the optimal BPDU
No. Procedure
1 Each port compares the received BPDU with its BPDU:
 If the received BPDU has a lower priority, the port discards the received BPDU and
does not process its BPDU.
 If the received BPDU has a higher priority, the port replaces its BPDU with the received
Table 10-1-7 Selecting the root port and designated port
No. Procedure
BPDU.
2 The device compares BPDUs on all the ports and selects the o
STP Calculation Example
When the root bridge, root port, and designated port are selected successfully, the whole tree
topology is set up. The following example describes STP calculation.
Figure 10-1-9 STP networking and topology after calculation
As shown in Figure 10-1-9, priorities of DeviceA, DeviceB, and DeviceC are 0, 1, and 2, and the
path costs between DeviceA and DeviceB, between DeviceA and DeviceC, and between DeviceB
and DeviceC are 5, 10, and 4 respectively.
1. Initial state of each device
Table 10-1-9 lists the initial state of each device.
Table 10-1-9 Initial state of each device
Device
DeviceA Port
Table 10-1-9 Initial state of each device
Device
Port
DeviceB Port
Port
DeviceC Port
Port
2. Comparison and result
Table 10-1-10 lists the comparison and result.
NOTE:
The fields in the BPDU represent {root bridge ID, accumulative root path cost, sender
BID, transmit port ID PID}.
Table 10-1-10 Topology calculation and result
Device Comparison BPDU After Comparison

DeviceA  Port A1: {0, 0, 0, Port
 Port A1 receives the BPDU {1, 0, 1, Port B1} from
A1}
Port B1 and finds that its BPDU {0, 0, 0, Port A1}
has higher priority than the BPDU {1, 0, 1, Port B1}  Port A2: {0, 0, 0, Port
from Port B1 , so Port A1 discards the BPDU {1, 0, A2}
1, Port B1}.
 Port A2 receives the BPDU {2, 0, 2, Port C1} from
Port C1 and finds that its BPDU {0, 0, 0, Port A2}
has higher priority than the BPDU {2, 0, 2, Port
C1} than so Port A2 discards the BPDU {2, 0, 2,
Port C1}.
 After finding that both the root and the designated
switches are itself in the BPDU on each port,
DeviceA considers itself as the root. SwitchA
then sends BPDUs from each port periodically
without modifying the BPDUs.
DeviceB  Port B1: {0, 0, 0, Port

 Port B1 receives the BPDU {0, 0, 0, Port A1} from
A1}
Port A1 and finds that its BPDU {0, 0, 0, Port A1}
Device
has higher priority than the BP

B1}, so Port B1 updates its BP
 Port B2 receives the BPDU {2
 DeviceB compares the BPDU
 DeviceB calculates the BPDU

B2} with its BPDU {1, 0, 1, P
DeviceC Port C1 receives the BPDU {0


 Port C2 receives the BPDU {1
 DeviceC compares the BPDU
 DeviceC calculates the BPDU

Device
DeviceC finds that the calcula
 DeviceC finds that the root pa

patch cost 4).
 DeviceC calculates the BPDU
C1} with its BPDU {0, 0, 0, P
After the topology becomes stable, the root bridge still sends configuration BPDUs at intervals set
by the Hello timer. Each non-root bridge forwards the received configuration BPDUs by using its
designated port. If the priority of the received BPDU is higher than that on the non -root bridge, the
non-root bridge updates its own BPDU based on the information carried in the received BPDU.

1210
STP Topology Changes
Figure 10-1-10 shows the packet transmission process after the STP topology changes.
Figure 10-1-10 Diagram of packet transmission after the topology changes
1. After the network topology changes, a downstream device continuously sends TCN BPDUs
to an upstream device.
2. After the upstream device receives TCN BPDUs from the downstream device, only the
designated port processes them. The other ports may receive TCN BPDUs but do not
process them.
3. The upstream device sets the TCA bit of the Flags field in the configuration BPDUs to 1
and returns the configuration BPDUs to instruct the downstream device to stop sending
TCN BPDUs.
4. The upstream device sends a copy of the TCN BPDUs to the root bridge.
5. Steps 1, 2, 3 and 4 are repeated until the root bridge receives the TCN BPDUs.
6. The root bridge sets the TC bit of the Flags field in the configuration BPDUs to 1 to instruct
the downstream device to delete MAC address entries.
NOTE:
 TCN BPDUs are used to inform the upstream device and root bridge of topology changes.
 Configuration BPDUs with the TCA bit being set to 1 are used by the upstream device to
inform the downstream device that the topology changes are known and instruct the
downstream device to stop sending TCN BPDUs.
 Configuration BPDUs with the TC bit being set to 1 are used by the upstream device to inform
the downstream device of topology changes and instruct the downstream device to delete
MAC address entries. In this manner, fast network convergence is achieved.
10.1.5 Evolution from STP to RSTP
In 2001, IEEE 802.1w was published to introduce an extension of the Spanning Tree Protocol
(STP), namely, Rapid Spanning Tree Protocol (RSTP). RSTP is developed based on STP but
outperforms STP.
Disadvantages of STP
STP ensures a loop-free network but has a slow network topology convergence speed, leading to
service deterioration. If the network topology changes frequently, the connections on the STP-
capable network are frequently torn down, causing frequent service interruption. Users can hardly
tolerate such a situation.
Disadvantages of STP are as follows:
 Port states or port roles are not subtly distinguished, which is not conducive to the learning
and deployment for beginners.
A network protocol that subtly defines and distinguishes different situations is likely
to outperform the others.
 Ports in the Listening, Learning, and Blocking states do not forward user traffic and are
not even slightly different to users.
 The differences between ports in essence never lie in the port states but the port roles
from the perspective of use and configuration.
It is possible that the root port and designated port are both in the Listening state or
Forwarding state.
 The STP algorithm determines topology changes after the time set by the timer expires,
which slows down network convergence.
 The STP algorithm requires a stable network topology. After the root bridge sends
configuration BPDUs, other devices process the configuration BPDUs so that the configuration
BPDUs are advertised to the entire network.
This also slows down topology convergence.
Advantages of RSTP over STP
RSTP deletes three port states and adds two port roles, and decouples port attributes based on the
port status and role. In addition, RSTP provides enhanced features and protection measures to
implement network stability and fast convergence.
 More port roles are defined to simplify the knowledge and deployment of STP.

1210
Figure 10-1-11 Diagram of port roles
As shown in Figure 10-1-11, RSTP defines four port roles: root port, designated port,
alternate port, and backup port.
The functions of the root port and designated port are the same as those defined in STP.
The alternate port and backup port are described as follows:
 From the perspective of configuration BPDU transmission:
 An alternate port is blocked after learning the configuration BPDUs sent by

other bridges.
 A backup port is blocked after learning the configuration BPDUs sent by

itself.
 From the perspective of user traffic:
 An alternate port backs up the root port and provides an alternate path from
the designated bridge to the root bridge.
 A backup port backs up the designated port and provides an alternate path from
the root bridge to the related network segment.
After all RSTP-capable ports are assigned roles, topology convergence is completed.
 Port states are redefined in RSTP.
Port states are simplified from five types to three types. Based on whether a port forwards
user traffic and learns MAC addresses, the port is in one of the following states:
 If a port neither forwards user traffic nor learns MAC addresses, the port is in the
Discarding state.
 If a port does not forward user traffic but learns MAC addresses, the port is in the
Learning state.
 If a port forwards user traffic and learns MAC addresses, the port is in the
Forwarding state.
Table 10-1-11 shows the comparison between port states in STP and RSTP.
NOTE:
Port states and port roles are not necessarily related. Table 10-1-11 lists states of ports
with different roles.
Table 10-1-11 Comparison between states of STP ports and RSTP ports with different roles
STP Port State
Forwarding
Learning
Listening
Blocking
Disabled
 Configuration BPDUs in RSTP are differently defined. Port roles are described based on the
Flags field defined in STP.
Compared with STP, RSTP slightly redefined the format of configuration BPDUs.
 The value of the Type field is no longer set to 0 but 2. Therefore, the RSTP-capable
device always discards the configuration BPDUs sent by an STP-capable device.
 The 6 bits in the middle of the original Flags field are reserved. Such a configuration
BPDU is called an RST BPDU, as shown in Figure 10-1-12.
Figure 10-1-12 Format of the Flags field in an RST BPDU
 Configuration BPDUs are processed in a different manner.
 Transmission of configuration BPDUs
In STP, after the topology becomes stable, the root bridge sends configuration BPDUs at
an interval set by the Hello timer. A non-root bridge does not send configuration BPDUs
until it receives configuration BPDUs sent from the upstream device. This renders the STP
calculation complicated and time-consuming. In RSTP, after the topology becomes stable,
a non-root bridge sends configuration BPDUs at Hello intervals, regardless of whether
it has received the configuration BPDUs sent from the root bridge. Such operations are
implemented on each device independently.
 BPDU timeout period
In STP, a device has to wait a Max Age period before determining a negotiation failure.
In RSTP, if a port does not receive configuration BPDUs sent from the upstream device
for three consecutive Hello intervals, the negotiation between the local device and its
peer fails.
 Processing of inferior BPDUs
In RSTP, when a port receives an RST BPDU from the upstream designated bridge,
the port compares the received RST BPDU with its own RST BPDU.
If its own RST BPDU is superior to the received one, the port discards the received
RST BPDU and immediately responds to the upstream device with its own RST BPDU.
After receiving the RST BPDU, the upstream device updates its own RST BPDU based
on the corresponding fields in the received RST BPDU.
In this manner, RSTP processes inferior BPDUs more rapidly, independent of any
timer that is used in STP.
 Rapid convergence
 Proposal/agreement mechanism
When a port is selected as a designated port, in STP, the port does not enter the
Forwarding state until a Forward Delay period expires; in RSTP, the port enters the
Discarding state, and then the proposal/agreement mechanism allows the port to
immediately enter the
Forwarding state. The proposal/agreement mechanism must be applied on the P2P links
in full duplex mode.
For details, see Details about RSTP.
 Fast switchover of the root port
If the root port fails, the most superior alternate port on the network becomes the root
port and enters the Forwarding state. This is because there must be a path from the root
bridge to a designated port on the network segment connecting to the alternate port.
When the port role changes, the network topology accordingly changes. For details, see
Details about RSTP.
 Edge ports
In RSTP, a designated port on the network edge is called an edge port. An edge
port directly connects to a terminal and does not connect to any other switching
devices.
An edge port does not receive configuration BPDUs, so it does not participate in the
RSTP calculation. It can directly change from the Disabled state to the Forwarding state
without any delay, just like an STP-incapable port. If an edge port receives bogus
configuration BPDUs from attackers, it is deprived of the edge port attributes and
becomes a common STP port. The STP calculation is implemented again, causing
network flapping.
 Protection functions
Table 10-1-12 shows protection functions provided by RSTP.
Table 10-1-12 Protection functions
Protection
Function
BPDU On a
protection Usua
Root protection Due
Table 10-1-12 Protection functions
Protection Scenario Principle

Function
incorrectly changes. This also priority before a period (generally two Forward
causes the traffic that should be Delay periods) expires, the port automatically
transmitted over high-speed links to enters the Forwarding state.
be transmitted over low-speed links, NOTE:
leading to network congestion.
Root protection can take effect on only
designated ports.
Loop On an RSTP-capable network, the After loop protection is configured, if the root
protection switching device maintains the port or alternate port does not receive RST
status of the root port and blocked BPDUs from the upstream switching device for a
ports by continually receiving long time, the switching device notifies the NMS
BPDUs from the upstream that the port enters the Discarding state. The
switching device. blocked port remains in the Blocked state and
If ports cannot receive BPDUs from does not forward packets. This prevents loops on
the upstream switching device due the network. The root port or alternate port
to link congestion or unidirectional restores the Forwarding state after receiving new
link failures, the switching device RST BPDUs.
re-selects a root port. Then, the NOTE:
previous root port becomes a Loop protection can take effect on only the root
designated port and the blocked port and alternate ports.
ports change to the Forwarding
state. As a result, loops may occur
on the network.
TC BPDU After receiving TC BPDUs, a After the TC BPDU attack defense is enabled, the
attack switching device will delete its number of times that TC BPDUs are processed by
defense MAC entries and ARP entries. In the switching device within a given time period is
the event of a malicious attack by configurable. If the number of TC BPDUs that
sending bogus TC BPDUs, a the switching device receives within the given
switching device receives a large time exceeds the specified threshold, the
number of TC BPDUs within a switching device processes TC BPDUs only for
short period, and busies itself the specified number of times. Excess TC BPDUs
deleting its MAC entries and ARP are processed by the switching device as a whole
entries. As a result, the switching for once after the specified period expires. In this
device is heavily burdened, manner, the switching device is prevented from
rendering the network rather frequently deleting its MAC entries and ARP
unstable. entries.
10.1.6 Details about RSTP
P/A Mechanism
The Proposal/Agreement (P/A) mechanism helps a designated port to enter the Forwarding state as
soon as possible. As shown in Figure 10-1-12, a new link is established between the root bridges
S1 and S2. On S2, p2 is an alternate port; p3 is a designated port in the Forwarding state; p4 is an
edge port.
Figure 10-1-13 Schematic diagram for the P/A negotiation
The P/A mechanism works in the following process:
1. p0 and p1 become designated ports and send RST BPDUs.
2. After receiving an RST BPDU with a higher priority, p1 determines that it will become a
root port but not a designated port. p1 then stops sending RST BPDUs.
3. p0 enters the Discarding state, and sends RST BPDUs with the Proposal field being 1.
4. After receiving an RST BPDU with the Proposal field being 1, S2 sets the sync variable to 1
for all its ports.
5. As p2 has been blocked, its status keeps unchanged; p4 is an edge port, and does not
participate in calculation. Therefore, only the non-edge designated port p3 needs to be
blocked.
6. After p2, p3, and p4 enter the Discarding state, their synced variables are set to 1. The
synced variable of the root port p1 is then set to 1, and p1 sends an RST BPDU with the
Agreement field being 1 to S1. Except for the Agreement field, which is set to 1, and the
Proposal field, which is set to 0, the RST BPDU is the same as that was received.
7. After receiving this RST BPDU, S1 identifies it as a reply to the proposal that it just sent,
and p0 immediately enters the Forwarding state.
This P/A negotiation process finishes, and S2 continues to perform the P/A negotiation with
its downstream device.
Theoretically, STP can quickly select a designated port. To prevent loops, STP has to wait for a
period of time long enough to determine the status of all ports on the network. All ports can enter the
Forwarding state at least one forward delay later. RSTP is developed to eliminate this bottleneck by
blocking non-root ports to prevent loops. By using the P/A mechanism, the upstream port can
rapidly enter the Forwarding state.
NOTE:
To use the P/A mechanism, ensure that the link between the two devices is a P2P link in full-duplex
mode. Once the P/A negotiation fails, a designated port can be selected by performing the
STP negotiation after the forwarding delay timer expires twice.
RSTP Topology Change
In RSTP, if a non-edge port changes to the Forwarding state, the topology changes.
After a switching device detects the topology change (TC), it performs the following procedures:
 Start a TC While Timer for every non-edge port. The TC While Timer value doubles the Hello
Timer value.
All MAC addresses learned by the ports whose status changes are cleared before the
timer expires.
These ports send RST BPDUs with the TC field being 1. Once the TC While Timer expires,
they stop sending the RST BPDUs.
 After another switching device receives the RST BPDU, it clears the MAC addresses learned
by all ports excluding the one that receives the RST BPDU. The device then starts a TC While
Timer for all non-edge ports and the root port, the same as the preceding process.
In this manner, RST BPDUs flood the network.
Interoperability between RSTP and STP
When RSTP switches to STP, RSTP loses its advantages such as fast convergence.
On a network where both STP-capable and RSTP-capable devices are deployed, STP-capable
devices ignore RST BPDUs; if a port on an RSTP-capable device receives a configuration BPDU
from an
STP-capable device, the port switches to the STP mode after two Hello intervals and starts to
send configuration BPDUs. In this manner, RSTP and STP are interoperable.
After STP-capable devices are removed, Huawei RSTP-capable datacom devices can switch back
to the RSTP mode.
10.2 MSTP Principles
10.2.1 MSTP Background
RSTP, an enhancement to STP, implements fast convergence of the network topology. There is a
defect for both RSTP and STP: All VLANs on a LAN use one spanning tree, and VLAN-based
load balancing cannot be performed. Once a link is blocked, it will no longer transmit traffic,
wasting bandwidth and causing the failure in forwarding certain VLAN packets.
Figure 10-2-1 STP/RSTP defect
On the network shown in Figure 10-2-1, STP or RSTP is enabled. The broken line shows the
spanning tree. S6 is the root switching device. The links between S1 and S4 and between S2 and S5
are blocked. VLAN packets are transmitted by using the corresponding links marked with "VLAN2"
or "VLAN3."
Host A and Host B belong to VLAN 2 but they cannot communicate with each other because the
link between S2 and S5 is blocked and the link between S3 and S6 denies packets from VLAN 2.
To fix the defect of STP and RSTP, the IEEE released 802.1s in 2002, defining the Multiple
Spanning Tree Protocol (MSTP). MSTP implements fast convergence and provides multiple paths to
load balance VLAN traffic.
MSTP divides a switching network into multiple regions, each of which has multiple spanning
trees that are independent of each other. Each spanning tree is called a Multiple Spanning Tree
Instance (MSTI) and each region is called a Multiple Spanning Tree (MST) region.
NOTE:
An instance is a collection of VLANs. Binding multiple VLANs to an instance saves communication

costs and reduces resource usage. The topology of each MSTI is calculated independent of one
another, and traffic can be balanced among MSTIs. Multiple VLANs that have the same
topology can be mapped to one instance. The forwarding status of the VLANs for a port is
determined by the port status in the MSTI.
Figure 10-2-2 Multiple spanning trees in an MST region
As shown in Figure 10-2-2, MSTP maps VLANs to MSTIs in the VLAN mapping table. Each
VLAN can be mapped to only one MSTI. This means that traffic of a VLAN can be transmitted in
only one MSTI. An MSTI, however, can correspond to multiple VLANs.
Two spanning trees are calculated:
 MSTI 1 uses S4 as the root switching device to forward packets of VLAN 2.
 MSTI 2 uses S6 as the root switching device to forward packets of VLAN 3.
In this manner, devices within the same VLAN can communicate with each other; packets of different
VLANs are load balanced along different paths.
10.2.2 Basic MSTP Concepts
MSTP Network Hierarchy
As shown in Figure 10-2-3, the MSTP network consists of one or more MST regions. Each
MST region contains one or more MSTIs. An MSTI is a tree network consisting of switching
devices running STP, RSTP, or MSTP.
Figure 10-2-3 MSTP network hierarchy
MST Region
An MST region contains multiple switching devices and network segments between them.
The switching devices of one MST region have the following characteristics:
 MSTP-enabled
 Same region name
 Same VLAN-MSTI mappings
 Same MSTP revision level
A LAN can comprise several MST regions that are directly or indirectly connected. Multiple
switching devices can be grouped into an MST region by using MSTP configuration commands.
As shown in Figure 10-2-4, the MST region D0 contains the switching devices S1, S2, S3, and S4,
and has three MSTIs.

1210
Figure 10-2-4 MST region
VLAN Mapping Table
The VLAN mapping table is an attribute of the MST region. It describes mappings between
VLANs and MSTIs.
As shown in Figure 10-2-4, the mappings in the VLAN mapping table of the MST region D0 are
as follows:
 VLAN 1 is mapped to MSTI 1.
 VLAN 2 and VLAN 3 are mapped to MSTI 2.
 Other VLANs are mapped to MSTI 0.
Regional Root
Regional roots are classified into Internal Spanning Tree (IST) and MSTI regional roots.
In the region B0, C0, and D0 on the network shown in Figure 10-2-6, the switching devices closest
to the Common and Internal Spanning Tree (CIST) root are IST regional roots.
An MST region can contain multiple spanning trees, each called an MSTI. An MSTI regional root
is the root of the MSTI. On the network shown in Figure 10-2-5, each MSTI has its own regional
root.
Figure 10-2-5 MSTI
MSTIs are independent of each other. An MSTI can correspond to one or more VLANs, but a VLAN
can be mapped to only one MSTI.
Master Bridge
The master bridge is the IST master, which is the switching device closest to the CIST root in a
region, for example, S1 shown in Figure 10-2-4.
If the CIST root is in an MST region, the CIST root is the master bridge of the region.
CIST Root
Figure 10-2-6 MSTP network
On the network shown in Figure 10-2-6, the CIST root is the root bridge of the CIST. The CIST root
is a device in A0.
CST
A Common Spanning Tree (CST) connects all the MST regions on a switching network.
If each MST region is considered a node, the CST is calculated by using STP or RSTP based on all
the nodes.
As shown in Figure 10-2-6, the MST regions are connected to form a CST.
IST
An IST resides within an MST region.
An IST is a special MSTI with the MSTI ID being 0, called MSTI 0.
An IST is a segment of the CIST in an MST region.
As shown in Figure 10-2-6, the switching devices in an MST region are connected to form an IST.
CIST
A CIST, calculated by using STP or RSTP, connects all the switching devices on a switchin g
network. As shown in Figure 10-2-6, the ISTs and the CST form a complete spanning tree, the CIST.
SST
A Single Spanning Tree (SST) is formed in either of the following situations:
 A switching device running STP or RSTP belongs to only one spanning tree.
 An MST region has only one switching device.
As shown in Figure 10-2-6, the switching device in B0 forms an SST.
Port Role
Based on RSTP, MSTP has two additional port types. MSTP ports can be root ports, designated
ports, alternate ports, backup ports, edge ports, master ports, and regional edge port.
The functions of root ports, designated ports, alternate ports, and backup ports have been defined in
RSTP. Table 10-2-1 lists all port roles in MSTP.
NOTE:
Except edge ports, all ports participate in MSTP calculation.

A port can play different roles in different spanning tree instances.
Table 10-2-1 Port roles
Port Role
Root port A root port is the no

Root ports are respo
As shown in Figure
Designated port The designated port

As shown in Figu
Alternate port  From the pers

sent by anothe
 From the pers
Table 10-2-1 Port roles
Port Role
As shown in Figure
Backup port  From the pers

sent by itself i
 From the pers
As shown in Figure
Master port A master port is on

Master ports are spe
As shown in Figure
Regional edge port A regional edge po

MST region or an S
During MSTP calcu
As shown in Figu
AP1 is a master por
MST region.
Edge port An edge port is lo

Generally, edge por

Figure 10-2-7 Root port, designated port, alternate port, and backup port
Figure 10-2-8 Master port and regional edge port
MSTP Port Status
Table 10-2-2 lists the MSTP port status, which is the same as the RSTP port status.
Table 10-2-2 Port status

1210
Port
Status
Forwarding A port in the Forw
Learning A port in the Learn

address table.
In the Learning sta
Discarding A port in the Disca
There is no necessary link between the port status and the port role. Table 10-2-3 lists the relationships
between port roles and port status.
Table 10-2-3 Relationships between port roles and port status
Port
Status
Forwarding Yes
Learning Yes
Discarding Yes
NOTE:
Yes: The port supports this status.

No: The port does not support this status.
10.2.3 MST BPDUs
MSTP calculates spanning trees on the basis of Multiple Spanning Tree Bridge Protocol Data
Units (MST BPDUs). By transmitting MST BPDUs, spanning tree topologies are computed,
network topologies are maintained, and topology changes are conveyed.
Table 10-2-4 shows differences between TCN BPDUs, configuration BPDUs defined by STP,
RST BPDUs defined by RSTP, and MST BPDUs defined by MSTP.
Table 10-2-4 Differences between BPDUs
Version
2
Table 10-2-4 Differences between BPDUs
Version
MST BPDU Format
Figure 10-2-9 shows the MST BPDU format.
Figure 10-2-9 MST BPDU format

The first 36 bytes of an intra-region or inter-region MST BPDU are the same as those of an
RST BPDU.
Fields from the 37th byte of an MST BPDU are MSTP-specific. The field MSTI Configuration
Messages consists of configuration messages of multiple MSTIs.
Table 10-2-5 lists the major information carried in an MST BPDU.
Table 10-2-5 Major information carried in an MST BPDU
Field Byte Description

Field
Protocol
Identifier
Protocol Version
Identifier
BPDU Type
CIST Flags
CIST Root
Identifier
CIST External
Path Cost
CIST Regional
Root Identifier
CIST Port
Identifier
Message Age
Max Age
Hello Time
Forward Delay
Version 1 Length
Version 3 Length
MST Configuration Identifier
CIST Internal
Root Path Cost

Field
CIST Bridge
Identifier
CIST Remaining
Hops
MSTI Configuration Messages(may be absent)
Configurable MST BPDU Format
Currently, there are two MST BPDU formats:
 dot1s: BPDU format defined in IEEE 802.1s.
 legacy: private BPDU format.
If a port transmits either dot1s or legacy BPDUs by default, the user needs to identify the format of
BPDUs sent by the peer, and then runs a command to configure the port to support the peer BPDU
format. Once the configuration is incorrect, a loop probably occurs due to incorrect MSTP
calculation.
By using the stp compliance command, you can configure a port on a Huawei datacom device to
automatically adjust the MST BPDU format. With this function, the port automatically adopts the
peer BPDU format. The following MST BPDU formats are supported by Hua wei datacom devices:
 auto
 dot1s
 legacy
In addition to dot1s and legacy formats, the auto mode allows a port to automatically switch to the
BPDU format used by the peer based on BPDUs received from the peer. In this manner, the two
ports use the same BPDU format. In auto mode, a port uses the dot1s BPDU format by default, and
keeps pace with the peer after receiving BPDUs from the peer.
Configurable Maximum Number of BPDUs Sent by a Port at a Hello Interval
BPDUs are sent at Hello intervals to maintain the spanning tree. If a switching device does not
receive any BPDU during a certain period of time, the spanning tree will be re-calculated.
After a switching device becomes the root, it sends BPDUs at Hello intervals. Non -root
switching devices adopt the Hello Time value set for the root.
1210
Huawei datacom devices allow the maximum number of BPDUs sent by a port at a Hello interval to
be configured as needed.
The greater the Hello Time value, the more BPDUs sent at a Hello interval. Setting the Hello Time to
a proper value limits the number of BPDUs sent by a port at a Hello interval. This helps prevent
network topology flapping and avoid excessive use of bandwidth resources by BPDUs.
10.2.4 MSTP Topology Calculation
MSTP Principle
In MSTP, the entire Layer 2 network is divided into multiple MST regions, which are
interconnected by a single CST. In an MST region, multiple spanning trees are calculated, each of
which is called an MSTI. Among these MSTIs, MSTI 0 is also known as the internal spanning tree
(IST). Like STP, MSTP uses configuration messages to calculate spanning trees, but the
configuration messages are MSTP-specific.
Vectors
Both MSTIs and the CIST are calculated based on vectors, which are carried in MST
BPDUs. Therefore, switching devices exchange MST BPDUs to calculate MSTIs and the
CIST.
 Vectors are described as follows:
 The following vectors participate in the CIST calculation:
{ root ID, external root path cost, region root ID, internal root path cost,
designated switching device ID, designated port ID, receiving port ID }
 The following vectors participate in the MSTI calculation:
{ regional root ID, internal root path cost, designated switching device ID, designated port
ID, receiving port ID }
 The priorities of vectors in braces are in descending order from left to right.
 Table 10-2-6 describes the vectors.
Table 10-2-6 Vector description
Vector Name Description
Root ID Identifies the root switching device for the CIST. The root identifier
consists of the priority value (16 bits) and MAC address (48 bits).
The priority value is the priority of MSTI 0.
External root path Indicates the path cost from a CIST regional root to the root. ERPCs saved
cost (ERPC) on all switching devices in an MST region are the same. If the CIST root is
in an MST region, ERPCs saved on all switching devices in the MST region
are 0s.
Table 10-2-6 Vector description
Vector Name
Regional root ID
Internal root path cost

(IRPC)
Designated switching device ID
Designated port ID
Receiving port ID
 The vector comparison principle is as follows:
For a vector, the smaller the priority value, the higher the
priority. Vectors are compared based on the following rules:
1. Compare the IDs of the roots.
2. If the IDs of the roots are the same, compare ERPCs.
3. If ERPCs are the same, compare the IDs of regional roots.
4. If the IDs of regional roots are the same, compare IRPCs.
5. If IRPCs are the same, compare the IDs of designated switching devices.
6. If the IDs of designated switching devices are the same, compare the IDs of
designated ports.
7. If the IDs of designated ports are the same, compare the IDs of receiving ports.
If the priority of a vector carried in the configuration message of a BPDU received by a port is
higher than the priority of the vector in the configuration message saved on the port, the port
replaces the saved configuration message with the received one. In addition, the port updates
the global configuration message saved on the device. If the priority of a vector carried in the
configuration message of a BPDU received on a port is equal to or lower than the priority of
the vector in the configuration message saved on the port, the port discards the BPDU.
CIST Calculation
After completing the configuration message comparison, the switching device with the highest
priority on the entire network is selected as the CIST root. MSTP calculates an IST for each MST
region, and computes a CST to interconnect MST regions. On the CST, each MST region is
considered a switching device. The CST and ISTs constitute a CIST for the entire network.
MSTI Calculation
In an MST region, MSTP calculates an MSTI for each VLAN based on mappings between VLANs
and MSTIs. Each MSTI is calculated independently. The calculation process is similar to the process
for STP to calculate a spanning tree. For details, see STP Topology Calculation.
MSTIs have the following characteristics:
 The spanning tree is calculated independently for each MSTI, and spanning trees of MSTIs
are independent of each other.
 MSTP calculates the spanning tree for an MSTI in the manner similar to STP.
 Spanning trees of MSTIs can have different roots and topologies.
 Each MSTI sends BPDUs in its spanning tree.
 The topology of each MSTI is configured by using commands.
 A port can be configured with different parameters for different MSTIs.
 A port can play different roles or have different status in different MSTIs.
On an MSTP-aware network, a VLAN packet is forwarded along the following paths:
 MSTI in an MST region
 CST among MST regions
MSTP Responding to Topology Changes
MSTP topology changes are processed in the manner similar to that in RSTP. For details about how
RSTP processes topology changes, see Details about RSTP.
10.2.5 MSTP Fast Convergence
MSTP supports both ordinary and enhanced Proposal/Agreement (P/A) mechanisms:
Ordinary P/A
The ordinary P/A mechanism supported by MSTP is implemented in the same manner as that
supported by RSTP. For details about the P/A mechanism supported by RSTP, see Details about RSTP.
Enhanced P/A
Figure 10-2-10 Enhanced P/A mechanism

As shown in Figure 10-2-10, in MSTP, the P/A mechanism works as follows:
1. The upstream device sends a proposal to the downstream device, indicating that the port
connecting to the downstream device wants to enter the Forwarding state as soon as
possible. After receiving this BPDU, the downstream device sets its port connecting to the
upstream device to the root port, and blocks all non-edge ports.
2. The upstream device continues to send an agreement. After receiving this BPDU, the root
port enters the Forwarding state.
3. The downstream device replies with an agreement. After receiving this BPDU, the
upstream device sets its port connecting to the downstream device to the designated port,
and the port enters the Forwarding state.
By default, Huawei datacom devices use the fast transition mechanism in enhanced mode. To enable
a Huawei datacom device to communicate with a third-party device that use the fast transition
mechanism in common mode, configure the Proposal/Agreement mechanism on the Huawei datacom
device so that the Huawei datacom device works in common mode.
10.2.6 MSTP Multi-Process
Background
On the network shown in Figure 10-2-11:
 UPEs are deployed at the aggregation layer, running MSTP.
 UPE1 and UPE2 are connected by a Layer 2 link.
 Multiple rings are connected to UPE1 and UPE2 through different ports.
 Switching devices on the rings reside at the access layer, running STP or RSTP. In addition,
UPE1 and UPE2 work for different carriers, so they need to reside on different spanning
trees whose topology changes do not affect each other.
Figure 10-2-11 Application with both MSTP and STP/RSTP
On the network shown in Figure 10-2-11, switching devices and UPEs construct multiple Layer 2
rings. STP must be enabled on these rings to prevent loops. UPE1 and UPE2 are connected to
multiple access rings that are independent of each other. The spanning tree protocol cannot calculate
a single spanning tree for all switching devices. Instead, the spanning tree protocol must be enabled
on each ring to calculate a separate spanning tree.
MSTP supports MSTIs, but these MSTIs must belong to one MST region and devices in the region
must have the same configurations. If the devices belong to different regions, MSTP calculates the
spanning tree based on only one instance. Assume that devices on the network belong to different
regions, and only one spanning tree is calculated in one instance. In this case, the status change of
any device on the network affects the stability of the entire network. On the network shown in
Figure
10-2-11, the switching devices connected to UPEs support only STP or RSTP but not MSTP. When
MSTP-enabled UPEs receive RST BPDUs from the switching devices, the UPEs consider that they
and switching devices belong to different regions. As a result, only one spanning tree is calculated for
the rings composed of UPEs and switching devices, and the rings affect each other.
To prevent this problem, MSTP multi-process is introduced. MSTP multi-process is an enhancement to

MSTP. The MSTP multi-process mechanism allows ports on switching devices to be bound to different
processes. MSTP calculation is performed based on processes. In this manner, only ports that are
bound to a process participate in the MSTP calculation for this process. With the MSTP multi-process
mechanism, spanning trees of different processes are calculated independently and do not affect each
other. The network shown in Figure 10-2-11 can be divided into multiple MSTP processes by using
MSTP multi-process. Each process takes charge of a ring composed of switching devices. The MSTP
processes have the same functions and support MSTIs. The MSTP calculation for one process does
not affect the MSTP calculation for another process.
NOTE:
MSTP multi-process is applicable to MSTP as well as RSTP and STP.
Purpose
On the network shown in Figure 10-2-11, MSTP multi-process is configured to implement

the following:
 Greatly improves applicability of STP to different networking conditions.
To help a network running different spanning tree protocols run properly, you can bind the
devices running different spanning tree protocols to different processes. In this manner,
every process calculates a separate spanning tree.
 Improves the networking reliability. For a network composed of many Layer 2 access
devices, using MSTP multi-process reduces the adverse effect of a single node failure on the
entire network.
The topology is calculated for each process. If a device fails, only the topology corresponding
to the process to which the device belongs changes.
 Reduces the network administrator workload during network expansion, facilitating

operation and maintenance.
To expand a network, you only need to configure new processes, connect the processes to
the existing network, and keep the existing MSTP processes unchanged. If device expansion
is performed in a process, only this process needs to be modified.
 Implements separate Layer 2 port management
An MSTP process manages parts of ports on a device. Layer 2 ports on a device are
separately managed by multiple MSTP processes.
Principle
 Public link status
As shown in Figure 10-2-11, the public link between UPE1 and UPE2 is a Layer 2 link running
MSTP. The public link between UPE1 and UPE2 is different from the links connecting
switching devices to UPEs. The ports on the public link need to participate in the calculation for
multiple
access rings and MSTP processes. Therefore, the UPEs must identify the process from which
MST BPDUs are sent.
In addition, a port on the public link participates in the calculation for multiple MSTP
processes, and obtains different status. As a result, the port cannot determine its status.
To prevent this situation, it is defined that a port on a public link always adopts its status in
MSTP process 0 when participating in the calculation for multiple MSTP processes.
NOTE:
After a device normally starts, MSTP process 0 exists by default, and MSTP configurations in
the system view and interface view belong to this process.
 Reliability
On the network shown in Figure 10-2-12, after the topology of a ring changes, the MSTP
multi-process mechanism helps UPEs flood a TC packet to all devices on the ring and prevent
the TC packet from being flooded to devices on the other ring. UPE1 and UPE2 update MAC
and ARP entries on the ports corresponding to the changed spanning tree.
Figure 10-2-12 MSTP multi-process topology change
On the network shown in Figure 10-2-13, if the public link between UPE1 and UPE2
fails, multiple switching devices that are connected to the UPEs will unblock their blocked
ports.
Figure 10-2-13 Public link fault

Assume that UPE1 is configured with the highest priority, UPE2 with the second highest
priority, and switching devices with default or lower priorities. After the link between UPE1
and UPE2 fails, the blocked ports (replacing the root ports) on switching devices no longer
receive packets with higher priorities and re-performs state machine calculation. If the
calculation changes the blocked ports to designated ports, a permanent loop occurs, as shown in
Figure 10-2-14.
Figure 10-2-14 Loop between access rings
 Solutions
To prevent a loop between access rings, use either of the following

solutions:
 Configure an inter-board Eth-Trunk link between UPE1 and UPE2.
An inter-board Eth-Trunk link is used as the public link between UPE1 and UPE2
to improve link reliability, as shown in Figure 10-2-15.
Figure 10-2-15 Inter-board Eth-Trunk link
 Configure root protection between UPE1 and UPE2.
If all physical links between UPE1 and UPE2 fail, configuring an inter-board Eth-Trunk
link cannot prevent the loop. Root protection can be configured to prevent the loop
shown in Figure 10-2-14.

1210
Figure 10-2-16 MSTP multi-process with root protection
Use the blue ring shown in Figure 10-2-16 as an example. UPE1 is configured with the
highest priority, UPE2 with the second highest priority, and switching devices on the
blue ring with default or lower priorities. In addition, root protection is enabled on
UPE2.
Assume that a port on S1 is blocked. When the public link between UPE1 and UPE2 fails,
the blocked port on S1 begins to calculate the state machine because it no longer receives
BPDUs of higher priorities. After the calculation, the blocked port becomes the
designated port and performs P/A negotiation with the downstream device.
After S1, which is directly connected to UPE2, sends BPDUs of higher priorities to the
UPE2 port enabled with root protection, the port is blocked. From then on, the port
remains blocked because it continues receiving BPDUs of higher priorities. In this
manner, no loop will occur.
10.3 Examples for Configuring of STP
10.3.1 Example for Configuring Basic STP Functions
Network designers tend to deploy multiple physical links between two devices (one link is the
master and the others are backups) to fulfill network redundancy requirements. Loops are bound to
occur on such types of complex networks.
Loops will cause broadcast storms, which exhaust network resources and paralyze the network.
Loops also cause MAC address flapping that damages MAC address entries.
STP can be deployed on a network to eliminate loops by blocking some ports. On the network shown
in Figure 10-3-1, after SwitchA, SwitchB, SwitchC, and SwitchD running STP discover loops by
exchanging information, they trim the ring topology into a loop-free tree topology by blocking a
certain port. STP prevents replication and circular propagation of packets on the network and the
release the switching devices from processing duplicate packets, improving their processing
performance.
Figure 10-3-1 Networking diagram of basic STP configurations

1. Configure basic STP functions, including:
a. Configure the STP mode for the ring network.
b. Configure primary and secondary root
bridges. c. Set path costs for ports to block
certain ports.
d. Enable STP to eliminate loops.
NOTE:
STP is not required on the interfaces connected to terminals because these interfaces
do not need to participate in STP calculation.
Procedure
1. Configure basic STP functions.
a. Configure the STP mode for the devices on the ring network.
# Configure the STP mode on SwitchA.
[Huawei] sysname SwitchA
[RouterA] stp mode stp
# Configure the STP mode on SwitchB.
[HUAWEI] sysname SwitchB
[SwitchB] stp mode stp
# Configure the STP mode on SwitchC.
[HUAWEI] sysname SwitchC
[SwitchC] stp mode stp
# Configure the STP mode on SwitchD.
[HUAWEI] sysname SwitchD
[SwitchD] stp mode stp
b. Configure primary and secondary root bridges.
# Configure RouterA as the primary root bridge.
[RouterA] stp root primary
# Configure SwitchA as the secondary root bridge.
[SwitchA] stp root secondary
c. Set path costs for ports in each spanning tree to block certain ports.
NOTE:
 The values of path costs depend on path cost calculation methods. This example
uses the Huawei proprietary calculation method and sets the path cost to
200000.
 All switching devices on a network must use the same path cost
calculation method. Refer to STP List of path costs to get standard of other
calculation methods.
# On SwitchA, configure the path cost calculation method as the Huawei

calculation method.
[SwitchA] stp pathcost-standard legacy
# On SwitchB, configure the path cost calculation method as the Huawei

calculation method.
[SwitchB] stp pathcost-standard legacy
# Set the path cost of GigabitEthernet0/0/1 on SwitchC to 20000.
[SwitchC] stp pathcost-standard legacy

[SwitchC] interface gigabitethernet 0/0/1
[SwitchC-GigabitEthernet0/0/1] stp cost 20000
[SwitchC-GigabitEthernet0/0/1] quit
# On SwitchD, configure the path cost calculation method as the Huawei

calculation method.
[SwitchD] stp pathcost-standard legacy
d. Enable STP to eliminate loops.
 Disable STP on interfaces connected to PCs.
# Disable STP on GigabitEthernet 0/0/2 on SwitchB. Enable STP globally.
[SwitchB] interface gigabitethernet 0/0/2

[SwitchB-GigabitEthernet0/0/2] stp disable
[SwitchB-GigabitEthernet0/0/2] quit
# Disable STP on GigabitEthernet 0/0/2 on SwitchC.

[SwitchC-GigabitEthernet0/0/2] stp disable
 Enable STP globally.
# Enable STP globally on SwitchA.
[SwitchA] stp enable
# Enable STP globally on SwitchB.

[SwitchB] stp enable
# Enable STP globally on SwitchC.
[SwitchC] stp enable
# Enable STP globally on SwitchD.
[SwitchD] stp enable
After the previous configurations, run the following commands to verify the configuration
when the network is stable:
# Run the display stp brief command on RouterA to view the interface status and
protection type. The displayed information is as follows:
[SwitchA] display stp brief

MSTID Port
0 GigabitEthernet0/0/1
After SwitchA is configured as a root bridge, GigabitEthernet 0/0/2 and GigabitEthernet 0/0/1
connected to SwitchB and SwitchD respectively are elected as designated ports in spanning
tree calculation.
# Run the display stp interface gigabitethernet 0/0/1 brief command on SwitchB to
view status of GigabitEthernet 0/0/1. The displayed information is as follows:
[SwitchB] display stp interface gigabitethernet 0/0/1 brief

MSTID Port Role STP State Protection
0 GigabitEthernet0/0/1 DESI FORWARDING NONE
GigabitEthernet 0/0/1 is elected as a designated port in spanning tree calculation and is in the
Forwarding state.
# Run the display stp brief command on SwitchC to view the interface status and
[SwitchC] display stp brief

GigabitEthernet 0/0/3 is elected as a root port in spanning tree calculation and is in the
Forwarding state.
GigabitEthernet 0/0/1 is elected as an alternate port in spanning tree calculation and is in the
Discarding state.
Configuration Files
 Configuration file of SwitchA
#
sysname SwitchA
#
stp mode stp
stp instance 0 root primary
stp pathcost-standard legacy
#
return
 Configuration file of SwitchB
#
sysname SwitchB
#
stp mode stp
#
stp disable
#
return
 Configuration file of SwitchC
#
sysname SwitchC
#
stp mode stp
#
stp instance 0 cost 20000
#
stp disable
#
return
 Configuration file of SwitchD

#
sysname SwitchD
#
stp mode stp
stp instance 0 root secondary
#
return
10.3.2 Example for Configuring Basic RSTP Functions
On a complex network, loops are inevitable. With the requirement for network redundancy
backup, network designers tend to deploy multiple physical links between two devices, one of
which is the master and the others are the backup. Loops are likely or bound to occur in such a
situation.
Loops will cause broadcast storms, thereby exhausting network resources and paralyzing the
network. Loops also cause flapping of MAC address tables and damages MAC address entries.
RSTP can be deployed on a network to eliminate loops by blocking some ports. On the network
shown in Figure 10-3-2, after RouterA, SwitchA, SwitchB, SwitchC and SwitchD running RSTP
discover loops on the network by exchanging information with each other, they trim the ring
topology into a
loop-free tree topology by blocking an interface. In this manner, replication and circular propagation
of packets are prevented on the network and the switching devices are released from processing
duplicated packets, thereby improving their processing performance.
Figure 10-3-2 Networking diagram of configuring basic RSTP functions
1. Configure basic RSTP functions, including:
a. Configure the RSTP mode for the ring network.
b. Configure primary and secondary root bridges.
c. Set path costs for ports to block certain ports.
d. Enable RSTP to eliminate loops, including:
 Enable RSTP globally.
 Enable RSTP on all the interfaces except the interfaces connected to terminals.
NOTE:
RSTP is not required on the interfaces connected to terminals because these interfaces
do not need to participate in RSTP calculation.
2. Configure RSTP protection functions, for example, configure root protection on a
designated port of a root bridge.
Procedure
1. Configure basic RSTP functions.
a. Configure the RSTP mode for the devices on the ring network.
# Configure the RSTP mode on RouterA.
[RouterA] stp mode rstp
# Configure the RSTP mode on SwitchA, SwitchB, SwitchC and
SwitchD. b. Configure primary and secondary root bridges.
# Configure RouterA as the primary root bridge.
[RouterA] stp root primary
# Configure SwitchA as a second root bridge. (The detailed configuration is not

provided here.)
c. Set path costs for the interface to be blocked.

NOTE:
 The values of path costs depend on path cost calculation methods. This example
uses the Huawei proprietary calculation method and sets the path cost to
200000.
 All switching devices on a network must use the same path cost
calculation method. Refer to STP List of path costs to get standard of other
calculation methods.
# On RouterA, configure the path cost calculation method as the Huawei

proprietary method.
[RouterA] stp pathcost-standard legacy
# On SwitchA, SwitchB, SwitchC and SwitchD, configure the path cost calculation
method as the Huawei proprietary method. (The detailed configuration is not
provided here.)
# As shown in Figure 10-3-2, set the path cost of Eth0/0/4 on SwitchC and SwitchD to
200000. (The detailed configuration is not provided here.)
d. Enable RSTP to eliminate loops.
 Disable RSTP on interfaces connected to PCs.
# Disable RSTP on interfaces connected to terminals for SwitchC and SwitchD.

 Enable RSTP globally.
# Enable RSTP globally on RouterA.
[RouterA] stp enable
# Enable RSTP globally on other switching devices.
 Enable RSTP on all the interfaces except the interfaces connected to terminals.
# Enable RSTP on RouterA Ethernet2/0/0 and Ethernet2/0/1.

[RouterA-Ethernet2/0/0] stp enable
# Enable STP on all the interfaces except the interfaces connected to terminals for
SwitchA, SwitchB, SwitchC and SwitchD.
2. Configure RSTP protection function.
# Enable root protection on Eth2/0/0 and Eth2/0/1 of RouterA.

[RouterA-Ethernet2/0/0] stp root-protection
# Run the display stp brief command on RouterA to view the interface status and
[RouterA] display stp brief

0 Ethernet2/0/0 DESI FORWARDING ROOT
0 Ethernet2/0/1 DESI FORWARDING ROOT
After RouterA is configured as a root bridge, Ethernet2/0/0 connected to SwitchA and

Ethernet2/0/1 connected to SwitchB are elected as designated ports during spanning
tree calculation.

1210
Configuration Files
#
sysname RouterA
#
stp mode rstp
#
stp root-protection
#
stp root-protection
#
return
#
sysname SwitchA
#
stp mode rstp
#
#
#
#
return
#
sysname SwitchB
#
stp mode rstp
#
#
#
#
return
#
sysname SwitchC
#
stp mode rstp
#
#
stp disable
#
stp disable
#
#
return
#
sysname SwitchD
#
stp mode rstp
#
#
stp disable
#
stp disable
#
#
return
10.3.3 Example for Configuring Basic MSTP Functions
On a complex network, loops are inevitable. With the requirement for network redundancy
backup, network designers tend to deploy multiple physical links between two devices, one of
which is the master and the others are the backup. Loops are likely or bound to occur in such a
situation.
Loops will cause broadcast storms, thereby exhausting network resources and paralyzing the
network. Loops also cause flapping of MAC address tables and damages MAC address entries.
MSTP can be deployed to eliminate loops. MSTP blocks redundant links on a Layer 2 network
and trims the network into a loop-free tree.
As shown in Figure 10-3-3, to load balance traffic of VLANs 2 to 10 and traffic of VLANs 11 to 20,
multiple MSTIs are created. MSTP defines a VLAN mapping table in which VLANs are associated
with spanning tree instances. Run MSTP on RouterA, SwitchA, SwitchB, SwitchC and SwitchD.
Figure 10-3-3 Networking diagram of configuring basic MSTP functions
1. Configure basic MSTP functions, including:
a. Configure the MSTP mode for the ring network.
b. Configure an MST region and create multiple MSTIs to implement load balancing.
c. In the MST region, configure a primary root bridge and a secondary root bridge for each
MSTI.
d. Set path costs for ports to be blocked in each MSTI.
e. Enable MSTP to eliminate loops, including:
 Enable MSTP globally.
 Enable MSTP on all the interfaces except the interfaces connected to terminals.
NOTE:
MSTP is not required on the interfaces connected to terminals because these

interfaces do not need to participate in MSTP calculation.
2. Configure MSTP protection functions, for example, configure root protection on a
designated port of a root bridge in each MSTI.
3. Configure the Layer 2 forwarding function on devices.
Procedure
1. Configure basic MSTP functions.
a. Configure the MSTP mode for the devices on the ring network.
# Configure the MSTP mode on RouterA.
[RouterA] stp mode mstp
# Configure the MSTP mode on SwitchA, SwitchB, SwitchC and SwitchD.
b. Add all devices to MST region RG1, and create two MSTIs. MSTI1 maps to VLAN (2
to 10), and MSTI2 maps to VLAN (11 to 20).
# Configure RouterA to MST region.
[RouterA] stp region-configuration

[RouterA] region-name RG1
[RouterA] instance 1 vlan 2 to 10
[RouterA] instance 2 vlan 11 to 20
[RouterA] active region-configuration
[RouterA] quit
# Configure SwitchA, SwitchB, SwitchC and SwitchD to MST region RG1, and
create two MSTIs. MSTI1 maps to VLAN (2 to 10), and MSTI2 maps to VLAN (11 to
20).
c. In RG1, configure primary and secondary root bridges for MSTI1 and MSTI2.
# Configure primary root bridge on RouterA in MSTI1.
[RouterA] stp instance 1 root primary
# Configure secondary root bridge on SwitchA in MSTI1.
# Configure primary root bridge on RouterA in MSTI2.
[RouterA] stp instance 2 root primary
# Configure secondary root bridge on SwitchB in MSTI2.
d. Set the path costs of the ports to be blocked in MSTI1 and MSTI2 to be larger than
the default value.
NOTE:
 The values of path costs depend on path cost calculation methods. Use the Huawei
proprietary calculation method as an example to set the path costs of the ports to
be
blocked to 200000.
 If the switches are not Huawei 2300 Series, all switches on a network must use
the same path cost calculation method. Refer to STP List of path costs to get
standard of other calculation methods.
# On RouterA, configure the path cost calculation method as the Huawei

proprietary method.
[RouterA] stp pathcost-standard legacy
# On SwitchA, SwitchB, SwitchC and SwitchD, configure the path cost

calculation method as the Huawei proprietary method.
# As shown in Figure 10-3-3, set the path cost of Eth0/0/4 on SwitchC to 200000 in
MSTI1.
# As shown in Figure 10-3-3, set the path cost of Eth0/0/4 on SwitchD to 200000 in
MSTI2.
e. Enable MSTP to eliminate loops.
 Disable MSTP on interfaces connected to PCs.
# As shown in Figure 10-3-3, disable MSTP on interface Eth0/0/2 and Eth0/0/3 of

SwitchC.
# As shown in Figure 10-3-3, disable MSTP on interface Eth0/0/2 and Eth0/0/3 of

SwitchD.
# Enable MSTP globally on RouterA.
[RouterA] stp enable
# Enable MSTP globally on SwitchA, SwitchB, SwitchC and SwitchD.
 Enable MSTP on all the interfaces except the interfaces connected to terminals.
# Enable MSTP on RouterA Eth2/0/0 and Eth2/0/1.

# As shown in Figure 10-3-3, Enable MSTP on all interfaces except the

interfaces connected to terminals, for SwitchA, SwitchB, SwitchC and SwitchD.
2. Configure MSTP protection function.
# Enable root protection on RouterA Eth2/0/0 and Eth2/0/1.

3. Configure the Layer 2 forwarding function on devices in the ring.
 Create VLANs on RouterA, SwitchA, SwitchB, SwitchC and SwitchD.
# Create VLANs 2 to 20 on RouterA.
[RouterA] vlan batch 2 to 20
# Create VLANs 2 to 20 on SwitchA and SwitchB.
# Create VLANs 2 to 10 on SwitchC.
# Create VLANs 11 to 20 on SwitchD.
 Add interfaces on the switching devices in the ring to VLANs.
# Add RouterA Eth2/0/0 and Eth2/0/1 to VLAN 2 to 20.

[RouterA-Ethernet2/0/0] port trunk allow-pass vlan 2 to 20
[RouterA-Ethernet2/0/1] port trunk allow-pass vlan 2 to 20
# Add interfaces Eth0/0/1, Eth0/0/2 and Eth0/0/3 on SwitchA and SwitchB to VLAN 2 to
20.
# Add interfaces Eth0/0/1, Eth0/0/2, Eth0/0/3 and Eth0/0/4 on SwitchC to VLAN 2 to 10.
# Add interfaces Eth0/0/1, Eth0/0/2, Eth0/0/3 and Eth0/0/4 on SwitchD to VLAN 11 to

20.
# run display stp brief on RouterA to view the interface status and protection type.
The displayed information is as follows:
[RouterA] display stp brief

0 Ethernet2/0/0
0 Ethernet2/0/1
1 Ethernet2/0/0
1 Ethernet2/0/1
2 Ethernet2/0/0
2 Ethernet2/0/1
In MSTI1, after RouterA is configured as a root bridge, RouterA Eth2/0/0 and Eth2/0/1
are elected as designated ports during spanning tree calculation. In MSTI2, after RouterA
is configured as a root bridge, RouterA Eth2/0/0 and Eth2/0/1 are elected as designated
ports during spanning tree calculation.
# Verify the interface status and protection type on SwitchA. In MSTI1, interface Eth0/0/1 is
elected as root port, interfaces Eth0/0/2 and Eth0/0/3 are elected as designated ports. In
MSTI2, interface Eth0/0/1 is elected as root port, interfaces Eth0/0/2 and Eth0/0/3 are elected
as designated ports.
# Verify the interface status and protection type on SwitchB. In MSTI1, interface Eth0/0/1 is
elected as root port, interfaces Eth0/0/2 and Eth0/0/3 are elected as designated ports. In
MSTI2, interface Eth0/0/1 is elected as root port, interfaces Eth0/0/2 and Eth0/0/3 are elected
as designated ports.
# Verify the interface status and protection type on SwitchC. In MSTI1, interface Eth0/0/1
is elected as root port, interface Eth0/0/4 is blocked. In MSTI2, interface Eth0/0/1 is elected
as root port, interface Eth0/0/4 is elected as designated port.
# Verify the interface status and protection type on SwitchD. In MSTI1, interface Eth0/0/1
is elected as root port, interface Eth0/0/4 is elected as designated port. In MSTI2, interface
Eth0/0/1 is elected as root port, interface Eth0/0/4 is blocked.
Configuration Files
#
sysname RouterA
#
vlan batch 2 to 20
#
#
stp region-configuration
region-name RG1
instance 1 vlan 2 to 10
active region-configuration
#
stp root-protection
#
stp root-protection
#
return
#
sysname SwitchA
#
vlan batch 2 to 20
#
#
region-name RG1
#
#
#
#
return
#
sysname SwitchB
#
vlan batch 2 to 20
#
#
region-name RG1
#

1210
#
#
#
return
#
sysname SwitchC
#
vlan batch 2 to 10
#
#
region-name RG1
#
#
stp disable
#
stp disable
#
#
return
#
sysname SwitchD
#
vlan batch 11 to 20
#
#
region-name RG1
#
#
stp disable
#
stp disable
#
#
return
10.3.4 Example for Configuring MSTP + VRRP Network
As shown in Figure 10-3-4, hosts connect to SwitchC, and SwitchC connects to the Internet
through SwitchA and SwitchB. To improve access reliability, the user configures redundant links.
The redundant links causes a network loop, which leads to broadcast storm and destroy MAC
bridge entries.
It is required that the network loop be prevented when redundant links are deployed, traffic be
switched to another link when one link is broken, and network bandwidth be effectively used.
MSTP can be configured on the network to prevent loops. MSTP blocks redundant links and prunes a
network into a tree topology free from loops. In addition, VRRP needs to be configured on Switch A
and SwitchB. Host A connects to the Internet by using SwitchA as the default gateway and SwitchB
as the secondary gateway. Host B connects to the Internet by using SwitchB as the default gateway
and SwitchA as the secondary gateway. Traffic is thus load balanced and communication reliability is
improved.
Figure 10-3-4 MSTP + VRRP network

Table 10-3-1 Parameters of MSTP + VRRP network
Device
SwitchA
SwitchB
1. Configure basic MSTP on the switches, including:
a. Configure MST and create multi-instance, map VLAN 2 to MSTI1, and map VLAN 3 to
MSTI2 to load balance traffic.
b. Configure the root bridge and backup bridge in the MST region.
c. Configure the path cost on an interface so that the interface can be
blocked. d. Enable MSTP to prevent loops:
 Enable MSTP on all interfaces except the interfaces connecting to hosts.
NOTE:
The interfaces connecting to hosts do not participate in MSTP calculation.
2. Enable the protection function to protect devices or links. For example, enable the
protection function on the root bridge of each instance to protect roots.
3. Configure Layer 2 forwarding.
4. Assign an IP address to each interface and configure the routing protocol on each device
to ensure network connectivity.
5. Create VRRP group 1 and VRRP group 2 on SwitchA and SwitchB. Configure SwitchA as
the master device and SwitchB as the backup device of VRRP group 1. Configure SwitchB as
the master device and SwitchA as the backup device of VRRP group 2.
Procedure
1. Configure basic MSTP functions.
a. Add SwitchA, SwitchB, and SwitchC to region RG1, and create instances MSTI1 and
MSTI2.
# Configure an MST region on SwitchA.
[HUAWEI] sysname SwitchA
[SwitchA] stp region-configuration
[SwitchA-mst-region] region-name RG1
[SwitchA-mst-region] instance 1 vlan 2
[SwitchA-mst-region] instance 2 vlan 3
[SwitchA-mst-region] active region-configuration
[SwitchA-mst-region] quit
# Configure an MST region on SwitchB.
[HUAWEI] sysname SwitchB
[SwitchB] stp region-configuration
[SwitchB-mst-region] region-name RG1
[SwitchB-mst-region] instance 1 vlan 2
[SwitchB-mst-region] instance 2 vlan 3
[SwitchB-mst-region] active region-configuration
[SwitchB-mst-region] quit
# Configure an MST region on SwitchC.
[HUAWEI] sysname SwitchC
[SwitchC] stp region-configuration
[SwitchC-mst-region] region-name RG1
[SwitchC-mst-region] instance 1 vlan 2
[SwitchC-mst-region] instance 2 vlan 3
[SwitchC-mst-region] active region-configuration
[SwitchC-mst-region] quit
b. Configure the root bridges and backup bridges for MSTI1 and MSTI2 in RG1.
 Configure the root bridge and backup bridge for MSTI1.
# Set SwitchA as the root bridge of MSTI1.
[SwitchA] stp instance 1 root primary

# Set SwitchB as the root bridge of MSTI1.
[SwitchB] stp instance 1 root secondary
 Configure the root bridge and backup bridge for MSTI2.
# Set SwitchB as the root bridge of MSTI2.
[SwitchB] stp instance 2 root primary
# Set SwitchA as the root bridge of MSTI2.
[SwitchA] stp instance 2 root secondary
c. Set the path costs of the interfaces that you want to block on MSTI1 and MSTI2 to
be greater than the default value.
NOTE:
 The path cost range is decided by the algorithm. The Huawei proprietary
algorithm is used as an example. Set the path costs of the interfaces to 20000.
 The switches on the same network must use the same algorithm to calculate
path costs.
# Set the path cost algorithm on SwitchA to Huawei proprietary algorithm.
[SwitchA] stp pathcost-standard legacy
# Set the path cost algorithm on SwitchB to Huawei proprietary algorithm.
[SwitchB] stp pathcost-standard legacy
# Set the path cost algorithm on SwitchC to Huawei proprietary algorithm. Set the
path cost of GE0/0/1 in MSTI2 to 20000; set the path cost of GE0/0/4 in MSTI1 to
20000.
[SwitchC] stp pathcost-standard legacy

[SwitchC-GigabitEthernet0/0/1] stp instance 2 cost 20000
[SwitchC-GigabitEthernet0/0/4] stp instance 1 cost 20000
d. Enable MSTP to prevent loops.
# Enable MSTP on SwitchA.
[SwitchA] stp enable
# Enable MSTP on SwitchB.
[SwitchB] stp enable
# Enable MSTP on SwitchC.

[SwitchC] stp enable
 Disable MSTP on the interfaces connecting to hosts.
# Disable STP on GE0/0/2 and GE0/0/3 of SwitchC.

2. Enable the protection function on the designated interfaces of each root bridge.
# Enable root protection on GE0/0/1 of SwitchA.
[SwitchA] interface gigabitethernet 0/0/1

[SwitchA-GigabitEthernet0/0/1] stp root-protection
[SwitchA-GigabitEthernet0/0/1] quit
# Enable root protection on GE0/0/1 of SwitchB.

[SwitchB-GigabitEthernet0/0/1] stp root-protection
3. Configure Layer 2 forwarding on the switches in the ring.
 Create VLANs 2 and 3 on SwitchA, SwitchB, and SwitchC.
# Create VLANs 2 and 3 on SwitchA.
[SwitchA] vlan batch 2 to 3
# Create VLANs 2 and 3 on SwitchB.
[SwitchB] vlan batch 2 to 3
# Create VLANs 2 and 3 on SwitchC.
[SwitchC] vlan batch 2 to 3
 Add the interfaces connecting to the loops to VLANs.
# Add GE0/0/1 of SwitchA to VLANs.

[SwitchA-GigabitEthernet0/0/1] port link-type trunk
[SwitchA-GigabitEthernet0/0/1] port trunk allow-pass vlan 2 to 3
# Add GE0/0/2 of SwitchA to VLANs.

[SwitchA-GigabitEthernet0/0/2] port trunk allow-pass vlan 2 to 3
# Add GE0/0/1 of SwitchB to VLANs.

[SwitchB-GigabitEthernet0/0/1] port link-type trunk
[SwitchB-GigabitEthernet0/0/1] port trunk allow-pass vlan 2 to 3
# Add GE0/0/2 of SwitchB to VLANs.

[SwitchB-GigabitEthernet0/0/2] port link-type trunk
[SwitchB-GigabitEthernet0/0/2] port trunk allow-pass vlan 2 to 3
# Add GE0/0/1 of SwitchC to VLANs.

[SwitchC-GigabitEthernet0/0/1] port link-type trunk
[SwitchC-GigabitEthernet0/0/1] port trunk allow-pass vlan 2 to 3

[SwitchC-GigabitEthernet0/0/2] port link-type access
[SwitchC-GigabitEthernet0/0/2] port default vlan 2

[SwitchC-GigabitEthernet0/0/3] port link-type access
[SwitchC-GigabitEthernet0/0/3] port default vlan 3

[SwitchC-GigabitEthernet0/0/4] port link-type trunk
[SwitchC-GigabitEthernet0/0/4] port trunk allow-pass vlan 2 to 3
After the preceding configurations are complete and the network topology becomes
stable, perform the following operations to verify the configuration.
# Run the display stp brief command on SwitchA to view the status and protection type on
interfaces. The displayed information is as follows:
[SwitchA] display stp brief

In MSTI1, GE0/0/2 and GE0/0/1 of SwitchA are set as designated interfaces because
SwitchA is the root bridge of MSTI1. In MSTI2, GE0/0/1 of SwitchA is set as the designated
interface and GE0/0/2 is set as the root interface.
# Run the display stp brief command on SwitchB. The displayed information is as follows:
[SwitchB] display stp brief

MSTID Port
0 GigabitE
0 GigabitE
1 GigabitE
1 GigabitE
2 GigabitE
2 GigabitE
In MSTI2, GE0/0/1 and GE0/0/2 of SwitchB are set as designated interfaces because SwitchB
is the root bridge of MSTI2. In MSTI1, GE0/0/1 of SwitchB is set as the designated interface
and GE0/0/2 is set as the root interface.
# Run the display stp interface brief command on SwitchC. The displayed information is
as follows:
[SwitchC] display stp interface gigabitethernet 0/0/1 brief

0 GigabitEthernet0/0/1 ROOT FORWARDING NONE
1 GigabitEthernet0/0/1 ROOT FORWARDING NONE
2 GigabitEthernet0/0/1 ALTE DISCARDING NONE
[SwitchC] display stp interface gigabitethernet 0/0/4 brief
GE0/0/1 of SwitchC is the root interface of MSTI1, and is blocked in MSTI2. GE0/0/4 of
SwitchC is the root interface of MSTI2, and is blocked in MSTI1.
5. Connect devices.
# Assign an IP address to each interface, for example, the interfaces on SwitchA. The
configurations on SwitchB are similar to the configurations on SwitchA. For details, see
the configuration file.
[HUAWEI] sysname SwitchA
[SwitchA] vlan batch 4
[SwitchA-GigabitEthernet0/0/3] port trunk allow-pass vlan 4
[SwitchA] interface vlanif 2
[SwitchA-Vlanif2] ip address 10.1.2.102 24
[SwitchA-Vlanif2] quit
# Run OSPF on SwitchA, SwitchB, and routers. The configurations on SwitchA are used as
an example. The configurations on SwitchB are similar to the configurations on SwitchA. For
details, see the configuration file.
[SwitchA] ospf 1
[SwitchA-ospf-1] area 0
[SwitchA-ospf-1-area-0.0.0.0] network 10.1.2.0 0.0.0.255
[SwitchA-ospf-1-area-0.0.0.0] quit
[SwitchA-ospf-1] quit
6. Configure VRRP groups.
# Create VRRP group 1 on SwitchA and SwitchB. Set SwitchA as the master device, priority to
120, and preemption delay to 20 seconds. Set SwitchB as the backup device and retain
the default priority.

[SwitchA-Vlanif2] vrrp vrid 1 virtual-ip 10.1.2.100

1210
[SwitchA-Vlanif2] vrrp vrid 1 priority 120
[SwitchA-Vlanif2] vrrp vrid 1 preempt-mode timer delay 20
[SwitchB] interface vlanif 2
[SwitchB-Vlanif2] vrrp vrid 1 virtual-ip 10.1.2.100
[SwitchB-Vlanif2] quit
# Create VRRP group 2 on SwitchA and SwitchB. Set SwitchB as the master device, priority to
120, and preemption delay to 20 seconds. Set SwitchA as the backup device and retain
the default priority.
[SwitchB] interface vlanif 3

[SwitchB-Vlanif3] vrrp vrid 2 virtual-ip 10.1.3.100
[SwitchB-Vlanif3] vrrp vrid 2 priority 120
[SwitchB-Vlanif3] vrrp vrid 2 preempt-mode timer delay 20
[SwitchB-Vlanif3] quit
[SwitchA-Vlanif3] vrrp vrid 2 virtual-ip 10.1.3.100
# Set the virtual IP address 10.1.2.100 of VRRP group 1 as the default gateway of Host A,
and the virtual IP address 10.1.3.100 of VRRP group 2 as the default gateway of Host B.
# After completing the preceding configurations, run the display vrrp command on
SwitchA. SwitchA's VRRP status is master in VRRP group 1 and backup in VRRP group 2.
<SwitchA> display vrrp

Vlanif2 | Virtual Router 1
State : Master
Virtual IP : 10.1.2.100
Master IP : 10.1.2.102
PriorityRun : 120
PriorityConfig : 120
MasterPriority : 120
Preempt : YES Delay Time : 20 s
TimerRun : 1 s
TimerConfig : 1 s
Auth type : NONE
Virtual MAC : 0000-5e00-0101
Check TTL : YES
Config type : normal-vrrp
Backup-forward : disabled
Create time : 2012-05-11 11:39:18 UTC+08:00
Last change time : 2012-05-26 11:38:58 UTC+08:00

State : Backup
Virtual IP : 10.1.3.100
Master IP : 10.1.3.103
PriorityRun : 100
TimerRun : 1 s
TimerConfig : 1 s
Auth type : NONE
Virtual MAC : 0000-5e00-0102
Check TTL : YES
Create time : 2012-05-11 11:40:18 UTC+08:00
# Run the display vrrp command on SwitchB. SwitchB's VRRP status is backup in VRRP
group 1 and master in VRRP group 2.
<SwitchB> display vrrp

State : Backup
Virtual IP : 10.1.2.100
Master IP : 10.1.2.102
PriorityRun : 100
TimerRun : 1 s
TimerConfig : 1 s
Auth type : NONE
Virtual MAC : 0000-5e00-0101
Check TTL : YES
Create time : 2012-05-11 11:39:18 UTC+08:00

State : Master
Virtual IP : 10.1.3.100
Master IP : 10.1.3.103
PriorityRun : 120
TimerRun : 1 s
TimerConfig : 1 s
Auth type : NONE
Virtual MAC : 0000-5e00-0102
Check TTL : YES
Create time : 2012-05-11 11:40:18 UTC+08:00
Configuration File
#
sysname SwitchA
#
vlan batch 2 to 4
#
#
region-name RG1
instance 1 vlan 2
instance 2 vlan 3
#
interface Vlanif2
ip address 10.1.2.102 255.255.255.0
vrrp vrid 1 virtual-ip 10.1.2.100
vrrp vrid 1 priority 120
vrrp vrid 1 preempt-mode timer delay 20
#
interface Vlanif3
ip address 10.1.3.102 255.255.255.0
#
interface Vlanif4
ip address 10.1.4.102 255.255.255.0
#
stp root-protection
#
#
#
ospf 1
area 0.0.0.0
network 10.1.2.0 0.0.0.255
network 10.1.3.0 0.0.0.255
network 10.1.4.0 0.0.0.255
#
return
#
sysname SwitchB
#
vlan batch 2 to 3 5
#
#
region-name RG1
instance 1 vlan 2
instance 2 vlan 3
#
interface Vlanif2
ip address 10.1.2.103 255.255.255.0
#
interface Vlanif3
ip address 10.1.3.103 255.255.255.0
vrrp vrid 2 priority 120
vrrp vrid 2 preempt-mode timer delay 20
#
interface Vlanif5
ip address 10.1.5.103 255.255.255.0
#
stp root-protection
#
#
#
ospf 1
area 0.0.0.0
network 10.1.2.0 0.0.0.255
network 10.1.3.0 0.0.0.255
network 10.1.5.0 0.0.0.255
#
return
#
sysname SwitchC
#
vlan batch 2 to 3
#
#
region-name RG1
instance 1 vlan 2
instance 2 vlan 3
#
#
port default vlan 2
stp disable
#
port default vlan 3
stp disable
#
#
return
Chapter 11 Multicast
11.1 IP Multicast Basics
11.1.1 Introduction to IP Multicast
Definition
IP multicast transmission is a mode in which packets are transmitted from a source to a group of
receivers. Compared with unicast and broadcast transmission, IP multicast transmission saves
network bandwidth and reduces loads on networks. IP multicast is widely used in IPTV, real-time
data transmission, and multimedia conferencing services.
Purpose
Traditional IP communication supports two transmission modes: unicast and broadcast. In unicast
transmission, a source sends an independent data packet to each host that requiring its data. In
broadcast transmission, a source sends data to all the hosts on the local network segment, regardless
whether the hosts require its data. To transmit data to multiple destination hosts but not all hosts, a
source host uses the broadcast mode or sends multiple copies of data in unicast mode to the
destination hosts one by one, as shown in Figure 11-1-1.
Figure 11-1-1 Point-to-multipoint data transmission in unicast and broadcast modes
 In unicast mode, the amount of data transmitted on the network is proportional to the number
of users that require the data. If a large number of users require the same data, the source host
must send many copies of data to these users, consuming high bandwidth on the source host
and
network. Therefore, the unicast mode is not suitable for batch data transmission and is
applicable only to networks with a small number of users.
 In broadcast mode, data is sent to all hosts on a network segment regardless of whether they
require the data. This threatens information security and causes storms on the network
segment. Therefore, the broadcast mode is not suitable for data transmission from a source to
specified destinations and it also wastes network bandwidth.
In a summary, traditional unicast and broadcast modes cannot effectively

implement point-to-multipoint data transmission.
Multicast is a solution to point-to-multipoint data transmission. As shown in Figure 11-1-2, the

source sends only one copy of data, and all the hosts that require the data (HostA and HostC) can
receive the same data copy. HostB cannot receive the data.
Figure 11-1-2 Point-to-multipoint data transmission in multicast mode
Multicast has the following advantages over unicast and broadcast:
 Compared with the unicast mode, the multicast mode starts to copy data and distribute data
copies on the network node as far from the source as possible. Therefore, the amount of data
and network resource consumption will not increase greatly when the number of receivers
increases.
 Compared with the broadcast mode, the multicast mode transmits data only to receivers
that require the data. This saves network resources and enhances data transmission
security.
11.1.2 Multicast Concepts
Multicast transmits data from one source to multiple receivers. Figure 11-1-3 shows the multicast
transmission model. HostA and HostC are interested in information sent from Source and request
for reception of the information. The data sent from Source is received only by HostA and HostC.
Figure 11-1-3 Multicast transmission
 Multicast group: a group of receivers identified by an IP multicast address. User hosts (or
other receiver devices) that have joined a multicast group become members of the group and
can identify and receive the IP packets destined for the multicast group address.
 Multicast source: a sender of multicast data. Source in Figure 11-1-3 is a multicast source. A
multicast source can simultaneously send data to multiple multicast groups. Multiple
multicast sources can simultaneously send data to a multicast group. A multicast source does
not need to join any multicast groups.
 Multicast group member: a host that has joined a multicast group. HostA and HostC in
Figure
11-1-3 are multicast group members. Memberships in a multicast group change
dynamically. Hosts can join or leave a multicast group anytime. Members of a multicast
group are located anywhere on a network.
 Multicast router: a router or Layer 3 switch that supports IP multicast. The routers in Figure
11-1-3 are multicast routers. In addition to multicast routing functions, multicast
routers connected to user network segments provide multicast member management
functions.
Table 11-1-1 describes concepts involved in IP multicast by using TV channels and programs.
Table 11-1-1 Analogy between TV watching and multicast transmission

1210
3

1210
Table 11-1-1 Analogy between TV watching and multicast transmission
11.1.3 Multicast Service Models
Multicast service models differ for receiver hosts and do not affect multicast sources. A multicast
source sends multicast packets by using its own IP address as the source IP address and a group
address as the destination IP address. Depending on whether receiver hosts can select multicast
sources, two multicast models are defined: the Any-Source Multicast (ASM) model and Source-
Specific Multicast (SSM) model. The two models use multicast group addresses in different ranges.
ASM Model
The ASM model distributes multicast data based on group addresses. A group address identifies a
collection of network service, and multicast packets sent from any source to this address obtain the
same service. After joining a group, a host can receive multicast data sent from any source with
this group address as the destination address.
To improve security, multicast source filter policies can be configured on routers to permit or
deny packets from specified multicast sources. This filters data sent to receiver hosts.
In the ASM model, each group address must be unique on the entire multicast network. An ASM
group can only be used by a single application at a time. If two applications use the same ASM group
simultaneously, receiver hosts of the two applications receive traffic from both application sources.
This may result in network congestion and malfunction of receiver hosts of the applications.
SSM Model
The SSM model provides service for the data flow from specific sources to a specific group.
Receiver hosts can specify the sources from which they want to receive data when they join a group.
After joining the group, the hosts receive only the data sent from the specified sources.
The SSM model does not require globally unique group addresses. Each group address must be unique
for a multicast source. Different applications on a source must use different SSM groups. Different
applications on different sources can reuse SSM group addresses because each pair of source and
group has an (S, G). This model saves multicast group address without congesting the network.
11.1.4 Multicast Addresses
To enable multicast sources and group members to communicate, the network must provide
network-layer multicast service, which uses IP multicast addresses. To enable multicast data to be
correctly transmitted on the local physical network, the network must provide link-layer multicast
service, which uses multicast MAC addresses. A technology is required to map IP multicast
addresses to multicast MAC addresses.
IPv4 Multicast Addresses
The Internet Assigned Numbers Authority (IANA) allocates Class D addresses for IPv4 multicast. An
IPv4 address is 32 bits long, and the first four bits of a Class D IP address is 1110. Therefore,
multicast IP addresses range from 224.0.0.0 to 239.255.255.255. Table 11-1-2 describes IPv4
multicast addresses.
Table 11-1-2 Range and description of IPv4 multicast addresses
Class D Address Range
224.0.0.0-224.0.0.255
224.0.1.0-231.255.255.255
233.0.0.0-238.255.255.255
232.0.0.0-232.255.255.255
239.0.0.0-239.255.255.255
Table 11-1-2 List of permanent multicast group addresses
224.0.0.0
224.0.0.1
224.0.0.2
224.0.0.3
Table 11-1-2 List of permanent multicast group addresses
224.0.0.4
224.0.0.5
224.0.0.6
224.0.0.7
224.0.0.8
224.0.0.9
224.0.0.11
224.0.0.12
224.0.0.13
224.0.0.14
224.0.0.15
224.0.0.16
224.0.0.17
224.0.0.18
224.0.0.22
224.0.0.19-224.0.0.21
224.0.0.23-224.0.0.255
IPv6 Multicast Addresses
An IPv6 address is 128 bits long. The IPv6 multicast address format is defined in RFC 4291, as
Figure 11-1-4 IPv6 multicast address format
Compared with an IPv4 multicast address, an IPv6 multicast address has a Group ID field to identify
a multicast group.
 0xFF: The high-order eight bits are 11111111, indicating that the address is a multicast address.
All IPv6 multicast addresses start with FF.
 Flags: It is 4 bits long and identifies the state of a multicast address.
Figure 11-1-5 Format of the Flags field
Table 11-1-3 Description of flag values
R flag
P flag
T flag
 Scope: It is 4 bits long and identifies the scope of a multicast group, for example, whether a
multicast group covers nodes in the same network, same site, same organization or any node
in
the global address space.
Table 11-1-4 Description of Scope field values

0, 3, F
Others
 Group ID: It is 112 bits long and identifies a unique multicast group in the range specified by
the Scope field. The Group ID can be permanently or temporarily assigned, depending on the
value of the T flag in the Flags field.
Table 11-1-5 Range and description of IPv6 multicast addresses
FF0x::/32
FF1x::/32 (x is not 1 or 2) FF2x::/32 (x is not 1 or 2)
FF3x::/32 (x is not 1 or 2)
Table 11-1-6 Commonly used IPv6 multicast addresses
Range
Node/interface-local scope
Link-local scope
Table 11-1-6 Commonly used IPv6 multicast addresses
Range
Site-local scope
IPv4 Multicast MAC Addresses
When unicast IPv4 packets are transmitted on an Ethernet network, the packets use receiver MAC
addresses as destination MAC addresses. However, the destination of a multicast data packet is a
group with changeable members but not a specific receiver. Therefore, multicast data packets must
use IPv4 multicast MAC addresses on an Ethernet network. IPv4 multicast MAC addresses are link-
layer addresses mapped from IPv4 multicast addresses.
As defined by the IANA, leftmost 24 bits of an IPv4 multicast MAC address are 0x01005e, the 25th
bit is 0, and the rightmost 23 bits are the same as the rightmost 23 bits of a multicast IPv4 address, as
shown in Figure 11-1-6. Multicast MAC address 01-00-5e-00-01-01 is mapped to IP multicast address
224.0.1.1.
Figure 11-1-6 Mapping between an IPv4 multicast address and an IPv4 multicast MAC
address
The first four bits of an IPv4 multicast address is 1110, mapping the leftmost 25 bits of a
multicast
MAC address. Only 23 bits of the last 28 bits are mapped to a MAC address. That is, information
about
5 bits of the IP address is lost. As a result, 32 multicast IP addresses are mapped to the same MAC
address. For example, IP multicast addresses 224.0.1.1, 224.128.1.1, 225.0.1.1, and 239.128.1.1 are all
mapped to multicast MAC address 01-00-5e-00-01-01. Address conflicts must be considered in
address assignment.
IPv6 Multicast MAC Addresses
In an IPv6 multicast MAC address, the leftmost 16 bits are 0x3333, and the rightmost 32 bits
are mapped to the rightmost 32 bits of an IPv6 multicast address. Figure 11-1-7 shows the
mapping between IPv6 multicast address FF01::1111:1 and an IPv6 multicast MAC address.
Figure 11-1-7 Mapping between an IPv6 multicast address and an IPv6 multicast MAC
address
The figure shows that more IPv6 multicast addresses are mapped to the same multicast MAC
address.
11.1.5 Multicast Protocols

In IP multicast transmission, the sender only needs to send data to a specified destination address and
does not need to know the locations of receivers. It is the responsibility of network devices to
forward data from the sender to the receivers. Routers on the multicast network must collect
information about
receivers, and forward and replicate multicast packets along correct paths. A set of protocols
are developed to complete these tasks.
 Receiver information is collected and managed using the Internet Group Management
Protocol (IGMP) or Multicast Listener Discovery (MLD). IGMP applies to IPv4 networks,
and MLD applies to IPv6 networks.
 Forwarding paths are established for multicast packets by various multicast routing
protocols, among which Protocol Independent Multicast (PIM) is the most widely used. PIM
is an
intra-domain multicast routing protocol. Inter-domain multicast transmission requires the
Multicast Source Discovery Protocol (MSDP), and multicast transmission between
autonomous systems (ASs) requires the MultiProtocol Border Gateway Protocol (MBGP).
On a small-sized network, all multicast routers are located in the same PIM domain. Figure 11-1-8
shows a multicast network with a single PIM domain.
Figure 11-1-8 Multicast network with a single PIM domain
Table 11-1-7 Protocols used on a multicast network with a single PIM domain
IGMP (IPv4) MLD (IPv6)
Table 11-1-7 Protocols used on a multicast network with a single PIM domain
PIM Dense Mode (PIM-DM) or

PIM Sparse Mode (PIM-SM)
IGMP snooping (IPv4) MLD snooping (IPv6)
A multicast domain can be divided into multiple isolated PIM-SM domains to facilitate management
of multicast resources, including multicast groups, multicast sources, and group members. Figure 11-
1-9 shows a multicast network spanning multiple PIM-SM domains.
Figure 11-1-9 Multicast network with multiple PIM-SM domains
The MSDP protocol must be deployed between the PIM-SM domains to enable the PIM-SM
domains to exchange multicast data. An MSDP peer relationship is established between the PIM-SM
domains, and MSDP peers exchange SA messages to obtain each other's multicast information.
Then receiver hosts in one PIM-SM domain can receive data from a multicast source in another PIM-
SM domain. MSDP applies only to IPv4 networks and is useful only in the ASM model. Within a
PIM domain, IGMP manages group memberships, and PIM-SM maintains multicast forwarding
routes.
PIM forwards multicast data based on a unicast routing table; therefore, multicast forwarding paths
are the same as unicast forwarding paths. When a multicast source and receivers are located in
different ASs, a multicast distribution tree needs to be set up between the ASs. In this scenario,
MBGP can be used to create a multicast routing table independent of the unicast routing table. Then
multicast data is transmitted based on the multicast routing table. Figure 11-1-10 shows a multicast
network spanning multiple ASs.
NOTE:
For details about MBGP, see "BGP" in Feature Description - IP Routing.

1210
Figure 11-1-10 Multicast network with multiple ASs
11.1.6 Multicast Packet Forwarding
In unicast transmission, the destination address of a packet indicates a specific receiver. Unicast
forwarding paths are established based on destination addresses of packets. Each routing entry
records the outbound interface through which a packet can be forwarded to a destination. When a
router receives a unicast packet, it searches the routing table based on the destination address to
select the optimal path to the destination network segment. Then the router forwards the packet
through the outbound interface specified in the matching routing entry.
In multicast transmission, the destination address of a packet indicates a group but of a specific
receiver. A multicast source only needs to send information to a specified destination address and does
not need
to know how many members need to receive the information. Multicast routers must ensure
that information from the source is correctly forwarded to group members.
The source address of a multicast packet is a unicast address. When a router receives a multicast
packet, it checks the unicast route destined for the source address to determine whether the inbound
interface is on the optimal path to the multicast source. This process is reverse path forwarding (RPF)
check. When the packet passes the RPF check, the router copies the packet to multiple outbound
interfaces.
Therefore, multicast forwarding paths are established based on multicast source addresses in either
of the following ways:
 Dynamically generated using the RPF check mechanism. Routers perform RPF check for
received multicast packets. When multicast packets pass the RPF check, routers create
multicast routing entries and establish distribution paths to downstream routers. For details, see
RPF Check.
 Manually configured: Static multicast routes are manually configured on routers. Each route
specifies outbound interfaces for a multicast source address. Routers forward packets to
specified outbound interfaces and establish distribution paths to downstream routers. For details,
see Multicast Static Route.
11.2 IGMP
11.2.1 IGMP Versions
Currently, IGMP has three versions:
 IGMPv1 defined in RFC 1112
IGMPv1 defines the multicast member query and report processes. IGMPv2 extends IGMPv1 by
adding the querier election and member leave mechanisms. IGMPv3 adds the function that allows
hosts to specify the multicast sources from which they want to or not want to receive data. The IGMP
versions are backward compatible. Therefore, a multicast router running a later IGMP version can
identify Membership Report messages sent from hosts running an earlier IGMP version, although the
IGMP messages in different versions use different formats.
All IGMP versions support the Any-Source Multicast (ASM) model. IGMPv3 can be independently
used in the Source-Specific Multicast (SSM) model, whereas IGMPv1 and IGMPv2 must be used
with SSM mapping. For details about the ASM and SSM models, see IP Multicast Basics.
11.2.2 IGMPv1 Rationale
IGMPv1 Messages
IGMP messages are encapsulated in IP packets. IGMPv1 defines the following types of messages:
 General Query: A querier sends General Query messages to all hosts and routers on the
shared network segment to discover which host groups have members on the network
segment.
 Report: Hosts send Report messages to multicast switches to request to join a multicast group
or respond to General Query messages.
How IGMPv1 Works
IGMPv1 uses a query-report mechanism to manage multicast groups. When multicast routers exist on
a network segment, one router is elected as the IGMP querier to send Query messages. In IGMPv1
implementation, a unique Assert winner or designated router (DR) is elected by Protocol Independent
Multicast (PIM) to work as the querier. The querier is the only device that sends Host Membership
Query messages on the local network segment.
For details about Assert and DR election, see PIM.
General query and report
Figure 11-2-1 IGMPv1 general query and report

As shown in Figure 11-2-1, RouterA and RouterB connect to a user network segment with three
receivers: HostA, HostB, and HostC. RouterA is the querier on the network segment. HostA and
HostB want to receive data sent to multicast group G1, and HostC wants to receive data sent to
multicast
group G2. The general query and report process is as follows:
1. The IGMP querier (RouterA) sends a General Query message with the destination address
224.0.0.1 (indicating all hosts and routers on the same network segment). The IGMP querier
sends General Query messages at intervals. The interval can be configured using a
command, and the default interval is 60 seconds.
2. All hosts on the network segment receive the General Query message. Then HostA and HostB
start a timer for G1 (Timer-G1), and HostC starts a timer for G2 (Timer-G2). The timer length
is a random value between 0 and 10, in seconds.
3. The host with the timer expiring first sends a Report message for the multicast group. In
this example, the Timer-G1 on HostA expires first, and HostA sends a Report message with
the
destination address as G1. When HostB detects the Report message sent by HostA, HostB
stops Timer-G1 and does not send any Report messages for G1. This listening mechanism
reduces the number of Report messages transmitted on the network segment, lowering loads on
multicast routers.
4. When Timer-G2 on HostC expires, HostC sends a Report message with the destination
address as G2 to the network segment.
5. After the routers receive the Report message, they know that multicast groups G1 and G2
have members on the local network segment. Then the routers use the multicast routing
protocol to create (*, G1) and (*, G2) entries, in which * stands for any multicast source.
Once the routers receive data sent to G1 and G2, they forward the data to this network
segment.
A new member joins a group
Figure 11-2-2 A new member joins a group

As shown in Figure 11-2-2, HostD connects to the network segment. HostD wants to join multicast
group G3 but detects no multicast data for G3. In this case, HostD immediately sends a Report
message for G3 without waiting for a General Query message. After receiving the Report message, the
router s know that a number of G3 has connected to the network segment, and they create a (*, G3)
entry. Once the routers receive data sent to G3, they forward the data to this network segment.
A member leaves a group
IGMPv1 does not define the Leave message. After a host leaves a multicast group, it no longer
responds to General Query messages. Assume that HostC has left group G2. It does not send
Report messages for G2 when receiving General Query messages. Because G2 has not member on
this network segment, the routers no longer receive Report messages for G2. After a fixed period
(130 seconds), the routers delete the (*, G2) entry.
The routers will not know if HostA leaves G1 because G1 still has a member HostB on the
network segment.
11.2.3 Changes in IGMPv2
IGMPv2 Messages
IGMPv2 defines two types of new messages in addition to General Query and Report messages:
 Group-Specific Query: A querier sends a Group-Specific Query message to a specified group

on the shared network segment to check whether the group has members on the network
segment.
 Leave: A host sends a Leave message to notify routers on the local network segment that it
has left a group.
IGMPv2 adds a new field Max Response Time to General Query messages. The field value controls
the response speed of group members and is configurable.
How IGMPv2 Works
Compared with IGMPv1, IGMPv2 adds the querier election and leave mechanisms.
Querier election
IGMPv2 defines an independent querier election mechanism. When multiple multicast routers exist in
a shared network segment, the router with the smallest IP address works as the querier.
Figure 11-2-3 Querier election
1. Each IGMPv2 router considers itself as a querier when it starts and sends a General
Query message to all hosts and routers on the local network segment.
2. When other routers receive a General Query message, they compare the source IP address of
the message with their own interface IP addresses. The router with the smallest IP address
becomes
the querier, and the other routers are non-queriers. As shown in Figure 11-2-3, RouterA
becomes the querier because it has a smaller interface address than RouterB.
3. All non-queriers start a timer (Other Querier Present Timer). If non-queriers receive a Query
message from the querier before the timer expires, they reset the timer. If non-queriers
receive no Query message from the querier when the timer expires, they trigger election of a
new querier.
Leave mechanism
Figure 11-2-4 A host leaves a group

As shown in Figure 11-2-4, when HostC wants to leave multicast group G2:
1. HostC sends a Leave message for G2 to all multicast routers on the local network segment.
The destination address of the Leave message is 224.0.0.2.
2. When the querier receives the Leave message, it sends Group-Specific Query messages for G2
at intervals to check whether G2 has other members on the network segment. The sending
interval and number of Group-Specific Query messages sent by the querier are configurable.
By default, the querier sends a total of two Group-Specific Query messages, at an interval of 1
second. In addition, the querier starts the membership timer (Timer-Membership). The timer
length is calculated using the following formula:
Timer-Membership = Interval for sending Group-Specific Query messages x Number

of messages sent
3. If G2 has no member on the network segment, the routers cannot receive any Report message
for G2. After Timer-Membership expires, the routers delete the downstream interface
connected to the network segment from the (*, G2) entry. Then the routers no longer forward
data of G2 to the network segment.
4. If G2 has other members on the network segment, the members send a Report message for
G2 within the maximum response time defined in the Group-Specific Query message. The
routers continues maintaining membership of G2.
11.2.4 Changes in IGMPv3
IGMPv3 was developed to support the Source-Specific Multicast (SSM model). IGMPv3 messages
can contain multicast source information so that hosts can receive data sent from a specific source to a
specific group.
IGMPv3 Messages
IGMPv3 also defines two types of messages: Query messages and Report messages. Compared with
IGMPv2, IGMPv3 has the following changes:
 In addition to General Query and Group-Specific Query messages, IGMPv3 defines a new
Query message type: Group-and-Source-Specific Query. A querier sends a Group-and-Source-
Specific Query message to members of a specific group on the shared network segment, to
check whether the group members are interested in data from specific sources. A Group-and-
Source-Specific Query message carries one or more multicast source addresses.
 A host sends a Report message to notify a multicast router that it wants to join a multicast group
and receive data from specified multicast sources. IGMPv3 supports source filtering and defines
two filter modes: INCLUDE and EXCLUDE. In IGMPv3, group-source mappings are
represented by (G, INCLUDE, (S1, S2...)) or (G, EXCLUDE, (S1, S2...)). A (G, INCLUDE,
(S1, S2...)) entry indicates that members of group G receive only data sent from sources S1, S2,
and
so on. A (G, EXCLUDE, (S1, S2...)) entry indicates that members of group G receive data
from multicast sources except S1, S2, and so on.
When mappings between multicast groups and sources change, a multicast router sends an
IGMPv3 Report message with Group Record fields to the querier on the network segment.
Group Records are classified into six types, as described in Table 11-2-1.
Table 11-2-1 Group Record types in IGMPv3 Report messages
Current-State Record, sent in response to a Query message to report the current state of the local system.
Table 11-2-1 Group Record types in IGMPv3 Report messages
Filter-Mode-Change Record, sent when the source filter mode for a multicast group changes from INCLUDE to EXC
Source-List-Change Record, sent when the source list of a multicast group changes.
An IGMPv3 Report message can carry information about multiple multicast groups, whereas an
IGMPv1 or IGMPv2 Report message carries information about only one multicast
group. IGMPv3 greatly reduces the number of messages transmitted on a network.
IGMPv3 does not define dedicated Leave message. Group members send Report messages of a
specified type to notify multicast routers that they leave a multicast group. For example, if a member
of group 225.1.1.1 wants to leave the group, it sends a Report message with (225.1.1.1, TO_IN, (0)).
How IGMPv3 Works
Compared with IGMPv2, IGMPv3 allows hosts to select multicast sources.
Joining a specific source and group
IGMPv3 Report messages have a destination address 224.0.0.22, indicating all IGMPv3-capable
multicast routers on the same network segment. A Report message contains Group Record fields,
allowing hosts to specify the multicast sources from which they want to or not want to receive data
when joining a multicast group. As shown in Figure 11-2-5, two multicast sources S1 and S2 send
data to multicast group G. The host only wants to receive data sent from S1 to G.
Figure 11-2-5 Source-and-group-specific multicast data transmission

If IGMPv1 or IGMPv2 is running between the host and its upstream router, the host cannot select
multicast sources when it joins group G. The host receives data from both S1 and S2, regardless of
whether it requires the data. If IGMPv3 is running between the host and its upstream router, the
host can choose to receive only data from S1 using either of the following methods:
 Method 1: Send an IGMPv3 Report (G, IS_IN, (S1)), requesting to receive only the data
sent from S1 to G.
 Method 2: Send an IGMPv3 (G, IS_EX, (S2)), notifying the upstream router that it does not
want to receive data from S2. Then only data sent from S1 is forwarded to the host.
Group-and-Source-Specific Query
When a querier receives a Report message containing a Filter-Mode-Change Record or

Source-List-Change Record (the last four types listed in Table 11-2-1), the querier sends
Group-and-Source-Specific Query messages. If a member wants to receive the data from any source
in the source list, it sends a Report message. The multicast router updates the source list of the
corresponding group according to the received Report messages.
11.2.5 IGMP SSM Mapping
Source-Specific Multicast (SSM) requires multicast routers to know multicast sources that hosts
specify when they join a multicast group. A host running IGMPv3 can specify multicast source
addresses in IGMPv3 Report messages. Some hosts can run only IGMPv1 or IGMPv2. To enable
such hosts to obtain the SSM service, multicast routers need to provide the IGMP SSM mapping
function.
After static SSM mapping entries are configured on a multicast router, the router can convert (*, G)
information in IGMPv1 and IGMPv2 Report messages to (S, G) information to provide the SSM
service for the IGMPv1 and IGMPv2 hosts. By default, SSM group addresses range from 232.0.0.0
to
232.255.255.255. For details about SSM group addresses, see PIM-SSM.
With SSM mapping entries configured, a multicast router checks the multicast group address G in
each received IGMPv1 or IGMPv2 Report message, and processes the message based on the check
result:
 If G is in the range of Any-Source Multicast (ASM) group addresses, the router provides the
ASM service for the host.
 If G is in the range of SSM group addresses:
 When the router has no SSM mapping entry matching G, it does not provide the SSM
service and drops the Report message.
 If the router has an SSM mapping entry matching G, it converts (*, G) information in the
Report message into (S, G) information and provides the SSM service for the host.
NOTE:
IGMP SSM mapping does not apply to IGMPv3 Report messages. To enable hosts running any IGMP
version on a network segment to obtain the SSM service, IGMPv3 must run on interfaces of multicast
routers on the network segment.
As shown in Figure 11-2-6, HostA runs IGMPv3, HostB runs IGMPv2, and HostC runs IGMPv1 on
an SSM network. HostB and HostC cannot run IGMPv3. To provide the SSM service for all the
hosts on the network segment, IGMP SSM mapping must be configured on the Router.
Figure 11-2-6 SSM mapping

1210
The following table lists the SSM mapping entries configured on the
Router.
Table 11-2-2 SSM mapping entries

1210
Multicast Group Address
232.0.0.0/8
232.1.0.0/16
232.1.0.0/16
232.1.1.0/24
When the Router receives Report messages from HostB and HostC, it checks whether the
multicast
group addresses in the messages are in the SSM group address range. If so, the Router generates (S,
G) entries based on the SSM mappings (see the following table). If a group address is mapped to
multiple sources, the Router generates multiple (S, G) entries.
Table 11-2-3 Multicast address
232.1.1.1 (from HostC)
232.1.2.2 (from HostB)
NOTE:
The Router generates an (S, G) entry as long as a multicast group addr ess matches an SSM
mapping entry. Therefore, the Router generates four (S, G) entries for 232.1.1.1, and three (S, G)
entries for
232.1.2.2.
11.3 Layer 2 Multicast
11.3.1 IGMP/MLD Snooping
Principles
IGMP/MLD snooping is a basic Layer 2 multicast function that forwards and controls multicast
traffic at Layer 2. IGMP/MLD snooping runs on a Layer 2 device and analyzes IGMP/MLD
messages exchanged between a Layer 3 device and hosts to set up and maintain a Layer 2 multicast
forwarding table. The Layer 2 device forwards multicast packets based on the Layer 2 multicast
forwarding table.
NOTE:
IGMP snooping applies to IPv4 multicast networks, while MLD snooping applies IPv6 multicast
networks. The implementation of these two technologies is the same, except that they use different
address types and define different protocol packets. The following describes IGMP snooping
implementation as an example.
As shown in Figure 11-3-1, after receiving multicast packets from a Layer 3 device Router, Switch at
the edge of the access layer forwards the multicast packets to receiver hosts. If Switch does not run
IGMP snooping, it broadcasts multicast packets at Layer 2. After IGMP snooping is configured,
Switch forwards multicast packets only to specified hosts.
With IGMP snooping configured, Switch listens on IGMP messages exchanged between Router and
hosts. It analyzes packet information (such as packet type, group address, and receiving interface) to
set up and maintain a Layer 2 multicast forwarding table, and forwards multicast packets based on the
Layer 2 multicast forwarding table.
Figure 11-3-1 Multicast packet transmission before and after IGMP snooping is configured on a Layer
2 device
Concepts
As shown in Figure 11-3-2, Router connects to the multicast source. IGMP snooping is configured on
SwitchA and SwitchB. HostA, HostB, and HostC are receiver hosts.
Figure 11-3-2 IGMP snooping ports
Figure 11-3-2 shows IGMP snooping ports. The following table describes these ports.
Table 11-3-1 IGMP snooping ports
Port Role Function Generation

Router port A router port receives multicast A dynamic router port is

Ports marked as blue points on packets from a Layer 3 multicast
SwitchA and SwitchB. device such as a designated generated by MLD/IGMP
NOTE: router (DR) or IGMP querier. snooping. A port becomes
a dynamic router port
A router port is a port on a Layer
2 multicast device and connects when it receives an IGMP
to an upstream multicast router. General Query message or
PIM Hello message with
any source address except
0.0.0.0. The PIM Hello
messages are sent from the
PIM port on a Layer 3
multicast device to
discover and maintain
neighbor relationships.
 A static router port is
manually configured.
Table 11-3-1 IGMP snooping ports
Member port
Ports marked as yellow points on SwitchA and SwitchB.
The router port and member port are outbound interfaces in Layer 2 multicast forwarding entries.
A router port functions as an upstream interface, while a member port functions as a downstream
interface. Port information learned through protocol packets is saved as dynamic entries, and port
information manually configured is saved as static entries.
Besides the outbound interfaces, each entry includes multicast group addresses and VLAN IDs.
 Multicast group addresses can be multicast IP addresses or multicast MAC addresses mapped
from multicast IP addresses. In MAC address-based forwarding mode, multicast data may be
forwarded to hosts that do not requires the data because multiple IP addresses are mapped to
the same MAC addresses. The IP address-based forwarding mode can prevent this problem.
 The VLAN ID specifies a Layer 2 broadcast domain. After multicast VLAN is configured, the
inbound VLAN ID is the multicast VLAN ID, and the outbound VLAN ID is a user VLAN ID.
If multicast VLAN is not configured, both the inbound and outbound VLAN IDs are the ID of
the VLAN to which a host belongs. For details about multicast VLAN, see Multicast VLAN.
Implementation
After IGMP snooping is configured, the Layer 2 multicast device processes the received IGMP
protocol packets in different ways and sets up Layer 2 multicast forwarding entries.
Table 11-3-2 IGMP message processing by IGMP snooping
IGMP Working Phase IGMP Message Received on Processing Method

a
Layer 2 Device
General query IGMP General Query message A Layer 2 device forwards

The IGMP querier periodically IGMP General Query messages
sends General Query messages to to all ports excluding the port
all hosts and the router (224.0.0.1) receiving the messages. The
on the local network segment, to Layer 2 device processes the

a
Layer 2 Device
check which multicast groups receiving port as follows:

have members on the network
 If the port is included in
segment.
the router port list, the
Layer 2 device resets the
aging timer of the router
port.
 If the port is not in the
router port list, the Layer
2 device adds it to the list
and starts the aging timer.
NOTE:
By default, the Layer 2 device
sets the aging time to 180
seconds when the router port
receives an IGMP General
Query message. You can set the
aging time using a command.
Membership report A Layer 2 device forwards an

IGMP Report message
Membership Report messages are IGMP Report message to all
used in two scenarios: router ports in a VLAN. The
Layer 2 device obtains the
 Upon receiving an IGMP
multicast group address from
General Query message, a the Report message and
member returns an IGMP performs the following
operations on the port receiving
Report message. the message:
 A member sends an IGMP Report message to the
IGMP querier to announce its joining to a multicast group.


a
Layer 2 Device
outbound interface list as

a dynamic member port,
and starts the aging timer.
 If the multicast group
matches a forwarding
entry and the port is in the
router port list, the Layer
2 device resets the aging
timer.
NOTE:
Aging time of a dynamic router
port = Robustness variable x
General query interval +
Maximum response time for
General Query messages
Leave of multicast members IGMP Leave message The Layer 2 device determines
There are two phases: whether the multicast group
matches a forwarding entry and
1. An IGMPv2/IGMPv3 whether the port that receives
member sends an IGMP the message is in the outbound
interface list.
Leave message to notify
routers on the local  If no forwarding entry
network segment that it has matches the multicast

left a multicast group. group or the outbound
interface list of the
2. Upon receiving the IGMP
matching entry does not
Leave message, the IGMP
contain the receiving port,
querier obtains the
the Layer 2 device drops
multicast group address
the IGMP Leave message.
and sends an IGMP
Group-Specific/Group-Sou  If the multicast group
rce-Specific Query matches a forwarding
message to the multicast entry and the port is in the
group. outbound interface list,
the Layer 2 device
forwards the IGMP Leave
message to all router ports
in the VLAN.
The following assumes that the
port receiving an IGMP Leave
message is a dynamic member

a
Layer 2 Device
port. Within the aging time of

the member port:
 If the port receives IGMP
Report messages in
response to the IGMP
Group-Specific Query
message, the Layer 2
device knows that the
multicast group has
members connected to the
port and resets the aging
timer.
 If the port receives no
IGMP Report message in
response to the IGMP
Group-Specific Query
message, no member of
the multicast group exists
under the interface. Then
the Layer 2 device deletes
the port from the
outbound interface list
when the aging time is
reached.
IGMP An IGMP
Group-Specific/Group-Source- Group-Specific/Group-Source-
Specific Query message Specific Query message is
forwarded to all ports in a
VLAN excluding the port
receiving the message.
Upon receiving a PIM Hello message, a Layer 2 device forwards the message to all ports excluding
the port that receives the Hello message. The Layer 2 device processes the receiving port as follows:
 If the port is included in the router port list, the device resets the aging timer of the router port.
 If the port is not in the router port list, the device adds it to the list and starts the aging timer.
NOTE:
When the Layer 2 device receives a PIM Hello message, it sets the aging time of the router port to the
Holdtime value in the Hello message.
If a static router port is configured, the Layer 2 device forwards received IGMP Report and Leave
messages to the static router port. If a static member port is configured for a multicast group, the
Layer
2 device adds the port to the outbound interface list for the multicast group.
After a Layer 2 multicast forwarding table is set up, the Layer 2 device searches the multicast
forwarding table for outbound interfaces of multicast data packets according to the VLAN IDs and
destination addresses (group addresses) of the packets. If outbound interfaces are found for a packet,
the Layer 2 device forwards the packet to all the member ports of the multicast group. If no
outbound interface is found, the Layer 2 device drops the packet or broadcasts the packet in th e
VLAN.
11.3.2 IGMP/MLD Snooping Proxy
Principles
IGMP/MLD snooping proxy can be configured on a Layer 2 device. The Layer 2 device then
functions as a host to send IGMP Report messages to the upstream Layer 3 device. This function
reduces the number of IGMP Report/MLD Report and IGMP Leave/MLD Done messages sent to the
upstream Layer 3 device. A device configured with IGMP/MLD snooping proxy functions as a host
for its upstream device and a querier for its downstream hosts.
NOTE:
IGMP snooping proxy applies to IPv4 multicast networks, while MLD snooping proxy applies to IPv6
multicast networks. The implementation of these two technologies is the same, except that they use
different address types and define different protocol packets. The following uses IGMP snooping
proxy implementation as an example.
As shown in Figure 11-3-3, when Switch runs IGMP snooping, it forwards IGMP Query, Report,
and Leave messages transparently to the upstream Router. When numerous hosts exist on the
network, redundant IGMP messages increase the burden of Router.
With IGMP snooping proxy configured, Switch can terminate IGMP Query messages sent from
Router and IGMP Report/Leave sent from downstream hosts. When receiving these messages, Switch
constructs new messages to send them to Router.
Figure 11-3-3 Networking diagram of IGMP snooping proxy
After IGMP snooping proxy is deployed on the Layer 2 device, the Layer 3 device considers that it
interacts with only one user. The Layer 2 device interacts with the upstream device and downstream
hosts. The IGMP snooping proxy function conserves bandwidth by reducing IGMP message
exchanges. In addition, IGMP snooping proxy functions as a querier to process protocol messages
received from downstream hosts and maintain group memberships. This reduces the load of the
upstream Layer 3 device.
Implementation
A device that runs IGMP snooping proxy sets up and maintains a Layer 2 multicast forwarding table
and sends multicast data to hosts based on the multicast forwarding table. Table 11-3-3 describes
how the IGMP snooping proxy device processes IGMP messages.
Table 11-3-3 received IGMP message processing by IGMP snooping proxy
IGMP General Query message

Table 11-3-3 received IGMP message processing by IGMP snooping proxy
IGMP Group-Specific/Group-Source-Specific
Query message
IGMP Report message
IGMP Leave message
11.3.3 Layer 2 SSM Mapping
Compared to Any-Source Multicast (ASM), Source-Specific Multicast (SSM) conserves multicast

addresses and has higher security. Only IGMPv3 and MLDv2 support SSM. A host running IGMPv3
or MLDv2 can specify multicast source addresses in IGMP Report messages. Some hosts can run
only IGMPv1, IGMPv2, or MLDv1. To enable such hosts to obtain the SSM service, multicast
routers need to provide the IGMP/MLD SSM mapping function.
Layer 2 SSM mapping is used to implement SSM mapping on Layer 2 networks. Currently, only IPv4
multicast networks support Layer 2 SSM mapping that is implemented based on IGMP snooping.
After static SSM mapping entries are configured on a multicast device, the device can convert (*, G)
information in IGMPv1 and IGMPv2 Report messages to (S, G) information to provide the SSM
service for IGMPv1 and IGMPv2 hosts. S indicates the multicast source, G indicates the multicast

1210
group, and the asterisk (*) indicates any multicast source. By default, SSM group addresses range from
232.0.0.0 to 232.255.255.255.
As shown in Figure 11-3-4, HostA runs IGMPv3, HostB runs IGMPv2, and HostC runs IGMPv1 on
an SSM network. HostB and HostC cannot run IGMPv3. To provide the SSM service for all the hosts
on the network segment, configure IGMP SSM mapping on Switch.
Figure 11-3-4 Networking diagram of Layer 2 SSM mapping

The following table lists the SSM mapping entries configured on Switch.
Multicast Group Address
232.1.1.0/24
232.1.2.0/24
232.1.3.0/24
When Switch receives Report messages from HostB and HostC, it checks whether the multicast
group addresses in the messages are within the SSM group address range. If so, Switch generates (S,
G)
entries based on the SSM mappings, as shown in the following table.

Multicast Group Address in IGMPv1/IGMPv2 Generated Multicast Forwarding Entry
Report
232.1.1.1 (from HostC) (10.10.1.1, 232.1.1.1)
232.1.2.2 (from HostB) (10.10.2.2, 232.1.2.2)
When the multicast group address in a Report message is within the SSM group address range,
but Switch no SSM mapping entry matching the multicast group address, it does not provide the
SSM service and drops the Report message.
If the multicast group address in a Report message is out of the SSM group address range,
Switch provides only the ASM service.
11.3.4 Multicast VLAN
Principles
On a Layer 2 broadcast network, multicast data is broadcast to all hosts. The IGMP snooping
function solves this problem. This function, however, takes effect based on a VLAN. If users in
different VLANs require the same multicast data, the upstream router still has to send multiple copies
of identical multicast data to different VLANs. As shown in Figure 11-3-5, users in VLAN 2 and
VLAN
3 need to receive the same multicast data flows. RouterA replicates the multicast data in each VLAN
and sends two copies of data to SwitchA. This wastes bandwidth between the router and Layer 2
device and increases burden on the router.
The multicast VLAN function can be configured on the Layer 2 device to implement inter -VLAN
multicast replication. As shown in Figure 11-3-5, after the multicast VLAN function is configured
on SwitchA, RouterA replicates multicast data in VLAN 4 and sends only one copy to the SwitchA.
RouterA no longer needs to send several identical multicast data flows downstream. This saves
network bandwidth and reduces the burden on the router.
Figure 11-3-5 Multicast data flow processing before and after multicast VLAN is configured
Concepts
 Multicast VLAN: VLAN to which a network-side interface belongs. A multicast VLAN is

used to aggregate multicast data flows. One multicast VLAN can be bound to multiple user
VLANs.
 User VLAN: VLAN to which a user-side interface belongs. A user VLAN is used to receive
multicast data flows from the multicast VLAN. A user VLAN can be bound only to one
multicast VLAN.
Multicast VLAN Extensions
In most cases, the multicast VLAN replicates multicast data and sends identical data to different user
VLANs to save bandwidth. Sometimes, a single user VLAN needs to receive multicast data from
multiple multicast VLANs. To meet this requirement, the multicast VLAN function is extended
as follows:
 N-to-N multicast replication
N-to-N multicast replication supplements the traditional 1-to-N multicast replication. In 1-to-N
multicast replication, multiple user VLANs can be bound to one multicast VLAN, but a user
VLAN can be bound only to one multicast VLAN. As shown in Figure 11-3-6, the user VLAN
(UVLAN) needs multicast data from multicast VLANs (MVLANs) MVLAN1 and MVLAN2.
The N-to-N multicast replication meets this requirement. The implementation process is
as follows:
1. Enable static multicast flow triggering in UVLAN.
2. Configure static multicast flows for Source1 and Source2 in the multicast VLANs.
3. Bind UVLAN to MVLAN1 and MVLAN2.
The implementation requires static multicast flow triggering and 1-to-N multicast
replication.
Figure 11-3-6 N-to-N multicast replication
 Port-based multicast VLAN

In some cases, multiple Internet service providers (ISPs) provide multicast services on a
network, and users in a single user VLAN subscribe multicast services of different ISPs. N-to-N
multicast replication allows users that subscribe to multicast services of one ISP to receive
multicast services from other ISPs. To isolate multicast services users, assign a multicast VLAN
to each
ISP and bind the multicast VLAN to user VLANs on a specified port. The mapping between
the multicast VLAN and a combination of the user port and user VLAN is generated. The user
port then forwards multicast data only to the user VLANs bound to the multicast VLAN.
As shown in Figure 11-3-7, ISP1 and ISP2 provide multicast services on the network. Host1
and Host2 obtain the multicast services from ISP1, and Host3 and Host4 obtain the multicast
services from ISP2. To ensure that multicast data is sent to only hosts that requires the data,
configure MVLAN1 and MVLAN2 for ISP1 and ISP2 respectively. Bind the access ports of
Host1 and Host2 to MVLAN1, and bind access ports of Host3 and Host4 to MVLAN2.
Multicast data provided by ISP1 is sent to Host1 and Host2, and that provided by ISP2 is sent to
Host3 and Host4.
Only IGMP snooping supports port-based multicast VLAN.
Figure 11-3-7 Port-based multicast VLAN

11.3.5 Layer 2 Multicast CAC
Principles
As the IPTV service develops, the number of channels increases rapidly. If the number of channels
demanded by users keeps increasing, aggregation devices will be overloaded, which causes low
user experience. If multicast-based network attacks exist, devices on the network may be busy
processing attack packets and cannot respond to valid requests on the network.
When providing the IPTV service, ISPs should consider whether their network bandwidth supports
these sparse channels in case of a large number of channels. If the network bandwidth is
insufficient, the network must reject the requests to join new channels to ensure service quality for
most users.
Figure 11-3-8 shows how Layer 2 multicast call admission control (CAC) addresses this problem
for the IPTV service. Layer 2 multicast CAC controls user access based on different rules. This
technology accurately controls the multicast services to ensure service quality for most users
and reduces multicast-based network attacks.
Figure 11-3-8 Networking diagram of multicast services

Concepts
 CAC: provides a series of rules for controlling multicast entry learning, including restrictions
on the number of group memberships and the number of multicast groups in a channel. Layer 2
multicast CAR controls multicast services on Layer 2 networks.
 Channel: is a series of multicast groups. For example, a channel can be regarded as TV, and
TV1 or TV2 indicates a multicast group.
Implementation
If IGMP snooping is configured to provide multicast services, Layer 2 multicast CAC can be used to
control the multicast services. Multicast CAC controls the generation of multicast forwarding
entries. When the number of existing multicast forwarding entries reaches the configured limit, no
more forwarding entries will be generated. This ensures the processing capacity of devices and
controls link bandwidth.
Layer 2 multicast CAC restricts the following items:
 Number of group memberships
This restriction applies to all multicast groups. As shown in Figure 11-3-9, Layer 2 multicast
CAC controls the multicast services based on the system, VLAN, port, or a combination of port
and VLAN. When the Layer 2 device receives IGMP Report messages from hosts, it generates
corresponding entries. The number of group memberships increases by 1 every time a multicast
group is created or a member joins a group. If the number of group memberships does not
exceed the limit, the device can generate forwarding entries. If the number of group
memberships exceeds the limit, no entry is generated. The number of group memberships
decreases by 1 every time an entry is deleted because an IGMP Leave message is received or the
entry ages out.
Figure 11-3-9 Restriction rules of Layer 2 multicast CAC
 Number of multicast groups in a channel
Each channel has a multicast group range. Layer 2 multicast CAC controls the number of
multicast groups in a channel. The restriction on the channel is also based on the system,
VLAN,
port, or a combination of port and VLAN. These restriction rules take effect only for the
number of multicast groups in a channel.
11.3.6 Controllable Multicast
Principles
Traditional multicast services are uncontrollable. Users send IGMP/MLD Report messages to join a
desired multicast group, and then they can receive multicast packets of the group. After the IPTV
service emerges, the uncontrollable multicast services cannot meet carriers' requirements. The IPTV
service aims to make profits. Users in multicast groups can watch a program (join a multicast group)
only after they pay fees. Users that are not authenticated cannot obtain the IPTV service.
Controllable multicast is developed to control the user rights to join a multicast group. When a user
sends a request to join a multicast group, a Layer 2 device authenticates the request packet and
rejects invalid and unauthorized requests.
As shown in Figure 11-3-10, SwitchA configured with the controllable multicast function can control
the generation of Layer 2 multicast forwarding entries by intercepting IGMP/MLD Report messages.
When SwitchA receives an IGMP/MLD Report message from a user, it obtains the profile based on
the VLAN ID of the message.
 If the multicast group requested by the user is not in the multicast group list of the profile,
the user cannot join the group. SwitchA then drops the IGMP/MLD Report message and
does not generate the related forwarding entry. Therefore, the user cannot receive data flows
of this multicast group.
 If the multicast group is in the multicast group list of the profile, SwitchA checks the mode in
which the list is added to the profile. If the list is added to the profile in watch mode, the
IGMP/MLD Report message can pass. If the list is added to the profile in preview mode,
SwitchA allows the IGMP/MLD Report message to pass and starts a preview timer. When the
preview timer times out, SwitchA deletes the forwarding entry of this multicast group and
intercepts subsequent IGMP/MLD Report messages of the multicast group. In this manner,
the preview function is implemented.
Figure 11-3-10 Usage scenario of controllable multicast
Concepts
As shown in Figure 11-3-11, a Layer 2 device provides the VLAN-based controllable multicast
function and controls the user rights to join a multicast group using the multicast group,
multicast group list, and multicast profile.
Figure 11-3-11 Hierarchical control mechanism of controllable multicast
 Multicast group: a group identified by a multicast address such as 224.1.1.1. A multicast

group can be regarded as a channel or program of IPTV.
 Multicast group list: a set of multicast groups. A multicast group list can contain multiple
multicast groups. For example, in Figure 11-3-11, multicast group list L1 contains groups
G1, G2, G3, and G4. A multicast group can be contained in multiple multicast group lists.
For example, G3 is contained in L1 and L2.
 Multicast profile: a set of multicast group lists, which define user rights to join desired
multicast groups. A multicast profile can contain multiple multicast group lists. For example, in
Figure
11-3-11, multicast profile P1 contains L1, L2, and LN. A multicast group list can be contained in
multiple multicast profiles. For example, L2 is contained in P1 and P2. Multicast group lists in
a profile have the attributes such as preview or watch. If a multicast group list is added to a
multicast profile in watch mode, users bound to the multicast profile can watch all multicast
groups in the list. If a multicast group list is added to a multicast profile in preview mode, users
bound to the multicast profile can only preview all multicast groups in the list.
11.4 PIM
11.4.1 Concepts
This section describes PIM-related concepts based on the network shown in Figure 11-4-1.
Figure 11-4-1 PIM network

1210
Multicast Distribution Tree
On a PIM network, a point-to-multipoint (P2MP) multicast forwarding path is established for each
multicast group on separate routers. The multicast forwarding path looks like a tree, so it is also
called a multicast distribution tree (MDT).
Two types of MDTs are available:
 Shortest path tree (SPT): uses the multicast source as the root and multicast group members
as leaves. SPT applies to both PIM-DM and PIM-SM networks.
In Figure 11-4-1, the MDT, RouterE→RouterD→RouterA/RouterB, is an SPT, which uses the

source as the root and HostA and HostB as leaves.
 Rendezvous point tree (RPT): uses a rendezvous point (RP) as the root and multicast
group members as leaves. RPT applies only to PIM-SM networks.
For details about RP and RPT, see PIM-SM (ASM Model).
PIM Router
Routers with PIM enabled on interfaces are called PIM routers. During the establishment of an
MDT, PIM routers play the following roles:
 Leaf router: connects to user hosts, which may not be multicast group members. For
example, RouterA, RouterB, and RouterC in Figure 11-4-1 are leaf routers.
 First-hop router: directly connects to the multicast source on the multicast forwarding path and
is responsible for forwarding multicast data from the multicast source. For example, RouterE in
Figure 11-4-1 is the first-hop router.
 Last-hop router: directly connects to multicast group members (receivers) on the multicast
forwarding path and is responsible for forwarding multicast data to these members. For
example, RouterA and RouterB in Figure 11-4-1 are last-hop routers.
 Intermediate router: resides between the first-hop router and the last-hop router on the
multicast forwarding path. For example, RouterD in Figure 11-4-1 is an intermediate router.
PIM Routing Entry
Two types of PIM routing entries are generated using PIM: (S, G) and (*, G); S indicates a
specific multicast source, G indicates a specific multicast group, and * indicates any multicast
source.
 An (S, G) entry is often used to establish an SPT on PIM routers. (S, G) entries apply to PIM-DM
and PIM-SM networks.
 A (*, G) entry is often used to establish an RPT on PIM routers. (*, G) entries apply only to
PIM-SM networks.
A PIM router may have both (S, G) and (*, G) entries. When a PIM router receives a multicast
packet with the source address S and the group address G and the packet passes the RPF check, the
router forwards the packet according to the following rules:
 If the (S, G) entry exists, the router forwards the packet according to the (S, G) entry.
 If the (S, G) entry does not exist but the (*, G) entry exists, the router creates an (S, G)
entry based on this (*, G) entry, and then forwards the packet according to the (S, G) entry.
PIM routing entries contain the following information to guide multicast packet forwarding:
 Multicast source address
 Multicast group address
 Upstream interface, which receives multicast data on the local router, such as GE3/0/0 in Figure
11-4-1
 Downstream interface, which forwards multicast data, such as GE1/0/0 and GE2/0/0 in Figure
11-4-1
11.4.2 PIM-DM
Principles
PIM-DM forwards multicast packets in push mode and is for use on small-scale networks with densely
distributed multicast group members. PIM-DM assumes that each network segment has multicast
group members. When a multicast source sends multicast packets, PIM-DM floods all PIM routers on
the network with the multicast packets and prunes the branches that do not have multicast group
members. Through periodic flooding and pruning, PIM-DM creates and maintains a unidirectional
loop-free SPT that connects the multicast source and group members.
If a new member joins a multicast group on the network segment connected to a leaf router in a
pruned branch, the router can initiate the grafting mechanism before starting new flooding and
pruning. As a result, the pruned branch turns into a forwarding branch.
PIM-DM uses the following mechanisms: neighbor discovery, flooding, pruning, grafting, assert, and
state refresh. The flooding, pruning, and grafting mechanisms are used to establish an SPT. For
details about all of these six mechanisms, see the sections below.
Neighbor Discovery
PIM routers send Hello messages through PIM-enabled interfaces. For example, in a Hello message:
 The destination address is 224.0.0.13 and all PIM routers on the same network segment
will receive this Hello message.
 The source address is the IP address of the interface that receives multicast packets.
 The time to live (TTL) value is 1.
Hello messages are used to discover PIM neighbors, adjust various PIM protocol parameters,
and maintain neighbor relationships.
 Discovering PIM neighbors
PIM routers on the same network segment must receive multicast packets with the
destination address 224.0.0.13. By exchanging Hello messages, directly connected PIM
routers learn neighbor information and establish neighbor relationships.
A PIM router can receive other PIM messages to create multicast routing entries only after
it establishes neighbor relationships with other PIM routers.
 Adjusting PIM protocol parameters
A Hello message carries the following PIM protocol parameters:
 DR_Priority: indicates the priority used by router interfaces to elect the designated router
(DR). The interface with the highest priority becomes the DR.
 Holdtime: indicates the period during which a neighbor remains reachable. If a router
receives no Hello message from a neighbor within this period, the router considers that
the neighbor is unreachable.
 LAN_Delay: indicates the delay in transmitting Prune messages on a shared

network segment.
 Neighbor-Tracking: indicates the neighbor tracking function. For details about this
function, see the configuration guide.
 Override-Interval: indicates the interval for overriding the pruning mechanism.

NOTE:
The DR_Priority parameter is only used in DR election on PIM-SM networks. For details about
DR election, see DR Election.
 Maintaining neighbor relationships
PIM routers periodically send Hello messages to each other. If a PIM router does not receive a
new Hello message from its PIM neighbor within the Holdtime, the router considers the
neighbor unreachable and deletes the neighbor from the neighbor list.
Changes of PIM neighbors lead to multicast topology changes on the network. If an upstream
or downstream neighbor in the MDT is unreachable, multicast routes re-converge and the
MDT is re-established.
Flooding
On a PIM-DM network, multicast packets from a multicast source are flooded throughout the entire
network. When a PIM router receives a multicast packet, the router performs the RPF check on the
packet based on the unicast routing table. If the packet passes the RPF check, the router creates an
(S,
G) entry, in which the downstream interface list contains all the interfaces connected to PIM
neighbors. The router then forwards subsequent multicast packets through each downstream interface.
When the multicast packets reach a leaf router, the leaf router processes the packets as follows:
 If the network segment connected to the leaf router has group members, the leaf router adds
its interface that is connected to the network segment to the downstream interface list of the
(S, G) entry, and forwards subsequent multicast packets to the group members.
 If the network segment connected to the leaf router has no group member and the leaf router
does not need to forward multicast packets to downstream PIM neighbors, the leaf router
initiates the
pruning mechanism and stops forwarding.
NOTE:
Multicast packets are sometimes flooded to a shared network segment with multiple PIM routers. If
the packets pass the RPF check on these PIM routers, multiple copies of multicast packets are
forwarded to this network segment. These PIM routers will need to initiate the assert mechanism.
As shown in Figure 11-4-2, RouterA, RouterB, and RouterC on the PIM-DM network establish PIM
neighbor relationships by exchanging Hello messages. HostA joins multicast group G using Internet
Group Management Protocol (IGMP) that runs between RouterA and HostA, but HostB does not
join
any multicast group.
Figure 11-4-2 Flooding diagram

The flooding process is as follows:
1. Multicast source S sends a multicast packet to multicast group G.
2. RouterC receives the multicast packet and performs the RPF check based on the unicast
routing table. If the packet passes the RPF check, RouterC creates an (S, G) entry, in which
the downstream interface list contains interfaces connected to RouterA and RouterB. RouterC
then forwards subsequent packets to RouterA and RouterB.
3. RouterA receives the multicast packet from RouterC. If the packet passes the RPF check,
RouterA creates an (S, G) entry, in which the downstream interface list contains the
interface connected to HostA. RouterA then forwards subsequent packets to HostA.
4. RouterB receives the multicast packet from RouterC. Because the downstream network
segment does not have group members or PIM neighbors, RouterB sends a Prune message to
RouterC.
Pruning
When a PIM router receives a multicast packet, it performs the RPF check on the packet. If the packet
passes the RPF check but the downstream network segment does not need to receive the multicast
packet, the PIM router sends a Prune message to an upstream router. After receiving the Prune
message, the upstream router deletes the downstream interface from the downstream interface list of
the created (S, G) entry.
The deletion ensures that the downstream interface can no longer forward multicast packets. A leaf
router initiates the pruning mechanism, and the Prune message is sent upstream by hop along the
MDT to prune the network segment that has no group members.
A PIM router starts a prune timer for the pruned downstream interface. The interface resumes
forwarding multicast packets after the timer expires. Subsequently, multicast packets are
flooded throughout the entire network and new group members can receive multicast packets.
If a leaf router connecting to a network segment that has no group members receives the
flooded multicast packets, the leaf router initiates the pruning mechanism.
PIM-DM updates the SPT periodically through the process of periodic flooding and pruning.
After a downstream interface of a leaf router is pruned, the leaf router will initiate either the grafting
or state refresh mechanism:
 Grafting: When new members join a multicast group on the network segment connected to
the leaf router and want to receive multicast packets before the prune timer expires, the leaf
router initiates the grafting mechanism.
 State Refresh: When no member joins a multicast group on the network segment connected to
the leaf router and the downstream interface is expected to remain suppressed, the leaf router
initiates the state refresh mechanism.
As shown in Figure 11-4-3, no group member connects to RouterB, so RouterB sends a Prune
message to the upstream router.
Figure 11-4-3 Pruning diagram
The pruning process is as follows:
1. RouterB sends a Prune message to RouterC, instructing RouterC not to forward data to the
network segment (HostB) to which RouterB connects.
2. After receiving the Prune message, RouterC stops forwarding data through its downstream
interface connecting to RouterB, and deletes this downstream interface from the (S, G)
entry. The pruning process for this network segment ends. RouterC sends subsequent
multicast
packets only to RouterA, which then forwards the packets to connected group members (such as
HostA).
Grafting
PIM-DM uses the grafting mechanism to enable new group members on a pruned network segment
to rapidly obtain multicast data. IGMP helps a leaf router learn whether new group members have
joined a multicast group on the connected network segment.
If a leaf router learns that new group members have joined multicast group G, the leaf router sends a
Graft message to the upstream router. The message requests the upstream router to resume multicast
packet forwarding on the downstream interface and to add the downstream interface to the
downstream interface list of the (S, G) entry.
The grafting mechanism is initiated by a leaf router and ends when the upstream router receives
the multicast packets destined to the leaf router.
As shown in Figure 11-4-4, RouterC does not send multicast packets to RouterB after the
pruning process ends. When HostB joins multicast group G, RouterB initiates the grafting
mechanism.
Figure 11-4-4 Grafting diagram
The grafting process is as follows:
1. RouterB sends a Graft message to RouterC. The message requires RouterC to resume
multicast packet forwarding on the downstream interface connecting to RouterB.
2. After receiving the Graft message, RouterC resumes multicast packet forwarding on the
interface and adds the interface to the downstream interface list of the (S, G) entry. The
grafting process for RouterB ends. RouterC sends subsequent multicast packets to RouterB,
which then forwards the packets to HostB.
State Refresh
To prevent a pruned interface from resuming multicast packet forwarding after the prune timer
expires, the first-hop router nearest to the multicast source periodically sends a State-Refresh message
throughout the entire PIM-DM network.
PIM routers receiving the State-Refresh message refresh the prune timer state. If no group
member joins a multicast group on the network segment connected to a leaf router in a pruned
branch, the upstream interface connected to this router remains suppressed.
In Figure 11-4-5, RouterC's interface connected to RouterB is pruned, and no group member joins
a multicast group on the network segment connected to RouterB.
Figure 11-4-5 State refresh diagram
The state refresh process is as follows:
1. RouterC initiates the state refresh mechanism and sends a State-Refresh message to RouterA
and RouterB.
2. RouterC has a pruned interface and refreshes the prune timer state of this interface. When
RouterC starts new flooding and pruning, the pruned interface on RouterC is still
prohibited from forwarding multicast packets because no group member connects to
RouterB.
Assert
When multicast packets pass the RPF check on multiple PIM routers connecting to a network
segment, the assert mechanism is required to ensure that only one PIM router forwards the multicast
packets to the network segment.
When a PIM router receives a multicast packet that is the same as the multicast packet it sends to
other neighbors, the PIM router broadcasts an Assert message with the destination address 224.0.0.13
to all other PIM routers on the same network segment.
When the other PIM routers receive the Assert message, they compare their parameters with
those carried in the Assert message for assert election. The election rules are as follows:
1. If these routers have different priorities, the router with the highest unicast routing priority
wins.
2. If these routers have the same unicast routing priority, the router with the smallest route cost
to the multicast source wins.
3. If these routers have the same unicast routing priority and the same route cost to the
multicast source, the router with the highest IP address for the downstream interface wins.
A PIM router performs the following operations based on assert election results:
 If a router wins the assert election, its downstream interface becomes the assert winner and
is responsible for forwarding multicast packets to the shared network segment.
 If a router fails the assert election, its downstream interface becomes the assert loser, is
prohibited from forwarding multicast packets to the shared network segment, and is deleted
from the downstream interface list of the (S, G) entry.
After the assert election is complete, only one downstream interface exists on the shared network
segment and it transmits only one copy of multicast packets. All assert losers can periodically
resume multicast packet forwarding, which causes periodic assert elections.
As shown in Figure 11-4-6, RouterB and RouterC receive multicast packets from the multicast
source. The multicast packets from RouterA pass the RPF check on RouterB and RouterC, RouterB
and RouterC create (S, G) entries and send multicast packets to the same network segment that their
downstream interfaces connect to.
Figure 11-4-6 Assert diagram

The assert process is as follows:
1. RouterB and RouterC receive a multicast packet from each other through a downstream
interface, but this packet fails the RPF check and is discarded. Then, RouterB and RouterC
send an Assert message to the network segment.
2. RouterB compares its routing information with that carried in the Assert message sent by
RouterC, and it wins the assert election because its route cost to the multicast source is lower
than that of RouterC. RouterB then continues to forward subsequent multicast packets to the
network segment, whereas RouterC discards subsequent multicast packets because these
packets fail the RPF check.
3. RouterC compares its routing information with that carried in the Assert message sent by
RouterB, and it fails the assert election because its route cost to the multicast source is
higher than that of RouterB. RouterC then prohibits its downstream interface from
forwarding multicast packets to the network segment and deletes the interface from the
downstream interface list of the (S, G) entry.
11.4.3 PIM-SM (ASM Model)
Implementation
PIM-Sparse Mode (PIM-SM) forwards multicast packets in pull mode and is for use on large-scale
networks with sparsely distributed group members. In Any-Source Multicast (ASM)
implementation, devices on the PIM-SM network work as follows:
 A Rendezvous Point (RP), an important PIM router, is available to provide services for
group members or multicast sources that appear anytime. All PIM routers on the network
know the position of the RP.
 When a new group member appears on the network (that is, a user host joins a multicast group
G through IGMP), the last-hop router sends a Join message to the RP. A (*, G) entry is created
hop by hop, and an RPT with the RP as the root is generated.
 When an active multicast source appears on the network (that is, the multicast source sends the
first multicast packet to a multicast group G), the first-hop router encapsulates the multicast data
in a Register message and unicasts the Register message to the RP. The RP then creates an (S,
G) entry and registers multicast source information.
PIM-SM uses the following mechanisms in the ASM model: neighbor discovery, DR election, RP
discovery, RPT setup, multicast source registration, SPT switchover, prune, and assertion. You can
also configure a Bootstrap router (BSR) to implement fine-grained management in a single PIM-SM
domain. For details about all of these mechanisms, see the sections below.
Neighbor Discovery
Neighbor discovery in PIM-SM is similar to that in PIM-DM. For details, see Neighbor Discovery.
DR Election
The network segment where a multicast source or group member resides is usually connected to
multiple PIM routers. These PIM routers exchange Hello messages to set up PIM neighbor
relationships. The Hello messages carry the DR priority and the interface address of the network
segment. Each PIM router compares its own information with the information carried in the
messages sent by its neighbors. The DR that forwards multicast packets from the source DR or
receiver DR is elected based on the following election rules. The election rules are as follows:
 If all PIM routers on the network segment allow Hello messages to carry DR priorities, the PIM
router with the highest DR priority is elected as the DR.
 If PIM routers have the same DR priority or at least one PIM router does not allow Hello
messages to carry the DR priority, the PIM router with the largest IP address is elected as the
DR.

1210
If an existing DR becomes faulty, PIM neighbor relationships time out, and a new DR election
is triggered among PIM neighbors.
As shown in Figure 11-4-7, there are two types of DRs in the ASM model:
 Source DR: DR connected to the multicast source. On the shared network segment connected
to the multicast source, the source DR is responsible for sending Register messages to the RP.
 Receiver DR: DR connected to group members. On the shared network segment connected
to group members, the receiver DR is responsible for sending Join messages to the RP.
Figure 11-4-7 DR election
RP Discovery
An RP is responsible for processing Register messages from the multicast source and Join
messages from group members. All PIM routers on the network know the position of the RP.
An RP can serve multiple multicast groups simultaneously, but each multicast group can be
associated with only one RP. RPs can be configured either static or dynamic:
 Static RP: All the PIM routers on the network are manually configured with the same RP
address.
 Dynamic RP: Several PIM routers in the PIM domain are configured as Candidate-RPs (C-
RPs)
and an RP is elected from the candidates. One or more PIM routers are configured as
Candidate-BSRs (C-BSRs). The C-BSRs automatically elect a BSR, and this BSR is
responsible for collecting and advertising C-RP information.
During a BSR election, each C-BSR considers itself the BSR and sends the entire network a
BootStrap message that carries its address and priority. Each PIM router compares the Bootstrap
messages it receives from the C-BSRs. The BSR is elected based on the result of the
comparison:
 If the C-BSRs have different priorities, the C-BSR with the highest priority (largest
priority value) is elected as the BSR.
 If the C-BSRs have the same priority, the C-BSR with the largest IP address is elected
as the BSR.
Figure 11-4-8 shows the C-RP election process:
1. C-RPs send Advertisement messages to the BSR. An Advertisement message carries

the address of the C-RP, the range of the multicast groups that it serves, and its
priority.
2. The BSR collects the information in an RP-Set, encapsulates the RP-Set in a

Bootstrap message, and advertises the message to each PIM-SM router on the network.
3. The routers elect an RP from multiple C-RPs that serve a specific multicast group
based on the RP-set and the following election rules:
 If the C-RPs have interface address masks of different lengths, the C-RP with
the longest interface address mask is elected as the RP.
 If the C-RPs have interface address masks of the same length, the C-RP with
the highest priority (largest priority value) is elected.
 If the C-RPs have the same priority, a hash algorithm is used to elect the C-RP
with the largest hash value.
 If all the preceding values are the same, the C-RP with the largest IP address
is elected as the RP.
4. PIM routers save the relationship between this multicast group and its RP for
subsequent multicast operations. This relationships on all PIM routers are the
same because they use the same RP-Set and the same election rules.
Figure 11-4-8 Dynamic RP election

RPT Setup
Figure 11-4-9 RPT setup

A PIM-SM RPT is a multicast distribution tree (MDT) that uses an RP as the root and group member
routers as leaves. As shown in Figure 11-4-9, when a group member appears on the network (that is,
a user host joins a multicast group G through IGMP), the receiver's DR sends a Join message to the
RP. A (*, G) entry is created hop by hop, and an RPT with the RP as the root is generated.
Multicast Source Registration
Figure 11-4-10 Multicast source registration

As shown in Figure 11-4-10, a new multicast source on the PIM-SM network must register with
the RP so that the RP can forward multicast data to group members. The registration and
forwarding process is as follows:
1. The multicast source sends a multicast packet to the source's DR.
2. After receiving the multicast packet, the source's DR encapsulates the multicast packet into a
Register message and sends the Register message to the RP.
3. After receiving the Register message, the RP decapsulates it, creates an (S, G) entry, and
sends multicast data to group members along the RPT.
SPT Switchover
A multicast group on a PIM-SM network can be associated with only one RP and sets up only one
RPT. Under normal circumstances, all multicast packets destined for a multicast group are
encapsulated in Register messages and sent to the RP. The RP then decapsulates the packets and
forwards them along
the RPT to multicast group members. All multicast packets pass through the RP. If the number of
multicast packets increases dramatically, the RP becomes heavily burdened. To resolve this
problem, PIM-SM allows the RP or the receiver DR to trigger an SPT switchover.
 SPT switchover triggered by the RP
After receiving a Register message from the source DR, the RP decapsulates the Register
message and forwards multicast packets along the RPT to group members. The RP also sends
a Join message to the source's DR to set up an SPT from the RP to the source.
After the SPT is set up, the source DR forwards multicast packets directly to the RP. After
the switchover, the source DR and RP do not need to encapsulate or decapsulate packets.
 SPT switchover triggered by the receiver DR
Figure 11-4-11 SPT switchover triggered by the receiver's DR

As shown in Figure 11-4-11, the receiver DR periodically checks the forwarding rate
of multicast packets. When the receiver DR finds that the forwarding rate is higher
than a configured threshold, it triggers an SPT switchover.
1. The receiver DR sends a Join message to the source DR hop by hop, creates an (S, G)
entry hop by hop, and then sets up an SPT from the source DR to the receiver
DR.
2. After the SPT is set up, the receiver DR sends Prune messages along the RPT to the RP
and deletes the RP's interface connected to it from the (S, G) entry. After the prune
action is complete, the RP does not forward multicast packets along the RPT.
3. Because the SPT does not pass through the RP, the RP continues to send Prune messages
along the RPT to the source DR and deletes the RP's interface connected to it from the
(S, G) entry. After the prune action is complete, the source's DR does not forward
multicast
packets along the SPT to the RP.
NOTE:
By default, no threshold for the multicast packet forwarding rate is configured on the device.
Therefore, an SPT switchover is triggered upon the receiving of the first multicast packet from
the multicast source, instead of threshold crossing.
Assert
The Assert mechanism in PIM-SM is similar to that in PIM-DM. For details, see "PIM-DM
Assert".
BSR Administrative Domain
To provide fine-grained network management, a PIM-SM network has both a global domain
and multiple BSR administrative domains. This reduces the workload on individual BSRs and
allows provisioning of special services to users in a specific domain by using private group
addresses.
Each BSR administrative domain maintains only one BSR that serves multicast groups within a
specific group address range. The global domain maintains a BSR that serves multicast groups
not served by an administrative domain.
This section describes the relationship between BSR administrative domains and the global domain
in terms of domain space, group address ranges, and multicast functions.
 Domain space
Figure 11-4-12 Relationship between BSR administrative domains and the global domain
from in terms of domain space
As shown in Figure 11-4-12, BSR administrative domains contain different PIM routers. A PIM
router belongs to only one BSR administrative domain. BSR administrative domains are
independent of and isolated from each other. Each BSR administrative domain manages the
multicast groups within a specific group address range. Multicast packets within this range can
be transmitted only within this administrative domain and cannot cross its border.
The global domain contains all PIM routers on the PIM-SM network. A multicast packet that
does not belong to any BSR administrative domain can be transmitted throughout the entire
PIM network.
 Group address range
Figure 11-4-13 Relationship between BSR administrative domains and the global domain
in terms of group address ranges
Each BSR administrative domain provides services for multicast groups within a specific
group address range. The group address ranges served by different BSR administrative
domains can
overlap. As shown in Figure 11-4-13, the group address range of BSR1 overlap that of the
BSR3. The address of a multicast group that a BSR administrative domain serves is used as a
private group address and is valid only in its BSR administrative domain.
The global domain serves all multicast groups that do not belong to a BSR administrative
domain. As shown in Figure 11-4-13, the group address range of the global domain is G-G1-G2.
 Multicast function
As shown in Figure 11-4-13, the global domain and each BSR administrative domain have
their respective C-RP and BSR devices. These devices function only in the domain where they
reside. Each domain holds independent BSR and RP elections.
Each BSR administrative domain has a border. Multicast messages from this domain, such as
C-RP Advertisement messages or BSR BootStrap messages, can be transmitted only within
the domain where they originate. Multicast messages from the global domain can be
transmitted throughout the entire global domain and traverse any BSR administrative domain.
11.4.4 PIM-SM (SSM Model)
Implementation
The SSM model uses IGMPv3/MLDv2 and PIM-SM technology. There is no need to maintain an
RP, set up an RPT, or register a multicast source. An SPT can be built directly between the source
and group members.
In the SSM model, user hosts know the positions of multicast sources in advance of requesting
multicast services. When user hosts join multicast groups, they can specify the sources from which
they want to receive data. After receiving requests from user hosts, the receiver DR directly forwards
Join messages to the source DR. The Join message is then transmitted upstream hop by hop to set up
an SPT between the source and group members.
In the SSM model, PIM-SM uses the following mechanisms: neighbor discovery, DR election, and
SPT setup. For details about all of these three mechanisms, see the sections below.
Neighbor Discovery
Neighbor discovery in PIM-SM is similar to that in PIM-DM. For details, see "PIM DM Neighbor
Discovery".
DR Election
DR election in PIM-SM (SSM model) is similar to that in PIM-SM (ASM model). For details, see
"PIM DM DR Election".
SPT Setup
Figure 11-4-14 SPT setup
Figure 11-4-14 shows the SPT setup process:
1. Using IGMPv3/MLDv2, RouterD and RouterE learn that packets from user hosts have the
same multicast group address but are requesting multicast data from different source addresses.
They send Join messages to sources hop by hop.
2. PIM routers create (S1, G) and (S2, G) entries based on the Join messages and set up SPTs
from
S1 to HostA and from S2 to HostB.
3. After SPTs are set up, the sources forward multicast packets along the SPTs to group
members.
Comparisons of PIM Protocols
PIM has three implementations: PIM-DM, PIM-SM (ASM model), and PIM-SM (SSM model). Table
11-4-1 compares these PIM implementations.
Table 11-4-1 Comparisons between PIM implementations
Protocol
PIM-DM
Table 11-4-1 Comparisons between PIM implementations
Protocol
PIM-SM
11.4.5 PIM BFD
A network device must detect a communications fault between adjacent devices quickly so that
the upper layer protocol can rectify the fault and prevent a service interruption.
Bidirectional Forwarding Detection (BFD) provides uniform, millisecond-level detection for all
media and protocol layers. Two systems set up a BFD session and periodically send BFD control
packets along the path between them. If one system does not receive BFD control packets within a
specified period, the system considers that a fault has occurred on the path.
Implementation
If the current DR or Assert winner on the shared network segment is faulty in a multicast scenario,
other PIM neighbors start a new DR election or Assert election after the neighbor relationship or the
Assert timer times out. Consequently, multicast data transmission is interrupted. The interruption
period, usually in seconds, is at least as long as the timeout interval of the neighbor relationship or
the Assert timer.
Because PIM BFD detects the link status on a shared network segment within milliseconds, it
responds quickly to PIM neighbor faults. If an interface enabled with PIM BFD does not receive BFD
control
packets from the DR or Assert winner within the detection interval, it considers that the DR or Assert
winner is faulty. BFD fast notifies the RM of the session status and the RM then notifies the PIM
module. The PIM module triggers a new DR election or Assert election without waiting for the
neighbor relationship or the Assert timer to expire. PIM BFD reduces the time services are
interrupted and makes data transmission more reliable.
NOTE:
PIM BFD can be used only on a PIM-SM network.
Figure 11-4-15 PIM BFD

Figure 11-4-15 shows a shared network segment connected to user hosts. Downstream Interface1
on RouterB and downstream Interface2 on RouterC establish a PIM BFD session and send BFD
control packets to detect link status.
RouterB functions as the DR and its downstream interface Interface1 is responsible for forwarding
multicast data. If Interface1 becomes faulty, BFD fast notifies the RM of the session status and the
RM then notifies the PIM module. The PIM module then triggers a new DR election. RouterC quickly
begins functioning as the new DR and its downstream interface Interface2 forwards multicast data to
the receivers.
11.4.6 PIM GR
Graceful Restart (GR) is a type of master/slave switchover protocol on the contr ol plane. Protocol
Independent Multicast (PIM) GR ensures multicast non-stop forwarding (NSF) during a
master/slave switchover. PIM GR supports PIM-Sparse Mode (PIM-SM) and PIM-Source Specific
Multicast
(PIM-SSM) but does not support PIM-Dense Mode (PIM-DM).

1210
Implementation
Multicast GR is based on unicast GR. PIM GR ensures multicast NSF when a master/slave
switchover occurs on a device that has PIM-SM or PIM-SSM enabled and dual main control boards
configured. The PIM protocol of the new main control board learns Join messages from downstream
neighbors or Report messages from Internet Group Management Protocol (IGMP) hosts and performs
the following operations:
 Recalculates PIM multicast routing entries.
 Maintains the Join status of upstream neighbors.
 Updates multicast routing entries of the forwarding plane.
After a master/slave switchover, PIM routing entries on the main control board are quickly
restored, and multicast forwarding entries are updated. This shortens multicast traffic interruption
during a master/slave switchover.
PIM GR is for use on PIM-SM networks. On a PIM-SM network, PIM GR on PIM router ensures
multicast NSF during a master/slave switchover. PIM GR can also be used for an in-service software
upgrade (ISSU). PIM GR ensures that main control boards and interface boards can forward
multicast traffic during ISSUs.
The example in Figure 11-4-16 uses RouterA to show the PIM GR process.
Figure 11-4-16 PIM GR

PIM GR involves three phases: GR_START, GR_SYNC, and GR_END.
GR_START
1. After RouterA performs a master/slave switchover, the PIM protocol starts the GR timer, and
PIM GR enters the GR_START phase. Unicast GR begins at the same time.
2. The PIM protocol sends Hello messages carrying new Generation IDs to all interfaces
enabled with PIM-SM.
3. When RouterB and RouterD, reverse path forwarding (RPF) neighbors of RouterA,
discover that the Generation ID of RouterA has changed, they send new Join-Prune
messages to RouterA.
4. If dynamic RPs are used and the neighbors receive Hello messages with the changed
Generation ID, the neighbors send a BSR message to RouterA to restore BSR information and
RP information on RouterA.
5. After RouterA receives a Join-Prune message from RouterD or RouterB, it creates a

PIM routing entry in an empty inbound interface table to record the Join status of
RouterD or RouterB.
During this period, the entries in the forwarding module remain unchanged and forwarding
of multicast traffic continues.
GR_SYNC
After unicast GR is complete, PIM GR enters the GR_SYNC phase. The PIM protocol builds a
multicast distribution tree (MDT) based on unicast routing information, restores the inbound
interface of the PIM routing entry, and updates the Join queue to the source or the Rendezvous Point
(RP). The PIM protocol then instructs the multicast forwarding module to update the forwarding
table.
GR_END
After the GR timer expires, the PIM protocol enters the GR_END phase and notifies the multicast
forwarding module. The multicast forwarding module then ages the forwarding entries that were
not updated during GR.
11.5 Multicast Route Management
11.5.1 Multicast Routing and Forwarding
Devices that play different roles on a multicast network maintain different multicast tables,
including the IGMP/MLD group table, IGMP/MLD routing table, multicast protocol routing table,
multicast routing table, and multicast forwarding table. This section uses an IPv4 network as an
example to describe the functions of these tables in multicast routing and forwarding.
IGMP Group and Routing Tables
A multicast router creates an IGMP group entry when receiving an IGMP Report message (IGMP
Join) that a host sends to join a group. The router maintains group memberships in IGMP group
entries and instructs a multicast routing protocol, usually the Protocol Independent Multicast (PIM)
protocol, to create matching (*, G) entries. The router maintains an IGMP group entry for each
interface as long as
the interfaces have IGMP enabled and have received IGMP Join messages. The following is an
example of a group entry on an interface:
<HUAWEI> display igmp group

Interface group report information of VPN-Instance: public net
GigabitEthernet1/0/0 (10.1.6.2):
Total 1 IGMP Group reported
Group Address Last Reporter
225.1.1.2 10.1.6.10
Table 11-5-1 explains the fields in an IGMP group entry.
Table 11-5-1 Description of fields in an IGMP group entry
Group Address
Last Reporter
Uptime
Expires
An IGMP routing table is also maintained by the IGMP protocol. An interface is included in an IGMP
routing entry only when PIM is not enabled on the interface. IGMP routing entries provide
downstream interfaces to extend multicast routing entries. The following is an example of an IGMP
routing entry:
<HUAWEI> display igmp routing-table

Routing table of VPN-Instance: public net
Total 1 entry
00001. (*, 225.1.1.1)

List of 1 downstream interface
GigabitEthernet1/0/0 (20.20.20.1),
Protocol: IGMP
Table 11-5-2 explains the fields in an IGMP routing entry.
Table 11-5-2 Description of fields in an IGMP routing entry
Field Description
Table 11-5-2 Description of fields in an IGMP routing entry
00001. (*, 225.1.1.1)
List of 1 downstream interface
Protocol: IGMP
According to the preceding information, the protocol type of the downstream interface is IGMP,
indicating that PIM is not enabled on the interface. If PIM is enabled on an interface, the routing
entries of the interface are maintained by PIM.
Multicast Protocol Routing Table
Multicast routing protocols maintain their own routing tables to guide multicast routing and
forwarding. PIM is the most widely used multicast routing protocol. The following is an example of a
PIM routing table:
<HUAWEI> display pim routing-table

VPN-Instance: public net
Total 0 (*, G) entry; 1 (S, G) entry
(172.168.0.12, 227.0.0.1)
RP: 2.2.2.2
Protocol: pim-sm, Flag: SPT LOC ACT
UpTime: 02:54:43
Upstream interface: GigabitEthernet1/0/0
Upstream neighbor: NULL RPF prime
neighbor: NULL Downstream
interface(s) information:
Total number of downstreams: 1
1: GigabitEthernet2/0/0
Protocol: pim-sm, UpTime: 02:54:43, Expires: 00:02:47
Table 11-5-3 explains the fields in a PIM routing entry.
Table 11-5-3 Description of fields in a PIM routing entry

(172.168.0.12, 227.0.0.1)
RP: 2.2.2.2
Protocol: pim-sm
UpTime: 02:54:43
Flag: SPT LOC ACT
Upstream neighbor: NULL
RPF prime neighbor: NULL
Downstream interface(s) information:
Expires: 00:02:47
For details about PIM routing entries, see Concepts in the PIM feature description.
Multicast Routing Table
A multicast routing table is generated and maintained by the multicast route management module of a
router. If a router supports multiple multicast protocols, its multicast routing table contains the
optimal routes selected from routing tables of these protocols. PIM Dense Mode (DM) and PIM
Sparse Mode (SM) cannot run simultaneously on a router. In unicast routing, routing tables of various
routing protocols such as Open Shortest Path First (OSPF), Routing Information Protocol (RIP), and
Boarder Gateway Protocol (BGP) constitute an IP routing table. Similarly, routing tables of different
multicast protocols constitute a multicast table. Routers deliver multicast routing entries to their
multicast forwarding tables to guide multicast data forwarding. The following is an example of a
multicast routing table:
<HUAWEI> display multicast routing-table
Multicast routing table of VPN-Instance: public net
Total 1 entry
00001. (172.168.0.2, 227.0.0.1)
Uptime: 00:00:28
Upstream Interface: GigabitEthernet1/0/0
List of 2 downstream interfaces
Table 11-5-4 explains the fields in a multicast routing entry.
Table 11-5-4 Description of fields in a multicast routing entry
00001. (172.168.0.2, 227.0.0.1)
UpTime: 02:54:43
Upstream Interface: GigabitEthernet1/0/0
Multicast Forwarding Table
A multicast forwarding table, usually called a multicast forwarding information base (MFIB), is
created and maintained by the route management module of a router according to multicast routing
information. Routers forward multicast data according to their MFIBs. You can use the display
multicast forwarding-table command to view entries in an MFIB. An MFIB has the same functions as
a unicast
FIB. The following is an example of an MFIB.
<HUAWEI> display multicast forwarding-table

Multicast Forwarding Table of VPN-Instance: public net
Total 1 entry, 1 matched
00001. (172.168.0.2, 227.0.0.1)

MID: 0, Flags: 0x0:0
Uptime: 00:08:32, Timeout in: 00:03:26
Incoming interface: GigabitEthernet1/0/0
List of 1 outgoing interfaces:
Activetime: 00:23:15
Matched 38264 packets(1071392 bytes), Wrong If 0 packets
Forwarded 38264 packets(1071392 bytes)
Table 11-5-5 explains the fields in a multicast forwarding entry.
Table 11-5-5 Description of fields in a multicast forwarding entry
Field Description
00001. (172.168.0.2, 227.0.0.1) Entry number 00001, in the (S, G) format.
Flags: 0x0:0 Flag of the multicast forwarding entry.
MID: 0 Unique identifier of the multicast forwarding entry in the

MFIB, which is used to rapidly search the multicast
forwarding table.
UpTime: 02:54:43 How long the multicast forwarding entry has existed.
Timeout in: 00:03:26 How soon the multicast forwarding entry will time out.
Incoming interface: Inbound interface in the multicast forwarding entry.

List of 1 outgoing interfaces: List of outbound interfaces.
Activetime: 00:23:15 How long an outbound interface has existed.
Matched 38264 packets(1071392 Number of packets that match the multicast forwarding entry.
bytes)
Wrong If 0 packets Number of packets that arrive on the incorrect

inbound interfaces.
Forwarded 38264 packets(1071392 Number of forwarded packets.

bytes)
The preceding information shows that multicast data is actually forwarded according to the MFIB.
Each multicast forwarding entry records statistics about packets that are forwarded according to
the entry.
11.5.2 RPF Check
RPF Check Basics
In unicast routing and forwarding, unicast packets are transmitted along a point-to-point path. Routers
only need to know the destination address of a packet to find the outbound interface. In multicast
routing and forwarding, routers cannot know the location of a receiver because the destination address
of a multicast packet identifies a group of receivers. However, routers can know the source of a
multicast packet according to the source address, and they ensure correct forwarding paths for
multicast packets by checking source addresses of the packets.
When a router receives a multicast packet, it searches the unicast routing table for the route to the
source address of the packet. After finding the route, the router checks whether the outbound
interface of the route is the same as the inbound interface of the multicast packet. If they are the same,
the router considers that the multicast packet is received from a correct interface. This process is
called an RPF check, which ensures correct forwarding paths for multicast packets.
The correct interface is called an RPF interface.
Process of an RPF Check
In addition to unicast routes, RPF checks can also be performed using Multiprotocol Border Gatewa
y Protocol (MBGP) routes and multicast static routes. If a router has all these routes, it performs an
RPF check as follows after receiving a multicast packet:
1. The router selects an optimal route from each of the unicast routing table, MBGP routing table,
and multicast static routing table according to the source address of the multicast packet. The
outbound interfaces of the unicast route and MBGP route are RPF interfaces, and the next
hops of the routes are the RPF neighbors. The RPF interface and RPF neighbor of the
multicast static route have been specified when the route is manually configured.
2. The router selects a route from the three routes as the RPF route according to the
following rules:
 If the longest match rule is configured, the router selects the route with the longest mask.
If the routes have the same mask length, the router selects the one with the highest
preference. If the routes have the same preference, the router selects a route in an order
of multicast static route, MBGP route, and unicast route.
 If the longest match rule is not configured, the router selects the route with the highest
preference. If the routes have the same preference, the router selects a route in an order
of multicast static route, MBGP route, and unicast route.
3. The router compares the inbound interface of the packet with the RPF interface of the selected
RPF route. If the inbound interface is the same as the RPF interface, the router considers that
the packet has arrived on the correct path from the source and forwards the packet to
downstream
interfaces. If the inbound interface is different from the RPF interface, the packet fails the RPF
check. The router considers that the packet is received from an incorrect interface and drops
the packet.
As shown in Figure 11-5-1, a multicast stream sent from the source 152.10.2.2 arrives at interface
S1 of the router. The router checks the routing table and finds that the multicast stream from this
source should arrive at interface S0. Therefore, the RPF check fails and the multicast stream is
dropped by the router.
Figure 11-5-1 RPF check fails
As shown in Figure 11-5-2, a multicast stream sent from the source 152.10.2.2 arrives at interface
S0 of the router. The router checks the routing table and finds that the RPF interface is also S0. The
RPF check succeeds, and the multicast stream is correctly forwarded.
Figure 11-5-2 RPF check succeeds
RPF Check in Multicast Data Forwarding
Multicast routing protocols determine the upstream and downstream neighbors and create multicast
routing entries according to existing unicast routes, MBGP routes, and multicast static routes. The
RPF check mechanism enables multicast data streams to be transmitted along the multicast
distribution tree and prevents loops on forwarding paths.
If a router searches the unicast routing table to perform an RPF check on every multicast data
packet received, many system resources are consumed. To save system resources, a router first
searches for the matching (S, G) entry after receiving a data packet sent from a source S to a group
G.
 If no matching (S, G) entry is found, the router performs an RPF check to find the RPF
interface for the packet. The router then creates a multicast route with the RPF interface as the
upstream interface and delivers the route to the multicast forwarding table. If the RPF check
succeeds, the inbound interface of the packet is the RPF interface, and the router forwards the
packet to all the
downstream interfaces in the forwarding entry. If the RPF check fails, the packet is
forwarded along an incorrect path, and the router drops the packet.
 If a matching (S, G) entry is found and the inbound interface of the packet is the same as the
upstream interface in the entry, the router forwards the packet to all the downstream
interfaces specified in the entry.
 If a matching (S, G) entry is found but the inbound interface of the packet is different from
the upstream interface in the entry, the router performs an RPF check on the packet. The
router processes the packet according to the RPF check as follows:
 If the RPF interface is the same as the upstream interface in the entry, the (S, G) entry
is correct and the packet is forwarded along an incorrect path. The router drops the
packet.
 If the RPF interface is different from the upstream interface in the entry, the (S, G) entry
is outdated, and the router changes the upstream interface in the entry to the RPF
interface. The router then compares the RPF interface with the inbound interface of the
packet. If the inbound interface is the RPF interface, the router forwards the packet to all
the downstream interfaces specified in the (S, G) entry. If the inbound interface is not the
RPF interface, the router drops the packet.
11.5.3 Multicast Static Route
RPF checks can be performed using multicast static routes. Multicast static routes can be used
to change RPF routes and connect RPF routes.
Changing RPF Routes
You can change RPF routes on a network by configuring multicast static routes. Then multicast
data can be transmitted along a different path than unicast data.
As shown in Figure 11-5-3, RouterA is the RPF neighbor of RouterC towards the multicast source
(Source). Multicast packets sent from Source are transmitted along the path Source-> RouterA->
RouterC. If you configure a multicast static route on RouterC and specify RouterB as the RPF
neighbor, the transmission path of multicast packets sent from Source changes to Source-> RouterA->
RouterB-> RouterC. Then the multicast path diverges from the unicast path.

1210
Figure 11-5-3 Configure a multicast static route to change the RPF route
Connecting RPF Routes
When unicast routes on a multicast network are incomplete, multicast packets cannot be forwarded
due to lack of an RPF route. You can configure multicast static routes on the network to generate new
RPF routes. Then multicast routers can create new multicast forwarding entries to guide multicast data
forwarding.
As shown in Figure 11-5-4, Domain1 and Domain2 are routing domains (RIP and OSPF domains for
example). The domains have no unicast route to each other, so the receivers in Domain2 cannot
receive data from the multicast source in Domain1. To enable the receivers to receive data from the
multicast source, configure multicast static routes on RouterC and RouterD in Domain2. On RouterC,
specify RouterB as the RPF neighbor. On RouterD, specify RouterC as the RPF neighbor.
Figure 11-5-4 Configure multicast static routes to connect RPF routes
NOTE:
Multicast static routes are local to the router where they are configured and are not advertised
or redistributed to any other router.
11.5.4 Multicast Load Splitting
Load splitting and load balancing are different. Load splitting provides a way to distribute data
streams destined for the same destination to multiple equal-cost paths, which may not result in a
balanced traffic load on the paths. Load balancing is a special form of load splitting and distributes
even data traffic loads on multiple equal-cost paths.
Implementation
By default, a router selects an RPF route from multiple equal-cost optimal routes to forward
multicast packets according to the following RPF check policy:
 If the equal-cost routes are in the same routing table, for example, unicast routing table,
multicast static routing table, or MBGP routing table, the router selects the route with the largest
next-hop address as the RPF route.
 If the equal-cost routes are in different routing tables, the router selects the route with the
highest preference. If the routes have the same preference, the router selects the route with the
longest mask length. If the routes have the same preference and mask length, the router uses an
algorithm to select a route as the RPF route.
No matter in which condition, the router selects only one route as the RPF route.
Multicast load splitting enables a router to distribute multicast traffic to multiple equal-cost
routes, instead of selecting only one route according to the RPF check policy.
As shown in Figure 11-5-5, the multicast source (Source) sends multicast streams to group G.
RouterA and RouterD run an Interior Gateway Protocol (IGP), OSPF for example, to implement IP
interworking. Two equal-cost paths are available: RouterA-> RouterB-> RouterD and RouterA->
RouterC-> RouterD. According to the default RPF check policy, the multicast streams are forwarded
through interface Int0 of RouterA because interface Int0 has a larger IP address than interface
Int1. After multicast load splitting is configured on RouterA, RouterA does not select
forwarding paths by comparing the next-hop IP addresses. Multicast streams are forwarded through
both the two equal-cost paths.
Figure 11-5-5 Multicast forwarding without and with multicast load splitting
Multicast Load Splitting Modes
Various methods are available to load split (*, G) and (S, G) data streams in different scenarios,
as described in the following table.
 Load splitting based on group addresses
As shown in Figure 11-5-6, the source sends data streams to different multicast groups (G1 to
G10). Router7, Router6, and Router5 each have two equal-cost paths towards the source.These
routers use route selection algorithms to select an optimal route for data sent to each group.In
this load splitting mode, streams transmitted on different paths are sent to different groups.
Figure 11-5-6 Load splitting based on group addresses
 Load splitting based on source addresses
As shown in Figure 11-5-7, different sources (S1 to S10) send data streams to the same group.
Router7, Router6, and Router5 each have two equal-cost paths towards the sources.These
routers use route selection algorithms to select an optimal path for data from each source.In this
load splitting mode, streams transmitted on different paths are sent from different sources.
Figure 11-5-7 Load splitting based on source addresses
 Load splitting based on source and group addresses
As shown in Figure 11-5-8, different sources (S1 to S10) send data streams to different
groups (G1 to G10). Router7, Router6, and Router5 each have two equal-cost paths towards
the sources.These routers use route selection algorithms to select an optimal path for each (S,
G) stream.In this load splitting mode, streams transmitted on different paths have different
source and group addresses.
Figure 11-5-8 Load splitting based on source and group addresses
 Other load splitting methods
Figure 11-5-9 Other load splitting methods
 Stable-preferred load splitting
As shown in Figure 11-5-9, when route flapping occurs on a multicast network, frequent
changes of multicast traffic distribution on equal-cost paths will worsen route flapping.
Stable-preferred load splitting can be configured to solve the problem. When route
flapping occurs, a router with stable-preferred load splitting adjusts traffic distribution on
equal-cost paths until route flapping ends.When the network topology becomes stable, the
router evenly distributes (S, G) streams from the same source to the equal-cost paths.
 Balance-preferred load splitting
As shown in Figure 11-5-9, balance-preferred load splitting enables routers to adjust

traffic distribution among equal-cost paths immediately when route flapping occurs on a
multicast network.When the network topology becomes stable, the router evenly
distributes (S, G) streams from the same source to the equal-cost paths.
 Unbalanced load splitting

As shown in Figure 11-5-9, unbalanced load splitting is a supplement to stable-
preferred and balance-preferred load splitting and does not change the behaviors of the
two load splitting modes. In unbalanced load splitting mode, (S, G) streams are
distributed to
equal-cost paths in proportion to the weights of the paths.As transmission paths on a
network have different capabilities, you may need to manually adjust loads on some
paths. In this case, you can configure load splitting weights on upstream interfaces of a
router to implement unbalanced load splitting. A larger weight on an upstream interface
allows the corresponding path to transmit more (*, G) and (S, G) streams.
11.5.5 MPing/MTrace
Introduction to MPing/MTrace
As the Internet develops, more and more data, voice, and video service information is exchanged on
the network and multicast services are rapidly developing. The following comes the requirement for
management on multicast networks. Multicast ping/tracert (MPing/MTrace) has been developed to
provide users with the multicast service detection and fault diagnosis functions.
 MPing: a tool for detecting multicast services. MPing sends ICMP Echo Request messages
to trigger the setup of the multicast forwarding tree and detect members of reserved
multicast
groups on the network.
NOTE:
Reserved multicast group: The reserved multicast group addresses range from 224.0.0.0 to
224.0.0.255. For example, 224.0.0.5 is reserved for the OSPF multicast group; 224.0.0.13 is reserved
for the PIMv2 multicast group.
 MTrace: a tool for tracing multicast forwarding paths. MTrace traces the path from a receiver to
a multicast source along the multicast forwarding tree.
MPing
MPing uses standard ICMP messages to detect the connectivity of a multicast path. MPing
constructs an ICMP Echo Request message with the encapsulated destination address being a
multicast address (either a multicast address for the reserved multicast group or a common multicast
group address).
 If the encapsulated destination address of an ICMP Echo Request message is the address of a
reserved multicast group, the querier must specify the outbound interface of the message.
Upon receiving such an ICMP Echo Request message, the member of the reserved multicast
group responds with an ICMP Echo Reply packet. Therefore, you can ping the address of the
reserved multicast group to detect the members in the reserved multicast group.
 If the encapsulated destination address of an ICMP Echo Request message is the address of a
common multicast group, the querier cannot specify the outbound interface of the message. The
ICMP Echo Request message, as limited multicast traffic, is forwarded on the multicast
network, which triggers the setup of multicast routing entries. The querier collects statistics on
received
ICMP Echo Reply packets from the destination host and calculates the TTL and response
time from the multicast source to the member of a multicast group.
MTrace
MTrace complies with the protocol draft draft-fenner-traceroute-ipm-01.txt defined by the Internet
Engineering Task Force (IETF).
This draft describes a mechanism to trace the path along which multicast data is forwarded from
the multicast source to the designated receiver.
Figure 11-5-10 Networking diagram of MTrace

MTrace takes effect only on a network where a multicast protocol (such as the PIM-SM protocol) is
enabled and the multicast distribution tree is established. MTrace detects the multicast forwarding
path by sending query messages. Query messages are classified into IGMP Tracert Query message,
IGMP Tracert Request message, and IGMP Tracert Response message.
MTrace implements as follows:
1. The querier sends an IGMP Tracert Query message to the last-hop device connected to
the destination host.
2. After receiving the IGMP Tracert Query message, the last-hop device adds a response
data
block containing information about the interface that receives the IGMP Tracert Query
message, and sends an IGMP Tracert Request message to the previous-hop device.
3. Devices of each hop add a response data block to the IGMP Tracert Request message and
send the message upstream.
4. When the first-hop device connected to the multicast source receives the IGMP Tracert
Request message, it adds a response data block and sends the IGMP Tracert Response message
to the querier.
5. The querier parses the IGMP Tracert Response message and obtains information about
the forwarding path from the multicast source to the destination host.
6. If the IGMP Tracert Request message cannot reach the first-hop device because of some
errors, the IGMP Tracert Response message is directly sent to the querier. The querier then
parses the data block information for locating and monitoring the faulty node.
11.5.6 Multicast in BGP/MPLS IP VPN
Applicable Scenario
Figure 11-5-11 shows the typical BGP/MPLS IP VPN networking. Multicast in BGP/MPLS IP VPN
allows private multicast traffic to be forwarded on the BGP/MPLS IP VPN. VPN users at each site
receive multicast data from the users of the same VPN. PEs at the public network edge support
multi-instance, and multicast traffic in VPN instances is isolated.
Figure 11-5-11 Typical networking of BGP/MPLS IP VPN

Implementation
Figure 11-5-12 Using the GRE tunnel to transmit private multicast

traffic
As shown in Figure 11-5-12, the device transmits private multicast traffic over the GRE
tunnel deployed between PEs.
To deploy multicast in BGP/MPLS IP VPN network, create a tunnel interface on the PE and bind the
tunnel interface and the interface connecting the PE and the CE to the same VPN instance. The
private routing protocol process on the PE advertises IP addresses of network segments where the
tunnel interface and the interface connecting the PE and the CE are located. After multicast packets
reaches the PE, the next hop in the VPN instance routing table is the tunnel interface. The PE
encapsulates a GRE header to multicast packets and sends it to the remote PE over the GRE tunnel.
The remote PE decapsulates the multicast packets.
When configuring multicast in BGP/MPLS IP VPN network, note the following points:
 There must be a reachable route between the source address and destination address of the
tunnel interface. The tunnel interface can use the loopback interface address as the source
address. The loopback interface binds to the same VPN instance as the tunnel interface. In
addition, there must be a reachable route between the loopback interface and the source address
of the peer tunnel interface.
 IP addresses of tunnel interfaces at both ends of the GRE tunnel must be located on the
same network segment.
 Interfaces including tunnel interfaces in a VPN instance must use the same PIM protocol. PIM
can be not configured on the source interface of tunnel interface.
 All the PEs bound to the same VPN instance must establish a GRE tunnel.
11.6 Configuration Examples
11.6.1 Example for Adding an Interface to a Multicast Group Statically
As shown in Figure 11-6-1, video on demand (VoD) users receive video streams in multicast mode.
User hosts are located on two network segments: N1 and N2. The receiver HostA is located on N1,
and receivers HostC and HostD are located on N2. HostA needs to receive data of multicast group
225.1.1.1 for long time, while HostC and HostD do not have such requirements.
Figure 11-6-1 Networking diagram for basic IGMP configuration
To meet the preceding requirements, add the interface connected to the network segment of HostA
to multicast group 225.1.1.1 statically. The configuration roadmap is as follows:
1. Configure a unicast routing protocol to implement IP interworking. Configure IP addresses

for interfaces and configure a unicast routing protocol on each Router. Multicast routing
protocols depend on unicast routing protocols.
2. Configure basic multicast functions to enable multicast data to be forwarded on th e

network.
Enable PIM-SM and configure an RP on each Router. Enable IGMP on the interface
connected to the receiver network segment.

1210
3. Enable HostA to receive data of multicast group 225.1.1.1 for a long time. On RouterA, add
the interface connected to the network segment of HostA to multicast group 225.1.1.1
statically.

1210
Procedure
1. Configure IP addresses for interfaces and configure a unicast routing protocol on each Router.
Configure an IP address and mask for each interface according to Figure 11-6-1. Configure
OSPF on each Router to ensure IP connectivity between them, and enable them to
dynamically update routing information. The detailed configurations are not mentioned here.
For details, see Configuration Files.
2. Enable PIM-SM and configure an RP.
# Enable multicast functions on RouterA and enable PIM-SM on GE1/0/0 and GE2/0/0. The
configurations of RouterB, RouterC and RouterD are similar to the configuration of
RouterA,
and are not mentioned here. For details, see Configuration Files.
[RouterA] multicast routing-enable

[RouterA-GigabitEthernet1/0/0] pim sm
[RouterA] pim
[RouterA-pim] static-rp 192.168.4.1
[RouterA-pim] quit
3. Enable IGMP on the interface connected to user hosts.
# Enable IGMP on GE1/0/0 of RouterA. The configurations of RouterB, RouterC and RouterD
are similar to the configuration of RouterA, and are not mentioned here. For details, see
Configuration Files.

[RouterA-GigabitEthernet1/0/0] igmp enable
4. Add GE1/0/0 of RouterA to the multicast group 225.1.1.1 to enable user hosts connected to
GE1/0/0 to receive stable multicast data sent to the multicast group 225.1.1.1.

[RouterA-GigabitEthernet1/0/0] igmp static-group 225.1.1.1
# Run the display igmp interface command to check the IGMP configuration and
running status on each router interface. The IGMP command output on GE1/0/0 of
RouterB is as follows:
<RouterB> display igmp interface gigabitethernet 1/0/0
Interface information of VPN-Instance: public net
GigabitEthernet1/0/0(10.110.2.1):
IGMP is enabled
Current IGMP version is 2
IGMP state: up
IGMP group policy: none
IGMP limit: -
Value of query interval for IGMP (negotiated): -
Value of query interval for IGMP(configured): 60
s Value of other querier timeout for IGMP: 0 s
Value of maximum query response time for IGMP: 10 s
Querier for IGMP: 10.110.2.1 (this router)
Total 2 IGMP Groups reported
# Run the display pim routing-table command on RouterA to check whether GE1/0/0 has
been added to the multicast group 225.1.1.1 statically. The command output is displayed as
follows:
If a (*, 225.1.1.1) entry is generated on RouterA, the downstream interface is
GigabitEthernet1/0/0, and the protocol type is static, it means GigabitEthernet1/0/0 has
been added to the multicast group 225.1.1.1 statically.
<RouterA> display pim routing-table

(*, 225.1.1.1)
RP: 192.168.4.1
Protocol: pim-sm, Flag: WC
UpTime: 00:12:17
Upstream neighbor: 192.168.1.1
RPF prime neighbor: 192.168.1.1
Protocol: static, UpTime: 00:12:17, Expires: -
Configuration Files
#
sysname RouterA
#
multicast routing-enable
#
ip address 10.110.1.1 255.255.255.0
pim sm
igmp enable
igmp static-group 225.1.1.1
#
ip address 192.168.1.1 255.255.255.0
pim sm
#
ospf 1
area 0.0.0.0
network 10.110.1.0 0.0.0.255
network 192.168.1.0 0.0.0.255
#
pim
static-rp 192.168.4.1
#
return
#
sysname RouterB
#
#
ip address 10.110.2.1 255.255.255.0
pim sm
igmp enable
#
ip address 192.168.2.1 255.255.255.0
pim sm
#
ospf 1
area 0.0.0.0
network 10.110.2.0 0.0.0.255
network 192.168.2.0 0.0.0.255
#
pim
static-rp 192.168.4.1
#
return
#
sysname RouterC
#
#
ip address 10.110.2.2 255.255.255.0
pim sm
igmp enable
#
ip address 192.168.3.1 255.255.255.0
pim sm
#
ospf 1
area 0.0.0.0
network 10.110.2.0 0.0.0.255
network 192.168.3.0 0.0.0.255
#
pim
static-rp 192.168.4.1
#
return
#
sysname RouterD
#
#
ip address 192.168.1.2 255.255.255.0
pim sm
#
ip address 192.168.2.2 255.255.255.0
pim sm
#
ip address 192.168.3.2 255.255.255.0
pim sm
#
interface GigabitEthernet/0/0
ip address 192.168.4.1 255.255.255.0
pim sm
#
ospf 1
area 0.0.0.0
network 192.168.1.0 0.0.0.255
network 192.168.2.0 0.0.0.255
network 192.168.3.0 0.0.0.255
network 192.168.4.0 0.0.0.255
#
pim
static-rp 192.168.4.1
#
return
11.6.2 Example for Configuring Basic IGMP Functions
As shown in Figure 11-6-2, video on demand (VoD) users receive video streams in multicast
mode. User hosts are located on two network segments: N1 and N2. The receivers HostA and
HostC are located on the two network segments respectively. On this network, multicast groups
225.1.1.1 to
225.1.1.5 are used to receive video streams. HostA subscribes to only the program of group
225.1.1.1, and HostC can receive all the programs.
Figure 11-6-2 Networking diagram for basic IGMP configuration
To meet the preceding requirements, configure basic IGMP functions and limit the range of
multicast groups on the interface connected to the network segment of HostA. The configuration
roadmap is as follows:

2. Configure basic multicast functions to enable multicast data to be forwarded on the network.
3. Control multicast data that HostA can receive. Configure an ACL on the interface of RouterA
connected to the network segment of HostA to filter multicast data sent to HostA.
Procedure
dynamically update routing information. The configuration details are not mentioned here.
2. Enable multicast routing on RouterA and enable PIM-SM on all interfaces.

# Enable multicast routing on RouterA, enable PIM-SM on all interfaces, and configure
GE1/0/0 of RouterD as the static RP. The configurations of RouterB, RouterC and RouterD
are similar to the configuration of RouterA, and are not mentioned here.

[RouterA] pim
[RouterA-pim] quit
3. On RouterA, RouterB, RouterC, enable IGMP on the interfaces connected to the

receiver network segments.
# Enable IGMP on GE1/0/0 of RouterA. The configurations of RouterB and RouterC are
similar to the configuration of RouterA, and are not mentioned here.

4. Add GE1/0/0 of RouterA to the multicast group 225.1.1.1 only.
# On RouterA, create an ACL, configure a rule that only permits packets of the multicast group
225.1.1.1, and apply the ACL rule to GE1/0/0.

[RouterA-acl-basic-2001] rule permit source 225.1.1.1 0
[RouterA-GigabitEthernet1/0/0] igmp group-policy 2001
# Run the display igmp interface command to check the IGMP configuration and
running status on each interface. The IGMP command output on GE1/0/0 of RouterA is as
follows:
<RouterA> display igmp interface gigabitethernet 1/0/0

gigabitethernet1/0/0(10.110.1.1):
IGMP is enabled
IGMP state: up
IGMP group policy: 2001
IGMP limit: -
Value of query interval for IGMP (configured): 60 s
Value of other querier timeout for IGMP: 0 s
Total 1 IGMP Group reported
Configuration Files
#
sysname RouterA
#
#
acl number 2001
rule 5 permit source 225.1.1.1 0
#
ip address 10.110.1.1 255.255.255.0
pim sm
igmp enable
igmp group-policy 2001
#
ip address 192.168.1.1 255.255.255.0
pim sm
#
ospf 1
area 0.0.0.0
network 10.110.1.0 0.0.0.255
network 192.168.1.0 0.0.0.255
#
pim
static-rp 192.168.4.2
#
return
#
sysname RouterB
#
#
ip address 10.110.2.1 255.255.255.0
pim sm
igmp enable
#
ip address 192.168.2.1 255.255.255.0
pim sm
#
ospf 1
area 0.0.0.0
network 10.110.2.0 0.0.0.255
network 192.168.2.0 0.0.0.255
#
pim
static-rp 192.168.4.2
#
return
#
sysname RouterC
#
#
ip address 10.110.2.2 255.255.255.0
pim sm
igmp enable
#
ip address 192.168.3.1 255.255.255.0
pim sm
#
ospf 1
area 0.0.0.0
network 10.110.2.0 0.0.0.255
network 192.168.3.0 0.0.0.255
#
pim
static-rp 192.168.4.2
#
return
#
sysname RouterD
#
#
ip address 192.168.4.2 255.255.255.0
pim sm
#
ip address 192.168.1.2 255.255.255.0
pim sm
#
ip address 192.168.2.2 255.255.255.0
pim sm
#
ip address 192.168.3.2 255.255.255.0
pim sm
#
ospf 1
area 0.0.0.0
network 192.168.1.0 0.0.0.255
network 192.168.2.0 0.0.0.255
network 192.168.3.0 0.0.0.255
network 192.168.4.0 0.0.0.255

1210
#
pim
static-rp 192.168.4.2
#
return
11.6.3 Example for Configuring IGMP SSM Mapping
On the multicast network shown in Figure 11-6-3, PIM-SM is run and SSM mode is configured to
provide multicast services. The Router interface connected to the receiver network segment runs
IGMPv3, whereas the receiver runs IGMPv2 and cannot upgrade the version to IGMPv3.
Therefore, the receiver cannot specify a multicast source from which it wants to receive multicast
data when joining a multicast group.
The range of SSM group addresses on the network is 232.1.1.0/24. Source 1, Source 2, and Source 3
all send multicast data to the multicast groups in this range. Configure the receiver to receive only
multicast data from Source 1 and Source 3.
Figure 11-6-3 Networking diagram for the SSM mapping configuration
Device Interface
RouterA GE1/0/0
GE2/0/0
GE3/0/0
RouterB GE1/0/0
GE2/0/0
GE3/0/0
To meet the preceding requirements, configure basic multicast functions on the Routers, and
then configure SSM mapping on RouterD. The configuration roadmap is as follows:

2. Configure basic multicast functions to enable multicast data to be forwarded on the network.
3. Configure SSM mapping to enable the receiver to select multicast sources. Enable SSM
mapping on the interface of RouterD connected to the receiver network segment, and
configure SSM mapping rules on RouterD.
Procedure
Configure an IP address and mask for each interface according to Figure 11-6-3
Networking diagram for the SSM mapping configuration. Configure OSPF on each Router
to ensure IP connectivity between them, and enable them to dynamically update routing
information. The detailed configurations are not mentioned here. For details, see
Configuration Files.
2. Enable IP multicast routing on each Router, and enable PIM-SM and IGMP on interfaces.
# Enable IP multicast routing on RouterD and enable PIM-SM on interfaces. Enable IGMP on
GE1/0/0 and set the IGMP version to IGMPv3.
[RouterD] multicast routing-enable [RouterD]

interface gigabitethernet 1/0/0 [RouterD-
GigabitEthernet1/0/0] pim sm [RouterD-
GigabitEthernet1/0/0] igmp enable [RouterD-
GigabitEthernet1/0/0] igmp version 3
[RouterD-GigabitEthernet2/0/0] pim sm
[RouterD-GigabitEthernet3/0/0] pim sm
# Enable IP multicast routing on RouterA and enable PIM-SM on interfaces of RouterA. The
configurations of RouterB and RouterC are similar to the configuration of RouterA, and are
not mentioned here.

# Configure GE3/0/0 as the C-BSR and C-RP on RouterD.
[RouterD] pim
[RouterD-pim] c-bsr gigabitethernet 3/0/0
[RouterD-pim] c-rp gigabitethernet 3/0/0
[RouterD-pim] quit
3. Enable SSM mapping on the interface connected to the receiver network segment.
# Enable SSM mapping on GE1/0/0 of RouterD.

[RouterD-GigabitEthernet1/0/0] igmp ssm-mapping enable
4. Configure the range of SSM group addresses on all Routers.
# Set the range of SSM group addresses to 232.1.1.0/24 on RouterA. The configurations
of RouterB, RouterC, and RouterD are similar to the configuration of RouterA, and are
not mentioned here.

[RouterA-acl-basic-2000] rule permit source 232.1.1.0 0.0.0.255
[RouterA] pim
[RouterA-pim] ssm-policy 2000
[RouterA-pim] quit
5. Configure SSM mapping rules on RouterD.
# Map the multicast groups in the range of 232.1.1.0/24 to Source 1 and Source 3.
[RouterD] igmp
[RouterD-igmp] ssm-mapping 232.1.1.0 24 10.10.1.1
[RouterD-igmp] ssm-mapping 232.1.1.0 24 10.10.3.1
[RouterD-igmp] quit
Configuration Files
#
sysname RouterA
#
#
acl number 2000
#
ip address 10.10.1.2 255.255.255.0
pim sm
#
ip address 192.168.1.1 255.255.255.0
pim sm
#
ip address 192.168.4.2 255.255.255.0
pim sm
#
ospf 1
area 0.0.0.0
network 10.10.1.0 0.0.0.255
network 192.168.1.0 0.0.0.255
network 192.168.4.0 0.0.0.255
#
pim
ssm-policy 2000
#
return

#
sysname RouterB
#
#
acl number 2000
#
ip address 10.10.2.2 255.255.255.0
pim sm
#
ip address 192.168.1.2 255.255.255.0
pim sm
#
ip address 192.168.2.1 255.255.255.0
pim sm
#
ospf 1
area 0.0.0.0
network 10.10.2.0 0.0.0.255
network 192.168.1.0 0.0.0.255
network 192.168.2.0 0.0.0.255
#
pim
ssm-policy 2000
#
return
#
sysname RouterC
#
#
acl number 2000
#
ip address 10.10.3.2 255.255.255.0
pim sm
#
ip address 192.168.3.1 255.255.255.0
pim sm
#
ip address 192.168.2.2 255.255.255.0
pim sm
#
ospf 1
area 0.0.0.0
network 10.10.3.0 0.0.0.255
network 192.168.3.0 0.0.0.255
network 192.168.2.0 0.0.0.255
#
pim
ssm-policy 2000
#
return
#
#
acl number 2000
#
ip address 10.10.4.2 255.255.255.0
pim sm
igmp enable
igmp version 3
igmp ssm-mapping enable
#
ip address 192.168.3.2 255.255.255.0
pim sm
#
ip address 192.168.4.1 255.255.255.0
pim sm
#
ospf 1
area 0.0.0.0
network 10.10.4 0.0.0.255
network 192.168.3.0 0.0.0.255
network 192.168.4.0 0.0.0.255
#
igmp
ssm-mapping 232.1.1.0 255.255.255.0 10.10.1.1
ssm-mapping 232.1.1.0 255.255.255.0 10.10.3.1
#
pim
c-bsr GigabitEthernet3/0/0
c-rp GigabitEthernet3/0/0
ssm-policy 2000
#
return
11.6.4 Example for Configuring IGMP Limit
When many users are watching multiple video programs, the programs occupy high bandwidth. As
a result, the device performance degrades and multicast data received by users is unstable.
Multicast services are deployed on the network shown in Figure 11-6-4, HostA connected to
RouterA subscribes to the program of group 225.1.1.3 for a long time. The IGMP limit function can
be configured on RouterA, RouterB and RouterC to limit the number of multicast groups that users
can join and allows network resources to be used more efficiently. When the number of multicast
groups that hosts can join reaches the limit, hosts cannot subscribe to new programs. This ensures
that users can watch high-quality programs.
Figure 11-6-4 Networking diagram for IGMP limit configuration

2. Configure basic multicast functions to enable multicast data to be forwarded on the n etwork.
3. Configure HostA to steadily receive multicast data of multicast group 225.1.1.3 for a long time.
On RouterA, add the interface connected to the network segment of HostA to multicast group
225.1.1.3 statically.
4. Limit the number of IGMP group memberships on Router to control the programs that
multicast users can subscribe to.
Procedure
1. Configure IP addresses for interfaces and configure a unicast routing protocol on each
Router.
dynamically update routing information. The configuration details are not mentioned here.
2. Enable multicast routing on RouterA and enable PIM-SM on all interfaces.
# Enable multicast routing on RouterA, enable PIM-SM on all interfaces, and configure
GE4/0/0 of RouterD as the static RP. The configurations of RouterB, RouterC and RouterD
are similar to the configuration of RouterA, and are not mentioned here.

[RouterA] pim
[RouterA-pim] quit
3. On RouterA, RouterB, RouterC, enable IGMP on the interfaces connected to the

receiver network segments.
# Enable IGMP on GE1/0/0 of RouterA. The configurations of RouterB and RouterC are
similar to the configuration of RouterA, and are not mentioned here.

4. Set the maximum number of IGMP group memberships on the last-hop router.
# Set the maximum number of IGMP memberships on RouterA to 50.
[RouterA] igmp global limit 50
# Set the maximum number of IGMP group memberships in the public network instance to 40.
[RouterA] igmp
[RouterA-igmp] limit 40
[RouterA-igmp] quit
# Set the maximum number of IGMP group memberships on GE1/0/0 to 30.

[RouterA-GigabitEthernet1/0/0] igmp limit 30

1210
# Run the display igmp interface command to check the IGMP configuration and running
status on router interfaces. The IGMP command output on GE1/0/0 of RouterA is as follows:
<RouterA> display igmp interface gigabitethernet 1/0/0

IGMP is enabled
IGMP state: up
IGMP group policy: none
IGMP limit: 30
Value of other querier timeout for IGMP: 0 s
You can find that a maximum of 30 IGMP group memberships can be created on GE1/0/0 of
RouterA.
Configuration Files
#
sysname RouterA
#
igmp global limit 50
#
ip address 10.110.1.1 24
pim sm
igmp enable
igmp limit 30
#
ip address 192.168.1.1 24
pim sm
#
ospf 1
area 0.0.0.0
network 10.110.1.0 0.0.0.255
network 192.168.1.0 0.0.0.255
# igmp
limit 40
#
pim
static-rp 192.168.4.1
#
return
#
sysname RouterB
#
#
ip address 10.110.2.1 24
pim sm
igmp enable
igmp limit 30
#
ip address 192.168.2.1 24
pim sm
#
ospf 1
area 0.0.0.0
network 10.110.2.0 0.0.0.255
network 192.168.2.0 0.0.0.255
# igmp
limit 40
#
pim
static-rp 192.168.4.1
#
return
#
sysname RouterC
#
#
ip address 10.110.2.2 24
pim sm
igmp enable
igmp limit 30
#
ip address 192.168.3.1 24
pim sm
#
ospf 1
area 0.0.0.0
network 10.110.2.0 0.0.0.255
network 192.168.3.0 0.0.0.255
# igmp
limit 40
#
pim
static-rp 192.168.4.1
#
return
#
sysname RouterD
#
ip address 192.168.1.2 24
pim sm
#
ip address 192.168.2.2 24
pim sm
#
ip address 192.168.3.2 24
#
ip address 192.168.4.1 24
pim sm
#
ospf 1
area 0.0.0.0
network 192.168.1.0 0.0.0.255
network 192.168.2.0 0.0.0.255
network 192.168.3.0 0.0.0.255
network 192.168.4.0 0.0.0.255
#
pim
static-rp 192.168.4.1
#
return
11.6.5 Example for Configuring IGMP Proxy
When a large number of users watch the same channel at the same time or frequently change
channels, the access device will have to allocate a large amount of bandwidth to process the service
requests. As a result, the access device will be heavily burdened and unable to guarantee stable
transmission of multicast traffic.
To resolve this problem, configure IGMP proxy on a Layer 3 device between the RouterA and
hosts. The Layer 3 device works as a proxy for hosts to send Report and Leave messages and for
the access device to send Query messages, therefore reducing the load on the access device and
improving user experience for multicast services.
On the network shown in Figure 11-6-5, RouterA is an access device. RouterB functions as a Layer
3 device between the access devices and hosts (receivers 1 and 2) and should be enabled with IGMP
proxy. For RouterB to proactively send Report and Leave messages, set the robustness variable to 3
and the source lifetime to 300s.
Figure 11-6-5 Networking diagram for configuring IGMP proxy
Configure IGMP proxy on RouterB to mitigate the pressure of the upatream PIM router (RouterA)
in processing protocol packets.
1. Enable multicast routing on all Routers that provide multicast services. (Multicast is
a prerequisite for enabling IGMP.)
2. Enable IGMP on the Router interfaces connected to hosts.
3. Enable IGMP proxy on the Router interface GE1/0/0 connected to the access device.
4. Configure a backup IGMP proxy interface GE4/0/0 on the Router.
5. Configure a source lifetime in the IGMP view of an IGMP proxy-capable Router.
Procedure
1. Configure an IP address for each interface. The configuration details are omitted.
2. Enable the multicast function on devices and configure IGMP on the interface connected
to hosts.
# Enable the multicast function on RouterA, enable IGMP on GE 1/0/0 and GE 2/0/0, and
set the IGMP version number to 3.

[RouterA-GigabitEthernet1/0/0] igmp version 3
# Enable the multicast function on RouterB, enable IGMP on GE 2/0/0 and GE 3/0/0, and
set the IGMP version number to 3.
[RouterB] multicast routing-enable [RouterB]

interface gigabitethernet 2/0/0 [RouterB-
GigabitEthernet2/0/0] igmp enable [RouterB-
GigabitEthernet2/0/0] igmp version 3
[RouterB-GigabitEthernet3/0/0] igmp enable
[RouterB-GigabitEthernet3/0/0] igmp version 3
3. Enable IGMP proxy on an interface on RouterB.
# Enable IGMP proxy on GE 1/0/0 on RouterB and set the IGMP robustness variable to 3.

[RouterB-GigabitEthernet1/0/0] igmp proxy
[RouterB-GigabitEthernet1/0/0] igmp robust-count 3
4. Configure a backup IGMP proxy interface on the Router.
# Configure GE 4/0/0 on RouterB as a backup IGMP proxy interface.

[RouterB-GigabitEthernet4/0/0] igmp proxy backup
5. Configure a source lifetime in the IGMP view of an IGMP proxy-capable Router.
# Configure a source lifetime in the IGMP view of RouterB.
[RouterB] igmp
[RouterB-igmp] proxy source-lifetime 300
[RouterB-igmp] quit
6. Verify the IGMP-proxy configurations.
# Run the display igmp proxy interface command to check the IGMP proxy interface on the
Router.
[RouterB] display igmp proxy interface

IGMP proxy is enabled
Current IGMP proxy version (negotiated) is 3
Current IGMP proxy version (configured) is 3
IGMP proxy state: up
Value of query interval for IGMP (negotiated): 60 s
Value of querier present timeout for IGMPv1: off
General query response expiry: off
Querier for IGMP: -
Robustness (negotiated): 3
Robustness (configured): 3
Require-router-alert: disabled
Send-router-alert: enabled
IGMP proxy backup is enabled
Current IGMP proxy version (negotiated) is 3
Current IGMP proxy version (configured) is 3
IGMP proxy state: up
Value of query interval for IGMP (negotiated): 60 s
General query response expiry: off
Querier for IGMP: -
Robustness (negotiated): 2
Robustness (configured): 2
Require-router-alert: disabled
Send-router-alert: enabled
The command output shows that IGMP proxy is enabled on GE 1/0/0, and GE 4/0/0
functions as a backup for GE 1/0/0.
# Run the display igmp proxy group command to check IGMP proxy groups on the Router.
[RouterB] display igmp proxy group

Interface group report information of VPN-Instance: public net
Total 1 IGMP proxy Group
Group Address Filter mode
232.0.0.1 include
The preceding command output shows that GE 1/0/0 has information about the multicast group
232.0.0.1 and the filter mode of the group is include, which indicates that Receiver1 has
joined the multicast group 232.0.0.1.
# Run the display igmp proxy routing-table command to check the IGMP proxy routing
table on the Router. Receiver1 sends a (1.1.1.1, 232.1.1.1) Report message.
[RouterB] display igmp proxy routing-table

Routing table of VPN-Instance: public net
(1.1.1.1, 232.1.1.1)
Flag: JOIN, UpTime: 01:38:45
Protocol: static, UpTime: 01:38:45
The preceding command output shows that the IGMP proxy routing table of RouterB has the
(1.1.1.1, 232.1.1.1) entry, which indicates that Receiver1 has joined the multicast group
232.1.1.1 to which the multicast source 1.1.1.1 sends data.
Configuration Files
#
sysname RouterA
#
#
ip address 192.168.1.1 255.255.255.0
igmp enable
igmp version 3
#
ip address 192.168.4.1 255.255.255.0
igmp enable
igmp version 3
#
return
#
sysname RouterB
#
#
ip address 192.168.1.2 255.255.255.0
igmp version 3
igmp robust-count 3
igmp proxy
#
ip address 192.168.2.1 255.255.255.0
igmp enable
igmp version 3
#
ip address 192.168.3.1 255.255.255.0
igmp enable
igmp version 3
#
ip address 192.168.4.2 255.255.255.0
igmp version 3
igmp proxy backup
#
igmp
proxy source-lifetime 300
#
return
11.6.6 Example for Configuring IGMP Snooping
As shown in Figure 11-6-6, RouterA connects to user hosts through a Layer 2 device RouterB and
RouterA runs IGMPv2. The multicast source sends data to multicast groups 225.1.1.1 to 225.1.1.5.
On the network, there are three receivers HostA, HostB, and HostC and the three hosts only want to
receive data of multicast groups 225.1.1.1 to 225.1.1.3.
Figure 11-6-6 Networking diagram for IGMP snooping configuration
To meet the preceding requirements, configure basic IGMP snooping functions and a multicast
group policy on the Layer 2 RouterB. The configuration roadmap is as follows:
1. On RouterB, create a VLAN and add interfaces to the VLAN.
2. Enable IGMP snooping globally and in the VLAN.
3. Configure a multicast group policy and apply this policy to the VLAN.

1210
Procedure
[RouterB] vlan 10
[RouterB-vlan10] quit
[RouterB-Ethernet2/0/1] port hybrid pvid vlan 10
[RouterB-Ethernet2/0/1] port hybrid untagged vlan 10
2. Enable IGMP snooping.
# Enable IGMP snooping globally.
[RouterB] igmp-snooping enable
# Enable IGMP snooping in VLAN 10.
[RouterB] vlan 10
[RouterB-vlan10] igmp-snooping enable
3. Configure a multicast group policy and apply this policy.
# Configure a multicast group policy.
[RouterB] acl 2000

[RouterB-acl-basic-2000] rule deny source 225.1.1.4 0
[RouterB-acl-basic-2000] rule deny source 225.1.1.5 0
# Apply the multicast group policy in VLAN 10.
[RouterB] vlan 10
[RouterB-vlan10] igmp-snooping group-policy 2000
# Check the interface information on RouterB.
<RouterB> display igmp-snooping port-info vlan 10

-----------------------------------------------------------------------
(Source, Group) Port Flag
Flag: S:Static D:Dynamic M: Ssm-mapping
-----------------------------------------------------------------------
VLAN 10, 3 Entry(s)
(*, 225.1.1.1) Ethernet2/0/1 -D-
Ethernet2/0/2 -D-
2 port(s)
(*, 225.1.1.2) Ethernet2/0/1 -D-
Ethernet2/0/2 -D-
2 port(s)
(*, 225.1.1.3) Ethernet2/0/1 -D-
Ethernet2/0/2 -D-
2 port(s)
-----------------------------------------------------------------------
The command output shows that multicast groups 225.1.1.1 to 225.1.1.3 have
dynamically generated member ports Eth2/0/1 and Eth2/0/2 on RouterB.
# Check the Layer 2 multicast forwarding table on RouterB.
<RouterB> display l2-multicast forwarding-table vlan 10

VLAN ID : 10, Forwarding Mode : IP
------------------------------------------------------------------------
(Source, Group) Interface Out-Vlan
------------------------------------------------------------------------
Router-port Ethernet2/0/3 10
(*, 225.1.1.1) Ethernet2/0/3 10
Ethernet2/0/1 10
Ethernet2/0/2 10
(*, 225.1.1.2) Ethernet2/0/3 10
Ethernet2/0/1 10
Ethernet2/0/2 10
(*, 225.1.1.3) Ethernet2/0/3 10
Ethernet2/0/1 10
Ethernet2/0/2 10
Total Group(s) : 3
----------------------------------------------------------------------
The command output shows that the forwarding table contains only information about
multicast groups 225.1.1.1 to 225.1.1.3. The multicast groups 225.1.1.4 to 225.1.1.5 do not
forward data to the hosts.
Configuration Files
#
sysname RouterB
#
vlan batch 10
#
igmp-snooping enable
#
acl number 2000
rule 5 deny source 225.1.1.4 0
#
vlan 10
igmp-snooping group-policy 2000
#
#
#
#
return
11.6.7 Example for Configuring Layer 2 Multicast through Static Interfaces
As shown in Figure 11-6-7, RouterA connects to user hosts through a Layer 2 device RouterB and
RouterA runs IGMPv2. There are four receivers on the network: HostA, HostB, HostC, and
HostD. HostA and HostB expect to receive data of multicast groups 225.1.1.1 to 225.1.1.3 for long
time. HostC and HostD expect to receive data of multicast groups 225.1.1.4 to 225.1.1.5.
Figure 11-6-7 Networking diagram for Layer 2 multicast configuration through static interfaces
To meet the preceding requirements, configure a static router port and static member ports of IGMP
snooping on the Layer 2 RouterB. The configuration roadmap is as follows:
3. Configure a static router port.
4. Configure static member ports.

Procedure
[RouterB] vlan 10
[RouterB] vlan 10
3. Configure a static router port.

[RouterB-Ethernet2/0/3] igmp-snooping static-router-port vlan 10
4. Configure static member ports.

[RouterB-Ethernet2/0/1] l2-multicast static-group group-address 225.1.1.1 to
225.1.1.3 vlan 10
[RouterB-Ethernet2/0/2] l2-multicast static-group group-address 225.1.1.4 to
225.1.1.5 vlan 10
# Check the router port information on RouterB.
<RouterB> display igmp-snooping router-port vlan 10

Port Name UpTime Expires Flags
---------------------------------------------------------------------
VLAN 10, 1 router-port(s)
Ethernet2/0/3 00:20:09 -- STATIC
The command output shows that Eth2/0/3 has been configured as static router
port.
# Check the member port information on RouterB.
<RouterB> display igmp-snooping port-info vlan 10

-----------------------------------------------------------------------
(Source, Group) Port Flag
Flag: S:Static D:Dynamic M: Ssm-mapping
-----------------------------------------------------------------------
VLAN 10, 5 Entry(s)
(*, 225.1.1.1) Ethernet2/0/1 S--
1 port(s)
(*, 225.1.1.2) Ethernet2/0/1 S--
1 port(s)
(*, 225.1.1.3) Ethernet2/0/1 S--
1 port(s)
(*, 225.1.1.4) Ethernet2/0/2 S--
1 port(s)
(*, 225.1.1.5) Ethernet2/0/2 S--
1 port(s)
-----------------------------------------------------------------------
The command output shows that multicast groups 225.1.1.1 to 225.1.1.3 have a static member
port Eth2/0/1 on RouterB and multicast groups 225.1.1.4 to 225.1.1.5 have a static member
port Eth2/0/2 on RouterB.
# Check the Layer 2 multicast forwarding table on RouterB.

---------------------------------------------------------------------------
---------------------------------------------------------------------------
(*, 225.1.1.1) Ethernet2/0/1 10
Ethernet2/0/3 10
(*, 225.1.1.2) Ethernet2/0/1 10
Ethernet2/0/3 10
(*, 225.1.1.3) Ethernet2/0/1 10
Ethernet2/0/3 10
(*, 225.1.1.4) Ethernet2/0/2 10
Ethernet2/0/3 10
(*, 225.1.1.5) Ethernet2/0/2 10
Ethernet2/0/3 10
Total Group(s) : 5
--------------------------------------------------------------------------
The command output shows that multicast groups 225.1.1.1 to 225.1.1.5 have a
forwarding table on RouterB.
Configuration Files
#
sysname RouterB
#
vlan batch 10
#
#
vlan 10
#
l2-multicast static-group group-address 225.1.1.1 to 225.1.1.3 vlan 10
#
l2-multicast static-group group-address 225.1.1.4 to 225.1.1.5 vlan 10
#
igmp-snooping static-router-port vlan 10
#
return
11.6.8 Example for Configuring an IGMP Snooping Querier
As shown in Figure 11-6-8, on a pure Layer 2 network, multicast sources Source1 and Source2 send
multicast data to multicast groups 224.1.1.1 and 225.1.1.1. HostA and HostC expect to receive data
of multicast group 224.1.1.1 for long time, while HostB and HostD expect to receive data of
multicast group 225.1.1.1 for long time. All the hosts run IGMPv2.
Figure 11-6-8 Networking diagram for IGMP snooping querier configuration
To meet the preceding requirements, enable IGMP snooping on the four Routers and configure an
IGMP snooping querier. Enable all the Routers to discard unknown multicast packets to prevent the
Routers from broadcasting multicast data in the VLAN when there are no Layer 2 multicast
forwarding entries on the Routers. The configuration roadmap is as follows:
1. On all the Routers, create a VLAN and add interfaces to the VLAN according to Figure 11-6-8.
2. Enable IGMP snooping globally and in the VLAN on all the Routers.
3. Configure RouterA as an IGMP snooping querier.
4. Enable all the Routers to discard unknown multicast packets.
Procedure
1. On all the Routers, create a VLAN and add interfaces to the VLAN.
[RouterA] vlan 10
[RouterA-vlan10] quit
[RouterA-Ethernet2/0/1] port hybrid pvid vlan 10
[RouterA-Ethernet2/0/1] port hybrid untagged vlan 10
# The configurations of RouterB, RouterC and RouterD are similar to the configuration of
2. Enable IGMP snooping globally and in the VLAN on all the Routers.
[RouterA] igmp-snooping enable

[RouterA] vlan 10
[RouterA-vlan10] igmp-snooping enable
3. Configure RouterA as an IGMP snooping querier.
[RouterA] vlan 10
[RouterA-vlan10] igmp-snooping querier enable
4. Enable all the Routers to discard unknown multicast packets.
[RouterA] vlan 10
[RouterA-vlan10] multicast drop-unknown
# When the IGMP snooping querier begins to work, all the Routers except the IGMP snooping
querier receive IGMP General Query messages. Run the display igmp-snooping statistics
vlan
10 command on RouterB to view IGMP message statistics. The command output is as follows:
<RouterB> display igmp-snooping statistics vlan 10

IGMP Snooping Packets Counter
Statistics for VLAN 10
Recv V1 Report 0
Recv V2 Report 32
Recv V3 Report 0
Recv V1 Query 0
Recv V2 Query 30
Recv V3 Query 0
Recv Leave 0
Recv Pim Hello 0
Send Query (S=0) 0
Send Query (S!=0) -
Proxy Send General Query 0
Proxy Send Group-Specific Query 0
Proxy Send Group-Source-Specific Query 0
Configuration Files
#
sysname RouterA
#
vlan batch 10

1210
#
#
vlan 10
multicast drop-unknown
igmp-snooping querier enable
#
#
#
#
return
#
sysname RouterB
#
vlan batch 10
#
#
vlan 10
#
#
#
#
#
return
#
sysname RouterC
#
vlan batch 10
#
#
vlan 10
#
#
#
#
return
#
sysname RouterD
#
vlan batch 10
#
#
vlan 10
#
#
#
return
11.6.9 Example for Configuring Multicast SSM Mapping
As shown in Figure 11-6-9, RouterA connects to user hosts through a Layer 2 device RouterB.
RouterA runs IGMPv3 and uses the ASM mode and SSM mode to provide multicast services. User
hosts HostA, HostB, and HostC on the network run IGMPv2 and do not support IGMPv3. The
multicast sources Source1 and Source2 send multicast data to the multicast group 225.1.1.1, but
the user hosts want to receive only the multicast data sent from Source1.
Figure 11-6-9 Networking diagram for the SSM mapping configuration
To meet the preceding requirements, configure SSM mapping on RouterB. The configuration
3. Configure an IGMP snooping SSM policy to add the multicast address of the ASM mode to the
SSM group address range.
4. Configure SSM mapping to allow the users to receive only multicast data sent from
the specified source.
Procedure
[RouterB] vlan 10
[RouterB] vlan 10
3. Configure an IGMP snooping SSM policy.
# Create an ACL, and configure a rule that allows hosts to receive data of multicast group
225.1.1.1.
[RouterB] acl number 2008

[RouterB-acl-basic-2008] rule 5 permit source 225.1.1.1 0
# Apply the SSM mapping policy in the VLAN and treat the multicast group 225.1.1.1 as
a member in the SSM groups.
[RouterB] vlan 10
[RouterB-vlan10] igmp-snooping ssm-policy 2008
4. Enable SSM mapping.
# Configure RouterB to run IGMPv3, enable SSM mapping, and configure a mapping
between the multicast group 225.1.1.1 and the source IP address 10.10.1.1.
[RouterB-vlan10] igmp-snooping version 3

[RouterB-vlan10] igmp-snooping ssm-mapping enable
[RouterB-vlan10] igmp-snooping ssm-mapping 225.1.1.1 32 10.10.1.1
# Check the IGMP snooping configuration in the VLAN.
<RouterB> display igmp-snooping vlan configuration

IGMP Snooping Configuration for VLAN 10
igmp-snooping version 3
igmp-snooping ssm-mapping enable
igmp-snooping ssm-policy 2008
igmp-snooping ssm-mapping 225.1.1.1 255.255.255.255 10.10.1.1
An SSM mapping policy has been configured in VLAN 10.
# Check the Layer 2 multicast forwarding table.

----------------------------------------------------------------------------
----------------------------------------------------------------------------
(10.10.1.1, 225.1.1.1) Ethernet2/0/1 10
Ethernet2/0/3 10
Total Group(s) : 1
----------------------------------------------------------------------------
The command output shows that a mapping entry (10.10.1.1, 225.1 .1.1) has been generated on
RouterB. The mapping entry indicates that the data is sent by Source1.
Configuration Files
#
sysname RouterB
#
vlan batch 10
#
#
acl number 2008
#
vlan 10
igmp-snooping ssm-mapping enable
igmp-snooping version 3
igmp-snooping ssm-policy 2008
igmp-snooping ssm-mapping 225.1.1.1 255.255.255.255 10.10.1.1
#
#
#
return
11.6.10 Example for Configuring Basic PIM-DM Functions
Figure 11-6-10 shows a small-scale network with densely distributed users. HostA and HostB need
to receive VoD streams from Source.
Figure 11-6-10 Configuring basic PIM-DM functions
Router Inter
RouterA
RouterB
RouterC
Since users are densely distributed on the network, PIM-DM can be deployed on the network to
provide multicast services for the user hosts. After PIM-DM is configured on the network, all
user hosts in a multicast group can receive VoD streams sent from the multicast source to the
group.
1. Configure IP addresses for interfaces and configure a unicast routing protocol on each router.
PIM is an intra-domain multicast routing protocol that depends on a unicast routing protocol.
The multicast routing protocol can work normally only when the unicast routing protocol
works normally.
2. Enable multicast routing on all the routers providing multicast services. Multicast routing is
the prerequisite for PIM-DM configuration.
3. Enable PIM-DM on all router interfaces. Other PIM-DM functions can be configured only after
PIM-DM is enabled.
4. Enable IGMP on the interfaces connected to user network segments. The IGMP protocol
maintains group memberships. The leaf routers maintain group memberships using
IGMP.
NOTE:
If PIM-DM and IGMP need to be enabled on the same user-side interface, enable PIM-DM
and then IGMP.
Procedure
1. Configure IP addresses for interfaces and configure a unicast routing protocol on the routers.
# Configure IP addresses and masks for router interfaces. Configure OSPF on the routers to
implement IP interworking between the routers and enable the routers to dynamically
update routes. (The configurations of the other routers are similar to the configuration of
RouterA.)

[RouterA] ospf 100
2. Enable multicast routing on all the routers and enable PIM-DM on all interfaces.
# Enable multicast routing on all the routers and enable PIM-DM on all interfaces.
(The configurations of the other routers are similar to the configuration of RouterA.)

[RouterA-GigabitEthernet1/0/0] pim dm
3. Enable IGMP on the interfaces connected to user hosts.
# Enable IGMP on the user-side interface of RouterA. (The configurations of RouterB and
RouterC are similar to the configuration of RouterA.)

# Run the display pim interface command to check the PIM configuration and running
status on router interfaces. The following is the command output on RouterC, indicating that
PIM is
running on the interfaces.
<RouterC> display pim interface

Interface Sta
GE2/0/0 u
GE1/0/0 u
# Run the display pim routing-table command to check the PIM routing tables on the routers.
You can see from the PIM routing tables that multicast source (10.110.3.100/24) to group
(225.1.1.1/24), and HostA and HostB have joined group (225.1.1.1/24). The PIM routing
tables
of the routers are as follows:
[RouterA] display pim routing-table

(10.110.3.100, 225.1.1.1)
Protocol: pim-dm, Flag: ACT
UpTime: 00:00:29
Downstream interface(s)
information: Total number of
downstreams: 1
Protocol: pim-dm, UpTime: 00:00:29, Expires:-
[RouterB] display pim routing-table
(10.110.3.100, 225.1.1.1)
UpTime: 00:00:29

1210
downstreams: 1

1210
[RouterD] display pim routing-table
(10.110.3.100, 225.1.1.1)
UpTime: 00:00:29
[RouterE] display pim routing-table
(10.110.3.100, 225.1.1.1)
UpTime: 00:01:22
[RouterC] display pim routing-table
(10.110.3.100, 225.1.1.1)
UpTime: 00:01:25
Protocol: igmp, UpTime: 00:01:25, Expires:-
Configuration Files
#
sysname RouterA
#
#
ip address 192.168.5.1 255.255.255.0
pim dm
#
ip address 10.110.1.1 255.255.255.0
pim dm
igmp enable
#
ip address 192.168.1.1 255.255.255.0
pim dm
#
ospf 1
area 0.0.0.0
network 10.110.1.0 0.0.0.255
network 192.168.1.0 0.0.0.255
network 192.168.5.0 0.0.0.255
#
return
#
sysname RouterB
#
#
ip address 192.168.2.1 255.255.255.0
pim dm
#
ip address 10.110.2.1 255.255.255.0
pim dm
igmp enable
#
ospf 1
area 0.0.0.0
network 10.110.2.0 0.0.0.255
network 192.168.2.0 0.0.0.255
#
return
#
sysname RouterC
#
#
ip address 10.110.2.2 255.255.255.0
pim dm
igmp enable
#
ip address 192.168.3.1 255.255.255.0
pim dm
#
ospf 1
area 0.0.0.0
network 10.110.2.0 0.0.0.255
network 192.168.3.0 0.0.0.255
#
return
#
sysname RouterD
#
#
ip address 10.110.3.1 255.255.255.0
pim dm
#
ip address 192.168.1.2 255.255.255.0
pim dm
#
ip address 192.168.4.1 255.255.255.0
pim dm
#
ospf 1
area 0.0.0.0
network 10.110.3.0 0.0.0.255
network 10.110.4.0 0.0.0.255
network 192.168.1.0 0.0.0.255
network 192.168.4.0 0.0.0.255
#
return
#
sysname RouterE
#
#
ip address 192.168.5.2 255.255.255.0
pim dm
#
ip address 192.168.3.2 255.255.255.0
pim dm
#
ip address 192.168.2.2 255.255.255.0
pim dm
#
ip address 192.168.4.2 255.255.255.0
pim dm
#
ospf 1
area 0.0.0.0
network 192.168.2.0 0.0.0.255
network 192.168.3.0 0.0.0.255
network 192.168.4.0 0.0.0.255
network 192.168.5.0 0.0.0.255
#
return
11.6.11 Example for Configuring a PIM-SM (ASM Model)

Network
As shown in Figure 11-6-11, the network is connected to the Internet. Configure the PIM-SM
protocol on the routers to enable them to provide ASM services for user hosts on the network. Then
all the hosts in a multicast group can receive Voice on Demand (VoD) streams sent from any source
to this group.
Figure 11-6-11 Networking diagram for configuring a PIM-SM (ASM model) network
1. Configure an IP address for each interface on routers and a unicast routing protocol. PIM is an
intra-domain multicast routing protocol that depends on a unicast routing protocol. The
multicast routing protocol can work normally after the unicast routing protocol works
normally.
2. Enable the multicast function on all routers providing multicast services. Before
configuring other PIM-SM functions, you must enable the multicast function.
3. Enable PIM-SM on all interfaces of the routers. After PIM-SM is enabled, you can
configure other PIM-SM functions.
4. Enable IGMP on the interface connected to user hosts. A receiver can join or leave a multicast
group by sending IGMP messages. The leaf routers maintain the multicast member
relationship using IGMP.
NOTE:
If PIM-SM and IGMP need to be enabled on the same user host, enable PIM-SM, and
then enable IGMP.
5. Configure the interface connected to hosts to be PIM silent to prevent malicious hosts from
simulating PIM Hello messages. In this manner, security of the PIM-SM domain is
ensured.
NOTE:
If the user network segment is connected to multiple routers, such as RouterB and RouterC
in this example, do not enable PIM silent on interfaces that connect these routers to user hosts.
6. Configure the RP. The RP is the forwarding core of the PIM-SM network. It is
recommended that you configure the RP on a router that has more multicast flows, for
example, RouterE in Figure 11-6-11.
7. Set the BSR boundary on the interface connected to the Internet. The Bootstrap message
cannot pass through the BSR boundary. Therefore, the BSR serves only this PIM-SM domain.
In this manner, multicast services can be controlled effectively.
Procedure
1. Configure an IP address for each interface and configure the unicast routing protocol.
# Configure an IP address and mask for each interface according to Figure 11-6-11.
Configure OSPF on each router to ensure IP connectivity between them, and enable them to
dynamically update routing information. The configuration of RouterB, RouterC, RouterD,
and RouterE are
similar to the configuration of RouterA, and are not provided here.

[RouterA] ospf
[RouterA-ospf-1-area-0.0.0.0] network 192.168.1.0
0.0.0.255 [RouterA-ospf-1-area-0.0.0.0] network
192.168.5.0 0.0.0.255 [RouterA-ospf-1-area-0.0.0.0] quit
2. Enable multicast routing on all routers and PIM-SM on all interfaces.
# Enable multicast routing on all routers and enable PIM-SM on all interfaces. The
configurations of RouterB, RouterC, RouterD, and RouterE are similar to the configuration
of RouterA, and are not mentioned here.

3. Enable IGMP on the interface connected to user hosts.
# Enable IGMP on the interface that connects RouterA to user hosts. The configurations of
RouterB and RouterC are similar to the configuration of RouterA, and are not mentioned here.

4. Enable PIM silent on the interface of RouterA.

[RouterA-GigabitEthernet2/0/0] pim silent
5. Configure the RP.
NOTE:
The RP can be configured in two modes: the static RP and the dynamic RP. The static RP can
be configured together with the dynamic RP. You can also configure only the static RP or the
dynamic RP. When the static RP and the dynamic RP are configured simultaneously, you can
adjust parameters to specify the preferred RP.
This example shows how to configure a static RP and a dynamic RP together and to specify
the dynamic RP as the preferred RP and the static RP as the standby RP.
# Configure a dynamic RP. Configure one or more routers in the PIM-SM domain as the C-
RP and C-BSR. In this example, RouterE is configured as both the C-RP and C-BSR. Set the
service range of the RP and specify the locations of the C-BSR and C-RP on RouterE.
[RouterE] acl number 2008

[RouterE-acl-basic-2008] rule permit source 225.1.1.0 0.0.0.255
[RouterE-acl-basic-2008] quit
[RouterE] pim
[RouterE-pim] c-bsr gigabitethernet 4/0/0
[RouterE-pim] c-rp gigabitethernet 4/0/0 group-policy 2008
# Configure a static RP. Specify IP addresses for RPs on all routers. The configuration of
RouterA is used as an example. The configurations of RouterB, RouterC, RouterD, and
RouterE are similar to the configuration of RouterA, and are not mentioned here.
NOTE:
If you enter preferred to the right of static-rp X.X.X.X, the static RP is selected as the RP in the
PIM-SM domain.
[RouterA] pim
6. Configure the BSR boundary on the interface connecting RouterD to the Internet.

[RouterD-GigabitEthernet2/0/0] pim bsr-boundary
# Run the display pim interface command to view the configuration and running status of PIM
on the interface. The PIM configuration on RouterC is as follows:

Interface Sta
GE1/0/0
GE2/0/0
# Run the display pim bsr-info command to view information about BSR election on
routers. For example, BSR information on RouterA and RouterE is as follows (C-BSR
information is also displayed on RouterE):
<RouterA> display pim bsr-info
Elected AdminScoped BSR Count: 0
Elected BSR Address: 192.168.4.2
Priority: 0
Hash mask length: 30
State: Accept Preferred
Scope: Not scoped
Uptime: 01:40:40
Expires: 00:01:42
C-RP Count: 1
<RouterE> display pim bsr-info

Elected AdminScoped BSR Count: 0
Elected BSR Address: 192.168.4.2
Priority: 0
Mask length: 30
State: Elected
Scope: Not scoped
Uptime: 00:00:18
Next BSR message scheduled at :00:01:42
C-RP Count: 1
Candidate AdminScoped BSR Count: 0
Candidate BSR Address is: 192.168.4.2
Priority: 0
Hash mask length: 30
State:Elected
Scope: Not scoped
Wait to be BSR: 0
# Run the display pim rp-info command on routers to check RP information. RP

information on RouterA is as follows:
<RouterA> display pim rp-info

PIM-SM BSR RP Number:1
Group/MaskLen: 225.1.1.0/24
RP: 192.168.4.2
Priority: 0
Uptime: 00:45:13
Expires: 00:02:17
PIM SM static RP Number:1
Static RP: 192.168.2.2
# Run the display pim routing-table command to view the PIM multicast routing table on
the routers. The multicast source 10.110.3.100/24 sends messages to the multicast group
225.1.1.1/24. HostA and HostB join the multicast group 225.1.1.1/24. Take RouterA and
RouterB as an example. The command output is as follows:
NOTE:
By default, when the receiver's DR receives the first multicast packet, it triggers an
SPT switchover and creates a new (S, G) entry. The (S, G) entry displayed on the router is the
(S, G) entry created after the SPT switchover completes.
(*, 225.1.1.1)
RP: 192.168.4.2
UpTime: 00:13:46
Upstream interface: GigabitEthernet3/0/0,
(10.110.3.100, 225.1.1.1)
RP: 192.168.4.2
Protocol: pim-sm, Flag: SPT ACT
UpTime: 00:00:42
downstreams: 1
Protocol: pim-sm, UpTime: 00:00:42,
Expires:- [RouterB] display pim routing-table
1210
(*, 225.1.1.1)
RP: 192.168.4.2
UpTime: 00:10:12
(10.110.3.100, 225.1.1.1)
RP: 192.168.4.2
Protocol: pim-sm, Flag: SPT ACT
UpTime: 00:00:42
downstreams: 1
Protocol: pim-sm, UpTime: 00:00:30, Expires:-
Configuration Files
#
sysname RouterA
#
#
ip address 192.168.5.1 255.255.255.0
pim sm
#
ip address 10.110.1.1 255.255.255.0
pim silent
pim sm
igmp enable
#
ip address 192.168.1.1 255.255.255.0
pim sm
#
ospf 1
area 0.0.0.0
network 10.110.1.0 0.0.0.255
network 192.168.1.0 0.0.0.255
network 192.168.5.0 0.0.0.255
#
pim
static-rp 192.168.2.2
#
return
#
sysname RouterB
#
#
ip address 192.168.2.1 255.255.255.0
pim sm
#
ip address 10.110.2.1 255.255.255.0
pim sm
igmp enable
#
ospf 1
area 0.0.0.0
network 10.110.2.0 0.0.0.255
network 192.168.2.0 0.0.0.255
#
pim
static-rp 192.168.2.2
#
return
#
sysname RouterC
#
#
ip address 10.110.2.2 255.255.255.0
pim sm
igmp enable
#
ip address 192.168.3.1 255.255.255.0
pim sm
#
ospf 1
area 0.0.0.0
network 10.110.2.0 0.0.0.255
network 192.168.3.0 0.0.0.255
#
pim
static-rp 192.168.2.2
#
return
#
sysname RouterD
#
#
ip address 10.110.3.1 255.255.255.0
pim sm
#
ip address 10.110.4.1 255.255.255.0
pim sm
pim bsr-boundary
#
ip address 192.168.1.2 255.255.255.0
pim sm
#
ip address 192.168.4.1 255.255.255.0
pim sm
#
ospf 1
area 0.0.0.0
network 10.110.3.0 0.0.0.255
network 10.110.4.0 0.0.0.255
network 192.168.1.0 0.0.0.255
network 192.168.4.0 0.0.0.255
#
pim
static-rp 192.168.2.2
#
return
#
sysname RouterE
#
#
acl number 2008
#
ip address 192.168.5.2 255.255.255.0
pim sm
#
ip address 192.168.3.2 255.255.255.0
pim sm
#
ip address 192.168.2.2 255.255.255.0
pim sm
#
ip address 192.168.4.2 255.255.255.0
pim sm
#
ospf 1
area 0.0.0.0
network 192.168.2.0 0.0.0.255
network 192.168.3.0 0.0.0.255
network 192.168.4.0 0.0.0.255
network 192.168.5.0 0.0.0.255
#
pim
c-bsr GigabitEthernet4/0/0
c-rp GigabitEthernet4/0/0 group-policy 2008
static-rp 192.168.2.2
#
return
11.6.12 Example for Configuring SPT Routerover in PIM-SM Domain
Receivers can receive the VoD information in multicast mode. The entire PIM network adopts a
single BSR administrative domain. By default, after receiving the first multicast data packet, the RP
and the DR on the receiver side perform the SPT switchover, searching for an optimal path to receive
the multicast information from the multicast source. If receivers require that the SPT switchover be
performed after the traffic reaches the threshold, you need to configure the SPT switchover.
As shown in Figure 11-6-12, you need to configure the routers properly, so that HostA on the leaf
network can receive multicast data from the RP (GE1/0/0 of RouterA). When the transmission rate of
multicast data packets reaches 1024 kbit/s, the SPT switchover is performed. After the SPT
switchover, the path through which HostA receives multicast packets is Source-RouterB-RouterC-
HostA.
Figure 11-6-12 Networking diagram for performing SPT switchover in PIM-SM domain
1. Configure an IP address for each interface on routers and a unicast routing protocol.
2. Enable the multicast function on all routers, enable PIM-SM on all interfaces, and enable IGMP
on the interface connected to user hosts.
3. Configure the same static RP on each router.
4. Configure the SPT switchover on RouterC.
Procedure
1. Configure an IP address for each interface on routers and a unicast routing protocol.
# Configure an IP address and mask for each interface according to Figure 11-6-12. Configure
OSPF on RouterA, RouterB, and RouterC to ensure IP connectivity between them, and enable
them to dynamically update routing information. The configuration of RouterA and RouterB
are
similar to the configuration of RouterC, and are not mentioned here.

[RouterC-GigabitEthernet1/0/0] ip address 192.168.1.2 24
[RouterCA] ospf
2. Enable the multicast function on all routers, enable PIM-SM on all interfaces, and enable IGMP
on the interface connected to user hosts.
# Enable the multicast function on all routers, PIM-SM on all interfaces, and IGMP on the
interface that connects RouterC to the leaf network. The configurations of RouterA and
RouterB are similar to the configuration of RouterC, and are not mentioned here.
[RouterC] multicast routing-enable

[RouterC-GigabitEthernet1/0/0] pim sm
[RouterC-GigabitEthernet2/0/0] igmp enable
3. Configure a static RP.
# Configure a static RP on RouterA, RouterB, and RouterC. The configurations of RouterB and
RouterC are similar to the configuration of RouterA, and are not mentioned here.
[RouterA] pim
4. Configure the threshold for an SPT switchover.
# Configure RouterC to perform an SPT switchover when the transmission rate of

multicast packets reaches 1024 kbit/s.
[RouterC] pim
[RouterC-pim] spt-switch-threshold 1024
[RouterC-pim] quit
# The multicast source begins to send data to the multicast group, and HostA can receive
the data from the source. When the rate is smaller than 1024 kbit/s, run the display pim
routing-table command to view the PIM multicast routing table on RouterC. You can find that
the upstream neighbor is RouterA. The command output is as follows:
<RouterC> display pim routing-table

(*, 225.1.1.1)
RP: 192.168.1.1
UpTime: 00:13:46
(10.110.5.100, 225.1.1.1)
RP: 192.168.1.1
Protocol: pim-sm, Flag: ACT
UpTime: 00:00:42
# When the rate is higher than 1024 kbit/s, run the display pim routing-table command to view
the PIM multicast routing table on RouterC. You can find that the upstream neighbor is
RouterB.
The command output is as follows:

(*, 225.1.1.1)
RP: 192.168.1.1
UpTime: 00:13:46
Upstream interface:
GigabitEthernet3/0/0, Upstream
neighbor: 192.168.2.1
1: GigabitEthernet2/0/0,
(10.110.5.100, 225.1.1.1)
RP: 192.168.1.1
Protocol: pim-sm, Flag:RPT SPT ACT
UpTime: 00:00:42
Configuration Files
#
sysname RouterA
#
#
ip address 192.168.1.1 255.255.255.0
pim sm
#
ip address 192.168.3.1 255.255.255.0
pim sm
#
pim
static-rp 192.168.1.1
#
ospf 1
area 0.0.0.0
network 192.168.1.0 0.0.0.255
network 192.168.3.0 0.0.0.255
#
return
#
sysname RouterB
#
#
ip address 192.168.2.1 255.255.255.0
pim sm
#
ip address 192.168.3.2 255.255.255.0
pim sm
#
ip address 10.110.5.1 255.255.255.0
pim sm
#
pim
static-rp 192.168.1.1
#
ospf 1
area 0.0.0.0
network 10.110.5.0 0.0.0.255
network 192.168.2.0 0.0.0.255
network 192.168.3.0 0.0.0.255
#
return

1210
#
sysname RouterC
#
#
ip address 192.168.1.2 255.255.255.0
pim sm
#
ip address 10.110.2.1 255.255.255.0
pim sm
igmp enable
#
ip address 192.168.2.2 255.255.255.0
pim sm
#
pim
spt-switch-threshold 1024
static-rp 192.168.1.1
#
ospf 1
area 0.0.0.0
network 10.110.2.0 0.0.0.255
network 192.168.1.0 0.0.0.255
network 192.168.2.0 0.0.0.255
#
return
11.6.13 Example for Configuring a PIM-SM (SSM Model) Network
As shown in Figure 11-6-13, configure the PIM-SM protocol on routers to enable them to
provide SSM services for user hosts on the network. Then hosts in a multicast group can receive
Voice on Demand (VoD) streams sent from specified sources to this group.
Figure 11-6-13 Networking diagram for configuring a PIM-SM (SSM model) network
Router Inte
RouterA
RouterB
RouterC
1. Configure an IP address for each interface on routers and a unicast routing protocol. PIM is an
intra-domain multicast routing protocol that depends on a unicast routing protocol. The
multicast routing protocol can work normally after the unicast routing protocol works
normally.
2. Enable the multicast function on all routers providing multicast services. Before
configuring other PIM-SM functions, you must enable the multicast function.
3. Enable PIM-SM on all interfaces of the routers. After PIM-SM is enabled, you can
configure other PIM-SM functions.
4. Enable IGMP on interfaces that connect routers to user hosts, and set the IGMP version to
IGMPv3. A receiver can join or leave a multicast group by sending IGMP messages. The
leaf routers maintain the multicast member relationship using IGMP.
NOTE:
If PIM-SM and IGMP need to be enabled on the same user host, enable PIM-SM, and
then enable IGMP.
5. Configure the interface connected to hosts to be PIM silent to prevent malicious hosts from
simulating PIM Hello messages. In this manner, security of the PIM-SM domain is
ensured.
NOTE:
If the user network segment is connected to multiple routers, such as RouterB and RouterC
in this example, do not enable PIM silent on interfaces that connect routers to user hosts.
6. Configure the SSM group address range on each router. Ensure that the routers in the PIM-SM
domain provide services only for multicast groups in the range of SSM group addresses. In
this manner, multicast can be controlled effectively.
NOTE:
The SSM group address range configured on each router must be the same.
Procedure
# Configure an IP address and mask for each interface according to Figure 11-6-13.
Configure OSPF on each router to ensure IP connectivity between them, and enable them to
dynamically update routing information. The configuration details are not provided here. The
configuration of RouterB, RouterC, RouterD, RouterE, and RouterF are similar to the
configuration of
RouterA, and are not mentioned.

[RouterA] ospf
0.0.0.255 [RouterA-ospf-1-area-0.0.0.0] network
192.168.5.0 0.0.0.255 [RouterA-ospf-1-area-0.0.0.0] quit
configurations of RouterB, RouterC, RouterD, RouterE, and RouterF are similar to
the configuration of RouterA, and are not mentioned here.

3. Enable IGMP on the router interface connected to user hosts, and set the IGMP version to
IGMPv3.
# Enable IGMP on the interface that connects RouterA to user hosts. The configurations of
RouterB and RouterC are similar to the configuration of RouterA, and are not mentioned here.

4. Enable PIM silent on the interface of RouterA.

[RouterA-GigabitEthernet3/0/0] pim silent
5. Configure the SSM group address range.

# Configure the SSM group address range to 232.1.1.0/24 on all routers. The configurations of
RouterB, RouterC, RouterD, RouterE, and RouterF are similar to those of RouterA, and
the detailed configurations are not mentioned here.

[RouterA-acl-basic-2000] rule permit source 232.1.1.0 0.0.0.255
[RouterA] pim
[RouterA-pim] ssm-policy 2000
# Run the display pim interface command to view the configuration and running status of PIM
on the interface. The PIM configuration on RouterC is as follows:

Interface Sta
GE1/0/0
GE2/0/0
# Run the display pim routing-table command to view the PIM multicast routing table on
the routers. HostA needs to receive messages sent from multicast groups 10.110.3.100/24 and
10.110.4.100/24 to group 232.1.1.1/24. HostB needs to receive messages sent from only
multicast group 10.110.3.100/24 to group 232.1.1.1/24. The command output is as follows:

(10.110.3.100, 232.1.1.1)
Protocol: pim-ssm, Flag: SPT ACT
UpTime: 00:13:46
(10.110.4.100, 232.1.1.1)
UpTime: 00:00:42
downstreams: 1
[RouterB] display pim routing-table
(10.110.3.100, 232.1.1.1)
UpTime: 00:10:12
Upstream interface:
GigabitEthernet1/0/0, Upstream
neighbor: 192.168.2.2

(10.110.3.100, 232.1.1.1)
Protocol: pim-ssm, Flag:
UpTime: 00:01:25
[RouterD] display pim routing-table

(10.110.3.100, 232.1.1.1)
UpTime: 00:00:42
Protocol: pim-ssm, UpTime: 00:00:42, Expires:-
[RouterE] display pim routing-table

(10.110.3.100, 232.1.1.1)
UpTime: 00:13:16
Protocol: pim-ssm, UpTime: 00:13:16, Expires: 00:03:22
[RouterF] display pim routing-table

(10.110.4.100, 232.1.1.1)
UpTime: 00:13:16
Protocol: pim-ssm, UpTime: 00:15:28, Expires: 00:05:21
Configuration Files
#
sysname RouterA
#
#
acl number 2000
#
ip address 192.168.5.1 255.255.255.0
pim sm
#
ip address 192.168.1.1 255.255.255.0
pim sm
#
ip address 10.110.1.1 255.255.255.0
pim silent
pim sm
igmp enable
igmp version 3
#
ospf 1
area 0.0.0.0
network 10.110.1.0 0.0.0.255
network 192.168.1.0 0.0.0.255
network 192.168.5.0 0.0.0.255
#
pim
ssm-policy 2000
#
return
#
sysname RouterB
#
#
acl number 2000
#
ip address 192.168.2.1 255.255.255.0
pim sm
#
ip address 10.110.2.1 255.255.255.0
pim sm
igmp enable
igmp version 3
#
ospf 1
area 0.0.0.0
network 10.110.2.0 0.0.0.255
network 192.168.2.0 0.0.0.255
#
pim
ssm-policy 2000
#
return
#
sysname RouterC
#
#
acl number 2000
#
ip address 10.110.2.2 255.255.255.0
pim sm
igmp enable
igmp version 3
#
ip address 192.168.3.1 255.255.255.0
pim sm
#
ospf 1
area 0.0.0.0
network 10.110.2.0 0.0.0.255
network 192.168.3.0 0.0.0.255
#
pim
ssm-policy 2000
#
return
#
sysname RouterD
#
#
acl number 2000
#
ip address 10.110.3.1 255.255.255.0
pim sm
#
ip address 192.168.4.1 255.255.255.0
pim sm
#
ospf 1

1210
area 0.0.0.0
network 10.110.3.0 0.0.0.255
network 192.168.4.0 0.0.0.255
#
pim
ssm-policy 2000
#
return
#
sysname RouterE
#
#
acl number 2000
#
ip address 192.168.5.2 255.255.255.0
pim sm
#
ip address 192.168.3.2 255.255.255.0
pim sm
#
ip address 192.168.2.2 255.255.255.0
pim sm
#
ip address 192.168.4.2 255.255.255.0
pim sm
#
ospf 1
area 0.0.0.0
network 192.168.2.0 0.0.0.255
network 192.168.3.0 0.0.0.255
network 192.168.4.0 0.0.0.255
network 192.168.5.0 0.0.0.255
#
pim
ssm-policy 2000
#
return
#
sysname RouterF
#
#
acl number 2000
#
ip address 10.110.4.1 255.255.255.0
pim sm
#
ip address 192.168.1.2 255.255.255.0
pim sm
#
ospf 1
area 0.0.0.0
network 10.110.4.0 0.0.0.255
network 192.168.1.0 0.0.0.255
#
pim
ssm-policy 2000
#
return
11.6.14 Example for Configuring PIM for Anycast RP
In a traditional PIM-SM domain, all multicast groups map to only one RP. When the network is
overloaded or traffic is concentrated on the RP, the RP may be overburdened. If the RP fails, routes
are converged slowly or multicast data are forwarded over non-optimal paths. Configuring Anycast
RP in a
single PIM-SM domain can address this problem. IP routing will automatically select the closest RP
for each source and receiver. This releases burdens on a single RP, implements RP backup, and
optimizes multicast forwarding paths.
As shown in Figure 11-6-14, there are multiple receivers in the PIM-SM domain. Receiver2 wants
to receive multicast data from Source. You need to configure Anycast RP peering between RouterC
and RouterD, so that Receiver2 can send a Join message to the closest RouterD. After RouterA
receives multicast data from Source, it encapsulates the multicast data in a Register message and
sends it to RouterC. On receiving the Register message, RouterC forwards it to RouterD, and
Receiver2 can receive the multicast data from Source.
Figure 11-6-14 Networking diagram for configuring PIM for Anycast RP
1. Configure IP addresses for interfaces of each router, and configure OSPF to implement IP
interworking.
2. Enable the multicast function and enable PIM-SM on each interface.
3. Enable IGMP on the interfaces that connect router to hosts.
4. Configure loopback 0 on RouterC and RouterD as C-RP and C-BSR respectively.
5. Configure loopback 0 on RouterC and RouterD as Anycast RPs.
6. Configure the addresses of loopback 0 on RouterC and RouterD as local addresses of Anycast
RPs.
7. Set an Anycast RP peer relationship between RouterC and RouterD.
Procedure
# Configure an IP address and mask for each interface according to Figure 11-6-14. Configure
OSPF on each router to ensure IP connectivity between them, and enable them to dynamically
update routing information. The configuration of RouterB, RouterC, and RouterD are similar
to
the configuration of RouterA, and are not mentioned.

[RouterA] ospf
0.0.0.255 [RouterA-ospf-1-area-0.0.0.0] quit
configurations of RouterB, RouterC, and RouterD are similar to the configuration of

3. Enable IGMP on the interfaces that connect the router to hosts.
# Enable IGMP on the interfaces that connect RouterC and RouterD to hosts.


[RouterD-GigabitEthernet2/0/0] igmp enable
4. Configure loopback 0 on RouterC and RouterD as the C-RP and C-BSR respectively.
[RouterC] pim
[RouterC-pim] c-bsr loopback 0
[RouterC-pim] c-rp loopback 0
[RouterC-pim] quit
[RouterD] pim
[RouterD-pim] c-bsr loopback 0
[RouterD-pim] c-rp loopback 0
[RouterD-pim] quit
5. Configure loopback 0 on RouterC and RouterD as Anycast RPs.
[RouterC] pim
[RouterC-pim] anycast-rp 1.1.1.1
[RouterC-pim-anycast-rp-1.1.1.1] quit
[RouterC-pim] quit
[RouterD] pim
[RouterD-pim] anycast-rp 1.1.1.1
[RouterD-pim-anycast-rp-1.1.1.1] quit
[RouterD-pim] quit
6. Configure the addresses of loopback 0 on RouterC and RouterD as local addresses of Anycast
RPs.
[RouterC] pim
[RouterC-pim-anycast-rp-1.1.1.1] local-address 2.2.2.2
[RouterC-pim] quit
[RouterD] pim
[RouterC-pim-anycast-rp-1.1.1.1] local-address 3.3.3.3
[RouterD-pim] quit
7. Set an Anycast RP peer relationship between RouterC and RouterD.
[RouterC] pim
[RouterC-pim-anycast-rp-1.1.1.1] peer 3.3.3.3
[RouterC-pim] quit
[RouterD] pim
[RouterD-pim] anycast-rp 1.1.1.1
[RouterD-pim-anycast-rp-1.1.1.1] peer 2.2.2.2
[RouterD-pim-anycast-rp-1.1.1.1] quit
[RouterD-pim] quit
# Run the display pim rp-info command on RouterC and RouterD to check RP information.
<RouterC> display pim rp-info

RP: 1.1.1.1 (local)
Priority: 0
Uptime: 00:45:19
Expires: 00:02:11
<RouterD> display pim rp-info
RP: 1.1.1.1 (local)
Priority: 0
Uptime: 02:27:56
Expires: 00:01:39
The command output shows that RouterC and RouterD serve as RPs and forward the
Register message from the multicast source to each other.
# Run the display pim routing-table command to check PIM entries on each router. Source
(10.110.1.2/24) in the PIM-SM domain sends multicast data to multicast group G (226.1.1.1).
Receiver2 joins G and receives the multicast data sent to G. Source sends a Register message
to
RouterC and Receiver2 sends a Join message to RouterD.

Total 0 (*, G) entry; 1 (S, G) entries
(10.110.1.2, 226.1.1.1)
RP: 1.1.1.1 (local)
Protocol: pim-sm, Flag: 2MSDP ACT
UpTime: 00:00:38
Upstream interface: Register
Downstream interface(s) information: None
<RouterD> display pim routing-table
(*, 226.1.1.1)
RP: 1.1.1.1 (local)
UpTime: 00:01:25
Protocol: igmp, UpTime: 00:01:25, Expires: -
(10.110.1.2, 226.1.1.1)
RP: 1.1.1.1 (local)
Protocol: pim-sm, Flag: 2MSDP SWT ACT
UpTime: 00:00:02
Protocol: pim-sm, UpTime: 00:00:02, Expires: -
Configuration Files
#
sysname RouterA
#
#
ip address 10.110.1.1 255.255.255.0
pim sm
#
ip address 192.168.1.1 255.255.255.0
pim sm
#
ospf 1
area 0.0.0.0
network 10.110.1.0 0.0.0.255
network 192.168.1.0 0.0.0.255
#
return

#
sysname RouterB
#
#
ip address 192.168.2.1 255.255.255.0
pim sm
#
ospf 1
area 0.0.0.0
network 192.168.2.0 0.0.0.255
#
return
#
sysname RouterC
#
#
ip address 192.168.3.1 255.255.255.0
pim sm
#
ip address 192.168.1.2 255.255.255.0
pim sm
#
ip address 10.110.2.1 255.255.255.0
pim sm
igmp enable
#
interface LoopBack0
ip address 1.1.1.1 255.255.255.255
pim sm
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
pim sm
#
ospf 1
area 0.0.0.0
network 192.168.1.0 0.0.0.255
network 192.168.3.0 0.0.0.255
network 10.110.2.0 0.0.0.255
network 1.1.1.1 0.0.0.0
network 2.2.2.2 0.0.0.0
#
pim
c-bsr LoopBack0 c-rp
LoopBack0 anycast-
rp 1.1.1.1 local-
address 2.2.2.2
peer 3.3.3.3
#
return
#
sysname RouterD
#
#
#
ip address 192.168.2.2 255.255.255.0
pim sm
#
ip address 10.110.3.1 255.255.255.0
pim sm
igmp enable
#
ip address 192.168.3.2 255.255.255.0
pim sm
#
interface LoopBack0

1210
ip address 1.1.1.1 255.255.255.255
pim sm
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.0
pim sm
#
ospf 1
area 0.0.0.0
network 192.168.2.0 0.0.0.255
network 192.168.3.0 0.0.0.255
network 10.110.3.0 0.0.0.255
network 3.3.3.3 0.0.0.0
network 1.1.1.1 0.0.0.0
#
pim
c-bsr LoopBack0 c-rp
LoopBack0 anycast-
rp 1.1.1.1 local-
address 3.3.3.3
peer 2.2.2.2
#
return
11.6.15 Example for Configuring a Multicast Static Route to Change the RPF Route
As shown in Figure 11-6-15, RouterA, RouterB, and RouterC run OSPF to implement IP
interworking, and router interfaces use PIM-DM to provide multicast services. Data sent from the
multicast source (Source) is forwarded to the receiver host (Receiver) through RouterA and RouterB.
The link between RouterA and RouterB transmits unicast and multicast services simultaneously. To
reduce the loads on this link, multicast data needs to be transmitted along the path
RouterA→RouterC→RouterB.
Figure 11-6-15 Configuring a static route to change the RPF route
Router
RouterA
RouterB
RouterC
The RPF interface used to receive multicast data can be changed by configuring a multicast static
route. After the RPF route is changed, multicast and unicast services are transmitted through different
links so that the load on a single link is reduced. The configuration roadmap is as follows:
1. Configure IP addresses for interfaces and configure a unicast routing protocol (OSPF in
this example) on each router. Multicast routing protocols depend on unicast routing
protocols.
2. Enable multicast routing on all routers, PIM-DM on all interfaces, and IGMP on the interface
connected to the network segment of the receiver host. After these basic multicast functions
are configured, the routers can establish a multicast distribution tree using default parameter
settings. Then multicast data can be forwarded to Receiver along the multicast distribution
tree.
3. Configure a multicast RPF static route on RouterB and specify RouterC as the RPF neighbor.
Procedure
1. Configure IP addresses for interfaces and configure OSPF on each router.
# Configure IP addresses and masks for interfaces on the routers. (The configurations of
the other routers are similar to the configuration of RouterB.)

[RouterB-GigabitEthernet1/0/0] ip address 9.1.1.2 24
# Configure OSPF on the routers. (The configurations of the other routers are similar to
the configuration of RouterB.)
[RouterB] ospf
2. Enable multicast routing on the routers and enable PIM-DM on all interfaces.
# Enable multicast routing on all the routers and enable PIM-DM on all interfaces. Enable
IGMP on the interface connected to the network segment of the receiver host. (The PIM-DM
configurations on the other routers are similar to the PIM-DM configuration on RouterB.)
[RouterB] multicast routing-enable

[RouterB] interface gigabitethernet1/0/0
[RouterB-GigabitEthernet1/0/0] pim dm
[RouterB-GigabitEthernet3/0/0] igmp enable
# Run the display multicast rpf-info command on RouterB to check the RPF route to
Source. The following command output shows that the RPF route is originated from a unicast
routing
protocol, and the RPF neighbor is RouterA.
[RouterB] display multicast rpf-info 8.1.1.2

RPF information about source 8.1.1.2:
RPF interface: GigabitEthernet1/0/0, RPF neighbor: 9.1.1.1
Referenced route/mask: 8.1.1.0/24
Referenced route type: unicast
Route selection rule: preference-preferred
Load splitting rule: disable
3. Configure a multicast static route.
# Configure a multicast RPF static route to Source on RouterB, and configure RouterC as the
RPF neighbor.
[RouterB] ip rpf-route-static 8.1.1.0 255.255.255.0 13.1.1.2
# Run the display multicast rpf-info command on RouterB to check the RPF route to Source.
The following information is displayed, indicating that the unicast RPF route has been
replaced
by the multicast static route and the RPF neighbor has changed to RouterC.

Referenced route type: mstatic
Configuration Files
#
sysname RouterA
#
#
ip address 9.1.1.1 255.255.255.0
pim dm
#
ip address 8.1.1.1 255.255.255.0
pim dm
#
ip address 12.1.1.1 255.255.255.0
pim dm
#
ospf 1
area 0.0.0.0
network 8.1.1.0 0.0.0.255
network 9.1.1.0 0.0.0.255
network 12.1.1.0 0.0.0.255
#
return
#
sysname RouterB
#
#
ip address 9.1.1.2 255.255.255.0
pim dm
#
ip address 13.1.1.1 255.255.255.0
pim dm
#
ip address 7.1.1.1 255.255.255.0
pim dm
igmp enable
#
ospf 1
area 0.0.0.0
network 7.1.1.0 0.0.0.255
network 9.1.1.0 0.0.0.255
network 13.1.1.0 0.0.0.255
#
ip rpf-route-static 8.1.1.0 24 13.1.1.2
#
return
#
sysname RouterC
#
#
ip address 13.1.1.2 255.255.255.0
pim dm
#
ip address 12.1.1.2 255.255.255.0
pim dm
#
ospf 1
area 0.0.0.0
network 12.1.1.0 0.0.0.255
network 13.1.1.0 0.0.0.255

1210
#
return
11.6.16 Example for Configuring Multicast Static Routes to Connect RPF Routes
As shown in Figure 11-6-16, RouterB and RouterC run OSPF to implement IP interworking, but they
have no unicast route to RouterA. Router interfaces need to run PIM-DM to provide multicast
services. The receiver host (Receiver) can receive data from Source1. Now Receiver needs to receive
data from Source2.
Figure 11-6-16 Configuring multicast static routes to connect RPF routes
Router Interface and IP Address

RouterA
RouterB
RouterC
An RPF route to Source2 can be established on the path RouterC→RouterB→RouterA by configuring

multicast static routes on RouterB and RouterC. The configuration roadmap is as follows:
1. Configure IP addresses for interfaces of the routers. Configure OSPF on RouterB and RouterC
but not on RouterA, so that RouterB and RouterC have no unicast route to RouterA.
2. Enable multicast routing on all routers, PIM-DM on all interfaces, and IGMP on the interface
connected to the network segment of the receiver host. After these basic multicast functions
are configured, the routers can establish a multicast distribution tree using default parameter
settings. Then multicast data can be forwarded to Receiver along the multicast distribution
tree.
3. Configure multicast static routes to Source2 on RouterB and RouterC.
Procedure
1. Configure IP addresses for interfaces and configure OSPF on each router.
the other routers are similar to the configuration of RouterB.)

# Configure OSPF on RouterB and RouterC. (The configuration of RouterC is similar to

the configuration of RouterB.)
[RouterB] ospf
2. Enable multicast routing on the routers and enable PIM-DM on all interfaces.
# Enable multicast routing on all routers, PIM-DM on all interfaces, and IGMP on the
interface connected to the network segment of the receiver host.
Configure RouterA.

Configure RouterB.
[RouterB] multicast routing-enable

[RouterC] multicast routing-enable

[RouterC-GigabitEthernet1/0/0] pim dm
[RouterC-GigabitEthernet2/0/0] pim dm
# Source1 (10.1.3.2/24) and Source2 (10.1.5.2/24) send multicast data to group G (225.1.1.1).
After Receiver joins group G, it receives the multicast data sent by Source1 but cannot
receive the multicast data sent by Source2.
# Run the display multicast rpf-info 10.1.5.2 command on RouterB and RouterC. No
information is displayed, indicating that the routers have no RPF route to Source2.
3. Configure multicast static routes.
# Configure a multicast RPF static route to Source2 on RouterB, and configure RouterA as
the
RPF neighbor.
[RouterB] ip rpf-route-static 10.1.5.0 255.255.255.0 10.1.4.2
# Configure a multicast RPF static route to Source2 on RouterC, and configure RouterB as the
RPF neighbor.
[RouterC] ip rpf-route-static 10.1.5.0 255.255.255.0 10.1.2.2
# Run the display multicast rpf-info 10.1.5.2 command on RouterB and RouterC to check the
RPF route to Source2. The following information is displayed:

RPF information about source: 10.1.5.2
Route selecting rule: preference-preferred
[RouterC] display multicast rpf-info 10.1.5.2
1210
# Run the display pim routing-table command on RouterC to check the PIM routing table.
RouterC has multicast entries of Source2, indicating that Receiver can receive multicast
data
from Source2.

(*, 225.1.1.1)
Protocol: pim-dm, Flag: WC
UpTime: 03:54:19
Upstream interface: NULL
Protocol: igmp, UpTime: 01:38:19, Expires: never
(10.1.3.2, 225.1.1.1)
UpTime: 00:00:44
Protocol: pim-dm, UpTime: 00:00:44, Expires: never
(10.1.5.2, 225.1.1.1)
UpTime: 00:00:44
Protocol: pim-dm, UpTime: 00:00:44, Expires: never
Configuration Files
#
sysname RouterA
#
#
ip address 10.1.5.1 255.255.255.0
pim dm
#
ip address 10.1.4.2 255.255.255.0
pim dm
#
return
#
sysname RouterB
#
#
ip address 10.1.2.2 255.255.255.0
pim dm
#
ip address 10.1.3.1 255.255.255.0
pim dm
#
ip address 10.1.4.1 255.255.255.0
pim dm
#
ospf 1
area 0.0.0.0
network 10.1.2.0 0.0.0.255
network 10.1.3.0 0.0.0.255
#
#
return
#
sysname RouterC
#
#
ip address 10.1.2.1 255.255.255.0
pim dm
#
ip address 10.1.1.1 255.255.255.0
pim dm
igmp enable
#
ospf 1
area 0.0.0.0
network 10.1.1.0 0.0.0.255
network 10.1.2.0 0.0.0.255
#
#
11.6.17 Example for Configuring Multicast Load Splitting
As shown in Figure 11-6-17, RouterE connects to HostA and has three equal-cost routes to the
multicast source (Source). According to the default RPF check policy, RouterE will select one
of
equal-cost routes to transmit multicast data. When the rate of multicast traffic is high, the network
may be congested, degrading the quality of multicast services. To ensure the quality of multicast
services, configure multicast load splitting so that multicast data can be transmitted through multiple
equal-cost routes.
Figure 11-6-17 Networking diagram of multicast load splitting
Router Interface and IP A
RouterA
RouterB
RouterC
 Configure IP addresses for the interfaces on each router.

 Configure a unicast routing protocol (IS-IS in this example) to implement interworking
among all the routers and ensure that route costs are the same.
 Enable multicast routing on all the routers, enable PIM-SM on all interfaces, and
configure loopback 0 of RouterA as a C-BSR and C-RP.
 On RouterE, configure stable-preferred multicast load splitting to ensure stable transmission

of multicast services.
 On RouterE, configure static multicast groups on the interface connected to HostA, because
HostA needs to receive data of these groups for a long time.
 On RouterE, configure different multicast load splitting weights for the interfaces connected
to the upstream routers to implement unbalanced load splitting, because HostA needs to
receive multicast data of new groups.
Procedure
1. Configure IP addresses for the interfaces on the routers.
the other routers are similar to the configuration of RouterA.)

[RouterA] interface loopback0
[RouterA-LoopBack0] ip address 1.1.1.1 32
2. Configure IS-IS to implement interworking among all the routers and ensure that route costs
are the same.
# Configure RouterA. (The configurations of the other routers are similar to the configuration of
RouterA.)
[RouterA] isis
[RouterA-GigabitEthernet1/0/0] isis enable
[RouterA] interface loopback0
[RouterA-LoopBack0] isis enable
3. Enable multicast routing on all the routers and enable PIM-SM all interfaces.
# Configure RouterA. (The configurations of the other routers are similar to the configuration of
RouterA.)

[RouterA] interface loopback 0
[RouterA-LoopBack0] pim sm
4. Configure a C-RP on RouterA.
# Configure Loopback0 of RouterA as a C-BSR and C-RP.
[RouterA] pim
1210
[RouterA-pim] c-bsr loopback 0
[RouterA-pim] c-rp loopback 0
[RouterA-pim] quit
5. Configure stable-preferred multicast load splitting on RouterE.
[RouterE] multicast load-splitting stable-preferred
6. Configure static multicast groups on the interface of RouterE connected to HostA.
# Configure static multicast groups 225.1.1.1 to 225.1.1.3 on GE2/0/0.
[RouterE] interface gigabitethernet2/0/0

[RouterE-GigabitEthernet2/0/0] igmp static-group 225.1.1.1 inc-step-mask 32 number 3
[RouterE-GigabitEthernet2/0/0] quit
7. Verify the configuration of stable-preferred multicast load splitting.
# Source (10.110.1.1/24) sends multicast data to multicast groups 225.1.1.1 to 225.1.1.3.

HostA can receive multicast data from Source. Check brief information about the PIM routing
table on RouterE.
<RouterE> display pim routing-table brief

Total 3 (*, G) entries; 3 (S, G) entries
00001.(*, 225.1.1.1)
Upstream interface:GE1/0/3
Number of downstream:1
00002.(10.110.1.1, 225.1.1.1)
00003.(*, 225.1.1.2)
00004.(10.110.1.1, 225.1.1.2)
00005.(*, 225.1.1.3)
00006.(10.110.1.1, 225.1.1.3)
(*, G) and (S, G) entries are evenly distributed on the three equal-cost routes. The
upstream interfaces of the routes are GE1/0/1, GE1/0/2, GE1/0/3 respectively.
NOTE:
The load splitting algorithm processes (*, G) and (S, G) entries separately using the same rule.
8. Set different multicast load splitting weights for upstream interfaces of RouterE to
implement uneven multicast load splitting.
# Set the multicast load splitting weight of GE1/0/1 to 3.
[RouterE] interface gigabitethernet 1/0/1

[RouterE-GigabitEthernet1/0/1] multicast load-splitting weight 3
# Set the multicast load splitting weight of GE1/0/2 to 2.

[RouterE-GigabitEthernet1/0/2] multicast load-splitting weight 2
9. Configure new static multicast groups on the interface of RouterE connected to HostA.
# Configure static multicast groups 225.1.1.4 to 225.1.1.6 on GE2/0/0.

[RouterE-GigabitEthernet2/0/0] igmp static-group 225.1.1.4 inc-step-mask 32 number 3
10. Verify the configuration of uneven multicast load splitting.
# Source (10.110.1.1/24) sends multicast data to multicast groups 225.1.1.1 to 225.1.1.6. HostA
can receive multicast data from Source. Check brief information about the PIM routing table on
RouterE.
<RouterE> display pim routing-table brief

00001.(*, 225.1.1.1)
00002.(10.110.1.1, 225.1.1.1)
00003.(*, 225.1.1.2)
00004.(10.110.1.1, 225.1.1.2)
00005.(*, 225.1.1.3)
00006.(10.110.1.1, 225.1.1.3)
00007.(*, 225.1.1.4)
00008.(10.110.1.1, 225.1.1.4)
00009.(*, 225.1.1.5)
00010.(10.110.1.1, 225.1.1.5)
00011.(*, 225.1.1.6)
00012.(10.110.1.1, 225.1.1.6)
00013.(*, 225.1.1.7)
00014.(10.110.1.1, 225.1.1.7)
00015.(*, 225.1.1.8)
00016.(10.110.1.1, 225.1.1.8)
00017.(*, 225.1.1.9)
00018.(10.110.1.1, 225.1.1.9)
The upstream interfaces of existing (*, G) and (S, G) entries remain unchanged. GE1/0/1 has a
larger multicast load splitting weight (3) than GE1/0/2 (2). Therefore, more new (*, G) and (S,
G) entries are distributed to the route with GE1/0/1 as the upstream interface. The multicast
load splitting weight of GE1/0/3 is 1 (default value), smaller than the weights of GE1/0/1 and
GE1/0/2. Therefore, the route with GE1/0/3 as the upstream interface does not have new
entries.
Configuration Files
#
sysname RouterA
#
#
isis 1
network-entity 10.0000.0000.0001.00
#
ip address 10.110.1.2 255.255.255.0
isis enable 1
pim sm
#
ip address 192.168.1.1 255.255.255.0
isis enable 1
pim sm
#
ip address 192.168.2.1 255.255.255.0
isis enable 1
pim sm
#
1210
ip address 192.168.3.1 255.255.255.0
isis enable 1
pim sm
#
interface LoopBack0
ip address 1.1.1.1 255.255.255.255
isis enable 1
pim sm
#
pim
c-bsr LoopBack0
c-rp LoopBack0
#
return
#
sysname RouterB
#
#
isis 1
network-entity 10.0000.0000.0002.00
#
ip address 192.168.1.2 255.255.255.0
isis enable 1
pim sm
#
ip address 192.168.4.1 255.255.255.0
isis enable 1
pim sm
#
return
#
sysname RouterC
#
#
isis 1
network-entity 10.0000.0000.0003.00
#
ip address 192.168.2.2 255.255.255.0
isis enable 1
pim sm
#
ip address 192.168.5.1 255.255.255.0
isis enable 1
pim sm
#
return
#
sysname RouterD
#
#
isis 1
network-entity 10.0000.0000.0004.00
#
ip address 192.168.3.2 255.255.255.0
isis enable 1
pim sm
#
ip address 192.168.6.1 255.255.255.0
isis enable 1
pim sm
#
return
#
sysname RouterE
#
multicast load-splitting stable-preferred
#
isis 1
network-entity 10.0000.0000.0005.00
#
ip address 192.168.4.2 255.255.255.0
isis enable 1
pim sm
multicast load-splitting weight 3
#
ip address 192.168.5.2 255.255.255.0
isis enable 1
pim sm
multicast load-splitting weight 2
#
ip address 192.168.6.2 255.255.255.0
isis enable 1
pim sm
#
ip address 10.110.2.2 255.255.255.0
isis enable 1
pim sm
igmp static-group 225.1.1.1 inc-step-mask 0.0.0.1 number
3 igmp static-group 225.1.1.4 inc-step-mask 0.0.0.1 number
3
#
return
Chapter 12 IPv6
12.1 IPv6 Addresses
12.1.1 IPv6 Address Formats
An IPv6 address is 128 bits long. It is written as eight groups of four hexadecimal digits (0 to 9, A to
F), where each group is separated by a colon (:). For example,
2031:0000:130F:0000:0000:09C0:876A:130B is a valid IPv6 address. This IPv6 address format is
the preferred format.
For convenience, IPv6 provides the compressed format. The following uses IPv6 address
2031:0000:130F:0000:0000:09C0:876A:130B as an example to describe the compressed format:
 Any zeros at the beginning of a group can be omitted. Then the given example
becomes
2031:0:130F:0:0:9C0:876A:130B.
 A double colon (::) can be used in an IPv6 address when two or more consecutive groups
contain all zeros. Then the given example can be written as 2031:0:130F::9C0:876A:130B.
NOTE:
An IPv6 address can contain only one double colon (::). Otherwise, a computer cannot determine
the number of zeros in a group when restoring the compressed address to the original 128-bit address.
12.1.2 IPv6 Address Structure
An IPv6 address has two parts:
 Network prefix: corresponds to the network ID of an IPv4 address. It is of n bits.
 Interface identifier (interface ID): corresponds to the host ID of an IPv4 address. It is of 128-n
bits.
NOTE:
If the first 3 bits of an IPv6 unicast address are not 000, the interface ID must be of 64 bits. If the first
3 bits are 000, there is no such limitation.
The interface ID can be manually configured, generated through the system software, or generated
in IEEE 64-bit Extended Unique Identifier (EUI-64) format. It is most common to generate the
interface ID in EUI-64 format.
IEEE EUI-64 standards convert an interface MAC address into an IPv6 interface ID. As shown in
Figure 12-1-1, if a 48-bit MAC address is used as an interface ID, the first 24 bits (expressed by c) is
a vendor identifier, and the last 24 bits (expressed by m) is an extension identifier. If the higher
seventh bit is 0, the MAC address is locally unique. During conversion, EUI-64 inserts FFFE between
the vendor identifier and extension identifier of the MAC address, and then the higher seventh bit 0 is
changed to 1 to indicate that the interface ID is globally unique.
Figure 12-1-1 EUI-64 format
For example, if the MAC address is 00-0E-0C-82-C4-D4, the interface ID is
020E:0CFF:FE:82:C4D4 after the conversion.
The method for converting MAC addresses into IPv6 interface IDs reduces the configuration
workload. When stateless address autoconfiguration is used, you only need an IPv6 network prefix
before obtaining an IPv6 address. The defect of this method is that an IPv6 address can be easily
calculated based on a MAC address.
12.1.3 IPv6 Address Types
IPv6 addresses are classified into unicast, anycast, and multicast addresses. Compared to IPv4,
IPv6 has no broadcast address, uses multicast addresses as broadcast addresses, and introduces a
new address type anycast address.
IPv6 Unicast Address
An IPv6 unicast address identifies an interface. Each interface belongs to a node. Therefore, the IPv6
unicast address of any interface on a node can identify the node. Packets sent to an IPv6 unicast
address are delivered to the interface identified by the unicast address.
IPv6 defines multiple unicast addresses, including unspecified address, loopback address,
global unicast address, link-local address, and unique local address.
 Unspecified address
An IPv6 unspecified address is 0:0:0:0:0:0:0:0/128 or ::/128, indicating that an interface or a

node does not have an IP address. It can be used as the source IP address of some packets,
such
as Neighbor Solicitation (NS) message in duplicate address detection. Routers do not forward
the packets with the source IP address as an unspecified address.
 Loopback address
An IPv6 loopback address is 0:0:0:0:0:0:0:1/128 or ::1/128. Similar to IPv4 loopback address

127.0.0.1, IPv6 loopback address is used when a node needs to send IPv6 packets to itself. This
IPv6 loopback address is usually used as the IP address of a virtual interface (a loopback
interface for example). The loopback address cannot be used as the source or destination IP
address of packets that need to be forwarded.
 Global unicast address
An IPv6 global unicast address is an IPv6 address with a global unicast prefix, which is similar
to an IPv4 public address. IPv6 global unicast addresses support route prefix summarization,
helping limit the number of global routing entries.
A global unicast address consists of a global routing prefix, subnet ID, and inter face ID, as
Figure 12-1-2 Global unicast address format

Global routing prefix: is assigned by a service provider to an organization. A global routing
prefix is of at least 48 bits. Currently, the first 3 bits of all the assigned global routing prefixes are
001.
Subnet ID: is used by organizations to construct a local network (site). There are a maximum of
64 bits for both the global routing prefix and subnet ID. It is similar to an IPv4 subnet
number. Interface ID: identifies a device (host).
 Link-local address
Link-local addresses are used only in communication between nodes on the same local link.
A link-local address uses a link-local prefix FE80::/10 as the first 10 bits (1111111010 in
binary) and an interface ID as the last 64 bits.
When IPv6 runs on a node, each interface of the node is automatically assigned a link-local
address that consists of a fixed prefix and an interface ID in EUI-64 format. This mechanism
enables two IPv6 nodes on the same link to communicate without any configuration.
Therefore, link-local addresses are widely used in neighbor discovery and stateless address
configuration.
Routers do not forward IPv6 packets with the link-local address as a source or destination
address to devices on different links.
Figure 12-1-3 shows the link-local address format.

Figure 12-1-3 Link-local address format
 Unique local address
Unique local addresses are used only within a site. Site-local addresses are deprecated in RFC
3879 and replaced by unique local addresses in RFC 4193.
Unique local addresses are similar to IPv4 private addresses. Any organization that does not
obtain a global unicast address from a service provider can use a unique local address.
Unique local addresses are routable only within a local network but not the Internet.
Figure 12-1-4 shows the unique local address format.
Figure 12-1-4 Unique local address format

Prefix: is fixed as FC00::/7.
L: is set to 1 if the address is valid within a local network. The value 0 is reserved for
future expansion.
Global ID: indicates a globally unique prefix, which is pseudo-randomly allocated (for
details, see RFC 4193).
Subnet ID: identifies a subnet within the site.
Interface ID: identifies an interface.

A unique local address has the following characteristics:
 Has a globally unique prefix. The prefix is pseudo-randomly allocated and has a
high probability of uniqueness.
 Allows private connections between sites without creating address conflicts.
 Has a well-known prefix (FC00::/7) that allows for easy route filtering at site boundaries.
 Does not conflict with any other addresses if it is leaked outside of the site through routing.
 Functions as a global unicast address to applications.

 Is independent of the Internet Service Provider (ISP).
IPv6 Multicast Address
Like an IPv4 multicast address, an IPv6 multicast address identifies a group of interfaces, which
usually belong to different nodes. A node may belong to any number of multicast groups. Packets
sent to an IPv6 multicast address are delivered to all the interfaces identified by the multicast
address.
An IPv6 multicast address is composed of a prefix, flag, scope, and group ID (global ID):
 Prefix: is fixed as FF00::/8 (1111 1111).
 Flag: is 4 bits long. The high-order 3 bits are reserved and must be set to 0s. The last bit 0
indicates a permanently-assigned (well-known) multicast address allocated by the
Internet Assigned Numbers Authority (IANA). The last bit 1 indicates a non-
permanently-assigned (transient) multicast address.
 Scope: is 4 bits long. It limits the scope where multicast data flows are sent on the network.
Figure 12-1-5 shows the field values and meanings.
 Group ID (global ID): is 112 bits long. It identifies a multicast group. RFC 2373 does not
define all the 112 bits as a group ID but recommends using the low-order 32 bits as the group
ID and setting all the remaining 80 bits to 0s. In this case, each multicast group ID maps to a
unique Ethernet multicast MAC address (for details, see RFC 2464).
Figure 12-1-5 shows the IPv6 multicast address format.
Figure 12-1-5 IPv6 multicast address format
 Solicited-node multicast address
A solicited-node multicast address is generated using an IPv6 unicast or anycast address of a

node. When a node has an IPv6 unicast or anycast address, a solicited-node multicast address
is generated for the node, and the node joins the multicast group that corresponds to the IPv6
unicast or anycast address. A unicast or anycast address corresponds to a solicited-node
multicast address, which is often used in neighbor discovery and duplicate address detection.
IPv6 does not support broadcast addresses or Address Resolution Protocol (ARP). In IPv6,
Neighbor Solicitation (NS) packets are used to resolve IP addresses to MAC addresses. When
a node needs to resolve an IPv6 address to a MAC address, it sends an NS packet in which the
destination IP address is the solicited-node multicast address corresponding to the IPv6
address.
The solicited-node multicast address consists of the prefix FF02::1:FF00:0/104 and the last
24 bits of the corresponding unicast address.
IPv6 Anycast Address
An anycast address identifies a group of network interfaces, which usually belong to different nodes.
Packets sent to an anycast address are delivered to the nearest interface that is identified by the
anycast address, depending on the routing protocols.
Anycast addresses are designed to implement the redundancy and load balancing functions when
multiple hosts or nodes are provided with the same services. Currently, a unicast address is assigned
to more than one interface to make a unicast address become an anycast address. When a unicast
address is assigned to multiple hosts or nodes, the sender cannot determine which device can receive
the sent data packets with the destination IP address as the anycast address, if there are multiple
routes to the anycast address. This depends on the routing protocols running on the network. Anycast
addresses are used in stateless applications, such as Domain Name Service (DNS).
IPv6 anycast addresses are allocated from the unicast address space. Anycast addresses are used
in mobile IPv6 applications. Anycast prefix (2002:c058:6301::) is also used in IPv6-to-IPv4 relay.
NOTE:
IPv6 anycast addresses can be assigned only to routers but not hosts. Anycast addresses cannot be
used as the source IP addresses of IPv6 packets.
 Subnet-router anycast address
A subnet-router anycast address is predefined in RFC 3513. Packets sent to a subnet-router

anycast address are delivered to the nearest router on the subnet identified by the anycast
address, depending on the routing protocols. All routers must support subnet-router anycast
addresses. A subnet-router anycast address is used when a node needs to communicate with any
of the routers on the subnet identified by the anycast address. For example, a mobile node needs
to communicate with one of the mobile agents on the home subnet.
In a subnet-router anycast address, the n-bit subnet prefix identifies a subnet and the
remaining bits are padded with 0s. Figure 12-1-6 shows the subnet-router anycast address
format.
Figure 12-1-6 Subnet-router anycast address format

12.2 IPv6 Packet Format
An IPv6 packet has three parts: an IPv6 basic header, one or more IPv6 extension headers, and
an upper-layer protocol data unit (PDU).
An upper-layer PDU is composed of the upper-layer protocol header and its payload such as
an
ICMPv6 packet, a TCP packet, or a UDP packet.
12.2.1 IPv6 Basic Header
An IPv6 basic header is fixed as 40 bytes long and has eight fields. Each IPv6 packet must have
an IPv6 basic header. The IPv6 basic header provides basic packet forwarding information and
will be parsed by all routers on the forwarding path.
Figure 12-2-1 shows the IPv6 basic header.
Figure 12-2-1 IPv6 basic header
An IPv6 basic header contains the following

fields:
 Version: is 4 bits long. In IPv6, the Version field value is 6.
 Traffic Class: is 8 bits long. It indicates the class or priority of an IPv6 packet. The Traffic
Class field is similar to the TOS field in an IPv4 packet and is mainly used in QoS control.
 Flow Label: is 20 bits long. This field is added in IPv6 to differentiate traffic. A flow label and
source IP address identify a data flow. Intermediate network devices can effectively
differentiate data flows based on this field.
 Payload Length: is 16 bits long, which indicates the length of the IPv6 payload. The payload
is the rest of the IPv6 packet following this basic header, including the extension header and
1210
upper-layer PDU. This field indicates only the payload with the maximum length of 65535 bytes.

1210
If the payload length exceeds 65535 bytes, the field is set to 0. The payload length is
expressed by the Jumbo Payload option in the Hop-by-Hop Options header.
 Next Header: is 8 bits long. This field identifies the type of the first extension header that
follows the IPv6 basic header or the protocol type in the upper-layer PDU.
 Hop Limit: is 8 bits long. This field is similar to the Time to Live field in an IPv4 packet,
defining the maximum number of hops that an IP packet can pass through. The field value is
decremented by 1 by each device that forwards the IP packet. When the field value becomes
0, the packet is discarded.
 Source Address: is 128 bits long, which indicates the address of the packet originator.
 Destination Address: is 128 bits long, which indicates the address of the packet recipient.
Compared with the IPv4 packet header, the IPv6 packet header does not carry IHL, identifier,
flag,
fragment offset, header checksum, option, and paddiing fields but carries the flow label field. This
facilitates IPv6 packet processing and improves processing efficiency. To support various options
without changing the existing packet format, the Extension Header information field is added to the
IPv6 packet header. This improves IPv6 flexibility. The following describes IPv6 extension
headers.
12.2.2 IPv6 Extension Header
An IPv4 packet header has an optional field (Options), which includes security, timestamp, and
record route options. The variable length of the Options field makes the IPv4 packet header length
range from
20 bytes to 60 bytes. When routers forward IPv4 packets with the Options field, many resources
need to be used. Therefore, these IPv4 packets are rarely used in practice.
To improve packet processing efficiency, IPv6 uses extension headers to replace the Options field in
the IPv4 header. Extension headers are placed between the IPv6 basic header and upper-layer PDU.
An IPv6 packet may carry zero, one, or more extension headers. The sender of a packet adds one or
more extension headers to the packet only when the sender requests other routers or the destination
router to perform special handling. Unlike IPv4, IPv6 has variable-length extension headers, which
are not limited to 40 bytes. This facilitates further extension. To improve extension header processing
efficiency and transport protocol performance, IPv6 requires that the extension header length be an
integer multiple of 8 bytes.
When multiple extension headers are used, the Next Header field of an extension header indicates the
type of the next header following this extension header. As shown in Figure 12-2-2, the Next Header
field in the IPv6 basic header indicates the type of the first extension header, and the Next Header
field in the first extension header indicates the type of the next extension header. If the next extension
header does not exist, the Next Header field indicates the upper-layer protocol type. Figure 12-2-2
shows the IPv6 extension header format.
Figure 12-2-2 IPv6 extension header format
An IPv6 extension header contains the following fields:
 Next Header: is 8 bits long. It is similar to the Next Header field in the IPv6 basic header,
indicating the type of the next extension header (if existing) or the upper-layer protocol
type.
 Extension Header Len: is 8 bits long, which indicates the extension header length excluding
the
Next Header field.
 Extension Head Data: is of variable length. It includes a series of options and the padding
field. RFC 2460 defines six IPv6 extension headers: Hop-by-Hop Options header, Destination
Options
header, Routing header, Fragment header, Authentication header, and Encapsulating Security Payload
header.
Table 12-2-1 IPv6 extension headers
Header Type Next Description

Header
Field
Value
Hop-by-Hop 0 This header carries information that must be examined by every node along
Options the delivery path of a packet. This header is used in the following
header applications:
 Jumbo payload (the payload length exceeds 65535 bytes)
 Prompting routers to check this option before the routers

forward packets.
 ource Reservation Protocol (RSVP)
Res
Destination 60 This header carries information that needs to be examined only by the
Table 12-2-1 IPv6 extension headers
Header Type Next Description

Header
Field
Value
Options destination node of a packet. Currently, this header is used in mobile IPv6.
header
Routing 43 Similar to the Loose Source and Record Route option in IPv4, this header is
header used by an IPv6 source node to specify the intermediate nodes that a packet
must pass through on the way to the destination of the packet.
Fragment 44 Like IPv4 packets, IPv6 packets to be forwarded cannot exceed the MTU.
header When the packet length exceeds the MTU, the packet needs to be
fragmented. In IPv6, the Fragment header is used by an IPv6 source node
to send a packet larger than the MTU.
Authentication 51 This header is used in IPSec to provide data origin authentication, data
header integrity check, and packet anti-replay. It also protects some fields in
the IPv6 basic header.
Encapsulating 50 Similar to the Authentication header, this header is used in IPSec to provide
Security data origin authentication, data integrity check, packet anti-replay, and
Payload IPv6 packet encryption.
header
12.2.3 Conventions on IPv6 extension headers
When more than one extension header is used in the same packet, the headers must be listed in
the following order:
 IPv6 basic header
 Hop-by-Hop Options header
 Destination Options header
 Routing header
 Fragment header
 Authentication header
 Encapsulating Security Payload header
 Destination Options header (for options to be processed only by the final destination of
the packet)
 Upper-layer header
Intermediate routers determine whether to process extension headers according to the Next Header
field value in the IPv6 basic header. Not all extension headers need to be examined and processed
by intermediate routers.
Each extension header can only occur once in an IPv6 packet, except for the Destination Options
header. The Destination Options header may occur at most twice (once before a Routing header
and once before the upper-layer header).
12.3 ICMPv6
The Internet Control Message Protocol version 6 (ICMPv6) is one of the basic IPv6 protocols.
In IPv4, ICMP reports IP packet forwarding information and errors to the source node. ICMP defines
certain messages such as Destination Unreachable, Packet Too Big, Time Exceeded, and Echo
Request or Echo Reply to facilitate fault diagnosis and information management. In addition to the
common functions provided by ICMPv4, ICMPv6 provides mechanisms such as Neighbor Discovery
(ID), stateless address configuration including duplicate address detection, and Path Maximum
Transmission Unit (PMTU) discovery.
The protocol number of ICMPv6, namely, the value of the Next Header field in an IPv6 packet is 58.
Figure 12-3-1 shows the ICMPv6 packet format.
Figure 12-3-1 Format of an ICMPv6 packet

Each field is described as follows:
 Type: specifies the message type. Values 0 to 127 indicate the error message type, and values
128 to 255 indicate the informational message type.
 Code: indicates a specific message type.
 Checksum: indicates the checksum of an ICMPv6 packet.

12.3.1 Classification of ICMPv6 Error Messages
Error messages report errors generated during IPv6 packet forwarding. ICMPv6 error messages
are classified into the following four types:
 Destination Unreachable message
During IPv6 packet forwarding, if an IPv6 node detects that the destination address of a packet
is unreachable, it sends an ICMPv6 Destination Unreachable message to the source node.
Information about the causes for the error message is carried in the message.
In an ICMPv6 Destination Unreachable message, the value of the Type field is 1. Based
on different causes, the value of the Code field can be:
 Code=0: No route to the destination device.
 Code=1: Communication with the destination device is administratively prohibited.
 Code=2: Not assigned.
 Code=3: Destination IP address is unreachable.
 Code=4: Destination port is unreachable.
 Packet Too Big message
During IPv6 packet forwarding, if an IPv6 node detects that the size of a packet exceeds the link
MTU of the outbound interface, it sends an ICMPv6 Packet Too Big message to the source
node. The link MTU of the outbound interface is carried in the message. PMTU discovery is
implemented based on Packet Too Big messages.
In a Packet Too Big message, the value of the Type field is 2 and the value of the Code field is 0.
 Time Exceeded message
During the transmission of IPv6 packets, when a router receives a packet with the hop limit being
0 or a router reduces the hop limit to 0, it sends an ICMPv6 Time Exceeded message to the
source node. During the processing of a packet to be fragmented and reassembled, an
ICMPv6
Time Exceeded message is also generated when the reassembly time is longer than the
specified period.
In a Time Exceeded message, the value of the Type field is 3. Based on different causes,
the value of the Code field can be:
 Code=0: Hop limit exceeded in packet transmission.
 Code=1: Fragment reassembly timeout.
 Parameter Problem message
When a destination node receives an IPv6 packet, it checks the validity of the packet. If an
error is detected, it sends an ICMPv6 Parameter Problem message to the source node.
In a Parameter Problem message, the value of the Type field is 4. Based on different causes,
the value of the Code field can be:
 Code=0: A field in the IPv6 basic header or extension header is incorrect.
 Code=1: The Next Header field in the IPv6 basic header or extension header cannot
be identified.
 Code=2: Unknown options exist in the extension header.
12.3.2 Classification of ICMPv6 Information Messages
ICMPv6 information messages provide the diagnosis and additional host functions such as Multicast
Listener Discovery (MLD) and ND. Common ICMPv6 information messages include Ping
messages that consist of Echo Request and Echo Reply messages.
 Echo Request messages: Echo Request messages are sent to destination nodes. After receiving
an Echo Request message, the destination node responds with an Echo Reply message. In an
Echo Request message, the value of the Type field is 128 and the value of the Code field is 0.
 Echo Reply messages: After receiving an Echo Request message, the destination node
responds with an Echo Reply message. In an Echo Reply message, the value of the Type field
is 129 and the value of the Code field is 0.
12.4 Neighbor Discovery
The Neighbor Discovery Protocol (NDP) is one important IPv6 basic protocol. It is an enhancement
of the Address Resolution Protocol (ARP) and Internet Control Management Protocol (ICMP) router
discovery. In addition to the function of ICMPv6 address resolution, NDP also provides the following
functions: neighbor tracking, duplicate address detection, router discovery, and redirection.
12.4.1 Address Resolution
In IPv4, a host needs to obtain the link-layer address of the destination host through the ARP
protocol for communication. Similar to IPv4, the IPv6 NDP protocol parses the IP address to obtain
the
link-layer address.
ARP packets are encapsulated in Ethernet packets. The Ethernet type value is 0x0806. ARP is
defined as a protocol that runs between Layer 2 and Layer 3. ND is implemented through ICMPv6
packets. The IPv6 type value is 0x86dd. The Next Header value in the IPv6 header is 58, indicating
that the packets are ICMPv6 packets. NDP packets are encapsulated in ICMPv6 packets. Therefore,
NDP is taken as a Layer 3 protocol. Layer 3 address resolution brings the following advantages:
 Layer 3 address resolution enables Layer 2 devices to use the same address resolution protocol.
 Layer 3 security mechanisms such as IPSec are used to prevent address resolution attacks.
 Request packets are sent in multicast mode, reducing performance requirements on Layer
2 networks.
Neighbor Solicitation (NS) packets and Neighbor Advertisement (NA) packets are used during
address resolution.
 In an NS packet, the value of the Type field is 135 and the value of the Code field is 0. An
NS
packet is similar to the ARP Request packet in IPv4.
 In an NA packet, the value of the Type field is 136 and the value of the Code field is 0. An
NA
packet is similar to the ARP Reply packet in IPv4.
Figure 12-4-1 shows the process of address resolution.
Figure 12-4-1 IPv6 address resolution

Host A needs to parse the link-layer address of Host B before sending packets to Host B. Therefore,
Host A sends an NS message on the network. In the NS message, the source IP address is the IPv6
address of Host A, and the destination IP address is the solicited-node multicast address of Host B.
The destination IP address to be parsed is the IPv6 address of Host B. This indicates that Host A
wants to know the link-layer address of Host B. The Options field in the NS message carries the link-
layer address of Host A.
After receiving the NS message, Host B replies with an NA Reply message. In the NA reply
message, the source address is the IPv6 address of Host B, and the destination address is the IPv6
address of
Host A (the NS message is sent to Host A in unicast mode using the link-layer address of Host A). The
Options field carries the link-layer address of Host B. This is the whole address resolution process.
12.4.2 Neighbor Tracking
Communication with neighboring devices will be interrupted because of various reasons such as
hardware fault and hot swapping of interface cards. If the destination address of a neighboring device
becomes invalid, communication cannot be restored. If the path fails, communication can be
restored. Therefore, nodes need to maintain the neighbor table to monitor the status of each
neighboring device. A neighbor state can transit from one to another.
Five neighbor states are defined in RFC2461: Incomplete, Reachable, Stale, Delay, and Probe.
Figure 12-4-2 shows the transition of neighbor states.
Figure 12-4-2 Neighbor state transition

The following example describes the neighbor state changes of node A during the first
communication with node B.
1. Node A sends an NS message and generates a cache entry. The neighbor state of node A is
Incomplete.
2. If node B replies with an NA message, the neighbor state of node A changes from Incomplete
to Reachable; otherwise, the neighbor state changes from Incomplete to Empty after a certain
period of time. Node A deletes this entry.
3. After the neighbor reachable time times out, the neighbor state changes from Reachable to
Stale, indicating that whether the neighbor is reachable is unknown.
4. If node A in the Reachable state receives a non-NA Request message from node B, and the
link-layer address of node B carried in the message is different from that learned by node A,
the neighbor state of node A immediately goes to Stale.
5. If node A in the Stale state sends data to node B, the state of node A changes from Stale to Delay.
Node A sends an NS Request message.
6. After a certain period of time, the neighbor state changes from Delay to Probe. During this
time, if node A receives an NA Reply message, the neighbor state of node A changes to
Reachable.
7. Node A in the Probe state sends unicast NS messages at the configured interval for several times.
If node A receives a Reply message, the neighbor state of node A changes from Probe to
Reachable; otherwise, the state changes to Empty. Node A deletes this entry.
12.4.3 Duplicate Address Detection
Before an IPv6 unicast address is assigned to an interface, duplicate address detection (DAD) is
performed to check whether the address is used by another node. DAD is required if IP addresses are
configured automatically. An IPv6 unicast address that is assigned to an interface but has not been
verified by DAD is called a tentative address. An interface cannot use the tentative address for
unicast communication but will join two multicast groups: ALL-nodes multicast group and Solicited-
node multicast group.
IPv6 DAD is similar to IPv4 free ARP. A node sends an NS message that requests the tentative
address as the destination address to the Solicited-node multicast group. If the node receives an NA
Reply message, the tentative address is being used by another node. This node will not use this
tentative address for communication.
Figure 12-4-3 shows the DAD working principle.
Figure 12-4-3 DAD example

An IPv6 address 2000::1 is assigned to Host A as a tentative IPv6 address. To check the validity of
2000::1, Host A sends an NS message to the Solicited-node multicast group to which 2000::1
belongs. The NS message contains the requested address 2000::1. Since 2000::1 is not specified, the
source address of the NS message is an unspecified address. After receiving the NS message, Host B
processes the message in the following ways:
 If 2000::1 is one tentative address of Host B, Host B will not use this address as an
interface address and not send the NA message.
 If 2000::1 is being used on Host B, Host B sends an NA message to the Solicited-node multicast
group to which 2000::1 belongs. The NA message carries IP address 2000::1. Host A receives
the message, finding that the tentative address is being used. Then, Host A abandons the address.
12.4.4 Router Discovery
Router discovery is used to locate a neighboring router and learn the address prefix and
configuration parameters for address autoconfiguration.
IPv6 supports stateless address autoconfiguration. Hosts obtain IPv6 prefixes and
automatically generate interface IDs. Router Discovery is the basics for IPv6 address
autoconfiguration and is implemented through the following two packets:
 Router Advertisement (RA) message: Each router periodically sends multicast RA messages that
carry network prefixes and identifiers on the network to declare its existence to Layer 2 hosts
and routers. An RA message has a value of 134 in the Type field.
 Router Solicitation (RS) message: After being connected to the network, a host
immediately sends an RS message to obtain network prefixes. Routers on the network
reply with an RA message. An RS message has a value of 133 in the Type field.
Figure 12-4-4 shows the router discovery function.
Figure 12-4-4 Router discovery example
12.4.5 Address Autoconfiguration
IPv4 uses DHCP to automatically configure IP addresses and default gateways. This simplifies
network management. The length of an IPv6 address is increased to 128 bits. Multiple terminal nodes
require
the function of automatic configuration. IPv6 allows both stateful and stateless address
autoconfiguration. Stateless autoconfiguration enables hosts to automatically generate link-local
addresses. Based on the prefixes in the RA message, hosts automatically configure global
unicast addresses and obtain other information.
The process of IPv6 stateless autoconfiguration is as follows:
1. A host automatically configures the link-local address based on the interface ID.
2. The host sends an NS message for duplicate address detection.
3. If address conflict occurs, the host stops address autoconfiguration. Then addresses need to
be configured manually.
4. If addresses do not conflict, the link-local address takes effect. The host is connected to
the network and can communicate with the local node.
5. The host sends an RS message or receives RA messages routers periodically send.
6. The host obtains the IPv6 address based on the prefixes carried in the RA message and
the configured interface ID specified by EUI-64.
12.4.6 Default Router Priority and Route Information Discovery

1210
If multiple routers exist on the Internet where hosts reside, hosts need to select forwarding routers
based on the destination address of the packet. In such a case, routers advertise default router
priorities

1210
and route information, which allows hosts to select the optimal forwarding router based on the
packet destination address.
The fields of default router priority and route information are defined in an RA message. These
two fields enable hosts to select the optimal forwarding router.
After receiving an RA message that contains route information, hosts update their routing tables.
When sending packets to other devices, hosts check the route in the routing table and select the
optimal route.
When receiving an RA message that carries default router priorities, hosts update their default
router lists. When sending packets to other devices, hosts check the router list to select the router
with the highest priority to forward packets. If the selected router does not work, hosts select the
router in descending order of priorities.
12.4.7 Redirection
To choose an optimal gateway router, the gateway router sends a Redirection message to notify the
sender that packets can be sent from another gateway router. A Redirection message is contained in
an ICMPv6 message. A Redirection message has the value of 137 in the Type field and carries a
better next hop address and destination address of packets that need to be redirected.
Figure 12-4-5 shows the process of redirecting packets.
Figure 12-4-5 Packet redirection example

Host A needs to communicate with Host B. By default, packets sent from Host A to Host B are sent
through RouterA. After receiving packets from Host A, RouterA finds that sending packets to
RouterB
is much better. RouterA sends a Redirection message to Host A to notify Host A that RouterB is a
better next hop address. The destination address of Host B is carried in the Redirection message. After
receiving the Redirection message, Host A adds a host route to the default routing table. Packets sent
to Host B will be directly sent to RouterB.
A router sends a Redirection message in the following situations:
 The destination address of the packet is not a multicast address.
 Packets are not forwarded to the router through the route.
 After route calculation, the outbound interface of the next hop is the interface that receives
the packets.
 The router finds that a better next hop IP address of the packet is on the same network segment
as the source IP address of the packet.
 After checking the source address of the packet, the router finds a neighboring device in
the neighbor entries that uses this address as the global unicast address or the link-local
unicast address.
12.5 Path MTU
In IPv4, a packet needs to be fragmented if it is oversized. When the transit device receives from a
source node a packet whose size exceeds the maximum transmission unit (MTU) of its outbound
interface, the transit device fragments the packet before forwarding it to the destination node. In
IPv6, however, packets are fragmented on the source node to reduce the pressure on the transit
device. When an interface on the transit device receives a packet whose size exceeds the MTU, the
transit device discards the packet and sends an ICMPv6 Packet Too Big message to the source node.
The ICMPv6
Packet Too Big message contains the MTU value of the outbound interface. The source node
fragments the packet based on the MTU and sends the packet again. This increases traffic overhead.
The Path MTU Discovery (PMTUD) protocol dynamically discovers the MTU value of each link on
the transmission path, reducing excessive traffic overhead.
The PMTU protocol is implemented through ICMPv6 Packet Too Big messages. A source node first
uses the MTU of its outbound interface as the PMTU and sends a probe packet. If a smaller PMTU
exists on the transmission path, the transit device sends a Packet Too Big message to the source node.
The Packet Too Big message contains the MTU value of the outbound interface on the transit device.
After receiving the message, the source node changes the PMTU value to the received MTU value
and sends packets based on the new MTU. This process is repeated until packets are sent to the
destination address. Then the source node obtains the PMTU of the destination address.
NOTE:
The switch supports the MTU setting on a VLANIF interface. Then packets sent by the protocol
stack are fragmented based on the configured MTU. However, the hardware chip does not support the
MTU setting, and the default MTU is 12K.
Figure 12-5-1 shows the process of PMTU
discovery.
Figure 12-5-1 PMTU discovery
Packets are transmitted through four links. The MTU values of the four links are 1500, 1500, 1400, and
1300 bytes respectively. Before sending a packet, the source node fragments the packet based on
PMTU 1500. When the packet is sent to the outbound interface with MTU 1400, the router returns a
Packet Too Big message that carries MTU 1400. After receiving the message, the source node
fragments the packet based on MTU 1400 and sends the fragmented packet again. When the packet is
sent to the outbound interface with MTU 1300, the router returns another Packet Too Big message
that carries MTU 1300. The source node receives the message and fragments the packet based on
MTU
1300. In this way, the source node sends the packet to the destination address and discovers the PMTU
of the transmission path.
NOTE:
IPv6 allows a minimum MTU of 1280 bytes. Therefore, the PMTU must be greater than 1280
bytes. PMTU of 1500 bytes is recommended.
12.6 Dual Protocol Stack
Dual protocol stack is a technology used for the transition from the IPv4 to IPv6 network. Nodes on a
dual stack network support both IPv4 and IPv6 protocol stacks. A source node and a destination node
use the same protocol stack. Network devices use protocol stacks to process and forward packets
based on the protocol type of packets. You can implement a dual protocol stack on a unique device or
a dual stack backbone network. On the dual stack backbone network, all devices must support both
IPv4 and IPv6 protocol stacks. Interfaces connecting to the dual stack network must be configured
with both IPv4 and IPv6 addresses. Figure 12-6-1 shows the structures of a single protocol stack and
a dual protocol stack.
Figure 12-6-1 Dual protocol stack
A dual protocol stack has the following advantages:
 Supported by multiple link protocols.
Multiple link protocols, such as Ethernet, support dual protocol stacks. In Figure 12-6-1, the
link protocol is Ethernet. In an Ethernet frame, if the value of the Protocol ID field is 0x0800,
the network layer receives IPv4 packets. If the value of the Protocol ID field is 0x86DD, the
network layer receives IPv6 packets.
 Supported by multiple applications.
Multiple applications, such as the DNS, FTP, and Telnet, support dual protocol stacks. The
upper layer applications, such as the DNS, can use TCP or UDP as the transport layer protocol.
However, they prefer the IPv6 protocol stack rather than the IPv4 protocol stack as the network
layer protocol.
Figure 12-6-2 shows a typical application of the dual IPv4/IPv6 protocol stack.
Figure 12-6-2 Networking diagram for applying a dual protocol stack
As shown in Figure 12-6-2, an application that supports dual protocol stack requests an IP address
corresponding to the domain name www.example.com from the DNS server. As shown in the figure, a
host sends a DNS request packet to the DNS server, requesting the IP address corresponding to the
domain name www.example.com. The DNS server responds with the requested IP address. The IP
address can be 10.1.1.1 or 3ffe:yyyy::1. If the host sends a class A query packet, it requests the IPv4
address from the DNS server. If the host sends a class AAAA query packet, it requests the IPv6
address from the DNS server.
Router in the figure supports the dual protocol stack. Router uses the IPv4 protocol stack to connect
the host to the network server with the IPv4 address 10.1.1.1. Router uses the IPv6 protocol stack to
connect the host to the network server with the IPv6 address 3ffe:yyyy::1.
12.7 IPv6 over IPv4 Tunnel
Tunnel is an encapsulation technology. Tunnel technology encapsulates packets of a network layer

protocol as packets of another one for transmission. A tunnel is a virtual point-to-point (P2P)
connection. It provides a path through which encapsulated packets are transmitted. Datagrams are
encapsulated at one end and then decapsulated at the other end of the tunnel. Tunnel technology
refers to the process that datagrams are encapsulated, transmitted, and decapsulated. It is of great
importance for the transition from IPv4 to IPv6.
Exhaustion of IPv4 addresses brings an urgent demand for transition to IPv6. As IPv6 is not
compatible with IPv4, you need to replace devices on the original IPv4 network. Replacing a large
number of devices on the IPv4 network costs a lot and causes service interruption of the current
network. Therefore, transition from IPv4 networks to IPv6 networks must be performed step by step.
During the early transition, a large number of IPv4 networks have been deployed, whereas IPv6
networks are isolated sites over the world. You can create tunnels on the IPv4 networks to connect to
IPv6 isolated sites. These tunnels are called IPv6 over IPv4 tunnels.
Figure 12-7-1 shows how to apply the IPv6 over IPv4 tunnel.
Figure 12-7-1 Networking diagram for applying the IPv6 over IPv4 tunnel
1. On the border router, the dual IPv4/IPv6 protocol stack is enabled, and an IPv6 over IPv4
tunnel is configured.
2. After the border router receives a packet from the IPv6 network, the router appends an
IPv4 header to the IPv6 packet to encapsulate the IPv6 packet as an IPv4 packet if the
destination address of the IPv6 packet is not the router and the outbound interface of the
next hop is the tunnel interface.
3. On the IPv4 network, the encapsulated packet is transmitted to the remote border router.
4. The remote border router decapsulates the packet, removes the IPv4 header, and sends
the decapsulated IPv6 packet to the IPv6 network.
A tunnel is established when its start and end points are determined. You must manually configure an
IPv4 address at the start point of an IPv6 over IPv4 tunnel. The IPv4 address at the end point of the
tunnel can be determined manually or automatically. Based on the mode in which the end point
IPv4 address is obtained, IPv6 over IPv4 tunnels are classified into manual tunnels and automatic
tunnels.
 Manual tunnel: If a tunnel is created manually, a border router cannot automatically obtain
an IPv4 address at the end point. You must manually configure an end point IPv4 address
before packets can be transmitted to the remote border router.
 Automatic tunnel: If a tunnel is created automatically, a border router can automatically obtain
an IPv4 address at the end point. The addresses of two interfaces on both ends of the tunnel are
IPv6 addresses with IPv4 addresses embedded. The border router extracts IPv4 addresses from
destination IPv6 addresses.
12.7.1 Manual Tunnel
Based on encapsulation modes of IPv6 packets, manual tunnels are classified into IPv6 over
IPv4 manual tunnels and IPv6 over IPv4 Generic Routing Encapsulation (GRE) tunnels.
12.7.2 IPv6 over IPv4 Manual Tunnel
The border router uses the received IPv6 packet as the payload and encapsulates the IPv6 packet as an
IPv4 packet. You must manually specify the source and destination addresses of a manual tunnel. A
manual tunnel is a P2P connection. It can be created between two border routers to connect IPv4
isolated IPv6 sites, or created between a border router and a host to enable the host to access an IPv6
network. Hosts and border routers on both ends of a manual tunnel must support the IPv4/IPv6 dual
protocol stack. Other devices only need to support a single protocol stack. If you cr eate multiple IPv6
over IPv4 manual tunnels between one border router and multiple hosts, the configuration workload is
heavy. Therefore, an IPv6 over IPv4 manual tunnel is commonly created between two border routers
to connect IPv6 networks.
Figure 12-7-2 shows the encapsulation format of an IPv6 over IPv4 packet.
Figure 12-7-2 Encapsulation format of an IPv6 over IPv4 packet

The forwarding mechanism of an IPv6 over IPv4 manual tunnel is as follows: After a border router
receives a packet from the IPv6 network, it searches the destination address of the IPv6 packet in the
routing and forwarding table. If the packet is forwarded from this virtual tunnel interface, the router
encapsulates the packet based on the source and destination IPv4 addresses configured on the
interface. The IPv6 packet is encapsulated as an IPv4 packet and processed by the IPv4 protocol stack.
The encapsulated packet is forwarded through the IPv4 network to the remote end of the tunnel. After
the border router on the remote end of the tunnel receives the encapsulated packet, it decapsulates the
packet and processes the packet using the IPv6 protocol stack.
12.7.3 IPv6 over IPv4 GRE Tunnel
An IPv6 over IPv4 GRE tunnel uses the standard GRE tunnel technology to provide P2P
connections. You must manually specify addresses for both ends of the tunnel. Any types of protocol
packets that
GRE supports can be encapsulated and transmitted through a GRE tunnel. The protocols may include
IPv4, IPv6, Open Systems Interconnection (OSI), and Multiprotocol Label Switching (MPLS).
Figure 12-7-3 shows the encapsulation and transmission process on an IPv6 over IPv4 GRE tunnel.
Figure 12-7-3 IPv6 over IPv4 GRE tunnel

The forwarding mechanism of an IPv6 over IPv4 GRE tunnel is the same as that of an IPv6 over
IPv4 manual tunnel. For details, see the Feature Description - VPN.
12.7.4 Automatic Tunnel
You only need to configure the start point of an automatic tunnel, and the device automatically
obtains the end point of the tunnel. The tunnel interface uses a special form of IPv6 address with an
IPv4 address embedded. The device obtains the IPv4 address from the destination IPv6 address and
uses the IPv4 address as the end point address of the tunnel.
Based on the encapsulation modes of IPv6 packets, automatic tunnels are classified into
IPv4-compatible IPv6 automatic tunnels, IPv6-to-IPv4 tunnels, and Intra-Site Automatic Tunnel
Addressing Protocol (ISATAP) tunnels.
IPv4-compatible IPv6 Automatic Tunnel
For an IPv4-compatible IPv6 automatic tunnel, the destination address contained in an IPv6 packet
is an IPv4-compatible IPv6 address. The first 96 bits of an IPv4-compatible IPv6 address are all 0s
and the last 32 bits are the IPv4 address. Figure 12-7-4 shows the format of an IPv4-compatible
IPv6 address.
Figure 12-7-4 IPv4-compatible IPv6 address
Figure 12-7-4 shows the forwarding mechanism of an IPv4-compatible IPv6 automatic tunnel.
Figure 12-7-5 Forwarding mechanism of an IPv4-compatible IPv6 automatic tunnel
After receiving an IPv6 packet, RouterA searches the routing table for the destination address
::2.1.1.1 and finds that the next hop address is a virtual tunnel interface address. RouterA then
encapsulates the IPv6 packet as an IPv4 address because the tunnel configured on RouterA is an
IPv4-compatible IPv6 automatic tunnel. The source address of the encapsulated IPv4 address is the
start point address of the tunnel 1.1.1.1, and the destination address is 2.1.1.1, which is the last 32 bits
of the IPv4-compatible IPv6 address. RouterA sends the packet through the tunnel interface and
forwards it on an IPv4 network to the destination address 2.1.1.1 (RouterB). RouterB receives the
packet, obtains the IPv6 packet, and processes the IPv6 packet using the IPv6 protocol stack. RouterB
returns packets to RouterA in the same way.
NOTE:
If the IPv4 address contained in an IPv4-compatible IPv6 address is a broadcast address,

multicast address, network broadcast address, subnet broadcast address of an outbound interface,
address of all
0s, or loopback address, the IPv6 packet will be discarded.
To deploy an IPv4-compatible IPv6 tunnel, each host must have a valid IP address, and hosts that
communicate with each other must support dual protocol stacks and IPv4-compatible IPv6
tunnels. Therefore, it is unsuitable for large-scale networks. Currently, the IPv4-compatible IPv6
tunnel has been replaced by the IPv6-to-IPv4 tunnel.
IPv6-to-IPv4 Tunnel
An IPv6-to-IPv4 tunnel also uses an IPv4 address that is embedded in an IPv6 address. Unlike
IPv4-compatible IPv6 tunnels, you can create IPv6-to-IPv4 tunnels between two routers, a router and
a host, and two hosts. An IPv6-to-IPv4 address uses the IPv4 address as the network ID. Figure 12-7-
6 shows the format of an IPv6-to-IPv4 address.
Figure 12-7-6 Format of an IPv6-to-IPv4 address
 FP: format prefix of a global unicast address. The value is 001.
 TLA ID: top level aggregation identifier. The value is 0x0002.
 SLA ID: site level aggregation identifier.

An IPv6-to-IPv4 address is expressed in the format of 2002::/16. An IPv6-to-IPv4 network is
expressed as 2002:IPv4 address::/48. An IPv6-to-IPv4 address has a 64-bit prefix composed of 48-bit
2002:IPv4 address and 16-bit SLA. 2002:IPv4 address in the format of 2002:a.b.c.d is determined by
the IPv4 address allocated to the router and the SLA is defined by the user. Figure 12-7-7 shows the
encapsulation and forwarding process of the IPv6-to-IPv4 tunnel. It is the same as that of the
IPv4-compatible IPv6 automatic tunnel, and therefore it is not mentioned here.
Figure 12-7-7 Example of an IPv6-to-IPv4 tunnel (1)

One IPv4 address can be used as the source address of only one IPv6-to-IPv4 tunnel. When a
border router is connected to multiple IPv6-to-IPv4 networks that use the same IPv4 address as the
source address of the tunnel, the IPv6-to-IPv4 networks share a tunnel and are identified by SLA
ID in the IPv6-to-IPv4 address. Figure 12-7-8 shows the case.
Figure 12-7-8 Example of an IPv6-to-IPv4 tunnel (2)

Backed by the advance of IPv6 networks, IPv6 hosts need to communicate with IPv4 hosts through
IPv6-to-IPv4 networks. It can be implemented by deploying IPv6-to-IPv4 relays. When the
destination address of an IPv6 packet forwarded through an IPv6-to-IPv4 tunnel is not an IPv6-to-
IPv4 address,
but the next hop address is an IPv6-to-IPv4 address, the next hop router is an IPv6-to-IPv4 relay.
The device obtains the destination IPv4 address from the next hop IPv6-to-IPv4 address. Figure 12-
7-9 shows an IPv6-to-IPv4 relay.
Figure 12-7-9 IPv6-to-IPv4 relay
When hosts on IPv6-to-IPv4 network 2 want to communicate with hosts on the IPv6 network,
configure the next hop address as the IPv6-to-IPv4 address of the IPv6-to-IPv4 relay on the border
router. The IPv6-to-IPv4 address matches the source address of the IPv6-to-IPv4 tunnel. Packets sent
from IPv6-to-IPv4 network 2 to the IPv6 network are sent to the IPv6-to-IPv4 relay router according
to the routing table. The IPv6-to-IPv4 relay router then forwards packets to the pure IPv6 network.
When hosts on the IPv6 network send packets to IPv6-to-IPv4 network 2, the IPv6-to-IPv4 relay
router appends IPv4 headers to the packets and forwards the packets to the destination addresses
(IPv6-to-IPv4 addresses).
ISATAP Tunnel
ISATAP is another automatic tunnel technology. The ISATAP tunnel uses a special format of IPv6
address with an IPv4 address embedded. Different from the IPv6-to-IPv4 address that uses the IPv4
address as the network prefix, the ISATAP address uses the IPv4 address as the interface ID.
Figure
12-7-10 shows the format of the interface ID of an ISATAP address.
Figure 12-7-10 Format of the interface ID of an ISATAP

address
The "u" bit in the IPv4 address that is globally unique is set to 1. Otherwise, the "u" bit is set to 0. "g"
is the individual/group bit. An ISATAP address contains an interface ID and it can be a global unicast
address, link-local address, ULA address, or multicast address. The device obtains the first 64 bits of
an ISATAP address by sending Request packets to the ISATAP router. Devices on both ends of the
ISATAP tunnel run the Neighbor Discovery (ND) protocol. The ISATAP tunnel considers the IPv4
network as a non-broadcast multiple access (NBMA) network.
ISATAP allows IPv6 networks to be deployed within existing IPv4 networks. The deployment is

1210
simple and networks can be easily expanded. Therefore, ISATAP is suitable for transition of local
sites. ISATAP supports local routing within IPv6 sites, global IPv6 routing domains, and automatic
IPv6 tunnels. ISATAP can be used together with NAT to allow the use of an IPv4 address that is not

1210
globally unique within the site. Typically, an ISATAP tunnel is used within the site, and does
not require a globally unique IPv4 address embedded.
Figure 12-7-11 shows a typical application of the ISATAP tunnel.
Figure 12-7-11 Typical application of the ISATAP

tunnel
As shown in Figure 12-7-11, Host B and Host C are located on an IPv4 network. They both
support dual protocol stacks and have private IPv4 addresses. Perform the following operations to
enable the ISATAP function on Host B and Host C:
1. Configure an ISATAP tunnel interface to generate an interface ID based on the IPv4 address.
2. Encapsulate a link-local IPv6 address based on the interface ID. When a host obtains
the link-local IPv6 address, it can access the IPv6 network on the local link.
3. The host automatically obtains a global unicast IPv6 address and ULA address.
4. The host obtains an IPv4 address from the next hop IPv6 address as the destination address,
and forwards packets through the tunnel interface to communicate with another IPv6 host.
When the destination host is located on the same site as the source host, the next hop address is
the
address of the source host. When the destination host is not located on the local site, the
next hop address is the address of the ISATAP router.
12.7.5 6PE
IPv6 Provider Edge (6PE) is a transition technology from the IPv4 to IPv6 network. With 6PE
routers, Independent Service Providers (ISPs) can provide access services for the IPv6 networks of
isolated users over the existing IPv4 backbone network. The 6PE router labels IPv6 routing
information and floods the information onto the ISP's IPv4 backbone network through Internal
Border Gateway Protocol (IBGP) sessions. The IPv6 packets are labeled before flowing into tunnels
on the backbone network. The tunnels can be GRE tunnels or MPLS LSPs. To allow IPv6 packet
exchange on
IPv4/MPLS networks through MPLS, LSPs can just update the PE routers. Therefore, using the 6PE
technology as an IPv6 transition mechanism is a cost-effective solution for ISPs.
Figure 12-7-12 shows the typical 6PE networking diagram.
Figure 12-7-12 Typical 6PE networking diagram
12.8 IPv4 over IPv6 Tunnel
During the later transition from IPv4 networks to IPv6 networks, a large number of IPv6 networks
are deployed. IPv4 networks, however, are isolated sites over the world. You can create tunnels on
the IPv6 networks to connect IPv4 isolated sites so that IPv4 isolated sites can access other IPv4
networks through the IPv6 public network.
Figure 12-8-1 shows how to apply the IPv4 over IPv6 tunnel.
Figure 12-8-1 Networking diagram for applying the IPv4 over IPv6 tunnel
1. On the border router, the IPv4/IPv6 dual protocol stack is enabled and the IPv4 over IPv6
tunnel is configured.
2. After the border router receives a packet not destined for the router from the IPv4 network,
the router appends an IPv6 header to the IPv4 packet and encapsulates the IPv4 packet as an
IPv6 packet.
3. On the IPv6 network, the encapsulated packet is transmitted to the remote border router .
4. The remote border router decapsulates the packet, removes the IPv6 header, and sends
the decapsulated IPv4 packet to the IPv4 network.
12.9 RIPng
12.9.1 RIPng Features
In addition to IPv4 networks, RIP is also applicable to IPv6 networks to provide accurate r oute
information for IPv6 packets. IETF has defined RIP next generation (RIPng) based on RIP for
IPv6 networks. RIPng is an important protocol for IPv6 networks.
12.9.2 Comparison between RIPng and RIP
RIPng made the following modifications to RIP:
 RIPng uses UDP port 521 to send and receive routing information.
 RIPng uses the destination addresses with 128-bit prefixes (mask length).
 RIPng uses 128-bit IPv6 addresses as next hop addresses.
 RIPng uses the local link address FE80::/10 as the source address to send RIPng Update packets.
 RIPng periodically sends routing information in multicast mode and uses FF02::9 as
multicast address.
 A RIPng packet consists of a header and multiple route table entries (RTEs). In a RIPng
packet, the maximum number of RTEs depends on the MTU on the interface.
12.10 OSPFv3
12.10.1 Principle of OSPFv3
Running on IPv6, OSPFv3 (defined in RFC 2740) is an independent routing protocol whose
functions are enhanced on the basis of OSPFv2.
 OSPFv3 and OSPFv2 are the same in respect of the working principles of the Hello
message, state machine, link-state database (LSDB), flooding, and route calculation.
 OSPFv3 divides an Autonomous System (AS) into one or more logical areas and
advertises routes through LSAs.
 OSPFv3 achieves unity of routing information by exchanging OSPFv3 packets between
routers within an OSPFv3 area.
 OSPFv3 packets are encapsulated into IPv6 packets, which can be transmitted in unicast
or multicast mode.
Formats of OSPFv3 Packets
Table 12-10-1 Formats of OSPFv3 packets
Packet Type Description
Hello message Hello messages are sent regularly to discover and maintain
OSPFv3 neighbor relationships.
Database Description (DD) packet A DD packet contains the summary of the local LSDB. It
is exchanged between two OSPFv3 routers to update the
LSDBs.
Link State Request (LSR) packet LSR packets are sent to the neighbor to request the required
LSAs.
An OSPFv3 router sends LSR packets to its neighbor only
after they exchange DD packets.
Link State Update (LSU) packet The LSU packet is used to transmit required LSAs to
the neighbor.
Link State Acknowledgment (LSAck) The LSAck packet is used to acknowledge the received LSA
packet packets.
LSA Type
LSA Type Description
Router-LSA (Type1) Generated by a router for each area to which an OSPFv3

interface belongs, the router LSA describes the status and costs
of links of the router and is advertised in the area where the
OSPFv3 interface belongs.
Network-LSA (Type2) Generated by a designated router (DR), the network LSA

describes the link status and is broadcast in the area that the DR
belongs to.
Inter-Area-Prefix-LSA (Type3) Generated on the area border router (ABR), an inter-area

prefix LSA describes the route of a certain network segment
within the local area and is used to inform other areas of the route.
Inter-Area-Router-LSA (Type4) Generated on the ABR, an inter-area router LSA describes

the route to the autonomous system boundary router (ASBR) and
is advertised to all related areas except the area that the
ASBR belongs to.
LSA Type Description
AS-external-LSA (Type5) Generated on the ASBR, the AS-external LSA describes the
route to a destination outside the AS and is advertised to all areas
except the stub area and NSSA area.
NSSA-LSA (Type7) Describes routes to a destination outside the AS. It is generated

by an ASBR and advertised in NSSAs only.
Link-LSA (Type8) Each router generates a link LSA for each link. A link
LSA describes the link-local address and IPv6 address prefix
associated with the link and the link option set in the network
LSA. It is transmitted only on the link.
Intra-Area-Prefix-LSA (Type9) Each router or DR generates one or more intra-area prefix

LSAs and transmits it in the local area.
 An LSA generated on a router describes the IPv6
address prefix associated with the router LSA.
 An LSA generated on a DR describes the IPv6 address

prefix associated with the network LSA.
Router Type
Figure 12-10-1 Router type
Table 4-10-3 Router types and descriptions
Router Type Description

Table 4-10-3 Router types and descriptions
Router Type
Internal router
Area border router (ABR)
Backbone router
AS boundary router (ASBR)
OSPFv3 Route Type
Inter-area routes and intra-area routes describe the network structure of an AS. External routes
describe how to select a route to the destination outside an AS. OSPFv3 classifies the imported AS
external routes into Type 1 routes and Type 2 routes.
Table 12-10-4 lists route types in a descending order of priority.
Table 12-10-4 Types of OSPFv3 routes
Route Type
Intra Area
Inter Area
Type1 external routes
Type2 external routes

Table 12-10-4 Types of OSPFv3 routes
Route Type
Area Type
Table 12-10-5 Types of OSPFv3 areas
Area Type
Totally stub area
Stub area
NSSA
Network Types Supported by OSPFv3
OSPFv3 classifies networks into the following types according to link layer protocols.
Table 12-10-6 Types of OSPFv3 networks
Network Type Description
Broadcast If the link layer protocol is Ethernet or FDDI, OSPFv3 defaults

the network type to broadcast.
In this type of networks, the following situations occur:
 Hello messages, LSU packets, and LSAck packets are transmitted
in multicast mode (FF02::5 is the reserved IPv6 multicast address
of the OSPFv3 router; FF02::6 is the reserved IPv6 multicast
address of the OSPFv3 DR or BDR).
 DD packets and LSR packets are transmitted in unicast mode.
Non-broadcast Multiple If the link layer protocol is frame relay, ATM, or X.25, OSPFv3
Access (NBMA) defaults the network type to NBMA.
In this type of networks, protocol packets such as Hello messages, DD
Table 12-10-6 Types of OSPFv3 networks
Network Type
Point-to-Multipoint
(P2MP)
Point-to-point (P2P)
Stub Area
A stub area is a special area where the ABRs do not flood the received external routes. In stub
areas, the size of the routing table of the routers and the routing information in transmission are
reduced.
Configuring a stub area is optional. Not all areas can be configured as stub areas. Usually, a stub area
is a non-backbone area with only one ABR and is located at the AS boundary.
To ensure the reachability of a destination outside the AS, the ABR in the stub area generates a
default route and advertises it to the non-ABR routers in the stub area.
Note the following when configuring a stub area:
 The backbone area cannot be configured as a stub area.
 If an area needs to be configured as a stub area, all the routers in this area must be
configured with the stub command.
 An ASBR cannot exist in a stub area. That is, external routes are not flooded in the stub area.
 A virtual link cannot pass through the stub area.
OSPFv3 Route Summarization
Routing information can be decreased after route aggregation so that the size of routing tables
is reduced, which improves the performance of routers.
The procedure for OSPFv3 route aggregation is as follows:
 Route summarization on an ABR
An ABR can summarize routes with the same prefix into one route and advertise the
summarized route in other areas.
When sending routing information to other areas, an ABR generates Type 3 LSAs based on
IPv6 prefixes. If consecutive IPv6 prefixes exist in an area and route summarization is enabled
on the ABR of the area, the IPv6 prefixes can be summarized into one prefix. If there are
multiple LSAs that have the same prefix, the ABR summarizes these LSAs and advertises only
one summarized LSA. The ABR does not advertise any specific LSAs.
 Route summarization on an ASBR
An ASBR can summarize imported routes with the same prefix into one route and then
advertise the summarized route to other areas.
After being enabled with route summarization, an ASBR summarizes imported Type 5 LSAs
within the summarized address range. After route summarization, the ASBR does not generate
a separate Type 5 LSA for each specific prefix within the configured range. Instead, the ASBR
generates a Type 5 LSA for only the summarized prefix. In an NSSA, an ASBR summarizes
multiple imported Type 7 LSAs within the summarized address range into one Type 7 LSA.
OSPFv3 Virtual Link
A virtual link refers to a logical channel established between two ABRs through a non-backbone area.
 A virtual link must be set up on both ends of the link; otherwise, it does not take effect.
 The transmit area refers to the area that provides an internal route of a non-backbone area
for both the ends of the virtual link.
In actual applications, the physical connectivity between non-backbone areas and the backbone
area cannot be ensured owing to various limitations. To solve this problem, you can configure
OSPFv3 virtual links.
The virtual link is similar to a point-to-point connection between two ABRs. Similar to
physical interfaces, the interfaces on the virtual link can be configured with parameters such as
the hello interval.
Figure 12-10-2 OSPFv3 virtual link

As shown in Figure 12-10-2, OSPFv3 packets transmitted between two ABRs are only forwarded
by the OSPFv3 devices that reside between the two ABRs. The OSPFv3 devices detect that they are
not the destinations of the packets, so they forward the packets as common IP packets.
12.10.2 Comparison between OSPFv3 and OSPFv2
OSPFv3 and OSPFv2 are the same in the following aspects:
 Network type and interface type
 Interface state machine and neighbor state machine
 LSDB
 Flooding mechanism
 Five types of packets, including Hello, DD, LSR, LSU, and LSAck packets
 Route calculation
OSPFv3 and OSPFv2 are different in the following aspects:
 OSPFv3 is based on links rather than network segments.
OSPFv3 runs on IPv6, which is based on links rather than network segments.
Therefore, you need not to configure OSPFv3 on the interfaces in the same network segment.
It is only required that the interfaces enabled with OSPFv3 are on the same link. In addition,
the interfaces can set up OSPFv3 sessions without IPv6 global addresses.
 OSPFv3 does not depend on IP addresses.
This is to separate topology calculation from IP addresses. That is, OSPFv3 can calculate the
OSPFv3 topology without knowing the IPv6 global address, which only applies to virtual
link interfaces for packet forwarding.
 OSPFv3 packets and LSA format change.
 OSPFv3 packets do not contain IP addresses.
 OSPFv3 router LSAs and network LSAs do not contain IP addresses, which are
advertised by link LSAs and intra-area prefix LSAs.
 In OSPFv3, Router IDs, area IDs, and LSA link state IDs no longer indicate IP
addresses, but the IPv4 address format is still reserved.
 Neighbors are identified by Router IDs instead of IP addresses in broadcast, NBMA, or

P2MP networks.
 Information about the flooding scope is added in LSAs of OSPFv3.
Information about the flooding scope is added in the LSA Type field of LSAs of OSPFv3.
Thus, OSPFv3 routers can process LSAs of unidentified types, which makes the processing
more flexible.
1210
 OSPFv3 can store or flood unidentified packets, whereas OSPFv2 just discards
unidentified packets.
 OSPFv3 floods packets in an OSPF area or on a link. It sets the U flag bit of packets (the
flooding area is based on the link local) so that unidentified packets are stored or
forwarded to the stub area.
For example, RouterA and RouterB can identify LSAs of a certain type. They are connected
through RouterC, which, however, cannot identify this type of LSAs. When RouterA floods
an LSA of this type, RouterC can still flood the received LSA to RouterB although it does not
identify this LSA. RouterB then processes the LSA.
If OSPFv2 is run, RouterC discards the unidentified LSA so that the LSA cannot reach RouterB.
 OSPFv3 supports multi-process on a link.
Only one OSPF process can be configured on a physical interface.
In OSPFv3, one physical interface can be configured with multiple processes that are identified
by different instance IDs. That is, multiple OSPFv3 instances can run on one physical link.
They establish neighbor relationships with the other end of the link and transmit packets to the
other end without interfering with each other.
Thus, the resources of a link can be shared among OSPFv3 instances that simulate multiple
OSPFv3 routers, which improves the utilization of limited router resources.
 OSPFv3 uses IPv6 link-local addresses.
IPv6 implements neighbor discovery and automatic configuration based on link-local

addresses. Routers running IPv6 do not forward IPv6 packets whose destination address is a
link-local address. Those packets can only be exchanged on the same link. The unicast link-
local address starts from FE80/10.
As a routing protocol running on IPv6, OSPFv3 also uses link-local addresses to maintain
neighbor relationships and update LSDBs. Except virtual link interfaces, all OSPFv3
interfaces use link-local addresses as the source address and that of the next hop to transmit
OSPFv3 packets.
The advantages are as follows:
 The OSPFv3 can calculate the topology without knowing the global IPv6 addresses so
that topology calculation is not based on IP addresses.
 The packets flooded on a link are not transmitted to other links, which
prevents unnecessary flooding and saves bandwidth.
 OSPFv3 packets do not contain authentication fields.
OSPFv3 directly adopts IPv6 authentication and security measures. Thus, OSPFv3 does not
need to perform authentication. It only focuses on the processing of packets.
 OSPFv3 supports two new LSAs.

 Link LSA: A router floods a link LSA on the link where it resides to advertise its link-
local address and the configured global IPv6 address.
 Intra-area prefix LSA: A router advertises an intra-area prefix LSA in the local OSPF
area to inform the other routers in the area or the network, which can be a broadcast
network or a NBMA network, of its IPv6 global address.
 OSPFv3 identifies neighbors based on router IDs only.
On broadcast, NBMA, and P2MP networks, OSPFv2 identifies neighbors based on

IPv4 addresses of interfaces.
OSPFv3 identifies neighbors based on router IDs only. Thus, even if global IPv6 addresses are
not configured or they are configured in different network segments, OSPFv3 can still
establish and maintain neighbor relationships so that topology calculation is not based on IP
addresses.
12.11 MP-BGP
12.11.1 MP-BGP
Traditional BGP-4 manages only IPv4 routing information. Inter-AS transmission of other network
layer protocol packets (such as IPv6 and multicast packets) is limited. To support multiple network
layer protocols, Multiprotocol BGP (MP-BGP) is designed in RFC 4760 as an extension to BGP-4.
MP-BGP uses extended attributes and address families to support IPv6, multicast, and VPN,
without changing the existing BGP packet forwarding and routing mechanism.
MP-BGP is called BGP4+ on IPv6 unicast networks or called multicast BGP (MBGP) on IPv4
multicast networks. MP-BGP establishes separate topologies for IPv6 unicast networks and IPv4
multicast networks, and stores IPv6 unicast and IPv4 multicast routing information in different
routing tables. This ensures that routing information of IPv6 unicast networks and IPv4 multicast
networks is separated from each other, and allows routes of different networks to be maintained
using different routing policies.
Extended Attributes
In BGP, an Update message carries three IPv4-related attributes: NLRI, Next_Hop, and
Aggregator. To support multiple network layer protocols, BGP requires NLRI and Next_Hop
attributes to carry
information about network layer protocols. Therefore, MP-BGP uses the following new
optional non-transitive attributes:
 MP_REACH_NLRI: indicates the multiprotocol reachable NLRI. It is used to

advertise reachable routes and next hop information.
 MP_UNREACH_NLRI: indicates the multiprotocol unreachable NLRI. It is used to
withdraw unreachable routes.
Address Families
MP-BGP uses address families to differentiate network layer protocols. For the values of
address families, see RFC 3232 (Assigned Numbers). Currently, devices support the following address
family views:
 BGP-IPv4 unicast address family view
 BGP-IPv4 multicast address family view
 BGP-VPN instance IPv4 address family view
 BGP-VPNv4 address family view
 BGP-VPN instance IPv6 address family view
 BGP-VPNv6 address family view
12.12 Examples for Configuring of IPv6
12.12.1 Example for Configuring Basic IPv6 Functions
As shown in Figure 12-12-1, RouterA and RouterB are connected using GE1/0/0. RouterA and
RouterB need to establish a neighbor relationship, and RouterB can obtain an IPv6 address using
the neighbor discovery function.
Figure 12-12-1 Networking diagram for configuring basic IPv6 functions
1. Enable the IPv6 forwarding function on RouterA and configure an IPv6 address for RouterA
so that RouterA can forward IPv6 packets.
2. Configure RouterA to send RA packets and allow GE1/0/0 of RouterB to

automatically configure an IPv6 address based on the route prefix carried in the
received RA packets.
Procedure
# Configure an IPv6 address for GE1/0/0 of RouterA.
[RouterA] ipv6
[RouterA-GigabitEthernet1/0/0] ipv6 enable
[RouterA-GigabitEthernet1/0/0] ipv6 address 3001::1/64
# Configure the neighbor discovery function on RouterA.

[RouterA-GigabitEthernet1/0/0] undo ipv6 nd ra halt
2. # Configure RouterB.
# Configure GE1/0/0 of RouterB to automatically generate an IPv6 address through

stateless autoconfiguration.
[RouterB] ipv6
[RouterB-GigabitEthernet1/0/0] ipv6 enable
[RouterB-GigabitEthernet1/0/0] ipv6 address auto link-local
[RouterB-GigabitEthernet1/0/0] ipv6 address auto global
If the preceding configurations are successful, you can view the configured global unicast
addresses. The interface status and the IPv6 protocol are Up. You can also check the
neighbor of the interfaces.
# Check interface information on RouterA.
<RouterA> display ipv6 interface gigabitethernet 1/0/0

IPv6 protocol current state : UP
IPv6 is enabled, link-local address is FE80::A19:A6FF:FECD:A897
Global unicast address(es):
3000::1, subnet is 3000::/64
Joined group address(es):
FF02::1:2
FF02::1:FF00:1
FF02::2
FF02::1
FF02::1:FFCD:A897
MTU is 1500 bytes
ND DAD is enabled, number of DAD attempts: 1
ND reachable time is 30000 milliseconds
ND retransmit interval is 1000 milliseconds
ND advertised reachable time is 0 milliseconds
ND advertised retransmit interval is 0 milliseconds
ND router advertisement max interval 600 seconds, min interval 200 seconds
ND router advertisements live for 1800 seconds
ND router advertisements hop-limit 64
ND default router preference medium
Hosts use stateless autoconfig for addresses
# Check interface information on RouterB.
<RouterB> display ipv6 interface gigabitethernet 1/0/0

IPv6 is enabled, link-local address is FE80::2D6F:0:7AF3:1
3001::15B:E0EA:3524:E791
subnet is 3001::/64 [SLAAC 2012-07-19 17:30:55 2592000S]
FF02::1:FF00:2
FF02::1:FFF3:1
FF02::2
FF02::1
MTU is 1500 bytes
ND DAD is enabled, number of DAD attempts: 1
# Check neighbor information on GE1/0/0 of RouterA.
<RouterA> display ipv6 neighbors gigabitethernet 1/0/0

---------------------------------------------------------
IPv6 Address : 3001::15B:E0EA:3524:E791
Link-layer : 00e0-fc89-fe6e State : STALE
Interface : GigabitEthernet1/0/0 Age :7
VLAN :- CEVLAN: -
VPN name : Is Router : TRUE
Secure FLAG : UN-SECURE
---------------------------------------------------------
Total: 1 Dynamic: 1 Static: 0
Configuration File
#
sysname RouterA
#
ipv6
#
ipv6 enable
ipv6 address 3001::1/64
undo ipv6 nd ra halt
#
return
#
sysname RouterB
#
ipv6
#
ipv6 enable
ipv6 address auto link-local
ipv6 address auto global
#
return
12.12.2 Example for Configuring a Manual IPv6 over IPv4 Tunnel
As shown in Figure 12-12-2, two IPv6 networks connect to RouterB on an IPv4 backbone
network through RouterA and RouterC respectively. Hosts on the two IPv6 networks are required
to communicate through the IPv4 backbone network.
Figure 12-12-2 Networking diagram for configuring a manual IPv6 over IPv4 tunnel
1. Configure IP addresses for physical interfaces so that devices can communicate on the
IPv4 backbone network.
2. Configure IPv6 addresses, source interfaces, and destination addresses for tunnel interfaces
so that devices can communicate with hosts on the two IPv6 networks.
3. Set the tunnel protocol to IPv6-IPv4 so that hosts on the two IPv6 networks can
communicate through the IPv4 backbone network.
Procedure
# Configure an IP address for an interface.
<Huawei>system-view
[RouterA] ipv6
# Set the tunnel protocol to IPv6-IPv4.
[RouterA] interface tunnel 0/0/1

[RouterA-Tunnel0/0/1] tunnel-protocol ipv6-ipv4
# Configure an IPv6 address, a source interface, and a destination address for the
tunnel interface.
[RouterA-Tunnel0/0/1] ipv6 enable

[RouterA-Tunnel0/0/1] ipv6 address 3001::1/64
[RouterA-Tunnel0/0/1] source gigabitethernet 1/0/0
[RouterA-Tunnel0/0/1] destination 192.168.51.2
[RouterA-Tunnel0/0/1] quit
# Configure a static route.
# Configure IP addresses for interfaces.
[RouterC] ipv6
[RouterC-GigabitEthernet1/0/0] ip address 192.168.51.2 255.255.255.0
# Set the tunnel protocol to IPv6-IPv4.
[RouterC] interface tunnel 0/0/1

[RouterC-Tunnel0/0/1] tunnel-protocol ipv6-ipv4
# Configure an IPv6 address, a source interface, and a destination address for the tunnel
interface.
[RouterC-Tunnel0/0/1] ipv6 enable

[RouterC-Tunnel0/0/1] ipv6 address 3001::2/64
[RouterC-Tunnel0/0/1] source gigabitethernet 1/0/0
[RouterC-Tunnel0/0/1] destination 192.168.50.2
[RouterC-Tunnel0/0/1] quit
# Ping the IPv4 address of GE1/0/0 on RouterA from RouterC. RouterC can receive a
Reply packet from RouterA.

ms
--- 192.168.50.2 ping statistics ---
0.00% packet loss
# Ping the IPv6 address of Tunnel0/0/1 on RouterA from RouterC. RouterC can receive a
[RouterC] ping ipv6 3001::1

PING 3001::1 : 56 data bytes, press CTRL_C to break
Reply from 3001::1
bytes=56 Sequence=1 hop limit=64 time = 28 ms
Reply from 3001::1
Reply from 3001::1
Reply from 3001::1
Reply from 3001::1
--- 3001::1 ping statistics ---
0.00% packet loss
Configuration Files
#
sysname RouterA
#
ipv6
#
ip address 192.168.50.2 255.255.255.0
#
interface Tunnel0/0/1
ipv6 enable
tunnel-protocol ipv6-ipv4
source GigabitEthernet1/0/0
destination 192.168.51.2
#
ip route-static 192.168.51.0 255.255.255.0 192.168.50.1
#
return
#
sysname RouterB
#
ip address 192.168.50.1 255.255.255.0
#
ip address 192.168.51.1 255.255.255.0
#
return

1210
#
sysname RouterC
#
ipv6
#
ip address 192.168.51.2 255.255.255.0
#
ipv6 enable
#
ip route-static 192.168.50.0 255.255.255.0 192.168.51.1
#
return
12.12.3 Example for Configuring an IPv6 over IPv4 GRE Tunnel
As shown in Figure 12-12-3, two IPv6 networks connect to RouterB on an IPv4 backbone network
respectively through RouterA and RouterC. An IPv6 over IPv4 GRE tunnel needs to be set up
between RouterA and RouterC so that hosts on the two IPv6 networks can communicate.
Figure 12-12-3 Networking diagram for configuring an IPv6 over IPv4 GRE tunnel

2. Configure IPv6 addresses, source interfaces, and destination addresses for tunnel interfaces
so that devices can communicate with hosts on the two IPv6 networks.
3. Set the tunnel protocol to GRE so that hosts on the two IPv6 networks can
communicate through the IPv4 backbone network.
Procedure
[RouterA] ipv6
[RouterA] interface pos 1/0/0
[RouterA-Pos1/0/0] ip address 192.168.50.2 255.255.255.0
[RouterA-Pos1/0/0] quit
# Set the tunnel protocol to GRE.

[RouterA-Tunnel0/0/1] tunnel-protocol gre
tunnel interface.

[RouterA-Tunnel0/0/1] ipv6 address 3001::1 64
[RouterA-Tunnel0/0/1] source pos 1/0/0
[RouterA-Tunnel0/0/1] destination 192.168.51.2
# Configure IP addresses for interfaces.

1210
[RouterB] interface pos 1/0/0
[RouterB-Pos1/0/0] ip address 192.168.50.1 255.255.255.0
[RouterB-Pos1/0/0] quit
[RouterC] ipv6
[RouterC] interface pos 1/0/0
[RouterC-Pos1/0/0] ip address 192.168.51.2 255.255.255.0
[RouterC-Pos1/0/0] quit
# Set the tunnel protocol to GRE.
[RouterC] interface tunnel 0/0/1

[RouterC-Tunnel0/0/1] tunnel-protocol gre
tunnel interface.
[RouterC-Tunnel0/0/1] ipv6 enable

[RouterC-Tunnel0/0/1] ipv6 address 3001::2 64
[RouterC-Tunnel0/0/1] source pos 1/0/0
[RouterC-Tunnel0/0/1] destination 192.168.50.2
[RouterC-Tunnel0/0/1] quit
# Ping the IPv4 address of Pos 1/0/0 on RouterA from RouterC. RouterC can receive a

ms Reply from 192.168.50.2: bytes=56 Sequence=4 ttl=255 time=3
ms Reply from 192.168.50.2: bytes=56 Sequence=5 ttl=255 time=24
ms
--- 192.168.50.2 ping statistics ---
0.00% packet loss
# Ping the IPv6 address of Tunnel1/0/0 on RouterA from RouterC. RouterC can receive a
[RouterC] ping ipv6 3001::1

Reply from 3001::1
Reply from 3001::1
Reply from 3001::1
Reply from 3001::1
Reply from 3001::1
0.00% packet loss
Configuration Files
#
sysname RouterA
#
ipv6
#
interface Pos1/0/0
link-protocol ppp
ip address 192.168.50.2 255.255.255.0
#
ipv6 enable
tunnel-protocol gre
source pos1/0/0
#
ip route-static 192.168.51.0 255.255.255.0 192.168.50.1
#
return
#
sysname RouterB
#
interface Pos1/0/0
link-protocol ppp
ip address 192.168.50.1 255.255.255.0
#
interface Pos2/0/0
link-protocol ppp
ip address 192.168.51.1 255.255.255.0
#
return
#
sysname RouterC
#
ipv6
#
interface Pos1/0/0
link-protocol ppp
ip address 192.168.51.2 255.255.255.0
#
ipv6 enable
tunnel-protocol gre
source pos1/0/0
#
ip route-static 192.168.50.0 255.255.255.0 192.168.51.1
#
return
12.12.4 Example for Configuring an Automatic IPv6 over IPv4 Tunnel
As shown in Figure 12-12-3 Networking diagram for configuring an IPv6 over IPv4 GRE tunnel,
two IPv6 networks connect to an IPv4 backbone network through RouterA and RouterB respectively.
An automatic IPv6 over IPv4 tunnel needs to be set up between RouterA and RouterB so that devices
on the two IPv6 networks can communicate.
Figure 12-12-4 Networking diagram for configuring an automatic IPv6 over IPv4 tunnel
2. Configure IPv6 addresses and source interfaces for tunnel interfaces so that devices
can communicate with hosts on the two IPv6 networks.
3. Set the tunnel protocol to automatic so that hosts on the two IPv6 networks can
communicate through the IPv4 network.
Procedure
# Configure an IPv4/IPv6 dual stack.
[RouterA] ipv6
# Configure an automatic IPv6 over IPv4 tunnel.

[RouterA-Tunnel0/0/1] tunnel-protocol ipv6-ipv4 auto-tunnel
[RouterA-Tunnel0/0/1] ipv6 address ::2.1.1.1/96
[RouterB] ipv6
# Configure an automatic IPv6 over IPv4 tunnel.
[RouterB] interface tunnel 0/0/1

[RouterB-Tunnel0/0/1] tunnel-protocol ipv6-ipv4 auto-tunnel
[RouterB-Tunnel0/0/1] ipv6 enable
[RouterB-Tunnel0/0/1] ipv6 address ::2.1.1.2/96
[RouterB-Tunnel0/0/1] source pos 1/0/0
[RouterB-Tunnel0/0/1] quit
# View the IPv6 status of tunnel0/0/1 on RouterA. You can see that the tunnel status is Up.
[RouterA] display ipv6 interface tunnel 0/0/1

Tunnel0/0/1 current state : UP
IPv6 is enabled, link-local address is FE80::201:101
::2.1.1.1, subnet is ::/96
FF02::1:FF01:101
FF02::2
FF02::1
MTU is 1500 bytes
# Ping the IPv6 address of the peer device that is compatible with the IPv4 address from
RouterA. The IPv6 address is pinged successfully.
[RouterA] ping ipv6 ::2.1.1.2

PING ::2.1.1.2 : 56 data bytes, press CTRL_C to break
Reply from ::2.1.1.2
--- ::2.1.1.2 ping statistics ---
0.00% packet loss
Configuration Files
#
sysname RouterA
#
ipv6
#
interface pos1/0/0
link-protocol ppp
ip address 2.1.1.1 255.0.0.0
#
interface Tunnel 0/0/1
ipv6 enable
ipv6 address ::2.1.1.1/96
tunnel-protocol ipv6-ipv4 auto-tunnel
source pos1/0/0
#
return
#
sysname RouterB
#
ipv6
#
interface pos1/0/0
link-protocol ppp
ip address 2.1.1.2 255.0.0.0
#
ipv6 enable
ipv6 address ::2.1.1.2/96
tunnel-protocol ipv6-ipv4 auto-tunnel
source pos1/0/0
#
return
12.12.5 Example for Configuring 6to4 Relay
As shown in Figure 12-12-5, the IPv6 network-side interface of 6to4 router RouterA connects to a
6to4 network. RouterB is a 6to4 relay agent and connects to the IPv6 Internet (2001::/64). RouterA and
RouterB are connected through an IPv4 backbone network. A 6to4 tunnel needs to be set up between
RouterA and RouterB so that hosts on the 6to4 network and the IPv6 network can communicate.
Figure 12-12-5 Networking diagram for configuring 6to4 relay.
1. Configure an IPv4/IPv6 dual stack on routers so that they can access the IPv4 network and the
IPv6 network.
2. Configure a 6to4 tunnel on routers to connect IPv6 networks through the IPv4
backbone network.
3. Configure a static route between RouterA and RouterB so that they can communicate
through the IPv4 backbone network.
Procedure
[RouterA] ipv6
[RouterA-GigabitEthernet2/0/0] ipv6 address 2002:0201:0101:1::1/64

1210
# Configure a 6to4 tunnel.

[RouterA-Tunnel0/0/1] tunnel-protocol ipv6-ipv4 6to4
[RouterA-Tunnel0/0/1] ipv6 address 2002:0201:0101::1/64
# Configure a static route to 2002::/16.
[RouterA] ipv6 route-static 2002:: 16 tunnel 0/0/1
# Configure a default route to the IPv6 network.
[RouterA] ipv6 route-static :: 0 2002:0201:0102::1
[RouterB] ipv6
[RouterB-GigabitEthernet2/0/0] ipv6 enable
[RouterB-GigabitEthernet2/0/0] ipv6 address 2001::1/64
# Configure a 6to4 tunnel.
[RouterB] interface tunnel 0/0/1

[RouterB-Tunnel0/0/1] tunnel-protocol ipv6-ipv4 6to4
[RouterB-Tunnel0/0/1] ipv6 enable
[RouterB-Tunnel0/0/1] ipv6 address 2002:0201:0102::1/64
[RouterB-Tunnel0/0/1] source pos 1/0/0
[RouterB-Tunnel0/0/1] quit
# Configure a static route to 2002::/16.
[RouterB] ipv6 route-static 2002:: 16 tunnel 0/0/1
# Ping the IPv6 address of GE2/0/0 on RouterB from RouterA. The IPv6 address is
pinged successfully.
[RouterA] ping ipv6 2001::1
Reply from 2001::1
Reply from 2001::1
Reply from 2001::1
Reply from 2001::1
Reply from 2001::1
0.00% packet loss
Configuration Files
#
sysname RouterA
#
ipv6
#
interface pos1/0/0
link-protocol ppp
ip address 2.1.1.1 255.0.0.0
#
ipv6 enable
ipv6 address 2002:201:101:1::1/64
#
ipv6 enable
ipv6 address 2002:201:101::1/64
tunnel-protocol ipv6-ipv4 6to4
source pos1/0/0
#
ipv6 route-static :: 0 2002:201:102::1
#
ipv6 route-static 2002:: 16 Tunnel 0/0/1
#
return
#
sysname RouterB
#
ipv6
#
interface Pos1/0/0
link-protocol ppp
ip address 2.1.1.2 255.0.0.0
#
ipv6 enable
#
ipv6 enable
ipv6 address 2002:201:102::1/64
tunnel-protocol ipv6-ipv4 6to4
source Pos1/0/0
#
ipv6 route-static 2002:: 16 Tunnel 0/0/1
#
return
12.12.6 Example for Configuring an ISATAP Tunnel
As shown in Figure 12-12-6, an IPv6 host on the IPv4 network runs Windows XP. The IPv6 host
needs to be connected to the IPv6 network through a border router. The IPv6 host and border router
support ISATAP. An ISATAP tunnel needs to be set up between the IPv6 host and the border
router.
Figure 12-12-6 Networking diagram for configuring an ISATAP tunnel
1. Configure an IPv4/IPv6 dual stack on the router so that the router can communicate
with devices on the IPv4 network and the IPv6 network.
2. Configure an ISATAP tunnel on the router so that IPv6 hosts on the IPv4 network
can communicate with IPv6 hosts on the IPv6 network.
3. Configure a static route.
Procedure
1. Configure the ISATAP router.
# Enable the IPv4/IPv6 dual stack and configure an IP address for each interface.
[Huawei] sysname Router
[Router] ipv6
[Router] interface gigabitethernet 1/0/0
[Router-GigabitEthernet1/0/0] ipv6 enable
[Router-GigabitEthernet1/0/0] ipv6 address 3001::1/64
[Router-GigabitEthernet1/0/0] quit
[Router-GigabitEthernet2/0/0] ip address 2.1.1.1 255.0.0.0
# Configure an ISATAP tunnel.
[Router] interface tunnel 0/0/2

[Router-Tunnel0/0/2] tunnel-protocol ipv6-ipv4 isatap
[Router-Tunnel0/0/2] ipv6 enable
[Router-Tunnel0/0/2] ipv6 address 2001::/64 eui-64
[Router-Tunnel0/0/2] source gigabitethernet 2/0/0
[Router-Tunnel0/0/2] undo ipv6 nd ra halt
[Router-Tunnel0/0/2] quit
2. Configure the ISATAP host.
The ISATAP host is relevant to the operating system.
 When the ISATAP host runs Windows XP operating system, perform the
following operations:
# Configure the IPv6 protocol.
C:\> ipv6 install
# Run the following command to add a static route to the border router. The number of
the pseudo interface on the host is 2. You can run the ipv6 if command to check the
interface
corresponding to Automatic Tunneling Pseudo-Interface.
C:\> ipv6 rlu 2 2.1.1.1
# Check ISATAP interface information on the host.
C:\>ipv6 if
Interface 2: Automatic Tunneling Pseudo-Interface
Guid {48FCE3FC-EC30-E50E-F1A7-71172AEEE3AE}
does not use Neighbor Discovery
uses Router Discovery
routing preference 1
EUI-64 embedded IPv4 address: 2.1.1.2
router link-layer address: 2.1.1.1
preferred global 2001::5efe:2.1.1.2, life 29d23h59m50s/6d23h59m50s (pu
blic)
preferred link-local fe80::5efe:2.1.1.2, life infinite
link MTU 1280 (true link MTU 65515)
current hop limit 64
reachable time 16500ms (base 30000ms)
retransmission interval 1000ms
DAD transmits 0
default site prefix length 48
The preceding information shows that the host obtains the prefix 2001::/64 and generates
the address 2001::5efe:2.1.1.2, router discovery has been enabled, and the ISATAP
tunnel has been set up successfully.
 When the ISATAP host runs Windows 7 operating system, perform the
following operations:
# Run the following command to add a static route to the border router. IPv6 has
been installed by default in Windows 7 operating system.
C:\> netsh interface ipv6 isatap set router 2.1.1.1
C:\> netsh interface ipv6 isatap set router 2.1.1.1 enabled
# Check ISATAP interface information on the host.
C:\>ipconfig/all
Tunnel adapter Automatic Tunneling Pseudo-Interface
isatap.{895CA398-8C4F-4332-9558-642844FCB01B}:
Connection-specific DNS Suffix . . . . . . . :
Description . . . . . . . . . . . . . . . : Microsoft ISATAP Adapter #5
Physical Address. . . . . . . . . . . . . : 00-00-00-00-00-00-00-E0
Dhcp Enabled . . . . . . . . . . . :No
Automatic configuration. . . . . . . . . . : YES
IP Address . . . . . . . . . . . . : 2001::200:5efe:2.1.1.2
IP Address. . . . . . . . : fe80::200:5efe:2.1.1.2%30
Default Gateway. . . . . . . . . . . . . : fe80::5efe:2.1.1.1%30
DNS Servers . . . . . . . . . . . : fec0:0:0:ffff::1%1
fec0:0:0:ffff::2%1
fec0:0:0:ffff::3%1
NetBIOS over Tcpip . . . . . . . : Disabled
The preceding information shows that the host obtains the prefix 2001::/64 and
generates the address 2001::200:5efe:2.1.1.2, and the ISATAP tunnel has been set up
successfully.
3. Configure the IPv6 host.
# Configure a static route to the border router tunnel on the IPv6 host so that PCs on
two different networks can communicate through the ISATAP tunnel.
C:\> ipv6 rtu 2001::/64 6/3001::1
# View the IPv6 status of Tunnel0/0/2 on the ISATAP router. You can see that the tunnel
status is Up.
[Router] display ipv6 interface Tunnel 0/0/2

IPv6 is enabled, link-local address is FE80::5EFE:201:101
2001::5EFE:201:101, subnet is 2001::/64
FF02::1:FF01:101
FF02::2
FF02::1
MTU is 1500 bytes
ND advertised reachable time is 0 milliseconds
ND advertised retransmit interval is 0 milliseconds
ND router advertisement max interval 600 seconds, min interval 200 seconds
ND router advertisements live for 1800 seconds
# Ping the global unicast address of the tunnel interface on the ISATAP host running Windows
XP operating system from the ISATAP router.
[Router] ping ipv6 2001::5efe:2.1.1.2

PING 2001::5efe:2.1.1.2 : 56 data bytes, press CTRL_C to break
Reply from 2001::5EFE:201:102
--- 2001::5efe:2.1.1.2 ping statistics ---
0.00% packet loss
# Ping the global unicast address of the ISATAP router from the ISATAP host running
Windows XP operating system.
C:\> ping6 2001::5efe:2.1.1.1

Pinging 2001::5efe:2.1.1.1
from 2001::5efe:2.1.1.2 with 32 bytes of data:
Reply from 2001::5efe:2.1.1.1: bytes=32 time=1ms
Ping statistics for 2001::5efe:2.1.1.1:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 1ms, Maximum = 1ms, Average = 1ms
# Ping the IPv6 host from the ISATAP host running Windows XP operating system. They
can ping each other.
C:\> ping6 3001::2

Pinging 3001::2 with 32 bytes of data:
Reply from 3001::2: time<1ms
Ping statistics for 3001::2:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
Configuration Files
Configuration file of the ISATAP router
#
sysname ISATAP
#
ipv6
#
ipv6 enable
#
ip address 2.1.1.1 255.0.0.0
#
ipv6 enable
ipv6 address 2001::/64 eui-64
undo ipv6 nd ra halt
tunnel-protocol ipv6-ipv4 isatap
#
return
12.12.7 Example for Configuring an IPv4 over IPv6 Tunnel
As shown in Figure 12-12-7, two IPv4 networks are connected to an IPv6 network through RT1
and RT5. Border devices RT2 and RT4 on the IPv6 network support the IPv4/IPv6 dual stack. An
IPv4 over IPv6 tunnel needs to be set up between RT2 and RT4 so that physically isolated IPv4
networks can communicate.
Figure 12-12-7 Networking diagram for configuring an IPv4 over IPv6 tunnel
1. Configure an IPv4 over IPv6 tunnel on the border devices at both ends of the IPv6 network.
2. Use a dynamic routing protocol to configure a route for the tunnel interface to forward packets.
Configuration Procedures
1. Configure an IPv6 address for the physical interface and enable IPv6 capability for IS-IS on the
IPv6 network to implement IP connectivity of the IPv6 network.
# Configure RT2.
[Huawei] sysname RT2
[RT2] ipv6
[RT2] interface pos 2/0/0
[RT2-Pos2/0/0] ipv6 enable
[RT2-Pos2/0/0] ipv6 address 2001::1 64
[RT2-Pos2/0/0] quit
[RT2] isis 1
[RT2-isis-1] network-entity 10.0000.0000.0001.00
[RT2-isis-1] ipv6 enable topology standard
[RT2-isis-1] quit
[RT2-Pos2/0/0] isis ipv6 enable 1
[RT2-Pos2/0/0] quit
# Configure RT3.
[RT3] ipv6
[RT3-Pos1/0/0] quit [RT3]
interface pos 2/0/0 [RT3-
Pos2/0/0] ipv6 enable
[RT3-Pos2/0/0] quit
[RT3] isis 1
[RT3-isis-1] quit
[RT3-Pos1/0/0] quit
[RT3-Pos2/0/0] quit
# Configure RT4.
[RT4] ipv6

1210
[RT4-Pos1/0/0] quit
[RT4] isis 1
[RT4-isis-1] quit
[RT4-Pos1/0/0] quit
2. Configure an IPv4 address for the physical interface and configure OSPF on the IPv4
network to implement IP connectivity of the IPv4 network.
# Configure RT1.
[RT1-Pos1/0/0] ip address 10.1.2.2 30
[RT1-Pos1/0/0] quit
[RT1] ospf 1
[RT1-ospf-1] area 0
[RT1-ospf-1-area-0.0.0.0] network 10.1.2.0 0.0.0.3
# Configure RT2.
<RT2> system-view
[RT2-Pos1/0/0] ip address 10.1.2.1 30
[RT2-Pos1/0/0] quit
[RT2] ospf 1
[RT2-ospf-1] area 0
# Configure RT4.
<RT4> system-view
[RT4-Pos1/0/0] ip address 10.1.3.1 30
[RT4-Pos1/0/0] quit
[RT4] ospf 1
[RT4-ospf-1] area 0
# Configure RT5.
[RT5-Pos1/0/0] ip address 10.1.3.2 30
[RT5-Pos1/0/0] quit
[RT5] ospf 1
[RT5-ospf-1] area 0
3. Configure a tunnel interface.
# Create a tunnel interface, and configure an IPv4 address, a source IPv6 address (or
source interface), and a destination IPv6 address for the tunnel interface.
# Configure RT2.
<RT2> system-view
[RT2] interface tunnel 0/0/2
[RT2-Tunnel0/0/2] tunnel-protocol ipv4-ipv6
[RT2-Tunnel0/0/2] ip address 10.1.1.1 30
[RT2-Tunnel0/0/2] source pos 2/0/0
[ET2-Tunnel0/0/2] destination 2002::2
# Configure RT4.
<RT4> system-view
[RT4] interface tunnel 0/0/1
[RT4-Tunnel0/0/1] tunnel-protocol ipv4-ipv6
[RT4-Tunnel0/0/1] ip address 10.1.1.2 30
[RT4-Tunnel0/0/1] source pos 1/0/0
[ET4-Tunnel0/0/1] destination 2001::1
4. Use a dynamic routing protocol to configure a route for the tunnel interface to forward packets.
# Configure RT2.
<RT2> system-view
[RT2] ospf 1
[RT2-ospf-1] area 0
[RT2-ospf-1-area-0.0.0.0] quit
[RT2-ospf-1] quit
# Configure RT4.
<RT4> system-view
[RT4] ospf 1
[RT4-ospf-1] area 0
After the preceding configurations are complete, check the tunnel interface status on RT2 and
RT4. You can see that the protocol status of the tunnel interface is Up.
[RT2] display interface tunnel 0/0/2

Last line protocol up time: 2010-06-22, 19:33:19
Description : HUAWEI, AR Series, Tunnel0/0/2 Interface
Encapsulation is TUNNEL6, loopback not set
Tunnel protocol/transport (IPv6 or IPV4) over IPv6
Tunnel Source 2001::1 (Pos2/0/0)
Tunnel Destination 2002::2
Tunnel Encapsulation limit 4
Tunnel Traffic class not set
Tunnel Flow label not set
Tunnel Hop limit 64
300 seconds input rate 0 bits/sec, 0 packets/sec
300 seconds output rate 0 bits/sec, 0 packets/sec
102 seconds input rate 0 bits/sec, 0 packets/sec
102 seconds output rate 0 bits/sec, 0 packets/sec
0 packets input, 0 bytes
0 input error
0 packets output, 0 bytes
0 output error
Input bandwidth utilization : --
Output bandwidth utilization : --
Check the IPv4 routing table on RT2 and RT4. You can see that the outbound interface of
the route to the remote IPv4 network is a tunnel interface.
[RT2] display ip routing-table

Destination/Mask
1.1.1.1/32
10.1.1.0/30
10.1.1.1/32
10.1.2.0/30
10.1.2.1/32
10.1.2.2/32
10.1.3.0/24
127.0.0.0/8
127.0.0.1/32
RT1 and RT5 can ping each other.
Configuration Files
 Configuration file of RT1
#
sysname RT1
#
interface Pos1/0/0
link-protocol ppp
ip address 10.1.2.2 255.255.255.252
#
ospf 1
area 0.0.0.0
network 10.1.2.0 0.0.0.3
#
return
#
sysname RT2
#
ipv6
#
isis 1
network-entity 10.0000.0000.0001.00
#
ipv6 enable topology standard
#
#
interface Pos1/0/0
link-protocol ppp
ip address 10.1.2.1 255.255.255.252
#
interface Pos2/0/0
link-protocol ppp
ipv6 enable
isis ipv6 enable 1
#
ip address 10.1.1.1 255.255.255.252
source Pos2/0/0
destination 2002::2
#
ospf 1
area 0.0.0.0
network 10.1.2.0 0.0.0.3
network 10.1.1.0 0.0.0.3
#
return
#
sysname RT3
#
ipv6
#
isis 1
network-entity 10.0000.0000.0002.00
#
#
#
interface Pos1/0/0
link-protocol ppp
ivp6 enable
isis ipv6 enable 1
#
interface Pos2/0/0
link-protocol ppp
ipv6 enable
isis ipv6 enable 1
#
return
#
sysname RT4
#
ipv6
#
isis 1
network-entity 10.0000.0000.0003.00
#
#
#
interface Pos1/0/0
link-protocol ppp
ipv6 enable
isis ipv6 enable 1
#
interface Pos2/0/0
link-protocol ppp
ip address 10.1.3.1 255.255.255.252
#
ip address 10.1.1.2 255.255.255.252
source Pos1/0/0
destination 2001::1
#
ospf 1
area 0.0.0.0
network 10.1.1.0 0.0.0.3
network 10.1.3.0 0.0.0.3
#
return
#
sysname RT1
#
interface Pos1/0/0
link-protocol ppp
ip address 10.1.3.2 255.255.255.252
#
ospf 1
area 0.0.0.0
network 10.1.3.0 0.0.0.3
#
return
12.12.8 Example for Configuring Basic RIPng Functions
As shown in Figure 12-12-8, three routers (RouterA, RouterB, and RouterC) reside on a small
IPv6 network. RouterA, RouterB, and RouterC must communicate with each other.
Figure 12-12-8 Networking diagram of configuring basic RIPng functions
1. Assign IP addresses to interfaces to ensure network reachability.
2. Enable RIPng on routers to implement network interconnection.
Procedure
1. Assign an IPv6 address to each interface.
[RouterA] ipv6
[RouterA-GigabitEthernet1/0/0] ipv6 address 2::1 64
[RouterA-GigabitEthernet2/0/0] ipv6 address 1::1 64
2. Configure basic RIPng functions.
[RouterA] ripng 1
[RouterA-ripng-1] quit
[RouterA-GigabitEthernet2/0/0] ripng 1 enable
[RouterA-GigabitEthernet1/0/0] ripng 1 enable
[RouterB] ripng 1
[RouterB-ripng-1] quit
[RouterB-GigabitEthernet1/0/0] ripng 1 enable
[RouterB-GigabitEthernet2/0/0] ripng 1 enable
[RouterC] ripng 1
[RouterC-ripng-1] quit
[RouterC-GigabitEthernet1/0/0] ripng 1 enable
# Check the RIPng routing table of RouterA.
[RouterA] display ripng 1 route

Route Flags: R - RIPng
A - Aging, G - Garbage-collect
----------------------------------------------------------------
Peer FE80::200:5EFF:FE04:B602 on GigabitEthernet1/0/0
Dest 3::/64,
via FE80::200:5EFF:FE04:B602, cost 1, tag 0, RA, 10 Sec
# Check the RIPng routing table of RouterB.
[RouterB] display ripng 1 route

----------------------------------------------------------------
Peer FE80::A19:A6FF:FECE:7D4C on GigabitEthernet1/0/0
Dest 1::/64,
via FE80::A19:A6FF:FECE:7D4C, cost 1, tag 0, RA, 25 Sec
# Check the RIPng routing table of RouterC.
[RouterC] display ripng 1 route

----------------------------------------------------------------
Peer FE80::2E0:FCFF:FE01:9 on GigabitEthernet1/0/0
Dest 1::/64,
via FE80::2E0:FCFF:FE01:9, cost 2, tag 0, RA, 4 Sec
Dest 2::/64,
via FE80::2E0:FCFF:FE01:9, cost 1, tag 0, RA, 4 Sec
Configuration Files
#
sysname RouterA
#
ipv6
#
ipv6 enable
ripng 1 enable
#
ipv6 enable
ripng 1 enable
#
ripng 1
#
return
#
sysname RouterB
#
ipv6
#
ipv6 enable
ripng 1 enable
#
ipv6 enable
ripng 1 enable
#
ripng 1
#
return
#
sysname RouterC
#
ipv6
#
ipv6 enable
ripng 1 enable
#
ripng 1

1210
#
return
12.12.9 Example for Configuring OSPFv3 Areas
As shown in Figure 12-12-9, all routers run OSPFv3. The entire autonomous system is divided
into three areas. RouterB and RouterC serve as ABRs to forward the inter-area routes.
It is required that Area 2 be configured to decrease the LSAs advertised to this area, without
affecting route reachability.
Figure 12-12-9 Networking diagram of configuring OSPFv3 areas
1. Enable basic OSPFv3 function on each router.
2. Configure Area 2 as a stub area to decrease the LSAs advertised to this area, without
affecting route reachability.
Procedure
1. Assign an IPv6 address for each interface.
The details are not mentioned here.

2. Configure basic OSPFv3 functions.
[RouterA] ipv6
[RouterA] ospfv3
[RouterA-ospfv3-1] router-id 1.1.1.1
[RouterA-ospfv3-1] quit
[RouterA-GigabitEthernet1/0/0] ospfv3 1 area 1
[RouterA-GigabitEthernet2/0/0] ospfv3 1 area 1
[RouterB] ipv6
[RouterB] ospfv3
[RouterB-ospfv3-1] router-id 2.2.2.2
[RouterB-ospfv3-1] quit
[RouterB-GigabitEthernet1/0/0] ospfv3 1 area 0
[RouterB-GigabitEthernet2/0/0] ospfv3 1 area 1
[RouterC] ipv6
[RouterC] ospfv3
[RouterC-ospfv3-1] router-id 3.3.3.3
[RouterC-ospfv3-1] quit
[RouterC-GigabitEthernet1/0/0] ospfv3 1 area 0
[RouterC-GigabitEthernet2/0/0] ospfv3 1 area 2
[RouterD] ipv6
[RouterD] ospfv3
[RouterD-ospfv3-1] router-id 4.4.4.4
[RouterD-ospfv3-1] quit
[RouterD-GigabitEthernet1/0/0] ospfv3 1 area 2
# Display the OSPFv3 neighbors of RouterB.
[RouterB] display ospfv3 peer

OSPFv3 Process (1)
OSPFv3 Area (0.0.0.1)
Neighbor ID
1.1.1.1
Neighbor ID
3.3.3.3
# Display OSPFv3 neighbors of RouterC.
[RouterC] display ospfv3 peer

OSPFv3 Process (1)
Neighbor ID Pri State Dead Time Interface Instance ID
2.2.2.2 1 Full/ - 00:00:37 GE1/0/0 0
Neighbor ID Pri State Dead Time Interface Instance ID
4.4.4.4 1 Full/ - 00:00:33 GE2/0/0 0
# Display the OSPFv3 routing table of RouterD.
[RouterD] display ospfv3 routing

Codes : E2 - Type 2 External, E1 - Type 1 External, IA - Inter-
Area, N - NSSA, U - Uninstalled
OSPFv3 Process (1)
OSPFv3 Process (1)
Destination Metric
Next-hop
IA 1000::/64 2
via FE80::1572:0:5EF4:1, GigabitEthernet1/0/0
IA 1001::/64 3
1002::/64 1
directly-connected, GigabitEthernet1/0/0
IA 2000::/64 4
3. Configure stub areas.
# Configure the stub area of RouterD.
[RouterD] ospfv3
[RouterD-ospfv3-1] area 2
[RouterD-ospfv3-1-area-0.0.0.2] stub
[RouterD-ospfv3-1-area-0.0.0.2] quit
# Configure the stub area of RouterC, and set the cost of the default route advertised to the
stub area to 10.
[RouterC] ospfv3
[RouterC-ospfv3-1] area 2
[RouterC-ospfv3-1-area-0.0.0.2] stub
[RouterC-ospfv3-1-area-0.0.0.2] default-cost 10
[RouterC-ospfv3-1-area-0.0.0.2] quit
# Display the OSPFv3 routing table of RouterD, and you can view a new default route in the
routing table. Its cost is the sum of the cost of the directly connected routes and the
configured cost.

OSPFv3 Process (1)
OSPFv3 Process (1)
Destination Metric
Next-hop
IA ::/0 11
IA 1000::/64 2
IA 1001::/64 3
1002::/64 1
IA 2000::/64 4
4. Configure totally stub areas.
# Configure RouterC and configure Area 2 as a totally stub area.
[RouterC] ospfv3
[RouterC-ospfv3-1] area 2
[RouterC-ospfv3-1-area-0.0.0.2] stub no-summary
[RouterC-ospfv3-1-area-0.0.0.2] quit
# Display the OSPFv3 routing table of RouterD, and you can view that the entries in the
routing table decrease; other non-directly connected routes are suppressed; only the default
route is reserved.

OSPFv3 Process (1)
OSPFv3 Process (1)
Destination Metric
Next-hop
IA ::/0 11
1002::/64 1
Configuration Files
#
sysname RouterA
#
ipv6
#
ipv6 enable
ospfv3 1 area 0.0.0.1
#
ipv6 enable
#
ospfv3 1
router-id 1.1.1.1
#
return
#
sysname RouterB
#
ipv6
#
ipv6 enable
#
ipv6 enable
#
ospfv3 1
router-id 2.2.2.2
#
return
#
sysname RouterC
#
ipv6
#
ipv6 enable
#
ipv6 enable
#
ospfv3 1
router-id 3.3.3.3
area 0.0.0.2
stub no-summary
default-cost 10
#
return
#
sysname RouterD
#
ipv6
#
ipv6 enable
#
ospfv3 1
router-id 4.4.4.4
area 0.0.0.2
stub
#
return
12.12.10 Example for Configuring Basic BGP4+ Functions
As shown in Figure 12-12-10, there are two ASs: 65008 and 65009. RouterA belongs to AS
65008; RouterB, and RouterC belong to AS65009. Routing Protocol is required to exchange the
routing information between the two ASs.
Figure 12-12-10 Networking diagram of configuring BGP4+ route reflection
1. Configure the IBGP connection between RouterB and RouterC.
2. Configure the EBGP connection between RouterA and RouterB.
Procedure
1. Assign an IPv6 address for each interface. The details are not mentioned here.
2. Configure the IBGP.
[RouterB] ipv6
[RouterB] bgp 65009
[RouterB-bgp] peer 9:1::2 as-number 65009
[RouterB-bgp-af-ipv6] peer 9:1::2 enable
[RouterB-bgp-af-ipv6] network 9:1:: 64
[RouterC] ipv6
[RouterC] bgp 65009
[RouterC-bgp] peer 9:1::1 as-number 65009
[RouterC-bgp-af-ipv6] peer 9:1::1 enable
[RouterC-bgp-af-ipv6] network 9:1:: 64
3. Configure the EBGP.
[RouterA] ipv6
[RouterA] bgp 65008
[RouterA-bgp] peer 10::1 as-number 65009
[RouterA-bgp-af-ipv6] peer 10::1 enable
[RouterA-bgp-af-ipv6] network 10:: 64
[RouterA-bgp-af-ipv6] network 8:: 64
[RouterB] bgp 65009

[RouterB-bgp] peer 10::2 as-number 65008
[RouterB-bgp-af-ipv6] peer 10::2 enable
[RouterB-bgp-af-ipv6] network 10:: 64
# Check the connection status of BGP4+ peers.
[RouterB] display bgp ipv6 peer

Peer V AS MsgRcvd MsgSent OutQ Up/Down

State PrefRcv
9:1::2 4 65009 10 14 0 00:07:10 Established

1
10::2 4 65008 6 6 0 00:02:17 Established
2
The routing table shows that RouterB has set up BGP4+ connections with other routers.
# Display the routing table of RouterA.
[RouterA] display bgp ipv6 routing-table


*> Network : 8:: PrefixLen : 64
NextHop : :: LocPrf :
MED :0 PrefVal :0
Label :
Path/Ogn : i
*> Network : 9:1:: PrefixLen : 64
NextHop : 10::1 LocPrf :
MED :0 PrefVal :0
Label :
Path/Ogn : 65009 i
*> Network : 10:: PrefixLen : 64
NextHop : :: LocPrf :
MED :0 PrefVal :0
Label :
Path/Ogn : i
NextHop : 10::1 LocPrf :

MED :0 PrefVal :0
Label :
Path/Ogn : 65009 i
The routing table shows that RouterA has learned the route from AS 65009. AS 65008 and AS
65009 can exchange their routing information.
Configuration Files
#
sysname RouterA
#
ipv6
#
ipv6 enable
#
ipv6 enable
#
bgp 65008
router-id 1.1.1.1
peer 10::1 as-number 65009
#
ipv4-family unicast
#

1210
ipv6-family unicast
network 8:: 64
network 10:: 64
peer 10::1 enable
#
return
#
sysname RouterB
#
ipv6
#
ipv6 enable
ipv6 address 9:1::1/64
#
ipv6 enable
#
bgp 65009
router-id 2.2.2.2
peer 9:1::2 as-number 65009
peer 10::2 as-number 65008
#
ipv4-family unicast
#
ipv6-family unicast
network 9:1:: 64
network 10:: 64
peer 9:1::2 enable
peer 10::2 enable
#
return

#
sysname RouterC
#
ipv6
#
ipv6 enable
ipv6 address 9:1::2/64
#
bgp 65009
router-id 3.3.3.3
peer 9:1::1 as-number 65009
#
ipv4-family unicast
#
ipv6-family unicast
network 9:1:: 64
peer 9:1::1 enable
#
return
Chapter 13 MPLS VPN
13.1 MPLS Basics
13.1.1 Basic MPLS Architecture
MPLS Network Structure
On a typical MPLS network shown in Figure 13-1-1, all routers function as label switching routers
(LSRs) that exchange labels and forward packets. These LSRs construct an MPLS domain.LSRs
that reside at the edge of the MPLS domain and connect to other networks are called label edge
routers (LERs). LSRs within an MPLS domain are core LSRs.
Figure 13-1-1 MPLS network structure
On IP networks, packets are forwarded based on IP addresses; in MPLS domains, packets
are forwarded based on labels.
When receiving IP packets from the connected IP network, an LER tags labels on the packets and
then forwards the labeled packets to a core LSR. When receiving labeled packets from the core LSR,
the LER removes the labels and forwards the packets to the IP network. LSRs only forward packets
based on labels.
LSPs are determined using different protocols and are established before packet forwarding. IP
packets are transmitted through the specified label switched paths (LSPs) on an MPLS network.
As shown in Figure 13-1-2, an LSP is a unidirectional path whose direction is the same as the data
flow. The nodes on an LSP include the ingress, transit, and egress nodes. The number of transit
nodes on an LSP varies (none, one, or multiple), but only one ingress node and one egress node
exist on the LSP.
To an LSR, all LSRs that send MPLS packets to the LSR are the upstream LSRs, and all next-hop
LSRs that receive MPLS packets from the LSR are the downstream LSRs. As shown in Figure 13-1-
2, for the data flow that are destined for 192.168.1.0/24, the ingress node is the upstream to the transit
node, and the transit node is the downstream to the ingress node. Similarly, the transit node is the
upstream to the egress node, and the egress node is the downstream to the transit node.
Figure 13-1-2 Upstream and downstream LSRs
MPLS Architecture
The MPLS architecture consists of a control plane and a forwarding plane.
Figure 13-1-3 shows the MPLS architecture.

Figure 13-1-3 MPLS architecture
 The connectionless control plane generates and maintains routing information and labels.
On the control plane, the IP Routing Protocol module transmits routing information and
generates a routing information base (RIB); the Label Distribution Protocol module
switches labels and establishes LSPs.
 The forwarding plane, also called data plane, is connection-oriented and forwards common
IP
packets and labeled MPLS packets.
The forwarding plane consists of the modules IP forwarding information base (FIB) and label
forwarding information base (LFIB). When receiving common IP packets, the forwarding
plane forwards the packets based on the IP FIB or LFIB as required. When receiving labeled
packets, the forwarding plane forwards the packets based on the LFIB. If the destination
locates on an IP network, the data plane removes the labels and forwards the packets based on
the IP FIB.
13.1.2 MPLS Label
Forwarding Equivalence Class
Forwarding equivalence class (FEC) is a class-based forwarding technology that classifies the
packets with the same forwarding mode based on the destination address or mask. Packets with the
same FEC are forwarded in the same way on an MPLS network.
FEC can be defined based on the destination IP address and mask. For example, during IP
forwarding, packets with the same destination belong to a FEC according to the longest match
algorithm.
Label
A label is a short identifier that is 4 bytes long and has only local significance. It uniquely identifies
a FEC to which a packet belongs. In some cases, such as load balancing, a FEC can be mapped to
multiple incoming labels. Each label, however, represents only one FEC on a device.
Figure 13-1-4 shows the encapsulation structure of the label.
Figure 13-1-4 Structure of an MPLS label

A label contains the following fields:
 Label: indicates the value field of a label. The length is 20 bits.
 Exp: indicates the bits used for extension. The length is 3 bits. Generally, this field is used for
the class of service (CoS) that serves in a manner similar to Ethernet 802.1p.
 S: identifies the bottom of a label stack. The length is 1 bit. MPLS supports multiple
labels, namely, the label nesting. When the S field is 1, the label is at the bottom of the
label stack.
 TTL: indicates the time to live. The length is 8 bits. This field is the same as the TTL in IP
packets.
Labels are encapsulated between the data link layer and the network layer. Labels can be supported
by all data link layer protocols.
Figure 13-1-5 shows the position of the label in a packet.
Figure 13-1-5 Position of a label in a packet
Label Space
The label space is the value range of the label. The following describes the label space classification:
 0 to 15: indicates special labels. For details about special labels, see Table 13-1-1.
Table 13-1-1 Special labels
Label Value Label Description

0 IPv4 Explicit The label must be popped out, and the packets must be
NULL Label forwarded based on IPv4. If the egress node allocates a label
whose value is 0 to the LSR at the penultimate hop, the LSR at
the penultimate hop pushes label 0 to the top of the label stack
and forwards the packet to the egress node. When the
egress node recognizes that the value of the label carried in the
packet is 0, the egress node pops it out. The label 0 is valid
only at the bottom of the label stack.
Table 13-1-1 Special labels
Label Value
4 to 13
14
15
 16 to 1023: indicates the label space shared by static LSPs and static constraint-based routed
LSPs (CR-LSPs).
 1024 or above: indicates the label space for dynamic signaling protocols, such as Label
Distribution Protocol (LDP), Resource Reservation Protocol-Traffic Engineering (RSVP-
TE), and Multiprotocol Extensions for BGP (MP-BGP).
Label Stack
A label stack is a set of arranged labels. An MPLS packet can carry multiple labels at the same
time. The label next to the Layer 2 header is called the top label or the outer label. The label next
to the Layer 3 header is called the bottom label or inner label. Theoretically, MPLS labels can be
nested without any limit.
Figure 13-1-6 Label stack
The label stack organizes labels according to the rule of Last-In, First-Out. The labels are
processed from the top of the stack.
Label Operations
Information about basic label operations is a part of the label forwarding table. The operations
are described as follows:
 Push: When an IP packet enters an MPLS domain, the ingress node adds a new label to the
packet between the Layer 2 header and the IP header. Alternatively, an LSR adds a new label
to the top of the label stack, namely, the label nesting.
 Swap: When a packet is transferred within the MPLS domain, a local node swaps the label at
the top of the label stack in the MPLS packet for the label allocated by the next hop according
to the label forwarding table.
 Pop: When a packet leaves the MPLS domain, the label is popped out of the MPLS packet.
Alternatively, the top label of the label stack is popped out at the penultimate hop on an MPLS
network to decrease the number of labels in the stack.
In fact, the label is useless at the last hop of an MPLS domain. The penultimate hop popping
(PHP) feature applies. On the penultimate node, the label is popped out of the packet to reduce
the size of the packet that is forwarded to the last hop. Then, the last hop directly forwards the
IP packet or forwards the packet by using the second label.
PHP is configured on the egress node. The egress node supporting PHP allocates the label
with the value of 3 to the penultimate hop.
13.1.3 Establishing LSPs
Procedure for Establishing LSPs
Usually, MPLS allocates labels to packets and establishes an LSP through which MPLS
forwards packets.
The downstream LSR allocate labels to packets sent to the upstream LSR. As shown in Figure 13-1-
7, the downstream LSR identifies FEC based on the destination address, allocates a label to the
specified FEC, and records the mapping between the label and FEC. The downstream LSR then
encapsulates the mapping relationship into a message and sends it to the upstream LSR. A label
forwarding table and an LSP are established.
Figure 13-1-7 Establishment of an LSP
LSPs are classified into the following types:
 Static LSP: set up by the administrator.
 Dynamic LSP: set up using the routing protocols and label distribution protocols.
Establishing Static LSPs
You can manually allocate labels to set up static LSPs. The value of the outgoing label of the
upstream node is equal to the value of the incoming label of the downstream node.
The availability of a static LSP makes sense only for the local node that cannot detect the entire LSP.
A static LSP is set up without label distribution protocols or the exchanging of control packets. The
static LSP costs little and is recommended for small-scale networks with the simple and stable
topology. The static LSP cannot change with the network topology. Instead, it needs to be configured
by an administrator.
Establishing Dynamic LSPs
Dynamic LSPs are established using label distribution protocols. As the contr ol protocol or
signaling protocol for MPLS, a label distribution protocol defines FECs, distributes labels, and
establishes and maintains LSPs.
The following label distribution protocols apply to an MPLS network.
 LDP
LDP is defined to distribute labels and used to dynamically establish LSPs. An LSR can use LDP
to map routing information on the network layer to the LSP on the data link
layer. For details about LDP, see MPLS LDP.
 RSVP-TE
RSVP-TE is an extension to RSVP and used to establish or delete constraint-based
LSPs. For details about RSVP-TE, see MPLS TE.
 MP-BGP
MP-BGP is an extension to BGP and allocates labels to MPLS VPN routes and inter-AS VPN
routes.
For details about MP-BGP, see Feature Description - IP Routing.
13.1.4 MPLS Forwarding
MPLS Forwarding Principle
The LSP that supports the PHP is used in the following example to describe how MPLS packets
are forwarded.
Figure 13-1-8 MPLS label distribution and packet forwarding
As shown in Figure 13-1-8, an LSP whose FEC is identified by the destination address 4.4.4.2/24 is
set up on an MPLS network. MPLS packets are forwarded as follows:
1. The ingress node receives an IP packet destined for 4.4.4.2. Then, the ingress node adds Label Z
to the packet and forwards it.
2. The transit node receives the labeled packet and swaps labels by popping Label Z out
and pushing Label Y into the packet.
3. A transit node at the penultimate hop receives the packet with Label Y. The transit node pops
Label Y out because the label value is 3. The transit node then forwards th e packet to the
egress node as an IP packet.
4. The egress node receives the IP packet and forwards it to 4.4.4.2/24.
Process of MPLS Packet Forwarding
 NHLFE
The next hop label forwarding entry (NHLFE) can guide MPLS packet forwarding.
An NHLFE contains the following information:
 Tunnel ID
 Outbound interface
 Next hop
 Outgoing label
 Label operation
 FTN
FTN is a short form of FEC-to-NHLFE. The FTN indicates the mapping between a FEC and a
set of NHLFEs.
Details about the FTN can be obtained by searching for the Tunnel ID values that are not 0x0 in a
FIB. The FTN is available on the ingress only.
 ILM
The incoming label map (ILM) indicates the mapping between an incoming label and a set of
NHLFEs.
The ILM contains the following information:
 Tunnel ID
 Incoming label
 Inbound interface
 Label operation
The ILM on a transit node can bind the labels to NHLFEs. The function of an ILM table is
similar to the FIB that is searched according to destination IP addresses. Therefore, you
can obtain all label forwarding information by searching an ILM table.
 Tunnel ID
To provide the same interface of a tunnel used by upper layer applications such as the VPN
and route management, the system automatically allocates an ID to each tunnel, referred to as
the tunnel ID. The tunnel ID is 32 bits long and is valid only on the local end.
When an IP packet enters an MPLS domain, the ingress node searches the FIB to check whether
the tunnel ID corresponding to the destination IP address is 0x0.
 If the tunnel ID is 0x0, the packet is forwarded along the IP link.
 If the tunnel ID is not 0x0, the packet is forwarded along an LSP.

1210
Figure 13-1-9 Process of MPLS packet forwarding
MPLS packets are forwarded as follows on nodes along an LSP:
 The ingress node searches the FIB and NHLFE tables.
 The transit node searches the ILM and NHLFE tables.
 The egress node searches the ILM table or RIB.
During MPLS forwarding, FIB entries, ILM entries, and NHLFEs are associated with each
other through the tunnel ID.
 Forwarding on the ingress node
The ingress node processes the forwarding of MPLS packets as follows:
1. Searches the FIB and finds the tunnel ID corresponding to the destination IP address.
2. Finds the NHLFE corresponding to the tunnel ID in the FIB and associates the FIB
entry with the NHLFE entry.
3. Checks the NHLFE for information about the outbound interface, next hop, outgoing
label, and label operation type. The label operation type is Push.
4. Pushes the obtained label into IP packets, processes the EXP field according to QoS
policy and TTL field, and sends the encapsulated MPLS packets to the next hop.
 Forwarding on the transit node
The transit node forwards the received MPLS packets as follows:
1. Checks the ILM table corresponding to an MPLS label and finds the Tunnel ID.
2. Finds the NHLFE corresponding to the Tunnel ID in the ILM table.
3. Checks the NHLFE for information about the outbound interface, next hop, outgoing
label, and label operation type.
4. Processes the MPLS packets according to the specific label value:
 If the label value is equal to or greater than 16, a new label replaces the label in
the MPLS packet. At the same time, the EXP field and TTL field are processed.
The MPLS packet with the new label is forwarded to the next hop.
 If the label value is 3, the label is popped out of the MPLS packet. At the same
time, the EXP field and TTL field are processed. The packet is forwarded through
IP routes, or in accordance with its next layer label.
 Forwarding on the egress node
 When the egress node receives IP packets, it checks the FIB and performs IP forwarding.
 When the egress node receives MPLS packets, it checks the ILM table for the label
operation type. At the same time, the egress node processes the EXP field and TTL
field.
 When the S field in the label is equal to 1, the label is the stack's bottom label and
the packet is directly forwarded through IP routes.
 When the S field in the label is equal to 0, a next-layer label exists and the packet
is forwarded according to the next layer label.
13.1.5 MPLS TTL Processing
This section describes how MPLS processes the TTL and responds to TTL timeout.
MPLS TTL Processing Modes
The TTL field in an MPLS label is 8 bits long. The TTL field is the same as that in an IP packet
header. MPLS processes the TTL to prevent loops and implement traceroute.
RFC 3443 defines two modes to process the TTL in MPLS packets: Uniform mode and Pipe mode.
By default, MPLS processes the TTL in Uniform mode.
 Uniform mode
When IP packets enter an MPLS network, the ingress node decreases the IP TTL by one and
copies it to the MPLS TTL field. The TTL field in MPLS packets is processed in standard
mode. The egress node decreases the MPLS TTL by one and maps it to the IP TTL field.
Figure
13-1-10 shows how the TTL field is processed on the transmission path.
Figure 13-1-10 TTL processing in Uniform mode
 Pipe mode
As shown in Figure 13-1-11, the ingress node decreases the IP TTL by one and the MPLS
TTL is constant. The TTL field in MPLS packets is processed in standard mode. The egress
node decreases the IP TTL by one. In Pipe mode, the IP TTL only decreases by one on the
ingress node and one on the egress node when packets travels across an MPLS network.
Figure 13-1-11 TTL processing in Pipe mode

In MPLS VPN applications, the MPLS backbone network needs to be hidden to ensure
network security. The Pipe mode is recommended for private network packets.
TTL Timeout Responding
On an MPLS network, an LSR receives labeled MPLS packets. The LSR generates an
ICMP TTL-expired message when the TTL of an MPLS packet times out.
The LSR returns the TTL-expired message to the sender in the following ways:
 If the LSR has a reachable route to the sender, it directly sends the TTL-expired message to
the sender through the IP route.
 If the LSR has no reachable route to the sender, it forwards the TTL-expired message along the
LSP. The egress node forwards the TTL-expired message to the sender.
In most cases, the received MPLS packet contains only one label and the LSR responds to the sender
with the TTL-expired message using the first method. If the MPLS packet contains multiple labels,
the LSR uses the second method.
The MPLS VPN packets may contain only one label when they arrive at an autonomous system
boundary router (ASBR) on the MPLS VPN, a superstratum PE (SPE) device in HoVPN
networking, or a PE device in the VPN nesting networking. These devices have no IP routes to the
sender, so they use the second method to reply to the TTL-expired messages.
13.1.6 MPLS QoS Implementation
MPLS QoS, an important part in the deployment of QoS services, implements QoS using the
Differentiated Services (DiffServ) model in actual MPLS networking. MPLS QoS differentiates
data flows based on the EXP field value, which ensures low delay and low packet loss ratio for
voice and video data streams and increases network resource efficiency.
MPLS DiffServ
In the DiffServ model, network edge nodes map a service to a service class based on the QoS
requirements of the service and use the DS field (ToS field) in IP packets to identify the service.
Nodes on the backbone network apply preset policies to the service based on the DS field to ensure
service quality. The service classification and label mechanism of DiffServ are similar to label
distribution of MPLS. MPLS DiffServ combines DS distribution and MPLS label distribution.
MPLS DiffServ is implemented as the EXP field in an MPLS packet header carriers DiffServ per-
hop behavior (PHB). An LSR must consider the MPLS EXP value when determining the forwarding
policy. MPLS DiffServ provides the following plans for determining PHBs:
 E-LSP: an LSP whose PHB is determined by the EXP field. E-LSP applies to a network with
less than eight PHBs. In this plan, a differentiated services code point (DSCP) is mapped to a
specified EXP that identifies a PHB. Packets are forwarded based on labels, while the EXP field
determines the scheduling type and drop priority at each hop. An LSP transmits a maximum of
eight PHB flows that are differentiated based on the EXP field in the MPLS packet header. The
EXP field can be determined by the ISP or mapped from the DSCP value in a packet. In this
plan, PHB information does not need to be transmitted by signaling protocols, the label
efficiency is high, and the label status is easy to maintain.
 L-LSP: an LSP whose PHB is determined by both the label and EXP field. L-LSP applies to a
network with any number of PHBs. During packet forwarding, the label of a packet determines
the forwarding path and scheduling type, while the EXP field determines the drop priority of
the
packet. Labels differentiate service flows, so multiple service flows can be transmitted over one
LSP. This plan requires more labels and so occupies a large number of system resources.
NOTE:
Currently, only the E-LSP plan is supported.
MPLS DiffServ Modes
An MPLS network provides tunnels for services. MPLS L3VPN DiffServ modes include: pipe,
short pipe, and uniform.
 Pipe: The EXP field value that the ingress node adds to the MPLS label of packets is specified
by the user. If the EXP field value of the packet is changed on the MPLS network, the change is
valid only on the MPLS network. The egress node selects the PHB according to the EXP field
value of the packet. When the packet leaves the MPLS network, the previous DSCP value
becomes effective again.
 Short pipe: The EXP field value that the ingress node adds to the MPLS label of packets is
specified by the user. If the EXP field value of the packet is changed on the MPLS network,
the change is valid only on the MPLS network. The egress node selects the PHB according to
the DSCP field value of the packet. When the packet leaves the MPLS network, the previous
DSCP value becomes effective again.
 Uniform: The priorities of packets on the IP network and the MPLS network are uniformly
defined, so the priorities of the packets on the two networks are globally valid. At the
ingress node, each packet is assigned a label and the lower 3 bits in the DSCP field are
mapped to the EXP field. A change in the value of the EXP field on the MPLS network
determines the PHB used when the packet leaves the MPLS network. The egress node maps
the EXP field to the DSCP field.
On an L2VPN, the MPLS label is in the outer layer of an encapsulated packet. Therefore, the
802.1p field of VLAN packets needs to be mapped to the EXP field.
13.1.7 MPLS Ping/Tracert
Introduction to MPLS Ping/Tracert
On an MPLS network, the control panel used for setting up an LSP cannot detect the failure in
data forwarding of the LSP. This makes network maintenance difficult. The MPLS ping and
tracert mechanisms detect LSP errors and locate faulty nodes.
MPLS ping is used to check network connectivity and host reachability. MPLS tracert is used to
check the network connectivity and host reachability, and to locate network faults. Similar to IP ping
and tracert, MPLS ping and tracert use MPLS echo request packets and MPLS echo reply packets to
check LSP availability. MPLS echo request packets and echo reply packets are both encapsulated into
User
Datagram Protocol (UDP) packets. The UDP port number of the MPLS echo request packet is
3503, which can be identified only by MPLS-enabled devices.
An MPLS echo request packet carries FEC information to be detected, and is sent along the same LSP
as other packets with the same FEC. In this manner, the connectivity of the LSP is checked. MPLS
echo request packets are forwarded to the destination end using MPLS, while MPLS echo reply
packets are forwarded to the source end using IP. Routers set the destination address in the IP header
of the MPLS echo request packets to 127.0.0.1/8 (local loopback address) and the TTL value is 1. In
this way, MPLS echo request packets are not forwarded using IP forwarding when the LSP fails so
that the
failure of the LPS can be detected.
MPLS Ping
Figure 13-1-12 MPLS network
As shown in Figure 13-1-12, RouterA establishes an LSP to RouterD. RouterA performs MPLS
ping on the LSP by performing the following steps:
1. RouterA checks whether the LSP exists. (On a TE tunnel, the router checks whether the
tunnel interface exists and the CR-LSP has been established.) If the LSP does not exist, an
error message is displayed and the MPLS ping stops. If the LSP exists, RouterA performs the
following operations.
2. RouterA creates an MPLS echo request packet and adds 4.4.4.4 to the destination FEC stack
in the packet. In the IP header of the MPLS echo request packet, the destination address is
127.0.0.1/8 and the TTL value is 1. RouterA searches for the corresponding LSP, adds the LSP
label to the MPLS echo request packet, and sends the packet to RouterB.
3. Transit nodes RouterB and RouterC forward the MPLS echo request packet based on MPLS.
If MPLS forwarding on a transit node fails, the transit node returns an MPLS echo reply
packet carrying the error code to RouterA.
4. If no fault exists along the MPLS forwarding path, the MPLS echo request packet reaches the
LSP egress node RouterD. RouterD returns a correct MPLS echo reply packet after verifying
that the destination IP address 4.4.4.4 is the loopback interface address. MPLS ping is
complete.
MPLS Tracert
As shown in Figure 13-1-12, RouterA performs MPLS tracert on RouterD (4.4.4.4/32) by

performing the following steps:
1. RouterA checks whether an LSP exists to RouterD. (On a TE tunnel, the router checks
whether the tunnel interface exists and the CR-LSP has been established.) If the LSP does not
exist, an error message is displayed and the tracert stops. If the LSP exists, RouterA performs
the following operations.
2. RouterA creates an MPLS echo request packet and adds 4.4.4.4 to the destination FEC stack
in the packet. In the IP header of the MPLS echo request packet, the destination address is
127.0.0.1/8. Then RouterA adds the LSP label to the packet, sets the TTL value to 1, and
sends the packet to RouterB. The MPLS echo request packet contains a downstream mapping
TLV
that carries downstream information about the LSP at the current node, such as next-hop
address and outgoing label.
3. Upon receiving the MPLS echo request packet, RouterB decreases the TTL by one and finds
that TTL times out. RouterB then checks whether the LSP exists and the next-hop address and
whether the outgoing label of the downstream mapping TLV in the packet is correct. If so,
RouterB returns a correct MPLS echo reply packet that carries the downstream mapping TLV
of RouterB. If not, RouterB returns an incorrect MPLS echo reply packet.
4. After receiving the correct MPLS echo reply packet, RouterA resends the MPLS echo request
packet that is encapsulated in the same way as step 2 and sets the TTL value to 2. The
downstream mapping TLV of this MPLS echo request packet is replicated from the MPLS
echo reply packet. RouterB performs common MPLS forwarding on this MPLS echo request
packet. If TTL times out when RouterC receives the MPLS echo request packet, RouterC
processes the MPLS echo request packet and returns an MPLS echo reply packet in the same
way as step 3.
5. After receiving a correct MPLS echo reply packet, RouterA repeats step 4, sets the TTL value to
3, replicates the downstream mapping TLV in the MPLS echo reply packet, and sends the
MPLS echo request packet. RouterB and RouterC perform common MPLS forwarding on this
MPLS echo request packet. Upon receiving the MPLS echo request packet, RouterD repeats
step 3 and verifies that the destination IP address 4.4.4.4 is the loopback interface address.
RouterD returns an MPLS echo reply packet that does not carry the downstream mapping
TLV. MPLS tracert is complete.
When routers return the MPLS echo reply packet that carries the downstream mapping TLV, RouterA
obtains information about each node along the LSP.
13.2 MPLS LDP
LDP Adjacency
When an LSR receives a Hello message from a peer, an LDP peer may exist. An LDP adjacency can
be created to maintain the presence of the peer. There are two types of LDP adjacencies:
 Local adjacency: The adjacency is discovered by exchanging Link Hello messages.

 Remote adjacency: The adjacency is discovered by exchanging Target Hello messages.
LDP Peers
LDP peers refer to two LSRs that use LDP to set up an LDP session and then exchange label
messages. LDP peers learn labels from each other using the LDP session between them.
LDP Session
LSRs in an LDP session exchange messages such as label mapping messages and label
release messages. LDP sessions are classified into the following types:
 Local LDP session: The LDP session is set up between local adjacencies. The two LSRs
setting up the local LDP session are directly connected.
 Remote LDP session: The LDP session is set up between remote adjacencies. The two
LSRs setting up the remote LDP session can be either directly or indirectly connected.
NOTE:
LDP maintains the presence of peers using adjacencies. The type of peers depends on the type of
adjacencies. A pair of peers can be maintained by multiple adjacencies. If a pair of peers is maintained
by both local and remote adjacencies, the peers support coexistence of the local and remote
adjacencies. An LDP session can only be established if such pairs of peers exist.
A local and a remote LDP session can be set up

simultaneously.
The principle is that the local and remote LDP adjacencies can be connected to the same peer so
that the peer is maintained by both the local and remote LDP adjacencies.
As shown in Figure 13-2-1, when the local LDP adjacency is deleted due to a failure on the link to
which the adjacency is connected, the peer's type may change without affecting its presence or status.
(The peer type is determined by the adjacency type. The types of adjacencies include local, remote,
and coexistent local and remote.)
If the link becomes faulty or is recovering from a fault, the peer type may change while the type of
the session associated with the peer changes accordingly. However, the session is not deleted and
does not become Down. Instead, the session remains Up.
Figure 13-2-1 Networking diagram for a coexistent local and remote LDP session
A coexistent local and remote LDP session is typically applied to L2VPN. As shown in Figure 13-2-
1, L2VPN services are transmitted between PE1 and PE2. When the directly-connected link between
PE1 and PE2 recovers after being disconnected, the processing is as follows:
1. MPLS LDP is enabled on the directly-connected PE1 and PE2, and a local LDP session is set
up between PE1 and PE2. PE1 and PE2 are configured as the remote peer of each other, and a
remote LDP session is set up between PE1 and PE2. Local and remote adjacencies are then set
up between PE1 and PE2. Since now, both local and remote LDP sessions exist between PE1
and PE2. L2VPN signaling messages are transmitted through the compatible local and remote
LDP session.
2. When the physical link between PE1 and PE2 becomes Down, the local LDP adjacency also
goes Down. The route between PE1 and PE2 is still reachable through the P, indicating that
the remote LDP adjacency remains Up. The session changes to a remote session so that it can
remain Up. The L2VPN does not detect the change in session status and therefore does not
delete the session. This prevents the L2VPN from having to disconnect and recover services,
and shortens service interruption time.
3. When the fault is rectified, the link between PE1 and PE2 as well as the local LDP adjacency
can go Up again. The session changes to the compatible local and remote LDP session and
remains Up. Again, the L2VPN will not detect the change in session status and therefore
does not delete the session. This shortens service interruption time.
Type of LDP Messages
LDP messages are classified into the following types:
 Discovery message: used to notify and maintain the existence of an LSR on a network.
 Session message: used to establish, maintain, and terminate sessions between LDP peers.
 Advertisement message: used to create, modify, and delete label mappings for FECs.
 Notification message: used to provide advisory and error information.
To ensure the reliability of message transmission, LDP uses the TCP transport for Session,
Advertisement, and Notification messages. LDP uses the UDP transport only for transmitting
the Discovery message.
Label space
A label space is a range of labels allocated between LDP peers, which can be categorized as follows:
 Per-platform label space: An entire LSR uses one label space. Currently, per-platform label
space is mostly used.
 Per-interface label space: Each interface of an LSR is assigned a label space.

LDP identifier
An LDP identifier identifies the label space used by a specified LSR. An LDP identifier is 6 bytes in
the format <LSR ID>:<Label space ID>.
 LSR ID: indicates the 4-byte LSR identifier.
 Label space ID: indicates the 2-byte label space identifier. The value 0 indicates the per-
platform label space, while the value non-0 indicates the per-interface label space.
For example, the LDP ID is 192.168.1.1:0, indicating that the LSR ID is 192.168.1.1 and per
-platform label space is used.
13.2.2 LDP Working Mechanism
LDP defines the label distribution process and messages transmitted during label distribution. An
LSR can use LDP to map routing information on the network layer to on the data link layer, setting
up an LSP. LDP working process goes through the following phases:
1. After discovering a neighbor, an LSR sets up an LDP session.
2. After the session is established, LDP notifies LDP adjacencies of the mappings between
FECs and labels and sets up an LSP.
RFC 5036 defines the label advertisement mode, label distribution control mode, and
label retention mode to determine how the LSR advertises and manages labels.
LDP Session
LDP Discovery Mechanisms
LDP discovery mechanisms are used by LSRs to discover potential LDP peers. LDP
discovery mechanisms are classified into the following types:
 Basic discovery mechanism: used to discover directly-connected LSR peers on a link.
An LSR periodically sends LDP Hello messages to implement the mechanism and establish
a local LDP session.
The Hello messages are encapsulated in UDP packets with the multicast destination address
and sent through LDP port 646. A Hello message carries an LDP ID and other information
(such as the hello-hold time and the transport address). If an LSR receives an LDP Hello
message on a specified interface, a potential LDP peer is connected to the same interface.
 Extended discovery mechanism: used to discover the LSR peers that are not directly
connected on a link.
An LSR periodically sends Target Hello messages to a specified destination address according
to the mechanism to establish a remote LDP session.

1210
The Target Hello messages are encapsulated in UDP packets and carry unicast destination
addresses, sent using LDP port 646. A Target Hello message carries an LDP ID and other
information (such as the hello-hold time and the transport address). If an LSR receives a
Target Hello message, the LSR has a potential LDP peer.
Process of Establishing an LDP Session
Two LSRs exchange Hello messages to trigger the establishment of an LDP session.
Figure 13-2-2 shows the process of LDP session establishment.
Figure 13-2-2 Process for establishing an LDP session

1. Two LSRs send Hello messages to each other.
2. After receiving the Hello messages carrying the transport addresses, the two LSRs use the
transport addresses to establish an LDP session. The LSR with the larger transport address
serves as the active peer and initiates a TCP connection. As shown in Figure 13-2-2, LSRA
serves as the active peer to initiate a TCP connection and LSRB serves as the passive peer
to wait for the initiation of the TCP connection.
3. After the TCP connection is successfully established, LSRA sends an Initialization message to
negotiate parameters used to establish an LDP session with LSRB. The main parameters
include the LDP version, label advertisement mode, the Keepalive hold timer value, maximum
PDU length, and label space.
4. If LSRB rejects some parameters, it sends a Notification message to terminate the

establishment of the LDP session. If LSRB accepts all parameters, it sends an Initialization
message carrying the LDP version, label advertisement mode, the Keepalive hold timer value,
maximum PDU length, and label space, and sends a Keepalive message to LSRA.
5. If LSRA rejects certain parameters after receiving the Initialization message, it sends a
Notification message to terminate LDP session establishment. If LSRA accepts all
parameters, it sends a Keepalive message to LSRB.
After both LSRA and LSRB have accepted Keepalive messages from each other, the LDP session
is successfully established.
Advertising and Managing Labels
Label Advertisement Modes
An LSR on an MPLS network assigns a label to a specified FEC and notifies its upstream LSRs of the
label. This means that the label is specified by a downstream LSR, and is distributed from
downstream to upstream.
As described in Table 13-2-1, two label advertisement modes are

available.
Table 13-2-1 Label advertisement modes
Label Advertisement Modes
Downstream Unsolicited (DU)

mode
Downstream on Demand (DoD)

mode
The label advertisement modes on upstream and downstream LSRs must be the same.
NOTE:
When DU is used, LDP supports label distribution for all peers by default. Each node can send Label
Mapping messages to all peers without distinguishing upstream and downstream nodes. If an LSR
distributes labels only for upstream peers when it sends Label Mapping messages, the LSR checks the
upstream/downstream relationship of the session in routing information. An upstream node cannot
send Label Mapping messages to its downstream node along a route. If the route changes and the
upstream/downstream relationship is switched, the new downstream node resends Label
Mapping
messages. In this process, the convergence is slow.
Figure 13-2-3 DU and DoD

Label Distribution Control Modes
The label distribution control mode refers to a method of label distribution on the LSR during LSP
establishment.
As described in Table 13-2-2, two label distribution control modes are available.
Table 13-2-2 Label distribution control modes
Label Distribution Control Definition Description

Modes
Independent mode A local LSR can distribute a As shown in Figure


label bound to an FEC and then
inform the upstream LSR, 13-2-3, if the label
without waiting for the label advertisement mode is DU
distributed by the downstream
and the label distribution
LSR.
control mode is
Independent, a transit LSR
can assign a label to the
ingress node without
waiting for the label
assigned by the egress
node.
 As shown in Figure
13-2-3, if the label
advertisement mode is
DoD and the label
distribution control mode
is Independent, the
directly-connected ingress
transit node that sends a
Label Request message
Table 13-2-2 Label distribution control modes
Label
Ordered mode
Label Retention Modes

The label retention mode refers to the way an LSR processes the label mapping that it receives but
does not immediately use.
The label mapping that an LSR receives may or may not originate at the next hop.
As described in Table 13-2-3, two label retention modes are available.
Table 13-2-3 Label retention modes
Label Retention Modes
Liberal mode
Conservative mode
Currently, the combination of the following modes is supported:
 Combination of the DU label advertisement mode, ordered label control mode, and liberal
label retention mode
 Combination of the DoD label advertisement mode, ordered label control mode, and
conservative label retention mode
13.2.3 LDP Label Filtering Mechanism
By default, an LSR receives and sends Label Mapping messages for all FECs, resulting in the
establishment of a large number of LDP LSPs. The establishment of a large number of LDP LSPs
consumes a great deal of LSR resources. As a result, the LSR may be overburdened. An outbound
or inbound LDP policy needs to be configured to reduce the number of Label Mapping messages to
be sent or received, reducing the number of LSPs to be established and saving memory.
Outbound LDP Policy
LDP outbound policies are used to filter out Label Mapping messages sent to peers. If a FEC matches
no outbound policy, neither a transit LSP nor an egress LSP can be established. If a pair of or all peers
have the same restriction on the FEC range when sending Label Mapping messages, the same
outbound policy can be configured for the pair of or all peers.
An LDP outbound policy filters out Label Mapping messages only for the FEC, but not those for
L2VPN. Meanwhile, the LDP outbound policy specifies the FEC range.
In addition, the outbound LDP policy supports split horizon. After split horizon is configured, an LSR
distributes labels only to its upstream LDP peers.
Before sending Label Mapping messages only for the FEC to a peer, an LSR checks whether
an outbound policy is configured.
 If no outbound policy is configured, the LSR sends the Label Mapping message.
 If an outbound policy is configured, the LSR checks whether the FEC in the Label Mapping
message is within the range defined in the outbound policy. If the FEC is within the FEC
range, the LSR sends a Label Mapping message for the FEC; if the FEC is not within the FEC
range, the LSR does not send a Label Mapping message.
Inbound LDP Policy
LDP inbound policies are used to filter out Label Mapping messages received from peers. If a FEC
matches no inbound policy, Label Mapping messages are not accepted. If a pair of or all peers have
the same restriction on the FEC range when receiving Label Mapping messages, the same inbound
policy can be configured for the pair of or all peers.
An LDP inbound policy filters out Label Mapping messages only for the FEC, but not those for
L2VPN. Meanwhile, the LDP inbound policy specifies the FEC range for non-BGP routes.
An LSR checks whether an inbound policy mapped to a FEC is configured before receiving a Label
Mapping message for the FEC.
 If no inbound policy is configured, the LSR receives the Label Mapping message.
 If an inbound policy is configured, the LSR checks whether the FEC in the Label Mapping
message is within the range defined in the inbound policy. If the FEC is within the FEC
range, the LSR receives the Label Mapping message for the FEC; if the FEC is not in the
FEC range, the LSR does not receive the Label Mapping message.
If the FEC fails to pass an outbound policy on an LSR, the LSR receives no Label Mapping
message for the FEC.
One of the following results may occur:
 If a DU LDP session is established between an LSR and its peer, a liberal LSP is established.
This liberal LSP cannot function as a backup LSP after LDP FRR is enabled.
 If a DoD LDP session is established between an LSR and its peer, the LSR sends a
Release message to tear down label-based bindings.
NOTE:
An LSP that is distributed with a label but is not successfully established called a liberal LSP.
13.2.4 Synchronization between LDP and Static Routes
Synchronization between LDP and static routes applies to MPLS networks where primary and
backup LSPs exist. LSPs are established between LSRs based on static routes. When the LDP session
on the primary LSP fails (not due to a link failure) or the primary LSP is restored, MPLS traffic is
interrupted for a short time.
As shown in Figure 13-2-4, LSRA and LSRD are connected using static routes. LDP establishes
primary and backup LSPs between LSRA and LSRD based on static routes, and LinkA is the
primary path.
Figure 13-2-4 LSP switchover based on synchronization between LDP and static
routes
Synchronization between LDP and static routes implements LSP switchover in the following scenarios:
 The LDP session on the primary LSP fails (not due to a link failure).
When an LDP session is established, MPLS traffic is forwarded through LinkA. If LDP is
disabled or faulty on LSRB, the LDP session between LSRA and LSRB fails. However, the
link between LSRA and LSRB is running properly and static routes are active. MPLS traffic is
interrupted between LSRA and LSRD during LSP switchover to LinkB.
After synchronization between LDP and static routes is enabled on LSRA, static routes
automatically switch to LinkB when the LDP session is Down. This ensures uninterrupted
MPLS traffic during an LSP switchover.
 The primary LSP recovers from a fault.
If the link between LSRA and LSRB fails, the LSP switches to LinkB. When the link between
LSRA and LSRB recovers, the LSP switches back to LinkA. At this time, the backup LSP cannot
be used, but the new LSP has not been established. MPLS traffic between LSRA and LSRD
is interrupted during this period.
After synchronization between LDP and static routes is enabled on LSRA, static routes
become active only when the LDP session is Up, which ensures uninterrupted traffic.
13.2.5 Synchronization between LDP and IGP
Background
The LDP convergence speed depends on the convergence speed of IGP routes, which indicates IGP
convergence is faster.
 On an MPLS network with the primary and backup links, the following problems occur:
1. When the primary link fails, an IGP route of the backup link becomes reachable and a
backup LSP over the backup link takes over traffic. After the primary link recovers,
the IGP route of the primary link becomes reachable before an LDP session is
established over the primary link. As a result, traffic is dropped when being
transmitted using the reachable IGP route along the unreachable LSP.
2. When the IGP route of the primary link is reachable and an LDP session between nodes
on the primary link fails, traffic is directed using the IGP route of the primary link,
whereas the LSP over the primary link is torn down. Because a preferred IGP route of
the backup link is unavailable, an LSP over the backup link cannot be established,
causing traffic loss.
 When the active/standby switchover occurs on a node, the LDP session establishment is
later than the IGP GR completion. IGP advertises the maximum cost of the link, causing
route flapping.
Related Concepts
Synchronization between LDP and IGP is implemented by suppressing IGP from advertising
normal routes to ensure convergence performed by synchronization between LDP and IGP.
Synchronization between LDP and IGP involves three timers:
 Hold-down timer: used to control the period for establishing the IGP neighbor relationship.
 Hold-max-cost timer: used to control the period for advertising the maximum cost of the link.
 Delay timer: used to control the period for waiting for the LSP establishment.
Implementation
Figure 13-2-5 Synchronization between LDP and IGP for reverting switchover
 During active/standby link switchover, synchronization between LDP and IGP takes
effect.
As shown in Figure 13-2-5, the processes of synchronization between LDP and IGP differ in
the following scenarios:
1. The primary link recovers from a physical fault.
a. The faulty link recovers.
b. An LDP session is set up between LSR2 and LSR3. IGP suppresses the
establishment of the neighbor relationship and starts the Hold-down timer
as required.
c. Traffic keeps traveling through the LSP over the backup link.
d. After the LDP session is set up, Label Mapping messages are exchanged and
then synchronization between IGP and LDP starts.
e. The IGP establishes a neighbor relationship and switches traffic back to the
primary link, and the LSP is reestablished and its route converges on the
primary link (in milliseconds).
2. IGP on the primary link is normal and the LDP session is faulty.
a. An LDP session between nodes along the primary link becomes
defective. b. LDP notifies the IGP primary link of the session fault. IGP
starts the
Hold-max-cost timer and advertises the maximum cost on the primary
link. c. The IGP route of the backup link becomes reachable.
d. An LSP is established over the backup link and the LDP module on LSR2
delivers forwarding entries.
The Hold-max-cost timer can be configured to always advertise the maximum cost of
the primary link. This setting allows traffic to keep traveling through the backup link
before
the LDP session over the primary link is reestablished.
 During active/standby system switchover, the procedure for synchronization between LDP and
IGP is as follows:
1. An IGP on the Restarter advertises a normal cost value and starts a Delay timer,
waiting for an LDP session to be set up. Then IGP ends the GR process.
2. If the Delay timer expires before the LDP session is set up, IGP starts a Hold-max-
cost timer, and advertises the maximum cost value of the link.
3. After the LDP session is established or the Hold-max-cost timer expires, IGP
advertises the actual link cost and updates the IGP route.
4. The helper retains the IGP route and LSP. After the LDP session on the helper goes
Down, the LDP module does not notify the IGP module of the session status change. This
indicates that IGP keeps advertising the actual link cost, preventing traffic or LSP
switchover.
13.2.6 BFD for LSP
A Bidirectional Forwarding Detection (BFD) session is established on an LSP. BFD is used to

quickly detect faults on the LSP, providing end-to-end protection.
BFD is used to detect faults on the data plane of the MPLS LSP, and the format of BFD packets is
fixed. When a BFD session is associated with a unidirectional LSP, the reverse link can be an IP lin
k, an LSP, or a TE tunnel.
Implementation
BFD detects LSPs in asynchronous mode. The ingress and the egress nodes send BFD control
packets to each other periodically.
 If any of the ingress and the egress nodes does not receive BFD control packets sent by the
peer within a detection period, LSP status is considered to be Down and a message that the
LSP is Down is sent to the LSP Management (LSPM) module.
 If the LSP status changes between Up and Down frequently, BFD sends two messages of LSP
changes successively. Therefore, the detection can be performed flexibly.
 If the reverse link of the BFD control packets sent by the egress node to the ingress node
fails, the BFD session is Down.
NOTE:
BFD is a bidirectional detection mechanism, but BFD for LSP is unidirectional. BFD for LSP
sends BFD control packets through LSPs on the ingress node and through IP links on the egress
node. As a result, when the ingress node does not receive BFD control packets sent through the
reverse path from the egress node, the system considers that the LSP fails no matter the fault occurs
on LSP or on the reverse link.
1210
BFD Session Setup
To check MPLS LSP connectivity, negotiation on a BFD session can be performed in the
following modes:
 Static: The negotiation on a BFD session is performed using the local discriminator (LD)
and remote discriminator (RD) that are manually configured.
 Dynamic: The negotiation on a BFD session is performed using the BFD discriminator TLV in an
LSP ping packet.
BFD detects the following types of LSPs:
 Static BFD for static LSP
 Static BFD for LDP LSP
 Dynamic BFD for LDP LSP
Figure 13-2-6 shows the establishment of dynamic BFD sessions that detect LDP LSPs.
1. The ingress node sends an MPLS echo request packet that carries the type-length-value
(TLV) with the type as 15 along an LSP. The packet contains an LD that the ingress node
allocates to the BFD session.
2. The egress node receives the MPLS echo request packet sent from the ingress node and
takes the contained LD as its own RD.
3. The egress node sends an MPLS echo reply packet to the ingress node. The packet contains an
LD that the egress node allocates to the BFD session.
4. The ingress node receives the MPLS echo reply packet sent by the egress node and takes
the contained LD as its own RD.
The dynamic BFD session that detects the LDP LSP is created successfully.
Figure 13-2-6 Establish a session of dynamic BFD for LDP LSP

13.2.7 LDP FRR
LDP Fast Reroute (FRR) provides the fast reroute function for MPLS networks by backing up
local interfaces.
LDP FRR, in liberal label retention mode of LDP, obtains a liberal label, applies a forwarding entry
for the label, and then forwards the forwarding entry to the forwarding plane as the backup
forwarding entry for the primary LSP. When the interface is faulty (detected by the interface itself or
according to BFD detection) or the primary LSP fails (according to BFD detection), LDP FRR fast
switches traffic to the backup LSP to protect the primary LSP.
 Manually configured LDP FRR needs to be specified with the outbound interface and next hop
of the backup LSP by running a command. When the source of the liberal label matches the
outbound interface and next hop, a backup LSP can be established and its forwarding entries can
be delivered.
 LDP auto FRR depends on the implementation of IP FRR. When the source of the preserved
liberal label matches the outbound interface and next hop of the backup route, the requirement
for the policy for establishing the backup LSP is met, and no backup LSP manually configured
according to the backup route exists, a backup LSP can be established and its forwarding
entries can be delivered. The default policy of LDP auto FRR is that LDP can use the 32-bit
backup routes to establish backup LSPs. When both the manually configured LDP FRR and
LDP auto FRR meet the establishment conditions, the manually configured LDP FRR is
established preferentially.
Applicable Environment
Figure 13-2-7 A typical applicable environment of LDP FRR (triangle topology)

Figure 13-2-7 shows a typical applicable environment of LDP FRR. The optimal route from LSRA to
LSRB is LSRA -> LSRB and the less optimal route is LSRA -> LSRC -> LSRB. A primary LSP
along the path LSRA -> LSRB is established on LSRA, and a backup LSP along the path LSRA ->
LSRC -> LSRB is established to protect the primary LSP. After receiving a label from LSRC, LSRA
compares the label with the route from LSRA to LSRB and finds that LSRC is not the next hop of the
route. LSRA preserves the label as a liberal label and applies for a forwarding entry as the backup
forwarding entry of the primary LSP. LSRA forwards the forwarding entries of both the primary and
backup LSPs to the forwarding plane. In this manner, the primary LSP is associated with the backup
LSP.
When the interface detects faults by itself, BFD detects faults on the interface, or BFD detects that the
primary LSP fails, LDP FRR is triggered. After LSP FRR is complete, traffic is switched to the backup
LSP according to the backup forwarding entry. In this manner, LSP FRR takes effect. Then , the route
is converged from LSRA-LSRB to LSRA-LSRC-LSRB. An LSP is established on the new LSP (the
original backup LSP), and the original primary LSP is deleted, and then the traffic is forwarded along
the new LSP LSRA -> LSRC -> LSRB.
Figure 13-2-8 A typical applicable environment of LDP FRR (rectangle

topology)
As shown in Figure 13-2-7, all nodes in the triangle topology supports LDP FRR, but only parts of
nodes in the rectangle topology supports LDP FRR. As shown in Figure 13-2-8, if the optimal route
from N1 to D is N1 -> N2 -> D (load balancing is unavailable), S receives a liberal label from N1
and is configured with LDP FRR. When the link between S and D is faulty, traffic is switched to the
route of S -> N1 -> N2 -> D without forming a loop.
However, if the optimal route from N1 to D is load balanced between N1 -> N2 -> D and N1 -> S ->
D, S as the downstream neighbor of N1 does not necessarily receive the liberal label from N1. In
addition, even though S receives the liberal label (LDP distributes labels for each peer) and is
configured with LDP FRR, traffic may still go to S after traffic switches to N1, which leads to a loop.
This occurs till
the route from N1 to D is converged to N1 -> N2 -> D.
13.2.8 LDP GR
LDP graceful restart (GR) ensures uninterrupted traffic forwarding on the restarter with the help of
a neighbor (Helper) when an active main board/standby main board (AMB/SMB) switchover or a
protocol restart occurs on the restarter.
When the AMB/SMB switchover occurs on a device that is not capable of GR, the neighbor deletes
the LSP because the LDP session becomes Down. As a result, traffic cannot be forwarded and services
are interrupted for a short period. To prevent service interruption, LDP GR can be configured to keep
labels consistent before and after the AMB/SMB switchover or the protocol restart. LDP GR
ensures uninterrupted MPLS forwarding. Figure 13-2-9 shows the detailed process.
1. Before the AMB/SMB switchover, LDP neighbors negotiate the GR capability during the LDP
session establishment.
2. After the AMB/SMB switchover, the GR detects helper starts the LDP session failure and
starts the GR Reconnect timer. The GR helper retains the forwarding entries related to the GR
restarter and marks the entries with the stale tag.
3. After performing the AMB/SMB switchover, the GR restarter starts the Forwarding State
Holding timer. Before the Forwarding State Holding timer times out, the GR restarter retains
all MPLS forwarding entries before the restart and marks the entries with the stale tag. The GR
restarter then sends an LDP Initialization message to the GR helper. When the Forwarding
State Holding timer times out, the GR restarter performs step 6.
4. Before the GR Reconnect timer times out, the LDP session is reestablished. The GR
helper deletes the Forwarding State Holding timer, starts the GR Recovery timer, and
retains the forwarding entries with the stale tag.
5. Before the GR Recovery timer times out, the neighbors exchange Label Mapping messages
with each other and restore the label binding before the AMB/SMB switchover. When the GR
Recovery timer times out, the GR helper deletes all forwarding entries with the stale tag.
6. The GR process ends. The GR restarter deletes all forwarding entries with the stale tag.
Figure 13-2-9 LDP GR implementation
13.2.9 LDP NSR
The non-stop routing (NSR) technology is an innovation based on non-stop forwarding (NSF)
technology. If a software or hardware fault occurs on the control plane, NSR ensures
uninterrupted forwarding and connection of the control plane. In addition, the control plane of a
neighbor will not detect any fault.
LDP NSR is implemented using the synchronization of the master and slave control boards. During
the startup, the slave control board backs up data of the master control board in batch es to ensure data
consistency on both boards. LDP NSR simultaneously notifies the master and slave control boards of
receipt of packets and backs up these packets in real time. In this manner, the slave control board
synchronizes data with the master control board. NSR ensures that after switchover, the slave control
board can quickly take over services from the original master control board, while the neighbor will
not detect the fault on the local router.
LDP NSR synchronizes the following key data between the master and slave control boards:
 LSP forwarding entries
 Key resources such as labels and cross connections
 LDP protocol control blocks
13.2.10 LDP Security Mechanisms
MD5 Authentication
Message-digest algorithm 5 (MD5) is a standard digest algorithm defined in RFC 1321. A typical
application of MD5 is to calculate a message digest to prevent message spoofing. The MD5 message
digest is a unique result calculated by an irreversible character string conversion. If a message is
modified during transmission, a different digest is generated. After the message arrives at the
receiver, the receiver can determine whether the packet is modified by comparing the received digest
with the pre-calculated digest.
LDP MD5 authentication prevents LDP packets from being modified by generating a unique digest
for an information segment. This authentication is stricter than the common checksum verification of
TCP connections.
Before an LDP message is sent over a TCP connection, LDP MD5 authentication is performed by
padding the TCP header with a unique digest. This digest is a result calculated by MD5 based on
the TCP header, LDP session message, and password set by the user.
When receiving this TCP packet, the receiver obtains the TCP header, digest, and LDP session
message, and then uses MD5 to calculate a digest based on the received TCP header, received
LDP session message, and locally stored password. The receiver compares the calculated digest
with the received one to check whether the packet is modified.
A password can be set in either cipher text or plain text. The plain-text password is directly recorded
in the configuration file. The cipher-text password is recorded in the configuration file after being
encrypted using a special algorithm.
During the calculation of a digest, the manually entered character string is used regardless of
whether the password is in plain text or cipher text. This indicates that a password calculated using a
private encryption algorithm does not participate in MD5 calculation, ensuring that LDP MD5
authentication implemented on Huawei devices is transparent to non-Huawei devices.
Keychain Authentication
Keychain, an enhanced encryption algorithm to MD5, calculates a message digest for the same LDP
message to prevent the message from being modified.
During keychain authentication, a group of passwords are defined to form a password string. Each
password is specified with encryption and decryption algorithms such as MD5 algorithm and SHA-
1, and is configured with the validity period. When sending or receiving a packet, the system selects
a valid password based on the user's configuration. Within the valid period of the password, the
system uses the encryption algorithm matching the password to encrypt the packet before sending it
out, or uses the decryption algorithm matching the password to decrypt the packet before accepting
it. In
addition, the system automatically uses a new password after the previous password expires,
preventing the password from being decrypted.
The keychain authentication password, the encryption and decryption algorithms, and the password
validity period that construct a keychain configuration node are configured using different
commands. A keychain configuration node requires at least one password and encryption and
decryption algorithms.
LDP GTSM
Generalized TTL Security Mechanism (GTSM) is a mechanism that protects the service by
checking whether the TTL value in the IP header is within the pre-defined range. The prerequisites
for using GTSM are as follows:
 The TTL of normal packets between routers is determined.
 The TTL value of packets can hardly be modified.
LDP GTSM refers to GTSM implementation over LDP.
To protect the router against attacks, GTSM checks the TTL in a packet to verify it. GTSM for LDP
is applied to LDP packets between neighbors or adjacent (based on a fixed number of hops) routers.
The TTL range is preset on each router for packets from other routers and GTSM is enabled. If the
TTL of an LDP packet received by a router configured with LDP is out of the TTL range, the packet
is considered invalid and is discarded. This protects the upper-layer protocols.
13.2.11 LDP Extension for Inter-Area LSP
This feature enables LDP to establish inter-area LDP LSPs to provide tunnels that traverse the
public network.
Figure 13-2-10 Networking topology for LDP extension for inter-area LSP
As shown in Figure 13-2-10, there are two IGP areas: Area 10 and Area
20.
In the routing table of LSRD at the edge of Area 10, two host routes are reachable to LSRB and
LSRC. You can use IS-IS to aggregate the two routes to one route to 1.3.0.0/24 and send this route to
Area 20 to prevent a large number of routes from occupying too many resources on the LSRD.
Consequently, there is only one aggregated route (1.3.0.0/24) but not 32-bit host routes in LSRA's
routing table. By default, when establishing LSPs, LDP searches the routing table for the route that
exactly matches the FEC in the received Label Mapping message. Figure 13-2-10 shows routing
entry information of LSRA and routing information carried in the FEC, as shown in Table 13-2-4.
Table 13-2-4 Routing entry information of LSRA and routing information carried in the FEC
Routing Entry Information of FEC

LSRA
1.3.0.0/24 1.3.0.1/32
1.3.0.2/32
LDP establishes liberal LSPs, not inter-area LDP LSPs, for aggregated routes. In this situation, LDP
cannot provide required backbone network tunnels for VPN services.
Therefore, in the situation shown in Figure 13-2-10, configure LDP to search for routes according
to the longest match rule for establishing LSPs. There is already an aggregated route to 1.3.0.0/24 in
the routing table of LSRA. When LSRA receives a Label Mapping message (such as the carried
FEC is
1.3.0.1/32) from Area 10, LSRA searches for a route according to the longest match rule defined in
RFC 5283. Then, LSRA finds information about the aggregated route to 1.3.0.0/24, and uses the
outbound interface and next hop of this route as those of the route to 1.3.0.1/32. In this manner,
LDP can establish inter-area LDP LSPs.
13.3 BGP/MPLS IP VPN
13.3.1 Concepts
Site
"Site" is a frequently used term in VPN technology.
 A site is a group of IP systems that have mutual IP interconnectivity without the use of the SP
network.
Figure 13-3-1 shows an example of sites. In the networks on the left side, the headquarters of
company X in city A is a site, and the branch of company X in city B is another site. IP
devices can communicate within each site without using the SP network.
Figure 13-3-1 Diagram of sites
 Sites are configured based on the topologies between devices but not their geographic
locations although the devices in a site are geographically adjacent to each other in most cases.
Two geographically separated IP systems can also compose a site if they are connected
through private lines and can communicate without the use of the SP network.
On the right side of Figure 13-3-1, the branch network in city B connects to the headquarters
network in city A through private lines instead of an SP network. The branch network and
the headquarters network compose a site.
 The devices in a site may belong to multiple VPNs. That is, a site may belong to more than one
VPN.
As shown in Figure 13-3-2, the decision-making department of company X in city A (Site A) is
allowed to communicate with the R&D department in city B (Site B) and the financial
department in city C (Site C). Site B and Site C are not allowed to communicate with each
other. In this case, two VPNs, VPN1 and VPN2, can be established. Site A and Site B belong to
VPN1; Site A and Site C belong to VPN2. Site A belongs to two VPNs.
Figure 13-3-2 One site belonging to multiple VPNs
 A site connects to an SP network through CE devices. A site may have more than one CE
device, but a CE device belongs to only one site.
The following are recommended CE devices for different types of
sites: If a site is a host, the host is the CE device of the site.
If a site is a subnet, switches are used as CE devices.
If a site has multiple subnets, routers are used as CE devices.
Sites connected to the same SP network can be grouped into different sets using policies. Only
sites that belong to the same set can communicate with each other through the SP network.
Such a set is a VPN.
Address Space Overlapping
As a private network, each VPN manages an address space. Address spaces of different VPNs may
overlap. For example, if both VPN1 and VPN2 use addresses on the network segment
10.110.10.0/24, their address spaces overlap.
VPNs can use overlapping address spaces in the following situations:
 Two VPNs do not cover the same site.

 Two VPNs cover the same site, but the devices in the site do not need to communicate with
the devices using overlapping address spaces in the VPNs.
VPN Instance
In BGP/MPLS IP VPN implementation, routes of different VPNs are isolated by VPN
instances. A PE device establishes and maintains a VPN instance for each directly connected
site. A VPN
instance contains VPN member interfaces and routes of the corresponding site. Specifically,
information in a VPN instance includes the IP routing table, label forwarding table, interface bound to
the VPN instance, and VPN instance management information. VPN instance management
information includes the route distinguisher (RD), route filtering policy, and member interface list of
the VPN instance.
The relationships between VPNs, sites, and VPN instances are as follows:
 A VPN consists of multiple sites. A site may belong to multiple VPNs.
 A site is associated with a VPN instance on a PE device. A VPN instance integrates the
VPN members and routing policies of associated sites. Multiple sites compose a VPN based
on the rules of the VPN instance.
 VPN instances are not mapped to VPNs on a one-to-one basis, whereas VPN instances
are mapped to sites on a one-to-one basis.
A VPN instance is also called a VPN routing and forwarding table (VRF). A PE device has multiple
routing and forwarding tables, including a public routing and forwarding table and one or more
VRFs. Figure 13-3-3 shows VPN instances.
Figure 13-3-3 VPN instances

A public routing and forwarding table and a VRF differ in the following aspects:
 A public routing table contains IPv4 routes of all the PE and P devices. The routes are
static routes or dynamic routes generated by routing protocols on the backbone network.
1210
 A VPN routing table contains routes of all sites that belong to the VPN instance. The routes
are obtained through the exchange of VPN routing information between PE devices or
between CE and PE devices.
 A public forwarding table contains the minimum forwarding information extracted from the
public routing table according to route management policies. A VPN forwarding table
contains the minimum forwarding information extracted from the corresponding VPN routing
table.
The VPN instances on a PE device are independent of each other and maintain a VRF
independent of the public routing and forwarding table.
Each VPN instance can be considered as a virtual device, which maintains an

independent address space and has one or more interfaces connected to the physical
device.
RD and VPN-IPv4 Address
Traditional BGP cannot process VPN routes with overlapping address spaces. For example, VPN1 and
VPN2 use addresses on the network segment 10.110.10.0/24, and they each advertise a route to this
network segment. The local PE device can identify the routes based on VPN instances. However,
when the routes are advertised to the remote PE device, BGP selects only one of the two routes
because load balancing is not performed between routes of different VPNs. The other route is lost.
To address the preceding problem, the PE devices use Multiprotocol Extensions for BGP-4 (MP-BGP)
to advertise VPN routes and use the VPN-IPv4 address family.
A VPN-IPv4 address has 12 bytes. The first eight bytes represent the RD, and the last four
bytes represent the IPv4 address prefix, as shown in Figure 13-3-4.
Figure 13-3-4 VPN-IPv4 address structure

RDs distinguish the IPv4 prefixes with the same address space. IPv4 addresses with RDs are VPN-
IPv4 addresses (VPNv4 addresses). After receiving IPv4 routes from a CE device, a PE device
converts the routes into globally unique VPN-IPv4 routes and advertises the routes on the public
network.
The RD format enables SPs to allocate RDs independently. When CE devices are dual-homed to
PE devices, RD must be globally unique to ensure correct routing. As shown in Figure 13-3-5, a
CE device is dual-homed to PE1 and PE2. PE1 also functions as a route reflector (RR).
Figure 13-3-5 Networking diagram of CE dual-homing
PE1 is an edge device of the backbone network and advertises a VPN-IPv4 route with the IPv4 prefix
10.1.1.1/8 to PE3. PE1 also functions as an RR and reflects a VPN-IPv4 route with the IPv4 prefix
10.1.1.1/8 from PE2 to PE3.
 If the VPN has the same RD on PE1 and PE2, PE3 retains only one VPN-IPv4 route to
10.1.1.1/8 (PE3 -> PE1 -> CE) because the two routes have the same destination address.
 When the direct link between PE1 and CE fails, PE3 deletes the VPN-IPv4 route to
10.1.1.1/8.
As a result, VPN data destined for 10.1.1.1/8 cannot be forwarded to the destination.
Actually, PE3 has another route to 10.1.1.1/8, PE3 -> PE2 -> CE.
 If the VPN has different RDs on PE1 and PE2, the VPN-IPv4 routes to 10.1.1.1/8 received by
PE3 from PE1 have different destination addresses. Therefore, PE3 stores both the two
VPN-IPv4 routes. When any link between PE1 and CE fails, PE3 deletes the corresponding
route and reserves the other one. Data destined for 10.1.1.1/8 can still be correctly forwarded.
VPN Target
A VPN target, also called the route target (RT), is a 32-bit BGP extension community
attribute. BGP/MPLS IP VPN uses VPN targets to control the advertisement of VPN routes.
A VPN instance is associated with one or more VPN target attributes. VPN target attributes are
divided into the following types:
 Export target: After a PE device learns the IPv4 routes from directly connected sites, it
converts the routes to VPN-IPv4 routes and sets the export target attribute for those routes. The
export target attribute is advertised with the routes as a BGP extended community attribute.
 Import target: After a PE device receives VPN-IPv4 routes from other PE devices, it checks the
export target attribute of the routes. If the export target is the same as the import target of a
VPN instance on the local PE device, the local PE device adds the route to the VPN routing
table.
BGP/MPLS IP VPN uses VPN targets to control the advertisement and reception of VPN routing
information between sites. VPN export targets are independent of import targets. An export target
and an import target can be configured with multiple values to implement flexible VPN access
control and VPN networking.
For example, if the import target of a VPN instance contains 100:1, 200:1, and 300:1, any route
with the export target of 100:1, 200:1, or 300:11 is added to the routing table of the VPN instance.
13.3.2 BGP/MPLS IP VPN Principles
This section describes BGP/MPLS IP VPN principles covering the following:
 VPN Label Allocation
 VPN Route Cross
 Public Network Tunnel Iteration
 VPN Route Selection Rules
 Route Advertisement in BGP/MPLS IP VPN
 Packet Forwarding in BGP/MPLS IP VPN
VPN Label Allocation
Before advertising private routes to other PE devices on the backbone network through MP-BGP, a
PE device must assign MPLS labels (VPN label) for the private network routes. The packets
transmitted over the backbone network carry MPLS labels.
A PE device allocates MPLS labels in either of the following ways:
 One label per route
By default, a PE device allocates a label to each route in a VRF. When a large number of routes
exist on the network, the Incoming Label Map (ILM) maintains a large number of entries,
which requires 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, saving labels.
NOTE:
MP-BGP can allocate labels to private network routes only after MPLS is enabled on the PE device.
VPN Route Cross
The routes exchanged between two PE devices through MP-BGP are VPNv4 routes. A PE
device checks received VPNv4 routes and drops the following routes:
 VPNv4 routes with next hops unreachable
 VPNv4 routes received from an RR and contain the cluster_id of the PE device in the cluster_list
 VPNv4 routes that are denied by the BGP routing policy
Then the PE device matches the remaining routes with the import target attributes of VPN
instances. The matching process is called VPN route cross.
Some routes sent from local CE devices belong to different VPNs. The PE device also matches these
routes with the import targets of local VPN instances if these routes have reachable next hops or can
be iterated. The matching process is called local VPN route cross. For example, CE1 resides in a site
of VPN1, and CE2 resides in a site of VPN2. Both CE1 and CE2 connect to PE1. When PE1 receives
routes of VPN1 from CE1, PE1 also matches the routes with the import target of the instance of
VPN2.
NOTE:
To correctly forward a packet, a BGP device must find out a directly reachable address, through
which the packet can be forwarded to the next hop in the routing table. The route to the directly
reachable address is called the dependent route, because BGP guides packet forwarding based on the
route. The process of finding a dependent route based on the next-hop address is called route iteration.
Public Network Tunnel Iteration
To transmit traffic of private networks across a public network, tunnels need to be established on the
public network. After VPN route cross is complete, PE devices perform route iteration based on
destination IPv4 prefixes to find the appropriate tunnels (except for the local cross routes). Then
tunnel iteration is performed. The routes are injected into the VPN routing table only after the tunnel
iteration succeeds. The process of iterating routes to corresponding tunnels is called tunnel iteration.
After the tunnel iteration succeeds, the tunnel IDs are reserved for subsequent packet forwarding.
A tunnel ID identifies a tunnel. In VPN packet forwarding, the PE devices search for
corresponding tunnel according to the tunnel ID.
VPN Route Selection Rules
Not all the cross routes processed by tunnel iteration are installed to VPN routing tables. Similarly,
not all the routes received from the local CE devices and the local cross routes are injected into VPN
routing tables.
When multiple routes to the same destination are available, a PE device selects one route based on
the following rules if load balancing is not configured:
 If a route received from a local CE device and a cross route are destined to the same
destination, the PE device selects the route received from the local CE device.
 If a local cross route and a cross route received from another PE device are destined for the
same destination, the PE device selects the local cross route.
If load balancing is configured, the PE device selects one route based on the following rules:
 Preferentially selects the route from the local CE device. When one route from the local CE
device and multiple cross routes exist, the PE device selects the route from the local CE device.
 Performs load balancing between the routes from the local CE device or between the cross routes.
The PE device does not perform load balancing between the routes from the local CE device
and the cross routes.
 The AS_Path attributes of the routes participating in load balancing must be the same.
Route Advertisement in BGP/MPLS IP VPN
In basic BGP/MPLS IP VPN application, CE and PE devices are responsible for advertising
VPN routing information, whereas P devices only need to maintain the routes of the backbone
network without knowing VPN routing information. Generally, PE devices maintain all VPN
routes.
VPN route advertisement goes through three phases: from the local CE device to the ingress PE
device, from the ingress PE device to the egress PE device, and from the egress PE device to the
remote CE device. After the whole route advertisement process is complete, the local and remote CE
devices have reachable routes to each other, and VPN routing information can be advertised on the
backbone network.
The following describes the three phases of route advertisement in detail.
 From the local CE device to the ingress PE device
After a neighbor or peer relationship is set up between a CE device and the directly connected PE
device, the CE device advertises the local IPv4 routes to the PE device. The CE and PE devices
can use static routes, the Routing Information Protocol (RIP), the Open Shortest Path First
(OSPF) protocol, the Intermediate System-to-Intermediate System (IS-IS) protocol, or BGP. No
matter which routing protocol is used, the routes advertised by the CE device to the PE device are
standard IPv4 routes.
 From the ingress PE device to the egress PE device
 After learning VPN routes from a CE device, the egress PE device adds RDs to
these standard IPv4 routes. The routes are changed into VPN-IPv4 routes.
 The ingress PE device advertises the MP-BGP Update messages containing VPN-
IPv4 routes to the egress PE device. The Update messages contain Export VPN
targets and MPLS labels.
 When the egress PE device receives the VPN-IPv4 routes and if the next hops are
reachable, it performs VPN route cross, tunnel iteration, and route selection to
determine whether to inject the routes into the VRF. For the routes added to the VPN
routing table, the local PE stores the tunnel IDs and MPLS labels carried in MP-BGP
Update messages for subsequent packet forwarding.
 From the egress PE device to the remote CE device
The remote CE device can learn VPN routes from the egress PE device through static routes,
RIP, OSPF, IS-IS, or BGP. The route advertisement from the egress PE device to the remote CE
device is the same as that from the local CE device to the ingress PE device. The
routes advertised by the egress PE device to the remote CE device are standard IPv4
routes.
Figure 13-3-6 shows an example of route advertisement from CE2 to CE1. In this example, BGP
runs between CE and PE devices, and the tunnels are LSP tunnels.
Figure 13-3-6 Route advertisement from CE2 to CE1
1. IGP routes are imported into the BGP IPv4 unicast address family of CE2.
2. CE2 advertises an EBGP Update message with routing information to the egress PE device.
After receiving the message, the egress PE device converts the route to a VPN-IPv4 route,
and then installs the route to the VPN routing table.
3. The egress PE device allocates an MPLS label to the route. Then it adds the label and VPN-
IPv4 routing information to the NLRI field and the export target to the extended
community attribute field of the MP-IBGP Update message. After that, the egress PE
device sends the Update message to the ingress PE device.
4. After receiving the message, the ingress PE device performs VPN route cross. After the
VPN route cross succeeds, the ingress PE device performs tunnel iteration based on the
destination IPv4 address to find the appropriate tunnel. If the tunnel iteration succeeds, the
ingress PE device stores the tunnel ID and label, and then adds the route to the VPN routing
table of the VPN instance.
5. The ingress PE device advertises a BGP Update message with the route to CE1. The
advertised route is an IPv4 route.
6. After receiving the route, CE1 installs the route to the BGP routing table. CE1 can import
the route to the IGP routing table by importing BGP routes to IGP.
To ensure that CE1 and CE2 can communicate, CE1 also needs to advertise routes to CE2, of
which the process is similar to the preceding process.
Packet Forwarding in Basic BGP/MPLS IP VPN
In basic BGP/MPLS IP VPN applications (excluding inter-AS VPN), VPN packets are forwarded
with double labels:
 Outer label (public network label): It is swapped on the backbone network and identifies an
LSP from a PE device to a remote PE device. The outer label enables VPN packets to reach the
remote PE device through the LSP.
 Inner label (VPN label): It is used when VPN packets are sent from the remote PE device to a
CE device. The label identifies the site (or more specifically, the CE) to which VPN packets are
sent. The remote PE device finds the outbound interface for VPN packets according to the inner
label.
If two sites of a VPN connect to the same PE device, the PE device only needs to know how VPN
packets can reach the remote CE device.
Figure 13-3-7 shows an example packet forwarding from CE1 to CE2. In the figure, I-L indicates
an inner label, and O-L indicates an outer label.
Figure 13-3-7 Forwarding of a VPN packet from CE1 to CE2

1. CE1 sends a VPN packet.
2. After receiving the packet on the interface bound to a VPN instance, the ingress PE
device processes the packet as follows:
 Searches for the corresponding VPN forwarding table based on the RD of the VPN
instance.
 Matches the destination IPv4 prefix to find the corresponding tunnel ID.
 Adds I-L to the packet and finds the tunnel based on the tunnel ID.
 Sends the packet through the tunnel and adds O-L1 to the packet.
Then the packet travels across the backbone network with double MPLS labels. Each P
device on the backbone network swaps the outer label of the packet.
3. After receiving the packet with double labels, the egress PE device delivers the packet to
MPLS for processing. MPLS pops the outer label. In this example, the final outer label of the
packet is O-L2. If the Penultimate Hop Popping (PHP) is configured, the outer label is popped
on the hop before the egress PE device, and the egress PE device receives the packet with only
the inner label.
4. At this time, the egress PE device can only identify the inner label. Finding the label is at
the bottom of the label stack, the egress PE device pops the inner label.
5. The egress PE device sends the packet to CE2. At this time, the packet is a pure IP packet.
The packet is successfully transmitted from CE1 to CE2. CE2 transmits the packet to
the destination according to the IP forwarding process.
13.3.3 Basic Networking
Intranet VPN
In the simplest networking, all the users in a VPN form a closed user group. The users within the
VPN can transmit packets to each other but cannot communicate with users outside the VPN. This
networking mode is called an intranet VPN. The sites within an intranet VPN usually belong to the
same organization.
In intranet VPN networking, each VPN is allocated a VPN target as the export target and import
target. The VPN target of a VPN cannot be used by other VPNs.
Figure 13-3-8 Intranet VPN networking
As shown in Figure 13-3-8, PE devices allocate the VPN target 100:1 to VPN1 and the target 200:1
to VPN2. The two sites in the same VPN can communicate with each other, whereas sites in different
cannot communicate.
Extranet VPN
If users in a VPN need to access some sites of another VPN, the extranet networking mode can be
used. In extranet networking, if a VPN needs to access a shared site, its export target must be in the
import
target list of the VPN instance covering the shared site, and its import target must be contained in
the export target list of the VPN instance covering shared site.
Figure 13-3-9 Extranet VPN networking
As shown in Figure 13-3-9, VPN1 and VPN2 can access Site3 of VPN1.
 PE3 can receive the VPN-IPv4 routes advertised by PE1 and PE2.
 PE1 and PE2 can receive the VPN-IPv4 routes advertised by PE3.
 Site1 and Site3 of VPN1 can communicate with each other. Site2 of VPN2 and Site3 of
VPN1 communicate with each other.
 PE3 does not advertise the VPN-IPv4 routes learned from PE1 to PE2 and does not advertise
the VPN-IPv4 routes learned from PE2 to PE1. Therefore, Site1 of VPN1 and Site2 of VPN2
Hub and Spoke
If a central access control device needs to be deployed to control communication between VPN
users, the Hub and Spoke networking can be used. The site with the access control device
deployed is the Hub site, and other sites are Spoke sites. The following devices are used in the
Hub and Spoke networking:
 Hub-CE: deployed in the Hub site and connected to the VPN backbone network.
 Spoke-CE: deployed in a Spoke site and connected to the VPN backbone network.
 Hub-PE: deployed on the VPN backbone network and connected to the Hub site.
 Spoke-PE: deployed on the VPN backbone network and connected to a Spoke site.
A Spoke site advertises routes to the Hub site, and then the Hub site advertises the routes to
other Spoke sites. No route is advertised directly between all the Spoke sites. The Hub site
controls communication between all Spoke sites.
In the Hub and Spoke networking, two VPN targets are configured to stand for Hub and Spoke
respectively. Figure 13-3-10 shows the Hub and Spoke networking.
Figure 13-3-10 Hub and Spoke networking

The VPN targets of a PE device must comply with the following rules:
 The export target and import target of a Spoke-PE device are Spoke and Hub respectively.
The import target of any Spoke-PE device cannot be the same as the export target of any other
Spoke-PE device.
 A Hub-PE device requires two interfaces or sub-interfaces.
 One interface or sub-interface receives routes from Spoke-PE devices. The import target
of the VPN instance on the interface is Spoke.
 The other interface or sub-interface advertises routes to Spoke-PE devices. The

export target of the VPN instance on the interface is Hub.
As shown in Figure 13-3-10, the Hub site controls communication between Spoke sites. The
arrow lines show the process of advertising a route from Site2 to Site1.
 The Hub-PE device can receive the VPN-IPv4 routes advertised by all the Spoke-PE devices.
 All the Spoke-PE devices can receive the VPN-IPv4 routes advertised by the Hub-PE.
 The Hub-PE device advertises the routes learned from the Spoke-PE devices to the Hub-CE
device, and advertises the routes learned from the Hub-CE device to all the Spoke-PE devices.
In this way, the Spoke sites can access each other through the Hub site.
 The import target of any Spoke-PE device is different from the export targets of other Spoke-PE
devices. Therefore, any two Spoke-PE devices do not directly advertise VPN-IPv4 routes to
each other. The Spoke sites cannot directly communicate with each other.

1210
13.3.4 VPN FRR
Background
As networks develop rapidly, the end-to-end convergence time upon a fault on a carrier network has
been used as an indicator to measure bearer network performance. MPLS TE Fast Reroute (FRR) is
one of the commonly used fast switching technologies. This solution sets up an end-to-end TE
tunnel between two PE devices and uses a backup LSP to protect the primary LSP. When either PE
device detects that the primary LSP is unavailable because of a node or link failure, the PE device
switches traffic to the backup LSP.
MPLS TE FRR can trigger fast switching when a link or node between the ingress and egress PE
devices. However, if the ingress or egress PE device fails, services can only be restored through
end-to-end route convergence and LSP convergence. The convergence time is closely related to the
number of routes inside an MPLS VPN and the number of LSP hops on the bearer network. The
more VPN routes, the longer the convergence time, and the more traffic is lost.
VPN FRR implements fast switching based on VPN routes. Forwarding entries pointing to the active
and standby PE devices are configured on a remote PE device. Working with a fast fault detection
mechanism on PE devices, VPN FRR can reduce end-to-end convergence time upon failures on an
MPLS VPN where a CE is dual-homed to PE devices. In VPN FRR, convergence time depends only
on the time required to detect the failure of the remote PE and change tunnel status. Service
convergence time does not increase even when a large number of VPN routes exist on the network.
Implementation
Figure 13-3-11 Typical VPN FRR networking

As shown in Figure 13-3-11, CE1 communicates with CE2 through Link A when PE2 is
working properly. If PE2 is Down, CE1 communicates with CE2 through Link B.
 In traditional BGP/MPLS VPN implementation, both PE2 and PE3 advertise the routes destined
for CE2 to PE1, and allocate private network labels. PE1 selects the optimal VPNv4 route from
an MP-BGP neighbor. In this example, PE1 selects the route advertised by PE2 and saves only
routing information advertised by PE2 (including the IP prefix, inner label, and selected LSP),
in the forwarding table of the forwarding engine.
 When PE2 fails, PE1 detects the fault of PE2 (the BGP peer relationship becomes Down or the
outer LSP is unavailable). Then PE1 selects the route advertised by PE3 and updates the
forwarding entry to complete the end-to-end convergence. Before PE1 delivers the forwarding
entry matching the route advertised by PE3, CE1 cannot communicate CE2 for a certain
period because the end point of the outer LSP, PE2, is Down. This results in interruption of
end-to-end services.
 VPN FRR is an improvement on the traditional reliability technology. VPN FRR enables PE1 to
add the optimal route advertised by PE2 and the second optimal route advertised by PE3 to a
forwarding entry. The optimal route is used for traffic forwarding, and the second optimal route
is used as a backup route.
 When a fault occurs on PE2, PE1 detects that the outer tunnel between PE1 and PE2 is
unavailable. Then PE1 sets the flag in the LSP status table to unavailable and delivers the flag to
the forwarding engine. After selecting a forwarding entry, the forwarding engine examines the
status of the LSP corresponding to the forwarding entry. If the LSP is unavailable, the
forwarding engine uses the forwarding information of the second-best route in the local
forwarding entry to forward packets. Packets are tagged the inner label allocated by PE3 and are
transmitted to PE3 over the outer LSP between PE1 and PE3. PE3 then forwards the packets to
CE2. In this manner, fast end-to-end convergence is implemented when PE2 fails.
VPN FRR performs fast switching based on inner labels. Outer tunnels can be LDP LSPs or RSVP
TE tunnels. When the forwarding engine detects that the outer tunnel is unavailable, it triggers fast
switching based on the inner labels.
13.3.5 VPN GR
Definition
VPN GR is the application of the GR technology on a VPN. VPN GR ensures uninterrupted

VPN traffic forwarding when an active/standby switchover is performed on a device
transmitting VPN services. The purposes of VPN GR are as follows:
 Reduce the impact of route flapping on the entire network during the switchover.
 Reduce lost packets so that the packet loss ratio of VPN traffic decrease to almost 0%.
 Reduce the impact on important VPN services.
 Reduce single-point failures on PE or CE devices to improve VPN network reliability.
Prerequisites for VPN GR
The device where an active/standby switchover occurs and its connected devices must have GR
capabilities. They must retain forwarding information of all VPN routes within a period to
ensure uninterrupted VPN traffic forwarding. This requires that:
 The devices support IGP GR and BGP GR.
 The devices support LDP GR. If TE tunnels are deployed on the backbone network, these
devices must support RSVP GR.
Implementation
On a common L3VPN network, active/standby switchovers may occur on any PE, CE, or P device.
 Active/standby switchover on a PE device
The GR process on a PE device is the same as that on the GR restarter in IGP GR, LDP GR, or
BGP GR.
When a CE device connected to the PE device detects the restart of the PE device, the CE device
acts the same as the GR helper IGP GR or BGP GR and retains all IPv4 routes in a certain
period.
When the P device connected to the PE device detects the restart of the PE device, the P
device acts the same as the GR helper in IGP GR, LDP GR, or BGP GR and retains all public
IPv4 routes in a certain period.
When other PE devices (including those functioning as ASBRs) and the RR reflecting
VPNv4 routes detect the restart of the PE device, they act the same as the GR helper in BGP
GR, and they retain all the public IPv4 routes and VPNv4 routes in period.
 Active/standby switchover on a P device
The GR process on a P device is the same as that on the GR restarter in IGP GR, LDP GR, or
BGP GR.
When a P or PE device connected to this P device detects the restart, the P or PE device acts
the same as the GR helper in IGP GR or BGP GR and retains all the public IPv4 routes in a
certain period.
 Active/standby switchover on a CE device
The GR process on a CE device is the same as that on the GR restarter in IGP GR or BGP
GR. When the PE device connected to the CE device detects the restart of the CE device, the
PE
device acts the same as the GR helper in IGP GR or BGP GR and retains all the private
IPv4 routes in a certain period.
For details about IGP GR and BGP GR, see the description of GR in the Feature Description -
IP Routing.
For details about LDP GR, see "LDP GR" in the Feature Description - MPLS.
13.3.6 VPN NSR
As networks develop fast, the demand for the triple-play services of the Public Switched Telephone
Network (PSTN), cable TV network, and Internet becomes more and more stringent. Carriers pose
high requirements for reliability on IP networks. Non-Stop Routing (NSR), as a High Availability
(HA) solution, is introduced to meet their requirements.
NSR ensures that the control plane of a neighbor is unaware of the fault on a control plane of the
local device with double control planes. In this process, the neighbor relationships set up through
routing protocols, MPLS, and other protocols are not interrupted.
As an HA solution, NSR eliminates or minimizes impact of device failures on user services.
When an active/standby switchover occurs on the local device, VPN NSR ensures continuous
forwarding and advertisement of VPN routes. The neighbor relationships are not affected by the
switchover, and neighbors are not aware of the switchover. This ensures uninterrupted transmission
of VPN services.
13.4 Configuration Examples
13.4.1 Example for Configuring Static LSPs
As shown in Figure 13-4-1, on a simple, stable, and small-scale network, LSRA, LSRB, LSRC, and
LSRD are the backbone devices. A public network tunnel needs to be established on the backbone
network for transmitting L2VPN services. The path from LSRA to LSRD is
LSRA→LSRB→LSRD, and the path from LSRD and LSRA is LSRD→LSRC→LSRA.
Figure 13-4-1 Networking diagram of establishing static LSPs
Configuring static LSPs can meet the preceding requirements.
Configure two static LSPs: LSRA→LSRB→LSRD (LSRA is the ingress node, LSRB is the transit
node, and LSRD is the egress node); LSRD→LSRC→LSRA (LSRD is the ingress node, LSRC is
the transit node, and LSRA is the egress node)
1. Configure MPLS to establish public network LSPs on the backbone network. To implement the
MPLS function, enable global MPLS capability on all nodes and interfaces.
2. Configure static LSPs and establish public network LSPs for transmitting L2VPN services.
Perform the following steps:
a. Configure the destination IP address, next hop, value of the outgoing label for the LSP
on the ingress node.
b. Configure the incoming interface, value of the incoming label equivalent to the
outgoing label of the last node, and next hop and value of the outgoing label of the LSP
on the transit node.
c. Configure the incoming interface and value of the incoming label equivalent to
the outgoing label of the last node of the LSP on the egress node.
Procedure

# Configure LSRA.
[Huawei] sysname LSRA
[LSRA] interface loopback 1
[LSRA-LoopBack1] ip address 1.1.1.9 32
[LSRA-LoopBack1] quit
[LSRA] interface gigabitethernet 1/0/0
[LSRA-GigabitEthernet1/0/0] ip address 10.1.1.1 24
[LSRA-GigabitEthernet1/0/0] quit
The configurations of LSRB, LSRC, and LSRD are similar to that of LSRA, and are
not mentioned here.
2. Configure OSPF to advertise the network segments that the interfaces are connected to and
the host route of the LSR ID.
# Configure LSRA.
[LSRA] ospf 1
[LSRA-ospf-1] area 0
[LSRA-ospf-1-area-0.0.0.0] network 1.1.1.9 0.0.0.0
[LSRA-ospf-1-area-0.0.0.0] quit
[LSRA-ospf-1] quit
# Configure LSRB.
[LSRB] ospf 1
[LSRB-ospf-1] area 0
[LSRB-ospf-1-area-0.0.0.0] network 2.2.2.9 0.0.0.0
[LSRB-ospf-1-area-0.0.0.0] quit
[LSRB-ospf-1] quit
# Configure LSRC.
[LSRC] ospf 1
[LSRC-ospf-1] area 0
[LSRC-ospf-1-area-0.0.0.0] network 3.3.3.9 0.0.0.0
[LSRC-ospf-1-area-0.0.0.0] quit
[LSRC-ospf-1] quit
# Configure LSRD.
[LSRD] ospf 1
[LSRD-ospf-1] area 0
[LSRD-ospf-1-area-0.0.0.0] network 4.4.4.9 0.0.0.0
[LSRD-ospf-1-area-0.0.0.0] quit
[LSRD-ospf-1] quit
After the configuration is complete, run the display ip routing-table command on each
node, and you can view that the nodes learn routes from each other.
Use the command output on LSRA as an example.
[LSRA] display ip routing-table

------------------------------------------------------------------------------
1.1.1.9/32 Direct 0 0 D 127.0.0.1 LoopBack1
2.2.2.9/32 OSPF 10 1 D 10.1.1.2
3.3.3.9/32 OSPF 10 1 D 10.3.1.2
4.4.4.9/32 OSPF 10 2 D 10.1.1.2
OSPF 10 2 D 10.3.1.2
10.1.1.0/24 Direct 0 0 D 10.1.1.1 GigabitEthernet1/0/0

10.2.1.0/24 OSPF 10 2 D 10.1.1.2
10.4.1.0/24 OSPF 10 2 D 10.3.1.2
127.0.0.0/8
127.0.0.1/32
127.255.255.255/32
255.255.255.255/32
The next hop of the static LSP on 4.4.4.9/32 from LSRA to LSRD is determined by the
routing table. It is shown in boldface. In this example, the next hop IP address is 10.1.1.2/24.
Use the command output on LSRD as an example.
[LSRD] display ip routing-table

------------------------------------------------------------------------------
1.1.1.9/32 OSPF 10 2 D 10.2.1.1
OSPF 10 2 D 10.4.1.1
2.2.2.9/32 OSPF 10 1 D 10.2.1.1

D 10.4.1.1
3.3.3.9/32

10.1.1.0/24 OSPF 10 2 D 10.2.1.1
10.2.1.0/24
10.2.1.2/32
10.2.1.255/32
10.3.1.0/24
10.4.1.0/24
10.4.1.2/32
10.4.1.255/32
127.0.0.0/8
127.0.0.1/32
127.255.255.255/32
255.255.255.255/32
The next hop of the static LSP on 1.1.1.9/32 from LSRD to LSRA is determined by the
routing table. It is shown in boldface. In this example, the next hop IP address is 10.4.1.1/24.
3. Enable basic MPLS functions on each node.

# Configure LSRA.
[LSRA] mpls lsr-id 1.1.1.9

[LSRA] mpls
[LSRA-mpls] quit
# Configure LSRB.
[LSRB] mpls lsr-id 2.2.2.9

[LSRB] mpls
[LSRB-mpls] quit
# Configure LSRC.
[LSRC] mpls lsr-id 3.3.3.9

[LSRC] mpls
[LSRC-mpls] quit
# Configure LSRD.
[LSRD] mpls lsr-id 4.4.4.9

[LSRD] mpls
[LSRD-mpls] quit
4. Enable MPLS on each interface.
# Configure LSRA.

[LSRA-GigabitEthernet1/0/0] mpls
# Configure LSRB.
[LSRB] interface gigabitethernet 1/0/0

[LSRB-GigabitEthernet1/0/0] mpls
[LSRB-GigabitEthernet1/0/0] quit
# Configure LSRC.
[LSRC] interface gigabitethernet 1/0/0

[LSRC-GigabitEthernet1/0/0] mpls
[LSRC-GigabitEthernet1/0/0] quit
# Configure LSRD.
[LSRD] interface gigabitethernet 1/0/0

[LSRD-GigabitEthernet1/0/0] mpls
[LSRD-GigabitEthernet1/0/0] quit
[LSRD-GigabitEthernet2/0/0] mpls
5. Configure a static LSP from LSRA to LSRD.
# Configure ingress node LSRA.
[LSRA] static-lsp ingress SAtoSD destination 4.4.4.9 32 nexthop 10.1.1.2 out-label 20
# Configure transit node LSRB.
[LSRB] static-lsp transit SAtoSD incoming-interface gigabitethernet 1/0/0 in-label 20

nexthop 10.2.1.2 out-label 40
# Configure egress node LSRD.
[LSRD] static-lsp egress SAtoSD incoming-interface gigabitethernet 1/0/0 in-label 40
After the configuration is complete, run the display mpls static-lsp command on each node
to check the status of the static LSP. Use the command output on LSRA as an example.
[LSRA] display mpls static-lsp

TOTAL
UP
DOWN
Name
SAtoSD
The LSP is unidirectional, you need to configure a static LSP from LSRD to LSRA.
6. Configure a static LSP from LSRD to LSRA.
# Configure ingress node LSRD.
[LSRD] static-lsp ingress SDtoSA destination 1.1.1.9 32 nexthop 10.4.1.1 out-label 30
# Configure transit node LSRC.
[LSRC] static-lsp transit SDtoSA incoming-interface gigabitethernet 2/0/0 in-label 30

nexthop 10.3.1.1 out-label 60
# Configure egress node LSRA.
[LSRA] static-lsp egress SDtoSA incoming-interface gigabitethernet 2/0/0 in-label 60

1210
After the configuration is complete, run the display mpls static-lsp or display mpls static-
lsp verbose command on each node to check the status and detailed information about the
static
LSP. Use the command output on LSRD as an example.
[LSRD] display mpls static-lsp

TOTAL :2 STATIC LSP(S)
UP
DOWN
Name
Stat
SAtoSD
Up
SDtoSA
[LSRD] display mpls static-lsp verbose
No :1
LSP-Name : SAtoSD
LSR-Type : Egress
FEC : -/-
In-Label : 40
Out-Label : NULL
In-Interface : GigabitEthernet1/0/0
Out-Interface :-
NextHop :-
Static-Lsp Type: Normal
Lsp Status : Up
No :2
LSP-Name : SDtoSA
LSR-Type : Ingress
FEC : 1.1.1.9/32
In-Label : NULL
Out-Label : 30
In-Interface :-
Out-Interface : GigabitEthernet2/0/0
NextHop : 10.4.1.1
Lsp Status : Up
Run the ping lsp ip 1.1.1.9 32 command on LSRD. The command output shows that the static
LSP can be pinged.
Run the ping lsp ip 4.4.4.9 32 command on LSRA. The command output shows that the static
LSP can be pinged.
Configuration Files
 Configuration file of LSRA
#
sysname LSRA
#
mpls lsr-id 1.1.1.9
mpls
#
ip address 10.1.1.1 255.255.255.0
mpls
#
ip address 10.3.1.1 255.255.255.0
mpls
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 1.1.1.9 0.0.0.0
network 10.1.1.0 0.0.0.255
network 10.3.1.0 0.0.0.255
#
static-lsp ingress SAtoSD destination 4.4.4.9 32 nexthop 10.1.1.2 out-label
20 static-lsp egress SDtoSA incoming-interface GigabitEthernet2/0/0 in-
label 60
#
return
 Configuration file of LSRB
#
sysname LSRB
#
mpls lsr-id 2.2.2.9
mpls
#
ip address 10.1.1.2 255.255.255.0
mpls
#
ip address 10.2.1.1 255.255.255.0
mpls
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 2.2.2.9 0.0.0.0
network 10.1.1.0 0.0.0.255
network 10.2.1.0 0.0.0.255
#
static-lsp transit SAtoSD incoming-interface GigabitEthernet1/0/0 in-label 20 nexthop
10.2.1.2 out-label 40
#
return
 Configuration file of LSRC
#
sysname LSRC
#
mpls lsr-id 3.3.3.9
mpls
#
ip address 10.3.1.2 255.255.255.0
mpls
#
ip address 10.4.1.1 255.255.255.0
mpls
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 3.3.3.9 0.0.0.0
network 10.3.1.0 0.0.0.255
network 10.4.1.0 0.0.0.255
#
static-lsp transit SDtoSA incoming-interface GigabitEthernet2/0/0 in-label 30 nexthop
10.3.1.1 out-label 60
#
return
 Configuration file of LSRD
#
sysname LSRD
#
mpls lsr-id 4.4.4.9
mpls
#
ip address 10.2.1.2 255.255.255.0
mpls
#
ip address 10.4.1.2 255.255.255.0
mpls
#
interface LoopBack1
ip address 4.4.4.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 4.4.4.9 0.0.0.0
network 10.2.1.0 0.0.0.255
network 10.4.1.0 0.0.0.255
#
static-lsp egress SAtoSD incoming-interface GigabitEthernet1/0/0 in-label
40 static-lsp ingress SDtoSA destination 1.1.1.9 32 nexthop 10.4.1.1 out-
label 30
#
return
13.4.2 Example for Configuring Static BFD to Monitor Static LSPs
As shown in Figure 13-4-2, static LSPs LSP1 and LSP2 are configured between PE1 and PE2.
LSP1 passes through P1, and LSP2 passes through P2. It takes an interface a long period to detect a
fault on the connected link. The connectivity check on LSP1 is required. If a fault occurs on LSP1,
PE1 can receive the fault report within 500ms.
Figure 13-4-2 Networking diagram of establishing static LSPs
Configuring static BFD to detect static LSPs can meet the preceding requirements.
1. Only static BFD can be configured to detect static LSPs. Configure BFD on PE1 and PE2.
2. Adjust BFD parameters to enable PE1 to receive a fault report within 500 ms.
Procedure
For configuration details, refer to Example for Configuring Static LSPs.
2. Configure OSPF to advertise the network segments that the interfaces are connected to and
the host route of the LSR ID.
For configuration details, refer to Example for Configuring Static LSPs.
3. Enable basic MPLS functions on each node.
# Configure PE1.
[PE1] mpls lsr-id 1.1.1.9

[PE1] mpls
[PE1-mpls] quit
# Configure P1.
[P1] mpls lsr-id 2.2.2.9

[P1] mpls
[P1-mpls] quit
# Configure P2.

[P2] mpls
[P2-mpls] quit
# Configure PE2.

[PE2] mpls
[PE2-mpls] quit
4. Enable MPLS on each interface.
# Configure PE1.
[PE1] interface gigabitethernet 1/0/0

[PE1-GigabitEthernet1/0/0] mpls
[PE1-GigabitEthernet1/0/0] quit
# Configure P1.
[P1] interface gigabitethernet 1/0/0

[P1-GigabitEthernet1/0/0] mpls
[P1-GigabitEthernet1/0/0] quit
# Configure P2.

# Configure PE2.

5. Create a static LSP named LSP1 with PE1 being the ingress node, P1 being the transit node, and
PE2 being the egress node.
# Configure ingress node PE1.
[PE1] static-lsp ingress LSP1 destination 4.4.4.9 32 nexthop 10.1.1.2 out-label 20
# Configure transit node P1.
[P1] static-lsp transit LSP1 incoming-interface gigabitethernet 1/0/0 in-label 20 nexthop

10.2.1.2 out-label 40
# Configure egress node PE2.
[PE2] static-lsp egress LSP1 incoming-interface gigabitethernet 1/0/0 in-label 40
6. Create a static LSP named LSP2 with PE1 being the ingress node, P2 being the transit node, and
PE2 being the egress node.
# Configure ingress node PE1.
[PE1] static-lsp ingress LSP2 destination 4.4.4.9 32 nexthop 10.3.1.2 out-label 30
# Configure transit node P2.
[P2] static-lsp transit LSP2 incoming-interface gigabitethernet 1/0/0 in-label 30 nexthop

10.4.1.2 out-label 60
# Configure egress node PE2.
[PE2] static-lsp egress LSP2 incoming-interface gigabitethernet 2/0/0 in-label 60
After the configuration is complete, run the ping lsp ip 4.4.4.9 32 command on PE1.
The command output shows that the LSP can be pinged.
Run the display mpls static-lsp or display mpls static-lsp verbose command on each node to
check the status and detailed information about the static LSP. Use the command output on
PE1 as an example.
[PE1] display mpls static-lsp
TOTAL
UP
DOWN
Labe
Name
Stat
LSP1 4.4.4.9/
LSP2 4.4.4.9/
[PE1] display mpls static-lsp verbose
No :1
LSP-Name : LSP1
LSR-Type : Ingress
FEC : 4.4.4.9/32
In-Label : NULL
Out-Label : 20
In-Interface :-
NextHop : 10.1.1.2
Lsp Status : Up
No :2
LSP-Name : LSP2
LSR-Type : Ingress
FEC : 4.4.4.9/32
In-Label : NULL
Out-Label : 30
In-Interface :-
NextHop : 10.3.1.2
Lsp Status : Up
7. Configure the BFD session to detect static LSP LSP1.
# On ingress node PE1, configure a BFD session, with the local discriminator of 1, the
remote discriminator of 2, and the minimal intervals for sending and receiving packets of 100
ms. The port state table (PST) can be modified.
[PE1] bfd
[PE1-bfd] quit
[PE1] bfd pe1tope2 bind static-lsp LSP1
[PE1-bfd-lsp-session-pe1tope2] discriminator local 1
[PE1-bfd-lsp-session-pe1tope2] discriminator remote 2
[PE1-bfd-lsp-session-pe1tope2] min-tx-interval 100
[PE1-bfd-lsp-session-pe1tope2] min-rx-interval 100
[PE1-bfd-lsp-session-pe1tope2] process-pst
[PE1-bfd-lsp-session-pe1tope2] commit
[PE1-bfd-lsp-session-pe1tope2] quit
# On egress node PE2, configure a BFD session to notify PE1 of faults on the static LSP.
[PE2] bfd
[PE2-bfd] quit
[PE2] bfd pe2tope1 bind peer-ip 1.1.1.9
[PE2-bfd-session-pe2tope1] discriminator local 2
[PE2-bfd-session-pe2tope1] discriminator remote 1
[PE2-bfd-session-pe2tope1] min-tx-interval 100
[PE2-bfd-session-pe2tope1] min-rx-interval 100
[PE2-bfd-session-pe2tope1] commit
[PE2-bfd-session-pe2tope1] quit
# Run the display bfd session all verbose command on PE1 to check the configuration.
The command output shows that the BFD session on PE2 is Up.
[PE1] display bfd session all verbose

--------------------------------------------------------------------------------
Session MIndex : 257 State : Up Name : pe1tope2
--------------------------------------------------------------------------------
Local Discriminator :1 Remote Discriminator :2
Session Detect Mode : Asynchronous Mode Without Echo Function
BFD Bind Type : STATIC_LSP
Bind Session Type : Static
Bind Peer IP Address : 4.4.4.9
NextHop Ip Address : 10.1.1.2
Bind Interface :-
Static LSP name : LSP1 LSP Token : 0xe
FSM Board Id :0 TOS-EXP :7
Min Tx Interval (ms) : 100 Min Rx Interval (ms) : 100
Actual Tx Interval (ms) : 100 Actual Rx Interval (ms) : 100
Local Detect Multi :3 Detect Interval (ms) : 300
Echo Passive : Disable Acl Number :-
Destination Port : 3784 TTL :1
Proc Interface Status
WTR Interval (ms)
Active Multi
Last Local Diagnostic : Neighbor Signaled Session Down(Receive
AdminDown) Bind Application : LSPM | L2VPN | OAM_MANAGER
Session TX TmrID :- Session Detect TmrID :-
Session Init TmrID :- Session WTR TmrID :-
Session Echo Tx TmrID :-
PDT Index : FSM-0 | RCV-0 | IF-0 | TOKEN-0
Session Description :-
--------------------------------------------------------------------------------
# Run the display bfd session all verbose command on PE2 to check the configuration.

--------------------------------------------------------------------------------
Session MIndex : 512 (Multi Hop) State : Up Name : pe2tope1
--------------------------------------------------------------------------------
BFD Bind Type : Peer IP Address
Bind Interface :-
Track Interface :-
Actual Tx Interval (ms) : 100
Local Detect Multi
Echo Passive
Destination Port
WTR Interval (ms)
Active Multi
Last Local Diagnostic
Bind Application
Session TX TmrID
Session Init TmrID
Session Echo Tx TmrID
PDT Index

1210
--------------------------------------------------------------------------------
# Run the shutdown command on GE2/0/0 of P1 to simulate a fault on a static LSP.

[P1-GigabitEthernet2/0/0] shutdown
# Run the display bfd session all verbose command on PE to check the status of the BFD
session.

--------------------------------------------------------------------------------
Session MIndex : 512 (Multi Hop) State : Down Name : pe2tope1
--------------------------------------------------------------------------------
Local Discriminator :2 Remote Discriminator :
1
Session Detect Mode : Asynchronous Mode Without Echo
Function
Bind Interface :-
Track Interface :-
Actual Tx Interval (ms) : 11500 Actual Rx Interval (ms) : 11500
Destination Port : 3784 TTL : 254
Proc Interface Status : Disable Process PST :
Disable
WTR Interval (ms) :-
Active Multi :3
Last Local Diagnostic : Control Detection Time
Expired
Bind Application : No Application Bind
Session TX TmrID : 2204 Session Detect TmrID :-
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
Session MIndex : 257 State : Down Name : pe1tope2
--------------------------------------------------------------------------------
2
Function
BFD Bind Type : STATIC_LSP
Bind Interface :-
Static LSP name : LSP1 LSP Token :
0x10002
Actual Tx Interval (ms) : 13500 Actual Rx Interval (ms) :
13500
Local Detect Multi :3 Detect Interval (ms) :-
Enable
Active Multi :3
Last Local Diagnostic : Control Detection Time
Expired
Bind Application : LSPM | L2VPN | OAM_MANAGER
Session TX TmrID : 1207 Session Detect TmrID :-
--------------------------------------------------------------------------------
Configuration Files
 Configuration file of PE1
#
sysname PE1
#
bfd
#
mpls lsr-id 1.1.1.9
mpls
#
ip address 10.1.1.1 255.255.255.0
mpls
#
ip address 10.3.1.1 255.255.255.0
mpls
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
#
bfd pe1tope2 bind static-lsp LSP1
discriminator local 1
min-tx-interval 100
min-rx-interval 100
process-pst
commit
#
ospf 1
area 0.0.0.0
network 1.1.1.9 0.0.0.0
network 10.1.1.0 0.0.0.255
network 10.3.1.0 0.0.0.255
#
static-lsp ingress LSP1 destination 4.4.4.9 32 nexthop 10.1.1.2 out-label
20 static-lsp ingress LSP2 destination 4.4.4.9 32 nexthop 10.3.1.2 out-
label 30
#
return
 Configuration file of P1
#
sysname P1
#
mpls lsr-id 2.2.2.9
mpls
#
ip address 10.1.1.2 255.255.255.0
mpls
#
ip address 10.2.1.1 255.255.255.0
mpls
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 2.2.2.9 0.0.0.0
network 10.1.1.0 0.0.0.255
network 10.2.1.0 0.0.0.255
#
static-lsp transit LSP1 incoming-interface GigabitEthernet1/0/0 in-label 20 nexthop
10.2.1.2 out-label 40
#
return
#
sysname P2
#
bfd
#
mpls lsr-id 3.3.3.9
mpls
#
ip address 10.3.1.2 255.255.255.0
mpls
#
ip address 10.4.1.1 255.255.255.0
mpls
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 3.3.3.9 0.0.0.0
network 10.3.1.0 0.0.0.255
network 10.4.1.0 0.0.0.255
#
static-lsp transit LSP2 incoming-interface GigabitEthernet1/0/0 in-label 30 nexthop
10.4.1.2 out-label 60
#
return
#
sysname PE2
#
bfd
#
mpls lsr-id 4.4.4.9
mpls
#
ip address 10.2.1.2 255.255.255.0
mpls
#
ip address 10.4.1.2 255.255.255.0
mpls
#
interface LoopBack1
ip address 4.4.4.9 255.255.255.255
#
bfd pe2tope1 bind peer-ip 1.1.1.9
min-tx-interval 100
min-rx-interval 100
commit
#
ospf 1
area 0.0.0.0
network 4.4.4.9 0.0.0.0
network 10.2.1.0 0.0.0.255
network 10.4.1.0 0.0.0.255
#
static-lsp egress LSP1 incoming-interface GigabitEthernet1/0/0 in-label
40 static-lsp egress LSP2 incoming-interface GigabitEthernet2/0/0 in-
label 60
#
return
13.4.3 Example for Configuring Local LDP Sessions
As shown in Figure 13-4-3, on a complex and unstable network, LSRA, LSRB, and LSRC function
as the backbone devices. A public network tunnel needs to be established on the backbone network
for transmitting L3VPN services.
Figure 13-4-3 Networking diagram for configuring local LDP sessions
To meet the preceding requirements, configure local LDP sessions. The configuration roadmap is
as follows:
1. Enable global MPLS LDP on each LSR.
2. Configure a local LDP session and create a public network tunnel for L3VPN services. Enable
MPLS LDP on interfaces of each LSR.
Procedure

# Configure LSRA.
The configurations of LSRB and LSRC are similar to the configuration of LSRA, and are
not mentioned here.
2. Configure OSPF to advertise the network segments connecting to interfaces on each node and
to advertise the routes of hosts with LSR IDs.
# Configure LSRA.
[LSRA] ospf 1
[LSRA-ospf-1] area 0
[LSRA-ospf-1-area-0.0.0.0] quit
[LSRA-ospf-1] quit
# Configure LSRB.
[LSRB] ospf 1
[LSRB-ospf-1] area 0
[LSRB-ospf-1-area-0.0.0.0] quit
[LSRB-ospf-1] quit
# Configure LSRC.
[LSRC] ospf 1
[LSRC-ospf-1] area 0
[LSRC-ospf-1-area-0.0.0.0] quit
[LSRC-ospf-1] quit
3. Enable global MPLS and MPLS LDP on each LSR.
# Configure LSRA.
[LSRA] mpls [LSRA-
mpls] quit [LSRA]
mpls ldp [LSRA-
mpls-ldp] quit
# Configure LSRB.

[LSRB] mpls [LSRB-
mpls] quit [LSRB]
mpls ldp [LSRB-
mpls-ldp] quit
# Configure LSRC.

[LSRC] mpls [LSRC-
mpls] quit [LSRC]
mpls ldp [LSRC-
mpls-ldp] quit
4. Enable MPLS and MPLS LDP on interfaces of each LSR.
# Configure LSRA.

[LSRA-GigabitEthernet1/0/0] mpls ldp
# Configure LSRB.

[LSRB-GigabitEthernet1/0/0] mpls ldp
# Configure LSRC.

[LSRC-GigabitEthernet1/0/0] mpls ldp
# After the configuration is complete, run the display mpls ldp session command. The
command output shows that the status of local LDP sessions between LSRA and LSRB
and between LSRB and LSRC is Operational.
LSRA is used as an example.
[LSRA] display mpls ldp session
LDP Session(s) in Public Network

Codes: LAM(Label Advertisement Mode), SsnAge
Unit(DDDD:HH:MM) A '*' before a session means the session is being
deleted.
------------------------------------------------------------------------------
PeerID Status LAM SsnRole SsnAge KASent/Rcv
------------------------------------------------------------------------------
2.2.2.2:0 Operational DU Passive 000:00:22 91/91
------------------------------------------------------------------------------
TOTAL: 1 session(s) Found.
Configuration Files
#
sysname LSRA
#
mpls lsr-id 1.1.1.1
mpls
#
mpls ldp
#
ip address 10.1.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack0
ip address 1.1.1.1 255.255.255.255
#
ospf 1
area 0.0.0.0
network 1.1.1.1 0.0.0.0
network 10.1.1.0 0.0.0.255
#
return
#
sysname LSRB
#
mpls lsr-id 2.2.2.2
mpls
#
mpls ldp
#
ip address 10.1.1.2 255.255.255.0
mpls
mpls ldp
#
ip address 10.2.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack0
ip address 2.2.2.2 255.255.255.255
#
ospf 1
area 0.0.0.0
network 2.2.2.2 0.0.0.0
network 10.1.1.0 0.0.0.255
network 10.2.1.0 0.0.0.255
#
return
#
sysname LSRC
#

1210
mpls lsr-id 3.3.3.3
mpls
#
mpls ldp
#
ip address 10.2.1.2 255.255.255.0
mpls
mpls ldp
#
interface LoopBack0
ip address 3.3.3.3 255.255.255.255
#
ospf 1
area 0.0.0.0
network 3.3.3.3 0.0.0.0
network 10.2.1.0 0.0.0.255
#
return
13.4.4 Example for Configuring Static BFD to Detect LDP LSPs
On a simple and stable network shown in Figure 13-4-4, the path PE1 -> P1 -> PE2 is an LDP LSP,
while the path PE2 -> P2 -> PE1 is an IP link. It takes an interface a long period to detect a fault on
the connected link. Connectivity check on the LSP is required. If a fault occurs on the LSP, PE1 can
receive the fault report within 500 ms.
Figure 13-4-4 Networking diagram of configuring static BFD for LDP LSPs
To meet the preceding requirements, configure static BFD to detect LDP LSPs. The
configuration roadmap is as follows:
1. Configure BFD that can quickly check connectivity of the LDP LSP.
2. Configure static BFD for LDP LSP because the network is stable and IP addresses of devices
do not change. Configure BFD sessions on PE1 and PE2.
3. Adjust BFD parameters to enable PE1 to receive a fault report within 500 ms.
Procedure
# Configure PE1.
[Huawei] sysname PE1
[PE1] interface LoopBack 1
[PE1-LoopBack1] ip address 1.1.1.1 32
[PE1-LoopBack1] quit
[PE1-GigabitEthernet1/0/0] ip address 10.1.1.1 24
The configurations of P1, P2, and PE2 are similar to the configuration of PE1, and are
not mentioned here.
# Configure PE1.
[PE1] ospf 1
[PE1-ospf-1] area 0
[PE1-ospf-1-area-0.0.0.0] network 1.1.1.1 0.0.0.0
[PE1-ospf-1-area-0.0.0.0] quit
[PE1-ospf-1] quit
The configurations of P1, P2, and PE2 are similar to the configuration of PE1, and are
not mentioned here.
3. Set up an LDP LSP whose path is PE1 -> P1 -> PE2.
# Configure PE1.

[PE1] mpls
[PE1-mpls] quit
[PE1] mpls ldp
[PE1-mpls-ldp] quit
[PE1-GigabitEthernet1/0/0] mpls ldp
# Configure P1.

[P1] mpls
[P1-mpls] quit
[P1] mpls ldp
[P1-mpls-ldp] quit
[P1-GigabitEthernet1/0/0] mpls ldp
# Configure PE2.

[PE2] mpls
[PE2-mpls] quit
[PE2] mpls ldp
[PE2-mpls-ldp] quit
# Run the display mpls ldp lsp command. The command output shows that an LDP LSP
destined for 4.4.4.4/32 is set up on PE1.
[PE1] display mpls ldp lsp
LDP LSP Information

-------------------------------------------------------------------------------
DestAddress/Mask In/OutLabel UpstreamPeer NextHop
OutInterface
-------------------------------------------------------------------------------
1.1.1.1/32 3/NULL 2.2.2.2 127.0.0.1 InLoop0
*1.1.1.1/32 Liberal/3 DS/2.2.2.2
2.2.2.2/32 NULL/3 - 10.1.1.2 GE1/0/0
2.2.2.2/32 1024/3 2.2.2.2 10.1.1.2 GE1/0/0
4.4.4.4/32 NULL/1025 - 10.1.1.2 GE1/0/0
4.4.4.4/32 1022/1025 2.2.2.2 10.1.1.2 GE1/0/0
-------------------------------------------------------------------------------
TOTAL: 5 Normal LSP(s) Found.
TOTAL: 1 Liberal LSP(s) Found.
TOTAL: 0 Frr LSP(s) Found.
A '*' before an LSP means the LSP is not
established
A '*' before a Label means the USCB or DSCB is
stale A '*' before a UpstreamPeer means the session is
state A '*' before a DS means the session is stale
A '*' before a NextHop means the LSP is FRR
LSP
4. Enable global BFD on the two nodes of the detected link.
# Configure PE1.
[PE1] bfd
[PE1-bfd] quit
# Configure PE2.
[PE2] bfd
[PE2-bfd] quit
5. Bind the BFD session destined for the LDP LSP on the ingress node. Set the minimum
interval for sending and receiving packets to both 100 ms. Configure the port status table to
be changeable.
# Configure PE1.
[PE1] bfd pe1tope2 bind ldp-lsp peer-ip 4.4.4.4 nexthop 10.1.1.2 interface gigabitethernet
1/0/0
[PE1-bfd-lsp-session-pe1tope2] discriminator local 1
[PE1-bfd-lsp-session-pe1tope2] discriminator remote 2
[PE1-bfd-lsp-session-pe1tope2] min-tx-interval 100
[PE1-bfd-lsp-session-pe1tope2] min-rx-interval 100
[PE1-bfd-lsp-session-pe1tope2] process-pst
[PE1-bfd-lsp-session-pe1tope2] commit
[PE1-bfd-lsp-session-pe1tope2] quit
6. On PE2, configure a BFD session that is bound to the IP link to notify PE1 of the detected
faults on the LDP LSP.
# Configure PE2.
[PE2] bfd pe2tope1 bind peer-ip 1.1.1.1

[PE2-bfd-session-pe2tope1] discriminator local 2
[PE2-bfd-session-pe2tope1] discriminator remote 1
[PE2-bfd-session-pe2tope1] min-tx-interval 100
[PE2-bfd-session-pe2tope1] min-rx-interval 100
[PE2-bfd-session-pe2tope1] commit
[PE2-bfd-session-pe2tope1] quit
# Run the display bfd session all verbose command on PE1. The command output shows
that the State field is displayed as Up and the BFD Bind Type field is displayed as
LDP_LSP.

--------------------------------------------------------------------------------
Session MIndex : 4094 State : Up Name : pe1tope2
--------------------------------------------------------------------------------
2
Function
BFD Bind Type : LDP_LSP
Bind Interface :
LSP Token : 0x1b
Actual Tx Interval (ms): 100 Actual Rx Interval (ms): 100
Enable
Active Multi :3
Last Local Diagnostic : No Diagnostic
Bind Application : LSPM | L2VPN | OAM_MANAGER
Session Echo Tx TmrID : -
--------------------------------------------------------------------------------
# Run the display bfd session all verbose command on PE2, and the command output that the
(Multi Hop) State field is displayed as Up and the BFD Bind Type field is displayed as Peer
IP Address.

--------------------------------------------------------------------------------
Session MIndex : 4097 (Multi Hop) State : Up Name : pe2tope1
--------------------------------------------------------------------------------
Bind Peer IP Address
Bind Interface
Track Interface
FSM Board Id
Min Tx Interval (ms)
Local Detect Multi
Echo Passive
Destination Port
WTR Interval (ms)
Active Multi
Last Local Diagnostic
Bind Application : No Application Bind
Session TX TmrID
Session Init TmrID
--------------------------------------------------------------------------------
Configuration Files
#
sysname PE1
#
bfd
#
mpls lsr-id 1.1.1.1
mpls
#
mpls ldp
#
ip address 10.1.1.1 255.255.255.0
mpls
mpls ldp
#
ip address 10.3.1.1 255.255.255.0
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
#
bfd pe1tope2 bind ldp-lsp peer-ip 4.4.4.4 nexthop 10.1.1.2 interface
min-tx-interval 100
min-rx-interval 100
process-pst
commit
#
ospf 1
area 0.0.0.0
network 1.1.1.1 0.0.0.0
network 10.1.1.0 0.0.0.255
network 10.3.1.0 0.0.0.255
#
return
#
sysname P1
#
mpls lsr-id 2.2.2.2
mpls
#
mpls ldp
#
ip address 10.1.1.2 255.255.255.0
mpls
mpls ldp
#
ip address 10.2.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
#
ospf 1
area 0.0.0.0
network 2.2.2.2 0.0.0.0
network 10.1.1.0 0.0.0.255
network 10.2.1.0 0.0.0.255
#
return
#
sysname P2
#
ip address 10.3.1.2 255.255.255.0
#
ip address 10.4.1.1 255.255.255.0
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
#
ospf 1
area 0.0.0.0
network 3.3.3.3 0.0.0.0
network 10.3.1.0 0.0.0.255
network 10.4.1.0 0.0.0.255
#
return
#
sysname PE2
#
bfd
#
mpls lsr-id 4.4.4.4
mpls
#
mpls ldp
#
ip address 10.2.1.2 255.255.255.0
mpls
mpls ldp
#
ip address 10.4.1.2 255.255.255.0
#
interface LoopBack1
ip address 4.4.4.4 255.255.255.255
#
bfd pe2tope1 bind peer-ip 1.1.1.1
min-tx-interval 100
min-rx-interval 100
commit
#
ospf 1
area 0.0.0.0
network 4.4.4.4 0.0.0.0
network 10.2.1.0 0.0.0.255
network 10.4.1.0 0.0.0.255
#
return
13.4.5 Example for Configuring Dynamic BFD to Detect LDP LSPs
On a complex and unstable network shown in Figure 13-4-5, LSRA, LSRB, and LSRC belong to
the same MPLS domain, and an LDP LSP is established between LSRA and LSRC. It takes a period
of

1210
time for an interface to detect a fault on the connected link. Connectivity check on the LSP is
required. If a fault occurs on the LSP, LSRA can receive the fault report within 500ms.
Figure 13-4-5 Networking diagram of dynamic BFD for LDP LSPs
To meet the preceding requirements, configure dynamic BFD to detect LDP LSPs. The
1. Configure BFD that can quickly check connectivity of the LDP LSP.
2. Configure dynamic BFD for LDP LSPs, and configure BFD sessions on LSRA and LSRC.
3. Adjust BFD parameters to enable LSRA to receive a fault report within 500ms.
Procedure
For details, see Example for Configuring Local LDP Sessions.
3. Create an LDP LSP between LSRA and LSRC.
# Configure LSRA.

[LSRA] mpls
[LSRA-mpls] quit
[LSRA] mpls ldp
[LSRA-mpl-ldp] quit
# Configure LSRB.
[LSRB] mpls
[LSRB-mpls] quit
[LSRB] mpls ldp
[LSRB-mpl-ldp] quit
# Configure LSRC.

[LSRC] mpls
[LSRC-mpls] quit
[LSRC] mpls ldp
[LSRC-mpl-ldp] quit
[LSRC-GigabitEthernet1/0/0] mpls ldp
After the configuration is complete, run the display mpls ldp lsp command on LSRA. The
command output shows that an LDP LSP is set up between LSRA and LSRC. LSRA is used
as
an example.
[LSRA] display mpls ldp lsp
LDP LSP Information

-------------------------------------------------------------------------------
DestAddress/Mask In/OutLabel UpstreamPeer NextHop OutInterface
-------------------------------------------------------------------------------
1.1.1.1/32 3/NULL 2.2.2.2 127.0.0.1 InLoop0
*1.1.1.1/32 Liberal/3 DS/2.2.2.2
2.2.2.2/32 NULL/3 - 10.1.1.2 GE1/0/0
2.2.2.2/32 1024/3 2.2.2.2 10.1.1.2 GE1/0/0
3.3.3.3/32 NULL/1025 - 10.1.1.2 GE1/0/0
3.3.3.3/32 1025/1025 2.2.2.2 10.1.1.2 GE1/0/0
-------------------------------------------------------------------------------
A '*' before an LSP means the LSP is not
established
A '*' before a Label means the USCB or DSCB is
stale A '*' before a UpstreamPeer means the session is
state A '*' before a DS means the session is stale
A '*' before a NextHop means the LSP is FRR
LSP
4. Configure dynamic BFD to detect the connectivity of the LDP LSP between LSRA and LSRC.
# Configure an FEC list on LSRA to ensure that BFD detects only the connectivity of the
LDP LSP between LSRA and LSRC.
[LSRA] fec-list tortc

[LSRA-fec-list-tortc] fec-node 3.3.3.3
# Enable BFD on LSRA, specify the FEC list that triggers BFD session
establishment dynamically, and adjust BFD parameters.
[LSRA] bfd
[LSRA-bfd] quit
[LSRA] mpls
[LSRA-mpls] mpls bfd-trigger fec-list tortc
[LSRA-mpls] mpls bfd enable
[LSRA-mpls] mpls bfd min-tx-interval 100 min-rx-interval 100
[LSRA-mpls] quit
# Enable BFD for LSPs passively on LSRC.
[LSRC] bfd
[LSRC-bfd] mpls-passive
# Run the display bfd session all verbose command to view the BFD session status that
is created dynamically.
[LSRA] display bfd session all verbose

-----------------------------------------------------------
Session MIndex : 256 State : Up Name : dyn_8192
-----------------------------------------------------------
Local Discriminator: 8192 Remote Discriminator : 8192
BFD Bind Type : LDP_LSP
Bind Session Type : Dynamic
Bind Peer Ip Address : 3.3.3.3
NextHop Ip Address
Bind Interface
LSP Token
FSM Board Id
Min Tx Interval (ms)
Proc interface status : Disable Process PST : Enable
Active Multi :3
Bind Application : LSPM | LDP | L2VPN | OAM_MANAGER
-----------------------------------------------------------
# Check the status of the BFD session created dynamically on LSRC. The BFD Bind Type
field is displayed as Peer IP Address, indicating that BFD packets sent by LSRC are
transmitted through the IP route.
[LSRC] display bfd session passive-dynamic verbose

-----------------------------------------------------------
Session MIndex : 512 (Multi Hop) State : Up Name : dyn_8192
-----------------------------------------------------------
Local Discriminator : 8192 Remote Discriminator : 8192
BFD Bind Type : Peer Ip Address
Bind Session Type : Entire_Dynamic
Bind Peer Ip Address : 1.1.1.1
Bind Interface :-
Destination Port : 3784 TTL : 253
Proc interface status : Disable Process PST : Disable
Active Multi :3
Bind Application : LSPV
-----------------------------------------------------------
Configuration Files
#
sysname LSRA
#
bfd
#
mpls lsr-id 1.1.1.1
mpls
mpls bfd enable
mpls bfd-trigger fec-list tortc
mpls bfd min-tx-interval 100 min-rx-interval 100
#
fec-list tortc
fec-node 3.3.3.3
#
mpls ldp
#
ip address 10.1.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack0
ip address 1.1.1.1 255.255.255.255
#
ospf 1
area 0.0.0.0
network 1.1.1.1 0.0.0.0
network 10.1.1.0 0.0.0.255
#
return
#
sysname LSRB
#
mpls lsr-id 2.2.2.2
mpls
#
mpls ldp
#
ip address 10.1.1.2 255.255.255.0
mpls
mpls ldp
#
ip address 10.2.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack0
ip address 2.2.2.2 255.255.255.255
#
ospf 1
area 0.0.0.0
network 2.2.2.2 0.0.0.0
network 10.1.1.0 0.0.0.255
network 10.2.1.0 0.0.0.255
#
return

#
sysname LSRC
#
bfd
mpls-passive
#
mpls lsr-id 3.3.3.3
mpls
#
mpls ldp
#
ip address 10.2.1.2 255.255.255.0
mpls
mpls ldp
#
interface LoopBack0
ip address 3.3.3.3 255.255.255.255
#
ospf 1
area 0.0.0.0
network 3.3.3.3 0.0.0.0
network 10.2.1.0 0.0.0.255
#
return
13.4.6 Example for Configuring Synchronization between LDP and Static Routes
On an MPLS network with primary and backup LSPs, LSPs are established between LSRs based
on static routes. When the primary LDP session on the primary LSP fails (not due to a link fault) or
the primary LSP is restored, MPLS traffic is interrupted for a short period of time. This is because
static routes and LDP are not synchronized.
As shown in Figure 13-4-6, LSRA has static routes that are destined for LSRD and pass LSRB and
LSRC. An LDP session is established on LSRA. LinkA is the primary LSP, while LinkB is the
backup LSP. The MPLS traffic needs to be uninterrupted when the LDP session on LinkA fails or
LinkA is restored from a fault.
Figure 13-4-6 Networking diagram for configuring synchronization between LDP and static routes
To meet the preceding requirements, configure synchronization between LDP and static routes.
Configure synchronization between LDP and static routes on LSRA and LSRD, and set the value of
Hold-down timer to 20s.
Procedure
# Configure LSRA.
The configurations of LSRB, LSRC, and LSRD are similar to the configuration of LSRA,
and are not mentioned here.
2. Configure static routes for nodes to make the network connected.
# Configure two static routes with different priorities from LSRA to LSRD. Configure
two static routes with different priorities from LSRD to LSRA.
# Configure LSRA.
[LSRA] ip route-static 2.2.2.2 32 10.1.1.2

[LSRA] ip route-static 4.4.4.4 32 10.1.1.2 preference 40
[LSRA] ip route-static 4.4.4.4 32 20.1.1.2 preference 60
# Configure LSRB.
[LSRB] ip route-static 1.1.1.1 32 10.1.1.1

[LSRB] ip route-static 4.4.4.4 32 30.1.1.2
# Configure LSRC.
[LSRC] ip route-static 1.1.1.1 32 20.1.1.1

[LSRC] ip route-static 4.4.4.4 32 40.1.1.2
# Configure LSRD.
[LSRD] ip route-static 2.2.2.2 32 30.1.1.1

[LSRD] ip route-static 1.1.1.1 32 30.1.1.1 preference 40
[LSRD] ip route-static 1.1.1.1 32 40.1.1.1 preference 60
# Run the display ip routing-table protocol static command on each node to check
the configured static routes. Use the display on LSRA as an example.
[LSRA] display ip routing-table protocol static

------------------------------------------------------------------------------
Public routing table : Static
Destinations : 5 Routes : 6 Configured Routes : 6
Static routing table status : <Active>

2.2.2.2/32 Static 60 0 RD 10.1.1.2

3.3.3.3/32 Static 60 0 RD 20.1.1.2
4.4.4.4/32 Static 40 0 RD 10.1.1.2
30.1.1.0/30 Static 60 0 RD 10.1.1.2
40.1.1.0/30 Static 60 0 RD 20.1.1.2
Static routing table status : <Inactive>

4.4.4.4/32 Static 60 0 D 20.1.1.2

3. Enable MPLS LDP on LSRs and establish an LDP LSP.
# Configure LSRA.

[LSRA] mpls [LSRA-
mpls] quit [LSRA]
mpls ldp [LSRA-
mpls-ldp] quit
The configurations of LSRB, LSRC, and LSRD are similar to the configuration of LSRA.
For configuration procedures, see the related configuration files.
# Run the display mpls ldp session command on each node. The command output shows
that the LDP session is established and status is Operational. LSRA is used as an example.
1210

deleted.
------------------------------------------------------------------------------
------------------------------------------------------------------------------
------------------------------------------------------------------------------
4. Configure synchronization between LDP and static routes on LSRA and

LSRD.
# Configure LSRA.
[LSRA] ip route-static 4.4.4.4 32 gigabitethernet 1/0/0 ldp-sync

[LSRA-GigabitEthernet1/0/0] static-route timer ldp-sync hold-down 20
# Configure LSRD.
[LSRD] ip route-static 1.1.1.1 32 gigabitethernet 1/0/0 ldp-sync

[LSRD-GigabitEthernet1/0/0] static-route timer ldp-sync hold-down 20
# Check the status of the outbound interface specified by static routes that are synchronized with
LDP.
[LSRA] display static-route ldp-sync

Total number of routes enable Ldp-Sync: 1
-----------------------------------------------------
Interface GigabitEthernet1/0/0
Enable ldp-sync static routes number: 1
Static-route ldp-sync holddown timer: 20s
Sync state: Normal
Dest = 4.4.4.4, Mask = 32, NextHop = 10.1.1.1.
-----------------------------------------------------
The command output shows that synchronization between LDP and static routes is
configured and synchronization status is Normal.
 If the LDP session on LinkA fails, traffic is immediately switched to LinkB,
ensuring uninterrupted traffic transmission.
 When LinkA is restored from the fault, the static route whose next hop IP address is
10.1.1.1 is not used immediately. Only when the Hold-down timer expires after 20s, the
LDP session on LinkA is established. The static route whose next hop IP address is
10.1.1.1 is activated. The static route and LDP are synchronized and MPLS
traffic transmission is not interrupted.
Configuration Files
#
sysname LSRA
#
mpls lsr-id 1.1.1.1
mpls
#
mpls ldp
#
ip address 10.1.1.1 255.255.255.252
static-route timer ldp-sync hold-down 20
mpls
mpls ldp
#
ip address 20.1.1.1 255.255.255.252
mpls
mpls ldp
#
interface loopback0
ip address 1.1.1.1 255.255.255.255
#
ip route-static 2.2.2.2 255.255.255.255 10.1.1.2
ip route-static 3.3.3.3 255.255.255.255 20.1.1.2
ip route-static 4.4.4.4 255.255.255.255 10.1.1.2 preference
40 ip route-static 4.4.4.4 255.255.255.255 20.1.1.2
ip route-static 4.4.4.4 255.255.255.255 GigabitEthernet1/0/0 ldp-
sync ip route-static 30.1.1.0 255.255.255.252 10.1.1.2
ip route-static 40.1.1.0 255.255.255.252 20.1.1.2
#
return
#
sysname LSRB
#
mpls lsr-id 2.2.2.2
mpls
#
mpls ldp
#
ip address 10.1.1.2 255.255.255.252
mpls
mpls ldp
#
ip address 30.1.1.1 255.255.255.252
mpls
mpls ldp
#
interface loopback0
ip address 2.2.2.2 255.255.255.255
#
ip route-static 1.1.1.1 255.255.255.255 10.1.1.1
ip route-static 4.4.4.4 255.255.255.255 30.1.1.2
#
return
#
sysname LSRC
#
mpls lsr-id 3.3.3.3
mpls
#
mpls ldp
#
ip address 20.1.1.2 255.255.255.252
mpls
mpls ldp
#
ip address 40.1.1.1 255.255.255.252
mpls
mpls ldp
#
interface loopback0
ip address 3.3.3.3 255.255.255.255
#
ip route-static 1.1.1.1 255.255.255.255 20.1.1.1
ip route-static 4.4.4.4 255.255.255.255 40.1.1.2
#
return
 Configuration file of LSRD
#
sysname LSRD
#
mpls lsr-id 4.4.4.4
mpls
#
mpls ldp
#
ip address 30.1.1.2 255.255.255.252
static-route timer ldp-sync hold-down 20
mpls
mpls ldp
#
ip address 40.1.1.2 255.255.255.252
mpls
mpls ldp
#
interface loopback0
ip address 4.4.4.4 255.255.255.255
#
ip route-static 1.1.1.1 255.255.255.255 30.1.1.1 preference
40 ip route-static 1.1.1.1 255.255.255.255 40.1.1.1
ip route-static 1.1.1.1 255.255.255.255 GigabitEthernet1/0/0 ldp-sync
ip route-static 2.2.2.2 255.255.255.255 30.1.1.1
ip route-static 3.3.3.3 255.255.255.255 40.1.1.1
ip route-static 10.1.1.0 255.255.255.252 30.1.1.1
ip route-static 20.1.1.0 255.255.255.252 40.1.1.1
#
return
13.4.7 Example for Configuring Synchronization between LDP and
IGP Networking Requirements
As shown in Figure 13-4-7, P1, P2, P3, and PE2 exist on an MPLS backbone network, and OSPF
runs between each two devices. Two LSPs are established between PE1 and PE2. The LSP PE1 -> P1
-> P2
-> PE2 is the primary LSP, while the LSP PE1 -> P1 -> P3 -> PE2 is the backup LSP. When the
primary LSP recovers, IGP traffic is switched back to the primary LSP earlier than LDP traffic
because IGP route convergence is faster than LDP convergence. As a result, LSP traffic is lost. The
LSP traffic loss needs to be prevented on the MPLS network where primary and backup LSPs are
configured.
Figure 13-4-7 Networking diagram for configuring synchronization between LDP and
IGP
To meet the preceding requirements, configure synchronization between LDP and IGP.
1. Enable synchronization between LDP and IGP on the interfaces at both ends of the link
between P1 (crossing node of the primary and backup LSPs) and P2 (LDP neighboring node on
the primary LSP).
2. Set the values of Hold-down timer, Hold-max-cost timer and Delay timer on the interfaces
at both ends of the link between P1 and P2.
Procedure
# Configure P1.
[Huawei] sysname P1
[P1] interface loopback 1
[P1-LoopBack1] ip address 1.1.1.9 32
[P1-LoopBack1] quit
[P1-GigabitEthernet1/0/0] ip address 10.1.1.1 24
[P1-GigabitEthernet2/0/0] ip address 10.3.1.1 24
The configurations of P2, P3, and PE2 are similar to the configuration of P1, and are
not mentioned here.
# Configure P1.
[P1] ospf 1
[P1-ospf-1] area 0
[P1-ospf-1-area-0.0.0.0] network 1.1.1.1 0.0.0.0
[P1-ospf-1-area-0.0.0.0] quit
[P1-ospf-1] quit
The configurations of P2, P3, and PE2 are similar to the configuration of P1, and are
not mentioned here.
3. # Set the cost of GE2/0/0 on P1 to 1000.

[P1-GigabitEthernet2/0/0] ospf cost 1000
When the configurations are complete, run the display ip routing-table command on each
node. The command output shows that the nodes have learned routes from each other. The
outbound
interface of P1-to-P2 route is GE1/0/0. P1 is used as an example.
[P1] display ip routing-table

------------------------------------------------------------------------------
Destination/Mask
1.1.1.9/32
2.2.2.9/32
3.3.3.9/32
4.4.4.9/32
10.1.1.0/24
10.1.1.1/32
10.1.1.255/32
10.2.1.0/24
10.3.1.0/24
10.3.1.1/32
10.3.1.255/32
10.4.1.0/24
127.0.0.0/8
127.0.0.1/32
127.255.255.255/32
255.255.255.255/32
4. Enable MPLS and MPLS LDP on each node and each interface.
# Configure P1.
[P1] mpls
[P1-mpls] quit
[P1] mpls ldp
[P1-mpls-ldp] quit
# Configure P2.

[P2] mpls
[P2-mpls] quit
[P2] mpls ldp
[P2-mpls-ldp] quit
# Configure P3.

[P3] mpls
[P3-mpls] quit
[P3] mpls ldp
[P3-mpls-ldp] quit
# Configure PE2.

[PE2] mpls
[PE2-mpls] quit
[PE2] mpls ldp
[PE2-mpls-ldp] quit
When the configurations are complete, LDP sessions are established between neighboring
nodes. Run the display mpls ldp session command on each node. The command output shows
that
LDP session status is Operational. P1 is used as an example.
[P1] display mpls ldp session

deleted.
------------------------------------------------------------------------------
------------------------------------------------------------------------------
------------------------------------------------------------------------------
5. Enable synchronization between LDP and IGP on the interfaces at both ends of the link between
P1 and P2.
# Configure P1.

[P1-GigabitEthernet1/0/0] ospf ldp-sync
# Configure P2.

[P2-GigabitEthernet1/0/0] ospf ldp-sync
6. Set the value of Hold-down timer on the interfaces at both ends of the link between P1 and P2.
# Configure P1.

[P1-GigabitEthernet1/0/0] ospf timer ldp-sync hold-down 8
# Configure P2.

[P2-GigabitEthernet1/0/0] ospf timer ldp-sync hold-down 8
7. Set the value of Hold-max-cost timer on the interfaces at both ends of the link between P1 and
P2.
# Configure P1.

[P1-GigabitEthernet1/0/0] ospf timer ldp-sync hold-max-cost 9
# Configure P2.

[P2-GigabitEthernet1/0/0] ospf timer ldp-sync hold-max-cost 9
8. Set the value of Delay timer on the interfaces at both ends of the link between P1 and P2.
# Configure P1.

[P1-GigabitEthernet1/0/0] mpls ldp timer igp-sync-delay 6
# Configure P2.

[P2-GigabitEthernet1/0/0] mpls ldp timer igp-sync-delay 6

1210
Run the display ospf ldp-sync command on P1. The command output shows that the interface
status is Sync-Achieved.
[P1] display ospf ldp-sync interface gigabitethernet 1/0/0

Interface GigabitEthernet1/0/0
HoldDown Timer: 8 HoldMaxCost Timer: 9
LDP State: Up OSPF Sync State: Sync-Achieved
Configuration Files
#
sysname P1
#
mpls lsr-id 1.1.1.9
mpls
#
mpls ldp
#
ip address 10.1.1.1 255.255.255.0
ospf ldp-sync
ospf timer ldp-sync hold-down 8
ospf timer ldp-sync hold-max-cost 9
mpls
mpls ldp
mpls ldp timer igp-sync-delay 6
#
ip address 10.3.1.1 255.255.255.0
ospf cost 1000
mpls
mpls ldp
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 1.1.1.9 0.0.0.0
network 10.1.1.0 0.0.0.255
network 10.3.1.0 0.0.0.255
#
return
#
sysname P2
#
mpls lsr-id 2.2.2.9
mpls
#
mpls ldp
#
ip address 10.1.1.2 255.255.255.0
ospf ldp-sync
ospf timer ldp-sync hold-down 8
ospf timer ldp-sync hold-max-cost 9
mpls
mpls ldp
mpls ldp timer igp-sync-delay 6
#
ip address 10.2.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 2.2.2.9 0.0.0.0
network 10.1.1.0 0.0.0.255
network 10.2.1.0 0.0.0.255
#
return
#
sysname P3
#
mpls lsr-id 3.3.3.9
mpls
#
mpls ldp
#
ip address 10.3.1.2 255.255.255.0
mpls
mpls ldp
#
ip address 10.4.1.1 255.255.255.0
mpls
mpls ldp
#
ospf 1
area 0.0.0.0
network 3.3.3.9 0.0.0.0
network 10.3.1.0 0.0.0.255
network 10.4.1.0 0.0.0.255
#
return
#
sysname PE2
#
mpls lsr-id 4.4.4.9
#
mpls
#
mpls ldp
#
ip address 10.2.1.2 255.255.255.0
mpls
mpls ldp
#
ip address 10.4.1.2 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 4.4.4.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 4.4.4.9 0.0.0.0
network 10.2.1.0 0.0.0.255
network 10.4.1.0 0.0.0.255
#
return
13.4.8 Example for Configuring LDP GR
As shown in Figure 13-4-8, MPLS LDP is deployed on the MPLS network, and LSRA, LSRB,
and LSRC are all equipped with one main control board. During the AMB/SMB switchover or
system upgrade, a neighbor deletes an LSP because the LDP session is Down. Therefore, LDP
traffic is interrupted for a short period of time. A neighbor is required not to delete an LSP during
the AMB/SMB switchover or system upgrade to ensure uninterrupted LDP traffic.
Figure 13-4-8 Networking diagram for configuring LDP GR
To meet the preceding requirements, configure LDP GR. The configuration roadmap is as
follows: Enable MPLS LDP GR on each node, ensuring uninterrupted traffic in a short period of
time.
Procedure
1. Configure an LDP LSP.
When the configurations are complete, run the display mpls ldp session command on
each node to view the established LDP session. LSRA is used as an example.

deleted.
--------------------------------------------------------------------------
--------------------------------------------------------------------------
--------------------------------------------------------------------------
2. Configure LDP GR.
# Configure LSRA.
[LSRA] mpls ldp

[LSRA-mpls-ldp] graceful-restart
Warning: All the related sessions will be deleted if the operation is performed
!Continue? (y/n)y
[LSRA-mpls-ldp] quit
# Configure LSRB.
[LSRB] mpls ldp

[LSRB-mpls-ldp] graceful-restart
!Continue? (y/n)y
[LSRB-mpls-ldp] quit
# Configure LSRC.
[LSRC] mpls ldp

[LSRC-mpls-ldp] graceful-restart
!Continue? (y/n)y
[LSRC-mpls-ldp] quit
# Run the display mpls ldp session verbose command on the LSRs. The command
output shows that the Session FT Flag field is displayed as On. LSRA is used as an
example.
[LSRA]display mpls ldp session verbose

------------------------------------------------------------------------------
Peer LDP ID : 2.2.2.2:0 Local LDP ID : 1.1.1.1:0
TCP Connection : 1.1.1.1 <- 2.2.2.2
Session State : Operational Session Role : Passive
Session FT Flag : On MD5 Flag : Off
Reconnect Timer : 0 Sec Recovery Timer : 300 Sec
Keychain Name : ---
Negotiated Keepalive Timer : 45 Sec

Configured Keepalive Send Timer : ---
Keepalive Message Sent/Rcvd : 1/1 (Message Count)
Label Advertisement Mode : Downstream
Unsolicited Label Resource Status(Peer/Local) :
Available/Available
Session Age : 000:00:00 (DDD:HH:MM)
Session Deletion Status : No
Capability:
Capability-Announcement : Off
Outbound&Inbound Policies applied : NULL

Addresses received from peer: (Count: 3)
2.2.2.2 10.1.1.2 10.2.1.1
------------------------------------------------------------------------------
# Or run the display mpls ldp peer verbose command on the LSRs. The command
output shows that the Peer FT Flag field is displayed as On. LSRA is used as an
example.
[LSRA] display mpls ldp peer verbose
LDP Peer Information in Public network

------------------------------------------------------------------------------
Peer LDP ID : 2.2.2.2:0
Peer Max PDU Length : 4096 Peer Transport Address : 2.2.2.2
Peer Loop Detection : Off Peer Path Vector Limit : ----
Peer FT Flag
Recovery Timer
Peer Type
Peer Label Advertisement Mode : Downstream Unsolicited

Peer Discovery Source : GigabitEthernet1/0/0
Peer Deletion Status : No
Capability-Announcement : Off
------------------------------------------------------------------------------
Configuration Files
#
sysname LSRA
#
mpls lsr-id 1.1.1.1
mpls
#
mpls ldp
graceful-restart
#
ip address 10.1.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack0
ip address 1.1.1.1 255.255.255.255
#
ospf 1
area 0.0.0.0
network 1.1.1.1 0.0.0.0
network 10.1.1.0 0.0.0.255
#
return
#
sysname LSRB
#
mpls lsr-id 2.2.2.2
mpls
#
mpls ldp
graceful-restart
#
ip address 10.1.1.2 255.255.255.0
mpls
mpls ldp
#
ip address 10.2.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack0
ip address 2.2.2.2 255.255.255.255
#
ospf 1
area 0.0.0.0
network 2.2.2.2 0.0.0.0
network 10.1.1.0 0.0.0.255
network 10.2.1.0 0.0.0.255
#
return
#
sysname LSRC
#
mpls lsr-id 3.3.3.3
mpls
#
mpls ldp
graceful-restart
#
ip address 10.2.1.2 255.255.255.0

1210
mpls
mpls ldp
#
interface LoopBack0
ip address 3.3.3.3 255.255.255.255
#
ospf 1
area 0.0.0.0
network 3.3.3.3 0.0.0.0
network 10.2.1.0 0.0.0.255
#
Return
13.4.9 Example for Configuring BGP/MPLS IP VPN
 CE1 connects to the headquarters R&D area of a company, and CE3 connects to the branch R&D
area. CE1 and CE3 belong to vpna.
 CE2 connects to the headquarters non-R&D area, and CE4 connects to the branch non-R&D area.
CE2 and CE4 belong to vpnb.
 BGP/MPLS IP VPN needs to be deployed for the company to ensure secure

communication between the headquarters and branches.
Figure 13-4-9 Networking diagram for configuring BGP/MPLS IP VPN
1. Configure OSPF between the P and PEs to ensure IP connectivity on the backbone network.
2. Configure basic MPLS capabilities and MPLS LDP on the P and PEs to set up MPLS LSP
tunnels for VPN data transmission on the backbone network.
3. Configure MP-IBGP on PE1 and PE2 to enable them to exchange VPN routing information.
4. Configure VPN instances vpna and vpnb on PE1 and PE2. Set the VPN target of vpna to 111:1
and the VPN target of vpnb to 222:2. This configuration allows users in the same VPN to
communicate with each other and isolates users in different VPNs. Bind the VPN instance to
the PE interfaces connected to CEs to provide access for VPN users.
5. Configure EBGP on the CEs and PEs to exchange VPN routing information.

1210
Procedure
1. Configure OSPF on the MPLS backbone network so that the PEs and Ps can communicate
with each other.
# Configure PE1.
[PE1] interface loopback 1
[PE1] ospf 1
[PE1-ospf-1] area 0
[PE1-ospf-1] quit
# Configure P.
[Huawei] sysname P
[P] interface loopback 1
[P-LoopBack1] ip address 2.2.2.9 32
[P-LoopBack1] quit
[P] interface gigabitethernet 1/0/0
[P-GigabitEthernet1/0/0] ip address 172.1.1.2 24
[P-GigabitEthernet1/0/0] quit
[P-GigabitEthernet2/0/0] ip address 172.2.1.1 24
[P] ospf
[P-ospf-1] area 0
[P-ospf-1-area-0.0.0.0] network 172.1.1.0 0.0.0.255
[P-ospf-1-area-0.0.0.0] quit
[P-ospf-1] quit
# Configure PE2.
[PE2] ospf
[PE2-ospf-1] area 0
[PE2-ospf-1] quit
After the configuration is complete, OSPF neighbor relationships can be set up between PE1,
P, and PE2. Run the display ospf peer command. The command output shows that the
neighbor status is Full. Run the display ip routing-table command. The command output
shows that PEs have learned the routes to Loopback1 of each other.
The information displayed on PE1 is used as an example.
[PE1] display ip routing-table

------------------------------------------------------------------------------
1.1.1.9/32
2.2.2.9/32
3.3.3.9/32
127.0.0.0/8
127.0.0.1/32
127.255.255.255/32
172.1.1.0/24
172.1.1.1/32
172.1.1.255/32
172.2.1.0/24 OSPF 10 2 D 172.1.1.2
[PE1] display ospf peer

Neighbors

DR: 172.1.1.1 BDR: 172.1.1.2 MTU: 0
2. Configure basic MPLS capabilities and MPLS LDP on the MPLS backbone network to set up
LDP LSPs.
# Configure PE1.

[PE1] mpls
[PE1-mpls] quit
[PE1] mpls ldp
[PE1-mpls-ldp] quit
# Configure P.
[P] mpls lsr-id 2.2.2.9

[P] mpls
[P-mpls] quit
[P] mpls ldp
[P-mpls-ldp] quit
[P-GigabitEthernet1/0/0] mpls
[P-GigabitEthernet1/0/0] mpls ldp
# Configure PE2.

[PE2] mpls
[PE2-mpls] quit
[PE2] mpls ldp
[PE2-mpls-ldp] quit
After the configuration is complete, LDP sessions can be set up between PE1 and the P
and between the P and PE2. Run the display mpls ldp session command. The command
output shows that the Status field is Operational. Run the display mpls ldp lsp
command. Information about the established LDP LSPs is displayed.
[PE1] display mpls ldp session

deleted.
------------------------------------------------------------------------------
------------------------------------------------------------------------------
2.2.2.9:0 Operational DU Active 0000:00:01 6/6
------------------------------------------------------------------------------
LDP LSP Information

-------------------------------------------------------------------------------
OutInterface
-------------------------------------------------------------------------------
1.1.1.9/32 3/NULL 2.2.2.9 127.0.0.1 InLoop0
*1.1.1.9/32 Liberal/1024 DS/2.2.2.9
2.2.2.9/32 NULL/3 - 172.1.1.2 GE3/0/0
2.2.2.9/32 1024/3 2.2.2.9 172.1.1.2 GE3/0/0
3.3.3.9/32 NULL/1025 - 172.1.1.2 GE3/0/0
3.3.3.9/32 1025/1025 2.2.2.9 172.1.1.2 GE3/0/0
-------------------------------------------------------------------------------
A "*" before an LSP means the LSP is not
established
A "*" before a Label means the USCB or DSCB is stale
A "*" before a UpstreamPeer means the session is stale
A "*" before a DS means the session is stale
A "*" before a NextHop means the LSP is FRR LSP
3. Configure VPN instances on PEs and bind the instances to the interfaces connected to
CEs.
# Configure PE1.
[PE1] ip vpn-instance vpna

[PE1-vpn-instance-vpna] ipv4-family
[PE1-vpn-instance-vpna-af-ipv4] route-distinguisher 100:1
[PE1-vpn-instance-vpna-af-ipv4] vpn-target 111:1 both
[PE1-vpn-instance-vpna-af-ipv4] quit
[PE1-vpn-instance-vpna] quit
[PE1] ip vpn-instance vpnb
[PE1-vpn-instance-vpnb] ipv4-family
[PE1-vpn-instance-vpnb-af-ipv4] route-distinguisher 100:2
[PE1-vpn-instance-vpnb-af-ipv4] vpn-target 222:2 both
[PE1-vpn-instance-vpnb] quit
[PE1-GigabitEthernet1/0/0] ip binding vpn-instance vpna
[PE1-GigabitEthernet2/0/0] ip binding vpn-instance vpnb
# Configure PE2.

[PE2-vpn-instance-vpnb-af-ipv4] quit
# Assign IP addresses to interfaces on CEs according to Figure 13-4-9.
# Configure CE1.
[Huawei] sysname CE1
[CE1] interface gigabitethernet 1/0/0
[CE1-GigabitEthernet1/0/0] ip address 10.1.1.1 24
[CE1-GigabitEthernet1/0/0] quit
The configuration on other CEs is similar to the configuration on CE1 and is not
mentioned here.
After the configuration is complete, run the display ip vpn-instance verbose command on the
PEs to check the configuration of VPN instances. Each PE can ping its connected CE.
NOTE:
If a PE has multiple interfaces bound to the same VPN instance, specify a source IP addresses
by setting -a source-ip-address in the ping -vpn-instance vpn-instance-name -a
source-ip-address dest-ip-address command to ping the remote CE. If the source IP address
is not specified, the ping operation fails.
The information displayed on PE1 and CE1 is used as an example.
[PE1] display ip vpn-instance verbose

Total VPN-Instances configured : 2
Total IPv4 VPN-Instances configured : 2
VPN-Instance Name and ID : vpna, 1

Interfaces : GigabitEthernet1/0/0
Address family ipv4
Create date : 2012/07/25 00:58:17 UTC+08:00
Up time : 0 days, 22 hours, 24 minutes and 53 seconds
Route Distinguisher : 100:1
Export VPN Targets : 111:1
Import VPN Targets : 111:1
Label Policy : label per route
Log Interval : 5
VPN-Instance Name and ID : vpnb, 2

Address family ipv4
Create date : 2012/07/25 00:58:17 UTC+08:00
Log Interval : 5
[PE1] ping -vpn-instance vpna 10.1.1.1


0.00% packet loss
4. Set up an MP-IBGP peer relationship between the PEs.
# Configure PE1.
[PE1] bgp 100

[PE1-bgp] peer 3.3.3.9 as-number 100
[PE1-bgp] peer 3.3.3.9 connect-interface loopback 1
[PE1-bgp] ipv4-family vpnv4
[PE1-bgp-af-vpnv4] peer 3.3.3.9 enable
[PE1-bgp-af-vpnv4] quit
[PE1-bgp] quit
# Configure PE2.
[PE2] bgp 100

[PE2-bgp] quit
After the configuration is complete, run the display bgp peer or display bgp vpnv4 all peer
command on the PEs. The command output shows that BGP peer relationships have
been established between the PEs.
[PE1] display bgp peer


PrefRcv
3.3.3.9 4 100 12 6 0 00:02:21 Established

0
[PE1] display bgp vpnv4 all peer


PrefRcv
3.3.3.9 4 100 12 18 0 00:09:38 Established 0
5. Set up EBGP peer relationships between the PEs and CEs and import VPN routes into BGP.
# Configure CE1.
[CE1] bgp 65410

[CE1-bgp] peer 10.1.1.2 as-number 100
[CE1-bgp] import-route direct
[CE1-bgp] quit
NOTE:
mentioned here.
# Configure PE1.
[PE1] bgp 100

[PE1-bgp] ipv4-family vpn-instance vpna
[PE1-bgp-vpna] peer 10.1.1.1 as-number 65410
[PE1-bgp-vpna] import-route direct
[PE1-bgp-vpna] quit
[PE1-bgp] ipv4-family vpn-instance vpnb
[PE1-bgp-vpnb] peer 10.2.1.1 as-number 65420
[PE1-bgp-vpnb] import-route direct
[PE1-bgp-vpnb] quit
[PE1-bgp] quit
NOTE:
The configuration on PE2 is similar to the configuration on PE1 and is not mentioned here.
After the configuration is complete, run the display bgp vpnv4 vpn-instance peer
command on the PEs. The command output shows that BGP peer relationships have been
established between the PEs and CEs.
The peer relationship between PE1 and CE1 is used as an example.
[PE1] display bgp vpnv4 vpn-instance vpna peer

VPN-Instance vpna, Router ID 1.1.1.9:

1210
Peer V AS MsgRcvd MsgSent OutQ Up/Down

State PrefRcv
10.1.1.1 4 65410 6 3 0 00:00:02 Established

4
Run the display ip routing-table vpn-instance command on the PEs to view the routes to
the remote CEs.
[PE1] display ip routing-table vpn-instance vpna

------------------------------------------------------------------------------
Routing Tables: vpna
10.1.1.0/24 Direct 0 0 D 10.1.1.2

10.1.1.2/32 Direct 0 0 D 127.0.0.1
10.1.1.255/32 Direct 0 0 D 127.0.0.1
10.3.1.0/24
255.255.255.255/32
[PE1] display ip routing-table vpn-instance vpnb

------------------------------------------------------------------------------
Routing Tables: vpnb
Destination/Mask Proto
10.2.1.0/24 Direct

1210
10.2.1.2/32
10.2.1.255/32
10.4.1.0/24
CEs in the same VPN can ping each other, whereas CEs in different VPNs
cannot. For example, CE1 can ping CE3 at 10.3.1.1 but cannot ping CE4 at
10.4.1.1.
[CE1] ping 10.3.1.1

0.00% packet loss
[CE1] ping 10.4.1.1
Request time out
Request time out
Request time out
Request time out
Request time out
100.00% packet loss
Configuration Files
#
sysname PE1
#
ip vpn-instance vpna
ipv4-family
route-distinguisher 100:1
vpn-target 111:1 import-extcommunity
vpn-target 111:1 export-extcommunity
#
ip vpn-instance vpnb
ipv4-family
#
mpls lsr-id 1.1.1.9
mpls
#
mpls ldp
#
ip binding vpn-instance vpna
ip address 10.1.1.2 255.255.255.0
#
ip binding vpn-instance vpnb
ip address 10.2.1.2 255.255.255.0
#
ip address 172.1.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
#
bgp 100
peer 3.3.3.9 connect-interface LoopBack1
#
ipv4-family unicast
peer 3.3.3.9 enable
#
ipv4-family vpnv4
policy vpn-target
peer 3.3.3.9 enable
#
ipv4-family vpn-instance vpna
import-route direct
#
ipv4-family vpn-instance vpnb
import-route direct
#
ospf 1
area 0.0.0.0
network 172.1.1.0 0.0.0.255
network 1.1.1.9 0.0.0.0
#
return
 Configuration file of P
#
sysname P
#
mpls lsr-id 2.2.2.9
mpls
#
mpls ldp
#
ip address 172.1.1.2 255.255.255.0
mpls
mpls ldp
#
ip address 172.2.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 172.1.1.0 0.0.0.255
network 172.2.1.0 0.0.0.255
network 2.2.2.9 0.0.0.0
#
return
Configuration file of PE2
#
sysname PE2
#
ipv4-family
#
ipv4-family
#
mpls lsr-id 3.3.3.9
mpls
#
mpls ldp
#
ip address 10.3.1.2 255.255.255.0
#
ip address 10.4.1.2 255.255.255.0
#
ip address 172.2.1.2 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 1.1.1.9 enable
#
ipv4-family vpnv4
policy vpn-target
peer 1.1.1.9 enable
#
import-route direct
#
import-route direct
#
ospf 1
area 0.0.0.0
network 172.2.1.0 0.0.0.255
network 3.3.3.9 0.0.0.0
#
return
 Configuration file of CE1
#
sysname CE1
#
ip address 10.1.1.1 255.255.255.0
#
bgp 65410
#
ipv4-family unicast
import-route direct
#
return
#
sysname CE2
#
ip address 10.2.1.1 255.255.255.0
#
bgp 65420
#
ipv4-family unicast
import-route direct
#
return
#
sysname CE3
#
ip address 10.3.1.1 255.255.255.0
#
bgp 65430
#
ipv4-family unicast
import-route direct
#
return
#
sysname CE4
#
ip address 10.4.1.1 255.255.255.0
#
bgp 65440
#
ipv4-family unicast
import-route direct
#
return
13.4.10 Example for Configuring BGP/MPLS IP VPNs with Overlapping Address Spaces
 CE1 connects to the headquarters R&D area of a company, and CE3 connects to the branch R&D
area. CE1 and CE3 belong to vpna.
 CE2 connects to the headquarters non-R&D area, and CE4 connects to the branch non-R&D area.
CE2 and CE4 belong to vpnb.
 The headquarters and branches use overlapping address spaces.
The company wants to ensure secure communication between the headquarters and branches
and isolate the R&D areas from non-R&D areas, without changing the current network
deployment.
Figure 13-4-10 Networking diagram for configuring BGP/MPLS IP VPNs with overlapping
address spaces
1. Configure OSPF between the P and PEs to ensure IP connectivity on the backbone network.
2. Configure basic MPLS capabilities and MPLS LDP on the P and PEs to set up MPLS LSP
tunnels for VPN data transmission on the backbone network.
3. Configure MP-IBGP on PE1 and PE2 to enable them to exchange VPN routing information.
4. Configure VPN instances vpna and vpnb on PE1 and PE2. Set the VPN target of vpna to
100:100 and the VPN target of vpnb to 200:200. This configuration allows users in the
same VPN to communicate with each other and isolates users in different VPNs. Bind the
VPN instance to the PE interfaces connected to CEs to provide access for VPN users.
5. Configure static routes on the CEs and PEs to exchange VPN routing information.
Procedure
1. Assign IP addresses to interfaces according to Figure 13-4-10.

# Configure PE1.
The configuration on PE2, P, and CE1 to CE4 is similar to the configuration on PE1 and is
not mentioned here.
2. Configure OSPF on the MPLS backbone network so that the PEs and Ps can communicate
with each other.
# Configure PE1.
[PE1] ospf
[PE1-ospf-1] area 0
[PE1-ospf-1] quit
# Configure P.
[P] ospf
[P-ospf-1] area 0
[P-ospf-1-area-0.0.0.0] quit
[P-ospf-1] quit
# Configure PE2.
[PE2] ospf
[PE2-ospf-1] area 0
[PE2-ospf-1] quit
After the configuration is complete, OSPF neighbor relationships can be set up between PE1,
P, and PE2. Run the display ospf peer command. The command output shows that the
neighbor
status is Full. Run the display ip routing-table command. The command output shows that
PEs have learned the routes to Loopback0 of each other.

Route Flags: R - relied, D - download to fib
------------------------------------------------------------------------------
1.1.1.9/32
2.2.2.9/32
3.3.3.9/32
12.1.1.0/24
12.1.1.1/32
12.1.1.255/32
23.1.1.0/24
127.0.0.0/8
127.0.0.1/32
127.255.255.255/32
255.255.255.255/32
3. Configure basic MPLS capabilities and MPLS LDP on the MPLS backbone network to set up
LDP LSPs.
# Configure PE1.

[PE1] mpls
[PE1-mpls] quit
[PE1] mpls ldp
[PE1-mpls-ldp] quit

1210
# Configure P.
[P] mpls lsr-id 2.2.2.9

[P] mpls
[P-mpls] quit
[P] mpls ldp
[P-mpls-ldp] quit
# Configure PE2.

[PE2] mpls
[PE2-mpls] quit
[PE2] mpls ldp
[PE2-mpls-ldp] quit
After the configuration is complete, LDP sessions can be set up between PE1 and the P
and between the P and PE2. Run the display mpls ldp session command. The command
output shows that the Status field is Operational. Run the display mpls ldp lsp

deleted.
------------------------------------------------------------------------------
------------------------------------------------------------------------------
------------------------------------------------------------------------------
LDP LSP Information

-------------------------------------------------------------------------------
OutInterface
-------------------------------------------------------------------------------
1.1.1.9/32 3/NULL 2.2.2.9 127.0.0.1 InLoop0
*1.1.1.9/32 Liberal/1024 DS/2.2.2.9
2.2.2.9/32 NULL/3 - 12.1.1.2 GE1/0/0
2.2.2.9/32 1024/3 2.2.2.9 12.1.1.2 GE1/0/0
3.3.3.9/32 NULL/1025 - 12.1.1.2 GE1/0/0
3.3.3.9/32 1025/1025 2.2.2.9 12.1.1.2 GE1/0/0
-------------------------------------------------------------------------------
A "*" before an LSP means the LSP is not
established
A "*" before a Label means the USCB or DSCB is stale
A "*" before a UpstreamPeer means the session is stale
A "*" before a DS means the session is stale
A "*" before a NextHop means the LSP is FRR LSP
4. Configure VPN instances on PEs and bind the instances to the interfaces connected to CEs.
# Configure PE1.

[PE1-vpn-instance-vpna-af-ipv4] route-distinguisher
100:100
[PE1-vpn-instance-vpna-af-ipv4] vpn-target 100:100 export-extcommunity
[PE1-vpn-instance-vpna-af-ipv4] vpn-target 100:100 import-extcommunity
[PE1-vpn-instance-vpnb-af-ipv4] vpn-target 200:200 export-
extcommunity
[PE1-vpn-instance-vpnb-af-ipv4] vpn-target 200:200 import-extcommunity
[PE1-GigabitEthernet2/0/0] ip address 14.1.1.1 255.255.255.0
# Configure PE2.

[PE2-vpn-instance-vpna-af-ipv4] vpn-target 100:100 import-extcommunity
[PE2-vpn-instance-vpnb-af-ipv4] vpn-target 200:200 export-extcommunity
[PE2-vpn-instance-vpnb-af-ipv4] vpn-target 200:200 import-extcommunity
# Configure CE1.
mentioned here.
After the configuration is complete, run the display ip vpn-instance verbose command on the
PEs to check the configuration of VPN instances. Each PE can ping its connected CE.
[PE1] display ip vpn-instance verbose


Address family ipv4
Create date : 2012/07/25 00:58:17 UTC+08:00
Log Interval : 5
VPN-Instance Name and ID : vpnb, 2

Address family ipv4
Create date : 2012/07/25 00:58:17 UTC+08:00
Log Interval : 5


0.00% packet loss
5. Set up an MP-IBGP peer relationship between the PEs.
# Configure PE1.
[PE1] bgp 100

[PE1-bgp-vpna] quit
[PE1-bgp-vpnb] quit
[PE1-bgp] quit
# Configure PE2.
[PE2] bgp 100

[PE2-bgp-vpna] quit
[PE2-bgp-vpnb] quit
[PE2-bgp] quit
After the configuration is complete, run the display bgp peer command on the PEs. The
command output shows that a BGP peer relationship has been set up between the PEs.
[PE1] display bgp peer


PrefRcv
3.3.3.9 4 100 3 3 0 00:01:08 Established

0
6. On CE1, CE2, CE3, and CE4, configure static routes to their connected PEs.
# Configure CE1.
[CE1] ip route-static 0.0.0.0 0.0.0.0 gigabitethernet 1/0/0 14.1.1.1

NOTE:
mentioned here.
Run the display ip routing-table vpn-instance command on the PEs to view the routes to
the remote CEs.

------------------------------------------------------------------------------
14.1.1.0/24 Direct 0 0 D 14.1.1.1

14.1.1.1/32 Direct 0 0 D 127.0.0.1
14.1.1.255/32 Direct 0 0 D 127.0.0.1
34.1.1.0/24 IBGP 255 0 RD 3.3.3.9
[PE1] display ip routing-table vpn-instance vpnb

------------------------------------------------------------------------------
Routing Tables: vpnb
14.1.1.0/24 Direct 0 0 D 14.1.1.1

14.1.1.1/32 Direct 0 0 D 127.0.0.1
14.1.1.255/32 Direct 0 0 D 127.0.0.1
34.1.1.0/24 IBGP 255 0 RD 3.3.3.9
Run the ping 34.1.1.2 command on CE1, and the ping is successful. Run the display interface
command on PE2 to view traffic statistics on GE1/0/0 and GE3/0/0. The command output
shows that there are packets passing through GE1/0/0 but no packet passing through GE3/0/0.
This indicates that the two VPN instances have overlapping address spaces but they are
isolated from each other.
Configuration Files
#
sysname PE1
#
ipv4-family
#
ipv4-family
#
mpls lsr-id 1.1.1.9
mpls
#
mpls ldp
#
ip address 12.1.1.1 255.255.255.0
mpls
mpls ldp
#
ip address 14.1.1.1 255.255.255.0
#
ip address 14.1.1.1 255.255.255.0
#
interface LoopBack0
ip address 1.1.1.9 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 3.3.3.9 enable
#
ipv4-family vpnv4
policy vpn-target
peer 3.3.3.9 enable
#
import-route direct
#
ospf 1
area 0.0.0.0
network 12.1.1.0 0.0.0.255
network 1.1.1.9 0.0.0.0
#
return
#
sysname P
#
mpls lsr-id 2.2.2.9
mpls
#
mpls ldp
#
ip address 12.1.1.2 255.255.255.0
mpls
mpls ldp
#
ip address 23.1.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack0
ip address 2.2.2.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 12.1.1.0 0.0.0.255
network 23.1.1.0 0.0.0.255
network 2.2.2.9 0.0.0.0
#
return
#
sysname PE2
#
ipv4-family
#
ipv4-family
#
mpls lsr-id 3.3.3.9
mpls
#
mpls ldp
#
ip address 34.1.1.1 255.255.255.0
#
ip address 23.1.1.2 255.255.255.0
mpls
mpls ldp
#
ip address 34.1.1.1 255.255.255.0
#
interface LoopBack0
ip address 3.3.3.9 255.255.255.255
#
bgp 100
#
ipv4-family unicast

1210
peer 1.1.1.9 enable
#
ipv4-family vpnv4
policy vpn-target
peer 1.1.1.9 enable
#
import-route direct
#
import-route direct
#
ospf 1
area 0.0.0.0
network 23.1.1.0 0.0.0.255
network 3.3.3.9 0.0.0.0
#
return
Configuration file of CE1
#
sysname CE1
#
ip address 14.1.1.2 255.255.255.0
#
ip route-static 0.0.0.0 0.0.0.0 GigabitEthernet 1/0/0 14.1.1.1
#
return
#
sysname CE2
#
ip address 34.1.1.2 255.255.255.0
#
#
return
#
sysname CE3
#
ip address 14.1.1.2 255.255.255.0
#
#
return
#
sysname CE4
#
ip address 34.1.1.2 255.255.255.0
#
#
return
13.4.11 Example for Configuring Communication between Local

VPNs
As shown in Figure 13-4-11, company A and company B realize communication between

their respective headquarters and branches through BGP/MPLS IP VPN. The network deployment is
as follows:
 CE1 connects to the headquarters of company A, and CE3 connects to the branches of company
A. CE1 and CE3 belong to vpna.
 CE2 connects to the headquarters of company B, and CE4 connects to the branches of company
B. CE2 and CE4 belong to vpnb.
Headquarters of company A and headquarters of company B need to communicate with each other
for business.
Figure 13-4-11 Networking diagram for configuring communication between local VPNs
1. Configure VPN instances on PE1 and configure different VPN targets for the instances
to isolate VPNs.
2. On PE1, bind the VPN instances to the interfaces connected to CEs to provide access for VPN
users.
3. Import direct routes to the local CEs into the VPN routing table on PE1. On each CE
connected to PE1, configure a static route to the other local CE to enable the CEs to
Procedure
1. # Assign IP addresses to interfaces on CEs according to Figure 13-4-11.
# Configure CE1.
The configuration on CE2 is similar to the configuration on CE1 and is not mentioned here.
# Configure PE1.
[PE1-vpn-instance-vpna-af-ipv4] vpn-target 111:1 222:2 import-extcommunity
[PE1-vpn-instance-vpnb-af-ipv4] vpn-target 222:2 export-extcommunity
[PE1-vpn-instance-vpnb-af-ipv4] vpn-target 222:2 111:1 import-extcommunity
Each PE can ping its connected CE. The information displayed on PE1 and CE1 is used as
an example.


0.00% packet loss
3. Configure BGP and import the direct routes to local CEs to the VPN routing table.
# Configure PE1.
[PE1] bgp 100

[PE1–bgp-vpna] import-route direct
[PE1–bgp-vpna] quit
[PE1–bgp-vpnb] import-route direct
[PE1–bgp-vpnb] quit
[PE1–bgp] quit
4. Configure static routes on the CEs.
# Configure CE1.
[CE1] ip route-static 10.2.1.0 24 10.1.1.2
# Configure CE2.
After the configuration is complete, run the display ip routing-table vpn-instance vpna
command on PE1. The command output shows that the VPNs have imported routes of
each other. The VPN instance vpna is used as an example.

------------------------------------------------------------------------------
10.1.1.0/24 Direct 0 0 D 10.1.1.2

10.1.1.2/32 Direct 0 0 D 127.0.0.1
10.1.1.255/32 Direct 0 0 D 127.0.0.1
10.2.1.0/24 BGP 255 0 D 10.2.1.2
10.2.1.2/32 BGP 255 0 D 127.0.0.1 InLoopBack0
CE1 and CE2 can ping each other.
[CE1] ping 10.2.1.1

0.00% packet loss
Configuration Files
#
sysname PE1
#
ipv4-family
vpn-target 111:1 222:2 import-extcommunity
#
ipv4-family
vpn-target 222:2 111:1 import-extcommunity
#
ip address 10.1.1.2 255.255.255.0
#
ip address 10.2.1.2 255.255.255.0
#
bgp 100
#
ipv4-family unicast
#
import-route direct
#
import-route direct
#
return
#
sysname CE1
#
ip address 10.1.1.1 255.255.255.0
#
ip route-static 10.2.1.0 255.255.255.0 10.1.1.2
#
return
#
sysname CE2
#
ip address 10.2.1.1 255.255.255.0
#
ip route-static 10.1.1.0 255.255.255.0 10.2.1.2
#
return
13.4.12 Example for Configuring Hub and Spoke
A bank wants to realize secure communication between its headquarters and branches through
MPLS VPN. VPN traffic from branches passes the headquarters so that the headquarters can
monitor the traffic. The Hub and Spoke networking can meet the bank's needs. As shown in Figure
13-4-12, the Spoke-CEs connect to branches, and the Hub-CE connects to the headquarters. All
traffic transmitted between Spoke-CEs is forwarded by the Hub-CE.
Figure 13-4-12 Networking diagram for configuring Hub and Spoke

1. Configure an IGP protocol on the backbone network to enable the Hub-PE and Spoke-PEs
to communicate with each other.
2. Configure basic MPLS capabilities and MPLS LDP on the backbone network to set up
LDP LSPs.
3. Set up MP-IBGP peer relationships between the Hub-PE and the Spoke-PEs. The Spoke-PEs do
not need to set up an MP-IBGP peer relationship or exchange VPN routing information.
4. Create two VPN instances on the Hub-PE. One is used to receive routes from Spoke-PEs,
and the other is used to advertise routes to the Spoke-PEs. Set import target of the first VPN
instance to 100:1 and the export target of the other VPN instance to 200:1.
5. Create a VPN instance on the Spoke-PEs. Set the export target of the VPN instance to 100:1
and the import target to 200:1.
6. Configure EBGP on the CEs and PEs to enable them to exchange VPN routing information.
Configure Hub-PE to allow Hub-PE to receive the route with the AS repeated for one time.
Procedure
1. Configure OSPF on the backbone network to enable the Hub-PE and Spoke-PEs to
# Configure Spoke-PE1.

sysname Spoke-PE1 [Spoke-PE1]
interface loopback 1
[Spoke-PE1-LoopBack1] ip address 1.1.1.9 32
[Spoke-PE1-LoopBack1] quit
[Spoke-PE1] interface gigabitethernet 2/0/0
[Spoke-PE1-GigabitEthernet2/0/0] ip address 10.1.1.1 24
[Spoke-PE1-GigabitEthernet2/0/0] quit
[Spoke-PE1] ospf 1
[Spoke-PE1-ospf-1] area 0
[Spoke-PE1-ospf-1-area-0.0.0.0] network 10.1.1.0 0.0.0.255
[Spoke-PE1-ospf-1-area-0.0.0.0] network 1.1.1.9 0.0.0.0
[Spoke-PE1-ospf-1-area-0.0.0.0] quit
[Spoke-PE1-ospf-1] quit
The configuration on the Hub-PE and Spoke-PE2 is similar to the configuration on Spoke-
PE1 and is not mentioned here.
After the configuration is complete, Hub-PE can establish OSPF neighbor relationships with
the Spoke-PEs. Run the display ospf peer command on the PEs. The command output shows
that the status of OSPF neighbor relationships is Full. Run the display ip routing-table
command.
The command output shows that the Hub-PE and the Spoke-PEs have learned the route to
the loopback interface of each other.
LDP LSPs.
# Configure the Hub-PE.
[Hub-PE] mpls lsr-id 2.2.2.9

[Hub-PE] mpls
[Hub-PE-mpls] label advertise non-null
[Hub-PE-mpls] quit
[Hub-PE] mpls ldp
[Hub-PE-mpls-ldp] quit
[Hub-PE] interface gigabitethernet 1/0/0
[Hub-PE-GigabitEthernet1/0/0] mpls
[Hub-PE-GigabitEthernet1/0/0] mpls ldp
[Hub-PE-GigabitEthernet1/0/0] quit
[Hub-PE-GigabitEthernet2/0/0] mpls
[Hub-PE-GigabitEthernet2/0/0] mpls ldp
# The configuration on the Spoke-PEs is similar to the configuration on the Hub-PE and is
not mentioned here.
After the configuration is complete, the Hub-PE can set up LDP peer relationships with the
Spoke-PEs. Run the display mpls ldp session command on the PEs. In the command
output, the state is Operational. Run the display mpls ldp lsp command. Information about
the established LDP LSPs is displayed.
NOTE:
The import target of the VPN instances on the Hub-PE is the export target of the VPN
instance on the Spoke-PEs. The import target and export target on the Hub-PE are different.
The import VPN target on the Spoke-PEs is the export VPN target on the Hub-PE.
[Spoke-PE1] ip vpn-instance vpna

[Spoke-PE1-vpn-instance-vpna] ipv4-family
[Spoke-PE1-vpn-instance-vpna-af-ipv4] route-distinguisher 100:1
[Spoke-PE1-vpn-instance-vpna-af-ipv4] vpn-target 100:1 export-extcommunity
[Spoke-PE1-vpn-instance-vpna-af-ipv4] vpn-target 200:1 import-
extcommunity [Spoke-PE1-vpn-instance-vpna-af-ipv4] quit
[Spoke-PE1-vpn-instance-vpna] quit

1210
[Spoke-PE1-GigabitEthernet1/0/0] ip binding vpn-instance vpna
#Configure Spoke-PE2.
[Spoke-PE2] ip vpn-instance vpna

[Spoke-PE2-vpn-instance-vpna] ipv4-family
[Spoke-PE2-vpn-instance-vpna-af-ipv4] route-distinguisher 100:3
[Spoke-PE2-vpn-instance-vpna-af-ipv4] vpn-target 100:1 export-extcommunity
[Spoke-PE2-vpn-instance-vpna-af-ipv4] vpn-target 200:1 import-
extcommunity [Spoke-PE2-vpn-instance-vpna-af-ipv4] quit
[Spoke-PE2-vpn-instance-vpna] quit
[Spoke-PE2-GigabitEthernet1/0/0] ip binding vpn-instance vpna
[Hub-PE] ip vpn-instance vpn_in

[Hub-PE-vpn-instance-vpn_in] ipv4-family
[Hub-PE-vpn-instance-vpn_in-af-ipv4] route-distinguisher 100:21
[Hub-PE-vpn-instance-vpn_in-af-ipv4] vpn-target 100:1 import-extcommunity
[Hub-PE-vpn-instance-vpn_in-af-ipv4] quit
[Hub-PE-vpn-instance-vpn_in] quit
[Hub-PE] ip vpn-instance vpn_out
[Hub-PE-vpn-instance-vpn_out] ipv4-family
[Hub-PE-vpn-instance-vpn_out-af-ipv4] route-distinguisher 100:22
[Hub-PE-vpn-instance-vpn_out-af-ipv4] vpn-target 200:1 export-extcommunity
[Hub-PE-vpn-instance-vpn_out-af-ipv4] quit
[Hub-PE-vpn-instance-vpn_out] quit
[Hub-PE-GigabitEthernet3/0/0] ip binding vpn-instance vpn_in
[Hub-PE-GigabitEthernet3/0/0] ip address 110.1.1.2 24
[Hub-PE-GigabitEthernet4/0/0] ip binding vpn-instance vpn_out
[Hub-PE-GigabitEthernet4/0/0] ip address 110.2.1.2 24

# Configure Spoke-CE1.
[Huawei] sysname Spoke-CE1
[Spoke-CE1] interface gigabitethernet 1/0/0
[Spoke-CE1-GigabitEthernet1/0/0] ip address 100.1.1.1 24
[Spoke-CE1-GigabitEthernet1/0/0] quit
The configuration on other CEs is similar to the configuration on Spoke-CE1 and is

not mentioned here.
After the configuration is complete, run the display ip vpn-instance verbose command on
the PEs to check the configuration of VPN instances. Each PE can ping its connected CE by
using the ping -vpn-instance vpn-name ip-address command.
NOTE:
If a PE has multiple interfaces bound to the same VPN instance, you need to specify the source
IP addresses by setting -a source-ip-address in the ping -vpn-instance vpn-instance-name -a
4. Set up EBGP peer relationships between the PEs and CEs and import VPN routes into BGP.
NOTE:
To accept the routes advertised by Hub-CE, configure the Hub-PE to allow AS number to
be repeated once.
[Spoke-CE1] bgp 65410

[Spoke-CE1-bgp] peer 100.1.1.2 as-number 100
[Spoke-CE1-bgp] import-route direct
[Spoke-CE1-bgp] quit
[Spoke-PE1] bgp 100

[Spoke-PE1-bgp] ipv4-family vpn-instance vpna
[Spoke-PE1-bgp-vpna] peer 100.1.1.1 as-number 65410
[Spoke-PE1-bgp-vpna] import-route direct
[Spoke-PE1-bgp-vpna] quit
[Spoke-PE1-bgp] quit
[Spoke-CE2] bgp 65420

[Spoke-CE2-bgp] peer 120.1.1.2 as-number 100
[Spoke-CE2-bgp] import-route direct
[Spoke-CE2-bgp] quit
[Spoke-PE2] bgp 100

[Spoke-PE2-bgp] ipv4-family vpn-instance vpna
[Spoke-PE2-bgp-vpna] peer 120.1.1.1 as-number 65420
[Spoke-PE2-bgp-vpna] import-route direct
[Spoke-PE2-bgp-vpna] quit
[Spoke-PE2-bgp] quit
# Configure the Hub-CE.
[Hub-CE] bgp 65430

[Hub-CE-bgp] peer 110.1.1.2 as-number 100
[Hub-CE-bgp] peer 110.2.1.2 as-number 100
[Hub-CE-bgp] import-route direct
[Hub-CE-bgp] quit
[Hub-PE] bgp 100

[Hub-PE-bgp] ipv4-family vpn-instance vpn_in
[Hub-PE-bgp-vpn_in] peer 110.1.1.1 as-number 65430
[Hub-PE-bgp-vpn_in] import-route direct
[Hub-PE-bgp-vpn_in] quit
[Hub-PE-bgp] ipv4-family vpn-instance vpn_out
[Hub-PE-bgp-vpn_out] peer 110.2.1.1 as-number 65430
[Hub-PE-bgp-vpn_out] peer 110.2.1.1 allow-as-loop 1
[Hub-PE-bgp-vpn_out] import-route direct
[Hub-PE-bgp-vpn_out] quit
[Hub-PE-bgp] quit
After the configuration is complete, run the display bgp vpnv4 all peer command on the
PEs. The command output shows that the BGP peer relationships have been set up between
the PEs and CEs and are in Established state.
5. Set up MP-IBGP peer relationships between the Spoke-PEs and Hub-PE.
NOTE:
The Spoke-PEs do not need to allow the repeated AS number, because the router does not
check the AS_Path attribute in the routing information advertised by the IBGP peers.
[Spoke-PE1] bgp 100

[Spoke-PE1-bgp] peer 2.2.2.9 as-number 100
[Spoke-PE1-bgp] peer 2.2.2.9 connect-interface loopback 1
[Spoke-PE1-bgp] ipv4-family vpnv4
[Spoke-PE1-bgp-af-vpnv4] peer 2.2.2.9 enable
[Spoke-PE1-bgp-af-vpnv4] quit
[Spoke-PE2] bgp 100

[Spoke-PE2-bgp] peer 2.2.2.9 as-number 100
[Spoke-PE2-bgp] peer 2.2.2.9 connect-interface loopback 1
[Spoke-PE2-bgp] ipv4-family vpnv4
[Spoke-PE2-bgp-af-vpnv4] peer 2.2.2.9 enable
[Spoke-PE2-bgp-af-vpnv4] quit
[Hub-PE] bgp 100

[Hub-PE-bgp] peer 1.1.1.9 as-number 100
[Hub-PE-bgp] peer 1.1.1.9 connect-interface loopback 1
[Hub-PE-bgp] peer 3.3.3.9 as-number 100
[Hub-PE-bgp] peer 3.3.3.9 connect-interface loopback 1
[Hub-PE-bgp] ipv4-family vpnv4
[Hub-PE-bgp-af-vpnv4] peer 1.1.1.9 enable
[Hub-PE-bgp-af-vpnv4] peer 3.3.3.9 enable
[Hub-PE-bgp-af-vpnv4] quit
After the configuration is complete, run the display bgp peer or display bgp vpnv4 all
peer command on the PEs. The command output shows that the BGP peer relationships
have been set up between the Spoke-PEs and the Hub-PE and are in Established state.
After the configuration is complete, the Spoke-CEs can ping each other. Run the tracert
command on the CEs. The command output shows that the traffic between the Spoke-CEs
is forwarded through the Hub-CE. You can also deduce the number of forwarding devices
between the Spoke-CEs based on the TTL in the ping result.
The information displayed on Spoke-CE1 is used as an example.
[Spoke-CE1] ping 120.1.1.1

0.00% packet loss
[Spoke-CE1] tracert 120.1.1.1
traceroute to 120.1.1.1(120.1.1.1), max hops: 30 ,packet length: 40,press CTRL
_C to break
1 100.1.1.2 10 ms 2 ms 1 ms
2 110.2.1.2 < AS=100 > 10 ms 2 ms 2 ms
3 110.2.1.1 < AS=100 > 10 ms 2 ms 2 ms
4 110.1.1.2 < AS=65430 > 10 ms 2 ms 2 ms
5 120.1.1.2 < AS=100 > 10 ms 2 ms 2 ms
6 120.1.1.1 < AS=100 > 10 ms 2 ms 5 ms
Run the display bgp routing-table command on the Spoke-CEs. The command output
shows the repeated AS number in AS paths of the BGP routes to the remote Spoke-CE.
The information displayed on Spoke-CE1 is used as an example.
[Spoke-CE1] display bgp routing-table


Path/Ogn
*> 100.1.1.0/24
*> 100.1.1.1/32
*> 110.1.1.0/24
65430?
*> 110.2.1.0/24
*> 120.1.1.0/24
100?
*> 127.0.0.0
*> 127.0.0.1/32
Configuration Files
 Configuration file of Spoke-CE1
#
sysname Spoke-CE1
#
ip address 100.1.1.1 255.255.255.0
#
bgp 65410
#
ipv4-family unicast
import-route direct
#
return
 Configuration file of Spoke-PE1
#
sysname Spoke-PE1
#
ipv4-family
#
mpls lsr-id 1.1.1.9
mpls
label advertise non-null
#
mpls ldp
#
ip address 100.1.1.2 255.255.255.0
#
ip address 10.1.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 2.2.2.9 enable
#
ipv4-family vpnv4
policy vpn-target
peer 2.2.2.9 enable
#
import-route direct
#
ospf 1
area 0.0.0.0
network 10.1.1.0 0.0.0.255
network 1.1.1.9 0.0.0.0
#
return
 Configuration file of Spoke-PE2
#
sysname Spoke-PE2
#
ipv4-family
#
mpls lsr-id 3.3.3.9
mpls
#
mpls ldp
#
ip address 120.1.1.2 255.255.255.0
#
ip address 11.1.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 2.2.2.9 enable
#
ipv4-family vpnv4
policy vpn-target
peer 2.2.2.9 enable
#
import-route direct
#
ospf 1
area 0.0.0.0
network 3.3.3.9 0.0.0.0
network 11.1.1.0 0.0.0.255
#
return
 Configuration file of Spoke-CE2
#
sysname Spoke-CE2
#
ip address 120.1.1.1 255.255.255.0
#
bgp 65420
#
ipv4-family unicast
import-route direct
#
return
 Configuration file of Hub-CE
#
sysname Hub-CE
#
ip address 110.1.1.1 255.255.255.0
#
ip address 110.2.1.1 255.255.255.0
#
bgp 65430
#
ipv4-family unicast
import-route direct
#
return
 Configuration file of Hub-PE
#
sysname Hub-PE
#
ip vpn-instance vpn_in
ipv4-family
#
ip vpn-instance vpn_out
ipv4-family
#
mpls lsr-id 2.2.2.9
mpls
#
mpls ldp
#
ip address 10.1.1.2 255.255.255.0
mpls
mpls ldp
#
ip address 11.1.1.2 255.255.255.0
mpls
mpls ldp
#
ip binding vpn-instance vpn_in
ip address 110.1.1.2 255.255.255.0
#
ip binding vpn-instance vpn_out
ip address 110.2.1.2 255.255.255.0
#

1210
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 1.1.1.9 enable
peer 3.3.3.9 enable
#
ipv4-family vpnv4
policy vpn-target
peer 1.1.1.9 enable
peer 3.3.3.9 enable
#
ipv4-family vpn-instance vpn_in
import-route direct
#
ipv4-family vpn-instance vpn_out
peer 110.2.1.1 allow-as-loop
import-route direct
#
ospf 1
area 0.0.0.0
network 2.2.2.9 0.0.0.0
network 10.1.1.0 0.0.0.255
network 11.1.1.0 0.0.0.255
#
return
13.4.13 Example for Configuring Multi-VPN-Instance CE
The headquarters and branches of a company need to communicate through MPLS VPN, and two
services of the company must be isolated. To reduce hardware costs, the company wants the
branches to connect to the PE through one CE.
As shown in Figure 13-4-13, the networking requirements are as follows:
 CE1 and CE2 connect to the headquarters. CE1 belongs to vpna, and CE2 belongs to vpnb.
 The multi-VPN-instance CE (MCE) device connects to vpna and vpnb of the branches through
CE3 and CE4.
Users in the same VPN need to communicate with each other, but users in different VPNs must
be isolated.
Figure 13-4-13 Networking diagram for configuring MCE
1. Configure OSPF between PEs to implement interworking between them and configure
MP-IBGP to exchange VPN routing information.
2. Configure basic MPLS capabilities and MPLS LDP on the PEs to set up LDP LSPs.
3. Create VPN instances vpna and vpnb on the MCEs and PEs to isolate services.
4. Set up EBGP peer relationships between PE1 and its connected CEs, and import BGP routes
to the VPN routing table on PE1.
5. Configure routing between the MCE and VPN sites and between the MCE and PE2.
Procedure
1. Configure OSPF on PEs of the backbone network.
# Configure PE1.
[PE1] ospf
[PE1-ospf-1] area 0
[PE1-ospf-1] quit
The configuration on PE2 is similar to the configuration on PE1 and is not mentioned
here. After the configuration is complete, PEs can learn Loopback1 address of each other.

------------------------------------------------------------------------------
1.1.1.9/32 OSPF 10 1 D 172.1.1.1
2.2.2.9/32
127.0.0.0/8
127.0.0.1/32
127.255.255.255/32
172.1.1.0/24
172.1.1.2/32
172.1.1.255/32
255.255.255.255/32
2. Configure basic MPLS capabilities and MPLS LDP on the PEs to set up LDP LSPs.
# Configure PE1.
[PE1] mpls
[PE1-mpls] quit
[PE1] mpls ldp
[PE1-mpls-ldp] quit
After the configuration is complete, run the display mpls ldp session command on the PEs.
The command output shows that the MPLS LDP session between the PEs is in Operational
state.

deleted.
------------------------------------------------------------------------------
------------------------------------------------------------------------------
------------------------------------------------------------------------------
3. Configure VPN instances on the PEs. On PE1, bind the VPN instances to the interfaces
connected to CE1 and CE2 respectively. On PE2, bind the VPN instances to the
interfaces connected to the MCE.
# Configure PE1.

# Configure PE2.

[PE2] interface gigabitethernet 2/0/0.1
[PE2-GigabitEthernet2/0/0.1] dot1q termination vid 10
[PE2-GigabitEthernet2/0/0.1] arp broadcast enable
[PE2-GigabitEthernet2/0/0.1] ip binding vpn-instance vpna
[PE2-GigabitEthernet2/0/0.1] ip address 192.1.1.1 24
[PE2-GigabitEthernet2/0/0.1] quit
[PE2] interface gigabitethernet 2/0/0.2
[PE2-GigabitEthernet2/0/0.2] dot1q termination vid 20
[PE2-GigabitEthernet2/0/0.2] arp broadcast enable
[PE2-GigabitEthernet2/0/0.2] ip binding vpn-instance vpnb
[PE2-GigabitEthernet2/0/0.2] ip address 192.2.1.1 24
[PE2-GigabitEthernet2/0/0.2] quit
4. Configure VPN instances on the MCE, and bind the VPN instances to the interfaces
connected to CE3, CE4, and PE2.
[Huawei] sysname MCE
[MCE] ip vpn-instance vpna
[MCE-vpn-instance-vpna] ipv4-family
[MCE-vpn-instance-vpna-af-ipv4] route-distinguisher 300:1
[MCE-vpn-instance-vpna-af-ipv4] vpn-target 111:1 both
[MCE-vpn-instance-vpna-af-ipv4] quit
[MCE-vpn-instance-vpna] quit
[MCE] ip vpn-instance vpnb
[MCE-vpn-instance-vpnb] ipv4-family
[MCE-vpn-instance-vpnb-af-ipv4] route-distinguisher 300:2
[MCE-vpn-instance-vpnb-af-ipv4] vpn-target 222:2 both
[MCE-vpn-instance-vpnb-af-ipv4] quit
[MCE-vpn-instance-vpnb] quit
[MCE] interface gigabitethernet 3/0/0
[MCE-GigabitEthernet3/0/0] ip binding vpn-instance vpna
[MCE-GigabitEthernet3/0/0] ip address 10.3.1.2 24
[MCE-GigabitEthernet3/0/0] quit
[MCE] interface gigabitethernet 4/0/0
[MCE-GigabitEthernet4/0/0] ip binding vpn-instance vpnb
[MCE-GigabitEthernet4/0/0] ip address 10.4.1.2 24
[MCE-GigabitEthernet4/0/0] quit
[MCE] interface gigabitethernet 1/0/0.1
[MCE-GigabitEthernet1/0/0.1] dot1q termination vid 10
[MCE-GigabitEthernet1/0/0.1] arp broadcast enable
[MCE-GigabitEthernet1/0/0.1] ip binding vpn-instance vpna
[MCE-GigabitEthernet1/0/0.1] ip address 192.1.1.2 24
[MCE-GigabitEthernet1/0/0.1] quit
[MCE] interface gigabitethernet 1/0/0.2
[MCE-GigabitEthernet1/0/0.2] dot1q termination vid 20
[MCE-GigabitEthernet1/0/0.2] arp broadcast enable
[MCE-GigabitEthernet1/0/0.2] ip binding vpn-instance vpnb
[MCE-GigabitEthernet1/0/0.2] ip address 192.2.1.2 24
[MCE-GigabitEthernet1/0/0.2] quit
5. Set up an MP-IBGP peer relationship between PEs. Set up EBGP peer relationships between
PE1 and CE1, and between PE1 and CE2.
# Configure CE1.
[CE1] bgp 65410
[CE1-bgp] ipv4-family unicast
[CE1-bgp-af-ipv4] import-route direct
[CE1-bgp-af-ipv4] quit
[CE1-bgp] quit
The configuration on other PE1 and PE2 is similar to the configuration on CE1 and is
not mentioned here.
After the configuration is complete, run the display bgp vpnv4 all peer command on PE1.
The command output shows that the PE1 has set up an IBGP peer relationship with PE2 and
EBGP
peer relationships with CE1 and CE2. The peer relationships are in Established state.


PrefRcv
2.2.2.9 4 100 288 287 0 01:19:16 Established 4
Peer of IPv4-family for vpn instance :
VPN-Instance vpna, router ID 1.1.1.9:

10.1.1.1 4 65410 9 11 0 00:04:14 Established 4
VPN-Instance vpnb, router ID 1.1.1.9:

10.2.1.1 4 65420 9 12 0 00:04:09 Established 3
6. Configure OSPF multi-instance between the MCE and PE2.
# Configure PE2.
[PE2] ospf 100 vpn-instance vpna

[PE2-ospf-100] area 0
[PE2-ospf-100] import-route bgp
[PE2-ospf-100] quit
[PE2] ospf 200 vpn-instance vpnb
[PE2-ospf-200] area 0
1210
[PE2-ospf-200] import-route bgp
[PE2-ospf-200] quit
[PE2] bgp 100
[PE2-bgp-vpna] import-route ospf 100
[PE2-bgp-vpna] quit
[PE2-bgp-vpnb] import-route ospf 200
[PE2-bgp-vpnb] quit
[PE2-bgp] quit
# Configure the MCE.
[MCE] ospf 100 vpn-instance vpna

[MCE-ospf-100] area 0
[MCE-ospf-100-area-0.0.0.0] network 192.1.1.0 0.0.0.255
[MCE-ospf-100-area-0.0.0.0] quit
[MCE-ospf-100] quit
[MCE] ospf 200 vpn-instance vpnb
[MCE-ospf-200] area 0
[MCE-ospf-200-area-0.0.0.0] network 192.2.1.0 0.0.0.255
[MCE-ospf-200-area-0.0.0.0] quit
[MCE-ospf-200] quit
7. Configure RIPv2 between the MCE and CE3, and between the MCE and CE4.
# Configure the MCE.
[MCE] rip 100 vpn-instance vpna

[MCE-rip-100] version 2
[MCE-rip-100] network 10.0.0.0
[MCE-rip-100] import-route ospf 100
[MCE-rip-100] quit
[MCE] rip 200 vpn-instance vpnb
[MCE-rip-200] version 2
[MCE-rip-200] network 10.0.0.0
[MCE-rip-200] import-route ospf 200
[MCE-rip-200] quit
# Configure CE3.
[CE3] rip 100
[CE3-rip-100] version 2
[CE3-rip-100] network 10.0.0.0
[CE3-rip-100] import-route direct
# Configure CE4.
[CE4] rip 200
[CE4-rip-200] version 2
[CE4-rip-200] network 10.0.0.0
[CE4-rip-200] import-route direct
8. Disable loop detection on the MCE device and import RIP routes.
[MCE] ospf 100 vpn-instance vpna

[MCE-ospf-100] vpn-instance-capability simple
[MCE-ospf-100] import-route rip 100
[MCE-ospf-100] quit
[MCE] ospf 200 vpn-instance vpnb
[MCE-ospf-200] vpn-instance-capability simple
[MCE-ospf-200] import-route rip 200
[MCE-ospf-200] quit
After the configuration is complete, run the display ip routing-table vpn-instance

command on the MCE. The command output shows the route to the remote CE.
The VPN instance vpna is used as an example.
[MCE] display ip routing-table vpn-instance vpna

------------------------------------------------------------------------------
Destination/Mask Proto Pre Cost

10.1.1.0/24 O_ASE 150 1
GigabitEthernet1/0/0.1
10.3.1.0/24 Direct 0 0 D 10.3.1.2
10.3.1.2/32 Direct 0 0 D 127.0.0.1
10.3.1.255/32 Direct 0 0 D 127.0.0.1
192.1.1.0/24 Direct 0 0 D 192.1.1.2
192.1.1.2/32 Direct 0 0 D 127.0.0.1
192.1.1.255/32 Direct 0
255.255.255.255/32 Direct 0
Run the display ip routing-table vpn-instance command on the PE. The command output
shows the route to the remote CE.
The VPN instance vpna on PE1 is used as an example.

------------------------------------------------------------------------------
Destination/Mask Interface
10.1.1.0/24
10.1.1.2/32
10.1.1.255/32 Direct 0 0 D 127.0.0.1
10.3.1.0/24 IBGP 255 2 RD 2.2.2.9
192.1.1.0/24 IBGP 255 0 RD 2.2.2.9
CE1 and CE3 can ping each other, and CE2 and CE4 can ping each other.
The ping from CE1 to CE3 is used as an example.
[CE1] ping 10.3.1.1


1210
0.00% packet loss
CE1 cannot ping CE2 or CE4. CE3 cannot ping CE2 or CE4.
For example, if you ping CE4 from CE1, the following information is displayed:
[CE1] ping 10.4.1.1

Request time out
Request time out
Request time out
Request time out
Request time out

100.00% packet loss
Configuration Files
#
sysname CE1
#
ip address 10.1.1.1 255.255.255.0
#
bgp 65410
#
ipv4-family unicast
import-route direct
#
return
#
sysname CE2
#
ip address 10.2.1.1 255.255.255.0
#
bgp 65420
#
ipv4-family unicast
import-route direct
#
return
#
sysname PE1
#
ipv4-family
#
ipv4-family
#
mpls lsr-id 1.1.1.9
mpls
#
mpls ldp
#
ip address 10.1.1.2 255.255.255.0
#
ip address 10.2.1.2 255.255.255.0
#
ip address 172.1.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 2.2.2.9 enable
#
ipv4-family vpnv4
policy vpn-target
peer 2.2.2.9 enable
#
import-route direct
#
import-route direct
#
ospf 1
area 0.0.0.0
network 1.1.1.9 0.0.0.0
network 172.1.1.0 0.0.0.255
#
return
#
sysname PE2
#
ipv4-family
#
ipv4-family
#
mpls lsr-id 2.2.2.9
mpls
#
mpls ldp
#
ip address 172.1.1.2 255.255.255.0
mpls
mpls ldp
#
interface GigabitEthernet2/0/0.1
dot1q termination vid 10
arp broadcast enable
ip address 192.1.1.1 255.255.255.0
#
ip address 192.2.1.1 255.255.255.0
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 1.1.1.9 enable
#
ipv4-family vpnv4
policy vpn-target
peer 1.1.1.9 enable
#
import-route ospf 100
#
#
ospf 1
area 0.0.0.0
network 2.2.2.9 0.0.0.0
network 172.1.1.0 0.0.0.255
#
ospf 100 vpn-instance vpna
import-route bgp
area 0.0.0.0
network 192.1.1.0 0.0.0.255
#
ospf 200 vpn-instance vpnb
import-route bgp
area 0.0.0.0
network 192.2.1.0 0.0.0.255
#
return
 Configuration file of the MCE
#
sysname MCE
#
ipv4-family
#
ipv4-family
#
ip address 192.1.1.2 255.255.255.0
#
ip address 192.2.1.2 255.255.255.0
#
ip address 10.3.1.2 255.255.255.0
#
ip address 10.4.1.2 255.255.255.0
#
ospf 100 vpn-instance vpna
vpn-instance-capability simple
area 0.0.0.0
network 192.1.1.0 0.0.0.255
#
ospf 200 vpn-instance vpnb
vpn-instance-capability simple
area 0.0.0.0
network 192.2.1.0 0.0.0.255
#
rip 100 vpn-instance vpna
version 2
network 10.0.0.0
#
rip 200 vpn-instance vpnb
version 2
network 10.0.0.0
#
return
#
sysname CE3
#
ip address 10.3.1.1 255.255.255.0
#
rip 100 version 2
network 10.0.0.0
import-route direct
#
return
#
sysname CE4
#
ip address 10.4.1.1 255.255.255.0
#
rip 200 version 2
network 10.0.0.0
import-route direct
#
return
13.4.14 Example for Configuring PBR to an LSP for VPN Packets
As shown in Figure 13-4-14, the BGP/MPLS IP VPN backbone network consists of PE1, PE2, P1, and
P2. CE1 and CE2 connect to the backbone network through PE1 and PE2 respectively. The path
PE1->P2->PE2 is the primary LSP, and the path PE1->P1->PE2 is the backup LSP.
If the PBR is configured on PE1, packets of 10 to 1000 bytes long sent from CE1 to CE2 are
forwarded through P2.
Figure 13-4-14 Networking diagram for configuring the PBR to an LSP for VPN packets
1. Configure BGP/MPLS VPN according to Example for Configuring BGP/MPLS IP VPN.
2. Configure the PBR and policy node on the PE that requires the configuration of the PBR to
an LSP. Set a matching rule of IP packet length and specify an LSP for forwarding VPN
instance packets that meet the matching rule in the policy-based route view.
3. Apply the PBR to the outbound interface bound to the VPN instance on the PE.
Procedure
1. Configure BGP/MPLS VPN.
For the configuration procedure, refer to Example for Configuring BGP/MPLS IP VPN.
After the configuration is complete, run the display mpls lsp command to check LSPs on PE1.
[PE1] display mpls lsp

----------------------------------------------------------------------
LSP Information: BGP LSP
----------------------------------------------------------------------
FEC In/Out Label In/Out IF Vrf Name
10.1.1.0/24 15360/NULL -/- vpna
----------------------------------------------------------------------
LSP Information: LDP LSP
----------------------------------------------------------------------
FEC
2.2.2.9/32
2.2.2.9/32
3.3.3.9/32
3.3.3.9/32
4.4.4.9/32
4.4.4.9/32
1.1.1.9/32
The LSPs to PE2 have two outbound interfaces: GE1/0/0 and GE2/0/0.
2. Configure the PBR to an LSP on PE1.
[PE1] policy-based-route policy1 permit node 10

[PE1-policy-based-route-policy1-10] if-match packet-length 10 1000
[PE1-policy-based-route-policy1-10] apply lsp vpn vpna 10.3.1.1 3.3.3.9 172.3.1.2
[PE1-policy-based-route-policy1-10] quit
3. Enable the PBR on PE1.
[PE1] ip local policy-based-route policy1
4. Clear statistics on GE2/0/0 of PE1.
[PE1] quit
<PE1> reset counters interface GigabitEthernet 2/0/0
Ping CE2 from CE1 to check the forwarding path of the packets.
[CE1] ping –c 1500 –s 950 10.3.1.1
# Check packet statistics on the interface of PE1.
<PE1> display interface gigabitethernet 2/0/0

IP Sending Frames' Format is PKTFMT_ETHNT_2, Hardware address is 80fb-0635-45b6
: AUTO

Unicast:
Broadcast:
Discard:
CRC:
Jabbers:
Runts:
Ignoreds:

Unicast:
Broadcast:
Discard:
Collisions:
Late Collisions:

Run the display interface gigabitethernet 1/0/0 and display interface gigabitethernet 2/0/0
commands repeatedly on PE1 to check the change of packet statistics on interfaces of PE1.
The command output shows that packets are forwarded along the specified LSP.
Configuration Files
#
sysname PE1
#
ipv4-family
#
mpls lsr-id 1.1.1.9
mpls
#
mpls ldp
#
ip address 10.1.1.2 255.255.255.0
#
ip address 172.1.1.1 255.255.255.0
mpls
mpls ldp
#
ip address 172.3.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 3.3.3.9 enable
#
ipv4-family vpnv4
policy vpn-target
peer 3.3.3.9 enable
#
import-route direct
#
ospf 1
area 0.0.0.0
network 1.1.1.9 0.0.0.0
network 172.3.1.0 0.0.0.255
network 172.1.1.0 0.0.0.255
#
policy-based-route policy1 permit node 10
apply lsp vpn vpna 10.3.1.1 3.3.3.9 172.3.1.2
#
ip local policy-based-route policy1
#
return
#
sysname P1
#
mpls lsr-id 2.2.2.9
mpls
#
mpls ldp
#
ip address 172.1.1.2 255.255.255.0
mpls
mpls ldp
#
ip address 172.2.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 2.2.2.9 0.0.0.0
network 172.2.1.0 0.0.0.255
network 172.1.1.0 0.0.0.255
#
return
#
sysname PE2
#
ipv4-family
#
mpls lsr-id 3.3.3.9
mpls
#
mpls ldp
#
ip address 10.3.1.2 255.255.255.0
#
ip address 172.2.1.2 255.255.255.0
mpls
mpls ldp
#
ip address 172.4.1.2 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 1.1.1.9 enable
#
ipv4-family vpnv4
policy vpn-target
peer 1.1.1.9 enable
#
import-route direct
#
ospf 1
area 0.0.0.0
network 3.3.3.9 0.0.0.0
network 172.2.1.0 0.0.0.255
network 172.4.1.0 0.0.0.255
#
return
#
sysname P2
#
mpls lsr-id 4.4.4.9
mpls
#
mpls ldp
#
ip address 172.3.1.2 255.255.255.0
mpls
mpls ldp
#
ip address 172.4.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 4.4.4.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 4.4.4.9 0.0.0.0
network 172.3.1.0 0.0.0.255
network 172.4.1.0 0.0.0.255
#
return
#
sysname CE1
#
ip address 10.1.1.1 255.255.255.0
#
bgp 65410
#
ipv4-family unicast
import-route direct
#
return
#
sysname CE2
#
ip address 10.3.1.1 255.255.255.0
#
bgp 65430
#
ipv4-family unicast
import-route direct
#
return
13.4.15 Example for Configuring HoVPN
Figure 13-4-15 shows a hierarchical VPN network consisting of a provincial backbone network and
a city MPLS VPN network.
 The SPE is located on the provincial backbone network and connects to the city MPLS VPN
network.
 The UPE is located on the city network and connects to VPN users.
The routing and forwarding capabilities of the UPE are lower than those of the SPE and PEs. Th e
HoVPN networking can enable users in VPN-A to communicate with each other while reducing
the loads on the UPE.
Figure 13-4-15 Networking diagram for configuring HoVPN
1. Configure an IGP on the backbone network to implement IP interworking.
MPLS LSPs.
3. Set up MP-IBGP peer relationships between the UPE and SPE and between the PE and SPE
to exchange VPN routing information.
4. On the UPE and PEs, create VPN instances and set up EBGP peer relationships with CEs
to exchange VPN routing information.
5. On the SPE, create a VPN instance and specify the UPE as its underlayer PE (or user-end PE).
Advertise the default route of the VPN instance to the UPE to reduce the loads on the
UPE.
Procedure
1. Configure OSPF on the backbone network to implement IP interworking.
# Configure the UPE.
[Huawei] sysname UPE
[UPE] ospf
[UPE-ospf-1] area 0
[UPE-ospf-1-area-0.0.0.0] network 1.1.1.9 0.0.0.0
[UPE-ospf-1-area-0.0.0.0] network 172.1.1.0 0.0.0.255
[UPE-ospf-1-area-0.0.0.0] quit
[UPE-ospf-1] quit
The configuration on the SPE and PEs is similar to the configuration on the UPE and is
not mentioned here.
After the configuration is complete, OSPF neighbor relationships are set up between the
UPE, SPE, and PE. Run the display ospf peer command on these devices. The command
output shows that the neighbor relationships are in Full state. Run the display ip routing-
table command on these devices. The command output shows that they have learned the
route to the loopback interface of each other.
LDP LSPs.
[UPE] mpls lsr-id 1.1.1.9

[UPE] mpls [UPE-
mpls] quit [UPE]
mpls ldp [UPE-
mpls-ldp] quit
[UPE] interface gigabitethernet 2/0/0
[UPE-GigabitEthernet2/0/0] mpls
[UPE-GigabitEthernet2/0/0] mpls ldp
[UPE-GigabitEthernet2/0/0] quit
The configuration on the SPE and PEs is similar to the configuration on the UPE and is
not mentioned here.
After the configuration is complete, LDP sessions are established between UPE and SPE, and
between SPE and PE. Run the display mpls ldp session command on these devices. The
command output shows that the status is Operational. Run the display mpls ldp lsp
3. Set up MP-IBGP peer relationships between the UPE and SPE and between the PE and SPE.
[UPE] bgp 100

[UPE-bgp] peer 2.2.2.9 as-number 100
[UPE-bgp] peer 2.2.2.9 connect-interface loopback 1
[UPE-bgp] ipv4-family vpnv4
[UPE-bgp-af-vpnv4] peer 2.2.2.9 enable
[UPE-bgp-af-vpnv4] quit
[UPE-bgp] quit
# Configure the SPE.
[SPE] bgp 100

[SPE-bgp] peer 1.1.1.9 as-number 100
[SPE-bgp] peer 1.1.1.9 connect-interface loopback 1
[SPE-bgp] peer 3.3.3.9 as-number 100
[SPE-bgp] peer 3.3.3.9 connect-interface loopback 1
[SPE-bgp] ipv4-family vpnv4
[SPE-bgp-af-vpnv4] peer 1.1.1.9 enable
[SPE-bgp-af-vpnv4] peer 3.3.3.9 enable
[SPE-bgp-af-vpnv4] quit
[SPE-bgp] quit
# Configure the PE.
[PE] bgp 100

[PE-bgp] peer 2.2.2.9 as-number 100
[PE-bgp] peer 2.2.2.9 connect-interface loopback 1
[PE-bgp] ipv4-family vpnv4
[PE-bgp-af-vpnv4] peer 2.2.2.9 enable
[PE-bgp-af-vpnv4] quit
[PE-bgp] quit
4. On the UPE and PEs, create a VPN instance and set up EBGP peer relationships with the CEs.
[UPE] ip vpn-instance vpna

[UPE-vpn-instance-vpna] ipv4-family
[UPE-vpn-instance-vpna-af-ipv4] route-distinguisher 100:1
[UPE-vpn-instance-vpna-af-ipv4] vpn-target 1:1
[UPE-vpn-instance-vpna-af-ipv4] quit
[UPE-vpn-instance-vpna] quit
[UPE] interface gigabitethernet 1/0/0
[UPE-GigabitEthernet1/0/0] ip binding vpn-instance vpna
[UPE-GigabitEthernet1/0/0] ip address 10.1.1.2 24
[UPE-GigabitEthernet1/0/0] quit
[UPE] bgp 100
[UPE-bgp] ipv4-family vpn-instance vpna
[UPE-bgp-vpna] peer 10.1.1.1 as-number 65410
[UPE-bgp-vpna] import-route direct
[UPE-bgp-vpna] quit
[UPE-bgp] quit
# Configure CE1.
[CE1] bgp 65410
[CE1-bgp] quit
# Configure the PE.
[PE] ip vpn-instance vpna

[PE-vpn-instance-vpna] ipv4-family
[PE-vpn-instance-vpna-af-ipv4] route-distinguisher 100:2
[PE-vpn-instance-vpna-af-ipv4] vpn-target 1:1
[PE-vpn-instance-vpna-af-ipv4] quit
[PE-vpn-instance-vpna] quit
[PE-GigabitEthernet1/0/0] ip binding vpn-instance vpna
[PE-GigabitEthernet1/0/0] ip address 10.2.1.2 24
[PE] bgp 100
[PE-bgp] ipv4-family vpn-instance vpna
[PE-bgp-vpna] peer 10.2.1.1 as-number 65420
[PE-bgp-vpna] import-route direct
[PE-bgp-vpna] quit
[PE-bgp] quit
# Configure CE2.
[CE2] bgp 65420
[CE2-bgp] quit
After the configuration is complete, run the display ip vpn-instance verbose command on
the UPE and PEs to check the configuration of VPN instances. Run the ping -vpn-instance
command on the UPE and PEs to ping the connected CEs. The ping operations succeed.
NOTE:
If a PE has multiple interfaces bound to the same VPN instance, you need to specify the source
IP addresses by setting -a source-ip-address in the ping -vpn-instance vpn-instance-name -a
UPE is used as an example.
[UPE] display ip vpn-instance verbose

Address family ipv4
Create date : 2012/09/14 14:34:10
Log Interval : 5
5. On the SPE, create a VPN instance, specify the UPE as its underlayer PE, and advertise
the default route of the VPN instance to the UPE.
# Configure the VPN instance.
[SPE] ip vpn-instance vpna

[SPE-vpn-instance-vpna] route-distinguisher 200:1
[SPE-vpn-instance-vpna] vpn-target 1:1
[SPE-vpn-instance-vpna] quit
# Specify the UPE for the SPE.
[SPE] bgp 100

[SPE-bgp] ipv4-family vpnv4
[SPE-bgp-af-vpnv4] peer 1.1.1.9 upe
# Advertise the default route of the VPN instance to the UPE.
[SPE-bgp-af-vpnv4] peer 1.1.1.9 default-originate vpn-instance vpna

[SPE-bgp-af-vpnv4] quit
[SPE-bgp] quit
After the configuration is complete, CE1 has no route to the network segment of the interface on
CE2, but CE1 has a default route with the next hop as UPE. CE2 has a BGP route to
the network segment of the interface on CE1. CE1 and CE2 can ping each other.
[CE1] display ip routing-table

------------------------------------------------------------------------------
0.0.0.0/0 EBGP 255 0 D 10.1.1.2

10.1.1.0/24 Direct 0 0 D 10.1.1.1
10.1.1.1/32 Direct 0 0 D 127.0.0.1
10.1.1.255/32 Direct 0 0 D 127.0.0.1
127.0.0.0/8
127.0.0.1/32
127.255.255.255/32
255.255.255.255/32
[CE1] ping 10.2.1.1


0.00% packet loss
[CE2] display ip routing-table

------------------------------------------------------------------------------
10.1.1.0/24 D 10.2.1.2
10.2.1.0/24
10.2.1.1/32
10.2.1.255/32
127.0.0.0/8 Direct 0 0 D 127.0.0.1
InLoopBack0
127.0.0.1/32
InLoopBack0
127.255.255.255/32
InLoopBack0
255.255.255.255/32
InLoopBack0
Run the display bgp vpnv4 all routing-table command on the UPE. The command output
shows a default route of vpna with the next hop as SPE.
[UPE] display bgp vpnv4 all routing-table

Total number of routes from all PE: 4
Route Distinguisher: 100:1

Path/Ogn
*> 10.1.1.0/24
*
*> 10.1.1.2/32 0.0.0.0 0 0 ?
Route Distinguisher: 200:1

Path/Ogn
*>i 0.0.0.0 2.2.2.9 0 100 0 i
VPN-Instance vpna, Router ID 1.1.1.9:

Path/Ogn
*>i 0.0.0.0
*> 10.1.1.0/24
*> 10.1.1.2/32 0.0.0.0 0 0 ?
Configuration Files
#
sysname CE1
#
ip address 10.1.1.1 255.255.255.0
#
bgp 65410
#
ipv4-family unicast
import-route direct
#
return
 Configuration file of the UPE
#
sysname UPE
#
ipv4-family
#
mpls lsr-id 1.1.1.9
mpls
#
mpls ldp
#
ip address 10.1.1.2 255.255.255.0
#
ip address 172.1.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 2.2.2.9 enable
#
ipv4-family vpnv4
policy vpn-target
peer 2.2.2.9 enable
#
import-route direct
#
ospf 1
area 0.0.0.0
network 1.1.1.9 0.0.0.0
network 172.1.1.0 0.0.0.255
#
return
 Configuration file of the SPE
#
sysname SPE
#
ipv4-family
#
mpls lsr-id 2.2.2.9
mpls
#
mpls ldp
#
ip address 172.1.1.2 255.255.255.0
mpls
mpls ldp
#
ip address 172.2.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 1.1.1.9 enable
peer 3.3.3.9 enable
#
ipv4-family vpnv4
policy vpn-target
peer 1.1.1.9 enable
peer 1.1.1.9 upe
peer 1.1.1.9 default-originate vpn-instance vpna
peer 3.3.3.9 enable
#
ospf 1
area 0.0.0.0
network 2.2.2.9 0.0.0.0
network 172.1.1.0 0.0.0.255
network 172.2.1.0 0.0.0.255
#
return
 Configuration file of the PE
#
sysname PE
#
ipv4-family
#
mpls lsr-id 3.3.3.9
mpls
#
mpls ldp
#
ip address 10.2.1.2 255.255.255.0
#
ip address 172.2.1.2 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 2.2.2.9 enable
#
ipv4-family vpnv4
policy vpn-target
peer 2.2.2.9 enable
#
import-route direct
#
ospf 1
area 0.0.0.0
network 3.3.3.9 0.0.0.0
network 172.2.1.0 0.0.0.255
#
return
#
sysname CE2
#
ip address 10.2.1.1 255.255.255.0
#
bgp 65420
#
ipv4-family unicast
import-route direct
#
return
13.4.16 Example for Connecting a VPN to the Internet
As shown in Figure 13-4-16, CE1 and CE2 need to communicate with each other, and users
connected to CE1 need to connect to the Internet.
To enable users connected to CE1 to access the Internet, connect an agent server to CE1 and
configure a public IP address for the agent server. Then users connected to CE1 can access the
Internet through the agent server. In this example, the P represents on the Internet.
Figure 13-4-16 Networking diagram for connecting a VPN to the Internet
1. Configure basic BGP/MPLS IP VPN functions.
2. Configure three static routes:
 On CE1, create a default route and specify PE1 as the next hop.
 On PE1, configure a default route from the VPN to the Internet and specify P as the
next hop. This route enables traffic to be transmitted from the agent server to the
Internet.
 On PE1, configure a static route from the Internet to the agent server and specify CE1 as
the next hop. Configure IGP to advertise the static route to the Internet. This route
enables traffic to be transmitted from the Internet to the agent server.
Procedure
1. Assign IP addresses to interfaces according to Figure 13-4-16.
# Configure PE1.
The configuration on PE2, P, CE1, and CE2 is similar to the configuration on PE1 and is
not mentioned here.
2. Configure an IGP protocol on the MPLS backbone network for IP connectivity.
# Configure PE1.
[PE1] ospf
[PE1-ospf-1] area 0
[PE1-ospf-1] quit
The configuration on PE2 and P is similar to the configuration on PE1 and is not
mentioned here.
NOTE:
The IP addresses of loopback interfaces that are used as LSR IDs need to be advertised.
After the configuration is complete, the devices on the backbone network can learn the
loopback interface addresses from each other.
3. Set up MPLS LDP LSPs and an MP-IBGP peer relationship between the devices on
the backbone network.
# Enable MPLS LDP on PE1 to set up MPLS LDP LSPs.

[PE1] mpls
[PE1-mpls] quit
[PE1] mpls ldp
[PE1-mpls-ldp] quit
The configuration on PE2 and P is similar to the configuration on PE1 and is not
mentioned here.
After the configuration is complete, run the display mpls ldp session command on P. The
command output shows that the LDP sessions between PE1 and P, and between PE2 and P
are in Operational state.
The information displayed on P is used as an example.
[P] display mpls ldp session

deleted.
------------------------------------------------------------------------------
------------------------------------------------------------------------------
------------------------------------------------------------------------------
# Configure an MP-IBGP peer on PE1.
[PE1] bgp 100

[PE1-bgp] quit
Run the display bgp vpnv4 all peer command on PE1 and PE2. The command output
shows
that an MP-IBGP peer relationship has been set up between the PEs and is in Established state.


PrefRcv
3.3.3.3 4 100 6 8 0 00:03:48 Established 2
4. Create VPN instances and set up EBGP peer relationships.
# Create VPN instance vpn1 on the PEs and bind it to the interfaces connected to CEs.
[PE1] ip vpn-instance vpn1
[PE1-vpn-instance-vpn1] ipv4-family
[PE1-vpn-instance-vpn1-af-ipv4] route-distinguisher 100:1
[PE1-vpn-instance-vpn1-af-ipv4] vpn-target 1:1 both
[PE1-vpn-instance-vpn1-af-ipv4] quit
[PE1-vpn-instance-vpn1] quit
[PE1-GigabitEthernet1/0/0] ip binding vpn-instance vpn1
Set up EBGP peer relationships between PE1 and CE1 and between PE2 and CE2 so that
routes of the CEs can be advertised to the PEs. The configuration on CE1 and PE1 is used as
an example.
# Configure CE1.
[CE1] bgp 65410

[CE1-bgp] quit
The configuration on CE2 is similar to the configuration on CE1 and is not mentioned here.
# Configure PE1.
[PE1] bgp 100

[PE1-bgp] ipv4-family vpn-instance vpn1
[PE1-bgp-vpn1] peer 10.1.1.1 as-number 65410
[PE1-bgp-vpn1] import-route direct
[PE1-bgp-vpn1] import-route static
[PE1-bgp-vpn1] quit
[PE1-bgp] quit
After the configuration is complete, run the display ip vpn-instance command on the PEs.
In
the command output, vpn1 is displayed in the VPN-Instance Name field.
[PE1] display ip vpn-instance

Total VPN-Instances configured :1
VPN-Instance Name RD Creation Time
Address-family
vpn1 100:2 2012/09/10 15:36:20
UTC+08:00 IPv4
Run the display bgp vpnv4 all peer command on the PEs. The command output shows that the
IBGP and EBGP peer relationships are all in Established state.

Peer
PrefRcv
3.3.3.3
Peer of IPv4-family for vpn instance :
VPN-Instance vpn1, Router ID 1.1.1.1:

10.1.1.1 4 65410 107 110 0 01:26:33 Established 3
5. Configure static routes to enable VPN users to access the Internet.
# On CE1, create a default route and specify PE1 as the next hop.
# Configure PE1.
# Configure a default route from the agent server to the Internet and specify P as the next
hop. Specify the public keyword in the command to use the public IP address of P as the
next hop
address.
[PE1] ip route-static vpn-instance vpn1 0.0.0.0 0 100.1.1.2 public

NOTE:
If the CEs and PEs are connected through an Ethernet network, you must specify the next
hop when configuring the static route.
# Configure a static route from the Internet to the agent server and specify CE1 as the next hop.
[PE1] ip route-static 100.3.1.0 24 vpn-instance vpn1 10.1.1.1
# Advertise the preceding static route to the Internet using an IGP (OSPF in this example).
[PE1] ospf 1
[PE1-ospf-1] import-route static
[PE1-ospf-1] quit
# Configure the agent server. Set the IP address of the agent server to 100.3.1.1/24 and the
default gateway address of the agent server to 100.3.1.2/24 (address of CE1). In addition,
the agent server must run the agent software.
Run the display ip routing-table vpn-instance vpn1 command on PE1 to check the VPN
routing table of vpn1. The VPN routing table has a default route with the next hop address
100.1.1.2 and the outbound interface GE2/0/0.
[PE1] display ip routing-table vpn-instance vpn1

------------------------------------------------------------------------------
Routing Tables: vpn1
0.0.0.0/0 Static 60 0 RD 100.1.1.2
10.1.1.0/24 Direct 0 0 D 10.1.1.2
10.1.1.2/32 Direct 0 0 D 127.0.0.1
10.1.1.255/32 Direct 0 0 D 127.0.0.1
10.2.1.0/24 IBGP 255 0 RD 3.3.3.3
100.3.1.1/32 EBGP 255 0 D 10.1.1.1
Run the display ip routing-table command on PE1 to check the IP routing table on PE1.
The routing table has a route to the agent server, in which the next hop address is 10.1.1.1.

------------------------------------------------------------------------------
2.2.2.2/32 OSPF 10 1 D 100.1.1.2

1210
3.3.3.3/32 OSPF 10 2 D 100.1.1.2
100.1.1.0/24
100.1.1.1/32
100.1.1.255/32
100.2.1.0/24 OSPF 10 2 D 100.1.1.2
100.3.1.0/24 Static 60 0 D 10.1.1.1
127.0.0.0/8
127.0.0.1/32
127.255.255.255/32
255.255.255.255/32
P can ping the agent server.
[P] ping 100.3.1.1

ms

0.00% packet loss
The agent server can access the P on the Internet.
Configuration Files
#
sysname CE1
#
ip address 10.1.1.1 255.255.255.0
#
ip address 100.3.1.2 255.255.255.0
#
bgp 65410
#
ipv4-family unicast
import-route direct
#
ip route-static 0.0.0.0 0.0.0.0 10.1.1.2
#
return
#
sysname PE1
#
ip vpn-instance vpn1
ipv4-family
#
mpls lsr-id 1.1.1.1
mpls
#
mpls ldp
#
ip binding vpn-instance vpn1
ip address 10.1.1.2 255.255.255.0
#
ip address 100.1.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 1.1.1.1 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 3.3.3.3 enable
#
ipv4-family vpnv4
policy vpn-target
peer 3.3.3.3 enable
#
ipv4-family vpn-instance vpn1
import-route static
import-route direct
#
ospf 1
import-route static
area 0.0.0.0
network 1.1.1.1 0.0.0.0
network 100.1.1.0 0.0.0.255
#
ip route-static 100.3.1.0 255.255.255.0 vpn-instance vpn1 10.1.1.1
ip route-static vpn-instance vpn1 0.0.0.0 0.0.0.0 100.1.1.2 public
#
return
#
sysname P
#
mpls lsr-id 2.2.2.2
mpls
#
mpls ldp
#
ip address 100.1.1.2 255.255.255.0
mpls
mpls ldp
#
ip address 100.2.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 2.2.2.2 255.255.255.255
#
ospf 1
area 0.0.0.0
network 2.2.2.2 0.0.0.0
network 100.1.1.0 0.0.0.255
network 100.2.1.0 0.0.0.255
#
return
#
sysname PE2
#
ip vpn-instance vpn1
ipv4-family
#
mpls lsr-id 3.3.3.3
mpls
#
mpls ldp
#
ip address 100.2.1.2 255.255.255.0
mpls
mpls ldp
#
ip binding vpn-instance vpn1
ip address 10.2.1.2 255.255.255.0
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
#
bgp 100
#
ipv4-family unicast
peer 1.1.1.1 enable
#
ipv4-family vpnv4
policy vpn-target
peer 1.1.1.1 enable
#
ipv4-family vpn-instance vpn1
import-route direct
#
ospf 1
area 0.0.0.0
network 3.3.3.3 0.0.0.0
network 100.2.1.0 0.0.0.255
#
return
#
sysname CE2
#
ip address 10.2.1.1 255.255.255.0
#
bgp 65420
#
ipv4-family unicast
import-route direct
#
return
Chapter 14 Other Technologies
14.1 BFD
14.1.1 BFD for IP Links
You can create a single-hop or multi-hop BFD session on an IP link to rapidly detect faults:
 Single-hop BFD detects IP connectivity of the forwarding link between two directly
connected systems.
 Multi-hop BFD detects IP connectivity of paths between two indirectly connected systems.
These paths may span multiple hops or overlap.
Application
Typical application 1
As shown in Figure 14-1-1, a BFD session detects a single-hop path between two devices and the BFD
session is bound to the outbound interface.
Figure 14-1-1 Single-hop BFD for IP links

Typical application 2
As shown in Figure 14-1-2, a BFD session detects a multi-hop path between SwitchA and
SwitchC, and the BFD session is bound to the peer IP address but not the outbound interface.
Figure 14-1-2 Multi-hop BFD for IP links
14.1.2 BFD Echo Function
The BFD echo function detects connectivity of the forwarding link by looping back packets.
Among two directly connected devices, one device supports BFD, but the other device does not
support BFD and supports only forwarding at the network layer. To rapidly detect forwarding failures
between the two devices, the BFD echo function is configured on the BFD-supporting device. The
BFD-supporting device sends an Echo Request packet to the remote device. The remote device
sends the Echo Request packet back along the same path to detect the connectivity of the forwarding
link.
NOTE:
The BFD echo function is only applicable to single-hop BFD sessions.
Application
Figure 14-1-3 BFD Echo Function
As shown in Figure 14-1-3, SwitchA supports BFD, whereas SwitchB does not support BFD. The
BFD echo function is configured on SwitchA to detect connectivity of the single-hop path between
SwitchA and SwitchB. After SwitchB receives a BFD echo packet from SwitchA, SwitchB loops back
the packet at the network layer. This can rapidly detect connectivity of the direct link between
SwitchA and SwitchB.
14.1.3 Association between the BFD Session Status and the Interface Status
BFD for process interface status (PIS) associates the BFD session with the interface status. This
improves sensitivity of interfaces to detect link faults and minimizes the impact of faults on indirectly
connected links. When detecting a link fault, a BFD session immediately sends a Down message to
the
corresponding interface. The interface enters the BFD Down state. In BFD Down state, the
interface can process only BFD packets. Therefore, the interface can rapidly detect link faults.
Application
Figure 14-1-4 Association between the BFD session status and the interface status
As shown in Figure 14-1-4, a transit device exists on a faulty link, it takes a long time for devices on
two ends of the link to detect faults although they are directly connected at Layer 3. The reason is
that the two devices are connected by multiple physical links. As a result, service interruption time is
long. A BFD session is configured on SwitchA and SwitchB and the BFD session status is associated
with the interface status. When detecting a link fault, a BFD session immediately sends a Down
message to the corresponding interface. The interface enters the BFD Down state.
14.1.4 BFD for Static Routes
Unlike dynamic routing protocols, static routes do not have a dedicated detection mechanism. After
a fault occurs, static routes cannot detect the fault, and the network administrator must delete the
corresponding static route. BFD for static routes enables a BFD session to detect the status of the
link of the static route on the public network.
Each static route can be bound to a BFD session. When a BFD session bound to a static route detects
a fault (for example, the link changes from Up to Down) on a link, BFD reports the fault to the
routing management module (RM). Then, the RM configures the route as inactive, indicating that the
route is unavailable and deleted from the IP routing table. When the BFD session bound to the static
route is successfully set up or the link of the static route recovers (that is, the link changes from
Down to Up), BFD reports the event to the RM and the RM configures the static route as active,
indicating that the route is available and added to the IP routing table.
14.1.5 BFD for OSPF
A link failure or topology change may lead to route recalculation; therefore, convergence of routing
protocols must be shortened as much as possible to improve network performance. A feasible
solution is to rapidly detect link faults and immediately notify routing protocols of the faults.
BFD for OSPF associates a BFD session with OSPF. The BFD session rapidly detects a link fault
and notifies OSPF of the fault. By doing this, OSPF quickly responds to the network topology
change. Table 14-1-1 lists OSPF convergence speed.
Table 14-1-1 OSPF convergence speed
Whet
No
Yes
Application
Figure 14-1-5 BFD for OSPF
As shown in Figure 14-1-5, SwitchA establishes OSPF neighbor relationships with SwitchC and
SwitchD. The outbound interface in the route from SwitchA to SwitchB is Interface1. Packets
from SwithA traverse SwitchC, and then reach SwitchB. When the OSPF neighbor is in Full state,
the system instructs BFD to create a BFD session.
When a fault occurs on the link between SwitchA and SwitchC, the BFD session detects the fault
and notifies SwitchA. SwitchA processes the neighbor Down event and recalculates the route. Then,
the new outbound interface in the route is Interface2. Packets from SwithA traverse SwitchD, and
then reach SwitchB.
14.1.6 BFD for IS-IS
Generally, the interval at which Intermediate System to Intermediate System (IS-IS) sends Hello
packets is 10s. The holdtime of neighbors is three times the interval at which Hello packets are sent.
If the Switch does not receive a Hello packet from its neighbor within the holddown time, the Switch
deletes the neighbor relationship. That is, the Switch detects neighbor faults in seconds. The
second-level detection leads to the loss of a large number of packets on a high-speed network.
In BFD for IS-IS, BFD session setup is dynamically triggered by IS-IS but not configured
manually. When detecting a fault, the BFD session notifies IS-IS through the RM. Then, IS-IS
processes the neighbor Down event and rapidly updates the link state PDU (LSP) and performs the
partial route
calculation (PRC). This speeds up IS-IS route convergence. BFD is not used to replace the Hello
mechanism of IS-IS. Instead, BFD works with IS-IS to rapidly detect link faults and to
immediately notify IS-IS of route recalculation, which guides packet forwarding. Table 14-1-2
lists IS-IS
convergence speed.
Table 14-1-2 IS-IS convergence speed
Whet
No
Yes
Application
Figure 14-1-6 BFD for IS-IS
As shown in Figure 14-1-6, IS-IS is enabled on devices and association between BFD and IS-IS is
enabled on SwitchA and SwitchB. When the link between SwitchA and SwitchB fails, BFD can
rapidly detect the fault and report the fault to IS-IS. IS-IS then disconnects the neighbors of this
interface,
which triggers topology calculation. IS-IS updates LSPs so that the neighbors, for example, Switch
B's neighbor SwitchC, can receive the updated LSPs from SwitchB. IS-IS fast convergence is
implemented.
14.1.7 BFD for BGP
BGP enables the Switch to periodically send Keepalive packet to its peers for fault detection.
Detecting a fault takes more than 1s. When traffic is transmitted at gigabit rates, long-time fault
detection will cause loss of enormous packets. Association between BFD and BGP enables BFD to
rapidly detect faults on links between BGP peers and reports faults to BGP, which implements fast
BGP route
convergence. Table 14-1-3 lists BGP convergence speed.
Table 14-1-3 BGP convergence speed

Whe
No
Yes
Application
Figure 14-1-7 BFD for BGP

As shown in Figure 14-1-7, SwitchA belongs to AS 100, and SwitchB belongs to AS 200. SwitchA
and SwitchB are directly connected and establish an EBGP connection. BFD detects the status of
the EBGP connection between SwitchA and SwitchB. When the link between SwitchA and
SwitchB becomes faulty, BFD can rapidly detect the fault and notify BGP of the fault.
14.1.8 BFD for VRRP
When the VRRP master fails, the VRRP backup with the highest priority should take over
traffic within a short time to shorten service interruption.
When the VRRP master fails, VRRP determines whether to perform preemption based on the timeout
interval of the backup. The switching takes more than 1s. BFD can be used to rapidly detect the
master status and shorten traffic interruption. BFD detects real IP addresses of the master and backup
devices during communication. If communication is abnormal, the backup device considers that the
master device is Down and becomes the master device. a VRRP backup group implements a
master/backup VRRP switchover rapidly by tracking the BFD session status. The switchover time is
within 50 milliseconds.
Application
Figure 14-1-8 BFD for VRRP

As shown in Figure 14-1-8, SwitchA and SwitchB establish a VRRP group. SwitchA functions as
the master and SwitchB functions as the backup. User traffic is transmitted through SwitchA. A BFD
session is established between SwitchA and SwitchB. The VRRP group tracks the BFD session
status. When the BFD session status changes, the priority of the VRRP group is changed and then a
master/backup VRRP switchover is triggered.
When a BFD session detects a link fault between SwitchA and SwitchC, BFD reports a Down event
to VRRP. Then the priority of SwitchB increases above the priority of SwitchA. SwitchB becomes
the master switch immediately and subsequent user traffic is forwarded through SwitchB. In this
manner, fast master/backup VRRP switchover is performed.
14.1.9 BFD for PIM
If a DR on the shared network segment becomes faulty, PIM neighbor relationships time out, and a
new DR election is triggered among PIM neighbors. Consequently, multicast data transmission is
interrupted. The interruption period, usually in seconds, is at least as long as the timeout interval of
the neighbor relationship.
After detecting a fault on the peer, BFD immediately instructs the PIM module to trigger a new DR
election without waiting for timeout of the neighbor relationship.
BFD for PIM can rapidly detect faults on the Assert winner and is also applicable to Assert election
on a shared network segment.
Table 14-1-4 lists PIM convergence speed.
Table 14-1-4 PIM convergence speed

Whe
No
Yes
Application
Figure 14-1-9 BFD for PIM
As shown in Figure 14-1-9, on the shared network segment connected to user hosts, downstream
interface Interface1 on SwitchC and downstream interface Interface2 on SwitchD establish a PIM
BFD session and send BFD control packets to detect the link status.
SwitchC functions as the DR and its downstream interface Interface1 is responsible for forwarding
multicast data. If Interface1 becomes faulty, BFD fast notifies the RM of the session status, and the
RM notifies the PIM module. The PIM module then triggers a new DR election. SwitchD quickly
begins functioning as the new DR and its downstream interface Interface2 forwards multicast data to
the receivers.
14.2 URPF
14.2.1 Principles
Working Mode
On a complex network, the routes recorded on the local end and remote end may be different. A
URPF-enabled device on this network may discard the packets transmitted along the correct path,
but forward the invalid packets.
The device provides the following URPF modes to solve the preceding problem:
 Strict check
In strict mode, a packet passes the check only when the source IP address of the packet exists in
the FIB table and the outbound interface of the default route matches the inbound interface of
the packet.
If route symmetry is ensured, you are advised to use the URPF strict check. For example, if
there is only one path between two network edge devices, URPF strict check can be used to
ensure network security.
 Loose check
In loose mode, a packet passes the check as long as the source IP address of the packet
matches an entry in the FIB table.
If route symmetry is not ensured, you are advised to use the URPF loose check. For example,
if there are multiple paths between two network edge devices, URPF loose check can be used
to ensure network security.
Principles
URPF enables the device to search for the source IP address of a received packet in the FIB table to
obtain the matching outbound interface. If this outbound interface is different from the inbound
interface of the packet, the device considers the source address as a spoofing one and discards the
packet. In this manner, URPF can effectively protect the device against malicious attacks by
modifying source IP addresses in packets.
Figure 14-2-1 Principle

As shown in Figure 14-2-1, a bogus packet with source IP address 2.1.1.1 is sent from SwitchA to
SwitchB. After receiving the bogus packet, SwitchB sends a response packet to the actual
destination device SwitchC at 2.1.1.1. SwitchB and SwitchC are attacked by the bogus packets.
When SwitchB with URPF enabled receives the bogus packet with source IP address 2.1.1.1,
URPF discards the packet because the inbound interface of the source IP address is not the
interface that receives the packet.
14.3 IPSG
14.3.1 IPSG Overview
IP Source Guard (IPSG) defends against source address spoofing attacks.

Some attacks on networks aim at source IP addresses by accessing and using network resources
through spoofing IP addresses, stealing users' information or blocking authorized users from
accessing networks. IPSG can prevent source address spoofing attacks.
IPSG enables the device to check IP packets against dynamic and static DHCP entries. Before the
device forwards an IP packet, it compares the source IP address, source MAC address, interface, and
VLAN information in the IP packet with entries in the binding table. If an entry is matched, the
device takes the IP packet as a valid packet and forwards an IP packet. Otherwise, the device takes
the IP packet as an attack packet and discards the packet.
As shown in Figure 14-3-1, an attacker sends bogus packets to modify the outbound interface in the
MAC address table on the Router. Then replies are sent from the server to the attacker.
Figure 14-3-1 IP/MAC address spoofing attack

To prevent these attacks, you can configure IPSG on the Router to check incoming IP packets
against the binding entries. IP packets that match the binding entries are forwarded, and IP packets
that do not match the binding entries are discarded.
14.4 ARP Security
14.4.1 Rate Limit on ARP Packets
The device has no sufficient CPU resource to process other services when processing a large number of
ARP packets. To protect CPU resources of the device, limit the rate of ARP
packets. The device provides the following mechanisms for limiting the rate of ARP
packets:
 Limiting the rate of ARP packets based on the source MAC address or source IP address
When detecting that a host sends a large number of ARP packets in a short period, the device
limits the rate of ARP packets sent from this host based on the source MAC address or source
IP address. If the number of ARP packets received within a specified period exceeds the
threshold, the device discards the excess ARP packets.
 Limiting the rate of ARP packets based on the source MAC address: If a MAC address is
specified, the device applies the rate limit to ARP packets from this source MAC
address; otherwise, the device applies the rate limit to all ARP packets.
 Limiting the rate of ARP packets based on the source IP address: If an IP address is
specified, the device applies the rate limit to ARP packets from this source IP
address; otherwise, the device applies the rate limit to all ARP packets.
 Limiting the rate of ARP packets based on the destination IP Address
When processing a large number of ARP packets with the same destination IP address, the
device limits the rate of ARP packets based on the destination IP Address. The device collects
statistics on ARP packets with a specified destination IP address. If the number of received ARP
packets with the specified destination IP address in 1 second exceeds the threshold, the device
discards
the excess ARP packets.
 Limiting the rate of ARP packets on a VLANIF interface of a super-VLAN
A VLANIF interface of a super-VLAN is triggered to learn ARP entries in the

following scenarios:
 The VLANIF interface receives IP packets triggering ARP Miss messages. For
details about ARP Miss messages, see Rate Limit on ARP Miss Messages.
 The VLANIF interface enabled with ARP proxy receives ARP packets with the destination
IP address matching proxy conditions but matching no ARP entry.
The VLANIF interface replicates ARP Request packets in each sub-VLAN when learning ARP
entries. If a large number of sub-VLANs are configured for the super-VLAN, the device
generates a large number of ARP Request packets. As a result, the CPU is busy processing ARP
Request packets, and other services are affected. To prevent this problem, limit the rate of ARP
packets on the VLANIF interface of a super-VLAN.
 Limiting the rate on ARP packets globally, in a VLAN, or on an interface
The maximum rate and rate limit duration of ARP packets can be set globally, in a VLAN, or
on an interface. The configurations on an interface, in a VLAN, and globally takes effect in
descending order of priority.
In addition, the duration for blocking ARP packets can be set on an interface. If the number of
ARP packets received within a specified rate limit duration exceeds the threshold (the
maximum number of ARP packets), the device discards the excess ARP packets and discards all
received ARP packets in a specified duration (duration for blocking ARP packets).
 Limiting the rate of ARP packets globally: limits the number of ARP packets to be
processed by the system. When an ARP attack occurs, the device limits the rate of
ARP packets globally.
 Limiting the rate of ARP packets in a VLAN: limits the number of ARP packets to be
processed on all interfaces in a VLAN. The configuration in a VLAN does not affect
ARP entry learning on interfaces in other VLANs.
 Limiting the rate of ARP packets on an interface: limits the number of ARP packets to
be processed on an interface. The configuration on an interface does not affect ARP
entry learning on other interfaces.
14.4.2 Rate Limit on ARP Miss Messages
If a host sends a large number of IP packets with unresolvable destination IP addresses to attack a
device, that is, if the device has a route to the destination IP address of a packet but has no ARP entry
matching the next hop of the route, the device triggers a large number of ARP Miss messages. IP
packets triggering ARP Miss messages are sent to the master control board for processing. The
device generates a large number of temporary ARP entries and sends many ARP Request packets to
the network, consuming a large number of CPU and bandwidth resources.
To avoid the preceding problems, the device provides multiple techniques to limit the rate on
ARP Miss messages.
 Limiting the rate of ARP Miss messages based on the source IP address
If the number of ARP Miss messages triggered by IP packets from a source IP address in
1 second exceeds the limit, the device considers that an attack is initiated from the source
IP address.
If the ARP Miss packet processing mode is set to block, the CPU of the device discards excess
ARP Miss messages and delivers an ACL to discard all subsequent packets that are sent from
this source IP address. If the ARP Miss packet processing mode is set to none-block, the CPU
discards excess ARP Miss messages. When ARP Miss messages are discarded, corresponding
ARP Miss packets are discarded.
If a source IP address is specified, the rate of ARP Miss messages triggered by IP packets
from the source IP address is limited. If no source IP address is specified, the rate of ARP
Miss messages triggered by IP packets from each source IP address is limited.
 Limiting the rate of ARP Miss messages globally, in a VLAN, or on an interface
The maximum number of ARP Miss massages can be set globally, in a VLAN, or on an
interface. The configurations on an interface, in a VLAN, and globally takes effect in descending
order of priority.
 Limiting the rate of ARP Miss messages globally: limits the number of ARP Miss
messages processed by the system.
 Limiting the rate of ARP Miss messages in a VLAN: limits the number of ARP Miss
messages to be processed on all interfaces in a VLAN. The configuration in a VLAN
does not affect IP packet forwarding on interfaces in other VLANs.
 Limiting the rate of ARP Miss messages on an interface: limits the number of ARP Miss
messages to be processed on an interface. The configuration on an interface does not
affect IP packet forwarding on other interfaces.
 Limiting the rate of ARP Miss messages by setting the aging time of temporary ARP entries
When IP packets trigger ARP Miss messages, the device generates temporary ARP entries
and sends ARP Request packets to the destination network.
 In the aging time of temporary ARP entries:
 An IP packet that is received before the ARP Reply packet and matches a temporary
ARP entry is discarded and triggers no ARP Miss message.
 After receiving the ARP Reply packet, the device generates a correct ARP entry
to replace the temporary entry.
 When temporary ARP entries age out, the device clears them. If no ARP entry matches
the IP packets forwarded by the device, ARP Miss messages are triggered again and
temporary ARP entries are regenerated. This process continues.
When ARP Miss attacks occur on the device, you can extend the aging time of temporary ARP
entries and reduce the frequency of triggering ARP Miss messages to minimize the impact on
the device.
14.4.3 Gratuitous ARP Packet Discarding
In a gratuitous ARP packet, the source IP address and destination IP address are both the local IP
address, the source MAC address is the local MAC address, and the destination MAC address is a
broadcast address. When a host connects to a network, the host broadcasts a gratuitous ARP packet to
notify other devices on the network of its MAC address and to check whether any device uses the
same IP address as its own IP address in the broadcast domain. When the MAC address of a host
changes,
the host sends a gratuitous ARP packet to notify all hosts before the ARP entry ages out.
No authentication is performed on a host that sends gratuitous ARP packets, so any host can
send gratuitous ARP packets, causing the following problems:
 If a large number of gratuitous ARP packets are broadcast on the network, the device
cannot process valid ARP packets due to CPU overload.
 If the device processes bogus gratuitous ARP packets, ARP entries are updated
incorrectly, leading to communication interruptions.
To solve the preceding problems, enable the gratuitous ARP packet discarding function on
the gateway.
CAUTION:
If the gratuitous ARP packet discarding function is enabled on the gateway, other hosts on the
network cannot update their ARP entries when a host uses a new MAC address to connect to the
network. Consequently, other hosts cannot communicate with this host. When a host changes the
interface card and restarts, or the standby node takes over the active node due to faults in a two-
node cluster hot
backup system, a host connects to the network with a new MAC address.
14.4.4 Strict ARP Learning
If many users send a large number of ARP packets to a device at the same time, or attackers send bogus
ARP packets to the device, the following problems occur:
 Many CPU resources are consumed to process a large number of ARP packets. The device
learns many invalid ARP entries, which exhaust ARP entry resources and prevent the device
from learning ARP entries for ARP packets from authorized users. Consequently,
communication of authorized users is interrupted.
 Bogus ARP packets modify ARP entries on the device. As a result, the device
cannot communicate with other devices.
To avoid the preceding problems, deploy the strict ARP learning function on the gateway.
After strict ARP learning function is enabled, the device learns only ARP entries for ARP reply
packets in response to ARP request packets sent by itself. In this way, the device can defend against
most ARP attacks.
Figure 14-4-1 Strict ARP learning
As shown in Figure 14-4-1, after receiving an ARP Request packet from UserA, the gateway sends
an ARP Reply packet to UserA and adds or updates an ARP entry matching UserA. After the strict
ARP learning function is enabled on the gateway:
 When receiving an ARP Request packet from UserA, the gateway adds or updates no ARP
entry matching UserA. If the ARP Request packet requests the MAC address of the gateway,
the gateway sends an ARP Reply packet to UserA.
 If the gateway sends an ARP Request packet to UserB, the gateway adds or updates an ARP
entry matching UserB after receiving the ARP Reply packet.
14.4.5 ARP Entry Limiting
The ARP entry limiting function controls the number of ARP entries that a gateway interface can
learn. By default, the number of ARP entries that an interface can dynamically learn is the same as the
default number of ARP entries supported by the device. After the ARP entry limiting function is
deployed, if the number of ARP entries that a specified interface dynamically learned reaches the
maximum, the interface cannot learn any ARP entry. This prevents ARP entries from being exhausted
when a host connecting to this interface initiates ARP attacks.
14.4.6 ARP Entry Fixing
As shown in Figure 14-4-2, an attacker simulates UserA to send a bogus ARP packet to the
gateway. The gateway then records an incorrect ARP entry for UserA. As a result, UserA cannot
communicate with the gateway.
Figure 14-4-2 ARP gateway spoofing attack

To defend against ARP gateway spoofing attacks, de e gateway. After the gateway with this
function enabled learns an ARP entry for the first time, it does not change the ARP entry, only
updates part of the entry, or sends a unicast ARP Request packet to check validity of the ARP packet
for updating the entry.
The device supports three ARP entry fixing modes, as described in Table 14-4-1.
Table 14-4-1 ARP entry fixing modes

Mode
fixed-all
fixed-mac
send-ack

14.4.7 DAI
A man-in-the-middle (MITM) attack is a common ARP spoofing attack.
Figure 14-4-3 Man-in-the-middle attack

Figure 14-4-3 shows an MITM attack scenario. An attacker simulates UserB to send a bogus ARP
packet to UserA. UserA then records an incorrect ARP entry for UserB. The attacker easily obtains
information exchanged between UserA and UserB. Information security between UserA and UserB
is not protected.
To defend against MITM attacks, deploy DAI on the switch.
DAI defends against MITM attacks using DHCP snooping. When a device receives an ARP packet,
it compares the source IP address, source MAC address, interface number, and VLAN ID of the
ARP packet with DHCP snooping binding entries. If the ARP packet matches a binding entry, the
device considers the ARP packet valid and allows the packet to pass through. If the ARP packet
matches no binding entry, the device considers the ARP packet invalid and discards the packet.
NOTE:
This function is available only when DHCP snooping is configured. The device enabled with DHCP
snooping generates DHCP snooping binding entries when DHCP users go online. If a user uses a
static IP address, you need to manually configure a static DHCP snooping binding entry for the user.
For details about DHCP snooping, see description in Basic
Principles.

1210
When an attacker connects to the switch enabled with DAI and sends bogus ARP packets, the
switch detects the attacks based on the DHCP snooping entries and discards the bogus ARP packets.
When both the DAI and packet discarding alarm functions are enabled on the switch, the switch
generates alarms when the number of discarded ARP packets matching no DHCP snooping entry
exceeds the alarm threshold.
14.4.8 ARP Gateway Anti-Collision
As shown in Figure 14-4-4, UserA and UserB connect to the gateway. An attacker forges the
gateway address to send bogus ARP packets to UserA and UserB. UserA and UserB record incorrect
ARP entries for the gateway. As a result, all traffic from UserA and UserB to the gateway is sent to
the attacker and the attacker intercepts user information.
Figure 14-4-4 ARP gateway collision

To prevent bogus gateway attacks, enable ARP gateway anti-collision on the gateway. The
gateway considers that a gateway collision occurs when a received ARP packet meets either of the
following conditions:
 The source IP address in the ARP packet is the same as the IP address of the VLANIF
interface matching the physical inbound interface of the packet.
 The source IP address in the ARP packet is the virtual IP address of the inbound interface but
the source MAC address in the ARP packet is not the virtual MAC address of the Virtual Router
Redundancy Protocol (VRRP) group.
NOTE:
A VRRP group, also called a virtual router, serves as the default gateway for hosts on a LAN. A
virtual router has a virtual MAC address that is generated based on the virtual router ID. The
virtual MAC address is in the format of 00-00-5E-00-01-{VRID}(VRRP). The virtual
router sends ARP Reply packets using the virtual MAC address instead of the interface MAC
address.
For details about VRRP, see Basic Concepts of VRRP in the Feature Description –
Reliability.
The device generates an ARP anti-collision entry and discards the received packets with the same
source MAC address and VLAN ID in a specified period. This function prevents ARP packets with
the bogus gateway address from being broadcast in a VLAN.
In addition, you can enable gratuitous ARP packet sending on the device to send correct
gratuitous ARP packets. The gratuitous ARP packet is broadcast to all users so that incorrect ARP
entries are corrected.
14.4.9 Gratuitous ARP Packet Sending
As shown in Figure 14-4-5, an attacker forges the gateway address to send a bogus ARP packet to
UserA. UserA then records an incorrect ARP entry for the gateway. As a result, the gateway
cannot receive packets from UserA.
Figure 14-4-5 Bogus gateway attack

To avoid the preceding problem, deploy gratuitous ARP packet sending on the gateway. Then the
gateway sends gratuitous ARP packets at intervals to update the ARP entries of authorized users so
that the ARP entries contain the correct MAC address of the gateway.
Gratuitous ARP packet sending can be enabled globally or on a VLANIF interface. If gratuitous ARP
packet sending is enabled globally and on a VLANIF interface simultaneously, the configuration on
the VLANIF interface takes precedence over the global configuration.
14.4.10 MAC Address Consistency Check in an ARP Packet
This function defends against attacks from bogus ARP packets in which the source and destination
MAC addresses are different from those in the Ethernet frame header.
This function enables the gateway to check the MAC address consistency in an ARP packet before
ARP learning. If the source and destination MAC addresses in an ARP packet are different from
those in the Ethernet frame header, the device discards the packet as an attack. If the source and
destination MAC addresses in an ARP packet are the same as those in the Ethernet frame header, the
device performs ARP learning.
14.4.11 ARP Packet Validity Check
This function allows the device to filter out packets with invalid MAC addresses or IP addresses.
The device checks validity of an ARP packet based on each or any combination of the following
items:
 Source MAC address: The device compares the source MAC address in an ARP packet with
that in the Ethernet frame header. If they are the same, the packet is valid. If they are different,
the device discards the packet.
 Destination MAC address: The device compares the destination MAC address in an ARP
packet with that in the Ethernet frame header. If they are the same, the packet is valid. If they
are different, the device discards the packet.
 IP address: The device checks the source and destination IP addresses in an ARP packet. If the
source or destination IP address is all 0s, all 1s, or a multicast IP address, the device discards
the packet as an invalid packet. The device checks both the source and destination IP addresses
in an ARP Reply packet but checks only the source IP address in an ARP Request packet.
14.4.12 ARP Learning Triggered by DHCP
When there are a large number of DHCP users, the device needs to learn many ARP entries and
age them. This affects device performance.
ARP learning triggered by DHCP prevents this problem on the gateway. When the DHCP server
allocates an IP address for a user, the gateway generates an ARP entry for the user based on the
DHCP ACK packet received on the VLANIF interface. Ensure that DHCP snooping has been enabled
before using ARP learning triggered by DHCP.
You can also deploy DAI to prevent ARP entries of DHCP users from being modified maliciously.
14.4.13 ARP Proxy on a VPLS Network
To prevent bogus ARP packets at the PW side from being broadcast to the AC side on a VPLS
network, enable ARP proxy and DHCP snooping over VPLS on a PE.
ARP packets at the PW side are sent to the master control board to process.
 If the ARP packets are ARP Request packets and the destination IP addresses in the packets
match DHCP snooping binding entries, the device constructs ARP Reply packets based on
the DHCP snooping binding entries and sends them to the requester at the PW side.
 If the ARP packets are not ARP Request packets or the destination IP addresses in the
packets match no DHCP snooping binding entry, the device forwards these ARP packets.
14.5 QoS Technology Description
14.5.1 Priority Mapping
Introduction to Priority Mapping
Packets carry different precedence fields on various networks. For example, packets carry the
802.1p field in a VLAN, the EXP field on an MPLS network, and the DSCP field on an IP network.
The mapping between the priority fields must be configured on the gateway to retain priorities of
packets when the packets traverse different networks.
The priority mapping mechanism provides the mapping from precedence fields of packets to internal
priorities (local priorities) or the mapping from internal priorities to precedence fields of packets. This
mechanism uses the DiffServ domain to manage and record the mapping of precedence fields and
CoSs. When packets reach the device, the device maps priorities in packets or the default 802.1p
priorities of inbound interfaces to local priorities. The device then determines the queues that packets
enter based
on the mapping between internal priorities and queues and performs traffic shaping, congestion
avoidance, and queue scheduling. In addition, the device can re-mark priorities of outgoing packets
so that the downstream device can provide differentiated QoS based on packet priorities.
Precedence Fields
Certain fields in the packet header or frame header record QoS information so that network devices
can provide differentiated services on the Internet based on QoS information. These fields include:
 Precedence field
As defined in RFC 791, the 8-bit ToS field in an IP packet header contains a 3-bit IP
precedence field. Figure 14-5-1 shows the Precedence field in an IP packet.
Figure 14-5-1 IP Predecence/DSCP field

Bits 0 to 2 constitute the Precedence field, representing precedence values 7, 6, 5, 4, 3, 2, 1 and
0 in descending order of priority. The higher priority 7 and 6 are reserved for routing and
network control communication updating. User-level applications can use only priority values 0
to 5.
Apart from the Precedence field, a ToS field also contains the following sub-fields:
 Bit D indicates the delay. The value 0 represents a normal delay and the value 1
represents a short delay.
 Bit T indicates the throughput. The value 0 represents normal throughput and the value
1 represents high throughput.
 Bit R indicates the reliability. The value 0 represents normal reliability and the value
1 represents high reliability.
Bits 6 and 7 are reserved.
 DSCP field
RFC 1349 initially defined the ToS field in IP packets and adds bit C. Bit C indicates the
monetary cost. Later, the IETF DiffServ working group redefined bits 0 to 5 of a ToS field as
the DSCP field in RFC 2474. In RFC 2474, the field name is changed from ToS to DS, which
stands for Differentiated Service. Figure 14-5-1 shows the DSCP field in packets.
In the DS field, the leftmost six bits (bits 0 to 5) are the DS CodePoint (DSCP) and the rightmost
two bits (bits 6 and 7) are reserved. The leftmost three bits (bits 0 to 2) are the Class Selector
CodePoint (CSCP), which represents a type of the DSCP. The DS node selects the
corresponding Per-Hop Behavior (PHB) based on the DSCP value.
 802.1p priority in the Ethernet frame header
Layer 2 devices exchange Ethernet frames. As defined in IEEE 802.1Q, the PRI field
(802.1p priority) in the Ethernet frame header, also called Class of Service (CoS), identifies
the QoS requirement. Figure 14-5-2 shows the PRI field.
Figure 14-5-2 802.1p priority in the Ethernet frame header

The 802.1Q header contains a 3-bit PRI field, representing eight service priorities 7, 6, 5, 4, 3, 2,
1 and 0 in descending order of priority.
 MPLS EXP field
Different from IP packets, MPLS packets use labels. A label has 4 bytes. Figure 14-5-3
shows the format of the MPLS EXP field.
Figure 14-5-3 Format of the MPLS EXP Field
The EXP field contains four sub-fields:

 Label: has 20 bits and specifies the next hop to which a packet is to be forwarded.
 EXP: has 3 bits and is reserved for extensions. It is called Class of Service (CoS) currently.
 S: has 1 bit and identifies the last entry in the label stack. MPLS supports
hierarchical labels. If the S sub-field is 1, the label is at the bottom of the stack.
 TTL: has 8 bits and is the same as the TTL in IP packets.
The EXP field is used as the CoS field in MPLS packets and is equivalent to the ToS field in
IP packets. The EXP field is used to differentiate data flows on MPLS networks. The EXP
field encodes eight transmission priorities 7, 6, 5, 4, 3, 2, 1 and 0 in descending order of
priority.
 On IP networks, IP precedences or DSCP fields in IP packets identify CoS levels. On an

MPLS network, Label Switching Router (LSR) cannot identify IP packet headers;
therefore, EXP fields are marked at the edge of the MPLS network.
 By default, the IP precedence in an IP packet is copied to the EXP field in an MPLS packet
at the edge of an MPLS network. If an ISP does not trust a user network or differentiated
service levels defined by an ISP are different from those on a user network, then
reconfigures the EXP field in an MPLS packet based on simple traffic classification rules
and internal service levels. During forwarding on the MPLS network, the ToS field in an
IP packet remains unchanged.
 On a MPLS network, intermediate nodes classify packets based on the EXP field in
MPLS packets and perform PHBs such as congestion management, traffic policing, and
traffic shaping.
14.5.2 Traffic Policing and Traffic Shaping
If traffic sent by users is not limited, continuous burst data from numerous users may aggravate
network congestion. To efficiently use limited network resources and better serve more users,
traffic sent by users must be limited.
Traffic policing and traffic shaping limit traffic and resource usage by monitoring the traffic rate.
Before implementing traffic policing and traffic shaping, assess whether the traffic exceeds the rate
limit. Then traffic policies are implemented based on the assessment result. Generally, token
buckets are used to assess traffic.
Differences between Traffic Policing and Traffic Shaping
The differences between traffic policing and traffic shaping are as follows:
 Traffic policing directly discards the packets whose rate exceeds the rate limit. Traffic
shaping, however, buffers the packets whose rate is greater than the traffic shaping rate.
When there are sufficient tokens in the token bucket, the device forwards buffered packets at
an even rate.
 Traffic shaping increases the delay, whereas traffic policing does

not.
Table 14-5-1 Differences between traffic policing and traffic shaping
Type
Traffic shaping
Traffic policing
Figure 14-5-4 shows the differences between traffic shaping and traffic policing.
Figure 14-5-4 Differences between traffic policing and traffic shaping
 Token Bucket
 Traffic Policing
 Traffic Shaping
14.5.3 Token Bucket
Overview
A token bucket has specified capacity to store tokens. The system places tokens into a token bucket
at the configured rate. If the token bucket is full, excess tokens overflow and no token is added.
When assessing traffic, a token bucket forwards packets based on the number of tokens in the token
bucket. If there are enough tokens in the token bucket for forwarding packets, the traffic rate is
within the rate limit. Otherwise, the traffic rate is not within the rate limit.
Single Bucket at a Single Rate
Figure 14-5-5 Single bucket at a single rate
As shown in Figure 14-5-5, the bucket is called bucket C. Tc indicates the number of tokens in bucket
C. A single bucket uses the following parameters:
 Committed information rate (CIR): indicates the rate at which tokens are put into bucket C,
that is, average traffic rate permitted by bucket C.
 Committed burst size (CBS): indicates the capacity of bucket C, that is, maximum volume
of burst traffic allowed by bucket C each time.
The system places tokens into the bucket at the CIR. If Tc is smaller than the CBS, Tc increases. If
Tc is smaller than or equal to the CBS, Tc remains unchanged.
B indicates the size of an arriving packet:
 If B is smaller than or equal to Tc, the packet is colored green, and Tc decreases by B.
 If B is larger than Tc, the packet is colored red, and Tc remains unchanged.
Dual Buckets at a Single Rate
Dual buckets at a single rate use A Single Rate Three Color Marker (srTCM) defined in RFC 2697
to assess traffic and mark packets in green, yellow, and red based on the assessment result.
Figure 14-5-6 Dual buckets at a single rate
As shown in Figure 14-5-6, the two buckets are called bucket C and bucket E. Tc indicates the
number of tokens in bucket C, and Te indicates the number of tokens in bucket E. Dual buckets at a
single rate use the following parameters:
 CIR: indicates the rate at which tokens are put into bucket C, that is, average traffic
rate permitted by bucket C.
 CBS: indicates the capacity of bucket C, that is, maximum volume of burst traffic allowed
by bucket C each time.
 Excess burst size (EBS): indicates the capacity of bucket E, that is, maximum volume of
excess burst traffic allowed by bucket E each time.
The system places tokens into the bucket at the
CIR:
 If Tc is smaller than the CBS, Tc increases.
 If Tc is equal to the CBS and Te is smaller than the EBS, Te increases.
 If Tc is equal to the CBS and Te is equal to the EBS, Tc and Te do not
increase. B indicates the size of an arriving packet:
 If B is smaller than or equal to Tc, the packet is colored green, and Tc decreases by B.
 If B is larger than Tc and smaller than or equal to Te, the packet is colored yellow and
Te decreases by B.
 If B is larger than Te, the packet is colored red, and Tc and Te remain unchanged.
Dual Buckets at Dual Rates
Dual buckets at dual rates use A Two Rate Three Color Marker (trTCM) defined in RFC 2698 to
assess traffic and mark packets in green, yellow, and red based on the assessment result.
Figure 14-5-7 Dual buckets at dual rates
As shown in Figure 14-5-7, the two buckets are called bucket P and bucket C. Tp indicates the
number of tokens in bucket P, and Tc indicates the number of tokens in bucket C. Dual buckets at dual
rates use the following parameters:
 Peak information rate (PIR): indicates the rate at which tokens are put into bucket P, that
is, average traffic rate permitted by bucket P. The PIR must be greater than the CIR.
 CIR: indicates the rate at which tokens are put into bucket C, that is, average traffic
rate permitted by bucket C.
 Peak burst size (PBS): indicates the capacity of bucket P, that is, maximum volume of
burst traffic allowed by bucket P each time.
 CBS: indicates the capacity of bucket C, that is, maximum volume of burst traffic allowed
by bucket C each time.
The system places tokens into bucket P at the PIR and places tokens into bucket C at the CIR:
 If Tp is smaller than the PBS, Tp increases. If Tp is larger than or equal to the PBS, Tp
remains unchanged.
 If Tc is smaller than the CBS, Tc increases. If Tc is larger than or equal to the CBS, Tp
remains unchanged.
B indicates the size of an arriving packet:
 If B is larger than Tp, the packet is colored red.
 If B is larger than Tc and smaller than or equal to Tp, the packet is colored yellow and
Tp decreases by B.
 If B is smaller than or equal to Tc, the packet is colored green, and Tp and Tc decrease by B.
14.5.4 Traffic Policing
Traffic policing discards excess traffic to limit the traffic within a specified range and to
protect network resources as well as the enterprise benefits.
Implementation of traffic policing
Figure 14-5-8 Traffic policing components
As shown in Figure 14-5-8, traffic policing involves the following components:
 Meter: measures the network traffic using the token bucket mechanism and sends
the measurement result to the marker.
 Marker: colors packets in green, yellow, or red based on the measurement result received
from the meter.
 Action: performs actions based on packet coloring results received from the marker.
The following actions are defined:
 Pass: forwards the packets that meet network requirements.
 Remark + pass: changes the local priorities of packets and forwards them.
 Discard: drops the packets that do not meet network requirements.

By default, green and yellow packets are forwarded, and red packets are discarded.
If the rate of a type of traffic exceeds the threshold, the device reduces the packet priority and then
forwards the packets or directly discards the packets based on traffic policing configuration. By
default, the packets are discarded.
14.5.5 Traffic Shaping
Traffic shaping adjusts the rate of outgoing traffic so that the outgoing traffic can be sent out at an
even rate. Traffic shaping uses the buffer and token bucket to control traffic. When packets are sent at
a high speed, traffic shaping caches packets in the buffer and then evenly sends these cached packets
based on the token bucket.
When the rate of an interface on a downstream device is slower than that of an interface on an
upstream device or burst traffic occurs, traffic congestion may occur on the downstream device
interface. Traffic shaping can be configured on the interface of an upstream device so that outgoing
traffic is sent at an even rate and congestion is avoided.
Traffic Shaping Process
The traffic shaping technology is used on an interface, a sub-interface, or in an interface queue, and
can limit the rate of all the packets on an interface or the packets of a certain type passing through an
interface.
Flow-based queue shaping using the single bucket at a single rate on an interface or sub-interface
is used as an example. Figure 14-5-9 shows the traffic shaping process.
Figure 14-5-9 Traffic shaping process
The traffic shaping process is described as follows:
1. When packets arrive, the device classifies packets so that the packets enter different queues.
2. If the queue that packets enter is not configured with traffic shaping, the packets of the
queue are sent. Otherwise, proceed to the next step.
3. The system places tokens into the bucket at the configured rate (CIR):
 If there are sufficient tokens in the bucket, the device sends packets directly and
the number of tokens decreases.
 If there are insufficient tokens in the bucket, the device places packets into the
buffer queue. If the buffer queue is full, packets are discarded.
4. When there are packets in the buffer queue, the system extracts the packets from the queue
and sends them periodically. Each time the system sends a packet, it compares the number of
packets with the number of tokens till the tokens are insufficient to send packets or all the
packets are sent.
After queue shaping is performed, the system needs to control the packets at the traffic shaping rate
configured on an interface if traffic shaping is configured on the interface or sub-interface. The
process is the same as the queue shaping process; however, you do not need to perform 1 and 2.
Adaptive Traffic Shaping
Traffic shaping solves the problem of packets discarded on the inbound interface of the downstream
device when the rate of the inbound interface on the downstream device is smaller than the rate of th
e outbound interface on the upstream device. In some scenarios, the interface rate of the downstream
device is variable, so the upstream device cannot determine the traffic shaping parameters.
Configure an adaptive traffic profile and associate an NQA test instance with the adaptive traffic
profile so that the device can dynamically adjust traffic shaping parameters based on the NQA
result.
The adaptive traffic profile defines the following parameters:
 NQA test instance: detects the packet loss ratio on the inbound interface of the downstream
device. The upstream device adjusts traffic shaping parameters based on the detected packet
loss ratio.
 Traffic shaping rate range: allowed by the outbound interface of the upstream device. The
traffic shaping rate in this range is adjusted dynamically.
 Traffic shaping rate adaptation step: step of the traffic shaping rate dynamically adjusted
each time.
 Packet loss ratio range: is allowed by the inbound interface of the downstream device. If the
packet loss ratio detected by the NQA test instance is within the range, the upstream device
does not adjust the traffic shaping rate. If the detected packet loss ratio is larger than the upper
threshold for the packet loss ratio, the upstream device reduces its traffic shaping rate. If the
detected packet loss ratio is smaller than the lower threshold for the packet loss ratio and
congestion occurs on the upstream device, the upstream device increases its traffic shaping rate.
 Interval at which the traffic shaping rate increases: interval at which the upstream device
increases the traffic shaping rate when the packet loss ratio frequently changes below the
lower threshold of the packet loss ratio. This parameter prevents frequent traffic shaping rate
change.
NOTE:
When the NQA test instance detects a high packet loss ratio, to prevent packet loss, the
upstream device immediately reduces the traffic shaping rate regardless of the interval.
The traffic shaping rate is adjusted based on the detected packet loss ratio:
Table 14-5-2 NQA test
Condition Action
The NQA test instance detects that the packet Reduce the traffic shaping rate.
loss ratio is greater than the upper threshold
in the adaptive traffic profile for three
consecutive times.
 The NQA test instance detects that the  The interval at which the traffic shaping rate
packet loss ratio is smaller than the lower
threshold in the adaptive traffic profile
for three consecutive times.
 Congestion occurs on the outbound interface
of the upstream device.
Increase the traffic shaping rate.
Table 14-5-2 NQA test
Condition Action
increases is reached.
 The NQA test instance detects that the Retain the traffic shaping rate.
packet loss ratio is smaller than the lower
threshold in the adaptive traffic profile
for three consecutive times.
 No congestion occurs on the outbound
interface of the upstream device.
The detected packet loss ratio is within the packet

loss ratio range in the adaptive traffic profile.
NQA test fails.

NOTE:
The adaptive traffic profile can be bound to an NQA test instance. The upstream device uses the
upper threshold for the traffic shaping rate in the adaptive traffic profile if the adaptive traffic profile
is not bound to the NQA test instance.
14.5.6 Congestion Management
When a network is congested intermittently and delay-sensitive services require higher QoS than
delay-insensitive services, congestion management is required. If congestion persists on the network
after congestion management is configured, bandwidth needs to be increased. Congestion
management sends packet flows by using queuing and scheduling.
Based on queuing and scheduling policies, LAN-side interfaces on the device support PQ,
DRR, PQ+DRR, WRR, and PQ+WRR. WAN-side interfaces support PQ, WFQ, and PQ+WFQ.
On the device, there are four or eight queues on each interface in the outbound direction, which are
identified by index numbers. The index numbers range from 0 to 3 or 0 to 7. Based on the
mappings between local priorities and queues, the device sends the classified packets to queues,
and then schedules the packets using queue scheduling mechanisms.
 PQ scheduling
PQ scheduling is designed for core services, and is applied to the queues in descending order
of priorities. Queues with lower priories are processed only after all the queues with higher
priorities are empty. In PQ scheduling, packets of core services are placed into a queue of a
higher priority, and packets of non-core services such as email services are placed into a queue
of a lower priority. Core services are processed first, and non-core services are sent at intervals
when core services are not processed.
As shown in Figure 14-5-10, the priorities of queues 7 to 0 are in descending order of priorities.
The packets in queue 7 are processed first. The scheduler processes packets in queue 6 only
after queue 7 becomes empty. The packets in queue 6 are sent at the link rate when packets in
queue 6 need to be sent and queue 7 is empty. The packets in queue 5 are sent at the link rate
when queue
6 and queue 7 are empty, and so on.
PQ scheduling is valid for short-delay services. Assume that data flow X is mapped to the
queue of the highest priority on each node. When packets of data flow X reach a node, the
packets are processed first.
The PQ scheduling mechanism, however, may result in starvation of packets in queues

with lower priorities. For example, if data flows mapped to queue 7 arrive at 100% link
rate in a period, the scheduler does not process flows in queue 6 and queues 0 to 5.
To prevent starvation, upstream devices need to accurately define service features of data flows
so that service flows mapped to queue 7 does not exceed a certain percentage of the link
capacity. By doing this, queue 7 is always in empty state and the scheduler can process packets
in queues with lower priorities.
Figure 14-5-10 PQ scheduling
 WRR scheduling
Weight Round Robin (WRR) scheduling is an extension of Round Robin (RR) scheduling.
Packets in each queue are scheduled in a polling manner based on the queue weight. RR
scheduling equals WRR scheduling with the weight being 1.
Figure 14-5-11 shows WRR scheduling.

Figure 14-5-11 WRR scheduling
In WRR scheduling, the device schedules packets in queues in a polling manner round by
round based on the queue weight. After one round of scheduling, the weights of all queues are
decreased by 1. The queue whose weight is decreased to 0 cannot be scheduled. When the
weights of all the queues are decreased to 0, the next round of scheduling starts. For example,
the weights of eight queues on an interface are set to 4, 2, 5, 3, 6, 4, 2, and 1. Table 14-5-3 lists
the WRR scheduling results.
Table 14-5-3 WRR scheduling results
Queue Queue 7
Index
Queue 4
Weight
Queue in the first round of scheduling Queue 7
Queue in the second round of scheduling Queue 7
Queue in the third round of scheduling Queue 7
Queue in the fourth round of scheduling Queue 7

Table 14-5-3 WRR scheduling results
Queue Queue 7
Index
Queue in the fifth round of scheduling -
Queue in the sixth round of scheduling -
Queue in the Queue 7

seventh round of scheduling
Queue in the eighth round of scheduling Queue 7
Queue in the ninth round of scheduling Queue 7
Queue in the tenth round of scheduling Queue 7
Queue in the eleventh round of scheduling -
Queue in the twelfth round of scheduling -
The statistics show that the number of times packets are scheduled in each queue corresponds
to the queue weight. A higher queue weight indicates a greater number of times packets in the
queue are scheduled. The unit for WRR scheduling is packet; therefore, there is no fixed
bandwidth for each queue. If packets are scheduled fairly, large-sized packets obtain more
bandwidth than small-sized packets.
WRR scheduling offsets the disadvantage of PQ scheduling in which packets in queues with
lower priories may be not processed for a long period of time. In addition, WRR can
dynamically change the time of scheduling packets in queues. For example, if a queue is empty,
WRR scheduling ignores this queue and starts to schedule the next queue. This ensures
bandwidth usage. WRR scheduling, however, cannot schedule short-delay services in time.
 DRR scheduling
Deficit Round Robin (DRR) is also based on RR. DRR solves the WRR problem. In WRR
scheduling, a large-sized packet obtains less bandwidth than a small-sized packet. DRR
schedules packets considering the packet length, ensuring that packets are scheduled
equally.
Deficit indicates the bandwidth deficit of each queue. The initial value is 0. The system allocates
bandwidth to each queue based on the weight and calculates the deficit. If the deficit of a queue
is greater than 0, the queue participates in scheduling. The device sends a packet and calculates
the deficit based on the length of the sent packet. If the deficit of a queue is smaller than 0, the
queue does not participate in scheduling. The current deficit is used as the basis for the next roun
d of scheduling.
Figure 14-5-12 Queue weights

In Figure 14-5-12, the weights of Q7, Q6, Q5, Q4, Q3, Q2, Q1, and Q0 are set to 40, 30, 20, 10,
40, 30, 20, and 10 respectively. During scheduling, Q7, Q6, Q5, Q4, Q3, Q2, Q1, and Q0 obtain
20%, 15%, 10%, 5%, 20%, 15%, 10%, and 5% of the bandwidth respectively. Q7 and Q6 are
used as examples to describe DRR scheduling. Assume that Q7 obtains 400 bytes/s
bandwidth and Q6 obtains 300 bytes/s bandwidth.
 First round of scheduling
Deficit[7][1] = 0+400 = 400
Deficit[6][1] = 0+300 = 300
After packet of 900 bytes in Q7 and packet of 400 bytes in Q6 are sent, the values are
as follows:
Deficit[7][1] = 400-900 =-500
Deficit[6][1] = 300-400 =-100
 Second round of scheduling
Deficit [7][2] = -500 + 400 = -100
Deficit [6][2] = -100 + 300 = 200
Packet in Q7 is not scheduled because the deficit of Q7 is negative. Packet of 300 bytes in
Q6 are sent, the value is as follows:
Deficit [6][2] = 200-300 =-100.
 Third round of scheduling
Deficit[7][3] = -100+400 = 300
Deficit[6][3] = -100+300 = 200
Packet of 600 bytes in Q7 and packet of 400 bytes in Q6 are sent, the values are as
follows: Deficit[7][3] = 300-600 =-300
Deficit[6][3] = 200-500 =-300
Such a process is repeated and finally Q7 and Q6 respectively obtain 20% and 15% of
the bandwidth. This illustrates that you can obtain the required bandwidth by setting the
weights.
In DRR scheduling, short-delay services still cannot be scheduled in time.
 WFQ scheduling
Fair Queuing (FQ) equally allocates network resources so that the delay and jitter of all flows
are minimized.
 Packets in different queues are scheduled fairly. The delays of all flows have
slight difference.
 Packets with different sizes are scheduled fairly. If many large and small packets in
different queues need to be sent, small packets are scheduled first so that the total
packet jitter of each flow is reduced.
Compared with FQ, WFQ schedules packets based on priorities. WFQ schedules packets
with higher priorities before packets with lower priorities.
Before packets enter queues, WFQ classifies the packets based on:
 Session information
WFQ classifies flows based on the session information including the protocol type, source
and destination TCP or UDP port numbers, source and destination IP addresses, and
precedence field in the ToS field. Additionally, the system provides a large number of
queues and equally places flows into queues to smooth out the delay. When flows leave
queues, WFQ allocates the bandwidth on the outbound interface for each flow based on
the precedence of each flow. Flows with the lowest priorities obtain the least bandwidth.
Only the packets matching the default traffic classifier in CBQ can be classified based on
session information.
 Priority
The priority mapping technique marks local priorities for traffic and each local priority
maps a queue number. Each interface is allocated four or eight queues and packets
enter queues. By default, queue weights are the same and traffic equally shares the
interface bandwidth. Users can change weights so that high-priority and low-priority
packets are
allocated bandwidth based on weight percentage.
Figure 14-5-13 WFQ scheduling
 PQ+WRR scheduling
PQ scheduling and WRR scheduling have advantages and disadvantages. To offset

disadvantages of PQ scheduling or DRR scheduling, use PQ+WRR scheduling. Packets from
queues with lower priorities can obtain the bandwidth by WRR scheduling and short-delay
services can be
scheduled first by PQ scheduling.
On the device, you can set WRR parameters for queues. The eight queues on each interface
are classified into two groups. One group includes queue 7, queue 6, and Queue 5, and is
scheduled in PQ mode; the other group includes queue 4, queue 3, queue 2, queue 1, and queue
0, and is
scheduled in WRR mode. Only LAN-side interfaces on the device support PQ+WRR scheduling.
Figure 14-5-14 shows PQ+WRR scheduling.
Figure 14-5-14 PQ+WRR scheduling

During scheduling, the device first schedules traffic in queue 7, queue 6, and queue 5 in PQ
mode. The device schedules traffic in other queues in WRR mode only after the traffic in queue
7,
queue 6, and queue 5 are scheduled. Queue 4, queue 3, queue 2, queue 1, and queue 0 have their
own weights. Important protocol packets or short-delay service packets must be placed in
queues using PQ scheduling so that they can be scheduled first. Other packets are placed in
queues using WRR scheduling.
 PQ+DRR scheduling
Similar to PQ+WRR, PQ+DRR scheduling offsets disadvantages of PQ scheduling and DRR

scheduling. If only PQ scheduling is used, packets in queues with lower priorities cannot obtain
bandwidth for a long period of time. If only DRR scheduling is used, short-delay services such
as voice services cannot be scheduled first. PQ+DRR scheduling has advantages of both PQ and
DRR scheduling and offsets their disadvantages.
Eight queues on the device interface are classified into two groups. You can specify PQ
scheduling for certain groups and DRR scheduling for other groups.
Figure 14-5-15 PQ+DRR scheduling
As shown in Figure 14-5-15, the device first schedules traffic in queues 7, 6, and 5 in PQ mode.
After traffic scheduling in queues 7, 6, and 5 is complete, the device schedules traffic in queues
4,
3, 2, 1, and 0 in DRR mode. Queues 4, 3, 2, 1, and 0 have their own weight.
Important protocol packets or short-delay service packets must be placed in queues using
PQ scheduling so that they can be scheduled first. Other packets are placed in queues using
DRR scheduling.
 PQ+WFQ scheduling
Similar to PQ+WRR, PQ+WFQ scheduling has advantages of PQ scheduling and WFQ

scheduling and offsets their disadvantages. If only PQ scheduling is used, packets in queues
with lower priorities cannot obtain bandwidth for a long period of time. If only WFQ
scheduling is used, short-delay services such as voice services cannot be scheduled first. To
solve the problem, configure PQ+WFQ scheduling.
Eight queues on the device interface are classified into two groups. You can specify PQ
scheduling for certain groups and WFQ scheduling for other groups. Only WAN-side
interfaces support PQ+WFQ scheduling.
Figure 14-5-16 PQ+WFQ scheduling
As shown in Figure 14-5-16, the device first schedules traffic in queue 7, queue 6, and queue 5
in PQ mode. After traffic scheduling in queues 7, 6, and 5 is complete, the device schedules
traffic in queues 4, 3, 2, 1, and 0 in WFQ mode. Queues 4, 3, 2, 1, and 0 have their own
weights.
Important protocol packets or short-delay service packets must be placed in queues using PQ
scheduling so that they can be scheduled first. Other packets are placed in queues using
WFQ scheduling.
 CBQ scheduling
Class-based queueing (CBQ) is an extension of WFQ and matches packets with traffic
classifiers. CBQ classifies packets based on the IP precedence or DSCP priority, inbound
interface, or
5-tuple (protocol type, source IP address and mask, destination IP address and mask, source
port range, and destination port range). Then CBQ puts packets into different queues. If packets
do not match any configured traffic classifiers, CBQ matches packets with the default traffic
classifier.
Figure 14-5-17 CBQ scheduling
As shown in Figure 14-5-17, CBQ provides the following types of queues:

 Expedited Forwarding (EF) queues are applied to short-delay services.
 Assured Forwarding (AF) queues are applied to key data services that require
assured bandwidth.
 Best-Effort (BE) queues are applied to best-effort services that require no strict QoS
assurance.
 EF queue
An EF queue has the highest priority. You can put one or more types of packets into EF
queues and set different bandwidth for different types of packets.
During packet scheduling, packets in EF queues are sent first. When congestion occurs,
packets in EF queues are sent first. To ensure that packets in AF and BE queues are
scheduled, packets in EF queues are sent at the configured rate limit. When no congestion
occurs, EF queues can use available bandwidth of AF and BE queues. The EF queues can
be allocated available bandwidth but cannot occupy additional bandwidth. This protects
the bandwidth available to other packets.
In addition to common EF queues, the device provides a special EF queue, LLQ queue.
Both EF and LLQ queues use the SP mode. The device uses traffic policing to process
packets in LLQ queues, ensuring a short delay because traffic policing does not buffer
packets. The traffic does not exceed the configured bandwidth regardless of whether
the
interface is congested. LLQ provides good QoS assurance for delay-sensitive services
such as VoIP services.
 AF queue
Each AF queue corresponds to one type of packets. You can set bandwidth for each type
of packets. During scheduling, the system sends packets based on the configured
bandwidth. AF implements fair scheduling. If an interface has remaining bandwidth,
packets in AF queues obtain the remaining bandwidth based on weights. When congestion
occurs, each type of packets can obtain the minimum bandwidth.
If the length of an AF queue reaches the maximum value, the tail drop method is used
by default. You can choose to use WRED.
 BE queue
If packets do not match any configured traffic classifiers, packets match the default
traffic classifier defined by the system. You are allowed to configure AF queues and
bandwidth for the default traffic classifier, whereas BE queues are configured in most
situations. BE uses WFQ scheduling so that the system schedules packets matching the
default traffic classifier based on flows.
If the length of a BE queue reaches the maximum value, the tail drop method is used
by default. You can choose to use WRED.
14.5.7 Congestion Avoidance
Congestion avoidance is a flow control mechanism. A system configured with congestion

avoidance monitors network resource usage such as queues and memory buffers. When congestion
occurs or aggravates, the system discards packets.
Congestion avoidance uses tail drop and WRED to discard packets.
 Traditional tail drop policy
The traditional packet drop policy uses the tail drop method. When the length of a queue
reaches the maximum value, all the packets last added to the queue (at the tail of the queue) are
discarded.
This packet drop policy may cause global TCP synchronization. As a result, TCP connections
cannot be set up. The three colors represent three TCP connections. When packets from
multiple TCP connections are discarded, these TCP connections enter the congestion avoidance
and slow start state. Traffic reduces, and then reaches the peak. The volume of traffic varies
greatly.
Figure 14-5-18 Tail drop policy
 WRED
To avoid global TCP synchronization, Random Early Detection (RED) is used. The RED
mechanism randomly discards packets so that the transmission speed of multiple TCP
connections is not reduced simultaneously. In this manner, global TCP synchronization
is prevented. The rate of TCP traffic and network traffic become stable.
Figure 14-5-19 RED

Based on the RED technology, the device provides Weighted Random Early Detection (WRED).
WRED discards packets in queues based on DSCP priorities or IP priorities. You can set the
upper drop threshold, lower drop threshold, and drop probability for different types of packets
independently. When the number of packets reaches the lower drop threshold, the device starts
to discard packets. When the number of packets reaches the upper drop threshold, the device
discards all the packets. A higher threshold indicates a high drop probability. The greatest drop
probability cannot exceed the upper drop threshold percentage. WRED discards packets in
queues based on the drop probability, preventing a certain degree of congestion.
14.5.8 Traffic Policy
A traffic policy classifies traffic based on rules and associates actions with traffic of the same type. A
traffic policy that is applied can monitor traffic, remark packet priorities, and redirect packets.
A traffic policy contains the following entities: traffic classifier, traffic behavior, and traffic policy.
Traffic Classifier
A traffic classifier identifies packets of a certain type by using matching rules, and is the basis
for providing differentiated services.
You can define matching rules to classify packets and specify the relationship between matching rules.
 AND: Packets match a traffic classifier only when the packets match all the rules. If a traffic
classifier contains ACL rules, packets match the traffic classifier only when the packets
match one ACL rule and all the non-ACL rules. If a traffic classifier does not contain ACL
rules, packets match the traffic classifier only when the packets match all the non-ACL rules.
 OR: Packets match a traffic classifier as long as they match one of rules.
Table 14-5-4 lists traffic classification rules.
Table 14-5-4 Traffic classification rules
Layer 2
Layer 3
Table 14-5-4 Traffic classification rules
Others
Traffic Behavior
A traffic behavior is a set of actions to be taken for packets of a specified type. A traffic classifier
must be associated with a traffic control action or a resource allocation action so that the device can
provide differentiated services.
The device supports the following actions in a traffic

behavior:
 Packet filtering
The packet filtering action is the simplest traffic control action. The device controls
network traffic by forwarding or discarding packets to implement firewall filtering
functions.
 Re-marking
This traffic control action sets the precedence field in a packet. Packets carry different
precedence fields on various networks. For example, packets carry the 802.1p field in a VLAN,
the ToS field on an IP network, and the EXP field on an MPLS network. Therefore, the device
is required to mark precedence fields of packets based on the network type.
Generally, a device at the border of a network needs to re-mark precedence fields of

incoming packets; the device in the core of a network provides corresponding QoS services
based on precedence fields marked by the border device, or re-marks the precedence fields
based on its configuration rule.
 Redirection
This traffic control action redirects packets to the CPU, specified interface, specified next
hop address, or Label Switched Path (LSP). The device does not forward packets based on
the destination IP address.
By using redirection, you can implement policy-based routing (PBR). A policy-based route is a
static route. When the next hop is unavailable, the device forwards packets based on the
original forwarding path.
 Traffic policing
This traffic control action limits the volume of traffic and the resources used by the traffic
by monitoring the rate of the traffic. To prevent network congestion caused by burst traffic,
use
traffic policing so that the device can discard excess packets, re-mark the color or precedence
of excess packets, or implement other QoS measures over excess packets.
 Traffic shaping
This traffic control action limits the volume of traffic and the resources used by the traffic by
monitoring the rate of the traffic. Traffic shaping adjusts the rate of outgoing traffic so that
the downstream device has sufficient capabilities to process traffic. This implementation
prevents packet loss and congestion. Traffic shaping controls the volume of outgoing traffic
over a network connection on a network so that the outgoing traffic can be sent out at an even
rate.
 Flow mirroring
This traffic control action copies the specified data packets to a specified destination to detect
and troubleshoot faults on a network.
 Queue scheduling
Queue scheduling involves configurations relevant to queues, including scheduling modes of

Expedited Forwarding (EF), Assured Forwarding (AF), Low Latency Queuing (LLQ), and
Weighted Fair Queuing (WFQ) queues, traffic shaping, and Weighted Random Early Detection
(WRED).
 Traffic statistics
This traffic control action collects data packets matching complex traffic classification rules.
The traffic statistics action is not a QoS control measure, but can be used with other actions
to
improve security of networks and packets.
 Binding a sub traffic policy
This action binds a traffic behavior in a traffic policy to a sub traffic policy. When a traffic
policy is bound to a sub traffic policy, the traffic behavior in the traffic policy is taken for
packets matching the traffic classifier associated with the traffic behavior. Then the packets are
classified by the sub traffic policy and the traffic behavior in the sub traffic policy is taken for
the classified packets. This action implements fine-grained HQoS.
The device supports two layers of traffic policies. A sub traffic policy cannot be nested
by another traffic policy.
 Disabling URPF
After this action is configured, the device does not perform URPF check for packets matching
traffic classification rules. After URPF is enabled on an interface, the device performs URPF
check for all the traffic entering the interface. The device discards packets whose source
address does not match the inbound interface. To prevent packets of a certain type from being
discarded, you can disable URPF check for these packets. For example, if the device is
configured to trust all the packets from a certain server, the device does not check these
packets.
 Adding the outer VLAN tag

After this action is configured, the device adds an outer VLAN tag to packets matching traffic
classification rules. When the downstream device provides differentiated services based on
the outer VLAN tag, configure this action.
 Disabling MAC address learning
After this action is configured, the device does not learn MAC addresses of packets matching
traffic classification rules. On a stable network where MAC addresses of packets seldom
change, disabling MAC address learning can reduce the size of the MAC address table and
improve device performance.
Traffic Policy
A traffic policy is a complete policy configured by binding traffic classifiers to traffic behaviors.
Differentiated services are provided for service flows by applying traffic policies to the
interfaces, devices, boards, or VLANs.
14.6 SNMP
14.6.1 SNMP Management Model
The SNMP system is composed of the NMS, agent, management object, and MIB.
The NMS is the network management center of the network and manages devices on the network.
Each managed device has the agent process, MIB, and multiple managed objects. The NMS
interacts
with the agent on the managed device. The agent performs operations on the MIB to perform the NMS
request.
Figure 14-6-1 shows an SNMP management model.

Figure 14-6-1 SNMP management model
Elements in the network management system are as follows:
 NMS
A manager on the network, or a system using SNMP to manage and monitor network
devices. The NMS runs on NMS servers.
 An NMS can send requests to an agent on a device to query or modify the value of one
or multiple parameters.
 An NMS can receive traps sent from the agent on a device to learn the current status of
the device.
 Agent
Agent is a process on the managed device. The agent maintains data on the managed device,
receives and processes the request packets from the NMS, and then sends the response packets
to the NMS.
 Upon receiving requests of the NMS, the agent performs the required operation over th e
MIB and sends the operation result to the NMS.
 When a fault or an event occurs on the device, the agent running on the device
sends notifications to the NMS, reporting the current status of the device.
 Management object
Object to be managed. A device may have multiple management objects, including a

hardware component (such as an interface board), software, and parameters (such as a route
selection protocol) configured for the hardware or software.
 MIB
MIB is a database specifying variables that are maintained by the managed device and can be
queried or set by the agent. MIB defines attributes of the managed device, including the
name, status, access rights, and data type of objects.
An agent can use the MIB to:
 Learn the current status of the device.
 Set the status parameter of the device.
The SNMP MIB adopts a tree structure like the Domain Name System (DNS) with its root on
the top without a name. Figure 14-6-2 shows a part of the MIB, called object naming tree. Each
object identifier (OID) maps a managed object, for example, the system OID is 1.3.6.1.2.1.1,
and the interface OID is 1.3.6.1.2.1.2.
The OID tree facilitates information management and improves management efficiency. With the
OID tree, the network administrator can query information in batches.
When configuring the agent, the user can configure the MIB object access control for the NMS
based on the MIB view. A MIB view is a subset of a MIB.
Figure 14-6-2 OID tree
14.6.2 SNMPv1/SNMPv2c
SNMPv1/SNMPv2c Packet Format
As shown in Figure 14-6-3, a SNMPv1 packet is composed of the version, community name, and
SNMP Protocol Date Unit (PDU) fields.
Figure 14-6-3 SNMPv1/SNMPv2c packet format

The fields in a SNMPv1/SNMPv2c packet are defined as follows:
 Version: SNMP version. The SNMPv1 packet field is 0, and the SNMPv2c packet field is 1.
 Community name: used for authenticating operations between the agent and NMS. The
community name is a string of characters and can be defined by users. The community name
can be a read-only or write-only community name. To authenticate the GetRequest or
GetNextRequest operations, use the read-only community name; to authenticate the Set
operation, use the write-only community name.
 SNMPv1/SNMPv2c PDU: includes the PDU type, request ID, and binding variable list. The
SNMPv1 PDU includes GetRequest PDU, GetNextRequest PDU, SetRequest PDU,
Response PDU, and Trap PDU. The SNMPv2c PDU inherits the SNMPv1 PDU and
introduces the GetBulkRequest PDU and InformRequest PDU.
For simplification, the SNMP operations are described as the Get, GetNext, Set, Response,
Trap, GetBulk, and Inform operations.
SNMPv1/SNMPv2c Operations
As shown in Table 14-6-1, SNMPv1/SNMPv2c defines seven types of operations for

exchanging information between the NMS and the agent.
Table 14-6-1 SNMPv1/SNMPv2c Operations
Operation Description
Get The management process reads one or several parameter values from the MIB
of the agent process.
GetNext The management process reads the next parameter value from the MIB of
the agent process.
Set The management process sets the parameter value of one or more MIBs of
the agent process.
Response The agent process returns one or more queried values. The agent performs this
operation that corresponds to the GetRequest, GetNextRequest, SetRequest, and
GetBulkRequest operations. Upon receiving a Get or Set request, the agent
performs the Query or Modify operation using MIB tables and then sends the
responses to the NMS.
Trap The agent process notifies the NMS of a fault or event on the managed device.
GetBulk The NMS queries managed devices in batches.
Inform The managed device notifies the NMS of an alarm on a managed device. After the
managed device sends an inform, the NMS must send an InformResponse
packet to the managed device.
NOTE:
SNMPv1 does not support the GetBulk or Inform operations.
Working Mechanisms of SNMPv1/SNMPv2c
The working mechanisms of SNMPv1 and SNMPv2c are similar, as shown in Figure 14-6-4.
Figure 14-6-4 Basic operations
 Get
The following assumes that the NMS wants to use the read-only community name public
to obtain the value of the object sysContact on the managed devices. The procedure is as follows:
1. NMS: sends a GetRequest packet to the agent. The fields of the packet are set as
follows: The version is the SNMP version in use; the community name is public; the
PDU type is Get; the MIB object is sysContact.
2. Agent: authenticates the version and community name of the packet. When
authentication succeeds, the agent encapsulates the queried sysContact value into the
PDU of the response packet. Then the agent sends the response packet to the NMS. If the
agent fails
to obtain the sysContact value, the agent will send an incorrect response packet to the
NMS.
 GetNext
The following assumes that the NMS wants to use the community name public to obtain the
value of the object sysName (object next to sysContact) on the managed device. The procedure
is as follows:
1. NMS: sends a GetNext request packet to the agent. The fields of the packet are set as
follows: The version is the SNMP version in use; the community name is public; the
PDU type is GetNext; the MIB object is sysContact.
authentication succeeds, the agent encapsulates the queried sysName value into the PDU
of the response packet. Then the agent sends the response packet to the NMS. If the
agent fails to obtain the sysName value, the agent will send an incorrect response packet
to the NMS.
 Set
The following assumes that the NMS wants to use the read-only community name private to set
the value of the object sysName on the managed device to HUAWEI. The procedure is
as follows:
1. NMS: sends a SetRequest packet to the agent. The fields of the packet are set as follows:
The version is the SNMP version in use; the community name is private; the PDU type
is Set; the MIB object is sysContact; the target value is HUAWEI.
authentication succeeds, the agent sets an object mapping the requested management
variable. If the
setting succeeds, the agent sends a response packet to the NMS. If the setting fails, the
agent will send an incorrect response packet to the NMS.
 Trap
Trap is a spontaneous behavior of a managed device. Traps do not belong to the basic operations
performed by the NMS on the managed device. If a managed device meets the triggering
condition for generating a trap, the agent notifies the NMS of the exception by sending a trap.
For example, when a managed device is started in hot startup mode, the agent sends a warmStart
trap to the NMS.
The agent sends the trap to the management process only when a module on the device meets
the triggering condition for generating a trap. This method reduces exchange traffic by sending
traps only when major events occur.
Figure 14-6-5 shows the operations that are added in SNMPv2c.
Figure 14-6-5 New operations in SNMPv2c
 GetBulk
The GetBulk operation is equal to consecutively performed GetNext operations. You can set
the number of times that the GetNext operations are performed during one GetBulk operation.
 Inform
A managed device notifies the NMS of an inform. After the managed device sends an inform,
the NMS must send an InformResponse packet to the managed device. If the managed device
does not receive the response packet, the managed device performs the following operations:
1. Save the alarm in the inform buffer.
2. Repeatedly send the alarm until the NMS returns the response packet or the number
of times that the managed device sends alarms exceeds the allowed range.
3. An alarm log is generated on the managed device.
Therefore, informs may occupy many system resources.
14.6.3 SNMPv3
SNMPv3 Packet Format
SNMPv3 defines a new packet format shown in Figure 14-6-6.

Figure 14-6-6 SNMPv3 packet format
The following describes the composition of a SNMPv3 packet:
 Version: SNMP version. The SNMPv3 packet field is 2.
 Header: information such as the maximum message size supported by the transmitter,
and security mode of messages.
 Security parameters: security information including the entity engine information, user
name, authentication parameter, and encryption information.
 SNMPv3 PDU: includes the following information:
 Context EgineID: SNMP ID. Together with the PDU type, it determines which
application messages are to be sent.
 Context Name: determines the Context EgineID MIB view of the managed device.
 PDU data: includes the PDU type, request ID, and binding variable list. The SNMPv3
PDU includes GetRequest PDU, GetNextRequest PDU, SetRequest PDU, Response PDU,
Trap PDU, GetBulkRequest PDU, and InformRequest PDU.
SNMPv3 Architecture
SNMPv3 uses the SNMPv3 entity for the communication between different SNMP-enabled NMSs. A
SNMPv3 entity consists of SNMPv3 engines and applications, and each SNMPv3 engine or
application has multiple modules.
The modular architecture of the SNMP entity has the following advantages:
 Strong adaptability: This architecture is adaptable for both simple and complex networks.
 Easy management: This architecture consists of multiple independent sub-systems and

applications. When a fault occurs in the system. It is easy to locate the sub-system to which
the fault belongs based on the fault type.
 Excellent expandability: An SNMP system can be extended by increasing the number of

modules on the SNMP entity. For example, a module can be added in the security sub-system
for the application of a new security protocol.
SNMPv3 improves security by adopting the user security model (USM) and view-based access
control model (VACM).
 USM: authenticates user identity and encrypts data. These two functions require that the NMS
and the agent use a shared key.
 Identify authentication: a process in which the agent (or the NMS) confirms whether
the received message is from an authorized NMS (or agent) and whether the message is
changed during transmission. RFC 2104 defines Keyed-Hashing for Message
Authentication Code (HMAC), an effective tool that uses the security hash function and
key to generate the message authentication code. This tool is widely used in the Internet.
HMAC used in SNMP contains HWAC-MD5-96 and HWAC-SHA-96. The hash
function of HWAC-MD5-96 is MD5 that uses 128-bit authKey to generate the key. The
hash function of HWAC-SHA-96 is SHA-1 that uses 160-bit authKey to generate the
key.
 Data encryption: uses the cipher block chaining (CBC) code of the data encryption
standard (DES) and uses 128-bit privKey to generate the key. The network management
station uses the key to calculate the CBC code and then adds the CBC code to the
message while the agent fetches the authentication code through the same key and then
obtains the actual information. Like identity authentication, data encryption also requires
the network management station and the agent to use a shared key for encryption or
decryption.
 VACM: controls access of user groups or community names based on the view. You must
pre-configure a view and specify its authority. Then, when you configure a user, user group,
or community, load this view to implement read/write restriction or trap function.
SNMPv3 Mechanism
The mechanism of SNMPv3 is similar to those of SNMPv1 and SNMPv2, but SNMPv3 supports
identity authentication and encryption. The following describes the SNMPv3 mechanism by using
the Get operation as an example.
The following assumes that the NMS wants to obtain the value of the object sysContact on
the managed device in authentication and encryption mode, as shown in Figure 14-6-7.
Figure 14-6-7 Get operation of SNMPv3

1. NMS: sends a GetRequest packet without security parameters to the agent and requests
the values of Context EgineID, Context Name, and security parameter.
2. Agent: responds to the request from the NMS by providing the requested parameters.
3. NMS: sends a GetRequest packet to the agent. The packet fields are set as follows:
 Version: SNMPv3.
 Header: specifies authentication and encryption.

 Security parameters: The NMS calculates the authentication and encryption parameters
using the configured algorithm. These parameters and security parameters are filled in
the corresponding fields.
 PDU: Set corresponding fields using obtained Context EgineID and Context Name.
The PDU type is set to Get, the MIB object is sysContact, and the configured
encryption algorithm is used to encrypt the PDU.
4. Agent: authenticates the messages. When authentication succeeds, the agent decrypts the PDU.
When encryption succeeds, the agent obtains the value of sysContact and encapsulates it to
the PDU in the response packet. The agent encrypts the PDU and sends the response packet to
the NMS. If the query, authentication, or encryption fails, the agent will send an incorrect
response packet to the NMS.
14.6.4 Comparison among SNMP Versions
Table 14-6-2 Comparison in the security of SNMP of different versions
Protocol version
SNMPv1
SNMPv2c
SNMPv3
14.7 NQA
14.7.1 Principles
Constructing a test instance
NQA requires two test ends, an NQA client and an NQA server (or called the source and
destination). The NQA client (or the source) initiates an NQA test. You can configure test instances
through command lines or the NMS. Then NQA places the test instances into test queues for
scheduling.
Starting a test instance
When starting an NQA test instance, you can choose to start the test instance immediately, at a
specified time, or after a delay. A test packet is generated based on the type of a test instance when
the timer expires. If the size of the generated test packet is smaller than the minimum size of a
protocol packet, the test packet is generated and sent out with the minimum size of the protocol
packet.
Processing a test instance
After a test instance starts, the protocol-related running status can be collected according to response
packets. The client adds a timestamp to a test packet based on the local system time before sending
the packet to the server. After receiving the test packet, the server sends a response packet to the
client.
The client then adds a timestamp to the received response packet based on the current local system
time. This helps the client calculate the round-trip time (RTT) of the test packet based on the two
timestamps.
NOTE:
In a jitter test instance, both the client and server add a timestamp to the sent and received
packets based on the local system time. In this manner, the client can calculate the jitter value.
You can view the test results to learn about the network operating status and service
quality.
14.7.2 ICMP Test
An NQA ICMP test detects whether there are reachable routes from the source to the destination.
An ICMP test has similar functions as the ping command except that the ICMP test provides more
output information:
 By default, the system saves results of the latest five tests.
 The test results include the average delay, packet loss ratio, and time the last packet is
correctly received.
Figure 14-7-1 shows the process of an ICMP

test:
1. The source (RouterA) constructs an ICMP Echo Request packet and sends it to the destination
(RouterB).
2. After receiving the ICMP Echo Request packet, the destination responds the source with an
ICMP Echo Reply packet.
The source then can calculate the time for communication between the source and the
destination by subtracting the time the source sends the ICMP Echo Request packet from
the time the source receives the ICMP Echo Reply packet. The calculated data can reflect
the network operating status.
Figure 14-7-1 ICMP test scenario
The ICMP test results and historical records are collected in test instances. You can run commands
to view the test results and historical records.
14.7.3 TCP Test
An NQA TCP test measures the time taken to set up a TCP connection between an NQA client and a
TCP server through three-way handshake.
Figure 14-7-2 shows the process of a TCP test:
1. RouterA (NQA client) sends a TCP SYN packet to RouterB (TCP server) to set up a TCP
connection.
2. After receiving the TCP SYN packet, RouterB accepts the request and responds RouterA with a
TCP SYN ACK packet.
3. After receiving the SYN ACK packet, RouterA sends an ACK packet to RouterB.
Subsequently, a TCP connection is successfully set up.
Then RouterA can calculate the time taken to set up the TCP connection with RouterB by
subtracting the time RouterA sends the TCP SYN packet to the time RouterA receives the
TCP SYN ACK packet. This can reflect network TCP performance.
Figure 14-7-2 TCP test scenario

Frequent TCP tests will consume too many resources and affect device performance.
The TCP test results and historical records are collected in test instances. You can run commands
14.7.4 Trace Test
An NQA trace test detects the forwarding path between the source and the destination and collects
statistics about each device along the forwarding path. A trace test has similar functions as the
tracert command except that the trace test provides more output information, including the average
delay, packet loss ratio, and time the last packet is received.
Figure 14-7-3 shows the process of a trace test:

1. The source (RouterA) constructs a UDP packet, with the TTL as 1, and sends the packet to
the destination (RouterD).
2. After the first-hop router (RouterB) receives the UDP packet, it checks the TTL field and
finds that the TTL decreases to 0. Then RouterB returns an ICMP Time Exceeded packet.
3. After the source receives the ICMP Time Exceeded packet, it obtains the IP address of
the first-hop router and reconstructs a UDP packet, with the TTL as 2.
4. After the second-hop router (RouterC) receives the UDP packet, it checks the TTL field
and finds that the TTL decreases to 0. Then RouterC returns an ICMP Time Exceeded
packet.
5. The preceding process is repeated until the packet reaches the last-hop router, which
then returns an ICMP Port Unreachable packet to the source.
According to the ICMP packet received from each hop, the source obtains information about
the forwarding path from the source to the destination and statistics about each device along
the forwarding path. These statistics can reflect the forwarding path status.
Figure 14-7-3 Trace test scenario

The trace test results and historical records are collected in test instances. You can run commands
14.7.5 UDP Test
An NQA UDP test measures the time taken for communication between the source and the destination
(UDP server).
Figure 14-7-4 shows the process of a UDP test:
1. The source (RouterA) constructs a UDP packet and sends it to the destination (RouterC).
2. After receiving the UDP packet, the destination returns the packet to the source.
After receiving the UDP packet, the source calculates the time taken for communication
between the source and the destination by subtracting the time the source sends the UDP
packet from the time the source receives the UDP packet. This can reflect network UDP
performance.
Figure 14-7-4 UDP test scenario

The UDP test results and historical records are collected in test instances. You can run commands

1210
14.8 NTP
14.8.1 NTP Operating Principle
Figure 14-8-1 shows NTP implementation:
RouterA and RouterB are connected through a wide area network (WAN). Each of them has its
own system clock, which is synchronized automatically through NTP.
Presuming that:
 Before the clocks of RouterA and RouterB are synchronized, the clock of RouterA is
10:00:00 a.m. and the clock of RouterB is 11:00:00 a.m.
 RouterB acts as an NTP time server, and RouterA must synchronize its clock with that of
RouterB.
 It takes one second to unidirectionally transmit an NTP message between RouterA and RouterB.
 Both RouterA and RouterB take one second to process an NTP message.
Figure 14-8-1 Diagram of NTP implementation

The process of synchronizing the system clock is as follows:
1. RouterA sends an NTP message to RouterB. The message carries an initial timestamp, 10:00:00
a.m. (T1), indicating the time when it leaves RouterA.
2. When the NTP message reaches RouterB, RouterB adds the timestamp 11: 00:01 a.m. (T2) to
the NTP message, indicting the time when RouterB receives the message.
3. When the NTP message leaves RouterB, RouterB adds the transmit timestamp 11:00:02 a.m.
(T3) to the NTP message, indicating the time when the message leaves RouterB.
4. When RouterA receives this response message, it adds a new receive timestamp, 10:00:03
a.m. (T4).
RouterA uses the information in the received message to calculate the following two
important parameters:
 Roundtrip delay of the NTP message: Delay = (T4 - T1) - (T3 - T2)
 Clock offset of RouterA by taking RouterB as a reference: Offset = ((T2 - T1) + (T3
- T4))/2
5. After the calculation, RouterA knows that the roundtrip delay is 2 seconds and the clock offset
of RouterA is 1 hour. RouterA sets its own clock based on these two parameters to
synchronize its clock with that of RouterB.
NOTE:
The preceding example is only a brief description of the operating principle of NTP. In fact, NTP
uses the standard algorithms in RFC 1305 to ensure the precision of clock synchronization.
14.8.2 Network Architecture
In a synchronization subnet, the primary time server sends time information to other secondary
time servers using the NTP protocol. The secondary time servers then synchronize their clocks with
the primary time server. These servers are hierarchically connected, and each level of the hierarchy is
called a stratum and assigned a layer number. For example, the primary time server is a stratum 1
server, the secondary time servers are stratum 2 servers, and following strata can be obtained by
analogy. A larger clock stratum indicates lower precision.
The NTP network architecture involves the following concepts:
 Synchronization subnet consists of the primary time server, secondary time servers, clients,
and interconnecting transmission paths, as shown in Figure 14-8-2.
 Primary time server directly synchronizes its clock with a standard reference clock using a
cable or radio. The standard reference clock is usually a radio clock or the Global
Positioning System (GPS).
 Secondary time server synchronizes its clock with the primary time server or other
secondary time servers on the network. A secondary time server transmits the time
information to other hosts on a LAN through NTP.
 Stratum is a hierarchical standard for clock synchronization. It represents precision of a

clock.
The value of a stratum ranges from 1 to 16. A smaller value indicates higher precision. The value
1 indicates the highest clock precision, and 16 indicates that the clock is not synchronized.
Figure 14-8-2 NTP network architecture
Under normal circumstances, the primary time server and the secondary time servers in a
synchronization subnet are arranged in a hierarchical-master-slave structure. In this structure, the
primary time server is located at the root, and the secondary time servers are arranged close to leaf
nodes. As their strata increase, the precision decreases accordingly. The extent to which the
precision of the secondary time servers decreases depends on stability of network paths and the
local clock.
NOTE:
When the synchronization subnet has multiple primary time servers, the optimal server can be
selected using an algorithm.
Such a design ensures that:
 When faults occur in one or more primary/secondary time servers or network paths
interconnecting them, the synchronization subnet will automatically be reconstructed into
another hierarchical-master-slave structure to obtain the most precise and reliable time.
 When all primary time servers in the synchronization subnet become invalid, a standby
primary time server runs.
When all primary time servers in the synchronization subnet become invalid, other secondary time
servers are synchronized among themselves. These secondary time servers become independent of the
synchronization subnet and automatically run at the last determined time and frequency. When a
router with a stable oscillator becomes independent of the synchronization subnet for an extended
period of time, its timing error can be kept less than several milliseconds in a day because of highly
precise calculations.
14.8.3 Operating Mode
A device may use multiple NTP operating modes to perform time

synchronization.
 Unicast Server/Client Mode
 Symmetric Peer Mode
 Broadcast Mode
 Multicast Mode
 Manycast Mode
You can select an appropriate operating mode as required. When an IP address of the NTP server
or peer device cannot be determined or a large number of devices require synchronization on a
network, the broadcast or multicast mode can be used for clock synchronization. In server and peer
mode, the devices synchronize their clocks with a specified server or peer, which increases clock
reliability.
Unicast Server/Client Mode
The unicast server/client mode runs on a higher stratum on a synchronous subnet. In this mode,
devices need to obtain the IP address of the server in advance.
 Client: A host running in client mode (client for short) periodically sends packets to the server .
The Mode field in the packets is set to 3, indicating that the packets are coming from a client.
After receiving a reply packet, the client filters and selects clock signals, and synchronizes its
clock with the server that provides the optimal clock. A client does not check the reachability
and stratum of the server. Usually, a host running in this mode is a workstation on a network. It
synchronizes its clock with the clock of a server but does not change the clock of the server.
 Server: A host running in server mode (server for short) receives the packets from clients and
responds to the packets received. The Mode field in reply packets is set to 4, indicating that the
packets are coming from a server. Usually, the host running in server mode is a clock server on
a network. It provides synchronization information for clients but does not change its own
clock.
Figure 14-8-3 Unicast Client/Server Mode

During and after the restart, the host operating in client mode periodically sends NTP request
messages to the host operating in server mode. After receiving the NTP request message, the server
swaps the position of destination IP address and source IP address, and the source port number and
destination port number, fills in the necessary information, and sends the message to the client. The
server does not need to retain state information when the client sends the request message. The client
freely adjusts the interval for sending NTP request messages according to the local conditions.
Symmetric Peer Mode
The peer mode runs on a lower stratum on a synchronous subnet. In this mode, a symmetric active
peer and a symmetric passive peer can synchronize with each other. The symmetric peer with a higher
stratum (a lower level) synchronizes with a symmetric peer with a lower stratum (a higher level).
In symmetric peer mode, the symmetric active peer initiates an NTP packet with the Mode field set to
3 (the client mode), and the symmetric passive peer responds with an NTP packet with the Mode field
set to 4 (the server mode). This interaction creates a network delay so that devices at both ends enter
the symmetric peer mode.
 Symmetric active peer: A host that functions as a symmetric active peer sends packets
periodically. The value of the Mode field in a packet is set to 1. This indicates that the packet is
sent by a symmetric active peer, without considering whether its symmetric peer is reachable
and which stratum its symmetric peer is on. The symmetric active peer can provide time
information about the local clock for its symmetric peer, or synchronize the time information
about the local clock based on that of the symmetric peer clock.
 Symmetric passive peer: A host that functions as a symmetric passive peer receives packets from
the symmetric active peer and sends reply packets. The value of the Mode field in a reply packet
is set to 2. This indicates that the packer is sent by a symmetric passive peer. The symmetric
passive peer can provide time information about the local clock for its symmetric peer, or
synchronize the time information about the local clock based on that of the symmetric peer
clock.
Figure 14-8-4 Symmetric peer mode

The prerequisite for having a host run in symmetric passive mode is that: The host receives an
NTP packet from a symmetric peer running in symmetric active peer mode. The symmetric
active peer has a stratum lower than or equal to that of the host, and is reachable from the local
host.
NOTE:
The symmetric passive peer does not need to be configured. A host sets up a connection and
sets relevant state variables only when it receives an NTP packet.
Broadcast Mode
The broadcast mode is applied to the high speed network that has multiple workstations and does not
require high accuracy. In a typical scenario, one or more clock servers on the network periodically
send broadcast packets to the workstations. The delay of packet transmission in a LAN is at the
milliseconds level.
 Broadcast server: A host that runs in broadcast mode sends clock synchronization packets to
the broadcast address 255.255.255.255 periodically. The value of the Mode field in a packet is
set to
5. This indicates that the packet is sent by a host that runs in broadcast mode, without
considering whether its peer is reachable and which stratum its peer is on. The host running in
broadcast
mode is usually a clock server running high-speed broadcast media on the network, which
provides synchronization information for all of its peers but does not alter the clock of its
own.
 Broadcast client: The client listens to the clock synchronization packets sent from the server.
When the client receives the first clock synchronization packet, the client and server exchange
NTP packets whose values of Mode fields are 3 (sent by the client) and the NTP packets
whose values of Mode fields are 4 (sent by the server). In this process, the client enables the
server/client mode for a short time to exchange information with the remote server. This
allows the client to obtain the network delay between the client and the server. Then, the client
returns the broadcast mode, and continues to sense the incoming clock synchronization
packets to synchronize the local clock.
Figure 14-8-5 Broadcast mode
Multicast Mode
Multicast mode is useful when there are large numbers of clients distributed in a network. This
normally results in large number of NTP packets in the network. In the multicast mode, a single NTP
multicast packet can potentially reach all the clients on the network and reduce the control traffic on
the network.
 Multicast server: A server running in multicast mode sends clock synchronization packets to a
multicast address periodically. The value of the Mode field in a packet is set to 5. This
indicates that the packet is sent by a host that runs in multicast mode. The host running in
multicast mode is usually a clock server running high-speed broadcast media on the network,
which provides synchronization information for all of its peers but does not alter the clock of
its own.
 Multicast client: The client listens to the multicast packets from the server. When the client
receives the first broadcast packet, the client and server exchange NTP packets whose values
of Mode fields are 3 (sent by the client) and the NTP packets whose values of Mode fields are
4 (sent by the server). In this process, the client enables the server/client mode for a short time
to exchange information with the remote server. This allows the client to obtain the network
delay between the client and the server. Then, the client returns the multicast mode, and
continues to sense the incoming multicast packets to synchronize the local clock.
Figure 14-8-6 Multicast mode
Manycast Mode
Manycast mode is applied to a small set of servers scattered over the network. Clients can discover
and synchronize to the closest manycast server. Manycast can especially be used where the identity of
the server is not fixed and a change of server does not require reconfiguration of all the clients in the
network.
 Manycast client: The client in manycast mode periodically sends request packets (the Mode
field is set to 3) to an IPv4/IPv6 multicast address. After receiving a reply packet, the client
filters and selects clock signals, and synchronizes its clock with the server that provides the
optimal clock.
 Manycast server: The manycast server continuously listens to the packets. If a server can be
synchronized, the server returns a packet (the Mode field is set to 4) by using the unicast
address of the client as the destination address.
To prevent the client from constantly sending NTP request packets to the manycast server and reduce
the load of the server, the NTP protocol defines a minimum number of connections. In manycast
mode,
the client records the number of connections established every time it synchronizes clock with the
server. The minimum number of connections is the minimum number of connections called during a
synchronization process. If the number of connections called by the client reaches the minimum
number during subsequent synchronization processes and the synchronization is completed, the
client considers that the synchronization is completed. After that, the client sends a packet every time
a timeout period expires to maintain the connection. The NTP protocol uses the time to live (TTL)
mechanism to ensure that the client can successfully synchronize with the server. Every time the
client
sends an NTP packet, the TTL of the packet increases (the initial value as 1) until the minimum
number of connections is reached or the TTL value reaches the upper limit. If the TTL reaches the
upper limit
or the number of connections called by the client reaches the minimum number, but connections
called by the client still cannot complete the synchronizing process, the client stops data transmission
in a timeout period to eliminate all connections. Then the client repeats the preceding process.
NOTE:
In NTP implementation, a peer structure is established for each synchronization source, and these
peer structures are stored in a chain in a Hash form. Each peer structure is corresponding to a
connection. A single device supports a maximum of 128 connections. When the number of
connections exceeds 128, no new connection can be established.
Figure 14-8-7 Manycast mode
14.8.4 NTP Access Control
When a time server on a synchronization subnet is faulty or encounters a malicious attack,

timekeeping on other clock servers on the subnet should not be affected. To meet this requirement,
NTP provides
the following security mechanisms to ensure network security: access authority, Kiss-o'-Death
(KOD)
and NTP authentication.
Access Authority
A device provides access authority, which is simpler and more secure, to protect a local
clock.
NTP access control is implemented based on an access control list (ACL). NTP supports four levels
of access authority, and a corresponding ACL rule can be specified for each level. If an NTP access
request hits the ACL rule for a level of access authority, they are successfully matched and the
access request enjoys the access authority at this level.
When an NTP access request reaches the local end, the access request is successively matched with
the access authority from the maximum one to the minimum one. The first successfully matched
access authority takes effect. The matching order is as follows:
1. peer: indicating the maximum access authority. A time request may be made for the local
clock and a control query may be performed on the local clock. The local clock can also be
synchronized to a remote server.
2. server: indicating that a time request may be made for the local clock and a control query
may be performed on the local clock, but the local clock cannot be synchronized with the
clock of the remote server.
3. synchronization: indicating that only a time request can be made for the local clock.
4. query: indicating the minimum access authority. Only a control query can be performed on
the local clock.
5. limited: taking effect only when the KoD function is enabled. The rate of incoming packets
is controlled and the kiss code is sent after the KoD function is enabled.
KOD
When a server receives a large number of client access packets within a specified period of time and
cannot bear the load, the KOD function can be enabled on the server to perform access control. KOD
is a brand new access control technology that is put forward in NTPv4, and it is used by the server to
provide information, such as a status report and access control, for the client.
A KOD packet is a special NTP packet. When the Stratum field in an NTP packet is 0, the packet
is called a KOD packet and the ASCII message it conveys is called kiss code and represents access
control information. Currently, only two types of kiss codes are supported: DENY and RATE.
After the KOD function is enabled on the server, the server sends kiss code DENY or RATE to
the client based on the configuration.
NOTE:
After the KOD function is enabled, the corresponding ACL rule needs to be configured. When the
ACL rule is configured as deny, the server sends the kiss code DENY. When the ACL rule is
configured as permit and the rate of NTP packets received reaches the configured upper limit, the
server sends the kiss code RATE.
When the client receives kiss code DENY, the client terminates all connections to the server and stops
sending packets to the server.
When the client receives kiss code RATE, the client immediately reduces its polling interval to
the server and continues to reduce the interval each time it receives a RATE kiss code.
Authentication
The NTP authentication function can be enabled on networks demanding high security. Differ ent
keys may be configured in different operating modes.
When a user enables the NTP authentication function in a certain NTP operating mode, the
system records the key ID in this operating mode.
 Sending process
The system determines whether authentication is required in this operating mode.
If authentication is not required, the system directly sends a packet. If authentication is required,
the system encrypts the packet using the key ID and an encryption algorithm and sends it.
NOTE:
Currently, devices support only the MD5 key authentication algorithm.
 Receiving process
After receiving a packet, the system determines whether the packet needs to be authenticated. If
the packet does not need to be authenticated, the system directly performs subsequent
processing on the packet. If the packet needs to be authenticated, the system authenticates the
packet using the key ID and a decryption algorithm. If the authentication fails, the system
directly discards the packet. If the authentication succeeds, the system processes the received
packet.
14.9 Examples for Configuring Other Technologies
14.9.1 Example for Configuring URPF
As show in Figure 14-9-1, the R&D department of an enterprise connects to GE1/0/0 of RouterA,
and the marketing department connects to GE2/0/0. RouterA has a reachable route to an external
server,
and users in the R&D and marketing departments are allowed to connect to the server through
RouterA. RouterA is required to prevent staff in other departments from accessing the server without
permission
using source IP address spoofing.
NOTE:
RouterA is an access router of the enterprise, and RouterB is an aggregation router.

Figure 14-9-1 Networking diagram of URPF configuration
Configure URPF on GE1/0/0 and GE2/0/0, and allow special processing for the default route.
Procedure
1. Configure URPF on the interface.
[RouterA-GigabitEthernet1/0/0] urpf strict allow-default-route
[RouterA-GigabitEthernet2/0/0] urpf strict allow-default-route
Run the display this command on GE1/0/0 to check the URPF configuration.
[RouterA-gigabitethernet1/0/0] display this

#
ip address 10.10.1.5 255.255.255.0
urpf strict allow-default-route
#
return
Run the display this command on GE2/0/0 to check the URPF configuration.
[RouterA-gigabitethernet2/0/0] display this

#
ip address 10.10.2.5 255.255.255.0
#
return
Configuration Files
#
sysname RouterA
#
ip address 10.10.1.5 255.255.255.0
#
ip address 10.10.2.5 255.255.255.0
#
return
14.9.2 Example for Configuring IPSG
As shown in Figure 14-9-2, host A and host B belong to the same department and RouterA is
directly connected to host A and host B in this department. Host A and host B are dynamically
allocated IP addresses by DHCP and added to different VLANs through interfaces of RouterA.
HostB communicates with a server on the Internet by using the IP address and MAC address of
HostA. As a result, HostA cannot use services provided by the server. RouterA is required to defend
against attack packet sent from host B so that host A can use services provided by the server.
Figure 14-9-2 Networking diagram of configuring IPSG
 Enable DHCP snooping on RouterA so that a dynamic binding table is generated.
NOTE:
Before configuring IPSG, ensure that DHCP snooping is enabled. For details on how to enable
DHCP snooping, see Configure Basic Functions of DHCP Snooping.
 Configure IP packet check in the VLAN view to check the source IP address, source MAC
address and interface number against the binding table. In this way, the device discards
attack packets from HostB.
Procedure
1. Globally enable DHCP snooping.
[RouterA] dhcp enable
[RouterA] dhcp snooping enable
2. Configure IP packet check in the view of VLAN 10.
[RouterA] vlan 10
[RouterA-vlan10] dhcp snooping enable
[RouterA-vlan10] ip source check user-bind enable
Configuration Files
#
sysname RouterA
#
dhcp enable
dhcp snooping enable
#
vlan 10
ip source check user-bind enable
#
return
14.9.3 Example for Configuring ARP Security Functions
As shown in Figure 14-9-3, Router connects to a server using Eth2/0/3 and connects to four users in
VLAN 10 and VLAN 20 using Eth2/0/1 and Eth2/0/2. The following ARP threats exist on the network:
 Attackers send bogus ARP packets or bogus gratuitous ARP packets to Router. ARP entries on
Router are modified, leading to packet sending and receiving failures.
 Attackers send a large number of IP packets with unresolvable destination IP addresses to

Router, leading to CPU overload.
 User1 sends a large number of ARP packets with fixed MAC addresses but variable source IP
addresses to Router. As a result, ARP entries on Router are exhausted and the CPU is
insufficient to process other services.
 User3 sends a large number of ARP packets with fixed source IP addresses to Router. As a
result, the CPU of Router is insufficient to process other services.
The administrator wants to prevent the preceding ARP flood attacks and provide users with
stable services on a secure network.
Figure 14-9-3 Networking for configuring ARP security functions
1. Configure strict ARP learning and ARP entry fixing to prevent ARP entries from being
modified by bogus ARP packets.
2. Configure rate limit on ARP Miss messages based on the source IP address. This function
defends against attacks from ARP Miss messages triggered by a large number of IP packets
with unresolvable IP addresses. At the same time, Router must have the capability to process a
large number of ARP Miss packets from the server to ensure network communication.
3. Configure ARP entry limit and rate limit on ARP packets based on the source MAC address.
These functions defend against ARP flood attacks caused by a large number of ARP
packets with fixed MAC addresses but variable IP addresses and prevent ARP entries from
being exhausted and CPU overload.
4. Configure rate limit on ARP packets based on the source IP address. This function
defends against ARP flood attacks from User3 with a fixed IP address and prevents CPU
overload.
Procedure
1. Create VLANs, add interfaces to the VLANs, and configure VLANIF interfaces.
# Create VLAN 10, VLAN 20, and VLAN 30, add Eth2/0/1 to VLAN 10, Eth2/0/2 to VLAN
20, and Eth2/0/3 to VLAN 30.
[Huawei] vlan batch 10 20 30
# Create VLANIF 10, VLANIF 20, and VLANIF 30, and assign IP addresses to them.
[Huawei] interface vlanif 10

[Huawei-Vlanif10] ip address 8.8.8.4 24
[Huawei-Vlanif10] quit
2. Configure strict ARP learning.
[Huawei] arp learning strict
3. Configure ARP entry fixing.
# Set the ARP entry fixing mode to fixed-mac.
[Huawei] arp anti-attack entry-check fixed-mac enable
4. Configure rate limit on ARP Miss messages based on the source IP address.
# Set the maximum rate of ARP Miss messages triggered by the server with the IP address
10.10.10.2 to 40 pps, and set the maximum rate of ARP Miss messages triggered by other
hosts to 20 pps.
[Huawei] arp-miss speed-limit source-ip maximum 20

[Huawei] arp-miss speed-limit source-ip 10.10.10.2 maximum 40
5. Configure interface-based ARP entry limit.
# Configure that Eth2/0/1 can learn a maximum of 20 dynamic ARP entries.

[Huawei-Ethernet2/0/1] arp-limit vlan 10 maximum 20
6. Configure rate limit on ARP packets based on the source MAC address.
# Set the maximum rate of ARP packets from User1 with the source MAC address
0001-0001-0001 to 10 pps.
[Huawei] arp speed-limit source-mac 0001-0001-0001 maximum 10
7. Configure rate limit on ARP packets based on the source IP address.
# Set the maximum rate of ARP packets from User3 with the source IP address 9.9.9.2 to
10 pps.
[Huawei] arp speed-limit source-ip 9.9.9.2 maximum 10
# Run the display arp learning strict command to check the global configuration of strict ARP
entry learning.
[Huawei] display arp learning strict

The global configuration:arp learning strict
Interface LearningStrictState
------------------------------------------------------------
------------------------------------------------------------
Total:0
Force-enable:0
Force-disable:0
# Run the display arp-limit command to check the maximum number of ARP entries that
the interface can dynamically learn.
[Huawei] display arp-limit interface ethernet 2/0/1

Interface LimitNum VlanID LearnedNum(Mainboard)
---------------------------------------------------------------------------
Ethernet2/0/1 20 10 0
---------------------------------------------------------------------------
Total:1
# Run the display arp anti-attack configuration all command to check the configuration of
ARP anti-attack.
[Huawei] display arp anti-attack configuration all
ARP anti-attack packet-check function: disable

ARP anti-attack entry-check mode: fixed-mac
ARP gateway-duplicate anti-attack function: disabled
ARP rate-limit configuration:

-------------------------------------------------------------------------------
Global configuration:
Interface configuration:
-------------------------------------------------------------------------------
ARP miss rate-limit configuration:

-------------------------------------------------------------------------------
Global configuration:
-------------------------------------------------------------------------------
ARP speed-limit for source-MAC configuration:

MAC-address suppress-rate(pps)(rate=0 means function disabled)
-------------------------------------------------------------------------------
0001-0001-0001 10
Others 0
-------------------------------------------------------------------------------
1 specified MAC addresses are configured, spec is 256 items.
ARP speed-limit for source-IP configuration:

IP-address suppress-rate(pps)(rate=0 means function disabled)
-------------------------------------------------------------------------------
9.9.9.2 10
Others 5
-------------------------------------------------------------------------------
1 specified IP addresses are configured, spec is 256 items.
ARP miss speed-limit for source-IP configuration:

-------------------------------------------------------------------------------
10.10.10.2 40
Others 20
-------------------------------------------------------------------------------
# Run the display arp packet statistics command to check statistics on ARP-based packets.
[Huawei] display arp packet statistics
ARP Pkt Received: sum 8678904
ARP Learnt Count: sum 37
ARP Pkt Discard For Limit: sum 146
ARP Pkt Discard For SpeedLimit: sum 40529
ARP Pkt Discard For Proxy Suppress: sum 0
ARP Pkt Discard For Other: sum 8367601
In the preceding command output, the number of ARP packets discarded by Router is
displayed, indicating that the ARP security functions have taken effect.
Configuration File
#
vlan batch 10 20 30
#
arp-miss speed-limit source-ip maximum 20
#
arp learning strict
#
arp-miss speed-limit source-ip 10.10.10.2 maximum 40
arp speed-limit source-ip 9.9.9.2 maximum 10
arp speed-limit source-mac 0001-0001-0001 maximum 10
arp anti-attack entry-check fixed-mac enable
#
interface Vlanif10
ip address 8.8.8.4 255.255.255.0
#
interface Vlanif20
ip address 9.9.9.4 255.255.255.0
#
interface Vlanif30
ip address 10.10.10.3 255.255.255.0
#
arp-limit vlan 10 maximum 20
#
#
#
return
14.9.4 Example for Configuring Defense Against ARP MITM

Attacks
As shown in Figure 14-9-4, RouterA connects to the DHCP server using Eth2/0/4, connects to
DHCP clients UserA and UserB using Eth2/0/1 and Eth2/0/2, and connects to UserC configured with
a static IP address using Eth2/0/3. Eth2/0/1, Eth2/0/2, Eth2/0/3, and Eth2/0/4 on RouterA all belong
to VLAN
10. The administrator wants to prevent ARP MITM attacks and theft on authorized user
information, and learn the frequency and range of ARP MITM attacks.
Figure 14-9-4 Networking diagram for defending against ARP MITM attacks

1. Enable DAI so that RouterA compares the source IP address, source MAC address, interface
number, and VLAN ID of the ARP packet with DHCP snooping binding entries. This
prevents ARP MITM attacks.
2. Enable packet discarding alarm function upon DAI so that RouterA collects statistics on ARP
packets matching no DHCP snooping binding entry and generates alarms when the number of
discarded ARP packets exceeds the alarm threshold. The administrator learns the frequency
and range of the current ARP MITM attacks based on the alarms and the number of discarded
ARP packets.
3. Enable DHCP snooping and configure a static DHCP snooping binding table to make DAI
take effect.
Procedure
# Create VLAN 10, and add Eth2/0/1, Eth2/0/2, Eth2/0/3, and Eth2/0/4 to VLAN 10.
[RouterA] vlan batch 10
[RouterA-Ethernet2/0/1] port link-type access
[RouterA-Ethernet2/0/1] port default vlan 10
2. Enable DAI and the packet discarding alarm function.
# Enable DAI and packet discarding alarm function on Eth2/0/1, Eth2/0/2, and
Eth2/0/3. Eth2/0/1 is used as an example. Configurations of other interfaces are similar
to the configuration of Eth2/0/1, and are not mentioned here.
[RouterA-Ethernet2/0/1] arp anti-attack check user-bind enable
[RouterA-Ethernet2/0/1] arp anti-attack check user-bind alarm enable
3. Configure DHCP snooping.
# Enable DHCP snooping globally.
[RouterA] dhcp enable

[RouterA] dhcp snooping enable
# Enable DHCP snooping in VLAN 10.
[RouterA] vlan 10
[RouterA-vlan10] dhcp snooping enable
# Configure Eth2/0/4 as a trusted interface.

[RouterA-Ethernet2/0/4] dhcp snooping trusted
# Configure a static DHCP snooping binding table.
[RouterA] user-bind static ip-address 10.0.0.2 mac-address 0001-0001-0001 interface

ethernet 2/0/3 vlan 10
# Run the display arp anti-attack check user-bind interface command to check the DAI
configuration on each interface. Eth2/0/1 is used as an example.
[RouterA] display arp anti-attack check user-bind interface ethernet 2/0/1

arp anti-attack check user-bind enable
arp anti-attack check user-bind alarm enable
ARP packet drop count = 966
In the preceding command output, the number of discarded ARP packets on Eth2/0/1
is displayed, indicating that the defense against ARP MITM attacks has taken effect.
When you run the display arp anti-attack check user-bind interface command for
multiple times on each interface, the administrator can learn the frequency and range of ARP
MITM attacks based on the value of ARP packet drop count.
Configuration File
Configuration file of RouterA
#
sysname RouterA
#
vlan batch 10
#
dhcp enable
#
user-bind static ip-address 10.0.0.2 mac-address 0001-0001-0001 interface Ethernet2/0/3 vlan 10
#
vlan 10
#
#
#
#
dhcp snooping trusted
#
return
14.9.5 Example for Configuring ARP Security
Functions（S3700）
As shown in Figure 14-9-5, the Switch is connected to a server through Ethernet 0/0/3 and
is connected to four users in VLAN 10 and VLAN 20 through Ethernet 0/0/1 and Ethernet 0/0/2.
There are the following ARP attacks on the network:
 The server may send several packets with an unreachable destination IP address, and the
number of these packets is larger than the number of packets from common users.
 After virus attacks occur on User 1, a large number of ARP packets are sent. Among these
packets, the source IP address of certain ARP packets changes on the local network segment
and the source IP address of certain ARP packets is the same as the IP address of the gateway.
 User 3 constructs a large number of ARP packets with a fixed IP address to attack the network.
 User 4 constructs a large number of ARP packets with an unreachable destination IP address
to attack the network.
It is required that ARP security functions be configured on the Switch to prevent the preceding
attacks. The suppression rate of ARP Miss packets set on the server should be greater than the
suppression rate of other users.
Figure 14-9-5 Networking diagram for configuring ARP security functions
1. Enable strict ARP learning.
2. Enable interface-based ARP entry restriction.
3. Enable the ARP anti-spoofing function.

4. Enable the ARP anti-attack function for preventing ARP packets with the bogus
gateway address.
5. Configure the rate suppression function for ARP packets.
6. Configure the rate suppression function for ARP Miss packets.
7. Enable log and alarm functions for potential attacks.
Data Preparation
To complete the configuration, you need the following data:
 Number of limited ARP entries on the interface being 20
 Anti-spoofing mode used to prevent attacks that is initiated by User 1 being fixed-mac
 IP address of the server being 2.2.2.2/24
 IP address of User 4 that sends a large number of ARP packets being 2.2.4.2/24
 Maximum suppression rate for ARP packets of User 4 being 10 pps and maximum
suppression rate for ARP packets of other users being 15 pps
 Maximum suppression rate for ARP Miss packets of common users being 20 pps and
maximum suppression rate for ARP Miss packets on the server being 50 pps
 Interval for writing an ARP log and sending an alarm being 300 seconds
Procedure
1. Enable strict ARP learning.
<Quidway> system-view
[Quidway] arp learning strict
2. Configure interface-based ARP entry restriction.
# The number of limited ARP entries on each interface is 20. The following lists the
configuration of Ethernet 0/0/1, and the configurations of other interfaces are the same as
the
configuration of Ethernet 0/0/1.
[Quidway] interface ethernet 0/0/1

[Quidway-Ethernet0/0/1] arp-limit vlan 10 maximum 20
[Quidway-Ethernet0/0/1] quit
3. Enable the ARP anti-spoofing function.
# Set the ARP anti-spoofing mode to fixed-mac to prevent ARP spoofing attacks initiated by
User 1.
[Quidway] arp anti-attack entry-check fixed-mac enable
4. Enable the ARP anti-attack function for preventing ARP packets with the bogus
gateway address.
# Enable the ARP anti-attack function for preventing ARP packets with the bogus
gateway address to prevent User 1 from sending ARP packets with the bogus gateway
address.
[Quidway] arp anti-attack gateway-duplicate enable
5. Configure the rate suppression function for ARP packets.
# Set the suppression rate for ARP packets sent by User 4 to 10 pps. To prevent all users from
sending a large number of ARP packets incorrectly, set the suppression rate for ARP packets
of the system to 15 pps.
[Quidway] arp speed-limit source-ip maximum 15

[Quidway] arp speed-limit source-ip 2.2.2.4 maximum 10
6. Configure the rate suppression function for ARP Miss packets.
# Set the suppression rate for ARP Miss packets of the system to 20 pps to prevent users
from sending a large number of IP packets with an unreachable destination IP address.
[Quidway] arp-miss speed-limit source-ip maximum 20
# Set the suppression rate for ARP Miss packets on the server to 50 pps to prevent the server
from sending a large number of IP packets with an unreachable destination IP address, and to
prevent communication on the network when the rate for the server to send IP packets with
an
unreachable destination IP address is not as
required.
[Quidway] arp-miss speed-limit source-ip 2.2.2.2 maximum 50
7. Enable log and alarm functions for potential attacks.
[Quidway] arp anti-attack log-trap-timer 300
After the configuration, run the display arp learning strict command. You can see
information about strict ARP learning.
<Quidway> display arp learning strict

The global configuration:arp learning strict
interface LearningStrictState
------------------------------------------------------------
------------------------------------------------------------
Total:0
force-enable:0
force-disable:0
You can use the display arp-limit command to check the maximum number of ARP entries
learned by the interface.
<Quidway> display arp-limit interface ethernet 0/0/1

interface LimitNum VlanID LearnedNum(Mainboard)
---------------------------------------------------------------------------
Ethernet0/0/1 20 10 0
---------------------------------------------------------------------------
Total:1
You can use the display arp anti-attack configuration all command to check the
configuration of ARP anti-attack.
<Quidway> display arp anti-attack configuration all

ARP anti-attack entry-check mode: fixed-MAC
ARP gateway-duplicate anti-attack function: enabled
ARP anti-attack log-trap-timer: 30seconds

(The log and trap timer of speed-limit, default is 0 and means disabled.)
ARP rate-limit configuration:

-------------------------------------------------------------------------------
Globle configuration:
Vlan configuration:
-------------------------------------------------------------------------------
ARP miss rate-limit configuration:

-------------------------------------------------------------------------------
Globle configuration:
Vlan configuration:
-------------------------------------------------------------------------------
ARP speed-limit for source-IP configuration:

------------------------------------------------------------------------
2.2.4.2 10
Others 15
------------------------------------------------------------------------
ARP miss speed-limit for source-IP configuration:
------------------------------------------------------------------------
2.2.2.2 50
Others 20
------------------------------------------------------------------------
You can use the display arp packet statistics command to view the number of discarded
ARP packets and the number of learned ARP entries. In addition, you can also use the display
arp anti-attack gateway-duplicate item command to view information about attacks from
the
packets with the forged gateway address on the current network.
<Quidway> display arp packet statistics

ARP Pkt Received: sum 167
ARP Learnt Count: sum 8
ARP Pkt Discard For Limit: sum 5
ARP Pkt Discard For SpeedLimit: sum 0
ARP Pkt Discard For Other: sum 3
<Quidway> display arp anti-attack gateway-duplicate item
interface IP address MAC address VLANID aging time
-------------------------------------------------------------------------------
GigabitEthernet0/0/1 2.1.1.1 0000-0000-0002 2 153
GigabitEthernet0/0/2 2.1.1.2 0000-0000-0004 2 179
-------------------------------------------------------------------------------
There are 2 records in gateway conflict table
Configuration Files
#
sysname Quidway
#
vlan batch 10 20 30
#
arp speed-limit source-ip maximum 15
arp-miss speed-limit source-ip maximum 20
arp learning strict
arp anti-attack log-trap-timer 300
#
arp anti-attack entry-check fixed-mac
enable arp anti-attack gateway-duplicate
enable
arp-miss speed-limit source-ip 2.2.2.2 maximum 50
arp speed-limit source-ip 2.2.4.2 maximum 10
#
interface Ethernet0/0/1 port
hybrid pvid vlan 10 port
hybrid tagged vlan 10
#
interface Ethernet0/0/2 port
hybrid pvid vlan 20 port
hybrid tagged vlan 20
#
#
return
14.9.6 Example for Configuring ARP Anti-Attack to Prevent Man-in-the-Middle Attacks

（S3700）
As shown in Figure 14-9-6, two users are connected to the Switch through Ethernet 0/0/1 and Ethernet
0/0/2 respectively. Assume that the user connected to Ethernet 0/0/2 is an attacker. To prevent the
man-in-the-middle attacks, you can configure the IP source guard function. After the IP source
guard function is configured on the Switch, the Switch checks the IP packets according to the
binding table. Only the IP packets that match the content of the binding table can be forwarded; the
other IP packets are discarded. In addition, you can enable the alarm function for discarded packets.
Figure 14-9-6 Networking diagram for prevent man-in-the-middle attacks
1. Enable the IP source guard function.
2. Configure the check items for ARP packets.
3. Configure a static binding table.
4. Enable the alarm function for discarded packets.
Data Preparation
To complete the configuration, you need the following data:
 Interfaces enabled with IP source guard: Ethernet 0/0/1 and Ethernet 0/0/2
 Check items: IP address + MAC address + VLAN
 Alarm threshold of the number of discarded ARP packets: 80
 IP address of the client configured in the static binding table: 10.0.0.1/2; MAC address: 1-1-
1; VLAN ID: 10
Procedure
1. Configure the IP source guard function.
# Enable the IP source guard function on Ethernet 0/0/1 connected to the client.

[Quidway-Ethernet0/0/1] arp anti-attack check user-bind enable
[Quidway-Ethernet0/0/1] arp anti-attack check user-bind check-item ip-address
mac-address vlan
# Enable the IP source guard function on Ethernet 0/0/2 connected to the attacker.

[Quidway-Ethernet0/0/2] arp anti-attack check user-bind enable
[Quidway-Ethernet0/0/2] arp anti-attack check user-bind check-item ip-address
mac-address vlan
2. Configure the alarm function for discarded packets.
# Set the alarm threshold of the ARP packets discarded because they do not match the
binding table on Ethernet 0/0/1 connected to the client.
[Quidway-Ethernet0/0/1] arp anti-attack check user-bind alarm enable

[Quidway-Ethernet0/0/1] arp anti-attack check user-bind alarm threshold 80
# Set the alarm threshold of the ARP packets discarded because they do not match the
binding table on Ethernet 0/0/2 connected to the attacker.
[Quidway-Ethernet0/0/2] arp anti-attack check user-bind alarm enable

[Quidway-Ethernet0/0/2] arp anti-attack check user-bind alarm threshold 80
3. Configure the check items of the static binding table.
# Configure Client in the static binding table.
[Quidway] user-bind static ip-address 10.0.0.1 mac-address 0001-0001-0001 interface

ethernet 0/0/1 vlan 10
Run the display arp anti-attack configuration check user-bind interface command. You
can view the configuration of the IP source guard function on the interface.
<Quidway> display arp anti-attack configuration check user-bind interface ethernet 0/0/1
arp anti-attack check user-bind alarm threshold 80
arp anti-attack check user-bind check-item ip-address mac-address vlan
<Quidway> display arp anti-attack configuration check user-bind interface ethernet 0/0/2
arp anti-attack check user-bind check-item ip-address mac-address vlan
The preceding information indicates that Ethernet 0/0/1 does not discard ARP packets, whereas
Ethernet 0/0/2 has discarded ARP packets. The anti-attack function takes effect.
Configuration Files
#
vlan batch 10
#
user-bind static ip-address 10.0.0.1 mac-address 0001-0001-0001 interface Ethernet 0/0/1 vlan 10
#
arp anti-attack check user-bind check-item ip-address mac-address
vlan arp anti-attack check user-bind alarm enable
#
arp anti-attack check user-bind check-item ip-address mac-address
vlan arp anti-attack check user-bind alarm enable
#
return
14.9.7 Example for Configuring Priority Mapping
As shown in Figure 14-9-7, voice, video, and data terminals on the enterprise's LAN connect to
Eth2/0/0 and Eth2/0/1 of RouterA through SwitchA and SwitchB. These terminals connect to the
WAN through GE3/0/0 of RouterA.
Packets of different services are identified by 802.1p priorities on the LAN. RouterA identifies and
processes service packets on the LAN side based on 802.1p priorities in packets. When packets
reach the WAN- side network from GE3/0/0, RouterA needs to provide differentiated services
based on DSCP priorities in the packets. A priority mapping table is configured so that RouterA can
re-mark
802.1p priorities with DSCP priorities.
Figure 14-9-7 Networking diagram of priority mapping configurations
1. Create VLANs and VLANIF interfaces on RouterA and configure interfaces so that
enterprise users can access the WAN-side network through RouterA.
2. Configure interfaces to trust 802.1p priorities in packets on RouterA.
3. Configure a priority mapping table on RouterA and modify the mappings between
802.1p priorities and DSCP priorities so that RouterA can re-mark 802.1p priorities with
DSCP priorities.
Procedure
1. Create VLANs and configure interfaces.
# Create VLAN 20 and VLAN 30 on RouterA.
# Configure Eth2/0/0 and Eth2/0/1 as trunk interfaces, and add Eth2/0/0 to VLAN 20 and
Eth2/0/1 to VLAN 30.

NOTE:
Configure the interface of SwitchA connected to RouterA as a trunk interface and add it to
VLAN 20.
Configure the interface of SwitchB connected to RouterA as a trunk interface and add it to
VLAN 30.
# Create VLANIF 20 and VLANIF 30, assign IP address 192.168.2.1/24 to VLANIF 20, and
assign IP address 192.168.3.1/24 to VLANIF 30.
[RouterA] interface vlanif 20

[RouterA-Vlanif20] ip address 192.168.2.1 24
[RouterA-Vlanif20] quit
# Configure IP address 192.168.4.1/24 for GE3/0/0.

NOTE:
Configure RouterB and ensure that there are reachable routes between RouterB and RouterA.
2. Configure priority mapping.
# Configure Eth2/0/0 and Eth2/0/1 to trust 802.1p priorities in packets.

[RouterA-Ethernet2/0/0] trust 8021p override
[RouterA-Ethernet2/0/1] trust 8021p override
# Configure priority mapping.
[RouterA] qos map-table dot1p-dscp

[RouterA-maptbl-dot1p-dscp] input 2 output 14
# View priority mapping information on RouterA.

<RouterA> display qos map-table dot1p-dscp
Input Dot1p
-------------------
0
1
2
3
4
5
6
7
[RouterA-Ethernet2/0/0] display this
#
trust 8021p override
#
return
[RouterA-Ethernet2/0/1] display this
#
#
return
Configuration file
#
sysname RouterA
#
vlan batch 20 30
#
qos map-table dot1p-dscp
input 2 output 14
input 6 output 46
#
interface Vlanif20
ip address 192.168.2.1 255.255.255.0
#
interface Vlanif30
ip address 192.168.3.1 255.255.255.0
#
#
#
ip address 192.168.4.1 255.255.255.0
#
return
14.9.8 Example for Configuring Traffic Policing
As shown in Figure 14-9-8, voice, video, and data services on the LAN side of the enterprise belong
to VLAN 10, VLAN 20, and VLAN 30 respectively. The services are transmitted to Eth2/0/0 on
RouterA through the switch, and are transmitted to the WAN through GE3/0/0 on RouterA.
Flow-based traffic policing needs to be performed for different service packets on RouterA so that
the service traffic is limited within a proper range and bandwidth is ensured. Interface-based traffic
policing needs to be performed for all incoming traffic on Eth2/0/0 so that the total traffic of a single
enterprise user is limited within a proper range.
Figure 14-9-8 Networking diagram of traffic policing
enterprise users can access the WAN through RouterA.
2. Configure traffic classifiers on RouterA to classify packets based on their VLAN IDs.
3. Configure traffic behaviors on RouterA to perform traffic policing for different service
flows from the enterprise.
4. Configure a traffic policy on RouterA, associate the traffic behaviors with traffic classifiers
in the traffic policy, and apply the traffic policy to the inbound direction of the interface on
RouterA connected to the switch.
5. Configure interface-based traffic policing to the inbound direction of the interface on RouterA
connected to the switch to limit the rate of all the packets.
Procedure
# Create VLAN 10, VLAN 20, and VLAN 30 on RouterA.
[RouterA] vlan batch 10 20 30
# Configure Eth2/0/0 as a trunk interface and allow packets from VLAN10, VLAN20, and
VLAN30 to pass through.

[RouterA-Ethernet2/0/0] port trunk allow-pass vlan 10 20 30
NOTE:
Configure the interface on the switch connected to RouterA as a trunk interface and
allow packets from VLAN 10, VLAN 20, and VLAN 30 to pass through.
# Create VLANIF 10, VLANIF 20, and VLANIF 30, and assign IP addresses 192.168.1.1/24,
192.168.2.1/24, and 192.168.3.1/24 to VLANIF 10, VLANIF 20, and VLANIF 30 respectively.

# Set the IP address of GE3/0/0 to 192.168.4.1/24.

NOTE:
# Configure traffic classifiers c1, c2, and c3 on RouterA to classify different service flows
from the enterprise based on VLAN IDs.
[RouterA] traffic classifier c1

[RouterA-classifier-c1] if-match vlan-id 10
[RouterA-classifier-c1] quit

# Create traffic behaviors b1, b2, and b3 on RouterA to perform traffic policing for different
service flows from the enterprise.
[RouterA] traffic behavior b1

[RouterA-behavior-b1] car cir 256 cbs 48128 pbs 80128
[RouterA-behavior-b1] statistic enable
[RouterA-behavior-b1] quit
4. Configure a traffic policy and apply the traffic policy to an interface.
# Create a traffic policy p1 on RouterA, associate the traffic behaviors with traffic classifiers
in the traffic policy, and apply the traffic policy to the inbound direction of Eth2/0/0.
[RouterA] traffic policy p1

[RouterA-trafficpolicy-p1] classifier c1 behavior b1
[RouterA-trafficpolicy-p1] quit
[RouterA-Ethernet2/0/0] traffic-policy p1 inbound
5. Configure interface-based traffic policing.
# Configure interface-based traffic policing for the inbound direction of Eth2/0/0 on RouterA
to limit traffic of a single enterprise user within a proper range.
[RouterA-Ethernet2/0/0] qos car inbound cir 10000

# View the traffic classifier configuration.
[RouterA] display traffic classifier user-defined

User Defined Classifier
Information: Classifier: c2
Operator: OR
Rule(s) :
if-match vlan-id 20
Classifier: c3
Operator: OR
Rule(s) :
if-match vlan-id 30
Classifier: c1
Operator: OR
Rule(s) :
if-match vlan-id 10

Policy: p1
Classifier: c1
Operator: OR
Behavior: b1
Committed Access Rate:
CIR 256 (Kbps), PIR 0 (Kbps), CBS 48128 (byte), PBS 80128 (byte)
Color Mode: color Blind
Conform Action: pass
Yellow Action: pass
Exceed Action: discard
statistic: enable
Classifier: c2
Operator: OR
Behavior: b2
Yellow Action: pass
statistic: enable
Classifier: c3
Operator: OR
Behavior: b3
Yellow Action: pass
statistic: enable
# View the traffic policy configuration on Eth2/0/0.
[RouterA] display traffic policy statistics interface ethernet 2/0/0 inbound
Interface: Ethernet2/0/0
Traffic policy inbound: p1
Rule number: 3
Current status: OK!
Item Sum(Packets/Bytes) Rate(pps/bps)
-------------------------------------------------------------------------------
Matched 0/ 0/
- -
+--Passed 0/ 0/
- -
+--Dropped 0/ 0/
- -
+--Filter 0/ 0/
- -
+--CAR 0/ 0/
- -
+--Queue Matched 0/ 0/
- -
+--Enqueued 0/ 0/
- -
+--Discarded 0/ 0/
- -
+--Car 0/ 0/
- -
+--Green packets 0/ 0/
- -
+--Yellow packets 0/ 0/
- -
+--Red packets 0/ 0/
- -
Configuration Files
#
sysname RouterA
#
vlan batch 10 20 30
#
traffic classifier c1 operator or
if-match vlan-id 10
if-match vlan-id 20
if-match vlan-id 30
#
traffic behavior b1
car cir 256 cbs 48128 pbs 80128 green pass yellow pass red discard
statistic enable
traffic behavior b2
statistic enable
traffic behavior b3
statistic enable
#
traffic policy p1
classifier c1 behavior b1
#
interface Vlanif10
ip address 192.168.1.1 255.255.255.0
#
interface Vlanif20
ip address 192.168.2.1 255.255.255.0
#
interface Vlanif30
ip address 192.168.3.1 255.255.255.0
#
port trunk allow-pass vlan 10 20 30
qos car inbound cir 10000
traffic-policy p1 inbound
#
ip address 192.168.4.1 255.255.255.0
#
return
14.9.9 Example for Configuring Traffic

Shaping
As shown in Figure 14-9-9, the LAN interface of an enterprise connects to Eth2/0/0 of

RouterA through the switch. RouterA connects to the WAN through GE3/0/0. The voice, video,
and data services are deployed on the LAN.
Packets of different services are identified by 802.1p priorities on the LAN. RouterA sends service
packets to queues based on 802.1p priorities. When packets reach the WAN through GE3/0/0,
jitter may occur. The following conditions must be met to prevent jitter and ensure bandwidth for
services:
 The CIR on GE3/0/0 is 8000 kbit/s.
 The CIR and CBS for the voice service are 256 kbit/s and 6400 bytes respectively.
 The CIR and CBS for the video service are 4000 kbit/s and 100000 bytes respectively.
 The CIR and CBS for the data service are 2000 kbit/s and 50000 bytes respectively.
Figure 14-9-9 Networking of traffic shaping

enterprise users can access the WAN through RouterA.
2. Configure interfaces to trust 802.1p priorities in packets on RouterA.
3. Configure interface-based traffic shaping on RouterA to limit the interface bandwidth.
4. Configure queue-based traffic shaping on RouterA to limit the bandwidth of voice, video,
and data services.
Procedure
# Create VLAN 10 on RouterA.
<Router> system-view
[Router] sysname RouterA
[RouterA] vlan 10
# Configure Eth2/0/0 as a trunk interface and add it to VLAN 10.

NOTE:
Configure the interface on the switch connected to RouterA as a trunk interface and add it to
VLAN 10.
# Create VLANIF 10 and assign IP address 192.168.1.1/24 to VLANIF 10.

# Set the IP address of GE3/0/0 to 192.168.4.1/24.

NOTE:
2. Configure the packet priority trusted by the inbound interface of packets.

# Configure Eth2/0/0 to trust 802.1p priorities of packets.

[RouterA-Ethernet2/0/0] trust 8021p
3. Configure interface-based traffic shaping.
# Configure traffic shaping on GE3/0/0 of RouterA and set the CIR value to 8000 kbit/s.

[RouterA-GigabitEthernet3/0/0] qos gts cir 8000
4. Configure queue-based traffic shaping.
# Create a queue profile qp1 on RouterA, set the scheduling mode to WFQ for queues 0 to 5
and to PQ for queue 6 and queue 7. Set CIR values of queue 6, queue 5, and queue 2 to 256
kbit/s, 4000 kbit/s, and 2000 kbit/s. Set CBS values of queue 6, queue 5, and queue 2 to 6400
bytes, 100000 bytes, and 50000 bytes.
[RouterA] qos queue-profile qp1

[RouterA-qos-queue-profile-qp1] schedule pq 6 to 7 wfq 0 to 5
[RouterA-qos-queue-profile-qp1] queue 6 gts cir 256 cbs 6400
[RouterA-qos-queue-profile-qp1] quit
# Apply the queue profile qp1 on GE3/0/0 of RouterA.

[RouterA-GigabitEthernet3/0/0] qos queue-profile qp1
# View the configuration of GE3/0/0 on RouterA.

#
ip address 192.168.4.1 255.255.255.0
qos queue-profile qp1
qos gts cir 8000 cbs 200000
#
return
# View the queue profile configuration.
[RouterA] display qos queue-profile qp1
Queue-profile: qp1
Queue Schedule Weight Length(Bytes/Packets) GTS(CIR/CBS)
-----------------------------------------------------------------
0 WFQ 10 -/- -/-
1 WFQ 10 -/- -/-
2 WFQ 10 -/- 2000/50000
3 WFQ 10 -/- -/-
4 WFQ 10 -/- -/-
5 WFQ 10 -/- 4000/100000
6 PQ - -/- 256/6400
7 PQ - -/- -/-
Configuration Files
#
sysname RouterA
#
vlan batch 10
#
queue 2 gts cir 2000 cbs 50000
schedule wfq 0 to 5 pq 6 to 7
#
interface Vlanif10
ip address 192.168.1.1 255.255.255.0
#
trust 8021p
#
ip address 192.168.4.1 255.255.255.0
qos gts cir 8000 cbs 200000
#
return
14.9.10 Example for Configuring Adaptive Traffic Shaping
As shown in Figure 14-9-10, the enterprise headquarters connects to the Internet through GE1/0/0 on
RouterA and connects to branch RouterB thorough the 3G network.
The branch uses 3G access and link bandwidth is unstable. It is required that the rate of packets
sent from the enterprise headquarters be adjusted based on 3G link bandwidth to reduce jitter on
the 3G network.
Priorities of data, video, and voice packets sent from the enterprise headquarters to the branch are
af11, af21, and ef respectively. Voice packets need to be processed first and bandwidth of video and
data packets needs to be ensured.
Figure 14-9-10 Networking diagram of adaptive traffic shaping
Interface-based adaptive traffic shaping is used to dynamically adjust the rate of packets sent from the
enterprise headquarters, and flow-based congestion management is used to process voice, video,
and data packets in different manners. The configuration roadmap is as follows:
1. Configure an NQA test instance of jitter on RouterA and RouterB to detect the status of the
link between the enterprise headquarters and branch.
2. Apply an an adaptive traffic profile on GE1/0/0 of RouterA. When the packet loss ratio
detected by the NQA test instance is larger than 30% for three consecutive times, the rate at
which packets are sent on GE1/0/0 is reduced.
3. Configure traffic classifiers on RouterA to classify data, video, and voice packets.
4. Configure traffic behaviors on RouterA in which different congestion management actions

are taken for data, video, and voice packets.
5. Configure a traffic policy on RouterA, bind traffic classifiers and traffic behaviors to the
traffic policy, and apply the traffic policy to GE1/0/0 so that data, video, and voice packets
are processed in different manners.
Procedure
1. Configure an NQA test instance.
# Configure the IP address and number of the interface used for monitoring the UDP service
on the NQA server.
[RouterB] nqa-server udpecho 192.168.2.2 9000
# Enable the NQA client and create an NQA test instance of jitter.
[RouterA] nqa test-instance admin jitter1
[RouterA-nqa-admin-jitter1] test-type jitter
[RouterA-nqa-admin-jitter1] destination-address ipv4 192.168.2.2
[RouterA-nqa-admin-jitter1] destination-port 9000
[RouterA-nqa-admin-jitter1] start now
[RouterA-nqa-admin-jitter1] quit
2. Configure an adaptive traffic profile on RouterA.
[RouterA] qos adaptation-profile gts1

[RouterA-qos-adaptation-profile-gts1] rate-range low-threshold 128 high-threshold 512
[RouterA-qos-adaptation-profile-gts1] rate-adjust step 32
[RouterA-qos-adaptation-profile-gts1] rate-adjust loss low-threshold 20 high-threshold 30
[RouterA-qos-adaptation-profile-gts1] track nqa admin jitter1
[RouterA-qos-adaptation-profile-gts1] quit
3. Apply the adaptive traffic profile on GE1/0/0 of RouterA.

[RouterA-GigabitEthernet1/0/0] qos gts adaptation-profile gts1
4. Configure traffic classifiers on RouterA to differentiate data, video, and voice services.
[RouterA] traffic classifier data

[RouterA-classifier-data] if-match dscp af11
[RouterA-classifier-data] quit
[RouterA] traffic classifier video
[RouterA-classifier-video] if-match dscp af21
[RouterA-classifier-video] quit
[RouterA] traffic classifier voice
[RouterA-classifier-voice] if-match dscp ef
[RouterA-classifier-voice] quit
5. Configure traffic behaviors on RouterA, and configure RouterA to send packets matching
traffic classifiers to specified queues and allocate bandwidth to the queues.
[RouterA] traffic behavior data

[RouterA-behavior-data] queue af bandwidth pct 30
[RouterA-behavior-data] quit
[RouterA] traffic behavior video
[RouterA-behavior-video] queue af bandwidth pct 60
[RouterA-behavior-video] quit
[RouterA] traffic behavior voice
[RouterA-behavior-voice] queue llq bandwidth pct 5
[RouterA-behavior-voice] quit
6. Configure a traffic policy on RouterA, and bind traffic classifiers and traffic behaviors to
the traffic policy.

[RouterA-trafficpolicy-p1] classifier voice behavior voice
[RouterA-trafficpolicy-p1] classifier video behavior video
[RouterA-trafficpolicy-p1] classifier data behavior data
7. Apply the traffic policy to GE1/0/0 on RouterA.

[RouterA-GigabitEthernet1/0/0] traffic-policy p1 outbound
# View the record of the adaptive traffic profile gts1 on GE1/0/0 of RouterA.
[RouterA] display qos adaptation-profile gts1 interface gigabitethernet 1/0/0

applied-record
Interface: GigabitEthernet1/0/0
-----------------------------------------------------------------
QoS gts adaptation-profile: gts1
-----------------------------------------------------------------
NQA admin Name: admin
NQA test Name: jitter1

1210
Current Rate: 256(Kbps)
Last packet loss: 25(%)
The latest traffic shaping rate fails to be updated because the packet loss ratio is with in
the allowed range.
Configuration Files
#
sysname RouterA
#
qos adaptation-profile gts1
rate-range low-threshold 128 high-threshold 512
track nqa admin jitter1
rate-adjust loss low-threshold 20 high-threshold
30 rate-adjust step 32
#
traffic classifier video operator or
if-match dscp af21
traffic classifier data operator or
if-match dscp af11
traffic classifier voice operator or
if-match dscp ef
#
traffic behavior video
queue af bandwidth pct 60
traffic behavior data
queue af bandwidth pct 30
traffic behavior voice
queue llq bandwidth pct 5
#
traffic policy p1
classifier voice behavior voice
classifier video behavior video
classifier data behavior data
#
ip address 192.168.1.2 255.255.255.0
qos gts adaptation-profile gts1
traffic-policy p1 outbound
#
nqa test-instance admin jitter1
test-type jitter
destination-port 9000
#
return
#
sysname RouterB
#
nqa-server udpecho 192.168.2.2 9000
#
return
14.9.11 Example for Configuring Congestion Management and Congestion Avoidance
As shown in Figure 14-9-11, voice, video, and data services on the LAN side of the enterprise
are connected to Eth2/0/0 and Eth2/0/1 of RouterA through SwitchA and SwitchB, and are sent
to the WAN-side network through GE3/0/0 of RouterA.
Packets are marked with different DSCP priorities by SwitchA and SwitchB, and the priorities of
voice, video, and data services are ef, af43, and af32 and af31. RouterA sends packets to queues based
on DSCP priorities. The rates of Eth2/0/0 and Eth2/0/1 on RouterA are greater than those of GE3/0/0,
congestion may occur on GE3/0/0 in the outbound direction. It is required that voice packets be sent
first. Ensure that video and data packets with smaller priority obtain less bandwidth and have less drop
probability.
Figure 14-9-11 Networking diagram of congestion management and congestion
avoidance configurations
Congestion management and congestion avoidance are used to lessen congestion. The
2. On the Router, configure an interface to trust DSCP priorities so that packets with
different priorities enter different queues.
3. Create a drop profile, and set WRED parameters based on DSCP priorities so that packets
with smaller priorities have greater drop probability.
4. Create a queue profile in which PQ scheduling is used for voice packets and WFQ scheduling
is used for video and data packets so that voice packets are sent preferentially and video and
data packets are scheduled based on priorities.
5. Bind the drop profile to the queue profile, and apply the queue profile to the interface
on RouterA connected to the WAN to implement congestion avoidance and congestion
management.
Procedure
# Configure Eth2/0/0 and Eth2/0/1 to trust DSCP priorities, configure them as trunk
interfaces, and add Eth2/0/0 to VLAN 20 and Eth2/0/1 to VLAN 30.

[RouterA-Ethernet2/0/0] trust dscp
[RouterA-Ethernet2/0/1] trust dscp
NOTE:
Configure the interface of SwitchA connected to RouterA as a trunk interface and add it to
VLAN 20.
Configure the interface of SwitchB connected to RouterA as a trunk interface and add it to
VLAN 30.
# Create VLANIF 20 and VLANIF 30, assign IP address 192.168.2.1/24 to VLANIF 20, and
assign IP address 192.168.3.1/24 to VLANIF 30.

# Assign IP address 192.168.4.1/24 to GE3/0/0.

NOTE:
Configure RouterB to ensure that there is a reachable route between RouterB and RouterA.
2. Create drop profiles.
# Create drop profiles data and video on RouterA.
[RouterA] drop-profile data

[RouterA-drop-profile-data] wred dscp
[RouterA-drop-profile-data] dscp 28 low-limit 50 high-limit 70 discard-percentage 30
[RouterA-drop-profile-data] dscp 26 low-limit 40 high-limit 60 discard-percentage 40
[RouterA-drop-profile-data] quit
[RouterA] drop-profile video
[RouterA-drop-profile-video] wred dscp
[RouterA-drop-profile-video] dscp 38 low-limit 60 high-limit 80 discard-percentage 20
[RouterA-drop-profile-video] quit
3. Create a queue profile.
# Create a queue profile queue-profile1 on RouterA and set the scheduling mode for
each queue.
[RouterA] qos queue-profile queue-profile1

[RouterA-qos-queue-profile-queue-profile1] schedule pq 5 wfq 3 to 4
4. Apply the queue profile.
# Bind the drop profile to the queue profile.
[RouterA-qos-queue-profile-queue-profile1] queue 4 drop-profile video

[RouterA-qos-queue-profile-queue-profile1] queue 3 drop-profile data
[RouterA-qos-queue-profile-queue-profile1] quit
# Apply the queue profile to GE3/0/0 of RouterA.

[RouterA-GigabitEthernet3/0/0] qos queue-profile queue-profile1

#
ip address 192.168.4.1 255.255.255.0
qos queue-profile queue-profile1
#
return
# View the drop profile configuration.
[RouterA] display qos queue-profile queue-profile1
Queue-profile: queue-profile1
Queue Schedule Weight Length(Bytes/Packets) GTS(CIR/CBS)
-----------------------------------------------------------------
3 WFQ
4 WFQ

1210
5 PQ - -/- -/-
# View the drop profile bound to the queue profile.
[RouterA] qos queue-profile queue-profile1

[RouterA-qos-queue-profile-queue-profile1] display this
#
queue 3 drop-profile data
queue 4 drop-profile video
schedule wfq 3 to 4 pq 5
#
return
# View the configuration of drop profiles.
[RouterA-qos-queue-profile-queue-profile1] quit
[RouterA] display drop-profile video
Drop-profile[2]: video
DSCP Low-limit High-limit Discard-percentage
-----------------------------------------------------------------
0(default)
1
2
3
4
5
6
7
8(cs1) 30 100 10
9
10(af11)
11
12(af12)
13
14(af13)
15
16(cs2)
17
18(af21)
19
20(af22)
21
22(af23)
23
24(cs3)
25
26(af31)
27
28(af32)
29
30(af33)
31
32(cs4)
33
34(af41)
35
36(af42)
37
38(af43)
39
40(cs5)
41
42
43
44
45
46(ef)
47
48(cs6)
49
50
51
52
53
54
55
56(cs7)
57
58
59
60
61
62
63
-----------------------------------------------------------------
[RouterA] display drop-profile data
Drop-profile[1]: data
DSCP Low-limit High-limit Discard-percentage
-----------------------------------------------------------------
0(default)
1
2
3
4
5
6
7
8(cs1)
9
10(af11)
11
12(af12)
13
14(af13)
15
16(cs2)
17
18(af21)
19
20(af22)
21
22(af23)
23
24(cs3)
25
26(af31)
27
28(af32)
29
30(af33)
31
32(cs4)
33
34(af41)
35
36(af42)
37
38(af43)
39
40(cs5)
41
42
43
44
45
46(ef)
47
48(cs6)
49
50
51
52
53
54
55
56(cs7)
57
58
59
60
61
62
63
-----------------------------------------------------------------
Configuration Files

#
sysname RouterA
#
vlan batch 20 30
#
drop-profile data
wred dscp
dscp af31 low-limit 40 high-limit 60 discard-percentage 40
#
drop-profile video
wred dscp
#
queue 3 drop-profile data
queue 4 drop-profile video
schedule wfq 3 to 4 pq 5
#
interface Vlanif20
ip address 192.168.2.1 255.255.255.0
#
interface Vlanif30
ip address 192.168.3.1 255.255.255.0
#
trust dscp
#
trust dscp
#
ip address 192.168.4.1 255.255.255.0
#
return
14.9.12 Example for Configuring Re-marking
As shown in Figure 14-9-12, voice, video, and data terminals on the enterprise's LAN connect
to Eth2/0/0 and Eth2/0/1 on RouterA through SwitchA and SwitchB. These terminals connect to
the WAN through GE3/0/0 on RouterA.
Packets of different services are identified by 802.1p priorities on the LAN. When packets reach
the WAN through GE3/0/0, it is required that differentiated services are provided based on DSCP
priorities.
Figure 14-9-12 Networking for configuring re-marking
802.1p priorities are re-marked with DSCP priorities to implement differentiated services.
2. Configure traffic classifiers on RouterA to classify packets based on 802.1p priorities.
3. Configure traffic behaviors on RouterA to re-mark 802.1p priorities of packets with DSCP
priorities.
4. Configure a traffic policy on RouterA, bind the configured traffic behaviors and traffic
classifiers to the traffic policy, and apply the traffic policy to Eth2/0/0 and Eth2/0/1 in
the inbound direction so that packets are re-marked.
Procedure
# Configure Eth2/0/0 and Eth2/0/1 as trunk interfaces, and add Eth2/0/0 to VLAN 20 and
Eth2/0/1 to VLAN 30.

NOTE:
Configure the interface on SwitchA connected to RouterA as a trunk interface and add it to
VLAN 20.
Configure the interface on SwitchB connected to RouterA as a trunk interface and add it to
VLAN 30.
# Create VLANIF 20 and VLANIF 30, and assign IP address 192.168.2.1/24 to VLANIF 20 and
IP address 192.168.3.1/24 to VLANIF 30.

# Configure IP address 192.168.4.1/24 for GE3/0/0 on RouterA.

# Configure IP address 192.168.4.2/24 for GE3/0/0 on RouterB.
# Configure RouterB to interwork with the LAN-side device.

NOTE:
Configure the default gateway address 192.168.2.1/24 for enterprise users connected to
SwitchA.
SwitchB.
# Create and configure traffic classifiers c1, c2, and c3 on RouterA to classify packets based on
802.1p priorities.

[RouterA-classifier-c1] if-match 8021p 2
# Create and configure traffic behaviors b1, b2, and b3 on RouterA to re-mark 802.1p
priorities of packets with DSCP priorities.

[RouterA-behavior-b1] remark dscp 15
4. Configure a traffic policy and apply the traffic policy to interfaces.

# Create a traffic policy p1 on RouterA, bind the traffic behaviors and traffic classifiers to the
traffic policy, and apply the traffic policy to Eth2/0/0 and Eth2/0/1 in the inbound direction.

<RouterA> display traffic classifier user-defined

Operator: OR
Rule(s) :
if-match 8021p 5
Classifier: c3
Operator: OR
Rule(s) :
if-match 8021p 6
Classifier: c1
Operator: OR
Rule(s) :
if-match 8021p 2
<RouterA> display traffic policy user-defined p1

Policy: p1
Classifier: c1
Operator: OR
Behavior: b1
Marking:
Remark DSCP 15
Classifier: c2
Operator: OR
Behavior: b2
Marking:
Remark DSCP cs5
Classifier: c3
Operator: OR
Behavior: b3
Marking:
Remark DSCP 50
Configuration Files
#
sysname RouterA
#
vlan batch 20 30
#
if-match 8021p 6
if-match 8021p 5
if-match 8021p 2
#
traffic behavior b3
remark dscp 50
traffic behavior b2
remark dscp cs5
traffic behavior b1
remark dscp 15
#
traffic policy p1
#
interface Vlanif20
ip address 192.168.2.1 255.255.255.0
#
interface Vlanif30
ip address 192.168.3.1 255.255.255.0
#
#
#
ip address 192.168.4.1 255.255.255.0
#
return
#
sysname RouterB
#
ip address 192.168.4.2 255.255.255.0
#
ip route-static 192.168.2.0 255.255.255.0 192.168.4.1
ip route-static 192.168.3.0 255.255.255.0 192.168.4.1
#
return
14.9.13 Example for Configuring PBR
As shown in Figure 14-9-13, two departments in VLAN 10 and VLAN 20 connect to GE1/0/0 and
GE2/0/0 on RouterA.
RouterA can connect to the Internet through the link RouterA -> RouterB -> RouterD or RouterA
-> RouterC -> RouterD. The requirements are as follows:
 Packets from the two departments reach the Internet through the two links when the two links
are running properly.
 When a link is faulty, packets from the two departments are forwarded on the other link.
This prevents service interruption for a long time.
 When the link fault is rectified, packets reach the Internet through the two links.
Table 14-9-1 IP Address
RouterA
Table 14-9-1 IP Address
RouterB
RouterC
RouterD
Redirection is used to implement PBR. The configuration roadmap is as follows:
1. Configure an IP address for each interface so that enterprise users can access the
Internet through RouterA.
2. Configure NQA test instances to detect whether the links RouterA -> RouterB -> RouterD and
RouterA -> RouterC -> RouterD are running
properly.
3. Associate the NQA test instances with static routes. When a link becomes faulty, services can
be switched to another link.
4. Configure traffic classifiers and configure matching rules based on the inbound interface.
5. Configure traffic behaviors in which redirection is associated with the NQA test instance.
When the NQA test instance detects that the link RouterA -> RouterB -> RouterD is running
properly, packets matching the traffic classifier are redirected to 192.168.3.2/24. When the
NQA test instance detects that the link RouterA -> RouterC -> RouterD is running properly,
packets matching the traffic classifier are redirected to 192.168.4.2/24.
6. Configure traffic policies, bind the traffic classifiers and traffic behaviors to the traffic
policies, and apply the traffic policies to interfaces.
Procedure
1. Configure interworking between devices.
# Assign an IP address to each interface. This example describes the configuration on RouterA.
The configurations of other devices are similar to the configuration of RouterA. For the
detailed configuration procedure, see the configuration files.
NOTE:
Configure SwitchA and SwitchB so that they can communicate with RouterA.
# Configure static routes between devices.

2. Configure NQA test instances on RouterA.

3. Associate the NQA test instances with static routes.
[RouterA] ip route-static 192.168.7.0 255.255.255.0 192.168.3.2 track nqa admin vlan10

[RouterA] ip route-static 192.168.7.0 255.255.255.0 192.168.4.2 track nqa admin vlan20
# Configure traffic classifiers vlan10 and vlan20 on RouterA to match incoming packets on
GE1/0/0 and GE2/0/0 respectively.

[RouterA-classifier-vlan10] if-match inbound-interface gigabitethernet 1/0/0
[RouterA-classifier-vlan20] if-match inbound-interface gigabitethernet 2/0/0
5. Configure a traffic behavior.
# Create traffic behavior vlan10 on RouterA and associate the NQA test instance admin vlan10
with redirection to the next hop 192.168.3.2/24. When the NQA test instance detects that
the link is running properly, redirection takes effect. When the NQA test instance detects a
link fault, packets are forwarded along the original path.

# Create traffic behavior vlan20 on RouterA and associate the NQA test instance admin vlan20
with redirection to the next hop 192.168.4.2/24. When the NQA test instance detects that
the link is running properly, redirection takes effect. When the NQA test instance detects a
link
fault, packets are forwarded along the original path.

6. Configure traffic policies and apply the traffic policies to interfaces.
# Create traffic policies vlan10 and vlan20 on RouterA and bind traffic classifiers and
traffic behaviors to the traffic policies.
# Apply the traffic policy vlan10 to GE1/0/0 in the inbound direction and the traffic policy
vlan20 to GE2/0/0 in the inbound direction.


#
ip address 192.168.1.1 255.255.255.0
#
return
#
ip address 192.168.2.1 255.255.255.0
#
return
Policy: vlan10
Classifier: vlan10
Operator: OR
Behavior: vlan10
Redirect:
Policy: vlan20
Classifier: vlan20
Operator: OR
Behavior: vlan20
Redirect:
Configuration Files
#
sysname RouterA
#
if-match inbound-interface
GigabitEthernet1/0/0 traffic classifier vlan20
operator or
if-match inbound-interface GigabitEthernet2/0/0
#
#
#
ip address 192.168.1.1 255.255.255.0
#
ip address 192.168.2.1 255.255.255.0
#
ip address 192.168.3.1 255.255.255.0
#
ip address 192.168.4.1 255.255.255.0
#
ip route-static 192.168.5.0 255.255.255.0 192.168.3.2
ip route-static 192.168.6.0 255.255.255.0 192.168.4.2
#
test-type icmp
frequency 10
probe-count 2
start now
test-type icmp
frequency 10
probe-count 2
start now
#
return
#
sysname RouterB
#
ip address 192.168.3.2 255.255.255.0
ip address 192.168.5.2 255.255.255.0
#
ip route-static 192.168.1.0 255.255.255.0 192.168.3.1
ip route-static 192.168.7.0 255.255.255.0 192.168.5.1
#
return
#
sysname RouterC
#
ip address 192.168.4.2 255.255.255.0
ip address 192.168.6.2 255.255.255.0
#
ip route-static 192.168.1.0 255.255.255.0 192.168.4.1
ip route-static 192.168.7.0 255.255.255.0 192.168.6.1
#
return
#
sysname RouterD
#
ip address 192.168.5.1 255.255.255.0
ip address 192.168.6.1 255.255.255.0
ip address 192.168.7.1 255.255.255.0
#
ip route-static 192.168.1.0 255.255.255.0 192.168.5.2
ip route-static 192.168.2.0 255.255.255.0 192.168.6.2
ip route-static 192.168.3.0 255.255.255.0 192.168.5.2
ip route-static 192.168.4.0 255.255.255.0 192.168.6.2
#
return
14.9.14 Example for Configuring Traffic Statistics
As shown in Figure 14-9-14, the MAC address of PC1 is 0000-0000-0003 and PC1 is connected to
the WAN-side network device through the switch. The Router is required to collect statistics on
packets with the source MAC address 0000-0000-0003.
Figure 14-9-14 Networking for configuring traffic statistics
You can define the traffic statistics action in a traffic policy. The configuration roadmap is as follows:
1. Configure interfaces so that the Router can connect to the switch and PC1.
2. Configure an ACL to match packets with the source MAC address 0000-0000-0003.
3. Configure a traffic classifier and reference the ACL in the traffic classifier.
4. Configure a traffic behavior so that the Router can collect statistics on packets matching rules.
5. Configure a traffic policy, bind the traffic policy to the traffic classifier and traffic behavior,
and apply the traffic policy to Eth2/0/0 so that the Huawei can collect statistics on packets with
the source MAC address 0000-0000-0003.
Procedure
# Create VLAN 20 on the Router.
[Router] vlan 20
[Router-vlan20] quit
# Configure Eth2/0/0 on the Router as a trunk interface and add Eth2/0/0 to VLAN 20.
[Router] interface ethernet 2/0/0

[Router-Ethernet2/0/0] port link-type trunk
[Router-Ethernet2/0/0] port trunk allow-pass vlan 20
[Router-Ethernet2/0/0] quit
# Create VLAN 20 on the switch, configure GE1/0/2 as a trunk interface and GE1/0/1 as
an access interface, and add GE1/0/2 to VLAN 20.
[Huawei] sysname Switch
[Switch] vlan 20
[Switch-GigabitEthernet1/0/2] port link-type trunk
[Switch-GigabitEthernet1/0/2] port trunk allow-pass vlan 20
2. Configure an ACL.
# Create ACL 4000 (Layer 2 ACL) on the Router to match packets with the source MAC
address 0000-0000-0003.
[Router] acl 4000

[Router-acl-L2-4000] rule permit source-mac 0000-0000-0003 ffff-ffff-ffff
[Router-acl-L2-4000] quit
3. Configure a traffic classifier.
# Create a traffic classifier c1 on the Router and bind it to ACL 4000.
[Router] traffic classifier c1

[Router-classifier-c1] if-match acl 4000
[Router-classifier-c1] quit
4. Configure a traffic behavior.
# Create a traffic behavior b1 on the Router and configure the traffic statistics action in
the traffic behavior.
[Router] traffic behavior b1

[Router-behavior-b1] statistic enable
[Router-behavior-b1] quit
5. Configure a traffic policy and apply the traffic policy to an interface.
# Create a traffic policy p1 on the Router and bind the traffic policy to the traffic classifier
and traffic behavior.
[Router] traffic policy p1
[Router-trafficpolicy-p1] classifier c1 behavior b1
[Router-trafficpolicy-p1] quit
# Apply the traffic policy p1 to Eth2/0/0.
[Router] interface ethernet 2/0/0

[Router-Ethernet2/0/0] traffic-policy p1 inbound
[Router-Ethernet2/0/0] quit
# View the ACL configuration.
<Router> display acl 4000

L2 ACL 4000, 1 rule
Acl's step is 5
rule 5 permit source-mac 0000-0000-0003
<Router> display traffic classifier user-defined

Operator: OR
Rule(s) :
if-match acl 4000
<Router> display traffic policy user-defined p1

Policy: p1
Classifier: c1
Operator: OR
Behavior: b1
statistic: enable
# View the traffic statistics.
<Router> display traffic policy statistics interface ethernet 2/0/0 inbound
Interface: Ethernet2/0/0
Traffic policy inbound: p1
Rule number: 1
Current status: OK!
Item Sum(Packets/Bytes) Rate(pps/bps)
-------------------------------------------------------------------------------
Matched 0/ 0/
- -
+--Passed 0/ 0/
- -
+--Dropped 0/ 0/
- -
+--Filter 0/ 0/
- -
+--CAR 0/ 0/
- -
+--Queue Matched 0/ 0/
- -
+--Enqueued 0/ 0/
- -
+--Discarded 0/ 0/
- -
+--Car 0/ 0/
- -
+--Green packets 0/ 0/
- -
+--Yellow packets 0/ 0/
- -
+--Red packets 0/ 0/
- -
Configuration Files
 Configuration file of the Router
#
sysname Router
#
vlan batch 20
#
acl number 4000
rule 5 permit source-mac 0000-0000-0003
#
if-match acl 4000
#
traffic behavior b1
statistic enable
#
traffic policy p1
#
#
return
 Configuration file of Switch
#
sysname Switch
#
vlan batch 20
#
#
#
return
14.9.15 Example for Configuring Packet Filtering
As shown in Figure 14-9-15, voice, video, and data terminals on the enterprise's LAN connect
to Eth2/0/0 and Eth2/0/1 on RouterA through SwitchA and SwitchB. These terminals connect to
the WAN through GE1/0/0 on RouterA.
Packets of different services are identified by 802.1p priorities on the LAN. When packets reach
the WAN through GE1/0/0, it is required that data packets be filtered and voice and video services
be ensured.
Figure 14-9-15 Networking for configuring packet filtering
You can define the deny action in a traffic policy to filter packets. The configuration roadmap is
as follows:
1. Configure interfaces so that enterprise users can access the WAN through RouterA.
2. Configure traffic classifiers to classify packets based on 802.1p priorities.
3. Configure traffic behaviors so that the device permits or rejects packets matching rules.
4. Configure a traffic policy, bind the traffic policy to the traffic classifiers and traffic
behaviors, and apply the traffic policy to Eth2/0/0 and Eth2/0/1 in the inbound direction to
filter packets.
Procedure
# Configure Eth2/0/0 and Eth2/0/1 on RouterA as trunk interfaces, and add Eth2/0/0 to VLAN
10 and Eth2/0/1 to VLAN 20. Configure IP address 192.168.4.1/24 for GE1/0/0.

NOTE:
Configure the interface on SwitchA connected to RouterA as a trunk interface and add it to
VLAN 10.
Configure the interface on SwitchB connected to RouterA as a trunk interface and add it to
VLAN 20.
# Create VLANIF 10 and VLANIF 20, and assign IP address 192.168.2.1/24 to VLANIF 10 and
IP address 192.168.3.1/24 to VLANIF 20.

# Configure IP address 192.168.4.2/24 for GE1/0/0 on RouterB.
# Configure RouterB to interwork with the LAN-side device.

NOTE:
SwitchA.
SwitchB.
# Create and configure traffic classifiers c1, c2, and c3 on RouterA to classify packets based on
802.1p priorities.

# Configure the traffic behavior b1 on RouterA and define the deny action.

[RouterA-behavior-b1] deny
# Configure the traffic behaviors b2 and b3 on RouterA and define the permit action.

[RouterA-behavior-b2] permit
[RouterA-behavior-b3] permit
4. Configure a traffic policy and apply the traffic policy to interfaces.
# Create a traffic policy p1 on RouterA, bind the traffic behaviors and traffic classifiers to
the traffic policy, and apply the traffic policy to Eth2/0/0 and Eth2/0/1 in the inbound
direction to
filter packets.


<RouterA> display traffic classifier user-defined
Operator: OR
Rule(s) :
if-match 8021p 5
Classifier: c3
Operator: OR
Rule(s) :
if-match 8021p 6
Classifier: c1
Operator: OR
Rule(s) :
if-match 8021p 2
# View the traffic policy record.
<Router> display traffic-policy applied-record p1

-------------------------------------------------
Policy Name: p1
Policy Index: 3
Classifier:c2 Behavior:b2
-------------------------------------------------
*interface Ethernet2/0/0
slot 0 : success
slot 2 : success
Classifier: c2
Operator: OR
Rule(s) :
if-match 8021p 5
Behavior: b2
Classifier: c1
Operator: OR
Rule(s) :
if-match 8021p 2
Behavior: b1
Deny
Classifier: c3
Operator: OR
Rule(s) :
if-match 8021p 6
Behavior: b3
-------------------------------------------------
Policy total applied times: 1.
Configuration Files
#
sysname RouterA
#
vlan batch 10 20
#
if-match 8021p 6
if-match 8021p 5
if-match 8021p 2
#
traffic behavior b3
traffic behavior b2
traffic behavior b1
deny
#
traffic policy p1
#
interface Vlanif10
ip address 192.168.2.1 255.255.255.0
#
interface Vlanif20
ip address 192.168.3.1 255.255.255.0
#
#
#
ip address 192.168.4.1 255.255.255.0
#
return
#
sysname RouterB
#
ip address 192.168.4.2 255.255.255.0
#
ip route-static 192.168.2.0 255.255.255.0 192.168.4.1
ip route-static 192.168.3.0 255.255.255.0 192.168.4.1
#
return
14.9.16 Example for Configuring the Device to Communicate with the NM Station Using
SNMPv2c
As shown in Figure 14-9-16, NMS1 and NMS2 manage devices on the existing network. Since the
network is small and has high security and a high service traffic volume, devices are configured to
communicate with the NMS using SNMPv2c. A router is added to the network for capacity
expansion and monitored by the NMSs.
Users want to monitor the router using current network resources. To allow the NMS administrator
quickly contact a device administrator to locate and troubleshoot faults on the router, contact
information about the device administrator is required to be configured on the device. Based on
users' service requirements, the NMS is restricted to manage only DNS nodes on the router.
Figure 14-9-16 Networking diagram for configuring the device to communicate with the NM
station using SNMPv2c
Since the network is small and has high security and a high service traffic volume, SNMPv2c can
be enabled on the new device. To reduce the workload of the NM station, NMS2 is used to manage
the router. NMS1 does not manage the router.
1. Configure SNMPv2c on the router.
2. Configure user access rights to enable NMS2 to manage DNS nodes on the router.
3. Configure the trap function on the router to send alarms generated on the router to NMS2.
Only modules that are enabled by default can send alarms, which helps locate alarms and
prevent unwanted alarms.
4. Configure contact information for the router administrator to quickly troubleshoot faults
when the router fails.
5. Configure the NM station (only NMS2).
Procedure
1. Configure the IP address and route on the router and ensure the route between the device and the
NMS is reachable.
[Router-GigabitEthernet1/0/0] ip address 1.1.2.1 24
[Router] ospf
[Router-ospf-1] area 0
[Router-ospf-1-area-0.0.0.0] network 1.1.2.0 0.0.0.255
[Router-ospf-1-area-0.0.0.0] quit
[Router-ospf-1] quit
2. Enable the SNMP agent.
[Router] snmp-agent
3. Configure SNMPv2c on the Router.
[Router] snmp-agent sys-info version v2c
4. Configure access rights of the NM station.
# Configure ACLs, enable NMS2 to manage the router, and disable NMS1 from managing
the router.
[Router] acl 2001

[Router-acl-basic-2001] rule 5 permit source 1.1.1.2 0.0.0.0
[Router-acl-basic-2001] rule 6 deny source 1.1.1.1 0.0.0.0
[Router-acl-basic-2001] quit
# Configure a MIB view.
[Router] snmp-agent mib-view dnsmib include 1.3.6.1.4.1.2011.5.25.194
# Configure an SNMP community name and reference the configured ACLs and the MIB view.
[Router] snmp-agent community write adminnms2 mib-view dnsmib acl 2001
5. Configure the trap function.
[Router] snmp-agent target-host trap-paramsname trapnms2 v2c securityname

adminnms2
[Router] snmp-agent target-host trap-hostname nms2 address 1.1.1.2 trap-paramsname
trapnms2
[Router] snmp-agent trap queue-size 200
[Router] snmp-agent trap life 60
[Router] snmp-agent trap enable
6. Check contact information about the device administrator.
[Router] snmp-agent sys-info contact call Operator at 010-12345678
7. Configure the NM station (NMS2).
Set read and write community names on the NMS that uses SNMPv2. Set the timeout
period and the maximum number of retries. For configurations of the NMS, refer to related
configuration guides.
NOTE:
Authentication parameter configuration of the NMS must be the same as that of the device.
If the authentication parameter configuration of the NMS is different from that of the device,
the NMS cannot manage the device.
8. Check the configuration.
After the configuration is complete, run the following commands to verify that
the configurations have taken effect.
# Check the configured SNMP version.
<Router> display snmp-agent sys-info version

SNMP version running in the system:
SNMPv2c
# View the community names.
<Router> display snmp-agent community write

Community name: adminNMS2
Storage type: nonVolatile
View name: dnsmib
Acl: 2001
Total number is 1
# Check the configuration of ACLs.

Basic ACL 2001, 2 rules
Acl's step is 5
# Display the MIB view.
<Router> display snmp-agent mib-view dnsmib

View name: dnsmib
MIB subtree: hwDnsMIB
Subtree mask:
View type: included
View status: active
# Check the target host for alarms.
<Router> display snmp-agent target-host

Traphost list:
Target host name: nms2
Traphost address: 1.1.1.2
Traphost portnumber: 162
Target host parameter: trapnms2
Total number is 1
Parameter list trap target host:

Parameter name of the target host: trapnms2
Message mode of the target host: SNMPV2C
Trap version of the target host: v2c
Security name of the target host: adminnms2
Total number is 1
# Check contact information about the device administrator.
<Router> display snmp-agent sys-info contact

The contact person for this managed node:
call Operator at 010-12345678
Configuration Files
#
sysname Router
#
snmp-agent local-engineid 800007DB03548998F3A458
snmp-agent community write %$%$P1^727o+9Ic1LFM/>q8T,\SJ%$%$ mib-view dnsmib acl 2001
snmp-agent sys-info contact call Operator at 010-12345678
snmp-agent sys-info version v2c
snmp-agent target-host trap-hostname nms2 address 1.1.1.2 udp-port 162 trap-paramsname
trapnms2
snmp-agent target-host trap-paramsname trapnms2 v2c securityname
adminnms2 snmp-agent mib-view dnsmib include hwDnsMIB
snmp-agent trap enable
snmp-agent trap queue-size 200
snmp-agent trap life 60
snmp-agent
#
acl number 2001
#
ip address 1.1.2.1 255.255.255.0
#
ospf 1
area 0.0.0.0
network 1.1.2.0 0.0.0.255
#
return
14.9.17 Example for Configuring the Device to Communicate with the NM Station Using
SNMPv3
As shown in Figure 14-9-17, NMS1 and NMS2 manage devices on the existing network. Since the
network is large and has low security, devices are configured to communicate with the NM station
using SNMPv3. Authentication and encryption functions are configured to enhance network
security. A router is added to the network for capacity expansion and monitored by the NMSs.
Users want to monitor the router using current network resources. To allow the NMS administrator
quickly contact a device administrator to locate and troubleshoot faults on the device, contact
information about the device administrator is required to be configured on the device. Based on
users' service requirements, the NMS is restricted to manage only DNS nodes on the router.
Figure 14-9-17 Networking diagram for configuring the device to communicate with the NM
station using SNMPv3
Since the network has a small scale and high security but has a high service traffic volume, SNMPv3
can be enabled on the new device. To reduce the workload of the NM station, NMS2 is used to
manage the router. NMS1 does not manage the router.
1. Configure SNMPv3 on the router.

2. Configure user access rights to enable NMS2 to manage DNS nodes on the router.
3. Configure the trap function on the router to send alarms generated on the router to NMS2.
Only modules that are enabled by default can send alarms, which helps locate alarms and
prevent unwanted alarms.
4. Check contact information about the router administrator to quickly troubleshoot faults
when the router fails.
5. Configure the NM station (only NMS2).
Procedure
1. Configure the IP address and route on the router and ensure the route between the device and the
NMS is reachable.
[Router-GigabitEthernet1/0/0] ip address 1.1.2.1 24
[Router] ospf
[Router-ospf-1] area 0
[Router-ospf-1-area-0.0.0.0] network 1.1.2.0 0.0.0.255
[Router-ospf-1-area-0.0.0.0] quit
[Router-ospf-1] quit
2. Enable the SNMP agent.
[Router] snmp-agent
3. Configure SNMPv3 on the Router.
[Router] snmp-agent sys-info version v3
4. Configure access rights of the NM station.
# Configure ACLs, enable NMS2 to manage the Router, and disable NMS1 from managing the
Router.
[Router] acl 2001

[Router-acl-basic-2001] rule 5 permit source 1.1.1.2 0.0.0.0
[Router-acl-basic-2001] rule 6 deny source 1.1.1.1 0.0.0.0
[Router-acl-basic-2001] quit
# Configure a MIB view.
[Router] snmp-agent mib-view dnsmib include 1.3.6.1.4.1.2011.5.25.194
# Configure users and user groups and authenticate and encrypt user data.
[Router] snmp-agent usm-user v3 testuser testgroup authentication-mode md5
87654321 privacy-mode des56 87654321
[Router] snmp-agent group v3 testgroup privacy write-view dnsmib notify-view dnsmib
acl 2001
5. Configure the trap function.
[Router] snmp-agent target-host trap-paramsname trapnms2 v3 securityname

adminnms2 privacy
[Router] snmp-agent target-host trap-hostname nms2 address 1.1.1.2 trap-paramsname
trapnms2
[Router] snmp-agent trap queue-size 200
[Router] snmp-agent trap life 60
[Router] snmp-agent trap enable
6. Check contact information about the device administrator.
[Router] snmp-agent sys-info contact call Operator at 010-12345678
7. Configure the NM station (NMS2).
Set users and user groups on the NMS that uses SNMPv3. For configurations of the NMS,
refer to related configuration guides.
NOTE:
Authentication parameter configuration of the NMS must be the same as that of the device.
If the authentication parameter configuration of the NMS is different from that of the device,
the NMS cannot manage the device.
8. Check the configuration.
After the configuration is complete, run the following commands to verify that
the configurations have taken effect.
# View user information.
<Router> display snmp-agent group testgroup
Group name: testgroup

Security model: v3 AuthPriv
Readview: ViewDefault
Writeview: dnsmib
Notifyview: dnsmib
Acl: 2001
# View user information.
<Router> display snmp-agent usm-user

User name: testuser
Engine ID: 800007DB03548998F3A458
Group name: testgroup
Authentication mode: md5, Privacy mode: des56
User status: active
Total number is 1
# Check the ACLs.

Basic ACL 2001, 2 rules
ACL's step is 5
# Display the MIB view.
<Router> display snmp-agent mib-view dnsmib

View name: dnsmib
MIB subtree: hwDnsMIB
Subtree mask:
View type: included
View status: active
# Check the target host for alarms.
<Router> display snmp-agent target-host

Traphost list:
Target host name: nms2
Traphost address: 1.1.1.2
Traphost portnumber: 162
Target host parameter: trapnms2
Total number is 1
Parameter list trap target host:

Parameter name of the target host: trapnms2
Message mode of the target host: SNMPV3
Trap version of the target host: v3
Security name of the target host: adminnms2
Security level of the target host: privacy
Total number is 1
# Check contact information about the device administrator.
<Router> display snmp-agent sys-info contact

The contact person for this managed node:
call Operator at 010-12345678
Configuration Files
#
sysname Router
#
snmp-agent local-engineid 800007DB03548998F3A458
snmp-agent sys-info contact call Operator at 010-12345678
snmp-agent sys-info version v3
snmp-agent group v3 testgroup privacy write-view dnsmib notify-view dnsmib acl 2001
snmp-agent target-host trap-hostname nms2 address 1.1.1.2 udp-port 162 trap-paramsname
trapnms2
snmp-agent target-host trap-paramsname trapnms2 v3 securityname adminnms2
privacy snmp-agent mib-view dnsmib include hwDnsMIB
snmp-agent usm-user v3 testuser testgroup authentication-mode md5
E7E7F72509A17CCBCDE43C7EFF3B882D privacy-mode des56
E7E7F72509A17CCBCDE43C7EFF3B882D
snmp-agent trap enable
snmp-agent trap queue-size 200
snmp-agent trap life 60
snmp-agent
#
acl number 2001
#
ip address 1.1.2.1 255.255.255.0
#
ospf 1
area 0.0.0.0
network 1.1.2.0 0.0.0.255
#
return
14.9.18 Example for Configuring Authenticated NTP Unicast Server/Client Mode
As shown in Figure 14-9-18, RouterB, RouterC, and RouterD are on a local area network (LAN),
and are connected to RouterA through a network.
To provide charging services, all routers on the LAN are required to synchronize their system clocks
to a standard clock.
Figure 14-9-18 Networking diagram for configuring NTP unicast client/server mode
As is required by the user, the NTP protocol is used to synchronize clocks. The configuration
1. Configure RouterA as the primary time server.
2. The NTP unicast server/client mode is used to synchronize the clocks of RouterA and RouterB.
RouterA functions as the server, and RouterB functions as the client.
3. The NTP unicast server/client mode is used to synchronize the clocks of RouterB, RouterC, and
RouterD. RouterB functions as the server, while RouterC and RouterD function as the clients.
4. RouterA and RouterB are connected through the network, which is not secure, so that the NTP
authentication function is enabled.
NOTE:
 When configuring NTP authentication in the unicast server/client mode, enable the NTP
authentication on the client, and specify the NTP server address and the authentication key sent
to the server. Otherwise, the NTP authentication is not performed, and the NTP client and server
are
directly synchronized.
 To ensure successful authentication, configure the NTP client and server properly.
Procedure
1. According to Figure 14-9-18, configure IP addresses, and configure reachable routes

between any two of RouterA, RouterB, RouterC, and RouterD.
# Configure an IP address on RouterA. For details about the configurations of

RouterB, RouterC, and RouterD, see "Configuration Files".
[RouterA] ospf 1
2. Configure an NTP primary clock on RouterA and enable the NTP authentication function.
# Specify the local clock of RouterA as the reference clock, and set the clock stratum to 2.
[RouterA] ntp-service refclock-master 2
# Enable the NTP authentication function, configure the authentication key, and specify the
key as reliable.
[RouterA] ntp-service authentication enable

[RouterA] ntp-service authentication-keyid 42 authentication-mode md5 Hello
[RouterA] ntp-service reliable authentication-keyid 42
NOTE:
The server and the client must be configured with the same authentication key.
3. Enable the NTP authentication function on RouterB.
# Enable the NTP authentication function on RouterB, configure the authentication key,
and specify the key as reliable.
<RouterB> system-view
[RouterB] ntp-service authentication enable
[RouterB] ntp-service authentication-keyid 42 authentication-mode md5 Hello
[RouterB] ntp-service reliable authentication-keyid 42
# Specify RouterA as the NTP server of RouterB, and use the configured authentication key.
[RouterB] ntp-service unicast-server 2.2.2.2 authentication-keyid 42
4. # Specify on RouterC that RouterB functions as the NTP server of RouterC.

[RouterC] ntp-service authentication enable
[RouterC] ntp-service authentication-keyid 42 authentication-mode md5 Hello
[RouterC] ntp-service reliable authentication-keyid 42
[RouterC] ntp-service unicast-server 10.0.0.1 authentication-keyid 42
5. # Specify on RouterD that RouterB functions as the NTP server of RouterD.
<RouterD> system-view
[RouterD] ntp-service authentication enable
[RouterD] ntp-service authentication-keyid 42 authentication-mode md5 Hello
[RouterD] ntp-service reliable authentication-keyid 42
[RouterD] ntp-service unicast-server 10.0.0.1 authentication-keyid 42
After the preceding configuration is complete, RouterB can synchronize its clock with the
clock of RouterA.
# Check the NTP status of RouterB, and you can find that the clock status is
"synchronized", indicating that the synchronization is complete. The stratum of the clock is
3, which is one stratum lower than that of the clock of the server RouterA.
[RouterB] display ntp-service status

clock status: synchronized
clock stratum: 3
reference clock ID: 2.2.2.2
nominal frequency: 60.0002 Hz
actual frequency: 60.0002 Hz
clock precision: 2^18
clock offset: 3.8128 ms
root delay: 31.26 ms
root dispersion: 74.20 ms
peer dispersion: 34.30 ms
reference time: 11:55:56.833 UTC Mar 2 2006(C7B15BCC.D5604189)
After the preceding configuration is complete, RouterC can synchronize its clock with the
clock of RouterB.
# Check the NTP status of RouterC, and you can find that the clock status is
4, which is one
stratum lower than that of the clock of the server RouterB.
[RouterC] display ntp-service status

clock stratum: 4
# Check the NTP status of RouterD, and you can find that the clock status is
4, which is one
stratum lower than that of the clock of the server RouterB.
[RouterD] display ntp-service status

clock stratum: 4
# Check the NTP status of RouterA.
[RouterA] display ntp-service status

clock stratum: 2
reference clock ID: LOCAL(0)
root delay: 0.00 ms
reference time: 12:01:48.377 UTC Mar 2 2012(C7B15D2C.60A15981)
Configuration Files
#
sysname RouterA
#
ntp-service authentication enable
ntp-service authentication-keyid 42 authentication-
mode md5 %$%$iU;C@~zqb+};!@!vGIp5q}tk%$%$
ntp-service reliable authentication-keyid
42 ntp-service refclock-master 2
#
ip address 2.2.2.2 255.255.255.0
#
ospf 1
area 0.0.0.0
network 2.2.2.0 0.0.0.255
#
return
#
sysname RouterB
#
ntp-service reliable authentication-keyid 42
ntp-service unicast-server 2.2.2.2 authentication-keyid 42
#
ip address 10.0.1.1 255.255.255.0
#
ip address 10.0.0.1 255.255.255.0
#
ospf 1
area 0.0.0.0
network 10.0.0.0 0.0.0.255
network 10.0.1.0 0.0.0.255
#
return
#
sysname RouterC
#
#
ip address 10.0.0.2 255.255.255.0
#
return
#
sysname RouterD
#
#
ip address 10.0.0.3 255.255.255.0
#
return
14.9.19 Example for Configuring NTP Symmetric Peer Mode
As shown in Figure 14-9-19, three devices are on a local area network (LAN). RouterC
is synchronized with a standard clock through a network.
RouterC, RouterD, and RouterE on the unified LAN need to be synchronized to the standard clock.
Figure 14-9-19 Networking diagram for configuring the symmetric peer mode
1. Configure the local clock of RouterC as the NTP primary clock.
2. The NTP unicast server/client mode is used to synchronize the clocks of RouterC and RouterD.
RouterC functions as the server, and RouterD functions as the client.
3. The symmetric peer mode is used to synchronize the clocks of RouterE and RouterD. RouterE
functions as the symmetric active peer and sends a clock synchronization request to RouterD.
Procedure
1. Configure IP addresses for RouterC, RouterD, and RouterE.
Configure an IP address for each interface according to Figure 14-9-19. After

the configurations are complete, the three switches can ping each other.
# Configure an IP address on RouterC. For details about the configurations of RouterD and
RouterE, see "Configuration Files".
2. Configure the NTP client/server mode.
# Set the local clock of RouterC as the NTP primary clock, and set the clock stratum to 2.

1210
[RouterC] ntp-service refclock-master 2
# Specify on RouterD that RouterC functions as the NTP server of RouterD.
[RouterD] ntp-service unicast-server 10.0.0.1
After the preceding configuration is complete, RouterD can synchronize its clock with the
clock of RouterC.
3, which is one stratum lower than that of the clock of RouterC.

clock stratum: 3
reference time: 06:52:33.465 UTC Mar 7 2012(C7B7AC31.773E89A8)
3. Configure the NTP unicast symmetric peer mode.
# Specify on RouterE that RouterD functions as the symmetric passive peer of RouterE.
<RouterE> system-view
[RouterE] ntp-service unicast-peer 10.0.0.2
RouterE is not configured with a primary clock and its clock stratum is lower than that of
RouterD, so that RouterE synchronizes its clock with the clock of RouterD.
Monitor the status of RouterE after the synchronization. The clock of RouterE is in
"synchronized" status, indicating that the synchronization is complete. The clock stratum
of RouterE is 4, which is one stratum lower than that of the symmetric passive peer
RouterD.
# Check the clock status of RouterE.
[RouterE] display ntp-service status

clock stratum: 4
reference time: 06:55:50.784 UTC Mar 7 2012(C7B7ACF6.C8D002E2)
Configuration Files
#
sysname RouterC
#
ntp-service refclock-master 2
#
ip address 10.0.0.1 255.255.255.0
#
return
#
sysname RouterD
#
ntp-service unicast-server 10.0.0.1
#
ip address 10.0.0.2 255.255.255.0
#
return
#
sysname RouterE
#
ntp-service unicast-peer 10.0.0.2
#
ip address 10.0.0.3 255.255.255.0
#
return
14.9.20 Example for Configuring Authenticated NTP Broadcast Mode
As shown in Figure 14-9-20, RouterF, RouterC, and RouterD are on a local area network (LAN).
RouterA directly connects to RouterF. RouterC directly synchronize its clock to a standard clock
by radio.
All routers except RouterA on the LAN are required to synchronize their clocks to the standard clock.
Figure 14-9-20 Networking diagram for configuring NTP broadcast mode
1. Configure RouterC as the primary time server, use the local clock as the NTP primary
clock, and set the clock stratum to 3.
2. Configure RouterC as the NTP broadcast server that sends broadcast packets from interface
GE1/0/0.
3. Configure RouterA, RouterD and RouterF as NTP broadcast clients. RouterA uses
interface GE1/0/0 to listen to the broadcast packets. RouterD uses interface GE1/0/0 to
listen to the broadcast packets. RouterF uses interface GE2/0/0 to listen to the broadcast
packets.
4. To strengthen the network security, the NTP authentication function is enabled.

Procedure
1. Configure an IP address for each interface according to Figure 14-9-20, and

configure reachable routes between the routeres.
# Configure an IP address for the interface and configure a routing protocol on RouterA.
[RouterA] ospf 1
For details about the configurations of RouterC, RouterD, and RouterF, see "Configuration
Files".
2. Configure the NTP broadcast server, and enable the

authentication.
# Configure the local clock of RouterC as the NTP primary clock, and set the clock stratum to 3.
# Enable NTP authentication.
[RouterC] ntp-service authentication enable
[RouterC] ntp-service authentication-keyid 16 authentication-mode md5 Hello
[RouterC] ntp-service reliable authentication-keyid 16
# Configure RouterC as the NTP broadcast server that sends NTP broadcast packets from
VLANIF10, and specify the key with the ID 16 for
encryption. [RouterC] interface gigabitethernet 1/0/0
[RouterC-GigabitEthernet1/0/0] ntp-service broadcast-server authentication-keyid 16
3. Configure the NTP broadcast client RouterD on a network segment the same as that of the
NTP
server.
[RouterD] ntp-service authentication enable
[RouterD] ntp-service authentication-keyid 16 authentication-mode md5 Hello
[RouterD] ntp-service reliable authentication-keyid 16
# Configure RouterD as the NTP broadcast client that listens to the NTP broadcast packets
from interface GE1/0/0.
[RouterD-GigabitEthernet1/0/0] ntp-service broadcast-client
After the configuration is complete, RouterD synchronizes its clock to that of RouterC.
For details about the configuration of RouterF, which is similar to that of RouterC, see the
corresponding configuration file.
4. Configure the NTP broadcast client RouterA on a network segment different from that of
the server.

[RouterA] ntp-service authentication enable
[RouterA] ntp-service authentication-keyid 16 authentication-mode md5 Hello
[RouterA] ntp-service reliable authentication-keyid 16
# Configure RouterA as the NTP broadcast client that listens to the NTP broadcast packets
from interface VLANIF20.
[RouterA-GigabitEthernet1/0/0] ntp-service broadcast-client
After the preceding configuration is complete, RouterD can synchronize its clock to that of
RouterC, but RouterA cannot synchronize its clock to that of RouterC.
This is because RouterA is on a network segment different from that of RouterC, but RouterD
is on a network segment the same as that of RouterC.
4, which is one stratum lower than that of the clock of RouterC.

clock stratum: 4
root delay: 0.00 ms
reference time: 12:17:21.773 UTC Mar 7 2012(C7B7F851.C5EAF25B)
Configuration Files
#
sysname RouterA
#
mode md5 %$%$Q1Ub0~;Ga!9IasE'@Db-,5,#%$%$
#
ip address 1.0.1.11 255.255.255.0
ntp-service broadcast-client
#
return
#
sysname RouterC
#
#
ip address 3.0.1.31 255.255.255.0
ntp-service broadcast-server authentication-keyid 16
#
return
#
sysname RouterD
#
#
ip address 3.0.1.31 255.255.255.0
#
return
#
sysname RouterF
#
#
ip address 3.0.1.2 255.255.255.0
#
ip address 1.0.1.2 255.255.255.0
#
return
14.9.21 Example for Configuring NTP Multicast Mode
As shown in Figure 14-9-21, RouterA, RouterB and RouterC are on the same local area network
(LAN). RouterA is directly synchronized to a standard clock by radio.
The clocks of all routers on the network need to be synchronized to the standard clock.
Figure 14-9-21 Networking diagram for configuring NTP multicast mode
1. Configure RouterA as the primary time server, use the local clock as the NTP primary
clock, and set the clock stratum to 2.
2. Configure RouterA as the NTP multicast server that sends multicast packets from interface
GE1/0/0.
3. Configure RouterB and RouterC as NTP multicast clients. RouterB uses GE1/0/0 to listen to
the multicast packets. RouterC uses GE1/0/0 to listen to the multicast packets.
Procedure
1. Configure an IP address for each interface according to Figure 14-9-21, and

configure reachable routes between the routeres.
# Configure an IP address for the interface on RouterA.
For details about the configurations of RouterB and RouterC, see "Configuration Files".
2. Configure the NTP multicast server.
# Configure the local clock of RouterA as the NTP primary clock, and set the clock stratum to 2.
# Configure RouterA as the NTP multicast server that sends NTP multicast packets from
GE1/0/0.
[RouterA-GigabitEthernet1/0/0] ntp-service multicast-server
3. Configure the NTP multicast client RouterB on a network segment the same as that of the NTP
server.
# Configure RouterB as the NTP multicast client that listens to the NTP multicast packets
<RouterB> system-view
[RouterB-GigabitEthernet1/0/0] ntp-service multicast-client
4. Configure the NTP multicast client RouterC on a network segment different from that of
the server.
# Configure RouterC as the NTP multicast client that listens to the NTP multicast packets
[RouterC-GigabitEthernet1/0/0] ntp-service multicast-client
After the preceding configuration is complete, RouterB and RouterC can synchronize
their clocks to the clock of RouterA.
# Check the NTP status of RouterB, and you can find that the clock status is
3, which is one stratum lower than that of the clock of the server RouterA.
[RouterB] display ntp-service status

clock stratum: 3
peer dispers ion: 9.63 ms
reference time: 12:17:21.773 UTC Mar 7 2012(C7B7F851.C5EAF25B)
Configuration Files
#
sysname RouterA
#
ntp-service refclock-master 2
#
ip address 10.1.1.1 255.255.255.0
ntp-service multicast-server
#
return
#
sysname RouterC
#
ip address 10.1.1.2 255.255.255.0
ntp-service multicast-client
#
return
#
sysname RouterD
#
ip address 10.1.1.3 255.255.255.0
ntp-service multicast-client
#
return

HCIE Routing and Switching Material

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

HCIE Routing and Switching Material

Uploaded by

Copyright:

Available Formats

HCIE-R&S Material Confidentiality Level

2016-1-11 Huawei Confidential Page 1 of 1210

1.1.1 RIP Routing Table

Figure 1-1-1 RIP routing table generation

As shown in Figure 1-1-1, the process of RIP routing table generation.

1.1.2 RIP Update and Maintenance

RIP uses four timers to update and maintain routing information:

Relationships between RIP routes and timers:

1.1.2 Triggered Update

Figure 1-1-2 Triggered update

1.2 RIPv2 Enhanced Features

1.2.1 Comparison between RIPv1 and RIPv2

Figure 1-2-1 RIPv1 packet format

Figure 1-2-2 RIPv2 packet format

 Provides two authentication modes to enhance security: plain-text authentication and

1.2.2 RIPv2 Route Summarization

Route summarization is classified into two types:

 RIP process-based classful summarization

1.3 Split Horizon and Poison Reverse

1.3.1 Split Horizon

On a Non-Broadcast Multiple Access (NBMA) network, an interface connects to multiple neighbors;

Figure 1-3-2 Neighbor-based split horizon

1.3.2 Poison Reverse

Figure 1-3-3 Poison reverse

1.4 Multi-process and Multi-instance

1.5 RIP and BFD Association

Table 1-5-1 lists the features of RIP and BFD Association

BFD is classified into static BFD and dynamic BFD:

Figure 1-5-1 RIP and BFD association network

1.6 Hot Standby

1.7 Examples for Configuring RIP

1.7.1 Example for Configuring Basic RIP Functions

Figure 1-7-1 Network diagram of basic RIP functions

1. Configure IP address for each interface to ensure network reachability.

2. Enable RIP on each router to implement network connections between processes.

3. Configure RIPv2 on each router to improve RIP performance.

1. Configure IP address for each interface.

[RouterA] interface gigabitethernet 1/0/0

2. Configure basic RIP functions.

# Check the RIP routing table of RouterA.

[RouterA] display rip 1 route

3. Configure the RIP version.

# Configure RIPv2 on RouterB.

# Configure RIPv2 on RouterC.

# Configure RIPv2 on RouterD.

4. Verify the configuration.

# Check the RIP routing table of RouterA.

[RouterA] display rip 1 route

 Configuration file of RouterA

 Configuration file of RouterB

 Configuration file of RouterC

1.7.2 Example for Importing Routes to RIP

Figure 1-7-2 Network diagram of configuring RIP to import external routes

The configuration roadmap is as follows:

1. Enable RIP on each router to implement network connections between processes.

1. Configure an IP address for each interface.

[RouterA] interface gigabitethernet 1/0/0

2. Configure the basic RIP functions.

# Enable RIP process 100 on RouterA.

[RouterA] rip 100

# Enable RIP processes 100 and 200 on RouterB.

[RouterB] rip 100

# Enable RIP process 200 on RouterC.

[RouterC] rip 200