From mboxrd@z Thu Jan 1 00:00:00 1970 From: Phil Karn Subject: Re: hard-coded limit on unresolved multicast route cache in ipv4/ipmr.c causes slow, unreliable creation of multicast routes on busy networks Date: Sat, 21 Jul 2018 22:32:02 -0700 Message-ID: <0e085e9b-1e49-126c-f5f7-6ce2cfdd478d@ka9q.net> References: <147f730b-8cbf-b76d-f693-b3fdaf72a89c@ka9q.net> <20180721.220309.1193443933653884021.davem@davemloft.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Cc: kuznet@ms2.inr.ac.ru, yoshfuji@linux-ipv6.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org To: David Miller Return-path: Received: from mail-pf1-f169.google.com ([209.85.210.169]:34307 "EHLO mail-pf1-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727764AbeGVG13 (ORCPT ); Sun, 22 Jul 2018 02:27:29 -0400 Received: by mail-pf1-f169.google.com with SMTP id k19-v6so355180pfi.1 for ; Sat, 21 Jul 2018 22:32:05 -0700 (PDT) In-Reply-To: <20180721.220309.1193443933653884021.davem@davemloft.net> Content-Language: en-US Sender: netdev-owner@vger.kernel.org List-ID: On 07/21/2018 10:03 PM, David Miller wrote: > There does have to be some limit, because we are depending upon a user > process (mrouted or whatever) to receive the netlink message, resolve > the cache entry, and update the kernel. Wow, thanks for the quick response. I notice that an "unresolved" entry seems to be created whenever the router sees multicast traffic from a particular source to a particular group. The entry seems to "resolve" when an IGMP membership message is also seen for that particular group. There are a whole bunch of active multicast streams on my UCSD network segment for which there are apparently no listeners, and that seems to be why I always see a mroute cache full of "unresolved" entries. (If I run a local application that joins a group, the entry "resolves".) What puzzles me is that the Iif field is given as "unresolved" even though we know where the multicast traffic is coming from. We only don't know who might want it. I'm intimately familiar with unicast IP but I'm still learning about multicast routing so I am probably missing something important. I tried a workaround by using iptables to block the unwanted multicast traffic (the senders are on one well-defined non-local subnet). I created drop entries in both the INPUT and FORWARD chains but the hit counts remain zero. I guess the mroute table is populated before the packets reach netfilter. Is that how it should work? Phil