  |    |
| |
One would say, "Why messing with a database, care to maintain it, perform manual completions etc. It's more convenient to sample the LAN with existing software from time to time and make as well visual and manual expections scheduledly."
Well, it is a solution. But not for a BIG Local Area Network, like Intel Haifa, where the administrator must keep the trace of thousands of nodes and be in control of dozens thousands of wires, everything under an excessively heavy traffic needed by the high-tech production of the company which allows minimal, close to zero downtime.
By maintaining a database we may be sure of a quick location of a problem whatever large the covered area is, given the tools are powerful enough. We also make to ourself easier the future integration of new, possibly more complicated and featuring equipment.
Now, this is a more complicated question. We weigh two possible solutions here. It is clear, and known, that we are dealing with several kinds of equipment and data providing mechanisms and they are not neccessarily giving their information to the same information pool directly. Therefore a dilemma appears - whether nevertheless drag the information that is naturally outside of the central database location, by force into it, or to store the information at the location it originally is born.
The distributed solution has the advantage that no network data transfer, which is relatively unreliable mechanism does not affect much the yielding of the data, and as well it allows a quicker update of the data sources.
But, the advantages of a central database are more important to us, and they
are following.
Any query performed by the administrator is being done
over a homogenous, single-location entity and thus is unaffected by
possible network interferences that may occur at the time of the query,
as well as the speed of the query goes up considerably.
The data damaged due to a network interference during the collection may
be easily located and fixed through observing log files and generating
troubleshooting messages.
Minor advantages are that less resources of the LAN are involved in a
centralized collection thus required less distributed attention and
also the controlling configuration file also won't need a distribution
over several locations.
We want such a database to contain as many LAN-descriptive fields as possible. Currently provided fields are:
Such a chain is easily transfored into a camomille-like scheme, but still the definition of a new item is going to be derived from the next one.
We want to allow queries that show connections for any node in the LAN which we collect information about. We want to allow all kind of information for the specific node to be shown to the user and as well specific requested parts. We want to allow queries about single items and queries about lists of items, including wildcarded list. More about it in the implementation section.
In general a binary format of a powerful existing DB engine is preferred.
Since Network control station usually runs UNIX, we suppose the DB engine
should be UNIX oriented. Thus, it can be SQL, Oracle, Ingres, PostgresQL
etc. Then, an interface between data collecting scripts that gather
ascii streams from the Network and binary data warehouses of the DB should
be provided.
But, here we are dealing with a proof of concept and are building a prototype,
therefore we choose to use a more representative, though slower, ASCII tables
within files, which are readable by a user without cunning tools. An efficient
format and database engines weren't the exact purpose of this project,
therefore no accent was put on them.
As stated above, the chain relations allow an easy integration of new fields into the database while keeping the principle of "one derives another". The addition of new fields should be done with an update of the controlling configuration file and that will allow the queries to automatically learn the new entites added.
First, we would require them to have an easily readable format, either one that can be interfaced with the database format, or regular ascii tables. Second, we would desire a frequent update of those databases. A loose update of them would reduce the value of the querying results, introducing mistakes of obsoletion and misinformating the network engineer. Third we would want such a database to be within an easy reach by the network engineer so that he could keep an eye on the changes going in it.