Flashing a new IOS onto a Cisco switch or router

Flashing a new IOS onto a Cisco switch or router

This tutorial will guide you through flashing a new IOS onto a Cisco switch or router.

Cisco devices use IOS images which are typically in .bin (binary) format. The device will download the image of your choice from a TFTP server and write it to its internal flash memory. Once you have obtained your new IOS image, you will need to set up a TFTP server on a networked PC. A good free TFTP server for Windows can be obtained from http://tftpd32.jounin.net/.

Once you have installed and are running the TFTP server, you will need to go into the Settings (using the obvious button) and change the Base Directory to the directory in which your IOS image resides. Once you have done this and restarted the TFTP server application, you are ready to use it.

Now ensure that at least one Ethernet port of your Cisco device is connected to the same network as the PC running TFTP and log into the console of your router.

Now you must, if you have not done so already, assign an appropriate IP address to the network interface on the Cisco device. For my examples, I am using a Cisco 2610 router which labels its only Ethernet port as Ethernet0/0.

To assign an IP address, you would do the following. The bold bits are the bits that you type:

router-2610-1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
router-2610-1(config)#int Ethernet0/0
router-2610-1(config-if)#no shutdown
00:04:03: %LINK-3-UPDOWN: Interface Ethernet0/0, changed state to up
00:04:04: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0/0, changed state
router-2610-1(config-if)#ip address

This assigns the IP address to Ethernet0/0 with a subnet mask of

The device should now be pingable from your TFTP host machine:

Pinging with 32 bytes of data:
Reply from bytes=32 time=7ms TTL=255
Reply from bytes=32 time=5ms TTL=255
Reply from bytes=32 time=4ms TTL=255
Reply from bytes=32 time=5ms TTL=255
Ping statistics for
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 4ms, Maximum = 7ms, Average = 5ms

Now you can copy the IOS image to your flash from the TFTP server. In my example below, I am copying the image c2600-i-mz.123-19a.bin from the TFTP server at to flash.  The bold bits are the bits that you type, <Hit Enter> is an instruction:

router-2610-1#copy tftp: flash:
Address or name of remote host []?
Source filename []? c2600-i-mz.123-19a.bin
Destination filename [c2600-i-mz.123-19a.bin]? c2600-i-mz.123-19a.bin
Accessing tftp://…
Erase flash: before copying? [confirm] <Hit Enter>
Erasing the flash filesystem will remove all files! Continue? [confirm] <Hit Enter>
Erasing device… eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee …erased
Erase of flash: complete
Loading c2600-i-mz.123-19a.bin from (via Ethernet0/0): !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! etc. etc.
[OK – 7738476 bytes]

Verifying checksum… OK (0x213C)
7738476 bytes copied in 68.568 secs (112858 bytes/sec)

Now you can reload your router:


System configuration has been modified. Save? [yes/no]: no
Proceed with reload? [confirm] <Hit Enter>

Your router should now reboot and will hopefully show your new IOS as running when you type show ver on the console.

How to securely copy data over SSH

This is a really useful tip, and it has infinite uses in a *nix environment. You can pipe data over SSH, from both a client and a server, and process it on the other side. This is pretty useful as it avoids the requirement to have the hard disk space to store a file before it is imported. Here’s a few examples:

Copying a remote database to a local database

  1. ssh user@server-domain.com 'mysqldump -u root --password=passwordhere remote-database-name-here | gzip -c' | gunzip | mysql -u root --password=passwordhere local-database-name-here
You’ll see  that we can pass a command as the 3rd parameter of ssh. This is executed on the remote end. Here, we take the output of mysqldump, gzip it and send it over SSH. We pipe the ssh command into gunzip to decompress it and finally pipe that into the local mysql command to import it.


Copying a folder of files to a remote server

  1. cd /path/to/dir/to/copy;
  2. tar -cz . | ssh user@server-domain.com 'tar -C /path/to/remote/dir -xzv'
In this example, we cd into a directory on the local machine, create a tar of its contents and pipe this over ssh into a reverse tar command on the remote server. The z flag on the tar commands gzips/ungzips the output for you, automagically. Note that this won’t include the root directory – i.e. it’ll transport  /path/to/dir/to/copy/* to  /path/to/remote/dir.


The two examples above have shown you using ssh on the left and right of the command. There’s plenty of other uses, see what you can do with it.

Rugby Borough Council – Recycling and Refuse Collection Calendar 2012

It’s mighty dull but pretty tricky to find on the travesty that is the Council’s website. First you’ll need to go to http://www.rugby.gov.uk/site/custom_scripts/wcsc.php. Enter you postcode or street name and hit Go. It’ll tell you when your next collection is and for which bins it is. Now you’ll have to work out whether you’re covered by the ‘Week 1’ calendar or the ‘Week 2’ calendar. Download both and see, on which, does the next collection match up with what the above calculator told you. These are available below, as PDFs.

Week 1 calendar

Week 2 calendar

Exciting, eh?


Creating a Wireshark compatible .cap file with tcpdump

Tcpdump is a useful tool to capture network packets on a Linux, UNIX, BSD, etc. system. It is nice, however, to be able to see its output in a graphical UI. Wireshark can be used to view capture files created by Tcpdump, if you use the right parameters on the tcpdump command. Run tcpdump as follows:

  1. tcpdump -s 65535 -w /path/to/file.cap

Download the .cap to your computer and import it into Wireshark.

You can also pass filters into tcpdump to get a smaller cap file. The below captures only port 80 (http traffic):

  1. tcpdump -s 65535 -w /path/to/file.cap 'src port 80 || dst port 80'


Life expectancy… WE’RE ALL GONNA DIE!

So… I got bored. So did @sicoanimal. @allanjude did too. Also, it’s half way through the month and I’ve only blogged once.

Based on Google’s (stolen) life expectancy data we made a (piss poor) attempt to work out when we were going to die. I say that it was a piss poor attempt because it’s probably really inaccurate. Graphing the data suggests it had a near perfect polynomial, of power 2, trend. However, this gave a silly life expectancy (about 111 for me) and we felt that if we had more than 49 years’ of data to work with, it wouldn’t be polynomial. As such, I opted for the next closest – exponential.

A link to an Excel spreadsheet that calculates this is below. The data that is in the “CONFIG” bit is my age and UK mixed gender data taken from the above link. I should probably clarify that by “mixed gender”, I mean male and female combined – I sadly couldn’t find accurate statistics on the life expectancy of hermaphrodites.  Change the config to match your own data. Seems I’m going to die at the ripe old age of 96. Sounds good to me 🙂

Download the life expectancy calculation spreadsheet

If you’re currently thinking something along the lines of “OMfuckingG! This is so inaccurate”… you’re probably missing the point.

Here’s a graph of it, for shits ‘n’ giggles:

Life Expectancy Graph

Life Expectancy Graph