multilink ppp fails if rejected once in lcp

  • Thread starter Thread starter Olaf Selke
  • Start date Start date
O

Olaf Selke

OS: Win2000, SP4
HW: vanilla PC with two Ethernet NICs

hi,

it looks like the MS ppp stack refuses to negotiate multilink in a
second lcp phase, if it had been rejected in the first lcp
phase. That's my setup:

Win2000 <-- pppoe --> 1st AC/LAC <-- ip network --> 2nd AC/LNS
<----- l2tp ----->
<------------------- mppp ----------------->

The Win2000 box is connected with two DSL lines connected via a
dedicated NIC each to an access concentrator (AC). The RASPPPOE pppoe
protocol is used (http://raspppoe.com/).

After an lcp phase and authentication with the first AC, the ppp
sessions are tunnelled compulsory to a second AC using the l2tp
protocol. The second AC and the Win2000 client are going through a
second lcp phase, authentication is performed again and the ppp
sessions are terminated. The client gets assigned an ip address from
the second AC's pool.

mppp works perfectly if both NICs are configured as dialup device on
the Win2000 client, if both AC acks in lcp to mppp option as requested
by the client!

mppp doesn't work, if only the second AC acks to mppp in client's lcp
config request. So it looks like there's a possible bug in MS ppp
stack breaking mppp, if multiple lcp phases are required and if mppp
is rejected by an early lcp negotiation, even if the last AC in line
is willing to negotiated mppp.

Don't tell me mppp isn't supported together with DSL dialup and
pppoe. I'm working for the network side ;-) The second AC doesn't care
at all if the multilinked ppp sessions are pppoe over DSL, POTS, or
ISDN on client's local loop.

Olaf
 
Olaf Selke said:
it looks like the MS ppp stack refuses to negotiate multilink in a
second lcp phase, if it had been rejected in the first lcp
phase.
Click to expand...

with some Ethereal sniffing during the weekend I've been able to
confirm this. If the NAS config-rejects the multilink MRRU in the
first lcp phase, Win2000's ppp stack seem to be disgruntled about it
and doesn't config-request again a multilink MRRU during lcp
re-negotiation.

cheers, Olaf
 
Are saying that it does work if the first AC supports multilink?

If so, since the 1st AC will need to be coordinated with the 2nd AC, why not
just enable multilink on the first AC?

If the first AC supports multilink and multilink PPPoE works with the first
AC, you could theoretically also set the client to double-dial a single
L2TP/IPSec link over the first multi-linked connection (if compulsory
tunneling is causing the problem).

I do not use the PPPoE client you referenced so I'm not sure if it handles
multilink or not.
 
Carl DaVault said:
Are saying that it does work if the first AC supports multilink?
If so, since the 1st AC will need to be coordinated with the 2nd AC,
why not just enable multilink on the first AC?
Click to expand...

*LOL* If only things were that easy. Background to Olaf's question: Here in
Germany, 97% of all ADSL lines are operated by the (ex?)monopoly Deutsche
Telekom, and DT also operates the ACs all the ADSL lines lead to. The ACs
will either directly authenticate the user and connect them to Deutsche
Telekom's backbone, or (grudgingly) pass the PPP connection on to a
competing backbone operator.

Telekom's ACs always reject MLPPP, and you can imagine that Telekom will
hardly change anything about that because their competitors ask them to...
If the first AC supports multilink and multilink PPPoE works with the
first AC, you could theoretically also set the client to double-dial
a single L2TP/IPSec link over the first multi-linked connection (if
compulsory tunneling is causing the problem).
Click to expand...

No, that's not the issue. The issue is that if a PPP endpoint rejects any
LCP option, there is _no_ way this option can be renegotiated in a second
LCP phase. I think there is a fundamental issue (bug) with Microsoft's PPP
implementation here; this behavior may not be compliant with the standards
(RFCs)...
I do not use the PPPoE client you referenced so I'm not sure if it
handles multilink or not.
Click to expand...

The version of RASPPPOE which Olaf is using reports to NDISWAN that
multilink framing is allowed. I should know, because I wrote RASPPPOE and
made that special build for him ;)

Regards,
 
Carl DaVault said:
If so, since the 1st AC will need to be coordinated with the 2nd AC, why not
just enable multilink on the first AC?
Click to expand...

hi Carl,

thanx for the info. From my point of view everything Robert said is
correct. The first AC is operated by the former German incumbent
'Deutsche Telekom' and I'm working for the former Spanish incumbent's
German subsidiary 'Telefonica Deutschland'. The l2tp Tunnel between
the first and second AC (actually there're lots of them) defines the
inter-carrier interface between two telcos. Deutsche Telekom operates
about 4 Mio DSL Lines on their ACs and they certainly won't enable
multilink on my behalf.

Did I mention it nearly works out of the box with Linux used as pppoe
client? :-)

Olaf
 
Back
Top