On Tue, Feb 02, 2021 at 11:30:12AM +0100, Alexandr Nedvedicky wrote:
> Hello,
>
> </snip>
> On Tue, Feb 02, 2021 at 02:52:52PM +1000, David Gwynne wrote:
> >
> > however, like most things relating to route-to/reply-to/dup-to, im
> > pretty sure at this point it's not used a lot, so the impact is minimal.
> > a lot of changes in this space have already been made, so adding another
> > simplification is justifiable. if this does remove functionality that
> > people need, i believe sashan@ has agreed to help me implement route-to
> > on match rules to give more flexibility and composability of rules.
> >
>
> as David says my concern is single corner case, which combines
> NAT with route-to action. I think the escape plan for people,
> who combine route-to with nat-to, is already there. If someone
> has rule as follows:
>
> pass in on em0 from v.x.y.z/n to a.b.c.d/m \
> route-to o.p.q.r@em2 nat-to(em2)
You can nat-to and route-to on the same rule, so this should still
work if all you do is drop the @em2:
pass in on em0 from v.x.y.z/n to a.b.c.d/m \
route-to o.p.q.r nat-to (em2)
> then this needs to be converted to two rules:
>
> match in on em0 from v.x.y.z/n to a.b.c.d/m nat-to(em2)
> pass in on em0 from v.x.y.z/n to a.b.c.d/m route-to o.p.q.r
>
> I have not tried that yet. However I think this should work. If it does
> not work, then I'll try to fix it.
I thought the problem was for rules like this:
pass out on em1 from v.x.y.z/n to a.b.c.d/m \
route-to o.p.q.r@em2
pass out on em2 nat-to (em2)
Only one pass out rule will win if I commit this, because the packet
will only go through the ruleset when it leaves the stack, not every
time the interface changes. If we can do match route-to rules, we could
do the following:
match out on em1 from v.x.y.z/n to a.b.c.d/m \
route-to o.p.q.r # o.p.q.r is reachable via em2
pass out on em2 nat-to (em2)
> > i've canvassed a few people, and their responses have varied from "i
> > don't care, route-to is the worst" to "i thought we did option 2
> > anyway". anyone else want to chime in?
> >
> > this keeps the behaviour where route-to on a packet coming into the
> > stack is pushed past it and immediately forwarded to the output
> > interface. the condition for that is greatly simplified now though.
> >
> > ok?
>
> given there is an escape plan, I'm fine with the change.
Thank you.
