Conference netcad::hub_mgnt

    
    Sam,
    
    	The NA means that the feature is not applicable or not supported.
        The COPIED counter relates to the fddimibMACCopiedCts MIB object
        and the TRANSMITTED relates to the MIB object fddimibMACTransmitCts 
        (both from RFC 1512). These MIBs are not supported on GIGAswitch/FDDI.
        The DIAL for utilization is not supported by HUBwatch at this time. 
    
        As for the interface counters being 0, if you could do an SNMP
        Trace and see if the GIGAswitch/FDDI is returning 0s, this would
        help isolate this problem. 
    
    Hope this helps,
    Bob
    

    Bob,
    
    From DECMCC I can look at the INTERFACE counters and see traffic  on
    all the ports, none of them returns 0.
    
    What mib variables did you want me to look at fro the bridge counters
    FRAMES IN and FRAMES OUT per second?
    
    Thanks,
    
    sam

    
    Sam,
    
    	The MIB variables concerned are:
    
           dot1dTpPortInFrames and dot1dTpPortOutFrames
    
        What HUBwatch does is to take a sample, gather some other MIB info
        and then take another sample. Based on a timestamp it calculates
        a per second value. If no frames entered or left the port between
        samples then the value(s) will be 0, even though the MIB variable(s)
        are not 0.
    
        The time bewteen samples may vary depending on network/system load,
        but should be within a few seconds.
    
    Regards,
    Bob

    
    Bob,
    
    I looked at the mib variables dot1dTpPortInFrames and
    dot1dTpPortOutFrames. They do change on all the port and there is
    traffic in and out. Yet HUBWATCH can't report it. on a couple of ports
    where I have VAXs connected I get some numbers for INFRAMES and
    OUTFRAMES but the numbers are very small and they do not reflect the
    actual frames comming in or going out, also, the FILTERED field is 0
    for those ports. The only port where I have correct information is the
    one that connects to a DECCON 500 (this is a B port, all other ports
    are M ports!)
    
    Thanks,
    
    sam

    
    Sam,
    
    	Thanks for the info.. One possibility that I can think of is that 
        when HUBwatch gets the mibs that it hits a lull in the traffic on
        that port. Since it takes a sample, waits a short while, then takes
        another sample, there is the possibility that little or no traffic
        was seen during the interval. What you might want to try is to 
        create some constant traffic on that port and then look at what
        HUBwatch shows.
    
    Bob

    Bob,
    
    I looked at the bridge port statistics for IN and OUT frames again and
    I do have traffic, and the filterd counter is 0 on ports where I have
    VAXs only makes sense now. I am not supposed to see any traffic going
    into a port where there is a single station unless that traffic is
    destined to that station.
    
    Thanks,
    
    sam