Open Shortest Path First (OSPF) is one of the most widely used IGP routing protocols. Implementing OSPF may not be a big deal but it is always a big deal to trouble-shoot OSPF. A network engineer has to take care of many aspects of configuration in order to deal with OSPF troubleshooting. And I know all of you are now very comfortable with OPSF implementation (Thanks to previous articles published here about OSPF).
In this article, we are going to learn how to trouble-shoot and resolve OSPF routing. Before i I start, I want to tell you that I made a GNS3 topology for you, which is configured with IP addresses and hostname so you can get the GNS3 file from the download link posted here and start with described configuration in this article.
In the real environment, our OSPF neighborship often goes down, and we have to check some common possible causes for the breakdown. The most common problems with OSPF neighborship are:
Neighbors must be in same area
Neighbors must be using same primary subnet
Authentication must be properly implemented on both neighbors (if configured)
Timers (hello and dead interval) must be same on neighbors
MTU (Maximum Transmission Unit) must be same
Router Id must be unique on neighbors
Area flags (stub, nssa NSSA, etc.) must be same on OSPF neighbors
Fig.1 shows a scenario where OSPF is configured with Process_id 1 and Area 1 between two routers, in New York and Washington.
I already configured IP addresses, so just start the devices in GNS3 and enable OSPF routing with the following commands:
NewYork(config)#router ospf 1
NewYork(config-router)#network 18.104.22.168 0.0.0.0 area 1
NewYork(config-router)#network 22.214.171.124 0.0.0.0 area 1
Washington(config)#router ospf 1
Washington(config-router)#network 126.96.36.199 0.0.0.0 area 1
Washington(config-router)#network 188.8.131.52 0.0.0.0 area 1
After configuring the above commands, you will get following log message for OSPF neighborship formation:
“*Mar 1 00:03:44.511: %OSPF-5-ADJCHG: Process 1, Nbr 184.108.40.206 on Serial0/0 from LOADING to FULL, Loading Done”
Okay, for now your OSPF routing is configured, so it’s time to prove OSPF neighborship conditions, which will make you more confident while resolving OSPF issues in a real environment. So let’s start with the first one,
Reachability:: To check this condition, just shut down the serial interface of any router.
NewYork(config)#int serial 0/0
You will get this log message: “*Mar 1 00:37:11.335: %OSPF-5-ADJCHG: Process 1, Nbr 220.127.116.11 on Serial0/0 from FULL to DOWN, Neighbor Down: Interface down or detached”
To get your OSPF neighborship up again, bring up your interface:
Neighbor must be in same area: To check this condition, just advertise the serial interface network under OSPF configuration with any area-id other than 1; for example, just configure Router New York as:
NewYork(config)#router ospf 1
NewYork(config-router)#network 18.104.22.168 0.0.0.0 area 2
After advertising the network in area 2, you will see that your neighborship will goes down. Advertise it in area 1 again to form your neighborship.
And if you use debug ip OSPF adj , you will get the following log message, which indicates mismatch area-id:
” *Mar 1 02:02:30.151: OSPF: Rcv pkt from 22.214.171.124, Serial0/0, area 0.0.0.0
mismatch area 0.0.0.1 in the header”
Useful Tshoot commands for area mismatch:
show ip ospfOSPF interface interface-id (eg- sh ip ospf int s0/0)
show ip protocol
debug ip ospf adj
Neighbors must be using same primary subnet: definitely, if your neighbor is in a different subnet, then your OSPF neighborship will definitely not be formed because it will not be reachable at all. I don’t think I need to prove this point, since we already covered this at in the reachability section. If you want, then change the serial interface ip address of Router Washington to 126.96.36.199/30 and then check.
Authentication must be properly configured on both neighbors: You can configure three kinds of authentication with OSPF. The first one is Null (use no authentication, just like description), the second one is plain text authentication, and the third one is the most important and widely used “MD5 Authentication.” You can configure OSPF authentications by using the following commands:
For Null Authentication,
NewYork(config-if)#ip ospf authentication null
For Plain Text Authentication,
NewYork(config-if)#ip ospf authentication /* to enable plain text authentication
NewYork(config-if)#ip ospf authentication-key cisco123 /* to set password
For MD5 Authentication,
NewYork(config-if)#ip ospf authentication message-digest /* to enable md5 authentication.
NewYork(config-if)#ip ospf message-digest-key 1 md5 cisco123 /to set password
Note: For plain text authentication, key-string (cisco123 in my eg) must be the same on OSPF neighbors but, for MD5 authentication, key-id and key-string must be same (key-id is 1 and key-string is cisco123 in my description)
If OSPF authentication is not properly configured (a mismatch of key-id or key string) then you can debug OSPF adjacency (debug ip ospf adj) and you will get logs for mismatch authentication key, as shown in fig. 2.
Useful Tshoot commands to check OSPF authentication:
- * show ip OSPF interface interface-id (eg- sh ip ospf int s0/0)
- * show run interface interface-id (eg – sh run int s0/0)
- * debug ip ospf adj
To configure OSPF timers:
NewYork(config-if)#ip ospf hello-interval <1-65535> Seconds
NewYork(config-if)#ip ospf dead-interval <1-65535> Seconds
Useful Tshoot Commands to show OSPF Timers ::
* show ip OSPF interface interface-id (eg- sh ip ospf int s0/0)
* show run interface interface-id (eg – sh run int s0/0)
Washington(config-if)#ip mtu 1490
Washington(config-if)#shut /* MTU takes effect only with reload so reload interface
Note: You will get a Log message for MTU mismatch like “*Mar 1 01:02:40.955: %OSPF-5-ADJCHG: Process 1, Nbr 188.8.131.52 on Serial0/0 from EXCHANGE to DOWN, Neighbor Down: Too many retransmissions”
But it is always better to use “ip opsf mtu-ignore” for an interface which is configured with least MTU.
- Router-Id must be unique on neighbors: If the OSPF router-id is the same on neighbors, then they will not form an OSPF neighborship and you will get OSPF detected duplicate router-id log message, as follows:
Log Message for same router-id
“*Mar 1 01:15:42.855: %OSPF-4-DUP_RTRID_NBR: OSPF detected duplicate router-id 184.108.40.206 from 220.127.116.11 on interface Serial0/0 ”
Useful Tshoot commands to check the OSPF router-id:
- * show ip ospfOSPF interface interface-id (eg- sh ip ospf int s0/0)
- * show ip protocol
- Area flags (stub, NSSA, etc.) must be the same on OSPF neighbors: if an area is configured as stub or NSSA, then OSPF neighbors must be configured with the same area flag. Fig. 6 shows the output of “show ip protocol” that results when an area is configured as stub.
Note: OSPF network type should the same on neighbors for proper OSPF database exchange.
There are many commands to check OSPF status and configuration, but I personally recommend the following commonly used commands that will help you to troubleshoot most OSPF issues.
For neighbor relationships, local configuration issues, and routing problems you can use the following commands for OSPF troubleshooting.
* show ip ospf neighbors—Displays adjacent neighbors, router ID of neighbors, neighbor state/DR-BDR state, IP addresses/interfaces, and dead time of neighbors.
* show ip ospf interfaces—Displays OSPF interfaces. You can also use “show ip ospf int
interface-id” for eg. sh ip ospf s0/0, as shown in Fig. 3.
* show ip protocols—You can check OSPF process-id, status, and networks that are being advertised and, most important, you can check the router-id with this command. It also provide information for area types configured (normal, stub, NSSA, etc.)
For missing routes and filtering problems, you can use following commands to resolve OSPF issues:
* show ip ospf database—Displays LSA types per area, advertising router, Link ID (subnet), and age.
* show ip route ospf—Displays OSPF routes that are being received from neighbors and their administrative distances, with cost.
The following debug commands can also useful in troubleshooting OSPF issues:
* debug ip ospf adjacency is used to debug neighbor adjacencies
* debug ip ospf events is used to debug OSPF network events
I always enjoy technology with my work and, day to day. I try to make it easier so everyone can understand it. I personally believe that, without understanding, one cannot be comfortable with technologies.
If you really like this article, then please say thanks to intenseschool.com for providing you with such technologies from the best of technical professionals from all over the world.
Guide to Cisco Certified Network Associate Certification by Todd Lammle
Routing TCP/IP Vol. 1 by Jeff Doyle
CCNP—Route Quick Reference by Denis Donohou, Ciscopress.com
Cisco Certified Internetwork Expert by Wendell Odom and others, Ciscopress.com
Cisco Certified Internetwork Expert Quick Reference by Brad Ellis, Ciscopress.com