Changes between Initial Version and Version 1 of NCG

24 Jul 2009, 12:56:55 (11 years ago)



  • NCG

    v1 v1  
     1= Introduction =
     3This document describes the [ Netomata Config Generator (NCG)] implementation and usage for the IETF meeting network.
     5NCG is used to generate complete, consistent, ready-to-install config files for a number of devices and services in the IETF network, including:
     6 * Devices
     7   * Routers
     8   * Switches
     9   * Access Points (APs)
     10 * Services
     11   * RANCID
     12   * DNS
     14The benefits of using NCG are discussed in detail on Netomata's [ Benefits of Automating Network Configuration] page.  In a nutshell, using NCG to generate all these config files ensures that they are complete and consistent, which yields a number of benefits:
     15 * It's faster to bring up the network, because NCG has all the configs ready to install; configs don't have to be manually and individually created and customized.
     16 * The network requires less troubleshooting during bring-up, because the NCG-generated configs are more consistent and complete than manually-created and customized config files would be.
     17 * The network is easier to troubleshoot once it is in service, because configurations, names, addresses, and so forth are more consistent from device to device.
     18 * It's easier to make network-wide changes.  Instead of figuring out and making the change on each device individually (and maybe typoing the changes on some devices, or accidentally skipping other devices), you can simply change the templates which NCG uses to generate the configs, and then generate a whole new set of configs with the change made consistently across all devices.
     20= NCG Documentation =
     22The [wiki:NCGHowTo] document gives brief instructions for how to use NCG to perform many common tasks for the IETF meeting network.
     24The [wiki:NCGFiles] document describes the input and output files that NCG uses and generates for the IETF meeting network.
     26NCG itself is documented on the web at []
     28= How NCG Works =
     30In a nutshell, NCG operates in two phases:
     32 * First, the program builds up an internal model of the network by parsing [ '''.neto''' files] and [ tables].
     33   * These files describe the network, including all the information about various devices (routers, switches, etc.) and services (RANCID, DNS, etc.) that's needed in order to generate configs.
     34   * These files also include references to various config-file templates in [ '''.ncg''' format], which are used to generate the actual config files.
     35 * Then, the program crawls through this internal model of the network, using the referenced templates to generate config files as directed.
     37  '''Tip:''' After '''ncg''' completes the first phase, its internal model of the network can be dumped for examination using the "{{{-d}}}" flag to the {{{ncg}}} program.
     39  If the "{{{-d}}}" flag to {{{ncg}}} is used, the program simply exits after dumping the internal model of the network that it has constructed, __without__ generating any config files.
     41  See the [ '''ncg''' manual page] for more information.
     43= NCG's Internal Network Model =
     45The internal model of the network that NCG creates is a tree-structured description of the network, as described in the [ '''.neto''' file] documentation.
     47The tree is like a UNIX filesystem:
     49 * Each node within the tree is like a fileystem directory; it contains a mix of named sub-nodes (which are like subdirectories) and named elements (which are like files, with the value of the element being analogous to the contents of the file).
     50 * Each node or element has a "key" that describes its location with, just as each directories and files has a pathname. The separator for parts of the key is "!", similar to how "/" is the separator for parts of file or directory pathnames (FYI, "!" was chosen because, unlike "/", it is not commonly used as part of interface names on network devices).
     51 * Just like files and directories, nodes can be referred to by either their absolute key (pathname), or in relation to another node. For example, if you're working with node "!a!b!c", then node "d!e" is going to be a reference to the sub-element with the full key "!a!b!c!d!e".
     53== Structure ==
     55The structure of the tree, and particularly the naming of elements within the tree, is established by convention (just as convention establishes the filesystem structure of a typical UNIX system to be "/bin", "/usr/lib", "/var", and so forth).
     57  '''Tip:''' To get a listing of all the keys in the network model, use the "{{{ncg -k ''neto_file''}}}" command (for instance, "{{{ncg -k ietf.neto}}}"). This is like doing "{{{find / -print}}}" to see the names of all the files and directories in a filesystem.
     59= Files and Directories =
     61See the [wiki:NCGFiles] wiki page.