[c-nsp] Cisco Juniper PPPoE forwarding via L2TP
Junaid
junaid.x86 at gmail.com
Wed Aug 29 17:25:02 EDT 2007
Gabor, many thanks for such a comprehensive reply and info. I did experience
MTU issues while working with Cisco devices however there are a few
differences between the described problem and my scenario. Firstly, I am
using Cisco as LAC and ERX as LNS. Secondly the error my Cisco device gives
is related to NCP (which I mistakenly wrote LCP in my last email). Logs
attached showed following on cisco (LAC) side:
Aug 30 01:33:37: ppp27 PPP: Process pending ncp packets
Aug 30 01:33:37: uid:27 Tnl/Sn 21276/20 L2TP: Result code(4): 4: Call
failed, not enough resources (temporary)
Aug 30 01:33:37: Error code(4): Insufficient resources
Aug 30 01:33:37: Optional msg: session no resources server port
Aug 30 01:33:37: [27]PPPoE 27: State CNCT_FWDED Event SSS_DISCNCT
nocf7#
Aug 30 01:33:37: ppp27 PPP: Received Disconnect from Lower Layer
While on ERX side, following is observed:
DEBUG 08/29/2007 15:18:25 l2tp (interface TUNNEL l2tp:3/12): AVP Header:
type = vendor (0x0009) type (0x0064), length = 15, flags = ~M ~H
NOTICE 08/29/2007 15:18:25 l2tp (interface TUNNEL l2tp:3/12/12): Error in
incoming icrq from vr default, remote address 172.16.40.39 - invalid
non-mandatory AVP (l2tp session receive icrq avp bad value cisco nas port)
DEBUG 08/29/2007 15:18:25 l2tpStateMachine (interface TUNNEL l2tp:3/12/12):
lnsIncomingSession: state = idle, event = icrq, next state = txIcrp
I think I am messing up the config on ERX. I have configured another cisco
as LNS and it works fine when substituted for the juniper erx as an LNS.
Configs are as follows, please comment:
CISCO LAC Config:
------------------------------
vpdn enable
vpdn search-order domain dnis
!
vpdn-group 1
accept-dialin
protocol pppoe
virtual-template 1
!
vpdn-group 2
request-dialin
protocol l2tp
domain mycompany
initiate-to ip 172.16.40.40
local name nocrouter
no l2tp tunnel authentication
interface FastEthernet2/0
ip address 172.16.40.39 255.255.255.0
pppoe enable
interface Virtual-Template1
ip unnumbered FastEthernet2/0
no peer default ip address
ppp authentication pap
Juniper ERX CONFIG:
--------------------------------
aaa domain-map mycompany
router-name default
address-pool-name juniper
ipv6-router-name default
!
aaa domain-map defaut
router-name default
local-interface loopback 1
ipv6-router-name default
!
aaa domain-map none
router-name default
ipv6-router-name default
aaa local username "junaid at mycompany" database default
password 8 dPB;H0J;CGS
profile mycompany
ip virtual-router default
ip unnumbered fastEthernet 0/0
ppp authentication pap
virtual-router default
aaa authentication atm1483 default radius
aaa accounting atm1483 default radius
aaa authentication ip default none
aaa accounting ip default none
aaa authentication ppp default local
aaa accounting ppp default none
!
ip address-pool local
aaa authentication radius-relay default none
aaa accounting radius-relay default none
aaa authentication tunnel default none
aaa accounting tunnel default none
interface fastEthernet 0/0
ip address 172.16.40.40 255.255.255.0
l2tp disconnect-cause
l2tp destination profile mycompany virtual-router default ip address
172.16.40.39
remote host nocrouter
profile mycompany
local ip address 172.16.40.40
enable proxy authenticate
disconnect-cause
ip local pool juniper
ip local pool juniper 10.10.10.11 10.10.10.254
On 8/26/07, Gabor Ivanszky <ivanszky at niif.hu> wrote:
>
> 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