Routing

 View Only
last person joined: 19 hours ago 

Ask questions and share experiences about ACX Series, CTP Series, MX Series, PTX Series, SSR Series, JRR Series, and all things routing, including portfolios and protocols.
Expand all | Collapse all

L2TP tunnel subscribers in different VRF

  • 1.  L2TP tunnel subscribers in different VRF

    Posted 05-07-2019 04:25

    Hi all,

     

    My company has a l2tp tunnel service with a company that delivers Digital Subscriber Lines to our network.

    The DSL CPE's connect to our network via PPPoE which is, with a specific suffix, is sent and encapsulated in l2tp to our network.

     

    Recently a requirement came up where this CPE needs to have it's PPPoE session established in a different routing-instance (VRF).

    Usually, I use the Virtual-Router VSA to put this session in a different routing-instance rather than the default one.

     

    The Junos documentation (https://www.juniper.net/documentation/en_US/junos/topics/topic-map/radius-std-attributes-vsas-support.html#id-aaa-access-messages-and-supported-radius-attributes-and-juniper-networks-vsas-for)  says:

    "For L2TP tunnel subscribers, it is the routing instance in which the tunnel resides, whether default or non-default. If the tunnel routing instance is not default and you want the L2TP session to be in the default routing instance, you must use the Virtual-Router VSA to set the desired routing instance."

     

    Does this mean that I need another l2tp tunnel inside a different routing-instance in order to use the Virtual-Router attribute with a different value than default to get this to work?

    Or should the Virtual-Router attribute work anyway, because right now it doesn't.

     

    Hopefully you can help me with this one.

     

    My configuration:

    show services l2tp    
    tunnel-group L2TP-TG {
        l2tp-access-profile L2TP-LAC-PROFILE;
        aaa-access-profile L2TP-USER-AUTH;
        local-gateway {
            address xx.xx.xx.xx;
        }
        service-interface si-1/0/0;
        dynamic-profile L2TP-SUBSCRIBER;
    }
    tunnel {
        assignment-id-format client-server-id;
    }
    
    
    group-profile L2TP-USER-GROUP-PROFILE {
        ppp {
            ppp-options {
                pap;
                chap;
            }
            keepalive 60;
        }
    }
    profile L2TP-USER-AUTH {
        authentication-order radius;
        radius {
            authentication-server xx.xx.xx.xx;
        }
        radius-server {
            yy.yy.yy.yy {
                secret "test"; ## SECRET-DATA
                source-address zz.zz.zz.zz;
            }
        }
    }
    profile L2TP-LAC-PROFILE {
        client bras04.edpnet.net {
            l2tp {
                lcp-renegotiation;
            }
            user-group-profile L2TP-USER-GROUP-PROFILE;
        }
    }


  • 2.  RE: L2TP tunnel subscribers in different VRF

     
    Posted 05-07-2019 04:39

    Hello,

     

    It seems your objective is to terminate tunneled PPPoE subscribers from L2TP Access Concentrator (LAC) on your L2TP Network Server (LNS) in a different routing-instance (VRF). I assume that currently all tunneled PPPoE subscribers are terminated in the default routing-instance on LNS, and it's working fine.

     

    In order to proceed, could you please provide configuration of dynamic profile used for these subscribers (L2TP-SUBSCRIBER), and Radius profile that you used when you tried to terminate subscribers in a VRF?

     

    Best regards,

    Sergii



  • 3.  RE: L2TP tunnel subscribers in different VRF

    Posted 05-07-2019 05:04

    Hi Sergii,

     

    You're explanation is much better and cleaner, thank you 🙂

     

    L2TP-SUBSCRIBER 

     

    marijn@core-ixn-be-01# show dynamic-profiles L2TP-SUBSCRIBER 
    predefined-variable-defaults {
        input-filter police-unlimited;
        output-filter police-unlimited;
    }
    routing-instances {
        "$junos-routing-instance" {
            interface "$junos-interface-name";
            routing-options {
                access {
                    route $junos-framed-route-ip-address-prefix {
                        next-hop "$junos-framed-route-nexthop";
                        metric "$junos-framed-route-cost";
                    }
                }
                access-internal {
                    route $junos-subscriber-ip-address {
                        qualified-next-hop "$junos-interface-name";
                    }
                }
            }
        }
    }
    interfaces {
        "$junos-interface-ifd-name" {
            unit "$junos-interface-unit" {
                dial-options {
                    l2tp-interface-id l2tp-encapsulation;
                }
                ppp-options {
                    chap;
                    pap;
                    mru 1450;
                    mtu 1450;
                }
                keepalives interval 60;
                family inet {
                    filter {
                        input "$junos-input-filter";
                        output "$junos-output-filter";
                    }
                    address xx.xx.xx.xx/yy;
                }
            }
        }
    }
    

    10720 user@suffix Framed-IP-Address = 10.0.100.3
    10723 user@suffix Framed-Netmask = 255.255.255.255
    10771 user@suffix ERX-Redirect-VRouter-Name = default:routing-instance

    and of course the cleartext-password

     

     



  • 4.  RE: L2TP tunnel subscribers in different VRF

     
    Posted 05-07-2019 05:10

    Yes, Virtual-Router Attribute works fine. You can also use aaa domain map to terminate the subscriber in VRF.

     

    Regards,

    Rahul



  • 5.  RE: L2TP tunnel subscribers in different VRF

    Posted 05-07-2019 05:33

    Thanks Sergii and rnayar for replying.

    Version is 14.2R7-S9 btw.

     

    I'm aware of the Virtual-Router VSA, my dictionary forces me to use it as ERX-Virtual-Router-Name (VSA 26-1).

    The contents of this attribute is always logical-instance:routing-instance, so mostly default:routing-instance.

     

    In the logging I see this attribute in my access-accept packet I get back from the radius server.

    "routing-instance" is an existing routing instance.

     

    May  7 14:22:23.904 radius-access-accept: Framed-IP-Address received: 10.0.100.3

    May  7 14:22:23.904 radius-access-accept: Framed-IP-Netmask received: 255.255.255.255

    May  7 14:22:23.904 radius-access-accept: Virtual-Router (Juniper-ERX-VSA) received: default:routing-instance

    May  7 14:22:23.905 radius-access-accept: Ingress-Policy-Name (Juniper-ERX-VSA) received: police-unlimited

    May  7 14:22:23.905 radius-access-accept: Egress-Policy-Name (Juniper-ERX-VSA) received: police-unlimited

     

     

     

    Regarding the unnumbered IP, we're working towards a setup where all subscribers get the same gateway IP address with their PPPoE session. This works fine for us.

     

    And at last:

    user@core-ixn-be-01> show services l2tp tunnel extensive 
    Waiting for statistics...
      Tunnel local ID: 18521, Tunnel remote ID: 18323
        Remote IP: xx.xx.xx.xx:1701
        Sessions: 4, State: Established
        Tunnel Name: 1/2
        Local IP: yy.yy.yy.yy:1701
        Local name: core-ixn-be-01, Remote name: remote
        Effective Peer Resync Mechanism: silent failover
        Nas Port Method: none
        Tunnel Logical System: default, Tunnel Routing Instance: default
        Max sessions: 128100, Window size: 1024, Hello interval: 60
        Create time: Tue Mar  5 03:30:14 2019, Up time: 063 days,10:01:46
        Idle time: 00:00:00, ToS Reflect: Disabled
        Interface Name: si-1/0/0, Tunnel Group Name: L2TP-TG
        Statistics since: Tue Mar  5 03:30:14 2019
                            Packets        Bytes
          Control Tx          96.3k      1328.7k
          Control Rx         100.8k      2411.8k
          Data Tx            136.6M     69848.1M
          Data Rx            124.8M     20966.7M
          Errors Tx               0
          Errors Rx               3
    

     

     



  • 6.  RE: L2TP tunnel subscribers in different VRF

     
    Posted 05-07-2019 05:44

    Hello Beeelzebub,

     

    Thanks for providing these outputs. JUNOS subscriber management is not officially supported in 14.2R7-S9, and it may be the reason why you see this issue. Perhaps you need to plan upgrade to 15.1+ some time soon.

     

    Regarding the contents of ERX-Virtual-Router-Name (VSA 26-1), if it's set as "routing-instance", authd will process it as "default:routing-instance", if I'm not mistaken.

     

    As a last ditch effort, could you provide configuration of your "routing-instance" - maybe you have some issues there.

     

    Best regards,

    Sergii

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

    Please accept the solution if your problem is resolved Smiley Happy

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



  • 7.  RE: L2TP tunnel subscribers in different VRF
    Best Answer

     
    Posted 05-07-2019 05:47

    Hello Beeelzebub,

     

    Giving it a second thought, I believe the issue is caused by the fact that your fixed IP address in the dynamic profile is not available in VRF "routing-instance". Can you please try adding this IP address to the lo0.x interface, add this lo0.x interface to your VRF and check?

     

    Best regards,

    Sergii

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

    Please accept the solution if your problem is resolved Smiley Happy

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



  • 8.  RE: L2TP tunnel subscribers in different VRF

    Posted 05-07-2019 05:57

    Hi Sergii,

     

    We tried upgrading it to 15.1+, but we had some unexplanable issues that forced us to go back to this version.

    Here are the contents of the routing-instance (pretty straightforward if you ask me):

    routing-instance {
        instance-type vrf;
        no-vrf-propagate-ttl;
        route-distinguisher 202120L:2011;
        vrf-target target:202120L:2011;
        vrf-table-label;
    }

     

    Tried adding the IP address to the routing-instance, but no luck. Nothing has changed. 

     

    This setup works fine on non-L2TP-subscribers, so I'm not sure why this doesn't work.

    I mean, when I use "default" as the contents of the Virtual-Router attribute, the PPPoE CPE session establishes.

    Using any other *existing* routing-instance name, it doesn't.  



  • 9.  RE: L2TP tunnel subscribers in different VRF

     
    Posted 05-07-2019 06:08

    Hi Beeelzebub,

     

    Well, if it works for locally terminated PPPoE and doens't work for L2TP, I don't have any other idea regarding what else can be checked. Probably it's an issue with the unsupported release. In any case, even though 14.2 is working fine for you, I'd strongly recommend upgrading to 15.1+ release. There are additional steps that should be taken during such upgrade (and there are additional knobs to enable new generation subscriber management). You can open JTAC case and receive detailed instructions for this upgrade if you have any doubts, but, in my opinion, this is a proper way forward.

     

    Best regards,

    Sergii

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

    Please accept the solution if your problem is resolved Smiley Happy

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



  • 10.  RE: L2TP tunnel subscribers in different VRF

    Posted 05-08-2019 00:50

    Hey Sergii,

     

    Thanks for your last answer.

    Upgrading to a higher version is out of the question right now.

    Simply saying 14.2 is not supported doesn't help me. Is there a source that can confirm this?

     

    Below is what I briefly see when the subscriber is being processed. Only the States 'Init' and 'Termination' are being shown.
    It never applies the input and output filter policies defined in the profile (or sent with the Access-Accept packet).

    But even removing anything in the dynamic profile that has something to do with policies, doesn't work.

     

    Type: L2TP
    
    User Name: user@host.nl
    
    IP Address: 10.0.100.3
    
    IP Netmask: 255.255.255.255
    
    Primary DNS Address: 8.8.8.8
    
    Secondary DNS Address: 8.8.4.4
    
    Logical System: default
    
    Routing Instance: routing-instance
    
    Interface: si-1/0/0.1073744866
    
    Interface type: Dynamic
    
    Underlying Interface: si-1/0/0.1073744866
    
    Dynamic Profile Name: L2TP-SUBSCRIBER
    
    Dynamic Profile Version: 4
    
    State: Terminating
    
    Radius Accounting ID: 3046
    
    Session ID: 3046
    
    Login Time: 2019-05-08 09:38:54 CEST

     

    Also tried the domain map, doesn't seem to apply anything.

     

    What logging could I turn on to see what is happening with the subscriber?

     

    This is what I use now:

     

    how groups SUBSCRIBER-DEBUG-LOGGING                
    apply-flags omit;
    system {
        services {
            dhcp-local-server {
                traceoptions { ## Warning: 'traceoptions' is deprecated
                    file dhcp-local-server.log size 1m files 10;
                }
            }
            subscriber-management {
                traceoptions {
                    file subscriber-management.log size 1m files 5;
                    flag all;
                }
            }
        }
        auto-configuration {
            traceoptions {
                file auto-configuration.log size 1m files 5;
                level all;
                flag all;
            }
        }
        processes {
            general-authentication-service {
                traceoptions {
                    file general-authentication-service.log size 1m files 5;
                    flag radius;
                }
            }
            dhcp-service {
                traceoptions {
                    file dhcp-service.log size 1m files 10;
                    flag all;
                }
            }
        }
    }
    interfaces {
        traceoptions {
            file iflog size 2m files 2;
            flag change-events;
            flag config-states;
        }
    }
    protocols {
        ppp {
            traceoptions {
                file ppp.log size 1m files 5;
                level all;
                flag all;
            }
        }
    }

     

     



  • 11.  RE: L2TP tunnel subscribers in different VRF

     
    Posted 05-08-2019 01:20

    Hello Beeelzebub,

     

    There is an internal KB30328 which includes this information (I can try to make it public, but it will take a while anyway), please see the following excerpt:

    As of September 2016, the following are supported releases for Junos subscriber management functionality:
    
    GA for all customers:
    12.3R3 and subsequent 12.3R releases
    13.3R3 and subsequent 13.3R releases
    15.1F5-S1  (vMX ONLY)
    15.1R4 and subsequent 15.1R releases
    Future:  16.1R3 tentatively scheduled for Q1 2017

    What is the platform you're using, btw?

    You can try to enable the following traceoptions and compare them for working and non-working scenario (this list would be different for 15.1+ releases):

    set system processes general-authentication-service traceoptions file jtac-authd.log
    set system processes general-authentication-service traceoptions file size 100m
    set system processes general-authentication-service traceoptions file files 20
    set system processes general-authentication-service traceoptions flag all
    set services l2tp traceoptions file jtac-jl2tpd.log
    set services l2tp traceoptions file size 100m
    set services l2tp traceoptions file files 20
    set services l2tp traceoptions level all
    set services l2tp traceoptions flag all
    set protocols ppp-service traceoptions file jtac-jpppd.log
    set protocols ppp-service traceoptions file size 100m
    set protocols ppp-service traceoptions file files 20
    set protocols ppp-service traceoptions level all
    set protocols ppp-service traceoptions flag all
    set interfaces traceoptions file jtac-dcd.log
    set interfaces traceoptions file size 100m
    set interfaces traceoptions file files 20
    set interfaces traceoptions flag all

    Thanks,

    Sergii



  • 12.  RE: L2TP tunnel subscribers in different VRF

    Posted 05-08-2019 01:52

    Hi Sergii,

     

    Thanks for sharing the kb link.

    We're using the MX5 router, upgraded to MX80.

     

    I have added the l2tp logging and I am viewing the interface logs as well.

    l2tp logging is empty.

    interface logs shows a lot, but nothing special I think. Not sure what to look for.

     

    Btw domain mapping is matching, but then it doesn't send anything to my radius server.



  • 13.  RE: L2TP tunnel subscribers in different VRF

     
    Posted 05-08-2019 02:01

    Please share your routing-instance configuration. Do you have loop back configured under the RI?

     

     



  • 14.  RE: L2TP tunnel subscribers in different VRF

    Posted 05-08-2019 04:40

    Well...

    I added the loopback interface to the VRF, changed the hard-coded address statement to an unnumbered-address and the pppoe session on the CPE got established.

     

    Usually, a loopback interface is not required in a VRF, but apparantly for L2TP subscribers it is necessary.

    If anyone can explain me why this is, I would really like to know so I can take this into account the next time I deploy something like this.

     

    Thanks all for helping me with this one!



  • 15.  RE: L2TP tunnel subscribers in different VRF

     
    Posted 05-08-2019 04:50

    Hello Beeelzebub,

     

    Hmmm, I think I already asked you to perform this change (message #9 in this thread):

    Giving it a second thought, I believe the issue is caused by the fact that your fixed IP address in the dynamic profile is not available in VRF "routing-instance". Can you please try adding this IP address to the lo0.x interface, add this lo0.x interface to your VRF and check?

    In any case, I'm happy to hear that the issue is resolved - please mark one of the posts as the "Accepted solution" so others could benefit.

     

    In subscriber management environment, when PPP link is being negotiated between CPE and LNS, MX needs to have its own IP address in the target routing instance so it could use it during IPCP negotiation (when MX will present its own IP address and assign IP address to CPE).

     

    Best regards,

    Sergii

     



  • 16.  RE: L2TP tunnel subscribers in different VRF

     
    Posted 05-07-2019 05:48

    Hi,

     

    14.2 is not supported for subscriber management. Kindly upgrade the node to avoid any major impact.

     

    You can directly give the routing-instance name.

     

    Regards,

    Rahul



  • 17.  RE: L2TP tunnel subscribers in different VRF

     
    Posted 05-07-2019 05:17

    Thank you for providing this output. Can you please also mention the version you're using? I suspect that you'll have to adjust the following parts of your dynamic-profile.

    1) If it's 15.1+ (not sure about earlier releases), you don't need routing-options anymore:

    routing-instances {
        "$junos-routing-instance" {
            interface "$junos-interface-name";
            routing-options {
                access {
                    route $junos-framed-route-ip-address-prefix {
                        next-hop "$junos-framed-route-nexthop";
                        metric "$junos-framed-route-cost";
                    }
                }
                access-internal {
                    route $junos-subscriber-ip-address {
                        qualified-next-hop "$junos-interface-name";
                    }
                }
            }
        }
    }
     

    Instead:

        routing-instances {
            "$junos-routing-instance" {
                interface "$junos-interface-name";
            }
        }

    2) Usually it's better to use unnumbered-address instead of fixed IP:

                    family inet {
                        unnumbered-address "$junos-loopback-interface";
                    }

    3) ERX-Redirect-VRouter-Name = default:routing-instance is not Virtual-Router VSA. I believe you need:

    ERX-Virtual-Router-Name = "target_RI_name"

     

    HTH

     

    Best regards,

    Sergii

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

    Please accept the solution if your problem is resolved

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

     



  • 18.  RE: L2TP tunnel subscribers in different VRF

     
    Posted 05-07-2019 05:08

    Hello,

     

    There are multiple ways to terminate subscribers in VRF on LNS while keeping underlying L2TP tunnel in the default routing instance, and Virtual-Router VSA should work as well.

     

    While your scenario is a bit different from described in KB33453, I'd still recommend checking it out.

     

    Best regards,

    Sergii

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

    Please accept the solution if your problem is resolved Smiley Happy

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