Odd MTU / fragmented packet issue on web GUI and haproxy
-
@johnpoz I submitted a ticket to the switch vendor. I'll update here if I find out anything useful.
-
@shewless great - that damn curiosity cat of mine is is always meowing.. Yes please let us know what comes of that.
-
@johnpoz update:
I verified that on my ubuntu client that this ping works:
ping -c 10 -M do -s 1472 192.168.120.1
But it results in the oversize counter increasing. wireshark shows a packet size of 1514 for both request and reply.The size of 1468 is required to avoid oversize counter increasing
ping -c 10 -M do -s 1468 192.168.120.1
This results in a wireshark packet size of 1510.Likely a cosmetic problem as the packets all seam to go where they are supposed to go... a support case is opened for the switch vendor.
-
@shewless yeah that is odd! for sure.. 1522 should be max size, even says so in the doc I linked too. I could see anything over 1522 triggering the oversize counter, if you didn't have jumbo enabled..
-
@johnpoz Update:
Switch vendor believes it's okay to have to update the system MTU to a higher value (in order to remove the error counter) and to live with the "oversize" counter increases.
I have since set the system MTU to 9000 (which is the L2 MTU). Any IP Interface I create can have an L3 MTU applied to it of 1500.Thanks for the help.
-
@shewless said in Odd MTU / fragmented packet issue on web GUI and haproxy:
it's okay to have to update the system MTU to a higher value (in order to remove the error counter)
Yeah that is not the correct solution.. Mismatched mtu is never a good thing..
-
@johnpoz I agree that this is not the correct solution and I have let the switch vendor know. Maybe if other potential customers provide feedback they'll make changes.
In my case I don't think the MTU settings will be harmful. I've already tested that my endpoint devices all have "Layer3" MTU of 1500 and having the switch system MTU set to a higher value doesn't impact the traffic being sent. -
@shewless Personally I would just live with the cosmetic errors being listed most likely vs setting a clearly mismatched mtu.
As long as its not actually dropping the traffic, etc.
-
@johnpoz In that case if there actually was an error in packet transmission it would be harder to detect.. certainly an option though. I could also return the switch :)
-
@shewless said in Odd MTU / fragmented packet issue on web GUI and haproxy:
I could also return the switch
Another option for sure - such issues, and their "fix" is to set your mtu to something it shouldn't be doesn't instill confidence if you ask me.
Now if they said, oh yeah we know about - cosmetic, will be corrected in next update.
If they can not get this right, what else are they getting wrong?
Reminds me of issues with entry level tplink, not letting your remove vlan 1 from ports you were putting in a different vlan.. They came back that it was meant to be like that, and normal.. Took them ever to correct it, and they never back ported it to earlier models.. Not something that instills confidence in their understanding of how vlans work ;)
-
I don't recall seeing an MTU size on switches I've worked on, not that I've looked though. However, as long as the switch can handle whatever size frame you throw at it, it shouldn't be a problem. So, you have to look at the largest frames that will be used on the network and allow for that. The only issue I can think of is the amount of buffer space larger frames will use. Perhaps the manufacturer is from back in the days prior to frame expansion and doesn't think frames would have more that 1500 MTU. This would, of course, cause issues with things like VLANs needing 4 bytes of the MTU.
Even my cheap, crappy TP-Link 5 port switch can handle 16 KB jumbo frames.
-
@jknott see my info from the manual, where it correctly states 1522.. its a cosmetic issue.. But you shouldn't be going about changing the actual mtu on any interface or a switch because of some cosmetic issue with the switch software.
The mtu should be 1500.. Unless your running some unique network with different mtu, jumbo, etc..
If he wants to enable jumbo frames that is up to him.. But he is not using jumbo, and it would do would be to remove the logging of oversized frames, that are not actually oversized.
I do not have jumbo enabled.. All of my mtu's everywhere are the default 1500.. I see no oversized marked on any ports of the switch, many carry vlans..
-
I don't doubt there's an MTU setting on it. My question is why. Other than the management interface, there is no need for a MTU setting, as the switch should be able to pass any reasonable size frame. As I mentioned, even that TP-Link can handle 16 KB. The MTU limit started growing back in the late '90s, with frame expansion to allow for VLAN tags, etc.. So a switch after that time should pass VLAN frames without complaint. Later, jumbo frames came it which means it should never worry about a few extra bytes in a frame. As I mentioned, the only issue would be buffer size as data within a switch is transferred a frame at a time. You can see this in switch specs where performance is measured in frames per second, regardless of frame size. I just find it very odd that a switch these days would worry about a few bytes.
-
@jknott all stuff pointing to returning of the switch if you ask me..
