I is obvious you just google MTU when I mentioned it.
It is even more obvious you do not fully understand the Cloudflare article.
What is most obvious is you are not a network engineer. Every single network engineer I know deal with at least one MTU problem in their life and remember their experience well because it is one hell of a mystery to begin with.
But I am an inclusive person and I will not tell people to stop argument with me. Most importantly I will not brush people off because they are not a doctor or not a network engineer or what not. So let me start you up with your research, as you seems a lot smarter than tng55. Not sure who is smarter, is it you or
BeeYenHuaPPPoE:
The standard says the minimum overhead is 8 bytes. It can be more. You never know if the BNG you are using are having an 8 bytes overhead or more.
Multipath link:
All telco run jumbo frame in their network. If they misconfigured one path, anything going through that path will be hit with fragmentation and reassembly.
MPLS and Segment Routing:
Overhead varies, depending on the number of label, and the number of tunnel-in-tunnel the telco use.
5G edge compute:
They are mostly MTU 1300 right now.
The Mikrotik specific problem:
It can do MRU 1500 but MTU is 1480. Do a packet capture and you will understand why. The negitiation for MTU 1500 is actually successful, but then TM BNG has a problem where the LCP-Reply will be malformed. When Mikrotik detects it, it lower MTU to 1480. As far as I can tell, all the TM BNG I tried exhibit this bug. The lowering of MTU is actually a bug itself in RouterOS. So 2 bugs combined made this happen.
The "most stable" MTU:
It is 1280. It is the smallest dictated by IPv6 standard without fragmentation. Large enough to fit most tunnel, including 5G compute edge, PPPoE, VPN. It will even work if Path MTU Discovery is broken.
Windows and their firewall:
The last time I use Windows, their firewall by default block ICMP Type 3 Code 4 and ICMPv6 Type 2 Code 0. What this means is PMTUD will never work on Windows. If the BNG is configured to never disassemble packet, it will break all Windows machine with the default configuration and has a higher than link MTU set.
CDN and big tech runs at MTU 1280 for maximum compatibility. Cloudflare only recently changed and they blogged it:
https://blog.cloudflare.com/increasing-ipv6-mtuUsing a browser test to talk about hop count? You need to do better than that. Hop count is never accurate on MPLS / SR network because everything inside the tunnel session has count=1 regardless of how many physical router they pass-through.
Proof that MRU 1500 is working even when my MTU is 1480... Woots!
CODE
$ ss -tapi
State Recv-Q Send-Q                Local Address:Port        Peer Address:Port  Process                                                                                                Â
ESTAB 0    0                  192.168.88.17:37238        104.26.6.73:https  users:(("firefox",pid=3486,fd=157))                                Â
 bbr wscale:13,7 rto:227 rtt:26.152/5.336 ato:40 mss:1388 pmtu:1500 rcvmss:1428 advmss:1448 cwnd:23 bytes_sent:3454 bytes_acked:3455 bytes_received:7593 segs_out:24 segs_in:21 data_segs_out:13 data_segs_in:15 bbr:(bw:1.81Mbps,mrtt:15.556,pacing_gain:2.88672,cwnd_gain:2.88672) send 9.77Mbps lastsnd:22071 lastrcv:22047 lastack:22047 pacing_rate 10.8Mbps delivery_rate 1.81Mbps delivered:14 app_limited busy:182ms rcv_space:14480 rcv_ssthresh:64088 minrtt:11.561 snd_wnd:49152 rcv_wnd:59392
ESTAB 0    0                  192.168.88.17:32940      151.101.65.140:https  users:(("firefox",pid=3486,fd=153))                                Â
 bbr wscale:9,7 rto:221 rtt:20.62/5.495 ato:40 mss:1428 pmtu:1500 rcvmss:1428 advmss:1448 cwnd:30 bytes_sent:12516 bytes_acked:12517 bytes_received:23479 segs_out:43 segs_in:50 data_segs_out:22 data_segs_in:31 bbr:(bw:3.78Mbps,mrtt:10.567,pacing_gain:2.88672,cwnd_gain:2.88672) send 16.6Mbps lastsnd:25072 lastrcv:25053 lastack:25053 pacing_rate 27.1Mbps delivery_rate 3.78Mbps delivered:23 app_limited busy:203ms rcv_space:14480 rcv_ssthresh:64088 minrtt:10.567 rcv_ooopack:1 snd_wnd:187392 rcv_wnd:64128
ESTAB 0    0                  192.168.88.17:50304       104.18.18.239:https  users:(("firefox",pid=3486,fd=125))                                Â
 bbr wscale:13,7 rto:226 rtt:25.686/19.446 ato:40 mss:1388 pmtu:1500 rcvmss:1428 advmss:1448 cwnd:17 bytes_sent:2427 bytes_acked:2428 bytes_received:6841 segs_out:13 segs_in:15 data_segs_out:7 data_segs_in:9 bbr:(bw:1.27Mbps,mrtt:13.162,pacing_gain:2.88672,cwnd_gain:2.88672) send 7.35Mbps lastsnd:29026 lastrcv:28959 lastack:28959 pacing_rate 24.1Mbps delivery_rate 1.27Mbps delivered:8 app_limited busy:183ms rcv_space:14480 rcv_ssthresh:64088 minrtt:13.162 snd_wnd:49152 rcv_wnd:59264
ESTAB 0    0     [2001:e68:5427:3c12:be6e:fc31:120a:42af]:49876  [2001:4860:4860::8844]:https  users:(("firefox",pid=3486,fd=121))                                Â
 bbr wscale:8,7 rto:214 rtt:13.583/4.275 ato:40 mss:1408 pmtu:1480 rcvmss:1208 advmss:1408 cwnd:18 bytes_sent:2837 bytes_acked:2838 bytes_received:2068 segs_out:16 segs_in:12 data_segs_out:8 data_segs_in:7 bbr:(bw:3.2Mbps,mrtt:7.028,pacing_gain:2.88672,cwnd_gain:2.88672) send 14.9Mbps lastsnd:46324 lastrcv:46310 lastack:46310 pacing_rate 23.6Mbps delivery_rate 3.2Mbps delivered:9 app_limited busy:79ms rcv_space:14080 rcv_ssthresh:64128 minrtt:7.028 snd_wnd:74240 rcv_wnd:63616
To my defense I wasnt even replying or even engaging any conversation with you but you quote me and turned it all to be about you. You even drop names which I dont even know who they are. If you have issues with them dont trash it on me. Or maybe you have issues with me too since you kept flaming all my conversation with others as if I was in conversation with you. I dont know whats your problem or what are you trying to achieve from all this by being this hostile but rest assured Im not gonna hang around here anymore. Especially not around people like you.
Jun 20 2024, 05:48 PM
Quote
0.0208sec
1.06
6 queries
GZIP Disabled