Conference netcad::hub_mgnt

607.0. "DECpacketprobe/PROBEwatch Limits/Errors??" by GUCCI::DMCCLOUD (Dennis McCloud - Eastern Client/Server Consultant) Wed Jan 12 1994 00:18

    I've installed PROBEwatch for ULTRIX and a DECpacketprobe at a customer
    site and encountered a few errors and possible limitations.  Can
    someone please comment about my perceptions of limitations found and
    take note of the errors and let me know if these are errors or my
    misunderstanding of the products.
    
    Perceived limitations:
    
    1)  A major limitation which I perceive is that after a power cycle of
    the DECpacketprobe the internal parameters are not retained except for
    the basics like IP address, netmask, and default router.  Other
    parameters like Domains for monitoring specific data and traps under
    the Watchdog setup are lost when the power is cycled in the probe.
    
    If I spend 30 minutes setting up the probe to collect information for
    me and notify me when errors occur or thresholds are reached then it
    would be highly desirable for these to be running even after I take a
    power hit on the network.
    
    I guess I could get out my trusty RMON MIB listing and figure out
    what objects to set to perform the setup operations using SNMP but that
    sort of defeats the benefit of the nice GUI.
    
    2) The RMON MIB has some nice features where you can filter on pattern
    matches anywhere in the packet.  Apparently there is no mechanism in
    the PROBEwatch application to setup filters on anything other than
    the standard Source Address, Destination Address, and the canned
    filters.  The format of the canned filters appears to be binary
    and I can not find a mechanism to create additional filters.
    
    3) There are occasions where it is desirable to capture the bad
    packets (fragments, CRC/Alignment, ...) because there are often
    clues to network problems in these frames.  I can find no way to tell
    the probe to capture bad packets.  I recently worked with the new
    NAT 450 probe and their application and this was one of the better
    features along with flexible filtering.
    
    4) Discovering new nodes is a pain.  If I place the probe on a
    network there is no apparent way (for non TCP/IP nodes) to generate the
    table of MAC address to name mapping.  Whichever vendor solves this
    problem will have a major selling feature.  The IP Discovery should
    also lookup the node name in the translation from address to name in
    the table automatically.
    
    ERRORS ?
    
    1) The initial screen on the ProbeWatch Domain View window contains
    invalid data.  The network which I am monitoring has average loads
    around 20-30%.  The initial windows shows small values for packets,
    octets, and utilization and after the first update (30 seconds)
    the values appear correct.  The Refresh widget causes the numbers
    to revert to the incorrect small numbers.
    
    2) The ProbeWatch Host Zoom (dvhz) application appears to lockup
    for a host with many conversations.  The network has 2 major servers
    which service hundreds of clients each.  The load on eack server is
    approximately 10-15% ethernet load.  When I attempt to zoom into
    one of the major servers the application locks up.  Other selections
    can be performed and I can zoom into other less busy hosts which the
    one window is locked and the probe appears to respond to these
    queries.
    
    3) MIB II support.  The DECpacketprobe appears to not support the
    complete MIB II and when I query with a GetNext to walk the
    ...mgmt.mib.interfaces branch I get a "response error, error status=5"
    after the ifOutQLen object.  Also it appears that MIB groups other
    than interfaces and system are not supported.
    
    4) While adding Domains, I apparently exceeded some internal resources
    in the DECpacketprobe.  The console on the probe gave an error:
    
    	"alloc_bucket: malloc failed"
    
    The error on the PROBEwatch application indicated that the Capture
    was not capability was not available when I attempted multiple
    Domain setups simultaneously. However, when I attempt to setup
    the same operations one at a time them worked.
    
    There appears to be a mismatch between what PROBEwatch thinks
    the resource limits on the probe and the actual hardware limits.  It
    would be nice if PROBEwatch had the ability to recognize when the user
    was attempting to exceed the resources of the probe and warn the user.
    
    Also, I could find where to modify the max_matrix, max_host, and
    max_captsize values from the console but don't know the implications of
    what raising these values will have on the overall table sizes
    elsewhere in the probe of how changing these values will effect
    performance.
    
    Thanks,
    
    	Dennis

    Another "error" encountered in my setup and use of the PROBEwatch
    application is concerned with the address to name translation.  The
    file user.def contains the addresses which are learned from the
    network.  When I modify this file using the GUI tool the changes
    show up in the file but the Capture application dues not appear to be
    using my modifications as the addresses still show up as DEC - 12 34 56
    instead of the real name that I added to user.def.  The application
    which shows confersations however shows the name as expected.
    
    Another problem with the "learn address" process is that I get multiple
    entries for IP addresses.  The first time I ran the learn address
    process it found a number of IP address entries and added them to the
    file.  I modify the name field to show the node name.  Now whenever
    I run the "learn addresses" functions I get a duplicate entry for the
    same IP address.