Message-ID: <7cf5a995-8e59-93cd-ccab-243a4c24cedc@gmail.com>
Date:   Wed, 15 Dec 2021 09:48:03 -0800
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Alex Elder <elder@...aro.org>,
        Network Development <netdev@...r.kernel.org>
Cc:     "bjorn.andersson@...aro.org" <bjorn.andersson@...aro.org>
Subject: 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

Powered by blists - more mailing lists