Check out the new USENIX Web site. next up previous
Next: Related Work Up: OSPF Monitoring: Architecture, Design Previous: Abstract

   
1. Introduction

Effective management and operation of IP routing infrastructure requires sound monitoring systems. With the advent of applications that require a high degree of performance and stability, such as VoIP and distributed gaming, network operators are now paying considerable attention to the performance of the routing infrastructure - its convergence, stability, reliability and scalability properties. Yet very few monitoring tools exist for effective routing management and operation. In this paper we present a monitoring system for one of the widely used intra-domain routing protocols, OSPF [1] by providing its detailed architecture and design. The OSPF Monitor has been deployed in two operational networks: a large enterprise network and an ISP network. It has proved to be a valuable asset in both networks. We provide several examples illustrating different ways in which the monitor has been used, as well as the lessons learned through these experiences.

We designed the OSPF Monitor to meet the following objectives:

1.
Provide real-time tracking of OSPF behavior. Such real-time tracking can be used for (a) identifying problems in the network and helping operators troubleshoot them, (b) validation of OSPF configuration changes made for maintenance or traffic engineering purposes, and (c) real-time presentation of accurate views of the OSPF network topology.

2.
Facilitate off-line, in-depth analysis of OSPF behavior. Such off-line analysis can be used for (a) post-mortem analysis of recurring problems, (b) generating statistics and reports about network performance, (c) identifying anomaly signatures and using these signatures to predict impending problems, (d) tuning configurable parameters, and (e) improving maintenance procedures.

There are two basic approaches for monitoring OSPF: rely on SNMP [2] MIBs and traps, or listen to Link State Advertisements (LSAs) flooded by OSPF to describe the network changes. Our prior work [3] has shown the superiority of the LSA-based approach, so we take the approach of passively listening to LSAs for our OSPF Monitor. The monitor directly attaches to the network, and speaks enough OSPF to receive LSAs. These LSAs are then analyzed in real-time to identify network problems and validate configuration changes. LSAs are also archived for a detailed off-line analysis, for example, for identification and diagnosis of recurring problems. The monitor uses a three-component architecture to provide a stable, scalable and flexible solution. The three components are:

1.
LSA Reflector (LSAR) which collects LSAs from the network,
2.
LSA aGgregator (LSAG) which analyzes LSA streams in real-time to identify problems, and
3.
OSPFScan which provides off-line analysis capabilities on top of LSA archives.
The paper describes these three components in detail and the benefits offered by this three-component architecture. Since the LSAR and LSAG are key to real-time monitoring, their efficiency and scalability are of utmost importance. We demonstrate the efficiency and scalability of the LSAR and LSAG in terms of network size and LSA rate through lab experiments.

This paper is organized as follows. We discuss related work in  Section 2.  Section 3 provides an overview of OSPF.  Section 4 discusses the three-component architecture of the OSPF Monitor.  Sections 5, 6 and 7 provide detailed description of these three components.  Section 8 presents the performance analysis of LSAR and LSAG through lab experiments. In  Section 9, we describe salient aspects of our experiences with deploying the monitor in commercial networks. Finally,  Section 10 presents conclusions.


next up previous
Next: Related Work Up: OSPF Monitoring: Architecture, Design Previous: Abstract
aman shaikh
2004-02-07