IOS 12.2.33SB5 and unknown AVP 56 / 57 with Mandatory bit

Unanswered Question
Sep 20th, 2010

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.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Giuseppe Larosa Tue, 09/28/2010 - 09:59

Hello Daniel,

I guess you have opened a Cisco TAC service request as your findings show a very big impact

you have been kind to open this thread it can be helpful for others that can face the same issue.

Hope to help

Giuseppe

Actions

This Discussion