Junos OS

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?

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

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.

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?

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: 

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:

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

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.