01-05 OSPF Configuration
01-05 OSPF Configuration
01-05 OSPF Configuration
Router 5 OSPF
5 OSPF Configuration
By building OSPF networks, you can enable OSPF to discover and calculate routes in an AS.
OSPF is applicable to large-scale networks with hundreds of routers.
5.1 Overview of OSPF
Open Shortest Path First (OSPF), which is developed by the IETF, is a link-state IGP. OSPF is
widely used in access networks and MANs.
5.2 Licensing Requirements and Limitations for OSPF
5.3 Configuring Basic OSPF Functions
Before constructing OSPF networks, you need to configure basic OSPF functions.
5.4 Configuring OSPF on the NBMA or P2MP Network
This section describes how to configure OSPF and modify attributes on the NBMA or point-
to-multipoint (P2MP) network to flexibly construct the OSPF network.
5.5 Adjusting OSPF Route Selection
By adjusting OSPF route selection, you can enable OSPF to meet the requirements of
complex networks.
5.6 Controlling OSPF Routing Information
You can control the advertising and receiving of OSPF routing information and import routes
of other protocols.
5.7 Adjusting the OSPF Network Convergence Speed
By adjusting OSPF timers, you can implement OSPF network convergence speed.
5.8 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.
5.9 Configuring OSPF Flush LSA Source Tracing
OSPF flush LSA source tracing helps improve the efficiency in locating the devices that
flushed OSPF LSAs.
5.10 Configuring an OSPF Dynamic Hostname
Compared with router IDs, OSPF dynamic hostnames are easier to memorize. Therefore,
using dynamic hostnames to identify routers can facilitate network management.
Definition
Open Shortest Path First (OSPF) is a link-state Interior Gateway Protocol (IGP) developed by
the Internet Engineering Task Force (IETF).
OSPF version 2 (OSPFv2) is intended for IPv4. OSPF version 3 (OSPFv3) is intended for
IPv6.
NOTE
In this document, OSPF refers to OSPFv2, unless otherwise stated.
Purpose
Before the emergence of OSPF, the Routing Information Protocol (RIP) was widely used as
an IGP on networks. RIP is a distance-vector routing protocol. Due to its slow convergence,
routing loops, and poor scalability, RIP is gradually being replaced with OSPF.
Typical IGPs include RIP, OSPF, and Intermediate System to Intermediate System (IS-
IS).
Table 5-1 describes differences among the three typical IGPs.
Applicati Applies to small networks Applies to medium- sized Applies to large networ
on scope with simple architectures, networks with several as Internet service provi
such as campus networks. hundred routers supported, (ISP) networks.
such as enterprise networks.
Routing Uses a distance-vector Uses the shortest path first Uses the SPF algorithm
algorithm algorithm and exchanges (SPF) algorithm to generate a generate an SPT based o
routing information over the shortest path tree (SPT) based network topology, calcu
User Datagram Protocol on the network topology, shortest paths to all
(UDP). calculates shortest paths to all destinations, and exchan
destinations, and exchanges routing information ove
routing information over IP. The SPF algorithm runs
separately in Level-1 an
Level-2 databases.
Benefits
OSPF offers the following benefits:
Wide application scope: OSPF applies to medium-sized networks with several hundred
routers, such as enterprise networks.
Network masks: OSPF packets can carry masks, and therefore the packet length is not
limited by natural IP masks. OSPF can process variable length subnet masks (VLSMs).
Fast convergence: When the network topology changes, OSPF immediately sends link
state update (LSU) packets to synchronize the changes to the link state databases
(LSDBs) of all routers in the same autonomous system (AS).
Loop-free routing: OSPF uses the SPF algorithm to calculate loop-free routes based on
the collected link status.
Area partitioning: OSPF allows an AS to be partitioned into areas, which simplifies
management. Routing information transmitted between areas is summarized, which
reduces network bandwidth consumption.
Equal-cost routes: OSPF supports multiple equal-cost routes to the same destination.
Hierarchical routing: OSPF uses intra-area routes, inter-area routes, Type 1 external
routes, and Type 2 external routes, which are listed in descending order of priority.
Authentication: OSPF supports area-based and interface-based packet authentication,
which ensures packet exchange security.
Multicast: OSPF uses multicast addresses to send packets on certain types of links,
which minimizes the impact on other devices.
When a device in an NSSA Plan configurations properly and Load balancing fails to
generates an NSSA LSA based on determine whether to enable OSPF implemented, which may c
an imported external route, the on the loopback interface. link congestion.
device preferentially uses the IP
address of a loopback interface in
the NSSA as the forwarding address
(FA). If no loopback interfaces exist
in the NSSA, the device selects the
IP address of a non-loopback
interface. As a result, the
downstream
device may fail to implement
load balancing using routes even
when links with the same cost
exist.
Before running the undo ospf Before running the undo ospf The residual Opaque LSAs a
process-id command to delete an process-id command to delete an used for calculation. As a res
OSPF process, you need to check OSPF process, you need to check calculation error occurs and m
whether segment routing is enabled. whether segment routing is enabled. last for a maximum of 3600s
If segment routing is enabled, you If segment routing is enabled, you
need to disable it before deleting the need to disable it before deleting the
OSPF process. Otherwise, Opaque OSPF process. Otherwise, Opaque
LSAs may remain unexpectedly due LSAs may remain unexpectedly due
to the Opaque capability change if to the Opaque capability change if
the process is reconfigured. the process is reconfigured.
Usage Scenario
When OSPF is configured on multiple routers in the same area, most configuration data, such
as the timer, filter, and aggregation, must be planned uniformly in the area. Incorrect
configurations may cause neighboring routers to fail to send messages to each other or even
causing routing information congestion and self-loops.
The OSPF-relevant commands that are configured in the interface view take effect regardless
of whether OSPF is enabled. After OSPF is disabled, the OSPF-relevant commands also exist
on interfaces.
Pre-configuration Tasks
Before configuring basic OSPF functions, complete the following tasks:
Configure a link layer protocol.
Configure IP addresses for interfaces to ensure that neighboring nodes are reachable at
the network layer.
Configuration Procedures
Enabling OSPF
Mandatory procedure
Optional procedure
Procedure
Step 1 Run system-view
The system view is displayed.
If the automatic recovery function is enabled and a router ID conflict occurs between
indirectly connected routers in one OSPF area, the conflicting router ID is replaced with
a newly calculated one, regardless of whether the conflicting router ID was manually
configured or automatically generated.
The system can replace a router ID in a maximum of three attempts in case the router ID
conflict persists.
After a router ID is replaced, the reset ospf [ process-id ] process command needs to be
run to validate the new router ID.
If a VPN instance is specified, the OSPF process belongs to this VPN instance. If a VPN
instance is not specified, the OSPF process belongs to the public-network instance.
You can run the description command to configure a description for the OSPF process for
easier identification.
non-backbone areas keep connected to the backbone area and devices within the backbone
area also keep connected. In real-world scenarios, however, these requirements cannot be met
due to various limitations. Configuring OSPF virtual links can solve the problem.
Procedure
Step 1 Run system-view
Step 4 Run vlink-peer router-id [ dead dead-interval | hello hello-interval | retransmit retransmit-
interval | trans-delay trans-delay-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 ] | smart-discover ] *
A virtual link is created. The virtual link must also be configured on the neighboring router.
The default value is recommended when a virtual link is created. You can modify the value as
required. Suggestions for configuring parameters are as follows:
The smaller the hello value, the faster the router detects network topology changes, and
the more network resources are consumed.
If the retransmit value is set too small, LSAs may be retransmitted. Setting the
parameter to a large value is recommended on a low-speed network.
The authentication modes of a virtual link and the backbone area must be the same.
----End
Context
RFC 2328 and RFC 1583 define the route selection rule differently. After OSPF is enabled on
the router, specify a route selection rule based on the router configuration. The router
complies with the route selection rule defined in RFC 1583 by default. If the neighboring
router complies with the route selection rule defined in RFC 2328, configure the local router
to comply with that defined in RFC 2328. This allows all routers in the OSPF area to comply
with the same route selection rule.
Procedure
Step 1 Run system-view
The router is configured to comply with the route selection rule defined in RFC 2328, not
RFC 1583.
----End
Context
The routing protocols may share and select the routing information because the router may
run multiple dynamic routing protocols at the same time. The system sets a priority for each
routing protocol. When multiple routing protocols are used to select routes, the route selected
by the routing protocol with a higher priority takes effect.
Procedure
Step 1 Run system-view
Step 3 Run preference [ ase | inter | intra ] { preference | route-policy route-policy-name | route-
filter route-filter-name } *
The OSPF priority is set.
----End
Context
If no response is received when the maximum number of packet retransmission attempts is
reached, the neighbor relationship will be interrupted.
Procedure
Step 1 Run system-view
----End
Context
After sending an LSA packet to the neighboring router, the router waits for a response. If no
response is received within the set interval, the router retransmits the LSA packet to the
neighboring router.
Procedure
Step 1 Run system-view
Setting the interval to a proper value is recommended. A rather small interval will cause
unnecessary retransmission. The interval is generally longer than a round trip of one packet
transmitted between two routers.
----End
Context
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.
Setting the MTU in a DD packet will have the neighbor relationship reestablished.
Procedure
Step 1 Run system-view
The interface is configured to fill in a DD packet with the interface MTU and check whether
the MTU in the DD packet from the neighboring router exceeds the MTU of the local router.
----End
Prerequisites
Basic OSPF functions have been configured.
Procedure
Run the display ospf [ process-id ] abr-asbr [ router-id ] command in any view to check
information about the ABRs and ASBRs of OSPF.
Run the display ospf [ process-id ] cumulative command in any view to check
information about OSPF statistics.
Run the display ospf [ process-id ] peer command in any view to check information
about OSPF neighbors.
Run the display ospf [ process-id ] nexthop command in any view to check information
OSPF next hop information.
Run the display ospf [ process-id ] error [ lsa | interface interface-type interface-
number ] command in any view to check information about OSPF error information.
Run the display ospf [ process-id ] vlink command in any view to check information
about OSPF virtual links.
Run the display ospf [ process-id ] interface [ all | no-peer | interface-type interface-
number ] [ verbose ] command in any view to check information about OSPF interfaces.
Run the display ospf [ process-id ] routing command in any view to check information
about the OSPF routing table.
Run the display ospf [ process-id ] topology [ area area-id ] [ statistics | verbose ]
command in any view to check information about the topology calculated for OSPF
routes.
Run the display ospf [ process-id ] spf-statistics [ verbose ] command in any view to
check information about route calculation statistics in OSPF processes.
Run the display ospf [ process-id ] request-queue [ interface-type interface-number ]
[ neighbor-id ] command in any view to check information about OSPF request list.
Run the display ospf [ process-id ] retrans-queue [ interface-type interface-number ]
[ neighbor-id ] command in any view to check information about OSPF retransmission
list.
Run the display ospf [ process-id ] statistics updated-lsa [ originate-router
advertising-router-id | history ] command in any view to check information about the
frequent updates of the LSAs that the LSDB receives
Run the display ospf [ process-id ] router-id conflict command in any view to check
information about router ID conflicts (if any).
----End
Example
Run the display ospf peer command, and you can view the Router IDs, addresses, and status
of OSPF neighbors.
Run the display ospf vlinkcommand, and you can view the OSPF virtual links.
<HUAWEI> display ospf vlink
OSPF Process 1 with Router ID 1.1.1.1
Virtual Links
Virtual-link Neighbor-id -> 2.2.2.2, Neighbor-State: Full
Interface: 10.1.1.1 (GigabitEthernet1/0/0) Cost: 1 State: P-
2-P Type: Virtual Transit Area: 0.0.0.1
Timers: Hello 10 , Dead 40 , Retransmit 5 , Transmit Delay 1
GR State: Normal
Run the display ospf interface command, and you can view the network types and status of
OSPF interfaces.
<HUAWEI> display ospf interface
Run the display ospf routing command, and you can view the destination addresses, link costs, and next hop
OSPF routes. For example:
<HUAWEI> display ospf routing
Total Nets: 3
Intra Area: 1 Inter Area: 2 ASE: 0 NSSA: 0
Run the display ospf [ process-id ] topology [ area area-id ] [ statistics | verbose ]
command, and you can view the information about the topology calculated for OSPF routes.
<HUAWEI> display ospf topology
Applicable Environment
As shown in Table 5-2, OSPF classifies networks into four types based on the types of link
layer protocols.
NOTE
Differentiated OSPF configurations that are applicable to the NBMA network and P2MP network are
provided in this section. The OSPF configurations not provided here are applicable to the four types of
networks.
Broadcast On the broadcast network, Hello packets, If the link layer protocol is Etherne
LSU packets, and LSAck packets are Fiber Distributed Data Interface
multicasted; DD packets and LSR packets (FDDI), OSPF regards the network
are unicasted. a broadcast network by default.
Non-broadcast On an NBMA network, Hello packets, If the link layer protocol is ATM, O
multiple access DD packets, LSR packets, LSU regards the network as an NBMA n
(NBMA) packets, and LSAck packets are by default.
unicasted.
The NBMA network must be
fully meshed. Any two routers on the
NBMA network must be directly
reachable.
Point-to-point On a P2P network, Hello packets, DD If the link layer protocol is PPP, HD
(P2P) packets, LSR packets, LSU packets, and Link Access Procedure Balanced (L
LSAck packets are multicasted. OSPF regards the network as a P2P
network by default.
Point-to- On a P2MP network, Hello packets are OSPF does not regard a network as
multipoint multicasted; DD packets, LSR packets, P2MP network by default regardles
(P2MP) LSU packets, and LSAck packets are any link layer protocol. A P2MP ne
unicasted. is forcibly changed from the netwo
The mask lengths of the routers on the another type.
P2MP network must be the same.
As shown in Table 5-2, OSPF sends packets in different manners on networks of different
types. Therefore, the difference between OSPF configurations on the networks lies in the
packet sending configurations.
Pre-configuration Tasks
Before configuring session parameters for the OSPF neighbor or adjacency relationship,
complete the following tasks:
Configuring a link layer protocol
Configuring IP addresses for interfaces to ensure that neighboring nodes are reachable at
the network layer
Configuring Basic OSPF Functions
Configuration Procedures
You can choose one or several configuration tasks (excluding "Checking the Configuration")
as required.
Context
The network types of the interfaces on both ends of a link must be the same; otherwise, the
OSPF neighbor relationship cannot be established.
Procedure
Step 1 Run system-view
The system view is displayed.
Step 2 Run interface interface-type interface-number
The interface view is displayed.
Step 3 Run ospf network-type { broadcast | nbma | p2mp | p2p [ peer-ip-ignore ] }
The network type of the OSPF interface is configured.
When the network type is configured for an interface, the original network type of the
interface is replaced.
The network type can be configured based on the real world situations.
On an interface with the broadcast network type, if a router that does not support the
multicast address exists, change the network type of the interface to NBMA.
On an interface with the NBMA network type, if the network is fully meshed or any two
routers are directly connected, change the network type of the interface to broadcast and
do not configure neighboring router information on the interface.
On an interface with the NBMA network type, if the network is not fully meshed, change
the network type of the interface to P2MP. After that, two indirectly connected routers
can communicate through one router that can directly reach both the two routers. After
the network type of the interface is changed to P2MP, configuring neighboring router
information on the interface is unnecessary.
If only two routers run OSPF on the same network segment, changing the network type
of the interface to P2P is recommended.
peer-ip-ignore is used to disable network segment check when IP address unnumbering is not
configured for a P2P interface changed from a broadcast interface and the interface tries to
establish an OSPF neighbor relationship. By default, if peer-ip-ignore is not specified in the
command, OSPF checks the network segment of the two ends during which an OSPF
neighbor relationship is to be established. Specifically, OSPF performs an AND operation on
the local subnet mask and the local IP address and on the local subnet mask and the remote IP
address. An OSPF neighbor relationship can be established only when the results on the two
ends are the same.
NOTE
OSPF cannot be configured on a null interface.
----End
Procedure
Step 1 (Optional) Set the network type to NBMA.
The NBMA network must be fully meshed. Any two routers on the NBMA network must be
directly reachable. In most cases, however, this requirement cannot be met. To resolve this
problem, run specific commands to forcibly change the network type to NBMA. For details,
see Configuring Network Types for OSPF Interfaces.
1. Run system-view
The interval at which Hello packets for polling are sent by an NBMA interface is set.
On the NBMA network, after the neighbor relationship becomes invalid, the router sends
Hello packets at an interval defined in the polling mechanism.
----End
Procedure
Step 1 Disable OSPF from checking the network mask.
The OSPF neighbor relationship cannot be established between the devices with different
mask lengths on the P2MP network. After OSPF is disabled from checking the network mask,
the OSPF neighbor relationship can be properly established.
1. Run system-view
A P2MP network is forcibly changed from another other type of network. For details, see
Configuring Network Types for OSPF Interfaces.
4. Run ospf p2mp-mask-ignore
OSPF is disabled from checking the network mask on the P2MP network.
5. Run commit
Step 2 (Optional) Configure the device to filter the LSA packets to be sent.
When multiple links exist between two devices, you can configure the local device to filter
the LSA packets to be sent. This can reduce unnecessary LSA retransmission attempts and
save bandwidth resources.
1. Run system-view
If the action specified in an ACL rule is permit, a route that matches the rule
will be received or advertised by the system.
If the action specified in an ACL rule is deny, a route that matches the rule
will not be received or advertised by the system.
If a route has not matched any ACL rules, the route will not be received or
advertised by the system.
If an ACL does not contain any rules, all routes matching the route-policy that
references the ACL will not be received or advertised by the system.
If the ACL referenced by the route-policy does not exist, all routes matching
the route-policy will be received or advertised by the system.
In the configuration order, the system first matches a route with a rule that has
a smaller number and then matches the route with a rule with a larger number.
Routes can be filtered using a blacklist or a whitelist:
Route filtering using a blacklist: Configure a rule with a smaller number and
specify the action deny in this rule to filter out the unwanted routes. Then,
configure another rule with a larger number in the same ACL and specify the
action permit in this rule to receive or advertise the other routes.
Route filtering using a whitelist: Configure a rule with a smaller number and
specify the action permit in this rule to permit the routes to be received or
advertised by the system. Then, configure another rule with a larger number in
the same ACL and specify the action deny in this rule to filter out unwanted
routes.
4. Run commit
----End
Prerequisites
OSPF attributes have been configured on networks of different types.
Procedure
Run the display ospf [ process-id ] interface [ all | no-peer | interface-type interface-
number ] [ verbose ] command to check information about OSPF interfaces.
Run the display ospf [ process-id ] peer command to check information about OSPF
neighbors.
Run the display ospf brief command to check the interval at which Hello packets are
sent on an NBMA network.
----End
Example
Run the display ospf interface command to view the network types and status of OSPF
interfaces.
<HUAWEI> display ospf interface
Run the display ospf peer command to view information about OSPF neighbors, including
the IP address, interface priority, and the DR or BDR.
<HUAWEI> display ospf peer
OSPF Process 1 with Router ID 1.1.1.1
Neighbors
Run the display ospf brief command to view the interval at which Hello packets are sent on
an NBMA network.
<HUAWEI> display ospf brief
OSPF Process 1 with Router ID 9.9.9.9
OSPF Protocol Information
RouterID: 9.9.9.9 Border Router: AREA
Multi-VPN-Instance is not enabled
Global DS-TE Mode: Non-Standard IETF Mode
Graceful-restart capability: disabled
Helper support capability : not configured
OSPF Stub Router State Reason: Startup Synchronize
Router LSA stub links with cost 65535
Summary LSA with cost 16777214
External LSA with cost 16777214
Applications Supported: MPLS Traffic-Engineering
Spf-schedule-interval: max 10000ms, start 500ms, hold 1000ms
Default ASE parameters: Metric: 1 Tag: 1 Type: 2
Route Preference: 10
ASE Route Preference: 150
Intra Route Preference: 50
Inter Route Preference: 50
SPF Computation Count: 56
RFC 1583 Compatible
OSPF is in LSDB overflow status(remain time: 205s)
Retransmission limitation is disabled
Import routes limitation is enabled
Self ASE LSA count: 8
Current status: Normal
bfd enabled
BFD Timers: Tx-Interval 10 , Rx-Interval 10 , Multiplier 3
Area Count: 2 Nssa Area Count: 1
ExChange/Loading Neighbors: 0
Usage Scenario
In real world situations, you can configure an OSPF route selection rule by setting OSPF
route attributes to meet the requirements of complex networks.
Set the cost of an interface. The link connected to the interface with a smaller cost value
preferentially transmits routing information.
Configure equal-cost routes to implement load balancing.
Configure a stub router during the maintenance operations such as upgrade to ensure
stable data transmission through key routes.
Suppress interfaces from sending or receiving packets to help select the optimal route.
Configuring an OSPF interface to automatically adjust the link cost based on link quality
that facilitates route selection control and improves network reliability.
Pre-configuration Tasks
Before adjusting OSPF route selection, complete the following tasks:
Configure IP addresses for interfaces to ensure that neighboring nodes are reachable at
the network layer.
Configure basic OSPF functions.
Configuration Procedures
Perform one or more of the following configurations as required.
Context
After the OSPF interface costs are set, the interface with a smaller cost value preferentially
transmits routing information. This helps select the optimal route.
The OSPF interface cost can be set or calculated based on the interface bandwidth.
Procedure
Manually configure a cost for an OSPF interface.
a. Run system-view
Context
If the destinations and costs of the multiple routes discovered by one routing protocol are the
same, load balancing can be implemented among the routes.
As shown in Figure 5-2, three routes between Device A and Device B that run OSPF have the
same costs. The three routes are equal-cost routes for load balancing.
IP Network
cost=10 cost=5
IP Network
DeviceA DeviceB
IP Network
Procedure
Step 1 Run system-view
The system view is displayed.
Step 2 Run ospf [ process-id ]
The OSPF process view is displayed.
Step 3 Run maximum load-balancing number
The maximum number of equal-cost routes is set.
If the number of equal-cost routes is greater than number specified in the maximum load-
balancing command, routes are selected for load balancing based on the following criteria:
1. Route priority: Routes with smaller priority values are selected for load balancing. For
details about route priority configuration, see Step 4.
2. Interface index: If routes have the same priority, those with greater interface index values
are selected for load balancing.
3. Next hop IP address: If routes have the same priority and interface index, those with
larger IP addresses are selected for load balancing.
Step 4 (Optional) Run either of the following commands:
To configure a priority for an equal-cost route, run the nexthop ip-address weight value
command.
Among equal-cost OSPF routes, those with smaller priority values configured using the
nexthop command are selected for load balancing.
– ip-address specifies the next hop address of the equal-cost route.
– value specifies the weight of the next hop.
To configure priorities for the routes with a TE tunnel interface or an IPv4 interface as
the outbound interface for route selection if both an IGP-Shortcut-enabled TE tunnel and
IP link are available, run the ecmp prefer { te-tunnel | intact } command.
Step 5 Run commit
----End
Context
To set the convergence priority of OSPF routes based on a specified IP prefix list takes effect
on the public network only.
OSPF route calculation, link-state advertisement (LSA) flooding, and LSDB synchronization
can be implemented according to the configured priority. Therefore, route convergence can be
controlled.
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 enables OSPF to calculate the three types of routes separately
according to the specified route calculation priorities. Convergence priorities are critical, high,
medium, and low. To speed up the processing of LSAs with the higher priority, during LSA
flooding, the LSAs need to be placed into the corresponding critical, high, medium, and low
queues according to priorities.
Procedure
Step 1 Run system-view
The system view is displayed.
Step 2 Run ip_ip-prefix ip-prefix-name [ index index-number ] { permit | deny } ipv4-address
mask-length [ match-network ] [ greater-equal greater-equal-value ] [ less-equal less-
equal-value ]
The IP prefix list is configured.
Step 3 Run ospf [ process-id ]
The OSPF process is started and OSPF view is displayed.
Step 4 Run prefix-priority { critical | high | medium } ip-prefix ip-prefix-name
The convergence priority for OSPF routes is set.
Step 5 Run commit
The configuration is committed.
----End
Context
After a stub router is configured, the route on the stub router will not be preferentially
selected. After the route cost is set to the maximum value 65535, traffic generally bypasses
the router. This ensures an uninterrupted route on the router during maintenance operations
such as upgrade.
Procedure
Step 1 Run system-view
NOTE
The stub router configured in this manner is irrelevant to the router in the stub area.
----End
Context
Suppressing an interface from receiving and sending OSPF packets helps routing information
to bypass a specific router and enables the local router to reject routing information advertised
by another router. This ensures that an optimal route is provided.
For example, there are three routes between Device A and Device B, as shown in Figure 5-3.
To configure the route with the outbound interface of Interface 2 to be the optimal route,
suppress Interface 1 and Interface 3 from receiving and sending OSPF packets.
Figure 5-3 Networking diagram of suppressing an interface from receiving and sending
OSPF packets
IP Network
Interface2
IP Network
DeviceA DeviceB
IP Network
Procedure
Step 1 Run system-view
The system view is displayed.
Step 2 Run ospf [ process-id ]
The OSPF process view is displayed.
Step 3 Run silent-interface { all | interface-type interface-number }
An interface is suppressed from receiving and sending OSPF packets.
The same interface in different processes can be suppressed from sending and receiving OSPF
packets, but the silent-interface command is valid only for the OSPF interface in the local
process.
After an OSPF interface is configured to be in the silent state, the interface can still advertise
its direct routes. Hello packets on the interface, however, cannot be forwarded. Therefore, no
neighbor relationship can be established on the interface. This can enhance the networking
adaptability of OSPF and reduce system resource consumption.
Step 4 Run commit
The configuration is committed.
----End
transferred during a studied time interval. During data transmission, a high BER will degrade
or even interrupt services in extreme cases.
To prevent this problem, configure OSPF interfaces to automatically adjust link costs based
on link quality so that unreliable links are not used by the optimal routes.
Procedure
Step 1 Run system-view
The system view is displayed.
Step 2 Run interface interface-type interface-number
The interface view is displayed.
Step 3 (Optional) Run bit-error-mode { crc | prefec [ trigger-interval time-interval ] }
Bit error detection is enabled on the interface.
NOTE
Bit error detection is classified as CRC bit error detection or Prefec bit error detection.
NOTE
The cost parameter specifies the link cost adjustment value. After this parameter is specified:
If the link quality changes from good to low, the link cost equals the original link cost plus the adjustment
value. The maximum link cost allowed is 65535.
If the link quality changes from low to good, the original link cost applies.
----End
of the interface is changed to the fallback cost which is higher than the normal cost, and
traffic is then switched to an alternative path; when the remaining bandwidth of the Eth-Trunk
interface reaches or exceeds the bandwidth threshold, the original cost is restored.
Procedure
Step 1 Run system-view
The system view is displayed.
Step 2 Run interface eth-trunk trunk-id
The Eth-Trunk interface view is displayed.
Step 3 Run ospf cost-fallback fallbackcost threshold fallbackbw
A fallback cost is configured for an Eth-Trunk interface.
Step 4 Run commit
The configuration is committed.
----End
Procedure
Run the display ospf [ process-id ] interface [ all | no-peer | interface-type interface-
number ] [ verbose ] command to check information about OSPF interfaces.
Run the display ospf [ process-id ] routing command to check information about the
OSPF routing table.
Run the display ospf [ process-id ] ecmp-group command to check information about
OSPF ECMP groups
----End
Example
Run the display ospf interface command to view the network types and costs of OSPF
interfaces.
<HUAWEI> display ospf interface
Run the display ospf routing command to view the destination addresses and link costs of
OSPF routes and whether load balancing is performed among these OSPF routes.
Routing Tables
Total Nets: 4
Intra Area: 1 Inter Area: 2 ASE: 1 NSSA: 0
Pre-configuration Tasks
Before controlling OSPF routing information, complete the following tasks:
Configure IP addresses for interfaces to ensure that neighboring nodes are reachable at
the network layer.
Configure basic OSPF functions.
Configuration Procedures
Perform one or more of the following configurations as required.
Context
To access a router running a non-OSPF protocol, an OSPF-capable router needs to import
routes of the non-OSPF protocol into the OSPF network.
OSPF provides loop-free intra-area routes and inter-area routes; however, OSPF cannot
prevent external routing loops. Therefore, exercise caution when configuring OSPF to import
external routes. For details, see "OSPF VPN Extension" in the HUAWEI NetEngine40E
Feature Description - VPN.
Perform the following steps on the ASBR running OSPF.
Procedure
Step 1 Run system-view
The system view is displayed.
Step 4 (Optional) Run default { cost { cost | inherit-metric } | tag tag | type type } *
The default values of parameters (the cost, number of routes, tag, and type) are set for
imported routes.
When OSPF imports external routes, you can set default values for some additional
parameters, such as the cost, number 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 carried in BGP routes imported by OSPF.
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 priorities.
Run the apply cost command to set the cost of a route.
Run the import-route command to set the cost of the imported route.
Run the default command to set the default cost of the imported route.
If a route has not matched any ACL rules, the route will not be received or
advertised by the system.
If an ACL does not contain any rules, all routes matching the route-policy that
references the ACL will not be received or advertised by the system.
If the ACL referenced by the route-policy does not exist, all routes matching
the route-policy will be received or advertised by the system.
In the configuration order, the system first matches a route with a rule that has
a smaller number and then matches the route with a rule with a larger number.
Routes can be filtered using a blacklist or a whitelist:
Route filtering using a blacklist: Configure a rule with a smaller number and
specify the action deny in this rule to filter out the unwanted routes. Then,
configure another rule with a larger number in the same ACL and specify the
action permit in this rule to receive or advertise the other routes.
Route filtering using a whitelist: Configure a rule with a smaller number and
specify the action permit in this rule to permit the routes to be received or
advertised by the system. Then, configure another rule with a larger number in
the same ACL and specify the action deny in this rule to filter out unwanted
routes.
Based on the IP prefix:
Run filter-policy ip-prefix ip-prefix-name export [ protocol [ process-id ] ]
Routes imported using Step 3 can be advertised only when meeting filtering conditions.
OSPF filters the imported routes. OSPF uses Type 5 LSAs to carry routes that meet the
filtering conditions and advertises these Type 5 LSAs.
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
imported routes.
The import-route command cannot be used to import the default route from another AS.
A limit is configured on the number of LSAs generated when an OSPF process imports
external routes.
If OSPF imports a large number of external routes and advertises them to a device with a
smaller routing table capacity, the device may restart unexpectedly. To address this problem,
run the import-route limit command to configure a limit on the number of LSAs generated
when an OSPF process imports external routes. Check the overload status based on the value
of the Current status field in the display ospf brief command output.
Normal: The number of LSAs generated when an OSPF process imports external routes
is less than or equal to the lower alarm threshold (in percentage) multiplied by the
maximum number allowed.
Approach limit: The number of LSAs generated when an OSPF process imports external
routes is approaching (reaching or exceeding 90% of) the upper alarm threshold.
Exceed limit: The number of LSAs generated when an OSPF process imports external
routes has reached or exceeded the maximum number allowed.
----End
Context
On the area border and AS border of an OSPF network generally reside multiple routers for
next-hop backup or traffic load balancing. A default route can be configured to reduce routing
entries and improve resource usage on the OSPF network.
The default route is generally applied to the following scenarios:
1. An ABR in an area advertises Type 3 LSAs carrying the default route within the area.
routers in the area use the received default route to forward inter-area packets.
2. An ASBR in an AS advertises Type 5 or Type 7 LSAs carrying the default route within
the AS. routers in the AS use the received default route to forward AS external packets.
When no exactly matched route is discovered, the router can forward packets through the
default route.
The preference of the default route in Type 3 LSAs is higher than that of the route in Type 5
or Type 7 LSAs.
The advertising mode of the default route is determined by the type of the area to which the
default route is imported, as shown in Table 5-3.
Procedure
Step 1 Run system-view
The system view is displayed.
Step 2 Run ospf [ process-id ]
The OSPF process view is displayed.
Step 3 Run default-route-advertise [ [ always | permit-calculate-other ] | cost cost | type type |
{ route-policy route-policy-name | route-filter route-filter-name } | distribute-delay delay-
time ] *
The default route is imported into the OSPF process.
For details about how to configure the default route in the NSSA, see Configuring an NSSA.
Step 4 Run commit
The configuration is committed.
----End
Procedure
Configure ABR route summarization.
Perform the following steps on the OSPF ABR:
a. Run system-view
The system view is displayed.
b. Run ospf [ process-id ]
The OSPF process view is displayed.
c. Run area area-id
The OSPF area view is displayed.
d. Run abr-summary ip-address mask [ [ advertise | cost { cost | inherit-minimum }
| generate-null0-route | hold-max-cost interval ] * | [ not-advertise | cost { cost |
inherit-minimum | hold-max-cost interval } ] * | [ generate-null0-route |
advertise | cost { cost | inherit-minimum } | hold-max-cost interval ] * ]
ABR route summarization is configured.
e. Run commit
The configuration is committed.
Configure ASBR route summarization.
Perform the following steps on the OSPF ASBR:
a. Run system-view
The system view is displayed.
b. Run ospf [ process-id ]
----End
Context
After filtering conditions are set for the incoming or outgoing Type 3 LSAs (Summary LSAs)
in an area, only the Type 3 LSAs that meet the filtering conditions can be received or
advertised.
Procedure
Step 1 Run system-view
Filter outgoing Type 3 LSAs in the area. Run any of the following commands as
required:
– Based on the basic ACL:
i. Run filter { acl-number | acl-name acl-name } export
Filter outgoing Type 3 LSAs in the area can be advertised.
ii. Run quit
Return to the system view.
iii. Run acl { name basic-acl-name { basic | [ basic ] number basic-acl-number }
| [ number ] basic-acl-number } [ match-order { config | auto } ]
The basic ACL view is displayed.
iv. Run rule [ rule-id ] [ name rule-name ] { deny | permit } [ fragment-type
{ fragment | non-fragment | non-subseq | fragment-subseq | fragment-spe-
first } | source { source-ip-address { source-wildcard | 0 | src-netmask } |
any } | time-range time-name | vpn-instance vpn-instance-name ] *
The rule for the basic ACL is configured.
When the rule command is run to configure rules for a named ACL, only the
source address range specified by source and the time period specified by
time-range are valid as the rules.
When a filtering policy of a routing protocol is used to filter routes:
○ If the action specified in an ACL rule is permit, a route that matches the
rule will be received or advertised by the system.
○ If the action specified in an ACL rule is deny, a route that matches the
rule will not be received or advertised by the system.
○ If a route has not matched any ACL rules, the route will not be received
or advertised by the system.
○ If an ACL does not contain any rules, all routes matching the route-
policy that references the ACL will not be received or advertised by the
system.
○ If the ACL referenced by the route-policy does not exist, all routes
matching the route-policy will be received or advertised by the system.
○ In the configuration order, the system first matches a route with a rule that
has a smaller number and then matches the route with a rule with a larger
number. Routes can be filtered using a blacklist or a whitelist:
Route filtering using a blacklist: Configure a rule with a smaller number
and specify the action deny in this rule to filter out the unwanted routes.
Then, configure another rule with a larger number in the same ACL and
specify the action permit in this rule to receive or advertise the other
routes.
Route filtering using a whitelist: Configure a rule with a smaller number
and specify the action permit in this rule to permit the routes to be
received or advertised by the system. Then, configure another rule with a
larger number in the same ACL and specify the action deny in this rule to
filter out unwanted routes.
– Based on the IP prefix:
Run filter ip-prefix ip-prefix-name export
Filter outgoing Type 3 LSAs in the area can be advertised.
----End
Procedure
Step 1 Run system-view
The system view is displayed.
Step 2 Run interface interface-type interface-number
The interface view is displayed.
Step 3 Based on the basic ACL:
1. 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.
2. Run quit
Return to the system view.
3. Run acl { name basic-acl-name { basic | [ basic ] number basic-acl-number } |
[ number ] basic-acl-number } [ match-order { config | auto } ]
----End
Procedure
Step 1 Run system-view
The system view is displayed.
Step 2 Run ospf [ process-id ]
----End
Procedure
Step 1 Run system-view
The system view is displayed.
Step 2 Run ospf [ process-id ]
The OSPF process view is displayed.
Step 3 Run lsdb-overflow-limit number
The maximum number of external routes supported by the OSPF LSDB is configured.
If the number of external routes imported by OSPF exceeds the configured maximum number,
the device deletes self-generated non-default external routes to ensure the proper forwarding
of other external routes.
Step 4 Run commit
The configuration is committed.
----End
Procedure
Run the display ospf [ process-id ] lsdb command to check information about the OSPF
LSDB.
Run the display ospf [ process-id ] asbr-summary [ ip-address mask ] command to
check information about OSPF route summarization.
----End
Example
Run the display ospf lsdb command to view information about the OSPF LSDB, including
the link state IDs in the LSAs and information about the routers that advertise or generate
LSAs.
<HUAWEI> display ospf lsdb
OSPF Process 1 with Router ID 1.1.1.1
Link State Database
Area: 0.0.0.0
Type LinkState ID AdvRouter Age Len Sequence M
Router 2.2.2.2 2.2.2.2 98 36 8000000B
Network 10.1.1.2 2.2.2.2 98 32 80000004
Sum-Net 20.1.1.0 2.2.2.2 286 28 80000001
Sum-Asbr 2.2.2.2 1.1.1.1 61 28 80000001
AS External Database
Type LinkState ID AdvRouter Age Len Sequence M
External 0.0.0.0 2.2.2.2 1128 36 80000001
External 100.1.1.0 2.2.2.2 538 36 80000002
Pre-configuration Tasks
Before adjusting the OSPF network convergence speed, complete the following tasks:
Configuration Procedures
Perform one or more of the following configurations as required.
Context
Hello packets are periodically sent between OSPF interfaces to establish and maintain
neighbor relationships. The intervals set on the interfaces at both ends must be the same.
Otherwise, the OSPF neighbor relationship cannot be established.
Procedure
Step 1 Run system-view
The interval at which Hello packets are sent is set on the OSPF interface.
To speed up OSPF convergence in the case of a link failure, configuring BFD For OSPF is
recommended. If the remote end does not support BFD for OSPF or you do not want to
configure BFD for OSPF, specify conservative when you run the ospf timer hello command.
If the conservative mode is configured, the value configured for the dead timer using the ospf
timer dead command takes effect even when the value is less than 10s; if the value
configured for the dead timer is greater than 10s, services may be affected.
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.
----End
Procedure
Step 1 Run system-view
The system view is displayed.
Step 2 Run interface interface-type interface-number
The OSPF interface view is displayed.
Step 3 Run ospf trans-delay interval
The delay for transmitting LSAs is set on an interface.
The LSAs in the LSDB of the local router age with time (increase by 1 each second), but not
during transmission. To set a delay for transmitting LSAs on an interface.
Step 4 Run commit
The configuration is committed.
----End
Procedure
Step 1 Run system-view
The system view is displayed.
Step 2 Run interface interface-type interface-number
The OSPF interface view is displayed.
Step 3 Run ospf timer dead interval
The dead time is set for the neighbor relationship.
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. If
the conservative mode is configured using the ospf timer hello command, the configured dead timer
takes effect even when its value is less than 10s.
Both the Hello timer and Dead timer are restored to the default values if the network type is changed.
----End
Procedure
Step 1 Run system-view
The system view is displayed.
Step 2 Run ospf [ process-id ]
The OSPF process view is displayed.
Step 3 Run sham-hello enable
OSPF sham hello is enabled.
Step 4 Run commit
The configuration is committed.
----End
Context
Without Smart-discover, when the neighbor status of the router changes or the DR/BDR on
the multiple-access network (broadcast or NBMA network) changes, the router does not send
Hello packets to its neighbor until the Hello timer expires; after Smart-discover is configured,
the router sends Hello packets to its neighbor immediately without waiting for the Hello timer
to expire, which speeds up the neighbor relationship establishment and OSPF network
convergence.
Procedure
Step 1 Run system-view
The system view is displayed.
Step 2 Run interface interface-type interface-number
The OSPF interface view is displayed.
Step 3 Run ospf smart-discover
Smart-discover is configured on the interface.
Step 4 Run commit
The configuration is committed.
----End
Context
OSPF sets the interval at which LSAs are updated to 5s. This prevents network connections or
frequent route flapping from consuming excessive network bandwidth or device resources.
On a stable network that requires fast route convergence, you can change the interval for
updating LSAs to 0s. In this manner, the device can fast respond to topology or route changes,
which speeds up route convergence.
Procedure
Step 1 Run system-view
intelligent-timer: Sets the intelligent timer to update OSPF Type-1 LSA (Router LSA) ,
Type-2 LSA (Network LSA), Type-5 LSA (AS-external-LSA), Type-7 LSA (NSSA
LSA).
max-interval: Sets the maximum interval at which LSAs are updated, in milliseconds.
start-interval: Sets the initial interval at which LSAs are updated, in milliseconds.
hold-interval: Sets the hold interval at which LSAs are updated, in milliseconds.
other-type: Sets the interval to update OSPF Type-3 LSA (Network-summary-LSA),
Type-4 LSA (ASBR-summary-LSA) and Type-10 LSA (Opaque LSA).
After an intelligent timer is enabled, the interval for updating LSAs is 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 equal 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 updates LSAs at the initial interval specified by start-
interval.
The suppression period that takes effect when the OSPF LSAs to be sent flap is configured.
If no flapping occurs among the OSPF LSAs to be sent, the configuration of the lsa-
originate-interval command prevents the device from frequently sending LSAs. If the OSPF
LSAs to be sent flap, the configuration of the lsa-originate-interval suppress-flapping
command minimizes the impact of the flapping on services. The larger value of the two
intervals specified in the commands is used as the suppression period.
----End
Context
In OSPF, the defined interval at which LSAs are received is 1s. This aims to prevent network
connections or frequent route flapping from consuming excessive network bandwidth or
device resources.
On a stable network that requires fast route convergence, you can cancel the interval at which
LSAs are received by setting the interval to 0s. After the interval is set to 0s, topology or route
changes can be immediately advertised on the network through LSAs, which speeds up route
convergence.
Procedure
Step 1 Run system-view
The parameter interval sets the interval at which LSAs are received, in milliseconds.
The parameter intelligent-timer sets the interval at which router LSAs or network LSAs
are received using an intelligent timer.
The parameter max-interval sets the maximum interval at which LSAs are received, in
milliseconds.
The parameter start-interval sets the initial interval at which LSAs are received, in
milliseconds.
The parameter hold-interval sets the hold interval at which LSAs are received, in
milliseconds.
Details about the interval at which LSAs are received are as follows:
1. start-interval specifies the initial interval at which LSAs are received.
2. The interval at which LSAs are received for the nth (n ≥ 2) time = hold-interval x 2 x
(n-1).
3. When the interval specified in hold-interval x 2 x (n-1) reaches the maximum interval
specified in 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 in start-interval.
----End
Context
When the OSPF LSDB changes, the shortest path needs to be recalculated. If a network
changes frequently, the shortest path is calculated accordingly, which consumes a large
number of system resources degrades system performance. By configuring an intelligent timer
and a proper interval for the SPF calculation, you can prevent excessive system memory and
bandwidth resources from being occupied.
Procedure
Step 1 Run system-view
The system view is displayed.
Step 2 Run ospf [ process-id ]
The OSPF process view is displayed.
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.
The interval for the SPF calculation is as follows:
1. The initial interval for the SPF calculation is specified in start-interval.
2. The interval for the SPF calculation for the nth (n≥2) time is equal to hold-interval ×
2(n-2).
3. When the interval specified in hold-interval × 2(n-2) reaches the maximum interval
specified in max-interval, OSPF performs the SPF calculation at the maximum interval
until no SPF calculation is performed within max-interval. After the maximum interval
elapses, the calculation mechanism goes back to step 1.
4. If no flapping occurs within the interval of max-interval that starts upon the end of the
previous SPF calculation, the intelligent timer exits.
5. If no flapping occurs in the previous interval and flapping occurs in the current interval,
SPF calculation is delayed for a period of the start-interval. After the SPF calculation is
complete, the current interval is used for the next SPF calculation.
Step 4 Run commit
The configuration is committed.
----End
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
The route calculation delay function is configured to suppress frequent OSPF LSA flapping.
----End
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)
Procedure
Step 1 Run system-view
The master/slave board switching triggered by abnormal OSPF LSA aging is disabled.
----End
Context
If an exception occurs in the age field of LSAs, LSAs may be aged unexpectedly, causing
LSA flapping or a route calculation error. For example, if the abnormal aging time is 2500s
and the actual aging time is 500s, LSAs are aged prematurely. To address this problem, OSPF
LSA aging management is enabled by default. If the aging time in a received LSA is greater
than 1800s, OSPF considers the LSA abnormal and changes the aging time to 1700s until the
aging time values of all LSAs in the area become the same. In this case, routes can be
calculated correctly.
Procedure
Step 1 Run system-view
----End
Context
When an OSPF interface changes from Down to Up, the OSPF neighbor relationship is re-
established. When IGP route convergence ends, traffic is switched back. IGP routes converge
fast. Many services that depend on IGP routes may require a delayed switchback. In this case,
you can run the ospf peer hold-max-cost command so that OSPF keeps the maximum cost in
local LSAs for a specified period after the OSPF neighbor relationship reaches Full state.
During this period, the traffic forwarding path remains unchanged. After this period elapses,
the original cost is restored, and traffic is switched back.
Procedure
Step 1 Run system-view
The system view is displayed.
Step 2 Run interface interface-type interface-number
The interface view is displayed.
Step 3 Run ospf peer hold-max-cost timer timer
A period during which OSPF keeps the maximum cost in local LSAs is set.
Step 4 Run commit
The configuration is committed.
----End
Procedure
Step 1 Run system-view
The system view is displayed.
Step 2 Run ospf [process-id ]
The OSPF view is displayed.
Step 3 Run safe-sync enable
Secure synchronization is configured.
Step 4 Run commit
The configuration is committed.
----End
Example
Run the display ospf brief command to view information about OSPF timers.
<HUAWEI> display ospf brief
OSPF Process 1 with Router ID 9.9.9.9
OSPF Protocol Information
RouterID: 9.9.9.9 Border Router: AREA
Multi-VPN-Instance is not enabled
Global DS-TE Mode: Non-Standard IETF Mode
Graceful-restart capability: disabled
Helper support capability : not configured
OSPF Stub Router State Reason: Startup Synchronize
Router LSA stub links with cost 65535
Summary LSA with cost 16777214
External LSA with cost 16777214
Applications Supported: MPLS Traffic-Engineering
Spf-schedule-interval: max 10000ms, start 500ms, hold 1000ms
Default ASE parameters: Metric: 1 Tag: 1 Type: 2
Route Preference: 10
ASE Route Preference: 150
Intra Route Preference: 50
Inter Route Preference: 50
SPF Computation Count: 56
RFC 1583 Compatible
OSPF is in LSDB overflow status(remain time: 205s)
Retransmission limitation is disabled
Import routes limitation is enabled
Self ASE LSA count: 8
Current status: Normal
bfd enabled
BFD Timers: Tx-Interval 10 , Rx-Interval 10 , Multiplier 3
Area Count: 2 Nssa Area Count: 1
ExChange/Loading Neighbors: 0
Run the display ospf [ process-id ] statistics maxage-lsa command to view information
about router LSAs that have reached the aging time.
<HUAWEI> display ospf statistics maxage-lsa
-------------------------------------------
Area: 0.0.0.0
LinkState ID MaxAge count Last MaxAge time
1.1.1.1 1 2014-03-22 11:12:00
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.
NOTE
The following steps are optional, choose them as required.
Pre-configuration Tasks
Before configuring OSPF neighbor relationship flapping suppression, complete the following
tasks:
Configure an IP address for each interface to ensure that neighboring routers are
reachable at the network layer.
Configure basic OSPF functions.
Procedure
Step 1 Run system-view
Flapping suppression can also work first in Hold-down mode and then in Hold-max-cost
mode.
To disable the Hold-max-cost mode, run the ospf suppress-flapping peer hold-max-cost
disable command.
Step 4 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.
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.
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 5 Run quit
Interfaces are forced to exit from OSPF neighbor relationship flapping suppression.
NOTE
----End
Suppress flapping peer in the command output indicates the current suppression mode
(Hold-down), time when the flapping suppression started, and the remaining time of the
flapping suppression.
Usage Scenario
If network-wide OSPF LSPs are deleted, purge LSPs are flooded, which adversely affects
network stability. In this case, source tracing must be implemented to locate the root cause of
the fault immediately to minimize the impact. However, OSPF itself does not support source
tracing. A conventional solution is isolation node by node until the faulty node is located, but
the solution is complex and time-consuming. To address this problem, enable OSPF purge
LSP source tracing.
NOTE
Pre-configuration Tasks
Before configuring OSPF flush LSA source tracing, complete the following task:
Configure an IP address for each interface to ensure that neighboring routers are
reachable at the network layer.
Configure basic OSPF functions.
Procedure
Step 1 Run system-view
The system view is displayed.
By default, the OSPF flush LSA source tracing function is enabled globally. To disable this
function, run the ospf flush-source-trace disable command.
Step 2 Run interface interface-type interface-number
The interface view is displayed.
By default, the OSPF flush LSA source tracing function is enabled on all interfaces of a
specified OSPF process. To disable this function on an interface, run the ospf flush-source-
trace block command.
Step 3 Run quit
The system view is displayed.
----End
Area(0.0.0.0)Analysis Information
Usage Scenario
To facilitate network management, configure dynamic hostnames to identify routers. If you
configure a dynamic hostname for a router, the router generates a router information (RI)
Opaque LSA, from which you can check the mapping between the router ID and the dynamic
hostname.
Pre-configuration Tasks
Before configuring a dynamic hostname, complete the following tasks:
Configure an IP address for each interface to ensure that neighboring routers can use the
IP addresses to communicate with each other.
Configure basic OSPF functions.
Procedure
Step 1 Run system-view
NOTE
If you specify hostname in hostname command, hostname is advertised as the dynamic hostname. If no
hostname is specified in hostname command, the hostname specified in the sysname command is
advertised as the dynamic hostname.
----End
Run the display ospf hostname-table command to check information about OSPF dynamic
hostnames.
<HUAWEI> display ospf hostname-table
Area: 0.0.0.1
Router ID Hostname
3.3.3.3 RTR_BLR
10.1.1.1 RTR_SHANGHAI
255.255.255.254
RTR_BJI
Area: 0.0.0.2
Router ID Hostname
3.3.3.3 RTR_BLR
30.1.1.1 RTR_DELHI
AS-Scope
Router ID Hostname
20.1.1.1 RTR_SHENZHEN
255.255.255.254 RTR_BJI
Applicable Environment
The number of LSAs can be reduced by partitioning an AS into different areas. To reduce the
number of entries in the routing table and the number of LSAs to be transmitted in a non-
backbone area, configure the non-backbone area on the border of the AS as a stub area.
Configuring a stub area is optional. A stub area generally resides on the border of an AS. For
example, a non-backbone area with only one ABR can be configured as a stub area. In a stub
area, the number of entries in the routing table and the amount of routing information to be
transmitted greatly decrease.
Pre-configuration Tasks
Before configuring a stub area, complete the following tasks:
Configuring IP addresses for interfaces to ensure that neighboring routers are reachable
at the network layer
Configuring Basic OSPF Functions
Procedure
Step 1 Run system-view
NOTE
All routers in a stub area must be configured with stub attributes using the stub command.
Configuring or deleting stub attributes will update routing information in the area. Stub attributes
can be deleted or configured again only after the routing update is complete.
----End
Area: 0.0.0.1
Type LinkState ID AdvRouter Age Len Sequence Metric
Router 10.1.1.1 10.1.1.1 26 48 80000005 1
Router 100.1.1.2 100.1.1.2 28 48 80000004 1
Run the display ospf peer command, and you can view the router IDs, addresses, and status of OSPF neighb
Run the display ospf routing command, and you can view the table of OSPF routes. For example:
Routing Tables
Total Nets: 4
Intra Area: 2 Inter Area: 2 ASE: 0 NSSA: 0
When Router is in a common area, there are AS external routes in the routing table. After the
area where Router resides is configured as a stub area, AS external routes are invisible, ASE
is 0.
Usage Scenario
An excessive number of entries in a routing table wastes network resources and causes high
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.11 Configuring an
OSPF Stub Area.
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 where it resides. Different from the stub area, the NSSA
allows AS external routes to be imported and forwarded in the entire AS.
If you want to import AS external routes to an area and prevent these routes from consuming
resources, configure the area as an NSSA.
Type 7 link state advertisements (LSAs) are used to carry imported AS external routes in the
NSSA. Type 7 LSAs are generated by ASBRs of NSSAs and flooded only in the NSSAs
where ASBRs reside. The 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
A Type 7 LSA was introduced to support NSSAs and describe imported external routes.
Type 7 LSAs can be used to carry default route to transmit traffic to other ASs.
To configure an area as an NSSA, configure NSSA attributes on all the routers in this area.
Pre-configuration Tasks
Before configuring an NSSA, complete the following tasks:
Configure IP addresses for interfaces to ensure that neighboring routers are reachable at
the network layer.
Procedure
Step 1 Run system-view
The system view is displayed.
Step 2 Run ospf [ process-id ]
The OSPF process view is displayed.
Step 3 Run area area-id
The OSPF area view is displayed.
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 area is configured as an NSSA.
NOTE
NSSA attributes must be configured on all routers in the NSSA using the nssa command.
Configuring or deleting NSSA attributes may trigger routing update in the area and disconnection
from neighbors. The NSSA attributes can be reconfigured or re-canceled only after the routing
update is complete.
----End
Total Nets: 7
Intra Area: 2 Inter Area: 4 ASE: 1 NSSA: 0
Total Nets: 7
Intra Area: 2 Inter Area: 4 ASE: 0 NSSA: 1
By comparing the routing tables before and after an NSSA is configured, you can reach the
following conclusions:
After an area is configured as an NSSA, the number of entries in the routing table is
reduced.
AS external routes are imported to the NSSA.
Usage Scenario
When multicast and an Interior Gateway Protocol (IGP) Shortcut-enabled MPLS TE tunnel
are configured on a network, the outbound interface of the route calculated by an IGP may not
be a physical interface but a TE tunnel interface. The TE tunnel interface on the router sends
multicast Join packets over a unicast route to the multicast source address. The multicast Join
packets are transparent to the router through which the TE tunnel passes. As a result, the
router through which the TE tunnel passes cannot generate multicast forwarding entries.
To resolve this problem, enable OSPF local MT. After local MT is enabled, if the outbound
interface of a calculated route is an IGP Shortcut-enabled TE tunnel interface, the route
management (RM) module creates an independent Multicast IGP (MIGP) routing table for the
multicast protocol, calculates a physical outbound interface for the route, and adds the route to
the MIGP routing table. Multicast packets are then forwarded along this route.
You can configure a routing policy for local MT to control the number of routing entries in an
MIGP routing table and speed up MIGP routing table lookup.
Pre-configuration Tasks
Before configuring local MT, complete the following tasks:
Configure IP addresses for interfaces to ensure that neighboring Devices are reachable at
the network layer.
Configure basic OSPF functions.
Configure the IGP Shortcut.
Procedure
Step 1 Run system-view
Local MT is enabled.
NOTE
Local MT takes effect only to the OSPF process of a public network instance.
Local MT does not support Forwarding Adjacency (FA).
If the action specified in an ACL rule is deny, a route that matches the rule
will not be received or advertised by the system.
If a route has not matched any ACL rules, the route will not be received or
advertised by the system.
If an ACL does not contain any rules, all routes matching the route-policy that
references the ACL will not be received or advertised by the system.
If the ACL referenced by the route-policy does not exist, all routes matching
the route-policy will be received or advertised by the system.
In the configuration order, the system first matches a route with a rule that has
a smaller number and then matches the route with a rule with a larger number.
Routes can be filtered using a blacklist or a whitelist:
Route filtering using a blacklist: Configure a rule with a smaller number and
specify the action deny in this rule to filter out the unwanted routes. Then,
configure another rule with a larger number in the same ACL and specify the
action permit in this rule to receive or advertise the other routes.
Route filtering using a whitelist: Configure a rule with a smaller number and
specify the action permit in this rule to permit the routes to be received or
advertised by the system. Then, configure another rule with a larger number in
the same ACL and specify the action deny in this rule to filter out unwanted
routes.
Based on the IP prefix:
Run local-mt filter-policy ip-prefix ip-prefix-name
A routing policy is configured for local MT.
Based on the Route-Policy:
Run local-mt filter-policy route-policy route-policy-name
A routing policy is configured for local MT.
Based on the XPL Route-Policy:
Run local-mt filter-policy route-filter route-filter-name
A routing policy is configured for local MT.
After an MIGP routing table is created, OSPF performs route calculation. If the outbound
interface of the calculated route is an IGP Shortcut-enabled TE tunnel interface, the router
saves the physical interface on which the tunnel interface is configured as the outbound
interface in the MIGP routing table. Multicast packets are then forwarded along this route.
After the routing policy is configured, only the matching routes to the multicast source
address are added to the MIGP routing table, which controls the number of entries in the
MIGP routing table and speeds up MIGP routing table lookup.
Configure a routing policy before you enable local MT, because if an excessive number of
routes to a non-multicast source address exist in an MIGP routing table, the number of entries
may exceed the upper limit.
----End
Total Nets: 4
Intra Area: 4 Inter Area: 0 ASE: 0 NSSA: 0
Usage Scenario
Generally, BGP peers use BGP extended community attributes to carry routing information
over the BGP/MPLS IP VPN backbone network. PEs can use the routing information to
exchange inter-area routes between PEs and CEs through OSPF. OSPF sham links are
unnumbered P2P links between two PEs over an MPLS VPN backbone network. The source
and destination IP addresses of each sham link are IP addresses with a 32-bit mask of
loopback interfaces. The loopback interfaces must be bound to a VPN instance, and routes of
the two IP addresses are advertised through BGP.
On the BGP/MPLS IP VPN backbone network, if an intra-area OSPF link exists between the
network segment where the local CE resides and the network segment where the remote CE
resides, the route over this intra-area OSPF link is an intra-area route and has a higher priority
than the inter-area route over the BGP/MPLS IP VPN backbone network. In this case, VPN
traffic is always forwarded through this intra-area route. To prevent this problem, you can set
up an OSPF sham link between the PEs so that the route over the MPLS IP VPN backbone
network becomes an OSPF intra-area route and ensure that this route is preferentially
selected.
Pre-configuration Tasks
Before configuring an OSPF sham link, complete the following tasks:
Configure basic BGP/MPLS IP VPN functions and configure OSPF between each PE
and its corresponding CE.
Procedure
Step 1 Configure endpoint IP addresses for a sham link.
Perform the following steps on PEs at both ends of the sham link:
1. Run system-view
The system view is displayed.
2. Run interface loopback loopback-number
A loopback interface is created, and its view is displayed.
Each VPN instance must have an endpoint IP address of a sham link, and the IP address
is a loopback interface IP address with a 32-bit mask in the VPN address space of a PE.
Sham links of the same OSPF process can share the same endpoint IP address. The
endpoint IP addresses of sham links of different OSPF processes must be different.
3. Run ip binding vpn-instance vpn-instance-name
A VPN instance is bound to the loopback interface.
4. Run ip address ip-address { mask | mask-length }
An IP address is configured for the loopback interface.
NOTE
The configured IP address must have a 32-bit mask (255.255.255.255).
5. Run commit
The configuration is committed.
6. Run quit
Return to the system view.
Step 2 Advertise routes of the sham link's endpoint IP addresses.
Perform the following steps on PEs at both ends of the sham link:
1. Run bgp { as-number-plain | as-number-dot }
The BGP view is displayed.
2. Run ipv4-family vpn-instance vpn-instance-name
The BGP-VPN instance IPv4 address family view is displayed.
3. Run import-route direct
Import direct routes (routes of the sham link's endpoint IP addresses in this case) to BGP.
Routes of the sham link's endpoint IP addresses are advertised as VPN IPv4 routes by
BGP.
NOTE
Ensure that routes of the sham link's endpoint IP addresses are not exchanged by PEs through the VPN
OSPF process.
If routes of the sham link's endpoint IP addresses are exchanged by PEs through the VPN OSPF
process, each PE has two routes to the other endpoint of the sham link. One of the routes is learned
through the VPN OSPF process, and the other is learned through the MP-BGP connection. Because the
OSPF route has a higher priority than the BGP route, the OSPF route is selected, causing a sham link
establishment failure.
4. Run commit
The configuration is committed.
5. Run quit
Return to the BGP view.
6. Run quit
Return to the system view.
Step 3 Create an OSPF sham link.
Perform the following steps on PEs at both ends of the sham link:
1. Run ospf process-id [ router-id router-id ] vpn-instance vpn-instance-name
The OSPF multi-instance view is displayed.
2. Run area area-id
The OSPF area view is displayed.
3. Run sham-link soure-ip-address destination-ip-address [ smart-discover | cost cost |
hello hello-interval | dead dead-interval | retransmit retransmit-interval | trans-delay
trans-delay-interval | [ simple [ plain plain-text | [ cipher cipher-text | cipher-text ] |
{ md5 | hmac-md5 | hmac-sha256 } [ key-id { plain plain-text | cipher cipher-text |
cipher-text } ] | authentication-null | keychain keychain-name ] ] *
A sham link is created.
The authentication modes configured at the two ends must be the same. If packet
authentication is configured, only the OSPF packets that pass the authentication are
accepted; if the authentication fails, the OSPF neighbor relationship cannot be
established.
NOTE
To ensure that VPN traffic is forwarded over the MPLS backbone network, ensure that the cost of the
sham link is smaller than that of the OSPF route used to forward the traffic over the user network when
running the sham-link command. In most cases, you need to change the cost of the interfaces on the
user network to ensure that the cost of the OSPF route used to forward the traffic over the user network
is greater than that of the sham link.
----End
Run the display ip routing-table command on CEs to check the routing table.
Run the tracert host command on a CE to check the nodes through which data is
forwarded to the remote end.
Run the display ospf process-id sham-link [ area area-id ] command on PEs to check
whether the sham link is established.
Run the display ospf routing command on CEs to check OSPF routes.
# Run the display ip routing-table vpn-instance command on a PE. The following command
output shows that the route to the remote CE is an OSPF route over the user network rather
than the BGP route over the backbone network.
<HUAWEI> display ip routing-table vpn-instance vpn1
Route Flags: R - relay, D - download to fib, T - to vpn-instance, B - black hole
route
------------------------------------------------------------------------------
Routing Tables: vpn1
Destinations : 10 Routes : 10
Destination/Mask Proto Pre Cost Flags NextHop Interface
5.5.5.5/32 Direct 0 0 D 127.0.0.1 LoopBack10
6.6.6.6/32 IBGP 255 0 RD 3.3.3.9
GigabitEthernet2/0/0
8.8.8.8/32 IBGP 255 2 RD 3.3.3.9
GigabitEthernet2/0/0
10.1.1.0/24 OSPF 10 11 D 172.16.1.1
GigabitEthernet1/0/0
10.2.1.0/24 OSPF 10 12 D 172.16.1.1
GigabitEthernet1/0/0
172.16.1.0/24 Direct 0 0 D 172.16.1.2
GigabitEthernet1/0/0
172.16.1.2/32 Direct 0 0 D 127.0.0.1
GigabitEthernet1/0/0
172.16.1.255/32 Direct 0 0 D 127.0.0.1
GigabitEthernet1/0/0
172.16.2.0/24 IBGP 255 0 RD 3.3.3.9
GigabitEthernet2/0/0
255.255.255.255/32 Direct 0 0 D 127.0.0.1 InLoopBack0
# Run the display ip routing-table and tracert commands on the CE. The following
command outputs show that the VPN traffic to the remote end is forwarded over the backbone
network.
<HUAWEI> display ip routing-table
Route Flags: R - relay, D - download to fib, T - to vpn-instance, B - black hole
route
------------------------------------------------------------------------------
Routing Table : _public_
Destinations : 15 Routes : 15
Destination/Mask Proto Pre Cost Flags NextHop Interface
5.5.5.5/32 O_ASE 150 1 D 172.16.1.2
GigabitEthernet1/0/0
6.6.6.6/32 O_ASE 150 1 D 172.16.1.2
GigabitEthernet1/0/0
8.8.8.8/32 OSPF 10 3 D 172.16.1.2
GigabitEthernet1/0/0
10.1.1.0/24 Direct 0 0 D 10.1.1.1
GigabitEthernet2/0/0
10.1.1.1/32 Direct 0 0 D 127.0.0.1
GigabitEthernet2/0/0
10.1.1.255/32 Direct 0 0 D 127.0.0.1
GigabitEthernet2/0/0
10.2.1.0/24 OSPF 10 11 D 10.1.1.2
GigabitEthernet2/0/0
127.0.0.0/8 Direct 0 0 D 127.0.0.1 InLoopBack0
127.0.0.1/32 Direct 0 0 D 127.0.0.1 InLoopBack0
127.255.255.255/32 Direct 0 0 D 127.0.0.1 InLoopBack0
# Run the display ospf process-id sham-link area command on the PE. The following command output sho
the OSPF neighbor relationship between the PE and remote CE is in Full state.
# Run the display ospf routing command on the CE. The following command output shows that the route to
remote CE is an intra-area route.
<HUAWEI> display ospf routing
OSPF Process 1 with Router ID 10.1.1.1
Routing Tables
Routing for Network
Destination Cost Type NextHop AdvRouter Area
8.8.8.8/32 3 Stub 172.16.1.2 10.2.1.2 0.0.0.0
10.1.1.0/24 10 Direct 10.1.1.1 10.1.1.1 0.0.0.0
10.2.1.0/24 11 Transit 10.1.1.2 10.1.1.2 0.0.0.0
172.16.1.0/24 1 Direct 172.16.1.1 10.1.1.1 0.0.0.0
172.16.2.0/24 3 Transit 172.16.1.2 10.2.1.2 0.0.0.0
Routing for ASEs
Destination Cost Type Tag NextHop AdvRouter
6.6.6.6/32 1 Type2 3489661028 172.16.1.2 11.11.11.11
5.5.5.5/32 1 Type2 3489661028 172.16.1.2 22.22.22.22
Total Nets: 7
Intra Area: 5 Inter Area: 0 ASE: 2 NSSA: 0
Usage Scenario
OSPF enables the router to periodically send Hello packets to a neighboring router for fault
detection. Detecting a fault takes more than 1s. As voice, video, and other VOD services are
widely used. These services are sensitive to packet loss and delays. When traffic is
transmitted at gigabit rates, long-time fault detection will cause packet loss. This cannot meet
high reliability requirements of the carrier-class network. BFD for OSPF was introduced to
resolve this problem. After BFD for OSPF is configured in a specified process or on a
specified interface, the link status can be rapidly detected and fault detection can be
completed in milliseconds. This speeds up OSPF convergence when the link status changes.
Pre-configuration Tasks
Before configuring BFD for OSPF, complete the following tasks:
Configure IP addresses for interfaces to ensure that neighboring nodes are reachable at
the network layer.
Configure basic OSPF functions.
Configuration Procedures
Perform one or more of the following configurations as required.
Procedure
Step 1 Run system-view
The system view is displayed.
Step 2 Run bfd
BFD is globally configured.
Step 3 Run quit
Return to the system view.
Step 4 Run ospf [ process-id ]
The OSPF process view is displayed.
Step 5 Run bfd all-interfaces enable
BFD for OSPF is configured. The default parameter values are used to create a BFD session.
If all the interfaces in a certain process are configured with BFD and their neighbor
relationships are in the Full state, OSPF creates BFD sessions with default parameter values
on all the interfaces in the process.
Step 6 (Optional) Run bfd all-interfaces { min-rx-interval receive-interval | min-tx-interval
transmit-interval | detect-multiplier multiplier-value | frr-binding } *
You can skip this step. The default interval at which BFD packets are transmitted and the
default detection multiplier are recommended.
The parameters are configured based on the network status and network reliability
requirements. A short interval at which BFD packets are transmitted can be configured for a
link that has a higher requirement for reliability. A long interval at which BFD packets are
transmitted can be configured for a link that has a lower requirement for reliability.
NOTE
Actual interval at which BFD packets are transmitted on the local router = Max { configured interval
transmit-interval at which BFD packets are transmitted on the local router, configured interval receive-
interval at which BFD packets are received on the peer router }
Actual interval at which BFD packets are received on the local router = Max { configured interval
transmit-interval at which BFD packets are transmitted on the peer router, configured interval receive-
interval at which BFD packets are received on the local router }
Actual time for detecting BFD packets = Actual interval at which BFD packets are received on the local
router x Configured detection multiplier multiplier-value on the peer router
For example:
On the local router, the configured interval at which BFD packets are transmitted is 200 ms; the
configured interval at which BFD packets are received is 300 ms; the detection multiplier is 4.
On the peer router, the configured interval at which BFD packets are transmitted is 100 ms; the interval at
which BFD packets are received is 600 ms; the detection multiplier is 5.
Then:
On the local router, the actual interval at which BFD packets are transmitted is 600 ms calculated by
using the formula max {200 ms, 600 ms}; the interval at which BFD packets are received is 300 ms
calculated by using the formula max {100 ms, 300 ms}; the detection period is 1500 ms calculated by
multiplying 300 ms by 5.
On the peer router, the actual interval at which BFD packets are transmitted is 300 ms calculated by using
the formula max {100 ms, 300 ms}, the actual interval at which BFD packets are received is 600 ms
calculated by using the formula max {200 ms, 600 ms}, and the detection period is 2400 ms calculated by
multiplying 600 ms by 4.
After BFD for OSPF is configured, all interfaces on which neighbor relationships are Full in
the OSPF process will create BFD sessions. To prevent specific interfaces from being enabled
with BFD, disable these interfaces from dynamically creating BFD sessions.
1. Run quit
----End
Context
After BFD for OSPF is configured on a specified interface and the interface becomes faulty,
the router rapidly detects the fault and instructs OSPF to recalculate routes. This speeds up
OSPF convergence. When the OSPF neighbor relationship goes Down, the BFD session
between OSPF neighbors is dynamically deleted.
Before configuring BFD for OSPF, enable BFD globally.
Perform the following steps on the router:
Procedure
Step 1 Run system-view
The system view is displayed.
Step 2 Run bfd
BFD is globally configured.
Step 3 Run quit
Return to the system view.
Step 4 Run interface interface-type interface-number
The interface view is displayed.
Step 5 Run ospf bfd enable [ per-link one-arm-echo ]
BFD for OSPF is configured. The default parameter values are used to create a BFD session.
If all the interfaces in a certain process are configured with BFD and their neighbor
relationships are in the Full state, OSPF creates BFD sessions with default parameter values
on specified interfaces in the process.
If multiple physical interfaces are bound to an Eth-Trunk in a VLAN and per-link one-arm-
echo is not specified, the BFD session may go Down as long as one of the physical interfaces
goes Down. As a result, the OSPF neighbor relationship goes Down. If per-link one-arm-
echo is specified in this case, the BFD session goes Down only if all the physical interfaces
are Down, which prevents the OSPF neighbor relationship from going Down.
NOTE
The priority of BFD for OSPF configured on an interface is higher than that of BFD for OSPF
configured for a process.
The parameters are configured based on the network status and network reliability
requirements. A short interval at which BFD packets are transmitted can be configured for a
link that has a higher requirement for reliability. A long interval at which BFD packets are
transmitted can be configured for a link that has a lower requirement for reliability.
NOTE
Actual interval at which BFD packets are transmitted on the local router = Max { configured interval
transmit-interval at which BFD packets are transmitted on the local router, configured interval receive-
interval at which BFD packets are received on the peer router }
Actual interval at which BFD packets are received on the local router = Max { configured interval
transmit-interval at which BFD packets are transmitted on the peer router, configured interval receive-
interval at which BFD packets are received on the local router }
Actual time for detecting BFD packets = Actual interval at which BFD packets are received on the local
router x Configured detection multiplier multiplier-value on the peer router
For example:
On the local router, the configured interval at which BFD packets are transmitted is 200 ms; the interval at
which BFD packets are received is set to 300 ms; the detection multiplier is 4.
On the peer router, the configured interval at which BFD packets are transmitted is 100 ms; the interval at
which BFD packets are received is 600 ms; the detection multiplier is 5.
Then:
On the local router, the actual interval at which BFD packets are transmitted is 600 ms calculated by
using the formula max {200 ms, 600 ms}; the interval at which BFD packets are received is 300 ms
calculated by using the formula max {100 ms, 300 ms}; the detection period is 1500 ms calculated by
multiplying 300 ms by 5.
On the peer router, the actual interval at which BFD packets are transmitted is 300 ms calculated by using
the formula max {100 ms, 300 ms}, the actual interval at which BFD packets are received is 600 ms
calculated by using the formula max {200 ms, 600 ms}, and the detection period is 2400 ms calculated by
multiplying 600 ms by 4.
----End
Prerequisites
BFD for OSPF has been configured.
Procedure
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
Example
Run the display ospf bfd session all command to view the "BFDState:up" field. The
following example shows that the field is Up, indicating that the BFD session on the local
router is Up.
<HUAWEI> display ospf bfd session all
NeighborId:2.2.2.2 BFDState:up
LocalIpAdd:2.2.2.1 RemoteIpAdd:2.2.2.2
Usage Scenario
As networks develop, services such as Voice over IP (VoIP) and on-line video services
require high-quality real-time transmission. Nevertheless, if an OSPF fault occurs, traffic can
be switched to a new link only after the fault detection that lasts milliseconds, fault
notification
to the routing control plane that lasts milliseconds, new topology information generation and
flooding that lasts milliseconds, Shortest Path First (SPF) calculation that lasts tens of
milliseconds, and new route notification and adding that lasts hundreds of milliseconds. As a
result, it takes much more than 50 ms, the maximum convergence time tolerable for VoIP and
on-line video services, which cannot meet the requirement for real-time services on the
network.
With OSPF IP FRR that calculates a backup link in advance, devices can fast switch traffic to
the backup link without interrupting traffic if the primary link fails, which protects traffic and
improves OSPF network reliability.
As shown in Figure 5-4, traffic flows from Router S to Router D. The preceding inequality is
met. Router S switches the traffic to the backup link if the primary link fails.
DeviceN
NOTE
OSPF IP FRR also applies to node protection. For details, see "OSPF" in HUAWEI NetEngine40E
Feature Description.
OSPF IP FRR is applicable to services that are sensitive to packet delay and packet loss.
The NE40E supports OSPF IP FRR that uses LFA or Remote LFA as the algorithm.
LFA Auto FRR cannot be used to calculate alternate links on large-scale networks, especially
on ring networks. To address this problem, enable Remote LFA Auto FRR. Remote LFA takes
effect only when LFA has been enabled.
Both OSPF LFA FRR and OSPF remote LFA FRR use the SPF algorithm to calculate the
shortest path to the destination node, with each neighbor that provides a backup link as the
root node. The backup next hop is node-based, which applies to single-source routing
scenarios. As networks are increasingly diversified, two ABRs or ASBRs are deployed to
improve network reliability. In this case, OSPF FRR in a multi-source routing scenario is
needed. In Figure 5-5, Device B and Device C function as ABRs to forward area 0 and area 1
routes. Device E advertises an intra-area route. Upon receipt of the route, Device B and
Device C translate it to a Type 3 LSA and flood the LSA to area 0. After OSPF FRR is
enabled on Device A, Device A considers Device B and Device C as its neighbors. Without a
fixed neighbor as the root node, Device A fails to calculate FRR backup next hop. To address
this problem, a virtual node is simulated between Device B and Device C and used as the root
node of Device A, and Device A uses the LFA or remote LFA algorithm to calculate the
backup next hop. This solution converts multi-source routing into single-source routing.
Area 1
Area 0
Device A Device B
Device D Device C
After OSPF IP FRR is configured, the lower layer needs to fast respond to a link change so
that traffic can be fast switched to the backup link. After FRR and BFD are bound, link
failures can be detected rapidly so that traffic is rapidly switched to the backup link if the
primary link fails.
Pre-configuration Tasks
Before configuring OSPF IP FRR, complete the following tasks:
Configuration Procedures
Block FRR on a
specified
OSPF interface
Mandatory procedure
Optional procedure
Context
Perform the following steps on the router:
Procedure
Step 1 Run system-view
Issue 01 (2018-12- Copyright © Huawei Technologies Co., 2
HUAWEI NetEngine40E Universal Service
Router 5 OSPF
NOTE
OSPF can generate a loop-free backup link only when the OSPF IP FRR traffic protection inequality is
met. For detailed description of OSPF IP FRR, see HUAWEI NetEngine40E Feature Description- OSPF
IP FRR.
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 If you want to configure remote LFA Auto FRR, perform the following steps:
1. Run remote-lfa tunnel ldp [ maximum-reachable-cost cost-value ]
Only the PQ node that matches the filtering policy can be used as the next hop of an LFA
link.
3. (Optional) Run avoid-microloop frr-protected
If OSPF remote LFA FRR is enabled and the primary link fails, traffic is switched to the
backup link. If route convergence occurs again, traffic is switched from the backup link
to a new primary link. During the switchover, microloop may occur. To prevent this
problem, OSPF anti-microloop is enabled and delays the switching. To configure the
delay, run the avoid-microloop frr-protected rib-update-delay command. After the
command is run, OSPF does not switch traffic to the backup link until the delay elapses.
NOTE
OSPF anti-microloop applies only to OSPF remote LFA FRR.
By default, the solution of selecting a backup path for OSPF IP FRR is node-protection path
first. In some cases, the solution needs to be changed to smallest-cost path first because of
data forwarding capacity or link cost consideration. In Figure 5-7, the primary path is Link-1
(Device S -> Device E -> Device D), and Link-2 and Link-3 (Device S -> Device N ->
Device D) are backup path candidates. By default, Link-3 is selected as the backup path. To
change the solution of selecting a backup path for OSPF IP FRR to smallest-cost path first,
run the tiebreaker command. After the command is run, Link-2 is selected as the backup
path.
Link-2 cost = 20
Link-3
DeviceN
Figure 5-8 shows an inter-board scenario, where Link-1 (Device A -> Device D) is the
primary path, and Link-2 (Device A -> Device E -> Device D) is the backup path. If Link-1
fails, Link-2 functions as the new primary path, and Link-3 (Device A->Device B->Device C-
>Device D) functions as the new backup path. If Link-1 goes Up again but the LDP session
has not gone Up, OSPF enters the Hold-max-cost state. Consequently, the primary path is still
Link-2, and the backup path is still Link-3. If the LDP session goes Up but ldp-sync hold-
max-cost is not configured, OSPF exits from the Hold-max-cost state when the timer used to
delay sending an LDP session Up message expires. In this case, OSPF switches the primary
path back to Link-1. Because the upstream and downstream entries reside on different boards
and the downstream entry has not been updated when downstream traffic arrives, packet loss
occurs. To resolve the problem, configure ldp-sync hold-max-cost so that OSPF
preferentially selects the path with the maximum cost set by LDP-IGP synchronization when
OSPF is in the Hold-max-cost state. Then OSPF switches the backup path to Link-1 and
delivers the backup forwarding entry in advance. When the timer used to delay sending an
LDP session Up message expires, OSPF exits from the Hold-max-cost state and switches the
primary path to Link-1. Because the downstream backup entry is available, no packet loss
occurs.
DeviceE
DeviceD DeviceC
----End
Context
After the parameter frr-binding is set to bind the BFD status to the link status of an interface,
link failures can be detected rapidly. This ensures that traffic is rapidly switched to the backup
link if the primary link fails.
Perform the following steps on the router where IP FRR and BFD need to be bound:
Procedure
Bind IP FRR and BFD in an OSPF process.
a. Run system-view
NOTE
The BFD configuration on an interface takes precedence over that in an OSPF process.
d. Run commit
----End
Procedure
Step 1 Run system-view
The system view is displayed.
Step 2 Run interface interface-type interface-number
The view of an OSPF interface on which FRR is enabled is displayed.
Step 3 Run ospf frr block
FRR is blocked on the OSPF interface.
Step 4 (Optional) Run ospf remote-lfa disable
Interfaces of the specified level are disabled from being calculated as the Remote LFA next
hop.
Step 5 Run commit
The configuration is committed.
----End
Prerequisites
OSPF IP FRR has been configured.
Procedure
Run the display ospf [ process-id ] routing command to check the information about the
primary and backup links after configuring OSPF IP FRR.
----End
Example
View the routes to a specified OSPF router, including information about the backup next hop.
<HUAWEI> display ospf routing 10.1.1.1
OSPF Process 1 with Router ID 1.1.1.1
Destination : 10.1.1.0/24
AdverRouter : 10.1.1.1 Area : 0.0.0.0
Cost : 1 Type : Transit
NextHop : 10.1.1.2 Interface : GE1/0/0
Priority : High Age : 09h20m11s
Backup NextHop : 10.1.1.3 Backup Interface : GE1/0/1
Backup Type : LFA LINK Tunnel Destination : 3.3.3.3
Tunnel Type : LDP
Usage Scenario
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
GR includes the GR restarter and GR helper. NE40E supports the GR Helper only.
Pre-configuration Tasks
Before configuring OSPF GR, complete the following tasks:
Configure IP addresses for interfaces to ensure that neighboring nodes are reachable at
the network layer.
Configure basic OSPF functions.
Procedure
Step 1 Run system-view
OSPF supports OSPF GR through Type 9 LSAs (Opaque LSAs). Therefore, before
configuring OSPF GR, run the opaque-capability enable command to enable the Opaque-
LSA capability.
Step 4 Configure GR session parameters on the helper.
1. Run graceful-restart helper-role ignore-external-lsa
Usage Scenario
With the increase in attacks on TCP/IP networks and the defects in the TCP/IP protocol suite,
network attacks have increasing impacts on the network security. Attacks on network devices
may lead to network crash. By configuring GTSM and authentication, you can improve OSPF
network security.
OSPF authentication encrypts OSPF packets by adding the authentication field to packets to
ensure network security. When a local device receives OSPF packets from a remote device,
the local device discards the packets if the authentication passwords carried in these packets
do not match the local one, which protects the local device from potential attacks.
In terms of the packet type, the authentication is classified as follows:
Area authentication
Area authentication is configured in the OSPF area view and applies to packets received
by all interfaces in the OSPF area.
Interface authentication
Interface authentication is configured in the interface view and applies to all packets
received by the interface.
The NE40E supports the following authentication modes:
Simple authentication
MD5 authentication
HMAC-MD5 authentication
Keychain authentication
NOTE
The NE40E supports OSPF GTSM. For detailed configuration of OSPF GTSM, refer to the HUAWEI
NetEngine40E Configuration Guide - Security
Pre-configuration Tasks
Before improving OSPF network security, complete the following tasks:
Configuration Procedures
Perform one or more of the following configurations as required.
Context
NOTE
By default, authentication is not configured for OSPF area. Configuring authentication is recommended
to ensure system security.
Procedure
Step 1 Run system-view
For the sake of security, using the HMAC-SHA256 algorithm rather than the MD5 and HMAC-
MD5 algorithm is recommended.
Run authentication-mode keychain keychain-name
The Keychain authentication is configured for the OSPF area.
NOTE
Before using the Keychain authentication, you must run the keychain command to create a
keychain. Then, run the key-id, key-string, and algorithm commands to configure a key ID, a
password, and an authentication algorithm for this keychain. Otherwise, the OSPF authentication
will fail.
----End
Context
NOTE
By default, authentication is not configured for OSPF interface. Configuring authentication is
recommended to ensure system security.
Procedure
Step 1 Run system-view
The system view is displayed.
Step 2 Run interface interface-type interface-number
The OSPF interface view is displayed.
Step 3 Run any of the following commands to configure interface authentication as required:
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 password in simpletext. For simple authentication, cipher-text
passwords are used by default.
– cipher indicates the cipher-text password. For MD5, HMAC-MD5 or HMAC-
SHA256 authentication, cipher-text passwords are used by default.
When configuring an authentication password, select the ciphertext mode because the
password is saved in configuration files in simpletext if you select simpletext mode,
which has a high risk. To ensure device security, change the password periodically.
Run ospf authentication-mode { md5 | hmac-md5 | hmac-sha256 } [ key-id { plain
plain-text | [ cipher ] cipher-text } ]
Cipher-text authentication 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.
NOTE
For the sake of security, using the HMAC-SHA256 algorithm rather than the MD5 and HMAC-
MD5 algorithm is recommended.
Run ospf authentication-mode keychain keychain-name
The Keychain authentication is configured for the OSPF interface.
NOTE
Before using the Keychain authentication, you must run the keychain command to create a
keychain. Then, run the key-id, key-string, and algorithm commands to configure a key ID, a
password, and an authentication algorithm for this keychain. Otherwise, the OSPF authentication
will fail.
Run ospf authentication-mode null
The OSPF interface does not perform authentication.
Step 4 Run commit
The configuration is committed.
----End
Procedure
Run the display this command to view the configurations of the system in the current
view.
----End
Example
Run the display this command to view the configurations of the system in the current view.
<HUAWEI> system-view
[~HUAWEI] display this
#
interface GigabitEthernet1/0/0
ospf authentication-mode simple
#
Usage Scenario
Through the Simple Network Management Protocol (SNMP), the OSPF Management
Information Base (MIB) manages information exchanged between the NMS and agents.
Pre-configuration Tasks
Before configuring the network management function of OSPF, complete the following tasks:
Configure a link layer protocol.
Configure IP addresses for interfaces to ensure that neighboring nodes are reachable at
the network layer.
Configure basic OSPF functions.
Procedure
Step 1 Run system-view
The system view is displayed.
Step 2 Run ospf mib-binding process-id
----End
Run the display ospf [ process-id ] brief command to view information about the binding of
OSPF MIBs and OSPF processes.
Context
OSPF information cannot be restored after you clear it. Exercise caution when clearing it.
To clear OSPF information, run the following reset commands in the user view.
Procedure
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.
Run the reset ospf [ process-id ] counters maxage-lsa command to delete the statistics
about router LSAs that have reached the aging time.
Run the reset ospf [ process-id ] frr command to perform OSPF IP FRR calculation
again.
Run the reset ospf [ process-id ] peer [ interface-type interface-number ] router-id
command to restart an OSPF neighbor.
----End
Context
The OSPF neighbor relationships will be torn down if you run the reset ospf command to
reset OSPF connections. Exercise caution when running the command.
Usage Scenario
In OSPF, intra-area links take precedence over inter-area links. Therefore, even if a high-
speed link exists between two areas, a low-speed intra-network link rather than the high-speed
link is used to transmit inter-area traffic. To address this problem, run the ospf enable multi-
area command to enable OSPF on a multi-area adjacency interface so that a link can be
shared by multiple areas.
Among the OSPF features supported by an OSPF multi-area adjacency interface, some can be
inherited from the main interface, whereas others need to be configured independently. For
details, see Table 5-4.
BFD for BFD for OSPF can be inherited from main 5.21.6 Disabling an OSPF Multi- Area
OSPF interfaces, except for the configuration that Adjacency Interface from Creating BF
disables BFD from an interface. This Sessions
configuration needs to be configured
independently for OSPF multi-area adjacency
interfaces.
OSPF OSPF multi-area adjacency interfaces support 5.21.4 Configuring Fast Convergence
fast OSPF fast convergence which needs to be for a Multi-Area Adjacency Interface
converg configured independently for these interfaces
ence and cannot be inherited from their main
interfaces.
OSPF OSPF multi-area adjacency interfaces support 5.21.7 Disabling OSPF IP FRR on an O
IP FRR OSPF IP FRR. OSPF IP FRR can be inherited Multi-Area Adjacency Interface
from main interfaces, except for the
configuration that disables FRR from a specified
OSPF interface. This configuration needs to be
configured independently for OSPF multi-area
adjacency interfaces.
OSPF OSPF multi-area adjacency interfaces support 5.21.5 Configuring Neighbor Relations
neighbo OSPF neighbor relationship flapping Flapping Suppression on an OSPF Mu
r suppression which needs to be configured Area Adjacency Interface
relation independently for these
ship interfaces and cannot be inherited from their
flapping main interfaces.
suppres
sion
OSPF OSPF multi-area adjacency interfaces support 5.9 Configuring OSPF Flush LSA Sour
flush OSPF flush LSA source tracing which can be Tracing
LSA inherited from their main interfaces.
source
tracing
OSPF OSPF multi-area adjacency interfaces inherit TE Configuring IGP TE (OSPF or IS-IS)
TE information from their main interfaces.
Pre-configuration Tasks
Before configuring OSPF multi-area adjacency, complete the following tasks:
Configuration Procedures
Mandatory
Optional
Procedure
Step 1 Run system-view
The system view is displayed.
The multi-area adjacency interface is configured to add its MTU to the DD packets to be sent
and check whether the MTU in each received DD packet exceeds the local interface MTU.
The default MTU may vary with the device manufacturer. To keep consistency, prevent the
interface from adding its MTU to the DD packets to be sent.
----End
Procedure
Step 1 Run system-view
----End
Procedure
Step 1 Run system-view
The system view is displayed.
Step 2 Run interface interface-type interface-number
The interface view is displayed.
Step 3 Run ospf enable [ process-id ] area area-id
OSPF is enabled on the interface.
Step 4 Run ospf enable multi-area area-id
OSPF is enabled on the multi-area adjacency interface.
Step 5 Run either of the following commands:
Run the ospf authentication-mode simple [ plain plain-text | [ cipher ] cipher-text ]
multi-area area-id command to configure simple authentication for the multi-area
adjacency interface.
Run the ospf authentication-mode { md5 | hmac-md5 | hmac-sha256 } [ key-id
{ plain plain-text | [ cipher ] cipher-text } ] multi-area area-id command to configure
ciphertext authentication for the multi-area adjacency interface.
Run the ospf authentication-mode keychain keychain-name multi-area area-id
command to configure keychain authentication for the multi-area adjacency interface.
Run the ospf authentication-mode null multi-area area-id command to configure null
authentication for the multi-area adjacency interface.
Step 6 Run commit
The configuration is committed.
----End
The interval at which Hello packets are sent is configured on the multi-area
adjacency interface.
f. Run commit
The configuration is committed.
Configure the dead interval of OSPF neighbor relationships for a multi-area adjacency
interface.
a. Run system-view
The system view is displayed.
b. Run interface interface-type interface-number
The interface view is displayed.
c. Run ospf enable [ process-id ] area area-id
OSPF is enabled on the interface.
d. Run ospf enable multi-area area-id
OSPF is enabled on the multi-area adjacency interface.
e. Run ospf timer dead interval multi-area area-id
The dead interval of OSPF neighbor relationships is configured for the multi-area
adjacency interface.
f. Run commit
The configuration is committed.
Configure an LSA retransmission interval on a multi-area adjacency interface.
a. Run system-view
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.
NOTE
The following steps are optional, choose them as required.
Procedure
Step 1 Run system-view
The system view is displayed.
Flapping suppression can also work first in Hold-down mode and then in Hold-max-cost
mode.
To disable the Hold-max-cost mode, run the ospf suppress-flapping peer hold-max-cost
disable multi-area command.
Step 7 Run ospf suppress-flapping peer { detecting-interval detecting-interval | threshold
threshold | resume-interval resume-interval } * multi-area area-id
Detection parameters are configured for OSPF neighbor relationship flapping suppression on
an OSPF multi-area adjacency interface.
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.
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.
You can configure the detection parameters as required. However, keeping the default
configurations is recommended. By default, the detection interval of OSPF neighbor
relationship flapping suppression on multi-area adjacency interfaces is 60s, the suppression
threshold is 10, and the interval for exiting from suppression is 120s.
Step 8 Run quit
The system view is displayed.
Step 9 Run quit
The user view is displayed.
Step 10 Run reset ospf suppress-flapping process-id peer [ interface-name [ all-areas | area
area- id ] ] | [ interface-type interface-number [ all-areas | area area-id ] ] [ notify-peer ]
The OSPF process or the multi-area adjacency interface is configured to exit from OSPF
neighbor relationship flapping suppression.
NOTE
The OSPF process or interface exits from flapping suppression in the following scenarios:
The suppression timer expires.
The corresponding OSPF process is reset.
An OSPF neighbor is reset using the reset ospf peer command.
OSPF neighbor relationship flapping suppression is disabled globally using the suppress-flapping
peer disable (OSPF) command.
The reset ospf suppress-flapping peer command is run.
----End
Procedure
Step 1 Run system-view
The system view is displayed.
Step 2 Run interface interface-type interface-number
The interface view is displayed.
Step 3 Run ospf enable [ process-id ] area area-id
OSPF is enabled on the interface.
The OSPF multi-area adjacency interface is disabled from creating BFD sessions.
----End
Procedure
Step 1 Run system-view
Remote loop-free alternate (LFA) is disabled on the OSPF multi-area adjacency interface.
----End
Context
If a member interface of an Eth-Trunk multi-area adjacency interface goes down, the
remaining bandwidth of the Eth-Trunk multi-area adjacency interface may fail to meet user
requirements. As a result, user services are affected. To address this problem, run the ospf
cost-fallback multi-area command to configure cost-fallback parameters (fallback cost and
bandwidth threshold) for the Eth-Trunk multi-area adjacency interface; if the remaining
bandwidth of the interface goes below the bandwidth threshold, the cost of the interface is
changed to the fallback cost which is higher than the normal cost, and traffic is then switched
to an alternative path; when the remaining bandwidth of the interface reaches or exceeds the
bandwidth threshold, the original cost is restored.
Procedure
Step 1 Run system-view
The system view is displayed.
Step 2 Run interface eth-trunk trunk-id
The Eth-Trunk interface view is displayed.
Step 3 Run ospf enable [ process-id ] area area-id
OSPF is enabled on the interface.
Step 4 Run ospf enable multi-area area-id
OSPF is enabled on the multi-area adjacency interface.
Step 5 Run ospf cost-fallback fallbackcost threshold fallbackbw multi-area area-id
A fallback cost is configured for an Eth-Trunk multi-area adjacency interface.
Step 6 Run commit
The configuration is committed.
----End
OSPF statistics cannot be restored after being cleared. Therefore, exercise caution before
clearing the OSPF statistics.
To clear OSPF statistics, run the following command in the user view.
Procedure
Run reset ospf [ process-id ] counters [ neighbor [ interface-type interface-number
[ all-areas | area area-id ] ] | [ interface-name [ all-areas | area area-id ] ] [ router-id ] ]
Prerequisites
OSPF multi-area adjacency has been configured.
Procedure
Run the following commands and check (M) Indicates MADJ interface, Multi-area
interface, and Multi-area Interface Count fields to view configurations on the multi-
area adjacency interface:
– display ospf brief
– display ospf interface
– display ospf peer
----End
Networking Requirements
On the network shown in Figure 5-10, all routers run OSPF, and the entire AS is divided into
three areas. Device A and Device B function as ABRs to forward inter—area routes.
After the configuration is complete, each router should learn the routes to all network
segments in the AS.
Interface 1 and interface 2 in this example are GE 1/0/0 and GE 2/0/0, respectively.
Area0
interface1
192.168.0.2/24
DeviceA interface1 Device
interface2 192.168.0.1/24 interface2
192.168.1.1/24 192.168.2.
interface1 interface1
192.168.1.2/24 192.168.2.
DeviceC Device
interface2 interface2
172.16.1.1/24 172.17.1.1/24
interface2 interface2
172.16.1.2/24 172.17.1.2/24
DeviceE DeviceF
Area1 Area2
Precautions
When configuring basic OSPF functions, note the following rules:
The backbone area is responsible for forwarding inter-area routes. In addition, the
routing information between non-backbone areas must be forwarded through the
backbone area. OSPF defines the following rules for the backbone area:
– Connectivity must be available between non-backbone areas and the backbone area.
– Connectivity must be available over the backbone area.
The intervals at which Hello, Dead, and Poll packets are sent on the local interface must
be the same as those on the remote interface. Otherwise, the OSPF neighboring
relationship cannot be established.
Configuration Roadmap
The configuration roadmap is as follows:
Data Preparation
To complete the configuration, you need the following data:
Procedure
Step 1 Assign an IP address to each interface. For configuration details, see Configuration Files in
this section.
Step 2 Configure basic OSPF functions.
# Configure Device A.
[~DeviceA] router id 1.1.1.1
[~DeviceA] ospf 1
[*DeviceA-ospf-1] area 0
[*DeviceA-ospf-1-area-0.0.0.0] network 192.168.0.0 0.0.0.255
[*DeviceA-ospf-1-area-0.0.0.0] quit
[*DeviceA-ospf-1] area 1
[*DeviceA-ospf-1-area-0.0.0.1] network 192.168.1.0 0.0.0.255
[*DeviceA-ospf-1-area-0.0.0.1] quit
[*DeviceA-ospf-1] commit
# Configure Device B.
[~DeviceB] router id 2.2.2.2
[~DeviceB] ospf 1
[*DeviceB-ospf-1] area 0
[*DeviceB-ospf-1-area-0.0.0.0] network 192.168.0.0 0.0.0.255
[*DeviceB-ospf-1-area-0.0.0.0] quit
[*DeviceB-ospf-1] area 2
[*DeviceB-ospf-1-area-0.0.0.2] network 192.168.2.0 0.0.0.255
[*DeviceB-ospf-1-area-0.0.0.2] quit
[*DeviceB-ospf-1] commit
# Configure Device C.
[~DeviceC] router id 3.3.3.3
[~DeviceC] ospf 1
[*DeviceC-ospf-1] area 1
[*DeviceC-ospf-1-area-0.0.0.1] network 192.168.1.0 0.0.0.255
[*DeviceC-ospf-1-area-0.0.0.1] network 172.16.1.0 0.0.0.255
[*DeviceC-ospf-1-area-0.0.0.1] commit
[~DeviceC-ospf-1-area-0.0.0.1] quit
# Configure Device D.
[~DeviceD] router id 4.4.4.4
[~DeviceD] ospf 1
[*DeviceD-ospf-1] area 2
[*DeviceD-ospf-1-area-0.0.0.2] network 192.168.2.0 0.0.0.255
[*DeviceD-ospf-1-area-0.0.0.2] network 172.17.1.0 0.0.0.255
[*DeviceD-ospf-1-area-0.0.0.2] commit
[~DeviceD-ospf-1-area-0.0.0.2] quit
# Configure Device E.
[~DeviceE] router id 5.5.5.5
[~DeviceE] ospf 1
[*DeviceE-ospf-1] area 1
[*DeviceE-ospf-1-area-0.0.0.1] network 172.16.1.0 0.0.0.255
[*DeviceE-ospf-1-area-0.0.0.1] commit
[~DeviceE-ospf-1-area-0.0.0.1] quit
# Configure Device F.
[~DeviceF] router id 6.6.6.6
[~DeviceF] ospf 1
[*DeviceF-ospf-1] area 2
[*DeviceF-ospf-1-area-0.0.0.2] network 172.17.1.0 0.0.0.255
[*DeviceF-ospf-1-area-0.0.0.2] commit
[~DeviceF-ospf-1-area-0.0.0.2] quit
Total Nets: 3
Intra Area: 1 Inter Area: 2 ASE: 0 NSSA: 0
Area: 0.0.0.0
Type LinkState ID AdvRouter Age Len Sequence Me
Router 1.1.1.1 1.1.1.1 93 48 80000004
Router 2.2.2.2 2.2.2.2 92 48 80000004
Sum-Net 172.16.1.0 1.1.1.1 1287 28 80000002
Sum-Net 192.168.1.0 1.1.1.1 1716 28 80000001
Sum-Net 172.17.1.0 2.2.2.2 1336 28 80000001
Sum-Net 192.168.2.0 2.2.2.2 87 28 80000002
Area: 0.0.0.1
Type LinkState ID AdvRouter Age Len Sequence Metric
Router 1.1.1.1 1.1.1.1 1420 48 80000002 1
Router 3.3.3.3 3.3.3.3 1294 60 80000003 1
Router 5.5.5.5 5.5.5.5 1296 36 80000002 1
Network 172.16.1.1 3.3.3.3 1294 32 80000001 0
Sum-Net 172.17.1.0 1.1.1.1 1325 28 80000001 3
Sum-Net 192.168.0.0 1.1.1.1 1717 28 80000001 1
Sum-Net 192.168.2.0 1.1.1.1 1717 28 80000001 2
# Display the routing table on Device D and perform the ping operation to test the
connectivity.
[~DeviceD] display ospf routing
Total Nets: 3
Intra Area: 0 Inter Area: 3 ASE: 0 NSSA: 0
[~DeviceD] 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
Reply from 172.16.1.1: bytes=56 Sequence=2 ttl=253 time=16 ms
Reply from 172.16.1.1: bytes=56 Sequence=3 ttl=253 time=62 ms
Reply from 172.16.1.1: bytes=56 Sequence=4 ttl=253 time=94 ms
Reply from 172.16.1.1: bytes=56 Sequence=5 ttl=253 time=63 ms
----End
Configuration Files
Device A configuration file
#
sysname DeviceA
#
router id 1.1.1.1
#
interface GigabitEthernet1/0/0
undo shutdown
ip address 192.168.0.1 255.255.255.0
#
interface
GigabitEthernet2/0/0 undo
shutdown
ip address 192.168.1.1 255.255.255.0
#
ospf 1
area 0.0.0.0
network 192.168.0.0
0.0.0.255 area 0.0.0.1
network 192.168.1.0 0.0.0.255
#
return
Device B configuration file
#
sysname DeviceB
#
router id 2.2.2.2
#
interface
GigabitEthernet1/0/0 undo
shutdown
ip address 192.168.0.2 255.255.255.0
#
interface
GigabitEthernet2/0/0 undo
shutdown
ip address 192.168.2.1 255.255.255.0
#
ospf 1
area 0.0.0.0
network 192.168.0.0
0.0.0.255 area 0.0.0.2
network 192.168.2.0 0.0.0.255
#
Device C configuration file
#
sysname DeviceC
#
router id 3.3.3.3
#
interface
GigabitEthernet1/0/0 undo
shutdown
ip address 192.168.1.2 255.255.255.0
#
interface
GigabitEthernet2/0/0 undo
shutdown
ip address 172.16.1.1 255.255.255.0
#
ospf 1
area 0.0.0.1
network 192.168.1.0
0.0.0.255 network
172.16.1.0 0.0.0.255
Device D configuration file
#
sysname DeviceD
#
router id 4.4.4.4
#
interface
GigabitEthernet1/0/0 undo
shutdown
ip address 192.168.2.2 255.255.255.0
#
interface
Networking Requirements
On the network shown in Figure 5-11, Area 2 is not directly connected to the backbone area
Area 0. Area 1 serves as a transit area to connect Area 2 and Area 0. A virtual link is
configured between Device A and Device B.
Area1
interface1 interface1
DeviceA 192.168.1.1/24 192.168.1.2/24 Device
interface2 interface2
10.1.1.2/8 172.16.1.2/
DeviceC Device
Area0 Area2
Precautions
The default value is recommended when a virtual link is created. You can modify the value in
actual scenarios.
The smaller the hello parameter, the more rapidly a router detects network topology
change, the more network resources are consumed.
If the retransmit parameter is set too small, LSAs may be retransmitted. Setting the
parameter to a large value is recommended in a low-speed network.
The authentication modes of a virtual link and the backbone area must be the same.
Configuration Roadmap
The configuration roadmap is as follows:
Data Preparation
To complete the configuration, you need the following data:
Procedure
Step 1 Assign an IP address to each interface. For configuration details, see Configuration Files in
this section.
Step 2 Configure basic OSPF functions.
For configuration details, see 5.3 Configuring Basic OSPF Functions.
Step 3 Check the OSPF routes on Device A
[~DeviceA] display ospf routing
Total Nets: 2
Intra Area: 2 Inter Area: 0 ASE: 0 NSSA: 0
The routing table on Device A contains no route in Area 2 because Area 2 is not directly
connected to Area 0.
Step 4 Configure an OSPF virtual link.
# Configure Device A.
[~DeviceA] router id 1.1.1.1
[~DeviceA] ospf 1
[*DeviceA-ospf-1] area 1
[*DeviceA-ospf-1-area-0.0.0.1] vlink-peer 2.2.2.2
[*DeviceA-ospf-1-area-0.0.0.1] quit
[*DeviceA-ospf-1] quit
[*DeviceA] commit
# Configure Device B.
[~DeviceB] router id 2.2.2.2
[~DeviceB] ospf 1
[*DeviceB-ospf-1] area 1
[*DeviceB-ospf-1-area-0.0.0.1] vlink-peer 1.1.1.1
[*DeviceB-ospf-1-area-0.0.0.1] quit
[*DeviceB-ospf-1] quit
[*DeviceB] commit
The preceding command output shows that the OSPF vlink neighbor status is "Full".
# Display the OSPF routes on Device A.
[~DeviceA] display ospf routing
Total Nets: 3
Intra Area: 2 Inter Area: 1 ASE: 0 NSSA: 0
After the virtual link is configured, the routing table on Device A contains routes in Area 2.
----End
Configuration Files
Device A configuration file
#
sysname DeviceA
#
router-id 1.1.1.1
#
interface GigabitEthernet1/0/0
undo shutdown
ip address 192.168.1.1 255.255.255.0
#
interface GigabitEthernet2/0/0
undo shutdown
ip address 10.1.1.1 255.0.0.0
#
ospf 1
area 0.0.0.0
network 10.0.0.0 0.255.255.255
area 0.0.0.1
network 192.168.1.0 0.0.0.255
vlink-peer 2.2.2.2
#
return
undo shutdown
ip address 172.16.1.1 255.255.0.0
#
ospf 1
area 0.0.0.1
network 192.168.1.0
0.0.0.255 vlink-peer
1.1.1.1
area 0.0.0.2
network 172.16.0.0 0.0.255.255
#
return
Device C configuration file
#
sysname DeviceC
#
router-id 3.3.3.3
#
interface
GigabitEthernet2/0/0 undo
shutdown
ip address 10.1.1.2 255.0.0.0
#
ospf 1
area 0.0.0.0
network 10.0.0.0 0.255.255.255
#
return
Device D configuration file
#
sysname DeviceD
#
router-id 4.4.4.4
#
interface
GigabitEthernet2/0/0 undo
shutdown
ip address 172.16.1.2 255.255.0.0
#
ospf 1
area 0.0.0.2
network 172.16.0.0 0.0.255.255
#
Networking Requirements
On the network shown in Figure 5-12, all routers run OSPF, and the entire AS is divided into
three areas. Device A and Device B function as ABRs to advertise inter-area routes; Device D
functions as the ASBR to import external routes (static routes).
Configure Area 1 as a stub area to reduce the LSAs advertised to this area without affecting
route reachability.
Interface 1 and interface 2 in this example are GE 1/0/0 and GE 2/0/0, respectively.
Area0
DeviceA interface1 DeviceB
192.168.0.1/24 interface1
192.168.0.2/24
interface2 interface2
192.168.1.1/24 192.168.2.1/24
interface1 interface1
192.168.1.2/24 192.168.2.2/24
ASBR
DeviceC DeviceD
interface2 interface2
172.16.1.1/24 Stub 172.17.1.1/24
interface2 interface2
172.16.1.2/24 172.17.1.2/24
DeviceE DeviceF
Area1 Area2
Precautions
When configuring an OSPF stub area, note the following rules:
Configuration Roadmap
The configuration roadmap is as follows:
Data Preparation
To complete the configuration, you need the following data:
Procedure
Step 1 Assign an IP address to each interface. For configuration details, see Configuration Files in
this section.
Step 2 Configure basic OSPF functions. For details, see 5.22.1 Example for Configuring Basic
OSPF Functions.
Step 3 Configure Device D to import static routes.
[~DeviceD] ip route-static 10.0.0.0 8 null 0
[*DeviceD] ospf 1
[*DeviceD-ospf-1] import-route static type 1
[*DeviceD-ospf-1] commit
[~DeviceD-ospf-1] quit
NOTE
If the area where Device C resides is a common area, external routes exist in the routing table.
[~DeviceC] display ospf routing
Total Nets: 4
Intra Area: 0 Inter Area: 3 ASE: 1 NSSA: 0
Step 4 Configure Area 1 as a stub area.
# Configure Device A.
[~DeviceA] ospf 1
[*DeviceA-ospf-1] area 1
[*DeviceA-ospf-1-area-0.0.0.1] stub
[*DeviceA-ospf-1-area-0.0.0.1]
commit [~DeviceA-ospf-1-area-
0.0.0.1] quit
# Configure Device C.
[~DeviceC] ospf 1
[*DeviceC-ospf-1] area 1
[*DeviceC-ospf-1-area-0.0.0.1] stub
[*DeviceC-ospf-1-area-0.0.0.1]
commit [~DeviceC-ospf-1-area-
0.0.0.1] quit
# Configure Device E.
[~DeviceE] ospf 1
[*DeviceE-ospf-1] area 1
[*DeviceE-ospf-1-area-0.0.0.1] stub
[*DeviceE-ospf-1-area-0.0.0.1]
commit [~DeviceE-ospf-1-area-
0.0.0.1] quit
# Display the routing table on Device C.
NOTE
After the area where Device C resides is configured as a stub area, a default route rather than AS
external routes is displayed in the routing table.
[~DeviceC] display ospf routing
Total Nets: 1
Intra Area: 0 Inter Area: 1 ASE: 0 NSSA: 0
NOTE
After the advertisement of summary LSAs to the stub area is disabled, the number of routing entries on
the routers in the stub area further decreases, and only the default route to a destination beyond the stub
area is reserved.
----End
Configuration Files
Device A configuration file
#
sysname DeviceA
#
router id 1.1.1.1
#
interface
GigabitEthernet1/0/0 undo
shutdown
ip address 192.168.0.1 255.255.255.0
#
interface
GigabitEthernet2/0/0 undo
shutdown
ip address 192.168.1.1 255.255.255.0
#
ospf 1
area 0.0.0.0
network 192.168.0.0
0.0.0.255 area 0.0.0.1
network 192.168.1.0
0.0.0.255 stub no-summary
#
Device B configuration file
#
sysname DeviceB
#
router id 2.2.2.2
#
interface
GigabitEthernet1/0/0 undo
shutdown
ip address 192.168.0.2 255.255.255.0
#
interface
GigabitEthernet2/0/0 undo
shutdown
ip address 192.168.2.1 255.255.255.0
#
ospf 1
area 0.0.0.0
network 192.168.0.0
0.0.0.255 area 0.0.0.2
network 192.168.2.0 0.0.0.255
#
Device C configuration file
#
sysname DeviceC
#
router id 3.3.3.3
#
interface GigabitEthernet1/0/0
undo shutdown
ip address 192.168.1.2 255.255.255.0
#
interface GigabitEthernet2/0/0
undo shutdown
ip address 172.16.1.1 255.255.255.0
#
ospf 1
area 0.0.0.1
network 192.168.1.0 0.0.0.255
network 172.16.1.0 0.0.0.255
stub
#
return
Device D configuration file
#
sysname DeviceD
#
router id 4.4.4.4
#
interface GigabitEthernet1/0/0
undo shutdown
ip address 192.168.2.2 255.255.255.0
#
interface GigabitEthernet2/0/0
undo shutdown
ip address 172.17.1.1 255.255.255.0
#
ospf 1
import-route static type 1
area 0.0.0.2
network 192.168.2.0 0.0.0.255
network 172.17.1.0 0.0.0.255
#
ip route-static 10.0.0.0 255.0.0.0 NULL0
#
return
Device E configuration file
#
sysname DeviceE
#
router id 5.5.5.5
#
interface GigabitEthernet2/0/0
undo shutdown
ip address 172.16.1.2 255.255.255.0
#
ospf 1
area 0.0.0.1
network 172.16.1.0 0.0.0.255
stub
#
return
Device F configuration file
#
sysname DeviceF
#
router id 6.6.6.6
#
interface GigabitEthernet2/0/0
undo shutdown
ip address 172.17.1.2 255.255.255.0
#
ospf 1
area 0.0.0.2
network 172.17.1.0 0.0.0.255
#
return
Networking Requirements
An excessive number of entries in a routing table wastes network resources and causes high
CPU usage. To solve this problem, a non-backbone area on the border of an AS can be
configured as an NSSA to reduce the amount of routing information to be transmitted. An
NSSA in an AS does not transmit routes learned from other areas in the AS but imports AS
external routes. This reduces bandwidth and storage resource consumption.
On the network shown in Figure 5-13, OSPF runs on all routers and the entire AS is divided
into two areas. Device A and Device B function as Area Border Routers (ABRs) to forward
inter-area routes; Device D functions as an Autonomous System Boundary Router (ASBR)
and imports the external static route 10.0.0.0/8. To import AS-external routes but reduce the
number of Link State Advertisements (LSAs) advertised to area 1 without affecting route
reachability, configure area 1 as an NSSA and configure Device A as an LSA translator in the
NSSA.
Configuration Roadmap
The configuration roadmap is as follows:
1. Enable OSPF on all routers and configure basic OSPF functions to ensure that routers
communicate with each other using OSPF. For details, see 5.3 Configuring Basic OSPF
Functions.
2. Configure area 1 as an NSSA.
3. Configure Device D to import the static route 10.0.0.0/8.
4. Configure Device A in the NSSA as an LSA translator.
Data Preparation
To complete the configuration, you need the following data:
Router ID 1.1.1.1 of Device A; OSPF process ID 1; network segment 192.168.0.0/24 of
area 0; network segments 192.168.1.0/24 and 192.168.3.0/24 of area 1
Router ID 2.2.2.2 of Device B; OSPF process ID 1; network segment 192.168.2.0/24 of
area 0; network segments 192.168.1.0/24 and 192.168.4.0/24 of area 1
Router ID 3.3.3.3 of Device C; OSPF process ID 1; network segments 192.168.0.0/24
and 192.168.2.0/24 of area 0
Router ID 4.4.4.4 of Device D; OSPF process ID 1; network segments 192.168.3.0/24
and 192.168.4.0/24 of area 1
Procedure
Step 1 Configure an IP address for each interface.
Configure an IP address for each interface as shown in Figure 5-13. For configuration details,
see Configuration Files in this section.
Step 2 Configure basic OSPF functions.
5.3 Configuring Basic OSPF Functions shows how to configure basic OSPF functions. For
details about the configuration, see Configuration Files in this section.
Step 3 Configure area 1 as an NSSA.
# Configure Device A.
[~DeviceA] ospf
[*DeviceA-ospf-1] area 1
[*DeviceA-ospf-1-area-0.0.0.1] nssa [*DeviceA-ospf-1-
area-0.0.0.1] commit [~DeviceA-ospf-1-area-0.0.0.1] quit
# Configure Device B.
[~DeviceB] ospf
[*DeviceB-ospf-1] area 1
[*DeviceB-ospf-1-area-0.0.0.1] nssa [*DeviceB-ospf-1-
area-0.0.0.1] commit [~DeviceB-ospf-1-area-0.0.0.1] quit
# Configure Device D.
[~DeviceD] ospf
[*DeviceD-ospf-1] area 1
[*DeviceD-ospf-1-area-0.0.0.1] nssa [*DeviceD-ospf-1-
area-0.0.0.1] commit [~DeviceD-ospf-1-area-0.0.0.1] quit
NOTE
NSSA attributes must be configured on all routers in the NSSA using the nssa command.
Total Nets: 7
Intra Area: 2 Inter Area: 4 ASE: 1 NSSA: 0
The command output shows that Device B has imported an AS external route and that the
router ID of the router that advertises the imported AS external route is 2.2.2.2. Device B
functions as the type-5 LSA translator because OSPF selects the ABR with a larger router
ID as an LSA translator.
Step 5 # Configure Device A as an LSA translator.
[~DeviceA] ospf
[*DeviceA-ospf-1] area 1
[*DeviceA-ospf-1-area-0.0.0.1] nssa default-route-advertise no-summary
translator- always
[*DeviceA-ospf-1-area-0.0.0.1] commit
[~DeviceA-ospf-1-area-0.0.0.1] quit
Step 6
Verify the configuration.
Total Nets: 7
Intra Area: 2 Inter Area: 4 ASE: 1 NSSA: 0
The command output shows that Device C has imported an AS external route and that the
router ID of the router that advertises the imported AS external route is 1.1.1.1. Device A
functions as the type-5 LSA translator.
----End
Configuration Files
Device A configuration file
#
sysname DeviceA
#
router id 1.1.1.1
#
interface GigabitEthernet1/0/0
undo shutdown
ip address 192.168.0.1 255.255.255.0
#
interface GigabitEthernet2/0/0
undo shutdown
ip address 192.168.3.1 255.255.255.0
#
interface GigabitEthernet3/0/0
undo shutdown
ip address 192.168.1.1 255.255.255.0
#
ospf 1
area 0.0.0.0
network 192.168.0.0 0.0.0.255
area 0.0.0.1
network 192.168.1.0 0.0.0.255
network 192.168.3.0 0.0.0.255
nssa default-route-advertise no-summary translator-always
#
return
#
router id 3.3.3.3
#
interface GigabitEthernet1/0/0
undo shutdown
ip address 192.168.0.2 255.255.255.0
#
interface GigabitEthernet2/0/0
undo shutdown
ip address 192.168.2.2 255.255.255.0
#
ospf 1
area 0.0.0.0
network 192.168.0.0 0.0.0.255
network 192.168.2.0 0.0.0.255
#
return
Networking Requirements
On the network shown in Figure 5-14, the interface of Device A has the highest priority of
100 on the network and is elected as the DR; Device C has the second highest priority and is
elected as the BDR. Device B has the priority of 0 and cannot be elected as a DR or a BDR;
no priority is configured for Device D and therefore, Device D uses the default value (1).
interface1 interface1
192.168.1.1/24 192.168.1.2/24
interface1
interface1
192.168.1.3/24
DeviceC DeviceD
Precautions
Reconfiguring the DR priority for a router does not change the DR or BDR on a network. You
can use either of the following methods to re-elect a DR or BDR. However, the following
methods will disconnect OSPF neighbors. Therefore, use the following methods only when
necessary.
Restart the OSPF processes on all routers.
Configure the shutdown and undo shutdown commands on the interfaces where the
OSPF neighboring relationships are established.
Configuration Roadmap
The configuration roadmap is as follows:
1. Configure basic OSPF functions on each router for interconnection.
2. Configure the Router ID for each router.
3. Use the default DR priorities and check whether the router is the DR or BDR.
4. Configure the DR priority on an interface and check whether the router is the DR or
BDR.
Data Preparation
To complete the configuration, you need the following data:
Router ID (1.1.1.1) and priority (100) of Device A
Router ID (2.2.2.2) and priority (0) of Device B
Router ID (3.3.3.3) and priority (2) of Device C
Router ID (4.4.4.4) and priority (1) of Device D
Procedure
Step 1 Assign an IP address to each interface. For configuration details, see Configuration Files in
this section.
Step 2 Configure basic OSPF functions.
# Configure Device A.
# Configure Device B.
[~DeviceB] router id 2.2.2.2
[*DeviceB] ospf 1
[*DeviceB-ospf-1] area 0
[*DeviceB-ospf-1-area-0.0.0.0] network 192.168.1.0 0.0.0.255
[*DeviceB-ospf-1-area-0.0.0.0] commit
[~DeviceB-ospf-1-area-0.0.0.0] quit
# Configure Device C.
[~DeviceC] router id 3.3.3.3
[*DeviceC] ospf 1
[*DeviceC-ospf-1] area 0
[*DeviceC-ospf-1-area-0.0.0.0] network 192.168.1.0 0.0.0.255
[*DeviceC-ospf-1-area-0.0.0.0] commit
[~DeviceC-ospf-1-area-0.0.0.0] quit
# Configure Device D.
[~DeviceD] router id 4.4.4.4
[*DeviceD] ospf 1
[*DeviceD-ospf-1] area 0
[*DeviceD-ospf-1-area-0.0.0.0] network 192.168.1.0 0.0.0.255
[*DeviceD-ospf-1-area-0.0.0.0] commit
[~DeviceD-ospf-1-area-0.0.0.0] quit
When checking the neighbors of Device A, you can view the DR priority and the neighbor
status. By default, the DR priority is 1. Now Device D functions as the DR and Device C
functions as the BDR.
Step 3 Set the DR priority on each interface.
# Configure Device A.
[~DeviceA] interface gigabitethernet 1/0/0
[~DeviceA-GigabitEthernet1/0/0] ospf dr-priority 100
[*DeviceA-GigabitEthernet1/0/0] commit
[~DeviceA-GigabitEthernet1/0/0] quit
# Configure Device B.
[~DeviceB] interface gigabitethernet 1/0/0
[~DeviceB-GigabitEthernet1/0/0] ospf dr-priority 0
[*DeviceB-GigabitEthernet1/0/0] commit
[~DeviceB-GigabitEthernet1/0/0] quit
# Configure Device C.
[~DeviceC] interface gigabitethernet 1/0/0
[~DeviceC-GigabitEthernet1/0/0] ospf dr-priority 2
[*DeviceC-GigabitEthernet1/0/0] commit
[~DeviceC-GigabitEthernet1/0/0] quit
If the neighbor is in the Full state, the device has established a neighbor relationship with its
neighbor. If the neighbor remains in the 2-Way state, neither of them is the DR or BDR. In
this case, they do not need to exchange LSAs.
If the status of the OSPF interface is DROther, the interface is neither DR nor BDR.
----End
Configuration Files
Device A configuration file
#
sysname DeviceA
#
router id 1.1.1.1
#
interface GigabitEthernet1/0/0
undo shutdown
ip address 192.168.1.1 255.255.255.0
Networking Requirements
On the network shown in Figure 5-15, the requirements are as follows:
Device A, Device B, Device C, Device D, and Device E are connected to each other
through OSPF.
Device A, Device B, Device C, Device D, and Device E belong to Area 0.
Load balancing is configured so that the traffic from Device A to Device E is load-
balanced by Device C and Device D.
Interface 1 to 4 in this example are GE 1/0/0, GE 2/0/0, GE 3/0/0 and GE 4/0/0, respectively.
Area0
DeviceB
interface1 interface2
10.1.1.2/24 192.168.0.1/24
10.1.1.1/24 192.168.0.2/24
DeviceC
interface1 10.1.2.1/24 192.168.1.2/24 interface1172.
DeviceA interface2 interface2 interfac
interface1 interface2 Device
Interface3 10.1.2.2/24 Interface3
192.168.1.1/24
10.1.3.1/24 192.168.2.2/24
DeviceD
10.1.3.2/24
192.168.2.1/24 interface1
interface2
Configuration Roadmap
The configuration roadmap is as follows:
Data Preparation
To complete the configuration, you need the following data.
Data of Device A, including router ID (1.1.1.1), OSPF process ID (1), and network
segment addresses of Area 0 (10.1.1.0/24, 10.1.2.0/24 and 10.1.3.0/24)
Data of Device B, including router ID (2.2.2.2), OSPF process ID (1), and network
segment addresses of Area 0 (10.1.1.0/8 and 192.168.0.0/8)
Issue 01 (2018-12- Copyright © Huawei Technologies Co., 3
HUAWEI NetEngine40E Universal Service
Router 5 OSPF
Data of Device C, including router ID (3.3.3.3), OSPF process ID (1), and network
segment addresses of Area 0 (10.1.2.0/8 and 192.168.1.0/8)
Data of Device D, including router ID (4.4.4.4), OSPF process ID (1), and network
segment addresses of Area 0 (10.1.3.0/8 and 192.168.2.0/8)
Data of Device E, including router ID (5.5.5.5), OSPF process ID (1), and network
segment addresses of Area 0 (192.168.0.0/24, 192.168.1.0/24, 192.168.2.0/24, and
172.17.1.0/24)
Number of equal-cost routes for load balancing on Device A (2)
Next hop weights of the routes from Device A to Device B, Device C, and Device D (2,
1, and 1, respectively)
Procedure
Step 1 Assign an IP address to each interface. For configuration details, see Configuration Files in
this section.
Step 2 Configure basic OSPF functions. For details, see 5.22.1 Example for Configuring Basic
OSPF Functions.
Step 3 Display the routing table of Device A.
As shown in the routing table, Device A has three valid next hops: Device B (10.1.1.2),
Device C (10.1.2.2), and Device D (10.1.3.2) because the default maximum number of equal-
cost routes is 6.
<DeviceA> display ip routing-table
Route Flags: R - relay, D - download
to fib, T - to vpn-instance, B - black hole route
----------------------------------------------------------------------------
Routing Tables : _public_
Destinations : 15 Routes : 15
Step 4 Set the maximum number of routes for load balancing to 2 on Device A.
[~DeviceA] ospf 1
[*DeviceA-ospf-1] maximum load-balancing 2
[*DeviceA-ospf-1] commit
[~DeviceA-ospf-1] quit
# Display the routing table of Device A. You can view two routes for load balancing on
Device A, with Device B (10.1.1.2) and Device C (10.1.2.2) as the next hops.
[~DeviceA] display ip routing-table
Route Flags: R - relay, D - download
to fib, T - to vpn-instance, B - black hole route
----------------------------------------------------------------------------
Routing Tables : _public_
Destinations : 15 Routes : 15
----------------------------------------------------------------------------
Routing Tables : _public_
Destinations : 15 Routes : 15
As shown in the routing table, the priority of the route with 10.1.2.2 and 10.1.3.2 as the next
hop addresses is higher than that of the route with 10.1.1.2 as the next hop address. Therefore,
Device A has only two valid next hops, Device C (10.1.2.2) and Device D (10.1.3.2).
----End
Configuration Files
Device A configuration file
#
sysname DeviceA
#
interface GigabitEthernet1/0/0
undo shutdown
ip address 10.1.1.1 255.255.255.0
#
interface GigabitEthernet2/0/0
undo shutdown
ip address 10.1.2.1 255.255.255.0
#
interface GigabitEthernet3/0/0
undo shutdown
ip address 10.1.3.1 255.255.255.0
#
ospf 1 router-id 1.1.1.1
maximum load-balancing 2
nexthop 10.1.1.2 weight 2
nexthop 10.1.2.2 weight 1
nexthop 10.1.3.2 weight 1
area 0.0.0.0
network 10.1.1.0 0.0.0.255
interface GigabitEthernet2/0/0
undo shutdown
ip address 192.168.1.2 255.255.255.0
#
interface GigabitEthernet3/0/0
undo shutdown
ip address 192.168.2.2 255.255.255.0
#
interface GigabitEthernet4/0/0
undo shutdown
ip address 172.17.1.1 255.255.255.0
#
ospf 1 router-id 4.4.4.4
area 0.0.0.0
network 192.168.0.0 0.0.255.255
network 192.168.1.0 0.0.0.255
network 192.168.2.0 0.0.0.255
network 172.17.1.0 0.0.0.255
#
return
Networking Requirements
On the network shown in Figure 5-16, on the broadcast network, OSPF runs on the four
devices, which belong to the same OSPF area.
interface1 interface1
192.168.1.1/24 192.168.1.2/24
interface1
interface1
192.168.1.3/24
DeviceC DeviceD
Precautions
When configuring OSPF fast convergence, note the following rules:
You can decrease the interval at which Hello packets are sent and values of the Dead,
Poll, and Wait timers for fast OSPF network convergence. Frequent packet transmission,
however, may overload the device. In addition, the OSPF network convergence slows
down if the values of these timers are too large. Therefore, set values based on the
network stability.
The intervals at which Hello packets are sent and values of the Dead, Poll, and Wait
timers at both ends must be the same. Otherwise, the OSPF neighbor relationship cannot
be established.
Configuration Roadmap
The configuration roadmap is as follows:
1. Configure basic OSPF functions on each router for interconnection.
2. Configure the BFD function on each router.
3. Adjust the holddown time of the OSPF neighbors on each router.
4. Configure the Smart-discover function on each router.
5. Adjust the intervals for configuration update, LSA reception, and SPF calculation
through an intelligent timer on each router.
Data Preparation
To complete the configuration, you need the following data.
Holddown time of the OSPF neighbors
Intervals for LSA update, LSA reception, and SPF calculation
Procedure
Step 1 Assign an IP address to each interface. For configuration details, see Configuration Files in
this section.
Step 2 Configure basic OSPF functions. For details, see 5.22.1 Example for Configuring Basic
OSPF Functions.
Step 3 Adjust the holddown time of the OSPF neighbors on each router.
# Configure Device A.
[~DeviceA] interface gigabitethernet 1/0/0
[*DeviceA-GigabitEthernet1/0/0] ospf timer dead 30
[*DeviceA-GigabitEthernet1/0/0] commit
NOTE
The holddown time of neighbors of the OSPF-capable interfaces must be longer than the interval at
which Hello packets are sent, and the values of dead interval on the routers in the same network
segment must be the same.
In this configuration example, the following configurations on each router are the same as that on
Device A. For configuration details, see "Configuration Files" in this section.
– Adjust the holddown time of the OSPF neighbors on each router.
– Configure the Smart-discover function on each router.
– Adjust the intervals for configuration update, LSA reception, and SPF calculation through an
intelligent timer on the router.
[*DeviceA-GigabitEthernet1/0/0] commit
[~DeviceA-GigabitEthernet1/0/0] quit
# Configure Device A.
[*DeviceA] bfd
[*DeviceA-bfd] quit
[*DeviceA] ospf
[*DeviceA-ospf-1] bfd all-interfaces enable
[*DeviceA-ospf-1] commit
[~DeviceA-ospf-1] quit
Step 6 Adjust the intervals for configuration update, LSA reception, and SPF calculation through an
intelligent timer on each router.
# Configure Device A.
[~DeviceA] ospf 1
[*DeviceA-ospf-1] lsa-originate-interval intelligent-timer 3000 200 500
[*DeviceA-ospf-1] lsa-arrival-interval intelligent-timer 3000 200 500
[*DeviceA-ospf-1] spf-schedule-interval intelligent-timer 3000 200 500
[*DeviceA-ospf-1] commit
# Run the display ospf brief command on each router to view the brief information about
OSPF. Use Router A as an example. You can view the value of timers.
[~DeviceA] display ospf brief
OSPF Process 1 with Router ID 9.9.9.9
OSPF Protocol Information
RouterID: 9.9.9.9 Border Router: AREA
Multi-VPN-Instance is not enabled
Global DS-TE Mode: Non-Standard IETF Mode
Graceful-restart capability: disabled
Helper support capability : not configured
OSPF Stub Router State Reason: Startup Synchronize
Router LSA stub links with cost 65535
Summary LSA with cost 16777214
External LSA with cost 16777214
Applications Supported: MPLS Traffic-Engineering
Spf-schedule-interval: max 10000ms, start 500ms, hold 1000ms
Default ASE parameters: Metric: 1 Tag: 1 Type: 2
Route Preference: 10
ASE Route Preference: 150
Intra Route Preference: 50
Inter Route Preference: 50
SPF Computation Count: 56
RFC 1583 Compatible
Retransmission limitation is disabled
bfd enabled
BFD Timers: Tx-Interval 10 , Rx-Interval 10 , Multiplier 3
Area Count: 2 Nssa Area Count: 0
ExChange/Loading Neighbors: 0
----End
Configuration Files
Device A configuration file
#
sysname DeviceA
#
router id 1.1.1.1
#
bfd
#
interface GigabitEthernet1/0/0
undo shutdown
ip address 192.168.1.1 255.255.255.0
ospf timer dead 30
ospf smart-discover
#
ospf 1
bfd all-interfaces enable
spf-schedule-interval intelligent-timer 3000 200 500
lsa-arrival-interval intelligent-timer 3000 200 500
lsa-originate-interval intelligent-timer 3000 200 500
area 0.0.0.0
network 192.168.1.0 0.0.0.255
#
return
#
ospf 1
bfd all-interfaces enable
spf-schedule-interval intelligent-timer 3000 200 500
lsa-arrival-interval intelligent-timer 3000 200 500
lsa-originate-interval intelligent-timer 3000 200 500
area 0.0.0.0
network 192.168.1.0 0.0.0.255
#
return
Device D configuration file
#
sysname DeviceD
#
router id 4.4.4.4
#
bfd
#
interface GigabitEthernet1/0/0
undo shutdown
ip address 192.168.1.4 255.255.255.0
ospf timer dead 30
ospf smart-discover
#
ospf 1
bfd all-interfaces enable
spf-schedule-interval intelligent-timer 3000 200 500
lsa-arrival-interval intelligent-timer 3000 200 500
lsa-originate-interval intelligent-timer 3000 200 500
area 0.0.0.0
network 192.168.1.0 0.0.0.255
#
return
Networking Requirements
When multicast and an Interior Gateway Protocol (IGP) Shortcut-enabled Multiprotocol
Label Switching (MPLS) traffic engineering (TE) tunnel are configured on a network, the
outbound interface of the route calculated by an IGP may not be a physical interface but a TE
tunnel interface. The TE tunnel interface on the Device sends multicast Join packets over a
unicast route to the multicast source address. The multicast Join packets are transparent to the
Device through which the TE tunnel passes. As a result, the Device through which the TE
tunnel passes cannot generate multicast forwarding entries.
On the network shown in Figure 5-17, Device A, Device B, Device C, Device D, and Device
E are running OSPF. Device B and Device D set up an MPLS TE tunnel with the tunnel
interface Tunnel 10, and IGP Shortcut is enabled on Tunnel 10 of Device B. The outbound
interface calculated by Device B may be the TE tunnel interface, not the physical interface
GE 2/0/0. Tunnel 10 on Device B sends multicast Join packets over a unicast route to the
multicast source address. The multicast Join packets are transparent to Device C through
which the TE tunnel passes. As a result, Device C cannot generate multicast forwarding
entries.
To resolve the problem, enable OSPF local MT on Device B. After local MT is enabled, if the
outbound interface of a calculated route is an IGP Shortcut-enabled TE tunnel interface, the
route management (RM) module creates an independent Multicast IGP (MIGP) routing table
for the multicast protocol, calculates a physical outbound interface for the route, and adds the
route to the MIGP routing table. Multicast packets are then forwarded along this route.
Interface 1 and interface 2 in this example are GE 1/0/0, and GE 2/0/0, respectively.
Client Server
172.16.1.2/24 192.168.3.2/24
interface1 interface2
172.16.1.1/24 192.168.3.1/24
DeviceA DeviceE
interface2 interface1
10.0.0.1/24 10.0.3.2/24
interface1 interface1
10.0.0.2/24 interface1 interface2 10.0.3.1/24
10.0.1.1/24 10.0.2.2/24
DeviceB DeviceD
interface2 interface2
10.0.1.2/24 DeviceC 10.0.2.1/24
Tunnel10
Configuration Roadmap
The configuration roadmap is as follows:
Data Preparation
To complete the configuration, you need the IP address of each interface on each Router, as
shown in Table 5-5.
Device A 1.1.1.1/32
Device B 2.2.2.2/32
Device C 3.3.3.3/32
Device D 4.4.4.4/32
Device E 5.5.5.5/32
The TE tunnel interface Tunnel 10 uses the IP address of Loopback 0 and runs the MPLS
TE protocol. The destination address of the TE tunnel is 4.4.4.4, and the tunnel ID is
100. The TE tunnel uses RSVP-TE as a signaling protocol.
Procedure
Step 1 Assign an IP address to each interface.
Figure 5-17 shows how to assign an IP address to each interface. For configuration details,
see Configuration Files in this section.
Step 2 Configure basic OSPF functions.
Configuring Basic OSPF Functions shows how to configure basic OSPF functions. For
configuration details, see Configuration Files in this section.
Step 3 Configure Protocol Independent Multicast-Sparse Mode (PIM-SM).
# Enable PIM-SM on Device A.
[*DeviceA] multicast routing-enable
[~DeviceA] interface Gigabitethernet 2/0/0 [~DeviceA-
GigabitEthernet2/0/0] pim sm [*DeviceA-GigabitEthernet2/0/0]
quit [*DeviceA] interface Gigabitethernet 1/0/0 [*DeviceA-
GigabitEthernet1/0/0] pim sm [*DeviceA-GigabitEthernet1/0/0]
commit [~DeviceA-GigabitEthernet1/0/0] quit
NOTE
Enable PIM-SM on each Device. The configurations for Device B, Device C, Device D, and Device E are similar to those on D
A. For configuration details, see Configuration Files in this section.
The preceding command output shows information about the multicast routing table on
Device C.
Step 4 Configure an MPLS RSVP-TE tunnel.
# Configure Device B.
[*DeviceB] mpls lsr-id 2.2.2.2
[*DeviceB] mpls [*DeviceB-
mpls] mpls te [*DeviceB-
mpls] mpls rsvp-te
[*DeviceB-mpls] mpls te cspf
[*DeviceB-mpls] commit
[*DeviceB-mpls] quit
[*DeviceB] interface Gigabitethernet 2/0/0
[*DeviceB-GigabitEthernet2/0/0] mpls
[*DeviceB-GigabitEthernet2/0/0] mpls te
[*DeviceB-GigabitEthernet2/0/0] mpls rsvp-te
[*DeviceB-GigabitEthernet2/0/0] commit
[*DeviceB-GigabitEthernet2/0/0] quit
[*DeviceB] ospf 1
[*DeviceB-ospf-1] enable traffic-adjustment
[*DeviceB-ospf-1] opaque-capability enable
[*DeviceB-ospf-1] area 0.0.0.0
[*DeviceB-ospf-1-area-0.0.0.0] mpls-te enable
[*DeviceB-ospf-1-area-0.0.0.0] commit
[*DeviceB-ospf-1-area-0.0.0.0] quit
# Configure Device C.
[*DeviceC] mpls lsr-id 3.3.3.3
[*DeviceC] mpls [*DeviceC-
mpls] mpls te [*DeviceC-
mpls] mpls rsvp-te
[*DeviceC-mpls] commit
[*DeviceC-mpls] quit
[*DeviceC] interface Gigabitethernet 1/0/0
[*DeviceC-GigabitEthernet1/0/0] mpls
[*DeviceC-GigabitEthernet1/0/0] mpls te
[*DeviceC-GigabitEthernet1/0/0] mpls rsvp-te
[*DeviceC-GigabitEthernet1/0/0] commit
[*DeviceC-GigabitEthernet1/0/0] quit
[*DeviceC] interface Gigabitethernet 2/0/0
[*DeviceC-GigabitEthernet2/0/0] mpls
[*DeviceC-GigabitEthernet2/0/0] mpls te
[*DeviceC-GigabitEthernet2/0/0] mpls rsvp-te
[*DeviceC-GigabitEthernet2/0/0] commit
[*DeviceC-GigabitEthernet2/0/0] quit
[*DeviceC] ospf 1
[*DeviceC-ospf-1] opaque-capability enable
[*DeviceC-ospf-1] area 0.0.0.0
[*DeviceC-ospf-1-area-0.0.0.0] mpls-te enable
[*DeviceC-ospf-1-area-0.0.0.0] commit
[*DeviceC-ospf-1-area-0.0.0.0] quit
# Configure Device D.
# Check the OSPF routing table on Device B. Information shows that an MPLS TE tunnel has
been set up.
[*DeviceB] display ip routing-table
Route Flags: R - relay, D - download
to fib, T - to vpn-instance, B - black hole route
----------------------------------------------------------------------------
Routing Tables : _public_
Destinations : 14 Routes : 14
No multicast routing entry is displayed in the multicast routing table on Device C, indicating
that Device C has discarded multicast packets.
Step 6 Enable OSPF local MT.
# Enable OSPF local MT on Device B.
[*DeviceB] ospf
[*DeviceB-ospf-1] local-mt enable
[*DeviceB-ospf-1] commit
[*DeviceB-ospf-1] quit
The preceding command output shows information about the multicast routing table on
Device C.
----End
Configuration Files
Device A configuration file
#
sysname DeviceA
#
router id 1.1.1.1
#
multicast routing-enable
#
interface GigabitEthernet2/0/0
undo shutdown
ip address 10.0.0.1 255.255.255.0
pim sm
igmp version 3
#
interface GigabitEthernet1/0/0
undo shutdown
ip address 172.16.1.1 255.255.255.0
pim sm
igmp enable
#
interface LoopBack0
ip address 1.1.1.1 255.255.255.255
#
ospf 1
area 0.0.0.0
network 172.16.1.0 0.0.0.255
network 10.0.0.0 0.0.0.255
#
return
Device B configuration file
#
sysname DeviceB
#
router id 2.2.2.2
#
multicast routing-enable
#
mpls lsr-id 2.2.2.2
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
ospf 1
opaque-capability enable
enable traffic-adjustment
local-mt enable
area 0.0.0.0
network 10.0.0.0 0.0.0.255
network 10.0.1.0 0.0.0.255
network 2.2.2.2 0.0.0.0
mpls-te enable
#
interface GigabitEthernet1/0/0
undo shutdown
ip address 10.0.0.2 255.255.255.0
pim sm
#
interface GigabitEthernet2/0/0
undo shutdown
ip address 10.0.1.2 255.255.255.0
pim sm
mpls
mpls te
mpls rsvp-te
#
interface LoopBack0
ip address 2.2.2.2 255.255.255.255
pim sm
#
interface Tunnel10
ip address unnumbered interface LoopBack0
tunnel-protocol mpls te
destination 4.4.4.4
mpls te tunnel-id 100
mpls te igp shortcut ospf
mpls te igp metric relative -10
#
pim
C-BSR LoopBack0
C-RP LoopBack0
#
return
Device C configuration file
#
sysname DeviceC
#
multicast routing-enable
#
mpls lsr-id 3.3.3.3
mpls
mpls te
mpls rsvp-te
#
ospf 1
opaque-capability enable
area 0.0.0.0
network 10.0.1.0 0.0.0.255
network 10.0.2.0 0.0.0.255
network 3.3.3.3 0.0.0.0
mpls-te enable
#
interface GigabitEthernet1/0/0
undo shutdown
ip address 10.0.1.1 255.255.255.0
pim sm
mpls
mpls te
mpls rsvp-te
#
interface GigabitEthernet2/0/0
undo shutdown
ip address 10.0.2.2 255.255.255.0
pim sm
mpls
mpls te
mpls rsvp-te
#
interface LoopBack0
undo shutdown
ip address 3.3.3.3 255.255.255.255
#
return
Device D configuration file
#
sysname DeviceD
#
router id 4.4.4.4
#
multicast routing-enable
#
mpls lsr-id 4.4.4.4
mpls
mpls te
mpls rsvp-te
#
interface GigabitEthernet1/0/0
undo shutdown
ip address 10.0.3.1 255.255.255.0
pim sm
#
interface GigabitEthernet2/0/0
undo shutdown
ip address 10.0.2.1 255.255.255.0
pim sm
mpls
mpls te
mpls rsvp-te
#
interface LoopBack0
ip address 4.4.4.4 255.255.255.255
pim sm
#
ospf 1
opaque-capability enable
area 0.0.0.0
network 10.0.2.0 0.0.0.255
network 10.0.3.0 0.0.0.255
network 4.4.4.4 0.0.0.0
mpls-te enable
#
pim
C-BSR GigabitEthernet1/0/0
C-RP GigabitEthernet1/0/0
#
return
Networking Requirements
When a fault occurs on the primary link T, traffic is switched to a backup link. In such a
scenario, two problems arise:
It takes hundreds of milliseconds for the traffic to be switched to a backup link. During
this period, services are interrupted.
Traffic may be switched to the link that passes through Device A. Device A is an ASBR
and is not expected to function as a backup device.
If 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 prevent the link which passes through Device A from functioning as
the backup link.
On the network shown in Figure 5-18:
All routers run OSPF.
The link cost meets the OSPF IP FRR traffic protection inequality.
If the primary link T fails, Device S immediately switches traffic to the backup link
which passes through Device N.
Based on the network planning, the link which passes through Device A does not
function as an FRR backup link.
Interface 1, interface 2, interface 3, interface 4 in this example are GE 1/0/0, GE 2/0/0, GE 3/0/0, GE
1/0/1, respectively.
IS-IS
Network
OSPF Network
Area0
interface1 interface2
DeviceA
ASBR interface1 DeviceD
interface1
LinkT cost=5
interface2 interface2
interface3 cost = 15 interface3 interface4
DeviceS DeviceE OSPF Network
Area1
interface1 GE2/0/0
DeviceN
Precautions
When configuring OSPF IP FRR, note the following points:
Before configuring OSPF IP FRR, block FRR on certain interfaces to prevent the links
connected to these interfaces from functioning as backup links. 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 so that link faults can be rapidly detected.
Configuration Roadmap
The configuration roadmap is as follows:
1. Configure basic OSPF functions on each router.
2. Configure BFD for OSPF on all the devices in Area 0.
3. Set the costs of links to ensure that link T is selected to transmit traffic.
4. Block FRR on a specified interface of Device S.
5. Enable OSPF IP FRR on Device S to protect the traffic forwarded by Device S.
Data Preparation
To complete the configuration, you need the following data.
GE 2/0/0 10.1.2.1/24
GE 3/0/0 10.1.3.1/24
GE 2/0/0 10.2.1.2/24
GE 2/0/0 10.2.3.2/24
GE 2/0/0 10.1.2.2/24
GE 3/0/0 10.2.3.1/24
GE 1/0/1 172.17.1.1/24
Procedure
Step 1 Assign an IP address to each interface. For configuration details, see Configuration Files in
this section.
Step 2 Configure basic OSPF functions. For details, see Example for Configuring Basic OSPF
Functions.
Step 3 Configure BFD for OSPF on all the devices in Area 0. For details, see Example for
Configuring BFD for OSPF.
Step 4 Set the costs of links to ensure that link T is selected to transmit traffic.
# Configure Device S.
[~DeviceS] interface gigabitethernet1/0/0
[~DeviceS-GigabitEthernet1/0/0] ospf cost 10
[*DeviceS-GigabitEthernet1/0/0] quit
[~DeviceS] interface gigabitethernet2/0/0
[~DeviceS-GigabitEthernet2/0/0] ospf cost 15
[*DeviceS-GigabitEthernet2/0/0] quit
[~DeviceS] interface gigabitethernet3/0/0
[~DeviceS-GigabitEthernet3/0/0] ospf cost 10
[*DeviceS-GigabitEthernet3/0/0] quit
[*DeviceS] commit
# Configure Device A.
[~DeviceA] interface gigabitethernet2/0/0
[~DeviceA-GigabitEthernet2/0/0] ospf cost 15
[*DeviceA-GigabitEthernet2/0/0] quit
[*DeviceA] commit
# Configure Device N.
----End
Configuration Files
Device S configuration file
#
sysname DeviceS
#
bfd
#
interface GigabitEthernet1/0/0
ip address 10.1.1.1 255.255.255.0
ospf cost 5
#
interface GigabitEthernet2/0/0
ip address 10.1.2.1 255.255.255.0
ospf cost 15
#
interface GigabitEthernet3/0/0
ip address 10.1.3.1 255.255.255.0
ospf frr block
ospf cost 10
#
interface LoopBack0
ip address 1.1.1.1 255.255.255.255
#
ospf 1 router-id 1.1.1.1
bfd
#
interface GigabitEthernet1/0/0
ip address 10.2.1.1 255.255.255.0
#
interface GigabitEthernet2/0/0
ip address 10.1.2.2 255.255.255.0
#
interface GigabitEthernet3/0/0
ip address 10.2.3.1 255.255.255.0
#
interface GigabitEthernet1/0/1
ip address 172.17.1.1 255.255.255.0
ospf cost 5
#
interface LoopBack0
ip address 4.4.4.4 255.255.255.255
#
ospf 1 router-id 4.4.4.4
bfd all-interfaces enable
bfd all-interfaces frr-binding
area 0.0.0.1
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
network 172.17.1.0 0.0.0.255
#
return
Networking Requirements
OSPF enables the router to periodically send Hello packets to a neighboring router for fault
detection. Detecting a fault takes more than 1s. With the development of technologies, voice,
video, and other VOD services are widely used. These services are quite sensitive to packet
loss and delays. When traffic is transmitted at gigabit rates, long-time fault detection will
cause packet loss. This cannot meet high reliability requirements of the carrier-class network.
BFD for OSPF is used to resolve the problem. After BFD for OSPF is configured, the link
status can be rapidly detected and fault detection can be completed in milliseconds. This
speeds up OSPF convergence when the link status changes.
For example, as shown in Figure 5-19, the primary link Device A -> Device B and the
secondary link Device A -> Device C -> Device B are deployed on the network. Traffic is
transmitted on the primary link normally. When the primary link becomes faulty, the Device
is expected to rapidly detect the fault and switch traffic to the secondary link.
You can configure BFD for OSPF to detect the OSPF neighbor relationship between Device A
and Device B. When the link between Device A and Device B fails, BFD can rapidly detect
the failure and report it to OSPF. Traffic is then switched to the secondary link.
Interface 1, interface 2, interface 3 in this example are GE 1/0/0, GE 2/0/0, and GE 3/0/0, respectively.
interface1 interface2
1.1.1.2/24 2.2.2.1/24
DeviceC Area0
Precautions
None
Configuration Roadmap
The configuration roadmap is as follows:
1. Configure basic OSPF functions on each router for interconnection.
2. Enable global BFD.
3. Enable OSPF BFD on Device A and Device B.
Data Preparation
To complete the configuration, you need the following data:
Data of Device A, including the router ID (1.1.1.1), OSPF process number (1), and
network segment addresses of Area 0 (3.3.3.0/24 and 1.1.1.0/24)
Data of Device B, including the router ID (2.2.2.2), OSPF process number (1), and
network segment addresses of Area 0 (3.3.3.0/24, 2.2.2.0/24, and 172.16.1.0/24)
Data of Device C, including the router ID (3.3.3.3), OSPF process number (1), and
network segment addresses of Area 0 (1.1.1.0/24 and 2.2.2.0/24)
Minimum interval at which BFD packets are received and sent and local detection
multiplier on Device A and Device B
Procedure
Step 1 Assign an IP address to each interface. For configuration details, see Configuration Files in
this section.
Step 2 Configure basic OSPF functions.
# Configure Device A.
[~DeviceA] router id 1.1.1.1
[*DeviceA] ospf 1
[*DeviceA-ospf-1] area 0
# Configure Device B.
[~DeviceB] router id 2.2.2.2
[*DeviceB] ospf 1
[*DeviceB-ospf-1] area 0
[*DeviceB-ospf-1-area-0.0.0.0] network 2.2.2.0 0.0.0.255
[*DeviceB-ospf-1-area-0.0.0.0] network 3.3.3.0 0.0.0.255
[*DeviceB-ospf-1-area-0.0.0.0] network 172.16.1.0 0.0.0.255
[*DeviceB-ospf-1-area-0.0.0.0] commit
[~DeviceB-ospf-1-area-0.0.0.0] quit
# Configure Device C.
[~DeviceC] router id 3.3.3.3
[*DeviceC] ospf 1
[*DeviceC-ospf-1] area 0
[*DeviceC-ospf-1-area-0.0.0.0] network 1.1.1.0 0.0.0.255
[*DeviceC-ospf-1-area-0.0.0.0] network 2.2.2.0 0.0.0.255
[*DeviceC-ospf-1-area-0.0.0.0] commit
[~DeviceC-ospf-1-area-0.0.0.0] quit
# After the preceding configurations, run the display ospf peer command. You can view that
a neighbor relationship is established between Device A and Device B, and between Device B
and Device C. Use the command output Device A as an example.
<DeviceA> display ospf peer
# Display information about the OSPF routing table on Device A, and you can view the
routing entries to Device B and Device C. The next hop address of the route to 172.16.1.0/24
is 3.3.3.2, and service traffic is transmitted on the primary link.
<DeviceA> display ospf routing
Total Nets: 2
Intra Area: 2 Inter Area: 0 ASE: 0 NSSA: 0
[*DeviceA] bfd
[*DeviceA-bfd] quit
[*DeviceA] ospf
[*DeviceA-ospf-1] bfd all-interfaces enable
[*DeviceA-ospf-1] commit
[~DeviceA-ospf-1] quit
# After the preceding configurations, run the display ospf bfd session all command on
Device A, Device B, or Device C. You can view that the BFD session is
Up. Use the command output Device A as an example.
[~DeviceA] display ospf bfd session all
OSPF Process 1 with Router ID
1.1.1.1
Area 0.0.0.0 interface 1.1.1.1(GE1/0/0)'s BFD Sessions
[*DeviceB-GigabitEthernet2/0/0] commit
[~DeviceB-GigabitEthernet2/0/0] quit
# After the preceding configurations, run the display ospf bfd session all command on
Device A or Device B. You can check that the minimum intervals at which packets are
sent and received are 500 ms and that the local detection multiplier is 4.
Use the command output Device B as an example.
[~DeviceB] display ospf bfd session all
# Display the routing table on Device A. You can view that the backup link takes effect
after the primary link fails and that the next hop address of the route to 172.16.1.0/24 is
1.1.1.2.
<DeviceA> display ospf routing
----End
Configuration Files
Device A configuration file
#
sysname DeviceA
#
router id 1.1.1.1
#
bfd
#
interface GigabitEthernet1/0/0
undo shutdown
ip address 1.1.1.1 255.255.255.0
#
interface GigabitEthernet2/0/0
undo shutdown
ip address 3.3.3.1 255.255.255.0
ospf bfd enable
ospf bfd min-tx-interval 500 min-rx-interval 500 detect-multiplier 4
#
ospf 1
bfd all-interfaces enable
area 0.0.0.0
network 3.3.3.0 0.0.0.255
network 1.1.1.0 0.0.0.255
#
return
Networking Requirements
On the network shown in Figure 5-20, all devices run BGP. An EBGP connection is set up
between Device D and Device E. IBGP connections are set up between devices in AS 10, and
OSPF is used as an IGP protocol.
OSPF-BGP synchronization is required on Device B so that the restart of Device B does not
interrupt the traffic from Device A to AS 20.
Interface 1, interface 2, interface 3 in this example are GE 1/0/0, GE 2/0/0, and GE 3/0/0, respectively.
DeviceC AS 20
interface2 interface1 DeviceF
10.1.2.2/30 10.1.4.1/30
interface1
interface1 10.3.1.2/30
interface2
10.1.2.1/30 10.1.4.2/30 interface2
10.3.1.1/30
DeviceA DeviceD EBGP
DeviceE
interface3
interface1 10.2.1.1/30
10.1.1.1/30 interface2 interface1
10.1.3.2/30 10.2.1.2/30
interface1 interface2
10.1.1.2/30 10.1.3.1/30
DeviceB AS 10
Precautions
None
Configuration Roadmap
The configuration roadmap is as follows:
1. Enable OSPF on Device A, Device B, Device C, and Device D (except 10.2.1.1/30) and
specify the same area for all OSPF interfaces.
2. Set up IBGP connections between Device A, Device B, Device C, and Device D (except
10.2.1.1/30).
3. Configure the OSPF cost on Device C.
4. Set up EBGP connections between Device D and Device E.
Data Preparation
To complete the configuration, you need the following data:
Data of Device A, including the Router ID (1.1.1.1), number of the AS to which Device
A belongs (10), OSPF process number (1), and network segment addresses of Area 0
(10.1.1.0/30 and 10.1.2.0/30)
Data of Device B, including the Router ID (2.2.2.2), number of the AS to which Device
B belongs (10), OSPF process number (1), and network segment addresses of Area 0
(10.1.1.0/30 and 10.1.3.0/30)
Data of Device C, including the Router ID (3.3.3.3), number of the AS to which Device
C belongs (10), OSPF process number (1), and network segment addresses of Area 0
(10.1.2.0/30 and 10.1.4.0/30)
Data of Device D, including the Router ID (4.4.4.4), number of the AS to which Device
D belongs (10), OSPF process number (1), and network segment addresses of Area 0
(10.1.3.0/30 and 10.1.4.0/30)
Data of Device E, including the Router ID (5.5.5.5) and number of the AS to which
Device E belongs (20)
Procedure
Step 1 Assign an IP address to each interface. For configuration details, see Configuration Files in
this section.
Step 2 Configure basic OSPF functions. For details, see 5.22.1 Example for Configuring Basic
OSPF Functions.
Step 3 Set up IBGP connections.
# Configure Device A.
<DeviceA> system-view
[~DeviceA] interface loopback 0
[~DeviceA-LoopBack0] ip address 1.1.1.1 32
[*DeviceA-LoopBack0] quit
[*DeviceA] bgp 10
[*DeviceA-bgp] router-id 1.1.1.1
[*DeviceA-bgp] peer 2.2.2.2 as-number 10
[*DeviceA-bgp] peer 2.2.2.2 connect-interface LoopBack 0
[*DeviceA-bgp] peer 3.3.3.3 as-number 10
[*DeviceA-bgp] peer 3.3.3.3 connect-interface LoopBack 0
[*DeviceA-bgp] peer 4.4.4.4 as-number 10
[*DeviceA-bgp] peer 4.4.4.4 connect-interface LoopBack 0
[*DeviceA-bgp] quit
[*DeviceA] commit
# Configure Device B.
<DeviceB> system-view
[~DeviceB] interface loopback 0
[~DeviceB-LoopBack0] ip address 2.2.2.2 32
[*DeviceB-LoopBack0] quit
[*DeviceB] bgp 10
[*DeviceB-bgp] router-id 2.2.2.2
[*DeviceB-bgp] peer 1.1.1.1 as-number 10
[*DeviceB-bgp] peer 1.1.1.1 connect-interface LoopBack 0
# Configure Device C.
<DeviceC> system-view
[~DeviceC] interface loopback 0
[~DeviceC-LoopBack0] ip address 3.3.3.3 32
[*DeviceC-LoopBack0] quit
[*DeviceC] bgp 10
[*DeviceC-bgp] router-id 3.3.3.3
[*DeviceC-bgp] peer 1.1.1.1 as-number 10
[*DeviceC-bgp] peer 1.1.1.1 connect-interface LoopBack 0
[*DeviceC-bgp] peer 2.2.2.2 as-number 10
[*DeviceC-bgp] peer 2.2.2.2 connect-interface LoopBack 0
[*DeviceC-bgp] peer 4.4.4.4 as-number 10
[*DeviceC-bgp] peer 4.4.4.4 connect-interface LoopBack 0
[*DeviceC-bgp] quit
[*DeviceC] commit
# Configure Device D.
<DeviceD> system-view
[~DeviceD] interface loopback 0
[~DeviceD-LoopBack0] ip address 4.4.4.4 32
[*DeviceD-LoopBack0] quit
[*DeviceD] bgp 10
[*DeviceD-bgp] router-id 4.4.4.4
[*DeviceD-bgp] peer 1.1.1.1 as-number 10
[*DeviceD-bgp] peer 1.1.1.1 connect-interface LoopBack 0
[*DeviceD-bgp] peer 2.2.2.2 as-number 10
[*DeviceD-bgp] peer 2.2.2.2 connect-interface LoopBack 0
[*DeviceD-bgp] peer 3.3.3.3 as-number 10
[*DeviceD-bgp] peer 3.3.3.3 connect-interface LoopBack 0
[*DeviceD-bgp] quit
[*DeviceD] commit
# Configure Device E.
[*DeviceE] bgp 20
[*DeviceE-bgp] peer 10.2.1.1 as-number
10 [*DeviceE-bgp] ipv4-family unicast
[*DeviceE-bgp-af-ipv4] network 10.3.1.0
30 [*DeviceE-bgp-af-ipv4] quit
[*DeviceE-bgp] commit
[*DeviceC] commit
NOTE
After the OSPF cost is set to 2 on Device C, Device A selects only Device B as the intermediate router
to the network segment 10.2.1.0, and Device C becomes a backup of Device B.
# Check the routing table on DeviceA. BGP learns the route to 10.1.3.0, and the outbound
interface is GE 1/0/0.
[~DeviceA] display ip routing-table
Route Flags: R - relied, D - download to fib
------------------------------------------------------------------------------
Routing Tables: _public_
Destinations : 20 Routes : 20
As shown in the routing table, Device B learns the route to 10.3.1.0 through BGP, and the
outbound interface is GE 2/0/0. The routes to 10.1.2.0 and 10.1.4.0 can be learned through
OSPF. The costs of these routes are both 2.
Step 6 Enable OSPF-BGP synchronization on Device B.
[~DeviceB] ospf 1
[*DeviceB-ospf-1] stub-router on-startup
[*DeviceB-ospf-1] quit
[*DeviceB] commit
NOTE
Exercise caution when running the reboot command it may lead to a temporary network crash. In
addition, save the configuration file of the router before restarting the router.
<DeviceB> reboot
System will reboot! Continue?[Y/N] y
# Display the routing table on Device A. As shown in the routing table, BGP learns the route
to 10.3.1.0, and the outbound interface is GE 2/0/0.
[~DeviceA] display ip routing-table
Route Flags: R - relied, D - download to fib
------------------------------------------------------------------------------
Routing Tables: _public_
Destinations : 20 Routes : 20
# Display the routing table on Device B. As shown in the routing table, only OSPF routes
exist in the routing table because IGP routes converge faster than BGP routes do. The costs of
the OSPF routes are 65535.
[~DeviceB] display ip routing-table
Route Flags: R - relied, D - download to fib
------------------------------------------------------------------------------
Routing Tables: _public_
Destinations : 15 Routes : 15
As shown in the routing table, BGP routes on Device B have converged, and the routing
information is the same as that displayed before the restart.
----End
Configuration Files
Device A configuration file
#
sysname DeviceA
#
router id 1.1.1.1
#
interface GigabitEthernet1/0/0
undo shutdown
ip address 10.1.1.1 255.255.255.252
#
interface GigabitEthernet2/0/0
undo shutdown
ip address 10.1.2.1 255.255.255.252
#
interface LoopBack0
ip address 1.1.1.1 255.255.255.255
#
bgp 10
router-id 1.1.1.1
peer 2.2.2.2 as-number 10
peer 2.2.2.2 connect-interface LoopBack 0
peer 3.3.3.3 as-number 10
peer 3.3.3.3 connect-interface LoopBack 0
peer 4.4.4.4 as-number 10
peer 4.4.4.4 connect-interface LoopBack 0
#
ospf 1
area 0.0.0.0
network 1.1.1.1 0.0.0.0
network 10.1.1.0 0.0.0.3
network 10.1.2.0 0.0.0.3
#
return
#
bgp 10
router-id 2.2.2.2
peer 1.1.1.1 as-number 10
peer 1.1.1.1 connect-interface LoopBack 0
peer 3.3.3.3 as-number 10
peer 3.3.3.3 connect-interface LoopBack 0
peer 4.4.4.4 as-number 10
peer 4.4.4.4 connect-interface LoopBack 0
#
ospf 1
stub-router on-startup
area 0.0.0.0
network 10.1.1.0 0.0.0.3
network 10.1.3.0 0.0.0.3
network 2.2.2.2 0.0.0.0
#
return
Device C configuration file
#
sysname DeviceC
#
router id 3.3.3.3
#
interface GigabitEthernet1/0/0
undo shutdown
ip address 10.1.4.1 255.255.255.252
ospf cost 2
#
interface GigabitEthernet2/0/0
undo shutdown
ip address 10.1.2.2 255.255.255.252
ospf cost 2
#
interface LoopBack0
ip address 3.3.3.3 255.255.255.255
#
bgp 10
router-id 3.3.3.3
peer 1.1.1.1 as-number 10
peer 1.1.1.1 connect-interface LoopBack 0
peer 2.2.2.2 as-number 10
peer 2.2.2.2 connect-interface LoopBack 0
peer 4.4.4.4 as-number 10
peer 4.4.4.4 connect-interface LoopBack 0
#
ospf 1
area 0.0.0.0
network 10.1.2.0 0.0.0.3
network 10.1.4.0 0.0.0.3
network 3.3.3.3 0.0.0.0
#
return
Device D configuration file
#
sysname DeviceD
#
router id 4.4.4.4
#
interface GigabitEthernet1/0/0
undo shutdown
ip address 10.1.4.2 255.255.255.252
#
interface GigabitEthernet2/0/0
undo shutdown
ip address 10.1.3.2 255.255.255.252
#
interface GigabitEthernet3/0/0
undo shutdown
ip address 10.2.1.1 255.255.255.252
#
interface LoopBack0
ip address 4.4.4.4 255.255.255.255
#
bgp 10
router-id 4.4.4.4
peer 10.2.1.2 as-number 20
peer 1.1.1.1 as-number 10
peer 1.1.1.1 connect-interface LoopBack 0
peer 2.2.2.2 as-number 10
peer 2.2.2.2 connect-interface LoopBack 0
peer 3.3.3.3 as-number 10
peer 3.3.3.3 connect-interface LoopBack 0
#
ipv4-family unicast
undo synchronization
import-route direct
import-route ospf 1
peer 10.2.1.2 enable
#
ospf 1
area 0.0.0.0
network 4.4.4.4 0.0.0.0
network 10.1.3.0 0.0.0.3
network 10.1.4.0 0.0.0.3
#
return
Networking Requirements
In Figure 5-21, all routers run OSPF, and the AS consists of two areas: area 1 and area 2. The
link between router A and router B in area 1 is a high-speed link. Because intra-area links take
precedence over inter-area links during OSPF route selection, traffic from router A to router B
in area 2 is forwarded along the low-speed link of router A -> router C -> router D -> router
B, even though high-speed link between router A and router B exists. However, it is required
that traffic from router A to router B in area 2 be forwarded along the high-speed link between
router A and router B. In this case, configure OSPF multi-area adjacency on router A and
router B and add their multi-area adjacency interfaces to area 2.
Interface 1 and interface 2 in this example stand for GE 1/0/0 and GE 2/0/0, respectively.
Area
1
interface1
interface1
DeviceA
10.1.1.1/24 10.1.1.2/24
interface2 interface2
10.1.2.1/24 10.1.3.1/24
Area
interface2 2 interface2
10.1.2.2/24 10.1.3.2/24
interface1 interface1
DeviceC DeviceD
10.1.4.1/24 10.1.4.2/24
Configuration Roadmap
The configuration roadmap is as follows:
Data Preparation
To complete the configuration, you need the following data:
OSPF process ID: 1
OSPF areas: area 1 and area 2
Procedure
Step 1 Configure an IP address for each interface. The configuration details are not provided here.
# Configure Device A.
[~DeviceA] ospf 1
[*DeviceA-ospf-1] area 1
[*DeviceA-ospf-1-area-0.0.0.1] quit
[*DeviceA-ospf-1] quit
[*DeviceA] interface gigabitethernet 1/0/0
[*DeviceA-GigabitEthernet1/0/0] ospf enable 1 area 1
[*DeviceA-GigabitEthernet1/0/0] quit
[*DeviceA] ospf 1
[*DeviceA-ospf-1] area 2
[*DeviceA-ospf-1-area-0.0.0.2] quit
[*DeviceA-ospf-1] quit
[*DeviceA] interface gigabitethernet 2/0/0
[*DeviceA-GigabitEthernet2/0/0] ospf enable 1 area 2
[*DeviceA-GigabitEthernet2/0/0] quit
[*DeviceA] commit
# Configure Device B.
[~DeviceB] ospf 1
[*DeviceB-ospf-1] area 1
[*DeviceB-ospf-1-area-0.0.0.1] quit
[*DeviceB-ospf-1] quit
[*DeviceB] interface gigabitethernet 1/0/0
[*DeviceB-GigabitEthernet1/0/0] ospf enable 1 area 1
[*DeviceB-GigabitEthernet1/0/0] quit
[*DeviceB] ospf 1
[*DeviceB-ospf-1] area 2
[*DeviceB-ospf-1-area-0.0.0.2] quit
[*DeviceB-ospf-1] quit
[*DeviceB] interface gigabitethernet 2/0/0
[*DeviceB-GigabitEthernet2/0/0] ospf enable 1 area 2
[*DeviceB-GigabitEthernet2/0/0] quit
[*DeviceB] commit
# Configure Device C.
[~DeviceC] ospf 1
[*DeviceC-ospf-1] area 2
[*DeviceC-ospf-1-area-0.0.0.2] quit
[*DeviceC-ospf-1] quit
[*DeviceC] interface gigabitethernet 1/0/0
[*DeviceC-GigabitEthernet1/0/0] ospf enable 1 area 2
[*DeviceC-GigabitEthernet1/0/0] quit
[*DeviceC] interface gigabitethernet 2/0/0
[*DeviceC-GigabitEthernet2/0/0] ospf enable 1 area 2
[*DeviceC-GigabitEthernet2/0/0] quit
[*DeviceC] commit
# Configure Device D.
[~DeviceD] ospf 1
[*DeviceD-ospf-1] area 2
[*DeviceD-ospf-1-area-0.0.0.2] quit
[*DeviceD-ospf-1] quit
[*DeviceD] interface gigabitethernet 1/0/0
[*DeviceD-GigabitEthernet1/0/0] ospf enable 1 area 2
[*DeviceD-GigabitEthernet1/0/0] quit
[*DeviceD] interface gigabitethernet 2/0/0
[*DeviceD-GigabitEthernet2/0/0] ospf enable 1 area 2
[*DeviceD-GigabitEthernet2/0/0] quit
[*DeviceD] commit
# Run the display ospf peer brief command to check brief information about OSPF
neighbors. Device A is used as an example. The following command output shows that the
OSPF neighbor relationships between Device A and Device B and between Device A and
Device C are established.
[~DeviceA] display ospf peer brief
# Run the display ip routing-table command to check information about the IP routing table.
Device A is used as an example. The following command output shows that the outbound
interface of the route destined for 1.1.1.1 is GigabitEthernet 2/0/0.
[~DeviceA] display ip routing-table
Route Flags: R - relay, D - download
to fib, T - to vpn-instance, B - black hole route
------------------------------------------------------------------------------
Routing Table : _public_
Destinations : 13 Routes : 13
The preceding command output shows that traffic from router A to router B in area 2 is
forwarded along the low-speed link of router A -> router C -> router D -> router B.
Step 3 Enable OSPF on multi-area adjacency interfaces.
# Configure Device A.
[~DeviceA] interface gigabitethernet 1/0/0
[*DeviceA-GigabitEthernet1/0/0] ospf enable multi-area 2
[*DeviceA-GigabitEthernet1/0/0] quit
[*DeviceA] commit
# Configure Device B.
[~DeviceB] interface gigabitethernet 1/0/0
# Run the display ip routing-table command to check information about the IP routing table.
Device A is used as an example. The following command output shows that the outbound
interface of the route destined for 1.1.1.1 is GigabitEthernet 1/0/0.
[~DeviceA] display ip routing-table
Route Flags: R - relay, D - download
to fib, T - to vpn-instance, B - black hole route
------------------------------------------------------------------------------
Routing Table : _public_
Destinations : 13 Routes : 13
The preceding command output shows that traffic from router A to router B in area 2 is
forwarded along the high-speed link between router A and router B.
----End
Configuration Files
Device A configuration file
#
sysname DeviceA
#
interface GigabitEthernet1/0/0
undo shutdown
ip address 10.1.1.1 255.255.255.0
ospf enable 1 area 0.0.0.1
ospf enable multi-area 0.0.0.2
#
interface GigabitEthernet2/0/0
undo shutdown
ip address 10.1.2.1 255.255.255.0
ospf enable 1 area 0.0.0.2
#
ospf 1
area 0.0.0.1
area 0.0.0.2
#
return
#
sysname DeviceD
#
interface GigabitEthernet1/0/0
undo shutdown
ip address 10.1.4.2 255.255.255.0
ospf enable 1 area 0.0.0.2
#
interface GigabitEthernet2/0/0
undo shutdown
ip address 10.1.3.2 255.255.255.0
ospf enable 1 area 0.0.0.2
#
ospf 1
area 0.0.0.2
#
return
Networking Requirements
In Figure 5-22, CE1 and CE2 reside in the same OSPF area, belong to VPN1, and are
connected to PE1 and PE2, respectively. In this example, the cost of each link is 1.
It is required that OSPF run between each CE and its connected PE and the VPN traffic
between CE1 and CE2 be forwarded over the MPLS backbone network.
interface2 interface2
PE1 50.1.1.1/24 40.1.1.2/24 PE2
Interface1 interface2
interface1 interface1
50.1.1.2/24 P 40.1.1.1/24
172.16.1.2/24 172.16.2.2/24
Loopback10 Loopback10
5.5.5.5/32 6.6.6.6/32
Configuration Roadmap
The configuration roadmap is as follows:
1. Configure an MP-IBGP peer relationship between PEs and configure OSPF between
each CE and its connected PE.
2. Create a VPN instance on each PE and bind the VPN instance to the interface connected
to the corresponding CE.
3. Create an OSPF sham link between PEs.
4. Adjust the cost of forwarding interfaces over the user network to ensure that the cost of
the OSPF route used to forward the traffic over the user network is greater than that of
the sham link.
Data Preparation
To complete the configuration, you need the following data:
MPLS LSR IDs of the PEs and P
VPN instance name, RD, and VPN target of each PE
Data used to configure OSPF (The OSPF process running on the backbone network, the
OSPF process running on the user network, and the OSPF process connecting each PE to
the corresponding CE are different.)
Cost of the sham link and the cost of the OSPF route used to forward the traffic over the
user network
Procedure
Step 1 Configure OSPF on the user network.
Configure OSPF on CE1, RT0, and CE2 and advertise network segments of their interfaces.
# Configure CE1.
<HUAWEI> system-view
[~HUAWEI] sysname CE1
[~CE1] interface GigabitEthernet2/0/0
[~CE1-GigabitEthernet2/0/0] ip address 10.1.1.1 24
[*CE1-GigabitEthernet2/0/0] quit
[*CE1] interface GigabitEthernet1/0/0
[*CE1-GigabitEthernet1/0/0] ip address 172.16.1.1 24
[*CE1-GigabitEthernet1/0/0] quit
[*CE1] ospf
[*CE1-ospf-1] area 0
[*CE1-ospf-1-area-0.0.0.0] network 10.1.1.0 0.0.0.255
[*CE1-ospf-1-area-0.0.0.0] network 172.16.1.0 0.0.0.255
[*CE1-ospf-1-area-0.0.0.0] quit
[*CE1-ospf-1] quit
[*CE1] commit
# Configure RT0.
<HUAWEI> system-view
[~HUAWEI] sysname RT0
[~RT0] interface GigabitEthernet1/0/0
[~RT0-GigabitEthernet1/0/0] ip address 10.1.1.2 24
[*RT0-GigabitEthernet1/0/0] quit
[*RT0] interface GigabitEthernet2/0/0
[*RT0-GigabitEthernet2/0/0] ip address 10.2.1.1 24
[*RT0-GigabitEthernet2/0/0] quit
[*RT0] ospf
[*RT0-ospf-1] area 0
[*RT0-ospf-1-area-0.0.0.0] network 10.1.1.0 0.0.0.255
[*RT0-ospf-1-area-0.0.0.0] network 10.2.1.0 0.0.0.255
[*RT0-ospf-1-area-0.0.0.0] quit
[*RT0-ospf-1] quit
[*RT0] commit
# Configure CE2.
<HUAWEI> system-view
[~HUAWEI] sysname CE2
[~CE2] interface GigabitEthernet2/0/0
[~CE2-GigabitEthernet2/0/0] ip address 10.2.1.2 24
[*CE2-GigabitEthernet2/0/0] quit
[*CE2] interface GigabitEthernet1/0/0
[*CE2-GigabitEthernet1/0/0] ip address 172.16.2.1 24
[*CE2-GigabitEthernet1/0/0] quit
[*CE2] ospf
[*CE2-ospf-1] area 0
[*CE2-ospf-1-area-0.0.0.0] network 10.2.1.0 0.0.0.255
[*CE2-ospf-1-area-0.0.0.0] network 172.16.2.0 0.0.0.255
[*CE2-ospf-1-area-0.0.0.0] quit
[*CE2-ospf-1] quit
[*CE2] commit
Step 2 Configure basic BGP/MPLS IP VPN functions on the backbone network, including an IGP
(OSPF) on the backbone network, MPLS and LDP on the backbone network, and an MP-
IBGP peer relationship between PEs.
# Configure PE1.
<HUAWEI> system-view
[~HUAWEI] sysname PE1
[~PE1] interface loopback 1
[~PE1-LoopBack1] ip address 1.1.1.9 32
[*PE1-LoopBack1] quit
[*PE1] mpls lsr-id 1.1.1.9
[*PE1] mpls
[*PE1-mpls] quit
[*PE1] mpls ldp
[*PE1-mpls-ldp] quit
[*PE1] interface GigabitEthernet2/0/0
[*PE1-GigabitEthernet2/0/0] ip address 50.1.1.1 24
[*PE1-GigabitEthernet2/0/0] mpls
[*PE1-GigabitEthernet2/0/0] mpls ldp
[*PE1-GigabitEthernet2/0/0] quit
[*PE1] ospf
[*PE1-ospf-1] area 0
[*PE1-ospf-1-area-0.0.0.0] network 1.1.1.9 0.0.0.0
[*PE1-ospf-1-area-0.0.0.0] network 50.1.1.0 0.0.0.255
[*PE1-ospf-1-area-0.0.0.0] quit
[*PE1-ospf-1] quit
[*PE1] bgp 100
[*PE1-bgp] peer 3.3.3.9 as-number 100
[*PE1-bgp] peer 3.3.3.9 connect-interface loopback 1
[*PE1-bgp] ipv4-family vpnv4
[*PE1-bgp-af-vpnv4] peer 3.3.3.9 enable
[*PE1-bgp-af-vpnv4] quit
[*PE1-bgp] quit
[*PE1] commit
# Configure the P.
<HUAWEI> system-view
[~HUAWEI] sysname P
[~P] interface loopback 1
[~P-LoopBack1] ip address 2.2.2.9 32
[*P-LoopBack1] quit
# Configure PE2.
<HUAWEI> system-view
[~HUAWEI] sysname PE2
[~PE2] interface loopback 1
[~PE2-LoopBack1] ip address 3.3.3.9 32
[*PE2-LoopBack1] quit
[*PE2] mpls lsr-id 3.3.3.9
[*PE2] mpls
[*PE2-mpls] quit
[*PE2] mpls ldp
[*PE2-mpls-ldp] quit
[*PE2] interface GigabitEthernet2/0/0
[*PE2-GigabitEthernet2/0/0] ip address 40.1.1.2 24
[*PE2-GigabitEthernet2/0/0] mpls
[*PE2-GigabitEthernet2/0/0] mpls ldp
[*PE2-GigabitEthernet2/0/0] quit
[*PE2] ospf
[*PE2-ospf-1] area 0
[*PE2-ospf-1-area-0.0.0.0] network 3.3.3.9 0.0.0.0
[*PE2-ospf-1-area-0.0.0.0] network 40.1.1.0 0.0.0.255
[*PE2-ospf-1-area-0.0.0.0] quit
[*PE2-ospf-1] quit
[*PE2] bgp 100
[*PE2-bgp] peer 1.1.1.9 as-number 100
[*PE2-bgp] peer 1.1.1.9 connect-interface loopback 1
[*PE2-bgp] ipv4-family vpnv4
[*PE2-bgp-af-vpnv4] peer 1.1.1.9 enable
[*PE2-bgp-af-vpnv4] quit
[*PE2-bgp] quit
[*PE2] commit
After completing the configurations, PE1 and PE2 learn the route to each other's loopback
interface and establish an MP-IBGP peer relationship.
Step 3 Configure the connection between each PE and the corresponding CE, with OSPF running
between them.
# Configure PE1.
[~PE1] ip vpn-instance vpn1
[*PE1-vpn-instance-vpn1] ipv4-family
[*PE1-vpn-instance-vpn1-af-ipv4] route-distinguisher 100:1
[*PE1-vpn-instance-vpn1-af-ipv4] vpn-target 1:1
[*PE1-vpn-instance-vpn1-af-ipv4] quit
[*PE1-vpn-instance-vpn1] quit
[*PE1] interface gigabitethernet 1/0/0
[*PE1-GigabitEthernet1/0/0] ip binding vpn-instance vpn1
[*PE1-GigabitEthernet1/0/0] ip address 172.16.1.2 24
[*PE1-GigabitEthernet1/0/0] quit
[*PE1] ospf 100 vpn-instance vpn1
[*PE1-ospf-100] domain-id 10
[*PE1-ospf-100] import-route bgp
[*PE1-ospf-100] area 0
[*PE1-ospf-100-area-0.0.0.0] network 172.16.1.0 0.0.0.255
[*PE1-ospf-100-area-0.0.0.0] quit
[*PE1-ospf-100] quit
[*PE1] bgp 100
[*PE1-bgp] ipv4-family vpn-instance vpn1
[*PE1-bgp-vpn1] import-route direct
[*PE1-bgp-vpn1] import-route ospf 100
[*PE1-bgp-vpn1] quit
[*PE1-bgp] quit
[*PE1] commit
# Configure PE2.
[~PE2] ip vpn-instance vpn1
[*PE2-vpn-instance-vpn1] ipv4-family
[*PE2-vpn-instance-vpn1-af-ipv4] route-distinguisher 100:2
[*PE2-vpn-instance-vpn1-af-ipv4] vpn-target 1:1
[*PE2-vpn-instance-vpn1-af-ipv4] quit
[*PE2-vpn-instance-vpn1] quit
[*PE2] interface GigabitEthernet1/0/0
[*PE2-GigabitEthernet1/0/0] ip binding vpn-instance vpn1
[*PE2-GigabitEthernet1/0/0] ip address 172.16.2.2 24
[*PE2-GigabitEthernet1/0/0] quit
[*PE2] ospf 100 vpn-instance vpn1
[*PE2-ospf-100] import-route bgp
[*PE2-ospf-100] domain-id 10
[*PE2-ospf-100] area 0
[*PE2-ospf-100-area-0.0.0.0] network 172.16.2.0 0.0.0.255
[*PE2-ospf-100-area-0.0.0.0] quit
[*PE2-ospf-100] quit
[*PE2] bgp 100
[*PE2-bgp] ipv4-family vpn-instance vpn1
[*PE2-bgp-vpn1] import-route direct
[*PE2-bgp-vpn1] import-route ospf 100
[*PE2-bgp-vpn1] quit
[*PE2-bgp] quit
[*PE2] commit
After completing the configurations, run the display ip routing-table vpn-instance command
on a PE. You may find that the route to the remote CE is an OSPF route over the user network
rather than the BGP route over the backbone network.
The following example uses the command output on PE1.
<PE1> display ip routing-table vpn-instance vpn1
Route Flags: R - relay, D - download to fib, T - to vpn-instance, B - black hole
route
------------------------------------------------------------------------------
Routing Tables: vpn1
Destinations : 5 Routes : 5
Destination/Mask Proto Pre Cost Flags NextHop Interface
10.1.1.0/24 OSPF 10 2 D 172.16.1.1
GigabitEthernet1/0/0
10.2.1.0/24 OSPF 10 3 D 172.16.1.1
GigabitEthernet1/0/0
172.16.1.0/24 Direct 0 0 D 172.16.1.2
GigabitEthernet1/0/0
172.16.1.2/32 Direct 0 0 D 127.0.0.1
GigabitEthernet1/0/0
172.16.2.0/24 OSPF 10 4 D 172.16.1.1
GigabitEthernet1/0/0
To ensure that VPN traffic is forwarded over the MPLS backbone network, ensure that the cost of the
sham link is smaller than that of the OSPF route used to forward the traffic over the user network when
configuring the sham link. In most cases, you need to change the cost of the interfaces on the user
network to ensure that the cost of the OSPF route used to forward the traffic over the user network is
greater than that of the sham link.
# Configure CE1.
# Configure CE2.
[~CE2] interface GigabitEthernet2/0/0
[~CE2-GigabitEthernet2/0/0] ospf cost 10
[~CE2] interface loopback 1
[~CE2-LoopBack1] ip address 8.8.8.8
32 [*CE2-LoopBack1] ospf enable 1
area 0 [*CE2-LoopBack1] quit
[*CE2] commit
# Configure PE1.
[~PE1] interface loopback 10
[*PE1-LoopBack10] ip binding vpn-instance vpn1
[*PE1-LoopBack10] ip address 5.5.5.5 32
[*PE1-LoopBack10] quit
[*PE1] ospf 100 router-id 11.11.11.11
[*PE1-ospf-100] area 0
[*PE1-ospf-100-area-0.0.0.0] sham-link 5.5.5.5 6.6.6.6 cost 1
[*PE1-ospf-100-area-0.0.0.0] quit
[*PE1-ospf-100] quit
[*PE1] commit
# Configure PE2.
[~PE2] interface loopback 10
[*PE2-LoopBack10] ip binding vpn-instance vpn1
[*PE2-LoopBack10] ip address 6.6.6.6 32
[*PE2-LoopBack10] quit
[*PE2] ospf 100 router-id 22.22.22.22
[*PE2-ospf-100] area 0
[*PE2-ospf-100-area-0.0.0.0] sham-link 6.6.6.6 5.5.5.5 cost 1
[*PE2-ospf-100-area-0.0.0.0] quit
[*PE2-ospf-100] quit
[*PE2] commit
Run the display ip routing-table command on a CE. You may find that the cost of the OSPF
route to the remote CE becomes 3 and the next hop is the IP address of the connected PE
interface. The next hop indicates that the VPN traffic to the remote end is forwarded over the
backbone network.
The following example uses the command output on CE1.
<CE1> display ip routing-table
Route Flags: R - relay, D - download to fib, T - to vpn-instance, B - black hole
route
------------------------------------------------------------------------------
Routing Table : _public_
Destinations : 15 Routes : 15
Destination/Mask Proto Pre Cost Flags NextHop Interface
5.5.5.5/32 O_ASE 150 1 D 172.16.1.2
GigabitEthernet1/0/0
6.6.6.6/32 O_ASE 150 1 D 172.16.1.2
GigabitEthernet1/0/0
8.8.8.8/32 OSPF 10 3 D 172.16.1.2
GigabitEthernet1/0/0
10.1.1.0/24 Direct 0 0 D 10.1.1.1
GigabitEthernet2/0/0
10.1.1.1/32 Direct 0 0 D 127.0.0.1
GigabitEthernet2/0/0
10.1.1.255/32 Direct 0 0 D 127.0.0.1
GigabitEthernet2/0/0
10.2.1.0/24 OSPF 10 11 D 10.1.1.2
GigabitEthernet2/0/0
127.0.0.0/8 Direct 0 0 D 127.0.0.1 InLoopBack0
127.0.0.1/32 Direct 0 0 D 127.0.0.1 InLoopBack0
127.255.255.255/32 Direct 0 0 D 127.0.0.1 InLoopBack0
172.16.1.0/24 Direct 0 0 D 172.16.1.1
GigabitEthernet1/0/0
172.16.1.1/32 Direct 0 0 D 127.0.0.1
GigabitEthernet1/0/0
172.16.1.255/32 Direct 0 0 D 127.0.0.1
GigabitEthernet1/0/0
172.16.2.0/24 OSPF 10 3 D 172.16.1.2
GigabitEthernet1/0/0
255.255.255.255/32 Direct 0 0 D 127.0.0.1 InLoopBack0
NOTE
Cost (3) of the OSPF route from CE1 to CE2 = Cost (1) of the link from CE1 to PE1 + Cost (1) of the
sham link + Cost (1) of the link from PE2 to CE2
Run the tracert command and you may find that the next hop for CE1 to send data to CE2 is
the IP address of PE1's GE 1/0/0. The next hop indicates that the VPN traffic to the remote
end is forwarded over the backbone network.
<CE1> tracert 172.16.2.1
Run the display ospf sham-link command on a PE to check whether the sham link is established.
The following example uses the command output on PE1.
Run the display ospf sham-link area command. The following command output shows that the OSPF neigh
relationship is in Full state.
<PE1> display ospf sham-link area 0
OSPF Process 100 with Router ID 11.11.11.11
Sham-Link: 5.5.5.5 --> 6.6.6.6
NeighborID: 22.22.22.22, State: Full, GR status: Normal
Area: 0.0.0.0
Cost: 1 , State: P-2-P , Type: Sham
Timers: Hello 10 , Dead 40 , Retransmit 5 , Transmit Delay 1
Run the display ospf routing command on a CE. The following command output shows that the route to the
CE is an intra-area route.
<CE1> display ospf routing
OSPF Process 1 with Router ID 10.1.1.1
Routing Tables
Routing for Network
Destination Cost Type NextHop AdvRouter Area
8.8.8.8/32 3 Stub 172.16.1.2 10.2.1.2 0.0.0.0
10.1.1.0/24 10 Direct 10.1.1.1 10.1.1.1 0.0.0.0
10.2.1.0/24 11 Transit 10.1.1.2 10.1.1.2 0.0.0.0
172.16.1.0/24 1 Direct 172.16.1.1 10.1.1.1 0.0.0.0
172.16.2.0/24 3 Transit 172.16.1.2 10.2.1.2 0.0.0.0
Routing for ASEs
Destination Cost Type Tag NextHop AdvRouter
6.6.6.6/32 1 Type2 3489661028 172.16.1.2 11.11.11.11
5.5.5.5/32 1 Type2 3489661028 172.16.1.2 22.22.22.22
Total Nets: 7
Intra Area: 5 Inter Area: 0 ASE: 2 NSSA: 0
----End
Configuration Files
PE1 configuration file
#
sysname PE1
#
ip vpn-instance vpn1
ipv4-family
route-distinguisher 100:1
vpn-target 1:1 export-extcommunity
vpn-target 1:1 import-extcommunity
#
import-route bgp
domain-id 0.0.0.10
area 0.0.0.0
network 172.16.2.0 0.0.0.255
sham-link 6.6.6.6 5.5.5.5 cost 1
#
return
return