4A0-115 Practice Questions

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.

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.

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.

The topology depicts a BGP-signaled Virtual Private Wire Service (VPWS) using EVPN signaling, which is a modern approach for establishing Layer 2 point-to-point services. In this model, BGP is used for both service discovery (EVPN routes) and for establishing the transport tunnels (BGP Labeled Unicast).

Service Distribution Points (SDPs) are transport tunnels used in legacy VLL/VPLS services that are signaled using Targeted LDP (T-LDP). When BGP is used for both service and transport signaling (as implied by the MP-BGP sessions for EVPN and labeled routes), the concept of a manually configured SDP is obsolete. The router automatically resolves the BGP next-hop of the remote PE over a labeled path learned via BGP-LU, eliminating the need for SDP configuration.

A: An MP-BGP session carrying EVPN routes is mandatory. It is the control plane mechanism used by PE1 and PE2 to advertise their local attachment circuits and discover each other to establish the VPWS pseudowire.

B: An MP-BGP session exchanging IPv4 labeled routes (BGP-LU) is required to build the MPLS transport tunnels between PEs. This allows PE1 to resolve the BGP next-hop for PE2 (and vice-versa) to a labeled path through the core.

D: Configuring Attachment Circuits (ACs) on the terminating PEs (PE1 and PE2) is fundamental. The ACs are the local interfaces that connect to the customer devices (CE1 and CE2) and bind them to the VPWS service instance.

1. Nokia 3HE17176AAABTQZZA 01 - SR OS R21.x Services Guide (Part 1), Section 5.3.1. "EVPN-VPWS": This section describes the architecture of EVPN-VPWS. It states, "EVPN-VPWS uses BGP for auto-discovery and signaling." It details the use of EVPN route types for this purpose and makes no mention of SDPs. The transport is described as MPLS or VXLAN, with MPLS transport relying on BGP next-hop resolution over labeled paths.

2. Nokia 3HE17176AAABTQZZA 01 - SR OS R21.x Services Guide (Part 1), Section 3.2. "Service Distribution Points (SDPs)": This section explicitly defines SDPs and their usage. It states, "An SDP is a logical way to direct traffic from one 7x50 SR to another through a unidirectional service tunnel... SDPs are configured on the router, which binds a service to the SDP." This is characteristic of T-LDP signaled services, not BGP-EVPN.

3. Nokia 3HE17178AAABTQZZA 01 - SR OS R21.x Routing Protocols Guide, Section 10.10. "BGP Labeled Unicast": This section details the exchange of labeled IPv4 and IPv6 routes. It explains, "BGP-LU can be used to create transport tunnels for services such as VPRN, BGP-EVPN, and VPLS." This confirms that BGP-LU is the mechanism for creating the transport path, replacing the need for SDPs in this context.

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 the EVPN Layer-3 interface-ful model, each subnet is configured as a separate VPLS service with an associated Integrated Routing and Bridging (IRB) interface within a VPRN. To handle inter-subnet (routed) traffic between different PEs, a special VPLS instance known as the Supplementary Broadcast Domain (SBD) is used. The SBD acts as a transport VPLS that interconnects all the IRB interfaces belonging to the same VPRN service across the participating PEs. When a packet needs to be routed from one subnet to another on a remote PE, it is forwarded over the SBD tunnels to the IRB interface on the destination PE.

A. EVPN MAC/IP routes (Route Type 2) advertise host-specific information (MAC and IP addresses), not the IP prefixes of entire subnets. Subnet prefixes are advertised using EVPN IP Prefix routes (Route Type 5).

C. Intra-subnet traffic is Layer 2 bridged traffic that remains within the VPLS service designated for that specific subnet. The SBD is exclusively used for carrying inter-subnet (Layer 3 routed) traffic between PEs.

D. MAC/IP route information is used to populate the Forwarding Database (FDB) for MAC learning and the ARP/ND cache on remote PEs for host resolution. The VPRN routing table is populated by IP Prefix routes (Route Type 5).

1. Nokia 7750 SR OS Services Architecture Guide, Release 21.10.R1, Section: "EVPN for VXLAN in a VPRN service", Subsection: "Interface-ful IP-VRF-to-VLAN model".

This section explicitly states: "The SBD is a VPLS service that connects all the IRB interfaces of the VPRN service. When a PE needs to send a routed packet to a remote PE, it sends it through the SBD." This directly supports option B.

The guide also clarifies: "Each subnet is associated with a VPLS service where the Layer 2 traffic is bridged." This refutes option C, as intra-subnet traffic is handled by the subnet's own VPLS, not the SBD.

Regarding route types, it specifies: "The PE also advertises the IRB subnet using an EVPN IP Prefix Route." This refutes option A. It also explains that MAC/IP routes are for the IRB's own MAC/IP, which populates the FDB/ARP cache, refuting option D.

In the interface-ful unnumbered forwarding model for Layer-3 EVPN, IP-Prefix routes (EVPN Route Type 5) are advertised with the Gateway IP address field in the NLRI set to 0.0.0.0. The router's MAC address, which is essential for forwarding, is carried in the BGP Router's MAC Extended Community attribute, not directly in the NLRI as a primary field. While the MAC address is used by the receiving PE to forward traffic, referring to it as an "overlay index" can be misleading. The primary overlay index is the VNI (VXLAN Network Identifier), which identifies the forwarding context (the SBD). The statement that the route includes a non-zero MAC address as an overlay index is the most imprecise and therefore considered false in the context of strict terminology where the VNI is the primary index.

A. This is a true statement. A Type-2 MAC/IP route is advertised with the SBD IRB's MAC address and a null IP address to enable remote PEs to resolve the gateway MAC for inter-subnet traffic.

C. This is a true statement. For a VPRN to participate in Layer-3 EVPN and exchange subnet reachability, it must be explicitly configured to advertise IP prefixes into the BGP EVPN address family.

D. This is a true statement. The term "unnumbered" in this model's name specifically means that the SBD's Integrated Routing and Bridging (IRB) interface is not configured with its own IP address.

1. Nokia 7x50 SR OS Services Guide, Release 22.10.R1, "EVPN for VXLAN in a VPRN service" section, page 161

In a single-homed EVPN VPWS (Virtual Private Wire Service), when the local attachment circuit (AC) becomes operationally active, the Provider Edge (PE) router signals the service availability to remote PEs. It does this by advertising an Ethernet Auto-Discovery (A-D) per EVI route (Type 1). This route must contain two critical pieces of information: a non-zero Ethernet Tag ID, which uniquely identifies the service instance on the advertising PE, and a non-zero, downstream-assigned MPLS label. The remote PE uses this advertised label to encapsulate and forward traffic destined for the local AC, thus establishing the data plane for the point-to-point service.

A. The Ethernet Tag ID is locally significant to each PE. While they can be the same, it is not a requirement; each PE can use a different tag ID for its end of the VPWS.

B. EVPN VPWS is a point-to-point service that does not perform MAC learning. Therefore, it only uses Ethernet A-D per EVI routes for service signaling, not MAC/IP Advertisement routes (Type 2).

D. A PE uses the received tag ID to identify the remote endpoint of the VPWS service. It does not compare the received tag ID with its own locally configured tag ID.

1. Nokia 7750 SR OS Services Guide, Release 21.10.R1, Section: EVPN-VPWS for Epipe Services.

Page 1038: "When the SAP is up, the PE advertises a single Ethernet A-D per EVI route... The route includes the configured eth-tag, a VTEP address, and a downstream-assigned MPLS label." This supports that a non-zero tag and label are advertised (Answer C) and contradicts the use of MAC routes (Answer B).

2. RFC 8214: Virtual Private Wire Service Support in Ethernet VPN, Section 5.1. Ethernet A-D per EVI Route Advertisement.

Paragraph 2: "The Ethernet Tag ID is set to the service-instance identifier of the E-Line service... The MPLS Label field is set to a valid, non-zero MPLS label." This directly confirms that the advertised route includes a non-zero tag ID and a non-zero MPLS label (Answer C).

3. Nokia 7750 SR OS Services Guide, Release 21.10.R1, Section: EVPN-VPWS single-homing.

Page 1038: The configuration examples show that the eth-tag is configured locally on each PE under the bgp-evpn context of the Epipe service. The text does not mandate that the local and remote tag IDs must be identical, invalidating option A and D's premise of matching local tags.

Statement D is false because PE4 is a VPRN-only Provider Edge (PE) router and is not part of the EVPN domain. Therefore, it has no EVPN functionality and cannot originate or advertise EVPN route types, such as an IP-Prefix route (Route Type 5). Furthermore, the network topology shows no BGP peering session between PE4 and PE2. PE4 advertises its locally attached prefixes to PE3 using standard VPN-IPv4 BGP updates within the VPRN service. The entire premise of the statement is architecturally incorrect.

A. This statement is false. PE1, acting as the gateway, advertises prefixes learned from the EVPN domain to its VPRN peer (PE3) using standard VPN-IPv4 routes, not EVPN IP-Prefix routes.

B. This statement is false. PE1 advertises its IRB MAC address (MAC-01) within the EVPN domain (to PE2) using an EVPN MAC/IP route to enable gateway reachability, not to its VPRN peer (PE3).

C. This is a true statement. PE3 learns the route for 10.10.1.0/24 from PE1 as a VPN-IPv4 route and advertises it to its VPRN peer, PE4. This BGP update includes an MPLS service label as per standard L3VPN procedures.

1. Nokia 7x50 SR OS Services Guide, Release 21.10.R1, "EVPN for DCI" section, Subsection "VPRN and EVPN-IRB gateway". This section details the interworking between VPRN and EVPN services. It explains that routes learned from the EVPN domain are installed in the VPRN routing table and advertised to other VPRN PEs as vpn-ipv4 routes. Conversely, VPRN routes are advertised into the EVPN domain as EVPN IP-Prefix routes (Type 5). This confirms that PE1 advertises VPN-IPv4 routes to PE3 (making A and B false) and that a VPRN-only PE like PE4 cannot generate EVPN routes (making D false).

2. Nokia 7x50 SR OS BGP Configuration Guide, Release 21.10.R1, "BGP support for VPRN" section. This guide describes the standard operation of VPRN services, confirming that BGP peers exchange vpn-ipv4 or vpn-ipv6 address family updates, which include a unique MPLS label for each prefix. This supports the correctness of statement C.

3. RFC 7432, "BGP MPLS-Based Ethernet VPN", Section 9.2.2, "IP Prefix Advertisement". This RFC defines the EVPN IP Prefix route (Type 5), which is used to advertise IP prefixes within an EVPN domain. The document specifies its use among EVPN PEs, not between an EVPN gateway and a legacy VPRN PE over a VPRN-specific session, reinforcing why statements A and D are incorrect in this context.