IP Accounting Access Control List (ACL)

The IP Accounting ACL identifies IP traffic that fails an IP access control list. This is a relevant security feature, because a sudden increase in traffic being blocked by an ACL can indicate a security attack in the network. Identifying IP source addresses that violate IP access control lists can help track down attackers. Alternatively, this mechanism can be used to identify when an attack is over, because an ACL is usually applied to block the attack. The data might also indicate that you should verify the network element configurations of the IP access control list. It is important to understand that the IP Accounting ACL does not account the amount of traffic that passes an individual ACL; therefore, it cannot be used for ACL optimization. However, the IP Accounting ACL can be used in conjunction with IP Accounting (Layer 3). For example, if ACLs are configured at a router, packets passing all ACLs are accounted by the IP Accounting (Layer 3) feature, and blocked traffic is collected via the IP Accounting ACL.

IP Accounting ACL is supported on ingress and egress traffic. There is no explicit command to recognize if the incoming traffic was blocked (the ip access-group ACL-number IN command, called ACL IN for simplicity) or the outgoing traffic was blocked (the ip access-group ACL-number OUT command, called ACL OUT). Nevertheless, because the blocking access list number is reported by the IP Accounting ACL, the direction can be identified in most cases.

Note

There are rare exceptions where the network element modifies ACL-related parts of a packet and these packet changes relate to ACLs. An example is if an ACL blocks certain precedence values and Policy Routing or Committed Access Rate (CAR) is active (where the precedence could be changed). In a case where the ACL IN statement passes the original packet, but the ACL OUT statement blocks the modified packet, you cannot measure if ACL IN or ACL OUT has blocked the packet.

IP Accounting ACL Principles

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

It provides information for identifying IP traffic that fails IP ACLs.
It supports standard and extended ACLs, but not named ACLS.
It supports ACLs applied as both ingress and egress.
It has the same database concept as IP Accounting (Layer 3): active and checkpoint databases.
If the packet is blocked by an ACL, only the IP Accounting ACL database is updated, not the IP Accounting (Layer 3) database.
Collection data is accessible via CLI and SNMP; however, the initial configuration is required via CLI. To retrieve the collection results via SNMP, you need to enable SNMP on the router first. When configuring SNMP, distinguish between read-only access and read-write access. For more details about SNMP configuration, see Chapter 4.
The MIB contains only 32-bit SNMP counters.

Supported Devices and IOS Versions

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

IP Accounting ACL was introduced in IOS 10.3.
It is supported on all routers, including the RSM and MSFC, except for the Cisco 12000.
It is supported on all physical interfaces and logical subinterfaces.
It is supported on all switching paths, except for autonomous switching, SSE switching, and dCEF. On the Cisco 7500 router, the IP Accounting ACL causes packets to be switched on the RSP instead of the VIP, which can cause performance degradation.

CLI Operations

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

router(config-if)# ip accounting access-violations
allows IP Accounting ACL to identify IP traffic that fails IP ACLs.
router(config)# ip accounting-threshold count
sets the maximum number of accounting entries to be created. The accounting threshold defines the maximum number of entries (source and destination address pairs) that are accumulated, with a default of 512 entries.
router# show ip accounting [checkpoint] access-violations
displays the active accounting or checkpoint database for ACL violations.
router# clear ip accounting
copies the content of the active database to the checkpoint database and afterwards clears the active database for both IP Accounting (Layer 3) and IP Accounting ACL.
router# clear ip accounting checkpoint
clears the checkpoint database.

Note

The IP Accounting ACL and IP Accounting (Layer 3) entries share the same databases. Consequently, there is no explicit command to erase the IP Accounting ACL entries independently of the IP Accounting (Layer 3) entries.

SNMP Operations

IP Accounting ACL uses the same MIB (OLD-CISCO-IP-MIB) as IP Accounting (Layer 3), which was described previously. IP Accounting ACL cannot be configured via SNMP, but a copy function from the active database to the checkpoint database is provided. First, you should copy the active database to the checkpoint database. Afterward, retrieve the data from the checkpoint database if you want to collect consistent accounting data across multiple network elements at the same time. IP Accounting ACL uses the same MIB tables as IP Accounting (Layer 3) but augments the information with the ACL Identifier—the ACL number that was violated by packets from source to destination. The ACL identifier is represented by actViolation in the lipAccountingTable table (the active database) and ckactViolation in the lipCkAccountingTable table (the checkpoint database). actCheckPoint copies the active database into the checkpoint database. For details about the MIB configuration, see the section "SNMP Operations" under "IP Accounting (Layer 3)."

Examples (CLI and SNMP)

The following example for IP Accounting ACL provides CLI and SNMP commands and extends them to display the entries of the IP Accounting (Layer 3) database as well. This helps you understand the close relationship between IP Accounting (Layer 3) and IP Accounting ACL.

Initial Configuration

Initially, the active and checkpoint databases are empty for both IP Accounting (Layer 3) and IP Accounting ACL. An SNMP query to the lipAccountingTable MIB table (active) and to the lipAcCkAccountingTable MIB table (checkpoint) confirms this:

router#show ip accounting output-packets
   Source        Destination       Packets        Bytes
   Accounting data age is 0

router#show ip accounting access-violations
   Source        Destination       Packets        Bytes       ACL
   Accounting data age is 0

router#show ip accounting checkpoint output-packets
   Source        Destination       Packets        Bytes
   Accounting data age is 0

router#show ip accounting checkpoint access-violations
   Source        Destination       Packets        Bytes       ACL
   Accounting data age is 0

For this example, IP Accounting ACL is configured in addition to IP Accounting (Layer 3); however, it can be configured independently of IP Accounting (Layer 3). An access list is inserted, which blocks the traffic coming from the source IP address 192.1.1.110 and going to the destination IP address 192.1.1.97:

router(config)#access-list 107 deny ip host 192.1.1.110 host 192.1.1.97
router(config)#access-list 107 permit ip any any
router(config)#int serial 0/0
router(config-if)#ip accounting output-packets
router(config-if)#ip accounting access-violations
router(config-if)#ip access-group 107 out
router(config-if)#exit

Collection Monitoring

Afterwards, the following results can be retrieved from the router:

router#show ip accounting access-violations
   Source        Destination         Packets         Bytes    ACL
 192.1.1.110     192.1.1.97             3             300     107
  Accounting data age is 3
router#show ip accounting output-packets
   Source        Destination         Packets         Bytes
 192.1.1.110     192.1.1.26            5              500
  Accounting data age is 3

Three packets from the traffic (192.1.1.110, 192.1.1.97) are blocked by access list 107 and therefore are accounted by the IP Accounting ACL. The traffic (192.1.1.110, 192.1.1.26) is accounted by IP Accounting (Layer 3).

For the SNMP example, the router is accessed with SNMP2c, a read community string public, and the net-snmp SNMP utility. The entries from both IP Accounting (Layer 3) and the IP Accounting ACL appear in the same MIB lipAccountingTable table. The only difference is that the entries from the IP Accounting ACL will have a non-null value in the actViolation MIB variable:

SERVER % snmpwalk -c public -v 2c <router> lipAccountingTable
actSrc.192.1.1.110.192.1.1.26 = IpAddress: 192.1.1.110
actSrc.192.1.1.110.192.1.1.97 = IpAddress: 192.1.1.110
actDst.192.1.1.110.192.1.1.26 = IpAddress: 192.1.1.26
actDst.192.1.1.110.192.1.1.97 = IpAddress: 192.1.1.97
actPkts.192.1.1.110.192.1.1.26 = INTEGER: 5
actPkts.192.1.1.110.192.1.1.97 = INTEGER: 3
actByts.192.1.1.110.192.1.1.26 = INTEGER: 500
actByts.192.1.1.110.192.1.1.97 = INTEGER: 300
actViolation.192.1.1.110.192.1.1.26 = INTEGER: 0
actViolation.192.1.1.110.192.1.1.97 = INTEGER: 107

Formatting the result in a different way, the distinction between show ip accounting output-packets and show ip accounting access-violations is clear.

The first entry (show ip accounting output-packets) is

actSrc.192.1.1.110.192.1.1.26 = IpAddress: 192.1.1.110
actDst.192.1.1.110.192.1.1.26 = IpAddress: 192.1.1.26
actPkts.192.1.1.110.192.1.1.26 = INTEGER: 5
actByts.192.1.1.110.192.1.1.26 = INTEGER: 500
actViolation.192.1.1.110.192.1.1.26 = INTEGER: 0

The second entry (show ip accounting access-violations) is

actSrc.192.1.1.110.192.1.1.97 = IpAddress: 192.1.1.110
actDst.192.1.1.110.192.1.1.97 = IpAddress: 192.1.1.97
actPkts.192.1.1.110.192.1.1.97 = INTEGER: 3
actByts.192.1.1.110.192.1.1.97 = INTEGER: 300
actViolation.192.1.1.110.192.1.1.97 = INTEGER: 107

Note

In this example, the first entry corresponds to show ip accounting output-packets and the second to show ip accounting access-violations. This correspondence is a coincidence in this case.

At this point, the checkpoint database is still empty. The clear ip accounting CLI command or the actCheckPoint MIB variable procedure copies the active database content to the checkpoint database. The two entries just discussed are now in the checkpoint database, and the active database is empty.

Code View:

router#show ip accounting checkpoint access-violations
   Source        Destination           Packets            Bytes    ACL
 192.1.1.110     192.1.1.97              3                 300     107
  Accounting data age is 10

router#show ip accounting checkpoint output-packets
   Source        Destination           Packets             Bytes
 192.1.1.110     192.1.1.26              5                  500
  Accounting data age is 10

router#show ip accounting access-violations
   Source        Destination           Packets            Bytes    ACL
  Accounting data age is 11

router#show ip accounting output-packets
   Source        Destination           Packets             Bytes
  Accounting data age is 11

SERVER % snmpwalk -c public -v 2c <router> lipcKAccountingTable
ckactSrc.192.1.1.110.192.1.1.26 = IpAddress: 192.1.1.110
ckactSrc.192.1.1.110.192.1.1.97 = IpAddress: 192.1.1.110
ckactDst.192.1.1.110.192.1.1.26 = IpAddress: 192.1.1.26
ckactDst.192.1.1.110.192.1.1.97 = IpAddress: 192.1.1.97
ckactPkts.192.1.1.110.192.1.1.26 = INTEGER: 5
ckactPkts.192.1.1.110.192.1.1.97 = INTEGER: 3
ckactByts.192.1.1.110.192.1.1.26 = INTEGER: 500
ckactByts.192.1.1.110.192.1.1.97 = INTEGER: 300
ckactViolation.192.1.1.110.192.1.1.26 = INTEGER: 0
ckactViolation.192.1.1.110.192.1.1.97 = INTEGER: 107