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 |
I'm trying to find the source of the following error counters from the Hubwatch bridge port detail window: - Framing(frames): - Bad Received(frames): - Receive Error(frames): - Transmit erro(frames): - Carrier Loss: - Collision Limit Exceeded: I assume the above error counters should be gettable via the following MIB variables: Bridge port error counters defined in "sys$library:hubwatch_mib_master.dat": db90IfEthCarrierLoss 1.3.6.1.4.1.36.2.18.10.5.3.5.2.1.3 Counter db90IfEthCollisionLimitExceeded 1.3.6.1.4.1.36.2.18.10.5.3.5.2.1.4 Counter db90IfEthFramingError 1.3.6.1.4.1.36.2.18.10.5.3.5.2.1.2 Counter dbIfBadFramesReceived 1.3.6.1.4.1.36.2.18.10.5.2.1.1.2 Counter dbIfTransmitFramesError 1.3.6.1.4.1.36.2.18.10.5.2.1.1.3 Counter I have used DECmcc as well as a simple MIB query tool to read the above variables directly. The following variables are readable: db90IfEthCarrierLoss db90IfEthCollisionLimitExceeded The following variables are NOT gettable: db90IfEthFramingError dbIfBadFramesReceived dbIfTransmitFramesError I assume that the DECbridge 90 console interface is able to display all error counters which are shown in the Hubwatch bridge port detail window. I assume that the following 1:1 correspondance exists: db90IfEthCarrierLoss == Unsent, carrier check failed db90IfEthCollisionLimitExceeded == Unsent, excessive collisions: The DECbridge 90 Console interface command "show port 1/2" shows the following bridge port error counters: - Received frame too long: - Unsent, excessive collisions: - Unsent, carrier check failed: - Unsent, lifetime exceeded: Because I cannot see any counters like db90IfEthFramingError, dbIfBadFramesReceived or dbIfTransmitFramesError, I assume that the Hubwatch bridge port detail windows show wrong error counter information. I know a customer which would like to use these error counters for LAN statistics, but if they are inaccurate/not valid... Can sombody from Hubwatch Engineering correct/confirm the above statements. Any help will be appreciated Roland
T.R | Title | User | Personal Name | Date | Lines |
---|---|---|---|---|---|
444.1 | confirmed | SLINK::HOOD | I'd rather be surfing | Fri Oct 22 1993 12:51 | 10 |
We found during the HUBwatch V2.0 development that what is reported in SNMP for many of the DECbridge 90 counters is wrong. I QAR'd some of the errors we saw, but there ain't nobody looking at it, so I'm not holding my breath. On the other hand, what the bridge reports thru RBMS is correct, so either DECelms or the ELM module from DECmcc can get the correct counters. Tom Hood | |||||
444.2 | change "0" with "NA" | ZUR01::FUEGLISTER | Roland Fueglister, 760-2498 | Fri Oct 29 1993 09:10 | 20 |
Thank you for your immediate reply /We found during the HUBwatch V2.0 development that what is reported in SNMP /for many of the DECbridge 90 counters is wrong. /I QAR'd some of the errors we saw, but there ain't nobody looking at it, so /I'm not holding my breath. Why does Hubwatch V2.0 displaying counters with a value of zero which don't exist or are not readable via SNMP. Every normal person is trusting in these counters and the attached LAN segment should be ok, if the displayed value is "0". I would like to have displayed something like NA(not applicable) for nonexisting counters. /On the other hand, what the bridge reports thru RBMS is correct, so either /DECelms or the ELM module from DECmcc can get the correct counters. This suggestion is not appropriate for my customer; he has a routed network. Roland |