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