linux-kernel - Re: hard-coded limit on unresolved multicast route cache in ipv4/ipmr.c causes slow, unreliable creation of multicast routes on busy networks

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <0e085e9b-1e49-126c-f5f7-6ce2cfdd478d@ka9q.net>
Date:   Sat, 21 Jul 2018 22:32:02 -0700
From:   Phil Karn <karn@...q.net>
To:     David Miller <davem@...emloft.net>
Cc:     kuznet@....inr.ac.ru, yoshfuji@...ux-ipv6.org,
        netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: hard-coded limit on unresolved multicast route cache in
 ipv4/ipmr.c causes slow, unreliable creation of multicast routes on busy
 networks

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