Free Nokia SR Linux EVPN and Data Center Interconnect 4A0-D03 Exam Questions

Comprehensive and Detailed 150 to 250 words of Explanation From [SR Linux EVPN and Data Center Interconnect/Course Guide/topics]:

In interface-less symmetric L3 EVPN routing, hosts in a subnet may be attached to different leaf routers, while inter-subnet forwarding is performed through the IP-VRF using VXLAN routed interfaces. The ingress and egress PEs both participate in L3 forwarding, and the routed VXLAN interface provides the per-IP-VRF overlay data-plane construct needed for symmetric routing. The IRB interfaces on the local MAC-VRFs must advertise learned local host routes so that remote PEs have the necessary host reachability information. The MAC-VRFs also need the appropriate EVPN control-plane configuration so host MAC/IP information can be exchanged, while the IP-VRF participates in L3 VPN-style route exchange for routed reachability. Option A is false because anycast gateway is not optional in this design for Leaf1 and Leaf2. Anycast gateway allows the same default-gateway IP and virtual MAC behavior to exist consistently on multiple leaves serving the same subnet. Without it, host default-gateway behavior would be inconsistent and traffic mobility across the fabric would break expected distributed gateway operation. Reference: interface-less symmetric routing, IRB, anycast gateway, routed VXLAN interface.

Comprehensive and Detailed 150 to 250 words of Explanation From [SR Linux EVPN and Data Center Interconnect/Course Guide/topics]:

A decoupled gateway-based DCI model separates the data center border-leaf function from the WAN PE function. This separation is the key design point. The border leaf remains part of the data center EVPN/VXLAN environment, while the WAN PE participates in WAN VPN transport and policy enforcement. Because the roles are split across two devices, the handoff between the border leaf and WAN PE provides a clean administrative and operational boundary. That boundary is useful for security policy, QoS marking, traffic classification, and troubleshooting ownership. The WAN does not need direct reachability to every leaf and route reflector as in a gateway-less model. The WAN PE also does not peer directly with the data center route reflector in a decoupled model; route exchange occurs through the border-leaf/WAN-PE handoff. VXLAN tunnels between leaf routers across different data centers are characteristic of gateway-less extension, not decoupled gateway operation. Therefore, the statement about clear demarcation between the data center border leaf and WAN PE is the accurate description. Reference: decoupled gateway-based DCI, security/QoS demarcation, WAN PE separation.

Comprehensive and Detailed 150 to 250 words of Explanation From [SR Linux EVPN and Data Center Interconnect/Course Guide/topics]:

Layer 3 EVPN multi-homing with a centralized router uses an Ethernet Segment to associate multiple leaf routers with a common external L3 attachment. The centralized router is part of that attached segment from the forwarding perspective, and the connected leaf routers advertise third-party or customer prefixes into EVPN so that remote leaves can reach those prefixes through the multi-homed attachment. For L3 EVPN, learned customer prefixes are normally advertised using EVPN route type 5, which carries IP prefix reachability. In an all-active design, remote leaf routers may load balance traffic to the customer prefix through multiple attached leaf routers because the ES next-hop allows the remote PE to understand that the prefix is reachable through a multi-homed Ethernet Segment. The false statement is that every router participating in the Ethernet Segment must be configured with all-active mode. Multi-homing mode is a design and configuration property of the EVPN PEs participating in the ES, and designs may use single-active or all-active behavior depending on redundancy and forwarding requirements. Reference: L3 EVPN multi-homing, centralized router attachment, EVPN RT-5 prefix advertisement.

Comprehensive and Detailed 150 to 250 words of Explanation From [SR Linux EVPN and Data Center Interconnect/Course Guide/topics]:

EVPN route type 2 carries MAC/IP advertisement information. It is central to host-based routing and to designs where the fabric must distribute host MAC-to-IP bindings for integrated routing and bridging. In host routing, RT-2 is required because individual host reachability is signaled through MAC/IP advertisements. In interface-less prefix routing, RT-2 is still needed because the system relies on host or gateway MAC/IP information associated with the IRB and distributed gateway behavior. Interface-ful unnumbered designs may also require RT-2-style information to resolve next-hop or adjacency behavior because the routed interface does not use a conventional numbered next-hop model. Prefix routing with interface-ful numbered operation is different. In that model, the routed interface has explicit IP addressing and prefix reachability can be carried with L3 prefix routes without requiring EVPN RT-2 host MAC/IP advertisement as a dependency. Therefore, the symmetric routing option that does not require EVPN route type 2 is prefix routing interface-ful numbered. Reference: symmetric L3 EVPN routing models, RT-2 MAC/IP advertisements, prefix routing behavior.

Comprehensive and Detailed 150 to 250 words of Explanation From [SR Linux EVPN and Data Center Interconnect/Course Guide/topics]:

Ethernet Auto-Discovery per EVI routes are EVPN route type 1 advertisements used in multi-homing at the service-instance level. A PE sends an AD per EVI route for each MAC-VRF associated with the Ethernet Segment. These routes allow remote PEs to understand that the advertising PE has reachability to a given EVI through the shared ES. They are also used for aliasing and fast convergence, because a remote PE can treat multiple attached PEs as valid paths for traffic toward the same multihomed segment. In VXLAN EVPN, the update can include data-plane information such as the VNI, and it carries route-target information so the route is imported into the correct MAC-VRF. Option B is false because the multi-homing type or redundancy mode is not carried in the AD per EVI update as stated. Redundancy behavior is associated with Ethernet Segment-level signaling and configuration, especially ES discovery and related route attributes, not with AD per EVI as the mechanism that declares the multi-homing type. Reference: EVPN RT-1 AD per EVI, MAC-VRF association, route target, VNI, aliasing.

Comprehensive and Detailed 150 to 250 words of Explanation From [SR Linux EVPN and Data Center Interconnect/Course Guide/topics]:

In a gateway-less DCI design, there is no dedicated gateway device performing EVPN-to-WAN service interworking. Instead, the data center EVPN overlay is extended across the WAN more directly. Because leaf routers must establish overlay reachability across sites, the IP addresses of the leaf VTEPs need to be reachable through the WAN, commonly by redistributing or otherwise carrying the necessary loopback reachability. The WAN transparently carries the EVPN/VXLAN overlay, and leaf routers can establish VXLAN tunnels across the WAN to remote leaves. Option D is false because it introduces ''data center gateway routers'' maintaining MP-BGP EVPN peering with the data center route reflector. That is not the gateway-less model; it describes a gateway-based role that does not exist as a separate function in this architecture. In gateway-less DCI, the EVPN control-plane and VXLAN data-plane extension are handled by the fabric endpoints themselves, so the design trades demarcation and interworking control for a more direct overlay extension model. Reference: gateway-less DCI, WAN reachability for leaf VTEPs, transparent EVPN overlay carriage, VXLAN tunnel extension.

Comprehensive and Detailed 150 to 250 words of Explanation From [SR Linux EVPN and Data Center Interconnect/Course Guide/topics]:

In an all-active Layer 2 EVPN multi-homing design, the host is normally dual-attached through a LAG to multiple leaf routers that share the same Ethernet Segment Identifier. Leaf1 and Leaf2 both participate in the Ethernet Segment and may receive traffic from the host. For BUM traffic sourced by the host, the host-side hashing can send frames toward either attached leaf. For BUM traffic sent from the EVPN overlay toward the multi-homed segment, DF election controls which PE forwards that replicated traffic toward the local Ethernet Segment to prevent duplicate delivery. The false statement is option B. A remote leaf such as Leaf3 does not simply enable ECMP on the MAC-VRF to load-balance traffic between Leaf1 and Leaf2. EVPN all-active forwarding uses Ethernet Segment discovery, Ethernet A-D routes, aliasing, and split-horizon procedures to determine valid next-hops and prevent loops. ECMP alone is an underlay or routing-table behavior; it is not the MAC-VRF mechanism that authorizes multi-homed L2 forwarding across an Ethernet Segment. Reference: all-active L2 EVPN multi-homing, Ethernet Segment association, DF election, aliasing.

Comprehensive and Detailed 150 to 250 words of Explanation From [SR Linux EVPN and Data Center Interconnect/Course Guide/topics]:

In EVPN PE-CE routing, the PE exchanges ordinary IPv4 or IPv6 unicast routing information with the CE. When the PE learns CE prefixes, it imports them into the tenant IP-VRF and advertises them to other EVPN PEs as EVPN route type 5 IP Prefix routes. Conversely, when the PE receives EVPN routes from remote PEs, it can advertise corresponding IPv4/IPv6 BGP updates toward the CE, subject to policy. Import and export policies are essential because they control which customer routes are accepted, which EVPN-learned routes are advertised, and how attributes are modified. Option C is false because iBGP is not the preferred PE-CE model in this context. eBGP is typically preferred between PE and CE because it creates a clean administrative routing boundary between the provider/data-center edge and the customer or external router. Using eBGP also simplifies route policy, loop prevention, and operational separation. The CE does not need to participate in the EVPN overlay; it speaks standard BGP unicast with the PE, while the PE performs the EVPN RT-5 advertisement into the fabric. Reference: EVPN PE-CE BGP routing, eBGP preference, RT-5 prefix advertisement, import/export policy.

Comprehensive and Detailed 150 to 250 words of Explanation From [SR Linux EVPN and Data Center Interconnect/Course Guide/topics]:

An anycast-gateway IRB allows multiple PEs to present the same default-gateway IP address to hosts in the same subnet. This is the mechanism that enables distributed gateway behavior in EVPN fabrics. The same anycast gateway IP may be configured on equivalent IRB subinterfaces across remote PEs participating in the same IP-VRF, allowing hosts to use the nearest leaf as their default gateway without changing their gateway address. SR Linux also associates gateway MAC information with the IRB, including virtual gateway MAC behavior used inside the MAC-VRF forwarding table. Option C is false because the anycast gateway IP is not treated as a normal unique host route that appears in the IP-VRF route table alongside the subnet prefix. The subnet route is installed for the connected network, but the shared anycast gateway address is a gateway function, not a separately advertised host endpoint that should appear as ordinary routed host reachability. Treating the anycast IP as a regular host route would undermine the distributed gateway model and create ambiguous ownership across PEs. Reference: IRB anycast gateway, MAC-VRF/IP-VRF interconnection, distributed default-gateway operation.

Comprehensive and Detailed 150 to 250 words of Explanation From [SR Linux EVPN and Data Center Interconnect/Course Guide/topics]:

The route target is the extended community consistently associated with EVPN updates to control route import and export between EVPN instances. In SR Linux EVPN services, route targets determine which MAC-VRF or IP-VRF should import a received EVPN route. This is essential for tenant separation because multiple tenants may use overlapping MAC or IP address spaces while sharing the same physical fabric and BGP control plane. The AFI/SAFI is not an extended community; it identifies the BGP address family and subsequent address family used to carry EVPN NLRI. The EVPN route type is also not an extended community; it is part of the EVPN NLRI structure and identifies whether the route is RT-1, RT-2, RT-3, RT-4, RT-5, and so on. The VXLAN network ID may be carried or inferred through service and encapsulation-specific attributes, but it is not universally present as the required extended community in every EVPN update. The route target is the mandatory policy element that enables receiving PEs to place EVPN routes into the correct service context. Reference: EVPN extended communities, route-target import/export policy, tenant service identification.