[c-nsp] PPPoE, MPMRRU and interface MTU

[Jessup, Toby]

Try the easy stuff first.

Before messing with changing protocol encapsulations consider using the
Cisco ip tcp adjust-mss command. Easy, harmless and likely to fix the
blocked PMTUD problem for most applications (for anything using TCP
flows).


-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Andre Beck
Sent: Wednesday, September 07, 2005 3:38 AM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] PPPoE, MPMRRU and interface MTU


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 <-
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/