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

Explanation

The exhibit shows that R1's OSPF interface is configured with `Network Type POINT_TO_POINT` and an MTU of 9216 bytes, while R2's OSPF interface is configured with `Network Type POINT_TO_MULTIPOINT` and an MTU of 1500 bytes. When two OSPF routers are stuck in EXCHANGE/EXSTART state, the most common cause is an MTU mismatch, because during database descriptor (DBD) exchange each router includes its MTU in the DBD packets, and if the MTUs do not match the routers refuse to proceed. Additionally, the network type mismatch (point-to-point vs point-to-multipoint) is also present and would cause adjacency problems because the hello and dead timer behavior differs between these network types. However, the specific symptom of being stuck in EXCHANGE/EXSTART is directly tied to the MTU mismatch. Among the options provided, matching the MTU value is the fix that addresses the EXCHANGE/EXSTART hang. This makes option D the correct answer.

Why the other options are incorrect:

A. match IPv4 addresses – The IP addresses 172.20.1.12/31 and 172.20.1.13/31 are in the same /31 subnet and are correctly configured. IP addresses do not need to match; they only need to be in the same subnet, which they are.

B. match OSPF areas – R1 is in Area 0.0.1.255 and R2 is in Area 511, which is a mismatch. While area mismatch would prevent adjacency, the routers would not progress to EXCHANGE/EXSTART state at all. They would be stuck in DOWN or INIT. The EXCHANGE/EXSTART symptom specifically points to MTU mismatch.

C. match OSPF network types – The network type mismatch (point-to-point vs point-to-multipoint) is a real issue that should also be corrected, but it is not the direct cause of the EXCHANGE/EXSTART hang. Network type mismatch typically causes the adjacency to fail earlier (INIT or DOWN) due to hello timer or DR election differences. The specific EXCHANGE/EXSTART state is a classic MTU mismatch indicator.

Reference:

RFC 2328 – OSPF Version 2 (Database Description packet MTU field); Cisco IOS XR Routing Configuration Guide – Implementing OSPF: Troubleshooting Adjacency Issues; Cisco 350-501 SPCOR Official Cert Guide, OSPF chapter.

Explanation

The exhibit shows that R1 and R2 are directly connected on FastEthernet0/0 interfaces and are receiving OSPF hello mismatch errors. The debug output reveals a Mask mismatch (`Mask R 255.255.255.252 C 255.255.255.0`), meaning R1 has a /24 mask (255.255.255.0) while R2 has a /30 mask (255.255.255.252). On a broadcast network type (the default for FastEthernet), OSPF requires the subnet mask to match between neighbors, and this mismatch prevents adjacency formation. Changing the OSPF network type to point-to-point on both interfaces eliminates the subnet mask check, because point-to-point network type does not require masks to match. This allows the adjacency to form. This makes option C the correct answer.

Why the other options are incorrect:

A. ip ospf network non-broadcast – Non-broadcast network type still requires the subnet mask to match and requires manual neighbor configuration. It would not resolve the mask mismatch issue.

B. ip ospf network point-to-multipoint non-broadcast – Point-to-multipoint does not require mask matching, but the non-broadcast variant requires manual neighbor statements and is unnecessarily complex for a direct point-to-point link. The simpler and standard fix is point-to-point.

D. ip ospf network broadcast – Broadcast is the default network type on FastEthernet, which is already in effect and is causing the mask mismatch problem. Changing to broadcast explicitly would not fix anything.

Reference:

RFC 2328 – OSPF Version 2 (Network types and mask requirements); Cisco IOS XR Routing Configuration Guide – Implementing OSPF: Network Types; Cisco 350-501 SPCOR Official Cert Guide, OSPF chapter.

Explanation

In the Cisco IOS command `snmp-server community ciscotest ro 2`, the string `ciscotest` is the community string, `ro` grants read-only access, and the number `2` at the end is an access list number. This number references a standard IP access list that defines which SNMP managers (by source IP address) are permitted to query the router using this community string. It does not specify the SNMP version or the number of managers. This makes option D the correct answer.

Why the other options are incorrect:

A. It dictates the number of sessions that will be open with the SNMP manager – The command does not limit or define the number of SNMP sessions. SNMP sessions are not controlled by this parameter.

B. It represents the version of SNMP running – SNMP version is not configured with this command. SNMPv1, v2c, and v3 are enabled through different commands such as `snmp-server host` or `snmp-server group`, not by a number appended to the community string.

C. It indicates two SNMP managers are able to read and write with the agent using community string ciscotest – The number 2 does not specify a count of managers. It is an ACL reference, and the access is read-only (`ro`), not read-write.

Reference:

Cisco IOS Network Management Command Reference – snmp-server community; RFC 1157 – A Simple Network Management Protocol (SNMP); Cisco 350-501 SPCOR Official Cert Guide, Network Assurance section.

Explanation

To make a router forward multicast traffic for a specific group such as 239.10.10.10, the interface must join that multicast group so the router becomes a receiver and sends IGMP membership reports. The command `ip igmp join-group 239.10.10.10` configures the interface to join the specified multicast group, which causes the router to process and forward traffic for that group. This makes option D the correct answer.

Why the other options are incorrect:

A. Cisco(config-if)# ip igmp max-groups action replace – This command limits the maximum number of IGMP groups an interface can join and defines the action when the limit is exceeded. It does not cause the router to join a specific group or forward its traffic.

B. Cisco(config-if)# ip igmp filter – This command applies an IGMP filter profile to restrict which groups hosts on the interface can join. It is used to limit access, not to forward traffic for a specific group.

C. Cisco(config-if)# ip igmp access-group 239.10.10.10 – This command applies an access group to control which multicast groups hosts on the interface may join. The argument should be an access list number or name, not a multicast group address, so the syntax is incorrect and it does not make the router forward traffic.

Reference:

Cisco IOS XR Multicast Configuration Guide – Configuring IGMP and Multicast Group Membership; RFC 3376 – Internet Group Management Protocol, Version 3; Cisco 350-501 SPCOR Official Cert Guide, Multicast chapter.

Explanation

The exhibit shows a model-driven telemetry configuration on an IOS XR router. The `telemetry model-driven` command enters telemetry configuration mode. The `sensor-group cisco` command creates a sensor group named "cisco". The `sensor-path Cisco-IOS-XR-infra-statsd-oper:infra-statistics/interfaces/interface/latest/generic-counters` command adds a YANG model path to that sensor group, which specifies the exact data to be streamed. This configuration creates a sensor group containing a list of YANG model paths used for streaming telemetry data. This makes option D the correct answer.

Why the other options are incorrect:

A. It is used to create a subscription to specify the streaming interval – A subscription is created with the `subscription` command under telemetry configuration, not with `sensor-group`. The exhibit does not show any subscription or streaming interval configuration.

B. It is used to identify traps for SNMP polling – This is model-driven telemetry, not SNMP. SNMP traps are configured with `snmp-server host` and related commands, which are not present here.

C. It is used to identify MIB entries and has a list of YANG models – While MIBs and YANG models are related concepts, this configuration specifically defines a sensor group with YANG model paths for streaming, not MIB entries for polling. The distinction is that telemetry uses YANG paths, not MIB OIDs.

Reference:

Cisco IOS XR Telemetry Configuration Guide – Model-Driven Telemetry: Sensor Groups and Sensor Paths; RFC 7950 – The YANG 1.1 Data Modeling Language; Cisco 350-501 SPCOR Official Cert Guide, Automation and Assurance section.

Explanation

The route-policy must accept only customer-assigned prefixes, preserve customer-advertised BGP communities, set local-preference to 110, and attach the ORIGINATION-PE and LOCAL-CITY communities. The `additive` keyword is critical because it appends the new communities to the existing ones instead of overwriting them, which satisfies the requirement to preserve customer-advertised communities. The correct policy must use `set community ORIGINATION-PE additive` and `set community LOCAL-CITY additive`, along with `set local-preference 110` and the `if destination in $CUSTOMER_PREFIX then pass else drop` logic. Only Option A contains both `additive` keywords on both community statements, making it the correct answer.

Why the other options are incorrect:

B. Option B – It is missing the `additive` keyword on `set community ORIGINATION-PE`, which means the ORIGINATION-PE community would overwrite the customer's existing communities, violating the requirement to preserve them.

C. Option C – It is missing the `additive` keyword on `set community LOCAL-CITY`, which means the LOCAL-CITY community would overwrite existing communities, violating the preservation requirement.

D. Option D – It is missing the `additive` keyword on both community statements, so both ORIGINATION-PE and LOCAL-CITY would overwrite the customer's advertised communities, failing the requirement.

Reference:

Cisco IOS XR Routing Configuration Guide – Implementing Routing Policy: Set Community Additive; RFC 1997 – BGP Communities Attribute; Cisco 350-501 SPCOR Official Cert Guide, BGP chapter.

Explanation

In an inter-AS MPLS L3VPN scenario where a regional provider connects its sites over a global carrier backbone, the edge routers at the different regional sites must exchange customer VPNv4 routes. This is accomplished by running MP-eBGP (Multiprotocol eBGP) between the ASBRs or PE routers across the carrier backbone, using the VPNv4 address family to carry the customer routes and their associated route targets and MPLS labels. Option A correctly states that MP-eBGP must run between the routers to exchange customer VPNv4 routes, making it the correct answer.

Why the other options are incorrect:

B. When eBGP is used for label exchange using the send label option, MPLS-BGP forwarding is configured under the global ABC CSC PE-to-CE interface – The `send-label` option is used for BGP labeled unicast (RFC 3107) between provider routers, not on the PE-to-CE interface. The PE-to-CE interface uses IP forwarding or VRF-lite, not MPLS-BGP forwarding.

C. When IGP is used for route exchange and LDP for label exchange, MPLS is enabled only on the VRF interface on the backbone-carrier PE side – MPLS must be enabled on the core-facing interfaces for LDP to distribute labels, not on the VRF interface. The VRF interface is the customer-facing side and does not run LDP.

D. When BGP is used for both route and label exchange, the neighbor a.b.c.d send-label command is used under the address family VPNv4 command mode – The `send-label` command is used under the IPv4 unicast address family for BGP labeled unicast, not under the VPNv4 address family. VPNv4 routes already carry labels as part of the NLRI, so `send-label` is not needed there.

Reference:

RFC 4364 – BGP/MPLS IP Virtual Private Networks (VPNs); RFC 3107 – Carrying Label Information in BGP-4; Cisco IOS XR MPLS Configuration Guide – Inter-AS MPLS VPN Options; Cisco 350-501 SPCOR Official Cert Guide, MPLS L3VPN chapter.

Explanation

In a Unified MPLS architecture with partitioned IGP domains, the ABR (R102) must act as a BGP route reflector for its iBGP labeled unicast clients and must enable label distribution to those peers. The correct configuration under the IPv4 address family must include `route-reflector-client` for each iBGP peer (172.16.0.5 and 172.16.0.11, and optionally 172.16.0.12), `next-hop-self` to ensure next-hop reachability across IGP domain boundaries, and `send-label` to distribute MPLS labels via BGP labeled unicast. Option D includes all three required elements — route-reflector-client, next-hop-self, and send-label — for every neighbor, which satisfies the requirements for Unified MPLS with partitioned IGP domains. This makes option D the correct answer.

Why the other options are incorrect:

A. Option A – It includes `route-reflector-client` and `send-label` but omits `next-hop-self`. Without next-hop-self, the next hop for reflected routes may be unreachable across the partitioned IGP domains, breaking the Unified MPLS forwarding path.

B. Option B – It includes all three elements for neighbor 172.16.0.5, but for neighbors 172.16.0.11 and 172.16.0.12 it omits `route-reflector-client`, which is required for R102 to act as a route reflector for those iBGP peers.

C. Option C – It includes `route-reflector-client` and `next-hop-self` but omits `send-label` on all neighbors. Without send-label, BGP labeled unicast is not enabled, so MPLS labels are not exchanged and the Unified MPLS LSP cannot be built.

Reference:

Cisco IOS XR MPLS Configuration Guide – Unified MPLS and BGP Labeled Unicast; RFC 3107 – Carrying Label Information in BGP-4; RFC 4456 – BGP Route Reflection; Cisco 350-501 SPCOR Official Cert Guide, MPLS and BGP chapters.

Explanation

The BFD interval configuration is applied under an interface or subinterface. When the BFD-configured subinterface is removed, the BFD interval configuration associated with that subinterface is also removed and the BFD session is disconnected. This is because the BFD configuration is tied to the subinterface on which it was applied, and deleting the subinterface removes all configuration under it, including BFD interval settings. This makes option C the correct answer.

Why the other options are incorrect:

A. The status of the interface changes – An interface going up or down does not remove the BFD interval configuration. The configuration remains in place and the BFD session may re-establish when the interface comes back up.

B. The IPv4 or IPv6 address configuration on the interface changes – Changing the IP address does not delete the BFD interval configuration. The BFD configuration remains under the interface regardless of address changes.

D. It is automatically disconnected when the BFD main interface is removed – Removing the main interface would also remove subinterfaces and their BFD configuration, but the specific and more precise behavior is tied to the subinterface removal, not the main interface. Option C is the more accurate answer.

Reference:

Cisco IOS XR Routing Configuration Guide – Configuring BFD: BFD on Subinterfaces; RFC 5880 – Bidirectional Forwarding Detection (BFD); Cisco 350-501 SPCOR Official Cert Guide, Network Assurance section.

Explanation

Cisco MPLS TE tunnels use RSVP-TE to reserve bandwidth and signal the Label Switched Path across the core, which is one of their fundamental characteristics. MPLS TE tunnels are also unidirectional: a tunnel carries traffic from the headend (ingress) to the tailend (egress), and a separate tunnel must be configured in the reverse direction for bidirectional traffic. These two characteristics make options B and E the correct answers.

Why the other options are incorrect:

A. They require EIGRP to be running in the core – MPLS TE does not require EIGRP specifically. It can run with OSPF or IS-IS as the IGP, as long as the IGP is extended with TE capabilities.

C. They are run over Ethernet cores only – MPLS TE can run over various Layer 2 technologies, including SONET/SDH, DWDM, and Ethernet. It is not limited to Ethernet cores.

D. The headend and tailend routes of the tunnel must have a BGP relationship – MPLS TE tunnels do not require a BGP relationship between the headend and tailend routers. They are signaled by RSVP-TE and rely on the IGP for reachability, not BGP.

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.