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=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 7127DC32771 for ; Wed, 15 Jan 2020 19:19:37 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 391322187F for ; Wed, 15 Jan 2020 19:19:37 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="UWrRhi44" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726553AbgAOTTg (ORCPT ); Wed, 15 Jan 2020 14:19:36 -0500 Received: from out5-smtp.messagingengine.com ([66.111.4.29]:57183 "EHLO out5-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725999AbgAOTTg (ORCPT ); Wed, 15 Jan 2020 14:19:36 -0500 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 5A58522085; Wed, 15 Jan 2020 14:19:35 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Wed, 15 Jan 2020 14:19:35 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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=fm1; bh=lFOhyx 55xjNGhMEvMKh98M1xXLHAofEmofJC0TwH0ek=; b=UWrRhi44JAHgmfltXo6BSP 3liUyO7XQYtLOf1pHoq1pQ3oYTTPb8bth7324N87oihx97BEdKTWEZGOPfuiK03u kDofsfkQxaA+DXxevc6CVESO5En02AUaNb/3Wa2HVTzCSBPsB9iha3YeShC+Lxrh sntHgKlmpOhW/hE/PZhgQ2MJOL4Ak8azmdy21ZCkZBZhH53NQrrPOrl6AzWByX+I KAGQdXEqR99IfDLyy7g+Jl6kHWmrGmd+9nZj0wNYdslTqX4dwqgs1/IIC59EQY5P naRrHY5NMb+sy80R/2DyKEhfBRAEx6uwSUXpwG30+N7tq8yg4NEymujQvWXMFhig == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrtdefgdduvddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfhfgggtuggjsehttdertddttddvnecuhfhrohhmpefkughoucfu tghhihhmmhgvlhcuoehiughoshgthhesihguohhstghhrdhorhhgqeenucffohhmrghinh eptggrnhguvghlrghtvggthhdrtghomhenucfkphepjeejrddufeekrddvgeelrddvtdel necurfgrrhgrmhepmhgrihhlfhhrohhmpehiughoshgthhesihguohhstghhrdhorhhgne cuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from localhost (unknown [77.138.249.209]) by mail.messagingengine.com (Postfix) with ESMTPA id E72C030602DE; Wed, 15 Jan 2020 14:19:33 -0500 (EST) Date: Wed, 15 Jan 2020 21:19:20 +0200 From: Ido Schimmel To: Ben Greear Cc: David Ahern , "netdev@vger.kernel.org" Subject: Re: vrf and multicast is broken in some cases Message-ID: <20200115191920.GA1490933@splinter> References: <3906c6fe-e7a7-94c1-9d7d-74050084b56e@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Wed, Jan 15, 2020 at 11:02:26AM -0800, Ben Greear wrote: > > > On 01/15/2020 10:45 AM, David Ahern wrote: > > On 1/15/20 10:57 AM, Ben Greear wrote: > > > Hello, > > > > > > We put two different ports into their own VRF, and then tried to run a > > > multicast > > > sender on one and receiver on the other. The receiver does not receive > > > anything. > > > > > > Is this a known problem? > > > > > > If we do a similar setup with policy based routing rules instead of VRF, > > > then the multicast > > > test works. > > > > > > > It works for OSPF for example. I have lost track of FRR features that > > use it, so you will need to specify more details. > > > > Are the sender / receiver on the same host? > > Yes, like eth2 sending to eth3, eth2 is associated with _vrf2, eth3 with _vrf3. Two questions: 1. Did you re-order the FIB rules so that l3mdev rule is before the main table? 2. Did you configure a default unreachable route in the VRF? IIRC, locally generated multicast packets are forwarded according to the unicast FIB rules, so if you don't have the unreachable route, it is possible the packet is forwarded according to the default route in the main table. > > I'll go poking at the code. > > Thanks, > Ben > > -- > Ben Greear > Candela Technologies Inc http://www.candelatech.com