[c-nsp] Cisco Juniper PPPoE forwarding via L2TP
Gabor Ivanszky
ivanszky at niif.hu
Sun Aug 26 12:06:23 EDT 2007
Hi,
have a look at this:
Synopsis
Interoperability problems relating to LCP negotiation of MRU
Problem
Cisco and Juniper have different approaches that are used to negotiate
the Maximum Receive Unit (MRU) during LCP. This can cause PPP sessions
to fail in an L2TP environment if the ERX is the LAC and the Cisco is
acting as the LNS. Oddly, the problem is only apparent with certain PPP
clients. An analysis of the PPP negotiation between the client with the
ERX and Cisco (LNS) shows the problem to be with LCP. Specifically, the
problem is with the MRU value and how it is negotiated. The issue is
that the PPP client is requesting an MRU of 1492. How that request is
processed by each vendor is the root of the problem. The ERX will by
default operate with an MRU of 1500. However, it will accept the lower
value requested by the client. This is seen in the PPP debug output seen
below: pppPacket (interface ATM 13/3.16033): time: 0.00, tx lcp confReq,
id = 52, length = 19, mru = 9178, authentication = chap MD5, magicNumber
= 0x7ca9c557 pppPacket (interface ATM 13/3.16033): time: 0.01, rx lcp
confReq, id = 69, length = 14, mru = 1492, magicNumber = 0x1e1d5335
pppPacket (interface ATM 13/3.16033): time: 0.01, tx lcp confAck, id =
69, length = 14, mru = 1492, magicNumber = 0x1e1d5335 pppPacket
(interface ATM 13/3.16033): time: 0.01, rx lcp confNak, id = 52, length
= 8, mru = 1500 pppPacket (interface ATM 13/3.16033): time: 0.01, tx lcp
confReq, id = 53, length = 15, authentication = chap MD5, magicNumber =
0x7ca9c557 pppPacket (interface ATM 13/3.16033): time: 0.02, rx lcp
confAck, id = 53, length = 15, authentication = chap MD5, magicNumber =
0x7ca9c557 The negotiated MRU is then passed along to the Cisco LNS via
an AVP. The LNS will then reject the MRU value that has been sent and
refute the session. It is torn down and never established. This is seen
in the following PPP output:
Nov 3 17:41:47.576: ppp24 PPP: Phase is ESTABLISHING
Nov 3 17:41:47.576: ppp24 LCP: I FORCED rcvd CONFACK len 15
Nov 3 17:41:47.576: ppp24 LCP: MRU 1492 (0x010405D4)
Nov 3 17:41:47.576: ppp24 LCP: AuthProto CHAP (0x0305C22305)
Nov 3 17:41:47.576: ppp24 LCP: MagicNumber 0x54104795 (0x050654104795)
Nov 3 17:41:47.576: ppp24 LCP: I FORCED sent CONFACK len 14
Nov 3 17:41:47.576: ppp24 LCP: MagicNumber 0x00B64095 (0x050600B64095)
Nov 3 17:41:47.576: ppp24 LCP: PFC (0x0702)
Nov 3 17:41:47.576: ppp24 LCP: ACFC (0x0802)
Nov 3 17:41:47.576: ppp24 LCP: MRU 1492 (0x010405D4)
Nov 3 17:41:47.576: ppp24 PPP LCP not accepting sent CONFACK
Nov 3 17:41:47.576: ppp24 LCP: State is Closed
Nov 3 17:41:47.576: ppp24 PPP: Sending Acct Event[Down] id[30]
Nov 3 17:41:47.576: ppp24 PPP: Phase is DOWN
Nov 3 17:42:32.066: ppp25 PPP: Phase is ESTABLISHING
Nov 3 17:42:32.066: ppp25 LCP: I FORCED rcvd CONFACK len 15
Nov 3 17:42:32.066: ppp25 LCP: MRU 1492 (0x010405D4)
Nov 3 17:42:32.070: ppp25 LCP: AuthProto CHAP (0x0305C22305)
Nov 3 17:42:32.070: ppp25 LCP: MagicNumber 0x65ED3436 (0x050665ED3436)
Nov 3 17:42:32.070: ppp25 LCP: I FORCED sent CONFACK len 14
Nov 3 17:42:32.070: ppp25 LCP: MagicNumber 0x00B6EE70 (0x050600B6EE70)
Nov 3 17:42:32.070: ppp25 LCP: PFC (0x0702)
Nov 3 17:42:32.070: ppp25 LCP: ACFC (0x0802)
Nov 3 17:42:32.070: ppp25 LCP: MRU 1492 (0x010405D4)
Nov 3 17:42:32.070: ppp25 PPP LCP not accepting sent CONFACK
Nov 3 17:42:32.070: ppp25 LCP: State is Closed
Nov 3 17:42:32.070: ppp25 PPP: Sending Acct Event[Down] id[32]
Nov 3 17:42:32.070: ppp25 PPP: Phase is DOWN
Interestingly enough, if a Cisco LAC is substituted for the ERX,
everything will work fine. The Cisco LAC will refuse to accept an MRU
negotiated via LCP that is lower than 1500. Thus, all attempts by the
PPP client to get 1492 are rebuked. In the end, the client gives up and
no longer even tries to negotiate an MRU:
Nov 5 10:08:34: Vi1548 PPP: Treating connection as a dedicated line
Nov 5 10:08:34: Vi1548 PPP: Phase is ESTABLISHING, Active Open
Nov 5 10:08:34: Vi1548 PPP: Preauth Authorization:
Nov 5 10:08:34: Vi1548 PPP/AAA: auth-required
Nov 5 10:08:34: Vi1548 LCP: O CONFREQ [Closed] id 12 len 15
Nov 5 10:08:34: Vi1548 LCP: AuthProto CHAP (0x0305C22305)
Nov 5 10:08:34: Vi1548 LCP: MagicNumber 0x8D275427 (0x05068D275427)
Nov 5 10:08:34: Vi1548 LCP: I CONFACK [REQsent] id 12 len 15
Nov 5 10:08:34: Vi1548 LCP: AuthProto CHAP (0x0305C22305)
Nov 5 10:08:34: Vi1548 LCP: MagicNumber 0x8D275427 (0x05068D275427)
Nov 5 10:08:36: Vi1548 LCP: TIMEout: State ACKrcvd
Nov 5 10:08:36: Vi1548 LCP: O CONFREQ [ACKrcvd] id 13 len 15
Nov 5 10:08:36: Vi1548 LCP: AuthProto CHAP (0x0305C22305)
Nov 5 10:08:36: Vi1548 LCP: MagicNumber 0x8D275427 (0x05068D275427)
Nov 5 10:08:36: Vi1548 LCP: I CONFACK [REQsent] id 13 len 15
Nov 5 10:08:36: Vi1548 LCP: AuthProto CHAP (0x0305C22305)
Nov 5 10:08:36: Vi1548 LCP: MagicNumber 0x8D275427 (0x05068D275427)
Nov 5 10:08:37: Vi1548 LCP: I CONFREQ [ACKrcvd] id 3 len 14
Nov 5 10:08:37: Vi1548 LCP: MRU 1492 (0x010405D4)
Nov 5 10:08:37: Vi1548 LCP: MagicNumber 0x00004CC9 (0x050600004CC9)
Nov 5 10:08:37: Vi1548 LCP: O CONFNAK [ACKrcvd] id 3 len 8
Nov 5 10:08:37: Vi1548 LCP: MRU 1500 (0x010405DC)
Nov 5 10:08:37: Vi1548 LCP: I CONFREQ [ACKrcvd] id 4 len 14
Nov 5 10:08:37: Vi1548 LCP: MRU 1492 (0x010405D4)
Nov 5 10:08:37: Vi1548 LCP: MagicNumber 0x00004CC9 (0x050600004CC9)
Nov 5 10:08:37: Vi1548 LCP: O CONFNAK [ACKrcvd] id 4 len 8
Nov 5 10:08:37: Vi1548 LCP: MRU 1500 (0x010405DC)
Nov 5 10:08:37: Vi1548 LCP: I CONFREQ [ACKrcvd] id 5 len 14
Nov 5 10:08:37: Vi1548 LCP: MRU 1492 (0x010405D4)
Nov 5 10:08:37: Vi1548 LCP: MagicNumber 0x00004CC9 (0x050600004CC9)
Nov 5 10:08:37: Vi1548 LCP: O CONFNAK [ACKrcvd] id 5 len 8
Nov 5 10:08:37: Vi1548 LCP: MRU 1500 (0x010405DC)
Nov 5 10:08:37: Vi1548 LCP: I CONFREQ [ACKrcvd] id 6 len 14
Nov 5 10:08:37: Vi1548 LCP: MRU 1492 (0x010405D4)
Nov 5 10:08:37: Vi1548 LCP: MagicNumber 0x00004CC9 (0x050600004CC9)
Nov 5 10:08:37: Vi1548 LCP: O CONFNAK [ACKrcvd] id 6 len 8
Nov 5 10:08:37: Vi1548 LCP: MRU 1500 (0x010405DC)
Nov 5 10:08:37: Vi1548 LCP: I CONFREQ [ACKrcvd] id 7 len 14
Nov 5 10:08:37: Vi1548 LCP: MRU 1492 (0x010405D4)
Nov 5 10:08:37: Vi1548 LCP: MagicNumber 0x00004CC9 (0x050600004CC9)
Nov 5 10:08:37: Vi1548 LCP: O CONFNAK [ACKrcvd] id 7 len 8
Nov 5 10:08:37: Vi1548 LCP: MRU 1500 (0x010405DC)
Nov 5 10:08:37: Vi1548 LCP: I CONFREQ [ACKrcvd] id 8 len 14
Nov 5 10:08:37: Vi1548 LCP: MRU 1492 (0x010405D4)
Nov 5 10:08:37: Vi1548 LCP: MagicNumber 0x00004CC9 (0x050600004CC9)
Nov 5 10:08:37: Vi1548 LCP: O CONFREJ [ACKrcvd] id 8 len 8
Nov 5 10:08:37: Vi1548 LCP: MRU 1492 (0x010405D4)
Nov 5 10:08:37: Vi1548 LCP: I CONFREQ [ACKrcvd] id 9 len 10
Nov 5 10:08:37: Vi1548 LCP: MagicNumber 0x00004CC9 (0x050600004CC9)
Nov 5 10:08:37: Vi1548 LCP: O CONFACK [ACKrcvd] id 9 len 10
Nov 5 10:08:37: Vi1548 LCP: MagicNumber 0x00004CC9 (0x050600004CC9)
Nov 5 10:08:37: Vi1548 LCP: State is Open
Nov 5 10:08:37: Vi1548 PPP: Phase is AUTHENTICATING, by this end
Since no MRU was negotiated at the LAC, an empty value is forwarded to
the LNS. MRU is never negotiated. The LNS will then act as if it were
1500. The client can still transmit at 1492 with no impairment of
service. The negotiation between the Cisco LNS and the client is:
Nov 3 17:46:00.881: ppp27 PPP: Phase is ESTABLISHING
Nov 3 17:46:00.881: ppp27 LCP: I FORCED rcvd CONFACK len 15
Nov 3 17:46:00.881: ppp27 LCP: AuthProto CHAP (0x0305C22305)
Nov 3 17:46:00.881: ppp27 LCP: MagicNumber 0x847DACA6 (0x0506847DACA6)
Nov 3 17:46:00.881: ppp27 LCP: I FORCED sent CONFACK len 10
Nov 3 17:46:00.881: ppp27 LCP: MagicNumber 0x00BA1D77 (0x050600BA1D77)
Nov 3 17:46:00.881: ppp27 LCP: PFC (0x0702)
Nov 3 17:46:00.881: ppp27 LCP: ACFC (0x0802)
Nov 3 17:46:00.881: ppp27 PPP: Phase is FORWARDING, Attempting Forward
Nov 3 17:46:00.881: ppp27 PPP: Phase is AUTHENTICATING, Unauthenticated
User
Nov 3 17:46:03.896: ppp27 PPP: Phase is FORWARDING, Attempting Forward
Nov 3 17:46:03.916: Vi3 PPP: Phase is DOWN, Setup
Nov 3 17:46:03.920: Vi3 PPP: Phase is AUTHENTICATING, Authenticated User
Nov 3 17:46:03.920: Vi3 CHAP: O SUCCESS id 6 len 4
Nov 3 17:46:03.920: Vi3 PPP: Phase is UP
The problem would only occur if an ERX is tunneling subscribers to a
Cisco. It would also only occur if the client requests an MRU of 1492.
If it were to request 1500, everything would work fine. The reasons for
the differing implementations of MRU can be traced to the PPP RFC (1661)
and the PPPoE RFC (2516) The PPP specification indicates that the
default value for the MRU is 1500 octets. However, lower values are
allowed: "The maximum length for the Information field, including
Padding, but not including the Protocol field, is termed the Maximum
Receive Unit (MRU), which defaults to 1500 octets. By negotiation,
consenting PPP implementations may use other values for the MRU. "
Additionally however, the PPP RFC also goes on to call out the fact that
implementations MUST be able to receive 1500 octets in case the link
synchronization is lost. The specific verbiage is: "The default value is
1500 octets. If smaller packets are requested, an implementation MUST
still be able to receive the full 1500 octet information field in case
link synchronization is lost. Implementation Note: This option is used
to indicate an implementation capability. The peer is not required to
maximize the use of the capacity. For example, when a MRU is indicated
which is 2048 octets, the peer is not required to send any packet with
2048 octets. The peer need not Configure-Nak to indicate that it will
only send smaller packets, since the implementation will always require
support for at least 1500 octets. " This inherent limit works fine in
PPP only environments, but support for PPPoE changes things. PPPoE
inherently carries with it additional headers that make an MRU of 1500
impossible to attain. The physical limit for a PPPoE MRU is 1492. It
cannot transmit at a higher rate. This is explicitly stated in the PPPoE
RFC (RFC 2516): "The Maximum-Receive-Unit (MRU) option MUST NOT be
negotiated to a larger size than 1492. Since Ethernet has a maximum
payload size of 1500 octets, the PPPoE header is 6 octets and the PPP
Protocol ID is 2 octets, the PPP MTU MUST NOT be greater than 1492. "
So, the two specs are in contention. By allowing only 1500, the Cisco is
following the letter of the PPP spec, but it is contrary to the
parameters specified for PPPoE. On the other hand, the ERX is operating
in a much more compliant manner. It follows the PPPoE RFC in that it
only allows an MRU of 1492. However, it also allows for support and
interoperability with PPP stacks that are not as compliant.
Solution
The ERX is considered to be functioning as designed. An MRU of 1500 will
be allowed but reported internally as 1492. The fact that it works with
Cisco as the LAC and LNS is a matter of standardization. Because both
the LAC and the LNS operate in the same manner, it works in spite of the
fact that it is seemingly broken. There are 2 workarounds to the problem
that can be implemented at the Cisco LNS. The two options are to either
manually set a lower MTU or to enable LCP renegotiation. The first
option is to force the Cisco to negotiate a lower MRU. In order to
manually define a lower IP MTU, the configuration for the Virtual
Template referenced by the VPDN group would need to be modified. A
sample of the change would be:
vpdn-group 1
accept-dialin
protocol l2tp
virtual-template 1
interface virtual-template 1
ip mtu 1492
ip unnumbered loopback 0
default ip address pool
ppp authentication chap
The other option is to turn on LCP renegotiation. This is a command that
Cisco has implemented to deal with L2TP interoperability issues. When
turned on, the command will allow the LNS to renegotiate the PPP LCP
parameters with incoming sessions. Thus, the values sent by the LAC can
be ignored. The command syntax is:
vpdn-group 1
accept-dialin
protocol l2tp
virtual-template 1
terminate-from pat
lcp renegotiation on-mismatch
More information about the cisco-nsp
mailing list