Cheshire Cat Computing

I discovered my gigabit Ethernet interfaces were capping out at 100mb with MRTG (routers2 and rrdtool) because I wasn't using 64 bit counters. When I add :::::2 at the end of the target line of the cfg files for my Windows hosts, I get an error stating something to the effect the the returned data was incorrect (returned eval data?). I'm assuming it doesn't understand what the :::::2 means or the target is incorrect for SNMPv2.

I used the windows host template file found on this forum if that makes a difference. From what I understand, Windows uses SNMPv2 so this should be comparable. Is the SNMPv2 target different than whats in the windows host template file? If so, what is it so I can properly monitor my gigabit interfaces.

Thank you!!!

Also, when I create a new .cfg file with cfgmaker and use the --snmp-options=:::::2, the network interfaces are commented out. This is against a Windows Server 2003 host.

The ':::::2' tells MRTG to use the 64bit SNMPv2 highspeed counters instead of the old 16bit ones which wrap at about 120Mbps (this is actually an MRTG issue i nhow it detects counter wrap).

Run the cfgmaker with the --snmp-options=:::::2 and see what it produces; there's apossibility that Windows' support of SNMPv2 is a bit patchy. If the interface is commented out in the produced cfg file, then the comments should indicate WHY it was commented out (disabled, speed of zero, no unique identifier, etc)

If the interfaces are valid, then you may be able to simply uncomment the lines in the generated file.

_________________
Steve Shipway
UNIX Systems, ITSS, University of Auckland, NZ
Woe unto them that rise up early in the morning... -- Isaiah 5:11

I did an snmpwalk specifying smnpv2c and the WIndows box responded so it seems snmpv2 is working in that respect. The output said SNMP v2 at the top of the results. The reason the interface is commented out per the cfg is because "* has a speed which does not make sense" and the speed is set to 0. This is the same interface that I've been monitoring for some time now without specifying :::::2.

I'm at a complete loss here. It works fine against my switches with :::::2 at the ned of the target line.

Okay, I took what cfgmaker created, uncommented out all the lines, filled in the proper max speed and am now monitoring! Time will tell if it graphs above 100mbps but I no longer get the errors when running mrtg against that cfg file.

The difference I see in the configuration cfg maker made and what the template made is one line. That line is:

noHC[target]: yes

This line doesn't exist in the file the template made for the interface and :::::2 wouldn't work. Everything else is the same. Any ideas what that line means and why its needed for SNMPv2 to work against a windows interface?

The noHC[] directive tells MRTG to NOT use the highspeed counters; I think this is not what you want.

It seems that Windows SNMPv2 is not giving the interface speeds correctly, which is why cfgmaker is commenting them out.

Can you remove the noHC[] and add the :::::2 to the end of the Target definition, if you have manually added in the correct MaxBytes value?

_________________
Steve Shipway
UNIX Systems, ITSS, University of Auckland, NZ
Woe unto them that rise up early in the morning... -- Isaiah 5:11

Since I can't seem to get this Windows server to respond to SNMPv2, I decided to take the switch ports that the server is connected to and place the " - " in front of the target definition to switch the In and the Out and rename the description to look like the servers interface. This will at least get me close to what I need, and that's to see 1GB bandwidth for the Windows server.

It's not exact, but a good work around IMO. Thank you again for all your help! I hope this helps someone else in the future.

Cheers

When you have the noHC[]:yes option, it forces MRTG to use the old 16bit counters (albeing via SNMPv2) so you'll get the same problems.

It seems the issue is with Windows' implementation of the HC information in SNMPv2. Your workaround (using the graphs from the connected switch ports) is a good solution, and is in fact what we do here (we dont use SNMP on our windows servers at all, we use nsclient with mrtg-pnsclient.pl)

_________________
Steve Shipway
UNIX Systems, ITSS, University of Auckland, NZ
Woe unto them that rise up early in the morning... -- Isaiah 5:11