p any host ASA-Outside eq 5060 access-list Inbound permit tcp any host lab eq 8080 access-list Inbound permit udp any host meg eq domain access-list Inbound permit udp any host gto eq domain access-list Inbound permit tcp any host gto eq smtp access-list Inbound permit tcp any host meg eq smtp access-list Inbound permit tcp any host gto eq imap4 access-list Inbound permit tcp any host meg eq imap4 access-list Inbound permit esp any any access-list Inbound permit icmp any any unreachable Designing Access Lists access-list Inbound permit icmp any any time-exceeded access-list Inbound permit icmp any any echo-reply Notice that there is an object group already in use for CCIE-Rack. This may not seem necessary, as the same thing could be accomplished with the range keyword: access-list Inbound line 3 permit tcp any host lab range 2033 2050 In fact, as you'll see shortly, the object group is converted to this line anyway. Some people argue that if an object group takes up more lines of configuration than the number of lines it is translated into, it shouldn't be used. I disagree. I like the fact that I can add a description to an object group. Additionally, I can easily add a service to the object group at a later time without having to change any access lists. Here are the groups I've created based on the original access list. I've incorporated the services common to multiple servers into a group called Webserver-svcs. I've also cre- ated a group called Webservers that contains all of the web servers, another called Webserver-svcs-udp for UDP-based services like DNS, and one for ICMP packets called ICMP-Types. The ICMP-Types group is for return packets resulting from pings and traceroutes. The brackets in the description fields may look odd to you, but I like to add them to make the descriptions stand out: object-group service CCIE-Rack tcp description [< For Terminal Server Reverse Telnet > ] port-object range 2033 2050 object-group service Webserver-svcs tcp description Webserver TCP Services >] port-object eq WWW p