Just packet drop, (very normal in IP, even in a single UDP or TCP stream) ? (queue full or packet reached end-of-life/TTL value, device cannot handle volume, congestion, …)
RX packets number is off screen capture. But you actually hide almost everything. (What MT ? SFP speed, ether4 speed, routed/bridged?, NAT or any other firewall rules?, what is after ether4?, HW offloaded? , error counters SFP and ether4?, CPU load? , protocol used? … ???)
On thing common in every post i read on MikroTik forum is that i person who believes he/she knows all will make a comment that is actually not in anyway helpful or contributive
As a network admin sometimes when we are stuck we reach out to colleagues for ideas or advice.
I believe its one of the main reason this forum was created
Anyways thanks for your no contribution and your irrelevant response
I suggest attacks of some devices on the other part of the network
We are cleaning up the client side.
May i also add there's no need for unnecessary harsh and hostile comments before you make your suggestions i tried to ignore once but you still had to comment "Please do not quote unnecessarily.
Use "Post Reply",
Even if you feel im a newbie i dont think not knowing how to post a reply after 9years in this forum makes any logical sense
What does your NMS say? You should be able to look at your netflow stats to determine what the excess traffic is, or just torch the interface see whats happening that is not being forwarded to ether4. Likely dropped/queued packets or traffic to unused IP’s in a subnet you are using but not actively being used by a customer.
I’m sorry, my magic crystal ball sometimes is unreliable and I can’t use it in mystery problem solving.
But I see that you recently found the export function, after 9 years “of forum”. PS: spending time on a forum doesn’t make you a network administrator.
PS2: Ever saw Tool/Torch? It’s like a magic crystal ball of some sorts.
Since you talk about “customers”, chances are high that you’ve got some bandwidth shaping rules (using queues) in place. If so, it’s what @bpwl suggests - that client has attracted (willingly or unwillingly) a traffic volume his contract doesn’t allow. So that traffic arrives via the uplink (sfp) interface, but only part of it is actually forwarded to the client. Not all types of traffic adjust the transmit speed to a feedback provided by the recipient.
Regarding the harsh comments - nobody has been born a network administrator, but the same information can be presented in multiple forms, and some people perceive some forms better than others. Your augmented screenshot does illustrate what you ask about, but whereas some people may understand it at first glance, other people (like me) have to study it longer - not to find what is actually wrong but to find out what you deem wrong.
It would have been easy for you to describe your concern also in plain words, like “why the Rx bandwidth on the uplink interface is much higher than the sum of Tx bandwidths on downlink interfaces”.