[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference azur::mcc

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

4643.0. "PA_FM, TCPIP interface Statistics, & CISCO" by GADWAL::WOESTEMEYER (Why??...Why not!!!) Fri Mar 05 1993 09:14

An interesting problem from a customer, and a vaild complaint.  
Symptoms started with interface statistics on an SNMP entity being 
wildly off on an intermittent basis.
Further investigation, hand calculating 'outbound packet rate' 
show the PA FM to be off, but for a interesting reason.  Attached
are counters from the interface in question, the hand calculation,
and what the PA FM reported.

BAD TEST
========

SNMP fcstce2 Interface 1
AT  4-MAR-1993 11:17:40 Counters

Examination of attributes shows:
                            ifOutErrors = 0
                          ifOutDiscards = 0
                        ifOutNUcastPkts = 703839728
                         ifOutUcastPkts = 4060468637
                            ifOutOctets = 601470324
                      ifInUnknownProtos = 0
                             ifInErrors = 407
                           ifInDiscards = 1
                         ifInNUcastPkts = 103306298
                          ifInUcastPkts = 128939509
                             ifInOctets = 3090704284
                    CounterCreationTime =  7-OCT-1992 19:04:39.67

SNMP fcstce2 Interface 1
AT  4-MAR-1993 11:18:38 Counters

Examination of attributes shows:
                            ifOutErrors = 0
                          ifOutDiscards = 0
                        ifOutNUcastPkts = 703842839
                         ifOutUcastPkts = 4060468122
                            ifOutOctets = 601800326
                      ifInUnknownProtos = 0
                             ifInErrors = 407
                           ifInDiscards = 1
                         ifInNUcastPkts = 103306684
                          ifInUcastPkts = 128940350
                             ifInOctets = 3090835697
                    CounterCreationTime =  7-OCT-1992 19:04:40.09

SNMP fcstce2 Interface 1
AT  4-MAR-1993 11:19:38 Counters

Examination of attributes shows:
                            ifOutErrors = 0
                          ifOutDiscards = 0
                        ifOutNUcastPkts = 703846222
                         ifOutUcastPkts = 4060467681
                            ifOutOctets = 602181218
                      ifInUnknownProtos = 0
                             ifInErrors = 407
                           ifInDiscards = 1
                         ifInNUcastPkts = 103307116
                          ifInUcastPkts = 128941381
                             ifInOctets = 3090983991
                    CounterCreationTime =  7-OCT-1992 19:04:40.00


SNMP fcstce2 Interface 1
AT  4-MAR-1993 11:18:37 Statistics

                   Outbound Packet Rate = 2.587188E+07 Packets/Sec

SNMP fcstce2 Interface 1
AT  4-MAR-1993 11:19:39 Statistics

                   Outbound Packet Rate = 2.361543E+07 Packets/Sec


Using the last pair of counter values to caluculate the difference:

ifOutuCastPkts    ifOutNUcastPkts     ifOutErrors    ifOutDiscard     Packets 
    -441        +      3383        +      0        +      0        =    2942

Packet Rate = packets/time = 49.03 packets/sec

Yet for the same interval the PA FM indicates:

                   Outbound Packet Rate = 2.361543E+07 Packets/Sec

The interesting part of this seems to be that the CISCO counters reach a
MAX value, then start decreamenting the counter value.  This would throw
of the value, as a negative counter value is produced, yet it should not
be off to the extent that the PA FM produces.

I would say that CISCO has has a problem, but at the same time so do we.
DECmcc is not following its own algorithms as documented in the PA manual 
appendix.

Any hints on this??
Steve Woestemeyer
CSC/CS - Network Support Group
T.RTitleUserPersonal
Name
DateLines
4643.1The best explaination I can come up with is ...MOLAR::ROBERTSKeith Roberts - Network Management ApplicationsTue Apr 20 1993 16:3329
  Steve,

  Without the *exact* data used by PA to calculate this statistics, I am
  only guessing.  I say the exact information because you must have recorded
  the data (historian) then played it back with 'show counters' and 'show
  statistics' .. I'd want to see the exact values to be certain .. Historical
  data is returned in multiple data samples, so I can't say for certain what
  PA processed.

  Anyway, the only thing I can think of is .. these counters are UNSIGNED,
  so there really isn't any negative values.  Thus, the LARGE positive
  values could explain the LARGE Packet Rate.

  I did try to work the numbers presented here .. but got even larger results.

  PA converts everything to Double real values and I thought that this would
  explain things.  If you do the math with Unsigned 32 bit integers the answer
  is the same as you got (due to wrapping).

  So .. I don't have a solid answer.  Just that Garbage-In == Garbage-Out.

  If an AM is going to return garbage to PA, you can't expect PA to turn it
  into Gold.  At the very least, I would have expected PA to return an
  Exception indicating that the counter had gone backwards .. 8{

  Does this seem reasonable ?

  /keith
  
4643.2Refered to Local officeGADWAL::WOESTEMEYERWhy??...Why not!!!Wed Apr 21 1993 09:306
    Keith,
    
    Thanks for your reply.  However, this was a customer problem/complaint
    and has been refered to his local office to assist with the resolution.
    
    Steve