In an SR OS VPLS, proxy-ARP/ND becomes active when the service is configured with “proxy-arp” together with “dynamic-populate.”

With dynamic-populate, the PE snoops ARP or ND messages coming from both its local SAPs and from remote pseudowires to learn IP-to-MAC bindings; each binding is stored in the proxy-ARP table.

VPLS distributes only Ethernet frames; it has no control-plane construct equivalent to EVPN’s Route-Type 2 MAC/IP advertisement. Consequently, a PE in VPLS never sends a BGP “MAC/IP route” that carries a host’s MAC and IP information. Therefore statement E is the single false statement.

B. Required; “proxy-arp” plus “dynamic-populate” must be on for the feature to work.

C. Correct; remote hosts are learned by snooping ARP/ND frames that arrive over the PW.

D. Correct; ARP/ND messages from a local SAP add a local entry in the proxy-ARP table.

1. Nokia SR OS 22.10.R1 Layer 2 Services Guide, Section “Proxy-ARP/ND in VPLS,” pp. 624-626 (explains dynamic-populate learning for local and remote hosts).

2. Nokia SR OS 22.10.R1 Router Configuration Guide, “proxy-arp dynamic-populate” command syntax, p. 312.

3. Nokia SR OS 22.10.R1 EVPN Guide, Section 11 “MAC/IP Advertisement Route,” pp. 490-492 (states such routes exist only in EVPN, not VPLS).

The EVPN Inclusive Multicast Ethernet Tag (IMET) route, also known as EVPN Route Type 3, is used for the auto-discovery of Provider Edge (PE) routers participating in the same EVPN Instance (EVI) or VPLS service. Each PE advertises an IMET route to signal its membership in a specific VPLS. Other PEs in the same service receive this route and add the originating PE to their flood list. This mechanism is fundamental for establishing the necessary ingress replication tunnels to forward Broadcast, Unknown Unicast, and Multicast (BUM) traffic to all participating PEs within that service instance.

A. This is the function of the EVPN MAC/IP Advertisement route (Route Type 2), which communicates specific host reachability information.

B. This is handled by the EVPN Ethernet Segment route (Route Type 4), which is used for multi-homing redundancy and Designated Forwarder (DF) election.

D. Discovering PEs attached to the same multi-homed Ethernet Segment is the primary function of the Ethernet Auto-Discovery (A-D) per ES route (Route Type 1).

1. Nokia 7450 ESS, 7750 SR, 7950 XRS, and VSR Layer 2 Services and EVPN Guide, Release 22.10.R1, Document ID: 3HE 18121 AAAC TQZZA 01.

Section: EVPN-MPLS for VPLS services > EVPN route types

Quote/Paraphrase: "The inclusive multicast Ethernet tag route is used for BUM traffic. The route is also referred to as route type 3. The route advertisement is used by the remote PEs to build their flooding list for a specified VPLS service." This confirms the route is used for PEs to discover each other for the purpose of BUM traffic flooding within a service.

2. IETF RFC 7432: BGP MPLS-Based Ethernet VPN.

Section 8.3: Inclusive Multicast Ethernet Tag Route

Quote/Paraphrase: "A PE that is configured with a particular EVI MUST advertise an Inclusive Multicast Ethernet Tag route for that EVI. This route is used to advertise the tunnel endpoint for ingress replication... When a PE receives an Inclusive Multicast Ethernet Tag route, it MUST check if it is configured for the EVI associated with the route. If it is, the receiving PE adds the originator of the route to the flooding list for BUM traffic for that EVI." This directly supports the auto-discovery function for building BUM forwarding paths.

The statement that is FALSE is B. The P-flag (Proxy-ARP/ND flag) is an attribute carried within the EVPN BGP Extended Community. Its purpose is to signal that the advertising Provider Edge (PE) router is capable of and willing to perform proxy-ARP/ND functions for hosts within the EVPN instance. This functionality is specific to Integrated Routing and Bridging (IRB) interfaces in EVPN VLAN-based services.

The service in the exhibit is an EVPN-VPWS (Virtual Private Wire Service), which is a point-to-point Layer 2 service. EVPN-VPWS does not involve Layer 3 routing or ARP/ND processing within the service. Therefore, the P-flag is not applicable, and PE3 would not set it to 1.

A. When the physical link between PE1 and CE1 fails, the corresponding Service Access Point (SAP) on PE1, which represents that attachment circuit, will transition to an operationally down state. This is standard behavior.

C. In an all-active multi-homing scenario, both PE1 and PE3 advertise an Ethernet A-D per EVI route for the service. When the link from PE1 to CE1 fails, PE1 withdraws its route. Consequently, the remote PE2 will only see the remaining route from PE3.

D. The Ethernet A-D per ES route is used for multi-homing functions like auto-discovery and designated forwarder election. Both PE1 and PE3 are part of the same Ethernet Segment (ES) and will advertise this route. A single attachment circuit failure does not cause the ES route to be withdrawn.

1. Nokia 7450 ESS, 7750 SR, 7950 XRS, and VSR Layer 2 Services and EVPN Guide: SR OS Release 21.10.R1, Section: EVPN-VPWS. The guide describes EVPN-VPWS as a point-to-point service without L3 functions, confirming that proxy-ARP/ND is not a relevant feature.

2. Nokia 7450 ESS, 7750 SR, 7950 XRS, and VSR Layer 3 Services Guide: SR OS Release 21.10.R1, Section: EVPN-IRB and Proxy-ARP/Proxy-ND. This section details the use of proxy-ARP/ND and the associated P-flag specifically for EVPN IRB interfaces, distinguishing it from other EVPN service types like VPWS.

3. RFC 9136: The IP and MAC-VRF-to-VRF Model for BGP/MPLS IP-VPNs, Section 4.4.1. This RFC defines the EVPN Extended Community and explicitly states: "Proxy-ARP/ND Flag (P-flag): 1 bit. If this flag is set to 1, it indicates that the advertising PE is willing to send proxy ARP/ND replies for the attached host." This function is tied to IP routing, which is not part of a VPWS service.

4. RFC 7432: BGP MPLS-Based Ethernet VPN, Section 8.2.2. This RFC specifies that upon failure of an attachment circuit in a multi-homed ES, the PE "MUST withdraw the associated Ethernet A-D per-EVI route(s)." This supports the reasoning for why option C is a correct statement of behavior.

In an EVPN/VXLAN fabric a MAC-VRF (also called an EVPN Instance) is created per bridge domain or Layer-2 segment. The exhibit shows two distinct bridge domains (BD-10 and BD-20) that belong to the same tenant. Because each BD requires its own EVPN control-plane context, exactly two MAC-VRFs are instantiated across all participating PEs. The number of PEs or the presence of an IP-VRF for inter-subnet routing does not change this fact—only the number of bridge domains determines the number of MAC-VRFs. Therefore, the correct count is 2.

A. 1 – Only one MAC-VRF would exist if there were a single bridge domain; the exhibit shows two.

C. 3 – A third context would be an IP-VRF, not a MAC-VRF.

D. 4 – Would require four separate bridge domains, which are not present in the exhibit.

1. Nokia SR OS Service Configuration Guide — EVPN, R22.5, Section 5.1 “MAC-VRF and IP-VRF Constructs”, pp. 77-78.

2. Nokia SR OS Layer 2/EVPN Services Guide, R22.5, Figure 5-2 “Tenant with two bridge domains”, p. 84.

3. IETF RFC 7432 “BGP MPLS-Based Ethernet VPN”, Section 2.1, para 3 (“A MAC-VRF is instantiated for every bridge domain”).

4. Nokia VSP Fabric Technical Configuration Guide 9.0, Chapter “EVPN-VXLAN”, p. 112, bullets under “Designing Bridge Domains and MAC-VRFs.”

In an EVPN multi-homing all-active mode, a Customer Edge (CE) device is connected to multiple Provider Edge (PE) routers, and all the links are active and can be used for forwarding traffic. This setup provides both load balancing and redundancy. All PEs attached to the same Ethernet Segment (ES) advertise the same Ethernet Segment Identifier (ESI) and can forward traffic to and from the CE for a given service. This is the fundamental operational principle of all-active multi-homing.

A. In single-active mode, the CE is typically connected via individual links, not a LAG. A multi-chassis LAG (MC-LAG) is characteristic of the all-active mode.

B. In single-active mode, only one PE (the Designated Forwarder) is active for a service. Therefore, the CE forwards and receives traffic through that single active PE only.

D. The Nokia 7750 SR supports a CE being multi-homed to more than two PEs. The specific limit is up to four PEs for all-active mode and up to eight PEs for single-active mode.

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

Section: EVPN for VPLS and Epipe Services > EVPN Multi-homing

Content: This section explicitly describes the two multi-homing modes. For all-active, it states: "In all-active mode, the CE is connected to the PEs through a LAG and all the links in the LAG can be used to send and receive traffic." This directly supports answer C. For single-active, it states: "In single-active mode... Only one of the links between the CE and the PEs is active at a time." This refutes options A and B. The guide also specifies the supported scale: "A CE can be multi-homed to up to four PEs in all-active mode, or up to eight PEs in single-active mode," which refutes option D.

2. IETF RFC 7432: BGP MPLS-Based Ethernet VPN.

Section: 8.3.1. All-Active Redundancy Mode

Content: "In this mode of operation, a CE may be connected to two or more PEs via a set of Ethernet links that constitute a Link Aggregation Group (LAG). From the CE's perspective, it is connected to a single device. In this mode, all PEs attached to the Ethernet segment are allowed to forward traffic to/from that Ethernet segment." This standard definition validates answer C.

3. IETF RFC 7432: BGP MPLS-Based Ethernet VPN.

Section: 8.3.2. Single-Active Redundancy Mode

Content: "In this mode of operation, a CE is connected to two or more PEs, but only one of these PEs is allowed to forward traffic to/from the CE for a given EVI." This standard definition confirms that the behavior described in option B is incorrect for single-active mode.

Statement C is false. PE3 is a standard VPRN PE, not an EVPN-IRB gateway. When PE3 receives the VPN-IPv4 route for 10.10.1.0/24 from the EVPN domain (advertised by PE1/PE2), it resolves this route using a standard VPRN mechanism. This involves finding a transport tunnel (e.g., an MPLS LSP) to the BGP next-hop (PE1 or PE2). The concept of resolving a route to a "MAC-OI" (MAC Overlay Index) is an internal data plane function specific to an EVPN-IRB PE. The IRB PE uses this to forward Layer 2 traffic to the correct destination VTEP after IP-to-MAC resolution. A remote VPRN-only PE like PE3 has no awareness of the EVPN Layer 2 constructs.

A. This is a true statement. PE3 and PE4 are part of a VPRN service, which uses MP-BGP with the VPN-IPv4 address family to exchange customer routing information between them.

B. This is a true statement. PE1 and PE2 are part of an EVPN service (VPLS 10), which uses MP-BGP with the EVPN address family to exchange Layer 2 reachability information.

D. This is a true statement. The route to 10.10.4.0/24 is advertised by PE4 to PE3 via MP-BGP. PE3 resolves this standard VPN-IPv4 route using a transport tunnel toward the BGP next-hop, which is PE4.

1. Nokia 7x50 SR OS Services Guide, Release 21.10.R1, "EVPN for VXLAN in a VPRN service" section. This section details the interaction between EVPN-IRB and standard VPRN services. It clarifies that routes advertised from the EVPN domain are standard VPN-IPv4 routes to remote PEs. The remote PEs resolve these routes to the BGP next-hop via the transport network, without knowledge of EVPN-specific constructs like overlay indexes.

2. Nokia 7x50 SR OS Services Guide, Release 21.10.R1, "VPRN service overview" section. This section describes the fundamental operation of VPRN services, stating that "When BGP is used to exchange routing information, the PE routers exchange information on a private basis. They use the BGP MPLS VPN extensions (RFC 4364) and the extended BGP community attribute to provide a separate routing information base for each VPN." This confirms that PE3 resolves routes via transport tunnels to the advertising PE.

3. Nokia 4A0-115 Courseware, "Module 4: EVPN and Data Center Interconnect", Section on EVPN Integrated Routing and Bridging (IRB). The course material explains that in an EVPN-IRB architecture, the IRB PEs advertise their local subnets into the VPN-IPv4 address family. Remote VPRN PEs receive these advertisements and perform standard L3VPN route resolution to the BGP next-hop. The concept of MAC-OI is presented as a data plane optimization within the IRB PE for forwarding packets to hosts in the EVPN domain.

The statement is false because the responsibility for adding the Ethernet Segment Identifier (ESI) label lies with the ingress Provider Edge (PE) router that receives the traffic from the multi-homed Ethernet Segment (ES). In the traffic flow depicted, CE1 sends Broadcast, Unknown Unicast, or Multicast (BUM) traffic to PE1. PE1, as the ingress PE for ES-1, adds the ESI label for ES-1 before performing ingress replication to remote PEs (PE2 and PE3). PE3, being a peer PE on the same ES-1, receives this packet, inspects the ESI label, and performs split-horizon filtering by not forwarding the traffic back to CE1. PE3 does not add an ESI label itself in this process.

A. This statement is also false. In an EVPN with ingress replication, the source PE (PE1) replicates BUM traffic to all other PEs. Egress PEs (PE3) do not re-replicate this traffic to other PEs.

C. This statement is also false. The split-horizon filtering based on the ESI label is performed by the PE (PE1 in the hypothetical reverse flow). The PE would discard the frame, not forward it to the CE.

D. This statement is also false as written. According to the ingress replication model shown, PE1 forwards the traffic to PE2. PE3 does not forward BUM traffic to other PEs.

(Examiner's Note: This question is flawed as options A, B, C, and D are all factually incorrect statements based on standard EVPN operation. However, option B describes a fundamental misunderstanding of the ESI label imposition rule, which is central to the EVPN multi-homing mechanism being tested.)

1. Nokia 7750 SR OS, 7450 ESS, and 7950 XRS EVPN Services Guide, Release 22.10.R1, Section: EVPN for MPLS Tunnels.

Page 103, "Split horizon" section: "The PE at the ingress of the network (that is, the PE that receives the traffic from the CE) encapsulates the packet with the ESI label and the VPLS label, and sends it to the remote P

RFC 7432 and the Nokia SR OS EVPN implementation use Algorithm-1 for DF election when the “default” algorithm is left in place.

1. Every PE attached to the same ES advertises a DF-Preference in its Ethernet-Segment route; the PE with the numerically lowest preference becomes DF.

2. If two or more PEs have the same preference, the tie-breaker is the numerically lowest originating-router IP address.

In the exhibit PE-2 advertises DF-Preference 100, while PE-1 and PE-3 advertise 32767 (default) and PE-4 advertises 200. Because 100 is the smallest value, PE-2 wins and is elected the DF for VPLS 10 on ESI-1.

A. PE1’s DF-Preference (32767) is higher than PE2’s 100, so it loses in the first comparison step.

C. PE3’s DF-Preference (32767) is higher than PE2’s 100, so it is not chosen.

D. PE4 advertises preference 200, higher than PE2’s 100, so it is not selected.

1. IETF RFC 7432 “BGP MPLS-based Ethernet VPN”, Sec. 8.5.1-8.5.2, pp. 33-34 – DF-Preference and tie-breaker rules.

2. Nokia SR OS 22.10.R1 EVPN Guide, Sec. “Designated Forwarder Election”, pp. 110-112 – default Algorithm-1 behaviour and preference values.

3. Nokia “Virtualized Services Fundamentals” Courseware (4A0-115), Module 4, pp. 4-35 to 4-36 – example showing PE with lowest DF-Preference elected DF.

The statement that VPLS 10 must be configured with two BGP instances on the gateway PEs (PE3 and PE4) is false. A single BGP instance on a Nokia router is capable of handling multiple BGP address families simultaneously. In this scenario, a single BGP process can manage both the L2-VPN address family for BGP-VPLS signaling with the MPLS core and the EVPN address family for signaling with the VXLAN domain. The distinction is handled by configuring separate bgp and bgp-evpn contexts within the same VPLS service, not by creating separate, system-level BGP routing instances.

B. Using different Route Distinguishers (RDs) for the MPLS and VXLAN portions of the service on the gateway is required to uniquely identify and re-originate routes between the two domains.

C. Different Route Targets (RTs) are essential for the gateway to control the import/export of routes, effectively stitching the VPLS service between the separate MPLS and VXLAN signaling domains.

D. An export policy is required on the gateway PEs to control route propagation, ensuring that routes with encapsulation information for one domain (e.g., VXLAN) are not advertised into the other (MPLS).

1. Nokia 7450 ESS, 7750 SR, 7950 XRS, and VSR Services Architecture Guide, Release 21.10.R1, Document Part Number: 3HE 17663 AAAC TQZZA, Edition 01.

Section: VPLS > EVPN for VPLS > EVPN-VXLAN to EVPN-MPLS Gateway.

Reference for A: The configuration examples in this section show a single router "Base" BGP instance. Within the VPLS service, separate bgp and bgp-evpn contexts are configured, demonstrating that multiple BGP instances are not required.

Reference for B & C: This section states, "The gateway is a VPLS service that is configured with a BGP context for the BGP-VPLS routes and a bgp-evpn context for the EVPN-VXLAN routes... When re-advertising routes from one protocol to the other, the gateway will use its own IP address as next-hop and generate a new route-distinguisher for the route." This confirms the need for separate contexts with their own RTs and the re-origination with new RDs.

Reference for D: The guide explains the gateway's role in handling BUM traffic by terminating an IMET route from one domain and originating a new one for the other (e.g., a PMSI attribute for MPLS). This controlled re-advertisement process necessitates policy control to prevent leaking incompatible encapsulation information.

Statement (D) is false because it incorrectly describes the scope and primary purpose of the EVPN Auto-Discovery (A-D) per EVI route. The discovery of all PEs attached to an Ethernet Segment (ES) for functions like Designated Forwarder (DF) election is the specific role of the A-D per ES route.

The A-D per EVI route, as its name implies, is scoped to a specific EVPN Instance (EVI) or service. It is used to discover other PEs on the same ES that are also part of that specific service. Its primary functions are to enable aliasing (for all-active multi-homing) and mass MAC withdrawal for that service. It cannot be used to discover a PE on the ES that does not participate in that particular EVI.

A: This is a true statement. Remote PEs use the collection of received A-D per EVI routes from PEs in an all-active segment to build a next-hop list (aliasing) for load-balancing traffic.

B: This is a true statement. A PE attached to an Ethernet Segment generates and advertises a distinct A-D per EVI route for every single service (EVI) that is operationally active on that segment.

C: This is a true statement. According to RFC 7432, the Ethernet A-D per EVI route (Type 1) is defined to have the Ethernet Tag ID field set to zero, as it applies to the entire EVI on the segment, not a specific VLAN.

1. Nokia 3HE 17175 AAAA TQZZA 01, SR OS 22.10 Services Architecture Guide, Chapter: EVPN for VPLS and Epipe services, Section: EVPN route types.

This guide distinguishes between the two Type 1 routes. It states, "The Ethernet A-D per ES route is advertised per Ethernet segment and is used for DF election." This confirms that discovering all PEs for core multi-homing is the role of the per-ES route. It then describes the A-D per EVI route: "This route is advertised per EVI... It is used for aliasing and backup... It is also used for mass-withdrawal." This confirms the EVI-scoped functions of the A-D per EVI route, contradicting statement (D).

2. RFC 7432: BGP MPLS-Based Ethernet VPN, Section 8.2.1. Ethernet A-D per EVI Route.

This section specifies, "The Ethernet Tag ID is a 4-octet field that is set to 0." This confirms that statement (C) is true. The RFC also details how these routes are used for mass withdrawal and aliasing, confirming statement (A) is true.

3. Nokia 3HE 17175 AAAA TQZZA 01, SR OS 22.10 Services Architecture Guide, Chapter: EVPN for VPLS and Epipe services, Section: Ethernet A-D per EVI route advertisement.

This section states, "The Ethernet A-D per EVI route is advertised when an Ethernet-segment is configured on a SAP or SDP-binding and the SAP or SDP-binding is operationally up." This directly confirms that statement (B) is true.