Replies: 4 comments
-
Hi @hellracer, yes. This feature available only with radius Framed-Route attribute. We did not get similar feature requests, so maybe it is not pretty useful. On the other hand, to implement this, we have to change chap-secrets format, and I think it is not suitable |
Beta Was this translation helpful? Give feedback.
-
The use case of this is more of a convenience because not everyone can setup a radius server and you don't have to define the frame-ip-address statically just to route additional IP block. In an ISP setup with many IP block at your own disposal, we don't NAT the IP pool we just route the public ip block to use it as a LAN address of the customer. Even though similar functionality is available today with radius, this will complicate thing and a major step back in workflow for us because you have to define/maintain the framed-ip-address statically VS just define the additional IP block and be done with it. I don't know if we are just spoiled with MT implementation. :) Just my 0.2$ |
Beta Was this translation helpful? Give feedback.
-
If you want you can try to resolve this with custom scripts pppd_compat module |
Beta Was this translation helpful? Give feedback.
-
Thanks, will certainly try this though we prefer if this can be bake with seamless with VYoS 💯 |
Beta Was this translation helpful? Give feedback.
-
I don't know if this is the right place to ask this, but here it goes anyway, In Mikrotik / ROS implementation of PPPPoE there's a convenient option called "route" which allows you to route additional IP block once the pppoe client is authenticated, today we can do this via radius authentication in accel-ppp by using frame-ip-address and framed-route but not possible without radius authentication
Beta Was this translation helpful? Give feedback.
All reactions