MRTG-FAQ(1)                          mrtg                          MRTG-FAQ(1)

N?NA?AM?ME?E

       mrtg-faq - How to get help if you have problems with MRTG

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

       MRTG seems to raise a lot of questions. There are a number of resources

       apart from the documentation where you can find help for mrtg.

F?FA?AQ?Q

       In the following sections you'll find some additonal Frequently Asked

       Questions, with Answers.

   W?Wh?hy?y i?is?s t?th?he?er?re?e n?no?o "?"@?@#?#$?$%?%"?" (?(m?my?y n?na?at?ti?iv?ve?e l?la?an?ng?gu?ua?ag?ge?e)?) v?ve?er?rs?si?io?on?n o?of?f M?MR?RT?TG?G???

       Nobody has contributed a _?@_?#_?$_?%_?._?p_?m_?d file yet. Go into the

       _?m_?r_?t_?g_?-_?2_?._?1_?7_?._?7_?/_?t_?r_?a_?n_?s_?l_?a_?t_?e directory and create your own translation file.

       When you are happy with it send it to me for inclusion with the next

       mrtg release.

   I?I n?ne?ee?ed?d a?a s?sc?cr?ri?ip?pt?t t?to?o m?ma?ak?ke?e m?mr?rt?tg?g w?wo?or?rk?k w?wi?it?th?h m?my?y x?xy?yz?z d?de?ev?vi?ic?ce?e.?.

       Probably this has already been done. Check the stuff in the

       _?m_?r_?t_?g_?-_?2_?._?1_?7_?._?7_?/_?c_?o_?n_?t_?r_?i_?b directory. There is a file called _?0_?0_?I_?N_?D_?E_?X in that

       directory which tells what you can find in there.

   H?Ho?ow?w d?do?oe?es?s t?th?hi?is?s S?SN?NM?MP?P t?th?hi?in?ng?g w?wo?or?rk?k

       There are many resources on the net that explain SNMP.  Take a look at

       this article from the Linux Journal by David Guerrero

        http://www.david-guerrero.com/papers/snmp/

       And at this rather long document from CISCO.

        http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/snmp.htm

   T?Th?he?e i?im?ma?ag?ge?es?s c?cr?re?ea?at?te?ed?d b?by?y M?MR?RT?TG?G l?lo?oo?ok?k v?ve?er?ry?y s?st?tr?ra?an?ng?ge?e.?.

       Remove the *-{week,day,month,year}.png files and start MRTG again.

       Using MRTG for the first time, you might have to do this twice. This

       will also help when you introduce new routers into the cfg file.

   W?Wh?ha?at?t i?is?s m?my?y C?Co?om?mm?mu?un?ni?it?ty?y N?Na?am?me?e???

       Ask the person in charge of your Router or try 'public', as this is the

       default Community Name.

   M?My?y g?gr?ra?ap?ph?hs?s s?sh?ho?ow?w a?a f?fl?la?at?t l?li?in?ne?e d?du?ur?ri?in?ng?g a?an?n o?ou?ut?ta?ag?ge?e.?. W?Wh?hy?y ???

       Well, the short answer is that when an SNMP query goes out and a

       response doesn't come back, MRTG has to assume something to put in the

       graph, and by default it assumes that the last answer we got back is

       probably closer to the truth than zero.  This assumption is not perfect

       (as you have noticed).  It's a trade-off that happens to fail during a

       total outage.

       If this is an unacceptable trade-off, use the u?un?nk?kn?na?as?sz?ze?er?ro?o option.

       You may want to know what you're trading off, so in the spirit of

       trade-offs, here's the long answer:

       The problem is that MRTG doesn't know *why* the data didn't come back,

       all it knows is that it didn't come back.  It has to do something, and

       it assumes it's a stray lost packet rather than an outage.

       Why don't we always assume the circuit is down and use zero, which will

       (we think) be more nearly right?  Well, it turns out that you may be

       taking advantage of MRTG's "assume last" behaviour without being aware

       of it.

       MRTG uses SNMP (Simple Network Management Protocol) to collect data,

       and SNMP uses UDP (User Datagram Protocol) to ship packets around.  UDP

       is connectionless (not guaranteed) unlike TCP where packets are tracked

       and acknowledged and, if needed, retransmitted.  UDP just throws

       packets at the network and hopes they arrive.  Sometimes they don't.

       One likely cause of lost SNMP data is congestion; another is busy

       routers.  Other possibilities include transient telecommunications

       problems, router buffer overflows (which may or may not be congestion-

       related), "dirty lines" (links with high error rates), and acts of God.

       These things happen all the time; we just don't notice because many

       interactive services are TCP-based and the lost packets get

       retransmitted automatically.

       In the above cases where some SNMP packets are lost but traffic is

       flowing, assuming zero is the wrong thing to do - you end up with a

       graph that looks like it's missing teeth whenever the link fills up.

       MRTG interpolates the lost data to produce a smoother graph which is

       more accurate in cases of intermittent packet loss.  But with V2.8.4

       and above, you can use the "unknaszero" option to produce whichever

       graph is best under the conditions typical for your network.

A?AU?UT?TH?HO?OR?R

       Tobias Oetiker <tobi@oetiker.ch>

2.17.7                            2018-07-13                       MRTG-FAQ(1)