[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.

To collect bulk statistics for a subset of all configured subinterfaces, you can define the subinterfaces using the following syntax:

Slot/Port[.subInterfaceId]

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.

The maximum number of interfaces for each type of interface and line module can differ. Bulk statistics can collect these statistics when you configure the slots with their respective interfaces to the corresponding maximum values. For information about maximum values see JUNOSe Release Notes, Appendix A, System Maximums.

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.


The name of the bulk statistics file that is transferred to the host when there is a collectorSequence attribute in the remote name is as follows:

fileName-z-mmddHHMM-s.sts

where:

Interface Strings

Bulk statistics provides interface strings as described in Table 24.



Table 24: Interface Strings 
Type of Interface
Common Description Format-Mode Disabled
Common Description Format-Mode Enabled

IP interfaces

IP

Ip

PPP interfaces

PPP

Ppp

DS0 interfaces

Ds0

Ds0

DS1 interfaces

SERIAL

Ds1

DS3 interfaces

SERIAL

Ds3

Frame Relay Major interfaces

FR

FrameRelayMajor

Ethernet interfaces

ENET

Ethernet

Sonet interfaces

SONET

Sonet

Sonet Path interfaces

SONET

SonetPath

ATM interfaces

ATM

Atm

ATM AAL5 interfaces

ATM

AtmAal5

ATM 1483 interfaces

ATM

Atm1483

Ft1 interfaces

SERIAL

Ft1

HDLC interfaces

HDLCIntf

HDLC

IpLoopback interfaces

Loopback

IpLoopback

IpVirtual interfaces

IpVirtual

IpVirtual

Frame Relay Sub interfaces

FR

FrameRelaySub

PppOE Major interfaces

PPPoE

PppoeMajor

PppOE Sub interfaces

PPPoE

PppoeSub

Bridged Ethernet

BRG-ET

BridgedEthernet

L2TP Tunnel

L2TP

L2tpTunnel

L2TP Session

L2TP

L2tpSession

PppLink interfaces

MLPPP

PppLink

HDLC interfaces

HDLCEncaps

Hdlc

L2TP Destinataion

L2TP

L2tpDestination

MPLS Major interfaces

MplsIfMajor

MplsMajor

MPLS Minor interfaces

MplsIfMinor

MplsMinor

Ppp Network interfaces

MLPPP

PppNetwork

Ethernet Sub interfaces

ENET

EthernetSub

MultiLink Frame Relay interfaces

MLFR

MultilinkFrameRelay

Ip Tunnel Interfaces

IP-TUNNEL

IpTunnel

Server Port Interfaces

ServerPort

ServerPort

Sonet VT interfaces

SONET

SonetVT

Vlan major interfaces

VLAN-MAJ

VlanMajor

Vlan sub interfaces

VLAN-SUB

VlanSub

Gtp interfaces

Gtp

Gtp

L2fTunnel interfaces

L2fTunnel

L2fTunnel

L2fSession interfaces

L2fSession

L2fSession

L2fDestination interfaces

L2fDestination

L2fDestination

IpSec Tunnel interfaces

IpSecTunnel

IpsecTunnel

Sg interfaces

SgInterface

SgInterface

MPLS L2 Shim interfaces

MplsL2Shim

MplsL2Shim

MPLS VC Sub interfaces

MplsL3Shim

MplsVcSub

LacGen interfaces

LacGen

LacGen

Bridge interfaces

BridgeIf

Bridge

IpSec Transport interfaces

IPSecTransportIf

IpsecTransport

IPv6 interfaces

IPv6If

Ipv6

IPv6 Tunnel interfaces

IPv6TunnelIf

Ipv6Tunnel

IPv6 loopback interfaces

IPv6LoopbackIf

Ipv6Loopback

OSI interfaces

Osi

Osi

LAG interfaces

Lag

Lag

Ip Tunnel MDT interfaces

IpTunnelMdt

IpTunnelMdt


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 Copying and Redirecting Files 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

Although 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.

NOTE: There are no explicit schema objects for the if-stack and system schemas.


Table 25 shows the type of data each schema retrieves.



Table 25: 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 26 presents igmp objects you can configure using the bulkstats schema subtree command.



Table 26: 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 27 presents if-stats objects you can configure using the bulkstats schema subtree command.

Table 27: Schema ifStats Objects  
Object
Definition

all

Configure IfStats schema for all stats

correlator

Configure IfStats schema for correlator

in-bcast-pkts

Configure IfStats schema for in-bcast-pkts

in-discards

Configure IfStats schema for in-discards

in-errors

Configure IfStats schema for in-errors

in-mcast-octets

Configure IfStats schema for in-mcast-octets

in-mcast-pkts

Configure IfStats schema for in-mcast-pkts

in-octets

Configure IfStats schema for in-octets

in-policed-octets

Configure IfStats schema for in-policed-octets

in-policed-pkts

Configure IfStats schema for in-policed-pkts

in-spoofed-pkts

Configure IfStats schema for in-spoofed-pkts

in-ucast-pkts

Configure IfStats schema for in-ucast-pkts

in-unknown-protos

Configure IfStats schema for in-unknown-protos

lower-interface

Configure IfStats schema for lower-interface

out-bcast-pkts

Configure IfStats schema for out-bcast-pkts

out-discards

Configure IfStats schema for out-discards

out-errors

Configure IfStats schema for out-errors

out-mcast-octets

Configure IfStats schema for out-mcast-octets

out-mcast-pkts

Configure IfStats schema for out-mcast-pkts

out-octets

Configure IfStats schema for out-octets

out-policed-octets

Configure IfStats schema for out-policed-octets

out-policed-pkts

Configure IfStats schema for out-policed-pkts

out-sched-octets

Configure IfStats schema for out-sched-octets

out-sched-pkts

Configure IfStats schema for out-sched-pkts

out-ucast-pkts

Configure IfStats schema for out-ucast-pkts

time-offset

Configure IfStats schema for time-offset


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

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.

policy Objects

Table 28 presents policy objects you can configure using the bulkstats schema subtree command.

Table 28: Schema Policy Objects  
Object
Definition

all

Configure policy schema for all statistics

green-bytes

Configure policy schema for green bytes

green-packets

Configure policy schema for green packets

red-bytes

Configure policy schema for red bytes

red-packets

Configure policy schema for red packets

upper-green-bytes

Configure policy schema for upper green bytes

upper-green-packets

Configure policy schema for upper green packets

upper-red-bytes

Configure policy schema for upper red bytes

upper-red-packets

Configure policy schema for upper red packets

upper-yellow-bytes

Configure policy schema for upper yellow bytes

upper-yellow-packets

Configure policy schema for upper yellow packets

yellow-bytes

Configure policy schema for yellow bytes

yellow-packets

Configure policy schema for yellow packets


bulkstats schema

bulkstats schema subtree

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 the 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. However, 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 value 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]