HUAWEI - OSPF Configuration

CloudEngine 8800&7800&6800&5800 Series Switches
Configuration Guide - IP Unicast Routing 5 OSPF Configuration
5 OSPF Configuration
5.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. Unless otherwise stated, OSPF stated in this
document refers to OSPF Version 2.
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 the following advantages:
l Receives or sends packets in multicast mode to reduce load on the Router that does 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.
5.2 Principle
5.2.1 Fundamentals of OSPF
Issue 06 (2017-09-12) Huawei Proprietary and Confidential 179

Copyright © Huawei Technologies Co., Ltd.
OSPF has the following functions:
l Divides an Autonomous System (AS) into one or multiple logical areas.

l Advertises routes by sending Link State Advertisements (LSAs).
l Exchanges OSPF packets between devices in an OSPF area to synchronize routing
information.
l Encapsulates OSPF packets into IP packets and sends the packets in unicast or multicast
mode.
Packet Type
Table 5-1 packet type
Packet Type Function
Hello packet Sent periodically to discover and maintain OSPF

neighbor relationships.
Database Description (DD) packet Contains brief information about the local link-state
database (LSDB) and synchronizes the LSDBs on
two devices.
Link State Request (LSR) packet Requests the required LSAs from neighbors.
LSR packets are sent only after DD packets are
exchanged successfully.
Link State Update (LSU) packet Sends the required LSAs to neighbors.
Link State Acknowledgement Acknowledges the receipt of an LSA.

(LSAck) packet
LSA Type
Table 5-2 LSA type
LSA Type Function
Router-LSA (Type 1) Describes the link status and link cost of a router. It is
generated by every router and advertised in the area to
which the router belongs.
Network-LSA (Type 2) Describes the link status of all routers on the local network
segment. Network-LSAs are generated by a designated
router (DR) and advertised in the area to which the DR
belongs.
Network-summary-LSA Describes routes to a specific network segment in an area.

(Type 3) Network-summary-LSAs are generated by an Area Border
Router (ABR) and advertised in all areas except totally stub
areas and Not-So-Stubby Areas (NSSAs).

LSA Type Function
ASBR-summary-LSA Describes routes to an Autonomous System Boundary

(Type 4) Router (ASBR). ASBR-summary-LSAs are generated by an
ABR and advertised to all related areas except the area to
which the ASBR belongs.
AS-external-LSA (Type 5) Describes routes to a destination outside the AS. AS-

external-LSAs are generated by an ASBR and advertised to
all areas except stub areas and NSSAs.
NSSA-LSA (Type7) Describes routes to a destination outside the AS. Generated

by an ASBR and advertised in NSSAs only.
Opaque-LSA (Type 9/Type Provides a universal mechanism for OSPF extension.

10/Type 11) l Type 9 LSAs are advertised only on the network segment
where the interface originating Type 9 LSAs resides.
Grace LSAs used to support GR are a type of Type 9
LSAs.
l Type 10 LSAs are advertised inside an OSPF area. LSAs
used to support TE are a type of Type 10 LSAs.
l Type 11 LSAs are advertised within an AS. At present,
there are no applications of Type 11 LSAs.
Router Type
Figure 5-1 lists common Router types used in OSPF.
Figure 5-1 Router type

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

Table 5-3 Router type

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

OSPF area.
Area Border Router (ABR) An ABR belongs to two or more than two areas, one of
which must be the 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.
Internal routers in Area 0 and all ABRs are backbone
routers.
ASBR (AS Boundary An ASBR exchanges routing information with other ASs.
Router) An ASBR does not necessarily reside on the border of an
AS. It can be an internal router or an ABR. An OSPF
device that has imported external routing information will
become an ASBR.
Route Type
Inter-area and intra-area routes in an AS describe the AS's network structure. AS external
routes describe the routes to destinations outside an AS. OSPF classifies the imported AS
external routes into Type 1 and Type 2 external routes.
Table 5-4 lists route types in descending priority order.
Table 5-4 route type

Route Type Description
Intra-area route Indicates routes within an area.
Inter-area route Indicates routes between areas.
Type 1 external route Type 1 external routes have high reliability.

Cost of a Type 1 external route = Cost of the route from a
local router to an ASBR + Cost of the route from the
ASBR to the destination of the Type 1 external route
Type 2 external route Type 2 external routes have low reliability, and therefore
OSPF considers that the cost of the route from an ASBR
to the destination of a Type 2 external route is much
greater than the cost of any internal route to the ASBR.
Cost of a Type 2 external route = Cost of the route from
the ASBR to the destination of the Type 2 external route

Area Type
Table 5-5 area type

Area Type Function
Common area OSPF areas are common areas by default. Common areas include
standard areas and backbone areas.
l A standard area is the most common area and transmits intra-
area routes, inter-area routes, and external routes.
l A backbone area connects all the other OSPF areas. It is usually
named Area 0.
Stub area A stub area does not advertise AS external routes, but only intra-
area and inter-area routes.
Compared with a non-stub area, the Router in a stub area maintains
fewer routing entries and transmits less routing information.
To ensure the reachability of AS external routes, the ABR in a stub
area advertises Type 3 default routes to the entire stub area. All AS
external routes must be advertised by the ABR.
Totally stub area A totally stub area does not advertise AS external routes or inter-
area routes, but only intra-area routes.
Compared with a non-stub area, the Router in a totally stub area
maintains fewer routing entries and transmits less routing
information.
To ensure the reachability of AS external and inter-area routes, the
ABR in a totally stub area advertises Type 3 default routes to the
entire totally stub area. All AS external and inter-area routes must
be advertised by the ABR.
NSSA An NSSA can import AS external routes. An ASBR uses Type 7

LSAs to advertise the imported AS external routes to the entire
NSSA. These Type 7 LSAs are translated into Type 5 LSAs on an
ABR, and are then flooded in the entire OSPF AS.
An NSSA has the characteristics of the stub areas in an AS.
An ABR in an NSSA advertises Type 7 default routes to the entire
NSSA. All inter-area routes must be advertised by the ABR.
Totally NSSA A totally NSSA can import AS external routes. An ASBR uses
Type 7 LSAs to advertise the imported AS external routes to the
entire NSSA. These Type 7 LSAs are translated into Type 5 LSAs
on an ABR, and are then flooded in the entire OSPF AS.
A totally NSSA has the characteristics of the totally stub areas in an
AS.
An ABR in a totally NSSA advertises Type 3 and Type 7 default
routes to the entire totally NSSA. All inter-area routes must be
advertised by the ABR.

OSPF Network Type

Table 5-6 lists four OSPF network types that are classified based on link layer protocols.
Table 5-6 OSPF network type
Network Type Description
Broadcast A network with the link layer protocol of Ethernet or Fiber

Distributed Data Interface (FDDI) is a broadcast network by
default.
On a broadcast network:
l Hello packets, LSU packets, and LSAck packets are usually
transmitted in multicast mode. 224.0.0.5 is an IP multicast
address reserved for an OSPF device. 224.0.0.6 is an IP
multicast address reserved for an OSPF DR or backup
designated router (BDR).
l DD and LSR packets are transmitted in unicast mode.
Non-Broadcast Multi- A network with the link layer protocol of frame relay (FR), X.25
Access (NBMA) is an NBMA network by default.
On an NBMA network, protocol packets such as Hello packets,
DD packets, LSR packets, LSU packets, and LSAck packets are
sent in unicast mode.
Point-to-Multipoint No network is a P2MP network by default, no matter what type

(P2MP) of link layer protocol is used on the network. A network can be
changed to a P2MP network. The common practice is to change
a non-fully meshed NBMA network to a P2MP network.
On a P2MP network:
l Hello packets are transmitted in multicast mode using the
multicast address 224.0.0.5.
l Other types of protocol packets, such as DD packets, LSR
packets, LSU packets, and LSAck packets are sent in unicast
mode.
Point-to-point (P2P) By default, a network where the link layer protocol is PPP,
HDLC, or LAPB is a P2P network.
On a P2P network, protocol packets such as Hello packets, DD
packets, LSR packets, LSU packets, and LSAck packets are sent
in multicast mode using the multicast address 224.0.0.5.
Stub Area
Stub areas are specific areas where ABRs do not flood the received AS external routes. In
stub areas, Routers maintain fewer routing entries and less routing information.
Configuring a stub area is optional. Not every area can be configured as a stub area. A stub
area is usually a non-backbone area with only one ABR and is located at the AS border.

To ensure the reachability of the routes to destinations outside an AS, the ABR in the stub
area generates a default route and advertises the route to the non-ABRs in the same stub area.
Note the following points when configuring a stub area:
l The backbone area cannot be configured as a stub area.

l Before configuring an area as a stub area, you must configure stub area attributes on all
Routers in the area.
l There should be no ASBR in a stub area, meaning that AS external routes cannot be
transmitted in the stub area.
l Virtual connections cannot cross a stub area.
NSSA
NSSAs are a special type of OSPF areas. There are many similarities between an NSSA and a
stub area. Both of them do not advertise the external routes received from the other OSPF
areas. The difference is that a stub area cannot import AS external routes, whereas an NSSA
can import AS external routes and advertise the imported routes to the entire AS.
After an area is configured as an NSSA, an ABR in the NSSA generates a default route and
advertises the route to the other Routers in the NSSA. This is to ensure the reachability of the
routes to the destinations outside an AS.
Note the following points when configuring an NSSA:
l The backbone area cannot be configured as an NSSA.

l Before configuring an area as an NSSA, you must configure NSSA attributes on all
Routers in the area.
l Virtual connections cannot cross an NSSA.
Neighbor State Machine

To exchange routing information on an OSPF network, neighbor routers must establish
adjacencies. The differences between neighbor relationships and adjacencies are described as
follows:
l Neighbor relationship: After the local router starts, it uses an OSPF interface to send a
Hello packet to the remote router. After the remote router receives the packet, it checks
whether the parameters carried in the packet are consistent with its own parameters. If
the parameters carried in the packet are consistent with its own parameters, the local and
remote routers establish a neighbor relationship.
l Adjacency: After the local and remote routers establish a neighbor relationship, they
exchange DD packets and LSAs to establish an adjacency.
OSPF has eight state machines: Down, Attempt, Init, 2-way, Exstart, Exchange, Loading, and
Full.
l Down: It is in the initial stage of setting up sessions between neighbors. The state
machine is Down when a router fails to receive Hello packets from its neighbor before
the dead interval expires.
l Attempt: It occurs only on an NBMA network. The state machine is Attempt when a
neighbor does not reply with Hello packets after the dead interval has expired. The local
router, however, keeps sending Hello packets to the neighbor at every poll interval.

l Init: The state machine is Init after a router receives Hello packets.
l 2-way: The state machine is 2-way when the Hello packets received by a router contain
its own router ID. The state machine will remain in the 2-way state if no neighbor
relationship is established, and will become Exstart if a neighbor relationship is
established.
l Exstart: The state machine is Exstart when the two neighbors start to negotiate the
master/slave status and determine the sequence numbers of DD packets.
l Exchange: The state machine is Exchange when a router starts to exchange DD packets
with its neighbor after the master/slave status negotiation is completed.
l Loading: The state machine is Loading after a router has finished exchanging DD
packets with its neighbor.
l Full: The state machine is Full when the LSA retransmission list is empty.
OSPF Packet Authentication

OSPF supports packet authentication. Only the OSPF packets that have been authenticated
can be received. If OSPF packets are not authenticated, a neighbor relationship cannot be
established.
The Router supports two authentication methods:
l Area-based authentication
l Interface-based authentication
When both area-based and interface-based authentication methods are configured, interface-
based authentication takes effect.
OSPF Route Summarization

Route summarization means that an ABR in an area summarizes the routes with the same
prefix into one route and advertises the summarized route to the other areas.
Route summarization between areas reduces the amount of routing information to be

transmitted, reducing the size of routing tables and improving device performance.
Route summarization can be carried out by an ABR or an ASBR:
l Route summarization on an ABR:

When an ABR in an area advertises routing information to other areas, it generates Type
3 LSAs by network segment. If this area contains consecutive network segments, you
can run a command to summarize these network segments into one network segment.
The ABR only needs to send one summarized LSA, and will not send the LSAs that
belong to the summarized network segment specified in the command.
l Route summarization on an ASBR:
If the local device is an ASBR and route summarization is configured, the ASBR will
summarize the imported Type 5 LSAs within the aggregated address range. After an
NSSA is configured, the ASBR needs to summarize the imported Type 7 LSAs within
the aggregated address range.
If the local device is an ASBR and ABR, the device will summarize the Type 5 LSAs
that are translated from Type 7 LSAs.

OSPF Default Route

A default route is a route of which the destination address and mask are all 0s. If a router
cannot find a route in its routing table for forwarding packets, it can forward packets using a
default route. Due to hierarchical management of OSPF routes, the priority of default Type 3
routes is higher than the priority of default Type 5 or Type 7 routes.
OSPF default routes are usually used in the following cases:
l An ABR advertises default Type 3 Summary LSAs to instruct routers within an area to
forward packets between areas.
l An ASBR advertises default Type 5 ASE LSAs or default Type 7 NSSA LSAs to instruct
routers in an AS to forward packets to other ASs.
Principles for advertising OSPF default routes are described below:

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 advertised an LSA carrying information about a type of default
route, the OSPF router does not learn this type of default routes advertised by other
routers. This means that the OSPF router no longer calculates routes based on the LSAs
carrying information about the same type of the default routes advertised by other
routers, but stores these LSAs in its LSDB.
l The route on which default external route advertisement depends cannot be a route in the
local OSPF AS. This means that the route cannot be the one learned by the local OSPF
process. This is because default external routes are used to guide packet forwarding
outside an AS, whereas the routes within an AS have the next hop pointing to the devices
within the AS.
Table 5-7 lists principles for advertising default routes in different areas.
Table 5-7 Principles for advertising OSPF default routes
Area Type Function
Common area By default, devices in a common OSPF area do not automatically

generate default routes, even if the common OSPF area has default
routes.
When a default route on the network is generated by another
routing process (not OSPF process), the device that generates the
default route must advertise the default route in the entire OSPF
AS. (Run a command on an ASBR to configure the ASBR to
generate a default route. After the configuration, the ASBR
generates a default Type 5 ASE LSA and advertises the LSA to the
entire OSPF AS.)
STUB area A stub area does not allow AS external routes (Type 5 LSAs) to be
transmitted within the area.
All routers within the stub area must learn AS external routes from
the ABR. The ABR automatically generates a default Summary
LSA (Type 3 LSA) and advertises it to the entire stub area. Then all
routes to destinations outside an AS can be learned from the ABR.

Area Type Function
Totally STUB area A totally stub area does not allow AS external routes (Type 5
LSAs) or inter-area routes (Type 3 LSAs) to be transmitted within
the area.
All routers within the totally stub area must learn AS external
routes and other areas' routes from the ABR. The ABR
automatically generates a default Summary LSA (Type 3 LSA) and
advertises it to the entire totally stub area. Then, all routes to
destinations outside an AS and to destinations in other areas can be
learned from the ABR.
NSSA An NSSA allows its ASBRs to import a small number of AS

external routes, but does not advertise ASE LSAs (Type 5 LSAs)
received from other areas within the NSSA. This means that AS
external routes can be learned only from ASBRs in the NSSA.
Devices in an NSSA do not automatically generate default routes.
Use either of the following methods as required:
l To advertise some external routes using the ASBR in the NSSA
and advertise other external routes through other areas,
configure a default Type 7 LSA on the ABR and advertise this
LSA in the entire NSSA.
l To advertise all the external routes using the ASBR in the
NSSA, configure a default Type 7 LSA on the ASBR and
advertise this LSA in the entire NSSA.
The difference between these two configurations is described
below:
l An ABR will generate a default Type 7 LSA regardless of
whether the routing table contains the default route 0.0.0.0.
l An ASBR will generate a default Type 7 LSA only when the
routing table contains the default route 0.0.0.0.
A default route is flooded only in the local NSSA and is not
flooded in the entire OSPF AS. If Routers in the local NSSA cannot
find routes to the outside of the AS, the Routers can forward
packets to the outside of the AS through an ASBR. Packets of other
OSPF areas, however, cannot be sent to the outside of the AS
through this ASBR. Default Type 7 LSAs will not be translated into
default Type 5 LSAs and flooded in the entire OSPF AS.
Totally NSSA A totally NSSA does not allow AS external routes (Type 5 LSAs)
or inter-area routes (Type 3 LSAs) to be transmitted within the area.
All Routers within the totally NSSA must learn AS external routes
from the ABR. The ABR automatically generates a default
Summary LSAs and advertises it to the entire totally NSSA. Then
all external routes received from other areas and inter-area routes
can be advertised within the totally NSSA.

OSPF Route Filtering

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

You can run a command to configure an ABR to filter the outgoing Summary LSAs.
This configuration takes effect only on ABRs.
OSPF Multi-Process
OSPF supports multi-process. Multiple OSPF processes can run on the same Router, and they
are independent of each other. Route exchanges between different OSPF processes are similar
to route exchanges between different routing protocols.
Each interface on the Router belongs to only one OSPF process.
A typical application of OSPF multi-process is that OSPF runs between PEs and CEs in a
VPN, whereas OSPF is used as an IGP on the backbone of the VPN. Two OSPF processes on
the same PE are independent of each other.

OSPF RFC 1583 Compatibility

RFC 1583 is an earlier version of OSPFv2.
When OSPF calculates external routes, routing loops may occur because RFC 2328 and RFC
1583 define different route selection rules. To prevent routing loops, both communication
ends must use the same route selection rules.
l After RFC 1583 compatibility is enabled, OSPF use the route selection rules defined in
RFC 1583.
l When RFC 1583 compatibility is disabled, OSPF uses the route selection rules defined
in RFC 2328.
OSPF calculates external routes based on Type 5 LSAs. If the Router enabled with RFC 1583
compatibility receives a Type 5 LSA:
l The Router selects a route to the ASBR that originates the LSA, or to the forwarding
address (FA) described in the LSA.
l The Router selects external routes to the same destination.
By default, OSPF uses the route selection rules defined in RFC 1583.
5.2.2 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 a path between two systems.
The path can be a physical link, a logical link, or a tunnel.
In BFD for OSPF, a BFD session is associated with OSPF. The BFD session quickly detects a
link fault and then notifies OSPF of the fault. This speeds up OSPF's response to the change
of the network topology.
Purpose
The link fault or the topology change may cause devices to re-calculate routes. Therefore, the
convergence of routing protocols must be as quick as possible to improve the network
performance.
Link faults are unavoidable. Therefore, a feasible solution is required to detect faults faster
and notify the faults to routing protocols immediately. If BFD is associated with OSPF, once a
fault occurs on a link between neighbors, BFD can speed up the OSPF convergence.
Table 5-9 Comparison before and after BFD for OSPF is enabled
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 Link Fault Detection Mechanism Convergence

with BFD or Speed
Not
Associated with A BFD session goes Down. At the millisecond

BFD level
Principle
Figure 5-2 BFD for OSPF
RouterA RouterB GE3/0/0

172.16.1.1/24
GE2/0/0 GE2/0/0
10.3.3.1/24 10.3.3.2/24 GE1/0/0
GE1/0/0 10.2.2.2/24
10.1.1.1/24
GE1/0/0 GE2/0/0
10.1.1.2/24 10.2.2.1/24
Area0
RouterC
The principle of BFD for OSPF is shown in Figure 5-2.
1. OSPF neighbor relationships are established between these three routers.

2. After a neighbor relationship becomes Full, this triggers BFD to establish a BFD session.
3. The outbound interface on RouterA connected to RouterB is GE 2/0/0. If the link fails,
BFD detects the fault and then notifies RouterA of the fault.
4. RouterA processes the event that a neighbor relationship becomes Down and re-
calculates routes. After calculation, the outbound interface is GE1 /0/0 passes through
RouterC and then reaches RouterB.
5.2.3 OSPF Smart-discover
Definition
Generally, Routers periodically send Hello packets through OSPF interfaces. That is, a Router
sends Hello packets at the Hello interval set by a Dead timer. Because Hello packets are sent
at a fixed interval, the speed at which OSPF neighbor relationship is established is lowered.
Enabling Smart-discover can speed up the establishment of OSPF neighbor relationships in

specific scenarios.

Table 5-10 OSPF Smart-discover

Smart-discover Configured or Processing
Not
Smart-discover is not configured l Hello packets are sent only when the Hello timer
expires.
l The gap between the sending of two Hello packets
is the Hello interval.
l Neighbors keep waiting to receive Hello packets
within the Hello interval.
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 immediately.
Principle
In the following scenarios, the interface enabled with Smart-discover can send Hello packets
to neighbors without having to wait for the Hello timer to expire:
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.
5.2.4 OSPF VPN
Definition
As an extension of OSPF, OSPF VPN multi-instance enables Provider Edges (PEs) and
Customer Edges (CEs) in VPNs to run OSPF for interworking and use OSPF to learn and
advertise routes.
Purpose
As a widely used IGP, in most cases, OSPF runs in VPNs. If OSPF runs between PEs and
CEs, and PEs advertise VPN routes to CEs using OSPF, CEs do not need to support other
routing protocols for interworking with PEs. This simplifies management and configuration of
CEs.
Running OSPF Between PEs and CEs

In BGP/MPLS VPN, routing information is transmitted between PEs using Multi-Protocol
BGP (MP-BGP), whereas routes are learned and advertised between PEs and CEs using
OSPF.
Running OSPF between PEs and CEs has the following benefits:
l OSPF is used in a site to learn routes. Running OSPF between PEs and CEs can reduce
the protocol types that CEs must support, reducing the requirements for CEs.

l Similarly, running OSPF both in a site and between PEs and CEs simplifies the workload
of network administrators. In this manner, network administrators do not have to be
familiar with multiple protocols.
l When a network using OSPF but not VPN on the backbone network begins to use BGP/
MPLS VPN, running OSPF between PEs and CEs facilitates the transition.
As shown in Figure 5-3, 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 5-3 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 VPN1 Site4
VPN2
The process of advertising routes of CE1 to CE3 and CE4 is as follows:
1. PE1 imports OSPF routes of CE1 into BGP and forms BGP VPNv4 routes.
2. PE1 advertises BGP VPNv4 routes to PE2 using MP-BGP.
3. PE2 imports BGP VPNv4 routes into OSPF, and then advertises these routes to CE3 and
CE4.
The process of advertising routes of CE4 or CE3 to CE1 is the same as the preceding process.
Configuring OSPF Areas Between PEs and CEs

OSPF areas between PEs and CEs can be either non-backbone areas or backbone areas (Area
0). A PE can only be an area border router (ABR).
In the extended application of OSPF VPN, the MPLS VPN backbone network serves as Area
0. OSPF requires that Area 0 be contiguous. Therefore, Area 0 of all VPN sites must be
connected to the MPLS VPN backbone network. If a VPN site has OSPF Area 0, the PEs that
CEs access must be connected to the backbone area of this VPN site through Area 0. If no
physical link is available to directly connect PEs to the backbone area, a virtual link can be
used to implement logical connection between the PEs and the backbone area, as shown in
Figure 5-4.

Figure 5-4 Configuring OSPF areas between PEs and CEs
VPN
PE1 backbone PE2
Area0 Area0
Area1
Virtual link
CE1 CE2 Area0

Site1 Site2
Area0
A non-backbone area (Area 1) is configured between PE1 and CE1, and a backbone area
(Area 0) is configured in Site 1. As a result, the backbone area in Site 1 is separated from the
VPN backbone area. Therefore, a virtual link is configured between PE1 and CE1 to ensure
that the backbone area is contiguous.
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 more domain IDs, one of which is a primary ID with the
others being secondary IDs.
l If an OSPF instance does not have a specific domain ID, its ID is considered as null.
Before advertising the remote routes sent by BGP to CEs, PEs need to determine the type of
OSPF routes (Type 3, Type 5 or Type 7) to be advertised to CEs according to domain IDs.
l If local domain IDs are the same as or compatible with remote domain IDs in BGP
routes, PEs advertise Type 3 routes.
l Otherwise, PEs advertise Type 5 or Type 7 routes.
Table 5-11 Domain ID
Comparison Between Local and Local and Route Type

Remote Domain IDs Remote
Domain
IDs the
Same Or
Not
Both the local and remote domain IDs are The same Inter-area route
null.
The remote domain ID is the same as the The same Inter-area route
local primary domain ID or one of the local
secondary domain IDs.

Comparison Between Local and Local and Route Type

Remote Domain IDs Remote
Domain
IDs the
Same Or
Not
The remote domain ID is different from the Not the If the local area is a non-
local primary domain ID or any of the local same NSSA, external routes are
secondary domain IDs. generated.
If the local area is an NSSA,
NSSA routes are generated.
Routing Loop Prevention

Between PEs and CEs, routing loops may occur when OSPF and BGP learn routes from each
other.
Figure 5-5 OSPF VPN routing loops
PE1
VPN
backbone
vpn1 site1 10.1.1.1/32
CE1
PE2
As shown in Figure 5-5, on PE1, OSPF imports a BGP route whose destination address is
10.1.1.1/32, and then generates and advertises a Type 5 or Type 7 LSA to CE1. Then, CE1
learns an OSPF route with the destination address and next hop being 10.1.1.1/32 and PE1
respectively, and advertises the route to PE2. In this manner, PE2 learns an OSPF route with
the destination address and next hop being 10.1.1.1/32 and CE1 respectively.
Similarly, CE1 also learns an OSPF route with the destination address and next hop being
10.1.1.1/32 and PE2 respectively. PE1 learns an OSPF route with the destination address and
next hop being 10.1.1.1/32 and CE1 respectively.
As a result, CE1 has two equal-cost routes with next hops being PE1 and PE2 respectively,
and the next hops of the routes from PE1 and PE2 to 10.1.1.1/32 are CE1. Thus, a routing
loop occurs.
In addition, the preference of an OSPF route is higher than that of a BGP route. Therefore, on
PE1 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 again. This cycle
causes route flapping.
OSPF VPN provides a solution to this problem, as shown in Table 5-12.
Table 5-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 generated Type 3, Type 5, or
a flag bit, which is called the DN-bit. Type 7 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 Type When a PE detects that the
5 or Type 7 LSAs generated by PEs VPN route tag in the
according to the received BGP private incoming LSA is the same
route. as that in the local LSA, the
Not transmitted in BGP extended PE ignores this LSA.
community attributes, the VPN route Consequently, routing loops
tag is valid only on the PEs that are avoided.
receive 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 routes.
route. Default routes are used to
forward the traffic from CEs
or the sites where CEs
reside to the VPN backbone
network.

Disabling Routing Loop Prevention
NOTICE
Disabling routing loop prevention may cause routing loops. Exercise caution when
performing this operation.
During BGP or OSPF route exchanges, routing loop prevention prevents OSPF routing loops
in VPN sites.
In the inter-AS VPN Option A scenario, if OSPF is running between ASBRs to transmit VPN
routes, the remote ASBR may be unable to learn the OSPF routes sent by the local ASBR due
to the routing loop prevention mechanism.
As shown in Figure 5-6, inter-AS VPN Option A is deployed. OSPF is running between PE1
and CE1. CE1 sends VPN routes to CE2.
Figure 5-6 Networking diagram for inter-AS VPN Option A
VPN1
CE1 VPN1
BGP/MPLS CE3
BGP/MPLS
backbone backbone
PE1 AS: 100 AS: 200
PE3
ASBR1 ASBR2
MP-IBGP MP-IBGP
OSPF
PE2
PE4
CE4
CE2
VPN2 VPN2
1. PE1 learns routes to CE1 using the OSPF process in a VPN instance, and imports these
routes into MP-BGP, and sends the MP-BGP routes to ASBR1.
2. After having received the MP-BGP routes, ASBR1 imports the routes into the OSPF
process in a VPN instance and generates Type 3, Type 5, or Type 7 LSAs in which the
DN bit is set to 1.
3. ASBR2 learns these LSAs using OSPF and checks the DN bit of each LSA. After
learning that the DN bit in each LSA is set to 1, ASBR2 does not add the routing
information carried in these LSAs to its routing table.
Due to the routing loop prevention mechanism, ASBR2 cannot learn the OSPF routes sent
from ASBR1, causing CE1 to be unable to communicate with CE3.
To address the preceding problem, use either of the following methods:

l A device does not set the DN bit to 1 in the LSAs when importing BGP routes into
OSPF. For example, ASBR1 does not set the DN bit to 1 when importing MP-BGP
routes into OSPF. After ASBR2 receives these routes and checks that the DN bit in the
LSAs carrying these routes is 0, ASBR2 adds the routes to its routing table.
l A device does not check the DN bit after having received LSAs. For example, ASBR1
sets the DN bit to 1 in LSAs when importing MP-BGP routes into OSPF. ASBR2,
however, does not check the DN bit after having received these LSAs.
The preceding methods can be used more flexibly based on specific types of LSAs. For Type
3 LSAs, you can configure a sender to determine whether to set the DN bit to 1 or configure a
receiver to determine whether to check the DN bit in the Type 3 LSAs based on the router ID
of the device that generates the Type 3 LSAs.
In the inter-AS VPN Option A scenario shown in Figure 5-7, the four ASBRs are fully
meshed and run OSPF. ASBR2 may receive the Type 3, Type 5, or Type 7 LSAs generated on
ASBR4. If ASBR2 is not configured to check the DN bit in the LSAs, ASBR2 will accept the
Type 3 LSAs, and routing loops will occur, as described in Figure 5-7. ASBR2 will deny the
Type 5 or Type 7 LSAs, because the VPN route tags carried in the LSAs are the same as the
default VPN route tag of the OSPF process on ASBR2.
To address the routing loop problem caused by Type 3 LSAs, configure ASBR2 not to check
the DN bit in the Type 3 LSAs that are generated by devices with the router ID 10.1.1.1 and
the router ID 10.3.3.3. After the configuration is complete, if ASBR2 receives Type 3 LSAs
sent by ASBR4 with the router ID 10.4.4.4, ASBR2 will check the DN bit and deny these
Type 3 LSAs because the DN bit is set to 1.
Figure 5-7 Networking diagram for full-mesh ASBRs in the inter-AS VPN Option A scenario
OSPF Router ID OSPF Router ID
10.1.1.1 10.2.2.2
ASBR1 ASBR2
OSPF
AS: 100 AS: 200
ASBR3 ASBR4
OSPF Router ID OSPF Router ID
10.3.3.3 10.4.4.4
Multi-VPN-Instance CE
OSPF multi-instance generally runs on PEs. The devices that run OSPF multi-instance within
the LANs of users are called Multi-VPN-Instance CEs (MCEs), that is, multi-instance CEs.
Compared with OSPF multi-instance running on PEs, MCEs have the following
characteristics:
l MCEs do not need to support OSPF-BGP synchronization.
l MCEs establish different OSPF instances for different services. Different virtual CEs
transmit different services. This solves the security issue of the LAN at a low cost.

l MCEs implement different OSPF multi-instances on a CE. The key to implementing

MCEs is to disable loop detection and calculate routes directly. MCEs also need to use
the received LSAs with the ND-bit for route calculation.
5.2.5 OSPF NSSA
Definition
As defined in OSPF, stub areas cannot import external routes. This prevents a large number of
external routes from consuming bandwidth and storage resources of the Routers in stub areas.
To import external routes and to prevent external routes from consuming resources, NSSAs
are used, because stub areas cannot meet requirements.
NSSAs are a new type of OSPF areas.
There are many similarities between NSSAs and stub areas. The difference between NSSAs
and stub areas is that NSSAs can import AS external routes into the entire OSPF AS and
advertise the imported routes in the OSPF AS, but do not learn external routes from other
areas on the OSPF network.
Figure 5-8 NSSA

RIP RIP
Type5 Type5 NSSA Area
Type5 Type5 Type7

ASBR Area2 Area0 Area1 ASBR
ABR ABR
N-bit
All Routers in an area must be configured with the same area type. In OSPF, the N-bit is
carried in a Hello packet and is used to identify the area type supported by the Router. OSPF
neighbor relationships cannot be established between Routers configured with different area
types.
Some manufacturers do not comply with the standard and set the N-bit in both OSPF Hello
and DD packets. To allow Huawei devices to interwork with these manufacturers' devices, set
the N-bit in OSPF DD packets on Huawei devices.
Type 7 LSA
l Type 7 LSAs are a new type of LSAs that can only be used in NSSAs and describe the
imported external routes.
l Type 7 LSAs are generated by ASBRs in an NSSA and flooded only in the NSSA where
the ASBRs reside.
l When the ABRs in the NSSA receive these Type 7 LSAs, they translate some of the
Type 7 LSAs into Type 5 LSAs to advertise AS external routes to the other areas on the
OSPF network.

Translating Type 7 LSAs Into Type 5 LSAs

To advertise the external routes imported by an NSSA to other areas, Type 7 LSAs need to be
translated into Type 5 LSAs so that the external routes can be advertised on the entire OSPF
network.
l The Propagate bit (P-bit) in a Type 7 LSA is used to instruct the Router whether to
translate Type 7 LSAs into Type 5 LSAs.
l By default, the ABR with the largest router ID in an NSSA is responsible for translating
Type 7 LSAs into Type 5 LSAs.
l Only the Type 7 LSAs in which the P-bit is set to 1 and the FA is not 0 can be translated
into Type 5 LSAs. The FA indicates that the packet to a specific destination address will
be forwarded to the address specified by the FA.
l The P-bit in the Type 7 LSAs generated by ABRs is not set to 1.
Preventing Loops Caused by Default Routes

There may be multiple ABRs in an NSSA. To prevent routing loops, these ABRs not to
calculate default routes advertised by each other.
5.2.6 OSPF Fast Convergence

OSPF fast convergence is an extended feature of OSPF to speed up route convergence. The
characteristics of OSPF fast convergence are as follows:
l 5.2.8 Priority-based OSPF Convergence
l When certain routes on the network change, only the changed routes are recalculated.
This is called Partial Route Calculation (PRC).
l An intelligent timer is used to implement LSA management (the generating and
receiving of LSAs). With the intelligent timer, infrequent changes are responded to
quickly, whereas frequent changes are suppressed as desired.
To avoid excessive consumption of device resources by network connections or due to
frequent route flapping, RFC 2328 maintains that:
– After an LSA is generated, it cannot be generated again in five seconds. That is, the
interval for updating LSAs is one second.
– The interval for receiving LSAs is one second.
On a stable network where routes need to be fast converged, you can use the intelligent
timer to set the interval for receiving LSAs to 0 seconds. This ensures that topology or
route changes can be advertised to the network or be immediately sensed, thus speeding
up route convergence on the network.
l Route calculation is controlled through the intelligent timer.
When the network topology changes, devices need to recalculate routes according to
OSPF. This means that frequent changes in the network topology affect the performance
of devices. To address issue, RFC 2328 requires the use of a delay timer in route
calculation so that route calculation is performed only after the specified delay. But the
delay suggested by RFC is a fixed value, and cannot ensure both fast response to
topology changes and effective suppression of flapping.
By means of the intelligent timer, the delay in route calculation can be flexibly set as
desired. As a result, infrequent changes are responded to quickly, whereas frequent
changes are suppressed as desired.

l 5.2.3 OSPF Smart-discover
5.2.7 OSPF Neighbor Relationship Flapping Suppression

OSPF neighbor relationship flapping suppression works by delaying OSPF neighbor
relationship reestablishment or setting the link cost to the maximum value (65535).
Background
If the status of an interface carrying OSPF services alternates between Up and Down, OSPF
neighbor relationship flapping occurs on the interface. During the flapping, OSPF frequently
sends Hello packets to reestablish the neighbor relationship, synchronizes LSDBs, and
recalculates routes. In this process, a large number of packets are exchanged, adversely
affecting neighbor relationship stability, OSPF services, and other OSPF-dependent services,
such as LDP and BGP. OSPF neighbor relationship flapping suppression can address this
problem by delaying OSPF neighbor relationship reestablishment or preventing service traffic
from passing through flapping links.
Related Concepts
Flapping_event: reported when the status of a neighbor relationship on an interface last
changes from Full to ExStart or Down. The flapping_event triggers flapping detection.
Flapping_count: number of times flapping has occurred.
Detect-interval: interval at which flapping is detected. The interval is used to determine

whether to trigger a valid flapping_event.
Threshold: flapping suppression threshold. When the flapping_count exceeds the threshold,
flapping suppression takes effect.
Resume-interval: interval used to determine whether flapping suppression exits. If the

interval between two valid flapping_events is longer than the resume-interval, flapping
suppression exits.
Implementation
Flapping detection
OSPF interfaces start a flapping counter. If the interval between two flapping_events is
shorter than the detect-interval, a valid flapping_event is recorded, and the flapping_count
increases by 1. When the flapping_count exceeds the threshold, the system determines that
flapping occurs, and therefore triggers flapping suppression, and sets the flapping_count to 0.
If the interval between two valid flapping_events is longer than the resume-interval before
the flapping_count reaches the threshold again, the system sets the flapping_count to 0 again.
Interfaces start the suppression timer when the status of a neighbor relationship last changes
to ExStart or Down.
The detect-interval, threshold, and resume-interval are configurable.
NOTE
The value of resume-interval must be greater than that of detecting-interval.
Flapping suppression
Flapping suppression works in either Hold-down or Hold-max-cost mode.

l Hold-down mode: In the case of frequent flooding and topology changes during neighbor
relationship establishment, interfaces prevent neighbor relationships from being
reestablished during the suppression period, which minimizes LSDB synchronization
attempts and packet exchanges.
l Hold-max-cost mode: If the traffic forwarding path changes frequently, interfaces use
65535 as the cost of the flapping link during the suppression period, which prevents
traffic from passing through the flapping link.
Flapping suppression can also work first in Hold-down mode and then in Hold-max-cost
mode.
By default, the Hold-max-cost mode takes effect. The mode and suppression period can be
changed manually.
NOTE
When an interface enters the flapping suppression state, all neighbor relationships on the interface enter
the state accordingly.
Exiting from flapping suppression
Interfaces exit from flapping suppression in the following scenarios:
l The suppression timer expires.
l The corresponding OSPF process is reset.
l A command is run to exit from flapping suppression.
Typical Scenarios
Basic scenario
In Figure 5-9, the traffic forwarding path is Router A -> Router B -> Router C -> Router E
before a link failure occurs. After the link between Router B and Router C fails, the
forwarding path switches to Router A -> Router B -> Router D -> Router E. If the neighbor
relationship between Router B and Router C frequently flaps at the early stage of the path
switchover, the forwarding path will be switched frequently, causing traffic loss and affecting
network stability. If the neighbor relationship flapping meets suppression conditions, flapping
suppression takes effect.
l If flapping suppression works in Hold-down mode, the neighbor relationship between
Router B and Router C is prevented from being reestablished during the suppression
period, in which traffic is forwarded along the path Router A -> Router B -> Router D ->
Router E.
l If flapping suppression works in Hold-max-cost mode, 65535 is used as the cost of the
link between Router B and Router C during the suppression period, and traffic is
forwarded along the path Router A -> Router B -> Router D -> Router E.

Figure 5-9 Flapping suppression in a basic scenario
Router C
cost=10 cost=10
Router A Router B Router E

cost=100 cost=100
Router D
Single-forwarding path scenario

When only one forwarding path exists on the network, the flapping of the neighbor
relationship between any two devices on the path will interrupt traffic forwarding. In Figure
5-10, the traffic forwarding path is Router A -> Router B -> Router C -> Router E. If the
neighbor relationship between Router B and Router C flaps, and the flapping meets
suppression conditions, flapping suppression takes effect. However, if the neighbor
relationship between Router B and Router C is prevented from being reestablished, the whole
network will be divided. Therefore, Hold-max-cost mode (rather than Hold-down mode) is
recommended. If flapping suppression works in Hold-max-cost mode, 65535 is used as the
cost of the link between Router B and Router C during the suppression period. After the
network stabilizes and the suppression timer expires, the link is restored.
NOTE
By default, the Hold-max-cost mode takes effect.
Figure 5-10 Flapping suppression in a single-forwarding path scenario
Router A Router E
cost=65535
Router B Router C
Broadcast scenario
In Figure 5-11, four devices are deployed on the same broadcast network using switches, and
the devices are broadcast network neighbors. If Router C flaps due to a link failure, and
Router A and Router B were deployed at different time (Router A was deployed earlier for
example) or the flapping suppression parameters on Router A and Router B are different,

Router A first detects the flapping and suppresses Router C. Consequently, the Hello packets
sent by Router A do not carry Router C's router ID. However, Router B has not detected the
flapping yet and still considers Router C a valid node. As a result, the DR candidates
identified by Router A are Router B and Router D, whereas the DR candidates identified by
Router B are Router A, Router C, and Router D. Different DR candidates result in a different
DR election result, which may lead to route calculation errors. To prevent this problem in
scenarios where an interface has multiple neighbors, such as on a broadcast, P2MP, or NBMA
network, all neighbors on the interface are suppressed when the status of a neighbor
relationship last changes to ExStart or Down. Specifically, if Router C flaps, Router A,
Router B, and Router D on the broadcast network are all suppressed. After the network
stabilizes and the suppression timer expires, Router A, Router B, and Router D are restored to
normal status.
Figure 5-11 Flapping suppression on a broadcast network
Router A Router B
Router C Router D
Multi-area scenario
In Figure 5-12, Router A, Router B, Router C, Router E, and Router F are connected in area
1, and Router B, Router D, and Router E are connected in backbone area 0. Traffic from
Router A to Router F is preferentially forwarded along an intra-area route, and the forwarding
path is Router A -> Router B -> Router C -> Router E -> Router F. When the neighbor
relationship between Router B and Router C flaps and the flapping meets suppression
conditions, flapping suppression takes effect in the default mode (Hold-max-cost).
Consequently, 65535 is used as the cost of the link between Router B and Router C. However,
the forwarding path remains unchanged because intra-area routes take precedence over inter-
area routes during route selection according to OSPF route selection rules. To prevent traffic
loss in multi-area scenarios, configure Hold-down mode to prevent the neighbor relationship
between Router B and Router C from being reestablished during the suppression period.
During this period, traffic is forwarded along the path Router A -> Router B -> Router D ->
Router E -> Router F.
NOTE
By default, the Hold-max-cost mode takes effect. The mode can be changed to Hold-down manually.

Figure 5-12 Flapping suppression in a multi-area scenario
Router C
Router A Router F
cost=10 cost=10
Area 1
Device
Area Router B Device
Router E
Area 0 B
0 cost=10
cost=10 cost=10
Router D
Scenario with both LDP-IGP synchronization and OSPF neighbor relationship flapping
suppression configured
In Figure 5-13, if the link between PE1 and P1 fails, an LDP LSP switchover is implemented
immediately, causing the original LDP LSP to be deleted before a new LDP LSP is
established. To prevent traffic loss, LDP-IGP synchronization needs to be configured. With
LDP-IGP synchronization, 65535 is used as the cost of the new LSP to be established. After
the new LSP is established, the original cost takes effect. Consequently, the original LSP is
deleted, and LDP traffic is forwarded along the new LSP.
LDP-IGP synchronization and OSPF neighbor relationship flapping suppression work in
either Hold-down or Hold-max-cost mode. If both functions are configured, Hold-down mode
takes precedence over Hold-max-cost mode, followed by the configured link cost. Table 5-13
lists the suppression modes that take effect in different situations.
Table 5-13 Principles for selecting the suppression modes that take effect in different
situations
LDP-IGP LDP-IGP LDP-IGP Exited from LDP-
Synchronization/ Synchronization Synchronization IGP
OSPF Neighbor Hold-down Mode Hold-max-cost Synchronization
Relationship Mode Suppression
Flapping
Suppression
Mode
OSPF Neighbor Hold-down Hold-down Hold-down

Relationship
Flapping
Suppression Hold-
down Mode

LDP-IGP LDP-IGP LDP-IGP Exited from LDP-

Synchronization/ Synchronization Synchronization IGP
OSPF Neighbor Hold-down Mode Hold-max-cost Synchronization
Relationship Mode Suppression
Flapping
Suppression
Mode
OSPF Neighbor Hold-down Hold-max-cost Hold-max-cost

Relationship
Flapping
Suppression Hold-
max-cost Mode
Exited from OSPF Hold-down Hold-max-cost Exited from LDP-

Neighbor IGP synchronization
Relationship and OSPF neighbor
Flapping relationship flapping
Suppression suppression
For example, the link between PE1 and P1 frequently flaps in Figure 5-13, and both LDP-
IGP synchronization and OSPF neighbor relationship flapping suppression are configured. In
this case, the suppression mode is selected based on the preceding principles. No matter
which mode (Hold-down or Hold-max-cost) is selected, the forwarding path is PE1 -> P4 ->
P3 -> PE2.
Figure 5-13 Scenario with both LDP-IGP synchronization and OSPF neighbor relationship
flapping suppression configured
P1 P2
cost=10
cost=10 cost=10
CE1 PE1 PE2 CE2

cost=100 cost=100
cost=100
P4 P3
Scenario with both bit-error-triggered protection switching and OSPF neighbor

relationship flapping suppression configured
If a link has poor link quality, services transmitted along it may be adversely affected. If bit-
error-triggered protection switching is configured and the bit error rate (BER) along a link
exceeds a specified value, a bit error event is reported, and 65535 is used as the cost of the
link, triggering route reselection. Consequently, service traffic is switched to the backup link.

If both bit-error-triggered protection switching and OSPF neighbor relationship flapping

suppression are configured, they both take effect. Hold-down mode takes precedence over
Hold-max-cost mode, followed by the configured link cost.
5.2.8 Priority-based OSPF Convergence

Priority-based OSPF convergence ensures that specific routes converge first when a great
number of routes need to converge. Different routes can be set with different convergence
priorities. This allows important routes to converge first and therefore improves network
reliability.
By using priority-based OSPF convergence, you can assign a higher convergence priority to
routes for key services so that those routes can converge fast. By so doing, the impact on key
services is reduced.
5.2.9 OSPF-BGP Association
Definition
When a new device is deployed in the network or a device is restarted, network traffic may be
lost during BGP convergence. This is because IGP convergence is faster than BGP
convergence.
This problem can be solved through the synchronization between OSPF and BGP.
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 5-14, RouterA, RouterB, RouterC, and RouterD run OSPF and establish
IBGP connections. RouterC functions as the backup of RouterB. When the network is stable,
BGP and OSPF routes converge completely on the device.
Normally, traffic from RouterA to 10.3.1.0/30 passes through RouterB. When RouterB
becomes faulty, traffic is switched to RouterC. After RouterB recovers, traffic is switched
back to RouterB. During this process, packet loss occurs.
This is because when traffic is switched back to RouterB, IGP route convergence is faster than
BGP route convergence. Consequently, convergence of OSPF routes is already complete
when BGP route convergence is still going on. As a result, RouterB does not know the route
to 10.3.1.0/30.
Therefore, when packets from RouterA to 10.3.1.0/30 arrive at RouterB, they are discarded
because RouterB does not have the route to 10.3.1.0/30.

Figure 5-14 OSPF-BGP synchronization

RouterC
RouterF
POS2/0/0 POS1/0/0
10.1.2.2/30 10.1.4.1/30 POS1/0/0
10.3.1.2/30
POS1/0/0 POS2/0/0
POS2/0/0 10.1.4.2/30 10.3.1.1/30
10.1.2.1/30 EBGP
RouterA RouterD RouterE
POS1/0/0 POS3/0/0
10.1.1.1/30 10.2.1.1/30 POS1/0/0
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
AS 10 RouterB AS 20
Principle
The device enabled with OSPF-BGP synchronization remains as a stub router within the set
synchronization period. That is, the link metric in the LSA advertised by the device is the
maximum value 65535. Therefore, the device instructs other OSPF devices not to use it for
data forwarding.
As shown in Figure 5-14, OSPF-BGP synchronization is enabled on RouterB. In this
situation, before BGP route convergence is complete, RouterA continues to use the backup
link RouterC rather than forward traffic to RouterB until BGP route convergence on RouterB
is complete.
5.2.10 OSPF GR
Routers generally operate with separation of the control plane and forwarding plane. When
the network topology remains stable, a restart of the control plane does not affect the
forwarding plane, and the forwarding plane can still forward data properly. This separation
ensures non-stop service forwarding.
In graceful restart (GR) mode, the forwarding plane continues to direct data forwarding after a
restart occurs. The actions on the control plane, such as re-establishment of neighbor
relationships and route calculation, do not affect the forwarding plane. Network reliability is
improved because service interruption caused by route flapping is prevented.
Basic Concepts of OSPF GR

Graceful Restart (GR) is a technology used to ensure normal traffic forwarding and non-stop
forwarding of key services during the restart of routing protocols.
Unless otherwise stated, GR described in this section refers to the GR technology defined in
RFC 3623.
GR is one of the high availability (HA) technologies, which comprise a set of comprehensive
technologies, such as fault-tolerant redundancy, link protection, faulty node recovery, and
traffic engineering. As a fault-tolerant redundancy technology, GR is widely used to ensure
non-stop forwarding of key services during master/slave switchover and system upgrade.

The following concepts are involved in GR:

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 the GR starts and ends.
l Role of a router during GR
– Restarter: is the router that restarts. The Restarter can be configured to support
totally GR or partly GR.
– Helper: is the router that helps the Restarter. The Helper can be configured to
support planned GR or unplanned GR or to selectively support GR through the
configured policies.
l Conditions that cause GR
– Unknown: indicates that GR is triggered for an unknown reason.
– Software restart: indicates that GR is triggered by commands.
– Software reload/upgrade: indicates that GR is triggered by software restart or
upgrade.
– Switch to redundant control processor: indicates that GR is triggered by the
abnormal master/slave switchover.
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 OSPF 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
using a 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 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 master/slave switchover is triggered through a command, the
Restarter sends a Grace-LSA to all neighbors to notify them of the start, period, and
cause of GR, and then performs the master/slave switchover.
In unplanned GR, the Restarter does not send the Grace-LSA.
In unplanned GR mode, the Restarter sends a Grace-LSA immediately after the slave
board goes Up, informing neighbors of the start, period, and cause of GR. The Restarter
then sends a Grace-LSA to each neighbor five times consecutively. This ensures that
neighbors receive the Grace-LSA. This operation is proposed by manufacturers but not
defined by the OSPF protocol.

The Restarter sends a Grace-LSA to notify neighbors that it enters GR. During GR,
neighbors keep neighbor relationships with the Restarter so that other routers cannot
detect the switchover of the Restarter.
l The GR process runs, as shown in Figure 5-15.
Figure 5-15 OSPF GR process
RouterA RouterB
Restarter Helper
Before the active/ Grace-LSA
Enter Helper
standby switchover
Switchover Return LSAck
LSAck
Finish switchover packet for the
received LSA
Grace-LSA Updates the GR
Enter GR period for the
Grace-LSAs received
Grace-LSAs
Send Hello packets, negotiate,
exchange
Full DD packets, and synchronize LSDB
Exit GR Exit the Helper
successfully, Flush Grace-LSA successfully and
calculate routes, and generate Router-
generate LSA LSA
l The router exits from GR.
Table 5-14 Reasons that a router exits GR

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

Executi Restarter Helper

on of
GR
GR l GR expires, and neighbor l Helper does not receive the

fails. relationships do not recover Grace-LSA from Restarter
completely. before the neighbor
l Router-LSA or Network-LSA sent by relationship expires.
the Helper causes Restarter to fail to l Status of the interface that
perform bidirectional check. functions as the Helper
l Status of the interface that functions changes.
as the Restarter changes. l Helper receives the LSA
l Restarter receives the one-way Hello that is inconsistent with the
packet from the Helper. LSA in the local LSDB
from another router. This
l The Restarter receives the Grace- situation can be excluded
LSA that is generated by another after the Helper is
router on the same network segment. configured not to perform
Only one router can perform GR on strict LSA check.
the same network segment.
l Helper receives Grace-
l On the same network segment, LSAs from two routers on
neighbors of the Restarter have the same network segment
different DRs or BDRs because of at the same time.
the topology changes.
l Neighbor relationships
between Helper and other
neighbors change.
Comparison Between GR Mode and Non-GR Mode
Table 5-15 Comparison of master/slave switchover in the GR mode and non-GR mode
Switchover in Non-GR Mode Switchover in GR Mode
l OSPF neighbor relationships are re- l OSPF neighbor relationships are re-
established. established.
l Routes are recalculated. l Routes are recalculated.
l Forwarding table changes. l Forwarding table remains unchanged.
l Entire network detects route changes, l Except for neighbors of the device where
and route flapping occurs for a short master/slave switchover occurs, other
period of time. routers do not detect route changes.
l Packets are lost during forwarding, l No packets are lost during forwarding, and
and services are interrupted. services are not affected.

5.2.11 OSPF-LDP Association

Definition
In the networking that uses primary and backup links, when the faulty primary link recovers,
traffic is switched from the backup link back to the primary link.
IGP route convergence completes before an LDP session is established. Consequently, the old
LSP is deleted before the new LSP is established and LSP traffic is interrupted.
Purpose
As shown in Figure 5-16, the primary link adopts the path PE1→P1→P2→P3→PE2, and the
backup link adopts the path PE1→P1→P4→P3→PE2.
When the primary link is faulty, traffic is switched to the backup link. After the primary link
recovers, traffic is switched back to the primary link. During this process, traffic is interrupted
for a long period of time.
Figure 5-16 OSPF-LDP association

P2
PE1 P1 P3 PE2
Primary link
Backup link
P4
Synchronizing Label Distribution Protocol(LDP) and IGP on P1 and P2 can shorten traffic
interruption caused by traffic switchover from the backup link to the primary link.
Table 5-16 OSPF-LDP association

Enabling Status of OSPF-LDP Traffic Interruption Time
Association
Not enabled. Seconds level
Enabled. Milliseconds level
Principle
The principle of LDP-IGP synchronization is to delay route switchback by suppressing the
establishment of IGP neighbor relationships until LDP convergence is complete. That is,

before an LSP on the primary link is established, the backup link continues to forward traffic.
Then the link is deleted after the LSP is established.
Synchronization of LDP and IGP involves three timers:
l Hold-down
l Hold-max-cost
l Delay
After the primary link recovers, a router responds as follows:
1. Starts the hold-down timer. The IGP interface does not establish IGP neighbors but waits
for establishment of an LDP session. The Hold-down timer specifies the period that the
IGP interface waits.
2. Starts the hold-max-cost timer after the hold-down timer expires. The hold-max-cost
timer specifies the interval for advertising the maximum link metric of the interface in
the Link State Advertisement (LSA) to the primary link.
3. Starts the Delay timer to allow time for establishment of an LSP after an LDP session is
re-established for the faulty link.
4. After the Delay timer expires, LDP notifies IGP that synchronization is complete
regardless of the status of IGP.
5.2.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 carry the
additional routing information because of limited system resources. This situation is called
OSPF database overflow.
Purpose
You can configure stub areas or NSSAs to solve the problem of the continuous increase in
routing information that causes the exhaustion of system resources of routers. However,
configuring stub areas or NSSAs cannot solve the problem when the unexpected increase in
dynamic routes causes database overflow. Setting the maximum number of external LSAs in
the LSDB can dynamically limit the LSDB capacity, to avoid the problems caused by
database overflow.
Principle
To prevent database overflow, you can set the maximum number of non-default external
routes on a router.
All routers on the OSPF network must be set with the same upper limit. If the number of
external routes on a router reaches the upper limit, the router enters the Overflow state and
starts an overflow timer. The router automatically exits from the overflow state after the timer
expires, By default, it is 5 seconds.

Table 5-17 OSPF database overflow

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

state l Router generates non-default routes.
l Router learns the newly received non-default routes,
and replies with an LSAck packet.
l Router prepares to enter Overflow state for the next
time it occurs.
5.2.13 OSPF Mesh-Group
Definition
In the scenario where there are multiple concurrent links, you can deploy OSPF mesh-group
to classify links into a mesh group. Then, OSPF floods LSAs to only a link selected from the
mesh group. Using OSPF mesh-group prevents unnecessary burden on the system caused by
repetitive flooding.
The mesh-group feature is disabled by default.
Purpose
After receiving or generating an LSA, an OSPF process floods the LSA. When there are
multiple concurrent links, OSPF floods the LSA to each link and sends Update messages.
In this scenario, if there are 2000 concurrent links, OSPF floods each LSA 2000 times. Only
one flooding, however, is valid. The other 1999 times are useless repetition.
To prevent burden on the system caused by repetitive flooding, you can enable mesh-group to
classify multiple concurrent links between a router and its neighbor into a group and then
select a primary link to use for flooding.

Principles
As shown in Figure 5-17, RouterA and RouterB, which are connected through three links,
establish an OSPF neighbor relationship. After receiving a new LSA from interface 4,
RouterA floods the LSA to RouterB through interfaces 1, 2, and 3.
This flooding causes a heavy load on the concurrent links. For the neighbor with concurrent
links, only a primary link is selected to flood the LSA.
Figure 5-17 LSA flooding with OSPF mesh-group disabled
1 LSA
LSA 4 2 LSA
RouterA 3 LSA RouterB
When multiple concurrent links exist between a device enabled with OSPF mesh-group and
its neighbor, the device selects to flood the received LSAs, as shown in Figure 5-18.
Figure 5-18 LSA flooding with OSPF mesh-group enabled
1 LSA
LSA 4 2 LSA
3 LSA
RouterA RouterB
As defined in OSPF, LSAs can be flooded to a link only when the neighbor status is not lower
than Exchange. In this case, when the status of the interface on the primary link is lower than
Exchange, OSPF reselects a primary link from the concurrent links and then floods the LSA.
After receiving the LSA flooded by RouterA from link 1, RouterB no longer floods the LSA
to RouterA through interfaces 2 and 3.
As defined by the mesh-group feature, the Router ID of a neighbor uniquely identifies the
mesh group. Interfaces connected to the same neighbor that have a status greater than
Exchange belong to the same mesh group.
In Figure 5-19, a mesh group of RouterA resides in Area 0, which contains the links of
interface 1 and interface 2. More than one neighbor of interface 3 resides on the broadcast
link. Therefore, interface 3 cannot be defined as part of the mesh group.

Figure 5-19 Interface not added to 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, LSDBs cannot be synchronized and routes cannot be calculated correctly. In this
case, you need to reconfigure the Router ID of the neighbor.
5.3 OSPF Applications
5.3.1 OSPF GR
In Figure 5-20, RouterA, RouterB, RouterC, and RouterD run OSPF for interworking, and
RouterA and RouterB are enabled with GR. When RouterA restarts, RouterB helps RouterA
perform GR, without notifying other neighbors of RouterA. OSPF GR ensures uninterrupted
network traffic.
Figure 5-20 OSPF GR
es RouterC
B do ter
r o u
ute y R r A
Ro notif oute
t R
Set up neighbor no that tarts
relationship and C res
RouterA
negotiate GR RouterB
Restarter Helper Rout

noti er B d RouterD
fy oe
Restart Rou Route s not
ter A r D t
rest hat
arts

5.4 Configuration Task Summary

Table 5-18 describes the OSPF configuration tasks.
Table 5-18 OSPF configuration tasks

Scenario Description Task
Configuring Basic OSPF The configuration of basic 5.7 Configuring Basic

Functions OSPF functions is the OSPF Functions
foundation of the OSPF 5.8 Setting Session
network and the Parameters for OSPF
precondition for other OSPF Neighbor Relationships
functions.
5.9 Configuring OSPF
Attributes in Different
Types of Networks
Configuring OSPF Areas l In a stub area, the area 5.10 Configuring OSPF
border router (ABR) Stub Areas
does not transmit learned 5.11 Configuring OSPF
autonomous system (AS) NSSA
external routes. This
implementation reduces
entries in the routing
tables on ABRs in stub
areas and the amount of
routing information to be
transmitted.
l An NSSA is a new type
of OSPF area. Neither
the NSSA nor the stub
area transmits routes
learned from other areas
in the AS on which it
resides. Different from
the stub area, the NSSA
allows AS external
routes to be imported and
forwarded in the entire
AS.
Adjusting OSPF Route To meet various user 5.12 Adjusting OSPF

Selection requirements, you can adjust Route Selection
OSPF parameters to flexibly
control OSPF routing.

Controlling OSPF Routing To meet network 5.13 Controlling OSPF

Information requirements, you can Routing Information
configure different
parameters to accurately
control the advertising and
receiving of OSPF routes.
Controlling the convergence To enable OSPF to quickly 5.16 Configuring OSPF

speed of OSPF routes detect changes in the Fast Convergence
network topology, you can
speed up OSPF route
convergence. To decrease
the impact of route flapping
on the network and relieve
loads on devices, you can
lower the convergence speed
of OSPF routes.

Improving the Reliability of l OSPF IP FRR pre- 5.14 Configuring OSPF IP

an OSPF Network computes a backup link FRR
by using the Loop-Free 5.15 Configuring BFD for
Alternate (LFA) OSPF
algorithm, and then adds
the backup link and the 5.18 Configuring OSPF
primary link to the GR Helper
forwarding table. In the
case of failures, OSPF IP
FRR can fast switch
traffic to the backup link
before routes on the
control plane converge.
This prevents traffic
interruption, protects
traffic, and improves
reliability of an OSPF
network.
l By default, the interval
for OSPF to send Hello
packets is 10 seconds on
broadcast networks; on
NBMA networks, the
interval for sending
Hello packets is 30
seconds. The interval for
declaring a neighbor
Down, that is, the dead
time after which the
neighbor relationship
becomes invalid, is four
times the interval for
sending Hello packets. If
the switch does not
receive a Hello packet
from its neighbor within
the dead time, the switch
deletes the neighbor.
That is, the switch
detects neighbor faults at
the second level. This
causes a large number of
packets to be lost on a
high-speed network.
Bidirectional Forwarding
Detection (BFD) is
introduced to solve the
preceding problem in the
existing detection

mechanism. BFD
ensures that the detection
interval is reduced to the
millisecond level.
Instead of replacing the
Hello mechanism of
OSPF, BFD works with
OSPF to fast detect the
adjacency fault. In
addition, BFD instructs
OSPF to recalculate
corresponding routes to
ensure correct packet
forwarding.
l When a switch restarts or
performs an active/
standby switchover, it
directly ages all routing
entries in the Forward
Information Base (FIB)
table. This results in
route interruption. In
addition, neighboring
switchs remove this
switch from the neighbor
list, and notify other
switchs. This causes the
re-calculation of SPF. If
this switch recovers
within a few seconds, the
neighbor relationship
becomes unstable. This
results in route flapping.
After being enabled with
OSPF Graceful Restart
(GR), a switch can
ensure continuous packet
forwarding in the event
of a restart caused by an
abnormality. In such a
case, route flapping is
avoided during the short
restart of the switch.

Improving Stability of an You can improve the 5.19 Improving Stability of

OSPF Network stability of the OSPF an OSPF Network
network to reduce route
flapping on the OSPF
network and enable the
device to work in a normal
state for a long time.
Improving Security of an In a network demanding 5.20 Improving the

OSPF Network high security, you can Security of an OSPF
configure OSPF Network
authentication and adopt the
GTSM mechanism to
improve the security of the
OSPF network.
5.5 Configuration Notes

Involved Network Elements
Other network elements also need to support OSPF.
License Support
OSPF is a basic feature of the CE8800&7800&6800&5800 series switches and is not under
license control.
Version Support
Table 5-19 Products and minimum version supporting OSPF
Series Product Minimum Version Required
CE8800 CE8860EI V100R006C00
CE8850EI V200R002C50
CE7800 CE7850EI V100R003C00
CE7855EI V200R001C00
CE6800 CE6810EI V100R003C00
CE6810LI V100R005C10
CE6850EI V100R001C00
CE6850-48S6Q-HI V100R005C00

Series Product Minimum Version Required
CE6850-48T6Q-HI/ V100R005C10
CE6850U-HI/CE6851HI
CE6855HI V200R001C00
CE6860EI V200R002C50
CE6870-24S6CQ-EI/ V200R001C00
CE6870-48S6CQ-EI
CE6870-48T6CQ-EI V200R002C50
CE6880-24S4Q2CQ-EI/ V200R002C50
CE6880-48S4Q2CQ-EI/
CE6880-48T4Q2CQ-EI
CE5800 CE5810EI V100R002C00
CE5850EI V100R001C00
CE5850HI V100R003C00
CE5855EI V100R005C10
Feature Dependencies and Limitations

None
5.6 Default Configuration

Table 5-20 describes the default configuration of OSPF.
Table 5-20 Default configuration of OSPF

Parameter Default Setting
OSPF Disabled
Interval for sending Hello By default, the interval for sending Hello packets is 10
packets seconds on P2P and broadcast interfaces; the interval is
30 seconds on P2MP and NBMA interfaces.
Dead interval for OSPF By default, the dead interval for OSPF neighbors is 40
neighbors seconds on P2P and broadcast interfaces; the interval is
120 seconds on P2MP and NBMA interfaces.
Period during which a device 500 seconds

continues to act as a stub router
Bandwidth reference value used 100 Mbit/s

to calculate the link cost

5.7 Configuring Basic OSPF Functions
Pre-configuration Tasks
Before configuring basic OSPF functions, complete the following task:
l Configuring IP addresses for interfaces to ensure that neighboring nodes are reachable at
the network layer
5.7.1 Creating an OSPF Process
Context
To run OSPF, the switch needs to have a router ID. A router ID of the switch is a 32-bit
unsigned integer, which uniquely identifies the switch in an AS. To ensure the stability of
OSPF, you need to manually configure a router ID for each device during network planning.
Procedure
Step 1 Run:
system-view
The system view is displayed.
Step 2 Run:
ospf [ process-id | router-id router-id | vpn-instance vpn-instance-name ] *
An OSPF process is created, and the OSPF view is displayed.
l The parameter process-id specifies the ID of an OSPF process. The default value is 1.
The switch supports OSPF multi-process. You can create different processes for different
types of service. The OSPF process ID is valid in the local area, without affecting packet
exchange with other switchs. Therefore, different switchs can also exchange packets
even though they have different process IDs.
l The parameter router-id router-id specifies the router ID of the switch.
By default, the system automatically selects an IP address of the interface as the router
ID. The largest IP address in loopback addresses is taken as the router ID. If no loopback
interface is configured, the largest IP address configured on the interface is selected as
the router ID. When manually setting a router ID, ensure that the router ID of each
device in an AS is unique. Generally, you can set the router ID to be the same as the IP
address of a certain interface on the device.
NOTE
The router ID of each OSPF process must be unique on the OSPF network; otherwise, the OSPF
neighbor relationship cannot be set up and routing information is incorrect. Configuring a unique
router ID for each OSPF process on each OSPF device is recommended to ensure stability.
l The parameter vpn-instance vpn-instance-name specifies the name of a VPN instance.
If a VPN instance is specified, the OSPF process belongs to the specified VPN instance.
Otherwise, the OSPF process belongs to the public network instances.

Step 3 Run:
commit
The configuration is committed.
----End
5.7.2 Creating an OSPF Area
Context
More and more devices are deployed with the increasing expansion of the network scale. As a
result, each device has to maintain a large LSDB, which becomes a heavy burden. OSPF
solves this problem by dividing an AS into areas. An area is regarded as a logical device
group. Each group is identified by an area ID. The borders of an area are devices, rather than
links. A network segment (or a link) belongs to only one area; that is, each OSPF interface
must belong to an area.
Procedure
Step 1 Run:
system-view

Step 2 Run:
The OSPF process is enabled, and the OSPF view is displayed.

Step 3 Run:
area area-id
The OSPF area view is displayed.

Areas are not equally important. The area with an area ID 0 is called the backbone area. The
backbone area is responsible for forwarding inter-area routing information. In addition,
routing information between non-backbone areas must be forwarded through the backbone
area.
Step 4 Run:
commit
----End
5.7.3 Enabling OSPF
Context
After creating an OSPF process, you need to configure the network segments included in an
area. A network segment belongs to only one area. that is, you need to specify an area for
each interface that runs OSPF. In this document, network segment refers to the network
segment to which the IP address of the OSPF interface belongs.

OSPF checks the network mask carried in a received Hello packets. If the network mask
carried in a received Hello packet is different from the network mask of the local device, the
Hello packet is discarded. As a result, an OSPF neighbor relationship is not established.
Procedure
Step 1 Run:
system-view
Step 2 Run:
ospf [ process-id ]
The OSPF process view is displayed.
Step 3 Run:
area area-id
OSPF can be enabled in an OSPF area or on a specific interface.
l Enable OSPF in an OSPF area.

1. Run:
network ip-address wildcard-mask
Network segments belonging to an area are configured.
OSPF can properly run on an interface only when the following conditions are met:
– The IP address mask length of the interface is equal to or greater than the mask
length specified in the network command.
– The primary IP address of the interface must be within the network segment
specified by the network command.
By default, OSPF advertises the IP address of the loopback interface as a 32-bit host
route, which is irrelevant to the mask length configured on the loopback interface. To
advertise routes to the network segment of the loopback interface, configure the network
type as NBMA or broadcast in the interface view. For details, see Configuring Network
Types of OSPF Interfaces.
l Enable OSPF on an interface.
1. Run the following command in the system view:
interface interface-type interface-number
The interface view is displayed.

2. On an Ethernet interface, run:
undo portswitch
The interface is switched to Layer 3 mode.
By default, an Ethernet interface works in Layer 2 mode.

If an Ethernet interface already has Layer 2 configuration, this command will fail to be
executed on the interface. Before running this command on the interface, delete all the
Layer 2 configuration of the interface.

NOTE
If many Ethernet interfaces need to be switched to Layer 3 mode, run the undo portswitch batch
interface-type { interface-number1 [ to interface-number2 ] } &<1-10> command in the system
view to switch these interfaces to Layer 3 mode in batches.
3. Run:
ospf enable process-id area area-id
OSPF is enabled on the interface.
Step 4 Run:
commit
----End
5.7.4 (Optional) Creating OSPF Virtual Links
Context
After OSPF areas are defined, OSPF route updates between non-backbone areas are
transmitted through a backbone area. Therefore, OSPF requires that all non-backbone areas
maintain connectivity with the backbone area and that the backbone areas in different OSPF
areas maintain connectivity with each other. In real world situations, this requirement may not
be met because of certain restrictions. To resolve this problem, you can configure OSPF
virtual links.
Perform the following steps on the switch running OSPF.
Procedure
Step 1 Run:
system-view
Step 2 Run:
ospf [ process-id ]
Step 3 Run:
area area-id
Step 4 Run:
vlink-peer router-id [ smart-discover | hello hello-interval | retransmit
retransmit-interval | trans-delay trans-delay-interval | dead dead-interval |
[ simple [ plain plain-text | [ cipher ] cipher-text ] | { md5 | hmac-md5 | hmac-
sha256 } [ key-id { plain plain-text | [ cipher ] cipher-text } ] |
authentication-null | keychain keychain-name ] ] *
A virtual link is created.
This command must also be configured on the neighboring switch.

NOTICE
If plain is selected, the password is saved in the configuration file in plain text. This brings
security risks. It is recommended that you select cipher to save the password in cipher text.
MD5 authentication and HMAC-MD5 authentication have potential security risks. HMAC-
SHA256 authentication mode is recommended.
----End
Follow-up Procedure
After virtual links are created, different default MTUs may be used on devices provided by
different vendors. To ensure consistency, the MTU is set to 0 by default when the interface
sends DD packets. For details, see Configuring an Interface to Fill in the DD Packet with
the Actual MTU.
5.7.5 Checking the Configuration
Prerequisites
All configurations of basic OSPF functions are complete.
Procedure
l Run the display ospf [ process-id ] peer command in any view to check information
about OSPF neighbors.
l Run the display ospf [ process-id ] interface command in any view to check information
about OSPF interfaces.
l Run the display ospf [ process-id ] routing command in any view to check information
about the OSPF routing table.
----End
5.8 Setting Session Parameters for OSPF Neighbor

Relationships
Before configuring session parameters for OSPF neighbor or adjacency relationships,
complete the following tasks:
l Configuring a link layer protocol

the network layer
l 5.7 Configuring Basic OSPF Functions

Configuration Procedures
Perform one or more of the following configuration tasks (excluding "Checking the
Configuration") as required.
5.8.1 Setting the OSPF Packet Retransmission Limit
Context
After an OSPF switch sends one of the following packets, if it does not receive the LSAck
packet within a specified time, it retransmits the packet. After the number of packet
retransmissions reaches the set limit, the OSPF switch tears down the adjacency relationship
with its neighbor.
l DD packets
l LSU packets
l LSR packets
Procedure
Step 1 Run:
system-view

Step 2 Run:
ospf [ process-id ]
The OSPF view is displayed.

Step 3 Run:
retransmission-limit [ max-number ]
The OSPF packet retransmission limit is set.

By default, the OSPF packet retransmission limit is not set. The default maximum number of
packet retransmissions is 30.
Step 4 Run:
commit
----End
5.8.2 Configuring an Interface to Fill in DD Packets with the

Actual MTU
Procedure
Step 1 Run:
system-view

Step 2 Run:
The OSPF interface view is displayed.
Step 3 (On an Ethernet interface), run:

undo portswitch

executed on the interface. Before running this command on the interface, delete all the Layer
2 configuration of the interface.
NOTE
interface-type { interface-number1 [ to interface-number2 ] } &<1-10> command in the system view to
switch these interfaces to Layer 3 mode in batches.
Step 4 Run:
ospf mtu-enable
The interface is configured to fill in DD packets with the actual MTU and check whether the
MTU in DD packets from the neighbor exceeds the MTU of the local end.
By default, the MTU in DD packets sent by an interface is 0.
NOTICE
Setting the MTU in a DD packet will lead to the re-establishment of the neighbor relationship.
Step 5 Run:
commit
----End
Prerequisites
All configurations of session parameters of the OSPF neighbor or adjacency relationship are
complete.
Procedure
l Run the display ospf [ process-id ] peer command to check information about OSPF
neighbors.
l Run the display ospf [ process-id ] brief command to check brief information about the
specified OSPF process.

l Run the display ospf [ process-id ] retrans-queue [ interface-type interface-number ]

[ neighbor-id] command to check the OSPF retransmission list.
----End
5.9 Configuring OSPF Attributes in Different Types of

Networks
Applicable Environment
According to the types of link layer protocols, OSPF classifies networks into the following
types:
l P2MP: There is no concept of P2MP in link layer protocols. Therefore, a P2MP network
must be forcibly changed from other network types.
l NBMA: If the link layer protocol is FR, X.25, OSPF defaults the network type to
NBMA.
l Broadcast: If the link layer protocol is Ethernet or FDDI, OSPF defaults the network
type to broadcast.
l P2P: If the link layer protocol is PPP, HDLC, or LAPB, OSPF defaults the network type
to P2P.
When link layer protocols remain unchanged, you can change network types and configure
OSPF features to flexibly build networks.
Before configuring OSPF attributes in different types of networks, complete the following
tasks:
the network layer

Figure 5-21 Flowchart of configuring OSPF attributes in different types of networks
For a P2P network For a P2MP network For an NBMA network For a broadcast network
Set the network type Set the network type Set the network type Set the network type
of the OSPF interface of the OSPF interface of the OSPF interface of the OSPF interface
to P2P to P2MP to NBMA to broadcast
Disable OSPF from

Set the DR Priority for
checking the network Configure neighbors
the OSPF interface
mask
Set the interval for

sending poll packets
Set the DR priority for

the OSPF interface
Mandatory
procedure
Optional
procedure
5.9.1 Configuring Network Types of OSPF Interfaces
Context
You can configure one of the following network types for an interface as required:
l P2MP: P2MP is not a link layer protocol. Therefore, a P2MP network must be forcibly
changed from other network types.
l NBMA: An NBMA network must be fully meshed. That is, any two switches on the
NBMA network must be directly reachable. In most cases, however, this requirement
cannot be met. In this case, you need to forcibly change the network type using
commands.
l Broadcast: To speed up the establishment of the neighbor relationship, you can change
the network type of broadcast to P2P network.
Procedure
Step 1 Run:
system-view
Step 2 Run:


undo portswitch

NOTE
Step 4 Run:
ospf network-type { broadcast | nbma | p2mp | p2p [ peer-ip-ignore ] }
The network type of the OSPF interface is configured.

By default, the network type of an interface depends on the physical interface. The network
type of an Ethernet interface is broadcast.
Configuring the new network type for an interface will cause the OSPF session on the
interface to be reestablished.
NOTE
Generally, the network types of OSPF interfaces on both ends of a link must be the same. Otherwise,
routes cannot be correctly calculated.
Step 5 Run:
commit
----End
5.9.2 (Optional) Setting the DR Priority for the OSPF Interface of

the Broadcast or NBMA Network Type
Procedure
Step 1 Run:
system-view

Step 2 Run:

undo portswitch


NOTE
Step 4 Run:
ospf dr-priority priority
The DR priority of the OSPF interface is set. The greater the value, the higher the priority.
By default, the DR priority of an interface is 1.
Step 5 Run:
commit
----End
Follow-up Procedure
NOTICE
Restarting or shutting down the current interface will interrupt the OSPF adjacency
relationship between devices. Therefore, perform the operation with caution.
Reconfiguring the DR priority for a device does not change the DR or BDR on a network.
You can reelect a DR or BDR by using the following methods. This, however, will result in
the interruption of the OSPF adjacency relationship between devices. Therefore, the following
methods are used only when necessary.
l Restart the OSPF processes on all the switchs.
l Run the shutdown and then undo shutdown commands on the interfaces where the
OSPF adjacency relationship is established.
5.9.3 Configuring P2MP Network Attributes
Procedure
Step 1 Disable OSPF from checking the network mask.
1. Run:
system-view

2. Run:

3. On an Ethernet interface, run:

undo portswitch

executed on the interface. Before running this command on the interface, delete all the
Layer 2 configuration of the interface.
NOTE
interface-type { interface-number1 [ to interface-number2 ] } &<1-10> command in the system
view to switch these interfaces to Layer 3 mode in batches.
4. Run:
ospf network-type p2mp
The network type of the OSPF interface is configured.

A P2MP network is forcibly changed from another type of network. For details, see
Configuring Network Types for OSPF Interfaces.
5. Run:
ospf p2mp-mask-ignore
OSPF is disabled from checking the network mask on the P2MP network.
6. Run:
commit

Step 2 Configure the switch to filter the LSA packets to be sent.
When multiple links exist between two switchs, you can configure the local switch to filter
the LSA packets to be sent. This can reduce unnecessary LSA retransmission attempts and
save bandwidth resources.
1. Run:
quit
Exit from the interface view.

2. Run:
ospf [ process-id ]

3. Run:
filter-lsa-out peer ip-address { all | { summary [ acl { acl-number | acl-
name } ] | ase [ acl { acl-number | acl-name } ] | nssa [ acl { acl-number |
acl-name } ] } * }
The local switch is configured to filter the LSA packets to be sent on the P2MP network.
By default, the LSA packets to be sent are not filtered.
4. Run:
commit
----End

5.9.4 Configuring Neighbors for NBMA Networks
Procedure
Step 1 Run:
system-view

Step 2 Run:
ospf [ process-id ]

Step 3 Run:
peer ip-address [ dr-priority priority ]
Neighbors are configured on an NBMA network.

l The parameter ip-address specifies the IP address of a neighbor.
l The parameter dr-priority priority specifies the DR priority of the neighbor. The greater
the value, the higher the priority.
Step 4 Run:
commit
----End
5.9.5 (Optional) Configuring the Interval for Sending Poll Packets

in NBMA Networks
Context
On an NBMA network, devices establish neighbor relationships with adjacencies by sending
Hello packets.
Procedure
Step 1 Run:
system-view

Step 2 Run:

undo portswitch


NOTE
Step 4 Run:
ospf timer poll interval
The interval for sending Poll packets on the NBMA interface is set.
The parameter interval specifies the polling interval for sending Hello packets.
Step 5 Run:
commit
----End
Prerequisites
All configurations of OSPF attributes in different types of network are complete.
Procedure
l Run the display ospf [ process-id ] interface command to check information about
OSPF interfaces.
neighbors.
l Run the display ospf brief command to check the interval for sending Hello packets on
an NBMA network.
----End
5.10 Configuring OSPF Stub Areas
Dividing an AS into different areas can reduce the number of LSAs to be transmitted on the
network and enhance OSPF extensibility. For some non-backbone areas at the edge of ASs,
you can configure these areas as stub areas to further reduce the size of the routing table and
the number of transmitted LSAs.
Before configuring OSPF stub areas, complete the following tasks:

the network layer
Figure 5-22 Flowchart of configuring OSPF stub areas
Configure OSPF stub areas
Configure metrics of default routes

sent to stub areas
Mandatory
procedure
Optional
procedure
5.10.1 Defining the Current Area as a Stub Area
Procedure
Step 1 Run:
system-view

Step 2 Run:
ospf [ process-id ]

Step 3 Run:
area area-id

Step 4 Run:
stub [ no-summary ]
The current area is configured as a stub area.

If the parameter no-summary is specified, an ABR is disabled from sending summary LSAs
to a stub area. To disable an ABR from sending summary LSAs to a stub area, you can
specify the parameter no-summary in the stub only when the stub command is configured
on the ABR.
To configure an area as a stub area, you need to run the stub command on all the switchs in
this area.
AS external routes in Type 5 LSAs cannot be advertised in a stub area. Therefore, the switchs
in the stub area learn AS external routes from an ABR. The ABR automatically generates a
Type 3 summary LSA with the link state ID being 0.0.0.0 and the network mask being 0.0.0.0
and then advertises the LSA in the entire stub area.

Step 5 Run:
commit
----End
5.10.2 (Optional) Configuring Metrics of Default Routes Sent to

Stub Areas
Procedure
Step 1 Run:
system-view
Step 2 Run:
ospf [ process-id ]
Step 3 Run:
area area-id
Step 4 Run:
stub [ no-summary ]
The current area is configured as a stub area.
Step 5 Run:
default-cost cost
The cost of the default route to the stub area is set.
The parameter cost specifies the cost of the Type 3 default route to a stub area. The default
value is 1.
This command applies to only the ABR that is connected to a stub area.
Step 6 Run:
commit
----End
Prerequisites
All configurations of OSPF stub areas are complete.

Procedure
neighbors.
l Run the display ospf [ process-id ] routing command to check information about the
OSPF routing table.
----End
5.11 Configuring OSPF NSSA
An excessive number of entries in a routing table wastes network resources and causes high
central processing unit (CPU) usage. To reduce entries in a routing table, configure a non-
backbone area on the border of an AS as a stub area or an NSSA to reduce the amount of
routing information to be transmitted. For details on how to configure an OSPF stub area, see
5.10 Configuring OSPF Stub Areas.
An NSSA is a special type of OSPF area. Neither an NSSA nor a stub area transmits routes
learned from other areas in the AS where it resides. Different from a stub area, an NSSA
allows AS external routes to be imported and advertised in the entire AS.
An OSPF stub area can save system resources but cannot import external routes. An NSSA
can be applied to a scenario in which AS external routes are to be imported but not forwarded
to save system resources.
Type 7 link state advertisements (LSAs) are used to carry imported AS external routing
information in the NSSA. Type 7 LSAs are generated by autonomous system border routers
(ASBRs) of NSSAs and flooded only in the NSSAs where ASBRs reside. The area border
router (ABR) in an NSSA selects Type 7 LSAs from the received LSAs and translates them
into Type 5 LSAs to advertise AS external routes to the other areas over the OSPF network.
NOTE
l A Type 7 LSA is a new type of LSA that has been introduced to support NSSAs and describe
imported external routes.
l Type 7 LSAs can be used to carry default route information to guide traffic to other ASs.
Before configuring an NSSA, complete the following tasks:
l Configuring IP addresses for interfaces to ensure that neighboring switchs are reachable
at the network layer
Procedure
Step 1 Run:
system-view

Step 2 Run:
ospf [ process-id ]
Step 3 Run:
area area-id
Step 4 Run:
nssa [ default-route-advertise [ backbone-peer-ignore ] | no-import-route | no-
summary | set-n-bit | suppress-forwarding-address | translator-always |
translator-interval interval-value | zero-address-forwarding ] *
The specified area is configured as an NSSA.
NOTE
l NSSA attributes must be configured on all devices in the NSSA using the nssa command.
l Configuring or deleting NSSA attributes may update the routing information in the area and
disconnect neighbor relationships. NSSA attributes can be reconfigured or deleted only after the
routing update is complete.
The nssa command is applicable to the following scenarios:

l The default-route-advertise parameter is configured to advertise Type 7 LSAs carrying
the default route on the ASBR to the NSSA.
Regardless of whether the default route 0.0.0.0/0 exists in the routing table on the ABR,
Type 7 LSAs carrying the default route will be generated. However, Type 7 LSAs
carrying the default route will be generated on the ASBR only when the default route
0.0.0.0/0 exists in the routing table.
l If an ASBR also functions as an ABR, the no-import-route parameter can be configured
to prevent external routes imported using the import-route command from being
advertised to the NSSA.
l The no-summary parameter is configured on an ABR to reduce the number of LSAs
that are transmitted to the NSSA. This implementation prevents the ABR from
transmitting Type 3 LSAs to the NSSA.
l After the set-n-bit parameter is configured, the N-bit is set in the database description
(DD) packets during the synchronization between the switch and neighboring switchs.
l The suppress-forwarding-address parameter sets the forwarding address (FA) of the
Type 5 LSAs translated from Type 7 LSAs by the NSSA ABR to 0.0.0.0.
l If multiple ABRs are deployed in the NSSA, the system automatically selects an ABR
(generally the switch with the largest router ID) as a translator to convert Type 7 LSAs
into Type 5 LSAs. You can configure the translator-always parameter on an ABR to
specify the ABR as an all-the-time translator. To specify two ABRs for load balancing,
configure the translator-always parameter on the chosen ABRs to specify the ABRs as
all-the-time translators. You can use this command to pre-configure a fixed translator to
prevent LSA flooding caused by translator role changes.
l The translator-interval parameter is used to ensure uninterrupted services when
translator roles change. The value of interval-value must be greater than the flooding
period.
l The zero-address-forwarding parameter is used to set the FA of the generated NSSA
LSAs to 0.0.0.0 when external routes are imported to the ABR in an NSSA.

Step 5 (Optional) Run:

default-cost cost
The cost of the default route on which Type 3 LSAs are transmitted to the NSSA by the ABR
is set.
To ensure the reachability of AS external routes, the ABR in the NSSA generates a default
route and advertises this route to the other switchs in the NSSA. The cost of the default route
to an NSSA is set and the selection of the default route is adjusted.
By default, the cost of the default route to the NSSA by the ABR is 1.
Step 6 Run:
commit
----End
Checking the Configuration
Run either of the following commands to check LSDB information:
l display ospf [ process-id ] lsdb [ brief ]

l display ospf [ process-id ] lsdb [ { [ { router | network | summary | asbr | ase | nssa |
opaque-link | opaque-area | opaque-as } [ link-state-id ] ] [ originate-router
[ advertising-router-id ] | hostname hostname | self-originate ] } ] [ age { min-value
min-age-value | max-value max-age-value } * ]
l display ospf [ process-id ] lsdb [ { [ { router | network | summary | asbr | ase | nssa |
opaque-link | opaque-area | opaque-as } [ link-state-id ] ] [ originate-router
[ advertising-router-id ] | self-originate ] } ] [ age { min-value min-age-value | max-
value max-age-value } * ] [ resolve-hostname ]
Run either of the following commands to check routing table information:
l display ospf [ process-id ] routing [ ip-address [ mask | mask-length ] ] [ interface

interface-type interface-number ] [ nexthop nexthop-address ]
l display ospf [ process-id ] routing router-id [ router-id ]
Run the display ospf [ process-id ] interface [ all | interface-type interface-number ]

[ verbose ] command to check OSPF interface information.
5.12 Adjusting OSPF Route Selection
On complex networks, you can adjust OSPF parameters to flexibly optimize load balancing
requirements.
Before adjusting OSPF route selection, complete the following tasks:

the network layer
Perform one or more configuration tasks (excluding "Checking the Configuration") as
required.
5.12.1 Setting the Link Cost for an OSPF Interface
Context
OSPF can automatically calculate the link cost for an interface according to the interface
bandwidth. You can also set the link cost for the interface using commands.
If you do not set the cost of an OSPF interface using the ospf cost cost command, OSPF
automatically calculates the cost of the interface according to the interface bandwidth. The
calculation formula is as follows: Cost of the interface = Bandwidth reference value/Interface
bandwidth. The integer of the calculated result is the cost of the interface. If the calculated
result is smaller than 1, the cost value is 1. Changing the bandwidth reference value can
change the cost of an interface.
Procedure
l Setting the link cost for an OSPF interface
a. Run:
system-view

b. Run:

c. On an Ethernet interface, run:
undo portswitch

If an Ethernet interface already has Layer 2 configuration, this command will fail to
be executed on the interface. Before running this command on the interface, delete
all the Layer 2 configuration of the interface.
NOTE
If many Ethernet interfaces need to be switched to Layer 3 mode, run the undo portswitch
batch interface-type { interface-number1 [ to interface-number2 ] } &<1-10> command in
the system view to switch these interfaces to Layer 3 mode in batches.
d. Run:
ospf cost cost
The cost of the OSPF interface is set.

e. Run:

commit

l Setting the bandwidth reference value
a. Run:
system-view

b. Run:
ospf [ process-id ]

c. Run:
bandwidth-reference value
The bandwidth reference value is set.

The parameter value specifies the bandwidth reference value used to calculate the
link cost, in Mbit/s.
d. Run:
commit

----End
5.12.2 Setting the Preference for Equal-cost OSPF Routes
Context
After OSPF calculates equal-cost routes, you can run the nexthop command to select the
route with the highest priority from the equal-cost routes as the next hop. The smaller the
weight, the higher the priority of the route. The default weight is 255. OSPF discovers equal-
cost routes and the number of equal-cost routes is smaller than or equal to that specified in the
maximum load-balancing number command. In this case, OSPF traffic will be balanced
among these equal-cost routes.
Procedure
Step 1 Run:
system-view

Step 2 Run:
ospf [ process-id ]

Step 3 Run:
nexthop ip-address weight value
The preference is set for equal-cost routes.

l The parameter ip-address specifies the next-hop address of the equal-cost route.

l The parameter value specifies the weight of the next hop. The default value is 255. The
smaller the weight, the higher the priority of the route.
Step 4 Run:
commit
----End
5.12.3 Setting the Maximum Number of Equal-Cost Routes
Context
The CE8800&7800&6800&5800 series switches support load balancing among equal-cost
routes. That is, you can configure multiple routes, which have the same destination and
preference.
Procedure
Step 1 Run:
system-view

Step 2 Run:
ospf [ process-id ]

Step 3 Run:
maximum load-balancing number
The maximum number of equal-cost routes is set. The default value is 32(64 on the
CE6870EI).
NOTE
When the number of equal-cost routes is greater than number specified in the maximum load-
balancing command, valid routes are selected for load balancing based on the following criteria:
1. Route preference: Routes with higher preferences are selected for load balancing.
2. Interface index: If routes have the same priorities, routes with higher interface index values are
selected for load balancing.
3. Next hop IP address: If routes have the same priorities and interface index values, routes with larger
IP address are selected for load balancing.
Step 4 Run:
commit
----End
5.12.4 Configuring External Route Selection Rules Compatible

with RFC 1583

Context
All devices in an OSPF routing domain must be configured with the same route selection rule.
At present, most OSPF routing domains adopt the route selection rules defined in RFC 2328.
Procedure
Step 1 Run:
system-view
Step 2 Run:
ospf [ process-id ]
Step 3 (Optional)Run:
rfc1583 compatible
The external route selection rules, which are compatible with RFC 1583, are configured.
By default, the routing rule of compatible 1583 is enabled.

l When RFC1583 compatibility is enabled, a device selects a route to the destination based
on the costs of the routes.
l When RFC1583 compatibility is disabled, a device selects a route to the destination
based on the types of routes. In the case of the same route type, the device compares the
costs of the routes, and selects a route with the smallest cost.
NOTE
On a network, if OSPF switchs have different configurations of the external route selection rules
compatible with RFC 1583, external loops may occur.
Step 4 Run:
commit
----End
Prerequisites
All configurations of adjusting OSPF route selection are complete.
Procedure
l Run the display ospf [ process-id ] interface command to check information about
OSPF interfaces.
l Run the display ospf [ process-id ] routing command to check information about the
OSPF routing table.
----End

5.13 Controlling OSPF Routing Information
Before controlling OSPF routing information, complete the following tasks:
the network layer
required.
5.13.1 Configuring OSPF to Import External Routes
Context
OSPF can ensure loop-free intra-area and inter-area routes; however, OSPF cannot protect
external routes against loops. Therefore, when configuring OSPF to import external routes,
avoid the loops caused by manual configurations.
Do as follows on the switch that functions as the ASBR running OSPF:
Procedure
l Configuring OSPF to import the routes discovered by other protocols
a. Run:
system-view

b. Run:
ospf [ process-id ]

c. Run:
import-route { bgp [ permit-ibgp ] | direct | rip [ process-id-rip ] |
static | isis [ process-id-isis ] | ospf [ process-id-ospf ] } [ cost
cost | route-policy route-policy-name | tag tag | type type ] *
The routes discovered by other protocols are imported.

d. Run:
commit

l Setting parameters for OSPF to import routes
a. Run:
system-view

b. Run:
ospf [ process-id ]

c. Run:
default { cost { cost-value | inherit-metric } | tag tag | type type } *
The default values of parameters (the metric of routes, tag, and type) are set for
importing routes.
n The parameter cost cost-value specifies the default metric of the external route
imported by OSPF.
n The parameter inherit-metric indicates that the cost of the imported route is
the cost carried in the route. If the cost is not specified, the default cost set
through the default command is used as the cost of the imported route.
When OSPF imports external routes, you can set default values for some additional
parameters, such as the metric of routes to be imported, route tag, and route type.
The route tag is used to identify the protocol-related information. For example, it
can be used to differentiate AS numbers when OSPF receives BGP routes.
By default, the default metric of the external routes imported by OSPF is 1; the type
of the imported external routes is Type 2; the default tag value is 1.
NOTE
You can run one of the following commands to set the cost of the imported route. The
following commands are listed in descending order of priority:
l Run the apply cost command in a route-policy to set the cost of the imported route.
l Run the import-route command for OSPF to set the cost of the imported route.
l Run the default command to set the default cost of the imported route.
d. Run:
commit

----End
5.13.2 Configuring OSPF to Advertise the Default Route to the

OSPF Area
Context
In a routing table, a default route is the route to the network 0.0.0.0 (with the mask 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.
Procedure
l Configuring OSPF to advertise the default route to the OSPF area

a. Run:
system-view

b. Run:
ospf [ process-id ]

c. Run the following commands as required:
n Run:
default-route-advertise [ [ always | permit-calculate-other ] | cost
cost | type type | route-policy route-policy-name | distribute-delay
delay-time ] * or default-route-advertise [ permit-calculate-other |
cost cost | type type | route-policy route-policy-name | distribute-
delay delay-time | permit-ibgp ] *
OSPF is configured to advertise the default route to the OSPF area.

○ always indicates that an LSA describing the default route is generated
and then advertised regardless of whether there are active default routes
of other OSPF processes in the routing table of the local device.
○ permit-calculate-other indicates that the local router is still allowed to
calculate the default routes advertised by other switchs after adverting its
default route.
○ route-policy route-policy-name indicates that the local device advertises
default routes according to the parameters of the configured routing
policy when there are matched default routing entries generated by other
OSPF processes.
n Run:
default-route-advertise summary cost cost
The default cost of a Type 3 summary LSA is set.

Before selecting the preceding parameters, you need to configure VPN.
Otherwise, this command cannot be run.
NOTE
l An ASE LSA that describes the default route is generated and then advertised only when
there are active default routes of other OSPF processes in the routing table of the local
device.
l Before advertising a default route, OSPF compares the preferences of default routes.
Therefore, if a static default route is configured on an OSPF switch, to add the default
route advertised by OSPF to the current routing table, ensure that the preference of the
configured static default route is lower than that of the default route advertised by OSPF.
d. Run:
commit

----End
5.13.3 Configuring OSPF Route Aggregation
Context
Carry out the following steps on the OSPF router.

Procedure
l Configuring ABR route aggregation
a. Run:
system-view

b. Run:
ospf [ process-id ]

c. Run:
area area-id

d. Run:
abr-summary
ABR route aggregation is configured.

e. Run:
commit

l Configuring ASBR route aggregation
a. Run:
system-view

b. Run:
ospf [ process-id ]

c. Run:
asbr-summary ip-address mask [ not-advertise | tag tag | cost cost |
distribute-delay interval ] *
ASBR route aggregation is configured.

d. Run:
commit

----End
5.13.4 Configuring OSPF to Filter the Received Routes
Procedure
Step 1 Run:
system-view

Step 2 Run:

ospf [ process-id ]

Step 3 Run:
filter-policy { acl-number | acl-name acl-name | ip-prefix ip-prefix-name | route-
policy route-policy-name [ secondary ] } import
OSPF is configured to filter the received routes.

l The parameter acl-number specifies the number of a basic ACL.
l The parameter acl-name acl-name specifies the name of an ACL.
l The parameter ip-prefix ip-prefix-name specifies the name of an IP prefix list.
OSPF is a link-state dynamic routing protocol, with routing information carried in the LSA.
Therefore, the filter-policy import command cannot be used to filter the advertised or
received LSAs.
The filter-policy import command is used to filter the routes calculated by OSPF. Only the
routes that pass the filtering criteria are added to the routing table. Routes that do not pass the
filtering criteria cannot be added to the OSPF routing table but can be advertised.
Step 4 Run:
commit
----End
5.13.5 Configuring OSPF to Filter the Routes to Be Advertised
Procedure
Step 1 Run:
system-view

Step 2 Run:
ospf [ process-id ]

Step 3 Run:
filter-policy { acl-number | acl-name acl-name | ip-prefix ip-prefix-name }
export [ protocol [ process-id ] ]
OSPF is configured to filter the routes imported through the import-route command. Only
the routes that pass the filtering criteria are advertised.
l The parameter acl-number specifies the number of a basic ACL.
l The parameter acl-name acl-name specifies the name of an ACL.
l The parameter ip-prefix ip-prefix-name specifies the name of an IP prefix list.
You can specify the parameter protocol [ process-id ] to filter the routes of a certain routing
protocol or a certain OSPF process. If protocol [ process-id ] is not specified, OSPF filters all
the imported routes.

NOTE
l The import-route command cannot be used to import external default routes.

l OSPF filters the imported routes, and generates Type 5 LSAs to advertise only external routes that
passing the filtering criteria.
Step 4 Run:
commit
----End
5.13.6 Configuring the switch to Filter LSAs to Be Sent
Context
When multiple links exist between two switches, you can configure the local switch to filter
the LSAs to be sent. This prevents transmission of unnecessary LSAs and saves bandwidth
resources.
Perform the following steps on the switch running OSPF.
Procedure
Step 1 Run:
system-view

Step 2 Run:

undo portswitch

NOTE
Step 4 Run:
ospf filter-lsa-out { all | { summary [ acl { acl-number | acl-name } ] | ase
[ acl { acl-number | acl-name } ] | nssa [ acl { acl-number | acl-name } ] } * }
The LSAs to be sent are filtered.

By default, the LSAs to be sent are not filtered.
----End

5.13.7 Configuring OSPF to Filter ABR Type3 LSA
Procedure
Step 1 Run:
system-view
Step 2 Run:
ospf [ process-id ]
Step 3 Run:
area area-id
Step 4 Depending on type of desired filtering, run one of following commands to configure OSPF to
filter the Type 3 LSAs generated by ABRs.
OSPF is configured to filter the Type 3 LSAs generated by ABRs.
l Run:
filter { acl-number | acl-name acl-name | ip-prefix ip-prefix-name | route-
policy route-policy-name } export
The outgoing summary LSAs in the local area will be filtered.

l Run:
filter { acl-number | acl-name acl-name | ip-prefix ip-prefix-name | route-
policy route-policy-name } import [ include-abr-summary ]
The incoming summary LSAs in the local area will be filtered.
Step 5 Run:
commit
----End
Prerequisites
All configurations of controlling OSPF routing information are complete.
Procedure
l Run the display ospf [ process-id ] lsdb command to check information about the OSPF
LSDB.
----End

5.14 Configuring OSPF IP FRR
Before configuring OSPF IP FRR, complete the following tasks:
the network layer
Figure 5-23 Flowchart for configuring OSPF IP FRR
Enable OSPF IP FRR
Block FRR on a specified

OSPF interface
Mandatory
procedure
Optional
procedure
5.14.1 Enabling OSPF IP FRR
Context
FRR calculation consumes a large number of CPU resources. When there are import features
such as routing protocol, you need to delay FRR calculation.
After FRR calculation is delayed, devices process important services such as route calculation
first.
Do as follows on the switch that needs to protect traffic to be forwarded:
Procedure
Step 1 Run:
system-view

Step 2 Run:
An OSPF process is started and the OSPF view is displayed.

Step 3 Run:
frr
The OSPF IP FRR view is displayed.
Step 4 Run:
loop-free-alternate
OSPF IP FRR is enabled to generate a loop-free backup link.
NOTE
OSPF can generate a loop-free backup link only when the OSPF IP FRR traffic protection inequality is
met.

frr-policy route route-policy route-policy-name
An OSPF IP FRR filtering policy is configured.
After the OSPF IP FRR filtering policy is configured, only the OSPF backup routes that
match the filtering conditions of the policy can be added to the forwarding table.
Step 6 Run:
commit
----End
5.14.2 (Optional) Blocking FRR on an OSPF Interface
Procedure
Step 1 Run:
system-view
Step 2 Run:
The view of an OSPF interface enabled with FRR is displayed.

undo portswitch

NOTE

Step 4 Run:
ospf frr block
FRR is blocked on the OSPF interface.

Step 5 Run:
commit
----End
Prerequisites
All OSPF IP FRR configurations are complete.
Procedure
l Run the display ospf [ process-id ] routing command to check the information about the
primary link and backup link of a route after configuring OSPF IP FRR.
----End
5.15 Configuring BFD for OSPF
The link fault or the topology change may cause devices to recalculate routes. Therefore, the
convergence of routing protocols must be speed up to improve the network performance.
Link faults are inevitable. Therefore, a feasible solution is required to fast detect faults and
notify routing protocols of the faults immediately. If BFD is associated with routing protocols,
once a link fault occurs, BFD can speed up the convergence of routing protocols.
Before configuring BFD for OSPF, complete the following tasks:
the network layer

Figure 5-24 Flowchart of configuring BFD for OSPF
Configure global BFD
Configure BFD for OSPF
Prevent an interface from dynamically

setting up a BFD session
Configure BFD on the specified

interface
Mandatory procedure
Optional procedure
5.15.1 Configuring Global BFD
Procedure
Step 1 Run:
system-view

Step 2 Run:
bfd
BFD is configured globally, and the global BFD view is displayed.

Step 3 Run:
commit
----End
5.15.2 Configuring BFD for OSPF Feature
Procedure
Step 1 Run:
system-view

Step 2 Run:

ospf [ process-id ]

Step 3 Run:
bfd all-interfaces enable
BFD for OSPF is enabled to establish the BFD session.

If all the interfaces in a certain process are configured with BFD and their neighbor
relationships are in the Exstart state, OSPF establishes BFD sessions on all the interfaces in
the process.
Run the bfd all-interfaces { min-rx-interval receive-interval | min-tx-interval transmit-
interval | detect-multiplier multiplier-value | frr-binding } * command to set parameters for
BFD sessions.
l The parameter min-rx-interval receive-interval specifies the expected minimum interval
for receiving BFD packets from the neighbor.
l The parameter min-tx-interval transmit-interval specifies the minimum interval for
sending BFD packets to the neighbor.
l The parameter detect-multiplier multiplier-value specifies the local detection multiplier.
l The parameter frr-binding indicates that the status of the BFD session is bound to OSPF
IP FRR.
NOTE
If only the bfd all-interfaces { min-rx-interval receive-interval | min-tx-interval transmit-interval |

detect-multiplier multiplier-value | frr-binding } * command is run to set BFD parameters, and the bfd
all-interfaces enable command is not run, BFD cannot be enabled.
Step 4 Run:
commit
----End
5.15.3 (Optional) Preventing an Interface from Dynamically

Setting Up a BFD Session
Context
After the bfd all-interfaces enable command is run in an OSPF process, BFD sessions can be
established on all the OSPF interfaces whose neighbor relationships are Full.
Procedure
Step 1 Run:
system-view

Step 2 Run:
The view of the interface enabled with BFD for OSPF is displayed.


undo portswitch

NOTE
Step 4 Run:
ospf bfd block
The interface is prevented from dynamically establishing a BFD session.

Step 5 Run:
commit
----End
5.15.4 (Optional) Configuring BFD on the Specified Interface
Procedure
Step 1 Run:
system-view

Step 2 Run:
The view of the interface enabled with BFD for OSPF is displayed.
undo portswitch

NOTE
Step 4 Run:
ospf bfd enable

BFD is enabled on the interface to establish the BFD session.

If all the interfaces in a certain process are configured with BFD and their neighbor
relationships are in the Exstart state, OSPF establishes BFD sessions on all the interfaces in
the process by using default BFD parameters.
Run the ospf bfd { min-rx-interval receive-interval | min-tx-interval transmit- interval |
detect-multiplier multiplier-value } * command to set parameters for BFD sessions.
NOTE
l The BFD priority configured on an interface is higher than the BFD priority configured in a process.
That is, if BFD is enabled on an interface, BFD parameters on the interface are used to establish
BFD sessions.
l If only the ospf bfd { min-rx-interval receive-interval | min-tx-interval transmit- interval | detect-
multiplier multiplier-value } * command is run to set BFD parameters, and the ospf bfd enable
command is not run, BFD cannot be enabled on the interface.
Step 5 Run:
commit
----End
Prerequisites
All configurations of BFD for OSPF are complete.
Procedure
l Run either of the following commands to check the BFD session:
– display ospf [process-id ] bfd session interface-type interface-number [ router-id ]
– display ospf [process-id ] bfd session { router-id | all }
----End
5.16 Configuring OSPF Fast Convergence
Before configuring OSPF fast convergence, complete the following tasks:
the network layer
required.

5.16.1 Setting the Convergence Priority of OSPF Routes
Context
With the integration of network services, different services such as data, voice, and video run
on the same network infrastructure, and have different requirements for the network. For
Video on Demand (VoD) services, the route convergence speed of the multicast source server
is the most critical factor that affects multicast services. It is required that the routes to the
multicast source should converge rapidly when network faults occur. On the BGP or MPLS
VPN bearer network where OSPF is used to implement the IP connectivity of the backbone
network, end-to-end routes between PEs need to be converged rapidly.
You can set priorities for specific routes by setting the convergence priority of OSPF routes so
that these routes converge preferentially. This shortens the interruption of key services and
improves the reliability of the entire network.
Procedure
Step 1 Run:
system-view
Step 2 Run:
ospf [ process-id ]
Step 3 Run:
prefix-priority { critical | high | medium } ip-prefix ip-prefix-name
The convergence priority of OSPF routes is set.
After the convergence priority of OSPF routes is set, OSPF can calculate and flood LSAs, and
synchronize LSDBs according to the priorities. This speeds up route convergence. When an
LSA meets multiple priorities, the highest priority takes effect. OSPF calculates LSAs in the
sequence of intra-area routes, inter-area routes, and AS external routes. This command makes
OSPF calculate route priorities. Convergence priorities are critical, high, medium, and low.
During LSA flooding, LSAs are placed into the corresponding critical, high, medium, and low
queues according to priorities to speed up the processing of high-priority LSAs.
NOTE
This command takes effect only on the public network.
Step 4 Run:
commit
----End
5.16.2 Setting the Interval for Sending Hello Packets

Context
Hello packets are commonly used packets, which are periodically sent on OSPF interfaces to
establish and maintain neighbor relationships. The intervals set on the interfaces connecting
two OSPF neighbors need to be the same. Otherwise, the OSPF neighbor relationship cannot
be established.
Procedure
Step 1 Run:
system-view
Step 2 Run:

undo portswitch

NOTE
Step 4 Run:
ospf timer hello interval
The interval for sending Hello packets is set on the OSPF interface.
By default, the interval for sending Hello packets on a P2P or broadcast interface is 10s; the
interval for sending Hello packets on a P2MP or NBMA interface is 30s; the dead time for the
OSPF neighbors on the same interface is four times the interval for sending Hello packets.
To speed up OSPF convergence in the case of a link failure, Configuring BFD for OSPF is
recommended.
NOTE
The interval must be longer than the time a device takes to perform a master/slave main control board
switchover. If the timer is set to less than the switchover time, a protocol intermittent interruption occurs
during a switchover. The default timer value is recommended.
Step 5 Run:
commit
----End

5.16.3 Setting the Dead Time of the Neighbor Relationship
Procedure
Step 1 Run:
system-view
Step 2 Run:

undo portswitch

NOTE
Step 4 Run:
ospf timer dead interval
The dead time after which the neighbor relationship between two switches is set.
By default, the dead time of the neighbor relationship on a P2P or broadcast interface is 40s;
the dead time of the neighbor relationship on a P2MP or NBMA interface is 120s; the dead
time of the neighbor relationship on the same interface is four times the interval for sending
Hello packets.
NOTE
If the dead interval of an OSPF neighbor is shorter than 10s, the session may be closed. Therefore, if
dead interval is shorter than 10s, the actual dead interval of an OSPF neighbor is not shorter than 10s.
Both the Hello timer and the Dead timer are restored to their respective default values upon a change to
the network type.
Step 5 Run:
commit
----End
5.16.4 Configuring Smart-discover

Context
Before Smart-discover is configured, when the neighbor status of the switch changes or the
DR/BDR on the multi-access network (broadcast or NBMA network) changes, the switch
does not send Hello packets to its neighbor until the Hello timer expires. This slows down the
establishment of neighbor relationships between devices. After Smart-discover is configured,
when the neighbor relationship status of the switch changes or the DR/BDR on the multi-
access network (broadcast or NBMA network) changes, the switch can send Hello packets to
its neighbor immediately without waiting for the expiration of the Hello timer. This speeds up
the establishment of neighbor relationships and thus implements fast convergence of OSPF
networks.
Procedure
Step 1 Run:
system-view
Step 2 Run:

undo portswitch

NOTE
Step 4 Run:
ospf smart-discover
Smart-discover is configured on the interface.
Step 5 Run:
commit
----End
5.16.5 Setting the Interval for Updating LSAs

Context
In OSPF, the interval for updating LSAs is defined as 5s. This aims to prevent network
connections or frequent route flapping from consuming excessive network bandwidth or
device resources.
On a stable network where routes need to be fast converged, you can cancel the interval for
updating LSAs by setting the interval to 0 seconds. In this manner, changes to the topology or
the routes can be immediately advertised on the network through LSAs, thereby speeding up
route convergence on the network.
Procedure
Step 1 Run:
system-view

Step 2 Run:
ospf [ process-id ]

Step 3 Run:
lsa-originate-interval { 0 | { intelligent-timer max-interval start-interval hold-
interval | other-type interval } * }
The interval for updating LSAs is set.

l The parameter intelligent-timer sets the intelligent timer to update OSPF Type-1 LSA
(Router LSA) and Type-2 LSA (Network LSA).
l The parameter max-interval sets the maximum interval at which LSAs are updated, in
milliseconds.
l The parameter start-interval sets the initial interval at which LSAs are updated, in
milliseconds.
l The parameter hold-interval sets the hold interval at which LSAs are updated, in
milliseconds.
l The parameter other-type interval sets the intelligent timer to update OSPF Type-3 LSA
(Network-summary-LSA), Type-4 LSA (ASBR-summary-LSA) and Type-10 LSA
(Opaque LSA).
By default, an intelligent timer is enabled. After an intelligent timer is enabled, the default
maximum interval for updating LSAs is 5000 ms, the default initial interval is 500 ms, and the
default hold interval is 1000 ms. Details about the interval for updating LSAs are as follows:
1. The initial interval for updating LSAs is specified by start-interval.
2. The interval for updating LSAs for the nth (n ≥ 2) time is equal to hold-interval x 2(n-2).
3. When the interval specified by hold-interval x 2(n-2) reaches the maximum interval
specified by max-interval, OSPF updates LSAs at the maximum interval for three
consecutive times. Then, OSPF goes back to step Step 3.1 and updates LSAs at the
initial interval specified by start-interval.
lsa-originate-interval suppress-flapping suppress-interval [ threshold threshold ]
The maximum LSA suppression period is configured.

If frequent LSA flapping occurs, the larger value between lsa-originate-interval suppress-
flapping and lsa-originate-interval is used to suppress LSA flapping.
By default, if the device receives a LSA, it delays route calculation for 10s.
Step 5 Run:
commit
----End
5.16.6 Setting the Interval for Receiving LSAs
Context
In OSPF, the interval for receiving LSAs is 1s. This aims to prevent network connections or
frequent route flapping from consuming excessive network bandwidth or device resources.
On a stable network where routes need to be fast converged, you can cancel the interval for
receiving LSAs by setting the interval to 0 seconds. In this manner, changes to the topology or
the routes can be immediately advertised on the network through LSAs, thereby speeding up
route convergence on the network.
Procedure
Step 1 Run:
system-view

Step 2 Run:
ospf [ process-id ]

Step 3 Run:
lsa-arrival-interval { interval | intelligent-timer max-interval start-interval
hold-interval }
The interval for receiving LSAs is set.

l The parameter interval specifies the interval for receiving LSAs, in milliseconds.
l The parameter intelligent-timer indicates that the interval for receiving router LSAs or
network LSAs is set through an intelligent timer.
l The parameter max-interval specifies the maximum interval for receiving LSAs, in
milliseconds.
l The parameter start-interval specifies the initial interval for receiving LSAs, in
milliseconds.
l The parameter hold-interval specifies the hold interval for receiving LSAs, in
milliseconds.
On a stable network where routes need to be fast converged, you can set the interval for
receiving LSAs to 0 seconds so that changes to the topology or the routes can be detected
immediately.

By default, an intelligent timer is enabled. After an intelligent timer is enabled, the default
maximum interval for receiving LSAs is 1000 ms, the default initial interval is 500 ms, and
the default hold interval is 500 ms. Details about the interval for receiving LSAs are as
follows:
1. The initial interval for receiving LSAs is specified by the parameter start-interval.
2. The interval for receiving LSAs for the nth (n ≥ 2) time is equal to hold-interval x 2(n-2).
specified by max-interval, OSPF receives LSAs at the maximum interval for three
consecutive times. Then, OSPF goes back to step Step 3.1 and receives LSAs at the
initial interval specified by start-interval.
lsa-arrival-interval suppress-flapping suppress-interval [ threshold threshold ]
The maximum LSA suppression period is configured.

If frequent LSA flapping occurs, the larger value between lsa-arrival-interval suppress-
flapping and lsa-arrival-interval is used to suppress LSA flapping.
By default, if the device receives a LSA, it delays route calculation for 10s.
Step 5 Run:
commit
----End
5.16.7 Setting the Interval for the SPF Calculation
Context
When the OSPF LSDB changes, the shortest path needs to be recalculated. If a network
changes frequently and the shortest path is calculated continually, many system resources are
consumed and thus system performance is degraded. By configuring an intelligent timer and
setting a correct interval for the SPF calculation, you can prevent excessive system memory
and bandwidth resources from being occupied.
Procedure
Step 1 Run:
system-view

Step 2 Run:
ospf [ process-id ]

Step 3 Run:
spf-schedule-interval{ interval1 | intelligent-timer max-interval start-interval
hold-interval [ conservative ] | millisecond interval2 }
The interval for the SPF calculation is set.

l The parameter interval1 specifies the interval for the SPF calculation, in milliseconds.
l The parameter intelligent-timer indicates that the interval for the SPF calculation is set
through an intelligent timer.
l The parameter max-interval specifies the maximum interval for the SPF calculation, in
milliseconds.
l The parameter start-interval specifies the initial interval for the SPF calculation, in
milliseconds.
l The parameter hold-interval specifies the hold interval for the SPF calculation, in
milliseconds.
l The parameter millisecond interval2 specifies the interval for the SPF calculation, in
milliseconds.
By default, an intelligent timer is enabled; the maximum interval for the SPF calculation is
10000 ms, the initial interval is 500 ms, and the hold interval is 1000 ms.
After an intelligent timer is enabled, the interval for the SPF calculation is as follows:
1. The initial interval for the SPF calculation is specified by the parameter start-interval.
2. The interval for the SPF calculation for the nth (n ≥ 2) time is equal to hold-interval x
2(n-2).
specified by max-interval, OSPF performs the SPF calculation at the maximum interval
for three consecutive times. Then, OSPF goes back to step Step 3.1 and performs the
SPF calculation at the initial interval specified by start-interval.
Step 4 Run:
commit
----End
5.16.8 Configuring the Route Calculation Delay Function to

Suppress Frequent LSA Flapping
A route calculation delay can suppress frequent OSPF LSA flapping.
Context
Frequent OSPF LSA flapping on the remote device may lead to route flapping on the local
device, affecting services. To address this problem, run the maxage-lsa route-calculate-delay
command to configure the local device to delay route calculation in the case of frequent OSPF
LSA flapping, which suppresses route flapping locally.
Procedure
Step 1 Run:
system-view

Step 2 Run:
ospf [ process-id ]

Step 3 Run:
maxage-lsa route-calculate-delay delay-interval
The route calculation delay function is configured to suppress frequent OSPF LSA flapping.
Step 4 Run:
commit
----End
5.16.9 Disabling Master/Slave Board Switching Triggered by

Abnormal OSPF LSA Aging
Context
When the local device's aging timer expires, the local device incorrectly clears all Router
LSAs from the peer device, which causes route flapping and service interruptions. To resolve
this issue, master/slave board switching triggered by abnormal OSPF LSA aging is
automatically enabled. Master/slave board switching is triggered to restore network
connections and service traffic when the following condition is met:
(Number of incorrectly cleared Router LSAs/Total number of Router LSAs) x 100% ≥ 80%
(Router LSAs are those sent by the peer device to the local device)
By default, master/slave board switching triggered by abnormal OSPF LSA aging is enabled.
To disable master/slave board switching triggered by abnormal OSPF LSA aging, run the ospf
maxage-lsa auto-protect disable command.
Procedure
Step 1 Run:
system-view
Step 2 Run:
ospf maxage-lsa auto-protect disable
The master/slave board switching triggered by abnormal OSPF LSA aging is disabled.
By default, master/slave board switching triggered by abnormal OSPF LSA aging is enabled.
Step 3 Run:
commit
----End

Prerequisites
All configurations of OSPF fast convergence are complete.
Procedure
----End
5.17 Configuring OSPF Neighbor Relationship Flapping

Suppression
OSPF neighbor relationship flapping suppression works by delaying OSPF neighbor
relationship reestablishment or setting the link cost to the maximum value.
Usage Scenario
If an interface carrying OSPF services alternates between Up and Down, OSPF neighbor
relationship flapping occurs on the interface. During the flapping, OSPF frequently sends
Hello packets to reestablish the neighbor relationship, synchronizes LSDBs, and recalculates
routes. In this process, a large number of packets are exchanged, adversely affecting neighbor
relationship stability, OSPF services, and other OSPF-dependent services, such as LDP and
BGP. OSPF neighbor relationship flapping suppression can address this problem by delaying
OSPF neighbor relationship reestablishment or preventing service traffic from passing
through flapping links.
Before configuring OSPF neighbor relationship flapping suppression, complete the following
tasks:
l Configure an IP address for each interface to ensure that neighboring routers are
reachable at the network layer.
l Configure basic OSPF functions.
Procedure
Step 1 Run:
system-view

By default, OSPF neighbor relationship flapping suppression is enabled globally. To disable
this function globally, run the suppress-flapping peer disable command in the OSPF view.
Step 2 Run:

By default, OSPF neighbor relationship flapping suppression is enabled on all interfaces in
the same OSPF process. To disable the function from one of the interfaces, run the ospf
suppress-flapping peer disable command.


undo portswitch

NOTE
Step 4 Run:
ospf suppress-flapping peer hold-down interval
The Hold-down mode is configured, and its duration is set.

Flapping suppression works in either Hold-down or Hold-max-cost mode.
l Hold-down mode: In the case of frequent flooding and topology changes during neighbor
relationship establishment, interfaces prevent neighbor relationship reestablishment
during Hold-down suppression, which minimizes LSDB synchronization attempts and
packet exchanges.
l Hold-max-cost mode: If the traffic forwarding path changes frequently, interfaces use
65535 as the cost of the flapping link during Hold-max-cost suppression, which prevents
traffic from passing through the flapping link.
Flapping suppression can also work first in Hold-down mode and then in Hold-max-cost
mode.
By default, the Hold-down mode is disabled, and the Hold-max-cost mode is enabled.
To disable the Hold-max-cost mode, run the ospf suppress-flapping peer hold-max-cost
disable command.
Step 5 Run:
ospf suppress-flapping peer { detecting-interval detecting-interval | threshold
threshold | resume-interval resume-interval } *
Detection parameters are configured for OSPF neighbor relationship flapping suppression.
l Specifies the interval for exiting from OSPF neighbor relationship flapping suppression.
If the interval between two successive neighbor status changes from Full to a non-Full
state is longer than resume-interval, the flapping_count is reset.
l If OSPF neighbor relationship flapping suppression works in hold-max-cost mode,
resume-interval indicates the duration of this mode.
NOTE
The value of resume-interval must be greater than that of detecting-interval.
By default, the detection interval of OSPF neighbor relationship flapping suppression is 60s,
the suppression threshold is 10, and the interval for exiting from suppression is 120s.Using
the default detection parameters is recommended.
Step 6 Run:

commit
----End
Checking the Configurations

Run the display ospf [ process-id ] interface interface-type interface-number verbose
command to check the status of OSPF neighbor relationship flapping suppression.
5.18 Configuring OSPF GR Helper
Graceful Restart (GR) is a technology used to ensure normal traffic forwarding and non-stop
forwarding of key services during the restart of routing protocols. GR is one of high
availability (HA) technologies. HA technologies comprise a set of comprehensive techniques,
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.
NOTE
The CE8800&7800&6800&5800 series switches support only the GR Helper.
Before configuring OSPF GR, complete the following tasks:
the network layer
Procedure
Step 1 Run:
system-view

Step 2 Run:
ospf [ process-id ]

Step 3 Run:
opaque-capability enable
The opaque-LSA capability is enabled.

Opaque LSAs provide a generic mechanism for OSPF extension:
l OSPF supports GR using Type 9 LSAs.
l OSPF supports TE using Type 10 LSAs.

Before configuring OSPF GR, enable the opaque LSA capability using the opaque-capability
enable command.
Step 4 Run:
graceful-restart helper-role { [ { ip-prefix ip-prefix-name | acl-number acl-
number | acl-name acl-name } | ignore-external-lsa | planned-only ] * | never }
The GR session parameters is set.
l Set ACL parameters, the local switch can enter the Helper mode only after neighbors
pass the filtering policies of ip-prefix or acl.
l Set ignore-external-lsa, the Helper does not check the LSAs outside the AS (AS-
external LSA). By default, the Helper checks the LSAs outside the AS.
l Set planned-only, the Helper supports only planned GR. By default, the Helper supports
both planned GR and unplanned GR.
l Set never, the switch does not support the Helper mode.
----End

Run the display ospf [ process-id ] graceful-restart [ verbose ] command to check the restart
status of OSPF GR.
5.19 Improving Stability of an OSPF Network
By configuring timers, you can reduce the number of unnecessary packets on networks and
reduce the load on the device to improve network performance.
Before improving the security of an OSPF network, complete the following task:
5.7 Configuring Basic OSPF Functions
required.
5.19.1 Setting the Priority of OSPF
Procedure
Step 1 Run:
system-view

Step 2 Run:
ospf [ process-id ]
Step 3 Run:
preference [ ase | inter | intra ] { preference | route-policy route-policy-
name } *
The priority of OSPF is set.
l If the parameter ase is specified, it indicates that the preference of AS external routes is
set.
l inter: sets the priority of the Inter-area route.
l intra: sets the priority of the Intra-area route.
l The parameter preference specifies the preference of OSPF routes. The smaller the value,
the higher the preference.
l If the parameter route-policy route-policy-name is specified, it indicates that the
preference is set for specified routes according to the routing policy.
By default, the preference of OSPF routes is 10. When the parameter ase is specified, the
default preference of AS external routes is 150.
Step 4 Run:
commit
----End
5.19.2 Configuring the Delay in Transmitting LSAs on the

Interface
Procedure
Step 1 Run:
system-view
Step 2 Run:

undo portswitch


NOTE
Step 4 Run:
ospf trans-delay interval
The delay in transmitting LSAs is set on the interface.
By default, the delay in transmitting LSAs is 1 second.
Step 5 Run:
commit
----End
5.19.3 Configuring the Interval for Retransmitting LSAs
Procedure
Step 1 Run:
system-view
Step 2 Run:

undo portswitch

NOTE
Step 4 Run:
ospf timer retransmit interval
The interval for retransmitting LSAs between adjacent switchs is set.
By default, the interval for retransmitting LSAs is 5 seconds.

NOTE
The interval for retransmitting LSAs between adjacent switchs cannot be set too small. Generally, the
interval needs to be larger than the round trip time of a packet transmitted between two switchs.
Otherwise, certain LSAs are retransmitted unnecessarily.
Step 5 Run:
commit
----End
5.19.4 Configuring Secure Synchronization
Context
When the switchs in an area just finish synchronizing the LSDBs, the LSDBs of these switchs
are different from each other. As a result, route flapping occurs. You can configure secure
synchronization to solve this problem. This, however, may delay the establishment of the
OSPF adjacency relationship.
Procedure
Step 1 Run:
system-view
Step 2 Run:
ospf [process-id ]
Step 3 Run:
safe-sync enable
Secure synchronization is configured.
Step 4 Run:
commit
----End
5.19.5 Configuring Stub Routers
Context
A stub switch is used to control traffic and instruct other OSPF switchs not to use it to
forward data. Other OSPF switchs can have a route to the stub switch.
The metric of links in the Router LSAs generated by the stub switch is set to the maximum
value (65535).

Procedure
Step 1 Run:
system-view

Step 2 Run:
ospf [ process-id ]

Step 3 Run:
stub-router [ on-startup [ interval ] ]
A stub switch is configured.

The parameter on-startup [ interval ] specifies the interval during which the switch continues
to function as a stub switch. By default, the interval is 500 seconds.
NOTE
There is no relationship between the stub switch configured through this command and the switch in a
stub area.
Step 4 Run:
commit
----End
5.19.6 Prohibiting an OSPF Interface from Sending and Receiving

OSPF Packets
Context
You can prohibit an OSPF interface from sending and receiving OSPF packets to prevent
local OSPF routing information from being obtained by devices on other networks. This
restriction also prevents the local device from receiving the routing update information
advertised by other devices on the same network.
After an OSPF interface is prohibited from sending and receiving OSPF packets, the interface
can still advertise its direct routes, but not Hello packets. Therefore, no neighbor relationship
can be set up between the device and its neighbor. The OSPF network becomes more adaptive
and network resources are saved.
Procedure
Step 1 Run:
system-view

Step 2 Run:
ospf [ process-id ]

Step 3 Run:
silent-interface { all | interface-type interface-number }
An OSPF interface is prohibited from sending and receiving OSPF packets.
By default, an interface is allowed to send and receive OSPF packets.
You can prohibit an interface from sending and receiving OSPF packets in different OSPF
processes, but the silent-interface command is valid only for the OSPF interface in the local
process.
----End
Prerequisites
All configurations of improving the stability of an OSPF network are complete.
Procedure
l Run the display ip routing-table command to check information about the IP routing
table.
----End
5.20 Improving the Security of an OSPF Network
With the increase in attacks on TCP/IP networks and the defects in the TCP/IP protocol suite,
network attacks have a greater impact on the network security. Especially attacks on network
devices will cause the crash of the network. By configuring the GTSM and authentication,
you can improve the security of an OSPF network.
The CE8800&7800&6800&5800 series switches support the following authentication modes:

l Simple authentication
l MD5 authentication
l HMAC-MD5 authentication
l Keychain authentication
NOTE
The CE8800&7800&6800&5800 series switches supports OSPF GTSM. For detailed configuration of
OSPF GTSM, refer to the CloudEngine 8800&7800&6800&5800 Series Switches Configuration Guide
- Security
NOTE

Before improving the security of an OSPF network, complete the following tasks:
the network layer
required.
5.20.1 Configuring the OSPF GTSM Functions
Context
To apply GTSM functions, enable GTSM on the two ends of the OSPF connection.
The valid TTL range of the detected packets is [255 -hops + 1, 255].
GTSM checks the TTL value of only the packets that match the GTSM policy. For the packets
that do not match the GTSM policy, you can set them as "pass" or "drop". If the GTSM
default action performed on the packet is set as "drop", you need to configure all the switch
connections for GTSM. If the packets sent from a switch do not match the GTSM policy, they
are dropped. The connection thus cannot be established. This ensures security but reduces the
ease of use.
You can enable the log function to record information about dropped packets. This
information facilitates fault location.
Procedure
Step 1 Run:
system-view

Step 2 Run:
ospf valid-ttl-hops hops [ nonstandard-multicast ] [ vpn-instance vpn-instance-
name ]
OSPF GTSM functions are configured.
NOTE
The ospf valid-ttl-hops command has two functions:

l Enabling OSPF GTSM
l Configuring the TTL value to be detected
The parameter vpn-instance is valid only for the latter function.
Thus, if only the private network policy or the public network policy is configured, it is recommended to
set the default action performed on the packets that do not match the GTSM policy as pass. This
prevents the OSPF packets of other processes from being discarded incorrectly.
----End

5.20.2 Configuring the Area Authentication Mode
Context
In area authentication, all the switchs in an area must use the same area authentication mode
and password. For example, the authentication mode of all devices in Area 0 is simple
authentication and the password is abc.
NOTICE
If plain is selected during the configuration of the area authentication mode, the password is
saved in the configuration file in plain text. This saving mode brings security risks. It is
recommended that you select cipher to save the password in cipher text.
Simple, MD5 authentication, and HMAC-MD5 cipher text authentication have potential
security risks. HMAC-SHA256 cipher text authentication is recommended.
Procedure
Step 1 Run:
system-view

Step 2 Run:
ospf [ process-id ]

Step 3 Run:
area area-id

Step 4 Run any of the following commands to configure the authentication mode of the OSPF area
as required:
l Run:
authentication-mode simple [ plain plain-text | [ cipher ] cipher-text ]
Simple authentication is configured for the OSPF area.

– plain indicates the plain text password.
– cipher indicates the cipher text password. For Message Digest 5 (MD5) or Hashed
Message Authentication Code-MD5 (HMAC-MD5) authentication, the
authentication mode is in cipher text by default.
l Run:
authentication-mode { md5 | hmac-md5 | hmac-sha256 } [ key-id { plain plain-
text | [ cipher ] cipher-text } ]
The specified authentication mode is configured for the OSPF area.

– md5 indicates the MD5 cipher text authentication mode.
– hmac-md5 indicates the HMAC-MD5 cipher text authentication mode.

– hmac-sha256 indicates the HMAC-SHA256 cipher text authentication mode.

– key-id specifies the ID of the authentication key.
l Run:
authentication-mode keychain keychain-name
Keychain authentication is configured for the OSPF area.

NOTE
Before using keychain authentication, you need to configure keychain information in the system
view. To establish the OSPF neighbor relationship, you need to ensure that the key-id, algorithm,
and key-string of the local ActiveSendKey are the same as those of the remote ActiveRecvKey.
Step 5 Run:
commit
----End
5.20.3 Configuring the Interface Authentication Mode
Context
The interface authentication mode is used among neighbor switchs to set the authentication
mode and password. Its priority is higher than that of the area authentication mode.
NOTICE
If plain is selected during the configuration of the interface authentication mode, the
password is saved in the configuration file in plain text. This saving mode brings security
risks. It is recommended that you select cipher to save the password in cipher text.
Simple, MD5 authentication, and HMAC-MD5 cipher text authentication have potential
security risks. HMAC-SHA256 cipher text authentication is recommended.
Procedure
Step 1 Run:
system-view

Step 2 Run:

undo portswitch


NOTE
Step 4 Run any of the following commands to configure the interface authentication mode as
required:
l Run:
ospf authentication-mode simple [ plain plain-text | [ cipher ] cipher-text ]
Simple authentication is configured for the OSPF interface.

– simple indicates simple authentication.
– plain indicates the plain text password. For simple authentication, the
authentication mode is in plain text by default.
– cipher indicates the cipher text password. For MD5 or HMAC-MD5 authentication,
the authentication mode is in cipher text by default.
l Run:
ospf authentication-mode { md5 | hmac-md5 | hmac-sha256 } [ key-id { plain
plain-text | [ cipher ] cipher-text } ]
The specified authentication mode is configured for the OSPF interface.

– md5 indicates the MD5 cipher text authentication mode.
– hmac-md5 indicates the HMAC-MD5 cipher text authentication mode.
– hmac-sha256 indicates the HMAC-SHA256 cipher text authentication mode.
l Run:
ospf authentication-mode null
The OSPF interface is not authenticated.

l Run:
ospf authentication-mode keychain keychain-name
Keychain authentication is configured for the OSPF area.

NOTE
Before using keychain authentication, you need to configure keychain information in the system
view. To establish the OSPF neighbor relationship, you need to ensure that the key-id, algorithm,
and key-string of the local ActiveSendKey are the same as those of the remote ActiveRecvKey.
Step 5 Run:
commit
----End
Prerequisites
All configurations of improving the security of an OSPF network are complete.

Procedure
l Run the display ospf [ process-id ] brief command to view the configurations of the
system in the current view.
----End
5.21 Configuring the Network Management Function of

OSPF
Through the Simple Network Management Protocol (SNMP), the OSPF Management
Information Base (MIB) manages multicast information exchanged between the NMS and
agents.
Before configuring the network management function of OSPF, complete the following tasks:
the network layer
Procedure
Step 1 Run:
system-view

Step 2 Run:
ospf mib-binding process-id
The OSPF process is bound to the MIB.

Step 3 Run:
commit
----End

Run the following commands to check the previous configuration.
binding between the OSPF process and the MIB.
5.22 Maintaining OSPF

5.22.1 Clearing OSPF
Context
NOTICE
OSPF information cannot be restored after you clear it. So, confirm the action before you use
the command.
To clear OSPF information, run the following reset commands in the user view.
Procedure
l Run the reset ospf [ process-id ] counters [ neighbor [ interface-type interface-number ]
[ router-id ] ] command to reset OSPF counters.
– counters indicates OSPF counters.
– neighbor indicates neighbor information on the specified interface.
l Run the reset ospf [ process-id ] counters maxage-lsa command to delete the statistics
about router LSAs that have reached the aging time.
l Run the reset ospf [ process-id ] redistribution command in the user view to re-import
routes by OSPF.
l Run the reset gtsm statistics { all | slot-id } command in the user view to clear the
GTSM statistics on the device.
l Run the reset ospf [ process-id ] frr command in the user view to perform OSPF IP FRR
calculation again.
l Run:
reset ospf process-id suppress-flappingpeer [ interface-type interface-
number ] [ notify-peer ]
Interfaces are forced to exit from OSPF neighbor relationship flapping suppression.
NOTE
Interfaces exit from flapping suppression in the following scenarios:

l The suppression timer expires.
l The corresponding OSPF process is reset.
l An OSPF neighbor is reset using the reset ospf peer command.
l OSPF neighbor relationship flapping suppression is disabled globally using the suppress-
flapping peer disable command in the OSPF view.
l The reset ospf suppress-flapping peer command is run.
If notify-peer is specified when the reset ospf suppress-flapping peer command is run on a
device, the device sends Hello packets in which HelloInterval and RouterDeadInterval are 0s to
its neighbors to instruct the neighbors to exit from OSPF neighbor relationship flapping
suppression too. If the neighbors fail to receive such Hello packets, the function of notify-peer
does not take effect. To force the neighbors to exit from OSPF neighbor relationship flapping
suppression, run the reset ospf suppress-flapping peer command on them.

l Run the reset ospf [ process-id ] peer [ interface-type interface-number ] router-id

command to restart OSPF peers.
----End
5.22.2 Resetting OSPF
Context
NOTICE
Running the reset ospf command will tear down the OSPF adjacency relationship between
the switchs. So, confirm the action before you use the command.
To reset OSPF connections, run the following reset commands in the user view.
Procedure
l Run the reset ospf [ process-id ] process command in the user view to restart the OSPF
process.
----End
5.23 Configuration Examples

This section only provides configuration examples for single features. For details about multi-
feature configuration cases, feature-specific configuration cases, interconnection cases,
protocol or hardware replacement cases, and industry application cases, see the Typical
Configuration Cases.
5.23.1 Example for Configuring Basic OSPF Functions
Networking Requirements
As shown in Figure 5-25, all switchs run OSPF, and the entire AS is partitioned into three
areas. Switch A and Switch B function as ABRs to forward the routes between areas.
After the configuration is complete, each switch should learn the routes to all network
segments in the AS.

Figure 5-25 Networking diagram of configuring basic OSPF functions

Area0
10GE1/0/1
VLANIF10
192.168.0.2/24
SwitchA 10GE1/0/1 SwitchB
10GE1/0/2 10GE1/0/2
VLANIF10
VLANIF20 VLANIF30
192.168.0.1/24
192.168.1.1/24 192.168.2.1/24
10GE1/0/1 10GE1/0/1
VLANIF20 VLANIF30
192.168.1.2/24 192.168.2.2/24
SwitchC SwitchD
10GE1/0/2 10GE1/0/2
VLANIF40 VLANIF50
172.16.1.1/24 172.17.1.1/24
10GE1/0/1 10GE1/0/1
VLANIF40 VLANIF50
172.16.1.2/24 172.17.1.2/24
SwitchE SwitchF
Area1 Area2
Configuration Roadmap
The configuration roadmap is as follows:
1. Enable OSPF on each switch.
2. Specify network segments in different areas.
Procedure
Step 1 Assign an IP address to each interface. The detailed configuration is not mentioned here.
Step 2 Configure basic OSPF functions.

# Configure Switch A.
<HUAWEI> system-view
[~HUAWEI] sysname SwitchA
[*HUAWEI] commit
[~SwitchA] router id 10.1.1.1
[*SwitchA] ospf 1
[*SwitchA-ospf-1] area 0
[*SwitchA-ospf-1-area-0.0.0.0] network 192.168.0.0 0.0.0.255
[*SwitchA-ospf-1-area-0.0.0.0] quit
[*SwitchA-ospf-1] commit
[~SwitchA-ospf-1] quit
# Configure Switch B.

[~HUAWEI] sysname SwitchB
[*HUAWEI] commit
[~SwitchB] router id 10.2.2.2
[*SwitchB] ospf 1
[*SwitchB-ospf-1] area 0
[*SwitchB-ospf-1-area-0.0.0.0] network 192.168.0.0 0.0.0.255
[*SwitchB-ospf-1-area-0.0.0.0] quit
[*SwitchB-ospf-1] commit
[~SwitchB-ospf-1] quit
# Configure Switch C.
[~HUAWEI] sysname SwitchC
[*HUAWEI] commit
[~SwitchC] router id 10.3.3.3
[*SwitchC] ospf 1
[*SwitchC-ospf-1] area 1
[*SwitchC-ospf-1-area-0.0.0.1] network 192.168.1.0 0.0.0.255
[*SwitchC-ospf-1-area-0.0.0.1] commit
[~SwitchC-ospf-1-area-0.0.0.1] quit
[~SwitchC-ospf-1] quit
# Configure Switch D.
[~HUAWEI] sysname SwitchD
[*HUAWEI] commit
[~SwitchD] router id 10.4.4.4
[*SwitchD] ospf 1
[*SwitchD-ospf-1] area 2
[*SwitchD-ospf-1-area-0.0.0.2] network 192.168.2.0 0.0.0.255
[*SwitchD-ospf-1-area-0.0.0.2] commit
[~SwitchD-ospf-1-area-0.0.0.2] quit
[~SwitchD-ospf-1] quit
# Configure Switch E.
[~HUAWEI] sysname SwitchE
[*HUAWEI] commit
[~SwitchE] router id 10.5.5.5
[*SwitchE] ospf 1
[*SwitchE-ospf-1] area 1
[*SwitchE-ospf-1-area-0.0.0.1] network 172.16.1.0 0.0.0.255
[*SwitchE-ospf-1-area-0.0.0.1] commit
[~SwitchE-ospf-1-area-0.0.0.1] quit
[~SwitchE-ospf-1] quit
# Configure Switch F.
[~HUAWEI] sysname SwitchF
[*HUAWEI] commit
[~SwitchF] router id 10.6.6.6
[*SwitchF] ospf 1
[*SwitchF-ospf-1] area 2
[*SwitchF-ospf-1-area-0.0.0.2] network 172.17.1.0 0.0.0.255
[*SwitchF-ospf-1-area-0.0.0.2] commit
[~SwitchF-ospf-1-area-0.0.0.2] quit
[~SwitchF-ospf-1] quit
Step 3 Verify the configuration.

# Display the OSPF neighbors of Switch A.

[~SwitchA] display ospf peer
OSPF Process 1 with Router ID 10.1.1.1
Area 0.0.0.0 interface 192.168.0.1(Vlanif10)'s neighbors
Router ID: 10.2.2.2 Address : 192.168.0.2
State : Full Mode : Nbr is Master Priority: 1
DR : 192.168.0.2 BDR : 192.168.0.1 MTU : 0
Dead timer due (in seconds) : 36
Retrans timer interval : 5
Neighbor up time : 02h29m06s
Authentication Sequence : 0

Router ID: 10.3.3.3 Address : 192.168.1.2
State : Full Mode : Nbr is Master Priority: 1
DR : 192.168.1.2 BDR : 192.168.1.1 MTU : 0
Dead timer due (in seconds) : 33
Retrans timer interval : 5
Neighbor up time : 02h28m52s
Authentication Sequence : 0
# Display the OSPF routes of Switch A.

[~SwitchA] display ospf routing
Routing for Network

--------------------------------------------------------------------------------
Destination Cost Type NextHop AdvRouter Area
172.16.1.0/24 2 Transit 192.168.1.2 10.3.3.3 0.0.0.1
172.17.1.0/24 3 Inter-area 192.168.0.2 10.2.2.2 0.0.0.0
192.168.0.0/24 1 Direct 192.168.0.1 10.1.1.1 0.0.0.0
192.168.1.0/24 1 Direct 192.168.1.1 10.1.1.1 0.0.0.1
192.168.2.0/24 2 Inter-area 192.168.0.2 10.2.2.2 0.0.0.0
Total Nets: 5
Intra Area: 3 Inter Area: 2 ASE: 0 NSSA: 0
# Display the LSDB of Switch A.

[~SwitchA] display ospf lsdb

Link State Database
Area: 0.0.0.0
Type LinkState ID AdvRouter Age Len Sequence Metric
Router 10.1.1.1 10.1.1.1 93 48 80000004 1
Router 10.2.2.2 10.2.2.2 92 48 80000004 1
Sum-Net 172.16.1.0 10.1.1.1 1287 28 80000002 2
Sum-Net 192.168.1.0 10.1.1.1 1716 28 80000001 1
Sum-Net 172.17.1.0 10.2.2.2 1336 28 80000001 2
Sum-Net 192.168.2.0 10.2.2.2 87 28 80000002 1
Area: 0.0.0.1
Type LinkState ID AdvRouter Age Len Sequence Metric
Router 10.1.1.1 10.1.1.1 1420 48 80000002 1
Router 10.3.3.3 10.3.3.3 1294 60 80000003 1
Router 10.5.5.5 10.5.5.5 1296 36 80000002 1
Network 172.16.1.1 10.3.3.3 1294 32 80000001 0
Sum-Net 172.17.1.0 10.1.1.1 1325 28 80000001 3
Sum-Net 192.168.0.0 10.1.1.1 1717 28 80000001 1
Sum-Net 192.168.2.0 10.1.1.1 1717 28 80000001 2

# Display the routing table on Switch D and perform the ping operation to test the
connectivity.
[~SwitchD] display ospf routing
Routing for Network

--------------------------------------------------------------------------------
172.16.1.0/24 4 Inter-area 192.168.2.1 10.2.2.2 0.0.0.2
172.17.1.0/24 1 Direct 172.17.1.1 10.4.4.4 0.0.0.2
192.168.0.0/24 2 Inter-area 192.168.2.1 10.2.2.2 0.0.0.2
192.168.1.0/24 3 Inter-area 192.168.2.1 10.2.2.2 0.0.0.2
192.168.2.0/24 1 Direct 192.168.2.2 10.4.4.4 0.0.0.2
Total Nets: 5
[~SwitchD] ping 172.16.1.1
PING 172.16.1.1: 56 data bytes, press CTRL_C to break
Reply from 172.16.1.1: bytes=56 Sequence=1 ttl=253 time=62 ms
--- 172.16.1.1 ping statistics ---
5 packet(s) transmitted
5 packet(s) received
0.00% packet loss
round-trip min/avg/max = 16/59/94 ms
----End
Configuration Files
l Configuration file of Switch A
#
sysname SwitchA
#
vlan batch 10 20
#
router id 10.1.1.1
#
interface Vlanif10
ip address 192.168.0.1 255.255.255.0
#
interface Vlanif20
ip address 192.168.1.1 255.255.255.0
#
interface 10GE1/0/1
port link-type trunk
port trunk allow-pass vlan 10
#
interface 10GE1/0/2
#
ospf 1
area 0.0.0.0
network 192.168.0.0 0.0.0.255
area 0.0.0.1
network 192.168.1.0 0.0.0.255
#
return

l Configuration file of Switch B

#
sysname SwitchB
#
vlan batch 10 30
#
router id 10.2.2.2
#
interface Vlanif10
ip address 192.168.0.2 255.255.255.0
#
interface Vlanif30
ip address 192.168.2.1 255.255.255.0
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
ospf 1
area 0.0.0.0
network 192.168.0.0 0.0.0.255
area 0.0.0.2
network 192.168.2.0 0.0.0.255
#
return
l Configuration file of Switch C

#
sysname SwitchC
#
vlan batch 20 40
#
router id 10.3.3.3
#
interface Vlanif20
ip address 192.168.1.2 255.255.255.0
#
interface Vlanif40
ip address 172.16.1.1 255.255.255.0
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
ospf 1
area 0.0.0.1
network 192.168.1.0 0.0.0.255
network 172.16.1.0 0.0.0.255
#
return
l Configuration file of Switch D

#
sysname SwitchD
#
vlan batch 30 50
#
router id 10.4.4.4
#
interface Vlanif30
ip address 192.168.2.2 255.255.255.0

#
interface Vlanif50
ip address 172.17.1.1 255.255.255.0
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
ospf 1
area 0.0.0.2
network 192.168.2.0 0.0.0.255
network 172.17.1.0 0.0.0.255
#
return
l Configuration file of Switch E

#
sysname SwitchE
#
vlan batch 40
#
router id 10.5.5.5
#
interface Vlanif40
ip address 172.16.1.2 255.255.255.0
#
interface 10GE1/0/1
#
ospf 1
area 0.0.0.1
network 172.16.1.0 0.0.0.255
#
return
l Configuration file of Switch F

#
sysname SwitchF
#
vlan batch 50
#
router id 10.6.6.6
#
interface Vlanif50
ip address 172.17.1.2 255.255.255.0
#
interface 10GE1/0/1
#
ospf 1
area 0.0.0.2
network 172.17.1.0 0.0.0.255
#
return
5.23.2 Example for Configuring OSPF Stub Areas

As shown in Figure 5-26, all switchs run OSPF, and the entire AS is partitioned into three
areas. Switch A and Switch B function as ABRs to advertise routes between areas; Switch D
functions as the ASBR to import external routes, that is, static routes.
It is required to configure Area 1 as a stub area to reduce the LSAs advertised to this area
without affecting the route reachability.
Figure 5-26 Networking diagram of configuring an OSPF stub area

Area0
10GE1/0/1
VLANIF10
192.168.0.2/24
10GE1/0/2 10GE1/0/2
VLANIF10
VLANIF20 VLANIF30
192.168.0.1/24
192.168.1.1/24 192.168.2.1/24
10GE1/0/1 10GE1/0/1
VLANIF20 VLANIF30
192.168.1.2/24 192.168.2.2/24
SwitchC SwitchD
10GE1/0/2 10GE1/0/2
Stub VLANIF40 VLANIF50
ASBR
172.16.1.1/24 172.17.1.1/24
10GE1/0/1 10GE1/0/1
VLANIF40 VLANIF50
172.16.1.2/24 172.17.1.2/24
SwitchE SwitchF
Area1 Area2
1. Configure basic OSPF functions on each switch to realize interconnection.
2. Configure static routes on Switch D and import it into OSPF.
3. Configure Area 1 as a stub area by running the stub command on all switchs in Area 1
and check the OSPF routing information on Switch C.
4. Prevent Switch A from advertising Type 3 LSAs to the stub area, and check the OSPF
routing information on Switch C.
Procedure
Step 1 Assign an IP address to each interface. The detailed configuration is not mentioned here.
Step 2 Configure basic OSPF functions. For details, see 5.23.1 Example for Configuring Basic
OSPF Functions.

Step 3 Configure Switch D to import static routes.

[~SwitchD] ip route-static 192.168.200.0 24 null 0
[*SwitchD] ospf 1
[*SwitchD-ospf-1] import-route static type 1
[*SwitchD-ospf-1] commit
[~SwitchD-ospf-1] quit
# Display ABR and ASBR information on Switch C.

[~SwitchC] display ospf abr-asbr
Routing Table to ABR and ASBR
Type Destination Area Cost NextHop RtType
Intra-area 10.1.1.1 0.0.0.1 1 192.168.1.1 ABR
Inter-area 10.4.4.4 0.0.0.1 3 192.168.1.1 ASBR
# Display the OSPF routing table on Switch C.
NOTE
If the area where Switch C resides is a common area, external routes exist in the routing table.
[~SwitchC] display ospf routing
Routing for Network

--------------------------------------------------------------------------------
Destination Cost Type Next-Hop AdvRouter Area
172.16.1.0/24 1 Direct 172.16.1.1 10.3.3.3
0.0.0.1
172.17.1.0/24 4 Inter-area 192.168.1.1 10.1.1.1

0.0.0.1
192.168.0.0/24 2 Inter-area 192.168.1.1 10.1.1.1

0.0.0.1
192.168.1.0/24 1 Direct 192.168.1.2 10.1.1.1

0.0.0.1
192.168.2.0/24 3 Inter-area 192.168.1.1 10.1.1.1

0.0.0.1
Routing for ASEs

--------------------------------------------------------------------------------
Destination Cost Type Tag NextHop AdvRouter
192.168.200.0/24 4 Type1 1 192.168.1.1 10.4.4.4
Total Nets: 6
Step 4 Configure Area 1 as a stub area.

[~SwitchA] ospf 1
[*SwitchA-ospf-1-area-0.0.0.1] stub
[*SwitchA-ospf-1-area-0.0.0.1] commit
[~SwitchA-ospf-1-area-0.0.0.1] quit
[~SwitchA-ospf-1] quit
[~SwitchC] ospf 1
[*SwitchC-ospf-1-area-0.0.0.1] stub
[*SwitchC-ospf-1-area-0.0.0.1] commit

[~SwitchC-ospf-1-area-0.0.0.1] quit
[~SwitchC-ospf-1] quit
[~SwitchE] ospf 1
[*SwitchE-ospf-1-area-0.0.0.1] stub
[*SwitchE-ospf-1-area-0.0.0.1] commit
[~SwitchE-ospf-1-area-0.0.0.1] quit
[~SwitchE-ospf-1] quit
# Display the routing table on Switch C.
NOTE
After the area where Switch C resides is configured as a stub area, a default route rather than AS
external routes exists in the routing table.
Routing for Network

--------------------------------------------------------------------------------
0.0.0.0/0 2 Inter-area 192.168.1.1 10.1.1.1 0.0.0.1
172.16.1.0/24 1 Direct 172.16.1.1 10.3.3.3

0.0.0.1
172.17.1.0/24 4 Inter-area 192.168.1.1 10.1.1.1

0.0.0.1
192.168.0.0/24 2 Inter-area 192.168.1.1 10.1.1.1

0.0.0.1
192.168.1.0/24 1 Direct 192.168.1.2 10.3.3.3

0.0.0.1
192.168.2.0/24 3 Inter-area 192.168.1.1 10.1.1.1

0.0.0.1
Total Nets: 6
Step 5 # Prevent Switch A from advertising Type 3 LSAs to the stub area.
[~SwitchA] ospf
[*SwitchA-ospf-1-area-0.0.0.1] stub no-summary
[*SwitchA-ospf-1-area-0.0.0.1] commit
[~SwitchA-ospf-1-area-0.0.0.1] quit

# Display the OSPF routing table on Switch C.
Routing for Network

--------------------------------------------------------------------------------
0.0.0.0/0 2 Inter-area 192.168.1.1 10.1.1.1
0.0.0.1
172.16.1.0/24 1 Direct 172.16.1.1 10.3.3.3

0.0.0.1

192.168.1.0/24 1 Direct 192.168.1.2 10.3.3.3

0.0.0.1
Total Nets: 3
NOTE
After the advertisement of summary LSAs to the stub area is disabled, the routing entries on the switch
in the stub area are further reduced, and only the default route to a destination outside the stub area is
reserved.
----End
Configuration Files
#
sysname SwitchA
#
vlan batch 10 20
#
router id 10.1.1.1
#
interface Vlanif10
ip address 192.168.0.1 255.255.255.0
#
interface Vlanif20
ip address 192.168.1.1 255.255.255.0
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
ospf 1
area 0.0.0.0
network 192.168.0.0 0.0.0.255
area 0.0.0.1
network 192.168.1.0 0.0.0.255
stub no-summary
#
return
NOTE
Configuration files of Switch B and Switch F are similar to the configuration file of Switch A, and
are not mentioned here.
#
sysname SwitchC
#
vlan batch 20 40
#
router id 10.3.3.3
#
interface Vlanif20
ip address 192.168.1.2 255.255.255.0
#
interface Vlanif40
ip address 172.16.1.1 255.255.255.0
#
interface 10GE1/0/1

#
interface 10GE1/0/2
#
ospf 1
area 0.0.0.1
network 192.168.1.0 0.0.0.255
network 172.16.1.0 0.0.0.255
stub
#
return

#
sysname SwitchD
#
vlan batch 30 50
#
router id 10.4.4.4
#
interface Vlanif30
ip address 192.168.2.2 255.255.255.0
#
interface Vlanif50
ip address 172.17.1.1 255.255.255.0
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
ospf 1
import-route static type 1
area 0.0.0.2
network 192.168.2.0 0.0.0.255
network 172.17.1.0 0.0.0.255
#
ip route-static 200.0.0.0 255.0.0.0 NULL0
#
return

#
sysname SwitchE
#
vlan batch 40
#
router id 10.5.5.5
#
interface Vlanif40
ip address 172.16.1.2 255.255.255.0
#
interface 10GE1/0/1
#
ospf 1
area 0.0.0.1
network 172.16.1.0 0.0.0.255
stub
#
return

5.23.3 Example for Configuring an NSSA
As shown in Figure 5-27, OSPF is enabled on all Switches and the AS is divided into three
areas. Switch A and Switch B function as ABRs to forward routes between areas; Switch D
functions as the ASBR to import external routes, that is, static routes.
You need to configure Area 1 as an NSSA and configure SwitchC as an ASBR to import
external routes (static routes). The routing information can be transmitted correctly in the AS.
Figure 5-27 Networking diagram for configuring an NSSA
Area0
10GE1/0/1
VLANIF10
192.168.0.2/24
10GE1/0/2 10GE1/0/2
VLANIF10
VLANIF20 VLANIF30
192.168.0.1/24
192.168.1.1/24 192.168.2.1/24
10GE1/0/1 10GE1/0/1
VLANIF20 VLANIF30
192.168.1.2/24 192.168.2.2/24
SwitchC SwitchD
10GE1/0/2 10GE1/0/2
NSSA VLANIF40 VLANIF50
ASBR
172.16.1.1/24 172.17.1.1/24
10GE1/0/1 10GE1/0/1
VLANIF40 VLANIF50
172.16.1.2/24 172.17.1.2/24
SwitchE SwitchF
Area1 Area2
1. Enable OSPF on each Switch and configure the basic OSPF functions.
2. Configure static routes on Switch D and import them into OSPF.
3. Configure Area 1 as an NSSA and check the OSPF routing information of Switch C. You
must run the nssa command on all the devices in Area 1.
4. Configure static routes on Switch C, import them into OSPF, and check the OSPF
routing information of Switch D.

Procedure
Step 1 Configure the VLAN that each interface belongs to.
[*HUAWEI] commit
[~SwitchA] vlan batch 10 20
[*SwitchA] interface 10ge 1/0/1
[*SwitchA-10GE1/0/1] port link-type trunk
[*SwitchA-10GE1/0/1] port trunk allow-pass vlan 10
[*SwitchA-10GE1/0/1] quit
[*SwitchA] commit
The configurations of Switch B, Switch C, Switch D, Switch E, and Switch F are similar to
the configuration of Switch A, and are not mentioned here.
Step 2 Assign an IP address to each VLANIF interface.
[~SwitchA] interface vlanif 10
[*SwitchA-Vlanif10] ip address 192.168.0.1 24
[*SwitchA-Vlanif10] quit
[*SwitchA] interface vlanif 20
[*SwitchA] commit
The configurations of Switch B, Switch C, Switch D, Switch E, and Switch F are similar to
the configuration of Switch A, and are not mentioned here.
Step 3 Configure the basic OSPF functions. See 5.23.1 Example for Configuring Basic OSPF
Functions.
Step 4 Configure Switch D to import static routes. See 5.23.2 Example for Configuring OSPF
Stub Areas.
Step 5 Configure Area 1 as an NSSA.
[~SwitchA] ospf
[*SwitchA-ospf-1-area-0.0.0.1] nssa default-route-advertise no-summary
[*SwitchA-ospf-1] quit
[*SwitchA] commit
[~SwitchC] ospf
[*SwitchC-ospf-1-area-0.0.0.1] nssa
[*SwitchC-ospf-1-area-0.0.0.1] quit
[*SwitchC-ospf-1] quit
[*SwitchC] commit
[~SwitchE] ospf
[*SwitchE-ospf-1-area-0.0.0.1] nssa
[*SwitchE-ospf-1-area-0.0.0.1] quit
[*SwitchE-ospf-1] quit
[*SwitchE] commit

NOTE
The default-route-advertise and no-summary keywords are recommend on the ABR (Switch A). In
this manner, the size of the routing table of devices in an NSSA can be reduced. For the other devices in
the NSSA, you need to run only the nssa command.
# View the OSPF routing table of Switch C.

Routing for Network

-----------------------------------------------------------------------------
0.0.0.0/0 2 Inter-area 192.168.1.1 10.1.1.1 0.0.0.1
172.16.1.0/24 1 Direct 172.16.1.1 10.3.3.3 0.0.0.1
192.168.1.0/24 1 Direct 192.168.1.2 10.3.3.3 0.0.0.1
Total Nets: 3
Step 6 Configure Switch C to import static routes.
# Import static routes on Switch C.

[~SwitchC] ip route-static 100.0.0.0 8 null 0
[*SwitchC] ospf
[*SwitchC-ospf-1] import-route static
[*SwitchC] commit
# View the OSPF routing table of Switch D.

[~SwitchD] display ospf routing
Routing for Network

----------------------------------------------------------------------------
172.16.1.0/24 4 Inter-area 192.168.2.1 10.2.2.2 0.0.0.2
172.17.1.0/24 1 Direct 172.17.1.1 10.4.4.4 0.0.0.2
192.168.0.0/24 2 Inter-area 192.168.2.1 10.2.2.2 0.0.0.2
192.168.1.0/24 3 Inter-area 192.168.2.1 10.2.2.2 0.0.0.2
192.168.2.0/24 1 Direct 192.168.2.2 10.4.4.4 0.0.0.2
Routing for ASEs

-----------------------------------------------------------------------------
Destination Cost Type Tag NextHop AdvRouter
100.0.0.0/8 1 Type2 1 192.168.2.1 10.1.1.1
Total Nets: 6
From the routing table of Switch D, you can find that an AS external route is imported to the
NSSA.
----End

Configuration Files
l Configuration file of SwitchA
#
sysname SwitchA
#
vlan batch 10 20
#
router id 10.1.1.1
#
interface Vlanif10
ip address 192.168.0.1 255.255.255.0
#
interface Vlanif20
ip address 192.168.1.1 255.255.255.0
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
ospf 1
area 0.0.0.0
network 192.168.0.0 0.0.0.255
area 0.0.0.1
network 192.168.1.0 0.0.0.255
nssa default-route-advertise no-summary
#
return
NOTE
Configuration files of Switch B, Switch D, and Switch F are similar to the configuration file of
Switch A, and are not mentioned here.
#
sysname SwitchC
#
vlan batch 20 40
#
router id 10.3.3.3
#
interface Vlanif20
ip address 192.168.1.2 255.255.255.0
#
interface Vlanif40
ip address 172.16.1.1 255.255.255.0
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
ospf 1
import-route static
area 0.0.0.1
network 192.168.1.0 0.0.0.255
network 172.16.1.0 0.0.0.255
nssa
#
ip route-static 100.0.0.0 255.0.0.0 NULL0

#
return

#
sysname SwitchE
#
vlan batch 40
#
router id 10.5.5.5
#
interface Vlanif40
ip address 172.16.1.2 255.255.255.0
#
interface 10GE1/0/1
#
ospf 1
area 0.0.0.1
network 172.16.1.0 0.0.0.255
nssa
#
return
5.23.4 Example for Configuring DR Election of OSPF
As shown in Figure 5-28, Switch A has the highest priority of 100 on the network and is
elected as the DR; Switch C has the highest priority of 2. Switch C has the second highest
priority and is elected as the BDR; The priority of Switch B is 0 and therefore cannot be
elected as a DR or a BDR; the priority of Switch D is not set, so Switch D uses the default
value 1.
Figure 5-28 Networking diagram for configuring DR election of an OSPF process

SwitchA SwitchB
10GE1/0/1 10GE1/0/1
VLANIF10 VLANIF10
192.168.1.1/24 192.168.1.2/24
10GE1/0/1 10GE1/0/1
VLANIF10 VLANIF10
192.168.1.3/24 192.168.1.4/24
SwitchC SwitchD
1. Configure the ID of the VLAN that each interface belongs to.

2. Assign an IP address to each VLANIF interface.

3. Configure the router ID, enable OSPF, and specify network segments on each Switch.
4. Check whether an Switch is the DR or BDR with its default DR priority.
5. Set the DR priority of the interface on each Switch and check whether the Switch
becomes the DR or BDR.
Procedure
Step 1 Configure the VLAN that each interface belongs to.
[*HUAWEI] commit
[~SwitchA] vlan 10
[*SwitchA-vlan10] quit
[*SwitchA] commit
The configurations of Switch B, Switch C, and Switch D are similar to the configuration of

[*SwitchA-Vlanif10] commit
[~SwitchA-Vlanif10] quit
Step 3 Configure the basic OSPF functions.
[~SwitchA] router id 10.1.1.1
[*SwitchA] ospf
[*SwitchA] commit
# Configure SwitchB.
[~SwitchB] router id 10.2.2.2
[*SwitchB] ospf
[*SwitchB-ospf-1] quit
[*SwitchB] commit
[~SwitchC] router id 10.3.3.3
[*SwitchC] ospf
[*SwitchC-ospf-1-area-0.0.0.0] quit
[*SwitchC] commit

# Configure Switch D.
[~SwitchD] router id 10.4.4.4
[*SwitchD] ospf
[*SwitchD-ospf-1] area 0
[*SwitchD-ospf-1-area-0.0.0.0] quit
[*SwitchD-ospf-1] quit
[*SwitchD] commit
# Check information about neighbors of Switch A to find the DR and BDR.

[~SwitchA] display ospf peer

Router ID: 10.2.2.2 Address: 192.168.1.2 GR State: Normal
State: Full Mode:Nbr is Master Priority: 1
DR: 192.168.1.4 BDR: 192.168.1.3 MTU: 0
Dead timer due in 32 sec
Neighbor is up for 00:00:00
Authentication Sequence: [~ 0 ]

DR: 192.168.1.4 BDR: 192.168.1.3 MTU: 0

DR: 192.168.1.4 BDR: 192.168.1.3 MTU: 0
Check the neighbors of Switch A. You can view the DR priority and the neighbor status. By
default, the DR priority is 1. Now Switch D functions as the DR and Switch C functions as
the BDR.
NOTE
When the priority is the same, the switch with a higher router ID is elected as the DR. If a new switch is
added after the DR/BDR election is complete, the new switch cannot become the DR even if it has the
highest priority.
Step 4 Set the DR priority on each VLANIF interface.

[~SwitchA] interface Vlanif 10
[~SwitchA-Vlanif10] ospf dr-priority 100
[*SwitchA] commit
Configure SwitchB.
[~SwitchB] interface Vlanif 10
[~SwitchB-Vlanif10] ospf dr-priority 0
[*SwitchB-Vlanif10] quit
[*SwitchB] commit
[~SwitchC] interface Vlanif 10
[~SwitchC-Vlanif10] ospf dr-priority 2
[*SwitchC-Vlanif10] quit
[*SwitchC] commit

# Check the status of the DR or BDR.

[~SwitchD] display ospf peer

State: Full Mode:Nbr is Slave Priority: 100
DR: 192.168.1.4 BDR: 192.168.1.3 MTU: 0

DR: 192.168.1.4 BDR: 192.168.1.3 MTU: 0

DR: 192.168.1.4 BDR: 192.168.1.3 MTU: 0
NOTE
The DR priorities configured on the interfaces do not take effect immediately.
Step 5 Restart the OSPF process.

In the user view of each Switch, run the reset ospf 1 process command to restart the OSPF
process.
# Check the status of OSPF neighbors.
[~SwitchD] display ospf peer

DR: 192.168.1.1 BDR: 192.168.1.3 MTU: 0

DR: 192.168.1.1 BDR: 192.168.1.3 MTU: 0

DR: 192.168.1.1 BDR: 192.168.1.3 MTU: 0
# Check the status of OSPF interfaces.

[~SwitchA] display ospf interface

Area: 0.0.0.0 (MPLS TE not enabled)
Interface IP Address Type State Cost Pri

Vlanif10 192.168.1.1 Broadcast DR 1 1
[~SwitchB] display ospf interface
Area: 0.0.0.0 (MPLS TE not enabled)
Interface IP Address Type State Cost Pri

Vlanif10 192.168.1.2 Broadcast DROther 1 0
If all neighbors are in Full state, it indicates that the local device establishes adjacencies with
all its neighbors. If a neighbor stays in 2-Way state, it indicates the local Switch and the
neighbor are not the DR or BDR. Therefore, they do not need to exchange LSAs.
If the status of an OSPF interface is DROther, it indicates that the router is neither the DR nor
the BDR.
----End
Configuration Files
#
sysname SwitchA
#
vlan batch 10
#
router id 10.1.1.1
#
interface Vlanif10
ip address 192.168.1.1 255.255.255.0
ospf dr-priority 100
#
interface 10GE1/0/1
#
ospf 1
area 0.0.0.0
network 192.168.1.0 0.0.0.255
#
return

#
sysname SwitchB
#
vlan batch 10
#
router id 10.2.2.2
#
interface Vlanif10
ip address 192.168.1.2 255.255.255.0
ospf dr-priority 0
#
interface 10GE1/0/1
#
ospf 1
area 0.0.0.0
network 192.168.1.0 0.0.0.255

#
return

#
sysname SwitchC
#
vlan batch 10
#
router id 10.3.3.3
#
interface Vlanif10
ip address 192.168.1.3 255.255.255.0
ospf dr-priority 2
#
interface 10GE1/0/1
#
ospf 1
area 0.0.0.0
network 192.168.1.0 0.0.0.255
#
return

#
sysname SwitchD
#
vlan batch 10
#
router id 10.4.4.4
#
interface Vlanif10
ip address 192.168.1.4 255.255.255.0
#
interface 10GE1/0/1
#
ospf 1
area 0.0.0.0
network 192.168.1.0 0.0.0.255
#
return
5.23.5 Example for Configuring Load Balancing Among OSPF

Routes
As shown in Figure 5-29, the networking requirements are as follows:
l Switch A, Switch B, Switch C, and Switch D connect to each other through OSPF.
l Switch A, Switch B, Switch C, and Switch D belong to Area 0.
l Load balancing needs is configured so that the traffic of Switch A can be sent to Switch
D through Switch B and Switch C.

Figure 5-29 Networking diagram for configuring load balancing among OSPF routes
SwitchC
10GE1/0/1 10GE1/0/2
VLANIF10 VLANIF30
10.1.1.2/24 192.168.0.1/24
10GE1/0/1 10GE1/0/1
VLANIF10 VLANIF30
10GE1/0/3 10.1.1.1/24
VLANIF50 192.168.0.2/24
172.16.1.1/24
SwitchA SwitchD
10GE1/0/3
10GE1/0/2 10GE1/0/2 VLANIF60
VLANIF20 VLANIF40 172.16.2.1/24
10.1.2.1/24 192.168.1.2/24
10GE1/0/1 10GE1/0/2
VLANIF20 VLANIF40
10.1.2.2/24 192.168.1.1/24
SwitchB
1. Configure basic OSPF functions on each Switch to implement interconnection.
2. Disable load balancing on Switch A and check the routing table of Switch A.
3. (Optional) Set the weight of equal-cost routes on Switch A.
Procedure
Step 1 Configure VLANs that the related interfaces belong to.
[*HUAWEI] commit
[~SwitchA] vlan batch 10 20 50
[*SwitchA] commit

[*SwitchA] commit
Functions.
Step 4 Disable load balancing on Switch A.

[~SwitchA] ospf
[*SwitchA-ospf-1] maximum load-balancing 1
[*SwitchA] commit
# View the routing table of Switch A.

[~SwitchA] display ip routing-table
Proto: Protocol Pre: Preference
Route Flags: R - relay, D - download
to fib, T - to vpn-instance, B - black hole route
------------------------------------------------------------------------------
Routing Table: _public_
Destinations : 16 Routes : 16
Destination/Mask Proto Pre Cost Flags NextHop Interface
10.1.1.0/24 Direct 0 0 D 10.1.1.1 Vlanif10

10.1.1.1/32 Direct 0 0 D 127.0.0.1 Vlanif10
10.1.1.255/32 Direct 0 0 D 127.0.0.1 Vlanif10
10.1.2.0/24 Direct 0 0 D 10.1.2.1 Vlanif20
10.1.2.1/32 Direct 0 0 D 127.0.0.1 Vlanif20
10.1.2.255/32 Direct 0 0 D 127.0.0.1 Vlanif20
127.0.0.0/8 Direct 0 0 D 127.0.0.1 InLoopBack0
172.16.1.0/24 Direct 0 0 D 172.16.1.1 Vlanif50
172.16.1.1/32 Direct 0 0 D 127.0.0.1 Vlanif50
172.16.1.255/32 Direct 0 0 D 127.0.0.1 Vlanif50
172.16.2.0/24 OSPF 10 3 D 10.1.1.2 Vlanif10
192.168.0.0/24 OSPF 10 2 D 10.1.1.2 Vlanif10
192.168.1.0/24 OSPF 10 2 D 10.1.2.2 Vlanif20
As shown in the routing table, when the maximum number of equal-cost routes for load
balancing is set to 1, OSPF selects 10.1.1.2 as the next hop to the destination network
172.16.2.0.
NOTE
In the preceding example, 10.1.1.2 is selected as the optimal next hop. This is because OSPF selects the
next hop randomly among equal-cost routes.
Step 5 Restore the default number of equal-cost routes for load balancing on Switch A.
[~SwitchA] ospf
[*SwitchA-ospf-1] undo maximum load-balancing
[*SwitchA] commit
# View the routing table of SwitchA.


----------------------------------------------------------------------------
10.1.1.0/24 Direct 0 0 D 10.1.1.1 Vlanif10

10.1.1.1/32 Direct 0 0 D 127.0.0.1 Vlanif10
10.1.1.255/32 Direct 0 0 D 127.0.0.1 Vlanif10
10.1.2.0/24 Direct 0 0 D 10.1.2.1 Vlanif20
10.1.2.1/32 Direct 0 0 D 127.0.0.1 Vlanif20
10.1.2.255/32 Direct 0 0 D 127.0.0.1 Vlanif20
172.16.1.0/24 Direct 0 0 D 172.16.1.1 Vlanif50
172.16.1.1/32 Direct 0 0 D 127.0.0.1 Vlanif50
172.16.1.255/32 Direct 0 0 D 127.0.0.1 Vlanif50
172.16.2.0/24 OSPF 10 3 D 10.1.1.2 Vlanif10
OSPF 10 3 D 10.1.2.2 Vlanif20
192.168.0.0/24 OSPF 10 2 D 10.1.1.2 Vlanif10
192.168.1.0/24 OSPF 10 2 D 10.1.2.2 Vlanif20
As shown in the routing table, when the default setting of load balancing is restored, the next
hops of Switch A, that is, 10.1.1.2 and 10.1.2.2, become valid routes. This is because the
default number of equal-cost routes is 32.
Step 6 (Optional) Set the weight of equal-cost routes on Switch A.
If you do not want to implement load balancing between Switch B and Switch C, set the
weight of equal-cost routes to specify the next hop.
[~SwitchA] ospf
[~SwitchA-ospf-1] nexthop 10.1.2.2 weight 1
[*SwitchA] commit

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

10.1.1.0/24 Direct 0 0 D 10.1.1.1 Vlanif10
10.1.1.1/32 Direct 0 0 D 127.0.0.1 Vlanif10
10.1.1.255/32 Direct 0 0 D 127.0.0.1 Vlanif10
10.1.2.0/24 Direct 0 0 D 10.1.2.1 Vlanif20
10.1.2.1/32 Direct 0 0 D 127.0.0.1 Vlanif20
10.1.2.255/32 Direct 0 0 D 127.0.0.1 Vlanif20
172.16.1.0/24 Direct 0 0 D 172.16.1.1 Vlanif50
172.16.1.1/32 Direct 0 0 D 127.0.0.1 Vlanif50
172.16.1.255/32 Direct 0 0 D 127.0.0.1 Vlanif50
172.16.2.0/24 OSPF 10 3 D 10.1.2.2 Vlanif20
192.168.0.0/24 OSPF 10 2 D 10.1.1.2 Vlanif10
192.168.1.0/24 OSPF 10 2 D 10.1.2.2 Vlanif20

As shown in the routing table, the priority of the next hop 10.1.2.2 with the weight as 1 is
higher than that of 10.1.1.2, after the weight is set for equal-cost routes. Therefore, OSPF
selects the route with the next hop 10.1.2.2 as the optimal route.
----End
Configuration Files
#
sysname SwitchA
#
vlan batch 10 20 50
#
interface Vlanif10
ip address 10.1.1.1 255.255.255.0
#
interface Vlanif20
ip address 10.1.2.1 255.255.255.0
#
interface Vlanif50
ip address 172.16.1.1 255.255.255.0
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
interface 10GE1/0/3
#
ospf 1 router-id 10.10.10.1
nexthop 10.1.2.2 weight 1
area 0.0.0.0
network 10.1.1.0 0.0.0.255
network 10.1.2.0 0.0.0.255
network 172.16.1.0 0.0.0.255
#
return

#
sysname SwitchB
#
vlan batch 20 40
#
interface Vlanif20
ip address 10.1.2.2 255.255.255.0
#
interface Vlanif40
ip address 192.168.1.1 255.255.255.0
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
area 0.0.0.0
network 10.1.2.0 0.0.0.255

network 192.168.1.0 0.0.0.255

#
return

sysname SwitchC
#
vlan batch 10 30
#
interface Vlanif10
ip address 10.1.1.2 255.255.255.0
#
interface Vlanif30
ip address 192.168.0.1 255.255.255.0
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
area 0.0.0.0
network 10.1.1.0 0.0.0.255
network 192.168.0.0 0.0.0.255
#
return

#
sysname SwitchD
#
vlan batch 30 40 60
#
interface Vlanif30
ip address 192.168.0.2 255.255.255.0
#
interface Vlanif40
ip address 192.168.1.2 255.255.255.0
#
interface Vlanif60
ip address 172.16.2.1 255.255.255.0
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
interface 10GE1/0/3
#
area 0.0.0.0
network 192.168.0.0 0.0.0.255
network 192.168.1.0 0.0.0.255
network 172.16.2.0 0.0.0.255
#
return
5.23.6 Example for Configuring OSPF IP FRR

When a fault occurs on the primary link T, traffic is switched to a backup link. In such a
scenario, two problems arise:
l It takes hundreds of milliseconds for the traffic to be switched to a backup link during
OSPF fault restoration. During this period, services are interrupted.
l Traffic will pass Switch A after link switching. Switch A is an ASBR and is not expected
to function as a backup device.
When a fault occurs on the network, OSPF IP FRR can fast switch traffic to the backup link
without waiting for route convergence. This ensures uninterrupted traffic transmission. In
addition, you can also configure Switch A to detour around the backup link.
As shown in Figure 5-30:

l All switches run OSPF.
l The link cost meets the OSPF IP FRR traffic protection inequality.
l When the primary link T fails, Switch S immediately switches traffic to the backup link.
Thus, the traffic is forwarded through Switch N.
l Based on the network planning, the link where Switch A resides does not function as an
FRR backup link.
Figure 5-30 Networking diagram for configuring OSPF IP FRR
IS-IS
Network
OSPF Network
Area0
10GE1/0/1 10GE1/0/2
c
10 os
t= t=
s SwitchA 15
co OSPF
10GE1/0/1 ASBR 10GE1/0/1 Network
10GE1/0/2 LinkT 10GE1/0/2 cost = 5
10GE1/0/3 10GE1/0/3 10GE1/0/4
SwitchS c cost = 15 SwitchE SwitchD
os 0
t=1 s t=1 Area1
0 co
10GE1/0/1 10GE1/0/2
SwitchN
Table 5-21 Data preparation

Switch Router ID Interface VLANIF IP address
interface
SwitchS 10.10.10.1 10GE1/0/1 VLANIF 10 10.1.1.1/24
10GE1/0/2 VLANIF 20 10.1.2.1/24

Switch Router ID Interface VLANIF IP address

interface
10GE1/0/3 VLANIF 30 10.1.3.1/24
SwitchA 10.10.10.2 10GE1/0/1 VLANIF 10 10.1.1.2/24
10GE1/0/2 VLANIF 40 10.20.1.2/24
SwitchN 10.10.10.3 10GE1/0/1 VLANIF 30 10.1.3.2/24
10GE1/0/2 VLANIF 60 10.20.3.2/24
SwitchE 10.10.10.4 10GE1/0/1 VLANIF 40 10.20.1.1/24
10GE1/0/2 VLANIF 20 10.1.2.2/24
10GE1/0/3 VLANIF 60 10.20.3.1/24
10GE1/0/4 VLANIF 70 172.17.1.1/24
Configuration Notes
When configuring OSPF IP FRR, note the following points:
Before configuring OSPF IP FRR, you need to block FRR on the interface that is not
expected to be an interface of a backup link. After that, the link where the interface resides is
not calculated as a backup link during FRR calculation.
During the configuration of OSPF IP FRR, the lower layer needs to fast respond to a link
change so that traffic can be rapidly switched to the backup link. After the bfd all-interfaces
frr-binding command is run, the BFD session status is associated with the link status of an
interface (when the BFD session goes Down, the link status of the interface becomes Down)
so that link faults can be rapidly detected.
1. Configure basic OSPF functions on each switch.
2. Configure BFD for OSPF on all the devices in Area 0.
3. Set the costs of links to ensure that link T is preferred to transmit traffic.
4. Block FRR on a specified interface of Switch S.
5. Enable OSPF IP FRR on Switch S to protect the traffic forwarded by Switch S.
Procedure
Step 1 Assign an IP address to each interface. The configuration details are not mentioned here.
Step 2 Configure basic OSPF functions. For details, see 5.23.1 Example for Configuring Basic
OSPF Functions.
Step 3 Configure BFD for OSPF on all the devices in Area 0. For details, see 5.23.7 Example for
Configuring BFD for OSPF.

Step 4 Set the costs of links to ensure that link T is preferred to transmit traffic.
# Configure Switch S.
[~SwitchS] interface vlanif 10
[*SwitchS-Vlanif10] ospf cost 10
[*SwitchS-Vlanif10] quit
[*SwitchS] interface vlanif 20
[*SwitchS] interface vlanif 30
[*SwitchS] commit
[*SwitchA-Vlanif40] ospf cost 15
[*SwitchA-Vlanif10] ospf cost 10
[*SwitchA] commit
# Configure Switch N.
[~SwitchN] interface vlanif 30
[*SwitchN-Vlanif30] ospf cost 10
[*SwitchN-Vlanif30] quit
[*SwitchN] interface vlanif 60
[*SwitchN-Vlanif60] ospf cost 10
[*SwitchN-Vlanif60] quit
[*SwitchN] commit
[~SwitchE] interface vlanif 20
[*SwitchE-Vlanif20] ospf cost 15
[*SwitchE-Vlanif20] quit
[*SwitchE] interface vlanif 40
[*SwitchE] commit
Step 5 Block FRR on a specified interface of Switch S.

[~SwitchS] interface vlanif 10
[~SwitchS-Vlanif10] ospf frr block
[*SwitchS] commit
Step 6 Enable OSPF IP FRR on Switch S.

[~SwitchS] ospf
[*SwitchS-ospf-1] frr
[*SwitchS-ospf-1-frr] loop-free-alternate
[*SwitchS-ospf-1-frr] commit
# Run the display ospf routing router-id command on Switch S to view routing information.
[~SwitchS-ospf-1-frr] display ospf routing 172.17.1.1

Flags: A - Added to URT, S - Secondary route
Destination :
10.10.10.4/32
AdverRouter : 10.10.10.4 Area :

0.0.0.0
Cost : 3 Type :
Stub
NextHop : 10.1.2.2 Interface :
Vlanif20
Priority :
Low
Backup NextHop : 10.1.3.2 Backup Interface :

Vlanif30
Backup Type : LFA LINK-
NODE
Flags : A/-
The preceding display shows that a backup route is generated on Switch S.
----End
Configuration Files
l Configuration file of Switch S
#
sysname SwitchS
#
vlan batch 10 20 30
#
bfd
#
interface Vlanif10
ip address 10.1.1.1 255.255.255.0
ospf cost 10
ospf frr block
#
interface Vlanif20
ip address 10.1.2.1 255.255.255.0
ospf cost 15
#
interface Vlanif30
ip address 10.1.3.1 255.255.255.0
ospf cost 10
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
interface 10GE1/0/3
#
bfd all-interfaces frr-binding
frr
loop-free-alternate

area 0.0.0.0
network 10.1.1.0 0.0.0.255
network 10.1.2.0 0.0.0.255
network 10.1.3.0 0.0.0.255
#
return
#
sysname SwitchA
#
vlan batch 10 40
#
bfd
#
interface Vlanif10
ip address 10.1.1.2 255.255.255.0
ospf cost 10
#
interface Vlanif40
ip address 20.1.1.2 255.255.255.0
ospf cost 15
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
area 0.0.0.0
network 10.1.1.0 0.0.0.255
network 20.1.1.0 0.0.0.255
#
return
l Configuration file of Switch N
#
sysname SwitchN
#
vlan batch 30 60
#
bfd
#
interface Vlanif30
ip address 10.1.3.2 255.255.255.0
ospf cost 10
#
interface Vlanif60
ip address 20.1.3.2 255.255.255.0
ospf cost 10
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
frr
area 0.0.0.0
network 10.1.3.0 0.0.0.255

network 20.1.3.0 0.0.0.255

#
return

#
sysname SwitchE
#
vlan batch 20 40 60 70
#
bfd
#
interface Vlanif20
ip address 10.1.2.2 255.255.255.0
ospf cost 15
#
interface Vlanif40
ip address 20.1.1.1 255.255.255.0
ospf cost 15
#
interface Vlanif60
ip address 20.1.3.1 255.255.255.0
ospf cost 10
#
interface Vlanif70
ip address 172.17.1.1 255.255.255.0
ospf cost 5
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
interface 10GE1/0/3
#
interface 10GE1/0/4
#
area 0.0.0.0
network 10.1.2.0 0.0.0.255
network 20.1.1.0 0.0.0.255
network 20.1.3.0 0.0.0.255
network 172.17.1.0 0.0.0.255
#
return
5.23.7 Example for Configuring BFD for OSPF
As shown in Figure 5-31, the networking requirements are as follows:
l Switch A, Switch B, and Switch C run OSPF.

l BFD for OSPF is enabled on Switch A, Switch B, and Switch C.
l Service traffic is transmitted on the main link Switch A→Switch B. Link Switch
A→Switch C→Switch B is a backup link.

l BFD is configured on the interfaces between Switch A and Switch B. When a fault
occurs on the link between the Switch s, BFD can quickly detect the fault and notify
OSPF of the fault. Then, the service flow is transmitted on the backup link.
Figure 5-31 Networking diagram for configuring BFD for OSPF
10GE1/0/3
SwitchA SwitchBVLANIF40
172.16.1.1/24
10GE1/0/2 10GE1/0/2
10GE1/0/1 VLANIF20 VLANIF20 10GE1/0/1
VLANIF10 10.3.3.1/24 10.3.3.2/24 VLANIF30
10.1.1.1/24 10.2.2.2/24
10GE1/0/1 10GE1/0/2
VLANIF10 VLANIF30 Area0
10.1.1.2/24 10.2.2.1/24
SwitchC
1. Configure the basic OSPF functions on the switches.

2. Enable the BFD feature globally.
3. Enable BFD for OSPF on Switch A and Switch B.
Procedure
Step 1 Create VLANs and add corresponding interfaces to the VLANs.
[*HUAWEI] commit
[~SwitchA] vlan 10
[*SwitchA] vlan 20
[*SwitchA] commit
The configurations of Switch B and Switch C are similar to the configuration of Switch A,
and are not mentioned here.


[*SwitchA] commit
The configurations of Switch B and Switch C are similar to the configuration of Switch A,
and are not mentioned here.
Functions.
Step 4 Configure BFD for OSPF.
# Enable BFD globally on Switch A.

[~SwitchA] bfd
[*SwitchA-bfd] quit
[*SwitchA] ospf
[*SwitchA-ospf-1] bfd all-interfaces enable
[*SwitchA] commit
# Enable BFD globally on Switch B.

[~SwitchB] bfd
[*SwitchB-bfd] quit
[*SwitchB] ospf
[*SwitchB-ospf-1] bfd all-interfaces enable
[*SwitchB-ospf-1] quit
[*SwitchB] commit
# Run the display ospf bfd session all command on Switch A or Switch B. You can see that
the BFD state is Up.
Take Switch A for example. The display is as follows:

[~SwitchA] display ospf bfd session all
Area 0.0.0.0 interface 10.3.3.1(Vlanif20)'s BFD Sessions
NeighborId:10.10.10.2 AreaId:0.0.0.0
Interface:Vlanif20
BFDState:Up rx :1000 tx :
1000
Multiplier:3 BFD Local Dis:16385 LocalIpAdd:
10.3.3.1
RemoteIpAdd:10.3.3.2 Diagnostic Info:No diagnostic
information
Interface:Vlanif10
1000
10.1.1.1
information
Total UP/DOWN/UNKNOWN BFD Session Number : 2 / 0 / 0
Step 5 Configure the BFD feature of interfaces.

# Configure BFD on VLANIF 20 of Switch A, set the minimum interval for sending the
packets and the minimum interval for receiving the packets to 100 ms, and set the local
detection time multiplier to 4.
[*SwitchA-Vlanif20] ospf bfd enable
[*SwitchA-Vlanif20] ospf bfd min-tx-interval 100 min-rx-interval 100 detect-
multiplier 4
[*SwitchA] commit
# Configure BFD on VLANIF20 of Switch B and set the minimum interval for sending the
packets and the minimum interval for receiving the packets to 100 ms and the local detection
time multiplier to 4.
[*SwitchB] interface vlanif 20
[*SwitchB-Vlanif20] ospf bfd enable
[*SwitchB-Vlanif20] ospf bfd min-tx-interval 100 min-rx-interval 100 detect-
multiplier 4
[*SwitchB-Vlanif20] quit
[*SwitchB] commit
# Run the display ospf bfd session all command on Switch A or Switch B. You can check
that the minimum intervals at which packets are sent and received are 100 ms and that the
local detection multiplier is 4.
Take Switch B for example. The display is as follows:
[~SwitchB] display ospf bfd session all

Interface:Vlanif20
100
10.3.3.2
information
Interface:Vlanif30
100
10.2.2.2
information
Total UP/DOWN/UNKNOWN BFD Session Number : 2 / 0 / 0

# Run the shutdown command on VLANIF 20 of Switch B to simulate a link fault.
[~SwitchB] interface vlanif 20
[~SwitchB-Vlanif20] shutdown
[*SwitchB-Vlanif20] commit

[~SwitchA] display ospf routing

Routing for Network

172.16.1.0/24 3 Stub 10.1.1.2 10.10.10.2 0.0.0.0
10.3.3.0/24 1 Stub 10.3.3.1 10.10.10.1 0.0.0.0
10.2.2.0/24 2 Transit 10.1.1.2 10.10.10.3 0.0.0.0
10.1.1.0/24 1 Transit 10.1.1.1 10.10.10.1 0.0.0.0
Total Nets: 4 Intra Area: 4 Inter Area: 0 ASE: 0 NSSA: 0
As shown in the OSPF routing table, the backup link Switch A→Switch C→Switch B takes
effect after the main link fails. The next hop address of the route to 172.16.1.0/24 becomes
10.1.1.2.
----End
Configuration Files
#
sysname SwitchA
#
vlan batch 10 20
#
router id 10.10.10.1
#
bfd
#
interface Vlanif10
ip address 10.1.1.1 255.255.255.0
#
interface Vlanif20
ip address 10.3.3.1 255.255.255.0
ospf bfd enable
ospf bfd min-tx-interval 100 min-rx-interval 100 detect-multiplier 4
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
ospf 1
bfd all-interface enable
area 0.0.0.0
network 10.3.3.0 0.0.0.255
network 10.1.1.0 0.0.0.255
#
return

#
sysname SwitchB
#
vlan batch 20 30 40
#
#
bfd
#
interface Vlanif20
ip address 10.3.3.2 255.255.255.0
ospf bfd enable
ospf bfd min-tx-interval 100 min-rx-interval 100 detect-multiplier 4
#

interface Vlanif30
ip address 10.2.2.2 255.255.255.0
#
interface Vlanif40
ip address 172.16.1.1 255.255.255.0
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
interface 10GE1/0/3
#
ospf 1
area 0.0.0.0
network 10.3.3.0 0.0.0.255
network 10.2.2.0 0.0.0.255
network 172.16.1.0 0.0.0.255
#
return

#
sysname SwitchC
#
vlan batch 10 30
#
#
bfd
#
interface Vlanif10
ip address 10.1.1.2 255.255.255.0
#
interface Vlanif30
ip address 10.2.2.1 255.255.255.0
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
ospf 1
area 0.0.0.0
network 10.1.1.0 0.0.0.255
network 10.2.2.0 0.0.0.255
#
return
5.24 Common Misconfigurations

5.24.1 OSPF Neighbor Relationship Cannot Be Established
Fault Symptom
OSPF neighbor relationship cannot be established between two devices.
Procedure
Step 1 Check whether the physical status and protocol status of interfaces on both ends are Up and
stable, whether packets are lost on the interfaces, and whether the two devices can ping each
other with large packets.
If the physical status of the interfaces is not Up or unstable (interfaces flap for example),
check the physical link and link layer protocol and ensure that the physical status and protocol
status of the interfaces are Up and the interfaces have no error packet statistics.
You can perform a ping test for a long time to check whether packets are lost on the interfaces
and ping with large packets (longer than 1500 bytes) to check whether the two devices can
ping each other with large packets.
Step 2 Check whether the two devices have the same OSPF process router ID.
Run the display ospf [ process-id ] brief command on the two devices to check the OSPF
process router ID.
Each router ID in an OSPF process must be unique. Otherwise, devices on both ends cannot
establish OSPF neighbor relationships and routing information will be incorrect. You need to
configure a unique router ID for each OSPF process on the devices.
If the two devices have the same OSPF process router ID, run the ospf [ process-id ] router-
id router-id command in the system view to change the OSPF process router ID and ensure
that the two devices have different OSPF process router IDs.
After changing the OSPF process router ID, you must run the reset ospf [ process-id ]
process command in the user view to make the configured router ID take effect.
Step 3 Check whether the two devices have the same OSPF area ID.
Run the display ospf [ process-id ] brief command on the two devices to check the OSPF
area ID.
If the two devices have different OSPF area IDs, run the area area-id command in the OSPF
view to change the OSPF area ID and ensure that the two devices have the same OSPF area
ID.
Step 4 Check whether OSPF interfaces on both ends have the same network type.
Run the display ospf [ process-id ] interface command on the two devices to check the OSPF
interface network type.
The network types of the OSPF interfaces on both ends of a link must be the same; otherwise,
the two interfaces cannot establish an OSPF neighbor relationship.
If the network types of the two OSPF interfaces are different, run the ospf network-type
{ broadcast | nbma | p2mp | p2p } command in the OSPF interface view to change the OSPF
interface network type and ensure that the two OSPF interfaces have the same network type.

NOTE
If the network types of OSPF interfaces on both ends are both NBMA, you must run the peer ip-address
[ dr-priority priority ] command in the OSPF view to configure NBMA neighbors.
Step 5 Check whether OSPF interfaces on both ends have the same IP address mask.
Run the display current-configuration interface interface-type interface-number command

on the two devices to check the IP address of the specified OSPF interface.
The IP address masks of the OSPF interfaces on both ends of a link must be the same;
otherwise, the two interfaces cannot establish an OSPF neighbor relationship. On a P2MP
network, however, you can run the ospf p2mp-mask-ignore command in the OSPF interface
view to disable a device from checking the network mask so that an OSPF neighbor
relationship can be established.
If the two OSPF interfaces have different IP address masks, run the ip address ip-address
{ mask | mask-length } command in the OSPF interface view to change the IP address mask
and ensure that the two OSPF interfaces have the same IP address mask.
Step 6 Check whether IP addresses of OSPF interfaces on both ends belong to the network segment
specified by the network command.
Run the display current-configuration interface interface-type interface-number command

on devices on both ends to check IP addresses of OSPF interfaces on both ends and run the
display current-configuration configuration ospf command on the two devices to check the
OSPF process configuration.
OSPF can run on an interface only when the following conditions are met:
l The mask length of the IP address of the interface is longer than or equal to that specified
by the network command. OSPF uses reverse mask. For example 0.0.0.255 indicates
that the mask length is 24 bits.
l The primary IP address of the interface belongs to the network segment specified by the
network command.
If the IP address of the interface does not meet the preceding conditions, run the ip address
ip-address { mask | mask-length } command in the OSPF-enabled interface view to change
the IP address of the interface or run the network command in the view of the area that the
OSPF process belongs to change the configured network segment so that the IP address of the
interface can meet the preceding conditions.
Step 7 Check whether the DR priorities of OSPF interfaces on both ends are both 0.
Run the display ospf [ process-id ] interface command on the two devices to check the OSPF
interface DR priority.
On a broadcast or NBMA network, there must be at least one OSPF interface of which the DR
priority is not 0 to ensure that the DR can be elected. Otherwise, the neighbor status of
devices on both ends can be only 2-Way.
If the DR priorities of the two OSPF interfaces are both 0, run the ospf dr-priority priority
command in the OSPF interface view to change the DR priority and ensure that there is at
least one OSPF interface of which the DR priority is not 0.
Step 8 Run:
commit

----End
5.24.2 OSPF Cannot Find Routes of a Non-Local Area

Symptom
When the link is normal, OSPF cannot find routes of a non-local area.
Procedure
Step 1 Check whether the area where the device resides is connected to the backbone area.
Run the display ospf [ process-id ] brief command on the ABR in the area where the device
resides to check area configuration.
OSPF requires that all non-backbone areas remain connected to the backbone area.
If no backbone area information is configured on the ABR, run the area area-id command in
the OSPF view to modify the OSPF area information. Ensure that at least one interface on the
ABR runs in the backbone area.
NOTE
If some non-backbone areas cannot be connected to the backbone area due to networking restrictions,
configure OSPF virtual links to resolve this problem.
Step 2 Check whether the area where the device resides is a totally stub area.
Run the display current-configuration configuration ospf [ process-id ] command on the
device to check the OSPF process configuration.
If you specify the parameter no-summary (run the stub no-summary command in the OSPF
area view) when configuring a non-backbone area as a stub area on the ABR, the area is
configured as a totally stub area.
A totally stub area allows only intra-area routes to be advertised within the area.
If the area where the device resides is configured as a totally stub area, perform the following
configuration based on service requirements:
l To restore the totally stub area to a common area, run the undo stub command in the
OSPF area view on all devices in the area.
l To restore a totally stub area to a stub area, run the undo stub command in the OSPF
area view on the ABR in the area and then run the stub command.
Step 3 Check whether the area where the device resides is a totally NSSA.
Run the display current-configuration configuration ospf [ process-id ] command on the
device to check the OSPF process configuration.
If you specify the parameter no-summary (run the nssa no-summary command in the OSPF
area view) when configuring a non-backbone area as an NSSA on the ABR, the area is
configured as a totally NSSA.
A totally NSSA allows only intra-area routes to be advertised within the area.
If the area where the device resides is configured as a totally NSSA, perform the following
configuration based on service requirements:

l To restore the totally NSSA to a common area, run the undo nssa command in the OSPF
area view on all devices in the area.
l To restore a totally NSSA to a stub area, run the undo nssa command in the OSPF area
view on the ABR in the area and then run the nssa command.
----End
5.25 References
This section lists references of OSPF.
The following table lists the references that apply in this chapter.
Document Description Remarks
RFC 1587 This document describes a new optional type of -

OSPF area, referred to humorously as a "not-so-
stubby" area (or NSSA). NSSAs are similar to
the existing OSPF stub area configuration
option, but have the additional capability to
import AS external routes on a limited basis.
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 might be unable to store the
entire database due to resource shortages. This
condition is called "database overflow".
RFC 2328 This memo documents version 2 of the OSPF -

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 future extensibility of OSPF.
RFC 3137 This memo describes a backward-compatible This RFC is

technique that can 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 router.
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.

Document Description Remarks
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 This document describes the use of a packets This RFC is
Time to Live (TTL) (IPv4) or Hop Limit (IPv6) experimental and
to protect a protocol stack from CPU-utilization non-standard.
based attacks, which has been 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 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 Internet
networks. In particular, it defines objects to
manage version 2 of the Open Shortest Path First
Routing Protocol. Version 2 of the OSPF
protocol is specific to the IPv4 address family.


HUAWEI - OSPF Configuration

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

HUAWEI - OSPF Configuration

Uploaded by

Copyright:

Available Formats

CloudEngine 8800&7800&6800&5800 Series Switches

Configuration Guide - IP Unicast Routing 5 OSPF Configuration

5.1 Introduction to OSPF

5.2.1 Fundamentals of OSPF

Issue 06 (2017-09-12) Huawei Proprietary and Confidential 179

OSPF has the following functions:

l Divides an Autonomous System (AS) into one or multiple logical areas.

Table 5-1 packet type

Packet Type Function

Hello packet Sent periodically to discover and maintain OSPF

Link State Acknowledgement Acknowledges the receipt of an LSA.

Table 5-2 LSA type

LSA Type Function

Network-summary-LSA Describes routes to a specific network segment in an area.

Issue 06 (2017-09-12) Huawei Proprietary and Confidential 180

LSA Type Function

ASBR-summary-LSA Describes routes to an Autonomous System Boundary

AS-external-LSA (Type 5) Describes routes to a destination outside the AS. AS-

NSSA-LSA (Type7) Describes routes to a destination outside the AS. Generated

Opaque-LSA (Type 9/Type Provides a universal mechanism for OSPF extension.

Figure 5-1 Router type

Internal Router Backbone Router

Area2 ABR Area3

Issue 06 (2017-09-12) Huawei Proprietary and Confidential 181

Table 5-3 Router type

Internal router All interfaces on an internal router belong to the same

Backbone router At least one interface on a backbone router belongs to the

Table 5-4 route type

Intra-area route Indicates routes within an area.

Inter-area route Indicates routes between areas.

Type 1 external route Type 1 external routes have high reliability.

Issue 06 (2017-09-12) Huawei Proprietary and Confidential 182

Table 5-5 area type

NSSA An NSSA can import AS external routes. An ASBR uses Type 7

Issue 06 (2017-09-12) Huawei Proprietary and Confidential 183

OSPF Network Type

Table 5-6 OSPF network type

Network Type Description

Broadcast A network with the link layer protocol of Ethernet or Fiber

Point-to-Multipoint No network is a P2MP network by default, no matter what type

Issue 06 (2017-09-12) Huawei Proprietary and Confidential 184

Note the following points when configuring a stub area:

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

Note the following points when configuring an NSSA:

l The backbone area cannot be configured as an NSSA.

Neighbor State Machine

Issue 06 (2017-09-12) Huawei Proprietary and Confidential 185

OSPF Packet Authentication

The Router supports two authentication methods:

OSPF Route Summarization

Route summarization between areas reduces the amount of routing information to be

Route summarization can be carried out by an ABR or an ASBR:

l Route summarization on an ABR:

Issue 06 (2017-09-12) Huawei Proprietary and Confidential 186

OSPF Default Route

OSPF default routes are usually used in the following cases:

Principles for advertising OSPF default routes are described below:

Table 5-7 Principles for advertising OSPF default routes

Area Type Function

Common area By default, devices in a common OSPF area do not automatically

Issue 06 (2017-09-12) Huawei Proprietary and Confidential 187

Area Type Function

NSSA An NSSA allows its ASBRs to import a small number of AS