From mboxrd@z Thu Jan  1 00:00:00 1970
From: David Ahern <dsahern@gmail.com>
Subject: Re: v6/sit tunnels and VRFs
Date: Fri, 13 Apr 2018 14:31:19 -0600
Message-ID: <e19f2fb3-319c-e8ea-5fc3-5072ddb69c5b@gmail.com>
References: <CAL6e_pdXJFoVVCfAOc9D_kE73juGQzjoUueEBvEMS=cq5CDKkg@mail.gmail.com>
 <fc420b5d-f179-a1fb-9cf5-ce1820870c83@gmail.com>
 <CAL6e_pdBDWBO796tfCnygj0e-c7S81O1y3hvZz3rgbMgxUobOg@mail.gmail.com>
 <9cade21c-5d92-d435-386f-6d854e6b6d55@gmail.com>
 <CAL6e_pc=Z03obL1U_+EY1t2EQ3Q7pmmcfU72tuO-hPzqqgPgig@mail.gmail.com>
 <aa76d6b7-dbb1-5275-09f6-a4450aeceeb2@gmail.com>
 <CAL6e_pfAtUAFRmm_2Ykn43jk-0mQn7f9FAt+CgHV4nFHT-PdPQ@mail.gmail.com>
 <609f2e30-3e9d-f317-e2b4-ba3fb7d20532@gmail.com>
 <CAL6e_pcL3DF1J1-+w0pw0CZ=Zm_BRfKtz=5jML_GcZBZFW1JVA@mail.gmail.com>
 <abb3291a-222a-7eff-724c-9d06fea9f02d@gmail.com>
 <CAL6e_peeeGNhXr1rxF5k+N_THGMyEOa8pt7JCLB_PyFfK2PXOg@mail.gmail.com>
 <66ebbad0-68e4-ba2d-ffb6-2a8057e72b04@gmail.com>
 <CAL6e_pdihSXvYFQQ0MAXFtw=eUjJPfR9kS9j5QQNSqCNzdQteg@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Cc: netdev@vger.kernel.org
To: Jeff Barnhill <0xeffeff@gmail.com>
Return-path: <netdev-owner@vger.kernel.org>
Received: from mail-pf0-f178.google.com ([209.85.192.178]:34703 "EHLO
        mail-pf0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1751011AbeDMUbW (ORCPT
        <rfc822;netdev@vger.kernel.org>); Fri, 13 Apr 2018 16:31:22 -0400
Received: by mail-pf0-f178.google.com with SMTP id q9so6790926pff.1
        for <netdev@vger.kernel.org>; Fri, 13 Apr 2018 13:31:22 -0700 (PDT)
In-Reply-To: <CAL6e_pdihSXvYFQQ0MAXFtw=eUjJPfR9kS9j5QQNSqCNzdQteg@mail.gmail.com>
Content-Language: en-US
Sender: netdev-owner@vger.kernel.org
List-ID: <netdev.vger.kernel.org>

On 4/13/18 2:23 PM, Jeff Barnhill wrote:
> It seems that the ENETUNREACH response is still desirable in the VRF
> case since the only difference (when using VRF vs. not) is that the
> lookup should be restrained to a specific VRF.

VRF is just policy routing to a table. If the table wants the lookup to
stop, then it needs a default route. What you are referring to is the
lookup goes through all tables and does not find an answer so it fails
with -ENETUNREACH. I do not know of any way to make that happen with the
existing default route options and in the past 2+ years we have not hit
any s/w that discriminates -ENETUNREACH from -EHOSTUNREACH.

I take it this is code from your internal code base. Why does it care
between those two failures?