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

[Ido Schimmel <idosch@idosch.org>]

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