It’s the routing table, stupid!

It only took three years for the frustration to build up sufficiently. :-) Finally I went a little deeper to try to solve the mystery of the 30 second hang time before requests to my Linux guest VM would return. I love doing testing on a Linux guest VM via VirtualBox while working on my Mac, but the occasional slow down (with no load on the VM) drove me to the brink of madness.

I had assumed for a while that it was some complicated (potentially Mac-related) DNS asshattery. No. It’s the routing table, stupid! I finally noticed that this wasn’t right at all.

$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.1.1 0.0.0.0 UG 100 0 0 eth2
10.0.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth3
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 eth3
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth2
192.168.56.0 192.168.56.1 255.255.255.0 UG 0 0 0 eth4
192.168.56.0 0.0.0.0 255.255.255.0 U 0 0 0 eth4

So after some fiddling, I added this to my /etc/rc.local:

route -v add -host 192.168.56.2 gw 192.168.56.1 eth4
route -v del -net 192.168.56.0/24 gw 0.0.0.0 eth4

It is a host-only interface after all. Now the table looks far more sensible.

$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.1.1 0.0.0.0 UG 100 0 0 eth2
10.0.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth3
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 eth3
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth2
192.168.56.0 0.0.0.0 255.255.255.0 U 0 0 0 eth4
192.168.56.2 192.168.56.1 255.255.255.255 UGH 0 0 0 eth4

Hope that helps someone in the same boat.