Knowledge + Practice

Cisco CCNP ENARSI 300-410 (300-410) — Questions 2026–2100

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

Take a mock exam Exam hub

Page 28 of 29

2026

MCQmedium

Examine this BGP configuration on router R6: router bgp 65006 bgp router-id 6.6.6.6 neighbor 10.6.6.7 remote-as 65007 neighbor 10.6.6.7 weight 200 ! What is the effect of the weight command?

A.It sets the weight of all routes learned from 10.6.6.7 to 200, making them preferred over routes with lower weight.

B.It sets the weight of routes sent to 10.6.6.7 to 200.

C.It has no effect because weight is only configurable under route-map.

D.It sets the MED value to 200 for routes from this neighbor.

AnswerA

Weight is locally significant and higher weight wins.

Why this answer

The weight command assigns a weight value to routes from a specific neighbor. Weight is a Cisco-specific attribute that is local to the router. Higher weight is preferred over other routes.

The default weight for eBGP routes is 0, so weight 200 makes routes from this neighbor preferred.

Full explanation →

2027

MCQmedium

A network engineer runs the following command to troubleshoot a Device Access Control issue: R1# debug nhrp NHRP: Receive Resolution Request via Tunnel0 10.1.1.2, target 192.168.1.1 NHRP: Send Resolution Reply via Tunnel0 to 10.1.1.2, target 192.168.1.1 What does this output indicate?

A.The router is acting as a NHRP server and successfully resolves the NBMA address for the target.

B.The router is a NHRP client and is requesting resolution for target 192.168.1.1.

C.The router is unable to resolve the target address because it does not have a mapping.

D.The NHRP process is failing due to a misconfigured authentication key.

AnswerA

The router receives a request and sends a reply, indicating it has the mapping and is providing resolution.

Why this answer

The debug output shows the router receiving a Resolution Request and immediately sending a Resolution Reply, which is the behavior of a Next Hop Resolution Protocol (NHRP) server (or hub) that has a mapping for the target 192.168.1.1. The router successfully resolves the Non-Broadcast Multiple Access (NBMA) address (10.1.1.2) for the target, indicating it is acting as a server in a DMVPN or similar overlay network.

Exam trap

Cisco often tests the distinction between NHRP client (spoke) and server (hub) roles by showing debug output; the trap here is that candidates may confuse sending a Resolution Reply with sending a Resolution Request, incorrectly assuming the router is a client.

How to eliminate wrong answers

Option B is wrong because the router is sending a Resolution Reply, not a Resolution Request, so it is not acting as a client requesting resolution. Option C is wrong because the router successfully sends a reply, meaning it does have a mapping for the target address. Option D is wrong because the debug output shows successful NHRP message exchange with no authentication errors; a misconfigured key would generate NHRP authentication failure messages, not a successful reply.

Full explanation →

2028

MCQhard

An engineer configured IP SLA 80 to monitor a remote server (192.168.100.100) using ICMP echo. The IP SLA is used in a track object for a static route. The engineer notices that the IP SLA state is 'Active', but the track object shows 'Down'. What is the most likely cause?

A.The track object is configured with a 'delay up' timer that has not yet expired.

B.The IP SLA probe is using a different source IP than expected.

C.The track object is referencing the wrong IP SLA number.

D.The router's routing table is full, preventing the track object from updating.

AnswerA

A 'delay up' timer forces the track to wait before transitioning to 'Up' after the IP SLA becomes 'Active'. This is a common cause of mismatch.

Why this answer

The track object can be configured with a threshold (e.g., 'threshold' or 'delay') that causes it to remain 'Down' even if the IP SLA is 'Active'. For example, if the track object has a 'delay up' timer, it will not transition to 'Up' immediately.

Full explanation →

2029

MCQmedium

Which of the following is a mandatory condition for a route to be considered a feasible successor in EIGRP?

A.The reported distance must be less than the feasible distance.

B.The metric must be equal to the successor's metric.

C.The next-hop router must be directly connected.

D.The route must be learned from the same AS.

AnswerA

This is the feasibility condition defined by EIGRP.

Why this answer

In EIGRP, a feasible successor is a backup route that can be used immediately if the successor fails. The mandatory condition for a route to be considered a feasible successor is that its reported distance (RD) must be less than the feasible distance (FD) of the current successor. This ensures the backup route is loop-free, as per the Diffusing Update Algorithm (DUAL).

Exam trap

Cisco often tests the misconception that a feasible successor must have a metric equal to or better than the successor, but the actual condition is that the reported distance must be strictly less than the feasible distance.

How to eliminate wrong answers

Option B is wrong because the metric does not need to be equal to the successor's metric; feasible successors can have a higher metric as long as the RD < FD condition is met. Option C is wrong because the next-hop router does not have to be directly connected; EIGRP can learn routes through multiple hops, and feasibility is based on distance, not adjacency. Option D is wrong because all EIGRP routes are learned from the same autonomous system by default; this is not a distinguishing condition for feasible successors.

Full explanation →

2030

MCQhard

What is the default ERSPAN ID range on Cisco IOS-XE devices?

A.1 to 256

B.1 to 1023

C.1 to 4096

D.1 to 65535

AnswerB

The ERSPAN ID range is 1 to 1023 on most Cisco IOS-XE platforms.

Why this answer

ERSPAN sessions use an ID from 1 to 1023 (or 1 to 256 on some platforms) to identify the session. The default is 1 if not specified.

Full explanation →

2031

MCQhard

An engineer configures OSPF on a link with an MTU of 1500 on one side and 1400 on the other. The OSPF neighbor state is stuck in EXSTART. What is the most likely explanation?

A.The router with the smaller MTU (1400) rejects DBD packets from the neighbor with MTU 1500 because they exceed the interface MTU, causing the EXSTART state.

B.The router with the larger MTU (1500) cannot process the smaller DBD packets from the neighbor.

C.The OSPF network type is point-to-point, which ignores MTU mismatches.

D.The 'ip ospf mtu-ignore' command is needed on both sides to bypass the MTU check.

AnswerA

OSPF DBD packets are sized based on MTU; a mismatch prevents the exchange from completing.

Why this answer

OSPF uses the MTU of the interface to determine the maximum size of Database Description (DBD) packets. If the MTU mismatches, the router with the smaller MTU will reject DBD packets that exceed its MTU, causing the neighbor to remain in EXSTART.

Full explanation →

2032

Multi-Selecthard

Which TWO configuration steps are required to enable an Embedded Event Manager (EEM) applet that sends an SNMP trap when a specific OID is polled? (Choose TWO.)

Select 2 answers

A.Configure 'event snmp oid 1.3.6.1.4.1.9.9.117.1.1.2.1.1 get-type exact' within the applet.

B.Ensure the 'snmp-server enable traps' command is configured globally.

C.Configure 'event syslog pattern "SNMP"' to capture the SNMP poll.

D.Configure an SNMP community string with read-write access inside the applet using 'action snmp-community'.

E.Configure 'event cli command "snmpwalk" sync yes' to trigger on SNMP walks.

AnswersA, B

This defines the SNMP event trigger, specifying the OID to monitor and the type of access (exact match) that will fire the applet.

Why this answer

To trigger an EEM applet on an SNMP OID poll, you must configure the 'event snmp oid' command and ensure SNMP is enabled globally. The other options are either unnecessary (like configuring a community for the applet itself) or incorrect (like using 'event syslog' or 'event cli').

Full explanation →

2033

MCQeasy

A network engineer runs the following command on Router R5: R5# show logging | include %LINEPROTO-5-UPDOWN *Mar 1 00:00:10.123: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/0, changed state to up *Mar 1 00:00:20.456: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/0, changed state to down *Mar 1 00:00:30.789: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/0, changed state to up *Mar 1 00:00:40.012: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/0, changed state to down *Mar 1 00:00:50.345: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/0, changed state to up *Mar 1 00:01:00.678: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/0, changed state to down Based on this output, what is the most likely problem?

A.The interface is administratively down.

B.There is a physical layer issue causing the interface to flap.

C.The interface is configured with a high bandwidth delay product.

D.The router is experiencing a high CPU load due to routing updates.

AnswerB

Repeated line protocol up/down messages indicate a flapping interface, typically due to physical or Layer 2 issues.

Why this answer

The output shows the line protocol on GigabitEthernet0/0 flapping every 10 seconds. This is a classic symptom of a flapping interface, often due to a physical issue (bad cable, faulty transceiver) or a Layer 2 problem (e.g., spanning tree topology changes, keepalive mismatch).

Full explanation →

2034

Multi-Selecthard

Which THREE symptoms indicate that a Cisco IOS router is experiencing issues with device access control due to misconfigured AAA local authentication? (Choose THREE.)

Select 3 answers

A.Users with correct credentials are repeatedly denied access, and the 'show aaa local user lockout' command shows no locked accounts.

B.The 'debug aaa authentication' output shows 'FAIL' for local authentication attempts even though the username and password are correctly configured.

C.Users are locked out after three failed attempts despite 'login block-for' not being configured.

D.The 'show aaa servers' output shows the RADIUS server status as 'DEAD'.

E.The 'show line' command shows that the line is in 'ready' state but login prompts are not displayed.

AnswersA, B, C

This suggests the authentication method list may not reference 'local' or the local database is not properly configured, causing failures without lockouts.

Why this answer

Option A is correct because when AAA local authentication is misconfigured, users with valid credentials can be repeatedly denied access without any lockout entries. The 'show aaa local user lockout' command would show locked accounts only if the 'aaa local authentication attempts max-fail' feature is enabled, but the absence of lockouts indicates the issue is not due to failed attempts but rather a misconfiguration in the local username/password database or AAA method list.

Exam trap

Cisco often tests the distinction between local authentication lockout (controlled by 'aaa local authentication attempts max-fail') and login blocking (controlled by 'login block-for'), causing candidates to incorrectly associate lockout behavior with the 'login block-for' feature rather than AAA local authentication parameters.

Full explanation →

2035

MCQmedium

Examine the following IPv6 ACL applied to an interface: ipv6 access-list FILTER permit ipv6 any any fragments deny ipv6 any any interface GigabitEthernet0/1 ipv6 traffic-filter FILTER in What is the effect of this configuration?

A.All IPv6 traffic is permitted because the permit statement matches any packet.

B.Only fragmented IPv6 packets are permitted; all other IPv6 traffic is denied.

C.The ACL is invalid because 'fragments' cannot be used with 'any any'.

D.The interface command is missing the 'ipv6 enable' prerequisite.

AnswerB

The first ACE permits only fragments; the second denies everything else, so only fragments pass.

Why this answer

Option B is correct because the ACL explicitly permits only fragmented IPv6 packets via the 'permit ipv6 any any fragments' statement, while the subsequent 'deny ipv6 any any' statement denies all other IPv6 traffic. Since ACLs are processed sequentially, the permit for fragments is evaluated first, allowing only fragmented packets; all non-fragmented packets are then denied by the second entry.

Exam trap

Cisco often tests the misconception that 'permit ipv6 any any' without the 'fragments' keyword matches all packets, but here the 'fragments' keyword narrows the match, causing candidates to overlook the sequential processing of ACL entries and incorrectly assume all traffic is permitted.

How to eliminate wrong answers

Option A is wrong because the permit statement includes the 'fragments' keyword, which restricts the match to only fragmented IPv6 packets, not all IPv6 traffic; thus, non-fragmented packets are denied by the subsequent deny statement. Option C is wrong because the 'fragments' keyword is fully valid with 'any any' in an IPv6 ACL; it simply limits the match to fragmented packets, and the ACL is syntactically correct. Option D is wrong because the 'ipv6 traffic-filter' command does not require the 'ipv6 enable' interface command as a prerequisite; IPv6 traffic filtering works independently as long as IPv6 is configured on the interface.

Full explanation →

2036

MCQmedium

A network engineer runs the following command on Router R7: R7# show ip route 172.16.0.0 Routing entry for 172.16.0.0/16 Known via "bgp 65000", distance 200, metric 0 Redistributing via bgp 65000 Last update from 10.0.0.1 00:00:20 ago Routing Descriptor Blocks: * 10.0.0.1, from 10.0.0.1, 00:00:20 ago Route metric is 0, traffic share count is 1 Based on this output, what type of BGP route is this?

A.This is an eBGP route because the distance is 200.

B.This is an iBGP route because the distance is 200.

C.This is a redistributed route from OSPF into BGP.

D.The distance of 200 is non-default and manually configured.

AnswerB

iBGP routes have a default administrative distance of 200, matching this output.

Why this answer

The administrative distance of 200 is the default for iBGP routes. eBGP routes have a default distance of 20. Therefore, this is an iBGP route.

Full explanation →

2037

MCQhard

An engineer configures SNMPv2c with a read-only community string 'public' on a router. The NMS can poll interface statistics, but when trying to poll OSPF neighbor states, the NMS receives no response. Which is the most likely explanation?

A.The OSPF MIB is not supported or not loaded on the router.

B.The community string 'public' is not allowed to access the OSPF MIB due to a missing 'snmp-server view' command.

C.OSPF neighbor states are only available via SNMPv3 due to security restrictions.

D.The NMS must use the OSPF process ID in the OID to poll neighbor states.

AnswerA

Some routers require the 'snmp-server enable traps ospf' command or the OSPF process to be configured to load the OSPF MIB; otherwise, the MIB objects are not available.

Why this answer

The most likely explanation is that the OSPF MIB is not supported or not loaded on the router. SNMPv2c with a read-only community string 'public' can poll standard interface MIB objects (like ifEntry) because those are part of the base IF-MIB, which is always loaded. However, OSPF neighbor states are defined in the OSPF-MIB (RFC 1850/4750), which is an enterprise-specific MIB that must be explicitly supported and loaded in the router's SNMP agent.

If the OSPF MIB is not present, the agent will not respond to GET requests for OSPF-related OIDs, even though the community string has read-only access.

Exam trap

Cisco often tests the misconception that SNMP community strings or views are the only reason for MIB access failures, when in fact the MIB itself may not be loaded or supported on the device.

How to eliminate wrong answers

Option B is wrong because the 'snmp-server view' command restricts access to specific MIB subtrees; if no view is configured, the default view allows access to all MIB objects, so a missing view does not block OSPF MIB access. Option C is wrong because OSPF neighbor states are available via SNMPv2c; there is no security restriction in SNMPv2c that limits OSPF MIB access to SNMPv3 only. Option D is wrong because the OSPF process ID is not part of the OID for polling neighbor states; the OSPF-MIB uses the ospfNbrEntry table indexed by neighbor IP address and interface, not the process ID.

Full explanation →

2038

MCQhard

An enterprise uses BGP to exchange routes with a service provider. After redistributing OSPF into BGP, some prefixes are missing. Router R1 config: router bgp 65001 redistribute ospf 1 match internal external 1 external 2 ! router ospf 1 redistribute bgp 65001 subnets R1# show ip bgp 10.10.10.0 % Network not in table R1# show ip ospf database external 10.10.10.0 Type-5 AS External Link States LS age: 360 Options: (No TOS-capability, DC) LS Type: AS External Link Link State ID: 10.10.10.0 (External Network Number) Advertising Router: 192.168.1.2 LS Seq Number: 80000001 Checksum: 0x1234 Length: 36 Network Mask: /24 Metric Type: 2 (Larger than any link state path) Metric: 20 Forward Address: 0.0.0.0 External Route Tag: 0 What is the root cause?

A.The OSPF external route is not installed in the routing table because of a mismatched metric type or LSA filtering.

B.The BGP redistribute command is missing the route-map to set the metric.

C.The OSPF process is not configured with the default-information originate command.

D.The BGP table is full and cannot accept more routes.

AnswerA

The route appears in the database but not in the routing table, so BGP cannot redistribute it.

Why this answer

The OSPF external route 10.10.10.0/24 has a Forward Address of 0.0.0.0, which means it is reachable via the advertising router. However, BGP redistribution of OSPF requires the route to be in the OSPF routing table, not just the database. The route may be missing due to an OSPF LSA filtering or a mismatched area.

The correct fix is to ensure the OSPF route is fully installed and not filtered.

Full explanation →

2039

MCQmedium

Given this IP SLA configuration on router R4: ip sla 40 icmp-echo 10.10.10.1 source-ip 172.16.1.1 frequency 15 ip sla schedule 40 life forever start-time now Which statement is true?

A.The source IP 172.16.1.1 must be configured on an interface of R4.

B.The source IP 172.16.1.1 can be any IP address, even if not local.

C.The operation will fail because frequency 15 is too high.

D.The operation will use TCP instead of ICMP.

AnswerA

The source-ip must belong to a local interface for the probe to be sourced correctly.

Why this answer

The configuration sends ICMP echo probes from 172.16.1.1 to 10.10.10.1 every 15 seconds. The source IP is explicitly set.

Full explanation →

2040

Multi-Selecthard

Which TWO statements about the 'ip domain-lookup' and DNS configuration on a Cisco IOS router are true? (Choose TWO.)

Select 2 answers

A.The 'ip domain-lookup' command is disabled by default on Cisco IOS routers.

B.The 'ip name-server' command can specify up to six DNS servers.

C.The 'ip domain-list' command adds a domain suffix to the search list for DNS queries.

D.The 'ip host' command creates a dynamic DNS entry that can be overwritten by a DNS server.

E.The 'show hosts' command displays only statically configured host entries.

AnswersB, C

Correct. The 'ip name-server' command allows configuring up to six DNS server addresses. The router will query them in order.

Why this answer

Option B is correct because the 'ip name-server' command on a Cisco IOS router can specify up to six DNS servers, which the router will query in order when resolving hostnames. This is a standard limitation documented in Cisco IOS configuration guides.

Exam trap

The trap here is that candidates often assume 'ip domain-lookup' is disabled by default (Option A) because they recall it must be explicitly enabled for certain features, but in fact it is enabled by default on most IOS versions.

Full explanation →

2041

MCQmedium

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) Based on this output, what is the operational state of uRPF on this interface?

A.uRPF is disabled

B.uRPF is enabled in strict mode

C.uRPF is enabled in loose mode

D.uRPF is enabled but only for multicast

AnswerB

The output confirms strict mode uRPF is active.

Why this answer

The output explicitly states 'IPv6 uRPF: strict mode (drop invalid packets)', which confirms that unicast Reverse Path Forwarding (uRPF) is enabled on the interface and operating in strict mode. In strict mode, the router verifies that the source address of an incoming packet matches a route in the FIB pointing back to the same interface; if not, the packet is dropped. This is a direct read of the operational state from the show command.

Exam trap

Cisco often tests the ability to read the exact operational state from the 'show ipv6 interface' output, where candidates may overlook the explicit 'strict mode' line and instead assume uRPF is disabled or confuse it with loose mode based on incomplete knowledge of the command syntax.

How to eliminate wrong answers

Option A is wrong because the output clearly shows 'IPv6 uRPF: strict mode', indicating uRPF is enabled, not disabled. Option C is wrong because the output specifies 'strict mode', not 'loose mode'; loose mode would only require a matching route in the FIB regardless of the incoming interface. Option D is wrong because uRPF operates on unicast traffic, not multicast; the output makes no mention of multicast filtering, and uRPF is not designed for multicast.

Full explanation →

2042

MCQeasy

An engineer is troubleshooting why the NMS is not receiving SNMP traps from router R8 after a recent configuration change. The engineer added 'snmp-server host 10.1.1.100 version 2c public' and 'snmp-server enable traps' but forgot to remove the old 'snmp-server host 10.1.1.200 version 2c public' command. The NMS at 10.1.1.100 can receive traps from other devices. What is the most likely cause?

A.The engineer did not configure the SNMP community string 'public' on the router.

B.The old 'snmp-server host' command for 10.1.1.200 is causing a conflict, preventing traps to the new host.

C.The engineer needs to remove the old host command before adding the new one.

D.The router requires a reload after adding a new 'snmp-server host' command.

AnswerA

Correct because the 'snmp-server host' command references a community string that must be defined; without it, traps are not sent.

Why this answer

Option A is correct because the router's SNMP agent will not send traps to any host unless the community string referenced in the 'snmp-server host' command is first defined with an 'snmp-server community' command. Without 'snmp-server community public ro' (or rw), the router has no valid community string to include in the trap PDU, so the NMS at 10.1.1.100 will never receive traps from R8, even though the host and enable commands are present.

Exam trap

Cisco often tests the misconception that adding 'snmp-server host' alone is sufficient to send traps, when in fact the community string must be explicitly configured with 'snmp-server community' for the trap to be generated and transmitted.

How to eliminate wrong answers

Option B is wrong because multiple 'snmp-server host' commands can coexist; each defines a separate trap destination, and there is no conflict that would block traps to the new host. Option C is wrong because there is no requirement to remove an old host command before adding a new one; the router supports multiple trap receivers simultaneously. Option D is wrong because SNMP configuration changes, including 'snmp-server host', take effect immediately without requiring a router reload.

Full explanation →

2043

MCQhard

A large enterprise network is experiencing intermittent BGP session resets between R1 and R2. R1 has the following relevant configuration: ! R1 control-plane service-policy input CoPP ! access-list 100 permit tcp any any eq bgp class-map match-all BGP-CLASS match access-group 100 ! policy-map CoPP class BGP-CLASS police 8000 conform-action transmit exceed-action drop class class-default police 1000000 conform-action transmit exceed-action drop ! R2 shows: R2#show ip bgp summary BGP router identifier 2.2.2.2, local AS number 65002 BGP table version is 1, main routing table version 1 Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 1.1.1.1 4 65001 12345 12345 0 0 0 00:02:34 0 What is the root cause?

A.The BGP session is flapping because the CoPP policy drops BGP keepalive packets when the police rate is exceeded.

B.The access-list 100 is misconfigured; it should match TCP port 179 specifically.

C.The class-default police rate is too low, causing all traffic to be dropped, including BGP.

D.The CoPP policy should be applied to the control-plane input direction, but the service-policy is missing the 'control-plane' keyword.

AnswerA

BGP keepalives are small, but if the overall BGP traffic (including updates) exceeds 8000 bps, the policer drops packets, causing keepalive loss and hold timer expiry.

Why this answer

The BGP session resets because the CoPP policy applies a police rate of 8000 bps to BGP packets matched by access-list 100. When BGP keepalive or other packets exceed this rate, they are dropped, causing the hold timer to expire and the session to reset. The short uptime of 2 minutes 34 seconds on R2 confirms the session is flapping due to packet loss.

Exam trap

Cisco often tests the misconception that CoPP misconfiguration is always due to ACL or direction errors, but here the trap is that a seemingly reasonable police rate (8000 bps) is actually too low for BGP control-plane traffic, causing intermittent drops that mimic a flapping session.

How to eliminate wrong answers

Option B is wrong because access-list 100 already matches TCP any any eq bgp, which correctly identifies BGP traffic (TCP port 179); the issue is not the ACL but the policing rate. Option C is wrong because the class-default police rate of 1,000,000 bps is high enough to pass most traffic, and BGP packets are classified into the BGP-CLASS, not class-default, so the class-default rate is irrelevant to the BGP drops. Option D is wrong because the service-policy input CoPP is correctly applied under the control-plane configuration; the 'control-plane' keyword is not missing—it is the parent context for the service-policy command.

Full explanation →

2044

MCQmedium

A network engineer runs the following command to troubleshoot an OSPF adjacency issue: R1# debug ip ospf adj OSPF: Interface GigabitEthernet0/0 going Up OSPF: Send with youngest orig age 0 OSPF: Rcv DBD from 2.2.2.2 seq 0x1A opt 0x52 flag 0x7 len 32 mtu 1500 state INIT OSPF: First DBD and we are not SLAVE OSPF: Rcv DBD from 2.2.2.2 seq 0x1A opt 0x52 flag 0x7 len 32 mtu 1500 state EXSTART OSPF: Nbr 2.2.2.2 has larger interface MTU What does this output indicate?

A.OSPF adjacency is forming correctly, moving to FULL state.

B.OSPF adjacency is stuck due to MTU mismatch; the neighbor has a larger MTU.

C.OSPF adjacency is stuck because the router is not the DR/BDR.

D.OSPF adjacency is stuck due to authentication mismatch.

AnswerB

The debug explicitly states 'Nbr has larger interface MTU', which blocks adjacency.

Why this answer

The debug output shows that R1 receives a Database Description (DBD) packet from neighbor 2.2.2.2 with the INIT and EXSTART states, and then explicitly states 'Nbr 2.2.2.2 has larger interface MTU'. This indicates an MTU mismatch where the neighbor's interface MTU (1500) is larger than R1's interface MTU, preventing the OSPF adjacency from progressing beyond the EXSTART state. Option B is correct because the adjacency is stuck due to the MTU mismatch, as OSPF requires matching MTU values on both sides for DBD exchange to complete.

Exam trap

Cisco often tests the MTU mismatch trap by showing debug output with 'Nbr has larger interface MTU' and candidates mistakenly think the adjacency is progressing normally (Option A) or confuse it with DR/BDR election issues (Option C), but the key is that OSPF adjacency will not form until MTU values match.

How to eliminate wrong answers

Option A is wrong because the adjacency is not forming correctly; it is stuck in EXSTART due to the MTU mismatch, not moving to FULL state. Option C is wrong because the DR/BDR election occurs after the adjacency reaches the 2-WAY state, and this issue is in EXSTART, which is before that election; the debug output shows no DR/BDR-related problem. Option D is wrong because authentication mismatches would generate different debug messages (e.g., 'auth type mismatch' or 'auth key mismatch') and would typically cause the adjacency to be stuck in INIT or EXSTART with authentication errors, not an MTU size message.

Full explanation →

2045

MCQhard

Consider the following configuration on Router R4: router eigrp 100 redistribute ospf 1 metric 10000 100 255 1 1500 router ospf 1 redistribute eigrp 100 metric 20 metric-type 1 subnets What is a potential issue with this configuration?

A.The configuration is correct and will work without issues.

B.The 'metric-type 1' in OSPF redistribution may cause EIGRP routes to be preferred over OSPF routes.

C.Mutual redistribution without route filtering can cause routing loops or suboptimal routing.

D.The EIGRP metric values are invalid because load must be between 1 and 255.

AnswerC

Without filtering, routes can be redistributed back and forth, causing loops.

Why this answer

Mutual redistribution without route filtering or administrative distance adjustments can cause routing loops or suboptimal routing. The configuration does not include any route-maps or distribute-lists to control which routes are redistributed, which is a common pitfall.

Full explanation →

2046

MCQmedium

Examine the following partial configuration: username admin privilege 15 secret 5 $1$abcdefg$hashedvalue username operator privilege 1 password cisco ! line console 0 login local ! line vty 0 4 login local transport input ssh What is a potential security issue with this configuration?

A.The 'operator' username uses a password instead of a secret, which is stored insecurely in the configuration.

B.The 'admin' user has privilege 15, which is too high for administrative access.

C.The console line is missing the 'transport input' command.

D.The VTY lines should use 'login' without 'local' to allow remote authentication.

AnswerA

The 'password' keyword stores the password in a reversible format (type 7 or clear), whereas 'secret' uses MD5 hashing.

Why this answer

Option A is correct because the 'operator' username uses a 'password' keyword instead of 'secret', which means the password is stored in plaintext (or weakly hashed) in the running configuration. Cisco recommends using 'secret' with a strong hash algorithm (e.g., MD5 or SHA-256) to protect credentials from being easily compromised if the configuration is viewed. This is a direct violation of secure device access best practices.

Exam trap

Cisco often tests the distinction between 'password' and 'secret' in username configurations, and the trap here is that candidates may overlook the security implications of using 'password' instead of 'secret' for non-privileged users, assuming it only matters for enable passwords.

How to eliminate wrong answers

Option B is wrong because privilege 15 is the standard highest privilege level for full administrative access, and it is appropriate for an 'admin' user; there is no security issue with using privilege 15 for administrative accounts. Option C is wrong because the console line does not require a 'transport input' command by default, as console access is out-of-band and typically uses a direct serial connection; the absence of 'transport input' does not create a security vulnerability. Option D is wrong because 'login local' on VTY lines is the correct method to enforce local username/password authentication; using 'login' without 'local' would allow any password (including no password) if no other authentication method is configured, which is less secure.

Full explanation →

2047

MCQmedium

A network engineer is troubleshooting a connectivity issue between two routers R1 and R2 connected via GigabitEthernet0/0. The engineer notices that R1 can ping its own IPv6 address 2001:db8:1::1/64, but cannot ping R2's interface address 2001:db8:1::2/64. The output of 'show ipv6 interface GigabitEthernet0/0' on R1 indicates that IPv6 is enabled and the interface is up/up. The engineer checks the access list applied to the interface and sees an inbound IPv6 ACL that permits only ICMPv6 echo requests from a specific source. What is the most likely cause of the ping failure?

A.The ACL is applied inbound on R1 and does not permit ICMPv6 echo replies from R2.

B.The ACL is applied outbound on R1 and blocks the echo request.

C.IPv6 unicast-routing is not enabled on R1.

D.The ACL is missing a permit statement for IPv6 neighbor discovery (ND) messages.

AnswerA

Correct because ICMPv6 echo replies are sourced from the destination address (R2) and must be permitted inbound on R1 for the ping to succeed.

Why this answer

The inbound ACL on R1 is blocking the ICMPv6 echo reply from R2, because the ACL only permits echo requests from a specific source, not replies. For a successful ping, both the echo request and echo reply must be permitted. The reply is sourced from R2's address, which is not matched by the permit statement.

Full explanation →

2048

MCQhard

An enterprise is redistributing EIGRP into OSPF on router R1. R1 has the following configuration: router eigrp 100 redistribute ospf 1 metric 10000 100 255 1 1500 route-map RMAP-OSPF. Router R2 (OSPF-only) shows: 'show ip route 10.1.1.0' as an O E2 route with metric 20, but 'show ip ospf database external 10.1.1.0' shows the forwarding address is 0.0.0.0. Router R3 (also OSPF) cannot reach 10.1.1.0. What is the root cause?

A.The redistributed route's next-hop is not reachable via OSPF, causing the forwarding address to be 0.0.0.0, but R1's router ID is not reachable from R3 due to a missing OSPF network statement.

B.The route-map RMAP-OSPF is setting the metric to 20, which is too high and causes the route to be suppressed.

C.The EIGRP process on R1 has a distribute-list blocking the route.

D.The OSPF process on R1 has a route-map applied inbound that filters the route.

AnswerA

If the next-hop is not in OSPF, the forwarding address is set to 0.0.0.0, meaning the packet should be sent to the advertising router (R1). If R1's router ID is not reachable (e.g., R1's OSPF interfaces are not advertised correctly), R3 cannot reach the route.

Why this answer

When redistributing into OSPF, if the redistributed route's next-hop is not reachable via OSPF (e.g., it is an EIGRP-learned route with a next-hop that is not in the OSPF domain), the forwarding address is set to 0.0.0.0. This causes other OSPF routers to try to reach the originating router (R1) as the next-hop. However, if R1's OSPF router ID is not reachable or if there is a filtering issue, the route may be installed but unreachable.

In this scenario, the route-map RMAP-OSPF may be filtering the route or setting incorrect metrics, but the forwarding address issue suggests that the next-hop is not being advertised correctly. The root cause is likely that the redistributed route's next-hop is not in the OSPF domain, so R1 should use a route-map to set the forwarding address to itself (e.g., set forwarding-address 0.0.0.0 is default, but if the next-hop is reachable, it should be set to the router's own interface IP).

Full explanation →

2049

MCQhard

A network engineer configured IP SLA 50 to monitor a remote router's loopback (5.5.5.5) using ICMP echo. The IP SLA is linked to a track object that is used in a PBR (policy-based routing) route-map. The engineer notices that the PBR is not applying the alternate path when the IP SLA goes down. The track object shows 'Down'. What is the most likely misconfiguration?

A.The route-map is missing the 'set ip next-hop verify-availability' command with the track object.

B.The IP SLA probe is using the wrong source interface.

C.The track object is configured with a delay that prevents immediate reaction.

D.The PBR is applied to the wrong interface.

AnswerA

Without 'verify-availability', PBR does not check the track state and will continue using the primary next-hop even if the track is down.

Why this answer

PBR with set ip next-hop verify-availability requires the track object to be referenced correctly in the route-map. If the route-map uses 'set ip next-hop verify-availability' but does not include the track keyword, PBR will not react to the IP SLA state.

Full explanation →

2050

MCQhard

A network engineer is troubleshooting a connectivity issue where a host on VLAN 10 cannot reach a server on VLAN 20. Both VLANs are on the same switch, which is running IPv6. The engineer checks the switch and finds that uRPF (unicast Reverse Path Forwarding) is enabled in strict mode on the VLAN 20 interface. The host's IPv6 address is 2001:db8:10::100/64, and the server's address is 2001:db8:20::200/64. The switch has a default route pointing to a next-hop router. The host sends traffic to the server, but the switch drops the packets. What is the most likely cause?

A.The uRPF strict mode check fails because the switch does not have a specific route to the host's subnet pointing back to the VLAN 10 interface.

B.The uRPF mode should be loose mode to allow traffic from any source as long as there is a route in the FIB.

C.The host's IPv6 address is not in the switch's neighbor cache.

D.The switch has an ACL that blocks traffic between VLANs.

AnswerA

Correct because uRPF strict mode requires a matching route in the FIB that points to the same interface on which the packet was received; a default route does not satisfy this requirement.

Why this answer

With uRPF strict mode enabled on the VLAN 20 interface, the switch checks that the source IP address of incoming packets (2001:db8:10::100) is reachable via the same interface on which the packet arrived. Since the switch only has a default route pointing to a next-hop router and no specific route for the 2001:db8:10::/64 subnet pointing back to the VLAN 10 interface, the FIB lookup for the source address fails the strict uRPF check, causing the switch to drop the packet.

Exam trap

Cisco often tests the distinction between strict and loose uRPF modes, and the trap here is that candidates assume a default route is sufficient for strict mode, not realizing that strict mode requires a specific route pointing back to the source's ingress interface.

How to eliminate wrong answers

Option B is wrong because loose mode only requires that a route exists in the FIB for the source address, not that it points back to the incoming interface; while that would allow the traffic, it is not the most likely cause given that strict mode is already enabled and failing. Option C is wrong because the neighbor cache is used for Layer 2 address resolution (NDP), not for uRPF validation; uRPF checks the FIB for a matching route, not the neighbor cache. Option D is wrong because the question states that uRPF is enabled and the symptom matches a uRPF failure; an ACL would produce a different drop reason (e.g., 'denied by ACL') and is not indicated as the cause.

Full explanation →

2051

Multi-Selecthard

Which TWO statements about MPLS Traffic Engineering (MPLS-TE) are true? (Choose TWO.)

Select 2 answers

A.MPLS-TE uses RSVP-TE to signal label-switched paths (LSPs) and reserve bandwidth.

B.The command 'show mpls traffic-eng tunnels' displays the status of MPLS-TE tunnels.

C.MPLS-TE uses LDP to distribute labels for the TE tunnels.

D.MPLS-TE requires BGP to carry the TE attributes across the network.

E.MPLS-TE requires a full mesh of IBGP sessions between all routers.

AnswersA, B

Correct. RSVP-TE is the standard signaling protocol for MPLS-TE.

Why this answer

MPLS-TE allows explicit path selection using RSVP-TE to reserve bandwidth and set up LSPs. The 'show mpls traffic-eng tunnels' command displays tunnel status. Option A is correct: RSVP-TE is the signaling protocol used for MPLS-TE.

Option B is correct: 'show mpls traffic-eng tunnels' is a valid verification command. Option C is false: MPLS-TE does not use LDP; it uses RSVP-TE. Option D is false: MPLS-TE uses the Resource Reservation Protocol (RSVP) for signaling, not BGP.

Option E is false: MPLS-TE does not require a full mesh of IBGP sessions; it uses IGP with TE extensions.

Full explanation →

2052

MCQmedium

In MPLS, what is the purpose of the TTL propagation feature?

A.It propagates the MPLS label stack to all routers in the domain.

B.It copies the IP TTL into the MPLS TTL at the ingress LER, allowing traceroute to see each hop in the MPLS path.

C.It prevents TTL from being decremented in the MPLS core for security purposes.

D.It ensures that the MPLS TTL is always equal to the IP TTL at the egress LER.

AnswerB

When enabled, the IP TTL is decremented and copied to the MPLS label, so each LSR decrements the TTL, making traceroute visible.

Why this answer

The TTL propagation feature controls how the IP TTL is handled when packets enter an MPLS domain. By default, the IP TTL is copied to the MPLS TTL (propagation), allowing traceroute to work across the MPLS network. When disabled, the MPLS TTL is set to 255, hiding the core from traceroute.

Full explanation →

2053

MCQhard

A network uses PBR to route traffic from a specific host (10.1.1.1) through a VPN tunnel (next-hop 10.10.10.2). After a VPN tunnel failure, traffic from this host is being dropped. Router R1 shows: 'show ip policy' shows PBR applied, 'debug ip policy' shows 'PBR: no route to next-hop 10.10.10.2', but 'show ip route 10.10.10.2' shows a route via a different interface. What is the root cause?

A.The next-hop 10.10.10.2 is not directly connected; it is reachable via a route. PBR requires the next-hop to be directly connected. Use a directly connected next-hop or configure a static route to make it directly connected.

B.The route-map is missing a 'set ip next-hop verify-availability' command, causing PBR to use the next-hop even when it is not reachable.

C.The routing table on R1 has a better route to the destination via the VPN tunnel, overriding PBR.

D.The VPN tunnel is down, causing the next-hop to be unreachable.

AnswerA

PBR's 'set ip next-hop' command requires the next-hop to be on a directly connected subnet. If it is reachable via a route, PBR will not use it and will drop the packet. This is a common misconfiguration when the next-hop is on a remote subnet.

Why this answer

PBR requires the next-hop to be directly reachable (i.e., on a directly connected subnet). If the next-hop is reachable via a route (e.g., through another router), PBR will not use it because it expects a direct connection. In this case, 10.10.10.2 is reachable via a route, not directly connected, so PBR drops the traffic.

The solution is to ensure the next-hop is directly connected or use a different next-hop that is directly connected.

Full explanation →

2054

Drag & Dropmedium

Drag and drop the steps to set up a PE-CE BGP session in an MPLS L3VPN 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 with defining the VRF and its RD/RT on the PE, then assigning the VRF to the CE-facing interface. After that, the PE interface is configured with an IP address and BGP is enabled in the VRF address-family. Finally, the BGP neighbor is activated under the VRF address-family to establish the PE-CE session.

Full explanation →

2055

MCQhard

An engineer configures route redistribution from EIGRP into OSPF. The redistributed routes appear in the OSPF database but are not installed in the routing table of other OSPF routers. Which is the most likely explanation?

A.The OSPF process on the redistributing router does not have a router-id configured.

B.The redistributed routes have a metric of 0, which OSPF treats as unreachable.

C.The administrative distance of OSPF external routes (110) is higher than EIGRP (90), so the EIGRP routes are preferred.

D.The redistribute command is missing the subnets keyword, causing only classful routes to be redistributed.

AnswerB

OSPF requires a non-zero metric for external routes; a metric of 0 (default for type 1) can cause the route to be ignored.

Why this answer

When redistributing into OSPF, a seed metric must be specified. If not, OSPF defaults to a metric of 20 for external type 2 routes, but if the metric-type is set to 1, the default metric is 0, which may cause the route to be considered unreachable or not installed.

Full explanation →

2056

MCQhard

An enterprise network uses EIGRP with route summarization. Router R1 has the following configuration: interface GigabitEthernet0/0 ip summary-address eigrp 100 10.1.0.0 255.255.252.0. Router R2, connected to R1 via GigabitEthernet0/0, shows: 'show ip route eigrp' includes 10.1.0.0/22 but not the more specific route 10.1.1.0/24. Hosts in subnet 10.1.1.0/24 are unreachable from R2. What is the root cause?

A.R1 has a missing null0 route for the summary, causing it to not advertise the summary correctly.

B.The summary address 10.1.0.0/22 is configured on the wrong interface; it should be on the interface facing the internal network.

C.R1's summary address 10.1.0.0/22 includes the 10.1.1.0/24 subnet, so R1 suppresses the more specific route, and R2 only learns the summary. This is expected behavior, but if the summary does not match the actual network, reachability fails.

D.R2 has a route filter that blocks the 10.1.1.0/24 route.

AnswerC

EIGRP automatically suppresses more specific routes when a summary is configured. If the summary is correct, this is normal; however, if the summary is too broad or incorrect, specific subnets may be unreachable.

Why this answer

Option C is correct because EIGRP's route summarization behavior is to suppress more specific routes (e.g., 10.1.1.0/24) when a covering summary (10.1.0.0/22) is configured on an interface. R2 learns only the summary route, but if the actual network 10.1.1.0/24 is not reachable via the summary's next hop (e.g., because the summary includes subnets not actually present or because R1 lacks a discard route), R2 cannot reach those hosts. The root cause is that the summary route does not accurately represent the reachable subnets, leading to black-holing.

Exam trap

The trap here is that candidates often assume EIGRP summarization always works correctly once configured, failing to realize that the summary route must exactly match the set of reachable subnets; otherwise, the suppressed specifics lead to unreachability, not a configuration error on the summary command itself.

How to eliminate wrong answers

Option A is wrong because a missing null0 route for the summary would cause R1 to not have a local discard route for the summary, potentially leading to routing loops or incorrect forwarding, but it does not prevent R1 from advertising the summary to R2; the summary is still advertised. Option B is wrong because the summary-address command is correctly placed on the interface facing R2 (the outbound interface) to aggregate routes being advertised to R2; placing it on the interface facing the internal network would not affect what R2 learns. Option D is wrong because there is no evidence of a route filter on R2; the show ip route eigrp output shows the summary route, and the absence of the /24 is due to EIGRP's suppression behavior, not filtering.

Full explanation →

2057

MCQmedium

A network engineer runs the following command on Router R1: R1# show ip route 10.1.1.0 Routing entry for 10.1.1.0/24 Known via "eigrp 100", distance 170, metric 2560000 Redistributing via eigrp 100 Advertised by eigrp 100 (self originated) Last update from 10.2.2.2 on GigabitEthernet0/1, 00:00:10 ago Routing Descriptor Blocks: * 10.2.2.2, from 10.2.2.2, 00:00:10 ago, via GigabitEthernet0/1 Route metric is 2560000, traffic share count is 1 Total delay is 100 microseconds, minimum bandwidth is 100000 Kbit Reliability 255/255, minimum MTU 1500 Loading 1/255, Hops 1 Based on this output, what is the problem?

A.The route 10.1.1.0/24 is an internal EIGRP route because the administrative distance is 90.

B.The route is redistributed into EIGRP from another protocol, as indicated by the distance of 170 and the 'self originated' message.

C.The route is learned from a neighbor with a metric of 2560000, which is the default for redistributed routes.

D.The route is not being advertised to any EIGRP neighbors because it is marked as 'self originated'.

AnswerB

The distance of 170 and the 'self originated' flag indicate redistribution into EIGRP.

Why this answer

The output shows a route learned via EIGRP with an administrative distance of 170, which is the default for external EIGRP routes. The route is marked as 'Redistributing via eigrp 100' and 'Advertised by eigrp 100 (self originated)', indicating that this route was redistributed into EIGRP from another protocol. The problem is that the route is both learned and redistributed by the same router, which could cause a routing loop if not filtered.

Full explanation →

2058

MCQhard

An engineer configures Control Plane Policing (CoPP) on a router to protect the management plane. After applying the policy, the router becomes unreachable via SSH, but the console is still accessible. The engineer checks the CoPP policy and sees that SSH traffic is permitted. Which is the most likely explanation?

A.The class-map for SSH uses 'match protocol ssh' but the SSH server is configured on a non-default port, so the traffic is not matched and is dropped by the default class.

B.The CoPP policy is applied in the input direction, but SSH traffic is generated by the router itself, so it is not affected by input policing.

C.The CoPP policy uses 'rate-limit' in bps instead of pps, causing all traffic to be dropped due to a misconfiguration.

D.The CoPP policy has an explicit deny statement before the permit statement for SSH, so SSH traffic is denied.

AnswerA

CoPP class-maps that match by protocol may not match non-standard ports. If the default class has a drop action, SSH traffic will be dropped.

Why this answer

CoPP policies have an implicit deny at the end. If the class-map for SSH does not match the traffic correctly (e.g., using the wrong protocol or port), SSH packets will fall through to the default class, which may have a deny action. Additionally, the default class behavior is to permit traffic if not explicitly configured, but if the default class is configured with a drop action, all unmatched traffic is dropped.

A common edge case is when the class-map uses 'match protocol ssh' but the router uses a different port for SSH (e.g., port 2222), so the traffic is not matched and is dropped by the default class.

Full explanation →

2059

MCQhard

A network engineer runs the following command to troubleshoot PAT exhaustion: R1# show ip nat statistics Total active translations: 1024 (0 static, 1024 dynamic; 1024 extended) Outside interfaces: GigabitEthernet0/1 Inside interfaces: GigabitEthernet0/0 Hits: 50000 Misses: 10 CEF Translated packets: 45000, CEF Punted packets: 5000 Expired translations: 2000 Dynamic mappings: -- Inside Source [Id: 1] access-list NAT permit ip 10.0.0.0 0.255.255.255 any refcount 1024, pool MyPool pool MyPool: netmask 255.255.255.240 start 203.0.113.1 end 203.0.113.14 type generic, total addresses 14, allocated 14 (100%), misses 0 What is the most likely issue?

A.The pool is exhausted; PAT is using all addresses, but port exhaustion may occur.

B.The access list is misconfigured, blocking traffic.

C.The outside interface is down.

D.Static translations are missing.

AnswerA

All 14 addresses are allocated, meaning PAT is using them, but with 1024 translations, ports may be running out.

Why this answer

The output shows that the NAT pool 'MyPool' has 14 addresses, all of which are allocated (100% usage), and there are 1024 active translations. With only 14 public IPs, PAT can theoretically support up to 14 * 65535 = 917,490 ports, but the pool exhaustion indicates that all addresses are in use, and the high number of translations suggests that port exhaustion is imminent or occurring, as each address can only handle a finite number of simultaneous sessions before ports are exhausted.

Exam trap

Cisco often tests the misconception that PAT exhaustion only occurs when the pool has a single address, but here the trap is that even with multiple addresses, all can be fully allocated, leading to port exhaustion per address.

How to eliminate wrong answers

Option B is wrong because the access list 'NAT permit ip 10.0.0.0 0.255.255.255 any' is correctly configured to match the inside network, and the refcount of 1024 shows it is actively matching traffic. Option C is wrong because the outside interface GigabitEthernet0/1 is listed in the output, and the presence of hits (50000) and misses (10) indicates that the interface is operational and processing traffic. Option D is wrong because static translations are not required for PAT; the issue is dynamic pool exhaustion, not a lack of static entries.

Full explanation →

2060

Multi-Selecthard

Which TWO actions will prevent unauthorized access to a Cisco IOS-XE device's console port? (Choose TWO.)

Select 2 answers

A.Configure 'login authentication default' under the console line to require AAA authentication.

B.Configure 'exec-timeout 0 0' under the console line to prevent idle sessions from timing out.

C.Configure 'transport input none' under the console line to block all inbound connections.

D.Configure 'no exec' under the console line to disable EXEC sessions on the console port.

E.Configure 'password cisco' and 'login' under the console line to require a local password.

AnswersA, E

This command applies the default AAA authentication method list to the console line, requiring users to authenticate before gaining access.

Why this answer

Option A is correct because configuring 'login authentication default' under the console line forces the device to use AAA (Authentication, Authorization, and Accounting) services for console login. This prevents unauthorized access by requiring valid credentials verified by a centralized AAA server (e.g., RADIUS or TACACS+), rather than relying on a local password that could be compromised or shared.

Exam trap

Cisco often tests the distinction between commands that actually prevent unauthorized access versus those that modify session behavior or apply to different line types, so the trap here is assuming that disabling idle timeout (exec-timeout 0 0) or blocking transport input enhances security, when in fact they either weaken it or are irrelevant to console port access.

Full explanation →

2061

Multi-Selecthard

Which TWO statements about SNMPv3 security models are true? (Choose TWO.)

Select 2 answers

A.The noAuthNoPriv security level provides no authentication and no encryption.

B.The authPriv security level requires both authentication and encryption.

C.The authNoPriv security level uses encryption but no authentication.

D.SNMPv3 always requires encryption for all security levels.

E.The 'priv' keyword in the snmp-server group command disables authentication.

AnswersA, B

This is the least secure level, often used for read-only access.

Why this answer

SNMPv3 defines three security levels. The noAuthNoPriv level uses a community-string-like mechanism without authentication or encryption, making it the least secure option. This is correct because it matches the RFC 3414 definition where no authentication and no privacy (encryption) are applied.

Exam trap

Cisco often tests the misconception that authNoPriv includes encryption or that the 'priv' keyword disables authentication, leading candidates to confuse the purpose of the 'auth' and 'priv' keywords in the snmp-server group command.

Full explanation →

2062

MCQeasy

What is the default severity level for syslog messages sent to the console on a Cisco IOS device?

A.Debugging (level 7)

B.Informational (level 6)

C.Warnings (level 4)

D.Notifications (level 5)

AnswerA

The default console logging level is debugging, which includes all severities.

Why this answer

By default, the console logging level is 'debugging' (severity 7), meaning all messages from 0 to 7 are displayed on the console. This is a common fact for ENARSI.

Full explanation →

2063

Drag & Dropmedium

Drag and drop the steps to verify and validate DHCP (IPv4 and IPv6) 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

Start by checking the DHCP pool utilization and bindings. Then, verify that clients have received addresses from the correct pool. Next, confirm that the DHCP relay agent is forwarding packets.

After that, validate DHCPv6 prefix delegation if used. Finally, ensure that the DHCP server is not running out of addresses.

Full explanation →

2064

MCQmedium

Which OSPF LSA type is flooded only within the originating area and is used for loop prevention by describing the topology of the area?

A.Type 1 LSA (Router LSA)

B.Type 2 LSA (Network LSA)

C.Type 3 LSA (Summary LSA)

D.Type 4 LSA (ASBR Summary LSA)

AnswerA

Correct. Router LSAs are area-scoped and describe the router's interfaces and neighbors.

Why this answer

Type 1 Router LSAs describe the router's links and are flooded only within the area. They provide topology information for loop prevention within the area.

Full explanation →

2065

MCQhard

An MPLS network with EIGRP as the IGP is experiencing label distribution failures. Router R1 shows: 'show mpls ldp neighbor' does not list R2. R1's configuration: mpls ip on interfaces, but no router-id configured. R2's configuration: mpls ldp router-id Loopback0 force. R1 and R2 are directly connected. What is the root cause?

A.R1's LDP router-id is not configured, so it uses the IP of the interface facing R2, which may not be reachable from R2's loopback.

B.R2 has a loopback interface that is not advertised via EIGRP, so R1 cannot reach it.

C.R1 has an ACL that blocks LDP UDP packets (port 646).

D.R2's 'force' keyword causes it to use the loopback even if it is not reachable.

AnswerA

LDP requires a reachable router-id. Without explicit configuration, R1 uses the interface IP, which may not be in R2's routing table.

Why this answer

R1 has no explicit LDP router-id configured, so it defaults to the highest IP address on a loopback interface or, if none exists, the highest IP on a physical interface. Since R1 has no loopback, it uses the IP of the interface facing R2. R2's LDP router-id is forced to its Loopback0 address via the 'force' keyword.

For LDP sessions to establish, each router must be able to reach the other's LDP router-id. R2's loopback may not be reachable from R1's interface IP, or R1's interface IP may not be reachable from R2's loopback, breaking the TCP transport required for LDP.

Exam trap

Cisco often tests the nuance that LDP router-id reachability is required for session establishment, and candidates mistakenly focus on the 'force' keyword or ACLs instead of the fundamental TCP reachability requirement.

How to eliminate wrong answers

Option B is wrong because the question does not indicate that R2's loopback is not advertised via EIGRP; the issue is about LDP router-id reachability, not route advertisement. Option C is wrong because there is no mention of an ACL on R1, and the symptom 'show mpls ldp neighbor' not listing R2 points to a failure in LDP session establishment, which is more likely due to router-id reachability than a blocked UDP port (LDP uses UDP for discovery but TCP for session establishment). Option D is wrong because the 'force' keyword on R2 causes it to use the loopback address as its LDP router-id regardless of reachability, but the problem is that R1 cannot reach that loopback address, not that R2's configuration is incorrect.

Full explanation →

2066

MCQeasy

What is the default route distinguisher (RD) format when using the 'ip vrf' command without specifying an RD?

A.The RD defaults to 0:0.

B.The RD is automatically derived from the router ID.

C.The VRF will not be created until an RD is configured.

D.The RD defaults to the ASN:1 format.

AnswerC

This is correct. The RD is required to create a VRF.

Why this answer

The RD is mandatory when creating a VRF. If not specified, the VRF will not be created. There is no default RD.

Full explanation →

2067

MCQmedium

A network engineer runs the following command to troubleshoot a Control Plane Policing (CoPP) issue: R1# show bgp neighbors 10.1.1.2 received-routes BGP table version is 10, local router ID is 10.1.1.1 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S stale, m multipath, b backup-path, f RT-Filter, x best-external, a additional-path, c RIB-compressed, Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *> 10.3.3.0/24 10.1.1.2 0 100 0 i Total number of prefixes 1 What does this output indicate?

A.BGP is not receiving any routes due to CoPP dropping updates.

B.BGP is receiving routes correctly, and CoPP is not interfering with inbound updates.

C.BGP is receiving routes but not installing them in the routing table due to CoPP.

D.BGP session is flapping due to CoPP.

AnswerB

The route is received from neighbor 10.1.1.2 with valid attributes.

Why this answer

The output shows a single BGP prefix (10.3.3.0/24) received from neighbor 10.1.1.2, with the route marked as valid (*) and best (>). This confirms that BGP is successfully receiving and processing the update, and the route is eligible for installation in the routing table. Since the route appears in the received-routes output, CoPP is not dropping the inbound BGP update packets, as CoPP would prevent the packets from reaching the BGP process entirely.

Exam trap

Cisco often tests the distinction between CoPP dropping packets before they reach the BGP process (which would show no received routes) versus BGP receiving routes but not installing them due to other reasons like RIB-failure or policy, leading candidates to incorrectly assume CoPP affects route installation.

How to eliminate wrong answers

Option A is wrong because the output clearly shows one route received, so BGP is receiving updates; CoPP dropping updates would result in zero received routes. Option C is wrong because the route is marked as valid and best, meaning BGP has installed it in the BGP table and will attempt to install it in the routing table; CoPP does not affect route installation after the update is processed. Option D is wrong because the BGP session is stable (the neighbor is reachable and updates are received); a flapping session would show no routes or intermittent connectivity, not a single stable prefix.

Full explanation →

2068

MCQhard

A DMVPN network with hub R1 and spokes R2 and R3 is configured with mGRE and NHRP. Spoke-to-spoke tunnels fail to form. R1 configuration: interface Tunnel0, ip address 10.0.0.1 255.255.255.0, tunnel source GigabitEthernet0/0, tunnel mode gre multipoint, ip nhrp network-id 1, ip nhrp map multicast dynamic. R2 shows: 'show dmvpn' shows no dynamic sessions. R3 shows: 'show ip nhrp' shows no entries for R2. What is the root cause?

A.The spokes are missing the 'ip nhrp nhs' command to point to the hub, preventing registration and resolution of spoke-to-spoke addresses.

B.The tunnel mode is mGRE, but the spokes are configured with point-to-point GRE tunnels.

C.The NHRP network-id is different on R2 and R3, preventing communication.

D.The tunnel source interface is not reachable between spokes.

AnswerA

Without NHS configuration, spokes do not register with the hub, so NHRP cannot provide the mapping for spoke-to-spoke tunnels.

Why this answer

The correct answer is A because in a DMVPN network, spokes must use the 'ip nhrp nhs' command to register their real (physical) IP addresses with the hub (NHS). Without this command, the hub never learns the spokes' addresses, so it cannot provide NHRP resolution replies to other spokes attempting to form spoke-to-spoke tunnels. The absence of dynamic sessions on R2 and no NHRP entries for R2 on R3 directly indicate that R2 never registered with the hub.

Exam trap

Cisco often tests the misconception that 'ip nhrp map multicast dynamic' alone is sufficient for spoke registration, but in reality, the 'ip nhrp nhs' command is mandatory for spokes to register their addresses with the hub.

How to eliminate wrong answers

Option B is wrong because the question states the network is configured with mGRE, and while spoke-to-spoke tunnels fail, there is no evidence that spokes use point-to-point GRE; even if they did, that would not prevent NHRP registration with the hub. Option C is wrong because if the NHRP network-id were different on R2 and R3, they would not be able to communicate with the hub either, but the hub (R1) is configured with network-id 1, and the spokes would need matching IDs to register; the issue is specifically the missing 'ip nhrp nhs' command, not a mismatch. Option D is wrong because the tunnel source interface reachability between spokes is irrelevant for initial registration; spokes first register with the hub, and the hub facilitates spoke-to-spoke resolution; if the hub is reachable, registration should occur, but it does not due to the missing NHS configuration.

Full explanation →

2069

MCQeasy

A network engineer runs the following command to troubleshoot an IPv4 Access Control Lists issue: R1# show ip interface GigabitEthernet0/0 | include access list Outgoing access list is 102 Inbound access list is not set Then the engineer checks: R1# show ip access-lists 102 Extended IP access list 102 10 deny tcp any any eq 23 20 permit ip any any What does this output indicate?

A.ACL 102 is applied outbound on GigabitEthernet0/0, denying Telnet traffic and permitting all other traffic.

B.ACL 102 is applied inbound on GigabitEthernet0/0, blocking Telnet.

C.ACL 102 is not applied to any interface.

D.ACL 102 is applied inbound and outbound on GigabitEthernet0/0.

AnswerA

The output shows the ACL is outbound and its entries.

Why this answer

The output of 'show ip interface GigabitEthernet0/0 | include access list' shows 'Outgoing access list is 102', which means ACL 102 is applied in the outbound direction on that interface. The ACL itself contains a deny statement for TCP traffic destined to port 23 (Telnet) followed by a permit ip any any, so it denies Telnet traffic while permitting all other IP traffic. Option A correctly summarizes this behavior.

Exam trap

Cisco often tests the distinction between the ACL being 'applied' to an interface versus the ACL's content, and the trap here is that candidates see the ACL content and assume it is applied inbound without checking the interface output for direction.

How to eliminate wrong answers

Option B is wrong because the interface output explicitly states 'Inbound access list is not set', so ACL 102 is not applied inbound. Option C is wrong because the interface output confirms ACL 102 is applied outbound on GigabitEthernet0/0. Option D is wrong because the interface output shows only an outbound ACL; the inbound access list is not set, so it is not applied in both directions.

Full explanation →

2070

MCQhard

An engineer is troubleshooting a DMVPN phase 3 network where spoke-to-spoke tunnels are established, but traffic between spokes is taking a suboptimal path through the hub. The engineer checks 'show ip nhrp shortcut' on the spoke and sees no shortcut entries. The hub has 'ip nhrp redirect' enabled, and the spoke has 'ip nhrp shortcut' enabled. The engineer also verifies that the spoke's routing table has a route to the remote spoke's LAN via the hub. What is the most likely cause?

A.The hub router does not have a route to the remote spoke's LAN subnet.

B.The spoke's 'ip nhrp shortcut' command is missing on the tunnel interface.

C.The spoke's routing table has a static route to the remote spoke's LAN via the hub.

D.The hub's tunnel interface has 'no ip nhrp redirect' configured.

AnswerA

Correct because the hub must have a route to the destination subnet to send an NHRP redirect.

Why this answer

In DMVPN phase 3, for spoke-to-spoke shortcuts to be installed, the spoke must receive an NHRP redirect from the hub. If the hub does not send a redirect, the spoke will not create a shortcut. The hub sends a redirect only if it has a route to the destination subnet.

If the hub does not have a route to the remote spoke's LAN, it will not send a redirect.

Full explanation →

2071

MCQmedium

An engineer is troubleshooting an IPv6 deployment where hosts on a subnet are not receiving IPv6 addresses via SLAAC. The router is configured with 'ipv6 unicast-routing' and the interface has 'ipv6 address 2001:db8:1::1/64' and 'ipv6 nd other-config-flag'. The hosts are sending Router Solicitations but receive no Router Advertisements. What is the root cause?

A.The interface is missing the 'ipv6 enable' command.

B.The 'ipv6 nd ra suppress' command is configured on the interface.

C.The 'ipv6 nd prefix' command is missing for the subnet.

D.The hosts are using DHCPv6 instead of SLAAC.

AnswerB

Correct because this command suppresses Router Advertisements, preventing hosts from receiving RAs even though the interface has an IPv6 address.

Why this answer

For SLAAC to work, the router must send Router Advertisements (RAs). The 'ipv6 nd other-config-flag' only sets the 'O' flag for additional information (like DNS), but does not enable RA generation. The interface must have an 'ipv6 enable' command or a configured unicast address to automatically enable RA generation, but here the address is configured, so RA generation should be on by default.

However, the 'ipv6 nd prefix' command may be missing or the interface may be administratively down. The most common cause is that the interface is not 'no shutdown' or the RA interval is set to 0. Given the symptom, the likely cause is that the interface is in a state where RAs are suppressed, such as when 'ipv6 nd ra suppress' is configured.

Full explanation →

2072

MCQmedium

A network engineer runs the following command to troubleshoot an IP SLA issue: R1# debug ip sla trace IP SLAs trace debugging is on *Mar 1 12:34:56.789: IP SLAs: Starting operation 10 *Mar 1 12:34:56.789: IP SLAs: Sending ICMP echo request to 192.168.1.1 *Mar 1 12:34:56.790: IP SLAs: Received ICMP echo reply from 192.168.1.1 *Mar 1 12:34:56.790: IP SLAs: RTT = 12 ms *Mar 1 12:34:56.790: IP SLAs: Operation 10 completed successfully *Mar 1 12:35:56.789: IP SLAs: Starting operation 10 *Mar 1 12:35:56.789: IP SLAs: Sending ICMP echo request to 192.168.1.1 *Mar 1 12:35:56.790: IP SLAs: Received ICMP echo reply from 192.168.1.1 *Mar 1 12:35:56.790: IP SLAs: RTT = 14 ms *Mar 1 12:35:56.790: IP SLAs: Operation 10 completed successfully What does this output indicate?

A.The IP SLA operation is failing because the RTT values are too high.

B.The IP SLA operation is successfully completing each probe cycle.

C.The IP SLA operation is not configured because no configuration is shown.

D.The IP SLA operation is timing out because no reply is received.

AnswerB

Each cycle shows 'completed successfully'.

Why this answer

This debug output shows the IP SLA trace for operation 10 (newer command). It confirms successful ICMP echo probes with RTT values, indicating the operation is functioning correctly.

Full explanation →

2073

MCQmedium

A network engineer runs the following command to troubleshoot an IPsec Site-to-Site VPN issue: R1# debug crypto ipsec *Mar 1 00:02:34.567: IPSEC(sa_request): , (key eng. msg.) src=10.0.0.1, dst=10.0.0.2, src_proxy=192.168.1.0/255.255.255.0/0/0, dst_proxy=192.168.2.0/255.255.255.0/0/0, *Mar 1 00:02:34.567: IPSEC(validate_proposal): transform proposal (esp-3des esp-sha-hmac) not supported for proxy 192.168.1.0/255.255.255.0/0/0 *Mar 1 00:02:34.567: IPSEC(validate_proposal): proposal doesn't match! *Mar 1 00:02:34.568: IPSEC(create_sa): SA created with (0x1234, 0x5678) but no inbound or outbound SPI What does this output indicate?

A.The IPsec SA is established successfully with ESP 3DES and SHA.

B.The transform set on the remote peer does not match the local transform set, causing IPsec SA negotiation to fail.

C.The ACL for the crypto map is misconfigured, causing the traffic to not match.

D.The IKE phase 1 SA is not established before IPsec negotiation.

AnswerB

The debug explicitly states the proposal is not supported, meaning a mismatch in transform set.

Why this answer

The debug output shows that the IPsec SA request is generated, but the transform proposal (esp-3des esp-sha-hmac) is rejected with 'not supported for proxy'. This indicates that the remote peer does not support or is configured with a different transform set, causing the proposal to fail validation. The SA is created with placeholder SPIs (0x1234, 0x5678) but no actual inbound/outbound SPI, confirming negotiation failure due to transform set mismatch.

Exam trap

Cisco often tests the distinction between IKE phase 1 and phase 2 failures; the trap here is that candidates might assume the SA creation message with SPIs indicates success, but the 'no inbound or outbound SPI' line reveals the SA is incomplete, pointing to a transform set mismatch rather than ACL or IKE phase 1 issues.

How to eliminate wrong answers

Option A is wrong because the debug clearly shows 'proposal doesn't match' and 'no inbound or outbound SPI', meaning the SA is not established successfully. Option C is wrong because the debug output shows the correct proxy identities (src=192.168.1.0/24, dst=192.168.2.0/24), indicating the ACL is matching traffic; the failure is at the transform proposal validation stage, not ACL misconfiguration. Option D is wrong because the debug output shows an IPsec SA request is being processed, which implies IKE phase 1 (ISAKMP SA) has already been established; if IKE phase 1 were not up, the debug would not reach the IPsec SA negotiation stage.

Full explanation →

2074

MCQhard

A router is configured with 'logging host 10.1.1.100' and 'logging trap debugging'. The engineer notices that the router is sending a large number of debug messages to the syslog server, causing high CPU usage. The engineer wants to stop sending debug messages to the remote server but keep them in the local buffer. What is the best command to achieve this?

A.Configure 'no logging trap debugging' globally.

B.Configure 'logging host 10.1.1.100 trap notifications' to set the remote threshold to severity 5.

C.Use 'undebug all' to stop all debug output.

D.Set 'logging buffered 4096 notifications' to limit local buffer to severity 5.

AnswerB

Correct because this command sets the severity level for that specific host only, allowing local logging to remain at debugging.

Why this answer

To stop sending debug messages to the remote server without affecting local logging, the engineer should change the remote logging severity to a higher level (e.g., 'logging host 10.1.1.100 trap notifications' to set severity 5). This will exclude debug (severity 7) messages from being sent to that specific host. The local buffer can remain at debugging level.

Full explanation →

2075

Drag & Drophard

Drag and drop the steps to troubleshoot Policy-Based Routing (PBR) adjacency or connectivity failures 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

Start by checking if PBR is applied on the correct interface. Then verify the route map sequence and match statements. Check the set next-hop reachability via routing table.

Use 'debug ip policy' to see packet matches. Finally, test with extended ping or traceroute to confirm path.

Full explanation →

2076

MCQhard

In a VRF-Lite setup, Router R1 and R2 are running OSPF in VRF-A. R1 has interface Gig0/0 in VRF-A with ip ospf network point-to-point. R2 has interface Gig0/1 in VRF-A with default network type (broadcast). The link between them is a direct Ethernet connection. OSPF neighbors are not forming. What is the root cause?

A.The OSPF network types are mismatched: one side is point-to-point, the other is broadcast, causing neighbor adjacency failure.

B.The VRF names must match for OSPF to form neighbors.

C.The OSPF process ID must be the same on both routers.

D.The interface must be configured with the same IP subnet mask.

AnswerA

Correct: OSPF requires matching network types on the same link; mismatch leads to no neighbor formation.

Why this answer

OSPF network type mismatch prevents neighbor formation. On a broadcast network, OSPF expects DR/BDR elections, while point-to-point expects no election. The mismatch causes hello packets to be ignored because the OSPF interface parameters (like hello interval, dead interval, and network type) differ.

Specifically, on a point-to-point link, the neighbor state machine expects a different packet format and does not process broadcast hellos.

Full explanation →

2077

Multi-Selecthard

An engineer wants to use EEM to automatically back up the running configuration to a TFTP server whenever a 'write memory' command is executed. Which TWO configuration steps are required? (Choose TWO.)

Select 2 answers

A.Configure 'event cli pattern "write memory" sync no' under the applet.

B.Use 'action cli command "copy running-config tftp://10.1.1.1/backup-config"' to perform the backup.

C.Define the applet using the 'event manager policy' command instead of 'event manager applet'.

D.Add an 'event syslog pattern "WRITE"' to detect the write memory operation.

E.Include an 'action cli command "enable"' before the copy command to ensure privileged access.

AnswersA, B

Correct. This event triggers on the 'write memory' command without synchronizing, allowing the backup to proceed asynchronously.

Why this answer

The 'event cli' with 'sync no' is needed to avoid blocking the CLI. The 'action cli command' must use the 'copy running-config tftp:' command. The 'event manager applet' is correct, not 'event manager policy'.

The 'event syslog' with pattern 'WRITE' is not precise enough. The 'action cli command' should not use 'enable' as a separate action because the applet runs in the same privilege level as the triggering user.

Full explanation →

2078

MCQmedium

What is the default timeout value (in milliseconds) for an IP SLA operation?

A.1000 ms

B.5000 ms

C.10000 ms

D.60000 ms

AnswerB

Correct. The default timeout is 5000 ms (5 seconds).

Why this answer

The default timeout for an IP SLA operation is 5000 milliseconds (5 seconds). If a response is not received within this time, the probe is considered failed.

Full explanation →

2079

MCQeasy

Which of the following EEM event types can be used to trigger an applet based on a specific IOS command being entered?

A.event syslog

B.event snmp

C.event cli

D.event timer

AnswerC

Correct. 'event cli' is used to trigger on CLI commands.

Why this answer

EEM provides the 'event cli' event type to match on CLI commands. The syntax is 'event cli pattern <string>' where the pattern can be a regular expression to match the command. Other event types like 'event syslog' match syslog messages, not CLI commands.

Full explanation →

2080

MCQhard

DMVPN spoke-to-spoke tunnel is not forming between two spokes. Hub router R1 has the following relevant configuration: interface Tunnel0 ip address 10.0.0.1 255.255.255.0 ip nhrp network-id 1 ip nhrp map multicast dynamic ip ospf 1 area 0 tunnel source GigabitEthernet0/0 tunnel mode gre multipoint Spoke R2 shows: show dmvpn Legend: Attrb -> S: Static, D: Dynamic, I: Incomplete Interface: Tunnel0, IPv4 NHRP Details Type:Spoke, NHRP Peers: 1 # Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb 1 192.168.1.1 10.0.0.1 UP 00:10:00 D Spoke R3 shows similar, but no spoke-to-spoke tunnel. What is the root cause?

A.Missing ip nhrp redirect on hub and ip nhrp shortcut on spokes.

B.OSPF network type is broadcast; change to point-to-multipoint.

C.IPsec is not configured; DMVPN requires encryption.

D.The tunnel key is mismatched; configure tunnel key on all routers.

AnswerA

NHRP redirect triggers shortcut creation; without it, spokes always use hub.

Why this answer

Spoke-to-spoke tunnel requires NHRP redirect and shortcut route. Without ip nhrp redirect on hub and ip nhrp shortcut on spokes, traffic between spokes goes through hub. OSPF over DMVPN may also need mtu or ipsec issues.

The correct fix is to enable NHRP redirect on hub and shortcut on spokes.

Full explanation →

2081

MCQmedium

A network engineer is troubleshooting an OSPFv2 adjacency issue between two routers connected via a VLAN trunk. R1 and R2 are in different VLANs but are connected through a Layer 2 switch. The engineer has configured 'ip ospf 1 area 0' on the subinterfaces. The adjacency forms but is stuck in INIT state. What is the most likely cause?

A.The routers have the same OSPF router ID.

B.The OSPF hello interval is mismatched between the two routers.

C.The subinterfaces are in different VLANs, preventing Layer 2 communication.

D.The OSPF network type is set to point-to-point on one side and broadcast on the other.

AnswerA

When a router receives a hello packet with its own router ID, it ignores it, causing the adjacency to stay in INIT.

Why this answer

The INIT state indicates that the router has received a hello packet from the neighbor but the neighbor has not seen its own router ID in the hello packet. This is often due to a mismatch in the OSPF network type or a unicast communication issue. In a VLAN trunk scenario, if the subinterfaces are not in the same VLAN, the routers may not be able to communicate at Layer 2.

However, the most common cause is that the routers are using the same router ID, which causes the hello packet to be ignored because the router sees its own router ID in the neighbor list.

Full explanation →

2082

Multi-Selecthard

Which TWO statements about the 'time-range' feature in IPv4 ACLs are correct? (Choose TWO.)

Select 2 answers

A.A time-range can include both absolute and periodic statements simultaneously.

B.The time-range is applied to the entire ACL, not individual ACEs.

C.If the router's clock is not set, the time-range will be considered active at all times.

D.The time-range feature can only be used with extended named ACLs, not standard ACLs.

E.The time-range must be configured before it is referenced in an ACE.

AnswersA, E

Correct. A time-range can have one absolute statement and multiple periodic statements; the ACE is active if any of the conditions are met.

Why this answer

Option A is correct because the 'time-range' feature in Cisco IOS allows both absolute (specific start/end dates) and periodic (recurring days/times) statements to be combined within a single time-range definition. This enables flexible scheduling, such as allowing traffic only during business hours on weekdays while also specifying an absolute end date for the policy.

Exam trap

Cisco often tests the misconception that a time-range applies to the entire ACL rather than individual ACEs, leading candidates to incorrectly select option B.

Full explanation →

2083

MCQhard

What is the maximum hop count for an EIGRP route?

A.15

B.255

C.224

D.Unlimited

AnswerC

Correct. EIGRP limits hop count to 224 by default.

Why this answer

EIGRP uses a maximum hop count of 224, not 255 like RIPv2 or other distance-vector protocols. This limit is hard-coded in the EIGRP protocol to prevent routing loops and excessive path lengths, and it is enforced by the EIGRP update process. Routes with a hop count exceeding 224 are considered unreachable and are not installed in the routing table.

Exam trap

Cisco often tests the specific EIGRP hop count of 224 to trap candidates who confuse it with the more common RIP hop count of 15 or the RIPv2/EIGRP default of 255, or who assume EIGRP has no hop count limit due to its advanced metric system.

How to eliminate wrong answers

Option A is wrong because 15 is the maximum hop count for RIP (Routing Information Protocol), not EIGRP. Option B is wrong because 255 is the maximum hop count for RIPv2 and some other distance-vector protocols, but EIGRP specifically uses 224. Option D is wrong because EIGRP does have a finite hop count limit (224), so routes are not unlimited; this misconception might arise from EIGRP's use of composite metrics rather than hop count as the primary metric.

Full explanation →

2084

MCQmedium

Consider the following partial configuration on a Cisco IOS-XE router: interface GigabitEthernet0/0 ip address 192.168.1.1 255.255.255.0 ip nat inside ! interface GigabitEthernet0/1 ip address 203.0.113.1 255.255.255.0 ip nat outside ! ip nat inside source list 1 interface GigabitEthernet0/1 overload access-list 1 permit 192.168.1.0 0.0.0.255 What is the effect of this configuration?

A.All traffic from 192.168.1.0/24 is translated to 203.0.113.1 using PAT.

B.Only traffic from 192.168.1.1 is translated to 203.0.113.1 using PAT.

C.Traffic is translated using static NAT to 203.0.113.1.

D.The configuration is incomplete; a NAT pool is required for dynamic translation.

AnswerA

The 'overload' keyword enables PAT, and the ACL matches the inside network.

Why this answer

The configuration uses an ACL (access-list 1) to match traffic from the 192.168.1.0/24 subnet, and the 'ip nat inside source list 1 interface GigabitEthernet0/1 overload' command translates all matching source IP addresses to the single IP address 203.0.113.1 (the outside interface IP) using Port Address Translation (PAT). This is a classic dynamic NAT overload configuration, where multiple internal hosts share one public IP by multiplexing on source ports.

Exam trap

Cisco often tests the distinction between 'ip nat inside source list <acl> interface <interface> overload' (dynamic PAT using the interface IP) and configurations that require a NAT pool or static mapping, leading candidates to mistakenly think a pool is mandatory for any dynamic translation.

How to eliminate wrong answers

Option B is wrong because the ACL permits the entire 192.168.1.0/24 subnet, not just the router's own interface IP 192.168.1.1; all hosts in that subnet are eligible for translation. Option C is wrong because static NAT requires the 'ip nat inside source static' command, not the 'overload' keyword, and the configuration here uses dynamic translation with PAT. Option D is wrong because when using 'interface' with 'overload', no NAT pool is required; the outside interface IP itself serves as the single translated address, and PAT handles port multiplexing.

Full explanation →

2085

MCQhard

A network engineer notices that routes redistributed from EIGRP into OSPF are causing routing loops. Router R1 has the following relevant configuration: router eigrp 100 redistribute ospf 1 metric 10000 100 255 1 1500 router ospf 1 redistribute eigrp 100 subnets metric-type 1 Router R2 shows: show ip route 192.168.1.0 Routing entry for 192.168.1.0/24 Known via "ospf 1", distance 110, metric 20, type E1 Last update from 10.1.1.1, 00:01:30 ago Also, R2 has a default route via R1. What is the root cause?

A.Mutual redistribution without filtering causes a routing loop; apply distribute-list or route-map with tags.

B.The metric-type 1 should be type 2 to avoid loops.

C.The EIGRP metric values are incorrect; they should match OSPF cost.

D.The subnets keyword is missing in the redistribute command for OSPF.

AnswerA

Without filtering, routes are redistributed back and forth, creating loops. Tags and filters break the cycle.

Why this answer

The mutual redistribution between EIGRP and OSPF without route filtering can cause a routing loop. R1 redistributes OSPF into EIGRP, and EIGRP back into OSPF, creating a feedback loop. The E1 metric of 20 suggests the route was redistributed twice.

The correct fix is to implement route tagging and filtering to prevent loop.

Full explanation →

2086

MCQmedium

What is the default EIGRP composite metric formula used for route calculation?

A.metric = bandwidth + delay + load + reliability

B.metric = (K1 * bandwidth) + (K3 * delay)

C.metric = bandwidth + delay + MTU

D.metric = (K1 * bandwidth) + (K2 * load) + (K3 * delay) + (K5 / (K4 + reliability))

AnswerB

Correct: With default K values (K1=1, K3=1, others=0), the formula simplifies to bandwidth + delay.

Why this answer

The default EIGRP composite metric uses only K1 and K3, which correspond to bandwidth and delay, with K1=1 and K3=1 by default. This yields the formula metric = bandwidth + delay, where bandwidth is calculated as (10^7 / minimum path bandwidth in kbps) * 256 and delay is the sum of interface delays in tens of microseconds multiplied by 256. Option B correctly represents this default behavior.

Exam trap

Cisco often tests the misconception that the full five-term formula (Option D) is the default, but the trap is that K2, K4, and K5 default to zero, so only K1 and K3 are used, making Option B the correct default formula.

How to eliminate wrong answers

Option A is wrong because it omits the K-value scaling and treats load and reliability as additive components, but EIGRP does not include load or reliability in the default metric calculation. Option C is wrong because MTU is not part of the EIGRP composite metric; it is only used for path MTU discovery and does not influence route selection. Option D is wrong because it includes K2 (load), K4, and K5 (reliability) terms, which are set to zero by default, making the formula non-functional for default operation; the full formula is only used when non-default K-values are configured.

Full explanation →

2087

MCQhard

What is the default keepalive interval for a GRE tunnel interface on Cisco IOS-XE?

A.5 seconds

B.10 seconds

C.15 seconds

D.20 seconds

AnswerB

The default keepalive interval is 10 seconds.

Why this answer

The default keepalive interval for a GRE tunnel interface on Cisco IOS-XE is 10 seconds. This is defined by the default behavior of the `keepalive` command on tunnel interfaces, which sends periodic keepalive packets to verify the reachability of the tunnel destination. If no keepalive reply is received within three consecutive intervals (30 seconds by default), the tunnel interface is marked as down.

Exam trap

Cisco often tests the default keepalive interval for GRE tunnels, and the trap here is that candidates confuse it with the default keepalive interval for other interface types (e.g., serial interfaces default to 10 seconds as well, but some assume 5 or 15 seconds based on unrelated protocols like EIGRP hello timers).

How to eliminate wrong answers

Option A is wrong because 5 seconds is not the default; it is a common misconfiguration or a value used for faster failure detection but not the Cisco IOS-XE default. Option C is wrong because 15 seconds is not the default; it might be confused with the default keepalive interval for other interface types like serial interfaces (which default to 10 seconds as well, but not 15). Option D is wrong because 20 seconds is not the default; it could be mistaken for the default dead interval (three keepalive intervals) which is 30 seconds, not 20.

Full explanation →

2088

MCQeasy

Which IPv6 FHS feature uses a 'device tracking' database to maintain reachability information for hosts?

A.RA Guard

B.DHCPv6 Guard

C.Device Tracking

D.PACL

AnswerC

Correct. Device Tracking maintains a database of IPv6 addresses and their reachability.

Why this answer

Device Tracking is the correct answer because it is the IPv6 First Hop Security (FHS) feature that maintains a 'device tracking' database to monitor and store reachability information for hosts. This database tracks the IPv6 address, MAC address, and binding state of each host, enabling features like ND Inspection and DHCPv6 Guard to verify host reachability before forwarding traffic.

Exam trap

Cisco often tests the distinction between features that maintain the database (Device Tracking) versus features that use the database (e.g., DHCPv6 Guard, RA Guard), so the trap here is assuming that any FHS feature that interacts with host information must be the one that maintains the tracking database.

How to eliminate wrong answers

Option A is wrong because RA Guard is an IPv6 FHS feature that filters Router Advertisement messages to prevent rogue router attacks, but it does not maintain a device tracking database for host reachability. Option B is wrong because DHCPv6 Guard is an IPv6 FHS feature that filters DHCPv6 messages to block unauthorized DHCP servers, but it relies on the device tracking database rather than maintaining it. Option D is wrong because PACL (Port Access Control List) is a security feature used to filter traffic based on Layer 2 or Layer 3 criteria, but it is not an IPv6 FHS feature and does not maintain a device tracking database.

Full explanation →

2089

MCQeasy

Which DHCP message type is used by a client to renew its lease before it expires?

A.DHCPREQUEST

B.DHCPDISCOVER

C.DHCPACK

D.DHCPRELEASE

AnswerA

The client uses DHCPREQUEST to renew its lease, sent unicast to the DHCP server.

Why this answer

When a DHCP client wants to renew its existing lease before it expires, it sends a unicast DHCPREQUEST message directly to the DHCP server that originally granted the lease. This is part of the renewal process defined in RFC 2131, where the client transitions from the BOUND state to the RENEWING state and uses the server's IP address to request an extension of the lease time.

Exam trap

Cisco often tests the distinction between the unicast DHCPREQUEST used for lease renewal and the broadcast DHCPREQUEST used during the initial DORA process, leading candidates to mistakenly think DHCPDISCOVER is involved in renewal.

How to eliminate wrong answers

Option B (DHCPDISCOVER) is wrong because it is used by a client to locate available DHCP servers when it has no current lease or is starting from the INIT state, not for renewing an existing lease. Option C (DHCPACK) is wrong because it is a server-to-client response that acknowledges and grants the lease or renewal, not a message sent by the client. Option D (DHCPRELEASE) is wrong because it is used by a client to voluntarily relinquish its IP address lease to the server, not to renew it.

Full explanation →

2090

MCQmedium

A network engineer runs the following command on Router R1: R1# show ip access-lists Extended IP access list 120 10 permit tcp 10.0.0.0 0.255.255.255 any eq www (1000 matches) 20 permit udp any any eq dns (500 matches) 30 deny ip any any (200 matches) Based on this output, what is the problem?

A.The ACL is correctly permitting web and DNS traffic.

B.The ACL is blocking all traffic except web and DNS, which may be too restrictive.

C.The ACL has no effect because it is not applied.

D.The ACL allows all traffic because of the permit statements.

AnswerB

The deny ip any any with matches shows that other traffic is being denied, which could be a problem.

Why this answer

Option B is correct because the ACL explicitly permits only TCP port 80 (www) and UDP port 53 (dns) traffic, while the final deny ip any any statement blocks all other traffic. With only 1000 matches for web and 500 for DNS, the ACL is likely too restrictive for a production network, as it would drop essential traffic such as routing protocols, management traffic (e.g., SSH, SNMP), or other application flows. The output shows the ACL is present and has hit counts, but its restrictive nature is the problem.

Exam trap

Cisco often tests the misconception that an ACL with permit statements is automatically 'correct' or 'permissive,' when in fact the explicit deny at the end makes it highly restrictive, and candidates may overlook the need to evaluate whether the ACL matches the intended security policy.

How to eliminate wrong answers

Option A is wrong because the ACL does not 'correctly permit' all necessary traffic; it only permits web and DNS, while blocking everything else, which is typically too restrictive for a functioning network. Option C is wrong because the ACL is defined and has match counts (1000, 500, 200), indicating it is applied to an interface; an unapplied ACL would show zero matches. Option D is wrong because the permit statements do not allow all traffic; the explicit deny ip any any at line 30 blocks all traffic not matching the earlier permit entries.

Full explanation →

2091

MCQhard

An engineer configures RSPAN VLAN 100 on two switches to monitor traffic across the network. The remote switch shows the RSPAN source as active, but the destination switch receives no mirrored traffic. What is the most likely cause?

A.The RSPAN VLAN is not allowed on a trunk link between the source and destination switches.

B.The RSPAN VLAN is configured as a native VLAN on the trunk, causing VLAN tagging issues.

C.The destination switch has a different RSPAN VLAN ID configured for the session.

D.The source switch has not enabled RSPAN globally with the 'monitor session' command.

AnswerA

RSPAN traffic traverses the network in the RSPAN VLAN; if that VLAN is not permitted on an intermediate trunk, the traffic is dropped.

Why this answer

RSPAN requires that the RSPAN VLAN be created and allowed on all intermediate switches (trunks) between source and destination. If the RSPAN VLAN is pruned or not allowed on a trunk, the mirrored traffic never reaches the destination. Additionally, the RSPAN VLAN must not be used for user data.

Full explanation →

2092

MCQhard

A large enterprise network is experiencing intermittent SNMP polling failures from the NMS to router R2. R1 and R2 are connected via a serial link running OSPF. R1 has the following relevant configuration: snmp-server community public RO, snmp-server community private RW, snmp-server trap-source Loopback0, snmp-server enable traps ospf. R2 shows: debug ip packet shows packets from NMS (10.1.1.100) to R2's Loopback0 (10.2.2.2) being dropped with 'access-list violation'. No ACL is applied to any interface on R2. What is the root cause?

A.An ACL is applied to the SNMP community string that does not permit the NMS IP address.

B.OSPF network type mismatch between R1 and R2 causes routing blackhole.

C.The NMS is using SNMPv3 with incorrect credentials, causing authentication failure.

D.R2's loopback interface is not advertised into OSPF, making it unreachable.

AnswerA

The snmp-server community command can have an optional ACL. If configured, it filters SNMP access. The debug shows ACL violation, so this is the direct cause.

Why this answer

The debug output on R2 shows packets from the NMS (10.1.1.100) to R2's Loopback0 (10.2.2.2) being dropped with 'access-list violation'. Since no ACL is applied to any interface on R2, the only remaining ACL that could cause this is an SNMP community ACL. The SNMP community string 'public' or 'private' can have an optional ACL applied via the 'snmp-server community <string> [view <view-name>] [ro|rw] [acl-number]' command.

If that ACL does not permit the NMS IP address (10.1.1.100), the router will silently drop SNMP packets from that source, even though no interface ACL exists. This matches the symptom exactly.

Exam trap

Cisco often tests the concept that ACLs can be applied to SNMP community strings (not just interfaces), and candidates mistakenly assume 'no ACL on interfaces' means no ACL is dropping traffic, overlooking the community-string-level ACL as the root cause.

How to eliminate wrong answers

Option B is wrong because an OSPF network type mismatch (e.g., point-to-point vs broadcast) can cause adjacency issues or routing blackholes, but it would not generate an 'access-list violation' debug message; that message is specific to ACL-based drops. Option C is wrong because the NMS is using SNMPv2c (as indicated by the community strings 'public' and 'private' in R1's configuration), not SNMPv3; authentication failures in SNMPv3 would produce different debug messages (e.g., 'authFailure') and would not be described as 'access-list violation'. Option D is wrong because if R2's loopback interface were not advertised into OSPF, the NMS would not be able to reach it at all, resulting in 'destination unreachable' or timeouts, not an 'access-list violation' drop; the debug shows the packet is being received by R2 and then dropped by an ACL, proving reachability is fine.

Full explanation →

2093

Drag & Dropmedium

Drag and drop the steps to verify and validate DMVPN 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

Validating DMVPN starts with checking the tunnel interface status, then verifying NHRP mappings and IPsec security associations. Next, confirm routing protocol adjacencies over the tunnel. Finally, test end-to-end reachability to ensure the DMVPN network is fully operational.

Full explanation →

2094

Multi-Selectmedium

Which TWO commands would a network engineer use to verify the MPLS label forwarding table on a Cisco IOS-XE router? (Choose TWO.)

Select 2 answers

A.show mpls forwarding-table

B.show mpls ldp neighbor

C.show mpls label table

D.show ip route

E.show mpls interfaces

AnswersA, C

This command displays the MPLS forwarding table, including incoming labels, outgoing labels, and next-hop information.

Why this answer

The MPLS label forwarding table is verified using 'show mpls forwarding-table' and 'show mpls label table'. The former displays outgoing labels for prefixes, while the latter shows local label bindings. Other commands either show LDP neighbors or are invalid.

Full explanation →

2095

Multi-Selectmedium

Which TWO statements about IPv6 Neighbor Discovery (ND) Inspection are true? (Choose TWO.)

Select 2 answers

A.It validates Neighbor Solicitation and Neighbor Advertisement messages against the IPv6 snooping binding table.

B.It can be configured to rate-limit ND packets on a per-interface basis.

C.It prevents rogue DHCPv6 servers from assigning malicious addresses.

D.It uses a prefix list to determine which source addresses are allowed.

E.It is enabled globally and cannot be applied on a per-interface basis.

AnswersA, B

ND Inspection checks NS and NA messages against the binding table to prevent spoofing attacks.

Why this answer

Option A is correct because IPv6 ND Inspection validates Neighbor Solicitation (NS) and Neighbor Advertisement (NA) messages against the IPv6 snooping binding table. This table is built by gleaning information from DHCPv6 messages or by using the IPv6 Neighbor Discovery protocol itself, ensuring that only legitimate ND messages from trusted sources are forwarded, preventing attacks like Neighbor Cache exhaustion or address spoofing.

Exam trap

Cisco often tests the distinction between IPv6 First Hop Security features, and the trap here is confusing ND Inspection (which validates ND messages) with DHCPv6 Guard (which blocks rogue DHCPv6 servers) or RA Guard (which uses prefix lists).

Full explanation →

2096

MCQmedium

Examine this OSPF configuration snippet on router R3: router ospf 1 network 10.1.1.0 0.0.0.255 area 0 default-information originate always What is the effect of the default-information originate always command?

A.R3 will advertise a default route into OSPF only if it has a default route in its routing table.

B.R3 will unconditionally advertise a default route into OSPF as an external LSA type 5.

C.R3 will advertise a default route only if it is an ASBR.

D.The command is invalid because default-information originate requires a route-map.

AnswerB

Correct. The 'always' keyword forces advertisement regardless of the presence of a default route.

Why this answer

The command injects a default route (0.0.0.0/0) into the OSPF domain as an external LSA type 5, regardless of whether the router has a default route in its routing table. The 'always' keyword forces advertisement even without a default route.

Full explanation →

2097

MCQhard

An engineer configures CoPP on a router running EIGRP. The policy includes a class-map matching EIGRP traffic with a police rate of 1000 pps. After applying the policy, EIGRP neighbors form but occasionally go active and become stuck-in-active (SIA). Which is the most likely explanation?

A.EIGRP uses multicast, and CoPP cannot police multicast traffic.

B.The police rate in pps is too low, causing EIGRP reliable packets (queries/replies) to be dropped, leading to SIA.

C.CoPP only affects incoming traffic, but EIGRP SIA is caused by outgoing packet drops.

D.EIGRP uses TCP, and CoPP only polices UDP.

AnswerB

EIGRP's reliable transport requires all packets to be acknowledged; drops cause retransmissions and potential SIA.

Why this answer

EIGRP uses RTP (Reliable Transport Protocol) for certain packets like queries and replies. These reliable packets require acknowledgment; if the CoPP police rate of 1000 pps is too low, EIGRP queries or replies may be dropped. Missing acknowledgments cause the neighbor to be declared active, and if the query process is not completed within the active timer, the route becomes stuck-in-active (SIA).

Exam trap

The trap here is that candidates may assume CoPP only affects incoming traffic or that EIGRP uses TCP, but the key is understanding that EIGRP's reliable packets (queries/replies) are sensitive to drops, and a low pps police rate can cause SIA.

How to eliminate wrong answers

Option A is wrong because CoPP can police multicast traffic; EIGRP uses multicast address 224.0.0.10, and CoPP class-maps can match this traffic using access-lists or protocol matching. Option C is wrong because CoPP can police both incoming and outgoing control plane traffic; EIGRP SIA is typically caused by dropped incoming reliable packets (queries/replies) or missing acknowledgments, not solely by outgoing drops. Option D is wrong because EIGRP does not use TCP; it uses its own Reliable Transport Protocol (RTP) over IP protocol 88, and CoPP can police any IP protocol, not just UDP.

Full explanation →

2098

MCQmedium

A network engineer is troubleshooting MPLS traffic where packets are being dropped at a P router. The engineer runs show mpls forwarding-table and sees that the outgoing label for a specific FEC is 'Untagged' instead of a valid label. The IGP is running correctly, and LDP neighbors are established. What is the most likely cause?

A.LDP is not enabled on the outgoing interface.

B.The IGP metric is too high, causing LDP to prefer a different path.

C.The mpls label range is exhausted.

D.The router is configured with mpls ldp advertise-labels for host routes only.

AnswerA

Correct because LDP must be enabled on each interface to assign a label for the FEC; without it, the label remains 'Untagged' and packets are dropped.

Why this answer

The 'Untagged' label in the LFIB indicates that LDP has not assigned a label for that FEC on the outgoing interface. This typically happens when LDP is not enabled on the outgoing interface, either because the interface is not configured with mpls ip or because the interface is passive under LDP.

Full explanation →

2099

MCQhard

A network engineer runs the following command to troubleshoot an MPLS L3VPN issue: R1# show bgp vpnv4 vrf CUSTOMER-A 10.1.1.0/24 Output: BGP routing table entry for 10.1.1.0/24, version 10 Paths: (1 available, best #1, table CUSTOMER-A) Advertised to update-groups: 1 Refresh Epoch 1 Local 0.0.0.0 from 0.0.0.0 (10.0.0.1) Origin incomplete, metric 0, localpref 100, weight 32768, valid, sourced, best Extended Community: RT:100:100 mpls labels in/out nolabel/nolabel What does this output indicate?

A.The route is locally originated and has no MPLS label

B.The route is learned from a BGP peer

C.The route has an MPLS label of 100

D.The route is not best

AnswerA

The route is sourced locally (0.0.0.0 from 0.0.0.0) and the mpls labels are nolabel/nolabel.

Why this answer

This shows a VPNv4 route for prefix 10.1.1.0/24 in VRF CUSTOMER-A. The path is local (sourced from this router), with next hop 0.0.0.0, and the route is valid and best. The extended community is RT:100:100.

The mpls labels show nolabel/nolabel, meaning no MPLS label is assigned for this prefix, which could indicate a problem if labels are expected.

Full explanation →

2100

MCQeasy

Which of the following is NOT a valid match criterion for a class-map used in Control Plane Policing?

A.match access-group

B.match ip dscp

C.match protocol

D.match ip precedence

AnswerC

Correct. match protocol is not supported in CoPP; only ACLs, DSCP, or IP precedence are allowed.

Why this answer

In Control Plane Policing (CoPP), class-maps are used to classify traffic destined to the control plane. The valid match criteria include match access-group, match ip dscp, and match ip precedence. However, match protocol is not a valid match criterion for a class-map under CoPP; it is used in other contexts like QoS policy-maps for application-level classification, but not for CoPP class-maps.

Exam trap

Cisco often tests the distinction between match criteria available in CoPP class-maps versus those in general QoS class-maps, and the trap here is that candidates assume match protocol is universally valid across all class-map types, when it is specifically excluded from CoPP.

How to eliminate wrong answers

Option A is wrong because match access-group is a valid match criterion in CoPP class-maps, allowing classification based on an IPv4 or IPv6 ACL. Option B is wrong because match ip dscp is a valid match criterion, enabling classification based on DSCP values in the IP header. Option D is wrong because match ip precedence is a valid match criterion, allowing classification based on IP precedence bits.

The only invalid option is C, as match protocol is not supported in CoPP class-maps.

Full explanation →

Page 28 of 29

All pages

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29

Cisco CCNP ENARSI 300-410 300-410 Questions 2026–2100 | Page 28/29 | Courseiva