Free Cisco 350-501 Practice Questions 2026 | Implementing and Operating Cisco Service Provider Network Core Technologies (350-501 SPCOR)

Explanation

The exhibit shows that Router 1 has a static route for 192.168.1.0/24 pointing to null 0 with tag 1, and a route-map named "ddos" that matches tag 1, sets the next-hop to 192.0.2.1, sets local-preference to 150, and sets the community to no-export. Under BGP, the static route is redistributed using `redistribute static route-map ddos`. The static route to 192.168.1.0/24 points to null 0, which means traffic destined for that prefix is dropped at Router 1. This is a common DDoS mitigation technique, often called Remotely Triggered Black Hole (RTBH) filtering, where traffic to the attacked prefix is blackholed by routing it to null 0. Therefore, all traffic to 192.168.1.0/24 is dropped. This makes option C the correct answer.

Why the other options are incorrect:

A. Router 1 drops all traffic with a local-preference set to 150 – The local-preference of 150 is a BGP attribute set by the route-map and is used for BGP path selection. It does not cause the router to drop traffic matching that local-preference. Traffic is dropped because the route points to null 0, not because of the local-preference value.

B. All traffic is dropped – Only traffic destined for the specific prefix 192.168.1.0/24 is blackholed. The route to 192.0.2.0/24 is also a null 0 route on both routers, but the question focuses on the 192.168.1.0/24 prefix that is tagged and redistributed. Traffic to other destinations is not dropped.

D. Router 1 and Router 2 advertise the route to 192.0.2.0/24 to all BGP peers – The 192.0.2.0/24 static route is not tagged and is not matched by the route-map "ddos" (which matches tag 1). Therefore, it is not redistributed into BGP by the `redistribute static route-map ddos` command, so it is not advertised to BGP peers.

Reference:
RFC 3882 – Configuring BGP to Block Denial-of-Service Attacks; RFC 7999 – BLACKHOLE Community; Cisco IOS XR Routing Configuration Guide – Implementing BGP: Remotely Triggered Black Hole Filtering; Cisco 350-501 SPCOR Official Cert Guide, BGP and Security sections.

Explanation

Traffic shaping delays excess packets rather than dropping them, so the implementation requires a buffer queue with sufficient memory to hold the delayed packets and a scheduling function to send those buffered packets out at the configured rate once tokens become available. The queue provides the storage for excess traffic, and the scheduler handles the delayed transmission so that the shaped rate is not exceeded while still preserving the packets. This makes options A and D the correct answers.

Why the other options are incorrect:

B. Configure the token values in bytes – Token values in traffic shaping are configured in bits per second, not in bytes. The token bucket parameters (CIR, Bc, Be) are rate and burst values, so specifying bytes is incorrect.

C. Implement packet remarking for excess traffic – Packet remarking (for example, setting DSCP or precedence) is a marking/policing action, not a fundamental requirement for shaping. Shaping delays rather than remarks excess packets.

E. Configure a threshold over which excess packets are discarded – Discarding excess packets above a threshold describes policing, not shaping. Shaping buffers excess packets in a queue instead of dropping them.

Reference:
Cisco IOS XR Modular QoS Configuration Guide – Configuring Traffic Shaping and Queuing; RFC 2475 – An Architecture for Differentiated Services; Cisco 350-501 SPCOR Official Cert Guide, QoS section.

Explanation

To inject a default route into the MP-BGP address family for the Internet_Shared_Services VRF, the configuration must include the `address-family ipv4 vrf Internet_Shared_Services` block with `network 0.0.0.0` and the correct neighbor activation under the VPNv4 address family. Option D shows the VPNv4 neighbor activated with `send-community both`, and the VRF address family configured as `address-family ipv4 vrf Internet_Shared_Services` with `no synchronization` and `network 0.0.0.0`. This combination injects the default route into the specified VRF and allows the community attributes to be carried across MP-BGP. This makes option D the correct answer.

Why the other options are incorrect:

A. Option A – The VRF address family is configured as `address-family ipv4 vrf Internet_Shared_Services`, but the `network 0.0.0.0` command is missing, and `send-community extended` is used instead of `send-community both`. Without the network statement, the default route is not injected.

B. Option B – The VRF address family is configured as `address-family ipv4 vrf Internet`, which is the wrong VRF name. The requirement specifies the Internet_Shared_Services VRF, so this option targets the wrong VRF and injects the default route into the wrong table.

C. Option C – The VRF address family is configured as `address-family ipv4 vrf Internet`, again the wrong VRF name, and it is missing the `network 0.0.0.0` statement, so the default route is not injected into the required VRF.

Reference:
Cisco IOS XR Routing Configuration Guide – Implementing BGP: Configuring VRF Address Families and Default Route Injection; RFC 4364 – BGP/MPLS IP VPNs; Cisco 350-501 SPCOR Official Cert Guide, MPLS L3VPN chapter.

Explanation

When implementing a prefix list, a Cisco best practice is to use non-sequential sequence numbers for the entries so that additional entries can be inserted later without having to renumber the entire list. If sequential numbers (10, 20, 30, etc.) are used, inserting a new entry between existing ones requires renumbering, which can be disruptive. Using non-sequential numbers (for example, 10, 20, 30 with gaps like 10, 20, 25, 30) allows the engineer to insert new entries in the gaps. This makes option A the correct answer.

Why the other options are incorrect:

B. The final entry in a prefix list must be /32 – There is no requirement that the final entry in a prefix list be a /32. The final entry is typically an implicit deny any, but it is not configured as a /32. Prefix lists can contain any valid prefix lengths.

C. An engineer must identify the prefix list with a number only – Prefix lists can be identified by either a name or a number. Named prefix lists are commonly used and are actually preferred for readability. Requiring a number only is not a best practice.

D. An engineer must include only the prefixes for which he needs to log activity – Prefix lists are used for filtering and matching, not just for logging. Logging is an optional feature that can be applied to specific entries, but limiting the prefix list to only logged prefixes would defeat its filtering purpose.

Reference:
Cisco IOS XR Routing Configuration Guide – Implementing Routing Policy: Prefix Lists; RFC 4271 – A Border Gateway Protocol 4 (BGP-4); Cisco 350-501 SPCOR Official Cert Guide, Routing Policy section.

Explanation

Cisco MPLS TE tunnels require a link-state routing protocol because the headend router must have a complete view of the network topology, including all links, their available bandwidth, and their TE metrics, in order to compute an explicit path that satisfies the tunnel's constraints. Link-state protocols such as OSPF and IS-IS with TE extensions flood this information into the link-state database (TED), allowing the headend to run a Constrained Shortest Path First (CSPF) calculation over the entire topology and select the best path for the tunnel. This makes option C the correct answer.

Why the other options are incorrect:

A. Link-state routing protocols use SPF calculations that the tunnel endpoints leverage to implement the tunnel – While SPF is part of link-state operation, the tunnel does not simply leverage the SPF calculation. It uses the link-state database to run CSPF, which is a constrained path computation, not the standard SPF. The tunnel endpoints do not implement the tunnel via the IGP SPF itself.

B. The link-state database provides a data repository from which the tunnel endpoints can dynamically select a source ID – The link-state database is used for topology and resource information, not for selecting a source ID. The tunnel source is a configured attribute (typically the router ID or a loopback), not something derived from the database.

D. The link state database provides segmentation by area, which improves the path-selection process – Area segmentation is a feature of link-state protocols, but it does not improve path selection for TE tunnels. In fact, TE tunnels often need to cross area boundaries, and the TED must be synchronized across areas for TE to work properly.

Reference:
RFC 3209 – RSVP-TE: Extensions to RSVP for LSP Tunnels; RFC 3630 – Traffic Engineering (TE) Extensions to OSPF Version 2; RFC 5305 – IS-IS Extensions for Traffic Engineering; Cisco IOS XR MPLS Configuration Guide – Implementing MPLS Traffic Engineering; Cisco 350-501 SPCOR Official Cert Guide, MPLS Traffic Engineering chapter.

Explanation

The exhibit shows `mpls ldp graceful-restart` configured on R1. This command enables LDP Graceful Restart (GR) with Non-Stop Forwarding (NSF) on R1, allowing R1 to help a neighboring LDP router recover from a control-plane outage without disrupting the MPLS forwarding plane. When the peer restarts, R1 preserves the MPLS label bindings and continues forwarding traffic using the existing labels while the peer re-establishes its LDP session and re-synchronizes its label database. This means R1 supports a peer that is configured for LDP SSO/NSF as the peer recovers from an outage, which makes option B the correct answer.

Why the other options are incorrect:

A. R1 supports a graceful restart operation on the peer, even if graceful restart is disabled on the peer – Graceful Restart is a negotiated capability. Both routers must have LDP GR enabled for the GR procedures to take effect. R1 cannot unilaterally provide GR support if the peer has it disabled.

C. R1 failovers only to a peer that is configured for LDP SSO/NSF – LDP Graceful Restart is not a failover mechanism to a specific type of peer. It is a recovery mechanism that preserves forwarding state during a peer restart. The phrasing about "failovers only" is incorrect.

D. R1 failovers to any peer – LDP GR does not cause R1 to fail over to any peer. It simply allows the LDP session and label bindings to survive a peer restart. There is no concept of failing over to an arbitrary peer in this context.

Reference:
RFC 3478 – Graceful Restart Mechanism for Label Distribution Protocol (LDP); Cisco IOS XR MPLS Configuration Guide – Implementing LDP: Graceful Restart and NSF; Cisco 350-501 SPCOR Official Cert Guide, MPLS chapter.

Explanation

To enable the BGP FlowSpec client function and install policies on all local interfaces, the correct configuration is `flowspec` followed by `address-family ipv4` and `local-install interface-all`. The `local-install interface-all` keyword tells the router to install the received FlowSpec policies on all local interfaces, which is exactly what the requirement specifies. This makes option C the correct answer.

Why the other options are incorrect:

A. Option A – The keyword `all-interface` is not valid syntax in this context. The correct keyword is `interface-all`, so this configuration would be rejected.

B. Option B – The keyword `install interface-all` is missing the `local-` prefix. The correct command is `local-install interface-all`, which enables local installation of FlowSpec policies on all interfaces. Without `local-install`, the behavior is not the same.

D. Option D – The keyword `install interface-all local` places `local` at the end, which is incorrect syntax. The correct order is `local-install interface-all`.

Reference:
Cisco IOS XR Routing Configuration Guide – Implementing BGP: BGP FlowSpec; RFC 5575 – Dissemination of Flow Specification Rules; Cisco 350-501 SPCOR Official Cert Guide, BGP and Security sections.

Explanation

To influence inbound traffic from ASN 64501 so that it prefers the primary link via North_A instead of the backup link via North_B, the administrator of ASN 64502 should advertise more specific subnets of 10.0.0.0/8 through North_A while continuing to advertise the aggregate 10.0.0.0/8 through North_B. BGP always prefers the longest match (more specific prefix) regardless of other attributes such as local preference, MED, or weight. By advertising specific subnets through North_A, ASN 64501 will forward traffic for those subnets via North_A, while the less specific /8 remains available via North_B as a backup. This makes option B the correct answer.

Why the other options are incorrect:

A. Set a higher local preference between North_A and South_A – Local preference is used within an autonomous system to influence outbound path selection. It is not advertised to external peers, so it cannot influence how ASN 64501 selects its inbound path.

C. Set a Lower Weight value for incoming traffic on North_A – Weight is a Cisco-proprietary attribute that is locally significant and only affects outbound path selection on the local router. It is not advertised to external peers and cannot influence inbound traffic from ASN 64501.

D. Set a lower MED between North_B and South_B – MED is used to influence inbound traffic from an external AS, but a lower MED would make North_B more preferred, not less. Additionally, MED is evaluated only after other attributes and is less preferred than a more specific prefix match.

Reference:
RFC 4271 – A Border Gateway Protocol 4 (BGP-4); Cisco IOS XR Routing Configuration Guide – Implementing BGP: Influencing Inbound Path Selection; Cisco 350-501 SPCOR Official Cert Guide, BGP chapter.

Explanation

In an MPLS Layer 3 VPN, shared services such as Internet access are provided by placing the shared services routes (including the Internet routes) into a dedicated shared services VRF on the PE routers. The customer VRF imports routes from the shared services VRF using route targets, which allows the customer sites to reach the Internet through the shared services VRF. Conversely, the shared services VRF can export routes so that customer routes are available to the shared services VRF if needed. This import/export of routes via route targets between the customer VRF and the shared services VRF is the standard mechanism for providing shared services such as Internet access. This makes option C the correct answer.

Why the other options are incorrect:

A. The CE router can establish a BGP peering to a PE router and use the PE device to reach the Internet – While CE routers can peer with PE routers, this does not by itself provide shared Internet access through a shared services VRF. The question specifically asks about shared services in an MPLS L3VPN, which relies on route target import/export, not simply CE-PE peering.

B. Route distinguishers are used to identify the routes that CEs can use to reach the Internet – Route distinguishers (RDs) are used to make VPNv4 prefixes unique across the MPLS domain; they do not identify which routes CEs can use to reach the Internet. Route targets, not RDs, control import and export of routes between VRFs.

D. Static routes on CE routers allow route leakage from a PE global routing table – Route leakage from the global routing table into a VRF is not done through static routes on CE routers. Shared services are implemented through VRF route target import/export, not through static route leakage.

Reference:
RFC 4364 – BGP/MPLS IP Virtual Private Networks (VPNs); Cisco IOS XR MPLS Configuration Guide – Implementing MPLS L3VPN: Shared Services and Route Targets; Cisco 350-501 SPCOR Official Cert Guide, MPLS L3VPN chapter.

Explanation

The exhibit shows `router ospf 1` with `nsf ietf restart interval 90` configured. NSF (Non-Stop Forwarding) with the IETF restart interval is used to maintain OSPF neighbor relationships and continue forwarding traffic during a Route Processor (RP) switchover or a software restart. The `restart interval 90` specifies the maximum time (90 seconds) that the router will wait for the restart to complete while neighbors keep the adjacency up. This allows the neighbor relationships to remain up during the switchover, which is the purpose described in option D. This makes option D the correct answer.

Why the other options are incorrect:

A. The router uses NSF to load balance traffic between two links, with the primary link alternating every 90 seconds – NSF is not a load-balancing mechanism. The restart interval of 90 seconds has nothing to do with alternating traffic between links.

B. The router uses NSF to reduce neighbor-relationship downtime during RP switchover – While NSF does reduce downtime, the more precise and complete description is that it allows neighbor relationships to remain up entirely during the switchover, not just reduces downtime. Option D is the more accurate answer.

C. The router uses NSF to load balance traffic on a routed EtherChannel – NSF is not used for load balancing on EtherChannels. It is a high-availability feature for control-plane restart while preserving the forwarding plane.

Reference:
RFC 4811 – OSPF Out-of-Band LSDB Resynchronization (NSF); RFC 3623 – Graceful OSPF Restart; Cisco IOS XR Routing Configuration Guide – Implementing OSPF: Non-Stop Forwarding; Cisco 350-501 SPCOR Official Cert Guide, OSPF and Network Assurance sections.