Free 300-410 Practice Test Questions and Answers (2026) | Cert Empire Practice Questions

To meet the requirements on router R-WEST, two distinct services must be configured.

1. Logging: To satisfy the first requirement, the service sequence-numbers command is used to prepend a sequence number to each locally generated log message. The service timestamps log datetime command is used to add the date and time to these log messages, fulfilling the requirement for a timestamp.
2. SNMP Traps: To satisfy the second requirement, the snmp-server enable traps ospf command is executed. This command specifically enables the generation of OSPF-related traps as defined in the standard RFC 1253 MIB. This includes traps for OSPF events and for state changes of OSPF-participating interfaces (e.g., ospfIfStateChange).

Cisco Systems. (2023). Cisco IOS XE Software-Defined WAN and Services Configuration Guide, Release 17.x - Configuring Logging Services.

Section: service sequence-numbers Command. States: "To specify that sequence numbers be affixed to log messages, use the service sequence-numbers command..."

Section: service timestamps Command. States: "To configure the time-stamping of logging and debugging messages, use the service timestamps command... log datetime... Specifies that the date and time be affixed to logging messages."

Cisco Systems. (2023). Cisco IOS XE Network Management Command Reference - snmp-server community to snmp-server view.

Section: snmp-server enable traps Command. Documents the ospf keyword: "Enables OSPF traps defined in RFC 1253."

Moy, J. (1991). RFC 1253: OSPF Version 2 Management Information Base. Internet Engineering Task Force (IETF).

Section: 7. Traps. Defines the OSPF-specific traps, including ospfIfStateChange, which directly relates to the requirement for "participating interface state changes".

DOI: https://doi.org/10.17487/RFC1253

In MPLS architecture:

• LSR (Label Switching Router): Operates in the core of the network (often called a P router in provider contexts), switching packets solely based on labels.
• FEC (Forwarding Equivalence Class): Describes a group of packets forwarded in the same manner (same path, same forwarding treatment).
• LER (Label Edge Router): Operates at the edge of the MPLS network (often called a PE router), handling the ingress (pushing labels) and egress (popping labels) of traffic from customer routers (CE).
• LDP (Label Distribution Protocol): A signaling protocol used to exchange label mapping information between MPLS peers to build the forwarding database.
• LSP (Label Switched Path): The sequence of LSRs a labeled packet traverses through the network.

RFC 3031 - Multiprotocol Label Switching Architecture, Section 3.1 "MPLS System Components".

Defines LSRs, LERs (Edge LSRs), FECs, and LSPs.

Available at: https://doi.org/10.17487/RFC3031

RFC 5036 - LDP Specification, Section 1 "Overview".

Defines LDP as the protocol for distributing label binding information.

Available at: https://doi.org/10.17487/RFC5036

Cisco Systems, "MPLS Fundamentals," Configuration Guide.

Confirms the terminology mapping where Provider (P) routers act as core LSRs and Provider Edge (PE) routers act as LERs connecting to customers.

Data Plane: Consists of user traffic (like web browsing or file transfers) traversing the router to reach another destination. These are "always forwarded" and typically handled in hardware (ASICs).

Control Plane: Includes protocols (OSPF, BGP, STP, ARP) that build the network topology. These packets are "used for the creation of the network itself" so the data plane can function.

Management Plane: Includes protocols (SSH, Telnet, SNMP, NTP) used to "operate" and monitor the devices. Unlike control traffic, these don't build the route table but facilitate administrative access.

1. Services Plane: A subset of the data plane in some NFP models, often referring to specialized customer traffic (like VoIP or high-value data streams) that "requires higher priority" or specific processing (QoS, NAT, Encryption) compared to normal bulk data.

Cisco Systems, Cisco Network Foundation Protection (NFP) Framework.

Whitepaper: "Control Plane Policing Implementation Guide".

Definition: "The Management Plane... is used to manage the network elements... The Control Plane... is used to set up and maintain the network topology."

Cisco Networking Academy, CCNP Enterprise: Core Networking (ENCOR) v8.0.

Chapter: Network Architecture / Security.

Context: Defines the four planes: Data, Control, Management, and Services, specifically noting the Services plane handles specialized forwarding requirements.

Cisco Press, CCIE Routing and Switching v5.0 Official Cert Guide, Vol 1.

Section: "Foundation of Network Security".

Quote: Distinguishes traffic destined for the router (Control/Mgmt) versus traffic through the router (Data/Services).

The Desired Min TX Interval is the BFD parameter that specifies the minimum interval, in microseconds, that the local system would like to use when transmitting BFD Control packets. This value directly represents the minimum time gap the system wants to maintain before putting the next control packet on the wire. The actual transmission interval is negotiated between BFD peers and will be the greater of the local system's Desired Min TX Interval and the remote system's Required Min RX Interval.

A. Detect Mult: This is a multiplier used with the negotiated transmission interval to calculate the BFD detection timer, not the packet sending rate.

B. Required Min Echo RX Interval: This parameter is specific to the BFD Echo function and defines the minimum interval for receiving Echo packets, not sending control packets.

D. Required Min RX Interval: This is the minimum interval at which the local system is capable of receiving BFD packets, a value it advertises to its peer.

---

1. IETF RFC 5880

"Bidirectional Forwarding Detection (BFD)":

Section 4.1

"State Variables": Defines bfd.DesiredMinTxInterval as "The desired minimum interval between transmission of BFD Control packets that this system would like to use..."

Section 6.8.7

"Timer Values": Explains the fields in the BFD Control packet. It states

"Desired Min TX Interval: The desired minimum transmit interval

in microseconds

that the local system wishes to use when sending BFD Control packets..."

2. Cisco IOS XE IP Routing: BFD Configuration Guide:

"BFD Timers" section: Describes the bfd interval command syntax: bfd interval milliseconds minrx milliseconds multiplier number. The first milliseconds value is explicitly defined as the "Desired minimum transmit interval." This parameter controls how often the local system sends BFD hello packets to its neighbor.

IPv6 Source Guard is a security feature that filters traffic based on the source IPv6 address and, optionally, the source MAC address. It leverages the binding table, which is populated by the IPv6 Snooping feature, to validate incoming packets. When IPv6 Source Guard is enabled on an interface, the switch examines traffic from hosts connected to that interface. If the source address of an incoming packet does not match a valid entry in the binding table for that specific port, the packet is dropped. This effectively prevents IP address spoofing attacks from devices on that segment.

A. IPv6 Snooping: This feature builds and maintains the binding table by observing Neighbor Discovery Protocol messages, but it does not, by itself, perform the traffic filtering or rejection.

C. IPv6 DAD Proxy: The Duplicate Address Detection (DAD) Proxy feature responds to DAD queries on behalf of hosts, which helps in scaling ND-P in large L2 domains. It is not a traffic filtering mechanism.

D. IPv6 RA Guard: This feature specifically filters and drops unauthorized Router Advertisement (RA) messages from rogue devices. It does not filter general data traffic based on the source address.

1. Cisco Systems

Inc. (2023). First-Hop Security Configuration Guide

Cisco IOS XE Bengaluru 17.6.x (Catalyst 9300 Switches). Chapter: "Configuring IPv6 First-Hop Security"

Section: "IPv6 Source Guard".

The document states

"IPv6 source guard is a security feature that filters traffic based on the IPv6 source address and the source MAC address... It uses the binding table populated by IPv6 snooping to validate the source of the incoming packets. When IPv6 source guard is enabled on an interface

the device drops packets when the source address is not found in the binding table."

2. Cisco Systems

Inc. (2021). IP Addressing: IPv6 Configuration Guide

Cisco IOS XE 17. Chapter: "Implementing IPv6 First-Hop Security"

Section: "IPv6 Source Guard".

This guide explains

"The IPv6 Source Guard feature filters traffic based on the IPv6 source address of the traffic. The feature uses the binding table

which is populated by the IPv6 snooping feature

to validate the source of the incoming packets."

3. Haddad

W.

& Bshara

M. (2018). IPv6 Security. Cisco Press. Chapter 4: "Layer 2 Security".

This official Cisco Press publication details that IPv6 Source Guard is the feature responsible for using the binding table to perform source IP address filtering

thereby preventing spoofing attacks. It explicitly differentiates its role from IPv6 Snooping

which builds the table

and RA Guard

which protects against rogue routers.

In a hub-and-spoke DMVPN topology using EIGRP, the hub router learns routes from all spokes via a single multipoint GRE (mGRE) tunnel interface. By default, EIGRP's split-horizon rule prevents the hub from advertising a route back out of the same interface on which it was learned. This means the hub will not advertise routes learned from Spoke 1 to Spoke 2, and vice-versa. To enable spoke-to-spoke communication, spokes must learn the routes to each other's networks. Disabling EIGRP split-horizon on the hub's tunnel interface allows the hub to reflect these routes, enabling spokes to establish direct tunnels.

A. no ip eigrp 1 mode multipoint: This is not a valid EIGRP configuration command. It appears to be a distractor combining EIGRP syntax with a generic interface mode concept.

C. no ip eigrp 1 tunnel-redirect: This is not a valid EIGRP command. It is likely a distractor referencing the NHRP redirect mechanism (ip nhrp redirect), which is separate from EIGRP routing advertisements.

D. no ip eigrp 1 mode mgre: This is not a valid EIGRP configuration command. It incorrectly merges EIGRP syntax with the mGRE interface type.

1. Cisco Systems

Inc. (2019). IP Routing: EIGRP Configuration Guide

Cisco IOS XE Gibraltar 16.12.x.

Section: "Configuring EIGRP

" Sub-section "Disabling or Enabling Split Horizon."

Content: This document details the no ip split-horizon eigrp command. It explains that split horizon is enabled by default on most interfaces and that disabling it may be necessary on a hub router in a hub-and-spoke network to allow the hub to advertise information learned from one spoke to other spokes.

2. Cisco Systems

Inc. (2021). Dynamic Multipoint VPN Configuration Guide

Cisco IOS XE 17.

Section: "Configuring DMVPN

" Sub-section "DMVPN Phase 2: Hub-and-Spoke with Spoke-to-Spoke Tunnels."

Content: The guide explicitly states: "For certain routing protocols like EIGRP

you must disable split horizon on the hub to allow the hub to forward routing updates from one spoke to another." This directly supports the need to disable split-horizon for the described scenario.

3. Martin

R.

& Tafa

S. (2020). CCNP Enterprise Advanced Routing ENARSI 300-410 Official Cert Guide. Cisco Press.

Chapter 6: "Dynamic Multipoint VPN

" Section "DMVPN Phase 2."

Content: The text explains that for EIGRP to support spoke-to-spoke communication in DMVPN Phase 2

split-horizon must be disabled on the hub's mGRE interface. It provides the specific command no ip split-horizon eigrp and explains its function in this context.

The solution addresses the tasks as follows:

1. Task 1 & 2 (Path Engineering): Task 1 (redundancy) is achieved via the (assumed) pre-configured mutual redistribution on R3 and R4. Task 2 (path selection) requires two actions:

• The metric weights command must be applied to all routers in EIGRP AS 10 (R3, R4, R5, R6) to ensure they can form adjacencies, as the K-values must match.
• To force the path R1->R3->R5->R6, the alternative path (R3->R4->R6) must be made less desirable. By increasing the delay on the e0/1 interfaces of R4 and R6, the EIGRP metric for that link becomes significantly higher (due to K3=255), forcing traffic over the R5 path.

1. Task 3 (Policy-Based Routing):

• Access-lists (R6_SOURCE_TRAFFIC, R2_SOURCE_TRAFFIC) are created on R3 to identify the specific source traffic.
• The pre-configured route-maps INTERNET1 and INTERNET2 are modified to use these ACLs and set the appropriate next-hop IP address for SP1 (209.165.200.229) and SP2 (209.165.200.237), respectively.

Cisco Systems, (2023). IP Routing: EIGRP Configuration Guide, Cisco IOS XE 17.

Section: "EIGRP Metrics" and "Configuring EIGRP Metric Weights". (Explains the metric weights command and the K-values [TOS] K1 K2 K3 K4 K5 syntax).

Section: "Configuring Interface Parameters". (Details the use of the delay command on an interface to influence EIGRP routing metrics, specified in tens of microseconds).

Cisco Systems, (2024). IP Switching: Cisco Express Forwarding Configuration Guide, Cisco IOS XE 17.

Section: "Configuring Policy-Based Routing". (Documents the standard procedure for PBR: creating an access-list to match traffic, configuring a route-map to match the ACL and set the next-hop, and applying the policy to an interface).

Cisco Systems, (2023). IP Routing: Protocol-Independent Configuration Guide, Cisco IOS XE 17.

Section: "Configuring Route-Maps". (Provides the syntax for creating and modifying route-map statements, including match ip address and set ip next-hop clauses).

The OSPF neighbor states follow a strict progression:

1. Down: No Hello packets have been received.
2. Init: A Hello packet is received, but the receiver's Router ID is not listed (uni-directional).
3. 2-Way: The router sees its own ID in the neighbor's Hello (bi-directional). On multi-access networks, neighbor relationships are established with all routers here, but adjacencies usually only proceed with the Designated Router (DR).
4. ExStart: Occurs after the DR/BDR election (which happens in 2-Way). Routers negotiate Master/Slave roles.
5. Exchange: Routers swap Database Description (DBD) packets to compare Link State Databases (LSDB).
6. Loading: Routers send Link State Requests (LSR) for any missing or outdated entries identified during the Exchange state.

Cisco Systems, OSPF Neighbor States Explained, Document ID: 13685.

Section: "ExStart State" and "Exchange State".

Quote: "In the ExStart state... The DR and BDR are elected in the 2-Way state." / "In the Exchange state, OSPF routers exchange database descriptor (DBD) packets."

IETF, RFC 2328: OSPF Version 2.

Section: 10.1. Neighbor States.

Definition: "Loading: ...Link State Requests are sent to the neighbor asking for the more recent LSAs."

Cisco Networking Academy, CCNP Enterprise: Core Networking (ENCOR) v8.0, Chapter 7: OSPF.

Micro BFD, also known as BFD over Link Aggregation Group (LAG) member links, is designed to overcome the limitations of running a single BFD session over an entire LAG interface. The primary goal is to provide rapid failure detection and verify data plane continuity for each individual member link within the bundle. This is achieved by establishing a separate and independent BFD session on every physical member link. If a micro BFD session detects a failure on a specific link, that link is immediately removed from the LAG's forwarding table, preventing traffic from being black-holed, while the remaining healthy links continue to forward traffic.

A. Micro BFD is not selective; its purpose is to monitor all member links, irrespective of their bandwidth, to ensure complete bundle integrity.

B. While aggressive timers are a feature of BFD, a specific value like "3x3 ms" is a configuration detail, not a fundamental goal of the protocol.

D. Monitoring just "any" member link is insufficient; the goal is to monitor all links comprehensively to prevent any single point of failure within the bundle.

1. Cisco Systems

Inc.

IP Routing: BFD Configuration Guide

Cisco IOS XE Cupertino 17.9.x

"BFD over Link Aggregation Group (LAG) Interfaces" section. The guide states

"The BFD over LAG feature allows BFD sessions to monitor individual member links in a LAG. This is also known as micro BFD... A separate BFD session is created for each member link". This supports that each link must run BFD (E) to monitor individual links (C).

2. Cisco Systems

Inc.

Cisco Nexus 9000 Series NX-OS Unicast Routing Configuration Guide

Release 10.3(x)

"Configuring BFD" chapter

"BFD for Link Aggregation (LAG)" section. This document specifies

"BFD for LAG provides fast failure detection on a per-member link basis. A separate BFD session runs on each member of a port channel." This directly validates verifying continuity for each link (C) and running BFD on each member (E).

In an MPLS network, the roles are strictly defined:

• P (Provider) routers are core routers (Label Switching Routers - LSRs) that forward traffic purely by swapping labels, without consulting the IP routing table.
• LSP (Label Switched Path) is the unidirectional path defined by the label sequence that packets traverse from ingress to egress.
• CE (Customer Edge) routers are standard IP routers located at the customer site. They send standard IP packets to the provider and are typically unaware of the MPLS labels used within the provider's core.
• PE (Provider Edge) routers (Label Edge Routers - LERs) function as gateways. They perform "imposition" (adding labels) to ingress traffic and "disposition" (removing labels) from egress traffic before handing it off to the CE.

IETF, RFC 3031: Multiprotocol Label Switching Architecture.

Section 3.1: Defines the Label Switching Router (LSR/P) and Label Edge Router (LER/PE).

Section 2: Defines the Label Switched Path (LSP).

IETF, RFC 4364: BGP/MPLS IP Virtual Private Networks (VPNs).

Section 1.2 & 2: Specifically defines P, PE, and CE devices.

Quote: "The CE devices are not required to support MPLS." / "The PE routers... forward packets based on the MPLS label."

Cisco Systems, MPLS Fundamentals.

Documentation: "MPLS Terminology and Definitions." Explains the P router's role in label swapping vs. the PE router's role in label imposition/disposition.

IPv6 Neighbor Discovery (ND) inspection is a Layer 2 security feature designed to mitigate man-in-the-middle attacks that exploit the Neighbor Discovery Protocol. It operates on a switch by intercepting and validating ND messages (e.g., Neighbor Solicitations and Advertisements). The feature builds a trusted binding table, which is a Layer 2 table that maps a device's IPv6 address to its MAC address and the switch port it is connected to. This mechanism is essential for securing environments that use Stateless Address Autoconfiguration (SLAAC), where clients generate their own addresses without a central authoritative server like DHCPv6.

A. ND inspection is a Layer 2 security feature that builds its binding table on the switch, not a Layer 3 routing or neighbor table.

C. ND inspection is designed for stateless (SLAAC) address autoconfiguration. Stateful address assignment is secured by the DHCPv6 snooping feature.

D. While ND inspection is a Layer 2 feature, its primary purpose is to secure stateless (SLAAC) autoconfiguration, not stateful autoconfiguration.

1. Cisco Systems

Inc. (2023). IPv6 First-Hop Security Configuration Guide

Cisco IOS XE Cupertino 17.9.x.

Section: "Information About IPv6 First-Hop Security" > "IPv6 Neighbor Discovery Inspection"

Quote: "The IPv6 ND inspection feature learns and secures bindings for stateless autoconfiguration addresses in Layer 2 neighbor tables." This statement directly confirms that ND inspection is for stateless autoconfiguration and operates on Layer 2 neighbor tables.

2. Cisco Systems

Inc. (2022). IP Addressing: IPv6 Configuration Guide

Cisco IOS XE Gibraltar 16.12.x.

Section: "Configuring IPv6 First-Hop Security" > "IPv6 Neighbor Discovery Inspection"

Content: This section explains that ND inspection analyzes ND messages to build a secure binding table. It contrasts this with DHCPv6 snooping

which is used for stateful address assignments

reinforcing that ND inspection's role is with stateless autoconfiguration (SLAAC).

The user is successfully authenticated but is not granted the correct privilege level. This occurs because the TACACS+ server is reachable and authorizes the user but fails to return the shell:priv-lvl=15 attribute, causing the router to default to privilege level 1. The original default authorization list's fallback method (local) is never used because the primary method (group tacacs+) succeeds.

Option C resolves this for console access by creating a new authorization list CON with the method none. Applying this list to line con 0 bypasses the TACACS+ authorization check for console logins. When authorization is set to none, the privilege level is determined by the authentication source. Since the user cisco is configured locally with privilege 15, this level is granted upon successful authentication.

A: The if-authenticated keyword is a fallback method used only when TACACS+ servers are unreachable. The current issue is a server misconfiguration, not an outage, so this change has no effect.

B: The none keyword as a fallback is also only used when TACACS+ servers are unreachable. It would not be triggered in this scenario where the server is responding.

D: This globally changes the primary authorization method to local for all lines. While it would work, it is a less targeted solution and alters the intended security policy for all access methods.

1. Cisco IOS Security Configuration Guide: Securing User Services

Release 15M&T

"Configuring Authorization" chapter

"EXEC Authorization" section.

This guide explains that if a remote AAA server authorizes an EXEC session but does not specify a privilege level

the user is placed at privilege level 1. This confirms the cause of the problem. It also details how to apply a named authorization list to a specific line

as shown in Option C.

2. Cisco IOS Security Command Reference

"aaa authorization" command documentation.

This reference details the none keyword for the aaa authorization command

stating: "No authorization is performed. If the security server fails to respond

the user is automatically granted the privilege level associated with that user

as specified in the local database." This supports the mechanism by which Option C solves the issue for the console line.

3. Cisco IOS Security Configuration Guide: Securing User Services

Release 15M&T

"Configuring Authentication" chapter

"Authentication Method Lists" section.

This document clarifies that method lists are processed in sequential order. If the first method (e.g.

group tacacs+) returns a PASS

subsequent methods are not attempted. This explains why the local fallback in the original configuration was not being used and why options A and B are incorrect.

A router selects the best path to a destination by first comparing the Administrative Distance (AD) of all available routes. The route with the lowest AD is preferred. In Cisco IOS, a standard static route has a default AD of 1, while OSPF has a default AD of 110.

The exhibit shows that the active route to 10.10.10.0/24 is learned via OSPF (AD 110). For an OSPF route to be chosen over a configured static route to the same destination, the static route must have been configured with a custom AD value that is higher than 110, making it less preferred.

A. This is incorrect. Route selection is based on the lowest Administrative Distance, and by default, static routes (AD 1) are preferred over dynamic protocols like OSPF (AD 110).

B. The metric is only compared when two or more routes have the same Administrative Distance. Since static routes and OSPF routes have different ADs, the metric is not the primary deciding factor.

D. If the static route syntax were invalid, the command would be rejected by the router's command-line interface and the route would never be entered into the configuration.

1. Cisco Systems

Inc.

"IP Routing: Protocol-Independent Configuration Guide

Cisco IOS XE Gibraltar 16.12.x"

Route Selection in Cisco IOS. This guide states

"If multiple routes to the same destination are available

the router uses the route with the lowest administrative distance." It also lists the default AD for a static route as 1 and OSPF as 110.

2. Cisco Systems

Inc.

"IP Routing: Protocol-Independent Configuration Guide

Cisco IOS XE Gibraltar 16.12.x"

Configuring a Static Route. The documentation provides the syntax for configuring a static route

which includes an optional [distance] parameter to manually set the administrative distance: ip route prefix mask {ip-address | interface-type interface-number [ip-address]} [distance]. This confirms that the AD of a static route can be modified.

3. Kurose

J. F.

& Ross

K. W. (2021). Computer Networking: A Top-Down Approach (8th ed.). Pearson. Chapter 5

"The Network Layer: Control Plane

" discusses the principles of routing algorithms and path selection. It explains that routing protocols use administrative distances as a measure of trustworthiness

with lower values being preferred when multiple protocols provide a route to the same destination.

The error message %Authorization failed is explicit. It indicates that the initial step, authentication (verifying the user's identity), was successful. However, the subsequent step, authorization (determining what the authenticated user is permitted to do), failed. This means the router (R1) successfully communicated with the TACACS+ server, but the server's policy for that user does not grant permission for the requested service, which is an EXEC shell session. The issue lies within the TACACS+ server's configuration, not with the router's configuration or network reachability. The resolution is to modify the user's profile or policy on the TACACS+ server to explicitly permit shell access.

A. The error is about authorization, not authentication. An authentication misconfiguration would typically result in a "login incorrect" message, not an authorization failure.

B. The specific error message confirms that the TACACS+ server is reachable and responded with a denial. If the server were unreachable, a timeout error would occur.

C. If the TACACS+ server host IP were not configured on R1, the router would not know where to send the AAA request, resulting in a different failure, not this specific message.

1. Cisco IOS Security Configuration Guide

Release 15M&T

"Implementing TACACS+": In the "Authorization Overview" section

it is stated

"Authorization is the process of granting or denying a user specific services or commands... Authorization is a separate function from authentication." This confirms that the failure is in a distinct step after successful authentication.

2. Cisco Identity Services Engine Administrator Guide

3.1

"Chapter: Device Administration": The section "Configure Policy Elements for Device Administration" details the configuration of "TACACS Profiles" and "Shell Profiles." It specifies that to grant EXEC shell access

a Shell Profile with appropriate privilege levels must be configured on the ISE (acting as the TACACS+ server) and applied to the user via a policy. An authorization failure occurs if no such policy matches or if the matching policy denies access.

3. Cisco IOS Security Command Reference

"aaa authorization": The documentation for the aaa authorization command explains that its purpose is to run authorization for a specific service (like exec for shell access) against the configured AAA server. The server's response dictates whether the user is granted access

and a denial from the server results in an authorization failure on the device.

SNMPv2c relies on a community string (functioning as a shared password) for access. It transmits data in clear text, meaning there is no encryption. In many basic configurations and exam contexts, SNMPv2c is associated with standard read-only (RO) access strings (e.g., "public").

SNMPv3 uses a User-based Security Model (USM) requiring a username and password. It supports strong security features including authentication (integrity verification via MD5 or SHA) and privacy (encryption). The term privileged in this context refers to the priv security level (Authentication + Privacy) or the ability to map users to privileged execution levels, a capability distinctively managed in V3 groups.

Cisco Systems, Inc., "SNMP Configuration Guide, Cisco IOS XE Release 3S," Chapter: SNMPv1 and SNMPv2c, Section: Security Models. (Confirming community strings and lack of encryption in v2c).

Cisco Systems, Inc., "SNMP Configuration Guide, Cisco IOS XE Release 3S," Chapter: SNMPv3, Section: SNMPv3 Overview. (Confirming USM, username/password, and authentication/privacy levels).

RFC 3414, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)." (Defining the architecture for authentication and privacy).

The route-map FILTER contains a single sequence, deny 10, which matches and denies the 1.1.1.0/24 prefix. However, all route-maps have an implicit, invisible deny all statement at the end. Consequently, any route that does not match sequence 10 (i.e., all routes other than 1.1.1.0/24) will be processed by this implicit deny and will also be dropped. This results in all routes from the neighbor being filtered.

To fix this, a second sequence must be added to explicitly permit all other routes. Adding route-map FILTER permit 20 with no match clause will match all routes that were not denied by sequence 10, thereby permitting them and restoring connectivity.

A. Add a second line in the access list to permit any: This would cause the deny 10 sequence in the route-map to match and deny all routes, not just the intended prefix.

B. Modify the route map to permit the access list instead of deny it: This would permit only 1.1.1.0/24, while all other routes would be blocked by the implicit deny at the end of the route-map.

C. Modify the access list to deny instead of permit it: A deny statement in an access list used by a match clause means the prefix is not considered a match, so it would fall to the implicit deny.

1. Cisco Systems

Inc. (2021). IP Routing: BGP Configuration Guide

Cisco IOS XE Cupertino 17.6.x. In the "Implementing BGP Route Maps" section

the documentation states

"If the route does not match any of the match commands in a route map

it is filtered (denied) by the implicit deny that exists at the end of every route map. To permit routes that are not explicitly denied

you must configure a permit statement without any match commands at the end of the route map." This directly supports the addition of a permit sequence to allow other routes.

2. Cisco Systems

Inc. (2023). Cisco IOS IP Routing: BGP Command Reference. Under the route-map command description

the behavior is detailed: "If you end the route-map statements without a permit or deny action

and a packet does not match any of the match statements

the packet is not forwarded." This confirms the implicit deny behavior.

3. Cisco Systems

Inc. (2023). Cisco IOS IP Routing: BGP Command Reference. The documentation for the match ip address command explains its interaction with access lists. It clarifies that the route-map sequence action (permit or deny) is taken only if the prefix matches a permit entry in the specified access list. This invalidates option C

as a deny in the ACL would prevent a match.

The flapping of routing protocols indicates that legitimate control plane traffic, such as hellos or updates, is being dropped by the Control Plane Policing (CoPP) policy. The best practice for deploying CoPP is to first implement it in a non-disruptive, monitor-only mode. This is achieved by setting both the conform-action and exceed-action to transmit. This configuration allows all traffic to pass but increments counters for conforming and exceeding traffic. The engineer can then analyze these counters to validate the Access Control Lists (ACLs) and adjust the policing rates to accommodate necessary protocol traffic before changing the exceed-action to drop. CoPP protects traffic destined to the router, so the policy must be applied in the input direction on the control plane.

A. Control Plane Policing is applied to traffic destined for the control plane, which is an input function; applying it in the output direction is incorrect.

C. Setting the exceed-action to drop immediately is the likely cause of the routing protocol flapping. A monitoring phase is required first.

D. This option is incorrect for two reasons: the policy direction is wrong (output), and the exceed-action is prematurely set to drop.

1. Cisco Systems

"Control Plane Policing Implementation Best Practices" White Paper.

Reference: In the "CoPP Deployment" section

under the "Monitor Mode" subsection

the document states: "It is highly recommended to deploy CoPP in a non-disruptive

monitor-only fashion first. This can be accomplished by configuring the exceed action to transmit instead of drop. This allows for the verification of the CoPP policy without affecting traffic." This directly supports setting both actions to transmit for initial testing.

2. Cisco IOS XE Security Configuration Guide

Cisco IOS XE Fuji 16.9.x

"Configuring Control Plane Policing".

Reference: In the "How to Configure Control Plane Policing" section

the guide shows the command service-policy {input | output} policy-map-name. It explains that CoPP is applied to the control plane interface

and for protecting the router's CPU

the input keyword is used to control traffic destined for the device. This confirms the correct direction is input.

3. Cisco Systems

"Guide to Control Plane Policing" Document.

Reference: In the "Deployment Methodology" section

the guide recommends a phased approach: "The first phase is to deploy CoPP in monitor mode (that is

permit all traffic but use counters to measure the traffic rates). This allows you to understand the current traffic rates without impacting the network... Once you are confident with the configured rates

you can move to the second phase

which is to enforce the policy by changing the action for exceeding traffic from transmit to drop." This validates the entire strategy outlined in the correct answer.

For OSPF to function correctly over a DMVPN network, the OSPF network type should be set to point-to-multipoint on all participating routers (hub and spokes). This network type is designed for Non-Broadcast Multi-Access (NBMA) environments like DMVPN. It prevents the election of a Designated Router (DR) and Backup Designated Router (BDR), which would fail in a standard hub-and-spoke topology where spokes cannot directly communicate with each other initially. By treating the network as a collection of point-to-point links, it ensures proper next-hop resolution, which is critical for enabling direct spoke-to-spoke communication in DMVPN Phase 2 and 3.

B. ip ospf network point-to-point on the hub router: The hub's multipoint GRE (mGRE) interface connects to multiple spokes, not a single peer, making the point-to-point network type unsuitable.

C. ip ospf network point-to-multipoint on One spoke router: OSPF parameters, including the network type, must be consistent across all routers on a network segment to form adjacencies.

D. ip ospf network point-to-point on both spoke routers: The spokes connect to a multipoint network via the hub, not a simple point-to-point link, making this network type incorrect.

1. Cisco Systems

"OSPF over DMVPN Design Guide". In the "OSPF Network Type" section

the document states

"The recommended OSPF network type to run on a DMVPN network is point-to-multipoint. This network type does not have a DR/BDR

so it does not matter which routers can speak to each other." This directly supports using point-to-multipoint to avoid DR/BDR issues inherent in the DMVPN topology.

2. Cisco Systems

"IP Routing: OSPF Configuration Guide

Cisco IOS XE Gibraltar 16.12.x". The "OSPF Network Types" section describes the point-to-multipoint network type as a "numbered point-to-point link that has one or more neighbors

" which accurately models the hub-to-spoke relationship in DMVPN.

3. Lacoste

R.

& Edgeworth

B. (2020). CCNP Enterprise Advanced Routing ENARSI 300-410 Official Cert Guide. Cisco Press. Chapter 11

"Dynamic Multipoint VPN (DMVPN)

" in the section "DMVPN and Routing Protocols

" explicitly recommends

"The recommended OSPF network type for DMVPN is point-to-multipoint. This network type does not elect a DR/BDR

which is ideal for a partial-mesh topology." The configuration examples in this chapter show the ip ospf network point-to-multipoint command applied to both hub and spoke tunnel interfaces.

The Cisco DNA Center exhibit indicates a "BGP Flapping" issue, and the router output confirms that Bidirectional Forwarding Detection (BFD) is enabled for the BGP neighbor. BFD provides very fast failure detection, but if its timers are too aggressive for the underlying network conditions (e.g., minor jitter or packet loss), it can prematurely declare the neighbor down, causing the BGP session to flap.

The most appropriate solution is to make the BFD timers less aggressive. The command bfd interval 300 minrx 300 multiplier 5 on the relevant interface increases the BFD transmission/reception interval to 300 milliseconds and the dead timer multiplier to 5. This increases the total detection time, making the BFD session more resilient to transient network issues and stabilizing the BGP peering.

A: This command enables BFD, but the show command output confirms that BFD is already enabled for the neighbor.

B: This command modifies the BGP keepalive and hold timers. BFD operates independently and provides much faster detection, making these BGP timers irrelevant for failure detection when BFD is active.

C: This command disables BFD. While this would stop the BFD-induced flapping, it sacrifices the primary benefit of fast network convergence, which is generally not the preferred solution.

1. Cisco IOS XE Interface and Hardware Component Configuration Guide

Cisco IOS XE Gibraltar 16.12.x

"Configuring BFD Session Parameters on the Interface": This document details the bfd interval milliseconds minrx milliseconds multiplier number command. It explains that this command is used to customize BFD timers on an interface to prevent BFD from reporting false link failures on unstable networks. This directly supports the configuration in the correct answer. (Source: Cisco Official Documentation

URL: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproutebfd/configuration/16-12/irb-16-12-book/irb-bfd.html#ID-2112-0000004d)

2. Cisco IOS XE BGP Configuration Guide

Cisco IOS XE Fuji 16.9.x

"BGP Support for BFD": This guide explains that when BFD is enabled for a BGP neighbor using the neighbor fall-over bfd command

the BGP session state is tied to the BFD session state. If the BFD session goes down

BGP immediately tears down its peering relationship. This confirms why an unstable BFD session leads to BGP flapping. (Source: Cisco Official Documentation

URL: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproutebgp/configuration/xe-16-9/irg-xe-16-9-book/bgp-support-for-bfd.html)

3. Cisco SD-WAN BGP Configuration Guide

Cisco IOS XE SD-WAN Release 17.x

"Configure BFD for BGP": This document explicitly states

"If you configure BFD to be too aggressive

BFD may report a link as having failed

when the link has not failed. For example

if you configure a very low BFD timer and multiplier

a slight increase in traffic on a link may cause BFD to miss the required number of packets to keep the link active." This directly describes the problem scenario and validates the solution of adjusting BFD timers to be less aggressive. (Source: Cisco Official Documentation

URL: https://www.cisco.com/c/en/us/td/docs/routers/sdwan/configuration/routing/ios-xe-17/routing-book-xe/m-bgp.html#CiscoConcept.dita1109c59f-115e-411b-811b-111111111111)

The primary advantage of Bidirectional Forwarding Detection (BFD) is its ability to provide rapid failure detection in the forwarding path between two adjacent devices. BFD is a lightweight protocol designed specifically for this purpose, capable of detecting path failures in tens or hundreds of milliseconds. This is significantly faster than the default failure detection mechanisms of most routing protocols (e.g., OSPF or EIGRP hellos), which typically operate on a scale of seconds. This rapid detection allows for faster network convergence and minimizes traffic loss upon a link or node failure.

A. BFD detects forwarding path failures, not route flapping. While a flapping link can cause route instability, BFD's function is to signal the path failure, not manage the route advertisements.

C. BFD is not a standalone protocol for routing; it is designed to work with client applications, such as routing protocols (OSPF, BGP, EIGRP), to which it signals detected failures.

D. BFD does not directly maintain the routing table. It provides a fast trigger to routing protocols, which then update and maintain the routing table based on the BFD state information.

1. Cisco Systems

Inc.

"IP Routing: BFD Configuration Guide

Cisco IOS XE Release 3S". BFD Overview. "BFD is a detection protocol designed to provide fast forwarding path failure detection times for all media types

encapsulations

topologies

and routing protocols... BFD provides a low-overhead

short-duration detection of failures in the path between adjacent forwarding engines. It operates in the order of milliseconds."

2. Katz

D.

& Ward

D.

"RFC 5880: Bidirectional Forwarding Detection (BFD)"

Internet Engineering Task Force (IETF)

June 2010. Abstract. "This document describes a protocol that is intended to detect faults in the bidirectional path between two forwarding engines... It provides low-overhead

short-duration detection of failures..."

3. Katz

D.

& Ward

D.

"RFC 5882: Generic Application of Bidirectional Forwarding Detection (BFD)"

Internet Engineering Task Force (IETF)

June 2010. Section 3

Why BFD?. "The primary application for BFD is for any two systems that are connected at any protocol layer to agree to track the liveness of the path between them... The intent of BFD is to provide a low-overhead

ubiquitous

short-latency

protocol- and media-independent failure detection mechanism."