Configuring MQC Support for IP Sessions

MQC on IP sessions is supported through the following interfaces, arranged by system:

• Cisco 10000 series systems
  • Physical Ethernet
  • .1Q, QinQ (unambiguous only)
• Cisco 7200 and Cisco 7300 series systems
  • Physical Ethernet
  • .1Q, QinQ (unambiguous only)
  • Nonqueuing MQC over ATM
  • ATM 1483 RBE and ATM routed permanent virtual circuits (PVCs)
  • Generic routing encapsulation (GRE) tunnel. Policy maps are not allowed on the session and tunnel simultaneously.
• Cisco 7600 series systems
  • Gigabit Ethernet with .1Q or QinQ subinterfaces
  • Routed bridge encapsulation (RBE)
  • Permanent virtual connection (PVC)

MQC is not supported on the following interfaces:

• Bridge-Group Virtual Interface (BVI)
• GEC
• Interfaces configured for Layer 2 Tunnel Protocol (L2TP) sessions (on L2TP Network Servers (LNS))

The following features and configurations are used on MQC on IP sessions:

• ISG policer for traffic classes

Note	Traffic classes are not supported on Cisco 7600 series systems.

You can create configurations to work on an IP session with multiple traffic classes, and with one or more of the traffic classes acting as a policer. ISG policer is retained for backward compatibility and is fully supported if you do not want to migrate to MQC now. Note that ISG policing is supported on traffic classes, but MQC is not supported for traffic classes.

An ISG session can be configured with the ISG policer (also called dynamic rate limiting) or MQC, but not both. You should either use the ISG policer or migrate fully to MQC. If you do not migrate fully from ISG policer to MQC, a misconfiguration will occur.

A policy map can be attached to one or more interfaces to specify a service policy. Configuration sources combined with context determines which QoS policy map is applied. The three configuration sources and their general order of precedence are as follows:

1. Per-user (per-subscriber) configuration
2. Service profile
3. Interface configuration

This order of precedence shows the general condition, that is, service profiles and per-user configurations have higher priority than interface configurations.

However, a change of authorization (CoA) per-user push replaces the current per-user configuration for any overlapping or common feature. Similarly, when a new service logs in, its configuration replaces any overlapping feature, from previously configured service profiles, that is not already in effect from a per-user configuration source

If the new service then logs off, the previously existing configuration is reapplied if no higher-precedence configuration source is in effect.

Given those precedence qualifications, the policy map is determined as follows:

• If there is no policy map on the session, the incoming policy map is not applied.
• If an existing policy map is configured from a higher priority source than an incoming one, the incoming policy map is not applied.
• If an existing policy map is configured from a lower priority source than an incoming one, the incoming policy map replaces it.

The inheritance rules on Cisco 10000 series systems for policies and queues from the parent interface are as follows:

• When a session that does not have a policy map starts, it inherits the policy and queues from the immediate parent that has a policy; for example, a subinterface or main interface.
• When a session with an inherited policy receives a policy from a RADIUS server, it first removes the inherited policy and then applies the policy from the RADIUS server.
• When a session that does not have a policy starts and its parent interfaces also do not have a policy but a policy is later attached to the parent, there are two possible outcomes:
  • The policy is attached to the main interface, and sessions directly on that interface inherit it. Sessions on subinterfaces under the main interface that do not have a policy of their own also inherit it.
  • The policy is attached to the subinterface, and sessions under that subinterface inherit it.
• When a user removes a policy from the parent interface, there are two possible outcomes:
  • The policy is removed from a subinterface and is uninherited from any sessions on the subinterface that inherited the policy from it. If the main interface has a policy, sessions on the subinterface from which the policy was removed inherit that.
  • The policy is removed from the main interface and is uninherited from the main interface and also from any sessions under its subinterfaces that inherited this policy.
• When a session that does not already have a policy receives one from the RADIUS server, you need only install the new policy. However when a session that already has a policy inherited from the parent receives a new one from the RADIUS server, you must first uninherit the parent policy and then install the new one.
• When a session policy is removed, the session inherits the policy from its nearest parent, subinterface, or main interface that has a policy.

1.    enable

2.    configure terminal

3.    policy-map type service service-name

4.    service-policy policy-name

For information about configuring a local service profile, see the section “Configuring Per-Session QoS Using the ISG Framework” in the "Configuring ISG Control Policies" chapter in the Cisco IOS Intelligent Services Gateway Configuration Guide.

1.    enable

2.    configure terminal

3.    policy-map type service service-name

4.    class type traffic class-name