The Silo Chronicles
The not so exciting adventures of a Network Engineer

As a Cisco Partner I have had several occasions to password recover some devices. Today brought an usual request of wanting to harvest the configuration not the password. A customer had a Cisco router provided by a 3rd party that they wanted to replace and return but unfortunately the vendor would/did not give them the information they needed to bypass the router and have the services handled directly by their equipment.

For some reason I always get a chuckle when doing these. The task is simple enough to complete. When you password recover the device it also provides you the current configuration, including passwords, except you are in enable mode and you can make any changes you deem necessary. To password recovery an IOS device do the following:

1. Connect a console cable to the device and power the device on.
2. Press CTRL-BRK to enter rommon.
3. Type “confreg 0×2142″ and press enter.
4. Type “reset” and press enter.
5. Upon booting the device will ask you to enter a configuration setup wizard. Answer NO to this question. The device is now booted with no configuration.
6. Type “enable” and press enter.
7. Type “configure memory”

At this point you should see the hostname change and if you issue a “show running-config” you will see the complete configuration, including passwords. In the case of today the vendor did not run password encryption so all their passwords were in plain text. Ruh Roh!

I ran into a very annoying software glitch today with my 3G iPhone. I charge my phone every night so when I started out at 06:00 it was fully charged. I got to my first client of the day at around 9:00 and noticed that my phone was already at half power. The best part was I actually hadn’t even used it yet. After another 2 hours my phone was completed dead and powered off. I popped up my laptop and started re-charging it and it turned back on. My laptop ended up going to sleep and when I turned around it was dead again. I repeated the process this time when it powered on I properly powered off the phone and then powered it back on. Same thing it drained in a matter of minutes. I finally made it back to my wall charger and was shocked to find that after I plugged it in the thing still managed to drain itself and power off. Yes, it powered itself off while still plugged in. I had to unplug and plug it back in to get it to start charging again.

Another engineer at my company had a similar problem a few weeks back and I talked to him about it and he set to reset the iPhone and delete all settings and content. I did this, which took about an hour, and when it came back up it wanted to be synced with iTunes, after all that it seems to have charged and is ok now.

Long story short is there definitely seems to be a software glitch since erasing my iPhone seems to have fixed the issue. One item of note is that when I first plugged it in my iTunes prompted me to restore from backup but I chose to just start over.

Today’s post is a blast from the past. While studying for the CCNP I came across the CEF section which reminded me of my first introduction to CEF. It started with a report that users that some servers were down. The helpdesk was very confused because when they tried to talk to the servers it worked. The first technician tried to take control of the user’s workstation but couldn’t yet another technician could.

When I heard of the issue I knew what the root problem was. The location in which the user was at had dual equal cost paths and one of the paths was down. What made me pause for a second was the network engineer asking me a very simple question “how can I tell which path will be selected?”. It was a perfect case of knowing how a technology worked but not how to prove what I was seeing.

The first place to start is checking to make sure you actually have redudant paths recognized by CEF and the routing table. To start with you can check the CEF table and issue the following command:

As you can see there are two entries for the 192.168.1.0 network. You can verify that both routes are in the routing table by taking the network and doing the following:

This output shows you the two routes and the details about the routes. The one with the * next to it will be the default selected path. Now that you know there are in fact dual paths you can get more details about the CEF effects. The first command to enter will be:

The important part to get from this output is “per-destination” this tells you which type of load balancing is in use. This tells you that the path is selectd on a per-destination basis instead of changing it up on a per-packet basis. This is very important. If you are passing order sensative data such as voice packing arriving out of order is very bad. As such you want to make sure per-destination is selected. The way load balancing is done is there are 16 bit buckets created inside the router and those bit buckets are evenly split up between the avaialble paths. To see how the buckets are distributed enter the following command:

Now that you have verified that dual paths exist and you understand what method the router is using to select paths the question that arises is how can I see which path will be used under certain conditions. This can be done via the following command:

The first argument is the source IP and the second is the destination IP. This lets you ask the router if it were to process a packet with that source and that destination which path it would select. As you can see with this example with the destination changing the link selected has changed.

Under the conditions I created in my lab and the output shown this scenario would not exist. That is beause the routes are populated via EIGRP and as such when one of the paths is broken the routes will be automatically removed and the path depricated.

Today marked the start of my CCNP studying. The first topic I found on the Blue Print was EIGRP. While I have used EIGRP for years now I have to admit did not fully understand how the protocol worked and how to get the most out of it. Like I did with my CCVP I will be making posts of useful information.

Neighbor Table

Each router is responsible for keeping state information about their adjacent neighbors. When a neighbor is discovered the address and interface of the neighbor is recorded. Each of the protocol dependent modules has their own neighbor table. During the Hello phase a HoldTime is advertised. This time is the amount of time a router waits between Hellos before marking the neighbor as unreachable and non-operational. If this occurs DUAL is informed of the topology change. Along with this information sequence numbers are stored to help detect out of order packets. A transmission list is used to queue packets for retransmission on a per neighbor basis.

Topology Table

The Topology Table is managed by the protocol dependent modules and accessed by the DUAL finite state machine. It contains the destinations advertised by neighboring routers. Each entry is contains the destination address and a list of neighbors that advertise the destination. For each neighbor the advertised metric is recorded. This is the metric that the neighbor stores in its routing table.

The router then takes the sum of the best advertised metric from all neighbors plus the link cost to the best neighbor. This is the metric that the router uses in its own routing table.

Feasible Successors

Feasible Successors are routes that can be installed into the routing table if a route goes away. As long as the neighbor is considered downstream it will consider it a feasible successor. This allows a new route to be selected without having to re-compute the routing table.

Viewing Route Details

To view the detailed information regarding the routes in the router you will want to issue the following command. If you have two routes installed in the route table to the same destination it will tell you which route will be used.

The route with the * next to it will be selected for the traffic at that destination. By default the route selection is determined by Delay and Bandwidth. If they metric isn’t the same for two routes you will only see a single route installed. You can influence these selections by various means which I will cover in a later post.

After battling with getting Phone Proxy working on an ASA for a bit of time I finally tracked down the problem. It all started when I tried to turn on phone-proxy on an ASA5505 running 8.0(4). I started getting very strange debug outputs with very strange TFTP messages. What I noticed is that after random intervals of time the ASA stopped passing traffic. What was happening was the ASA was running out of 80 byte blocks. After working with TAC we discovered the issue was relating to the ASA running EIGRP. As soon as I removed EIGRP from the ASA it stopped dying and phone-proxy magically started working.

If you need EIGRP on your ASA open a TAC case and they will send you an interim release with a fixed. I believe anything past 8.0(4)12 will do it. For more details check Bug ID CSCsv89678 (CCO Required).