300-410 Practice Test 1 — 30 Questions

Question 1

Consider the following DHCPv6 configuration on router R2:

ipv6 dhcp pool DHCP6_POOL
 dns-server 2001:db8::1
 domain-name example.com
!
interface GigabitEthernet0/0
 ipv6 address 2001:db8:1::1/64
 ipv6 dhcp server DHCP6_POOL
 ipv6 nd other-config-flag
 no shutdown

What is the effect of this configuration?

Accepted Answer

Hosts on this subnet will use SLAAC to obtain their IPv6 address and then use DHCPv6 to get DNS and domain information.. The configuration uses the `ipv6 nd other-config-flag` command, which sets the 'Other Configuration' flag (O-flag) in Router Advertisement (RA) messages. This tells hosts to use Stateless Address Autoconfiguration (SLAAC) for their IPv6 address (based on the prefix in the RA) and then use DHCPv6 (stateless DHCPv6) only to obtain additional parameters like DNS server and domain name, as defined in the DHCPv6 pool.

Answer

Hosts will obtain both their IPv6 address and DNS information from the DHCPv6 pool.

Answer

The DHCPv6 pool is missing the address prefix, so it will not provide any configuration to clients.

Answer

The ipv6 nd other-config-flag command is ignored because the DHCPv6 server is configured on the interface.

Question 2

Drag and drop the steps to troubleshoot OSPF DR/BDR election on a multi-access segment into the correct order, from first to last.

Accepted Answer

Verify current DR/BDR roles with show ip ospf interface. The correct order ensures that the OSPF DR/BDR election is properly influenced. First, verify the current DR/BDR roles using show ip ospf interface. Next, set the OSPF priority on the desired router to a higher value than the current DR. Then, clear the OSPF process on all routers to force a new election. After that, verify the new DR/BDR roles have been elected as expected. Finally, confirm that adjacencies are formed with the new DR/BDR.

Question 3

Drag and drop the steps to verify and validate IPv6 traffic filtering and uRPF operational state into the correct order, from first to last.

Accepted Answer

Check uRPF config with show running-config. Validation begins with checking the uRPF configuration on the interface, then verifying the interface status, inspecting uRPF statistics, testing connectivity with ping, and finally confirming the routing table for expected routes.

Question 4

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

Accepted Answer

Display all ACLs using show access-list. First, display all ACLs with show access-list; second, check interface bindings with show ip interface; third, verify hits on each entry; fourth, confirm the ACL is active using show running-config; fifth, test traffic with extended ping or traffic generator.

Question 5

Drag and drop the steps to establish a DMVPN Phase 2 spoke-to-spoke tunnel into the correct order, from first to last.

Accepted Answer

Configure NHRP and mGRE on hub and spokes. In DMVPN Phase 2, spoke-to-spoke tunnels are built dynamically. First, the spoke must have a valid NHRP registration to the hub. When traffic from one spoke to another triggers an NHRP resolution request, the hub forwards it to the target spoke, which replies. The spoke then initiates a direct mGRE tunnel, and finally, the spoke-to-spoke IPsec session is established.

Question 6

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?

Accepted Answer

BGP is receiving routes correctly, and CoPP is not interfering with inbound updates.. 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.

Answer

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

Answer

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

Answer

BGP session is flapping due to CoPP.

Question 7

When using the 'access-group' command to apply an ACL to an interface, what is the default direction if none is specified?

Accepted Answer

The command is rejected without a direction keyword.. The 'access-group' command in Cisco IOS requires a direction keyword (either 'in' or 'out') to specify whether the ACL filters inbound or outbound traffic. If no direction is provided, the command is rejected with an error message because the direction is a mandatory parameter. This behavior is consistent across all Cisco IOS versions and platforms.

Answer

Inbound

Answer

Outbound

Answer

The command defaults to inbound.

Question 8

An engineer configures an IPsec VPN between two routers using a transform-set with ESP encryption (AES 256) and ESP authentication (SHA-256). The engineer also applies an IPv4 ACL to define interesting traffic that matches all IP traffic. After configuration, the VPN tunnel comes up, but only ICMP traffic is encrypted; other traffic like HTTP is sent in clear text. What is the most likely explanation?

Accepted Answer

The ACL for interesting traffic only permits ICMP, so only ICMP is encrypted.. The most likely explanation is that the ACL for interesting traffic only permits ICMP, so only ICMP is encrypted. In Cisco IOS, the crypto map uses the ACL to identify which traffic should be protected by IPsec. If the ACL only matches ICMP (e.g., 'permit icmp any any'), then only ICMP packets trigger IPsec encryption; all other traffic, such as HTTP, is forwarded in clear text because it does not match the ACL and is therefore not subject to IPsec processing.

Answer

The transform-set does not support HTTP traffic due to port filtering.

Answer

The IPsec SA is only established for ICMP; other traffic requires a separate SA.

Answer

The router has a NAT rule that bypasses IPsec for HTTP traffic.

Question 9

On a DMVPN Phase 2 hub-and-spoke network, an engineer applies an inbound IPv4 ACL on the tunnel interface of a spoke router to permit only traffic from specific spoke IPs. After the ACL is applied, the spoke cannot establish a direct spoke-to-spoke tunnel with another spoke, even though NHRP resolution succeeds. What is the most likely explanation?

Accepted Answer

The ACL is filtering the outer IP header of the mGRE tunnel, blocking spoke-to-spoke traffic.. In a DMVPN Phase 2 network, spoke-to-spoke traffic is encapsulated in a new IP header with the destination IP set to the target spoke's public address. When an inbound ACL is applied to the spoke's tunnel interface, it filters traffic after decapsulation, meaning it inspects the inner (original) IP header. However, the ACL is applied on the physical interface or the tunnel interface in a way that inadvertently filters the outer IP header of the mGRE tunnel, blocking the encapsulated spoke-to-spoke packets before they can be processed. Since NHRP resolution succeeds, the spoke knows the peer's address, but the actual data traffic is dropped because the ACL denies the outer encapsulation.

Answer

The ACL is filtering NHRP packets, preventing spoke-to-spoke resolution.

Answer

The spoke has a misconfigured NHRP authentication key.

Answer

The ACL is applied outbound, filtering outgoing traffic.

Question 10

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?

Accepted Answer

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

Answer

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

Answer

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

Answer

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

Question 11

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?

Accepted Answer

The spokes are missing the 'ip nhrp nhs' command to point to the hub, preventing registration and resolution of spoke-to-spoke addresses.. 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.

Answer

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

Answer

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

Answer

The tunnel source interface is not reachable between spokes.

Question 12

An engineer configures unicast Reverse Path Forwarding (uRPF) in strict mode on an interface connected to a customer network. The customer has a default route pointing to the router. After enabling uRPF, the router drops traffic from the customer that has a source IP address that is not in the routing table as a directly connected or static route. What is the most likely explanation?

Accepted Answer

Strict mode uRPF requires a specific route for the source IP; a default route is not sufficient.. Strict mode uRPF verifies that the source IP address of an incoming packet matches a specific route in the routing table, and that the interface used to reach that source IP is the same as the incoming interface. A default route (0.0.0.0/0) is a catch-all entry and does not provide a specific, directly connected or static route for the customer's source IP. Therefore, the router drops the traffic because it cannot find an exact match for the source IP in the routing table, which is a fundamental requirement of strict mode.

Answer

The customer's default route causes asymmetric routing, which breaks strict mode.

Answer

The uRPF mode should be loose mode to allow the default route.

Answer

The router has an ACL that is blocking the traffic before uRPF checks.

Question 13

An engineer configures mutual redistribution between OSPF and EIGRP on a router. Both protocols have routes for the same prefix. The engineer also applies an inbound ACL on the OSPF interface to deny certain routes from being learned via OSPF. After the ACL is applied, the router still has the prefix in the routing table, but it is learned via EIGRP instead of OSPF. What is the most likely explanation?

Accepted Answer

The ACL blocks OSPF updates, so the router learns the prefix via EIGRP with a lower AD.. The inbound ACL on the OSPF interface blocks the OSPF-learned route from being installed in the routing table. Since mutual redistribution is configured, the same prefix is also learned via EIGRP. EIGRP has a default administrative distance (AD) of 90 for internal routes, which is lower than OSPF's AD of 110. Therefore, the router selects the EIGRP route as the best path, and the prefix remains in the routing table but now points to the EIGRP next hop.

Answer

The ACL is applied outbound, so it filters OSPF routes being sent to the neighbor.

Answer

The router has a static route for the prefix with AD 1.

Answer

The OSPF process has a distribute-list that is filtering the route.

Question 14

A network engineer runs the following command on Router R1:

R1# show ipv6 interface tunnel 0
Tunnel0 is up, line protocol is up
  IPv6 is enabled, link-local address is FE80::1
  Global unicast address(es):
    2001:DB8:2::1, subnet is 2001:DB8:2::/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
  IPv6 uRPF: loose mode (allow default route)

Based on this output, what is the uRPF configuration on this interface?

Accepted Answer

uRPF is enabled in loose mode. The output explicitly shows 'IPv6 uRPF: loose mode (allow default route)', which confirms that unicast Reverse Path Forwarding (uRPF) is enabled in loose mode. In loose mode, the router checks that the source address of an incoming packet has a matching entry in the routing table, but it does not require the incoming interface to match the best return path. This is distinct from strict mode, which requires both a routing table entry and that the incoming interface is the same as the outgoing interface for the return route.

Answer

uRPF is disabled

Answer

uRPF is enabled in strict mode

Answer

uRPF is enabled but only for IPv4

Question 15

A network engineer is troubleshooting an IPv6 connectivity issue on a router that is receiving routes via EIGRP for IPv6. The engineer notices that some routes are not being installed in the routing table, even though the EIGRP neighbor relationship is established. The engineer checks the interface configuration and finds an inbound IPv6 ACL that permits only certain EIGRP packets. The ACL permits EIGRP hello packets and updates, but not EIGRP queries or replies. What is the most likely cause of the missing routes?

Accepted Answer

The ACL is blocking EIGRP query and reply packets, which are necessary for the EIGRP process to install routes.. EIGRP for IPv6 uses multicast address FF02::A for all EIGRP packets, including hello, update, query, and reply. The ACL permits only hello and update packets, blocking query and reply packets. EIGRP requires query and reply packets for the Diffusing Update Algorithm (DUAL) to converge and install routes; without them, the router cannot complete the route installation process, even though the neighbor relationship is established.

Answer

The EIGRP router ID is not configured.

Answer

The ACL is applied outbound, blocking the EIGRP updates from being sent.

Answer

The EIGRP for IPv6 is not enabled on the interface.

Question 16

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?

Accepted Answer

The hub router does not have a route to the remote spoke's LAN subnet.. 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.

Answer

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

Answer

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

Answer

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

Question 17

Which IPv6 access-list entry will deny traffic from any source to the destination prefix 2001:db8:1::/48?

Accepted Answer

deny ipv6 any 2001:db8:1::/48. The IPv6 access-list entry 'deny ipv6 any 2001:db8:1::/48' uses the correct syntax: the source is 'any' (all traffic), and the destination is the prefix 2001:db8:1::/48, which matches all addresses within that /48 range. This entry denies traffic from any source to the entire destination prefix, as required by the question.

Answer

deny ipv6 2001:db8:1::/48 any

Answer

deny ipv6 any host 2001:db8:1::1

Answer

deny ipv6 2001:db8:1::/48 2001:db8:1::/48

Question 18

An engineer configures a DMVPN Phase 2 network. Spoke routers are configured with a route map that sets the next-hop to the tunnel interface for routes learned from the hub. This is intended to allow spoke-to-spoke direct communication. However, spoke-to-spoke traffic still goes through the hub. Which is the most likely explanation?

Accepted Answer

The route map is applied on the spoke router inbound from the hub, but it should be applied on the hub router outbound to the spokes.. In DMVPN Phase 2, spoke-to-spoke direct communication requires that the spoke routers have a route with the next-hop set to the tunnel interface of the remote spoke. However, if the route map is applied inbound on the spoke from the hub, it sets the next-hop to the hub's tunnel interface, not the remote spoke. The correct approach is to use a route map on the hub that sets the next-hop to the spoke's tunnel IP when advertising routes, or to use the 'next-hop-self' command incorrectly. The edge case is that the route map is applied on the spoke, not the hub.

Answer

The route map uses a prefix-list that does not match the spoke's subnet.

Answer

The spoke routers have NHRP authentication mismatch, preventing direct communication.

Answer

The tunnel mode is mGRE on the spokes, which does not support spoke-to-spoke.

Question 19

A DMVPN phase 3 network with IPv6 over IPv4 tunnels is experiencing spoke-to-spoke tunnel failures. Hub router R1 has the following relevant configuration: interface Tunnel0 ipv6 address 2001:DB8:1::1/64 tunnel source GigabitEthernet0/0 tunnel mode gre multipoint ip nhrp network-id 1 ip nhrp map multicast dynamic ipv6 nhrp map multicast dynamic. Spoke router R2 shows: R2# show dmvpn detail Legend: Attrb -> S: Static, D: Dynamic, I: Incomplete NHRP domain: 1 Interface: Tunnel0, IPv4 NHRP Details Type:Spoke, Total NBMA Peers: 1 # Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb 1 192.0.2.2 2001:DB8:1::2 UP 00:10:00 D. What is the root cause?

Accepted Answer

The hub is missing the ip nhrp redirect command under Tunnel0.. In DMVPN Phase 3, spoke-to-spoke tunnels rely on the hub to send NHRP Redirect messages to trigger shortcut creation. The hub's configuration is missing the `ip nhrp redirect` command under Tunnel0, which prevents it from informing the spoke that a better path exists directly to another spoke. Without this redirect, the spoke never initiates an NHRP Resolution Request to build a direct tunnel, causing spoke-to-spoke communication to fail.

Answer

The spoke is missing the ip nhrp shortcut command under Tunnel0.

Answer

The tunnel mode should be gre multipoint on the spokes.

Answer

IPv6 NHRP is not supported on DMVPN phase 3.

Question 20

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?

Accepted Answer

The OSPF network types are mismatched: one side is point-to-point, the other is broadcast, causing neighbor adjacency failure.. 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.

Answer

The VRF names must match for OSPF to form neighbors.

Answer

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

Answer

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