How to use BulkDNS in Pinkie

In a way Bulk DNS, works pretty much like PingSweep. It does DNS lookup & ping but the difference is it doesn’t do that for a subnet or a range of consecutive IP Addresses.

This is particularly useful when you need to do verify and make sure the newly deployed devices are live and have the proper DNS setup. The Bulk DNS feature can take input from a textbox or from a text file. Text file should have either IP Addresses or Hostnames; each on a separate line.

Here’s a few tips to be more efficient with Bulk DNS:

  • Show Hostname First: This option, when checked will arrange for the Hostname column to show before IP Address.
  • Include Ping Time: If you just want to do DNS lookup, then leave this option unchecked. Check this option only if you wish to check DNS and also ping the host to see if is on the network.
  • Include Row Number: If this option is checked, it will show the row number for each host on the Bulk DNS list.
  • Copy Only Live Hosts: This option works with the Include Ping Time option. It will only copy the hosts that responded to ICMP requests. Checking this option will automatically enable Include Ping Time since it’s requires that work work properly.
  • Copy To Clipboard: Click on Copy To Clipboard button will copy the Bulk DNS result to the clipboard. Typically you would want to set the other options to your liking then click on this button to copy the Bulk DNS result.
  • Copy IP Address: At times, you might just want to copy a particular IP Address. To do this, click on a row in the result listview. The selected host’s IP Address will be copied automatically.
  • Those are just a few ways to take advantage of the Bulk DNS feature in Pinkie. With that I hope you’ll have a better understanding of how it works and use it more in the future.

    Best regards,
    Brian

Redirect Procurve’s output to TFTP Server

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.

Procurve corrupted flash recovery

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.

Using TFTP Server Feature in Pinkie!

If you are a network professional then chances are you have dealt with and needed a TFTP Server before. TFTP stands for Trivial File Transfer Protocol. The protocol was developed many, many moons ago and it is still one of the most common way of transfer firmware and/or configuration files to/from network devices.

TFTP Server is simple; there’s not a whole lot of options to it as it was specifically designed that way. Below are some explanations about its settings:

  • Port Number: By default TFTP Server runs on UDP port number 69. You should not need to change this number unless you have a specific security requirement to close port 69.
  • Server Timeout: This is how long the TFTP Server will wait for a data packet or an acknowledgement from the client. In Pinkie, the default setting is 5 seconds. If you wish to change it, go to Application Settings dialog, click on TFTP Server tab and change it there.
  • Maximum Retry: This is how many times Pinkie will attempt to retransmit a data packet after it encountered a timeout. You can change this value in Application Settings dialog.
  • TFTP Folder: For TFTP Server to work properly, this folder must be set. This is where Pinkie looks for the file requested by a TFTP client. This folder should be writeable if you need to copy files from your devices to the machine you run Pinkie on.

Most antivirus software will block port 69 by default. You might have to create an exception and allow UDP port 69 in order to let the TFTP traffic pass through. If you use Pinkie for server admin purposes, you should not be concern with this particular feature and as the result, shouldn’t need to open port 69.

TFTP is simple, widely used and will probably be sticking around for the foreseeable future. With it built in to Pinkie, hopefully, it will reduce another application that you have to install on your machine to get the work done.