Ayuda - Cómo conseguir ayuda si tienes problemas con MRTG
MRTG parece plantear muchas preguntas. Hay varios recursos aparte de la documentación dónde puedes encontrar ayuda para mrtg.
Alex van den Bogaerdt <alex@ergens.op.Het.Net> mantiene la web de FAQ de MRTG FAQ en
http://faq.mrtg.org
En las secciones siguientes encontrarás algunas Preguntas de Uso Frecuente adicionales, con sus respuestas.
Todavía nadie ha contribuido con un fichero @ #$% .pmd. Entra en el directorio mrtg -2.9.18/translate y crea tu propio archivo de traducción. Cuando estás contento con él me lo envías para la inclusión en la próximo versión de mrtg.
Probablemente esto ya se ha hecho. Verifica el material en el directorio mrtg-2.9.18/contrib. Hay un archivo llamado 00INDEX en ese directorio que dice lo que puedes encontrar allí.
Hay muchos recursos sobre SNMP en la red. Da un vistazo a este artículo, en español, de David Guerrero:
http://www.david-guerrero.com/papers/snmp/lj.es.html
Y a este documento, en inglés, bastante largo de CISCO
http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/snmp.htm
Borra los ficheros * - {week,day,month,year}.png y arranca MRTG de nuevo. Cuando arrancas MRTG por primera vez, tendrás que hacer esto dos veces. Esto también ayuda cuando introduzcas nuevo dispositivos en el archivo cfg.
Pregúntale a la persona a cargo de tu Router o prueba 'public', ya que es el Nombre de Comunidad por defecto.
Bien, la respuesta corta es que cuando se realiza una consulta SNMP y no se recibe respuesta, MRTG tiene que poner algo en el gráfico, y por defecto asume que la última respuesta recibida está más cerca de la realidad que el cero. Esta suposición no es perfecta (como has notado), es un equilibrio que falla durante un paro total.
Si esto es un equilibio inaceptable, usa la opción unknaszero.
Si quieres saber más, aquí está la respuesta larga:
El problema es que MRTG no sabe *porqué* no se reciben los datos, todo lo que sabe es que no se reciben. Tiene que hacer algo, y asume es un paquete perdido en lugar de un paro.
¿Por qué no asumimos siempre que el circuito está caido, y usamos cero lo cual (pensamos) es más correcto? Bien, resulta que puedes estar tomando ventaja del comportamiento ``acepta el último'' sin estar enterado.
MRTG usa SNMP para recopilar datos, y SNMP usa UDP para enviar los paquetes. UDP es un protocolo sin conexión (no garantiza la recepción) - a diferencia de TCP el cuál rastrea los paquetes y confirma la recepción, y si es necesario, los retransmite, UDP solo los lanza a la red y espera que lleguen. Algunas veces no llegan.
Una causa probable de pérdida de datos SNMP es la congestión, otra son dispositivos ocupados. Otras posibilidades incluyen los problemas transitorios de las telecomunicaciones, los desbordamientos de buffer en dispositivos (qué pueden relacionarse, o no, con la congestión), ``líneas sucias'' (enlaces con tasas de error altas), y fuerza mayor. Estas cosas pasan todo el tiempo, sólo que nosotros no las notamos porque muchos servicios interactivos son basados en TCP y los paquetes perdidos se retransmiten automáticamente.
En los casos anteriores dónde algunos paquetes de SNMP se pierden pero el tráfico fluye, asumir cero es erróneo - terminas con un gráfico 'desdentado' siempre que el enlace se satura. MRTG interpola los datos perdidos para producir un gráfico más parejo y que es más exacto en los casos de pérdida intermitente de paquetes. Pero a partir de la V2.8.4, puedes usar la opción ``unknaszero'' para producir cualquier gráfico que se adecue mejor a las condiciones típicas de tu red.
Tobias Oetiker <oetiker@ee.ethz.ch>
Daniel Palomo <dpalomo@inicia.es