Misconfiguring OSPF

OSPF was the first routing protocol that I learned mostly because of its prominence in the CCNA and though I found it interesting, most of my time recently has been spent learning BGP and IS-IS. I recently built a topology to revisit OSPF areas and neighbor relationships. After tinkering around with some of the configuration and looking through some wireshark packet captures, I discovered (or rediscovered?) some interesting behaviors.

Before diving into the different types of areas, I started with the neighboring process itself. Like any computer protocol, there is a set of steps that two communicating routers step through before the OSPF process is considered up. I’ve seen the relationship form a lot but since I’m studying it again, it’s more beneficial to break the process instead. I originally turned debugging on for OSPF adjacencies and was quickly reminded that it basically just tells you what is wrong with the OSPF configuration. Cisco did a great job with both the name of the debug message and the message itself. Seriously, any misconfigured settings are indicated in the name of the OSPF log message and inside the message itself. Wanting a bit more of a real world environment, I just turned debugging off to try to find if any of these misconfigurations have unique signs.

Happily, some of them do! The one mismatch that you cannot miss is if there is an area mismatch with the backbone area. IOS will keep logging this error to the console until you fix the problem. Clearly, Cisco has classified this misconfiguration as a highly undesirable one because any other area mismatch that doesn’t include area 0 is not logged insistently.

Most of the other misconfigurations are also much less prominently logged to the console. Some still can be traced uniquely. For example if the OSPF packets are being filtered between two routers, the process will be stuck in the INIT phase. Curious if debugging messages will indicate the problem explicitly, I turned it back on. Though there isn’t an explicit message, the debugger will complain about an excessive amount of retransmissions. I did something similar with EIGRP peerings and retransmissions seem to be a big indicator of a transport problem.

Another thing that will result in a suspension of the neighbor process is an MTU mismatch. In my lab, the routers are suspended in the EXSTART state when one has the default MTU and another has one set to 1400.

The most interesting misconfiguration was network type simply because there are so many different OSPF networks. I first tried the two most common network types, point-to-point and broadcast, and was surprised to see the relationship proceed to FULL! The routers do not exchange any routes with each other, however. Looking at the packet capture, the link information in LSA-1 packets is not fully described. I’ve shown the difference between the LSA updates for misconfigured and correctly configured neighbors below.

LSA update from misconfigured network type neighbors. No link information.
LSA update from the same router as above. Much more information included.

I then configured one neighbor as a point-to-multipoint and the other as a point-to-point network. Initially, the neighboring goes down completely, which makes sense. The point-to-multipoint network has a hello timer of 30 and a dead/hold timer of 120 which is completely different from the point-to-point network’s default timers. I haven’t configured point-to-multipoint networks that often before and did a bit of research at this point. Apparently, the point-to-multipoint network is conceptually a set of point-to-point links and does not involve the DR/BDR election process. I decided to change the hello timer for the point-to-multipoint configured router and the neighboring proceeded to FULL! They both exchanged routes and everything.

Changing the HELLO timer for a point-to-multipoint configured router allows it to form a FULL adjacency with a point-to-point neighbor!

Perhaps the strangest pairing I performed was the non-broadcast with point-to-point. This is another one of networks that I haven’t worked with often and I again had to do some research. The non-broadcast moniker implies that when a packet is sent, there is no guarantee that it will be received by all connected devices. This type of network was used with older networks like frame relay and ATM, some of which required extra configuration in order to ensure that hello messages could be received by neighboring routers. Instead of sending hellos to the typical multicast, they are sent by unicast to each neighbor instead. So this configuration is not unlike named mode unicast EIGRP or even regular BGP where neighbors need to be configured manually.

Non-broadcast OSPF networks share the same timers as broadcast and point-to-point networks and once again the two routers proceeded to a FULL adjacency. Just like the broadcast/point-to-point “adjacency” there were no actual routes exchanged. I did not configure the neighbor statement by the way. In the wireshark consul, there were no packets, unicast or multicast, from the non-broadcast configured router but the FULL adjacency was a big surprise to me.

None of the other misconfigurations were all that interesting. It is worth noting that a lot of the misconfigurations were logged once immediately after the feature was (mis)configured so filtering a router’s log for OSPF adjacencies is a viable way of troubleshooting neighboring issues. Otherwise, the go-to show commands were show ip ospf int IF_NAME, show ip ospf PROCESS and show ip ospf neighbors.

Let’s move on to OSPF areas. There actually isn’t a lot to discuss in terms of misconfigurations. Here’s a quick walk through of the topology below. All the border routers are in the backbone area except the border router in the NSSA area. Area 1 is a regular area but it is a transit area because it’s attached to R51, which is in the orphaned area 51. I’ve mainly set that up to study virtual links. Area 2 is a stub area and area 3 is an NSSA. E1 is an eBGP peer with the ASBR and E2 is an eBGP peer with NSSA1. Most of the neighbors are using a point-to-point OSPF network but some are also using the default broadcast network so that all the standard LSA types are advertised in this topology.

OSPF Topology. Area 1 is a normal area. Area 2 is a stub area. Area 3 is an NSSA and Area 51 is orphaned. E1 and E2 are external routers that have eBGP peerings with their connected routers.

The OSPF hello packet holds a list of options that advertises what type of area the router is in. By default, all routers have the external bit set and are willing to accept external routes (LSA type 5.) When a stub area is configured, the external bit is turned off. If the bits don’t match, two routers will not form a relationship. If you want to restrict LSA type 3s from entering the area then you need to configure that at the ABR. Just prepend no-summary to the stub configuration.

NSSAs are configured the same way as stubs and the only difference between the two is the existence of LSA-7s. One thing that I did forget was that these special LSAs only exist in NSSAs. The ABR(s) convert LSA-7s to LSA-5s when advertising these external routes into the backbone area. The rest of the ABRs continue advertising the external routes as LSA-5s. Of course, LSA-4s with the information about the ASBR are generated for every LSA-5 that’s generated. OSPF ABRs are busy routers.

I did stumble into something interesting when I was configuring a virtual link. It seems that if the router-id corresponds to the physical interface addresses that are the endpoints of the connection between two routers, the virtual link will not establish. For example, let’s say that R3 connects to R7 and their IP addresses are and respectively. Their router IDs are also set to these IPs respectively and the virtual link is configured using these router IDs. The virtual link will not form in this situation.

A virtual link only forms if the router IDs do not match the physical IPs between two routers.

If you change the router IDs on one of the routers to be any other valid number then the virtual link establishes right away. Even if the router ID that you change to corresponds to another physical interface the virtual link will come up. It’s a really specific and niche situation but I’m glad I found it.

The virtual link forming after changing the router ID.

There are other LSAs that I didn’t generate like LSA-8 and LSA-9 because they only show up in OSPFv3 with IPv6 routing. Also, the opaque LSA, LSA-10, is used for traffic engineering so exploring those make more sense when studying something like MPLS. Still, OSPF distributing up to 8 LSAs (sorry LSA-6) makes it a more complex routing protocol to learn compared to something like EIGRP. I remembered a lot of the details from when I first studied OSPF but doing these labs periodically is a good way to refresh the information.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: