在什么情况下 Linux 在选择出站帧的 MAC 地址时会忽略路由表?

在什么情况下 Linux 在选择出站帧的 MAC 地址时会忽略路由表?

尽管调试在 KVM 下运行的一组虚拟机的网络配置存在问题,我发现这样一种情况,即客户虚拟机中的内核决定为传出的以太网帧标记一个目标地址,而这个地址与它根据内核 IP 路由表选择的地址相冲突。

因此,在该示例中,我预计出站帧将被传送到 de:ad:be:3b:24:48,它对应于拥有 IP 地址 10.11.11.2 且拥有到 10.8.0.0/24 的路由的主机。

实际发生的情况是,内核决定将帧的目的地标记为 00:10:db:ff:70:01,从而将帧发送到 10.11.11.1 方向,而 10.11.1 不知道如何路由到 10.8.0.0/24,因此数据包被丢弃。

此决定违反了本地路由表,该表明确规定到 10.8.0.0/24 的路由是通过 10.11.11.2 的。有关详细信息,请参阅原始问题报告。

[在以错误方向发送帧的客户虚拟机中运行 tcpdump 可以看到错误的目标地址。]

事实上,通过拼凑本地 arp 表以使 10.11.11.1 的明显 MAC 地址与 10.11.11.2 的实际 MAC 地址相同,我能够让帧流向正确的方向。

所以我的问题是:在客户虚拟机或 KVM 主机中,哪种机制可能导致客户内核忽略本地路由表并将数据包以帧的形式发送到 10.11.11.1 的(不正确的)主机,即使 10.11.11.1 未被列为目标网络(10.8.0.0/24)的网关?

注意:当时客户机中的 iptables 被禁用。我不知道 KVM 主机中是否启用了 ebtables,但即使启用了,这又如何导致客户机虚拟机中的内核想要将数据包发送到 10.11.11.1 的方向?

我确实注意到一个现象,如果我清除受影响主机的 ARP 表并从 10.8.0.0/24 网络向受影响主机发送 ping 请求,它会收到请求,然后立即发送 10.11.11.1 的 arp 广播,然后立即向 10.11.11.1 方向发送 ping 响应,而不是 10.11.11.2,因此是 10.8.0.0/24。是什么原因导致它尝试未指定为网关的 10.11.11.1?

答案1

可能是基于源或策略的路由?Linux 可以有多个路由表,并根据多个条件选择使用哪一个。查看OpenVZ 关于基于源的路由的文档

相关内容