Like This Blog 1

Added by Mark Jacob March 17, 2014

This blog post is more of a challenge situation than a real life example.  Let’s say you were presented with a lab situation or even an exam scenario where you had to deal with the following stated objective: You will have administrative access to a Cisco router which is connected to one other Cisco router. The other router is correctly configured with the OSPF routing protocol.  Authentication is not configured.  You are not permitted to employ a network packet sniffer. All discovery must occur on the router to which you have administrative console access.  Your task it to determine the area ID of the interface of the other router to which you are connected.  Your router is not running a routing protocol.  Any other needed information must be discovered by you.

Do you have an idea how you would handle this challenge?  Give your brain a few moments to cogitate, and then continue reading to see if you came up with the same solution I did.  (If you have an alternate solution that works, I would love to hear about it.)

First of all, to set the stage, here is a small piece of a larger network.  The ‘other’ router is the one that is already configured – our challenge is to access RIGHT router and discover all we need to know.  Remember that the situation presented is one where you are seated at a console and you are connected to RIGHT router.  Everything else must be discovered.

When I log in to RIGHT, I notice immediately that there are duplex messages appearing on the console:

This might seem like a bad thing, but it tells me that CDP is running (nobody has disabled it) which is good for me! I already know the ‘other’ router’s name – it is LEFT (I can see that is the CDP output).  Let’s see what I can find out about my neighbor.

Now I know the two of us are connected via our FastEthernet 0/0 interfaces and my neighbor’s IP address is 200.10.1.253.

Since I have been told that the goal is to discover the area ID in use on my neighbor’s F0/0 interface, I can safely assume that OSPF must be running. Since process-id is locally significant, I can start up OSPF on my router with any number I want. Let’s see what happens when I do that.

Aha!  Since I haven’t configured any IPv4 addresses on my router, it has no way to grab an address to use as the OSPF router ID.  Let’s fix that. I can make another presumption based on the output of the show cdp entry command shown above, and that is that I can safely confgure my side with the IP address 200.10.1.254. I cannot be certain yet that my neighbor is using a 30 bit subnet mask, but the .254 address is the best choice in the absence of any other information.  Let’s do that.

To be safe, I configured my side with a 24 bit mask. This means I will be close enough for now regardless of what mask my neighbor has chosen. I test this with a ping command and it is successful as shown above. I am still getting the duplex errors, so let’s correct that also.

For good measure, I hard-coded the speed as well. Now the duplex errors have disappeared.

Here is where we get creative. Since I do not know that area ID in use, I will just pick one. It is unlikely that I will accidentally select the correct number, but if I did, I would know quickly because I would see some OSPF messages populating the console. Let’s try it with area 0.

I will show two different ways to determine the area ID in use in this blog. They are both dependent on debug output. The first is to debug OSPF adjacencies. Watch what happens when we do that.

There it is! We know that the far side is using area ID 0.0.1.17. Let’s plug that in to our side and see if it works.

We have achieved some success, but not full success. We see that OSPF reacted to the corrected area ID and tried to form a full adjacency, but failed. My first thought is that I was too lenient on my subnet mask on my F0/0. Remember that I placed a mask as though it was the full class C network in use. If I am right, I should see evidence of that in debug ip ospf hello.

Sure enough, I see that there is a mismatch on the subnet mask values. I search all over the Cisco website, but I did not find anywhere that explained the ‘R’ and the ‘C’ so I will use Remote for the ‘R’ and Connected for the ‘C.’  (Maybe someone from Cisco will read this and correct me if I guessed incorrectly.) So let’s correct our mask.

Yippee!  We have neighbor!  Just to be sure…

So if this question was on your exam, you would have the answer now, right? Let’s say the choices looked like this for the question “Which area ID is in use on int F0/0 on LEFT router?”

Which would you choose? Wait a minute, I did not use any of those choices when I configured my side to match up with LEFT. Let’s go back and look at what was used. I used area 0.0.1.17. What is going on here? It may look a little unusual to some readers, but the dotted decimal format is valid for configuring an area in OSPF. So what is that number in decimal? Let’s look at it like this:

The first two octets are 0, so let’s skip to the 3^rd and 4^th octets.  The third octet is 1, which in binary, looks like the above figure on the left side.  The right side of the figure shows the binary representation of the number 17.  Notice that the 1 on the left side is in the ‘256’ column.  So we just need to add the left and right side together, which is 256 + 17, for a total of 273.  This is our missing area ID in decimal format.  To test this, let’s reconfigure our RIGHT router with tha area ID defined in decimal format and see if the neighbor adjacency returns.

As you can see, I removed the network command with area ID 0.0.1.17 and replaced it with area ID 273 and Voila! my adjacency was restored.

If we recall the choices given to us in the imaginary exam scenario, we now can choose confidently!

I did promise you two ways to discover the area ID.  So far we have seen one of them.  Let’s take a look at the other one.  The situation has been restored so that we can access RIGHT’s console as an admin user.  The first steps are the same, up to the point where I configure OSPF and define the F0/0 network with an arbitrarily selected area ID (recall I used 0):

Here is where the methods diverge. I will create an extended access-list which focuses on the main multicast address used by OPSF, which is 224.0.0.5. Then I will debug with an eye on that access-list. Here is the creation of the access-list.

We are interested in the received (rcvd) hello. Find the field filled with E0000005, and then count 3 more. The orange rectangle identifies what we seek: 00000111. Since this is a hexadecimal field, we need to convert it to decimal, which turns out to be – you guessed it – 273. Once again we have identified the area ID in use. To test this, recall that since I did not know the area ID in use, I configured my side with area 0. If I look at the sending hello information above and follow the same format, 3 after the E0000005 is 00000000, which is 0. So it works both ways.

Now I know that this is not really secret information like the title of this blog indicated, but at least it made the blog interesting enough to read. I hope you found some tidbits in here that you didn’t already know, and if you know another was to resolve this scenario, please feel free to leave comments!

In part 2, we’ll explore the ease with which a simple password can be pulled off the wire, without so much as a packet sniffer in sight.

Until next time, when I will show more secret information!  🙂

Mark Jacob
Cisco Instructor – Interface Technical Training
Phoenix, AZ