如何通过 Linux 中的特定接口发送多播数据包 [英] How to send multicast packets via a specfic interface in Linux
问题描述
尝试了所有可能的方法都找不到解决此问题的方法.我有一台机器有两个接口 eth0 和 eth2.我希望所有 ff38:40:2001:dead:beef:cafe::/96 数据包都在 eth2 上.我尝试了以下所有方法，但是当我执行 ping6 ff38:40:2001:dead:beef:cafe::1 时，数据包总是在 eth0 上.我尝试过但没有奏效的事情(即数据包仍然在 eth0 上发出).
Having tried all possible ways couldn't find a work around for this problem. I have a machine with two interfaces eth0 and eth2. I want all ff38:40:2001:dead:beef:cafe::/96 packets to go on eth2. I tried all the following but when I do ping6 ff38:40:2001:dead:beef:cafe::1 the packets always goes on eth0. Things I have tried and have not worked (i.e., packet still goes out on 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 没问题).
However, ping6 ff38:40:2001:dead:beef:cafe::1 -I eth2 work just fine. Moreover, I see this problem only on Linux machines (MAC is fine).
[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 路由.
Perhaps the problem has to do with the fact that there is a ff00::/8 for eth0. How do I overrule that route. I am not able to delete ff00::/8 route as well.
推荐答案
我并不完全相信我的解决方案是正确的，但我至少可以对正在发生的事情有更多的了解.
I'm not entirely convinced my solution is correct, but I can at least shed a little more light on what is going on.
Linux 实际上有多个路由表，它们会按照特定的优先级顺序一次搜索一个，直到找到匹配路由的表.您可以根据源地址或协议选择性地搜索一些路由表；请参阅 ip-rule(8) 手册页.
Linux actually has multiple routing tables, and they are searched one at a time in a specific priority order until a table with a matching route is found. You can optionally search some of the routing tables based on source address or protocol; see the ip-rule(8) man page.
问题在于本地"路由表，它的优先级为 0，可能是最高的.本地"表由内核自动填充并保存明显"接口和广播路由.对于 Linux 下的 IPv6，这显然包括整个多播块.
The trouble is the "local" routing table, which has priority 0, the highest possible. The "local" table is populated automatically by the kernel and holds "obvious" interface and broadcast routes. For IPv6 under Linux, this apparently includes the entire multicast block.
我将使用 iproute2 工具而不是更传统的 route，因为它会显示我需要知道的一切.
I'm going to be using the iproute2 tool rather than the more traditional route, because it will show me everything I need to know.
在我的 Linux 机器上:
On my Linux box:
$ 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 添加到本地表的选择对我来说是有问题的.
...And my multicast packets for ff15::1 (5==site-local, >link-local) end up on eth0, because the "local" routing table matches first and overrides the "main" table, even though the "main" table has a more specific route. This overriding behavior is correct in the greater scheme of policy routing, but the choice of auto-adding ff00::/8 to the local table is questionable to me.
我没有足够的经验来知道这是否是一个好主意，但是:
I don't have enough experience to know if this is a good idea, but:
# ip -6 route add ff15::/16 dev eth1 table local
现在我的 ff15::1 数据包通过 eth1 路由.
and now my ff15::1 packets are routed through eth1.
这与本地表的语义有些一致，因为它直接通过设备路由.感觉不太对劲(考虑到自动管理和你不应该看这张表")，但这是我找到的最好的解决方案.
This agrees somewhat with the semantics of the local table, in that it's routed directly through a device. It doesn't feel exactly right (considering automatic management and "you shouldn't have to look at this table"), but it's the best solution I've found.
这篇关于如何通过 Linux 中的特定接口发送多播数据包的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
