What requirements must general firewall/routing software meet, to make OSI 2 port mirroring work correctly?

Question

The basics are obvious, but there are technical points of networking implication which I don't understand.

Some of these are general to networking, others general to all routing/firewall softwares or to a specific implementation. If specific implementation is relevant then I'm thinking of general purpose rather than specialised networking devices - I use OpenBSD/FreeBSD's pf here so that would be most helpful to illustrate any firewall-specific handling. (i.e., not asking about specialised networking firmware such as Cisco/Juniper). I imagine that pf's dup-to, span or bridge directives would be good exemplars, but at a pinch 'tcpdump` might also be relevant.

I'm assuming the broadest case, where all packets on a port are mirrored to another port (OSI 2 and by implication also OSI 3, without any selective filters).

1. Does a mirror port in effect imply an implicit "block all inbound" rule, so that it can be listened to externally but no other interaction or change to the original traffic flow can occur, if packets are sent on the mirror port?
2. If it does create the equivalent of a "block all inbound" rule, is a no-state rule parameter necessary and/or sufficient to ensure packets will mirror correctly even though replies (SYN-ACK etc) will be blocked on the mirror port? If not, what then?
3. The act of mirroring probably needs consideration of either promiscuous mode (using tcpdump), or a span port, dup-to directive or bridge interface (using pf), to mirror all (not just directed) traffic to another port. Are these 4 approaches equivalent or equally suited for a mirrored port?
4. The mirror needs to treat as data, copies of packets such as ARP, RSTP and BGP on the source interface, which are normally automatically treated as actionable input (unless blocked inbound), when an appropriate service is configured to recognise them. Does this break the layering/packet processing model as it seemingly needs the fîrewall implementation to actively breach the usual data/instruction norm and forward such packets as data on the "mirror" stream while also actioning them as instructions on the "real" stream?
5. Forwarding packets usually involves automatic generation of additional packets such as ARP who-has, possible routing protocols, and the MAC field automatically being generated/updated on the packet, all of which are clearly undesirable for mirrored port traffic. Clearly this is implementation-specific. Is this an issue when creating a mirrored port on a general OS, since these and other automated routing methods on an interface have to be suppressed while still forwarding a packet? (Put another way, the copy must always exit the mirror port without any header modification, and without additional internally-originated packets being auto-added on the stream, but technically do general purpose fw sw allow this on a port by port basis?)

(Hoping this is appropriate for this site, if not can it be moved to the most appropriate site for a technical network-engineering based answer?)

Answer 1

Port mirroring is generally not a router/firewall (OSI Layer-3) function, it is a bridge/switch (OSI Layer-2) function, where all the layer-2 frames for an interface, group of interfaces, or VLAN are also sent to a designated bridge/switch mirror interface. The host on the bridge/switch mirror interface receiving the frames must have its interface configured to allow all frames (promiscuous, monitor mode, etc.), regardless of the layer-2 destination address (regularly configured NICs will drop frames not addressed to them). The host will typically not be able to use its interface for normal network communication, so it usually also has a different, regular interface connected to the network.

The bridge/switch interface to which the frames are mirrored is still a normal bridge/switch interface, and it can easily be oversubscribed by sending more traffic to it than it can handle. For example, on a 48-port switch with 1 Gbps interfaces, there could easily be 10 Gbps of traffic, and sending all the frames to a mirror 1 Gbps interface will cause you to lose 90% of the frames you want to capture. This can be exacerbated by capturing the frames from multiple switches to a VLAN for mirroring.

The target host receiving the frames must run software that ignores all the headers, and it copies everything to whatever process is uses for analysis.