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

Explanation

Cisco MPLS TE tunnels require a link-state routing protocol that supports TE extensions, because the headend router needs a complete view of the network topology, including available bandwidth and TE metrics, to compute a constrained path using CSPF. IS-IS and OSPF are the two link-state protocols that support MPLS TE extensions (RFC 5305 for IS-IS and RFC 3630 for OSPF). These extensions allow the flooding of TE link information into the TED (Traffic Engineering Database), which is essential for TE tunnel path computation. This makes options A and D the correct answers.

Why the other options are incorrect:

B. RIP – RIP is a distance-vector protocol and does not support MPLS TE extensions. It does not provide the topology and resource information needed for CSPF path computation.

C. BGP – BGP is a path-vector protocol used for exchanging routing information between autonomous systems. It does not flood TE link-state information and does not support MPLS TE path computation.

E. EIGRP – EIGRP is an advanced distance-vector protocol. While it supports some traffic engineering capabilities, it does not support the standard MPLS TE extensions (RFC 3630/5305) required for CSPF-based TE tunnel computation in Cisco MPLS TE deployments.

Reference:
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 a telemetry model-driven configuration with `destination-group ciscotest` and an address family entry specifying the receiver 192.168.1.1 on port 1025 with `encoding self-describing-gpb`. To complete the gRPC dial-out configuration, the engineer must specify the protocol used for the telemetry stream. For gRPC dial-out telemetry, the correct protocol keyword is `grpc`, which tells the router to use the gRPC protocol to push the telemetry data to the destination. This makes option A the correct answer.

Why the other options are incorrect:

B. protocol all – `protocol all` is not a valid option for gRPC dial-out telemetry configuration. It does not specify the gRPC transport.

C. protocol tcp – While gRPC uses TCP as its underlying transport, the telemetry configuration requires the `grpc` keyword, not `tcp`. Specifying TCP alone would not enable the gRPC dial-out behavior.

D. protocol any – `protocol any` is not a valid keyword for this configuration and would not enable gRPC dial-out.

Reference:
Cisco IOS XR Telemetry Configuration Guide – Configuring gRPC Dial-Out Telemetry; Cisco 350-501 SPCOR Official Cert Guide, Automation and Assurance section.

Explanation

BGPsec (BGP Security) is a framework that extends BGP to provide cryptographic protection of the AS_PATH attribute, ensuring that the path information in BGP updates cannot be tampered with. It uses digital signatures to secure the AS path, allowing routers to validate that the path is authentic. Additionally, BGPsec uses router key pairs consisting of a public and private key, where the rivate key is used to sign route updates (specifically the AS_PATH and other path attributes). These signatures are then verified by receiving routers using the sender's public key. This makes options B and D the correct answers.

Why the other options are incorrect:

A. BGPsec uses IPsec tunnel for security – BGPsec does not rely on IPsec tunnels. It uses cryptographic signatures (digital signatures) applied directly to BGP updates to protect the AS_PATH and associated path attributes.

C. In BGPsec, all route advertisements are given an expiry time by the originator of the route – BGPsec does not define an expiry time for route advertisements. It uses signatures and key lifetimes, but the concept of a per-route expiry time is not part of the BGPsec framework.

E. In BGPsec, route advertisements are not given an expiration time by the originator of the route – While this statement is technically true (BGPsec does not assign an expiration time to route advertisements), it is not one of the two defining conditions that an engineer must take into account when configuring BGPsec. Options B and D are the core operational and security characteristics.

Reference:
RFC 8205 – BGPsec Protocol Specification; RFC 8206 – BGPsec Considerations for Autonomous System (AS) Migration; Cisco 350-501 SPCOR Official Cert Guide, BGP and Security sections.

Explanation

The exhibit shows a Cisco IOS XR BGP configuration with `address-family ipv4 unicast` and `address-family vpnv4 unicast` enabled globally, and a neighbor 10.19.20.20 with `remote-as 1` and `address-family ipv4 unicast` under the neighbor. In Cisco IOS XR, when an eBGP neighbor is configured without an explicit inbound or outbound route policy, the default behavior is to drop all routes in both directions. This means that although the BGP session may establish (TCP connectivity and OPEN message exchange), no routes will be exchanged, and the neighbor relationship will not be fully functional for route exchange. To establish a working eBGP neighborship that exchanges routes, a routing policy (such as a pass-all policy) must be applied. The absence of this routing policy is the configuration error preventing the ASBR from establishing a functional BGP neighborship. This makes option A the correct answer.

Why the other options are incorrect:

B. The IPv4 address family configuration under neighbor configuration-mode must be removed – The IPv4 address family under the neighbor is correctly configured to activate the neighbor for IPv4 unicast. Removing it would prevent IPv4 route exchange entirely.

C. The VPNv4 address family interferes with the BGP IPv4 address family negotiations – The VPNv4 address family is configured globally but is not activated under the neighbor, so it does not interfere with the IPv4 unicast address family negotiations.

D. The TCP session parameters are not specified – BGP does not require explicit TCP session parameters for basic neighbor establishment. TCP port 179 is used by default, and the session can be established without additional TCP configuration.

Reference:
Cisco IOS XR Routing Configuration Guide – Implementing BGP: Default Behavior for eBGP Neighbors Without Policies; RFC 4271 – A Border Gateway Protocol 4 (BGP-4); Cisco 350-501 SPCOR Official Cert Guide, BGP chapter.

Explanation

The exhibit shows an engineer configuring a BGP neighbor with `remote-as 65507` on a Cisco IOS XR router. To prevent a DoS attack on the BGP session, the engineer must enable TTL security (GTSM, Generalized TTL Security Mechanism) for the neighbor. In Cisco IOS XR, the command to enable TTL security for a specific neighbor is `neighbor ttl-security hops ` under the BGP neighbor configuration mode. This mechanism ensures that BGP packets are only accepted if their TTL is at least 255 minus the configured hop count, which prevents spoofed BGP packets from attackers that are more than the specified number of hops away. This makes option D the correct answer.

Why the other options are incorrect:

A. neighbor ebgp-multihop – The `ebgp-multihop` command allows eBGP peering with neighbors that are more than one hop away. It does not provide security against DoS attacks and is used for multihop peering scenarios.

B. ebgp-multihop – This is the same as option A but without the `neighbor` keyword. It is not a valid command in this context and does not provide TTL security.

C. ttl-security – While `ttl-security` is the correct keyword, in Cisco IOS XR the full command syntax requires `neighbor ttl-security hops `, not just `ttl-security`. Option D is the complete and correct form.

Reference:
RFC 5082 – The Generalized TTL Security Mechanism (GTSM); Cisco IOS XR Routing Configuration Guide – Implementing BGP: TTL Security; Cisco 350-501 SPCOR Official Cert Guide, BGP and Security sections.

Explanation

To ensure that the IGP routing protocol waits until LDP convergence is completed before advertising a link, the engineer must configure MPLS LDP IGP synchronization on the network. This feature prevents packet loss by ensuring that the IGP does not advertise a link as usable until LDP has converged and label bindings are established on that link. Without synchronization, the IGP could advertise the link before LDP is ready, causing traffic to be forwarded without labels and potentially dropped. This makes option B the correct answer.

Why the other options are incorrect:

A. Disable IP CEF on routers running LDP and enable LDP protocol – CEF must remain enabled for MPLS LDP to function properly. Disabling CEF would break MPLS forwarding and is not a valid solution.

C. Configure LDP session protection on the network – LDP session protection uses targeted hellos to maintain LDP sessions during link failures. It does not make the IGP wait for LDP convergence.

D. Disable MPLS LDP IGP synchronization on the network – Disabling LDP-IGP synchronization is the opposite of what is required. It would allow the IGP to advertise links before LDP converges, potentially causing packet loss.

Reference:
RFC 5443 – LDP IGP Synchronization; Cisco IOS XR MPLS Configuration Guide – Implementing LDP: LDP-IGP Synchronization; Cisco 350-501 SPCOR Official Cert Guide, MPLS chapter.

Explanation

A Prefix Segment Identifier (Prefix-SID) in Segment Routing is globally unique within the Segment Routing domain. The Prefix-SID identifies a prefix (typically a loopback address) and represents the shortest path to that node's prefix. Because it must be understood by all routers in the SR domain to forward traffic correctly, it must be unique across the entire domain, not just locally on a single router. This makes option B the correct answer.

Why the other options are incorrect:

A. It contains the interface address of the device per each link – A Prefix-SID is associated with a prefix (usually a loopback), not with each individual interface address on every link. Interface addresses are not the basis of Prefix-SIDs.

C. It is locally unique – Locally unique identifiers are Adjacency SIDs, which are significant only on the router that advertises them. Prefix-SIDs must be globally unique within the SR domain.

D. It contains a router to a neighbor – A Prefix-SID identifies a prefix (node), not a neighbor relationship. Adjacency SIDs are used to identify a specific neighbor or link.

Reference:
RFC 8402 – Segment Routing Architecture; RFC 8665 – OSPF Extensions for Segment Routing; Cisco IOS XR Segment Routing Configuration Guide – Configuring Prefix-SIDs; Cisco 350-501 SPCOR Official Cert Guide, Segment Routing chapter.

Explanation

To ensure that all outbound traffic from Router 1 uses the link between R1 and R3 to reach ASN 4567, the engineer must influence outbound path selection on Router 1. The BGP attribute that controls outbound path selection on a Cisco router is weight, which is a Cisco-proprietary attribute and is locally significant to the router. A higher weight value makes a path more preferred. Therefore, the engineer must configure a high weight on the peer to ASN 4567 (Router 3) so that Router 1 prefers the path through R3 for all outbound traffic destined to ASN 4567. This makes option B the correct answer.

Why the other options are incorrect:

A. Configure a low weight on the peer to ASN 4567 – A low weight would make the path through ASN 4567 less preferred, causing outbound traffic to use a different path. This is the opposite of the requirement.

C. Configure an AS path prepend on the peer to ASN 4567 – AS path prepending is used to influence inbound traffic from other autonomous systems, not outbound traffic from Router 1. It would not affect Router 1's outbound path selection.

D. Configure a high MED on the peer to ASN 4567 – MED (Multi-Exit Discriminator) is used to influence inbound traffic from an external AS. It does not control outbound path selection on Router 1, and a high MED is typically less preferred.

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