我在具有 2 个接口的系统上运行 Linux 3.14。在第一个接口上，我可以访问我们的本地网络。在第二个接口上，arp 数据包进入，但 Linux 没有发出回复。mac 地址是否可能导致 Linux 丢弃 arp 数据包？tcpdump 显示源地址来自以下源：fe:xx:xx:xx:xx:xx。我无法在网上找到任何信息来表明 Linux 如何处理这种类型的 mac 地址。60 字节数据包的其余部分看起来很好。我甚至将 arp 数据包与来自第一个接口的数据包进行了比较。
先感谢您。
嗨，mathius 顺便说一下，我还注意到，如果不运行 tcpdump，驱动程序统计信息显示 rx 数据包不会增加。但运行 tcpdump 时，rx 计数会增加。因此，似乎 tcpdump 导致驱动程序接受数据包。也许 tcpdump 将驱动程序置于混杂模式？这是“ip as”和“ip rs”命令的输出。eobc 接口是问题所在 eobc
pad# ip as 1: lo: mtu 65536 qdisc noop
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2：eth0：mtu 1500 qdisc noop qlen 1000
link/ether 80:3f:5d:09:7f:4b brd ff:ff:ff:ff:ff:ff
3：eobc：mtu 1500 qdisc mq qlen 1000
link/ether 00:a0:c9:00:00:00 brd ff:ff:ff:ff:ff:ff
inet 192.168.0.10/24 brd 192.168.0.255 scope global eobc
valid_lft forever preferred_lft forever
inet6 fe80::2a0:c9ff:fe00:0/64 scope link
valid_lft forever preferred_lft forever
4：管理：mtu 1500 qdisc mq qlen 1000
link/ether 00:a0:c9:01:25:68 brd ff:ff:ff:ff:ff:ff
inet 172.24.22.68/24 brd 172.24.22.255 scope global mgmt
valid_lft forever preferred_lft forever
inet6 2001:420:293:1330:2a0:c9ff:fe01:2568/64 scope global dynamic
valid_lft 2591998sec preferred_lft 604798sec
inet6 fe80::2a0:c9ff:fe01:2568/64 scope link
valid_lft forever preferred_lft forever
5：bcm：mtu 1500 qdisc noop qlen 1000
link/ether 00:a0:c9:00:00:03 brd ff:ff:ff:ff:ff:ff
pad# ip rs
默认通过 192.168.0.100 dev eobc
默认通过 172.24.22.1 dev mgmt
172.24.22.0/24 设备管理源 172.24.22.68
192.168.0.0/24 dev eobc 源 192.168.0.10
pad#
按照 xavier 的建议，我仍然看到同样的问题。（我消除了重复的默认值）并修改了路由：pad# ip rs default via 172.24.22.1 dev mgmt
172.24.22.0/24 设备管理源 172.24.22.68
192.168.0.0/24 dev eobc