FAQ -- Frequently Asked Questions

Answers to frequently asked questions about Netomata and our products and services.

Project FAQ

What is the Netomata Project?

The Netomata Project is an open source project to develop and support network automation software.

Who sponsors the Netomata Project?

The Netomata Project is sponsored by Great Circle Associates, Inc. See our Sponsor page for more information, including contact information.

Who manages the Netomata Project?

See the Management section of our Sponsor page for information about the management of the Netomata Project.

Where does the name come from?

Netomata is intended to suggest "network automata", similar to "cellular automata". The inspiration for the name was a comment by our founder's spouse, Janet Salsman.

Tools FAQ

What are we building?

We're building tools to automate the configuration of network systems, in order to make networks more reliable and scalable. We're going to make these tools available in a way that's accessible and affordable for even the smallest organization, while still providing a nice living for ourselves. And we're going to build a community around these tools, to support their growth and ongoing development.

Why does the world need what we're building?

Because it doesn't exist, and it should. The lack of widely available network automation tools leads most networks to be built and managed by hand, which means that they're less consistent than they could and should be, which in turn makes them less reliable and harder to troubleshoot.

In the words of our founder, Brent Chapman:

My background is system administration, with a specialization on network design and management. Like many good sysadmins, I'm fundamentally lazy. I enjoy figuring out all the finicky details to make a system or network do what I want, experimenting with the configurations, and figuring out what works best to deliver a reliable and cost-effective service as cheaply and easily as possible. Once I've figured things out for a particular situation, though, I'm not especially fond of the routine, repetitive work that's usually involved in deploying and maintaining what I've designed and built. When it's done by hand, besides being boring, such repetitive configuration work is also very error-prone, which leads to inconsistent configurations, which in turn leads to unreliable services.

Given this fundamental laziness, I've long recognized the power of automation. When it comes to UNIX/Linux hosts, automation systems like Puppet and cfengine give me a great way to turn my designs into repeatable recipes that can be implemented over and over again. There seem to be similar tools in the Windows world, though I'm not as familiar with that space.

However, there haven't been similar tools widely and accessibly available in the networking world. Sure, if you're the average large enterprise and you've got a few hundred thousand dollars to spend, there are commercial packages you can buy. If you've got really unique requirements, and a couple of million dollars to spend, and a couple of years to spend on the project, you can build your own tools. But if you're the typical sysadmin who uses tools like Puppet or cfengine to handle your host configuration and replication needs, what would you use to handle your networking gear (routers, switches, load balancers, firewalls, VPN concentrators, and so forth) and services (Nagios, MRTG, Cricket, etc.)? There just hasn't been any equivalent platform in the networking space, and we aim to change that.

Like many sysadmins, I've often created shell scripts and similar tools to address this problem in a particular situation. These scripts and tools have always been very site- and situation-specific, though, tightly bound to the particular circumstances at hand. Every time I've written something like that, I've wished there was, instead, an easily available platform that I could have built on, as well as a community of users supporting that platform to learn from and share with.

I'm tired of waiting for somebody else to create that platform, and nurture the community around it, so that's what we're going to do.

Why shouldn't I manage my configs by hand, as I've always done?

The problem isn't managing any single config, for a single device or service; that can clearly be done by hand, and it either works or it doesn't.

The problem is managing multiple related configs across multiple devices and services. How do you ensure that those configs are consistent and complete across all those devices and services? If you do it by hand, you're probably going to make errors, which in turn are going to make your network less reliable and harder to scale. On the other hand, if you generate all those configs from a common model of your network using Netomata's tools, those configs will be consistent and complete. And even if you make an error in setting up the templates that the configs are generated from, it will be much easier to fix the template and regenerate the configs than it would be to fix all the individual configs by hand.

I've already created my configs by hand; why would I want to use Netomata tools?

Most network engineers works out their base config by hand, often in a lab or pre-production environment. However, once you've got your base configs worked out, how do you keep them working as you extend your network to multiple devices, sites, and services? If you're editing your configs by hand, inconsistencies are going to creep in (you add an interface to a router, for example, but forget to add it to a firewall or to the monitoring system; or, you do add it to those as well, but typo one of those additions). That's where our tool comes in; it gives you a way to turn those base configs (worked out by hand) into something that you can grow and evolve in a consistent and complete way (which leads to a more reliable and scalable network).

I'm adding a second site; why not just use a handful of simple Perl scripts to convert my existing configs?

You could write a couple of small Perl scripts to do a one-time conversion job for one platform (your firewall, for instance). But then what? How do you continue to keep those configurations consistent between the two sites, as both grow and evolve? How do you keep things consistent between the firewalls and the load balancers (and the monitoring systems and the VLAN switches and the VPN concentrators and ...)? If you're doing it by hand, as most organizations currently do, you're working harder than you have to and inconsistencies are guaranteed to creep in, because people make mistakes. They make typos, they get interrupted, they get distracted, or whatever. If you're maintaining a bunch of related-but-independent configurations by hand, they're going to devolve over time.

If you use Netomata's tools to generate all of your configs, you can then easily generate revised configs whenever you need to as the sites grow and evolve.

Why shouldn't I write my own tools to generate configs?

You could create the tools to do that yourself, and historically many folks have because there wasn't any alternative, but why would you now that Netomata's tools are available? Are you going to write your own web server, instead of using Apache? Code up your own monitoring system, instead of using MRTG or Nagios or whatever? If good tools are available, it's smart to use them to leverage your efforts and expertise.

Aren't these tools just for junior network engineers, not gurus?

Should a network guru be making routine move/add/change config changes by hand, or would they better spend their time on bigger issues? Most likely, they're going to tell junior network admins how to make those changes, and then hope the juniors do it correctly and consistently. Netomata's tools give network gurus a way to ensure that the correct configs (all of them, for all the various devices and services that you've templated for your network) are generated, rather than hoping the juniors do it perfectly when they do it by hand. It means fewer opportunities for mistakes in the handoff from guru to operating staff, and better leveraging of the guru's time and expertise (by working on architectural issues, and reflecting that expertise into templates).

What platforms, products, or services do the Netomata tools support?

Does Netomata support Cisco, Juniper, Checkpoint? Does Netomata support F5, Netscalers, etc.?

At this point, we support any of those, or none, depending on how you interpret the question.

What we're building, and have the very earliest version of available now, is a platform-independent tool. It will generate config files for whatever platforms you give it templates for. So, questions like these are analogous to asking someone creating a word processor "what kind of documents can you create? Memos? White papers? Family letters? Shopping lists? Business letters?" The answer is "yes, all of those."

Right now, you have to create the templates yourself for particular platforms (Cisco, Juniper, Checkpoint, F5, Netscaler, etc.) and use cases (web hosting, enterprise app hosting, VoIP, VPN, monitoring, etc.). Over time, we plan to offer an ever-growing library of templates for various platforms and use cases, to give people a head start on building new environments.

Even at this early stage, without the library, the tool is still useful, because it gives you a way to automate the generation (and regeneration) of configs in a consistent manner, thus improving your network's reliability and scalability. You can take your existing configs and "templatize" them (i.e., decide what parts are static and what parts should be generated from a description of your network). This should make your existing network both more reliable (by eliminating accidental inconsistencies between devices or services; for example, when you add an interface to a router, it will also be added to the monitoring system, consistently, automatically, and instantly) and more scalable (by making it quick and easy to activate and configure new devices and interfaces, or to make consistent configuration changes across multiple existing devices).

What license are the tools released under?

Netomata Config Generator (ncg) is released under the GNU General Public License, version 3.

For more information, see the Netomata Config Generator (ncg) License page.

What environment do the Netomata tools require?

The Netomata tools are written in Ruby. We've developed the code under Ruby version 1.8.6; we haven't yet tested it under other versions, such as the new Ruby 1.9. You can find out what version of Ruby you have with the "ruby -v" command.

The tools should run just fine on any UNIX or Linux system (including MacOS X; that's where we do most of our development, as it happens). We haven't tried them under Windows yet, but they'll probably work there too (if not, let us know what problems you ran into by email to bugs@netomata.com, and we'll see about fixing them so that they do).

In addition to the standard Ruby libraries, the tools also requires the Facets and ruby-debug gems. You should be able to easily install these gems, if you don't already have them, with the commands "gem install facets" and "gem install ruby-debug".

How do I run the tools on MacOS X 10.5 (Leopard)?

Most of the development of the Netomata tools has been done under Mac OS X 10.5 (Leopard), so that's a fine platform to run the tools on. Beyond a basic MacOS X Leopard installation, you need to do 3 things to run the tools on Leopard:

  1. Install the "Xcode Tools" package from the "Optional Installs" folder on the MacOS 10.5 DVD, if you haven't already.

  2. Set the following environment variables in your .bashrc or equivalent (we're not CERTAIN this is necessary, but it doesn't seem to hurt anything): GEM_PATH=/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8:\ /Library/Ruby/Gems/1.8 export GEM_HOME=/Library/Ruby/Gems/1.8

  3. Run the following commands as root to install the "facets" and "ruby-debug" packages: gem update --system gem update gem install facets gem install ruby-debug


RANCID is a popular tool for monitoring for changes in the configurations of network devices (routers, switches, firewalls, etc.). NCG, on the other hand, is more analogous to a tool like Puppet or cfengine, though it's intended for networking gear rather than UNIX/Linux host. NCG generates the config files for your network devices and services, rather than simply monitoring those files for changes the way RANCID does.

If RANCID detects any meaningful changes in the configurations of the devices that it is monitoring, it emails you about them, and checks the new config into a version control system. RANCID doesn't generate configs, though; it doesn't know or care where a config originally comes from, or whether changes to it were made manually or by some automated system, it merely monitors those changes.

In contrast, NCG generates whole config files from templates and a high-level description of your network. Because the config files are generated rather than hand-maintained, they are more likely to be complete and consistent (particularly across multiple related devices, such as multiple redundant switches in a hosting environment, or across firewalls and load balancers serving the same hosting environment). More complete and consistent configs makes your network more reliable. Generating configs rather than maintaining them by hand makes your network easier to manage and grow; when you need to make a change, you change the templates and/or description of the network as appropriate, run NCG, and regenerate a new set of complete, consistent configs for all your devices (routers, switches, load balancers, firewalls, etc.) and services (DNS servers, DHCP servers, monitoring systems such as Nagios and Cacti and Munin, etc.).

You can read more about the philosophy behind NCG at http://www.netomata.com/benefits

The initial release of NCG doesn't actually attempt to place the generated configs on any of the devices; it merely generates config files which you can review and install as, when, and however you see fit. In the future, we'll be looking at integrating NCG with tools like Puppet (for installing config files for UNIX/Linux-based services such as DNS, DHCP, and monitoring) and Ziptie (for installing configs on network devices).