CFGMAKER(1)
🎀 cfgmaker 🎀
mrtg manual page, section 1 — and yeah bestie, this is a long one, buckle up 🦋
🌸 NAME 🌸
cfgmaker — creates mrtg.cfg files (for mrtg-2.17.10) 💅
✨ SYNOPSIS ✨
cfgmaker [options] [community@]router [[options] [community@]router ...]👑 OPTIONS 👑
okay so here's the full option menu, no skips, no cuts:
--ifref=name— interface references by Interface Name (default)--ifref=ip— … by Ip Address--ifref=eth— … by Ethernet Number--ifref=descr— … by Interface Description--ifref=nr— … by Interface Number--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 filterfto decide whether or not to include that interface into the collection. Currentlyfis 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 configuration file.
(Experimental, under development, might change) 🚧
--global "x: a"— add global config entries--nodefaultglobal— do not include default global settings--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 viaifSpeed/ifHighSpeed.100Mbps = 100000000--subdirs=format— give each router its own subdirectory, naming each per "format", in whichHOSTNAMEandSNMPNAMEwill be replaced by the values of those items — for instance,--subdirs=HOSTNAMEor--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--nointerfacesappearing earlier on the command line.--help— brief help message--man— full documentation--version— print the version ofcfgmaker--output=file— output filename default isSTDOUT
💖 DESCRIPTION 💖
Cfgmaker creates MRTG configuration files based on information pulled from a router or another SNMP manageable device. periodt ✨
🌈 [community@]router 🌈
Community is the community name of the device you want to create a configuration for. If not specified, it defaults to 'public'; 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. 😭
Router is the DNS name or the IP number of an SNMP-manageable device. Following the name you can specify 6 further options separated by colons. The full syntax looks like this:
router[:[prt][:[tmout][:[retr][:[backoff][:vers]]]]]Of special interest may be the last parameter, vers. 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 generated 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. 🫶
⚙️ Configuration ⚙️
Except for the --output and --global 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 --output and --global for how their behaviour is affected by where or how many times they appear on the command line.
See the Examples below on how to set an option differently for multiple routers.
--help— Print a brief help message and exit.--man— Prints the manual page and exits.--version— Print the version ofcfgmaker. This should match the version of MRTG for which config files are being created.
--ifref nr|ip|eth|descr|name — Select the interface identification method. Default is nr 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 their 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 addresses can be problematic as some routers have the same ethernet address on most of their interface cards.
Select ip to identify the interface by its IP number. Use eth to use the ethernet address for identification. Use descr to use the Interface description. Or use name 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,nameIf your chosen method does not allow unique interface identification on the device you are querying, cfgmaker will tell you about it. 🫡
--ifdesc nr|ip|eth|descr|name|type|alias — 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 nr 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 ip if you want to use the interface's IP-address. Use eth if you want to use the interface's ethernet address. If you want a better description, you can use either descr, name or alias. 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 name might result in "S0" being the interface description , descr might result in "Serial0" and alias 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 type.
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.
--if-filter 'filter-expression' — 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 filter-expression 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.
(still lowkey on the filter flags from up there, btw) Wanna know how those filters actually do their thing? There's a whole "Details on Filters" section further down — go read it, it's right there. ✨
--if-templatetemplate-file — okay first thing's first: this one is under some development and is experimental 🙈
Use it when you want to control what the line for each target looks like in the config file. The contents of template-file get evaluated as a Perl program that generates the lines, using certain variables for input and output.
For more on how these templates work, see "Details on Templates" below.
--host-templatetemplate-file — also under some development and experimental, bestie 🧪
Use this when you want some extra targets related to the host itself — think CPU utilization, ping response time to the host, number of busy modems, that whole vibe. The contents of template-file get evaluated once per host as a Perl program that generates the lines using certain variables for input and output.
And again, for the full breakdown on these templates, see "Details on Templates" below.
--communitycommunity-string — sets the community for the routers following on the command line to community-string. Individual routers can totally override this by using the syntaxcommunity@router. 💅--enable-ipv6— this turns on IPv6 support ✨ It needs the appropriate perl modules, and if they're not found, then IPv6 gets disabled (check the ipv6 documentation for that).
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. No cap, that's not optional.
For example:
cfgmaker --enable-ipv6 [2001:760:4::1]:165:::2If 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 super useful for targets which don't support SNMP over IPv6.
--use-16bit— forces the use of 16bit SNMP request IDs. Some broken SNMP agents just will not accept 32bit request IDs. Try to avoid this option as much as possible, and complain to your agent vendor instead. 😤 Like, fr fr, make it their problem.--snmp-options:[port][:[timeout][:[retries][:[backoff][:version]]]] — use this to set the default SNMP options for all routers following on the command line. Individual values might be omitted, and so might trailing colons. Note that routers might override individual (or all) values specified by--snmp-optionsby using the syntax:
router[:[port][:[timeout][:[retries][:[backoff][:version]]]]]--global"bla: abc" — use this to add global options to the generated config file. You can call--globalseveral 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 --global after the last router on the command line will create a line in the configuration file which will appear after all the routers. 👑
--noreversedns— do not try to reverse lookup IP numbers ... a must for DNS free environments. 🚫--no-down— normallycfgmakerwill not include interfaces which are marked anything but administratively and operationally UP. With this switch you get them all. 🙈--show-op-down— include interfaces which are operatively down.--zero-speedspeed — assign this speed, in bits-per-second, to all interfaces which return 0 forifSpeedandifHighSpeed. 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.--subdirsformat — gives each router its own subdirectory for the HTML and graphics (or.rrd) files. The directory name is the given format string with a couple of pattern replacements. The string"HOSTNAME"gets replaced by the hostname of the router (however you specified it on thecfgmakercommandline — it may be an actual hostname or just an IP address), and"SNMPNAME"gets 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.18would result in the generation of lines looking something like:
Directory[10.10.0.18_1]: 10.10.0.18__fp2200-bothrip-1.3--outputfile — write the output fromcfgmakerinto the file. The default is to use"STDOUT".--outputis expected to appear only once on the command line. If used multiple times, the file specified by the last--outputwill be used.--nointerfaces— 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. That speeds up the execution of cfgmaker, and it will neither run any interface templates. 🏃♀️💨
--interfaces— this makescfgmakergenerate configuration lines for interfaces (the default behaviour).
The main usage of this option is to negate an --nointerfaces appearing earlier on the command line. ✨
🌈 SNMP V3 Options 🌈
Cfgmaker supports SNMP V3 using the Net:SNMP perl module. There are optional parameters affecting SNMP operation.
--enablesnmpv3{yes|no} — the--enablesnmpv3option is an optional flag to check for the presence of theNet::SNMPlibraries.Cfgmakerwill try to determine whether this flag is required and will set the values automatically. 🫶
🦋 SNMPv3 Arguments 🦋
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 --contextengineid and --contextname argument to configure these fields. iykyk 💅
Context Engine ID — the --contextengineid argument expects a hexadecimal string representing the desired contextEngineID. The string must be 10 to 64 characters (that's 5 to 32 octets, bestie) long, and can be prefixed with an optional "0x". Once the --contextengineid is specified, it stays with the object until it's 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 --contextname argument. The contextName stays with the object until it's changed. The contextName defaults to an empty string, which represents the "default" context.
👑 User-based Security Model Arguments 👑
The User-based Security Model (USM) used by SNMPv3 requires that a securityName be specified using the --username argument. The creation of a Net::SNMP object with the version set to SNMPv3 will fail if the --username argument is not present. The --username 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 --authkey or --authpassword arguments are specified, the securityLevel becomes 'authNoPriv'. The --authpassword argument expects a string which is at least 1 octet in length. Optionally, the --authkey argument can be used so that a plain text password does not have to be specified in a script. The --authkey 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 --authprotocol argument. This argument expects either the string 'md5' or 'sha' to be passed to modify the hash algorithm.
By specifying the arguments --privkey or --privpassword, 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 --authkey or --authpassword arguments are missing, the creation of the object fails. The --privkey and --privpassword arguments expect the same input as the --authkey and --authpassword 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 --privprotocol 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 --privprotocol 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 -privprotocol argument. 🔐✨
🎀 Details on Filters 🎀
Okay so bestie, the whole point of filters is this: they decide which interfaces get to stay and which ones get yeeted. For every single interface, cfgmaker takes your filter expression, runs it as a piece of Perl code, and peeks at what comes back. True means accept, false means reject. That's the whole vibe check.
Now, when you're out here writing filters, pls remember that Perl has its own opinions about truth and lies. The empty string "" and the string "0" are false. Literally every other string is true. Which also means any integer value of 0 is false, and any undef value is false too. And — plot twist — all references are considered true.
Since your filter gets evaluated as a Perl expression, there's some genuinely useful Perl stuff worth knowing about:
You can group expressions with parentheses "()". And you can smoosh expressions together with boolean operators, like these:
"and"(same thing as"&&") — boolean "and" of the two expressions. Only true if both expressions are true. Example:expression1 and expression2"or"(same thing as"||") — boolean "or" of the two expressions. True if either one or both of them are true. Example:expression1 or expression2"not"(same thing as"!") — boolean negation of a single expression. Example:not expression. And another one, just because:!expression
(If you want the deep lore on all this, honestly, go read a book on Perl. 💅)
✨ Predefined Filter Variables ✨
To make your life easier, there's a whole stack of predefined values you can just... use in your filter. And heads up — these variables are also available when template interfaces get evaluated. But not host templates. iykyk.
Caveat, and this one matters: every single one of these variable names starts with a dollar sign ($), because that's a syntactic requirement for scalar variables in Perl. The danger? In a lot of shells, the dollar sign is an active character — usually for shell variables, which is exactly the same way Perl uses them. So it is super important to make sure your Perl expression doesn't get evaluated by the command line shell as shell code before it even reaches cfgmaker as a command line argument. In shells like Bourne shell, ksh shell or bash shell, wrapping the entire expression in single quotes saves you from that accidental evaluation:
'--if-filter=($default_iftype && $if_admin)'$if_type— 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 bunch of predefined variables below. Normally, cfgmaker puts the target's iftype value into the target's PageTop, inside parentheses, right after the name of the interface type. Like"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 Asymmetric Digital Subscriber Loop (ADSL)
117 Gigabit Ethernet
134 ATM Sub Interface$default— true if and only if cfgmaker would normally accept the interface, based on the interface's administrative and operational state (taking the flags--no-downand--show-op-downinto account) and its type (plus a few other things).$default_ifstate— true if and only if cfgmaker would have accepted the interface based on its operational and administrative states (again taking the presence of the flags--no-downand--show-op-downinto account).$default_iftype— true if and only if cfgmaker would have accepted the interface based on its type (and a few type-specific details on top of that).$if_admin— true if and only if the interface is in an administrative up state.$if_oper— true if and only if the interface is in an operational up state.
There's also a bunch of variables predefined so you can easily tell whether an interface belongs to a certain category or not. Here's all of them, together with which if_type numbers each variable is true for. Note that some of these variables refer to other variables too. 👑
$if_is_ethernet— true for ethernet interfaces (nr 6, 7, 26, 62, 69 and 117).$if_is_isdn— true for various ISDN interface types (nr 20, 21, 63, 75, 76 and 77)$if_is_dialup— true for dial-up interfaces such as PPP as well as ISDN. (nr 23, 81, 82 and 108 in addition to the numbers of$if_is_isdn).$if_is_atm— true for miscellaneous ATM related interface types (nr 37, 49, 107, 105, 106, 114 and 134).$if_is_wan— true for WAN interfaces point to point, Frame Relay and High Speed Serial ( 22,32,44,46)$if_is_lan— true for LAN interfaces (8, 9, 11, 15, 26, 55, 59, 60 and 115 in addition to the numbers of$if_is_ethernet).$if_is_dsl— true for ADSL, RDSL, HDSL and SDSL (nr 94, 95, 96, 97)$if_is_loopback— true for software loopback interfaces (nr 24)$if_is_ciscovlan— true for Cisco VLAN interfaces (interfaces with the word Vlan or VLAN in their ifdescs)$if_vlan_id— returns the vlan id associated with a specific port on Cisco Catalyst switches under both Catalyst OS and IOS, and 3Com switches. If it's not a vlan interface, it will returnundef.$if_cisco_trunk— 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,undefotherwise.$if_MTU— returns the Maximum Transfer Unit associated with a specific port.
On top of all that, you can also use the variables defined for templates below. And further, all the variables available in cfgmaker are at the script's disposal, even if using features like that is discouraged. More "shortcuts" in the form of variables and functions will be made available in the future instead. 🔮
💖 Examples on Filters 💖
This first filter won't change which interfaces get included or excluded at all — cfgmaker will just behave normally:
'--if-filter=$default'This next one makes cfgmaker exclude PPP (23) interfaces:
'--if-filter=$default && $if_type!=23'And this one makes cfgmaker behave as usual, except it'll consider the operational state of an interface irrelevant — while still rejecting every interface that's administratively down:
'--if-filter=$if_admin && $default_iftype'🌸 Details on Templates 🌸
The contents of template files get evaluated as a Perl program. There are a number of Perl variables available for the program to read, and others that are there to be written to. 🦋
Since quite a few of the predefined variables have values that are meant to be used in HTML code, some of them have an "HTML-escaped" variant. Like $html_syslocation is the HTML escaped variant of $syslocation. What does HTML escaping mean, exactly? It means the chars "<", ">" and "&" get replaced by "<", ">" and "&", and it means newlines embedded in the string get "<BR>" prepended to them and a space character appended to them (unless a newline is the last thing in the string, in which case it's left alone).
🌈 Writable Template Variables 🌈
These are the variables you've got for storing the configuration lines in. Some of them get initialized before the template is evaluated — but that content is normally comments meant for the final configuration file, so you can totally reset those variables to the empty string inside your template code to get rid of the comments. The reverse is possible too: you can extend the contents of these variables with further info for various reasons, like debugging and such.
Once the template has been evaluated, here's what goes down: if the template is an interface template and the actual interface gets rejected for some reason (so it needs to be commented out), then all the lines in the variable $target_lines get turned into comments by adding a hash mark ("#") at the beginning of each one. After that, all the variables $head_lines, $problem_lines , $target_lines and $separator_lines get concatenated together to form the lines that get added to the configuration file. 💅
$target_lines— this variable is the placeholder for the configuration lines created by the template.$target_linesis predefined to be empty when the template code is evaluated.$head_lines— this variable is meant to be the placeholder for the comment line that appears just before the target in the configuration file. It's initialized with that comment line before the template code is evaluated, and if your template doesn't modify$head_linesduring evaluation, the comment will look like usual in the config file.$problem_lines— this variable is meant to be the placeholder for the comment lines describing any problems that 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,$problem_linesis predefined with the error description comments that cfgmaker would normally use for rejected interfaces — or as the empty string for accepted interfaces.
You can test against$problem_linesto find out if an interface will be included or rejected, but that is not recommended. Test against$if_okinstead.
$separator_lines— this variable is the placeholder for the string to use as the separator between the code for individual targets. The contents of this variable get put after each target (so the lines will show up after the end of the last target in the config as well).
🧚 Predefined Template Variables 🧚
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.
⭐ Host and System Variables ⭐
$router_name— this is the fully qualified name for the router. It's affected by the following items on the command line: the router name itself and--dns-domain.$router_connect— ok so this is the reference string for the router being polled 💖. It's on the formcommunity@routerpossibly followed by some snmp options. It's affected by the following items on the command line: the router name itself,--community,--snmp-optionsand--dns-domain. (There's no HTML escaped variant available)$directory_name— bestie this should contain the directory name ascfgmakernormally would use as the value for the"Directory[]"directive. The value is determined by the--subdirscommand line option. If--subdirsisn't specified$directory_namewill be the empty string. (There's no HTML escaped variant available)$syscontact— this is the router's SNMPsysContactvalue 🫶. (HTML escaped variant:$html_syscontact)$sysname— this is the router's SNMPsysNamevalue ✨. (No HTML escaped variant available)$syslocation— this is the router's SNMPsysLocationvalue 🎀. (HTML escaped variant:$html_syslocation)$sysdescr— this is the router's SNMPsysDescrvalue 🌸. It's normally not used bycfgmakerbut might be useful in a template. (HTML escaped variant:$html_sysdescr)
💫 Interface Target Related Variables 💫
$target_name— this is whatcfgmakernormally would use as the name of the target 💅. The target name is what's found within the square brackets,"[]", for target directives. (There's no HTML escaped variant available)$if_ref— this is the reference string for the interface 🦋. It's expected to be used in the"Target[xyz]"directive to distinguish what interface to use. The value of this variable is affected by the--ifrefcommand line option. It's normally used together with$router_connect. (There's no HTML escaped variant available)$if_ok— true if the interface is going to be included into the configuration file, otherwise false 🔥. Don't test against other variables such as$problem_linesto find out if an interface will be rejected or not, use this$if_okinstead, fr fr.$default_target_lines— this variable contains all the target lines whichcfgmakerby 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.
$default_target_directive— this variable contains the default string for theTarget[]directive line.$default_setenv_directive— this variable contains the default string for theSetEnv[]directive line.$default_directory_directive— this variable contains the default string for theDirectory[]directive line which means it's an empty string (with no newline) if there's no directory.$default_maxbytes_directive— this variable contains the default string for theMaxBytes[]directive line.$default_title_directive— this variable contains the default string for theTitle[]directive line.$default_pagetop_directive— this variable contains the default string for thePageTop[]directive lines.
🎀 Interface Network Configuration Variables 🎀
$if_ip— this variable should contain the IP-address of the interface, if any has been assigned to it 🫶. (There's no HTML escaped variant available)$ifindex— this variable is the SNMPifIndexfor the interface which per definition always is an integer 💜. (There's no HTML escaped variant available)$if_index— equivalent with$ifindex.$if_eth— contains the ethernet address of the interface, if any. (There's no HTML escaped variant available)$if_speed— this variable is the speed in bytes/second (with prefixes). (There's no HTML escaped variant available)$if_speed_str— this variable is a cooked speed description which is either in bits or bytes depending on whether or not the bits option is active and also with the proper prefix for the speed (k,M,Getc). (No HTML escaped variant available)$if_type_desc— this variable is a textual description of the interface type. (HTML escaped variant:$html_if_type_desc)$if_type_num— this variable is 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)$if_dns_name— this is the DNS name for the interface. (No HTML escaped variant available)
🌈 Interface Name, Description and Alias Variables 🌈
It might seem confusing with both Name, Description and Alias in this context and to some extent it is 😭. Name and Description are usually supported on most equipment but how they are used varies, both between manufacturers as well as between different categories of equipment from the same manufacturer. The Alias 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 Description).
For better control from the command line consider $if_title_desc which contents are controlled by the --if-descr command line option.
$if_snmp_descr— this variable should contain the"raw"description of the interface as determined by the SNMP polling of the router 💖. (HTML escaped variant:$html_if_snmp_descr)$if_snmp_name— the"raw"name for the interface as provided by SNMP polling. (HTML escaped variant:$html_if_snmp_name)$if_snmp_alias— the"raw"ifAliasfor the interface as provided by SNMP polling. (HTML escaped variant:$html_if_snmp_alias)$if_cisco_descr— the"raw"CiscolocIfDescrfor the interface as provided by SNMP polling. (HTML escaped variant:$html_if_cisco_descr)$if_description— this is the"cooked"description string for the interface, taking into account the SNMP values found for the interface'sRDescr,ifAliasandCiscolocIfDescr🦋. (HTML escaped variant:$html_if_description)$if_title— the full stringcfgmakerby default would have used for theTitle[]directive in the configuration as well as the content of the topmostH1tag in thePageTop[]. Is composed by the contents of$desc_prefix,$if_title_descand$sysname.
As $if_title depends on $if_title_desc, it's possible to indirectly control $if_title by using the command line option --if-descr.
(HTML escaped variant: $html_if_title)
$if_port_name— if the host is a Cisco Catalyst LAN switch, this variable is the name of that port 💅. (No HTML escaped variant available)$if_pp_port_name— if the host is a Nortel Passport LAN switch, this variable is the name of that port ✨. (No HTML escaped variant available)$desc_prefix— this variable is a prefix of the description of what the target is to use in the"Title[]"directive and in theH1section of the"PageTop[]". Default is"Traffic analysis for ". (HTML escaped variant:$html_desc_prefix)$if_title_desc— this is the description of the interface normally used bycfgmakeras part of the variable$if_title💖. The latter is used as the full string in the"Title[]"directive and theH1section in thePageTop[].
$if_title_desc is controlled by the command line option --if-descr which indirectly controls the contents of $if_title.
(HTML escaped variant: $html_if_title_desc)
🧚 Help Functions for Templates 🧚
The following functions exists to facilitate the writing of host and interface templates 👑.
html_escape(string)—html_escape()takes a string as an argument and returns a new string where the following substitutions has been done: the chars"<",">"and"&"are replaced by"<",">"and"&"and that newlines embedded in the string are prepended with"<BR>"and appended with a space character (newlines at the end of the string are not touched).oid_pick($router_connect,$v3opt,"oid1","oid2"...)— this function will try to poll each of the oids specified until it is successful or has run out of oids 🔥. It will return the name of the first oid that worked or undef if it is not successful.
🌸 Example Template Files 🌸
Template Example 1: Eliminating Rejected Targets From Appearing
This template file generates exactly the same configuration code per interface as cfgmaker does by default, with the exception that it eliminates all lines (comments as well as config code) for an interface if the interface happens to be rejected 💀.
if(not $problem_lines)
{
$target_lines .= <<ECHO;
Target[$target_name]: $if_ref:$router_connect
SetEnv[$target_name]: MRTG_INT_IP="$if_ip" MRTG_INT_DESCR="$if_snmp_descr"
ECHO
if ($directory_name) {
$target_lines .= "Directory[$target_name]: $directory_name\n";
} $target_lines .= <<ECHO;
MaxBytes[$target_name]: $if_speed
Title[$target_name]: $html_desc_prefix$html_if_title_desc -- $sysname
PageTop[$target_name]: <h1>$html_desc_prefix$html_if_title_desc -- $sysname</h1>
<div id="sysdetails">
<table>
<tr>
<td>System:</td>
<td>$sysname in $html_syslocation</td>
</tr>
<tr>
<td>Maintainer:</td>
<td>$html_syscontact</td>
</tr>
<tr>
<td>Description:</td>
<td>$html_if_description</td>
</tr>
<tr>
<td>ifType:</td>
<td>$html_if_type_desc ($if_type_num)</td>
</tr>
<tr>
<td>ifName:</td>
<td>$html_if_snmp_name</td>
</tr>
ECHO
$target_lines .= <<ECHO if defined $if_port_name;
<tr>
<td>Port Name:</td>
<td>$if_port_name</td>
</tr>
ECHO
$target_lines .= <<ECHO if defined $if_pp_port_name;
<tr>
<td>Port Name:</td>
<td>$if_pp_port_name</td>
</tr>
ECHO
$target_lines .= <<ECHO;
<tr>
<td>Max Speed:</td>
<td>$if_speed_str</td>
</tr>
ECHO
$target_lines .= <<ECHO if $if_ip;
<tr>
<td>Ip:</td>
<td>$if_ip ($if_dns_name)</td>
</tr>
ECHO
$target_lines .= <<ECHO;
</table>
</div>
ECHO
} else {
$head_lines="";
$problem_lines="";
$target_lines="";
$separator_lines="";
}🌸 Template Example 2: Simpler Version of Example 1
Okay so real talk, Example 1 was doing double duty: part "look how you can customize interface target generation" 💅 and part "here's a lil peek at how the variables get used inside the "default" template" — which, lowkey, is the template that cfgmaker normally reaches for.
But bestie, if all you want is the easiest possible way to make those reject interfaces fully vanish, the template below does the whole job too, just by using $default_target_lines. No cap. ✨
if($if_ok) {
$target_lines = $default_target_lines;
} else {
$head_lines="";
$problem_lines="";
$target_lines="";
$separator_lines="";
}👑 Template Example 3: Creating CPU Targets for Hosts
And now for something completely different — a host template, bestie. It's giving main character energy, it's giving CPU stats, it's giving slay. 🎀
$head_lines .= <<ECHO;
#---------------------------------------------------------------------
ECHO
my $target_name = $router_name . ".cpu";
$target_lines .= <<ECHO;
YLegend[$target_name]: Percentage CPU load
ShortLegend[$target_name]: %
Legend1[$target_name]: CPU load in %
Legend2[$target_name]:
Legend3[$target_name]: Max Observed CPU load
Legend4[$target_name]:
LegendI[$target_name]: CPU Load:
LegendO[$target_name]:
WithPeak[$target_name]: ywm
MaxBytes[$target_name]: 100
Options[$target_name]: growright, gauge, nopercent
Title[$target_name]: $router_name CPU load
Target[$target_name]: 1.3.6.1.4.1.9.2.1.58.0&1.3.6.1.4.1.9.2.1.58.0:$router_connect
PageTop[$target_name]: <h1>$router_name CPU load</h1>
<div>
<table>
<tr>
<td>System:</td>
<td>$router_name in $html_syslocation</td>
</tr>
<tr>
<td>Maintainer:</td>
<td>$html_syscontact</td>
</tr>
<tr>
<td>Description:</td>
<td>$html_sysdescr</td>
</tr>
<tr>
<td>Resource:</td>
<td>CPU.</td>
</tr>
</table>
</div>
ECHO🌈 EXAMPLES
Real examples time!! Grab a snack. 🍓
💖 Example 1 — the classic
This first one builds a config file for router.place.xyz, and that router has the community name public. Interfaces get ID'd by their IP number. Two global options get dropped into the config file. And the whole config file gets redirected into mrtg.conf.
⭐ Important bestie note: those \ signs at the end of the lines mean the command is meant to be written on a single line. It's just wrapped for your eyeballs.
cfgmaker --global "WorkDir: /home/tobi" \
--global "Options[_]: growright,bits" \
--ifref=ip \
public@router.place.xyz > mrtg.cfgNote: if cfgmaker isn't in your path, but you're chillin' in the directory where cfgmaker lives, you can just start it with ./cfgmaker. 🫶
💖 Example 2 — the four-device situation
Next up: one config file for four devices — router1.place.xyz, router2.place.xyz, switch1.place.xyz and switch2.place.xyz — all of them rocking the community public.
The two routers get --ifref set to descr, while the two switches use --ifref set to name. Then, extra detail: the routers use --ifdesc set to alias, and switch1.place.xyz uses --ifdesc set to descr while switch2.place.xyz uses name instead. So many little switches, so little time. 💅
And finally, two Options lines get inserted into the configuration: one right at the beginning, and the other dropped in after the lines for the two routers but before the lines for the switches. Order matters, bestie. ✨
cfgmaker --global "WorkDir: /home/tobi" \
--global "Options[_]: growright,bits" \
--ifref=descr \
--ifdesc=alias \
public@router1.place.xyz \
public@router2.place.xyz \
--global "Options[_]: growright" \
--ifref=name \
--ifdesc=descr \
public@switch1.place.xyz \
--ifdesc=name \
public@switch2.place.xyz > mrtg.cfg💖 Example 3 — the command-line glow-up
This one's a lil demo of how to use --community, --snmp-options and --dns-domain to make the command line so much simpler. 😭
- All the equipment uses the community
hidden— except theppp-server, which uses communityaccess. - All equipment uses these SNMP options:
1stimeout,1retry and SNMP version2(backoff and port are unspecified, which means they just use the default values, no thoughts head empty 🌸). - The exception again is the
ppp-server, which uses SNMP version1. - Finally, all the equipment is part of the domain
place.xyz— except theppp-server, which is part of the domainremote.place.xyz. And here's the iconic bit: that last one is achieved simply by specifying the name of the ppp-server asppp-server.remote. Chef's kiss. 👑
cfgmaker --global "WorkDir: /home/tobi" \
--global "Options[_]: growright,bits" \
--dns-domain=place.xyz \
--community=hidden \
--snmp-options=::1:1::2 \
router1 \
router2 \
router3 \
router4 \
router5 \
switch1 \
switch2 \
switch3 \
switch4 \
switch5 \
switch6 \
switch7 \
access@ppp-server.remote:::::1 > mrtg.cfg🦋 SEE ALSO
mrtg-reference
🎀 AUTHOR
Tobias Oetiker <tobi@oetiker.ch> and Jakob Ilves <jakob.ilves@oracle.com> — the actual legends who built this. 🫶
⭐ LICENSE
GNU General Public License
💜 COPYRIGHT
Cfgmaker is Copyright 2000 by Tobias Oetiker <tobi@oetiker.ch>
And that's the whole page, bestie!! 🎉 You made it to the end — that's genuinely iconic behavior. This one's from version 2.17.10, dated 2022-01-19, and yeah, it's the CFGMAKER(1) page. Go make some config files, you absolute main character. 💅✨🌸
📦 where this page comes from
- alpine 3.22: mrtg-doc 2.17.10-r1 · GPL-2.0-or-later
- alpine 3.23: mrtg-doc 2.17.10-r1 · GPL-2.0-or-later
- alpine 3.24: mrtg-doc 2.17.10-r2 · GPL-2.0-or-later
- centos-stream 10: mrtg 2.17.10-13.el10 · GPL-2.0-or-later
- debian bookworm: mrtg 2.17.10-5+deb12u2 · GPL-2.0-or-later
- debian trixie: mrtg 2.17.10-13+deb13u2 · GPL-2.0-or-later
- fedora 43: mrtg 2.17.10-12.fc43 · GPL-2.0-or-later
- fedora 43: mrtg 2.17.10-13.fc43 · GPL-2.0-or-later
- fedora 44: mrtg 2.17.10-13.fc44 · GPL-2.0-or-later
- fedora 44: mrtg 2.17.10-14.fc44 · GPL-2.0-or-later
- nixos 26.05: mrtg 2.17.10
- nixpkgs unstable: mrtg 2.17.10
- ubuntu jammy: mrtg 2.17.10-3 · GPL-2.0-or-later
- ubuntu noble: mrtg 2.17.10-12 · GPL-2.0-or-later
- ubuntu questing: mrtg 2.17.10-13
- ubuntu resolute: mrtg 2.17.10-14 · GPL-2.0-or-later
- ubuntu stonking: mrtg 2.17.10-16 · GPL-2.0-or-later
- 💖 girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms