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.