Junos OS

 View Only
last person joined: 2 days ago 

Ask questions and share experiences about Junos OS.
Expand all | Collapse all

Juniper MX104 : LNS Subsribers won't establish

  • 1.  Juniper MX104 : LNS Subsribers won't establish

    Posted 09-10-2020 02:05

    I'm using a MX104 as a LNS connecting to a LAC. I've used the MX104 before but for anothe provider and apart from lots of fiddling around initially it works well.  

      

    I can't however get this new LNS to LAC working. The l2tp tunnel establishes fine but and I can see the username/password hit our radius server but as it's trying to establish it then fails and tears itself down.


    I've attached the relevant part of the MX104 configuration as well as the AUTH log I've captured. Could anyone take a look and offer me some advice as to where I may be going wrong?

     

    i've done a find/replace on IP's just for security 🙂

     

    Thanks

    Attachment(s)

    txt
    AUTHDEBUG.txt   16 KB 1 version
    txt
    LNS-CONFIG.txt   6 KB 1 version


  • 2.  RE: Juniper MX104 : LNS Subsribers won't establish

    Posted 09-10-2020 02:10

    I have no actual experience configuring such features on the MX platforms... but I know this requires a license which is enforced.

     

    So - can you confirm if any licenses for BNG features are installed (show system license)?

     



  • 3.  RE: Juniper MX104 : LNS Subsribers won't establish

    Posted 09-10-2020 02:52

    Thanks for the response. 

    I can confirm that I have the required additional licenses:

    show system license
    License usage:
    Licenses Licenses Licenses Expiry
    Feature name used installed needed
    subscriber-accounting 0 1 0 permanent
    subscriber-authentication 0 1 0 permanent
    subscriber-address-assignment 1 1 0 permanent
    subscriber-vlan 0 1 0 permanent
    subscriber-ip 0 1 0 permanent
    service-dc 0 1 0 permanent
    service-accounting 0 1 0 permanent
    service-qos 0 1 0 permanent
    service-ancp 0 1 0 permanent
    service-cbsp 0 1 0 permanent
    scale-subscriber 0 4000 0 permanent
    scale-l2tp 0 1000 0 permanent
    l2tp-inline-lns 1 1 0 permanent
    MX104-2x10Gig-port-0-1 0 1 0 permanent



  • 4.  RE: Juniper MX104 : LNS Subsribers won't establish

    Posted 09-10-2020 03:00

    you should check log and traceoptions on LAC side because looks like this subscriber was tunneled

    Sep 10 09:57:36.986025 SEQ SendClientMsg:jpppd-client session-id:4240 reply-code=10 (OK TUNNELLED), result-subopcode=1 (ACCESS_OK), cookie=12703 ex_cookie=0x8f rply_len=28, num_tlv_blocks=0

     

    but then disconnected

    Sep 10 09:57:37.214976 SEQ RecvClientMsg:jpppd-client session-id:4240 Opcode:3, Subcode:15 (SESSION_LOGOUT)

     



  • 5.  RE: Juniper MX104 : LNS Subsribers won't establish

    Posted 09-10-2020 03:24

    Thanks for the response.

     

    I've had them check their LAC for errors and any debugs but they are pretty sure the CPE device (end user) is terminating/ending the session to the our LNS not fully establishing the session.

     

    You mentioned the Tunnel. should it not be coming up in a tunnel?

     

    thanks again



  • 6.  RE: Juniper MX104 : LNS Subsribers won't establish

     
    Posted 09-10-2020 09:36

    Hello,

     

    First of all, you'll have to check your Radius server configuration.

    It seems your subscriber is trying to connect from LAC to LNS 5.5.5.5:

    Sep 10 09:57:36.926657 radius-access-request: Service-Type added: 2
    Sep 10 09:57:36.926700 radius-access-request: Framed-Protocol added: 1
    Sep 10 09:57:36.926740 radius-access-request: Tunnel-Type added: Tag () 3
    Sep 10 09:57:36.926777 radius-access-request: Tunnel-Medium-Type added: Tag () 1
    Sep 10 09:57:36.926814 radius-access-request: Tunnel-Client-Endpoint added: 123.0.0.1
    Sep 10 09:57:36.926849 radius-access-request: Tunnel-Server-Endpoint added: 5.5.5.5
    Sep 10 09:57:36.926883 radius-access-request: Tunnel-Assignment-ID added: 33886
    Sep 10 09:57:36.926919 radius-access-request: Tunnel-Client-Auth-ID added: lts.01
    Sep 10 09:57:36.926953 radius-access-request: Tunnel-Server-Auth-ID added: Cust24
    Sep 10 09:57:36.926987 radius-access-request: Chargeable-User-Identity added:
    Sep 10 09:57:36.927024 radius-access-request: Acct-Tunnel-Connection added: 0018019557
    Sep 10 09:57:36.927057 radius-access-request: Acct-Session-Id added: 4240
    Sep 10 09:57:36.927092 radius-access-request: Calling-Station-Id added: BBEU07295297
    Sep 10 09:57:36.927132 radius-access-request: DHCP-MAC-Address (Juniper-ERX-VSA) added: 0000.0000.0000
    Sep 10 09:57:36.927172 radius-access-request: NAS-Identifier added: Cust24
    Sep 10 09:57:36.927204 radius-access-request: NAS-Port added: 10 00 0f ff
    Sep 10 09:57:36.927246 radius-access-request: NAS-Port-Id added: Ip:5.5.5.5:123.0.0.1:33886:8829:62417:1317:18019557
    Sep 10 09:57:36.927275 radius-access-request: NAS-Port-Type added: 5
    Sep 10 09:57:36.927311 radius-access-request: L2tp-Tx-connect-speed (Juniper-ERX-VSA) added: 1881000
    Sep 10 09:57:36.927348 radius-access-request: L2tp-Rx-connect-speed (Juniper-ERX-VSA) added: 723000
    Sep 10 09:57:36.947503 radius-access-request: Client-Profile-Name (Juniper-ERX-VSA) added: DYN-PROF-1:
    Sep 10 09:57:36.947622 radius-access-request: PPPoE-Description (Juniper-ERX-VSA) added: pppoe 00:00:00:00:00:00

     Then this subscriber is authenticated successfully, but Radius profile received on MX includes a set of tunnel attributes again, which instructs MX to tunnel this subscriber to LNS 5.5.5.5 (e.g. LTS scenario):

    Sep 10 09:57:36.972143 Parsing RADIUS message for session-id:4240
    Sep 10 09:57:36.976694 radius-access-accept: Tunnel-Password received: ""
    Sep 10 09:57:36.976775 radius-access-accept: Tunnel-Server-Endpoint received: 5.5.5.5
    Sep 10 09:57:36.976813 radius-access-accept: Framed-IP-Address received: 192.168.5.5
    Sep 10 09:57:36.976843 radius-access-accept: Tunnel-Client-Auth-ID received: lts.01
    Sep 10 09:57:36.976873 radius-access-accept: Tunnel-Type received: Tag () 3
    Sep 10 09:57:36.976903 radius-access-accept: Framed-IP-Netmask received: 255.255.255.255
    Sep 10 09:57:36.976934 radius-access-accept: Framed-Protocol received: 1
    Sep 10 09:57:36.976962 radius-access-accept: Tunnel-Medium-Type received: Tag () 1
    Sep 10 09:57:36.976991 radius-access-accept: Service-Type received: 2

     If you want to terminate this subscriber locally, please remove all Tunnel-* attributes for this subscriber when it authenticates on this MX.

     

    Please try and let us know the outcome.

     

    Best regards,

    Sergii

    -------------------------------------------------------------------

    Please accept the solution if your problem is resolved Smiley Happy

    -------------------------------------------------------------------



  • 7.  RE: Juniper MX104 : LNS Subsribers won't establish

    Posted 09-10-2020 13:05

    Thanks Sergii.

     

    You are right on what's happening. We have a few LNS devices connected to the same supplier (LAC) in various DC's   All initial radius requests come in over one central LNS and is then forwarded to our radius server.


    The radius server then responds with the accept and the appropriate tunnel-endpoint (LNS) for the user to connect to. The LAC side then forwards the radius request again to the correct tunnel-endpoint (in this case 5.5.5.5). The request comes in on 5.5.5.5 as another auth-request I guess so the tunnel-end-point is issued again but this time on the correct LAC where I would hope it should then fully estabish. This obviously isn't the case.

     

    So the difficulty we have is if we remove the tunnel attributes then the radius requests will never come in on this new Juniper LNS. They will simply connect to the initial lns instead if that makes sense.

     

    I've tried adding 'set access profile aaa-profile radius attributes exclude tunnel-server-endpoint access-request' to the config in the hope it would ignore the tunnel-endpoint issues by the radius server but no luck.

     

    Is there a way to get the juniper to just ignore the tunnel attributes delivered by radius?

     

    Thanks again for all your help

     

     



  • 8.  RE: Juniper MX104 : LNS Subsribers won't establish

     
    Posted 09-10-2020 13:20

    Hello Busby,

     

    Unfortunately, you don't have a choice - it's not possible to force JUNOS to ignore half of attributes in Access-Accept and use another half. Not sure which Radius you're using, but in Freeradius it's possible to have multiple profiles for the same username and choose between them based on NAS-IP-Address:

    l2tp    Cleartext-Password := "spirent", NAS-IP-Address == "10.1.6.1"
            Service-Type = Framed-User,
            Tunnel-Client-Endpoint:1 += 10.1.1.1,
            Tunnel-Server-Endpoint:1 += 10.1.1.3,
            Tunnel-Type:1 += l2tp,
            Tunnel-Medium-Type:1 += IP
    
    l2tp    Cleartext-Password := "spirent", NAS-IP-Address == "10.1.6.3"
            Service-Type = Framed-User

     It should be part of basic functionality and your Radius server should support it as well.

     

    Best regards,

    Sergii

    -------------------------------------------------------------------

    Please accept the solution if your problem is resolved Smiley Happy

    -------------------------------------------------------------------



  • 9.  RE: Juniper MX104 : LNS Subsribers won't establish

     
    Posted 09-10-2020 13:30

    I must also admit I do not fully understand your design. Can you please elaborate a bit more here?


    All initial radius requests come in over one central LNS and is then forwarded to our radius server.

    So the first tunnel is built from any LAC to your central LNS. Then somehow your central LNS informs LAC that the existing tunnel needs to be torn down, and another LNS should be used (not sure how such behavior is possible though).




    The radius server then responds with the accept and the appropriate tunnel-endpoint (LNS) for the user to connect to. The LAC side then forwards the radius request again to the correct tunnel-endpoint (in this case 5.5.5.5). The request comes in on 5.5.5.5 as another auth-request I guess so the tunnel-end-point is issued again but this time on the correct LAC where I would hope it should then fully estabish. This obviously isn't the case.

    Not sure how many tunnels and between which nodes you're expecting to have here.

     

    Best regards,

    Sergii

    -------------------------------------------------------------------

    Please accept the solution if your problem is resolved

    -------------------------------------------------------------------

     



  • 10.  RE: Juniper MX104 : LNS Subsribers won't establish

    Posted 09-10-2020 15:09

    thanks again. we do use freeradius so I’ll see about making those changes and will update if it works thanks.

     

    In regards to the design. its just the initial radius request which gets forwarded through our main LNS and then straight to our radius server. No tunnel is built on that LNS unless the radius responds with the appropriate tunnel endpoint.

     

    Once the tunnel endpoint IP is sent back to the lac of the appropriate LNS then the lac simply resends the radius request through that LNS instead to build the tunnel.

     

    strangely this works fine on our cisco lns devices using this design. not sure why or how they get around it? I agree that this certainly seems to be the issue.

     

    hopefully a change on radius config will help. i’ll definitely update 🙂

     

    thanks



  • 11.  RE: Juniper MX104 : LNS Subsribers won't establish

     
    Posted 09-11-2020 02:32

    Hello Busby,

     

    You're more than welcome. If no tunnel is built on your central LNS, then, based on your description, it works as a Radius proxy to your Radius servers. From Radius server configuration perspective, this Radius proxy (or central LNS) should receive set of user attributes required for tunneling, and all other LNSs should receive all attributes required for local termination of this subscriber.

    l2tp    Cleartext-Password := "spirent", NAS-IP-Address == "10.1.6.1" <=== Central LNS IP
            Service-Type = Framed-User,
            Tunnel-Client-Endpoint:1 += 10.1.1.1,
            Tunnel-Server-Endpoint:1 += 10.1.1.3,
            Tunnel-Type:1 += l2tp,
            Tunnel-Medium-Type:1 += IP
    
    l2tp    Cleartext-Password := "spirent", NAS-IP-Address == "10.1.6.3" <=== LNS where this subscriber will be locally terminated.
            Service-Type = Framed-User

     

     

    Best regards,

    Sergii

    -------------------------------------------------------------------

    Please accept the solution if your problem is resolved Smiley Happy

    -------------------------------------------------------------------



  • 12.  RE: Juniper MX104 : LNS Subsribers won't establish
    Best Answer

    Posted 09-11-2020 12:24

    Hi, I've now managed to get this working. We were not able to create seperate profiles on freeradius due to the NAT IP affectively being the same regardless as to which LNS the sessions were steered to.

     

    In the end I managed to tell the MX104 to ignore just the tunnel-attributes of the radius request with the below lines:

     

    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 standard-attribute 90
    set access profile aaa-profile radius attributes ignore standard-attribute 65

     

    Once done it worked fine. 

     

    Thanks again for all your help



  • 13.  RE: Juniper MX104 : LNS Subsribers won't establish

     
    Posted 09-11-2020 13:21

    Hello Busby,

     

    Thank you for sharing your result! It seems to be a recently introduced feature and it's good to know that it's working as designed. I'd also suggest accepting your own post with the solution as the solution just to mark this question as resolved.

     

    Best regards,

    Sergii

    -------------------------------------------------------------------

    Please accept the solution if your problem is resolved

    -------------------------------------------------------------------