Neighbors and Adjacencies
Operation of OSPF [3]
At a very high level, the operation of OSPF is easily explained:
When all link state information has been flooded to all routers in an area ”that is, the link state databases have been synchronized ”and the route tables have been built, OSPF is a quiet protocol. Hello packets are exchanged between neighbors as keepalives , and LSAs are retransmitted every 30 minutes. If the internetwork topology is stable, no other activity should occur. Before any LSAs can be sent, OSPF routers must discover their neighbors and establish adjacencies. The neighbors will be recorded in a neighbor table , along with the link (interface) on which each neighbor is located and other information necessary for the maintenance of the neighbor (Figure 9.1). Figure 9-1. The neighbor table records all OSPF-speaking neighbors. The tracking of other OSPF routers requires that each router have a R outer ID , an IP address by which the router is uniquely identified within the OSPF domain. Cisco routers derive their Router IDs by the following means: Note Router ID
Using addresses associated with loopback interfaces has two advantages:
Cisco's OSPF will continue to use a Router ID learned from a physical interface even if the interface subsequently fails or is deleted (see "Case Study: Setting Router IDs with Loopback Interfaces," later in this chapter). Therefore, the stability of a loopback interface is only a minor advantage. The primary benefit is the ability to control the Router ID. The OSPF router begins a neighbor relationship by advertising its Router ID in Hello packets. The Hello ProtocolThe Hello protocol serves several purposes:
OSPF-speaking routers periodically send a Hello packet out each OSPF-enabled interface. This period is known as the HelloInterval and is configured on a per interface basis. Cisco uses a default HelloInterval of 10 seconds; [5] the value can be changed with the command ip ospf hello-interval . If a router has not heard a Hello from a neighbor within a period of time known as the RouterDeadInterval , it will declare the neighbor down. Cisco's default RouterDeadInterval is four times the HelloInterval and can be changed with the command ip ospf dead-interval . [6]
Each Hello packet contains the following information:
This section overviews the meaning and use of most of the information listed. Subsequent sections discuss the DR, BDR, and Router Priority and illustrate the precise format of the Hello packet. When a router receives a Hello from a neighbor, it will verify that the Area ID, Authentication, Network Mask, HelloInterval, RouterDeadInterval, and Options values match the values configured on the receiving interface. If they do not, the packet is dropped and no adjacency is established. If everything matches, the Hello packet is declared valid. If the ID of the originating router is already listed in the neighbor table for that receiving interface, the RouterDeadInterval timer is reset. If the Router ID is not listed, it is added to the neighbor table. Whenever a router sends a Hello, it includes in the packet the Router IDs of all neighbors listed for the link on which the packet is to be transmitted. If a router receives a valid Hello in which it finds its own Router ID listed, the router knows that two-way communication has been established. Once two-way communication has been established, adjacencies may be established. However, as mentioned earlier, not all neighbors will become adjacent. Whether an adjacency is formed or not depends on the type of network to which the two neighbors are attached. Network types also influence the way in which OSPF packets are transmitted; therefore, before discussing adjacencies, it is necessary to discuss network types. Network TypesOSPF defines five network types:
Point-to-point networks, such as a T1 or subrate link, connect a single pair of routers. Valid neighbors on point-to-point networks will always become adjacent. The destination address of OSPF packets on these networks will always be the reserved class D address 224.0.0.5, known as AllSPFRouters . [7]
Broadcast networks, such as Ethernet, Token Ring, and FDDI, might be better defined as broadcast multi-access networks to distinguish them from NBMA networks. Broadcast networks are multi-access in that they are capable of connecting more than two devices, and they are broadcast in that all attached devices can receive a single transmitted packet. OSPF routers on broadcast networks will elect a DR and a BDR, as described in the next section, "Designated Routers and Backup Designated Routers." Hello packets are multicast with the AllSPFRouters destination address 224.0.0.5, as are all OSPF packets originated by the DR and BDR. The destination Media Access Control (MAC) identifier of the frames carrying these packets is 0100.5E00.0005. All other routers will multicast link state update and link state acknowledgment packets (described later) to the reserved class D address 224.0.0.6, known as AllDRouters . The destination MAC identifier of the frames carrying these packets is 0100.5E00.0006. NBMA networks, such as X.25, Frame Relay, and ATM, are capable of connecting more than two routers but have no broadcast capability. A packet sent by one of the attached routers would not be received by all other attached routers. As a result, extra configuration may be necessary for routers on these networks to acquire their neighbors. OSPF routers on NBMA networks elect a DR and BDR, and all OSPF packets are unicast. Point-to-multipoint networks are a special configuration of NBMA networks in which the networks are treated as a collection of point-to-point links. Routers on these networks do not elect a DR and BDR, and because the networks are seen as point-to-point links, the OSPF packets are multicast. Virtual links, described in a later section, are special configurations that are interpreted by the router as unnumbered point-to-point networks. OSPF packets are unicast over virtual links. In addition to these five network types, it should be noted that all networks fall into one of two more-general types:
Designated Routers and Backup Designated RoutersMultiaccess networks present two problems for OSPF, relating to the flooding of LSAs (described in a later section):
Figure 9-2. Ten adjacencies would be required for each of the five routers on this OSPF network to become fully adjacent with all of its neighbors; 25 LSAs would be originated from the network. Note Designated Router (DR) To prevent these problems a Designated Router is elected on multi-access networks. The DR has the following duties :
The concept behind the DR is that the network itself is considered a "pseudonode," or a virtual router. Each router on the network forms an adjacency with the DR (Figure 9.3), which represents the pseudonode. Only the DR will send LSAs to the rest of the internetwork. Keep in mind that a router might be a DR on one of its attached multi-access networks, and it might not be the DR on another of its attached multi-access networks. In other words, the DR is a property of a router's interface, not the entire router. Figure 9-3. The Designated Router represents the multi-access network. Other routers on the network will form adjacencies with the DR, not with each other. A significant problem with the DR scheme as described so far is that if the DR fails, a new DR must be elected. New adjacencies must be established, and all routers on the network must synchronize their databases with the new DR (part of the adjacency-building process). While all this is happening, the network is unavailable for transit packets. To prevent this problem, a Backup Designated Router is elected in addition to the DR. All routers form adjacencies not only with the DR but also with the BDR. The DR and BDR also become adjacent with each other. If the DR fails, the BDR becomes the new DR. Because the other routers on the network are already adjacent with the BDR, network unavailability is minimized. Note Backup Designated Router (BDR) The election of the DR and BDR is triggered by the interface state machine, which is described in a later section. For the election process to function properly, the following preconditions must exist:
The election procedure of the DR and BDR is as follows :
In simpler language, when an OSPF router becomes active and discovers its neighbors, it checks for an active DR and BDR. If a DR and BDR exist, the router accepts them. If there is no BDR, an election is held in which the router with the highest priority becomes the BDR. If more than one router has the same priority, the one with the numerically highest Router ID wins. If there is no active DR, the BDR is promoted to DR and a new election is held for the BDR. It should be noted that the priority can influence an election, but will not override an active DR or BDR. That is, if a router with a higher priority becomes active after a DR and BDR have been elected, the new router will not replace either of them. So the first two DR-eligible routers to initialize on a multiaccess network will become the DR and BDR. Once the DR and BDR have been elected, the other routers (known as DRothers) will establish adjacencies with the DR and BDR only. All routers continue to multicast Hellos to the AllSPFRouters address 224.0.0.5 so that they can track neighbors, but DRothers multicast update packets to the AllDRouters address 224.0.0.6. Only the DR and BDR will listen to this address; in turn, the DR will flood the updates to the DRothers on 224.0.0.5. Note that if only one eligible router is attached to a multiaccess network, that router will become the DR and there will be no BDR. Any other routers will form adjacencies only with the DR. If none of the routers attached to a multi-access network are eligible, there will be no DR or BDR and no adjacencies will form. The neighbor states of all routers will remain 2-Way (explained later, in "The Neighbor State Machine"). The duties performed by the DR and BDR are described more fully in subsequent sections. OSPF InterfacesThe essence of a link state protocol is that it is concerned with links and the state of those links. Before Hellos can be sent, before adjacencies can be formed, and before LSAs can be sent, an OSPF router must understand its own links. A router's interfaces are the means by which OSPF interprets links. As a result, when speaking of OSPF it is not uncommon to hear the terms interface and link used synonymously. This section examines the data structure OSPF associates with each interface and the various states of an OSPF interface. The Interface Data StructureAn OSPF router maintains a data structure for each OSPF-enabled interface. In Figure 9.4, the command show ip ospf interface has been used to observe the components of an interface data structure. Figure 9-4. The OSPF-specific data related to an interface can be observed with the command show ip ospf interface. In this example, the interface is attached to a point-to-point network type. The components of the interface data structure are as follows: IP Address and Mask. This component is the configured address and mask of the interface. OSPF packets originated from this interface will have this source address. In Figure 9.4, the address/mask pair is 192.168.21.21/30. Area ID. The area to which the interface, and the network to which it is attached, belong. OSPF packets originated from this interface will have this Area ID. In Figure 9.4, the area ID is 7. Process ID. This Cisco-specific feature is not part of the open standard. Cisco routers are capable of running multiple OSPF processes and use the Process ID to distinguish them. The Process ID has no significance outside the router on which it is configured. In Figure 9.4, the Process ID is 1. Router ID. In Figure 9.4, the Router ID is 192.168.30.70. Network Type. The type of network to which the interface is connected: broadcast, point-to-point, NBMA, point-to-multipoint, or virtual link. In Figure 9.4, the network type is point-to-point. [10]
Cost. The outgoing cost for packets transmitted from this interface. Cost is the OSPF metric, expressed as an unsigned 16-bit integer in the range of 1 to 65535. Cisco uses a default cost of 10 8 /BW, expressed in whole numbers , where BW is the configured bandwidth of the interface and 10 8 is the reference bandwidth . The interface in Figure 9.4 has a configured bandwidth of 128K (not shown in the figure), so the cost is 10 8 /128K = 781. The cost can be changed with the command ip ospf cost . This command is especially important when configuring Cisco routers in a multivendor environment. Bay and other vendors , for example, use a default cost of 1 on all interfaces ( essentially making OSPF cost reflect hop counts). If all routers do not assign costs in the same manner, OSPF can route improperly. Note Changing the default cost. The reference bandwidth of 10 8 creates a problem for some modern media with bandwidths higher than 100M (such as OC-3 and Gigabit Ethernet). 10 8 /100M = 1, meaning that higher bandwidths calculate to a fraction of 1, which is not allowed. Beginning with IOS 11.2, Cisco has remedied this with the command ospf auto-cost reference- band width , which allows the default reference bandwidth to be changed. InfTransDelay. The seconds by which LSAs exiting the interface will have their age incremented. In Figure 9.4, this is displayed as Transmit Delay and is shown to be the Cisco default, 1 second. InfTransDelay can be changed with the command ip ospf transmit-delay . State. The functional state of the interface, which is described in the following section, "The Interface State Machine." Router Priority. This 8-bit unsigned integer in the range of 0 to 255 elects the DR and BDR. The priority is not displayed in Figure 9.4 because the network type is point-to-point; no DR or BDR is elected on this network type. Figure 9.5 shows another OSPF interface in the same router. This interface shows an attached network type of broadcast, so a DR and BDR will be elected. The priority shown is 1, the Cisco default. The command ip ospf priority is used to change the Router Priority. Figure 9-5. This interface is attached to a broadcast network type, and the router is the DR on this network. Designated Router. The DR for the network to which the interface is attached is recorded both by its Router ID and by the address of the interface attached to the shared network. Note that no DR is displayed in Figure 9.4; it will be displayed only for multi-access network types. In Figure 9.5, the BDR is 192.168.30.70. The address of its attached interface is 192.168.17.73. A look at the Router ID, the interface address, and the interface state show that Renoir is the DR. Backup Designated Router. The BDR for the network to which the interface is attached is also recorded both by its Router ID and by the address of the attached interface. In Figure 9.5, the BDR is 192.168.30.80, and its interface address is 192.168.17.74. HelloInterval. The period, in seconds, between transmissions of Hello packets on the interface. This period is advertised in Hello packets that are transmitted from the interface. Cisco uses a default of 10 seconds, which can be changed with the command ip ospf hello-interval . Figure 9.5 displays HelloInterval as Hello and shows that the default is being used. RouterDeadInterval. The period, in seconds, that the router will wait to hear a Hello from a neighbor on the network to which the interface is connected before declaring the neighbor down. The RouterDeadInterval is advertised in Hello packets transmitted from the interface. Cisco uses a default of four times the HelloInterval; the default can be changed with the command ip ospf dead-interval . Figure 9.5 displays the RouterDeadInterval as Dead and shows that the default is being used. Wait Timer. The length of time the router will wait for a DR and BDR to be advertised in a neighbor's Hello packet before beginning a DR and BDR selection. The period of the wait timer is the RouterDeadInterval. In Figure 9.4, the wait time is irrelevant because the interface is attached to a point-to-point network; no DR or BDR will be used. RxmtInterval. The period, in seconds, the router will wait between retransmissions of OSPF packets that have not been acknowledged . Figure 9.5 displays this period as retransmit and shows that the Cisco default of 5 seconds is being used. An interface's RxmtInterval can be changed with the command ip ospf retransmit-interval . Hello Timer. A timer that is set to the HelloInterval. When it expires , a Hello packet is transmitted from the interface. Figure 9.5 shows that the Hello timer will expire in three seconds. Neighboring Routers. A list of all valid neighbors (neighbors whose Hellos have been seen within the past RouterDeadInterval) on the attached network. Figure 9.6 shows yet another interface on the same router. Here, five neighbors are known on the network, but only two are adjacent (the Router IDs of only the adjacent neighbors are displayed). As a DRother on this network, the router has established an adjacency only with the DR and the BDR, in keeping with the DR protocol. Figure 9.6. On this network, the router sees five neighbors but has only formed adjacencies with the DR and the BDR. AuType. Describes the type of authentication used on the network. The authentication type may be Null (no authentication), Simple Password, or Cryptographic (Message Digest). Figure 9.6 shows that Message Digest authentication is being used. If Null authentication is used, no authentication type or key information will be displayed when show ip ospf interface is invoked. Authentication Key. A 64-bit password if simple authentication has been enabled for the interface or a message digest key if Cryptographic authentication is used. Figure 9.6 shows that the "youngest key ID" is 10. This alludes to the fact that Cryptographic authentication allows the configuration of multiple keys on an interface to ensure smooth and secure key changes. Figure 9.7 shows an interface that is connected to an NBMA network. Notice that the HelloInterval is 30 seconds, the default for NBMA, and that the RouterDeadInterval is at the default of four times the HelloInterval. Figure 9-7. This interface is attached to a NBMA Frame Relay network and is the BDR for this network. It is worthwhile to spend some time comparing Figures 9.4 through 9.7. All four interfaces are on the same router, yet on each network the router performs a different role. In each case, the interface state dictates the role of the OSPF router on a network. The next section describes the various interface states and the interface state machine. The Interface State MachineAn OSPF-enabled interface will transition through several states before it becomes fully functional. Those states are Down, Point-to-Point, Waiting, DR, Backup, DRother, and Loopback. Down. This is the initial interface state. The interface is not functional, all interface parameters are set to their initial values, and no protocol traffic is transmitted or received on the interface. Point-to-Point. This state is applicable only to interfaces connected to point-to-point, point-to-multipoint, and virtual link network types. When an interface transitions to this state, it is fully functional. It will begin sending Hello packets every HelloInterval and will attempt to establish an adjacency with the neighbor at the other end of the link. Waiting. This state is applicable only to interfaces connected to broadcast and NBMA network types. When an interface transitions to this state, it will begin sending and receiving Hello packets and will set the wait timer. The router will attempt to identify the network's DR and BDR while in this state. DR. In this state, the router is the DR on the attached network and will establish adjacencies with the other routers on the multi-access network. Backup. In this state, the router is the BDR on the attached network and will establish adjacencies with the other routers on the multi-access network. DRother. In this state, the router is neither the DR nor the BDR on the attached network. It will form adjacencies only with the DR and BDR, although it will track all neighbors on the network. Loopback. In this state, the interface is looped back via software or hardware. Although packets cannot transit an interface in this state, the interface address is still advertised in router LSAs (described later) so that test packets can find their way to the interface. Figure 9.8 shows the OSPF interface states and the input events that will cause a state transition. The input events are described in Table 9.1 Figure 9-8. The OSPF interface state machine; see Table 9.1 for a description of input events (IEs). Table 9.1. Input events for the interface state machine.
OSPF NeighborsThe preceding section discussed a router's relationship with the attached network. Although a router's interaction with other routers was discussed in the context of electing DRs and BDRs, the purpose of the DR election process is still to establish a relationship with a network. This section discusses a router's relationship with the neighbors on the network. The ultimate purpose of the neighbor relationship is the formation of adjacencies over which to pass routing information. Note The phases of establishing an adjacency An adjacency is established in four general phases:
As previously discussed, neighbor relationships are established and maintained through the exchange of Hello packets. On broadcast and point-to-point network types, Hellos are multicast to AllSPFRouters (224.0.0.5). On NBMA, point-to-multipoint, and virtual link network types, Hellos are unicast to individual neighbors. The implication of unicasting is that the router must first learn of the existence of its neighbors either through manual configuration or an underlying mechanism such as Inverse ARP. The configuration of neighbors on these network types is covered in the appropriate sections. Hellos are sent every HelloInterval on every network type, with one exception: On NBMA networks, a router will send Hellos to neighbors whose neighbor state is down every PollInterval. On Cisco routers, the default PollInterval is 60 seconds. The Neighbor Data StructureAn OSPF router builds the Hello packets for each network using the information stored in the interface data structure of the attached interface. By sending the Hello packets containing this information, the router informs neighbors about itself. Likewise, for each neighbor the router will maintain a neighbor data structure consisting of the information learned from other routers' Hello packets. This two-way exchange of information with a neighbor can be thought of as a conversation. In Figure 9.9, the command show ip ospf neighbor is used to observe some of the information in the neighbor data structure for a single neighbor. [11]
Figure 9.9. An OSPF router describes each conversation with each neighbor by a neighbor data structure. Actually, the data structure records more information about each neighbor than is shown in the figure. The components of the neighbor data structure are as follows: Neighbor ID. The router ID of the neighbor. In Figure 9.9, the neighbor ID is 192.168.30.105. Neighbor IP Address. The IP address of the neighbor's interface attached to the network. When OSPF packets are unicasted to the neighbor, this address will be the destination address. In Figure 9.9, the neighbor's IP address is 192.168.16.41. Area ID. In order for two routers to become neighbors, the Area ID carried in a received Hello packet must match the Area ID of the receiving interface. The Area ID of the neighbor in Figure 9.9 is 0 (0.0.0.0). Interface. The interface attached to the network on which the neighbor is located. In Figure 9.9, the neighbor is reached via S0. Neighbor Priority. This component is the Router Priority of the neighbor, as advertised in the neighbor's Hello packets. The priority is used in the DR/BDR election process. The neighbor in Figure 9.9 has a priority of 1, the Cisco default. State. This component is the functional state of the neighbor, as described in the following section, "The Neighbor State Machine." The state of the neighbor in Figure 9.9 is Full. PollInterval. This value is recorded only for neighbors on NBMA networks. Because neighbors may not be automatically discovered on NBMA networks, if the neighbor state is Down, a Hello will be sent to the neighbor every PollInterval ”some period longer than the HelloInterval. The neighbor in Figure 9.9 is on an NBMA network, as indicated by the default Cisco PollInterval of 60 seconds. Neighbor Options. The optional OSPF capabilities supported by the neighbor. Options are discussed in the section describing the Hello packet format. Inactivity Timer. A timer whose period is the RouterDeadInterval, as defined in the interface data structure. The timer is reset whenever a Hello is received from the neighbor. If the inactivity timer expires before a Hello is heard from the neighbor, the neighbor is declared Down. In Figure 9.9, the inactivity timer is shown as the Dead Timer and will expire in 100 seconds. Components of the neighbor data structure that are not displayed by the show ip ospf neighbor command are as follows: Designated Router. This address is included in the DR field of the neighbor's Hello packets. Backup Designated Router. This address is included in the BDR field of the neighbor's Hello packets. Master/Slave. The master/slave relationship, negotiated with neighbors in the ExStart state, establishes which neighbor will control the database synchronization. DD Sequence Number. The Sequence Number of the Database Description (DD) packet currently being sent to the neighbor. Last Received Database Description Packet. The Initialize, More, and Master bits; the options; and the sequence number of the last received database description packet are recorded. This information is used to determine whether the next DD packet is a duplicate. Link State Retransmission List. This component is a list of LSAs that have been flooded on the adjacency, but have not yet been acknowledged. The LSAs are retransmitted every RxmtInterval, as defined in the interface data structure, until they are acknowledged or until the adjacency is destroyed . Database Summary List. This component is the list of LSAs sent to the neighbor in Database Description packets during database synchronization. These LSAs make up the link state database when the router goes into exchange state. Link State Request List. This list records LSAs from the neighbor's Database Description packets which are more recent than the LSAs in the link state database. Link State Request packets are sent to the neighbor for copies of these LSAs; as the requested LSAs are received in Link State Update packets, the Request List is depleted. The Neighbor State MachineAn OSPF router will transition a neighbor (as described in the neighbor data structure) through several states before the neighbor is considered fully adjacent. Down. The initial state of a neighbor conversation indicates that no Hellos have been heard from the neighbor in the last RouterDeadInterval. Hellos are not sent to down neighbors unless those neighbors are on NBMA networks; in this case, Hellos are sent every PollInterval. If a neighbor transitions to the Down state from some higher state, the link state Retransmission List, Database Summary List, and link state request list are cleared. Attempt. This state applies only to neighbors on NBMA networks, where neighbors are manually configured. A DR-eligible router will transition a neighbor to the Attempt state when the interface to the neighbor first becomes Active or when the router is the DR or BDR. A router will send packets to a neighbor in Attempt state at the HelloInterval instead of the PollInterval. Init. This state indicates that a Hello packet has been seen from the neighbor in the last RouterDeadInterval, but 2-Way communication has not yet been established. A router will include the Router IDs of all neighbors in this state or higher in the Neighbor field of the Hello packets. 2-Way. This state indicates that the router has seen its own Router ID in the Neighbor field of the neighbor's Hello packets, which means that a bidirectional conversation has been established. On multi-access networks, neighbors must be in this state or higher to be eligible to be elected as the DR or BDR. The reception of a Database Description packet from a neighbor in the init state will also cause a transition to 2-Way. ExStart. In this state, the router and its neighbor establish a master/slave relationship and determine the initial DD sequence number in preparation for the exchange of Database Description packets. The neighbor with the highest interface address becomes the master. Exchange. The router sends Database Description packets describing its entire link state database to neighbors that are in the Exchange state. The router may also send Link State Request packets, requesting more recent LSAs, to neighbors in this state. Loading. The router will send Link State Request packets to neighbors that are in the Loading state, requesting more recent LSAs that have been discovered in the Exchange state but have not yet been received. Full. Neighbors in this state are fully adjacent, and the adjacencies will appear in Router LSAs and Network LSAs. Figures 9.10 through 9.12 show the OSPF neighbor states and the input events that will cause a state transition. The input events are described in Table 9.2, and the decision points are defined in Table 9.3. Figure 9.10 shows the normal progression from the least functional state to the fully functional state, and Figure 9.11 and Figure 9.12 show the complete OSPF neighbor state machine. Figure 9.10. The normal series of transitions in the OSPF neighbor state machine which take a neighbor from Down to Full. Figure 9.11. The neighbor state machine, from Down to Init. Figure 9.12. The neighbor state machine, from Init to Full. Building an AdjacencyNeighbors on point-to-point, point-to-multipoint, and virtual link networks always become adjacent unless the parameters of their Hellos don't match. On broadcast and NBMA networks, the DR and BDR become adjacent with all neighbors, but no adjacencies will exist between DRothers. The adjacency building process uses three OSPF packet types:
Table 9.2. Input events for Figures 9.10, 9.11, and 9.12.
Table 9.3. Decision points for Figures 9.10 and 9.12.
The formats of these packet types are described in detail in a subsequent section, "OSPF Packet Formats." The Database Description packet is of particular importance to the adjacency building process. As the name implies, the packets carry a summary description of each LSA in the originating router's link state database. These descriptions are not the complete LSAs, but merely their headers ”enough information for the receiving router to decide whether it has the latest copy of the LSA in its own database. In addition, three flags in the DD packet are used to manage the adjacency building process:
When the master/slave negotiation begins in the ExStart state, both neighbors will claim to be the master by sending an empty DD packet with the MS-bit set to one. The DD sequence number in these two packets will be set to the originating router's idea of what the sequence number should be. The neighbor with the lower Router ID will become the slave and will reply with a DD packet in which the MS-bit is zero and the DD sequence number is set to the master's sequence number. This DD packet will be the first packet populated with LSA summaries. When the master/slave negotiation is completed, the neighbor state will transition to Exchange. In the Exchange state, the neighbors will synchronize their link state databases by describing all entries in their respective link state databases. The Database Summary List is populated with the headers of all LSAs in the router's database; Database Description packets containing the listed LSA headers are sent to the neighbor. If either router sees that its neighbor has an LSA that is not in its own database, or that the neighbor has a more recent copy of a known LSA, it places the LSA on the Link State Request list. It then sends a Link State Request packet asking for a complete copy of the LSA in question. Link State Update packets convey the requested LSAs. As the requested LSAs are received, they are removed from the Link State Request list. All LSAs sent in Update packets must be individually acknowledged. Therefore, the transmitted LSAs are entered into the Link State Retransmission list. As they are acknowledged, they are removed from the list. The LSA may be acknowledged by one of two means:
The master controls the synchronization process and ensures that only one DD packet is outstanding at a time. When the slave receives a DD packet from the master, the slave acknowledges the packet by sending a DD packet with the same sequence number. If the master does not receive an acknowledgment of an outstanding DD packet within the RxmtInterval, as specified in the interface data structure, the master will send a new copy of the packet. The slave sends DD packets only in response to DD packets it receives from the master. If the received DD packet has a new sequence number, the slave sends a DD packet with the same sequence number. If the received sequence number is the same as a previously acknowledged DD packet, the acknowledging packet is re-sent. When the database synchronization process is complete, one of two state transitions will occur:
The master knows that the synchronization process is complete when it has sent all the DD packets necessary to fully describe its link state database and has received a DD packet with the M-bit set to zero. The slave knows that the process is complete when it receives a DD packet with the M-bit set to zero and sends an acknowledging DD packet that also has its M-bit set to zero (that is, the slave has fully described its own database). Because the slave must acknowledge each received DD packet, the slave will always be the first to know that the synchronization process is complete. Figure 9.13 shows the adjacency building process. This example is taken directly from RFC 2328. Figure 9.13. The link state database synchronization process and associated neighbor states. The following steps are illustrated in Figure 9.13:
Note that if either router has entries in its Link State Request list, it does not need to wait for the Loading state to send Link State Request packets; it may do so while the neighbor is still in the Exchange state. Consequently, the synchronization process is not as tidy as depicted in Figure 9.13, but it is more efficient. Figure 9.14 shows an analyzer capture of an adjacency being built between two routers. Although Link State Request and Link State Update packets are being sent while both neighbors are still in the Exchange state, attention to the I-, M-, and MS-bits and the sequence numbers reveals that the real-life process follows the generic procedure of Figure 9.13. Figure 9.14. This analyzer capture shows an adjacency being built. In Figure 9.15, the output of the command debug ip ospf adj shows the adjacency of Figure 9.14 being built from the perspective of one of the routers (router ID 192.168.30.175). Figure 9.15. This debug output shows the adjacency events of Figure 9.14 from the perspective of one of the routers. At the end of the synchronization process in Figure 9.14, a series of Link State Update and Link State Acknowledgment packets can be observed. These are part of the LSA flooding process, discussed in the next section. FloodingThe entire OSPF topology may be depicted as a group of routers, or nodes, interconnected not by physical links but by logical adjacencies (Figure 9.16). For the nodes to route properly over this logical topology, each node must possess an identical map of the topology. This map is the topological database. Figure 9.16. A group of routers interconnected by data links will be viewed by OSPF as a group of nodes interconnected by adjacencies. The OSPF topological database is better known as the link state database. This database consists of all the LSAs the router has received. A change in the topology is represented as a change in one or more of the LSAs. Flooding is the process by which these changed or new LSAs are sent throughout the network, to ensure that the database of every node is updated and remains identical to all other nodes' databases. Flooding makes use of the following two OSPF packet types:
As Figure 9.17 shows, each Link State Update and Acknowledgment packet may carry multiple LSAs. Although the LSAs themselves are flooded throughout the internetwork, the Update and Acknowledgment packets travel only between two nodes across an adjacency. Figure 9.17. LSAs are sent across adjacencies within link state update packets. On point-to-point networks, updates are sent to the multicast address AllSPFRouters (224.0.0.5). On point-to-multipoint and virtual link networks, updates are unicasted to the interface addresses of the adjacent neighbors. On broadcast networks, DRothers form adjacencies only with the DR and BDR. Therefore, updates are sent to the address AllDRouters (224.0.0.6). The DR in turn multicasts an Update packets containing the LSA to all adjacent routers on the network using the address AllSPFRouters. All routers then flood the LSA out all other interfaces (Figure 9.18). Although the BDR hears and records LSAs multicast from DRothers, it will not reflood or acknowledge them unless the DR fails to do so. The same DR/BDR functionality exists on NBMA networks, except that LSAs are unicast from DRothers to the DR and BDR, and the DR unicasts a copy of the LSA to all adjacent neighbors. Figure 9.18. On a broadcast network, a DRother sends an LSA only to the DR and BDR (a); the DR refloods the LSA to all adjacent neighbors (b); all routers then flood the LSA on all other interfaces (c). Because identical link state databases are essential to correct OSPF operation, flooding must be reliable. Transmitting routers must know that their LSAs were received successfully, and receiving routers must know that they are accepting the correct LSAs. Reliable Flooding: AcknowledgmentsEach individual transmitted LSA must be acknowledged. This may be accomplished by either an implicit acknowledgment or an explicit acknowledgment. Note Implicit acknowledgment A neighbor can implicitly acknowledge the receipt of an LSA by including a duplicate of the LSA in an update back to the originator. Implicit acknowledgments are more efficient than explicit acknowledgments in some situations, for instance, when the neighbor was intending to send an update to the originator anyway. Note Explicit acknowledgment A neighbor explicitly acknowledges the receipt of an LSA by sending a Link State Acknowledgment packet. A single Link State Acknowledgment packet is capable of acknowledging multiple LSAs. The packet carries only LSA headers ”enough to completely identify the LSA ”not the complete LSA. When a router first sends an LSA, a copy of the LSA is entered into the Link State Retransmission list of every neighbor to which it was sent. The LSA is retransmitted every RxmtInterval until it is acknowledged or until the adjacency is broken. The Link State Update packets containing retransmissions are always unicast, regardless of the network type. Note Delayed acknowledgments Acknowledgments may be either delayed or direct . By delaying an acknowledgment, more LSAs can be acknowledged in a single Link State Acknowledgment packet; on a broadcast network, LSAs from multiple neighbors can be acknowledged in a single multicast Link State Acknowledgment packet. The period by which an acknowledgment is delayed must be less than the RxmtInterval to prevent unnecessary retransmissions. Under normal circumstances, the unicast/multicast addressing conventions used for Link State Update packets on various network types also apply to Link State Acknowledgments. Direct acknowledgments are always sent immediately and are always unicast. Direct acknowledgments are sent whenever the following conditions occur: Note Direct acknowledgments
Reliable Flooding: Sequencing, Checksums, and AgingEach LSA contains three values that are used to ensure that the most recent copy of the LSA exists in every database. These values are sequence number, checksum, and age. OSPF uses a linear sequence number space (discussed in Chapter 4, "Dynamic Routing Protocols" ) and 32-bit signed sequence numbers ranging from InitialSequenceNumber (0x80000001) to MaxSequenceNumber (0x7fffffff). When a router originates an LSA, the router sets the LSA's sequence number to InitialSequenceNumber. Each time the router produces a new instance of the LSA, the router increments the sequence number by one. Note Sequence number If the present sequence number is MaxSequenceNumber and a new instance of the LSA must be created, the router must first flush the old LSA from all databases. This is done by setting the age of the existing LSA to MaxAge (defined later in this section) and reflooding it over all adjacencies. As soon as all adjacent neighbors have acknowledged the prematurely aged LSA, the new instance of the LSA with a sequence number of InitialSequenceNumber may be flooded. The checksum is a 16-bit integer calculated using a Fletcher algorithm. [12] The checksum is calculated over the entire LSA with the exception of the Age field (which changes as the LSA passes from node to node and would therefore require recalculation of the checksum at each node). The checksum of each LSA is also verified every five minutes as it resides in the link state database, to ensure that it has not been corrupted in the database.
Note Checksum The age is an unsigned 16-bit integer that indicates the age of the LSA in seconds. The range is 0 to 3600 (1 hour , known as MaxAge). When a router originates an LSA, the router sets the age to 0. As the flooded LSA transits a router, the age is incremented by a number of seconds specified by InfTransDelay. Cisco routers have a default InfTransDelay of 1 second, which can be changed with the command ip ospf transmit-delay . The age is also incremented as it resides in the database. Note MaxAge When an LSA reaches MaxAge, the LSA is reflooded and then flushed from the database. When a router needs to flush an LSA from all databases, it prematurely sets the age to MaxAge and refloods it. Only the router that originated the LSA can prematurely age it. Figure 9.19 shows a portion of a link state database; the age, sequence number, and checksum of each LSA can be observed. More detailed discussion of the database and the various LSA types is in "The Link State Database," later in this chapter. Figure 9.19. The age, sequence number, and checksum for each LSA is recorded in the link state database. The age is incremented in seconds. When multiple instances of the same LSA are received, a router determines which is the most recent by the following algorithm:
AreasThe reader should by now have a good feel for why OSPF, with its multiple databases and complex algorithms, can put greater demands on the memory and processors of a router than the previously examined protocols can. As an internetwork grows, these demands can become significant or even crippling. And although flooding is more efficient than the periodic, full-table updates of RIP and IGRP, it can still place an unacceptable burden on the data links of a large internetwork. Contrary to popular belief, the SPF algorithm itself is not particularly processor intensive . It is the related processes, such as flooding and database maintenance, that burden the CPU. Note Benefits of areas OSPF uses areas to reduce these adverse effects. In the context of OSPF, an area is a logical grouping of OSPF routers and links that effectively divide an OSPF domain into sub-domains (Figure 9.20). Routers within an area will have no detailed knowledge of the topology outside of their area. Because of this condition:
Figure 9.20. An OSPF area is a logical grouping of OSPF routers. Each area is described by its own link state database, and each router must maintain a database only for the area to which it belongs. Note Area ID Areas are identified by a 32-bit Area ID . As Figure 9.20 shows, the Area ID may be expressed either as a decimal number or in dotted decimal, and the two formats may be used together on Cisco routers. The choice usually depends on which format is more convenient for identifying the particular Area ID. For example , area 0 and area 0.0.0.0 are equivalent, as are area 16 and area 0.0.0.16, and area 271 and area 0.0.1.15. In each of these cases, the decimal format would probably be preferred. However, given the choice of area 3232243229 and area 192.168.30.29, the latter would probably be chosen. Note Classifying traffic in relation to areas Three types of traffic may be defined in relation to areas:
Note Backbone Area ID 0 (or 0.0.0.0) is reserved for the backbone. The backbone is responsible for summarizing the topographies of each area to every other area. For this reason, all inter-area traffic must pass through the backbone; non-backbone areas cannot exchange packets directly. Another special type of area is the stub area . Because stub areas cannot be sufficiently explained without first describing the various types of LSAs, this subject will be addressed in the section "The Link State Database." Many OSPF designers have a favorite rule of thumb concerning the maximum number of routers that an area can handle. This number might range from 30 to 200. However, the number of routers has little actual bearing on the maximum size of an area. Far more important factors include the number of links in an area, the stability of the topology, the memory and horsepower of the routers, the use of summarization, and the number of summary LSAs entering the area. Because of these factors, 25 routers may be too many for some areas, and other areas may accommodate well over 500 routers. It is perfectly reasonable to design a small OSPF internetwork with only a single area. Regardless of number of areas, a potential problem arises when an area is so underpopulated that no redundant links exist within it. If such an area becomes partitioned, service disruptions may occur. Partitioned areas are discussed in more detail in a later section. Router TypesRouters, like traffic, can be categorized in relation to areas. All OSPF routers will be one of four router types, as shown in Figure 9.21. Figure 9.21. All OSPF routers can be classified as an Internal Router, a Backbone Router, an Area Border Router (ABR), or an Autonomous System Boundary Router (ASBR). Note that any of the first three router types may also be an ASBR. Internal Routers are routers whose interfaces all belong to the same area. These routers have a single link state database. Area Border Routers (ABRs) connect one or more areas to the backbone and act as a gateway for inter-area traffic. An ABR always has at least one interface that belongs to the backbone, and must maintain a separate link state database for each of its connected areas. For this reason, ABRs often have more memory and perhaps more powerful processors than internal routers. An ABR will summarize the topological information of its attached areas into the backbone, which will then propagate the summary information to the other areas. Backbone Routers are routers with at least one interface attached to the backbone. Although this requirement means that ABRs are also Backbone Routers, Figure 9.21 shows that not all Backbone Routers are ABRs. An Internal Router whose interfaces all belong to area 0 is also a Backbone Router. Autonomous System Boundary Routers (ASBRs) are gateways for external traffic, injecting routes into the OSPF domain that were learned (redistributed) from some other protocol, such as the BGP and EIGRP processes shown in Figure 9.21. An ASBR can be located anywhere within the OSPF autonomous system; it may be an Internal, Backbone , or ABR. Partitioned AreasA partitioned area is an area in which a link failure causes one part of the area to become isolated from another. If a non-backbone area becomes partitioned and if all routers on either side of the partition can still find an ABR, as in Figure 9.22, no service disruptions will occur. The backbone will merely treat the partitioned area as two separate areas. Intra-area traffic from one side of the partition to the other side will become inter-area traffic, passing through the backbone to circumvent the partition. Note that a partitioned area is not the same as an isolated area, in which no path exists to the rest of the internetwork. Figure 9.22. (a) Area 3 is connected to the backbone (area 0) by two ABRs. (b) A link failure in area 3 creates a partitioned area, but all routers within area 3 can still reach an ABR. In these circumstances, traffic can still be routed between the two sides of the partitioned area. Note Partitioned areas versus isolated areas A partition of the backbone itself is a more serious matter. As Figure 9.23 shows, a partitioned backbone area will isolate the areas on each side of the partition, creating two separate OSPF domains. Figure 9.23. If a backbone becomes partitioned, each side of the partition and any connected areas become isolated from the other side. Figure 9.24 shows some better area designs. Both area 0 and area 2 are designed so that neither of them can be partitioned by a single link failure. The vulnerability of area 2, however, is that if the ABR fails, the area will be isolated. Area 3 uses two ABRs; here, neither a single link failure nor a single ABR failure will isolate any part of the area. Figure 9.24. In areas 0 and 2, no single link failure can partition the area. In area 3, no single ABR or link failure can isolate the area. Virtual LinksA virtual link is a link to the backbone through a non-backbone area. Virtual links are used for the following purposes:
Figure 9.25. A virtual link connects area 23 to the backbone through area 12. Figure 9.26. A virtual link reconnects a partitioned backbone through a nonbackbone area. In both examples, the virtual link is not associated with a particular physical link. The virtual link is a tunnel through which packets may be routed on the optimal path from one endpoint to the other. Several rules are associated with the configuration of virtual links:
As mentioned previously, OSPF classifies a virtual link as a network type. Specifically , the link is considered an unnumbered ”that is, unaddressed ”link, belonging to the backbone, between two ABRs. These ABRs are considered neighbors by virtue of the virtual link between them, although they are not linked physically. Within each ABR, the virtual link will transition to the fully functional point-to-point interface state when a route to the neighboring ABR is found in the route table. The cost of the link is the cost of the route to the neighbor. When the interface state becomes point-to-point, an adjacency will be established across the virtual link. Virtual links add a layer of complexity and troubleshooting difficulty to any internetwork. It is best to avoid the need for them by ensuring that areas, particularly backbone areas, are designed with redundant links to prevent partitioning. When two or more internetworks are merged, sufficient planning should take place beforehand so that no area is left without a direct link to the backbone. If a virtual link is configured, it should be used only as a temporary fix to an unavoidable topology problem. A virtual link is a flag marking a part of the internetwork that needs to be reengineered. Permanent virtual links are virtually always a sign of a poorly designed internetwork. The Link State DatabaseAll valid LSAs received by a router are stored in its link state database. The collected LSAs will describe a graph of the area topology. Because each router in an area calculates its shortest path tree from this database, it is imperative for accurate routing that all area databases are identical. A list of the LSAs in a link state database can be observed with the command show ip ospf database , as shown in Figure 9.27. This list does not show all of the information stored for each LSA, but shows only the information in the LSA header. Note that this database contains LSAs from multiple areas, indicating that the router is an ABR. Figure 9.27. The command show ip ospf database displays a list of all LSAs in the link state database. Most of the entries in Figure 9.27 have been deleted for brevity; the actual link state database contains 1,445 entries and four areas, as shown in Figure 9.28. Figure 9.28. The command show ip ospf database database-summary displays the number of LSAs in a link state database by area and by LSA type. As mentioned earlier in "Reliable Flooding: Sequencing, Checksums, and Aging," the LSAs are aged as they reside in the link state database. If they reach MaxAge (1 hour), they are flushed from the OSPF domain. The implication here is that there must be a mechanism for preventing legitimate LSAs from reaching MaxAge and being flushed. This mechanism is the link state refresh . Every 30 minutes, known as the LSRefreshTime, the router that originated the LSA will flood a new copy of the LSA with an incremented sequence number and an age of zero. Upon receipt, the other OSPF routers will replace the old copy of the LSA and begin aging the new copy. So the link state refresh process can be thought of as a keepalive for each LSA. An additional benefit is that any LSAs that might have become corrupted in a router's LS database will be replaced with the refreshed copy of the legitimate LSA. The idea behind associating an individual refresh timer with each LSA is that the LSRefreshTime of the LSAs will not expire all at once, reflooding all LSAs every 30 minutes. Instead, the reflooding will be spread out in a semirandom pattern. The problem with this approach is that with each individual LSA being reflooded as its LSRefreshTime expires, bandwidth is used inefficiently. Update packets can be transmitted with only a few, or even a single, LSA. Prior to IOS 11.3, Cisco chose to have a single LSRefreshTime associated with the entire LS database. Every 30 minutes, each router refreshes all of the LSAs it originated , regardless of their actual age. Although this strategy avoids the problem of inefficiency, it reintroduces the problem the individual refresh timers were meant to solve. If the LS database is large, each router can create spikes in the area traffic and CPU usage every half hour. Note LSA group pacing IOS 11.3AA introduced a mechanism known as LSA group pacing to reach a compromise between the problems of individual refresh timers and a single monolithic timer. Each LSA has its own refresh timer, but as the individual refresh timers expire, a delay is introduced before the LSAs are flooded. By delaying the refresh, more LSAs can be grouped together before being flooded, so that Update packets are carrying a larger number of LSAs. By default, the group-pacing interval is 240 seconds (4 minutes), and it can be changed with the command timers lsa-group-pacing . If the database is very large, decreasing the group pacing interval is beneficial; if the database is small, increasing the interval can be useful. The range of the group pacing timer is 10 to 1800 seconds. LSA TypesBecause of the multiple router types defined by OSPF, multiple types of LSA are also necessary. For example, a DR must advertise the multi-access link and all the routers attached to the link. Other router types would not advertise this type of information. Both Figure 9.27 and Figure 9.28 show that there are multiple types of LSA. Each type describes a different aspect of an OSPF internetwork. Table 9.4 lists the LSA types and the type codes that identify them. Table 9.4. LSA types.
Router LSAs are produced by every router (Figure 9.29). This most fundamental LSA lists all of a router's links, or interfaces, along with the state and outgoing cost of each link. These LSAs are flooded only within the area in which they are originated. The command show ip ospf database router will list all of the Router LSAs in a database. Figure 9.30 shows a variant of the command , in which a single router LSA is observed by specifying the router's ID. As this and the subsequent illustrations show, the complete LSA is recorded in the link state database. For a description of all the LSA fields, see the "OSPF Packet Formats" section later in this chapter. Figure 9.29. The Router LSA describes all of a router's interfaces. Figure 9.30. The command show ip ospf database router displays Router LSAs from the link state database. Network LSAs are produced by the DR on every multi-access network (Figure 9.31). As discussed earlier, the DR represents the multi-access network and all attached routers as a "pseudonode," or a single virtual router. In this sense, a Network LSA represents a pseudonode just as a Router LSA represents a single physical router. The Network LSA lists all attached routers, including the DR itself. Like Router LSAs, network LSAs are flooded only within the originating area . In Figure 9.31, the command show ip ospf database network is used to observe a Network LSA. Figure 9.31. A DR originates a network LSA to represent a multi-access network and all attached routers. Figure 9.32. Network LSAs can be observed with the command show ip ospf database network. Network Summary LSAs are originated by ABRs. They are sent into a single area to advertise destinations outside that area (Figure 9.33). In effect, these LSAs are the means by which an ABR tells the Internal Routers of an attached area what destinations the ABR can reach. An ABR also advertises the destinations within its attached areas into the backbone with Network Summary LSAs. Default routes external to the area but internal to the OSPF autonomous system are also advertised by this LSA type. The command show ip ospf database summary is used to display the network summary LSAs in the database, as shown in Figure 9.34. Figure 9.33. An ABR will originate a Network Summary LSA to describe inter-area destinations. Figure 9.34. Network Summary LSAs can be observed with the command show ip ospf database summary. When an ABR originates a Network Summary LSA, it includes the cost from itself to the destination the LSA is advertising. The ABR will originate only a single Network Summary LSA for each destination even if it knows of multiple routes to the destination. Therefore, if an ABR knows of multiple routes to a destination within its own attached area, it originates a single Network Summary LSA into the backbone with the lowest cost of the multiple routes. Likewise, if an ABR receives multiple Network Summary LSAs from other ABRs across the backbone, the original ABR will choose the lowest cost advertised in the LSAs and advertise that one cost into its attached non-backbone areas. When another router receives a Network Summary LSA from an ABR, it does not run the SPF algorithm. Rather, it simply adds the cost of the route to the ABR and the cost included in the LSA. A route to the advertised destination, via the ABR, is entered into the route table along with the calculated cost. This behavior ”depending on an intermediate router instead of determining the full route to the destination ”is distance vector behavior. So, while OSPF is a link state protocol within an area, it uses a distance vector algorithm to find inter-area routes. [13]
ASBR Summary LSAs are also originated by ABRs. ASBR Summary LSAs are identical to Network Summary LSAs except that the destination they advertise is an ASBR (Figure 9.35), not a network. The command show ip ospf database asbr-summary is used to display ASBR Summary LSAs (Figure 9.36). Note in the illustration that the destination is a host address, and the mask is zero; the destination advertised by an ASBR Summary LSA will always be a host address because it is a route to a router. Figure 9.35. ASBR summary LSAs advertise routes to ASBRs. Figure 9.36. ASBR Summary LSAs can be observed with the command show ip ospf database asbr-summary. Autonomous System External LSAs , or External LSAs , are originated by ASBRs and advertise either a destination external to the OSPF autonomous system, or a default route [14] external to the OSPF autonomous system (Figure 9.37). Referring back to Figure 9.27, you can see that the AS External LSAs are the only LSA types in the database that are not associated with a particular area; external LSAs are flooded throughout the autonomous system. The command show ip ospf data base external displays AS External LSAs (Figure 9.38).
Figure 9.37. AS External LSAs advertise destinations external to the OSPF autonomous system. Figure 9.38. AS External LSAs can be observed with the command show ip ospf database external. Group Membership LSAs are used in an enhancement of OSPF known as Multicast OSPF (MOSPF). [15] MOSPF routes packets from a single source to multiple destinations, or group members , which share a class D multicast address. Although Cisco supports other multicast routing protocols, MOSPF is not supported as of this writing. For this reason, neither MOSPF nor the Group Membership LSA is covered in this book.
NSSA External LSAs are originated by ASBRs within not-so-stubby areas (NSSAs). NSSAs are described in the following section. An NSSA External LSA is almost identical to an AS External LSA, as the section on OSPF packet formats shows. Unlike AS External LSAs, which are flooded throughout an OSPF autonomous system, NSSA external LSAs are flooded only within the not-so-stubby area in which it was originated. The command show ip ospf database nssa-external displays NSSA external LSAs (Figure 9.39). Figure 9.39. NSSA external LSAs can be observed with the command show ip ospf database nssa-external. External Attributes LSAs are proposed as an alternative to running Internal BGP (iBGP) in order to transport BGP information across an OSPF domain. As of this writing, type 8 LSAs have not yet been implemented, and no RFC or Internet draft has been published yet on the subject. Opaque LSAs are a proposed class of LSAs that consist of a standard LSA header followed by application-specific information. [16] The Information field can be used directly by OSPF or indirectly by other applications to distribute information throughout the OSPF domain. As of this writing, Opaque LSAs have not been deployed.
Stub AreasAn ASBR learning external destinations will advertise those destinations by flooding AS External LSAs throughout the OSPF autonomous system. In many cases, these External LSAs may make up a large percentage of the LSAs in the databases of every router. For example, Figure 9.28 shows that 580 of the LSAs in that database ”40% ”are external LSAs. In Figure 9.40, not every router needs to know about all the external destinations. The routers in area 2 must send a packet to an ABR to reach the ASBR, no matter what the external destination may be. For this reason, area 2 can be configured as a stub area . Figure 9.40. Memory can be conserved and performance improved by making area 2 a stub area. A stub area is an area into which AS External LSAs are not flooded. And if type 5 LSAs are not known inside an area, type 4 LSAs are unnecessary; these LSAs are also blocked. ABRs at the edge of a stub area will use Network Summary LSAs to advertise a single default route (destination 0.0.0.0) into the area. Any destination that the Internal Routers cannot match to an intra- or inter-area route will match the default route. Because the default route is carried in type 3 LSAs, it will not be advertised outside of the area. The performance of routers within a stub area can be improved, and memory conserved, by the reduced size of their databases. Of course, the improvement will be more marked in internetworks with a large number of type 5 LSAs. There are, however, four restrictions on stub areas: Note Restrictions on stub areas
Totally Stubby AreasIf memory is saved by blocking the propagation of type 5 and type 4 LSAs into an area, wouldn't more memory be saved by blocking type 3 LSAs? In addressing this question, Cisco carries the concept of stub areas to its logical conclusion with a scheme known as totally stubby areas . Totally stubby areas use a default route to reach not only destinations external to the autonomous system but also all destinations external to the area. The ABR of a totally stubby area will block not only AS External LSAs but also all Summary LSAs ”with the exception of a single type 3 LSA to advertise the default route. Not-So-Stubby AreasIn Figure 9.41, a router with a few stub networks must be attached to the OSPF internetwork via one of the area 2 routers. The router supports only RIP, so the area 2 router will run RIP and redistribute the networks into OSPF. Unfortunately, this configuration makes the area 2 router an ASBR, and therefore area 2 can no longer be a stub area. Figure 9.41. Because a few external destinations must be redistributed into OSPF at one of the area 2 routers, all of area 2 is ineligible to be a stub area. The RIP speaker does not need to learn routes from OSPF ”a default route pointing to the area 2 router is all it needs. But all OSPF routers must know about the networks attached to the RIP router to route packets to them. Not-so-stubby areas (NSSAs) [17] allow external routes to be advertised into the OSPF autonomous system while retaining the characteristics of a stub area to the rest of the autonomous system. To do this, the ASBR in an NSSA will originate type 7 LSAs to advertise the external destinations. These NSSA External LSAs are flooded throughout the NSSA but are blocked at the ABR.
The NSSA External LSA has a flag in its header known as the P-bit. The NSSA ASBR has the option of setting or clearing the P-bit. If the NSSA's ABR receives a type 7 LSA with the P-bit set to one, it will translate the type 7 LSA into a type 5 LSA and flood it throughout the other areas (see Figure 9.42). If the P-bit is set to zero, no translation will take place and the destination in the type 7 LSA will not be advertised outside of the NSSA. Figure 9.42. An ASBR within an NSSA will originate NSSA External LSAs. If the P-bit of an NSSA External LSA is set, the ABR will translate the LSA into an AS External LSA. NSSAs are supported in IOS 11.2 and later. Table 9.5 summarizes which LSAs are allowed in which areas. Table 9.5. LSA types allowed per area type.
The Route TableThe Dijkstra algorithm is used to calculate the Shortest Path Tree from the LSAs in the link state database. Chapter 4 has a somewhat detailed discussion of the Dijkstra algorithm; for a full description of the OSPF calculation of the SPF tree, see section 16.1 of RFC 2328. The SPF algorithm is run once to build the branches of the tree, which are the links to each node (router) in the area. The algorithm is then run a second time to add the leaves to the tree ”the stub networks attached to each router. Note Cisco default cost OPSF determines the shortest path based on an arbitrary metric called cost , which is assigned to each interface. The cost of a route is the sum of the costs of all the outgoing interfaces to a destination. RFC 2328 does not specify any values for cost. Cisco routers calculate a default OSPF cost as 10 8 /BW, where BW is the configured bandwidth of the interface. Fractional costs are rounded down to the nearest whole number. The cost of an interface may be changed with the command ip ospf cost . LSAs record cost in a 16-bit field, so the total cost of an interface can range from 1 to 65535. Table 9.6 shows the default costs for some typical interfaces. Table 9.6. Cisco default interface costs.
Destination TypesEach route entry will be classified according to a destination type . The destination type will be either network or router . Network entries are the addresses of networks to which packets can be routed. These are the destinations that are entered into the route table (Figure 9.43). Figure 9.43. The OSPF entries in the route table are network destination types. Router entries are routes to ABRs and ASBRs. If a router needs to send a packet to an inter-area destination, it must know how to find an ABR; if a packet must go to an external destination , the router must know how to find an ASBR. Router entries contain this information, and are kept in a separate, internal route table. This table can be observed with the command show ip ospf border-routers (Figure 9.44). Figure 9.44. Router entries, kept in a separate table from network entries, are routes to ABRs and ASBRs. As Figure 9.44 shows, the internal route table looks very similar to any other route table ”there are destinations, metrics, next-hop addresses, and exit interfaces. The difference is that all destinations are the Router IDs of ABRs and ASBRs. Each entry is tagged as intra-area (i) or inter-area (I), and the entry indicates whether the destination is an ABR, an ASBR, or both. The area is recorded, as is the iteration of the SPF algorithm that installed th e entry. Path TypesEach route to a network destination will also be classified as one of four path types . These path types are intra-area, inter-area, type 1 external, and type 2 external. Intra-area paths are to destinations within one of the router's attached areas. Inter-area paths are to destinations in another area but within the OSPF autonomous system. An inter-area path, tagged with an IA in Figure 9.43, will always pass through at least one ABR. Type 1 external paths (E1 in Figure 9.43) are to destinations outside the OSPF autonomous system. When an external route is redistributed into any autonomous system, it must be assigned a metric that is meaningful to the routing protocol of the autonomous system. Within OSPF, the ASBR is responsible for assigning a cost to the external routes they advertise. Type 1 external paths have a cost that is the sum of this external cost plus the cost of the path to the ASBR. Configuring an ASBR to advertise an external (redistributed) route with an E1 metric is covered in Chapter 11, "Route Redistribution." Type 2 external paths (E2) are also to destinations outside the OSPF autonomous system, but do not take into account the cost of the path to the ASBR. E2 routes provide the network administrator with the option of telling OSPF to consider only the external cost of an external route, disregarding the internal cost of reaching the ASBR. OSPF external routes are, by default, E2 paths. In Figure 9.45, router A has two paths to external destination 10.1.2.0. If the destination is advertised as E1, the A-B-D path will have a cost of 35 (5 + 20 + 10) and will be preferred over the A-C-D path whose cost is 50 (30 + 10 + 10). If the destination is advertised as E2, the cost of the two internal links to the ASBRs will be disregarded. In this case, the A-B-D path has a cost of 30 (20 + 10) and the A-C-D path has a cost of 20 (10 + 10). The latter will be the preferred path. Figure 9.45. If the route to external network 10.1.2.0 is advertised with an E1 metric, router A will choose B as the " closest " ASBR. If the destination is advertised with an E2 metric, C will be chosen as the ASBR. Route Table LookupsWhen an OSPF router examines the destination address of a packet, it takes the following steps to select the best route: [18]
Note Cisco's OSPF performs equal-cost load balancing If multiple equal-cost, equal-path-type routes exist in the final set, OSPF will utilize them. By default, Cisco's OSPF implementation will load balance over a maximum of four equal-cost paths; this number may be changed within the range of one to six with the command maximum-paths . AuthenticationOSPF has the capability of authenticating all packets exchanged between neighbors. Authentication may be by simple passwords or by MD5 cryptographic checksums. These authentication methods are discussed in Chapter 7, "Routing Information Protocol Version 2," and examples of configuring OSPF authentication are given in the configuration section. OSPF over Demand CircuitsOSPF sends Hellos every 10 seconds and refreshes its LSAs every 30 minutes. These functions maintain the neighbor relationships, ensure that the link state databases are accurate, and use far less bandwidth than RIP or IGRP. However, even this minimal traffic is undesirable on demand circuits ”usage-sensitive connections such as X.25 SVCs, ISDN, and dialup lines. The recurring charges for such links may be determined by connect time or traffic volume or both, thus motivating the network manager to minimize their uptime. An enhancement that makes OSPF practical over demand circuits is the capability of suppressing the Hello and LSA refresh functions so that a link does not have to be constantly up. [19] Although this enhancement is designed specifically for usage-sensitive circuits, it may be useful on any bandwidth-limited link. [20] OSPF over demand circuits is supported in IOS 11.2 and later.
OSPF over demand circuits will bring up a demand link to perform the initial database synchronization and will subsequently bring up the link to flood only LSAs in which certain changes have occurred. These changes are:
Because no periodic Hellos are exchanged (Hellos are used only to bring up the link), OSPF must make a presumption of reachability . That is, it must presume that the demand circuit will be available when needed. In some instances, however, the link may not be immediately accessible. For example, a dialup link may be in use, both B channels of a BRI link may be in use, or the maximum number of allowed X.25 SVCs may already be up. In these situations, where the link is unavailable not because it is down but because of normal operational characteristics, the link is oversubscribed . OSPF will not report an oversubscribed demand link as down, and packets routed to an oversubscribed link will be dropped rather than being queued. This behavior makes sense because there is no way to predict when the link will again become available; a stream of packets to an unavailable interface could overflow the buffers. Several changes to the interface and neighbor state machines and to the flooding procedure must be made to support OSPF over demand circuits (see RFC 1793 for more details). Within the LSA format, two changes are made. First, if LSAs are not periodically refreshed across a demand circuit, no routers on the other side of the link should declare the LSA invalid after MaxAge. The semantics of the LSA's Age field are changed to accomplish this by designating the high bit as the DoNotAge bit. When an LSA is flooded over a demand circuit, the transmitting router will set DoNotAge = 1. As the LSA is flooded to all routers on the other side of the link, the Age field will be incremented normally by InfTransDelay seconds. [21] However, after being installed in a database, an LSA will not be aged like the other LSAs.
The second change derives from the first change. Because all routers must be capable of correctly interpreting the DoNotAge bit, a new flag known as the Demand Circuit bit (DC-bit) is added to all LSAs. By setting this flag in all LSAs it originates, a router signals to the other routers that it is capable of supporting OSPF over demand circuits. OSPF Packet FormatsThe OSPF packet consists of multiple encapsulations , and deconstructing one is like peeling an onion. As shown in Figure 9.46, the outside of the onion is the IP header. Cisco's maximum OSPF packet size is 1500 octets. Encapsulated within the IP header is one of five OSPF packet types. Each packet type begins with an OSPF packet header, whose format is the same for all packet types. The OSPF packet data following the header varies according to the packet type. Each packet type will have a number of type-specific fields, followed by more data. The data contained in a Hello packet will be a list of neighbors. LS Request packets will contain a series of fields describing the requested LSAs. LS Update packets will contain a list of LSAs, as shown in Figure 9.46. These LSAs in turn have their own headers and type-specific data fields. Database Description and LS Acknowledgment packets will contain a list of LSA headers. Figure 9.46. An OSPF packet is composed of a series of encapsulations. Note that OSPF packets are exchanged only between neighbors on a network. They are never routed beyond the network on which they originate. Figure 9.47 shows an analyzer capture of an IP header for a packet carrying OSPF data, indicated by the protocol number of 89. OSPF packets are sent with a TTL of 1, as can be seen here. Since an OSPF packet should never be routed past an immediate neighbor, setting the TTL to 1 helps to ensure that the packet never travels more than a single hop. Some routers run processes that prioritize packets according to the Precedence bits (Weighted Fair Queuing and Weighted Random Early Detection, for example). OSPF sets the Precedence bits to Internetwork Control (110b), as shown in Figure 9.47, so that these processes will give a high priority to OSPF packets. Figure 9.47. OSPF uses a protocol number of 89. It also sets the TTL value in the IP header to 1 and the Precedence bits to Internetwork Control. This section details the five OSPF packet types, beginning with the header. The following section details the LSA types. An Options field is carried in Hello, Database Description packets, and in all LSAs. The format of this field is the same in all cases and is detailed in its own section. The Packet HeaderAll OSPF packets begin with a 24-octet header, as shown in Figure 9.48. Figure 9.48. The OSPF packet header. Version is the OSPF version number. As of this writing, the most recent OSPF version number is 2. Type specifies the packet type following the header. Table 9.7 lists the five packet types by the number appearing in the Type field. Table 9.7. OSPF packet types.
Packet length is the length of the OSPF packet, in octets, including the header. Router ID is the ID of the originating router. Area ID is the area from which the packet originated. If the packet is sent over a virtual link, the Area ID will be 0.0.0.0, the backbone Area ID, because virtual links are considered part of the backbone. Checksum is a standard IP checksum of the entire packet, including the header. AuType is the authentication mode being used. Table 9.8 lists the possible authentication modes. Table 9.8. OSPF authentication types.
Authentication is the information necessary for the packet to be authenticated by whatever mode is specified in the AuType field. If AuType = 0, the field is not examined and therefore may contain anything. If AuType = 1, the field will contain a password of up to 64 bits. If AuType = 2, the Authentication field will contain a Key ID, the Authentication Data Length, and a nondecreasing Cryptographic sequence number. The message digest is appended to the end of the OSPF packet, and is not considered part of the packet itself. Key ID identifies the authentication algorithm and the secret key used to create the message digest. Authentication Data Length specifies the length, in octets, of the message digest appended to the end of the packet. Cryptographic Sequence Number is a nondecreasing number used to prevent replay attacks. The Hello PacketThe Hello packet (Figure 9.49) establishes and maintains adjacencies. The Hello carries parameters on which neighbors must agree in order to form an adjacency. Figure 9.49. The OSPF Hello packet. Network Mask is the address mask of the interface from which the packet was sent. If this mask does not match the mask of the interface on which the packet is received, the packet will be dropped. This technique ensures that routers will become neighbors only if they agree on the exact address of their shared network. Hello Interval , as discussed earlier, is the period, in seconds, between transmissions of Hello packets on the interface. If the sending and receiving routers don't have the same value for this parameter, they will not establish a neighbor relationship. Options are described in "The Options Field," later in this chapter. This field is included in the Hello packet to ensure that neighbors have compatible capabilities. A router may reject a neighbor because of a capabilities mismatch. Router Priority is used in the election of the DR and BDR. If set to zero, the originating router is ineligible to become the DR or BDR. Router Dead Interval is the number of seconds the originating router will wait for a Hello from a neighbor before declaring the neighbor dead. If a Hello is received in which this number does not match the RouterDeadInterval of the receiving interface, the packet will be dropped. This technique ensures that neighbors agree on this parameter. Designated Router is the IP address of the interface of the DR on the network (not its Router ID). During the DR election process, this may only be the originating router's idea of the DR, not the finally elected DR. If there is no DR (because one has not been elected or because the network type does not require DRs), this field will be set to 0.0.0.0. Backup DR is the IP address of the interface of the BDR on the network. Again, during the DR election process, this may only be the originating router's idea of the BDR. If there is no BDR, this field is set to 0.0.0.0. Neighbor is a recurring field that lists all neighbors on the network from which the originating router has received a valid Hello in the past RouterDeadInterval. The Database Description PacketThe Database Description packet (Figure 9.50) is used when an adjacency is being established (see "Building an Adjacency," earlier in this chapter). The primary purpose of the DD packet is to describe some or all of the LSAs in the originator's database so that the receiver can determine whether it has a matching LSA in its own database. This is done by listing only the headers of the LSAs. Because multiple DD packets may be exchanged during this process, flags are included for managing the exchange via a master/slave polling relationship. Figure 9.50. The OSPF Database Description packet. Interface MTU is the size, in octets, of the largest IP packet that can be sent out the originator's interface without fragmentation. This field will be set to 0x0000 when the packet is sent over virtual links. Options are described in "The Options Field." The field is included in the Database Description packet so that a router may choose not to forward certain LSAs to a neighbor that doesn't support the necessary capabilities. The first five bits of the next octet are unused and are always set to 00000b. I-bit , or Initial bit, is set to 1 when the packet is the initial packet in series of DD packets. Subsequent DD packets will have I-bit = 0. M-bit , or More bit, is set to 1 to indicate that the packet is not the last in a series of DD packets. The last DD packet will have M-bit = 0. MS-bit , or Master/Slave bit, is set to 1 to indicate that the originator is the master (that is, is in control of the polling process) during a database synchronization. The slave will have MS-bit = 0. DD Sequence Number ensures that the full sequence of DD packets are received in the database synchronization process. The sequence number will be set by the master to some unique value in the first DD packet, and the sequence will be incremented in subsequent packets. LSA Headers list some or all of the headers of the LSAs in the originator's link state database. See "The Link State Header," for a full description of the LSA header; the header contains enough information to uniquely identify the LSA and the particular instance of the LSA. The Link State Request PacketAs Database Description packets are received during the database synchronization process, a router will take note of any listed LSAs that are not in its database or are more recent than its own LSA. These LSAs are recorded in the Link State Request list. The router will then send one or more Link State Request packets (Figure 9.51) asking the neighbor for its copy of the LSA. Note that the packet uniquely identifies the LSA by Type, ID, and advertising router fields of its header, but it does not request a specific instance of the LSA (identified by the header's sequence number, checksum, and age). Therefore, the request is for the most recent instance of the LSA, whether the requester is aware of that instance or not. Figure 9.51. The OSPF link state request packet. Link State Type is the LS type number, which identifies the LSA as a router LSA, network LSA, and so on. Type numbers are listed in Table 9.4. Link State ID is a type-dependent field of the LSA header. See "The Link State Header" and the LSA-specific sections for a full description of how the various LSAs use this field. Advertising Router is the Router ID of the router which originated the LSA. The Link State Update PacketThe Link State Update packet, shown in Figure 9.52, is used in the flooding of LSAs and to send LSAs in response to Link State Requests. Recall that OSPF packets do not leave the network on which they were originated. Consequently, a Link State Update packet, carrying one or many LSAs, only carries the LSAs only one hop further from their originating router. The receiving neighbor is responsible for re-encapsulating the appropriate LSAs in new LS Update packets for further flooding. Figure 9.52. The OSPF Link State Update packet. Number of LSAs specifies the number of LSAs included in this packet. LSAs are the full LSAs as described in OSPF LSA formats. Each update may carry multiple LSAs, up to the maximum packet size allowed on the link. The Link State Acknowledgment PacketLink State Acknowledgment packets are used to make the flooding of LSAs reliable. Each LSA received by a router from a neighbor must be explicitly acknowledged in a Link State Acknowledgment packet. The LSA being acknowledged is identified by including its header in the LS ACK packet, and multiple LSAs may be acknowledged in a single packet. As Figure 9.53 shows, the LS ACK packet consists of nothing more than an OSPF packet header and a list of LSA headers. Figure 9.53. The OSPF Link State Acknowledgment packet. OSPF LSA FormatsThis section details the fields of each LSA type. The exception is the Group Membership LSA (type 6); because MOSPF is not covered in this book, details of its associated LSA are also not covered. LSA types 8 through 11 are also not covered because they are currently only proposed types and have not yet been deployed. The LSA HeaderThe LSA header (Figure 9.54) begins all LSAs and is also used by itself in Database Description and Link State Acknowledgment packets. Three fields in the header uniquely identify every LSA: the Type, Link State ID, and Advertising Router. Additionally, three other fields uniquely identify the most recent instance of an LSA: the Age, Sequence Number, and Checksum. Figure 9.54. The OSPF LSA header. Age is the time, in seconds, since the LSA was originated. As the LSA is flooded, the age is incremented by InfTransDelay seconds at each router interface it exits. The age is also incremented in seconds as it resides in a link state database. Options is described in "The Options Field." In the LSA header, the Options field specifies the optional capabilities supported by the portion of the OSPF domain described by the LSA. Type is the LSA type. The type codes are shown in Table 9.4. Link State ID identifies the portion of the OSPF domain being described by the LSA. The specific usage of this field varies according to the LSA type; the descriptions of each LSA include a description of how the LSA uses this field. Advertising Router is the router ID of the router that originated the LSA. Sequence Number is incremented each time a new instance of the LSA is originated. This update helps other routers identify the most recent instance of the LSA. Checksum is the Fletcher checksum of the complete contents of the LSA except the Age field. If the Age field were included, the checksum would have to be recalculated every time the age was incremented. Length is the number of octets of the LSA, including the header. The Router LSAA Router LSA (Figure 9.55) is produced by every router. It lists a router's links, or interfaces, along with the state and the outgoing cost of each link. These LSAs are flooded only within the area in which they are originated. The command show ip ospf database router (refer to Figure 9.30) lists the Router LSAs in a database. Note that Router LSAs advertise host routes as stub networks; the Link ID field carries the host IP address, and the Link Data field carries the host address mask of 255.255.255.255. Figure 9.55. The OSPF Router LSA. Link State ID for router LSAs is the originating router's Router ID. V , or Virtual Link Endpoint bit, is set to one when the originating router is an endpoint of one or more fully adjacent virtual links having the described area as the transit area. E, or External bit, is set to one when the originating router is an ASBR. B , or Border bit, is set to one when the originating router is an ABR. Number of Links specifies the number of router links the LSA describes. The router LSA must describe all of the originating router's links, or interfaces, to the area in which the LSA is flooded. Subsequent fields in the Router LSA describe each link and appear one or more times, corresponding to the number in the Number of Links field. This discussion covers the Link Type field first, although that field does not appear until after the Link Data field. Understanding link type first is important because the descriptions of the Link ID and Link Data fields vary according to the value of the Link Type field. Link Type describes the general type of connection the link provides. Table 9.9 lists the possible values of the field and the associated connection types. Table 9.9. Link type values.
Link ID identifies the object to which the link connects. This is dependent on the link type, as shown in Table 9.10. Note that when the connected object is another router, the Link ID is the same as the Link State ID in the header of the neighboring router's LSA. During the routing table calculation, this value is used to find the neighbor's LSA in the link state database. Table 9.10. Link ID values.
Link Data also depends on the value of the Link Type field, as shown in Table 9.11. Table 9.11. Link data values.
Number of TOS specifies the number of Type of Service metrics listed for this link. Although TOS is no longer supported in RFC 2328, the TOS fields are still included for backward compatibility with earlier OSPF implementations . If no TOS metrics are associated with a link, this field is set to 0x00. Metric is the cost of the link (interface). The next two fields are associated with a link corresponding to the number (#) of TOS field. For example, if # of TOS = 3, there will be three 32-bit words containing three instances of these fields. If # of TOS = 0, there will be no instances of these fields. Note that Cisco supports only TOS = 0. TOS specifies the Type of Service to which the following metric refers. [22] Table 9.12 lists the TOS values (as specified in RFC 1349), the bit values of the corresponding TOS field in the IP header, and the corresponding value used in the OSPF TOS field.
Table 9.12. OSPF TOS values.
TOS Metric is the metric associated with the specified TOS value. The Network LSANetwork LSAs (Figure 9.56) are originated by DRs. These LSAs advertise the multi-access network, and all routers (including the DR) attached to the network. Like Router LSAs, Network LSAs are flooded only within the originating area. The command show ip ospf database network (Figure 9.32) is used to observe a Network LSA. Figure 9.56. The OSPF Network LSA. Link State ID for Network LSAs is the IP address of the DR's interface to the network. Network Mask specifies the address or subnet mask used on this network. Attached Router lists the Router IDs of all routers on the network that are fully adjacent with the DR, and the Router ID of the DR itself. The number of instances of this field (and hence the number of routers listed) can be deduced from the LSA header's Length field. The Network and ASBR Summary LSAsThe Network Summary LSA (type 3) and the ASBR Summary LSA (type 4) have an identical format, shown in Figure 9.57. The only difference in field contents is the Type and the Link State ID. ABRs produce both types of Summary LSA; Network Summary LSAs advertise networks external to an area (including default routes), whereas ASBR Summary LSAs advertise ASBRs external to an area. Both types are flooded only into a single area. The Network Summary LSAs in a router's database can be observed with the command show ip ospf database summary (Figure 9.34), and ASBR Summary LSAs can be observed with show ip ospf database asbr-summary (Figure 9.36). Figure 9.57. The OSPF Summary LSA. The format is the same for both type 3 and type 4 Summary LSAs. Link State ID , for type 3 LSAs, is the IP address of the network or subnet being advertised. If the LSA is type 4, the Link State ID is the Router ID of the ASBR being advertised. Network Mask is the address or subnet mask of the network being advertised in type 3 LSAs. In type 4 LSAs, this field has no meaning and is set to 0.0.0.0. If a type 3 LSA is advertising a default route, both the Link State ID and the Network Mask fields will be 0.0.0.0. Metric is the cost of the route to this destination. The TOS and TOS Metric fields are optional and are described in "The Router LSA." Again, Cisco supports only TOS = 0. The Autonomous System External LSAAutonomous System External LSAs (Figure 9.58) are originated by ASBRs. These LSAs are used to advertise destinations external to the OSPF autonomous system, including default routes to external destinations, and are flooded into all nonstub areas of the OSPF domain. The command show ip ospf database external is used to display AS External LSAs (Figure 9.38). Figure 9.58. The OSPF Autonomous System External LSA. Link State ID for AS External LSAs is the IP address of the destination. Network Mask is the address or subnet mask for the destination being advertised. If the type 5 LSA is advertising a default route, the Link State ID and the network mask will both be 0.0.0.0. E , or External Metric bit, specifies the type of external metric to be used with this route. If the E-bit is set to 1, the metric type is E2. If the E-bit = 0, the metric type is E1. See the section "Path Types," earlier in this chapter, for more information on E1 and E2 external metrics. Metric is the cost of the route, as set by the ASBR. Forwarding Address is the address to which packets for the advertised destination should be forwarded. If the forwarding address is 0.0.0.0, packets will be forwarded to the originating ASBR. External Route Tag is an arbitrary tag that may be applied to the external route. This field is not used by the OSPF protocol itself, but is instead provided for external route management. The setting and use of such tags are discussed in Chapter 14, "Route Maps." Optionally, TOS fields may be associated with the destination. These fields are the same as discussed previously, except each TOS metric also has its own E-bit, Forwarding Address, and External Route Tag. The NSSA External LSANSSA External LSAs are originated by ASBRs within an NSSA (not-so-stubby area). All fields of the NSSA External LSA (Figure 9.59) are identical to an AS External LSA's fields, with the exception of the Forwarding Address field. Unlike AS External LSAs, which are flooded throughout an OSPF autonomous system, NSSA external LSAs are flooded only within the not-so-stubby area in which it was originated. The command show ip ospf database nssa-external is used to display NSSA External LSAs (Figure 9.39). Figure 9.59. The OSPF NSSA LSA. Forwarding Address , if the network between the NSSA ASBR and the adjacent autonomous system is advertised as an internal route, is the next hop address on the network. If the network is not advertised as an internal route, the forwarding address will be the NSSA ASBR's Router ID. The Options FieldThe Options field (Figure 9.60) is present in every Hello and Database Description packet and in every LSA. The Options field allows routers to communicate their optional capabilities to other routers. Figure 9.60. The OSPF Options field. The asterisk, *, indicates an unused bit, normally set to zero. DC is set when the originating router is capable of supporting OSPF over demand circuits. EA is set when the originating router is capable of receiving and forwarding External Attributes LSAs. These LSAs are not yet in general usage and are not covered in this book. N is used only in Hello packets. A router will set N-bit = 1 to indicate support for NSSA External LSAs. If N-bit = 0, the router will not accept or send these LSAs. Neighboring routers with mismatched N-bits will not become adjacent; this restriction ensures that all routers in an area support NSSA capabilities equally. If the N-bit = 1, the E-bit must be 0. P is used only in NSSA External LSA headers. (For this reason, the N- and P-bit can use the same position.) This bit tells the ABR of a not-so-stubby area to translate type 7 LSAs into type 5 LSAs. MC is set when the originating router is capable of forwarding IP multicast packets. This bit is used by MOSPF. E is set when the originating router is capable of accepting AS External LSAs. It will be set to 1 in all AS External LSAs and in all LSAs originated in the backbone and nonstub areas. E-bit = 0 in all LSAs originated within a stub area. Additionally, the bit is used in the Hello packet to indicate an interface's capability of sending and receiving type 5 LSAs. Neighboring routers with mismatched E-bits will not become adjacent; this restriction ensures that all routers in an area support stub capabilities equally. T is set when the originating router is capable of supporting TOS. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
![Routing TCP[s]IP (Vol. 11998)](/icons/blank_book.jpg "Routing TCP[s]IP (Vol. 11998)"){kind=icon}