GNS3 Lab: Troubleshoot and Resolve Routing Issues OSPF

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).

GNS3TroubleshootingOSPF.zip

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:
1. Reachability
2. Neighbors must be in same area
3. Neighbors must be using same primary subnet
4. Authentication must be properly implemented on both neighbors (if
configured)
5. Timers (hello and dead interval) must be same on neighbors
6. MTU (Maximum Transmission Unit) must be same
7. Router Id must be unique on neighbors
8. Area flags (stub, nssa NSSA, etc.) must be same on OSPF neighbors

<img
src="http://1rtdn21e2k8w27koup1eiasxspe.wpengine.netdna-cdn.com/wpcontent/uploads/050614_1830_GNS3LabTrou1.png" alt="" />
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 12.1.1.1 0.0.0.0 area 1
NewYork(config-router)#network 1.1.1.1 0.0.0.0 area 1
Washington(config)#router ospf 1
Washington(config-router)#network 12.1.1.2 0.0.0.0 area 1
Washington(config-router)#network 2.2.2.2 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 1.1.1.1 on
Serial0/0 from LOADING to FULL, Loading Done
Okay, for now your OSPF routing is configured, so its time to prove OSPF
neighborship conditions, which will make you more confident while
resolving OSPF issues in a real environment. So lets start with the first
one,
1. Reachability:: To check this condition, just shut down the
serial interface of any router.
NewYork(config)#int serial 0/0
NewYork(config-if)#shutdown
You will get this log message: *Mar 1 00:37:11.335: %OSPF-5-ADJCHG:
Process 1, Nbr 2.2.2.2 on Serial0/0 from FULL to DOWN, Neighbor Down:
Interface down or detached
To get your OSPF neighborship up again, bring up your interface:
NewYork(config)#int s0/0
NewYork(config-if)#no shutdown

1. 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 12.1.1.1 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 12.1.1.2, 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

2. 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 dont 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 13.1.1.2/30 and then check.
3. 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)#interface s0/0
NewYork(config-if)#ip ospf authentication null

For Plain Text Authentication,

NewYork(config)#interface s0/0
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)#interface s0/0
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.

<img src="http://1rtdn21e2k8w27koup1eiasxspe.wpengine.netdnacdn.com/wp-content/uploads/050614_1830_GNS3LabTrou2.jpg" alt="" />

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

2. OSPF hello and dead intervals must be the same: Timers

plays an important role for OSPF neighborship formation. Both
hello and dead intervals must match on OSPF neighbors. By
default, the hello interval is 10 sec and the dead interval is 40
sec for fast links; for slow links, the hello interval is 30 sec and
the dead interval is 120 sec. Fig. 3 displays the output of the

show ip ospf int s0/0 command, where you can check

multiple useful configurations.

<im
g
src="http://1rtdn21e2k8w27koup1eiasxspe.wpengine.netdnacdn.com/wpcontent/uploads/050614_1830_GNS3LabTrou3.jpg" alt="" />
To configure OSPF timers:
NewYork(config)#int s0/0
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)

2. MTU (Maximum Transmission Unit): If the MTU is not the

same between OSPF neighbors, then your neighborship can be
stuck in exstart state. Fig. 4 shows the result of checking the
MTU. And you can change the MTU by using the following
commands:

<img src="http://1rtdn21e2k8w27koup1eiasxspe.wpengine.netdnacdn.com/wp-content/uploads/050614_1830_GNS3LabTrou4.jpg" alt="" />

Washington(config)#int s0/0
Washington(config-if)#ip mtu 1490
Washington(config-if)#shut /* MTU takes effect only with reload so reload
interface
Washington(config-if)#no shut

<i
mg src="http://1rtdn21e2k8w27koup1eiasxspe.wpengine.netdnacdn.com/wp-content/uploads/050614_1830_GNS3LabTrou5.jpg" alt="" />
Note: You will get a Log message for MTU mismatch like *Mar 1
01:02:40.955: %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 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.
1. 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 1.1.1.1 from 12.1.1.1 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

<img src="http://1rtdn21e2k8w27koup1eiasxspe.wpengine.netdnacdn.com/wp-content/uploads/050614_1830_GNS3LabTrou6.jpg" alt="" />

1. 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.
1. * show ip ospf neighborsDisplays adjacent neighbors,
router ID of neighbors, neighbor state/DR-BDR state, IP
addresses/interfaces, and dead time of neighbors.
2. * show ip ospf interfacesDisplays OSPF interfaces. You
can also use show ip ospf int
interface-id for eg. sh ip ospf s0/0, as shown in Fig. 3.

3. * show ip protocolsYou 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:
1. * show ip ospf databaseDisplays LSA types per area,
advertising router, Link ID (subnet), and age.
2. * show ip route ospfDisplays 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:
1. * debug ip ospf adjacency is used to debug neighbor
adjacencies
2. * 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.
References :
o Guide to Cisco Certified Network Associate Certification by
Todd Lammle
o Routing TCP/IP Vol. 1 by Jeff Doyle
o CCNPRoute Quick Reference by Denis Donohou,
Ciscopress.com
o Cisco Certified Internetwork Expert by Wendell Odom and
others, Ciscopress.com
o Cisco Certified Internetwork Expert Quick Reference by Brad
Ellis, Ciscopress.com

o http://www.cisco.com/c/en/us/support/docs/ip/open-shortestpath-first-ospf/12151-trouble-main.html