Re: using flow offload for sip server

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Thanks for the reference.

As I read it, flowtables is useful to efficently _forward_
established packets to another machine, not to input. So it would not
be useful at the asterisk server.

I could use flowtables at the router if I can dnat the SIP packets
that are not established.  Like so ?

        table inet x {
              flowtable f {
                   hook ingress priority 0 devices = { external, internal };
              }
                chain y {
                        type filter hook forward priority 0; policy accept;
                        ip  protocol { udp, tcp } flow offload @f
                        iifname "external" udp dport { iax, 5060-5063
} counter dnat to $asterisk
                        iifname "external" tcp dport 5060-5063 counter
dnat to $asterisk
                        counter
                }
        }

If I'm correct, this will offload all established udp and tcp packets
. Then it will dnat and forward the new SIP signalling packets
{5060-5063}.

Am I getting closer ?

On Mon, May 21, 2018 at 1:36 PM, Laura Garcia <nevola@xxxxxxxxx> wrote:
> On Mon, May 21, 2018 at 7:01 PM, Sean Darcy <seandarcy2@xxxxxxxxx> wrote:
>>
>> The man page says
>>
>> "Flowtables reside in the ingress hook"
>>
>> but the lwn article referenced in the 0.8.4 announcement,
>>
>>        table inet x {
>>                 chain y {
>>                         type filter hook forward priority 0; policy accept;
>>                         ip protocol tcp flow offload counter
>>
>> uses  filter table and the forward hook.
>>
>> So is a SIP a good use case for flowtables ? And if so, how ?
>>
>
> It's quite well explained how flow tables work in the official documentation at:
> https://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf-next.git/tree/Documentation/networking/nf_flowtable.txt
>
> I believe that for the SIP case should work for both TCP and UDP flows
> as the document states:
> "(...) once the flow enters the
> established state according to the conntrack semantics (ie. we have seen traffic
> in both directions), then you can decide to offload the flow to the flowtable
> from the forward chain (...)"
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux