From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 164F7C06510 for ; Tue, 2 Jul 2019 19:21:28 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id E39662184C for ; Tue, 2 Jul 2019 19:21:27 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="LGXYc763" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726963AbfGBTV1 (ORCPT ); Tue, 2 Jul 2019 15:21:27 -0400 Received: from out1-smtp.messagingengine.com ([66.111.4.25]:42777 "EHLO out1-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726291AbfGBTV0 (ORCPT ); Tue, 2 Jul 2019 15:21:26 -0400 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id E086721F6D; Tue, 2 Jul 2019 15:21:25 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Tue, 02 Jul 2019 15:21:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=H1eyvMtTWOTiP2We7gzPAIDaj/UBsLA87/zgqMXvy EE=; b=LGXYc763qalKVbTmzWzbomTXW1P/8UwjZEs6DxMO+8aOREt1Sb1OssFRG tmfIiUEuhEKnVilEepWZS7gsLQmVW0nSiwU90WXPSP3FQmWHH5KIIjyBNmmUOlFH 0SIxbxFplH6viRgMOYB6JhPSl6fa3ls7+tey8u0RIzuz7l8ZdcKRl3U3X4vWXall DZuuJyHZu9AYblz7UMwkg7IVxYySF57wtvV47OzcFftjHNXuPRc2Kqewz5fOtIh4 FnHi8FvukejRwSUhZ2p5RiKUUQtwya6RNhQcLcDnZysVNpMs4N6zed+wHmroarxa 9Qx/yq6VaxQW6uacthqgThiMIGHtw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrvdekgddugedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfhfgggtugfgjggfsehtkeertddtredunecuhfhrohhmpefkugho ucfutghhihhmmhgvlhcuoehiughoshgthhesihguohhstghhrdhorhhgqeenucfkphepud dtledrieehrdeifedruddtudenucfrrghrrghmpehmrghilhhfrhhomhepihguohhstghh sehiughoshgthhdrohhrghenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from localhost (bzq-109-65-63-101.red.bezeqint.net [109.65.63.101]) by mail.messagingengine.com (Postfix) with ESMTPA id CF00B80063; Tue, 2 Jul 2019 15:21:24 -0400 (EDT) Date: Tue, 2 Jul 2019 22:21:22 +0300 From: Ido Schimmel To: =?iso-8859-1?Q?Zolt=E1n?= Elek Cc: netdev@vger.kernel.org, dsa@cumulusnetworks.com Subject: Re: veth pair ping fail if one of them enslaved into a VRF Message-ID: <20190702192122.GA16784@splinter> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.11.3 (2019-02-01) Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Tue, Jul 02, 2019 at 08:42:15PM +0200, Zoltán Elek wrote: > Hi! > > I have a simple scenario, with a veth pair, IP addresses assigned from > the same subnet. They can ping eachother. But when I put one of them > into a VRF (in the example below, I put veth in-vrf into the test-vrf > VRF) the ping fails. My first question: that is the expected behavior? > And my second question: is there any way to overcome this? > > Here are my test commands: > ip link add out-of-vrf type veth peer name in-vrf > ip link set dev out-of-vrf up > ip link set dev in-vrf up > ip link add test-vrf type vrf table 10 > ip link set dev test-vrf up > ip -4 addr add 100.127.253.2/24 dev in-vrf > ip -4 addr add 100.127.253.1/24 dev out-of-vrf > > Then ping works as expected: > ping -c1 -I 100.127.253.1 100.127.253.2 > > After I put the in-vrf into test-vrf, ping fails: > ip link set in-vrf vrf test-vrf up You need to re-order the FIB rules so that lookup for 100.127.253.1 happens in table 10 and not in the local table: # ip -4 rule add pref 32765 table local # ip -4 rule del pref 0 # ip -4 rule show 1000: from all lookup [l3mdev-table] 32765: from all lookup local 32766: from all lookup main 32767: from all lookup default Bad: ping 16735 [001] 13726.398115: fib:fib_table_lookup: table 255 oif 0 iif 9 proto 0 100.127.253.2/0 -> 100.127.253.1/0 tos 0 scope 0 flags 4 ==> dev out-of-vrf gw 0.0.0.0 src 100.127.253.1 err 0 Good: ping 16665 [001] 13500.937145: fib:fib_table_lookup: table 10 oif 0 iif 9 proto 0 100.127.253.2/0 -> 100.127.253.1/0 tos 0 scope 0 flags 4 ==> dev in-vrf gw 0.0.0.0 src 100.127.253.2 err 0 > > Thanks, > Zoltan Elek, > VI1