376.49_2 (and older) SNMP bandwidth oddities (RT-AC66U)

[Potato Sack]

First, I want to thank RMerlin for the great firmware. It's rock solid.

However, I've recently decided I wanted to turn on SNMP and generate some RRD graphs via MRTG. During this process, I've had really confusing data being provided on the WAN (eth0) port of my RT-AC66U.

I'm wondering if somebody could confirm if this is a bug somewhere or if the snmpd configuration on the device is strange, or if I'm doing something wrong that I've totally overlooked, or what.

The main issue seems to be that bandwidth reported on the WAN (eth0) interface on the router seems to only be half correct. The outbound traffic seems to be way off from what it should be, in that it's reporting very high. When I compare my MRTG graphs to the Traffic Monitor graph on the router itself, it's nowhere close. I know that MRTG is using averaged octet counts over a 5-minute period, but I should still see something of a correlation.

I have confirmed via an snmpwalk of the device that it does indeed have OIDs 1.3.6.1.2.1.31.1.1.1.6.2 and 1.3.6.1.2.1.31.1.1.1.10.2 (IfHCInOctets and IfHCOutOctets). I have actually run a tcpdump on the br0 interface of the router (via entware) explicitly looking for UDP 161 packets, and I have verified in the packet capture that MRTG is indeed polling these OIDs and getting octet counts back.

Example:
https://i.imgur.com/aRHkLjm.png (pardon the blue line, accident by me in snipping tool)

I left the packet capture running for about 30 minutes, capturing 6 5-minute samples of the IfHC* OIDs above. When I average out the values (by subtracting the previous 5-minute poll result from the current, diving by 300 (5 minutes in seconds) to arrive at a Bytes/second number, and then dividing by 1024 to get kB/s), it agrees with the MRTG graphs.

This tells me the values that the router is inserting into those OIDs, at least for the outbound traffic, appears to be incorrect.

Any idea what would cause this?

 

[RMerlin]

Disable NAT acceleration. That causes part of the traffic to bypass the router's network stack, and will lead to unreliable traffic values.

 

[Potato Sack]

Disable NAT acceleration. That causes part of the traffic to bypass the router's network stack, and will lead to unreliable traffic values.

Thanks for the response -- I'll give it a whirl.

Before I do, I seem to notice that what appears as "Inbound" traffic on my WAN port (eth0) actually appears to be "Outbound" traffic on br0. Even if this traffic is between two local hosts (e.g., 192.168.1.100 on wireless talking to 192.168.1.101 on wired), it still shows up on the WAN port, which of course isn't correct. Not sure if this is symptomatic of what you mentioned above Re: NAT acceleration, but I'll give it a shot.

I appreciate the response, and I'll follow up with a result in case others notice the same issue.

 

[Potato Sack]

Well, something changed after disabling NAT acceleration, i'm just not sure what. From my MRTG graphs, I still seem to be seeing a similar curiosity in reported bytes/s from the SNMP OIDs it polls after turning off NAT Acceleration. I'm not sure I've seen an appreciable change there.

However I'm also getting these ginormous and semi-regular traffic spikes on the WAN interface via Traffic Monitor:

https://i.imgur.com/RjonNSk.png