PPP LFI over L2TPv3

[d.stepanenko]

PPP LFI (link fragmentation and interleaving) over L2TPv3 - is it

possible? Could anybody implement this with Cisco routers?

The problem is the following. We have a central office with Cisco3660

and some remote offices with, say, Cisco 871s. The remote offices are

connected to the central one through the provider's network, which has

a mixed nature - somewhere FR, somewhere Wi-Fi, somewhere plain

ethernet. Traditionally I used GRE-tunnels (encrypted with IPSEC) to

pass the traffic between the offices. This worked and keeps working

now.

But then, the following idea to improve VoIP quaulity in this VPN has

appeared. What if I replace GRE-tunnels with L2TPv3 ones, pass PPP over

L2TPv3, and the cut the traffic to the small pieces using multilink PPP

interleaving and fragmentation.

I have made the working model on my LAN and everything seemed to work.

But it only seemed, unfortunately. Pings walked through the tunnel, but

the other traffic (HTTP etc) could not. After more detailed

investigation it became clear that IP-packets bigger than the PPP

fragment could not pass the tunnel. Probably the fragments could not be

reassembled on the tunnel's far end. When I tried to turn interleaving

off, all began to work. But I don't need the tunnel without

interleaving - I would better use plain old GRE in this case.

So the question is: what is wrong? Have not Cisco routers learned to

pass fragmented PPP over L2TPv3 pseudwires yet or is there something

wrong with my hands? If anybody managed to implement this schema, I

could show my configs for more detailed investigation.

Thanks in advance.

[drolemc]

The Cisco IOS Link Fragmentation and Interleaving (LFI) feature uses Multilink PPP (MLP). MLP provides a method of splitting, recombining, and sequencing datagrams across multiple logical data links.Refer URL for more information

http://www.cisco.com/en/US/products/sw/iosswrel/ps1835/products_configuration_guide_chapter09186a00800b75d2.html

[d.stepanenko]

Thank you, Donald,

but I feel you did not understand my problem (probably because of my bad English) :-)

Surely, I used MLP when I tried to implement PPP LFI over L2TPv3. I've created interface, say, "Multilink1", assigned an IP-address to it, and enabled EIGRP on it. Then I've declared, say, "Virtual-PPP1" interface (with no IP-address) as "ppp multilink" and belonging to multilink group 1. The problem is that this did not work.

Or, more accurately, this worked until I entered "ppp multilink interleave" and "ppp multilink fragment delay 20" on the Multilink interface. From this moment only packets, small enough to go from the interface without L2-fragmentation, could pass through the link.

Debugging log (debug ppp multilink events showed the following):

MLP: Discard reassembled packet, class 0

MLP: Lost fragment 4E1 (all links out of sequence), class 0

MLP: Begin bit lost, discard fragment 4E5, class 0

MLP: Received lost fragment seq 4E1, expecting 4E6, class 0

MLP: Out of sync with peer, resyncing to last rcvd seq# (0004E1), class 0

MLP: Unusual jump in seq number, from 0004E6 to 0004E1, class 0

MLP: Lost fragment 4E5 (all links out of sequence), class 0

MLP: Discard reassembled packet

...and so on, with no end.

It is clear that sometimes one fragment comes to the destination with some delay, out of order. But when it finally arrives, the destination router (which evidently understands that this is the long-waited lost fragment) drops all the fragments it accumulated in its buffer, instead of trying to reassemble the whole frame.

I have no idea what prevents PPP fragments from being properly reassembled.