Re: Port mirroring (RFC)

On 12/15/21 2:12 PM, Florian Fainelli wrote:

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

quoted

On 12/15/21 3:18 AM, Andrew Lunn wrote:

quoted

quoted

IPA is a device that sits between the main CPU and a modem,
carrying WWAN network data between them.

In addition, there is a small number of other entities that
could be reachable through the IPA hardware, such as a WiFi
device providing access to a WLAN.

Packets can travel "within IPA" between any of these
"connected entities."  So far only the path between the
AP and the modem is supported upstream, but I'm working
on enabling more capability.

Technically, the replicated packets aren't visible on
any one port; the only way to see that traffic is in
using this special port.  To me this seemed like port
mirroring, which is why I suggested that.  I'm want to
use the proper model though, so I appreciate your
response.

Do you have netdevs for the modem, the wifi, and whatever other
interfaces the hardware might have?

Not yet, but yes I expect that's how it will work.

quoted

To setup a mirror you would do something like:

sudo tc filter add dev eth0 parent ffff: protocol all u32 match u32 0
0 action mirred egress mirror dev tun0

OK so it sounds like the term "mirror" means mirroring using
Linux filtering.  And then I suppose "monitoring" is collecting
all "observed" traffic through an interface?

It is mirroring in terms of an action to perform for a given packet
having been matched, now Ethernet switches for instance support
mirroring in hardware and that specific action can be offloaded down to
your hardware. You can take a look at net/dsa/* and drivers/net/dsa/ for
an example of how this is done.

I've looked a bit at Documentation/networking/dsa/*, not at the
code.  You're right though, this is more like the Ethernet switch
port mirroring.

quoted

If that's the case, this seems to me more like monitoring, except
I suggested presenting the replicated data through a separate
netdev (rather than, for example, through the one for the modem).

If it makes more sense, I could probably inject the replicated
packets received through this special interface into one or
another of the existing netdevs, rather than using a separate
one for this purpose.

quoted

where you are mirroring eth0 to tun0. eth0 would have to be your modem
netdev, or your wifi netdev, and tun0 would be your monitor device.

If you do have a netdev on the host for each of these network
interfaces, mirroring could work. Architecturally, it would make sense
to have these netdevs, so you can run wpa_supplicant on the wifi
interface to do authentication, etc.

Do you have control over selecting egress and ingress packets to be
mirrored?

That I'm not sure about.  If it's possible, it would be controlling
which originators have their traffic replicated.

And the originators would be represented as network devices, or would
they be another kind of object in the Linux kernel? If they are network
devices then you can use the example from Andrew above because you
basically define the source device to mirror. Else, you may have to
invent your own thing.

That's a good question, and it's one I still don't have an answer
for.  I'm actually having a parallel discussion internally about
how best to represent some of this stuff.

I don't really want to invent my own thing, but it would be no
surprise if some things needed enhancement to allow IPA to "fit"
naturally.

All that is next year's work though.  For now I'm just trying to
gather input so I can have a reasonable picture of the design in
mind as I start implementing.

					-Alex

quoted

I don't think it will take me all that long to implement this, but
my goal right now is to be sure that the design I implement is a good
solution.  I'm open to recommendations.

Thanks.

                     -Alex

quoted

     Andrew