Hi Guys

i have L2tp+bcp working, but i need to add ipsec. I have entered the ipsec secret in the l2tp server on the main site and the same on the client site, but it fails on phase 2 i have double checked the policy's and they match, but i can not get the tunnel encrypted. if i untick the ipsec box on the client then the tunnel is up, not secur.

Both ends are running the same fw and Ros

Adrian

but it fails on phase 2 i have double checked the policy's and they match

You mean proposals, right?

Ok so got the Ipsec working fine.

So i have l2tp+bcp working with ipsec, but when i turn on mlppp to get better mtu rates i get poor speed and fragmented packets.

MTU 1450
MRU1450
MRRU 1600

gives 1596 mtu on far end, but very bad speeds.

Thanks in advance.
Adrian

As you must be able to support 1500 byte MTU for BCP to work properly there is bound to be fragmentation somewhere. The L2TP MRU/MTU needs to be smaller than 1450 so there isn't nested fragmentation for both L2TP/IPsec traffic and the BCP payload - I've not found a definitive calculation, others on here may have a more insight.

Thanks for you answers, when im testing im using BW test from the headend router (ccr1036) to the client end. With mrru set to 1600 i get low test, i have changed the mrru setting and the the mtu settings to lower but never get any better speeds. i understand that to get full mtu size you MLPPP does the work but as this multi link does this mean i need tow l2tp tunnels per site to be running

Adrian

I understand that to get full mtu size you MLPPP does the work but as this multi link does this mean i need tow l2tp tunnels per site to be running

Not really, there's a lot of confusion around MLPPP.

The whole idea of MLPPP is to be able to spread the traffic across multiple links without need to avoid packet ordering issues by sticking each logical flow to a single link to maintain packet/frame order (which is what bonding/teaming normally does, and which requires to understand the internal structure of the payload to be able to identify the logical flows).

The key tool to achieve that is to split the contents of the same payload packet into two (or more) transport packets which have their own sequence numbers, so the receiving MLPPP stack sends the decapsulated payload packets in the same order in which the transmitting MLPPP stack has received them.

So what MLPPP does is that it fragments the payload packets using its own means, and re-assembles them at the receiving side, and it does not depend on whether the payload protocol has (like IP) or doesn't have (like L2 protocols) its own fragmentation mechanism, nor does it depend on whether there is just a single link between the client and server or there are more. The only condition is that both peers support MLPPP. And it is implementation dependent whether payload packets that fit into the MTU of a single link after encapsulation are split anyway or whether they are sent using a single transport packet. Some implementations cut the payload packet into halves, other send the bulk via one link and the part which didn't fit via the other one.

What I'm afraid of is that the MLPPP doesn't know the actual available size of the UDP packets as the IPsec overhead occupies part of the available MTU, so instead of each payload packet being transported in two UDP transport packets, it may be transported in three, as the first MLPPP fragment may be split into two IP fragments. But I'm far from sure here, you'd have to sniff to see the actual behaviour. In any case, unless you can provide a large enough path MTU so that a 1500-byte frame along with all the additional headers would still fit (and it's [IP[ESP[UDP[PPP[Payload]]]]] in the best case, can be even worse if NAT comes into play), the best you can get is the large frames to be split into two.

Just a final woe - Mikrotik seems to have resigned on further PPP development, so it supports MLPPP as both client and server on all PPP flavors, but the actual support of multiple links is only available if acting as a PPPoE client. And MPPC (Microsoft compression) is also unsupported.

So am i better off using EoIP for the layer 2 point to point links and have to put up with lower speeds?

Adrian

I don't think there's much of a difference. The basic issue is the same, any payload exceeding the physical MTU minuts all the encapsulation headers has to be cut into parts. And both EoIP over IPsec and BCP over IPsec (talking about transport packets, not about the session management) will take roughly the same overhead, so a significant difference could be seen only if the bulk of the traffic was fitting into a single EoIP transport packet but would need two MLPPP ones (or vice versa, I don't remember the exact overhead size of none of the two). The only thing is that EoIP doesn't need to know in advance what the actually usable packet space is as it does not fragment the packets itself. That's the only point which I'm uncertain about regarding MLPPP, how does it find out the actually usable packet space before populating the first transport packet to be sent.