Courseiva
QoSInterface Config

service-policy

Applies a named QoS policy to an interface so traffic is treated according to the policy map's class-based rules.

Definition: service-policy is a Cisco IOS interface config command. Attaches a QoS policy map to an interface in the input or output direction, activating traffic classification, marking, queuing, policing, and shaping defined in the policy map.

Overview

The `service-policy` command is a fundamental tool in Cisco IOS Quality of Service (QoS) configuration, used to attach a policy map to an interface for inbound or outbound traffic. This command enables network engineers to classify, mark, police, shape, or queue traffic based on defined policies, ensuring that critical applications receive appropriate bandwidth and latency guarantees while non-essential traffic is limited. QoS is essential in modern networks where voice, video, and data converge, as it prevents congestion-related degradation and maintains service level agreements (SLAs).

The `service-policy` command is typically used after creating a policy map with `class-map` and `policy-map` commands, and it is applied in interface configuration mode. Alternatives include using `mls qos` on older Catalyst switches or `qos-policy` on some platforms, but `service-policy` is the standard for IOS routers and switches. In a troubleshooting workflow, this command is often verified with `show policy-map interface` to confirm policy application and monitor statistics.

Important IOS behaviors: the command is buffered and applied immediately; it requires privileged EXEC access (enable mode) for configuration; and it modifies the running configuration, which must be saved to startup-config to persist. Understanding `service-policy` is critical for CCNA and CCNP candidates, as QoS is a core topic in both certifications, appearing in scenarios involving traffic prioritization, bandwidth management, and network optimization.

Syntax·Interface Config
service-policy {input | output} <policy-map-name>

When to Use This Command

  • Attach a shaping policy to a WAN egress interface to enforce bandwidth contracts
  • Apply DSCP marking on a LAN ingress port to trust or remark traffic from endpoints
  • Enable CBWFQ or LLQ on a slow link to prioritise VoIP and video
  • Police inbound traffic to drop bursts above a defined rate

Parameters

ParameterSyntaxDescription
input|outputinput | outputSpecifies the direction of traffic to which the policy map is applied. 'input' applies to inbound traffic (received on the interface), while 'output' applies to outbound traffic (transmitted from the interface). Common mistakes include applying a policy in the wrong direction, such as using 'output' for policing inbound traffic, which will not work as expected.
policypolicy-map-nameThe name of the policy map to be attached. The policy map must already be defined using the `policy-map` command. Common mistakes include misspelling the policy name or referencing a policy that does not exist, which results in a configuration error.

Command Examples

Apply output policy on WAN interface

Router(config)# interface GigabitEthernet0/0
Router(config-if)# service-policy output WAN_SHAPER
Router(config-if)# end
Router# show policy-map interface GigabitEthernet0/0

Apply input marking policy on LAN port

Switch(config)# interface GigabitEthernet1/0/1
Switch(config-if)# service-policy input MARK_DSCP
Switch(config-if)# end

Understanding the Output

show policy-map interface lists the policy name, each class, bytes matched, actions taken, queue drops, and conform/exceed/violate counters for policing. Zero counters on a class mean no traffic is matching that class-map.

Configuration Scenarios

Apply outbound shaping to limit bandwidth on a WAN interface

A branch office has a 10 Mbps WAN link that is often congested due to bulk file transfers. The goal is to shape outbound traffic to 8 Mbps to prevent packet loss and ensure fair sharing with real-time applications.

Topology

R1(Gi0/0)---10.0.0.0/30---(Gi0/0)ISP

Steps

  1. 1.Step 1: Enter global configuration mode: configure terminal
  2. 2.Step 2: Create a class-map to match all traffic (optional, but used for shaping): class-map match-all ALL
  3. 3.Step 3: Match all traffic: match any
  4. 4.Step 4: Create a policy-map named SHAPE: policy-map SHAPE
  5. 5.Step 5: Define the class: class ALL
  6. 6.Step 6: Apply shaping to 8 Mbps: shape average 8000000
  7. 7.Step 7: Exit policy-map configuration: exit
  8. 8.Step 8: Enter interface configuration for Gi0/0: interface GigabitEthernet0/0
  9. 9.Step 9: Apply the policy-map in the outbound direction: service-policy output SHAPE
  10. 10.Step 10: Exit and save: end, write memory
Configuration
!
class-map match-all ALL
 match any
!
policy-map SHAPE
 class ALL
  shape average 8000000
!
interface GigabitEthernet0/0
 service-policy output SHAPE
!

Verify: Use 'show policy-map interface GigabitEthernet0/0' to verify the policy is applied and see shaping statistics. Expected output shows the policy name, direction, and shaping parameters like target rate and packets shaped.

Watch out: Shaping is only effective on outbound policies; applying 'service-policy input SHAPE' will not shape inbound traffic. Also, ensure the shaping rate does not exceed the physical interface bandwidth.

Apply inbound policing to limit traffic from a specific subnet

A company wants to limit inbound traffic from a partner subnet (192.168.1.0/24) to 5 Mbps to prevent overwhelming the internal network. Policing is used to drop excess traffic.

Topology

R1(Gi0/0)---10.0.0.0/30---(Gi0/0)Partner_Router (192.168.1.0/24)

Steps

  1. 1.Step 1: Enter global configuration mode: configure terminal
  2. 2.Step 2: Create an access-list to match the partner subnet: access-list 100 permit ip 192.168.1.0 0.0.0.255 any
  3. 3.Step 3: Create a class-map to match the ACL: class-map match-all PARTNER
  4. 4.Step 4: Match the ACL: match access-group 100
  5. 5.Step 5: Create a policy-map named POLICE: policy-map POLICE
  6. 6.Step 6: Define the class: class PARTNER
  7. 7.Step 7: Apply policing with a 5 Mbps rate, normal burst 1.5 MB, excess burst 3 MB: police 5000000 1500000 3000000 conform-action transmit exceed-action drop
  8. 8.Step 8: Exit policy-map configuration: exit
  9. 9.Step 9: Enter interface configuration for Gi0/0: interface GigabitEthernet0/0
  10. 10.Step 10: Apply the policy-map inbound: service-policy input POLICE
  11. 11.Step 11: Exit and save: end, write memory
Configuration
!
access-list 100 permit ip 192.168.1.0 0.0.0.255 any
!
class-map match-all PARTNER
 match access-group 100
!
policy-map POLICE
 class PARTNER
  police 5000000 1500000 3000000 conform-action transmit exceed-action drop
!
interface GigabitEthernet0/0
 service-policy input POLICE
!

Verify: Use 'show policy-map interface GigabitEthernet0/0' to see the policer statistics. Look for 'conformed' and 'exceeded' packets to verify traffic is being policed. Expected output shows the rate and actions.

Watch out: Policing on inbound interfaces drops packets that exceed the rate, which may cause TCP retransmissions. Ensure the burst sizes are appropriate for the traffic pattern; too small bursts can cause unnecessary drops.

Troubleshooting with This Command

When troubleshooting QoS with the `service-policy` command, the primary verification tool is `show policy-map interface [interface]`. This command displays the applied policy, direction, and per-class statistics including classified packets, bytes, and actions taken (e.g., transmit, drop, mark). A healthy output shows increasing packet counts for conforming traffic and minimal or zero drops for exceed actions.

Problem indicators include: no packets matched (indicating a classification issue), excessive drops (indicating policer or shaper misconfiguration), or the policy not appearing at all (indicating it was not applied or was removed). Focus on the 'Class' section for each class-map; if a class shows zero packets, the match criteria (e.g., ACL, DSCP) may be incorrect. For policing, compare conformed vs exceeded packets; a high exceed rate suggests the policer rate is too low or bursts are too small.

For shaping, check the 'Queueing' section for depth and drops; if the queue is full and tail drops occur, consider increasing buffer or adjusting shaping rate. A step-by-step diagnostic flow: 1) Verify the policy is applied with `show running-config interface [interface]` or `show policy-map interface`. 2) Check classification with `show access-lists` or `show class-map` to ensure match criteria are correct. 3) Monitor real-time statistics with `show policy-map interface [interface]` multiple times to see trends. 4) Use `debug policy-map` (with caution) to see per-packet decisions. Correlate with other show commands: `show interface` for interface errors and speed, `show queueing` for queue statistics, and `show processes cpu` to ensure QoS is not overloading the CPU.

Common symptoms: voice quality issues may be due to missing or incorrect QoS marking; use `show policy-map interface` to verify that voice traffic is being classified and prioritized. If traffic is not being shaped, check that the interface speed is correctly set and that shaping is applied outbound. Remember that `service-policy` only applies the policy; the policy itself must be correctly defined with appropriate class-maps and actions.

Always test policies in a lab before production deployment.

CCNA Exam Tips

1.

CCNA QoS questions frequently test that service-policy output is what actually activates shaping

2.

A policy map defined but not attached with service-policy has zero effect

3.

Remember: input = classify/mark/police inbound; output = queue/shape/schedule outbound

Common Mistakes

Applying service-policy input and output on the same interface — only supported on some platforms

Forgetting to attach the policy after creating the policy-map (policy is silent until attached)

Applying a shaping policy in the input direction (shaping only works outbound)

service-policy vs show mls qos

These commands are often mentioned together in QoS troubleshooting because one applies a QoS policy to an interface (service-policy), while the other displays the MLS QoS state including any applied policies (show mls qos). Understanding their differences helps avoid confusion between configuration and verification steps.

Aspectservice-policyshow mls qos
ScopePer-interface, direction-specificSwitch-wide, per-interface statistics
Configuration modeInterface Configuration (config-if)Privileged EXEC
PersistenceSaved in running-configRuntime display only
PrecedenceActivates queuing/policingRead-only; does not affect traffic
Typical useImplementing QoS policiesVerifying MLS QoS settings

Use service-policy when you need to attach a QoS policy map to an interface to enforce classification, marking, queuing, or shaping in a specific direction.

Use show mls qos when you need to inspect the MLS QoS configuration, trust state, DSCP mappings, or per-interface QoS counters across the switch.

Platform Notes

In IOS-XE (e.g., Catalyst 9000 switches), the `service-policy` command syntax is identical, but output from `show policy-map interface` may include additional fields like 'queue depth' and 'drop statistics' in a different format. On NX-OS (e.g., Nexus switches), the equivalent command is `service-policy [input|output] [policy-name]` under interface configuration, but policy maps are defined differently using `policy-map [type qos]` and class-maps with `class-map [type qos]`. NX-OS also uses `match` statements differently (e.g., `match ip dscp`).

For ASA firewalls, QoS is configured using `service-policy` globally or per interface, but the syntax is `service-policy [policy-name] [global | interface [name]]`. ASA does not support all IOS QoS features like shaping; it primarily supports policing and priority queuing. In IOS versions prior to 12.2, `service-policy` was introduced for MQC (Modular QoS CLI); older versions used `rate-limit` or `priority-group`.

IOS 15.x and 16.x maintain backward compatibility but add features like hierarchical policies. IOS-XR uses a different QoS configuration model with `policy-map` and `service-policy` under interface, but the syntax is more complex and includes `class type` and `shape` commands. For CCNA/CCNP study, focus on IOS and IOS-XE as they are most common in exam scenarios.

Related Commands

show interfaces

Displays detailed Layer 1 and Layer 2 statistics for all interfaces or a specific interface: line protocol state, hardware type, MAC address, MTU, bandwidth, duplex, speed, input/output rates, error counters, and queue statistics.

show mls qos

Displays the MLS (Multi-Layer Switching) QoS configuration on Catalyst switches including trust state, DSCP maps, queuing settings, and per-interface QoS statistics.

Practice for the CCNA 200-301

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

Practice CCNA 200-301 Questions