When terminating PPP into VRF using Accel-VRF-Name radius attribute and with Framed-Route attribute in the radius reply message, the route provided by radius is installed into default routing table instead of the appropriate table corresponding to the VRF.
Example. Access accept packet:
May 04 10:57:52 vyos-lns-1 accel-l2tp[2044]: :: recv [RADIUS(1) Access-Accept id=1 <Service-Type Framed-User> <Framed-Route "192.168.254.0/24"> <Accel-VRF-Name "client">]
admin@vyos-lns-1:~$ show l2tp-server sessions
ifname | username | ip | ip6 | ip6-dp | calling-sid | rate-limit | state | uptime | rx-bytes | tx-bytes
--------+--------------------------+-------------+-----+--------+--------------+------------+--------+----------+----------+----------
l2tp0 | [email protected] | 192.168.0.2 | | | 176.59.63.33 | | active | 00:05:16 | 40.2 KiB | 4.1 KiB
admin@vyos-lns-1:~$ sho ip route
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP, T - Table, v - VNC, V - VNC-Direct, A - Babel, F - PBR, f - OpenFabric, > - selected route, * - FIB route, q - queued, r - rejected, b - backup t - trapped, o - offload failure
B>* 0.0.0.0/0 [20/0] via 10.20.2.2, eth1.427, weight 1, 4d18h55m
C>* 10.10.10.1/32 is directly connected, dum0, 4d18h55m
B>* 10.10.10.10/32 [20/0] via 10.20.2.2, eth1.427, weight 1, 4d18h55m
B>* 10.20.1.0/24 [20/0] via 10.20.2.2, eth1.427, weight 1, 4d18h55m
C>* 10.20.2.0/29 is directly connected, eth1.427, 4d18h55m
C>* 10.20.2.8/29 is directly connected, eth1.428, 4d18h55m
C>* 192.168.1.1/32 is directly connected, dum1, 4d18h55m
B>* 192.168.1.2/32 [20/0] via 10.20.2.9, eth1.428, label implicit-null, weight 1, 4d18h55m
K>* 192.168.254.0/24 [0/0] is directly connected, l2tp0 (vrf client), 00:01:12
admin@vyos-lns-1:~$ show ip route vrf client
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP, T - Table, v - VNC, V - VNC-Direct, A - Babel, F - PBR, f - OpenFabric, > - selected route, * - FIB route, q - queued, r - rejected, b - backup t - trapped, o - offload failure
VRF client:
C>* 20.20.20.20/32 is directly connected, dum2, 4d18h54m
B> 20.20.20.21/32 [20/0] via 192.168.1.2 (vrf default) (recursive), label 80, weight 1, 4d18h54m
- via 10.20.2.9, eth1.428 (vrf default), label implicit-null/80, weight 1, 4d18h54m
C>* 192.168.0.2/32 is directly connected, l2tp0, 00:00:16
The corresponding bug report has been raised at accel-ppp project as well: