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

Explanation

The exhibit shows `encoding = gpbkv`, which is the gRPC encoding format used in Cisco IOS XR telemetry. GPBKV stands for Google Protocol Buffers Key-Value, a self-describing encoding format that carries both the key (the telemetry path) and the value (the data) within the message itself. In the context of a gRPC dial-in configuration, the client initiates the connection to the router (the gRPC server) and requests telemetry data using a specific encoding. The `encoding = gpbkv` parameter is specified by the gRPC client in its subscription request to tell the server which encoding format it wants for the streamed telemetry data. This makes option D the correct answer.

Why the other options are incorrect:

A. It is the encoding requested by the gRPC server – In gRPC dial-in mode, the client is the one that initiates the connection and specifies the encoding in the subscription request. The server does not request an encoding from the client; it responds using the encoding the client asked for.

B. IT is the encoding that is used for dial-in and dial-out – While gpbkv can be used in both dial-in and dial-out telemetry, this statement is too vague and does not accurately describe the specific role of the `encoding = gpbkv` parameter in a dial-in configuration. The parameter itself is a client-side request, not a generic statement about both modes.

C. It is used for encoding with the default protocol buffers – GPBKV is not the default Protocol Buffers encoding. The default Protocol Buffers (GPB) encoding is a compact, schema-based format that does not embed keys in the message. GPBKV is a separate, key-value variant that is self-describing and is selected explicitly by the client.

Reference:

Cisco IOS XR Telemetry Configuration Guide – gRPC Dial-In and Dial-Out Telemetry, Encoding Formats (GPB, GPBKV, JSON); Cisco 350-501 SPCOR Official Cert Guide, Automation and Assurance section; Cisco gRPC Telemetry documentation – Protocol Buffers Key-Value (GPBKV) encoding.

Explanation

Auto-RP relies on dense-mode PIM flooding to propagate RP announcement and discovery messages (224.0.1.39 and 224.0.1.40) across the multicast domain, because the RP mapping agents and candidate RPs must hear these messages before any shared tree exists. For Auto-RP to function, the interface must be enabled with either `ip pim sparse-dense-mode` or, in modern IOS, `ip pim sparse-mode` combined with `ip pim autorp listener`. In the exhibit, the interface GigabitEthernet0/0 is the interface over which Auto-RP messages must be forwarded, and it currently lacks any PIM configuration. The command `ip pim sparse-dense-mode` enables PIM on the interface and allows the dense-mode flooding behavior required for Auto-RP group messages to be forwarded. This makes option D the correct answer.

Why the other options are incorrect:

A. PE-A(config-if)#ip pim sparse-mode – Sparse mode alone does not forward Auto-RP messages, because Auto-RP uses dense-mode flooding to reach all routers before the RP is known. Sparse mode would drop these groups unless `ip pim autorp listener` is also configured, which is not present here.

B. PE-A(config-if)#no ip pim bsr-border – The `ip pim bsr-border` command is used to prevent BSR (Bootstrap Router) messages from crossing a domain boundary. It has no effect on Auto-RP forwarding and does not enable PIM on the interface.

C. PE-A(config-if)#ip igmp version 3 – IGMP version 3 controls how hosts report multicast group memberships. It is unrelated to PIM forwarding of Auto-RP messages between routers and does not enable PIM on the interface.

Reference:

Cisco IOS XR Multicast Configuration Guide – Configuring Auto-RP and PIM Sparse-Dense Mode; Cisco 350-501 SPCOR Official Cert Guide, Multicast chapter; RFC 4601 – Protocol Independent Multicast - Sparse Mode (PIM-SM); Cisco documentation on Auto-RP and the `ip pim autorp listener` command.

Explanation

The exhibit shows the interface configuration `no ip directed-broadcast` on GigabitEthernet0/2. This command disables the forwarding of directed broadcasts, which are IP packets sent to a subnet's broadcast address (for example, 192.168.1.255) rather than the all-hosts address 255.255.255.255. A smurf attack exploits directed broadcasts by sending a large number of ICMP echo requests to a network's broadcast address with a spoofed source address of the victim. All hosts on that network reply to the victim, amplifying the traffic and overwhelming it. Disabling directed broadcast on the interface prevents the router from forwarding these broadcast packets onto the subnet, which effectively mitigates smurf attacks. This makes option B the correct answer.

Why the other options are incorrect:

A. SYN flood – A SYN flood is a TCP-layer attack that exploits the TCP three-way handshake by sending many SYN packets with spoofed source addresses. It is mitigated by TCP intercept, SYN cookies, or firewall features such as `ip tcp intercept`, not by disabling directed broadcasts.

C. SIP INVITE flood attacks – A SIP INVITE flood targets VoIP infrastructure by sending excessive SIP INVITE messages to overwhelm call-processing resources. It is mitigated by SIP-aware firewalls, rate limiting, or VoIP-specific protections, not by `no ip directed-broadcast`.

D. teardrop attack – A teardrop attack sends fragmented IP packets with overlapping or malformed fragment offsets, causing targets to crash when reassembling them. It is mitigated by OS patching, firewall fragment inspection, or ACLs that drop malformed fragments, not by disabling directed broadcasts.

Reference:

Cisco IOS Security Configuration Guide – Configuring IP Directed Broadcast and Mitigating Smurf Attacks; Cisco 350-501 SPCOR Official Cert Guide, Security and Network Assurance section; RFC 2644 – Changing the Default for Directed Broadcasts in Routers.

It enables peer 192.168.1.2 to establish a BGP relationship with R1 using AS 65112
without additional configuration.

Explanation

The `local-as` keyword in BGP allows a router to appear as a different autonomous system number to a specific neighbor during BGP peering establishment. In the exhibit, R1 has a real AS of 65000 but is configured with `neighbor 192.168.1.2 local-as 65112`. This means R1 will present itself as AS 65112 to peer 192.168.1.2 while still using AS 65000 internally. The peer 192.168.1.2 is configured with `remote-as 65012`, which matches the real AS of R1 (65000) plus the local-as value (65112) combined in a way that the peer sees AS 65112 in the AS_PATH. This allows the peer to establish a BGP relationship with R1 using AS 65112 without requiring additional configuration on the peer side beyond the existing neighbor statement. This makes option D the correct answer.

Why the other options are incorrect:

A. It enables peer 192.168.1.2 to establish a BGP relationship with R1 using AS 65012 and the VPNv4 address family – The local-as value is 65112, not 65012. Additionally, the local-as keyword does not enable or require the VPNv4 address family; it only affects the AS number presented during peering.

B. It enables peer 192.168.1.2 to establish a BGP relationship with R1 using AS 65012 without additional configuration – The local-as value is 65112, not 65012, so this option misstates the AS number that the peer will use for peering.

C. It enables peer 192.168.1.2 to establish a BGP relationship with R1 using AS 65112 and the VPNv4 address family – While the AS number 65112 is correct, the local-as keyword has no relationship to the VPNv4 address family. VPNv4 is enabled separately under the address-family configuration, and this option incorrectly implies that local-as enables it.

Reference:

Cisco IOS XR Routing Configuration Guide – Implementing BGP: Neighbor local-as; RFC 4271 – A Border Gateway Protocol 4 (BGP-4); Cisco 350-501 SPCOR Official Cert Guide, BGP chapter.

Explanation

For R8 to establish an OSPF adjacency with R5, both routers must agree on the OSPF area, network type, and MTU on the connecting interface. R5's GigabitEthernet1.58 is configured with `ip address 192.168.58.5 255.255.255.0`, `ip mtu 1600`, and `ip ospf network point-to-point` under `router ospf 1` with area 0.0.0.2. Therefore, R8 must be configured with the matching subnet 192.168.58.0/24 in area 0.0.0.2, an MTU of 1600 to match R5, and the OSPF network type set to point-to-point. Option D provides all of these matching parameters: `network 192.168.58.0 0.0.0.255 area 0.0.0.2`, `ip mtu 1600`, and `ip ospf network point-to-point` on GigabitEthernet1.58. This makes option D the correct answer.

Why the other options are incorrect:

A. Option A – This option uses `ip ospf network point-to-multipoint`, which does not match R5's `point-to-point` network type. A mismatch in OSPF network type prevents adjacency formation because the hello timers and DR/BDR election behavior differ between these types.

B. Option B – This option places the network in `area 2` instead of `area 0.0.0.2`. OSPF neighbors must be in the same area to form an adjacency, so the area mismatch will prevent adjacency establishment.

C. Option C – This option matches the area and network type but omits the `ip mtu 1600` command. R5 has an MTU of 1600 configured, and if R8 uses the default MTU (1500), the MTU mismatch will prevent the OSPF adjacency from reaching the FULL state, typically causing it to remain in EXSTART or exchange state.

Reference:

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

Explanation

Unicast Reverse Path Forwarding (uRPF) in strict mode verifies that the source IP address of every packet arriving on an interface is reachable through the same interface the packet arrived on, as determined by the Forwarding Information Base (FIB). If the FIB lookup for the source address returns an outgoing interface that is different from the ingress interface, the packet is dropped. When strict uRPF is configured on both interfaces of R1 and R1 is multihomed to two service providers, the router will drop any traffic entering one interface whose return path points out the other interface. This effectively enforces symmetric routing and drops spoofed traffic that does not have a valid return path. This makes option D the correct answer.

Why the other options are incorrect:

A. R1 accepts source addresses on interface gigabitethernet0/1 that are private addresses – Strict uRPF does not make any special exception for private addresses. If a private source address does not have a valid return path out of the same ingress interface in the FIB, the packet will be dropped. There is no rule that strict uRPF accepts private addresses.

B. R1 permits asymmetric routing as long as the AS-PATH attribute entry matches the connected AS – Strict uRPF explicitly prevents asymmetric routing by requiring the return path to match the ingress interface. It does not evaluate BGP AS_PATH attributes, so this statement is incorrect.

C. R1 drops destination addresses that are routed to a null interface on the router – uRPF operates on source addresses, not destination addresses. While packets destined to null routes may be dropped by other mechanisms, strict uRPF does not perform this function.

Reference:

Cisco IOS XR Security Configuration Guide – Unicast Reverse Path Forwarding (uRPF) Strict Mode; RFC 3704 – Ingress Filtering for Multihomed Networks; Cisco 350-501 SPCOR Official Cert Guide, Security and Network Assurance section.

Explanation

NetFlow version 9 introduces template-based export and supports a much broader set of fields than version 5, including IPv6 flow information. Unlike NetFlow v5, which is limited to IPv4 flow records only, NetFlow v9 can export IPv6 fields such as IPv6 source and destination addresses, IPv6 next hop, and IPv6 traffic class. Therefore, upgrading the configuration from version 5 to version 9 enables the router to report IPv6 flow information, which was not possible with version 5. This makes option A the correct answer.

Why the other options are incorrect:

B. flow sequence numbers – Flow sequence numbers are already supported in NetFlow version 5. Version 9 continues to use sequence numbers for export packet ordering, so this is not an additional piece of information gained by upgrading.

C. BGP AS information – BGP AS information (origin-AS, peer-AS) is already available in NetFlow version 5 through the `origin-as` keyword shown in the exhibit. Upgrading to version 9 does not introduce BGP AS reporting as a new capability.

D. IPv4 flow information – IPv4 flow information is the primary content of NetFlow version 5 and remains supported in version 9. It is not new or additional information provided by the upgrade.

Reference:

Cisco IOS NetFlow Configuration Guide – NetFlow Version 9 and IPv6 Flow Export; RFC 3954 – Cisco Systems NetFlow Services Export Version 9; Cisco 350-501 SPCOR Official Cert Guide, Automation and Assurance section.

Explanation

For two OSPF devices to establish an adjacency, several interface and area parameters must match on both sides. The subnet mask must match because OSPF uses the mask to determine whether the two interfaces are on the same network; a mismatch prevents the routers from forming a neighbor relationship. The hello timer setting must match because OSPF hello packets carry the hello interval, and if the intervals differ, the routers will not consider each other valid neighbors. The area number must match because OSPF requires both interfaces to be in the same area to form an adjacency and exchange LSAs. This makes options C, E, and F the correct answer.

Why the other options are incorrect:

A. IP address – The IP addresses of the two interfaces must be in the same subnet, but they must be different from each other. Identical IP addresses would cause a conflict, so the IP address itself is not a parameter that must match.

B. interface cost – Interface cost is used for SPF calculation and can differ on each side of a link. It does not need to match for an adjacency to form.

D. process ID – The OSPF process ID is locally significant and only identifies the OSPF instance on the local router. It does not need to match between neighbors.

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

The exhibit shows a configuration that enables MPLS Traffic Engineering with Segment Routing on a Cisco router. The `mpls traffic-eng tunnels` command globally enables MPLS TE, while the `segment-routing mpls` command under both the global configuration and `router isis 1` enables Segment Routing using MPLS data plane. The `connected-prefix-sid-map` defines a prefix SID for the loopback address 192.168.1.1/32 with an index range, and the `set-attributes` block with `sr-label-preferred` indicates that SR labels are preferred for the TE tunnels. The `router isis 1` configuration includes `mpls traffic-eng router-id Loopback1` and `mpls traffic-eng level-1`, which are typical of a head-end router configuration for MPLS TE tunnels that leverage Segment Routing instead of RSVP-TE. This makes option C the correct answer.

Why the other options are incorrect:

A. It is configuration that requires an explicit Cisco MPLS TE path to be configured for the tunnel to run – Segment Routing TE does not require an explicit path to be manually configured; it can use the SR path computed by the IGP and the segment list. The exhibit does not show any explicit path configuration.

B. It is configuration that requires OSPF to also be running to have optimized Cisco MPLS TE tunnels – The exhibit shows IS-IS as the IGP (`ip router isis 1`, `router isis 1`), not OSPF. MPLS TE can operate with either IS-IS or OSPF, so requiring OSPF is incorrect.

D. It is configuration that requires a dynamic Cisco MPLS TE path to be configured for the tunnel – While dynamic paths can be used, the exhibit specifically shows Segment Routing configuration, not a requirement for a dynamic path. The SR configuration itself provides the path via prefix SIDs, so a separately configured dynamic path is not required.

Reference:

Cisco IOS XR MPLS Configuration Guide – Segment Routing and MPLS Traffic Engineering; Cisco 350-501 SPCOR Official Cert Guide, MPLS and Segment Routing chapters; RFC 8402 – Segment Routing Architecture.

Explanation

To influence inbound path selection in a multihomed BGP architecture, the engineer must manipulate the AS_PATH attribute. When a router advertises its prefixes to external neighbors, prepending additional AS numbers to the AS_PATH makes the path appear longer to the receiving autonomous systems, which causes them to prefer an alternate path. This is the standard and most effective method for influencing how traffic enters the local AS from multiple providers. A route map with AS_PATH prepending applied outbound to the provider-facing neighbors accomplishes this. This makes option D the correct answer.

Why the other options are incorrect:

A. A route map with WEIGHT attribute to control the inbound traffic – WEIGHT is a Cisco-proprietary attribute that is locally significant and only influences outbound path selection on the local router. It is not advertised to other autonomous systems and therefore cannot influence inbound traffic.

B. An offset list to set the metric for routes received from neighboring autonomous systems – Offset lists modify the MED (Multi-Exit Discriminator) or metric of incoming routes, which affects outbound path selection from the local router. They do not influence how remote autonomous systems select paths toward the local AS.

C. An access list to identify traffic and enable it on both of the provider-facing interfaces – An access list is a traffic-filtering tool and does not influence BGP path selection in any direction. It cannot affect inbound path selection.

Reference:

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