300-410 Quick Quiz — 10 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.