Why would you want to go through the trouble of hacking the PHP source code just to get SNMPv2c support? Two reasons.

Firstly, interfaces that support SNMPv2 have an entry called "ifAlias." This entry can contain a long, user-configurable description of the interface; thus, they're more human-readable than the shorter ifDescr entry that SNMPv1 uses. Without V2, you'll have to enter interface aliases manually, by hand, on each interface you want one on; with it, these aliases can be inserted automatically (and you can always override these auto-entries manually if desired).

Secondly, with SNMPv2 support you get 64-bit counters on machines that support them. "And that does what," you may ask? Some network links are very very fast. This means that they can exceed a 32-bit counter's maximum value (4 gigabytes) rather quickly; quicker than your collection interval, in fact. If this happens, NISCA will get confused and report utterly wrong averages on the graphs and reports. But it would take one amazingly fast link to fill up 64 bits within five minutes and make it "roll over" like this; its maximum size is 16.8 million terabytes. So if your graphs look like mountains that God whacked with a meat cleaver at regular intervals (see below), you can enable snmpv2c and fix it (see further below).

However, please note that enabling 64-bit counters on an interface will NOT fix any statistics you've already collected on that interface using the 32-bit counters! There's just no way to do that; sorry...

Note that interfaces that support SNMPv2 may or may not have working 64-bit counters on them. Some machines and interfaces may have the ifAlias entries, but not 64-bit counters. Annoying, isn't it?

Note: this is a dramatization; they aren't even from the same time period. This is roughly what you could expect to see without and with SNMPv2 on a fairly fast interface.


Without SNMPv2c


With SNMPv2c


Now do you see why?     ;-)