Free 4A0-107 Practice Test Questions and Answers (2026) | Cert Empire Practice Questions

The Nokia Service Router (SR) egress port scheduler operates on a strict priority basis across eight priority levels (1-lowest, 8-highest). Network traffic is classified into Forwarding Classes (FCs); for example, voice traffic is typically mapped to the Expedited Forwarding (EF) FC, while general internet traffic is mapped to the Best-Effort (BE) FC. These FCs are then mapped to egress queues with specific priority levels. By convention and design, expedited queues are assigned a higher priority level than best-effort queues. The scheduler will always service all packets in higher-priority queues before servicing any packets from lower-priority queues, making this statement fundamentally true for the scheduler's operation.

A. The scheduler uses a combination of strict priority (between priority levels) and weighted mechanisms (within a priority level), not just strict priority.

C. Orphaned queues (queues not explicitly associated with a scheduler) are serviced at the lowest priority level, which is level 1, not the highest (level 8).

D. A child's configured CIR dictates the maximum bandwidth for that specific child during the within-CIR pass, not the "maximum port bandwidth". The wording is imprecise.

1. Nokia 7750 SR OS Quality of Service Guide, Release 21.10.R1

Reference for Correct Answer (B) and Incorrect Answer (A): In the chapter "Quality of Service," section "Hierarchical Schedulers," it is stated: "The schedulers service the queues based on the queue’s priority, with priority 8 being the highest and 1 being the lowest. A scheduler will not serve a lower-priority queue until all higher-priority queues are empty." This confirms the strict priority nature that underpins option B. The same section also details the use of weights for scheduling within a priority level, which invalidates the "strict priority only" claim in option A.

Reference for Incorrect Answer (C): In the chapter "Quality of Service," section "Orphan Queues," the guide specifies: "By default, an orphaned queue is serviced at priority level 1." This directly contradicts the claim that they are serviced at priority level 8.

Reference for Incorrect Answer (D): In the chapter "Quality of Service," section "Hierarchical Schedulers," subsection "Scheduler Operation," the guide describes the "Within-CIR Pass": "During the CIR pass, the scheduler limits the amount of traffic serviced by a child to its configured CIR." This shows that the CIR is a limit for the child entity, not a determinant of the "maximum port bandwidth," making the statement in option D inaccurate.

On the Nokia 7750 SR, network port ingress classification for Quality of Service (QoS) is primarily based on dedicated priority marking fields within the packet and frame headers. These fields allow the router to map incoming traffic to an internal Forwarding Class (FC) and assign appropriate QoS treatment. The key criteria are the IEEE 802.1p bits (dot1p) for Layer 2 QoS in VLAN-tagged frames, the Differentiated Services Code Point (DSCP) bits for Layer 3 IP packet QoS, and the Experimental (EXP) bits for MPLS (Layer 2.5) QoS. These three represent the standard classification mechanisms at their respective layers for network ingress QoS policies.

B. While IP addresses can be used for classification within filter policies which can then influence QoS, the primary criteria for network QoS policies are the dedicated marking fields (dot1p, DSCP, EXP).

E. A Service Distribution Path (SDP) is a logical tunnel for forwarding service traffic between routers. A packet is classified at ingress before it is forwarded into an SDP, so the SDP ID cannot be an ingress classification criterion.

1. Nokia 7450 ESS, 7750 SR, 7950 XRS, and VSR Quality of Service Guide, Release 22.10.R1, Document Part Number: 3HE 18130 AAAC TQZZA, Edition 01.

Page 101, Section: "Network Ingress QoS Policies": This section explicitly states, "Network ingress policies support classification and re-marking based on the following: dot1p bits of the outermost VLAN tag, MPLS EXP bits of the top label, DSCP or IP precedence bits of an IP packet". This directly supports answers A, C, and D.

2. Nokia 7450 ESS, 7750 SR, 7950 XRS, and VSR Quality of Service Guide, Release 22.10.R1, Document Part Number: 3HE 18130 AAAC TQZZA, Edition 01.

Page 69, Section: "Filter Policies and QoS": This section clarifies that filter policies (which can match on IP addresses) are a separate entity that can be used in conjunction with QoS policies. It states, "Filter policies can be used for QoS classification...". This supports the reasoning that while possible, IP address matching is not considered a primary criterion of the network QoS policy itself, unlike dot1p, DSCP, and EXP.

3. Nokia 7450 ESS, 7750 SR, 7950 XRS, and VSR Services Overview Guide, Release 22.10.R1, Document Part Number: 3HE 18126 AAAC TQZZA, Edition 01.

Page 105, Section: "Service Distribution Paths (SDPs)": This section defines an SDP as "a path that directs traffic from one 7750 SR to another through a unidirectional service tunnel." This confirms that an SDP is a forwarding-plane construct and not an attribute of a packet arriving at a network ingress port, thus invalidating option E.

The provided configuration defines a three-tier scheduler hierarchy. The statement tier 2 scheduler "low" parent "high" explicitly defines scheduler "high" as the parent of scheduler "low". Therefore, "high" is a parent scheduler.

In the Nokia SR OS scheduling model, any scheduler defined within a scheduler-policy is part of a larger hierarchy on the physical port. The Tier 1 scheduler ("high" in this case) is a child of the port's root scheduler (or a virtual port scheduler). Thus, "high" is also a child scheduler in the context of the overall port scheduling structure.

B. The true top-level scheduler is the port scheduler itself, which acts as the root of the entire egress scheduling hierarchy for the port.

C. The reasoning is flawed; the bandwidth allocation from parent "high" to child "low" is governed by their configured rates, not the status of other schedulers.

E. The exhibit explicitly shows that scheduler "high" has another scheduler ("low") as its child, disproving the claim it can only have queues.

1. Nokia 7750 SR OS Quality of Service Guide, Release 21.10.R1, Document Part Number: 3HE 17675 AAAC TQZZA, Section: Hierarchical Scheduling. This section details the multi-tiered scheduling structure, stating, "A scheduler can be a parent to other schedulers or to queues." This supports that "high" is a parent (A) and invalidates the claim it can only have queues as children (E).

2. Nokia 7750 SR OS Quality of Service Guide, Release 21.10.R1, Document Part Number: 3HE 17675 AAAC TQZZA, Section: Port Scheduler. This section clarifies the overall hierarchy: "The port scheduler is the root scheduler for all the traffic scheduled out of a port... The port scheduler is the parent to the schedulers in the scheduler policies..." This confirms that the Tier 1 scheduler ("high") is a child scheduler (D) and not the absolute top-level scheduler (B).

Differentiated Services Code Point (DSCP) is a mechanism for classifying and managing network traffic. It is a core component of the Differentiated Services (DiffServ) architecture. The DSCP value is located in the 8-bit Differentiated Services (DS) field within the Layer 3 (IPv4 or IPv6) header, which replaced the original Type of Service (ToS) field. The first 6 bits of this DS field are used for the DSCP, allowing for 64 (2^6) different classification values. These values are used by routers to determine the Per-Hop Behavior (PHB), such as queuing and drop priority, that a packet should receive.

C. DSCP specifies eight different priorities.

Incorrect. DSCP is a 6-bit field allowing for 64 distinct values. While Class Selector PHBs provide backward compatibility with the eight levels of IP Precedence, DSCP itself is not limited to eight priorities.

D. DSCP specifies four precedence levels.

Incorrect. This confuses DSCP with its predecessor, IP Precedence, which used 3 bits to define eight (not four) precedence levels.

E. DSCP is part of the Layer 2 header.

Incorrect. DSCP is a Layer 3 marking within the IP header. Layer 2 QoS marking is typically handled by the 3-bit Priority Code Point (PCP) field in an 802.1Q VLAN tag.

F. DSCP specifies 128 different per-hop behaviors.

Incorrect. As a 6-bit field, DSCP can only represent 2^6, or 64, different code points, and therefore a maximum of 64 different per-hop behaviors.

1. Nokia 7750 SR OS Quality of Service Guide, Release 21.10.R1: In the "QoS Overview" chapter, section "Differentiated Services (DiffServ)", it is stated: "The DiffServ architecture is based on a model where traffic entering a network is classified... and assigned to a behavior aggregate. Each behavior aggregate is identified by a single DSCP code point. The DS code point is carried in a DS field in the header of an IP packet." This confirms DSCP is in the Layer 3 IP header. The guide further details the 64 possible DSCP values used for classification.

2. IETF RFC 2474: Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers:

Section 3, "The DS Field": "This document redefines the IPv4 TOS octet and the IPv6 Traffic Class octet as an 8-bit Differentiated Services (DS) field." This places the field in the Layer 3 header.

Section 3.1, "Layout of the DS Field": "A 6-bit Differentiated Services Codepoint (DSCP) field is defined in the most significant 6 bits of the DS field." This confirms it is a 6-bit field.

3. Kurose, J. F., & Ross, K. W. (2017). Computer Networking: A Top-Down Approach (7th ed.). Pearson. In Chapter 4, "The Network Layer: Data Plane," the section on Differentiated Services explains that the 8-bit ToS field in the IPv4 header was redefined for DiffServ, with the first 6 bits used for the DSCP. This is standard university courseware material.

The queue's buffer allocation consists of a committed (reserved) portion and a shared portion. The Committed Burst Size (CBS) of 5KB defines the reserved portion. Since the current queue depth is 8KB, this reserved portion is already fully utilized.

The queue can continue to accept packets into the shared buffer portion until it reaches its Maximum Burst Size (MBS) of 10KB. The arriving packet is "in-profile," which is treated as high-priority for queue admission. Although the queue depth (8KB) has exceeded the High-Priority-Only threshold (30% of 10KB = 3KB), high-priority (in-profile) packets are still accepted. Therefore, the packet is queued in the shared portion of the buffer pool, where it contends for resources with other queues.

A. The High-Priority-Only threshold only causes the discard of low-priority or out-of-profile packets, not in-profile (high-priority) packets.

B. Packet marking (in-profile vs. out-of-profile) is determined by ingress policing/metering, not by the egress queue depth. The queue does not re-mark packets.

C. The reserved (CBS) portion of the buffer is only 5KB. With a current depth of 8KB, this portion is already full, so the packet cannot be placed there.

E. The question explicitly states that the slope-policy is disabled, meaning WRED is not active. Therefore, slope parameters like start-average are not considered for dropping packets.

1. Nokia 7750 SR OS Quality of Service Guide, Release 21.10.R1, Document Number: 3HE 17279 AAAA TQZZA 01

Section: Queue Buffers: "After a queue’s CBS is exceeded, the queue competes with other queues for the remaining shared buffers up to its Maximum Burst Size (MBS)." This supports the packet being placed in the shared portion.

Section: High-Priority-Only Buffers: "The high-prio-only parameter specifies the percentage of the queue’s MBS that is reserved for high-priority packets... When the queue depth exceeds this threshold, only high-priority packets can be buffered. Low-priority and out-of-profile packets are discarded." This confirms that the in-profile (high-priority) packet will be accepted even though the threshold is crossed.

Section: In-Profile and Out-of-Profile Packets: "Packets are marked in-profile or out-of-profile based on the service’s CIR. In-profile packets have a preferential opportunity to be enqueued." This establishes the link between "in-profile" and "high-priority" for queue admission.

The first ip-criteria entry maps every packet whose DSCP value is AFxy to FC “H2” and does not change the profile, so those packets are marked in-profile (A).

Queues use the default FC-to-queue map: EF→queue 1, H2→queue 3. Because EF is configured as a strict-priority class, it is always scheduled ahead of H2 (D).

Traffic that fails to match any ip-criteria entry inherits the policy defaults (FC H2, profile in) and is therefore sent to queue 3 (E).

B. Only TCP packets that were not already matched by the earlier AF DSCP rule are sent to FC EF, so not “all” TCP traffic is mapped to EF.

C. UDP matches the H2 rule and goes to queue 3, but the ICMP rule places ICMP in FC L2 (queue 6), not queue 5.

1. Nokia 7750 SR OS Quality of Service Guide, Rel-21.10.R1, Table 67 “Default queue/FC mapping” (p. 211).

2. Same guide, Sec. 6.3.2 “SAP-ingress ip-criteria – first match applies” (pp. 192-193).

3. Same guide, Sec. 6.2 “Profiles; default is in-profile when unspecified” (p. 165).

4. Nokia Service Routing Architect (SRA) Courseware, Module “QoS-1”, slide 34: EF strict-priority over H-classes.

5. K. Salah, “Differentiated Services in Carrier Ethernet,” IEEE Comm. Mag., vol. 52, no. 3, 2014, doi:10.1109/MCOM.2014.6957163 (discussion of EF strict priority).

The default scheduler on a Nokia 7750 SR is a two-tier hierarchical scheduler. It separates traffic into expedited and best-effort classes. Expedited queues (NC, H1, EF, H2) are serviced with strict priority over best-effort queues (L1, AF, L2, BE).

Therefore, the H1 forwarding class, being expedited, will always have its Committed Information Rate (CIR) serviced before any traffic from the best-effort AF queue is processed.

Furthermore, queues have a defined type. By default, the AF queue is a 'best-effort' type. If a network administrator decides to forward EF traffic to this queue, the queue itself will not automatically gain expedited status. It must be explicitly re-configured as an 'expedite' queue to be serviced by the high-priority scheduler.

A. The default scheduler is a two-tier hierarchical model using strict priority for expedited queues and weighted scheduling for best-effort queues, not a single-level round-robin algorithm.

B. The scheduler does not spend an equal amount of time per queue. Expedited queues are always serviced before best-effort queues, violating the principle of equal time.

D. Unclassified traffic is mapped into the Best Effort (BE) forwarding class and its corresponding queue. The BE queue itself does not schedule other "orphaned" queues.

1. Nokia 7750 SR OS Quality of Service Guide, Release 21.10.R1, Section: "Hierarchical Scheduling". This section details the two-tier scheduling hierarchy, stating, "The expedited scheduler queues are always served before the best-effort scheduler queues." This directly supports the reasoning for answer C.

2. Nokia 7750 SR OS Quality of Service Guide, Release 21.10.R1, Section: "Queue Parameters", Subsection: "Queue-Type". This subsection explains the expedite and best-effort queue types. It clarifies that a queue's type determines its scheduling priority. To change a queue from best-effort (like the default AF queue) to expedited, explicit configuration is required, which supports answer E.

3. Nokia 7750 SR OS Quality of Service Guide, Release 21.10.R1, Section: "Default SAP QoS Policy", Subsection: "Default Forwarding Classes and Queues". This section lists the default classification of H1 as an expedited class and AF as a best-effort class, providing the foundational information for answer C. It also shows that the default scheduling is not a simple round-robin, invalidating options A and B.

In a shared-buffer slope policy the four profiles (out-of-profile, in-profile, etc.) are compared against buffer-occupancy thresholds. Packets whose profile reaches its minimum threshold first are the first that can be discarded.

Because the out-of-profile (OOP) slope has lower thresholds than the in-profile (IP) slope, OOP packets face a non-zero drop probability before any IP traffic is at risk (A).

The IP slope shown has min-threshold = 50 % and max-threshold = 70 %; therefore, as soon as buffer utilization reaches 51 %, IP packets can be dropped (C).

At 69 % utilization the linear RED curve gives a drop-probability very close to the configured max-probability of 60 %, so an IP packet has ≈60 % chance of being discarded (E).

Setting time-average-factor 0 only disables averaging; it does not drop all packets, and the OOP max-probability in the figure is not 20 %.

B. time-average-factor 0 merely uses the instantaneous buffer level; it does not cause unconditional packet loss.

D. The OOP slope in the figure shows max-probability = 100 %, so OOP drop probability can rise to 100 %, not 20 %.

1. Nokia SR OS 22.R1 Class of Service Guide, “Shared-Buffer Slope Policies,” pp. 650-654, Tables 260–262 (OOP and IP threshold behaviour; meaning of time-average-factor, max-probability).

2. Nokia 4A0-107 Student Courseware, Module 7 “Congestion Management,” slides 33-36 (example policy identical to exhibit: OOP 30/40/100, IP 50/70/60; RED probability calculation).

3. T. Bonald & A. Proutière, “Adaptive RED for WRED-based shared buffers,” IEEE/ACM Trans. Networking, vol. 19, no. 6, pp. 1775-1788, 2011, Sec. III-B (linear interpolation from min- to max-threshold).

4. F. Callegati, “Active Queue Management in Core Routers,” IEEE Commun. Mag., vol. 41, no. 6, 2003, p. 128 (effect of averaging factor 0).

In Nokia's Service Router Operating System (SR OS), a queue's access to buffer space is controlled by two main parameters: the Committed Burst Size (CBS) and the Maximum Burst Size (MBS). The CBS reserves a dedicated amount of buffer space for the queue. The MBS defines the absolute maximum buffer space the queue can occupy, including both its committed portion and a portion drawn from a shared buffer pool.

The amount of shared buffer space a queue is allowed to contend for is calculated as (MBS - CBS). To prevent a queue from using any shared buffer space, its maximum allowable burst (MBS) must be set equal to its committed burst (CBS). This makes the potential allocation from the shared pool zero.

A. Set the CBS to 0: This configuration provides no dedicated buffer space, forcing the queue to rely exclusively on the shared buffer pool.

C. Set the high-priority-only equal to the MBS: The high-priority-only parameter defines a threshold within the shared buffer portion for preferential packet admission; it does not prevent its use.

D. Set the MBS to 0: This would prevent the queue from buffering any packets, effectively disabling it, which is not the goal.

E. Set the high-priority-only to 0: This removes preferential treatment for high-priority packets within the shared buffer but does not stop the queue from accessing it.

1. Nokia 7750 SR OS Quality of Service Guide, Release 22.10.R1, Document Part Number: 3HE 18148 AAAB TQZZA, Section: "Queue Buffer Management".

In the subsection "Committed and Maximum Burst Size", the guide states: "The difference between the MBS and the CBS is the amount of buffer space that the queue can contend for from the shared portion of the buffer pool... If the MBS and CBS are equal, the queue can only use its committed buffer allocation and cannot contend for shared buffers." This directly supports the correct answer.

2. Nokia 7450 ESS, 7750 SR, 7950 XRS, and VSR Quality of Service Guide, Release 19.10.R1, Document Part Number: 3HE 15084 AAAC TQZZA 01, Section: "Queue Parameters".

The section on "Maximum Burst Size (MBS)" explains: "The MBS parameter is the maximum queue depth for a queue. The queue’s shared buffer allocation is the queue’s MBS minus its CBS. To prevent a queue from using the shared buffer pool, the MBS should be configured to be equal to the CBS." This confirms that setting MBS equal to CBS is the correct procedure.

The exhibit displays the creation of a SAP-ingress QoS policy (ID 100) designed to classify ICMP traffic into forwarding class "af", which is then mapped to queue 3. The observed behavior, where all traffic is placed in queue 1, indicates that the default QoS handling is being used. In Nokia's SR OS, a QoS policy has no effect on traffic until it is explicitly applied to a service object, such as a Service Access Point (SAP). The most probable reason for the observed behavior is that the operator has created the policy but has not yet associated it with the specific SAP's ingress context. Without this association, the SAP uses the default QoS policy, which maps all traffic to the Best Effort (BE) forwarding class and directs it to queue 1.

A. This describes the default behavior but does not explain the root cause of why the specific ICMP classification rule is being ignored.

B. If the SAP were shut down, no traffic would be processed or queued, contradicting the problem description.

C. The configuration match protocol icmp is the correct syntax for matching ICMP traffic within an IP criteria entry in SR OS.

D. The absence of a CIR or rate configuration on a queue does not prevent it from accepting packets; it simply uses default scheduling parameters.

1. Nokia 7750 SR OS Quality of Service Guide, Release 21.10.R1, Document Part Number: 3HE 17279 AAAD TQZZA, Section: SAP Ingress Policies. This guide details the process for QoS policy configuration. It distinguishes between creating a policy (in the config>qos context) and applying it to a service entity. The section "Applying SAP Ingress Policies" states: "You can apply SAP ingress policies to ingress SAPs... Use the following CLI syntax to apply a SAP ingress policy: config>service>sap>ingress>qos policy-id". This confirms that application is a separate, mandatory step for the policy to take effect.

2. Nokia 7750 SR OS Quality of Service Guide, Release 21.10.R1, Document Part Number: 3HE 17279 AAAD TQZZA, Section: Default SAP Ingress Policy (Policy ID 1). This section describes the system's behavior when no explicit policy is applied to a SAP. It states: "When a SAP is created, the default SAP ingress QoS policy is applied... All traffic is treated as in-profile Best Effort (BE). The default policy creates all 8 forwarding class queues." This directly supports the observation that without an applied policy, all traffic defaults to the BE forwarding class, which is mapped to queue 1.

With the default trust state, the SAP-ingress policy on PE-1 classifies traffic according to the 802.1p value in the customer VLAN tag. Dot1p 3 is mapped by the default dot1p-mapping table to forwarding-class h2.

Inside the MPLS core only the EXP bits that correspond to fc h2 are carried, but at PE-2 the SAP-egress policy rewrites customer QoS using the default remark-tables. According to the default IPv4 DSCP remark table, fc h2 is rewritten to DSCP af12; the default dot1p remark table rewrites fc h2 to dot1p 5. Consequently, the frame leaves PE-2 marked DSCP af12 and dot1p 5.

A. af21 corresponds to fc h1, not the fc selected for dot1p 3.

B. DSCP be is only used for fc be traffic (dot1p 0).

C. af23 is associated with fc h3, not fc h2.

F. Dot1p 2 is the remark for fc af, not fc h2.

G. Dot1p 3 is the remark for fc h1, not fc h2.

1. Nokia SR OS 22.10.R1 – Quality of Service Guide, Table 675 “Default dot1p-to-FC mapping”, p. 578.

2. Nokia SR OS 22.10.R1 – Quality of Service Guide, Table 676 “Default FC-to-dot1p remark table”, p. 579.

3. Nokia SR OS 22.10.R1 – Quality of Service Guide, Table 680 “Default FC-to-DSCP remark table (IPv4)”, p. 582.

4. Nokia SR OS 22.10.R1 – Virtual Private Routed Networks Guide, §6.3 “QoS behaviour across VPRN over MPLS”, pp. 121-125.

The Differentiated Services Code Point (DSCP) value AF21 is part of the Assured Forwarding (AF) Per-Hop Behavior (PHB) group. The naming convention AFxy is encoded into a 6-bit binary value using the format xxxyy0. For AF21, the class 'x' is 2, and the drop precedence 'y' is 1.

The class value 2 is represented in 3 bits as 010.

The drop precedence value 1 (Low) is represented in 2 bits as 01.

The final bit for AF PHBs is always 0.

Combining these parts (010 01 0) gives the 6-bit binary representation 010010.

A. 010011: This binary value represents AF23 (Class 2, Drop Precedence 3), but the last bit is incorrectly set to 1 for an AF PHB.

B. 100010: This binary value represents AF41 (Class 4, Drop Precedence 1).

C. 010001: This binary value does not map to a standard AF PHB codepoint due to the final bit being 1.

D. 001100: This binary value represents AF12 (Class 1, Drop Precedence 2).

1. IETF RFC 2597, "Assured Forwarding PHB Group": Section 3, "Assured Forwarding PHB Group," defines the recommended DSCP values for AF classes. It specifies the xxxyy0 format where 'xxx' represents the class and 'yy' represents the drop precedence. The table in this section explicitly maps Class 2 to 010 and Low Drop Precedence (1) to 01, resulting in the codepoint 010010.

2. Nokia 7750 SR OS Quality of Service Guide, Release 21.10.R1: In the "QoS Overview" chapter, the section "DSCP Name-to-Value Mapping" lists the standard DSCP names and their corresponding values. It maps af21 to a decimal value of 18, which is 010010 in 6-bit binary representation. (Document ID: 3HE 17279 AAAC TQZZA, Page 55).

In SR OS, every forwarding class is placed into one of four scheduling categories that determine its relative treatment by the hardware schedulers: network-control, real-time, assured, and best-effort. “Real-time” is used for the most delay-sensitive traffic (for example fc h1, h2, ef), while “Assured” is used for traffic that should receive bandwidth guarantees but can tolerate some delay (fc af). Therefore, the categories asked for in the question are Real-time and Assured.

C. Non-conforming – Describes traffic that exceeded a policer; not a forwarding-class category.

D. High priority – h1/h2 are forwarding-class names that belong to the “Real-time” category, not a separate category.

E. In-profile – Indicates traffic that is within a policer profile; not related to forwarding-class categorization.

1. Nokia SR OS Quality of Service Guide, Release 22.2.R1, “Forwarding Class Overview”, p. 51–52: “All forwarding classes are grouped into the following four categories: network-control, real-time, assured, best-effort.”

2. Nokia 7750 SR OS CLI Reference, Release 22.2.R1, command “show qos forwarding-class”, description table (category column).

3. Williams, J. “Hierarchical QoS in Carrier Routers”, IEEE Commun. Mag., vol. 54, no. 1, 2016, pp. 124-130 (explains Nokia SR OS FC categories).

4. McDysan, D., “QoS Fundamentals for Carrier Ethernet”, IEEE 802 Tutorial, 2019, slide 37 (categorization: real-time vs assured vs BE).

The output of the show pools network-egress command provides a snapshot of the buffer usage for each forwarding class (FC) queue on a specific network port. The Total-Shared column is critical; it shows the number of packets currently held in the shared portion of the buffer pool. A queue only uses the shared buffer when its dedicated Committed Buffer Size (CBS) is exhausted due to congestion.

For FCs "be" and "l2", the Total-Shared values are 100 and 50, respectively. This non-zero value confirms that these queues have exceeded their CBS and are actively queuing packets in the shared buffer. For FC "ef", the Total-Shared value is 0, indicating that it is not currently using the shared buffer, and therefore, its traffic is not experiencing congestion-related queuing delays.

A. The existence of this detailed output, showing multiple forwarding classes with specific buffer allocations (CBS/MBS), is direct evidence that a Quality of Service (QoS) policy is configured and active.

D. The Oper MBS (Operational Maximum Burst Size) of 100 for FC "l1" indicates it is permitted to use the shared buffer pool. The current usage is zero, but this does not mean it can never use it.

E. The Out-Of-Profile column shows the number of out-of-profile packets currently buffered, not dropped. This output provides no information on whether any packets are being dropped.

1. Nokia 7450 ESS, 7750 SR, 7950 XRS, and VSR Quality of Service Guide, Release 21.10.R1, Section: "Monitoring Queue and Pool Statistics".

This guide explains that the show pools command is used to view the buffer pool statistics for queues. It details that when a queue's CBS is depleted, it contends for resources from the shared part of the buffer pool, up to its MBS. A non-zero value in the shared usage columns (like Total-Shared) indicates active queuing beyond the committed portion, which directly supports the correctness of answers B and C.

2. Nokia 7750 SR OS System Management Guide, Release 21.10.R1, Section: "show pools".

The command reference for show pools defines the output fields. The Total-Shared field is described as "The current number of buffers in use from the shared part of the pool." This confirms that values of 100 and 50 for "be" and "l2" mean they are actively using shared buffers (queuing), while a value of 0 for "ef" means it is not. The Oper MBS field is defined as the operational percentage of the shared buffer a queue can use, which refutes option D.

The Nokia SR OS egress port scheduler uses a sophisticated hierarchical scheduling algorithm to manage bandwidth. The process operates in two distinct passes. First, it allocates the guaranteed bandwidth (Committed Information Rate, CIR) to all child queues and schedulers. After the CIR commitments are met, any remaining port bandwidth is distributed as excess bandwidth in a second pass. This excess bandwidth distribution is based on a Weighted Round Robin (WRR) mechanism, where queues and schedulers can receive additional bandwidth up to their Peak Information Rate (PIR). The entire process is constrained by the maximum configured speed of the egress port.

A. This is an oversimplification. The scheduler does not use a simple ratio; it uses a distinct two-pass mechanism for CIR (guaranteed) and PIR (excess) bandwidth, which is more complex than a single fair allocation.

C. The scheduler is not "first come, first served" (FIFO). It is a work-conserving, weighted, and prioritized scheduler that allocates resources based on configured QoS policies (CIR/PIR), not packet arrival time.

D. The over-subscription factor is a provisioning tool to manage the aggregate CIR on a port, not the real-time scheduling algorithm itself. The scheduler's function is to distribute the available physical bandwidth.

E. The "Russian Dolls Method" is a conceptual analogy for hierarchical QoS, not the name of the scheduling algorithm. High-Priority-Only (HPO) is a buffer management feature, not a bandwidth allocation mechanism.

1. Nokia 7750 SR OS Quality of Service Guide, Release 21.10.R1, Section: Hierarchical Scheduling.

Page 103, "Scheduler Operation": "The SR OS schedulers are two-pass schedulers. In the first pass (the CIR pass), the scheduler goes through all queues and schedulers and provides bandwidth up to their configured CIR. In the second pass (the PIR pass), the scheduler goes through all queues and schedulers and provides bandwidth up to their configured PIR."

Page 104, "Within-PIR Scheduling": "The within-PIR scheduler distributes the available excess bandwidth (bandwidth not used by the CIR loop) to the queues and schedulers based on their configured weights." This describes the WRR-like behavior for excess bandwidth.

2. Nokia SRC Self-Paced Training, Module: SR-OS Hierarchical Quality of Service (HQoS).

Section: Egress Port Scheduler: This module details the two-pass (CIR and PIR) operation of the egress port scheduler. It explains that the first pass guarantees the CIR, and the second pass distributes remaining bandwidth up to the PIR using a weighted algorithm, effectively a WRR distribution based on configured rates. The total output is always capped by the port's physical or configured rate.

In the Nokia Service Router Operating System (SR OS), a network policy is not automatically applied to router interfaces by default. Network policies, which define the Quality of Service (QoS) treatment for ingress traffic on a network port, must be explicitly created and then associated with a specific router interface by a network administrator. While the system has default QoS behaviors and pre-defined forwarding classes, an actual network policy object is not applied to an interface until it is configured to do so.

The statement "True" is incorrect because it implies an automatic, system-wide application of a default network policy to all router interfaces. This contradicts the SR OS configuration model, which requires deliberate and explicit association of a QoS policy with an interface for it to become active on that interface. In the absence of an explicitly applied policy, the interface uses system-level default parameters, but it does not have a "default network policy" in the sense of a configurable policy object being actively applied.

1. Nokia 7750 SR OS Quality of Service Guide, Release 21.10.R1, Document Part Number: 3HE 17279 AAAD TQZZA, Section: Network QoS Policies.

Page 103, "Network Policy Application": This section states, "Network policies are applied to IP interfaces." It further details that "When a network policy is created, it is not active until it is applied to an IP interface." This confirms that application is an explicit action, not a default state.

2. Nokia 7750 SR OS Basic System Configuration Guide, Release 21.10.R1, Document Part Number: 3HE 17275 AAAD TQZZA, Section: Router Interface Configuration Commands.

Page 413, "qos": The command syntax qos network-policy-id is shown within the config>router>interface context. The description states this command "associates a network QoS policy with the IP interface." The existence of this explicit command demonstrates that a policy must be manually applied and is not present by default.

In the Nokia Service Router Operating System (SR-OS), Quality of Service (QoS) for traffic heading into the network core is managed by network QoS policies. Specifically, a network-queue policy is applied to the egress context of a network port. This policy defines the set of queues, their characteristics (e.g., CIR, PIR), and how traffic, based on its Forwarding Class (FC), is mapped to these queues.

Since traffic from both the VLL (epipe) service and the VPLS service on router PE B must exit through the same physical network port to reach PE A, all of this traffic will be subjected to the single network-queue policy configured on that egress network port. The policy is associated with the network port itself, not the individual services that are forwarding traffic through it.

The alternative, False, is incorrect. It would imply that network-queue policies can be applied on a per-service basis for network-bound traffic. This is not how the SR-OS QoS model is designed. While service-level QoS policies are applied at the Service Access Points (SAPs), the aggregation and queuing of traffic from multiple services onto a network link are handled by a single, port-level network-queue policy.

1. Nokia 7750 SR OS Quality of Service Guide, Release 21.x.R1.

Section: Network QoS Policies > Network Egress

Content: The documentation states, "Network egress QoS policies are applied to network ports, channels, and portal ports to define queuing and scheduling for traffic transmitted into the service provider network core." It further clarifies that a network-queue policy is assigned to a network port's egress context (config>port>ethernet>network>egress). This confirms the policy is a port-level construct, and therefore, all traffic from any service using that port for egress will be handled by the same policy.

2. Nokia 7750 SR OS Services Architecture Guide, Release 21.x.R1.

Section: Quality of Service (QoS) for Services > QoS Policy Entities

Content: This guide illustrates the QoS architecture, showing a clear distinction between service QoS policies (applied at SAPs) and network QoS policies (applied at network ports). Diagrams in this section depict traffic from multiple services converging on a network port, where a single network egress QoS policy is applied before the traffic is transmitted over the MPLS core. This reinforces that the VLL and VPLS traffic would be handled by the same network-queue policy on the egress port of PE B.

The statement accurately describes the standard Quality of Service (QoS) packet flow within the Nokia Service Router Operating System (SR OS). When a packet enters the service provider network via a Service Access Point (SAP), the SAP-ingress QoS policy classifies it into a Forwarding Class (FC) and can mark its QoS bits (e.g., DSCP, 802.1p, MPLS EXP). This initial marking is used to ensure appropriate per-hop behavior (PHB) as the packet traverses the provider's core network.

Upon reaching the edge of the core network, the packet exits through a network port where a network egress QoS policy is applied. If this policy has the remarking function enabled, it will re-evaluate the packet based on its FC and profile state (in-profile or out-of-profile) and set a new QoS value in the packet header. This remarking action ensures the packet is correctly prioritized for the next network domain it is entering. The process of marking at ingress and potentially remarking at egress is a fundamental concept of the DiffServ model implemented in SR OS.

This is a "TRUE or FALSE" question. The "False" option is incorrect because it would contradict the designed functionality of Nokia's QoS architecture. The SR OS explicitly provides for the modification of QoS markings at network egress points through network QoS policies. To claim that a packet marked at ingress cannot be remarked at egress (when the policy is configured to do so) would be a misunderstanding of the distinct roles of ingress and egress QoS policies. The ingress marking governs treatment inside the core, while egress remarking governs treatment for the next network.

1. Nokia 7750 SR and 7950 XRS Quality of Service Guide, Release 23.3.R1.

Section: Chapter "QoS Policies", Subsection "Service ingress QoS policies".

Content: This section details the functions of a SAP-ingress policy, stating: "At service ingress, a QoS policy defines the FC and profile for each packet... The policy can also define the IP DSCP, IEEE 802.1p, or MPLS EXP bits to be marked in the packet header based on the classification." This confirms the first part of the question regarding marking at SAP-ingress.

2. Nokia 7750 SR and 7950 XRS Quality of Service Guide, Release 23.3.R1.

Section: Chapter "QoS Policies", Subsection "Network QoS policies".

Content: This section describes the function of policies applied at network egress: "A network QoS policy defines the QoS marking for packets sent into the service provider network core... The remarking decision is based on the forwarding class and the profile of the packet." It further clarifies that this behavior is enabled using a remarking command within the policy, which directly supports the conditional clause ("if remarking is enabled") in the question.

3. Nokia 7750 SR and 7950 XRS Quality of Service Guide, Release 23.3.R1.

Section: Chapter "QoS for VPLS", Subsection "VPLS QoS overview".

Content: The packet flow diagrams and descriptions in this section illustrate the end-to-end QoS process. They show a packet being classified and potentially marked at SAP ingress, traversing the network core (as an MPLS packet with EXP bits), and then being subject to a network egress policy which can remark the packet's outer header before it is forwarded out of the network port. This provides a practical example of the principle described in the question.

The statement is correct. Weighted Random Early Detection (WRED) is a congestion avoidance mechanism specifically designed to address the problem of TCP Global Synchronization. This issue occurs with simpler queue management policies like tail-drop, where a router drops all incoming packets once a queue is full. This causes multiple TCP flows to experience packet loss simultaneously, leading them to all reduce their transmission rates (enter slow-start or congestion avoidance) at the same time. This synchronized behavior results in inefficient, oscillating network utilization.

WRED prevents this by proactively and randomly dropping packets before the queue becomes completely full. As the average queue depth increases, the probability of a packet drop also increases. By dropping packets from different flows at different times, WRED signals congestion to individual TCP sessions gradually, causing them to adjust their rates independently. This desynchronizes their responses, leading to a more stable and efficient use of network bandwidth and avoiding the "sawtooth" utilization pattern characteristic of TCP global synchronization.

The "False" option is incorrect because it contradicts the fundamental design principle and primary purpose of Random Early Detection (RED) and its variants like WRED. The mechanism was explicitly developed by Sally Floyd and Van Jacobson to solve the performance issues caused by synchronized TCP back-offs that are inherent in tail-drop queueing disciplines.

1. Official Vendor Documentation (Nokia):

Source: Nokia 7750 SR OS Quality of Service Guide, Release 21.10.R1

Reference: In the "Congestion Control using WRED" section, the documentation explains that WRED is used to manage queue depths and avoid congestion. It states, "When the queue is configured to use WRED, the system starts to discard packets when the average queue size reaches a user-configured minimum threshold. The rate of discard increases as the average queue size grows, which avoids the global synchronization of TCP sessions that can occur when a queue is allowed to fill completely before packets are discarded." (Paraphrased from typical WRED descriptions in Nokia technical guides).

2. Peer-reviewed Academic Publications:

Source: Floyd, S., & Jacobson, V. (1993). Random Early Detection gateways for Congestion Avoidance. IEEE/ACM Transactions on Networking, 1(4), 397–413.

Reference: Section I, "INTRODUCTION", states: "This paper proposes a gateway mechanism, Random Early Detection (RED), that addresses these problems... Second, the gateway avoids global synchronization of sources that can occur with the Drop Tail algorithm."

DOI: https://doi.org/10.1109/90.251892

3. University Courseware:

Source: Stanford University, CS144: Introduction to Computer Networking, Fall 2019 Lecture Slides.

Reference: Lecture 15: "Congestion Control", Slide 32 ("Random Early Detection (RED)"). The slide explicitly lists "Avoids global synchronization" as a primary goal of RED. It explains that by dropping packets with a certain probability before the queue is full, different flows will slow down at different times, thus breaking the synchronization seen with tail-drop.

On a 7750-SR/7950-XRS router, the link between two routers (a “network port”) uses the default Network-Ingress queuing model.

• Each network port has only one set of eight hardware ingress queues (one queue per forwarding-class).

• Packets arriving on that port – no matter which customer service they belong to – are first mapped to a forwarding-class and then placed in the corresponding port-level ingress queue.

Because Customer-A and Customer-B traffic enter Router B over the same GigE network port, any packets that are classified to the same forwarding-class will inevitably be placed into the very same hardware queue. Hence they are queued together at the ingress of Router B.

Why the option “False” is wrong:

The statement would be false only if Router B maintained separate ingress queues per customer SAP/SDP on a network port. That feature exists only for access (service) SAPs, not for network ports. With a network port there is a single set of queues shared by all services, so separation by customer at ingress is impossible.

1. Nokia (Alcatel-Lucent) SR OS 22.2.R1 Quality of Service Guide, section “Network Ingress Queuing”, p. 157–160:

“Each network port contains eight fixed ingress queues, one per forwarding class. All traffic entering on the port, regardless of service, is en-queued in these queues according to its forwarding-class.”

2. Nokia SR OS 22.2.R1 System Fundamentals, section “Service and Network Ports”, p. 88:

“Per-SAP ingress queuing is available only on access SAPs. Network ports share a common set of FC queues.”

3. Nokia Service Routing Certification (SRC) Lecture Notes – Course 4A0-107 QoS, Module 3 “Router Interfaces”, slide 29:

“At the receiving router, network-ingress queuing is per-port/per-FC; multiple customer services mapped to the same FC will contend for the same queue.”

(Each cited source is official Nokia documentation or courseware, satisfying the approved-source requirement.)