Resources Archived Articles Netsys Enterprise/Solver Connectivity Toolkit
| Netsys Enterprise/Solver Connectivity Toolkit |
| Wednesday, 01 November 1995 21:00 |
|
Cisco sold Netsys to WANDL, see http://www.wandl.com/ . -- Fall, 2001.I've recently spent some time becoming certified to teach a course on the Netsys Enterprise/Solver Connectivity Toolkit. It's an interesting product, so we'll make it the topic of this month's article. Netsys is a fairly new company (1991) with an impeccable Palo Alto address and about 40 employees, including some impressively capable programmers. They're producing network management tools. Cisco has invested in the company. Some of their tools are being developed for Cisco, to be part of the CiscoWorks Blue product. These tools will focus on relating SNA and IP connectivity. Finally, Cisco currently resells and supports the Netsys Solver product. So despite their newness, the company should be stable. Netsys focuses on network planning and problem solving tools. Their goal: pro-active planning for network design and operation. The first products are the Connectivity Baseliner and Connectivity Solver. Netsys' Connectivity Baseliner starts by parsing Cisco router configuration files to determine network topology. It also constructs a graphical network topology map showing the actual connectivity in the network. A topology viewer allows the map to be examined in various ways, zooming in and out. Among other things, you can view the IP, IPX, AppleTalk, or the RSRB topology of the network. Two OSPF views are also available. Views can be customized by moving, grouping, adding, or deleting objects. Clicking on an object brings up dialog boxes showing detailed information about the object. A by-product of the router configuration import process is that the Baseliner performs integrity checks to all the configurations loaded. It reports missing information and problems, including but by no means limited to the following: redundant network addresses, invalid address / subnet mask combinations, static routes to shutdown interfaces, and redundant or ineffective access list entries. The documentation includes a large Appendix detailing the extensive list of checks performed. This baseline can then be modified for planning and problem solving with the Connectivity Solver. The Solver adds what-if analysis. This includes trying out proposed configuration changes. It understands access-lists, route distribution filters, and routing protocols. So it can be used to model routing protocol migrations or redistribution strategy changes. Proposed changes to access lists can be modeled prior to actual implementation. The Connectivity Solver also simulates failures of links or devices. Users can simulate the effects of actual outages, to verify robustness of their network design BEFORE trouble happens on the actual network. The Solver modeling centers around Connectivity Requirements. An example is clients that need to be able to connect to a certain server. A typical analysis verifies that all clients can connect to the specified server. But analysis can also test for routing loops and routing update blockages. Nor is the Solver limited to testing connectivity. For firewalling, we wish to deny connectivity based on access lists. In such cases, Solver reports on failures to block access. This becomes particularly powerful with selective link failures, since routing around a failed link may cause forbidden traffic to bypass the router that was assumed to block it. But don't overlook the value of the access list connectivity checking. I've been running into an increasing number of people in classes with complex access lists they have to maintain but don't feel comfortable with. If you can document your connectivity needs, then the Solver might be useful to verify off-line that changes to those messy access lists won't impact production traffic. Round-trip paths and anomalies can be examined, both textually and graphically via the Topology display. This can highlight problems such as routing loops, blocked routing updates, and packets that bypass an intended firewall router. Seeing the entire round-trip path is also a gain compared to trace or Path Tool functionality: sometimes the return path is not the same, reflecting asymmetrical routing. This is usually caused by missing or incorrect information in configurations (for example link bandwidth not set, or network not being advertised or redistributed). All modeling is done locally, so there is no impact to the production network. You can preview a design or change without affecting your production network. Only the router configuration files are used for the analysis and simulation. You don't have to buy the router to simulate it, just build a configuration file for it. The same for links: add configuration commands to the interfaces (real or imagined) which the link would join, and Netsys will model the link. This means that the Netsys tools are design verification tools, which allow you to create error free networks before implementing them. We've estimated that saving an hour of network downtime pays for the product. After router configurations have been modified, modeled, and tested off-line, the configuration changes can be exported, for subsequent transfer to routers. This is typically done via delta files, files containing just the router commands needed to get from the previous configuration state to the new one. (And yes, they know when to insert appropriate 'no' commands). Initially, Netsys ducked the issue of getting configurations from or to the routers. A bi-directional interface with CiscoWorks 3.0 is now being implemented. Netsys is also rapidly adding parser functionality (for example, they've added X.25 and SMDS in addition to Frame Relay in the last couple of months). Long term plans include extension of the "what-if" analysis capabilities, and the capability to examine a drawn network and automatically generate configuration files for routers. The software is fairly small in size but requires a fairly powerful Sun workstation, generally at least a SPARC 5. Both the automatic traffic generation and the connectivity analysis can be very compute-intensive, and you'll need to size the hardware to match the number of router configurations being loaded. Besides CPU, 64 MB of RAM and 150+ MB of swap are in order. You'll need 40 MB of disk to load the software, and more to actually do much with it. Versions are now available for SunOS 4.1.3._U1 or Solaris 2.4, and the code should be very portable. Help and on-line documentation is provided in HTML form (user provides the Web Viewer). Netsys has a Web page which will download Connectivity Checker, a demo / limited version of Baseliner that reports configuration file errors. There is also now a Topology demo available, or you can request a demo CD via a Web form. If you wish to purchase, the software can be activated by getting a key via fax. Netsys has certified me to teach their course on Baseliner / Solver. The course is 2 days and covers all aspects of Baseliner and Solver. The course is hands-on, with plenty of lab time.
11/95 |
