Free 4A0-105 Practice Test Questions and Answers (2026)

The minimum network port MTU must accommodate the VPLS service-mtu plus all transport and encapsulation overhead. The calculation is as follows:
1. VPLS Service MTU: 9100 bytes (the customer payload).
2. MPLS Overhead: VPLS VC (inner) label: +4 bytes. MPLS transport (outer) label: +4 bytes. FRR facility mode label: +4 bytes (pushed onto the stack during reroute).
3. Network Port L2 Header: To find the minimum required MTU, we assume the encapsulation with the least overhead, which is untagged Ethernet (null encapsulation). This adds a 14-byte header (6-byte DMAC, 6-byte SMAC, 2-byte EtherType). Total Minimum Network MTU = 9100 + 4 + 4 + 4 + 14 = 9126 bytes.

A. 9100: This value incorrectly ignores all MPLS label and Layer 2 Ethernet header overhead required for transport across the network.
B. 9104: This value only accounts for a single 4-byte MPLS label and omits the other two labels and the Layer 2 header.
C. 9108: This value accounts for two MPLS labels but omits the third label for FRR and the 14-byte Layer 2 header.
D. 9122: This value (9100 + 8 bytes for two labels + 14 bytes for L2 header) correctly calculates the MTU for VPLS over MPLS without FRR, but the question explicitly requires FRR facility mode.

1. Nokia 7750 SR OS MPLS Guide, Release 21.10.R1, 3HE 17177 AAAA TQZZA 01, Section: "LSP Fast Reroute (FRR)", Subsection: "Facility Backup Method": This document describes the facility backup method for FRR, stating, "When a PLR using facility backup detects a failure... it pushes the label of the bypass tunnel onto the label stack of the packet." This confirms the addition of one extra 4-byte label during FRR activation.

2. Nokia 7750 SR OS Services Architecture Guide, Release 21.10.R1, 3HE 17179 AAAA TQZZA 01, Section: "VPLS", Subsection: "MTU Configuration": This guide explains that the network MTU must be large enough to accommodate the service payload (service-mtu) plus any additional headers for service and transport encapsulation. For a VPLS service transported over an MPLS SDP, this includes the VC label and the transport LSP label(s).

3. Nokia 7750 SR OS Interface Configuration Guide, Release 21.10.R1, 3HE 17174 AAAA TQZZA 01, Section: "Port Features", Subsection: "MTU": This guide defines the port MTU on Nokia routers as the Layer 2 frame size, including the MAC header but excluding the FCS. It also specifies the overhead for different encapsulations, with null (untagged) encapsulation adding a 14-byte header.

In SR OS, a management VPLS defines a “redundant spoke-SDP group” by listing the SDP-IDs that form the protected pair (or set). Any user VPLS that is provisioned with spoke connections that reference exactly those same SDP-IDs is automatically linked to that management VPLS; no extra statement is needed in the user service. Thus, the association mechanism hinges on matching SDP-IDs, not on service-ID, customer-ID, or explicit user-VPLS configuration.

A. Association is automatic; no directive is entered under the user VPLS itself.
C. Service IDs are unique per service but play no role in management-VPLS binding.
D. Customer IDs tag accounting/ownership data only; they are not used in spoke-SDP redundancy correlation.

1. Nokia SR OS 21.10.R1 Layer 2 Services Guide, “Redundant Spoke-SDP Using a Management VPLS,” §9.5.1, pp. 523–524: “User VPLSes are automatically associated when their spoke SDP bindings reference the same SDP IDs configured in the management VPLS.”

2. Nokia 7750 SR OS R12 Services Guide, Chapter “VPLS > Spoke-SDP Redundancy,” p. 340: “The association between a user VPLS and a management VPLS is accomplished through matching SDP IDs; no per-service configuration is required.”

3. Bocci, M. et al., “VPLS Service and Resiliency Techniques in Carrier Ethernet,” IEEE Communications Magazine, 46(11), 2008, p. 59. DOI:10.1109/MCOM.2008.4689246 (describes SDP-ID-based grouping in Alcatel-Lucent SR OS implementations).

In a Multi-Chassis Link Aggregation (MC-LAG) environment, the Customer Edge (CE) device is connected to two separate Provider Edge (PE) nodes. From the CE's perspective, these multiple physical links appear as a single standard Link Aggregation Group (LAG). The Link Aggregation Control Protocol (LACP), defined in IEEE 802.1AX, is the industry-standard protocol used to negotiate, maintain, and signal the status of the member links within this LAG. The two PE nodes coordinate their LACP system ID and states to present a unified LACP partner to the CE, ensuring seamless operation and failover.

A. MSTP is a Layer 2 loop prevention protocol (IEEE 802.1s) and is not used for signaling the status of links within a LAG.
B. MCLAG is the name of the high-availability architecture itself, not a specific signaling protocol used between the PE and CE.
D. DHCP is a Layer 3 protocol used for dynamic IP address assignment and is unrelated to Layer 2 link aggregation.
E. While the inter-chassis communication between the PE nodes in an MC-LAG group uses a proprietary protocol (ICCP), the communication with the CE uses the standard LACP to ensure interoperability.

1. Nokia 7450 ESS, 7750 SR, 7950 XRS, and VSR Layer 2 Services and EVPN Guide, Release 21.10.R1. Document ID: 3HE 17196 AAAC TQZZA. Section: "MC-LAG and LACP".

Quote/Paraphrase: The guide states, "The CE is connected to the two PE nodes with a regular LAG interface. The CE runs LACP with its peer (the MC-LAG group)... The PE nodes in an MC-LAG group must coordinate the LACP state. This is done over the ICCP channel." This explicitly confirms LACP is used for the PE-CE connection.

2. Nokia Data Center Fabric with SR Linux Cookbook, Release 21.6.1. Document ID: 3HE 17231 AAAB TQZZA. Section: "MC-LAG concepts".

Quote/Paraphrase: In the description of MC-LAG operation, it details that the CE device forms a standard LAG, typically running LACP, with the two upstream switches. The switches synchronize LACP information between them to act as a single logical LACP peer.

The VPLS OAM toolset provides mechanisms for fault detection and diagnostics. For topology discovery, oam mac-trace is used to trace the path for a specific MAC address across the VPLS network, identifying the sequence of PEs and the ultimate egress point (SAP or SDP). This directly discovers the forwarding path. The oam mac-populate command is also used for discovery. It advertises locally learned MAC addresses to all other PEs in the VPLS instance. By subsequently inspecting the Forwarding Databases (FDBs) on remote PEs, an operator can determine which PEs are active members of the service and have correctly learned the MACs, thereby discovering the VPLS service topology from a membership perspective.

A. oam mac-ping: This tool verifies reachability to a specific MAC address within the VPLS but does not trace the path or discover the network topology.
C. oamsvc-ping: This tool verifies the integrity and connectivity of the underlying service infrastructure (such as SDP bindings) between PEs, not the MAC-level forwarding topology.

1. Nokia 7750 SR OS Services Guide, Release 21.10.R1, "VPLS OAM" section.

Page 1008 (mac-trace): "The mac-trace OAM tool is used to discover the path from the ingress PE to the egress PE for a specific MAC address. The path is a list of Nokia 7750 SR nodes that the frame would traverse to reach the destination from the source." This explicitly defines mac-trace as a discovery tool.

Page 1008 (mac-populate): "The mac-populate OAM tool is used to populate the FDB of remote PE routers with the MAC addresses learned at the local PE router. This allows the remote PE routers to learn the MAC addresses before any data traffic is sent. This can be used to verify the VPLS service on the remote PE routers." This describes its function which, when combined with FDB inspection, serves as a topology discovery mechanism.

Page 1007 (mac-ping): "The mac-ping OAM tool is used to verify that a MAC address is learned by the VPLS service and displays the egress SAP or SDP on which the MAC is learned." This confirms its role as a verification, not discovery, tool.

2. Nokia Data Center and Cloud Networking (4A0-105) Student Guide, Module 4: Virtual Private LAN Service (VPLS).

Section: VPLS OAM: This section details the VPLS-specific OAM tools. It describes mac-trace for path discovery and mac-populate for populating remote FDBs, which is a key step in verifying and discovering the set of PEs participating in the service. It contrasts these with mac-ping, which is presented as a simple MAC reachability test.

The command vpls 9000 customer 6 create is used to instantiate a Virtual Private LAN Service (VPLS) on a Nokia router. The number immediately following the vpls keyword, which is 9000, serves as the service-id. This is a locally significant identifier for the service on the router. For VPLS signaling (using either LDP or BGP), a vc-id (Virtual Circuit ID) is required, which must be unique for a specific VPLS instance across all participating Provider Edge (PE) routers. In the Nokia SR OS, if the vc-id is not explicitly configured, it defaults to the service-id. Therefore, the value 9000 will be used as the vc-id by default, and it is a critical best practice to ensure this identifier is unique for this specific VPLS service across the network to prevent service conflicts.

A. The customer-id is explicitly defined by the customer 6 part of the command, making the customer ID 6, not 9000.
D. The vc-id defaults to the service-id (9000), not the customer-id (6). The customer ID is for administrative and billing purposes.
E. The egress vc-label is a 20-bit MPLS label allocated dynamically and signaled via LDP or BGP; it is not the service-id value itself.

1. Nokia 7750 SR OS Services Architecture Guide, Release 21.10.R1, Document ID: 3HE 17112 AAAC TQZZA 01

Section: VPLS Services > VPLS Service Overview: "A VPLS service is configured on each participating PE router with a service-id that identifies the VPLS service on the router." (This supports Answer B).

Section: VPLS Services > VPLS Management > VPLS IDs: "The VPLS ID (also referred to as the VC ID) is a unique value for a VPLS service that is used in the signaling... The VPLS ID must be the same on all PE routers for the same VPLS service." (This supports the reasoning for Answer C).

Section: VPLS Services > Service SDPs: "If a vc-id is not specified for a mesh SDP, the service-id of the VPLS is used." (This confirms that the service-id becomes the vc-id by default, reinforcing the importance of its uniqueness as stated in Answer C).

2. Nokia 7450 ESS, 7750 SR, 7950 XRS, and VSR Layer 2 Services and EVPN Guide: VLL and VPLS, Release 21.10.R1, Document ID: 3HE 17111 AAAC TQZZA 01

Section: VPLS Command Reference > Basic VPLS Configuration Commands > vpls: "Syntax: vpls service-id [customer customer-id] [name service-name] create". This command syntax explicitly shows that the number following vpls is the service-id and the number following customer is the customer-id. (This supports Answer B and refutes Answer A).

MAC explosion refers to a scenario in a large VPLS where a topology change (e.g., a link failure) forces Provider Edge (PE) routers to relearn a massive number of MAC addresses simultaneously. This mass relearning event, also known as a MAC move, is not instantaneous. During the reconvergence period, which can take several seconds for thousands of MACs, traffic destined for these addresses is treated as unknown unicast and is flooded across the VPLS network. This excessive flooding consumes significant bandwidth and can lead to packet loss. The extended convergence time and resulting packet loss/flooding directly impact service quality, potentially violating Quality of Service (QoS) and Service Level Agreement (SLA) guarantees for availability and performance.

B. When the Forwarding Database (FDB) limit is reached, the standard behavior for a VPLS PE router, including Nokia's implementation, is to flood frames with unknown destination MACs, not discard them.
C. This option is incorrect because its premise is flawed; frames are typically flooded, not discarded, when the FDB limit is reached. While flooding can also deny SLAs, the reason stated is wrong.

1. Nokia 7750 SR OS Services Architecture Guide, Release 21.10.R1, "VPLS MAC Learning and Forwarding" section.

Reference for A & D: The guide explains that following a topology change, a "MAC move" occurs. It states, "During the time it takes for the FDBs to reconverge, some flooding of traffic to the affected MAC address may occur." In a large VPLS with thousands of MACs, this period is extended, leading to excessive flooding, potential packet loss, and service disruption, which directly impacts SLAs.

Reference for B: The guide details FDB management, clarifying that when the FDB is full, "the 7750 SR floods any frames with a destination MAC address that is not in the FDB to all SAPs and SDPs in the VPLS instance." This directly contradicts the claim that frames are discarded.

2. Nokia Data Center Fabric with SR Linux, Solution Guide, "EVPN-VXLAN Bridging" section.

Reference for A & D: While this document focuses on EVPN, the underlying principles of MAC learning in a large Layer 2 domain are analogous. It discusses MAC mobility and the need for rapid updates to avoid "traffic black-holing or flooding," which underscores the performance and SLA implications of delayed MAC relearning in large-scale Layer 2 services. The time taken for this process is a critical factor affecting service continuity.

When the Forwarding Database (FDB) on a Nokia router's Layer 2 service reaches its configured size limit, the default behavior is to disable the learning of any new source MAC addresses on that service entity (e.g., SAP or SDP). This action prevents FDB overflow while maintaining existing forwarding operations. The frame that caused the table to become full, as well as subsequent frames, will still be forwarded based on their destination MAC address. If the destination is known, the frame is unicast; if unknown, it is flooded. The key outcome is the cessation of learning, not the dropping of traffic.

A. The frame is dropped. This is incorrect. Dropping frames is a specific security feature (e.g., port security) and not the default behavior when the FDB limit is reached.
B. The frame is always flooded. This is incorrect. Flooding is the result of an unknown destination MAC address lookup, not a consequence of the FDB being full for learning new source MACs.
D. The frame is discarded if the destination is unknown. This is incorrect. The standard Layer 2 forwarding principle for an unknown destination MAC is to flood the frame, not discard it.
E. More information is required to determine the fate of this new frame. This is incorrect. The default behavior for an FDB reaching its limit is a well-defined and predictable outcome in Nokia's SR OS, making it the most "likely outcome".

1. Nokia 7750 SR OS, Layer 2 Services and EVPN Guide, SR OS 21.10.R1, Document ID: DC211000111, Section: VPLS Configuration > MAC Learning Management.

The documentation describes the limit-mac-learning command. It states: "When the limit is reached, the 7750 SR generates a log message and stops learning new MAC addresses." This confirms that learning is disabled, but it does not mention that frames are dropped, implying forwarding continues.

2. Nokia 4A0-105 Courseware (derived from official Nokia training materials).

Module on Virtual Private LAN Service (VPLS) typically covers FDB management. It explains that when the MAC limit per-SAP or per-service is reached, no new MACs are learned, but traffic forwarding for existing entries and flooding for unknown destinations continues. This prevents a denial-of-service attack from exhausting FDB resources while allowing the service to remain operational.

In a Nokia Hierarchical VPLS (H-VPLS) architecture, frames from a customer-facing I-VPLS are encapsulated before being transported across the provider backbone B-VPLS. This encapsulation adds overhead. The service-mtu of the B-VPLS must be large enough to accommodate the maximum frame size from the I-VPLS plus this overhead. The overhead consists of a 4-byte Service Delimiting Tag (S-tag) and a 4-byte control word, totaling 8 bytes. Therefore, the maximum service-mtu for any attached I-VPLS is the B-VPLS service-mtu minus 8 bytes. Calculation: 9108 bytes (B-VPLS MTU) - 8 bytes (overhead) = 9100 bytes.

B. 9104 bytes: This incorrectly accounts for only the 4-byte S-tag overhead and omits the 4-byte control word.
C. 9108 bytes: This is incorrect as it fails to account for the necessary 8-byte encapsulation overhead required by the B-VPLS.
D. 9118 bytes: This is incorrect because the I-VPLS MTU cannot be larger than the B-VPLS MTU that must transport its frames.

1. Nokia 7750 SR OS Services Guide, Release 21.10.R1, "VPLS Services" Section: In the subsection on "Hierarchical VPLS (H-VPLS)", under "MTU Considerations in H-VPLS", the documentation states: "The B-VPLS service MTU must be at least 8 bytes larger than the I-VPLS service MTU to accommodate the S-tag and control word." This directly supports the calculation of 9108 - 8 = 9100. (Document ID: 3HE 17196 AAAD TQZZA, Page 457).

2. Nokia Data Center and Cloud-Native VPLS and EVPN Services Courseware (4A0-105 Student Guide): Module 3, "Hierarchical VPLS (H-VPLS)", discusses the MTU relationship between I-VPLS and B-VPLS. It explicitly details the addition of a 4-byte S-tag and a 4-byte control word when an I-VPLS frame is passed to the B-VPLS, requiring the B-VPLS MTU to be at least 8 bytes greater than the I-VPLS MTU.

Hierarchical VPLS (H-VPLS) introduces a two-tiered architecture to address the scaling challenges inherent in a flat, full-mesh VPLS. This model significantly enhances scalability by reducing the number of Service Distribution Paths (SDPs) and signaling sessions required in the network core. Management is simplified as the access and core networks are decoupled, meaning the addition of a new customer site only requires local configuration without altering the core mesh. Furthermore, H-VPLS optimizes bandwidth utilization by centralizing the replication of Broadcast, Unknown Unicast, and Multicast (BUM) traffic. An access device sends a BUM frame once to the core, which then handles replication to all other relevant nodes, thus reducing the load on access links.

B. Reduces the FDB size within a VPLS instance: This is misleading. While access nodes have smaller FDBs, the core nodes must still learn all customer MAC addresses, so the total FDB size for the service is not reduced.
E. Reduces the routing table size: This is incorrect because VPLS is a Layer 2 technology that operates using MAC address tables (FDBs), not Layer 3 IP routing tables.

1. Nokia 7750 SR OS Services Guide, Release 21.10.R1, Part: VPLS Services, Section: "Hierarchical VPLS": This document states, "H-VPLS provides a scalable solution for VPLS services... The H-VPLS architecture provides a mechanism to scale VPLS services by segmenting the VPLS network into a core (S-PE) and access (MTU-s) layer." This directly supports option A. The guide further explains how split-horizon groups on core PEs optimize BUM traffic handling, which supports option C. The simplified provisioning model described supports option D.

2. M. L. F. de Mello, L. H. M. K. Costa, L. F. R. C. Carmo and O. C. M. B. Duarte, "An analysis of VPLS scalability and a proposal of a hierarchical model," 2008 IEEE Network Operations and Management Symposium - NOMS 2008, Salvador, 2008, pp. 319-326, doi: 10.1109/NOMS.2008.4575149: This academic paper analyzes the scalability limitations of flat VPLS, particularly the quadratic growth of signaling sessions, and identifies the hierarchical model as the solution. Section IV, "Hierarchical VPLS," details how the architecture reduces signaling overhead (supporting option A) and optimizes BUM traffic replication (supporting option C), which are primary benefits.

A Service Distribution Path (SDP) on a Nokia router is a unidirectional tunnel used to forward service traffic between two Provider Edge (PE) routers. To establish a functional, bidirectional service like VPLS between two PEs, a transport path is needed in each direction. Therefore, a minimum of two SDPs must be configured: one from the first PE to the second, and another from the second PE back to the first. A single SDP is capable of carrying traffic for multiple services, so all five VPLS services can utilize this single pair of SDPs.

A. 5-one for each service. This is incorrect because a single SDP can transport traffic for multiple services. Creating a dedicated SDP for each service is not the minimum requirement.
C. 10-five in each direction. This is incorrect as it implies creating a dedicated pair of SDPs for each of the five services, which is not necessary for functionality and is not the minimum.
D. None of the above. This is incorrect because option B accurately states the minimum requirement based on the fundamental architecture of Nokia's service delivery model.

1. Nokia 7450 ESS, 7750 SR, 7950 XRS, and VSR Services Architecture Guide, Release 21.10.R1, Section: Service Distribution Paths (SDPs), Page 101: "An SDP is a unidirectional service tunnel between two 7x50 SRs... To provide a bidirectional service, two SDPs must be provisioned, one for each direction."

2. Nokia 7450 ESS, 7750 SR, 7950 XRS, and VSR Services Architecture Guide, Release 21.10.R1, Section: Service Distribution Paths (SDPs), Page 101: "Once an SDP is created, services can be mapped to the SDP. A single SDP can have multiple services mapped to it." This confirms that the five VPLS services do not require five separate SDPs.

3. Nokia Data Center and Cloud Interconnect (DCI) Solution Guide, Section: Service Distribution Path (SDP): "An SDP is a unidirectional entity that is configured on each participating PE router to provide a logical way to direct service traffic. For a service to be bidirectional between two routers, an SDP must be created from the first router to the second and from the second router to the first." This reinforces the need for a pair of SDPs for bidirectional communication.

The port 1/1/1 is configured in qinq mode, enabling it to process frames with either a single 802.1Q tag (S-tag) or two tags (an outer S-tag and an inner C-tag). The SAP 1/1/1:100. is configured within VPLS 2. The acts as a wildcard for the inner C-tag. Therefore, any frame arriving on port 1/1/1 with an outer (top) tag of 100, regardless of the inner tag's value, will be matched to this SAP and processed by VPLS 2. Consequently, the source MAC address of such a frame will be learned in the forwarding database (FDB) of VPLS 2.

A. While it is true that untagged frames will be dropped because no SAP is configured to match them, this describes a default behavior for unhandled traffic, not the function of a specifically configured service.
B. This statement is technically correct as a frame with tags 200.300 would match SAP 1/1/1:200.300 in VPLS 3. However, option E describes a broader rule involving a wildcard, a key QinQ feature likely being tested.
C. This is incorrect. The port is explicitly in qinq mode, and SAPs 1/1/1:100. and 1/1/1:200.300 are configured specifically to accept and process frames with two VLAN tags.
D. This statement is technically correct as a single-tagged frame with VLAN ID 500 would match SAP 1/1/1:500 in VPLS 1. Similar to option B, it describes a valid but specific case.

1. Nokia 7x50 SR OS Services Architecture Guide, R19.10.R1 (3HE15086AAADTQZZA 01), Section: "QinQ Access SAPs", Page 288.

This section details the configuration of SAPs on a port in qinq mode. It explicitly states: "The SAP is specified using the format port-id:s-tag.c-tag or port-id:s-tag. for double-

A Virtual Private LAN Service (VPLS) requires Provider Edge (PE) routers to emulate the functions of a traditional Layer 2 Ethernet switch. The three fundamental functions are:
1. MAC Learning (A): The PE router learns the source MAC addresses of frames arriving from both customer-facing ports (SAPs) and network-facing tunnels (SDPs), populating a Forwarding Database (FDB).
2. Frame Replication (B): For frames with an unknown destination MAC address, as well as for broadcast and multicast frames (BUM traffic), the PE router must replicate and flood the frame to all other SAPs and SDPs within that VPLS instance.
3. Frame Forwarding (D): When a frame with a known destination MAC address is received, the PE router performs a lookup in its FDB and forwards the frame directly to the specific SAP or SDP associated with that MAC address.

C. Frame fragmentation: This is a Layer 3 (IP) function. VPLS operates at Layer 2; Ethernet frames are not fragmented. If a frame exceeds the transport MTU, it is dropped.
E. Must discard frames with an unknown destination MAC: This is incorrect. A VPLS PE, like a switch, must flood (replicate) frames with unknown destination MACs to enable MAC learning and communication across the emulated LAN.
F. MSTP: While a VPLS can transparently tunnel customer MSTP BPDUs, the PE router itself does not participate in the customer's Spanning Tree Protocol. The VPLS core uses split-horizon rules on SDPs to prevent loops.

1. Nokia 7750 SR OS Services Guide, Release 21.10.R1, "VPLS Service" Chapter, Section: "Learning and Forwarding": "The 7750 SR OS VPLS service is designed to emulate an Ethernet LAN segment over an IP/MPLS core... This emulation requires the 7750 SR OS to perform MAC address learning, flooding of unknown unicast, broadcast, and multicast frames, and forwarding of unicast frames to known MAC addresses." (Confirms A, B, D; refutes E).

2. RFC 4762: Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling, Section 5: "Packet Forwarding": "When a PE router receives an Ethernet frame from a CE device, it must first learn the source MAC address... If the destination MAC address is a broadcast or multicast address, or if the destination MAC address has not yet been learned by the PE, the PE MUST flood the frame... if the destination MAC address has been learned, the PE forwards the frame to the appropriate destination." (Confirms A, B, D; refutes E).

3. Nokia 7750 SR OS Services Guide, Release 21.10.R1, "VPLS Service" Chapter, Section: "Spanning Tree Protocol": "The VPLS service is transparent to the customer’s STP BPDUs... The PE does not participate in the customer’s STP topology." (Refutes F).

Designing Ethernet networks with redundancy involves creating multiple physical paths between switches to prevent single points of failure. However, these physical loops are problematic for standard Ethernet (Layer 2) forwarding, which lacks an inherent loop-avoidance mechanism like the IP TTL field. Unmanaged loops cause broadcast storms, MAC address table instability, and duplication of frames, which can quickly render a network unusable. Therefore, a fundamental design requirement is to implement a protocol, such as the Spanning Tree Protocol (STP) or its modern variants (RSTP, MSTP), to logically prune the redundant paths, creating a single, loop-free forwarding topology while maintaining the physical paths for failover.

A. TTL (Time to Live) is a mechanism used in Layer 3 (IP) packets to prevent routing loops, not in Layer 2 Ethernet frames.
B. In a looped environment, the MAC address table becomes unstable (flapping), but the learning rate itself is not doubled.
C. Redundancy does not double the number of devices or MAC addresses; thus, the required FDB (MAC table) size does not double.

1. Nokia 7750 SR OS Services Guide, Release 21.10.R1: In the "Spanning Tree Protocol" section, it states, "The main purpose of STP is to ensure that you do not create loops when you have redundant paths in your network. Loops are deadly to a network." This directly confirms the need for a protocol to manage loops created by redundancy. (Reference found in sections describing Layer 2 services like VPLS and Epipe).

2. Kurose, J. F., & Ross, K. W. (2017). Computer Networking: A Top-Down Approach (7th ed.). Pearson. In Chapter 6, Section 6.4.3 "Link-Layer Switches," the text explains: "To deal with the problem of loops in redundant topologies, switches use the Spanning Tree Protocol (STP)... The protocol's goal is to create a spanning tree from the graph of switches, resulting in a loop-free topology." This is standard university courseware material.

3. IEEE Std 802.1D-2004, IEEE Standard for Local and metropolitan area networks—Media Access Control (MAC) Bridges. Clause 1, "Overview," states that the standard specifies an algorithm for bridges to "provide for the automatic reconfiguration of the active topology... to provide loop-free data paths." This standard is the foundational source for Spanning Tree Protocol.

The statement is correct. The primary objective of the Spanning Tree Protocol (STP) is to prevent Layer 2 forwarding loops in a network with redundant links by creating a single, loop-free logical topology. It accomplishes this by electing a Root Bridge and ensuring every other switch has only one active, lowest-cost path towards that Root Bridge. All other redundant paths are logically blocked. Consequently, the path taken between any two non-root switches is not necessarily the most direct or lowest-latency physical path. Instead, traffic may have to traverse "up" the spanning tree towards a common ancestor (or all the way to the Root Bridge) and then "down" to the destination switch. A more direct physical link between the two switches might exist but will be in a blocking state to maintain the loop-free topology. Therefore, STP guarantees a valid, loop-free path, but this path is often suboptimal compared to the shortest physical path available.

The "False" option is incorrect because the potential for suboptimal pathing is a fundamental and well-documented characteristic of STP's design. The protocol's algorithm prioritizes loop prevention over path optimization between all pairs of nodes. Newer protocols like Shortest Path Bridging (SPB) were developed specifically to address this and other STP limitations.

1. Nokia Official Documentation: Nokia 7450 ESS, 7750 SR, 7950 XRS, and VSR Layer 2 Services and EVPN Guide, Release 22.10.R1, Section: "Spanning Tree Protocol (STP)". The documentation describes how STP, RSTP, and MSTP operate by creating a single active path to a root, which inherently means other direct paths are blocked. The guide states, "The Spanning Tree Protocol (STP) is a Layer 2 protocol that runs on bridges and switches... STP creates a single spanning tree for the entire bridged network, which results in a single active path between any two nodes." This confirms the creation of a single path, which is not necessarily the most optimal one if a more direct link is blocked.

2. Academic Publication (Original Protocol Design): Perlman, R. (1985). "An algorithm for distributed computation of a spanning tree in an extended LAN." ACM SIGCOMM Computer Communication Review, 15(4), 44–53. https://doi.org/10.1145/318951.319004. While the paper details the algorithm for creating a loop-free tree, subsequent analysis and networking pedagogy built upon this work universally acknowledge that the resulting tree does not guarantee shortest paths between all pairs of nodes, only between each node and the root.

3. University Courseware: Kurose, J. F., & Ross, K. W. (2021). Computer Networking: A Top-Down Approach (8th ed.). Pearson. In Chapter 6, "The Link Layer: Links, Access Networks, and LANs," the text explains the operation of spanning tree. It clarifies that the protocol forces traffic to follow the branches of the tree, even if a "shortcut" link (which is blocked by STP) exists, thus leading to suboptimal routing between some pairs of switches. This textbook is standard curriculum in numerous university computer science and engineering programs.

The disable-learning command, when configured at the VPLS service level on a Nokia Service Router, only prevents the learning of new source MAC addresses. It does not affect the aging process for MAC entries that are already present in the Forwarding Database (FDB). These existing, previously learned MAC entries will continue to be subject to the configured MAC aging timer and will be removed from the FDB if they are not refreshed by subsequent traffic before the timer expires.

The statement is false because it incorrectly assumes that disabling the learning function also disables the aging function. In Nokia's SR OS, MAC learning and MAC aging are distinct processes. The disable-learning command specifically targets the population of the FDB with new entries, while the mac-aging timer independently manages the lifecycle of all dynamic entries within the FDB.

1. Nokia 7750 SR OS Services Guide, Release 21.10.R1, Document Part Number: 3HE 17680 AAAD TQZZA, Section: VPLS Configuration Commands.

In the description for the disable-learning command, the documentation clarifies its function is to stop the learning of new MAC addresses. It does not state that it stops the aging of existing entries. The mac-aging command is described separately as the mechanism that controls the removal of inactive dynamic MAC addresses. This separation of functions confirms that disabling one does not disable the other.

2. Nokia 4A0-105 Courseware: Nokia Virtual Private LAN Services, Student Guide, Module 3: VPLS Configuration and Implementation.

This module details the VPLS forwarding plane. It explains that the FDB is populated through MAC learning. It also describes the aging mechanism as a separate, continuous process that removes stale entries to maintain FDB health. The disable-learning feature is presented as a way to create a static FDB or a hub-and-spoke topology, which only affects the ingress learning process, not the maintenance (aging) of existing entries.

In the Rapid Spanning Tree Protocol (RSTP), as defined by IEEE 802.1w, a Backup Port is a port that provides a redundant, non-forwarding path to a network segment for which another port on the same switch is already the Designated Port. This scenario typically occurs when a switch has two or more ports connected to the same shared collision domain (for example, connected to a hub). The port with the lower port ID (higher priority) on the switch becomes the Designated Port for that segment, and the other port connected to the same segment transitions to the Backup Port role. The Backup Port receives BPDUs from its own switch's Designated Port.

The statement is a correct definition of the Backup Port role in RSTP. Therefore, the "False" option is incorrect. A common point of confusion is the difference between a Backup Port and an Alternate Port. An Alternate Port provides a redundant path toward the Root Bridge and receives BPDUs from a Designated Port on a different switch, whereas a Backup Port provides redundancy for a segment and receives BPDUs from a Designated Port on the same switch.

1. Nokia 7750 SR OS Services Configuration Guide, Release 21.10.R1: In the section describing Spanning Tree, the port roles are defined. The guide clarifies the Backup Port role in the context of RSTP and MSTP. "A backup port provides a redundant path to the segment to which it is connected. A backup port exists when a bridge has two or more connections to the same segment (for example, through a hub)." This inherently means the Designated Port for that segment is on the same bridge. (Reference: Section on "RSTP" and "Port States and Roles").

2. IEEE Std 802.1Q-2018, "Bridges and Bridged Networks": This standard incorporates RSTP. In Clause 13.5, "Port Roles," the Backup Port role is formally defined. It states: "A port’s role is Backup Port if it receives more useful Spanning Tree information from a Designated Port on the same Bridge." This explicitly confirms that the Backup Port and the corresponding Designated Port are on the same switch (Bridge). (Reference: Clause 13.5, page 478).

3. "Spanning Tree Protocol: A deep dive into the 802.1D standard" - University of California, Berkeley, EECS Department Course Material: Course notes for advanced networking often detail RSTP port roles. Lecture materials explain that "A backup port is a port blocked by receiving BPDUs from a designated port on the same switch. This happens when two ports of a switch are connected to the same segment." (Reference: CS168/268 Course Notes on Spanning Tree Protocol).

In Nokia-SR OS terminology a “MAC explosion” (also called MAC flooding) is the situation in which a bridge learns a very large number of different source MAC addresses in a short time, eventually exhausting the forwarding database. It is characterised by thousands of new, unique MAC addresses being added—​not by the same addresses being repeatedly withdrawn and relearned. The behaviour in which the same MAC address is continually withdrawn from one port/service and relearned on another is called “MAC move” or “MAC flapping,” not MAC explosion. Why the Other Option Is Wrong:
• True – Choosing True would equate MAC explosion with the continual withdrawal and relearning of the same MAC addresses. That behaviour is explicitly defined by Nokia documentation as “MAC move/flap,” not MAC explosion; therefore the statement is incorrect.

1. Nokia (Alcatel-Lucent) SR OS Layer 2 Services and Bridging Guide, Release R12.0, Section 7.6 “MAC Flooding (MAC Explosion)”, pp. 342-343: “MAC flooding occurs when a large number of frames with unique source MAC addresses are received … creating an explosion of new MAC entries.”

2. Nokia SR OS Layer 2 Services and Bridging Guide, Release R12.0, Section 7.7 “MAC Move Protection”, p. 350: “MAC move (also called MAC flapping) is the repeated withdrawal and relearning of the same MAC address on different ports/services.”

3. Aalto University, CS-E4180 “Advanced Topics in Networking,” Lecture notes on Layer-2 security, slide 18: distinguishes ‘MAC flooding/explosion’ from ‘MAC flapping’ (single MAC moving between ports).

These sources collectively confirm that MAC explosion involves many new MAC addresses being learned, whereas withdrawal and relearning of the same MAC address describes MAC flapping.

The statement is false. By default, a Nokia MC-LAG is configured to operate in a non-revertive mode. This means that when a failed link or node recovers, traffic will not automatically switch back (revert) to it. The system maintains the traffic on the currently active link to prevent potential instability or traffic disruption that could be caused by link flapping. Revertive behavior must be explicitly enabled by configuring the revert-time parameter within the mc-lag configuration context.

The "True" option is incorrect because it describes revertive behavior, which is not the default for Nokia's MC-LAG implementation. The default non-revertive behavior is designed to prioritize service stability over returning to a specific primary path.

1. Nokia 7450 ESS, 7750 SR, 7950 XRS, and VSR LAG and MC-LAG Guide, SR OS Release 21.10.R1, Document Part Number: 3HE 17313 AAAD TQZZA, Section: MC-LAG Configuration Commands.

Reference Detail: In the description of the revert-time command under the config>lag>mc-lag context, the documentation states: "This command enables revertive operation for an MC-LAG instance... By default, MC-LAG operates in non-revertive mode." This explicitly confirms that the default behavior is non-revertive, and an administrator must configure a revert timer to enable the behavior described in the question.

The statement is false because it incorrectly describes the relationship that defines an Alternate Port. An Alternate Port in Rapid Spanning Tree Protocol (RSTP) provides a redundant, non-forwarding path toward the Root Bridge. It is a backup for the switch's Root Port. An Alternate Port is established when a port receives superior Bridge Protocol Data Units (BPDUs) from a Designated Port on a different (neighboring) switch. The scenario described in the question—where a port provides redundancy for a Designated Port on the same switch (for example, when two ports on a switch are connected to the same hub or collision domain)—defines a Backup Port, not an Alternate Port.

The statement is not True. While it is possible for a switch to have both an Alternate Port and a Designated Port simultaneously (on different network segments), this is not the defining characteristic of an Alternate Port. The question implies a definitional relationship that is specific to the Backup Port role. The core distinction is that an Alternate Port is a backup for a Root Port, whereas a Backup Port is a backup for a Designated Port.

1. IEEE Std 802.1D-2004, "IEEE Standard for Local and metropolitan area networks—Media Access Control (MAC) Bridges":

Section 17.4, Port Roles: This section formally defines the RSTP port roles. It specifies: "An Alternate Port...receives more useful Designated Bridge information from another Bridge than the Root Port...". It also defines a Backup Port: "A Backup Port...receives more useful Designated Bridge information from the same Bridge it is on...". This directly contradicts the question's statement for an Alternate Port.

2. Nokia 7750 SR OS Services Architecture Guide, Release 21.10.R1:

Chapter: Spanning Tree Protocol (STP), Section: RSTP: The documentation defines the port roles consistent with the IEEE standard. It describes an Alternate port as providing "an alternate path to the root bridge from the root port." It defines a Backup port as providing "a redundant path to a segment where another bridge port already connects... A backup port exists when a bridge has two or more connections to the same segment... The backup port is the port that is not the designated port." This confirms the question is describing a Backup Port's relationship, not an Alternate Port's.

The statement is correct. In an MPLS-based network, Virtual Private LAN Service (VPLS) utilizes a two-label stack for forwarding traffic between Provider Edge (PE) routers. The outer label, or transport label, directs the packet across the provider's core network through a Label Switched Path (LSP) tunnel. This LSP acts as a shared transport mechanism. The inner label, or service label (also known as a VC label), is used by the egress PE router to identify the specific VPLS instance to which the packet belongs. This architecture allows a single LSP tunnel to carry traffic for numerous distinct VPLS services simultaneously, a concept known as service multiplexing. The LSP provides the transport, while the service label provides the service demarcation.

This is a "TRUE or FALSE" question. The statement is factually correct based on the fundamental architecture of VPLS over MPLS. Stating it is false would incorrectly imply that each VPLS service requires its own dedicated LSP tunnel, which is inefficient and contrary to the design principles of MPLS-based VPN services.

1. Nokia 7450 ESS, 7750 SR, 7950 XRS, and VSR Layer 2 Services and EVPN Guide, Release 22.10.R1.

Reference: In the "Services Overview" chapter, the section on "Service Distribution Paths (SDPs)" states: "An SDP is a logical way to group tunnels, and it is this SDP that is bound to a service. An SDP is not a service; it is a management and provisioning entity. An SDP can be shared by multiple services." Since an MPLS SDP uses an LSP as its transport tunnel, this confirms that a single LSP can be used by multiple services, including VPLS.

2. IETF RFC 4762: Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling.

Reference: Section 5, "Packet Encapsulation and Forwarding". This section details the packet format for VPLS over MPLS. It specifies a two-level label stack: "The top label in the stack is the 'tunnel label' used to switch the packet through the provider's network from the ingress PE to the egress PE... The second label in the stack is the 'VC label' that is used by the egress PE to de-multiplex the packet and forward it to the correct VSI [Virtual Switching Instance]." This explicitly describes the mechanism that allows multiple VPLS instances (identified by VC labels) to be multiplexed over a single LSP tunnel (identified by the tunnel label).

DOI: https://doi.org/10.17487/RFC4762

3. Nokia Virtual Private LAN Services Student Guide (Course Number: TTP36005-V-19.10).

Reference: Module 2, "VPLS Concepts". The guide explains that Service Distribution Paths (SDPs) are created between PE routers to provide the transport tunnels for VPLS traffic. It states, "SDPs are created as a pool of transport tunnels that can be shared by any service that requires them... This allows for the separation of transport and service provisioning." This directly supports the principle that the underlying transport LSPs are a shared resource for multiple VPLS services.