@Fae 

Same result last night, averaging around 1TB every 5 mins while asleep

@Philbert 

Yesterday was the first day i've reset my switch since i installed it and the statistics have all seem to have gone back to normal! I will keep an eye on how long it lasts. 

Probaby not related but just before i reset it i added a primary and secondary DNS server for the switch (i left them blank originally). Do you have yours under DHCP or with a static mapping? 

@Adoril 

Hey

I have my switch set static, im one of those nutbags that likes everything thats not a client device set static  

A reboot does seem to fix this for a while, around 6-10 days for me.   Be interested to see if you get the same result..

@Philbert 

I'm the same, traditionally i have every device on a static IP, It just helps incase i ever need to ping a device or connect to it. The downside of this SDN controller in comparison to my previous hardware is the lack of any kind of DHCP reservation list. Its a pain to keep track of everything so i've left all the devices i possibly can on DHCP with static IP addresses just for key components. The other issue is the static addresses are in the DHCP range which seems a big flaw to me as i normally leave 192.168.0.2-192.168.0.100 for static allocation and the rest to DHCP!

Just to report in it is all fine still. 

@Fae 

Had an issue this morning which i may have tracked down what causes these huge spikes in traffic. While using the controller this morning editing the switch ACL it froze and kicked me out. I accessed it on its own VLAN(1) and it worked fine so i looked at the stats and noticed my PCs second NIC (connected to VLAN20) was putting through a lot of data which doesn't show up on the device screen but shows up on the statistics page.

It seemed to a huge amount of packets going back and forth as if you look at the multicast and broadcast packets they show:

This nic has an ACL gateway entry to deny it to any IP address (its used to transfer files over my second network) to prevent internet access. Once unplugged and plugged back in it now is fine.

So i am guessing this is some kind of network storm issue created by devices which can't get to an address they want to? Should i enable something in the storm control section to prevent it? 

@Fae 

As I wrote about in another post (https://community.tp-link.com/en/business/forum/topic/250758) I am also seeing incorrect "Client" usage statistics:  (thanks @Philbert for pointing me here)

   - Omada Controller v4.2.8  (Ubuntu 18.04 on a Raspberry Pi 3B)

   - (1) TL-R605 (v1.0.0 firmware)

   - (1) TL-SG2008 V3 (v3.0.0 firmware)          (connected to the TL-R605 carrying wired clients)

   - (2) AP620 HD  (v1.0.1 firmware)                (one is connected directly to the TL-R605)

   - (1) Dumb switch between the other AP and the TL-R605

In my case I click on "Clients" in the Controller, click the client then click History.  (the same data effectively shows less detailed in the big Client data table)  Here I see wireless devices that show many GB of traffic, which is incorrect.  Also, I have two wired computers to the TL-R605 and they both are showing 0 bytes of data, which is also incorrect.  (one is tied directly to the router, another has a dumb switch in-between)

Note "Device" statistics, for me, seems to roughly make sense.  (at least the TL-R605 router and the APs)

Rebooting doesn't seem to help in my case.  It started doing this from the first day.

I hope you are able to reproduce and find this bug.  Thank you in advance.

@Fae Hi did you have any news for us? when will the problem be resolved?

this is a very annoying problem because the statistics are so completely useless

@Fae Hi can tell me the status about the problem? 

Thank you!