<contents>

My involvement with Network managment is somewhat accidential, I never imagined nor sought to work in this area. Whatsoever, ... over several years I had to deal with this challenge. Here ist the place where some of my insights, experiences, findings and developments are put together, to make it easier for me to handle them.

The starting point for creating this page was the development of the Baby Route Generator: brg. Don't step into it yet, let me explain the concepts befind brg first:

While learning by doing I always tried to find the easiest way for network managment AND I always had to stretch the budget to the limits. My Networks are mainly composed of comodity hardware and low end switches or hubs. As PC's used as Routers are somewhat slow - especially when even prestigious Universities in Nicaragua use 133 MHz Pentiums and lowest price/lowest quality Network Cards, I don't let grow my networks bigger then about 60 to 160 Computers. If there is need for more computers, a new network card gets put in and a new subnet is created. On Router never handles more the three subnets.

So a medium sized Network can grow up to several Linuxrouters, which have to be configured to know each one the other routes and networks.

RIP and OSPF have never inspired much confidence in me - be it that I simply lack experience with these protocolo, or be it that I don't like my routers to autoconfigure themselves: for one because it can take time for these protocol to pick up a new route, and for two because I fear security considerations.

Inspired by Cfengine, which uses one big configuration file, known to all nodes on a network, I thought of a way, to give one network-map to all Linux-routers, and make them generate at startup time the necessary routes out of it.

So you can use Cfengine or Secure Shell/Secure Copy to distribute the network-map file to all routers. When a Linux Router starts up, it first configures all its network interfaces, then it uses the brg.sh script with the network-map as input to generate all routes to other networks, and finally IP-Firwalling, Masquerading (NAT) and Traffic Control are applied.

BRG is not ready for use yet. At this moment it is not recursive, so it only works for networks where all gateways/routers to subnets are connected to one common subnet - I call it the backbone.

At this moment I have not even had time to apply it on one of my Networks "for real".

For the future I want to reflect also routing policies in the network-map e.g. suppress the generation of routes to networks which a specific router shall not reach.

BRG only works with star-like networks. It will not recognize or handle multiple routes to a network.

BRG is just a very simple bourne-shell script. It could be rewritten with advantage in C or any other programming language.

I use the fabulous IPMASQ script found for example in Debian Distributions ("=apt-get install ipmasq=") to automatically configure my IP-Firewall. With time, IPMASQ has saved me a lot of work, while providing me with a warm, fuzzy felling of security. It took me some time to begin to understand its working.

Since IPMASQ does not block ports, it just establishes basic rules between "Inside" and "Outside" of the firewall, I always add hand-written rules to it, to make it fit into the respective situation.

IPMASQ does not use a configuration file, you have to copy and modify a set of shell-script fragments to modify its behaviour. This and a final need for modification - the use of IPMASQ not on the border-gate router, but rather inside of a routed network - inspired me to make a generic set of modifications, which would expand the capabilities of IPMASQ, selectable from a simple to manage configuration file rather then modifying the source code itself.

The result is IPMASQ+, a set of rule files, which drop into a standard IPMASQ installation.

To download and play with IPMASQ+ go to the first link at the "Links" section.

The status of IPMASQ+ is highly experimental. Back up your configuration before applying IPMASQ+ to it, and check the resulting rules before trusting the new Firewall.

https://soporte.netport.com.ni/notas/index.cgi?IpmasqPlus :: Wiki Page at Netport, where you can download the actual tar-file.

http://www.ecst.csuchico.edu/~dranch/LINUX/ipmasq/c-html/index.html :: 

    Linux IP Masquerade HOWTO

When managing networks and related services several tasks to be managed pop up: Client support, network supervision, Inventory, configuration managment, documentation. Lots of Software is floating around to deal with these tasks, either free or comercial.

My natural choice is always to use free Software because it's gratis too. So here is what I have used:

Is a webbased database application, which stores an inventory of computers or other connected hardware, as well as hubs, routers, etc. and its interconnections.

IRM provides also a FAQ-Systems and a Ticket Tracking System/Help Desk, where users can report problems with their computer.

Technologies :: PHP, mySQL

Pros :: IRM stores the interconexions between computers, hubs and 

        routers, i.e. a representation of the network-map.

Cons :: The Ticket Systems is very simple and it has no Mail-Gateway 

        for incoming tickets.
        No support for PostgreSQL.
        Language: only English.

Ideas :: Since IRM stores al IP/Mac-addresses of your computers, it 

         could be used to generate DHCP and DNS configuration files.
         We started a first prototype at UNI for this, however it's
         gone into the shadows.

http://www.stackworks.net/view.php/irm/index.html

Is a Trouble Ticket System. It is oriented towards the message flow between customers and the support team. You can introduce Tickets via a Client Web Interface, Email, and via the "Agent" Web Interface. An Agent is a support person.

Technologies :: Perl, DBI i.e. PostgreSQL or MySQL, or ..., multilingual

Pros :: Very good work.

Cons :: Does not provide direct conection to Network data/equipment

http://otrs.org/

Just For Fun Network Managment System - JFFNMS monitors (mainly) via SNMP different parameters of Servers or routers. It convertes e.g. the traffic flow into time series graphics, similar to MRTG, however JFFNMS stores the sample data in a database and can retrieve past data and rebuild de graphics with the full sample resolution.

JFFNMS also provides supervision of predetermined limits and can issue alarms when the respective parameters goes out of bound.

The Webinterface provides a view for "customer" where only specific graphics are shown, and a view for "tecnicians" which can see the hole slew of parameters, modifiy parameters and acknoledge network alarms.

Technologies :: PHP, PostgreSQL or MySQL.

Pros :: Monitoring is very easy to set up, retrieveal of old data is 

        possible,

Cons :: Slow, Resource intensive

Nagios is the successor of Netsaint, another network monitoring tool, designed for large scale monitoring. In the first place, Nagios runs as daemon in the background, it does not need a graphical frontend. Checks for different hosts and services on them are scheduled for execution, and their result is analized. If nagios thinks that an anomaly occured during a test, it issues Notifications.

There is a vast range of available network tests and notification methods. Nagios is highly configurable for use in subdivided support teams.

There exist a Webinterface, which allows to monitor the activities of the daemon, and to visualize different summaries of the Network status.

Nagios does not provide performance statistics or graphs. It just monitors events.

Technology :: C, perl, optionally database backends: PostgreSQL, 

               MySQL and others

Pros :: Fast, very flexible in configuration

Cons :: Configuration of Nagios is cumbersome and error-prone.