All of lore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.