| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 3910.1 | new functionality every day | SKIBUM::GASSMAN | | Fri Oct 16 1992 12:37 | 32 |
| I've also heard that the HP/IBM approach involves a combination of
listening and polling. This is effective on a LAN, but across a WAN
this doesn't make sense. Another approach that IBM is pushing along
with 3COM is the use of CMIP over an ethernet/token-ring logical link,
making notification when if the connection oriented logical link dies.
The polling factor is becoming an issue - not that it should in all
cases because netmgt traffic may be only a few percent of traffic, but
it is becoming marketing hype by those that vendors that strive to
minimize it. MSU's approach is one of the best on the market, because
it supports remote polling daemons which report back to a central
registration process thru standard distributed SQL techniques. MSU
also has a leading polling technique by asking routers for their
interface status during a poll, not just ping or simple request.
The DECmcc BMS product has not yet focused on the node status problem
or the incremental autotopology problem, which are related. The
framework service "domain to domain copy" needs to be supported to do
it right. However, daily thought is being put into figuring out what
the right solution should be. Working with MSU's existing pollers
either at the SQL level or using some kind of RPC/TRAP mechanism may
make sense.
Future functions available (from leading vendors) will allow domains to
be created on the fly which show top talkers, features to fade objects
to shade or remove from the 'active' map if they have not been heard
from for a while will exist, and status information will be consolidated
from many sources.
There is lots of talk about HP's owning the GUI for DME. I sure hope
it's not going to be that limited!!
bill
|
| 3910.2 | More on HP OpenView reachability | CUJO::HILL | Dan Hill-Net.Mgt.-Customer Resident | Fri Oct 16 1992 15:10 | 15 |
| HP OpenView also checks IP routing nodes to determine node
reachability. This is how they get around the problem of simply
listening for packets on a LAN segment ((Since bridges filter traffic
that is not destined "off segment", there may be instances where the
network management station will never see a node's packet.)).
The DECmcc V1.3 IP reachability method is billed as being substantially
better in performance and functionality by "listening" to the network.
There is talk about using the same methodology as MSU. Is this
happening?
DECnet Phase IV node reachability still must be addressed. (( Are you
tired of hearing this yet??? ;-) ))
-Dan
|
| 3910.3 | IP Poller does pings... | CHRISB::BRIENEN | DECmcc LAN and SNMP Stuff... | Fri Oct 16 1992 16:08 | 12 |
| RE: 3910.2 (Dan Hill)
> The DECmcc V1.3 IP reachability method is billed as being substantially
> better in performance and functionality by "listening" to the network.
The V1.3 IP reachability method is actually an IP Reachability Poller
(it "pings" entities of interest).
The poller turns out to be *considerably* more efficient (and faster!)
that using a wildcarded alarm rule checking ipReachability.
Chris
|
| 3910.4 | ping sync interfaces?? | CTHQ::WOODCOCK | | Fri Oct 16 1992 17:56 | 8 |
|
> The V1.3 IP reachability method is actually an IP Reachability Poller
> (it "pings" entities of interest).
How is the 'ping'er set up? Can it also hit the other (sync) interfaces
for status? This also appears more efficient than SNMP.
brad...
|
| 3910.5 | | YAHEY::BOSE | | Mon Nov 02 1992 10:58 | 7 |
|
>>How is the 'ping'er set up? Can it also hit the other (sync) interfaces
>>for status? This also appears more efficient than SNMP.
No, currently the poller does not poll the interfaces for status.
/rb
|