<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Bericht</TITLE>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2800.1589" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=461113212-14052007><FONT color=#0000ff
size=2>Gabor,</FONT></SPAN></DIV>
<DIV><SPAN class=461113212-14052007><FONT color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=461113212-14052007><FONT color=#0000ff size=2>When monitoring
links with speeds above 100Mbits/s you have to use the 64bit counters.
</FONT></SPAN></DIV>
<DIV><SPAN class=461113212-14052007><FONT color=#0000ff size=2>The 32bit
counters do roll over too quickly to give reliable statistics for this link
speeds.</FONT></SPAN></DIV>
<DIV><SPAN class=461113212-14052007></SPAN><SPAN class=461113212-14052007><FONT
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=461113212-14052007><FONT color=#0000ff size=2>MRTG can deal
with roll overs, but is unable to see the difference between 1, 2 or more roll
overs in a polling interval.</FONT></SPAN></DIV>
<DIV><SPAN class=461113212-14052007><FONT color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=461113212-14052007><FONT color=#0000ff size=2>To get the 64bit
counters just add :::::2 after the hostname. For details see <A
href="http://oss.oetiker.ch/mrtg/doc/mrtg-reference.en.html#item_snmpv2c">http://oss.oetiker.ch/mrtg/doc/mrtg-reference.en.html#item_snmpv2c</A></FONT></SPAN></DIV>
<DIV><SPAN class=461113212-14052007><FONT color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=461113212-14052007><FONT color=#0000ff
size=2>HTH,</FONT></SPAN></DIV>
<DIV><SPAN class=461113212-14052007><FONT color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=461113212-14052007><FONT color=#0000ff
size=2>Jan.</FONT></SPAN></DIV>
<BLOCKQUOTE style="MARGIN-RIGHT: 0px">
<DIV></DIV>
<DIV class=OutlookMessageHeader lang=nl dir=ltr align=left><FONT face=Tahoma
size=2>-----Original Message-----<BR><B>From:</B>
mrtg-bounces@lists.oetiker.ch [mailto:mrtg-bounces@lists.oetiker.ch] <B>On
Behalf Of </B>Gabor<BR><B>Sent:</B> Monday, May 14, 2007 2:22 PM<BR><B>To:</B>
mrtg@lists.oetiker.ch<BR><B>Subject:</B> [mrtg] MRTG accuracy
issue<BR><BR></FONT></DIV>
<DIV>Dear MRTG guys,</DIV>
<DIV> </DIV>
<DIV>This is my first post to this mailing list. I use MRTG to monitor
numerous things on our network. Recently an accuracy issue was brought to my
attention: MRTG shows too little traffic for Cisco Catalyst 65xx
switch gig interfaces. To test this theory, we conducted 2 tests.</DIV>
<DIV> </DIV>
<DIV>Test #1: connected a sniffer to the switch (Sniffer Pro software),
monitored all traffic through gig ports and got Sniffer Pro to draw its
own graph. FYI, the sniffer was set up on a 100 Mb port but we monitored a Gig
links with no more than 60-70 Mb traffic. We found that the MRTG graph showed
roughly 30% less traffic than the Sniffer Pro graph.</DIV>
<DIV> </DIV>
<DIV>Test #2: we cleared the counters on some gig interfaces. After a few
hours, then days, we checked the counters, noted the amount of traffic going
through, calculated the average and compared it to the MRTG graph. We came to
the same conclusion, namely that there was a roughly 30% difference.</DIV>
<DIV> </DIV>
<DIV>For now we just consider the 30% discrepency when looking at MRTG graphs
for gig ports. It seems that MRTG is accurate for slower ports.</DIV>
<DIV> </DIV>
<DIV>So, I wonder if any of you good folks have run into this problem. Is
there a special config I have to do for Gig ports or 65xx switches? I would
appreciate some thoughts, thanks in advance.</DIV>
<DIV> </DIV>
<DIV><U>This is how I create my config:</U></DIV>
<DIV># /usr/local/mrtg-2/bin/cfgmaker --global 'Htmldir:
/data2/web/mrtg/gig/hostname' --global 'Imagedir:
/data2/web/mrtg/gig/hostname' --global 'Logdir:
/data2/web/mrtg/g<BR>ig/hostname' --global 'RunAsDaemon: Yes' --global
'Interval: 5' --ifref=nr --ifdesc=ip --noreversedns --global 'Options[_]:
bits,growright' --output /data2/data/mrtg/c<BR>fgs/hostname.cfg <A
href="mailto:communitystring@hostname">communitystring@hostname</A></DIV>
<DIV> </DIV>
<DIV><U>A typical gig link:</U></DIV>
<DIV>### Interface 855 >> Descr: '' | Name: '1/1' | Ip: '' | Eth:
'00-01-64-75-cf-6d' ###</DIV>
<DIV>Target[hostname_855]:
855:communitystring@hostname:<BR>SetEnv[hostname_855]: MRTG_INT_IP=""
MRTG_INT_DESCR=""<BR>MaxBytes[hostname_855]: 125000000<BR>Title[hostname_855]:
855 -- hostname.domain.name<BR>PageTop[hostname_855]: <H1>855 --
hostname.domain.name</H1><BR> <TABLE><BR>
<TR><TD>System:</TD>
<TD>hostname.domain.name in </TD></TR><BR>
<TR><TD>Maintainer:</TD> <TD>Contact
info</TD></TR><BR>
<TR><TD>Description:</TD><TD>
</TD></TR><BR>
<TR><TD>ifType:</TD>
<TD>ethernetCsmacd (6)</TD></TR><BR>
<TR><TD>ifName:</TD>
<TD>1/1</TD></TR><BR> <TR><TD>Port
Name:</TD> <TD>Gig link to
Hostname</TD></TR><BR> <TR><TD>Max
Speed:</TD> <TD>1000.0
Mbits/s</TD></TR><BR> </TABLE></DIV>
<DIV> </DIV>
<DIV>Sincerely,</DIV>
<DIV> </DIV>
<DIV>Gabor</DIV>
<DIV> </DIV>
<P>
<HR SIZE=1>
<A
href="http://us.rd.yahoo.com/evt=48250/*http://searchmarketing.yahoo.com/arp/sponsoredsearch_v9.php?o=US2226&cmp=Yahoo&ctv=AprNI&s=Y&s2=EM&b=50">Pinpoint
customers </A>who are looking for what you sell. </BLOCKQUOTE></BODY></HTML>
<table><tr><td bgcolor=#ffffff><font color=#000000>_________________________________________________________<br>
<br>
Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het elektronisch verzenden van berichten.<br>
_________________________________________________________<br>
<br>
This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The state accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages.<br>
_________________________________________________________<br>
</font></td></tr></table>