Check out the new USENIX Web site. next up previous
Next: Utility of the Monitor Up: OSPF Monitoring: Architecture, Design Previous: Results

   
9. Deployment Experience


   
Table I: Facts related to the deployment of the OSPF monitor in two commercial networks.

Parameter

Enterprise network ISP network

Layer-2 architecture

Ethernet-based LAN Point-to-point links

Customer reachability information

Use of EIGRP between network-edge routers and customer-premise routers. EIGRP routes are imported into OSPF. Use of I-BGP to propagate customer reachability information. I-BGP routes are not imported into OSPF.

Scale of monitor deployment

15 areas; 500+ routers Area 0; 100+ routers

LSAR attachment mode

Host mode Partial adjacency mode

Deployment history

Deployment started in February, 2002 by connecting LSAR to two areas. Remaining areas were gradually covered in the next two months. Deployment started in January, 2003 by connecting LSAR to area 0.

Size of the LSA archive

10 MB per day 8 MB per day

We have deployed the monitor in two commercial networks: a large enterprise network and a large ISP network.  Table I provides some facts about these two networks and the deployment of the monitor. More details about the enterprise network architecture can also be found in [7]. It is important to note how diverse the two networks are in terms of their layer-2 architecture, and their use of OSPF. The layer-2 architecture dictated which LSAR mode we used for network attachment, whereas the use of OSPF affected the number of LSAs received per day. All servers running LSAR and LSAG processes are NTP-synchronized in both the networks.

Operators of both the networks were very cautious about deploying the LSAR and LSAG in their networks. As a result, before the deployment, both LSAR and LSAG underwent extensive testing and review to convince the operators about passiveness of the LSAR and robustness of both the components. During testing, we also ensured that there were no memory leaks in either of the components. To further enhance security, we turned off all unnecessary services, and put in measures to tightly control access to the server running the LSAR. To increase the accuracy of the time-stamping of the LSAs being archived at the LSAR, we took care of minimizing the I/O that might result from activities such as writing of syslog messages. In addition, to keep the measurements as clean as possible, we separated the interfaces used for remote management from those used to capture LSAs. This minimized the competition between measurement and management traffic.

The OSPF Monitor has handled the load imposed by these networks with ease, demonstrating and further confirming the scalability of the system. Furthermore, the LSAR and LSAG implementations have proved to be extremely reliable and robust. We have observed the LSAR crash only once during these two years, and have not observed the LSAG crash at all. The LSAR has been upgraded three times for bug fixes, and eight times for enhancements, whereas the LSAG has been upgraded three times for bug fixes and 26 times for enhancements.



 
next up previous
Next: Utility of the Monitor Up: OSPF Monitoring: Architecture, Design Previous: Results
aman shaikh
2004-02-07