Feature Description - IP Routing

HUAWEI NetEngine80E/40E Router
V600R003C00
Feature Description - IP Routing
Issue 02
Date 2011-09-10
HUAWEI TECHNOLOGIES CO., LTD.

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

Address: Huawei Industrial Base
Bantian, Longgang
Shenzhen 518129
People's Republic of China
Website: http://www.huawei.com
Email: support@huawei.com
Issue 02 (2011-09-10) Huawei Proprietary and Confidential i

Copyright Huawei Technologies Co., Ltd.
Feature Description - IP Routing About This Document
About This Document
Purpose
This document describes the IP Routing feature in terms of its concepts, theories, and
applications.
This document together with other types of document helps intended readers get a
comprehensive understanding of the IP Routing feature.
Related Versions
The following table lists the product versions related to this document.
Product Name Version
HUAWEI NetEngine80E/40E V600R003C00

Router
Intended Audience
This document is intended for:
l Network planning engineers
l Commissioning engineers
l Data configuration engineers
l System maintenance engineers
Symbol Conventions
The symbols that may be found in this document are defined as follows.
Issue 02 (2011-09-10) Huawei Proprietary and Confidential ii

Feature Description - IP Routing About This Document
Symbol Description
Indicates a hazard with a high level of risk, which, if not

avoided, will result in death or serious injury.
DANGER
Indicates a hazard with a medium or low level of risk, which,

if not avoided, could result in minor or moderate injury.
WARNING
Indicates a potentially hazardous situation, which, if not

avoided, could result in equipment damage, data loss,
CAUTION
performance degradation, or unexpected results.
TIP Indicates a tip that may help you solve a problem or save
time.
NOTE Provides additional information to emphasize or supplement

important points of the main text.
Change History
Updates between document issues are cumulative. Therefore, the latest document issue contains
all updates made in previous issues.
Changes in Issue 02 (2011-09-10)

Second commercial release.
Changes in Issue 01 (2011-06-30)

Initial field trial release.
Issue 02 (2011-09-10) Huawei Proprietary and Confidential iii

Feature Description - IP Routing Contents
Contents
About This Document.....................................................................................................................ii

1 IP Routing Overview....................................................................................................................1
1.1 Introduction to IP Routing..................................................................................................................................2
1.2 References..........................................................................................................................................................2
1.3 Principles............................................................................................................................................................2
1.3.1 Routers.......................................................................................................................................................2
1.3.2 Routing Protocols......................................................................................................................................3
1.3.3 Routing Table and FIB Table....................................................................................................................3
1.3.4 Static Routes and Dynamic Routes...........................................................................................................7
1.3.5 Classification of Dynamic Routing Protocols...........................................................................................7
1.3.6 Routing Protocols and Route Preferences.................................................................................................8
1.3.7 Priority-based Route Convergence..........................................................................................................10
1.3.8 Load Balancing and Route Backup.........................................................................................................11
1.3.9 Principle of IP FRR.................................................................................................................................12
1.3.10 Re-advertisement of Routing Information.............................................................................................14
1.3.11 Indirect Next Hop..................................................................................................................................14
1.3.12 Default Routes.......................................................................................................................................16
1.3.13 Multi-Topology.....................................................................................................................................17
1.3.14 VRRP for Direct Routes........................................................................................................................17
1.4 Applications......................................................................................................................................................18
1.4.1 Typical Application of Priority-based Route Convergence.....................................................................19
1.4.2 Typical Application of IP FRR................................................................................................................19
1.4.3 Typical Application of Indirect Next Hop...............................................................................................20
1.5 Terms and Abbreviations..................................................................................................................................21
2 Static Route...................................................................................................................................23
2.1 Introduction to Static Routes............................................................................................................................24
2.2 References........................................................................................................................................................24
2.3 Principles..........................................................................................................................................................24
2.3.1 Components of Static Routes..................................................................................................................24
2.3.2 Applications of Static Routes..................................................................................................................25
2.3.3 Functions of Static Routes.......................................................................................................................27
2.3.4 BFD for Static Routes..............................................................................................................................27
Issue 02 (2011-09-10) Huawei Proprietary and Confidential iv

2.3.5 NQA for IPv4 Static Routes....................................................................................................................28

2.3.6 Permanent Advertisement of Static Routes.............................................................................................30
3 RIP..................................................................................................................................................33
3.1 Introduction to RIP...........................................................................................................................................34
3.2 References........................................................................................................................................................34
3.3 Principles..........................................................................................................................................................34
3.3.1 RIP-1........................................................................................................................................................35
3.3.2 RIP-2........................................................................................................................................................35
3.3.3 Timer.......................................................................................................................................................36
3.3.4 Split Horizon............................................................................................................................................36
3.3.5 Poison Reverse........................................................................................................................................36
3.3.6 Triggered Update.....................................................................................................................................37
3.3.7 Route Aggregation...................................................................................................................................38
3.3.8 Multi-process and Multi-instance............................................................................................................38
3.3.9 Hot Backup..............................................................................................................................................39
4 RIPng..............................................................................................................................................40
4.1 Introduction to RIPng.......................................................................................................................................41
4.2 References........................................................................................................................................................41
4.3 Principles..........................................................................................................................................................41
4.3.1 RIPng Packet Format...............................................................................................................................41
4.3.2 Timer.......................................................................................................................................................43
4.3.3 Split Horizon............................................................................................................................................43
4.3.4 Poison Reverse........................................................................................................................................43
4.3.5 Triggered Update.....................................................................................................................................44
4.3.6 Route Aggregation...................................................................................................................................45
4.3.7 Multi-process and Multi-instance............................................................................................................45
4.3.8 Hot Backup..............................................................................................................................................46
4.3.9 IPSec Authentication...............................................................................................................................46
5 IS-IS................................................................................................................................................47
5.1 Introduction to IS-IS.........................................................................................................................................48
5.2 References........................................................................................................................................................48
5.3 Principles..........................................................................................................................................................49
5.3.1 Basic Concepts of IS-IS...........................................................................................................................49
5.3.2 IS-IS Multi-instance and Multi-process..................................................................................................67
5.3.3 IS-IS Route Leaking................................................................................................................................68
5.3.4 IS-IS Fast Convergence...........................................................................................................................69
5.3.5 Priority-based IS-IS Convergence...........................................................................................................70
5.3.6 IS-IS LSP Fragment Extension................................................................................................................71
Issue 02 (2011-09-10) Huawei Proprietary and Confidential v

5.3.7 IS-IS Administrative Tag.........................................................................................................................74

5.3.8 Dynamic Hostname Exchange Mechanism.............................................................................................74
5.3.9 IS-IS HA..................................................................................................................................................75
5.3.10 IS-IS 3-Way Handshake........................................................................................................................76
5.3.11 IS-IS GR................................................................................................................................................77
5.3.12 IS-IS NSR..............................................................................................................................................84
5.3.13 IS-IS for IPv6.........................................................................................................................................84
5.3.14 IS-IS MT................................................................................................................................................85
5.3.15 IS-IS TE.................................................................................................................................................87
5.3.16 IS-IS Shortcut (AA) and Advertise (FA)...............................................................................................91
5.3.17 IS-IS Wide Metric.................................................................................................................................94
5.3.18 IS-IS Local MT......................................................................................................................................95
5.3.19 IS-IS LDP Synchronization...................................................................................................................99
5.3.20 BFD for IS-IS......................................................................................................................................102
5.3.21 IS-IS Auto FRR...................................................................................................................................105
5.3.22 IS-IS Authentication............................................................................................................................108
5.4 Terms and Abbreviations................................................................................................................................110
6 OSPF.............................................................................................................................................113
6.1 Introduction to OSPF......................................................................................................................................114
6.2 References......................................................................................................................................................114
6.3 Principles........................................................................................................................................................116
6.3.1 Fundamentals of OSPF..........................................................................................................................116
6.3.2 OSPF GR...............................................................................................................................................126
6.3.3 OSPF TE................................................................................................................................................129
6.3.4 OSPF VPN.............................................................................................................................................130
6.3.5 OSPF NSSA..........................................................................................................................................136
6.3.6 OSPF Local MT.....................................................................................................................................137
6.3.7 BFD for OSPF.......................................................................................................................................138
6.3.8 OSPF GTSM..........................................................................................................................................139
6.3.9 OSPF Smart-discover............................................................................................................................140
6.3.10 OSPF-BGP Association.......................................................................................................................141
6.3.11 OSPF-LDP Association.......................................................................................................................142
6.3.12 OSPF Database Overflow....................................................................................................................144
6.3.13 OSPF Fast Convergence......................................................................................................................145
6.3.14 OSPF MIB...........................................................................................................................................146
6.3.15 OSPF Mesh-Group..............................................................................................................................147
6.3.16 Priority-based OSPF Convergence......................................................................................................149
6.3.17 OSPF IP FRR.......................................................................................................................................149
6.4 OSPF Applications.........................................................................................................................................150
6.4.1 OSPF GR...............................................................................................................................................150
6.4.2 OSPF GTSM..........................................................................................................................................150
Issue 02 (2011-09-10) Huawei Proprietary and Confidential vi

7 OSPFv3........................................................................................................................................153
7.1 Introduction to OSPFv3..................................................................................................................................154
7.2 References......................................................................................................................................................154
7.3 Principles........................................................................................................................................................155
7.3.1 Principle of OSPFv3..............................................................................................................................155
7.3.2 OSPFv3 GR...........................................................................................................................................160
7.3.3 BFD for OSPFv3...................................................................................................................................163
7.3.4 OSPFv3 IPSec Authentication...............................................................................................................164
7.3.5 Association between OSPFv3 and BGP................................................................................................165
7.3.6 Comparison between OSPFv3 and OSPFv2.........................................................................................166
8 BGP...............................................................................................................................................169
8.1 Introduction to BGP........................................................................................................................................170
8.2 References......................................................................................................................................................171
8.3 Principles........................................................................................................................................................172
8.3.1 Basic Principle of BGP..........................................................................................................................173
8.3.2 Route Import..........................................................................................................................................180
8.3.3 Route Aggregation.................................................................................................................................180
8.3.4 Route Dampening..................................................................................................................................180
8.3.5 Community Attribute.............................................................................................................................181
8.3.6 Route Reflector......................................................................................................................................183
8.3.7 BGP Confederation................................................................................................................................187
8.3.8 MP-BGP................................................................................................................................................189
8.3.9 BGP GR.................................................................................................................................................190
8.3.10 BGP Security.......................................................................................................................................190
8.3.11 BGP 6PE..............................................................................................................................................191
8.3.12 6PE Routes Sharing the Explicit Null Label.......................................................................................192
8.3.13 BFD for BGP.......................................................................................................................................192
8.3.14 BGP Tracking......................................................................................................................................193
8.3.15 BGP Auto FRR....................................................................................................................................194
8.3.16 BGP ORF.............................................................................................................................................195
8.3.17 Active-Route-Advertise.......................................................................................................................197
8.3.18 BGP Dynamic Update Peer-Groups....................................................................................................197
8.3.19 BGP NSR.............................................................................................................................................200
8.3.20 4-Byte AS Number..............................................................................................................................200
8.3.21 Next-Hop Iteration Based on the Specified Routing Policy................................................................202
9 Routing Policies.........................................................................................................................205
9.1 Introduction to Routing Policies.....................................................................................................................206
9.2 References......................................................................................................................................................206
9.3 Principles........................................................................................................................................................206
9.3.1 Basic Principle of Routing Policies.......................................................................................................206
Issue 02 (2011-09-10) Huawei Proprietary and Confidential vii

9.3.2 Application Environment......................................................................................................................208

9.3.3 IP Prefix List..........................................................................................................................................208
9.3.4 BGP to IGP............................................................................................................................................212
10 Appendix List of Port Numbers of Common Protocols...................................................214
Issue 02 (2011-09-10) Huawei Proprietary and Confidential viii

Feature Description - IP Routing 1 IP Routing Overview
1 IP Routing Overview
About This Chapter
1.1 Introduction to IP Routing

1.2 References
1.3 Principles
1.4 Applications
1.5 Terms and Abbreviations
Issue 02 (2011-09-10) Huawei Proprietary and Confidential 1

1.1 Introduction to IP Routing

Definition
Routing is the basic element of data communication networks. Routing information guides
packet forwarding. The process of routing packets refers to the process of relaying and
forwarding packets.
1.2 References
None
1.3 Principles
1.3.1 Routers
In the Internet, network connecting devices control traffic and ensure the quality of data
transmission on the network. Common network connecting devices include hubs, bridges,
switches and routers.
As a typical network connection device, a router is used to select routes and forward packets.
According to the destination address in the received packet, a router selects a proper path, which
has one or multiple hops, to send the packet to the next router. The last router is responsible for
sending the packet to the destination host. In addition, the router can select an optimal path to
transmit data.
In Figure 1-1, from Host A to Host C, a packet needs to go through three networks and two
routers. The hop count from a router to its directly connected network is zero, and that to a
network, which can be reached through another router, is one; the rest is deduced by analogy.
If a router is connected with another router through a network, that is, a network segment exists
between the two routers, the two routers, hence, are considered as the adjacent routers on the
Internet. In Figure 1-1, the bold arrows indicate network segments. The routers are not concerned
about the physical links that constitute each network segment.

Figure 1-1 Hop count and network segment
Host A
Host C
Host B
The size of each network may be distinct, and the length of each network segment may also be
distinct. In this case, the number of network segments is multiplied by a weighted coefficient
when the actual length of the path is measured.
Routing through the minimum of routing segments is not always the ideal path. For example,
routing through three high-speed LAN network segments is probably much faster than routing
through two low-speed WAN network segments.
1.3.2 Routing Protocols

As just mentioned, the main functions of a router are route selection and packet forwarding.
Routing protocols are the rules for routers to maintain the routing table. Routing protocols are
used to discover routes, generate routing tables, and guide the forwarding of packets. Routing
protocols can be classified into link-state protocols and distance-vector protocols.
1.3.3 Routing Table and FIB Table

The routing table is used to select routes, and the Forwarding Information Base (FIB) is used to
guide packet forwarding. Each router maintains one routing table and one FIB table at least.
l Routes discovered by various routing protocols are stored in the routing table. According
to the sources, the routes in the routing table are divided into the following types:
Directly connected route or interface route
The directly connected route, in another word, the interface route, refers to the route
discovered by the link layer protocols.
Static route
The static route refers to the route manually configured by the network administrator.
Dynamic route
The dynamic route refers to the route dynamically discovered by dynamic routing
protocols.

l Each entry in the FIB table contains the physical or logical interface through which a packet
is sent to a network segment or a host, and then it can reach the next router. Besides, the
entry also indicates that the packet can be directly sent to a destination host in the directly
connected network.
Routing Table
Each router maintains the protocol routing table for each protocol and a local core routing table
(or routing management table).
l Protocol routing table

A protocol routing table stores the routing information discovered by the protocol.
A routing protocol can import and advertise the routes that are discovered by other
protocols. For example, if a router that runs the Open Shortest Path First (OSPF) protocol
needs to use OSPF to advertise direct routes, static routes, or Intermediate System-
Intermediate System (IS-IS) routes, the router must import the routes to the OSPF routing
table.
l Local core routing table
A router uses the local core routing table to store protocol routes and preferred routes. The
router then delivers the preferred routes to the FIB table to guide the packets forwarding.
The router selects routes according to the priorities of protocols and costs in the routing
table. You can run the display ip routing-table command to view the local core routing
table of a router.
NOTE
The router that supports the Layer 3 Virtual Private Network (L3VPN) maintains a local core routing
table for each VPN instance.
Contents of the Routing Table

In the NE80E/40E, by running the display ip routing-table command, you can view the brief
routing table of the router as below:
<HUAWEI> display ip routing-table
Route Flags: R - relay, D - download to fib
------------------------------------------------------------------------------
Routing Tables: Public
Destinations : 8 Routes : 8
Destination/Mask Proto Pre Cost Flags NextHop Interface
0.0.0.0/0 Static 60 0 D 1.1.4.2 Pos1/0/0

1.1.1.0/24 Direct 0 0 D 1.1.1.1 GigabitEthernet2/0/0
1.1.1.1/32 Direct 0 0 D 127.0.0.1 InLoopBack0
1.1.4.0/30 OSPF 10 0 D 1.1.4.1 Pos1/0/0
1.1.4.2/32 OSPF 10 0 D 1.1.4.2 Pos1/0/0
A routing table has the following key entries:
l Destination address: is used to identify the destination IP address or the destination network
address of an IP packet.
l Network mask: is combined with the destination address to identify the address of the
network segment where the destination host or router resides.

The network address of the destination host or the router is obtained through the "AND"
operation on the destination address and network mask. For example, if the destination
address is 1.1.1.1 and the mask is 255.255.255.0, the address of the network where the
host or the router resides is 1.1.1.0.
The network mask is composed of several consecutive 1s. These 1s can be expressed
either in the dotted decimal notation or in the number of consecutive 1s in the mask.
For example, the network mask can be expressed either as 255.255.255.0 or as 24.
l Proto: indicates the protocol through which routes are learned.
l Pre: indicates the preference added to the IP routing table for a route. To the same
destination, multiple routes with different next hops and outgoing interfaces exist. These
routes may be discovered by different routing protocols, or they may just be the manually
configured static routes. The route with the highest preference (the smallest value) is
selected as the optimal route. .For the preference of each protocol, seeTable 1-1.
l Cost: indicates the route cost. When multiple routes to the same destination have the same
preference, the route with the smallest cost is selected as the optimal route.
NOTE
Preference is used to compare the preferences of various routing protocols, while cost is used to
compare the preferences of different routes of the same routing protocol.
l NextHop: indicates the IP address of the next device that an IP packet passes through.
l Interface: indicates the outgoing interface through which an IP packet is forwarded.
According to the destination, the routes can be divided into the following types:
l Subnet route: The destination is a subnet.
l Host route: The destination is a host.
In addition, based on whether the destination is directly connected to the router or not, routes
fall into the following types:
l Direct route: The router is directly connected to the network in which the destination
resides.
l Indirect route: The router is not directly connected to the network in which the destination
resides.
You can set a default route to reduce the number of entries in the routing table. All the packets
that fail to match entries in the routing table are forwarded through this default route. For
example, in the preceding routing table, the route whose destination address is 0.0.0.0/0 is a
default route.
As shown in Figure 1-2, Router A is connected with three networks, so it has three IP addresses
and three physical interfaces. Figure 1-2 shows the routing table of Router A.

Figure 1-2 Routing table
Routing Table 11.0.0.0/8

Destination Nexthop Interface
11.0.0.0/8 1.1.1.2 GE1/0/0 RouterB
12.0.0.0/8 2.2.2.2 GE2/0/0
1.1.1.2/24
13.0.0.0/8 3.3.3.2 GE3/0/0
GE1/0/0
1.1.1.1/24
GE2/0/0 GE3/0/0
2.2.2.1/24 3.3.3.1/24
RouterA
RouterC RouterD
2.2.2.2/24 3.3.3.2/24
12.0.0.0/8 13.0.0.0/8
Automatic Restoration After the Number of Routes Exceeds the Upper Limit
A local core routing table saves routes of different routing protocols. If the number of routes in
the local core routing table reaches the upper limit, no routes can be added to the table. The local
core routing table has the following route limitations:
l System route limitation
l System route prefix limitation
l Multicast IGP route limitation
l Multi-topology route limitation
l Private network route limitation
l VPN route limitation
l VPN route prefix limitation
If a protocol fails to add routes to the local core routing table due to a specified route limitation,
the system will record the failure with the protocol name and the routing table ID.
After routes of protocols are deleted from the local core routing table, and the number of routes
falls below the upper limit, the system will instruct all the protocols that fail to add routes to the
local core routing table to re-add routes to the local core routing table. This helps restore most
routes in the local core routing table. Whether all routes in the local core routing table can be
restored depends on the size of released routing table space.
Matching of FIB Table

After the route selection is complete, routers deliver the active routes in the routing table to the
FIB table. When receiving a packet, routers search the FIB table for the optimal route to forward
the packet.

The matching of the FIB table complies with the longest match. When searching the FIB table,
routers perform the "AND" operation on the destination address in the packet and the network
mask of each entry in the FIB table. routers then compare the result of the "AND" operation with
the entries in the FIB table. According to the comparison, routers choose the optimal route to
forward packets according to the longest match.
NOTE
For details of the FIB table, refer to the HUAWEI NetEngine80E/40E Router Feature Description IP
Services.
For example, the brief routing table of a router is as follows:

Routing Tables:
Destination/Mask Proto Pre Cost Flags NextHop Interface
0.0.0.0/0 Static 60 0 D 120.0.0.2 Pos1/0/0
8.0.0.0/8 RIP 100 3 D 120.0.0.2 Pos1/0/0
9.0.0.0/8 OSPF 10 50 D 20.0.0.2 Ethernet1/0/0
9.1.0.0/16 RIP 100 4 D 120.0.0.2 Pos2/0/0
20.0.0.0/8 Direct 0 0 D 20.0.0.1 Ethernet2/0/0
NOTE
The complete routing table contains active routes and inactive routes. The brief routing table contains only
active routes. You can run the display ip routing-table verbose command to view the complete routing
table.
After receiving a packet that carries the destination address 9.1.2.1, a router searches the
following table:
FIB Table:
Total number of Routes : 5
Destination/Mask Nexthop Flag TimeStamp Interface TunnelID
0.0.0.0/0 120.0.0.2 SU t[37] Pos1/0/0 0x0
8.0.0.0/8 120.0.0.2 DU t[37] Pos1/0/0 0x0
9.0.0.0/8 20.0.0.2 DU t[9992] Ethernet1/0/0 0x0
9.1.0.0/16 120.0.0.2 DU t[9992] Pos2/0/0 0x0
20.0.0.0/8 20.0.0.1 U t[9992] Ethernet2/0/0 0x0
The router performs the "AND" operation on the destination address 9.1.2.1 and the masks 0,
8, 16, and obtains the network segment addresses: 0.0.0.0/0, 9.0.0.0/8, and 9.1.0.0/16. The three
addresses match the three entries, namely, 0.0.0.0/0, 9.0.0.0/8, and 9.1.0.0/16. At last, the
router chooses the 9.1.0.0/16 entry according to the longest match and forwards the packet
through Pos 2/0/0.
1.3.4 Static Routes and Dynamic Routes

Besides static routes, the NE80E/40E supports dynamic routing protocols, such as RIP, OSPF,
IS-IS, and the Border Gateway Protocol (BGP).
Static routes can be easily configured on a system. They have lower system requirements. Static
routes are applicable to simple, stable, and small-scale networks. Static routes, however, cannot
automatically adapt to the changes of the network topology, so they must be manually
configured.
On the other hand, dynamic routing protocols can automatically adapt to the changes of network
topology by using routing algorithms. They are applicable to the network equipped with enough
Layer 3 devices. The configuration of a dynamic route, however, has a higher requirement for
the system performance and occupies certain network resources.
1.3.5 Classification of Dynamic Routing Protocols

Dynamic routing protocols can be classified based on the following conditions:
According to the Range of Functions

According to the application range, the routing protocols can be divided into the following types:
l Interior Gateway Protocol (IGP): runs inside an AS, such as RIP, OSPF, and IS-IS.
l Exterior Gateway Protocol (EGP): runs between different ASs, such as BGP.
According to the Algorithm

According to the algorithm type, the routing protocols can be divided into the following types:
l Distance-Vector Routing Protocol: includes RIP and BGP (BGP is also called Path-Vector).
l Link-State Routing Protocol: includes OSPF and IS-IS.
The preceding algorithms mainly differ in the methods of route discovery and route calculation.
According to the Types of Destination Addresses

According to the type of the destination address, the routing protocols can be divided into the
following types:
l Unicast routing protocol: includes RIP, OSPF, BGP, and IS-IS.

l Multicast routing protocol: includes Protocol Independent Multicast-Sparse Mode (PIM-
SM) and Protocol Independent Multicast-Dense Mode (PIM-DM).
This manual mainly describes unicast routing protocols. For details of multicast routing
protocols, refer to the HUAWEI NetEngine80E/40E Router Configuration Guide - IP
Multicast.
Static routes and dynamic routes discovered by the routing protocol are managed in the router.
All these routes can be shared among different routing protocols to implement Readvertisement
of Routing Information.
1.3.6 Routing Protocols and Route Preferences
Route Preferences
Different routing protocols (including the static route) can learn different routes to the same
destination, but not all these routes are optimal. At a time, only one routing protocol determines
the optimal route to a destination. To select the optimal route, each of these routing protocols
(including the static route) is configured with a preference. When multiple routing information
sources coexist, the route learned by the routing protocol with the highest preference becomes
the optimal route (the smaller the value is, the higher the preference is). Routing protocols and
the default preferences of the routes learned by the protocols are shown in Table 1-1.
In Table 1-1, 0 indicates the direct route, and 255 indicates any route learned from unreliable
sources. The smaller the value is, the higher the preference is.

Table 1-1 Routing protocols and their default preferences of the routes
Routing Protocol or Route Type Route Preference
DIRECT 0
OSPF 10
IS-IS 15
STATIC 60
RIP 100
OSPF ASE 150
OSPF NSSA 150
IBGP 255
EBGP 255
Except for direct routes, the preferences of the routing protocols can be manually configured.
In addition, the preference for each static route can be distinct.
The NE80E/40E also defines the external preference and internal preference. The external
preference refers to the preference set by users for each routing protocol. Table 1-1 shows the
default external preference.
When different routing protocols are configured with the same preference, the system determines
which routes discovered by these routing protocols become the preferred routes through internal
preference.Table 1-2 shows the internal preferences of routing protocols.
Table 1-2 Internal preferences of routing protocols
Routing Protocol or Route Type Route Preference
DIRECT 0
OSPF 10
IS-IS Level-1 15
IS-IS Level-2 18
STATIC 60
RIP 100
OSPF ASE 150
OSPF NSSA 150
IBGP 200
EBGP 20

For example, two routes, an OSPF route and a static route, can reach the destination 10.1.1.0/24,
and the preferences of the two routes are set to 5. In this case, the NE80E/40E determines the
optimal route according to the internal preferences listed in Table 1-2. The internal preference
(the value is 10) of OSPF is higher than the internal preference (the value is 60) of the static
route. Therefore, the system selects the route discovered by OSPF as the optimal route.
1.3.7 Priority-based Route Convergence
Definition
Priority-based route convergence, providing faster convergence of routes for key services, is an
important technology for improving network reliability.
Different routes can be set with different convergence priorities that can be critical, high,
medium, and low listed in descending order. Critical is the highest convergence priority; low is
the lowest convergence priority. The system then performs route convergence based on the
convergence priorities and a certain convergence rule, that is, schedules the convergence of
routes of different convergence priorities in proportion, for guiding service forwarding.
Purpose
With the integration of network services, it is strongly required that services be differentiated.
As required by operators, the routes for key services, such as Voice over IP (VoIP), video
conferences, and multicast services, should converge as fast as possible while the routes for
common services can be converged relatively slowly. In this manner, the system needs to
converge routes based on their convergence priorities, which improves network reliability.
Principle
The following table shows the default convergence priorities of public routes. The routing
protocols first compute and deliver routes of high convergence priorities to the system. By
default, the system converges routes according to the scheduling weights of the convergence
priorities in the proportion of critical:high:medium:low = 8:4:2:1. The scheduling weights of the
convergence priorities can be configured as required.
Table 1-3 Default convergence priorities of public routes
Routing Protocol or Route Type Convergence Priority
Direct High
Static Medium
32-bit host routes of OSPF and IS-IS Medium
OSPF route (except 32-bit host routes) Low
IS-IS route (except 32-bit host routes) Low
RIP Low
BGP Low

NOTE
For private routes, only 32-bit host routes of OSPF and IS-IS can be identified as medium and all other
routes are identifies as low.
1.3.8 Load Balancing and Route Backup
Load Balancing
The NE80E/40E supports the multi-route mode. That is, users can configure multiple routes with
the same destination and the same preference. If the destinations and costs of the multiple routes
discovered by a routing protocol are the same, load balancing can be performed among the routes.
In each protocol view, you can run the maximum load-balancing number command to perform
load balancing. The load balancing is classified into the following types:
l Packet-by-packet load balancing
When the packet-by-packet load balancing is configured, routers at the network layer
forward packets to the same destination through various equal-cost paths. That is,routers
always choose the next hop address that is different from the last one to send packets. In
this way, the load balancing, that is, packet-by-packet load balancing, is implemented.
Figure 1-3 shows the packet-by-packet load balancing.
Figure 1-3 Networking diagram of packet-by-packet load balancing
POS1/0/0 RouterB
P1, P3, P5 10.1.1.0/24

RouterA
P2, P4, P6
RouterD
POS2/0/0
RouterC
Router A forwards packet to the destination address 10.1.1.0/24. Packets P1, P2, P3, P4,
P5, and P6 need to be forwarded to the destination. The procedure for sending these packets
is as follows:
Sending P1 through POS1/0/0
Router A sends packets to the destination address 10.1.1.0/24 alternatively through the two
interfaces.
l Session-by-session load balancing

When the session-by-session load balancing is configured, routers forward packets

according to the source address, destination address, source port, destination port, and
protocol contained in the packets. When the five factors are the same, routers always choose
the next hop address the same as the last one to send packets. Figure 1-4 shows the session-
by-session load balancing.
Figure 1-4 Networking diagram of session-by-session load balancing
RouterB
POS1/0/0
10.1.1.0/24
P1-P6 10.1.1.0/24
RouterA 10.2.1.0/24
10.2.1.0/24
P1-P6 RouterD
POS2/0/0
RouterC
Router A forwards packets to the destinations at 10.1.1.0/24 and 10.2.1.0/24 respectively.

The routing policy of the session-by-session load balancing is that packets in the same flow
are always transmitted along the previous path. The process for Router A to forward packet
is as follows:
The first packet P1 to the destination address 10.1.1.0/24 is forwarded through POS
1/0/0, so packets to the destination are forwarded through the interface.
The first packet P1 to the destination address 10.2.1.0/24 is forwarded through POS
2/0/0, so packets to the destination are forwarded through the interface.
NOTE
By default, the NE80E/40E adopts the session-by-session load balancing. You can run the load-
balance packet command to change the load balancing mode to packet-by-packet load balancing.
In real application, the protocols that support load balancing are RIP, OSPF, BGP, and IS-IS.
Besides, static routes also support load balancing.
NOTE
The number of equal-cost routes among which load balancing is performed varies with the product.
1.3.9 Principle of IP FRR
IP FRR Overview
FRR refers to the mechanism that a fault detected at the physical layer or data link layer is
reported to the upper-layer routing system, and a backup link is immediately used to forward
packets.

Background of IP FRR
On traditional IP networks, when a fault occurs at the lower layer of the forwarding link, the
visible evidence is that the physical interface on the router becomes Down. After the router
detects the fault, it informs the upper layer routing system to recalculate routes and then update
routing information. Usually, it takes the routing system several seconds to re-select an available
route.
For services that require a low delay and low packet loss ratio, the convergence time of several
seconds is intolerant because it may lead to service interruption. For example, Voice over Internet
Protocol (VoIP) services are tolerant to interruption in milliseconds. IP FRR ensures that the
forwarding system swiftly detects such a fault and then takes measures to restore services as
soon as possible.
Classification and Implementation of IP FRR

IP FRR, which is designed for routes on IP networks, is classified into IP FRR for the public
network and IP FRR for the private network.
l IP FRR for the public network: protects routers of the public network.
l IP FRR for the private network: protects CEs.
IP FRR is implemented as follows:
l If the primary link is available, you can configure IP FRR by using a routing policy to
provide the forwarding information of the backup route for the forwarding engine.
l If the forwarding engine is notified of a link fault, the engine uses the backup link to forward
traffic before the routes on the control plane converge.
Comparison Between IP FRR and VPN FRR
Table 1-4 Comparison Between IP FRR and VPN FRR

Item Description
IP FRR IP FRR is suitable for IP services that require a low delay and low packet loss
ratio.
l Protects the public network and CEs.
l Implements FRR through a backed up route.
VPN FRR VPN FRR is suitable for services that require a low delay and low packet loss
ratio on VPNs.
l Protects PEs.
l Implements FRR through a backup tunnel.

Comparison Between IP FRR and Load Balancing
Table 1-5 Comparison Between IP FRR and Load Balancing

Item Description
IP FRR Implements FRR through a backed up route. IP FRR is applicable to single-

link networking without load balancing.
Load Implements fast route switching through equal-cost routes. Load balancing
balancing is applicable to multi-link networking with load balancing.
1.3.10 Re-advertisement of Routing Information

The algorithm of each routing protocol is distinct. Therefore, different protocols may discover
different routes. If the scale of the network is large and multiple protocols are run in the network,
the protocols need to re-advertise the routes discovered by each of them.
In the NE80E/40E, the routes discovered by a protocol can be imported to the routing table of
other protocols. Each protocol has the mechanism to import routes. For details, refer to the
chapter "Routing Policy".
1.3.11 Indirect Next Hop

Definition
Indirect next hop can change the direct association between route prefixes and the next hop into
an indirect association. Then, next hop information can be refreshed independently, the prefixes
of the same next hop need not be refreshed one by one, and thus route convergence is speeded
up.
Purpose
In the scenario in need of route iteration, when IGP routes or tunnels are switched, FIB entries
are quickly refreshed. This implements traffic fast convergence and reduces the impact on
services.
Mapping Between the Route Prefix and the Next Hop

The mapping between the route prefix and the next hop is the basis of indirect next hop. To meet
the requirements of route iteration and tunnel iteration in different scenarios, next hop
information involves the address family, the original next hop address, or the tunnel policy. The
system assigns an index to information about each next hop, performs route iteration, and then
notifies the iteration result to the route protocol and distributes FIB entries.
On-Demand Route Iteration

On-demand route iteration indicates that when a dependent route is changed, only the next hop
related to the dependent route is re-iterated. If the destination address of a route is the original
next hop address or network segment address of next hop information, route changes affect the
iteration result of next hop information. Otherwise, route changes do not affect next hop

information. Therefore, when a route changes, you can re-iterate only the related next hop by
judging the destination address of the route.
With respect to tunnel iteration, when a tunnel alternates between up and down, you just need
to re-iterate the next hop information whose next hop address is the same as the destination
address of the tunnel.
Iteration Policy
An iteration policy is used to control the iteration result of the next hop to meet the requirements
of different application scenarios. In route iteration, iteration behaviors do not need to be
controlled by the iteration policy. Instead, iteration behaviors only needs to comply with the
longest matching rule. What is more, the iteration policy needs to be applied only when VPN
routes iterate tunnels.
By default, the system selects LSPs for a VPN without performing load balancing. If load
balancing or other types of tunnels are required, you need to configure a tunnel policy and bind
the tunnel policy to a tunnel. After a tunnel policy is applied, the system adopts the tunnel bound
in the tunnel policy or selects a tunnel according to the priorities of different types of tunnels.
Refreshment of Indirect Next Hop

On the forwarding plane, public network routes are forwarded based on the next hop and
outbound interface while VPN routes are forwarded based on the public network tunnel in
addition to the next hop and outbound interface. Before indirect next hop is adopted, forwarding
information, including the next hop, outbound interface, and the tunnel token, needs to be added
into the FIB entry by using the route prefix. In this manner, the route convergence speed is
relevant to the number of route prefixes. After indirect next hop is adopted, many route prefixes
corresponds to a shared next hop. Forwarding information is added into the FIB entry by using
the next hop, and the traffic with the relevant route prefixes can be switched simultaneously.
Therefore, the route convergence speed becomes faster.
Figure 1-5 Schematic diagram before indirect next hop is adopted
Forwarding
Prefix 1 Nexthop 1
Information 1
Forwarding
Prefix 2 Nexthop 2
Information 2

Forwarding
Prefix N Nexthop N
Information N
As shown in Figure 1-5, before indirect next hop is adopted, prefixes are totally independent,
each corresponding to its next hop and forwarding information. When a dependent route changes,
the next hop corresponding to each prefix is iterated and forwarding information is updated based
on the prefix. In this case, the convergence speed is related to the number of prefixes.

Actually, prefixes of a BGP neighbor have the same next hop, forwarding information, and
refreshed forwarding information.
Figure 1-6 Schematic diagram after indirect next hop is adopted
Prefix 1
Forwarding
Prefix 2 Nexthop
Information
Prefix N
As shown in Figure 1-6, after indirect next hop is adopted, prefixes of a BGP neighbor share a
next hop. When a dependent route changes, only the shared next hop is iterated and forwarding
information is updated based on the next hop. In this case, traffic of all prefixes can be converged
at a time. The convergence speed is irrelevant to the number of prefixes.
Comparison Between Route Iteration and Tunnel Iteration

Comparison between route iteration and tunnel iteration is shown in the following table.
Table 1-6 Comparison between route iteration and tunnel iteration

Iteration Type Description
Route iteration l Iterating BGP public routes.

l It is triggered by route changes.
l It supports next-hop iteration based on the specified
routing policy.
Tunnel iteration l Iterating BGP VPN routes.

l It is triggered by tunnel changes or tunnel policy changes.
l Iteration behaviors can be controlled through the tunnel
policy to meet the requirements of different application
scenarios.
1.3.12 Default Routes

Default routes are special routes. Generally, administrators can manually configure default static
routes. Default routes can also be generated through dynamic routing protocols such as OSPF
and IS-IS.
Default routes are used only when packets to be forwarded have no matching routing entry in a
routing table. In the routing table, a default route is the route to the network 0.0.0.0 (with the
mask also being 0.0.0.0). You can check whether the default route is configured by using the
display ip routing-table command.

If the destination address of a packet does not match any entry in the routing table, the packet
is sent through a default route. If no default route exists and the destination address of the packet
does not match any entry in the routing table, the packet is discarded. An Internet Control
Message Protocol (ICMP) packet is then sent, informing the originating host that the destination
host or network is unreachable.
1.3.13 Multi-Topology
On a traditional IP network, only one unicast topology exists, and only one unicast forwarding
table exists on the forwarding plane. Services to the same destination address share the same
per-hop forwarding behavior. This means that various end-to-end services share the same
physical link. Some links may be heavily congested while other links are relatively idle.
A solution to this problem is to divide a physical network into different logical topologies for
different services. Such a solution is called multi-topology.
Multi-topology can enable an interface to function in different logical network topologies by
creating a separate routing table for each topology. Multi-topology solves the problem of
insufficient interfaces and is useful in complex network topologies.
Application
Multi-topology is usually applicable to multicast services.
The multicast RPF check depends on the unicast routing table. If multicast uses the default
unicast routing table, the following problems must be addressed:
l Multicast depends heavily on unicast routes. As a result, unicast route changes affect the
establishment of a Multicast Distribution Tree (MDT).
l Multicast depends on unicast routes to establish the MDT.
With multi-topology, the system generates a separate multicast multi-topology routing table for
each logical topology so that multicast routing no longer completely depends on the unicast
routing table. The preceding problems are thus addressed.
NOTE
The detailed information about multicast multi-topology refers to "HUAWEI NetEngine80E/40E Router
Feature Description - IP Multicast".
1.3.14 VRRP for Direct Routes

On the IP RAN shown in Figure 1-7, an L2VPN uses a virtual Ethernet (VE) interface to connect
to an L3VPN. If UPE1 recovers from a fault and traffic travels only from the L3VPN to the
L2VPN, UPE1 copies unknown unicast packets to every AC interface as UPE1 does not learn
the RSG's MAC address, deteriorating forwarding performance.
After UPE1 recovers from a fault, UPE1's interface connected to the RSG goes Up, but UPE1
needs to be able to use its interface to forward traffic only after learning the RSG's MAC address.
This requires that UPE1's interface be associated with the VRRP status, allowing UPE1 to
advertise the interface's direct route based on the VRRP status.

Figure 1-7 Networking diagram for VRRP for direct routes
UPE1 RSG1
CSG
NodeB RNC
UPE2 RSG2
L2VPN L3VPN
VRRP for direct routes allows the cost of a direct route to the network segment where the
interface associated with the VRRP backup group resides to change based on the VRRP status.
The cost change affects whether or not the direct route is an optimal route. The VRRP status
changes during a master/backup switchover. If an interface is associated with a VRRP backup
group, the cost of the direct route to the network segment where the interface resides changes
based on the VRRP status.
If VRRP for direct routes is configured, the direct route's priority changes based on the direct
route's cost:
l If the VRRP status becomes Backup, the direct route's cost increases, lowering the direct
route's priority. The direct route will no longer be an optimal route.
l If the VRRP status becomes Master, the direct route's cost is set to 0, allowing the direct
route's priority to be the highest. The direct route will be an optimal route.
You can set the interval, at which a VRRP Advertisement packet is sent, to determine the time
the VRRP status changes from Backup to Master.
NOTE
For detailed information about VRRP, refer to the HUAWEI NetEngine80E/40E Router Feature
Description - Reliability. For information about an IP RAN, refer to the HUAWEI NetEngine80E/40E
Router Feature Description - VPN.
On the network shown in Figure 1-7, after VRRP for direct routes is deployed, if UPE1 recovers
from a fault, UPE1 determines whether or not to advertise the direct route between UPE1 and
the RSG based on the VRRP status. If the VRRP status becomes Backup, the direct route's cost
decreases so that the direct route will no longer be an optimal route. If the VRRP status becomes
Master, the direct route's cost is automatically set to 0 to allow the direct route's priority to be
the highest so that the direct route will become the optimal route.
1.4 Applications

1.4.1 Typical Application of Priority-based Route Convergence

Figure 1-8 shows the networking for multicast services. An IGP runs on the network; the receiver
is at Router A; the multicast source server 10.10.10.10/32 is at Router B. It is required that the
route to the multicast source server be converged faster than other routes, such as 12.10.10.0/24.
In this case, you can set the convergence priority of 10.10.10.10/32 higher than that of
12.10.10.0/24. Then, when routes are converged on the network, the route to the multicast source
server 10.10.10.10/32 is converged first. This ensures the transmission of multicast services.
Figure 1-8 Networking for priority-based route convergence
IS-IS
12.10.10.0/24
OSPF
OSPF
10.10.10.10/32
User RouterA RouterB Source
1.4.2 Typical Application of IP FRR

As shown in Figure 1-9, IP FRR is configured to improve network reliability. CE1 is dual-
homed to PE1 and PE2. CE1 is configured with two outbound interfaces and two next hops.
That is, link B functions as the backup of link A. When link A fails, traffic can be rapidly switched
to link B.
Figure 1-9 Configuring the IP FRR function
IP forwarding
Link A PE1
CE1 Link B
IP forwarding
PE2

1.4.3 Typical Application of Indirect Next Hop

Indirect Next Hop Enabled When IBGP Routes Are Iterated to an IGP Route
Figure 1-10 Networking diagram of IBGP route iteration
AS100
IGP IGP
RouterB
IBGP
RouterA RouterD
IGP IGP
RouterC
As shown in Figure 1-10, Router A and Router D establish an IBGP neighbor relationship. To
refresh FIB entries and guide the packet forwarding, the real outbound interface and the directly
connected next hop must be identified based on the original IBGP next hop. Note that the next
hop of an IBGP route cannot be used to guide packet forwarding, because the IBGP neighbor
relationship is generally established through two loopback interfaces, and the next hop is not
directly reachable.
Router D receives 4 thousand routes from Router A. These routes have the same original BGP
next hop. After being iterated, these routes eventually follow the same IGP path (A->B->D).
When the IGP path (A->B->D) fails, these IBGP routes need not be iterated separately, and the
relevant FIB entries need not be refreshed one by one. Actually, only the shared next hop need
be iterated and refreshed. Consequently, these IBGP routes can be converged to the path (A->C-
> D) at a time in the forwarding plane. Thus, convergence time is related only to the number of
next hops, and sub-second convergence that is irrelevant to the number of prefixes is
implemented.
If Router A and Router D establish a multi-hop EBGP neighbor relationship, the convergence
procedure is the same as the previous procedure. Next hop separation also applies to multi-hop
EBGP route iteration.

Indirect Next Hop Enabled When VPN Routes Are Iterated to a Tunnel
Figure 1-11 Networking diagram of VPN route iteration
AS100
P1
Tunnel1
CE1 Tunnel2 CE2

PE1 PE2
AS65001 AS65002
P2
As shown in Figure 1-11, PE1 and PE2 establish a neighbor relationship and PE2 receives 4
thousand routes from PE1. These routes have the same original BGP next hop. After being
iterated, these private routes eventually follow the same network public tunnel, namely, tunnel
1. When tunnel 1 fails, these routes need not be iterated separately, and the FIB entries need not
be refreshed one by one. Actually, only the shared next hop need be iterated, and the relevant
FIB entries need be refreshed. Consequently, these VPN routes can be converged to tunnel 2 at
a time in the forwarding plane. Thus, convergence time is related only to the number of next
hops, and sub-second convergence that is irrelevant to the number of prefixes is implemented.

Terms
Term Description
FRR FRR is applicable to services that are very sensitive to packet loss and delay. When
a fault is detected at the lower layer, the lower layer informs the upper layer routing
system of the fault. Then, the routing system forwards packets through a backup
link. In this manner, the impact of the link fault on services is minimized.
Abbreviations
Abbreviation Full Spelling
BGP Border Gateway Protocol
CE Customer Edge
FIB Forwarding Information Base
IBGP Internal Border Gateway Protocol

IGP Internal Gateway Protocol
IS-IS Intermediate System-Intermediate System
OSPF Open Shortest Path First
PE Provider Edge
RIP Routing Information Protocol
RM Route Management
VoIP Voice Over IP
VPN Virtual Private Network
VRP Versatile Routing Platform

Feature Description - IP Routing 2 Static Route
2 Static Route
About This Chapter
2.1 Introduction to Static Routes

2.2 References
2.3 Principles

2.1 Introduction to Static Routes

Definition
Static routes need to be manually configured by the administrator.
Purpose
On a simple network, the administrator just needs to configure static routes so that the network
can run properly. Properly configuring and using static routes can improve network performance
and guarantee the required bandwidth for important applications.
When a network fault occurs or the network topology changes, however, static routes cannot
automatically change and must be changed manually by the administrator.
The HUAWEI NetEngine80E/40E supports common static routes and the static routes
associated with Virtual Private Network (VPN) instances. The static routes associated with VPN
instances are used to manage VPN routes. For details of VPN instances, see the HUAWEI
NetEngine80E/40E Router Feature Description - VPN.
2.2 References
None.
2.3 Principles
2.3.1 Components of Static Routes

On the NE80E/40E, you can run the ip route-static command to configure a static route, which
consists of the following:
l Destination Address and Mask
l Outbound Interface and Next-Hop Address
Destination Address and Mask

In the ip route-static command, the IPv4 address is expressed in dotted decimal notation, and
the mask is expressed in dotted decimal notation or represented by the mask length (the number
of consecutive 1s in the mask).
Outbound Interface and Next-Hop Address

When configuring a static route, you can specify an outbound interface, a next-hop address, or
both the outbound interface and the next hop-address as required.
Actually, each routing entry requires a next-hop address. Before sending a packet, a device needs
to search its routing table for the route matching the destination address in the packet by using
the longest match rule. The device can find the associated link layer address to forward the packet
only after the next-hop address of the packet is specified.

When specifying an outbound interface, note the following:
l For a Point-to-Point (P2P) interface, the next-hop address is specified after you specify the
outbound interface. That is, the address of the remote interface connected to this interface
is the next-hop address. For example, when a POS interface is encapsulated with the Point-
to-Point Protocol (PPP) and obtains the remote IP address through PPP negotiation, you
need to specify only the outbound interface rather than the next-hop address.
l Non-Broadcast Multiple-Access (NBMA) interfaces (such as an ATM interface) are
applicable to Point-to-Multipoint (P2MP) networks. Therefore, IP routes and the mappings
between IP addresses and link layer addresses are required. In this case, you need to
configure next-hop addresses.
l During static route configuration, specifying the next hops of static routes is recommended
when broadcast interfaces (such as Ethernet interfaces) and Virtual-Template (VT)
interfaces are as outbound interfaces of these static routes. This is because an Ethernet
interface is a broadcast interface and a VT interface can be associated with several virtual
access (VA) interfaces. If the Ethernet interface or the VT interface is specified as the
outbound interface, a unique next hop cannot be determined because multiple next hops
exist. In actual applications, to specify a broadcast interface (such as an Ethernet interface)
or a VT interface as the outbound interface, you are recommended specify the associated
next-hop address.
2.3.2 Applications of Static Routes

As shown in Figure 2-1, the network topology is simple, and network communication can be
implemented through static routes. It is required to specify an address for each physical network,
identify indirectly-connected physical networks for each router, and configure static routes for
the indirectly-connected physical networks.
Figure 2-1 Networking diagram of static routes
2 RouterB 4
1 5
RouterA RouterC
In Figure 2-1, static routes to networks 3, 4, and 5 need to be configured on Router A; static
routes to networks 1 and 5 need to be configured on Router B; static routes to networks 1, 2, and
3 need to be configured on Router C.
Default Static Route

When the ip route-static command is run to configure a static route, if the destination address
and the mask are set to all 0s (0.0.0.0 0.0.0.0), it indicates that a default route is configured. This
simplifies the network configuration.

In Figure 2-1, because the next hop of the packets sent by Router A to networks 3, 4, and 5 is
Router B, a default route can be configured on Router A to replace the three static routes destined
for networks 3, 4, and 5 in the preceding example. Similarly, only a default route from Router
C to Router B needs to be configured to replace the three static routes destined for networks 1,
2, and 3 in the preceding example.
Floating Static Routes

Different static routes can be configured with different preferences so that routing management
policies can be flexibly applied. Specifying different preferences for multiple routes to the same
destination can implement route backup.
As shown in Figure 2-2, there are two static routes from Router A to Router C. Normally, in
the routing table, only the static route with the next hop being Router B is in the Active state
because this route has a higher preference. The other static route with the next hop being
Router D functions as a backup route. The backup route is activated to forward data only when
the primary link becomes faulty. After the primary link recovers, the static route with the next
hop being Router B becomes active to forward data. Therefore, the backup route is also called
a floating static route. The floating static route becomes ineffective when a fault occurs on the
link between Router B and Router C.
Figure 2-2 Networking diagram of a floating static route

RouterB
Preference=60
Preference=100
RouterA RouterC
RouterD
Load Balancing Among Static Routes

Specifying the same preference for multiple routes to the same destination can implement load
balancing.
As shown in Figure 2-3, there are two static routes with the same preference from Router A to
Router C. The two routes exist in the routing table and forward data at the same time.

Figure 2-3 Load balancing among static routes

RouterB
Preference=60
Preference=60
RouterA RouterC
RouterD
2.3.3 Functions of Static Routes
IPv4 Static Routes

The NE80E/40E supports common static routes and the static routes associated with VPN
instances. The static routes associated with VPN instances are used to manage VPN routes. For
details of VPN instances, see the HUAWEI NetEngine80E/40E Router Feature Description -
VPN.
Attributes and Functions of IPv6 Static Routes

Similar to IPv4 static routes, IPv6 static routes need to be manually configured by the
administrator. IPv6 static routes are applicable to simple IPv6 networks.
The major difference between IPv6 static routes and IPv4 static routes lies in their destination
addresses and next-hop addresses. IPv6 static routes use IPv6 addresses, whereas IPv4 static
routes use IPv4 addresses.
During the configuration of an IPv6 static route, if the specified destination address is ::/0 (the
mask length is 0), it indicates that a default IPv6 route is configured. If the destination address
of a packet fails to match any entry in the routing table, a router selects the default IPv6 route
to forward the IPv6 packet.
2.3.4 BFD for Static Routes

Different from dynamic routing protocols, static routes do not have a detection mechanism. As
a result, when a fault occurs on the network, the administrator needs to handle it. Bidirectional
Forwarding Detection (BFD) for static route is introduced to bind a static route to a BFD session
so that the BFD session can detect the status of the link where the static route resides.
After BFD for static route is configured, each static route can be bound to a BFD session.
l If the BFD session on the link of a static route detects that the link changes from Up to
Down, BFD reports it to the system. Then, the system deletes the route from the IP routing
table.

l When a BFD session is established on the link of a static route or the BFD session changes
from Down to Up, BFD reports it to the system. Then, the system adds the route to the IP
routing table.
BFD for static route has two modes:
l Single-hop detection
For a non-iterated static route, the configured outbound interface and next-hop address are
the information about the directly connected next hop. In this case, the outbound interface
bound to the BFD session is the outbound interface of the static route, and the peer address
is the next-hop address of the static route.
l Multi-hop detection
For an iterated static route, only the next-hop address is configured. Therefore, the directly
connected next-hop and outbound interface need to be iterated. In this case, the peer address
of the BFD session is the original next-hop address of the static route, and the outbound
interface is not specified. Generally, the original next hop to be iterated is an indirect next
hop. Therefore, multi-hop detection is performed on the static routes that support route
iteration.
NOTE
If the next hop of a route is not directly reachable, the route cannot be used for packet forwarding. Based
on information about the current next hop of this route, the system will calculate an actual outbound
interface and an actual next hop. This process is called route iteration. In the display ip routing-table
command output, if the Flags value of a route is displayed R, the route is an iterated route. Otherwise, the
route is not an iterated route.
NOTE
For details of BFD, see the HUAWEI NetEngine80E/40E Router Feature Description - Reliability.
2.3.5 NQA for IPv4 Static Routes

Static routes can be configured on networks with simple topologies or for Routers that cannot
run dynamic routing protocols to generate routes to the destination. Unlike dynamic routing
protocols, static routes do not have a dedicated detection mechanism. After a fault occurs, the
corresponding static route cannot be automatically deleted from the IP routing table. This delays
the link switchover and probably interrupts services for a comparatively long time. The network
administrator must delete the corresponding static route to allow traffic to switch to an available
path.
An effective method is required to detect faults in links related to static routes. BFD for static
routes is applicable to the scenario where both communicating devices support BFD.
NQA for IPv4 static routes is available if either of the two communicating devices supports
NQA, and can be used to detect faults in links where Layer 2 devices reside.
NQA for IPv4 static routes refers to the association between a static route and an NQA test
instance. By using the NQA test instance to check the status of the link related to the static route,
the system can determine an optimal route in time according to the NQA test result. This prevents
communication interruption and ensures the service quality. NQA for IPv4 static routes functions
as follows:
l If NQA detects a fault in the link, the system sets the static route to inactive. The route
becomes unavailable and is deleted from the IP routing table.
l If NQA finds that the link recovers, the system sets the static route to active. The route
becomes available and is added to the IP routing table.

NOTE
Each static route can be associated with only one NQA test instance.
For details about NQA, see the HUAWEI NetEngine80E/40E Router Feature Description - System
Management.
Applications
On the network shown in Figure 2-4, each access switch provides access services for 10 users,
and a total number of 100 users are connected to the network. Because dynamic routing protocols
are unavailable for communication between Router B and users, static routes destined for users
are configured on Router B. Router C, functioning as the backup for Router B, are configured
with static routes to the same destination for network stability. Router A, Router B, and
Router C run a dynamic routing protocol to learn routes from each other. Router B and Router
C import static routes by using a dynamic routing protocol and have different costs for these
static routes. After the configuration is complete, Router A can use the dynamic routing protocol
to learn routes destined for users from Router B and Router C. Router A uses the link related to
the static route with a lower cost as the active link and the other link as the standby link.
NQA for IPv4 static routes is configured on Router B. NQA tests are performed to check the
active link of Router B Switch A Switch C (Switch D). If the active link fails, the
corresponding static route is deleted from the routing table, and traffic diverts to the standby
link of Router C Switch B Switch C (Switch D). If both links work properly, traffic travels
along the active link.
Figure 2-4 Networking diagram for applying NQA for IPv4 static routes
IP Network
GE2/0/0
GE1/0/0 172.16.4.1/24
172.16.3.1/24
GE2/0/0 GE2/0/0
172.16.3.2/24 RouterA 172.16.4.2/24
GE1/0/0 GE1/0/0
172.16.1.1/24 RouterB RouterC 172.16.2.1/24
SwitchA SwitchB
GE1/0/0 GE1/0/0
172.16.1.2/24 172.16.2.2/24
......
GE2/0/0 GE2/0/0
172.16.1.3/24 SwitchC SwitchD 172.16.2.3/24
...... ......
Client1 Client10 Client91 Client100

2.3.6 Permanent Advertisement of Static Routes

Link connectivity determines the stability and availability of a network. Therefore, link detection
plays an important role in network maintenance. BFD, as a link detection mechanism, is
inapplicable to certain scenarios. For example, a simpler and more natural method is required
for link detection between different ISPs.
Permanent advertisement of static routes provides a low-cost and simple link detection
mechanism and improves the compatibility between Huawei devices and non-Huawei devices.
If service traffic needs to be forwarded along a specified path, you can detect the connectivity
of links by pinging the destination addresses of static routes. In this manner, you can monitor
services.
After permanent advertisement of static routes is configured, the static routes that cannot be
advertised are still preferred and added to the routing table in the following cases:
l If an outbound interface configured with an IP address is specified for a static route, the
static route is always preferred and added to the routing table regardless of whether the
outbound interface is Up or Down.
l If no outbound interface is specified for a static route, the static route is always preferred
and added to the routing table regardless of whether the static route can be iterated to an
outbound interface.
By controlling the preference and prefix length of a static route, you can enable IP packets to be
always forwarded through this static route. In this manner, you can detect the link connectivity.
NOTE
A device enabled with this feature always stores static routes in its IP routing table, regardless of whether
the static routes are reachable. If a path is unreachable, the corresponding static route may become a
blackhole route.
Applications
As shown in Figure 2-5, BR1, BR2, and BR3 belong to ISP1, ISP2, and ISP3 respectively. There
are two links, Link A and Link B, between BR1 and BR2. ISP1, however, requires that service
traffic be forwarded to ISP2 over Link A without traveling through ISP3.

Figure 2-5 Networking diagram for applying permanent advertisement of static routes
ISP2
10.1.1.2/24 BR2
LinkA
BR1
ISP1
LinkB
BR3
ISP3
The EBGP peer relationship is established between BR1 and BR2. For service monitoring, a
static route destined for the BGP peer (BR2) at 10.1.1.2/24 is configured on BR1, and permanent
advertisement of static routes is enabled. The interface connecting BR1 to BR2 is specified as
the outbound interface of the static route. Then, the network monitoring system periodically
pings 10.1.1.2 to determine the status of Link A according to the ping result. This helps monitor
the status of BGP services.
If Link A works properly, ping packets are forwarded over Link A. If Link A becomes faulty,
the static route is still preferred because its preference is higher though service traffic can reach
BR2 over Link B. Therefore, ping packets are still forwarded over Link A, but packet forwarding
fails. This process is also applicable to BGP packets. That is, a link fault causes the BGP peer
relationship to be interrupted; the monitoring system detects service faults according to the ping
result and prompts maintenance engineers to rectify the faults in time.

Terms
Term Description
FRR Fast Reroute is applicable to the services that are very sensitive to packet loss and
delay. After FRR is configured, when a fault is detected at the lower layer, the fault
is reported to the upper-layer routing system. Then, packets are forwarded through
a backup link. Therefore, the impact of link faults on the carried services is
minimized.

Abbreviations
Abbreviatio Full Spelling
n
BFD Bidirectional Forwarding Detection
RM Route Management

Feature Description - IP Routing 3 RIP
3 RIP
About This Chapter
3.1 Introduction to RIP

3.2 References
3.3 Principles

3.1 Introduction to RIP

Definition
RIP is short for Routing Information Protocol. RIP is a simple Interior Gateway Protocol, mainly
used in small-scale and simply-structured networks such as campus networks and regional
networks. RIP is not suitable for complex environments or large-scale networks.
RIP is based on the Distance-Vector (DV) algorithm. It exchanges routing information through
User Datagram Protocol (UDP) packets. The port number used by RIP is 520.
RIP employs 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 network that is reachable 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 the convergence, RIP defines the HC as an integer that ranges from 0 to
15. The HC equal to or greater than 16 is defined as infinity, that is, the destination network or
the host is unreachable. RIP, therefore, is not applied to large-scale networks.
To improve the performance and to prevent routing loops, RIP supports split horizon and poison
reverse.
Purpose
As an earliest IGP, RIP is used in small-scale networks that support RIP. The implementation
of RIP is simple. The configuration and maintenance of RIP are easier than those of the Open
Shortest Path First (OSPF) and Intermediate System-to-Intermediate System (IS-IS) protocols.
RIP is thus widely used.
3.2 References
The following table lists the references of this document.
Document Description Remar

ks
RFC1058 This document describes RIP protocol, describes the -

elements, characteristic, limitation of RIP version 1.
RFC2453 This document specifies an extension of the Routing -

Information Protocol (RIP), as defined in [1], to expand
the amount of useful information carried in RIP
messages and to add a measure of security.
3.3 Principles
RIP is based on the Distance-Vector (DV) algorithm. It forwards packets through User Datagram
Protocol (UDP). RIP uses three timers to guarantee advertisement, update, and aging of routing
information. To maximumly avoid loops that may caused by RIP defects, RIP supports three
features: split horizon, poison reverse, and triggered update.

In addition, RIP periodically advertises its routing table to neighbors, and thus it uses RIP route
convergence to minimize the routing table.
3.3.1 RIP-1
RIP-1, that is, RIP version 1, is a classful routing protocol. It supports the advertisement of
protocol packets only in broadcast mode. Figure 3-1 shows the packet format.A RIP packet can
carry a maximum of 25 entries. RIP is based on UDP, and a RIP-1 data packet cannot be longer
than 512 bytes. The RIP-1 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. RIP-1, therefore,
does not support route aggregation or discontinuous subnet.
Figure 3-1 RIP-1 packet format

0 7 15 31
Header Command Version Must be zero
Address family identifier Must be zero
IP address
Route
Entries Must be zero
Must be zero
Metric
3.3.2 RIP-2
RIP-2, that is, RIP version 2, is a classless routing protocol. Figure 3-2 shows the packet format.
Figure 3-2 RIP-2 packet format

0 7 15 31
Header Command Version Must be zero
Address Family Identifier Route Tag
IP Address
Route
Subnet Mask
Entries
Next Hop
Metric
Compared with RIP-1, RIP-2 has the following advantages:
l It supports route tag and can flexibly control routes on the basis of the tag in the routing
policy.
l Its packets contain mask information and support route aggregation and Classless Inter-
domain Routing (CIDR).

l It supports the next hop address and can select the optimal next hop address in the broadcast
network.
l It uses multicast routes to send update packets. Only RIP-2 routers can receive protocol
packets. This reduces the resource consumption.
l To enhance the security, RIP-2 provides two authentication modes to enhance security:
plain-text authentication and MD5 authentication.
3.3.3 Timer
RIP mainly uses three timers:
l Update timer: The timer triggers the sending of update packets every 30s.
l Age timer: If a RIP router does not receive any update packet from its neighbors in the
aging time, the RIP router considers the route to its neighbors unreachable.
l Garbage-Collect timer: If the route is no longer valid after the timer times out, the entry is
removed from the RIP routing table.
The following describes the relationship among the three timers:
The advertisement of RIP routing update is triggered by the update timer every 30 seconds. Each
entry is associated with two timers, the age timer and the garbage-collect timer. When a route
is learned and added in the routing table, the age timer is initialized. If no Update packet is
received from the neighbor for 180 seconds, the metric of the route is set to 16 (specifying the
route as unreachable). At the same time, the garbage-collect timer is initialized. If no Update
packet is received for 120 seconds, the entry is deleted after the garbage-collect timer times out.
3.3.4 Split Horizon

The principle of split horizon is that a route learnt by RIP on an interface is not sent to neighbors
from the interface. This reduces bandwidth consumption and avoids route loops.
Figure 3-3 Schematic diagram of split horizon
10.0.0.0/2
RouterA RouterB
10.0.0.0/2
As shown in Figure 3-3, Router B sends a route to 10.0.0.0 to Router A and Router A does not
send the route back to Router B.
3.3.5 Poison Reverse

The principle of poison reverse is that RIP sets the cost of the route learnt from an interface of
a neighbor to 16 (specifying the route as unreachable) and then sends the route from the interface
back to the neighbor. In this way, RIP can delete useless routes from the routing table of the
neighbor.
Poison reverse of RIP can also avoid route loops.

Figure 3-4 Schematic diagram of poison reverse

10.0.0.0/8
cost=16
RouterA RouterB
cost=1
10.0.0.0/8
As shown in Figure 3-4, if poison reverse is not configured, Router B sends Router A a route
that is learnt from Router A and the cost of the route from Router A to network 10.0.0.0 is 1. If
the route from Router A to network 10.0.0.0 is unreachable and Router B keeps sending Router
A routes to network 10.0.0.0 because Router B fail to receive the route update packet from Router
A, a route loop forms.
If Router A sends Router B a message that the route is unreachable after receiving a route from
Router B, Router B no longer learns the reachable route from Router A, thus avoiding route
loops.
If both poison reverse and split horizon are configured, simple split horizon (the route learnt
from an interface is not sent back through the interface) is replaced by poison reverse.
3.3.6 Triggered Update

Triggered update occurs when the local routing information changes and the local router
immediately notifies its neighbors of the changes of routing information by sending the triggered
update packet.
Triggered update shortens the network convergence time. When the local routing information
changes, the local router immediately notifies its neighbors of the changes of routing information
rather than waiting for periodical update.
Figure 3-5 Schematic diagram of triggered update
The network to The network to

11.4.0.0 fails. 11.4.0.0 fails.
11.1.0.0
E0 11.2.0.0
RouterB
S0 S0 S1
RouterA
RouterC 11.3.0.0
E0 S0
The network to
11.4.0.0 fails.
11.4.0.0

As shown in Figure 3-5, when network 11.4.0.0 is unreachable, Router C learns the information
first. Usually, the route update message is sent to neighbors every 30s. If the update message of
Router B is sent to Router C when Router C is waiting for the route update message, Router C
learns the faulty route to network 11.4.0.0 from Router B. In this case, the routes from Router
B or Router C to network 11.4.0.0 point to Router C or Router B respectively, thus forming a
route loop. If Router detects a network fault and immediately sends a route update message to
Router B before the new update interval reaches. Consequently, the routing table of Router B is
updated in time, and routing loops are avoided.
There is another mode of triggering updates: The next hop of the route is unavailable because
the link is faulty. The local device needs to notify neighboring device about the unreachability
of this route. This is done by setting the cost of the route as 16 and advertising the route. This
is also called route-withdrawal.
3.3.7 Route Aggregation

When different subnet routes in the same natural network segment are transmitted to other
network segments, these routes are aggregated into one route of the same segment. This process
is called route aggregation. RIP-1 packets do not carry mask information, so RIP-1 can advertise
only the routes with natural masks. RIP-2 packets carry mask information, so RIP-2 supports
subnetting.
RIP-2 route convergence can improve extensibility and efficiency and minimize the routing table
of a large-scale network.
Route convergence is classified into two types as follows:
l Classful convergence based on RIP processes:
Aggregated routes are advertised with natural masks. When split horizon or poison reverse
is configured, classful aggregation becomes invalid due to the following reasons: split
horizon and poison reverse suppress routes to be advertised and when classful aggregation
is configured, an aggregated route may be the aggregation result of routes from different
interfaces. As a result, a conflict occurs on the aggregated route in advertisement.
For example, router 10.1.1.0 /24 (metric=2) and router 10.1.2.0 /24 (metric=3) are
aggregated as an aggregated route (10.0.0.0 /8(metric=2)) in the natural network segment.
RIP-2 aggregation is classful, thus obtaining the optimal metric.
l Interface-based aggregation:
A user can specify an aggregation address.
For example, router 10.1.1.0 /24(metric=2) and router 10.1.2.0 /24 (metric=3) are
aggregated as an aggregated route (10.1.0.0 /16(metric=2)).
3.3.8 Multi-process and Multi-instance

For easy management and effective control, RIP supports multi-process and multi-instance. The
multi-process feature allows a set of interfaces to be associated with a specific RIP process. This
ensures that the specific RIP process performs all the protocol operations only on this set of
interfaces. Thus, multiple RIP processes can work on a single router and each process is
responsible for a unique set of interfaces. In addition, the routing data is independent between
RIP processes; however, routes can be imported between processes.
For the routers that support the VPN, each RIP process is associated with a specific VPN instance.
In this case, all the interfaces attached to the RIP process should be associated with the RIP-
process-related VPN instance.

3.3.9 Hot Backup

Routers with distributed architecture support the RIP Hot Standby (HSB) feature. RIP backs up
data from the Active Main Board (AMB) to the Standby Main Board (SMB). Whenever the
AMB fails, the SMB becomes active. In this manner, RIP, being free from active/standby
switchover, proceeds to work normally.
RIP supports only the backup of RIP configurations. RIP performs Graceful Restart (GR) to
resend a routing request to neighbors and synchronize route database.

Term
Term Explanation
Poison reverse RIP sets the cost of the route learnt from an interface to 16 (specifying the
route as unreachable) and then sends the route from the interface to
neighbors.
Split horizon A route learnt by RIP on an interface is not sent to neighbors from the
interface.
Abbreviation
RIP Routing Information Protocol

Feature Description - IP Routing 4 RIPng
4 RIPng
About This Chapter
4.1 Introduction to RIPng

4.2 References
4.3 Principles

4.1 Introduction to RIPng

Definition
RIPng is an IPv6 extension of RIP-2 on the original IPv4 network. Most RIP concepts can be
applied to RIPng.
RIPng, based on the Distance Vector (D-V) algorithm, is a routing protocol that measures the
distance (metrics or cost) to the destination host by Hop Count (HC). According to RIPng, the
HC from a router to its directly connected network is 0, and the HC from a router to a network
that is reachable through another router is 1, and so on. When the HC reaches 16, the destination
network or host is defined as unreachable.
For adaption to the IPv6 network, RIPng is derived from RIP with changes as follows:
l UDP port number: RIPng uses UDP port number 521 to send and receive routing
information.
l Multicast address: RIPng uses FF02::9 as the multicast address of a RIPng router in the
local scope of the links.
l Prefix length: RIPng uses a 128-bit (the mask length) prefix in the destination address.
l Next hop address: RIPng uses a 128-bit IPv6 address.
l Source address: RIPng uses the local link address FE80::/10 as the source address to send
RIPng update packets.
Purpose
RIPng is developed by extending RIP to support IPv6.
4.2 References
Document Description Remark

s
RFC 2080 This document specifies a routing protocol for an IPv6 Internet.
It is based on protocols and algorithms currently in wide use on
the IPv4 Internet.
4.3 Principles
RIPng is developed by extending RIP-2 on the IPv6 network and uses the same timer as RIP-2.
RIPng supports split horizon, poison reverse, and triggered update to avoid routing loops.
4.3.1 RIPng Packet Format

A RIPng packet is composed of a header and several route table entries (RTEs). In a RIPng
packet, the maximum number of RTEs is determined by the MTU value of the interface.

Figure 4-1 shows the basic format of a RIPng packet.
Figure 4-1 RIPng packet format

0 7 15 31
Command Version Must be zero
Route table entry 1 (20 octets)
---------
Route table entry N (20 octets)
A RIPng packet contains two types of RTEs as follows:
l Next hop RTE: is located before the IPv6-prefix RTEs that have the same next hop. It
defines the IPv6 address of the next hop.
l IPv6-prefix RTE: is located after a next-hop RTE. Several different IPv6-prefix RTEs can
exist after the next-hop RTE. It describes the destination IPv6 address and the cost in the
RIPng routing table.
Figure 4-2 shows the format of the next-hop RTE.
Figure 4-2 Format of the next hop RTE

0 7 15 31
IPv6 next hop address (16 octets)
Must be zero Must be zero 0xFF
Figure 4-3 shows the format of the IPv6-prefix RTE.

Figure 4-3 Format of the IPv6-prefix RTE

0 7 15 31
IPv6 prefix (16 octets)
Route tag Prefix len Metric
4.3.2 Timer
RIPng uses the following three timers:
l Update timer: The timer triggers the sending of update packets every 30s. This timer
synchronizes RIPng routes on the network.
l Age timer: If a RIPng router does not receive any update packet from its neighbors in the
aging time, the RIPng router considers the route to its neighbors unreachable.
l Garbage-Collect timer: If the route is no longer valid after the timer times out, the entry is
removed from the RIPng routing table.
The following describes the relationship among the three timers:
The advertisement of RIPng routing update is triggered by the update timer every 30 seconds.
Each entry is associated with two timers, the age timer and the garbage-collect timer. When a
route is learned and installed in the routing table, the age timer is initialized. If no Update packet
is received from the neighbor for 180 seconds, the metric of the route is set to 16. At the same
time, the garbage-collect timer is initialized. If no Update packet is received for 120 seconds,
the entry is deleted after the garbage-collect timer times out.
4.3.3 Split Horizon

The principle of split horizon is that a route learnt by RIPng on an interface is not sent to neighbors
from the interface. This reduces bandwidth consumption and avoids route loops.
Figure 4-4 Schematic diagram of split horizon

123::45/64
RouterA RouterB
123::45/64
As shown in Figure 4-4, Router B sends a route to network 123::45 to Router A and Router A
does not send the route back to Router B.
4.3.4 Poison Reverse

The principle of poison reverse is that RIPng sets the cost of the route learnt from an interface
of a neighbor to 16 (specifying the route as unreachable) and then sends the route from the

interface to the neighbor. In this way, RIPng can delete useless routes from the routing table of
the neighbor.
Poison reverse of RIPng can also avoid route loops.
Figure 4-5 Schematic diagram of poison reverse

123::0/64
metric=16
RouterA RouterB
123::0/64
metric=1
As shown in Figure 4-5, if poison reverse is not configured, Router B sends Router A a route
that is learnt from Router A. The cost of the route from Router A to network 123::0/64 is 1.
When the route from Router A to network 123::0/64 becomes unreachable and Router B does
not receive the update packet from Router A and thus keeps sending Router A the route from
Router A to network 123::0/64, a route loop occurs.
If Router A sends Router B a message that the route is unreachable after receiving a route from
Router B, Router B no longer learns the reachable route from Router A, thus avoiding route
loops.
If both poison reverse and split horizon are configured, simple split horizon (the route learnt
from an interface is not sent back through the interface) is replaced by poison reverse.
4.3.5 Triggered Update

Triggered update occurs when local routing information changes and then the local router
immediately notifies its neighbors of the changes of routing information by sending the triggered
update packet.
Triggered update shortens the network convergence time. When local routing information
changes, the local router immediately notifies its neighbors of the changes of routing information
rather than waiting for periodical update.

Figure 4-6 Schematic diagram of triggered update

The network to
The network to
123::0 fails.
123::0 fails.
11:3::0
E0 11:2::0
RouterB
S0 S0 S1
RouterA
RouterC 11:1::0
E0 S0
The network to
123::0 fails.
123::0
As shown in Figure 4-6, when network 123::0 is unreachable, Router C learns the information
first. Usually, the route update message is periodically sent to neighbors. For example, RIPng
sends the route update message every 30s. If the update message of Router B is sent to Router
C when Router C is waiting for the route update message, Router C learns the faulty route to
network 123::0 from Router B. In this case, the routes from Router B or Router C to network
123::0 point to Router C or Router B respectively, thus forming a route loop. If Router detects
a network fault and immediately sends a route update message to Router B before the new update
interval reaches. Consequently, the routing table of Router B is updated in time, and routing
loops are avoided.
There is another mode of triggering updates: The next hop of the route is unavailable because
the link is faulty. The local Router needs to notify neighboring Router about the unreachability
of this route. This is done by setting the cost of the route as 16 and advertising the route. This
is also called route-withdrawal.

RIPng route aggregation is implemented by aggregating all routes advertised on an interface
according to the longest match rule.
RIPng route aggregation can improve extensibility and efficiency and minimize the routing table
of a large-scale network.
Implementation of route aggregation:
For example, RIPng advertises two routes, 11:11:11::24 Metric=2 and 11:11:12::34 Metric=3,
from an interface, and the aggregation route configured on the interface is 11::0/16. In this
manner, the finally advertised route is 11::0/16 Metric=2.
4.3.7 Multi-process and Multi-instance

For easy management and effective control, RIPng supports multi-process and multi-instance.
The multi-process feature allows a set of interfaces to be associated with a specific RIPng

process. This ensures that the specific RIPng process performs all the protocol operations only
on this set of interfaces. Thus, multiple RIPng processes can work on a single router and each
process is responsible for a unique set of interfaces. In addition, the routing data is independent
between RIPng processes; however, routes can be imported between processes.
For the routers that support the VPN, each RIPng process is associated with a specific VPN
instance. In this case, all the interfaces attached to the RIPng process should be associated with
the RIPng-process-related VPN instance.
4.3.8 Hot Backup

Routers with distributed architecture support the RIPng Hot Standby (HSB) feature. RIPng backs
up data from the Active Main Board (AMB) to the Standby Main Board (SMB). Whenever the
AMB fails, the SMB becomes active. In this manner, RIPng, being free from active/standby
switchover, proceeds to work normally.
RIPng backs up RIPng configurations only. After the SMB is activated, RIPng resends a route
request to neighbors and synchronizes routing database.
4.3.9 IPSec Authentication

RIPng does not have a clear definition on packet authentication. IPSec can be used by RIPng to
authenticate packets.
As networks develop rapidly, network security has become a major concern. If IPSec
authentication is configured on a RIPng network, the sent and received RIPng packets will be
authenticated, and those cannot pass authentication will be discarded. This can improve the
security of the RIPng network.
For more information about IPSec, see the relevant description of IPSec working principles.

Term
Term Explanation
Poison RIPng sets the cost of the route learnt from an interface to 16 (specifying the
reverse destination of the route as unreachable) and then sends the route from the
interface to neighbors.
Split horizon A route learnt by RIPng on an interface is not sent to neighbors from the
interface.
Abbreviation
RIPng RIP next generation

Feature Description - IP Routing 5 IS-IS
5 IS-IS
About This Chapter
5.1 Introduction to IS-IS

5.2 References
5.3 Principles

5.1 Introduction to IS-IS

Definition
The Intermediate System-to-Intermediate System (IS-IS) is a dynamic routing protocol initially
designed by the International Organization for Standardization (ISO) for its Connectionless
Network Protocol (CLNP).
To support IP routing, the Internet Engineering Task Force (IETF) extends and modifies IS-IS
in RFC 1195. This enables IS-IS to be applied to TCP/IP and OSI environments. This type of
IS-IS is called Integrated IS-IS or Dual IS-IS.
IS-IS stated in this document refers to Integrated IS-IS, unless otherwise stated.
Purpose
As an Interior Gateway Protocol (IGP), IS-IS is used in Autonomous Systems (ASs). IS-IS is a
link state protocol. It uses the Shortest Path First (SPF) algorithm to calculate routes.
5.2 References
Table 5-1 The following table lists the references of this document.
Document Description Remarks
ISO 10589 ISO IS-IS Routing Protocol -
ISO 8348/Ad2 Network Services Access Points -
RFC 1195 Use of OSI IS-IS for Routing in TCP/IP Multiple

and Dual Environments authentication
passwords are not
supported.
RFC 2763 Dynamic Hostname Exchange -

Mechanism for IS-IS
RFC 2966 Domain-wide Prefix Distribution with -

Two-Level IS-IS
RFC 2973 IS-IS Mesh Groups -
RFC 3277 IS-IS Transient Blackhole Avoidance -
RFC 3373 Three-Way Handshake for IS-IS Point- -

to-Point Adjacencies
RFC 3567 Intermediate System to Intermediate -

System (IS-IS) Cryptographic
Authentication
RFC 3719 Recommendations for Interoperable -

Networks using IS-IS

RFC 3784 IS-IS extensions for Traffic -

Engineering
RFC 3786 Extending the Number of IS-IS LSP -

Fragments Beyond the 256 Limit
RFC 3787 Recommendations for Interoperable IP -

Networks using IS-IS
RFC 3847 Restart signaling for IS-IS -
RFC 3906 Calculating Interior Gateway Protocol -

(IGP) Routes Over Traffic Engineering
Tunnels
RFC 4444 Management Information Base for IS- -

IS
RFC 5120 Multi Topology (MT) Routing in IS-IS -
draft-ietf-IS-IS-ipv6-05 Routing IPv6 with IS-IS -
draft-ietf-IS-IS-wg-multi- M-IS-IS: Multi Topology (MT) -

topology-11 Routing in IS-IS
draft-ietf-isis-admin- Admin Tag -

tags-02(Admin Tag)
5.3 Principles
5.3.1 Basic Concepts of IS-IS

Development of IS-IS
CLNP is a Layer 3 protocol in the OSI model posed by the ISO. IS-IS is initially designed by
the ISO and is used as a routing protocol based on CLNP addressing.

Figure 5-1 OSI model

OSI Reference OSI Protocol Suite
Model
CMIP DS FTAM MHS VTP
ASES
Application
ACSE ROSE RTSE CCRSE ......
Presentation Presentation Service/Presentation Protocal
Session Session Service/Session Protocal
Transport TP0 TP1 TP2 TP3 TP4
CONP/CMNS CLNP/CLNS
Network
IS-IS ES-IS
DataLink IEEE IEEE IEEE 802.5

FDDI X.25
802.2 802.3 Token Ring
IEEE 802.3 Token Ring FDDI X.25
Physical
Hardware Hardware Hardware Hardware
OSI adopts systemized (or hierarchical) addressing. The services on the transport layer in OSI
can be addressed through the Network Service Access Point (NSAP).
The following lists the commonly used terms in OSI:
l CLNS: indicates the Connectionless Network Service.

l CLNP: indicates the Connectionless Network Protocol.
l CMNS: indicates the Connection-Mode Network Service.
l CONP: indicates the Connection-Oriented Network Protocol.
OSI implements CLNS through CLNP, and implements CMNS through CONP.
CLNS is implemented through the following protocols:
l CLNP: is similar to the IP protocol in TCP/IP.

l IS-IS: is the routing protocol of an intermediate system.
l ES-IS: is the protocol used between a host system and an intermediate system. It is similar
to ARP or ICMP in IP.
Table 5-2 Concepts in OSI and IP
Abbre Concepts in OSI Concepts in IP

viation
IS Intermediate System Router
ES End System Host

Abbre Concepts in OSI Concepts in IP

viation
DIS Designated Intermediate System Designated Router (DR) in

OSPF
SysID System ID Router ID in OSPF
PDU Protocol Data Unit IP packet
LSP Link state Protocol Data Unit OSPF LSA
NSAP Network Service Access Point IP address
With the popularity of TCP/IP, the IETF extends and modifies IS-IS in RFC 1195 to support IP
routing. This enables IS-IS to be applied to TCP/IP and OSI environments. This type of IS-IS
is called Integrated IS-IS or Dual IS-IS.
Address Structure of IS-IS

In OSI, the NSAP is an address used to locate resources. The ISO adopts the address structure
shown in Figure 5-2, that is, NSAP. NSAP is composed of the Initial Domain Part (IDP) and
the Domain Specific Part (DSP). The IDP is equal to the network ID in the IP address, and the
DSP is equal to the subnet number and host address in an IP address.
As defined by the ISO, the IDP consists of the Authority and Format Identifier (AFI) and the
Initial Domain Identifier (IDI). The AFI specifies the address assignment mechanism and the
address format; the IDI identifies a domain.
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; the SEL indicates the service
type.
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.
Figure 5-2 Schematic diagram of the address structure of IS-IS
IDP DSP
AFI IDI High Order DSP System ID SEL(1 octet)
Area Address
l Area address
The IDP together with the HODSP of the DSP can identify a routing domain and the areas
in a routing domain; therefore, the combination of the IDP and HODSP is referred to as an

area address, which is equal to an area number in OSPF. There cannot be the same area
address in a routing domain. and the Level-1 area addresses of the routers in the same area
must be the same.
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 device, an IS-IS process can
be configured with a maximum of three area addresses for supporting seamless
combination, division, and transformation of areas.
l 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 manners:
Extend each part of the IP address 168.10.1.1 to 3 bits and add 0 to the front of the part
that is shorter than 3 bits.
Divide the extended address 168.010.001.001 into three parts, with each part consisting
of four decimal digits.
The reconstructed 1680.1000.1001 is the system ID.
There are many ways to specify a system ID. You need to ensure that the system ID uniquely
identifies a host or a router.
l SEL
The role of an SEL (also referred to as NSAP Selector or N-SEL) is similar to that of the
"protocol identifier" of IP. A transport protocol matches an SEL. The SEL is always "00"
in IP.
l NET
A Network Entity Title (NET) indicates the network layer information of an IS itself. It
does not contain the transport layer information (SEL = 0). A NET can be regarded as a
special NSAP. The length of the NET field is the same as that of an NSAP. Its maximum
length is 20 bytes and its minimum length is 8 bytes. When configuring IS-IS on a router,
you can configure only a NET instead of an NSAP.
In general, an IS-IS process is configured with only one NET. When an area needs to be
redefined, such as being combined with other areas or divided into sub-areas, you can
configure the router with multiple NETs to ensure the correctness of routes.
An IS-IS process can be configured with a maximum of three area addresses, and thus a
maximum of three NETs can be configured. When configuring multiple NETs, ensure that
their system IDs are the same.
For example, there is a NET ab.cdef.1234.5678.9abc.00, in which, the area is ab.cdef, the
system ID is 1234.5678.9abc, and the SEL is 00.
NOTE
The routers in an area must have the same area address.
IS-IS PDU Format

The types of PDUs for IS-IS include Hello, LSPs, CSNPs, and PSNPs.

Table 5-3 PDU types

Type PDU Type Name
Value
15 Level-1 LAN IS-IS Hello PDU L1 LAN IIH
16 Level-2 LAN IS-IS Hello PDU L2 LAN IIH
17 Point-to-Point IS-IS Hello PDU P2P IIH
18 Level-1 Link State PDU L1 LSP
20 Level-2 Link State PDU L2 LSP
24 Level-1 Complete Sequence Numbers PDU L1 CSNP
25 Level-2 Complete Sequence Numbers PDU L2 CSNP
26 Level-1 Partial Sequence Numbers PDU L1 PSNP
27 Level-2 Partial Sequence Numbers PDU L2 PSNP
l Hello packet format

Hello packets, also called the IS-to-IS Hello PDUs (IIH), are used to set up and maintain
neighbor relationships. Among them, Level-1 LAN IIHs are applied to the Level-1 routers
on broadcast LANs; Level-2 LAN IIHs are applied to the Level-2 routers on broadcast
LANs; P2P IIHs are applied to non-broadcast networks. Packets in different networks have
different formats.
Figure 5-3 shows the format of a Hello packet in a broadcast network (the part in blue is
the common header).
Figure 5-3 Format of a Level-1 or Level-2 LAN IIH

No. of Octets
Intradomain Routeing Protocol Discriminator 1
Length Indicator 1
Version/Protocol ID Extension 1
ID Length 1
R R R PDU Type 1
Version 1
Reserved 1
Maximum Area Address 1
Reserved/Circuit Type 1
Source ID ID Length
Holding Time 2
PDU Length 2
R Priority 1
LAN ID ID Length+1
Variable Length Fields

Figure 5-4 shows the format of a Hello packet in a P2P network.
Figure 5-4 Format of a P2P IIH

No. of Octets
Length Indicator 1
ID Length 1
R R R PDU Type 1
Version 1
Reserved 1
Reserved/Circuit Type 1
Source ID ID Length
Holding Time 2
PDU Length 2
Local Circuit ID 1
As shown in Figure 5-4, most fields in a P2P IIH are the same as those in a LAN IIH. The
P2P IIH does not have the priority and LAN ID fields, but has a local circuit ID field. The
local circuit ID indicates the local link ID.
l LSP packet format
Link State PDUs (LSPs) are used to exchange link-state information. There are two types
of LSPs, that is, Level-1 LSPs and Level-2 LSPs. Level-1 IS-IS transmits Level-1 LSPs;
Level-2 IS-IS transmits Level-2 LSPs; Level-1-2 IS-IS can transmit both Level-1 and
Level-2 LSPs.
Level-1 and Level-2 LSPs have the same format, as shown in Figure 5-5.

Figure 5-5 Format of a Level-1 or Level-2 LSP

No. of Octets
IntradomainRouteingProtocolDiscriminator 1
Length Indicator 1
Version/Protocol IDExtension 1
ID Length 1
R R R PDU Type 1
Version 1
Reserved 1
Maximum AreaAddress 1
PDULength 2
RemainingLifetime ID Length+2
SequencyNumber 4
Checksum 2
R ATT OL IS Type 1
The main fields are described as follows:

OL: indicates LSDB overload.
LSPs with the overload bit are still flooded on the network, but the LSPs are not used
when routes that pass through a router configured with the overload bit are calculated.
That is, after a router is configured with the overload bit, other routers ignore the router
when performing the SPF calculation. Only the direct routes of the router are considered.
As shown in Figure 5-6, packets from Router A to Router C are all forwarded by Router
B. If the OL field is set to 1 on Router B, however, Router A considers that the LSDB
of Router B is incomplete. Router A then forwards the packets to Router C through
Router D and Router E, but the packets to the destination that is directly connected to
Router B are forwarded normally.
Figure 5-6 Schematic diagram of LSDB overload
RouterD RouterE
Overload
RouterA RouterC
RouterB

IS Type: indicates the type of IS-IS generating the LSP.

It is used to specify whether the level of IS-IS is Level-1 or Level-2 (01 indicates
Level-1; 11 indicates Level-2).
l SNP Format
Sequence Number PDUs (SNPs) describe the LSPs in all or part of the databases to
synchronize and maintain all LSDBs.
An SNP consists of a complete SNP (CSNP) and a partial SNP (PSNP). They are further
divided into a Level-1 CSNP, a Level-2 CSNP, a Level-1 PSNP, and a Level-2 PSNP.
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.
Figure 5-7 shows the CSNP format.
Figure 5-7 Format of a Level-1 or Level-2 CSNP

No. of Octets
Length Indicator 1
ID Length 1
R R R PDU Type 1
Version 1
Reserved 1
PDU Length 2
Source ID ID Length+1
Start LSP ID ID Length+2
End LSP ID ID Length+2
The main fields are described as follows:

Source ID: indicates the system ID of the router that sends the SNP.
Start LSP ID: indicates the ID of the first LSP in the CSNP.
End LSP ID: indicates the ID of the last LSP in the CSNP.
A PSNP lists only the sequence number of recently received LSPs. A PSNP can
acknowledge multiple LSPs at a time. If an LSDB is not updated, the PSNP is also used to
request a neighbor to send a new LSP.
Figure 5-8 shows the PSNP format.

Figure 5-8 Format of a Level-1 or Level-2 PSNP

No. of Octets
Length Indicator 1
ID Length 1
R R R PDU Type 1
Version 1
Reserved 1
PDU Length 2
Source ID ID Length+1
l CLV
The variable length fields in a PDU are the multiple Code-Length-Values (CLVs). Figure
5-9 shows the CLV format. A CLV is also called the Type- Length-Value (TLV).
Figure 5-9 CLV format

No. of Octets
Code 1
Length 1
Value Length
CLVs vary with PDU types, as shown in Table 5-4.
Table 5-4 PDU types and CLV names
CLV Code Name Applied PDU Type
1 Area Addresses IIH and LSP
2 IS Neighbors (LSP) LSP
4 Partition Designated Level2 IS L2 LSP
6 IS Neighbors (MAC Address) LAN IIH
7 IS Neighbors (SNPA Address) LAN IIH
8 Padding IIH
9 LSP Entries SNP

CLV Code Name Applied PDU Type
10 Authentication Information IIH, LSP, and SNP
128 IP Internal Reachability Information LSP
129 Protocols Supported IIH and LSP
130 IP External Reachability Information L2 LSP
131 Inter-Domain Routing Protocol L2 LSP

Information
132 IP Interface Address IIH and LSP
The CLVs with codes ranging from 1 to 10 are defined in ISO 10589 (two types are not
listed in the table), and the other CLVs are defined in RFC 1195.
IS-IS Areas
l Two-Level structure
To support large-scale routing networks, IS-IS adopts a two-level structure in a routing
domain. A large domain can be divided into one or more areas. In general, Level-1 routers
are located in an area, Level-2 routers are located among areas, and Level-1-2 routers are
located between the Level-1 routers and the Level-2 routers.
l 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. It maintains a Level-1 LSDB. The
LSDB contains routing information on the local area. A packet to a destination outside this
area is forwarded to the nearest Level-1-2 router.
l Level-2 router
A Level-2 router manages inter-area routing. It can establish neighbor relationships with
Level-2 routers or Level-1-2 routers in other areas. It 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 are responsible
for communications between areas. The Level-2 routers in the routing domain must be in
succession 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.
l Level-1-2 router
A router, which 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 routers and Level-1-2
routers in the same area. It can also establish Level-2 neighbor relationships with Level-2
routers and Level-1-2 routers in other 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, that is, a Level-1 LSDB and a Level-2 LSDB.
The Level-1 LSDB is used for intra-area routing and the Level-2 LSDB is used for inter-
area routing.

NOTE
Level-1 routers in different areas cannot establish neighbor relationships. Level-2 routers can
establish neighbor relationships with each other, regardless of the areas to which the Level-2 routers
belong.
l Interface level
A Level-1-2 router may need to establish only a Level-1 neighbor relationship with the
remote end and establish only a Level-2 neighbor relationship with the other remote end.
You can set the level of an interface to restrict the setup of adjacencies on the interface.
For example, only a Level-1 adjacency can be established on a Level-1 interface and only
a Level-2 adjacency can be established on a Level-2 interface.
Figure 5-10 shows a network that runs IS-IS. The network is similar to an OSPF network
typology with multiple areas. The entire backbone area contains all routers in Area 1 and
Level-1-2 routers in other areas.
Figure 5-10 IS-IS topology I
Area2
Area3
L1
L1/2
L1/2
L2
L2
backbone Area1
L2 L2
Area5
Area4
L1/2 L1
L1/2
L1
L1
L1 L1
Figure 5-11 shows another type of IS-IS topologies. All the successive Level-1-2 and Level-2
routers form the backbone area of IS-IS. In the topology, Level-2 routers belong to different
areas, and Level-1-2 routers also belong to different areas. No area is defined as the backbone
area.

Figure 5-11 IS-IS topology II
Area1
L1
L2
L1
L1/L2
Area2 L1/L2 L1
Area4
L2
L2 Area3
NOTE
The IS-IS backbone network does not refer to a specific area.
This networking scheme shows the difference between IS-IS and OSPF. For OSPF, inter-area
routes are forwarded by the backbone area, and the SPF algorithm is used only in the same area.
For IS-IS, both Level-1 and Level-2 routes are calculated through the SPF algorithm to generate
the Shortest Path Tree (SPT).
IS-IS Network Types

IS-IS supports only two types of networks. According to physical links, IS-IS networks can be
classified into the following types:
l Broadcast links: such as Ethernet and Token-Ring

l Point-to-point links: such as PPP and HDLC
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 the Point to MultiPoint (P2MP)
networks.
DIS and Pseudo Node

In a broadcast network, IS-IS needs to elect a Designated Intermediate System (DIS) from all
the routers.
The DISs of Level-1 and Level-2 are elected respectively. 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 in a broadcast network, the one with the largest
MAC address is chosen. The DISs of different levels can be the same router or different routers.
Unlike the DR election in OSPF, the DIS election in IS-IS has the following features:
l The router with the priority being 0 also takes part in the DIS election.
l When a new router that meets the requirements of being a DIS joins the broadcast network,
the router is selected as the new DIS, and the original pseudonode is deleted. This causes
LSP flooding.

In an IS-IS broadcast network, the routers (including non-DIS routers) of the same level in a
network segment set up adjacencies, which is different from that of OSPF. Figure 5-12 shows
the networking.
Figure 5-12 DISs and adjacencies in an IS-IS broadcast network

L1/L2 L1/L2
L1 Adjacencies
L2 Adjacencies
L1 DIS L2 DIS
A DIS is used to create and update pseudo nodes. It also generates LSPs of the pseudo nodes.
The LSPs describe the available routers on the network.
The pseudo node is used to simulate the virtual node in the broadcast network and is not an actual
router. In IS-IS, a pseudo node is identified by the system ID of the DIS and the 1-byte Circuit
ID (its value is not 0).
With pseudo nodes, the network topology is simplified and LSPs are shortened. When the
network changes, the number of generated LSPs is reduced. As a result, the SPF consumes fewer
resources.
NOTE
In an IS-IS broadcast network, although all the routers set up adjacencies with each other, the LSDBs are
synchronized by the DISs.
Establishment of the IS-IS Neighbor Relationship

Two IS-IS routers need to establish the neighbor relationship before exchanging packets to
implement routing. On different networks, the modes for establishing IS-IS neighbors are
different.
l Establishment of a neighbor relationship on a broadcast link
Figure 5-13 Networking diagram of a broadcast link

RouterA RouterB
RouterC RouterD

Router A, Router B, Router C, and Router D are Level-2 routers. Router A is newly added
to the broadcast network. Figure 5-13 lists the process of establishing the neighbor
relationship between Router A and Router B. The process of establishing the neighbor
relationship between Router A and Router C or Router D is similar to that between Router
A and Router B, and is not mentioned here.
Figure 5-14 Process of establishing a neighbor relationship on a broadcast link
RouterA RouterB
Gigabit Ethernet1/0/0 Gigabit Ethernet1/0/0
SYS id:1111.1111.1111 SYS id:2222.2222.2222

L2 LAN IIH
( sys id:1111.1111.1111 neighbor:null )
neighbor Router A
L2 LAN IIH initialized
( sys id:2222.2222.2222 neighbor:Router A )
neighbor Router B
established L2 LAN IIH
( sys id:1111.1111.1111 neighbor:Router B )
neighbor Router A
established
L2 LAN IIH
L2 LAN IIH
Router A broadcasts a Level-2 LAN IS-IS Hello PDU. After receiving the PDU, Router B
sets its neighbor status with Router A to Initial. Then, Router B responds Router A with a
Level-2 LAN IIH packet indicating that Router A is a neighbor of Router B. On receiving
the IIH packet, Router A sets its neighbor status with Router B to Up.
The network is a broadcast network, so a DIS needs to be elected. After the neighbor
relationship is established, routers wait for two intervals for 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.
l 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, that is, 2-way mode
and 3-way mode.
2-way mode
Upon receiving an IS-IS Hello packet, a router unidirectionally sets up the neighbor
relationship.
3-way mode

A neighbor relationship is established after IS-IS Hello PDUs are sent for three times,
which is similar to the establishment of a neighbor relationship on a broadcast link.
NOTE
The three-way handshake mechanism of IS-IS is specifically introduced in IS-IS 3-Way
Handshake chapters.
Basic rules for establishing an IS-IS neighbor relationship are as follows:
l Only the neighboring routers of the same level can set up the neighbor relationship with
each other.
l For Level-1 routers, their area IDs must be the same.
l Routers are on the same network segment.
Network types of IS-IS interfaces on both ends of a link must be consistent; otherwise, the
neighbor relationship cannot be established. By simulating Ethernet interfaces as P2P interfaces,
you can establish a neighbor relationship on a P2P link.
IS-IS runs on the data-link layer and is initially designed for CLNP. Therefore, the establishment
of an IS-IS neighbor relationship is not related to IP addresses. In the implementation of the
device, IS-IS runs only over IP. Thus, 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 only when either the primary IP addresses or secondary IP addresses are
on the same network segment.
When IP address unnumbered is not configured, if the IP address of its neighbor and the address
of the interface through which the router receives packets are not on the same network segment,
the neighbor relationship cannot be set up. The IP unreachability is thus prevented. The neighbor
relationship can be set up if you configure the router not to check the IP addresses contained in
received Hello packets.
l For P2P interfaces, you can configure the interfaces not to check the IP addresses.
l For Ethernet interfaces, you must simulate Ethernet interfaces as P2P interfaces and then
configure the interfaces not to check the IP addresses.
Process of Exchanging IS-IS LSPs

l LSP flooding
The flooding of LSPs is a mode in which a router sends an LSP to its neighbors and 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.
Through the flooding, each router of the same level has the same LSP information and
keeps a synchronized LSDB.
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.
l 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:
A neighbor is Up or Down.
A related interface is Up or Down.
Imported IP routes change.

Inter-area IP routes change.

An interface is assigned with a new metric value.
Periodical updates occur.
l Processing of a new LSP received from a neighbor
1. The router installs the LSP to the LSDB and marks it with flooding.
2. The router sends the LSP to all interfaces except the interface that receives the LSP.
3. The neighbors flood the LSP to their neighbors.
l Process of synchronizing LSDBs between a newly added router and DIS
Figure 5-15 Process of updating LSDBs on a broadcast link

RouterA
RouterC
RouterB( DIS)
LSP
Router C.00-00
CSNP
Router A.00-00
Router B.00-00
Router B.01-00 PSNP
Router C.00-00 Router A.00-00
Router B.00-00
Router B.01-00
LSP
Router A.00-00
Router B.00-00
Router B.01-00
A newly added Router C sends Hello packets to establish neighbor relationships with
the other routers in the broadcast domain. For details, see "Establishment of a neighbor
relationship on a broadcast link."
After setting up the neighbor relationships with other routers, Router C sends its LSP
to the following multicast addresses after the LSP timer expires:
Level-1: 01-80-C2-00-00-14
Level-2: 01-80-C2-00-00-15
All neighbors on the network can receive the LSP.
The DIS on the network segment adds the LSP received from Router C to its LSDB.
After the CSNP timer expires, the DIS sends CSNPs to synchronize the LSDBs on the
network. By default, CSNPs are sent at intervals of 10 seconds.

After Router C receives the CSNPs from the DIS, Router C checks its LSDB and sends
a PSNP to request the LSPs it does not have.
After receiving the PSNP, the DIS sends the required LSPs to synchronize LSDBs.
l Process of updating the LSDB of the DIS
When the DIS receives an LSP, it searches the LSDB for the related records. If the DIS
does not find the LSP in its LSDB, it adds the LSP to its LSDB and broadcasts the
contents of the new LSDB.
If the sequence number of the received LSP is greater than the sequence number of the
corresponding LSP in the LSDB, the DIS replaces the LSP with the received LSP in
the LSDB, and broadcasts the contents of the new LSDB.
If the sequence number of the received LSP is smaller than the sequence number of the
corresponding LSP in the LSDB, the DIS sends the LSP in the LSDB to the inbound
interface.
If the sequence number of the received LSP is equal to the sequence number of the
corresponding LSP in the LSDB, the DIS 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 DIS replaces the LSP in the LSDB with the
received LSP, and broadcasts the contents of the new LSDB.
If the sequence number of the received LSP is equal to the sequence number of the
corresponding LSP in the LSDB, the DIS compares the Remaining Lifetime of the two
LSPs. If the received LSP has a greater Remaining Lifetime than that of the
corresponding LSP in the LSDB, the DIS sends the LSP in the LSDB to the inbound
interface.
If both the sequence number and the Remaining Lifetime of the received LSP and the
corresponding LSP in the LSDB are the same, the DIS 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 DIS replaces the LSP in the LSDB with the received LSP, and
advertises the contents of the new LSDB.
corresponding LSP in the LSDB are the same, the DIS compares the checksum of the
two LSPs. If the received LSP has a smaller checksum than that of the corresponding
LSP in the LSDB, the DIS sends the LSP in the LSDB to the inbound interface.
If both the sequence number, Remaining Lifetime, and checksum of the received LSP
and that of the corresponding LSP in the LSDB are the same, the LSP is not forwarded.
l Process of synchronizing the LSDB on a P2P link

Figure 5-16 Process of updating the LSDB on a P2P link

RouterA RouterB
PPP
LSP
Router A.00-00
PSNP
Router A.00-00
Retransmission
times out
LSP Resend
Router A.00-00 response packet
PSNP
Router A.00-00
1. For the establishment of the neighbor relationship, see "Establishment of the Neighbor
Relationship on a P2P Link."
2. When the neighbor relationship is set up for the first time, a router sends a CSNP to
its neighbor. If the LSDB of the neighbor and the CSNP are not synchronized, the
neighbor sends PSNP requests for a required LSP.
3. The router sends the required LSP to the neighbor and starts the LSP retransmission
timer. The router then waits for a PSNP from the neighbor as an acknowledgement of
the receiving of the LSP.
4. If the router does not receive the PSNP from the neighbor after the LSP retransmission
timer expires, it resends the LSP.
NOTE
A PSNP on a P2P link functions as follows:

l It is used as an Ack packet to acknowledge the received LSP.
l It is used as a request packet to require LSPs.
l Process of updating the LSDB of the P2P
If the sequence number of the received LSP is greater than the sequence number of the
corresponding LSP in the LSDB, the router adds the LSP to its LSDB. The router then
sends a PSNP to acknowledge the received LSP. At last, the router sends the LSP to all
its neighbors except the neighbor that sends the LSP.
If the sequence number of the received LSP is smaller than the sequence number of the
corresponding LSP in the LSDB, the router directly sends its LSP to the neighbor and
waits for a PSNP from the neighbor as the acknowledgement.
If the sequence number of the received LSP is the same as the sequence number 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 LSP to its LSDB. The router then
sends a PSNP to acknowledge the received LSP. At last, the router sends the LSP to all
its neighbors except the neighbor that sends the LSP.
If the sequence number of the received LSP is the same as the sequence number of the
corresponding LSP in the LSDB, the router compares the Remaining Lifetime of the

two LSPs. 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.
corresponding LSP in the LSDB are the same, 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 LSP to its LSDB. The router then sends a PSNP
to acknowledge the received LSP. At last, the router sends the LSP to all its neighbors
except the neighbor that sends the LSP.
corresponding LSP in the LSDB are the same, the router compares the checksum of the
two LSPs. 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.
If both the sequence number, Remaining Lifetime, and checksum of the received LSP
and the corresponding LSP in the LSDB are the same, the LSP is not forwarded.
5.3.2 IS-IS Multi-instance and Multi-process

For the routers that support the VPN, you can associate each IS-IS process with a specific VPN
instance. Thus, you can configure multiple IS-IS processes to be associated with multiple VPN
instances at the same time.
l IS-IS multi-instance indicates that you can configure multiple IS-IS instances on the same
router.
l IS-IS multi-process indicates that you can create multiple IS-IS processes in a VPN or a
public network.
The multi-process feature allows a set of interfaces to be associated with a specific IS-
IS process. This ensures that the specific IS-IS process performs all the protocol
operations only on the set of interfaces. Thus, multiple IS-IS processes can work on a
single router and each process is responsible for a unique set of interfaces.
IS-IS multi-processes share an RM routing table. IS-IS multi-instances use the RM
routing tables of VPNs. Each VPN has its own RM routing table.
When an IS-IS process is created, it can be associated with a VPN instance. Then, the
IS-IS process belongs to the VPN and processes events only in the VPN. The IS-IS
process is deleted when the associated VPN is deleted.
For easy management and effective control, IS-IS supports multi-process and multi-instance
features.
In the scenario where IS-IS is applied to users on private networks, after a VPN is created,
interfaces bound to the VPN and routes in the VPN are isolated from other VPNs and public
network data. In this case, you can adopt IS-IS multi-instance to deploy IS-IS in the VPN.
For the routers that support the VPN, each IS-IS process is associated with a specific VPN
instance. All the interfaces attached to an IS-IS process, therefore, should be associated with the
VPN instance that this IS-IS process is associated to.
At present, the VPN instance is maintained by the VPN module. Thus, IS-IS multi-instance is
implemented by associating an IS-IS process with a VPN instance when the IS-IS process is
created.
When configuring IS-IS multi-instance and multi-process, note the following:

l When creating IS-IS multi-instances, associate an IS-IS process with a VPN instance when
the IS-IS process is created. If an IS-IS process is not associated with a VPN instance when
the IS-IS process is created, the association cannot be configured later.
l An IS-IS process that is already associated with a VPN instance cannot be associated with
another VPN instance.
l An IS-IS process can be associated with only one VPN instance of a single protocol type
such as IPv4 or IPv6, whereas it can be associated with an IPv4 VPN instance and an IPv6
VPN instance at the same time.
l Multiple IS-IS processes can be associated with one VPN instance.
l The interfaces where IS-IS multi-instance needs to be enabled must be associated with the
same VPN instance as IS-IS.
l The IS-IS process associated with a VPN instance belongs to the VPN. Thus, the IS-IS
process is deleted when the VPN is deleted.
l Routes from different VPNs cannot be imported to each other.
5.3.3 IS-IS Route Leaking

With the route leaking function, Level-1-2 IS-IS advertises the known routing information about
other Level-1 and Level-2 areas to the specified Level-1 areas.
Normally, the intra-area routes are managed by Level-1 routers. All Level-2 and Level-1-2
routers form a successive backbone area. The Level-1 area can be connected to only the backbone
area. The Level-1 areas cannot be connected to each other.
Routing information in a Level-1 area is advertised to a Level-2 area through a Level-1-2 router.
That is, the Level-1-2 router encapsulates the 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. To reduce the size of
routing tables, Level-2 routers, by default, do not advertise the learned routing information of
Level-1 areas and that of the backbone area to Level-1 areas. The Level-1 routers, therefore,
cannot know the routing information outside the area. In this manner, the Level-1 routers cannot
select the optimal route to the destination outside the area.
To solve the preceding problem, IS-IS route leaking is introduced. By configuring Access
Control Lists (ACLs) and route-policies and marking routes with tags on Level-1-2 routers, you
can select eligible routes. Then, a Level-1-2 router can advertise some routing information of
other Level-1 areas and the backbone area to its Level-1 area.
Figure 5-17 Networking for route leaking

RouterA RouterC
Level-1GE1/0/0 GE1/0/0 Level-1-2
1.1.1.1/24 1.1.1.2/24
cost 50 GE1/0/0
cost 10 4.4.4.2/24
GE2/0/0 GE3/0/0 GE3/0/0
GE2/0/0 6.6.6.2/24 6.6.6.1/24
2.2.2.1/24 4.4.4.1/24
cost 10 cost 10
GE2/0/0 RouterE RouterF
cost 10 GE2/0/0 Level-2 Level-2
2.2.2.2/24 5.5.5.2/24
cost 10
GE2/0/0
GE1/0/0 GE1/0/0 5.5.5.1/24 Area20
3.3.3.1/24 3.3.3.2/24
RouterB RouterD
Level-1 Level-1-2
Area10

l Router A, Router B, Router C, and Router D belong to Area 10; Router A and Router B
are Level-1 routers; Router C and Router D are Level-1-2 routers.
l Router E and Router F are Level-2 routers and belong to Area 20.
If Router A sends a packet to Router F, the selected optimal route should be Router A -> Router
B -> Router D -> Router E -> Router F. This is because the cost of the route is 40. Check the
route on Router A to view the path of packets sent to Router F, and you can find that the selected
route is Router A -> Router C -> Router E -> Router F, of which the cost is 70. Thus, the route
is not the optimal route from Router A to Router F.
Router A does not know the routes outside the local area, so the packets sent by Router A to
other network segments are sent through the default route generated by the nearest Level-1-2
router.
In this case, you can enable route leaking on the Level-1-2 routers, that is, Router C and Router
D. Then, check the route and you can find that the selected route is Router A -> Router B ->
Router D -> Router E -> Router F, which is the optimal route from Router A to Router F.
5.3.4 IS-IS Fast Convergence

IS-IS fast convergence is an extended feature of IS-IS implemented to speed up the convergence
of routes. It includes the following:
l I-SPF
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.
l PRC
Partial Route Calculation (PRC) calculates only the changed routes when the routes on the
network change.
l LSP fast flooding
LSP fast flooding speeds up the flooding of LSPs.
l Intelligent timer
The first timeout period of the timer is fixed. If an event that triggers the timer happens
when the timer is set and does not expire, the interval set by the intelligent timer increases
next time.
The intelligent timer is applicable to the LSP generation and SPF calculation.
I-SPF (Incremental SPF)

In ISO 10589, the Dijkstra algorithm is adopted to calculate routes. When a node changes on
the network, this algorithm is used to recalculate all routes. The calculation lasts a long time and
consumes too many CPU resources, thus affecting 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 SPT generated at last is the same as that generated by the previous
algorithm. This decreases the CPU usage and speeds up the network convergence.
PRC (Partial Route Calculation)

Similar to I-SPF, PRC calculates only the changed routes. PRC, however, does not calculate the
shortest path. It updates the 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. In this case, PRC updates only the routes of this interface, thus 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.
NOTE
In the implementation of device, only I-SPF and PRC are used to calculate IS-IS routes.
LSP Fast Flooding

When IS-IS receives new LSPs from other routers, it updates the LSPs in the LSDB and
periodically floods out the updated LSPs according to a timer.
LSP fast flooding improves the preceding mode. When the device configured with this feature
receives one or more new LSPs, it floods out the LSPs whose amount is smaller than the specified
number before calculating routes. This significantly improves the network convergence speed.
Intelligent Timer
Although the route calculation algorithm is improved, the long interval for triggering the route
calculation also affects the convergence speed. You can shorten the interval by using a
millisecond-level timer. Frequent network changes, however, also consume too many CPU
resources. The SPF intelligent timer addresses these problems.
In general, an IS-IS network running normally is stable. The probability of the occurrence of
many network changes is very low, and IS-IS does not frequently calculate routes. The period
for triggering the route calculation is very short (millisecond level). If the topology of the network
changes very often, the interval set by the intelligent timer increases with the calculation times
to avoid too much CPU consumption.
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 original mechanism adopts a timer with uniform intervals, and thus fast
convergence and low CPU consumption cannot be achieved. Thus, 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. In addition, when the network changes very
often, the interval for the intelligent timer becomes longer to avoid too much CPU consumption.
5.3.5 Priority-based IS-IS Convergence

Priority-based IS-IS convergence ensures that specific routes converge first in the case of a great
number of routes. Different routes can be set with different convergence priorities. This allows
important routes to converge first and thus improves network reliability.
Priority-based IS-IS convergence enables specific routes (such as routes that match the specified
IP prefix) to converge first. Therefore, users can assign a high convergence priority to routes for
key services so that these routes can converge fast. This decreases impact on key services.

5.3.6 IS-IS LSP Fragment Extension

When the LSPs to be advertised by IS-IS contain much information, they are advertised in
multiple LSP fragments of the same system.
As defined in RFC 3786, virtual system IDs can be configured and virtual LSPs that carry routing
information can be generated for IS-IS.
The IS-IS LSP fragment extension attribute allows an IS-IS router to generate more LSP
fragments and carry more IS-IS information.
Terms
l Originating system
The originating system is a router that runs the IS-IS protocol. A single IS-IS process can
advertise its LSPs as multiple "virtual" routers, and the originating system represents the
"real" IS-IS process.
l Normal system ID
It is the system ID of the originating system.
l Additional system ID
The additional system ID, assigned by network administrators, is used to generate
additional or extended LSP fragments. Up to 256 additional or extended LSP fragments
can be generated. Like the normal system ID, the additional system ID must be unique in
the routing domain.
l Virtual system
The system, identified by an additional system ID, is used to generate extended LSP
fragments. These fragments carry the additional system IDs in their LSP IDs.
Principle
IS-IS LSP fragments are identified by the LSP Number field in their LSP IDs. The LSP Number
field is 1 byte. Thus, an IS-IS process can generate a maximum of 256 fragments, carrying a
limited number of routes (30,000 routes can be carried when the fragment length is 1497 bytes).
With fragment extension, more information can be carried.
Each system ID represents a virtual system that can generate 256 LSP fragments. With more
additional system IDs (up to 50 virtual systems), an IS-IS process can generate a maximum of
13056 LSP fragments.
When a virtual system and fragment extension are configured, an IS-IS router adds the contents
that cannot be contained in the LSPs advertised by the originating system to the LSPs of the
virtual system, and notifies other routers of the relation between the virtual system and itself
through a special TLV.
IS Alias ID TLV
A special TLV, IS Alias ID TLV, is defined in RFC 3786.

Table 5-5 IS Alias ID TLV

Field Length Description
Type 1 byte Indicates the TLV type. If the value is 24, it indicates
the IS Alias ID TLV.
Length 1 byte Indicates the length of Value in the TLV.
System ID 6 bytes System ID
Pseudonode 1 byte pseudonode number

number
sub-TLVs 1 byte sub-TLVs length

length
sub-TLVs 0 to 247 bytes sub-TLVs
In whatever operation mode, the originating system and virtual system send the LSPs with the
fragment number being 0 carrying IS Alias ID TLV to indicate the originating system.
Operation Modes
The IS-IS router can run the LSP fragment extension feature in the following modes:
Figure 5-18 Networking for LSP fragment extension
RouterA1
RouterB RouterA
RouterA2
l Mode-1
It is used when some routers on the network do not support the LSP fragment extension.
In this mode, virtual systems participate in the SPF calculation. The originating system
advertises LSPs containing information about links to each virtual system. Similarly, each
virtual system advertises LSPs containing information about links to the originating system.
In this manner, the virtual systems look like the actual routers that are connected to the
originating system on the network.
Mode-1 is a transitional mode for the earlier versions that do not support fragment
extension. In the earlier versions, IS-IS cannot identify the Alias ID TLV. Thus, the LSP
sent by a virtual system must look like a common IS-IS LSP.

The LSP sent by a virtual system contains the same area address and overload bit as that
in the common LSP. If the LSPs sent by a virtual system contain TLVs specified in other
features, they must be the same as those in common LSPs.
The virtual system carries neighbor information specifying that the neighbor is the
originating system, with the metric being the maximum value minus 1; the originating
system carries neighbor information specifying that the neighbor is the virtual system, with
the metric being 0. This ensures that the virtual system is the downstream node of the
originating system when other routers calculate routes.
As shown in Figure 5-18, Router B does not support the LSP fragment extension; Router
A is set to support the LSP fragment extension in mode-1; Router A1 and Router A2 are
virtual systems of Router A. Router A1 and Router A2 send LSPs carrying some routing
information of Router A. After receiving LSPs from Router A, Router A1, and Router A2,
Router B considers that there are three individual routers at the peer end and calculates
routes normally. Because the cost of the route from Router A to Router A1 and the cost of
the route from Router A to Router A2 are both 0s, the cost of the route from Router B to
Router A is equal to the cost of the route from Router B to Router A1.
l Mode-2
It is used when all the routers on the network support the LSP fragment extension. In this
mode, virtual systems do not participate in the SPF calculation. All the routers on the
network know that the LSPs generated by the virtual systems actually belong to the
originating system.
IS-IS working in mode-2 identifies IS Alias ID TLV, which is used to calculate the SPT
and routes.
As shown in Figure 5-18, Router B supports the LSP fragment extension; Router A is set
to support the LSP fragment extension in mode-2; Router A1 and Router A2 send LSPs
carrying some routing information of Router A. When receiving LSPs from Router A1 and
Router A2, Router B obtains IS Alias ID TLV and knows that the originating system of
Router A1 and Router A2 is Router A. Router B then considers that information advertised
by Router A1 and Router A2 belongs to Router A.
No matter LSP fragment extension is set to mode-1 or mode-2, both LSPs in mode-1 and LSPs
in mode-2 can be resolved. If LSP fragment extension is not supported, only LSPs in mode-1
can be resolved.
Table 5-6 Comparison between mode-1 and mode-2
LSP Content\Mode Mode-1 Mode-2
IS Alias ID Yes Yes
area Yes No
overload bit Yes Yes
IS NBR/IS EXTENDED NBR Yes No
Routing Yes Yes
ATT bits must 0 must 0
P bit must 0 must 0

Process
After LSP fragment extension is configured, if information is lost because LSPs are of full
lengths, the system prompts that the IS-IS router should be restarted. After being restarted, the
originating system loads as much routing information as possible. The remaining information
is added to the LSPs of the virtual systems for transmission.
Application Environment
NOTE
If there are devices of other manufacturers on the network, the LSP fragment extension must be set to
mode-1. Otherwise, devices of other manufacturers cannot identify the LSPs.
It is recommended that you configure the LSP fragment extension and virtual systems before
setting up IS-IS neighbors or importing routes. If you set up IS-IS neighbors or import routes,
which causes IS-IS to carry much information that cannot be loaded through 256 fragments, you
must configure the LSP fragment extension and virtual systems. The configurations, however,
takes effect only after you restart the IS-IS router.
5.3.7 IS-IS Administrative Tag

Administrative tags control the advertisement of IP prefixes in the IS-IS domain.
The administrative tag carries administrative information about an IP address prefix, which
simplifies management. It is used to control the importing of routes of different levels and
different areas, and control different routing protocols and IS-IS multi-instances running on the
same router.
The value of an administrative tag is associated with certain attributes. When cost-style is wide,
wide-compatible or compatible, if IS-IS advertises an IP address prefix with these attributes, it
adds the administrative tag to the TLV in the prefix. In this manner, the tag is flooded with the
prefix throughout the routing domain.
5.3.8 Dynamic Hostname Exchange Mechanism

The dynamic hostname exchange mechanism provides a mapping from the hostname to system
ID for IS-IS routers.
IS-IS was first designed by the ISO for the CLNS; thus, its unique address encoding method is
retained.
Information about IS-IS neighbors and LSDBs on an IS-IS router, with hostname exchange
disabled, is represented by a system ID with 12 hexadecimal numbers, for example, aaaa.eeee.
1234. This representation, however, is complicated and not easy to use.
To maintain and manage IS-IS networks easily, the dynamic hostname exchange mechanism is
introduced.
This dynamic hostname information is advertised in the form of a dynamic hostname TLV (type
137) in LSPs. The dynamic hostname exchange mechanism also provides a service to associate
a host name with the Designated IS (DIS) on a broadcast network. Then, this mechanism
advertises this association through LSPs in the form of a dynamic hostname TLV.
In the implementation of NE80E/40E, routers where IS-IS dynamic hostname mapping is
enabled add the Dynamic Hostname TLV (TLV type 137) that records the local host name to
the LSPs they generate before sending the LSPs out.
Dynamic Hostname TLV (TLV type 137) includes the following fields:

l Type: indicates the dynamic hostname exchange mechanism.

l Length: indicates the total length of the value field.
l Value: indicates a character string of 1 to 255 characters.
The Dynamic Hostname TLV is optional and can be inserted anywhere in an LSP. The hostname
value cannot be null. A router determines whether to carry the TLV in sending LSPs; the router
that receives the LSPs determines whether to ignore the TLV or obtain the TLV for its mapping
table.
Implementation
l Matching rules
The dynamic hostname abides by the longest match rule. System ID+NSEL is first
compared. If it doesn't match, the system ID is then compared.
l Transmission of the dynamic hostname
The dynamic hostname can be carried by the original LSP only.
l Transmission of the DIS dynamic hostname
The DIS dynamic hostname is transmitted through the LSPs generated by the DIS.
l Priority of the dynamic hostname
The dynamic hostname is prior to the static hostname. When both a dynamic hostname and
a static hostname are configured, the dynamic hostname replaces the static hostname.
l Configuration and resolution of the dynamic hostname
The dynamic hostname can be up to 64 bytes in length and a maximum of 255-byte contents
can be resolved.
In maintenance and management, the hostname is easier to identify and memorize than the
system ID. After this function is configured, it is the hostname instead of the system ID displayed
for the router.
The hostname exchange mechanism implemented on the NE80E/40E includes dynamic

hostname mapping and static hostname mapping. The system ID is replaced by the hostname in
the following cases:
l When an IS-IS neighbor is displayed, the system ID of the IS-IS neighbor is replaced by
the dynamic hostnames. If the IS-IS neighbor is the DIS, then the system ID of the DIS is
replaced by the dynamic hostnames of the neighbor.
l When an LSP in the IS-IS LSDB is displayed, the system ID in the LSP ID is replaced by
the dynamic hostname of the router that advertises the LSP.
l When details about the IS-IS LSDB are displayed, the Host Name field is included for the
LSP generated by the router where dynamic hostname exchange is enabled; the system ID
is replaced by the dynamic hostname of the IS-IS neighbor.
5.3.9 IS-IS HA
IS-IS HA includes hot standby, data backup, command line backup, batch backup, and real-time
backup.

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 AMB. IS-IS, therefore,
can keep working normally.
Basic Concepts
l Data backup
It indicates backup of data of processes and interfaces.
l Command line backup
If the AMB processes successfully, it sends the command lines to the SMB for processing.
If the AMB fails to process, it records in the log that the command lines fail to take effect
and does not send the command lines to the SMB for processing. If the SMB fails to process,
the failure is recorded in the log.
Hot Standby
The IS-IS Hot Standby (HSB) feature is supported on the devices with a distributed structure.
In the running process of IS-IS HSB, IS-IS configurations on the AMB and those on the SMB
are consistent. When the AMB/SMB switchover occurs, IS-IS on the new AMB performs GR.
The new AMB resends a request for setting up the neighbor relationship to neighbors to
synchronize LSDBs. Traffic, therefore, is not affected.
Batch Backup
l Backing up data in batches
When the SMB is installed, all data of the AMB is backed up to the SMB. No configuration
can be changed during batch backup.
l Backing up command lines in batches
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
l Real-time backup of data
It indicates real-time backup of changed data of processes and interfaces to the SMB.
l Real-time backup of command lines
It indicates that command lines that are run successfully on the AMB are backed up to the
SMB.
5.3.10 IS-IS 3-Way Handshake

IS-IS introduces the 3-way handshake mechanism on P2P links to ensure a reliable data link
layer.
According to ISO 10589, the 2-way handshake mechanism of IS-IS uses Hello packets to set up
P2P adjacencies between neighbors. Once the router receives a Hello packet from its peer, it
regards the status of the peer as Up and sets an adjacency with the peer. This mechanism has
distinct disadvantages.
When two or more links exist between two routers, an adjacency can still be set up when one
link is Down and the other is Up in the same direction. The parameters of the other link, however,

are also used in SPF calculation. The router does not detect any faults of the link that is in the
Down state and still tries forwarding packets through this link.
The 3-way handshake mechanism solves these problems on P2P links. In 3-way handshake
mode, the router regards the neighbor as Up only after confirming that the neighbor receives the
packet that it sends and then sets up an adjacency with the neighbor.
In addition, the 3-way handshake mechanism adopts the 32-bit Extended Local Circuit ID field.
This extends the original 8-bit Extended Local Circuit ID field and P2P links increase to more
than 255 in quantity.
NOTE
By default, the 3-way handshake mechanism of IS-IS is implemented on P2P links, as defined in RFC
3373.
5.3.11 IS-IS GR
IS-IS Graceful Restart (GR) implements non-stop forwarding by extending IS-IS to support the
GR capability. It is one of the high availability (HA) technologies. RFC 3847 defines the IS-IS
GR standard.
IS-IS is a link state routing protocol. All routers in an area must maintain the same network
topologies, that is, the same LSDBs.
After the master/slave switchover, no neighbor information is stored on the restarted router.
Thus, the first Hello packets sent by the router do not contain the neighbor list. After receiving
the Hello packets, the neighbor checks the 2-way neighbor relationship and finds that it is not
in the neighbor list of the Hello packets sent by the router. Thus, 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 then calculate routes based on the new LSDBs, which leads to route
interruption or routing loops.
Because no LSDB is stored on the restarted router, the router needs to synchronize its LSDB
with those of the neighbors after the master/slave switchover.
If IS-IS is not restarted in GR mode, IS-IS neighbor relationships are reset and LSPs are
regenerated and flooded. This triggers the SPF calculation in the entire area, which causes route
flapping and forwarding interruption in the area.
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. Thus, the route flapping and
interruption of the traffic forwarding caused by the restart can be avoided.
When a router fails, neighbors at the routing protocol layer detect that their neighbor relationships
are Down and then become Up again after a period of time. This is the flapping of neighbor
relationships. The flapping of neighbor relationships causes route flapping, which leads to black
hole routes on the restarted router or causes data services from the neighbors to be looped on
the restarted router. This decreases the reliability on the network. GR is thus introduced to address
route flapping.
Basic Concepts of IS-IS GR

IS-IS GR involves two roles, namely, GR restarter and GR helper.
l GR restarter

The GR restarter refers to the router that restarts in GR mode.

l GR- helper
The GR helper refers to another GR router that helps the restarter to complete the GR
process. The GR restarter must have the capability of the GR helper.
NOTE
By default, the device supports the GR helper.
To implement GR, IS-IS introduces the restart Type-Length-Value (TLV), T1 timer, T2 timer,
and T3 timer.
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 contains the restart TLV. The restart TLV carries the parameters for the
protocol restart. Figure 5-19 shows the format of the restart TLV.
Figure 5-19 Format of the Restart TLV

0 1 2 3 4 5 6 7
Type(211)
Length(1 to 9)
Reserved SA RA RR
Remaining Time
Restarting Neighbor System ID
Table 5-7 describes the fields of the restart TLV.
Table 5-7 Description of the fields of the restart TLV
Type 1 byte Indicates the TLV type. If the value is 211, the TLV is the
restart TLV.
Length 1 byte Indicates the length of the TLV.
RR 1 bit Indicates the restart request bit. A router sends an RR packet

to notify the neighbors of its restarting or starting and to require
the neighbors to retain the current IS-IS adjacency and return
CSNPs.
RA 1 bit Indicates the restart acknowledgement bit. A router sends an

RA packet to respond to the RR packet.

SA 1 bit Indicates the suppress adjacency advertisement bit. The

starting router uses an SA packet to require its neighbors to
suppress the broadcast of their neighbor relationships to
prevent routing loops.
Remaining 2 bytes Indicates the time during which the neighbor does not reset the
Time adjacency. The length of the field is 2 bytes. The time is
measured in seconds. When RA is reset, the value is mandatory.
Restarting 6 bytes Indicates the system ID of the neighboring router that responds
Neighbor to the RA packet.
System ID
Timers
Three timers are introduced to enhance IS-IS GR. They are T1, T2, and T3 timers.
l T1
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 respectively.
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 will reset the T1 timer and continues to send the
restart TLV.
If the ACK packet is received or the T1 timer expires for three times, the T1 timer is deleted.
The default value of a T1 timer is 3 seconds.
l T2
Level-1 and Level-2 LSDBs maintain separate T2 timers.
T2 is the maximum time that the system waits for the synchronization of various LSDBs.
T2 is generally 60 seconds.
l T3
The entire system maintains a T3 timer.
T3 timer can be considered as the maximum time for GR to complete.
If the T3 timer expires, GR fails.
The initial value of the T3 timer is 65535 seconds. After the IIH packets that carry the RA
are received from neighbors, the value of the T3 timer becomes the smallest value of the
Remaining Time field among the Remaining Time fields of the IIH packets.
The T3 timer applies to only restarting devices.
Session Mechanism of IS-IS GR

For differentiation, GR triggered by the master/slave switchover or the restart of an IS-IS process
is referred to as restarting. In this case, the FIB table remains unchanged. GR triggered by router
restart is referred to as starting. In this case, the FIB table is updated.
The following describes the process of IS-IS GR in restarting and starting modes:

IS-IS Restarting
Figure 5-20 shows the process of IS-IS restarting.
Figure 5-20 Process of IS-IS restarting
GR Restarter GR Helper
Active/standby
switchover
Start T1, T2, IIH (Restart TLV, RR=1, RA=0, SA=0)

and T3 timers
IIH (Restart TLV, RR=0, RA=1, SA=0)

Reset T3 timer
CSNP
Delete T1 timer
LSPs
Delete T2 timer
Delete T3 timer and Flood LSPs Update the

Update the FIB table FIB table
1. After performing the protocol restart, the GR restarter performs the following actions:
l Starts T1, T2, and T3 timers.
l 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:
l Maintains the neighbor relationship and refreshes the current Holdtime.
l Replies 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.
l Sends CSNPs and all LSPs to the GR restarter.
NOTE
l On a P2P link, a neighbor must send CSNPs.

l 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 GR helper does not support GR, it ignores the restart TLV and resets the adjacency
with the GR restarter according to the normal processing of IS-IS.
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:

l Compares the current value of the T3 timer with the value of the Remaining Time field
in the packet. The smaller one is taken as the value of the T3 timer.
l Deletes the T1 timer maintained by the interface that receives the ACK packet and
CSNPs.
l 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 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.
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 has been synchronized.
l In the case of a Level-1 or Level-2 router, the SPF caculation is triggered.
l 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 the T2 timers are deleted, the 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 the
LSDB synchronization, the GR restarter deletes the LSPs generated before GR.
7. So far, the IS-IS restarting of the GR restarter is complete.
IS-IS Starting
The starting device does not keep the FIB table. Thus, the starting device hopes the neighbors,
whose adjacency with itself is Up before it starts, 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 5-21.

Figure 5-21 Process of IS-IS starting
GR Restarter GR Helper
Starting
Start T2 timer for IIH (Restart TLV, RR=0, RA=0, SA=1)

various LSPDBs
Reestablish the adjacency relationship
Start T1 timer
CSNP
Delete T1 timer
LSPs
Delete T2 timer
Update the Flood LSPs Update the

FIB table FIB table
1. After the GR restarter is started, it performs the following actions:

l Starts the T2 timer for the synchronization of LSDBs of each level.
l Sends IIH packets that contain the restart TLV from all interfaces. In such a packet, RR
is set to 0, and SA is set to 1.
If RR is set to 0, a router is started.
If SA 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 according to whether GR is supported:
l 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.
l GR is not supported.
Ignores the restart TLV and resets the adjacency with the GR restarter.
Replies an IIH packet that does not contain the restart TLV. The neighbor then turns to
the 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 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. So far, the IS-IS starting of the GR restarter is complete.
GR is typically applied on PEs, especially single point PEs. In the scenario where a single point
PE fails, or master/slave switchover occurs on a PE due to maintenance operations such as
upgrading the software version, GR is configured to ensure non-stop forwarding of key services.
Figure 5-22 shows the networking.
Figure 5-22 Application of GR on the provider network
VPN A VPN B
CE-1 PE3 CE-2
PE1
IS-IS Level-2 PE4

VPN A IBGP Full mesh
PE2 AS#100 VPN B
CE-3
CE-4

NOTE
NSF is deployed on PE2 to prevent single-node failure on PE2; IS-IS GR, BGP GR, and LDP GR run on
PE2.
On the PEs, IS-IS, BGP, or LDP GR is run. On the Ps, IS-IS or LDP GR is run. The MPU/SRUs
on the PEs and Ps work in backup mode.
5.3.12 IS-IS NSR

Non-Stop Routing (NSR) is a technology that the control plane of a neighbor does not sense the
fault when the control plane of a router that provides a slave control plane. In this process, the
neighbor relationships set up through specific routing protocols, MPLS, and other protocols that
carry services are not interrupted.
As an HA solution, NSR ensures that user services are not affected in the case of device failures.
Background
As networks develop fast, operators pose high requirements for reliability on IP networks. NSR,
as an HA solution, is thus introduced to ensure that services transmitted by a device are not
affected when a hardware or software failure occurs on the device.
Implementation Principle
IS-IS NSR ensures that the real-time data is highly synchronized between the master and slave
MPU/SRUs. In this manner, in the case of the master/slave switchover, the slave MPU/SRU can
rapidly take over services on the master MPU/SRU with neighbors not sensing router failures.
IS-IS NSR synchronizes the real-time data between the master and slave MPU/SRUs in the
following manners:
l IS-IS backs up configuration data and dynamic data that includes information about
interfaces, neighbors, and LSDBs.
l IS-IS does not back up the status of the socket but transmits and receives packets through
the RawLink Socket.
l IS-IS does not back up routes, SPTs, and Traffic Engineering DataBases (TEDBs), which
can be restored through the source data in the real-time data backup process.
l When the master/slave switchover occurs, the new master MPU/SRU restores the operation
data and takes over services on the former master MPU/SRU with neighbors not sensing
or almost not sensing router failures.
5.3.13 IS-IS for IPv6

Extended IS-IS for IPv6 is defined in the draft-ietf-isis-ipv6 of IETF. Extended IS-IS processes
and calculates IPv6 routes. The draft introduces two TLVs and a Network Layer Protocol
Identifier (NLPID) for extended IS-IS to support IPv6.
The two new TLVs are:
l IPv6 Reachability
The type value is 236 (0xEC). It illustrates the reachability of the network by defining the
routing prefix and metric.

l IPv6 Interface Address

The type value is 232 (0xE8). It is equal to the IP interface address TLV of IPv4, except
that it changes the original 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.
5.3.14 IS-IS MT
Principles of IS-IS MT
IS-IS Multi-Topology (MT) enables IS-IS to support multi-topology. Complying with RFC
5120, IS-IS MT defines new TLV types in IS-IS packets to transmit multi-topology information.
A physical network can be divided into different logical topologies as needed. Each logical
topology calculates routes by using the Shortest Path First (SPF) algorithm and maintains its
own routing tables. In this manner, traffic of different services (including the traffic in different
IP topologies) can be forwarded along different paths. Therefore, IS-IS MT can help customers
better utilize networks and reduce costs for network construction.
IS-IS MT has the following functions:

l Separation between an IPv4 topology and an IPv6 topology
IS-IS implements IPv6 by extending TLV and complies with the rules of establishing and
maintaining neighbor databases and topology databases as defined in ISO 10589 and RFC
1195. Therefore, IPv4 and IPv6 networks have the same topology. The IPv4 and IPv6
hybrid topology can be regarded as an integrated topology, which uses the SPF algorithm
to calculate routes. It is required that all IPv4 and IPv6 topology information be the same.
In applications, however, not all devices on the same network support both IPv4 and IPv6.
This may result in inconsistency between IPv4 and IPv6 topology information. In an IPv4
and IPv6 hybrid topology, some routers and links do not support IPv6. Routers supporting
IPv4/IPv6 dual-stack, however, cannot detect these routers and links, and will still forward
IPv6 packets to them. As a result, the IPv6 packets fail to be forwarded and are thus
discarded by the devices that do not support IPv6. IPv4 packets will also fail to be forwarded
if some routers and links do not support IPv4 in an IPv4 and IPv6 hybrid topology.
IS-IS MT uses the SPF algorithm on an IPv6 topology, and sets up a routing table on each
device in the IPv6 topology. This solves the problem of inconsistency between IPv4 and
IPv6 topology information.
l Separation between a unicast topology and a multicast topology
In traditional IP networks, there is only one unicast topology and one unicast forwarding
table on each device. Traffic with the same destination address shares the same next hop.
The multicast Reverse Path Forwarding (RPF) check depends on the unicast routing table.
If multicast uses the default unicast routing table, the following problems may occur:
Multicast depends heavily on unicast routes. As a result, changes in unicast routes affect
the establishment of a Multicast Distribution Tree (MDT).
The MDT cannot be established for multicast services without using unicast routes.
With IS-IS MT, a separate multicast topology can be set up for multicast services, and the
multicast topology is separated from the unicast topology. The preceding problems can
thus be solved.

Networking Application
Figure 5-23 shows the networking diagram of separation between IPv4 and IPv6 topologies.
The values in the networking diagram are link costs. Router A, Router C, and Router D support
IPv4/IPv6 dual-stack; Router B supports IPv4 only and cannot forward IPv6 packets.
Figure 5-23 Networking diagram of separation between IPv4 and IPv6 topologies
RouterA RouterB
IPv4/IPv6 IPv4
4
IPv4
reachable 3
IPv6 6
dropped
5
RouterC RouterD
IPv4/IPv6 IPv4/IPv6
If IS-IS MT is not used, Router A, Router B, Router C, and Router D consider the IPv4 and IPv6
topologies the same when using the SPF algorithm for route calculation. In this case, the shortest
path from Router A to Router D is Router A -> Router B- > Router D. Router B does not support
IPv6, so Router B cannot forward IPv6 packets to Router C.
If IS-IS MT is used to set up a separate IPv6 topology, Router A chooses only IPv6 links to
forward IPv6 packets. In this case, the shortest path from Router A to Router D is Router A ->
Router C -> Router D. IPv6 packets are thus correctly forwarded.
Figure 5-24 shows the networking diagram of separation between a unicast topology and a
multicast topology by means of IS-IS MT.

Figure 5-24 Networking diagram of IS-IS MT
RouterB
TE-Tunnel
RouterA RouterE
PC RouterC Source
RouterD
Topology blue
Multicast topology
As shown in Figure 5-24, all routers run IS-IS and are connected to one another. TE tunnels are
set up between the routers, and the tunnel is along the path of Router A -> Router E. The outbound
interface of the route calculated by IS-IS may not be a physical interface but a TE tunnel interface.
In this case, the routers between which the TE tunnel is established cannot correctly set up
multicast forwarding entries. As a result, multicast services cannot run properly.
By means of IS-IS multi-topology, topologies, for example, topology blue, can be set up for
common services, and multicast topologies can be set up for multicast services. TE tunnels are
not contained in a multicast topology, and therefore multicast services can run properly, without
being affected by TE tunnels.
5.3.15 IS-IS TE
IS-IS Traffic Engineering (TE) is an extension of IS-IS to support MPLS TE. As specified in
RFC 5305 and RFC 4205, IS-IS TE defines new TLVsand sub-TLVs in IS-IS LSPs to carry TE
information, floods LSPs to implement the flooding and synchronization of TE information, and
transmits TE information to the CSPF module.
IS-IS TE supports MPLS to set up and maintain the Constraint-based Routed Label Switched
Paths (CR-LSPs).
When constructing the Constraint-based Routed LSP (CR-LSP), MPLS needs to learn the traffic
attributes of all the links in this area. MPLS can acquire the TE information of the links through
IS-IS.
Traditional routers select the shortest path as the master route regardless of other factors, such
as bandwidth. In this manner, the traffic is not switched to other paths even if a path is congested.

Figure 5-25 IS-IS route defects
RouterC
RouterD
RouterH
RouterB
RouterE
RouterA
RouterF RouterG
As shown in Figure 5-25, assume that each link has the same metric. The shortest path from
Router A/Router H to Router E is Router A/Router H -> Router B -> Router C -> Router D ->
Router E. Data is forwarded along this shortest path though other paths exist. In this manner,
the path Router A/Router H -> Router B -> Router C -> Router D -> Router E may be congested,
and the path Router A/Router H -> Router B -> Router F -> Router G -> Router D -> Router E
may be idle.
To solve the preceding problem, you can adjust the link metric. After analyzing the topology,
we adjust the metric of the path Router B-Router C to 3. In this manner, the traffic can be led to
the path Router A/Router H -> Router B -> Router F -> Router G -> Router D -> Router E.
This method eliminates the congestion on the link Router A/Router H -> Router B -> Router C
-> Router D -> Router E; however, the other link Router A/Router H -> Router B -> Router F -
> Router G -> Router D -> Router E may be congested. On the network of a complicated
topology, the metric is difficult to adjust because the change of a link may affect multiple routes.
As an overlay model, MPLS can set up a virtual topology over the physical network topology,
and then map the traffic to this virtual topology. Thus, MPLS TE that integrates MPLS with TE
emerges.
MPLS TE has advantages in solving the problem of network congestion. Through MPLS TE,
the provider can precisely control the traffic path and prevent the traffic from passing through
congested nodes. Meanwhile, MPLS TE can reserve resources to ensure the quality of services
during the establishment of LSPs.
To ensure the continuity of services, MPLS TE introduces the LSP backup and fast reroute (FRR)
mechanisms. When faults occur on the link, the traffic can be switched immediately. Through
MPLS TE, service providers (SPs) can fully utilize the current network resources to provide
diversified services, optimize network resources, and scientifically manage the network.
To achieve the preceding purpose, MPLS needs to learn TE information of all routers in this
network. MPLS TE lacks such a mechanism through which each router floods its TE information
in the entire network to implement the synchronization of TE information. This mechanism is

provided by the IS-IS protocol. Thus, MPLS TE can advertise and synchronize TE information
with the help of the IS-IS protocol. The IS-IS protocol needs to be extended to support MPLS
TE.
IS-IS TE is an extension of IS-IS to support MPLS TE. IS-IS TE defines new TLVs in IS-IS
LSPs to carry TE information and floods LSPs to implement the flooding and synchronization
of TE information. IS-IS TE then extracts TE information from all LSPs and then transmits the
TE information to the CSPF module of MPLS for calculating tunnel paths.
To put it simply, IS-IS TE collects TE information in the IS-IS network and then transmits the
TE information to the CSPF module.
Basic Principle
IS-IS Traffic Engineering (TE) is an extension of IS-IS to support MPLS TE. As specified in
RFC 5305 and RFC 4205, IS-IS TE defines new TLVs in IS-IS LSPs to carry TE information
and helps MPLS implement the flooding, synchronization, and resolution of TE information.
IS-IS TE then transmits the resolved TE information to the CSPF module. IS-IS TE plays the
role of a porter in MPLS TE. Figure 5-26 shows the relationships between IS-IS TE, MPLS TE,
and CSPF.
Figure 5-26 Relationships between MPLS TE, CSPF, and IS-IS TE
MPLS TE
TE management
Feedback
Advertising
And Adjust
CSPF IS-IS TE
calculating TE Flooding TE
collecting
To carry TE information in LSPs, IS-IS TE defines the following TLVs in RFC 5305:
l Extended IS reachability TLV
This TLV takes the place of IS reachability TLV and extends the TLV formats with sub-
TLVs. Sub-TLVs are implemented in TLVs in the same manner as TLVs are implemented
in LSPs. Sub-TLVs are used to carry TE information configured on physical interfaces.
NOTE
Currently, all sub-TLVs defined in RFC 5305 and sub-TLV type 22 defined in RFC 4124 are
supported.

Table 5-8 Sub-TLVs defined in Extended IS reachability TLV

Name Typ Length (Byte) Value
e
Administrative Group 3 4 Indicates the administrative

group.
IPv4 Interface Address 6 4 Indicates the IPv4 address of

a local interface.
IPv4 Neighbour Address 8 4 Indicates the IPv4 address of

a neighbor interface.
Maximum Link Bandwidth 9 4 Indicates the maximum

bandwidth of a link.
Maximum Reserved Link 10 4 Indicates the maximum

Bandwidth reserved bandwidth of a link.
Unreserved Bandwidth 11 32 Indicates the unreserved

bandwidth.
Traffic Engineering Default 18 3 Indicates the default metric

Metric of TE.
Bandwidth Constraints sub- 22 36 Indicates the TLV of the

TLV bandwidth constraint.
l Traffic Engineering router ID TLV

It is of TLV type 134, with a 4-byte Router ID. It is used as the MPLS LSR ID. In MPLS
TE, a Router ID uniquely identifies a router. Each router has a Router ID.
l Extended IP reachability TLV
This TLV takes the place of IP reachability TLV and carries routing information. It extends
the length of the route cost field and carries sub-TLVs.
l Shared Risk Link Group TLV
It is of TLV type 138 and used to carry information about the shared risk link group. This
TLV can carry information about multiple shared links, each of which is a 4-byte positive
integer.
IS-IS TE is implemented in two processes.
l Process of responding to MPLS TE configurations.
IS-IS TE functions only after MPLS TE is enabled.
IS-IS TE updates the TE information in IS-IS LSPs based on MPLS TE configurations.
IS-IS TE transmits MPLS TE configurations to the CSPF module.
l Process of handling TE information in LSPs.
IS-IS TE extracts TE information from IS-IS LSPs and transmits the TE information to the
CSPF module.

In typical applications, IS-IS TE helps MPLS TE set up TE tunnels. As shown in Figure 5-27,
a TE tunnel is set up between Router A and Router D.
Figure 5-27 Diagram of IS-IS TE networking

RouterB
RouterA RouterC
Tunnel
RouterD
The requirements are as follows:

l Enable MPLS TE on Router A and enable MPLS TE CSPF to calculate the path.
l Enable MPLS TE on Router B, Router C, and Router D.
l Run IS-IS on Router A, Router B, Router C, and Router D to realize communication
between the routers and enable IS-IS TE on each router.
After the configuration, IS-IS on Router A, Router B, Router C, and Router D respectively sends
LSPs carrying TE information configured on each router. Router A then obtains the TE
information of Router B, Router C, and Router D from the received LSPs. The CSPF module
can calculate the path required by the TE tunnel based on the TE information in the entire
network.
5.3.16 IS-IS Shortcut (AA) and Advertise (FA)

IS-IS Shortcut (AA) and IS-IS Advertise (FA) calculate routes through TE tunnel interfaces.
This feature is not clearly defined in RFC 3906. TE tunnel interfaces are used as outbound
interfaces of routes; thus, packets are transmitted through MPLS instead of IP.
For the traffic transmitted through a specific route, MPLS guarantees the forwarding comparing
with IP, which is unreliable. When IS-IS Shortcut (AA) and IS-IS Advertise (FA) are configured,
MPLS forwarding is achieved with TE tunnel interfaces involving in route calculation and being
the outbound interfaces of specific routes.

Figure 5-28 Principle of IS-IS Shortcut (AA) and Advertise (FA)
TE tunnel FA 10
10 10 10 10
RouterE RouterA RouterB RouterC RouterD

5
RouterT
IS-IS Shortcut (AA)

If the TE tunnel does not participate in the IS-IS route calculation, packets from Router A to
Router T should pass through Router B. Thus, the interface that connects Router A to Router B
is the outbound interface.
If packets from Router A to Router C need to travel through the TE tunnel, you can enable IS-
IS Shortcut (AA) and the IS-IS process on the TE tunnel interfaces. Then, Router A considers
that the cost of the path to Router C is 10 and then selects the tunnel interface as the outbound
interface.
IS-IS Shortcut (AA) is meaningful only on the local interface and functions unidirectionally.
l IS-IS Shortcut (AA) is meaningful only on the local interface.

Router A does not send the message that "Router A has a direct route to Router C", but
sends the message that "The cost of the route from Router A to Router T is 15". Instead of
knowing that packets from Router A can be transmitted to Router C through the TE tunnel,
Router E only knows that the cost of the route from Router E to Router T through Router
A is 25 (10+15).
l IS-IS Shortcut (AA) functions unidirectionally.
Generally, IS-IS considers a link applicable only after bidirectional detection is
implemented on the link. If Router B does not consider Router A as its neighbor, Router
A then does not consider the link to Router B applicable.
IS-IS Shortcut (AA) is meaningful only on the local interface and thus bidirectional
detection cannot be implemented. If a unidirectional tunnel works normally, it indicates
that the link is applicable.
IS-IS Shortcut (AA) does not affect the original structure of the IS-IS SPF tree, irrespective of
whether a TE tunnel exists or not. Apart from the link from Router A to Router B, and that from
Router B to Router C, a link marked with an S from Router A to Router C is added. S is short
for Shortcut. The link marked with an S participates in route calculation.
IS-IS Shortcut (AA) provides two types of metrics.
l Absolute metric
It indicates that the metric value of TE tunnels in IS-IS is fixed.

l Relative metric
It indicates that the metric value of TE tunnels in IS-IS is relative. The route cost is the
costs of the physical links plus the relative metric value.
As shown in Figure 5-28, if the relative metric is set to 1, the cost of the path from Router A to
Router C through the TE tunnel is 21 (10+10+1).
If the relative metric is set to 0, it indicates that the TE tunnel and physical link are of equal-cost
on the outbound interface. If the relative metric is less than 0, it indicates that the TE tunnel
interface is preferred as the outbound interface.
The metric of IS-IS Shortcut (AA) is prior to the IS-IS cost. If the metric of IS-IS Shortcut (AA)
is not configured, IS-IS adopts the IS-IS cost of the TE tunnel interface. If the metric of IS-IS-
Shortcut (AA) is configured, IS-IS adopts the value.
IS-IS Advertise (FA)

Similar to IS-IS Shortcut (AA), IS-IS Advertise (FA) also calculates routes through TE tunnel
interfaces. Currently, there is no RFCs or drafts detailing this feature.
The algorithm of IS-IS Advertise (FA) is the same as that of IS-IS Shortcut (AA).
The differences between IS-IS Advertise (FA) and IS-IS Shortcut (AA) are listed as follows:
l IS-IS Advertise (FA) advertises the TE tunnel information to other ISs, whereas IS-IS
Shortcut (AA) does not.
As shown in Figure 5-28, if the TE tunnel is enabled with IS-IS Advertise (FA), Router
A advertises information indicating that Router C is its neighbor. The neighbor information
is carried in TLV type 22 with no sub-TLVs. That is, no TE information is carried. If the
TE tunnel is enabled with IS-IS Shortcut (AA), Router A does not advertise such
information.
l IS-IS Advertise (FA) functions only when bidirectional TE tunnels are configured.
If the TE tunnel is enabled with IS-IS Advertise (FA), Router C must advertise information
indicating that Router A is its neighbor. Then, the TE tunnel interface can be used by Router
A to forward traffic. If the TE tunnel is enabled with IS-IS Shortcut (AA), Router A does
not check whether Router C is its neighbor.
l IS-IS Advertise (FA) affects the SPF tree of other routers.
If the TE tunnel is enabled with IS-IS Advertise (FA), Router A advertises the message
that "Router C is a neighbor of Router A" to other routers on the network. Other routers
then consider Router C a neighbor of Router A and add Router C to the SPF tree without
marking it with an S.
l IS-IS Advertise (FA) does not support relative metric.
IS-IS Advertise (FA) functions on the entire network. Thus, note the following when
deploying IS-IS Advertise (FA):
TE tunnels enabled with IS-IS Advertise (FA) are preferred to be bidirectional.
As shown in Figure 5-28, you must enable IS-IS Advertise (FA) on the TE tunnel from
Router C to Router A so that the TE tunnel from Router A to Router C can be applicable.
If there are P2P neighbors between the two devices enabled with IS-IS Advertise (FA),
a unidirectional TE tunnel can also be applicable.
As shown in Figure 5-28, if the TE tunnel from Router A to Router B is enabled with
IS-IS Advertise (FA), and Router A and Router B areconnected through networks other
than Ethernet, this TE tunnel is applicable. In this case, the physical link from Router

B to Router A acts as a TE tunnel enabled with IS-IS Advertise (FA) in the other
direction.
5.3.17 IS-IS Wide Metric

As defined in RFC 3784, the value of an interface metric can be extended to 16777215, and the
metric of a route can reach 4261412864.
On large-scale networks, a small range of metrics cannot meet the requirements. Moreover, IS-
IS TE needs to be supported. Thus, wide metric is introduced.
In the earlier ISO 10589, the greatest value of an interface metric can be only 63. TLV type 128
and TLV type 130 contain information about routes; TLV type 2 contains information about IS-
IS neighbors.
After IS-IS wide metric is enabled, TLV type 135 contains information about routes; TLV type
22 contains information about IS-IS neighbors.
l The following lists the TLVs used in narrow mode:
IP Internal Reachability TLV: carries internal routes.
IP External Reachability TLV: carries external routes.
IS Neighbors TLV: carries information about neighbors.
l The following lists the TLVs used in wide mode:
Extended IP Reachability TLV: replaces the earlier IP reachability TLV and carries
information about routes. This TLV expands the range of route cost to 4 bytes and carries
sub-TLVs.
IS Extended Neighbors TLV: carries information about neighbors.
NOTE
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.
Table 5-9 List of modes of receiving and sending
Mode\Receiving and Receiving Sending

Sending
narrow narrow narrow
narrow-compatible narrow&wide narrow
compatible narrow&wide narrow&wide
wide-compatible narrow&wide wide
wide wide wide
When the cost-style is set to compatible, IS-IS sends the information in narrow mode and in
wide mode respectively.

Process
CAUTION
The change of cost-style causes the IS-IS process to be restarted. Thus, be cautious to use the
cost-style command.
l Changing the sending mode from narrow to wide

The information used to be carried by TLV type 128, TLV type 130, and TLV type 2 is
now carried by TLV type 135 and TLV type 22.
l Changing the sending mode from wide to narrow
The information used to be carried by TLV type 135 and TLV type 22 is now carried by
TLV type 128, TLV type 130, and TLV type 2.
l Changing the sending mode from narrow/wide to narrow&wide
The information used to be carried in narrow/wide mode is now carried by TLV type 128,
TLV type 130, TLV type 2, TLV type 135, and TLV type 22.
l IS-IS wide metric must be enabled before you use IS-IS TE.
l IS-IS wide metric must be enabled before you use administrative tags. For details, see 5.3.7
IS-IS Administrative Tag.
5.3.18 IS-IS Local MT

IGP local multicast-topology (MT) creates a separate multicast topology on the local device,
without affecting the protocol packets exchanged between devices. When the outbound interface
calculated by an IGP for the route is a TE tunnel interface enabled with IGP Shortcut (AA), IGP
local MT then calculates one or a group of actual physical outbound interfaces for the route.
NOTE
The mentioned TE tunnel specifies the TE tunnel enabled with IGP Shortcut (AA).
On the network where both multicast and a TE tunnel are deployed, multicast may fail to function
because the IGP protocol, such as IS-IS and OSPF, may adopt the TE tunnel interface as the
outbound interface of a unicast route.
Local MT is thus introduced to address the conflict between the TE tunnel and multicast. Local
MT is configured at the ingress of a TE tunnel, and the protocol packets exchanged between
devices are not affected. Thus, it is easy to configure and no interconnectivity problem arises.
Local MT is an effective solution to the backbone network where a TE tunnel and multicast are
deployed simultaneously.
Background
When multicast and an MPLS TE tunnel are deployed in a network simultaneously, the multicast
function may be affected by the TE tunnel.
This is because after the TE tunnel is enabled with IGP Shortcut (AA), the outbound interface
of a route calculated by an IGP is not the actual physical interface but a TE tunnel interface.
According to the unicast route to the multicast source address, a router sends a Report message

through a TE tunnel interface. Routers spanned by the TE tunnel cannot sense the Report
message, so multicast forwarding entries cannot be created. The TE tunnel is unidirectional, so
multicast data packets sent by the multicast source are sent to the routers spanned by the tunnel
through the related physical interfaces. The routers do not have any multicast forwarding entry.
Thus, the multicast data packets are discarded. Figure 5-29 shows the networking.
Figure 5-29 TE tunnel scenario
172.16.1.2/24 Client Server 192.168.3.2/24
GE1/0/0 GE2/0/0
172.16.1.1/24 192.168.3.1/24
Router-id Router-id
RouterA 1.1.1.1 RouterE
5.5.5.5
GE2/0/0 GE1/0/0
10.0.0.1/24 10.0.3.3/24
GE1/0/0 GE1/0/0
10.0.0.2/24 RouterB 10.0.3.1/24 RouterD
Router-id Router-id
Tunnel1/0/0 4.4.4.4
2.2.2.2
GE2/0/0 RouterC GE2/0/0
10.0.1.2/24 10.0.2.1/24
Router-id
Tunnel1/0/0 3.3.3.3 Join
Multicast
GE1/0/0 GE2/0/0 Packets
10.0.1.1/24 10.0.2.2/24
RouterA, RouterB, RouterC, RouterD, and RouterE are Level-2 routers. The routers run IS-IS
to implement interconnection. The multicast services are normal. A unidirectional MPLS TE
tunnel is set up between RouterB and RouterD. The MPLS TE tunnel is enabled with IGP
Shortcut (AA). When you view the multicast routing table on RouterC spanned by the TE tunnel,
you cannot find any multicast forwarding entry. Thus, the multicast services are interrupted.
The process of transmitting multicast packets between the client and the multicast server is as
follows:
1. To join a multicast group, the client sends a Report message to RouterA. RouterA then
sends a Join message to RouterB.
2. When the Join message reaches RouterB, RouterB uses Tunnel 1/0/0 as the Reverse Path
Forwarding (RPF) interface and forwards the message to RouterC through GE 2/0/0 by
using the MPLS label.
3. The Join message is forwarded with the MPLS label, so RouterC just forwards the message
and does not create a multicast routing entry. In the topology shown in Figure 5-29,
RouterC is the penultimate hop of the MPLS forwarding. RouterC pops out the MPLS label,
and then forwards the Join message to RouterD through GE 2/0/0.
4. After receiving the Join message, RouterD creates a multicast forwarding entry. The
inbound interface is GE 2/0/0 and the outbound interface is GE 1/0/0. RouterD then
forwards the message to RouterE. The SPT is thus set up.

5. When the multicast source sends the traffic to RouterD, RouterD forwards the traffic to
RouterC. RouterC does not create any forwarding entry in advance. Therefore, the traffic
is discarded and the multicast service is interrupted.
As described in the preceding process of transmitting multicast packets, the forwarding of
multicast packets relies on the unicast routing table and the TE tunnel is unidirectional.
Therefore, the multicast packets are discarded. This problem can be avoided by using the
following methods:
l Manually configuring static multicast routes to guide the forwarding of multicast
packets
l Configuring a bidirectional TE tunnel
In this case, the returned multicast packets can be sent by using the same tunnel. Routers
spanned by the TE tunnel use the tunnel to transmit multicast packets.
l Configuring the Multicast Border Gateway Protocol (MBGP) to separate the unicast
topology from the multicast topology
MBGP provides the topology that does not contain the TE tunnel for multicast
separately. Multicast is used to perform RPF check on MBGP routes.
l Configuring local MT
The preceding methods are used to prevent the interruption of multicast services. The
disadvantage of the first three methods is that a lot of manual configurations need to be
done. As a result, if the network is complex, the planning, configuration, and maintenance
tasks become heavier. Therefore, in the preceding network environment, local MT needs
to be configured.
The device supports local MT. As a result, the case that the multicast services are interrupted
when multicast and the MPLS TE tunnel enabled with IGP Shortcut (AA) are deployed can be
avoided.
After local MT is enabled, the router at the ingress of a TE tunnel creates a separate multicast
IGP (MIGP) routing table to store the physical interfaces to which the TE tunnel corresponds.
This ensures that multicast protocol packets are correctly forwarded. The correct routing entries
are created in the multicast routing table (MRT). Figure 5-30 shows the networking.

Figure 5-30 Local MT Topology
172.16.1.2/24 Client Server 192.168.3.2/24
GE1/0/0 GE2/0/0
172.16.1.1/24 192.168.3.1/24
RouterA Router-id Router-id
1.1.1.1 RouterE
5.5.5.5
GE2/0/0 GE1/0/0
10.0.0.1/24 10.0.3.3/24
GE1/0/0 GE1/0/0
10.0.0.2/24 RouterB RouterD 10.0.3.1/24
Router-id Tunnel1/0/0 Router-id
2.2.2.2 4.4.4.4
GE2/0/0 RouterC GE2/0/0
10.0.1.2/24 10.0.2.1/24
Router-id
Tunnel1/0/0 3.3.3.3 Join
Multicast
GE1/0/0 GE2/0/0 Packets
10.0.1.1/24 10.0.2.2/24
l Create an MIGP routing table.

Multicast protocol packets are forwarded according to the unicast routing table. After local
MT is enabled on RouterB, RM creates separate MIGP routing tables for multicast
protocols. When the outbound interface of a route is a TE tunnel interface, an IGP calculates
out the actually physical outbound interface for the route and adds the outbound interface
to the MIGP routing table.
l Guide the forwarding of multicast protocol packets.
Before forwarding a multicast protocol packet, a router needs to search the unicast routing
table. If the router finds that the next hop is the TE tunnel, the router continues to search
the MIGP routing table for the related physical outbound interface to guide the forwarding
of the multicast protocol packet.
If the outbound interface of multicast source 192.168.3.2/24 is TE tunnel 1/0/0, the physical
outbound interface of the route calculated by IS-IS is GE 2/0/0. IS-IS installs the route to the
MIGP routing table. The multicast services are thus not affected by the TE tunnel. Multicast
packets are forwarded through the physical outbound interfaces according to the MIGP routing
table for the general IP forwarding. The related routing entries are created in the MRT. Multicast
data packets are thus correctly forwarded.
The principle of local MT is to create a separate multicast topology on the local device, without
affecting the protocol packets exchanged between devices. Take the topology in Figure 5-30 as
an example. After configuring local MT on RouterB, you can find that the (S,G) entries generated
by sending Join messages and multicast data are displayed as shown in Figure 5-31.

Figure 5-31 Local MT addressing the conflict between multicast and a TE tunnel
GE6/0/0 GE6/0/1
GE6/0/0 GE6/0/1 GE6/0/3 GE6/0/1
RouterA RouterB RouterC RouterD RouterE

Tunnel6/0/0
URT
Multicast 10.10.10.10/24 T6/0/0
User MIGP Multicast Source
10.10.10.10/24 E6/0/1
10.10.10.10/24
RouterB creates a separate MIGP routing table. If the outbound interface of the route
10.10.10.10/24 calculated by an IGP is Tunnel 6/0/0, an IGP then calculates out the actual
physical outbound interface GE 6/0/1. In this manner, the multicast services are not affected by
the TE tunnel.
5.3.19 IS-IS LDP Synchronization

In the networking where primary and backup LSPs are used, when the primary LSP recovers,
traffic is switched from the backup LSP back to the primary LSP.
IGP route convergence is complete before the establishment of an LDP session. Consequently,
the old LSP has been deleted, whereas the new LSP has not been established. As a result, LSP
traffic is interrupted.
As shown in Figure 5-32, the primary LSP adopts the path PE1 -> P1 -> P2 -> P3 -> PE2, and
the backup LSP adopts the path PE1 -> P1 -> P4 -> P3 -> PE2.
When the primary LSP is faulty, traffic is switched to the backup LSP. After the primary LSP
recovers, traffic is switched back from the backup LSP to the primary LSP. During this process,
traffic is interrupted for a long time.
NOTE
The LSP mentioned in this feature is short for Label Switch Path.

Figure 5-32 Networking for IS-IS LDP synchronization
P2
PE1 P1 P3 PE2
P4
Synchronizing LDP and IGP on P1 and P2 can shorten traffic interruption caused by traffic
switchover from the backup LSP to the primary LSP.
To prevent packet loss during traffic switchback, LDP-IGP synchronization is provided by

delaying the traffic forwarded by IGP routes switchback until LDP sessions are established. That
is, before an LSP is set up, the old LSP is not deleted and continues to forward traffic.
Figure 5-33 LDP-IGP synchronization state machine
1 4
Init
3 1
2
3
3
Hold 6 Hold 5 Hold

time out max cost down
2 4
4 2
Achieve
3
The numbers in Figure 5-33 are described as follows:

l 1 indicates that an interface is Up.

l 2 indicates that an LDP session is Down.
l 3 indicates that an interface is Down.
l 4 indicates that an LDP session is Up.
l 5 indicates that an LDP route is reachable or the Hold Down Timer expires.
l 6 indicates that Hold max cost Timer expires.
l State description
Init: indicates the initial LDP-IGP synchronization state.
Holdtimeout: indicates the expires state of an interface.
Holddown: indicates the holddown state of an interface. In the Holddown state, an
interface suppresses the receiving and sending of Hello packets.
HoldMaxCost: indicates that an interface advertises the maximum cost.
Sync Achieved: indicates the LDP-IGP synchronization state.
l State transition description
In the Init state,and when the LDP session is Down,an interface moves to the HoldDown
state when it receives a message indicating that the interface is Up.
In the Init state, and when the LDP session is Up,an interface moves to the Achieve
state when it receives a message indicating that the interface is Down.
In the Holdtimeout state, an interface moves to the Init state when it receives a message
indicating that the interface is Down.
In the Holdtimeout state, an interface moves to the Achieve state when it receives a
message indicating that the LDP session is Up.
In the HoldMaxCost state, an interface moves to the Init state when it receives a message
indicating that the interface is Up.
If the HoldMaxCost Timer expires, an interface moves to the Holdtimeout state when
it not receives a message indicating that the LDP session is Up.
If the HoldDown Timer expires, or an interface in the Achieve state receives a message
indicating that the LDP session is Down.
If the HoldDown Timer expires, or an interface in the Init state receives a message
If the HoldDown Timer expires, or an interface in the HoldDown state receives a
message indicating that the LDP route is unreachable, the interface moves to the
HoldMaxCost state.
In the Achieve state, an interface moves to the HoldMaxCost state when it receives a
message indicating that the LDP session is Down.
In the Achieve state, an interface moves to the Init state when it receives a message
In the networking shown in Figure 5-32, LDP-IGP synchronization can be configured to prevent
packet loss during traffic switchover from the backup LSP to the primary LSP.

5.3.20 BFD for IS-IS

BFD functions as a simple "Hello" protocol. It is similar to the adjacency test of a routing protocol
in many aspects.
Two systems periodically send BFD packets on the path between them. If one system does not
receive any BFD packet from its peer within the detection period, the system considers that the
bidirectional path to its peer is faulty. Under some conditions, systems need to negotiate the
sending and receiving rates to reduce the load.
BFD is classified into static BFD and dynamic BFD.
NOTE
BFD uses the local discriminator and remote discriminator to differentiate multiple BFD sessions between
the same pair of systems.
l Static BFD
In static BFD, BFD session parameters including local and remote discriminators are set
through commands, and the requests for establishing BFD sessions are manually delivered.
l Dynamic BFD(including BFD for IPv4BFD for IPv6)
In dynamic BFD, the establishment of BFD sessions is triggered by routing protocols. The
local discriminator is dynamically assigned, and the remote discriminator is learned by a
routing protocol.
BFD-for-IPv4 sessions and BFD-for-IPv6 sessions are established separately and do not
affect each other.
In BFD for IS-IS, the establishment of a BFD session is dynamically triggered by IS-IS instead
of being performed manually. When detecting a fault, BFD notifies IS-IS of the fault through
the RM module. IS-IS then sets the status of the associated neighbor relationship to Down,
rapidly advertises the changed Link State PDU (LSP), and performs incremental SPF. In this
manner, fast route convergence is implemented.
Generally, the interval for sending Hello packets is set to 10s. The interval for advertising that
a neighbor is Down, that is, the Holddown time for keeping the neighbor relationship, is three
times the interval for sending Hello packets. If a router does not receive any Hello packet from
its neighbor within the Holddown time, the router deletes the associated neighbor relationship.
A router can detect a neighbor fault at only the second level. As a result, a large number of
packets may be lost on a high-speed network.
BFD, which can provide link fault detection of light load and high speed (in milliseconds), is
introduced to solve the preceding problem.
BFD can provide millisecond-level fault detection. BFD does not take the place of the Hello
mechanism of IS-IS, but works with IS-IS to more quickly detect the faults that occur on
neighboring devices or links, and instructs IS-IS to recalculate routes to correctly guide packet
forwarding.
Static BFD
In static BFD, BFD session parameters including local and remote discriminators are set through
commands, and the requests for establishing BFD sessions are manually delivered.
In this mode, the creation and deletion of BFD sessions need to be triggered manually, which is
inflexible. Moreover, manual configuration errors may occur, for example, the local

discriminator and the remote discriminator are incorrectly configured, which causes the
abnormal functioning of the BFD session.
Dynamic BFD
In dynamic BFD, the establishment of BFD sessions is triggered by routing protocols.The
establishment of a BFD-for-IPv4 session is triggered by IS-IS when an IPv4 neighbor
relationship is set up.The establishment of a BFD-for-IPv6 session is triggered by IS-IS when
an IPv6 neighbor relationship is set up.
When setting up a new neighbor relationship, IS-IS sends parameters of the neighbors and
detection parameters (including source and destination IP addresses) to BFD. BFD then sets up
a session according to the received parameters. Dynamic BFD is more flexible than static BFD.
The RM module provides related services for the association with the BFD module for IS-IS.
Through RM, IS-IS instructs BFD to set up or tear down BFD sessions by sending notification
messages. In addition, BFD events are transmitted to IS-IS through RM.
Establishment and Deletion of BFD Sessions

l 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.
NOTE
On an IPv6 network, basic IS-IS IPv6 functions need to be configured.
BFD is enabled on each router, and BFD for IPv4 or BFD for IPv6 is enabled on
interfaces or processes of the routers.
BFD for IPv4 or BFD for IPv6 is enabled on interfaces or processes, and the status of
the neighboring router is Up (the DIS must be elected on a broadcast network).
Neighbors can adopt IPv4 and IPv6.
l 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.
On a broadcast network, the routers (including non-DIS routers) of the same level on the
same network segment can set up neighbor relationships. In the implementation of IS-IS
BFD, however, BFD sessions are set up between the DIS and non-DIS devices rather than
between non-DISs. On a P2P network, BFD sessions are directly set up 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 neighbor and the Level-2 neighbor on a broadcast
network, but sets up only one BFD session on a P2P network.
l If the IP protocol type of neighbors includes IPv4 and IPv6, IS-IS sets up two sessions: a
BFD-for-IPv4 session and a BFD-for-IPv6 session. The IPv6 link-local addresses of the
related interfaces are used to set up the BFD-for-IPv6 session.
l Conditions for tearing down a BFD session

P2P network
When a neighbor relationship set up on P2P interfaces by IS-IS is torn 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 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.
When the configurations of a dynamically established BFD session are deleted or BFD for
IS-IS is disabled on an interface, all BFD sessions to which neighbor relationships between
devices or between devices and the DIS correspond on the interface are deleted.
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.
NOTE
BFD detects only one-hop links between IS-IS neighbors, because IS-IS establishes only one-hop
neighbor relationships.
l Response to the Down event of a BFD session
When detecting a link failure, BFD generates a Down event, and then notifies RM of the
event. RM then instructs IS-IS to deletes the neighbor relationship. IS-IS recalculates routes
to speed up route convergence on the entire network.After BFD for IPv4 informs IS-IS of
the link failure, IS-IS changes only the IPv4 route.After BFD for IPv6 notifies IS-IS of the
link failure, IS-IS changes only the IPv6 route.
When a router and its neighbor are Level-1-2 routers, they set up two neighbor relationships,
that is, the Level-1 neighbor relationship and the Level-2 neighbor relationship. Then, IS-
IS sets up two BFD sessions for the Level-1 neighbor relationship and the Level-2 neighbor
relationship. In this case, the RM module deletes the neighbor relationship of a specific
level.
Applicable Environment
CAUTION
BFD needs to be configured according to the actual network environment. If timer parameters
are set improperly, network flapping may occur.
BFD for IS-IS can fast sense link changes to implement route convergence.

Figure 5-34 Networking diagram of BFD for IS-IS
Router A Switch Router B
Primary path
Backup path
Router C
The configuration requirements are as follows:

l Enable IS-IS on the routers, as shown in Figure 5-34.
NOTE
Before configuring BFD for IS-IS IPv6, you need to configure IS-IS IPv6.
l Enable BFD globally.
l Enable BFD for IS-IS on Router A and Router B.
Thus, when the link between Router A and Router B becomes faulty, BFD can fast detect the
fault and then notify it to IS-IS. IS-IS then turns the neighbor relationship on the interface Down
and deletes the IP protocol type to which the neighbor relationship corresponds, which triggers
route calculation. In addition, IS-IS updates LSPs so that the neighbors such as Router C can
receive updated LSPs from Router B. Fast convergence of IS-IS is thus implemented.
5.3.21 IS-IS Auto FRR

IS-IS Auto Fast Reroute (FRR) is a type of dynamic IP FRR. In IS-IS Auto FRR, an IGP pre-
computes a backup link for a primary link based on the LSDBs on the entire network and stores
it in the forwarding table, and switches traffic to the backup link if the primary link fails. In this
manner, the failure recovery time can be within 50 ms.
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.
Background
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 50 ms to rectify the fault, which cannot meet the requirement for real-
time transmission services on the network.
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 NE80E/40E supports IPv4 and IPv6 IS-IS Auto FRR.
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.
In the scenario where a BFD session is bound to IS-IS Auto FRR, when BFD detects a link fault
on an interface, the BFD session goes Down, triggering FRR on the interface. After that, the
traffic is switched from the faulty link to the backup link, which thus protects the traffic.
IS-IS Auto FRR supports the following types of TE links:
l IP protecting TE
As shown in Figure 5-35, 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 IS-IS 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 physical 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 5-35 IP protecting TE

Router S TE Tunnel: IS-IS cost = 1 Router D
IS-IS cost = 13
IS
-I S
co
1
t=
s t=
s
co
10
-I S
IS
Router N
Traffic in normal
Traffic in case of failure
l TE protecting IP
As shown in Figure 5-36, 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 thus implemented.
Figure 5-36 TE protecting IP

Router S TE Tunnel: IS-IS cost = 12 Router D
IS-IS cost = 13
IS
1
-I S
=
st
co
co
st
-I S
=
IS
10
Router N
Traffic in normal
Traffic in case of failure
IS-IS Auto FRR traffic protection 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 IS-IS
Auto FRR-enabled link. The link cost must satisfy the inequality: Distance_opt(N, D) <
Distance_opt(N, S) + Distance_opt(S, D). In the inequality, S indicates the source node of traffic,
N indicates a node on the backup link, and D indicates the destination node of traffic.
As shown in Figure 5-37, traffic is forwarded from Router S to Router D. The link cost satisfies
the link protection inequality. When the primary link fails, Router S switches traffic to the backup
link from Router S to Router N so that the traffic can be further transmitted along downstream
paths. This ensures that the traffic interruption period is less than 50 ms.
Figure 5-37 IS-IS Auto FRR link protection
cost = 10
RouterS c RouterD
os
10
t=
=
10
st
co
RouterN

Link-node dual protection: Figure 5-38 shows link-node dual protection of IS-IS Auto FRR.
Node protection takes precedence over link protection.
Link-node dual protection must satisfy the following situations:
l The link cost must satisfy the inequality: Distance_opt(N, D) < Distance_opt(N, S) +
Distance_opt(S, D).
l 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 5-38 IS-IS Auto FRR link-node dual protection

RouterE
co
st
5
=
=
st
10
co
RouterS co RouterD
st
10
=
=
10
st
co
RouterN
5.3.22 IS-IS Authentication

IS-IS authentication encrypts IS-IS packets by adding the authentication field to packets to
ensure network security. When a local router receives IS-IS packets from a remote router, the
local router discards the packets if finding that the authentication passwords do not match. This
protects the local router.
According to the types of packets, the authencation is classified into the following:
l Area authentication
It is configured in the IS-IS process view to authenticate Level-1 CSNPs, PSNPs, and LSPs.
l Routing domain authentication
It is configured in the IS-IS process view to authenticate Level-2 CSNPS, PSNPs, and LSPs.
l Interface authentication
It is configured in the interface view to authenticate Level-1 and Level-2 Hello packets.
According to the authentication modes of packets, the authentication is classified into the
following:
l Plain text authentication

It is a simple authentication mode in which passwords are directly added to packets. This
imposes security threats. Thus, the MD5 authentication is introduced.

l MD5 authentication
In MD5 authentication, passwords are encrypted through the MD5 algorithm before they
are added to packets. This improves the security of the passwords.
l Keychain authentication
In Keychain authentication, you can configure the key chain that changes with time to
further improve network security.
IS-IS provides a TLV to carry authentication information, with the type of the TLV specified as
10.
l Type
The ISO defines the type of the authentication packets as 10, with a length of 1 byte.
l Length
It indicates the length of the authentication TLV, which is 1 byte.
l Value
It indicates the contents of the authentication, including the authentication type and
authenticated password, which ranges from 1 to 254, in bytes.
The authentication type is 1 byte.
Type 0 is reserved.
Type 1 indicates plain text authentication.
Type 54 indicates MD5 authentication.
Type 255 is used for routing domain private authentication methods.
The authentication password is saved in the following modes:
l The authentication password for IIH packets are saved on interfaces. It is implemented as
interface authentication.
l The authentication password for Level-1 LSPs and SNPs are saved in the IS-IS process. It
is implemented as area authentication.
l The authentication password for Level-2 LSPs and SNPs are saved in the IS-IS process. It
is implemented as routing domain authentication.
Interface authentication can be classified into the following:
l A router sends authentication packets with the authentication TLV and verifies the
authentication information of the packets it receives.
l A router sends authentication packets with the authentication TLV but does not verify the
authentication information of the packets it receives.
For the area authentication and routing domain authentication, you can set a router to authenticate
SNPs and LSPs separately.
l A router sends LSPs and SNPs carrying the authentication TLV and verifies the
authentication information of the LSPs and SNPs it receives.
l A router sends LSPs carrying the authentication TLV and verifies the authentication
information of the LSPs it receives. The router sends SNPs carrying the authentication TLV
but does not verify the authentication information of the SNPs it receives.
l A router sends LSPs carrying the authentication TLV and verifies the authentication
information of the LSPs it receives. The router sends SNPs without the authentication TLV
and does not verify the authentication information of the SNPs it receives.

l A router sends LSPs and SNPs carrying the authentication TLV but does not verify the
authentication information of the LSPs and SNPs it receives.
Figure 5-39 Networking for IS-IS authentication on a broadcast network

RouterA RouterB RouterC
RouterD RouterE
The requirements are as follows:

l IS-IS neighbor relationships can be set up between multiple routers on the same network
only when interface authentication is configured in the same manner on all the routers.
l When multiple routers are in the same area, you must configure area authentication in the
same manner on all the routers to ensure the synchronization of their Level-1 LSDBs.
l When Level-2 neighbor relationships are set up between multiple routers, you must
configure routing domain authentication in the same manner on all the routers to ensure
the synchronization of their Level-2 LSDBs.

Terms
Term Description
s
TLV Type-Length-Value
TLV encoding features high efficiency and expansibility. It is also called Code-
Length-Value (CLV).
T indicates that different types can be defined through different values.
L indicates the total length of the value field.
V indicates the actual data of the TLV and is most important.
TLV encoding features high expansibility. New TLVs can be added to support new
features, which is flexible in describing information loaded in packets.

Term Description
s
LSP Link State Protocol Data Unit

It broadcasts link states in the area and contains all information about a router. The
information includes IS-IS neighbors, IP address prefix, the ES it is connected to,
and the area address. LSPs are classified into Level-1 LSPs and Level-2 LSPs. A
router generates one Level-1 LSP and one Level-2 LSP with fragments included.
CSNP Complete Sequence Numbers Protocol Data Unit

It contains brief information about the local LSDB and is used to synchronize the
LSDBs of neighbors. CSNPs are sent and resolved at different levels.
DIS Designated Intermediate System
Pseud A virtual node that is used to simulate a broadcast network. It is generated by the
onodes DIS and sets up neighbor relationships with all routers on the broadcast network.
PE Provider Edge
CE Customer Edge
NSR Non-Stop Routing
Abbreviations
IS-IS Intermediate System-Intermediate System
IGP Interior Gateway Protocol
LSP Link State Protocol Data Unit
CSNP Complete Sequence Numbers Protocol Data Unit
SNP Sequence Number PDU
DIS Designated Intermediate System
TLV Type-Length-Value
SPF Shortest Path First
MI Multiple Instance
MT Multi-topology
Local-MT Local Multicast-Topology
URT Unicast Routing Table
MIGP IGP Routing Table for Multicast
Shortcut (AA) IGP-Shortcut (Auto Announcement)

Advertise (FA) IGP-Advertise (Forwarding Adjacency)
GR Graceful Restart
RM Routing Management
VPN Virtual Private Networks
BFD Bidirectional Forwarding Detection
MPLS Multiprotocol Label Switching
CSPF Constraint-based Shortest Path First
TE Traffic Engineering
LDP Lable Distribution Protocol
LSP Lable Switched Path
SNMP Simple Network Management Protocol
MIB Management Information Base
PE Provider Edge
CE Customers Edge
RIB Routing Information Base
FRR Fast Reroute

Feature Description - IP Routing 6 OSPF
6 OSPF
About This Chapter
6.1 Introduction to OSPF

6.2 References
6.3 Principles
6.4 OSPF Applications

6.1 Introduction to OSPF

Definition
The Open Shortest Path First (OSPF) protocol, developed by the Internet Engineering Task Force
(IETF), is a link-state Interior Gateway Protocol (IGP).
At present, OSPF Version 2, defined in RFC 2328, is intended for IPv4, and OSPF Version 3,
defined in RFC 2740, is intended for IPv6. OSPF stated in this document refers to OSPFv2,
unless otherwise stated.
Purpose
Before the emergence of OSPF, the Routing Information Protocol (RIP) is widely used on
networks as an IGP.
RIP is a routing protocol based on the distance vector algorithm. Due to its slow convergence,
routing loops, and poor scalability, RIP is gradually replaced by OSPF.
As a link-state protocol, OSPF can solve many problems encountered by RIP. Additionally,
OSPF features have the following advantages:
l Transmits packets in multicast mode to reduce load on the routers that do not run OSPF.
l Supports Classless Interdomain Routing (CIDR).
l Supports load balancing among equal-cost routes.
l Supports packet encryption.
With the preceding advantages, OSPF is widely accepted and used as an IGP.
6.2 References
RFC 1587 This document describes a new optional type of -

OSPF areas, somewhat humorously referred to as
a "not-so-stubby" area (or NSSA). NSSAs are
similar to the existing OSPF stub area
configuration option but have the additional
capability of importing AS external routes in a
limited fashion.
RFC 1765 Proper operation of the OSPF protocol requires This RFC is
that all OSPF routers maintain an identical copy experimental and
of the OSPF link-state database. However, when non-standard.
the size of the link-state database becomes very
large, some routers may be unable to keep the
entire database due to resource shortages; we term
this "database overflow".

RFC 2328 This memo documents version 2 of the OSPF -

protocol. OSPF is a link-state routing protocol.
RFC 2370 This memo defines enhancements to the OSPF -

protocol to support a new class of link-state
advertisements (LSA) called Opaque LSAs.
Opaque LSAs provide a generalized mechanism
to allow for the future extensibility of OSPF.
RFC 3137 This memo describes a backward-compatible This RFC is

technique that may be used by OSPF (Open informational and
Shortest Path First) implementations to advertise non-standard.
unavailability to forward transit traffic or to lower
the preference level for the paths through such a
device.
RFC 3623 This memo documents an enhancement to the -

OSPF routing protocol, whereby an OSPF device
can stay on the forwarding path even as its OSPF
software is restarted.
RFC 3630 This document describes extensions to the OSPF -

protocol version 2 to support intra-area Traffic
Engineering (TE), using Opaque Link State
Advertisements.
RFC 3682 The use of a packet's Time to Live (TTL) (IPv4) This RFC is
or Hop Limit (IPv6) to protect a protocol stack experimental and
from CPU-utilization based attacks has been non-standard.
proposed in many settings.
RFC 3906 This document describes how conventional hop- -

by-hop link-state routing protocols interact with
new Traffic Engineering capabilities to create
Interior Gateway Protocol (IGP) shortcuts.
RFC 4576 This document specifies the necessary procedure, -

using one of the options bits in the LSA (Link State
Advertisements) to indicate that an LSA has
already been forwarded by a PE and should be
ignored by any other PEs that see it.
RFC 4577 This document extends that specification by -

allowing the routing protocol on the PE/CE
interface to be the Open Shortest Path First
(OSPF) protocol.

RFC 4750 This memo defines a portion of the Management -

Information Base (MIB) for use with network
management protocols in TCP/IP-based internets.
In particular, it defines objects for managing
version 2 of the Open Shortest Path First Routing
Protocol. Version 2 of the OSPF protocol is
specific to the IPv4 address family.
6.3 Principles
6.3.1 Fundamentals of OSPF

OSPF has the following advantages:
l Divides an Autonomous System (AS) into one or multiple logical areas.

l Advertises routes by sending Link State Advertisements (LSAs).
l Synchronizes routing information by exchanging OSPF packets between routers in OSPF
areas.
l Encapsulates OSPF packets in IP packets and then sends the packets in unicast mode or
multicast mode.
OSPF Packet Type
Table 6-1 OSPF packet type
Packet Function
Hello packet Hello packets are sent periodically to discover and

maintain OSPF neighbor relationships.
Database Description (DD) packet DD packets carry brief information about the local Link
State Database (LSDB) and are used to synchronize the
LSDBs of two routers.
Link State Request (LSR) packet LSR packets are used to request the required LSAs
from neighbors.
LSR packets are sent only after DD packets are
exchanged successfully.
Link State Update (LSU) packet LSU packets are used to send the required LSAs to
neighbors.
Link State Acknowledgment LSAck packets are used to acknowledge the received
(LSAck) packet LSAs.

LSA Type
Table 6-2 OSPF LSA type

LSA Function
Router-LSA (Type1) Describes the link status and link cost of a NE80E/40E. It is
generated by each NE80E/40E and advertised in the area to
which the NE80E/40E belongs.
Network-LSA (Type2) Describes the link status of all routers in the local network
segment. It is generated by a designated router (DR) and
advertised in the area to which the DR belongs.
Network-summary-LSA Describe the routes in a network segment and advertise the

(Type3) routes to the related non totally STUB or NSSA area.
ASBR-summary-LSA Describes routes to an Autonomous System Boundary Router

(Type4) (ASBR). It is generated by an ABR and advertised in the
related areas except the area to which the ASBR belongs.
AS-external-LSA (Type5) Describes routes to a destination outside the AS. It is generated

by an ASBR and advertised in all areas except stub areas and
Not-So-Stubby Areas (NSSAs).
NSSA-LSA (Type7) Describes routes to a destination outside the AS. It is generated

by an ASBR and advertised in NSSAs only.
Opaque-LSA (Type9/ Provides a general mechanism for OSPF extension:

Type10/Type11) l Type9 LSAs are advertised in the network segment where
interfaces reside. Grace LSAs used to support GR are one
type of Type9 LSAs.
l Type10 LSAs are advertised in an area. LSAs used to
support TE are one type of Type10 LSAs.
l Type11 LSAs are advertised in an AS. At present, there are
no application examples of Type11 LSAs.
Router Type
Figure 6-1 lists the types of common routers in OSPF.

Figure 6-1 Router type

IS-IS ASBR
Area1 Area4
Internal Router Backbone Router
Area0
Area2 ABR Area3
Table 6-3 OSPF router type

Router Description
Internal router All interfaces of an internal router belong to the same OSPF
area.
Area Border Router (ABR) An ABR can belong to two or more areas, and one of the
areas must be a backbone area.
An ABR is used to connect the backbone area and non-
backbone areas. It can be physically or logically connected
to the backbone area.
Backbone router At least one interface on a backbone router belongs to the

backbone area.
All ABRs and internal routers in Area 0, therefore, are
backbone routers.
AS Boundary Router (ASBR) An ASBR exchanges routing information with other ASs.
An ASBR may not reside at the boundary of an AS. It can be
an internal router or an ABR. If an OSPF router imports
external routes, the router is an ASBR.
OSPF 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 a destination outside an AS. OSPF classifies the imported AS
external routes into Type1 and Type2 external routes.
Table 6-4 lists route types in descending order of priority.

Table 6-4 OSPF route type

Route Description
Intra area Intra-area routes
Inter area Inter-area routes
Type1 external route Because of the high reliability of Type1 external routes, the
calculated cost of external routes equals that of AS internal
routes, and can be compared with the cost of OSPF routes.
That is, the cost of a Type1 external route equals the cost of
the route from the router to the corresponding ASBR plus
the cost of the route from the ASBR to the destination.
Type2 external route Because of the low reliability of Type2 external routes, their
costs are considered greater than the cost of any internal
path to an ASBR.
Thus, the cost of a Type2 external route equals the cost of
the route from the ASBR to the destination.
Area Type
Table 6-5 OSPF area type

Area Function
Totally stub area Allows the Type3 default routes advertised by an ABR, and denies
the routes outside an AS and inter-area routes.
Stub area Allows inter-area routes, which is different from a totally stub area.
NSSA Imports routes outside an AS, which is different from a stub area. An
ASBR advertises Type7 LSAs in the local area.
Totally NSSA Denies inter-area routes, which is different from an NSSA.
OSPF Network Type

According to link layer protocols, OSPF classifies networks into the following types, as shown
in Table 6-6.

Table 6-6 OSPF network type
Network Description
Broadcast If the link layer protocol is Ethernet or Fiber Distributed Data

Interface (FDDI), OSPF defaults the network type to broadcast.
In this type of networks,
l Hello packets, LSU packets, and LSAck packets are
transmitted in multicast mode. The address 224.0.0.5 is the
reserved IP multicast address of the OSPF router, and the
address 224.0.0.6 is the reserved IP multicast address of the
OSPF DR.
l DD packets and LSR packets are transmitted in unicast mode.
Non-Broadcast Multiple If the link layer protocol is frame relay (FR), ATM, or X.25, OSPF
Access (NBMA) defaults the network type to NBMA.
In this type of networks, protocol packets, such as Hello packets,
DD packets, LSR packets, LSU packets, and LSAck packets, are
transmitted in unicast mode.
Point-to-Multipoint Regardless of the link layer protocol, OSPF does not default the
(P2MP) network type to P2MP. A P2MP network must be forcibly changed
from other network types. The common practice is to change a
non-fully connected NBMA network to a P2MP network.
In this type of networks,
l Hello packets are transmitted in multicast mode through the
multicast address 224.0.0.5.
l Other protocol packets, such as DD packets, LSR packets, LSU
packets, and LSAck packets, are transmitted in unicast mode.
Point-to-point (P2P) If the link layer protocol is PPP, HDLC, or LAPB, OSPF defaults
the network type to P2P.
In this type of networks, protocol packets, such as Hello packets,
transmitted in multicast mode through the multicast address
224.0.0.5.
Stub Area
A stub area is a special area where ABRs do not flood the received external routes. In a stub
area, the size of the routing table of routers and routing information in transmission are greatly
reduced.
Configuring a stub area is optional. Not all areas can be configured as stub areas. Generally, 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 an AS, the ABR in a stub area generates a
default route and advertises it to non-ABRs in the stub area.
Note the following when configuring a stub area:

l The backbone area cannot be configured as a stub area.

l If an area needs to be configured as a stub area, all the routers in this area must be configured
with the stub command.
l An ASBR cannot exist in a stub area. That is, external routes are not flooded in the stub
area.
l A virtual link cannot pass through a stub area.
OSPF Packet Authentication

OSPF supports packet authentication. Only the OSPF packets that pass the authentication can
be received. If packets fail to pass the authentication, the neighbor relationship cannot be
established.
The NE80E/40E supports the following authentication modes:
l Area authentication mode
l Interface authentication mode
According to encryption algorithms, the authentication modes supported by the NE80E/40E are
classified into null, simple, MD5, and HMAC-MD5.
When the area authentication mode and interface authentication mode are available, the interface
authentication mode is preferred.
OSPF Route Aggregation

The routes with the same prefix can be aggregated into one route and the aggregated route is
advertised in other areas. This is called route aggregation.
After route aggregation, route information can be reduced. Consequently, the size of routing
tables is reduced, which improves the performance of routers.
Route aggregation can be carried out in the following manners:
l ABR aggregation
When an ABR transmits routing information to other areas, it originates Type3 LSAs per
network segment. If some consecutive segments exist in this area, you can run the related
command to aggregate these segments into one segment. An ABR sends only one
aggregated LSA. Any LSA that belongs to the aggregated network segment specified by
the command is not transmitted separately.
l ASBR aggregation
After route aggregation is enabled, if the local router is an ASBR, it aggregates the imported
Type5 LSAs within the aggregated address range. After an NSSA area is configured, the
ASBR aggregates the imported Type7 LSAs within the aggregated address range.
If the local router is both an ABR and an ASBR, it aggregates Type5 LSAs that are
transformed from Type7 LSAs.
OSPF Default Route

A default route refers to the route whose destination address and mask are all 0s. When a router
does not have exact matching routes, it can forward packets through default routes.
OSPF default routes are applicable to the following situations:

l An ABR advertises the default Type3 summary-LSAs to instruct intra-area routers to

forward packets to other areas.
l An ASBR advertises default Type5 ASE LSAs or Type7 NSSA LSAs to instruct intra-AS
routers to forward packets to other ASs.
The principles for advertising OSPF LSAs describing default routes are as follows:
l An OSPF router advertises an LSA that describes a default route only when an interface
on the OSPF router is connected to a network outside an area.
l If an OSPF router has already advertised an LSA that describes a default route, the OSPF
route no longer learns LSAs of the same type advertised by other routers. The OSPF router
calculates routes by using an LSA describing a default route in an LSDB, but not an LSA
of the same type advertised by another router.
l If the OSPF router needs to advertise an LSA describing a default route only with the help
of another route, the route cannot be the one in the local routing domain, that is, not the
one learned by the local OSPF process. The external default route guides forwarding outside
the local OSPF routing domain but the next hop of the routes in the local OSPF routing
domain are inside the local OSPF routing domain, failing to forward packets outside the
local OSPF routing domain.
According to the hierarchical management of OSPF routes, the priority of the default Type3
routes is higher than that of the default Type5 or Type7 route.
Table 6-7 shows the advertisement of default routes in different areas.
Table 6-7 Principles for advertising area-specific default routes
Area Type Advertising Principles
Common area By default, no default route is generated in a common area, even if a

default route exists in the common area.
After a default route is generated by another process, the default route
must be advertised in an entire OSPF AS. To help OSPF generate a
default route, you need to run a command on an ASBR. After the
configuration, a default ASE LSA (Type5 LSA) is generated and
advertised in the entire OSPF AS.
Stub area AS external routes in Type5 LSAs cannot be advertised in a stub area.
Routers in the stub area have to learn AS external routes from an
ABR. The ABR automatically generates a default summary-LSA
(Type3 LSA) and advertises it in the entire stub area. Then, routers
in the stub area obtain reachable AS external routes through the ABR.
Totally stub area AS external routes in Type5 LSAs or inter-area routes in Type3 LSAs
cannot be advertised in a totally stub area.
Routers in the totally stub area have to learn AS external routes and
the routes to other areas through an ABR. To help OSPF generate a
default router, you need to configure a totally stub area. After the
totally stub area is configured, an ABR automatically generates a
default summary-LSA (Type3 LSA) and advertises it to the entire
totally stub area. Then, routers in the totally stub area obtain reachable
AS external routes and routes to other areas through the ABR.

Area Type Advertising Principles
NSSA area A small number of AS external routes that are obtained through the
ASBR in the NSSA area can be imported to an NSSA area, but routes
to other areas in ASE LSAs (Type5 LSAs) cannot be advertised in
the NSSA area. Routers in the NSSA area obtain AS external routes
only through the ASBR in the same NSSA.
No default route is generated after an NSSA area is configured.
After an NSSA area is configured, either of the following operations
can be performed to help OSPF generate a default route:
l To help obtain AS external routes through the ASBR in the NSSA
area and other external routes through other areas, you need to
configure the relevant command on the ABR. The ABR then
generates a default NSSA LSA (Type7 LSA) and advertises it in
the entire NSSA. In this manner, a small number of AS external
routes can be obtained through the ASBR in the NSSA, and other
routes to other areas can be obtained through the ABR in the NSSA
area connected to ASBR in other areas.
l To help OSPF obtain all external routes only through the ASBR
in the NSSA area, you need to run commands on the ASBR. The
ASBR then generates a default NSSA LSA (Type7 LSA) and
advertises it to the entire NSSA. In this manner, all external routes
can be received only through the ASBR in an NSSA.
In the preceding operations, the same command is run in different
views. On an ABR, a Type7 LSA describing a default route is
generated regardless of whether there is the route to 0.0.0.0 in the
routing table. On an ASBR, a Type7 LSA describing a default route
is generated only when there is the route to 0.0.0.0 in the routing table.
The default route is flooded only in an NSSA area but not flooded in
the entire OSPF area. If no route is found in the NSSA, the LSAs that
are generated in the local NSSA area are sent out from the ASBR in
the NSSA. LSAs of other OSPF areas, however, cannot be sent to
other ASs through the ASBR. A Type7 LSA describing a default route
is neither translated into a Type5 LSA describing a default route on
an ABR nor advertised in the entire OSPF routing domain.
Totally NSSA area External routes in ASE LSAs (Type5 LSAs) to other areas or inter-
area routes in Type3 LSAs cannot be advertised in a totally NSSA
area.
Routers in the totally NSSA area learn routes to other areas from an
ABR. You can configure a totally NSSA area so that an ABR
automatically generates a default Type3 LSA and advertises it to the
entire totally NSSA. In this manner, routes to external areas and inter-
area routes can be advertised in the totally NSSA area through the
ABR.
OSPF Route Filtering

OSPF supports the filtering of routes through routing policies. By default, OSPF does not filter
routes.

Routing policies used by OSPF include the routing policy, ACL, and IP prefix list. For details,
refer to RM Feature Description.
OSPF route filtering is applicable to the following situations:
l Import of routes
OSPF imports the routes that are learnt by other protocols. When OSPF imports routes,
you can filter the routes by configuring routing policies so that OSPF imports only eligible
routes.
l Advertisement of imported routes
OSPF advertises the imported routes to neighbors.
Routing information to be advertised to neighbors can be filtered through the configured
filtering rules. The filtering rules take effect only when being configured on ASBRs because
only the ASBRs can import routes.
l Learning of routes
Filtering rules can be configured to enable OSPF to filter the received intra-area, inter-area,
and AS external routes.
The filtering action determines whether to add routing entries to the routing table. That is,
only the routes that pass the filtering are added to the local routing table. All the routes,
however, can still be advertised from the OSPF routing table.
l Learning of inter-area LSAs
ABRs can be configured to filter the incoming summary-LSAs of the local area through a
command. This configuration takes effect only on ABRs because only the ABRs can
advertise summary-LSAs.
Table 6-8 Differences between inter-area LSA learning and route learning
Inter-area LSA Route Learning

Learning
Filters the incoming Filters only the calculated routes in LSAs to determine whether
LSAs of an area these routes are added to the local routing table.
directly.
l Advertisement of inter-area LSAs

ABRs can be configured to filter the outgoing summary-LSAs of the local area through a
command. This configuration takes effect only on ABRs.
OSPF Virtual Link

A virtual link refers to a logical channel established between two ABRs through a non-backbone
area.
l A virtual link must be configured on both ends of the link; otherwise, it does not take effect.
l A transit area refers to the area that provides an internal route of a non-backbone area for
both ends of the virtual link.
According to RFC 2328, during the deployment of OSPF, all the non-backbone areas need to
be connected to the backbone area. Otherwise, some areas will be unreachable.

As shown in Figure 6-2, Area 2 is not connected to the backbone area (Area 0), and Router A
is not an ABR. Therefore, Router A does not advertise routing information of Network 1 in Area
0. As a result, Router B does not have the route to Network 1.
Figure 6-2 Non-Backbone Area Not Connected to the Backbone Area
RouterB
Network1
Area1 Area2
Area0
ABR RouterA
In actual applications, physical connectivity between non-backbone areas and backbone areas
cannot be ensured because of various limitations. To solve this problem, you can configure OSPF
virtual links.
A virtual link is similar to a P2P connection between two ABRs. Similar to physical interfaces,
the interfaces on both ends of the virtual link can be configured with parameters such as the
interval for sending Hello packets.
Figure 6-3 OSPF virtual link
Area0 Area2
Virtual Link
ABR Area1 ABR
Transit Area
As shown in Figure 6-3, OSPF packets transmitted between two ABRs are only forwarded by
the OSPF routers that reside between the two ABRs. These routers detect that they are not the
destinations of the packets, thus forwarding the packets as common IP packets.
OSPF Multi-process
OSPF supports multi-process. Multiple OSPF processes can run on the same router, and they
are independent of each other. Route interaction between different OSPF processes is similar to
route interaction between different routing protocols.
An interface of a router belongs to only a certain OSPF process.
A typical application of OSPF multi-process is to run OSPF between PEs and CEs in the VPN
where OSPF is also adopted in the backbone network. On the PEs, the two OSPF processes are
independent of each other.

6.3.2 OSPF GR
Routers generally operate with the separation of the control plane and forwarding plane. When
the network topology remains stable, the restart of the control plane does not affect the
forwarding plane, and the forwarding plane can still forward data properly. This ensures non-
stop service forwarding.
In graceful restart (GR) mode, the forwarding plane continues to direct data forwarding once a
restart occurs, and the actions on the control plane, such as the re-establishment of neighbor
relationships and route calculation, do not affect the forwarding plane. In this manner, service
interruption caused by route flapping is prevented so that the network reliability is improved.
Basic Concepts
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 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.
Concepts involved are as follows:
l 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 GR starts and ends.
l Role of a router during GR
Restarter: indicates the router that restarts. The Restarter can be configured to support
totally GR or partly GR.
Helper: refers to the router that helps the Restarter. The Helper can be configured to
support planned GR or unplanned GR or selectively support GR through the configured
policies.
l Cause of GR
Unknown: indicates that GR is triggered by 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.
l 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.
Classification of GR
l Totally GR: indicates that when a neighbor of a router does not support GR, the router exits
from GR.

l 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.
l Planned GR: indicates that a router restarts or performs the master/slave switchover by
using the command. The Restarter sends a grace LSA before restart or master/slave
switchover.
l Unplanned GR: indicates that a router restarts or performs the master/slave switchover
because of faults. A router directly 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.
GR Process
l A router starts GR.
In planned GR mode, after the master/slave switchover is triggered through a command,
the Restarter sends a grace LSA to all neighbors to inform 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 for five consecutive times. 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.
l GR process
Figure 6-4 OSPF GR process
RouterA RouterB
Restarter Helper
Before the active/ Grace-LSA
Enter Helper
standby switchover
Switchover LSAck Return LSAck
Finish switchover packet for the
Grace-LSA received LSA
Updates the GR
Enter GR
period for the
Grace-LSAs received
Send Hello packets, negotiate, Grace-LSAs
exchange DD packets, and
synchronize LSDB
Full
Exit GR successfully, Flush Grace-LSA Exit the Helper
calculate routes, and successfully and
generate LSA generate Router-LSA

l The router exits from GR.
Table 6-9 Cause that a router exits from GR

Executi Restarter Helper
on of
GR
GR Before GR expires, the Restarter re- After the Helper receives the
succeed establishes neighbor relationships with all grace LSA with the Age being
s. the neighbors before the master/slave 3600s from the Restarter, the
switchover. neighbor relationship between
the Helper and Restarter enters
the Full state.
GR l GR expires, and neighbor l The Helper does not receive

fails. relationships do not recover the grace LSA from the
completely. Restarter before the neighbor
l The router LSA or network LSA sent relationship expires.
by the Helper causes the Restarter to l The status of the interface
fail to perform bidirectional check. that functions as the Helper
l The status of the interface that changes.
functions as the Restarter changes. l The Helper receives the LSA
l The Restarter receives the 1-way that is inconsistent with the
Hello packet from the Helper. LSA in the local LSDB from
another router. This situation
l The Restarter receives the grace LSA can be excluded after the
that is generated by another router on Helper is configured not to
the same network segment. On the perform strict LSA check.
same network segment, only one
router can perform GR. l The Helper receives the
grace LSAs from two routers
l On the same network segment, on the same network
neighbors of the Restarter have segment at the same time.
different DRs or BDRs because the
topology changes. l Neighbor relationships
between the Helper and other
neighbors change.

Comparison between the GR Mode and Non-GR Mode
Table 6-10 Comparison between the GR mode and non-GR mode
Master/slave Switchover in Non-GR Master/slave Switchover in GR Mode

Mode
l OSPF neighbor relationships are re- l OSPF neighbor relationships are re-
established. established.
l Routes are recalculated. l Routes are recalculated.
l The forwarding table changes. l The forwarding table remains unchanged.
l The entire network detects route l Except the neighbors of the device where the
changes, and route flapping occurs for master/slave switchover occurs, other
a short period of time. routers do not detect route changes.
l Packets are lost during forwarding, and l No packets are lost during forwarding, and
services are interrupted. services are not affected.
6.3.3 OSPF TE
OSPF Traffic Engineering (TE) is a new feature extended on the basis of OSPF to support MPLS
TE and establish and maintain the Label Switch Path (LSP) of TE. In the MPLS TE architecture
described in "MPLS Feature Description", OSPF functions as the information advertising
component, responsible for collecting and advertising MPLS TE information.
In addition to the network topology, TE also needs to know network constraints, such as the
bandwidth, TE metric, administrative group, and affinity attribute. Current OSPF functions,
however, cannot meet these requirements. Therefore, OSPF needs to be extended by introducing
a new type of LSAs to advertise network constraints. Based on the network constraints, the
Constraint Shortest Path First (CSPF) algorithm can calculate the path that satisfies certain
constraints.
Figure 6-5 Function of OSPF in the MPLS TE architecture
IGP route Route

selection seletction
LSP is set up component LSP is set up
Signaling
LSA TEDB
component
Information Information
flooding flooding
Message advertisement
Incoming Outgoing
packets packets
Packet forwarding component

Function of OSPF in the MPLS TE Architecture

In the MPLS TE architecture, OSPF functions as the information advertising component:
l Collects related information about TE.

l Floods TE information between routers in the same area.
l Uses the collected TE information to form the TE database (TEDB) and provides it for
CSPF to calculate routes.
OSPF does not care what the specific information is or how MPLS uses the information.
TE-LSA
OSPF uses a new type of LSAs, namely, Type10 opaque LSAs, to collect and advertise TE
information. This type of LSAs contain the link status information required by TE, including
the maximum link bandwidth, maximum reservable bandwidth, current reserved bandwidth, and
link color. Type10 opaque LSAs synchronize link status information among routers in an area
through the OSPF flooding mechanism. In this manner, a uniform TEDB is formed for route
calculation.
Interaction between OSPF TE and CSPF

OSPF collects TE information in an area by using Type10 LSAs, including the bandwidth,
priority, and link metric. After processing the TE information, OSPF provides it for CSPF to
calculate routes.
IGP Shortcut and Forwarding Adjacency

OSPF supports IGP shortcut and forwarding adjacency. The two features allow OSPF to use a
tunnel interface as an outgoing interface to reach a destination.
Differences between IGP shortcut and forwarding adjacency are as follows:
l A router enabled with IGP shortcut uses a tunnel interface as an outgoing interface, but it
does not advertise the tunnel interface to neighbors. Therefore, other routers cannot use
this tunnel.
l A router enabled with forwarding adjacency uses a tunnel interface as an outgoing interface,
and advertises the tunnel interface to neighbors. Therefore, other routers can use this tunnel.
l IGP shortcut is unidirectional and needs to be configured only on the router that uses IGP
shortcut.
l Forwarding adjacency is bidirectional and needs to be configured on the routers on both
ends of the tunnel.
6.3.4 OSPF VPN
Definition
As an extension of OSPF, OSPF VPN multi-instance enables Provider Edges (PEs) and
Customer Edges (CEs) in VPN networks to run OSPF for interworking and use OSPF to learn
and advertise routes.

Purpose
As a widely used IGP, in most cases, OSPF runs in VPN networks. If OSPF runs between PEs
and CEs, and PEs advertise VPN routes to CEs through OSPF, CEs need not to support other
routing protocols for interworking with PEs. This simplifies management and configuration of
CEs.
Running OSPF between PEs and CEs

In BGP/MPLS VPN, routing information is transmitted between PEs through MP-BGP, whereas
routes are learned and advertised between PEs and CEs through OSPF.
Running OSPF between PEs and CEs features the following advantages:
l OSPF is used in a site to learn routes. Running OSPF between PEs and CEs can reduce the
protocol types supported by CEs, thus reducing the requirements for CEs.
l Similarly, running OSPF both in a site and between PEs and CEs simplifies the work of
network administrators. In this manner, network administrators are not required to be
familiar with multiple protocols.
l When the network, which originally uses 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 6-6, 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 6-6 Running OSPF between PEs and CEs
VPN1 VPN1
Site1 Site3
Area1
Area0
CE1 CE3
Area0 Area0
MPLS VPN
OSPF 100 VPN1
OSPF 100 VPN1 Backbone
Area1 PE1 PE2 Area1

OSPF 200 VPN2 OSPF 200 VPN1
CE2 CE4
Area1 Area2
Site2 Site4
VPN2 VPN1
The process of advertising routes of CE1 to CE3 and CE4 is as follows:
1. PE1 imports OSPF routes of CE1 into BGP to form BGP VPNv4 routes.
2. PE1 advertises BGP VPNv4 routes to PE2 through 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.
Configuring OSPF Areas between PEs and CEs

OSPF areas between PEs and CEs can be either non-backbone areas or backbone areas (Area
0), and PEs function always as ABRs.
In the application of OSPF VPN, the MPLS VPN backbone network is considered as Area 0.
OSPF requires connectivity between backbone areas (Area 0). Therefore, Area 0 of all VPN
sites must be connected to the MPLS VPN backbone network. If a VPN site has Area 0, the PEs
that CEs access must be connected to the backbone area of this VPN site through Area 0. In this
case, a virtual link can also be used to implement logical connection between the PEs and the
backbone area, as shown in Figure 6-7.
Figure 6-7 Configuring OSPF areas between PEs and CEs
VPN
PE1 backbone PE2
Area0 Area0
Area1
Virtual link
CE1 CE2 Area0

Site1 Site2
Area0
As shown in Figure 6-7, a non-backbone area (Area 1) is configured between PE1 and CE1,
and a backbone area (Area 0) is configured in Site 1. Then, the backbone area in Site 1 is separated
from the VPN backbone area. In this case, a virtual link is configured between PE1 and CE1 to
maintain connectivity between backbone areas.
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.
l Domain IDs identify and differentiate different domains.

l Each OSPF domain has one or multiple domain IDs, one of which is a primary ID and
others are secondary IDs.
l If an OSPF instance does not have specific domain IDs, 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 (Type3 or Type5) to be advertised to CEs according to domain IDs.
l If local domain IDs are the same as or compatible with remote domain IDs in BGP routes,
PEs advertise Type3 routes.

l Otherwise, PEs advertise Type5 routes.
Table 6-11 Domain ID
Comparison Between Local and Remote Equal or Type of Route to Be

Domain IDs Not Equal Generated
Both are null. Equal Inter-area route
The remote domain ID equals the local Equal Inter-area route

primary domain ID or one of the local
secondary domain IDs.
The remote domain ID does not equal the Not equal If the local area is a non-
local primary domain ID or any of the local NSSA, external routes are
secondary domain IDs. generated.
If the local area is an NSSA,
NSSA routes are generated.
Routing Loop Prevention

Routing loops may occur when OSPF and BGP learn routes from each other between PEs and
CEs.
Figure 6-8 OSPF VPN routing loops
PE1
VPN
backbone
vpn1 site1 10.1.1.1/32
CE1
PE2
As shown in Figure 6-8, on PE1, OSPF imports a BGP route to 10.1.1.1./32, and then a Type5
or Type7 LSA is generated and advertised 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 it 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.

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.
Additionally, the preference of an OSPF route is higher than that of a BGP route. Therefore, on
PE1 and 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 aging. The same process repeats,
which causes route flapping.
OSPF VPN provides solutions to this problem, as shown in Table 6-12.
Table 6-12 Routing loop prevention

Feature Definition Function
DN-bit To prevent routing loops, an OSPF When advertising the

multi-instance process uses one bit as a generated Type3, Type5, or
flag bit, which is called the DN-bit. Type7 LSAs to CEs, PEs set
the DN-bit of these LSAs to
1 and the DN-bit of other
LSAs to 0.
When calculating routes, the
OSPF multi-instance process
of a PE ignores the LSAs with
the DN-bit being 1. This
avoids routing loops that
occur when PEs learn the
self-originated LSAs from
CEs.
VPN route tag The VPN route tag is carried in the When a PE detects that the
Type5 or Type7 LSA generated by PEs VPN route tag in the
according to the received BGP private incoming LSA is the same as
route. that in the local LSA, the PE
Not transmitted in BGP extended ignores this LSA.
community attributes, the VPN route Consequently, routing loops
tag is valid only on the PEs that receive are avoided.
BGP routes and generate OSPF LSAs.
Default route A route with the destination address PEs do not calculate default
and mask being all 0s is a default route. routes.
Default routes forward the
traffic from CEs or the sites
where CEs reside to the VPN
backbone network.

Sham Link
OSPF sham links are unnumbered P2P links between two PEs over an MPLS VPN backbone
network.
Generally, BGP extended community attributes carry routing information over the MPLS VPN
backbone between BGP peers. OSPF running on the other PE can use the routing information
to generate inter-area routes from PEs to CEs.
Figure 6-9 OSPF sham link
MPLS VPN backbone
PE1 sham link PE2
Area 1 Area 1
OSPF 200 OSPF 200
CE12 CE22
VPN1 VPN1
site1 site3
backdoor
As shown in Figure 6-9, if an intra-area OSPF link exists between the network segments of local
and remote CEs, this OSPF link is called a backdoor link.
The routes that pass through the backdoor link are intra-area routes and have higher preferences
than the inter-area routes that pass through the MPLS VPN backbone network. As a result, VPN
traffic is always forwarded through the backdoor route instead of the backbone network.
To avoid such a problem, an OSPF sham link can be established between PEs so that the routes
that pass through the MPLS VPN backbone network also become OSPF intra-area routes and
are preferred.
l A sham link is regarded as a link between two VPN instances. Each VPN instance contains
the address of an end-point of a sham link. The address is a loopback address with the 32-
bit mask in the VPN address space on the PE.
l After a sham link is established between two PEs, the two PEs become neighbors on the
sham link and exchange routing information.
l A sham link functions as a P2P link in an area, and users can select a route from the sham
link and the backdoor link by adjusting the metric.
Multi-VPN-Instance CE
OSPF multi-instance generally runs on PEs. The routers 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 feature the following:

l MCEs do not need to support OSPF-BGP association.

l MCEs establish different OSPF instances for different services. That is, different virtual
CEs transmit different services. This solves the security problem of the LAN at a low cost.
l MCEs implement different OSPF multi-instances on a CE. The key to implementing MCEs
is to disable loop detection and calculate routes directly. That is, MCEs also use the received
LSAs with the ND-bit for route calculation.
6.3.5 OSPF NSSA

Definition
OSPF Not-So-Stubby Areas (NSSAs) are a new type of OSPF areas.
Derived from stub areas, NSSAs resemble stub areas in many ways. The difference between
NSSAs and stub areas is that NSSAs can import and flood AS external routes to the entire OSPF
AS, without learning external routes in other areas of the OSPF network.
Purpose
As defined in OSPF, stub areas cannot import external routes. This prevents a large number of
external routes from consuming the bandwidth and storage resources of the Router s in stub
areas. Stub areas thus cannot meet the requirement of the scenario where external routes need
to be imported and resource consumption caused by external routes also needs to be avoided.
Therefore, NSSAs are introduced.
Figure 6-10 NSSA

RIP RIP
Type5 Type5 NSSA Area
Type5 Type5 Type7

ASBR Area2 Area0 Area1 ASBR
ABR ABR
Type7 LSA
l Type7 LSAs are a new type of LSAs that are introduced to support NSSAs and describe
the imported external routes.
l Type7 LSAs are generated by the ASBRs of NSSAs and flooded only in the NSSAs where
ASBRs reside.
l When receiving Type7 LSAs, the ABRs of NSSAs selectively translate the Type7 LSAs
to Type5 LSAs so that external routes can be advertised in other areas of the OSPF network.
l Default routes can also be expressed through Type7 LSAs so that traffic can be forwarded
to other ASs.
N-bit
Router s in an area must be configured with the same area type. In OSPF, the N-bit is carried in
a Hello packet to identify that a Router supports NSSAs. OSPF neighbor relationships cannot
be established between the Router s with different area types.

Disobeying RFC 1587, some manufacturers also set the N-bit in OSPF Database Description
(DD) packets. Huawei devices can be configured to be compatible with the devices of these
manufacturers for interworking.
Translating Type7 LSAs to Type5 LSAs

To advertise the external routes imported by NSSAs in other areas, you need to translate Type7
LSAs to Type5 LSAs so that the external routes can be advertised in the entire OSPF network.
l The Propagate bit (P-bit) informs a Router whether Type7 LSAs need to be translated.
l The ABR with the largest Router ID in an NSSA translates Type7 LSAs to Type5 LSAs.
l Only the Type7 LSAs with the set P-bit and forwarding address not being 0 are translated
to Type5 LSAs. A forwarding address indicates that the packet to a specific destination
address is to be forwarded to the address specified by the forwarding address.
l The default Type7 LSAs meeting the preceding conditions can also be translated.
l The Type7 LSAs generated by ABRs are not set with the P-bit.
Preventing Loops Caused by Default Routes

There may be multiple ABRs in an NSSA. To prevent routing loops, ABRs do not calculate the
default routes advertised by the peer.
6.3.6 OSPF Local MT

Definition and Purpose
When multicast and an MPLS TE tunnel are deployed in a network, multicast may be affected
by the TE tunnel, which causes multicast services to become unavailable.
To solve this problem, you can enable local multicast-topology (MT) for multicast packet
forwarding.
Local MT
After IGP Shortcut is configured on a TE tunnel, the outbound interface of the route calculated
by an IGP may not be the actual physical interface but a TE tunnel interface.
According to the unicast route to the multicast source address, a router sends a Join message
through a TE tunnel interface. In this situation, routers spanned by the TE tunnel cannot detect
the Join message, so they do not create any multicast forwarding entry.
As shown in Figure 6-11, Router B spanned by the TE tunnel does not create any multicast
forwarding entry.

Figure 6-11 OSPF Local MT
Client Server
Join Packets
Multicast Packets
RouterB
GE1/1/0 GE2/1/0 GE2/2/0 GE3/1/0
RouterA RouterC
Tunnel1/0/0
A TE tunnel is unidirectional, so multicast data packets sent by the multicast source are sent to
the routers spanned by the tunnel through physical interfaces. These routers discard the multicast
data packets, because they do not have any multicast forwarding entry. As a result, services
become unavailable.
After local MT is enabled, if the outbound interface of the calculated route is a TE tunnel interface
of IGP Shortcut type, the route management (RM) module creates a separate Multicast IGP
(MIGP) routing table for the multicast protocol, calculates the actual physical outbound interface
for the route, and then adds the route to the MIGP routing table. Multicast then uses routes in
the MIGP routing table to forward packets.
In Figure 6-11, the packets requesting to join a multicast group is sent from Router A to Router
B through GE 1/1/0. Router B then can create the multicast forwarding table correctly.
6.3.7 BFD for OSPF

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 the same 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 fast detects a link
fault and then notifies OSPF of the fault. This speeds up OSPF's response to the change of the
network topology.
Purpose
The link fault or the topology change may cause Routers to recalculate routes. Therefore, the
convergence of routing protocols must be sped up 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 routing protocols,
once a link fault occurs, BFD can speed up the convergence of routing protocols.

Table 6-13 BFD for OSPF

Associated Link Fault Detection Mechanism Convergence
with BFD or Speed
Not
Not associated An OSPF Dead timer expires. By default, the At the second level
with BFD timeout period of the timer is 40s.
Associated with A BFD session goes Down. At the millisecond

BFD level
Principle
Figure 6-12 BFD for OSPF

RouterA RouterB
GE2/0/0
cost=1
GE1/0/0 co
0
st
=1
=1
st
co
RouterC
The principle of BFD for OSPF is shown in Figure 6-12.

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 Router A connected to Router B is GE 2/0/0. If the link fails,
BFD detects the fault and then notifies Router A of the fault.
4. Router A processes the event that a neighbor relationship becomes Down and re-calculates
routes. After calculation, the outbound interface is GE 1/0/0 passes through Router C and
then reaches Router B.
6.3.8 OSPF GTSM

Definition
The Generalized TTL Security Mechanism (GTSM) protects services above the IP layer against
attacks by checking whether the Time-to-Live (TTL) value in the IP header is within a specified
range.
Purpose
On the network, an attacker may simulate valid OSPF packets and then keeps sending them to
a router. After receiving these packets, the router finds itself the destination of the packets. The

forwarding plane of the router then directly sends the packets to the control plane for processing,
without checking the validity of the packets. As a result, the router busies itself with processing
these "valid" packets, and the CPU usage is high.
In applications, GTSM is mainly used to protect the TCP/IP-based control plane including
routing protocols from attacks of CPU-utilization type such as CPU overload.
Principle
Devices enabled with GTSM check the TTL values in all the received packets by using the
configured policies. The packets that fail to pass the policies are discarded or sent to the control
plane. This protects devices against attacks. The GTSM policy involves the following items:
l Source address of the IP packet sent to the local router
l VPN instance to which the packet belongs
l Protocol number of the IP packet (89 for OSPF, and 6 for BGP)
l Source interface number and destination interface number of protocols above TCP/UDP
l Valid TTL range
The method of implementing GTSM is as follows:
l For the directly connected OSPF neighbors, the TTL value of the protocol packets to be
sent is set to 255.
l For multi-hop neighbors, a reasonable TTL range is defined.
The application scope of GTSM is as follows:
l GTSM is valid for unicast packets and invalid for multicast packets. This is because
multicast packets have a fixed TTL value being 255 and thus do not need the protection of
GTSM.
l GTSM does not support tunnel-based neighbors.
l OSPF GTSM is mainly applied to Non-Broadcast Multi-Access (NBMA) networks, virtual
links, and sham links.
6.3.9 OSPF Smart-discover

Definition
Generally, routers periodically send Hello packets through OSPF interfaces. That is, a router
sends a Hello packet at the Hello interval by using a Hello timer. Sending Hello packets at a
fixed interval slows down the establishment of OSPF neighbor relationships.
Enabling Smart-discover can speed up the establishment of OSPF neighbor relationships in
specific scenarios.

Table 6-14 OSPF Smart-discover
Smart-discover Is Configured Processing

or Not
Smart-discover Is Not Configured l Hello packets are sent only when the Hello timer
expires.
l A Hello packet is sent at the Hello interval.
l Neighbors keep waiting to receive Hello packets
within the timeout period.
Smart-discover Is Configured l Hello packets are sent directly regardless of whether

the Hello timer expires.
l Neighbors can receive packets rapidly and perform
status transition fast.
Principle
In the following scenarios, the interface enabled with Smart-discover can send Hello packets to
neighbors actively, without having to wait for the Hello timer to expire:
l The neighbor status becomes 2-way for the first time.

l The neighbor status changes from 2-way or a higher state to Init.
6.3.10 OSPF-BGP Association
Definition
When a new router is deployed in the network or a router 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 association between OSPF and BGP.
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 6-13, Router A, Router B, Router C, and Router D run OSPF and establish
IBGP connections. Router C is the backup device of Router B. When the network is stable, BGP
and OSPF routes converge completely on the devices.
Normally, traffic from Router A to 10.3.1.0/30 passes through Router B. When Router B is
faulty, traffic is switched to Router C. After Router B recovers, traffic is switched back to Router
B; however, packet loss occurs.
When traffic is switched back to Router B, IGP route convergence is faster than BGP route
convergence. Consequently, OSPF routes converge first, whereas BGP route convergence is not
complete. As a result, Router B does not know how to reach 10.3.1.0/30.
Therefore, when packets from Router A to 10.3.1.0/30 are sent to Router B, they are discarded
by Router B because Router B has no route to 10.3.1.0/30.

Figure 6-13 OSPF-BGP association
RouterC AS 20
POS2/0/0 POS1/0/0 RouterF
10.1.2.2/30 10.1.4.1/30
POS1/0/0
POS1/0/0 10.3.1.2/30
POS2/0/0
10.1.2.1/30 10.1.4.2/30 POS2/0/0
10.3.1.1/30
RouterA RouterD EBGP
RouterE
POS3/0/0
POS1/0/0 10.2.1.1/30 POS1/0/0
10.1.1.1/30 POS2/0/0
10.2.1.2/30
10.1.3.2/30
POS1/0/0 POS2/0/0
10.1.1.2/30 10.1.3.1/30
RouterB AS 10
Principle
The router enabled with OSPF-BGP association remains to be a stub router within the set
association period. That is, the link metric in the LSA advertised by the router is the maximum
value of 65535. In this manner, the router instructs other OSPF routers not to use it as a transit
router for data forwarding.
In Figure 6-13, OSPF-BGP association is enabled on Router B. In this situation, before BGP
route convergence is complete, Router A continues to forward traffic to the backup link Router
C, without forwarding traffic to Router B, until BGP route convergence on Router B is complete.
6.3.11 OSPF-LDP Association
Definition
In the networking where primary and backup links are used, when the faulty primary link
recovers, traffic is switched from the backup link back to the primary link.
IGP route convergence is complete before the establishment of an LDP session. Consequently,
the old LSP has been deleted, whereas the new LSP has not been established. As a result, LSP
traffic is interrupted.
Purpose
As shown in Figure 6-14, the primary link adopts the path PE1P1P2P3PE2, and the
backup link adopts the path PE1P1P4P3PE2.
When the primary link is faulty, traffic is switched to the backup link. After the primary link
recovers, traffic is switched back from the backup link to the primary link. During this process,
traffic is interrupted for a long time.

Figure 6-14 OSPF-LDP association
P2
PE1 P1 P3 PE2
P4
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 6-15 OSPF-LDP association
Enabling Status of OSPF-LDP Traffic Interruption Time

Association
OSPF-LDP association is not enabled. At the second level
OSPF-LDP association is enabled. At the millisecond level
Principle
Principle of synchronization of LDP and IGP 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 and then
is deleted after the LSP is established.
Synchronization of LDP and IGP involves three timers:
l Hold-down
l Hold-max-cost
l Delay
After the primary link recovers, a router does as follows:
1. Starts the hold-down timer. The IGP interface does not establish IGP neighbors but waits
for the 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 wait for the establishment of an LSP after an LDP session is re-
established for the faulty link.

4. After the Delay timer expires, LDP notifies IGP that synchronization is complete regardless
of the status of IGP.
6.3.12 OSPF Database Overflow

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 bear so much routing
information because of limited system resources. This situation is called OSPF database
overflow.
Purpose
l Configuring stub areas or NSSAs can solve the problem that the continuous increase in
routing information causes the exhaustion of system resources of routers. Nevertheless,
configuring stub areas or NSSAs cannot solve the problem that the unexpected increase in
dynamic routes causes the database overflow.
l Setting the maximum number of external LSAs in the LSDB can dynamically limit the
LSDB capacity, thus avoiding the problem caused by the database overflow.
Principle
Setting the maximum number of non-default external routes on a router can avoid database
overflow.
All routers on the OSPF network must be set with the same upper limit. In this manner, if the
number of external routes on a router reaches the upper limit, the router enters the Overflow
state and starts an overflow timer so that the timer automatically exits from the overflow state
after the timer expires.
Table 6-16 OSPF database overflow

Phase of the Overflow OSPF Processing
State
Entering the overflow state A router deletes all the non-default routes generated by itself.
Staying in the overflow state l The router does not generate non-default routes.
l The router discards the newly received non-default
routes, and does not reply with an LSAck packet.
l When the overflow timer expires, the router checks
whether external routes still exceed the upper limit.
If so, the router restarts the timer.
If not, the router exits from the overflow state.

Phase of the Overflow OSPF Processing

State
Exiting from the overflow l The router deletes the overflow timer.
state l The router generates non-default routes.
l The router learns the newly received non-default routes,
and replies with an LSAck packet.
l The router prepares to enter the overflow state for the next
time.
6.3.13 OSPF Fast Convergence

OSPF fast convergence is an extended feature of OSPF implemented to speed up the convergence
of routes. It includes the following:
l I-SPF
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.
l PRC
Partial Route Calculation (PRC) calculates only the changed routes when the routes on the
network change.
l Intelligent timer
An Open Shortest Path First (OSPF) intelligent timer can dynamically adjust its value
according to the user's configuration and the interval at which an event is triggered such as
the route calculation interval, which ensures rapid and stable operation of a network.
The OSPF intelligent timer applies the exponential backoff technology so that the value of
the timer can reach the millisecond level.
I-SPF (Incremental SPF)

In ISO 10589, the Dijkstra algorithm is adopted to calculate routes. When a node changes on
the network, this algorithm is used to recalculate all routes. The calculation lasts a long time and
consumes too many CPU resources, thus affecting 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 SPT generated at last is the same as that generated by the previous
algorithm. This decreases the CPU usage and speeds up the network convergence.
PRC (Partial Route Calculation)

Similar to I-SPF, PRC calculates only the changed routes. PRC, however, does not calculate the
shortest path. It updates the routes based on the SPT calculated by I-SPF.
In route calculation, a leaf represents a route, and a node represents a router. The SPT change
and leaf change cause the change of routing information, but the SPT change is irrelevant to the
leaf change. PRC processes routing information based on SPT or leaf information.
l If the SPT changes, PRC processes the routing information of all leaves on a changed node.
l If the SPT does not change, PRC does not process the routing information on any node.

l If the leaf changes, RPC processes the routing information on the leaf only.
l If the leaf does not change, PRC does not process the routing information on any leaf.
For example, if OSPF is enabled on an interface of a node, the SPT calculated by I-SPF remains
unchanged. In this case, PRC updates only the routes of this interface, thus 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.
NOTE
In the implementation of device, only I-SPF and PRC are used to calculate OSPF routes.
OSPF Intelligent Timer

On an unstable network, routes are frequently calculated, which consumes a great number of
CPU resources. In addition, LSPs that describe the unstable topology are generated and
transmitted on the unstable network. Frequently processing such LSAs affects the rapid and
stable operation of the entire network.
The OSPF intelligent timer controls route calculation, LSA generation, and LSA receiving to
speed up route convergence on the entire network.
The OSPF intelligent timer speeds up route convergence in the following modes:
l On a network where routes are repeatedly calculated, the OSPF intelligent timer
dynamically adjusts the route calculation according to the user's configuration and the
exponential backoff technology. In this manner, the number of route calculation times and
the CPU resource consumption are decreased. Routes are calculated after the network
topology becomes table.
l On an unstable network, if a router generates or receives LSAs due to frequent topology
changes, the OSPF intelligent timer can dynamically adjust its value. No LSA is generated
or handled within an interval, which prevents invalid LSAs from being generated and
advertised on the entire network.
By default, the OSPF intelligent timer is started and uses the default value.
6.3.14 OSPF MIB

Definition
The Management Information Base (MIB) is a database that stores information. The network
administrator can call MIB objects through the agent to control, configure, or monitor network
devices. For details, refer to Chapter "SNMP".
As defined in RFC 4750, the OSPF MIB is used to set, modify, and view the OSPF protocol
running status on network devices.
Purpose
The network administrator can use the MIB to query information about the operation of managed
devices and configure network devices through the set operation. This helps the administrator
to monitor and manage networks more rapidly and effectively.
The network administrator can perform the get and get-next operations (rather than the set
operation) on all OSPF MIB objects defined in RFC 4750.

To enhance and supplement MIBs defined in RFC 4750, private OSPF MIBs are supported and
the set operation on the private MIBs can be performed.
Principles
After an OSPF process is bound to the MIB, the network administrator can perform the get and
get-next operations through the OSPF MIB to obtain information about OSPF link state
databases (LSDBs), areas, interfaces, and neighbors of the bound OSPF process.
OSPF supports the set operation on three private MIB tables, that is, the process table, area table,
and network table.
l By performing the set operation on the process table of a private MIB, the administrator
can create or delete an OSPF process, and configure or delete parameters of the OSPF
process.
l By performing the set operation on the area table of a private MIB, the administrator can
create or delete an OSPF area, and set or delete parameters of the OSPF area.
l By performing the set operation on the network table of a private MIB, the administrator
can create or delete a specific network segment for an OSPF area.
By performing the set operation on the three tables of the private MIB, the administrator can
configure the basic OSPF functions and set up a basic OSPF topology to conveniently manage
and configure the network.
6.3.15 OSPF Mesh-Group

Definition
In the scenario where there are multiple concurrent links, OSPF mesh-group can be deployed to
classify links into a mesh group. In this manner, OSPF floods LSAs to only a link selected from
the mesh group. This prevents unnecessary burden on the system caused by repetitive flooding.
By default, mesh-group is disabled.
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 case, if there are 2000 concurrent links, OSPF floods each LSA for 2000 times. Only one
flooding, however, is valid. The flooding for the other 1999 times is repetitive.
To prevent burden on the system caused by repetitive flooding, you can enable mesh-group to
classify concurrent links into a mesh group and then select a primary link for flooding.
Principles
When multiple concurrent links exist between a router and its neighbor, you can enable OSPF
mesh-group to reduce the burden on the links.
As shown in Figure 6-15, Router A and Router B, which are connected through three links,
establish an OSPF neighbor relationship. After receiving a new LSA from interface 4, Router
A floods the LSA to Router B through interfaces 1, 2, and 3.
This 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 6-15 Flooding of LSAs when OSPF mesh-group is disabled
1 LSA
LSA 4 2 LSA
RouterA 3 LSA RouterB
When multiple concurrent links exist between the devices enabled with OSPF mesh-group and
neighbors, the device selects one primary link to flood the received LSAs, as shown in Figure
6-16.
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 Router A from link 1, Router B no longer floods the LSA
to Router A through interfaces 2 and 3.
Figure 6-16 Flooding of LSAs when OSPF mesh-group is enabled
1 LSA
LSA 4 2 LSA
3 LSA
RouterA RouterB
As defined by mesh-group, the Router ID of a neighbor uniquely identifies a mesh group. The
interfaces connected to the same neighbor and with the status greater than Exchange, belong to
the same mesh group.
As shown in Figure 6-17, a mesh group of Router A resides in Area 0, which contains the links
of interface 1 and interface 2. There is more than one neighbor of interface 3 that resides on the
broadcast link. Therefore, interface 3 cannot join the mesh group.

Figure 6-17 Interfaces failing to be added to a mesh group
4 2
RouterB
RouterA
3
Area0
NOTE
After a router is enabled with mesh-group, if the Router IDs of the router and its directly connected neighbor
are the same, the LSDBs cannot be synchronized and routes cannot be calculated correctly. In this case,
you need to reconfigure the Router ID of the neighbor. Note that it is incorrect to configure the Router ID
of the neighbor the same as that of the router.
6.3.16 Priority-based OSPF Convergence

Priority-based OSPF convergence ensures that specific routes converge first in the case of a
great number of routes. Different routes can be set with different convergence priorities. This
allows important routes to converge first and thus improves network reliability.
By using priority-based OSPF convergence, users can assign a high convergence priority to
routes for key services so that those routes can converge fast. This decreases impact on key
services.
6.3.17 OSPF IP FRR
Definition
With IP Fast Reroute (FRR), traffic can be rapidly switched to a backup link to ensure continuous
service forwarding in case of a link fault.
Principle
With IP FRR, a loop-free backup link with an optimal route that only has the origin node in
common with the original route is calculated before a fault occurs. Once a fault occurs, the
backup next hop pre-calculated on the neighbor of the faulty node is used to forward traffic along
the pre-calculated backup link. This allows packets to be transmitted without passing through
the faulty link or faulty node, thus ensuring continuous service forwarding.
IP FRR involves only fault detection and next hop switching; it does not include LSA update,
LSA flooding, SPF calculation, and route delivery to the FIB table. Faults can be rapidly detected
using various mechanisms such as BFD. The key to implementing IP FRR is first to pre-calculate
a loop-free backup link that detours around a faulty link or faulty node and then to deliver the
backup link together with the primary next hop to the FIB table. In case of a fault, traffic is
forwarded over the backup link by replacing the primary next hop with the backup next hop.

6.4 OSPF Applications
6.4.1 OSPF GR
As shown in Figure 6-18, Router A, Router B, Router C, and Router D run OSPF for
interworking, and Router A and Router B are enabled with GR. When Router A restarts, Router
B helps Router A to perform GR, without notifying other neighbors of the restart of Router A.
This ensures non-interrupted network traffic.
Figure 6-18 OSPF GR
s
d oe er RouterC
B ut
u ter y Ro r A
Ro notif oute
t R
Set up neighbor no that tarts
relationship and C res
RouterA RouterB
negotiate GR
Restarter Helper Rou

noti ter B d RouterD
Restart fy R oes
Rou outer no
t er A D th t
rest a
arts t
6.4.2 OSPF GTSM

As shown in Figure 6-19, OSPF runs between devices, and GTSM is enabled on Router C. The
following are the valid TTL ranges of the packets sent from each device to Router C:
l Router A and Router E are the neighbors of Router C, and their valid TTL range of packets
is [255, 255].
l The valid TTL ranges of the packets sent from Router B, Router D, or Router F to Router
C are [254, 255], [253, 255], and [252, 255] respectively.

Figure 6-19 OSPF GTSM
RouterA Area0 RouterB

POS1/0/0 POS1/0/0
192.168.0.1/24 192.168.0.2/24
POS2/0/0 POS2/0/0
192.168.1.1/24 192.168.2.1/24
POS1/0/0 POS1/0/0
192.168.1.2/24 192.168.2.2/24
RouterC RouterD
GE2/0/0 GE2/0/0
172.16.1.1/24 172.17.1.1/24
GE2/0/0 GE2/0/0
172.16.1.2/24 172.17.1.2/24
RouterE RouterF
Area1 PC Area2

Terms
Term Description
PE Provider Edge: It is an edge router on an SP network, and is connected to the

CE. PEs process all VPN services.
CE Customer Edge: It is an edge router on the user network, and is connected to

the PE. CEs cannot detect the connected VPN.
Abbreviations
GR Graceful Restart
LSA Link State Advertisement
TE Traffic Engineering
MPLS Multiprotocol Label Switching
CSPF Constraint Shortest Path First


Feature Description - IP Routing 7 OSPFv3
7 OSPFv3
About This Chapter
7.1 Introduction to OSPFv3

7.2 References
7.3 Principles

7.1 Introduction to OSPFv3

Definition
The Open Shortest Path First (OSPF) protocol, developed by the Internet Engineering Task Force
(IETF), is an interior gateway protocol based on the link status.
At present, OSPF Version 2 is used for IPv4 and OSPF Version 3 is used for IPv6.
l OSPFv3 is short for OSPF Version 3.

l As defined in RFC 2740, OSPFv3 is a routing protocol over IPv6.
l OSPFv3 is an independent routing protocol whose functions are enhanced on the basis of
OSPFv2.
Purpose
The primary purpose of OSPFv3 is to develop a routing protocol independent of any specific
network layer. The internal routing information of OSPFv3 is redesigned to serve this purpose.
The differences between OSPFv3 and OSPFv2 are as follows:
l OSPFv3 does not insert IP-based data in the header of the packet and Link State
Advertisement (LSA).
l OSPFv3 executes some crucial tasks that originally require the data in the IP packet header
by making use of the information independent of any network protocol. For example,
OSPFv3 can identify the LSA that advertises the routing data.
7.2 References
Document Description Rema

rks
RFC 2740 This document describes the modifications to OSPF to

support version 6 of the Internet Protocol (IPv6).
draft-ietf-ospf- This document describes the OSPFv3 graceful restart. The

ospfv3-graceful- OSPFv3 graceful restart is identical to OSPFv2 except for the
restart differences described in this document. These differences
include the format of the grace Link State Advertisements
(LSA) and other considerations.
draft-ietf-ospf- This memo defines a portion of the Management Information

ospfv3-mib-11 Base (MIB) for use with network management protocols in
IPv6-based internets. In particular, it defines objects for
managing the Open Shortest Path First Routing Protocol for
IPv6.

7.3 Principles
7.3.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.
l 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.
l OSPFv3 divides an Autonomous System (AS) into one or more logical areas and advertises
routes through LSAs.
l OSPFv3 achieves unity of routing information by exchanging OSPFv3 packets between
routers within an OSPFv3 area.
l OSPFv3 packets are encapsulated into IPv6 packets, which can be transmitted in unicast
or multicast mode.
Formats of OSPFv3 Packets

Packet Type Description
Hello message Hello messages are sent regularly to discover and

maintain OSPFv3 neighbor relationships.
Database Description (DD) A DD packet contains the summary of the local LSDB.
packet 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 The LSAck packet is used to acknowledge the received
(LSAck) packet LSA 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.

LSA Type Description
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 Generated on the area border router (ABR), an inter-area

(Type3) 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 Generated on the ABR, an inter-area router LSA describes

(Type4) the route to the autonomous system boundary router (ASBR)
and is advertised to all related areas except the area that the
ASBR belongs to.
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.
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 Each router or DR generates one or more intra-area prefix

(Type9) LSAs and transmits it in the local area.
l An LSA generated on a router describes the IPv6 address
prefix associated with the router LSA.
l An LSA generated on a DR describes the IPv6 address
prefix associated with the network LSA.
Router Type
Figure 7-1 Router type

IS-IS ASBR
Area1 Area4
Internal Router Backbone Router
Area0
Area2 ABR Area3

Table 7-1 Router types and descriptions

Router Type Description
Internal router All interfaces on an internal router belong to the same

OSPFv3 area.
Area border router (ABR) An ABR can belong to two or more areas, but one of the areas
must be a backbone area.
An ABR is used to connect the backbone area and the non-
backbone areas. It can be physically or logically connected
to the backbone area.
Backbone router At least one interface on a backbone router belongs to the

backbone area.
All ABRs and internal routers in Area 0, therefore, are
backbone routers.
AS boundary router (ASBR) A router that exchanges routing information with other ASs
is called an ASBR.
An ASBR may not locate on the boundary of an AS. It can
be an internal router or an ABR. If an OSPFv3 router imports
the external routing information, the router is an 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 7-2 lists route types in a descending order of priority.
Table 7-2 Types of OSPFv3 routes

Route Type Description
Intra Area Intra-area routes
Inter Area Inter-area routes
Type1 external routes Because of the high reliability of Type 1 external routes, the
calculated cost of external routes is equal to that of AS
internal routes, and can be compared with the cost of OSPFv3
routes.
That is, the cost of a Type1 external route equals the cost of
the route from the router to the corresponding ASBR plus the
cost of the route from the ASBR to the destination address.

Route Type Description
Type2 external routes Because of the low reliability of Type2 external routes, the
cost of the route from the ASBR to a destination outside the
AS is considered far greater than the cost of any internal path
to an ASBR.
Therefore, OSPFv3 only takes the cost of the route from the
ASBR to a destination outside the AS into account when
calculating route costs. That is, the cost of a Type2 external
route equals the cost of the route from the ASBR to the
destination of the route.
Area Type
Table 7-3 Types of OSPFv3 areas

Area Type Description
Totally stub area A totally stub area allows the Type3 default routes advertised by the
ABR, and disallows the routes outside the AS and inter-area routes.
Stub area A stub area allows inter-area routes, which is different from a totally
stub area.
Network Types Supported by OSPFv3

OSPFv3 classifies networks into the following types according to link layer protocols.
Table 7-4 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:
l 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).
l 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,
transmitted in unicast mode.

Network Type Description
Point-to-Multipoint Regardless of the link layer protocol, OSPFv3 does not default the
(P2MP) network type to P2MP. A P2MP network must be forcibly changed
from other network types. The common practice is to change a
non-fully connected NBMA to a P2MP network.
In this type of networks, the following situations occur:
l Hello messages are transmitted in multicast mode with the
multicast address as FF02::5.
l Other protocol packets, including DD packets, LSR packets,
LSU packets, and LSAck packets, are transmitted in unicast
mode.
Point-to-point (P2P) If the link layer protocol is PPP, HDLC, or LAPB, OSPFv3
defaults the network type to P2P.
In this type of network, the protocol packets, including Hello
messages, DD packets, LSR packets, LSU packets, and LSAck
packets, are transmitted to the multicast address FF02::5.
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:
l The backbone area cannot be configured as a stub area.

l If an area needs to be configured as a stub area, all the routers in this area must be configured
with the stub command.
l An ASBR cannot exist in a stub area. That is, external routes are not flooded in the stub
area.
l A virtual link cannot pass through the stub area.
OSPFv3 Route Aggregation

The routes with the same prefix can be aggregated into a route and then only the aggregated
route is advertised to other areas. This is called route aggregation.
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:

1. When an ABR transmits routing information to other areas, it generates Type3 LSAs based
on IPv6 address prefixes.
2. If a continuum of IPv6 address prefixes exist in an area, these prefixes are aggregated to
one IPv6 address prefix.
3. An ABR sends only one aggregated LSA. Any LSA that belongs to the aggregated network
segment specified by the command is not transmitted separately.
OSPFv3 Virtual Link

A virtual link refers to a logical channel established between two ABRs through a non-backbone
area.
l A virtual link must be set up on both ends of the link; otherwise, it does not take effect.
l 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 7-2 OSPFv3 virtual link
Area0 Area2
Virtual Link
ABR Area1 ABR
Transit Area
As shown in Figure 7-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.
OSPFv3 Multi-process
OSPFv3 supports multi-process. More than one OSPFv3 process can run on the same router
because processes are independent of each other. Route interaction between different OSPFv3
processes is similar to the route interaction between different routing protocols.
An interface of a router belongs to only a certain OSPFv3 process.
7.3.2 OSPFv3 GR
Graceful restart (GR) is a technology used to ensure normal traffic forwarding when a routing
protocol restarts and guarantee that key services are not affected in the process.
GR is one of the high availability (HA) technologies, which comprise a series of comprehensive
technologies such as fault-tolerant redundancy, link protection, faulty node recovery, and traffic

engineering. As a redundancy technology, GR is widely used to ensure uninterrupted forwarding

of key data in active/standby switchover and system upgrade.
l If GR is not enabled, the active/standby switchover occurring owing to various causes leads
to transient interruption of data forwarding, and as a result, route flapping occurs on the
whole network. Such route flapping and service interruption are unacceptable on a large-
scale network, especially on a carrier network.
In GR mode, the forwarding plane continues to direct data forwarding once a restart occurs, and
the actions on the control plane, such as reestablishment of neighbor relationships and route
calculation, do not affect the forwarding plane. In this manner, service interruption caused by
route flapping is prevented so that the network reliability is improved.
Basic Concepts
l Grace LSA
OSPFv3 supports GR by flooding grace LSAs on the link.
Grace LSAs are used to inform the neighbor of the GR time, cause, and interface instance
ID when GR starts and ends.
l Router function
A router can function as a GR restarter.
A router can function as a GR helper.
l GR implementation
Planned-GR: This refers to the smooth restart of OSPFv3 through the reset ospfv3
graceful-restart command. In this mode, a grace LSA is sent to the neighbor before
the restart.
Unplanned-GR: This refers to the active/standby switchover triggered by commands or
the restart or active/standby switchover because of router faults.
Unlike planned-GR, no grace LSA is sent before the active/standby switchover in
unplanned GR mode. Instead, the switchover is directly performed. When the standby
board becomes Up, a grace LSA is sent and the GR process starts. The following
procedure is the same as that of planned GR.
GR Process
Figure 7-3 OSPFv3 planned-GR process (reset ospfv3 graceful-restart)

RouterA RouterB
Restarter Helper
Restart the OSPFv3 Grace-LSA

process in GR mode Enter the Helper
and enter the GR state LSAck state
Send Hello packets, negotiate with

neighbors by exchanging DD packets,
and synchronize LSDBs
Synchronize LSDBs with
Full the Restarter
Exit from the GR state, Flush Grace-LSA
recalculate routes, and Exit from the Helper state
generate LSAs and generate Router-LSAs

Figure 7-4 OSPFv3 unplanned-GR process (active/standby switchover)

RouterA RouterB
Restarter Helper
Master/slave Grace-LSA
Enter the Helper state
switchover is complete
LSAck
Responds to LSAs
with LSAcks
Send Hello packets, negotiate with
neighbors by exchanging DD packets,
and synchronize LSDBs
Synchronize LSDBs
Full
with the Restarter
Exit from the GR state,
recalculate routes, and Flush Grace-LSA
Exit from the Helper
generate LSAs state and generate
Router-LSAs
l On the GR restarter:
1. In planned-GR mode, when OSPFv3 is restarted through commands, the GR restarter sends
a grace LSA to all neighbors to inform them of the start of a GR process and the period and
cause of this process.
In unplanned GR mode, when a restart occurs after active/standby switchover or owing to
other causes other than commands, a grace LSA is sent to each neighbor immediately after
the standby board is Up to inform the neighbors of the start of a GR process and the period
and cause of the process.
2. The GR restarter performs negotiation with neighbors again to set up new neighbor
relationships.
3. When all the neighbor relationships between the GR restarter and the original neighbors
enter the Full state:
l The GR restarter exits from the GR process and OSPFv3 recalculates routes.
l The GR restarter updates the routing table on the main control board and the FIBs on
interface boards and deletes invalid routing entries.
l The GR restarter sends a grace LSA whose aging time is 3600 seconds to instruct the
GR helper to exit from the GR process.
Now, the GR process is complete.
4. If errors occur, the GR timer expires, or the neighbor relationship fails to enter the Full
state during a GR process, the GR restarter exits from the process and OSPFv3 is restarted
in non-GR mode. In this case, packets are lost.
l On the GR helper:
1. If a router is configured to support the GR process on its neighbor, the router enters the
helper mode after receiving a grace LSA.
2. The GR helper maintains its neighbor relationship with the GR restarter, and the status of
the neighbor relationship does not change.

3. If the GR helper continues to receive grace LSAs whose GR period is different from that
on the GR helper, the GR helper updates its GR period.
4. Being informed of the successful GR process through a grace LSA whose aging time is
3600 seconds from the GR restarter, the GR helper exits from the GR process.
5. If errors occur during a GR process, the GR helper exits from the helper state and deletes
invalid routes after route calculation.
Comparison between the GR Mode and the Non-GR Mode
Table 7-5 Comparison between the GR mode and the non-GR mode
Active/Standby Switchover in Non- Active/Standby Switchover in GR Mode
GR Mode
l OSPFv3 neighbor relationships are l OSPFv3 neighbor relationships are

reestablished. reestablished.
l Routes are recalculated. l Routes are recalculated.
l The forwarding table changes. l The forwarding table remains the same.
l Route changes are sensed on the l Except the neighbor of the device where the
network and route flapping occurs over active/standby switchover occurs, other
a short period of time. routers do not sense the route changes.
l Packets are lost during forwarding, and l No packets are lost during forwarding, and
services are interrupted. services are not affected.
7.3.3 BFD for OSPFv3

Definition
Bidirectional Forwarding Detection (BFD) is a mechanism used to detect faults of
communications 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.
BFD for OSPFv3 associates BFD with OSPFv3. BFD fast detects a link fault and then notifies
OSPFv3 of the fault. This speeds up OSPFv3's response to the change of the network topology.
Purpose
A link fault or the topology change causes routers to recalculate routes. Therefore, the
convergence of routing protocols must be as quick as possible to improve network performance.
Link faults are inevitable. Therefore, fast detecting faults and notifying routing protocols of the
faults is a feasible solution to immediately rectify link faults. After BFD is associated with
routing protocols, BFD can speed up the convergence of routing protocols if a link fault occurs.

Principles
Figure 7-5 BFD for OSPFv3

RouterA RouterB
GE2/0/0
cost=1
GE1/0/0 co
0
st
=1
=1
st
RouterC co
Figure 7-5 shows the principle of BFD for OSPFv3.
1. OSPFv3 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 Router A connected to Router B is GE2/0/0. If the link fails,
BFD detects the fault and then notifies Router A of the fault.
4. Router A processes the event that a neighbor relationship becomes Down and re-calculates
routes. After calculation, the outbound interface is GE1/0/0 passes through Router C and
then reaches Router B.
7.3.4 OSPFv3 IPSec Authentication

Internet Protocol Security (IPSec) is a framework of open standards for ensuring secure private
communications over the Internet by authenticating and encrypting each IP packet of a
communication session. IPSec is a trend to guarantee network security. It is a security scheme
operating in end-to-end mode to avoid attacks on private networks and the Internet.
OSPFv3 IPSec uses a complete set of IPSec mechanisms to authenticate sent and received
OSPFv3 packets, thus protecting devices against pseudo OSPFv3 packets.
IPSec is not a single protocol. It is a protocol suite providing a complete set of mechanisms for
securing IP communications. The security mechanisms include Authentication Header (AH),
Encapsulating Security Payload (ESP), Internet Key Exchange (IKE), and algorithms used in
data authentication and encryption. In IPSec, the two protected ends must use the same security
protocol, algorithm, and key, thus implementing access control, data source authentication, and
data encryption.
l AH provides authentication and anti-relay to ensure the integrity of data, but does not ensure
the confidentiality of data. In the scenario where the confidentiality requirement is low,
AH can be used to ensure the integrity and security of data.
l ESP provides the encryption function to work together with AH.
l IKE manages keys.
In practice, both AH and ESP can be used to obtain required security services.

7.3.5 Association between OSPFv3 and BGP

When a new router is deployed in the network or a router is restarted, the network traffic may
be lost during BGP convergence. This is because IGP convergence is quicker than BGP
convergence. This problem can be solved through the association between OSPFv3 and BGP.
If a router on a BGP network recovers from a fault, BGP convergence is performed again and
certain packets may be lost during the convergence.
As shown in Figure 7-6, traffic from Router A to Router D traverses a BGP network.
Figure 7-6 Traffic traversing a BGP network

RouterB
Router Nexthop
BGP 1::1 RouterD
OSPFv3 RouterD RouterC
RouterD
BGP Routes
RouterA 1::1/128
OSPFv3
RouterC
If a fault occurs on Router C, traffic is redirected to Router B after rerouting. Packets are lost
when Router C is restored to the normal status.
Because OSPFv3 convergence is quicker than BGP convergence, OSPFv3 convergence is
complete when Router C recovers. The next hop of the route from Router A to Router D isRouter
C, which, however, does not know the route to Router D since BGP convergence on Router C
is not complete.
Thus, when the packets destined for Router D are transmitted from Router A to Router C, they
are discarded by Router C because Router C has no route to Router D, as shown in Figure
7-7.
Figure 7-7 Packet loss during the restart of the device not enabled with association between
OSPFv3 and BGP
RouterB
Router Nexthop
BGP 1::1 RouterD
OSPFv3 RouterD RouterC
BGP Routes
RouterA 1::1/128
OSPFv3 RouterD
RouterC

Process of Association between OSPFv3 and BGP

When a router enabled with association between OSPFv3 and BGP restarts, the router advertises
a message in the local OSPFv3 area to instruct other routers not to use it as a transit router.
At the same time, the router sets the largest weight value of 65535 in its LSAs to ensure that it
is not used by other routers as the transit router. The BGP route, however, can still reach the
router.
7.3.6 Comparison between OSPFv3 and OSPFv2

OSPFv3 and OSPFv2 are the same in the following aspects:
l Network type and interface type

l Interface state machine and neighbor state machine
l LSDB
l Flooding mechanism
l Five types of packets, including Hello, DD, LSR, LSU, and LSAck packets
l Route calculation
OSPFv3 and OSPFv2 are different in the following aspects:
l 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.
l 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.
l 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.
l 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.
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, Router A and Router B can identify LSAs of a certain type. They are
connected through Router C, which, however, cannot identify this type of LSAs. When
Router A floods an LSA of this type, Router C can still flood the received LSA to Router
B although it does not identify this LSA. Router B then processes the LSA.
If OSPFv2 is run, Router C discards the unidentified LSA so that the LSA cannot reach
Router B.
l 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.
l 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 Vlink 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.
l 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.
l 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.
l 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.


Abbreviation
OSPFv3 OSPF Version 3
GR Graceful Restart
LSA Link State Advertisement

Feature Description - IP Routing 8 BGP
8 BGP
About This Chapter
8.1 Introduction to BGP

8.2 References
8.3 Principles

8.1 Introduction to BGP

Definition
The Border Gateway Protocol (BGP) is a dynamic routing protocol used between autonomous
systems (ASs).
BGP-1 (defined in RFC 1105), BGP-2 (defined in RFC 1163), and BGP-3 (defined in RFC 1267)
are three earlier-released versions of BGP. BGP exchanges the reachable inter-AS routes,
establishes inter-AS paths, avoids routing loops, and applies routing policies between ASs.
The current BGP version is BGP-4 defined by RFC 4271.
As an exterior routing protocol on the Internet, BGP is widely used among Internet Service
Providers (ISPs).
BGP has the following characteristics:
l Different from the Interior Gateway Protocol (IGP) such as Open Shortest Path First
(OSPF) and Routing Information Protocol (RIP), BGP is an Exterior Gateway Protocol
(EGP), which controls the route advertisement and selects the optimal route between ASs
rather than discover and calculate routes.
l BGP uses the Transport Control Protocol (TCP) with the listening port number being 179
as the transport layer protocol. The reliability of BGP is thus enhanced.
BGP selects inter-AS routes, which proposes high requirements on the reliability of the
protocol. TCP with high reliability, therefore, is used to enhance the stability of BGP.
BGP peers must be logically connected and establish TCP connections. The destination
port number is 179 and the local port number is random.
l BGP supports Classless Inter-Domain Routing (CIDR).
l BGP transmits only the updated routes when routes are being updated. This reduces the
bandwidth occupied by BGP for route distribution. Therefore, BGP is applicable to the
Internet where a large number of routes are transmitted.
l BGP is a distance-vector routing protocol.
l BGP is designed to avoid loops.
Inter-AS: BGP routes carry information about the ASs along the path. The routes that
carry the local AS number are discarded, thus avoiding inter-AS loops.
Intra-AS: BGP does not advertise the routes learned in the AS to the BGP peers, thus
avoiding intra-AS loops.
l BGP provides rich routing policies to flexibly select and filter routes.
l BGP provides the mechanism for preventing route flapping, which effectively enhances
the stability of the Internet.
l BGP can be easily extended to adapt to the development of networks.
Purpose
BGP transmits routes between ASs. It, however, is not required in all situations.

Figure 8-1 Application scenario of BGP
Client AS
IBGP
EBGP EBGP
ISP1 ISP2
Internet
BGP is required in the following situations:
l As shown in Figure 8-1, the user needs to be connected to two or more ISPs. The ISPs
need to provide all or part of the Internet routes for the user. The Router , therefore, selects
the optimal route through the AS of an ISP to the destination according to the AS_Path
carried in BGP routes.
l Different organizations need to transmit the AS_Path.
l Users transmit private network routes through Layer 3 VPN. For details, see the HUAWEI
NetEngine80E/40E Feature Description - VPN.
l Users use BGP as a signaling protocol to transmit routing information in Layer 2
applications (such as VPLS in Kompella mode). For details, see the HUAWEI
NetEngine80E/40E Feature Description - VPN.
l Users need to transmit multicast routes to construct the multicast topology. For details, see
the HUAWEI NetEngine80E/40E Feature Description - IP Multicast.
BGP is not required in the following situations:
l The user is connected to only one ISP.

l The ISP does not need to provide Internet routes for users.
l ASs are connected through default routes.
8.2 References
Table 8-1 lists the references of this feature.

Table 8-1 References
RFC 4271 A Border Gateway Protocol 4 (BGP-4) -
RFC 4760 Multiprotocol Extensions for BGP-4 -
RFC 3392 Capabilities Advertisement with BGP-4 -
RFC 2918 Route Refresh Capability for BGP-4 -
RFC 2439 BGP Route Flap Damping -
RFC 1997 BGP Communities Attribute -
RFC 4456 BGP Route Reflection -
RFC 3065 Autonomous System Confederations for -

BGP
RFC 3232 Assigned Numbers: RFC 1700 is -

Replaced by an On-line Database
RFC 827 Exterior Gateway Protocol (EGP) -
RFC 3682 The Generalized TTL Security -

Mechanism (GTSM)
RFC 4724 Graceful Restart Mechanism for BGP -
draft-rijsman-bfd- BFD Down Subcode for BGP Cease -

down-subcode-00 Notification Message
RFC 4486 Subcodes for BGP Cease Notification -

Message
RFC 5291 Outbound Route Filtering Capability for -

BGP-4
RFC 5292 Address-Prefix-Based Outbound Route -

Filter for BGP-4
8.3 Principles
This chapter describes BGP features, as shown in Table 8-2.
Table 8-2 List of BGP features
Feature Name References
BGP Basic RFC 4271
Route Redistribution
Route Aggregation RFC 2519

Feature Name References
BGP Route Flap Damping RFC 2439
BGP Communities Attribute RFC 1997
BGP Route Reflection RFC 4456
Autonomous System Confederations for BGP RFC 3065
Multiprotocol Extensions for BGP-4 RFC 4760
BGP Extended Communities Attribute RFC 4360
Graceful Restart Mechanism for BGP RFC 4724
Security Requirements for Keys used with the TCP MD5 RFC 3562
Signature Option
IPv6 Provider Edge Routers (6PE) RFC 4798
Bidirectional Forwarding Detection for BGP draft-ietf-bfd-base-06
8.3.1 Basic Principle of BGP

BGP Operating Modes
BGP operates on a router in either of the following modes, as shown in Figure 8-2:
l Internal BGP (IBGP)
l External BGP (EBGP)
BGP is called IBGP when it runs within an AS; it is called EBGP when it runs between ASs.

Figure 8-2 BGP operating modes
Client AS
IBGP
EBGP EBGP
ISP1 ISP2
Internet
Roles in Transmitting BGP Messages

l Speaker: The router that sends BGP messages is called a BGP speaker. The speaker receives
or generates new routing information, and then advertises the routing information to other
BGP speakers. When receiving a new route from another AS, a BGP speaker compares the
route with the current route. If the route takes precedence over the existing route, or the
route is new, the speaker advertises this route to all other BGP speakers except the BGP
speaker that sends this route.
l Peer: The BGP speakers that exchange messages with each other are called peers. Multiple
peers compose a peer group.
BGP Messages
BGP runs by sending messages. There are five types of BGP messages, namely, the Open
message, Update message, Notification message, Keepalive message, and Route-refresh
message.
l Open message: It is the first message that is sent after a TCP connection is set up, and is
used to set up BGP peer relationships. After the peer receives an Open message and the
peer negotiation succeeds, the peer sends a Keepalive message to confirm and maintain the
peer relationship. Then, peers can exchange Update, Notification, Keepalive, and Route-
refresh messages.
l Update message: It is used to exchange routes between BGP peers. The Update message
can be used to advertise multiple reachable routes with the same attributes, or to withdraw
multiple unreachable routes.
An Update message can be used to advertise multiple reachable routes with the same
attributes. These routes can share a group of route attributes. The route attributes

contained in an Update message are applicable to all destination addresses (expressed

by IP prefixes) contained in the Network Layer Reachability Information (NLRI) field
of the Update message.
An Update message can be used to withdraw multiple unreachable routes. Each route
is identified by its destination address, which identifies the routes previously advertised
between BGP speakers.
An Update message can be used only to withdraw routes. In this case, it does not need
to carry the path attributes or NLRI. On the contrary, an Update message can be used
only to advertise the reachable routes, so it does not need to carry information about the
withdrawn routes.
l Notification message: When BGP detects an error, it sends a Notification message to its
peer. The BGP connection is then torn down immediately.
l Keepalive message: BGP periodically sends a Keepalive message to the peer to maintain
the peer relationship.
l Route-refresh message: It is used to notify the peer of the capability to refresh routes.
If all routers of BGP are enabled with the Route-refresh capability, the local BGP router
sends Route-refresh messages to peers when the import routing policy of BGP changes.
After receiving the message, the peers resend their routing information to the local BGP
router. In this manner, the routing table of BGP can be dynamically refreshed and the new
routing policy can be used, without tearing down BGP connections.
BGP Finite State Machine

The BGP Finite State Machine (FSM) has six states, namely, Idle, Connect, Active, OpenSent,
OpenConfirm, and Established.
l In the Idle state, BGP denies all connection requests. This is the initial status of BGP.
l In the Connect state, BGP performs other actions after the TCP connection is set up
l In the Active state, BGP attempts to set up a TCP connection. This is the intermediate status
of BGP.
l In the OpenSent state, BGP waits for the Open message from its peer.
l In the OpenConfirm state, BGP waits for a Notification message or a Keepalive message.
l In the Established state, BGP peers can exchange Update messages, Route-Refresh
messages, Keepalive messages, and Notification messages.
During the establishment of BGP peer relationships, BGP is usually in the Idle, Active, or
Established state.
The BGP peer relationship can be established only when both the BGP peers are in the
Established state. The two peers send Update messages to exchange routes.
BGP Processing
l BGP adopts TCP as its transport layer protocol. Therefore, before the BGP peer relationship
is set up, a TCP connection must be set up between the peers. Then, BGP peers negotiate
related parameters by exchanging Open messages, and finally establish the BGP peer
relationship.
l After the peer relationship is set up, BGP peers exchange BGP routing tables. BGP does
not periodically update the routing table. When BGP routes change, however, BGP updates
the BGP routing table incrementally through Update messages.

l BGP sends Keepalive messages to maintain the BGP connection between peers. When
detecting an error on a network, for example, error packets or packets indicating
unsupported negotiation capability are received, BGP sends a Notification message to
report the error, and the BGP connection is torn down accordingly.
BGP Attributes
The BGP route attribute is a set of parameters that further describe routes. With the BGP route
attribute, BGP can filter and select routes. All BGP route attributes are classified into the
following types:
l Well-known mandatory: It can be identified by all BGP routers. This type of attribute is
mandatory and must be carried in Update messages. Without this attribute, errors occur in
the routing information.
l Well-known discretionary: It can be identified by all BGP routers. The attribute is
discretionary and is not necessarily carried in Update messages.
l Optional transitive: It indicates the transitive attribute between ASs. A BGP router may not
recognize this attribute, but it still receives these attributes and advertises them to other
peers.
l Optional non-transitive: If a BGP router does not recognize this attribute, the corresponding
attributes are ignored and are not advertised to other peers.
The following part describes the common BGP route attributes:
l Origin
The Origin attribute defines the origin of a route. It marks the paths of a BGP route. The
Origin attribute is classified into the following types:
Interior Gateway Protocol (IGP): It is of the highest priority. For the routing information
obtained through an IGP of the AS that originates the route, the Origin attribute is IGP.
For example, for the routes imported to the BGP routing table through the network
command, the Origin attribute is IGP.
Exterior Gateway Protocol (EGP): It is of the second highest priority. The Origin
attribute of the routes obtained through EGP is EGP.
Incomplete: It is of the lowest priority. The Origin attribute of the routes learned by
other means is Incomplete. For example, for the routes imported through the import-
route command by BGP, the Origin attribute is Incomplete.
l AS_Path
The AS_Path is used to record all ASs that a route passes through from the local end to the
destination in the distance-vector (DV) order.
Assume that the BGP speaker advertises a local route:
When advertising the route to other ASs, the BGP speaker adds the local AS number
in the AS_Path list, and advertises it to the neighboring routers through Update
messages.
When advertising the route to the local AS, the BGP speaker creates an empty AS_Path
list in an Update message.
Assume that the BGP speaker advertises the routes learned from the Update messages of
other BGP speakers:
When advertising the route to other ASs, the BGP speaker adds the local AS number
to the leftmost of the AS_Path list. According to the AS_Path attribute, the BGP
router that receives the route can know the ASs through which the route passes to the

destination. The number of the AS that is nearest to the local AS is placed on the top of
the list. The other AS numbers are arranged in sequence.
When the BGP speaker advertises the route to the local AS, it does not change the
AS_Path.
l Next_Hop
The Next_Hop attribute of BGP is different from that of IGP. It is not necessarily the IP
address of a neighboring router. Generally, the Next_Hop attribute complies with the
following principles:
When advertising a route to an EBGP peer, the BGP speaker sets the next hop of the
route to be the address of the local interface through which the BGP peer relationship
is set up.
When advertising a locally generated route to an IBGP peer, the BGP speaker sets the
next hop of the route to be the address of the local interface through which the BGP
peer relationship is set up.
When advertising a route learned from an EBGP peer to an IBGP peer, the BGP speaker
does not change the next hop of the route.
l MED
The Multi-Exit-Discriminator (MED) is exchanged only between two neighboring ASs.
The AS that receives the MED does not advertise it to any other ASs.
The MED serves as the metric used by an IGP. It is used to determine the optimal route
when traffic enters an AS. When a BGP router obtains multiple routes to the same
destination address but with different next hops through EBGP peers, the route with the
smallest MED value is selected as the optimal route.
l Local_Pref
The Local_Pref attribute is exchanged only between IBGP peers and is not advertised to
other ASs. It indicates preferences of the BGP routers.
The Local_Pref attribute is used to determine the optimal route when traffic leaves an AS.
When a BGP router obtains multiple routes to the same destination address but with
different next hops through IBGP peers, the route with the largest Local_Pref value is
selected.
Policies for BGP Route Selection

When there are multiple routes to the same destination, BGP selects routes according to the
following policies:
1. Prefers the route with the highest PreVal.

PrefVal is a Huawei-specific parameter. It is valid only on the device where it is configured.
2. Prefers the route with the highest Local_Pref.
A route without Local_Pref is considered to have had the value set by using the default
local-preference command or to have a value of 100 by default.
3. Prefers a locally originated route. A locally originated route takes precedence over a route
learned from a peer.
Locally originated routes include routes imported by using the network command or the
import-route command, manually aggregated routes, and automatically summarized
routes.

(1) A summarized route is preferred. A summarized route takes precedence over a non-
summarized route.
(2) A route obtained by using the aggregate command is preferred over a route obtained
by using the summary automatic command.
(3) A route imported by using the network command is preferred over a route imported
by using the import-route command.
4. Prefers the route with the shortest AS_Path.
l The AS_CONFED_SEQUENCE and AS_CONFED_SET are not included in the
AS_Path length.
l An AS_SET counts as 1, no matter how many ASs are in the set.
l After the bestroute as-path-ignore command is run, the AS_Path attributes of routes
are not compared in the route selection process.
5. Prefers the route with the highest Origin type. IGP is higher than EGP, and EGP is higher
than Incomplete.
6. Prefers the route with the lowest Multi Exit Discriminator (MED).
l The MEDs of only routes from the same AS but not a confederation sub-AS are
compared. MEDs of two routes are compared only when the first AS number in the
AS_SEQUENCE (excluding AS_CONFED_SEQUENCE) is the same for the two
routes.
l A route without any MED is assigned a MED of 0, unless the bestroute med-none-as-
maximum command is run. If the bestroute med-none-as-maximum command is run,
the route is assigned the highest MED of 4294967295.
l After compare-different-as-med command is run, the MEDs in routes sent from peers
in different ASs are compared. Do not use this command unless it is confirmed that
different ASs use the same IGP and route selection mode. Otherwise, a loop may occur.
l If the bestroute med-confederation command is run, MEDs are compared for routes
that consist only of AS_CONFED_SEQUENCE. The first AS number in the
AS_CONFED_SEQUENCE must be the same for the routes.
l After the deterministic-med command is run, routes are not selected in the sequence
in which routes are received.
7. Prefers EBGP routes over IBGP routes.
EBGP is higher than IBGP, IBGP is higher than LocalCross, and LocalCross is higher than
RemoteCross.
If the ERT of a VPNv4 route in the routing table of a VPN instance on a PE matches the
IRT of another VPN instance on the PE, the VPNv4 route will be added to the routing table
of the second VPN instance. This is called LocalCross. If the ERT of a VPNv4 route from
a remote PE is learned by the local PE and matches the IRT of a VPN instance on the local
PE, the VPNv4 route will be added to the routing table of that VPN instance. This is called
RemoteCross.
8. Prefers the route with the lowest IGP metric to the BGP next hop.
NOTE
Assume that load balancing is configured. If the preceding rules are the same and there are multiple
external routes with the same AS_Path, load balancing will be performed based on the number of
configured routes.
9. Prefers the route with the shortest Cluster_List.
10. Prefers the route advertised by the router with the smallest router ID.

NOTE
If routes carry the Originator_ID, the originator ID is substituted for the router ID during route
selection. The route with the smallest Originator_ID is preferred.
11. Prefers the route learned from the peer with the smallest address if the IP addresses of peers
are compared in the route selection process.
Policies for BGP Route Advertisement

BGP adopts the following policies to advertise routes:
l The BGP speaker advertises only the optimal route to its peer when there are multiple valid
routes.
l The BGP speaker advertises the routes learned from EBGP routers to all BGP peers,
including EBGP peers and IBGP peers.
l The BGP speaker does not advertise the routes learned from IBGP routers to its IBGP peers.
l The BGP speaker advertises the routes learned from IBGP routers to its EBGP peers.
l The BGP speaker advertises all BGP routes to the new peers when the peer relationship is
established.
Synchronization of IBGP and IGP

The synchronization of IBGP and IGP is to prevent misleading external AS routers.
If a non-BGP router in an AS provides forwarding service, IP packets forwarded by this AS may
be discarded because the destination address is unreachable. As shown in Figure 8-3, Router E
learns a route 8.0.0.0/8 of Router A from Router D through BGP, and then forwards the packet
to Router D. Router D searches the routing table and finds that the next hop is Router B. Router
D forwards the packet to Router C through route iteration, because Router D learns a route to
Router B through IGP. Router C, however, does not know the route to 8.0.0.0/8 and discards
the packet.
Figure 8-3 Synchronization of IBGP and IGP
8.0.0.0/8
AS20 IGP
RouterC
IGP RouterE
RouterA IBGP EBGP
AS10 EBGP AS30
RouterB RouterD
If the synchronization is configured, routers check the IGP routing table before adding the IBGP
route to the routing table and advertising it to the EBGP peers. The IBGP route is added to the
routing table and advertised to the EBGP peers only when IGP knows this IBGP route.
The synchronization can be disabled surely in the following cases:
l The local AS is not a transitive AS (The AS20 in Figure 1 is a transitive AS).
l All routers in the local AS are full-meshed IBGP peers.

NOTE
In the NE80E/40E, the synchronization function is disabled by default.
8.3.2 Route Import

BGP itself cannot discover routes. Therefore, it needs to import other protocol routes, such as
IGP or static routes to the BGP routing table. In this manner, these imported routes can be
transmitted within an AS or between ASs.
BGP can import routes either in Import mode or in Network mode.
l In Import mode, BGP imports routes according to protocol types, for example, Routing
Information Protocol (RIP) routes, Open Shortest Path First (OSPF) routes, Intermediate
System-to-Intermediate System (IS-IS) routes, static routes, or direct routes.
l The Network mode is more precise than the Import mode. In Network mode, routes with
the specified prefix and mask are imported to the BGP routing table.

In a large-scale network, the BGP routing table is rather large. You can configure route
aggregation to reduce the size of the routing table.
Route aggregation refers to the process of aggregating multiple routes into one route. After route
aggregation, BGP advertises only the aggregated route rather than all specific routes to BGP
peers.
Two modes of BGP route aggregation are supported:
l Automatic aggregation: aggregates the routes imported by BGP. After automatic
aggregation is configured, BGP aggregates routes according to the natural network segment
and sends only the aggregated route to the peers. For example, 10.1.1.1/24 and 10.2.1.1/24
are aggregated to 10.0.0.0/8, which is a Class A address.
l Manual aggregation: aggregates routes in the local BGP routing table. Manual aggregation
can be used to control the attributes of the aggregated route and determine whether to
advertise the specific routes.
IPv4 supports both automatic aggregation and manual aggregation, whereas IPv6 supports only
manual aggregation.
8.3.4 Route Dampening

Route instability is reflected by route flapping. That is, a route in a routing table disappears and
reappears frequently.
NOTE
A route is added to the routing table, and then is withdrawn. This process is called one route flapping.
When route flapping occurs, a device sends a routing update to the neighbors. The devices that
receive the routing update need to recalculate routes and modify routing tables. Frequent route
flapping consumes lots of bandwidths and CPU resources, and even affects the normal operation
of a network.
Route dampening solves the problem of route instability. In most situations, BGP is applied to
complex networks where routes change frequently. To avoid the impact of frequent route
flapping, BGP adopts route dampening to suppress unstable routes.

BGP dampening measures the stability of a route by using a penalty value. The greater the penalty
value, the more unstable the route. Each time route flapping occurs (route flapping refers to that
a route changes from active to inactive), BGP adds a certain penalty value (1000) to this route.
When the penalty value of a route exceeds the suppression threshold, the route is suppressed.
As a result, BGP does not add the route to the routing table, or advertise any Update message
to BGP peers.
The penalty value of the suppressed route decreases to half after a certain period. This period is
called half life. When the penalty value decreases to the reuse value, the route is reusable and is
added to the routing table. At the same time, BGP advertises an Update message to BGP peers.
The penalty value, suppression threshold, and half life can be manually configured. Figure
8-4 shows the process of BGP route dampening.
Figure 8-4 Diagram of BGP route dampening
Penalty value
suppress value
reuse value
suppress time
time
half-life
Route dampening applies only to EBGP routes. IBGP routes, however, cannot be dampened.
Generally, IBGP routes contain the routes from the local AS, which require that the forwarding
tables be the same. In addition, IGP fast convergence aims to achieve information
synchronization. Therefore, if IBGP routes are dampened, dampening parameters vary on
different devices, and thus the forwarding tables are inconsistent with each other.
8.3.5 Community Attribute

A community is a set of destination addresses with the same characteristics. It is expressed as a
list in the unit of four bytes. In the device, the community is in the format of aa:nn or the
community number.
l aa:nn: The value of aa or nn ranges from 0 to 65535. The administrator can set a specific
value as required. aa indicates the AS number and nn indicates the community identifier
defined by the administrator. For example, if a route is from AS 100, and its community
identifier defined by the administrator is 1, the format of the community is 100:1.

l Community number: It is an integer that ranges from 0 to 4294967295. As defined in RFC

1997, numbers from 0 (0x00000000) to 65535 (0x0000FFFF) and from 4294901760
(0xFFFF0000) to 4294967295 (0xFFFFFFFF) are reserved.
The community is used to simplify the application, maintenance, and management of routing
policies. With the community, a group of BGP devices in multiple ASs can share the same
routing policy. The community is a route attribute. It is transmitted between BGP peers and is
not restricted by the AS. Before advertising a route with the community to peers, a BGP device
can change the original community of this route.
The peer group allows a group of peers to share the same policy while the community allows a
group of BGP routes to share the same policy.
Besides the well-known communities, you can use a community filter to filter self-defined
extended communities to control routing policies in a more flexible manner.
Well-known Community
Table 8-3 lists the well-known communities of BGP routes.
Table 8-3 Well-known communities of BGP routes

Community Community Description
Name Identifier
Internet 0 By default, all routes belong to the Internet

(0x00000000) community. A route with this attribute can be
advertised to all BGP peers.
No_Export 4294967041 A route with this attribute cannot be advertised

(0xFFFFFF01) outside the local AS. If a confederation is
defined, the route with this attributes cannot be
advertised to the ASs outside the confederation,
but to other sub-ASs in the confederation.
No_Advertise 4294967042 A route with this attribute cannot be advertised

(0xFFFFFF02) to any other BGP peers.
No_Export_Subcon- 4294967043 A route with this attribute cannot be advertised

fed (0xFFFFFF03) outside the local AS or to other sub-ASs in the
confederation.
Networking Applications
As shown in Figure 8-5, EBGP connections are established between Router B and Router A,
and between Router B and Router C. With the community attribute of No_Export configured
on Router A, the routes from AS10 advertised to AS20 are not advertised to other ASs by AS20.

Figure 8-5 Networking diagram of configuring BGP communities
AS 10
RouterA
EBGP
AS 20 EBGP AS 30
RouterC
RouterB
8.3.6 Route Reflector

Generally, fully meshed connections need to be established between IBGP peers to ensure the
connectivity between them. If there are n routers in an AS, n (n-1)/2 IBGP connections need to
be established. If there are a lot of IBGP peers, network resources and CPU resources are greatly
consumed. To solve this problem, route reflection is introduced.
In an AS, one router severs as a Route Reflector (RR) and the other routers serve as clients. The
clients establish IBGP connections with the RR. The RR and its clients form a cluster. The RR
reflects routes between clients, and thus clients do not need to establish BGP connections.
A BGP device that functions neither an RR nor a client is called a non-client. A non-client must
establish a fully meshed connection with an RR and with all the other non-clients, as shown in
Figure 8-6.
Figure 8-6 Networking Diagram of an RR
Route
Reflector Non-Client
IBGP IBGP
Client
IBGP IBGP
Cluster IBGP IBGP
Client Client Non-Client

AS65000

Applications
After receiving routes from peers, an RR selects the optimal route based on BGP route selection
policies. The RR advertises the learned routes to its IBGP peers according to the rules defined
in RFC 2796.
l After learning routes from a non-client IBGP peer, the RR advertises the routes to all the
clients.
l After learning routes from a client, the RR advertises the routes to all the other clients and
all non-clients.
l After learning routes from an EBGP peer, the RR advertises the routes to all clients and
non-clients.
An RR is easy to configure, because it needs to be configured only on the device that functions
as a reflector, and clients do not need to know that they are clients.
On some networks, if clients of an RR establish fully meshed connections between each other,
they can exchange routing information directly. In this case, route reflection between clients is
unnecessary and occupies bandwidth. On the NE80E/40E, the undo reflect between-clients
command can be run to disable route reflection between clients, but routes between clients and
non-clients can still be reflected. By default, route reflection between clients is enabled.
Originator_ID
The Originator_ID attribute and the Cluster_List attribute are defined in RFC 2796. They are
used to detect and prevent routing loops.
The Originator_ID attribute is four bytes long and is generated by an RR. It carries the router
ID of the originator of the route in a local AS.
l When a route is reflected by an RR for the first time, the RR adds the Originator_ID attribute
to this route to identify the originating router of the route. If a route already has the
Originator_ID attribute, the RR does not create a new Originator_ID.
l When another BGP speaker receives the route, it compares the Originator_ID added to the
route with the local router ID. If the Originator_ID and the local router ID are the same,
the BGP speaker ignores this route.
Cluster_List
To avoid routing loops between ASs, a BGP router uses the AS_Path attribute to record the ASs
that a route passes through. The route with the local AS number is discarded by the router. To
avoid routing loops within an AS, a BGP router prohibits IBGP peers from advertising the routes
learned from the local AS.
An RR is implemented on the basis that IBGP peers can advertise the routes learned from the
local AS to each other. In this case, the Cluster_List attribute is introduced to avoid routing loops
within an AS.
An RR and its clients form a cluster. In an AS, each RR is uniquely identified by a Cluster_ID.
To avoid routing loops, the RR uses the Cluster_List attribute to record the Cluster_IDs of all
RRs that a route passes through.
The Cluster_List is composed of a series of Cluster_IDs. It records all the RRs that a route passes
through. The Cluster_List is similar to the AS_Path list and is generated by an RR.

l When an RR reflects routes between its clients or between its clients and non-clients, the
RR adds the local Cluster_ID to the top of the Cluster_List. If the Cluster_List is empty,
the RR creates a new one.
l When receiving an updated route, the RR checks its Cluster_List. If the Cluster_List
contains the local Cluster_ID, the RR discards the received 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 updated route.
Backup RR
To enhance the reliability of a network and avoid the single node fault, more than one RR needs
to be configured in a cluster. RRs in the same cluster have the same Cluster_ID, thus avoiding
routing loops. On the NE80E/40E, you can run the reflector cluster-id command to configure
the same Cluster_ID for all RRs in a cluster.
In the redundant environment, clients can receive multiple routes to the same destination from
different RRs. Clients then apply route selection policies to select the optimal route.
Figure 8-7 Backup RR
RR1 RR2
IBGP
Cluster
IBGP IBGP IBGP
Client1 Client2 Client3

AS65000
As shown in Figure 8-7, RR1 and RR2 are in the same cluster. RR1 and RR2 establish an IBGP
connection. That is, the two RRs are non-clients.
l When Client 1 receives an updated route from an external peer, it advertises the route to
RR1 and RR2 through IBGP.
l After receiving the updated route, RR1 reflects the route to other clients (Client 2 and Client
3) and non-clients (RR2) and adds the local Cluster_ID to the top of the Cluster_List.
l After receiving the reflected route, RR2 checks the Cluster_List. RR2 finds that its
Cluster_ID is contained in the Cluster_List; therefore, it discards the updated route and
does not reflect the route to its clients.
NOTE
The application of the Cluster_List ensures that routing loops do not occur between RRs in the same AS.
Multiple Clusters in an AS
Multiple clusters may exist in an AS. RRs are IBGP peers of each other. An RR can be configured
as a client or non-client of another RR. Therefore, the relationship between clusters in an AS
can be configured flexibly.

For example, a backbone network is divided into multiple reflection clusters. Each RR is
configured as a non-client of the other RRs, and these RRs are fully meshed. Each client
establishes IBGP connections with only the RRs in the same cluster. In this manner, all BGP
routers in the AS can receive the reflected routes, as shown in Figure 8-8.
Figure 8-8 Multiple clusters in an AS
Cluster 4
Cluster 3
Client Client Client
Client
Client
Client RR
RR
RR RR Client
Client
Client Client Client
AS100 Cluster 1 Cluster 2
Hierarchical Reflector
In the actual deployment of RRs, the scenario of the hierarchical reflector is usually used. As
shown in Figure 8-9, the ISP provides Internet routes for AS 100. Two EBGP connections are
established between the ISP and AS 100. AS 100 is divided into two clusters. The four routers
in Cluster 1 are core routers.
l Two Level-1 RRs (RR-1) are deployed in Cluster 1. This redundant structure ensures the
reliability of the core layer of AS 100. The other two routers at the core layer serve as clients
of RR-1.
l One Level-2 RR (RR-2) is deployed in Cluster 2. RR-2 is the client of RR-1.

Figure 8-9 Hierarchical reflector
ISP
EBGP EBGP
RR-1 RR-1
Cluster1 Client/RR-2
Client
Cluster2
AS100
Client Client
TIP
In the networking with RRs, if BGP preferred routes do not need to guide packet forwarding, after the
BGP-RIB-only feature is configured, all the BGP preferred routes are not added to the IP routing table and
are not delivered to the forwarding layer. In this manner, the forwarding efficiency is improved and the
system capacity is expanded.
8.3.7 BGP Confederation

The confederation is another method of dealing with increasing IBGP connections in an AS. It
divides an AS into several sub-ASs. IBGP full meshes are established in each sub-AS, and EBGP
full meshes are established between sub-ASs, as shown in Figure 8-10.

Figure 8-10 Diagram of a confederation
RouterB RouterC
AS 65002 AS 65003
AS 65001
RouterA RouterD
RouterF
AS 100
AS 200
RouterE
For BGP speakers outside the confederation (for example, the devices in AS100), the sub-ASs
(AS65001, AS65002, and AS65003) in the same confederation are invisible. The external
devices do not need to know the topology of each sub-AS. The confederation ID is the AS number
that is used to identify the entire confederation. For example, AS 200 as shown in Figure
8-10 is the confederation ID.
As shown in Figure 8-10, there are multiple BGP devices in AS200. To reduce IBGP
connections, AS200 is divided into three sub-ASs, namely, AS65001, AS65002, and AS65003.
In AS65001, IBGP full meshes are established between the three devices.
Applications and Limitations

The confederation needs to be configured on each device, and the device that joins the
confederation must support the confederation function.
The confederation has disadvantages. For example, if the devices originally are not in a
confederation but later need to be configured as a confederation, the logical topology changes
accordingly.
In large-scale BGP networks, RR and confederation can be used together.
NOTE
The old speaker with 2-byte AS numbers and the new speaker with 4-byte AS numbers cannot exist in the
same confederation. Otherwise, routing loops may occur because AS4_Path does not support
confederations.

8.3.8 MP-BGP
The traditional BGP-4 manages only the IPv4 unicast routing information. The inter-AS
transmission of the packets of other network layer protocols (such as, IPv6 and multicast),
however, is limited.
To support multiple types of network layer protocols, the Internet Engineering Task Force
(IETF) extends BGP-4 to Multiprotocol Extensions for BGP-4 (MP-BGP). The current MP-
BGP standard is RFC 4760. MP-BGP is forward compatible. That is, the routers supporting BGP
extension can communicate with the routers that do not support BGP extension.
As an enhancement of BGP-4, MP-BGP provides routing information for various protocols,
such as IPv6 (BGP4+) and multicast.
l MP-BGP maintains unicast and multicast routing information, and stores the two types of
routing information in different routing tables. This ensures the separation of unicast and
multicast routing information.
l MP-BGP supports unicast and multicast, and constructs different network topologies for
them.
l The unicast routing policy and configurations supported by BGP-4 can mostly be applied
to multicast, and thus BGP-4 can maintain unicast and multicast routes according to the
routing policy.
Extended Attributes
Among packets involved in BGP-4, three IPv4-related attributes are carried by the Update
packet: NLRI, Next_Hop, and Aggregator. Aggregator contains the IP address of the BGP
speaker that performs route aggregation.
To support multiple types of network layer protocols, BGP-4 needs to carry the information
about network layer protocols in NLRI and Next_Hop. MP-BGP introduces the following route
attributes:
l MP_REACH_NLRI: indicates the multiprotocol reachable NLRI. It is used to advertise a
reachable route and the next hop.
l MP_UNREACH_NLRI: indicates the multiprotocol unreachable NLRI. It is used to
withdraw an unreachable route.
The two attributes are optional non-transitive. Therefore, the BGP speakers that do not support
multiprotocol will ignore the information carried by the two attributes, and do not advertise the
information to the peers.
Address Family
BGP uses address families to distinguish different network layer protocols. For the values of
address families, refer to RFC 3232 (assigned numbers). The NE80E/40E supports multiple MP-
BGP extension applications, such as VPN extension and IPv6 extension, which are configured
in the corresponding address family views.
For details of MP-BGP in multicast, see the HUAWEI NetEngine80E/40E Feature Description
- IP Multicast.
For details on the BGP VPNv4 address family, BGP VPN instance address family, BGP L2VPN
address family, and BGP VPLS address family, see the HUAWEI NetEngine80E/40E Feature
Description - VPN.

8.3.9 BGP GR
When BGP restarts, the peer relationship is re-established and the forwarding is interrupted.
After Graceful Restart (GR) is enabled, traffic interruption can be avoided.
The following roles are involved in the GR process:
l GR restarter: indicates a device that performs GR caused by a fault or triggered by the
administrator. The GR restarter must be a GR-capable device. That is, the router must be
enabled with GR and negotiates the GR capability with its peer.
l GR helper: indicates a neighbor of the GR restarter. The GR helper must also have the GR
capability.
The following concepts are involved in the GR process:
l GR session: indicates the session with the GR capability. The GR session is a negotiation
mechanism between the GR restarter and the GR helper. By controlling the session
negotiation mechanism of the protocols, the GR restarter and the GR helper can know each
other's GR capability and set up a GR session.
l GR time: indicates the time during which a GR helper retains the forwarding information
after detecting that the GR restarter is Down. When detecting that the GR restarter is in the
Down state, the GR helper retains the topology or routing information obtained from the
GR restarter and does not delete the information during the GR time.
Principles of BGP GR are listed as follows:
l Using the capability negotiation mechanism of BGP, BGP speakers negotiate the GR
capability before setting up a BGP session with the GR capability.
l When detecting the restart of the GR restarter, a GR helper does not delete the routing
information and forwarding entries related to the GR restarter, but waits to re-establish a
BGP connection with the GR restarter.
l After setting up a new BGP connection, the GR restarter and the GR helper update BGP
routes.
In this manner, the forwarding is not interrupted. In addition, the flapping of BGP occurs only
on the neighbors of the GR restarter, and does not occur in the entire routing domain. This is
important for BGP that needs to process a large number of routes.
8.3.10 BGP Security

BGP Authentication
BGP uses TCP as the transport layer protocol. To enhance BGP security, you can perform the
Message Digest 5 (MD5) authentication when a TCP connection is set up. The MD5
authentication, however, does not authenticate BGP packets. Instead, it sets the MD5
authentication password for the TCP connection, and the authentication is performed by TCP.
If the authentication fails, the TCP connection cannot be established.
GTSM of BGP
The Generalized TTL Security Mechanism (GTSM) defends against attacks by checking the
Time-to-Live (TTL refers to the maximum number of routers through which a packet can pass)
value. If an attacker simulates real BGP packets and keeps sending them to a router, an interface
board on the router receives the packets and directly sends them to the main control board for

BGP processing, without checking the validity of the packets. In this case, the router is busy in
processing these packets, causing high usage of the CPU.
The GTSM checks whether the TTL value in the IP packet header is within a pre-defined value
range. In this manner, the GTSM can protect services above the IP layer, thus enhancing system
security.
After the GTSM of BGP is enabled, an interface board checks the TTL values carried in all BGP
packets. As required by the actual networking, packets whose TTL values are not within the
specified range are either allowed to pass or discarded by the GTSM. To configure the GTSM
to discard packets by default, you need to set an appropriate TTL value range according the
network topology. Then, packets whose TTL values are not within the specified range are
discarded. In this manner, attacks by bogus BGP packets are avoided.
You can also enable the log function to record information that GTSM drops packets for fault
location.
8.3.11 BGP 6PE

IPv6 Provider Edge (6PE) interconnects separated IPv6 networks at different locations by using
the MPLS tunneling technology in the existing IPv4 network. Separated IPv6 networks can be
connected through multiple tunneling technologies. For 6PE tunnels, with the IPv4/IPv6 dual-
protocol stack implemented on PEs of the ISP, MP-BGP assigns labels to identify IPv6 routes,
and IPv6 networks are then interconnected through LSPs between PEs.
As shown in Figure 8-11, 6PE needs to run on the edge of the ISP network. PEs connected to
the IPv6 network adopt the IPv4/IPv6 dual-protocol stack. PEs and CEs exchange IPv6 routes
through IGP, EBGP, and static routes of IPv6. Routes are exchanged through IPv4 routing
protocols between PEs and Ps, and between other PEs. Tunnels need to be set up between PEs
to transparently transmit IPv6 packets.
Figure 8-11 Networking diagram of 6PE tunnels
CE1 PE1 PE2 CE2

IPv6 Link IPv4 Link IPv6 Link
Tunnel
Advantages
The advantages of using 6PE tunnels to connect IPv6 networks are as listed follows:
l All configurations are performed on PEs, and the user network cannot sense the existence
of the IPv4 network.
l MPLS network resources of the ISP can be better used, and carriers' networks are not greatly
altered.
l Links between PEs and CEs can be of any type, and there is no special requirement for that.
l 6PE devices can provide multiple types of services such as IPv6 VPN and IPv4 VPN for
users.

8.3.12 6PE Routes Sharing the Explicit Null Label

On a 6PE networking, by default, each 6PE route is assigned. Therefore, each route advertised
to other 6PE peers needs to apply for a label. The number of required labels is directly
proportional to the number of 6PE routes. When there are many 6PE routes, a large number of
labels are required.
After 6PE routes sharing the explicit null label is enabled, all 6PE routes share the explicit null
label 2, without applying for labels. In such a case, the number of required labels is irrelevant
to the number of 6PE routes, thus saving label resources on 6PE routers.
The explicit null label 2 is a special label which needs to be popped out on the egress PE. The
packets then must be forwarded on the basis of IPv6.
Figure 8-12 6PE networking diagram
CE1 6PE1 6PE2 CE2
IPv4/MPLS
Backbone
In the 6PE networking shown in Figure 8-12, 6PE routes sharing the explicit null label is enabled
on 6PE1. 6PE1 then can advertise routes sharing the explicit null label 2 to 6PE2 without
applying for a label for each route. When 6PE2 sends data to 6PE1, the data packet carries two
labels, the top label being the label assigned by LDP and the bottom label is the explicit null
label 2 assigned by MP-BGP. After the data packet reaches 6PE1, 6PE1 pops the explicit null
label 2 and forwards the IPv6 data packet to CE1.
Note that when you enable or disable 6PE routes sharing the explicit null label after a 6PE peer
relationship is set up, temporary packet loss occurs. Therefore, enable this function prior to
setting up a 6PE peer relationship.
8.3.13 BFD for BGP

Bidirectional Forwarding Detection (BFD) provides fast link fault detection for BGP. BGP
periodically sends messages to the peer to detect the status of the peer. The detection, however,
lasts more than one second. When the data transmission rate reaches the level of Gbit/s, such a
slow detection will cause a large amount of data to be lost. As a result, the requirement for high
reliability of carrier-class networks cannot be met.
Therefore, BFD for BGP is introduced to fast detect faults on the links between BGP peers in
milliseconds and notify the faults to BGP. Therefore, BGP routes can fast converge.
BFD for BGP is applicable to both IPv4 and IPv6 networks.
Networking
As shown in Figure 8-13, Router A belongs to AS 100 and Router B belongs to AS 200, and
the EBGP peer relationship is established between them.

BFD is enabled to detect the BGP relationship between Router A and Router B. When the link
between Router A and Router B becomes faulty, BFD can fast detect the fault and notify it to
BGP.
Figure 8-13 Networking diagram of BFD for BGP
EBGP
AS100 AS200
RouterA RouterB
8.3.14 BGP Tracking

Bidirectional Forwarding Detection (BFD) provides fast link failure detection for BGP. BFD,
however, needs to be deployed globally, which is difficult to implement. Instead, you can
configure BGP tracking on the local device for fast link failure detection.
After BGP tracking is enabled on BGP peers, when a link between the BGP peers fails, one BGP
peer can rapidly detect the unreachability of its neighbor, terminate the connection with the
neighbor, and delete the routes received from the neighbor. Fast route convergence is thus
implemented.
The interval between when BGP detects the peer unreachable and when BGP terminates the
associated connection needs to be configured properly to ensure network stability.
l If the interval is set to 0, BGP immediately terminates the connection between the local
device and its peer after detecting the peer unreachable.
l If IGP route flapping occurs and the interval is set to 0, the peer relationship between the
local device and its peer alternates between Up and Down. Therefore, the interval should
be set to a value greater than the actual IGP route convergence time.
l When BGP neighbors successfully perform GR negotiation, active/standby switchover
occurs on the BGP neighbors. To prevent the failure of GR, the interval should be set to a
value greater than the GR convergence time. If the interval is set to be smaller than the GR
convergence time, the connection between the local device and its BGP peer will be
terminated, thus leading to the failure of GR.
BGP tracking can speed up network convergence and is easy to deploy. BGP route convergence
on a network configured with BGP tracking, however, is slower than that on a network enabled
with BFD. Therefore, BGP tracking cannot meet the requirements of voice services that require
the high convergence speed.
Networking
As shown in Figure 8-14, Router A and Router C establish an IBGP neighbor relationship. BGP
tracking is configured on Router A. Therefore, when the link between Router A and Router B
fails, Router A can detect that Router C is unreachable after IGP fast route convergence and then
terminates the BGP connection with Router C.

Figure 8-14 Networking diagram of BGP tracking
8.3.15 BGP Auto FRR

As a protection measure against faults over the link, BGP Auto FRR (Fast Re-Route) is
applicable to the network topology with primary and backup links. With BGP Auto FRR,
switching between two BGP neighbors or two next hops can be implemented at the sub-second
level.
After BGP auto FRR is enabled on a device, the device selects the optimal route from the routes
which carry the same prefix and are learnt from multiple peers to forward packets. In addition,
the device automatically adds information about the second optimal route to the backup
forwarding entries of the optimal route, and delivers the backup forwarding entry to the FIB
table and then to the data forwarding plane. When the primary link fails, the system quickly
responds to the message that the BGP route is unreachable and switches traffic to the backup
link.
As shown in Figure 8-15, Router Y advertises a learned BGP route to Router X2 and Router
X3 in AS 100; Router X2 and Router X3 then advertise the BGP route to Router X1 through the
reflector. Router X1 thus receives two routes whose next hops are Router X2 and Router X3
respectively. Then, Router X1 selects a route according to the configured policy. Assume that
the route received from Router X2, is preferred. Link B, then functions as the backup link.
Figure 8-15 Networking for BGP Auto FRR

Loopback1
2.2.2.2/32
RR
Loopback1 RouterX2
1.1.1.1/32
LinkA
AS100 AS200
RouterX1 LinkB RouterY
RouterX3
RR
Loopback1
3.3.3.3/32

When a device along Link A fails or faults occur on Link A, the next hop of the route to Router
X2 becomes invalid on Router X1. If BGP Auto FRR is enabled on Router X1, the forwarding
plane then quickly switches traffic sent from Router X1 to Router Y to Link B. This ensures
transmission of the traffic. In addition, Router X1 reselects the route received from Router X3
according to the forwarding prefixes and then updates the FIB table.
8.3.16 BGP ORF

Outbound Route Filtering (ORF) is used to enable a BGP device to send to its BGP peer a set
of routing policies that can be used by its peer to filter out unwanted routes during route
advertisement.
A user wants a carrier to send only the required routes, whereas the carrier does not want to
maintain a separate outbound policy for every user. Therefore, a solution is required by the
carrier to send only required routes to each user without maintaining a separate outbound policy
for each user. Thus, ORF is developed to meet the requirements of users and carriers. ORF
supports on-demand route advertisement, which greatly reduces bandwidth consumption and
effectively reduces the efforts of configuration.
The VRP supports two types of ORF:
l Prefix-based ORF
Prefix-based ORF, defined in RFC 5291 and RFC 5292, can be used to send prefix-based
inbound policies configured by users to a carrier through Route-Refresh (RR) messages.
The carrier then filters out unwanted routes during route advertisement based on the
received inbound policies. This prevents users from receiving a large number of unwanted
routes and thus saves resources.
l VPN ORF
VPN ORF, defined in RFC 4684, enables a PE to receive only wanted routes, which reduces
the burden of receiving a large number of routes and reduces the routing table capacities
of Router Reflectors (RR)s and Autonomous System Border Routers (ASBRs).
Applications
As shown in Figure 8-16, Router A and Router B are directly connected, and are enabled with
prefix-based ORF; after negotiating the prefix-based ORF capability with Router B, Router A
adds the local prefix-based inbound policy to a Route-Refresh message, and then sends the
Route-Refresh message to Router B. Based on the received Route-Refresh message, Router B
works out an outbound policy for advertising routes to Router A.
Figure 8-16 Applying ORF to directly connected BGP peers
RouterA RouterB
AS100 AS200
As shown in Figure 8-17, there is an RR in the domain, and Router A and Router B are the
clients of the RR; Router A, Router B, and the RR are enabled with prefix-based ORF. After

negotiating prefix-based ORF with the RR, Router A and Router B add the local prefix-based
inbound policies to Route-Refresh messages, and then send the Route-Refresh messages to the
RR. Based on the Route-Refresh messages received from Router A and Router B, the RR works
out associated outbound policies for reflecting routes to Router A and Router B.
Figure 8-17 Applying ORF to a domain with an RR

RR
RouterA RouterB
As shown in Figure 8-18, PE1 and PE2 are added to VPN1, and the same IRT (Import Route
Target) is set on PE1 and PE2. PE1 and PE2 send RT route to the RR. Assume that the RR
prefers the RT route sent by PE1. In this case, the RR sends VPN routes with the ERT (Export
Route Target) being 1:1 to not only PE1 but also PE2.
Figure 8-18 Applying ORF to a VPN

Intra-AS
RR
PE1 PE2
VPN1 VPN1
Import: 1:1 Import: 1:1
Export: 1:1 Export: 1:1
As shown in Figure 8-19, nodes a, b, c, d, e, f, g, h, i, and j are in different ASs. Assume that
node i initiates RT route. There are two available paths from node e to node i, that is, path (i,f,e)
and path (i,h,g,e). Node e prefers path (i,f,e) because the path is shorter, and sends the path to
node b and node d. Node b and node d then send the path to node a. If node a prefers the path
(e,b,a), node a sends VPN routes to node i along the path (a,b,e,f,i). In this case, node d, node
g, and node h on the sub-optimal paths (e,d,a) and (i,h,g,e) cannot receive the VPN routes.

Figure 8-19 Applying ORF between VPNs

Inter-AS
a b c
f j
d e
g h i
8.3.17 Active-Route-Advertise
Currently, only the route preferred by BGP is advertised to neighbors. In the earlier versions,
only the route preferred by the routing management layer is advertised. In this manner, Active-
Route-Advertise is designed to implement forward compatibility.
By default, once a route is preferred by BGP, the route can be advertised to neighbors. When
Active-Route-Advertise is configured, only the route preferred by BGP and also active on the
routing management layer is advertised to neighbors.
NOTE
Imported routes are active in the IP routing table and thus are not restricted by the active-route-
advertise command.
8.3.18 BGP Dynamic Update Peer-Groups

Currently, with the rapid increase in the size of the routing table and the complexity of the
network topology, BGP is required to support more neighbors. Especially in the case of a large
number of neighbors and routes, high-performance packaging and forwarding are required when
a device needs to send routes to a large number of BGP neighbors, most of which share the same
outbound policies.
The dynamic update peer-groups feature treats all the BGP neighbors with the same outbound
policies as an update-group. In this manner, each route to be sent is grouped once and then sent
to all neighbors in the update-group, improving packaging efficiency exponentially.
Without the dynamic update peer-groups feature, each route to be sent is grouped per neighbor.
With the dynamic update peer-groups feature, routes are grouped uniformly and then sent
separately. That is, each route to be sent is grouped once and then sent to all neighbors in the
update-group, which improves grouping efficiency exponentially. When a large number of
neighbors and routes exist, the BGP dynamic update peer-groups feature greatly improves the
BGP route packaging and forwarding performance.

The application scenarios of the BGP dynamic update peer-groups feature are as follows:
l International gateway
l RR
l Scenario where a device sends the routes received from EBGP neighbors to all IBGP
neighbors
Figure 8-20 Networking for the international gateway
AS1000
AS200
AS65001
AS30
Internet Route
IGW
Router
AS100
AS65002
AS120

Figure 8-21 Networking for the RR with many clients
AS100
RR1 RR2
IBGP IBGP
Client Client Client Client Client Client
Figure 8-22 Networking for a PE connecting multiple IBGP neighbors
AS200
RouterC
IBGP
AS100 RouterD
RouterA EBGP
RouterB RouterE
IBGP
RouterF
In the preceding scenarios, it is a common situation that a device needs to send routes to a large
number of BGP neighbors, most of which share the same outbound policies. This situation is
most obviously presented in the networking shown in Figure 8-21. When a large number of
neighbors and routes exist, the forwarding efficiency is restricted.
After the dynamic update peer-groups feature is applied, each route to be sent is grouped once
and then sent to all neighbors in the update-group, improving packaging efficiency
exponentially. For example, an RR has 100 clients and needs to reflect 100,000 routes to them.
If the RR sends the routes grouped per neighbor to 100 clients, the total number of times that all
routes are grouped is 100,000 x 100. After the dynamic update peer-groups feature is applied,
the total number of grouping times changes to 100,000 x 1. In this manner, performance is
improved by a factor of 100.

8.3.19 BGP NSR

As networks develop fast, the demand for the triple play services of the Public Switched
Telephone Network (PSTN), TV network, and Internet becomes more and more stringent.
Operators pose high requirements for reliability on IP networks. Non-Stop Routing (NSR), as
an High Availability (HA) solution, is thus introduced.
NSR ensures that the control plane of a neighbor does not sense the fault on the control plane
of the local device which provides a slave control plane. In this process, the neighbor
relationships set up through specific routing protocols, MPLS, and other protocols that carry
services are not interrupted.
As an HA solution, NSR ensures that user services are not affected or least affected in the case
of device failures.
During the master/slave switchover, BGP NSR ensures the continuous forwarding and
continuous advertisement of BGP routes. In this process, the neighbor relationships are not
affected, with neighbors not knowing the switchover on the local device. This ensures
uninterrupted transmission of BGP services.
8.3.20 4-Byte AS Number

Currently, 2-byte AS numbers used on the network range from 0 to 65535. However, available
AS numbers become almost exhausted. Therefore, 2-byte AS numbers need to be extended to
4-byte AS numbers, which should also be compatible with the old speaker that supports only 2-
byte AS numbers.
The 4-byte AS number feature extends a 2-byte AS number to a 4-byte AS number, and
negotiates the 4-byte AS number capability and transmits 4-byte AS numbers by defining a new
capability code and new optional transitive attributes. This implements communications between
new speakers that support 4-byte AS numbers, and between old speakers that support only 2-
byte AS numbers and new speakers.
l New speaker: indicates the peer that supports 4-byte AS numbers.

l Old speaker: indicates the peer that does not support 4-byte AS numbers.
l New session: indicates the BGP connection between new speakers.
l Old session: indicates the BGP connection between new speakers and old speakers, or
between old speakers.
BGP Extension
To support 4-byte AS numbers, an open capability code 0x41 is defined for BGP connection
negotiation. The capability code 0x41 indicates that the BGP speaker supports 4-byte AS
numbers.
Two new optional transitive attributes, AS4_Path with the attribute code being 0x11 and
AS4_Aggregator with the attribute code being 0x12, are defined to transmit 4-byte AS numbers
on old sessions.
If a connection is set up between a new speaker and an old speaker and the AS number of the
new speaker is greater than 65535, the remote AS number needs to be specified as AS_TRANS
on the old speaker. AS_TRANS is a reserved AS number with the value being 23456.

Principles
When setting up connections, BGP neighbors determine whether the peer supports 4-byte AS
numbers according to the optional capability field in Open messages.
l New sessions are set up between new speakers; therefore, AS_Path and Aggregator in an
Update message carry 4-byte AS numbers.
l Old sessions are set up between new speakers and old speakers. AS_Path and Aggregator
on old speakers carry 2-byte AS numbers.
When a new speaker sends an Update message to an old speaker, if the AS number of
the new speaker is greater than 65535, AS4_Path and AS4_Aggregator are used together
with AS_Path and AS_Aggregator to carry 4-byte AS numbers. AS4_Path and
AS4_Aggregator are transparent to the old speaker.
When receiving messages containing AS_Path, AS4_Path, AS_Aggregator, and
AS4_Aggregator from an old speaker, a new speaker reconstructs the actual AS_Path
and AS_Aggregator based on the reconstruction algorithm.
As shown in Figure 8-23, there are old speakers that support 2-byte AS numbers and new
speakers that support 4-byte AS numbers in the topology. The 4-byte AS number feature,
together with AS4_Path, transmits routing information between old speakers and new speakers.
Figure 8-23 Networking for the application of 4-byte AS numbers
AS10
old speaker
RouterA
D=(8.0.0.0)
AS_Path (10)
AS20.1 AS50.5
new speaker new speaker
RouterB RouterC
D=(8.0.0.0)
AS_Path (23456, 10) D=(8.0.0.0)
AS4_Path (20.1, 10) AS_Path (40.4, 30, 20.1, 10)
old speaker new speaker

D=(8.0.0.0)
RouterD AS_Path (30, 23456, 10) RouterE
AS4_Path (20.1, 10)
AS30 AS40.4

As shown in Figure 8-23, before advertising route D=8.0.0.0 of AS 10 to other ASs, a BGP
device performs the followings:
1. BGP adds 10, the AS number of AS 10, to the AS_Path list (10).
2. When the route passes AS 20.1, to enable Router D (old speaker) to transmit AS path
information with 4-byte AS numbers, this route carries the AS4_Path attribute, that is, (20.1,
10). Router B then adds AS number 20.1 of the route to the leftmost of the AS_Path list,
that is, (23456, 10). The value 23456 is obtained when AS_TRANS replaces 20.1.
3. When the route passes AS 30, Router D, as an old speaker not aware of AS4_Path,
transparently transmits AS4_Path (20.1, 10) to Router E. Router D then adds AS number
30 of the route to the leftmost of the AS_Path list, that is, (30, 23456, 10).
4. When the route passes AS 40.4, after the reconstruction of AS_Path and AS4_Path, BGP
adds 40.4, the AS number of AS 40.4, to the leftmost of the AS_Path list, that is, (40.4, 30,
20.1, 10).
The rest may be deduced by analogy. After the device in AS 50.5 receives the route, the
device learns the path to AS 10 according to the AS_Path list.
8.3.21 Next-Hop Iteration Based on the Specified Routing Policy

BGP needs to iterate indirect next hops. If indirect next hops are not iterated according to the
routing policy, routes may be iterated to incorrect forwarding paths. Therefore, next hops should
be iterated according to certain conditions to control the iterated routes. Next-hop iteration based
on the specified routing policy controls the iterated next hop according to the specified routing
policy. The route that fails to pass the policy is ignored.
Application
As shown in Figure 8-24, IBGP peer relationships are established between Router A and Router
B, and between Router A and Router C through loopback interfaces. Router A receives a BGP
route with the prefix 10.10.10.10/32 from Router B and Router C. The original next hop of the
BGP route received from Router B is 2.2.2.2. The address of GE 2/0/0 on Router A is 2.2.2.10/24.
Figure 8-24 Next-hop iteration based on the specified routing policy
Loopback0
2.2.2.2/32
Loopback0
1.1.1.1/32 RouterB
GE2/0/0
2.2.2.10/24 GE1/0/0
10.10.10.10/32
GE3/0/0
RouterA
RouterC
Loopback0
AS100 3.3.3.3/32

When Router B runs normally, the BGP route with the prefix 10.10.10.10/32 is iterated to the
IGP route 2.2.2.2/32. When Router B becomes faulty, the IGP route 2.2.2.2/32 is withdrawn.
This causes route iteration again. On Router A, a route is searched for in the IP routing table
based on the original next hop 2.2.2.2. Consequently, the route is iterated to 2.2.2.0/24. The route
with the next hop 2.2.2.2 is expected unreachable so that the route with the next hop 3.3.3.3 is
preferred.
With the next-hop iteration policy, you can control the mask length of the route through which
the original next hop can be iterated. As shown in Figure 8-24, after the next-hop iteration policy
is configured, the route with the original next hop 2.2.2.2 depends on only the IGP route
2.2.2.2/32.

Terms
Term Description
BGP BGP is a dynamic routing protocol used between ASs. Different from IGP
protocols such as OSPF and RIP, BGP focuses on controlling route
transmission and selecting optimal routes, rather than detect or calculate
routes.
BFD Bidirectional Forwarding Detection (BFD) is a common detecting

mechanism by using Hello packets. It can fast detect the change of the link
status and inform the protocol of the change. In this manner, the protocol
can decide whether to establish or turn down the peer relationship.
Abbreviations
Abbreviations Full Spelling
VPN Virtual Private Network
RM Routing Management
AS Autonomous System
ISP Internet Service Provider
EGP Exterior Gateway Protocol
IGP Interior Gateway Protocol
IBGP Internal BGP
EBGP External BGP
CE Customer Edge

Abbreviations Full Spelling
PE Provider Edge
P Provider
MPLS MultiProtocol Label Switch
LSP Label Switched Path
NLRI Network Layer Reachability Information
CIDR Classless Inter-Domain Routing
RR Route Reflector
RIB Route Information Base
MP-BGP Multiprotocol Extensions for BGP
GR Graceful Restart
GTSM Generalized TTL Security Mechanism
TTL Time-To-Live
6PE IPv6 Provider Edge

Feature Description - IP Routing 9 Routing Policies
9 Routing Policies
About This Chapter
9.1 Introduction to Routing Policies

9.2 References
9.3 Principles

9.1 Introduction to Routing Policies

Definition
Routing policies are used to filter routes and control the receiving and advertising of routes. By
changing route attributes (including reachability), a router can change the path that network
traffic passes through.
Purpose
When advertising, receiving, and importing routes, a router implements certain policies
according to actual networking requirements in order to filter the routes and change the attributes
of the routes. Purposes of routing policies are as follows:
l Controlling route advertising

Only the routes that match the rules specified in a policy are advertised.
l Controlling route receiving
Only the required and valid routes are received. This reduces the size of the routing table
and improves network security.
l Filtering and controlling imported routes
To enrich the routing information, a routing protocol may import routing information
discovered by other routing protocols. Only the routing information that satisfies the
conditions is imported. Some attributes of the imported routing information are configured
to meet the requirements of the protocol.
l Setting the attributes for specific routes
You can set attributes for the routes that match the rules.
9.2 References
None.
9.3 Principles
9.3.1 Basic Principle of Routing Policies

You can implement routing policies in the following steps:
1. Define rules. Define features of routing information to which routing policies are applied.
That is, you need to define a set of matching rules regarding different attributes of routing
information such as the destination address and AS number.
2. Implement the rules. Apply matching rules to the routing policies for advertising, receiving,
and importing routes.
Currently, the following filters are provided for routing protocols:
l Access Control List (ACL)

l IP prefix list
l AS path filter
l Community filter
l Extcommunity filter
l Route Distinguisher (RD) filter
ACL
There are ACLs for IPv4 packets and for IPv6 packets respectively. When defining an ACL,
you can specify the IP address and subnet range to match the destination network segment
address or the next hop address of a route.
IP Prefix List
There are IP prefix lists for IPv4 routes and for IPv6 routes respectively.
An IP prefix list is identified by its name. Each IP prefix list contains multiple entries. Each
entry can independently specify a matching range in the form of a network prefix. The matching
range is identified by an index number that designates the matching sequence.
During the matching, the device checks entries identified by the index number in an ascending
order. If a route matches an entry, the route does not match the next entry.
AS Path Filter
Each BGP route contains an AS path domain. AS path filters specify matching rules regarding
AS path domains. AS path filters are exclusively used in BGP.
For more information about the AS path attribute, refer to RFC 1965.
Community Filter
Community filters are exclusively used in BGP. Each BGP route contains a community domain
to identify a community. Community filters specify matching rules regarding community
domains.
For more information about the community attribute, refer to RFC 1997.
Extcommunity Filter
Extended community filters (Extcommunity filters) are exclusively used in BGP. Currently,
Huawei devices support filtration of routes only through the route-target (RT) extcommunity
attribute of VPNs.
RD Filter
RD filters are exclusively used in BGP. RD filters specify matching rules regarding the RD
attribute of VPNs.
Routing Policies
Matching rules are the core of routing policies.

A route policy can use the preceding filters to define its matching rules. A route policy can
consist of multiple nodes and the relationship between these nodes is OR. The system checks
the nodes according to the index number. When a route matches a node in the route policy, the
route does not match the next node.
Each node comprises a set of if-match and apply clauses. The if-match clauses define the
matching rules that are used to match certain route attributes. The relationship between the if-
match clauses of a node is AND. A route passes the filtration of a route policy only when the
route matches all the matching rules defined by the if-match clauses of the node. The apply
clauses specify actions. When a route matches a node, the apply clauses set certain attributes
for the route.
Matching modes of a node are as follows:
l Permit: If a route matches all the if-match clauses of a node, the route matches the route
policy and all the actions defined by apply clauses are performed. If a route does not match
any if-match clause of a node, the route continues to match the next node.
l Deny: If a route matches all the if-match clauses of a node, the route is denied and does
not match the next node.
9.3.2 Application Environment

As routing policies can be flexibly used, no specific networking is required. In general, routing
policies have the following two applications:
l filter-policy { import | export }

import defines acceptable routes. That is, it determines what routes are accepted from the
peer device.
export defines routes to be advertised. That is, it determines what routes are sent to the
peer device.
l import-route (also known as Redistribute)
import-route defines routing information exchange between protocols. By default, a
routing protocol advertises only routing information discovered by itself. import-route
allows a routing protocol to exchange routing information with other protocols and
advertise routes discovered by other protocols.
9.3.3 IP Prefix List

Function
An IP prefix list filters the routes that match IP prefixes according to the configured matching
mode (permit or deny) as required.
An IP prefix list can be configured by running the ip ip-prefix command in the system view.
The matching mode permit or deny can be configured to filter the routes that match IP prefixes
in the IP prefix list. Each IP prefix in an IP prefix list contains an IP address and a mask. The IP
address can be a network segment address or a host address; the mask length ranges from 0 to
32 bits.
Implementation
l Each IP prefix in an IP prefix list is identified by an index number. IP prefixes are matched
in ascending order of index numbers.

l If an index is configured for an IP prefix in an IP prefix list, when no index is configured

for another IP prefix of the same name, the index number increases by a step of 10 from
the last configured index number. For example, assume that an index numbered 10 is
configured for an IP prefix named aa. If a second IP prefix named aa is configured and no
index is configured for it, its index number defaults to 20, increasing by 10 from the
previously configured index numbered 10. If there is a third IP prefix named aa and no
index is configured for it, its index number defaults to 30.
l If the index is increased to 65525 by a step of 10, and another IP prefix of the same name
is configured and no index is configured for it, its index number increases by a step of 1
from the last configured index number, because the index number cannot exceed 65535.
For example, assume that the index number of an IP prefix named aa is 65525. If a second
IP prefix named aa is configured and no index is configured for it, its index number defaults
to 65526, increasing by 1 from 65525.
l When the index number is increased to 65535 by a step of 1, if another IP prefix of the
same name is configured and no index is configured for it, its index number starts from 1
again by a step of 1, because the index number cannot exceed 65535. For example, assume
that the index number of an IP prefix named aa is 65535. If a second IP prefix named aa
is configured and no index is configured for it, its index number defaults to 1. If there is a
third IP prefix named aa and no index is configured for it, its index number defaults to 2,
increasing by 1.
l The number of IP prefixes in an IP prefix list is defined in the license file and defaults to
65535.
l If an IP prefix has the same name and index number as those of another IP prefix but has
a different matching content, the newly configured IP prefix overrides the previous one.
l If a route does not match any IP prefix in an IP prefix list, the matching mode defaults to
deny.
l If an applied IP prefix list does not exist, the matching mode defaults to permit.
Mask Length Range

An IP prefix list is configured to filter routes. An IP prefix can be specified with an IP address
and a mask. In this case, only the route whose destination IP address and mask are the same as
those specified by the IP prefix meets the matching conditions. This is called accurate matching.
An IP prefix can also be specified with an IP address and a mask length range by using the
keyword greater-equal or less-equal. In this case, the routes whose destination IP addresses
are the same as the IP address specified by the IP prefix and whose mask length is within the
mask length range specified by the IP prefix meet the matching conditions. If the keyword
greater-equal or less-equal is not configured, accurate matching is performed according to the
IP prefix list. In this case, only the routes whose IP addresses have the same mask length as the
mask length specified in the IP prefix list meet the matching conditions. If only greater-equal
is configured, the routes with the mask length ranging from the value of greater-equal to 32
bits meet the matching conditions; if only less-equal is configured, the routes with the mask
length ranging from the specified mask length to the value of less-equal meet the matching
conditions.
The value of greater-equal-value and the value of less-equal-value must meet the following
requirements: mask-length<=greater-equal-value<=less-equal-value<=32.

Wildcard Address
0.0.0.0 is a wildcard address. If the IP prefix is 0.0.0.0, you can specify a mask and a mask range
following this IP prefix, indicating that all routes whose mask length is within the specified mask
length range are denied or permitted, irrespective of the mask.
For applications of the wildcard address, see "Wildcard-Address Matching."
Applications
Presume that there are five routes, namely, 1.1.1.1/24, 1.1.1.1/32, 1.1.1.1/26, 2.2.2.2/24,
1.1.1.2/16.
l Single-Node Matching
Case1:
ip ip-prefix aa index 10 permit 1.1.1.1 24
Matching result: Only the route 1.1.1.1/24 is permitted and the other routes are denied.
Note: This is a single-node accurate matching case, which indicates that only the route
whose destination IP address and mask are the same as those specified by the IP prefix
meets the matching conditions. In this application, permit is configured as the matching
mode. Therefore, the route 1.1.1.1/24 is permitted. The other routes are denied because
they do not meet the matching conditions.
Case2:
ip ip-prefix aa index 10 deny 1.1.1.1 24
Matching result: All routes are denied.

Note: This is also a single-node accurate matching case, which indicates that only the
route whose destination IP address and mask are the same as those specified by the IP
prefix meets the matching conditions. In this application, deny is configured as the
matching mode. Therefore, all routes are denied, irrespective of whether they meet the
matching conditions or not.
l Multi-Node Matching
Case1:
Matching result: The route 1.1.1.1/24 is denied; the route 1.1.1.1/32 is permitted; the
other routes are all denied.
Note: In this application case, multi-node accurate matching is applied.
When the route 1.1.1.1/24 is matching node 10 (node with the index being 10), it
meets the matching conditions but is denied because the matching mode is deny.
When the route 1.1.1.1/32 is matching node 10, it does not meet the matching
conditions and continues to match node 20 (node with the index being 20). Because
this route matches the matching conditions of node 20, and the matching mode of
node 20 is permit, this route is permitted.
Other routes do not meet the matching conditions of nodes 10 and 20, and thus these
routes are denied by default.
Case2:
Configuration result: Keyword greater-equal or less-equal is not configured. That is,

the greater-equal-value is 0 and the less-equal-value is 0. Therefore, accurate matching

is performed on routes according to IP prefixes. In this case, only the route whose
destination address and mask length are the same as those specified by the IP prefix
meets the matching conditions.
Matching result: The route 1.1.1.1/24 is permitted, and the other routes are all denied.
Case3:
ip ip-prefix aa index 10 permit 1.1.1.1 24 less-equal 32
Configuration result: The greater-equal-value is 24, and the less-equal-value is 32.

Matching result: The routes 1.1.1.1/24, 1.1.1.1/32, and 1.1.1.1/26 are permitted, and the
other routes are all denied.
When configuring greater-equal and less-equal, ensure that their values meet the
requirement: mask-length<=greater-equal-value<=less-equal-value. Otherwise, the
configurations fail.
Case4:
ip ip-prefix aa index 10 permit 1.1.1.1 24 greater-equal 26

Matching result: The routes 1.1.1.1/32 and 1.1.1.1/26 are permitted, and the other routes
are all denied.
Case5:
ip ip-prefix aa index 10 permit 1.1.1.1 24 greater-equal 26 less-equal 32

Matching result: The routes 1.1.1.1/32 and 1.1.1.1/26 are permitted, and the other routes
are all denied.
l Wildcard-Address Matching
Case1:
Configuration result: The value of greater-equal-value is 8, and the value of less-equal-

value is 32. Because the address 0.0.0.0 is a wildcard address, routes with the mask
length ranging from 8 to 32 bits meet the matching conditions.
Matching result: Routes with the mask length ranging from 8 to 32 bits are all permitted.
Case2:
ip ip-prefix aa index 10 deny 0.0.0.0 24 less-equal 32
Configuration result: For node 10, the greater-equal-value is 24, and the less-equal-
value is 32. Because the address 0.0.0.0 is a wildcard address, routes with the mask
length ranging from 24 to 32 bits are all denied. For node 20, the greater-equal-value
is 0, and the less-equal-value is 32. Because the address 0.0.0.0 is a wildcard address,
all routes except the routes with the mask length ranging from 24 to 32 bits are permitted.
Matching result: The route 1.1.1.2/16 is permitted, and the other routes are denied.
Case3:
Configuration result: For node 10, the route 2.2.2.2/24, which meets the matching
conditions, is denied. For node 20, the other routes are all permitted.
Matching result: All routes except the route 2.2.2.2/24 are permitted.

9.3.4 BGP to IGP

BGP to IGP is an enhancement of the routing policy feature. When an IGP applies a routing
policy to install BGP routes, the attributes of the routes can be set according the private attributes,
such as community, extended community, and AS_path in BGP routes.
Originally, when an IGP installs BGP routes, the private attributes such as community in BGP
routes do not match the routing policy and the BGP routes are denied. As a result, apply clauses
for configuring route attributes do not take effect. In a certain scenario shown in Figure 9-1, the
IGP needs to set the cost according to the private attributes such as community in BGP routes.
BGP to IGP is thus introduced.
l When an IGP installs BGP routes through a routing policy, the IGP can set the cost
according to the private attributes such as community carried in BGP routes.
l If BGP routes carry private attributes such as community, the system obtains the private
attributes and filters the BGP routes according to the routing policy. If the private attributes
match the routing policies, the BGP routes are permitted by the system and apply clauses
take effect.
l If BGP routes do not carry private attributes such as community, the BGP routes do not
match the routing policy and are denied by the system. In this case, apply clauses do not
take effect.
BGP to IGP Applications

As shown in Figure 9-1, the IS-IS relationship is set up between Router A and Router B that
are in the same AS. EBGP connections are established between Router B and Router C. Router
A is a non-BGP device in the AS. When IS-IS installs BGP routes and applies a routing policy,
IS-IS can change the cost according to the private attributes such as community in the matched
BGP routes.
Figure 9-1 Networking diagram of BGP to IGP
AS65008
AS65009


Terms
Terms Description
FRR Fast Reroute (FRR) is applicable to services that are very sensitive to packet loss
and delay. When a fault is detected at the lower layer, the lower layer informs the
upper routing system of the fault. Then the routing system forwards packets
through a backup link. In this manner, the impact of the link fault on services is
minimized.
PBR Policy Based Routing (PBR) refers to the IP packet forwarding process earlier than
the routing table searching. After PBR is enabled, routes are selected according to
the routing policy, with reference to the source IP addresses and the length of
packets.
PBR ensures network security and is applicable to load balancing.
Abbreviations
Abbreviatio Full Spelling
ns
IBGP Internal Border Gateway Protocol
EBGP External Border Gateway Protocol
ACL Access Control List
USR Unicast Static Route
RM Route Management

Feature Description - IP Routing 10 Appendix List of Port Numbers of Common Protocols
10 Appendix List of Port Numbers of

Common Protocols
Table 10-1 Port number of routing protocols
Routing Protocol UDP Port Number TCP Port Number
RIP 520 -
RIPv2 520 -
RIPng 521 -
BGP - 179
OSPF - -
IS-IS - -
Note that "-" indicates that the related transport layer protocol is not used.
Table 10-2 Port number of application layer protocols
Application Layer UDP Port Number TCP Port Number

Protocol
DHCP 67 -
DNS 53 53
FTP - 20/21
HTTP - 80
IMAP - 993
NetBIOS 137/138 137/139
POP3 - 110
SMB 445 445

Feature Description - IP Routing 10 Appendix List of Port Numbers of Common Protocols
Application Layer UDP Port Number TCP Port Number

Protocol
SMTP 25 25
SNMP 161 -
TELNET - 23
TFTP 69 -
Note that "-" indicates that the related transport layer protocol is not used.


Feature Description - IP Routing

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Feature Description - IP Routing

Transféré par

Droits d'auteur :

Formats disponibles

HUAWEI NetEngine80E/40E Router

Feature Description - IP Routing

HUAWEI TECHNOLOGIES CO., LTD.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Issue 02 (2011-09-10) Huawei Proprietary and Confidential i

About This Document

Product Name Version

HUAWEI NetEngine80E/40E V600R003C00

Issue 02 (2011-09-10) Huawei Proprietary and Confidential ii

Indicates a hazard with a high level of risk, which, if not

Indicates a hazard with a medium or low level of risk, which,

Indicates a potentially hazardous situation, which, if not

NOTE Provides additional information to emphasize or supplement

Changes in Issue 02 (2011-09-10)

Changes in Issue 01 (2011-06-30)

Issue 02 (2011-09-10) Huawei Proprietary and Confidential iii

About This Document.....................................................................................................................ii

Issue 02 (2011-09-10) Huawei Proprietary and Confidential iv

2.3.5 NQA for IPv4 Static Routes....................................................................................................................28

Issue 02 (2011-09-10) Huawei Proprietary and Confidential v

5.3.7 IS-IS Administrative Tag.........................................................................................................................74

Issue 02 (2011-09-10) Huawei Proprietary and Confidential vi

Issue 02 (2011-09-10) Huawei Proprietary and Confidential vii

9.3.2 Application Environment......................................................................................................................208

10 Appendix List of Port Numbers of Common Protocols...................................................214

Issue 02 (2011-09-10) Huawei Proprietary and Confidential viii

About This Chapter

1.1 Introduction to IP Routing

Issue 02 (2011-09-10) Huawei Proprietary and Confidential 1

1.1 Introduction to IP Routing

Issue 02 (2011-09-10) Huawei Proprietary and Confidential 2

Figure 1-1 Hop count and network segment

1.3.2 Routing Protocols

1.3.3 Routing Table and FIB Table

Issue 02 (2011-09-10) Huawei Proprietary and Confidential 3

l Protocol routing table

Contents of the Routing Table

Destination/Mask Proto Pre Cost Flags NextHop Interface

0.0.0.0/0 Static 60 0 D 1.1.4.2 Pos1/0/0

A routing table has the following key entries:

Issue 02 (2011-09-10) Huawei Proprietary and Confidential 4

Issue 02 (2011-09-10) Huawei Proprietary and Confidential 5

Figure 1-2 Routing table

Routing Table 11.0.0.0/8

Matching of FIB Table

Issue 02 (2011-09-10) Huawei Proprietary and Confidential 6

For example, the brief routing table of a router is as follows:

1.3.4 Static Routes and Dynamic Routes

1.3.5 Classification of Dynamic Routing Protocols

Issue 02 (2011-09-10) Huawei Proprietary and Confidential 7

Dynamic routing protocols can be classified based on the following conditions:

According to the Range of Functions

According to the Algorithm

According to the Types of Destination Addresses

l Unicast routing protocol: includes RIP, OSPF, BGP, and IS-IS.

1.3.6 Routing Protocols and Route Preferences

Issue 02 (2011-09-10) Huawei Proprietary and Confidential 8

Routing Protocol or Route Type Route Preference

OSPF ASE 150

OSPF NSSA 150

Table 1-2 Internal preferences of routing protocols

Routing Protocol or Route Type Route Preference

OSPF ASE 150