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

Reply via email to