350-401 Practice Questions

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].

Layer 3 roaming occurs when a wireless client moves between Access Points (APs) managed by different Wireless LAN Controllers (WLCs) that reside on different IP subnets. To maintain the client's original IP address and active sessions, the controllers establish a specific relationship. The client's original controller becomes the anchor controller, and the new controller it roams to becomes the foreign controller. The client's database entry on the original WLC is updated to reflect its anchor role, while the new WLC creates a foreign entry for the client. This anchor-foreign relationship facilitates the tunneling of the client's traffic from the foreign controller back to the anchor controller, allowing the client to egress onto its original subnet.

A. An EoIP (or CAPWAP data) tunnel is created between the foreign controller and the anchor controller, not between the client and the anchor controller. The client is unaware of this underlying tunnel.

B. The client entry is not simply "passed." The original controller maintains the client's entry, marking it as an anchor, to continue servicing the client's traffic from its original subnet.

C. Assigning a new IP address from the new subnet would break the client's existing sessions. The primary purpose of Layer 3 roaming is to prevent this by preserving the original IP address.

1. Cisco

Enterprise Mobility 8.5 Design Guide

"Mobility Fundamentals" chapter

"Layer 3 Roaming" section.

"When the client associates to an AP joined to a new controller

the new controller exchanges mobility messages with the original controller

and the client database entry is moved to the new controller. The new controller now sets up the client with a “foreign” role. The original controller is marked as the “anchor” for this client." This directly supports the anchor/foreign entry description in the correct answer.

2. Cisco

Cisco Wireless LAN Controller Configuration Guide

Release 8.10

"Configuring Mobility Groups" chapter

"Information About Inter-Controller Roaming" section.

"In a Layer 3 roam

the client keeps its original IP address. The client's data is tunneled from the foreign WLC to the anchor WLC." This confirms that the goal is to keep the IP address (making option C incorrect) and that the mechanism involves the two distinct controller roles.

3. Cisco

Unified Wireless Network (UWN) Solution Design Guide

"Mobility" chapter

"Inter-Controller Mobility" section.

"The WLC to which the client is currently associated is known as the foreign WLC. The original WLC is known as the anchor WLC... The anchor WLC maintains the original client entry in its client database." This reference explicitly defines the anchor and foreign roles and confirms that the original controller maintains the client entry

invalidating option B.

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).

By default, Cisco Wireless LAN Controllers (WLCs) transmit multicast frames at the highest configured mandatory data rate. In the provided exhibit, the 12 Mbps, 24 Mbps, and 54 Mbps rates are all set to "Mandatory." Consequently, the Access Point is forcing multicast audio streams to be transmitted at 54 Mbps.

Transmission at 54 Mbps utilizes 64-QAM modulation, which requires a high Signal-to-Noise Ratio (SNR) and has a limited effective range. Clients at the edge of the cell or in areas with slight interference will fail to demodulate these unacknowledged multicast frames, leading to audio dropouts. Changing the 24 Mbps and 54 Mbps rates to "Supported" leaves 12 Mbps as the highest mandatory rate. This forces the multicast stream to use 12 Mbps (QPSK), which is significantly more robust and reliable for all clients within the coverage area.

B. Set the RSSI Threshold to -67dBm This setting controls the RSSI Low Check, which disassociates clients with weak signals. Raising the threshold to -67 dBm would aggressively disconnect clients rather than improving the reliability of the multicast stream for connected users.

C. Set the Fragmentation Threshold to 1250 bytes Fragmentation is used to reduce collisions for large frames in noisy environments. Audio packets are typically small RTP/UDP payloads that fall below this threshold, so this change would have no impact on the issue.

D. Disable RSSI Low Check Disabling this check allows clients with even weaker signals to remain associated. Since these clients are already struggling to receive the high-speed 54 Mbps multicast stream, keeping them connected with weaker signals would likely worsen the user experience.

Cisco Systems, Inc. "Cisco Wireless Controller Configuration Guide, Release 8.5 - Configuring Network Data Rates." Cisco.com. Available at: https://www.cisco.com/c/en/us/td/docs/wireless/controller/8-5/config-guide/b_cg85/configuring_network_data_rates.html (Confirming multicast uses the highest mandatory rate).

Cisco Systems, Inc. "Video Over Wi-Fi Design Guide - Multicast on Wireless LANs." Cisco.com. Available at: https://www.cisco.com/c/en/us/td/docs/wireless/technology/video/deploy/guide/videowifi.html (Discussing the relationship between mandatory rates and multicast reliability).

Cisco Systems, Inc. "Troubleshooting Multicast in Wireless Networks." Cisco.com. (Detailing how high mandatory rates cause multicast packet loss due to lack of Layer 2 retries).

Cisco Systems, Inc. "Optimized Roaming and RSSI Low Check." Cisco.com. (Explaining that RSSI thresholds are for client roaming management, not modulation reliability).