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?
-Dave
frr-runn
Description: Binary data
