| Michael, can you describe what you saw the DECswitch state leds
do during the down-load and flash upgrade sequence? The reason
I ask is so it can be clearly understood what you mean by the
upgrade not working (other than the obvious).
The port state leds serve a purpose during the down-load/flash
upgrade procedure. The port state leds light in sequence from
port 1 to port 5 as the sequence progresses. This sequence is true
for both a manual upgrade and a bootp (in the instance where the
image is corrupt).
port 1 lit - load request
port 2 lit - load under way
port 3 lit - crc is checked
port 4 lit - fddi portion of image written to flash from landing pad
port 5 lit - main portion of image written to flash from landing pad
This is followed by all state leds flashing alternately green & yellow.
So if you can describe what you observed for the initial load that
you say took an hour and what you saw when you performed the bootp
it would be helpful.
One other thing, once the image is corrupt and it does the bootp thing,
it is expected that you have a cable on the first Ethernet port (port 2
of the DECswitch), or the FDDI port (these are the default port data paths
used in the bootp sequence).
When the normal upgrade from the console is invoked, one can use any
DECswitch port to connect to the LAN to down-load the image.
Bob
|
| This appears to be the most logical note to add on to with the
following problem/question...
We have had the unfortunate experience of corrupting the code running
on a DECswitch 900 a couple of times. Since this is a lab situation,
it's not unexpected that we mess things up on occassion. The real
problem becomes how to satisfy the primitive boot request from a
DECswitch 900 once this has happened. Everything is pretty much done
with the clearVISN product set now. Most of the lab PC's are running
the 1.1a suite.
All of the TFTP servers we have tried on the PC, fail to load the
DECswitch 900. This list includes, Router Manager TFTP server,
Netrider Loader, and the BOOTP/TFTP server provided with the DECNIS
configurator. Looking at a network trace of the operation, it appears
that the reason none of these TFTP servers work is because the Read
request from the DECserver 900 does not have a checksum for the UDP
header. At least one of the IP reference books I have states that this
checksum is optional. However, the author states that any vendor that
does not provide a UDP checksum is asking for trouble.
A DIGITAL UNIX box will load the DECswitch 900 just fine under these
circumstances. So we know it's some implementation difference between
the UNIX TFTP server (deamon), and the PC variants. Since it would be
very costly to replace the boot rom in the DECswitch, I would believe
the best solution would be to modify the TFTP server provided with
the clearVISN core.
Can anyone confirm our theory? Suggestions??
Randall Buck
MCS - Network Support
|