| >Is there any reason for this?
Brad, there is reason behind everything we do! Sometimes it's a good
reason, sometimes not.
When HUBwatch is trying to figure out which IP/Community pair to use, it
asks the MAM for the list of all possible agents associated with a module.
The net effect of the algorithm used by HUBwatch 4.1 and previous versions,
is that the highest non-MAM IP address for the module is used. HUBwatch
sends an SNMP test message to that address/community. If it is successful,
that's the address/community it uses. If not, it uses the MAM's address
and uses <comm>-<slot> as the community
Lack of success can come from many things - typical case is that the module
is on a LAN that's not IP accessible to the HUBwatch workstation.
[I haven't looked at this in a few months; it might use the lowest numbered
IP address, but everything else is the same.]
I think (not sure) the algorithm was beefed up for V5.0
Tom Hood
clearVISN eng (VLAN Mgr)
|
| Well Tom,
You are correct that the DR900TM and DS900EF where not accessible to the
Hubwatch mgmt station. So, they did put up the mam address in the mgmt info.
When I connected them so they could be reachable by the mgmt station, the mgmt
info changed to their respective addresses.
I hope in future releases, they put management info separate from module info so
the actual ip address of the device can be seen. Reason for this is we have
several dis-jointed lans in one hub.
Brad
|