Nokia QoS common mistakes
Nokia QoS · Understand the traps and how to avoid them.
Treating the QoS classification chain as a single step, so the candidate assumes a packet's DSCP or EXP value alone determines its final forwarding class and queue, and answers questions as if marking and classification were the same operation.
Most candidates come from a background where DSCP-to-queue mapping is one lookup. Nokia's model separates classification (assigning a forwarding class and profile at ingress via match criteria such as IP criteria, MAC criteria, or default classification) from marking (rewriting DSCP, EXP, or dot1p on egress). Because the terms sound interchangeable in casual reading, the distinction collapses.
What to do instead
Draw the pipeline explicitly for each scenario: ingress match criteria -> forwarding class + in/out profile -> queue selection -> scheduler/PIR/CIR treatment -> egress marking. Then answer each question by locating which stage it is actually asking about, and confirm whether the question says 'classification', 'marking', or 'queuing' before choosing.
Confusing the forwarding class with the queue and assuming a 1:1 fixed mapping, then picking an answer that says a given class always maps to a specific queue number regardless of configuration.
In Nokia's model the forwarding class is a label that indexes into a queue mapping, and the mapping from forwarding class to queue is configurable per port or per policy. Candidates who learned 'class = queue' from other vendors' documentation answer from memory instead of from the configuration logic.
What to do instead
State the rule in your own words: forwarding class is a classification result; the queue is chosen by the FC-to-queue map applied at egress. When a question supplies a mapping, use the supplied mapping. When it does not, answer in terms of the FC and note that the queue depends on the applied map.
Ignoring the in-profile versus out-of-profile distinction and treating a policer as if it simply drops all traffic above a rate, or treating a shaper as if it drops.
Candidates conflate policing with shaping and forget that Nokia policers typically mark out-of-profile and then let the scheduler or a subsequent action decide the treatment. The profile is a state carried with the packet, not an immediate verdict.
What to do instead
Memorise the two-part behaviour: the policer meters against CIR/PIR and sets the profile; the scheduler and queue then apply the profile-dependent treatment (for example, out-of-profile traffic is subject to a lower PIR or a discard threshold). When a question asks what happens to excess traffic, first ask whether a policer or a shaper is in the path.
Mixing up CIR and PIR semantics, especially assuming CIR is a guaranteed rate that is always schedulable independent of the port's total capacity or the sum of other queues' reservations.
CIR and PIR look like simple rate knobs, but their meaning depends on oversubscription and on how the scheduler allocates remaining bandwidth. Candidates answer as if CIR were an absolute reservation without checking whether the sum of CIRs exceeds the port rate.
What to do instead
For every rate question, write down the port capacity, the sum of CIRs, and the sum of PIRs. Then reason: CIR is the committed portion the scheduler tries to honour; PIR caps the maximum. If the sum of CIRs exceeds capacity, the guarantee cannot be met for all queues simultaneously, and the question is testing whether you notice that.
Assuming QoS policy changes take effect immediately on all traffic without considering where the policy is applied (ingress versus egress, SAP versus network port, subscriber versus interface level).
Nokia service-level enforcement attaches policies at specific attachment points, and the same policy applied at ingress versus egress produces different results because the classification and marking stages differ. Candidates who memorise a policy's contents but not its attachment point answer the wrong question.
What to do instead
For each policy question, first identify the attachment point named in the stem (ingress SAP, egress SAP, network ingress, subscriber profile). Then reason about which stages run there. If the stem does not name an attachment point, treat the answer as conditional and pick the option that states the dependency.
Treating mobile transport QoS as identical to fixed IP QoS and ignoring the mapping between radio bearer QoS parameters and the transport-layer DSCP/EXP treatment.
In mobile transport the QoS class identifier and allocation and retention priority from the radio layer must be mapped into transport marking and scheduling. Candidates who only studied fixed-router QoS miss the mapping step and answer as if the transport saw the radio parameters directly.
What to do instead
Build a two-column table: radio-side parameters (QCI or 5QI, ARP, GBR versus non-GBR) on the left, transport-side treatment (DSCP or EXP marking, forwarding class, queue, scheduler) on the right, with the mapping rule in the middle. Answer mobile questions by walking that mapping rather than by applying fixed-router defaults.
Reading monitoring output as if counters were end-to-end truth, for example concluding that a queue is healthy because its drop counter is zero, without checking whether traffic ever reached that queue.
Queue statistics are per-queue and per-direction, and a zero drop count can mean no drops or no traffic. Candidates also forget that policer out-of-profile counts and queue drop counts measure different things, so a clean queue counter can coexist with heavy policer marking.
What to do instead
Before interpreting any counter, establish the baseline: was there offered load, in which direction, at which attachment point. Then read the counters in pairs (offered versus dropped, in-profile versus out-of-profile) and state explicitly what a zero means in that context.
Diagnosing a QoS problem as a configuration error when the actual cause is a capacity or oversubscription issue, and vice versa, because the candidate stops at the first plausible cause.
Symptom patterns overlap: latency and jitter can come from a wrong queue mapping or from a congested uplink. Candidates who do not have a structured triage order jump to the configuration explanation because it is the one they studied most.
What to do instead
Use a fixed triage order: (1) verify offered load and link utilisation, (2) verify classification and marking at ingress, (3) verify queue mapping and scheduler rates, (4) verify policer profiles, (5) verify egress marking. State which step the evidence in the stem supports before selecting an answer.
Memorising default DSCP-to-forwarding-class tables as universal and applying them even when the question describes a non-default or custom mapping.
Defaults are easy to study and feel authoritative, so candidates treat them as invariants. Nokia platforms allow custom mappings, and exam questions often deliberately describe a custom map to test whether the candidate reads the configuration given in the stem.
What to do instead
Treat every default table as a fallback only. When a stem provides match criteria or a mapping, derive the result from the stem. When it does not, say 'with default mapping' in your reasoning and choose the answer that is consistent with defaults rather than asserting the default is always in force.
Answering assurance questions by naming a tool or command rather than describing what metric or evidence would confirm or refute the hypothesis.
Candidates prepare by memorising command names and feature names, which are easy to recall but do not answer 'how would you verify'. Assurance questions are usually testing the reasoning chain from symptom to measurement to conclusion.
What to do instead
For every assurance question, phrase the answer as: hypothesis -> metric that distinguishes it -> where that metric is collected -> decision rule. If an option names a tool without a metric or decision rule, it is usually the distractor.