Redirect Procurve’s output to TFTP Server

July 12, 2012 By Leave a Comment

So last night I learned another Procurve command that’ll redirect the output and send it to the TFTP Server instead of the terminal client. I was hoping to use one of these days and little did I know I would get to use it as soon as I get to work today.

It just happened that I have a Procurve switch that crashed and rebooted itself multiple times. There were something odds about it so the logs need to be sent to the support staff so they can do their thing. Normally, I have my terminal clients logs all output to a file and just run Show Tech and Show Log commands then copy the files to an email. But like any other diagnostic commands, these can take a long time to run through and it’s so true when you get to enterprise line of products so I thought I’d try the command I learned last night.

Redirect Procurve’s command output directly to TFTP server:

SYNTAX:

Copy command-output “command string” tftp ipAddress dest-file-name

EXAMPLES:

Copy command-output “show tech” tftp 1.2.3.4 switchXYZ-showtech.log
Copy command-output “show log” tftp 1.2.3.4 switchXYZ-showlog.log

WHAT IT DOES:

Redirects the command output to a file then sends it to a TFTP Server.
Really handy when it comes to long running command like Show Tech or Show Log.

Note that for this to work, quotations are needed around the command for which you want to redirect the output and TFTP Server must be running (guess which TFTP Server I was running – That’s right, Pinkie!). Further more, there’s no feed back when you execute this. The only form of feedback is if you are to watch the TFTP file transfer request, you’ll see that an incoming request is initiated and the specified file appears in your TFTP folder.

Using the commands above, I was able to gather the logs in a fraction of the time that it normally takes if I was doing it the old fashion way – which is just run the Show Tech/Show Log and let the info scrolls through the screen.

Procurve’s Output redirection isn’t limited just these two aforementioned commands. You can redirect other’s command output too. Just remember to wrap the command around the quotation marks.

Filed Under: TFTP, Tips & Tricks Tagged With: ,

Procurve corrupted flash recovery

July 7, 2012 By 5 Comments

As I wrote in the blog last week, I was upgrading the code on a fairly large number of switches. And during the upgrade, I did run into a couple of issues and lost a 3500 along with a few 5406’s. I was able to fix and recover all the switches that went down in that change window.

In this blog, I’ll go into details on how I addressed the bad switches and recover them from Monitor ROM and put them back to use.

Since I don’t have a bad switch at the moment I’ll simulate this by booting into Monitor ROM by choosing option 0 when the switch first boots up. And it looks something like this:

ROM information:
Build directory: /sw/rom/build/bmrom(t2g)
Build date: Apr 24 2009
Build time: 23:33:11
Build version: K.12.20
Build number: 24648
 
 
 
Boot Profiles:

0. Monitor ROM Console
1. Primary Software Image
2. Secondary Software Image

Select profile (primary): 0

and here’s what the output looks like when the switch – in this case a 3500yl with 48 copper ports:

HP ProCurve Switch 3500yl-48G-PWR (J8693A)
ROM Build Directory: /sw/rom/build/bmrom(t2g)
ROM Version: K.12.20
ROM Build Date: 23:33:11 Apr 24 2009
ROM Build Number: 24648
SSC Version: SSC 34 190120060501
MSI Version: 3
CSI Version: 7
Copyright (c) 1995-2005 Hewlett-Packard Company. All rights reserved.
               RESTRICTED RIGHTS LEGEND

Use, duplication, or disclosure by the Government is subject to restrictions as set forth in subdivision (b) (3) (ii) of the Rights in Technical Data and Computer Software clause at 52.227-7013.

Hewlett-Packard Company, 3000 Hanover Street, Palo Alto, CA 94303

Enter h or ? for help.

=>

For those of you new to Procurve, the Monitor ROM prompt looks like this =>

When you are in this prompt, you can type h or ? for help:

=>h

LAN Monitor Commands

do(wnload) – Download via Xmodem
sp(eed) – Set a new baud rate
h(elp) – Display help screen
? – Display help screen
id(entify) – Print out identification string
jp(jump) – Jump to product code, optional 1-primary, 2-secondary
q(uit) – Exit the monitor
boot – Reboot the system
reset – Reset the system
v(ersion) – Display version information
lsdev – Display I/O device table
fsck – File system check
ls [path] – Terse directory listing
ll [path] – Detailed directory listing
format – Format storage device
blkdump – raw I/O
pwd – Print current working directory
cd – Change directory
mkdir – Make directory
MORE? (Ctl-C to abort)
rmdir – Remove directory
rm – Remove file
cp – Copy file
mv – Move file
cat – Dump file contents
attrib +- – Change the attributes on a file
(a)rchive, (h)idden, (s)ystem, (r)ead-only
=>

Note that the output might vary depending on switch model and code version.

If you press V it will give you version information which you can give you some clue as to what next compatible image is.

=>v
Directory: /sw/rom/build/bmrom(t2g)
Build Date: 23:33:11 Apr 24 2009
Version: K.12.20
Build #: 24648
=>

Typically, a switch will boot into Monitor ROM when it has a bad or corrupted flash or when the image is not compatible with the Boot ROM. The way to fix this is to try and put a different image on the switch; one that is compatible with the Boot ROM in the switch. By compatible, I meant the image has to have the same Boot ROM version or one revision up from the current Boot ROM in the switch.

With the software version that I have at the time, the only option I can use to restore the code is through x-modem done over the serial console which can be painfully slow since the a typical serial console connection runs at 9600 baud. To speed things along, I change the baud rate to 115200 by using command speed 115200. When you issue the aforementioned command, you’ll probably see some garbage on the screen since the switch and the computer are now running at different speed. Just change the baud rate on your terminal client to 115200 and hit enter then you’ll get the readable screen back.

To initiate the x-modem transfer, type do for download:

=>do

You have invoked the console download utility.
Do you wish to continue? (Y/N)>

The switch will prompt for confirmation. Hit Y then start the transfer. At this point, in your terminal client, start x-modem transfer and pick the firmware you want to send to the switch. You’ll end up with something like this:

Starting xmodem transfer. Press Ctrl+C to cancel.
1% 59 KB 6 KB/s 00:24:23 ETA 0 Errors

It’ll take a while to send the file. Just remember that you do not have to change the baud rate. 9600 will work just fine but it will take forever to finish. Once the file has been transferred, you can issue the command boot to reboot the switch.

Now that’s how you recover from corrupted flash/wrong code version on Procurve 3500 series switches. On the 5400 series, you can also do the same thing. However, since the 5400 series have removable management module, it can be a little bit easier – you just need some spare modules or some memory card reader.

On the 5400, as I understand it, the boot rom is flashed to NVRAM and the code and configuration files are stored in flash. So what you need to do is making sure NVRAM and flash card have the same or compatible boot rom then the so-called “corrupted flash” will work again. You can do this in two ways. One is to put the correct code on the flash card and two is to flash the correct boot-rom on the management module.

So you can use x-modem transfer to copy code as outline above for the 3500 or find a spare management module and flash compatible boot rom to it, swap out the flash card then put it back to the switch. Since the configuration file is stored on the flash card, you won’t have to reconfigure the switch.

Now here’s something that I’ve been thinking about but haven’t tried yet since I don’t have a card reader handy. The code is stored on a flash card, you can probably use a generic card reader and update it unless Procurve is using some sort of proprietary file system.

I hope with the information above, it can help you restore corrupted flash on Procurve switches. If I have left something out or if you have any tips to share, feel free to leave a comment.

Filed Under: Home, Tips & Tricks Tagged With: ,

Know Your TFTP Server

May 24, 2012 By 2 Comments

From the previous blog, What is a TFTP Server?, we know that a TFTP is a file transfer protocol, running on UDP port 69 and typically used to transfer files to/from network devices. Now let’s take another look at TFTP and learn what to look for in a TFTP Server.

TFTP was first drafted in the early 1980’s in RFC 783 which specified a 16 bit Block number with 512 bytes or octets per data packet. As the result, the maximum file transfer using TFTP is 32MB’s. That was sufficient in the 80’s when it was proposed but as computing grown and technology advanced, 32MB’s became insufficient so in the 90’s a host of RFC’s were proposed and revised the TFTP Protocol to its current standard.

The latest of the TFTP related RFCs includes RFC 2347 (TFTP Option Extension) which provided the flexibility to negiotiate additional optional parameters and extends the capability of the orginal RFC and yet still be compatible with legacy software and/or devices implemented the earlier RFCs. It paved the way for others like RFC 2347 (TFTP Block Size Option) & RFC 2348 (TFTP Block Size Option).

RFC 2348 – TFTP Blocksize Option: Blocksize Option allows for the negotiation of the block size value to be in the range of 8 to 65,464 octets instead of the fixed 512 octets and extends the file size from 32MB’s to about 4GB’s (65,636 x 65,464).

RFC 2349 – TFTP Timeout Interval & Transfer Size Options: Timeout Interval Option specifies the amount of time a server will wait for an acknoledgement packet (Option Acknowledgement or OACK) before resend the previous packet. Transfer Size Option lets the receiving device knows how big the file is before the transmitting it. This is done to conserve bandwidth by making sure the receiving end can store the incoming data instead of blindly transmitting the data until the receiving end chokes on it. Some software like Pinkie also takes advantage of this option to calculate and report the progress of the file transfer thus providing a more responsive User Interface.

So in summary, when choosing your TFTP Server, you should choose one that can support Option Extension, Blocksize Option as well as Timeout Interval & Transfer Size Options. This can help you avoid potential issues when transferring firmware to network devices; especially to high end Cisco switches whose firmware tend to be larger than most others.

As a network tool, Pinkie has a multithreaded TFTP Server built-in and implemented all of the aforementioned RFC’s. It also does so in a unique One Window, One App architecture that can help reduce the desktop clutter, cut down the number of application you have to maintain and update. If you haven’t done so already, download Pinkie and try it out.

Further Readings:
RFC 783
RFC 1350
RFC 1782
RFC 1783
RFC 1784
RFC 1785
RFC 2347
RFC 2348
RFC 2349

Filed Under: TFTP Tagged With: , ,

What is a TFTP Server?

May 22, 2012 By 4 Comments

In this blog, I’ll attempt to give you some highlights of what a TFTP Server is without going too deep into the technical details, how it operates and what you should know about it.

TFTP stands for Trivial File Transfer Protocol. As the name suggests, TFTP is a mechanism to tranfer files from one device to another. It is typically used by network administrator to copy configuration file, log file and firmware to/from networking devices.

TFTP was designed to be small, simple and easy to implement. It uses UDP port 69 and runs on IP networks. It doesn’t provide any kind of error handling capability so all the error handling has to be done at Layer 7 – the Application Layer.

Per RFC 1350, a typical TFTP data payload has a minimum of 4 bytes and 516 max. The TFTP data packet has the following format:

OpCode Block # Data
2 Bytes 2 Bytes 0-512 Bytes

The OpCode signals the type of operation whether it is a read request or a write request… The Block # contains the block number or ACK number of the data packet being transmitted. The Data field ranges from 0 to 512 bytes in length. If it is exactly 512 bytes, then there is more data to follow; otherwise, it is the last data packet and signals the end of the file transfer.

It is important to know that the Block # field is two byte long or 16 bits total which yield 65,536 block numbers (2^16). So this means the largest file TFTP can send or receive is 65,536 x 512 = 33,554,432 bytes or 32MB’s. This is the reason why files transfer with size larger than 32MB’s often fail.

That might not make sense to some of you right now since you might have done some file transfers that are larger than 32MB’s. It is possible to transfer files larger than 32MB’s using TFTP. The only difference is the TFTP Server must support RFC 2348 (TFTP Block Size Option). But that will be the topic for another blog.

So in summary, TFTP Server is a mean to transfer file, used to send/receive file to/from network devices. It uses UDP port 69 and can send or receive a file with a “maximum” size of 32MB’s.

Futher Readings:
Know Your TFTP Server

Filed Under: TFTP Tagged With: , ,