![[Figure]](xmlconf.gif)
Figure 1: Overview of system specifications
CESNET technical report number 7/2002
also available in PDF,
PostScript, and XML
formats.
Petr Holub
2002-06-29
This document specifies architecture of the router configuration system we are developing as part of the IPv6 router project, includes specifications for the system and basic system architecture overview.
In nowadays networks administrators have usually many types of routers and even on one type of a router many versions of routing software with different configuration syntaxes can be run. Our software targets such an environment to ease and simplify administration and to make it less error-prone. With configuration stored in XML format and XSLT transformation templates provided it should be easier to generate configuration for specific router. This will allow the system to do more thorough semantic and consistency checks to avoid certain kind of errors. By providing web interface as well as command-line interface for router configuration we hope to have system that will allow router reconfiguration even from mobile devices.
Router configuration system will use XML as its primary format for storing router configuration. We have to provide XML transformation definitions for transforming to and from XML format at least for following routers:
Figure 1: Overview of system specifications
XML will be stored in central repository that will be able to provide versioning capabilities.
We will provide to ways for working with router configuration: command-line interface (CLI) and web interface (WWW). Web interface won't have to necessarily implement all the configuration features. System will use SNMP as one of possible ways for polling devices about their current state and configuration.
Configuration will be uploaded to router by producing configuration file for specified router (depending on router brand/type). Configuration can be applied either manually or using common services like TFTP and BOOTP. SNMP might be also used for basic configuration setting.
In some later stage we would like to provide some scheme called metaconfiguration that will allow administrator to configure whole network. This will apply some constraints on router configuration and thus minimize probability of router misconfiguration.
![[Figure]](arch-01.gif)
Figure 2: Architecture overview
For definition of XML configuration format we will use XML Schema because of two major reasons:
We will define two XSLT transformation sets: first one to produce XML configuration file for the each configuration interface and second to import and export configuration files of common formats. When exporting Cisco configuration system must take into account situation when commit is performed after each end of line and therfore it must adjust proper order of configuration steps. We might need to enhance XSLT format and XSLT processor used to support all the features needed.
Each configuration interface (CLI, web) will have at least one XML configuration file associated. This file will define set of available commands, their appearance etc. XSLT transformation will therefore work on definition of XML structure using XML Schema. These transformations will be performed only on change of XML structure definition or XSLT definition. Otherwise pre-generated version will be used to speed up process of configuration interface startup.
The other set of transformations will work on XML file with router configuration which will allow us to import and export router configuration files (e.g. Cisco, Juniper, PC router - ifconfig/route/gated/zebra), to check differences between configuration on the router and configuration stored in XML etc. These transformations will work on XML file with actual router configuration.
![[Figure]](arch-02.gif)
Figure 3: XML definition and transformation
We don't want to develop our own XML and XSLT parsers unless absolutely necessary since we think some publicly available parsers are of sufficiently high quality. Currently Xerces library for XML, DTD and XML-Schema parsing and Xalan library for XSLT processing (both by xml.apache.org project) seem to be the most convenient for our project. We would like to have most of our code written in C / C++.
CVS will serve as basic repository for our files which include XML structure definition, XML files with router configuration, XSLT files and XML files for configuration of interfaces behavior. We have to add three features to CVS: authentication and authorization service, XML validation, and xmldiff capabilities. Authentication and authorization has to sort out situation when user is allowed to modify not entire file but just some parts of it (e.g. situation when user is allowed to configure only properties of router interfaces to some limited extent). XML validation will ensure that changes committed to CVS are valid XML according to XML structure specification1. xmldiff should improve CVS diff capabilities with respect to the structure of files stored in the repository.
In further text we will use terminology common in CVS environment:
Core libraries for the project will provide following functionalities:
We want to have all the router configuration and management functions available in CLI. CLI will provide support for editing XML document (e.g. showing list of elements allowed in current context, filling values of some elements when writing).
When starting to edit XML in CLI user specifies either to check out some specified version from CVS repository or to work on local repository (usually checked out during some previous session). This allows user to work off-line without having network access to CVS repository. User performs necessary modifications and commits the results back in CVS repository and then applies the configuration to the specified router. There has to be possibility of applying configuration to the router without committing results to the repository but commit to the repository should be done as soon as possible because of possible version conflicts.
Applying configuration will be done manually by generating configuration file that will be transferred to the router either by TFTP or BOOTP or by cut-and-paste method. In case of PC router when CLI can run on the router configuration can be applied directly. In further versions we would like to implement some direct connection to the router via telnet or ssh or even serial line. In any case the system should work with privileges of current user to avoid any privilege escalation issues. System should check version of configuration currently in operation on the router to warn user when applying configuration that was edited in the meantime by someone else in the repository and was not applied to the router.
User will be able to poll device state by SNMP means in CLI.
Web interface will be based on Apache web server with SSL access using mod_ssl. Web server can run either on the router or on some other machine. Since HTTP protocol is stateless by its nature we will have to create session management on per-user basis that will allow user to do several subsequent modifications before committing the results to the CVS repository. Applying configuration to the router will be performed in similar way to CLI. Web interface will have version optimized for viewing on mobile devices.
Because of the web interface limitations we will implement just basic configuration options:
Routine management will consist of following steps:
It should be possible to reconfigure router even from PDA by using web configuration interface and some browser on PDA.
Setting up a new router will consist of following steps:
Recovering router after crash might consist of similar steps as setting-up a new router except for creating configuration for the new router. On the other hand if router brand or type changed after the crash (e.g. router was replaced by one from different vendor) configuring it should be rather easy because it involves creating configuration file for different brand/type using the same XML configuration.
Footnotes: