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

Explanation

QoS Policy Propagation Through BGP (QPPB) uses BGP attributes such as AS_PATH to classify traffic and assign a QoS group, which is then used to apply QoS policies. The exhibit shows a route-policy that matches specific AS_PATH values and sets a QoS group of 10, applied to the BGP table via `table-policy`. By leveraging BGP, QPPB can classify traffic based on prefix or AS_PATH information and propagate those classifications across the network without needing to manually define QoS policies on every router. This allows QoS policies to gain full coverage on the network using BGP as the classification and propagation mechanism. This makes option C the correct answer.

Why the other options are incorrect:

A. QoS policies are identified in the MPLS forwarding table – QPPB classification is derived from BGP attributes and applied to the RIB/FIB, not specifically from the MPLS forwarding table. While QPPB can be used in MPLS networks, the identification of QoS policies is based on BGP path attributes, not the MPLS forwarding table entries.

B. QoS policies rely exclusively on BGP attributes to manipulate traffic – QPPB uses BGP attributes to classify traffic and set QoS groups, but the actual QoS treatment is carried out by QoS policies such as policing, marking, and queuing. Saying policies rely exclusively on BGP attributes is inaccurate because the enforcement is done by QoS mechanisms.

D. QPPB policies affect only egress traffic – QPPB can affect both ingress and egress traffic. QoS groups set through QPPB can be used to apply input and output policies on interfaces. Restricting QPPB to egress only is incorrect.

Reference:

Cisco IOS XR Routing Configuration Guide – Implementing BGP: QoS Policy Propagation Through BGP (QPPB); Cisco 350-501 SPCOR Official Cert Guide, BGP and QoS sections.

Explanation

Cisco MPLS Traffic Engineering (TE) tunnels use RSVP (Resource Reservation Protocol) with TE extensions to establish and maintain Label Switched Paths (LSPs) across the core network. RSVP-TE signals the tunnel, reserves the required bandwidth, and enforces the explicit or dynamic path constraints along each hop. It is also responsible for maintaining the path through refresh messages and for tearing down or rerouting the tunnel if a link fails. This makes option A the correct answer.

Why the other options are incorrect:

B. VTP – VLAN Trunking Protocol is a Cisco proprietary Layer 2 protocol used to propagate VLAN configuration across switches. It has no role in MPLS TE path maintenance.

C. STP – Spanning Tree Protocol is a Layer 2 loop-prevention protocol used in Ethernet networks. It is unrelated to MPLS TE and does not signal or maintain MPLS LSPs.

D. RPF – Reverse Path Forwarding is a multicast and unicast forwarding check used to prevent loops and spoofing. It is not a signaling protocol and does not maintain MPLS TE paths.

Reference:

RFC 3209 – RSVP-TE: Extensions to RSVP for LSP Tunnels; Cisco IOS XR MPLS Configuration Guide – Implementing MPLS Traffic Engineering; Cisco 350-501 SPCOR Official Cert Guide, MPLS Traffic Engineering chapter.

Explanation

For two OSPF routers to form and maintain an adjacency, the hello interval must match on both interfaces. In the exhibit, Router 1 has `ip ospf hello-interval 1` while Router 2 has `ip ospf hello-interval 2`. This mismatch causes hello packets to be sent at different intervals, and each router will declare the other dead before receiving a valid hello, preventing the neighbor relationship from forming. To reestablish the OSPF neighbor relationship, the hello intervals must match on both routers. This makes option D the correct answer.

Why the other options are incorrect:

A. authentication is added to the configuration – Authentication is not currently configured on either router, so adding it is not required to reestablish the adjacency. If authentication were mismatched, it would cause a problem, but that is not the case here.

B. correct wildcard mask is used on Router 2 – Router 2 uses `network 192.168.1.2 0.0.0.0 area 1`, which matches the exact interface address. While this is an unusual wildcard mask, it still places the interface in area 1 and does not prevent adjacency formation. The wildcard mask is not the cause of the problem.

C. OSPF process IDs match – OSPF process IDs are locally significant and do not need to match between neighbors. Router 1 uses process 1 and Router 2 uses process 2, which is perfectly valid and does not affect adjacency formation.

Reference:

RFC 2328 – OSPF Version 2; Cisco IOS XR Routing Configuration Guide – Implementing OSPF: Neighbor Adjacency Requirements; Cisco 350-501 SPCOR Official Cert Guide, OSPF chapter.

Explanation

When configuring an 802.1q VLAN tag, the MTU must be increased by 4 bytes to accommodate the VLAN tag that is inserted into the Ethernet frame. The 802.1q tag adds a 4-byte field consisting of a 2-byte Tag Protocol Identifier (TPID) and a 2-byte Tag Control Information (TCI) field. Because this tag increases the frame size, the MTU on interfaces carrying tagged traffic must be increased by 4 bytes to prevent the tagged frames from being dropped as oversized. This makes option B the correct answer.

Why the other options are incorrect:

A. 2 bytes – A 2-byte increase would only account for either the TPID or the TCI portion of the 802.1q tag, not the full tag. The complete 802.1q tag is 4 bytes, so 2 bytes is insufficient.

C. 8 bytes – This value is associated with other encapsulations, such as QinQ (802.1ad), which adds two 4-byte tags for a total of 8 bytes. A single 802.1q tag only requires 4 bytes.

D. 12 bytes – This value does not correspond to the 802.1q tag size. MPLS labels, for example, add 4 bytes each, and other encapsulations have different overheads, but 12 bytes is not related to a single VLAN tag.

Reference:

IEEE 802.1Q – Virtual Bridged Local Area Networks; Cisco IOS XR Interface and Hardware Component Configuration Guide – Configuring 802.1q VLAN Subinterfaces; Cisco 350-501 SPCOR Official Cert Guide, Layer 2 VPN and Services section.

Explanation

In the exhibit, Router A (RA) is designated as the Rendezvous Point (RP). When an RP is present, the multicast domain typically uses PIM Sparse Mode (PIM-SM), where receivers join the shared tree rooted at the RP by sending PIM Join messages toward the RP, and sources register with the RP so that multicast traffic is forwarded down the shared tree. The RP is the core of the shared distribution tree in PIM-SM, making it the mode that relies on an RP to direct multicast traffic. This makes option A the correct answer.

Why the other options are incorrect:

B. PIM-DM – PIM Dense Mode does not use an RP at all. It floods multicast traffic throughout the network and relies on prune messages to remove unwanted branches. Since the question states that Router A is the RP, PIM-DM is not applicable.

C. BIDIR-PIM – Bidirectional PIM also uses an RP, but its purpose is to build bidirectional shared trees for many-to-many communication, where traffic flows both toward and away from the RP. The question specifically describes traffic being sent toward the RP, which is characteristic of PIM-SM source registration and shared tree behavior, not BIDIR-PIM.

D. PIM-SSM – PIM Source-Specific Multicast does not use an RP. SSM builds a shortest-path tree directly from the receiver to the source using IGMPv3 and does not rely on a rendezvous point, so it does not match the scenario.

Reference:

RFC 7761 – Protocol Independent Multicast - Sparse Mode (PIM-SM); Cisco IOS XR Multicast Configuration Guide – Configuring PIM-SM and Rendezvous Points; Cisco 350-501 SPCOR Official Cert Guide, Multicast chapter.

Explanation

The exhibit shows the output of `show mpls ldp discovery detail` on R2, which indicates that R2 is sending targeted Hellos to 1.1.1.1 as the transport IP address but has received no Hellos back from R1. The discovery sources only list R2's own target Hellos toward R1, and there is no entry showing R1 as a discovered neighbor. This means R2 is not receiving any Hello messages from R1, which is why no LDP neighbor exists for 1.1.1.1. Common causes include LDP not being enabled on R1's interface, an ACL blocking UDP port 646, or a mismatched LDP configuration. Since the question asks for the reason, the most accurate statement is that R2 does not see any Hellos from R1. This makes option B the correct answer.

Why the other options are incorrect:

A. LDP needs to be enabled on the R2 physical interface – R2 is already sending targeted Hellos to 1.1.1.1, which shows LDP is active on R2. The issue is the absence of Hellos from R1, not the configuration on R2's physical interface.

C. LDP needs to be enabled on the R2 loopback interface – LDP is already enabled on R2's loopback interface (2.2.2.2) as shown by the Local LDP Identifier and targeted Hello output. Enabling it further would not resolve the missing neighbor.

D. R2 sees the wrong type of hellos from R1 – The output shows R2 is not receiving any Hellos at all from R1. There is no indication of wrong Hello types, only a complete absence of incoming Hellos.

Reference:

Cisco IOS XR MPLS Configuration Guide – Implementing LDP: LDP Discovery and Neighbor Formation; RFC 5036 – LDP Specification; Cisco 350-501 SPCOR Official Cert Guide, MPLS chapter.

Explanation

The QoS group is a locally significant, internal marking value (0–63) that is set on the ingress of a router using a policy-map with the `set qos-group` action. Unlike IP precedence, DSCP, or MPLS EXP, the QoS group is not carried in the packet header and is not preserved end to end across the network. It is used only within the local router to carry the classification result from ingress to egress, where it can be matched by an egress policy-map. On Cisco IOS XR platforms with a fabric, the QoS group can also be used as a match criterion in the fabric QoS policy, allowing the fabric to differentiate traffic based on the internal marking. This makes options B and D the correct answers.

Why the other options are incorrect

A. The QoS group numbering corresponds to priority levels – QoS group values (0–63) are arbitrary local markings and do not inherently correspond to priority levels. Priority is defined by the traffic class and the actions (such as priority level 1 or 2) applied to it, not by the QoS group number itself.

C. It marks packets for end-to-end QoS policy enforcement across the network – The QoS group is not written into the packet header, so it is not carried across routers. End-to-end marking requires header fields such as DSCP, IP precedence, or MPLS EXP, not the QoS group.

E. It cannot be used with priority traffic class – The QoS group can be set and matched in policies that also include priority traffic classes. There is no restriction preventing its use with priority traffic.

Reference

Cisco IOS XR Modular QoS Configuration Guide – Configuring QoS Groups and Fabric QoS Policies; Cisco 350-501 SPCOR Official Cert Guide, QoS section.

Explanation

R2 is configured as the Auto-RP mapping agent and R1 as the candidate RP. The mapping agent listens for RP announcement messages from candidate RPs on 224.0.1.39, then floods the resulting RP-to-group mappings to all routers in the multicast domain on 224.0.1.40. This allows every router to learn which RP serves which groups. Therefore R2 floods information about R1 throughout the multicast domain, making option A the correct answer.

Why the other options are incorrect:

B. R2 is unable to share information because the ip pim autorp listener command is missing – The autorp listener is only needed on routers running pure sparse mode that must forward Auto-RP groups. The mapping agent itself does not require it to function, so this is not the effect.

C. R1 floods information about R2 throughout the multicast domain – This reverses the roles. R1 is the candidate RP that announces itself to R2; the mapping agent R2 performs the flooding, not R1.

D. R2 is elected as the RP for this domain – The mapping agent is not the RP. It only distributes RP information. R1 is the candidate RP in this design.

Reference:

Cisco IOS XR Multicast Configuration Guide – Configuring Auto-RP; RFC 5059 – Bootstrap Router (BSR) Mechanism for PIM; Cisco 350-501 SPCOR Official Cert Guide, Multicast chapter.

Explanation

The exhibit shows an IS-IS authentication failure log entry: `%CLNS-4-AUTH_FAIL: ISIS: LAN IIH authentication failed`. The `show isis neighbors` output on R1 shows the R2 neighbor as L2 in the UP state, while on R2 the R1 neighbor shows L1 in INIT state and L2 in UP state. Since the L2 adjacency is UP on both routers but the L1 adjacency is stuck in INIT on R2, the authentication failure is affecting only the Level 1 PDUs. The log message about LAN IIH authentication failure combined with the INIT state for L1 confirms that L1 hello packets are being rejected due to an authentication mismatch, while L2 hellos are accepted. This makes option C the correct answer.

Why the other options are incorrect:

A. IS-IS neighbor authentication is failing for Level 2 first and then for Level 1 PDUs – The L2 adjacency is UP on both routers, which means L2 authentication is succeeding. There is no evidence that L2 is failing first.

B. IS-IS neighbor authentication is failing for Level 1 and Level 2 PDUs – Since the L2 neighbor is in the UP state on both routers, authentication for Level 2 PDUs is working correctly. Only L1 is failing.

D. IS-IS neighbor authentication is failing for Level 2 PDUs only – The L2 adjacency is UP, so Level 2 authentication is not failing. The L1 adjacency is the one stuck in INIT due to authentication failure.

Reference:

ISO/IEC 10589 – IS-IS for Routing Information Exchange; Cisco IOS XR Routing Configuration Guide – Implementing IS-IS: Authentication; Cisco 350-501 SPCOR Official Cert Guide, IS-IS chapter.

Explanation

To allow devices in an administrative domain to dynamically learn the Rendezvous Point (RP), the engineer should implement BSR (Bootstrap Router). BSR is a standards-based mechanism defined in RFC 5059 where candidate RPs send their candidacy to the Bootstrap Router, and the BSR floods RP-to-group mapping information to all PIM routers in the domain via bootstrap messages. This enables every router to dynamically learn which RP serves which multicast groups without manual configuration. This makes option C the correct answer.

Why the other options are incorrect:

A. SSM – Source-Specific Multicast does not use an RP at all. Receivers join a specific source and group directly, so there is no RP to learn dynamically.

B. BIDIR-PIM – Bidirectional PIM uses an RP, but it does not provide a dynamic RP learning mechanism by itself. It still requires either static RP configuration or another mechanism such as BSR or Auto-RP to distribute RP information.

D. Auto-RP – Auto-RP is a Cisco proprietary mechanism that also allows dynamic RP learning, but the option is written as "-RP" which does not correctly identify the protocol. BSR is the standards-based answer typically expected in this context.

Reference:

RFC 5059 – Bootstrap Router (BSR) Mechanism for PIM; Cisco IOS XR Multicast Configuration Guide – Configuring BSR and Auto-RP; Cisco 350-501 SPCOR Official Cert Guide, Multicast chapter.