Cisco Catalyst 9000 to Cisco C9000 QoS Migration Guide

Cisco Catalyst 9000 to Cisco C9000 QoS Migration Guide. 3

Purpose and Audience. 3

Executive Summary 3

Architecture Differences 4

Feature Compatibility Matrix 9

Migration Workflow. 11

WRED, WTD, and Discard Class 17

Queue Buffers and Queue Limits 19

Policing and Shaping. 20

Hierarchical QoS (HQoS) Conversion 23

ACL and Classification Guidance. 24

SVI, Port-Channel, and Interface Attachment 24

Worked Example: Campus 1P7Q3T Policy 25

Validation Checklist 29

Migration Checklist 30

Migration Do’s and Don’ts 32

Summary 33

References 33

 

Cisco Catalyst 9000 to Cisco C9000 QoS Migration Guide

Migrating QoS configurations from UADP-based Catalyst 9000 switches to Silicon One-based Cisco C9000 switches.

Purpose and Audience

This guide helps network engineers migrate Cisco Catalyst 9000 QoS configurations to Cisco C9000 switches. It focuses on the behavior changes that matter during configuration conversion, especially egress queuing, classification, policing, WRED/WTD, queue buffers, and policy attachment points.

This guide assumes the reader is already familiar with general QoS configurations, as well as the Cisco UADP and Silicon One ASIC architectures on Cisco C9000 Series Smart Switches. Refer References for more information on these topics.

The key migration principle is simple: a Catalyst 9000 QoS policy should be converted by preserving the original traffic intent, not by copying each command directly.

Use this document as a migration planning and configuration-conversion guide. Always validate the final configuration on the exact target software release before production deployment.

Executive Summary

The largest Catalyst 9000 to Cisco C9000 QoS change is the move from egress classification-based queue selection to ingress traffic-class-based queue selection.

Queue-selection rule used throughout this guide: On Catalyst 9000, egress queueing can match packet-carried QoS fields that are already present or trusted, such as ToS, DSCP, IP precedence, CoS, or EXP; a separate ingress policy is not always required for those fields. Catalyst 9000 egress queueing can also match internal labels such as qos-group, but those labels must be set earlier, typically by an ingress policy. On Cisco C9000, egress queueing selects queues by matching only on the internal traffic-class field, so migrated queueing designs need a corresponding ingress policy to assign traffic-class before the packet reaches egress queueing.

 

The migration is therefore a policy split. The Cisco C9000 egress queueing policy depends on the ingress policy for queue-selection metadata:

1. Ingress policy: classify traffic, set traffic-class for egress queue selection, optionally mark DSCP/CoS/qos-group/discard-class for non-priority WRED queues, and apply ingress policing.

2. Egress queueing policy: match traffic-class and configure priority, bandwidth remaining ratio, shape, queue-limit, and discard-class-based WRED for non-priority queues.

3. Optional egress marking policy: use a separate non-queueing egress policy if post-queue marking is required and supported by the target release.

Architecture Differences

This section introduces the architectural and configuration differences at a high level. For the detailed migration sequence and explanations behind each conversion step, see Migration Workflow.

Before looking at configuration syntax, it is important to understand where each QoS decision is made. The Catalyst 9000 model can make several queueing decisions in the egress policy itself by matching packet-carried fields or previously assigned internal labels. The Cisco C9000 model expects traffic-class assignment before egress; the egress queueing policy then uses that internal field for VoQ selection, scheduling, and congestion behavior.

Catalyst 9000 UADP Egress-Based AFD/WFQ QoS Model

Catalyst 9000 platforms use a UADP egress-based AFD/WFQ QoS model.

For example, assume a campus deployment has the PM-C9000-1p7q3t-out uplink policy used in the worked example later in this guide. Real-time traffic marked EF, CS5, or CS4 must receive strict priority treatment. Transactional traffic marked AF21, AF22, and AF23 must share non-priority bandwidth, but AF21 should be protected longer during congestion than AF22 and AF23.

On Catalyst 9000, that intent can be expressed directly in an egress policy. The egress policy matches the DSCP values, selects the class, applies scheduler treatment, and applies DSCP-specific queue-limit thresholds in the same policy:

class-map match-any CM-REALTIME-MATCH
 match dscp ef
 match dscp cs5
 match dscp cs4

class-map match-any CM-TRANSACTIONAL-MATCH
 match dscp af21 af22 af23

policy-map PM-C9000-1p7q3t-out
 class CM-REALTIME-MATCH
  priority level 1
 class CM-TRANSACTIONAL-MATCH
  bandwidth remaining percent 20
  queue-buffers ratio 20
  queue-limit dscp af21 percent 90
  queue-limit dscp af22 percent 80
  queue-limit dscp af23 percent 70
 class class-default
  bandwidth remaining percent 25

interface TenGigabitEthernet1/1/1
 service-policy output PM-C9000-1p7q3t-out

That model works because the egress queueing policy can classify by packet-carried QoS fields such as DSCP and can directly map those classes to egress queue behavior. For the broader packet-field and qos-group distinction, use the queue-selection rule in Executive Summary.

When an ingress policy is present on Catalyst 9000, it may be used to trust, map, or mark the labels that the egress queueing policy later matches. The important migration point is that the ingress policy is optional for Catalyst 9000 queue selection if the required labels are already present, but it becomes required in the Cisco C9000 design to assign the internal traffic-class.

If the source configuration includes an ingress trust or marking policy, include that policy in the migration analysis. On Cisco C9000, the ingress policy is also where the migration should assign traffic-class for queue selection and, when WRED behavior must be preserved for non-priority queues, discard-class for drop behavior. See Step 4: Convert Ingress Classification and Marking provides the detailed conversion steps.

Cisco C9000 Silicon One Ingress-Based VoQ QoS Model

Cisco C9000 uses Silicon One ingress-based Virtual Output Queuing (VoQ) QoS model. The ingress virtual output queue selected for a packet is determined by the traffic class assigned to the packet. The traffic class is a 3-bit internal value, 0 through 7.

Important Cisco C9000 behavior:

·     Traffic class 7 is the highest priority traffic class.

·     Traffic class 0 maps to class-default.

·     Classification into traffic classes must happen before egress queueing, normally in an ingress policy.

·     Packet color, represented by discard-class, is used for congestion/drop behavior on non-priority queues where WRED is configured. WRED, WTD, and Discard Class explains the threshold conversion.

Notes:

·     Cisco C9000 queue selection is driven by traffic-class, not by egress ToS, DSCP, IP precedence, CoS, EXP, qos-group, or ACL matching.

·     On S1, TC7 is always a priority queue. Priority queues do not support WRED or random-detect, so TC7 does not need discard-class assignment in the ingress policy.

·     Because of this queue-selection rule, a Catalyst 9000 egress-only queueing policy normally becomes two Cisco C9000 policies: an ingress classifier that sets traffic-class, and an egress queueing policy that matches traffic-class.

To achieve similar results on Cisco C9000, preserve the same intent in two stages. First, use the ingress policy to classify traffic and assign internal metadata such as traffic-class and, for non-priority queues where congestion/drop behavior must be preserved, discard-class. This ingress policy may be new even when the source Catalyst 9000 queueing design did not need one. Second, configure the egress queueing policy to match those traffic classes and apply scheduling, shaping, and WRED behavior.

The example below shows the resulting policy split at a high level. WRED, WTD, and Discard Class explains how to map Catalyst 9000 DSCP/CoS queue-limit or WRED thresholds to Cisco C9000 discard-class thresholds.

In the example below, the color-coded classification intent is a one-to-two conversion: the single Catalyst 9000 CM-TRANSACTIONAL-MATCH class map is split into Cisco C9000 CM-TRANSACTIONAL-GREEN and CM-TRANSACTIONAL-YELLOW class maps. The same Classification color cue applies to the source transactional class-map lines and to both target green/yellow class-map groups:

class-map match-any CM-REALTIME-MATCH
 match dscp ef
 match dscp cs5
 match dscp cs4

class-map match-any CM-TRANSACTIONAL-GREEN
 match dscp af21

class-map match-any CM-TRANSACTIONAL-YELLOW
 match dscp af22 af23

policy-map PM-C9350-1P7Q-IN
 class CM-REALTIME-MATCH
  set traffic-class 7
 class CM-TRANSACTIONAL-GREEN
  set traffic-class 3
  set discard-class 0
 class CM-TRANSACTIONAL-YELLOW
  set traffic-class 3
  set discard-class 1
 class class-default
  set traffic-class 0

class-map match-any TC7
 match traffic-class 7

class-map match-any TC3
 match traffic-class 3

policy-map type queueing PM-C9350-1P7Q-OUT
 class TC7
  priority level 1
  shape average percent 10
 class TC3
  bandwidth remaining ratio 20
  random-detect discard-class-based
  random-detect discard-class 0 percent 90 90 1
  random-detect discard-class 1 percent 70 80 1
 class class-default
  bandwidth remaining ratio 25

interface TenGigabitEthernet1/1/1
 service-policy input PM-C9350-1P7Q-IN
 service-policy type queueing output PM-C9350-1P7Q-OUT

Note: The shape average percent 10 line is intentionally added in the Cisco C9000 priority queue. It is not copied from the Catalyst 9000 source policy. Always consider adding a shaper for all priority traffic queues so priority traffic cannot starve non-priority queues; choose the value based on the expected real-time traffic and link speed. Step 6 covers priority queue conversion in more detail.

Feature Compatibility Matrix

Queueing Sub-Features

Note: bandwidth remaining ratio is not the same as bandwidth percent. A practical one-to-one mapping may be possible for simple flat policies when the original percentages were being used only as relative weights, but HQoS, shaping, and priority designs require explicit validation. A full explanation of bandwidth percent versus bandwidth ratio behavior is outside the scope of this migration guide and should be covered in a separate reference.

Non-Queueing Sub-Features

Interface and Other Feature Sub-Features

Migration Workflow

Step 1: Inventory the Existing QoS Configuration

Collect the full QoS-related configuration from the Catalyst 9000:

show running-config | section class-map
show running-config | section policy-map
show running-config | section table-map
show running-config | include service-policy
show running-config | section ^interface
show access-lists

Build an inventory with:

·     All class maps used by QoS policies.

·     All policy maps and whether they are used on input or output.

·     All interfaces with service-policy input or service-policy output.

·     Any SVI, tunnel, sub-interface, or port-channel policy attachments.

·     Any table maps referenced by set or policer actions.

·     Any ACLs referenced by QoS class maps.

·     Any queueing features: priority, bandwidth, shape, queue-limit, queue-buffers, WRED, or random-detect.

·     Any policers, their rates, and their conform/exceed/violate actions.

Before conversion, check for duplicate definitions, missing referenced objects, and incomplete policy attachments. Resolve ambiguous source configuration before treating the result as deployable.

Exclude Platform-Managed QoS Configuration

Class maps, policy maps, table maps, and referenced service-policy names containing AutoQos, AutoConf, or system-cpp are platform-managed and should not be manually translated. Copy every interface configuration command that begins with auto qos to the corresponding Cisco C9000 interface; the generic form is “auto qos <options>”. Applying that interface command automatically generates the platform-specific Cisco C9000 AutoQoS objects and attachments. Validate the exact command on the target release.

Step 2: Flag Breaking Differences

Before translating the policy, flag commands that cannot be carried forward directly:

Step 3: Define the Traffic-Class Plan

Create an explicit traffic-class plan before writing the Cisco C9000 policy. This is the core design decision in the migration because the Cisco C9000 egress queueing policy cannot select queues from Catalyst 9000-style packet fields or qos-group directly.

The table below is a common starting point. Select different mappings when required by the existing QoS design, especially when CS6/CS7 are assigned to routing/control protocols and EF is assigned to voice.

Step 4: Convert Ingress Classification and Marking

Any Catalyst 9000 policy that classifies or marks traffic at ingress should be updated to set the internal traffic class. If the Catalyst 9000 design relied on egress-only packet-field matches, add a corresponding Cisco C9000 ingress policy to classify the same traffic and set traffic-class. If the Catalyst 9000 design matched qos-group, migrate the earlier internal-marking policy into a Cisco C9000 policy that assigns traffic-class. If congestion/drop behavior must be preserved for non-priority queues, WRED, WTD, and Discard Class describes how to add discard-class for WRED/WTD migration.

Catalyst 9000 source egress classification excerpt from the worked example:

class-map match-any CM-REALTIME-MATCH
 match dscp ef
 match dscp cs5
 match dscp cs4

class-map match-any CM-TRANSACTIONAL-MATCH
 match dscp af21 af22 af23

policy-map PM-C9000-1p7q3t-out
 class CM-REALTIME-MATCH
  priority level 1
 class CM-TRANSACTIONAL-MATCH
  bandwidth remaining percent 20
  queue-buffers ratio 20
  queue-limit dscp af21 percent 90
  queue-limit dscp af22 percent 80
  queue-limit dscp af23 percent 70
 class class-default
  bandwidth remaining percent 25

Cisco C9000-style ingress classification and traffic-class assignment:

class-map match-any CM-REALTIME-MATCH
 match dscp ef
 match dscp cs5
 match dscp cs4

class-map match-any CM-TRANSACTIONAL-GREEN
 match dscp af21

class-map match-any CM-TRANSACTIONAL-YELLOW
 match dscp af22 af23

policy-map PM-C9350-1P7Q-IN
 class CM-REALTIME-MATCH
  set traffic-class 7
 class CM-TRANSACTIONAL-GREEN
  set traffic-class 3
  set discard-class 0
 class CM-TRANSACTIONAL-YELLOW
  set traffic-class 3
  set discard-class 1
 class class-default
  set traffic-class 0

Apply the ingress classification policy to the ingress interface where the traffic enters the Cisco C9000:

interface TenGigabitEthernet1/1/1
 service-policy input PM-C9350-1P7Q-IN

Note: If no ingress policy is applied, only traffic classes 7 and 0 are chosen based on the trust type and trusted tag value.

The example includes discard-class assignment only for the non-priority transactional queue to show where Cisco C9000 packet color is set. TC7 does not need discard-class because it is a priority queue and does not use WRED. WRED, WTD, and Discard Class covers how to choose the green/yellow WRED thresholds for non-priority queues.

Step 5: Convert Egress Queuing

Egress queueing policy maps on Cisco C9000 should match traffic class only. They must be paired with ingress classification that assigns the traffic classes used by the queueing classes.

Create one class map per traffic class:

class-map match-any TC7
 match traffic-class 7
class-map match-any TC6
 match traffic-class 6
class-map match-any TC5
 match traffic-class 5
class-map match-any TC4
 match traffic-class 4
class-map match-any TC3
 match traffic-class 3
class-map match-any TC2
 match traffic-class 2
class-map match-any TC1
 match traffic-class 1

Then create the queueing policy:

policy-map type queueing PM-C9350-1P7Q-OUT
 class TC7
  priority level 1
  shape average percent 10
 class TC6
  bandwidth remaining ratio 10
 class TC5
  bandwidth remaining ratio 10
 class TC4
  bandwidth remaining ratio 30
 class TC3
  bandwidth remaining ratio 20
 class TC2
  bandwidth remaining ratio 4
 class TC1
  bandwidth remaining ratio 1
 class class-default
  bandwidth remaining ratio 25

Bandwidth Ratio Calculation

bandwidth remaining ratio is a relative scheduler weight, not a direct percent reservation. On Cisco C9000, the configured ratio value must be in the range 1 to 63. For a simple flat policy, the cleanest starting point is to preserve the relative relationship between the Catalyst 9000 non-priority classes, normalize the values into the 1-63 range, and then validate the result under congestion.

The 1-63 limit applies to each configured class ratio value. The sum of all configured ratios can be greater than 63.

For the best-case flat-policy conversion:

1.     Exclude strict-priority classes from the ratio calculation.

2.     List the Catalyst 9000 bandwidth remaining percent values for the remaining scheduled classes.

3.     Use the same numbers as the initial Cisco C9000 bandwidth remaining ratio values only when every value is within the 1-63 parser range.

4.     If any value is greater than 63, divide all values by a common factor or otherwise scale them down while preserving the same relative relationship.

5.     Calculate each class’s best-case share of the remaining scheduler bandwidth as:

class best-case share = class ratio / sum(all non-priority ratios)

For example, a Catalyst 9000 flat-policy relationship of 20 and 80 should not be configured as Cisco C9000 ratios 20 and 80, because 80 is outside the supported range. Normalize the same 1:4 relationship to valid Cisco C9000 values, such as 10 and 40.

If a priority class is shaped, first subtract that shaped portion from the link capacity, then apply the ratio calculation to the remaining bandwidth. For the example above, TC7 is shaped to 10 percent, leaving 90 percent for the non-priority scheduler. The non-priority ratios are 10 + 10 + 30 + 20 + 4 + 1 + 25 = 100.

This calculation is a planning aid, not a substitute for validation. HQoS, parent shaping, priority queues, oversubscription, and platform-specific scheduler behavior can change the effective bandwidth seen by a class.

Apply it with the typed queueing attachment:

interface TenGigabitEthernet1/1/1
 service-policy type queueing output PM-C9350-1P7Q-OUT

This output policy is not a standalone replacement for the Catalyst 9000 output policy. It depends on the ingress policy from Step 4 to assign the traffic-class values that the egress queueing class maps match.

Note: If the original Catalyst 9000 policy had egress marking in the same policy as queueing, split egress marking into a separate non-queueing policy.

Step 6: Convert Priority Queues

Catalyst 9000 designs commonly use one or two priority queues. Cisco C9000 supports up to seven priority levels, mapped to traffic classes from highest to lowest:

Rules to follow:

·     If any priority queue is configured, priority level 1 must be present.

·     Priority levels must be contiguous. For example, P1 and P3 without P2 is not valid.

·     Do not configure multiple classes with the same priority level.

·     TC7 should be treated as the highest priority queue.

·     TC7 is always a priority queue on S1 and cannot use WRED or random-detect.

·     Configure an explicit shaper for priority traffic. This prevents priority traffic from starving non-priority queues.

Note: Choose shape average percent <value> based on the expected traffic that belongs in the priority queue and the link speed. The percent value has 1 percent granularity; if the required cap is less than 1 percent of the link, use shape average <rate> instead.

Example:

policy-map type queueing PRIORITY-SYNTAX-EXAMPLE
 class TC7
  priority level 1
  shape average percent 10
 class TC6
  priority level 2
  shape average percent 5
 class TC5
  bandwidth remaining ratio 4
 class class-default
  bandwidth remaining ratio 15

The non-priority ratios in this example are normalized values. A source relationship such as 20:75 can be expressed as 4:15 so every configured Cisco C9000 ratio remains within the 1-63 range.

WRED, WTD, and Discard Class

What Changes

The worked example’s Catalyst 9000 egress policy uses DSCP-based queue limits for several classes. The mission-critical class is one representative example:

class-map match-any CM-MISSION-CRITICAL-MATCH
 match dscp af31 af32 af33

policy-map PM-C9000-1p7q3t-out
 class CM-MISSION-CRITICAL-MATCH
  bandwidth remaining percent 30
  queue-buffers ratio 20
  queue-limit dscp af31 percent 100
  queue-limit dscp af32 percent 90
  queue-limit dscp af33 percent 80

Cisco C9000 does not provide a direct DSCP-per-threshold queue-limit model. Instead, use the internal discard class:

·     discard-class 0: green, normally protected longer.

·     discard-class 1: yellow, normally dropped earlier.

Apply discard-class-based WRED only to non-priority queues. On S1, TC7 is always a priority queue. In addition, any other traffic class configured with priority level <value> is a priority queue. Do not configure random-detect under TC7 or under any other class configured as a priority queue, regardless of its traffic-class number.

This means a Catalyst 9000 three-threshold model must usually be collapsed into two Cisco C9000 drop colors. The migrated Cisco C9000 thresholds should preserve the Catalyst 9000 threshold values as closely as the two-threshold model allows.

Conversion Pattern

At ingress, split the traffic into green and yellow groups:

class-map match-any CM-MISSION-CRIT-GREEN
 match dscp af31

class-map match-any CM-MISSION-CRIT-YELLOW
 match dscp af32 af33

policy-map PM-C9350-1P7Q-IN
 class CM-MISSION-CRIT-GREEN
  set traffic-class 4
  set discard-class 0
 class CM-MISSION-CRIT-YELLOW
  set traffic-class 4
  set discard-class 1

At egress, configure discard-class-based thresholds. For the Catalyst 9000 example above, the source thresholds are 100, 90, and 80 percent; the closest Cisco C9000 two-threshold mapping is green at 100 to 100 percent and yellow at 80 to 90 percent:

policy-map type queueing PM-C9350-1P7Q-OUT
 class TC4
  bandwidth remaining ratio 30
  random-detect discard-class-based
  random-detect discard-class 0 percent 100 100 1
  random-detect discard-class 1 percent 80 90 1
  queue-limit 2000000 bytes

For dense DSCP WTD configurations, choose the mapping intentionally. A common approach is:

·     Map the most protected DSCP values to discard-class 0.

·     Map the DSCP values that should drop first to discard-class 1.

·     Choose the Cisco C9000 discard-class min/max values to match the Catalyst 9000 queue-limit dscp values as closely as possible.

·     Document the behavior change because three or more Catalyst 9000 thresholds become two Cisco C9000 colors.

Catalyst 9000 WRED Configuration Example

Catalyst 9000 can configure DSCP-based WRED with an explicit minimum and maximum threshold for each DSCP. The following source class uses three WRED profiles:

class-map match-any CM-AF2-DATA
 match dscp af21 af22 af23

policy-map C9300-EGRESS
 class CM-AF2-DATA
  bandwidth remaining percent 20
  random-detect dscp-based
  random-detect dscp 18 percent 80 100
  random-detect dscp 20 percent 70 100
  random-detect dscp 22 percent 60 100

The numeric DSCP values 18, 20, and 22 represent AF21, AF22, and AF23. Each Catalyst 9000 command supplies one minimum/maximum pair: AF21 uses 80 100, AF22 uses 70 100, and AF23 uses 60 100.

On Cisco C9000, first assign the queue and discard class at ingress. This example keeps AF21 as the protected green traffic and groups AF22 and AF23 as yellow traffic:

class-map match-any CM-AF2-GREEN
 match dscp af21

class-map match-any CM-AF2-YELLOW
 match dscp af22 af23

policy-map C9350-INGRESS
 class CM-AF2-GREEN
  set traffic-class 3
  set discard-class 0
 class CM-AF2-YELLOW
  set traffic-class 3
  set discard-class 1

Then configure WRED under the non-priority TC3 queue. When several source profiles are grouped into one discard class, a conservative starting point is the lowest member minimum and the highest member maximum. AF22 70 100 and AF23 60 100 therefore become the yellow envelope 60 100; do not form 60 70 from two source minimum thresholds.

class-map match-any TC3
 match traffic-class 3

policy-map type queueing C9350-EGRESS
 class TC3
  bandwidth remaining ratio 20
  random-detect discard-class-based
  random-detect discard-class 0 percent 80 100 1
  random-detect discard-class 1 percent 60 100 1

If this source class is instead migrated to a Cisco C9000 priority queue, omit every random-detect command from that target queue. This prohibition applies to every class configured with priority level, not only TC7. Preserve the queue’s priority and shaping intent, but do not attempt to retain the source WRED under that priority queue.

Queue Buffers and Queue Limits

The Catalyst 9000 queue-buffers ratio command and the Cisco C9000 queue-limit command express similar queue-depth intent through different models.

Why:

·     Catalyst 9000 UADP uses dynamic shared buffering.

·     queue-buffers ratio is a share of a dynamic pool, not a fixed byte value.

·     Softmax buffer tuning on Catalyst 9000 does not have a Cisco C9000 equivalent and is not required.

·     Cisco C9000 uses static per-VoQ queue limits.

·     Cisco C9000 queue-limit is configured in bytes.

Recommended migration behavior:

1.     Treat the source queue-buffers ratio as an indication of queue-depth intent, not as a value to copy.

2.     Use Cisco C9000 default queue limits as the starting point unless the source design has a clear queue-depth objective.

3.     When a queue-depth objective is known, express it with Cisco C9000 queue-limit.

4.     Monitor queue drops and latency after traffic validation.

5.     Tune queue-limit for queues that show real congestion or burst-loss symptoms.

If tuning is required, base it on traffic objective rather than trying to numerically convert the UADP ratio:

Policing and Shaping

Egress Policing and Egress Shaping

Do not treat every Catalyst 9000 egress policer as an ingress policer during migration. First identify the original intent. Many Catalyst 9000 egress policers were used as a practical way to manage egress bandwidth because that was the available design option. For that use case, Cisco C9000 egress shaping is usually the closest operational migration.

Use this decision rule:

Catalyst 9000 egress policing used for bandwidth management:

class-map match-any GUEST-TRAFFIC
 match access-group name GUEST-ACL

policy-map EGRESS-POLICE
 class GUEST-TRAFFIC
  police cir 50000000

interface GigabitEthernet1/0/1
 service-policy output EGRESS-POLICE

Cisco C9000 egress shaping replacement:

policy-map INGRESS-CLASSIFY
 class GUEST-TRAFFIC
  set traffic-class 2

interface GigabitEthernet1/0/1
 service-policy input INGRESS-CLASSIFY

class-map match-any TC2
 match traffic-class 2

policy-map type queueing EGRESS-SHAPE
 class TC2
  shape average 50000000

interface GigabitEthernet1/0/1
 service-policy type queueing output EGRESS-SHAPE

If the original requirement is strict policing rather than egress bandwidth management, use ingress policing only where the traffic can be identified before egress queueing. When approximating a single aggregate egress policer with multiple ingress policers, divide the intended aggregate rate across the ingress interfaces. For example, a 50 Mbps aggregate cap across two ingress interfaces starts as 25 Mbps per ingress interface:

policy-map INGRESS-POLICE-25M
 class GUEST-TRAFFIC
  police cir 25000000
   conform-action transmit
   exceed-action drop
  set traffic-class 2

interface GigabitEthernet1/0/1
 service-policy input INGRESS-POLICE-25M

interface GigabitEthernet1/0/2
 service-policy input INGRESS-POLICE-25M

This divided-rate approach is still not equivalent to one aggregate egress policer because traffic may not be evenly distributed across ingress interfaces. In that case, use egress shaping when the intent is bandwidth management, or redesign the policy with explicit ingress classification and policing where strict policing is required.

Policer Rate and Burst Syntax

For current Cisco C9000 migration planning, validate the target release for policer rate limits. Source migration material identifies a 1.2 Mbps minimum policer rate on Cisco C9000 software used for validation. Policies with lower Catalyst 9000 policer rates, such as 32 kbps or 128 kbps Auto QoS policers, should be flagged.

Migration options:

·     Raise the policer rate to the target Cisco C9000 minimum.

·     Remove the low-rate policer if it no longer provides useful protection.

·     Redesign the classification and policing at a coarser aggregate level.

Catalyst 9000 policers may also specify explicit conform and peak burst values with bc and be. Treat burst as a separate migration check from the policer rate. Current Cisco C9000/S1 policer syntax does not expose equivalent explicit burst knobs; the platform selects burst values based on the configured rates. Do not add a Cisco C9000 bc equivalent such as bc 39250, and do not retain source be on a dual-rate policer.

For a Catalyst 9000 policer below the Cisco C9000 minimum rate:

! Avoid carrying this over directly:
police cir 128000 bc 8000

! Use target rate syntax and validate platform-calculated burst behavior:
police cir 1200000
 conform-action transmit
 exceed-action drop

Note: In this example, the explicit source bc 8000 is not translated separately. The Cisco C9000 burst is automatically selected from the configured policer rate. For a dual-rate source, apply the same rule to both bc and be.

For a Catalyst 9000 policer whose CIR is already supported, keep the intended CIR but still remove explicit burst syntax:

! C9300 source:
police cir 50000000 bc 1562500

! C9350 target:
police cir 50000000
 conform-action transmit
 exceed-action drop

Use explicit policer actions in migrated configurations. This makes the intended behavior clear and avoids relying on platform defaults.

Preserve the complete policer structure unless the migration design intentionally changes it. A dual-rate policer containing CIR, PIR, conform, exceed, and violate behavior must not be reduced silently to a single-rate policer. If a minimum-rate fallback raises a dual-rate policer, scale CIR and PIR by the same factor so the relative CIR:PIR ratio is retained, keep PIR greater than CIR, and preserve each supported action.

Treat a user-defined table map and every policy action that references it as one migration unit. For a supported same-domain map such as DSCP-to-DSCP, retain the table-map definition, its explicit entries, default copy or other default behavior, and both exceed and violate references. Only platform-managed table maps identified by the AutoQoS exclusion rule should be omitted automatically.

Hierarchical QoS (HQoS) Conversion

Cisco C9000 supports the two-level egress port-shaper form of HQoS: a parent queueing policy shapes the aggregate traffic in class-default and invokes a child queueing policy. Preserve that parent/child structure instead of flattening the source policy. Convert the child policy with the same Cisco C9000 rules used for a flat queueing policy: classify and assign traffic-class at ingress, match traffic-class in the child, shape every priority queue, normalize non-priority ratios to the 1-63 range, and apply WRED only to non-priority queues.

For example, consider this Catalyst 9000 parent shaper and child queueing policy:

policy-map C9300-HQOS-CHILD
 class VOICE
  priority level 1
  police rate percent 10
 class BUSINESS
  bandwidth remaining percent 20
 class class-default
  bandwidth remaining percent 80

policy-map C9300-HQOS-PARENT
 class class-default
  shape average 1000000000
  service-policy C9300-HQOS-CHILD

After VOICE and BUSINESS have been assigned to TC7 and TC3 at ingress, the corresponding Cisco C9000 egress HQoS pattern is:

policy-map type queueing C9350-HQOS-CHILD
 class TC7
  priority level 1
  shape average percent 10
 class TC3
  bandwidth remaining ratio 10
 class class-default
  bandwidth remaining ratio 40

policy-map type queueing C9350-HQOS-PARENT
 class class-default
  shape average 1000000000
  service-policy C9350-HQOS-CHILD

Apply the parent HQoS policy as the typed output queueing policy on the Cisco C9000 egress interface:

interface <C9350-egress-interface>
 service-policy type queueing output C9350-HQOS-PARENT

In this example, the child source relationship 20:80 is normalized to 10:40. The parent contains only class-default, the aggregate shaper, and the child service-policy; do not place bandwidth remaining ratio in the parent. Validate the supported parent shape range, child actions, attachment type, and HQoS statistics on the exact Cisco C9000 software release. HQoS designs that use other Catalyst 9000 hierarchy forms require redesign rather than a direct syntax conversion.

ACL and Classification Guidance

Ingress ACL Classification

IPv4 and IPv6 ACL-based QoS classification can be used at ingress. This is the preferred replacement when a Catalyst 9000 egress marking policy used ACLs, or when a Cisco C9000 migration needs ACL matching before egress queueing or marking.

Pattern:

class-map match-any APP-TRAFFIC
 match access-group name APP-ACL

policy-map INGRESS-CLASSIFY
 class APP-TRAFFIC
  set traffic-class 4
  set qos-group 4

The traffic-class selects the egress queue. The optional qos-group can be used as an internal label if a separate egress marking policy needs to identify the traffic later.

Egress ACL Classification

Do not use ACL-based class maps in Cisco C9000 egress queueing or marking policies. On Catalyst 9000, ACL-based classification may appear in normal egress marking policies, while egress queueing policy maps follow the packet-field and internal-label behavior described earlier. For Cisco C9000, move egress ACL classification to ingress and set an internal field:

class-map match-any ACL-MATCHED-TRAFFIC
  match access-group name ACL-MATCHED-TRAFFIC

class-map match-any QG4
  match qos-group 4

policy-map INGRESS-CLASSIFY
 class ACL-MATCHED-TRAFFIC
  set traffic-class 4
  set qos-group 4

policy-map EGRESS-MARKING
 class QG4
  set dscp af31

MAC ACL Classification

MAC ACL based QoS classification will be supported on Cisco C9000 starting in release 26.2.2. For target releases before 26.2.2, replace MAC ACL QoS classification with one of the following:

·     IP ACL classification if the traffic has predictable IP source, destination, or L4 ports.

·     VLAN-based classification if the traffic is separated by VLAN.

·     DSCP/CoS trust or remarking at the access edge.

·     Upstream marking before the Cisco C9000.

SVI, Port-Channel, and Interface Attachment

SVI Attachment

Many Catalyst 9000 campus configurations attach ingress marking policies to many VLAN interfaces:

interface Vlan25
 service-policy input PM-LAN-VOICE-FACILITY-MARKING

interface Vlan500
 service-policy input PM-IDF-DATA-FACILITY-MARKING

This does not migrate directly to Cisco C9000. For Cisco C9000, move classification and marking to the physical or port-channel ingress points carrying the traffic.

Migration approach:

1.     Identify which physical ports and port-channels feed each VLAN.

2.     Apply the appropriate ingress classification policy to those ingress interfaces.

3.     Preserve VLAN-specific behavior by splitting policies by physical access role, trunk role, or VLAN match where supported.

4.     Use DSCP/CoS trust at the access boundary if the design depends on endpoints marking traffic correctly.

Port-Channel Attachment

Cisco C9000 uses a split behavior for port-channels:

·     Queueing policies are applied to member interfaces with service-policy type queueing output.

·     Non-queueing policies, such as ingress marking or policing, can be applied at the port-channel attachment point where supported.

Example:

interface Port-channel1
 service-policy input PM-C9350-1P7Q-IN

interface TenGigabitEthernet1/1/1
 channel-group 1 mode active
 service-policy type queueing output PM-C9350-1P7Q-OUT

interface TenGigabitEthernet2/1/1
 channel-group 1 mode active
 service-policy type queueing output PM-C9350-1P7Q-OUT

Worked Example: Campus 1P7Q3T Policy

The sample Catalyst 9000 configuration used for this guide has three major QoS elements:

·     Ingress marking policies applied to many SVI interfaces.

·     A PM-C9000-1p7q3t-out egress policy applied to uplink members.

·     Traffic classes for real-time, control, multimedia video, mission-critical data, transactional data, bulk data, scavenger, and default traffic.

The source Catalyst 9000 egress policy can select queues directly from DSCP values. The migrated Cisco C9000 design intentionally splits that behavior into two policies: the ingress policy maps those DSCP values into internal traffic classes, and the egress queueing policy matches only those traffic classes.

Source Catalyst 9000 Egress Policy Pattern

The Catalyst 9000 class maps and egress policy follow this structure:

class-map match-any CM-REALTIME-MATCH
 match dscp ef
 match dscp cs5
 match dscp cs4

class-map match-any CM-CONTROL-MATCH
 match dscp cs6
 match dscp cs7
 match dscp cs3

class-map match-any CM-MULTIMEDIA-VIDEO-MATCH
 match dscp af41 af42 af43

class-map match-any CM-MISSION-CRITICAL-MATCH
 match dscp af31 af32 af33

class-map match-any CM-TRANSACTIONAL-MATCH
 match dscp af21 af22 af23

class-map match-any CM-BULK-DATA-MATCH
 match dscp af11 af12 af13

class-map match-any CM-SCAVENGER-MATCH
 match dscp cs1

policy-map PM-C9000-1p7q3t-out
 class CM-REALTIME-MATCH
  priority level 1
 class CM-CONTROL-MATCH
  bandwidth remaining percent 10
  queue-buffers ratio 10
 class CM-MULTIMEDIA-VIDEO-MATCH
  bandwidth remaining percent 10
  queue-buffers ratio 10
  queue-limit dscp af41 percent 100
  queue-limit dscp af42 percent 90
  queue-limit dscp af43 percent 80
 class CM-MISSION-CRITICAL-MATCH
  bandwidth remaining percent 30
  queue-buffers ratio 20
  queue-limit dscp af31 percent 100
  queue-limit dscp af32 percent 90
  queue-limit dscp af33 percent 80
 class CM-TRANSACTIONAL-MATCH
  bandwidth remaining percent 20
  queue-buffers ratio 20
  queue-limit dscp af21 percent 90
  queue-limit dscp af22 percent 80
  queue-limit dscp af23 percent 70
 class CM-BULK-DATA-MATCH
  bandwidth remaining percent 4
  queue-buffers ratio 20
  queue-limit dscp af11 percent 100
  queue-limit dscp af12 percent 90
  queue-limit dscp af13 percent 80
 class CM-SCAVENGER-MATCH
  bandwidth remaining percent 1
  queue-buffers ratio 5
 class class-default
  bandwidth remaining percent 25

Target Traffic-Class Mapping

These target traffic classes are not selected by matching DSCP in the Cisco C9000 egress queueing policy. They must be assigned by the corresponding ingress classification policy.

Cisco C9000 Ingress Classification Example

class-map match-any CM-REALTIME-MATCH
 match dscp ef
 match dscp cs5
 match dscp cs4

class-map match-any CM-CONTROL-MATCH
 match dscp cs6
 match dscp cs7
 match dscp cs3

class-map match-any CM-MM-VIDEO-GREEN
 match dscp af41

class-map match-any CM-MM-VIDEO-YELLOW
 match dscp af42 af43

class-map match-any CM-MISSION-CRIT-GREEN
 match dscp af31

class-map match-any CM-MISSION-CRIT-YELLOW
 match dscp af32 af33

class-map match-any CM-TRANSACTIONAL-GREEN
 match dscp af21

class-map match-any CM-TRANSACTIONAL-YELLOW
 match dscp af22 af23

class-map match-any CM-BULK-DATA-GREEN
 match dscp af11

class-map match-any CM-BULK-DATA-YELLOW
 match dscp af12 af13

class-map match-any CM-SCAVENGER-MATCH
 match dscp cs1

policy-map PM-C9350-1P7Q-IN
 class CM-REALTIME-MATCH
  set traffic-class 7
 class CM-CONTROL-MATCH
  set traffic-class 6
 class CM-MM-VIDEO-GREEN
  set traffic-class 5
  set discard-class 0
 class CM-MM-VIDEO-YELLOW
  set traffic-class 5
  set discard-class 1
 class CM-MISSION-CRIT-GREEN
  set traffic-class 4
  set discard-class 0
 class CM-MISSION-CRIT-YELLOW
  set traffic-class 4
  set discard-class 1
 class CM-TRANSACTIONAL-GREEN
  set traffic-class 3
  set discard-class 0
 class CM-TRANSACTIONAL-YELLOW
  set traffic-class 3
  set discard-class 1
 class CM-BULK-DATA-GREEN
  set traffic-class 2
  set discard-class 0
 class CM-BULK-DATA-YELLOW
  set traffic-class 2
  set discard-class 1
 class CM-SCAVENGER-MATCH
  set traffic-class 1
 class class-default
  set traffic-class 0

Cisco C9000 Egress Queueing Example

This egress queueing policy assumes that PM-C9350-1P7Q-IN has already classified the traffic and assigned the traffic-class values. Without that corresponding ingress policy, the TC7 through TC1 queueing classes do not match packets merely because the packets carry the source QoS markings. If the source Catalyst 9000 design used qos-group, remember that it was an internal label assigned earlier, not a packet-carried marking.

class-map match-any TC7
 match traffic-class 7
class-map match-any TC6
 match traffic-class 6
class-map match-any TC5
 match traffic-class 5
class-map match-any TC4
 match traffic-class 4
class-map match-any TC3
 match traffic-class 3
class-map match-any TC2
 match traffic-class 2
class-map match-any TC1
 match traffic-class 1

policy-map type queueing PM-C9350-1P7Q-OUT
 class TC7
  priority level 1
  shape average percent 10
 class TC6
  bandwidth remaining ratio 10
  queue-limit 1000000 bytes
 class TC5
  bandwidth remaining ratio 10
  random-detect discard-class-based
  random-detect discard-class 0 percent 100 100 1
  random-detect discard-class 1 percent 80 90 1
  queue-limit 1000000 bytes
 class TC4
  bandwidth remaining ratio 30
  random-detect discard-class-based
  random-detect discard-class 0 percent 100 100 1
  random-detect discard-class 1 percent 80 90 1
  queue-limit 2000000 bytes
 class TC3
  bandwidth remaining ratio 20
  random-detect discard-class-based
  random-detect discard-class 0 percent 90 90 1
  random-detect discard-class 1 percent 70 80 1
  queue-limit 2000000 bytes
 class TC2
  bandwidth remaining ratio 4
  random-detect discard-class-based
  random-detect discard-class 0 percent 100 100 1
  random-detect discard-class 1 percent 80 90 1
  queue-limit 2000000 bytes
 class TC1
  bandwidth remaining ratio 1
  queue-limit 500000 bytes
 class class-default
  bandwidth remaining ratio 25

Notes for this example:

·     The Catalyst 9000 queue-buffers ratio commands are not copied.

·     The example uses explicit queue-limit values from the conversion attempt; validate these under expected traffic.

·     Priority traffic is shaped at 10 percent as an example. Choose a shaper value that matches the intended voice/video design and link speed.

Applying the Worked Example

For uplink or routed physical interfaces:

interface TenGigabitEthernet1/1/1
 service-policy input PM-C9350-1P7Q-IN
 service-policy type queueing output PM-C9350-1P7Q-OUT

For port-channel designs:

interface Port-channel1
 service-policy input PM-C9350-1P7Q-IN

interface TenGigabitEthernet1/1/1
 channel-group 1 mode active
 service-policy type queueing output PM-C9350-1P7Q-OUT

interface TenGigabitEthernet2/1/1
 channel-group 1 mode active
 service-policy type queueing output PM-C9350-1P7Q-OUT

Do not attach the migrated QoS policy directly to interface Vlan on Cisco C9000. Move that classification closer to the ingress physical or logical port where the traffic enters the switch.

Validation Checklist

Parser Validation

Apply the converted configuration in a lab on the target Cisco C9000 release. Check for:

·     Rejected policy-map type queueing syntax.

·     Rejected egress ACL classification.

·     Rejected egress policing.

·     Rejected SVI or sub-interface QoS attachments.

·     Rejected MAC ACL QoS classification on target releases before 26.2.2.

·     Mixed L2/L3 class-map errors.

·     Non-contiguous priority-level errors.

·     Priority classes missing required shapers.

·     Policer rates below the platform minimum.

Operational Validation

Use these commands as a starting point. Cisco C9000 supports FED QoS queue and interface validation commands; use them to confirm that the migrated traffic-class, queueing, WRED, and policy attachments programmed as intended. Exact fields can vary by software release.

show policy-map interface <interface>
show policy-map type queueing interface <interface>
show policy-map type queueing <policy-name>
show platform hardware fed switch active qos queue stats interface <interface>
show platform hardware fed switch active qos queue config interface <interface>
show platform software fed switch active qos interface <interface> ingress npd detailed
show logging | include QOS|FED|PANGEA_QOS|POLICY

Expected validation outcomes:

·     Ingress policy counters increment for expected classes.

·     Traffic-class assignment appears in hardware programming.

·     Egress queueing policy is attached with the typed queueing attachment and has a corresponding ingress policy assigning every non-default traffic class it matches.

·     TC7 traffic is mapped to the intended priority queue.

·     Non-priority queue weights match the intended bandwidth remaining ratio design.

·     Discard-class-based WRED entries appear for queues where WRED was configured.

·     No policy installation failure syslogs appear.

·     Queue drops are consistent with the intended service model.

Migration Checklist

Use this checklist for each migration:

Migration Do’s and Don’ts

Do:

·     Preserve the intended behavior, not every Catalyst 9000 command.

·     Classify once at ingress and set traffic-class explicitly for every egress queueing class.

·     Convert Catalyst 9000 packet-field queue-selection matches into Cisco C9000 ingress classification rules.

·     Convert Catalyst 9000 egress qos-group queue-selection matches by migrating the earlier internal marking step to assign Cisco C9000 traffic-class.

·     Use traffic-class-only class maps for egress queueing.

·     Use separate policies for ingress classification, egress queueing, and egress marking.

·     Keep TC7 for truly high-priority traffic.

·     Shape priority queues.

·     Validate under real traffic and tune queue-limit only when needed.

Do not:

·     Copy a Catalyst 9000 egress policy directly into Cisco C9000.

·     Attach only the Cisco C9000 output queueing policy when migrated queue selection depends on source packet-field or qos-group matches.

·     Use egress ACL classification for queueing or marking on Cisco C9000.

·     Use egress policing.

·     Attach QoS policies to SVIs on Cisco C9000.

·     Assume queue-buffers ratio converts to a fixed byte value.

·     Keep DSCP/CoS WRED syntax unchanged.

·     Assume MAC ACL QoS classification works on releases before 26.2.2.

·     Assign bulk or best-effort traffic to TC7.

·     Rely on implicit policer actions in a migration document.

Summary

Catalyst 9000 to Cisco C9000 QoS migration is primarily an architecture migration. The Catalyst 9000 policy model lets egress queueing policies classify and select queues directly from packet fields or previously assigned internal labels. The Cisco C9000 model expects ingress classification into traffic classes to enable the advantages of Silicon One ingress-based VoQ behavior, which requires a corresponding ingress traffic-class assignment policy for the egress queueing policy.

A successful migration therefore starts with a traffic-class plan, then rewrites policies around three separate responsibilities:

1.     Ingress: classify, mark, color, and police.

2.     Egress queueing: schedule and manage congestion by traffic class.

3.     Optional egress marking: remark traffic using supported non-queueing policy classification.

Some behavior changes should be expected, but a migration that preserves the original traffic intent, assigns traffic classes deliberately, and validates queue behavior can confidently deliver equivalent and often better QoS experiences on Cisco C9000.

References

·     Cisco Silicon One QoS White Paper: https://www.cisco.com/c/en/us/products/collateral/switches/catalyst-9500-series-switches/catalyst-9500x-9600x-qos-q200-wp.html

·     Cisco Live 2025 BRKARC-2039, S1 QoS on Cisco9K: https://www.ciscolive.com/c/dam/r/ciscolive/global-event/docs/2025/pdf/BRKARC-2039.pdf

·     Cisco Live 2024 BRKARC-2096, Migrating to S1 Q200 Platforms: https://www.ciscolive.com/c/dam/r/ciscolive/global-event/docs/2024/pdf/BRKARC-2096.pdf

·     Cisco IOS XE Quality of Service Configuration Guide: https://www.cisco.com/c/en/us/td/docs/switches/lan/c9000/qos/quality-of-service-configuration-guide.html

·     Cisco IOS XE Quality of Service Configuration Guide, Quality of Service chapter: https://www.cisco.com/c/en/us/td/docs/switches/lan/c9000/qos/quality-of-service-configuration-guide/m-quality-of-service.html

·     Cisco Catalyst 9300 QoS queue buffer allocation command reference: https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9300/software/release/17-18/configuration_guide/qos/b_1718_qos_9300_cg/configuring_qos.html#queue_buffer_allocation

·     Cisco Catalyst Center User Guide, Configure Application Policies: https://www.cisco.com/c/en/us/td/docs/cloud-systems-management/network-automation-and-management/catalyst-center/3-2-x/user-guide/cisco-catalyst-center-user-guide-3-2-x/m_configure-application-policies.html

·     Cisco Meraki Documentation, QoS Configuration: https://documentation.meraki.com/Switching/MS_-_Switches/Operate_and_Maintain/How-Tos/QoS_(Quality_of_Service)