While debugging a problem with the networking configuration for a set of virtual machines running under KVM, I discovered a circumstance where the kernel in the guest VM has decided to stamp the outgoing Ethernet frame with a destination address that is in conflict with the address it would choose if it was respecting with the kernel IP route table.

So, in that example, I expected the outbound frame to be delivered to de:ad:be:3b:24:48 which corresponds to the host that owns the IP address and that owns a route to

What actually happened is that the kernel decided to stamp the frame with a destination of 00:10:db:ff:70:01 which sent the frame in the direction of which doesn't know how to route to and as a result the packet was dropped.

This decision was in contravention of the local routing table that clearly specified that the route to was via See the original problem report for details.

[The incorrect destination address was visible by running tcpdump in the guest VM that was sending the frame in the incorrect direction.].

In fact, by kludging the local arp table to make's apparent MAC address to be identical to's actual MAC address, I was able to get the frame flowing in the correct direction.

So my question is: what mechanism, in either the guest VM or the KVM host, could cause the guest kernel to ignore the local route table and send the packet in a frame towards the (incorrect) host at, even though wasn't listed as a gateway for the destination network (

Note: iptables was disabled in the guest at the time. I don't know if ebtables is enabled in the KVM host, but even if it was, how would this cause the kernel in the guest VM to want send the packet in the direction of

One behaviour I did notice is that if I purge the ARP tables of the affected host and send a ping request to the affected host from the network, it receives the request, then sends an arp broadcast for immediately prior to sending the ping response in the direction of instead of and hence What is causing it to try which is not specified as a gateway?


Source or Policy based routing maybe? Linux can have several routing tables and choose which one to use based on several conditions. Check out the OpenVZ documentation on Source based routing

  • Thanks. As far as I know, in my particular case, there is no source based routing configured anywhere on the hosts (client, VPN server, LAN server) in my domain, so I don't think this explains the issue. – jonseymour Mar 14 '12 at 9:25
  • Mmmm. Ok, so perhaps policy based routing is a factor here. When I run ip rule show, I get this: 0: from all lookup 255 32764: from lookup route_eth1 32765: from lookup route_eth0 32766: from all lookup main 32767: from all lookup default How do I inspect these tables, I wonder? – jonseymour Mar 14 '12 at 9:29
  • ip route list table $id as per man ip(8) – ptman Mar 14 '12 at 9:35
  • Ok, so this perhaps has provided the answer: /etc/sysconfig/network-scripts/route-eth0 has an entry of this kind: default table route_eth0 via dev eth1 I suspect if I edit that to be I'll get the desired behaviour without the arp hack. Let's see! – jonseymour Mar 14 '12 at 9:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.