Configuring Mutation Mapping

This chapter describes how to configure the mutation of packet values used to define traffic classes on the Cisco NX-OS device.

Finding Feature Information

Your software release might not support all the features documented in this module. For the latest caveats and feature information, see the Bug Search Tool at https://tools.cisco.com/bugsearch/ and the release notes for your software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the "New and Changed Information"chapter or the Feature History table in this chapter.

Information About Mutation Mapping

Mutation mapping is a method of modifying a quality of service (QoS) field in all packets on an interface. On ingress, mutation mapping occurs before traffic classification and all other actions. On egress, mutation mapping occurs after traffic classification and before the other actions. You can apply mutation mapping to the class of service (CoS), Differentiated Service Code Point (DSCP), IP precedence packet fields, or to the internal field discard class.

You cannot configure system-defined mutation maps. You can only configure those maps that modify the same source and destination variable.

You use a hierarchical policy map to configure mutation mapping. In the mutation mapping policy map, you specify the field to mutate and the policy map to apply with the mutation.


Note


The device supports hierarchical policies only for mutation mapping.


The sequence of QoS actions on ingress traffic is as follows:

  1. Queuing and scheduling

  2. Mutation

  3. Classification

  4. Marking

  5. Policing

The sequencing of QoS actions on egress traffic is as follows:

  1. Classification

  2. Marking

  3. Policing

  4. Mutation

  5. Queuing and scheduling


Note


Mutation occurs much closer to the beginning of the traffic actions on the ingress packets, and any further classification and policing is based on the changed QoS values. Mutation occurs at the end of the traffic actions on the egress packets, right before queuing and scheduling.


Prerequisites for Mutation Mapping

Mutation mapping has the following prerequisites:

  • You must be familiar with the “Using Modular QoS CLI” section.

  • You are logged on to the switch.

  • You are in the VDC. A VDC is a logical representation of a set of system resources. You can use the switchto vdc command with a VDC number.

Guidelines and Limitations

Mutation mapping has the following configuration guidelines and limitations:

  • You use a hierarchical policy for mutation mapping. Hierarchical policies are not supported for any other use.

  • The device supports only one level of hierarchy.

  • You can configure up to 14 table maps for use in ingress interfaces and up to 15 table maps for use in egress interfaces.

  • Before you delete a referenced policy map, you must first remove all references to that policy map.

  • You can use only like parameters (for example, cos-cos) when you create a mutation map. Mutation maps with dissimilar types (for example, cos-dscp) are not supported.

  • On Layer 2 ports, hierarchial QoS policies are not applicable on ingress for Cisco Nexus M3 series modules.

Configuring Mutation Mapping

To configure mutation mapping, you create a hierarchical policy map that uses the class-default traffic class to capture all packets and apply mutation mapping to them. You use the service-policy command to specify the policy map to apply with mutation mapping.


Note


You can set only similar values when you create a mutation map. For example, you can set cos-cos or dscp-dscp; you cannot set cos-dscp or dscp-precedence.


To configure mutation mapping:

  1. Create the policy map to apply in the mutation mapping hierarchical policy. For information about configuring policy maps, see “Configuring Policing” or “Configuring Queuing and Scheduling.”

  2. Create the table map to use in the mutation mapping hierarchical policy. For information about configuring table maps, see the “Configuring Marking Using Table Maps” section.

  3. Configure the mutation mapping hierarchical policy as described in this section.

  4. Apply the service policy to the interface. For information about attaching policies to interfaces, see “Using Modular QoS CLI.”

Procedure

  Command or Action Purpose

Step 1

switch# configure terminal

Enters global configuration mode.

Step 2

switch(config)# policy-map [type qos] [match-first] {qos-policy-map-name | qos-dynamic}

Creates or accesses the specified policy map and then enters policy-map mode. The policy map name can contain alphabetic, hyphen, or underscore characters, is case sensitive, and can be up to 40 characters.

Step 3

switch(config-pmap-qos)# class class-default

Configures class-default to capture all traffic in this policy map.

Step 4

switch(config-pmap-c-qos)# set {cos | discard-class | dscp | precedence} {cos | discard-class | dscp | precedence} table table-map-name

Sets the first packet field to the value of the second packet field based on the mapping values in the specified table map. For mutation mapping, both fields must have the same value. The specified table map must already exist.

Note

 

You can only set same fields when in mutation mapping (for example, dscp-dscp).

The example shows how to use mutation mapping on the DSCP field based on the mapping values in table map dscp_mutation.

Step 5

switch(config-pmap-c-qos)# service-policy [type qos] {policy-map-name | qos-dynamic} [no-stats]

Defines the policy map to apply with the mutation map. The specified policy map must already exist and cannot contain a service-policy command.

Note

 

Classification within this service policy is based on the mutated value, not on the original value in the packet.

Note

 

The service-policy command can only be used for mutation mapping.

Step 6

(Optional) switch(config-pmap-c-qos)# show policy-map [type {qos | queuing}] [policy-map-name | qos-dynamic]

(Optional)

Displays information about all configured policy maps or the specified policy map.

Step 7

(Optional) switch(config-pmap-c-qos)# copy running-config startup-config

(Optional)

Saves the running configuration to the startup configuration.

Verifying the Mutation Mapping Configuration

To display the mutation mapping configuration information, perform the following task:

Command

Purpose

show policy-map [type {qos | queuing}] [policy-map-name | qos-dynamic]

Displays information about all configured policy maps or the specified policy map.

For detailed information about the fields in the output from these commands, see the Cisco Nexus 7000 Series NX-OS Quality of Service Command Reference.

Configuration Examples for Mutation Mapping

The following example shows how to configure a mutation:


Note


If the child service policy (in this example, child_qos_policy) is not configured in the parent policy map (in this example, parent_policy_for_mutation), all packets will be changed according to the mutation map.



class-map type qos match-all dscp0-12
  match dscp 0-12
  match protocol dhcp

class-map type qos match-all dscp13-63
  match dscp 13-60

table-map mutate_dscp
  default copy
  from 0 to 0
  from 1 to 1
  from 2 to 1
  from 63 to 46

policy-map type qos child_qos_policy
  class dscp0-12
   police cir 10 mbps bc 200 ms pir 20 mbps be 200 ms conform transmit exceed set dscp
dscp table cir-markdown-map violate drop
  class dscp13-63
   police cir 20 mbps bc 200 ms pir 40 mbps be 200 ms conform transmit exceed set dscp
dscp table cir-markdown-map violate drop
  class class-default
   police cir 5 mbps bc 200 ms conform transmit violate drop

policy-map type qos parent_policy_for_mutation
  class class-default
   set dscp dscp table mutate_dscp
   service-policy type qos child_qos_policy

Feature History for Mutation Mapping

Your software release might not support all the features in this document. For the latest caveats and feature information, see the Bug Search Tool at https://tools.cisco.com/bugsearch/ and the release notes for your software release.

Table 1. Feature History for Mutation Mapping

Feature Name

Release

Feature Information

No changes from Release 4.1(2)

5.1(1)

——

Mutation Mapping

4.1(2)

You can only use similar variables for mutation mapping.