Currently it is not possible to use more than 255 multicast interfaces
for IPv4 due to the format of the igmpmsg header which only has 8 bits
available for the VIF ID. There is enough space for the full VIF ID in
the Netlink cache notifications, however the value is currently taken
directly from the igmpmsg header and has thus already been truncated.
Using the full VIF ID in the Netlink notifications allows use of more
than 255 IPv4 multicast interfaces if the user space routing daemon
uses the Netlink notifications instead of the igmpmsg cache reports.
However doing this reveals a deficiency in the Netlink cache report
notifications, they lack any means for differentiating cache reports
relating to different multicast routing tables. This is easily
resolved by adding the multicast route table ID to the cache reports.
Paul Davey (2):
ipmr: Add route table ID to netlink cache reports
ipmr: Use full VIF ID in netlink cache reports
include/uapi/linux/mroute.h | 1 +
net/ipv4/ipmr.c | 12 +++++++-----
2 files changed, 8 insertions(+), 5 deletions(-)
--
2.28.0
From: Paul Davey <[email protected]>
Date: Wed, 2 Sep 2020 15:22:20 +1200
> Currently it is not possible to use more than 255 multicast interfaces
> for IPv4 due to the format of the igmpmsg header which only has 8 bits
> available for the VIF ID. There is enough space for the full VIF ID in
> the Netlink cache notifications, however the value is currently taken
> directly from the igmpmsg header and has thus already been truncated.
>
> Using the full VIF ID in the Netlink notifications allows use of more
> than 255 IPv4 multicast interfaces if the user space routing daemon
> uses the Netlink notifications instead of the igmpmsg cache reports.
>
> However doing this reveals a deficiency in the Netlink cache report
> notifications, they lack any means for differentiating cache reports
> relating to different multicast routing tables. This is easily
> resolved by adding the multicast route table ID to the cache reports.
But this means that mrouted has no way to see the full 16-bit value
via traditional igmpmsg UAPI interfaces.
Please instead make use of the unused3 member to store the high
order 16-bits of the vifi_t in the igmpmsg, and then code your
netlink changes around that.