[Contents] [Prev] [Next] [Index] [Report an Error] [No Frames]


Collecting Bulk Statistics

The router offers an efficient data collection and transfer facility for accounting applications. The E-series router SNMP MIBs extend the accounting data collection mechanism defined in the Accounting-Control-MIB (RFC 2513) to include support for connectionless networks.

Service providers need reasonably accurate data about customers' use of networks. This data is used for billing customers and must be available at a customer's request. Accounting applications based on SNMP polling models consume significant network bandwidth because they poll large volumes of data frequently.

Unfortunately, SNMP is not well suited for gathering large volumes of data, especially over short time intervals. It is inadequate for use by accounting applications because:

The router avoids the need for continuous polling of SNMP statistics by using applications known as collectors to retrieve data. You can configure up to six collectors. The router sends collected statistics through FTP to assigned hosts, known as receivers. You must assign a primary receiver to each collector, and you can assign a secondary receiver for redundancy.


NOTE: The basic-encoding-rules (BER)-encoding choice is not supported.

You can collect interface bulk statistics based on sets of virtual router groups. If sets of virtual router groups generally correspond to ISPs, you can then forward the relevant data to a particular ISP.

To configure a collector to include data from a specific list of virtual routers, you must first configure a collector and then associate a router set with it. A collector can have up to 64 virtual routers associated with it.

Per virtual router collection is supported on the if-stats and igmp schemas. It is supported on all interface types supported by BulkStats. Collectors modified to use per virtual router collection or configured after a collector has started have a time delay (up to the configured time in seconds) until an active collector starts again.

NOTE: Define all interface types before you map a collector to the if-stats schema to ensure that you display statistics for all configured interfaces in the first interval.


Understanding Counter Discontinuity

Interface counter discontinuity can occur when a counter wraps or after a line module is reloaded or reset. If one of these actions occurs, applications that utilize the counters in expressions or calculations generate erroneous values and misleading graphs.

Because counters are 64 bits long, the possibility of a counter's wrapping naturally would occur so infrequently (for example, in many hundreds of years) that this scenario is not recognized as an issue.

Counter discontinuity does occur, however, when you reload or reset a line module. To indicate reloading or resetting, bulk statistics files contain a record similar to the following:

{Controller down slot 3, TUE OCT 29 2004 14:25:10.370 UTC}

This record provides a mechanism by which applications can detect discontinuity events. To take advantage of this detection capability, the bulk statistics parsing entity should use the record to terminate expression or formula calculations for the indicated slot and to establish a new baseline.

Configuring Collectors and Receivers

To configure the router to collect statistics:

  1. Add names to the FTP host table for the primary and secondary (optional) receivers.

See Using the copy Command in Chapter 5, Managing the System, for information about adding names to the host table.

  1. Specify the type of interface on which you want to collect statistics.
  2. host1(config)#bulkstats interface-type ppp collector 2
    
    
    
  3. Specify the parameters for the receivers.
  4. host1(config)#bulkstats receiver 1 remote-name js:/ftptest/bulk%s%s.sts 
    sysName sysUpTime
    
    
    
  5. Assign the data collector.
  6. host1(config)#bulkstats collector 2
    
    
    
  7. Specify the method for data collection.
  8. host1(config)#bulkstats collector 2 collect-mode auto
    
    
    
  9. Assign the primary receiver.
  10. host1(config)#bulkstats collector 2 primary-receiver 1
    
    
    
  11. (Optional) Assign the secondary receiver.
  12. host1(config)#bulkstats collector 2 secondary-receiver 5
    
    
    
  13. (Optional) Specify the time for which the system transfers data.
  14. host1(config)#bulkstats collector 2 interval 1000
    
    
    
  15. (Optional) Set the maximum size of the bulk statistics file.
  16. host1(config)#bulkstats collector 2 max-size 20480
    
    
    
  17. (Optional) Add descriptive information to the bulk statistics file.
  18. host1(config)#bulkstats collector 2 description customer xyz
    
    
    
  19. (Optional) Set the encoding scheme of the ifDescr and ifName objects.
  20. host1(config)#bulkstats interfaces description-format common 
    
    
    
  21. (Optional) Set the system to retrieve bulk statistics once only.
  22. host1(config)#bulkstats collector 2 single-interval
    
    
    
  23. (Optional) Configure bulk statistics traps.
  24. host1(config)#bulkstats traps nearly-full
    
    
    
  25. (Optional) Collect bulk statistics per virtual router.
  26. host1(config)#bulkstats virtual-router-group collector 2 routerISP3
    
    
    

    NOTE: The bulk statistics feature supports generating files on a per interface basis.

bulkstats collector

bulkstats collector collect-mode

bulkstats collector description

bulkstats collector interval

bulkstats collector max-size

bulkstats collector primary-receiver

bulkstats collector secondary-receiver

bulkstats collector single-interval

bulkstats interfaces description-format common

bulkstats interface-type

bulkstats receiver remote-name

bulkstats traps

bulkstats virtual-router-group

Deleting All Bulkstats Configurations

Though individual bulkstats commands allow you to disable or delete a specific bulkstats parameter, the CLI also allows you to remove all bulkstats configurations from the router at one time.

no bulkstats

Monitoring Collection Statistics

To view the parameters the router uses to collect statistics, use the following show bulkstats commands.

To include or exclude lines of output based on a text string that you specify, use the output filtering feature for show commands. For details, see Chapter 2, Command-Line Interface.

show bulkstats

show bulkstats collector description

show bulkstats collector interval

show bulkstats collector max-size

show bulkstats collector transfer-mode

show bulkstats interface-type

show bulkstats receiver

show bulkstats statistics

show bulkstats traps

show bulkstats virtual-routers

Configuring Schemas

You can also set a management schema for bulk statistics. A schema is a group of attributes or counters that provide an efficient way to retrieve specific types of information about the router. The bulk statistics application supports five schema configurations: igmp, if-stack, if-stats, policy, and system.

Table 23 shows the type of data each schema retrieves.



Table 23: Data Retrieved According to Schema  
Schema
Retrieves . . .

igmp

Statistics associated with various IGMP components.

if-stack

The interface and interface column configuration. It is a complete retrieval of the ifStackTable, and using it can dramatically reduce the time to discover the configured interfaces and their stacking relationship on a router.

if-stats

Usage data on sets of interface types. The interface usage data is the ifTable/ifXTable counters. Note that the ifXTable supports 64-bit counters and the data written into the bulk statistics file supports the 64-bit counters.

policy

Statistics associated with a specified policy, a policy type, or traffic tagged by a policy with a color tag.

system

Global system and per-module statistics and information. The global system statistics retrieved are the sysUpTime and nvsUtilPct. The per-module statistics and information retrieved include the intPhysicalDesc, the cpuUtilPct, and the memUtilPct.


igmp Objects

Table 24 presents igmp objects you can configure using the bulkstats schema subtree command.



Table 24: Schema igmp Objects  
Object
Definition

all

Configure IGMP schema for all attributes

dest-address

Configure IGMP schema for destination address

igmp-cmd

Configure IGMP schema for IGMP command

lower-interface

Configure IGMP schema for lower interface

multicast-group

Configure IGMP schema for multicast group

router-index

Configure IGMP schema for router index

source-address

Configure IGMP schema for source address

time-stamp

Configure IGMP schema for time stamp


if-stats Objects

Table 25 presents if-stats objects you can configure using the bulkstats schema subtree command.



Table 25: Schema ifStats Objects  
Object
Definition

usdAcctngifInBroadcastPkts

Broadcast packets received

usdAcctngIfInOctets

Octets received; support 64-bit counters

usdAcctngIfInUcastPkts

Unicast packets received

usdAcctngIfInDiscards

Packets received and discarded

usdAcctngIfInErrors

Packets received with errors

usdAcctngifInMulticastPkts

Multicast packets received

usdAcctngIfInUnknownProtos

Packets received with unknown protocols

usdAcctngifOutBroadcastPkts

Broadcast packets sent

usdAcctngIfOutOctets

Octets sent; support 64-bit counters

usdAcctngIfOutUcastPkts

Unicast packets sent

usdAcctngIfOutDiscards

Packets sent and discarded

usdAcctngIfOutErrors

Packets sent with errors

usdAcctngifOutMulticastPkts

Multicast packets sent

usdAcctngIfCorrelator

Customer correlation:

  • FR = DLCI
  • ATM = VPI, VCI
  • IP = RouterName
  • Everything else = not used

usdAcctngIfInPolicedOctets

Octets dropped due to ingress policy; support 64-bit counters.

usdAcctngIfInPolicedPkts

Packets dropped due to ingress policy

usdAcctngIfInSpoofedPkts

Packets dropped due to invalid source address

usdAcctngIfOutPolicedOctets

Octets dropped due to egress policy; support 64-bit counters

usdAcctngIfOutSpoofedPkts

Packets dropped due to invalid source address

usdAcctngIfOutSchedulerDropPks

Scheduler packets dropped

usdAcctngIfOutSchedulerOctets

Scheduler octets dropped

usdAcctngIfLowerInterface

The ifIndex of the lower interface

usdAcctngIfInMulticastOctets

Multicast octets received

usdAcctngIfOutMulticastOctets

Multicast octets sent



NOTE: All the schema if-stats objects in Table 25 apply to both layer 2 and layer 3 interfaces, except usdAcctngSpoofedPkts, which is specific to layer 3.



NOTE: Defining all interface types before you map a collector to the if-stats schema ensures that you display statistics for all configured interfaces in the first interval.


You can get more accurate rate statistics by using the time-offset parameter. To use this parameter you must navigate to the if-stats subtreelist. The time-offset parameter is included in each bulk statistics interface record and is the offset from the master interval at which the record was collected.

bulkstats schema

bulkstats schema subtree

bulkstats schema subtree policy

Monitoring Schema Statistics

You are able to display your configuration and monitor the data generated by schemas.

show bulkstats schema

Configuring Interface Numbering Mode

E-series routers support RFC 1213 interface numbering mode on bulkstats. This mode is contrasted with the default interface numbering mode.

The RFC 1213 numbering mode is based on a 32-bit contiguous integer value starting from 1 and ranging to ifNumber. This mode differs from the default interface numbering mode, which encodes a type field in the upper 8-bits of a 32 bit integer. The use of the upper 8-bits creates large gaps in the ifIndex numbering scheme.

There is no re-use of ifIndex values in RFC 1213 mode, whereas in the default interface numbering mode, ifIndex values can be re-used. In the default interface numbering mode, re-use of ifIndex values across reboots is permitted and is basically known as ifIndex re-numbering.

In RFC 1213 mode, however, the interface numbers are not re-used during a single initialization of the device and renumbering of ifIndexes occurs after a system reboot. In the default interface numbering mode, ifIndexes are persistent across system reboots and can be reused without resetting the value of sysUpTime.

In RFC 1213 mode, two parameters control the size of the ifIndex range and the total number of interfaces in the standard interface tables—maxIfIndex and maxIfNumber. There is no such control in the default interface numbering mode.

In RFC 1213 mode, interface creations should not result in gaps in the ifIndex range. A gap that results from the deletion of an interface is acceptable because it is handled by older network management applications. The gaps are eliminated after the router is rebooted. Whereas, in the default interface numbering mode, large gaps occur from the creation of interfaces due to the use of the upper 8 bits of the ifIndex for interface type encoding. Gaps are not eliminated after a system reboot.

In RFC 1213 mode, small gaps can occur in the creation of IP interfaces when virtual routers are used. These gaps are minimized but not eliminated when the router is rebooted.

Rather than seeing an ifIndex of 1 and 10066329, for example, a management client would see ifIndex values of 1 and 2.

bulkstats interfaces rfc1213


[Contents] [Prev] [Next] [Index] [Report an Error] [No Frames]