| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] Xend vnet support to be removed
James Harper wrote:
Based on the description from your documentation, it sounds like the
guts of vnets could be done with 802.1q vlan trunking and bridging. No
extra code required. I'm already doing this now, where each xen server
has two physical interfaces (one for AoE, and one for domu network
access). I can provide some more information on 802.1q vlan trunking if
anyone is interested.
I'm basing all of my knowledge of vnets on a brief skim of the
documentation in your email below, so feel free to enlighten me as to
why they are different :)
In terms of abstract functionality they are very similar,
but there are important practical differences.
As far as I am aware, use of vlans requires that you have vlan-capable
switches in your network, and that you can configure them. Ordinary mortals
can't usually configure their network's vlan switches (if it has them).
Vnets don't require any assistance from the network,
and can be tunneled to remote subnets or through firewalls.
This is because vnets tunnel ethernet frames inside IP packets, which are
then routed normally, rather than using a modified ethernet frame like the
802.1q vlan header.
So a vnet can be created by anyone and its connectivity can span an
arbitrary piece of the IP network - not something you can do with vlans
It's also possible to run completely independent vnet infrastructures on the
same network simply by using different multicast addresses.
A new vnet can be dynamically created by configuring its endpoints, without
configuring anything in the network.
Vlan packets are limited to a 12-bit vlan id and have no support for
authentication or encryption. Vnets support 128-bit vnet ids and can
support authentication and encryption, currently using IPSEC.
Mike
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home