All of lore.kernel.org
 help / color / mirror / Atom feed
* routing table lookup
@ 2016-10-11 18:11 Bjørnar Ness
  2016-10-11 18:28 ` Jan Engelhardt
  0 siblings, 1 reply; 9+ messages in thread
From: Bjørnar Ness @ 2016-10-11 18:11 UTC (permalink / raw)
  To: netfilter-devel

Hello, netfilter-devel.

Is it possible/planned to be able to do routing table lookup from
within nftables?
Thinking then of a routingtable like "set". This would be nice to be able to do
early drop on bgp populated saddr based rtbl.

-- 
Bj(/)rnar

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: routing table lookup
  2016-10-11 18:11 routing table lookup Bjørnar Ness
@ 2016-10-11 18:28 ` Jan Engelhardt
  2016-10-11 19:10   ` Bjørnar Ness
  0 siblings, 1 reply; 9+ messages in thread
From: Jan Engelhardt @ 2016-10-11 18:28 UTC (permalink / raw)
  To: Bjørnar Ness; +Cc: netfilter-devel

On Tuesday 2016-10-11 20:11, Bjørnar Ness wrote:

>Hello, netfilter-devel.
>
>Is it possible/planned to be able to do routing table lookup from
>within nftables?
>Thinking then of a routingtable like "set". This would be nice to be able to do
>early drop on bgp populated saddr based rtbl.

Well you can mark routes with realm numbers, and match on that. (In 
iptables, this was done with -m realm.) At least that is the idea. Not 
sure if the skb field that holds the information is already 
filled in before FORWARD (at which point I guess it will contain the 
dst realm anyway).

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: routing table lookup
  2016-10-11 18:28 ` Jan Engelhardt
@ 2016-10-11 19:10   ` Bjørnar Ness
  2016-10-11 20:18     ` Jan Engelhardt
  0 siblings, 1 reply; 9+ messages in thread
From: Bjørnar Ness @ 2016-10-11 19:10 UTC (permalink / raw)
  To: Jan Engelhardt; +Cc: netfilter-devel

2016-10-11 20:28 GMT+02:00 Jan Engelhardt <jengelh@inai.de>:
> Well you can mark routes with realm numbers, and match on that. (In
> iptables, this was done with -m realm.) At least that is the idea. Not
> sure if the skb field that holds the information is already
> filled in before FORWARD (at which point I guess it will contain the
> dst realm anyway).

I think you misunderstood what I am looking for here, for example:

prerouting:

ip saddr route table 10 drop

-- 
Bj(/)rnar

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: routing table lookup
  2016-10-11 19:10   ` Bjørnar Ness
@ 2016-10-11 20:18     ` Jan Engelhardt
  2016-10-11 22:17       ` Bjørnar Ness
  0 siblings, 1 reply; 9+ messages in thread
From: Jan Engelhardt @ 2016-10-11 20:18 UTC (permalink / raw)
  To: Bjørnar Ness; +Cc: netfilter-devel


On Tuesday 2016-10-11 21:10, Bjørnar Ness wrote:
>2016-10-11 20:28 GMT+02:00 Jan Engelhardt <jengelh@inai.de>:
>> Well you can mark routes with realm numbers, and match on that. (In
>> iptables, this was done with -m realm.) At least that is the idea. Not
>> sure if the skb field that holds the information is already
>> filled in before FORWARD (at which point I guess it will contain the
>> dst realm anyway).
>
>I think you misunderstood what I am looking for here, for example:
>prerouting:
>ip saddr route table 10 drop

Assuming you mean "saddr is in {the set of dst addrs in table 10}"
then it's as I said - basically rpfilter with sort of an extra check
for the realm number (which you can make the same as the table number).

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: routing table lookup
  2016-10-11 20:18     ` Jan Engelhardt
@ 2016-10-11 22:17       ` Bjørnar Ness
  2016-10-12  6:19         ` Michal Kubecek
  0 siblings, 1 reply; 9+ messages in thread
From: Bjørnar Ness @ 2016-10-11 22:17 UTC (permalink / raw)
  To: Jan Engelhardt; +Cc: netfilter-devel

2016-10-11 22:18 GMT+02:00 Jan Engelhardt <jengelh@inai.de>:
>
> On Tuesday 2016-10-11 21:10, Bjørnar Ness wrote:
>>2016-10-11 20:28 GMT+02:00 Jan Engelhardt <jengelh@inai.de>:
>>> Well you can mark routes with realm numbers, and match on that. (In
>>> iptables, this was done with -m realm.) At least that is the idea. Not
>>> sure if the skb field that holds the information is already
>>> filled in before FORWARD (at which point I guess it will contain the
>>> dst realm anyway).
>>
>>I think you misunderstood what I am looking for here, for example:
>>prerouting:
>>ip saddr route table 10 drop
>
> Assuming you mean "saddr is in {the set of dst addrs in table 10}"
> then it's as I said - basically rpfilter with sort of an extra check
> for the realm number (which you can make the same as the table number).

Yeah, sortoff. But afaik rpfilter is a iptables module, and not
available in nftables yet.

Pablo: is the "lookup in routing table from nftables" a total waste of time?

-- 
Bj(/)rnar

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: routing table lookup
  2016-10-11 22:17       ` Bjørnar Ness
@ 2016-10-12  6:19         ` Michal Kubecek
  2016-10-12 15:19           ` Bjørnar Ness
  0 siblings, 1 reply; 9+ messages in thread
From: Michal Kubecek @ 2016-10-12  6:19 UTC (permalink / raw)
  To: Bjørnar Ness; +Cc: Jan Engelhardt, netfilter-devel

On Wed, Oct 12, 2016 at 12:17:24AM +0200, Bjørnar Ness wrote:
> 
> Yeah, sortoff. But afaik rpfilter is a iptables module, and not
> available in nftables yet.
> 
> Pablo: is the "lookup in routing table from nftables" a total waste of time?

You may be interested in

  https://www.youtube.com/watch?v=wfWMPlZHQBk&t=19m40s

Michal Kubecek


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: routing table lookup
  2016-10-12  6:19         ` Michal Kubecek
@ 2016-10-12 15:19           ` Bjørnar Ness
  2016-10-14 11:44             ` Florian Westphal
  0 siblings, 1 reply; 9+ messages in thread
From: Bjørnar Ness @ 2016-10-12 15:19 UTC (permalink / raw)
  To: Michal Kubecek; +Cc: Jan Engelhardt, netfilter-devel

2016-10-12 8:19 GMT+02:00 Michal Kubecek <mkubecek@suse.cz>:
> On Wed, Oct 12, 2016 at 12:17:24AM +0200, Bjørnar Ness wrote:
>>
>> Yeah, sortoff. But afaik rpfilter is a iptables module, and not
>> available in nftables yet.
>>
>> Pablo: is the "lookup in routing table from nftables" a total waste of time?
>
> You may be interested in
>
>   https://www.youtube.com/watch?v=wfWMPlZHQBk&t=19m40s

Thanks, Michal, this is interesting, but not exactly what I am looking
for. This fib module
would as far as I can tell follow the routing from rules -> table ->
decision, which will need
both a src and dst address. What I want is to skip the rule matching,
and check directly in
a table, that way we only need a single address, and the following
should potentially work
from prerouting:

ip saddr rt_table 10 drop

comments?

-- 
Bj(/)rnar

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: routing table lookup
  2016-10-12 15:19           ` Bjørnar Ness
@ 2016-10-14 11:44             ` Florian Westphal
  2016-10-14 16:48               ` Bjørnar Ness
  0 siblings, 1 reply; 9+ messages in thread
From: Florian Westphal @ 2016-10-14 11:44 UTC (permalink / raw)
  To: Bjørnar Ness; +Cc: Michal Kubecek, Jan Engelhardt, netfilter-devel

Bjørnar Ness <bjornar.ness@gmail.com> wrote:
> 2016-10-12 8:19 GMT+02:00 Michal Kubecek <mkubecek@suse.cz>:
> > On Wed, Oct 12, 2016 at 12:17:24AM +0200, Bjørnar Ness wrote:
> >>
> >> Yeah, sortoff. But afaik rpfilter is a iptables module, and not
> >> available in nftables yet.
> >>
> >> Pablo: is the "lookup in routing table from nftables" a total waste of time?
> >
> > You may be interested in
> >
> >   https://www.youtube.com/watch?v=wfWMPlZHQBk&t=19m40s
> 
> Thanks, Michal, this is interesting, but not exactly what I am looking
> for. This fib module
> would as far as I can tell follow the routing from rules -> table ->
> decision, which will need
> both a src and dst address. What I want is to skip the rule matching,
> and check directly in
> a table, that way we only need a single address, and the following
> should potentially work
> from prerouting:
> 
> ip saddr rt_table 10 drop
> 
> comments?

I don't really understand why you would want this.

If you only want to match saddr, why not use ipset (or nftables set) for
this?

If you want to use the fib, why not use blackhole routes?

I'd like to understand why you need this 'rule skip' thing, seems we
would have to export some fib internals for this which I'd like to
avoid.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: routing table lookup
  2016-10-14 11:44             ` Florian Westphal
@ 2016-10-14 16:48               ` Bjørnar Ness
  0 siblings, 0 replies; 9+ messages in thread
From: Bjørnar Ness @ 2016-10-14 16:48 UTC (permalink / raw)
  To: Florian Westphal; +Cc: Michal Kubecek, Jan Engelhardt, netfilter-devel

2016-10-14 13:44 GMT+02:00 Florian Westphal <fw@strlen.de>:
> Bjørnar Ness <bjornar.ness@gmail.com> wrote:
>>
>> ip saddr rt_table 10 drop
>>
>> comments?
>
> I don't really understand why you would want this.
>
> If you only want to match saddr, why not use ipset (or nftables set) for
> this?

Its hard to populate via routing protocols. RTBH/ Source RTBH is very
convenient, and handles all the details (filtering, timeout etc etc) in routing
daemon (bird in my case). It is ofcorse possible to make a middleware that
listens for updates on a routing table, and propagates them to a set, but
thats what I would want to and could avoid if I was given access to a
"set type" lookup in a spesific table.

> If you want to use the fib, why not use blackhole routes?

Because there is not possible to do saddr based lookups in prerouting,
the only way this is possible is if one enables rp_filter and packet will
the have traveled far inside the kernel already. Also, it is not possible
to send ICMP unreachable for example using rp_filter method

> I'd like to understand why you need this 'rule skip' thing, seems we
> would have to export some fib internals for this which I'd like to
> avoid.

I hope You can see the use of this. And it also probably has other usecases.

Regards,
--
Bj(/)rnar

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2016-10-14 16:48 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-10-11 18:11 routing table lookup Bjørnar Ness
2016-10-11 18:28 ` Jan Engelhardt
2016-10-11 19:10   ` Bjørnar Ness
2016-10-11 20:18     ` Jan Engelhardt
2016-10-11 22:17       ` Bjørnar Ness
2016-10-12  6:19         ` Michal Kubecek
2016-10-12 15:19           ` Bjørnar Ness
2016-10-14 11:44             ` Florian Westphal
2016-10-14 16:48               ` Bjørnar Ness

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.