Community discussions

MikroTik App
 
xristosthassos
just joined
Topic Author
Posts: 5
Joined: Wed May 16, 2018 4:26 pm

Bonding EoIP over vpn

Mon Oct 01, 2018 4:17 pm

Hello to all.

i have a mikrotik chr in a vps with p1 and 1 static ip

in my office i have 5 internet lines with a RB3011

i try to bond all the lines over my vps, but the speed is very low.

http://prntscr.com/l0uhvs

what i make wrong?

any help?
 
sindy
Forum Guru
Forum Guru
Posts: 10206
Joined: Mon Dec 04, 2017 9:19 pm

Re: Bonding EoIP over vpn

Mon Oct 01, 2018 9:27 pm

The TCP implementation on Windows reportedly doesn't work well if the packets don't come in the same order in which they have been sent. This is the reason why link aggregation (bonding) normally uses only a single link for all traffic between a given pair of IP addresses, i.e. its aggregated capacity can only be made use of by multi-source and/or multi-destinaton traffic. By using balance-rr, you break this rule, which almost certainly results in packets coming in shuffled order to the other end of the link.

To verify this, I'd disable all links but one at a time and check the bandwidth this way; if it matches the bandwidth of the enabled link (minus the overhead of the EoIP and of the VPN), the explanation above is the most likely one; if even this way the bandwidth is below, say, 2/3 of the raw one of each link, I'd check the CPU usage on the three devices involved (3011, the 941 in use, and the CHR) while you test the bandwidth to see whether one of them doesn't glow red doing its job.

Plus SSTP is a bad choice for L2 tunnelling - read something about TCP meltdown, it'll tell you that out of the VPNs available on Mikrotik, only IPsec makes real sense.

The 3011 can now use hardware encryption for IPsec (but not on SSTP), so you may well get better results if you terminate the VPN tunnels on the 3011, which may make the RB941s redundant in the overall scheme.
 
xristosthassos
just joined
Topic Author
Posts: 5
Joined: Wed May 16, 2018 4:26 pm

Re: Bonding EoIP over vpn

Tue Oct 02, 2018 4:02 am

Hi the problem in the 3011 is... I don't find a way for the l2pt vpn clients to go out from each internet line.... I try l2pt with ipsec.... with the 2 lines with same speed... down I have only 10m for each line... but upload I have the max of the lines. The 941 cpu is max 60%... the chr cpu the same... and the 3011 cpu 3-4%.
 
joegoldman
Forum Veteran
Forum Veteran
Posts: 767
Joined: Mon May 27, 2013 2:05 am

Re: Bonding EoIP over vpn

Tue Oct 02, 2018 6:13 am

Your current solution will only go as fast as the slowest connection, being 12/1, so even if the whole aggregation was working perfectly, you'd only be able to get 60mbit total. You'd have better success bonding just the 2x40m lines together.
 
sindy
Forum Guru
Forum Guru
Posts: 10206
Joined: Mon Dec 04, 2017 9:19 pm

Re: Bonding EoIP over vpn

Tue Oct 02, 2018 9:20 am

Hi the problem in the 3011 is... I don't find a way for the l2pt vpn clients to go out from each internet line.... I try l2pt with ipsec.... with the 2 lines with same speed... down I have only 10m for each line... but upload I have the max of the lines. The 941 cpu is max 60%... the chr cpu the same... and the 3011 cpu 3-4%.
This requires policy routing and maybe some extra voodoo to work but can be done. Did you manage to have all 5 PPPoEs up directly from the 3011? Do all the PPPoEs get public addresses? Is each of them on another ISP or some of them are from the same ISP?

With Mikrotik at both ends, you can use L2TP in bridge mode, but you cannot bond bridges together so better to use EoIP over IPsec than L2TP over IPsec. What bothers me more is the CPU load on the CHR, hopefully the physical CPU does have hardware acceleration for encryption and the virtualization environment allows to use it, otherwise it will be the bottleneck (in case of all-software encryption, there isn't a big difference between SSTP and IPsec on the same encryption algorithm). Encryption lowers the throughput seriously, especially with small packets, so without hardware acceleration 40 Mbit/s is just a dream and even with hardware acceleration it may be much less than you expect, the 3011 is not extra good in it (yet there should still be space for improvement in software versions to come, they've just started enabling it).

And what @joegoldman says is of course true, I completely forgot about it as I don't use balance-rr.
 
xristosthassos
just joined
Topic Author
Posts: 5
Joined: Wed May 16, 2018 4:26 pm

Re: Bonding EoIP over vpn

Tue Oct 02, 2018 3:43 pm

i setup a ovpn
server ok
client ok


now... i make a mangle rule

add action=mark-connection chain=prerouting comment=VPN-WAN5 dst-address=194.XX.XX.XXX dst-port=16805 new-connection-mark=\
to_wan5 passthrough=no port=16805 protocol=tcp src-address=192.168.0.1 src-mac-address=02:XX:06:XX:7E:XX src-port=16805

mac address is from ovpn client but every time the client go out from wan1
 
sindy
Forum Guru
Forum Guru
Posts: 10206
Joined: Mon Dec 04, 2017 9:19 pm

Re: Bonding EoIP over vpn

Tue Oct 02, 2018 4:29 pm

1) is that still related to the topic above? If you are concerned about bandwidth, forget about any encryption but IPsec, nothing else can be accelerated in hardware (even though the same encryption algorithms are used). Any VPN which uses TCP as transport is a voucher for a headache on a path which is not 100% loss-free, the more if you plan to tunnel L2 over it.

2) port=X is an abbreviation of src-port=X or dst-port=X, so your rule makes little sense to me. I don't know to what port number 16805 is related, to a particular ovpn-client instance? The port parameter of /interface ovpn-client specifies the port at which the remote server listens, not the local port from which the client initiates the connection, which is assigned dynamically (it's TCP). Also, connection-mark doesn't affect routing; routing-mark does if a route with such routing-mark exists. Also, MAC address of inside of the tunnel (of the L2 interface representing the local end of the tunnel) is not related to the transport packets carrying that tunnel in any way.

Who is online

Users browsing this forum: ajayrooplall, Gomo, smirgo and 66 guests