300-410 — frequently asked questions

The LSR performing the untagged operation uses its LFIB to decide the action and forwards a plain IP packet; the downstream router, not the LSR itself, then performs the FIB lookup.

Untagged (No Label) removes the whole label stack and forwards a native IP packet, while Pop Label removes only the top label and forwards the remaining labeled packet.

It configures the UDP echo responder for the wrong operation type and uses R101's IP (1.1.1.1) instead of R201's listening address; the control port 1967 is already the default and does not need to be specified.

No, the control connection on UDP 1967 is separate from the TCP Connect data probe; the global 'ip sla responder' enables the responder, and the specific port is handled by the operation setup.

No, the command is only valid in global configuration mode. Applying it per interface results in a syntax error.

No, clearing cache does not prevent ifIndex changes on reboot. Persistence must be enabled globally to ensure stability.

The route-map is referenced inbound on one neighbor only, so it suppresses the flapping network on that session but not across all peers as the stem requires.

No; the command uses defaults (15-minute half-life, 750 reuse, 2000 suppress, 60-minute max suppress), so option A is a complete, valid configuration.

If MPLS or LDP is not enabled on the PE routers, no LSP is ever built, so there is nothing that can break. A cause of an LSP break must act on a path that previously existed.

LDP only generates a local label for prefixes it finds in the routing table, so if the prefix or mask does not match, no label binding is installed and the LFIB has no outgoing label for that destination.

RIP counts hops and 16 means unreachable, so seeding the redistributed OSPF prefix at 14 lets it pass through the remaining RIP routers and still arrive at 15, which is installable.

Poison reverse only prevents advertising a route back out the interface it was learned on; it cannot lower a hop count that has already reached 16 or make the router install the prefix.

The RD is prepended to the IPv4 prefix only to create a unique VPNv4 NLRI. It never drives which VRF receives the route — the route target's import/export matching does that.

The RT is the control-plane tag that imports routes into a VRF; the inner VPN label actually forwards the data. Only the RT is offered among these answer choices.

The ABR still injects one Type 3 default summary LSA, but it suppresses all other Type 3, 4, and 5 LSAs, so R3's LSDB contains mainly Type 1 and 2 plus the default.

NSSA no-summary allows Type 7 LSAs and is for areas redistributing external routes, so it cannot restrict area 1 to only Type 1 and 2 LSAs.

The DHCP server is already reachable via relay, and the failure is caused by DHCP snooping dropping Option 82-tagged packets, not by a missing helper address on SW3.

It disables the insertion of DHCP Option 82 by the switch, preventing the switch from adding information that can cause upstream devices to drop DHCP requests.

The egress PE advertises the implicit-null label so its upstream neighbor pops the top label first, letting the PE do only an IP lookup. Option C reverses this by having the PE strip a label before sending to a P router.

No. The savings belong to the egress PE, which avoids a label lookup followed by an IP lookup, while transit P routers keep swapping labels. Option D misplaces both the router and the lookup saved.

The implicit-null label, value 3, is bound to the destination FEC by the egress LSR and advertised with LDP. Receiving it tells the penultimate LSR to pop the outer label instead of swapping it.

RA Guard is enforced by its own device-role policy and filters RAs independently; the question asks what snooping itself is for, and that is building the binding table.

No, it snoops IPv6 control traffic such as Neighbor Discovery and DHCPv6 messages to create address, MAC and port bindings; option D is simply the closest wording available.

The prefix inherits tag 200 from R4's static route, so an entry denying tag 200 filters it out; other prefixes then fall through to the implicit deny.

Yes: the map only filters or sets attributes, so redistribute eigrp ... subnets route-map CCNP must exist under router ospf or no EIGRP prefix enters the OSPF domain.

Without allow-default, strict uRPF drops any packet whose only matching route is the default route learned from the providers, so the asymmetric return traffic from ISP2 still fails the check.

Only if the default route's exit interface happens to be fastethernet 0/1 itself, making the reverse path match the ingress interface. On a multihomed edge that alignment isn't guaranteed, so allow-default (B) is the reliable fix.

No. The guard does not block client messages or relay-forward messages from clients to servers; it blocks Advertise and Reply messages from unauthorized servers and relays.

Option D is the intended blocking answer; DHCPv6 Guard blocks server-originated Advertise and Reply messages from unauthorized servers and relay agents, though the wording is imprecise.

The log keyword only affects syslog/logging messages. debug ip packet output requires the debug keyword in the service timestamps command, so options A and C do not modify debug output.

Yes. When localtime is omitted, IOS uses UTC for timestamps. Adding show-timezone appends the time zone name (UTC), making the timestamp explicitly time-zone independent.

IPsec can encrypt traffic but lacks DMVPN's dynamic mGRE/NHRP mesh, so hub-and-spoke or full-mesh IPsec requires far more configuration and does not simplify branch-to-branch connectivity as cleanly.

DMVPN itself relies on GRE/mGRE for tunneling; you enable strong encryption by applying IPsec tunnel protection (for example, tunnel protection ipsec profile) to the DMVPN tunnel interfaces.

0.0.0.0 is only the placeholder displayed while no session is established; the real peer router ID arrives inside the OPEN message after TCP port 179 connects, so it is a symptom, not the fault.

No. Inbound or outbound route maps on a neighbor filter or modify prefixes in a given AFI/SAFI after the session is up, so they cannot block the TCP session itself.

The option bits in the OSPF hello are set by the area type, so if R1's interface is in an NSSA and R2's is not, the bits differ and R1 drops the hello, keeping the neighbor from reaching FULL.

A different area ID produces its own 'area mismatch' rejection in the hello, not an NSSA option-bit error, so aligning area numbers would not clear the symptom shown in the exhibit.

BGP synchronization blocks advertising an iBGP-learned prefix to an eBGP peer until it is validated in the IGP; with no IGP running on R2, that validation never happens.

No. The command only removes the IGP validation requirement for iBGP-learned prefixes, so routes R2 learns directly from eBGP peers are still advertised normally.

An authentication mismatch stops hellos from being accepted, so the neighbor never leaves DOWN/INIT and logs an auth failure. It cannot cause a stall after two-way communication and DBD exchange begin.

No. Blocking 224.0.0.5 or 224.0.0.6 prevents hellos entirely, leaving the neighbor in DOWN with no adjacency timers, not frozen in ExStart/Exchange.

The P router is part of the core and only forwards based on MPLS labels. It has no visibility into customer VRFs or IP prefixes.

The RD is added by the PE router to make customer IPv4 prefixes unique globally, allowing overlapping IP spaces from different customers to coexist in the VPNv4 address space.

Local authentication requires usernames/passwords stored on the router, whereas 'network credentials' implies centralized authentication via AAA servers like RADIUS or TACACS+.

No, it only restricts the number of simultaneous HTTP sessions. It must be used alongside an authentication command to secure the access.

Global IPv6 routing enables the stack, but BGP requires the specific 'address-family ipv6 unicast' configuration to process and exchange IPv6 NLRI.

No, 'ipv6 cef' only enables hardware forwarding optimization for IPv6 packets; it does not trigger BGP route exchange logic.

It means the router receives EIGRP packets but doesn't recognize the sender as a valid neighbor, often because the receiving interface isn't enabled for EIGRP.

The hub must have its interface enabled to receive and process Hellos from the spoke. If the hub's interface isn't in the network statement, it won't form an adjacency regardless of the spoke's config.

'enable password' sets a local password but does not integrate with the TACACS+ authorization process. In TACACS+ environments, 'tacacs-server enable-password' is the specific command used to define the fallback credential.

It provides a local backup method for gaining privileged EXEC access if the TACACS+ server is unavailable or denies authorization, ensuring administrators are not locked out.

It permits only 132.108.2.0/24, so the type 5 LSA for 132.108.3.0/24 still does not match the ACL.

The wildcard range is 132.108.0.0–132.108.3.255, which includes both the .2.0/24 and .3.0/24 external prefixes.

PHP pops the outer transport (LDP/IGP) label at the penultimate LSR. The VPN label survives until the egress PE, which uses it to select the VRF and forward toward the CE.

C describes the egress LSR popping the transport label, which is the explicit-null behavior when PHP is disabled, not the function of penultimate hop popping.

Standard LDP LSPs are unidirectional. However, RSVP-TE can be configured for bidirectional P2MP or specific bidirectional scenarios, but the base LSP concept is directional.

Return traffic uses a separate, independently computed LSP in the opposite direction. The two LSPs together form a bi-directional communication path.

No, in most IOS-XE releases, the dedicated management interface does not support NetFlow export functions.

It is common for ISR and ASR series running IOS-XE. Always check the specific platform datasheet or release notes.

Adding a new entry appends it to the end. Removing it allows you to re-insert it at a specific lower sequence number (like 10) to change its evaluation order.

Sequence 20 is likely the 'permit any' rule. Deleting it would prevent all other allowed traffic from passing, violating the requirement to allow everything else.

SSO maintains the forwarding state during an RP switchover internally within the router. Graceful Restart helps neighbors understand that the adjacency is being maintained despite a control plane restart, preventing neighbor flapping.

MP-BGP distributes labeled routes for VPNs. LDP is responsible for the basic label bindings in the MPLS forwarding table. The question refers to the fundamental MPLS forwarding state recovery via RP failover, which is LDP's domain.

Auto-register allows dynamic registration of operations from any source, but it does not explicitly define the UDP echo parameters. Explicit configuration is often required for specific voice traffic probes to ensure correct binding.

tcp-connect establishes a TCP connection, while udp-echo sends UDP packets. Voice traffic typically uses UDP, so udp-echo is the appropriate responder type for measuring jitter and RTT on voice ports.

MP-BGP's VPNv4 address family carries the RD and RT between PE routers only; the CE is VRF-unaware, so the PE advertises the plain IPv4 prefix using BGP IPv4.

No. P routers only swap labels; the egress PE strips the RD and RT, imports the prefix into the VRF and advertises it to the CE over BGP IPv4.

Standard Layer 2 switches do not route broadcasts. While some managed switches support DHCP relay, the exam scenario typically relies on the router interface for this function.

No. The DHCP server listens for incoming unicast requests. The relay agent (router) is responsible for forwarding the initial broadcast request to the server.

It matches any AS path ending in 100, but routes originated outside AS 100 arrive from R1 as 100 <origin-AS>, so they do not end in 100 and would still be permitted.

^100$ matches only an AS path that is exactly AS 100, while _100_ matches 100 anywhere in the path, including transit paths like 100 200.

Configuring it locally won't help because the error is caused by the REMOTE router (10.40.1.1) sending unauthenticated packets. Both sides must match.

No. OSPVv2 and OSPFv3 do not use TCP; they encapsulate directly in IP (protocol 89). Only BGP uses TCP for its control plane communication.

BFD itself detects Layer 1 and Layer 2 failures. It notifies Layer 3 protocols (like OSPF or BGP) so they can react to the loss of adjacency.

While OSPF is a Layer 3 client of BFD, BFD's native detection capability is focused on the physical and data link layers (L1/L2) to ensure rapid failure identification.

It refers to traceroute, which uses UDP packets (ports 33434-33464) to discover paths, not standard ICMP ping. The task requires permitting this specific UDP range.

No. The prompt explicitly states management and diagnostic traffic must be allowed 'strictly to/from the CORE router'. Traffic between PE routers should be denied or handled by default.

R4 mutually redistributes EIGRP and OSPF, creating multiple paths. Changing the AD ensures R3 prefers the direct EIGRP path over the OSPF external path via R4.

The pre-configured ACLs often contain 'deny' statements for the target networks (e.g., 10.0.0.0), blocking traffic. You must remove these denies or modify them to 'permit' the specific prefixes.

It ensures the entire GRE packet (including its header) is encrypted as payload inside the IPSec packet, which is required for DMVPN functionality.

Use the command 'crypto isakmp key abc123 address 0.0.0.0 mask 0.0.0.0' on the Hub to accept connections from any dynamic IP.

Prefix Guard (DHCPv6 Guard) specifically manages the registration of IPs via DHCP/SLAAC and binds them to ports, whereas Destination Guard focuses on filtering based on existing bindings without managing the registration.

No, IPv6 Snooping (ND Inspection) helps build the binding table but does not actively drop packets from unregistered sources at the edge in the same enforcement manner as the Guard features.

Yes, Flexible NetFlow supports up to ten exporters per flow monitor, whereas Traditional NetFlow is capped at two.

While you can define multiple collectors, the actual concurrent export capability for a single cache in Traditional NetFlow is restricted to two destinations.

The tunnel source must be a stable, always-up physical interface IP. Using the tunnel IP would cause the tunnel to depend on itself, creating a bootstrapping failure.

No, it is not. The standard command is tunnel mode gre multipoint, and IPsec encryption is applied separately using tunnel protection ipsec profile.

Bandwidth affects throughput, not packet size. An MTU mismatch causes packet drops regardless of available bandwidth, breaking neighbor adjacencies.

Generally no. EIGRP updates may exceed the smaller MTU and be dropped if the DF bit is set, causing neighbor timeouts and flapping.