All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Ahern <dsahern@gmail.com>
To: Xin Long <lucien.xin@gmail.com>
Cc: network dev <netdev@vger.kernel.org>, davem <davem@davemloft.net>,
	Davide Caratti <dcaratti@redhat.com>,
	Ido Schimmel <idosch@idosch.org>
Subject: Re: [PATCHv2 net-next 2/2] selftests: add a selftest for directed broadcast forwarding
Date: Thu, 5 Jul 2018 07:18:46 -0600	[thread overview]
Message-ID: <df1c3df6-bd68-8a97-df36-ab3fa14d2bcb@gmail.com> (raw)
In-Reply-To: <CADvbK_fsFHuW4gvtpSZ-A8F12PXaMX8YGGKmhsMy3L_KTZt-8Q@mail.gmail.com>

On 7/5/18 1:57 AM, Xin Long wrote:
> On Thu, Jul 5, 2018 at 2:36 AM, David Ahern <dsahern@gmail.com> wrote:
>> On 7/4/18 11:56 AM, Xin Long wrote:
>>
>>>> your commands are not a proper test. The test should succeed and fail
>>>> based on the routing lookup, not iptables rules.
>>> A proper test can be done easily with netns, as vrf can't isolate much.
>>> I don't want to bother forwarding/ directory with netns, so I will probably
>>> just drop this selftest, and let the feature patch go first.
>>>
>>
>> BTW, VRF isolates at the routing layer and this is a routing change. We
>> need to understand why it does not work with VRF. Perhaps another tweak
>> is needed for VRF.
> One problem was that the peer may not use the address on the dev
> that echo_request comes from as the src IP of echo_reply when the
> echo_request's dst IP is broadcast, but try to get another one by
> looking up a route without ".flowi4_oif" set. See:
> 
> icmp_reply()->fib_compute_spec_dst():
>                 struct flowi4 fl4 = {
>                         .flowi4_iif = LOOPBACK_IFINDEX,
>                         .daddr = ip_hdr(skb)->saddr,
>                         .flowi4_tos = RT_TOS(ip_hdr(skb)->tos),
>                         .flowi4_scope = scope,
>                         .flowi4_mark = IN_DEV_SRC_VMARK(in_dev) ? skb->mark : 0,
>                 };
>                 if (!fib_lookup(net, &fl4, &res, 0))
>                         return FIB_RES_PREFSRC(net, res);
> 
> 
> Without ".flowi4_oif" set, it won't match the vrf route. That's why
> I had to make h2 NOT into a vrf so that h1 can get the echo_reply.
> But it can't tell if this echo_reply is from h2 or r1, as r1's echo_reply
> will also use the same src IP which is actually got from main route
> space as  ".flowi4_oif" is not set.
> (hope I this description is clear to you) :)
> 
> So i'm not sure if we can do any tweak for VRF.
> 

Try this:

diff --git a/net/ipv4/fib_frontend.c b/net/ipv4/fib_frontend.c
index b21833651394..e46cdd310e5f 100644
--- a/net/ipv4/fib_frontend.c
+++ b/net/ipv4/fib_frontend.c
@@ -300,6 +300,7 @@ __be32 fib_compute_spec_dst(struct sk_buff *skb)
        if (!ipv4_is_zeronet(ip_hdr(skb)->saddr)) {
                struct flowi4 fl4 = {
                        .flowi4_iif = LOOPBACK_IFINDEX,
+                       .flowi4_oif = l3mdev_master_ifindex_rcu(dev),
                        .daddr = ip_hdr(skb)->saddr,
                        .flowi4_tos = RT_TOS(ip_hdr(skb)->tos),
                        .flowi4_scope = scope,

  reply	other threads:[~2018-07-05 13:18 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-02  6:30 [PATCHv2 net-next 0/2] route: add support and selftests for directed broadcast forwarding Xin Long
2018-07-02  6:30 ` [PATCHv2 net-next 1/2] route: add support " Xin Long
2018-07-02  9:57   ` Davide Caratti
2018-07-02 15:05   ` David Ahern
2018-07-03 11:38     ` Xin Long
2018-07-02  6:30 ` [PATCHv2 net-next 2/2] selftests: add a selftest " Xin Long
2018-07-02 15:12   ` David Ahern
2018-07-03 11:36     ` Xin Long
2018-07-03 19:23       ` David Ahern
2018-07-04 17:56         ` Xin Long
2018-07-04 18:31           ` David Ahern
2018-07-04 18:36           ` David Ahern
2018-07-05  7:57             ` Xin Long
2018-07-05 13:18               ` David Ahern [this message]
2018-07-05 14:07                 ` Xin Long
2018-07-06  9:50                   ` Xin Long
2018-07-07 14:51                     ` David Ahern
2018-07-04 20:39           ` Ido Schimmel
2018-07-05  8:21             ` Xin Long
2018-07-05 15:38               ` Xin Long

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=df1c3df6-bd68-8a97-df36-ab3fa14d2bcb@gmail.com \
    --to=dsahern@gmail.com \
    --cc=davem@davemloft.net \
    --cc=dcaratti@redhat.com \
    --cc=idosch@idosch.org \
    --cc=lucien.xin@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.