300-410 Practice Exam 54 — 20 Questions

Question 1

A network engineer configures Control Plane Policing (CoPP) on a DMVPN hub router to protect the control plane. The policy includes a class-map matching NHRP traffic and a police rate of 1000 pps. Unexpectedly, after applying the policy, NHRP registrations from spokes fail intermittently, and debug shows packets being dropped by CoPP. Which is the most likely explanation?

Choose an answer to begin — your selection is scored in the full session.

Accepted Answer

The CoPP policy's class-default has a lower police rate or is set to drop, and NHRP traffic is not explicitly matched in a higher class, causing it to fall into class-default and be dropped.. CoPP rate-limits control plane traffic. If the police rate is set in packets per second (pps), but the actual NHRP registration traffic is bursty (e.g., multiple spokes registering simultaneously), the policer may drop packets. The corner case is that the default CoPP class-default may also match NHRP traffic if not explicitly classified, and the class-default may have a lower rate or be set to drop. Additionally, CoPP uses a token bucket; if the rate is too low or the burst size is insufficient, packets are dropped. The engineer should ensure that NHRP traffic is matched in a dedicated class with appropriate rate and burst.

Answer

The police rate of 1000 pps is too high for the hub's CPU, causing the router to drop packets due to CPU overload.

Answer

The CoPP policy is applied to the wrong interface; it should be applied to the tunnel interface, not the physical interface.

Answer

The NHRP packets are being classified as 'critical' traffic, and the CoPP policy has a lower priority for critical traffic.

Question 2

A network engineer runs the following command to troubleshoot IPv6 source guard:

R1# debug ipv6 source-guard

*Mar  1 00:04:56.789: IPv6-Source-Guard: R1, Fa0/0, IPv6 packet from 2001:db8::5, src MAC 0011.2233.4455, dst 2001:db8::1
*Mar  1 00:04:56.789: IPv6-Source-Guard: R1, Fa0/0, Binding lookup: 2001:db8::5 not found in binding table
*Mar  1 00:04:56.789: IPv6-Source-Guard: R1, Fa0/0, Packet dropped: source 2001:db8::5 not allowed

What does this output indicate?

Accepted Answer

IPv6 source guard is dropping packets from sources not in the binding table, preventing spoofing.. The debug output shows that IPv6 source guard is actively dropping a packet from source address 2001:db8::5 because that address is not found in the binding table. This is the core function of IPv6 source guard: it filters traffic based on the source IPv6 address and MAC address, using the binding table (populated by DHCPv6 snooping or ND snooping) to prevent spoofing attacks. The packet is dropped because the source address is not allowed, confirming that option A is correct.

Answer

IPv6 source guard is allowing the packet because the source MAC matches.

Answer

IPv6 source guard is not configured; the debug output is from default IPv6 forwarding.

Answer

IPv6 source guard is learning the binding from the packet and will allow future packets.

Question 3

An engineer configures unicast Reverse Path Forwarding (uRPF) in strict mode on the DMVPN hub's physical interface facing the WAN. Unexpectedly, spokes are unable to communicate with each other via the hub, even though direct spoke-to-spoke tunnels are working. Which is the most likely explanation?

Accepted Answer

uRPF strict mode on the physical interface drops packets from spokes because the reverse path to the spoke's tunnel IP is via the DMVPN tunnel interface, not the physical interface.. uRPF strict mode checks that the source IP address of incoming packets has a route back to the source via the same interface. In a DMVPN network, when a spoke sends traffic to another spoke via the hub, the source IP is the spoke's tunnel IP. The hub's routing table may have a route to that spoke's tunnel IP via the DMVPN tunnel interface, not the physical WAN interface. Therefore, uRPF strict mode on the physical interface drops the packet because the reverse path is not through the same interface. The fix is to use uRPF loose mode or allow-default option, or apply uRPF on the tunnel interface.

Answer

uRPF strict mode on the physical interface drops packets because the source IP of the spoke is not in the routing table at all.

Answer

uRPF strict mode is incompatible with DMVPN because the tunnel interface uses GRE encapsulation, which modifies the source IP.

Answer

The 'allow-default' option is not configured, which is required for uRPF to work with DMVPN.

Question 4

An engineer configures OSPF on two directly connected routers with MTU 1500 on one interface and MTU 1600 on the other. The OSPF adjacency remains stuck in EXSTART/EXCHANGE state. Which is the most likely explanation?

Accepted Answer

The larger MTU interface sends DBD packets that are too big for the smaller MTU interface, preventing the exchange of LSAs.. OSPF uses IP protocol 89 and directly exchanges Database Description (DBD) packets during the EXSTART/EXCHANGE state. When the MTU on one interface is smaller (1500) than the DBD packet size sent by the neighbor with the larger MTU (1600), the smaller interface drops the oversized packet. This prevents the successful exchange of LSAs, causing the adjacency to remain stuck in EXSTART/EXCHANGE.

Answer

OSPF uses TCP, and the MSS mismatch causes the adjacency to fail.

Answer

The MTU mismatch causes a routing loop that prevents the exchange of hello packets.

Answer

The router with the smaller MTU will not send hello packets because it detects the mismatch.

Question 5

A network engineer runs the following command to troubleshoot OSPF over DMVPN:

R1# debug ip ospf adj

OSPF: 2 Way Communication to 10.0.0.2 on Tunnel0, state 2WAY
OSPF: Send DBD to 10.0.0.2 on Tunnel0 seq 0x1234 opt 0x52 flag 0x7
OSPF: Rcv DBD from 10.0.0.2 on Tunnel0 seq 0x1235 opt 0x52 flag 0x2
OSPF: Exchange Done with 10.0.0.2 on Tunnel0
OSPF: Build router LSA for area 0, router ID 1.1.1.1

What does this output indicate?

Accepted Answer

OSPF adjacency with 10.0.0.2 is forming successfully and will reach FULL state.. The debug shows OSPF adjacency formation: 2-way state, database description exchange, and exchange done, indicating a full adjacency is being established.

Answer

OSPF adjacency with 10.0.0.2 is stuck in 2WAY state and not progressing.

Answer

OSPF is not enabled on Tunnel0.

Answer

There is an OSPF MTU mismatch causing the adjacency to fail.

Question 6

R1 and R2 are connected via an IPsec VPN tunnel. They are running OSPF over the tunnel. R1's show ip ospf neighbor shows R2 as FULL, but R1's show ip ospf database shows the LSA from R2 but with a high age (e.g., 3600). R1's show ip route does not have routes from R2. What is the root cause?

Accepted Answer

The OSPF dead interval on R1's tunnel interface is too short, causing frequent neighbor resets and LSA aging.. When the OSPF dead interval on R1's tunnel interface is too short, R1 may temporarily lose neighbor adjacency with R2, causing the LSA from R2 to be prematurely aged out (age reaches 3600, the MaxAge) and removed from the OSPF database. Even though the neighbor state shows FULL at the moment of inspection, the LSA has already been flushed due to a previous timeout, so routes are not installed in the routing table.

Answer

The IPsec tunnel is dropping OSPF packets due to MTU issues.

Answer

OSPF network type is point-to-multipoint, causing LSA flooding issues.

Answer

R2 has a distribute-list out filtering OSPF routes.

Question 7

Consider the following configuration:

ipv6 access-list FILTER
 permit ipv6 2001:db8:3::/48 any
 deny ipv6 any any

interface GigabitEthernet0/5
 ipv6 traffic-filter FILTER in
 ipv6 verify unicast source reachable-via rx

A packet arrives on GigabitEthernet0/5 with source 2001:db8:3::100 and destination 2001:db8:4::1. The route for 2001:db8:3::/48 points out interface GigabitEthernet0/6. What happens?

Accepted Answer

The packet is dropped by uRPF because strict mode requires the source to be reachable via the receiving interface.. The packet is dropped by uRPF (unicast Reverse Path Forwarding) in strict mode because the `ipv6 verify unicast source reachable-via rx` command checks that the source address 2001:db8:3::100 is reachable via the receiving interface (GigabitEthernet0/5). The route for the source prefix 2001:db8:3::48 points out GigabitEthernet0/6, not the receiving interface, so uRPF fails and drops the packet before the ACL is evaluated.

Answer

The packet is permitted because the ACL matches and uRPF is not applied.

Answer

The packet is dropped by the ACL because the deny statement blocks all traffic.

Answer

The packet is permitted because uRPF only checks destination addresses.

Question 8

An MPLS network is experiencing label distribution failures. Router R1 (LSR) has the following configuration: mpls ldp neighbor 10.0.0.2 password cisco. Router R2 shows: 'show mpls ldp neighbor' lists R1 as 'Oper Down' with reason 'TCP MD5 authentication failure'. R1's 'show mpls ldp neighbor' shows R2 as 'Oper Down' with the same reason. Both routers have the same password configured. What is the root cause?

Accepted Answer

The LDP neighbor IP address configured on R1 does not match R2's LDP transport address, causing MD5 authentication to fail.. LDP uses TCP for session establishment, and MD5 authentication is configured via the 'mpls ldp neighbor' command. However, the password must match on both ends, and the command must specify the correct neighbor IP. If the IP address specified is incorrect (e.g., using a loopback IP instead of the transport address), the authentication will fail. Additionally, the 'mpls ldp password' command under the interface or global configuration may be required. In this scenario, the root cause is likely that the neighbor IP in the command does not match the actual LDP transport address (e.g., R1 uses 10.0.0.2 but R2's LDP transport address is 10.0.0.3).

Answer

The password is not configured globally under 'mpls ldp password' on both routers.

Answer

The MPLS LDP session is using a different port number, causing authentication to be ignored.

Answer

The interface between R1 and R2 has 'mpls ip' disabled.

Question 9

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?

Accepted Answer

It sets the weight of all routes learned from 10.6.6.7 to 200, making them preferred over routes with lower weight.. 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.

Answer

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

Answer

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

Answer

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

Question 10

A network engineer runs the following command on Router R1:

R1# show policy-map control-plane

Control Plane

Service-policy input: CoPP

class-map: MANAGEMENT (match-all)
      5 packets, 500 bytes
      5 minute offered rate 0 bps
      police:
          cir 8000 bps, bc 1500 bytes
        conformed 5 packets, 500 bytes; actions:
          transmit
        exceeded 0 packets, 0 bytes; actions:
          drop
        conformed 0 bps, exceed 0 bps

class-map: ATTACK (match-all)
      100 packets, 10000 bytes
      5 minute offered rate 0 bps
      police:
          cir 8000 bps, bc 1500 bytes
        conformed 0 packets, 0 bytes; actions:
          transmit
        exceeded 100 packets, 10000 bytes; actions:
          drop
        conformed 0 bps, exceed 0 bps

Based on this output, what is happening to traffic matching class ATTACK?

Accepted Answer

All traffic in class ATTACK is being dropped.. The output shows that for class ATTACK, 100 packets were exceeded and dropped. This means the traffic rate exceeded the committed information rate (CIR) of 8000 bps, and all packets were dropped as per the exceed action.

Answer

All traffic in class ATTACK is being transmitted.

Answer

Traffic in class ATTACK is being rate-limited but not dropped.

Answer

Traffic in class ATTACK is being marked down.

Question 11

A network engineer runs the following command on Router R1:

R1# show event manager history events

Event History:
No.  Time                Type                Name
1    00:01:30 UTC Mar 1  syslog              EIGRP_Neighbor_Down
2    00:01:31 UTC Mar 1  syslog              OSPF_Neighbor_Flap
3    00:01:32 UTC Mar 1  syslog              EIGRP_Neighbor_Down
4    00:01:33 UTC Mar 1  syslog              OSPF_Neighbor_Flap

Based on this output, what is the most likely problem?

Accepted Answer

The router is experiencing network instability causing repeated neighbor state changes.. The 'show event manager history events' command shows the last triggered events. The output shows repeated syslog events for EIGRP neighbor down and OSPF neighbor flap within a short timeframe, indicating a flapping condition. The correct answer is that the router is experiencing network instability causing repeated neighbor state changes.

Answer

The EEM policies are not configured correctly.

Answer

The EEM applet policies are disabled.

Answer

The syslog server is not reachable.

Question 12

A network engineer configures redistribution between OSPF and EIGRP on a multi-access link. After configuration, OSPF neighbors keep flapping. Router R1 config:
interface GigabitEthernet0/0
 ip ospf network broadcast
 ip ospf hello-interval 10
!
router ospf 1
 redistribute eigrp 100 subnets
!
router eigrp 100
 redistribute ospf 1 metric 10000 100 255 1 1500

R1# show ip ospf neighbor
Neighbor ID     Pri   State           Dead Time   Address         Interface
192.168.1.2      1   FULL/DR        00:00:35     10.1.1.2        GigabitEthernet0/0
192.168.1.3      1   2WAY/DROTHER   00:00:31     10.1.1.3        GigabitEthernet0/0

What is the root cause?

Accepted Answer

The OSPF hello interval is too low, causing neighbor flapping under load from redistribution.. The OSPF network type is broadcast, but the EIGRP redistribution may be causing OSPF LSAs to be flooded with high CPU load, leading to neighbor flapping. Additionally, the hello interval is set to 10 seconds, but the dead interval is not explicitly set, defaulting to 40 seconds. If the router is overloaded, hello packets may be missed. The fix is to increase the dead interval or adjust the network type to point-to-point.

Answer

The EIGRP metric is misconfigured, causing route inconsistency.

Answer

The OSPF network type broadcast requires a DR/BDR election, causing instability.

Answer

The redistribute command under OSPF is missing the metric type.

Question 13

A network engineer is troubleshooting a DHCPv4 relay scenario where clients on subnet 10.1.1.0/24 are unable to obtain IP addresses from a DHCP server at 192.168.1.10. The router interface Gi0/0 (10.1.1.1/24) has 'ip helper-address 192.168.1.10' configured. The engineer captures packets and sees DHCP DISCOVER messages sourced from 10.1.1.1 being sent to 192.168.1.10, but no replies are seen. The server is reachable via ping from the router. What is the most likely cause?

Accepted Answer

The DHCP server is not configured with a scope for subnet 10.1.1.0/24.. The DHCP server may not have a route back to the client subnet (10.1.1.0/24) or the server's default gateway does not have a route. The relay agent sets the gateway IP address (giaddr) to the interface IP (10.1.1.1), and the server sends the OFFER back to that giaddr. If the server cannot reach 10.1.1.1, the reply is lost. However, the engineer confirms the server is reachable via ping, so the issue is likely that the server is not configured with a scope for the 10.1.1.0/24 subnet, causing it to drop the DISCOVER.

Answer

The DHCP server does not have a route to 10.1.1.0/24.

Answer

The 'ip helper-address' command should be configured on the server-facing interface, not the client-facing interface.

Answer

The router needs the 'ip dhcp relay information option' command.

Question 14

A network engineer runs the following command on switch SW1:

SW1# show monitor session 1
Session 1
---------
Type : Local Session
Source Ports :
    Both : Gi0/1, Gi0/2
Destination Ports : Gi0/3
    Encapsulation : Native
    Ingress : Disabled

Based on this output, which statement is correct?

Accepted Answer

The SPAN session is monitoring traffic on Gi0/1 and Gi0/2 and sending it to Gi0/3.. The output shows a local SPAN session with source ports Gi0/1 and Gi0/2, and destination port Gi0/3. The destination port is configured with native encapsulation and ingress is disabled, meaning traffic received on the destination port is not forwarded. The session is active and correctly configured.

Answer

The SPAN session is monitoring traffic on Gi0/3 and sending it to Gi0/1 and Gi0/2.

Answer

The SPAN session is using RSPAN because the destination port has ingress disabled.

Answer

The SPAN session is not active because the destination port is not in forwarding state.

Question 15

A large enterprise network is experiencing intermittent IPv6 connectivity between two remote sites connected via an IPv6-in-IPv4 manual tunnel. Router R1 has the following relevant configuration: interface Tunnel0 ipv6 address 2001:DB8:1::1/64 tunnel source 192.0.2.1 tunnel destination 198.51.100.1 ipv6 route 2001:DB8:2::/64 Tunnel0. Router R2 shows: R2# show ipv6 route 2001:DB8:1::/64 % Route not found. The tunnel interface is up/up on both routers, and IPv4 reachability between tunnel endpoints is verified. What is the root cause?

Accepted Answer

R2 is missing a static route for 2001:DB8:1::/64 pointing to its Tunnel0 interface.. The issue is that R2 has no route to the 2001:DB8:1::/64 network, which is the tunnel subnet on R1's side. Even though the tunnel is up/up and IPv4 reachability exists, R2 cannot return traffic to R1's tunnel endpoint address because it lacks a static route pointing to its own Tunnel0 interface. This is a common misconfiguration in point-to-point IPv6-in-IPv4 manual tunnels where both sides must have reciprocal static routes for the remote tunnel networks.

Answer

The tunnel destination on R1 is incorrect and should be 198.51.100.2.

Answer

The tunnel mode must be changed to ipv6ip for IPv6-in-IPv4 tunneling.

Answer

IPv6 unicast-routing is disabled on R2.

Question 16

A network engineer configures SNMPv2c on router R3 with 'snmp-server community cisco RO' and 'snmp-server community cisco RW'. The NMS can poll read-only data but fails when trying to write a configuration value. The NMS uses the RW community string. What is the most likely cause?

Accepted Answer

The community string 'cisco' is used for both RO and RW; the router applies the first matching community, which is RO.. When two SNMPv2c community strings are identical (both 'cisco'), the router applies the first matching entry in its configuration. Since 'snmp-server community cisco RO' is configured before 'snmp-server community cisco RW', the router treats all requests using 'cisco' as read-only, regardless of the intended access level. This prevents write operations even when the NMS correctly sends the RW community string.

Answer

The NMS is sending the community string in uppercase, but the router expects lowercase.

Answer

The router needs the 'snmp-server enable traps' command to allow write operations.

Answer

The NMS must use SNMPv3 for write operations; SNMPv2c does not support writes.

Question 17

Examine the following configuration:
```
interface GigabitEthernet0/3
 ip access-group WEB_ONLY out
!
ip access-list extended WEB_ONLY
 permit tcp any any eq 80
 permit tcp any any eq 443
```
What is the effect of this ACL when applied outbound on GigabitEthernet0/3?

Accepted Answer

It permits only HTTP and HTTPS traffic to leave the interface; all other traffic is denied.. The ACL named WEB_ONLY explicitly permits TCP traffic destined for ports 80 (HTTP) and 443 (HTTPS). When applied outbound on GigabitEthernet0/3, it filters traffic leaving the interface. Since every ACL has an implicit deny any at the end, only HTTP and HTTPS traffic is permitted outbound; all other traffic is denied.

Answer

It permits all web traffic entering the interface.

Answer

It permits all TCP traffic to any destination.

Answer

It has no effect because the ACL is missing a deny statement.

Question 18

An engineer applies a CoPP policy to a router to protect the control plane from a DDoS attack. The policy includes a class-map matching UDP traffic to port 123 (NTP) and polices it to 1000 bps. After the policy is applied, the engineer notices that the router's clock is not synchronizing with its NTP server. The NTP server is reachable via ping. What is the most likely cause?

Accepted Answer

The CoPP policy is dropping NTP packets because the police rate is too low.. The CoPP policy is policing NTP traffic (UDP port 123) to only 1000 bps. NTP synchronization requires a steady exchange of packets, and a 1000 bps rate is extremely low—likely insufficient to allow the NTP packets through, causing them to be dropped. Since the NTP server is reachable via ping (ICMP is not affected by this CoPP policy), the issue is clearly that the police rate is too restrictive for NTP traffic.

Answer

The NTP server is not responding because of the DDoS attack.

Answer

The CoPP class-map is not matching NTP packets because it uses the wrong port number.

Answer

The router's NTP configuration has a wrong server IP address.

Question 19

Which control plane protocol packets are classified as 'critical' in the default CoPP policy?

Accepted Answer

OSPF hello packets and BGP keepalives. In the default Control Plane Policing (CoPP) policy on Cisco IOS/IOS-XE devices, control plane protocol packets are classified into three categories: critical, normal, and medium. OSPF hello packets and BGP keepalives are classified as 'critical' because they are essential for maintaining neighbor adjacencies and routing protocol convergence; dropping these packets can cause immediate network instability. The default CoPP policy uses class maps to match these protocols and applies a higher priority (e.g., police rate) to ensure they are processed before less critical traffic.

Answer

ICMP echo requests and SSH

Answer

Telnet and HTTP

Answer

NTP and SNMP

Question 20

Drag and drop the steps to configure a Control Plane Policing (CoPP) policy into the correct order, from first to last.

Accepted Answer

Create a class-map to match control plane traffic. The correct order starts by identifying traffic with a class-map, then grouping classes in a policy-map, applying actions (e.g., drop), attaching the policy to the control-plane, and finally verifying the configuration. This follows the standard MQC (Modular QoS CLI) workflow.