* tc - mirred ingress not supported at the moment [not found] <CAAT+qEa6Yw-tf3L_R-phzSvLiGOdW9uLhFGNTz+i9eWhBT_+DA@mail.gmail.com> @ 2019-08-13 10:51 ` Martin Olsson 2019-08-13 16:47 ` Cong Wang 0 siblings, 1 reply; 5+ messages in thread From: Martin Olsson @ 2019-08-13 10:51 UTC (permalink / raw) To: netdev Two questions regarding tc-mirred: 1) The manual ( https://www.linux.org/docs/man8/tc-mirred.html ) states: OPTIONS ingress egress Specify the direction in which the packet shall appear on the destination interface. Currently only egress is implemented. I verify to see if this is still true, and unfortunately it is: # tc filter add dev eno2 parent ffff: prio 999 protocol all matchall action mirred ingress redirect dev mon0 mirred ingress not supported at the moment bad action parsing parse_action: bad value (5:mirred)! Illegal "action" Q1: Why was 'ingress' not implemented at the same time as 'egress'? 2) Ok, so I have to use 'egress': # tc filter add dev eno2 parent ffff: prio 999 protocol all matchall action mirred egress redirect dev mon0 Since the mirred action forces me to use 'egress' as the direction on the dest interface, all kinds of network statistics tools show incorrect counters. :-( eno2 is a pure sniffer interface (it is connected to the SPAN dest port of a switch). All packets (matchall) on eno2 are mirrored to mon0. # ip -s link show dev eno2 ... ... RX: bytes packets errors dropped overrun mcast 13660757 16329 0 0 0 0 TX: bytes packets errors dropped carrier collsns 0 0 0 0 0 0 # ip -s link show dev mon0 ... ... RX: bytes packets errors dropped overrun mcast 0 0 0 0 0 0 TX: bytes packets errors dropped carrier collsns 13660757 16329 0 0 0 0 eno2 and mon0 should be identical, but they are inverted. When I graph all interfaces of the machine, the traffic graph for 'mon0' is incorrect since it shows 100% egress when the traffic really is ingress. As a human I can re-enterpret the mon0 graph when looking at it, but it is harder for automated tools to do the right thing without explicit node configuration/exceptions in the tool. This is annoying when you have tools that graph hundreds of different types of nodes with different kinds of interface types, and want all graphs to be visually simillar for easy comparison. Tool output that mon0 has sent 16329 packets is also plain wrong. It has really *received* these packets. Q2: So... Can the 'ingress' option please be implemented? (I'm no programmer, so unfortunetly I can't do it myself). /Martin ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: tc - mirred ingress not supported at the moment 2019-08-13 10:51 ` tc - mirred ingress not supported at the moment Martin Olsson @ 2019-08-13 16:47 ` Cong Wang [not found] ` <CAAT+qEYG5=5ny+t0VcqiYjDUQLrcj9sBR=2w-fdsE7Jjf4xOkQ@mail.gmail.com> 0 siblings, 1 reply; 5+ messages in thread From: Cong Wang @ 2019-08-13 16:47 UTC (permalink / raw) To: Martin Olsson; +Cc: netdev On Tue, Aug 13, 2019 at 4:05 AM Martin Olsson <martin.olsson+netdev@sentorsecurity.com> wrote: > Q1: Why was 'ingress' not implemented at the same time as 'egress'? Because you are using an old iproute2. ingress support is added by: https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/commit/?id=5eca0a3701223619a513c7209f7d9335ca1b4cfa > 2) > Ok, so I have to use 'egress': > # tc filter add dev eno2 parent ffff: prio 999 protocol all matchall > action mirred egress redirect dev mon0 So you redirect packets from eno2's ingress to mon0's egress. > > Since the mirred action forces me to use 'egress' as the direction on > the dest interface, all kinds of network statistics tools show > incorrect counters. :-( > eno2 is a pure sniffer interface (it is connected to the SPAN dest > port of a switch). > All packets (matchall) on eno2 are mirrored to mon0. > > # ip -s link show dev eno2 > ... > ... > RX: bytes packets errors dropped overrun mcast > 13660757 16329 0 0 0 0 > TX: bytes packets errors dropped carrier collsns > 0 0 0 0 0 0 > # ip -s link show dev mon0 > ... > ... > RX: bytes packets errors dropped overrun mcast > 0 0 0 0 0 0 > TX: bytes packets errors dropped carrier collsns > 13660757 16329 0 0 0 0 > > eno2 and mon0 should be identical, but they are inverted. Yes, this behavior is correct. The keyword "egress" in your cmdline already says so. > > Q2: So... Can the 'ingress' option please be implemented? (I'm no > programmer, so unfortunetly I can't do it myself). It is completed, you need to update your iproute2 and kernel. Thanks. ^ permalink raw reply [flat|nested] 5+ messages in thread
[parent not found: <CAAT+qEYG5=5ny+t0VcqiYjDUQLrcj9sBR=2w-fdsE7Jjf4xOkQ@mail.gmail.com>]
* tc - mirred ingress not supported at the moment [not found] ` <CAAT+qEYG5=5ny+t0VcqiYjDUQLrcj9sBR=2w-fdsE7Jjf4xOkQ@mail.gmail.com> @ 2019-08-14 9:25 ` Martin Olsson 2019-08-14 16:14 ` Stephen Hemminger 2019-08-14 20:51 ` Cong Wang 1 sibling, 1 reply; 5+ messages in thread From: Martin Olsson @ 2019-08-14 9:25 UTC (permalink / raw) To: Cong Wang; +Cc: netdev Hi Cong! Ah sorry. Already implemented. Great! Hmmm. Then why don't the manual at https://www.linux.org/docs/man8/tc-mirred.html to reflect the changes? That was the place I checked to see if ingress was still not implemented. In the commit you point at, the sentence "Currently only egress is implemented" has been removed. Question: Is there any form of performance penalty if I send the mirrored traffic to the ingress queue of the destination interface rather than to the egress queue? I mean, in the kernel there is the possibility to perform far more actions on the ingress queue than on the egress, but if I leave both queues at their defaults, will mirrored packets to ingress use more CPU cycles than to the egress destination, or are they more or less identical? Question 2: Given the commit https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/commit/?id=5eca0a3701223619a513c7209f7d9335ca1b4cfa, how can I see in what kernel version it was added? /Martin Den tis 13 aug. 2019 kl 18:47 skrev Cong Wang <xiyou.wangcong@gmail.com>: > > On Tue, Aug 13, 2019 at 4:05 AM Martin Olsson > <martin.olsson+netdev@sentorsecurity.com> wrote: > > Q1: Why was 'ingress' not implemented at the same time as 'egress'? > > Because you are using an old iproute2. > > ingress support is added by: > https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/commit/?id=5eca0a3701223619a513c7209f7d9335ca1b4cfa > > > > 2) > > Ok, so I have to use 'egress': > > # tc filter add dev eno2 parent ffff: prio 999 protocol all matchall > > action mirred egress redirect dev mon0 > > > So you redirect packets from eno2's ingress to mon0's egress. > > > > > > Since the mirred action forces me to use 'egress' as the direction on > > the dest interface, all kinds of network statistics tools show > > incorrect counters. :-( > > eno2 is a pure sniffer interface (it is connected to the SPAN dest > > port of a switch). > > All packets (matchall) on eno2 are mirrored to mon0. > > > > # ip -s link show dev eno2 > > ... > > ... > > RX: bytes packets errors dropped overrun mcast > > 13660757 16329 0 0 0 0 > > TX: bytes packets errors dropped carrier collsns > > 0 0 0 0 0 0 > > # ip -s link show dev mon0 > > ... > > ... > > RX: bytes packets errors dropped overrun mcast > > 0 0 0 0 0 0 > > TX: bytes packets errors dropped carrier collsns > > 13660757 16329 0 0 0 0 > > > > eno2 and mon0 should be identical, but they are inverted. > > Yes, this behavior is correct. The keyword "egress" in your cmdline > already says so. > > > > > Q2: So... Can the 'ingress' option please be implemented? (I'm no > > programmer, so unfortunetly I can't do it myself). > > It is completed, you need to update your iproute2 and kernel. > > Thanks. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: tc - mirred ingress not supported at the moment 2019-08-14 9:25 ` Martin Olsson @ 2019-08-14 16:14 ` Stephen Hemminger 0 siblings, 0 replies; 5+ messages in thread From: Stephen Hemminger @ 2019-08-14 16:14 UTC (permalink / raw) To: Martin Olsson; +Cc: Cong Wang, netdev On Wed, 14 Aug 2019 11:25:25 +0200 Martin Olsson <martin.olsson+netdev@sentorsecurity.com> wrote: > Hi Cong! > > Ah sorry. > Already implemented. Great! > > Hmmm. Then why don't the manual at > https://www.linux.org/docs/man8/tc-mirred.html to reflect the changes? > That was the place I checked to see if ingress was still not implemented. > In the commit you point at, the sentence "Currently only egress is > implemented" has been removed. The man pages on linux.org are not controlled by kernel/iproute developers. Not sure who builds/owns these and don't care. > Question: > Is there any form of performance penalty if I send the mirrored > traffic to the ingress queue of the destination interface rather than > to the egress queue? > I mean, in the kernel there is the possibility to perform far more > actions on the ingress queue than on the egress, but if I leave both > queues at their defaults, will mirrored packets to ingress use more > CPU cycles than to the egress destination, or are they more or less > identical? > > > Question 2: > Given the commit > https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/commit/?id=5eca0a3701223619a513c7209f7d9335ca1b4cfa, > how can I see in what kernel version it was added? Look at the tags $ git tag --contains 5eca0a3701223619a513c7209f7d9335ca1b4cfa v4.10.0 v4.11.0 v4.12.0 v4.13.0 v4.14.0 v4.14.1 v4.15.0 v4.16.0 v4.17.0 v4.18.0 v4.19.0 v4.20.0 v5.0.0 v5.1.0 v5.2.0 https://stackoverflow.com/questions/27886537/how-to-find-out-which-releases-contain-a-given-git-commit ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: tc - mirred ingress not supported at the moment [not found] ` <CAAT+qEYG5=5ny+t0VcqiYjDUQLrcj9sBR=2w-fdsE7Jjf4xOkQ@mail.gmail.com> 2019-08-14 9:25 ` Martin Olsson @ 2019-08-14 20:51 ` Cong Wang 1 sibling, 0 replies; 5+ messages in thread From: Cong Wang @ 2019-08-14 20:51 UTC (permalink / raw) To: Martin Olsson; +Cc: netdev On Wed, Aug 14, 2019 at 2:02 AM Martin Olsson <martin.olsson+netdev@sentorsecurity.com> wrote: > > Hi Cong! > > Ah sorry. > Already implemented. Great! > > Hmmm. Then why don't the manual at https://www.linux.org/docs/man8/tc-mirred.html to reflect the changes? > That was the place I checked to see if ingress was still not implemented. > In the commit you point at, the sentence "Currently only egress is implemented" has been removed. This means that website is out-of-date, not sync'ed with latest man pages. > > > Question: > Is there any form of performance penalty if I send the mirrored traffic to the ingress queue of the destination interface rather than to the egress queue? > I mean, in the kernel there is the possibility to perform far more actions on the ingress queue than on the egress, but if I leave both queues at their defaults, will mirrored packets to ingress use more CPU cycles than to the egress destination, or are they more or less identical? > Hard to say without measurement. There is no queue on ingress side, by the way, so it could be faster than egress, regarding to lock contentions on queues. > > Question 2: > Given the commit https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/commit/?id=5eca0a3701223619a513c7209f7d9335ca1b4cfa, how can I see in what kernel version it was added? > The kernel commit is: commit 53592b3640019f2834701093e38272fdfd367ad8 Author: Shmulik Ladkani <shmulik.ladkani@gmail.com> Date: Thu Oct 13 09:06:44 2016 +0300 net/sched: act_mirred: Implement ingress actions which is merged in 4.10. Thanks. ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2019-08-14 20:51 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <CAAT+qEa6Yw-tf3L_R-phzSvLiGOdW9uLhFGNTz+i9eWhBT_+DA@mail.gmail.com> 2019-08-13 10:51 ` tc - mirred ingress not supported at the moment Martin Olsson 2019-08-13 16:47 ` Cong Wang [not found] ` <CAAT+qEYG5=5ny+t0VcqiYjDUQLrcj9sBR=2w-fdsE7Jjf4xOkQ@mail.gmail.com> 2019-08-14 9:25 ` Martin Olsson 2019-08-14 16:14 ` Stephen Hemminger 2019-08-14 20:51 ` Cong Wang
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).