Re: Port mirroring (RFC)

On 12/14/21 6:47 AM, Alex Elder wrote:

I am implementing what amounts to port mirroring functionality
for the IPA driver.

The IPA hardware isn't exactly a network switch (it's sort of
more than that), but it has the ability to supply replicas of
packets transferred within it to a special (read only) interface.

My plan is to implement this using a new "ipa_mirror" network
device, so it could be used with a raw socket to capture the
arriving packets.  There currently exists one other netdev,
which represents access through a modem to a WWAN network.

I would like some advice on how to proceed with this.  I want
the result to match "best practice" upstream, and would like
this to be as well integrated possible with existing network
tools.

A few details about the stream of packets that arrive on
this hardware interface:
- Packet data is truncated if it's larger than a certain size
- Each packet is preceded by a fixed-size header describing it
- Packets (and their headers) are aggregated into a buffer; i.e.
  a single receive might carry a dozen (truncated) packets

Andrew has already responded, but there are currently sort of two ways
that mirroring is implemented in upstream supported drivers:

- for "classic" Ethernet switches mirroring is typically from one port,
or a set of ports, to another with a choice in whether you want to
capture ingress, egress, or both towards that port. Because each port is
a netdev already you just run tcpdump/pcap the way you normally do on
your Ethernet NIC and get the captured packets. Configuration is via
offloading the tc_mired action.

- mlxsw implements devlink traps which is not exaclty designed for
capturing mirrored packets but more like management events such as why
the packet was trapped etc. You could however imagine using devlink
traps for that purpose of capturing mirrored packets in the absence of a
suitable network device

Not sure if this helps, but that is the situation.

Here are a few specific questions, but I would love to get
*any* feedback about what I'm doing.
- Is representing this as a separate netdev a reasonable
  thing to do?

I would think so, given this allows standard tools to work.

- Is there anything wrong with making a netdev read-only?
  (Any packets supplied for transmit would be dropped)

This looks reasonable.

- Are there things I should do so it's clear this interface
  does not carry IP traffic (or even UDP, etc.)?

There were various patches in the past to prevent a network device from
getting any IP stack to be configured:

https://yhbt.net/lore/all/20150825232021.GA8482@Alexeis-MacBook-Pro-2.local/t/

I forgot whether as a driver you can just refuse to have an IP address
assigned to your network device, AFAIR it requires changes to the
network stack as proposed in the patch set.

- Should the driver de-aggregate the received packets, i.e.
  separating each into a separate SKB for reading?

If this is truly a mirroring device, you would expect it to "render" the
mirrored packets exactly the way they are, maybe add an ethtool private
option to de-aggregate packets if this helps debugging?

I might have *many* more questions, but I'd just like to make
sure I'm on the right track, and would like both specific and
general suggestions about how to do this the right way.

Thanks.
                    -Alex

-- 
Florian