Hi all,
After the ios upgrade the (Non-Cisco) LNS drops down the tunnels comming from the Cisco LAC.
Scenario 1 : Cisco LAC <-> Cisco LNS
Scenario 2 : Cisco LAC <-> Non Cisco LNS
The problem comes from the new extension PPPoE rfc3817 of the L2TP rfc2661
The log of the Cisco LNS shows like this:
Parse AVP 56, len 6, flag 0x0
Unknown AVP 56 in CM SCCRQ
Ignoring unknown AVP 56
Unknown AVP found during length verification. AVP is 56, vendor code is 0, len is 6
Ignoring unknown AVP 56
Parse AVP 57, len 6, flag 0x0
Unknown AVP 57 in CM SCCRQ
Ignoring unknown AVP 57
Unknown AVP found during length verification. AVP is 57, vendor code is 0, len is 6
Ignoring unknown AVP 57
The log of the Non-Cisco LNS shows like this:
AVP 56 (56) len 0
Unknown AVP type 56
AVP 57 (57) len 0
Unknown AVP type 57
.
.
.
Result Code 2: General error--Error Code indicates the problem
Error Code 8: Session or tunnel was shutdown due to receipt of an unknown AVP with the M-bit set
The Cisco LNS ignores the unknown AVP even if the Mandatory bit is 1 or 0. (Mandatory bit ignored)
The Non Cisco LNS drops down the tunnel after verification of mandatory bit presence.
The RFC 2661 says ...:
RFC 2661 http://www.apps.ietf.org/rfc/rfc2661.html
4.2 Mandatory AVPs
Receipt of an unknown AVP that has the M-bit set is catastrophic to the session or tunnel it is associated with. Thus, the M bit should only be defined for AVPs which are absolutely crucial to proper operation of the session or tunnel. Further, in the case where the LAC or LNS receives an unknown AVP with the M-bit set and shuts down the session or tunnel accordingly, it is the full responsibility of the peer sending the Mandatory AVP to accept fault for causing an non-interoperable situation. Before defining an AVP with the M-bit set, particularly a vendor-specific AVP, be sure that this is the intended consequence.
When an adequate alternative exists to use of the M-bit, it should be utilized. For example, rather than simply sending an AVP with the M- bit set to determine if a specific extension exists, availability may be identified by sending an AVP in a request message and expecting a corresponding AVP in a reply message.
Use of the M-bit with new AVPs (those not defined in this document) MUST provide the ability to configure the associated feature off, such that the AVP is either not sent, or sent with the M-bit not set.
The RFC 3817 says ...:
RFC 3817 http://www.apps.ietf.org/rfc/rfc3817.html
2.4.1 PPPoE Service Relay Response Capability AVP
The PPPoE Service Relay Response Capability AVP, Attribute Type 56, indicates to an L2TP peer that the PPPoE Service Relay (SRRQ, SRRP) messages and the PPPoE Relay AVP will be processed and responded to when received.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H| rsvd | Length | Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Vendor ID is the IETF Vendor ID of 0.
This AVP MAY be hidden (the H bit MAY be 0 or 1).
The M bit for this AVP may be set to 0 or 1. If the sender of this AVP does not wish to establish a connection to a peer which does not understand this L2TP extension, it SHOULD set the M bit to 1, otherwise it MUST be set to 0.
The Length of this AVP is 6.
The AVP may be present in the following messages: SCCRQ, SCCRP
- 2.4.2 PPPoE Service Relay Forward Capability AVP
- The PPPoE Service Relay Forward Capability AVP, Attribute Type 57, indicates to an L2TP peer that PPPoE Service Relay (SRRQ, SRRP) messages and the PPPoE Relay AVP may be sent by this L2TP peer.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H| rsvd | Length | Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Vendor ID is the IETF Vendor ID of 0.
This AVP MAY be hidden (the H bit MAY be 0 or 1).
The M bit for this AVP may be set to 0 or 1. If the sender of this AVP does not wish to establish a connection to a peer which does not understand this L2TP extension, it SHOULD set the M bit to 1, otherwise it MUST be set to 0.
The Length of this AVP is 6.
The AVP may be present in the following messages: SCCRQ, SCCRP
The Cisco 10K LAC sends the new AVP's 56 & 57 with the M-bit to 1
Is this correct ?
if yes, then ..... with old LNS can't work (unknown AVP with M-bit true = shutdown)
But the Cisco LNS ignores the unknown AVP's
Is this correct ?
if yes, then .... RFC : the M-bit can't be ignored
How to disable the M-bit (on LAC sender of AVP's) in AVP's to be ignored ?
Result:
Cisco LAC <-> Cisco LNS = works fine
Cisco LAC <-> Non-Cisco LNS = catastrophic
Thanks all.
