I wanted to assign an external IP address to my KVM guest and went the bridged networking way. Unfortunately the guest has no network connectivity and I don't know why. After investigating it seems that it doesn't get any reply for it's ARP requests.

I have one physical interface: eth0, the bridged interface: br0 and the tap interface: tap0 brought up by qemu-ifup script by kvm. The host machine runs the latest Ubuntu Server. The guest machine runs GKRML live-cd (based on slackware).

What could be a potential problem is that the host machine and the guest machine are in the different networks. Unfortunately both IP addresses were assigned to me by the datacenter and I cannot change them.

Configuration details follow. Below xx.xx are the same for both host and guest.

Host's /etc/network/interfaces:

# Loopback device:
auto lo
iface lo inet loopback

# Device: eth0
auto eth0
iface eth0 inet manual

# Device: br0
auto br0
iface br0 inet static
  address   xx.xx.110.69
  network   xx.xx.110.64
  broadcast xx.xx.110.95
  gateway   xx.xx.110.65
  bridge_ports eth0
  bridge_fd 9
  bridge_hello 2
  bridge_maxage 12
  bridge_stp off

Host's routing table:

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
xx.xx.110.64 U     0      0        0 br0         xx.xx.110.65         UG    100    0        0 br0

Host's /etc/qemu-ifup scirpt (unmodified, shipped with qemu package):

switch=$(/sbin/ip route list | awk '/^default / { print $5 }')
/sbin/ifconfig $1 up
/usr/sbin/brctl addif ${switch} $1

Output of brctl show while the guest is running:

bridge name     bridge id               STP enabled     interfaces
br0             8000.4061862b90d5       no              eth0

KVM commandline:

kvm -cdrom grml_2009.10.iso -boot d -m 256 -vnc localhost:0 -net nic,macaddr=DE:AD:BE:EF:11:14 -net tap,script=/etc/qemu-ifup

Guest machine network setup (single eth0 interface):

$ ifconfig eth0 xx.xx.129.69/28 up
$ route add default gw xx.xx.129.65

Result of tcpdump -i tap0 while trying to ping anything from the guest:

tcpdump: WARNING: tap0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tap0, link-type EN10MB (Ethernet), capture size 96 bytes
23:38:13.659655 ARP, Request who-has xx.xx.129.65 tell xx.xx.129.69, length 28
23:38:14.659687 ARP, Request who-has xx.xx.129.65 tell xx.xx.129.69, length 28
23:38:15.659655 ARP, Request who-has xx.xx.129.65 tell xx.xx.129.69, length 28
23:38:16.666350 ARP, Request who-has xx.xx.129.65 tell xx.xx.129.69, length 28
23:38:17.666319 ARP, Request who-has xx.xx.129.65 tell xx.xx.129.69, length 28
23:38:18.666324 ARP, Request who-has xx.xx.129.65 tell xx.xx.129.69, length 28

... and so on without reply.

Thanks in advance for any help!

  • 1
    ARP requires routing to work also. A common problem is that you have both an IP address assigned to your bridge device (here br0) and to your other interface (eth0) in the same subnet. If you do this ARP replies break. Make sure that you have a clean, single route back to the subnet.
    – EdH
    Feb 12, 2015 at 17:35
  • In my case I forgot to add the tap0 (or equivalent for your system) to the bridge.
    – Bacon
    Oct 18, 2018 at 12:46

2 Answers 2

  1. Are you running iptables? If so, have you enabled bridge traffic? For example the following is one solution that works on Fedora/Red Hat:

iptables -F FORWARD

iptables -I FORWARD -m physdev --physdev-is-bridged -j ACCEPT

iptables-save > /etc/sysconfig/iptables

  1. Have you enabled IPv4 forwarding in sysctl.conf? Again on Fedora/Red Hat in /etc/sysctl.conf you need to set

net.ipv4.ip_forward = 1

  • Thank you very much for your reply. I have ipv4 forwarding enabled in /proc/sys and I've entered the iptables rule you've pasted but it's still not working. I've even deleted all my iptables rules and set all chains to ACCEPT policy - still, no luck.
    – MasterM
    Aug 1, 2010 at 18:00

your guest is in one network, and the host in another. The traffic goes through the tap device and bridge to eth0, is it supposed and expected to be able to reach the xx.xx.129.69/28 network at all? The typical working setup would be to have the bridge IP and the VM's attached to it in the same network, and if you want the host not to see that network, leave the bridge without an IP at all. You can follow the flow through by checking tcpdump on the bridge itself, and possibly on the underlying eth0

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .