Odd MTU / fragmented packet issue on web GUI and haproxy
-
@shewless that is not showing the status.
show interfaces status ethernet tg0/25
You have the mtu on that port set to 1550..
-
@johnpoz that command doesn't work on my switch unless I'm in the wrong mode or something? My switch is the "newer" model: The https://www.fs.com/products/134655.html?attribute=8032&id=289447
switch#show interfaces status ethernet tg0/25 show interfaces status ethernet tg0/25 ^ Too many parametersswitch#show interface ? GigaEthernet -- GigaEthernet interface TGigaEthernet -- Ten GigaEthernet interface Vlan -- VLAN interface Null -- Null interface brief -- brief information of the interface range -- show interface range ifindex -- show interface based on ifindex | -- Output modifiers <cr>switch#show ethernet ? cfm -- Configure Connection Fault Management protocol(CFM) oam -- Operations, Administration and MaintenanceThe MTU was set globally. When I look at the manual I only see a way to do it globally for this switch (the -R version):
switch#show system mtu System MTU size is 1550 bytesWhat am I missing?
-
@shewless I would set it back to 1500, 1550 mtu is not standard by any means.
did you look over that link to the manual - isn't that your switch?
-
@johnpoz I can do that (set the MTU to 1500). I think when it was at 1500 I was seeing both "error" counter increases and "oversize" packet increases... I will change it now and see if that is the case.
I totally have been pouring over the manual. As I mentioned the -R version seems to have a different CLI unfortunately. -
@johnpoz yeah as soon as I set the system mtu to 1500 I see both "error" and "oversize" increasing.. though I haven't noticed any functionality problems.. I'd love to get to the bottom of this.
TGigaEthernet0/25 is up, line protocol is up protocolstatus upTimes 1, downTimes 0, last transition 2000-1-1 0:0:21 Ifindex is 189, unique port number is 49 Hardware is 10Giga-FX, address is 649d.9928.4a3d (bia 649d.9928.4a3d) MTU 1500 bytes, BW 10000000 kbit, DLY 10 usec Encapsulation ARPA Full-duplex, 10000Mb/s, Flow-Control Off 5 minutes input rate 202703 bits/sec, 71 packets/sec 5 minutes output rate 105389 bits/sec, 69 packets/sec Real time input rate 0%, 133720 bits/sec, 64 packets/sec Real time output rate 0%, 99284 bits/sec, 67 packets/sec Received 14056231 packets, 14473843206 bytes 2951 broadcasts, 12725 multicasts, 14040555 ucasts 0 discard, 478 error, 0 PAUSE 0 align, 0 FCS, 0 symbol 0 jabber, 340230 oversize, 0 undersize 0 carriersense, 0 collision, 0 fragment 0 L3 packets, 0 discards, 0 Header errors Transmitted 8803287 packets, 1840177991 bytes 334995 broadcasts, 121700 multicasts, 8346592 ucasts 0 discard, 0 error, 0 PAUSE 0 sqettest, 0 deferred, 287250 oversize 0 single, 0 multiple, 0 excessive, 0 late 0 L3 forwards -
@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..
