VDE experimental version new features.
(The code of the experimental version is in the svn repository under the
branch named rd235)
------------------------------------------------------------
* Portgroups
This is a new way to assign ports to VLAN. It was already possible to
assign ports to VLANS py pre-configuring some ports. E.g. the following
commands configure port 1 to belong to vlans 2 (untagged), 3 and 4 (tagged).
port/create 1
port/setvlan 1 2
vlan/addport 3 1
vlan/addport 4 1
A new command of the "port" group provides a quicker way to define the
vlans. The same example above is:
port/create 1
port/vlansetup 1 u2t3t4
it is also possible to add commas,
port/vlansetup 1 u2,t3,t4
The main problem of this approach is that the user must pre-configure the
ports and remember the mapping between each port and its characteristics.
The service requiring vlan 2, 3 and 4 defined as above *must* be connected
to port #1. This approach is consistent with the mapping of vlan to ports
in the real (physical) Ethernet switches, but it is not convenient for
virtual switches.
A portgroup is a "label" assigned to a specific vlan assignment. A
client program (e.g. a virtual machine) can specify the portgroup to
be connected to. If the client has the rights to join the portgroup a
port is dynamically allocated and configured as requested.
Erroneous requests in the portgroup definition, like the request to add the
port to a non-existent vlan, will result in an abortion of the portgroup
assignment.
E.g. We can assign the label "lab42" to the same vlan assignment of the
previous example:
portgroup/add lab42 u2t3t4
the addportgroup can have 2 to 4 arguments:
- the first argument is the name of the portgroup (the first character
of the portgroup name cannot be a number).
- the second argument is the vlan assignment, expressed by the same syntax
of the vlansetup command, as previously explained.
- the third argument (optional) is an octal number which encodes the
permissions on the portgroup, as in chmod
- the fourth argument (optional) is the (UNIX) group as in chgrp.
The group ownership and access mode will be the same defined for the
whole switch, e.g. by commandline options -m and -g, if not otherwise specified.
E.g. All clients connected to "lab42" ports will join a port which belongs
to vlans 2 (untgged), 3 and 4 (tagged). Only processes of users in the group
named
lab42users group can use lab42 ports.
ds/addportgroup lab42 u2t3t4 660 lab42users
The portgroup command interface includes also a command to delete a
portgroup definition:
portgroup/del lab42
and a command to list the portgroups:
portgroup/list
------------------------------------------------------------
* vde_plug: new syntax to connect two local switches.
Now the tool vde_plug supports two libvdeplug targets:
e.g.
vde_plug /tmp/sw1 /tmp/sw2
connects the switch /tmp/sw1 to the switch /tmp/sw2
------------------------------------------------------------
* vde_plug: support for "baby giant" packets
The MTU supported by vde_plug has been extended to 1600 bytes to allow the
transit of trill packets and to be ready for other future features.
------------------------------------------------------------
* libvdeplug: new features and syntax overview
libvdeplug is the unified interface used by clients to get connected to
vde_switches.
The current version of libvdeplus provides several options for the
connectivity. The examples use "vde_plug", but the same syntax can be used
wherever the "switch name" is requested, e.g. parameters for user-mode
linux, qemu-kvm or virtuabox.
* default switch:
When the name of the switch is empty libvdeplug tries to connect the
client to a standard switch (/var/run/vde.ctl or /tmp/vde.ctl).
(the switch can be either a vde_switch or a kvde_switch)
* named switch:
When the name of the switch is a pathname of a switch (i.e. the path of
the switch directory for vde_switch or the the path of the ipn socket for
kvde_switch), the client gets connected to that switch.
* named switch and preconfigured port:
If the name of the switch is followed by a number enclosed in square
brachets (e.g. /tmp/myvde[4]) the client gets connected to the specified
switch (/tmp/myvde) using the port #4.
* portgroup of named switch:
If the name of the switch is followed by a name enclosed in square
brackets (the first character of the name is *not* a number), then the
client gets connected to the switch using the name inside the brackets
as
portgroup (e.g. /tmp/myvde[lab42] means portgroup lab42 of the switch
/tmp/myvde
* female socket for point to point link:
If the name ends in "[]", i.e. two square brackets without any symbol in
between, e.g. /tmp/yyy[], libvdeplug defines a "female socket" for a
point to point connection. The client is not connected to any switch.
The pathname before the brackets can be used by another client using
libvdeplug as if it were the path of a switch to create a point to point
connection.
* UDP connection:
If the name has the form host:port->host:port. E.g.
0.0.0.0:2222->10.1.2.3:4444
or
127.0.0.1:3333->127.0.0.1:5555
libvdeplug uses UDP to communicate, the first address and port is for
the
local bind, the second address and port is the remote peer.
Hostnames can be used instead of IP addresses, libvdeplug is able to use
both ipv4 and ipv6. e.g.:
[::]:2222->[::1]:4444
0.0.0.0:3333->host.domain.org:5555
On the other end of the communication the hostnames and ports must be
reverted. For example using vde switch a local UDP connection is:
vde_plug "127.0.0.1:3333->127.0.0.1:5555"
and:
vde_plug "127.0.0.1:5555->127.0.0.1:3333"
please note the need the double quote to protect the argument, as the
shell would interpretate the '>' symbol as an output redirection.
a remote UDP connection can be:
An insecure connection between two remote hosts can be set up by
vde_plus as
follows:
host A.domain.org:
vde_plug /tmp/myAswitch "0.0.0.0:4444->B.domain.org:4444"
and on host B.domain.org:
vde_plug /tmp/myBswitch "0.0.0.0:4444->A.domain.org:4444"
All the network traffic will be sent in clear and there is no access
control. Cryptcab and dpipe/ssh can be used to set up secure channels.
This option can be used as a interconnection tool to other networking
simulation and emulation environments like gns3.
------------------------------------------------------------
* Vtrill
Vtrill is an implementation of a routing bridge (see Radia Perlman
"Rbridges: Transparent Routing").
VDE+vtrill keeps the plug and play transparency of bridges or switches but
packets get routed.
Each VDE switch using vtrill self assign a 16bit nickname.
A OSI IS-IS implementation, i.e. a link state routing algorithm,
uses the nicknames to keep an updated map of the entire network and
to compute the shortest paths (and some spanning trees for broadcasts).
vtrill packets use an Ethernet header and a specific header to wrap the
original packets. Vtrill packets are Ethernet packets.
Using vtrill is quite simple.
vtrill needs a VPN, vtrill ports must use that VPN in tagged mode and
no untagged VPN.
It is possible to create a specific portgroup.
In my tests I used a rc file like this:
vlan/create 1
vlan/setvtrill 1
portgroup/add vtrill u4095,t1
The three commands mean: create the vlan #1, set VLAN #1 as the vtrill vlan,
and define the vtrill portgroup (no untagged, VLAN1 tagged).
Start a number of vtrill enabled vde_switch:
vde_switch -f rc .....
e.g.
vde_switch -f rc /tmp/aa
vde_switch -f rc /tmp/bb
vde_switch -f rc /tmp/cc
vde_switch -f rc /tmp/dd
connect the switches using your preferred topology.
e.g. this is a "square" network.
vde_plug /tmp/aa[vtrill] /tmp/bb[vtrill]
vde_plug /tmp/bb[vtrill] /tmp/cc[vtrill]
vde_plug /tmp/cc[vtrill] /tmp/dd[vtrill]
vde_plug /tmp/dd[vtrill] /tmp/aa[vtrill]
Obviously the tests can use remote switches:
dpipe vde_plug /tmp/aa[vtrill] = ssh remote.machine.org vde_plug
/tmp/zz[vtrill]
After a few tens of seconds (delays are tunable) the entire network
will be up and running.
The set of vtrill connected switches can be considered and used as they were
one distributed switch.
You can see the "view" of vtrill by typing the folowing commands:
vtrill/portprint: this shows the local reachability, the vtrill neighbors
vtrill/nodeprint: this prints the list of the vtrill nodes and the
first hop
to use to reach each one of them.
THe current implementation supports pure vtrill links, without nodes on them.
I mean that vtrill links are just infrastructure links, nodes must be
connected on other ports.
It should be possible to manage "hybrid" links, but I am uncertain if
this is really useful.
Vtrill still does not support LAN pseudo nodes. This means that vtrill
infrastructure links do not need to be point to point, a hub or a switch
can create a vtrill multipoint link. In this latter case each node
sees a point to point link to each other node connected on the multipoint link.
(IS-IS pseudo nodes provide a simpler mapping for this topology).
I have not implemented any broadcast optimization yet.
Broadcast packets use one of the five trees computed by the algorithm.
It is possible to implement caches for ARP, Router/Neighbor Advertisements to
reduce the amount of broadcast messages. It is in the to-do file.
Vtrill does automatic trunking: when there are several minimal
paths to a destination node, vtrill uses all the paths using a round robin
policy.
ciao
renzo
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
vde-users mailing list
vde-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/vde-users
