Go to:

IT Jobs

Simple questions sometimes don't have simple answers. When questions like: "Can we increase the bandwidth to our regional offices?"; "Can we provide more redundancy for our critical links?"; and "Can we do this and reduce costs at the same time?" are asked of enterprise network executives, it becomes more difficult. Keeping the complex beast of the various network sections running efficiently at maximum bandwidth and minimum cost is a monumental task.

Fortunately, network-modelling tools let designers or operators test changes to network topology before they are implemented in a production network. We recently tested the ability of three packages - Opnet Technologies' IT Guru 10.5, NetRule Version 6.0 from Analytical Engines, and Shunra Software's Shunra/Storm Version 3.1 - to model changes to predict their impact on the University of California, San Francisco (UCSF) campus network.

We found that IT Guru was the most-accomplished of the three products. It scaled easily to accommodate just about any production enterprise network and had powerful tools for analysing network issues. NetRule was very easy to configure and learn, providing good modelling tools, especially for LANs. Shunra/Storm did an especially fine job modelling WANs. Although each package has specific strengths, all are competent packages and share many common analysis tools and capabilities.

Modelling accuracy
The key to network modelling is the ability to closely match the generated network model map to the real network topology. We wanted to find out how accurately each product modelled events such as link failure, link change, device failure, load change, route change and link overloading.

IT Guru handled all these issues with aplomb. It let us implement changes on the fly. We could change factors such as Open Shortest Path First (OSPF) link costs, Hot Standby Router Protocol (HSRP) timers and OSPF timers, and immediately see the impact on the network. IT Guru took every configuration change we threw at it, and it accurately predicted the behaviour of routing protocol and topology changes. There seemed to be nothing too complex or tricky for IT Guru.

Changes in our model did require accuracy on our part. For example, we modelled two HSRP-connected routers. We entered all the HSRP attributes in both routers, but the HSRP model refused to work. It turned out we had forgotten to set the default gateway in the router configurations. Without this information, IT Guru simply would not establish the HSRP session. Because this is exactly the same thing that occurs in a real-world network, we were impressed with this feature.

While NetRule could accurately predict the impact of many network topology changes, the product has some limitations that concerned us. For example, to test load sharing we created two links, a 1G bit/sec link and a 100M bit/sec link. We reduced the 1G bit/sec link to an OSPF cost of zero, expecting the model to show a preference for the higher-bandwidth, lower-cost link. But the NetRule model assumed an equal cost between the 1G bit/sec and 100M bit/sec links. Mystified, we called NetRule support and were informed that to change the OSPF cost we had to delete one of the existing links and then re-create it with the new cost. We couldn't simply change the cost on the existing links. The inability to change costs on the fly seemed to us to be a major omission.

The NetRule library contains a reasonably large selection of vendors and products. However, it does allow customisation of any network models, such as changing the CPU processing power and interfaces. The tool does not check for configuration errors or device inconsistency, nor does it check for IP address conflicts or protocol errors. It seemed that the model assumes that users do not introduce input errors. That is a large, and probably unreasonable, assumption.

A very nice feature of Shunra's tool is that it can record network conditions directly and play them back. This enables real applications to run against the simulation. For example, we could send voice packets and streaming video between devices connected to Shunra/

Storm's StormAppliance. When we introduced delay, packet loss or jitter, or reduced the link bandwidth, we actually could see the video degrade or hear the audio drop out. This feature makes it extremely easy to determine the minimum acceptable criteria required for specific applications across various links. We found this a very useful feature. With IT Guru and NetRule, we could get this same information, but it was presented numerically.

Configuration
With its optional Multi-Vendor Import (MVI) module, IT Guru can import configuration directly from Cisco and Juniper devices. For other vendors' gear, Opnet requires the optional Virtual Network Environment (VNE) server. The VNE server supports network devices from Cisco Systems Inc.'s Catalyst IOS, Extreme Networks Inc., Foundry Networks Inc., Nortel Networks Corp. and other vendors. We were disappointed that IT Guru could not import more non-Cisco IOS devices' configurations directly, instead of requiring optional products that cost extra.

There are multiple ways to handle the IT Guru configuration. For example, it can use the optional VNE server, import text files from CiscoWorks or create network objects manually. It also can query an HP OpenView server, which lets it build a model of the production network that is automatic and up-to-date. However, this requires modifying the OpenView server configuration to accept connections from the workstation that is running IT Guru. Our IT security team wouldn't give us access to a production OpenView server from a test lab machine, so we couldn't test this feature. Instead, we modelled the Cisco devices in our network using data provided by a CiscoWorks text file export, along with manually created Foundry network devices.

IT Guru imported the backbone network device configuration for 120 Cisco devices from our CiscoWorks file in less than 3 minutes. Because IT Guru is very sensitive to syntax errors, creating manual configurations for the Foundry gear was a painful and time-consuming process. To make matters worse, there was no warning or alert that flagged syntax errors. The model simply refused to work properly.

In part 2 next week, Jeffrey Fritz reports on performance, plus installation and deployment issues.

Latest White Papers

Ten top problems network technicians encounter
>> Download whitepaper

Are all VoIP services the same?
>> Download whitepaper

Brocade solution guide: Deploying PoE and PoE+ solutions in the campus network
>> Download whitepaper