From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Florian Westphal <fw@strlen.de>
Cc: netfilter-devel@vger.kernel.org
Subject: Re: [PATCH nft] doc: extend description of fib expression
Date: Sat, 12 Oct 2024 18:35:58 +0200 [thread overview]
Message-ID: <ZwqlbhdH4Fw__daA@calendula> (raw)
In-Reply-To: <20241010133745.28765-1-fw@strlen.de>
Hi Florian,
Thanks, this is an improvement, a few comments.
On Thu, Oct 10, 2024 at 03:37:42PM +0200, Florian Westphal wrote:
> +The last argument to the *fib* expression is the desired result type.
> +
> +*oif* asks to obtain the interface index that would be used to send packets to the packets source
> +(*saddr* key) or destination (*daddr* key). If no routing entry is found, the returned interface
> +index is 0.
> +
> +*oifname* is like *oif*, but it fills the interface name instead. This is useful to check dynamic
> +interfaces such as ppp devices. If no entry is found, an empty interface name is returned.
> +
> +*type* returns the address type such as unicast or multicast.
> +
> +.FIB_TUPLE keywords
> [options="header"]
> |==================
> -|Keyword| Description| Type
> +|flag| Description
> +|daddr| Perform a normal route lookup: search fib for route to the *destination address* of the packet.
> +|saddr| Perform a reverse route lookup: search the fib for route to the *source address* of the packet.
> +|mark | consider the packet mark (nfmark) when querying the fib.
> +|iif | fail fib lookup unless route exists and its output interface is identical to the packets input interface
maybe easier to understand?
if fib lookups provides a route then check its output interface is identical to the packets *input* interface.
> +|oif | fail fib lookup unless route exists and its output interface is identical to the packets output interface.
if fib lookups provides a route then check its output interface is identical to the packets *output* interface.
> This flag can only be used with the *type* result.
Are you sure 'oif' can only be used with type? I can see NFTA_FIB_F_OIF is available in nft_fib4_eval()
if (priv->flags & NFTA_FIB_F_OIF)
oif = nft_out(pkt);
else if (priv->flags & NFTA_FIB_F_IIF)
oif = nft_in(pkt);
else
oif = NULL;
One more comment below.
> +|=======================
> +
> +.FIB_RESULT keywords
> +[options="header"]
> +|==================
> +|Keyword| Description| Result Type
> |oif|
> Output interface index|
> integer (32 bit)
> @@ -334,20 +365,40 @@ fib_addrtype
>
> Use *nft* *describe* *fib_addrtype* to get a list of all address types.
>
> +The *oif* and *oifname* result is only valid in the *prerouting*, *input* and *forward* hooks.
> +The *type* can be queried from any one of *prerouting*, *input*, *forward* *output* and *postrouting*.
> +
> +For *type*, the presence of the *iif* keyword in the 'FIB_TUPLE' modifiers restrict the available
> +hooks to those where the packet is associated with an incoming interface, i.e. *prerouting*, *input* and *forward*.
> +Likewise, the *oif* keyword in the 'FIB_TUPLE' modifier list will limit the available hooks to
> +*forward*, *output* and *postrouting*.
> +
> .Using fib expressions
> ----------------------
> # drop packets without a reverse path
> filter prerouting fib saddr . iif oif missing drop
>
> -In this example, 'saddr . iif' looks up routing information based on the source address and the input interface.
> -oif picks the output interface index from the routing information.
> +In this example, 'saddr . iif' looks up a route to the *source address* of the packet and restricts matching
> +results to the interface that the packet arrived on, then stores the output interface index from the obtained
> +fib route result.
>
> If no route was found for the source address/input interface combination, the output interface index is zero.
> -In case the input interface is specified as part of the input key, the output interface index is always the same as the input interface index or zero.
> -If only 'saddr oif' is given, then oif can be any interface index or zero.
> +Hence, this rule will drop all packets that do not have a strict reverse path (hypothetical reply packet
> +would be sent via the interface the tested packet arrived on).
> +
> +If only 'saddr oif' is used as the input key, then this rule would only drop packets where the fib cannot
> +find a route. In most setups this will never drop packets because the default route is returned.
>
> -# drop packets to address not configured on incoming interface
> +# drop packets if the destination ip address is not configured on the incoming interface
> filter prerouting fib daddr . iif type != { local, broadcast, multicast } drop
I don't see a table in the manpage possible return values of fib type
lookups, I mean:
static const struct symbol_table addrtype_tbl = {
.base = BASE_DECIMAL,
.symbols = {
SYMBOL("unspec", RTN_UNSPEC),
SYMBOL("unicast", RTN_UNICAST),
SYMBOL("local", RTN_LOCAL),
SYMBOL("broadcast", RTN_BROADCAST),
SYMBOL("anycast", RTN_ANYCAST),
SYMBOL("multicast", RTN_MULTICAST),
SYMBOL("blackhole", RTN_BLACKHOLE),
SYMBOL("unreachable", RTN_UNREACHABLE),
SYMBOL("prohibit", RTN_PROHIBIT),
SYMBOL_LIST_END
}
};
Thanks.
next prev parent reply other threads:[~2024-10-12 16:36 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-10 13:37 [PATCH nft] doc: extend description of fib expression Florian Westphal
2024-10-12 16:35 ` Pablo Neira Ayuso [this message]
2024-10-18 12:08 ` Florian Westphal
2024-10-22 11:34 ` Pablo Neira Ayuso
2024-10-24 10:41 ` Florian Westphal
2024-10-28 23:05 ` 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=ZwqlbhdH4Fw__daA@calendula \
--to=pablo@netfilter.org \
--cc=fw@strlen.de \
--cc=netfilter-devel@vger.kernel.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.