在debugging在KVM下运行的一组虚拟机的networkingconfiguration问题时，我发现了一个情况：虚拟机中的内核已经决定在外出的以太网帧上加上一个与它所在的地址冲突的目标地址select是否与内核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.8.0.0 / 24，结果数据包被丢弃。
这个决定违反了本地路由表，明确指出10.8.0.0/24的路由是通过10.11.11.2。 详情请参阅原始问题报告。
[错误的目标地址是通过在正在向不正确的方向发送帧的访客VM中运行tcpdump来显示的。
实际上，通过压缩本地arp表使10.11.11.1的表观MAC地址与10.11.11.2的实际MAC地址相同，我就能够正确地确定帧的stream向。
所以我的问题是：在访客虚拟机或KVM主机中，什么机制都可能导致客机内核忽略本地路由表，并在10.11.11.1将数据包发送到（错误的）主机，即使10.11 .11.1未被列为目标networking的网关（10.8.0.0/24）？
注意：iptables在当时被禁用了。 我不知道在KVM主机上是否启用了ebtables，但是即使是这样，这也会导致guest虚拟机内核在10.11.11.1的方向发送数据包？
我注意到的一个行为是，如果我清除受影响的主机的ARP表并从10.8.0.0/24networking向受影响的主机发送ping请求，它将接收到请求，然后立即发送10.11.11.1的arp广播在10.11.11.1而不是10.11.11.2，因此10.8.0.0/24发送ping响应之前。 是什么导致它尝试10.11.11.1哪一个没有被指定为网关？
基于源或策略的路由可能？ Linux可以有几个路由表，并根据几个条件select使用哪一个路由表。 查看基于源代码路由的OpenVZ文档