All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Suryaputra <ssuryaextr@gmail.com>
To: David Ahern <dsahern@gmail.com>
Cc: netdev@vger.kernel.org
Subject: Re: ip rule iif oif and vrf
Date: Thu, 24 Sep 2020 09:48:45 -0400	[thread overview]
Message-ID: <20200924134845.GA3688@ICIPI.localdomain> (raw)
In-Reply-To: <ccba2d59-58ad-40ca-0a09-b55c90e9145e@gmail.com>

On Wed, Sep 23, 2020 at 07:47:16PM -0600, David Ahern wrote:
> If I remove the fib rules and add VRF route leaking from core to tenant
> it works. Why is that not an option? Overlapping tenant addresses?

Exactly.

> One thought to get around it is adding support for a new FIB rule type
> -- say l3mdev_port. That rule can look at the real ingress device which
> is saved in the skb->cb as IPCB(skb)->iif.

OK. Just to ensure that the existing ip rule behavior isn't considered a
bug.

We have multiple options on the table right now. One that can be done
without writing any code is to use an nft prerouting rule to mark
the packet with iif equals the tunnel and use ip rule fwmark to lookup
the right table.

ip netns exec r0 nft add table ip c2t
ip netns exec r0 nft add chain ip c2t prerouting '{ type filter hook prerouting priority 0; policy accept; }'
ip netns exec r0 nft rule ip c2t prerouting iif gre01 mark set 101 counter
ip netns exec r0 ip rule add fwmark 101 table 10 pref 999

ip netns exec r1 nft add table ip c2t
ip netns exec r1 nft add chain ip c2t prerouting '{ type filter hook prerouting priority 0; policy accept; }'
ip netns exec r1 nft rule ip c2t prerouting iif gre10 mark set 101 counter
ip netns exec r1 ip rule add fwmark 101 table 10 pref 999

But this doesn't seem to work on my Ubuntu VM with the namespaces
script, i.e. pinging from h0 to h1. The packet doesn't egress r1_v11. It
does work on our target, based on 4.14 kernel.

We also notice though in on the target platform that the ip rule fwmark
doesn't seem to change the skb->dev to the vrf of the lookup table.
E.g., ping from 10.0.0.1 to 11.0.0.1. With net.ipv4.fwmark_reflect set,
the reply is generated but the originating ping application doesn't get
the packet.  I suspect it is caused by the socket is bound to the tenant
vrf. I haven't been able to repro this because of the problem with the
nft approach above.

Thanks,
Stephen.

  reply	other threads:[~2020-09-24 13:48 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-22 13:11 ip rule iif oif and vrf Stephen Suryaputra
2020-09-22 15:39 ` David Ahern
2020-09-23 23:50   ` Stephen Suryaputra
2020-09-24  1:47     ` David Ahern
2020-09-24 13:48       ` Stephen Suryaputra [this message]
2020-09-24 14:41         ` David Ahern
2020-10-01  2:23           ` Stephen Suryaputra
2020-10-12  0:06             ` David Ahern

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=20200924134845.GA3688@ICIPI.localdomain \
    --to=ssuryaextr@gmail.com \
    --cc=dsahern@gmail.com \
    --cc=netdev@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.