300-410 Hard Questions — 25 Difficult Questions

Question 1

Drag and drop the steps to troubleshoot an IPsec site-to-site VPN adjacency failure into the correct order, from first to last.

Accepted Answer

Ping peer IP to confirm reachability. Start by verifying basic IP connectivity between peers, then check that the crypto isakmp policy and IKE proposals match. Next, confirm tunnel interface configuration and ACLs, then inspect IKE and IPsec SA states. Finally, enable debugs to isolate the specific failure.

Question 2

Drag and drop the steps to troubleshoot IPv6 over IPv4 tunnel adjacency or connectivity failures into the correct order, from first to last.

Accepted Answer

Check tunnel interface status with 'show ipv6 interface brief'. The troubleshooting process follows a logical progression: first verify the tunnel interface is up/up, then check the IPv6 routing table for the destination prefix, inspect the tunnel source and destination IPs for correctness, verify IPv4 reachability to the tunnel destination, and finally examine ACLs or firewall rules that might block GRE protocol 47 traffic.

Question 3

Drag and drop the steps to troubleshoot IPv4 ACL adjacency or connectivity failures into the correct order, from first to last.

Accepted Answer

Verify ACL application on interface and direction. Start by confirming the ACL is applied to the correct interface and direction; then check for implicit deny blocking traffic; verify sequence numbers and order; examine log entries for hits; finally, adjust ACL by inserting a permit statement before the deny.

Question 4

Which THREE symptoms indicate that IPv6 unicast RPF is misconfigured or failing on an interface? (Choose THREE.)

Accepted Answer

Traffic from a valid source IP is being dropped on the interface.. uRPF drops packets if the source address is not reachable via the incoming interface. A syslog message about uRPF drops confirms this. The 'ipv6 verify unicast source reachable-via any' command is a configuration command, not a symptom. High CPU due to RPF checks is not typical; RPF is done in hardware (CEF). An increase in the 'ipv6_input' drop counter for 'RPF' indicates drops.

Answer

The command 'ipv6 verify unicast source reachable-via any' is present in the running config.

Answer

High CPU utilization is observed due to RPF processing.

Question 5

Which THREE statements about IPv6 unicast RPF (uRPF) are true? (Choose THREE.)

Accepted Answer

IPv6 uRPF uses the Forwarding Information Base (FIB) to verify source address reachability.. uRPF uses the FIB (CEF) for lookups, it can operate in strict or loose mode, and it is applied per interface. The other options are false: uRPF does not inspect the destination address (only source), and it is not used for multicast traffic.

Answer

IPv6 uRPF checks the destination address of incoming packets.

Answer

IPv6 uRPF is used to filter multicast traffic.

Question 6

A large enterprise network uses OSPFv3 for IPv6 routing. Router R1 and R2 are connected via a multi-access Ethernet link. R1 is configured with 'ipv6 ospf network point-to-point' while R2 uses the default broadcast network type. R1 has an IPv6 ACL applied inbound on its interface that permits only OSPF (89) and denies all other traffic. R2 is unable to form a full OSPF adjacency with R1. R2 shows 'OSPFv3 adjacency state is EXSTART/EXCHANGE' and logs 'Bad LSReq'. What is the root cause?

Accepted Answer

R1's ACL blocks OSPFv3 multicast hello packets (FF02::5), preventing adjacency formation on the broadcast link.. The network type mismatch between R1 (point-to-point) and R2 (broadcast) causes different DR/BDR election behavior and LSDB synchronization issues. The ACL on R1 blocks the multicast traffic used for OSPFv3 hello packets (FF02::5) on broadcast networks, but point-to-point uses unicast. The 'Bad LSReq' indicates that the LS Request packets are being filtered or malformed due to the mismatch.

Answer

R2's OSPFv3 process is configured with a different router-id, causing a DR election conflict.

Answer

The MTU mismatch between R1 and R2 causes OSPFv3 packet fragmentation, leading to LSReq errors.

Answer

R2 has a passive interface configured, preventing it from sending OSPFv3 hellos.

Question 7

An enterprise uses EIGRP for IPv6 with route summarization. Router R1 has a summary route 2001:db8:1::/48 via Null0 redistributed into EIGRP. Router R2 receives this summary and has a more specific route 2001:db8:1:1::/64 learned via a different interface. R2's IPv6 uRPF is configured in strict mode on the interface facing R1. Traffic from a host behind R2 destined to 2001:db8:1:2::1 is being dropped. R2 shows 'ipv6 cef' indicates the summary route points to R1, but uRPF checks fail. What is the root cause?

Accepted Answer

The summary route 2001:db8:1::/48 on R1 causes R2 to have a less specific route pointing to R1, making uRPF think the source address is not reachable via the incoming interface.. uRPF strict mode checks that the source address of incoming packets is reachable via the same interface. For traffic sourced from R2's subnet (e.g., 2001:db8:1:1::/64), the return route via the summary points to R1, but the source is directly connected. This asymmetry causes uRPF to drop the packet because the source is not reachable via the incoming interface.

Answer

R2's uRPF is configured in loose mode, which requires a matching route in the FIB, but the summary route is not installed.

Answer

EIGRP redistribution of the summary route creates a routing loop, causing uRPF to fail.

Answer

The host behind R2 has an incorrect source address, causing uRPF to drop all traffic.

Question 8

A DMVPN network uses IPv6 with EIGRP as the routing protocol. Spoke routers R2 and R3 are behind NAT and use mGRE tunnels. The hub R1 has an IPv6 ACL applied inbound on the tunnel interface that permits only EIGRP and denies all other IPv6 traffic. Spoke-to-spoke traffic fails even though direct tunnels are established. R2 shows 'ping 2001:db8:3::1 source loopback0' fails, but 'ping 2001:db8:1::1' (hub) succeeds. What is the root cause?

Accepted Answer

R1's inbound ACL on the tunnel interface permits only EIGRP, dropping all other traffic including spoke-to-spoke data packets.. The ACL on R1's tunnel interface blocks spoke-to-spoke traffic because it is not sourced from the hub. Even though the spokes have a direct tunnel, the traffic still traverses the hub's tunnel interface if the routing is not optimized. The ACL permits only EIGRP, so data traffic is dropped.

Answer

NAT traversal is broken for spoke-to-spoke traffic due to IPsec encryption issues.

Answer

EIGRP is not advertising spoke loopbacks to other spokes, causing no route.

Answer

The mGRE tunnel on R2 does not have a destination for R3, preventing direct communication.

Question 9

An MPLS network uses LDP for label distribution with IPv6. Router R1 and R2 are LDP peers. R1 has an IPv6 ACL applied inbound on the interface facing R2 that permits only TCP port 646 (LDP) and denies all other traffic. R2 shows 'show mpls ldp neighbor' indicates the neighbor is up, but 'show mpls forwarding-table' shows no labels for IPv6 prefixes. R1's 'show mpls ldp bindings' shows labels for all prefixes. What is the root cause?

Accepted Answer

The ACL blocks UDP port 646, which is used for LDP label advertisement messages, preventing label distribution.. LDP uses UDP for discovery (hello) and TCP for session. The ACL permits TCP 646, so the session is established. However, LDP also uses UDP for targeted hellos or link hellos, and the ACL blocks UDP 646, preventing proper label exchange. The bindings exist but are not advertised because the UDP-based label advertisement is blocked.

Answer

LDP session is established but the routers have mismatched label ranges, causing no label bindings.

Answer

IPv6 CEF is not enabled on R1, preventing label imposition.

Answer

R2 has an outbound ACL blocking LDP packets, causing asymmetric filtering.

Question 10

A dual-stack network uses BGP for IPv6 between AS 100 and AS 200. Router R1 (AS 100) has an inbound route-map that sets local preference to 200 for routes from R2 (AS 200). R1 also has an IPv6 ACL applied inbound that permits only BGP (TCP 179) and denies ICMPv6. R2 advertises a prefix 2001:db8:1::/48. R1's BGP table shows the prefix with local preference 200, but 'show ipv6 route' does not install it. R1 has uRPF strict mode on the interface facing R2. What is the root cause?

Accepted Answer

The ACL blocks ICMPv6, which is required for IPv6 neighbor discovery. Without ND, the next-hop address of the BGP route is unresolved, preventing route installation.. uRPF strict mode checks the source address of incoming packets. For BGP updates, the source is R2's IP. But the ACL denies ICMPv6, which is used for neighbor discovery (ND). If ND fails, the next-hop address of the BGP route may be unreachable, causing the route to not be installed. Alternatively, uRPF may drop the BGP packets if the source is not reachable via that interface.

Answer

uRPF strict mode drops the BGP updates because the source address is not in the FIB.

Answer

The route-map sets local preference incorrectly, causing the route to be suppressed.

Answer

R1's BGP process has 'soft-reconfiguration inbound' enabled, causing the route to be hidden.

Question 11

An enterprise uses VRF-lite with IPv6. VRF A on R1 leaks routes to VRF B using route-target import/export. R1 has an IPv6 ACL applied inbound on the interface in VRF A that permits only OSPFv3 and denies all other traffic. R1's VRF B has a static default route pointing to a next-hop in VRF A. Traffic from VRF B to the internet fails. R1 shows 'ping vrf B 2001:db8:2::1' fails, but 'ping vrf A 2001:db8:2::1' succeeds. What is the root cause?

Accepted Answer

The ACL on the VRF A interface blocks data traffic from VRF B, which is forwarded via the leaked route.. The ACL in VRF A blocks all traffic except OSPFv3. When VRF B sends traffic to the leaked default route, the packet enters VRF A and is subject to the ACL. The ACL drops the data traffic because it is not OSPFv3. The ping from VRF A works because the source is in VRF A and not filtered by the inbound ACL.

Answer

Route leaking is not configured correctly; the route-target import/export is missing.

Answer

The static default route in VRF B has an incorrect next-hop address.

Answer

uRPF is enabled on the VRF A interface and drops traffic from VRF B due to source address mismatch.

Question 12

An OSPFv3 network has multiple areas. Area 0 includes R1 and R2. Area 1 includes R2 and R3. R2 is an ABR. R1 has an IPv6 ACL applied inbound on the interface to R2 that permits only OSPFv3 and denies all other traffic. R3 advertises a prefix 2001:db8:3::/48 into Area 1. R1's routing table shows the prefix but with a next-hop of R2. R1's uRPF is configured in strict mode on the interface to R2. Traffic from R1 to 2001:db8:3::1 is dropped. R1 shows 'show ipv6 cef 2001:db8:3::/48' points to R2's link-local address. What is the root cause?

Accepted Answer

The source address of the traffic from R1 is not in the FIB as reachable via the interface facing R2, causing uRPF strict mode to drop the packet.. uRPF strict mode checks that the source address of incoming packets is reachable via the same interface. For traffic sourced from R1's own subnet, the return route points to R2 via the same interface. However, if the source address is not in the FIB as reachable via that interface (e.g., because of a summary or default route), uRPF drops the packet. In this case, the source address is likely a prefix that is not in the FIB or is reachable via a different interface.

Answer

The ACL on R1 blocks the return traffic from the destination, causing asymmetric routing.

Answer

R2's link-local address is not reachable due to OSPFv3 network type mismatch.

Answer

The prefix 2001:db8:3::/48 is not in the OSPFv3 database on R1 due to area filtering.

Question 13

A network engineer is troubleshooting a DHCPv6 prefix delegation issue on router R1 and runs the following command:

R1# debug ipv6 dhcp detail

Output:
 IPv6 DHCP: Received SOLICIT message from FE80::21A:2BFF:FE3C:4D01 on GigabitEthernet0/0
 IPv6 DHCP: Using interface pool DHCP_POOL
 IPv6 DHCP: Sending ADVERTISE message to FE80::21A:2BFF:FE3C:4D01
 IPv6 DHCP: Received REQUEST message from FE80::21A:2BFF:FE3C:4D01
 IPv6 DHCP: Client requests prefix 2001:DB8:1::/48
 IPv6 DHCP: Prefix 2001:DB8:1::/48 not available in pool DHCP_POOL
 IPv6 DHCP: Sending REPLY message with Status Code NoPrefixAvail

What does this output indicate?

Accepted Answer

The DHCPv6 server has a pool configured but the requested prefix is not in that pool or is already allocated.. The debug output shows a DHCPv6 client requesting a specific prefix delegation, but the server's pool does not have that prefix available. The server responds with a NoPrefixAvail status code, indicating the prefix cannot be assigned.

Answer

The DHCPv6 client successfully received the prefix 2001:DB8:1::/48.

Answer

The DHCPv6 client is using a relay agent because the SOLICIT was received on a different interface.

Answer

The DHCPv6 server is configured with a stateless configuration because it sent an ADVERTISE without a prefix.

Question 14

What is the default DHCPv4 client lease time on a Cisco IOS-XE router configured as a DHCP client?

Accepted Answer

86400 seconds (1 day). Cisco IOS-XE defaults to a DHCPv4 lease time of 86400 seconds (1 day) when acting as a client, per RFC 2131 and Cisco implementation.

Answer

3600 seconds (1 hour)

Answer

43200 seconds (12 hours)

Answer

1800 seconds (30 minutes)

Question 15

An enterprise uses EIGRP for IPv6 with route redistribution from a static route. R1 has a static route 2001:db8:0::/32 via Null0 redistributed into EIGRP. R2 receives this route and has a more specific route 2001:db8:1::/32 via a different interface. R2 has an IPv6 ACL applied inbound on the interface facing R1 that permits only EIGRP and denies all other traffic. R2's uRPF is configured in loose mode. Traffic from R2 to 2001:db8:2::1 fails. R2 shows 'show ipv6 route' has both routes, but 'show ipv6 cef' shows the summary route for 2001:db8:2::1 pointing to R1. What is the root cause?

Accepted Answer

The summary route 2001:db8:0::/32 on R1 points to Null0, causing traffic to be dropped at R1.. The ACL on R2 blocks the data traffic from R2 to the destination because the traffic is sent out the interface facing R1 (due to the summary route), but the ACL is inbound on that interface. However, uRPF loose mode only checks if a route exists in the FIB, not the interface. The issue is that the ACL is blocking the outbound traffic? Actually, the ACL is inbound, so it filters incoming traffic. The traffic from R2 to the destination is outbound, so the ACL does not affect it. The real issue is that the summary route points to R1, but the destination is not reachable via R1 because R1's Null0 route drops it. The ACL is a red herring; the root cause is the summary route causing blackholing.

Answer

The ACL on R2 blocks the return traffic from R1, causing asymmetric routing.

Answer

uRPF loose mode drops the packet because the source address is not in the FIB.

Answer

EIGRP redistribution of the static route creates a routing loop between R1 and R2.

Question 16

A dual-stack network uses BGP for IPv6 between two ISPs. R1 (AS 100) receives a full BGP table from R2 (AS 200). R1 has an IPv6 ACL applied inbound on the interface to R2 that permits only BGP (TCP 179) and denies all other traffic. R1 also has uRPF configured in strict mode on the same interface. R1's BGP table has a route to 2001:db8:1::/48 with next-hop 2001:db8:2::2. R1's routing table shows the route, but traffic from R1 to 2001:db8:1::1 fails. R1 shows 'show ipv6 cef 2001:db8:1::/48' points to 2001:db8:2::2 via the interface to R2. What is the root cause?

Accepted Answer

The ACL on R1 blocks the return traffic from the destination, which is not BGP, causing the ping to fail.. uRPF strict mode checks the source address of outgoing packets? No, it checks incoming packets. For traffic from R1 to the destination, the source is R1's own address. When the return traffic comes back, uRPF checks the source of the return packet. But the issue is that the ACL blocks all traffic except BGP. When R1 sends data to the destination, the return traffic is blocked by the ACL because it is not BGP. The uRPF is not the issue; the ACL is blocking the return traffic.

Answer

uRPF strict mode drops the outgoing traffic because the source address is not reachable via the interface.

Answer

The next-hop 2001:db8:2::2 is not reachable due to a missing ND entry.

Answer

BGP next-hop resolution fails because the next-hop is not in the FIB.

Question 17

A network engineer runs the following command to debug IPv6 traffic filtering:

R1# debug ipv6 packet access-list FILTER detail
IPv6 packet debugging is on for access list FILTER (detail)

*Mar 1 00:01:23.456: IPv6: source 2001:DB8:2::1 (GigabitEthernet0/0)
*Mar 1 00:01:23.456:   dest 2001:DB8:3::1 (GigabitEthernet0/1)
*Mar 1 00:01:23.456:   traffic class 0, flowlabel 0, hlim 64, next header 6 (TCP)
*Mar 1 00:01:23.456:   denied by access-list FILTER

What does this output indicate?

Accepted Answer

The packet is denied because the source address 2001:DB8:2::1 matches the deny entry in the access list.. The debug output shows an IPv6 packet from 2001:DB8:2::1 to 2001:DB8:3::1 being denied by access-list FILTER. This matches the deny statement for the 2001:DB8:2::/48 prefix.

Answer

The packet is permitted because it is a TCP packet.

Answer

The packet is denied because of uRPF check failure.

Answer

The packet is permitted because the destination is not in the access list.

Question 18

A network engineer runs the following command to debug IPv6 uRPF:

R1# debug ipv6 verify
IPv6 verify debugging is on

*Mar 1 00:02:34.567: IPv6 verify: source 2001:DB8:4::1 on GigabitEthernet0/0
*Mar 1 00:02:34.567:   no route to source

What does this output indicate?

Accepted Answer

The packet will be dropped because uRPF cannot find a route to the source address.. The debug output shows that a packet with source address 2001:DB8:4::1 arrived on GigabitEthernet0/0, but the router has no route to that source address. With uRPF enabled, this packet will be dropped.

Answer

The packet will be forwarded because uRPF only checks the destination.

Answer

The packet will be forwarded because the source is on the same interface.

Answer

The router will add a route to the source address.

Question 19

Which IPv6 traffic filter can be used to match traffic based on the Flow Label field?

Accepted Answer

IPv6 access-list with the 'flow-label' option. IPv6 access-lists support matching on the flow label using the 'flow-label' keyword.

Answer

IPv6 prefix-list

Answer

IPv6 route-map with match ipv6 address

Answer

IPv6 uRPF

Question 20

A network engineer runs the following command to debug IPv6 uRPF with detailed information:

R1# debug ipv6 verify detail
IPv6 verify debugging is on (detail)

*Mar 1 00:03:45.678: IPv6 verify: source 2001:DB8:5::1 on GigabitEthernet0/0
*Mar 1 00:03:45.678:   route to source via GigabitEthernet0/1, not same as input interface

What does this output indicate?

Accepted Answer

The packet will be dropped because strict uRPF requires the return path to be through the same interface.. The debug output shows that a packet from source 2001:DB8:5::1 arrived on GigabitEthernet0/0, but the route to that source points out GigabitEthernet0/1. With strict uRPF, this packet will be dropped because the return path is not through the receiving interface.

Answer

The packet will be forwarded because a route exists.

Answer

The packet will be forwarded because uRPF is loose.

Answer

The router will change the route to use GigabitEthernet0/0.