Cisco Designing and Implementing Cisco Service Provider Cloud Network Infrastructure v1.0 300-540 SPCNI Exam Questions

Answer : A

Comprehensive and Detailed Explanation

BGP Flowspec allows routers to distribute traffic-filtering rules using BGP NLRI.

To enable Flowspec, after neighbors are configured, the essential next step is:

Activate the Flowspec address-family under BGP

Example:

router bgp 65000

address-family ipv4 flowspec

neighbor X.X.X.X activate

exit-address-family

This enables:

FlowSpec NLRI exchange

Distribution of drop rules (rate-limit, redirect, null route, etc.)

Automatic ACL/class-map/policy-map generation on edge routers

Why the other options are incorrect:

B . Set BGP routing process already done when neighbors were configured

C . Activate neighbors only makes sense inside an address-family; flowspec AF must be enabled first

D . Configure route reflector optional and not required for Flowspec to operate

Thus, the correct next step is A. Configure Flowspec for the BGP address-family.

Answer :

R1 (AS 200) is multihomed to:

SP-1 in AS 300 via neighbor 172.16.1.1

SP-2 in AS 400 via neighbor 172.16.2.1

R1 must:

Advertise only locally originated prefixes (its own network 10.10.0.0/24).

NOT become a transit AS---i.e., R1 must not advertise routes learned from one provider to the other.

The configuration includes AS-path access-lists:

ip as-path access-list 1 permit ^$

ip as-path access-list 200 permit ^200

ip as-path access-list 300 permit ^300

ip as-path access-list 400 permit ^400

^$ in AS-path ACL 1 matches locally originated routes (empty AS-path).

ACLs 200, 300, and 400 match routes whose first AS in the path is 200, 300, or 400 respectively (used if we needed to match those provider or customer routes).

To ensure each upstream provider only receives locally originated routes, we apply AS-path ACL 1 as an outbound filter-list on each external BGP neighbor:

router bgp 200

neighbor 172.16.1.1 remote-as 300

neighbor 172.16.1.1 filter-list 1 out only advertise local prefixes to SP-1

neighbor 172.16.2.1 remote-as 400

neighbor 172.16.2.1 filter-list 1 out only advertise local prefixes to SP-2

This way:

Routes learned from SP-1 (AS 300) will not be advertised to SP-2 (AS 400) because their AS-path will begin with 300, not empty, so they fail ACL 1.

Similarly, routes from SP-2 will not be sent to SP-1.

Only R1's own prefixes are exported, preventing AS 200 from becoming a transit network.

Answer : C

Comprehensive and Detailed Explanation

In Cisco NFVI security architecture, the primary defense against lateral movement (an attacker moving from one compromised node to another) is network segmentation.

Segmentation:

Separates workloads (compute, storage, management, tenant networks)

Prevents attackers from pivoting inside the NFVI

Reduces blast radius during breaches

Enforces micro-segmented virtual network boundaries

WPA protects Wi-Fi, not NFVI.

WAF protects web apps, not internal movement.

Data encryption protects confidentiality, not lateral movement control.

Thus, network segmentation is the correct solution.

Answer :

In Cisco NFVI, the management node relies heavily on Docker containers for:

NFVIS management functions

VIM services

Orchestration components

If the management node fails to start and the system shows:

docker.service: inactive (dead)

...then all Docker-based platform services also fail to start.

The correct recovery action is to restart the Docker engine:

systemctl restart docker

This brings up:

All NFVI-required Docker containers

Management services

REST APIs and cluster components

Why other answers are incorrect:

docker-kibana Only affects Kibana logging container

docker-cobbler Used for provisioning, not core NFVI management

kube-apiserver Part of Kubernetes cluster, but relies on Docker; restarting it won't help until Docker is running

Thus, the correct answer is B. docker.

Answer : C

Comprehensive and Detailed Explanation

Cloud interconnects that support BGP peering must provide a routed Layer-3 adjacency capable of exchanging routing information dynamically. In major cloud architectures:

AWS Direct Connect supports private virtual interfaces (VIFs) where BGP is used between the customer router and AWS to exchange routes.

Azure S2S VPN uses IPsec tunnels with static routing by default; BGP is optional only with specific gateway SKUs, but the question expects the standard, universally correct answer, which is Direct Connect.

Azure Bastion is a remote-access management service and does not support BGP.

AWS-managed VPN uses IPsec tunnels with BGP optional, but in exams, the recognized cloud service specifically associated with BGP support is Direct Connect.

In service provider cloud interconnect design, AWS Direct Connect is the standard, well-defined offering that provides layerized WAN connectivity with BGP support.

Answer :

In a VXLAN BGP EVPN fabric, each VTEP (NVE interface) must use BGP EVPN as the host-reachability protocol so that MAC/IP information and VTEP reachability are exchanged through the control plane.

From the exhibit:

LEAF-SW-1 -- interface nve1

source-interface loopback0

No host-reachability protocol bgp

Host Learning Mode: Data-Plane in show nve interface

LEAF-SW-2 -- interface nve1

source-interface loopback0

host-reachability protocol bgp configured

This mismatch causes one VTEP to rely on data-plane flood-and-learn, while the other uses EVPN BGP control-plane learning, leading to inconsistent and ''corrupted'' MAC/IP and ARP/ND information between the leaf switches.

The fix is to configure LEAF-SW-1 to also use BGP for host reachability:

interface nve1

host-reachability protocol bgp

Options B and D are incorrect because anycast VTEP designs intentionally share the same primary loopback IP while using different secondary IPs and unique BGP router IDs. Option A (removing suppress-arp) does not correct the control-plane mismatch.

Therefore, enabling host-reachability protocol bgp on LEAF-SW-1 (Option C) resolves the issue.

Answer :

For a site-to-site IPsec VPN, each peer must configure a pre-shared key tied to the public IP address of the remote VPN peer:

crypto isakmp key <KEY> address <REMOTE_PUBLIC_IP>

From the diagram:

R1 outside IP: 192.168.10.1/24

R2 outside IP: 192.168.20.2/24 remote peer for R1

In the current R1 configuration, the ISAKMP key is incorrectly bound to 192.168.10.2, which is a local next-hop/ISP address on R1's own subnet, not the R2 public IP. Because the pre-shared-key address does not match the source IP of R2's IKE packets, phase 1 negotiation fails and the tunnel never comes up.

The correct configuration on R1 must therefore be:

crypto isakmp key vpnuser address 192.168.20.2

Options A and C incorrectly change the default route (next hop must be the local ISP router, not R2's public IP or a LAN address). Option D uses an internal address (10.1.1.2), which is not the IP used for IKE on the Internet.