IP Accounting Precedence

The IP Accounting Precedence feature provides IP precedence-related traffic accounting information. The collection per interface consists of the total number of packets and bytes for each of the eight IP Precedence values, separately per direction (send and receive).

IP Accounting Precedence does not collect individual IP or MAC addresses, so it cannot be used to identify a specific user for usage-based billing, except in cases where the (sub)interface can serve as user identifier. There is no concept of a checkpoint database. Regarding QoS operations, it is important to distinguish between ingress and egress traffic on an interface:

For incoming packets on the interface, the accounting statistics are gathered before input CAR/Distributed CAR (DCAR) is performed on the packet. Therefore, if CAR/DCAR changes the precedence on the packet, it is counted based on the old precedence setting with the show interface precedence command.
For outgoing packets on the interface, the accounting statistics are gathered after output features such as DCAR, Distributed Weighted Random Early Detection (DWRED), and Distributed Weighted Fair Queuing (DWFQ) are performed on the packet.

IP Accounting Precedence Principles

The principles of IP Accounting Precedence can be summarized as follows:

Both inbound and outbound traffic is collected for eight IP precedence classes.
IP Accounting Precedence is supported on physical interfaces and subinterfaces.
There is no concept of a checkpoint database.
Individual IP or MAC addresses are not collected.
Collection data is accessible via CLI and SNMP. However, all configuration changes need to be done via CLI, because the CISCO-IP-STAT-MIB has no read-write parameters.
The MIB contains 32-bit and 64-bit SNMP counters.
To retrieve the collection results via SNMP, you have to enable SNMP on the network element first. When configuring SNMP, distinguish between read-only access and read-write access. For more details about SNMP configuration, see Chapter 4.

Supported Devices and IOS Versions

The following list defines the devices and Cisco IOS Software releases that support IP Accounting Precedence:

IP Accounting Precedence was introduced in IOS 11.1CC.
It is supported on CEF, dCEF, and optimum switching.
It supports Virtual Routing and Forwarding (VRF) interfaces but does not support tunnel interfaces.
It is supported on all routers, including the RSM and MSFC, except for the Cisco 12000.

CLI Operations

Notable commands for configuring, verifying, and troubleshooting IP Accounting Precedence are as follows:

router(config-if)# ip accounting precedence {input | output}, where:
- input performs accounting based on IP precedence on received packets.
- output performs accounting based on IP precedence on transmitted packets.
router# show interface [type number] precedence
displays information for all interfaces configured for IP Accounting Precedence. To display information for a single interface, enter the appropriate values for the type number arguments.
router# clear counters [interface-type interface-number]
clears interface counters. Because the IP Accounting Precedence entries are stored per interface, the clear counters command clears all IP Accounting Precedence entries. Note that this function is different from the IP Accounting MAC Address feature. The clear counters command does not delete the content of the cipPrecedenceTable MIB table. An analogy would be the clear counters command that clears the number of bytes and packets in the output of show interface while the SNMP counters in the ifTable are not cleared. Note also that the clear counters command is applicable globally for all interfaces or for a single interface.

SNMP Operations

IP Accounting Precedence can be configured only by using the CLI. Collection data can be read but not deleted via SNMP. It can be deleted using the CLI command clear counters. CISCO-IP-STAT-MIB supports 32-bit and 64-bit counters.

The IP Accounting Precedence part of the MIB consists of two tables with separate 32-bit counters and 64-bit counters:

cipPrecedenceTable— The 32-bit counter table for IP Accounting Precedence contains four variables:
- cipPrecedenceDirection is the object's data source (incoming or outgoing traffic).
- cipPrecedenceIpPrecedence is the IP precedence value this object is collected on, with a total of eight different precedence values (0 to 7).
- cipPrecedenceSwitchedPkts is the number of packets per IP precedence value (cipPrecedenceIpPrecedence).
- cipPrecedenceSwitchedBytes is the number of bytes per IP precedence value (cipPrecedenceIpPrecedence).
The indexes of the three tables are ifIndex, cipPrecedenceDirection, and cipPrecedenceIpPrecedence
cipPrecedenceXTable— The 64-bit counter extension table for IP Accounting Precedence contains two variables:
- cipPrecedenceHCSwitchedPkts is the number of packets per IP precedence value (cipPrecedenceIpPrecedence). This object is the 64-bit version of cipPrecedenceSwitchedPkts.
- cipPrecedenceHCSwitchedBytes is the number of bytes per IP precedence value (cipPrecedenceIpPrecedence). This object is the 64-bit version of cipPrecedenceSwitchedBytes.
The three table indexes are ifIndex, cipPrecedenceDirection, and cipPrecedenceIpPrecedence.

Examples (CLI and SNMP)

The following example provides a systematic introduction to configuring and monitoring IP Accounting Precedence and displays the results for both CLI and SNMP.

Initial Configuration

Initially, there are no IP Accounting Precedence entries.

In this configuration, both IP Accounting Precedence input and output are enabled:

router(config-if)#interface serial 0/0
router(config-if)#ip accounting precedence input
router(config-if)#ip accounting precedence output
router(config-if)#exit

Collection Monitoring

The entries populate:

router#show interfaces precedence
Serial0/0
  Input
           Precedence 6:  8 packets, 467 bytes
  Output
           Precedence 0:  6 packets, 504 bytes
           Precedence 6:  11 packets, 863 bytes

The corresponding MIB table shows the identical entries.

The router is accessed with SNMP2c (SNMP version 2c), the read community string is public, and the SNMP tool net-snmp is used:

Code View:

SERVER % snmpwalk -c public -v 2c <router> cipPrecedenceTable
cipPrecedenceSwitchedPkts.1.input.0 = Counter32: 0
cipPrecedenceSwitchedPkts.1.input.1 = Counter32: 0
cipPrecedenceSwitchedPkts.1.input.2 = Counter32: 0
cipPrecedenceSwitchedPkts.1.input.3 = Counter32: 0
cipPrecedenceSwitchedPkts.1.input.4 = Counter32: 0
cipPrecedenceSwitchedPkts.1.input.5 = Counter32: 0
cipPrecedenceSwitchedPkts.1.input.6 = Counter32: 8
cipPrecedenceSwitchedPkts.1.input.7 = Counter32: 0
cipPrecedenceSwitchedPkts.1.output.0 = Counter32: 6
cipPrecedenceSwitchedPkts.1.output.1 = Counter32: 0
cipPrecedenceSwitchedPkts.1.output.2 = Counter32: 0
cipPrecedenceSwitchedPkts.1.output.3 = Counter32: 0
cipPrecedenceSwitchedPkts.1.output.4 = Counter32: 0
cipPrecedenceSwitchedPkts.1.output.5 = Counter32: 0
cipPrecedenceSwitchedPkts.1.output.6 = Counter32: 11
cipPrecedenceSwitchedPkts.1.output.7 = Counter32: 0
cipPrecedenceSwitchedBytes.1.input.0 = Counter32: 0
cipPrecedenceSwitchedBytes.1.input.1 = Counter32: 0
cipPrecedenceSwitchedBytes.1.input.2 = Counter32: 0
cipPrecedenceSwitchedBytes.1.input.3 = Counter32: 0
cipPrecedenceSwitchedBytes.1.input.4 = Counter32: 0
cipPrecedenceSwitchedBytes.1.input.5 = Counter32: 0
cipPrecedenceSwitchedBytes.1.input.6 = Counter32: 467
cipPrecedenceSwitchedBytes.1.input.7 = Counter32: 0
cipPrecedenceSwitchedBytes.1.output.0 = Counter32: 504
cipPrecedenceSwitchedBytes.1.output.1 = Counter32: 0
cipPrecedenceSwitchedBytes.1.output.2 = Counter32: 0
cipPrecedenceSwitchedBytes.1.output.3 = Counter32: 0
cipPrecedenceSwitchedBytes.1.output.4 = Counter32: 0
cipPrecedenceSwitchedBytes.1.output.5 = Counter32: 0
cipPrecedenceSwitchedBytes.1.output.6 = Counter32: 863
cipPrecedenceSwitchedBytes.1.output.7 = Counter32: 0

The table indexes are as follows:

ifIndex

In this case it is 1, which represents serial 0/0:

Router #show snmp mib ifmib ifIndex serial 0/0
          Interface = Serial0/0, ifIndex = 1

cipPrecedenceDirection: input or output
cipPrecedenceIpPrecedence: a value from 0 to 7

For example, the entry (Input, Precedence 6, 8 packets, 467 bytes) is represented in the SNMP table by

cipPrecedenceSwitchedBytes.1.input.6 = Counter32: 467

In a situation where the counters are small, polling cipPrecedenceXTable, which contains the high-capacity counter counter64, returns the same results as polling cipPrecedenceTable.

Finally, the IP Accounting Precedence counters can be cleared, either specifically for the interface or globally for all interfaces:

router(config)#clear counters [serial 0/0]
router#show interfaces precedence
Serial0/0
  Input
           none
        Output
           none

Note

The clear counters affects the IP Accounting Precedence counters and the IP Accounting MAC Address counters. This could be considered a limitation when enabled on the same interface.