Creating span interface using 'dup-to' option

Miłosz Kaniewski milosz.kaniewski at gmail.com
Thu Nov 26 21:11:02 UTC 2015


2015-11-22 20:14 GMT+01:00 Kristof Provost <kp at freebsd.org>:

> On 2015-11-15 18:33:49 (+0100), Kristof Provost <kp at FreeBSD.org> wrote:
> > On the other hand, perhaps there's something we can do about the state
> > matching. The problems all start because we match state on the
> > duplicated packet. That's not correct, because the rule is set on e.g.
> > em0, but the duplicated packet is sent out on em1.
> > In fact, from a first reading of the code I don't actually understand
> > why we're getting that state match.
> >
> I've looked at the state matching for a bit. It turns out that by
> default packets will match state on any interface (specifically, the
> state is saved to the 'all' interface, rather than to the specific
> interface it was created on).
> That default can be changed with 'set state-policy if-bound'. I'd expect
> adding that would work around the problem you see.
>

Thanks, it did the trick :) I made couple of tests and my dup-to options
started
to duplicate packets in a right way when I set 'if-bound' policy.
I didn't know that it is possible to control packets states policy. At
beginning
I was surprised that default behaviour is to make states floating between
interfaces. But now I think that it can have sense. For example in my case
I use
pf to forward hundreds of thousands of connections. If I would use floating
state policy then I would have as many states as connections. But if I
switch
to 'if-bound' policy then I would get two times more states than connections
(one state for original interface and one for interface where packets are
duplicated with dup-to).
So i think that this workaround is very useful and in many cases it would be
sufficient. But there are some scenarios, like mine, where floating states
could provide big profits and it would be really nice if We could use them.

Thank you very much for your help with my problem.

Best regards,
Miłosz


More information about the freebsd-pf mailing list