L2 redundant VPN
alter3d at alter3d.ca
Mon Jan 21 22:57:54 UTC 2013
Alternatively, just disable encryption by using "--cipher none" if you
only care about the L2 bridging and don't care about the encryption
aspect. You should get a huge performance boost through the tunnel and
it would be the same thing as dropping a dedicated circuit in there.
Of course, encryption is generally a Good Thing(tm), and the AES-NI
stuff is phenomenal, but it's not necessarily required in places where
you're just trying to get a link set up between 2 sites and you were
considering MPLS anyways.
On 01/21/2013 05:37 PM, Dan Olson wrote:
> Can you enable aes-ni on your openvpn servers? Any newer intel xeon
> chipset should support it, but it is usually disabled (bios) by default.
> There are more tuning tips at http://community.openvpn.net/openvpn/wiki/Gigabit_Networks_Linux
> ----- Original Message -----
>> From: "Tomas Podermanski" <tpoder at cis.vutbr.cz>
>> To: nanog at nanog.org
>> Sent: Monday, January 21, 2013 3:37:55 PM
>> Subject: L2 redundant VPN
>> Hi networking guys,
>> I need some help :-). We try to find for our department reliable
>> solution for L2 VPN. The task is to connect two remote data centers,
>> each of them connected two 1Gbps lines (with link aggregation). Only
>> connectivity between data centers is available (so there is no
>> possibility to create circuit based on MPLS or something like that).
>> basic problem is that high reliability is required, so the solution
>> to be fully redundant.
>> The initial idea was about two OpenVPN servers in each data center +
>> switches (HP E5800) joined into one logical switch via VRF. The link
>> failure is based on LACP packets between both data centers. The
>> solution works, however performance of OpenVPN is really creepy. The
>> maximum we were able to get from this configuration was about
>> We expect at least 500Mbps (or more in the future).
>> In our thoughts then we were thinking about l2tp on some
>> device, however there is little information about performance of that
>> solution and I am not sure how the failure detection would work in
>> redundant configuration.
>> Have anybody some experience with similar solution or at least any
>> idea ?
>> Thanks a lot for thoughts
More information about the NANOG