hledat:

FlowMon Probe Network Configuration

CESNET technical report number 32/2007
also available in PDF, PostScript, and XML formats.

Radek Krejčí, Pavel Čeleda, Petr Špringl, Marek Žižlavský
30.12.2007

1   Abstract

This technical report describes the FlowMon probe remote configuration system. The main objective of this system is to provide secure and user-friendly configuration of one or more FlowMon probes. Developed system is based on the client-server application implementing NETCONF protocol. Although the system is developed for the FlowMon probe configuration, the main part of the system (NETCONF system) can be simply reused for other network devices.

Keywords: NETCONF, network configuration, FlowMon, NetFlow, SSH, Liberouter.

2   Introduction

Secure remote configuration of the network devices is a necessary feature in today's highly interoperable networks. After two decades of using SNMP and many vendor specific mechanisms to network device configuration, the IETF introduced NETCONF (NETwork CONFiguration) protocol. This technical report presents experiences of implementing NETCONF protocol for remote configuration of the FlowMon probe. The FlowMon probe [Cel06] is a passive network monitoring device based on the COMBO6X technology.

The NETCONF is XML based protocol using simple RPC (Remote Procedure Call) mechanism (see Figure). XML is used for RPC message formatting as well as for configuration data encoding. XML formatting is one of the protocol advantages and the configuration data can be processed in many ways. The NETCONF is fully independent of used configuration data model or data definition language.

The remote configuration system implements the NETCONF protocol over SSH [WG06]. All NETCONF's messages are transported between agent and manager encapsulated in the SSH protocol. The SSH protocol (specifically SSHv2) guarantees sufficient security for NETCONF sessions.

3   Related Work

The remote network configuration system was developed as a software extension of the FlowMon probe. The probe is able to collect statistics about IP flows and export them in NetFlow v5, v9 and IPFIX protocols to external collectors. The exported NetFlow data are used in many network monitoring and security-related applications.

The probe configuration was initially performed by local configuration files and by parameters passed to start up scripts. This way of configuration is well known in Unix-like operating systems and useful for debugging and testing purposes. The probe deployment in European NRENs required new configuration approach to fulfill the network administrators requirements:

• simple and user-friendly interface,

• platform independent configuration interface,

• reliable and secure remote configuration,

• openness and extensibility for other non-FlowMon devices.

4   System Architecture

The proposed configuration system consists of several monitoring devices remotely managed from dedicated web server as shown in Figure. The NETCONF protocol was selected as the mechanism for storing and transporting configuration data. The NETCONF protocol was published by IETF in 2006 and is described in RFC 4741 [Enn06]. This protocol is based on sending XML messages between manager and agent. The manager (web front end) is supposed to serve as administrator's interface and the agent performs administrator's requests on the configured device.

The extensibility is important feature of the NETCONF protocol. It allows to specify new capabilities (modifications of basic operations or definitions of entirely new operations) for accessing vendor or device specific functions. The NETCONF protocol specifies only basic set of the operations suitable for all devices (or more precisely for its configuration data). The list of supported capabilities is advertised in messages sent by manager to agent (and vice versa) during NETCONF session establishment.

The FlowMon probe remote configuration is based on three main parts (see Figure):

• Configuration daemon flowmond(1) used for applying configuration changes in the FlowMon probe.

• NETCONF system providing operations to create, modify or delete configuration data.

• Web configuration front end with simple and intuitive user-friendly interface for changing FlowMon probe configuration data.

The FlowMon probe configuration data are stored in XML format. There are two data stores (startup and running) holding the FlowMon configuration data. The startup configuration contains information specifying parameters used at boot time. The configuration daemon reads this data at boot time and sets up the probe. The running configuration data store is created from the startup configuration at the boot time by the configuration daemon. This data store contains the current probe configuration. To change current settings of the probe user have to change running data store.

The following XML document shows FlowMon probe startup configuration:

<?xml version="1.0"?>
<flowmon-config
    xmlns="http://www.liberouter.org/ns/netopeer/flowmon/1.0">
  <probe>
    <active-timeout>30</active-timeout>
    <inactive-timeout>10</inactive-timeout>
    <sampling>
      <sampling-rate>10</sampling-rate>
      <sample-and-hold-rate>100</sample-and-hold-rate>
    </sampling>
  </probe>
  <collectors>
    <collector>
      <description>First collector</description>
      <protocol>netflow-v5</protocol>
      <host content-type="ipv4">collector.liberouter.org</host>
      <udp-port>60000</udp-port>
    </collector>
    <collector>
      <description>Second collector</description>
      <protocol>netflow-v9</protocol>
      <host content-type="ipv6">collector.liberouter.org</host>
      <udp-port>60001</udp-port>
    </collector>
  </collectors>
</flowmon-config>

The data model for configuration data and statistics are defined in the RELAX NG schema. This schema is available at [Lho07] and detailed sample configuration file can be found at [Lho07a].

5   Configuration Daemon

The start up script (flowmond.rc) loads probe's kernel modules and executes flowmond(1) during system boot. The configuration daemon [Spr06] finishes the setup process according to startup configuration data (firmware booting, hw setup, NetFlow export, etc.), stores current probe settings to XML file (running configuration) and provides the interface for NETCONF system.

The daemon receives information about changes in the current configuration and applies these changes. On the other hand, the daemon reads various card statistics (input/error packet counters, timeouts, input sampling, etc.) and sends them via NETCONF system to the manager's machine. This communication is implemented as a pair of named pipes (FIFOs) - one for transfer messages from NETCONF agent to configuration daemon and one for opposite direction. Because more than one instance of the NETCONF agent can run at the same time the access to these FIFOs have to be controlled by a communication key. This key is represented as a file created by configuration daemon during its starting procedure. Before accessing the FIFOs NETCONF agent have to lock communication key (file representing the communication key) so only one NETCONF agent is able to access to communication FIFOs in the same time. When the communication between configuration daemon and NETCONF agent is over the NETCONF agent have to unlock communication key.

Security of accessing configuration data stores and all communication files is ensured by Unix file access rights. Configuration data stores as well as communication FIFOs and communication key are created with read and write access only for owner and group (of flowmond(1) process). This owner and group can be specified as parameters given to the flowmond(1). Therefore only members of specified group (or specified owner) can access configuration data stores through FlowMon probe remote configuration system.

6   Network Configuration System

The NETCONF system is a core of the remote configuration system [Kre07]. It is composed of the NETCONF agent (netconf-agent(1)) and the NETCONF manager (netconf(1)). The communication between these two sides is based on NETCONF messages in the XML form. The connection is invoked by SSH client connecting to SSH server with requesting invocation of the netconf subsystem. netconf subsystem is specified as the NETCONF agent program. On the manager side the SSH client is interconnected with the NETCONF manager program by input/output stream redirection. The NETCONF manager forks a SSH program and redirects its standard output (stdout) and standard input (stdin) file as descriptors to prepared pipes. Therefore NETCONF manager program is able to write data to and read data from SSH program directly.

SSH program is invoked with '-s netconf' option which specifies that SSH server should start SSH subsystem called netconf. The SSH subsystem mechanism was introduced in SSHv2. The subsystems available on the machine are described in the configuration file /etc/ssh/sshd_config. For the netconf subsystem it has to be specified that NETCONF agent program should be started.

As soon as sshd(8) starts NETCONF agent program, the NETCONF session is established. As the first operation both sides send a 'hello' message with a list of supported capabilities. If NETCONF agent as well as NETCONF manager receives hello message correctly, the synchronous message exchange can start. The NETCONF manager program sends its requests through the SSH session to the NETCONF agent. Then the agent processes the request, performs necessary changes in configuration data or cooperates with configuration daemon to satisfy the request. When all necessary operations are performed, the NETCONF agent program creates a response for processed request and sends it again through the SSH connection to the manager. Then the agent's response is displayed to user by NETCONF manager program.

The NETCONF manager program includes simple interactive command line interface. This interface is not very user-friendly and it doesn't allow to configure more than one device at once. Therefore NETCONF's manager provides non-interactive batch mode as an interface for automated tasks. In such case the list of required operation calls is stored into the text file. This file is read by the program and executed automatically. The batch mode is useful as well in communication with the FlowMon web configuration front end. Front end only prepares files with the list of required operations and then runs NETCONF manager in batch mode.

7   Web Configuration Front End

The web configuration front end [Ziz07] is used as simple and intuitive web based graphical interface for configuring the FlowMon probe. It can be used for configuring probe parameters (like timeouts and sampling), for setting-up collectors and for performing critical administrative operations (reboot or halt probe's host machine).

The FlowMon probe configuration interface works as XML editor (see Figure) with specialized graphical user interface for editing the probe configuration files. After successful connection to target device via NETCONF system, front end automatically reads running device configuration. The configuration is stored locally and accessible for editing using Probe and Collectors menus (see Figure). Changes made to this configuration data can be then committed back to device (Admin menu).

8   System Evaluation

The FlowMon probe remote configuration system is available since FlowMon 1.3.0 package, see FlowMon home page. Detailed install and user documentation is available in the FlowMon probe handbook [Flo07]. The typical deployment scenario contains several FlowMon probes configured from common web interface placed on dedicated web server. Figure shows the configuration interface home page.

The front end allows the administrator to define and store connection profile for each FlowMon probe. Figure shows the main probe parameters. The administrator can define timeouts, sampling rates, NetFlow collectors and get interface statistics.

The configuration system was tested during several months without any significant issues. The web server is based on Apache with PHP 5 support. The web front end was fully tested on most widely used Internet browsers (Firefox, IE6, IE7 and Opera).

9   Conclusions

All parts of the presented system are fully implemented, tested and successfully used for remote configuration of FlowMon probes deployed on CESNET's backbone network. The system represents comfortable and intuitive way to control many probes without necessity of detailed information about probes.

The presented NETCONF system implementation shows NETCONF protocol's independence on configuration data model. The advantage of NETCONF system independence on configuration data model give us the possibility to use the presented configuration framework in other projects. Only the configuration daemon needs to be modified to be able to understand configuration data and to apply configuration changes to new appliance. In future we plan an extension for configuring other probe types and adding features to fully control monitoring appliance.

References

[Cel06]	Čeleda P. et al.: FlowMon Probe. Technical report 31/2006, Praha: CESNET, 2006.
[Enn06]	Enns R.: NETCONF Configuration Protocol - RFC 4741. RFC 4741, IETF, 2006.
[Kre07]	Krejčí R.: Configuration of Network Devices with NETCONF Protocol. Bachelor thesis. Brno: Masaryk University, 2007.
[Flo07]	Liberouter project: FlowMon Probe Handbook. Available online.
[Lho07]	Lhotka L.: XML Schema of FlowMon Configuration Data and Statistics, 2007. Available online.
[Lho07a]	Lhotka L.: FlowMon Probe Sample Configuration, 2007. Available online.
[Spr06]	Špringl P.: Design and implementation of configuration software for NetFlow probe. Bachelor thesis. Brno: Brno University of Technology, 2006.
[WG06]	Wasserman M., Goddard T.: Using the NETCONF Configuration Protocol over Secure SHell (SSH). RFC 4742, IETF, 2006.
[Ziz07]	Žižlavský M.: Web Configuration Interface for Network Devices. Bachelor thesis. Brno: Brno University of Technology, 2007.