| Title: | DECmcc user notes file. Does not replace IPMT. |
| Notice: | Use IPMT for problems. Newsletter location in note 6187 |
| Moderator: | TAEC::BEROUD |
| Created: | Mon Aug 21 1989 |
| Last Modified: | Wed Jun 04 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 6497 |
| Total number of notes: | 27359 |
A customer has posed a couple of interesting questions on the TCPIP SINK counters. I have duplicated his question/problem and do not understand it either. After enabling 3 mcc occurs rules on 1 snmp entity, the number of "Current Clients" was one, one entity one client. Created and enabled another snmp occurs rule on a different entity, Current Clients now 2. Setup an event notification on a 3rd snmp entity, current clients now 3. So far so good for each entity an occurs rule or notification request is created/enabled for we have a 1 to 1 correspondence of "Current Clients". Now for the problem/question. When traps start to be receive from these entities, the Current Client count changes. In my case from 3 to eight during the testing I did. Why? What is the "Current Client" counter? His second question deals with the count of traps received. He has notification logging enabled. The Sink event counters do not agree with the number of events in the notification log file. In my testing the number of notifications in the log file are 13, and the number of 'total traps received' is 10. All the events in the log file are SNMP events, and the testing was synced such that the log file was empty when the testing was started. Why don't the numbers agree? Thanks for any input, Steve Woestemeyer CSC/CS - Network Support Team
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 5894.1 | MOLAR::YAHEY::BOSE | Fri Mar 04 1994 15:44 | 21 | ||
The Current Client count keeps track of how many threads have requested events from the sink. Once the count goes down to zero the sink goes down. When traps are coming in, the situation is very dynamic. As a client request is serviced, the count goes down, but since the client posts the request again, the count goes up. Depending on the timing, you will see different numbers show up as client count when traps are being received. >>the number of events in the notification log file. In my testing the >>number of notifications in the log file are 13, and the number of 'total >>traps received' is 10. All the events in the log file are SNMP events, This can be easily explained. If you have two alarms written against the same entity, one SNMP trap received by the sink will cause both the alarms to trigger. Thus you will see two notifications for one SNMP trap. This explains why you may see more notifications than the count of SNMP traps received. Rahul. | |||||