I85PREP
⌘ K
Cisco SPVI 300-515 study materials
Cisco SPVI 300-515 study resources

Cisco SPVI 300-515 practice questions

One question at a time. Build your Cisco SPVI 300-515 understanding.

First 50 of 190 questions. Each one lists the choices, the correct answer, and an explanation. The checker at the top of this page saves progress in this browser when it is available.

Continue in the practice tool above to load more questions, 50 at a time.

Question 1Service-provider VPN architecture and underlay dependencies

For a pure Layer2 transport service compared with a conventional VRF-based Layer3 provider VPN, with no integrated routing/bridging assumed in the Layer2 service, which distinction is correct?

  1. L2VPN forwards customer IP packets using VRF route lookups, while L3VPN forwards Ethernet frames transparently
  2. L2VPN transports customer Ethernet frames transparently, while L3VPN performs IP routing for the customer using a per-customer VRF on the PE Correct answer.
  3. L2VPN always uses MP-BGP signaling, while L3VPN always uses LDP signaling
  4. L3VPN uses pseudowires between PEs, while L2VPN uses VPNv4 prefixes between PEs

Explanation

The pure Layer2 service transports the relevant customer frames while the conventional Layer3 VPN has provider-edge routing participation in the customer VRF. Integrated routing/bridging and composite services add roles, so the distinction does not mean a provider-edge device can never route any IP traffic.

Question 2Service-provider VPN architecture and underlay dependencies

In an Inter-AS L3VPN deployment, which statement best describes the difference between Intra-AS and Inter-AS designs?

  1. Intra-AS keeps PEs and the MPLS core inside one Autonomous System; Inter-AS interconnects VPN customers across multiple Autonomous Systems through ASBRs Correct answer.
  2. Intra-AS uses VPNv4 BGP and Inter-AS uses only VPNv6
  3. Intra-AS requires Option B; Inter-AS requires Option A
  4. Intra-AS does not use MP-BGP, while Inter-AS uses MP-BGP only on PEs

Explanation

Intra-AS L3VPN means every PE that imports/exports a given VRF lives in one AS with one IGP and one set of RRs. Inter-AS L3VPN extends customer VPNs between providers (or between AS regions of the same provider); the ASBRs at each AS edge exchange VPN routes using one of the four well-known options (A, B, AB, C).

Question 3Service-provider VPN architecture and underlay dependencies

A new L3VPN customer cannot reach remote sites and the operator suspects an underlay problem. Which two underlay components must be working before any VPN traffic can flow end-to-end? (Choose two.)

  1. Core IGP reachability between every PE loopback
  2. MP-BGP VPNv4 sessions between PEs
  3. An end-to-end LSP (LDP or SR) between ingress and egress PE loopbacks Correct answer.
  4. EVPN Type-2 routes for each customer prefix

Explanation

Without core IGP reachability between PE loopbacks, BGP sessions never form and recursive next hops never resolve. Without an LSP between PE loopbacks, MPLS forwarding fails at the ingress PE and traffic is dropped - the VPN label by itself cannot move the packet through P routers. MP-BGP VPNv4 and EVPN are overlay constructs that depend on a working underlay.

Question 4Service-provider VPN architecture and underlay dependencies

On Cisco IOS XR, which construct defines the Layer 2 attachment point for an EVC-style L2VPN service such as VPWS or EVPN?

  1. Service Instance under interface
  2. Ethernet Flowpoint (EFP) under l2transport sub-interface Correct answer.
  3. Bridge-domain interface (BDI)
  4. switchport mode trunk

Explanation

On IOS XR, an Ethernet Flowpoint (EFP) is configured as an l2transport sub-interface and matches one or more VLAN tags using encapsulation dot1q/dot1ad with optional rewrites. The EFP is the demarcation between the physical port and the L2VPN service (xconnect, bridge-domain, or EVPN AC). On IOS XE, the equivalent is the EVC service instance.

Question 5Service-provider VPN architecture and underlay dependencies

Which IOS XE construct is functionally equivalent to an IOS XR Ethernet Flowpoint for matching dot1q-tagged frames into an L2VPN service?

  1. MAC access-list
  2. Service Instance with encapsulation dot1q under the main interface Correct answer.
  3. Layer 3 sub-interface
  4. Port-channel load-balance configuration

Explanation

On IOS XE the Ethernet Virtual Circuit (EVC) model uses a Service Instance under the physical interface with encapsulation dot1q/dot1ad and optional rewrite ingress tag commands. The Service Instance is then bound to xconnect (VPWS), bridge-domain (E-LAN), or an EVPN/BD instance. This is the IOS XE counterpart of the IOS XR EFP.

Question 6Service-provider VPN architecture and underlay dependencies

In an L3VPN control plane, what is the role of the Route Distinguisher (RD)?

  1. It identifies which VRF imports the prefix on the receiving PE
  2. It is prepended to the IPv4 prefix to create a globally unique VPNv4 NLRI so MP-BGP can carry overlapping customer addresses Correct answer.
  3. It is the MPLS label imposed at the ingress PE for VPN traffic
  4. It selects the path used by traffic engineering

Explanation

An RD is a 64-bit value prepended to an IPv4 prefix to form a 96-bit VPNv4 NLRI (or to an IPv6 prefix to form a VPNv6 NLRI). RDs make customer prefixes unique within MP-BGP even when multiple customers reuse the same private addressing. RDs do not control import/export - that is the Route Target's job - and they are not labels.

Question 7Service-provider VPN architecture and underlay dependencies

Which three formats are valid for an MPLS L3VPN Route Distinguisher? (Choose the correct list.)

  1. Type 0: 2-byte ASN:32-bit number; Type 1: IPv4:16-bit number; Type 2: 4-byte ASN:16-bit number Correct answer.
  2. Type 0: MAC:VLAN; Type 1: 4-byte ASN; Type 2: IP:label
  3. Type 0: 4-byte ASN only; Type 1: 6-byte ESI; Type 2: 8-byte VNI
  4. Only one format exists: 32-bit IP:32-bit number

Explanation

RFC 4364 defines three RD encodings. Type 0 uses a 2-byte ASN with a 4-byte assigned number. Type 1 uses a 4-byte IPv4 address with a 2-byte assigned number. Type 2 uses a 4-byte ASN with a 2-byte assigned number for 4-byte ASN deployments. All three are 8 bytes total and prepend the customer prefix to form the VPNv4 NLRI.

Question 8Service-provider VPN architecture and underlay dependencies

Two customer sites are in VRFs with different RDs but matching import/export Route Targets. What is the result?

  1. Routes are still exchanged because RT, not RD, controls import/export Correct answer.
  2. Routes are not exchanged because the RDs do not match
  3. Routes are exchanged only if the PEs share a Route Reflector
  4. Routes are exchanged only if the PEs run iBGP IPv4 unicast

Explanation

RTs are extended communities attached to VPNv4 routes and they alone control import/export between VRFs. RDs make routes unique on the wire and never have to match between VRFs of the same customer. Many customer designs deliberately use a per-PE RD with shared RTs.

Question 9Service-provider VPN architecture and underlay dependencies

Which BGP extended community type carries the L3VPN Route Target?

  1. Standard community 0x0000
  2. Extended community of type Route-Target (0x0002 / 0x0102 / 0x0202) Correct answer.
  3. Large community only
  4. Origin attribute

Explanation

Route Targets are encoded as transitive extended communities of subtype 0x02 with type 0x00 (2-byte AS), 0x01 (IPv4), or 0x02 (4-byte AS). The 8-byte extended community is attached to VPNv4/VPNv6 routes and read by every PE that has a matching import RT in any VRF. Standard communities and large communities cannot carry RTs.

Question 10Service-provider VPN architecture and underlay dependencies

On the ingress PE in an L3VPN, what is the order of MPLS labels imposed on a customer packet?

  1. VPN label (inner), Transport label (outer) Correct answer.
  2. Transport label (inner), VPN label (outer)
  3. Only a single VPN label is used
  4. Only a single transport label is used

Explanation

The ingress PE pushes the VPN label first (inner, bottom of stack with S=1) so the egress PE can identify the destination VRF, then pushes the transport label (outer) used by the LDP/SR LSP across the core. P routers swap only the outer transport label; the inner VPN label is hidden until the egress PE pops PHP and reads the VPN label.

Question 11Service-provider VPN architecture and underlay dependencies

What is the purpose of BGP Additional Paths (Add-Path) in an L3VPN deployment?

  1. To allow MP-BGP to advertise multiple paths for the same prefix to a peer instead of only the best path Correct answer.
  2. To enable per-PE label allocation
  3. To replace LDP with SR
  4. To compute IGP shortest paths

Explanation

Add-Path lets a BGP speaker advertise more than one path for the same NLRI to a neighbor. In L3VPN, this allows route reflectors to distribute backup paths to PEs so PIC Edge can pre-compute alternate forwarding entries. Without Add-Path, the RR sends only the best path and PEs cannot install backups.

Question 12Service-provider VPN architecture and underlay dependencies

Which BGP feature reduces convergence time after a PE-PE or PE-CE failure by pre-installing backup paths in the FIB?

  1. BGP Prefix Independent Convergence (PIC) Correct answer.
  2. BGP confederations
  3. Soft reconfiguration inbound
  4. Maximum-paths ibgp

Explanation

BGP PIC pre-computes a backup next hop in the FIB so that when the primary fails, forwarding can be repaired in tens of milliseconds without waiting for BGP to reconverge. PIC Edge handles PE/CE failures and PIC Core handles core path failures. PIC requires Add-Path or BGP best-external to learn backups.

Question 13Service-provider VPN architecture and underlay dependencies

What does the term "Unified BGP/MPLS" describe in the L3VPN control plane?

  1. A model where BGP carries the labeled VPN prefixes and the underlay LSPs in one session, removing LDP from the equation when SR is used Correct answer.
  2. Combining IS-IS and OSPF into a single domain
  3. A method to replace MP-BGP with iBGP IPv4
  4. A Cisco-only feature that disables route targets

Explanation

Unified BGP/MPLS refers to designs where BGP signals both the service overlay (VPNv4/VPNv6) and labeled IPv4/IPv6 underlay prefixes (BGP-LU, RFC 8277) so a single BGP session pair carries everything an L3VPN needs. With Segment Routing as the data plane, LDP can be removed entirely, simplifying the architecture.

Question 14Service-provider VPN architecture and underlay dependencies

Which structure on a PE provides a per-customer Layer 3 forwarding instance with its own RIB and FIB?

  1. Bridge-domain
  2. VRF (VPN Routing and Forwarding instance) Correct answer.
  3. ESI
  4. VPLS instance

Explanation

A VRF is a per-customer routing and forwarding context on a PE. It has its own RIB, FIB, interface assignments, and (on most platforms) its own routing protocol instances. Each VRF is associated with an RD plus import/export RTs, and CE-facing interfaces are placed in the VRF with the vrf forwarding (or vrf) command.

Question 15Service-provider VPN architecture and underlay dependencies

Which protocol or method is most commonly used to advertise customer routes between a PE and a CE for an L3VPN?

  1. Only static routes are supported
  2. eBGP, OSPF (per-VRF process or capability vrf-lite), EIGRP, RIP, or static - chosen per customer Correct answer.
  3. Only iBGP between PE and CE
  4. Only LDP between PE and CE

Explanation

PE-CE routing supports eBGP (most common in carrier deployments), OSPFv2/v3 per-VRF (with sham-links and the OSPF down-bit on PEs), EIGRP per-VRF, RIPv2 per-VRF, and static routes. The PE redistributes the chosen PE-CE protocol into MP-BGP VPNv4 and back. iBGP and LDP are not used between PE and CE.

Question 16Service-provider VPN architecture and underlay dependencies

On the egress PE for an L3VPN packet, what determines into which VRF the packet is forwarded?

  1. The outer transport label
  2. The inner VPN label, which the egress PE assigned and advertised in MP-BGP Correct answer.
  3. The customer destination IP only
  4. The IGP next hop in the global table

Explanation

The egress PE allocated the VPN label when it advertised the VPN prefix; that label is locally significant and maps to either a specific VRF prefix (per-prefix label), a per-CE entry, or the entire VRF (per-VRF label). When the packet arrives, the PE pops the transport label, sees the VPN label, and uses it to choose the VRF or next hop.

Question 17Service-provider VPN architecture and underlay dependencies

A PE is configured with mpls label mode per-vrf. What is the operational impact?

  1. Each prefix in the VRF gets its own VPN label
  2. All prefixes in the same VRF share one aggregate VPN label, reducing label space at the cost of an extra IP lookup on the egress PE Correct answer.
  3. Labels are assigned only to summary routes
  4. VPN labels are no longer signaled in MP-BGP

Explanation

Per-VRF label allocation gives the entire VRF a single label. The egress PE pops the transport label, pops the VPN label to identify the VRF, then performs an IP lookup in that VRF for forwarding. This conserves label space (important on RR/ASBR scaling) but adds a recursive lookup compared with per-prefix labels.

Question 18Service-provider VPN architecture and underlay dependencies

Which statement about VPNv6 is correct?

  1. VPNv6 is only used for 6PE
  2. VPNv6 is the AFI/SAFI used by MP-BGP to carry IPv6 L3VPN prefixes (6VPE), with each prefix prepended by an 8-byte RD Correct answer.
  3. VPNv6 requires IPv4 underlay to be removed
  4. VPNv6 uses the same RD format as VPNv4 but disables RTs

Explanation

VPNv6 (AFI 2 SAFI 128) is the address family MP-BGP uses to carry IPv6 prefixes inside per-customer VRFs (6VPE). Like VPNv4, each prefix is prepended with an 8-byte RD and tagged with extended-community RTs. The underlay is typically IPv4 MPLS, so IPv6 packets are tunneled label-switched across an IPv4-only core.

Question 19Service-provider VPN architecture and underlay dependencies

An MPLS LSP between two PE loopbacks is broken even though OSPF reachability is fine. Which command is the most useful first check on Cisco IOS XR to confirm whether an end-to-end label exists?

  1. show ip route
  2. show ospf neighbor
  3. show mpls forwarding-table or show mpls forwarding (XR) for the remote PE loopback Correct answer.
  4. show running-config interface

Explanation

show mpls forwarding (IOS XR) or show mpls forwarding-table (IOS XE) tells you whether the local LSR has a labeled entry for the remote PE loopback. If the entry is missing or shows Untagged/Unlabeled, the LSP is broken even when OSPF reachability is intact. show ip route and show ospf neighbor only confirm IGP, not LSP.

Question 20Service-provider VPN architecture and underlay dependencies

Which statement about LDP label distribution is correct in a typical Cisco SP core?

  1. LDP advertises labels for every IGP prefix by default and uses TCP/646 for the session Correct answer.
  2. LDP only advertises labels for default routes
  3. LDP runs over UDP/646 with no TCP session
  4. LDP requires MP-BGP to operate

Explanation

By default LDP advertises labels for every IGP-learned prefix in the global table (downstream-unsolicited mode) and uses UDP/646 hello discovery plus a TCP/646 session to peers. Best practice is to filter LDP to advertise labels only for /32 PE loopbacks to prevent label exhaustion and LFIB bloat.

Question 21Service-provider VPN architecture and underlay dependencies

Why is the BGP next-hop for VPNv4 routes typically set to the advertising PE's loopback?

  1. Because customer-facing IPs change too often
  2. Because the loopback is the LSP endpoint that the underlay can reach with an MPLS label, and BGP requires recursive resolution to a labeled next hop Correct answer.
  3. Because LDP cannot label any other interface
  4. Because RDs require a loopback

Explanation

BGP next-hop reachability resolves recursively. For VPN traffic to be forwarded, the next hop must be in the IGP and have an LSP - that is the egress PE's loopback. If next-hop is set to a transit/CE address, no LSP exists and the VPN packet is dropped or punted.

Question 22Service-provider VPN architecture and underlay dependencies

In a VRF with import RT 65000:100 and export RT 65000:100, what happens if a sister PE exports a prefix with RT 65000:200?

  1. The prefix is installed because RDs match
  2. The prefix is filtered on receipt because no import RT matches Correct answer.
  3. The prefix is installed because RT is informational only
  4. The prefix is installed only if the sender uses the same router-id

Explanation

A receiving PE installs a VPNv4/VPNv6 route into a VRF only if at least one of the VRF's import RTs matches a route's attached RT. The local VRF imports 65000:100, the route carries 65000:200, so there is no match and the route is filtered.

Question 23Service-provider VPN architecture and underlay dependencies

Which IS-IS feature is typically deployed on a service provider core to give MPLS PEs full LSDB visibility while keeping the ABR boundary clean?

  1. Single Level-2 area for the core with route-leaking only where needed Correct answer.
  2. Disabling MPLS on the core
  3. Replacing IS-IS with RIP
  4. Per-customer IS-IS instance

Explanation

SP cores commonly run IS-IS as a single Level-2 backbone with all P/PE routers in the same area to provide a fully meshed LSDB and predictable LSP convergence. Where multi-area is required, route-leaking from L2 to L1 is used selectively. Per-customer IS-IS is not a thing; that is what VRFs and MP-BGP are for.

Question 24Service-provider VPN architecture and underlay dependencies

Which statement best describes the relationship between the underlay label and the VPN label in an L3VPN packet?

  1. They are the same label reused twice
  2. The underlay (transport) label is swapped hop by hop across the core, while the VPN label is only meaningful on the egress PE Correct answer.
  3. Both labels change at every hop
  4. The VPN label is removed by the first P router

Explanation

P routers swap only the outer transport label and never inspect the inner VPN label. The VPN label is allocated and consumed by the egress PE to choose the VRF or directly the egress next hop. With PHP, the penultimate hop pops the transport label; without PHP, the egress PE pops it itself.

Question 25Service-provider VPN architecture and underlay dependencies

An L3VPN customer reports complete black-hole. The PE shows the VPN route in BGP, the VRF, and the FIB, but pings still fail. Which is the next most likely cause?

  1. Customer IP overlap inside one VRF
  2. Missing or broken LSP between the two PE loopbacks Correct answer.
  3. MTU set to 9216 in the core
  4. RT mismatch with no routes installed at all

Explanation

If the route is in BGP, the VRF, and the FIB, the control plane is intact. A common cause of silent black-holing is a broken LSP - for example, LDP filtered loopbacks that exclude the remote PE. Without a label to the egress PE loopback, MPLS forwarding fails even though IP routing looks fine.

Question 26Service-provider VPN architecture and underlay dependencies

Which BGP attribute is NOT typically required for a VPNv4 route to be advertised between PEs?

  1. Route Distinguisher (in NLRI prepend)
  2. Route Target extended community
  3. Standard community 'no-export' (only required by policy) Correct answer.
  4. BGP next-hop (the advertising PE loopback)

Explanation

RD (in the NLRI), an RT extended community, and a BGP next-hop are required parts of any working VPNv4 advertisement. The standard community no-export is purely policy and is not required for normal L3VPN operation. Operators occasionally use it to constrain leaks but it is not part of the protocol baseline.

Question 27Service-provider VPN architecture and underlay dependencies

An operator wants to enable BGP PIC Edge for L3VPN. Which prerequisite is required?

  1. RR or PE must advertise more than one path per prefix using Add-Path or best-external Correct answer.
  2. All BGP timers must be set to 0
  3. OSPF must be replaced with IS-IS
  4. All ASBRs must run the same OS version

Explanation

PIC Edge needs at least two paths in the FIB. To get them, the BGP control plane must propagate a backup path - typically with Add-Path on iBGP (additional-paths send/receive plus advertise paths) or with best-external on PEs facing CEs. Without a backup path, PIC Edge has nothing to pre-install.

Question 28Service-provider VPN architecture and underlay dependencies

Which IS-IS or OSPF feature improves IGP convergence and is often deployed in SP cores to support fast L3VPN restoration?

  1. Loop-Free Alternates (LFA) and Remote LFA / TI-LFA on segment-routed cores Correct answer.
  2. RIP triggered updates
  3. Authoritative DNS
  4. BGP keepalive timer of 60s

Explanation

LFA (RFC 5286), Remote LFA, and TI-LFA (Topology Independent LFA, the SR-MPLS variant) pre-compute backup next-hops for IGP failures so the FIB can repair traffic in 50 ms order without waiting for full IGP reconvergence. This dramatically reduces the time L3VPN traffic is impacted by core failures.

Question 29Service-provider VPN architecture and underlay dependencies

A PE has VPN traffic dropping with "No label imposition" errors but the BGP VPNv4 table is healthy. Which underlay/control element should be checked first?

  1. LDP/SR-MPLS state for the egress PE loopback prefix - the system has no transport label Correct answer.
  2. OSPF area type
  3. BGP confederation membership
  4. VLAN encapsulation on the AC

Explanation

"No label imposition" means the FIB has no outer label for the BGP next-hop (egress PE loopback). LDP filters that excluded that loopback or SR-MPLS not labeling it are typical causes. show mpls forwarding-table for the egress PE loopback should show a labeled entry; if not, the underlay label distribution must be fixed.

Question 30Service-provider VPN architecture and underlay dependencies

Which statement best summarizes the modern Cisco SP VPN architecture covered by SPVI 300-515?

  1. All VPNs use static routes
  2. Layer 2 services are delivered with EVPN (replacing VPLS/AToM where possible) and Layer 3/IPv6 services use MP-BGP VPNv4/VPNv6 over an MPLS or SR underlay, with multicast extended via MVPN profiles and Inter-AS via Options A/B/AB/C Correct answer.
  3. All VPNs are point-to-point only
  4. EVPN replaces all L3VPN deployments

Explanation

The current SP VPN architecture combines EVPN-based L2 services (E-Line via EVPN VPWS, E-LAN via EVPN native or IRB, E-Tree via EVPN E-Tree), L3VPN via MP-BGP VPNv4/VPNv6 over an MPLS or Segment Routing underlay, MVPN profiles for multicast (Profile 0-14+ depending on PMSI), and Inter-AS connectivity via Options A, B, AB, and C. CSC supports carrier-of-carriers hierarchies. This is the SPVI v1.1 syllabus mapped to one architecture.

Question 31Layer2 provider services, pseudowires and EVPN

Which Metro Ethernet Forum service does an Ethernet point-to-point pseudowire (single AC on each PE) implement?

  1. E-LAN
  2. E-Line Correct answer.
  3. E-Tree
  4. E-Access

Explanation

E-Line is a point-to-point Ethernet service (EVPL or EPL) and maps directly to a VPWS pseudowire. E-LAN is multipoint-to-multipoint (VPLS or EVPN E-LAN). E-Tree is rooted multipoint where leaves cannot communicate with each other.

Question 32Layer2 provider services, pseudowires and EVPN

Which MEF service type is functionally equivalent to a multipoint-to-multipoint Ethernet bridged LAN across the WAN?

  1. E-Line
  2. E-LAN Correct answer.
  3. E-Tree
  4. Pseudowire

Explanation

E-LAN provides any-to-any Ethernet between sites and is implemented with VPLS (LDP or BGP-signaled) or EVPN E-LAN/Bridge Domain. The PEs maintain a MAC table per service and flood/learn customer MACs.

Question 33Layer2 provider services, pseudowires and EVPN

Which service blocks leaf-to-leaf traffic while allowing leaf-to-root and root-to-leaf forwarding?

  1. E-Line
  2. E-LAN
  3. E-Tree Correct answer.
  4. VPWS

Explanation

E-Tree is a rooted-multipoint service with two AC roles: Root and Leaf. Roots can talk to roots and leaves; leaves can talk only to roots. EVPN E-Tree implements this via per-AC role enforcement and split-horizon at the PE.

Question 34Layer2 provider services, pseudowires and EVPN

An L2VPN E-Line is built with AToM. Which AToM pseudowire types are supported?

  1. Only Ethernet
  2. Ethernet (raw mode), Ethernet VLAN (tagged mode), HDLC, PPP, ATM AAL5, Frame Relay, and TDM circuits via CESoPSN/SAToP Correct answer.
  3. Only HDLC and PPP
  4. Only ATM cell-mode

Explanation

Any Transport over MPLS (AToM) supports a broad set of PW types defined by IETF PWE3, including Ethernet (PW type 0x0005, raw/port mode), Ethernet VLAN (PW type 0x0004, VLAN/tagged mode), PPP, HDLC, ATM AAL5/cell, Frame Relay, and TDM via CESoPSN or SAToP. Cisco platforms expose these via xconnect with encapsulation mpls.

Question 35Layer2 provider services, pseudowires and EVPN

What is the difference between Ethernet raw-mode and Ethernet VLAN-mode AToM pseudowires?

  1. Raw mode preserves the customer dot1q tag transparently across the PW; VLAN mode strips the service tag at ingress and re-imposes it at egress Correct answer.
  2. Raw mode strips all tags; VLAN mode adds an outer SP tag
  3. Both modes are identical
  4. VLAN mode does not support multiple customers

Explanation

In raw mode (PW type 0x0005) the PE forwards the entire Ethernet frame including any service-delimiting VLAN tag, so the egress sees what the ingress sent. In VLAN mode (PW type 0x0004) the ingress PE pops the service-delimiting tag, the frame travels without it, and the egress PE imposes the tag configured on its AC. VLAN mode lets each PE use a different local VLAN for the same service.

Question 36Layer2 provider services, pseudowires and EVPN

Which two PW redundancy models are commonly used in MPLS L2VPN to protect against PE failure? (Choose the best description.)

  1. Active/Active only
  2. One-active (one PW forwards, others standby) and Primary/Backup (two PWs configured with explicit roles), both signaled via PW Status TLV Correct answer.
  3. Spanning-tree only
  4. VRRP between PEs

Explanation

AToM/L2VPN PW redundancy uses one-active (a redundancy group with multiple PWs where only one is active at a time) and Primary/Backup (the redundant configuration explicitly marks one PW as backup with a fast switchover when the primary fails). Both rely on the PW Status TLV (RFC 4447) to communicate forwarding state.

Question 37Layer2 provider services, pseudowires and EVPN

Which EVPN BGP route type signals MAC and optionally IP reachability for a host on an EVPN bridge-domain?

  1. Type 1 (Ethernet Auto-Discovery)
  2. Type 2 (MAC/IP Advertisement) Correct answer.
  3. Type 3 (Inclusive Multicast Ethernet Tag)
  4. Type 5 (IP Prefix)

Explanation

Type 2 routes carry a customer MAC (and optionally a host IP for ARP/ND suppression and IRB) per EVI/bridge-domain. They replace classical flood-and-learn with control-plane learning, support MAC mobility via the MAC Mobility extended community, and can be paired with EVPN IRB to also route traffic between subnets.

Question 38Layer2 provider services, pseudowires and EVPN

Which two EVPN route types together enable Active/Active multihoming aliasing and fast mass-withdrawal? (Best answer.)

  1. Type 2 and Type 3
  2. Type 1 (per-EVI Ethernet AD for aliasing) and Type 1 (per-ES Ethernet AD for mass withdrawal) Correct answer.
  3. Type 4 and Type 5
  4. Type 3 and Type 5

Explanation

EVPN multihoming uses two flavors of Type 1 (Ethernet Auto-Discovery). Per-EVI AD signals a remote PE that a given PE has the EVI on the ES (used for aliasing - load-sharing toward the multihomed CE). Per-ES AD lets a PE quickly withdraw all MACs behind an Ethernet Segment with a single update on link failure (mass withdrawal).

Question 39Layer2 provider services, pseudowires and EVPN

Which EVPN route type elects the Designated Forwarder on a multihomed Ethernet Segment?

  1. Type 1
  2. Type 2
  3. Type 3
  4. Type 4 (Ethernet Segment route) Correct answer.

Explanation

Each PE attached to an Ethernet Segment advertises a Type 4 ES route carrying the ESI. PEs on the same ESI use these routes to discover peers and run the DF election (modulo of ordinal IDs) so exactly one PE forwards BUM to the CE per VLAN.

Question 40Layer2 provider services, pseudowires and EVPN

Which EVPN route type is used by EVPN-IRB to advertise a customer IP prefix from a PE without an Ethernet Segment context?

  1. Type 2
  2. Type 3
  3. Type 5 (IP Prefix) Correct answer.
  4. Type 4

Explanation

Type 5 carries an IP prefix (with VRF/RT context) and decouples L3 reachability from the host's Ethernet Segment. It is used for summarized prefixes, default routes, and external L3 reachability in EVPN-IRB designs and for DCI use cases.

Question 41Layer2 provider services, pseudowires and EVPN

How is an EVPN Ethernet Segment Identifier (ESI) encoded?

  1. 5 bytes total
  2. 10 bytes: a 1-byte type field followed by a 9-byte value Correct answer.
  3. 8 bytes total like an RD
  4. 4 bytes only

Explanation

An ESI is 10 bytes: 1 byte of Type (0 = manual, 1 = LACP-derived, 2 = bridge MAC + priority, 3 = MAC + local discriminator, 4 = router-id-based, 5 = AS-based) followed by 9 bytes of value. The full ESI uniquely identifies a multihomed Ethernet Segment across PEs.

Question 42Layer2 provider services, pseudowires and EVPN

Which two EVPN multihoming modes are defined in RFC 7432?

  1. Single-Active and All-Active (sometimes called Active/Active) Correct answer.
  2. Active/Idle only
  3. Primary/Backup only
  4. STP-only

Explanation

EVPN supports Single-Active multihoming (only the elected DF forwards traffic to/from the CE per VLAN) and All-Active multihoming (every PE on the ES forwards in parallel using LACP or per-flow load balancing on the CE). All-Active is enabled by aliasing and split-horizon labels to prevent loops.

Question 43Layer2 provider services, pseudowires and EVPN

What is ARP/ND suppression in EVPN?

  1. Disabling ARP completely
  2. PEs answer local ARP/ND requests using the IP-to-MAC bindings learned via Type 2 routes, suppressing ARP/ND flood across the EVPN core Correct answer.
  3. Filtering all broadcast at the CE
  4. Disabling Type 2 routes

Explanation

When PEs learn host MAC and IP via EVPN Type 2 routes, they can answer ARP/ND requests locally on behalf of the remote host. Broadcasts are not flooded across the WAN, reducing BUM traffic and improving DC scaling. The local PE proxies the reply using the BGP-learned MAC/IP binding.

Question 44Layer2 provider services, pseudowires and EVPN

Which two underlay traffic-engineering options are commonly used with EVPN to steer service traffic across the SP core? (Choose the best.)

  1. RSVP-TE and Segment Routing TE (SR-TE) with IS-IS or OSPF Correct answer.
  2. STP and LACP
  3. DHCP and DNS
  4. VRRP and HSRP

Explanation

EVPN runs over an MPLS or SR underlay. Operators steer EVPN traffic with RSVP-TE (classic explicit-path tunnels with reservation state) or SR-TE (stateless source routing using SID lists) computed from the IS-IS/OSPF TE topology, often via PCE/SR-PCE. Both can carry service traffic with specific bandwidth or path constraints.

Question 45Layer2 provider services, pseudowires and EVPN

What is the role of CFM (IEEE 802.1ag) in Carrier Ethernet OAM?

  1. It is a control protocol for VPLS only
  2. It defines Maintenance Domains, Maintenance Associations, MEPs, and MIPs to enable end-to-end fault detection (CCM), loopback (LBM/LBR), and linktrace (LTM/LTR) across an Ethernet service Correct answer.
  3. It is identical to IS-IS
  4. It replaces LACP

Explanation

Connectivity Fault Management (IEEE 802.1ag, also ITU-T Y.1731) is the standardized E-OAM toolset for Ethernet services. It defines Maintenance Domains/Levels, MAs, MEPs (endpoints), MIPs (intermediate points), and uses CCMs for liveness, LBM/LBR for ping-style checks, and LTM/LTR for traceroute-style fault localization end-to-end on an EVC.

Question 46Layer2 provider services, pseudowires and EVPN

Which Y.1731 OAM message provides per-frame delay and delay-variation measurement on an Ethernet service?

  1. CCM
  2. DMM/DMR (Delay Measurement) Correct answer.
  3. LBM/LBR
  4. LTM/LTR

Explanation

ITU-T Y.1731 extends 802.1ag with performance OAM. DMM (Delay Measurement Message) and DMR (response) compute one-way and two-way frame delay and delay variation across the service. LMM/LMR perform loss measurement. CCM, LBM, LTM are for fault management.

Question 47Layer2 provider services, pseudowires and EVPN

Which EVPN configuration mode places a Layer 3 BVI/BDI inside a VRF and lets the PE bridge intra-subnet and route inter-subnet customer traffic?

  1. EVPN VPWS
  2. EVPN IRB (Integrated Routing and Bridging) Correct answer.
  3. EVPN native E-Line
  4. EVPN E-Tree

Explanation

EVPN IRB configures a bridge-domain with EVPN encapsulation plus a BVI (or BDI) interface placed in a VRF. Intra-subnet frames are bridged via Type 2 MAC routes; inter-subnet packets are routed by the BVI using the VRF's routing table (often with Type 5 prefix routes). This is the standard EVPN-VXLAN/MPLS DC and metro design.

Question 48Layer2 provider services, pseudowires and EVPN

What is EVPN VPWS?

  1. A multipoint EVPN service replacing VPLS
  2. An EVPN-signaled point-to-point pseudowire (E-Line) using Type 1 routes per AC, replacing AToM/Kompella with BGP-only signaling Correct answer.
  3. An IRB-only feature
  4. A flooding-only mode

Explanation

EVPN VPWS (RFC 8214) provides a point-to-point Ethernet service signaled entirely by BGP EVPN with Ethernet AD per-EVI Type 1 routes. It replaces LDP-based AToM and BGP/Kompella VPWS with a single, unified BGP control plane and supports active/active multihoming using flow-aware transport (FAT) PW labels and aliasing.

Question 49Layer2 provider services, pseudowires and EVPN

What is an EVPN "native" deployment most commonly understood to mean on Cisco platforms?

  1. EVPN with VXLAN encapsulation only
  2. An EVPN bridge-domain providing E-LAN service over MPLS without IRB, where the PE bridges between local ACs and remote PEs using EVPN Type 2/3 routes Correct answer.
  3. Only point-to-point services
  4. A non-BGP variant of EVPN

Explanation

EVPN native (sometimes "EVPN bridging" or "E-LAN native") is the L2-only EVPN service where the PE bridges customer frames using Type 2 MAC routes for known unicast and Type 3 routes for BUM. There is no BVI in the customer VRF; routing happens elsewhere (CE or central GW). It is the most direct VPLS replacement.

Question 50Layer2 provider services, pseudowires and EVPN

On IOS XR an L2VPN bridge-domain shows that no MACs are being learned over the EVPN core, but Type 3 IMET routes are present. Which check is most relevant next?

  1. Verify that Type 2 MAC/IP advertisements are being received and that the EVI (rt-set) matches between PEs Correct answer.
  2. Disable LDP
  3. Re-create the loopback interface
  4. Switch the AC to L3 sub-interface

Explanation

Type 3 IMET handles BUM replication and tells you the BUM tree is set up. But unicast MAC learning depends on Type 2 routes carrying the MAC (and optionally IP). If Type 2 advertisements are missing, RTs may not match, the EVI may differ, advertise-mac may be off, or the local AC is not learning MACs in the first place.