Nested Policy-map

Policy-maps do indeed have the ability to be nested inside other policy maps. When we engage in this nesting behavior, we refer to the policy as a hierarchical policy. This is typically done to configure multiple treatments to QoS. For example – we might want to traffic-shape all traffic to 3 MB; and then inside that 3 MB shaped traffic, guarantee Web traffic at least 1 MB of bandwidth.

Remember, we use a service-policy (normally done with interfaces) to  assign the QoS policies that we define inside the policy-map.

With the nesting of policy maps, there are some restrictions that you should be aware of. For example:

  • The set command is not supported on the child policy
  • The priority command can be used in either the parent or the child policy, but not both
  • The fair-queue command cannot be used in the parent

Here is an example of nesting policy maps:

Verifying your policy-map, is very simple thanks to the following show commands:

show policy-map
show policy-map interface int_name
Share this!

SVI Policy Configuration

Here are the main points to keep in mind:

  • The configuration requires a nested policy-map
  • The policy-map applied to the SVI references another policy map that actually does the policing
  • Do not forget to enable vlan-based QoS on the appropriate range of ports
  • In the parent policy-map, you must perform some action (besides calling another policy map)

In order to configure policing on a Switched Virtual Interface (SVI or VLAN interface), here is a sample configuration:

Notice we set the DSCP value in the parent policy map in order to  meet the requirement of “performing some action!” Also remember, both of the sample configurations above require mls qos configured globally on the device.

Share this!