netdev - Re: Multicast routing: wrong output interface selected unless VRF default route is added

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]

Date:   Tue, 23 Jun 2020 21:38:35 +0300
From:   Ido Schimmel <idosch@...sch.org>
To:     Qiwei Wen <wenqiweiabcd@...il.com>
Cc:     netdev@...r.kernel.org, dsahern@...il.com
Subject: Re: Multicast routing: wrong output interface selected unless VRF
 default route is added

On Mon, Jun 22, 2020 at 09:19:10AM +1000, Qiwei Wen wrote:
> Hi all,
> 
> While experimenting with FRRouting, I observed the following
> behaviour. I'm not sure whether it's intended or not.
> 
> In a virtual machine set up as a multicast router, I added two
> networks, created a VRF, and enslaved interfaces to both networks to
> the VRF, like so:
> 
> ip link add blue type vrf table 1001
> ip link set eth0 master blue
> ip link set eth1 master blue
> 
> I then set up PIM on the router VM (FRR configs attached) and started
> the multicast sender and receiver processes on two other VMs. The
> mroutes came up as expected (ip show mroute table 1001), but no
> packets came to the receiver. I added the following debug message to
> ipmr_queue_xmit, just before the NF_HOOK macro:
> 
> +    pr_info("calling NF_HOOK! vif->dev is %s,"
> +            " dev is %s, skb->dev is %s\n",
> +            vif->dev->name, dev->name, skb->dev->name);
> 
> and I found that "dev", the selected output interface, is in fact the
> output interface of the main table (unicast) default route. Running
> tcpdump on that (very wrong) output interface confirmed this.
> 
> I then went back to networking/vrf.txt, and found that I forgot to do this:
> 
> ip route add table 1001 unreachable default metric 4278198272
> 
> after this step, multicast routing began to work correctly.
> 
> Further debugging-by-printk lead to these observations:
> 1. Using the main table (without VRFs), multicast routing works fine
> with or without the default unicast route; but in the function "
> ip_route_output_key_hash_rcu", the call to "fib_lookup" in fact fails
> with -101, "network unreachable".
> 2. Using the VRF table 1001, the kernel stops routing multicast
> packets to the wrong interface once the unreachable default route is
> added. "fib_lookup" continues to fail, but with -113, "host
> unreachable".
> 
> My questions are:
> 1. is fib_lookup supposed to work with multicast daddr? If so, has
> multicast routing been working for the wrong reason?
> 2. Why does the addition of a unicast default route affect multicast
> routing behaviour?

I believe this was discussed in the past. See:
https://lore.kernel.org/netdev/20200115191920.GA1490933@splinter/#t