| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 4294.1 | Steady on... | KERNEL::FREKES | Like a thief in the night | Thu Mar 20 1997 12:00 | 26 |
|
>Some of the differences are having pink lights
>on some or all of the DECrepeater 900TM group of 8 ports. We have
>also noticed discrepancies in the Lan interconnect view where the
>fiber connection from the 900EF does not show connected to the
>fiber lan and yet hubwatch shows this connection.
What version of the MAM code are you running, and what version of firmware
are you running on the individual modules? Quite often you will see this
with version mismatches.
You should never have this.
>This must be fixed as soon as possible!!!!!
Yeah you are probably right about that.
>Please contact me with questions and when this has been fixed...
You are assuming that there is problems with the product. More than likley
the problem is with your configuration. You have not supplied enough
information for anyone to succesfully diagnose this. Perhaps you would
like to supply the versions of firmware in use etc. Any error logs etc.
Steven Freke
UK CSC Networks
|
| 4294.2 | y | SALEM::BARLOW | | Thu Mar 20 1997 12:34 | 21 |
| I know we don't have the latest version of firmware on our hubs. Given
that updating the HUBs requires disconnecting 100+ people per hub with
20+ HUBS I am not sure when we will be able to get every HUB and module
within the HUBS up to date.
My concern is that Version 1.0 of ClearVISN worked fine when comparing
HUBwatch with MultiChassis Manager. Why does upgrading to 1.1 all of a
sudden make MultiChassis Manager invalid. If we had to upgrade all of
our HUBS and every module within our HUB to the latest version, each
time a new version came out, it could be a full time job. We are
trying to get ClearVISN up and running so we can automate the upgrade
process. I have a major concern when an application gives false data
when upgraded (vs a previous version that was correct) and requires
that all systems and applications be upgraded so they speak the same
language.
All I am asking for is to have MultiChassis Manager of clearVISN 1.1
operate the same way as it did for clearVISN 1.0.
Craig
|
| 4294.3 | odd way of requesting assistance | KERNEL::FREKES | Like a thief in the night | Thu Mar 20 1997 12:47 | 39 |
| > I know we don't have the latest version of firmware on our hubs. Given
> that updating the HUBs requires disconnecting 100+ people per hub with
> 20+ HUBS I am not sure when we will be able to get every HUB and module
> within the HUBS up to date.
One of the many duties of a network manager.
> My concern is that Version 1.0 of ClearVISN worked fine when comparing
> HUBwatch with MultiChassis Manager. Why does upgrading to 1.1 all of a
> sudden make MultiChassis Manager invalid.
It does not make it 'invalid' it just makes is a lot harder to manage.
Without looking at the code and find out what is different I can't answer
your question. Only to say that the likes of CLEARvisn development team
go to a lot of effort. pointing out that you should always run with the
current version. There is a good reason for it.
>If we had to upgrade all of
>our HUBS and every module within our HUB to the latest version, each
>time a new version came out, it could be a full time job.
At the end of the day the decision to upgrade is yours, but don't write notes
blaming the product when you are warned against running with different
levels of firmware, and you have chosen not to upgrade. For what ever the
reason is.
>I have a major concern when an application gives false data
So do we, which is why we recommend strongly that you run with correct
versions of firmware.
> All I am asking for is to have MultiChassis Manager of clearVISN 1.1
> operate the same way as it did for clearVISN 1.0.
Why do you think one is called 'clearVISN 1.0' and the other is called
'clearVISN 1.1'. Because they are different.
Steven
|
| 4294.4 | | NETCAD::MILLBRANDT | answer mam | Thu Mar 20 1997 13:48 | 11 |
| Hi Craig -
You have to upgrade your hub to V5.0 before using clearVISN V1.1a to
manage it. Otherwise it won't work. The problems you are seeing
with "pink leds" etc are symptoms of the non-working configuration.
If you want to investigate how clearVISN V1.1a works and check out
Flash Loader, upgrade one hub and one PC. Be sure to leave
clearVISN 1.0 around for managing the older hubs until all are
upgraded.
Dotsie
|
| 4294.5 | It's a VERY BIG HOLE and needs to be fixed | PTOJJD::DANZAK | Pittsburgher � | Sat Mar 22 1997 23:09 | 39 |
| re: .3
Ahem,
We do *NOT* provide any indication of what the CORRECT version of hub
firmware is.
Remember, we build PLUMBING for data, you only think about it when it
breaks.
None of our sales literature explains the need for firmware. We do not
provide a way to automatically get updates.
We do NOT provide any guides about things like when you need to assign
IP addresses to modules. If you have hubs full of repeaters, have them
distributed throughout a campus of 6 buildings, about 36 floors, you
need to put on your damn roller skates and go have an IP address
assignment party. (Went through this at Roadway Package Systems).
AND, if your hubs are remote - i.e. like RPS in Phoenix and you're in
Pittsburgh, you need to FLY TO PHONIX to set it up.
The idea of all of this integrated firmware simply does not scale
because we have no way to upgrade it, provide guidelines, etc.
ANd, Roadway Package Systems - based on their DEChub experience at
their corporate site - will NOT deploy them remotely because they are
not manageable by their hub vendor's own applications (i.e. CLEARvisn,
things like changing community strings, setting IP addresses etc.) We
*LOST* a 50 state implementation because of that.
And, because of lack of basic remote management features, i.e. like
simple TELnet, we lost *ALL* of Pitt's campus (50 buildings, user
population of 60,000 etc.).
Bottom line - nice equipment - does NOT scale because of lack of some
basic management functionality.
It is a VERY BIG HOLE.
|
| 4294.6 | Some gotchas... | PTOJJD::DANZAK | Pittsburgher � | Sat Mar 22 1997 23:23 | 57 |
| Note: to .0
Unfortunately, CLEARvisn provides no warning about when it's going to
suicide your hub, incorrectly report configurations, or perform other
network management faux-pas.
Before upgrading CLEARvisn, you really do need to be sure to get all
of the recent firmware, and schedule in a time to make your network
unavailable to perform the upgrades.
Some notable "gotchas" on upgrades:
- It generally works best if each module in the hub has a TCP/IP
address. This allows you to directly load firmware to it. Some
older modules, like DECrepeater 900TMs, can only be loaded if
they have a TCP/IP address.
You load a module using the CLEARVISN Flash Loader. Enter
the IP address directly to do this.
You can perform a 'hub assisted load' on newer modules. This
is done by using the IP address of the hub, and then the "slot
number" over on the right of the screen. The gotcha with this
is that it takes extra time to "copy to the hub" and then
'copy to the module'.
Bottom line, get EVERY module in your hub an IP address.
- I think that typically you want to upgrade the hub manager first,
then the individual hub modules. That way if you upgrade a module
with firmware beyong the hub capability (i.e. like new
FDDI configurations etc.) the hub itself doesn't go
insane.
- With upgrades, some old versions of firmware (i.e. V3) will
cause the hub to totally loose the MAM code, require that it
be BOOTPed from the serial port. If you are upgrading some
critical production hubs, it's good to have a spare hub on
hand as a backup. There are no field tools to recover a hub
in this state (i.e. CLEARvisn doesn't help you do this, nor
ancillary tools.)
- Note, some older repeaters don't seem to be able to be upgraded.
When we tried at one site, we ran into 3 which could NOT be upgraded
to current code.
- Because of changes to the hub code, etc., the prior verions
of CLEARVISN won't work on newer hubs and the newer version
doesn't work on older hubs - ie. it will APPEAR TO WORK, but may
not. So if you're upgrading to the CURRENT CLEARVISN, be sure
to have an EXTRA MANAGEMENT STATION around. ONE to run the
OLD software and one to run the new until you get everything
at the new rev.
Nope, it ain't pretty, nor easy, nor documented. It's eating our time
at larger accounts.
|
| 4294.7 | The purple LEDs may be result of MCM change | NETCAD::DRAGON | | Mon Mar 31 1997 11:06 | 37 |
|
Hi,
One change that was made to clearVISN MCM V6.0A, which may help
shed some light on the original problem seen is the following:
With older DECrepeaters/PORTswitches (ie 900TM, 900GM) which have
multiple banks of LEDs, MCM will now show purple LEDs if the "Bank
Display Button" is in the "Hold" state. That is the state which stops
the LEDs from cycling through the different banks. This was done to
correct a problem which was less obvious. When the Bank LEDs were in a
hold state, MCM was not obtaining full LED information from the device.
As a result MCM was showing LEDs to be off/black when in fact they
could have been in any state. Since we cannot get the actual state
of the LEDs from the device, it was decided that the lack of info.
should be made obvious to the user, so that they did not make
decisions based on bad data. As a result the LEDs are shown purple.
This may or may not be your problem. To see if it is, check out one
of the DR900TMs that is having this problem and see if the "Bank
LED Hold" button is in the hold state. If it is, press it so that
the LEDs cycle and then see what MCM shows for the device's LEDs.
With newer repeaters/PORTswitches (ie 900TP) MCM will now get all LED
info. regardless of the state of the "Bank LED Hold" button. There
is no plan to change this in devices which now exhibit this
problem.
On the other topic about MCM/FW mismatch. Steps are being taken to
not allow a newer version of MCM to operate on an older version of
MAM in regards to LAN Interconnect. Since Release Notes and warnings
in the documentation do not seem to matter (until of course someone
blows away their net) this is the safest course for us to take.
I hope this info. helps.
Bob
|
| 4294.8 | LAN Interconnect changed to check MAM FW version | NETCAD::MOWER | | Sat Apr 12 1997 19:01 | 13 |
|
> Unfortunately, CLEARvisn provides no warning about when it's going to
> suicide your hub, incorrectly report configurations, or perform other
> network management faux-pas.
At least one of these "faux-pas" have been fixed. The clearVISN/MCM
LAN Interconnect view has been modified to check that the MAM being
managed is at the correct firmware version.
Please see note 4297.3 for full details.
Carl Mower.
|