Re: [tlug] OSS network visualization software, WAS: [Semi-OT] Network connectivity diagnosis

[Curt Sampson <cjs@example.com>]

On 2010-01-28 13:32 -0500 (Thu), Patrick Bernier wrote:

> I need something that will let me:
>   [Long list of requirements deleted.]

You may simply want to reconsider your working and documentation style.

I, too, tend to want to use diagrams to help understand and design
systems that are a lot more complex than can be expressed in the
diagrams, and in particular where the diagram is a convenient expression
of a topology, rather than a diagram per se. That is to say, it's how
things are connected that's important, rather than the overt shape of
the diagram, and it's not unusual at all for a minor topological change
("these things connect to these instead of those") to require a complete
reworking of the diagram, making it come out looking quite different.

What I've found works best for me is to design (or use an existing) text
format for my main representation that:

    * has minimal redundancy;
    * is as compact as it can reasonably be made, while still being readable;
    * is simple to edit and parse;
    * is line oriented to some degree, to make revision control and diffs
      easier to handle;
    * and provides some commonly-used and reasonable "view" of the data.

If it seems useful or necessary, I'll also write a consistency checker
for this "master" format to help me avoid making nonsensical statements.

I then use scripts and graphing tools of various sorts of massage the
data so that I can view it in different ways and try to understand
it better. I'll have various reporting tools that give me summaries,
details and different views in textual formats, further tools that
produce output suitable for programs such as graphviz to draw pictures
from, and so on.

The third tool I use is a whiteboard, and, when necessary, I just
mentally extract the appropriate information I need and draw it up by
hand to play with. This is actually an excellent exercise; I've found
that teams that cannot, from memory, make at least a rough sketch of
the design of some part of their system probably don't understand the
design of that part very well (or at all). This goes whether the team is
programmers drawing pesudo-UML, DBAs drawing E-R diagrams, or network
engineers drawing out their basic site topology.

This I've found to be the most effective way to manage a representation
of a complex and frequently-changing system. What I do lose with this
method is very professional looking pictures. But they don't contribute
any more understanding than doing all of the above and, unless an
enormous amount of time is spent on them, they actually contribute less
due to being expensive to change.

cjs
-- 
Curt Sampson         <cjs@example.com>         +81 90 7737 2974
             http://www.starling-software.com
The power of accurate observation is commonly called cynicism
by those who have not got it.    --George Bernard Shaw