public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Tom Lendacky <tahm@linux.vnet.ibm.com>
To: J L <lists@rrod.net>
Cc: kvm@vger.kernel.org
Subject: Re: Multiple TAP Interfaces, with multiple bridges
Date: Wed, 3 Feb 2010 11:10:50 -0600	[thread overview]
Message-ID: <201002031110.50628.tahm@linux.vnet.ibm.com> (raw)
In-Reply-To: <15f314a41002030856o70066267pc2e8f2b768fd3d83@mail.gmail.com>

On Wednesday 03 February 2010 10:56:43 am J L wrote:
> Hi,
> 
> I am having an odd networking issue. It is one of those "it used to
> work, and now it doesn't" kind of things. I can't work out what I am
> doing differently.
> 
> I have a virtual machine, started with (among other things):
>   -net nic,macaddr=fa:9e:0b:53:d2:7d,model=rtl8139 -net
> tap,script=/images/1/ifup-eth0,downscript=/images/1/ifdown-eth0
>   -net nic,macaddr=fa:02:4e:86:ed:ce,model=e1000 -net
> tap,script=/images/1/ifup-eth1,downscript=/images/1/ifdown-eth1
> 

I believe this has to do with the qemu vlan support. If you don't specify the 
vlan= option you end up with nics on the same vlan. You need to assign the two 
nics to separate vlans using vlan= on each net parameter, eg:


   -net nic,vlan=0,macaddr=fa:9e:0b:53:d2:7d,model=rtl8139 -net
 tap,vlan=0,script=/images/1/ifup-eth0,downscript=/images/1/ifdown-eth0
   -net nic,vlan=1,macaddr=fa:02:4e:86:ed:ce,model=e1000 -net
 tap,vlan=1,script=/images/1/ifup-eth1,downscript=/images/1/ifdown-eth1

Try that and see if you get the results you expect.

Tom

> The ifup-ethX script inserts the tap interface into the correct bridge
> (of which there are multiple.)
> 
> The Virtual Machine is Centos 5.3, with a 2.6.27.21 kernel. The Host
> is Ubuntu 9.10 with a 2.6.31 kernel.
> 
> 
> My network then looks like:
> 
> The Virtual Machine has an eth0 interface, which is matched with tap0
> on the host.
> The Virtual Machine has an eth1 interface, which is matched with tap1
> on the host.
> 
> The host has a bridge br0, which contains tap0 and eth0.
> The host has a bridge br1, which contains tap1.
> 
> There is a server on the same network as the Host's eth0.
> 
> The Virtual Machines eth0 interface is down.
> The Virtual Machines eth1 interface has an IP address of 192.168.1.10/24.
> The Virtual Machine has a default gateway of 192.168.1.1.
> 
> The host's br0 has an IP address of 192.168.0.1/24.
> The host's br1 has an IP address of 192.168.1.1/24.
> 
> The server has an IP address of 192.168.0.20/24, and a default gateway
> of 192.168.0.1.
> 
> Firewalling is disabled everywhere. I have allowed time for the
> bridges and STP to settle.
> 
> 
> 
> If I go to the Virtual Machine, and ping 192.168.0.20 (the server), I
> would expect tcpdumps to show:
>   * VM: eth1, dest MAC of Host's tap1/br0
>   * Host: tap1, dest MAC of Host's tap1/br0
>   * Host: br1, dest MAC of Host's tap1/br0
>   * Host now routes from br1 to br0
>   * Host: tap0, no packet
>   * Host: br0, dest MAC of Server
>   * Host: eth0, dest MAC of Server
>   * Server: eth0, dest MAC of Server
> 
> What I actually get:
>   * VM: eth1, dest MAC of Host's tap1/br0
>   * Host: tap1, dest MAC of Host's tap1/br0
>   * Host: br1, dest MAC of Host's tap1/br0
>   * Host should, but does not route from br0 to br1
>   * Host: tap0, dest MAC of ***Host's tap1/br0***
>   * Host: br0, dest MAC of ***Host's tap1/br0**
>   * Host: eth0, no packet
>   * Server: eth0, no packet
> 
> As you can see, the packet has egressed *both* tap interfaces! Is this
> expected behaviour? What can I do about this?
> 
> 
> 
> 
> If I remove tap0 from the bridge, I then get:
>   * VM: eth1, dest MAC of Host's tap1/br0
>   * Host: tap1, dest MAC of Host's tap1/br0
>   * Host: br1, dest MAC of Host's tap1/br0
>   * Host should, but does not, route from br0 to br1
>   * Host: tap0, no packet
>   * Host: br0, no packet
>   * Host: eth0, no packet
>   * Server: eth0, no packet
> 
> This is the other half of my problem: in this case, with effectively
> only one tap, the host is not routing between br1 and br0. The packet
> just gets silently dropped. Does anyone know what I am doing wrong?
> 
> I hope I have managed to explain this well enough!
> 
> Thanks,
> --
> Jarrod Lowe
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

  reply	other threads:[~2010-02-03 17:10 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-03 16:56 Multiple TAP Interfaces, with multiple bridges J L
2010-02-03 17:10 ` Tom Lendacky [this message]
2010-02-03 17:16 ` arnd
2010-02-03 17:44   ` J L

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201002031110.50628.tahm@linux.vnet.ibm.com \
    --to=tahm@linux.vnet.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=lists@rrod.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox