Like This Blog 1

Added by Mark Jacob March 6, 2013

Perhaps you have heard that it is a good idea for your routers to verify the sources of routing update information.  Much like when you call your bank and you ask them for your current balance, they want to know a few things before just spitting out the financial information.  If you know your last four, mother’s maiden, first pet, best man, and on and on, they will finally believe that it is really you and tell you what you want to know.  Let’s apply this same concept to OSPF routers.

Keep in mind that if you just configure OSPF, define your network, and step back, authentication won’t be running.  Our job is to make it run. 

I have a very simple network constructed with two routers, a serial link between them, and a loopback configured on each one.  It looks like this:

Before I configure authentication, I want to see if the advertised routes are showing up.  If they show up now, but disappear once authentication is turned on, then I can be pretty sure I know the source of the problem.  (ME!)

Here is the routing table for R1:

Here is the routing table for R2:

Sure enough, R1 sees the 192 network on R2’s loopback and R2 sees the 172 network on R1’s loopback.  Now to configure authentication.

On R1, I went interface Serial 0/0 and typed the following commands:

                ip ospf authentication

                ip ospf authentication-key password

I can tell something broke when I did that, because I see this in my console to R1:

On R2, I was running this debug command:  debug ip ospf adj and I received the following output:

Clearly, if I configure authentication on one side, it breaks things until I get authentication configured on the other side.  So let’s do it.  I will type the same authentication commands shown above on the Serial 0/0 interface of R2.

As soon as I did so, I saw a message that showed OSPF going from LOADING to FULL on both routers (similar to this):

Good news!  Now let’s look at those routing tables again to see if the expected networks are present.

Here is R1:

Here is R2:

Fantastic!  I see the expected networks on both sides – so authentication is working correctly.  As mentioned, you don’t want your routers listening to strange routers, so it is best to verify the sources of routing updates by using authentication.  What was shown above is just simple password authentication, which means the passwords must match on both sides, but they are stored in the config in clear text (which you can defeat by using the service password-encryption command).  They are also sent across the wire in clear text, which is not secure at all.  So if you want stronger authentication, OSPF also supports md5 authentication.  The steps are almost identical to the ones shown in this blog, but the end result is far safer.  Give it a shot and see if you can make your routers talk in secret code! 

Until next time, happy authenticating…

Mark Jacob
Cisco Instructor – Interface Technical Training
Phoenix, AZ