# KVM bridge not passing traffic, but the host can ping VMs

## MrTiredMan

My problem is that after a reboot of the server with two VMs, the VMs are now unable to have network access.  

(I rebooted the server in an attempt to update the kernel, but it's not right and kept rebooting during bootup, so I've gone back the previous kernel.  Plus I just went true the battle of Udev 182-r2 and LVM 2.02.95 of making the system unbootable since I don't use an initrd on this box.  So basically I've been battling the box for several hours...)

Here's my current net config:

```

bridge_br0="eth0 qtap0 qtap1"

brctl_br0="setfd 0 sethello 0 stp off"

rc_net_br0_need="net.qtap0 net.qtap1"

#rc_need_br0="net.qtap0 net.qtap1"

dhcp_br0="nodns"

config_br0="dhcp"

config_eth0="null"

dns_servers="127.0.0.1"

config_qtap0="null"

tuntap_qtap0="tap"

tunctl_qtap0="-u mrtiredman"

mac_qtap0="52:54:00:12:34:89"

config_qtap1="null"

tuntap_qtap1="tap"

tunctl_qtap1="-u mrtiredman"

mac_qtap1="52:54:00:11:be:ef"

```

The host system runs BIND, so the VMs can resolve IP address, but are unable to ping out to the local network.  The KVM host system is able to ping the VMs, but no other systems on the network are.

It is as if the bridge br0 is not passing traffic through.

What am I missing?  I've even gone through the point of taking out the tap stuff, and have the same startup script the VMs make the calls to tunctl and such for the tap devices, but no change.  Like below:

```

#/usr/bin/tunctl -u mrtiredguy -t qtap0

#/sbin/brctl addif br0 qtap0

#/bin/ifconfig qtap0 up 0.0.0.0 promisc

/usr/bin/qemu-kvm -cpu host -net nic,model=virtio,macaddr=52:54:00:12:34:89 -net tap,script=no,ifname=qtap0 -drive file=/dev/raid6/2008r2,if=virtio,cache=none -smp 4 -m 32768 -vnc :1 &

```

Both IPtables and EBtables are cleared, no rules in either and policies set to ACCEPT.

Again, this was working fine before until I attempted to update the kernel, udev, and LVM (along with some other stuff).

----------

## nativemad

Hi, 

as rc_net_br0_need don't have eth0 in it, it could be that br0 gets started before eth0 is ready... 

Is eth0 a member of br0 now?

```
#brctl show
```

HTH, Cheers

----------

## cach0rr0

here's one significant problem

the mac you define for your tap adapters in /etc/conf.d/net should NOT be the same mac you specify on the kvm command line 

from my own working setup:

```

mac_tap0="52:54:00:12:34:56"

```

```

qemu-kvm -drive file=/kvm/images/web/nginx.img,if=virtio,boot=on -net nic,model=virtio,macaddr=00:1d:92:ab:3f:77 -net tap,ifname=tap0,script=no,downscript=no -m 512 -vnc 127.0.0.1:5 -balloon virtio

```

ill bet if you were to check dmesg you'd see heaps of complaints about buggered ARP requests. 

For a completely working example, this is my full /etc/conf.d/net

```

bridge_br0="eth0 tap0 tap1 tap2 tap3"

brctl_br0="setfd 0" "sethello 0" "stp off"

rc_need_br0="net.tap0 net.tap1 net.tap2 net.tap3"

config_br0="192.168.1.85/24"

routes_br0="default via 192.168.1.1"

dns_servers_br0="192.168.1.1"

config_tap0="null"

tuntap_tap0="tap"

tunctl_tap0="-u meat"

mac_tap0="52:54:00:12:34:56"

config_tap1="null"

tuntap_tap1="tap"

tunctl_tap1="-u meat"

mac_tap1="52:54:00:12:34:57"

config_tap2="null"

tuntap_tap2="tap"

tunctl_tap2="-u meat"

mac_tap2="52:54:00:12:34:58"

config_tap3="null"

tuntap_tap3="tap"

tunctl_tap3="-u meat"

mac_tap3="52:54:00:12:34:59"

config_eth0="null"

```

and then my command-line for my VM's

```

#!/bin/bash

/usr/bin/sudo /usr/bin/qemu-kvm -drive file=/kvm/images/web/nginx.img,if=virtio,boot=on -net nic,model=virtio,macaddr=00:1d:92:ab:3f:77 -net tap,ifname=tap0,script=no,downscript=no -m 768 -vnc 127.0.0.1:5 -balloon virtio &

sleep 30

/usr/bin/sudo /usr/bin/qemu-kvm -drive file=/share/kvm-img-backup/mail/postfix.img,if=virtio,boot=on -net nic,model=virtio,macaddr=00:1d:92:ab:3f:78 -net tap,ifname=tap1,script=no,downscript=no -m 512 -vnc 127.0.0.1:6 -balloon virtio &

```

So you see how this pieces together, ifconfig -v from the host OS

```

tap0      Link encap:Ethernet  HWaddr 52:54:00:12:34:56  

          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1

          RX packets:26395657 errors:0 dropped:0 overruns:0 frame:0

          TX packets:15896868 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:500 

          RX bytes:37886244874 (35.2 GiB)  TX bytes:2167565562 (2.0 GiB)

```

and ifconfig -v from within the guest OS

```

eth0      Link encap:Ethernet  HWaddr 00:1d:92:ab:3f:77  

          inet addr:192.168.1.80  Bcast:192.168.1.255  Mask:255.255.255.0

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:15829574 errors:0 dropped:0 overruns:0 frame:0

          TX packets:26395679 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000 

          RX bytes:2152759884 (2.0 GiB)  TX bytes:37886247286 (35.2 GiB)

```

notice the MAC address on each, and how it corresponds to what ive set/run within the host OS  :Smile: 

I've pulled the mac addresses out of thin air; they are arbitrary, and not important, so long as they are valid, and different between what's defined in /etc/conf.d/net and what's defined on the kvm command line 

ip forwarding in sysctl should of course be enabled. 

I do have FORWARD and OUTPUT set to 'ACCEPT' as a default policy in iptables on the host OS, with the former being most important 

other than that...i just have net.br0 in my default runlevel, with the above /etc/conf.d/net, and i can start my KVM guests with the exact command line bits you see above

hope that helps

----------

## Ant P.

You might need to double-check sysctl net.ipv4.ip_forward and net.ipv4.conf.all.forwarding. My KVMs were broken like this recently and it turned out to be that.

----------

## MrTiredMan

cach0rr0, you're a life saver!  It was the MAC address duplication for the KVM guest and the tap devices.  The fix was to assign different MAC addresses for all the tap devices and VMs.  When I get a chance I'll add the correction/note to the Gentoo Wiki.  http://en.gentoo-wiki.com/wiki/KVM

----------

## Mad Merlin

FWIW, you don't need to explicitly assign MAC addresses to your tap devices. The kernel will pick a valid random one if it isn't specified.

Edit: You do, of course, need to specify MAC addresses for the guest interfaces (that is, on the KVM command line), if you run more than one VM (there is a default MAC address for the guest interface).

----------

