[Search for users]
[Overall Top Noters]
[List of all Conferences]
[Download this site]
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 |
2433.0. "Control FIND functions scope in HUBwatch???" by DECPRG::PAVLUP () Wed Jun 28 1995 04:37
Is there any way how to control/limit the scope of FIND ADDRESS and/or
FIND DUPLICATE functions of hubwatch?
The rationale for this question (request) is as follows.
A customer has a network of 8 900MS hubs with FDDI boxes and repeaters 900TMs.
The network is managed form an MCC station with HUBwatch V3.1. The customer
is using the above functions for their management tasks, and a problem
occurs that is a correct result of the functions' specification but causes
troubles, and makes the functions hardly useful.
The problem is bound to an "outside" connection between a repeater 900TM and
a DECswitch 900EF which serves as an interconnection between two hubs.
The interconnecting repeater port remembers correctly stations communicating
across the link. However, these stations are also connected to specific
ports of other repeaters in the network. Correctly again, HUBwatch displays
each of these stations as duplicate addresses.
Though I see that this is the expected behaviour, the function would be more
useful, if such known configuration points could be isolated and excluded
from the FIND functions scope (as, I assume, it is done for the backplane
repeater ports...?).
The question is first whether it is possible (somehow) to control the
scope of HUBwatch functions. If the answer is no, an obvious question is
whether something like that is planned.
Thanks a lot for answers and suggestions!
Regards Petr.
T.R | Title | User | Personal Name | Date | Lines |
---|
2433.1 | | SLINK::HOOD | Maine State Bird: The black fly | Wed Jun 28 1995 10:45 | 2 |
| The Find functions work off the HUBwatch agents file. If you don't want
Find to touch a repeater or a hub, remove it from your agents file.
|
2433.2 | That's right but not a >>solution<< | DECPRG::PAVLUP | | Thu Jun 29 1995 06:10 | 16 |
| Thanks for the response.
I know that one. It was actually the first workaround I've recommended
to the customer (and it works, of course). But I have'got to agree with
the customer that it spoils the power of address finding and duplicate
finding functions because you always exclude some portion of the network
from your search.
So I believe that this is not a solution. I think that a fully general
solution would allow to exclude defined repeater ports from MAC address
searches (as e.g. the backplane ports are by default - I believe).
The question is whether it can be achieved somehow (e.g. by setting some
variable in MIB) now, or in the future...
Regards Petr.
|
2433.3 | | SLINK::HOOD | Maine State Bird: The black fly | Fri Jun 30 1995 11:59 | 5 |
| There are a few changes to FIND that we're thinking about for future
releases. Your idea is now officially on our things-to-think-about list.
Tom Hood
HUBwatch
|
2433.4 | Will be watching... | DECPRG::PAVLUP | | Mon Jul 03 1995 03:26 | 8 |
| Hi Tom,
though in a little corner of my heart I hoped that a magic quick and easy
solution exists, your reply still sounds good to me.
Thanks and regards
Petr.
|