Why Is a Transparent FTD Not Processing ERSPAN Traffic?
An administrator is configuring their transparent Cisco FTD device to receive ERSPAN traffic from multiple switches on a passive port, but the Cisco FTD is not processing the traffic. What is the problem?
Community Insight
The exam tests whether you know that ERSPAN termination requires an IP-addressed interface, which exists only in routed mode — the trap is blaming the passive/SPAN interface design instead of the transparent firewall mode.
A transparent Cisco FTD cannot terminate ERSPAN traffic because Cisco supports ERSPAN interfaces only in routed firewall mode. This page confirms the correct answer, explains why the passive port and monitor session ID options miss the real restriction, and backs it with Cisco documentation.
Most candidates pick D, assuming the port type (passive vs. dedicated ERSPAN port) is the blocker; a passive interface can be an ERSPAN passive interface, so the interface type is not the problem — the transparent firewall mode is.
Community Discussion (11 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
Cisco's Secure Firewall configuration guide for inline sets and passive interfaces states directly that "ERSPAN interfaces are only allowed when the device is in routed firewall mode." ERSPAN delivers mirrored frames inside a GRE encapsulation, so the receiving FTD interface must be a Layer 3 interface that terminates the tunnel using a flow ID, source IP, and its own IPv4 address. A transparent FTD operates as a Layer 2 bridge and has no IP-addressed interface to terminate that GRE stream, so the mirrored packets are never processed. The question explicitly says the device is transparent, which makes the mode mismatch — not the switch configuration — the root cause. Option C is therefore the decisive fix: move the FTD to routed mode to use ERSPAN.Why the Other Options Are Wrong
Option A correctly describes a normal ERSPAN prerequisite (the switches need routable paths for the GRE-encapsulated copy), but it is not the failure here: with a transparent FTD the tunnel cannot be terminated at all, so fixing switch-side Layer 3 connectivity would not help. Option B points at the monitor session ID / flow ID pairing, which is a legitimate configuration parameter, but a wrong session ID would simply deliver no traffic even on a routed device — it does not explain an explicit transparent-mode restriction. Option D confuses the interface role with the firewall mode; a passive interface is exactly what handles SPAN or ERSPAN copies, and Cisco documents it as a valid inline-set/passive-interface design as long as the device is routed. None of these three address the mode requirement that blocks ERSPAN processing.Community Comment Notes
MB2222 quoted the exact Cisco guideline and pointed to the section "Guidelines for Inline Sets and Passive Interfaces," noting that "ERSPAN interfaces are only allowed when the device is in routed firewall mode." Joe_Blue and lapsi echo the same documentation quote, and Silexis and Initial14 state flatly that ERSPAN is configured only in routed mode. donciga adds the technical reason: the terminating interface needs an IP address, flow ID, and source IP, which a transparent FTD cannot provide. Seawanderer initially argued for Layer 3 connectivity, while Bbb78 corrected course mid-thread, writing that "this FTD is in transparent mode" and landing on C — a useful reminder to re-read the deployment mode before answering.Official Reference
- https://www.cisco.com/c/en/us/td/docs/security/firepower/640/configuration/guide/fpmc-config-guide-v64/inline_sets_and_passive_interfaces_for_firepower_threat_defense.html
- https://www.cisco.com/c/en/us/td/docs/security/firepower/630/configuration/guide/fpmc-config-guide-v63/inline_sets_and_passive_interfaces_for_firepower_threat_defense.html
Exam Strategy
When a question mentions ERSPAN on a Cisco FTD, first check the firewall mode stated in the scenario; transparent mode is an instant disqualifier because ERSPAN needs a routed interface to terminate the GRE copy. Watch for answer options that describe valid general ERSPAN prerequisites (Layer 3 reachability, session/flow IDs) — those are distractors designed to look plausible but not to match the stated deployment mode.
Frequently Asked Questions
Why can't a transparent Cisco FTD terminate ERSPAN traffic?
ERSPAN arrives as GRE-encapsulated copies that must be terminated by an IP-addressed interface with a flow ID and source IP; a transparent (Layer 2) FTD has no such interface, so only routed mode supports ERSPAN.
Does the passive port or the monitor session ID cause the failure?
No. A passive/ERSPAN passive interface and a matching monitor session ID are valid as long as the FTD is routed; the stated transparent mode is the actual blocker.