Understanding Open Shortest Path First (OSPF)

Understanding Open Shortest Path First (OSPF)

OSPF Packet Details

OSPF has five types of packets used for various reasons. Table 8-1 documents the different OSPF packet types and describes their functionality.

All the OSPF packet types share a common 20-byte OSPF protocol header. Figure 8-1 shows the common OSPF protocol header format.

The list that follows describes the fields in the OSPF protocol header:

• Version Number— This field represents the current version number of OSPF. The latest version is 2. Version 1 is not compatible with Version 2.
• Type— This field indicates which of the five types of OSPF packets is appended at the end of this header.
• Packet Length— This field contains the length of the entire OSPF packet, including the OSPF header.
• Router ID— This field contains the 4-byte IP address. The router ID is used to uni-quely identify the router throughout the autonomous system. For a Cisco box, this field contains the highest IP address on the box. If loopbacks are configured, the highest loopback becomes the router ID.
  After the router ID is chosen, it will not change unless the router is restarted, the inter-face that is selected as a router ID is shut down, or the IP address has been removed or replaced on that interface.
• Area ID— This field designates the area number to which this packet belongs. This is also a 4-byte number. The value must be the same on both sides to form neighbor relationships. There are two ways to write this: Area 1 or Area 0.0.0.1. There is no difference between the two.
• Checksum— This field includes the checksum for the entire OSPF packet, excluding the authentication for data corruption.
• AuType— This field contains the type code for the authentication:
  • 0 means that there is a null authentication.
  • 1 means that the authentication type is plain text.
  • 2 means that the authentication type is MD5.
• Authentication— This 64-bit field contains the authentication key in case of plain-text authentication. In case of message digest, the 64-bit Authentication field is redefined into several other parameters. See Appendix D of RFC 2328 for more detail on the MD5 authentication scheme.

Hello Packets

Hello packets are the first type of packets in OSPF. Figure 8-2 illustrates the Hello packet format. Hello packets are used to form a neighbor relationship between two routers. In environments that include broadcast/nonbroadcast media, Hello packets are used to elect the designated (DR) and backup designated (BDR) routers. On broadcast media, the destination address of the Hello packets is 224.0.0.5. On nonbroadcast media, the destination address is unicast.

The list that follows describes the fields in the Hello packet:

• Network Mask— Represents the network mask of the interface on which OSPF is running. The network mask is checked only on broadcast media.
• Hello Interval— Represents the number of seconds between two Hello packets. This interval must be the same for the two routers that are trying to form an adjacency. The Hello interval is 10 seconds on broadcast and point-to-point media, and 30 seconds on all other media.
• Options— Represents the optional capabilities supported by the router. The Options field has the following format:
  
  • O bit is used for opaque LSAs, mentioned in RFC 2370
  • DC is used for demand circuit capabilities, mentioned in RFC 1793
  • EA is the external attribute
  • N/P is used for not-so-stubby area (NSSA) option, mentioned in RFC 1587
  • MC designates multicast OSPF
  • E, when set, means that external LSA are allowed in this area
  • T bit is used for ToS capability (normally set to 0)

The first bit in the Options field is reserved for future use. Cisco routers also do not use EA and MC bits.

• Rtr Pri— Used for a router’s priority. By default, this value is set to 1. This field plays an important role in electing the DR and the BDR. A higher priority increases the chances that the router will become the DR. A priority of 0 means that this router will not take part in DR election.
• Router Dead Interval— Represents the number, in seconds, before a neighbor is declared dead. By default, the dead interval is four times the Hello interval.
• Designated Router— Lists the IP address of the designated router. If there is no DR, this field has a value of 0.0.0.0. The DR is elected through the Hello protocol. The router with the highest priority becomes the DR. If the priorities are equal, the router with the highest router ID becomes the DR. The purpose of the DR is to reduce the amount of flooding on multiaccess media. The DR uses multicasting to reduce the amount of flooding. All routers flood their link-state database to the DR, and the DR then floods that information back to other routers on that segment. No DRs/BDRs exist on point-to-point or point-to-multipoint segments.
• Backup Designated Router— Identifies the BDR and lists the interface IP address of the BDR. If no BDR exists, this field has a value of 0.0.0.0. The BDR is also elected through the Hello protocol. The purpose of the BDR is to serve as the backup of the DR, for a smoother transition in case the DR dies. BDR remains passive during flooding.
• Neighbor— Contains the router ID of each neighbor from which a Hello is seen.

Database Description Packets

The second type of OSPF packet, the database description (DBD) packet, is used mostly during the database exchange. The first DBD packet is used to elect the master and slave relationship and to set the initial sequence number elected by the master. The router with the highest router ID becomes the master and initiates the database synchronization. The master sends the sequence number, and the slave acknowledges it. After the master and the slave are elected, the database synchronization starts; in this process, the headers of all the LSAs are exchanged with neighbors. Figure 8-3 illustrates the DBD packet format.

The list that follows describes the fields in the DBD packet:

• Interface MTU— This field contains the largest data size, in bytes, that can be send through the associated interface. This option has been added starting from RFC 2178. This field must be set to 0 when sending the packet over a virtual link.
• Options— Options for this field were discussed in the previous section on the Hello packet format.
• I Bit— When set to 1, this means that this is the first packet in DBD exchange.
• M Bit— When set to 1, this means that more packets will follow.
• MS Bit— Use this for master and slave. When this bit is set, it means that the router is a master in the DBD exchange process. If this bit is set to 0, it means that the router is the slave.
• DBD Sequence Number— This field contains a unique value set by the master. This sequence number is used during database exchange. Only a master can increment the sequence number.
• LSA Header— This field consists of a list of the link-state database headers.

Link-State Request Packets

The Type 3 OSPF packet, a link-state request packet, is sent if part of the database is missing or out-of-date. The link-state request packet is used to retrieve that precise piece of database information that is missing. Link-state packets are also used after the DBD exchange is finished to request the LSAs that have been seen during the DBD exchange. Figure 8-4 illustrates the link-state request packet format.

The list that follows describes the fields in the link-state request packet:

• LS Type— Identifies what type of LSA is being requested.
• Link-State ID— Represents the link-state ID of that specific LSA. Link-state ID is discussed later in this chapter.
• Advertising Router— Contains the router ID of the router that is originating this LSA.

Link-State Update Packets

OSPF packet Type 4, the link-state update packet, implements flooding. Several LSAs are included in a single packet. Link-state update packets are also sent in response to link-state request packets. Flooded LSAs are acknowledged in the LSA acknowledgment packet. If an LSA is not acknowledged, it is retransmitted every retransmit interval (5 seconds, by default). Figure 8-5 illustrates the link-state update packet format.

As Figure 8-5 shows, this packet contains the number of LSAs (for example, 10 or 20 LSAs), followed by the LSA itself.

Link-State Acknowledgment Packet

The last type of OSPF packet, the link-state acknowledgment packet, is used to acknow-ledge each LSA. This packet is sent in response to link-state update packets. Multiple LSAs can be acknowledged in a single link-state acknowledgment packet. This packet is respon-sible for the reliable delivery of link-state update packets. Figure 8-6 illustrates the link-state acknowledgment packet format.

Link-state acknowledgment packets are sent as multicasts. If the state of the router is DR or BDR, the acknowledgment is sent to the OSPF router multicast address of 224.0.0.5. If the state of the router is not DR or BDR, the acknowledgment is sent to the all DR router multicast address of 224.0.0.6.

OSPF LSA Details

Several types of LSAs exist. This section discusses the nine types of LSAs documented in Table 8-2.

[*] Type 6 is used for group membership in Multicast OSPF (MOSPF), which is not implemented by Cisco. Type 8 is unused, and Types 9–11 are used for Opaque LSA, which is not used for route calculation but is used for MPLS traffic engineering, which is beyond of the scope of this chapter. More information about Opaque LSA can be found in RFC 2370.

Each LSA has a 20-byte common LSA header, the format for which is illustrated in Figure 8-7.

The list that follows describes the fields in the LSA header:

• LS Age— Gives the time, in seconds, since the LSA originated. The maximum age of the LSA is 3600 seconds; the refresh time is 1800 seconds. If the LS age reaches 3600 seconds, the LSA must be removed from the database.
• Options— Discussed earlier in the section “Hello Packets.”
• LS Type— Represents the types of LSA, several of which are documented in Table 8-2.
• Link-State ID— Identifies the portion of the network that is being described by the LSA. This field changes according to the LS type.
• Advertising Router— Represents the router ID of the router originating the LSA.
• LS Sequence Number— Detects old or duplicate LSAs. Each successive instance is given a successive sequence number. The maximum sequence number is represented by 0x7FFFFFFF. The first sequence number is always 0x80000001. The sequence number 0x80000000 is reserved.
• LS Checksum— Performs checksum on the LSA, not including LS age. An LSA can be corrupted during flooding or while kept in the memory, so this checksum is necessary. This field cannot have a value of 0 because 0 means that the checksum has not been performed. The checksum is performed at the time of LSA generation or when the LSA is received. It is also performed every CheckAge interval, which, by default, is 10 minutes.
• Length— Includes the length of the LSA, including the 20-byte header.

Router LSA

Router LSAs are generated by each router for each area to which the router belongs. These packets describe the states of the router’s link to the area and are flooded only within a particular area. All the router’s links in an area must be described in a single LSA.

The router LSA floods throughout the particular area; however, the flooding of this LSA is limited within an area. The router LSA of a router cannot exist outside the area; otherwise, every single router in OSPF would have to carry huge amounts of detailed information. Those details remain within an area. The router indicates whether it’s an ABR, ASBR, or an endpoint of a virtual link.

Figure 8-8 shows the packet format for the router LSA.

The list that follows describes the fields within the router LSA packet:

• Bit V— This bit is used to determine whether it’s an endpoint of a virtual link.
• Bit E— This bit is used to determine whether this router is an Autonomous System Boundary Router (ASBR).
• Bit B— This bit is used to determine whether this router is an Area Border Router (ABR).
• Number of Links— This includes the number of router links. Note that the router LSA includes all the router links in a single LSA for an area.
• Link ID, Link Data, and Type— The Type field represents the four types of router links. The other two fields, Link ID and Link Data, represent the 4-byte IP address value, depending on the network type. One thing to note here is that there can be two types of point-to-point links, numbered and unnumbered. In case of numbered point-to-point links, the Link Data field contains the interface address that connects to the neighbor. In the case of unnumbered links, the Link Data field contains the MIBII Ifindex value, a unique value that is associated with every interface. It normally has values starting from 0, as in 0.0.0.17. Table 8-3 lists all possible values for the Link ID and Link Data fields.
• ToS and ToS Metric— These fields represents the type of service and are normally set to 0.

Metric— This field contains the OSPF cost of a specific link. The formula to calculate OSPF cost is 108/Link bandwidth. For example, the metric of a Fast Ethernet interface would be 1. Metric is determined directly from the interface bandwidth, which is configurable. This formula for metric calculation can be overridden by two methods. The first method uses the ip ospf cost cost command under the interface. The second method uses the auto-cost reference-bandwidth reference-bandwidth command under router ospf configuration. The reference bandwidth actually changes the 108 value in metric calculation formula.

Router LSA Example

Example 8-1 shows the output of a router LSA from a Cisco router.

Example 8-1 Router LSA Output

RouterB#show ip ospf database router 141.108.1.21
LS age: 1362
Options: (No TOS-capability, DC)
LS Type: Router Links
Link State ID: 141.108.1.21
Advertising Router: 141.108.1.21
LS Seq Number: 80000085
Checksum: 0xE914
Length: 60
Area Border Router
Number of Links: 3
Link connected to: another Router (point-to-point)
(Link ID) Neighboring Router ID: 141.108.1.3
(Link Data) Router Interface address: 141.108.1.2
Number of TOS metrics: 0
TOS 0 Metrics: 64
Link connected to: another Router (point-to-point)
(Link ID) Neighboring Router ID: 141.108.3.1
(Link Data) Router Interface address: 141.108.1.2
Number of TOS metrics: 0
TOS 0 Metrics: 64
Link connected to: a Stub Network
(Link ID) Network/subnet number: 141.108.1.2
(Link Data) Network Mask: 255.255.255.255
Number of TOS metrics: 0
TOS 0 Metrics: 0

The output in Example 8-1 shows three links. A few important things to note in this output (as highlighted) are as follows:

• In normal situations, the LS Age field should be less than 1800.
• In the case of a router LSA, the Link-State ID field and advertising router should have the same value as they do in Example 8-1.
• This router is an ABR and has three router links.

With every point-to-point link, there is a stub link to provide the subnet mask of the link. In this example, two point-to-point links and one stub link are associated with these two point-to-point links because the network type is point-to-multipoint. So, if there are 300 point-to-point links, the router will generate 300 point-to-point links as well as 300 stub links to address the subnet associated with each point-to-point link. The point-to-multipoint network type is a better choice in this case, for two reasons:

• Only one subnet is required per point-to-multipoint network.
• The size of the router LSA is cut in half because there will be only one stub link to address the subnet on a point-to-multipoint network. This link is usually a host address.

If you drew a network topology out of this information, you would actually see a small part of OSPF network, as shown in Figure 8-9.

Network LSA

The DR generates the network LSA. If no DR exist (for example, in point-to-point or point-to-multipoint networks), there will be no network LSA. The network LSA describes all the routers attached to the network. This LSA is flooded in the area that contains the network, just like the router LSA. Figure 8-10 shows the packet format for the network LSA.

The network LSA has two important components:

• Network Mask— This field indicates the network mask associated with the transit link.
• Attached Router— This field includes the router ID of each router associated with this transit link. The designated router also lists itself in attached routers.

Network LSA Example

Example 8-2 shows the output of a network LSA from a Cisco router.

Example 8-2 Network LSA Output

RouterA#show ip ospf database network 141.108.1.1
Routing Bit Set on this LSA
LS age: 1169
Options: (No TOS-capability, DC)
LS Type: Network Links
Link State ID: 141.108.1.1 (address of Designated Router)
Advertising Router: 141.108.3.1
LS Seq Number: 8000000
Checksum: 0xC76E
Length: 36
Network Mask: /29
Attached Router: 141.108.3.1
Attached Router: 141.108.1.21
Attached Router: 141.108.1.3

The last three lines of output in Example 8-2 show that three routers are attached to this transit link. Also, the network mask on this transit link is /29. There are two important things to remember here:

• The Link-State ID field always contains the IP address of the DR.
• The advertising router field always contains the router ID of the DR.

You can similarly draw a network topology from the information contained in the network LSA showing the number of attached routers and the network mask on the link.

Figure 8-11 shows the network topology drawn from the information in the network LSA.

Summary LSA

The summary LSA describes the destination outside the area, but still within the AS. Summary LSAs are generated when there is more than one area provided and Area 0 is configured. The purpose of the summary LSA is to send the reduced topological information outside the area. Without an area hierarchy, it will be difficult to scale the huge topological information in a single area. This LSA does not carry any topological information; it carries only an IP prefix. This LSA is originated by the ABR, as follows:

• From a nonbackbone to a backbone area, summary LSAs are generated for:
  • Connected routes
  • Intra-area routes

NOTE

Only intra-area routes are advertised into the backbone to avoid loops. If there are any inter-area routes coming from nonbackbone area it means that the backbone is discontiguous. A discontiguous backbone is not allowed in OSPF networks.

• From a backbone to a nonbackbone area, summary LSAs are generated for the following:
  • Connected routes
  • Intra-area routes
  • Interarea routes

Two types of summary LSAs exist:

• Type 3— Used for the information about the network
• Type 4— Used for the information about the ASBR

Figure 8-12 shows the packet format for the summary LSA.

The list that follows describes the fields within the summary LSA packet:

• Network Mask— For the Type 3 summary LSA, this field contains the network mask associated with the network. For the Type 4 summary LSA, this field must be 0.
• Metric— This field represents the cost of the network.
• ToS and ToS Metric— These fields are normally set to 0.

Both the Type 3 and Type 4 summary LSAs use the same packet format. The important things to remember about summary LSA Types 3 and 4 are as follows:

• The network mask in Type 3 contains the subnet mask value of the network.
• The network mask field must be 0.0.0.0 in Type 4 LSAs.
• In Type 3 LSAs, the Link-State ID field should have the network number.
• In Type 4 LSAs, the Link-State ID field should have the router ID of the ASBR.

The advertising router field must contain the router ID of the ABR generating the summary LSA. This is true for both Type 3 and 4 LSAs.

There is one special case of summary LSAs—in cases when a stub-area ABR generates a summary default route. In this case, the Link-State ID field as well as the network mask must be 0.0.0.0.

Summary LSA Example

Example 8-3 shows the output of a summary LSA from a Cisco router.

Example 8-3 Summary Network LSA Output

RouterB#show ip ospf database summary 9.9.9.0
LS age: 1261
Options: (No TOS-capability, DC)
LS Type: Summary Links(Network)
Link State ID: 9.9.9.0 (summary Network Number)
Advertising Router: 141.108.1.21
LS Seq Number: 80000001
Checksum: 0xC542
Length: 28
Network Mask: /24
TOS: 0 Metric: 10

The Link-State ID field here is the network 9.9.9.0, and the network mask is /24. The Link-State ID field in summary LSAs Type 3 will always contain the network number that the summary LSA is generated for, along with the network mask. The summary LSA here is generated for 9.9.9.0/24, as shown in Figure 8-13.

Example 8-4 shows summary ASBR LSA output.

Example 8-4 Summary ASBR LSA Output

RouterB#show ip ospf database asbr-summary 141.108.1.21
LS age: 1183
Options: (No TOS-capability, No DC)
LS Type: Summary Links(AS Boundary Router)
Link State ID: 141.108.1.21 (AS Boundary Router address)
Advertising Router: 141.108.1.1
LS Seq Number: 80000001
Checksum: 0x57E4
Length: 28
Network Mask: /0
TOS: 0 Metric: 14

The output from Example 8-4 shows that this is summary LSA Type 4. The network mask is 0, and the Link-State ID is the router ID of the ASBR. In case of Type 4, the Link-State ID is always the router ID of the ASBR. The Network Mask field must always be 0 because this is the information about a router (ASBR), not a network. Figure 8-14 shows the net-work diagram based on the output shown in Example 8-4.

Example 8-5 shows the default summary ASBR LSA output.

Example 8-5 Default Summary LSA Output

RouterB#show ip ospf database summary 0.0.0.0
LS age: 6
Options: (No TOS-capability, DC)
LS Type: Summary Links(Network)
Link State ID: 0.0.0.0 (summary Network Number)
Advertising Router: 141.108.1.21
LS Seq Number: 80000001
Checksum: 0xCE5F
Length: 28
Network Mask: /0
TOS: 0 Metric: 1

The output in Example 8-5 shows that the Link-State ID and network mask are 0.0.0.0. Because this is the information about a default route, it must have 0.0.0.0 in the Link-State ID, and the network mask must be 0.0.0.0. These two pieces of information then represent the default route as 0.0.0.0/0. This summary default will be present in a stubby area situation, as shown in Figure 8-15.

External LSA

The external LSA defines routes to destinations external to the autonomous system. Domain-wide, the default route can also be injected as an external route. External LSAs are flooded throughout the OSPF domain, except to stubby areas. To install an external LSA in the routing table, two essential things must take place:

The calculating router must see the ASBR through the intra-area or interarea route. This means that it should have either a router LSA for the ASBR or a Type 4 LSA for the ASBR, in case of multiple areas.

The forwarding address must be known through an intra- or interarea route.

Figure 8-16 shows the packet format for the external LSA.

The list that follows describes the fields within the external LSA packet:

• Network Mask— Specifies the network mask of the external network.
• Bit E— Specifies the external type. If set, it is an external Type 2; otherwise, it is Type 1. The difference between type and type external is that the Type 1 metric is similar to the OSPF metric and the cost gets changed every hop; in Type 2, however, the external metric doesn’t change. The metric remains the same throughout the OSPF domain.
• Forwarding Address— Indicates the address to which data traffic to the advertised network should be forwarded. If the value is set to 0.0.0.0, this means that the traffic should be forwarded to the ASBR. In some situations, the forwarding address will be nonzero, to avoid suboptimal routing. The following list describes events that will produce a nonzero forwarding address:
  • OSPF is enabled on the ASBR’s next-hop interface.
  • The ASBR’s next-hop interface is nonpassive to OSPF.
  • The ASBR’s next-hop interface network type is not point-to-point or point-to-multipoint.
  • The ASBR’s next-hop interface address falls into the OSPF network range.
• External Route Tag— Not used by OSPF.

The ToS and ToS Metric fields normally are not used by any vendor.

External LSA Example

Example 8-6 shows the output of the external LSA from the Cisco router.

Example 8-6 External LSA Output

RouterE#show ip ospf database external 10.10.10.0
LS age: 954
Options: (No TOS-capability, DC)
LS Type: AS External Link
Link State ID: 10.10.10.0 (External Network Number)
Advertising Router: 141.108.1.21
LS Seq Number: 80000003
Checksum: 0x97D8
Length: 36
Network Mask: /24
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 20
Forward Address: 0.0.0.0
External Route Tag: 0

The output in Example 8-6 shows an external LSA for network 10.10.10.0/24. This is a Type 2 external LSA. There are a few important things to remember here:

• The Link-State ID field represents the external network number.
• The advertising router field contains the router ID of the ASBR.
• Metric Type: 2 means that the metric—20, in this case—remains the same throughout the OSPF domain.
• A forwarding address of 0.0.0.0 means that the traffic should be forwarded directly to the ASBR.

The route to the nonzero forwarding address must be known through an intra-area or interarea route; otherwise, the external route will not get installed in the routing table.

Figure 8-17 shows a network in which a Type 5 LSA is originated by Router E (ASBR). RIP is getting redistributed into Router E, so Router E originates a Type 5 LSA for every RIP subnet. Those Type 5 LSAs are propagated throughout the OSPF domain.

OSPF Areas

OSPF provides two levels of hierarchy throughout an area. An area is a 32-bit number that can be defined either in an IP address format of “Area 0.0.0.0” or as a decimal number format, such as “Area 0.” Area 0 is a backbone area, which is required if more than one area is configured. All areas must be connected to Area 0; otherwise, virtual links are needed, as shown in Figure 8-18.

Example 8-7 shows the configuration required for a virtual link between Router E and Router B. Area 2 is the transit area between Routers E and B. Router E will form a virtual link with Router B’s router ID, and vice versa. It is recommended that you use a loopback IP address as a router ID because loopback links always stay up; therefore, the virtual link will stay up.

Example 8-7 Configuring the Virtual Link Between Routers E and B

RouterE#
router ospf 1
area 2 virtual-link 141.108.1.1
_____________________________________________________________________________________
RouterB#
router ospf area 2 virtual-link 141.108.1.21
area 2 virtual-link 141.108.1.21

A virtual link itself is not a bad thing. The bad design would include an area that is not connected to Area 0, as shown in Figure 8-18, and then patching it up with a virtual link. Virtual links can be very useful in several scenarios. Figure 8-19 shows an example in which a virtual link can be used as a backup and for redundancy—in case the link between routers A and B goes down, the Area 3 connectivity will not be broken. Also, if the link between Routers C and D goes down, the backbone remains contiguous through the virtual link.

Example 8-8 shows the configuration of Routers A, B, C, and D. Routers A and D form a virtual link between each other with transit Area 2, and Router C and D form a virtual link with transit Area 1 between them. The virtual link between Routers A and B is to back up Area 3 connectivity; the virtual link between routers C and D is to back up Area 0 if the link between Routers E and F fails.

Example 8-8 Configuring the Virtual Link Between Routers A, B, C, and D

RouterA#
router ospf 1
area 2 virtual-link 141.108.1.2
_____________________________________________________________________________________
RouterB#
router ospf 1
area 2 virtual-link 141.108.1.1
_____________________________________________________________________________________
RouterC#
router ospf 1
area 1 virtual-link 141.108.1.4
_____________________________________________________________________________________
RouterD
router ospf 1
area 1 virtual-link 141.108.1.3

Figure 8-20 shows another example in which a virtual link can be useful for optimal routing. If the link between Routers B and C is put in Area 1, Area 0 will suffer from suboptimal routing. If that link is put into Area 0, area 1 will suffer from suboptimal routing. So, the solution is to put that link in Area 1 and then configure a virtual link between Routers B and C. This way, it will carry both the backbone and Area 1 traffic.

Example 8-9 shows the configuration that is required to form a virtual link between Routers B and C. This virtual link is needed for path optimization.

Example 8-9 Configuring Routers B and C to Form a Virtual Link for Path Optimization

RouterB#
router ospf 1
area 1 virtual-link 141.108.1.3
_____________________________________________________________________________________
RouterC#
router ospf 1
area 1 virtual-link 141.108.1.2

OSPF has several types of areas, which can be defined according to the needs of a network:

• Normal area
• Stub area
• Totally stubby area
• Not-so-stubby area (NSSA)
• Totally not-so-stubby area

The sections that follow cover the different OSPF areas in greater detail.

Normal Areas

When the area is defined by default, it is considered a normal or regular area. Normal areas have the following characteristics:

• Summary LSAs from other areas are injected.
• External LSAs are injected.
• External default LSAs can be injected.

In Figure 8-21, Area 1 and Area 2 are normal areas. IGRP routes are redistributed into Area 1, and RIP routes are redistributed into Area 2.

Stub Areas

In stub areas, no external LSAs are allowed. Recall the Options field in OSPF Hello packet. One of the bits in that option field is the E bit. In cases of stub areas, the E bit is clear, indicating that the area is incapable of importing any external LSAs.

Stub areas have the following characteristics:

• Summary LSAs from other areas are injected.
• The default route is injected as a summary route.
• External LSAs are not injected.

In Figure 8-22, Area 1 is defined as a stub area. No redistribution can take place at Routers I, H, or G because no Type 5 LSAs are allowed by stub areas. Also, RIP routes that are injected at Router E as OSPF externals are blocked at Router F; however, Area 1 still receives the summary route created for Area 2 by Router F (ABR). A default summary LSA also will be injected by the ABR (Router F) into Area 1. This means that if Routers I, H, or G need to send a packet to external destination, they will always forward the packet to the nearest ABR, which is Router F in this case.

Example 8-10 shows the configuration required to make Area 1 a stub area. This stub configuration must be done on all the routers in Area 1.

Example 8-10 Configuring Area 1 as a Stub Area

RouterF#
router ospf 1
area 1 stub

Totally Stubby Areas

Totally stubby areas are the most restricted form of area. Routers in this type of area rely on only the injection of a default summary route from the ABR. No other external or summary information is included in the routing table. This is an extension to the stub area, so all the characteristics are still true for this area. This area has the following characteristics:

• No summary LSAs are allowed.
• No external LSAs are allowed.
• The default route is injected as a summary route.

In Figure 8-13, Area 1 will not receive any summary route or any external routes. The only routes that Area 1 will have are the intra-area (marked with O in the routing table) routes for Area 1 and the default route injected by the ABR, which is marked with O IA.

Example 8-11 shows the configuration required on the ABR to make Area 1 a totally stubby area. Note that the difference between the stubby area and the totally stubby area is that no summary LSA is generated into a totally stubby area. Because summary LSA generation takes place only at the ABR, the configuration change needs to happen only at the ABR. All other routers that are configured with a stub option do not require any change in the con-figuration. The keyword no-summary here means to avoid sending any summary LSAs in Area 1.

Example 8-11 Configuring the ABR (Router F) to Make Area 1 Totally Stubby

RouterF#
router ospf 1
area 1 stub no-summary

Not-So-Stubby Areas

This is also an extension of the stub area. Suppose in Figure 8-12 that Area 1 is defined as a stub area and there is a requirement of redistribution of an IGRP route into that area. If Area 1 were defined as stub, this would not be possible. To redistribute an IGRP route into Area 1, Area 1 must be changed into an NSSA. When Area 1 is changed into an NSSA, it will allow redistribution and then IGRP routes can be redistributed into the NSSA area as Type 7 LSAs.

NSSAs were created to inject external routes from stub areas into the OSPF domain. In the NSSA, when the ASBR injects a route into the AS, it generates a Type 7 LSA. The ABR translates this LSA to a Type 5 LSA, which is propagated to the rest of the autono-mous system. The Type 7 LSA flooding scope is within the NSSA area.

NSSA is supported starting in Cisco IOS Software Release 11.2. NSSAs have the following characteristics:

• Type 7 LSAs carry external information within an NSSA.
• Type 7 LSAs are converted into Type 5 LSAs at the NSSA ABR.
• No external LSA are allowed.
• Summary LSAs are injected.

Because this is an extension of a stub area, RIP routes are not injected into Area 1 as OSPF external routes; IGRP routes, however, get converted into Type 7 LSAs.

Example 8-12 shows the configuration example for an NSSA area. The keyword nssa must be typed on all the routers that are part of Area 1, as shown Figure 8-21

Example 8-12 Configuring an NSSA on All the Routers in the NSSA Area

RouterF#
router ospf 1
area 1 nssa

Type 7 LSAs

The packet format for Type 7 LSA is very similar to that of Type 5. The three main differences are as follows:

• The Type field contains the value of 7 instead of 5, indicating its Type 7 LSA.
• The forwarding address is calculated as follows:If the route has a next-hop address (not true for connected routes), try to use it. This is possible only if the route is an OSPF internal route. Everything that was explained in the Type 5 forwarding address selection also holds true for Type 7 LSAs. If any of the conditions explained in the Type 5 forwarding address selection criteria is not true, the next hop will not be used as a forwarding address. The following two rules apply in that case:
  • Use one of the loopback addresses (if it’s up and OSPF is running) in the area that is announcing LSAs.
  • If no loopback addresses are configured, use the address of the first interface in that area.
• The P bit is explained in the following example.

NSSA LSA Example
Example 8-13 shows the output of the NSSA LSA from Figure 8-23. Router I is the NSSA ASBR doing redistribution of IGRP

into OSPF.

Type 7 LSAs are generated into Area 1 and then are translated into Type 5 LSAs by the NSSA ABR, which is Router F.

Example 8-13 NSSA LSA Output

RouterI#show ip ospf database nssa-external 10.10.10.0
LS age: 36
Options: (No TOS-capability, Type 7/5 translation, DC)
LS Type: AS External Link
Link State ID: 10.10.10.0 (External Network Number)
Advertising Router: 141.108.1.21
LS Seq Number: 80000001
Checksum: 0x4309
Length: 36
Network Mask: /24
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 20
Forward Address: 141.108.1.21
External Route Tag: 0

The output of the NSSA LSA resembles that of the external LSA output, except that there are a few important things to remember regarding the P bit in this output:

• The P bit is used to tell the NSSA ABR whether to translate Type 7 LSAs into Type 5 LSAs. This bit was already mentioned in the Option field that was discussed in the “Hello Packets” section earlier.
• No Type 7/5 translation means bit P = 0.
• Type 7/5 translation means bit P = 1.
• If bit P = 0, the NSSA ABR must not translate this LSA into a Type 5 LSA. This happens when the NSSA ASBR is also an NSSA ABR.
• If bit P = 1, the NSSA ABR (if multiple NSSA ABRs exist, the one with the lowest router ID) must translate this Type 7 LSA into a Type 5 LSA.

P stands for propagation. Basically, this bit is used for propagation control. The ABR makes the decision based on the value of this bit.

NSSA Configuration Example

Example 8-14 shows a configuration example for defining an NSSA area. This configu-ration must be present on all routers that are in Area 1, as shown in Figure 8-23.

Example 8-14 Configuring an NSSA

RouterF#
router ospf 1
area 1 nssa

After defining Area 1 as an NSSA in Figure 8-23, it will have the following characteristics:

• No Type 5 LSAs are allowed in Area 1. This means that no RIP routes are allowed in Area 1.
• All IGRP routes are redistributed as Type 7 routes. This Type 7 route can exist only within NSSA.
• All Type 7 LSAs are translated into Type 5 LSAs by the NSSA ABR and are leaked into the OSPF domain as Type 5 LSAs.

Totally Not-So-Stubby Areas

This type of area is an extension to the NSSA. If only one exit point exists, this is the most recommended form of NSSA area type. In Figure 8-23, if Area 1 is defined as a totally NSSA, the following is true:

• No RIP routes will be injected into Area 1 because those are external routes.
• No summary LSA from other areas will be injected into Area 1 because of the definition of a totally NSSA.
• The default summary LSA will be generated by the ABR, Router F.
• Totally NSSAs have the following characteristics:
• No summary LSAs are allowed.
• No external LSAs are allowed.
• The default route is injected as a summary route.
• Type 7 LSAs are converted into Type 5 LSAs at the NSSA ABR.

Example 8-15 shows the configuration required on the NSSA ABR. As in case of totally stubby areas, the no-summary command is needed only on the ABR because the summary LSA generation is done on the ABR.

Example 8-15 Configuration on the NSSA ABR, Router F, for Totally NSSA Area

RouterF#
router ospf 1
area 1 nssa no-summary

Filtering in NSSA

In some situations, there is no need to inject external routes into the NSSA as Type 7 routes. This situation usually occurs when an ASBR is also an NSSA ABR.

When redistribution takes place in this scenario, the router generates Type 5 LSAs as well as Type 7 LSAs. In Figure 8-24, Area 1 is configured using the no-redistribution option.

This means that all IGRP routes are redistributed into Area 0, but no Type 7 LSAs will be generated for Area 1. Example 8-16 shows the configuration that prevents NSSA ABR Router A from generating Type 7 LSAs for IGRP routes.

Example 8-16 Configuration to Filter Type 7 in NSSA

RouterA#
router ospf 1
area 1 nssa no-redistribution

Configure the no-redistribution command on an NSSA ABR that’s also an ASBR.

Another case of filtering occurs when you need to prevent the Type 7 LSAs from being translated outside the NSSA. In other words, you want to control which Type 7 LSAs get translated into Type 5 LSAs. For example, Figure 8-24 shows a RIP-learned route 141.108.10.0/24 that’s being injected into the OSPF NSSA Area 1. You don’t want this route to be leaked into the rest of the OSPF areas. Example 8-17 shows the configu-ration that will prevent RIP routes from being translated into Type 5 LSAs. This configuration can be used on either Router A or Router B.

Example 8-17 Configuration to Control Type 7 to Type 5 Conversion

RouterA#
router ospf 1
summary-address 141.108.10.0 255.255.255.0 not-advertise

This summary-address configuration generates a Type 7 LSA that won’t be translated into a Type 5 LSA by the NSSA ABR.

Default Routes in NSSA

There are two ways to have a default route in an NSSA:

• When you configure an area as an NSSA, the NSSA ABR doesn’t generate a default summary route, by default.
• In the case of a stub area or an NSSA, totally stubby area, the NSSA ABR generates a default summary route.

Default Summary Route

By defining an area as an NSSA, totally stubby area, the NSSA ABR generates a default summary route. As mentioned earlier, if the NSSA area were not defined as a totally stubby area, a default summary route would not be generated by the NSSA ABR. Example 8-18 shows how to send a default summary route in an NSSA by configuring an NSSA, totally stubby area. This is done by applying the no-summary option on the NSSA ABR.

Example 8-18 Configuration to Generate the Default Summary Route into an NSSA Area

RouterA#
router ospf 1
area 1 nssa no-summary

Default Type 7

Example 8-19 shows the configuration that generates a Type 7 default route. You can configure this command on any NSSA ASBR or NSSA ABR, with the following rules:

• NSSA ASBR can generate a default only when it has a default route in its routing table.
• NSSA ABR can generate a default route with or without a default route in its own routing table.

Example 8-19 Configuration for Originating Type 7 Default into an NSSA Area

RouterA#
router ospf 1
area 1 nssa default-information-originate

OSPF Media Types

OSPF runs on several media types. On some media, such as multiaccess and point-to-point media, the OSPF default network type is used. Therefore, there is no need to configure any network type on those media.

This section goes into detail on each medium type in OSPF and what network type to use for each medium. For OSPF, media can be divided into four categories:

• Multiaccess media
• Point-to-point media
• Nonbroadcast multiaccess media
• Demand circuits

Multiaccess Media

Multiaccess media includes Ethernet, Fast Ethernet, Gigabit Ethernet, FDDI, Token Ring, and similar multiaccess media. OSPF runs as a broadcast network type over these media. The OSPF network type of broadcast is on by default over these media.

In this network type, the DR and the BDR are elected to reduce the flooding on the segment. The multicast capabilities of OSPF are used to form adjacencies and to efficiently distribute the information to other routers on the segment. In broadcast network types, the interface subnet mask is checked in the Hello packet. If the masks of the two routers are different, an adjacency will not be formed.

Because this network type is on by default, no specific configuration is required for this media. Figure 8-25 shows an example of OSPF run over multiaccess media. Router A is elected as a DR because it has the highest priority. Router B is elected as the BDR. The priorities of both Routers B and C are equal; therefore, the BDR election is based on the highest router ID. All the routers will form an adjacency with the DR and the BDR. The DR and the BDR will listen specifically to the multicast address of 224.0.0.6 (all DR routers), while all other routers will listen to the multicast address of 224.0.0.5 (all SPF routers).

Point-to-Point Media

Point-to-point media includes HDLC and PPP encapsulation links, Frame Relay/ATM point-to-point subinterfaces, and similar point-to-point interfaces.

The OSPF network type of point-to-point is on by default on these media. No DR or BDR election takes place on this medium type. All the OSPF packets are multicast-based. The reason for sending all OSPF packets as multicast is that, in some cases of unnumbered links, the destination address is not known. Figure 8-26 shows an example of point-to-point media. Router A is attached to three other routers through point-to-point links. Router A will form a full adjacency with Routers B, C, and D.

Nonbroadcast Multiaccess Media

Many media fall under this category of nonbroadcast multiaccess (NBMA), including Frame Relay, X.25, SMDS, and ATM. Additional configuration is required for this type of medium. The OSPF network type on these media is nonbroadcast, by default. Several network type options can be defined in this scenario. This medium can be run in several modes under OSPF:

• Broadcast model
• Point-to-point model
• Point-to-multipoint model

Broadcast Model

In the broadcast model, the broadcast network is simulated. DRs and BDRs are elected. The broadcast model can be simulated in two ways:

• Configure the network-type broadcast.
• Configure the neighbor statement.

Figure 8-27 shows the NBMA network model. The medium is Frame Relay between routers. Router A has connectivity to all other routers; however, Routers B, C, D, and E are connected only to Router A, not to each other, through Frame Relay PVCs. The only time the broadcast model works here is when all routers are fully meshed. In a partially meshed situation, as shown in Figure 8-27, running a broadcast model is not recommended.

Assuming that there is fully meshed Frame Relay connectivity, Example 8-20 shows the configuration that is required on all the routers. This configuration changes the network type of the router’s Frame Relay interface to broadcast. One important thing to note here is that, in case of a static Frame Relay mapping, the keyword broadcast must be used at the end; otherwise, the OSPF multicast Hello will not go across the Frame Relay connection.

Example 8-20 Configure the Network Type as Broadcast

RouterA#
interface serial 0
encapsualtion frame-relay
ip ospf network-type broadcast

The command ip ospf network-type broadcast must be configured on all the routers’ Frame Relay interfaces.

Another way to simulate the broadcast model is through the neighbor statement, as shown in Example 8-21. The neighbor statement must be configured manually in the hub router, which is Router A in this case. Router A must be configured with a higher priority so that it can always be the DR.

Example 8-21 Configuring the neighbor Statement on the Hub Router

RouterA#
interface serial 0
encapsulation frame-relay
ip address 141.108.1.1 255.255.255.0
ip ospf priority 10
!
router ospf 1
neighbor 141.108.1.2
neighbor 141.108.1.3
neighbor 141.108.1.4
neighbor 141.108.1.5

Point-to-Point Model

If the point-to-point model is used, each PVC must be defined as a separate point-to-point subinterface; therefore, a separate subnet for each point-to-point subinterface is needed. Example 8-22 shows the configuration required at the hub Router A to create point-to-point subinterfaces. No network type is needed under the subinterface because, by default, all subinterfaces have a point-to-point network type. The physical topology remains the same as that shown in Figure 8-27.

The advantage of this model is that virtual circuit (VC) cost can be configured on a per-interface basis. The disadvantage is that a lot of address space is wasted on every point-to-point subinterface. In addition, the size of the router LSA created by Router A will be fairly large because it must include a Type 3 stub link for every point-to-point link.

Example 8-22 Configuring Point-to-Point Subinterfaces

RouterA#
Interface Serial 0.1 point-to-point
ip address 141.108.1.1 255.255.255.252
!
Interface Serial 0.2 point-to-point
ip address 141.108.1.5 255.255.255.252
Similarly, other subinterfaces can be created.

Point-to-Multipoint Model

In a point-to-multipoint model, each router that has connectivity with another router forms an adjacency with that router. No DR or BDR is elected in this network type. Muticast Hellos are sent to discover neighbors, so it is essential that Layer 2 must support multicast/broadcast capability. Also, only one subnet is required for the whole NBMA cloud, as shown in Figure 8-27.

Example 8-23 shows the configuration required for the point-to-multipoint network type. Router A’s Serial 0 is configured for point-to-multipoint network type. This net-work type must be configured on all the remote Routers B, C, D, and E.

Example 8-23 Configuration for Point-to-Multipoint Network Type

RouterA#
interface serial 0
encapsulation frame-relay
ip address 141.108.1.1 255.255.255.0
ip ospf network-type point-to-multipoint

This is the recommended network type to use in non–fully meshed NBMA networks. Sometimes, a medium is NBMA but is not capable of supporting multicast, so point-to-multipoint network type cannot be used. For this kind of medium, another network type has been introduced, called point-to-multipoint nonbroadcast. Assuming in Figure 8-27 that the NBMA network does not support multicast capabilities, this new type can be used. Example 8-24 shows the configuration required for this network type. This network type is configured only on Serial 0 on Router A, but it must be configured on all the remote router’s serial interfaces. The neighbor statement is required for this network type, but a DR and BDR will not be elected.

Example 8-24 Configuring Point-to-Multipoint Nonbroadcast Network Type

RouterA#
interface serial 0
encapsulation frame-relay
ip address 141.108.1.1 255.255.255.0
ip ospf network-type point-to-multipoint non-broadcast
!
router ospf 1
neighbor 141.108.1.2
neighbor 141.108.1.3
neighbor 141.108.1.4
neighbor 141.108.1.5

Demand Circuits

The demand circuit option was introduced as of Cisco IOS Software Release 11.2. With demand circuits, an adjacency is formed and all the databases are exchanged at the beginning. Then after the dead timer kicks in, the adjacency remains up even after the Layer 2 goes down. This is useful when you have to pay unnecessary toll charges to keep the link in use. ISDN is a prime example of a situation in which a demand circuit can be used. As long as the ISDN link is up, you must pay for the link.

The main characteristics of a demand circuit that make it different from a normal circuit are as follows:

• Periodic Hellos are suppressed.
• Periodic LSAs refreshes are suppressed.

Periodic Hellos are suppressed only on point-to-point and point-to-multipoint network types. All other network type Hellos still are sent over the interface.

The periodic LSA refresh that takes place every 30 minutes will not happen with a demand circuit because when the demand circuit link is established, a unique option bit, the DC bit or Do Not Age (DNA) bit (discussed earlier in the “Hello Packets” section), is sent across. If two routers negotiate the DC bit successfully, they make a note of it and set a specific bit in the LSA Age field that is the most significant bit. By setting this bit, the LSA stops aging over the demand circuit, so no periodic updates are sent.

In two normal scenarios the periodic refresh of the LSA will be sent:

• If there is a change in network topology
• If there is a router in OSPF domain that cannot understand demand circuits

In the first case, not much can be done because the router must send the new LSA infor-mation to update the neighbor about the topology change. In the second case, however, there is a special way to handle this situation.

The ABR, which is the router between A and C in Figure 8-28, knows that Router C is incapable of understanding DNA LSAs because it sees the options in the LSA originated by Router C and because the DC bit is clear in the Option field. When this situation occurs, the ABR indicates to the demand circuit–capable routers not to originate the LSA with the DNA bit set because there is a router that does not understand the DNA bit. The ABR originates an indication LSA in the backbone, telling everyone in the backbone not to originate any DNA LSAs. This indication LSA is shown in Example 8-25. This is a Type 4 summary LSA in which the link-state ID is the ABR itself instead of the ASBR.

Example 8-25 Indication LSA Example

RouterA#show ip ospf database asbr-summary
Adv Router is not-reachable
LS age: 971
Options: (No TOS-capability, No DC)
LS Type: Summary Links(AS Boundary Router)
Link State ID: 141.108.1.129 (AS Boundary Router address)
Advertising Router: 141.108.1.129
LS Seq Number: 80000004
Checksum: 0xA287
Length: 28
Network Mask: /0
TOS: 0 Metric: 16777215

The metric of indication LSA is set to infinity, and the link-state ID is always the router ID of the ABR originating the indication LSA. In Figure 8-28, the link between Routers A and B is configured as a demand circuit, but because there is a router in Area 1 that is incapable of understanding the DNA LSA, no DNA LSA will be originated by Area 2. As a result, the periodic refresh of the LSAs will be sent across the demand circuit.

As a solution, configure Area 1 as a stub or NSSA area. This is because of section 2.5.1 of the Demand Circuit RFC 1793 that states: “LSAs in regular OSPF areas are allowed to have DoNotAge set if and only if every router in the OSPF domain (excepting those in stub areas and NSSAs) is capable of DoNotAge processing.” So, if Area 1 is defined as stub or NSSA, LSA in Area 2 will be allowed to have LSA with DNA bit set.

Another recommendation is to always include a demand circuit in a nonbackbone area. If a situation arises similar to the one shown in Figure 8-28 and the demand circuit is also a part of the backbone, there is no solution for this because the backbone area cannot be configured as a stub or NSSA area. The advantage of configuring demand-circuit in a stub area is that if there are any routers in a remote OSPF area that cannot understand the DNA LSA, the indication LSA that will be generated by the ABR can never enter into the stub area. Therefore, the demand-circuit capable routers can still generate the LSA with DNA bit set within the area. Example 8-26 shows the configuration necessary to make a circuit a demand circuit. Only one side is required to have the demand circuit command under the interface because, if the other side is capable of understanding demand circuits, it auto-matically negotiates this capability in the Hello packet; otherwise, it simply ignores this option.

Example 8-26 Configuring a Demand Circuit

RouterA#
interface serial 0
encapsulation frame-relay
ip address 141.108.1.1 255.255.255.0
ip ospf network-type point-to-multipoint
ip ospf demand-circuit

A demand circuit can be run on any network type. The difference is that, without a point-to-point or point-to-multipoint network type, the Hellos will not be suppressed; however, these media types can still use the flooding robustness of demand circuit, and the LSA will not age out over that demand circuit links.

OSPF Media Type Summary

Table 8-4 explains the default value for each type of medium and gives the recommended network type.

OSPF Adjacencies

OSPF creates adjacencies between neighboring routers for the purpose of exchanging routing information. Not every neighbor becomes adjacent in a broadcast environment. The Hello protocol is responsible for establishing and maintaining an adjacency.

Hello packets are sent periodically out all router functional interfaces. Two-way communi-cation is established when the router is listed in the neighbor’s Hello packet. On broadcast and NBMA networks, Hello packets are used to elect the DR/BDR.

After the two-way communication is established, the decision is made whether to form an adjacency with this neighbor. This decision is based on the neighbor state and network type. If the network type is broadcast or nonbroadcast, the adjacency is formed only with the DR and BDR routers. In all other network types, the adjacency is formed between two neighbor routers.

The first step in forming the adjacency is synchronization of the database. Each router des-cribes its link-state database in the DBD packet. Only the LSA headers are exchanged bet-ween neighbors. Master and slave election takes place during this database exchange. Each router makes a note of the LSA headers that it receives during this DBD exchange. At the end of the DBD exchange, it sends the LS request packet to request LSAs whose headers have been seen during the DBD exchange. The neighbor router then replies with the LS update packet listing the entire content of those LSAs. This LS update packet is then acknowledged by sending the link-state acknowledgment packet. At this point, all the databases are fully exchanged, and the neighbor goes into Full state.

A router can be in several neighbor states:

• Down
• Attempt
• Init
• 2-way
• Exstart
• Exchange
• Loading
• Full

The sections that follow describe the different OSPF states in more detail.

OSPF Down State

In Figure 8-29, R1 and R2 are running OSPF. The neighbor state shows DOWN. This state means that no information has been received from the neighbor yet.

OSPF Attempt State

The Attempt state is valid for neighbors on NBMA networks. If a neighbor is in this state, it means that no information is received from this neighbor, but serious effort is being made to contact the neighbor. Serious effort means that this router will constantly send a Hello packet upon every Hello interval to contact the neighbor. In Figure 8-30, R1 is sending a Hello packet that says that R1 has not seen anyone yet and doesn’t know about the DR.

OSPF Init State

Init state is a one-way Hello. In Figure 8-31, R1 sends a Hello packet. Upon receiving this Hello, R2 declares a one-way state because R2 doesn’t see itself (its router ID) in that Hello packet.

OSPF 2-Way State

An OSPF neighbor reaches the 2-way state when bidirectional communication is estab-lished. This is the beginning of an OSPF adjacency. The DR and BDR are elected in this state. In Figure 8-32, R2 sends a Hello packet that says that R2 has seen R1’s Hello; the router ID of R2 is higher, so it has also elected itself as a DR.

OSPF Exstart State

This state is used for initialization of the database synchronization process. Master and slave are elected in this state. The first sequence number for DBD exchange is also decided in this state. In Figure 8-33, R1 sends the first DBD packet. R2 also sends it first DBD packet. The router that has the highest router ID becomes the master. In this example, R2 has a higher router ID, so R2 is the master.

OSPF Exchange State

In the Exchange state, the router describes its entire link-state database through DBD packets. Each DBD sequence is explicitly acknowledged. Only one outstanding DBD packet is allowed at a time. Link-state request packets are also sent in this state to request a new instance of the LSA. Figure 8-34 shows the exchange process in action. R1 and R2 are exchanging their database information. The last arrow shows that the M bit is set to 0. This means that the master has no more data to send. At this stage R1, the slave will send whatever database is left, and R1 will also set the M bit to 0. This is the indication that both routers have exchanged the complete database.

OSPF Loading State

In the Loading state, LS request packets are sent to request the more recent instance of an LSA that has not been received during the exchange process. In Figure 8-35, R1 is in the Loading state and is sending LS request packets to receive a more recent instance of an LSA.

OSPF Full State

This state means that the complete information has been exchanged between OSPF neigh-bors. In Figure 8-36, R1 and R2 have exchanged their entire database information and are in the Full state.

• Troubleshooting IP Routing Protocols