| Title: | DEChub/HUBwatch/PROBEwatch CONFERENCE |
| Notice: | Firmware -2, Doc -3, Power -4, HW kits -5, firm load -6&7 |
| Moderator: | NETCAD::COLELLA DT |
| Created: | Wed Nov 13 1991 |
| Last Modified: | Fri Jun 06 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 4455 |
| Total number of notes: | 16761 |
Thanks much to the efforts of Tom Hood and Atul Bansal, I was able to get
HUBwatch running on a VMS system to manage what in reality was a remote
DEChub900.
This configuration looked something like this:
HUBWATCH VAX
|
--------------------------------------
|
DECNIS 600
|
56kb WAN link
|
WANrouter 90 (in DEChub900)
When DEChub900 was local to HUBWATCH, no problems in getting connectivity.
However, when DEChub900 was remote, a couple problems occured......first
we had questionable results in pinging and tracerouting to the hub and/or
the components in the hub.
Normally we would use NCL, since this is a link state routing environment,
to show ROUTING IP DEST ADDRESS and see that the WANrouter could actually
see other systems on the local lan. Due to differences in the way in which
the WANrouter 90 and other DEC routers have been implemented, this is not
possible. (This is where product inconsistancies can really hurt!).
Only in knowing which counters to watch were we able to detect IP
initialization traffic from HUBwatch.
UCX was also questionable due to strange ping behaviour.....as it turns out
we have two paths out of the local LAN via different routers. You can tell
UCX to have knowledge of more than one gateway and more than one default
route, but only one appears to work.....the first one in the list.
So once this was resolved, I found that not only did I need to set the IP
address in the HUB, but I also need to reference a hub device, in this case
one of the 10baseT repeaters used as the point of management, with regard to
its' mac address......this reference needed to be in HUBWATCH_AGENTS.DAT.
If this entry was not in the file, the whole hub was unreachable.
I don't recall having to do this for the case in which the HUBwatch system was
local to the HUB....HUB folks please correct me if I'm wrong here!
The point I'm trying to make is that there appear to be some very subtle
"gotcha's" in getting this application to work. In addition, if some problem
occurs in the device chosen in the hub as the management point, then another
device will have to be appointed. How automatic is this?
This also assumes that the network manager has kept close accounting of all
mac addresses of all devices in all hubs?????
Yes, one can choose to update the HUBWATCH_AGENTS.DAT file via the community
"manage table" option, but this must be done specifically....it is not
automatic.
If a site has tens or hundreds of hubs, this management task could grow to
very large proportions w/o some sort of additional automation....any thing
planned?
Also, if lets say 100 or more hubs are in place, which is not at all
inconceivable and one only has a single HUBWATCH_AGENTS.DAT file, how does
HUBWATCH determine which devices are in which hub and how long does it take to
read in this file given the fact that devices could be widely scattered through
out the file if random attempts are made to update same via the iconic
interface?
Any thoughts, comments welcomed.
Al
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 784.1 | QUIVER::SLAWRENCE | Wed Mar 02 1994 21:17 | 11 | ||
I gather that you had configured the In-band address of the hub (at the
hub setup port) and designated the IP Server to be a DECrepeater900TM
in some hub slot. Correct?
Then you found that you needed to put the MAC address of that repeater
into the hubwatch agents file in order to manage the hub?
Did you configure a default gateway address on the repeater chosen as
IP Server? You need to redirect the hub setup port to that slot and
use the menu choice "Set In Band interface Default Gateway address".
| |||||
| 784.2 | Is this needed....and why difference (local vs remote)? | LICAUS::LICAUSE | Al Licause (264-4780) | Thu Mar 03 1994 11:38 | 21 |
>> I gather that you had configured the In-band address of the hub (at the >> hub setup port) and designated the IP Server to be a DECrepeater900TM >> in some hub slot. Correct? Yes >> Then you found that you needed to put the MAC address of that repeater >> into the hubwatch agents file in order to manage the hub? This is correct! >> Did you configure a default gateway address on the repeater chosen as >> IP Server? You need to redirect the hub setup port to that slot and >> use the menu choice "Set In Band interface Default Gateway address". Yes...this was setup....but it wasn't clear and it appears that not everyone is aware that this also needs to be done. Why does this differ depending upon whether HUBwatch is local or remote to the hub? | |||||
| 784.3 | QUIVER::SLAWRENCE | Thu Mar 03 1994 13:57 | 6 | ||
We are addressing the problem with documenting the default gateway
setup.
It should make no difference whether or not HUBwatch is local or
remote; I'll talk with Tom about this.
| |||||
| 784.4 | There's Big Macs, and the MacIntosh, but no MACs for repeaters! | SLINK::HOOD | I'd rather be surfing | Thu Mar 03 1994 16:56 | 59 |
I was starting to get confused by this note. But now, I'm officially confused.
From a HUBwatch point-of-view:
(1) If you are using a 900 repeater to provide IP services to your DEChub 900,
you do not need to put any information about the repeater in your agents
file. None. Whatsoever. If it's there or not should make absolutely
positively not a whit of difference.
(2) The MAC field in the agents file is never, never, never needed for a
repeater. It is never ever needed for any 900 device (except maybe the
DS900TM - I forget exactly.) That field is there as a hack to provide
manageability to older devices and to certain other devices that aren't
good hub citizens. Repeaters are good hub citizens.
Example:
* DEChub 900. DECrepeater 900TM provides IP services. You've got a few
other modules, too, including a DECbrouter and a DECserver 90TL.
Your agents file must contain two entries: one for the brouter, one for
the terminal server; both must contain the MAC addresses. For
convenience, you can also include an entry for the DEChub900. It will
contain the in-band ip address, agent name, community string, timeout,
and retries for the DEChub 900 agent. Agent type = DEChub900.
No information about the repeater is included in the agents file.
* Now, if you choose to manage the DECrepeater 900TM standalone, you might
also choose to include an entry (no mac, please) for the repeater, with
the repeater's own IP address. But in a hub this is definitely not
necessary!
I'm also confused about the path...
If you're doing in-band management, HUBwatch doesn't care about the path
between your workstation and the agents to be managed. If SNMP (which is
a routable protocol) can get through that path, HUBwatch is happy. In fact,
HUBwatch doesn't know if it's being run on the other side of 20 routers
or is connected directly to a repeater port.
I've talked to hubs in Singapore, Europe, and all over the US from my
workstation here in Littleton, without modifying my agents file (except to
add terminal servers or brouters).
What you *do* need to be sure about is your basic IP setup on both your
workstation (UCX or TGV MultiNet) and on the agent is correct. Make sure
gateways are defined.
Because the DEChub program includes a lot of older modules, and because the
newer terminal server modules and the DECbrouter 90 modules don't setup like
the other hub modules, configuration can be interesting, both in module set-up
and in HUBwatch set-up. It is really wicked very extremely ultra awfully
darned quite important to read the configuration manual. The people who
wrote it did a very nice job on it. It is EASY TO USE and it provides complete
information.
Now, if what you're seeing doesn't match what I've written here, and if you
configured things in accordance with the config manual, well, something is
definitely broken.
Bored with snow, I remain sincerely yours,
Tom Hood
HUBwatch
| |||||
| 784.5 | LEVERS::ANIL | Thu Mar 03 1994 22:08 | 15 | ||
Scott/Tom: We should word the documentation for setup of the default
gateway carefully. For example, in this config, the default gateway
would not need to be set-up for SNMP get/set communications. It's needed
for unsolicited IP traffic originated by the module: traps and, if
applicable, TFTP (when Flash-upgrading a module). In practice it's
usually done for IP end-station setup.
Good feedback, by the way. To answer one of the other questions,
if the "IP Server", a repeater in this case, were to fail,
then the hub would not automatically fall back to another
module. Another IP server would need to be manually set up on
the hub console. (It's a lot harder to do this automatically than
might appear.)
Anil
| |||||
| 784.6 | Thanks for the feedback and concern! | LICAUS::LICAUSE | Al Licause (264-4780) | Wed Mar 09 1994 18:37 | 12 |
I must appologize for some confusion on my part. On further investigation, I was able to reach the HUB as described in .0 w/o having any definition in the HUBWATCH_AGENTS.DAT file. We were also suffering from some connectivity issues which seem to create some strange routing annomolies....can't say that their completely solved...but I was able to bring up HUBWATCH w/o an entry in the file. I still have much to learn about TCP/IP!!! Al | |||||