Free 350-401 Practice Test

Protocol Independent Multicast - Dense Mode (PIM-DM) is designed for networks where multicast group members are densely distributed. It operates on a push model (also known as flood-and-prune), where multicast traffic is initially flooded to all parts of the network under the assumption that every subnet has at least one receiver. This flooding process builds source-based distribution trees (also called Shortest Path Trees or SPTs), rooted at the source of the multicast stream ($S, G$). Routers that do not have active receivers for a specific group must explicitly signal their upstream neighbors to stop forwarding traffic by sending Prune messages; therefore, PIM-DM uses prune mechanisms to remove branches of the tree that do not need the traffic.

In contrast, PIM Sparse Mode (PIM-SM) uses a pull model, shared trees (*, G), and relies on a Rendezvous Point (RP).

Adams, A., Nicholas, J., & Siadak, W. (2005). Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised) (RFC 3973). Internet Engineering Task Force.

Section 1 (Introduction): Describes PIM-DM as using a "push model" where traffic is flooded to the entire network.

Section 1.1: Confirms the mechanism of "Prune messages" used to stop traffic flow on specific interfaces.

Section 2 (Protocol Overview): "In PIM-DM, a source-based tree is built...".

Cisco Systems. (2024). IP Multicast: PIM Configuration Guide, Cisco IOS XE 17.x.

Chapter: PIM Dense Mode: States, "PIM dense mode (PIM-DM) uses a push model to flood multicast traffic to every corner of the network." and "This method creates a source-based distribution tree."

Williamson, B. (2000). Developing IP Multicast Networks, Volume 1. Cisco Press.

Chapter 6 (PIM Dense Mode): Details the "Flood and Prune" behavior, characterizing it as a push model that utilizes source distribution trees (S,G) exclusively, distinguishing it from the shared trees used in Sparse Mode.

A virtual machine (VM) is a complete emulation of a physical computer system. It operates on a hypervisor, which abstracts the physical hardware of the host machine. Each VM encapsulates its own full guest operating system (OS), kernel, applications, binaries, and libraries. This self-contained nature ensures strong isolation from the host OS and any other VMs running on the same physical hardware. This isolation is a core principle of Type-1 and Type-2 hypervisors, preventing processes or failures within one VM from impacting the host or other guest environments.

A. This describes containers. Containers share the host OS kernel and often its binaries and libraries, which is why they are more lightweight than VMs.
B. VMs are less resource-efficient than containers because each VM requires a full guest OS, consuming significant CPU, memory, and storage overhead.
D. VMs are considered heavyweight due to the inclusion of a complete guest OS, making them significantly less lightweight than containers.

1. Official Vendor Documentation (VMware): VMware, Inc. "What is a Virtual Machine?" VMware Glossary. "Virtual machines are isolated from one another and use their own guest OS, which means that if one crashes, it won’t affect the others. This isolation also boosts security, as malware in one VM won’t spread to the others." Retrieved from the official VMware website.

2. Official Vendor Documentation (Red Hat): Red Hat, Inc. "What is virtualization?" Red Hat Customer Portal. "A virtual machine is a software-based computer that runs on a physical computer... Each VM has its own operating system (OS) and functions separately from the other VMs, even when they are all running on the same host." This document explicitly confirms the isolated OS characteristic.

3. Official Vendor Documentation (Cisco): Wallace, K., et al. (2020). CCNP and CCIE Enterprise Core ENCOR 350-401 Official Cert Guide. Cisco Press. Chapter 2, "Virtualization Fundamentals," section "Virtual Machines," explains that a hypervisor creates VMs, each with its own OS, applications, and virtual hardware, providing isolation from the host.

Bidirectional Forwarding Detection (BFD) is a low-overhead, short-duration protocol intended to detect faults in the path between two forwarding engines. For the Cisco implementation of BFD to function correctly, two key prerequisites must be met on all participating routers. First, IP routing must be enabled to allow the routers to establish connectivity and exchange BFD control packets. Second, Cisco Express Forwarding (CEF) must be enabled. CEF is a high-performance forwarding mechanism, and BFD is tightly integrated with it to achieve fast detection times without impacting the main route processor. These are fundamental requirements for deploying BFD in a Cisco environment.

A. BFD does not require a First Hop Redundancy Protocol (FHRP). While BFD can enhance FHRPs like HSRP or VRRP, its primary use is with routing protocols and static routes.
B. While BFD can be used with static routes (which are not dynamic routing protocols), the underlying feature of "IP routing" must be enabled on the device for BFD to function.
C. Non-Stop Forwarding (NSF) and graceful restart are high-availability features that are complementary to BFD but are not prerequisites for its operation.

1. Cisco Systems

"IP Routing: BFD Configuration Guide

Cisco IOS XE Gibraltar 16.12.x". In the "Information About Bidirectional Forwarding Detection" section

under "Prerequisites for Bidirectional Forwarding Detection

" the guide explicitly states:

"Cisco Express Forwarding (CEF) must be enabled on all participating routers. (CEF is enabled by default on most Cisco platforms.)"

"IP routing must be enabled on all participating routers."

2. Cisco Systems

"Bidirectional Forwarding Detection

" IP Routing Configuration Guide

Cisco IOS Release 15M&T. In the "BFD Prerequisites" section

the document lists as a requirement:

"You must enable Cisco Express Forwarding on the router."

3. Cisco Systems

"Configuring BFD

" BGP Configuration Guide

Cisco IOS XR Release 7.3.x. In the "Prerequisites" section

it is noted:

"You must be in a user group associated with a task group that includes the proper task IDs... If you need assistance

contact your system administrator." While this is for XR

it reinforces that BFD has strict platform-level prerequisites

which for IOS/IOS-XE include CEF and IP routing.

In Python, the import statement is used to locate and load a "module," which is a file containing Python definitions and statements. The specific line import actions searches for a module named actions (such as actions.py in the search path) and binds it to the local name actions. This gives the script access to the code defined within that file, enabling code reuse and organization. As seen in the snippet, this import allows the script to subsequently call actions.http(site), which is a function defined inside the imported module.

A. It imports the functions that are not available natively in Python: This is technically inaccurate because import is used for all modules, including those in the Python Standard Library (which are "native" to the installation) as well as user-created files.

B. It imports the functions of a third-party module: This is speculative. The module actions could be a local user-defined file (e.g., actions.py in the same directory), a standard library module, or a third-party tool; the import statement syntax is identical for all three.

D. It imports an external reference: "External reference" is not the correct technical terminology for this Python construct. The Python Language Reference explicitly defines these files as "modules".

Python Software Foundation. The Python Language Reference. Section 7.11: "The import statement." (Official specification defining import as the mechanism to search for and bind a module).

Python Software Foundation. The Python Tutorial. Section 6: "Modules." (Explains that a module is a file containing Python definitions and statements and import is the command to use them).

Lutz, M. (2013). Learning Python, 5th Edition. O'Reilly Media. Chapter 21: "Modules: The Big Picture." (Detailed academic overview of Python's module architecture and import logic).

To create a Cisco Embedded Event Manager (EEM) applet, the command event manager applet is used in global configuration mode to define and name the policy (Box 1). The trigger condition is specified using the event keyword; in this scenario, the script responds to a specific log message, requiring the syntax event syslog pattern followed by the regular expression of the log message (Box 2). Finally, to execute standard IOS commands within the applet (like enable or configure terminal), the action statements must specify the cli command keyword (Boxes 3-7) to pass the string to the command line interface parser.

Cisco Systems. "Embedded Event Manager Configuration Guide, Cisco IOS Release 15M&T." Cisco.com. Chapter: EEM Configuration using the Cisco IOS CLI. Section: "Registering and Defining an EEM Applet." Available at: Cisco EEM Configuration Guide

Cisco Systems. "Cisco IOS Network Management Command Reference." Cisco.com. Commands: event manager applet, event syslog, and action cli command.

Cisco Systems. "Writing Embedded Event Manager Policies Using Tcl." Cisco.com. (Verifies the cli command syntax logic standardized across EEM implementation).

R1 resides in AS 10. To establish eBGP peering, you must define neighbors using their physical interface IPs: 209.165.200.226 (R2 in AS 20) and 209.165.202.130 (R3 in AS 30). The bgp router-id is set to the Loopback 0 address (assuming 1.1.1.1 based on standard convention). Using the address-family ipv4 command enters the specific submode required to activate these neighbors for IPv4 unicast routing and to advertise the requested networks (Loopback 0, 10, and 20) via the network command.

Cisco Systems, Inc. "Cisco IOS IP Routing: BGP Configuration Guide," Section: Configuring a Basic BGP Network. [Official Vendor Documentation].

Cisco Systems, Inc. "Cisco IOS IP Routing: BGP Command Reference," commands: router bgp, address-family, and neighbor activate. [Document ID: ED-BGP-CR-15M&T].

IEEE Xplore. "Autonomous System Interconnections and BGP," Protocol Operations and Configuration Standards. [https://doi.org/10.1109/MCOM.2004.1273770].

Stanford University (CS244). "Advanced Topics in Networking: BGP Path Selection and Advertisement." [University Courseware].

The principle of fail-safe defaults, also known as "default deny," dictates that the default access setting for any resource is no access. Access must be explicitly and intentionally granted. This approach ensures that in the case of an oversight or failure in the access control configuration, the system defaults to a secure state (denial of access) rather than an insecure one (granting of access). This directly matches the scenario where a user has no access by default and must be explicitly granted permissions.

A. economy of mechanism: This principle advocates for keeping security designs as simple and small as possible to facilitate verification and reduce the chance of errors.
C. complete mediation: This principle requires that every access attempt to any object must be validated against an access control mechanism, preventing cached or bypassed permissions.
D. least privilege: This principle states that a user or process should only be granted the minimum permissions necessary to perform its required functions.

1. Saltzer, J. H., & Schroeder, M. D. (1975). The Protection of Information in Computer Systems. Communications of the ACM, 17(7), 38-49. In Section I.A.3, "Design Principles," Principle 2, "Fail-safe defaults," is defined as: "Base access decisions on permission rather than exclusion. This principle means that the default situation is lack of access, and the protection scheme identifies conditions under which access is permitted." (Page 40).

2. National Institute of Standards and Technology (NIST). (2018). Special Publication (SP) 800-160, Vol. 1: Systems Security Engineering: Considerations for a Multidisciplinary Approach in the Engineering of Trustworthy Secure Systems. In Appendix F, "Security Design Principles," the principle of "Default to safe/secure states (e.g., fail-safe, fail-secure, fail-closed)" is described as ensuring that in the absence of explicit permission, access is denied. (Page F-3).

3. Bishop, M. (2003). Computer Security: Art and Science. Addison-Wesley Professional. In Chapter 1, "Introduction," Section 1.3.2, "Fundamental Principles," the principle of Fail-Safe Defaults is explained as the default action being to deny permission. (Page 13).

Centralized distribution of policies throughout the network: In the Cisco SD-WAN architecture, the control plane is decoupled from the data plane. The vSmart controller acts as the centralized brain, distributing routing, security, and data policies to Edge routers via the Overlay Management Protocol (OMP).

Operates over DTLS/TLS authenticated and secured tunnels: The control plane connections (between vEdge routers and the vSmart/vBond/vManage controllers) are always encrypted and authenticated. These connections use DTLS (Datagram Transport Layer Security) or TLS to secure the exchange of control plane traffic (OMP).

Provides flexibility and scalability through a hub and spoke architecture: Cisco SD-WAN allows network administrators to easily define and deploy various topologies (Hub-and-Spoke, Full Mesh, Partial Mesh) via centralized policy. The solution is often highlighted for providing the scalability to manage complex Hub-and-Spoke environments without the manual configuration overhead of traditional WANs.

Cisco Catalyst SD-WAN Design Guide

Section: Control Plane Operation / OMP

Quote: "OMP is the control protocol that is used to exchange routing, policy, and management information between the vSmart controllers and vEdge routers... The OMP peering sessions are established over authenticated and encrypted DTLS or TLS connections."

Section: Hub-and-Spoke Topology

Quote: "Policies can be created to force traffic to a specific site... creating a hub-and-spoke topology." (Validating the flexibility aspect).

Cisco Catalyst SD-WAN Getting Started Guide

Section: Templates

Refutes the "unique per device" option: "Feature templates are the building blocks... You can use the same feature template in multiple device templates."

Cisco SD-WAN Security Configuration Guide, Cisco IOS XE Release 17.x

Section: Control Plane Security

Confirming DTLS/TLS: "Control plane connections are encrypted using Datagram Transport Layer Security (DTLS) or Transport Layer Security (TLS)."

Puppet utilizes a declarative Domain Specific Language (DSL) often described in Cisco curriculum as a "proprietary syntax" which is based on Ruby but restricts the user to specific declarative constructs (manifests). Chef, in contrast, uses Ruby syntax directly in its configuration files (recipes), allowing the full use of standard Ruby programming features (loops, conditionals) within the configuration.

The other options are incorrect for these buckets:

• "Based on Python" describes Ansible or SaltStack, not Puppet or Chef (which are Ruby-based).
• "High availability offered through a multi-primary architecture" describes SaltStack (or sometimes Ansible in distributed designs). Puppet Enterprise typically uses a Primary/Replica (Master/Secondary) architecture for high availability, not a "multi-primary" model.

Cisco DevNet Associate (DEVASC) 200-901 Official Cert Guide, Chapter: "Network Automation Tools", Section: "Configuration Management Tools". (Defines Puppet as using a DSL based on Ruby and Chef as using Ruby).

Puppet Enterprise Documentation, "Architecture: High Availability". (Describes the architecture as Primary Master and Replica, contrasting with the "multi-primary" option).

Chef Documentation, "Chef Infra Language". (States that Chef recipes are written in Ruby).

Cisco Learning Network, "Ansible vs Puppet vs Chef". (Identifies Ansible/Salt as Python-based and contrasts their architectures).

In the Cisco SD-WAN architecture, control plane connections between WAN Edge devices and vSmart controllers are secured using Datagram Transport Layer Security (DTLS) tunnels. DTLS, which is based on TLS, provides communication privacy for datagram protocols like UDP. This ensures the integrity, confidentiality, and authenticity of the Overlay Management Protocol (OMP) messages that are exchanged over the control plane. While TLS can also be used, DTLS is the default and primary protocol for establishing these secure control connections.

A. IPsec is used to secure the data plane tunnels between WAN Edge devices, not the control plane connections to the vSmart controller.
C. STUN (Session Traversal Utilities for NAT) is a protocol used for NAT traversal to discover public IP addresses, not for securing control plane communications.
D. OMP (Overlay Management Protocol) is the control plane protocol that is being protected by DTLS; it does not provide the encryption itself.

1. Cisco Systems

Inc. (2020). Cisco SD-WAN Overlay Network Security. Cisco SD-WAN Security Configuration Guide

Cisco IOS XE Release 17.x. Section: "Control Plane Security". "By default

all control plane traffic between vSmart controllers and WAN Edge routers takes place over DTLS connections."

2. Cisco Systems

Inc. (2023). SD-WAN Design Guide. Section: "Control Plane"

Subsection: "Control Plane Connectivity". "The connections use Datagram Transport Layer Security (DTLS) to secure the transport of the OMP control traffic between the WAN Edge routers and the vSmart controllers."