[c-nsp] how "fast" is L2TP "fast switching" under 12.3T?

[Robert E.Seastrom]

Many thanks to Krzysztof and David for pointing out the fragmentation
problem.  I might have stumbled on that myself (given sufficient time
and had I been minus the 15 hours worth of cutovers that I'd already
done yesterday) but really appreciate having a couple of extra set of
eyes connected to functioning brains looking over the config.

Additional comments inline:

Krzysztof Adamski <k at adamski.org> writes:

> Your problem is fragmentation, since the L2TP tunnel is delivered over
> Ethernet, the max MTU is 1500. Every customer frame that is over 1452
> causes fragmentation since 1452 + 8(PPPoE) + 12(L2TP) + 8(UDP) + 20(IP) = 1500.
> You can add "ip tcp adjust-mss 1412" to eliminate fragmentation of TCP
> packets, but you won't be able to do anything about UDP and IPSec packets.

Yup, the "ip tcp adjust-mss 1412" is already in place.  Based on flow
stats collected upstream, UDP is the biggest contributor; IPSec plays
a bit role.

> You friend has ATM, he has a bigger MTU, so no fragmentation.
>
> I have an identical setup to you, I graph CPU usage and reassembly, the
> graphs match perfectly.

Thanks for that data point.  I'm investigating other technologies
(jumbo frame gige, MPLS/frame on POS, even ATM).  I like the idea of
engineering around the fragmentation issue, since it gives me the
uneasy feeling that we are just one windows-virus-that-sends-big-UDP-
datagrams away from taking it on the chin.

Cheers,

                                        ---Rob