Make your Cisco IPv4 Access Lists Easier and Safer
As anyone who has spent a lot of time with ACLs knows, that as they grow they become more complex to read, edit, and troubleshoot. There's a nice solution in Cisco IOS for this that works in 12.4(20)T and later. It allows you to create object groups that define subsets of IPs or services. This means that network administrators only need to be editing in a small area of access lists to add or delete hosts, blocks, or services. Since the lists are either all permit or deny and are already in the correct order in the Extended Access List, it greatly simplifies the task and reduces the chances of inserting the rule in the wrong place (such as at the end).
Let's look at the final ACL first. Note there are no IP addresses or ports defined in this access list, but it is an extended ACL.
ip access-list extended TrustedOutSelf
remark I am a list of lists
remark these are type 'network'
permit ip object-group Operations any
permit ip object-group Branch any
remark BGP group is a type 'service'
permit object-group BGPtcp179 object-group TunnelIPs any
The list above refers to the object definitions below:
object-group network Operations
description COS IPs
object-group service BGPtcp179
description match BGP tcp 179/179
tcp eq bgp
object-group network Branch
So the 'network' object groups are created similar to a standard access list, but without any permit or deny. The permit/deny and source/destination are defined in the actual extended ACL. Not shown here is also the ability to nest object groups of the same type.
Why would you want to nest? Imagine an object group called 'Company'. Inside of company you may want a few different lists to maintain such as 'Accounting', 'Executive', 'Operations'. This makes it very simple to add a network to the one of the subgroups. Any of the objects can be called by other object groupsso while 'Company' might hold 'Executive' and 'Operations', the 'OSS' group would contain 'Operations', but not 'Executive'.
The BGP entry is of type 'service' and can be used to match to/from ports and matches against either a network object or a standard host/network entry. Rather than
permit tcp host x.x.x.x eq 179 host y.y.y.y eq 179
permit object-group BGPtcp179 host x.x.x.x host y.y.y.y
This feature works with a simple extended ACL, IOS Firewall AND Zone Based Firewalls. A limit is still that you cannot remark individual lines or (as far as I know) edit the order of remark entries in the Extended ACL. You can put a description in the Object Group, however, and just the fact that they are in separate groups should help keep some useful command line documentation.
This sort of ruleset is compatible with Cisco Configuration Professional and you should be able to edit the rule names and remarks from that GUI tool or equivelant. I have not tried it with the express version that runs off the router.
I also cannot speak to any differences in performance, but I saw no difference on the 1812 and 2821 I tested on, IOS 15.1T and 12.4T respectively. They both appear to hit the CEF path with out any interference with GRE tunneling or qos pre-classify even with IPSEC DMVPN.
While ZBF does some inspection of IPv6 up to a certain layer, object-group does not appear to support IPv6, at least as of 15.1(4)T. IPv6 addresses or prefixes cannot be entered in the object-group and ipv6 access-list has no entry for 'object-group'. For more information, see Object Groups for ACLs.