Tx Queue Drops, where to start?

[rndm]

Actual loss happens on mikrotik … packet somehow arrives at port Tx queue (another name for FIFO buffer) where it’s discarded. So it’s never attempted to pass to SFP and SFP knows nothing about it (not even that it was dropped).

PPPoE is, in this case, payload of discarded packet. PPPoE interface doesn’t know that packet got discarded at some point as PPPoE is unacknowledged transport protocol. The only entity that can discover that some packets are missing, is PPPoE server … but doesn’t care either, PPPoE doesn’t do fragmentation (IP layer has to if PPPoE link MTU is too small and IP de-fragmentation is then done by final recipient of packets … when a fragment is missing, IP stack discards the incomplete packet) so it’s whole IP packets gone missing. PPPoE also doesn’t provide feedback to client so any detected missing PPPoE frames stats is kept secret from you.
Next instance noticing packet drops is actually TCP/UDP stack. UDP doesn’t care about it either while TCP requests retransmission. If you’d be able to look into retransmission stats, you’d probably see some non-zero number there. Iperf tests provide with such stats (for UDP as well because application itself does detection). For TCP the consequence is reduced throughput, each retransmission causes reduction of “TCP window size” and that is important on all links where round trip latency is not negligible (i.e. all links. Period.)

In short: there are not many places where you could notice dropped packets apart from counters at the place of drops and on application layer (but this one can’t tell you where packets get dropped). And dropped packet is counted as such only at the place where it’s dropped.

So. Is this a problem at all? I still can see these packets. But everything works fine. Not sure where this drop occurs and under what circumstances. Can it be dropped by firewall?