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 
-------------------------------------------------------------------
Yes, Virtual-Router Attribute works fine. You can also use aaa domain map to terminate the subscriber in VRF.
Regards,
Rahul
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
-------------------------------------------------------------------
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
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
-------------------------------------------------------------------
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
-------------------------------------------------------------------
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
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.
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
-------------------------------------------------------------------
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;
}
}
}
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
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.
Please share your routing-instance configuration. Do you have loop back configured under the RI?
@alex_kovalev, do we still need to configure below command?
set class-of-service interfaces xe-x/x/x unit 0 classifiers dscp default
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!
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
good morning everyone,
I'm looking for information about the 768k day in juniper and I can not find anything about it.
https://www.techradar.com/news/768k-day-may-cause-major-internet-outages
the equipment that I have is mx240 with the version of junos 10.4R7.5.
I have to worry about? Do I have to renew the MX? update the version of junos?
thanks since now!
Regards!
Hi Spuluka,
I think that command not show the maximum route that box can support.
Thanks and appreciate your feedback
Hi,
Does anybody know/have any experience with MX204 and SFP-1GE-FE-E-T? Do you know if 100Mbps rate is supported (ie. can the port connect to "legace" FE device)?