tc - mirred ingress not supported at the moment

tc - mirred ingress not supported at the moment

[Martin Olsson]

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

Re: tc - mirred ingress not supported at the moment

[Cong Wang]

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.

tc - mirred ingress not supported at the moment

[Martin Olsson]

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.

Re: tc - mirred ingress not supported at the moment

[Stephen Hemminger]

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

Re: tc - mirred ingress not supported at the moment

[Cong Wang]

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.