S1720, S2700, S5700, and S6720 V200R011C10 Configuration Guide - IP Unicast Routing
This document describes IP Unicast Routing configurations supported by the switch, including the principle and configuration procedures of IP Routing Overview, Static Route, RIP, RIPng, OSPF, OSPFv3, IS-IS(IPv4), IS-IS(IPv6), BGP, Routing Policy ,and PBR, and provides configuration examples.
Fundamentals of OSPF
OSPF Characteristics
In an OSPF network, each router generates a link-state advertisement (LSA) based on its surrounding network topology and transmits this LSA in an update packet to other routers in the network.
RIP devices exchange routes, whereas OSPF devices exchange link state information. That is, in RIP, routers select routes based on routing information of neighbors, without checking whether the information transmitted by neighbors is correct; in OSPF, routers calculate routes by themselves and select routes based on LSAs.
Each router learns about the whole network topology based on its link state database (LSDB). In Figure 6-1, each router collects LSAs sent from other routers, and all LSAs form the LSDB of this router. An LSA describes the surrounding network topology of a router, whereas an LSDB describes the network topology of the entire AS. A router transforms its LSDB into a weighted, directed graph, which reflects the topology of the entire AS. When the network topology is stable, all routers in the same area have the same graph.
A router calculates shortest paths to destinations using a shortest path first (SPF) algorithm instead of obtaining routing information through route advertisements. In Figure 6-2, based on the weighted, directed graph, each router uses an SPF algorithm to calculate a shortest path tree (SPT) with itself as the root. The SPT shows routes to nodes in the AS. This mechanism greatly improves routers' capabilities in independent route selection so that routers do not need to select routes based on route advertisement.
An LSDB ensures that a router learns about the whole network topology, and an SPF algorithm ensures that a router fast calculates shortest paths to destinations.
OSPF Mechanism
The OSPF mechanism includes the following steps:
Exchanging Hello packets to establish OSPF neighbor relationships
In Figure 6-3, after OSPF runs on the four routers, these routers send Hello packets from all OSPF-enabled interfaces. If two routers share a data link and successfully negotiate some parameters specified in their Hello packets, they establish an OSPF neighbor relationship.
Flooding LSAs to advertise link state information
Routers that have established an OSPF adjacency can exchange LSAs, as shown in Figure 6-4. LSAs describe information about a router, including all links, interfaces, neighbors, and link state. Routers exchange the link information to learn about the whole network topology. Because of link diversity, OSPF defines multiple LSA types. For details, see OSPF LSA Types.
Routers form their LSDBs to create a weighted, directed graph.
A router floods LSAs and records received LSAs in its LSDB. Finally, all routers form the same LSDB, as shown in Figure 6-5. An LSA describes the surrounding network topology of a router, whereas an LSDB describes the network topology of the entire AS and is the summary of LSAs.
Using an SPF algorithm to calculate and generate routes
In Figure 6-6, after LSDB synchronization is complete, each router uses an SPF algorithm to calculate a loop-free topology with itself as the root to describe the shortest path (with the minimum path cost) to each destination. The topology is the SPT, which shows the optimal paths to nodes in an AS.
Maintaining and updating routing tables
After each router uses an SPF algorithm to calculate the SPT, it installs the shortest paths in its routing table as routing entries to guide data forwarding and updates the routing table in real time, as shown in Figure 6-7. Meanwhile, neighbors exchange Hello packets to maintain their neighbor relationships or adjacencies and periodically retransmit LSAs.
OSPF Packet Types
OSPF provides five types of packets:
Hello packet
Hello packets are sent periodically by OSPF-enabled interfaces to discover and maintain OSPF neighbor relationships. These packets contain some timer values and information about the Designated Router (DR), Backup Designated Router (BDR), and known neighbors on the same network.
Database Description (DD) packet
During adjacency initialization, two routers send DD packets to negotiate their master/slave relationship. The DD packets do not contain an LSA header. When two routers exchange DD packets, one functions as the master and the other functions as the slave. The master defines a start sequence number and increases the sequence number by 1 each time it sends a DD packet. After the slave receives a DD packet, it uses the sequence number carried in the DD packet for acknowledgement. After an adjacency is established, routers use DD packets to describe their own LSDBs for LSDB synchronization. A DD packet contains the header of each LSA in an LSDB and is the summary of all LSAs. An LSA header uniquely identifies an LSA. The LSA header occupies only a small portion of the LSA, which reduces the amount of traffic transmitted between routers. A neighbor can use the LSA header to check whether it already has the LSA.
Link State Request (LSR) packet
After two routers have exchanged DD packets, they send LSR packets to request each other's LSAs. The LSR packets contain the summaries of the requested LSAs.
Link State Update (LSU) packet
A router uses an LSU packet to transmit LSAs requested by its neighbors or to flood its own updated LSAs. The LSU packet contains a set of LSAs. To ensure reliable LSA flooding, the router uses an LSAck packet to acknowledge the LSAs contained in an LSU packet that is received from a neighbor. If an LSA fails to be acknowledged, the router retransmits the LSA to the neighbor.
Link State Acknowledgement (LSAck) packet
A router uses an LSAck packet to acknowledge the LSAs contained in a received LSU packet. The LSAs can be acknowledged using LSA headers.
OSPF Network Types
Four OSPF network types are classified based on link layer protocols.
Broadcast
Networks using Ethernet or Fiber Distributed Data Interface (FDDI) at the link layer are broadcast networks by default.
On broadcast networks:
Hello packets, LSU packets, and LSAck packets are sent in multicast mode. 224.0.0.5 is the IP multicast address reserved for OSPF DR others. 224.0.0.6 is the IP multicast address reserved for OSPF DRs or BDRs.
DD and LSR packets are sent in unicast mode.
Non-Broadcast Multi-Access (NBMA)
Networks using frame relay (FR) or X.25 at the link layer are NBMA networks by default.
Within NBMA networks, protocol packets such as Hello packets, DD packets, LSR packets, LSU packets, and LSAck packets are sent in unicast mode.
Point-to-Multipoint (P2MP)
No networks are P2MP networks by default, regardless of the link layer protocol used by the network. Networks may be changed to P2MP networks. Typical practice is to change partial-meshed NBMA networks to P2MP networks.
On a P2MP network:
Hello packets are transmitted in multicast mode using the multicast address 224.0.0.5.
DD packets, LSR packets, LSU packets, and LSAck packets are sent in unicast mode.
Point-to-Point (P2P)
Networks using Point-to-Point Protocol (PPP), High-Level Data Link Control (HDLC), or Link Access Procedure Balanced (LAPB) at the link layer are P2P networks.
Within P2P networks, protocol packets such as Hello packets, DD packets, LSR packets, LSU packets, and LSAck packets are sent in multicast mode using the multicast address 224.0.0.5.
DR/BDR Election
Router ID
Before learning the DR/BDR election process, you need to know the router ID. A router ID is a 32-bit integer, which uniquely identifies an OSPF router in an AS. Each OSPF router has a router ID. A router ID is in the same format as an IP address. To ensure OSPF stability in actual network deployment, it is recommended that the IP address of a loopback interface on a router be used as the router ID of this router.
A router ID can be manually configured or automatically selected by a router.
If no router ID is manually configured for a router, the router automatically selects an interface IP address as its router ID. The router ID selection rules are as follows:
The router preferentially selects the largest IP address among loopback interface addresses as the router ID.
If no loopback interface is configured, the router selects the largest IP address among interface addresses as the router ID.
A switch can obtain a router ID again only after a router ID is reconfigured for the switch or an OSPF router ID is reconfigured and the OSPF process restarts.
Reason for DR/BDR Election
On broadcast and non-broadcast multiple access (NBMA) networks, any two routers need to exchange routing information. On the network in Figure 6-8, there are n routers that need to establish n x (n - 1)/2 adjacencies. A route change on any router is transmitted to the other routers, which wastes bandwidth resources.
To solve this problem, the concept of DR is defined in OSPF. After a DR is elected, all the other routers send routing information only to the DR, and the DR broadcasts LSAs.
To prevent service interruption caused by DR re-election when the DR fails, a BDR is also elected during DR election. The routers excluding DR and BDR are called DR others. The DR others do not establish adjacencies or exchange any routing information with each other. This reduces the number of adjacencies established between routers on broadcast and NBMA networks.
DR/BDR Election Implementation
To ensure stable DR/BDR election on broadcast and NBMA networks, OSPF defines three election rules: election, non-preemption, and inheritance.
Election
The DR and BDR are not designated manually, but are elected by all routers on the local network segment. In Figure 6-9, DR priorities of router interfaces determine whether the interfaces are qualified for DR/BDR election. Routers with DR priorities larger than 0 on the local network segment can be considered as candidates. The ballots in this election are Hello packets. Each router adds elected DR information to a Hello packet and sends the packet to other routers on the network segment. When two routers on the same network segment declare that they are the DR, the router with a higher DR priority is elected as the DR. If the two switch interfaces have the same DR priority, the switch interface with a larger router ID is elected as a DR. The router whose priority is 0 cannot be elected as a DR or a BDR.
Non-preemption
A router newly added to a network segment does not attempt in election and checks whether a DR exists on the network segment. In Figure 6-10, a DR exists on the network segment. Even if the DR priority of the newly added router is higher than that of the DR, the newly added router does not declare itself as the DR, and acknowledges the existing DR. Routers on a network segment only establish adjacencies with the DR and BDR. If the DR changes frequently, all routers on the network segment need to establish adjacencies with the new DR and BDR accordingly. As a result, a large number of OSPF packets are transmitted on the network segment within a short period of time, reducing the available bandwidth. The non-preemption principle improves network stability and saves the available network bandwidth. On a broadcast or NBMA network, the two routers that are qualified for DR election and start first become the DR and BDR.
Inheritance
If the DR on a network segment fails, the BDR is elected as the DR, and the other routers compete to become the new BDR, as shown in Figure 6-11. This ensures the DR stability and prevents frequent DR elections. If the DR has a BDR, the BDR becomes the new DR when the DR fails. Because LSDBs of the DR and BDR are fully synchronized, the BDR immediately becomes the new DR when the DR fails and performs duties of the DR. Because adjacencies have been established, the time from role change to service switching is short. In addition, when the BDR becomes the new DR, a new BDR will be elected. Although the election process takes a relatively long time, route calculation is not affected.
DR/BDR Election Process
The DR/BDR election process on a broadcast or NBMA network is as follows:
After an interface goes Up, it sends a Hello packet and enters the Waiting state. In the Waiting state, a wait timer is triggered. The wait timer value is the same as the dead timer value. The default wait timer value is 40 seconds and cannot be changed. For details about OSPF interface status, see OSPF Interface State Machine.
Before the wait timer is triggered, sent Hello packets do not contain DR or BDR information. In the Waiting state, if a received Hello packet contains DR and BDR information, the interface directly acknowledges the DR and BDR on the network, and does not trigger election. The interface directly exits the Waiting state and starts neighbor synchronization.
Assume that a DR and a BDR exist on the network. A router newly connected to the network acknowledges the existing DR and BDR regardless of how large its router ID or DR priority is.
If the DR fails and goes down, the BDR takes over the role of the DR and the other routers whose priority is greater than 0 compete to become the new BDR.
DR election rules are used to elect a DR only when routers with different router IDs or configured with different DR priorities are started at the same time. The election rules are that the device with the highest DR priority is elected as DR and the device with the second highest DR priority as BDR. A router with a DR priority of 0 can be a DR other only. If routers have the same DR priority, the router with the greatest router ID is elected as the DR, the router with the second greatest router ID becomes the BDR, and other routers are DR others.
Verifying the DR/BDR Election Process
Five routers establish a broadcast network. R5 works as a Layer 2 device, and R1 to R4 work as routers. R1 to R4 are in OSPF area 0. The IP addresses and router IDs of the routers are shown in Figure 6-12.
DR and BDR Are Properly Elected on the Network
Assume that interfaces on R1 to R4 are configured. Only OSPF configurations are provided here.
Configuration of R1
# ospf 1 Router ID 10.1.1.1 area 0.0.0.0 network 192.168.1.0 0.0.0.255 #
Configuration of R2
# ospf 1 Router ID 10.2.2.2 area 0.0.0.0 network 192.168.1.0 0.0.0.255 #
Configuration of R3
# ospf 1 Router ID 10.3.3.3 area 0.0.0.0 network 192.168.1.0 0.0.0.255 #
Configuration of R4
# ospf 1 Router ID 10.4.4.4 area 0.0.0.0 network 192.168.1.0 0.0.0.255 #
After the configurations are complete and the network is stable, check the DR/BDR election status.
# Check OSPF neighbor information on R1. The following command output shows that DR/BDR election has been completed. R1 is the DR, R2 is the BDR, and R3 and R4 are DR others. The reason why R1 and R2 are elected as the DR and BDR respectively is directly related to their startup sequence. In this example, R1, R2, R3, and R4 are started in sequence. Therefore, R1 and R2 complete initialization first and become the DR and BDR, respectively.
<R1> display ospf peer
OSPF Process 1 with Router ID 10.1.1.1
Neighbors
Area 0.0.0.0 interface 192.168.1.1(GigabitEthernet0/0/1)'s neighbors
Router ID: 10.2.2.2 Address: 192.168.1.2
State: Full Mode:Nbr is Master Priority: 1
DR: 192.168.1.1 BDR: 192.168.1.2 MTU: 0
Dead timer due in 38 sec
Retrans timer interval: 5
Neighbor is up for 00:22:16
Authentication Sequence: [ 0 ]
Router ID: 10.3.3.3 Address: 192.168.1.3
State: Full Mode:Nbr is Master Priority: 1
DR: 192.168.1.1 BDR: 192.168.1.2 MTU: 0
Dead timer due in 35 sec
Retrans timer interval: 5
Neighbor is up for 00:21:30
Authentication Sequence: [ 0 ]
Router ID: 10.4.4.4 Address: 192.168.1.4
State: Full Mode:Nbr is Master Priority: 1
DR: 192.168.1.1 BDR: 192.168.1.2 MTU: 0
Dead timer due in 33 sec
Retrans timer interval: 5
Neighbor is up for 00:20:24
Authentication Sequence: [ 0 ]
# Check brief OSPF neighbor information on R1, R2, R3, and R4. The following command outputs show that the states of neighbor relationships between R1 and the other three routers and those between R2 and the other three routers are Full, and the state of the neighbor relationship between R3 and R4 is 2-Way. The states indicate that the DR and BDR establish adjacencies with other routers, and DR others only establish neighbor relationships. For details about OSPF neighbor status, see OSPF Neighbor State Machine.
<R1> display ospf 1 peer brief
OSPF Process 1 with Router ID 10.1.1.1
Peer Statistic Information
----------------------------------------------------------------------------
Area Id Interface Neighbor id State
0.0.0.0 GigabitEthernet0/0/1 10.2.2.2 Full
0.0.0.0 GigabitEthernet0/0/1 10.3.3.3 Full
0.0.0.0 GigabitEthernet0/0/1 10.4.4.4 Full
----------------------------------------------------------------------------
Total Peer(s): 3
<R2> display ospf 1 peer brief
OSPF Process 1 with Router ID 10.2.2.2
Peer Statistic Information
----------------------------------------------------------------------------
Area Id Interface Neighbor id State
0.0.0.0 GigabitEthernet0/0/1 10.1.1.1 Full
0.0.0.0 GigabitEthernet0/0/1 10.3.3.3 Full
0.0.0.0 GigabitEthernet0/0/1 10.4.4.4 Full
----------------------------------------------------------------------------
Total Peer(s): 3
<R3> display ospf 1 peer brief
OSPF Process 1 with Router ID 10.3.3.3
Peer Statistic Information
----------------------------------------------------------------------------
Area Id Interface Neighbor id State
0.0.0.0 GigabitEthernet0/0/1 10.1.1.1 Full
0.0.0.0 GigabitEthernet0/0/1 10.2.2.2 Full
0.0.0.0 GigabitEthernet0/0/1 10.4.4.4 2-Way
----------------------------------------------------------------------------
Total Peer(s): 3
<R4> display ospf 1 peer brief
OSPF Process 1 with Router ID 10.4.4.4
Peer Statistic Information
----------------------------------------------------------------------------
Area Id Interface Neighbor id State
0.0.0.0 GigabitEthernet0/0/1 10.1.1.1 Full
0.0.0.0 GigabitEthernet0/0/1 10.2.2.2 Full
0.0.0.0 GigabitEthernet0/0/1 10.3.3.3 2-Way
----------------------------------------------------------------------------
Total Peer(s): 3
BDR Cannot Be Elected on the Network
If the ospf dr-priority command is run on GE0/0/1 of R2, R3, and R4 to set the interface DR priority to 0, the three routers are unqualified for DR/BDR election and can only work as DR others. Only one router (R1) on the network is qualified for DR/BDR election.
# Check OSPF neighbor information on R1. The following command output shows that R1 is the DR and the BDR field displays None, indicating that no BDR exists on the network.
<R1> display ospf peer
OSPF Process 1 with Router ID 10.1.1.1
Neighbors
Area 0.0.0.0 interface 192.168.1.1(GigabitEthernet0/0/1)'s neighbors
Router ID: 10.2.2.2 Address: 192.168.1.2
State: Full Mode:Nbr is Master Priority: 0
DR: 192.168.1.1 BDR: None MTU: 0
Dead timer due in 38 sec
Retrans timer interval: 5
Neighbor is up for 00:04:31
Authentication Sequence: [ 0 ]
Router ID: 10.3.3.3 Address: 192.168.1.3
State: Full Mode:Nbr is Master Priority: 0
DR: 192.168.1.1 BDR: None MTU: 0
Dead timer due in 35 sec
Retrans timer interval: 5
Neighbor is up for 00:03:45
Authentication Sequence: [ 0 ]
Router ID: 10.4.4.4 Address: 192.168.1.4
State: Full Mode:Nbr is Master Priority: 0
DR: 192.168.1.1 BDR: None MTU: 0
Dead timer due in 33 sec
Retrans timer interval: 5
Neighbor is up for 00:03:36
Authentication Sequence: [ 0 ]
# Check brief OSPF neighbor information on R1, R2, R3, and R4. The following command outputs show that R2, R3, and R4 establish adjacencies with R1, respectively, the corresponding states are Full, and the states of neighbor relationships among R2, R3, and R4 are 2-Way.
<R1> display ospf 1 peer brief
OSPF Process 1 with Router ID 10.1.1.1
Peer Statistic Information
----------------------------------------------------------------------------
Area Id Interface Neighbor id State
0.0.0.0 GigabitEthernet0/0/1 10.2.2.2 Full
0.0.0.0 GigabitEthernet0/0/1 10.3.3.3 Full
0.0.0.0 GigabitEthernet0/0/1 10.4.4.4 Full
----------------------------------------------------------------------------
Total Peer(s): 3
<R2> display ospf 1 peer brief
OSPF Process 1 with Router ID 10.2.2.2
Peer Statistic Information
----------------------------------------------------------------------------
Area Id Interface Neighbor id State
0.0.0.0 GigabitEthernet0/0/1 10.1.1.1 Full
0.0.0.0 GigabitEthernet0/0/1 10.3.3.3 2-Way
0.0.0.0 GigabitEthernet0/0/1 10.4.4.4 2-Way
----------------------------------------------------------------------------
Total Peer(s): 3
<R3> display ospf 1 peer brief
OSPF Process 1 with Router ID 10.3.3.3
Peer Statistic Information
----------------------------------------------------------------------------
Area Id Interface Neighbor id State
0.0.0.0 GigabitEthernet0/0/1 10.1.1.1 Full
0.0.0.0 GigabitEthernet0/0/1 10.2.2.2 2-Way
0.0.0.0 GigabitEthernet0/0/1 10.4.4.4 2-Way
----------------------------------------------------------------------------
Total Peer(s): 3
<R4> display ospf 1 peer brief
OSPF Process 1 with Router ID 10.4.4.4
Peer Statistic Information
----------------------------------------------------------------------------
Area Id Interface Neighbor id State
0.0.0.0 GigabitEthernet0/0/1 10.1.1.1 Full
0.0.0.0 GigabitEthernet0/0/1 10.2.2.2 2-Way
0.0.0.0 GigabitEthernet0/0/1 10.3.3.3 2-Way
----------------------------------------------------------------------------
Total Peer(s): 3
In conclusion, if only one router on a broadcast network is qualified for DR/BDR election, the router becomes the DR, no BDR exists on the network, and all the other routers only establish adjacencies with the DR.
DR and BDR Cannot Be Elected on the Network
Based on the preceding configuration, if the ospf dr-priority command is run on GE0/0/1 of R1 to set the interface DR priority to 0, R1 is also unqualified for DR/BDR election. No router on the network is qualified for DR/BDR election.
# Check OSPF neighbor information on R1. The following command output shows that both the DR and BDR fields display None, indicating that no DR or BDR exists on the network.
<R1> display ospf peer
OSPF Process 1 with Router ID 10.1.1.1
Neighbors
Area 0.0.0.0 interface 192.168.1.1(GigabitEthernet0/0/1)'s neighbors
Router ID: 10.2.2.2 Address: 192.168.1.2
State: Full Mode:Nbr is Master Priority: 0
DR: None BDR: None MTU: 0
Dead timer due in 38 sec
Retrans timer interval: 5
Neighbor is up for 00:00:00
Authentication Sequence: [ 0 ]
Router ID: 10.3.3.3 Address: 192.168.1.3
State: Full Mode:Nbr is Master Priority: 0
DR: None BDR: None MTU: 0
Dead timer due in 35 sec
Retrans timer interval: 5
Neighbor is up for 00:00:00
Authentication Sequence: [ 0 ]
Router ID: 10.4.4.4 Address: 192.168.1.4
State: Full Mode:Nbr is Master Priority: 0
DR: None BDR: None MTU: 0
Dead timer due in 33 sec
Retrans timer interval: 5
Neighbor is up for 00:00:00
Authentication Sequence: [ 0 ]
# Check brief OSPF neighbor information on R1, R2, R3, and R4. The following command outputs show that the states of all neighbor relationships are 2-Way, no adjacency can be established on the network, and routers cannot exchange routing information.
<R1> display ospf 1 peer brief
OSPF Process 1 with Router ID 10.1.1.1
Peer Statistic Information
----------------------------------------------------------------------------
Area Id Interface Neighbor id State
0.0.0.0 GigabitEthernet0/0/1 10.2.2.2 2-Way
0.0.0.0 GigabitEthernet0/0/1 10.3.3.3 2-Way
0.0.0.0 GigabitEthernet0/0/1 10.4.4.4 2-Way
----------------------------------------------------------------------------
Total Peer(s): 3
<R2> display ospf 1 peer brief
OSPF Process 1 with Router ID 10.2.2.2
Peer Statistic Information
----------------------------------------------------------------------------
Area Id Interface Neighbor id State
0.0.0.0 GigabitEthernet0/0/1 10.1.1.1 2-Way
0.0.0.0 GigabitEthernet0/0/1 10.3.3.3 2-Way
0.0.0.0 GigabitEthernet0/0/1 10.4.4.4 2-Way
----------------------------------------------------------------------------
Total Peer(s): 3
<R3> display ospf 1 peer brief
OSPF Process 1 with Router ID 10.3.3.3
Peer Statistic Information
----------------------------------------------------------------------------
Area Id Interface Neighbor id State
0.0.0.0 GigabitEthernet0/0/1 10.1.1.1 2-Way
0.0.0.0 GigabitEthernet0/0/1 10.2.2.2 2-Way
0.0.0.0 GigabitEthernet0/0/1 10.4.4.4 2-Way
----------------------------------------------------------------------------
Total Peer(s): 3
<R4> display ospf 1 peer brief
OSPF Process 1 with Router ID 10.4.4.4
Peer Statistic Information
----------------------------------------------------------------------------
Area Id Interface Neighbor id State
0.0.0.0 GigabitEthernet0/0/1 10.1.1.1 2-Way
0.0.0.0 GigabitEthernet0/0/1 10.2.2.2 2-Way
0.0.0.0 GigabitEthernet0/0/1 10.3.3.3 2-Way
----------------------------------------------------------------------------
Total Peer(s): 3
In conclusion, if no router on a broadcast network is qualified for DR/BDR election, the network has no DR or BDR, and routers on the network do not establish adjacencies. In this case, the states of all neighbor relationships among these routers are 2-Way.
OSPF State Machine
OSPF interface state machine
An OSPF device obtains link information from an interface and then establishes an adjacency with neighbors to exchange the link information. Before establishing adjacencies, these devices need to determine their roles to establish connections. The State field in OSPF interface information displayed using the display ospf interface command indicates the functions of an OSPF device on a link.
The OSPF interface state machine has the following states:
Down: This state is the initial state of an OSPF interface. If an OSPF interface is Down, it is unavailable and cannot receive and transmit traffic.
Loopback: An OSPF interface that connects a device to the network is in Loopback state. A loopback interface cannot transmit data but can be advertised using Router-LSAs. Therefore, during a connectivity test, you can find the path to a loopback interface.
Waiting: The device is determining the DR and BDR on the network. Before the device participates in DR and BDR election, the wait timer starts on an OSPF interface. Before this timer expires, the Hello packets sent by this device do not contain DR and BDR information, and the device cannot be elected as the DR or BDR. This prevents the existing DR and BDR on the link from being changed unnecessarily and ensures stability. This state exists only on Non-Broadcast Multi-Access (NBMA) and broadcast networks.
P-2-P: An OSPF interface is connected to a physical point-to-point network or virtual link. In this situation, the device establishes an adjacency with the device on the other end of the link. This state exists only on P2P and point-to-multipoint (P2MP) networks.
DROther: The device is not elected as the DR or BDR, and another device that is connected to a broadcast or NBMA network is elected as the DR. This device will establish an adjacency with the DR and BDR.
BDR: The device functions as the BDR on the network and will become the new DR when the existing DR fails. This device establishes adjacencies with all the other devices on the network.
DR: The device functions as the DR on the network. This device establishes adjacencies with all the other devices on the network.
An OSPF interface alternates among the preceding states based on the InputEvent (IE). This forms an efficient interface state machine, as shown in Figure 6-13.
Table 6-1 lists the InputEvents occurring during a neighbor state switchover. The InputEvent is abbreviated to IE in Figure 6-13.
InputEvent |
Description |
|---|---|
IE1 |
InterfaceUP: Lower-layer protocols indicate that an OSPF interface is available. |
IE2 |
WaitTimer: The wait timer expires, indicating that the DR/BDR election waiting time ends. |
IE3 |
BackupSeen: The device where an OSPF interface is located has detected whether there is a BDR on the network. This event occurs in either of the following situations:
The two situations indicate that neighbors have communicated with each other and the Waiting state ends. |
IE4 |
The device is elected as the DR on the network. |
IE5 |
The device is elected as the BDR on the network. |
IE6 |
The device is not elected as the DR or BDR on the network. |
IE7 |
NeighborChange: A neighbor relationship change event related to the interface occurs, indicating that the DR and BDR need to be elected again. The following neighbor relationship changes may result in DR/BDR re-election:
|
IE8 |
UnLoopInd: The NMS or lower-layer protocols indicate that the interface is not in Loopback state. |
IE9 |
InterfaceDown: Lower-layer protocols indicate that the interface is unavailable. Any state may change to the Down state after this event is triggered. |
IE10 |
LoopInd: The NMS or lower-layer protocols indicate that the interface is in Loopback state. Any state may change to the Loopback state after this event is triggered. |
OSPF neighbor state machine
On an OSPF network, neighbors establish adjacencies and exchange LSAs through neighbor state switchovers.
The State field in OSPF neighbor information displayed using the display ospf peer command indicates the neighbor status of an OSPF device.
The OSPF neighbor state machine has the following states:
Down: This is the initial state of a neighbor session. This state occurs when a device does not receive any Hello packets from its neighbors within a dead interval. Only OSPF routers on an NBMA network send Hello packets to neighbors at each poll interval, including the neighbors in Down state.
Attempt: This state is only used on NBMA networks where neighbors are manually configured. When the neighbor relationship is in Attempt state, an OSPF router sends a Hello packet to its manually configured neighbors at each Hello interval, trying to establish a neighbor relationship.
Init: This state occurs after the router has received a Hello packet from its neighbor but has not established a two-way session. In this state, the neighbor does not receive any Hello packet from this router, and the neighbor list in the received Hello packet does not contain the router ID of the local router.
2-Way: This state occurs when a router and its neighbor receive Hello packets containing their own router IDs from each other and establish an OSPF neighbor relationship. If no adjacency needs to be established, the two neighbors remain in the 2-way state. If adjacencies need to be established, the neighbors enter the Exstart state. The DR and BDR are elected only when the neighbor state is the 2-way state or higher.
ExStart: This state occurs when the two neighbors start to negotiate the master/slave status and determine the sequence numbers of DD packets. Exstart is the first step in creating an adjacency.
Exchange: This state occurs when the two neighbors start to exchange DD packets. DD packets contain LSDB information.
Loading: This state occurs when the two neighbors are synchronizing their LSDBs. The two devices send LSR packets to request LSAs from each other to synchronize their LSDBs.
Full: This state occurs when the two neighbors establish an adjacency after their LSDB synchronization is completed.
Figure 6-14 shows an OSPF neighbor state switchover.
Table 6-2 lists the InputEvents occurring during a neighbor state switchover. The InputEvent is abbreviated to IE in Figure 6-13.
InputEvent |
Description |
|---|---|
IE1 |
Start: A router sends a Hello packet to its neighbors at each Hello interval, trying to establish a neighbor relationship. This event exists only on an NBMA network. |
IE2 |
HelloReceived: The router receives a Hello packet from a neighbor. |
IE3 |
2-WayReceived: The router receives a Hello packet containing its router ID from a neighbor and establishes a two-way session with this neighbor. Then the router determines its neighbor state accordingly:
|
IE4 |
NegotiationDone: The two neighbors have negotiated their master/slave roles and exchanged sequence numbers of DD packets. |
IE5 |
ExchangeDone: The two neighbors have exchanged their DD packets. Then the router determines its neighbor state accordingly:
|
IE6 |
LoadingDone: The link state request list is empty. |
OSPF Adjacency Establishment
OSPF neighbor relationship and adjacency
After an OSPF device starts, it sends a Hello packet through its OSPF interface. After another OSPF device on the same network receives this Hello packet, it checks parameters defined in this packet, including the interval for sending Hello packets, interface addresses of the DR and BDR, and IP address mask. If these parameters are consistent in the Hello packets of both ends, the two devices establish an OSPF neighbor relationship and become neighbors.
After establishing an OSPF neighbor relationship, the two neighbors need to exchange DD packets and LSAs to establish an adjacency.
On a broadcast link or NBMA link, LSAs do not need to be exchanged between DR others, and so DR others establish neighbor relationships. LSAs need to be exchanged between the DR and BDR, and between the DR, BDR, and DR others, and so they establish an adjacency with each other. In Figure 6-15, two DR others each have three neighbor relationships and two adjacencies.
There are only OSPF adjacencies on a P2P or P2MP link.
A neighbor relationship indicates that two neighbors reach the 2-way state, whereas an adjacency indicates that two neighbors reach the Exstart state or higher.
OSPF adjacency establishment process
The OSPF adjacency establishment process varies slightly depending on the network type.
Broadcast Network
On a broadcast network, the DR and BDR establish adjacencies with each router on the same network segment, but DR others establish only neighbor relationships. Figure 6-16 shows the process of establishing an OSPF adjacency.
Neighbor relationship establishment
RouterA uses the multicast address 224.0.0.5 to send a Hello packet through the OSPF interface connected to a broadcast network. The packet carries the DR field of 1.1.1.1 (ID of RouterA) and the Neighbors Seen field of 0. A neighbor RouterB has not been discovered, and RouterA regards itself as the DR.
After RouterB receives the packet, it returns a Hello packet to RouterA. The returned packet carries the DR field of 2.2.2.2 (ID of Router B) and the Neighbors Seen field of 1.1.1.1 (RouterA's router ID). RouterA has been discovered but its router ID is less than that of RouterB, and therefore RouterB regards itself as the DR. Then RouterB's state changes to Init.
After RouterA receives the packet, RouterA's state changes to 2-way. The following procedures are not performed for DR others on a broadcast network.
Master/Slave negotiation and DD packet exchange
- RouterA sends a DD packet to RouterB. The packet carries the following fields:
- Seq field: The value X indicates the sequence number of X.
- I field: The value 1 indicates that the packet is the first DD packet, which is used to negotiate the master/slave roles and does not carry LSA summaries.
- M field: The value 1 indicates that the packet is not the last DD packet.
- MS field: The value 1 indicates that RouterA declares itself the master.
To improve transmission efficiency, RouterA and RouterB determine which LSAs in each other's LSDB need to be updated. If one party determines that an LSA of the other party is already in its own LSDB, it does not send an LSR packet for updating the LSA to the other party. To achieve the preceding purpose, RouterA and RouterB first send DD packets, which carry summaries of LSAs in their own LSDBs. Each summary identifies an LSA. To ensure reliable packet transmission, the master/slave roles must be determined during through DD packet exchange. The party serving as the master uses the Seq field to define a sequence number. The master increases the sequence number by 1 each time it sends a new DD packet. When the other party serving as the slave sends a DD packet, it sets the Seq field of the packet to the sequence number carried in the last DD packet received from the master.
After RouterB receives the DD packet, RouterB's state changes to Exstart and RouterB returns a DD packet to RouterA. The returned packet does not carry LSA summaries. Because RouterB has a larger router ID than RouterA, RouterB declares itself the master and sets the Seq field to Y.
After RouterA receives the DD packet, it agrees that RouterB is the master and RouterA's state changes to Exchange. Then RouterA sends a DD packet to RouterB to transmit LSA summaries. The packet carries the Seq field of Y and the MS field of 0. The value 0 indicates that RouterA declares itself the slave.
After RouterB receives the packet, RouterB's state changes to Exchange and RouterB sends a new DD packet containing its own LSA summaries to RouterA. The value of the Seq field carried in the new DD packet is changed to Y+1. RouterA uses the same sequence number as RouterB to confirm that it has received DD packets from RouterB. RouterB uses the sequence number plus 1 to confirm that it has received DD packets from RouterA. When RouterB sends the last DD packet, it sets the M field of the packet to 0.
LSDB synchronization (LSA request, LSA transmission, and LSA response)
After RouterA receives the last DD packet, it finds that many LSAs in RouterB's LSDB do not exist in its own LSDB, so RouterA's state changes to Loading. After RouterB receives the last DD packet from RouterA, RouterB's state directly changes to Full, because RouterB's LSDB already contains all LSAs of RouterA.
RouterA sends an LSR packet for updating LSAs to RouterB. RouterB returns an LSU packet to RouterA. After RouterA receives the packet, it sends an LSAck packet for acknowledgement.
The preceding procedures continue until the LSAs in RouterA's LSDB are the same as those in RouterB's LSDB. RouterA's state then changes to Full. After RouterA and RouterB exchange DD packets and update all LSAs, they establish an adjacency.
NBMA Network
On an NBMA network, all routers establish adjacencies only with the DR and BDR. Figure 6-17 shows the process of establishing an OSPF adjacency.
Neighbor relationship establishment
After RouterB sends a Hello packet to a Down interface of RouterA, RouterB's state changes to Attempt. The packet carries the DR field of 2.2.2.2 (ID of RouterB) and the Neighbors Seen field of 0. A neighbor RouterA has not been discovered, and RouterB regards itself as the DR.
After RouterA receives the packet, RouterA's state changes to Init and RouterA returns a Hello packet. The returned packet carries the DR and Neighbors Seen fields of 2.2.2.2. RouterB has been discovered but its router ID is larger than that of RouterA, and therefore RouterA agrees that RouterB is the DR. The following procedures are not performed for DR others on an NBMA network.
The procedures for negotiating master/slave roles and exchanging DD packets on an NBMA network are the same as those on a broadcast network.
The process of synchronizing LSDBs (LSA request, LSA transmission, and LSA response) on an NBMA network is the same as that on a broadcast network.
P2P Network and P2MP Network
The process for establishing an adjacency on a P2P/P2MP network is similar to that on a broadcast network except that no DR or BDR needs to be elected on a P2P/P2MP network. DD packets are transmitted in multicast mode on P2P networks and in unicast mode on P2MP networks.
OSPF Areas
When a large number of routers run OSPF, their LSDBs become very large and require a large amount of storage space. Large LSDBs also complicate SPF calculations and increase loads on the routers. Network expansion increases the possibility of network topology changes, resulting in route flapping and frequent OSPF packet transmission. When a large number of OSPF packets are transmitted on the network, bandwidth efficiency decreases. Moreover, each change in the network topology causes route recalculations on all routers on the network.
OSPF resolves this problem by partitioning an AS into different areas. An area is regarded as a logical group of routers and is identified by an area ID. A router, not a link, resides at the border of an area. Each OSPF interface must belong to an area, meaning that a link (or network segment) belongs to only one area.
Before learning about OSPF areas, master two concepts: router types and route types.
Router Types
Figure 6-18 shows common router types within OSPF.
Router Type |
Description |
|---|---|
Internal router |
All interfaces on an internal router belong to the same OSPF area. |
Area Border Router (ABR) |
An ABR belongs to two or more areas, one of which must be a backbone area. An ABR is used to connect backbone and non-backbone areas. It can be physically or logically connected to a backbone area. |
Backbone router |
One or more interfaces on a backbone router belong to a backbone area. Internal routers in Area 0 and all ABRs are backbone routers. |
Autonomous System Boundary Router (ASBR) |
An ASBR exchanges routing information with other ASs. An ASBR is not required to reside on the border of an AS. It may be an internal router or an ABR. An OSPF device that has imported external routing information becomes an ASBR. |
Route Types
Inter-area and intra-area routes in an AS describe the network structure of the AS. AS external routes describe routes to destinations outside the AS. OSPF classifies imported AS external routes into either Type 1 or Type 2 external routes.
Table 6-4 lists route types in descending order of priority.
Route Type |
Description |
|---|---|
Intra-area route |
Routes within an area. |
Inter-area route |
Routes between areas. |
Type 1 external route |
Type 1 external routes have high reliability. Cost of a Type 1 external route = Cost of the route from a router to an ASBR + Cost of the route from the ASBR to the destination |
Type 2 external route |
Type 2 external routes have low reliability. Therefore OSPF considers the cost of the route from an ASBR to the destination to be much greater than the cost of any internal route to the ASBR. Cost of a Type 2 external route = Cost of the route from an ASBR to the destination |
Area Types
OSPF areas include common areas, stub areas, and not-so-stubby areas (NSSAs).
Area Type |
Function |
Description |
|---|---|---|
Common area |
By default, OSPF areas are common areas. Common areas include:
|
|
Stub area |
A stub area is a non-backbone area with only one ABR and generally resides at the border of an AS. The ABR in a stub area does not transmit received AS external routes, which significantly decreases the number of entries in the routing table on the ABR and the amount of routing information to be transmitted. To ensure the reachability of AS external routes, the ABR generates a default route and advertises the route to non-ABRs in the stub area. A totally stub area allows only intra-area routes and ABR-advertised Type 3 LSAs carrying a default route to be advertised within the area. |
|
NSSA |
An NSSA is similar to a stub area. An NSSA does not advertise Type 5 LSAs. but can import AS external routes. ASBRs in an NSSA generate Type 7 LSAs to carry the information about the AS external routes. The Type 7 LSAs are advertised only within the NSSA. When the Type 7 LSAs reach an ABR in the NSSA, the ABR translates the Type 7 LSAs into Type 5 LSAs and floods them to the entire AS. A totally NSSA area allows only intra-area routes to be advertised within the area. |
|
After an OSPF network is partitioned into multiple areas, only LSAs within an area are used in SPF calculations of this area. In Figure 6-19, the link in Area 1 is always flapping, so SPF calculations are frequently performed in Area 1. This situation occurs only in Area 1 and will not affect other areas, improving network stability.
Stub area and totally stub area
In Figure 6-20, there are two Areas 0 and 2, and external routes are imported by the ASBR in Area 0. Typically, all routes on the network are advertised into OSPF to ensure network reachability. In this situation, network expansion will increase the number of devices and routing entries on each device and require a large amount of CPU and memory resources to maintain these entries. In some edge areas, device performance may be low, so maintaining a large number of routing entries brings heavy stress on device.
To optimize network performance, you often need to minimize the routing table size to reduce the number of flooded LSAs without compromising network reachability. If Area 2 is a common area, five types of LSAs, Type 1, Type 2, Type 3, Type 4, and Type 5 may exist in this area. Traffic from routers in Area 2 must first reach the ABR, regardless of which network outside Area 2 the traffic needs to reach. In this situation, non-ABR routers in Area 2 do not need to know detailed information about external network. To meet this requirement, Area 2 is designed as a stub area.
Stub areas are specific areas where ABRs do not flood received AS external routes. In stub areas, routers maintain fewer routing entries and less routing information.
Configuring a stub area is optional and not every area can be configured as such. A stub area is usually a non-backbone area with only one ABR, located at the AS border.
To ensure reachability of routes to destinations outside an AS, the ABR in a stub area generates a default route and advertises the route to non-ABRs in the same stub area.
When configuring a stub area, note that:
A backbone area cannot be configured as a stub area.
Prior to the configuration, configure stub area attributes on all routers in the area.
ASBRs cannot be part of a stub area, and therefore, AS external routes cannot be advertised within the stub area.
A virtual link cannot pass through a stub area.
Routers in Area 2 do not need to know inter-area specific routes and only one egress is required to transmit traffic of these routers outside Area 2. To solve this problem, a totally stub area is designed. In a totally stub area, AS external routes and inter-area routes cannot be advertised within this area, reducing the number of LSAs transmitted within this area.
NSSA and totally NSSA
In Figure 6-21, Area 2 is a stub area. An external network needs to access the OSPF network through Area 2. That is, AS external routes need to be imported and advertised within the entire AS. One method is to enable RouterA to import AS external routes into the AS. RouterA then becomes an ASBR, indicating that Area 2 is no longer a stub area. To address this issue, an NSSA is designed.
An NSSA differs from a stub area in that it allows importing and advertising AS external routes within the entire AS without transmitting routes learned from other areas in the AS.
To ensure the reachability of AS external routes, the ABR in an NSSA generates a default route and advertises the route to the other routers in this NSSA.
When configuring an NSSA, note that:
- A backbone area cannot be configured as an NSSA.
- Prior to the configuration, configure NSSA attributes on all routers in the area.
- A virtual link cannot pass through an NSSA.
Multiple ABRs may be deployed in an NSSA. To prevent routing loops caused by default routes, ABRs do to calculate the default routes advertised by each other.
All routers in an area must have the same area type configured. A router uses the N-bit carried in a Hello packet to identify the area type that it supports. If routers have different area types, they cannot establish OSPF neighbor relationships. Some vendors' devices do not comply with this requirement, and the N-bit is also set in Database Description (DD) packets. You can manually set the N-bit on switches to interwork with the vendors' devices.
Similar to a totally stub area, OSPF defines the totally NSSA to further reduce the number of LSAs transmitted within an NSSA.
Inter-Area Loop and Loop Prevention
The shortest path first (SPF) algorithm runs within an OSPF area, which prevents routing loops within this area. The distance-vector algorithm is used for inter-area route transmission, which may easily cause routing loops.
To prevent inter-area loops, OSPF prohibits routing information from being advertised between two non-backbone areas and allows advertising routing information within a single area or between the backbone and non-backbone areas. Therefore, each ABR must be connected to the backbone area.
If OSPF allows advertising routing information between non-backbone areas, an inter-area loop may occur, as shown in Figure 6-22. The route from the backbone area to the external network is transmitted from Area 0 to Area 1. If transmitting routing information between non-backbone areas is allowed, this route is transmitted back to Area 0, forming an inter-area routing loop. To prevent this loop, OSPF prohibits routing information from being exchanged between Area 1 and Area 3, and between Area 2 and Area 3 and allows exchanging routing information only between the backbone and non-backbone areas.
OSPF Default Route
Default routes have all 0s as the destination address and mask. A device uses a default route to forward packets when no matching route is discovered. Hierarchical management of OSPF routes prioritizes the default route carried in Type 3 LSAs over the default route carried in Type 5 or Type 7 LSAs.
OSPF default routes are used when:
An ABR advertises default Type 3 LSAs instructing routers within an area to forward packets between areas.
An ASBR advertises default Type 5 LSAs or default Type 7 LSAs instructing routers in an AS to forward packets to other ASs.
- An OSPF router in an area can advertise LSAs carrying a default route only when the router has an interface connected to a device outside the area.
- If an OSPF router has advertised LSAs carrying a default route, the router no longer learns the same type of LSA advertised by other routers, which carry a default route. That is, the router uses only the LSAs advertised by itself to calculate routes. The LSAs advertised by other routers are still recorded in the LSDB.
- If a router must use a route to advertise LSAs carrying an external default route, the route cannot be a route learned by the local process. This is because external default routes guide packet forwarding outside an AS, whereas routes within an AS have the next hops pointing to the devices within the AS.
Table 6-6 lists default route advertisement principles in different areas.
Area Type |
Function |
|---|---|
Common area |
By default, devices in a common OSPF area do not generate default routes. When a default route on the network is generated by another non-OSPF routing process, the device that generates the default route must advertise it within the entire OSPF AS. You can configure an ASBR to generate a default route. After configuration, the ASBR generates a Type 5 LSA carrying the default route and then advertises the LSA within the entire OSPF AS. |
Stub area |
A stub area does not allow AS external routes (carried in Type 5 LSAs) to be transmitted within the area. All routers within a stub area must learn AS external routes from the ABR. The ABR automatically generates a default Summary LSA (Type 3 LSA) and then advertises it within the entire stub area. This makes all routes to destinations outside an AS learnable from the ABR. |
Totally stub area |
A totally stub area does not allow AS external routes (carried in Type 5 LSAs) or inter-area routes (carried in Type 3 LSAs) to be transmitted within the area. All routers within the totally stub area must learn AS external routes and other areas' routes from the ABR. The ABR automatically generates a default Summary LSA (Type 3 LSA) and advertises it within the entire totally stub area. This makes all routes to destinations outside an AS and to destinations in other areas learnable from the ABR. |
NSSA |
An NSSA allows its ASBRs to import a small number of AS external routes. The ASBRs do not advertise Type 5 LSAs received from other areas within the NSSA. AS external routes can be learned only from ASBRs in the NSSA. Devices in an NSSA do not automatically generate default routes. Use either of the following methods
to generate default routes:
The difference between the two methods is:
Default routes are flooded only within the local NSSA and are not flooded within the entire OSPF AS. If routers in the local NSSA cannot discover routes to the outside of the AS, the routers can forward packets outside of the AS through an ASBR. However, packets of other OSPF areas cannot be sent outside the AS through this ASBR. Default Type 7 LSAs are neither translated into default Type 5 LSAs nor flooded within the entire OSPF AS. |
Totally NSSA |
A totally NSSA does not allow AS external routes (carried in Type 5 LSAs) or inter-area routes (carried in Type 3 LSAs) to be transmitted within the area. All routers within the totally NSSA must learn AS external routes from the ABR. The ABR automatically generates a Type 3 LSA carrying a default route and advertises it within the entire totally NSSA. This allows all external routes received from other areas and inter-area routes to be advertised within the totally NSSA. |
OSPF LSA Types
An OSPF network is partitioned into multiple areas. These areas need to maintain their own LSDBs, and routers in these areas are classified into different types. LSAs encapsulated with route descriptions can also be classified based on the router types.
Figure 6-23 shows an OSPF network that is partitioned into three areas. A static route is configured on R4 and imported into an OSPF process.
Table 6-7 lists router IDs and interface IP addresses of R1, R2, R3, and R4.
Device |
Router ID |
Interface IP Address |
|---|---|---|
R1 |
10.1.1.1/32 |
GE0/0/1: 192.168.12.1/24 |
R2 |
10.2.2.2/32 |
GE0/0/2: 192.168.12.2/24 GE0/0/1: 192.168.23.1/24 |
R3 |
10.3.3.3/32 |
GE0/0/2: 192.168.23.2/24 GE0/0/1: 192.168.34.1/24 |
R4 |
10.4.4.4/32 |
GE0/0/2: 192.168.34.2/24 |
The following describes LSA types based on the network shown in Figure 6-23.
Router-LSA
A Router-LSA is a Type 1 LSA. It describes a router's link state and cost.
Every router on the OSPF network generates and advertises Router-LSAs within its area. In Figure 6-24, R2 advertises a Router-LSA within Area 0 and Area 1.
If GE0/0/1 on R2 floods a Router-LSA, the information contained in this LSA is shown in Figure 6-25.
An LSA includes an LSA header and LSA information field. In all types of LSAs, their LSA header contains the same fields except the Link State ID field meaning. You need to focus on the following fields in an LSA header:
Link-State Advertisement Type: indicates the LSA type.
Link State ID: indicates a link state ID. In a Router-LSA, this field indicates the router ID of the device that originates this LSA. Here, this field value is the router ID of R2.
Advertising Router: indicates the router that advertises this LSA.
A Router-LSA contains three information fields, which are used to advertise a router's link states and costs to other routers in the area where this LSA is flooded.
The LSA shown in Figure 6-25 indicates that: The link type (Type) is a transit network (Transit), the DR interface's IP address (ID) is 192.168.23.2, the interface IP address of the advertising router connected to the network is 192.168.23.1 (Data), and the cost (Metric) to this network is 1. Routers that receive this LSA generate the topology based on the link state information.
Four link types area available, and the ID and Data field values vary depending on the link type:
P2P (the field value is 1): The ID field indicates the router ID of a neighbor, and the Data field indicates the interface IP address of the advertising router connected to the network.
Transit (the field value is 2): The ID field indicates the IP address of the DR interface, and the Data field indicates the interface IP address of the advertising router connected to the network.
Stub (the field value is 3): The ID field indicates the IP network or subnet address, and the Data field indicates the network IP address or subnet mask.
Virtual Link (the field value is 4): The ID field indicates the router ID of a neighbor, and the Data field indicates the MIB-II ifIndex of the advertising router's interface.
Network-LSA
A Network-LSA is a Type 2 LSA. It describes the link state of all routers on the local network segment. A DR generates and advertises Network-LSAs within its area. In Figure 6-26, R3 sends R2 a Network-LSA that contains router IDs of all the routers that establish adjacencies with the DR.
Figure 6-27 shows the information contained in the Network-LSA.
In a Network-LSA, the Link State ID field indicates the IP address of a DR interface.
Flooding Router-LSAs and Network-LSAs within an area enables each router in this area to complete LSDB synchronization, which implements intra-area communication.
Network-summary-LSA
A Network-summary-LSA is a Type 3 LSA. It describes inter-area routing information. An ABR generates and advertises Network-summary-LSAs within its area to notify destination addresses of routes from this area to other areas. Actually, an ABR collects Type 1 and Type 2 LSAs within its area, summarizes related routes, and then advertises these routes. In Figure 6-28, R2 functions as an ABR to advertise routing information in Area 0 and Area 1 to Area 1 and Area 0 respectively.
Figure 6-29, shows a Network-summary-LSA advertised by R2 on GE0/0/1.
In a Network-summary-LSA, the Link State ID field indicates the IP address of the network described by this LSA. Information in this LSA shows that this LSA is advertised by R2 (10.2.2.2) and can reach the network with the IP address 192.168.12.0 and subnet mask 255.255.255.0 at the metric of 1. R2 advertises the network address in Area 1 within Area 0 so that routers in Area 0 know how to reach this network, implementing inter-area communication.
If an ABR has multiple routes within its area to reach a destination, it originates a single Network-summary-LSA to the backbone area. The metric of this LSA is the lowest among the costs of the multiple routes.
Network-summary-LSAs will not be advertised within totally stub areas or totally NSSAs.
ASBR-Summary-LSA
An ASBR-summary-LSA is a Type 4 LSA. It describes routes to an ASBR. An ABR generates and advertises ASBR-summary-LSAs to the areas except the area to which the ASBR is located. In Figure 6-30, R3 functions as an ABR to advertise an ASBR-summary-LSA to Area 0.
Figure 6-31 shows information contained in an ASBR-summary-LSA. The Link State ID field indicates the router ID (10.4.4.4) of the ASBR that this LSA describes, namely, R4. The router that advertises this LSA is R3 (10.3.3.3), and the metric of the route from R3 to R4 is 1.
AS-external-LSA
An AS-external-LSA is a Type 5 LSA. It describes routes to a destination outside an AS. An ASBR generates and advertises AS-external-LSAs to all areas except stub areas and NSSAs. In Figure 6-32, R4 functions as an ASBR to advertise a route to an external destination network outside the AS.
Figure 6-33 shows the information contained in an AS-external-LSA. The Link State ID field indicates the destination IP address of the external network. The Forwarding Address field indicates the address to which packets destined for this external network should be forwarded. Here, the forwarding address 0.0.0.0 indicates that packets will be forwarded to the ASBR that generates this LSA.
NSSA LSA
In addition to the preceding LSAs, there is a special type of LSA, NSSA LSA, which is also called Type 7 LSA. It describes routes to a destination outside the AS. An ASBR generates and advertises NSSA LSAs only in NSSAs. When an ABR in an NSSA receives NSSA LSAs, the ABR selectively translates them into Type 5 LSAs to advertise imported external routes to other areas on the OSPF network.
If Area 2 in Figure 6-23 is an NSSA, GE0/0/2 of R4 generates an NSSA LSA, as shown in Figure 6-34.
NSSA LASs and AS-external-LSAs have the same fields but are flooded into different areas. AS-external-LSAs are flooded within an AS, whereas NSSA LSAs are flooded within NSSAs.
NSSAs allow importing external routes, but NSSA LSAs describing external routes can only be flooded within NSSAs. To enable external routes to be imported into all areas except NSSAs, the ABR (R3) translates NSSA LSAs into AS-external-LSAs and floods the LSAs within the entire AS.
- The propagate bit (P-bit) in Type 7 LSAs is used to notify a router whether Type 7 LSAs need to be translated.
- By default, the translator is the ABR with the largest router ID in an NSSA.
- Only NSSA LSAs with the P-bit set to 1 and a non-zero forwarding address (FA) can be translated into AS-external-LSAs. An FA indicates a specific address that a packet will be forwarded to before arriving at the destination address.
- The P-bit is not set for NSSA LSAs generated by an ABR.
Opaque LSA
Opaque LSAs include Type 9 LSAs, Type 10 LSAs, and Type 11 LSAs. They provide a universal mechanism for OSPF extensions.
- Type 9 LSAs are advertised only on the network segment where the originating interface resides. Grace LSAs used to support graceful restart (GR) are Type 9 LSAs.
- Type 10 LSAs are advertised inside an OSPF area. LSAs used to support traffic engineering (TE) are Type 10 LSAs.
- Type 11 LSAs are advertised within an AS. At present, there are no applications for Type 11 LSAs.
OSPF Fast Convergence
OSPF fast convergence speeds up the convergence of routes. It includes the following components:
Incremental SPF (I-SPF): recalculates only the routes of the changed nodes rather than all the nodes when the network topology changes, which speeds up route calculation.
Partial Route Calculation (PRC): calculates only the changed routes when the routes on the network change.
An OSPF intelligent timer: can dynamically adjust its value based on the user's configuration and the interval at which an event is triggered, such as the route calculation interval, which ensures rapid and stable network operation.
The OSPF intelligent timer uses the exponential backoff technology so that the value of the timer can reach the millisecond level.
I-SPF
In ISO 10589, the Dijkstra algorithm was adopted to calculate routes. When a node changes on the network, this algorithm is used to recalculate all routes. The calculation takes a long time and consumes too many CPU resources, which affects the convergence speed.
I-SPF improves the Dijkstra algorithm. Except for the first time, only changed nodes instead of all nodes are involved in calculation. The SPT generated at last is the same as that generated by the previous algorithm. I-SPF decreases CPU usage and speeds up network convergence.
PRC
Similar to I-SPF, PRC calculates only the changed routes. However, PRC does not calculate the shortest path. It updates routes based on the SPT calculated by I-SPF.
- If the SPT changes, PRC processes the routing information of all leaves on a changed node.
- If the SPT remains unchanged, PRC does not process the routing information on any node.
- If a leaf changes, RPC processes the routing information on the leaf only.
- If a leaf remains unchanged, PRC does not process the routing information on any leaf.
For example, if OSPF is enabled on an interface of a node, the SPT calculated by I-SPF remains unchanged. PRC updates only the routes of this interface, consuming less CPU resources.
PRC improves the SPF algorithm. Working with I-SPF, RPC further improves network convergence performance.
On live networks, only I-SPF and PRC are used to calculate OSPF routes.
OSPF Intelligent Timer
On an unstable network, routes are calculated frequently, which consumes a great number of CPU resources. In addition, LSPs that describe the unstable topology are generated and transmitted on the unstable network. Frequently processing such LSAs affects the rapid and stable operation of the entire network.
To speed up route convergence on the entire network, the OSPF intelligent timer controls route calculation, LSA generation, and LSA receiving.
The OSPF intelligent timer works as follows:
On a network where routes are calculated repeatedly, the OSPF intelligent timer dynamically adjusts the route calculation based on user's configuration and the exponential backoff technology. The number of route calculation times and the CPU resource consumption are decreased. Routes are calculated after the network topology stabilizes.
On an unstable network, if a router generates or receives LSAs due to frequent topology changes, the OSPF intelligent timer can dynamically adjust the interval. No LSAs are generated or processed within an interval, which prevents invalid LSAs from being generated and advertised on the entire network.
The OSPF intelligent timer is started by default and uses the default value.
OSPF Virtual Link
A virtual link is a logical channel set up between two ABRs through a non-backbone area.
As required in RFC 2328, all non-backbone areas must be connected to the backbone area to ensure that all areas are reachable. Some non-backbone areas may not be connected to the backbone area. You can configure an OSPF virtual link to resolve this issue.
In Figure 6-35, Area 2 is not connected to Area 0. Therefore, RouterA cannot function as an ABR to generate routing information of Network1 into Area 2, and RouterB does not have routes to Network1. A virtual link can be deployed to resolve this issue.
In Figure 6-36, two ABRs use a virtual link to directly transmit OSPF packets. The OSPF device between the two ABRs only forwards packets. Because the destination of OSPF packets is not the OSPF device, the OSPF device transparently transmits the OSPF packets as common IP packets.
A virtual link functions as a point-to-point connection between two ABRs. The interfaces on both ends of the virtual link can be configured with parameters such as the Hello interval in the same way these parameters are configured on physical interfaces. The transmit area refers to the area that provides an internal route of a non-backbone area for both ends of the virtual link. A virtual link must be configured at both ends of the link, or it will not take effect.
However, a virtual link increases network complexity and complicates fault location. It is not recommended to use virtual links during network planning. Virtual links are only a temporary measure to fix unavoidable network topology problems. When virtual links are designed, consider whether to re-plan the network.
OSPF Route Summarization and Filtering
OSPF Route Summarization
Route summarization allows routes with the same prefix to be summarized into one route. Only the summarized route is advertised to other areas. This reduces both the routing table size and routing information transmitted between areas, thereby improving device performance.
Route summarization can be carried out by either an ABR or ASBR following these conditions:
ABR
An ABR generates Network-summary (Type 3) LSAs by network segment while advertising routing information to other areas. If the network segments are contiguous, the ABR can summarize them into a single segment. This allows the ABR to send one summarized LSA for the specified network segments.
ASBR
An ASBR can summarize imported AS-external (Type 5) LSAs within a summarized address range. After an NSSA is configured, the ASBR must summarize imported NSSA (Type 7) LSAs with the summarized address range.
Devices that are both ABR and ASBR summarize Type 5 LSAs translated from Type 7 LSAs.
OSPF Route Filtering
OSPF supports route filtering using routing policies. By default, OSPF does not filter routes. These policies include route-policy, access-list, and prefix-list.
OSPF route filtering can be used to:
Import routes.
OSPF can import routes learned by other routing protocols. You can configure routing policies to filter imported routes, allowing OSPF to import only routes that match specific conditions.
Advertise imported routes.
OSPF advertises imported routes to its neighbors.
You can configure filtering rules to filter routes to be advertised. Filtering rules can be configured only on ASBRs.
Learn routes.
Filtering rules can be configured to allow OSPF to filter received intra-area, inter-area, and AS external routes.
After receiving routes, an OSPF device adds only the routes that match filtering rules to the local routing table. However, the device can advertise all routes from the OSPF routing table.
Learn inter-area LSAs.
You can configure an ABR to filter incoming Summary LSAs. This configuration takes effect only on ABRs because only ABRs can advertise Summary LSAs.
The differences between inter-area LSA learning and route learning: Inter-area LSA learning filters incoming LSAs. However, Route learning filters the routes that are calculated based on LSAs, but does not filter LSAs. All incoming LSAs can be learned in route learning.
Advertise inter-area LSAs.
You can configure an ABR to filter outgoing Summary LSAs. This configuration takes effect only on ABRs.
OSPF Multi-Process
OSPF supports multi-process. This allows multiple OSPF processes to run independently on the same router. Route exchange between different OSPF processes is similar to route exchanges between different routing protocols.
Each router interface belongs to a single OSPF process.
OSPF multi-process typically runs between provider edges (PEs) and customer edges (CEs) in a VPN, whereas OSPF is used as an IGP on the backbone of a VPN.
OSPF RFC 1583 Compatibility
RFC 1583 is an early version of OSPFv2.
During OSPF external route calculations, routing loops may occur because RFC 2328 and RFC 1583 define different route selection rules. To prevent routing loops, both communication ends must use the same route selection rules.
- When RFC 1583 compatibility is enabled, OSPF uses route selection rules defined in RFC 1583.
- When RFC 1583 compatibility is disabled, OSPF uses route selection rules defined in RFC 2328.
- The router selects a route to the ASBR that originates the LSA or to the forwarding address (FA) described in the LSA.
- The router selects external routes to the same destination.
OSPF by default uses route selection rules defined in RFC 1583.