Junos OS

Expand all | Collapse all

LNS to LTS/LAC Issue

Jump to Best Answer
  • 1.  LNS to LTS/LAC Issue

     
    Posted 09-11-2018 05:45

    We have a configuration that, from a DSL/FTTC perspective, works fine with no issues at all.

     

    Now we have asked our downstream ISP to enable session-steering for us, which requires extra VSAs on the RADIUS. 

     

    So, we see the LTS packet come in and the RADIUS respond with the correct tunnel end point (Session-Steering) and then, on the radius, I see the following access-accept at the LNS:

     

    Sent Access-Accept Id 89 from 180.80.0.38:1812 to 180.80.0.13:50903 length 0

     

    However, the CPE still does not authenticate and the LNS then receives a logout message. It then goes through the process again, and again and again.....

     

    So, my question is:

     

    Is there any other configuration required on the LNS beyond the curernt config that works fine without the session-steering?



  • 2.  RE: LNS to LTS/LAC Issue

     
    Posted 09-11-2018 06:03

    Hi Clive,

     

    Can you please send the PCAP file to understand the scenario? Are you receiving L2TP packet from LTS or simple radius packet?

     

    Regards,

    Rahul



  • 3.  RE: LNS to LTS/LAC Issue

     
    Posted 09-11-2018 06:54

    Hi Rahul,

     

    I cannot send a PCAP as we have no equipment at the Data Centre sitting in front of the LNS. 

     

    Their LTS is acting as a forwarder only, so I believe the traffic flow should be as follows:

     

    1: LTS sends auth packet to RADIUS directly.

    2: RADIUS responds saying "Yes, that's right, and here is the LNS I want you to use"

    3: LTS should hand over to correct LNS to begin LCP process with CPE - session-steering

    4: Normal authenticaiton process for access

     

    So, we are seeing, on the RADIUS, everything as successful....

     

    The auth log file on the LNS shows it as the following:

     

    Auth_req_rec

    Auth_ack_sent

    Logout_recd

     

    Over and over in a cycle.



  • 4.  RE: LNS to LTS/LAC Issue

     
    Posted 09-12-2018 00:49

    Hi Rahul,

     

    We are seeing the ICRQ packets etc (which should indicate a tunnel UP but we don't see a tunnel) at the interface level and I can tie this in with some of the authd log packets, but one of the possible errors we see in each log (RADIUS, authd and traffic interface) is the following:

     

    SMPF-SSSHE-1 atm 0/1/0/4:0.38@Remote-Agent-Id Not Present

     

    Have you seen this before and is it a possible issue?



  • 5.  RE: LNS to LTS/LAC Issue

     
    Posted 09-12-2018 01:49

    One more add on that might be relevant and probably is:

     

    180.80.0.29.1701 > 70.1.81.179.1701: MSGTYPE(CDN) : RESULT_CODE(3/6 session-administrative-close) :  (Not sure if this means code 3 out of 6 (as there are more than 6 on the IANA site) or it means 3 and 6):

    IANA does not give much more information as there is no rfc attachment for this. Here is the IANA code response: 

    3

    Call/Session disconnected for administrative reasons

    6

    Invalid destination

     

    And for the StopCCN code:

    180.80.0.29.1701 > 70.1.76.179.1701: MSGTYPE(StopCCN): RESULT_CODE(1/6) : (Again, not sure if this means code 1 from a possible 6 as there are more than 6 here too, or 1 and 6):

    IANA response for these codes:

    1

    General request to clear control connection

    6

    Requester is being shut down



  • 6.  RE: LNS to LTS/LAC Issue
    Best Answer

     
    Posted 09-13-2018 02:38

    I'm going to accept my own answer as the resolution to this  🙂

     

    Well, almost a resolution.

     

    After completing various tests, it looks like the CPE does not like certain VSAs. Of course, the confusing part is that the CPE during this period has NO IP address assigned and therefore the LAC/LTS is forwarding the information for the CPE making it look like the LAC/LTS is at fault.

     

    This can now be resolved off line due to this troubleshooting step...

     

    Thanks



  • 7.  RE: LNS to LTS/LAC Issue

     
    Posted 09-14-2018 02:08

    Apologies, I should have placed the solution in here. So, here is the solution:

     

    When looking at the log files, it is important to note that the authd files will look like they are from the LTS/LAC but, in fact, are not. Because the IPCP process has not completed, the CPE does not have an IP address and therefore the LTS/LAC is acting as forwarder for the CPE.

     

    In our case, the CPE was rejecting the VSAs that our downstream provider was stating we had to use. These were:

     

    ERX-Tunnel-Switch-Profile - Reply += (Value ISP supplied)

    ERX-Tunnel-Virtual-Router:0  - Reply += (ISP LTS Name)

    Tunnel-Server-Endpoint:0 - Reply +=  (Steered LNS address)

    Tunnel-Password:0 - Reply +=

    Tunnel-Type:0 - Reply +=  L2TP

    Tunnel-Preference - Reply += (Downstream ISP supplied)

     

    The :0 is the tagged element.

     

    Now, we have to find a way to either "ignore" or "exclude" these VSAs....

     

    Upgrade Junos to 18.2R1.

     

    Utilise the following command within the AAA Profile:

     

    set access profile aaa-profile radius attributes ignore standard-attribute 67
    set access profile aaa-profile radius attributes ignore standard-attribute 69
    set access profile aaa-profile radius attributes ignore standard-attribute 64
    set access profile aaa-profile radius attributes ignore standard-attribute 83
    set access profile aaa-profile radius attributes ignore vendor-id 4874 vendor-attribute 66
    set access profile aaa-profile radius attributes ignore vendor-id 4874 vendor-attribute 8
    set access profile aaa-profile radius attributes ignore vendor-id 4874 vendor-attribute 91

     

    And now everything is operational.