Courseiva

Cisco CCNP ENARSI 300-410 (300-410) — Questions 451–525

2152 questions total · 29pages · All types, answers revealed

Take a mock examExam hub
Page 6

Page 7 of 29

Page 8
451
MCQhard

A network engineer is troubleshooting an IPsec site-to-site VPN where the tunnel is up and traffic is flowing, but the engineer notices that the 'show crypto ipsec sa' output shows the 'pkts encaps failed' counter incrementing slowly over time. The tunnel remains up. What is the most likely cause?

A.There is a floating static route that points to the physical interface instead of the tunnel for some subnets.
B.The crypto map is applied to the tunnel interface instead of the physical interface.
C.The IPsec SA lifetime is set too high.
D.The access list in the crypto map is too restrictive and missing some subnets.
AnswerA

Correct because if a floating static route (with a higher administrative distance) becomes active for some traffic, those packets will be sent out the physical interface without encryption, causing encapsulation failures.

Why this answer

A slow but steady increase in 'pkts encaps failed' indicates that some packets that should be encrypted are not being encrypted. This is often caused by a routing issue where some traffic to the remote LAN is being routed out an interface that does not have the crypto map, bypassing encryption.

Full explanation →
452
MCQmedium

snmp-server community public RO\nsnmp-server community private RW\nsnmp-server location DataCenter\nsnmp-server contact admin@example.com What is the effect of this configuration?

A.SNMPv3 is enabled with authentication.
B.SNMPv2c is enabled with read-only community 'public' and read-write community 'private'.
C.Only read-only access is allowed using the 'private' community.
D.SNMP traps are enabled to the location DataCenter.
AnswerB

The 'snmp-server community' commands define SNMPv2c community strings with specified access levels.

Why this answer

The configuration uses SNMPv2c community strings 'public' (read-only) and 'private' (read-write), which are plain-text authentication mechanisms. SNMPv2c is enabled by default when community strings are configured, and the 'RO' and 'RW' keywords explicitly define the access levels. This matches option B exactly.

Exam trap

Cisco often tests the distinction between SNMP versions by hiding the version keyword; candidates assume SNMPv3 is in use when they see 'community', but community strings are exclusive to SNMPv1/v2c.

How to eliminate wrong answers

Option A is wrong because SNMPv3 requires 'snmp-server group' and 'snmp-server user' commands with authentication/hash parameters, not community strings. Option C is wrong because the 'private' community is configured with RW (read-write) access, not read-only. Option D is wrong because 'snmp-server location' sets the sysLocation MIB object, not trap destinations; traps require 'snmp-server host' and 'snmp-server enable traps' commands.

Full explanation →
453
MCQmedium

Examine this BGP configuration on router R3: router bgp 65001 neighbor 10.1.1.1 remote-as 65002 address-family ipv4 network 192.168.0.0 mask 255.255.252.0 aggregate-address 192.168.0.0 255.255.252.0 summary-only What is the effect of the 'aggregate-address' command with the 'summary-only' keyword?

A.It advertises the aggregate 192.168.0.0/22 and suppresses all more specific routes from being advertised to neighbor 10.1.1.1.
B.It advertises both the aggregate and all more specific routes.
C.It creates a static route for the aggregate.
D.It removes all more specific routes from the BGP table.
AnswerA

Correct. The summary-only keyword ensures only the aggregate is advertised, not the specifics.

Why this answer

The aggregate-address command creates an aggregate route in BGP. The summary-only keyword suppresses more specific routes from being advertised.

Full explanation →
454
MCQeasy

A network engineer runs the following command to verify NAT after a fix: R1# show ip nat translations Pro Inside global Inside local Outside local Outside global --- 203.0.113.1 10.1.1.1 192.168.1.1 192.168.1.1 --- 203.0.113.2 10.1.1.2 192.168.1.2 192.168.1.2 What is the most likely configuration?

A.Dynamic NAT without overload, using a pool of addresses.
B.Static NAT for each host.
C.PAT with a single address.
D.NAT is not configured.
AnswerA

Each inside host gets a unique global address from a pool.

Why this answer

The output shows two inside local addresses (10.1.1.1 and 10.1.1.2) translated to two different inside global addresses (203.0.113.1 and 203.0.113.2), with no port numbers listed in the 'Pro' column. This indicates a one-to-one mapping without port address translation, which is characteristic of dynamic NAT using a pool of addresses (not overloaded).

Exam trap

Cisco often tests the distinction between dynamic NAT and PAT by showing translation output without port numbers, leading candidates to mistakenly think it is static NAT or PAT with a single address.

How to eliminate wrong answers

Option B is wrong because static NAT would show a persistent one-to-one mapping in the configuration, but the output does not indicate static entries (which would typically appear with '---' but are manually configured and not dynamically learned). Option C is wrong because PAT (overload) would show multiple translations sharing the same inside global address with different port numbers in the 'Pro' column, which is absent here. Option D is wrong because the output clearly shows active translations, proving NAT is configured and operational.

Full explanation →
455
Multi-Selecthard

Which TWO statements about IPv6 unicast RPF (uRPF) behavior in Cisco IOS-XE are correct? (Choose TWO.)

Select 2 answers
A.Strict mode uRPF drops packets if the source address is not reachable via the incoming interface.
B.Loose mode uRPF drops packets if the source address is not present in the FIB at all.
C.The default uRPF mode on Cisco IOS-XE is strict mode.
D.IPv6 uRPF can be applied globally using the 'ipv6 unicast-rpf' command.
E.uRPF checks both source and destination addresses in the IPv6 header.
AnswersA, B

Correct. Strict mode requires the source prefix to be reachable via the exact incoming interface.

Why this answer

Option A is correct because IPv6 unicast RPF strict mode verifies that the source address of an incoming packet is reachable via the exact interface on which the packet arrived, according to the FIB. If the source address is not reachable through that interface, the packet is dropped. This prevents spoofed traffic from entering the network from an unexpected path.

Exam trap

Cisco often tests the misconception that uRPF is enabled by default or that it can be applied globally, when in fact it is an interface-level feature that must be explicitly configured per interface.

Full explanation →
456
MCQhard

A network engineer runs the following command on Router R1: R1# show bgp ipv4 unicast 10.10.10.0/24 BGP routing table entry for 10.10.10.0/24, version 5 Paths: (1 available, best #1, table default) Advertised to update-groups: 1 Refresh Epoch 1 Local 10.1.1.2 from 10.1.1.2 (10.2.2.2) Origin IGP, metric 0, localpref 100, valid, external, best rx pathid: 0, tx pathid: 0x0 (received-only) Based on this output, what does the "(received-only)" flag indicate?

A.The route is received but not installed in the routing table, likely due to a route-map filtering.
B.The route is best and installed in the routing table.
C.The route is suppressed by a route-map.
D.The route is being advertised to neighbors.
AnswerA

The received-only flag means the route is not used, often due to filtering.

Why this answer

The "(received-only)" flag indicates that the route was received from a neighbor but is not installed in the routing table, often due to a route-map filtering or a prefix-list. The correct answer is that a route-map is likely filtering this route from being installed.

Full explanation →
457
MCQhard

R1 and R2 are connected via an IPsec VPN tunnel. They are running EIGRP over the tunnel. R1's show ip eigrp neighbors shows R2 as up, but R1's show ip eigrp topology shows a route from R2 as 'stuck-in-active' (SIA). R1's show ip eigrp traffic shows queries being sent but no replies. What is the root cause?

A.The IPsec tunnel is not encrypting EIGRP multicast traffic, causing queries to be dropped.
B.EIGRP split-horizon is enabled on the tunnel interface.
C.The EIGRP active timer is set too low.
D.R2 has a passive interface for the tunnel.
AnswerA

EIGRP queries are sent to multicast address 224.0.0.10. If the crypto map does not protect multicast traffic, queries may be dropped, leading to SIA.

Why this answer

The correct answer is A because EIGRP uses multicast address 224.0.0.10 for neighbor discovery and route updates. If the IPsec VPN tunnel is misconfigured to not encrypt multicast traffic (e.g., using an ACL that only matches unicast or specific protocols), the EIGRP queries sent as multicast packets will be dropped by the IPsec process or the remote router, preventing replies. This results in the neighbor appearing up (due to unicast keepalives or a stale state) but routes stuck-in-active because queries are never answered.

Exam trap

Cisco often tests the misconception that a neighbor being 'up' in 'show ip eigrp neighbors' guarantees full EIGRP communication, when in fact the neighbor state can remain up due to unicast keepalives or a stale hold timer while multicast-based queries are blocked by IPsec ACLs.

How to eliminate wrong answers

Option B is wrong because EIGRP split-horizon prevents routes learned on an interface from being advertised back out the same interface, which could cause routing loops but does not cause queries to go unanswered or SIA routes; split-horizon does not block query transmission or reception. Option C is wrong because setting the EIGRP active timer too low would cause the route to transition to SIA faster, but the root cause here is that queries are sent and no replies are received, not that the timer expires prematurely; a low timer would still require replies to be sent. Option D is wrong because if R2 had a passive interface for the tunnel, R2 would not send or receive EIGRP hellos, so the neighbor adjacency would not form at all; the question states the neighbor is up, ruling out passive interface.

Full explanation →
458
MCQmedium

Consider the following partial DMVPN configuration on a hub router: interface Tunnel0 ip address 10.0.0.1 255.255.255.0 ip nhrp network-id 100 ip nhrp authentication cisco123 tunnel source GigabitEthernet0/0 tunnel mode gre multipoint ip nhrp map multicast dynamic ! What is the effect of this configuration?

A.The hub will dynamically register spoke NHRP addresses and forward multicast traffic to all registered spokes.
B.The hub will only forward multicast traffic to spokes that are statically mapped.
C.The hub will not forward multicast traffic at all because dynamic mapping is not supported.
D.The hub will use broadcast instead of multicast for all traffic.
AnswerA

This is correct; dynamic multicast mapping enables the hub to forward multicast to all spokes that have registered with NHRP.

Why this answer

The command 'ip nhrp map multicast dynamic' allows the hub to dynamically learn spoke NHRP addresses for multicast replication, which is essential for routing protocols (e.g., EIGRP, OSPF) that use multicast.

Full explanation →
459
MCQhard

A network engineer runs the following command on Router R1: R1# show ipv6 interface gigabitethernet 0/0 GigabitEthernet0/0 is up, line protocol is up IPv6 is enabled, link-local address is FE80::1 Global unicast address(es): 2001:DB8:1:1::1, subnet is 2001:DB8:1:1::/64 Joined group address(es): FF02::1 FF02::2 ICMP redirects are enabled ICMP unreachables are enabled ND DAD is enabled, number of DAD attempts: 1 ND reachable time is 30000 milliseconds ND advertised reachable time is 0 milliseconds ND advertised retransmit interval is 1000 milliseconds ND router advertisements are sent every 200 seconds ND router advertisements live for 1800 seconds Hosts use stateless autoconfig for addresses. IPv6 uRPF: strict mode (drop invalid packets) Inbound access list: FILTER-IPv6 Based on this output, which two features are configured on this interface?

A.uRPF in strict mode and inbound IPv6 ACL
B.uRPF in loose mode and outbound IPv6 ACL
C.uRPF disabled and inbound IPv6 ACL
D.uRPF in strict mode and outbound IPv6 ACL
AnswerA

Both are clearly shown in the output.

Why this answer

The output shows 'IPv6 uRPF: strict mode (drop invalid packets)' and 'Inbound access list: FILTER-IPv6', confirming that unicast Reverse Path Forwarding in strict mode and an inbound IPv6 ACL are both configured on the interface. Strict uRPF verifies that the source address of incoming packets has a matching route in the FIB pointing back to the same interface, dropping packets that fail this check. The inbound ACL filters traffic before any routing decision, as indicated by the 'Inbound access list' line.

Exam trap

Cisco often tests the distinction between strict and loose uRPF modes, and the trap here is that candidates may overlook the 'Inbound access list' line and assume the ACL is outbound, or confuse the uRPF mode with the ACL direction.

How to eliminate wrong answers

Option B is wrong because the output explicitly states 'IPv6 uRPF: strict mode', not loose mode, and the ACL is applied inbound, not outbound. Option C is wrong because uRPF is not disabled; it is enabled in strict mode. Option D is wrong because while uRPF is correctly identified as strict mode, the ACL is applied inbound, not outbound.

Full explanation →
460
MCQhard

A network engineer runs the following command to verify OSPFv3 database: R1# show ipv6 ospf database router 2.2.2.2 OSPFv3 Router with ID (1.1.1.1) (Process ID 1) Router Link States (Area 0) LS age: 60 LS Type: Router Links Link State ID: 0.0.0.0 Advertising Router: 2.2.2.2 LS Seq Number: 80000003 Checksum: 0x5678 Length: 40 Number of Links: 1 Link connected to: a Transit Network (Link ID) Interface ID: 2 (Link Data) Neighbor Interface ID: 1 Number of TOS metrics: 0 TOS 0 Metrics: 10 What does this output indicate?

A.The LSA shows a link to a stub network with prefix information.
B.The LSA indicates a single transit link with interface IDs, typical for OSPFv3.
C.The advertising router is 1.1.1.1.
D.This is a Type 5 External LSA.
AnswerB

OSPFv3 uses interface IDs to identify links, and this LSA shows one transit link.

Why this answer

The output shows an OSPFv3 Router LSA from router 2.2.2.2 with one link to a transit network, using interface IDs instead of IP addresses.

Full explanation →
461
MCQeasy

What is the default behavior of LDP when establishing a session between two directly connected routers?

A.LDP sends hellos to the unicast address of each neighbor.
B.LDP uses TCP port 646 for session establishment and UDP port 646 for hellos.
C.LDP hellos are sent to the all-OSPF-routers multicast address 224.0.0.5.
D.LDP sessions are established using UDP for reliability.
AnswerB

LDP uses UDP port 646 for hello messages (discovery) and TCP port 646 for session establishment and label exchange.

Why this answer

LDP uses hello messages to discover neighbors. By default, LDP hellos are sent to the multicast address 224.0.0.2 (all routers) on the local link. The session is established using the transport address, which by default is the router ID (usually the highest loopback or interface IP).

Full explanation →
462
MCQeasy

What is the default tunnel mode for a tunnel interface on Cisco IOS?

A.tunnel mode ipv6ip
B.tunnel mode gre ip
C.tunnel mode gre ipv6
D.tunnel mode mpls traffic-eng
AnswerB

GRE over IPv4 is the default.

Why this answer

The default tunnel mode on Cisco IOS is GRE (Generic Routing Encapsulation) over IPv4, configured with the command `tunnel mode gre ip`. This mode encapsulates packets using the GRE protocol (RFC 2784) with an IPv4 transport header, and it is the default when no explicit tunnel mode is specified. GRE ip supports multiprotocol payloads (IPv4, IPv6, etc.) and is widely used for site-to-site VPNs and overlay networks.

Exam trap

Cisco often tests the assumption that the default tunnel mode is IPv6-in-IPv4 or GRE over IPv6, but the actual default is GRE over IPv4, which catches candidates who overlook the implicit IPv4 transport requirement.

How to eliminate wrong answers

Option A is wrong because `tunnel mode ipv6ip` is used for IPv6-in-IPv4 manual tunneling, not the default; it requires explicit configuration and does not use GRE encapsulation. Option C is wrong because `tunnel mode gre ipv6` is a valid mode for GRE over IPv6 transport, but it is not the default; the default transport is IPv4, not IPv6. Option D is wrong because `tunnel mode mpls traffic-eng` is used for MPLS Traffic Engineering tunnels, not for generic IP tunneling, and it is not the default tunnel mode.

Full explanation →
463
MCQeasy

What is the default SNMPv2c community string on most Cisco IOS devices?

A.public
B.private
C.cisco
D.No default community string is configured.
AnswerA

Many Cisco devices come with a default 'public' community string for read-only access.

Why this answer

The default SNMPv2c community string on most Cisco IOS devices is 'public' for read-only access. This is a well-known default that allows basic SNMP polling without additional configuration, as defined in Cisco's default configuration for SNMP agents.

Exam trap

Cisco often tests the default SNMP community string to catch candidates who assume 'private' is the default for read-write or that no default exists, exploiting the common confusion between vendor defaults and best-practice security hardening.

How to eliminate wrong answers

Option B is wrong because 'private' is not a default community string on Cisco IOS; it is sometimes used as a default for read-write access on other vendors but not Cisco. Option C is wrong because 'cisco' is not a default community string; it is a common misconception but Cisco devices do not ship with this as a default. Option D is wrong because a default community string of 'public' is indeed configured on most Cisco IOS devices for SNMPv2c, so stating no default is incorrect.

Full explanation →
464
MCQhard

In a manual IPv6 over IPv4 tunnel (tunnel mode ipv6ip), what is the default maximum number of hops (TTL) for the IPv4 header?

A.64
B.128
C.255
D.16
AnswerC

The default TTL is 255 for manual IPv6 over IPv4 tunnels.

Why this answer

In a manual IPv6 over IPv4 tunnel (tunnel mode ipv6ip), the IPv4 header's TTL (Time to Live) defaults to 255. This is because the tunnel is treated as a directly connected virtual link, and the IPv4 TTL is set to the maximum value of 255 to minimize the chance of the tunneled packet being dropped due to TTL expiry within the transit IPv4 network. This behavior is defined in RFC 2473 and is the default for IPv6-in-IPv4 tunnels on Cisco IOS.

Exam trap

Cisco often tests the distinction between the default TTL values for IPv6 (64) and the outer IPv4 header in a manual IPv6 over IPv4 tunnel (255), leading candidates to mistakenly choose 64 or 128.

How to eliminate wrong answers

Option A is wrong because 64 is the default TTL for IPv6 packets, not for the IPv4 header in a manual IPv6 over IPv4 tunnel. Option B is wrong because 128 is the default TTL for IPv4 packets on many operating systems (e.g., Windows), but Cisco routers set the IPv4 TTL to 255 for tunnel mode ipv6ip. Option D is wrong because 16 is a common default for certain routing protocols (e.g., RIP), but it is not the default TTL for the IPv4 header in this tunnel type.

Full explanation →
465
MCQhard

What is the default DHCPv6 client DUID type on a Cisco IOS-XE router?

A.DUID-LLT (Link-Layer plus Time)
B.DUID-EN (Enterprise Number)
C.DUID-LL (Link-Layer)
D.DUID-UUID (Universally Unique Identifier)
AnswerC

Cisco IOS-XE defaults to DUID-LL for DHCPv6 clients.

Why this answer

Cisco IOS-XE routers default to DUID-LL (Link-Layer) as the DHCPv6 client DUID type, as defined in RFC 8415. This DUID is generated using the router's link-layer address (MAC address) without a timestamp, making it stable across reboots. The DUID-LL is the default because it provides a consistent identifier without requiring clock synchronization or enterprise registration.

Exam trap

Cisco often tests the default DUID type by contrasting it with DUID-LLT, leading candidates to mistakenly choose DUID-LLT because they recall that DHCPv6 clients can use a time-based identifier, but they forget that Cisco defaults to the simpler, non-timestamped DUID-LL.

How to eliminate wrong answers

Option A is wrong because DUID-LLT (Link-Layer plus Time) includes a timestamp, which is not the default on Cisco IOS-XE; it is used by some other vendors but Cisco defaults to DUID-LL. Option B is wrong because DUID-EN (Enterprise Number) requires an enterprise number assigned by IANA and is not the default; it is used only when explicitly configured with the 'duid enterprise-number' command. Option D is wrong because DUID-UUID (Universally Unique Identifier) is not a standard DUID type defined in RFC 8415 for DHCPv6; it is a common misconception from other contexts like system identification.

Full explanation →
466
MCQmedium

A network engineer runs the following command on Router R1: R1# show ip bgp 192.168.0.0 255.255.252.0 BGP routing table entry for 192.168.0.0/22, version 5 Paths: (1 available, best #1, table default) Advertised to update-groups: 1 Refresh Epoch 1 65001 10.1.1.1 from 10.1.1.1 (10.1.1.1) Origin IGP, metric 0, localpref 100, valid, external, best Community: 65001:100 rx pathid: 0, tx pathid: 0x0 Aggregator: 65001, 10.1.1.1 Based on this output, what is true about this route?

A.The route is a summary route aggregated by 10.1.1.1.
B.The route is a learned route from AS 65002.
C.The route is a default route.
D.The route is suppressed.
AnswerA

The Aggregator field shows 65001, 10.1.1.1, indicating this route is an aggregate.

Why this answer

The presence of 'Aggregator' indicates route summarization (aggregation) was performed by the router with IP 10.1.1.1 in AS 65001.

Full explanation →
467
MCQmedium

Which default IPsec transform set is automatically created in Cisco IOS when configuring a site-to-site VPN?

A.esp-aes 256 esp-sha-hmac
B.esp-3des esp-sha-hmac
C.No default transform set is created
D.esp-aes 128 esp-md5-hmac
AnswerC

Cisco IOS requires manual configuration of at least one transform set.

Why this answer

Cisco IOS does not automatically create any default IPsec transform set when configuring a site-to-site VPN. Transform sets must be explicitly defined using the `crypto ipsec transform-set` command, which specifies the encryption and authentication algorithms. The absence of a default ensures that administrators intentionally select the appropriate security parameters for their environment.

Exam trap

Cisco often tests the misconception that a default transform set exists, tempting candidates to select a common algorithm combination like `esp-aes 256 esp-sha-hmac` or `esp-3des esp-sha-hmac` as the default, when in fact no such default is automatically created.

How to eliminate wrong answers

Option A is wrong because `esp-aes 256 esp-sha-hmac` is not a default transform set; it is a valid user-defined transform set but must be manually configured. Option B is wrong because `esp-3des esp-sha-hmac` is also not a default; 3DES is a legacy algorithm that requires explicit configuration. Option D is wrong because `esp-aes 128 esp-md5-hmac` is not a default; MD5 is deprecated for security reasons and must be explicitly chosen if used.

Full explanation →
468
MCQmedium

A network engineer runs the following command on Router R1: R1# show policy-map control-plane Control Plane Service-policy input: CoPP-IN Class-map: CoPP-ICMP (match-all) 0 packets, 0 bytes 5 minute offered rate 0000 bps, drop rate 0000 bps Match: access-group 100 police: cir 8000 bps, bc 1500 bytes, be 1500 bytes conformed 0 packets, 0 bytes; actions: transmit exceeded 0 packets, 0 bytes; actions: drop violated 0 packets, 0 bytes; actions: drop Class-map: CoPP-SSH (match-all) 0 packets, 0 bytes 5 minute offered rate 0000 bps, drop rate 0000 bps Match: access-group 110 police: cir 16000 bps, bc 3000 bytes, be 3000 bytes conformed 0 packets, 0 bytes; actions: transmit exceeded 0 packets, 0 bytes; actions: drop violated 0 packets, 0 bytes; actions: drop Class-map: class-default (match-any) 1250 packets, 75000 bytes 5 minute offered rate 1000 bps, drop rate 0000 bps Match: any Based on this output, which statement is correct?

A.The CoPP policy is dropping all ICMP packets to the control plane.
B.The CoPP policy is not matching any packets for the CoPP-ICMP and CoPP-SSH classes.
C.The CoPP policy is rate-limiting SSH traffic to 16000 bps.
D.The CoPP policy is applied to the output direction.
AnswerB

The packet counters for both classes are zero, indicating no traffic matched these classes.

Why this answer

The output shows that the CoPP-ICMP and CoPP-SSH class-maps have zero packets matched (0 packets, 0 bytes), indicating that no traffic has been classified into these classes. This means the policy is not matching any ICMP or SSH packets, likely because the access-lists (100 and 110) are not correctly defined or applied, or the traffic is not reaching the control plane. Option B correctly identifies this lack of matching.

Exam trap

Cisco often tests the distinction between a configured policy and an active policy; candidates see police parameters and assume traffic is being policed, but the zero packet counters reveal that no classification is occurring, so the policy is effectively idle.

How to eliminate wrong answers

Option A is wrong because the CoPP-ICMP class shows 0 packets matched and 0 packets dropped, so no ICMP packets are being dropped; the policy is not affecting ICMP traffic at all. Option C is wrong because the CoPP-SSH class has 0 packets matched, meaning SSH traffic is not being rate-limited; the police cir 16000 bps is configured but never applied to any packets. Option D is wrong because the command 'show policy-map control-plane' and the output line 'Service-policy input: CoPP-IN' explicitly indicate the policy is applied to the input direction, not output.

Full explanation →
469
MCQmedium

Given this configuration on Router R6: ``` interface Tunnel0 ipv6 address 2001:DB8:8::1/64 tunnel source 2001:DB8:9::1 tunnel destination 2001:DB8:10::2 tunnel mode gre ipv6 tunnel path-mtu-discovery ``` What is the effect?

A.The tunnel will not work because path-mtu-discovery is not supported with GRE.
B.The tunnel will dynamically adjust the MTU based on the path MTU discovery.
C.The tunnel mode should be 'ipv6ip' for IPv6 transport.
D.The tunnel source and destination must be IPv4 addresses.
AnswerB

The 'tunnel path-mtu-discovery' command enables PMTUD for the tunnel.

Why this answer

The `tunnel path-mtu-discovery` command enables Path MTU Discovery (PMTUD) for the GRE tunnel, which dynamically determines the maximum MTU along the path to the tunnel destination and adjusts the tunnel interface's MTU accordingly. This prevents fragmentation issues by allowing the tunnel to use the smallest MTU in the path. Option B correctly identifies this behavior.

Exam trap

Cisco often tests the misconception that path-mtu-discovery is unsupported with GRE tunnels, but it is actually supported and commonly used to avoid fragmentation in overlay networks.

How to eliminate wrong answers

Option A is wrong because path-mtu-discovery is fully supported with GRE tunnels; it uses the DF bit and ICMPv6 Packet Too Big messages (or ICMPv4 Fragmentation Needed) to discover the path MTU. Option C is wrong because the tunnel mode 'gre ipv6' is correct for transporting IPv6 packets over an IPv6 transport network; 'ipv6ip' is used for IPv6-in-IPv4 tunnels, not for GRE over IPv6. Option D is wrong because the tunnel source and destination are IPv6 addresses (2001:DB8:9::1 and 2001:DB8:10::2), which is valid for a GRE tunnel operating over an IPv6 transport network.

Full explanation →
470
MCQmedium

An engineer configures NAT on a router with 'ip nat inside source list 1 pool POOL overload' where POOL contains 203.0.113.1-203.0.113.5. The inside hosts are 10.0.0.0/24. Traffic works, but the engineer notices that some hosts are assigned the same public IP and port, causing conflicts. 'Show ip nat translations' shows entries with the same inside global IP and port for different inside local hosts. What is the most likely cause?

A.The pool has only one IP address, and the router is reusing ports for different hosts.
B.The 'ip nat inside source' command is missing the 'overload' keyword.
C.The router is not performing PAT correctly because the ACL permits more than the pool can handle.
D.The router has a configuration that uses 'ip nat inside source static' for some hosts, conflicting with the dynamic pool.
AnswerD

Correct because if a static NAT entry maps a host to the same public IP as the pool, and the static entry does not use port translation, it can cause conflicts with dynamic entries.

Why this answer

Option D is correct because the scenario describes a PAT overload configuration where the pool has five IP addresses (203.0.113.1–203.0.113.5). If static NAT entries are also configured for some hosts, those static mappings reserve specific inside global IPs and ports, forcing the dynamic PAT process to reuse the same global IP and port for multiple inside local hosts when it runs out of unique combinations. This conflict causes the observed duplicate inside global IP and port entries in the translation table.

Exam trap

Cisco often tests the interaction between static NAT and dynamic PAT, where candidates mistakenly attribute the duplicate translation entries to PAT misconfiguration or pool exhaustion rather than recognizing that static entries consume resources and force reuse.

How to eliminate wrong answers

Option A is wrong because the pool contains five IP addresses, not one; a single-IP pool would still work with PAT (overload) and would not cause conflicts unless port exhaustion occurred, which is not indicated. Option B is wrong because the 'overload' keyword is present in the command, enabling PAT; without it, the router would not allow multiple hosts to share a single public IP, and the symptom would be a lack of translations for additional hosts, not duplicate IP/port entries. Option C is wrong because the ACL (list 1) permits the 10.0.0.0/24 network, which is exactly the size of the inside hosts; PAT correctly handles multiple hosts by using unique port numbers, and the pool size is sufficient—the issue is not ACL-to-pool mismatch but rather static entries consuming resources.

Full explanation →
471
MCQmedium

A network engineer runs the following command to troubleshoot an Administrative Distance issue: R1# show bgp ipv4 unicast 192.168.4.0/24 BGP routing table entry for 192.168.4.0/24, version 2 Paths: (1 available, best #1, table default) Advertised to update-groups: 1 Refresh Epoch 1 Local 10.1.1.2 from 10.1.1.2 (2.2.2.2) Origin IGP, metric 0, localpref 100, valid, external, best rx pathid: 0, tx pathid: 0x0 What does this output indicate?

A.The route is an internal BGP route with administrative distance 200.
B.The route is an external BGP route with administrative distance 20.
C.The route has a local preference of 200, making it preferred.
D.The route is not the best path because it is external.
AnswerB

The output shows 'external', and eBGP routes have a default AD of 20.

Why this answer

The output shows BGP route details including the path attributes. The administrative distance for BGP external routes is 20 by default, but this is not shown here. The output indicates the route is learned via eBGP and is the best path.

Full explanation →
472
MCQmedium

Consider the following CoPP configuration: class-map match-any COPP-ROUTING match protocol ospf match protocol eigrp match protocol bgp ! policy-map COPP-POLICY class COPP-ROUTING police 32000 conform-action transmit exceed-action drop class class-default police 64000 conform-action transmit exceed-action drop ! control-plane service-policy input COPP-POLICY What is a potential issue with this configuration?

A.The class-map uses match-any instead of match-all, which will cause incorrect matching.
B.The police rate of 32000 bps is too low for routing protocol traffic and may cause adjacency drops.
C.The 'match protocol' command is not supported in CoPP class-maps; only ACLs or DSCP/IP precedence can be used.
D.The policy-map must be applied to the control-plane with the 'output' keyword instead of 'input'.
AnswerC

Correct. CoPP only supports match access-group, match ip dscp, or match ip precedence. match protocol is not allowed.

Why this answer

Option C is correct because the 'match protocol' command is not supported in Control Plane Policing (CoPP) class-maps. CoPP operates on the control plane, which processes packets that are destined to the router itself; these packets are typically identified by ACLs, DSCP, or IP precedence values, not by protocol names like OSPF, EIGRP, or BGP. The 'match protocol' command is used in QoS policies applied to data-plane interfaces, not in control-plane service policies.

Exam trap

Cisco often tests the misconception that 'match protocol' can be used in CoPP class-maps because it is valid in data-plane QoS policies, but CoPP explicitly requires ACLs, DSCP, or IP precedence for classification.

How to eliminate wrong answers

Option A is wrong because 'match-any' is actually the correct and intended behavior for CoPP class-maps when you want to match any of the listed protocols; using 'match-all' would require all protocols to match simultaneously, which is not the goal. Option B is wrong because a police rate of 32000 bps (32 kbps) is not inherently too low for routing protocol traffic; routing protocol keepalives and updates are typically small and bursty, and the rate can be tuned based on network requirements—the issue is not the rate itself but the unsupported match criteria. Option D is wrong because CoPP is applied as a 'service-policy input' on the control-plane to police traffic entering the control plane from the data plane; applying it as 'output' would police traffic leaving the control plane, which is not the standard use case for protecting the router's CPU.

Full explanation →
473
MCQhard

A network engineer configures IP SLA with an ICMP echo operation to monitor a remote host. The engineer also configures a route map to set the next hop based on the IP SLA track object. The engineer notices that the route map is not applied to the routing table as expected. The show ip route shows the static route with the correct next hop, but the route map does not seem to affect the routing decision. Which is the most likely explanation?

A.The route map is not applied to the static route using the 'route-map' keyword under the 'ip route' command.
B.The IP SLA track object is not referenced in the route map.
C.The route map is configured with a match clause that does not match the static route.
D.The IP SLA operation is not reachable, so the route map is not triggered.
AnswerA

To use a route map with a static route, the route map must be referenced in the static route configuration; otherwise, it has no effect.

Why this answer

Route maps can be used with IP SLA tracking to modify route attributes, but the route map must be applied to the routing process or to the static route itself. If the route map is configured but not applied correctly, it will not affect the routing table. Additionally, route maps used with IP SLA tracking are typically applied to redistribution, not to static routes directly.

The most common edge case is that the route map is not applied to the static route using the 'route-map' keyword under the 'ip route' command.

Full explanation →
475
MCQhard

An engineer configures IPv6 Source Guard on a switch port with 'ipv6 verify source' and also enables 'ipv6 snooping' globally. A legitimate host on that port is unable to send traffic, and the switch logs show that packets are being dropped due to source address validation failure. The host has a static IPv6 address and the engineer has configured a static binding using 'ipv6 neighbor binding' command. What is the most likely oversight?

A.The static binding must be associated with a valid ND entry; without an NA from the host, the binding remains incomplete.
B.The 'ipv6 verify source' command must include the 'allow-default' option to work with static addresses.
C.The switch port must be configured as 'trusted' for IPv6 snooping.
D.The host must use DHCPv6 to obtain an address for Source Guard to work.
AnswerA

Source Guard requires the binding to be in REACHABLE state, which requires ND activity.

Why this answer

The correct answer is A because IPv6 Source Guard relies on the Neighbor Discovery (ND) cache to validate source addresses. Even with a static binding configured via 'ipv6 neighbor binding', the binding remains in an 'incomplete' state until the switch receives a valid Neighbor Advertisement (NA) from the host. Without a complete ND entry, the switch drops packets from the host as the source address cannot be verified against a valid binding.

Exam trap

Cisco often tests the misconception that a static binding alone is sufficient for IPv6 Source Guard, when in fact the binding must be resolved via ND (NA message) to become active and allow traffic.

How to eliminate wrong answers

Option B is wrong because the 'allow-default' option is used with IPv6 Source Guard to permit traffic from the unspecified address (::/0) or default routes, not to accommodate static addresses; static addresses are supported without this option. Option C is wrong because configuring the switch port as 'trusted' for IPv6 snooping would bypass source guard validation entirely, which is not the intended behavior for a port that should enforce source address verification. Option D is wrong because IPv6 Source Guard supports static addresses via manual bindings or ND-snooped entries; DHCPv6 is not a requirement, and the host can use a statically configured address as long as a valid binding exists.

Full explanation →
476
MCQeasy

By default in Cisco IOS-XE, what is the behavior of an IPv4 ACL when no entries match and the ACL is applied to an inbound interface?

A.The packet is permitted.
B.The packet is denied.
C.The packet is forwarded based on routing table lookup.
D.The ACL logs the packet and continues.
AnswerB

The implicit deny all at the end of every IPv4 ACL denies unmatched traffic.

Why this answer

By default, Cisco IOS-XE applies an implicit 'deny any' statement at the end of every IPv4 ACL. If no entries match the packet, the implicit deny triggers, and the packet is dropped. This behavior is consistent for ACLs applied to inbound interfaces, ensuring that only explicitly permitted traffic is allowed.

Exam trap

Cisco often tests the implicit deny any behavior by presenting scenarios where an ACL has no matching entries, leading candidates to mistakenly think the packet is permitted or forwarded based on routing.

How to eliminate wrong answers

Option A is wrong because the implicit deny any statement at the end of an ACL causes unmatched packets to be dropped, not permitted. Option C is wrong because ACLs operate independently of the routing table; a packet that is denied by an ACL is discarded before any routing decision is made. Option D is wrong because logging is not enabled by default; it requires the explicit 'log' keyword on an ACL entry, and even then, the packet is still subject to the implicit deny if no match occurs.

Full explanation →
477
MCQhard

In Cisco IOS, what is the default behavior of the ip nat service command?

A.It disables NAT for all protocols by default.
B.It enables NAT only for TCP and UDP by default.
C.It is used to configure NAT for specific application-layer protocols and is not enabled by default.
D.It configures the NAT translation timeout for all services.
AnswerC

Correct. The ip nat service command is used to fine-tune NAT for specific protocols and is not enabled by default; it is applied only when configured.

Why this answer

The `ip nat service` command in Cisco IOS is used to enable NAT for specific application-layer protocols (e.g., SIP, H.323, DNS) that embed IP addresses in their payloads, requiring the NAT router to perform deep packet inspection. By default, this command is not enabled; NAT only translates the IP header for TCP and UDP traffic without application-layer awareness. Option C correctly identifies that the command is not enabled by default and is used for specific protocol configuration.

Exam trap

The trap here is that candidates often assume NAT automatically supports all protocols, but Cisco tests the distinction that only TCP and UDP are translated by default, while application-layer protocols require explicit `ip nat service` configuration.

How to eliminate wrong answers

Option A is wrong because the default behavior of NAT is to translate IP addresses for TCP and UDP traffic, not to disable NAT for all protocols. Option B is wrong because NAT inherently supports TCP and UDP by default without needing the `ip nat service` command; this command is for additional application-layer protocols. Option D is wrong because the `ip nat service` command does not configure translation timeouts; timeouts are controlled by the `ip nat translation timeout` command.

Full explanation →
478
Multi-Selectmedium

Which TWO commands can be used to troubleshoot EIGRP route redistribution issues when routes are not appearing in the routing table? (Choose TWO.)

Select 2 answers
A.show ip protocols
B.show ip route
C.show ip eigrp topology all-links
D.show ip ospf database
E.debug ip routing
AnswersA, C

This shows redistribution settings, route maps, and administrative distances, helping identify misconfigurations.

Why this answer

The 'show ip protocols' command (A) is correct because it displays the routing protocol configuration, including redistribution settings such as the metric, route map, and which protocols are being redistributed. When EIGRP routes are missing from the routing table, this command helps verify that redistribution is correctly configured and active, which is a primary troubleshooting step for redistribution issues.

Exam trap

Cisco often tests the distinction between 'show ip eigrp topology' and 'show ip eigrp topology all-links', where the latter is necessary to see all routes, including those not selected as best paths, which is critical for troubleshooting redistribution failures.

Full explanation →
479
MCQmedium

In BGP, what is the default value of the keepalive timer?

A.30 seconds
B.60 seconds
C.90 seconds
D.180 seconds
AnswerB

Correct. The default BGP keepalive timer is 60 seconds.

Why this answer

In BGP, the default keepalive timer is 60 seconds, as specified in RFC 4271. This timer determines how often a BGP speaker sends Keepalive messages to its peer to maintain the session. The hold timer, which is three times the keepalive interval (default 180 seconds), triggers session teardown if no Keepalive or update is received within that period.

Exam trap

Cisco often tests the distinction between the keepalive timer (60 seconds) and the hold timer (180 seconds), and candidates frequently confuse the two or misremember the default as 30 seconds due to familiarity with other routing protocols like EIGRP.

How to eliminate wrong answers

Option A is wrong because 30 seconds is the default keepalive interval for EIGRP, not BGP. Option C is wrong because 90 seconds is not a standard BGP timer value; it might be confused with the OSPF dead interval (which is 40 seconds by default). Option D is wrong because 180 seconds is the default BGP hold timer, not the keepalive timer; the keepalive timer is one-third of the hold timer.

Full explanation →
480
MCQhard

A network redistributes EIGRP into OSPF. Router R1 is a redistribution point with configuration: router eigrp 100 redistribute ospf 1 metric 10000 100 255 1 1500. Router R2, an OSPF router, shows: 'show ip route ospf' includes some EIGRP routes but with higher cost than expected. Traffic from R2 to those networks takes suboptimal paths. What is the root cause?

A.The redistributed metric values are too high, causing EIGRP to calculate a high composite metric, making these routes less preferred than other paths.
B.OSPF is using a different metric type (E1 vs E2) that affects path selection.
C.R1 has a route-map that modifies the metric during redistribution, but it is not applied.
D.The redistribution is one-way; OSPF routes are not being redistributed back into EIGRP, causing asymmetry.
AnswerA

EIGRP uses a composite metric based on bandwidth and delay. A high bandwidth value (10000 kbps) results in a high metric, making the route less attractive.

Why this answer

The configuration 'redistribute ospf 1 metric 10000 100 255 1 1500' under router eigrp 100 redistributes OSPF routes into EIGRP, not EIGRP into OSPF. The metric values (bandwidth 10000 kbps, delay 100) produce a high composite metric, making these EIGRP routes less preferred compared to other EIGRP-learned paths. This causes R2, an OSPF router, to see the redistributed routes with higher cost (if the EIGRP routes are further redistributed into OSPF) or to experience suboptimal path selection due to the elevated metric.

Exam trap

Cisco often tests the misconception that redistribution metrics only affect the receiving protocol's cost, when in fact the metric values directly influence the EIGRP composite metric calculation, making routes less preferred within EIGRP itself.

How to eliminate wrong answers

Option B is wrong because OSPF metric type (E1 vs E2) affects the OSPF cost calculation, not the EIGRP composite metric; the issue is on the EIGRP side, not OSPF. Option C is wrong because the question states no route-map is applied, and even if one were, it would modify the metric during redistribution, not cause the described symptom of higher-than-expected cost. Option D is wrong because one-way redistribution does not cause higher metric values; it only prevents OSPF from learning EIGRP routes, which is not the issue here.

Full explanation →
481
MCQhard

A network engineer is troubleshooting a router that is not allowing SSH connections from any management station. The router has 'ip domain-name example.com' and 'crypto key generate rsa' configured. 'line vty 0 4' has 'transport input ssh' and 'login local'. The engineer can ping the router from a management station. What is the most likely cause?

A.The RSA key was generated with a modulus less than 768 bits, causing SSH to fail.
B.The VTY lines are missing the 'login local' command.
C.The router has 'ip ssh version 1' configured, and the client only supports SSHv2.
D.The management station is using the wrong username or password.
AnswerA

Cisco IOS requires a minimum 768-bit RSA key for SSHv2; if the key is smaller, SSH will not accept connections.

Why this answer

The most likely cause is that the RSA key was generated with a modulus less than 768 bits. Cisco IOS requires an RSA key modulus of at least 768 bits for SSH to function; if the modulus is smaller (e.g., 512 bits), SSH will fail to start even though the key is generated successfully. The presence of 'ip domain-name', 'crypto key generate rsa', 'transport input ssh', and 'login local' on the VTY lines, combined with successful ping reachability, points to an SSH-specific configuration issue rather than connectivity or authentication problems.

Exam trap

Cisco often tests the specific modulus requirement for SSH (768 bits minimum) and the fact that a successful 'crypto key generate rsa' does not guarantee SSH will work if the key is too small, leading candidates to overlook this subtle but critical detail.

How to eliminate wrong answers

Option B is wrong because the scenario explicitly states that 'login local' is configured on the VTY lines, so missing this command is not the issue. Option C is wrong because if the router had 'ip ssh version 1' and the client only supported SSHv2, the client would receive a version mismatch error, but SSH would still attempt negotiation; however, the question indicates no SSH connections are allowed at all, which is more consistent with a failed SSH server startup due to a weak RSA key. Option D is wrong because the management station can ping the router, indicating Layer 3 reachability, and the problem is that SSH connections are not allowed at all, not that authentication fails after a connection is established; wrong username/password would result in an authentication failure after the TCP connection is made, not a complete inability to connect.

Full explanation →
482
MCQhard

Router R1 is configured as an ERSPAN source to monitor traffic on interface Tunnel0 (a DMVPN tunnel). The destination is a collector at 172.16.0.100. R1's configuration: monitor session 1 type erspan-source source interface Tunnel0 both destination erspan-id 4 ip address 172.16.0.100 origin ip address 10.0.0.1. The collector receives no packets. The Tunnel0 interface is up/up and has an IP of 10.0.0.1/30. The tunnel destination is 192.168.1.1. The router has a route to 172.16.0.100 via 10.0.0.2. What is the root cause?

A.The ERSPAN source interface is a tunnel, which is not supported for ERSPAN.
B.The ERSPAN destination IP is routed via the tunnel interface, causing the encapsulated packets to be sent into the tunnel and double-encapsulated, leading to drop.
C.The tunnel interface is not in the same VRF as the collector.
D.The ERSPAN session ID 4 conflicts with the tunnel key.
AnswerB

The route to 172.16.0.100 via 10.0.0.2 points to the tunnel peer, so the encapsulated packets enter the tunnel, causing recursion.

Why this answer

ERSPAN monitors traffic on the source interface. When the source is a tunnel interface, the mirrored traffic is the original IP packets before encapsulation. The ERSPAN process then encapsulates these packets with a new IP header.

However, the encapsulated packets are sent using the routing table. If the destination IP is reachable via a route that points to the tunnel interface itself (e.g., via 10.0.0.2, which is the tunnel's peer), the encapsulated packets may be sent into the tunnel, causing them to be encapsulated again. This double encapsulation can cause issues.

But the more likely root cause is that the ERSPAN session is configured to monitor the tunnel interface, but the tunnel interface itself may not be able to generate the encapsulated packets correctly because the tunnel is used for the destination. The correct answer is that the ERSPAN source IP is the same as the tunnel interface IP, and the destination is routed via the tunnel, causing a recursive routing loop similar to the first question.

Full explanation →
483
MCQhard

A network engineer is troubleshooting an OSPFv3 adjacency issue between two routers over an IPv6-only link. The engineer configures OSPFv3 on both routers and sees that the adjacency is stuck in EXSTART state. 'debug ipv6 ospf packet' shows that the routers are exchanging DBD packets but not progressing. What is the most likely cause?

A.The OSPFv3 interface MTU is mismatched between the two routers.
B.The routers have different OSPFv3 router IDs.
C.The OSPFv3 process is configured with 'ipv6 ospf 1 area 0' on the interface, but the interface is not IPv6-enabled.
D.The link is a point-to-point link, but the OSPF network type is set to broadcast.
AnswerA

An MTU mismatch prevents DBD packets from being exchanged properly, causing the adjacency to be stuck in EXSTART.

Why this answer

The EXSTART state indicates that the routers are trying to establish the master/slave relationship and exchange DBD packets. If they are stuck, it is often due to a mismatch in the OSPF MTU or the interface MTU. If the MTU is mismatched, the DBD packets may be too large to be sent, causing the routers to keep retransmitting.

Another cause could be a mismatch in the OSPF network type, but that usually causes issues earlier. The most likely cause is an MTU mismatch.

Full explanation →
484
MCQmedium

Which BGP attribute is used as the first tie-breaker when selecting the best path for route summarization?

A.Local preference
B.Weight
C.AS path length
D.MED
AnswerB

Weight is Cisco-specific and is checked first.

Why this answer

The highest weight (locally configured) is the first tie-breaker in BGP path selection, before local preference.

Full explanation →
485
MCQhard

A DMVPN Phase 3 network with BGP as the routing protocol experiences high CPU usage on the hub router R1. The 'show process cpu' command shows high usage by the 'BGP Scanner' process. What is the root cause?

A.R1 is receiving a large number of BGP updates from many spokes, causing the BGP Scanner to process many prefixes and consume high CPU.
B.R1 has a CoPP policy that rate-limits BGP traffic, causing packet drops and retransmissions.
C.R1's BGP table is fragmented due to memory issues.
D.R1 has 'bgp update-delay' configured, causing delayed processing of updates.
AnswerA

Correct. BGP Scanner processes route updates and can become CPU-bound with many prefixes. Route aggregation or filtering can reduce the load.

Why this answer

High BGP Scanner CPU usage can be caused by a large number of prefixes being processed, especially if there are many updates or flapping routes. In a DMVPN network, if spokes are configured to advertise many prefixes or if there is route instability (e.g., due to flapping tunnels), the BGP Scanner process can consume high CPU. Another common cause is that the hub is processing many BGP updates from multiple spokes without proper route filtering or aggregation.

Full explanation →
486
MCQhard

An engineer configures Flexible NetFlow on a router to monitor traffic. Unexpectedly, the NetFlow exporter does not send any flow records to the collector. The engineer verifies that the monitor is applied to the correct interface and that the collector is reachable. Which is the most likely explanation?

A.The flow monitor references a record that does not include mandatory match fields, causing the monitor to remain inactive.
B.The exporter is configured with 'transport tcp' instead of 'transport udp', and the collector only accepts UDP.
C.The interface where the monitor is applied is in a VRF, and the exporter is not configured with the VRF name.
D.The flow monitor uses 'cache timeout inactive 60' which is too long, causing flows to be held until the cache is full.
AnswerA

Flexible NetFlow records require at least one match field (e.g., source IP, destination IP, protocol). Without it, the monitor cannot classify flows and will not export any data.

Why this answer

Flexible NetFlow requires a flow monitor to reference a record that defines the match and collect fields. If the record is not defined or is incomplete (e.g., missing key fields like source/destination IP), the monitor may not generate any flows. Additionally, the exporter configuration must include the correct source interface and transport protocol (UDP) to the collector.

A common edge case is when the record is defined but uses 'match ipv4 protocol' without 'match ipv4 source address', causing the flow monitor to fail to create flows.

Full explanation →
487
MCQmedium

Which of the following is the default EIGRP network type on a Frame Relay point-to-point subinterface?

A.NBMA
B.Point-to-point
C.Broadcast
D.Point-to-multipoint
AnswerB

Correct. Point-to-point subinterfaces default to point-to-point network type.

Why this answer

On a Frame Relay point-to-point subinterface, the default EIGRP network type is point-to-point. This is because each point-to-point subinterface creates a separate logical connection to a single remote router, eliminating the need for NBMA-specific mechanisms like split horizon or next-hop-self adjustments. The point-to-point network type enables EIGRP to use multicast hello packets (224.0.0.10) and form a single adjacency over the link.

Exam trap

Cisco often tests the misconception that Frame Relay always defaults to NBMA, but candidates must remember that point-to-point subinterfaces override this default to point-to-point, while only physical interfaces or multipoint subinterfaces retain the NBMA default.

How to eliminate wrong answers

Option A is wrong because NBMA is the default EIGRP network type on a Frame Relay physical interface or multipoint subinterface, not on a point-to-point subinterface. Option C is wrong because broadcast is a network type used on Ethernet or other multiaccess broadcast media, and it is not the default on any Frame Relay subinterface. Option D is wrong because point-to-multipoint is a network type that must be manually configured on a Frame Relay multipoint subinterface, and it is not the default on a point-to-point subinterface.

Full explanation →
489
MCQhard

MPLS network with LDP enabled. Routers R1 and R2 are directly connected. R1 has: mpls ip interface Serial0/0/0 mpls ip R2 has: mpls ip interface Serial0/0/0 mpls ip R1 shows: R1# show mpls ldp neighbor Peer LDP Ident: 10.2.2.2:0; Local LDP Ident: 10.1.1.1:0 TCP connection: 10.2.2.2.646 - 10.1.1.1.646 State: Oper; Msgs sent/rcvd: 10/10; Downstream Up time: 00:00:30 LDP discovery sources: Serial0/0/0, Src IP addr: 10.2.2.2 R1# show mpls forwarding-table Local tag Outgoing tag Prefix Bytes tag switched Outgoing interface 16 Untagged 10.3.3.0/24 0 Serial0/0/0 R2 shows: R2# show mpls forwarding-table Local tag Outgoing tag Prefix Bytes tag switched Outgoing interface 16 17 10.3.3.0/24 0 Serial0/0/0 R1 is not installing a label for 10.3.3.0/24 from R2. What is the root cause?

A.R1 has an 'mpls ldp advertise-labels' command that filters the label for 10.3.3.0/24.
B.R2 is not running LDP on the interface.
C.The prefix 10.3.3.0/24 is not in R2's routing table.
D.There is an MTU mismatch on the serial link.
AnswerA

This command can prevent R1 from advertising labels for certain prefixes, causing R1 to receive 'Untagged'.

Why this answer

R1 is not installing a label for 10.3.3.0/24 from R2 because R1 has an 'mpls ldp advertise-labels' command that filters the label advertisement for that prefix. This command controls which labels the router advertises to its LDP peers. Since the label for 10.3.3.0/24 is filtered out, R1 does not send a label advertisement to R2, and consequently R2 does not send a label back to R1 for that prefix.

As a result, R1's forwarding table shows 'Untagged' for the outgoing tag, indicating no label is used when forwarding to R2.

Full explanation →
490
MCQmedium

An engineer configures a local SPAN session on a Cisco switch to monitor all traffic on VLAN 20. The engineer uses the command 'monitor session 1 source vlan 20' and 'monitor session 1 destination interface GigabitEthernet0/3'. The engineer connects a laptop to GigabitEthernet0/3 and runs a packet capture, but sees only traffic from the switch itself, not from other devices in VLAN 20. What is the most likely cause?

A.The SPAN session is configured to monitor only ingress traffic by default.
B.The destination port is in a different VLAN than the source VLAN.
C.The switch does not support SPAN on VLANs.
D.The laptop is not configured to accept tagged traffic.
AnswerA

Correct because the default direction for a SPAN source VLAN is 'rx' (received traffic); to capture all traffic, the engineer must add 'both' or 'tx'.

Why this answer

By default, SPAN monitors only ingress traffic on the source VLAN. To capture both directions, the command must specify 'both' for the source. The default is 'rx' only.

Full explanation →
491
MCQhard

A network redistributes OSPF into EIGRP. Router R1 has: redistribute ospf 1 metric 10000 100 255 1 1500. Router R2 shows: show ip route eigrp includes some OSPF routes but not 192.168.1.0/24. What is the root cause?

A.The OSPF route 192.168.1.0/24 is not in the OSPF database.
B.The EIGRP metric components are misordered; delay should be 100, not 10000.
C.The high delay metric (10000) may cause the route to be suppressed by EIGRP's feasibility condition.
D.Redistribution requires a route-map to filter specific routes.
AnswerC

EIGRP uses composite metric; high delay can make the route less feasible, preventing installation.

Why this answer

C is correct because EIGRP uses a feasibility condition to prevent routing loops, which requires that the reported distance (RD) from a neighbor be strictly less than the feasible distance (FD). The redistribute command sets the EIGRP metric components in the order bandwidth, delay, reliability, load, MTU. Here, the delay is set to 10000 tens of microseconds, which is extremely high (100,000 microseconds).

This high delay inflates the composite metric, making the FD very large. When this route is advertised to an EIGRP neighbor, the neighbor's RD may equal or exceed its own FD for that route, violating the feasibility condition and causing the route to be suppressed from the routing table.

Exam trap

Cisco often tests the EIGRP feasibility condition by hiding it behind a metric misconfiguration—candidates mistakenly think the metric values are simply wrong or misordered, when the real issue is that the high delay causes the route to be suppressed by EIGRP's loop-prevention mechanism.

How to eliminate wrong answers

Option A is wrong because the question states that 'show ip route eigrp includes some OSPF routes but not 192.168.1.0/24', implying that the route is present in the OSPF database and is being redistributed, but it is not appearing in the EIGRP topology table or routing table due to a metric or feasibility issue. Option B is wrong because the EIGRP metric components in the 'redistribute ospf 1 metric' command are correctly ordered as bandwidth (kbps), delay (tens of microseconds), reliability, load, MTU; the delay value of 10000 is valid and not misordered—the issue is that this value is too high, not that it is in the wrong position. Option D is wrong because redistribution into EIGRP does not require a route-map to filter specific routes; a route-map is optional and used for policy-based control, but the absence of a route-map does not prevent a redistributed route from appearing in the EIGRP table if the metric is valid and the feasibility condition is met.

Full explanation →
492
MCQmedium

Consider the following configuration on router R2: crypto isakmp policy 10 encryption aes 256 authentication pre-share group 14 lifetime 3600 ! crypto isakmp key secretkey address 192.168.1.1 ! crypto ipsec transform-set TSET esp-aes 256 esp-sha-hmac mode tunnel ! crypto map CMAP 10 ipsec-isakmp set peer 192.168.1.1 set transform-set TSET match address 101 ! interface GigabitEthernet0/1 ip address 192.168.1.2 255.255.255.0 crypto map CMAP ! access-list 101 permit ip 10.2.2.0 0.0.0.255 10.1.1.0 0.0.0.255 Which statement is true?

A.The IPsec tunnel will establish successfully because the transform sets match.
B.The IKE phase 1 will fail due to ISAKMP lifetime mismatch.
C.The tunnel will work but will rekey every hour due to the shorter lifetime.
D.The pre-shared key mismatch will cause the tunnel to fail.
AnswerB

ISAKMP policies must match exactly, including lifetime. A mismatch causes negotiation failure.

Why this answer

The correct answer is B because the ISAKMP lifetime configured on R2 is 3600 seconds (1 hour), but the question implies the remote peer (192.168.1.1) has a different lifetime (likely the default of 86400 seconds). During IKE phase 1 negotiation, the peers propose their lifetimes, and if they do not match, the session fails because Cisco IOS requires identical lifetime values for successful phase 1 establishment. This mismatch causes the IKE phase 1 to fail, preventing the IPsec tunnel from forming.

Exam trap

Cisco often tests the misconception that only transform sets (phase 2) need to match, while IKE phase 1 parameters like lifetime are overlooked, causing candidates to incorrectly select option A.

How to eliminate wrong answers

Option A is wrong because even if the transform sets match, the IKE phase 1 lifetime mismatch will cause the entire tunnel negotiation to fail before phase 2 (transform set matching) is ever reached. Option C is wrong because the tunnel will not work at all due to the phase 1 failure; rekeying is irrelevant if the initial IKE SA cannot be established. Option D is wrong because the pre-shared key is configured correctly on R2 with the address of the peer (192.168.1.1), and there is no evidence of a mismatch; the question specifically highlights the lifetime as the issue.

Full explanation →
493
MCQhard

A large enterprise network is experiencing intermittent loss of reachability to a set of prefixes originated by R2. R1 (AS 65001) and R2 (AS 65002) are eBGP peers. R1 has the following relevant configuration: router bgp 65001, neighbor 10.1.1.2 remote-as 65002, neighbor 10.1.1.2 route-map RM_IN in. The route-map RM_IN has a clause: match ip address prefix-list PL_ALLOW, set local-preference 200. The prefix-list PL_ALLOW permits 10.0.0.0/8 le 24. R2 advertises 10.0.0.0/8 and more specific prefixes including 10.1.0.0/16. R1 shows: BGP table has 10.0.0.0/8 with local-pref 200, but 10.1.0.0/16 is missing. What is the root cause?

A.The prefix-list PL_ALLOW is missing a permit for 10.1.0.0/16 exactly, so it is denied by implicit deny.
B.The local-preference 200 is too high, causing the route to be suppressed by BGP best-path selection.
C.The neighbor command is missing the soft-reconfiguration inbound option, so the route is not stored.
D.The prefix-list should use ge instead of le to match longer prefixes.
AnswerA

The route-map RM_IN has no permit clause for unmatched prefixes, so the implicit deny at the end of the route-map filters 10.1.0.0/16.

Why this answer

The route-map RM_IN includes a match clause referencing prefix-list PL_ALLOW, which permits only 10.0.0.0/8 le 24. The more specific prefix 10.1.0.0/16 (length 16) is within the length range of the prefix-list, but it is not explicitly permitted. Since the route-map has a match clause, unmatched routes are subject to implicit deny, causing 10.1.0.0/16 to be filtered out.

The correct answer is A.

Full explanation →
494
Multi-Selecthard

Which TWO actions will prevent an EIGRP neighbor relationship from forming due to authentication mismatch? (Choose TWO.)

Select 2 answers
A.One router is configured with 'ip authentication mode eigrp 100 md5' and the other with 'ip authentication mode eigrp 100 sha256'.
B.Both routers use the same key chain name but one router has key ID 1 with string 'cisco' and the other has key ID 2 with string 'cisco'.
C.One router has 'ip authentication key-chain eigrp 100 MYCHAIN' configured, while the other router has no authentication configuration at all.
D.Both routers use the same key chain and key ID, but the key string on one router is 'cisco123' and on the other is 'Cisco123' (case-sensitive).
E.The 'accept-lifetime' on one router is set to 00:00:00 Jan 1 2020 to 23:59:59 Dec 31 2020, and the current time is in 2023.
AnswersA, D

Correct. Mismatched authentication modes (MD5 vs SHA-256) will prevent EIGRP neighbor formation.

Why this answer

EIGRP neighbor relationships fail due to authentication mismatch when authentication modes differ (MD5 vs SHA-256) as in A, and when key strings differ in case-sensitivity as in D. Option B does NOT prevent the neighbor relationship because both routers use the same key chain and same key string; the key ID does not need to match for authentication to succeed. Option C will not prevent the relationship because if one router has no authentication, the adjacency forms with a warning.

Option E describes a key expiration scenario, which prevents adjacency but is not an authentication mismatch between two routers.

Exam trap

A common trap is to think that mismatched authentication mode or key string prevents formation, but also consider that missing authentication on one side may not block adjacency.

Full explanation →
495
MCQmedium

A network engineer runs the following command to troubleshoot a VRF-Lite issue: R1# show ip eigrp vrf CUSTOMER_B topology 10.1.1.0/24 Output: IP-EIGRP (AS 100): Topology entry for 10.1.1.0/24 for VRF CUSTOMER_B State is Passive, Query origin flag is 1, 1 Successor(s), FD is 131072 Routing Descriptor Blocks: 10.1.1.1 (GigabitEthernet0/1), from 10.1.1.1, Send flag is 0x0 Composite metric is (131072/128256), Route is Internal Vector metric: Minimum bandwidth is 100000 Kbit Total delay is 100 microseconds Reliability is 255/255 Load is 1/255 Minimum MTU is 1500 Hop count is 1 What does this output indicate?

A.The route 10.1.1.0/24 is in Active state, indicating an EIGRP query is in progress.
B.The route 10.1.1.0/24 has one successor with a feasible distance of 131072 and is learned via 10.1.1.1.
C.The route 10.1.1.0/24 is an external EIGRP route redistributed into the VRF.
D.The route 10.1.1.0/24 has multiple successors due to equal-cost paths.
AnswerB

Correct. The output shows one successor, FD 131072, and next hop 10.1.1.1.

Why this answer

The 'show ip eigrp vrf topology' command displays the EIGRP topology table entry for a specific prefix within a VRF. The output shows the route 10.1.1.0/24 is in Passive state, meaning no EIGRP query is pending. It has one successor (the best path) with a feasible distance (FD) of 131072.

The next hop is 10.1.1.1 via GigabitEthernet0/1.

Full explanation →
496
MCQmedium

When redistributing routes between OSPF and EIGRP, which of the following is a recommended best practice to prevent routing loops?

A.Use the same administrative distance for both protocols.
B.Apply route filtering using route-maps or prefix-lists to control which routes are redistributed.
C.Increase the default metric to a high value to discourage redistribution.
D.Disable route summarization on both protocols.
AnswerB

Route filtering prevents unwanted routes from being redistributed, reducing loop risk.

Why this answer

To prevent routing loops during mutual redistribution, it is recommended to use route-maps with distribute-lists or prefix-lists to filter routes, and to adjust administrative distances to prefer one protocol over the other. This prevents routes from being redistributed back and forth.

Full explanation →
497
MCQmedium

A network engineer runs the following command to verify IPv6 uRPF operation: R1# show ipv6 interface GigabitEthernet0/0 | include verify IPv6 verify source: strict What does this output indicate?

A.Strict uRPF is enabled, so the router will drop packets if the source address is not in the routing table or if the best return path is not through the receiving interface.
B.Strict uRPF is enabled, but it only checks if the source address is in the routing table, regardless of interface.
C.Loose uRPF is enabled, which only checks if the source address is in the routing table.
D.uRPF is disabled on this interface.
AnswerA

Correct. Strict uRPF requires both a matching route and that the interface used to reach the source is the same as the receiving interface.

Why this answer

The output 'IPv6 verify source: strict' indicates that strict unicast Reverse Path Forwarding (uRPF) is enabled on the interface. Strict uRPF verifies that the source IPv6 address of an incoming packet is reachable via the routing table AND that the best return path to that source uses the same interface on which the packet was received. If either condition fails, the packet is dropped.

This matches option A exactly.

Exam trap

Cisco often tests the distinction between strict and loose uRPF by showing the 'verify source' output and expecting candidates to remember that 'strict' requires both a routing table match and the correct incoming interface, while 'loose' only requires the source to be in the routing table.

How to eliminate wrong answers

Option B is wrong because it describes a loose uRPF behavior, where only the source address must exist in the routing table, regardless of the incoming interface; strict uRPF additionally checks that the best return path is through the receiving interface. Option C is wrong because the output explicitly shows 'strict', not 'loose'; loose uRPF would display 'IPv6 verify source: loose' and only checks the routing table for the source address. Option D is wrong because the output clearly indicates that uRPF is enabled (strict mode), not disabled; a disabled state would show no 'verify' line or 'IPv6 verify source: none'.

Full explanation →
498
MCQeasy

Which CoPP mechanism prevents the CPU from being overwhelmed by control plane traffic?

A.Shaping
B.Policing
C.Queuing
D.Compression
AnswerB

CoPP applies policing to control plane traffic, dropping packets that exceed the configured rate to protect the CPU.

Why this answer

CoPP uses a policer (typically a single-rate two-color or three-color marker) to rate-limit traffic destined to the control plane, dropping packets that exceed the configured rate.

Full explanation →
499
MCQhard

A DMVPN network uses FlexVPN with BGP as the routing protocol. Spoke routers are configured with Flexible NetFlow to monitor traffic. After a configuration change, spoke-to-spoke tunnels fail to establish. Router R1 (spoke) shows: show dmvpn detail | include (State|Tunnel) State: NHRP, Tunnel: Tunnel0. The BGP neighbor to the hub is up, but no BGP routes are received for the remote spoke's LAN. What is the root cause?

A.The flow monitor is applied to the tunnel interface in the input direction and uses a flow record that matches on BGP port 179, causing BGP packets to be dropped.
B.The flow exporter's source interface is set to Tunnel0, but the tunnel is not yet established, so BGP updates sourced from Tunnel0 are unreachable.
C.The BGP neighbor is configured with a password that does not match the hub.
D.The NHRP authentication key is missing, preventing spoke-to-spoke communication.
AnswerB

If the exporter source is the tunnel interface, the router will try to send BGP packets with that source IP, but the tunnel is not up, so the packets are dropped. This prevents BGP from establishing.

Why this answer

Flexible NetFlow can be applied to the tunnel interface, but if the flow monitor is configured with a sampler or a flow record that changes the interface behavior, it might interfere with NHRP or BGP. Specifically, if the flow monitor is configured to use a flow record that includes the 'input interface' field and is applied in the input direction, it may cause the router to process packets differently, potentially dropping NHRP packets or BGP updates. However, the most likely issue is that the flow monitor is configured with a match statement that inadvertently matches BGP packets and applies an action (like drop) or that the flow exporter is misconfigured to use the tunnel interface as source, causing BGP updates to be sourced from the tunnel IP, which is not reachable.

The correct answer is that the flow exporter's source interface is set to Tunnel0, which is not reachable from the hub until the tunnel is up, creating a chicken-and-egg problem.

Full explanation →
500
MCQmedium

A network engineer runs the following command on Router R1: R1# show crypto ipsec sa | include pkts #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0 #pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0 #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0 #pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0 Based on this output, what is the problem?

A.The IPsec SA is not established; the tunnel is down.
B.No interesting traffic is being sent through the tunnel; check the crypto ACL and routing.
C.The tunnel is working correctly; all packets are being encrypted.
D.The remote peer is not responding; the SA is in MM_NO_STATE.
AnswerB

Zero packet counts indicate no traffic matches the crypto ACL or routing is not directing traffic to the tunnel.

Why this answer

All packet counters are zero, indicating no traffic has been encrypted or decrypted. This could be due to a misconfigured crypto ACL that does not match the actual traffic, or routing issues preventing traffic from reaching the tunnel.

Full explanation →
501
MCQhard

An engineer configures OSPF area range on an ABR to summarize routes. After configuration, some routes are still being advertised as individual LSAs into the backbone. Which is the most likely explanation?

A.The area range command does not summarize external routes redistributed into OSPF.
B.The ABR is not configured with the summary-address command.
C.The area range is configured on the wrong ABR.
D.The OSPF process needs to be cleared to apply the area range.
AnswerA

Area range only summarizes internal OSPF routes, not external routes (type 5 LSAs).

Why this answer

OSPF area range summarization works for intra-area routes (type 1 and type 2 LSAs) and inter-area routes (type 3 LSAs) within the range. However, it does not summarize external routes redistributed into OSPF (type 5 LSAs) or NSSA external routes (type 7 LSAs). Therefore, if the individual routes are external, they will still be advertised as separate LSAs.

Full explanation →
502
MCQmedium

snmp-server group MyGroup v3 priv\nsnmp-server user MyUser MyGroup v3 auth sha MyPassword priv aes 128 MyPrivKey What is missing from this SNMPv3 configuration?

A.The group is missing a view definition to allow access to MIB objects.
B.The authentication protocol should be MD5 instead of SHA.
C.The privacy password must be at least 16 characters long.
D.The user must be configured under a different group name.
AnswerA

By default, an SNMPv3 group without a view has no access to MIB objects; a view must be configured using 'snmp-server view' and associated with the group.

Why this answer

The configuration creates an SNMPv3 group 'MyGroup' with priv security level and a user 'MyUser' with SHA authentication and AES 128 privacy, but it does not include a view definition for the group. Without a view (e.g., via the 'snmp-server group MyGroup v3 priv view MyView' command or a default view), the group has no access to any MIB objects, rendering the SNMPv3 configuration non-functional for queries or notifications.

Exam trap

Cisco often tests the misconception that configuring authentication and privacy alone is sufficient for SNMPv3 functionality, but the missing view definition is the critical oversight that prevents any MIB access.

How to eliminate wrong answers

Option B is wrong because SHA is a valid and commonly used authentication protocol for SNMPv3; MD5 is also supported but not required, and Cisco does not mandate MD5 over SHA. Option C is wrong because the privacy password length requirement for AES 128 is not a fixed 16-character minimum; Cisco SNMPv3 accepts passwords of varying lengths, and the key derivation process handles shorter or longer strings. Option D is wrong because the user is correctly associated with the group 'MyGroup' via the 'snmp-server user MyUser MyGroup v3' command; there is no requirement for a different group name.

Full explanation →
503
MCQhard

In a VRF-Lite network, OSPF is configured with a distribute-list that filters routes from being installed in the routing table. The engineer notices that the distribute-list is working, but the filtered routes are still being advertised to OSPF neighbors. Which is the most likely explanation?

A.The distribute-list is applied inbound, which only prevents the route from being installed in the RIB, but the route remains in the OSPF LSDB and is advertised to neighbors.
B.The distribute-list is applied outbound, but the neighbor has a higher priority, so the route is still advertised.
C.The OSPF process has the 'database-filter all out' command configured, which overrides the distribute-list.
D.The distribute-list uses an ACL that does not match the route correctly, so the route is not filtered.
AnswerA

Distribute-list in filters routes from the RIB, not the LSDB. OSPF advertises based on the LSDB, so the route is still advertised.

Why this answer

The OSPF distribute-list in (or out) filters routes from being installed in the routing table (RIB) but does not affect the OSPF link-state database (LSDB) or the advertisement of routes. To filter routes from being advertised, the distribute-list must be applied outbound, or an area filter (using 'area range' with 'not-advertise') must be used. This is a common misconception: distribute-list in only affects local RIB installation, not LSDB propagation.

Full explanation →
504
MCQhard

Router R1 is configured with ip nat inside source list 100 interface GigabitEthernet0/1 overload. Internal host 192.168.1.10 can access the internet, but when it tries to connect to an internal server at 10.1.1.10 via its public IP 203.0.113.10, the connection fails. Router R1 shows: show ip nat translations: Pro Inside global Inside local Outside local Outside global --- 203.0.113.10 10.1.1.10 --- ---. The host's traffic is being NATed to 203.0.113.1, but the server's response is sent to 203.0.113.1. What is the root cause?

A.Enable NAT hairpinning by configuring ip nat inside source static tcp 10.1.1.10 80 203.0.113.10 80 and ensuring the router has a route to the public IP.
B.Configure the host to use the private IP of the server instead of the public IP.
C.Add a static route on the router for 203.0.113.10 pointing to the server.
D.Use ip nat outside source list 100 interface GigabitEthernet0/1 overload.
AnswerA

Hairpinning allows the router to forward traffic from inside to inside via the public IP.

Why this answer

The root cause is that NAT hairpinning (also known as NAT reflection or NAT loopback) is not enabled. When an internal host (192.168.1.10) tries to reach an internal server (10.1.1.10) using the server's public IP (203.0.113.10), the router performs NAT for the host's traffic, translating its source to 203.0.113.1. The server's response is sent to 203.0.113.1 (the router's outside interface), but without hairpinning, the router does not know to forward this response back to the internal host because it expects the traffic to come from the outside.

Option A corrects this by adding a static NAT for the server (mapping 10.1.1.10:80 to 203.0.113.10:80) and ensuring the router has a route to the public IP, which enables the router to perform the necessary NAT translation and forward the response back to the internal host.

Exam trap

Cisco often tests the misconception that NAT hairpinning is automatically handled by dynamic PAT, when in fact it requires explicit static NAT configuration and a route to the public IP to force the router to perform the necessary translations.

How to eliminate wrong answers

Option B is wrong because telling the host to use the private IP of the server bypasses the need for NAT entirely, but it does not solve the underlying NAT hairpinning issue; the host should be able to use the public IP as intended. Option C is wrong because adding a static route for 203.0.113.10 pointing to the server does not address the NAT translation problem; the router already knows how to reach the server (10.1.1.10) via its routing table, but the issue is that the router does not perform NAT for traffic that enters and exits the same inside interface. Option D is wrong because using 'ip nat outside source list 100 interface GigabitEthernet0/1 overload' would translate the source of traffic coming from the outside, which is not relevant here; the problem involves internal-to-internal traffic that needs NAT hairpinning, not outside source translation.

Full explanation →
505
MCQhard

A DMVPN network with NHRP is configured for spoke-to-spoke tunnels. Spoke routers R1 and R2 are both connected to a hub router H1. Spoke-to-spoke traffic is not working. R1's show dmvpn shows a dynamic NHRP mapping for R2's tunnel IP to R2's physical IP, but ping from R1's tunnel IP to R2's tunnel IP fails. R1's show ip nhrp shows the mapping as 'dynamic' with no flags. The hub has no special configuration. What is the root cause?

A.The hub is missing the ip nhrp redirect command, and the spokes are missing ip nhrp shortcut, preventing spoke-to-spoke direct communication.
B.The spoke routers have incorrect NHRP authentication, causing the mapping to be invalid.
C.The tunnel interface on R1 is not in the correct VRF.
D.The IPsec transform set is mismatched between spokes.
AnswerA

Without these commands, the hub does not trigger NHRP resolution for spoke-to-spoke traffic, and spokes do not install the necessary routes.

Why this answer

The correct answer is A because in a DMVPN phase 3 network, spoke-to-spoke traffic requires the hub to send NHRP redirect messages and the spokes to process them via the `ip nhrp shortcut` command. Without `ip nhrp redirect` on the hub, the hub forwards traffic between spokes without signaling them to establish a direct tunnel. The dynamic NHRP mapping on R1 for R2's tunnel IP indicates that R1 has learned R2's physical address via NHRP registration, but without the shortcut flag, R1 will not use that mapping to send traffic directly; instead, it continues to send traffic through the hub, which fails if the hub does not have a route or if the spoke-to-spoke tunnel is not triggered.

Exam trap

Cisco often tests the distinction between DMVPN phase 2 (where spokes automatically build direct tunnels without redirect) and phase 3 (which requires explicit redirect and shortcut commands), leading candidates to assume that a dynamic NHRP mapping alone is sufficient for spoke-to-spoke communication.

How to eliminate wrong answers

Option B is wrong because incorrect NHRP authentication would prevent the NHRP registration and mapping from being created at all; the show dmvpn output shows a dynamic mapping, so authentication is not the issue. Option C is wrong because a VRF mismatch would typically prevent the tunnel interface from being reachable or routing correctly, but the presence of a dynamic NHRP mapping indicates that the tunnel interface is operational and in the correct VRF. Option D is wrong because an IPsec transform set mismatch would cause the IPsec tunnel to fail to establish, but the question states that the mapping is present and the ping fails at the tunnel IP level, not at the IPsec level; DMVPN can operate without IPsec, and the issue is with NHRP routing, not encryption.

Full explanation →
506
MCQhard

A network engineer is troubleshooting an IPsec site-to-site VPN where the tunnel is up but traffic from the remote LAN to the local LAN is not working. The engineer pings from the remote router to the local LAN IP and it succeeds. However, pings from a host on the remote LAN to a host on the local LAN fail. What is the most likely cause?

A.The crypto map access list on the remote router does not include the remote LAN subnet.
B.The local router does not have a route to the remote LAN subnet in its routing table.
C.The IPsec transform set is missing the esp-sha-hmac authentication.
D.The pre-shared key is mismatched between the two routers.
AnswerB

Correct because the local router must have a route to the remote LAN subnet to route the return traffic back through the tunnel. Without it, the return traffic is dropped.

Why this answer

The symptom indicates that the VPN tunnel is working for traffic sourced from the router itself, but not for traffic from the remote LAN. This is typically caused by a missing route on the local router for the remote LAN subnet, or a missing route on the remote router for the local LAN subnet, preventing the return traffic from being routed correctly.

Full explanation →
507
Drag & Dropmedium

Drag and drop the steps to verify and validate syslog operational state into the correct order, from first to last.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps
Order
1Step 1
2Step 2
3Step 3
4Step 4
5Step 5

Why this order

First, check the logging status with show logging. Then, verify that syslog messages are being sent to the configured server. Next, confirm the severity level of logged messages.

After that, validate that the syslog server is receiving messages. Finally, test by generating a test log message.

Full explanation →
508
MCQmedium

A network engineer runs the following command to verify IPv6 device tracking: R1# show ipv6 device-tracking database Interface MAC Address VLAN IPv6 Address State Age Policy Fa0/0 0011.2233.4455 10 2001:db8::1 ACTIVE 10 TRUSTED Fa0/0 00aa.bbcc.ddee 10 2001:db8::2 ACTIVE 5 INSPECT Fa0/0 1111.2222.3333 10 2001:db8::3 VERIFY 0 - What does this output indicate?

A.Device tracking shows two devices in ACTIVE state and one in VERIFY state, indicating ongoing ND verification for the third device.
B.All devices are in ACTIVE state, indicating stable tracking.
C.Device tracking is disabled, and the database is empty.
D.Device tracking only tracks IPv4 addresses.
AnswerA

The VERIFY state means the device is being validated before becoming active.

Why this answer

The output shows three entries: two in ACTIVE state (indicating successful ND verification) and one in VERIFY state (meaning the device is currently undergoing Neighbor Discovery verification). The VERIFY state with age 0 indicates that the device has been recently discovered and is being validated before transitioning to ACTIVE. This confirms that device tracking is actively monitoring IPv6 devices, with ongoing ND verification for the third device.

Exam trap

Cisco often tests the distinction between ACTIVE and VERIFY states in IPv6 device tracking, where candidates mistakenly assume all entries are stable (ACTIVE) or that VERIFY indicates a failure, rather than recognizing it as a normal transitional state during ND verification.

How to eliminate wrong answers

Option B is wrong because not all devices are in ACTIVE state; the third device is in VERIFY state, which indicates ongoing verification, not stable tracking. Option C is wrong because the database is not empty; it contains three entries, and device tracking is clearly enabled as shown by the populated output. Option D is wrong because device tracking supports IPv6 addresses, as evidenced by the IPv6 Address column containing IPv6 addresses (2001:db8::1, etc.), not IPv4 addresses.

Full explanation →
509
MCQhard

What is the default IPv6 hop limit for packets sent over a tunnel interface in Cisco IOS-XE?

A.64
B.128
C.255
D.32
AnswerA

The default hop limit for originated IPv6 packets is 64.

Why this answer

The default IPv6 hop limit for packets sent over a tunnel interface in Cisco IOS-XE is 64. This value is defined in RFC 2473 and is used by Cisco for tunnel interfaces such as GRE, IPv6-in-IPv4, and ISATAP. The hop limit is decremented by one when the packet is encapsulated and again when it is decapsulated, so the effective end-to-end hop count is reduced by two.

Exam trap

Cisco often tests the distinction between default values for native interfaces (128) versus tunnel interfaces (64), and candidates mistakenly apply the native interface default to tunnels.

How to eliminate wrong answers

Option B (128) is wrong because 128 is the default hop limit for IPv6 packets sent over native interfaces (e.g., physical Ethernet) in Cisco IOS-XE, not for tunnel interfaces. Option C (255) is wrong because 255 is the default TTL for IPv4 packets on Cisco routers, not the IPv6 hop limit for tunnels. Option D (32) is wrong because 32 is not a standard default value for IPv6 hop limits; it might be confused with the default hop limit used in some older or non-Cisco implementations.

Full explanation →
510
MCQmedium

A network engineer runs the following command to troubleshoot an IPv6 traffic filtering issue: R1# show ipv6 access-list FILTER IPv6 access list FILTER permit ipv6 2001:DB8:1::/48 any sequence 10 deny ipv6 2001:DB8:2::/48 any sequence 20 permit ipv6 any any sequence 30 What does this output indicate?

A.The access list will permit traffic from 2001:DB8:1::/48 and deny traffic from 2001:DB8:2::/48, but permit all other IPv6 traffic.
B.The access list will permit traffic from 2001:DB8:1::/48 and deny traffic from 2001:DB8:2::/48, and implicitly deny all other IPv6 traffic.
C.The access list will deny all traffic because of the deny statement.
D.The access list is invalid because IPv6 access lists require implicit deny at the end.
AnswerA

Correct. Sequence 10 permits the first prefix, sequence 20 denies the second, and sequence 30 permits everything else.

Why this answer

The output shows an IPv6 access list with three explicit entries. Sequence 10 permits traffic from source 2001:DB8:1::/48 to any destination, sequence 20 denies traffic from 2001:DB8:2::/48 to any destination, and sequence 30 permits all other IPv6 traffic. Because sequence 30 explicitly permits any any, traffic not matching the first two entries is permitted, overriding the default implicit deny at the end of the list.

Exam trap

Cisco often tests the interaction between explicit permit entries and the implicit deny, where candidates mistakenly assume the implicit deny applies even when a later explicit permit any any exists.

How to eliminate wrong answers

Option B is wrong because it states that all other IPv6 traffic is implicitly denied, but the explicit permit any any entry at sequence 30 permits all remaining traffic, so the implicit deny is never reached. Option C is wrong because the deny statement only blocks traffic from 2001:DB8:2::/48; the permit entries allow other traffic, so the list does not deny all traffic. Option D is wrong because IPv6 access lists do have an implicit deny at the end, but the list is not invalid; the explicit permit any any entry is valid and overrides the implicit deny for unmatched traffic.

Full explanation →
511
MCQmedium

Given the partial configuration: crypto isakmp policy 10 encryption aes 256 authentication pre-share group 14 ! crypto isakmp key cisco123 address 0.0.0.0 0.0.0.0 ! crypto ipsec transform-set TSET esp-aes 256 esp-sha-hmac mode tunnel ! crypto map CMAP 10 ipsec-isakmp set peer 192.168.1.2 set transform-set TSET match address 101 ! interface GigabitEthernet0/1 ip address 192.168.1.1 255.255.255.0 crypto map CMAP ! access-list 101 permit ip 10.1.1.0 0.0.0.255 10.2.2.0 0.0.0.255 What is the effect of the 'crypto isakmp key' command with address 0.0.0.0 0.0.0.0?

A.The key will be used only for peer 192.168.1.2 because the crypto map specifies that peer.
B.The key will be accepted from any peer, creating a security vulnerability.
C.The configuration will fail because the key must specify a specific peer address.
D.The key will be ignored because there is no ISAKMP policy with a lifetime.
AnswerB

0.0.0.0 0.0.0.0 is a wildcard that matches any IP address, so any peer can use this key.

Why this answer

The `crypto isakmp key` command with address `0.0.0.0 0.0.0.0` acts as a wildcard, meaning the pre-shared key will be accepted from any peer IP address during IKE Phase 1 authentication. This effectively disables peer-specific validation, allowing any device that knows the key to establish an ISAKMP SA, which is a significant security vulnerability.

Exam trap

Cisco often tests the misconception that the crypto map's `set peer` command restricts which peers can authenticate with the pre-shared key, but in reality, the ISAKMP key wildcard overrides that restriction at the IKE layer.

How to eliminate wrong answers

Option A is wrong because the crypto map's peer specification only controls which peer is used for IPsec SA negotiation, not which peer is allowed to authenticate with the pre-shared key; the wildcard key overrides any peer restriction at the IKE level. Option C is wrong because the configuration is valid; Cisco IOS allows a wildcard address (0.0.0.0 0.0.0.0) for the ISAKMP key, and it will not cause a configuration failure. Option D is wrong because the ISAKMP key is not dependent on a lifetime being configured in the ISAKMP policy; the key is used regardless of whether a lifetime is explicitly set.

Full explanation →
512
MCQmedium

A network engineer configures CoPP on a router to limit ICMP traffic to 5000 bps. After the policy is applied, the engineer notices that the router is not responding to ping requests from a remote network. However, the router can ping other devices successfully. The engineer checks the CoPP statistics and sees that the ICMP class has dropped packets. What is the most likely root cause?

A.The CoPP policy is dropping incoming ICMP echo requests because the police rate is too low.
B.The CoPP policy is dropping outgoing ICMP echo replies because the police rate applies to both directions.
C.The router's interface ACL is blocking incoming ICMP traffic.
D.The router's ICMP rate-limit feature is enabled globally.
AnswerA

Incoming ICMP packets are policed by CoPP, and if the rate is exceeded, they are dropped, preventing the router from responding.

Why this answer

The CoPP policy is applied to control plane traffic, which includes ICMP echo requests destined to the router itself. When the police rate is set to 5000 bps, incoming ICMP echo requests are rate-limited and dropped if they exceed this threshold, causing the router to stop responding to pings. The fact that the router can still ping other devices confirms that the data plane is unaffected, isolating the issue to control plane policing of inbound ICMP.

Exam trap

The trap here is that candidates confuse the direction of CoPP policing, assuming it applies to both inbound and outbound control plane traffic, when in fact only inbound traffic to the control plane is policed by default.

How to eliminate wrong answers

Option B is wrong because CoPP polices traffic entering the control plane, not traffic leaving it; ICMP echo replies are generated by the router's control plane and are not subject to the same inbound CoPP policy. Option C is wrong because the engineer checked CoPP statistics and saw drops specifically in the ICMP class, which points to CoPP rather than an interface ACL; an ACL would show drops in ACL counters, not CoPP class counters. Option D is wrong because the ICMP rate-limit feature (using the 'ip icmp rate-limit' command) limits ICMP unreachable messages, not echo replies or requests, and would not cause the described behavior of dropped packets in CoPP statistics.

Full explanation →
513
Multi-Selecthard

Which THREE symptoms indicate that a device's NTP synchronization is failing? (Choose THREE.)

Select 3 answers
A.The output of 'show clock' does not have an asterisk (*) next to the time.
B.The output of 'show ntp associations' shows a dot (.) instead of an asterisk (*) for the peer.
C.Syslog messages indicate 'NTP synchronization lost'.
D.The output of 'show ntp status' shows 'Clock is synchronized'.
E.The command 'ntp peer 10.1.1.1' is configured.
AnswersA, B, C

The asterisk indicates the clock is synchronized to an NTP source.

Why this answer

Option A is correct because the asterisk (*) next to the time in the output of 'show clock' indicates that the device's clock is synchronized via NTP. If the asterisk is missing, the clock is not synchronized, which is a direct symptom of NTP synchronization failure.

Exam trap

Cisco often tests the distinction between NTP association status symbols (asterisk vs. dot) and the synchronization state in 'show ntp status', leading candidates to confuse a reachable peer with a synchronized one.

Full explanation →
514
MCQeasy

In an MPLS L3VPN environment using MP-BGP, what is the default value of the BGP keepalive timer on Cisco IOS-XE?

A.30 seconds
B.60 seconds
C.90 seconds
D.180 seconds
AnswerB

Correct. The default keepalive timer is 60 seconds.

Why this answer

The default BGP keepalive timer is 60 seconds, as defined in RFC 4271 and implemented in Cisco IOS-XE.

Full explanation →
515
Multi-Selecthard

Which TWO statements about OSPFv2 LSA types and their troubleshooting significance are true? (Choose TWO.)

Select 2 answers
A.Type 5 LSAs are flooded throughout all OSPF areas, including the backbone area.
B.Type 7 LSAs are used in NSSA areas to advertise external routes and are translated to Type 5 LSAs at the ABR.
C.Type 3 LSAs describe stub network prefixes within an area and are generated by DRs.
D.Type 4 LSAs are used to advertise external routes into the OSPF domain by ASBRs.
E.Type 1 LSAs are summary LSAs that describe inter-area routes.
AnswersA, B

Correct. Type 5 (AS-External) LSAs are flooded across the entire OSPF domain, except stub areas and NSSAs (unless translated).

Why this answer

Type 5 LSAs are always flooded throughout the entire OSPF domain, and type 7 LSAs are used in NSSA areas to carry external routes. Type 3 LSAs are summary LSAs, not stub network LSAs. Type 4 LSAs advertise ASBR reachability, not external routes.

Type 1 LSAs are router LSAs, not summary LSAs.

Full explanation →
516
MCQhard

An engineer configures EIGRP named mode with an offset-list that increases the metric of a route on Router A. The route is still selected as the best path on Router A's neighbor, Router B, because Router B learns the same prefix via another EIGRP neighbor with a higher metric. Which is the most likely explanation?

A.The offset-list modifies the advertised distance (AD) sent to neighbors, but Router B ignores it.
B.The offset-list only affects the feasible distance (FD) on Router A; the advertised distance (AD) sent to Router B remains unchanged.
C.The offset-list is applied to the wrong interface; it must be applied to the outgoing interface towards Router B.
D.EIGRP named mode does not support offset-list; only classic mode supports it.
AnswerB

Router B uses the AD from Router A for its feasibility condition and metric comparison; the offset-list does not alter the AD.

Why this answer

The offset-list in EIGRP affects the composite metric (FD) of the route on the router where it is applied. However, the advertised distance (AD) sent to neighbors is not modified. Router B still sees the original AD from Router A and compares it with metrics from other neighbors.

Full explanation →
517
MCQhard

A network engineer runs the following command to troubleshoot a VRF-Lite redistribution issue: R1# debug ip routing vrf CUSTOMER_E Output: RT: add 10.3.3.0/24 via 10.1.1.2, ospf 200 metric [110/20] RT: add 10.3.3.0/24 via 10.1.1.2, eigrp 100 metric [90/131072] tag 0 RT: closer admin distance for 10.3.3.0/24, adding via eigrp 100 RT: add 10.3.3.0/24 to routing table, via eigrp 100 What does this output indicate?

A.The route 10.3.3.0/24 is added from OSPF 200 because it has a lower metric.
B.The route 10.3.3.0/24 is added from EIGRP 100 because it has a lower administrative distance than OSPF.
C.The route 10.3.3.0/24 is added from both OSPF and EIGRP, creating an equal-cost path.
D.The route 10.3.3.0/24 is not added to the routing table due to a tag mismatch.
AnswerB

Correct. EIGRP AD 90 is lower than OSPF AD 110, so EIGRP route is preferred.

Why this answer

The 'debug ip routing vrf' command shows route insertion and selection events for a specific VRF. The output shows that route 10.3.3.0/24 is learned from both OSPF 200 (with administrative distance 110) and EIGRP 100 (with administrative distance 90). Because EIGRP has a lower administrative distance, it is chosen as the best path and added to the routing table.

Full explanation →
518
MCQmedium

A network engineer runs the following command on Router R1: R1# show ipv6 traffic IPv6 statistics: Rcvd: 1000 total, 800 unicast, 200 multicast Sent: 900 total, 700 unicast, 200 multicast Errors: 0 Dropped: 0 ND statistics: NS: 50 received, 40 sent NA: 30 received, 20 sent RS: 10 received, 5 sent RA: 2 received, 8 sent Redirect: 0 received, 0 sent Based on this output, which statement is correct?

A.The router is not sending any Router Advertisements.
B.The router is receiving more Neighbor Solicitations than it is sending, which is expected.
C.There is a high number of errors in IPv6 traffic.
D.The router is dropping many packets.
AnswerB

NS received (50) vs sent (40) is typical as the router responds to queries.

Why this answer

Option B is correct because in IPv6, Neighbor Solicitations (NS) are used for address resolution and duplicate address detection. A router typically receives more NS messages than it sends, as hosts send NS to resolve the router's link-layer address, while the router sends NS primarily for DAD or to verify neighbor reachability. The output shows 50 NS received versus 40 sent, which aligns with this expected behavior.

Exam trap

Cisco often tests the expected asymmetry in Neighbor Solicitation counts between routers and hosts, where candidates mistakenly think a router should send more NS than it receives, but in practice, routers receive more NS from hosts performing address resolution.

How to eliminate wrong answers

Option A is wrong because the router has sent 8 Router Advertisements (RA) and received 2, indicating it is actively sending RAs, not failing to do so. Option C is wrong because the output explicitly shows 'Errors: 0', meaning no errors in IPv6 traffic. Option D is wrong because the output shows 'Dropped: 0', indicating no packets are being dropped.

Full explanation →
519
MCQmedium

A network engineer runs the following command on Router R1: R1# show ip nhrp 10.0.0.2/32 via 10.0.0.2, Tunnel0 created 00:15:30, expire 01:44:30 Type: dynamic, Flags: used NBMA address: 192.168.1.2 10.0.0.3/32 via 10.0.0.3, Tunnel0 created 00:10:20, expire 01:49:40 Type: dynamic, Flags: used NBMA address: 192.168.1.3 Based on this output, which statement is correct?

A.Both NHRP entries are static.
B.Both NHRP entries are active and dynamically learned.
C.The NHRP entries have expired.
D.The NBMA addresses are IPv6 addresses.
AnswerB

Type dynamic and flags used indicate active dynamic entries.

Why this answer

The output shows two NHRP entries with 'Type: dynamic', meaning they were learned dynamically (not statically configured). Both have 'Flags: used', indicating they are active. The expiration times show they will expire in about 1 hour 44 minutes and 1 hour 49 minutes, respectively.

Full explanation →
520
Multi-Selecthard

Which TWO statements correctly describe the behavior of route summarization in RIP? (Choose TWO.)

Select 2 answers
A.RIPv2 automatically summarizes routes to their classful boundary by default, and this behavior can be disabled with the 'no auto-summary' command.
B.Manual route summarization in RIP is configured using the 'network' command under the RIP process.
C.When manual summarization is configured, RIP automatically installs a discard route for the summary prefix to prevent routing loops.
D.The summary route in RIP is advertised with a metric equal to the lowest hop count among the component routes.
E.RIP supports both automatic and manual summarization only for classful networks.
AnswersA, D

Correct. RIPv2 has auto-summary enabled by default, which causes classful summarization. It can be disabled to allow VLSM and CIDR prefixes.

Why this answer

RIPv2 automatically summarizes classful routes by default; this can be disabled with 'no auto-summary'. Manual summarization is configured per interface with 'ip summary-address rip', and the summary route is advertised with the metric (hop count) of the best component route—i.e., the lowest hop count among the contributing routes. Option C is incorrect because while a discard route is often installed to prevent loops, the statement 'RIP automatically installs a discard route' is not universally true for all manual summarizations; in many implementations, the discard route is created only when the summary route is more specific than the component routes, not automatically for every manual summary.

Full explanation →
521
MCQmedium

A network engineer is troubleshooting a Cisco router that is configured for TACACS+ authentication. The engineer issues 'test aaa group tacacs+ admin cisco123 new-code' and receives 'FAILED'. The router can ping the TACACS+ server. What is the most likely cause?

A.TCP port 49 is blocked between the router and the TACACS+ server.
B.The TACACS+ server shared key is incorrect.
C.The username 'admin' does not exist on the TACACS+ server.
D.The TACACS+ server is not configured for the router's IP address.
AnswerA

Correct because TACACS+ uses TCP port 49; if blocked, the router cannot establish a connection to the server.

Why this answer

The 'test aaa group tacacs+ admin cisco123 new-code' command uses the 'new-code' flag, which forces the test to use the TACACS+ protocol (TCP port 49) rather than the older, less secure method. Since the router can ping the TACACS+ server, Layer 3 connectivity is fine, but a failed authentication with 'new-code' strongly indicates that TCP port 49 is blocked by a firewall or ACL between the router and the server. TACACS+ relies on TCP port 49 for all communication, so blocking this port causes immediate failure.

Exam trap

Cisco often tests the distinction between Layer 3 reachability (ping) and Layer 4 connectivity (TCP port 49), trapping candidates who assume that successful ping implies full connectivity to the TACACS+ server.

How to eliminate wrong answers

Option B is wrong because if the shared key were incorrect, the TACACS+ server would typically respond with an authentication failure (e.g., 'authen failed') rather than a generic 'FAILED' from the test command, and the 'new-code' flag does not bypass key validation. Option C is wrong because the 'test aaa' command simulates authentication against the TACACS+ server; if the username 'admin' did not exist, the server would return a 'user not found' or similar error, not a generic 'FAILED' from the router's perspective. Option D is wrong because if the TACACS+ server were not configured for the router's IP address, the server would either drop the packet silently or respond with a rejection, but the router's ability to ping the server suggests no Layer 3 filtering; however, the server's configuration for the router's IP is a server-side setting that would cause a different failure mode (e.g., no response), not a generic 'FAILED' from the test command.

Full explanation →
522
MCQhard

A DMVPN network uses PBR to route traffic from spoke routers to specific hubs based on source IP. After a hub failure, traffic from spoke 1 (source 192.168.1.0/24) is being sent to a backup hub, but the backup hub drops the traffic. Router R1 (spoke) shows: 'show ip policy' shows PBR applied, 'debug ip policy' shows traffic being forwarded to next-hop 10.1.1.2 (backup hub). Router R2 (backup hub) shows: 'show ip route 192.168.1.0' returns no route. What is the root cause?

A.The backup hub does not have a route to the source subnet, causing it to drop traffic. Add a static route or enable routing protocol on the backup hub for the spoke subnet.
B.The PBR route-map on the spoke is missing a 'set ip next-hop verify-availability' command, causing it to use the backup hub even when it is not fully reachable.
C.The spoke's routing table has a better route to the destination via the backup hub, overriding PBR.
D.The backup hub has a route to the source subnet but with a higher administrative distance, causing it to be ignored.
AnswerA

PBR forwards traffic to the backup hub, but without a return route, the hub cannot respond. This is a common issue in DMVPN with PBR when hubs are not fully meshed.

Why this answer

PBR on the spoke forwards traffic to the backup hub, but the backup hub does not have a route back to the source subnet (192.168.1.0/24). This causes asymmetric routing, where the backup hub drops the traffic because it cannot find a return route. The solution is to ensure the backup hub has a route to the spoke subnet, either via dynamic routing or a static route.

Full explanation →
523
MCQhard

An engineer configures OSPF on a link between two routers with MTU 1500 on one side and MTU 1400 on the other. The adjacency forms but is stuck in EXSTART. Which is the most likely explanation?

A.The router with the larger MTU sends DBD packets that exceed the smaller MTU, causing them to be dropped silently.
B.The router with the smaller MTU cannot process OSPF hello packets from the larger MTU side.
C.The adjacency is stuck because OSPF network type mismatch prevents DBD exchange.
D.The router with the larger MTU must have 'ip ospf mtu-ignore' configured to bypass the MTU check.
AnswerA

OSPF DBD packets are sized based on the outgoing interface MTU. If the packet is larger than the receiving interface MTU, it is dropped, preventing the exchange of LSAs.

Why this answer

When OSPF routers have mismatched MTUs, the router with the larger MTU (1500) will send Database Description (DBD) packets that include the full MTU size in the interface MTU field. The router with the smaller MTU (1400) will reject these packets because they exceed its MTU, causing them to be silently dropped. This prevents the DBD exchange from completing, leaving the adjacency stuck in EXSTART state.

Exam trap

Cisco often tests the specific state where the adjacency gets stuck (EXSTART) to distinguish between MTU mismatch and other OSPF issues, and the trap here is that candidates may incorrectly attribute the problem to hello packet failures or network type mismatches rather than the silent dropping of DBD packets due to MTU mismatch.

How to eliminate wrong answers

Option B is wrong because OSPF hello packets are small (typically 44 bytes) and will not be dropped due to MTU mismatch; the issue is with DBD packets, not hello packets. Option C is wrong because a network type mismatch would typically prevent the adjacency from forming at all or cause it to be stuck in INIT/2WAY, not EXSTART; EXSTART specifically indicates the DBD exchange phase has begun but cannot complete. Option D is wrong because the 'ip ospf mtu-ignore' command is used to bypass the MTU check on the router receiving the DBD packets, but it is not a requirement for the larger MTU side; the command should be configured on the router with the smaller MTU to allow larger DBD packets to be accepted.

Full explanation →
524
Drag & Dropmedium

Drag and drop the steps to configure a Control Plane Policing (CoPP) policy into the correct order, from first to last.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps
Order
1Step 1
2Step 2
3Step 3
4Step 4
5Step 5

Why this order

The correct order starts by identifying traffic with a class-map, then grouping classes in a policy-map, applying actions (e.g., drop), attaching the policy to the control-plane, and finally verifying the configuration. This follows the standard MQC (Modular QoS CLI) workflow.

Full explanation →
525
Multi-Selecthard

Which TWO statements correctly describe the behavior of the 'default-information originate' command in the context of route redistribution? (Choose TWO.)

Select 2 answers
A.In OSPF, the 'default-information originate' command always injects a default route into the OSPF domain, even if no default route exists in the routing table, provided the 'always' keyword is used.
B.In EIGRP, the 'redistribute static' command automatically injects a default route if a static default route is configured.
C.In EIGRP, the 'default-information originate' command will inject a default route only if a default route is present in the routing table, unless the 'always' keyword is configured.
D.In OSPF, the 'default-information originate always' command will inject a default route even if OSPF is not configured on any interface.
E.In both OSPF and EIGRP, the 'default-information originate' command automatically redistributes all connected routes into the routing protocol.
AnswersA, C

Correct. The 'always' keyword forces OSPF to originate a default route even if no default route is present in the routing table.

Why this answer

The 'default-information originate' command in OSPF and EIGRP has specific behaviors. In OSPF, it always originates a default route regardless of the routing table, unless the 'always' keyword is omitted and there is no default route in the routing table. In EIGRP, it requires a default route in the routing table to inject the default, unless the 'always' keyword is used.

The command does not automatically redistribute all routes; it only injects a default route.

Full explanation →
Page 6

Page 7 of 29

Page 8

All pages

1234567891011121314151617181920212223242526272829

Practice 300-410 by domain

Target a specific domain to shore up weak areas.

Layer 3 TechnologiesEIGRP TroubleshootingOSPF Troubleshooting (v2/v3)BGP TroubleshootingRoute RedistributionPolicy-Based Routing (PBR)VRF-LiteRoute Maps and Route FilteringAdministrative DistanceRoute SummarizationBidirectional Forwarding Detection (BFD)VPN TechnologiesMPLS OperationsMPLS L3VPNDMVPNIPsec Site-to-Site VPNIPv6 Tunneling TechniquesInfrastructure SecurityDevice Access ControlIPv4 Access Control ListsIPv6 Traffic Filtering and uRPFControl Plane Policing (CoPP)IPv6 First Hop SecurityInfrastructure ServicesDevice ManagementSNMP TroubleshootingNetwork Logging and SyslogEmbedded Event Manager (EEM)IP SLANetFlow and Flexible NetFlowSPAN, RSPAN, and ERSPANDHCP (IPv4 and IPv6)NAT and PAT
See all domains with question counts →