All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Anders K. Pedersen | Cohaesio" <akp@cohaesio.com>
To: "pablo@netfilter.org" <pablo@netfilter.org>
Cc: "fw@strlen.de" <fw@strlen.de>,
	"netfilter-devel@vger.kernel.org"
	<netfilter-devel@vger.kernel.org>
Subject: Re: [PATCH nf-next] netfilter: nf_meta: support for nexthop and nexthop6
Date: Wed, 21 Sep 2016 05:07:22 +0000	[thread overview]
Message-ID: <1474434441.1021.42.camel@cohaesio.com> (raw)
In-Reply-To: <20160920152816.GA18239@salvia>

Hi Pablo,

On tir, 2016-09-20 at 17:28 +0200, Pablo Neira Ayuso wrote:
> Hi Anders,
> 
> On Wed, Sep 14, 2016 at 05:47:08AM +0000, Anders K. Pedersen |
> Cohaesio wrote:
> > Add meta support for IPv4 nexthop and IPv6 nexthop6 (i.e. the
> > directly
> > connected IP address that an outgoing packet is sent to), which can
> > be used
> > either for matching or accounting, eg.

> Florian is working on explicitly fib lookup expression, 

I had noticed his RFC before doing this, but thought that it wouldn't
be ideal for my use case, since 1) it might not give the route that is
actually used in case of ECMP, and 2) it would be less efficient to
perform an additional route lookup in stead of just reusing the one
that has to be performed anyway for routing the packet - especially on
a router with a full BGP feed (currently close to 600.000 routes).

> for the
> existing route attached to the skbuff, I think we can add
> nft_rt_ipv4.c, nft_rt_ipv6.c and nft_rt_inet.c expressions instead
> for
> this? One per family, have a look at nft_meta_bridge.c for reference,
> it should look similar.
> 
> I think many other rt fields could be useful with a valid usecase.
> 
> BTW, proposed syntax is:
> 
> # nft add rule filter postrouting \
> 	flow table acct { rt ip nexthop timeout 600s counter }
> 
> # nft add rule ip6 filter postrouting \
> 	flow table acct { rt ip6 nexthop timeout 600s counter }
> 
> Then, for the inet family:
> 
> # nft add rule inet filter postrouting \
> 	ether type ip flow table acct { rt ip nexthop timeout 600s
> counter }
> 
> This one should bail out if:
> 
> # nft add rule inet filter postrouting \
> 	ether type ip flow table acct { rt ip6 nexthop timeout 600s
> counter }
>                    ~~                      ^^^
> 
> they don't match, this is just a bit of code at
> nftables/src/evaluate.c
> 
> Thus, we pass an explicit NFTA_RT_FAMILY attribute to explicitly
> indicate the family type so we can use this from the inet table too.
> 
> You need to add a expr/rt.c expression to libnftnl, it is boiler
> plate
> code you can use meta expression as reference.
> 
> From nft, you have to add a new EXPR_RT, there will be code missing
> in
> evaluate.c, netlink_linearize.c and netlink_delinearize.c

...

> With the approach above, we will not need to check for pkt->pf !=
> NFPROTO_IPV4, given this will be checked from the _init() path of the
> expression.
> 
> It will be a bit more code though.
> 
> Would you have a look at this? Let me know, thanks!

I had an initial look at this and found that it would involve
modifying/creating the following files:

nf-next:
include/net/netfilter/nft_rt.h - new file based on nft_meta.h
include/uapi/linux/netfilter/nf_tables.h
 - new NFT_RT_* and NFTA_RT_* - based on what exists for nft_meta
net/netfilter/{Kconfig,Makefile} - new config NFT_RT and NFT_RT_INET
net/netfilter/nft_rt.c - new file based on nft_meta.c
net/netfilter/nft_rt_inet.c - new file based on nft_meta_bridge.c
net/ipv4/netfilter/{Kconfig,Makefile} - new config NFT_RT_IPV4
net/ipv4/netfilter/nft_rt_ipv4.c - new file based on nft_meta_bridge.c
net/ipv6/netfilter/{Kconfig,Makefile} - new config NFT_RT_IPV6
net/ipv6/netfilter/nft_rt_ipv6.c - new file based on nft_meta_bridge.c

libnftnl:
include/linux/netfilter/nf_tables.h - same as kernel changes
include/libnftnl/expr.h - add new NFTNL_EXPR_RT_* and NFT_EXPR_RT_*
src/expr/rt.c - new file based on meta.c
src/expr_ops.c - add references to expr_ops_rt
src/Makefile.am - add expr/rt.c

nftables:
doc/nft.xml - document new rt expression
include/linux/netfilter/nf_tables.h - same as kernel changes
include/expression.h - add new EXPR_RT
include/rt.h - new file based on meta.h
include/statement.h - add new STMT_RT and rt_stmt
src/evaluate.c - add handling of EXPR_RT and STMT_RT
src/netlink_linearize.c - add handling of EXPR_RT and STMT_RT
src/netlink_delinearize.c - add handling of EXPR_RT and STMT_RT
src/rt.c - new file based on meta.c
src/Makefile.am - add rt.c to nft_SOURCES
src/parser_bison.y - define new keywords and syntax
src/scanner.l - define new keywords

Does this seem right, or have I missed something?

It looks like quite a bit more code than my first attempt, but I can
give it a try. I don't know how much time I'll have for this, so it
will probably take some weeks to do.

Regards,
Anders K. Pedersen

  reply	other threads:[~2016-09-21  5:07 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-14  5:47 [PATCH nf-next] netfilter: nf_meta: support for nexthop and nexthop6 Anders K. Pedersen | Cohaesio
2016-09-20 15:28 ` Pablo Neira Ayuso
2016-09-21  5:07   ` Anders K. Pedersen | Cohaesio [this message]
2016-09-22  9:39     ` Pablo Neira Ayuso

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1474434441.1021.42.camel@cohaesio.com \
    --to=akp@cohaesio.com \
    --cc=fw@strlen.de \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=pablo@netfilter.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.