[Qemu-devel] Two taps, same IP?

[David Barrett]

I'm considering a tap-based alternative to the -redir patch I proposed 
earlier, but I'm just not quite getting how it works.  In particular, 
I'm able to access the webserver on one image just fine, but not the 
other: wget fails with "Connecting to 172.20.0.3:80... failed: No route 
to host."

Can you explain why and set me straight?

Specifically, I have two Debian qemu images (0 and 1), identical in all 
respects except that image0 and image1 are configured to use static IPs 
172.20.0.2 and 172.20.0.3, respectively.  I've launched both 
simultaneously with the following commands:

sudo qemu -kernel-kqemu -net nic,vlan=0 -net tap,vlan=0 image0.raw
sudo qemu -kernel-kqemu -net nic,vlan=0 -net tap,vlan=0 image1.raw

Each image is configured with the following /etc/network/interfaces:

auto lo
iface lo inet loopback
allow-hotplug eth0
iface eth0 inet static
address 172.20.0.2  <--- image1 has: address 172.20.0.3
netmask 255.255.0.0
gateway 172.20.0.1

This creates two tap interfaces (0 and 1) on the Ubuntu host, curiously 
with the same IP:

tap0      Link encap:Ethernet  HWaddr 00:ff:84:12:9d:72
          inet addr:172.20.0.1  Bcast:172.20.255.255  Mask:255.255.0.0
          inet6 addr: fe80::2ff:84ff:fe12:9d72/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:18 errors:0 dropped:0 overruns:0 frame:0
          TX packets:36 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:500
          RX bytes:1336 (1.3 KB)  TX bytes:4704 (4.5 KB)

tap1      Link encap:Ethernet  HWaddr 00:ff:af:9a:48:29
          inet addr:172.20.0.1  Bcast:172.20.255.255  Mask:255.255.0.0
          inet6 addr: fe80::2ff:afff:fe9a:4829/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:24 errors:0 dropped:0 overruns:0 frame:0
          TX packets:34 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:500
          RX bytes:1656 (1.6 KB)  TX bytes:4664 (4.5 KB)

"wget http://172.20.0.2"; and "wget http://172.20.0.3"; each work fine 
inside their respective VMs.  But each is unable to wget the other's 
webserver.

Furthermore, and most unusual, the host is able to wget image0's 
webserver fine, but not image1.  Specifically, the second wget fails as 
follows:

address@hidden:/svn/staging$ wget http://172.20.0.3
--18:17:12--  http://172.20.0.3/
           => `index.html.1'
Connecting to 172.20.0.3:80... failed: No route to host.
address@hidden:/svn/staging$

The error message suggests some sort of routing problem, and the routing 
table is:

address@hidden:/svn/staging$ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use 
Iface
68.28.57.85     *               255.255.255.255 UH    0      0        0 ppp0
172.20.0.0      *               255.255.0.0     U     0      0        0 tap0
172.20.0.0      *               255.255.0.0     U     0      0        0 tap1
default         *               0.0.0.0         U     0      0        0 ppp0
address@hidden:/svn/staging$

However, I'll admit I don't know much about the routing layer and thus 
I'm not sure how to diagnose beyond that.  But it seems very strange to 
me to have two network interfaces with the same IP.

With this in mind, if I shut down image0, the tap0 interface goes away, 
and now the wget to image1 works fine.  Again, this is suggesting 
there's some kind of conflict where the second tap interface is somehow 
"blocked" by the first.

Anyway, that's as far as I can get.  Is this supposed to work and am I 
doing something wrong?  Or am I supposed to do launch the second image 
with some other kind of command line?  Should I manually create my own 
tap devices before launching either image (and if so, any pointers on 
how I go about doing that)?

(Incidentally, I've tried putting the second image onto a different vlan 
by replacing both "vlan=0" with "vlan=1" in image1's launch command, but 
that had no effect -- the results were identical.)

Thanks for any tips you can provide!

-david