lagg with lacp from two tap

Hi
It is possibe to run lagg0 interface with lacp protocol from two tap0-tap1 interfaces?
tap interfaces used by OpenVpn.
I trying, but laggport flag not changed to active.

In failover proto work fine!

All offload options i removed from physical bge0 and bge1 interfaces by ifconfig -tso -tso4 -lro etc...
I tested lacp work if i create lagg0 from physical bge0-bge1 (so lacp functional in my system), but not over tap.
 
I want use lacp without switch (freebsd to freebsd via openvpn).
Can you explain this? FreeBSD to FreeBSD = directly back-to-back connected servers don't need OpenVPN.

If not back-to-back connected, there is a switch in between. But yes, if you want to use LACP over OpenVPN virtual interfaces, LACP does not need to be configured on the switch ports.

I'm not very familiar with OpenVPN but it seems they use tun and/or tap interfaces and tap are L2 interfaces while tun are L3 interfaces. Can you share your relevant configuration?

Perhaps redundant layer-3 connections via OpenVPN is better than a virtual LACP channel over to OpenVPN tunnels. What is the goal of this setup?
 
6490



I want to connect openvpn between two servers via two physical independent interfaces (bge).
In result a have two network interfaces tap0+tap1 on each server.
If i construct from tap interfaces, one lagg0 interface (in laggproto failover) it work (lagg0 select first active tap0 as path by default).
But if i construct lagg0 (in laggproto lacp) it not work (two laggport not change status and lagg0 not selected active path).
I want lacp features like failover and loadbalance (if i lost for example physical connection on bge0).
 
I want lacp features like failover and loadbalance (if i lost for example phisical connection on bge0).
Then put the lagg(4) on the physical interfaces. What's the point of load-balancing a VPN connection if both tunnels pass over the same upstream connection?
 
Then put the lagg(4) on the physical interfaces. What's the point of load-balancing a VPN connection if both tunnels pass over the same upstream connection?
I show my test system, in production this work throught internet (why in this point i need openvpn).
If i use lagg0 from two physical interfaces, it work (without tap0+tap1 interfaces).
I want determine, tap interfaces not capable to work with lacp, or i make error.
 
I show my test system, in production this work throught internet (why in this point i need openvpn).
So, both VPN tunnels pass over the same uplink. Then load-balancing is rather pointless as both tunnels will need to share the same uplink bandwidth. One single VPN tunnel will be able to use all available bandwidth, so there's no need to for a second VPN tunnel.

You're trying to put the cart before the horse.

If you want to build something resilient put the physical interfaces on a lagg(4) and run one VPN tunnel over it. The lagg(4) will make sure you keep connectivity if one of the physical interfaces fails. The VPN might do a quick reset and restart but will continue to work. There's no need to fail-over the VPN itself. A fail-over VPN does have its uses, mostly when the other side drops of the internet, the fail-over VPN will then connect to a backup connection. But you generally use this in a fail-over situation, not a load-balancing one.
 
But in theory, why lscp not work over tap interfaces, it is a ethernet L2 level device, or it have some different compared with physical bge (intel nic)?
 
So, both VPN tunnels pass over the same uplink. Then load-balancing is rather pointless as both tunnels will need to share the same uplink bandwidth. One single VPN tunnel will be able to use all available bandwidth, so there's no need to for a second VPN tunnel.

...and for different uplinks esp. from differnt ISPs this most likely will also fail because of different latencies of the links. You'd have to increase the buffers to levels where the overall latency of the link becomes unbearable or even unusable for some services (e.g. VoIP).

Load-balancing should _NEVER_ be used for resiliency. One link should be able to handle your load, the second one is only a backup (and should also be able to meet your bandwidth requirements!). Load-balancing should only be used as a workaround if you can't get a sufficient uplink and can't distribute or modulate the load by other means (e.g. routing and/or prioritization/QoS).
 
Back
Top