Understanding Open Shortest Path First OSPF

This chapter covers the following key topics about the Open Shortest Path First (OSPF) protocol:

• OSPF packet details

• OSPF LSA details

• OSPF media types

• OSPF adjacencies

OSPF is a link-state interior gateway protocol designed for a large complex network. An IETF standard, OSPF is widely deployed in many large networks. Development began in 1987, and OSPF Version 2 was established in 1991 with RFC 1247. The goal was to have a link-state protocol that is more efficient and scalable than RIP. RFC 2328 (April 1998) is the latest revision to OSPF Version 2.

OSPF runs on top of IP and uses protocol number 89, just as TCP runs on top of IP and uses protocol number 6. OSPF doesn't use any transport protocol, such as TCP, for reliability. The protocol itself has a reliable mechanism of transportation.

OSPF is a classless routing protocol that supports variable-length subnet masking (VLSM) and discontiguous networks. OSPF employs multicast addresses 224.0.0.5 (all SPF routers) and 224.0.0.6 (designated routers [DR] and backup designated routers [BDR]) to send Hellos and updates. OSPF also provides two types of authentication? plain text and message digest algorithm 5 (MD5).

OSPF uses the Dijkstra algorithm as a part of the routing table calculation process. The Dijkstra algorithm produces the shortest-path tree (SPT). Each router represents itself and its links to the neighbors in an understandable form? link-state advertisements (LSAs). Based on information from the shortest path tree, OSPF can draw the network topology.

Each router in OSPF exchanges information about its cost, type of link, and network information with the other routers. Discussed later in the chapter, this multistep process is called link-state advertisement (LSA) exchange.

^ PREVIOUS

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

Table 8-1. OSPF Packet Types

Type

Description

Functionality

1

Hello

To discover neighbors and form DR/BDR relationship and exchange neighbor capabilities.

2

Database description

To elect master/slave for the database exchange process and to exchange the LSA headers and select the first sequence number for database exchange.

3

Link-state request

To request a specific LSA that is seen during the DBD exchange process.

4

Link-state update

To send the entire LSA to the neighbor who requested the particular LSA through the link request packet. This packet is also used in flooding.

5

Link-state acknowledge

To acknowledge the receipt of the link-state update packet.

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

Figure 8-1. Common OSPF Protocol Header Format

Figure 8-1. 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-auely identify the router throughout the autonomous system. For a Cisco box, this

4 PREVIOUS

< Free Open Study >

BSD

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

Table 8-2. Types of LSA

Type

LSA

Functionality

1

Router

Defines the state and cost of the link to the neighbor and IP prefix associated with the point-to-point link.

2

Network

Defines the number of routers attached to the segment. It gives information about the subnet mask on that segment.

3

Summary network

Describes the destination outside an area but within the OSPF domain. The summary for one area is flooded into other areas, and vice versa.

4

Summary ASBR

Describes the information about the ASBR. In a single area, there will be no summary Type 4 LSA.

5

External

Defines routes to destination external to OSPF domain. Every subnet is represented by a single external LSA.

6;*i

Group membership

7

NSSA

Defines routes to an external destination, but in a separate LSA format known as Type 7.

8£*I

Unused

9? 11[*]

Opaque

[*] 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.

[*] 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. Figure 8-7. Common LSA Header Format

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. Page 210

4 PREVIOUS

< Free Open Study >

BSD

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.

Figure 8-18. Using a Virtual Link Where an Area Is Not Attached to the

Backbone

Figure 8-18. Using a Virtual Link Where an Area Is Not Attached to the

Backbone

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.

Was this article helpful?

0 0

Post a comment