An airport places its packet analyzer on a different IP subnet across the routed core and needs mirrored frames delivered to that analyzer. Which technology is intended for that Layer-3 path?
Select an answer to reveal the explanation.
Short Explanation
When your analyzer sits across a routed core, plain RSPAN VLAN tricks run out of road. ERSPAN wraps mirrored traffic in an IP-friendly envelope so it can reach your analyzer over Layer 3.
Full Explanation
The airport’s analyzer is on a different IP subnet across a routed core, so the mirrored frames need a Layer-3 delivery path. ERSPAN is intended for this design: it encapsulates mirrored traffic so copies can travel over an IP network to a remote analyzer, without relying on a continuous Layer-2 VLAN. This suits a routed campus or airport core when the analyzer is not Layer-2-adjacent to the sources. Local SPAN with the destination port in another VRF does not solve the problem: local SPAN expects its source and destination on the same switch, and VRF placement alone does not create a routed mirror-delivery path. An RSPAN VLAN flooded through every access closet without GRE still depends on an end-to-end Layer-2 RSPAN VLAN; flooding it widely is operationally harmful and does not carry it across Layer-3 boundaries. Syslog local7 can export packet summaries to a remote collector, but syslog messages are not mirrored Ethernet frames for packet analysis. Exam caveat: use ERSPAN when the analyzer is reachable only over IP, RSPAN for a remote Layer-2 path, and local SPAN for a same-switch destination. At the airport, configure ERSPAN for the relevant source ports or VLANs, set the analyzer’s IP as the destination, and verify delivery and analyzer receipt across the routed core. Check for encapsulation overhead and ACL or firewall filters that could drop ERSPAN traffic.