Classification and Marking 283
For all ACL types, after the named ACLs have been configured, they are temporarily placed
into an edit buffer within memory. As a result, if changes are made to an ACL, or a new
ACL is created, it is necessary to commit the changes before they can be implemented.
Committing the ACL copies the commands from the temporary edit buffer to the PFC in
hardware. Commits are performed with the following command, commit qos acl
{ACL_name | all}. Prior to committing any changes, it is possible to “roll back” any modifi-
cations without impacting the performance of currently operational ACLs. This eliminates
any ACL alterations or additions present within the temporary edit buffer. This is accom-
plished with rollback qos acl {ACL_name | all}. When modifying default ACL parameters,
it is not necessary to commit any changes. All changes take affect immediately. To verify
whether an ACL has been committed to hardware, or if there are outstanding “not
committed” changes, use show qos acl editbuffer. Refer to Example 8-23 in the “Classifi-
cation and Marking in Hybrid Mode” section for a demonstration on configuring and
applying QoS ACLs using Hybrid mode.
Class Maps and Policy Maps with Cisco IOS
With Cisco IOS, classification is performed utilizing Cisco’s MQC, as described in Chapter
5. The modular CLI enables the administrator to classify all interesting traffic by defining
named or numbered IOS ACLs and referencing them within class maps. Class maps are
then applied to policy maps. Policy maps identify the actions performed on traffic corre-
sponding to the predefined class maps, which are referenced within the policy map. Finally,
the defined policies are then applied to the appropriate port or interface with the service-
policy {input | output} command. For further information regarding the Cisco MQC, refer
to Chapter 5.
Cisco IOS supports the classification of IP, IPX, and MAC type traffic. With Cisco IOS,
both IP and IPX flows can be classified utilizing standard-numbered ACLs, extended-
numbered ACLS, or named ACLs. For MAC layer traffic, network data is classified using
named ACLs only.
NOTE With Release 12.1(1)E and later, it is possible to classify IPX and MAC layer traffic.
However, QoS support for IPX classification can be based on source network, and
optionally destination network and node parameters. Classifying IPX type traffic based on
socket numbers, source node, protocol, or service type is not supported.
When defining interesting traffic, you can configure multiple class maps. Potentially, one
class map can be specified for each type of inbound traffic for a designated receiving
interface. QoS on the Catalyst 6500 only supports one match statement when defining
classification criteria. You can match traffic based on Layer 3 precedence values by using
match ip, or administratively defined ACLs by using match access-group. All other class