Free 300-410 Practice Questions – 2025 Updated

A. This option is ambiguous as "between R2-R3-R1" does not refer to a single, configurable link cost.

C. Decreasing costs on the R6-R5-R2 segment does not alter R2's routing decision to prefer R3 as the next hop to R1.

D. Decreasing the R2-R1 cost to 41 is insufficient, as R2 would still prefer the path through R3, which has a cost of 20.

1. Cisco Systems, IP Routing: OSPF Configuration Guide, "OSPF Cost" section. This document explains that OSPF uses cost as its metric and that the path with the lowest total cost is preferred. Modifying link costs is the standard method for influencing the path selection made by the Shortest Path First (SPF) algorithm.

2. Moy, J. RFC 2328: OSPF Version 2, Section 16, "Calculating the Shortest-Path Tree for an Area". This RFC details the Dijkstra algorithm used by OSPF. Each router independently calculates the shortest path to all destinations. The calculation at R2 shows the path via R3 is preferred (cost 20) over the direct path (cost 50), which must be changed to influence the route.

3. Kurose, J., & Ross, K. Computer Networking: A Top-Down Approach, Chapter 5, "The Network Layer: Control Plane". University-level textbooks on networking explain that link-state protocols like OSPF build a complete map of the topology. Each router then independently runs an algorithm like Dijkstra's to compute the shortest path from itself to all other nodes. This confirms the analysis must focus on R2's local decision.

A. short duration, high overhead: BFD is designed to be a lightweight protocol with minimal impact on system resources, making the "high overhead" description inaccurate.

C. long duration, high overhead: This is the opposite of BFD's design goals. BFD is engineered for speed (short duration) and efficiency (low overhead).

D. long duration, low overhead: While BFD is low overhead, its main purpose is rapid failure detection, not "long duration." Routing protocol hello timers are an example of longer-duration mechanisms.

1. Cisco Systems, Inc. (2023). IP Routing: BFD Configuration Guide, Cisco IOS XE Bengaluru 17.6.x. "BFD provides a low-overhead, short-duration method of detecting failures in the path between adjacent forwarding engines, including the interfaces, data links, and forwarding planes." (Chapter: BFD Overview, Section: Finding Information About BFD, Paragraph 2).

2. Katz, D., & Ward, D. (2010). RFC 5880: Bidirectional Forwarding Detection (BFD). The Internet Engineering Task Force (IETF). "This document describes a protocol that is intended to detect faults in the path between two forwarding engines... It can provide very low-latency failure detection... It is intended to be a lightweight protocol that can be run on a wide variety of systems and platforms." (Abstract and Section 1: Introduction, Paragraph 3).

3. Cisco Systems, Inc. (2023). Cisco SD-WAN BFD and Tunnels Overview. "BFD is a low-overhead, short-duration protocol that detects failures in the path between adjacent routers." (Section: Bidirectional Forwarding Detection, Paragraph 1).

A. password encryption aes

This command is used to configure a master encryption key for features like VPNs, not for hashing local user passwords.

B. username Admin password Cisco@maedeh motamedi

This command configures a plaintext (Type 0) password, which is the exact problem the engineer is trying to resolve.

C. username Admin password 5 Cisco@maedeh motamedi

The 5 keyword indicates the string that follows is already an MD5 hash, not the plaintext password to be hashed.

E. no service password-encryption

This command disables the password encryption service, ensuring passwords remain in plaintext, which is the opposite of the desired outcome.

---

1. Cisco IOS Security Configuration Guide, Release 15M&T, "Securing User Services":

On username secret: "The secret keyword specifies that the password that follows is encrypted... We recommend using the secret option because the password option is not secure." (Found in the "Configuring Local AAA" section).

On service password-encryption: "The service password-encryption command prevents unauthorized users from seeing passwords in the configuration file." (Found in the "Encrypting Passwords" section).

2. Cisco IOS Security Command Reference, "username":

This document details the syntax username {password | secret} . It explains that secret stores the password in an encrypted format, while password stores it in clear text unless service password-encryption is enabled, in which case it uses a less secure, proprietary encryption.

3. Cisco IOS Security Command Reference, "service password-encryption":

This reference states, "To encrypt passwords, use the service password-encryption command in global configuration mode. To disable password encryption, use the no form of this command." This confirms its role in obscuring plaintext passwords.

A. Change the IP MTU of R1 Fa1/0 to 1300: This assumes R2 has an MTU of 1300. It is better practice to correct a misconfigured device to the standard value rather than lowering the correctly configured one.

B. Change the IP MTU of R2 Fa0/0 to 1300: This would only resolve the issue if R1's MTU was also 1300, which is a non-standard and less likely configuration for a FastEthernet interface.

C. Change the IP MTU of R1 Fa1/0 to 1500: This implies R1 is the misconfigured router. Since the provided output is from R2, it is more probable that the misconfiguration is on the local device (R2).

1. Cisco Systems, IP Routing: OSPF Configuration Guide, "OSPF Neighbor States." In the "Exstart State" section, the documentation explains that neighbors form a master/slave relationship to exchange DBD packets. It explicitly states, "If there is a mismatch in the MTU, the routers will get stuck in this state." This confirms that an MTU mismatch is a direct cause of adjacency failure after the initial Hello exchange.

2. Moy, J. (1998). RFC 2328: OSPF Version 2. Internet Engineering Task Force (IETF). Section 10.6, "Receiving Database Description Packets," p. 103. This official standard specifies the protocol behavior: "If the Interface MTU field in the Database Description packet indicates a larger MTU than the router can accept on the receiving interface, the Database Description packet is rejected." This rejection prevents the adjacency from progressing. DOI: 10.17487/RFC2328.

3. Cisco Systems, Internetworking Troubleshooting Guide, "Troubleshooting OSPF." In the section "OSPF is Stuck in EXSTART/EXCHANGE State," it details that an MTU mismatch is a primary cause. It notes that OSPF packets have the Don't Fragment (DF) bit set, so if a packet is larger than the receiving interface's MTU, it is dropped, stalling the adjacency process.

A. The delay command is configured under track configuration mode (config-track), not IP SLA configuration mode. The syntax ip sla 700 followed by a track command is incorrect.

B. Similar to option A, the delay command is not a valid subcommand for an IP SLA operation. The command syntax is incorrect.

D. While this option is syntactically correct, the specific timer values (down 20 up 30) represent a different dampening policy than option C. Given the scenario, option C is the intended correct configuration.

1. Cisco IOS IP Application Services Command Reference - track delay: "To configure a delay for a tracked object before it advertises a state change, use the delay command in tracking configuration mode. ... Using the delay command can be used to dampen the effect of a tracked object flapping." This source confirms the purpose of the delay command is for dampening flapping states.

2. Cisco IOS IP Application Services Command Reference - track ip sla: "To track the state of a Cisco IOS IP Service Level Agreements (SLAs) operation, use the track ip sla command in global configuration mode." This source confirms the syntax track ip sla state is correct for associating a track object with an IP SLA operation.

3. IP SLAs Configuration Guide, Cisco IOS XE - "Tracking with IP SLAs" section: This guide details the relationship between IP SLA operations and the tracking mechanism. It explains that tracking allows other features (like static routing) to react to the state of an IP SLA operation and that dampening features like delay can be applied to the track object.

A. Configure route tagging: Route tagging is used for route-map policies and redistribution control, not for preventing fundamental intra-AS routing loops.

C. Configure R2 as stub receive-only: While making R2 a stub router would stop it from advertising routes and thus break the loop, it is not the fundamental solution to the underlying protocol issue.

D. Configure route filtering: Route filtering with a distribute-list can manually block the looped route but only addresses the symptom, not the root cause of the loop.

---

1. Cisco Systems, IP Routing: EIGRP Configuration Guide, "How to Configure EIGRP": In the section "EIGRP Split Horizon," the documentation states, "Split horizon controls the sending of EIGRP update and query packets. When split horizon is enabled on an interface, these packets are not sent for destinations for which this interface is the next hop... By default, split horizon is enabled on all interfaces." This confirms that enabling split horizon is the standard mechanism to prevent this type of loop.

2. Cisco Press, "CCNP and CCIE Enterprise Core ENCOR 350-401 Official Cert Guide": Chapter 7, "EIGRP," in the section "EIGRP Path-Calculation and Loop Prevention," explains that split horizon is a key loop-prevention technique. It details that "The simple split-horizon rule says that if a router learns a route through an interface, it will not advertise that same route out that same interface." The text clarifies that disabling this feature can lead to routing loops.

3. RFC 7868: Cisco's Enhanced Interior Gateway Routing Protocol (EIGRP): Section 3.4, "Split Horizon," defines the rule: "A routing update is never sent back out the interface on which it was received. This is a fundamental loop-prevention mechanism." This RFC standardizes the behavior, confirming its role in loop prevention.

A. Enable poison reverse: Poison reverse is a stricter form of split horizon and would prevent, not enable, the advertisement of routes between spokes.

B. Enable split horizon: Split horizon is already enabled and is the cause of the issue; this action would not change the problematic state.

C. Disable poison reverse: The configuration does not show poison reverse being enabled, so disabling it would have no effect on the problem.

1. Cisco Systems, Inc., IP Routing: EIGRP Configuration Guide, Cisco IOS XE Release 3S, "How to Configure EIGRP" section, "Disabling and Enabling EIGRP Split Horizon" subsection. The document states, "Split horizon is disabled by default for multipoint subinterfaces using Frame Relay encapsulation. If you have a hub-and-spoke network, you may need to disable split horizon on the hub to allow routes to be advertised back to the spokes." This directly supports disabling split horizon as the solution.

2. Cisco Systems, Inc., Cisco IOS IP Routing: EIGRP Command Reference, "ip split-horizon eigrp" command documentation. It notes: "Split horizon is enabled by default on all interfaces except for Frame Relay and SMDS multipoint subinterfaces (it is disabled by default on these interfaces)." The question's configuration explicitly enables it, which is contrary to the required setting for a functional hub-and-spoke topology.

3. Teare, D., et al. (2015). Implementing Cisco IP Routing (ROUTE) Foundation Learning Guide: (CCNP ROUTE 300-101). Cisco Press. Chapter 4, "Implementing EIGRP for IPv4," section "EIGRP in an NBMA Topology." The text explains, "On a multipoint subinterface, split horizon is disabled by default. This is the desired behavior in a hub-and-spoke topology, so that the hub can advertise the routes learned from one spoke to the other spokes."

B. The command ip tcp adjust-mtu is not a valid Cisco IOS command for this purpose. The correct command to modify the TCP Maximum Segment Size is ip tcp adjust-mss.

C. The command crypto ipsec fragmentation mtu-discovery is not a valid Cisco IOS command. Path MTU Discovery (PMTUD) is typically managed using the df-bit setting, not this syntax.

D. This option contains two invalid commands for this scenario: ip tcp adjust-mtu and crypto ipsec fragmentation mtu-discovery.

1. Cisco Systems, "DMVPN Configuration Guide" (Cisco IOS XE Gibraltar 16.12.x). In the section "Resolve IP Fragmentation and MTU-Size Issues," the guide explicitly recommends this configuration: "The recommended values are ip mtu 1400 and ip tcp adjust-mss 1360 on the tunnel interface... IPsec post-fragmentation (fragmentation after encryption) is the recommended method. To configure IPsec post-fragmentation, use the crypto ipsec fragmentation after-encryption command in global configuration mode."

2. Cisco Systems, "IPsec Command Reference" (Cisco IOS XE). The documentation for the crypto ipsec fragmentation command states that after-encryption is the default and preferred behavior. It specifies that this command "enables IPsec packet fragmentation after encryption."

3. Cisco Systems, "IP Addressing Services Command Reference" (Cisco IOS XE). The documentation for the ip tcp adjust-mss command confirms its function: "To adjust the maximum segment size (MSS) for TCP connections, use the ip tcp adjust-mss command in interface configuration mode." It is used to prevent fragmentation by reducing the TCP segment size.

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

A. This adds a new entry to permit all other traffic but does not alter the logging behavior of the first entry, which is the source of the messages.

C. Replacing log-input with log would still generate log messages for denied Telnet packets, although the messages would contain less detail (no L2 info).

D. This adds a new entry with logging enabled. It does not stop the logging caused by the existing deny entry on line 10.

1. Cisco IOS IP Application Services Configuration Guide, Release 15M&T, "Configuring IP Access Lists" section, "IP Access List Entry Logging" subsection.

This document states, "To generate logging messages for packets that are permitted or denied by an access list, use the log or log-input keyword when you configure the access-list command." It further explains that log-input adds the input interface and source MAC address to the log. This confirms that removing the keyword is the correct action to stop the logging it enables.

2. Cisco IOS Security Command Reference, "access-list (IP extended)" command.

In the command syntax description, the log and log-input arguments are detailed as optional keywords that enable logging for matching packets. The documentation implicitly supports that the absence of these keywords means no logging will occur for that specific ACE.

B. neighbor R2 route-reflector-client

This command is syntactically incorrect. BGP neighbor configuration requires an IP address or a pre-defined peer-group name, not a hostname.

C. neighbor 10.1.1.2 allowas-in

This command is used to accept eBGP routes that contain the local router's AS number in the ASPATH, which is not relevant for an iBGP route reflection scenario.

D. neighbor R4 route-reflector-client

This command is syntactically incorrect. BGP neighbor configuration requires an IP address or a pre-defined peer-group name, not a hostname.

---

1. Cisco IOS IP Routing: BGP Command Reference, neighbor route-reflector-client command.

Reference: In the neighbor route-reflector-client command documentation, it states: "To configure the router as a BGP route reflector and to configure the specified neighbor as its client, use the neighbor route-reflector-client command... A BGP speaker that is configured as a route reflector does not advertise iBGP-learned routes to other iBGP peers by default. The neighbor route-reflector-client command must be configured for each iBGP peer that is a client of the route reflector." This directly supports the necessity of options A and E.

Source: Cisco Official Documentation, BGP Commands: M through N.

2. IP Routing: BGP Configuration Guide, Cisco IOS XE, "BGP Route Reflector" chapter.

Reference: Under the section "How to Configure a BGP Route Reflector," the guide specifies the configuration syntax: "neighbor ip-address route-reflector-client". It explicitly shows that an IP address is required, which invalidates the syntax used in options B and D.

Source: Cisco Official Documentation, IP Routing: BGP Configuration Guide, Cisco IOS XE.

3. RFC 4456, "BGP Route Reflection: An Alternative to Full Mesh Internal BGP (iBGP)", Section 8, "CONFIGURATION AND DEPLOYMENT CONSIDERATIONS".

Reference: This RFC, which defines the route reflector concept, states: "A RR and its clients form a cluster. The CLUSTERID is configured on the RR." and "An iBGP peer of a RR is configured as a client of the RR on the RR." This foundational document establishes that client configuration on the route reflector is the mechanism to enable route reflection.

A. RA Throttling specifically limits the rate of Router Advertisement (RA) messages to prevent CPU exhaustion on hosts, not the entire neighbor discovery process.

B. Source or Destination Guard are enforcement features that use the binding table (created by snooping) to filter traffic; they do not control the discovery process itself.

C. ND Multicast Suppression is a performance optimization feature that reduces the amount of ND multicast traffic, but it does not inspect or validate the discovery messages.

1. Cisco Systems, Inc. (2023). Security Configuration Guide, Cisco IOS XE Bengaluru 17.6.x (Catalyst 9300 Switches). "Information About IPv6 First-Hop Security" section, under "IPv6 Snooping". The document states, "IPv6 snooping learns and secures bindings for stateless autoconfiguration addresses in Layer 2 neighbor tables. IPv6 snooping is the basis for many of the other IPv6 first-hop security features." This confirms its role in learning from discovery traffic.

2. Cisco Systems, Inc. (2023). Security Configuration Guide, Cisco IOS XE Bengaluru 17.6.x (Catalyst 9300 Switches). "Information About IPv6 First-Hop Security" section, under "RA Throttling". The documentation explains that this feature is used "to control the RA messages that are sent from routers," which is a specific subset of NDP traffic.

3. Cisco Systems, Inc. (2023). Security Configuration Guide, Cisco IOS XE Bengaluru 17.6.x (Catalyst 9300 Switches). "Information About IPv6 First-Hop Security" section, under "IPv6 Source Guard". The guide notes that this feature "cause[s] the device to deny traffic from a source address that is not in the binding table," highlighting its role as an enforcement mechanism post-discovery.

A: The current access-list only permits UDP traffic. TCP traffic will not match the PBR policy and will be dropped by the route-map's implicit deny.

B: Adding a new route-map statement is not the most direct solution. The root cause is that the existing policy's match criteria (the ACL) is too restrictive.

D: The set ip next-hop 10.10.12.2 command is already correctly configured. The issue is that TCP traffic is not meeting the match condition to trigger this action.

1. Cisco Systems, Inc., "IP Routing: Protocol-Independent Configuration Guide, Cisco IOS XE Gibraltar 16.12.x", Chapter: "Policy-Based Routing". In the "How to Configure Policy-Based Routing" section, the procedure clearly states that the first step is to use an access list to classify the traffic that is to be policy-routed. The configuration in the question fails to classify TCP traffic, which is why the policy does not apply to it.

2. Cisco Systems, Inc., "Cisco IOS IP Routing: BGP Command Reference", route-map command documentation. The documentation explains the logic of route-maps: "If a packet does not match any match clause in a route map, it is denied (filtered) by the implicit deny statement that exists at the end of every route map." This confirms that TCP traffic, not matching the UDP-only ACL, will be dropped.

A. Only lowering the tunnel IP MTU triggers ICMP “frag-needed”; hosts often ignore it, so fragmentation still occurs or traffic stalls.

B. Enabling PMTUD on the tunnel relies on ICMP feedback that is frequently blocked; MSS remains too large.

D. Setting ip tcp adjust-mss 1500 leaves the MSS unchanged; packets still exceed the available MTU once the VPN headers are added.

1. Cisco IOS XE 17 “ip tcp adjust-mss” Command Reference, Usage Guidelines, para. 3-4 (cisco.com/c/en/us/support/docs/caq-10727).

2. Cisco “GRE over IPsec Design Guide”, Section “Effect of MTU and MSS on DMVPN” pages 5-7, 2019.

3. Cisco Live Session BRKSEC-2005 “IP Fragmentation & MTU in VPNs”, slides 29-33, June 2020.

4. D. B. Chapman & E. Zwicky, “TCP/IP Performance over Tunnels”, ACM SIGCOMM CCR Vol 42-4, pp. 54-55 (https://doi.org/10.1145/2378956.2378966).

A. Clearing the OSPF process alone is insufficient; the underlying configuration issue of the duplicate router ID will persist and cause the problem to reoccur.

C. Increasing the SPF delay interval only changes the timing of SPF calculations; it does not resolve fundamental configuration errors like a duplicate router ID.

D. The router with ID 0.0.0.0 has formed a full adjacency and is not the source of the problem; the duplicate router ID 10.255.255.1 is the critical issue.

1. Cisco Systems, Inc., IP Routing: OSPF Configuration Guide, Cisco IOS XE Gibraltar 16.12.x, "OSPF Router ID" section. The documentation states, "The OSPF router ID is a 32-bit number assigned to each router running OSPF. This number uniquely identifies the router within an autonomous system."

2. Moy, J., RFC 2328: OSPF Version 2, The Internet Society, April 1998, Appendix A.3.2, "The Router-LSA". This RFC specifies that the Router ID is a "32-bit number that uniquely identifies the router in the AS." The uniqueness is a core requirement of the protocol.

3. Cisco Systems, Inc., Troubleshooting OSPF, Document ID: 13689. In the "Troubleshooting OSPF Adjacency Problems" section, it is noted that duplicate router IDs will prevent adjacencies from forming correctly or cause routing instability. The document states, "If the router IDs are the same, routing problems will occur because OSPF router IDs must be unique."

B. BFD is designed to be a low-overhead protocol with minimal impact on CPU. Many network devices can offload BFD processing to hardware, further reducing CPU utilization.

C. If BFD neighbors have different version numbers, a session will not be established. The protocol does not negotiate to the highest version; a version mismatch results in failure.

D. While BFD provides uniform failure detection on the same media type, this statement is incomplete. Its key function is providing this uniformity across all media types, not just within one.

1. IETF RFC 5880: Bidirectional Forwarding Detection (BFD), D. Katz, D. Ward, June 2010.

Section 1, Introduction: "BFD provides a single, standardized method for failure detection for any media, at any protocol layer, with a wide range of detection times and overhead... It is also intended to be efficient enough for hardware implementation, allowing for very low detection times with minimal CPU load." (Supports answer A, refutes B).

Section 6.2, Sending BFD Control Packets: "The Version field is 3 bits. This specifies the BFD protocol version number. The version number of the protocol described in this document is 1." (The RFC defines a static version, implying a mismatch will cause failure, refuting C).

2. Cisco IOS XE BGP Configuration Guide, Release 17.x, "BFD Support for BGP" chapter.

"Information About BFD Support for BGP" section: "BFD is a detection protocol designed to provide fast forwarding-path failure detection times for all media types, encapsulations, topologies, and routing protocols." (Supports answer A and refutes D).

A: This configuration creates full bidirectional connectivity between Site-A and Sites B/C because each VRF is configured to import the other's exported Route Target, directly violating the isolation requirement.

B: While this configuration also isolates Site-A from B/C, it includes route-target import 100:1 for CUSTOMERA. This configures functionality beyond the requirements, implying connectivity between multiple "A" sites, which was not specified.

D: This configuration places all sites into the same VPN by having both VRFs export and import the same Route Target (100:1). This results in full any-to-any communication, violating the isolation requirement.

1. Cisco Systems, Inc. (2021). MPLS Layer 3 VPNs Configuration Guide, Cisco IOS XE Fuji 16.9.x.

Section: "How to Configure MPLS Layer 3 VPNs" > "Configuring a VRF Table". This section details the route-target {import | export | both} command. It clarifies that specifying only export adds a route target to the export list, and specifying only import adds to the import list. If one is specified without the other, the other list remains empty, which is the behavior leveraged by the correct answer.

2. Cisco Systems, Inc. (2023). IP Routing: BGP Configuration Guide, Cisco IOS XE 17.x.

Section: "MPLS VPN Inter-AS" > "MPLS VPN Overview". This document explains the fundamental roles of Route Distinguishers (RDs) and Route Targets (RTs). It states, "A route target is a BGP extended community attribute that is used to identify the VPNs to which a route belongs. The route-target command is used to control the distribution of routes among VPNs." This principle is central to the question, where RTs are used to control route distribution to enforce the required access policy.

A. Site2 router eigrp 100 variance 3

The variance command must be on the router performing the load balancing (Site1), not on the downstream router (Site2).

B. Site2 router eigrp 100 variance 2

This configuration is on the wrong router. It must be applied on Site1 to affect its routing table and load-balancing decisions.

C. Site3 router eigrp 100 variance 2

This configuration is on the wrong router. It must be applied on Site1, which is the convergence point for the paths.

1. Cisco Systems, "IP Routing: EIGRP Configuration Guide, Cisco IOS XE Gibraltar 16.12.x". In the section "Configuring EIGRP Unequal Cost Path Load Balancing," the documentation states, "The variance is a number (from 1 to 128) that the router uses to determine which routes to include in the load-balancing group. The variance is multiplied by the local best metric (the feasible distance [FD]), and any feasible successor with a metric less than this result is included in the load-balancing group." This confirms the command is configured locally on the router making the decision.

2. V. B., D. Hucaby, and B. Edgeworth, "CCNP Enterprise Advanced Routing ENARSI 300-410 Official Cert Guide," Cisco Press, 2020. In Chapter 4, "EIGRP," the section "Unequal-Cost Load Balancing" explains that the variance command is configured under the EIGRP routing process on the router where load balancing is desired. It also details the formula: Metric of Feasible Successor < (Metric of Successor variance).

A. This is a permit statement. The requirement is to deny, not permit, this specific traffic flow.

B. This statement incorrectly reverses the source and destination addresses for a filter applied inbound on R1.

D. This is a permit statement and also incorrectly reverses the source and destination addresses.

1. Cisco IOS XE Security Configuration Guide, Release 17.x, "Implementing IPv6 Access Control Lists": This document states, "The router tests the packet against the conditions in the access list one by one. The first match determines whether the router accepts or rejects the packet." This confirms that a specific deny statement must be placed before a general permit statement to be effective. The syntax for an ACE is also detailed, confirming the structure used in the correct answer.

2. Cisco IOS IPv6 Configuration Guide, Release 15M&T, "IPv6 Access Control Lists": In the section "How to Configure IPv6 ACLs," the guide provides the command syntax: deny protocol {source-ipv6-prefix/prefix-length | host source-ipv6-address | any} {destination-ipv6-prefix/prefix-length | host destination-ipv6-address | any}. This directly supports the format deny tcp host host as the correct way to specify the source and destination hosts for the traffic to be denied.

3. Cisco IOS Master Command List, "ipv6 traffic-filter": The documentation for this command explains its use for applying an access list to an interface for filtering inbound or outbound traffic. This confirms that for an in filter, the source address in the ACL corresponds to the packet's originator (R2) and the destination is the local interface (R1).

A. This command is in the wrong mode (# instead of (config)#) and sets a restrictive critical logging level, which captures fewer message types.

C. This command is entered in the wrong configuration mode (#). While it increases buffer size, the critical level is too restrictive for general troubleshooting.

D. This command uses the default buffer size of 4096 bytes, which fails to address the core problem of not holding enough log messages.

1. Cisco IOS XE System Management Command Reference, logging buffered command: This document specifies that logging buffered is a global configuration command. It defines the syntax as logging buffered [buffer-size | severity-level]. The buffer-size argument increases the memory allocated for log messages. The default size is platform-dependent but is often small (e.g., 4096 bytes).

Source: Cisco, "Cisco IOS XE System Management Command Reference," Chapter: L Commands, logging buffered section.

2. Cisco IOS XE System Management Configuration Guide, "Configuring System Message Logging" chapter: This guide explains the syslog severity levels. Level 6 (informational) includes messages for normal but significant conditions, providing more context for troubleshooting than level 2 (critical), which only logs critical conditions. Setting the level to informational logs all messages from levels 0 through 6.

Source: Cisco, "System Management Configuration Guide, Cisco IOS XE," Chapter: Configuring System Message Logging, "Syslog Message Severity Levels" table.

A. Increasing the EIGRP AD to 100 is still lower than the configured BGP AD of 200. EIGRP would remain the preferred protocol.

C. This is an incomplete solution. It would fix the issue on R1, but R2 would still prefer the EIGRP route, preventing symmetric BGP routing.

D. The routers are configured with EIGRP, not OSPF. This command would have no effect on the current routing behavior.

1. Cisco Systems, Inc., IP Routing: BGP Command Reference, "distance bgp" section. This document details the distance bgp command, explaining that its purpose is to "define the administrative distance for routes learned from a BGP routing process." It specifies the syntax distance bgp , confirming that the first value (200 in the exhibit) modifies the eBGP AD.

2. Cisco Systems, Inc., IP Routing: Protocol-Independent Configuration Guide, Cisco IOS Release 15M&T, "Route Selection in Cisco Routers" chapter, "Administrative Distance" section. This guide provides the default AD table, listing "External BGP" as 20 and "Internal EIGRP" as 90. This confirms that removing the manual configuration will restore a more preferable AD for BGP.

3. Cisco Systems, Inc., BGP Configuration Guide, Cisco IOS Release 15M&T, "BGP Overview" chapter, "BGP Administrative Distance" section. This document states, "The administrative distance is the first criterion that a router uses to determine which routing protocol to use if two protocols provide route information for the same destination." This supports the core reason for the problem.

A. Removing the password does not alter the allowed transport protocol; the transport input ssh command would still block the Telnet connection attempt.

C. The no login command disables authentication but does not affect the transport protocol restriction. The connection would still be refused.

D. While transport input all would also permit Telnet, it is a less precise solution. Option B is the most specific answer that enables only the required protocol.

1. Cisco IOS Terminal Services Command Reference, "transport input" command documentation.

Reference: Cisco Systems, Inc. (2012). Cisco IOS Terminal Services Command Reference, Release 15.2M&T.

Details: The documentation for the transport input command specifies that keywords like ssh or telnet restrict access to only those protocols. The configuration transport input ssh allows only SSH connections. To permit Telnet, the configuration must be changed to include the telnet keyword, for example, transport input telnet.

2. Cisco IOS Security Configuration Guide: Securing User Services, Release 15M&T, "Configuring Secure Shell" section.

Reference: Cisco Systems, Inc. (2013). Cisco IOS Security Configuration Guide: Securing User Services, Release 15M&T.

Details: In the section on securing VTY lines, the guide explains the use of transport input to control access methods. It explicitly states that transport input ssh will "cause the VTY lines to accept only SSH connections." This confirms that the original configuration is the source of the problem.

A. The set ip next-hop command is used without the recursive keyword. This configuration is invalid because the next-hop 10.3.3.1 is not directly connected to R1.

C. The access-list uses a subnet mask (255.255.255.0) instead of the required wildcard mask (0.0.0.255), making the ACL syntax incorrect.

D. The access-list uses a subnet mask (255.255.255.0) instead of the required wildcard mask (0.0.0.255), which is syntactically incorrect for an ACL.

1. Cisco Systems, "Cisco IOS IP Routing: Protocol-Independent Command Reference," Release 15M&T. In the route-map command reference section, the description for set ip next-hop states: "If you specify an IP address, the router transmits the packet to the specified next hop. This next hop must be on a directly attached network." The description for set ip next-hop recursive states: "Specifies a recursive next-hop IP address... The recursive next-hop is not required to be a connected next-hop... If the routing table has no entry for the specified next hop, the router forwards the packet by using the default routing table." This directly supports the use of recursive for non-adjacent next-hops and the failover behavior.

2. Cisco Systems, "IP Addressing: BGP Configuration Guide, Cisco IOS XE Release 3S," Chapter: "Configuring Policy-Based Routing". This guide explains, "Policy-based routing (PBR) provides a mechanism for expressing and implementing forwarding and routing policies... When a PBR next hop is unreachable, the packet is routed using the destination-based routing lookup." This confirms the failover mechanism to the default route when the PBR path is unavailable.

3. Cisco Systems, "Cisco IOS Security Command Reference: Commands A to C," access-list (IP) command section. The documentation specifies the syntax for extended access lists as access-list access-list-number ... permit protocol source source-wildcard destination destination-wildcard. This confirms that a wildcard mask, not a subnet mask, is the correct syntax, invalidating options C and D.

A. This command is identical to the one in the exhibit and does not resolve the issue of using an insecure fallback method.

B. The none keyword is extremely insecure, as it would grant access without any authentication if TACACS+ and local methods fail.

D. This command configures the default authentication list, but the VTY lines are explicitly configured to use the named list admin, so this change would have no effect.

1. Cisco IOS XE Security Configuration Guide, Cisco IOS XE Fuji 16.9.x, "Configuring Authentication" section.

Reference: In the "How to Configure AAA" chapter, under the "Configuring Authentication" section, the documentation for the aaa authentication login command describes the method keywords.

Details: It defines enable as "Use the enable password for authentication. We recommend that you use this method only as the last resort in a method list." This supports the premise that using enable is a potential issue. It defines if-authenticated as a method that "Succeeds if the user is already authenticated," which in a new login sequence will fail if prior methods fail, thus providing a secure failure.

2. Cisco IOS Security Command Reference, "aaa authentication login" command documentation.

Reference: The command reference provides the syntax and usage guidelines for aaa authentication login.

Details: The entry for the enable keyword states it uses the password set with the enable password command. The entry for if-authenticated specifies its use is "to allow users that are already authenticated access... without reauthentication." This confirms that if a user is not yet authenticated, this method will fail, preventing the insecure fallback seen in the original configuration.

3. Cisco IOS Security Configuration Guide: Securing User Services, Release 12.4T, "Configuring Authentication" section.

Reference: In the "Login Authentication Methods" table.

Details: This document outlines the various authentication methods. The description for applying method lists to lines (e.g., login authentication list-name) confirms that the list specified on the line (admin in this case) is what will be used, making option D's modification of the default list incorrect as it would not be applied to the VTY lines.

A. Configuring ASPATH prepend for the desired best path would make its path longer and thus less preferable, achieving the opposite of the goal.

B. BGP prefers a lower Multi-Exit Discriminator (MED) value. Configuring a higher MED on the desired path would make it less preferable.

C. BGP prefers a higher Local Preference (LOCALPREF) value. Configuring a lower LOCALPREF on the desired path would make it less preferable.

---

1. Cisco Systems, Inc., "BGP Best Path Selection Algorithm," IP Routing: BGP Configuration Guide, Cisco IOS Release 15M&T. This document outlines the BGP decision process. Step 5 states, "Prefer the path with the shortest ASPATH." This confirms that increasing the ASPATH length of the current best path will make it less preferred.

Reference Location: Section: "BGP Best Path Selection Algorithm," Step 5.

2. Lacoste, R., & Edgeworth, B. (2020). Implementing Cisco Enterprise Advanced Routing and Services (ENARSI) v1.0 Official Cert Guide. Cisco Press. Chapter 4, "Manipulating BGP Path Selection," discusses using AS path prepending for outbound traffic engineering.

Reference Location: Chapter 4, section "AS Path Prepending," states, "AS path prepending is the process of adding one or more AS numbers to the beginning of the AS path to make the path longer and, therefore, less desirable to other BGP routers." This directly supports the logic for choosing option D.

3. Kurose, J. F., & Ross, K. W. (2021). Computer Networking: A Top-Down Approach (8th ed.). Pearson. The textbook explains BGP route selection policies.

Reference Location: Chapter 5, Section 5.6.3, "Determining the Best Routes," explains that a router will "use the AS-PATH attribute to determine the shortest path" and that an AS can "prepend its AS number multiple times... This has the effect of making the path look longer and therefore less desirable."

A. The label is bound to a Forwarding Equivalence Class (FEC), which is a destination prefix, not directly to a neighboring router.

B. MPLS forwarding decisions are based on the destination of the packet, so labels are bound to destination prefixes, not source prefixes.

D. This describes an LDP session or adjacency, which is the communication channel used to exchange label bindings, not the binding itself.

1. RFC 5036: LDP Specification, Internet Engineering Task Force (IETF).

Section 1.1, "LDP Overview," Paragraph 1: "LDP is a protocol that defines a set of procedures and messages by which one Label Switching Router (LSR) informs another of the label bindings it has made."

Section 2.1, "Forwarding Equivalence Classes (FECs)," Paragraph 1: "An important example of a FEC is a set of IP unicast prefixes." This section explicitly links FECs, which are bound to labels, with destination prefixes.

2. Cisco IOS XE MPLS Configuration Guide, Release 17.x, Cisco Systems.

Chapter: MPLS Label Distribution Protocol (LDP), Section: MPLS Label Distribution Protocol (LDP) Overview: "LDP associates a Forwarding Equivalence Class (FEC) with a label. The FEC is a group of IP packets that are forwarded in the same manner... In the case of Cisco MPLS, a FEC is a destination IP subnet." This document directly states that a FEC, which is bound to a label, corresponds to a destination prefix.

A. RIB: The Routing Information Base (RIB) is a control-plane table that stores routes learned from routing protocols; it is a precursor to the forwarding table but does not directly map packets to LSPs.

C. LDP: The Label Distribution Protocol (LDP) is a signaling protocol used by LSRs to advertise and exchange FEC-to-label bindings, not a data structure used for packet mapping itself.

D. CEF: Cisco Express Forwarding (CEF) is a high-performance forwarding architecture. Its Forwarding Information Base (FIB) is built using information about FECs, but the FEC is the actual classification that groups the packets.

1. IETF RFC 3031, "Multiprotocol Label Switching Architecture":

Section 2.1, "Forwarding Equivalence Classes": "An FEC is a group of packets which are forwarded in the same manner (e.g., over the same path, with the same forwarding treatment)." This foundational document defines FEC as the group of packets receiving identical forwarding treatment.

2. Cisco IOS XE Fuji 16.9.x Documentation, "IP Switching: CEF Configuration Guide":

Chapter: "MPLS Label Switching": "A Forwarding Equivalence Class (FEC) is a group of IP packets that are forwarded in the same manner (for example, over the same path or with the same forwarding treatment). The router assigns a packet to a particular FEC at the ingress to the MPLS network." This official vendor documentation directly aligns with the IETF definition and the explanation provided.

3. Cisco IOS XE Release 3S Documentation, "MPLS Configuration Guide":

Chapter: "MPLS Basic Configuration", Section: "MPLS Forwarding": "The ingress router determines the forwarding equivalence class (FEC) for the packet and applies a label that corresponds to the FEC. At subsequent hops in the MPLS network, the routers and switches use the label to forward the packet." This confirms that the FEC is the basis for mapping packets to a label and a specific treatment path.

A. This is a classic EIGRP configuration that applies only to the global routing table, not the "Science" VRF where the interfaces reside.

B. This named EIGRP configuration lacks the vrf Science keyword, so it would incorrectly apply to the global routing table instead of the VRF.

C. This configuration uses invalid syntax. The vrf Science command is not a valid subcommand directly under the classic router eigrp 111 configuration mode.

1. Cisco Systems, Inc. (2023). IP Routing: EIGRP Configuration Guide, Cisco IOS XE Bengaluru 17.6.x.

Section: "Configuring EIGRP Named Mode" and "EIGRP VRF-Lite"

Details: This guide explicitly documents the required syntax. The configuration example for EIGRP VRF-Lite shows the structure: router eigrp , followed by address-family ipv4 vrf autonomous-system , and then the network commands within that address family. This directly validates the syntax and logic of the correct answer (D).

2. Cisco Systems, Inc. (2023). IP Routing: EIGRP Command Reference.

Command: address-family (EIGRP)

Details: The command reference specifies the syntax as address-family {ipv4 | ipv6} [vrf vrf-name] autonomous-system as-number. This confirms that the vrf parameter is required to associate the address family with a specific VRF, making option D correct and option B incorrect.

3. Gai, R., & Edgeworth, B. (2020). CCNP Enterprise Advanced Routing ENARSI 300-410 Official Cert Guide. Cisco Press.

Chapter 4: EIGRP, Section: "EIGRP for VRF-Lite"

Details: This official guide explains that for VRF-aware EIGRP, the configuration must be done within an address-family specific to the VRF. It provides examples identical in structure to option D, confirming it as the standard method for configuring EIGRP in a multi-VRF environment. It also clarifies that classic mode configuration (Option A) affects only the global routing instance.

A. This suggests changing the operational mode of FTP rather than fixing the configuration issue preventing passive FTP from working.

B. The rule for port 20 (ftp-data) is relevant for active FTP, not passive FTP. Modifying it does not solve the issue of blocked high ports.

C. Changing the ACL's direction from in to out does not change the fact that the rules within the ACL are incorrect for allowing passive FTP traffic.

1. RFC 959, File Transfer Protocol (FTP), Section 4.1.3, "PASV (Passive)". This official standard specifies that for a passive transfer, the server "listens on a data port (which is not its default data port) and waits for a connection rather than initiating one upon receipt of a transfer command." The server provides the port number, which is typically a high port, for the client to connect to.

2. Cisco IOS XE Security Configuration Guide, Release 17.x, "Configuring IP Access Lists" section. This guide details the creation and application of extended TCP access lists. The scenario demonstrates a standard extended ACL that filters traffic based on destination TCP ports. The failure occurs because the ACL lacks a permit statement for the TCP port range used by the passive FTP data connection (e.g., permit tcp any host 10.10.10.10 gt 1023).

3. Kurose, J. F., & Ross, K. W. (2021). Computer Networking: A Top-Down Approach (8th ed.). Pearson. In Chapter 2, Section 2.5 "File Transfer Protocol: FTP," the text explains the control and data connections for both active and passive FTP. It clarifies that for passive FTP, the client initiates the data connection to a port number provided by the server, which is a critical detail for configuring firewalls and access lists.

A. ip nhrp map dynamic: This is a hub-side command used to dynamically accept NHRP registration requests from spokes; it does not enable spoke-to-spoke communication on the spokes themselves.

C. ip nhrp nhs multicast: This is a hub-side command that statically maps multicast traffic to the Next Hop Server (NHS) for replication to spokes.

D. ip nhrp redirect: This is a hub-side command that instructs the hub to send redirect messages to spokes; the spoke requires ip nhrp shortcut to process these messages.

1. Cisco Systems, Inc. (2017). IP Addressing: NHRP Configuration Guide, Cisco IOS XE Release 3S. In the "NHRP Redirect" section, it is stated: "The ip nhrp redirect command is configured on the hub... The ip nhrp shortcut command is configured on the spokes." This source clarifies the distinct roles and locations for these two related commands.

2. Cisco Systems, Inc. (2014). DMVPN Phase 3. The "DMVPN Phase 3 Spoke Configuration" section in this design guide shows ip nhrp shortcut as a standard command on the spoke tunnel interface to enable the creation of dynamic spoke-to-spoke tunnels.

3. Cisco Systems, Inc. Cisco IOS IP Addressing Services Command Reference. The entry for the ip nhrp shortcut command states its purpose is to "enable NHRP shortcut switching on a spoke," which allows the router to bypass the hub and forward traffic directly.

A: A virtual link through Area 1 is incorrect. A virtual link's transit area must be a common non-backbone area, and its purpose is to connect to the backbone.

B: Configuring stub areas is invalid. Standard stub areas do not permit ASBRs, as they block Type-5 LSAs (external routes) by design.

C: Configuring Not-So-Stubby Areas (NSSA) allows ASBRs but does not solve the underlying inter-area reachability problem if the backbone itself is partitioned.

1. Cisco Systems, "OSPF Design Guide," Document ID: 13690, Updated January 29, 2008. In the section "Connecting Areas to the Backbone Area," it states, "All areas must be connected to the backbone area... If it is not possible to have an area physically connected to the backbone, you can use a virtual link to connect to the backbone through a non-backbone area... Virtual links can also be used to connect two parts of a partitioned backbone through a non-backbone area." This confirms a virtual link is the solution for a partitioned backbone.

2. Cisco IOS IP Routing: OSPF Command Reference, "area virtual-link." The documentation describes the area area-id virtual-link router-id command. It is used to "define an OSPF virtual link." The area-id is specified as the "transit area." The scenario in the question points to a partitioned backbone, which requires a virtual link for resolution.

3. Cisco Systems, "IP Routing: Protocol-Independent Configuration Guide, Cisco IOS XE Release 3S," Chapter: OSPF. In the section "Not-So-Stubby Areas," it is explained that NSSA is a feature to allow a limited import of external routes into a stub area, but it does not address backbone connectivity issues. This supports why option C is incorrect.

A: The route-map in this option uses a permit statement for the specific routes, which would achieve the opposite of the goal by explicitly allowing them to be redistributed.

C: The summary-address command is not a valid command under the router eigrp configuration mode. The correct command, ip summary-address eigrp, is configured on an interface and does not apply to redistributed routes.

D: The summary-address command under the router ospf process is used on an Autonomous System Boundary Router (ASBR) to summarize external routes within OSPF, not during redistribution into another protocol like EIGRP.

1. Cisco Press, CCNP and CCIE Enterprise Core ENCOR 350-401 Official Cert Guide. Chapter 13, "Route Redistribution," section "Summarizing During Redistribution." This section states, "To summarize, you must filter the more specific routes and advertise only a summary route... The most common way to do this is to create a static route for the summary address that points to the null0 interface... and then redistribute the static route." This directly supports the methodology used in Option B.

2. Cisco IOS IP Routing: EIGRP Configuration Guide, "Configuring EIGRP" chapter. The documentation for the ip summary-address eigrp command specifies its use on an interface to summarize routes learned via EIGRP, confirming it is not intended for summarizing external, redistributed routes. This invalidates the logic in Option C.

3. Cisco IOS IP Routing: OSPF Configuration Guide, "Configuring OSPF Route Summarization" section. This guide explains that the summary-address command under router ospf is for creating an aggregate address for OSPF, typically on an ASBR. This confirms the command's purpose is internal to OSPF and not for controlling redistribution into other protocols, making Option D incorrect.

A. The ip nhrp redirect command is configured on the DMVPN hub, not the spoke. A spoke uses ip nhrp shortcut to process redirects.

C. This option incorrectly uses two hub-side commands: ip nhrp redirect and ip nhrp map multicast dynamic. Spokes must statically map multicast to the hub.

D. The ip nhrp map multicast dynamic command is used on the hub to dynamically learn spoke mappings, not on the spoke itself.

1. Cisco Systems, Inc., IP Addressing: NHRP Configuration Guide, Cisco IOS XE Gibraltar 16.12.x, "DMVPN Phase 3" section. The guide states, "The ip nhrp redirect command must be configured on the hub. The ip nhrp shortcut command must be configured on the spokes."

2. Cisco Systems, Inc., Cisco IOS IP Addressing Services Command Reference, "ip nhrp shortcut" command documentation. Under Usage Guidelines, it specifies, "This command should be configured on spoke routers in a DMVPN network to enable the NHRP shortcut switching feature."

3. Cisco Systems, Inc., Cisco IOS IP Addressing Services Command Reference, "ip nhrp redirect" command documentation. The Usage Guidelines state, "This command should be configured on hub routers in a DMVPN network."

4. Cisco Systems, Inc., Dynamic Multipoint VPN (DMVPN) Design and Implementation Guide, "DMVPN Phase 3" section, Spoke Configuration Example. The example configuration for a spoke router includes ip nhrp shortcut and a static ip nhrp map multicast command.

A – ACL matches source port 23 (“any eq 23 any”), so packets initiated by users (source port >1023) never hit the TELNET class.

B – Uses “permit tcp any eq 23 any”; still matches source port, so Telnet to the router bypasses CoPP.

C – Class map references an undefined/empty ACL, therefore no traffic is classified and policing is ineffective.

1. Cisco IOS XE Security Configuration Guide, “Control Plane Policing: Example for policing Telnet” – Example shows “access-list 100 permit tcp any any eq telnet” (Destination-port match). (17.x, section: Configuring CoPP)

2. Cisco Press, CCNP Enterprise Advanced Routing ENARSI Official Cert Guide, Ch. 27 “Implementing Control Plane Policing”, p. 572–573 – Explains correct ACL direction and common error of matching source port.

3. Cisco Live BRKSEC-3021 “Control Plane Protection”, slide 16 – Highlights need to classify by destination port for management protocols such as Telnet/SSH.

A. Using an ACL is an alternative to match protocol ospf. The existing match statement is valid and does not need to be replaced to solve the issue.

B. This command only changes the exceed-action of the policer. This is irrelevant if the policy is not applied and thus not processing any traffic.

D. This changes the matching criteria from protocol-based to ACL-based. The problem is not the matching method but the lack of policy application.

1. Cisco IOS Quality of Service Solutions Configuration Guide, Release 15M&T, "Configuring Control Plane Policing": This document outlines the necessary steps for CoPP configuration. In the section "How to Configure Control Plane Policing," the final and mandatory step is "Attaching a Service Policy to the Control Plane," which requires using the service-policy {input | output} policy-map-name command in control-plane configuration mode. This confirms that the policy is inactive without this command.

2. Cisco IOS XE Quality of Service Solutions Configuration Guide, Cisco IOS XE Gibraltar 16.12.x, "Control Plane Policing": In the "Configuration Examples for CoPP" section, every complete example demonstrates that after defining class-maps and policy-maps, the configuration is made active by applying it under the control-plane hierarchy with the service-policy input command. This highlights it as the essential activation step.

3. Cisco Press, "CCNP and CCIE Enterprise Core ENCOR 350-401 Official Cert Guide": Chapter 21, "Control Plane Security," details the CoPP framework. It explains the three-step process: 1) Classify traffic (with class-maps), 2) Define policy (with policy-maps), and 3) Apply the policy to the control plane using the service-policy command under the control-plane global configuration. The absence of step 3 renders the configuration ineffective.