OSPF Router IDs
Before an OSPF router can send any OSPF messages, it must choose a unique 32-bit identifier called the OSPF router identifier(RID). Cisco routers use following sequence to choose RID-Use router-id id subcommand under router ospf.
-Use the highest numeric IP address on any currently nonshutdown loopback interface that has not yet been allocated as a RID by any other OSPF process.
-Use the highest numeric IP address on any currently nonshutdown, nonloopback interface that has not yet been allocated as a RID by any other OSPF process.
Multiple OSPF processes running on a single router try to choose unique RIDs. Each of the OSPF processes performs the same three steps to choose a RID, skipping IP addresses that have already been used as RIDs by other OSPF processes running on the router.
It is sufficient for the interface to be in the down/down state to be considered by OSPF as a prospective interface for RID selection.
OSPF does not have to advertise a route to reach the RID’s subnet.
The RID does not have to be reachable per the IP routing table.
Routers consider changing the OSPF RID when the OSPF process is restarted, or when the RID is changed through configuration. If a router’s RID changes, the rest of the routers in the same area will have to perform a new SPF calculation, even if the network topology has not changed. The reason is that a RID change is indistinguishable from a process of replacing one router with another.
Becoming Neighbors, Exchanging Databases, and Becoming Adjacent
The LSAs themselves are not OSPF messages. An LSA is a data structure, held inside a router’s LSDB and exchanged inside LSU messages.
OSPF Neighbor States
Down: Initial state for a neighbor. Mostly seen when a working adjacency to a neighbor is torn down or when a manually configured neighbor does not respond to our initial Hello packets. Note that having a neighbor in the Down state implies that the router already knows about this neighbor’s IP address.
Attempt: This state is valid only on nonbroadcast multiaccess (NBMA) and point-to-multipoint nonbroadcast networks. On these networks, a neighbor is immediately placed into the Attempt state and contacted by Hello packets sent at usual intervals.
Init: This router can hear the other router but it is not certain whether the other router can hear this router.
2-Way: This state confirms a bidirectional visibility between the two routers. The 2-Way is a stable state between routers on multiaccess networks that do not intend to become fully adjacent.
ExStart: The purpose of the ExStart state is to establish the Master/Slave relationship. In the ExStart state, routers exchange empty Database Description packets to compare their Router IDs, determine the Master and Slave roles for each
router, and agree on a common starting sequence number used to acknowledge subsequent Database Description packets used in the Exchange state.
Exchange: During this state, Database Description packets are exchanged between the routers carrying the list of link-state database elements(list of LSAs; not the LSA data itself.) known by each router. Each router builds a list of LSAs to be subsequently downloaded from the other router.
Loading: A neighbor is moved from the Exchange to Loading state after it has advertised the complete list of LSAs and this router needs to download some of the LSAs from the neighbor. The neighbor is kept in the Loading state during the LSA download.
Full: A neighbor is moved from the Exchange or Loading state to the Full state when all required LSAs have been downloaded from the neighbor, so all missing or outdated LSAs have been acquired. The Full state is a stable state between routers that have become fully adjacent.
Becoming Neighbors: The Hello Process
To discover neighbors, Cisco OSPF routers listen for multicast Hello messages sent to 224.0.0.5—the All OSPF Routers multicast address—on any interfaces that have been enabled for OSPF. The Hellos are sourced from that router’s primary IP address on the interface. After two routers discover each other by receiving Hellos from the other router, the routers perform the following parameter checks based on the receive Hellos:
-Must pass the authentication process
-Must be in the same primary subnet, including the same subnet mask
-Must be in the same OSPF area
-Must be of the same area type (regular, stub, not-so-stubby area[NSSA])
-Must not have duplicate RIDs
-OSPF Hello and Dead timers must be equal
If any of these items do not match, the two routers simply do not form a neighbor relationship. OSPF process ID doesn't have to match. The maximum transmission unit (MTU) must be equal for the DD packets to be successfully processed between neighbors, but this parameter check is technically not part of the Hello process. The MTU mismatch would negatively affect the database synchronization process in the ExStart and Exchange phases.
The third function of Hello packets is to verify bidirectional visibility between routers on the same segment. Each Hello packet contains a list of neighbors from whom the sending router received valid and acceptable Hellos. If a router finds its own RID in the list of seen routers in a Hello received from a neighbor, it can be sure that they can hear each other.
Finally, the fourth important function for a Hello is to maintain a heartbeat function between neighbors. The neighbors send Hellos every hello interval; failure to receive a Hello within the longer dead interval causes a router to believe that its neighbor has failed. The hello interval defaults to 10 seconds on interfaces with an OSPF broadcast or point-to-point network type, and 30 seconds on interfaces with an OSPF nonbroadcast or point-to-multipoint network type; the dead interval defaults to four times the hello interval. Use debug ip ospf hello for debugging.
Transmitting LSA Headers to Neighbors
When two routers hear Hellos, and the parameter check passes, each router creates and sends Database Description(DD, or sometimes called DBD)packets, which contain the headers of each LSA. The routers exchange an index list of all the LSAs they each know about; the next step in the process is letting a router request a new copy of only those LSAs it does not have or which are less recent. Each DD packet, which can contain several LSA headers, has a sequence number assigned. The receiver acknowledges a received DD packet by sending a DD packet with the identical sequence number back to the sender.
Database Description Exchange: Master/Slave Relationship
the neighbors determine which router is to be the master and which is to be the slave during the database exchange between them. The roles of master and slave define the responsibilities of routers during the exchange of DD packets. Only the master is allowed to send DD packets on its own accord as well as to set and increase their sequence numbers. A slave is allowed to send a DD packet only as a response to a DD packet received from master router, and must use the same sequence number.
Among other fields, a DD packet header contains three flags:Master(MS) flag, More(M) flag, Init(I) flag. There are two rules to sending DD packets that must be observed at all times: 1. Each DD packet sent from the master must be replied to by the slave and 2.A slave can send a DD packet only as a response to receiving a master’s DD packet.
In situation where slave holds more LSAs in its database than master's, the slave set the M flag in its DD packet sent in response to the master’s DD packet. If the master receives a DD packet from the slave with the M flag set, it knows that the slave has at least one more DD packet to send, so it must poll it again. A master will stop send sending DD packets to a slave when it has no more LSA headers to advertise, and the slave’s last received DD packet has the M flag cleared.
In the beginning of the exchange, each router places the other into the ExStart state. Each of them considers itself to be the master, and sends an empty DD packet to the other router, containing a randomly chosen sequence number, and MS(Master), M(More), and I(Init) flags set to 1. After receiving the neighbor’s DD packet, however, the router with the lower RID will change its role to slave, and it will respond with a DD packet with MS and I flags cleared and the sequence number set to the sequence number of master’s DD packet. This accomplishes the master/slave selection, and both routers move to the Exchange state. The master will then send a DD packet with the sequence number incremented by 1, optionally containing one or more LSA headers, and the slave will respond with a DD packet reusing the same sequence number from the received packet, optionally advertising its own LSA headers. The exchange continues in the same fashion, with the master incrementing the sequence number of each subsequent DD packet, until both routers have advertised all known all LSA headers.
Requesting, Getting, and Acknowledging LSAs
After all LSA headers have been exchanged using DD packets, each neighboring router has a list of LSAs known by the neighbor. Using that knowledge, a router needs to request a full copy of each LSA that is missing from its own LSDB. To know whether a neighbor has a more recent copy of a particular LSA, a router looks at the sequence number of the LSA in its LSDB and compares it to the sequence number of that same LSA learned from the DD packet. Routers use Link-State Request(LSR) packets to request one or more LSAs from a neighbor. The neighboring router replies with Link-State Update (LSU) packets, which hold one or more full LSAs. Both routers sit in a Loading state while the LSR/LSA process continues. After the process is complete, they settle into a Full state.
Designated Routers on LANs
OSPF optimizes the LSA flooding process on multiaccess data links by using the concept of a designated router(DR). They create a type 2 LSA that represents the multiaccess network segment.
Designated Router Optimization on LANs
If the DR or BDR needs to send an update, it simply does it directly by sending an LSU packet containing the updated LSA to the multicast IP address 224.0.0.5, the All OSPF Routers group. A router on a multiaccess segment that is neither DR nor BDR is in the Full state only with the DR and BDR. If it needs to send an update, it sends an LSU packet to the multicast IP address 224.0.0.6, the All OSPF DR Routers group. Neither the DR nor BDR acknowledge the original LSU with an LSAck. Instead, the LSU flooded by the DR serves as an implicit acknowledgment to the original router that sent the update. Other routers on the segment including the BDR, except the original router, will acknowledge the DR’s LSU with a unicast LSAck sent to the DR. When a DR is used on a link, a router that is neither a DR or a BDR is called a DROther router. Two neighbors that are both DROthers do not become fully adjacent; they stop at the 2-Way state.
To describe the fact that some neighbors do not directly exchange DD and LSU packets, OSPF makes a distinction between the terms neighbors and adjacent, as follows:
-Neighbors: Two routers that share a common data link and that exchange Hello messages, and the Hellos must match for certain parameters.
-Adjacent(fully adjacent): Two neighbors that have completed the process of fully exchanging DD and LSU packets directly between each other.
DR Election on LANs
The election occurs after the routers have become neighbors, but before they send DD packets and reach the ExStart neighbor state. When an OSPF router reaches the 2-Way state with the first neighbor on an interface, it has already received at least one Hello from that neighbor. If the Hello messages state a DR of 0.0.0.0—meaning that none have been elected—the router waits before attempting to elect a DR wait with the goal of giving all the routers on that subnet a chance to finish initializing after a failure so that all the routers can participate in the DR election. The wait time period is called the OSPF wait time, which is set to the same value as the Dead timer. However, if the received Hellos already list the DR’s RID, the router does not have to wait before beginning the election process. The router does not attempt to elect a new DR, assuming that the DR listed in the received Hello is indeed the current DR. Generally speaking, the following rules govern the DR/BDR election process:
-Any router with its OSPF priority set to 1–255 inclusive is eligible to become a DR or BDR. A router with its OSPF priority set to 0 is ignored in DR/BDR elections.
-Each router performs the elections locally based on the collected data from other neighbors on the segment;
-During the wait interval, whose length is automatically set to the Dead interval on the interface, each router collects the priorities and RIDs of other neighbors on the segment by listening to received Hellos, adding its own RID and priority to the list as well. However, a router does not assert itself as the DR or BDR during the wait interval, and all Hellos it sends indicate that the DR and BDR are not yet elected.
-If, during the wait interval, a Hello packet arrives from a neighbor that claims itself to be the BDR or if a neighbor that claims to be the DR and no BDR address is indicated in the Hello, the router immediately proceeds to the DR/BDR election process. Otherwise, the full wait interval period on the interface needs to expire.
-The election is performed only for those roles that are not yet claimed in neighbor Hellos(either both DR and BDR, or just BDR). A router examines the list of priorities and RIDs it has collected over the wait interval, choosing the router with the highest priority as the DR. If multiple routers advertise the same highest or second-highest priority, still competing for the role of DR or BDR, the higher RID is used to break the tie.
-After the election has completed, if a new router arrives or an existing router improves its priority, it cannot preempt the existing DR and take over as DR (or as BDR).
-When a DR is elected and the DR fails, the BDR becomes the DR, and a new election is held for a new BDR only.
Designated Routers on WANs and OSPF Network Types
Not using a DR on a point-to-point WAN link makes sense.
Cisco router interfaces can be configured to use, or not use, a DR, plus a couple of other key behaviors, based on the OSPF network type for each interface. The OSPF network type determines that router’s behavior regarding the following:
-Whether the router tries to elect a DR on that interface
-Whether the router must statically configure a neighbor(with the neighbor command), or find neighbors using the typical multicast Hello packets
-Whether more than two neighbors should be allowed on the same subnet.
The interface type values can be set with the ip ospf network type interface subcommand.
Caveats Regarding OSPF Network Types over NBMA Networks
The key items you should check when looking at an OSPF configuration over Frame Relay, when the OSPF network types used on the various routers do not match:
-Make sure that the default Hello/Dead timers do not cause the Hello parameter check to fail.
-If one router expects a DR to be elected, and the other does not, the neighbors might come up and full LSAs be communicated. However, show command output might show odd information, and next-hop routers might not be reachable. So, make sure that all routers in the same NBMA subnet use an OSPF network type that either uses a DR or does not.
-If a DR is used, the DR and BDR must have a permanent virtual circuit (PVC) to every other router in the subnet. If not, routers will not be able to learn routes. Routers that do not have a PVC to every other router must not be permitted to become a DR/BDR.
-If neighbors need to be configured statically, configuring the neighbor command on a single router is sufficient to bring up the OSPF adjacency with the configured neighbor. For clarity and stability, however, it is better to configure neighbor commands on both routers.
Two simple options exist for making OSPF work over Frame Relay—both of which do not require a DR and do not require neighbor commands. If the design allows for the use of point-to-point subinterfaces, use those and take the default OSPF network type of point-to-point, and no additional work is required. If multipoint subinterfaces are needed, or if the configuration must not use subinterfaces, adding the ip ospf network point-to-multipoint command on all the routers works.
Example of OSPF Network Types and NBMA
On NBMA networks with an OSPF network type that requires that a DR be elected, make sure that the correct DR is elected. The DR and BDR must each have a PVC connecting them to all the DROther routers and to each other. With partial meshes, the election should be influenced by configuring the routers’ priority and RIDs such that the hub site of a hub-and-spoke partial mesh becomes the DR.The priority specified in the neighbor command is never used in DR/BDR elections. For that purpose, exclusively the interface priority configured by the ip ospf priority interface command is taken into account. However, if there are multiple neighbor statements configured and at least one of them has a nonzero priority specified in the statement (the default neighbor priority setting is 0 when unspecified), the router will first send Hello packets only to those neighbors with a nonzero priority. Only after DR/BDR elections have completed between these routers, the router will start sending Hello packets to all remaining neighbors.
The priorities specified in the neighbor commands do not need to match the real priorities of these neighbors, but if they differ, the router can engage in DR/BDR elections with neighbors not entitled to become a DR/BDR. In any case, though, real priorities of these neighbors as seen in their Hello packets will be used to complete the DR/BDR elections.
Also, if the neighbors are reachable over an interface whose priority has been set to 0 using the ip ospf priority command, the router will automatically remove all corresponding neighbor statements from the configuration. This behavior prevents the router from participating in any way in the DR/BDR elections. This forces the router to wait for its neighbors to contact it. The router knows about no neighbors on its own, and is dependent on the DR and BDR contacting it thanks to their own neighbor statements.
SPF Calculation
After a router has new or different information in its LSDB, it uses the Dijkstra SPF algorithm to examine the LSAs in the LSDB and derive the new tree of shortest paths to available destinations.
Steady-State Operation
-Each router sends Hellos, based on per-interface hello intervals.
-Each router expects to receive Hellos from neighbors within the dead interval on each interface; if not, the neighbor is considered to have failed.
-Each router originally advertising an LSA refloods each LSA (after incrementing its sequence number by 1) based on a per-LSA Link-State Refresh (LSRefresh) interval(default 30 min).
-Each router expects to have its LSA refreshed within each LSA’s MaxAge timer(default 60 min)
No comments:
Post a Comment