Hello,
</snip>
> >
> > If I understand the idea right, then basically 'match out on em0....'
> > figures out the new 'outbound interface' so either 'pass out on em1...'
> > or
> > 'pass out on em2...' will kick in. In other words:
> >
> > depending on the destination picked up from <hops> table,
> > the route-to action will override the em0 interface to
> > either em1 or em2.
>
> yes.
>
> i dont understand the kif lifetimes though. can we just point a
> pdesc at an arbitrary kif or do we need ot reference count?
>
as long as we don't release NET_LOCK() (or PF_LOCK() in near future),
the reference to kif should remain valid.
kif is very own PF's abstraction of network interfaces. there are
two ways how one can create a kif:
there is either rule loaded, which refers to interface, which
is not plumbed yet.
the new interface gets plumbed and PF must have a kif for it.
the reference count currently used makes sure we destroy kif when
either interface is gone or when the rule, which refers kif is
gone.
hope I remember details above right.
> > I think this might be way to go.
> >
> > My only concern now is that such change is subtle. I mean the
> >
> > pass out ... route-to <hops>
> >
> > will change behavior in sense that current code will dispatch
> > packet to new interface and run pf_test() again. Once your diff
> > will be in the same rule will be accepted, but will bring entirely
> > different behaviour: just dispatch packet to new interface.
>
> yeah.
>
> the counter example is that i was extremely surprised when i
> discovered that pf_test gets run again when the outgoing interface
> is changed with a route-to rule.
surprised because you've forgot about current model? which is:
run pf_test() whenever packet crosses the interface?
>
> there's subtlety either way, we're just figuring out which one we're
> going for.
yes exactly. there are trade offs either way.
</snip>
> > I think this is acceptable. If this will cause a friction we can always
> > adjust the code in follow up commit to allow state-less
> > route-to/reply-to
> > with no support from pfsync(4).
>
> if we're going to support route-to on match rules i think this will be
> easy to implement.
>
I think there must be some broader consent on model change
from current which is run pf_test() for every NIC crossing
to new way, which is run pf_test() at most two times.
> > >
> > > > >
> > > > > lastly, the "argument" or address specified with route-to (and
> > > > > reply-to and dup-to) is a destination address, not a next-hop. this
> > > > > has been discussed on the lists a couple of times before, so i won't
> > > > > go over it again, except to reiterate that it allows pf to force
> > > > > "sticky" path selection while opening up the possibility for ecmp
> > > > > and failover for where that path traverses.
> > > >
> > > > I keep forgetting about it as I still stick to current
> > > > interpretation.
> > > >
> > > >
> > > > I've seen changes to pfctl. Diff below still allows rule:
> > > >
> > > > pass in on net0 from 192.168.1.0/24 to any route-to 10.10.10.10@em0
> > >
> > > Is there use case for the @interface syntax apart from the current
> > > route-to rules? If not, we can just delete it.
> >
> > perhaps I'm still not quite on the same page as you then. I also
> > had no time to entirely test you diff. The way I understand your
> > effort is to change route-to behavior such it will be using
> > a destination instead of next-hop@interface. Or are you planning
> > to keep current form ('route-to next-hop@interface') working?
>
> if we ignore route-to, what's the use case for the interface part of
> address@interface? it doesnt seem to be accepted as part of an address
> in other parts of the grammar:
>
> dlg@kbuild ~$ echo pass in from 192.168.0.0@vmx0 | sudo pfctl -nf -
> stdin:1: @if syntax not permitted in from or to
> stdin:1: skipping rule due to errors
> stdin:1: rule expands to no valid combination
> dlg@kbuild ~$ echo pass from 192.168.0.0@vmx0 | sudo pfctl -nf -
> stdin:1: @if syntax not permitted in from or to
> stdin:1: skipping rule due to errors
> stdin:1: rule expands to no valid combination
> dlg@kbuild ~$ echo pass nat-to 192.168.0.0@vmx0 | sudo pfctl -nf -
> stdin:1: @if not permitted
> stdin:1: nat-to and rdr-to require a direction
> stdin:1: skipping rule due to errors
> stdin:1: rule expands to no valid combination
> dlg@kbuild ~$ echo pass nat-to 192.168.0.0@vmx0 | sudo pfctl -nf -
>
> if route-to isn't going to use it, can we cut the @interface part out of
> fthe address parser?
>
that's also my understanding. the form 192.168.0.0@net0 is currently
used by route-to et.al. only. So we can eventually let it go.
however there is a strong objection from Sven, which wants it to keep
it around.
</snip>
> > unless we don't want to support yet another way of doing block/block
> > return
> > we should fail with error, I think.
>
> ok. i'll update my diff to have pf_route{,6} check these flags tomorrow.
>
thanks. I'll continue reading your diff. I'll also keep thinking of
how to combine all things together to keep Sven and you happy with
those changes.
regards
sashan
