Operation of OSPF[2]
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 and neighbors have verified that their databases are identicalthat is, the link-state databases have been synchronizedand 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 network topology is stable, no other activity should occur. Neighbors and AdjacenciesBefore 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 which contains other information necessary for the maintenance of the neighbor (Example 8-1). Example 8-1. The neighbor table records all OSPF-speaking neighbors.Monet#show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 192.168.30.70 1 FULL/DR 00:00:34 192.168.17.73 Ethernet0 192.168.30.254 1 FULL/DR 00:00:34 192.168.32.2 Ethernet1 192.168.30.70 1 FULL/BDR 00:00:34 192.168.32.4 Ethernet1 192.168.30.30 1 FULL/ - 00:00:33 192.168.17.50 Serial0.23 192.168.30.10 1 FULL/ - 00:00:32 192.168.17.9 Serial1 192.168.30.68 1 FULL/ - 00:00:39 192.168.21.134 Serial2.824 192.168.30.18 1 FULL/ - 00:00:30 192.168.21.142 Serial2.826 192.168.30.78 1 FULL/ - 00:00:36 192.168.21.170 Serial2.836 The tracking of other OSPF routers requires that each router have a Router 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:
Using addresses associated with loopback interfaces has two advantages:
The Cisco 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. 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 for broadcast networks and 30 seconds for non-broadcast; 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. The Cisco default RouterDeadInterval is four times the HelloInterval and can be changed with the command ip ospf dead-interval.[4]
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. After 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, DS-3, or SONET 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.[5]
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 might 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 the OSPF packets are unicast to each known neighbor. 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):
To prevent these problems, a DR is elected on multi-access networks. The DR has the following duties:
The concept behind the DR is that the broadcast link itself is considered a "pseudonode," or a virtual router. When the SPF tree is calculated, the link appears as a node and the routers attached to the link are attached to that node. The cost from an attached router to the pseudonode is the outgoing cost of that router's interface to the broadcast link, but the cost from the pseudonode to any attached router is 0. This way, the overall path cost is not affected by the pseudonode. Each router on the network forms an adjacency with the DR (Figure 8-2), which represents the pseudonode with a special Network LSA. 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 8-2. The DR 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 BDR 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. 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. After 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 two-way (explained later, in "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. Interface Data StructureAn OSPF router maintains a data structure for each OSPF-enabled interface. In Example 8-2, the command show ip ospf interface has been used to observe the components of an interface data structure.[8]
Example 8-2. 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.Renoir#show ip ospf interface Serial1.738 Serial1.738 is up, line protocol is up Internet Address 192.168.21.21/30, Area 7 Process ID 1, Router ID 192.168.30.70, Network Type POINT_TO_POINT, Cost: 781 Transmit Delay is 1 sec, State POINT_TO_POINT, Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5 Hello due in 00:00:07 Neighbor Count is 1, Adjacent neighbor count is 1 Adjacent with neighbor 192.168.30.77 Message digest authentication enabled Youngest key id is 10 The components of the interface data structure are as follows:
The cost can be changed with the command ip ospf cost. This command is especially important when configuring Cisco routers in a multivendor environment. Another vendor, for example, might 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, suboptimally, or in some other unexpected way. The reference bandwidth of 108 creates a problem for some modern media with bandwidths higher than 100M (such as OC-3 or above and Gigabit Ethernet). 108/100M = 1, meaning that higher bandwidths calculate to a fraction of 1, which is not allowed. So any cost that is calculated to a fraction of 1 is rounded up to 1. However, this means that if your network consists of high-bandwidth links, all interfaces wind up with a cost of 1 and the calculated shortest paths become based on least router hops. To remedy this, Cisco provides the command auto-cost reference-bandwidth, which allows the default reference bandwidth to be changed. Other components of the interface data structure are as follows:
Example 8-3. This interface is attached to a broadcast network type, and the router is the DR on this network.Renoir#show ip ospf interface Ethernet0 Ethernet0 is up, line protocol is up Internet Address 192.168.17.73/29, Area 0 Process ID 1, Router ID 192.168.30.70, Network Type BROADCAST, Cost: 10 Transmit Delay is 1 sec, State DR, Priority 1 Designated Router (ID) 192.168.30.70, Interface address 192.168.17.73 Backup Designated router (ID) 192.168.30.80, Interface address 192.168.17.74 Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5 Hello due in 00:00:03 Neighbor Count is 1, Adjacent neighbor count is 1 Adjacent with neighbor 192.168.30.80 (Backup Designated Router) Message digest authentication enabled Youngest key id is 10
Example 8-4. On this network, the router sees five neighbors but has only formed adjacencies with the DR and the BDR.Renoir#show ip ospf interface Ethernet1 Ethernet1 is up, line protocol is up Internet Address 192.168.32.4/24, Area 78 Process ID 1, Router ID 192.168.30.70, Network Type BROADCAST, Cost: 10 Transmit Delay is 1 sec, State DROTHER, Priority 1 Designated Router (ID) 192.168.30.254, Interface address 192.168.32.2 Backup Designated router (ID) 192.168.30.80, Interface address 192.168.32.1 Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5 Hello due in 00:00:01 Neighbor Count is 5, Adjacent neighbor count is 2 Adjacent with neighbor 192.168.30.80 (Backup Designated Router) Adjacent with neighbor 192.168.30.254 (Designated Router) Message digest authentication enabled Youngest key id is 10
Example 8-5 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. Example 8-5. This interface is attached to a NBMA Frame Relay network and is the BDR for this network.Renoir#show ip ospf interface Serial3 Serial3 is up, line protocol is up Internet Address 192.168.16.41/30, Area 0 Process ID 1, Router ID 192.168.30.105, Network Type NON_BROADCAST, Cost: 64 Transmit Delay is 1 sec, State BDR, Priority 1 Designated Router (ID) 192.168.30.210, Interface address 192.168.16.42 Backup Designated router (ID) 192.168.30.105, Interface address 192.168.16.41 Timer intervals configured, Hello 30, Dead 120, Wait 120, Retransmit 5 Hello due in 00:00:08 Neighbor Count is 1, Adjacent neighbor count is 1 Adjacent with neighbor 192.168.30.210 (Designated Router) It is worthwhile to spend some time comparing Example 8-2 through Example 8-5. 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. 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.
Figure 8-3 shows the OSPF interface states and the input events that will cause a state transition. The input events are described in Table 8-1. Figure 8-3. The OSPF interface state machine; see Table 8-1 for a description of input events (IEs).
OSPF NeighborsThe preceding section discussed a router's relationship with the attached data link. 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 link. 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. 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 120 seconds. 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. In Example 8-6, the command show ip ospf neighbor is used to observe some of the information in the neighbor data structure for a single neighbor.[10]
Example 8-6. An OSPF router describes each conversation with each neighbor by a neighbor data structure.Seurat#show ip ospf neighbor 10.7.0.1 Neighbor 10.7.0.1, interface address 10.8.1.2 In the area 0 via interface Ethernet0/0 Neighbor priority is 1, State is FULL, 6 state changes DR is 10.8.1.1 BDR is 10.8.1.2 Options is 0x52 LLS Options is 0x1 (LR) Dead timer due in 00:00:30 Neighbor is up for 09:55:04 Index 1/3, retransmission queue length 0, number of retransmission 1 First 0x0(0)/0x0(0) Next 0x0(0)/0x0(0) Last retransmission scan length is 1, maximum is 1 Last retransmission scan time is 0 msec, maximum is 0 msec Actually, the data structure records more information about each neighbor than is shown in the example.[11] The components of the neighbor data structure are as follows:
Components of the neighbor data structure that are not displayed by the show ip ospf neighbor command are as follows:
Neighbor State MachineAn OSPF router transitions a neighbor (as described in the neighbor data structure) through several states before the neighbor is considered fully adjacent:
Figure 8-4 through Figure 8-6 show the OSPF neighbor states and the input events that cause a state transition. The input events are described in Table 8-2, and the decision points are defined in Table 8-3. Figure 8-4 shows the normal progression from the least functional state to the fully functional state, and Figure 8-5 and Figure 8-6 show the complete OSPF neighbor state machine. Figure 8-4. The normal series of transitions in the OSPF neighbor state machine that take a neighbor from Down to Full.
Figure 8-5. The neighbor state machine, from Down to Init.
Figure 8-6. 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 exist between DRothers. The adjacency building process uses three OSPF packet types:
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 headersenough 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 transitions to Exchange. In the Exchange state, the neighbors 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 sends 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 8-7 shows the adjacency-building process. This example is taken directly from RFC 2328. Figure 8-7. The link-state database synchronization process and associated neighbor states.The following steps are illustrated in Figure 8-7:
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 8-7, but it is more efficient. Figure 8-8 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 8-7. Figure 8-8. This analyzer capture shows an adjacency being built.In Example 8-7, the output of the command debug ip ospf adj shows the adjacency of Figure 8-8 being built from the perspective of one of the routers (router ID 192.168.30.175). Example 8-7. This debug output shows the adjacency events of Figure 8-8 from the perspective of one of the routers.Degas#debug ip ospf adj OSPF adjacency events debugging is on OSPF: Rcv DBD from 192.168.30.70 on Ethernet0 seq 0x20E0 opt 0x2 flag 0x7 len 32 state INIT OSPF: 2 Way Communication to 192.168.30.70 on Ethernet0, state 2WAY OSPF: Neighbor change Event on interface Ethernet0 OSPF: DR/BDR election on Ethernet0 OSPF: Elect BDR 192.168.30.70 OSPF: Elect DR 192.168.30.175 DR: 192.168.30.175 (Id) BDR: 192.168.30.70 (Id) OSPF: Send DBD to 192.168.30.70 on Ethernet0 seq 0xB17 opt 0x2 flag 0x7 len 32 OSPF: First DBD and we are not SLAVE OSPF: Rcv DBD from 192.168.30.70 on Ethernet0 seq 0xB17 opt 0x2 flag 0x2 len 92 state EXSTART OSPF: NBR Negotiation Done. We are the MASTER OSPF: Send DBD to 192.168.30.70 on Ethernet0 seq 0xB18 opt 0x2 flag 0x3 len 72 OSPF: Database request to 192.168.30.70 OSPF: Rcv DBD from 192.168.30.70 on Ethernet0 seq 0xB18 opt 0x2 flag 0x0 len 32 state EXCHANGE OSPF: Send DBD to 192.168.30.70 on Ethernet0 seq 0xB19 opt 0x2 flag 0x1 len 32 OSPF: Rcv DBD from 192.168.30.70 on Ethernet0 seq 0xB19 opt 0x2 flag 0x0 len 32 state EXCHANGE OSPF: Exchange Done with 192.168.30.70 on Ethernet0 OSPF: Synchronized with 192.168.30.70 on Ethernet0, state FULL At the end of the synchronization process in Figure 8-8, 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 can be depicted as a group of routers, or nodes, interconnected not by physical links but by logical adjacencies (Figure 8-9). 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 8-9. 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 8-10 shows, each Link State Update and Acknowledgment packet may carry multiple LSAs. Although the LSAs themselves are flooded throughout the area, the Update and Acknowledgment packets travel only between two nodes across an adjacency. Figure 8-10. 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 packet 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 8-11). Although the BDR hears and records LSAs multicast from DRothers, it does 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 8-11. 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. 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, such as when the neighbor was intending to send an update to the originator anyway. 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 headersenough to completely identify the LSAnot 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. Acknowledgments might 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:
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 32-bit signed, linear sequence number space (discussed in Chapter 4, "Dynamic Routing Protocols") 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. 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.
The age is an unsigned 16-bit integer that indicates the age of the LSA in seconds. The range is 0 to 3600 (one 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 one second, which can be changed with the command ip ospf transmit-delay. The age is also incremented as it resides in the database. 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. Example 8-8 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 "Link-State Database," later in this chapter. Example 8-8. The age, sequence number, and checksum for each LSA are recorded in the link-state database. The age is incremented in seconds.Manet#show ip ospf database OSPF Router with ID (192.168.30.43) (Process ID 1) Router Link States (Area 3) Link ID ADV Router Age Seq# Checksum Link Count 192.168.30.13 192.168.30.13 910 0x80000F29 0xA94E 2 192.168.30.23 192.168.30.23 1334 0x80000F55 0x8D53 3 192.168.30.30 192.168.30.30 327 0x800011CA 0x523 8 192.168.30.33 192.168.30.33 70 0x80000AF4 0x94DD 3 192.168.30.43 192.168.30.43 1697 0x80000F2F 0x1DA1 2 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 a network grows, these demands can become significant or even crippling. And although flooding is more efficient than the periodic, full-table updates of RIP, it can still place an unacceptable burden on the data links of a large network. Contrary to popular belief, the SPF algorithm itself is not particularly processor-intensive. Rather, the related processes, such as flooding and database maintenance, burden the CPU. 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 8-12). Routers within an area will have no detailed knowledge of the topology outside of their area. Because of this condition
Figure 8-12. 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.
Areas are identified by a 32-bit Area ID. As Figure 8-12 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. Three types of traffic may be defined in relation to areas:
Area ID 0 (or 0.0.0.0) is reserved for the backbone. The backbone is responsible for summarizing the topologies 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. 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 might be too many for some areas, and other areas might accommodate well over 500 routers. It is perfectly reasonable to design a small OSPF network 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 might 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 8-13:
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 8-14, no service disruptions will occur. The backbone merely treats 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 OSPF domain. Figure 8-14. (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.
A partition of the backbone itself is a more serious matter. As Figure 8-15 shows, a partitioned backbone area isolates the areas on each side of the partition, creating two separate OSPF domains. Figure 8-15. If a backbone becomes partitioned, each side of the partition and any connected areas become isolated from the other side.
Figure 8-16 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 can isolate any part of the area. Figure 8-16. 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:
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 unnumberedthat is, unaddressedlink, 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 is established across the virtual link. Virtual links add a layer of complexity and troubleshooting difficulty to any network. 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 networks 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 network that needs to be reengineered. Permanent virtual links are virtually always a sign of a poorly designed network. 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 Example 8-9. 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. Example 8-9. The command show ip ospf database displays a list of all LSAs in the link-state database.Homer#show ip ospf database OSPF Router with ID (192.168.30.50) (Process ID 1) Router Link States (Area 0) Link ID ADV Router Age Seq# Checksum Link count 192.168.30.10 192.168.30.10 1010 0x80001416 0xA818 3 192.168.30.20 192.168.30.20 677 0x800013C9 0xDE18 3 192.168.30.70 192.168.30.70 857 0x80001448 0xFD79 3 192.168.30.80 192.168.30.80 1010 0x800014D1 0xEB5C 5 Net Link States (Area 0) Link ID ADV Router Age Seq# Checksum 192.168.17.18 192.168.30.20 677 0x800001AD 0x849A 192.168.17.34 192.168.30.60 695 0x800003E2 0x4619 192.168.17.58 192.168.30.40 579 0x8000113C 0xF0D 192.168.17.73 192.168.30.70 857 0x8000044F 0xB0E7 Summary Net Link States (Area 0) Link ID ADV Router Age Seq# Checksum 172.16.121.0 192.168.30.60 421 0x8000009F 0xD52 172.16.121.0 192.168.30.70 656 0x8000037F 0x86A 10.63.65.0 192.168.30.10 983 0x80000004 0x1EAA 10.63.65.0 192.168.30.80 962 0x80000004 0x780A Summary ASB Link States (Area 0) Link ID ADV Router Age Seq# Checksum 192.168.30.12 192.168.30.20 584 0x80000005 0xFC4C 192.168.30.12 192.168.30.30 56 0x80000004 0x45BA 172.20.57.254 192.168.30.70 664 0x800000CE 0xF2CF 172.20.57.254 192.168.30.80 963 0x80000295 0x23CC Router Link States (Area 4) Link ID ADV Router Age Seq# Checksum Link count 192.168.30.14 192.168.30.14 311 0x80000EA5 0x93A0 7 192.168.30.24 192.168.30.24 685 0x80001333 0x6F56 6 192.168.30.50 192.168.30.50 116 0x80001056 0x42BF 2 192.168.30.54 192.168.30.54 1213 0x80000D1F 0x3385 2 Summary Net Link States (Area 4) Link ID ADV Router Age Seq# Checksum 172.16.121.0 192.168.30.40 1231 0x80000D88 0x73BF 172.16.121.0 192.168.30.50 34 0x800003F4 0xF90D 10.63.65.0 192.168.30.40 1240 0x80000003 0x5110 10.63.65.0 192.168.30.50 42 0x80000005 0x1144 Summary ASB Link States (Area 4) Link ID ADV Router Age Seq# Checksum 192.168.30.12 192.168.30.40 1240 0x80000006 0x6980 192.168.30.12 192.168.30.50 42 0x80000008 0xC423 172.20.57.254 192.168.30.40 1241 0x8000029B 0xEED8 172.20.57.254 192.168.30.50 43 0x800002A8 0x9818 AS External Link States Link ID ADV Router Age Seq# Checksum Tag 10.83.10.0 192.168.30.60 459 0x80000D49 0x9C0B 0 10.1.27.0 192.168.30.62 785 0x800000EB 0xB5CE 0 10.22.85.0 192.168.30.70 902 0x8000037D 0x1EC0 65502 10.22.85.0 192.168.30.80 1056 0x800001F7 0x6B4B 65502 Homer# Most of the entries in Example 8-9 have been deleted for brevity; the actual link-state database contains 1,445 entries and four areas, as shown in Example 8-10. Example 8-10. The command show ip ospf database database-summary displays the number of LSAs in a link-state database by area and by LSA type.Homer#show ip ospf database database-summary OSPF Router with ID (192.168.30.50) (Process ID 1) Area ID Router Network Sum-Net Sum-ASBR Subtotal Delete Maxage 0 8 4 185 27 224 0 0 4 7 0 216 26 249 0 0 5 7 0 107 13 127 0 0 56 2 1 236 26 265 0 0 AS External 580 0 0 Total 24 5 744 92 1445 Homer# 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 floods a new copy of the LSA with an incremented sequence number and an age of zero. Upon receipt, the other OSPF routers 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 are 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 do not expire all at once, reflooding all LSAs every 30 minutes. Instead, the reflooding is spread out in a semi-random 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. Therefore a mechanism known as LSA group pacing was introduced 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). Depending on the IOS version, the default can be changed with either timers lsa-group-pacing or timers pacing lsa-group.[13] If the database is very large (10,000 or more LSAs), decreasing the group pacing interval is beneficial; if the database is small, increasing the interval might 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 Example 8-9 and Example 8-10 show that there are multiple types of LSAs. Each type describes a different aspect of an OSPF network. Table 8-4 lists the LSA types and the type codes that identify them.
Router LSAs are produced by every router (Figure 8-19). This most fundamental LSA lists all of a router's links, or interfaces, the state and outgoing cost of each link, and any known OSPF neighbors on the 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. Example 8-11 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 8-19. The Router LSA describes all of a router's interfaces.
Example 8-11. The command show ip ospf database router displays Router LSAs from the link-state database.Homer#show ip ospf database router 192.168.30.10 OSPF Router with ID (192.168.30.50) (Process ID 1) Router Link States (Area 0) Routing Bit Set on this LSA LS age: 680 Options: (No TOS-capability) LS Type: Router Links Link State ID: 192.168.30.10 Advertising Router: 192.168.30.10 LS Seq Number: 80001428 Checksum: 0x842A Length: 60 Area Border Router Number of Links: 3 Link connected to: another Router (point-to-point) (Link ID) Neighboring Router ID: 192.168.30.80 (Link Data) Router Interface address: 192.168.17.9 Number of TOS metrics: 0 TOS 0 Metrics: 64 Link connected to: a Stub Network (Link ID) Network/subnet number: 192.168.17.8 (Link Data) Network Mask: 255.255.255.248 Number of TOS metrics: 0 TOS 0 Metrics: 64 Link connected to: a Transit Network (Link ID) Designated Router address: 192.168.17.18 (Link Data) Router Interface address: 192.168.17.17 Number of TOS metrics: 0 TOS 0 Metrics: 10 Homer# One line you will notice in Example 8-11 and in several subsequent LSA displays is the statement "Routing Bit Set on this LSA." The routing bit is not a part of the LSA itself; it is an internal maintenance bit used by IOS indicating that the route to the destination advertised by this LSA is valid. So when you see "Routing Bit Set on this LSA," it means that the route to this destination is in the routing table. Network LSAs are produced by the DR on every multi-access network (Figure 8-20). 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 Example 8-12, the command show ip ospf database network is used to observe a Network LSA. Figure 8-20. A DR originates a Network LSA to represent a multi-access network and all attached routers.
Example 8-12. Network LSAs can be observed with the command show ip ospf database network.Homer#show ip ospf database network 192.168.17.18 OSPF Router with ID (192.168.30.50) (Process ID 1) Net Link States (Area 0) Routing Bit Set on this LSA LS age: 244 Options: (No TOS-capability) LS Type: Network Links Link State ID: 192.168.17.18 (address of Designated Router) Advertising Router: 192.168.30.20 LS Seq Number: 800001BF Checksum: 0x60AC Length: 32 Network Mask: /29 Attached Router: 192.168.30.20 Attached Router: 192.168.30.10 Attached Router: 192.168.30.30 Homer# Notice that unlike the Router LSA, there is no metric field in the Network LSA. This is because, as explained earlier in this chapter, the cost from the pseudonode represented by the LSA to any attached router is always 0. Network Summary LSAs are originated by ABRs. They are sent into a single area to advertise destinations outside that area (Figure 8-21). 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 Example 8-13. Figure 8-21. An ABR will originate a Network Summary LSA to describe inter-area destinations.
Example 8-13. Network Summary LSAs can be observed with the command show ip ospf database summary.Homer#show ip ospf database summary 172.16.121.0 OSPF Router with ID (192.168.30.50) (Process ID 1) Summary Net Link States (Area 0) Routing Bit Set on this LSA LS age: 214 Options: (No TOS-capability) LS Type: Summary Links(Network) Link State ID: 172.16.121.0 (summary Network Number) Advertising Router: 192.168.30.60 LS Seq Number: 800000B1 Checksum: 0xE864 Length: 28 Network Mask: /24 TOS: 0 Metric: 791 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 behaviordepending on an intermediate router instead of determining the full route to the destinationis 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.[14]
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 8-22), not a network. The command show ip ospf database asbr-summary is used to display ASBR Summary LSAs (Example 8-14). 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 8-22. ASBR Summary LSAs advertise routes to ASBRs.
Example 8-14. ASBR Summary LSAs can be observed with the command show ip ospf database asbr-summary.Homer#show ip ospf database asbr-summary OSPF Router with ID (192.168.30.50) (Process ID 1) Summary ASB Link States (Area 0) Routing Bit Set on this LSA LS age: 1640 Options: (No TOS-capability) LS Type: Summary Links (AS Boundary Router) Link State ID: 192.168.30.12 (AS Boundary Router address) Advertising Router: 192.168.30.20 LS Seq Number: 80000009 Checksum: 0xF450 Length: 28 Network Mask: /0 TOS: 0 Metric: 64 --More- Autonomous System External LSAs, or External LSAs, are originated by ASBRs. They advertise either a destination external to the OSPF autonomous system, or a default route[15] external to the OSPF autonomous system (Figure 8-23). Referring back to Example 8-9, 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 database external displays AS External LSAs (Example 8-15).
Figure 8-23. AS External LSAs advertise destinations external to the OSPF autonomous system.
Example 8-15. AS External LSAs can be observed with the command show ip ospf database external.Homer#show ip ospf database external 10.83.10.0 OSPF Router with ID (192.168.30.50) (Process ID 1) AS External Link States Routing Bit Set on this LSA LS age: 1680 Options: (No TOS-capability) LS Type: AS External Link Link State ID: 10.83.10.0 (External Network Number) Advertising Router: 192.168.30.60 LS Seq Number: 80000D5A Checksum: 0x7A1C Length: 36 Network Mask: /24 Metric Type: 1 (Comparable directly to link state metric) TOS: 0 Metric: 10 Forward Address: 172.20.57.254 External Route Tag: 0 Homer# Group Membership LSAs are used in an enhancement of OSPF known as Multicast OSPF (MOSPF).[16] 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 (Example 8-16). Example 8-16. NSSA External LSAs can be observed with the command show ip ospf database nssa-external.Morisot#show ip ospf database nssa-external OSPF Router with ID (10.3.0.1) (Process ID 1) Type-7 AS External Link States (Area 15) LS age: 532 Options: (No TOS-capability, No Type 7/5 translation, DC) LS Type: AS External Link Link State ID: 10.0.0.0 (External Network Number) Advertising Router: 10.3.0.1 LS Seq Number: 80000001 Checksum: 0x9493 Length: 36 Network Mask: /16 Metric Type: 2 (Larger than any link state path) TOS: 0 Metric: 100 Forward Address: 10.3.0.1 External Route Tag: 0 --More- External Attributes LSAs were proposed as an alternative to running Internal BGP (iBGP), to transport BGP information across an OSPF domain. This LSA has never been deployed on a wide scale, and is not supported in IOS. Opaque LSAs are a class of LSAs that consist of a standard LSA header followed by application-specific information.[17] The Information field can be used directly by OSPF or indirectly by other applications to distribute information throughout the OSPF domain. Opaque LSAs have been used to add various extensions to OSPF, such as traffic engineering parameters for Multiprotocol Label Switching (MPLS) networks.
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, Example 8-10 shows that 580 of the LSAs in that database40 percentare external LSAs. In Figure 8-24, 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 might be. For this reason, area 2 can be configured as a stub area. Figure 8-24. 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 use Network Summary (type 3) 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 OSPF domains with a large number of type 5 LSAs. There are, however, four 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 LSAswith the exception of a single type 3 LSA to advertise the default route. Not-So-Stubby AreasIn Figure 8-25, a router with a few stub networks must be attached to the OSPF domain 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 8-25. 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 OSPFa 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)[18] 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 8-26). 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. This option allows you to design an NSSA in which the external destinations learned in that area are known only in that area. Figure 8-26. 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 8-5 summarizes which LSAs are allowed in which areas.
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. OSPF 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 108/BW, where BW is the configured bandwidth of the interface and 108 is the reference bandwidth. As discussed previously, the default reference bandwidth can be changed with the command auto-cost reference-bandwidth. Fractional costs are rounded down to the nearest whole number. Table 8-6 shows the default costs calculated by this formula for some typical interfaces.
The command ip ospf cost can be used to override the default automatic cost calculations and assign a fixed cost to an interface. For example, a large network with homogeneous backbone link speeds might assign link costs based on line of sight or wire/fiber distance. LSAs record cost in a 16-bit field, so the total cost of an interface can range from 1 to 65535. Destination TypesEach route entry is 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 (Example 8-17). Example 8-17. The OSPF entries in the route table are network destination types.Homer#show ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default U - per-user static route Gateway of last resort is 192.168.32.2 to network 0.0.0.0 O E1 192.168.118.0/24 [110/94] via 192.168.17.74, 02:15:01, Ethernet0 O E1 10.0.0.0/8 [110/84] via 192.168.17.41, 02:15:01, Serial0.19 O E1 192.168.119.0/24 [110/94] via 192.168.17.74, 02:15:01, Ethernet0 O E2 172.19.0.0/16 [110/21] via 192.168.32.2, 02:15:01, Ethernet1 172.21.0.0/16 is variably subnetted, 2 subnets, 2 masks O E2 172.21.0.0/16 [110/801] via 192.168.21.6, 02:15:01, Serial1.724 O 172.21.121.0/24 [110/791] via 192.168.21.6, 04:18:30, Serial1.724 172.16.0.0/16 is variably subnetted, 104 subnets, 7 masks O 172.16.21.48/30 [110/844] via 192.168.21.10, 04:18:48, Serial1.725 O IA 172.16.30.61/32 [110/856] via 192.168.17.74, 02:15:19, Ethernet0 O IA 172.16.35.0/24 [110/865] via 192.168.17.74, 02:15:19, Ethernet0 C 172.16.32.0/24 is directly connected, Ethernet1 O 172.16.17.48/29 [110/74] via 192.168.17.74, 06:19:46, Ethernet0 O E1 172.16.46.0/24 [110/30] via 192.168.32.2, 02:15:19, Ethernet1 O 172.16.45.0/24 [110/20] via 192.168.32.2, 3d10h, Ethernet1 O IA 172.16.30.54/32 [110/1061] via 192.168.17.74, 02:15:21, Ethernet0 O 172.16.17.56/29 [110/84] via 192.168.17.74, 06:19:48, Ethernet0 O 172.16.54.0/24 [110/11] via 192.168.32.2, 3d10h, Ethernet1 O 172.16.55.0/24 [110/11] via 192.168.32.2, 3d10h, Ethernet1 O 172.16.52.0/24 [110/11] via 192.168.32.2, 3d10h, Ethernet1 O 172.16.53.0/24 [110/11] via 192.168.32.2, 3d10h, Ethernet1 C 172.16.25.28/30 is directly connected, Tunnel29 --More- 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 (Example 8-18). Example 8-18. Router entries, kept in a separate table from network entries, are routes to ABRs and ASBRs.Homer#show ip ospf border-routers OSPF Process 1 internal Routing Table Codes: i - Intra-area route, I - Inter-area route i 192.168.30.10 [74] via 192.168.17.74, Ethernet0, ABR, Area 0, SPF 391 I 192.168.30.12 [148] via 192.168.17.74, Ethernet0, ASBR, Area 0, SPF 391 I 192.168.30.18 [205] via 192.168.17.74, Ethernet0, ASBR, Area 0, SPF 391 i 192.168.30.20 [84] via 192.168.17.74, Ethernet0, ABR, Area 0, SPF 391 i 192.168.30.27 [781] via 192.168.21.6, Serial1.724, ASBR, Area 7, SPF 631 i 192.168.30.30 [74] via 192.168.17.74, Ethernet0, ABR/ASBR, Area 0, SPF 391 I 192.168.30.38 [269] via 192.168.17.74, Ethernet0, ASBR, Area 0, SPF 391 i 192.168.30.37 [390] via 192.168.21.10, Serial1.725, ASBR, Area 7, SPF 631 i 192.168.30.40 [84] via 192.168.17.74, Ethernet0, ABR/ASBR, Area 0, SPF 391 i 192.168.30.47 [400] via 192.168.21.10, Serial1.725, ASBR, Area 7, SPF 631 i 192.168.30.50 [74] via 192.168.17.41, Serial0.19, ABR/ASBR, Area 0, SPF 391 I 192.168.30.62 [94] via 192.168.17.74, Ethernet0, ASBR, Area 0, SPF 391 i 192.168.30.60 [64] via 192.168.17.41, Serial0.19, ABR/ASBR, Area 0, SPF 391 i 192.168.30.60 [790] via 192.168.21.10, Serial1.725, ABR/ASBR, Area 7, SPF 631 i 192.168.30.80 [10] via 192.168.32.5, Ethernet1, ABR/ASBR, Area 78, SPF 158 i 192.168.30.80 [10] via 192.168.17.74, Ethernet0, ABR/ASBR, Area 0, SPF 391 i 172.20.57.254 [10] via 192.168.32.2, Ethernet1, ASBR, Area 78, SPF 158 Homer# As Example 8-18 shows, the internal route table looks very similar to any other route tablethere 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 the entry. Path TypesEach route to a network destination is also classified as one of four path types. These path types are intra-area, inter-area, type 1 external, and type 2 external:
E1 and E2 routes provide the network administrator with the option of choosing whether the internal cost to the ASBR is important or whether only the external cost of an external route, disregarding the internal cost of reaching the ASBR, is more important. For example, "hot potato" routinggetting packets to external destinations out of the network at the closest exit pointusually requires E1 metrics, whereas if you want packets to exit your network at the closest point to their external destination, use E2 metrics. OSPF external routes are, by default, E2 paths. In Figure 8-27, 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 8-27. 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:[19]
If multiple equal-cost, equal-path-type routes exist in the final set, OSPF utilizes them. By default, the Cisco OSPF implementation load balances over a maximum of 16 equal-cost paths (four in older versions of IOS); this number can be changed within the range of one to six with the command maximum-paths.[20]
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 6, "RIPv2, RIPng, and Classless Routing," 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 less bandwidth than traditional distance vector protocols such as RIP. However, even this minimal traffic is undesirable on demand circuitsusage-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.[21] Although this enhancement is designed specifically for usage-sensitive circuits, it might be useful on any bandwidth-limited link.[22]
OSPF over demand circuits brings up a demand link to perform the initial database synchronization and subsequently brings up the link to flood only LSAs in which certain changes have occurred. These LSA 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 might not be immediately accessible. For example, a dialup link might be in use, both B channels of a BRI link might 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.[23] 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. A peripheral benefit of the enhancements made by OSPF over Demand Circuitsnamely, designating the high bit of the Age field as the DoNotAge bitis that you can now reduce flooding in stable topologies. With the command ip ospf flood-reduction entered for an interface, the DoNotAge bit is set on LSAs advertised out the interface and the LSAs are not refreshed unless they change. OSPF Packet FormatsThe OSPF packet consists of multiple encapsulations, and deconstructing one is like peeling an onion. As shown in Figure 8-28, the outside of the onion is the IP header. 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 has a number of type-specific fields, followed by more data. The data contained in a Hello packet is a list of neighbors. LS Request packets contain a series of fields describing the requested LSAs. LS Update packets contain a list of LSAs, as shown in Figure 8-28. These LSAs in turn have their own headers and type-specific data fields. Database Description and LS Acknowledgment packets contain a list of LSA headers. Figure 8-28. 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 8-29 shows an analyzer capture of an IP header for a packet carrying OSPF data, indicated by the protocol number of 89. When OSPF packets are multicast, their TTL is set to 1, as can be seen here. Because 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 8-29, so that these processes will give a high priority to OSPF packets. Figure 8-29. 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. Packet HeaderAll OSPF packets begin with a 24-octet header, as shown in Figure 8-30. Figure 8-30. The OSPF packet header.
Table 8-8 lists the possible authentication modes.
Hello PacketThe Hello packet (Figure 8-31) establishes and maintains adjacencies. The Hello carries parameters on which neighbors must agree in order to form an adjacency. Figure 8-31. The OSPF Hello packet.
Database Description PacketThe Database Description packet (Figure 8-32) 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 the headers of the LSAs; the LSA header contains enough information to identify not only a particular LSA but also the most recent instance of that LSA. Because multiple DD packets may be exchanged during the database description process, flags are included for managing the exchange via a master/slave polling relationship. Figure 8-32. The OSPF Database Description packet.
Link State Request PacketAs Database Description packets are received during the database synchronization process, a router takes 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 then sends one or more Link State Request packets (Figure 8-33) asking the neighbor for its copy of the LSAs on the Link State Request list. 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. This procedure protects against a situation in which the neighbor might acquire or originate a more recent copy of the LSA between the time it last described the LSA and the time a copy of it is requested. Figure 8-33. The OSPF Link State Request packet.
Link State Update PacketThe Link State Update packet, shown in Figure 8-34, 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, carries the LSAs only to the originating router's connected neighbors. The receiving neighbor is responsible for re-encapsulating the appropriate LSAs in new LS Update packets for further flooding to its own neighbors. Figure 8-34. The OSPF Link State Update packet.
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 Acknowledgement packet. The LSA being acknowledged is identified by including its header in the LS ACK packet, and multiple LSAs can be acknowledged in a single packet. As Figure 8-35 shows, the LS ACK packet consists of nothing more than an OSPF packet header and a list of LSA headers. Figure 8-35. The OSPF Link State Acknowledgment packet.
OSPF LSA FormatsThis section details the fields of LSA types 1-5 and 7. The Group Membership LSA (type 6) is not discussed because MOSPF is not covered in this book. Similarly, LSA types 8 through 11 are not covered because they either are not in general deployment (type 8) or because they are used to support capabilities that are outside of the scope of this book. LSA HeaderThe LSA header (Figure 8-36) 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 8-36. The OSPF LSA header.
Router LSAA Router LSA (Figure 8-37) is produced by every router. It lists a router's links, or interfaces, along with the state and the outgoing cost of each link and any known neighbors on the link. These LSAs are flooded only within the area in which they are originated. The command show ip ospf database router (refer to Example 8-11) 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 8-37. OSPF Router LSA.
Network LSANetwork LSAs (Figure 8-38) 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 (Example 8-12) is used to observe a Network LSA. Figure 8-38. The OSPF Network LSA.
Network and ASBR Summary LSAsThe Network Summary LSA (type 3) and the ASBR Summary LSA (type 4) have an identical format, shown in Figure 8-39. 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 (Example 8-13), and ASBR Summary LSAs can be observed with show ip ospf database asbr-summary (Example 8-14). Figure 8-39. The OSPF Summary LSA. The format is the same for both type 3 and type 4 Summary LSAs.
Autonomous System External LSAAutonomous System External LSAs (Figure 8-40) 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 (Example 8-15). Figure 8-40. The OSPF Autonomous System External LSA.
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. NSSA External LSANSSA External LSAs are originated by ASBRs within an NSSA (not-so-stubby area). All fields of the NSSA External LSA (Figure 8-41) 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 (Example 8-16). Figure 8-41. OSPF NSSA External 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. Options FieldThe Options field (Figure 8-42) 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 8-42. The OSPF Options field.
DN is used with MPLS-based layer 3 Virtual Private Networks (VPN), commonly called RFC 2547 VPNs after the RFC that specifies them. When a route is learned from a customer network via OSPF, is advertised across the RFC 2547 VPN using Multiprotocol BGP, and then is advertised back to a customer network via OSPF, a loop can occur in which the OSPF route is redistributed back to the VPN provider network in BGP. The DN bit prevents this looping. When the DN bit is set in a type 3, 5, or 7 LSA, the receiving router cannot use that LSA in its OSPF route calculations. O is set to indicate that the originating router supports Opaque (type 9, 10, and 11) LSAs. 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 in general usage and are not covered in this book. N is used only in Hello packets. A router sets 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. MT, when set, indicates that the originating router supports Multitopology OSPF (MT-OSPF). MT-OSPF, as of this writing, is only a proposal and has not yet found general adoption. Older OSPF standards specified that the options bit position now occupied by the MT bit was the T bit. T was set when the originating router is capable of supporting TOS. However, because the TOS capability was never deployed, the T bit was also never used. |