No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

S600-E V200R013C00 Configuration Guide - IP Unicast Routing

This document describes the configurations of IP Unicast Routing, including IP Routing, Static Route, RIP, RIPng, OSPF, OSPFv3, Routing Policy, IP Routing Table Management, and PBR.
Rate and give feedback:
Huawei uses machine translation combined with human proofreading to translate this document to different languages in order to help you better understand the content of this document. Note: Even the most advanced machine translation cannot match the quality of professional translators. Huawei shall not bear any responsibility for translation accuracy and it is recommended that you refer to the English document (a link for which has been provided).
OSPF Fundamentals

OSPF Fundamentals

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 5-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 and 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.

Figure 5-1  Obtaining the whole network topology through an LSDB

A router calculates shortest paths to destinations using a shortest path first (SPF) algorithm instead of obtaining routing information through route advertisements. In Figure 5-2, based on the weighted and 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 and frees routers from selecting routes based on route advertisements.

Figure 5-2  Calculating shortest paths to destinations using an SPF algorithm

An LSDB ensures that a router can learn about the whole network topology, and an SPF algorithm ensures that a router can quickly calculate shortest paths to destinations.

OSPF Mechanism

The OSPF mechanism includes the following steps:

  1. Exchanging Hello packets to establish OSPF neighbor relationships

    In Figure 5-3, after OSPF is run on the four routers, these routers send Hello packets on all OSPF-enabled interfaces. If two routers share a data link and successfully negotiate certain parameters specified in their Hello packets, they establish an OSPF neighbor relationship.

    Figure 5-3  Exchanging Hello packets to establish OSPF neighbor relationships

  2. Flooding LSAs to advertise link state information

    Routers that have established an OSPF adjacency can exchange LSAs, as shown in Figure 5-4. LSAs describe information about a router, including all links, interfaces, neighbors, and link state of the router. Routers exchange the link information to learn about the whole network topology. Because of the link diversity, OSPF defines multiple LSA types. For details, see OSPF LSA Types.

    Figure 5-4  Flooding LSAs to advertise link state information

  3. Forming an LSDB to create a weighted and directed graph

    A router floods LSAs and records received LSAs in its LSDB. Subsequently, all routers have the same LSDB, as shown in Figure 5-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.

    Figure 5-5  Forming an LSDB to create a weighted and directed graph

  4. Using an SPF algorithm to calculate and generate routes

    In Figure 5-6, after LSDB synchronization is complete, each router uses an SPF algorithm to calculate a loop-free topology with itself as the root and 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.

    Figure 5-6  Using an SPF algorithm to calculate and generate routes

  5. 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. These paths are installed as routing entries to guide data forwarding. The routers then update their routing tables in real time, as shown in Figure 5-7. Meanwhile, neighbors exchange Hello packets to maintain their neighbor relationships or adjacencies and periodically retransmit LSAs.

    Figure 5-7  Maintaining and updating routing tables

OSPF Packet Types

OSPF provides five types of packets:

  • Hello packet

    Hello packets are sent periodically by OSPF-enabled interfaces to establish and maintain OSPF neighbor relationships. These packets contain certain 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. In this phase, 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 increments 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 it received from a neighbor. If an LSA fails to be acknowledged, the router directly 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

OSPF classifies networks into two four types, depending on the link layer protocols:

  • Broadcast

    OSPF defaults networks using Ethernet or Fiber Distributed Data Interface (FDDI) at the link layer to broadcast networks.

    On broadcast networks:

    • Hello packets, LSU packets, and LSAck packets are sent in multicast mode. The address 224.0.0.5 is the IP multicast address reserved for OSPF DR others. The address 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)

    OSPF defaults networks using frame relay (FR) or X.25 at the link layer to NBMA networks.

    On NBMA networks, protocol packets such as Hello packets, DD packets, LSR packets, LSU packets, and LSAck packets are all sent in unicast mode.

  • Point-to-Multipoint (P2MP)

    OSPF does not default a network to a P2MP network regardless of the link layer protocol used by the network. A P2MP network must be changed from another network type. It is a typical practice to change partial-meshed NBMA networks to P2MP networks.

    On P2MP networks:

    • 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)

    OSPF defaults networks using Point-to-Point Protocol (PPP), High-Level Data Link Control (HDLC), or Link Access Procedure Balanced (LAPB) at the link layer to P2P networks.

    On P2P networks, protocol packets such as Hello packets, DD packets, LSR packets, LSU packets, and LSAck packets are all sent in multicast mode using the multicast address 224.0.0.5.

DR/BDR Election

Router ID

A router ID is a 32-bit integer used to uniquely identify an OSPF router in an AS. Each OSPF router has a router ID, which is in the same format as an IP address. To ensure OSPF stability, the IP address of a loopback interface on a router is recommended 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:

  1. The router preferentially selects the largest IP address among loopback interface addresses as the router ID.

  2. If no loopback interface is configured, the router selects the largest IP address among interface addresses as the router ID.

A router can obtain a new router ID only after a router ID is reconfigured for it or an OSPF router ID is reconfigured and the OSPF process restarts.

Reason for DR/BDR Election

On broadcast and NBMA networks, any two routers need to exchange routing information. As shown in Figure 5-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 consumes 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 if the DR fails, a BDR is also elected during DR election. The routers, excluding the 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.

Figure 5-8  DR/BDR election

DR/BDR Election Principles

To ensure stable DR/BDR election on broadcast and NBMA networks, OSPF defines three election principles: election, non-preemption, and inheritance.

Election Principle

The DR and BDR are not designated manually, but are elected by all routers on the local network segment. In Figure 5-9, DR priorities of router interfaces determine whether the interfaces are qualified for DR/BDR election. Routers with DR priorities greater than 0 on the local network segment can be considered as candidates. The ballots in this election are performed using 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 routers have the same DR priority, the router with the greater router ID is elected as the DR. The router whose DR priority is 0 cannot be elected as the DR or BDR.

Figure 5-9  Election principle

Non-preemption Principle

A router newly added to a network segment does not initiate a new election. Instead, it checks whether a DR exists on the network segment. In Figure 5-10, a DR exists on the network segment. Even if the DR priority of the newly added router is higher than that of the existing DR, the newly added router does not declare itself the DR, and acknowledges the existing DR. Routers on a network segment establish adjacencies only 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, consuming bandwidth resources. The non-preemption principle improves network stability and conserves bandwidth resources. On a broadcast or NBMA network, the two routers that are qualified for DR election and start first become the DR and BDR respectively.

Figure 5-10  Non-preemption principle

Inheritance Principle

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 5-11. This principle prevents frequent DR elections and enables the BDR to become the new DR when the DR fails, ensuring the DR stability. Because LSDBs of the DR and BDR are fully synchronized, the BDR can immediately become the new DR when the DR fails, providing the DR functions. The time consumed from role change to service switching is short because adjacencies have been established. Meanwhile, a new BDR will be elected after the original BDR becomes the DR. The new BDR election process consumes a relatively long time, but route calculation is not affected.

Figure 5-11  Inheritance principle

DR/BDR Election Process

The DR/BDR election process on a broadcast or NBMA network is as follows:

  1. After an interface goes Up, it sends a Hello packet and enters the Waiting state. In 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.

  2. Before the wait timer is triggered, sent Hello packets do not contain DR or BDR information. In 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.

  3. 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 its router ID or DR priority.

  4. If the DR fails and goes Down, the BDR takes over the role of the DR. The other routers with DR priorities greater than 0 then compete to become the new BDR.

  5. DR election rules are used to elect a DR only when routers with different router IDs or DR priorities are started at the same time. The election rules state that the device with the highest DR priority is elected as the DR and the device with the second highest DR priority as the BDR. A router with a DR priority of 0 can only be a DR other. If routers have the same DR priority, the router with the largest router ID is elected as the DR, the router with the second largest router ID becomes the BDR, and other routers are DR others.

Verifying the DR/BDR Election Process

In Figure 5-12, 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.

Figure 5-12  DR/BDR election networking

DR and BDR Are Properly Elected on the Network

Assume that interfaces on R1 to R4 have been configured. Only OSPF configurations are provided here.

  • R1 configuration

    #
    ospf 1 Router ID 10.1.1.1 
     area 0.0.0.0 
      network 192.168.1.0 0.0.0.255 
    #
  • R2 configuration

    #
    ospf 1 Router ID 10.2.2.2
     area 0.0.0.0 
      network 192.168.1.0 0.0.0.255 
    #
  • R3 configuration

    #
    ospf 1 Router ID 10.3.3.3 
     area 0.0.0.0 
      network 192.168.1.0 0.0.0.255 
    #
  • R4 configuration

    #
    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. R1 and R2 are elected as the DR and BDR respectively because of their startup sequence. In this example, R1, R2, R3, and R4 are started consecutively. 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 output shows that the neighbor relationships between R1 and the other three routers and those between R2 and the other three routers are in Full state, and the neighbor relationship between R3 and R4 is in 2-Way state. The states indicate that the DR and BDR establish adjacencies with other routers, and DR others only establish neighbor relationships with each other. 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. The BDR field is displayed as 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 output shows that R2, R3, and R4 each establish an adjacency with R1, 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 establish adjacencies only with the DR.

No DR or BDR Can Be Elected on the Network

On the basis of the preceding configuration, if the ospf dr-priority command is executed 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 are displayed as 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 output shows that all neighbor relationships are in 2-Way state, 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, all neighbor relationships among these routers are in 2-Way state.

OSPF State Machine

OSPF Interface State Machine

An OSPF device obtains link information from an interface and then establishes adjacencies 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 function 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 or transmit traffic.

  • Loopback: An OSPF interface that connects a device to a network is in Loopback state. A loopback interface cannot transmit data but its IP address can be advertised using Router-LSAs. Therefore, other devices can learn about paths to this IP address during a connectivity test.

  • 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 NBMA and broadcast networks.

  • P-2-P: An OSPF interface is connected to a P2P 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 P2MP networks.

  • DROther: The device is not elected as the DR or BDR. 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 if 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.

OSPF interfaces alternate among the preceding states based on the InputEvents (IEs), forming an efficient interface state machine, as shown in Figure 5-13.

Figure 5-13  OSPF interface state machine

Table 5-1 lists the IEs triggering interface state switchovers.

Table 5-1  InputEvents triggering OSPF interface state switchovers

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 with an OSPF interface has detected whether there is a BDR on the network. This event occurs in either of the following situations:

  • The OSPF interface receives a Hello packet from a neighbor, and the neighbor declares itself the BDR.

  • The OSPF interface receives a Hello packet from a neighbor, and the neighbor declares itself the DR but no BDR is specified.

Both 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: An interface-related neighbor relationship change event occurs, indicating that the DR and BDR need to be elected again. The following neighbor relationship changes may result in DR/BDR re-election:

  • The device implements bidirectional communication with a neighbor.

  • Bidirectional communication between the device and a neighbor is interrupted.

  • The device detects that the neighbor declares itself the DR or BDR based on the Hello packet received by the neighbor.

  • The device detects that the neighbor declares itself not the DR or BDR based on the Hello packet sent by the neighbor.

  • The device detects that the DR priorities of all neighbors have changed based on the Hello packets sent by the neighbors.

IE8

UnLoopInd: The NMS or lower-layer protocols indicate that the interface is not in Loopback state any longer.

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 through neighbor state switchovers, and then exchange LSAs.

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, attempting to establish neighbor relationships.

  • Init: This state occurs after the router has received a Hello packet from its neighbor but has not established a two-way session. In Init 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 2-Way state. If an adjacency needs to be established, the neighbor enters the Exstart state. The DR and BDR are elected only when the neighbor state is 2-Way or higher.

  • ExStart: This state occurs when two neighbors start to negotiate their master/slave roles and determine the sequence numbers of DD packets. Entering the Exstart state is the first step in setting up an adjacency.

  • Exchange: This state occurs when two neighbors exchange DD packets. In this state, DD packets contain LSDB information.

  • Loading: This state occurs when 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 two neighbors complete their LSDB synchronization and establish an adjacency.

Figure 5-14 shows an OSPF neighbor state machine.

Figure 5-14  OSPF neighbor state machine

Table 5-2 lists the IEs triggering neighbor state switchovers.

Table 5-2  InputEvents triggering OSPF neighbor state switchovers

InputEvent

Description

IE1

Start: A router sends a Hello packet to its neighbors at each Hello interval, attempting to establish neighbor relationships. This event exists only on NBMA networks.

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 implements two-way communication with this neighbor. The router then determines its neighbor state:

  • IE3(Y): If the router needs to establish an adjacency with the neighbor, it changes its neighbor state to Exstart.

  • IE3(N): If the router does not need to establish an adjacency with the neighbor, it changes its neighbor state to 2-Way.

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. One of the two routers then determines its neighbor state:

  • IE5(Y): If the link state request list is empty, the router changes its neighbor state to Full, indicating that all link state data has been exchanged and an adjacency has been established.

  • IE5(N): If the link state request list is not empty, the router changes its neighbor state to Loading and begins or continues sending LSR packets to its neighbor, requesting link state data that the local router does not have.

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 between the two devices, they 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 therefore DR others establish only neighbor relationships with each other. LSAs need to be exchanged between the DR and BDR, between the DR and a DR other, and between the BDR and a DR other. Therefore, they establish adjacencies with each other. In Figure 5-15, two DR others each have three neighbor relationships and two adjacencies.

Figure 5-15  OSPF neighbor relationship and adjacency

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 process of OSPF adjacency establishment varies slightly depending on the network type.

Broadcast Network

On a broadcast network, the DR and BDR establish an adjacency with each router on the same network segment, but DR others establish only neighbor relationships with each other. Figure 5-16 shows the process of establishing an OSPF adjacency.

Figure 5-16  Process of establishing an OSPF adjacency on a broadcast network

  1. Neighbor relationship establishment

    1. 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, indicating that a neighbor RouterB has not been discovered and RouterA regards itself as the DR.

    2. 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 neighbor state changes to Init.

    3. After RouterA receives the response, RouterA's neighbor state changes to 2-Way. Then, RouterA and RouterB start to send their LSDB information to each other, which does not occur between DR others on a broadcast network.

  2. Master/Slave negotiation and DD packet exchange

    1. RouterA sends a DD packet to RouterB. The packet carries the following fields:
      • Seq: The value X indicates the sequence number of X.
      • I: 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: The value 1 indicates that the packet is not the last DD packet.
      • MS: 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 before sending LSR packets. If one party detects 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 its own LSDB. 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 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.

    2. 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.

    3. 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 indicating that RouterA declares itself the slave.

    4. 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 acknowledge that it has received DD packets from RouterB. RouterB uses the sequence number from RouterA plus 1 to acknowledge that it has received DD packets from RouterA. When RouterB sends the last DD packet, it sets the M field in the packet to 0.

  3. LSDB synchronization (LSA request, LSA transmission, and LSA response)

    1. After RouterA receives the last DD packet, it finds that many LSAs in RouterB's LSDB do not exist in its own LSDB. Therefore, RouterA's neighbor state changes to Loading. After RouterB receives the last DD packet from RouterA, RouterB's neighbor state directly changes to Full because RouterB's LSDB already contains all LSAs of RouterA.

    2. RouterA sends an LSR packet for updating LSAs from RouterB to its own LSDB. RouterB sends an LSU to After RouterA. After receiving the packet from RouterB, RouterA sends an LSAck packet to RouterB for acknowledgement.

    The preceding procedure ends when the LSAs in RouterA's LSDB are the same as those in RouterB's LSDB. RouterA's neighbor state then changes to Full. After RouterA and RouterB exchange DD packets and update all LSAs, an adjacency is established between them.

NBMA Network

On an NBMA network, all routers establish adjacencies only with the DR and BDR. Figure 5-17 shows the process of establishing an OSPF adjacency.

Figure 5-17  Process of establishing an OSPF adjacency on an NBMA network

  1. Neighbor relationship establishment

    1. After RouterB sends a Hello packet to a Down interface of RouterA, RouterB's neighbor 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.

    2. 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 greater than that of RouterA, and therefore RouterA agrees that RouterB is the DR. Then, RouterA and RouterB start to exchange DD packets and LSDB information with each other, which does not occur between DR others on a broadcast network.

  2. The processes of negotiating master/slave roles and exchanging DD packets on an NBMA network are the same as those on a broadcast network.

  3. 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 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, leading to frequent route flapping and 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 on 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 understanding OSPF areas, you need to get to know two concepts: router type and route type.

Router Types

Figure 5-18 shows common router types involved in OSPF.

Figure 5-18  Router types

Table 5-3  Router types

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 imports external routing information becomes an ASBR.

Route Types

Inter-area and intra-area routes in an AS describe the internal network structure of the AS. AS external routes describe routes to destinations outside the AS. OSPF classifies imported AS external routes into Type 1 and Type 2.

Table 5-4 lists route types in descending order of priority.

Table 5-4  Route types

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 that 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).

Table 5-5  Area types

Area Type

Function

Description

Common area

By default, OSPF areas are common areas that include:

  • Standard area: transmits intra-area, inter-area, and external routes.
  • Backbone area: connects to all other OSPF areas and transmits inter-area routes. The backbone area is represented by area 0. Routes between non-backbone areas must be forwarded through the backbone area.
  • The backbone area must have all its devices connected.
  • All non-backbone areas must have themselves connected to the backbone area.

Stub area

A stub area is a non-backbone area containing only one ABR and generally resides on the border of an AS. The ABR in a stub area does not transmit received AS external routes, which significantly decreases the routing table size on the ABR and the amount of routing information 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.

  • A backbone area cannot be configured as a stub area.
  • An ASBR cannot exist in a stub area. Therefore, AS external routes cannot be advertised within a stub area.
  • A virtual link cannot pass through a stub 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 allows only intra-area routes to be advertised within the area.

  • An ABR in an NSSA advertises default routes in Type 7 LSAs within the NSSA.
  • All inter-area routes are advertised by ABRs.
  • A virtual link cannot pass through an NSSA.

After an OSPF network is partitioned into multiple areas, only LSAs within an area are used in SPF calculations of this area. For example, in Figure 5-19, the link in Area 1 is always flapping, and therefore SPF calculations are frequently performed in Area 1. However, frequent SPF calculations occur only in Area 1 without affecting other areas, improving network stability.

Figure 5-19  Area partitioning reducing the impact of link flapping

Stub area and totally stub area

In Figure 5-20, an AS is partitioned into Area 0 and Area 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, low-performance devices may be deployed, and therefore maintaining a large number of routing entries brings heavy load on these devices.

Figure 5-20  Stub area and totally stub area

To optimize network performance, you often need to minimize the routing table size to reduce the number of LSAs to be flooded 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 the traffic destination outside Area 2. Therefore, non-ABR routers in Area 2 do not need to know detailed information about external networks. To meet this requirement, Area 2 is designed as a stub area.

A stub area is a special area where the ABR does not flood received AS external routes. In a stub area, routers maintain fewer routing entries and transmit 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 containing only one ABR, located on 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 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 contained in 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 meet this requirement, a totally stub area is designed. In a totally stub area, AS external routes and inter-area routes cannot be advertised, reducing the number of LSAs transmitted within this area.

NSSA and totally NSSA

In Figure 5-21, Area 2 is a stub area. An external network needs to connect to the OSPF network through Area 2. That is, AS external routes need to be imported to and advertised within the entire AS. One method is to enable RouterA in Area 2 to import AS external routes into the AS. RouterA then becomes an ASBR, indicating that Area 2 is no longer a stub area. To meet this requirement, an NSSA is designed.

Figure 5-21  NSSA and totally NSSA

An NSSA differs from a stub area in that an NSSA allows importing AS external routes into and advertising them 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 specify 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 enable interworking with these vendors' devices.

Similar to a totally stub area, a totally NSSA is defined to further reduce the number of LSAs transmitted within an NSSA.

Inter-Area Loop and Loop Prevention

OSPF runs an SPF algorithm within an area, which prevents routing loops within the area. However, 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 directly 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 directly between non-backbone areas, an inter-area loop may occur, as shown in Figure 5-22. The route from the backbone area to the external network can be transmitted from Area 0 to Area 1. If transmitting routing information directly between non-backbone areas is allowed, this route can be transmitted back to Area 0, forming an inter-area routing loop. To prevent this loop, OSPF allows exchanging routing information only between the backbone and non-backbone areas. That is, OSPF prohibits routing information from being exchanged directly between Area 1 and Area 3 or directly between Area 2 and Area 3.

Figure 5-22  OSPF inter-area loop

OSPF Default Route

A default route has an all–0 destination address and an all-0 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 that carried in Type 5 or Type 7 LSAs.

An OSPF default route is used in the following scenarios:

  • An ABR advertises a default route in Type 3 LSAs for instructing routers within an area to forward packets between areas.

  • An ASBR advertises a default route in Type 5 LSAs or Type 7 LSAs for instructing routers in an AS to forward packets to other ASs.

Advertising an OSPF default route must follow these rules:
  • 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 LSAs carrying a default route advertised by other routers. 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 5-6 lists default route advertisement principles in different areas.

Table 5-6  OSPF areas and default route advertisement

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 use commands to 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 Summary LSA (Type 3 LSA) carrying a default route 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 inter-area routes from the ABR. The ABR automatically generates a Summary LSA (Type 3 LSA) carrying a default route 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. That is, 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:
  • Method 1: To advertise AS external routes through the ASBR in the NSSA and advertise other external routes through other areas, configure a Type 7 LSA carrying a default route on the ABR and advertise this LSA within the entire NSSA. In this manner, a small number of AS external routes can be learned from the ASBR in the NSSA, and other routes can be learned from the ABR in the NSSA.
  • Method 2: To advertise all external routes through the ASBR in the NSSA, configure a Type 7 LSA carrying a default route on the ASBR and advertise this LSA within the entire NSSA.

The difference between the two methods is:

  • In method 1, an ABR generates a Type 7 LSA carrying a default route regardless of whether the routing table contains a default route.
  • An ASBR generates a Type 7 LSA carrying a default route only when the routing table contains a default route.

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. Type 7 LSAs carrying default routes are not translated into Type 5 LSAs to make the default routes be 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 description can also be classified based on the router types.

Figure 5-23 shows an OSPF network that is partitioned into three areas. A static route is configured on R4 and imported into an OSPF process.

Figure 5-23  OSPF network partitioned into three areas

Table 5-7 lists router IDs and interface IP addresses of R1, R2, R3, and R4.

Table 5-7  Data plan

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 5-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 Router-LSAs and advertises them within its areas. In Figure 5-24, R2 advertises a Router-LSA within Area 0 and Area 1.

Figure 5-24  Router-LSA (Type 1)

Figure 5-25 shows the information contained in the Router-LSA flooded by GE0/0/1 on R2.

Figure 5-25  Information in a Router-LSA

An LSA includes the LSA header and LSA information fields. In all types of LSAs, their LSA header contains the same fields with the only difference of 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, the value of this field 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 5-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 states of all routers on the local network segment. A DR generates Network-LSAs and advertises them within its area. In Figure 5-26, R3 sends R2 a Network-LSA that contains router IDs of all the routers that establish adjacencies with the DR.

Figure 5-26  Network-LSA (Type 2)

Figure 5-27 shows the information contained in the Network-LSA.

Figure 5-27  Information in a 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 Network-summary-LSAs and advertises them within its area to notify destination addresses of routes from this area to other areas. Actually, an ABR generates Network-summary-LSAs by collecting Type 1 and Type 2 LSAs within its area and summarizing related routes. In Figure 5-28, R2 functions as an ABR to advertise routing information in Area 0 and Area 1 to Area 1 and Area 0 respectively.

Figure 5-28  Network-summary-LSA (Type 3)

Figure 5-29 shows the information contained in a Network-summary-LSA advertised by R2 on GE0/0/1.

Figure 5-29  Information in a Network-summary-LSA

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 the subnet mask 255.255.255.0 at the cost of 1. R2 advertises the network address of Area 1 to Area 0 so that routers in Area 0 know how to reach the network in Area 1, implementing inter-area communication.

If an ABR has multiple routes within its area to reach a destination, it originates only one Network-summary-LSA carrying the route with the lowest cost to the backbone area.

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 ASBR-summary-LSAs and advertises them to areas except the area to which the ASBR is located. In Figure 5-30, R3 functions as an ABR to advertise an ASBR-summary-LSA to Area 0.

Figure 5-30  ASBR-summary-LSA (Type 4)

Figure 5-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 cost of the route from R3 to R4 is 1.

Figure 5-31  Information in an ASBR-summary-LSA

AS-external-LSA

An AS-external-LSA is a Type 5 LSA. It describes routes to destinations outside an AS. An ASBR generates AS-external-LSAs and advertises them to all areas except stub areas and NSSAs. In Figure 5-32, R4 functions as an ASBR to advertise a route to an external destination network outside the AS.

Figure 5-32  AS-external-LSA (Type 5)

Figure 5-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.

Figure 5-33  Information in an AS-external-LSA

NSSA LSA

In addition to the preceding LSAs, there is a special type of LSA, namely, NSSA LSA. An NSSA LSA is a Type 7 LSA. It describes routes to destinations outside an AS. An ASBR generates NSSA LSAs and advertises them 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 5-23 is an NSSA, GE0/0/2 of R4 generates an NSSA LSA, as shown in Figure 5-34.

Figure 5-34  NSSA LSA

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 AS-external-LSAs within the entire AS. The following provides more information about the translation:

  • The propagate bit (P-bit) in Type 7 LSAs is used to notify a router of whether the Type 7 LSAs need to be translated.
  • By default, the translator is the ABR with the largest router ID in the 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 default routes in 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 within 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 of Type 11 LSAs.

Table 5-8 describes whether a type of LSA is supported in an area.

Table 5-8  Support status of LSAs in different types of areas

Area Type

Router-LSA (Type 1)

Network-LSA (Type 2)

Network-summary-LSA (Type 3)

ASBR-summary-LSA (Type 4)

AS-external-LSA (Type 5)

NSSA-LSA (Type 7)

Common area (including standard and backbone areas)

Supported Supported Supported Supported Supported Not supported

Stub area

Supported Supported Supported Not supported Not supported Not supported

Totally stub area

Supported Supported Not supported Not supported Not supported Not supported

NSSA

Supported Supported Supported Not supported Not supported Supported
Totally NSSA Supported Supported Not supported Not supported Not supported Supported

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.

  • OSPF intelligent timer: can dynamically adjust its value based on the user's configuration and the frequency of a triggering event, such as route calculation, which ensures rapid and stable network operation.

    The OSPF intelligent timer uses the exponential backoff technology so that the value of the timer is accurate to milliseconds.

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, which takes a long time and consumes too many CPU resources, affecting 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 using the Dijkstra algorithm. I-SPF consumes fewer CPU resources and speeds up network convergence.

PRC

Similar to I-SPF, PRC performs calculation only for the changed routes. The difference is that PRC does not calculate the shortest paths. It updates routes based on the SPTs calculated by I-SPF.

In route calculation, a leaf represents a route, and a node represents a router. Either an SPT change or a leaf change causes a routing information change. The SPT change is irrelevant to the leaf change. PRC processes routing information as follows:
  • 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 fewer CPU resources.

PRC improves the SPF algorithm. Working with I-SPF, RPC further improves network convergence performance.

NOTE:

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, LSAs that describe the unstable topology are generated and transmitted on the unstable network. Frequent processing of data such LSAs affects the rapid and stable operation of the entire network.

To speed up route convergence on the entire network, you can use the OSPF intelligent timer that can control route calculation, LSA generation, and LSA receipt.

The OSPF intelligent timer works in either of the following modes:

  • On a network where routes are calculated repeatedly, the OSPF intelligent timer dynamically adjusts the interval between two route calculations based on user's configuration and the exponential backoff technology. In this way, the number of route calculations can be reduced, and therefore fewer CPU resources are consumed. Routes will be calculated again after the network topology stabilizes.

  • On an unstable network, a router generates or receives numerous LSAs due to frequent topology changes. In this case, the OSPF intelligent timer can dynamically adjust the interval at which the LSAs are generated or processed. Within the interval, no LSAs are generated or processed. This prevents invalid LSAs from being generated and advertised on the entire network.

The OSPF intelligent timer is started by default and has a 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. However, it is not true in some scenarios due to certain restrictions. To resolve this issue, you can configure an OSPF virtual link.

In Figure 5-35, Area 2 is not connected to Area 0. Therefore, RouterA cannot function as an ABR to generate routing information of Network1 and advertise the information to Area 2, and RouterB does not have routes to Network1. A virtual link can be deployed to resolve this issue.

Figure 5-35  Non-backbone area not connected to the backbone area

In Figure 5-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.

Figure 5-36  OSPF virtual link implementation principles

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.

A virtual link increases the network complexity and complicates fault locating. You are not advised 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, you need to 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.

OSPF supports two modes of route summarization:

  • 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 all 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, including route-policy, access-list, and prefix-list. By default, OSPF does not filter routes.

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.

    An OSPF device advertises imported routes to its neighbors.

    You can configure filtering rules to filter the routes to be advertised, but the rules take effect 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.

    Difference between route filtering for inter-area LSA learning and that for route learning: The former directly filters incoming LSAs but the latter filters the routes calculated using LSAs to determine the routes to be added to the local routing table. In route filtering for route learning, all incoming LSAs are learned.

  • 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 exchanges between different OSPF processes are similar to route exchanges between different routing protocols.

Each router interface belongs to only one OSPF process.

OSPF multi-process typically applies to the scenario where OSPF runs between provider edges (PEs) and customer edges (CEs) in a VPN whereas OSPF is used as an IGP on the backbone of the VPN. On the PEs, the two OSPF processes do not affect each other.

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. The mechanism is as follows:

  • 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.
OSPF calculates external routes using Type 5 LSAs. If the router with RFC 1583 compatibility enabled receives a Type 5 LSA:
  • The router selects a route to the ASBR that originates the LSA or to the forwarding address (FA) described in the LSA.
  • The router selects external routes to the same destination.

By default, OSPF uses route selection rules defined in RFC 1583.

Translation
Download
Updated: 2019-04-08

Document ID: EDOC1100066165

Views: 26011

Downloads: 3

Average rating:
This Document Applies to these Products
Related Documents
Related Version
Share
Previous Next