【问题标题】:How to send multicast packets via a specfic interface in Linux如何通过 Linux 中的特定接口发送多播数据包
【发布时间】:2011-10-11 12:10:49
【问题描述】:

尝试了所有可能的方法后无法找到解决此问题的方法。我有一台机器有两个接口 eth0 和 eth2。我希望所有 ff38:40:2001:dead:beef:cafe::/96 数据包都在 eth2 上。我尝试了以下所有方法,但是当我执行 ping6 ff38:40:2001:dead:beef:cafe::1 时,数据包总是在 eth0 上。我尝试过但没有奏效的事情(即,数据包仍然在 eth0 上发出)。

$> route add --inet6 ff38:40:2001:dead:beef:cafe::/96 gw 2003::100 dev eth2
$> route add --inet6 ff38:40:2001:dead:beef:cafe::/96 dev eth2
$> route add --inet6 ff38:40:2001:dead:beef:cafe::/96 metric 1 gw 2003::100 dev eth2

我的路由表是

[root@dev ~]# route --inet6  |grep eth0
fe80::/64                                   *                                       U     256    0        0 eth0
ff00::/8                                    *                                       U     256    0        0 eth0

[root@dev ~]# route --inet6  |grep eth2
2003::/64                                   *                                       U     256    68       0 eth2
fe80::/64                                   *                                       U     256    0        0 eth2
ff38:40:2001:dead:beef:cafe::/96            2003::100                               UG    1      0        0 eth2
*/0                                         fe80::c671:feff:fe14:e482               UGDA  1024   0        0 eth2
ff00::/8                                    *                                       U     256    0        0 eth2

但是,ping6 ff38:40:2001:dead:beef:cafe::1 -I eth2 工作得很好。此外,我只在 Linux 机器上看到这个问题(MAC 很好)。

[root@dev ~]# ping6 ff38:40:2001:dead:beef:cafe::1 -I eth2
PING ff38:40:2001:dead:beef:cafe::1(ff38:40:2001:dead:beef:cafe:0:1) from cal eth2: 56 data bytes
64 bytes from 2012::1: icmp_seq=0 ttl=253 time=19.1 ms
64 bytes from 2012::1: icmp_seq=1 ttl=253 time=2.16 ms
64 bytes from 2012::1: icmp_seq=2 ttl=253 time=2.14 ms
64 bytes from 2012::1: icmp_seq=3 ttl=253 time=2.26 ms
64 bytes from 2012::1: icmp_seq=4 ttl=253 time=2.08 ms
64 bytes from 2012::1: icmp_seq=5 ttl=253 time=2.15 ms

root@dev ~]# uname -a
Linux 2.6.18-194.el5 #1 SMP Tue Mar 16 21:52:39 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux

也许问题与 eth0 有一个 ff00::/8 的事实有关。我如何否决那条路线。我也无法删除 ff00::/8 路由。

【问题讨论】:

  • 如果应用程序足够先进,可以使用 IPv6,为什么不能先进到选择传出接口。
  • @Steve-o:因为至少在传统上,这就是路由表的用途。 IPv6 的范围地址概念有所改变,但路由表肯定应该处理站点范围或更大范围的地址路由吗?

标签: linux routing ipv6 multicast


【解决方案1】:

我并不完全相信我的解决方案是正确的,但我至少可以更清楚地了解正在发生的事情。

背景

Linux 实际上有多个路由表,它们以特定的优先级顺序一次搜索一个,直到找到一个匹配路由的表。您可以选择根据源地址或协议搜索一些路由表;请参阅 ip-rule(8) 手册页。

问题在于“本地”路由表,它的优先级为 0,可能是最高的。 “本地”表由内核自动填充,并保存“明显”接口和广播路由。对于 Linux 下的 IPv6,这显然包括了整个多播块。

问题

我将使用 iproute2 工具而不是更传统的 route,因为它会告诉我我需要知道的一切。

在我的 Linux 机器上:

$ ip -6 route show table local
local ::1 via :: dev lo  proto none  metric 0 
local fe80::213:a9ff:fe91:5bcb via :: dev lo  proto none  metric 0 
local fe80::250:b6ff:fe44:37d1 via :: dev lo  proto none  metric 0 
ff00::/8 dev eth0  metric 256 
ff00::/8 dev eth1  metric 256

$ ip -6 route show table main
fe80::/64 dev eth0  proto kernel  metric 256 
fe80::/64 dev eth1  proto kernel  metric 256 
ff15::/16 dev eth1  metric 1024
ff00::/8 dev eth1  metric 1024 

$ ip -6 rule show
0:      from all lookup local 
32766:  from all lookup main 

...我的 ff15::1 (5==site-local, >link-local) 的多播数据包最终在 eth0 上,因为“本地”路由表首先匹配并覆盖“主”表,即使“主”表有更具体的路线。这种压倒一切的行为在更大的策略路由方案中是正确的,但对我来说,自动添加 ff00::/8 到本地表的选择是有问题的。

我的解决方案

我没有足够的经验知道这是否是个好主意,但是:

# ip -6 route add ff15::/16 dev eth1 table local

现在我的 ff15::1 数据包通过 eth1 路由。

这在某种程度上与本地表的语义一致,因为它直接通过设备进行路由。感觉不太对(考虑到自动管理和“你不应该看这张表”),但这是我找到的最佳解决方案。

【讨论】:

  • 我们预计会有类似的情况,但您最终澄清了这一点。
  • 相关,如果你需要将多播路由添加到多个接口,你应该执行这个答案中显示的命令,然后使用ip route append <prefix> dev <interface> table local添加第二个路由(在研究这个时我是带到这里,所以我想我会把线索留给任何未来的旅行者。)
【解决方案2】:

多播本质上是一种本地链接“广播”。因此,您必须始终指明将其发送到的区域或网络接口。没有路由。 如果您有多个接口,则应将其发送到多个接口。 方法是: ping(6) ip%zone 。 现在在同一个网络上可能有一个路由器接收数据包并将其转发到另一个区域,如果另一个区域上的某个节点订阅了该地址,并且数据包的 TTL > 1。不涉及路由表在多播路由中,除了多播路由器。

由于这个最初的问题是从 2012 年开始的,大约在那个时候,用户内核空间被修复,使得发送没有区域标识符的多播数据包是非法的。 所以原始问题中的 ping6 甚至不起作用。

IPv4 的情况很糟糕,因为很难为传出多播绑定到特定接口,除非使用的软件得到正确实施。

【讨论】:

    猜你喜欢
    • 2018-04-15
    • 2015-05-04
    • 1970-01-01
    • 1970-01-01
    • 2011-06-02
    • 2017-02-25
    • 1970-01-01
    • 1970-01-01
    • 2019-02-14
    相关资源
    最近更新 更多