CFGMAKER(1)                          mrtg                          CFGMAKER(1)

N?NA?AM?ME?E

       cfgmaker - Creates mrtg.cfg files (for mrtg-2.17.7)

S?SY?YN?NO?OP?PS?SI?IS?S

       cfgmaker [options] [community@]router [[options] [community@]router

       ...]

O?OP?PT?TI?IO?ON?NS?S

        --ifref=nr    interface references by Interface Number (default)

        --ifref=ip                     ... by Ip Address

        --ifref=eth                        ... by Ethernet Number

        --ifref=descr                      ... by Interface Description

        --ifref=name                       ... by Interface Name

        --ifref=type                       ... by Interface Type

                       You may also use multiple options separated by commas,

                      in which case the first available one is used:

                      e.g.  --ifref=ip,name,nr

        --ifdesc=nr       interface description uses Interface Number (default)

        --ifdesc=ip                        ... uses Ip Address

        --ifdesc=eth                       ... uses Ethernet Number

        --ifdesc=descr                     ... uses Interface Description

        --ifdesc=name                      ... uses Interface Name

        --ifdesc=catname                   ... uses CatOS Interface Name

        --ifdesc=ppname                    ... uses Passport Port Name

        --ifdesc=alias                     ... uses Interface Alias

        --ifdesc=type                      ... uses Interface Type

                       You may also use multiple options separated by commas,

                      in which case the first available one is used:

                      e.g.  --ifdesc=catname,ppname,descr,alias,ip,name,nr

        --if-filter=f     Test every interface against filter f to decide wether

                          or not to include that interface into the collection.

                          Currently f is being evaluated as a Perl expression

                          and it's truth value is used to reject or accept the

                          interface.

                          (Experimental, under development, might change)

        --if-template=templatefile

                          Replace the normal target entries for the interfaces

                          with an entry as specified by the contents in the file

                          templatefile.  The file is supposed to contain Perl

                          code to be executed to generate the lines for the

                          target in the configuration file.

                          (Experimental, under development, might change)

        --host-template=templatefile

                          In addition to creating targets for a host's interfaces

                          do also create targets for the host itself as specified

                          by the contents in the file templatefile.  The file is

                          supposed to contain Perl code to be executed to generate

                          the lines for the host related targets (such as CPU,

                          ping response time measurements etc.) in the config-

                          uration file.

                          (Experimental, under development, might change)

        --global "x: a"   add global config entries

        --no-down         do not look at admin or opr status of interfaces

        --show-op-down    show interfaces which are operatively down

        --zero-speed=spd  use this speed in bits-per-second as the interface

                          speed for all interfaces that return a speed of 0

                          via ifSpeed/ifHighSpeed.  100Mbps = 100000000

        --subdirs=format  give each router its own subdirectory, naming each per

                          "format", in which HOSTNAME and SNMPNAME will be

                          replaced by the values of those items -- for instance,

                          --subdirs=HOSTNAME or --subdirs="HOSTNAME (SNMPNAME)"

        --noreversedns    do not reverse lookup ip numbers

        --community=cmty  Set the default community string to "cmty" instead of

                          "public".

        --enable-ipv6     Enable IPv6 support, if the required libraries are

                          present. Numeric IPv6 addresses must be enclosed

                          in square brackets, e.g. public@[2001:760:4::1]:161

        --use-16bit       Use 16bit SNMP request IDs to query all routers.

        --snmp-options=:[<port>][:[<tmout>][:[<retr>][:[<backoff>][:<ver>]]]]

                          Specify default SNMP options to be appended to all

                          routers following.  Individual fields can be empty.

                          Routers following might override some or all of the

                  options given to --snmp-options.

        --dns-domain=domain

                  Specifies a domain to append to the name of all

                  routers following.

        --nointerfaces    Don't do generate any configuration lines for interfaces,

                          skip the step of gathering interface information and

                          don't run any interface template code.

        --interfaces      Generate configuration lines for interfaces (this is the

                          default).  The main purpose of this option is to negate

                          an --nointerfaces appearing earlier on the command line.

        --help            brief help message

        --man             full documentation

        --version         print the version of cfgmaker

        --output=file     output filename default is STDOUT

D?DE?ES?SC?CR?RI?IP?PT?TI?IO?ON?N

       C?Cf?fg?gm?ma?ak?ke?er?r creates MRTG configuration files based on information pulled

       from a router or another SNMP manageable device.

       [_?c_?o_?m_?m_?u_?n_?i_?t_?y@?@]_?r_?o_?u_?t_?e_?r

       _?C_?o_?m_?m_?u_?n_?i_?t_?y is the community name of the device you want to create a

       configuration for. If not specified, it defaults to 'p?pu?ub?bl?li?ic?c'; you might

       want to try this first if you do not know the community name of a

       device. If you are using the wrong community name you will get no

       response from the device.

       _?R_?o_?u_?t_?e_?r is the DNS name or the IP number of an SNMP-managable device.

       Following the name you can specify 6 further options separated by

       colons.  The full syntax looks like this:

       r?ro?ou?ut?te?er?r[:[p?pr?rt?t][:[t?tm?mo?ou?ut?t][:[r?re?et?tr?r][:[b?ba?ac?ck?ko?of?ff?f][:v?ve?er?rs?s]]]]]

       Of special interest may be the last parameter, v?ve?er?rs?s.  If you set this

       to '2' then your device will be queried with SNMP version 2 requests.

       This allows you to poll the 64 bit traffic counters in the device and

       will thus work much better with fast interfaces (no more counter

       overrun).  Note that the order in which the routers are specified on

       the command line do matter as the same order is used when the

       configuration file is generated.  The first specified router has it's

       configuration lines genrated first, followed by the lines belonging to

       the next router and so on.

       Note that the first line of the generated cfg file will contain all the

       commandline options you used for generating it. This is to allow for

       the easy 'regeneration' in case you want to add newhosts or make some

       other global change.

   C?Co?on?nf?fi?ig?gu?ur?ra?at?ti?io?on?n

       Except for the -?--?-o?ou?ut?tp?pu?ut?t and -?--?-g?gl?lo?ob?ba?al?l options, all options affect only

       the routers following them on the command line.  If an option specified

       earlier on the command line reappears later on the command line with

       another value, the new value overrides the old value as far as

       remaining routers are concerned.  This way options might be tailored

       for groups of routers or for individual routers.

       See -?--?-o?ou?ut?tp?pu?ut?t and -?--?-g?gl?lo?ob?ba?al?l for how their behaviour is affected by where

       or how many times they appear on the command line.

       See the E?Ex?xa?am?mp?pl?le?es?s below on how to set an option differently for multiple

       routers.

       -?--?-h?he?el?lp?p

           Print a brief help message and exit.

       -?--?-m?ma?an?n

           Prints the manual page and exits.

       -?--?-v?ve?er?rs?si?io?on?n

           Print the version of cfgmaker.  This should match the version of

           MRTG for which config files are being created.

       -?--?-i?if?fr?re?ef?f n?nr?r|i?ip?p|e?et?th?h|d?de?es?sc?cr?r|n?na?am?me?e

           Select the interface identification method.  Default is n?nr?r which

           identifies the router interfaces by their number.  Unfortunately

           the interface numbering scheme in an SNMP tree can change. Some

           routers change their numbering when new interfaces are added,

           others change thier numbering every full moon just for fun.

           To work around this sad problem MRTG can identify interfaces by 4

           other properties. None of these works for all interfaces, but you

           should be able to find one which does fine for you. Note that

           especially ethernet addrsses can be problematic as some routers

           have the same ethernet address on most of their interface cards.

           Select i?ip?p to identify the interface by its IP number. Use e?et?th?h to

           use the ethernet address for identification. Use d?de?es?sc?cr?r to use the

           Interface description. Or use n?na?am?me?e to use the Interface name.

           You can specify multiple properties if you wish, separated by

           commas.  In this case, cfgmaker will use the first item in the list

           which can provide unique identification.  This allows you to

           specify, for example, to use IP address and to use ifName if this

           is not defined:

             --ifref ip,name

           If your chosen method does not allow unique interface

           identification on the device you are querying, c?cf?fg?gm?ma?ak?ke?er?r will tell

           you about it.

       -?--?-i?if?fd?de?es?sc?c n?nr?r|i?ip?p|e?et?th?h|d?de?es?sc?cr?r|n?na?am?me?e|t?ty?yp?pe?e|a?al?li?ia?as?s

           Select what to use as the description of the interface.  The

           description appears in the "Title[]" property for the target as

           well as the text header in the HTML code defined in the target's

           "PageTop[]".  Default is to use n?nr?r which is just the interface

           number which isn't always useful to the viewer of the graphs.

           There are 6 other properties which could be used.  Use i?ip?p if you

           want to use the interface's IP-address.  Use e?et?th?h if you want to use

           the interface's ethernet address.  If you want a better

           description, you can use either d?de?es?sc?cr?r, n?na?am?me?e or a?al?li?ia?as?s.  Exactly what

           each of these do varies between different equipment so you might

           need to experiment.  For instance, for a serial interface on a

           Cisco router running IOS using n?na?am?me?e might result in "S0" being the

           interface description , d?de?es?sc?cr?r might result in "Serial0" and a?al?li?ia?as?s

           might result in "Link to HQ" (provided that is what is used as the

           interface's "description" in the router's configuration).

           Finally, if you want to describe the interface by it's Btype (i.e

           "ethernetCSMA", "propPointtoPoint" etc) you can use t?ty?yp?pe?e.

           You can specify multiple properties if you wish, separated by

           commas.  In this case, cfgmaker will use the first item in the list

           which is available for this interface.  This allows you to specify,

           for example, to use any of the different aliases in order of

           preference.

       -?--?-i?if?f-?-f?fi?il?lt?te?er?r 'f?fi?il?lt?te?er?r-?-e?ex?xp?pr?re?es?ss?si?io?on?n'

           First of all, this is under some development and is experimental.

           Use this if you want to have better control over what interfaces

           gets included into the configuration.  The f?fi?il?lt?te?er?r-?-e?ex?xp?pr?re?es?ss?si?io?on?n is

           evaluated as a piece of Perl code and is expected to return a truth

           value.  If true, include the interface and if false, exclude the

           interface.

           For a further discussion on how these filters work, see the section

           "Details on Filters" below.

       -?--?-i?if?f-?-t?te?em?mp?pl?la?at?te?e t?te?em?mp?pl?la?at?te?e-?-f?fi?il?le?e

           First of all, this is under some development and is experimental.

           Use this if you want to control what the line for each target

           should look like in the configuration file.  The contents of the

           file t?te?em?mp?pl?la?at?te?e-?-f?fi?il?le?e will be evaluated as a Perl program which

           generates the lines using certain variables for input and output.

           For a further discussion on how these templates work, see the

           section "Details on Temaplates" below.

       -?--?-h?ho?os?st?t-?-t?te?em?mp?pl?la?at?te?e t?te?em?mp?pl?la?at?te?e-?-f?fi?il?le?e

           First of all, this is under some development and is experimental.

           Use this if you want to have some extra targets related to the host

           itself such as CPU utilization, ping response time to the host,

           number of busy modems etc.  The contents of the file t?te?em?mp?pl?la?at?te?e-?-f?fi?il?le?e

           will be evaluated once per host as a Perl program which generates

           the lines using certain variables for input and output.

           For a further discussion on how these templates work, see the

           section "Details on Templates" below.

       -?--?-c?co?om?mm?mu?un?ni?it?ty?y c?co?om?mm?mu?un?ni?it?ty?y-?-s?st?tr?ri?in?ng?g

           Use this to set the community for the routers following on the

           command line to c?co?om?mm?mu?un?ni?it?ty?y-?-s?st?tr?ri?in?ng?g.  Individual routers might

           overrride this community string by using the syntax

           c?co?om?mm?mu?un?ni?it?ty?y@?@r?ro?ou?ut?te?er?r.

       -?--?-e?en?na?ab?bl?le?e-?-i?ip?pv?v6?6

           This option enables IPv6 support. It requires the appropriate perl

           modules; if they are not found then IPv6 is disabled (see the ipv6

           documentation).

           cfgmaker will use IPv6 or IPv4 depending on the target. If the

           target is a numeric address, the protocol depends on the type of

           address. If the target is a hostname, cfgmaker will try to resolve

           the name first to an IPv6 address then to an IPv4 address.

           IPv6 numeric addresses must be specified between square braces.

           For example:

            cfgmaker --enable-ipv6 [2001:760:4::1]:165:::2

           If the target has both an IPv6 address and an IPv4 address with the

           same hostname, cfgmaker first queries the target using IPv6 and

           falls back to IPv4 if it fails. This is useful for targets which

           don't support SNMP over IPv6.

       -?--?-u?us?se?e-?-1?16?6b?bi?it?t

           This option forces the use of 16bit SNMP request IDs.  Some broken

           SNMP agents do not accept 32bit request IDs.  Try to avoid this

           option as much as possible, complain to your agent vendor instead.

       -?--?-s?sn?nm?mp?p-?-o?op?pt?ti?io?on?ns?s  :[p?po?or?rt?t][:[t?ti?im?me?eo?ou?ut?t][:[r?re?et?tr?ri?ie?es?s][:[b?ba?ac?ck?ko?of?ff?f][:v?ve?er?rs?si?io?on?n]]]]

           Use this to set the default SNMP options for all routers following

           on the command line.  Individual values might be omitted as well as

           trailing colons.  Note that routers might override individual (or

           all) values specified by -?--?-s?sn?nm?mp?p-?-o?op?pt?ti?io?on?ns?s by using the syntax

           r?ro?ou?ut?te?er?r[:[p?po?or?rt?t][:[t?ti?im?me?eo?ou?ut?t][:[r?re?et?tr?ri?ie?es?s][:[b?ba?ac?ck?ko?of?ff?f][:v?ve?er?rs?si?io?on?n]]]]]

       -?--?-g?gl?lo?ob?ba?al?l "?"_?b_?l_?a_?: _?a_?b_?c"?"

           Use this to add global options to the generated config file.  You

           can call -?--?-g?gl?lo?ob?ba?al?l several times to add multiple options.  The line

           will appear in the configuration just before the config for the

           next router appearing on the command line.

            --global "workdir: /home/mrtg"

           If you want some default Options you might want to put

            --global "options[_]: growright,bits"

           Specifying -?--?-g?gl?lo?ob?ba?al?l after the last router on the command line will

           create a line in the configuration file which will appear after all

           the routers.

       -?--?-n?no?or?re?ev?ve?er?rs?se?ed?dn?ns?s

           Do not try to reverse lookup IP numbers ... a must for DNS free

           environments.

       -?--?-n?no?o-?-d?do?ow?wn?n

           Normally cfgmaker will not include interfaces which are marked

           anything but administratively and operationally UP. With this

           switch you get them all.

       -?--?-s?sh?ho?ow?w-?-o?op?p-?-d?do?ow?wn?n

           Include interfaces which are operatively down.

       -?--?-z?ze?er?ro?o-?-s?sp?pe?ee?ed?d _?s_?p_?e_?e_?d

           Assign this speed in bits-per-second to all interfaces which return

           0 for ifSpeed and ifHighSpeed.  Some switches, notably Foundry

           equipment, return a speed of zero for some interfaces.  For

           example, to have all interfaces reporting zero set to 100Mbps, use

           --zero-speed=100000000.

       -?--?-s?su?ub?bd?di?ir?rs?s _?f_?o_?r_?m_?a_?t

           Give each router its own subdirectory for the HTML and graphics (or

           .rrd) files.  The directory name is the given _?f_?o_?r_?m_?a_?t string with a

           couple of pattern replacements.  The string "HOSTNAME" will be

           replaced by the hostname of the router (however you specified it on

           the c?cf?fg?gm?ma?ak?ke?er?r commandline -- it may be an actual hostname or just an

           IP address), and "SNMPNAME" will be replaced with the device's idea

           of its own name (the same name that appears on the right side of

           the "Title" lines).  For instance, a call like:

            cfgmaker --subdirs=HOSTNAME__SNMPNAME public@10.10.0.18

           would result in the generation of lines looking something like:

            Directory[10.10.0.18_1]: 10.10.0.18__fp2200-bothrip-1.3

       -?--?-o?ou?ut?tp?pu?ut?t _?f_?i_?l_?e

           Write the output from c?cf?fg?gm?ma?ak?ke?er?r into the file _?f_?i_?l_?e. The default is

           to use "STDOUT". -?--?-o?ou?ut?tp?pu?ut?t is expected to appear only once on the

           command line. If used multiple times, the file specified by the

           last -?--?-o?ou?ut?tp?pu?ut?t will be used.

       -?--?-n?no?oi?in?nt?te?er?rf?fa?ac?ce?es?s

           Don't generate configuration lines for interfaces.

           This makes cfgmaker skip all steps related to interfaces which

           means it will not do any polling of the router to retrieve

           interface information which speeds up the execution of cfgmaker and

           it will neither run any interface templates.

       -?--?-i?in?nt?te?er?rf?fa?ac?ce?es?s

           This makes cfgmaker generate configuration lines for interfaces

           (the default behaviour).

           The main usage of this option is to negate an --nointerfaces

           appearing earlier on the command line.

   S?SN?NM?MP?P V?V3?3 O?Op?pt?ti?io?on?ns?s

       C?Cf?fg?gm?ma?ak?ke?er?r supports SNMP V3 using the N?Ne?et?t:?:S?SN?NM?MP?P perl module.  There are

       optional parameters affecting SNMP operation.

       --enablesnmpv3 {yes|no}

           The -?--?-e?en?na?ab?bl?le?es?sn?nm?mp?pv?v3?3 option is an optional flag to check for the

           presence of the N?Ne?et?t:?::?:S?SN?NM?MP?P libraries.  C?Cf?fg?gm?ma?ak?ke?er?r will try to

           determine whether this flag is required and will set the values

           automatically.

       _?S_?N_?M_?P_?v_?3 _?A_?r_?g_?u_?m_?e_?n_?t_?s

       A SNMP context is a collection of management information accessible by

       a SNMP entity.  An item of management information may exist in more

       than one context and a SNMP entity potentially has access to many

       contexts.  The combination of a contextEngineID and a contextName

       unambiguously identifies a context within an administrative domain.  In

       a SNMPv3 message, the contextEngineID and contextName are included as

       part of the scopedPDU.  All methods that generate a SNMP message

       optionally take a -?--?-c?co?on?nt?te?ex?xt?te?en?ng?gi?in?ne?ei?id?d and -?--?-c?co?on?nt?te?ex?xt?tn?na?am?me?e argument to

       configure these fields.

       Context Engine ID

           The -?--?-c?co?on?nt?te?ex?xt?te?en?ng?gi?in?ne?ei?id?d argument expects a hexadecimal string

           representing the desired contextEngineID.  The string must be 10 to

           64 characters (5 to 32 octets) long and can be prefixed with an

           optional "0x".  Once the -?--?-c?co?on?nt?te?ex?xt?te?en?ng?gi?in?ne?ei?id?d is specified it stays

           with the object until it is changed again or reset to default by

           passing in the undefined value.  By default, the contextEngineID is

           set to match the authoritativeEngineID of the authoritative SNMP

           engine.

       Context Name

           The contextName is passed as a string which must be 0 to 32 octets

           in length using the -?--?-c?co?on?nt?te?ex?xt?tn?na?am?me?e argument.  The contextName stays

           with the object until it is changed.  The contextName defaults to

           an empty string which represents the "default" context.

       _?U_?s_?e_?r_?-_?b_?a_?s_?e_?d _?S_?e_?c_?u_?r_?i_?t_?y _?M_?o_?d_?e_?l _?A_?r_?g_?u_?m_?e_?n_?t_?s

       The User-based Security Model (USM) used by SNMPv3 requires that a

       securityName be specified using the -?--?-u?us?se?er?rn?na?am?me?e argument.  The creation

       of a Net::SNMP object with the version set to SNMPv3 will fail if the

       -?--?-u?us?se?er?rn?na?am?me?e argument is not present.  The -?--?-u?us?se?er?rn?na?am?me?e argument expects a

       string 1 to 32 octets in length.

       Different levels of security are allowed by the User-based Security

       Model which address authentication and privacy concerns.  A SNMPv3

       target will derive the security level (securityLevel) based on which of

       the following arguments are specified.

       By default a securityLevel of 'noAuthNoPriv' is assumed.  If the

       -?--?-a?au?ut?th?hk?ke?ey?y or -?--?-a?au?ut?th?hp?pa?as?ss?sw?wo?or?rd?d arguments are specified, the securityLevel

       becomes 'authNoPriv'.  The -?--?-a?au?ut?th?hp?pa?as?ss?sw?wo?or?rd?d argument expects a string

       which is at least 1 octet in length.  Optionally, the -?--?-a?au?ut?th?hk?ke?ey?y

       argument can be used so that a plain text password does not have to be

       specified in a script.  The -?--?-a?au?ut?th?hk?ke?ey?y argument expects a hexadecimal

       string produced by localizing the password with the

       authoritativeEngineID for the specific destination device.  The

       "snmpkey" utility included with the Net::SNMP  distribution can be used

       to create the hexadecimal string (see snmpkey).

       Two different hash algorithms are defined by SNMPv3 which can be used

       by the Security Model for authentication.  These algorithms are

       HMAC-MD5-96 "MD5" (RFC 1321) and HMAC-SHA-96 "SHA-1" (NIST FIPS PUB

       180-1).   The default algorithm used by the module is HMAC-MD5-96.

       This behavior can be changed by using the -?--?-a?au?ut?th?hp?pr?ro?ot?to?oc?co?ol?l argument.

       This argument expects either the string 'md5' or 'sha' to be passed to

       modify the hash algorithm.

       By specifying the arguments -?--?-p?pr?ri?iv?vk?ke?ey?y or -?--?-p?pr?ri?iv?vp?pa?as?ss?sw?wo?or?rd?d the

       securityLevel associated with the object becomes 'authPriv'.  According

       to SNMPv3, privacy requires the use of authentication.  Therefore, if

       either of these two arguments are present and the -?--?-a?au?ut?th?hk?ke?ey?y or

       -?--?-a?au?ut?th?hp?pa?as?ss?sw?wo?or?rd?d arguments are missing, the creation of the object fails.

       The -?--?-p?pr?ri?iv?vk?ke?ey?y and -?--?-p?pr?ri?iv?vp?pa?as?ss?sw?wo?or?rd?d arguments expect the same input as the

       -?--?-a?au?ut?th?hk?ke?ey?y and -?--?-a?au?ut?th?hp?pa?as?ss?sw?wo?or?rd?d arguments respectively.

       The User-based Security Model described in RFC 3414 defines a single

       encryption protocol to be used for privacy.  This protocol, CBC-DES

       "DES" (NIST FIPS PUB 46-1), is used by default or if the string 'des'

       is passed to the -?--?-p?pr?ri?iv?vp?pr?ro?ot?to?oc?co?ol?l argument.  By working with the Extended

       Security Options Consortium http://www.snmp.com/eso/, the module also

       supports additional protocols which have been defined in draft

       specifications.  The draft

       http://www.snmp.com/eso/draft-reeder-snmpv3-usm-3desede-00.txt defines

       the support of CBC-3DES-EDE "Triple-DES" (NIST FIPS 46-3) in the User-

       based Security Model.  This protocol can be selected using the

       -?--?-p?pr?ri?iv?vp?pr?ro?ot?to?oc?co?ol?l argument with the string '3desede'.  The draft

       http://www.snmp.com/eso/draft-blumenthal-aes-usm-04.txt describes the

       use of CFB128-AES-128/192/256 "AES" (NIST FIPS PUB 197) in the USM. The

       three AES encryption protocols, differentiated by their key sizes, can

       be selected by passing 'aescfb128', 'aescfb192', or 'aescfb256' to the

       -?-p?pr?ri?iv?vp?pr?ro?ot?to?oc?co?ol?l argument.

   D?De?et?ta?ai?il?ls?s o?on?n F?Fi?il?lt?te?er?rs?s

       The purpose of the filters is to decide which interfaces to accept and

       which interfaces to reject.  This decision is done for each interface

       by evaluating the filter expression as a piece of Perl code and

       investigating the result of the evaluation.  If true, accept the

       interface otherwise reject it.

       When working with filters, remember that Perl has it's own idea of what

       truth and false is.  The empty string "" and the string "0" are false,

       all other strings are true.  This further imples that any integer value

       of 0 is false as well as any undef value.  It also implies that all

       references are considered true.

       As the filter is evaluated as a Perl expression, several useful

       constructs in Perl are worth mentioning:

       Expressions might be grouped by using parentheses "()".  Expressions

       might be combined using boolean operators such as the following:

       "a?an?nd?d" (equivalent with "&?&&?&")

           Boolean "and" of the two expressions, is only true if both

           expressions are true.  Example: _?e_?x_?p_?r_?e_?s_?s_?i_?o_?n_?1 a?an?nd?d _?e_?x_?p_?r_?e_?s_?s_?i_?o_?n_?2

       "o?or?r" (equivalent with "|?||?|")

           Boolean "or" of the two expressions, is true if either or both

           expressions are true.  Example: _?e_?x_?p_?r_?e_?s_?s_?i_?o_?n_?1 o?or?r _?e_?x_?p_?r_?e_?s_?s_?i_?o_?n_?2

       "n?no?ot?t" (equivalent with "!?!")

           Boolean negation of a single expression.  Example:  n?no?ot?t _?e_?x_?p_?r_?e_?s_?s_?i_?o_?n

           .  Yet another example: !?!_?e_?x_?p_?r_?e_?s_?s_?i_?o_?n

       (For more details on this I recommend a book on Perl)

       _?P_?r_?e_?d_?e_?f_?i_?n_?e_?d _?F_?i_?l_?t_?e_?r _?V_?a_?r_?i_?a_?b_?l_?e_?s

       To facilitate, there are a number of predefined values available to use

       in the filter.  Note that these variables are also available when

       templates interfaces are evaluated (but not host templates).

       Caveat:  All these variables' names begin with a dollar sign  ($),

       which is a syntactic requirement for scalar variables in Perl.  The

       danger here is that the dollar sign in many shells is an active

       character (often used for shell variables exactly as in Perl variables)

       so it is important to ensure that the Perl expression isn't evaluated

       by the command line shell as shell code before being passed to cfgmaker

       as command line arguments.  In shells like Bourne shell, ksh shell or

       bash shell, placing the entire expression within single qoutes will

       avoid such accidental evaluation:

        '--if-filter=($default_iftype && $if_admin)'

       $?$i?if?f_?_t?ty?yp?pe?e

           This is an integer specifying the interface type as per the SNMP

           standards and as reported by the polled device.  A complete list of

           interface types would be impractical for this document , but there

           are a number predefined varables below.  Normally, cfgmaker puts in

           the target's PageTop this iftype value within paranthesis after the

           name of the interface type. (e.g "propPointToPointSerial (22)").

           Here's a list of some of the most common interface types by number:

              6 ethernetCsmacd

              7 iso88023Csmacd

              9 iso88025TokenRing

             15 fddi

             19 E1

             20 basicISDN

             21 primaryISDN

             22 propPointToPointSerial

             23 ppp

             24 softwareLoopback

             30 ds3

             32 frame-relay

             33 rs232

             37 atm

             39 sonet

             44 frameRelayService

             46 hssi

             49 aal5

             53 propVirtual

             62 Fast Ethernet (100BaseT)

             63 ISDN & X.25

             69 Full Duplex Fast Ethernet (100BaseFX)

             94 Asymetric Digital Subscriber Loop (ADSL)

            117 Gigabit Ethernet

            134 ATM Sub Interface

       $?$d?de?ef?fa?au?ul?lt?t

           True if and only if cfgmaker normally should accepted the interface

           based on the interfaces administrative and operational state

           (taking the flags -?--?-n?no?o-?-d?do?ow?wn?n and -?--?-s?sh?ho?ow?w-?-o?op?p-?-d?do?ow?wn?n into account) and

           it's type (and a few other things).

       $?$d?de?ef?fa?au?ul?lt?t_?_i?if?fs?st?ta?at?te?e

           True if and only if cfgmaker would have accepted the interface

           based on it's operational and administrative states (also taking

           into account the presence of the flags -?--?-n?no?o-?-d?do?ow?wn?n and

           -?--?-s?sh?ho?ow?w-?-o?op?p-?-d?do?ow?wn?n).

       $?$d?de?ef?fa?au?ul?lt?t_?_i?if?ft?ty?yp?pe?e

           True if and only if cfgmaker would have accepted the interface

           based on it's type (and a few type specific details in addition).

       $?$i?if?f_?_a?ad?dm?mi?in?n

           True if and only if the interface is in an adminstrative up state.

       $?$i?if?f_?_o?op?pe?er?r

           True if and only if the interface is in an operational up state.

       A number of variables are also predefined to easily decide if an

       interface belong to a certain cathegory or not.  Below is all those

       variables listed together with which if_type numbers each variable will

       be true for.  Note that some variables refer to other variables as

       well.

       $?$i?if?f_?_i?is?s_?_e?et?th?he?er?rn?ne?et?t

           True for ethernet interfaces (nr 6, 7, 26, 62, 69 and 117).

       $?$i?if?f_?_i?is?s_?_i?is?sd?dn?n

           True for various ISDN interface types (nr 20, 21, 63, 75, 76 and

           77)

       $?$i?if?f_?_i?is?s_?_d?di?ia?al?lu?up?p

           True for dial-up interfaces such as PPP as well as ISDN.  (nr 23,

           81, 82 and 108 in addition to the numbers of $?$i?if?f_?_i?is?s_?_i?is?sd?dn?n).

       $?$i?if?f_?_i?is?s_?_a?at?tm?m

           True for miscellaneous ATM related interface types (nr 37, 49, 107,

           105, 106, 114 and 134).

       $?$i?if?f_?_i?is?s_?_w?wa?an?n

           True for WAN interfaces point to point, Frame Relay and High Speed

           Serial ( 22,32,44,46)

       $?$i?if?f_?_i?is?s_?_l?la?an?n

           True for LAN interfaces (8, 9, 11, 15, 26, 55, 59, 60 and 115 in

           addition to the numbers of $?$i?if?f_?_i?is?s_?_e?et?th?he?er?rn?ne?et?t).

       $?$i?if?f_?_i?is?s_?_d?ds?sl?l

           True for ADSL, RDSL, HDSL and SDSL (nr 94, 95, 96, 97)

       $?$i?if?f_?_i?is?s_?_l?lo?oo?op?pb?ba?ac?ck?k

           True for software loopback interfaces (nr 24)

       $?$i?if?f_?_i?is?s_?_c?ci?is?sc?co?ov?vl?la?an?n

           True for Cisco VLAN interfaces (interfaces with the word Vlan or

           VLAN in their ifdescs)

       $?$i?if?f_?_v?vl?la?an?n_?_i?id?d

           Returns the vlan id associated with a specific port on Cisco

           Catalyst switches under both Catalyst OS and IOS, and 3Com

           switches.  If it is not a vlan interface, will return undef.

       $?$i?if?f_?_c?ci?is?sc?co?o_?_t?tr?ru?un?nk?k

           Returns the trunking state of a specific port on Cisco Catalyst

           switches under both Catalyst OS and IOS.  Returns "1" if the

           interface is a trunk, undef otherwise.

       $?$i?if?f_?_M?MT?TU?U

           Returns the Maximum Transfer Unit associated with a specific port.

       Besides that, you can also use the variables defined for templates

       below.  Further, all the variables available in cfgmaker is at the

       scripts disposal even if the use of such features is discouraged.  More

       "shortcuts" in the form of variables and functions will be made

       available in the future instead.

       _?E_?x_?a_?m_?p_?l_?e_?s _?o_?n _?F_?i_?l_?t_?e_?r_?s

       The following filter will not affect which interfaces get's included or

       excluded, it will make cfgmaker behave as normally.

        '--if-filter=$default'

       The following filter will make cfgmaker exclude PPP (23) interfaces:

        '--if-filter=$default && $if_type!=23'

       The following filter will make cfgmaker behave as usual except that it

       will consider the operational state of an interface irrelevant but

       still reject all interfaces which are administratively down.

        '--if-filter=$if_admin && $default_iftype'

   D?De?et?ta?ai?il?ls?s o?on?n T?Te?em?mp?pl?la?at?te?es?s

       The contents of the template files are evaluated as a Perl program.  A

       number or Perl variables are available for the program to read and

       others are used to be written to.

       As quite a few of the predefined variables has values which are are

       supposed to be used in HTML code some of them have an "HTML-escaped"

       variant, e.g $html_syslocation is the HTML escaped variant of

       $syslocation.  The HTML escaping means that the chars "<", ">" and "&"

       are replaced by "<", ">" and "&" and that newlines embedded

       in the string are prepended with "
" and appended with a space

       character (if a newline is last in the string it is not touched).

       _?W_?r_?i_?t_?a_?b_?l_?e _?T_?e_?m_?p_?l_?a_?t_?e _?V_?a_?r_?i_?a_?b_?l_?e_?s

       These are the variables available to store the configuration lines in.

       Some of them are initialized prior to the evaluation of the template

       but such content normally is comments for inclusion in the final

       configuration file so those variables might be reset to the empty

       string in the template code to eliminate the comments.  The other way

       around is also possible, the contents of these variables might be

       extended with further information for various reasons such as debugging

       etc.

       Once the template has been evaluated, the following happens:  if the

       template is a interface template and the actual interface for some

       reason is rejected and thus needs to be commented out, all the lines in

       the variable $?$t?ta?ar?rg?ge?et?t_?_l?li?in?ne?es?s are turned into comments by adding a hash

       mark ("#") at their beginning.  Then all the variables $?$h?he?ea?ad?d_?_l?li?in?ne?es?s,

       $?$p?pr?ro?ob?bl?le?em?m_?_l?li?in?ne?es?s , $?$t?ta?ar?rg?ge?et?t_?_l?li?in?ne?es?s and $?$s?se?ep?pa?ar?ra?at?to?or?r_?_l?li?in?ne?es?s are concatenated

       together to form the lines to add to the configuration file.

       $?$t?ta?ar?rg?ge?et?t_?_l?li?in?ne?es?s

           This variable is the placeholder for the configuration lines

           created by the template.  $?$t?ta?ar?rg?ge?et?t_?_l?li?in?ne?es?s is predefined to be empty

           when the template code is evaluated.

       $?$h?he?ea?ad?d_?_l?li?in?ne?es?s

           This variable is intended to be the placeholder for the comment

           line appearing just before the target in the configuration file.

           It is initialized with that comment line before the evaluation of

           the template code and if the template doesn't modify $?$h?he?ea?ad?d_?_l?li?in?ne?es?s

           during evaluation, the comment will look like usual in the config

           file.

       $?$p?pr?ro?ob?bl?le?em?m_?_l?li?in?ne?es?s

           This variable is intended to be the placholder for the comment

           lines describing any problems which might have been encountered

           when trying to add the target into the configuration.  For host

           templates it's normally not used and for those it's predefined as

           the empty string.  For interface templates $?$p?pr?ro?ob?bl?le?em?m_?_l?li?in?ne?es?s is

           predefined with the error description comments which cfgmaker

           normally would use for rejected interfaces or as the empty string

           for accepted interfaces.

           It is possible to test against $?$p?pr?ro?ob?bl?le?em?m_?_l?li?in?ne?es?s to find out if an

           interface will be included or rejected but this is not recommended.

           Test against $?$i?if?f_?_o?ok?k instead.

       $?$s?se?ep?pa?ar?ra?at?to?or?r_?_l?li?in?ne?es?s

           This variable is the placeholder for the string to use as the

           separator between the code for individual targets.  The contents of

           this variable is put after each target (so the lines will appear

           after the end of the last target in the config as well).

       _?P_?r_?e_?d_?e_?f_?i_?n_?e_?d _?T_?e_?m_?p_?l_?a_?t_?e _?V_?a_?r_?i_?a_?b_?l_?e_?s

       All the variables below are available for interface templates to use.

       For host templates, only those listed under "Host and System Variables"

       are available.

       For interface templates the variables listed under "Predefined Filter

       Variables" are also available.

       _?H_?o_?s_?t _?a_?n_?d _?S_?y_?s_?t_?e_?m _?V_?a_?r_?i_?a_?b_?l_?e_?s

       $?$r?ro?ou?ut?te?er?r_?_n?na?am?me?e

           This is the fully qualified name for the router.  It is affected by

           the following items on the command line:  the router name itself

           and -?--?-d?dn?ns?s-?-d?do?om?ma?ai?in?n.

       $?$r?ro?ou?ut?te?er?r_?_c?co?on?nn?ne?ec?ct?t

           This is the reference string for the router being polled.  It is on

           the form community@router possibly followed by some snmp options.

           It is affected by the following items on the command line:  the

           router name itself, -?--?-c?co?om?mm?mu?un?ni?it?ty?y, -?--?-s?sn?nm?mp?p-?-o?op?pt?ti?io?on?ns?s and -?--?-d?dn?ns?s-?-d?do?om?ma?ai?in?n.

           (There's no HTML escaped variant available)

       $?$d?di?ir?re?ec?ct?to?or?ry?y_?_n?na?am?me?e

           This variable should contain the directory name as cfgmaker

           normally would use as the value for the "Directory[]" directive.

           The value is determined by the -?--?-s?su?ub?bd?di?ir?rs?s command line option.  If

           -?--?-s?su?ub?bd?di?ir?rs?s isn't specified $?$d?di?ir?re?ec?ct?to?or?ry?y_?_n?na?am?me?e will be the empty string.

           (There's no HTML escaped variant available)

       $?$s?sy?ys?sc?co?on?nt?ta?ac?ct?t

           This variable is the router's SNMP sysContact value.  (HTML escaped

           variant: $?$h?ht?tm?ml?l_?_s?sy?ys?sc?co?on?nt?ta?ac?ct?t)

       $?$s?sy?ys?sn?na?am?me?e

           This variable is the router's SNMP sysName value.  (No HTML escaped

           variant available)

       $?$s?sy?ys?sl?lo?oc?ca?at?ti?io?on?n

           This variable is the router's SNMP sysLocation value.  (HTML

           escaped variant: $?$h?ht?tm?ml?l_?_s?sy?ys?sl?lo?oc?ca?at?ti?io?on?n)

       $?$s?sy?ys?sd?de?es?sc?cr?r

           This variable is the router's SNMP sysDescr value.  It is normally

           not used by cfgmaker but might be useful in a template.  (HTML

           escaped variant: $?$h?ht?tm?ml?l_?_s?sy?ys?sd?de?es?sc?cr?r)

       _?I_?n_?t_?e_?r_?f_?a_?c_?e _?T_?a_?r_?g_?e_?t _?R_?e_?l_?a_?t_?e_?d _?V_?a_?r_?i_?a_?b_?l_?e_?s

       $?$t?ta?ar?rg?ge?et?t_?_n?na?am?me?e

           This is what cfgmaker normally would use as the the name of the

           target.  The target name is what is found within the square

           brackets, "[]", for target directives.  (There's no HTML escaped

           variant available)

       $?$i?if?f_?_r?re?ef?f

           This the reference string for the interface.  It is expected to be

           used in the "Target[xyz]" directive to distinguish what interface

           to use.  The value of this variable is affected by the -?--?-i?if?fr?re?ef?f

           command line option.  It is normally used together with

           $?$r?ro?ou?ut?te?er?r_?_c?co?on?nn?ne?ec?ct?t.  (There's no HTML escaped variant available)

       $?$i?if?f_?_o?ok?k

           This variable is true if the interface is going to be included into

           the configuration file, otherwise false.  Don't test against other

           variables such as $?$p?pr?ro?ob?bl?le?em?m_?_l?li?in?ne?es?s to find out if an interface will

           be rejected or not, use this $?$i?if?f_?_o?ok?k instead.

       $?$d?de?ef?fa?au?ul?lt?t_?_t?ta?ar?rg?ge?et?t_?_l?li?in?ne?es?s

           This variable contains all the target lines which cfgmaker by

           default outputs for this interface.  It's useful if you want to

           have the "standard target" but want to add some extra lines to it

           by using a template.

       By default cfgmaker uses the following directives for each target it

       generates: Target[], SetEnv[], MaxBytes[], Title[], PageTop[] and if

       there is any directory specified also the Directory[] directive.

       To facilitate the creation of templates which generates target configs

       which are similar to the default one, each of the above mentioned

       directive lines have a corresponding variable containing the line as

       cfgmaker would have output it by default.

       Note that none of these have a HTML escaped variant, text in them is

       HTML escaped where needed.  Also note that they do not have any newline

       at the end.

       $?$d?de?ef?fa?au?ul?lt?t_?_t?ta?ar?rg?ge?et?t_?_d?di?ir?re?ec?ct?ti?iv?ve?e

           This variable contains the default string for the Target[]

           directive line.

       $?$d?de?ef?fa?au?ul?lt?t_?_s?se?et?te?en?nv?v_?_d?di?ir?re?ec?ct?ti?iv?ve?e

           This variable contains the default string for the SetEnv[]

           directive line.

       $?$d?de?ef?fa?au?ul?lt?t_?_d?di?ir?re?ec?ct?to?or?ry?y_?_d?di?ir?re?ec?ct?ti?iv?ve?e

           This variable contains the default string for the Directory[]

           directive line which means it is an empty string (with no newline)

           if there's no directory.

       $?$d?de?ef?fa?au?ul?lt?t_?_m?ma?ax?xb?by?yt?te?es?s_?_d?di?ir?re?ec?ct?ti?iv?ve?e

           This variable contains the default string for the MaxBytes[]

           directive line.

       $?$d?de?ef?fa?au?ul?lt?t_?_t?ti?it?tl?le?e_?_d?di?ir?re?ec?ct?ti?iv?ve?e

           This variable contains the default string for the Title[] directive

           line.

       $?$d?de?ef?fa?au?ul?lt?t_?_p?pa?ag?ge?et?to?op?p_?_d?di?ir?re?ec?ct?ti?iv?ve?e

           This variable contains the default string for the PageTop[]

           directive lines.

       _?I_?n_?t_?e_?r_?f_?a_?c_?e _?N_?e_?t_?w_?o_?r_?k _?C_?o_?n_?f_?i_?g_?u_?r_?a_?t_?i_?o_?n _?V_?a_?r_?i_?a_?b_?l_?e_?s

       $?$i?if?f_?_i?ip?p

           This variable should contain the IP-address of the interface, if

           any has been assigned to it.  (There's no HTML escaped variant

           available)

       $?$i?if?fi?in?nd?de?ex?x

           This variable is the SNMP ifIndex for the interface which per

           definition always is an integer.  (There's no HTML escaped variant

           available)

       $?$i?if?f_?_i?in?nd?de?ex?x

           Equivalent with $?$i?if?fi?in?nd?de?ex?x.

       $?$i?if?f_?_e?et?th?h

           Contains the ethernet address of the interface, if any.  (There's

           no HTML escaped variant available)

       $?$i?if?f_?_s?sp?pe?ee?ed?d

           This variable is the speed in bytes/second (with prefixes).

           (There's no HTML escaped variant available)

       $?$i?if?f_?_s?sp?pe?ee?ed?d_?_s?st?tr?r

           This variable is a cooked speed description which is either in bits

           or bytes depending on wether or not the bits option is active and

           also with the proper prefix for the speed (k, M, G etc).  (No HTML

           escaped variant available)

       $?$i?if?f_?_t?ty?yp?pe?e_?_d?de?es?sc?c

           This variable is a textual description of the interface type.

           (HTML escaped variant: $?$h?ht?tm?ml?l_?_i?if?f_?_t?ty?yp?pe?e_?_d?de?es?sc?c)

       $?$i?if?f_?_t?ty?yp?pe?e_?_n?nu?um?m

           This variable the integer value corresponding to the interface type

           (for a listing for the value for the more common interface types,

           see the section DETAILS ON FILTERS above).  (No HTML escaped

           variant available)

       $?$i?if?f_?_d?dn?ns?s_?_n?na?am?me?e

           This is the DNS name for the interface.  (No HTML escaped variant

           available)

       _?I_?n_?t_?e_?r_?f_?a_?c_?e _?N_?a_?m_?e_?, _?D_?e_?s_?c_?r_?i_?p_?t_?i_?o_?n _?a_?n_?d _?A_?l_?i_?a_?s _?V_?a_?r_?i_?a_?b_?l_?e_?s

       It might seem confusing with both _?N_?a_?m_?e, _?D_?e_?s_?c_?r_?i_?p_?t_?i_?o_?n and _?A_?l_?i_?a_?s in this

       context and to some extent it is.  _?N_?a_?m_?e and _?D_?e_?s_?c_?r_?i_?p_?t_?i_?o_?n are usually

       supported on most equipment but how they are used varies, both between

       manufacturers as well as between different cathegories of equipment

       from the same manufacturer.  The _?A_?l_?i_?a_?s is at least supported by Cisco

       IOS, and that variable contains whatever is used in the IOS statement

       called "description" for the interface (not to be confused with the

       SNMP variables for _?D_?e_?s_?c_?r_?i_?p_?t_?i_?o_?n).