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 ser- vice 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 created 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 port-object eq ssh port-object eq domain port-object eq smtp port-object eq imap4 Designing Access Lists object-group service Webserver-svcs-udp udp description [< Webserver UDP Services >] port-object eq domain object-group network Webservers description [< Webservers >] network-object host gto network-object host meg object-group icmp-type ICMP-Types description [< Allowed ICMP Types > ] icmp-object unreachable icmp-object time-exceeded icmp-object echo-reply Now that I've organized all the services and servers into groups, it's time to rewrite the access list to use them: access-list Inbound permit udp any object-group Webservers object-group Webserver- svcs-udp access-list Inbound permit tcp any object-group Webservers object-group Webserver- access-list Inbound permit tcp any host lab eq telnet acces