In this article I will write about the OSPF routing protocol and give a quick overview of the inner workings. OSPF is a link state routing protocol as opposed to a distance vector protocol like RIP. You might be wondering what type of a protocol EIGRP falls under? EIGRP is categorized as an advanced distance vector protocol as it uses the DUAL algorithm rather than the Bellman Ford algorithm used by RIP. OSPF is based on Dijkstra’s Shortest Path First algorithm which computationally is more intensive than the others but gives us a lot more features and tuning capabilities than the other two.

The network that we will be implementing is the following:


The above diagram features a network with 3 different  OSPF areas. Our backbone area 0 has three routers in the same network with R2 and R4 being Area Boundary Routers(ABRs) that connect us to areas 45 and 32. Lastly, notice that R1 is an autonomous system boundary router(ASBR) that is connected to an external EIGRP network. R3 and R5 are both simulating local networks that reside in these areas via loopback interfaces that we will using for testing purposes.

There are some important concepts that we must know about OSPF networks before we start with the implementation. The OSPF backbone area also known as area 0 must connect to all other areas. This means that all areas must somehow connect to area 0 via an ABR or otherwise it will break the rules of OSPF. The goal of OSPF is to localize updates within an area and then have ABRs be the messengers for inter area communications. Because of this area design of OSPF, all routers within an area will share the same topology network. It is important for an area to have similar networks so that we can do summarization and therefore decrease the size of the routing table. Unlike EIGRP, where we can summarize at any router, in OSPF summarization is only allowed at the ABRs and ASBRs.

Let’s start by assigning the IP addresses to the different interfaces and executing basic ping test to make sure that everything works.

We will focus on area 0 at the moment and then we will move towards the other areas afterwards. In R1 we will go ahead and enable OSPF via the following command:

R1(config)#router ospf 25


R1(config-router)#network area 0

The first command will start the OSPF process on this router under an ID of 25. The OSPF process ID does NOT have to be the same on all your routers in your enterprise but for consistency purposes you should stick to the same ID. The second command will assign a router ID under this OSPF process for this device. The router ID in OSPF is important as there are advanced configurations that rely upon it unlike in EIGRP where the usage of the router ID is minimal. We must make sure that our OSPF devices have unique router IDs and if you don’t assign them manually then the following will happen:

  1. Highest IP address assigned to a loopback interface is selected
  2. If no loopback interfaces are configured then the highest IP address assigned to any other interface is selected.

Note that for rules one and two above the interface does not need to have OSPF enabled.

The last command above tells OSPF on which interfaces we should look for neighbors and what networks we should be advertising. Notice that OSPF takes an area parameter which means that the interface that matches this wildcard(See my EIGRP article for an explanation of how wildcards work) will be assigned to area 0. After enabling OSPF on interface f0/0 and assigning it to area 0 let’s take a look at the advertisements that we are sending out:


This is an OSPF Hello message sent to the multicast address This multicast address is used by OSPF to send Hello messages to all OSPF routers on this network segment. If we look into more detail we can see that the layer 2 destination MAC address is also a multicast address 01:00:5E:00:00:05 and in here the low order 23 bits map directly to the last 23 bits of the multicast IP address. We can tell that this is case because they both end with a 5.


At layer 3 we have some interesting fields starting with the TTL which is actually 1 unlike EIGRP or RIP. This makes sense since Hello messages are not supposed to leave this local network and if for some odd reason they do, then they will get killed as the TTL will get decremented to 0. Like EIGRP, OSPF also does not use TCP or UDP but instead it is using IP protocol 89 making it its own IP protocol.


Looking at the OSPF data within this Hello message we see that the OSPF Header has a version number of 2. OSPFv3 which is the most recent version supports IPv6 while version 2 supports IPv4. The message type tells us what type of information this OSPF packet carries. We can tell that the number is 1 and therefore it is a Hello packet. I have included a list of other OSPF message types that we will see going forward.

Message Number Message Type Description
1 Hello Used for Neighbor relationships and keepalives
2 Database Description Contain a summary of the router’s local database
3 Link State Request Used to query a neighbor specific topological information
4 Link state Update Used to send to neighbors specific topological information
5 Link state acknowledgement Acknowledge LSA that have been received. This is how OSPF provides reliability.

The source OSPF router list the router ID of the sender of this message. The next field list the area ID which matches area 0 that we configured for this interface. The network mask of the advertising interface is listed here because it has to match when the other router sends a hello message. OSPF requires neighbors to be in the same subnet or else the adjacency will never go up. We have the hello interval which is set to 10 seconds and this is the rate at which we will send out hello messages. The dead interval is 4 times the hello interval for OSPF and it is the time that we will wait for a reply from our neighbor before considering them dead. I have skipped the router priority and will also skip the designated router(DR) and backup designated router(BDR) fields as I will be explaining these later on.

At this point in time I will go ahead and configure OSPF on R4 and R2 to see what information we get when the neighbor relationship comes up.

R4(config)#router ospf 25


R4(config-router)#network area 45

R4(config-router)#network area 0

Go ahead and configure R2 in a similar manner. Note that I have configured the network that R4 is attached to and assigned it to be in area 45. You can similarly configure the network that R2 is attached to and have it be in area 32. Below is the first type of messages that we see from OSPF as a neighbor relationship starts to form and is simply the HELLO packet that we covered above.


Everything that I covered above for the hello packet applies to this one. Notice that there are certain values that match and this is because OSPF has certain conditions that must be met for routers to become neighbors. The values that have to match between routers in order for them to bring up their neighbor relationship are the following:

1. IP address of interfaces must be in the same subnet.
2. Both interfaces must be in the same area.
3. Both interfaces can’t be set to passive.
4. Hello and Dead interval must match.
5. Router IDs must be unique.
6. IP MTU must match.
7. No authentication mismatch should this be configured

Note, an IP MTU mismatch can allow the neighbor to be listed in the “show ip ospf neighbor” command but will prevent proper operation of the topology exchange.

We can see that all of the above match what R1 has and therefore they can go ahead and become neighbors. The next step is for them to exchange database description packets which contain a summary of a router’s local database. Here is a sample DB description message that gets sent from R1 to R2.


Starting at the top we have the usual information from OSPF with version number, message type which is 2 for database description, source OSPF router ID, area number, and whether there is any authentication. The important information here are the LSA headers which contain a summary of the OSPF database that R1 has. There are two type 1 LSAs, one type 2 LSA, and 1 type 3 LSA. I have included a table with the LSA Type, Name, and description courtesy of Wikipedia.

We will be focusing on LSA type 1-3 for now and then we will look into the other types as we progress through this lab.

LSA Type Name Description
1 Router The router announces its presence and lists the links to other routers or networks in the same area, together with the metrics to them. Type 1 LSAs are flooded across their own area only. The link-state ID of the type 1 LSA is the originating router ID.
2 Network The designated router (DR) on a broadcast segment (e.g. Ethernet) lists which routers are joined together by the segment. Type 2 LSAs are flooded across their own area only. The link-state ID of the type 2 LSA is the IP interface address of the DR.
3 Summary an Area Border Router (ABR) takes information it has learned on one of its attached areas and summarizes it before sending it out on other areas it is connected to. This summarization helps provide scalability by removing detailed topology information for other areas, because their routing information is summarized into just an address prefix and metric. The summarization process can also be configured to remove a lot of detailed address prefixes and replace them with a single summary prefix, also helping scalability. The link-state ID is the destination network number for type 3 LSAs.
4 ASBR This is needed because Type 5 External LSAs are flooded to all areas and the detailed next-hop information may not be available in those other areas. This is solved by an Area Border Router flooding the information for the router (i.e. the Autonomous System Boundary Router) where the type 5 originated. The link-state ID is the router ID of the described ASBR for type 4 LSAs.
5 External External LSA – these LSAs contain information imported into OSPF from other routing processes. They are flooded to all areas unchanged (except stub and NSSA areas). For “External Metric Type 1” LSAs routing decisions are made using the Type 1 metric cost sent, as the total cost to get to the external destination and includes the cost to the ASBR; while for “External Type 2” LSAs the metric sent is the cost from the ASBR to the External destination network and must be added to the OSPF cost to the ASBR advertising the Type 5. The link-state ID of the type 5 LSA is the external network number.
7 NSSA Routers in a Not-so-stubby-area (NSSA) do not receive external LSAs from Area Border Routers, but are allowed to send external routing information for redistribution. They use type 7 LSAs to tell the ABRs about these external routes, which the Area Border Router then translates to type 5 external LSAs and floods as normal to the rest of the OSPF network.

Before moving forward with the analysis, I will go ahead and talk about the Designated Router(DR) and Backup Designated Router (BDR) in OSPF. Consider the following scenario where you have multiple routers connected to the same broadcast network segment.


OSPF is an efficient protocol in that it will send full updates when neighbor relationships come up and triggered updates when there is a network change going forward. It will not waste bandwidth on your links by sending unnecessary messages unless they are required(e.g. Hello messages which are used as keep alives). Besides triggered updates, after 30 minutes routers will refresh any self-originated LSAs. The goal of a DR and BDR in a shared Ethernet segment is to reduce the amount of traffic that occurs between routers due to OSPF updates. If we were to map the number of connections in our example between devices should a DR not be present in this network then logically the diagram below is what it would look like. In this case we can see that every router has a connection to every other router so that when it has to send an update, it will reach all of its neighbors within that area.


Imagine if R3 had an interface that went down and as a result it triggered an OSPF update. R3 will send the message to all 4 routers who in turn would send it to everyone except out the interface where the messaged was received due to split horizon being in effect. This leads to an update storm and it will negatively affect the convergence time in the broadcast network segment. The purpose of a DR/BDR is to mitigate this effect. The DR and BDR election is based on two components, the first one being the priority and in case of a tie then the router ID becomes the tie breaker since router IDs have to be unique. The priority is by default set to 1 and this means that all routers are tied unless you modify it(we will configure this later on). The higher the priority the better the chances a router has as being elected as a DR/BDR and should there be a tie then it falls back to the router ID with the highest router ID winning. Suppose that in our above diagram R1 is elected as the DR and R2 is elected as the BDR then logically this is what we would have:


Going back to our example, suppose that R3 has an interface that went down. As before R3 will send a triggered update because something change but this time R3 will only communicate the change to R1 and R2. We know that OSPF relies on multicast for routing updates and it uses the address to communicate. R3 can’t use this address because all the routers are tuning into this address and therefore will get the message from R3 should it decide to use it. Instead, R1 and R2 both listen on the multicast address so that when R3 has an update it will send the message to the destination multicast address of R1 as the DR will then send the update to the other routers in the broadcast network segment using the multicast address as normal. The job of the BDR is to take over the role of the DR should it fail for some reason and is not reachable. This allows for a seamless transition without experiencing downtime.

Going back to the analysis, after R2 receives the DBD(database description) packet from R1 it will send a Link state request message requesting information about the LSAs in the DBD sent by R1. Below is the LS request message:


The message type is 3 which equates to a LSR. In here we see that R2 is requesting more information about the 4 LSAs that we previously saw. The next step is for R1 to send back a link state update with the information back to R2. The Link state update sent by R1 is below.



The message number for an LSU is 4 and it contains detailed information about each LSA. I will now move forward with the LSA type explanation. The Router type 1 LSAs are created by each router for each area that it connects to. A type 1 LSA will contain the router’s ID in the “link state ID” field. It also contains the advertising router’s router ID which in this case should match the link state ID field seeing as these are generated by each router. At the bottom we see that the type is set to transit which means that there are other routers located in this network as opposed to a stub network which leads to nowhere. The “ID” at the bottom of an LSA type 1 message designates the DR for this transit network and “Data” list our interface address in this network.

The type 2 LSA is generated when there is a multi-access network in place. In a multi access network there is always a DR and BDR elected and the DR goes on to generate the type 2 LSA. The Network LSA as it is called list the DR IP address for the link state ID since it is the one that generated it. The advertising router is the Router ID of the DR and data that it contains is all the routers that are attached to this multi access network which are R1 and R4.

Moving onto the type 3 LSA or Summary LSA(Inter Area Prefix is the name that I prefer) which is generated by ABRs represent the subnets in one area as they are advertised to another. This LSA was generated by router R4 and represents the network.

We have finished covering the basic operation of OSPF in this article and I will save the verification commands for part 2. Thank you for taking the time to read this article and I will see you here for the next section.

No Responses to “OSPF Configuration Overview Part 1”


  1. OSPF Configuration Overview Part 2 | HIGHLNK - […] is a follow-up article to part 1 of the OSPF configuration overview. In here we will go over some…

Leave a Reply