4A0-115: Nokia Ethernet Virtual Private Network ServicesDemo

In the interface-ful unnumbered EVPN-IRB model, EVPN Type-5 (IP-Prefix) routes are advertised under the route target(s) of the Layer-3 IP-VRF (VPRN) service, carrying the advertising PE's own IRB MAC address as the overlay index. However, the EVPN Type-2 MAC/IP route needed to resolve that MAC overlay index is generated and exported by the Layer-2 bridging instance (the R-VPLS/EVI) to which the IRB is bound — in this topology, R-VPLS 20 on PE1 — using that bridge instance's own configured route target, not the route target configured on VPRN 15. Therefore the claim that PE1's MAC route advertisement for MAC-01 carries the route target configured for VPRN 15 is incorrect, since the Layer-2 EVI and the Layer-3 VPRN are distinct services with independent route-target configuration.

In all-active EVPN multihoming, a non-DF PE forwards BUM traffic received from a multihomed CE to the other PEs in the EVI, including the DF. For ingress-replication tunnels, the ingress PE attaches the ESI split-horizon label only to packets sent to PEs that are connected to the same Ethernet segment. Therefore, PE1 sends copies to PE2 and PE3, with the ESI label only on the copy to PE3; PE3 uses it to prevent flooding back to ESI1. Juniper EVPN Multihoming Overview

In EVPN (RFC 7432), MAC mobility is handled via the control plane using the MAC Mobility extended community attached to MAC/IP Advertisement routes. When PE2 detects that CE1 (and MAC1) has moved to its local segment, it advertises a MAC/IP route for MAC1 with a sequence number higher than the one previously advertised by PE1. This higher sequence number tells all other PEs in the EVPN instance that PE2's advertisement is the most current one, causing them to update their forwarding databases to point to PE2 and causing PE1 to withdraw its now-stale route for MAC1.

In a VPLS/EVPN deployment, proxy-ARP/ND table entries for locally attached hosts are created by snooping ARP, Gratuitous ARP, or IPv6 Neighbor Advertisement messages received on local SAPs/SDP bindings (i.e., from CEs directly attached to that PE), not by snooping IP data packets arriving from remote PEs over the core. Once a local entry is learned, the PE advertises that host's MAC and IP address to remote PEs via a BGP EVPN MAC/IP Advertisement (Route Type 2) route. Remote PEs then populate their own proxy-ARP/ND tables with these EVPN-learned entries by importing the received BGP routes — this is a control-plane mechanism, not data-plane snooping of IP traffic from remote PEs. Traffic arriving on core-facing/network interfaces from remote PEs is explicitly excluded from ARP/ND snooping in standard implementations. Therefore, the statement claiming the proxy-ARP table is populated by snooping IP packets received from remote PEs is incorrect.

RFC 8214 specifies that EVPN-VPWS uses only Ethernet Auto-Discovery (A-D) per-EVI routes (Type 1) — it does not use MAC/IP Advertisement routes, since no MAC learning or lookup is required for a point-to-point VPWS service. When a PE advertises its per-EVI A-D route, the Ethernet Tag ID field must always be set to a non-zero value, representing the locally significant VPWS service instance identifier for that PE's attachment circuit, and the route also carries a non-zero MPLS label that the remote PE uses in the data plane to forward traffic to the correct egress AC. The two PEs' local AC tag/VLAN values do not need to match each other; EVPN-VPWS does not require tag translation or verification between PEs — the MPLS label, not the tag value, identifies the destination AC.