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
