300-515 Implementing Cisco Service Provider VPN Services Exam Topics and Questions

VPN Architecture sets the conceptual baseline for everything else on this exam. Get this wrong and the later topics become guesswork. The domain splits across three planes: the underlay that carries traffic, the control plane that builds VPN reachability, and the data plane that actually forwards labelled packets. Items here reward candidates who can move between those planes fluently and know why a design choice at one layer forces a constraint at another.

– Architectural comparisons and underlay health

The exam opens with a comparison of Layer 2 and Layer 3 VPN models. The distinction that matters for items is not a textbook definition but the boundary of customer control: in L2 VPNs the provider forwards frames, in L3 VPNs the provider participates in routing. Knowing which model owns the routing decision changes how you reason about a fault.

Inter-AS versus Intra-AS scope is a second axis. Intra-AS keeps everything inside one provider domain; Inter-AS introduces stitching across autonomous system boundaries, which affects label stacks and BGP session design.

Underlay troubleshooting covers the IGP (typically IS-IS or OSPF in a Cisco SP environment) and the Label Switched Path built on top of it. When an LSP is broken, the overlay VPN fails silently from the customer's view. Items on this sub-topic reward candidates who can isolate whether a problem sits in the IGP adjacency, the LDP or RSVP signalling, or the forwarding table itself. Confusing those three layers is where marks are lost.

– Layer 2 service architecture on IOS XR and IOS XE

IOS XR and IOS XE model Layer 2 attachment differently. On IOS XR, Ethernet Flowpoints define the point at which frames enter or leave an MPLS pseudowire or bridge domain. On IOS XE, Ethernet Virtual Circuits serve the same conceptual role but use a different configuration hierarchy. The exam tests whether you can recognise the platform-specific terminology and map it to the underlying service behaviour. A candidate who treats them as interchangeable will misread scenario output in a troubleshooting item.

– L3VPN control plane: BGP constructs and VRF design

This is the densest part of the topic. MP-BGP carries VPNv4 (and VPNv6) prefixes between PE routers. A VPNv4 address is a 96-bit construct: a 64-bit route distinguisher prepended to a 32-bit IPv4 prefix. The distinguisher makes globally unique prefixes out of potentially overlapping customer address space. Route targets are BGP extended communities that control import and export between VRFs, and they are the mechanism that determines which customer sees which routes.

The VPN label is assigned by the advertising PE and tells the receiving PE which VRF forwarding instance to use after the underlay label is popped. PE-CE route advertisement covers how customer routes enter the VRF: static, OSPF, EIGRP, BGP, or a combination. Additional Paths (BGP ADD-PATH) allows a route reflector to advertise more than one path for the same prefix, which feeds directly into PIC (Prefix Independent Convergence) by pre-programming backup next-hops. Unified BGP/MPLS ties these constructs into a single forwarding model. Understanding how each construct interacts is the exam's real demand here.

– L3VPN data plane: label stacks and VRF forwarding

Once the control plane has distributed routes and labels, the data plane must forward traffic correctly. A packet entering a PE router from a CE gets two labels pushed: the underlay (transport) label that steers it across the provider core, and the VPN label that identifies the egress VRF. The underlay label is swapped at each P router and popped (often penultimate-hop) before the egress PE, leaving only the VPN label for final disposition.

VRF forwarding instances partition the PE's routing and forwarding tables so that customer address spaces remain isolated. VPNv6 extends this model to IPv6 customer prefixes carried across an IPv4 MPLS core, using the same dual-label mechanism. Items on data-plane operation often present a label stack or a show-command output and ask you to trace a packet's path or identify where forwarding breaks. The trap is confusing which label belongs to which layer.

How VPN Architecture is tested

At 25% of the exam, this topic generates a significant share of items, and they span all three difficulty levels. Straightforward items ask you to identify what a route distinguisher or route target does in a given scenario. Harder items present a partial configuration or a show-command snippet and ask you to pinpoint a control-plane or data-plane fault.

The most common trap is conflating route distinguishers with route targets. Candidates who have memorised the definitions but not the operational difference will pick the wrong option when an item describes a VRF that is leaking routes or failing to import them. A second trap involves the label stack: items reward candidates who can count labels correctly and know at which hop penultimate-hop popping removes the transport label.

Troubleshooting items on the underlay (IGP and LSP) reward a methodical split between the IGP adjacency layer and the label distribution layer. Jumping straight to MPLS when the IGP has not converged is the move that loses marks. PIC and Additional Paths items test whether you understand the pre-convergence relationship, not just the feature names.

Layer 2 VPNs carries the heaviest weight on the exam. Where VPN Architecture asked you to understand constructs in isolation, this topic asks you to operate them: troubleshoot live service faults, reason about EVPN's control and data planes together, and implement specific EVPN variants. The shift from "describe" to "troubleshoot" and "implement" means items are scenario-driven and the detail in the output matters.

– E-LAN, E-Line, and E-Tree service troubleshooting

The three Carrier Ethernet service types map to different forwarding models and therefore to different failure signatures. E-Line is a point-to-point service: one pseudowire, two endpoints, and a straightforward path to trace. E-LAN is a multipoint-to-multipoint service where MAC learning and flooding behaviour are central to both operation and fault isolation. E-Tree introduces a root-and-leaf hierarchy that restricts which endpoints can communicate, and items on E-Tree often hinge on whether a leaf-to-leaf forwarding block is correctly enforced.

Troubleshooting items in this sub-topic reward candidates who can read service-level output (pseudowire state, bridge domain membership, MAC table entries) and correlate it with a described symptom. The trap is treating all three service types as variations of the same problem space. Each has a distinct set of control-plane states to verify, and a troubleshooting approach that works for E-Line will miss the MAC-learning dimension that is central to E-LAN faults.

– EVPN concepts: control plane, multihoming, and suppression

EVPN replaces flood-and-learn with a BGP control plane. MAC and IP reachability is distributed as BGP route types, and the exam expects you to know which route type carries which information and what happens when one is missing or misconfigured.

Multihoming is one of EVPN's defining capabilities. A CE can attach to multiple PEs (an Ethernet Segment), and EVPN uses the Ethernet Segment Identifier and associated route types to elect a designated forwarder and prevent loops. Items on multihoming reward candidates who understand the election mechanism, not just the existence of the feature.

Suppression mechanisms (ARP suppression, ND suppression) allow the EVPN control plane to answer ARP and Neighbour Discovery requests locally rather than flooding them across the fabric. Items here test whether you understand the conditions under which suppression works and the failure mode when it does not. Traffic engineering integration with RSVP-TE or SR-TE affects how EVPN-signalled paths are placed across the underlay, and IS-IS or OSPF carries the TE topology that makes that placement possible.

– Ethernet OAM

Ethernet Operations, Administration, and Maintenance covers the toolset used to verify and maintain Layer 2 connectivity end-to-end. Continuity Check Messages, Loopback, and Linktrace are the core mechanisms, and each operates at a specific Maintenance Level. Items on E-OAM reward candidates who know which tool answers which operational question: verifying a path is up, locating a fault, or measuring delay. The trap is treating OAM as a monitoring afterthought. In a service provider context it is a contractual tool, and items often frame it in terms of what a specific OAM action will or will not detect given a described topology.

– EVPN implementation: IRB, VPWS, and native EVPN

Three EVPN implementation variants appear on the exam and each has a distinct forwarding model. EVPN IRB (Integrated Routing and Bridging) allows a single PE to both bridge within a subnet and route between subnets using EVPN-distributed MAC/IP bindings. The asymmetric and symmetric IRB models differ in where routing and bridging happen on the path, and items distinguish between them by asking about ARP suppression behaviour or the label stack at a given hop.

EVPN VPWS provides a point-to-point pseudowire service signalled through BGP rather than LDP, giving operators the control-plane consistency of EVPN without the multipoint complexity. EVPN native (sometimes called EVPN-MPLS without pseudowire emulation) uses EVPN route types natively for multipoint bridging. Implementation items test configuration logic and expected state output, not conceptual descriptions. Knowing that a feature exists is not enough: you need to know what a correctly implemented instance looks like in the control and forwarding plane.

How Layer 2 VPNs is tested

At 30% this is the single largest topic, and the item mix reflects that breadth. Troubleshooting items dominate: you are given a service description, a symptom, and partial output, and you must identify the fault. Items reward candidates who work from the symptom to the relevant protocol layer rather than checking every possible cause.

EVPN items are scenario-heavy. The exam does not ask you to recite route types; it places you in a topology and asks what happens when a specific BGP advertisement is missing or a multihoming election produces an unexpected result. Candidates lose marks by knowing EVPN concepts at a surface level and failing to apply them to a forwarding outcome.

E-OAM items often combine with service troubleshooting: you must choose the right OAM tool for the described fault, not just confirm that OAM is configured. EVPN implementation items reward candidates who can distinguish between IRB models or between VPWS and native EVPN in terms of the label stack or BGP state, not just the feature name. Mixing up the forwarding behaviour of these variants is the most reliable way to lose marks in this topic.

Layer 3 VPNs is the heaviest topic on this exam. The scope runs from basic PE-CE routing through multicast VPN, extranet design, Inter-AS options, and Carrier Supporting Carrier. Items expect operational depth: you are not describing the architecture (that was Topic 1) but configuring, troubleshooting, and extending it. Every sub-topic here has a corresponding failure mode that the exam will put in front of you.

– Routing requirements and PE-CE protocol selection

MP-BGP carries VPNv4 prefixes between PEs; the PE-CE link uses a separate routing protocol (or static routes) to exchange customer prefixes into and out of the VRF. The exam tests whether you understand the interaction between these two routing processes. A route that is redistributed from OSPF into BGP on the ingress PE and then redistributed back into OSPF on the egress PE carries BGP attributes that affect how the remote CE sees it, including the OSPF domain tag used to prevent re-import loops.

Items on routing requirements reward candidates who can identify which protocol is appropriate for a given PE-CE relationship and what redistribution or route-policy logic is needed to make it work correctly. The trap is treating PE-CE protocol selection as a preference question rather than a correctness question: in some scenarios, only one protocol choice produces the required behaviour.

– Intra-AS L3VPN troubleshooting: PE-CE, PE-PE, and PE-RR

Troubleshooting Intra-AS L3VPNs requires you to isolate faults across three session types. PE-CE faults are closest to the customer: adjacency failures, missing redistributions, or VRF table mismatches. PE-PE faults sit in the MPLS core: label distribution problems, VPNv4 prefix not being advertised, or next-hop reachability missing. PE-RR (route reflector) faults introduce a third failure point: the RR may have the prefix but the cluster-id or originator-id logic may prevent it from being reflected correctly.

Items in this sub-topic reward a structured diagnostic approach. Candidates who jump to the most complex explanation (a route reflector policy bug) when a simpler cause (the PE-CE session is down) is present will consistently pick the wrong option. Reading show-command output to determine which session is the actual fault boundary is the core skill being assessed.

– Multicast VPN: intranet, extranet, and MLDP

Multicast VPN extends L3VPN to carry customer multicast traffic across the provider core. The exam covers three related areas. Intranet MVPN delivers multicast within a single VPN, using either a default MDT or data MDTs for high-bandwidth streams. Extranet MVPN allows a multicast source in one VPN to reach receivers in a different VPN, which requires explicit route-target import policy to control which VRFs receive the multicast routing information.

MLDP (Multipoint LDP) replaces RSVP-based P2MP trees with an LDP-signalled multipoint LSP, removing the need for PIM in the provider core. Items on MLDP reward candidates who understand how the customer multicast tree maps onto the MLDP tree in the core and where that mapping can fail. Extranet MVPN items are often the most complex in this sub-topic because they combine route-target logic (a control-plane concept) with multicast forwarding state (a data-plane concept).

– Extranet and shared services, Inter-AS options, and CSC

Extranet and shared services use route-target import and export policy to allow selective prefix leaking between VRFs. The exam tests the mechanics: which RT must be imported into which VRF, and what route policy is needed to prevent unwanted prefix propagation. Getting the RT direction wrong (importing where you should export, or vice versa) is the primary trap.

Inter-AS L3VPN introduces options for connecting customer VPNs across AS boundaries. Option A runs VRF-to-VRF across the ASBR boundary: simple but scale-limited. Option B exchanges VPNv4 routes between ASBRs using MP-EBGP, with label re-imposition at the boundary. Option C uses a multihop MP-EBGP session between PEs in different ASes, with the ASBR exchanging only labelled IPv4 routes. Option AB combines aspects of A and B. Items distinguish between these options by their label handling and session topology, not by their names.

Carrier Supporting Carrier (CSC) allows one SP to use another SP's MPLS backbone. The inner carrier runs its own MPLS; the outer carrier provides the transport. Items on CSC test the label stack interaction and the BGP session structure between the two carriers' PE and CE routers.

How Layer 3 VPNs is tested

At 35% this topic alone can determine whether you pass. The item count is large and the difficulty is uneven: some items test straightforward VRF configuration logic, while others place you inside a multi-AS topology and ask you to identify a specific label-forwarding fault.

Multicast VPN items reward candidates who can trace the relationship between customer PIM state and provider MDT state. Candidates who know the feature at a conceptual level but cannot map a specific failure symptom to the correct layer will lose marks consistently.

Inter-AS option items are frequently answered incorrectly because candidates confuse the session topology with the label handling. Items reward candidates who know precisely where labels are re-imposed or stitched for each option, not just which option uses MP-EBGP. Extranet route-target items reward directional precision: the import/export relationship must be correct in both VRFs for the service to work, and items exploit the common mistake of configuring only one side. CSC items are less frequent but reward candidates who can explain the label stack without conflating the inner and outer carrier's labels.

After the depth of Layer 3 VPNs, IPv6 VPNs is a focused topic with a narrow scope. At 10% it contributes a small but non-trivial share of items, and the concepts overlap significantly with what you have already covered in L3VPN. The distinguishing demand is knowing where IPv6 transport changes the routing and forwarding logic, and being able to troubleshoot the specific session pairs that break in a dual-stack or IPv6-only provider edge environment.

How IPv6 VPNs is tested

Items in this topic split between routing requirements and troubleshooting, mirroring the sub-topic structure. Routing requirement items reward candidates who can distinguish 6VPE from 6PE: 6VPE carries IPv6 customer prefixes inside VRFs using VPNv6 address families, while 6PE carries IPv6 prefixes in the global table using labelled IPv6. Conflating the two is the most common source of lost marks here.

The PE-CE routing protocol sub-topic tests the same redistribution and route-policy logic as the L3VPN equivalent, but applied to IPv6 address families. Candidates who configured only the IPv4 VRF address family in their lab experience may miss the IPv6-specific configuration steps that items probe.

Troubleshooting items focus on PE-PE and PE-CE session state. A PE-PE item might present a scenario where VPNv6 prefixes are not being exchanged and ask you to identify whether the fault is in the BGP address-family activation, the next-hop handling, or the label allocation. PE-CE troubleshooting items reward the same structured approach as their IPv4 equivalents: verify the session, then the prefix, then the forwarding state. The item count is modest but the material is precise, and a candidate who skips this topic entirely will feel it in the final score.