[c-nsp] PPPoE, MPMRRU and interface MTU

[Andre Beck]

Hi,

we are supplying Internet access on top of a carrier DSL/PPPoE based
infrastructure through an L2TP tunnel to a Cisco router that terminates
the PPPoE sessions. Due to the PPPoE maximum MRU of 1492 and further
overhead implied by the L2TP tunneling (resulting in an effective MRU
of 1452), this setup is exposed to the "Idiots destroying PMTUD with
their paranoid firewalls and/or broken load balancers" symptom. Bad
enough, these idiots are not our customers (who we could educate) but
server operators somewhere in the Internet. Just ignoring them is no
option either, as this includes sites which for some reason are relevant
to customers as if their life depends on it, namely eBay.

Now there is a rather simple solution to this "problem": Multilink PPP
aka MP. Combining the fact that MP negotiates a MRRU (maximum recon-
structed receive unit) which is independend from the real link MRU
of the bundle members and the fact that MP works perfectly even on
just a single link, one can establish an MP single-member bundle on top
of PPPoE which f.i. uses a fragment size of less than the link MRU
(1452 in my case), but an MRRU wich allows an MTU of 1500 to be main-
tained on routers feeding the bundle.

Now that's the theory, but practice on IOS seems altogether different.

1) Central side

At the central side virtual templates are used, which allows for the
statement "ppp mtu adaptive". It seems that this does what I want,
at least partially. However it is still unclear to me how to configure
the link MTU to the correct value for negotiation of the link MRU.

   Will giving the "mtu 1452" statement force the *link* interface
   cloned from the VT to have that MTU (so MP fragments will not
   exceed that size) but still allow the *bundle* interface to negotiate
   for its MTU, resulting in one of 1500 or more depending on the MRRU
   that was negotiated? Or will it force that interface's MTU to 1452
   as well, achieving nothing?

I currently have no mtu statement in the VT and end up with a bundle
interface MTU of 1500. I'd have expected this to be 1524 as this is the
MRRU negotiated (from debug ppp negot). So I fear giving an explict mtu
state ment on the VT will also force the MP bundle interface to this MTU
and thus break the whole idea - leaving out the mtu statement is just
setting it to the default 1500, isn't it?

2) CPE side

Things here are even worse. MP is only present in PLUS loads on the 836
and thelike platforms it seems, something I don't understand at all
given that the 836 has an ISDN BRI interface. After deploying a load
that supports MP I found that I cannot use "ppp mtu adaptive" in a
dialer interface, so I cannot use it on the CPE at all. I end up
with the good old (silly) default of MTU beeing and staying as configured
independend of what PPP negotiates. This for sure doesn't help solve
the problem.

Clearly having just *one* mtu statement for an interface is a bit
insufficient for an architecture that involves two layers, the PPP link
with its physically/endpoint determined MRU but on top of that, the
MP bundle with its completely virtual MRRU. What I want is a way to
specify *both*, independend of each other, and have the resulting
interface use the only relevant value, the MRRU, as its MTU. I have
not yet found a way to achieve this, to be silent of a clean and
elegant way of doing so. With "ppp mtu adaptive" on the central site
the solution is partial as it can fix the downstream direction and
as long as the customer is not doing the idiot thing, that suffices
to work around the problem. But he, when I start deploying MP for this,
it should be symmetrical and orthogonal, shouldn't it?

Has anyone already solved this problem and can give configuration
(or any other) hints of how to do it?

TIA,
Andre.
-- 
                  The _S_anta _C_laus _O_peration
  or "how to turn a complete illusion into a neverending money source"

-> Andre Beck    +++ ABP-RIPE +++    IBH Prof. Dr. Horn GmbH, Dresden <-