Monday Apr 03, 2006

Guide to the current quagga ON changes

proposed ON changes for quagga project

Note: this is a guide to the changes as they are today, and things may of course change - we're still a bit way from code review. The following is a guide to help people navigate the code and get up to speed on what we're trying to do. Referring to the design document will probably be helpful.

The ON changes involve a number of different components:

  1. changes to routeadm.c to support SMF services
  2. addition of ipv4(6)-routing(forwarding) SMF services
  3. addition of value/manage authorizations for routing services
  4. service conversions for in.routed, in.ripngd, in.rdisc and in.ndpd

changes to routeadm.c to support SMF services

These changes involved:

  • extending the functionality of the enable/disable (-e/-d) flags for routeadm to cover SMF services as well as the keywords ipv4-routing, ipv6-routing etc. In the former case, the named SMF service is checked to ensure if it is indeed a routing daemon service (identified by the presence of the "routing" application property group), and if so it is enabled disabled as specified immediately. If ipv4-routing/ipv6-routing etc is specified, the appropriate value is enabled/disabled in routing.conf as before. When "routeadm -u" (update) is run, these state changes are applied.
  • adding list/modify functionality for SMF routing services. In the case of "list", we check if the SMF service is a routing service (see above), and if so, list all the "routing" application properties. For modify, the user specifies a list of key=value properties (that must already exist - no routing properties can be created) along with the routing service FMRI.
  • adding the list of routing daemon services and their states to the routeadm output. Again, these are identified by presence of a "routing" application property group.
  • interacting with ipv4(6)-routing(forwarding) SMF services. When update (routeadm -u) is run, the states of the ipv4(6)-routing(forwarding) services are updated to match those specified in routing.conf. If a service is already enabled, it is restarted (to get updates to daemon arguments for example).
  • supporting upgrade. The new SMF commands will not run during upgrade, so instead they append themselves to /var/svc/profile/upgrade to be run post-upgrade. Upgrade is detected by specification of an alternate root (routeadm -R ) and by the fact that the SMF repository door is not present.


addition of ipv4(6)-routing(forwarding) SMF services

These services need to set ip forwarding flags in the case of ip forwarding services, and for ip routing, they needed to support legacy behaviour. So, for routing services, they check the contents of the ipv4(6)-routing-daemon ipv4(6)-daemon-args and ipv4(6)-daemon-stop-cmd fields in routing.conf. If the contents of these are upgradeable (either to SMF versions of in.routed etc, or to quagga equivalents for zebra daemons), the fields are blanked and the appropriate SMF routing service is enabled. For quagga services, the zebra configuration files are also migrated to /etc/quagga. If the daemon invokations are not upgradeable, for enable, the appropriate daemon is invoked and it's pidfile created. For disable, the stop command is run.

forwarding.xml routing.xml

addition of value/manage authorizations for routing services

We create 2 new authorizations in connection with SMF routing services - one covers the changing of routing service states, solaris.smf.modify.routing. All routing-related services should specify this authorization in the "general" property group, to let SMF know it is needed to run the methods for that service. The other new authorization, solaris.smf.manage.routing covers changing of routing service properties (needed for "routeadm -m" to work - see above). We need to augment the network management rights profile to include these new authorizations, as routing management is a part of network management.

prof_attr.txt auth_attr.txt

Examples of converted services are below.

service conversions for in.routed, in.ripngd, in.rdisc and in.ndpd

All the above are converted to SMF. Each has to have a "routing" property group of type "application" to identify itself as a routing service. Within this, each specifies daemon_args - the arguments to run the daemon with. Since this property is within the routing property group, it is available to "routeadm -m" to modify. We ensure each service method specifies it requires the routing authorization (so the user requires this auth to update state of routing services), and that the routing property group specifies the routing value authorization (so the user requires this auth to change values).

in.ndpd conversion: ndp.xml svc-ndp

in.ripngd conversion: ripng.xml svc-ripng

in.rdisc conversion: rdisc.xml svc-rdisc

in.routed conversion: route.xml svc-route

Tuesday Oct 25, 2005

Quagga design review active

We've posted the design document for the quagga/routing management design review over at opensolaris , and are really hoping people will have comments and suggestions. I might discuss some of the rationale behind the current SMF routing management design here in depth if it would be helpful, but the basic idea was to retool routeadm(1M) to both support SMF routing services and to take advantage of the framework SMF provides in it's own architecture.

The former involved extending routeadm's syntax in an inteadm-like manner to allow enabling and disabling of SMF routing dameon services, and setting/retrieval of SMF routing daemon service properties.

The latter involved creating services to match each routeadm option (ipv4(6)-routing, ipv4(6)-forwarding) which routing daemons can depend on, and creating an overall "routing-manager" service. Creating services to match these options allows SMF routing daemons to depend on global routing/forwarding settings through SMF dependencies, and creating a routing-manager service allows routing management to be split out from the network-initial service to further parallelism during boot. More details in the pdf itself of course, and to reiterate, we really want to hear what you think.

And as is mentioned, there will also be opportunities to collaborate further down the line, if people are interested - maybe, for example, you'd like to provide an SMF manifest for in.routed. But for now, as meem points out for Clearview, you've got a chance to influence the design whether you work in Sun or not, and are seeing the design document at the same time as internal folks are.




« July 2016