Tags
copy, debug, Fryguy, fryguy_pa, ios upgrade, labs, tftp, troubleshoot, USB, usb0:
The other day I mentioned about using a router as a TFTP server to upgrade other devices. Since I did mention that, it makes sense to post on how to use a router for this functionality.
Have you ever need to upgrade the IOS on a remote device? Happened to have more then one of those at a remote site? Have multiple devices at a site to upgrade? I am sure we have all been there at one time or another with one or all of these scenarios. Most of us tend to pre-load the code on the devices in preparation for the upgrade, but what happens when you have insufficient space on the device you need to upgrade? Typically that means performing the IOS transfer when you are doing the upgrade and not before – that is usually during sleeping hours and not business hours.
What happens if you could A) send a USB drive to the site and have someone plug it in or B) Copy the files necessary to another device and use that to copy the files from? Both of these sound much better then having to upload code in the middle of the night. Well, but configuring your router to act as a TFTP server, you might allow yourself some sleep time instead of watching the !!!!! – and the occasional 000 – go across the screen.
For this blog, lets use this topology:
R1 will be configured as the TFTP server and host files for SW1 and R2 and the network we will be using is 100.100.100.0/24. For the blog, I will only demonstrate on R2, but since the Switch is IOS, the commands are the same.
Router/Switch Output
Commands
Notes
On R1, lets configure the G0/0 interface on this router (its a 3800 series)
FryGuyR1(config)#int g0/0
FryGuyR1(config-if)#ip add 100.100.100.1 255.255.255.0
FryGuyR1(config-if)#no shut
FryGuyR1(config-if)#^Z
FryGuyR1#sh int g0/0 | inc up
GigabitEthernet0/0 is up, line protocol is up
Full-duplex, 100Mb/s, media type is RJ45
FryGuyR1#
Ok, onto Sw1 (VLAN 100 for this example)
FryGuyBlog-SW1(config)#vlan 100
FryGuyBlog-SW1(config-vlan)#name BlogVlan
FryGuyBlog-SW1(config-vlan)#exit
FryGuyBlog-SW1(config)#spanning-tree vl 100 roo pri
FryGuyBlog- SW1(config)#int vlan 100
FryGuyBlog-SW1(config-if)#ip add 100.100.100.10 255.255.255.0
FryGuyBlog-SW1(config-if)#no shut
FryGuyBlog-SW1(config-if)#int f0/1
FryGuyBlog-SW1(config-if)#sw mo ac
FryGuyBlog-SW1(config-if)#sw ac vl 100
FryGuyBlog-SW1(config-if)#int f0/2
FryGuyBlog-SW1(config-if)#sw mo ac
FryGuyBlog-SW1(config-if)#sw ac vl 100
FryGuyBlog-SW1(config-if)#^Z
FryGuyBlog-SW1#
Now onto R2
FryGuyBlogR2(config)#int g0/0
FryGuyBlogR2(config-if)#ip add 100.100.100.2 255.255.255.0
FryGuyBlogR2(config-if)#no shut
FryGuyBlogR2(config-if)#^Z
FryGuyBlogR2#
Now, lets use R1 to ping SW1 and R2 to test connectivity
FryGuyR1#ping 100.100.100.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 100.100.100.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
FryGuyR1#ping 100.100.100.10
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 100.100.100.10, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms
FryGuyR1#
Good there!
Now lets copy some IOS to R1 from a remote computer at 100.100.100.25
FryGuyR1#copy tftp flash:
Address or name of remote host []? 100.100.100.25
Source filename []? c3550-ipservicesk9-mz.122-25.SEE.bin
Destination filename [c3550-ipservicesk9-mz.122-25.SEE.bin]?
Accessing tftp://100.100.100.10/c3550-ipservicesk9-mz.122-25.SEE.bin…
Loading c3550-ipservicesk9-mz.122-25.SEE.bin from 100.100.100.10 (via GigabitEthernet0/0):
!!!!!!!!!!!!!!!!!!!!!!!!!!!!
[OK – 7131928 bytes]
7131928 bytes copied in 31.452 secs (226756 bytes/sec)
FryGuyR1#
Note: on some platforms the system check to see if the image being copied is a valid executable for that system. If it is not, it will present a warning asking if you want to abort. Just enter N and the image will copy.
FryGuyR3#copy tftp flash:
Address or name of remote host []? 100.100.100.1
Source filename []? c3845-advipservicesk9-mz.124-17b.bin
Destination filename [c3845-advipservicesk9-mz.124-17b.bin]?
Accessing tftp://100.100.100.1/c3845-advipservicesk9-mz.124-17b.bin…
%Warning: File not a valid executable for this system
Abort Copy? [confirm]N
Loading c3550-ipservicesk9-mz.122-25.SEE.bin from 100.100.100.10 (via FastEthernet0/0):
!!!!!!!!!!!!!!!!!!!!!!!!!!!!
[OK – 7131928 bytes]
So now that we have that file on R1, lets look at the flash and see what files are there:
FryGuyR1#dir
Directory of flash:/
1 -rw- 38906040 Apr 3 2008 19:07:08 +00:00 c3845-advipservicesk9-mz.124-17b.bin
2 -rw- 7131928 Jan 25 2011 04:11:56 +00:00 c3550-ipservicesk9-mz.122-25.SEE.bin
64012288 bytes total (7311360 bytes free)
FryGuyR1#
Ok, we have two IOS images in FLASH. One for this router and another for a 3550 switch.
Next, lets configure R1 as a TFTP server to server these files out.
FryGuyR1(config)#tftp-server flash:c3550-ipservicesk9-mz.122-25.SEE.bin
FryGuyR1(config)#tftp-server flash:c3845-advipservicesk9-mz.124-17b.bin
FryGuyR1(config)# ^Z
FryGuyR1#
Note: If we had a USB drive, the you would use USBx (where X=usb slot) instead of flash
Now, lets test this out. First, lets enable some TFTP debugs to make sure this is working
FryGuyR1#debug tftp events
TFTP Event debugging is on
FryGuyR1#
Now, lets initiate the transfer from R2
FryGuyBlogR2#copy tftp flash
Address or name of remote host []? 100.100.100.1
Source filename []? c3845-advipservicesk9-mz.124-17b.bin
Destination filename [c3845-advipservicesk9-mz.124-17b.bin]?
Accessing tftp://100.100.100.1/c3845-advipservicesk9-mz.124-17b.bin…
Loading c3845-advipservicesk9-mz.124-17b.bin from 100.100.100.1 (via GigabitEthernet0/0):
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
[OK – 38906040 bytes]
FryGuyBlogR2#dir
Directory of flash:/
1 -rw- 38906040 Jan 25 2011 04:09:32 +00:00 c3845-advipservicesk9-mz.124-17b.bin
Great, file copied. Now lets look at the debug output on R1 to see what is said.
FryGuyR1#debug tftp events
TFTP Event debugging is on
FryGuyR1#
*Jan 25 04:21:35.759: TFTP: Looking for c3845-advipservicesk9-mz.124-17b.bin
*Jan 25 04:21:35.927: TFTP: Opened flash:c3845-advipservicesk9-mz.124-17b.bin, fd 0, size 38906040 for process 97
*Jan 25 04:21:35.935: TFTP: Finished flash:c3845-advipservicesk9-mz.124-17b.bin, time 00:00:00 for process 97
*Jan 25 04:21:35.939: TFTP: Looking for c3845-advipservicesk9-mz.124-17b.bin
*Jan 25 04:21:36.107: TFTP: Opened flash:c3845-advipservicesk9-mz.124-17b.bin, fd 0, size 38906040 for process 97
*Jan 25 04:21:36.107: TFTP: Looking for c3845-advipservicesk9-mz.124-17b.bin
*Jan 25 04:21:36.275: TFTP: Opened flash:c3845-advipservicesk9-mz.124-17b.bin, fd 1, size 38906040 for process 239
*Jan 25 04:21:36.283: TFTP: Finished flash:c3845-advipservicesk9-mz.124-17b.bin, time 00:00:00 for process 239
*Jan 25 04:21:36.283: TFTP: Looking for c3845-advipservicesk9-mz.124-17b.bin
*Jan 25 04:21:36.451: TFTP: Opened flash:c3845-advipservicesk9-mz.124-17b.bin, fd 1, size 38906040 for process 239
*Jan 25 04:21:36.479: TFTP: Finished flash:c3845-advipservicesk9-mz.124-17b.bin, time 00:00:00 for process 239
*Jan 25 04:21:37.475: TFTP: Finished flash:c3845-advipservicesk9-mz.124-17b.bin, time 00:00:01 for process 97
*Jan 25 04:21:38.475: TFTP: Looking for c3845-advipservicesk9-mz.124-17b.bin
*Jan 25 04:21:38.643: TFTP: Opened flash:c3845-advipservicesk9-mz.124-17b.bin, fd 0, size 38906040 for process 97
*Jan 25 04:21:38.651: TFTP: Finished flash:c3845-advipservicesk9-mz.124-17b.bin, time 00:00:00 for process 97
*Jan 25 04:21:38.819: TFTP: Looking for c3845-advipservicesk9-mz.124-17b.bin
*Jan 25 04:21:38.987: TFTP: Opened flash:c3845-advipservicesk9-mz.124-17b.bin, fd 0, size 38906040 for process 97!
FryGuyR1#
As you can see, R1 showed the TFTP connections coming from R2 requesting the file. This is a way to make sure you TFTP server is working, but then again if the copy was not you would probably know that.
Yet what is good about he debug, if you are working with someone else and they are having problems, you will see what file name they are looking for in the debug output:
*Jan 25 04:28:49.387: TFTP: Looking for asdfasdf
Now, if you are wondering why there are so many of the same entries in the log, to be honest I do not know. What I suspect is that the receiving device is downloading the headers to see if is a valid IOS image. I did a debug tftp packet and you can see part of the output here that shows part of the file was downloaded and stopped. I DO NOT recommend running this debug on a production router!
FryGuyR1#debug tftp packets
TFTP Packet debugging is on
FryGuyR1#
*Jan 25 04:36:36.639: TFTP: Server request for port 57088, socket_id 0x659592E4 for process 97
*Jan 25 04:36:36.639: TFTP: read request from host 100.100.100.2(57088) via GigabitEthernet0/0
*Jan 25 04:36:36.639: TFTP: Looking for c3845-advipservicesk9-mz.124-17b.bin
*Jan 25 04:36:36.807: TFTP: Opened flash:c3845-advipservicesk9-mz.124-17b.bin, fd 0, size 38906040 for process 97
*Jan 25 04:36:36.807: TFTP: Sending block 1 (retry 0), socket_id 0x659592E4
*Jan 25 04:36:36.807: TFTP: Received ACK for block 1, socket_id 0x659592E4
*Jan 25 04:36:36.807: TFTP: Sending block 2 (retry 0), socket_id 0x659592E4
*Jan 25 04:36:36.807: TFTP: Received ACK for block 2, socket_id 0x659592E4
*Jan 25 04:36:36.807: TFTP: Sending block 3 (retry 0), socket_id 0x659592E4
*Jan 25 04:36:36.811: TFTP: Received ACK for block 3, socket_id 0x659592E4
*Jan 25 04:36:36.811: TFTP: Sending block 4 (retry 0), socket_id 0x659592E4
*Jan 25 04:36:36.811: TFTP: Received ACK for block 4, socket_id 0x659592E4
*Jan 25 04:36:36.811: TFTP: Sending block 5 (retry 0), socket_id 0x659592E4
*Jan 25 04:36:36.811: TFTP: Received ACK for block 5, socket_id 0x659592E4
*Jan 25 04:36:36.811: TFTP: Sending block 6 (retry 0), socket_id 0x659592E4
*Jan 25 04:36:36.811: TFTP: Received ACK for block 6, socket_id 0x659592E4
*Jan 25 04:36:36.811: TFTP: Sending block 7 (retry 0), socket_id 0x659592E4
*Jan 25 04:36:36.811: TFTP: Received ACK for block 7, socket_id 0x659592E4
*Jan 25 04:36:36.811: TFTP: Sending block 8 (retry 0), socket_id 0x659592E4
*Jan 25 04:36:36.811: TFTP: Received ACK for block 8, socket_id 0x659592E4
*Jan 25 04:36:36.811: TFTP: Sending block 9 (retry 0), socket_id 0x659592E4
*Jan 25 04:36:36.811: TFTP: error code 0 received – 21349
*Jan 25 04:36:36.811: TFTP: Finished flash:c3845-advipservicesk9-mz.124-17b.bin, time 00:00:00 for process 97
*Jan 25 04:36:36.815: TFTP: Server request for port 52041, socket_id 0x659592E4 for process 97
*Jan 25 04:36:36.815: TFTP: read request from host 100.100.100.2(52041) via GigabitEthernet0/0
*Jan 25 04:36:36.815: TFTP: Looking for c3845-advipservicesk9-mz.124-17b.bin
*Jan 25 04:36:36.983: TFTP: Opened flash:c3845-advipservicesk9-mz.124-17b.bin, fd 0, size 38906040 for process 97
*Jan 25 04:36:36.983: TFTP: Sending block 1 (retry 0), socket_id 0x659592E4
*Jan 25 04:36:36.991: TFTP: Received ACK for block 1, socket_id 0x659592E4
*Jan 25 04:36:36.991: TFTP: Sending block 2 (retry 0), socket_id 0x659592E4
*Jan 25 04:36:36.991: TFTP: Received ACK for block 2, socket_id 0x659592E4
*Jan 25 04:36:36.991: TFTP: Sending block 3 (retry 0), socket_id 0x659592E4
*Jan 25 04:36:36.991: TFTP: Server request for port 53752, socket_id 0x66358420 for process 239
*Jan 25 04:36:36.991: TFTP: read request from host 100.100.100.2(53752) via GigabitEthernet0/0
*Jan 25 04:36:36.991: TFTP: Looking for c3845-advipservicesk9-mz.124-17b.bin
*Jan 25 04:36:37.159: TFTP: Opened flash:c3845-advipservicesk9-mz.124-17b.bin, ACK for block 6, socket_id 0x66358420
*Jan 25 04:36:37.163: TFTP: Sending block 7 (retry 0), socket_id 0x66358420
*Jan 25 04:36:37.163: TFTP: Received ACK for block 7, socket_id 0x66358420 fd 1, size 38906040 for process 239
*Jan 25 04:36:37.159: TFTP: Sending blo
*Jan 25 04:36:37.163: TFTP: Sending block 8 (retry 0), socket_id 0x66358420
*Jan 25 04:36:37.163: TFTP: Received ACK for block 8, socket_id 0x66358420
*Jan 25 04:36:37.163: TFTP: Sending block 9 (retry 0), socket_id 0x66358420
*Jan 25 04:36:37.163: TFTP: error code 0 received – 21349