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