300-410 Practice Test 30 — 15 Questions

Question 1

In IPv6 FHS, what is the default action for 'RA Guard' when a rogue RA is detected on a switch port?

Accepted Answer

Drop the RA and generate a syslog message. In IPv6 First Hop Security (FHS), RA Guard is designed to block rogue Router Advertisement (RA) messages on switch ports. When a rogue RA is detected, the default action is to drop the offending packet and generate a syslog message, as specified by the 'drop' policy in the 'ipv6 nd raguard' configuration. This prevents unauthorized devices from advertising themselves as routers, mitigating man-in-the-middle attacks.

Answer

Forward the RA to the CPU for inspection

Answer

Shut down the port

Answer

Send a notification to the network management system

Question 2

A network engineer configures Flexible NetFlow on a router that also runs CoPP (Control Plane Policing). After applying the flow monitor to the ingress interface, the router's CPU spikes and management traffic (SSH, SNMP) becomes intermittent. Router R1 shows: show policy-map control-plane | include (class|police) class CoPP-MGMT police rate 10000 pps. show flow monitor FLOW-MONITOR statistics | include (Packets|Dropped) Packets dropped: 5000. What is the root cause?

Accepted Answer

CoPP is rate-limiting NetFlow export packets because they are classified as management traffic, causing export failures and cache buildup.. Flexible NetFlow can generate a large number of packets for export, especially if the flow monitor is configured to export all flows. These export packets are sent from the router's control plane, and if CoPP is policing management traffic, the export packets might be classified as management traffic and dropped. However, the show output indicates that the flow monitor itself is dropping packets, which suggests that the flow monitor's cache is full or that the export process is overwhelmed. The correct answer is that the flow monitor's cache is too small, causing packets to be dropped before they can be exported, and the CPU spike is due to the export process consuming resources. But the CoPP is also rate-limiting the export packets, causing further drops. The root cause is that CoPP is rate-limiting the NetFlow export traffic, which is classified as management traffic, causing the export to fail and the cache to fill up.

Answer

The flow monitor's cache size is too small, causing packet drops and CPU spikes due to cache overflow.

Answer

The flow exporter is configured with a wrong destination IP, causing all export packets to be dropped by the router.

Answer

The flow monitor is applied in the output direction, causing a loop.

Question 3

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

Accepted Answer

Verify Layer 3 connectivity with ping. Troubleshooting OSPF adjacency failures starts with verifying Layer 3 connectivity using ping. Next, check that OSPF is enabled on the correct interfaces with show ip ospf interface. Then, verify OSPF network type and area ID match on both sides. After that, check for mismatched authentication settings. Finally, clear the OSPF process to reset adjacency attempts.

Question 4

An MPLS network with IPv6 over MPLS (6PE) is experiencing loss of IPv6 routes from a remote provider edge (PE) router. Router PE1 has the following relevant configuration: interface GigabitEthernet0/0 ipv6 address 2001:DB8:1::1/64 mpls ip interface Loopback0 ip address 192.0.2.1 255.255.255.255 router ospf 1 router-id 192.0.2.1 redistribute bgp 65000 subnets. Router PE2 shows: PE2# show bgp ipv6 unicast 2001:DB8:2::/64 % Network not in table. PE2# show mpls forwarding-table 192.0.2.1 Label: 16, Interface: GigabitEthernet0/1. What is the root cause?

Accepted Answer

PE1 is missing the network 2001:DB8:2::/64 command under router bgp for IPv6 unicast address family.. The output shows that PE2 has an MPLS label (16) for PE1's loopback (192.0.2.1) and can forward labeled traffic, but the IPv6 route 2001:DB8:2::/64 is missing from the BGP table. This indicates that PE1 is not advertising the IPv6 prefix into BGP. The missing `network 2001:DB8:2::/64` command under the IPv6 unicast address family on PE1 prevents the prefix from being injected into BGP, even though the interface is configured with the IPv6 address and OSPF redistribution is in place.

Answer

The MPLS label distribution between PE1 and PE2 is failing due to LDP mismatch.

Answer

OSPF is not redistributing the IPv6 prefix correctly.

Answer

The IPv6 address family is not enabled under router bgp on PE1.

Question 5

Two routers R1 and R2 are connected via Ethernet link, but OSPF adjacency is not forming. Router R1 has the following relevant configuration: interface GigabitEthernet0/0 ip address 10.1.1.1 255.255.255.252 ip ospf network point-to-multipoint ip ospf 1 area 0 Router R2 shows: show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 10.1.1.2 1 FULL/DR 00:00:35 10.1.1.2 GigabitEthernet0/0 But R2's configuration: interface GigabitEthernet0/0 ip address 10.1.1.2 255.255.255.252 ip ospf network broadcast ip ospf 1 area 0 What is the root cause?

Accepted Answer

Network type mismatch; change both to point-to-point or broadcast.. OSPF network type mismatch: R1 is configured as point-to-multipoint, which does not elect DR/BDR and uses multicast 224.0.0.5 for all neighbors. R2 is broadcast, expecting DR/BDR election and using 224.0.0.6 for DR/BDR communication. This mismatch prevents proper adjacency formation, though R2 sees R1 as FULL due to unidirectional hello. The correct fix is to match network types.

Answer

The subnet mask is /30, which is not supported with point-to-multipoint.

Answer

The OSPF area is mismatched; both are area 0.

Answer

The IP addresses are on different subnets; both are 10.1.1.0/30.

Question 6

A network engineer configures 'ipv6 snooping' globally on a switch and applies 'ipv6 verify source' on a port connected to a router running OSPFv3. The router's OSPFv3 neighborship with another router across the switch fails. The switch logs show that OSPFv3 packets are being dropped. The engineer checks the binding table and sees no entries for the router's link-local address. What is the most likely reason?

Accepted Answer

Source Guard does not learn link-local addresses via ND snooping, so OSPFv3 packets are dropped.. IPv6 Source Guard, enabled by 'ipv6 verify source', relies on the IPv6 binding table to permit traffic. The binding table is populated by IPv6 Neighbor Discovery (ND) snooping, which learns global unicast and link-local addresses from ND messages. However, OSPFv3 uses its own Hello and LSA packets sent to the multicast address FF02::5, which are not ND messages. Since the router's link-local address is not learned via ND snooping, no binding entry exists, and Source Guard drops the OSPFv3 packets, causing the neighborship to fail.

Answer

OSPFv3 uses multicast addresses that are blocked by Source Guard.

Answer

The router must be configured as a static binding for its link-local address.

Answer

The switch must have 'ipv6 snooping' enabled on the VLAN, not globally.

Question 7

An engineer configures an IPsec site-to-site VPN using IKEv1 with aggressive mode. The VPN tunnel establishes, but after some time, the tunnel goes down and re-establishes repeatedly. The engineer notices that the ISAKMP SA lifetime is set to 86400 seconds on one router and 3600 seconds on the other. What is the most likely explanation for the instability?

Accepted Answer

Aggressive mode does not negotiate ISAKMP SA lifetimes; the responder's lifetime is used, so the SA expires at different times, causing re-key failures.. In IKEv1 aggressive mode, the ISAKMP SA lifetime is not negotiated; the responder's configured lifetime is used. With lifetimes of 86400 seconds (24 hours) on one router and 3600 seconds (1 hour) on the other, the responder will enforce its own 3600-second lifetime. When the SA expires after 3600 seconds, the re-key occurs, but the initiator still expects the longer lifetime, causing a mismatch in the re-key timing and leading to repeated tunnel drops and re-establishments.

Answer

The IPsec transform set uses ESP with null encryption, which is incompatible with aggressive mode.

Answer

The ISAKMP SA lifetime mismatch causes the IPsec SA to be re-keyed with different parameters, leading to a transform set mismatch.

Answer

Aggressive mode requires pre-shared keys to be identical, and a mismatch causes the tunnel to drop after the first re-key.

Question 8

An engineer configures PBR with a route-map that sets the next-hop to 10.0.0.2 for traffic from subnet 192.168.1.0/24. The route-map is applied inbound on interface GigabitEthernet0/0. The engineer also enables 'ip cef' globally. Traffic from 192.168.1.0/24 is not being policy-routed; instead, it follows the routing table. What is the most likely cause?

Accepted Answer

The interface needs the 'ip route-cache policy' command to enable CEF support for PBR.. PBR and CEF interact in a specific way: PBR is processed in software (process switching) by default, but CEF-switched packets bypass PBR unless 'ip route-cache policy' is enabled on the interface. Without this command, CEF fast-switches packets, ignoring PBR.

Answer

CEF is disabled globally, causing PBR to fail.

Answer

The route-map is missing a 'set interface' command.

Answer

The ACL in the route-map is using a named ACL instead of a numbered one.

Question 9

A VRF-aware network has VRF BLUE on routers R1 and R2. Routes are leaked between VRF BLUE and the global table on R1 using route-replicate. R2 shows: 'show ip route vrf BLUE' includes a route 10.10.10.0/24 learned via OSPF, but 'show ip route' (global) on R1 does not include this route. R1 configuration: ip vrf BLUE, rd 100:1, route-target export 100:1, route-target import 100:1, and 'route-replicate from vrf BLUE to global unicast 10.10.10.0 255.255.255.0'. What is the root cause?

Accepted Answer

The 'route-replicate' command is not configured under the VRF, so it does not take effect; it must be placed under 'ip vrf BLUE'.. The 'route-replicate' command must be configured under the VRF configuration mode (i.e., 'ip vrf BLUE') to take effect. In the given scenario, it was likely applied in global configuration mode, which is incorrect. Without proper placement, the route replication does not occur, so the 10.10.10.0/24 route remains only in the VRF BLUE table on R1 and is not copied to the global routing table.

Answer

The OSPF route in VRF BLUE has a tag that prevents it from being leaked.

Answer

The route 10.10.10.0/24 is not in the VRF BLUE table on R1 because it is learned via R2.

Answer

The route-replicate command requires a route-map to specify the prefix, but none is provided.

Question 10

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 the client sent a REQUEST for prefix 2001:DB8:1::/48, but the server responded with a REPLY containing the status code NoPrefixAvail. This indicates the requested prefix is either not defined in the DHCP_POOL or has already been allocated to another client, so the server cannot assign it.

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 11

A network engineer runs the following command to troubleshoot an EIGRP issue:

R1# debug eigrp packets
EIGRP: Received HELLO on GigabitEthernet0/0 nbr 10.1.1.2
  AS 100, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0
EIGRP: Sending HELLO on GigabitEthernet0/0
  AS 100, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0
EIGRP: Received UPDATE on GigabitEthernet0/0 nbr 10.1.1.2
  AS 100, Flags 0x1, Seq 1/0 idbQ 0/0 iidbQ un/rely 0/0
EIGRP: Sending UPDATE on GigabitEthernet0/0 nbr 10.1.1.2
  AS 100, Flags 0x1, Seq 2/1 idbQ 0/0 iidbQ un/rely 0/0

What does this output indicate?

Accepted Answer

EIGRP adjacency is forming and routes are being exchanged successfully.. The output shows both incoming and outgoing Hello packets, confirming that the EIGRP adjacency is established and both routers are in the Init state or beyond. The subsequent UPDATE packets with sequence numbers (Seq 1/0 and Seq 2/1) indicate that routes are being exchanged successfully, which is the normal behavior for a forming or stable EIGRP neighbor relationship.

Answer

EIGRP adjacency is stuck in INIT state because no hello packets are received.

Answer

EIGRP is experiencing authentication failures.

Answer

EIGRP is only sending hellos but not receiving updates.

Question 12

Network management traffic from a monitoring server to routers R1, R2, and R3 is being blocked intermittently. The monitoring server uses SNMP and SSH. R1 configuration: access-list 100 permit udp any any eq snmp, access-list 100 permit tcp any any eq 22, access-list 100 deny ip any any, and 'ip access-group 100 in' on the management interface. R2 shows: 'show snmp' indicates SNMP is enabled. R3 shows: 'show ssh' indicates SSH is enabled. The monitoring server can reach R1 but not R2 or R3. What is the root cause?

Accepted Answer

The ACL permits only SNMP and SSH, but blocks other necessary traffic such as ICMP and routing protocol packets, preventing the monitoring server from reaching R2 and R3.. The ACL on R1 permits only SNMP (UDP port 161) and SSH (TCP port 22), but denies all other IP traffic. For the monitoring server to reach R2 and R3, ICMP (for ping/traceroute) and routing protocol packets (e.g., OSPF, EIGRP) are necessary to establish and maintain reachability. Since the ACL blocks these, the server cannot communicate with R2 and R3, even though SNMP and SSH are enabled on those routers.

Answer

The ACL is applied in the wrong direction; it should be applied outbound to allow traffic from the management interface.

Answer

SNMP and SSH are not enabled on R2 and R3.

Answer

The monitoring server is not in the same subnet as the management interface, so routing is required but blocked by the ACL.

Question 13

Drag and drop the steps to configure PAT (overload) for dynamic source NAT into the correct order, from first to last.

Accepted Answer

Configure an access list to match inside local addresses. The correct order follows the standard Cisco IOS-XE configuration sequence: first define an access list to match interesting traffic, then create a NAT pool (if needed), then configure dynamic source translation with overload, then apply the configuration to the inside interface, and finally apply it to the outside interface.

Question 14

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 15

What is the default CoPP policy on a Cisco IOS-XE router if no service-policy is applied to the control-plane?

Accepted Answer

No CoPP policy is applied; all control-plane traffic is processed without rate-limiting.. C is correct because Cisco IOS-XE routers do not apply any default CoPP policy to the control-plane. Without an explicit 'service-policy' configuration under the 'control-plane' configuration mode, all control-plane traffic (including routing protocols, management traffic, and keepalives) is processed by the route processor without any rate-limiting or filtering. CoPP is an optional feature that must be manually configured to protect the control plane from excessive traffic.

Answer

All control-plane traffic is rate-limited to 64000 bps.

Answer

Only management traffic (SSH, Telnet) is rate-limited to 32000 bps.

Answer

A default policy is applied that drops all traffic exceeding 128000 bps.