Cisco Service Provider VPN Services Implementation Specialist — Practice Set 1

Question 1

On an IOS XR PE router, a network engineer needs to create a VRF named CUSTOMER-A with Route Distinguisher 65000:100 and import/export Route Target 65000:100. Which IOS XR VRF configuration is correct?

Accepted Answer

IOS XR VRF configuration uses 'vrf NAME' at the global level, 'rd X:Y' for the route distinguisher, and 'address-family ipv4 unicast' with 'import route-target' and 'export route-target' sub-commands for the RT values. Option B uses 'ip vrf' which is the classic IOS syntax, not IOS XR. Option C uses 'vrf definition' which is IOS-XE syntax. Option D uses 'route-distinguisher' (wrong keyword) and 'route-target both' which are not valid IOS XR VRF commands — IOS XR uses 'rd' and separate import/export statements.

Question 2

In an MPLS L3VPN, every VRF on every PE router must have a unique Route Distinguisher (RD). What is the primary purpose of the RD in VPNv4?

Accepted Answer

The Route Distinguisher (RD) is an 8-byte value prepended to a 4-byte IPv4 prefix to form a 12-byte (96-bit) VPNv4 address (RD:prefix). Its sole purpose is to make overlapping private IPv4 addresses from different customers globally unique in the BGP VPNv4 table — two customers can both use 10.0.0.0/8 and they will have different VPNv4 addresses based on their RDs. Import and export decisions are made by Route Targets (RTs), not RDs. The VPN label that identifies the VRF on the egress PE is a separate MPLS inner label allocated per-VRF or per-prefix. RD values have no bearing on BGP path preference or administrative distance.

Question 3

An IOS XR PE router runs OSPF as the PE-CE routing protocol for a VPN customer. The customer has a backdoor link between two CE routers in the same OSPF domain. The PE router is redistributing OSPF routes into MP-BGP and back. When the CE router on one side receives the customer prefix via both the direct OSPF path and the VPN path, it prefers the OSPF path correctly. However, when the backdoor link fails, the CE never uses the VPN backup path. What OSPF feature on the PE should be configured to solve this?

Accepted Answer

The issue is the OSPF down-bit (DN bit). Routes redistributed from BGP into OSPF on a PE are marked with the DN bit set, causing other PE routers not to redistribute these routes back into BGP (preventing loops). When the CE receives routes via the VPN backbone, they appear as OSPF external (type 5 or 7) routes, which have higher cost than intra-area or inter-area routes through the backdoor link. An OSPF sham-link is a logical link configured between PE routers running through the MPLS backbone — it makes the VPN backbone appear as an OSPF intra-area link so the cost comparison is equal to (and can supersede) the backdoor link. Without the sham-link, OSPF external routes from the VPN always lose to internal OSPF routes via the backdoor, leaving no functional backup.

Question 4

In an MPLS L3VPN, PE1 receives a VPNv4 prefix from CE1 and redistributes it into MP-BGP. PE2 is a route reflector client. The RR reflects the VPNv4 prefix to PE2. PE2 receives the prefix but cannot reach the NEXT_HOP address. Which command on PE1 or the RR would resolve this if the issue is that PE2 cannot resolve the PE1 loopback used as NEXT_HOP?

Accepted Answer

In MPLS L3VPN, the VPNv4 NEXT_HOP is the PE1 loopback address. PE2 resolves this NEXT_HOP via the IGP (IS-IS or OSPF) and must have an MPLS transport label (LDP or SR Prefix-SID) for PE1's loopback to build the label stack (outer transport label + inner VPN label). If PE2 cannot resolve the NEXT_HOP, the root cause is that PE1's loopback is not reachable in the IGP or the transport LSP label is missing — not a BGP configuration issue. Configuring 'next-hop-self' on PE1 for VPNv4 (option A) is unusual; it is commonly needed for iBGP where NEXT_HOP is not updated, but in a standard SP L3VPN the RR preserves the NEXT_HOP as the originating PE's loopback, which is the correct behavior. The real fix is IGP reachability and transport LSP. 'next-hop-self' on the RR (option B) would break L3VPN because it would replace PE1's address with the RR's address, causing traffic to terminate at the RR.

Question 5

A service provider implements an MPLS L3VPN hub-and-spoke topology for a customer. The hub site must see all spoke-site prefixes, and spoke sites must communicate with each other only through the hub. Which Route Target engineering achieves this?

Accepted Answer

In hub-and-spoke L3VPN, traffic between spokes must traverse the hub. The RT engineering requires asymmetric import/export: spoke PEs export their routes with a 'spoke' RT (e.g., 65000:200) and import only the 'hub' RT (65000:100) — they cannot import other spokes' routes directly. The hub PE imports the spoke RT (65000:200) to learn all spoke routes and exports them with the hub RT (65000:100) so that spokes can reach the hub and each other via the hub. The hub PE effectively re-originates spoke routes with the hub export RT. Using the same RT everywhere (option A) creates a full-mesh, not hub-and-spoke. RD wildcards (option C) do not exist in BGP. BGP community-based suppression (option D) would require additional route policy complexity and does not scale properly for hub-and-spoke topology enforcement.

Question 6

A service provider needs to connect two MPLS L3VPN domains belonging to different service providers using Inter-AS Option B. Which characteristic accurately describes Inter-AS L3VPN Option B?

Accepted Answer

Inter-AS L3VPN Option B uses eBGP VPNv4 sessions between the ASBRs of the two service provider networks. Each ASBR accepts VPNv4 routes from its own AS's RR and advertises them to the other AS's ASBR via eBGP with VPNv4 unicast address family. Critically, the ASBR re-labels (reallocates a new local VPN label) the VPNv4 prefixes before advertising them to the peer ASBR — this provides label independence and allows each ASBR to maintain its own label space. Option B describes Inter-AS Option A (back-to-back VRFs), which is a different (and simpler but less scalable) inter-AS method. Option C describes Inter-AS Option C (multi-hop eBGP between PEs with labeled unicast). Option D does not correspond to any standard inter-AS architecture.

Question 7

In a Carrier Supporting Carrier (CSC) architecture, a customer carrier (CC) runs its own MPLS network and needs to carry its own labeled traffic across the backbone carrier (BC). Which mechanism does the backbone carrier use to exchange labels with the customer carrier's CE routers?

Accepted Answer

In the CSC model, the backbone carrier PE (BC-PE) must exchange MPLS labels with the customer carrier CE (CC-CE) routers so that the CC's labeled traffic can traverse the BC MPLS core. This is done using either LDP between BC-PE and CC-CE (if they are directly connected) or BGP IPv4 labeled unicast (RFC 3107 — 'neighbor send-label' capability) to distribute transport labels to the CC-CE. The BC then carries the CC's label stack using its own outer transport labels. Option B describes a regular L3VPN which does not support carrying the CC's own MPLS labels intact across the BC. GRE tunnels (option C) could carry labeled packets but are not the standard CSC mechanism. RSVP-TE CC-PE to CC-PE tunneling (option D) would require CC-PE routers to have IGP reachability across the BC domain.

Question 8

An IOS XR PE router has a VRF configured with BGP as the PE-CE protocol. The operator needs to redistribute connected routes from the VRF into BGP for the CE. Under 'router bgp 65000', inside 'vrf CUSTOMER-A', which redistribution command is used on IOS XR?

Accepted Answer

On IOS XR, per-VRF redistribution into BGP is configured within the BGP VRF stanza. The hierarchy is: 'router bgp 65000' → 'vrf CUSTOMER-A' → 'address-family ipv4 unicast' → 'redistribute connected'. This redistributes connected routes within VRF CUSTOMER-A's routing table into BGP for advertisement to the CE or into VPNv4 for the SP backbone. Global redistribution under 'router bgp' (option B) does not target a specific VRF. The 'vrf' global stanza (option C) does not accept redistribution commands. VPNv4 address family (option D) carries inter-PE VPN routes, not PE-CE redistribution.

Question 9

In an MPLS L3VPN, PE2 receives a VPNv4 UPDATE from the RR for prefix 10.1.1.0/24 in VRF CUSTOMER-A. The VPNv4 NLRI carries extended community RT 65000:100. PE2's VRF CUSTOMER-A has 'import route-target 65000:100' configured. What happens next on PE2?

Accepted Answer

When PE2 receives a VPNv4 UPDATE and the RT in the extended community matches an import RT on a local VRF, PE2 installs the prefix (stripped of the RD) into that VRF's routing table. The VPN label carried in the NLRI's label field is used as the inner MPLS label to identify the VRF or prefix on the egress PE1. The outer transport label to reach PE1's loopback is provided by the IGP/LDP or SR label for PE1's loopback. This two-label stack (outer = transport to PE1, inner = VPN label) is how MPLS L3VPN forwarding works. The prefix goes into the VRF routing table, not the global table. BGP installation happens independently of CE advertisement and does not require a ROUTE-REFRESH.

Question 10

An IOS XR PE router needs to configure an MPLS pseudowire connecting to PE2 (10.0.0.2) with pseudowire ID 100 using MPLS encapsulation. Which IOS XR L2VPN configuration stanza creates this point-to-point pseudowire?

Accepted Answer

IOS XR L2VPN pseudowire configuration uses the 'l2vpn' global configuration block with an 'xconnect group' containing 'p2p' entries. Under the p2p entry, you specify the 'neighbor ipv4' (remote PE) and 'pw-id' (pseudowire ID) along with the 'interface' attached to this pseudowire. Option B mixes IOS pseudowire-class syntax with IOS XR l2vpn syntax and is not valid. Option C uses 'xconnect' directly under the interface which is IOS syntax, not IOS XR. Option D uses 'l2 vfi' which is the VPLS configuration syntax for IOS, not an IOS XR point-to-point pseudowire command.

Question 11

A service provider configures VPLS using BGP signaling on IOS XR. In a full-mesh VPLS core with PEs PE1, PE2, and PE3, PE1 receives a MAC frame destined for an unknown unicast MAC address. What does PE1 do with this frame under VPLS split-horizon rules?

Accepted Answer

In VPLS, a PE receiving an unknown unicast frame (BUM — Broadcast, Unknown unicast, Multicast) on a local access interface floods it to all other VPLS members: all other pseudowires (PE2, PE3) AND all other local access interfaces in the bridge domain. The VPLS split-horizon rule applies differently: a PE does NOT flood a frame received from a pseudowire back onto other pseudowires (to prevent core loops). But for a frame arriving from an access interface (CE-facing), it IS flooded to all pseudowires and other access interfaces. Since the question specifies PE1 receives the frame (implying from a local access port), PE1 floods to both PE2 and PE3 via their pseudowires and out local access ports.

Question 12

On IOS XR, a pseudowire between PE1 and PE2 shows state 'Down' in 'show l2vpn xconnect detail'. The operator notices the output shows 'MTU: 1500 (local) 1504 (remote)'. What is the most likely cause and resolution?

Accepted Answer

In MPLS pseudowires on IOS XR, MTU is negotiated during LDP pseudowire signaling. If the local and remote MTU values do not match, the pseudowire control plane considers the pseudowire misconfigured and keeps it in the Down state. The resolution is to configure matching MTU values under the pseudowire class ('encapsulation mpls' stanza) on both PE routers. A 4-byte difference (1500 vs 1504) is a common mistake caused by the remote PE accounting for 802.1Q (4 bytes) in its MTU while the local PE uses the payload MTU without tagging overhead. Standardizing the MTU to a common value resolves the negotiation failure. MTU mismatch is an explicit pseudowire status failure condition, not advisory.

Question 13

An IOS XR service provider deploys EVPN-VPWS (point-to-point Ethernet VPN) for a customer. Two PE routers PE1 and PE2 each connect one CE. Both PEs are configured with the same Ethernet Segment Identifier (ESI) for the CE-facing interface. What does a shared ESI across two PEs indicate, and what multihoming behavior does it enable?

Accepted Answer

In EVPN, the Ethernet Segment Identifier (ESI) identifies the physical Ethernet segment connecting a CE to the service provider network. When the same ESI is configured on two different PEs, it signals that the CE is multihomed to both PEs on the same Ethernet segment. EVPN uses ESI-based auto-discovery (Route Type 1 — Ethernet Auto-Discovery route) to advertise the ESI to all PEs. A designated forwarder (DF) election using EVPN procedures determines which PE forwards BUM traffic to the multihomed CE. Depending on the multihoming mode (all-active or single-active), unicast traffic may load-balance across or be forwarded only via the elected primary PE. Duplicate ESIs on unrelated interfaces would be an error, but for multihomed CE scenarios, identical ESI is correct and required.

Question 14

In EVPN-ELAN, PE routers advertise MAC and IP bindings to all other PEs. When a PE learns a MAC address locally from an access port, which EVPN BGP route type is used to advertise this MAC/IP binding to remote PEs?

Accepted Answer

EVPN Route Type 2 (MAC/IP Advertisement route) is the BGP EVPN route type used to advertise learned MAC addresses (with an optional associated IP address for ARP suppression) to all remote PEs in the same EVI (EVPN Instance). The route carries the MAC address, an optional IP address (for integrated routing and bridging), and the MPLS label(s) required for EVPN forwarding to the advertising PE. Route Type 1 is for Ethernet Auto-Discovery (ESI and DF election). Route Type 3 is for inclusive multicast (BUM traffic — it advertises the PE's tunnel endpoint for flooding). Route Type 5 is for IP prefix routes in EVPN IRB scenarios, not for MAC/IP bindings.

Question 15

An IOS XR PE participates in BGP-signaled VPLS. The operator runs 'show l2vpn bridge-domain detail' and sees the bridge domain is Up but several remote PEs appear as 'Peer not reachable'. The local PE's BGP table contains the VPLS NLRIs from those remote PEs. What is the most likely cause?

Accepted Answer

'Peer not reachable' in the VPLS bridge domain context means the PE can see the BGP NLRI (control plane is working) but cannot establish the pseudowire because the MPLS transport path to the remote PE loopback does not exist. VPLS uses LDP to signal pseudowire labels and relies on an underlying transport LSP (LDP or SR) to the remote PE. If LDP sessions are not established to the remote PE or the transport LSP is missing, the VPLS pseudowire cannot forward traffic even though BGP has distributed the VPLS NLRIs. The fix is to verify LDP or SR is running end-to-end and the remote PE loopbacks are reachable via labeled paths. BGP L2VPN VPLS address family being inactive would prevent receipt of the NLRIs entirely.

Question 16

A service provider needs to carry IPv6 customer traffic over an IPv4-only MPLS backbone without running IPv6 in the core. The customer CE routers speak native IPv6. Which Cisco SP solution requires the PE routers to run dual-stack (IPv4 and IPv6) and use BGP to distribute IPv6 prefixes with MPLS labels over the IPv4 backbone?

Accepted Answer

6PE (IPv6 Provider Edge) is the solution where PE routers are dual-stack (IPv4 + IPv6) but the P routers remain IPv4-only. PE routers exchange IPv6 prefix reachability via MP-BGP using the IPv6 unicast address family with 'send-label' (BGP labeled unicast) or with an IPv4-mapped NEXT_HOP. MPLS labels are stacked: the outer label is the transport label to the egress PE and the inner label carries the IPv6 forwarding context. P routers only see MPLS labels and never process IPv6 headers. 6VPE (option A) is for IPv6 L3VPN with per-customer VRFs — it also uses MPLS but adds the VRF isolation layer. 6RD uses stateless tunneling at the customer premise. DS-Lite is for IPv4 over IPv6 access networks.

Question 17

An IOS XR PE router is configured for 6VPE (IPv6 L3VPN). A VRF named CUSTOMER-B has both IPv4 and IPv6 address families configured. Which BGP address family carries 6VPE routes between PE routers in the SP backbone?

Accepted Answer

6VPE uses the BGP VPNv6 unicast address family (AFI 2, SAFI 128) to exchange IPv6 VPN routes between PE routers. A VPNv6 address is 24 bytes: 8-byte Route Distinguisher + 16-byte IPv6 prefix. On IOS XR this is activated with 'address-family vpnv6 unicast' under the BGP neighbor. The RD makes each customer's IPv6 prefixes globally unique across the backbone, and Route Targets control import/export between VRFs — exactly as in IPv4 L3VPN but with IPv6 as the payload. 'ipv6 unicast' carries global (non-VPN) IPv6 routes. 'ipv4 vpn' is not a valid combined AFI/SAFI. L2VPN EVPN Route Type 5 is for EVPN IP prefix routes, not 6VPE.

Question 18

A service provider deploys Stateful NAT64 for IPv6-only broadband customers who need to access legacy IPv4 Internet services. Where in the SP network is the NAT64 translation typically performed?

Accepted Answer

Stateful NAT64 is a service deployed at a centralized gateway in the SP network, typically at the Internet peering/edge boundary. IPv6-only clients send packets to IPv4 destinations using well-known NAT64 prefix (64:ff9b::/96 per RFC 6052). The NAT64 gateway translates IPv6 source addresses to IPv4 addresses from a shared pool and maintains stateful session mappings (IPv6 src, IPv4 dst) ↔ (IPv4 translated src, IPv4 dst). This allows IPv6-only hosts to initiate connections to IPv4 servers without any changes on the IPv4 server side. Performing NAT64 at the CE (option A) would require per-customer CPE upgrades and defeats the SP-managed service model. P routers do not perform NAT. Route Reflectors handle BGP routing, not packet translation.

Question 19

A service provider uses 6RD (IPv6 Rapid Deployment) to offer IPv6 to broadband customers over an IPv4-only access network. How does 6RD derive a customer's IPv6 prefix?

Accepted Answer

6RD (RFC 5969) is a stateless IPv6 transition mechanism where the SP embeds the customer's IPv4 address (WAN address) into the 6RD prefix. The SP allocates a 6RD prefix (e.g., 2001:db8::/32) and the CPE constructs its IPv6 /64 delegated prefix by combining the SP's 6RD prefix with the customer's public IPv4 WAN address. For example, if the 6RD prefix is 2001:db8::/32 and the CPE's IPv4 address is 198.51.100.1, the IPv6 prefix becomes 2001:db8:c633:6401::/64 (with the IPv4 address hex-encoded). This is entirely stateless — no per-customer state is maintained at the SP. DHCPv6-PD (option A) is a separate mechanism. EUI-64 (option C) is for interface ID generation, not 6RD prefix derivation. NAT44 with UDP tunneling is DS-Lite, not 6RD.

Question 20

An IOS XR PE is configured for dual-stack 6VPE. A VRF has both 'address-family ipv4 unicast' and 'address-family ipv6 unicast' configured with import/export route-targets. The operator notices IPv6 VPN routes from remote PEs are received in the BGP table (via 'show bgp vpnv6 unicast') but are not installed in the VRF IPv6 routing table. What is the most likely cause?

Accepted Answer

In IOS XR 6VPE, VRF route import is controlled independently for each address family. The 'address-family ipv6 unicast' stanza inside the VRF configuration must have its own 'import route-target' statement matching the RT used by the remote PEs in their VPNv6 NLRI. If the VRF only has 'import route-target' under 'address-family ipv4 unicast' (and not under 'address-family ipv6 unicast'), the BGP process will receive VPNv6 updates and place them in the BGP VPNv6 table but will not import them into the VRF IPv6 routing table because no IPv6-specific import RT is configured. IOS XR fully supports dual-stack VRFs. VPNv6 routes are installed in the VRF routing table (visible via 'show route vrf NAME ipv6') when correctly configured.

Question 21

An operator suspects an MPLS L3VPN route is missing from a PE router's VRF routing table. Which IOS XR command shows all routes within a specific VRF?

Accepted Answer

On IOS XR, the command to display all routes in a specific VRF routing table is 'show route vrf VRF-NAME'. This shows all protocol routes (BGP, OSPF, static, connected) installed in that VRF's RIB. Note that IOS XR does not use 'show ip route' — the 'ip' keyword is absent in IOS XR; it uses 'show route' for IPv4 and 'show route ipv6' for IPv6. 'show bgp vpnv4 unicast vrf CUSTOMER-A' shows only the BGP VPNv4 entries for that VRF, not all routes. 'show mpls forwarding-table vrf CUSTOMER-A' shows LFIB entries for the VRF, which is the MPLS forwarding plane — useful for troubleshooting but not for seeing IP routes.

Question 22

An operator needs to test end-to-end reachability from a PE router to a CE-connected prefix 192.168.10.0/24 within VRF CUSTOMER-A, using the VRF routing context for the ping. Which IOS XR command achieves this?

Accepted Answer

On IOS XR, the command to send an ICMP ping within a specific VRF context is 'ping vrf VRF-NAME DESTINATION'. This instructs the router to use VRF CUSTOMER-A's routing table to resolve 192.168.10.1 and send the ICMP packet with the appropriate VPN labels. Option A has the 'vrf' keyword at the end, which is not the standard IOS XR ping syntax — IOS XR places 'vrf NAME' before the destination address. Option C adds 'mpls' which is for MPLS LSP ping, not VRF IP ping. Option D's 'label vrf' is not valid IOS XR syntax.

Question 23

During L3VPN troubleshooting on IOS XR, the operator runs 'show bgp vpnv4 unicast all' and finds the expected VPNv4 prefix 10.1.1.0/24 with RD 65000:1. However, this prefix does not appear in 'show route vrf CUSTOMER-A'. What is the most likely cause?

Accepted Answer

The presence of a VPNv4 prefix in 'show bgp vpnv4 unicast all' confirms the prefix has been received and accepted by BGP. The prefix is imported into a VRF's routing table only when its Route Target (RT) extended community matches an 'import route-target' configured in the VRF's address family. If the VRF's import RT does not match the RT advertised in the VPNv4 NLRI, the route remains in the BGP VPNv4 table but is never installed in the VRF RIB. This is the most common cause of 'route present in BGP but missing from VRF'. The RD (option C) uniquely identifies the origin but is not used for import decisions — that is exclusively the RT's role. 'no bgp import' is not a standard IOS XR command. BGP convergence delay (option D) is implausible when the route is already in the BGP table.

Question 24

An operator troubleshoots a VPLS bridge domain on IOS XR where MAC addresses from remote PEs are not being learned. The bridge domain is Up and pseudowires show as 'Up' in 'show l2vpn xconnect detail'. 'show l2vpn bridge-domain detail' shows the bridge domain is forwarding but the MAC table has no remote entries. What is the most likely cause?

Accepted Answer

In VPLS, MAC address learning on a PE occurs when frames are received carrying source MAC addresses — including frames flooded by remote PEs for unknown unicast or broadcast traffic. If BUM replication is broken (e.g., the VPLS flood list on remote PEs is misconfigured or the remote PE is not sending BUM traffic correctly), the local PE never receives frames from remote PEs and therefore never learns their source MACs. Pseudowires being 'Up' confirms the control plane and MPLS transport are working, but if no data plane frames are arriving, the MAC table stays empty. ARP suppression (option A) is an EVPN feature that suppresses ARP broadcasts but does not prevent MAC learning from data frames. MAC aging at 0 (option C) would clear entries but would still briefly show learned MACs. Split-horizon (option D) prevents inter-pseudowire forwarding, not MAC learning from pseudowires themselves.

Question 25

An operator runs 'show l2vpn xconnect group XC-GROUP p2p CIRCUIT-1 detail' on an IOS XR PE and sees the pseudowire state as 'Incomplete'. Choose 2 conditions that can cause a pseudowire to remain in the Incomplete state.

Accepted Answer

An LDP-signaled pseudowire enters 'Incomplete' state (rather than 'Up' or 'Down') when the control plane negotiation has partially succeeded but parameter mismatch prevents full establishment. Two common causes: (B) Control-word mismatch — if one PE has 'control-word' enabled and the other does not, the LDP pseudowire parameter TLV negotiation fails during Label Mapping exchange because the control-word capability bit does not match, leaving the pseudowire Incomplete. (D) Attachment circuit (AC) down — if the local interface (AC) bound to the p2p xconnect is in a Link-Down state or absent, the pseudowire has no local forwarding endpoint and cannot transition to Up, showing as Incomplete. PW-ID mismatch (option A) would typically result in no LDP Label Mapping being sent/accepted at all (the pseudowire would not be established), not an Incomplete state. BGP RR configuration (option C) affects EVPN not LDP-signaled pseudowires. IP routing being disabled globally (option E) would break LDP session establishment entirely.

300-515 SPVI — Cisco Service Provider VPN Services Implementation Specialist