qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Contribution - L2TPv3 transport


From: Anton Ivanov (antivano)
Subject: [Qemu-devel] Contribution - L2TPv3 transport
Date: Fri, 28 Feb 2014 08:28:11 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130922 Icedove/17.0.9

Hi all,

On behalf of Cisco Systems I am authorized to contribute a new transport
to the network subsystem in qemu.

Specifically, we would like to contribute a new transport:

L2TPv3 static tunnel network transport.

Earlier versions of this (we have patchsets going back to qemu-1.0) have
been used extensively as a testing tool in our group and will be shipped
in product at a later date. We also use its counterpart designed for UML
in a soon to ship product.

The idea is quite simple - instead of inventing "yet another weird and
wonderful" encapsulation of the day for virtual transports, we use a
well established industry standard. Specifically we use L2TPv3 static
tunnels. This is very similar to what qemu has been doing in the storage
area for a long time (the iSCSI storage driver).

This allows:

1. Qemu to communicate with any other qemu, UML, router, firewall or
network device directly with no mediation by a virtual switch. Local and
remote.

2. Qemu to communicate with any modern linux distribution directly
(including communicating with containers). Local and remote.

3. Qemu to communicate with the local host, remote vms, network devices,
etc at speeds which for a number of use cases exceed the speed of the
legacy tap driver.

Our suggestion would be that this over time obsoletes the UDP variety of
the "socket" driver. It has a number of advantages over that driver:

    * Standard compliant - RFC 3931 updated recently by RFC 5641
    * Supported on most network equipment
    * Allows to move virtual switching off-host to a high performance
physical switch if needed
    * Allows to mix virtual and physical switching (well supported on
modern Linuxes and other OSes)
    * Well researched security profile as well as established
interactions with IPSEC allowing to extend virtual networks outside the
datacenter to remote physical devices and/or VMs.

This transport uses a linux specific call to get several GBit RX rate.
This call can be wrapped (at some cost) in a compatibility loop using
posix compliant recvmsg instead for other systems. As I am not familiar
with the fine details on how to add linux specific, windows specific,
etc bits to qemu I have decided to leave that bit out for the time being
and submit it "as we use it".

Patch attached.

Best Regards,

Anton

Attachment: l2tpv3.diff
Description: l2tpv3.diff


reply via email to

[Prev in Thread] Current Thread [Next in Thread]