带有静态组播路由的套接字选项 IP_MULTICAST_IF 从组播切换到单播 MAC 寻址

问题描述 投票:0回答:2

我希望专家就套接字选项 IP_MULTICAST_IF(“设置多播接口”)与静态多播路由的使用提供建议。

在 LAN 中,组播 IP 数据报通常在组播以太网帧中发送(IP/MAC 组播目的地址映射)。在多宿主 Linux 系统(内核 5.11)上,我注意到套接字选项

IP_MULTICAST_IF
修改了行为,如下所示:

  • 如果没有静态路由,多播 IP 数据报始终在多播以太网帧中发送,无论是否带有
    IP_MULTICAST_IF
  • 使用静态路由,没有
    IP_MULTICAST_IF
    ,多播 IP 数据报在多播以太网帧中发送。
  • 使用静态路由,通过
    IP_MULTICAST_IF
    ,多播 IP 数据报以单播以太网帧的形式发送到网关。

第一个问题:有了组播数据包的静态路由,组播IP数据报应该以组播以太网帧还是单播以太网帧的形式发送到网关?

第二个问题:无论第一个问题的答案是什么,为什么套接字选项 IP_MULTICAST_IF 从多播切换到单播 MAC 寻址?

Linux 手册页(“man 7 ip”)不是很明确:

IP_MULTICAST_IF (since Linux 1.2)
    Set  the  local device for a multicast socket.  The argument for setsockopt(2) is an ip_mreqn or (since Linux 3.5)
    ip_mreq structure similar to IP_ADD_MEMBERSHIP, or an in_addr structure.  (The kernel determines  which  structure
    is being passed based on the size passed in optlen.)  For getsockopt(2), the argument is an in_addr structure.

这是在两个 Linux 虚拟机之间重现此情况的示例配置。

第一个系统,“vmubuntu”,在 ens38 接口上运行 Wireshark 的接收器:

ens33: 00:0C:29:46:B7:CE  192.168.98.3   / 24  -> NAT, default route
ens38: 00:50:56:39:F0:03  192.168.233.11 / 24  -> host local vmware

第二个系统,“vmfedora”,发送方系统:

ens33: 00:0C:29:B6:33:8D  192.168.98.2   / 24  -> NAT, default route
ens37: 00:50:56:29:34:37  192.168.233.10 / 24  -> host local vmware

我们在“vmfedora”上声明多播流量的静态路由,使用“vmubuntu”作为网关。请注意,一般 IP 流量的默认路由位于另一个接口上。

$ uname -a
Linux vmfedora 5.11.15-200.fc33.x86_64 #1 SMP Fri Apr 16 13:41:20 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
$
$ sudo route add -net 224.0.0.0 netmask 240.0.0.0 gw 192.168.233.11 dev ens37
$
$ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.98.1    0.0.0.0         UG    20100  0        0 ens33
192.168.98.0    0.0.0.0         255.255.255.0   U     100    0        0 ens33
192.168.233.0   0.0.0.0         255.255.255.0   U     101    0        0 ens37
224.0.0.0       192.168.233.11  240.0.0.0       UG    0      0        0 ens37

让我们将多播数据包从“vmfedora”发送到路由范围内的239.230.2.44:3044。我们将套接字绑定到本地地址 192.168.233.10,这也是静态路由的出接口。我们不使用套接字选项

IP_MULTICAST_IF
(下面的示例代码)。

在“vmubuntu”上,Wireshark 报告如下:

Internet Protocol Version 4, Src: 192.168.233.10, Dst: 239.230.2.44
Ethernet II, Src: VMware_29:34:37 (00:50:56:29:34:37), Dst: IPv4mcast_66:02:2c (01:00:5e:66:02:2c)
    Destination: IPv4mcast_66:02:2c (01:00:5e:66:02:2c)
        Address: IPv4mcast_66:02:2c (01:00:5e:66:02:2c)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast)
    Source: VMware_29:34:37 (00:50:56:29:34:37)
        Address: VMware_29:34:37 (00:50:56:29:34:37)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Type: IPv4 (0x0800)

我们可以看到带有多播目的地址的IP数据报是在带有相应多播目的地址的以太网帧中发送的。

现在,让我们在

IP_MULTICAST_IF
之后添加套接字选项
bind()
。 Wireshark 报告了这一点:

Internet Protocol Version 4, Src: 192.168.233.10, Dst: 239.230.2.44
Ethernet II, Src: VMware_29:34:37 (00:50:56:29:34:37), Dst: VMware_39:f0:03 (00:50:56:39:f0:03)
    Destination: VMware_39:f0:03 (00:50:56:39:f0:03)
        Address: VMware_39:f0:03 (00:50:56:39:f0:03)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Source: VMware_29:34:37 (00:50:56:29:34:37)
        Address: VMware_29:34:37 (00:50:56:29:34:37)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Type: IPv4 (0x0800)

现在,我们看到带有多播目标地址的IP数据报是在以太网帧中发送的,并且以网关的单播MAC地址作为目标地址。

唯一的区别是套接字选项

IP_MULTICAST_IF

如果您想重现此内容,请参阅下面的代码。它采用一个强制命令行参数:套接字绑定到的本地接口的 IP 地址。第二个可选命令行参数是“-f”,用于强制套接字选项

IP_MULTICAST_IF
(默认情况下未设置)。

感谢您对此选项的解释。

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <errno.h>
#include <string.h>
#include <ctype.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <arpa/inet.h>
#include <netinet/in.h>

int main(int argc, char* argv[])
{
    struct sockaddr_in dest;
    dest.sin_family = AF_INET;
    dest.sin_port = htons(3044);
    inet_pton(AF_INET, "239.230.2.44", &dest.sin_addr);

    struct sockaddr_in local;
    local.sin_family = AF_INET;
    local.sin_port = 0;
    local.sin_addr.s_addr = 0;

    int use_mcast_if = 0;

    for (int arg = 1; arg < argc; ++arg) {
        if (strcmp(argv[arg], "-f") == 0) {
            use_mcast_if = 1;
        }
        else if (inet_pton(AF_INET, argv[arg], &local.sin_addr) != 1) {
            fprintf(stderr, "invalid local address: %s\n", argv[arg]);
            return EXIT_FAILURE;
        }
    }

    const int sock = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP);
    if (sock < 0) {
        perror("socket()");
        return EXIT_FAILURE;
    }
    
    if (bind(sock, (struct sockaddr*)&local, sizeof(local)) < 0) {
        perror("bind()");
        return EXIT_FAILURE;
    }

    if (use_mcast_if && setsockopt(sock, IPPROTO_IP, IP_MULTICAST_IF, &local.sin_addr, sizeof(local.sin_addr)) < 0) {
        perror("setsockopt(IP_MULTICAST_IF)");
        return EXIT_FAILURE;
    }

    const int data = 0x12345678;
    for (int i = 0; i < 10; ++i) {
        sendto(sock, &data, sizeof(data), 0, (struct sockaddr*)&dest, sizeof(dest));
    }

    close(sock);
    return EXIT_SUCCESS;
}
c linux sockets multicast multicastsocket
2个回答
1
投票

如果没有 mrouted 或 pimd 等特殊软件,Linux 通常无法处理组播路由。 我在 CentOS 7 VM(3.10 内核)上尝试过此操作,并看到带有静态路由的单播 MAC 地址,无论我是否使用

IP_MULTICAST_IF

以下关于 ServerFault 的帖子对此进行了更详细的介绍:

https://serverfault.com/questions/814259/use-ip-route-add-to-add-multicast-routes-to-multiple-interfaces

TL;DR——不要使用静态多播路由。 坚持设置

IP_MULTICAST_IF


0
投票

如果使用bind(源ip已知),或者如果使用connect套接字: 通过静态路由和 IP_MULTICAST_IF,多播 IP 数据报以单播以太网帧的形式发送到网关。 使用静态路由,没有 IP_MULTICAST_IF,多播 IP 数据报在多播以太网帧中发送。

如果使用取消连接套接字(无需首先绑定): 使用静态路由,多播 IP 数据报始终在单播以太网帧中发送,无论是否带有 IP_MULTICAST_IF。

所以不要使用静态组播路由。坚持设置 IP_MULTICAST_IF。

© www.soinside.com 2019 - 2024. All rights reserved.