Nokia QoS: QoS policy configuration and service-level enforcement

Scope

This domain tests how policies are actually attached and enforced: SAP ingress/egress policies, network QoS policies, scheduler and slope policies, port schedulers, and subscriber-level SLA enforcement.

Core rules

• A SAP ingress QoS policy is applied to a SAP with sap-ingress <policy>; a SAP egress policy with sap-egress; a network QoS policy to a network interface or SDP.
• Scheduler policies attach to a port, channel or SAP; the port scheduler attaches to the port and defines the available bandwidth and priority levels.
• A slope policy is attached to a queue or to the policy's queue definition; without it, default WRED or tail drop applies.
• H-QoS for subscribers uses scheduler-tiers plus a subscriber SLA profile (sla-profile) that references ingress/egress QoS and scheduler policies.
• Policy changes do not take effect until the policy is re-applied, and some changes require a SAP/interface bounce; always verify with show qos ... and show service sap ....
• Default policies are permissive; a missing explicit policy usually means best-effort treatment.

Worked example

A BNG subscriber has a 100M sla-profile with a tier-1 shaper, a tier-2 scheduler for voice, and a SAP ingress policy that meters peer-to-peer to 10M. The sla-profile is applied to the subscriber's SAP. Traffic above 100M is shaped at tier 1; P2P above 10M is marked out and WRED-dropped first. The port scheduler still arbitrates among all subscribers.

Traps

• Configuring a policy but never attaching it to the SAP/interface.
• Forgetting to reference the scheduler policy from the port or SAP, so default scheduling applies.
• Assuming sla-profile alone enforces bandwidth without a scheduler hierarchy.
• Changing a policy and expecting instant effect without checking the operational state.