XML Router Configuration
Specifications and Architecture Document

CESNET technical report number 7/2002
also available in PDF, PostScript, and XML formats.

Petr Holub
2002-06-29

1   Abstract

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.

2   Introduction

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.

3   Specifications

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:

This will allow us not only to configure the router but to import current configuration of the router to XML file and to see the differences between configuration of the router stored in CVS and the actual configuration of the router.
[Figure]

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.

4   Proposed system architecture

[Figure]

Figure 2: Architecture overview

4.1   XML definition and transformations

For definition of XML configuration format we will use XML Schema because of two major reasons:

Except for specified configuration elements XML definition will contain some non-interpreted element for administrator to be able to store configuration data that are not available in the definition. We will require fixed order of elements in XML which we think it's less error-prone and better for manipulation.

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]

Figure 3: XML definition and transformation

4.2   System components

4.2.1   XML parsing

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++.

4.2.2   XML repository

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:

4.2.3   Core libraries

Core libraries for the project will provide following functionalities:

4.3   CLI

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.

4.4   Web interface

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:

5   Use cases

5.1   Routine router management

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.

5.2   Setting-up a new router

Setting up a new router will consist of following steps:

5.3   Recovering router after crash

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:
  2. As we want to preserve full compatibility with CVS we have to take into account situation when user commits changes to the repository using ordinary CVS client that does no XML validation. Therefore XML validation has to be done before placing into the repository as well.
další weby:fond rozvojemetacentrumCzechLightpřenosyvideoservereduroameduID.cz