SNMP traffic numbers weird after 2.1.3 upgrade



  • Not particularly critical.

    I run some simple SNMP graphs to keep track of my network health.

    I look at various ports on switches, and I look at the WAN and LAN ports on the pfSense box.

    Since 2.1.3 (I don't think I actually got to applying 2.1.2 before 2.1.3 came out) the download is reported double on the LAN and the upload is reported double on the WAN. This bogosity does not appear to affect what's reported on the RRD graphs, just the SNMP reporting. Previously, if I saw a much higher number on the LAN side it was reflective of Squid working, and would be bursty in the way squid cache hits tend to be. Now in normal steady-state traffic it just always reads double the LAN (I'm not clear if cache hits are also doubled - in any case, cache hits are still making traffic spikes as they should, beyond what's coming in the WAN.)

    Whatever is being uploaded from the LAN is reported at double on the WAN, and squid obviously isn't involved.

    Speedtests say it's the reporting, not any effect on actual speeds. NICs are Intel.



  • Sorry to bump this older-ish thread, but I just noticed today the exact same behavior on my system.  I went back over my historical data, and this was introduced somewhere along a recent upgrade to pfsense, since my really old data is correct, but the new stuff is doubled as described above.

    I have just a very basic 2 port WAN-LAN configuration, no caching or other packages installed that would cause there to be anything but bit-wise parity between the two ports on the router.  I also have two Intel ports (em0,em1)

    I pulled the logs from the SNMP collector, and the numbers match up as coming from pfsense doubled depending on direction:

    8 In WAN -> 16 Out LAN
    17 Out LAN -> 9 In WAN

    10:05:03 AM - em0 (wan) SNMP: v2: 192.168.0.1, dsname: traffic_in, oid: .1.3.6.1.2.1.2.2.1.10.1, value: 824575915
    10:05:03 AM - em1 (lan) SNMP: v2: 192.168.0.1, dsname: traffic_out, oid: .1.3.6.1.2.1.2.2.1.16.2, value: 1617349603
    10:05:03 AM - em1 (lan) SNMP: v2: 192.168.0.1, dsname: traffic_in, oid: .1.3.6.1.2.1.2.2.1.10.2, value: 921430819
    10:05:03 AM - em0 (wan) SNMP: v2: 192.168.0.1, dsname: traffic_out, oid: .1.3.6.1.2.1.2.2.1.16.1, value: 1726736090

    10:00:03 AM - em0 (wan) SNMP: v2: 192.168.0.1, dsname: traffic_in, oid: .1.3.6.1.2.1.2.2.1.10.1, value: 824013028
    10:00:03 AM - em1 (lan) SNMP: v2: 192.168.0.1, dsname: traffic_out, oid: .1.3.6.1.2.1.2.2.1.16.2, value: 1616377161
    10:00:03 AM - em1 (lan) SNMP: v2: 192.168.0.1, dsname: traffic_in, oid: .1.3.6.1.2.1.2.2.1.10.2, value: 918096648
    10:00:03 AM - em0 (wan) SNMP: v2: 192.168.0.1, dsname: traffic_out, oid: .1.3.6.1.2.1.2.2.1.16.1, value: 1720177760

    09:55:02 AM - em0 (wan) SNMP: v2: 192.168.0.1, dsname: traffic_in, oid: .1.3.6.1.2.1.2.2.1.10.1, value: 822299137
    09:55:02 AM - em1 (lan) SNMP: v2: 192.168.0.1, dsname: traffic_out, oid: .1.3.6.1.2.1.2.2.1.16.2, value: 1613171931
    09:55:02 AM - em1 (lan) SNMP: v2: 192.168.0.1, dsname: traffic_in, oid: .1.3.6.1.2.1.2.2.1.10.2, value: 913142379
    09:55:02 AM - em0 (wan) SNMP: v2: 192.168.0.1, dsname: traffic_out, oid: .1.3.6.1.2.1.2.2.1.16.1, value: 1710376244

    This of course causes my traffic accounting to be double depending on direction as can be seen in the attached screenshot.

    Any clues as to why this might be, or some kind of workaround?




  • I hate to dredge up this really old post, but I'm seeing this as well, and I can't seem to find that anyone figured out a solution.
    Oddly enough, it is only happening on one of our pfSense installs (we have 11 running 2.2.1).  Of course, it is the one at our main corporate office, which means I'd like to get meaningful non-doubled bandwidth usage numbers from SNMP.

    One thought I had - this is also the only box we have running ipv6 and ipv4.  All of the others are ipv4 only.

    Any thoughts?


Log in to reply