In which configuration mode is match access-group name [acl] used?

The match access-group name [acl] command is entered in Class-map Config mode on Cisco IOS devices.

QoSClass-map Config

match access-group name [acl]

Matches packets against a named or numbered access list to classify traffic for QoS policy application.

Definition: match access-group name [acl] is a Cisco IOS class-map config command. Matches packets against a named or numbered access list to classify traffic for QoS policy application.

Overview

The `match access-group name [acl]` command is used in Cisco IOS Quality of Service (QoS) class-map configuration mode to classify packets based on a named or numbered access control list (ACL). This command is fundamental for implementing policy-based QoS, where traffic must be identified and grouped into classes before applying actions like marking, policing, shaping, or queuing. The command references an existing ACL (standard, extended, or named) to match packet headers—typically source/destination IP, protocol, or port numbers.

This allows granular traffic classification, such as separating voice, video, and data flows. The command is essential for network engineers designing QoS policies to meet Service Level Agreements (SLAs) or optimize bandwidth utilization. It fits into the broader QoS workflow: first define ACLs to specify interesting traffic, then create class maps that use `match access-group` to group that traffic, and finally attach a policy map that applies actions to each class.

Alternatives include `match protocol` (for NBAR-based classification) or `match ip dscp` (for marking-based classification), but `match access-group` is preferred when ACL-based granularity is needed, especially for legacy or simple deployments. Important IOS behavior: the ACL must exist before referencing it in the class map; otherwise, the command is rejected. The command affects the running configuration immediately and requires privileged EXEC mode (enable) to enter global configuration.

The class-map configuration mode is accessed via `class-map [match-all | match-any] [class-name]`. The `match-all` keyword (default) requires all match statements to be true; `match-any` requires at least one. This command is widely supported in IOS 12.x and later, including IOS-XE, but not in NX-OS (which uses `match access-group` with different syntax).

Understanding this command is critical for CCNA and CCNP candidates as it appears in QoS configuration scenarios and troubleshooting.

Syntax·Class-map Config

match access-group name [acl]

When to Use This Command

Classify HTTP traffic from a specific subnet for bandwidth prioritization
Match VoIP traffic (e.g., RTP) based on ACL to apply low-latency queuing
Identify and mark traffic from a specific host for traffic policing
Classify management traffic (e.g., SSH) to ensure it is not dropped during congestion

Parameters

Parameter	Syntax	Required	Description
acl	ACL name or number (e.g., MY_ACL, 100)	Required	Specifies the access control list (ACL) to use for matching packets. Can be a standard ACL (1-99, 1300-1999), extended ACL (100-199, 2000-2699), or a named ACL. The ACL must already be configured. Common mistake: using an ACL that does not exist or has no permit entries, resulting in no matches.

Command Examples

Match HTTP traffic from subnet 192.168.1.0/24

match access-group name HTTP-ACL

Router(config-cmap)# match access-group name HTTP-ACL
Router(config-cmap)#

The command is entered without any output confirmation. The ACL named HTTP-ACL must be pre-configured to permit HTTP traffic from 192.168.1.0/24. The class-map will then match packets that are permitted by that ACL.

Match VoIP traffic using a numbered ACL

match access-group 101

Router(config-cmap)# match access-group 101
Router(config-cmap)#

This matches packets that are permitted by access-list 101. Typically, ACL 101 would permit UDP traffic on ports 16384-32767 (RTP range) from VoIP phones. No output is shown upon successful configuration.

Understanding the Output

The 'match access-group name [acl]' command does not produce any output when entered correctly; it simply configures the class-map. To verify the match, use 'show class-map [class-map-name]' which will display the match criteria, including the referenced ACL. The ACL itself must be verified with 'show access-lists [acl-name]' to ensure it contains the desired permit statements.

A common pitfall is forgetting that the ACL must permit the traffic; deny statements will not match. Also, the ACL must be configured before referencing it in the class-map, otherwise the command will be rejected.

Configuration Scenarios

Classify VoIP traffic using a named extended ACL

A network administrator needs to prioritize voice traffic (RTP) over data traffic on a WAN link. They will classify traffic using an ACL that matches UDP ports 16384-32767 (typical RTP range).

Topology

R1(Gi0/0)---192.168.1.0/30---(Gi0/0)R2

Steps

1.Step 1: Enter global configuration mode: R1# configure terminal
2.Step 2: Create an extended named ACL to match VoIP RTP traffic: R1(config)# ip access-list extended VOIP_ACL
3.Step 3: Add a permit statement for UDP traffic from any source to any destination with destination port range 16384-32767: R1(config-ext-nacl)# permit udp any any range 16384 32767
4.Step 4: Exit ACL configuration: R1(config-ext-nacl)# exit
5.Step 5: Create a class map that matches this ACL: R1(config)# class-map match-all VOIP_CLASS
6.Step 6: Apply the match access-group command: R1(config-cmap)# match access-group name VOIP_ACL
7.Step 7: Exit class-map configuration: R1(config-cmap)# exit
8.Step 8: Create a policy map to mark VoIP traffic with DSCP EF: R1(config)# policy-map QOS_POLICY
9.Step 9: Define the class and set DSCP: R1(config-pmap)# class VOIP_CLASS; R1(config-pmap-c)# set ip dscp ef
10.Step 10: Apply the policy map to the interface: R1(config)# interface gigabitethernet 0/0; R1(config-if)# service-policy output QOS_POLICY

Configuration

!
ip access-list extended VOIP_ACL
 permit udp any any range 16384 32767
!
class-map match-all VOIP_CLASS
 match access-group name VOIP_ACL
!
policy-map QOS_POLICY
 class VOIP_CLASS
  set ip dscp ef
!
interface gigabitethernet 0/0
 service-policy output QOS_POLICY
!

Verify: Use `show class-map VOIP_CLASS` to verify the class map configuration. Use `show policy-map interface gigabitethernet 0/0` to see packet matches and DSCP marking.

Watch out: The ACL must have at least one permit statement; otherwise, no traffic will match. Also, ensure the ACL is applied to the correct direction (input vs output) in the service policy; the match access-group command itself is directionless, but the service-policy direction matters.

Classify web traffic using a numbered extended ACL

An engineer wants to shape HTTP traffic (TCP port 80) to limit bandwidth usage on a slow link. They will classify traffic using a numbered extended ACL.

Topology

R2(Gi0/1)---10.0.0.0/30---(Gi0/1)R1

Steps

1.Step 1: Enter global configuration mode: R2# configure terminal
2.Step 2: Create extended ACL 100 to match HTTP traffic: R2(config)# access-list 100 permit tcp any any eq 80
3.Step 3: Create a class map: R2(config)# class-map match-all HTTP_CLASS
4.Step 4: Apply the match access-group command: R2(config-cmap)# match access-group 100
5.Step 5: Exit class-map configuration: R2(config-cmap)# exit
6.Step 6: Create a policy map to shape traffic: R2(config)# policy-map SHAPE_POLICY
7.Step 7: Define the class and apply shaping: R2(config-pmap)# class HTTP_CLASS; R2(config-pmap-c)# shape average 1000000
8.Step 8: Apply the policy map to the interface: R2(config)# interface gigabitethernet 0/1; R2(config-if)# service-policy output SHAPE_POLICY

Configuration

!
access-list 100 permit tcp any any eq 80
!
class-map match-all HTTP_CLASS
 match access-group 100
!
policy-map SHAPE_POLICY
 class HTTP_CLASS
  shape average 1000000
!
interface gigabitethernet 0/1
 service-policy output SHAPE_POLICY
!

Verify: Use `show access-list 100` to verify the ACL. Use `show policy-map interface gigabitethernet 0/1` to see traffic classification and shaping statistics.

Watch out: Numbered ACLs are limited to standard (1-99) and extended (100-199) ranges. Using a number outside these ranges will be rejected. Also, ensure the ACL is not used for other purposes (like filtering) that might conflict.

Troubleshooting with This Command

When troubleshooting QoS classification with `match access-group name [acl]`, the first step is to verify that the ACL itself is correctly configured and matches the intended traffic. Use `show access-lists [acl-name]` to display the ACL entries and hit counts. A healthy output shows non-zero match counts for the permit statements.

If match counts are zero, the ACL may be too restrictive (e.g., wrong ports, IPs, or protocol) or the traffic may not be reaching the interface where the service policy is applied. Next, check the class-map configuration with `show class-map [class-name]`. Ensure the class map includes the `match access-group` statement and that the ACL name or number is correct.

A common mistake is using a class-map type that does not support ACL matching (e.g., class-map type qos is correct, but class-map type control-plane may not). Then, verify the policy-map application with `show policy-map interface [interface]`. Look for the class in the output and check packet counters.

If the class shows zero packets, the traffic is not being classified. Possible causes: the service policy is applied in the wrong direction (input vs output), the ACL is not matching due to asymmetric routing, or the traffic is being dropped before classification. Use `debug ip packet [acl]` cautiously to see if packets match the ACL, but be aware of CPU impact.

Also, correlate with `show ip interface [interface]` to ensure the interface is up and not dropping packets. For deeper analysis, use `show policy-map interface [interface] class [class-name]` to see per-class statistics. If the class shows matches but the action (e.g., marking, shaping) is not working, check the policy-map configuration for correct action statements.

Another diagnostic flow: 1) Confirm ACL matches traffic (hit counts). 2) Confirm class map references the ACL. 3) Confirm policy map includes the class. 4) Confirm service policy is applied to the correct interface and direction. 5) Check for any QoS pre-classify or other features that might interfere. Common symptoms: traffic not being marked or shaped as expected, or no matches in class-map counters. The `match access-group` command is often used with `match-any` or `match-all`; ensure the logic matches the intent.

If using `match-all`, all match statements must be true; if using `match-any`, at least one must be true. Misunderstanding this can lead to no classification. Finally, remember that ACLs used for QoS are not the same as ACLs used for security; they can be identical but serve different purposes.

Always test with a small subset of traffic before deploying.

CCNA Exam Tips

Remember that 'match access-group' matches only packets permitted by the ACL; denied packets are not matched.

On the CCNA exam, you may be asked to identify the correct syntax: 'match access-group name [acl-name]' for named ACLs, or 'match access-group [number]' for numbered ACLs.

The ACL used in the match statement must be a standard or extended ACL; named ACLs are typically extended.

Be aware that the class-map must be in class-map configuration mode (global config 'class-map [name]') before using this command.

Common Mistakes

Using 'match access-group' without the 'name' keyword for a named ACL, causing a syntax error.

Referencing an ACL that does not exist yet, resulting in a configuration rejection.

Forgetting that the ACL must permit the desired traffic; if the ACL denies, the class-map will never match.

match access-group name [acl] vs policy-map [name]

In Cisco IOS QoS configuration, 'match access-group name [acl]' is used within a class-map to identify traffic based on an ACL, while 'policy-map [name]' is used to create a policy that bundles multiple class-maps with associated actions. They are commonly confused because both are essential for building a QoS policy, but one focuses on traffic classification (match) and the other on action assignment (policy-map).

Aspect	match access-group name [acl]	policy-map [name]
Scope	Defines traffic class within a class-map	Defines entire QoS policy with multiple classes
Configuration mode	Class-map configuration mode	Global configuration mode (enters policy-map config)
Dependency	Requires an ACL to be pre-configured	Contains class-maps with match statements
Purpose	Classify traffic using ACL match criteria	Apply QoS actions (bandwidth, priority, drop) to classes
Level of configuration	Lower-level: classification only	Higher-level: aggregation of classification and actions

Use match access-group name [acl] when you need to classify traffic based on an existing ACL for inclusion in a class-map within a QoS policy.

Use policy-map [name] when you need to create a complete QoS policy that applies specific actions (e.g., priority, bandwidth) to multiple traffic classes defined by class-maps.

Platform Notes

In IOS-XE (e.g., 16.x), the `match access-group name [acl]` command syntax is identical to classic IOS. However, IOS-XE supports both numbered and named ACLs. The output of `show policy-map interface` may include additional fields like 'offered rate' and 'drop rate'.

In NX-OS (Cisco Nexus switches), the equivalent command is `match access-group [acl-name]` under class-map type qos, but note that NX-OS uses a different QoS framework (MQC is similar but with some syntax differences). For example, in NX-OS, you would use `class-map type qos match-all [name]` and then `match access-group [acl-name]`. Also, NX-OS requires the ACL to be configured with `ip access-list` and the match is based on the permit entries.

In ASA (Adaptive Security Appliance), QoS is more limited; the equivalent is using `access-list` with `class-map` and `policy-map` but the command is `match access-list [acl-name]` (not `match access-group`). ASA uses `match access-list` under class-map configuration. For IOS-XR, the command is `match access-group [acl-name]` under class-map configuration, but IOS-XR uses a different configuration hierarchy (e.g., `class-map [type qos] [name]`).

In older IOS versions (12.x), the command is the same, but the ACL may have limitations (e.g., no support for IPv6 ACLs in early versions). In IOS 15.x and later, IPv6 ACLs are supported with `match access-group name [ipv6-acl]` (using `ipv6 access-list`). Always check the platform documentation for specific version support.

Related Commands

policy-map [name]

Creates or modifies a QoS policy-map that defines a set of class-maps and associated actions (e.g., bandwidth, priority, drop) to apply to traffic on Cisco IOS routers.

show access-lists

Displays all configured ACLs or a specific ACL showing each entry with its sequence number, match criteria (permit/deny, protocol, source, destination, ports), and hit count showing how many packets have matched each entry.

show class-map

Displays the configuration and match criteria of all class maps or a specific class map, used to verify QoS classification rules.

Practice for the CCNA 200-301

Test your knowledge with practice questions covering all CCNA 200-301 exam domains.

Practice CCNA 200-301 Questions