netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alex Elder <elder@linaro.org>
To: 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: Wed, 15 Dec 2021 08:47:51 -0600	[thread overview]
Message-ID: <b00fb6e2-c923-39e9-f326-6ec485fcff21@linaro.org> (raw)
In-Reply-To: <YbmzAkE+5v7Mv89D@lunn.ch>

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?

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.

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-15 14:47 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 [this message]
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
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=b00fb6e2-c923-39e9-f326-6ec485fcff21@linaro.org \
    --to=elder@linaro.org \
    --cc=andrew@lunn.ch \
    --cc=bjorn.andersson@linaro.org \
    --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).