What's new

RT-AC68U - SNMP Values the same for in/out

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

yoleska

New Around Here
I have been trying to setup SNMP on this device for a couple days now.

I finally have cacti setup and able to poll (and graph) the 64-bit OIDs. 32-bit OIDs will not work as they stop graphing around 78Mbs since they rollover. I guess that's the only bad thing about having my Comcast Blast service upgraded to 105/10.

The problem is that I seem to be getting the same values for traffic_in and traffic_out on the WAN port (eth0) as seen from the attached picture.

I've also quickly setup MRTG and am also seeing the same thing.

Yes, I've checked the OIDs and they are correct for the particular interface.

$ snmpget -v2c -cpublic 192.168.120.101 1.3.6.1.2.1.31.1.1.1.6.2
IF-MIB::ifHCInOctets.2 = Counter64: 10911974723
$ snmpget -v2c -cpublic 192.168.120.101 1.3.6.1.2.1.31.1.1.1.10.2
IF-MIB::ifHCOutOctets.2 = Counter64: 11150153915

Has anyone else seen this?

The traffic graph in the stock (and now Merlin-based) GUI seem to also show this same behavior - same in and out bandwidth totals.

One thing to note is that for br0 (the LAN interface) it shows different values for in/out, but it's definitely not graphing the correct traffic for the inside interface.
 

Attachments

  • Asus-bandwidth-problem.jpg
    Asus-bandwidth-problem.jpg
    63.6 KB · Views: 1,402
I have been trying to setup SNMP on this device for a couple days now.

I finally have cacti setup and able to poll (and graph) the 64-bit OIDs. 32-bit OIDs will not work as they stop graphing around 78Mbs since they rollover. I guess that's the only bad thing about having my Comcast Blast service upgraded to 105/10.

The problem is that I seem to be getting the same values for traffic_in and traffic_out on the WAN port (eth0) as seen from the attached picture.

I've also quickly setup MRTG and am also seeing the same thing.

Yes, I've checked the OIDs and they are correct for the particular interface.

$ snmpget -v2c -cpublic 192.168.120.101 1.3.6.1.2.1.31.1.1.1.6.2
IF-MIB::ifHCInOctets.2 = Counter64: 10911974723
$ snmpget -v2c -cpublic 192.168.120.101 1.3.6.1.2.1.31.1.1.1.10.2
IF-MIB::ifHCOutOctets.2 = Counter64: 11150153915

Has anyone else seen this?

The traffic graph in the stock (and now Merlin-based) GUI seem to also show this same behavior - same in and out bandwidth totals.

One thing to note is that for br0 (the LAN interface) it shows different values for in/out, but it's definitely not graphing the correct traffic for the inside interface.

Yes, I also see the traffic_in and traffic_out SNMP statistics on the WAN port having the same values (but not always, see CTF below).

I'm sure someone out there knows exactly how this works but for now I believe that we're seeing the following mechanism:

The RT-AC68U normally routes all traffic between inside and outside across 2 internal vlans named vlan1 and vlan10. You might notice these being enumerated when you snmpwalk the router's interfaces.
The reason the eth0 (or WAN) counters move together is that both vlans are defined on the eth0 interface. When one vlan is sending the other one will be receiving, and vice versa.

However this symmetry stops when the Broadcom cut-through-forwarding (or CTF) kernel module kicks in, as that causes packets to bypass the br0/vlan1 and vlan10 routing. You can test the effect of CTF on the SNMP counters yourself by disabling it under LAN->Switch Control tab->NAT Acceleration (previously known as HW Acceleration).

Basically all of this means that: A) You can ignore the counters moving together, as eth0 isn't really receiving whatever it is sending and B) The br0, vlan1 and vlan10 counters will not show the complete picture when CTF is enabled.
 
BTW just for reference, there is another quirk on the RT-AC68U (at least on firmwares up to 3.0.0.4.376_1663):
The RX and TX counters on the ethX interfaces are 32-bit unsigned, meaning they roll over to 0 after 4,294,967,295 bytes. The same counters on vlanX are not and they keep ticking on.

This won't affect SNMP rate monitoring in Cacti etc.
But it's something to keep in mind if you're using ifconfig, ip -s link, or /proc/net/dev to compare traffic totals.

So rules of thumb:
- vlan1 RX or TX + vlan10 RX or TX = eth0 RX or TX (when CTF is disabled, and only until you transfer more than 4GB).
- eth0 is a reliable SNMP rate counter for all Internet traffic both with and without CTF, but only the higher number of either RX or TX.
 
Just to: exact same behavior observed with ASUS RT-3100 with eth0 (WAN) in /out being roughly the same.
Further, also seeing the rollover at about 4GB. I wanted to monitor total volume in/out and assumed the 64b octet counter could be used directly but it seems I will need to measure "deltas" periodically and accumulate them in order to get total volumes.
 

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top