Next: Bibliography
Up: OSPF Monitoring: Architecture, Design
Previous: Lessons Learned
10. Conclusion
In this paper,
we have described the architecture and design of an OSPF monitor,
which passively listens to LSAs flooded in the network,
provides real-time alerting and reporting on network events,
and allows off-line investigation and post-mortem analysis.
The three main components of the system are:
- The LSAR (LSA Reflector), which captures LSAs
from the network. The LSAR supports three modes
by which it can be attached safely and passively to the network.
- The LSAG (LSA aGgregator), which receives ``reflected''
LSAs from one or more LSARs, monitors the network in real-time
for operationally meaningful events.
The LSAG populates a network topology model using the LSA
stream, tracking changes to the topology, and
issuing associated alerts and console messages.
These messages allow network operators to quickly localize and
troubleshoot problems.
The topology model also provides timely and accurate
views of the OSPF topology to other network management applications.
- The OSPFScan, which
allows efficient post-mortem analysis of LSA archives
via streamlined parse, select and analyze capabilities.
The OSPFScan includes a large set of libraries,
implementing, in particular, playback and isolation of
topology change events, generation of statistics,
and construction and evolution of routing tables and
end-to-end paths for every topology change event.
We demonstrated that the LSAR and LSAG can scale to
large networks and large LSA rates through lab experiments.
Overall, the monitor cleanly separates instrumentation,
real-time processing and off-line analysis.
The monitor has been successfully deployed in two commercial networks,
where it has run without glitches for months.
We provided several examples illustrating how operators are using
the monitor to manage these networks, as well as some lessons
learned from this experience.
In future, we plan to work on improving the LSAG by incorporating
more intelligent grouping and prioritization of messages.
We also plan to focus on correlation of OSPF data with other data
sources both for better root-cause analysis of network problems and for
better understanding of network-wide interaction of various protocols.
Next: Bibliography
Up: OSPF Monitoring: Architecture, Design
Previous: Lessons Learned
aman shaikh
2004-02-07