AUTOMATED CONFIGURATION DISTRIBUTION IN VERINEC

∗

David Buchmann, Dominik Jungo, Ulrich Ultes-Nitsche

University of Fribourg

Chemin du Mus

ee 3, 1700 Fribourg, Switzerland

Keywords:

Network management, generated conﬁguration, runtime veriﬁcation, XML network speciﬁcation.

Abstract:

We present in this paper a system to conﬁgure networks. The Veriﬁed Network Conﬁguration (Verinec) project

aims to manage the complete network from one central XML database. This approach allows to test whether

the conﬁguration is usable prior to modify the setup of the real network devices.

The distribution of the conﬁguration is handled by the adaption module, a framework which can be extended

to support all kinds of services and devices. Applying the conﬁguration to each managed device within the

network requires conversion from the Verinec XML database into a format suitable for that device and send the

conﬁguration to the device using a protocol supported by that device. In this paper, we focus on the adaption

module.

1 INTRODUCTION

Administrating a network gets more and more dif-

ﬁcult with increasing size of the network. Besides

routers and switches, one ﬁnds different servers and

ﬁnally workstations that need to be conﬁgured. All

conﬁguration should be consistent for the network to

run smoothly. Moreover, each managed device comes

with its own administration tool. Conﬁguring every

machine on the network manually is error prone and

makes it hard to maintain an accurate documentation

of the network.

With the Verinec project (Ultes-Nitsche et al.,

2005), we aim to build a solution for centrally ad-

ministrating large heterogeneous networks. Having

a central administration tool is not merely a conve-

nience for the administrator, but can be used to ensure

a consistent setup. This will augment both reliability

and security of the network.

1.1 Verinec Overview

Verinec is based on a central network deﬁnition that is

independent of the products currently used. Our inter-

nal representation is expressed in XML. Every man-

ageable networking element is uniformly considered

∗

The VeriNeC project (Ultes-Nitsche et al., 2005) is

funded by the Swiss National Science Foundation.

as a node, for example a router or a server computer

providing several services. Several modules are built

around this language.

There is a module to deﬁne the network. It con-

tains an editor to create and conﬁgure nodes and the

network layout. However, in many cases, the network

already exists. Thus we built a sniffer module that

analyses the network trafﬁc to detect nodes. For this

purpose, we use JPCap (Charles, 2005). Then we use

the portscanner Nmap (Fyodor, 2005) to detect ser-

vices running on the found hosts. With the results of

the port scan and an administrator providing the nec-

essary authentication details, the analysis of hosts can

continue. Verinec can parse conﬁguration ﬁles or use

the Simple Network Management Protocol (SNMP)

to determine the exact conﬁguration of the services

detected with Nmap. Finally, the user will have to use

the editor to manually correct the parts which could

not be automatically detected.

One big advantage of having accurate knowledge

of the complete network conﬁguration is that we can

verify its correctness. Our approach is not a math-

ematical veriﬁcation, but Runtime Veriﬁcation (Bar-

ringer et al., 2004) on the simulated network. We

simulate the network and test whether it behaves as

expected.

Additionally, we cross-check whether the settings

of different nodes are consistent and try to detect po-

304

Buchmann D., Jungo D. and Ultes-Nitsche U. (2005).

AUTOMATED CONFIGURATION DISTRIBUTION IN VERINEC.

In Proceedings of the Second International Conference on e-Business and Telecommunication Networks, pages 304-309

DOI: 10.5220/0001410103040309

 SciTePress

tentially dangerous settings using rulesets.

Verifying the conﬁguration of a network helps

build more reliable networks, as conﬂicting or poten-

tially problematic setups are detected, for example if

the default gateway setting of one machine points to

no existing host within the network. We can also en-

sure policies like “This machine may not access hosts

on the Internet, but must have access to the intranet

web server.” We also increase the security of a net-

work, because risks, e.g. unnecessary running ser-

vices, can be avoided.

This veriﬁcation can be done without risking to

block the productive network. We test a conﬁguration

prior to applying it to the nodes. If rules and simula-

tion are carefully designed, we achieve a reasonable

high trust into the correctness of the network.

The adaption module applies the conﬁguration to

the individual nodes automatically. In the next sec-

tion, we explain the foundations of Verinec, then we

discuss the adaption module in detail.

2 NETWORK DEFINITION

The common base of all Verinec modules is the XML

language used to deﬁne network topology, interfaces

and service conﬁguration. The deﬁnition focusses on

the functionality rather than on speciﬁc implementa-

tions and thus is independent of the actual hardware

and software used.

Standard hardware and services have most of their

features in common. A network card can be assigned

a ﬁxed IP, a net mask and a gateway or it can be con-

ﬁgured using DHCP. This is the same under all oper-

ating systems supporting network cards. Packet ﬁlters

operate on the properties of packets like presence or

absence of certain header bits.

The application represents all nodes in the same

manner, even if the actual machines come from dif-

ferent vendors. Administrators do not need to learn

a new conﬁguration tool every time they get a new

machine.

Figure 1 shows the XML representation of a simple

node, a PC with one network interface card and no

services offered.

The structure for all network interfaces is the

same. The schema allows as many network ports

(<ethernet>, or <serial> for modems and

<wlan> for Wireless LAN cards respectively) to be

deﬁned as needed. The <ethernet-binding>

represents the physical connection to a network.

WLAN or modem interfaces can connect to differ-

ent networks over time (using different sessions resp.

phone numbers). However, Ethernet elements may

contain only one binding because there can be only

one cable physically connected.

<ethernet-binding name="eth0" id="xyz">

<nw id="i1" address="192.168.0.1"

subnet="255.255.0.0" gateway="192.168.0.24"

type="ip">

<nw-dnsserver ip="192.168.0.254" />

<nw-dnsserver ip="192.168.0.253" />

</nw>

</ethernet-binding>

</ethernet>

</hardware>

</node>

Figure 1: Deﬁnition of a node with one network interface.

The ID of the binding is used to deﬁne connections

between network interfaces. A simple network is de-

ﬁned in Figure 2.

</network>

Figure 2: Connection of two interfaces.

Every <network> tag contains a list of directly

connected interfaces. For Ethernet, this corresponds

to a hub. Packets received on the hub are sent to all

other lines. Even a simple unmanaged switch would

be considered as node, because it contains some logic.

Figure 3 shows the network layout with two nodes

connected by Ethernet interfaces, as it is visualised in

the Verinec graphical editor.

Figure 3: Two nodes connected by Ethernet.

AUTOMATED CONFIGURATION DISTRIBUTION IN VERINEC

305

3 ADAPTION MODULE

After the design phase, we have the new conﬁgura-

tion in the Verinec XML format. It is tested to work

as desired and ready to be distributed to the network

machines. But how to tell our network devices about

it? Verinec offers the adaption module as a framework

to automate this process.

Verinec needs to know what implementation of a

service is being used in order the conﬁgure it prop-

erly. Thus, for applying the conﬁguration we must

leave the abstraction level of not caring about vendor

speciﬁcs. We introduced a type system to add this

kind of device speciﬁc information into the node con-

ﬁguration. The type system will be described in the

ﬁrst subsection of this section.

We split the process into several steps to make it

more ﬂexible. For every implementation of a service,

a speciﬁc translator is used to generate the appropri-

ate conﬁguration information. Afterwards, a distrib-

utor matching the format of the generated conﬁgu-

ration data is used to apply the conﬁguration to the

device.

The separation between translation and applying

the conﬁguration is useful because the latter can be

implemented independent of the actual service. While

we need a speciﬁc translator for every implementation

of each service, fewer methods to distribute the con-

ﬁguration are needed. Linux, Unix and *BSD servers

can be covered by placing a plain text conﬁguration

ﬁle at the correct location in their ﬁle system. Sev-

eral Windows services can be conﬁgured using the

Windows Management Instrumentation (WMI). We

are implementing more distribution methods, e.g. for

Cisco routers, using SNMP to trigger the device to

download its new conﬁguration.

To produce implementation speciﬁc conﬁguration,

we have to leave the XML conﬁguration abstraction.

This introduces the problem that some implementa-

tions of a service might not support everything that

can be deﬁned in the abstract XML. To control the

situation, a restrictor produces warnings if features

are used which are not supported by the chosen im-

plementation.

The adaption module is divided into the following

three steps:

• Restriction: Identifying features that are not sup-

ported by the chosen implementation.

• Translation: Generate data in an appropriate form

from the abstract XML.

• Distribution: Actually conﬁgure the nodes.

The conﬁguration steps are shown in Figure 4 and

will be described in the Subsections 3.2 to 3.4.

Translate

Distribute

Restrict

Restriction

selected translator

warnings for

Configuration

Machine specific

XSL Repository

Network

Definition

Configuration

on Machines

Translator

Figure 4: Steps of the translation process.

3.1 Type system

A separate namespace allows to deﬁne node types and

distributors. Each node within the Verinec XML net-

work deﬁnition needs a type declaration with speciﬁ-

cations for each service conﬁgured on that node. Fig-

ure 5 deﬁnes a node type for a machine running the

Redhat Linux distribution. The <tr:service />

tags specify the restrictor and translator to be used

with the service. The framework reads this type infor-

mation to select the correct restrictor and translator.

<tr:type name="linux-redhat" id="typ01">

<tr:service name="ethernet"

translation="linux-redhat" />

<tr:service name="dns" translation="bind8" />

</tr:type>

Figure 5: Node type deﬁnition.

Types are deﬁned globally and can be referenced

within a node by their ID. If the node does not com-

pletely match the settings of its type, it is also pos-

sible to override the translator setting for that service

locally within the node.

3.2 Restriction step

The design of Verinec takes into account that some-

times, an implementation of a service does not sup-

port all features that can be expressed using the ab-

stract XML. A restrictor is an Extensible Stylesheet

Language Transformation (XSLT) (Clark, 1999) doc-

ument which extracts constructs from the conﬁgura-

tion data which are not usable with the chosen trans-

lator for the service. The restrictors produce human

readable explanations for each offending construct.

Every restrictor is bound to one translator, ensuring

ICETE 2005 - SECURITY AND RELIABILITY IN INFORMATION SYSTEMS AND NETWORKS

306

that the system produces the warnings speciﬁc to the

currently targeted implementation.

An improved handling of the restriction problem

would be to remove from the abstract conﬁguration all

offending parts, so it could be completely translated

into the desired implementation format. This would

ensure that the veriﬁcation process remains valid after

the translation of the conﬁguration to the device.

Note that sometimes, even if a feature of the Ver-

inec conﬁguration does not map one to one to a setting

in the conﬁguration ﬁle, it might be possible to emu-

late it using a clever translation. If a test in a packet

ﬁlter does not exactly map to one statement, it might

still be possible to create a bunch of tests that result

in the same behaviour. The restrictor will only issue

warnings if a feature can not be emulated.

3.3 Translation step

The framework locates the appropriate translator for

a service and applies it to the node XML document.

The translators are, as the restrictors, transformation

documents expressed in the XSLT language. One

stylesheet generates conﬁguration data for exactly

one implementation of a service. In Figure 5, the Eth-

ernet conﬁguration will be created by the linux-redhat

translator, while the DNS server conﬁguration can be

created by a standard translator for bind, as bind al-

ways has the same conﬁguration ﬁle format in Linux

distributions.

The output is an XML document according to the

conﬁguration schema. This schema allows to deﬁne

pre- and post-processes and contains tags to specify

the data for the distribution method.

The conﬁguration document contains the data to be

given to the distributor, for example the content of

a plain text ﬁle (<result-file>) or XML doc-

uments (<result-xml>) that will be understood

by the distributor, e.g. a list of WMI commands ex-

pressed in XML. An example is given in Figure 6.

3.4 Distribution step

To distribute the conﬁguration, we need to know what

method to use to access the target machine. The

<tr:target> element speciﬁed in the node type

deﬁnition and copied into the conﬁguration document

contains a tag for the appropriate distribution method.

Each tag has the necessary attributes for its method,

for example the community string for SNMP or user-

name and key ﬁle for SSH.

The target in Figure 6 tells the framework to use the

secure copy

distribution method, opening an ssh con-

Scp is an application to securely copy ﬁles over a net-

work. It is part of the secure shell suite.

http://www.openssh.org/

<tr:target name="copy to machine">

<tr:scp username="buchmand" host="diufpc55"

keyfile="/home/buchmand/.ssh/id_dsa" />

</tr:target>

<result-file filename="/etc/sysconfig/network-

skripts/ifcfg-eth0">

# Ethernet card configured by Verinec: ethernet 0

DEVICE=eth0

IPADDR=192.168.0.55

TYPE=Ethernet

ONBOOT=yes

</result-file>

</service>

</configuration>

Figure 6: Listing of conﬁguration output.

nection to the speciﬁed host to copy the conﬁguration

ﬁle there. If the host has our public key and supports

the public key authentication, no further information

is needed, otherwise we present the a password input

dialog. New targets can be deﬁned for other distribu-

tion methods.

Distribution is achieved by Java implementations

of conﬁguration protocols. The framework looks up

the distributor class using the <tr:target> ele-

ment. This class must implement the Java interface

IDistributor. The target tag is passed to the dis-

tributor together with the conﬁguration result to dis-

tribute. The distributor can be as simple as writing the

text of <result-file> into a ﬁle at the speciﬁed

location. Or it can be as complex as an implementa-

tion of WMI in Java, retreiving and executing objects

from a remote machine.

When reconﬁguring a service, we must take care

not to introduce temporary security risks. For exam-

ple, disabling a software ﬁrewall while we write the

conﬁguration ﬁle could expose a machine to security

threats. Security implication of the transition have to

be carefully examined when writing adaption module

components.

4 DISCUSSION

There exist many protocols to manage networks.

SNMP is a veteran, but is used mainly for status mon-

itoring. Many device manufacturers do not support

actively conﬁguring their devices by means of SNMP.

Besides some proprietary protocols, there are some

new open standards being developed. A quite promis-

ing work is being done by the NetConf working group

of the IETF. Their goal is to create a standard network

conﬁguration protocol (Enns, 2004). Also of inter-

est is the DM (device management) part of SyncML

AUTOMATED CONFIGURATION DISTRIBUTION IN VERINEC

307

(Guru, 2003). SyncML DM is primarily addressed at

mobile devices, but could also be used for other de-

vices. Both projects only address the transport layer

of conﬁguration data. The actual conﬁguration data

will still be in proprietary format. While one distrib-

utor for each of the protocol will sufﬁce, we will still

need a different translator for every implementation.

Another project is the Web Based Enterprise Man-

agement (WBEM) initiative of the Distributed Man-

agement Task Force (DMTF, 2005). It only tries

to achieve a common information model, which

would represent products from different vendors uni-

formly. We already support Microsoft’s implemen-

tation of WBEM, called WMI. However, experience

with WMI shows that it suffers the same problem as

SNMP: Many device settings are read only and can

not be changed via WMI.

Verinec is a framework with an open design. If

we need to support devices which can be conﬁgured

using the NetConf, WBEM or SyncML protocol, it

is possible to add support for them. As all those

projects chose an XML format for their protocol, cre-

ating commands from the Verinec XML conﬁguration

data should be rather straightforward.

Many attempts have been made to build network

conﬁguration solutions. Service providers can choose

from specialised tools to administrate large numbers

of routers (Cisco, 2005), (Wandl, 2005). There exist

projects like Splat (Abrahamson et al., 2003) that fo-

cus on one aspect of organisation and enterprise net-

works: the edge devices. However, organisation and

enterprise networks are a lot more heterogeneous than

service providers infrastructures.

Verinec is an open framework. It can support all

kind of different devices. Where it does not already

support a device, it is relatively easy to add support.

There are projects that require the user to deﬁne

the network conﬁguration from scratch, for exam-

ple (Bellogini and Santarelli, 2004). Others focus on

analysing existing networks (Hewlett-Packard, 2005),

(IBM, 2005), (Toledo, 2005) but do not have the ca-

pability to directly conﬁgure devices.

Verinec aims at joining the two worlds. One can

analyse the existing network, edit the retrieved con-

ﬁguration and reconﬁgure the devices in the network

within one single system.

However, the most important plus of Verinec com-

pared to other existing solutions is the runtime ver-

iﬁcation module to ensure proper functioning of the

network (Jungo et al., 2005) and (Jungo, 2004).

4.1 Plans for the future

There is a lot of work ahead for Verinec to become

really useful. Among others, the following points

should be addressed:

• To make Verinec usable in practice, it is important

to support as many network device vendors and ser-

vice implementations as possible. Currently, there

are only a few translators available to allow testing

the application.

• At the writing of this paper, Verinec supports only

TCP/IP networks. It is planned to implement sup-

port for other network types, for example IPX or

MPLS.

• The automatic distribution of conﬁguration data re-

quires that Verinec can access all nodes. Some-

times, a ﬁrewall or router might prevent this. It

would be interesting to see if we can develop a

module to solve such issues and i.e. temporarily

open a hole in a ﬁrewall allowing the conﬁguration

process to work but keep the security risk as small

as possible.

• One task of a network management tool is to moni-

tor the network behaviour. We could use the JRobin

project (Markovic and Vandamme, 2005) to gather

statistics of the network operations and present

them within Verinec. We could also think of cre-

ating alerts if something does not run as it was sup-

posed to.

4.2 Conclusion

In this paper, we presented a centralised approach to

network conﬁguration. Verinec is a conﬁguration tool

that “knows” about the whole network and can ensure

its correct functioning prior to applying conﬁguration

updates.

The modular design allows to add new functional-

ity easily around the common core of the XML net-

work deﬁnition. The adaption module is designed to

be extended to new devices in a simple manner, giving

the tool great ﬂexibility.

The centralised conﬁguration approach has several

advantages over the dispersed conﬁguration of indi-

vidual devices:

• Veriﬁable consistent conﬁguration.

• No illegal conﬁguration, syntactically correct but

dangerous conﬁgurations can be detected.

• Accurate documentation of the network’s setup.

• Automated conﬁguration of many machines.

• One tool to conﬁgure the whole network. The ad-

ministrator does not need to learn the particularities

When we consider the transition of the whole network

from an old conﬁguration to the new one, we enter the do-

main of temporal questions: How is the network currently

conﬁgured? In which order should we conﬁgure the nodes

so to minimise network outages during transition and never

to lock the machine running Verinec out?

ICETE 2005 - SECURITY AND RELIABILITY IN INFORMATION SYSTEMS AND NETWORKS

308

of several similar machines and their conﬁguration

tools from different vendors.

• If a node in the network breaks, it can be replaced

and the conﬁguration reapplied. It is even possible

to use a machine from a different vendor without

having to reenter the conﬁguration.

Altogether, these points help to increase reliability

and security of a network and facilitate the life of net-

work administrators.

However, we should not forget about some disad-

vantages. Verinec introduces an additional layer of

software between machines and administrators. We

should keep in mind some points to avoid introducing

new problems and maybe compromising the network

security:

• Automatic generation of conﬁguration instruction

makes live easier – as long as it is done correctly.

Special care must be given to make the translation

of XML into the vendor speciﬁc format as accurate

as possible.

• If Verinec is to be used in a real world environment,

we need to do performance testing. We do not yet

know how long it would take to conﬁgure a com-

plete network. One improvement regarding the du-

ration of the transition state of the network would

be to parallelise conﬁguration commands to inde-

pendent machines.

• The Verinec XML format does not cover all spe-

ciﬁc features found in service implementations, but

focus on the common parts. There is always a

compromise to achieve between many features and

portability from one implementation to the other.

Highly optimised conﬁgurations will be difﬁcult to

achieve using a conﬁguration generation tool like

Verinec.

The centralised approach is less ﬂexible to work

with, as all changes must be done to the central repos-

itory. This could lower the acceptance by system ad-

ministrators. If they would start to conﬁgure some

devices from outside the Verinec system, the incon-

sistency risks would rise again. To make it possible to

use Verinec from different locations, we could think

of a server/client approach, for example with a Java

applet as client to access the Verinec system with a

web browser.

REFERENCES

Abrahamson, C., Blodgett, M., Kunen, A., Mueller, N., and

Parter, D. (2003). Splat: A network switch/port con-

ﬁguration management tool. In Seventeenth Systems

Administration Conference (LISA 03), Berkeley, CA,

USA. Usenix.

Barringer, H., Goldberg, A., Havelund, K., and Sen, K.

(2004). Rule-based runtime veriﬁcation. In Proceed-

ings of Fifth International VMCAI conference (VM-

CAI’04). Springer.

Bellogini, A. and Santarelli, I. (2004). Network markup

language. Technical report, Roma Tre University,

http://giga.dia.uniroma3.it/ ivan/NetML/.

Charles, P. (2001–2005). Jpcap. Technical report,

http://jpcap.sourceforge.net.

Cisco (2005). Internet operation system. Technical report,

Cisco Systems, http://www.cisco.com.

Clark, J. (1999). Xsl transformations (xslt). Technical re-

port, W3C, http://www.w3.org/TR/xslt.

DMTF (1996-2005). Web-based enterprise man-

agement (wbem) initiative. Technical report,

http://www.dmtf.org/standards/wbem/.

Enns, R. (2004). Netconf conﬁguration protocol.

Technical report, Internet Engineering Task Force,

http://www.ops.ietf.org/netconf/.

Fyodor (1997–2005). Network mapper. Technical report,

http://www.insecure.org/nmap/.

Guru, R. (2003). Syncml device management. Technical

report, IBM India Software Labs, http://www-

106.ibm.com/developerworks/wireless/library/wi-

syncml1/.

Hewlett-Packard (2005). Hp openview. Techni-

cal report, Hewlett-Packard Development Company,

http://www.managementsoftware.hp.com.

IBM (2005). Ibm tivoli netview. Technical re-

port, International Business Machines Corp.,

http://www.ibm.com/software/tivoli/products/netview/.

Jungo, D. (2004). The role of simulation in a network con-

ﬁguration engineering approach. In ICICT 2004, Mul-

timedia Services and Underlying Network Infrastruc-

ture, Cairo, Egypt. Information Technology Institute.

Jungo, D., Buchmann, D., and Ultes-Nitsche, U. (2005).

A unit testing framework for network conﬁgurations.

In Proceedings of the 3rd International Workshop on

Modelling, Simulation, Veriﬁcation, and Validation

of Enterprise Information Systems (MS VVEIS 2005),

Miami, Florida, USA. INSTICC Press.

Markovic, S. and Vandamme, A. (2003–2005). Jrobin:

Rrdtool choice for the java world. Technical report,

jrobin.org, http://www.jrobin.org/.

Toledo, J. (2000–2005). Etherape. Technical report,

http://etherape.sourceforge.net.

Ultes-Nitsche, U., Jungo, D., and Buchmann, D.

(2004–2005). Veriﬁed network conﬁgura-

tion. Technical report, University of Fribourg,

http://diuf.unifr.ch/tns/projects/verinec/.

Wandl (2005). Ip analysis tool. Technical report, Wide

Area Network Design Labroratory, http://www.

wandl.com/html/ipat/IPAT

new.cfm.

AUTOMATED CONFIGURATION DISTRIBUTION IN VERINEC

309