4A0-D01 Practice Questions

An EVPN Inclusive Multicast Ethernet Tag (IMET) route, or Route Type 3, is advertised by a VTEP to signal its membership in a broadcast domain for handling Broadcast, Unknown Unicast, and Multicast (BUM) traffic. According to RFC 7432, this route advertisement includes the originating VTEP's IP address, the Route Distinguisher (RD) of the EVPN Instance (EVI), and a PMSI Tunnel Attribute that carries the VNI. Receiving VTEPs collect these individual IMET routes from all participating peers to dynamically build their own local flooding list for ingress replication. The advertised route itself contains only a single entry for this list (the originator's IP), not the complete flooding list.

A. The VXLAN Network Identifier (VNI) is essential for identifying the broadcast domain. It is carried within the PMSI Tunnel Attribute of the IMET route advertisement.

C. The Route Distinguisher (RD) is a mandatory field in the IMET route's Network Layer Reachability Information (NLRI) to ensure the route is unique across the BGP domain for that specific MAC-VRF/EVI.

D. The IP address of the originating VTEP is explicitly included in the "Originating Router's IP Address" field of the IMET route NLRI.

1. RFC 7432: BGP MPLS-Based Ethernet VPN.

Section 7.3, "Inclusive Multicast Ethernet Tag Route": This section specifies the format of the Route Type 3 NLRI, which explicitly includes an 8-octet Route Distinguisher and the Originating Router's IP Address.

Section 8.3, "Ingress Replication": This section describes how the PMSI Tunnel Attribute is used with the IMET route. It states, "The PMSI Tunnel Attribute... MUST be attached to the Inclusive Multicast Ethernet Tag routes... The MPLS label in this attribute is the VNI." It also explains that a PE router builds its flooding list from the received IMET routes.

2. Nokia 7750 SR OS Services Guide, Release 21.10.R1, "EVPN-VXLAN".

In the section on "EVPN Route Types", the documentation for "Route Type 3: Inclusive Multicast Ethernet Tag (IMET) Route" confirms that the NLRI for the IMET route contains the configured route-distinguisher and the originating VTEP IP address, and that it carries the PMSI attribute which includes the VNI. This confirms that options A, C, and D are included in the route.

The exhibit displays the output for a system security capture-filter. This feature is designed to select specific packets based on defined criteria (in this case, protocol icmp) and copy them to the Control Plane Module (CPM). Once copied to the CPM, the packets are placed in a buffer where they can be analyzed using a tcpdump-like utility, such as the SR OS tools dump system-pcap command. The Packets Captured counter, showing a value of 10, confirms that ICMP packets are actively being copied to the CPM for analysis.

A. The exhibit shows a capture-filter, which is distinct from an ACL filter. ACLs are primarily for permitting or denying traffic, not capturing it for analysis.

C. The configuration is a capture-filter, not a cpm-filter. Furthermore, no policer or rate-limiting action is configured; the action is capture.

D. The exhibit shows a capture-filter, not a cpm-filter. Captured packets are sent to a pcap buffer for utility-based analysis, not written to a log file.

1. Nokia 7750 SR OS System Management Guide, Release 21.10.R1, Section: Packet capturing.

This section states: "The packet capturing utility allows an operator to capture IPv4 and IPv6 packets that are sent to the CPM for processing... The capture-filter command is used to configure entries to match specific packets to be captured." This confirms that capture-filter copies packets to the CPM for analysis.

2. Nokia 7750 SR OS Router Configuration Guide, Release 21.10.R1, Section: System Security Command Reference, config>system>security>capture-filter context.

The documentation for the action command within this context specifies the capture keyword: "This keyword specifies that packets matching the entry criteria will be captured." This directly supports the function shown in the exhibit and described in the correct answer.

In Nokia SR Linux, checkpoint 0 is a reserved identifier that refers to the current running configuration datastore. It is not a historical, saved checkpoint file. Historical checkpoints, which are created automatically after each successful commit, are numbered sequentially starting from 1. Checkpoint 1 represents the oldest available checkpoint, not checkpoint 0. Therefore, the statement that checkpoint 0 is always the oldest checkpoint is false.

B. The tools system configuration save command allows an operator to save the running configuration to a file, and the format can be specified as JSON.

C. The tools system configuration revert command is used to replace the current running configuration with the contents of any existing checkpoint file.

D. SR Linux automatically creates a new configuration checkpoint file after every successful commit operation, capturing the state of the configuration at that time.

1. Nokia SR Linux System Management Guide (Release 23.10), Section: "Configuration management > Configuration checkpoints".

This section states: "SR Linux automatically creates a configuration checkpoint file after every successful commit operation... The checkpoint files are numbered sequentially, starting with 1." This directly refutes option A and confirms option D.

2. Nokia SR Linux CLI User Guide (Release 23.10), Section: "tools > system > configuration > save".

This section details the save command and its parameters, including output-format {json | xml}. This confirms that the configuration can be saved in JSON format, making option B correct.

3. Nokia SR Linux CLI User Guide (Release 23.10), Section: "tools > system > configuration > revert".

This section describes the revert command, stating its function is to "replace the running configuration with the contents of a specified checkpoint file." This confirms option C is correct.

4. Nokia SR Linux CLI User Guide (Release 23.10), Section: "Configuration mode commands > compare".

The documentation for the compare command shows usage like compare to checkpoint , where checkpoint-id 0 is implicitly understood by the system to mean the running configuration, reinforcing that it is not a historical file like checkpoints 1, 2, etc.

The statement that BGP neighbors automatically discover each other is factually incorrect. BGP is a path-vector protocol that requires neighbors (peers) to be manually and explicitly configured with each other's IP addresses and autonomous system numbers. Unlike link-state protocols such as OSPF or IS-IS, which use multicast Hello packets on a shared link to dynamically discover neighbors, BGP has no such native mechanism. Since automatic neighbor discovery is not a feature of BGP, it cannot be a reason for its use in the data center. The other options listed are all well-established reasons for BGP's adoption in modern data center fabrics.

A. This is a valid reason. In large-scale data center fabrics (e.g., leaf-spine), BGP is considered more efficient and scalable than link-state protocols because it avoids the overhead of flooding link-state databases across the entire fabric.

C. This is a valid reason. BGP has been the core routing protocol of the global internet for decades. Its maturity, stability, and the widespread operational expertise surrounding it make it a trusted choice for critical infrastructure.

D. This is a valid reason. Multi-Protocol BGP (MP-BGP) extensions allow BGP to carry routing information for various address families (AFI/SAFI), including IPv4, IPv6, and EVPN, making it highly versatile for modern, multi-service data centers.

1. RFC 7938: Use of BGP for Routing in Large-Scale Data Centers.

Section 3, "Why BGP?": This section details the advantages of using BGP in the data center, listing scalability, faster reconvergence (in specific DC designs), support for multiple address families (IPv4, IPv6, L2VPN, L3VPN), and its mature, widely implemented nature. It makes no mention of automatic discovery, as this is not a BGP feature. The configuration of BGP peers is always explicit.

2. Nokia Data Center Fabric Solution Guide.

Section "Underlay and Overlay Routing Protocols": This section typically explains the choice of eBGP for the fabric. It highlights BGP's scalability to handle a large number of leaf and spine nodes, its robust policy control, and its multi-protocol capabilities for services like EVPN. The configuration examples provided in such guides always demonstrate the manual configuration of BGP neighbors, reinforcing that auto-discovery is not a feature.

3. Kurose, J. F., & Ross, K. W. (2021). Computer Networking: A Top-Down Approach (8th ed.). Pearson.

Chapter 5.3, "BGP - The Internet's Inter-AS Routing Protocol": University-level textbooks on networking describe the fundamental operation of BGP. They explicitly state that BGP sessions are established over TCP between manually configured peers. This contrasts with their description of OSPF/IS-IS, where neighbor discovery via Hello packets is a key feature.

Nokia SR Linux defines user types based on their management and access domain within the system's architecture. It officially distinguishes between "SR Linux users," who are managed by the Network Operating System (NOS) for access to the CLI and gNMI, and "Regular Linux OS users," who are managed by the underlying Linux kernel for shell access. The system also supports containerized applications, which have their own user contexts ("Container users"). "Remote users" is not a distinct user type; rather, it describes a connection method (e.g., via SSH) that can be used by any of the supported user types.

A. SR Linux users are a primary, supported user type managed by the SR Linux AAA services for access to the NOS functions.

B. Regular Linux OS users are a supported user type, managed by the underlying Linux system, providing access to the base OS shell.

C. Container users are supported through the system's architecture, which allows running third-party applications in containers with their own user spaces.

1. Nokia SR Linux R23.10 User Guide, Chapter: System management > User management > Users. The document explicitly states, "SR Linux supports two types of users: SR Linux users and Linux OS users." This confirms options A and B are valid user types and that the primary classification does not include "Remote users."

2. Nokia SR Linux Architecture White Paper (2020), Section: "A pristine Linux environment," Page 6. This paper details the architecture where the SR Linux NOS applications run on a standard Linux distribution. This separation is the basis for having distinct SR Linux and Linux OS user domains.

3. Nokia SR Linux R23.10 Extensibility Guide, Chapter: Third-party applications. This guide describes the support for running applications within Docker containers on the system. This functionality inherently means the system supports the existence and operation of users within those containerized environments, making "Container users" a valid concept.

The Zero Touch Provisioning (ZTP) process on a Nokia SR Linux node is a device-centric mechanism initiated at boot time. It fundamentally relies on DHCP to acquire network connectivity and the location of a provisioning script. The device then downloads this script, along with any necessary software packages (RPMs) or images, from a web or FTP server and executes it to complete its configuration.

Nokia’s Fabric Services System (FSS) is a higher-level orchestration and automation platform for data center fabrics. While FSS utilizes ZTP to onboard new switches into the fabric, the ZTP process itself is independent of FSS. The deployment of a digital sandbox is a function managed by FSS, not a direct action performed by the device's native ZTP autoboot process.

A. DHCP is the primary mechanism used during ZTP to provide the device with its initial IP address, default gateway, and the location of the provisioning server via DHCP options.

B. A web (HTTP/HTTPS) or FTP server is the standard repository from which the device downloads its provisioning script, configuration files, and any required software packages or images.

C. The core of ZTP's automation is the downloading and execution of a provisioning script (e.g., a Python script), which performs the device's specific configuration tasks.

1. Nokia SR Linux R23.10.R1 System Management Guide, Section: "Zero touch provisioning". This section details the ZTP workflow: "When ZTP is enabled, the SR Linux device sends a DHCP discovery message on its management interface... The DHCP server responds with an offer that includes an IP address for the management interface and the location of a provisioning script... The SR Linux device downloads the script and executes it." This confirms that A, B, and C are integral parts of the process.

2. Nokia Data Center Fabric Solution Guide, Chapter 3: "Nokia Fabric Services System". This guide describes FSS as a platform for "fabric lifecycle automation," which includes "Day 0" operations like device onboarding via ZTP. It positions FSS as the orchestrator that leverages ZTP, confirming that FSS functions (like deploying a digital sandbox) are distinct from the ZTP process running on the switch itself.

The “nhgrp” keyword shown in the route entry indicates that the static route does not carry a single next-hop but is bound to a next-hop group object.

A next-hop group can only be referenced in the routing table when it contains two or more next-hops; otherwise the router would reference the single address directly and the keyword “nhgrp” would not appear. Therefore the presence of “nhgrp” guarantees that at least two next-hops have been configured for this static route, making option C the only true statement.

A. Recursive resolution is not shown; 10.2.1.0 already appears as a resolved entry, so no further lookup via 10.1.1.0 is occurring.

B. Same reasoning as A, but with addresses reversed; no evidence of a further lookup step is displayed.

D. Within a next-hop group SR OS first honours preference, but if all next-hops share the same preference (default), selection is by weight; exhibit provides no differing preferences.

1. Nokia SR OS Router Configuration Guide 21.7.R1, “Static Routes – Next-hop Groups”, p. 892-893: states that a route referencing “nhgrp” implies multiple next-hops.

2. Nokia SR OS 7750 SR Routing Protocols Guide 21.7.R1, §4.3.2 “Next-hop group behaviour”: explains preference/weight handling and that single-next-hop groups are optimised away.

3. Nokia SR OS CLI Reference Guide 21.7.R1, cmd “show router route …”: description of output fields, notes “nhgrp” appears only when more than one next-hop is present.

The displayed record is produced by the SR OS command “show mac-duplication”.

It shows that MAC 00:25:BA:00:00:10 triggered a “re-learning” event –- i.e., the same interface repeatedly re-learnt the MAC faster than the configured rate threshold.

When a duplicate is learnt on different interfaces the state would be “duplicate” and the interface list would contain more than one entry.

Because the output indicates a re-learning event (single interface), the statement claiming that the MAC is learnt on more than one interface is false.

The remaining statements accurately describe what can be read in the output: the re-learning threshold was exceeded, port ethernet-1/10 owns the MAC, and mac-duplication detection is enabled for mac-vrf-1.

B. Output shows “Last-Tracking-Event: re-learning” and counters above threshold → threshold exceeded; statement correct.

C. Output line “Configured-MAC: 00:25:BA:00:00:10 (If ethernet-1/10)” confirms the port has that address; statement correct.

D. Banner/header contains “MAC-VRF: mac-vrf-1 (dup-detection = enabled)”; statement correct.

1. Nokia SR OS 22.x Layer 2 Services and Bridging Guide, sec. 14.5 “MAC Duplication Detection”, pp. 390-394 – description of “duplicate” vs. “re-learning” events and output fields.

2. Nokia SR OS MD-CLI Command Reference, cmd. “show mac-duplication”, pp. 1853-1856 – field “Interfaces” and interpretation of single vs. multiple interfaces.

3. Nokia SR OS System Management Guide, sec. 9.3.4 “Setting re-learning thresholds”, p. 211 – explanation of threshold counters triggering alarms.

4. IEEE 802.1Q-2018 Annex F – definition of duplication and re-learning behaviour in provider bridges (background for Nokia implementation).

5. MIT OpenCourseWare “Advanced Computer Networks”, Lecture 13 notes, slide 22 – discussion of MAC flapping/re-learning and its detection in switches (academic corroboration).

An IP-VRF is a purely Layer 3 construct, equivalent to a virtual router. It contains an independent routing table and a set of Layer 3 interfaces. A subnet, where multiple servers can communicate directly, is a Layer 2 broadcast domain. While this Layer 2 domain is linked to an IP-VRF via a Layer 3 interface (such as an Integrated Routing and Bridging - IRB - interface) which acts as the default gateway, the servers themselves are not connected within the Layer 3 IP-VRF. They are connected to a Layer 2 network (like a mac-vrf or VLAN) that is merely associated with the IP-VRF. Therefore, the statement is technically false.

A. An IP-VRF is explicitly defined in Nokia SR Linux documentation as a Layer 3 network instance, or virtual router, for traffic isolation.

B. The fundamental principle of IP routing, which is the function of an IP-VRF, is to forward packets based on the destination IP address in the packet header.

C. The core purpose and defining characteristic of a VRF is to create an isolated routing domain with its own distinct routing and forwarding table.

1. Nokia SR Linux R22.10.1 System Management Guide, Section: "Network instances": This document states, "SR Linux supports different types of network instances for Layer-2 and Layer-3 traffic isolation... An ip-vrf network instance is a virtual router for Layer-3 traffic." This confirms that an IP-VRF is a Layer 3 instance (A is true) and that it provides isolation, which is achieved through distinct tables (C is true). The document also defines a mac-vrf as a "virtual switch for Layer-2 traffic," highlighting the separation between L2 and L3 domains, which supports the reasoning for D being false.

2. Nokia SR Linux R22.10.1 Layer 3 Services Guide, Section: "Unicast routing overview": This guide details the IP forwarding process. It implicitly confirms that within any routing context, including an IP-VRF, the forwarding decision is based on a lookup of the destination IP address in the Forwarding Information Base (FIB). This makes statement B true.

Resilient ECMP is an enhancement to standard Equal-Cost Multi-Path (ECMP) designed to minimize service disruption when a next-hop path fails or is restored. In traditional ECMP, a change in the number of available paths (e.g., from N to N-1) forces a recalculation of the hash algorithm for all flows, potentially re-routing traffic that was on stable paths. Resilient ECMP avoids this by using a more stable mapping mechanism. When a next-hop fails, only the traffic flows that were actively using that specific failed path are re-distributed among the remaining active next-hops. Flows on other, unaffected paths are not impacted, thus preserving their state and preventing unnecessary disruption.

A. This describes the hashing mechanism for standard, non-resilient ECMP. Resilient ECMP uses a more sophisticated method, often involving buckets, to avoid the complete flow re-shuffling caused by a simple modulo operation when the number of paths changes.

B. The goal described is to avoid hash polarization across multiple routers, which is a different network design consideration from resilience to a single next-hop failure on one router. Resilient ECMP's primary function is local failure recovery.

C. Using a different hash seed on downstream routers is a technique to prevent hash polarization, ensuring better traffic distribution across a network. This is not the defining characteristic or mechanism of resilient ECMP.

1. Nokia 7750 SR OS Services Architecture Guide, Release 21.10.R1, Section: Resilient ECMP: "When a next-hop is removed from the ECMP set, only the flows that are mapped to that next-hop are redistributed... Flows mapped to the other next-hops of the ECMP set are not modified." (Page 388)

2. Nokia 7750 SR OS Routing Protocols Guide, Release 21.10.R1, Section: ECMP Hashing: This section contrasts the behavior of the default hashing algorithm with resilient ECMP, explaining that the default algorithm re-hashes all flows upon a path change, while resilient ECMP provides stability for unaffected flows. (Page 124)