As part of the Quagga OpenSolaris project, we've attempted to move routing management under SMF. Routing management is currently driven by the routeadm (1M) tool, which was designed to allow the configuration of routing daemons and ip forwarding settings so that these settings persist across reboot. routeadm specifies flags for IPv4 and IPv6 forwarding, which if on set the appropriate kernel ndd variables. Additionally, routeadm allows for the specification of IPv4 and IPv6 routing daemons which are started during the boot process (currently in the network/initial service).
Some concerns were expressed about the way we've modeled routing management in SMF, and I'd like to run over the approach again to get opinions from the SMF community (a previous design discussion was carried out on an internal alias prior to the existence of smf-discuss, so new eyes on the problem are very welcome!). I apologize in advance for the length of the mail but the devil is in the details in this case unfortunately. Details of the project, including design document, can be found at http://www.opensolaris.org/os/project/quagga/ Also, for context, some previous discussions relating to SMF aspects of the design on this alias can be found at: http://www.opensolaris.org/jive/thread.jspa?messageID=17471& http://www.opensolaris.org/jive/thread.jspa?messageID=25128& http://www.opensolaris.org/jive/thread.jspa?messageID=24483& http://www.opensolaris.org/jive/thread.jspa?messageID=24430& The current model we've implemented works as follows: routeadm is redesigned, and rather than setting ip forwarding flags and spawning routing daemons itself, it interacts with smf services that carry out these actions in their method scripts (routing daemons that have no smf counterpart still need to be spawned and monitored via pidfiles, as they were previously). We introduce four "global" routing-related services: svc:/network/routing/ipv4-routing svc:/network/routing/ipv6-routing svc:/network/routing/ipv4-forwarding svc:/network/routing/ipv6-forwarding as counterparts to the global routing/forwarding values reported by routeadm (and stored in /etc/inet/routing.conf) So the command "routeadm -e ipv4-forwarding -u" (enables ip forwarding in routing configuration file routing.conf, and applies the change to the running system) is the equivalent of svcadm enable ipv4-forwarding In this model, the start method of the ipv4-forwarding service does the work of setting the ip forwarding flags (this was done by the routeadm program in the past) - routeadm simply enables the ipv4-forwarding service, and it does the work. Similarly for ip routing, "routeadm -e ipv6-routing -u" (enables ipv6 routing in routing configuration file routing.conf, and applies the change to the running system) is the equivalent of svcadm enable ipv6-routing Again the start method of the ipv6-routing service does the work of actually spawning any legacy services not convertible to SMF, and of upgrading legacy services such as in.ripngd to their SMF counterparts. The advantage of modeling these flags as services are that - we can control global routing/forwarding settings through standard smf commands (svcadm enable/disable/refresh) as well as through the domain specific *adm tool - routeadam - we can make routing daemon execution conditional on the state of those services uaing dependencies. For routing daemons such as in.ripngd, this is valuable, since in.ripngd requires ipv6 forwarding flags to be switched on to run correctly. Having a dependency then on ipv6-forwarding ensures that the daemon will not run without these flags having been set. In addition, when you consider that the only supported way to launch routing daemons in a persistent manner in the past was via enabling ipv4(6)-routing, having routing daemon services depend on global routing settings will move this behaviour forward into SMF. Now an alternative here would be not to use SMF services, but instead have each routing daemon check the state of the routing/forwarding flags before starting. The key question here is if we want to expose the flags as services. Opinions on this would be greatly appreciated! One additional detail: initially we thought that simply modeling the global flags as services and having routing daemons depend on these would be sufficient to ensure that global routing/forwarding settings control routing daemon execution appropriately, however it was pointed out that this would result in daemon services being offline if their dependencies are disabled. Being offline in these circumstances is suggestive of configuration errors where there are none it seems, so we modified the design slightly to accomodate this (when the ipv4(6)-routing service is disabled now, it disables the enabled routing daemon services, noting them so they will be reenabled if/when ipv4(6)-routing is enabled again). Another possible area of difficulty is our use of -e/-d/-l/-m flags to respectively enable, disable, list properties and modify properties of smf services. We modeled this usage after inetadm, and since routaedm already used -e/-d flags this seemed to make sense. One downside of this is the need to overload the -e/-d flags in such a way as to have them take global routing/forwarding flag names, and routing daemon FMRIs. However, in our current model the naming of the global routing/forwarding services was deliberately chosen to map to the flag names, i.e. ipv4-routing maps to svc:/network/routing/ipv4-routing:default etc. Another concern with these flags is that, like in the inetadm case, they do not match svcadm's use of enable/disable keywords. However, we are constrained here in that routeadm already took these options, and we have to ensure backwards compatibility. Again opinions on this issue would be greatly appreciated! thanks for your help, and again, apologies about the level of detail! alan This message posted from opensolaris.org