mrtg-faq.txt
上传用户:shbosideng
上传日期:2013-05-04
资源大小:1555k
文件大小:5k
源码类别:

SNMP编程

开发平台:

C/C++

  1. MRTG-FAQ(1)                    mrtg                   MRTG-FAQ(1)
  2. NNAAMMEE
  3.        mrtg-faq - How to get help if you have problems with MRTG
  4. SSYYNNOOPPSSIISS
  5.        MRTG seems to raise a lot of questions. There are a number
  6.        of resources apart from the documentation where you can
  7.        find help for mrtg.
  8. FFAAQQ
  9.        In the following sections you'll find some additonal Fre-
  10.        quently Asked Questions, with Answers.
  11.        WWhhyy iiss tthheerree nnoo ""@@##$$%%"" ((mmyy nnaattiivvee llaanngguuaaggee)) vveerrssiioonn ooff
  12.        MMRRTTGG??
  13.        Nobody has contributed a _@_#_$_%_._p_m_d file yet. Go into the
  14.        _m_r_t_g_-_2_._1_3_._2_/_t_r_a_n_s_l_a_t_e directory and create your own trans-
  15.        lation file.  When you are happy with it send it to me for
  16.        inclusion with the next mrtg release.
  17.        II nneeeedd aa ssccrriipptt ttoo mmaakkee mmrrttgg wwoorrkk wwiitthh mmyy xxyyzz ddeevviiccee..
  18.        Probably this has already been done. Check the stuff in
  19.        the _m_r_t_g_-_2_._1_3_._2_/_c_o_n_t_r_i_b directory. There is a file called
  20.        _0_0_I_N_D_E_X in that directory which tells what you can find in
  21.        there.
  22.        HHooww ddooeess tthhiiss SSNNMMPP tthhiinngg wwoorrkk
  23.        There are many resources on the net that explain SNMP.
  24.        Take a look at this article from the Linux Journal by
  25.        David Guerrero
  26.         http://www.david-guerrero.com/papers/snmp/
  27.        And at this rather long document from CISCO.
  28.         http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/snmp.htm
  29.        TThhee iimmaaggeess ccrreeaatteedd bbyy MMRRTTGG llooookk vveerryy ssttrraannggee..
  30.        Remove the *-{week,day,month,year}.png files and start
  31.        MRTG again.  Using MRTG for the first time, you might have
  32.        to do this twice. This will also help when you introduce
  33.        new routers into the cfg file.
  34.        WWhhaatt iiss mmyy CCoommmmuunniittyy NNaammee??
  35.        Ask the person in charge of your Router or try 'public',
  36.        as this is the default Community Name.
  37.        MMyy ggrraapphhss sshhooww aa ffllaatt lliinnee dduurriinngg aann oouuttaaggee.. WWhhyy ??
  38.        Well, the short answer is that when an SNMP query goes out
  39.        and a response doesn't come back, MRTG has to assume some-
  40.        thing to put in the graph, and by default it assumes that
  41.        the last answer we got back is probably closer to the
  42.        truth than zero.  This assumption is not perfect (as you
  43.        have noticed).  It's a trade-off that happens to fail dur-
  44.        ing a total outage.
  45.        If this is an unacceptable trade-off, use the uunnkknnaasszzeerroo
  46.        option.
  47.        You may want to know what you're trading off, so in the
  48.        spirit of trade-offs, here's the long answer:
  49.        The problem is that MRTG doesn't know *why* the data
  50.        didn't come back, all it knows is that it didn't come
  51.        back.  It has to do something, and it assumes it's a stray
  52.        lost packet rather than an outage.
  53.        Why don't we always assume the circuit is down and use
  54.        zero, which will (we think) be more nearly right?  Well,
  55.        it turns out that you may be taking advantage of MRTG's
  56.        "assume last" behaviour without being aware of it.
  57.        MRTG uses SNMP (Simple Network Management Protocol) to
  58.        collect data, and SNMP uses UDP (User Datagram Protocol)
  59.        to ship packets around.  UDP is connectionless (not guar-
  60.        anteed) unlike TCP where packets are tracked and acknowl-
  61.        edged and, if needed, retransmitted.  UDP just throws
  62.        packets at the network and hopes they arrive.  Sometimes
  63.        they don't.
  64.        One likely cause of lost SNMP data is congestion; another
  65.        is busy routers.  Other possibilities include transient
  66.        telecommunications problems, router buffer overflows
  67.        (which may or may not be congestion-related), "dirty
  68.        lines" (links with high error rates), and acts of God.
  69.        These things happen all the time; we just don't notice
  70.        because many interactive services are TCP-based and the
  71.        lost packets get retransmitted automatically.
  72.        In the above cases where some SNMP packets are lost but
  73.        traffic is flowing, assuming zero is the wrong thing to do
  74.        - you end up with a graph that looks like it's missing
  75.        teeth whenever the link fills up.  MRTG interpolates the
  76.        lost data to produce a smoother graph which is more accu-
  77.        rate in cases of intermittent packet loss.  But with
  78.        V2.8.4 and above, you can use the "unknaszero" option to
  79.        produce whichever graph is best under the conditions typi-
  80.        cal for your network.
  81. AAUUTTHHOORR
  82.        Tobias Oetiker <oetiker@ee.ethz.ch>
  83. 2.13.2                      2006-02-03                MRTG-FAQ(1)