Previous 14.1 Specifics of measurement server types Next

14.1.8 QoS measurement servers

The QoS measurement server is an active and discoverable PVSR module. The measurement server uses the timeout and retries values specified for the equipment for the SNMP query of the equipment. Beside the basic attributes, the equipment has the following additional parameters (the code of the parameter is given in parenthesis; see Subsection 7.5.6 on Parameters of non-SNMP data collectors):

  • IP address (QOS EQ 1 IP): Single line text field, which cannot be seen by non-administrators. It contains the IP address of the equipment, similarly to normal SNMP equipment
  • Community (QOS EQ 2 COMM): Single line text field, which cannot be seen by non-administrators. The field contains the password of the equipment community, similarly to SNMP equipment, if it is not specified, then it is interpreted as public

The measurement server always uses SNMPv2c to query the equipment.

 

For QoS monitoring servers, the measurement definitions can use a predefined set of variables. Based on these, there are 32 default measurement definitions in the system, but naturally these can be modified freely. With the exception of sysUptime, all variables are table variables, i.e. in measurement definitions they are referenced typically as #VARIABLE.PORT# or #VARIABLE.IDENTIFIER#, but naturally their .PRE form can be also used. The table variables can be divided into two parts: configuration and measurement variables.

  • sysUptime: returns the sysUptime value of the system divided by 100, that is the uptime in seconds
  • configuration variables: Used for recognizing the configuration, therefore they occur in the description and condition OID fields:
    • police: The name of the police type QoS object
    • classmap: The name of the classmap type QoS object
    • matchStatement: The name of the matchStatement type QoS object
    • queuing: The name of the queuing type QoS object
    • randomDetect: The name of the randomDetect (RED) type QoS object
    • trafficShaping: The name of the trafficShaping type QoS object
    • randomDetectHadTransmit: It is 0 for the randomDetect object if the object with the given IP precedence or IP DSCP had no traffic so far, 1 otherwise
    • interface: The name of the interface
  • Measurement variables: The variables supported by the measurement server, for each of them the used unit is the same as in the SNMP MIB definition: pieces for packets, bytes for Byte, etc. The value of each corresponds to the object as described by the SNMP:

cbQosCMPrePolicyByte64, cbQosCMPostPolicyByte64, cbQosCMDropByte64, cbQosCMPrePolicyPkt64, cbQosCMNoBufDropPkt64, cbQosCMDropPkt64, cbQosMatchPrePolicyByte64, cbQosMatchPrePolicyPkt64, cbQosPoliceConformedByte64, cbQosPoliceExceededByte64, cbQosPoliceViolatedByte64, cbQosPoliceConformedPkt64, cbQosPoliceExceededPkt64, cbQosPoliceViolatedPkt64, cbQosQueueingDiscardByte64, cbQosQueueingDiscardPkt64, cbQosQueueingCurrentQDepth, cbQosQueueingMaxQDepth, cbQosTSStatsDelayedByte64, cbQosTSStatsDropByte64, cbQosTSStatsDelayedPkt64, cbQosTSStatsDropPkt64, cbQosTSStatsCurrentQSize, cbQosTSStatsActive, cbQosREDTransmitByte64, cbQosREDRandomDropByte64, cbQosREDTailDropByte64, cbQosREDTransmitPkt64, cbQosREDRandomDropPkt64, cbQosREDTailDropPkt64

ifInOctets / ifOutOctets

 

With the exception of the interfaces, the measurement server builds up the name of objects according to their location in the QoS tree hierarchy:

  • The short name of the interface
  • Space
  • “IN” for input and “OUT” for output
  • For each of the QoS object level starting from the root:
    • space-at sign-space (“ @ ”)
    • The name of the object on the given level. In case of policymap, classmap and match this is the name that occurs in the configuration; for queuing, trafficShaping and police it is the type (i.e. the queuing, trafficShaping and police strings); for randomDetect it is also the randomDetect string, but for that there is another level below with name between 0 and 63, which corresponds to the IP precedence of IP DSCP value

Example: Fa0/0 OUT @ COS-OUT-fa0/0 @ DSCP-OUT-D2 @ randomDetect @ 12, which broken down:

  • Fa0/0 interface
  • Output direction
  • COS-OUT-fa0/0 policymap
  • DSCP-OUT-D2 classmap
  • randomDetect
  • IP precedence or IP DSCP of value 12

For interfaces the name is the short name of the interface.

 

During discovery every such measurement object is created by the system with the appropriate index according to its configuration, which consists of the policymap and the SNMP index of the object, together with the IP precedence and IP DSCP values in the randomDetect case. This value is changed only during configuration, handled by the automatic discovery process that modifies the indices in the database. Since this modification matching the PVSR configuration can occur rather late, the measurement server supports quick reindexing, but only for SNMPv2c type queries. This means that if the equipment returns that no such variable exists with the given index during a measurement, then the system immediately performs an equipment configuration discovery, and checks to what value the index has been modified. This reindexing occurs no more frequently than the rediscoveries are executed.

 

The measurement server registers its measurements by default during the installation. Most of these coincide with the list of available variables: Actual depth, Conformed packets, Conformed traffic, Delayed packets, Delayed traffic, Discard packets, Discard traffic, Drop packets, Drop traffic, Exceeded packets, Exceeded traffic, Maximum depth, PostPolicy packets, PostPolicy traffic, PrePolicy packets, PrePolicy traffic, Random Drop packets, Random Drop traffic, Tail Drop packets, Tail Drop traffic, Transmit packets, Transmit traffic, Violated packets, Violated traffic, Uptime, Traffic.

 

In case of trafficShaping the value of the status variable (cbQosTSStatsActive) is set to 1 if active and to 0 if inactive. In case of randomDetection, the variables are installed in such a way that they are displayed only if there was some traffic for the given IP precedence or IP DSCP value, since there are 64 possible values according to the configuration.

 

As can be seen above, the QoS monitoring server provides UPTIME data, and displays them too as a measurement.

During installation the measurement server also creates a “Default QoS” equipment template, which can be used to create all variables with the exception of packet count variables. Furthermore, several chart templates are created as well:

  • QoS Classmap Drop traffic: the Drop traffic for the Classmap object, drawn with superposed bars
  • QoS Classmap PostPolicy traffic: the PostPolicy traffic measurements for the Classmap object, drawn with superposed bars
  • QoS Classmap PrePolicy traffic: the PrePolicy traffic measurements for the Classmap object, drawn with superposed bars
  • QoS Match PrePolicy traffic: the PrePolicy traffic measurements for the Match object, drawn with superposed bars
  • QoS Police traffic: the traffic measurements for the Police object, drawn superimposed in columns: Conformed, Exceeded and Violated traffic
  • QoS Queuing depth: the current depth measurements for the Queuing object, drawn superimposed in columns
  • QoS RED traffic: the traffic measurements for the RED object, first ordered by object then by type, drawn superimposed in columns: Transmit, Tail Drop and Random Drop traffic
  • QoS Trafficshaping traffic: the traffic measurements for the Trafficshaping object, first ordered by object then by type, drawn superimposed in columns: Delayed and Drop traffic

 

The collector specific pages mentioned in section 14.1.2 SNMP measurement servers can be also used for these equipments, except the Processes and the Disks pages.