Most people will agree with me when I say that OSPF has ‘more to it’ than EIGRP does. Some might argue that it’s more complicated than EIGRP is. My opinion falls somewhere in the middle on that matter. Either way, OSPF has it’s place and is well known for being ‘standard’ based. The argument generally comes down to the fact that EIGRP is Cisco proprietary (that might actually be changing now) and OSPF is based on a open standard. Most people like to keep routing ‘vendor neutral’ so that at some point, they could switch to someone else without causing too much trouble.
OSPF is considered to be a link state protocol. As we discussed earlier, link state protocols share their updates will all of the routers, not just neighboring ones. When this is done, each router has the entire view of the network and current link state so it can make it’s own decision about what the best path is.
Before a router can hear updates from other routers, neighboring routers must become adjacent, or become neighbors. The process for becoming a neighbor is much like any other routing protocol. Two neighboring router’s will exchange hello messages to notify each other of their presence. In order for the router’s to become neighbors, they must pass the following parameter checks…
-If authentication is configured, it must pass
-The routers must be in the same subnet with matching subnet masks
-The routers must be in the same OSPF ‘area’ (more on this later)
-The routers must be of the same ‘type’ (more on this later)
-The router IDs must be distinct
-The OSPF hello and dead timers must match
Let’s talk a little bit about the router ID (RID). The RID can be manually configured using the ‘router-id <ID>’ subcommand of the ‘router OSPF <process>’ configuration. If it isn’t configured, then OSPF will choose one for you. It does so by picking the highest IP address on any currently ‘up’ loopback interface. If there isn’t a loopback, it will choose the highest IP configured on any ‘up’ non-loopback interface. Seems pretty straight forward right? Mostly… There is another set of rules that are also applied to the RIDs. The RID is picked when the OSPF process is started. However, it can be changed during operation by manually configuring the RID. If changed in this manner, each router has to rebuild the neighbor relationship. That being said, it’s best practice to set the router ID manually. For instance, let’s look at this topology…
Assuming that we already have OSPF up and running, let’s take a look at the neighbor table on router4…
As you can see, we don’t have the RIDs manually configured nor do we have any loopbacks configured. The RIDs were chosen based on the highest configured IP available. While not impossible to discern which router is which neighbor, I think it’s easier to just configure the RID and call it a day. Let’s see what happens when router4 updates it’s RID…
Actually, nothing happens except it warns you to clear your OSPF process for the change to take effect. A look at the OSPF hellos being sent by router4 still shows the old RID…
Let’s clear the process and examine what occurs between router4 and router5…
As we thought, router 4 drops all of it’s neighbors and essentially starts over. Good news is that the RID is now updated…
Since we are starting to look at captures, it’s pretty easy to see that OSPF uses the multicast address of 224.0.0.5 to send it’s hellos. The 224.0.0.5 address is designated as the ‘All OSPF routers’ address. OSPF also uses the 224.0.0.26 address to signal OSPF ‘designated routers’. More to come on the designated router role later.
So let’s update all of our RIDs in a similar fashion…
Router1 – 1.1.1.1
Router2 – 2.2.2.2
Router3 – 3.3.3.3
Router4 – 4.4.4.4
Router5 – 5.5.5.5
Router6 – 6.6.6.6
Switch1 – 9.9.9.9
Now, let’s talk about how OSPF router’s form adjacencies with neighboring routers. Let’s observe what occurs when an OSPF adjacency forms between router5 and router6…
We can see the peering process in this capture. As you can see, it starts with router5 (10.0.0.29) sending it’s multicast hellos out onto the wire. At packet 90, you can see that router6 is also now sending hellos onto the wire.
We can see the adjacency starting to form as early as packet 99.
Here router5 is reporting that it has ‘seen’ router6 by listing router6’s RID as the active router ID. This initial process of exchanging hellos is referred to as the Init (sending hello’s) and 2-way (replying back that you’ve seen the neighbor) phases. The next phase that occurs is called ExStart. The ExStart process begins by electing a master and slave router. The router with the highest RID will become the master and will initiate the database exchange. Let’s watch the ExStart phase in action…
The first stage of ExStart is each router’ sending an empty database descriptor (DD) packet to the neighbor claiming to be the master. We can see that router5 is claiming to be the master in the above packet since the ‘Master/Slave’ bit is set…
At the same time router6 is also claiming to be the master by sending an empty DD packet with the Maser/Slave bit also sent. At this point, we consider the ExStart phase complete since we now know who the master and slave router is. The next piece is what can be slightly confusing. Since router6 has the highest RID, it is the master. However, the next packet we see on the wire is this one…
All of a sudden router5 sends a DD packet with a list of LSA summaries. Shouldn’t that be router6’s job to do? This is actually the beginning of the exchange phase. Note that the sequence number is still 6789. Since router5 isn’t the master he can’t increment the sequence number. We can also tell router5 is the slave in the above packet because the master/slave bit is not set.
This packet shows the master (router6) sharing his link state database with the slave (router5). Note that the sequence number has incremented and that the master/slave bit is set. At this point, we are still in the exchange phase.
The last packet of the exchange phase shows router5 ack’ing router 6 by sending a empty DD packet back with the same sequence. It appears that the ‘ack’ process for the exchange includes the slave sending a response with the same sequence number OR the master sending a response with an incremented sequence number.
I didn’t catch this at first, but did anyone else see that router6 is offering up a whole lot of LSAs for only being connected to router5? It surprised me at first, but then I realized that I had built the connection between the two router’s multiple times before in my lab. The LSA’s stay in the link state database until they are aged out. This occurs when the ‘max age’ time expires. By default the max ager timer is 60 minutes. I haven’t seen a way to configure this yet but when I do I’ll be sure to mention it. Since we are talking about timers, it’s probably worth mentioning that the default hello timer is 10 seconds and the default dead timer is 40 seconds. If 4 hello’s are missed a OSPF neighbor is considered to be down.
That being said, let’s reboot router6 and start with a fresh capture so we can see the actual initial adjacency setup…
In this capture, packets 33 and 36 show the master/slave election (ExStart phase) that we outlined above. In this case, router6 is still going to be elected the master based on the higher RID. Packet 37 shows router5 starting the ExStart phase by sending it’s list of LSA headers (just like the first example)…
We can see in packet 38 that rouer6 is offering up it’s list of LSAs with a sequence of 2569 with Master/Slave bit set. Note that this time, it’s only sending one LSA header which is what we’d expect to see during a first time connection with router5…
Packet 39 shows router5 ack’ing this by sending a DD packet with the master/slave bit not set and the same sequence of 2569…
At this point, we’ve completed the exchange phase, but if you take a look at the information exchanged, you’ll see that we don’t actually have any prefix information in the updates…
The exchange phase only shares LSA header information with the neighboring router. The next phase ,the loading phase, is where we actually exchange the prefix information.
Let’s quickly summarize where we are at this point. Each router started in the init phase and then detected each other’s hellos during the 2-way phase. After that the ExStart phase began and the router’s elected a master and slave router. Once that happened, we started the exchange phase by having the master router send it’s entire list of LSA headers to the slave. At this point, the router’s have shared the header information from their link state databases and it’s time to get more specific information in the loading phase.
The loading phase consists of the routers using link state request (LSR), link state update (LSu), and link state ack (LSA) packets to exchange any other information they require. The process starts for us at packet 40…
In this packet (above), we can see that router6 is requesting a bunch of router and network LSAs. Don’t worry about what a LSA is at this point, just know that it refers to information about a specific OSPF router or a specific network. The next packet is router5’s reply…
In this packet (above) router5 replies back as requested with all the information is has about the requested LSAs. The next few packets are a little confusing (in my opinion). We see the beginning of the LSA flooding to notify other router’s of these new LSAs. As you can see, in packet 42…
Router6 is generating a router LSA (above) to tell all the other router’s (sent to the all OSPF router’s multicast address of 224.0.0.5) about his new router LSA. In packet 43…
We see router5 (above) doing the same by sending an updated router LSA which now includes his link to router6.
Packet 44 (above) shows that in addition to the router LSA being updated, router5 is also sending a network LSA to tell other routers about the new link between router5 and router6.
Packet 47 (above) shows router5 ack’ing router6’s LSA update sent in packet 42. You can tell that it’s matching that packet based on the LS sequence number matching.
Packet 48 (above) from router6 is an interesting one. It’s router6 ack’ing the initial LS update sent from router5 in packet 41. Note that there were 13 updates sent in packet 41 but in this packet, we are ack’ing 15 updates. Router6 waited to send the ack and before sending it saw the two other updates that router5 sent in packets 43 and 44. This packet is ack’ing all 3 updates. An important note to remember here is that router’s can chose to wait a period of time before sending an ACK so that they can reply to multiple updates at once.
Finally in packet 51 we see router6 sending an update (very similar to packet 42) updating the router LSA and telling everyone that it’s link to router5 is no longer a stub link, but rather a transit link…
Packet 56 is router5 ack’ing this last update (not shown).
At this point the router’s have completed the exchange phase and are now considered to be in the ‘full’ state. The router’s are now completely adjacent and will fall back to exchanging hellos until the next topology change.
I’m sure there are still a lot of open questions since I talked about some items which we haven’t yet covered. I’ll do my best in the next post to clear up any questions you might have at this point.
s/224.0.0.26/224.0.0.6/g
🙂