I in the overall counters of my routers (CCR) I see many packets with oversize on routed interfaces. When I catch them with a fw rule I see for example
08:48:03 firewall,info forward: in:vlan998 out:vlan314, src-mac 00:50:56:ac:3b:bd, proto UDP, x.y.64.2:53->x.y.81.45:43594, len 2021
08:48:03 firewall,info forward: in:vlan998 out:vlan314, src-mac 00:50:56:ac:3b:bd, proto UDP, x.y.64.2:53->x.y.81.45:62049, len 1866
08:48:03 firewall,info forward: in:vlan998 out:vlan314, src-mac 00:50:56:ac:3b:bd, proto UDP, x.y.64.2:53->x.y.81.45:41655, len 1867
If I make a packet sniff I see no big packets (max size 1514 byte) . As I said: The interfaces are routed with MTU 1500. The destination IPs are customer IP and in this case the traffic is a dns-response. In the past there were no oversize packets on this interfaces. Is it only a bug or has the reporting changed (packet combined by the contrack) ?
The size of an UDP packet is not related to the MTU, UDP packets can be fragmented as any other.
So a DNS reply of 2021 bytes should be sent as 2 packets by the router.
(and as the MTU probably is 1500 on the internet side as well, it should already be fragmented somewhere upstream so the router only has to forward the two fragments)
@pe1
Sure! I know but why this fragmented packet are shown in the “overall stat” tab of the interface as packets >1519 to max? I think in this stat only the IP-packet-size is relevant.
The IP packet size is the one that can be 0-64KB.
When it is more than the MTU (- header size) it will be fragmented during transmission and reassembled by the final receiver.
(some routers can also reassemble fragments to improve L7 matching and possibly improve efficiency when MTU is different on inside and outside network, but I don’t think MikroTik routers can do it)
Sure, but it appears your statement “I see many packets with oversize on routed interfaces. When I catch them with a fw rule” is not correct.
Of course it can be that packets are received that are too large, but these are not the packets you have traced with your firewall rule.
In fact, when this happens on receive, it is not possible to trace them. And I think it happens on receive, because there is no “too long” error counter for Tx.
When it happens on your customer-facing interface, probably your customer has a too large MTU set. Or has enabled “jumbo frames”.
Ask them to correct that.