Adjust MSS calculation to account for VLANs

johnpoz

@virtual-frog you have something all f'd up on that vlan would be my guess. So the mtu on the interface is 1500? What about your clients, are they wired or is wireless involved..

No idea about that tp link when it comes to vlans - they don't seem to quite get it ;) A few years back they had an issue where they would not allow you to remove vlan 1 from any ports.. So if you wanted to run say vlan 10 on that port, you were also untagged in vlan 1.. Took them like 2 years to correct it..

Why does WAN send the frag message for only packets originating on the VLAN?

Its not it sending it because what ddg is sending back.. A full packet seems to be too big for your vlan?? Even though the client sent a mss of 1460.. you can see that from the syn you sent.

virtual-frog

@johnpoz

Yes, all MTUs are the default 1500.
Mix of wired and wireless, same effect on both.
TP Link seems to have matured somewhat (still not perfect) so I don't think there's some huge flaw in the switch.
It's strange that this only happens with one site, too.
I may reset and reinstall everything.

johnpoz

@virtual-frog I am not having any issues with that site, via tagged vlans.. Than again I am not running on tplink ;)

Did you try just turning off jumbo support?

RobbieTT

@virtual-frog
Are you not going to try removing the switch from the equation by going direct to the router for fault finding purposes?

Ruling these things in or out takes seconds of self-help.

️

RobbieTT

@johnpoz said in Adjust MSS calculation to account for VLANs:

@virtual-frog you have something all f'd up on that vlan would be my guess.

I'd probably not use that phrasing but I agree that this looks to be a local network issue.

️

RobbieTT

@JKnott said in Adjust MSS calculation to account for VLANs:

Do switches even have an MTU setting? That's a layer 3 concept.

I think you just outed yourself as a fellow greybeard. For sure that was once the case and still referenced in some documentation but many (and disparate*) changes undermined that. Indeed, we were probably looking at switches with awe back then, as we nursed our hubs along.

Our distinction now is that in the context of Layer 2 switches the larger MTU is referenced with specific regard to jumbo frames and these are solely at L2.

At Layer 3 (network layer) the larger MTU is used in the context of jumbo packets. This is before we drift-off to sleep with oversized L3 MTU jumbo packets being jumbograms.

A few things don't matter and most things don't matter at all.

️

*some would argue that the word 'haphazard' should be inserted here

JKnott

@johnpoz said in Adjust MSS calculation to account for VLANs:

Did you try just turning off jumbo support?

What would that do? It only affects the size of frame the switch will pass. It has nothing to do with MTU.

JKnott

@RobbieTT said in Adjust MSS calculation to account for VLANs:

At Layer 3 (network layer) the larger MTU is used in the context of jumbo packets

I am aware of that. However, did the OP mention anything about a L3 switch? Are there any consumer level L3 switches. I have a switch that can pass 16K jumbo frames and, IIRC, there's no setting for that. It's just there and will pass any frames up to that size. Of course, with 1500 MTU, it won't see many that big.

RobbieTT

@JKnott I specifically said at the network layer. Nobody has mentioned any L3 features being used down at the data link layer.

In answer, there are very few consumer/prosumer switches with any L3-like capabilities. I have a couple of them but the L3 options are so badly implemented that I don't use them in that role.

️

johnpoz

@JKnott with a tplink have no idea sure isn’t going to hurt turning it off I mean 1518 isn’t even a valid jumbo anything 1518 is frame if you include 14 bytes of header and 4 for crc

Wouldn’t be surprise at any nonsense tplink might be doing to be honest