What actually bothers you, that router (i.e. the default gateway) is requested even though you the client is told not to use it, or that it is used?
Both router and classless-route are requested regardless the add-default-route value, what differs is how the client uses the received values. And to say it all, the name of “use default route” is a historic one, it should actually read “use routing info”.
So to request the classless route, you do not need to set add-default-route to special-classless. This value only says “even if you do receive the classless route, use the value from router as well if you receive it”, which is a behaviour which the classless route RFC normally prohibits.
So by setting add-default-route=special-classless you actually say do use the router if it is there, regardless whether classless-route is received and used; by setting add-default-route=yes, you ask the client to only use the value from classless-route if it is present in the response and ignore the value of router if present as well, and only the value from router if it is present but classless-route is not. And by setting add-default-route=no, you ignore any of the two.
And the value of default-route-distance is used also for all the routes provided by classless-route.
its actually simple to explain and probably in depency of the missing management feature inside an vrf:
we use for our customer one servicechannel (l3vpn or internetaccess) and one for management. (2 different vlan´s with 2 different destinations of course )
so because of the missing management feature inside an vrf, i cannot accept more than one default-route. (of course i can work with the distance..)
therefore for Management i push opt 121 to reach the ACS and dont Need an default-route.
anyway i can work without the feature.. but would be probably nice to have it seperatly requestable..
Does your DHCP server in the management VLAN change the contents of Option 121 in its responses depending on whether Option 3 was or was not requested by the client?
If it doesn’t, i.e. if it constantly provides the gateway for (implicit) prefix 0.0.0.0/0 in Option 3 and the gateway(s) for some other, longer, prefix(es) in Option 121, then just configure the DHCP client in the management VLAN with add-default-route=yes. In this case, your DHCP server will return both Option 3 and Option 121, but the Mikrotik’s DHCP client will ignore the contents of Option 3 and only add to its routing table the routes from Option 121. (As said - add-default-route is actually a historic name which is now confusing because it doesn’t reflect the actual behaviour any more).
What I’ve just described is the intended behaviour, as RFC3442 states:
If the DHCP server returns both a Classless Static Routes option and a Router option, the DHCP client MUST ignore the Router option.
So if you configure the client this way using add-default-route=yes and it behaves different from the description above, it is a bug and a support ticket needs to be open.
ROS client works as sindy described, “router” option is ignored if option 121 is received form the server. Exception is if add-default-route=special-classless is set, then “router” option is not ignored.
understood! - just checked it out with add-default-route where opt 121 are also offered.
had to disable and enable the Interface…
it works! - the description “add-default-route” made me crazy.
)