netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alex Elder <elder@linaro.org>
To: Florian Fainelli <f.fainelli@gmail.com>, Andrew Lunn <andrew@lunn.ch>
Cc: Network Development <netdev@vger.kernel.org>,
	"bjorn.andersson@linaro.org" <bjorn.andersson@linaro.org>
Subject: Re: Port mirroring (RFC)
Date: Mon, 20 Dec 2021 13:51:13 -0600	[thread overview]
Message-ID: <348666a6-6099-81f5-c6d9-d11ba4dc4a0e@linaro.org> (raw)
In-Reply-To: <cdaf3a32-65d6-6fc0-dafc-cd07cb67fc3e@gmail.com>

On 12/15/21 2:12 PM, Florian Fainelli wrote:
> On 12/15/21 6:47 AM, Alex Elder wrote:
>> On 12/15/21 3:18 AM, Andrew Lunn wrote:
>>>> 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.
>>
>>> 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.

>> 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.
>>
>>> 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

>> 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
>>
>>>      Andrew
>>>
>>
> 
> 


  reply	other threads:[~2021-12-20 19:51 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-14 14:47 Port mirroring (RFC) Alex Elder
2021-12-14 18:27 ` Andrew Lunn
2021-12-14 22:55   ` Alex Elder
2021-12-15  9:18     ` Andrew Lunn
2021-12-15 14:47       ` Alex Elder
2021-12-15 17:42         ` Andrew Lunn
2021-12-20 19:27           ` Alex Elder
2021-12-15 20:12         ` Florian Fainelli
2021-12-20 19:51           ` Alex Elder [this message]
2021-12-15 17:48 ` Florian Fainelli
2021-12-20 19:41   ` Alex Elder
2021-12-15 23:33 ` Jakub Kicinski
2021-12-20 20:17   ` Alex Elder
2022-01-14 16:50 ` Port mirroring, v2 (RFC) Alex Elder
2022-01-14 17:03   ` Alex Elder
2022-01-14 20:46     ` Andrew Lunn
2022-01-14 21:12       ` Alex Elder
2022-01-18 18:07         ` Jakub Kicinski
2022-01-18 18:14           ` Alex Elder
2022-01-15 15:14     ` Andrew Lunn
2022-01-18 17:37       ` Alex Elder
2022-01-18 18:30         ` Jakub Kicinski
2022-01-18 18:33           ` Alex Elder
2022-01-26 23:37             ` IPA monitor (Final RFC) Alex Elder
2022-01-26 23:43               ` Alex Elder
2022-02-02  0:19               ` Andrew Lunn
2022-02-02  0:41                 ` Alex Elder
2022-02-02 19:05                   ` Andrew Lunn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=348666a6-6099-81f5-c6d9-d11ba4dc4a0e@linaro.org \
    --to=elder@linaro.org \
    --cc=andrew@lunn.ch \
    --cc=bjorn.andersson@linaro.org \
    --cc=f.fainelli@gmail.com \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).