如何在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-我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屋！
