On Thu, Sep 22, 2016 at 10:11 PM, Shmulik Ladkani <shmulik.ladk...@gmail.com> wrote: > Was wondering why it's missing, googled a bit with no meaningful > results, so speculated the following: > > Some time long ago, initial 'mirred' purpose was to facilitate ifb. > Therefore 'egress redirect' was implemented. Jamal probably left the > 'ingress' support for a later time :) > > One interesting usecase for 'ingress redirect' is creating "rx bouncing" > construct (like macvlan/macvtap/ipvlan) but applied according to custom > logic.
We have done this for our containers for a long time. We simply redirect packets to veth TX then flow to veth RX of course. One problem to use your code for us is that, the RX side of veth is inside containers, not visible to outside, perhaps we need some more parameter to tell the netns before the device name/index? Thoughts? > >> It may be around preventing loops maybe. > > Could be, but personally, I treat these constructs as (powerful) > building blocks, and "with great power comes great responsibility". > > Even today, one may create loops using existing 'egress redirect', > e.g. this rediculously errorneous construct: > > # ip l add v0 type veth peer name v0p > # tc filter add dev v0p parent ffff: basic \ > action mirred egress redirect dev v0 Detecting such loops should not be hard technically, like we do for reclassification. We might need some bits in skb to detect this specific case. Anyway, I don't think it is a blocker, just need more tests to catch some corner cases. Thanks.
