[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Connecting vde and LAN
From: |
Henrik Nordstrom |
Subject: |
Re: [Qemu-devel] Connecting vde and LAN |
Date: |
Thu, 11 Aug 2005 16:56:22 +0200 (CEST) |
On Wed, 10 Aug 2005, Jim C. Brown wrote:
I was thinking that perhaps vde_packet could be modified to use a tap device
(for example tap0). Since the guests can't communicate to the address thats on
tap0, it doesn't matter what address it gets - the host address of tap0 and the
ip addresses of the guests don't even have to be on the same subnet.
So, the modified vde_packet would listen on the vde network and set packets
meant for the host (or other workstations on the LAN) to tap0. A route would be
set up so that the packets would be routed from tap0 to eth0, which would allow
the host to see them. On the other side, vde_packet would listen to eth0, and
intercept any packets meant for the guests and inject those into the vde
network.
Then we are back in the proxy-arp configuration situation which doesn't
really require any changes except proper routing and ip-forwarding setup
on the host. But it doesn't allow the guest Ethernet access to the LAN
(only IP access), and for the same reasons only unicast (broadcasts are
not routed).
I'm still learning how to create and manipulate tuntap devices so I haven't
been able to code this up yet. Are there any obvious problems that I missed
which would prevent this from working?
Yes, the fact that it is a separate network device on the host, fully
separate from eth0. Anything you send to the tap device is in fact like it
was recevied on another Ethernet interface by the host (lets say eth1).
Without bridgeing between the two it won't reach the real Ethernet, and
also in many situations the host will not be overly happy about seeing
traffic for it's eth0 address on the tap0 interface (rp-filter,
firewalling and a number of other minor tidbits will notice).
But since raw sockets does not allow you to send packets to the host there
is not much of a choice is there?
The following should work at the Ethernet level almost fully using the
already available tools, but requires some host configuration:
pcap (or raw socket): for receiving/sending to/from the LAN. This also
grabs broadcasts sent by the host.
tun device: for sending/receiving to/from the host.
1. Set up vde with both vde_pcap and a TUN/TAP tap device
vde_switch -tap tap0 -daemon
vde_pcap
2. Configure the VDE connected tap device with the same IP as the host has
on the LAN but a netmask of 255.255.255.255 (or /32 depending on your
taste). This makes the tap device a kind of "point-to-point Ethernet"
device.
ip addr add ip.of.host/32 dev tap0
ip link set tap0 up
3. Route the guest IP address to the tap device
ip route add ip.of.guest/32 dev tap0
This should work on Linux hosts. No idea about the viability on other host
flavors such as *BSD or Windows.
The above should work for most situations where the host is a just a host
on the LAN, but if the host is a LAN server for broadcast Ethernet
protocols such as DHCP some additional configuration of each such service
may be required to also listen on the tap0 device if the guest should be
able to use these services. Quite likely also applies to some other
protocols such as IPX or AppleTalk as these frames almost certainly will
be ignored by the host on the tap0 device unless configured proper for
each protocol.
Now, if only vendors could make the bridge setup easier to manage most of
this would be avoided.
Regards
Henrik