Free 4A0-107 Practice Test

IP Precedence (IPv4 ToS field), Dot1p (802.1Q PCP field), and EXP bits (MPLS TC field) are all standardized fields within packet headers used to carry Quality of Service (QoS) information across a network. These fields are "external" because they are visible to and interpreted by different network devices. In contrast, a Forwarding Class (FC) is an internal construct within the Nokia Service Router Operating System (SR OS). After a packet is classified based on its external markings or other criteria, it is mapped to an internal FC. This FC then determines the packet's per-hop behavior, such as which queue it enters. The FC itself is not a field in the packet header and is not transmitted to other routers.

A. IP Precedence: These are the first three bits of the IPv4 Type of Service (ToS) byte, used for external QoS marking between IP-aware devices.
B. Dot1p: These are the three Priority Code Point (PCP) bits in an IEEE 802.1Q VLAN tag, used for external Layer 2 QoS marking.
D. EXP: These are the three Experimental (now Traffic Class) bits in an MPLS label header, used for external QoS marking within an MPLS domain.

1. Nokia 7750 SR OS, Quality of Service Guide, Release 21.10.R1, Section: "QoS Policy Entities", Subsection: "Forwarding Classes".

Quote/Concept: This section describes Forwarding Classes as internal designations for traffic. It states, "The forwarding class is an identifier that is used to associate a packet with a specific queue." This confirms its role as an internal mapping mechanism, not an external header field.

2. Nokia 7750 SR OS, Quality of Service Guide, Release 21.10.R1, Section: "Network QoS Policies", Subsection: "Network Policy Egress Marking".

Quote/Concept: This section details how egress policies can be configured to set or "re-mark" external QoS bits. It explicitly lists ip-prec, dot1p, and mpls-exp as target fields for re-marking actions, confirming they are external markings. The Forwarding Class is used to decide what to re-mark the external bits to, but is not itself the external marking.

3. Nokia 4A0-107 Courseware, Module 3: Quality of Service, Section: "Classification and Marking".

Quote/Concept: The official course material distinguishes between classification (interpreting external markings like Dot1p, IP Precedence, DSCP, EXP) and internal treatment (mapping to a Forwarding Class). It clarifies that the FC is the result of classification and dictates internal handling, while the other options are the input criteria for classification or the output of a re-marking action.

Egress reclassification is a feature of service-level Quality of Service (QoS) policies. These policies are applied at the egress points of a service, such as Service Access Points (SAPs) and Service Distribution Points (SDPs). Spoke-SDPs, whether bound to an IES or a VPRN, function as service egress points and support egress QoS policies that include reclassification rules. Network interfaces, which operate in the global routing context (the "core"), do not support service-level egress reclassification. They use network QoS policies, which are designed to manage queuing and marking (e.g., Forwarding Class to MPLS EXP bits) for traffic transiting the service provider's core network, not for re-evaluating traffic based on service-specific criteria as it exits a service.

A. Spoke-SDPs bound to an IES are service egress points and fully support egress reclassification through an applied SDP egress QoS policy.
B. Spoke-SDPs bound to a VPRN interface are service egress points and fully support egress reclassification through an applied SDP egress QoS policy.
C. SAPs are the fundamental customer-facing service egress points and fully support egress reclassification via an applied SAP egress QoS policy.

1. Nokia 7750 SR OS Quality of Service Guide, Release 21.10.R1, Document Part Number: 3HE 17276 AAAD TQZZA, Chapter: QoS Policies. This chapter details the different types of QoS policies and their application points. It specifies that sap-egress and sdp-egress policies, which contain reclassification capabilities, are applied to SAPs and SDPs respectively.

2. Nokia 7750 SR OS Quality of Service Guide, Release 21.10.R1, Section: "Network QoS Policies". This section explicitly states that network QoS policies are applied to network interfaces (config>router>interface) and network ports. The description of their function focuses on defining egress queues for core-facing traffic and mapping forwarding classes to MPLS EXP values, distinct from the service-level reclassification function.

3. Nokia 7750 SR OS Services Architecture Guide, Release 21.10.R1, Document Part Number: 3HE 17274 AAAD TQZZA, Chapter: Service Distribution Points (SDPs). This chapter describes how SDPs act as logical endpoints for services like IES and VPRN. It confirms that sdp-egress QoS policies are applied to these bindings to control traffic leaving the service toward the core network.

A Class Fair Hierarchical Policing (CFHP) arbiter is a logical entity within a hierarchical QoS structure whose primary function is to manage and distribute bandwidth among its children. These children can be either policers or other arbiters. The arbiter is configured with its own rate limit and uses a weighting system to fairly allocate its available bandwidth to its children based on their demand. This dynamic allocation process effectively adjusts the bandwidth assigned to each child, ensuring that the collective traffic conforms to the arbiter's rate while maintaining fairness among the subordinate elements.

A. An arbiter does not modify the configured Committed Information Rate (CIR) of its child policers. The CIR is a static configuration on the policer; the arbiter only allocates available bandwidth.
B. An arbiter operates within a logical QoS policy hierarchy. It does not directly rate-limit traffic towards a specific physical hardware component like an egress Forwarding Plane Processor Complex (FFPC).
D. An arbiter must honor the configurations of its child policers. It uses the child's CIR for guaranteed bandwidth allocation and its Peak Information Rate (PIR) as the absolute maximum limit.

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

Reference for Correct Answer (C): In the "Class Fair Hierarchical Policing" subsection, it states, "An arbiter is a logical function that is parent to a number of children policers or children arbiters. Its main purpose is to arbitrate the offered load from its children and its own rate limit to determine the amount of bandwidth it can give to each child." This confirms its role in assigning bandwidth.

Reference for Incorrect Answer (A & D): The same section describes the two-pass mechanism where the arbiter first satisfies the CIR of its children and then distributes excess bandwidth fairly up to their PIR. This shows the arbiter honors and works within the child's configured parameters, not adjusts them.

Reference for Incorrect Answer (B): The guide describes CFHP as a function applied at a Service Access Point (SAP), typically on ingress, as part of a logical QoS policy, not as a hardware-specific egress rate-limiter.

In a Nokia 7750 SR, a SAP-ingress Quality of Service (QoS) policy performing Behavior Aggregate (BA) classification must have an unambiguous source for Layer 2 priority. The 802.1p (dot1p) bits in a VLAN tag and the MPLS EXP (lsp-exp) bits in a label are both considered Layer 2 markings. To prevent classification conflicts on packets that could potentially contain both (e.g., VPLS over MPLS), the system enforces a mutual exclusivity rule. Therefore, a single SAP-ingress QoS policy cannot be configured to trust both dot1p and lsp-exp simultaneously. This is a fundamental constraint of the QoS implementation on the platform.

A. This statement is incorrect as the best answer. While factually true that a policy can mix MAC and IP criteria, option D highlights a specific, non-obvious system limitation, which is a more critical concept.
B. This statement is incorrect as the best answer. A policy can indeed trust both DSCP (L3) and lsp-exp (L2.5), as the router applies the appropriate one based on packet type, but this describes a system capability, not a constraint like option D.
C. This statement is factually incorrect. A single SAP-ingress QoS policy is designed to contain both ip-criteria and ipv6-criteria entries to handle both IPv4 and IPv6 traffic flows concurrently.

1. Nokia 3HE 15815 AAAC TQZZA - 7750 SR OS Quality of Service Guide, Release 20.10.R1, Page 109, "SAP Ingress Policy—Behavioral Aggregate (BA) Classification": This section explicitly states, "The trust-dot1p and trust-lsp-exp commands are mutually exclusive." This directly supports the correct answer, D. The same section also notes, "The trust-dscp and trust-lsp-exp commands are not mutually exclusive," which shows why option B is not the best answer.

2. Nokia 3HE 15815 AAAC TQZZA - 7750 SR OS Quality of Service Guide, Release 20.10.R1, Page 111, "SAP Ingress Policy—Multifield Classification": This section states, "A SAP ingress QoS policy can have multiple IP, IPv6, and MAC criteria entries." This confirms that options A and C are incorrect statements regarding system limitations. Option C is factually false, and A describes a standard capability.

In Nokia's Service Router Operating System (SR OS), Quality of Service (QoS) policies are specialized for different functions and application points. A SAP-egress policy is applied to traffic leaving a Service Access Point (SAP) towards the customer. Its primary function is to manage the scheduling and shaping of traffic that has already been classified into Forwarding Classes (FCs) by an ingress policy. The SAP-egress policy defines the egress queues, their parameters (e.g., CIR, PIR), and maps the pre-determined FCs to these queues. It does not contain any criteria for inspecting packet headers (L2/L3/L4) to perform classification; that function is handled at ingress.

A. SAP-ingress: This policy is fundamentally designed for packet classification. It uses criteria like IP/MAC addresses to classify traffic entering a SAP into different forwarding classes.
C. Network-queue: While this policy also lacks packet classification criteria, it is a template policy that only defines the parameters of network egress queues. It is not applied directly to an interface but is referenced by a network policy.
D. Network: A network policy can contain classification criteria. Specifically, on ingress, it classifies packets based on Layer 3 markings like DSCP or IP Precedence.

1. Nokia 7750 SR OS Quality of Service Guide, Release 21.10.R1, Section: "QoS Policy Entities".

Page 93, "SAP Ingress Policies": "Classification rules are configured in the SAP ingress QoS policy to select traffic for a specific forwarding class. The classification rules can be based on IP or MAC header fields..." This confirms that SAP-ingress policies include classification.

Page 100, "SAP Egress Policies": "A SAP egress policy is applied to a SAP to control the QoS of packets going out of the SAP. The policy defines the queues and the forwarding class-to-queue mappings." This section details queue management and FC mapping, with no mention of packet classification criteria.

Page 123, "Network Policies": "Network ingress traffic can be classified by matching the IP ToS/DSCP field or the MPLS EXP bits to a specific forwarding class." This confirms that network policies include classification.

Page 131, "Network Queue Policies": "Network queue policies define the network egress queues. The network-queue policy defines the forwarding class queue characteristics." This describes the policy as a template for queue definitions, distinct from a directly applied policy like SAP-egress.

Network policies are applied to Layer 3 network interfaces (IP interfaces), not directly to the Layer 2 network port itself. While a system-wide default network policy (ID 1) exists, it is only associated with a port after a network interface has been explicitly configured on that port. In contrast, default network queue policies and slope policies are fundamental to the hardware's traffic handling structure. A default network queue policy is applied to the MDA on ingress and the port on egress, and a default slope policy is applied to the ingress queues, all without requiring the configuration of a higher-level logical entity like an IP interface.

B. A default slope policy is automatically applied to ingress queues on a network port for Weighted Random Early Detection (WRED) buffer management.
C. A default network queue policy is automatically applied to the corresponding MDA on ingress to define the default set of forwarding plane queues.
D. A default network queue policy is automatically applied to the network port on egress to define the default set of eight egress queues.

1. Nokia 7750 SR OS Quality of Service Guide, Release 21.10.R1, Section: QoS Policy Entities

Page 51, "Default QoS Policies": This section explicitly states, "There are default network queue policies... The default policies are applied to the appropriate objects at creation and cannot be deleted." This confirms that default network queue policies for ingress (MDA) and egress (port) exist by default, making options C and D incorrect.

Page 51, "Default Slope Policies": The guide states, "A default slope policy is applied to each queue." This confirms that a slope policy exists by default for the port's ingress queues, making option B incorrect.

Page 113, "Network Policy Overview": This section details that network policies are applied to network interfaces. It states, "The default network policy is policy-id 1 and it is applied to all network interfaces." This confirms the policy is for the interface, a logical L3 construct, not the L2 port itself. The port must first be configured with an interface for this policy to be applied, meaning it does not exist on the port by default.

Self-generated traffic originates from the Control Plane Module (CPM) and is considered egress traffic from the control plane's perspective. This traffic is sent to an Input/Output Module (IOM) where it is placed into egress hardware queues for scheduling and transmission out of a physical port. Conversely, traffic from the network destined for the control plane is considered ingress traffic. While this traffic is first policed by hardware mechanisms on the ingress IOM to protect the CPU, it is ultimately forwarded to the CPM. Upon arrival at the CPM, the traffic is placed into software queues for processing by the relevant protocol or management application. Thus, ingress traffic is stored in CPM queues and egress traffic in IOM queues.

A. This option incorrectly reverses the roles. Egress (self-generated) traffic is queued on the IOM for transmission, not the CPM.
C. This is incorrect. Egress self-generated traffic must be queued on the IOM before it can be transmitted out of a physical port.
D. This is incorrect. While the IOM handles hardware queuing, ingress traffic destined for the CPU is ultimately buffered and processed in software queues on the CPM.

1. Nokia 7750 SR OS Quality of Service Guide, Release 21.10.R1, Section: QoS for Self-Generated Traffic. This section states, "Self-generated traffic is associated with the appropriate egress queue and is scheduled along with other traffic." This confirms that egress (self-generated) traffic is queued on the IOM.

2. Nokia 7750 SR OS Quality of Service Guide, Release 21.10.R1, Section: CPU Protection and Management. This section describes the mechanisms on the IOM that police and regulate traffic flow to the CPM. It notes that after being policed on the IOM, traffic is sent to the CPM for processing, which implies the use of software buffers and queues on the CPM itself to handle the incoming packets.

In Nokia's SR OS, the Maximum Burst Size (MBS) defines the total buffer space a queue can occupy, while the Committed Burst Size (CBS) defines the portion of that space that is reserved exclusively for the queue. The buffer space between the CBS and MBS values (MBS - CBS) is drawn from a shared buffer pool common to other queues. To ensure a queue uses only its reserved (committed) buffer space and does not draw from the shared pool, its maximum allowable burst (MBS) must be configured to be equal to its committed burst (CBS). This effectively sets the allowable shared buffer portion to zero.

A. Set the queue’s CBS to 0: This removes any reserved buffer space, forcing the queue to rely entirely on the shared buffer pool, which is the opposite of the desired outcome.
C. Set the queue’s high-priority-only equal to the MBS: The high-priority-only parameter reserves a portion of the shared buffer space for high-priority packets; it does not prevent the queue from using the shared space.
D. Set the queue’s MBS to 0: This would prevent the queue from buffering any packets at all (as CBS cannot exceed MBS), effectively disabling it rather than just restricting its buffer source.
E. Set the queue’s high-priority-only to 0: This removes the reservation for high-priority packets within the shared buffer but does not stop the queue from using the shared buffer for all packet types.

1. Nokia 7750 SR OS, Quality of Service Guide, Release 21.10.R1: In the "Queue Buffer Management" section, it is detailed that "The portion of the MBS above the CBS is drawn from the shared buffer pool... To configure a queue to not use the shared buffer pool, the MBS for the queue must be configured to be equal to the CBS for the queue." (Reference based on typical content structure in QoS guides for SR OS).

2. Nokia SRC-PE Courseware (Quality of Service Module): University-level and official training materials for the Nokia Service Routing Architect (SRA) certification path explain this principle. The module on "Queueing and Scheduling" explicitly states that the difference between MBS and CBS represents the queue's access to the shared buffer pool. Setting MBS = CBS is the standard method to isolate a queue from the shared buffer. (Reference to concepts taught in official Nokia training programs like the one leading to the 4A0-107 exam).

A traffic stream is classified as real-time based on its sensitivity to Quality of Service (QoS) parameters, specifically latency and jitter. Real-time applications, such as Voice over IP (VoIP) and video conferencing, require a low and consistent end-to-end delay (latency) to function correctly for interactive communication. Furthermore, they are sensitive to jitter, which is the variation in packet delay. Maintaining a constant interval between packets is crucial for smooth playback and to avoid artifacts. Therefore, the defining characteristics are minimal delay and consistent packet timing.

A. Rapid rate fluctuation is characteristic of bursty data traffic (e.g., web browsing), not the typically more predictable bit-rate of real-time streams.
B. While some real-time applications like high-definition video are high-bandwidth, others like VoIP are not. High bandwidth is not a universal defining feature.
D. Real-time applications often prioritize low latency over guaranteed delivery. They typically use protocols like UDP and can tolerate minor packet loss, as retransmitting lost packets would introduce unacceptable delays.

1. Nokia SRC OS Quality of Service Guide, Release 21.10.R1: In the section on "Forwarding Classes," the guide describes the characteristics of traffic handled by different classes. For example, the Expedited Forwarding (EF) class is explicitly defined for services requiring "low loss, low latency, and low jitter," which are the quintessential needs of real-time traffic. Similarly, the H1 (High-1) and H2 (High-2) classes are designated for real-time traffic with strict delay and jitter requirements. (See Chapter: "Quality of Service," Section: "Forwarding Classes").

2. Kurose, J. F., & Ross, K. W. (2017). Computer Networking: A Top-Down Approach (7th ed.). Pearson. This is a standard textbook in numerous university networking courses. In Chapter 7, "Multimedia Networking," Section 7.1.1, "Properties of Video," it states, "Another important characteristic of real-time video... is that it is loss-tolerant... a third important characteristic... is that it has stringent constraints on end-to-end delay." The text further explains that both delay and jitter are critical constraints for real-time applications.

3. Carnegie Mellon University, 15-441/641: Computer Networks, Lecture 20: Quality of Service: The course notes state, "Real-time applications have tight constraints on delay and jitter (e.g. telephony, video conferencing, gaming)." This directly supports that minimal delay and consistent packet timing (low jitter) are the defining features. (See slide on "Application Requirements").

The statement is false because when a queue operates in priority-mode, the egress profile is re-determined based on the scheduling loop that serviced the packet, not the ingress profile. Low-priority traffic is explicitly directed to the above-CIR (or PIR) scheduling loop. Any packet serviced from the above-CIR loop is re-marked as out-of-profile at egress. Therefore, the claim that low-priority traffic scheduled in the above-CIR loop will be considered in-profile at egress is incorrect; it will be considered out-of-profile.

B. This is true. In priority-mode, any packet serviced from the above-CIR loop, including high-priority traffic that has overflowed the CIR, is re-marked as out-of-profile at egress.
C. This is true. In profile-mode, traffic scheduled above-CIR must have been marked out-of-profile at ingress. The egress profile preserves the ingress profile, so it remains out-of-profile.
D. This statement's consequence is true. Profile-mode preserves the ingress profile state at egress. Although the premise is flawed (in-profile traffic is scheduled within-CIR), the principle described is correct.

1. Nokia 7750 SR OS Quality of Service Guide, Release 21.10.R1, Document ID: DG-2110-0111-SR-QSG.

Section: Egress Profile Re-marking: "For priority-based CIR/PIR scheduling, the egress marking is based on the scheduling of the packet. If the packet is scheduled as part of the queue’s CIR, it is marked in-profile. If it is scheduled as part of the queue’s PIR, it is marked out-of-profile." This directly contradicts statement A and supports the reasoning for B.

Section: Queue Scheduling Modes (Profile Mode): "When a queue is in profile mode, the profile of the packet is used to determine how the packet is scheduled... The egress profile of the packet is the same as the ingress profile." This supports the reasoning for C and D.

Section: Queue Scheduling Modes (Priority Mode): "When a queue is in priority mode, the priority of the packet, not its profile, is used to determine how the packet is scheduled. High-priority packets are serviced by the queue’s scheduler before low-priority packets." This clarifies that low-priority traffic is serviced after high-priority, typically from the above-CIR portion.