| 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 |
a customer is trying to setup its snmp application to monitor the state of the 32 ports of a decrepeater900tm when he issues at the same time 32 snmp "get-pdu" requests for the state of each port thru the dechub manager in-band interface relaying to the repeater agent , only half of them are satisfied with "reponse-PDU" : he uses the dechub in-band ip address and the "sub-community" for the repeater agent ; so half are lost in between the dechub manager and the repeater agent if he does the same directly to the repeater900 agent using the ip address of the repeater , all the requests are satisfied and none is lost this "losing" of snmp request , is , from the customer , due to the constraint of the "internal" management star , which is based on async-like 38,6Kbps "channels" and to lack of buffering ; he wonders if this a known restriction and if something is going to be done so to avoid losing snmp get-requests thanks for your answers PS : by the way , i advised him to use "get-next" request a-la-Hubwatch but he sticked to it that it should work its way
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 3462.1 | Yes, all products can lose management messages. | NETCAD::GALLAGHER | Tue Apr 16 1996 14:31 | 33 | |
>this "losing" of snmp request , is , from the customer , due to the >constraint of the "internal" management star , which is based on async-like >38,6Kbps "channels" and to lack of buffering ; > Your customer is correct. >he wonders if this a known restriction and if something is going to be done >so to avoid losing snmp get-requests Yes, it's a known restriction. And nope, nothing is going to be done about it. Your customer can also find the limit of the in-band channel to the repeater. The repeater can't handle an infinite number of requests thru it's in-band channel either. No device I'm aware of can handle wire-speed management requests. >PS : by the way , i advised him to use "get-next" request a-la-Hubwatch Good! It would be preferable to use a single getNext request to get this information. >but he sticked to it that it should work its way Maybe you should remind your customer that SNMP is carried over UDP - a connectionless datagram delivery service in which messages are expected to get lost occasionally. By the way, we don't hear must about customers writing custom applications for our hub products. Most are pretty happy with HUBwatch or SomthingVISN. Can you tell us a little more about what the customer is doing, and why? -Shawn | |||||
| 3462.2 | snmp "supervision" | TOOPCS::SELLES | Wed Apr 17 1996 12:49 | 11 | |
Shawn , the customer is writing its own "network and system" supervision software tailored to its own configuration ( mix of digital, timeplex , hp ... ) and in French, around SNMP packages ; they also use Hubwatch and so on for equipement configuration and troubleshooting thanks for your reply PJ | |||||