SNMP Issue w/ Packet Flow MIB/data
-
Hi All,
I did a fresh install and after I completed it the SNMP data for Packet Flows no longer works. It always returns zero. This was working before with prior versions. Not sure how far back, i was running an old 1.2.1 release build a number of months ago. The rest of the MIB def's return data for CPU and interface traffic. It is just Packet Flow and it returns 0. The MIB/Module is enabled in the SNMP page.
You can see in the attached graphs before the new version, then after the the new version (latest snapshot).
Thanks all for your hard work. It has been a great product!
-
Using pfflowd?
-
Hi sullrich,
Thanks for the response. I'm not sure what you mean by pfflowd. All I had done before was tick the options to enable the MIB extensions in the SNMP configuration page and it had worked.
-
Seems that he's using cacti to graph packet filter stats: http://forums.cacti.net/viewtopic.php?t=19429&highlight=pfsense
This works fine on my old "1.2.1-RC1 built on Fri Aug 15 20:43:59 EDT 2008" snapshot, but it seems broken now(not confirmed this myself, the above snapshot is the latest i run in "production").
-
ridnhard19:
Could you run a: snmpwalk -v 2c -c public <ipcactidevice>.1.3.6.1.4.1.12325.1.200.1.8.2.1.7
This should return a list of pf interfaces with "Bytes In Passed" counters.Then could you return(from cacti) the Packet Filter statistic (Verbose Query) output?
This should give us some more information.Edit:
Just installed the latest snapshot in Vmware, and the pf MIB seems to be working fine. See screenshot.
</ipcactidevice> -
Hi YoMark,
The build date of the version i've got is Fri Nov 14 16:14:21 EST 2008. When I downloaded, the system was no longer producing new builds and their were some comments that no more active development work was going on so I assumed this was the latest. I just noticed the new files posted for the VMWare versions. Are the other installs (specifically embedded) updated again?
Here is the snmp walk data:
MacWild:~ myid$ snmpwalk -v 2c -c public ***.***.***.*** .1.3.6.1.4.1.12325.1.200.1.8.2.1.7 SNMPv2-SMI::enterprises.12325.1.200.1.8.2.1.7.1 = Counter64: 0 SNMPv2-SMI::enterprises.12325.1.200.1.8.2.1.7.2 = Counter64: 0 SNMPv2-SMI::enterprises.12325.1.200.1.8.2.1.7.3 = Counter64: 0 SNMPv2-SMI::enterprises.12325.1.200.1.8.2.1.7.4 = Counter64: 0 SNMPv2-SMI::enterprises.12325.1.200.1.8.2.1.7.5 = Counter64: 0 SNMPv2-SMI::enterprises.12325.1.200.1.8.2.1.7.6 = Counter64: 0 SNMPv2-SMI::enterprises.12325.1.200.1.8.2.1.7.7 = Counter64: 0 SNMPv2-SMI::enterprises.12325.1.200.1.8.2.1.7.8 = Counter64: 0 SNMPv2-SMI::enterprises.12325.1.200.1.8.2.1.7.9 = Counter64: 0 SNMPv2-SMI::enterprises.12325.1.200.1.8.2.1.7.10 = Counter64: 0 SNMPv2-SMI::enterprises.12325.1.200.1.8.2.1.7.11 = Counter64: 79754499 SNMPv2-SMI::enterprises.12325.1.200.1.8.2.1.7.12 = Counter64: 8118013 SNMPv2-SMI::enterprises.12325.1.200.1.8.2.1.7.13 = Counter64: 19540297 SNMPv2-SMI::enterprises.12325.1.200.1.8.2.1.7.14 = Counter64: 0 SNMPv2-SMI::enterprises.12325.1.200.1.8.2.1.7.15 = Counter64: 0 SNMPv2-SMI::enterprises.12325.1.200.1.8.2.1.7.16 = Counter64: 0
-
The SNMPwalk retuns data so my guess is that the interface OID has changed since the last upgrade.
As you could see there are 3 interfaces counters working(.11, .12, .13), but cacti is possibly polling for example .3, .4, or .5.
You could solve this problem by recreating the graphs, or rerun the Index query so that cacti knows it should poll another OID for the specific interface.Edit:
It seems that the order is changed somewhere during the latest snapshots:
Old snapshot:Executing SNMP walk for data @ '.1.3.6.1.4.1.12325.1.200.1.8.2.1.2' + Found item [ifIndex='bge0'] index: 1 [from value] + Found item [ifIndex='enc0'] index: 2 [from value] + Found item [ifIndex='lo0'] index: 3 [from value] + Found item [ifIndex='ng0'] index: 4 [from value] + Found item [ifIndex='pflog0'] index: 5 [from value] + Found item [ifIndex='pfsync0'] index: 6 [from value] + Found item [ifIndex='xl0'] index: 7 [from value] + Located input field 'pfInterfacesIfTZero' [walk]
New snapshot(other device):
+ Executing SNMP walk for data @ '.1.3.6.1.4.1.12325.1.200.1.8.2.1.2' + Found item [ifIndex='all'] index: 1 [from value] + Found item [ifIndex='carp'] index: 2 [from value] + Found item [ifIndex='enc'] index: 3 [from value] + Found item [ifIndex='enc0'] index: 4 [from value] + Found item [ifIndex='le0'] index: 5 [from value] + Found item [ifIndex='le1'] index: 6 [from value] + Found item [ifIndex='lo'] index: 7 [from value] + Found item [ifIndex='lo0'] index: 8 [from value] + Found item [ifIndex='pflog'] index: 9 [from value] + Found item [ifIndex='pflog0'] index: 10 [from value] + Found item [ifIndex='pfsync'] index: 11 [from value] + Found item [ifIndex='pfsync0'] index: 12 [from value] + Found item [ifIndex='plip0'] index: 13 [from value] + Located input field 'pfInterfacesIfTZero' [walk]
Notice the "all" , "carp" and "enc" interfaces now getting recognized in front of the rest. They weren't there before. This is causing the SNMP index number to change.
So it's not really a pfSense problem, only a feature change ;)
It could give some problems though with people using the SNMP packet filter MIB.ridnhard19: you could simply recreate you graphs in cacti and it should work again.
-
Ah ok great, I'll have to do that. Thanks for your help!
-
Hey it works! I just went and changed the Data Query in Cacti's interface. The index value before was vr0. I changed it to re0. I'm not sure why it was vr0 before but at any rate its working once again.
Thanks all for your help! Life is good ;D