We have a system where we authenticate DHCP clients based on DHCP option 82. This allows us to set a static IP for a service, which is not reliant on the CPE MAC or some other value which might change.
On our RADIUS server, we have taken advantage of the Framed-Route value so that we can assign additional subnets to be routed to the customer. The Mikrotik DHCP server takes the Framed-Route value and creates a “dynamic active static” route for those subnets with a gateway of the DHCP client IP. It’s a fantastic feature that makes for less manual configuration.
But only for non-Mikrotik CPEs. Mikrotik CPEs lose their default route, and only add routes for those Framed-Route values.
As far as I can gather/remember (it’s been a while since I investigated), the Mikrotik DHCP server also sends those Framed-Route values on to the client in the DHCP offer, as part of DHCP Option 121. As Chupaka eloquently stated in another post:
The issue is that ‘other brands’ does not follow RFC. RFC3442 clearly states: “If the DHCP server returns both a Classless Static Routes option and a Router option, the DHCP client MUST ignore the Router option.”
From what I have seen, an all Mikrotik environment would end up with those additional routes being routed to the CPE, and the CPE would only add (broken) routes for those subnets.
My apologies if I have made any mistakes in amongst this - it’s been a while since I investigated this behaviour, and only thought to post here after discussing a recent RouterOS release.
Has anyone else seen this behaviour, or gotten this working the way we intend to make it work?
Well, as for me, the problem is that Framed-Route value is used in Option121 (as well as in router’s dynamic routes), because those routes shouldn’t be ‘symmetric’.
Agreed, using the same RADIUS response value for those 2 behaviours seems like an unwanted “feature”.
I’ll lab it up and check the most recent bugfix release first to ensure it’s still showing the same behaviour - I’m seeing it on 6.39.3, the last bugfix release.
The issue persists. Framed-routes (dst-addresses with gateway as leased client ip address) sent by Radius Server to DHCP-SERVER to be dynamically installed on router are also sent via option 121 to dhcp-client which gets installed. This drops default-routes pushed to clients.
for an example:
device 1: linux - freeradius server with user, framed-ip, framed-route and delegated-ipv6-prefix
device 2: mikrotik RB - DHCP server with access to the freeradius
device 3: CPE dhcp client
CPE device successfully get framed-ip, network, mask, gateway
CPE device successfully receive delegated-ipv6-prefix and via ND get IPv6 WAN ip and gefault GW
MK DHCP server successfully add delegated-ipv6-prefix route into ipv6 routing table
MK DHCP server not add framed-route into ipv4 routing table (for PPPoE framed-route is installed in MK “device 2”)
So I think you should write to 