I have a network that I am upgrading to 100G downlink. See diagram attached
The link interfaces between the network and ccr2216 will be 100gb mtu 9200
This interface itself is not on anybridge but it does carry vlans that are each a port in a bridge.
Do I neeed to set these bridges to 9200 MTU as well?
Also am I right in thinking that any interface on these bridges must be MTU 9200 as well?
will my WAN uplink have problems at 1500 MTU?
I have a /21 comming from WAN and being forwarded over the vlans to CPEs So it is the same subnet of ip per vlan.
L3 MTU (as in: IP MTU) has to be the same for every single device in same IP subnet … in your case that includes ISP’s router handling that /21 address space. Which likely means that you’ll have to conform to whatever your ISP is using (and my bet would be on 1500 bytes + VLAN overhead).
BTW, L3 MTU setting only affects traffic touched by device’s IP layer. For switches this is only management … It doesn’t affect traffic being switched between ports members of same bridge (and VLAN).
L2 MTU (as in: max ethernet frames’ size) has to be large enough to accept L3 packets (optionally with added VLAN headers) as their payload. And not much more, L2 equipment doesn’t pack multiple L3 packets into same L2 frame. If using standard 1500-byte IP MTU and including single layer of VLAN headers, this means 1522 bytes (including trailing CRC-check). So having 9200 byte L2 MTU on router<->switch interconnect won’t speed up the link.
So generally the safest is to leave L2 MTU settings at default unless you know very well why you have to set it differently.
Changing L3 MTU on internet links is particularly tricky … because 1500 bytes is a global de-facto standard. If you use large MTU on your link but next hop link (or even server your client is connecting) uses standard MTU, then somebody will either have to fragment packets (which most of times means using excessive CPU power, e.g. MT’s devices supporting L3HW offload don’t support HW-offloaded fragmentation) or (more likely) drop oversized packet with appropriate ICMP reply (which may get lost due to stupidity of some router admins).
So yes, using non-standard MTU (specially larger than standard) sizes can be viable option, but mostly in case when one controlls both connnection ends and everything in between (read: in LAN environment).
Yes, ISP may allow for large MTU, but that has to be used carefully. Don’t ever consider only a single link/hop, always look at bigger picture.
Regarding speed problems: yes, many contemporary clienrs will struggle with speeds exceeding around 2Gbps … so will many routers. Yes, using large MTU sizes will alleviate the problem a bit, but throughput won’t increase linearly with MTU size, packet processing on IP level is rarely the only bottleneck (PPS limit). On end devices (clients and servers) it’s also application layer processing and that doesn’t change much by increasing MTU. Also TCP windowing WOES don’t change much (TCP window size is in kB/MB, not in number of packets). Etc.
Again: change MTU size only if you know what you’re doing … very well. Otherwise you’ll cause more problems than good.
