> I agree that it'd be nice to have a single service to represent "start > computing routes" and have the detail of whether those routes derive > from static or dynamic sources be just part of the service > configuration.
in that case, it sounds like we need routeadm to support 4 "routing state"-related variables, stored in a property group in the network/routing service: - dynamic_routing (if true, protocol daemons can run) - ipv4_dynamic_routing (if true, v4 protocol daemons can run) - ipv6-dynamic_routing (the v4/v6 distinction being maintained for historic reasons) - static_routing so users could do any of the following: # routeadm -e ipv4_routing (for backwards compatibility) # routeadm -e ipv4_dynamic-routing either of these would, on application of properties (through "routeadm -u" or "svcadm refresh routing") allow dynamic routing daemons to run. also supporting the general # routeadm -e dynamic_routing would be good too it seems. and finally, # routeadm -e static_routing would, on application of "routeadm -u" or refresh of network/routing, apply the persistent static routes added as properties to the network/routing service through route (1M). should routeadm's output report these persistent static routes in addition to the dynamic routing daemon states perhaps? note that services that carry out static routing could perhaps be disabled also on disable of static_routing (though some like zebra:quagga are also needed in dyamic_routing, so we could only safely disable static-only services). this would allow users the "big hammer" of disabling all routing, static and dynamic via disable of the network/routing service, and allow them to distinguish between static and dynamic (and v4 and v6 in the latter case for backwards compatibility) through routeadm. thoughts? alan This message posted from opensolaris.org
