Router R1 Cannot Reach R3 Practice Questions

Prefilter FastPath Rate Cap

Why it fails: Prefilter FastPath Rate Cap sets an early, pre-filter throughput ceiling for offloaded flows; it does not enforce a QoS policing rate within a policy map. Policing requires configuring the maximum-rate parameter on the policer itself. FastPath caps suit early traffic suppression, not per-class bandwidth enforcement.

Access Control Rate Limiting action

Why it fails: Access control rate limiting throttles connections matching an access control rule, operating before QoS policy evaluation and applying per-rule rather than per-class. Policing enforces a maximum bandwidth within a QoS policy map. Access control rate limiting suits blocking abusive connection rates, not interface bandwidth policing.

Random Early Detection (RED) drop threshold

Why it fails: RED is a congestion-avoidance mechanism that probabilistically drops packets as a queue approaches its threshold; it does not cap bandwidth. Policing needs a configured maximum rate with conform/exceed actions. RED would be chosen to smooth bursty TCP traffic and avoid tail drop, not to enforce a bandwidth limit.

Transparent mode with inline bypass enabled

Why it fails: Transparent mode with inline bypass still places the firewall physically inline, so traffic traverses it; bypass only preserves forwarding when the device fails, not under high load, and it is not out-of-band. It would suit an inline IPS needing failure resilience, not passive monitoring.

Inline deployment mode with fail-open enabled

Why it fails: Inline deployment places the firewall directly in the traffic path; fail-open only covers device failure, and high load can still drop packets, so it cannot guarantee zero production impact. It would be correct for an inline IPS where blocking is required, not passive out-of-band monitoring.

Routed mode with asymmetric routing tolerance

Why it fails: Routed mode requires the firewall to be a Layer 3 hop in the forwarding path, so production traffic must pass through it and asymmetric flows may be dropped. It would be correct for a routed, in-path firewall performing NAT and routing, not for out-of-band inspection.

FMC Captive Portal

Why it fails: Captive Portal authenticates users through an FMC-hosted web page for guest or BYOD access, generating its own mappings; it does not ingest the VPN concentrator's existing IP-to-user sessions, so VPN users stay unresolved. It would be correct where unauthenticated endpoints must be challenged before network access.

Terminal Services Agent (TS Agent)

Why it fails: TS Agent captures IP-to-user mappings on terminal servers hosting multiple sessions, not remote access VPN clients, whose mappings require the VPN integration such as the Cisco AnyConnect or ISE identity source. It is tempting because TS Agent does resolve shared-IP user mappings, but only for terminal services environments.

SNMP polling of the DHCP server

Why it fails: SNMP polling of the DHCP server retrieves lease data for DHCP-assigned endpoints, but remote access VPN clients receive addresses from the VPN pool, not DHCP, so no mapping exists to poll. It would be correct for resolving wired or wireless users whose addresses come from DHCP leases.

The rule that matches the interface

Why it fails: Interface matching alone does not decide between overlapping NAT rules; the first rule in the ordered NAT policy that matches the traffic is applied. It is tempting because interface selection is a genuine matching condition, so it feels decisive when rules differ only by interface.

The rule with the lowest priority

Why it fails: Lowest priority is not the selection criterion; overlapping NAT rules resolve by explicit ordering, with the first matching rule applied. It is tempting because priority ordering does govern other rule types, such as policy or QoS rules, where lower numbers take precedence.

The most specific rule

Why it fails: Specificity does not override ordering; NAT rules are evaluated top-down and the first match wins, regardless of how narrow the translation is. It is tempting because longest-prefix and most-specific matching do govern routing decisions, so the logic appears transferable.

The FMC eStreamer service is blocking group attribute propagation.

Why it fails: eStreamer exports event data to external collectors; it does not carry pxGrid user group attributes, so it cannot block propagation. It is tempting because eStreamer is a genuine FMC feature for streaming events to SIEM tooling, and would be the right answer if the requirement were forwarding connection or intrusion events rather than populating group memberships.

User groups can only be resolved via RADIUS accounting attributes, making pxGrid fundamentally incompatible with user group filtering.

Why it fails: pxGrid itself publishes user group and identity attributes, so group filtering does not depend on RADIUS accounting. It is tempting because RADIUS accounting does convey user sessions, and would be the correct mechanism if the deployment lacked pxGrid and relied solely on RADIUS-based identity mapping.

The FTD Snort engine must be configured with a local flat file containing all user group names.

Why it fails: Group membership arrives from ISE over pxGrid as session directory data; the FTD does not read a local flat file of group names. It is tempting because Snort rules do reference local files for IP or URL lists, which would be correct if the requirement were static blocklisting rather than dynamic user identity resolution.

FMC requires an active eStreamer connection to ingest guest identities because pxGrid only supports Active Directory domain accounts.

Why it fails: pxGrid fully supports guest identities as long as the session topic is correctly subscribed.

Guest users must manually log into a captive portal hosted on the FTD data plane before ISE can share their identity.

Why it fails: Identity propagation is handled entirely by ISE pxGrid; captive portal on FTD is not required for ISE-authenticated guests.

The FTD identity policy must be configured with a RADIUS server group instead of pxGrid to support guest VLANs.

Why it fails: pxGrid is the preferred and fully functional method for consuming ISE identity context for all user types.

The static route metric is automatically incremented by 100 while remaining active.

Why it fails: SLA tracking withdraws the route from the routing table on probe failure; it does not increment the metric by 100 and leave the route active. Metric manipulation is tempting because dynamic routing protocols use metric changes to influence path selection, but static route tracking toggles route installation rather than adjusting administrative distance or metric.

The firewall automatically reboots into maintenance mode to clear the routing cache.

Why it fails: A failed ICMP Echo SLA probe removes the tracked static route from the routing table; the device does not reboot into maintenance mode. Maintenance mode is tempting because it exists for recovery from failed image or configuration states, but SLA tracking only manipulates route presence, never device boot state.

All firewall interfaces are automatically placed in an administrative shutdown state.

Why it fails: ICMP Echo SLA tracking only withdraws the associated static route from the routing table when probes fail; it never shuts interfaces. Administrators are tempted because interface-level tracking exists, but that requires separate interface SLA monitoring, not route tracking.

VLAN object

Why it fails: A VLAN object represents a layer-2 broadcast domain and cannot carry the one-to-one public-to-private IP binding static NAT demands. It tempts because VLANs commonly group servers sharing policy, but NAT translation operates on individual IP addresses, so a static NAT object is required here.

Port object

Why it fails: A port object defines a single port or range for service matching, but cannot pair a public address with a private address, so it cannot express a NAT mapping. It is tempting because ports appear in access rules, and would be correct when permitting specific services rather than translating addresses.

Network object (Group)

Why it fails: A network object group bundles multiple addresses for use in one policy, but NAT requires a single static one-to-one binding between one public and one private IP. It tempts because groups simplify rule management when many hosts share identical treatment, yet a lone web server needs a dedicated static NAT object instead.

Route map

Why it fails: Route maps control redistribution and policy matching for routing protocols; they do not perform reachability checks. Static route tracking uses an SLA monitor object. Route maps are tempting because they influence routing decisions, but they lack the ICMP-based monitoring mechanism that triggers static route removal.

Failover group

Why it fails: Failover groups are not an FTD object for reachability checks; they relate to high-availability device pairing. Static route tracking requires an SLA monitor object that defines the reachability check. Failover is tempting because the scenario mentions failover, but that term describes device redundancy, not route tracking.

Interface tracking group

Why it fails: Interface tracking groups monitor interface status for dynamic routing protocols, not static route reachability. Static route tracking uses an SLA monitor object whose reachability check drives route removal. Interface tracking is tempting because it also tracks reachability, but it applies to interfaces rather than the SLA monitor bound to a static route.

STP topology change notifications received on the tracked interface.

Why it fails: STP topology change notifications are Layer 2 events on switched segments and carry no information about the reachability of a Layer 3 next-hop. They are tempting because STP reconvergence does restore connectivity after a link failure, which is the correct mechanism when the requirement is Layer 2 loop prevention and path failover.

FMC heartbeat loss detection between the firewall and the gateway.

Why it fails: FMC heartbeat loss only reflects management-plane connectivity between the manager and the firewall; it does not probe the primary next-hop, so a failed gateway leaves the tracked route up. It is tempting because FMC heartbeats do detect unreachable managed devices, which is the correct mechanism when the requirement is monitoring firewall health.

Automatic generation of dynamic OSPF neighbor adjacencies over the static interface.

Why it fails: Static route tracking relies on object or SLA tracking, not on forming OSPF adjacencies; the firewall does not auto-generate dynamic neighbours over a static interface. It is tempting because OSPF reconvergence does reroute around failed next-hops, which is the correct choice when the design already runs a dynamic routing protocol.

A mismatch in the NTP time synchronization greater than 5 minutes between the FTD and the FMC.

Why it fails: NTP drift beyond five minutes breaks FMC-to-FTD certificate validation, not identity map purging; user mappings expire on their own timeout or when ISE sends a CoA/reconnect. Time synchronisation matters for PKI and event correlation, so it is tempting whenever identity or logging anomalies appear.

Exceeding the FMC database storage limit for event logging.

Why it fails: FMC event storage limits affect logging retention, not the FTD user-to-IP mapping table. Identity maps are purged when the ISE probe or pxGrid session terminates, or when the user-to-IP mapping times out. Storage limits would be the cause only of lost connection events, not identity cache flushing.

Automatic daily rotation of the FMC administrator password.

Why it fails: Rotating the FMC administrator password affects management-plane authentication only; it does not touch FTD identity mappings. The cache is purged when ISE sessions end or mappings time out. Password rotation would be relevant only to administrative access failures, not to user identity cache behaviour.

Disable the Snort engine during wireless handover events.

Why it fails: Disabling Snort removes intrusion inspection entirely and has no bearing on identity mapping between ISE and FTD. Snort is disabled only for troubleshooting suspected false positives or performance issues, not to preserve user identity sessions during wireless roaming events.

Ensure the FTD is configured as an SXP speaker for wireless SSIDs.

Why it fails: SXP propagates IP-to-user mappings from ISE to FTD, but it is a fallback for devices that cannot use pxGrid directly, not a wireless roaming mechanism. It would be the right choice where pxGrid integration is unavailable and static SGT or identity propagation is needed instead.

Configure static ARP entries for all wireless client MAC addresses on the FTD.

Why it fails: Static ARP entries pin MAC-to-IP bindings and do nothing to preserve user identity sessions when a client reassociates to a new access point. Static ARP is correct for preventing ARP spoofing on a stable wired segment, not for maintaining identity continuity across roaming wireless clients.

ARP request polling sent every 3 seconds to the default gateway MAC address

Why it fails: FTD's static route tracking uses ICMP echo requests to the tracked IP, not ARP polling of the gateway MAC. ARP resolves layer-2 addresses on the local segment; it cannot verify end-to-end reachability of an arbitrary tracked destination across routed hops, which is what the SLA monitor requires.

Continuous bidirectional forwarding detection (BFD) sessions initiated directly from the routing daemon process

Why it fails: Static route tracking relies on ICMP echo replies from the tracked address; BFD is a separate protocol requiring configuration on both peers and is not what the SLA monitor invokes. BFD would be the right mechanism when sub-second failure detection between two BFD-capable devices is needed.

SNMP trap polling managed by the Firepower Management Center correlation engine

Why it fails: Reachability is verified locally by the FTD device sending ICMP echo requests, not by FMC via SNMP traps. SNMP polling is for monitoring and alerting on device state, so it would fit a management or reporting requirement, not dynamic removal of a static route from the routing table.

QoS Policy

Why it fails: QoS policy shapes and prioritises bandwidth for selected traffic; it neither authenticates users nor associates identities with IP addresses. User identity mapping requires a realm plus an identity source, whereas QoS policy is the right configuration when the requirement is rate limiting or prioritising specific applications.

Network Discovery Policy

Why it fails: Network Discovery Policy controls which hosts and networks are passively detected and added to the network map; it produces host and application data, not user-to-IP bindings. Identity mapping instead needs a realm and identity source, so discovery is correct only when populating the network map for host awareness.

SSL Policy

Why it fails: SSL policy governs TLS inspection and certificate handling for encrypted traffic; it decrypts flows but does not collect user-to-IP mappings. Identity mapping needs a realm and an identity source (such as AD or Cisco ISE), so SSL policy would be the correct component only when the requirement is inspecting encrypted sessions.

The NAT translation table lacks a dynamic PAT port allocation for the source IP.

Why it fails: NAT failures are reported at the NAT phase, not Access-Rule, so a missing PAT allocation cannot produce this drop. NAT is tempting because translation problems also silently discard packets, and the NAT phase would be the correct indicator had the trace shown no matching dynamic PAT rule for 192.168.1.50.

The FTD routing table does not have a valid route back to the source IP 192.168.1.50.

Why it fails: Reverse-path or routing failures appear at the Route-Lookup phase, not Access-Rule, so a missing return route cannot cause this drop. Engineers suspect routing because asymmetric paths commonly break traffic, and Route-Lookup would be the correct phase to cite had the trace shown no matching route to 10.0.0.5.

The SSL decryption policy failed to validate the server certificate for 10.0.0.5.

Why it fails: SSL decryption failures surface at the SSL-Decrypt phase, not Access-Rule, so a certificate validation error cannot produce this drop. Certificate validation is tempting because it also blocks traffic, but it applies only when an SSL Decryption policy inspects outbound TLS, which this plain HTTP port 80 trace never triggers.