Community discussions

MikroTik App
 
Michaelcrapse
newbie
Topic Author
Posts: 26
Joined: Wed Oct 25, 2017 9:57 pm

CRS317 Bridge MTU not changing

Tue Oct 15, 2019 10:50 pm

How do I change the MTU on my bridge on the CRS317?
Never had this issue before.
You can see every single interface has a higher MTU than the bridge interface which does not allow me to change manually..
You do not have the required permissions to view the files attached to this post.
 
Zacharias
Forum Guru
Forum Guru
Posts: 2309
Joined: Tue Dec 12, 2017 12:58 am
Location: Greece

Re: CRS317 Bridge MTU not changing

Tue Oct 15, 2019 11:35 pm

Change it to what?
1500 Byte is the size of an ethernet frame...
Your bridge has a correct MTU...
 
mkx
Forum Guru
Forum Guru
Posts: 5272
Joined: Thu Mar 03, 2016 10:23 pm

Re: CRS317 Bridge MTU not changing

Wed Oct 16, 2019 9:10 am

Change it to what?

Change it to e.g. 10000.

I've checked it on my RBD52G and behaves the same way. l2mtu is set to 1598 and there's no way to set mtu to anything larger than l2mtu.

And conducted a test: I created a new bridge and it appeared with l2mtu set to 65535. And I could set mtu to 10000 without a problem. After that I added a wifi interface to that bridge and bridge properties changed automagically: l2mtu changed to 1600 and actual-mtu changed to 1500 (while mtu remained set to 10000). If I then tried to set mtu to anything larger than l2mtu (but smaller than previously set 10000), ROS complained with "failure: could not set mtu". If I then removed wifi interface from that bridge, the l2mtu and actual-mtu changed back to initial values (65535 and 10000).

So it seems that l2mtu of a bridge gets set to smallest l2mtu value of all slave interfaces (OP should check the whole list of interfaces, from the screenshot it's not clear if the whole list is shown or it's actually truncated) and can not be set. And it's logical that MTU of bridge is set to smallest MTU value of slave interfaces ... bridge (the switch-like entity, being L2) doesn't perform fragmentation (only L3 device can do that), so bridge interface (which is actually used by router to interact with that L2 domain, it's not used when "only" switching traffic between slave interfaces) should have MTU small enough to pass whole ethernet frame via any of its slave interfaces ... because the egress physical port for a frame gets known only after frame lands on the bridge (the switch-like entity) consulting ARP tables.

Which means that OP's setup with different MTU settings for different interfaces, enslaved to the same bridge, is logically invalid. And it could happen that if all slave interfaces got mtu set to same (jumbo) value, it would be possible to set larger MTU on bridge interface.
BR,
Metod
 
Zacharias
Forum Guru
Forum Guru
Posts: 2309
Joined: Tue Dec 12, 2017 12:58 am
Location: Greece

Re: CRS317 Bridge MTU not changing

Wed Oct 16, 2019 3:39 pm

mkx, the MTU of an ethernet frame is 1500 Byte.. The MTU of an IP Packet is 65535 Byte.
The MTU of the Bridge will take the value of the lowest interface inside the Bridge...

L2MTU indicates the maximum size of the frame without MAC header that can be sent by this interface. https://wiki.mikrotik.com/wiki/Manual:M ... n_RouterOS
L2MTU is used in packet forwarding...

L3MTU Specifies how big IP packets router is allowed to send out the particular interface.. Same Source.
L3MTU is used in routing.. so we can let MTU as is if we dont care about routing packet size... and only change L2MTU for packet forwarding...

However the actual MTU always remains 1500 Byte.. So whatever happens the packet will be fragmented to 1500 Byte.. Right ? I dont understand what that "actual MTU" refers to....!!!
 
mkx
Forum Guru
Forum Guru
Posts: 5272
Joined: Thu Mar 03, 2016 10:23 pm

Re: CRS317 Bridge MTU not changing

Wed Oct 16, 2019 7:37 pm

mkx, the MTU of an ethernet frame is 1500 Byte.. The MTU of an IP Packet is 65535 Byte.
...
However the actual MTU always remains 1500 Byte..
How about reading some docs about ethernet frame sizes? Start with Wikipedia article. IP datagram max size is 65535 bytes (and this is not referred to as MTU).

So whatever happens the packet will be fragmented to 1500 Byte.. Right ?
Right ... by an L3 device, such as router. Not by L2 device, such as switch or bridge.

I dont understand what that "actual MTU" refers to....!!!
As I wrote: while bridge had l2mtu of 65535, I set mtu to 10000 ... after I added wlan interface with l2mtu of 1600, bridge l2mtu reduced to 1592 and actual-mtu shrunk to 1500 ... but mtu property remained 10000. And documentation states that actual-mtu and l2mtu are read-only ...
So mtu is wanted value, but if it's set too high due to any reason, ROS reduces it and displays actual value ...
BR,
Metod
 
Zacharias
Forum Guru
Forum Guru
Posts: 2309
Joined: Tue Dec 12, 2017 12:58 am
Location: Greece

Re: CRS317 Bridge MTU not changing

Wed Oct 16, 2019 8:00 pm

Byte..
How about reading some docs about ethernet frame sizes? Start with Wikipedia article. IP datagram max size is 65535 bytes (and this is not referred to as MTU).
What?
Maybe you should read some docs!!!

In the context of Internet Protocol, MTU refers to the maximum size of an IP packet that can be transmitted without fragmentation over a given medium.

Also the IPv4 MTU is 64 kib which is 65535 Byte...

Besides that, Nearly all IP over Ethernet implementations use the Ethernet II frame format.

The ethernet 2 format is between 64 to 1518 Bytes...
Source: https://en.m.wikipedia.org/wiki/Maximum ... ssion_unit

I always read!!!
 
Michaelcrapse
newbie
Topic Author
Posts: 26
Joined: Wed Oct 25, 2017 9:57 pm

Re: CRS317 Bridge MTU not changing

Wed Oct 16, 2019 8:30 pm


So it seems that l2mtu of a bridge gets set to smallest l2mtu value of all slave interfaces (OP should check the whole list of interfaces, from the screenshot it's not clear if the whole list is shown or it's actually truncated) and can not be set. And it's logical that MTU of bridge is set to smallest MTU value of slave interfaces ... bridge (the switch-like entity, being L2) doesn't perform fragmentation (only L3 device can do that), so bridge interface (which is actually used by router to interact with that L2 domain, it's not used when "only" switching traffic between slave interfaces) should have MTU small enough to pass whole ethernet frame via any of its slave interfaces ... because the egress physical port for a frame gets known only after frame lands on the bridge (the switch-like entity) consulting ARP tables.
Yes, i've posted an exhaustive list of interfaces, that is the first thing i checked and double checked.
Which means that OP's setup with different MTU settings for different interfaces, enslaved to the same bridge, is logically invalid. And it could happen that if all slave interfaces got mtu set to same (jumbo) value, it would be possible to set larger MTU on bridge interface.
[/quote]
I've attached another picture, of a CRS305, setup the same way, the reason we do this is that some devices have an MTU limit, but we have plans to swap them later, and rather than changing uplink MTUs in deployment, we set those to their final values.

As said you suggest, technically, we should just set all l2mtu always to 10218, because technically only L3MTU matters as long as l3 MTU is set correctly(and l2 is sufficiently large enough) then the routers will do the fragmenting required to send over the interface. To be honest, i have very little idea why mikrotik ships their products with a default 1600byte l2mtu when they should just give it the max l2MTU always. Most other enterprise switches do this by default. There are some that are stupid and put the l2MTU really low(ubnt edgepoint, netonix).
You do not have the required permissions to view the files attached to this post.
 
mkx
Forum Guru
Forum Guru
Posts: 5272
Joined: Thu Mar 03, 2016 10:23 pm

Re: CRS317 Bridge MTU not changing

Wed Oct 16, 2019 9:37 pm

In the context of Internet Protocol, MTU refers to the maximum size of an IP packet that can be transmitted without fragmentation over a given medium.

Also the IPv4 MTU is 64 kib which is 65535 Byte...
... over given medium ... which is L2, in our case ethernet with its limitation, whatever it might be (perhaps standard 1500 bytes plus overhead or jumbo with over 10kB frame sizes). I've yet to see transport technology (L2) with support for 64kB frames.

And we aren't discussing the "nearly all IP" practice, OP wanted to use jumbo frames and that's it.
BR,
Metod
 
mkx
Forum Guru
Forum Guru
Posts: 5272
Joined: Thu Mar 03, 2016 10:23 pm

Re: CRS317 Bridge MTU not changing

Wed Oct 16, 2019 9:54 pm

There's distinction between bridge "interface" MTU and bridge ports MTU: the later define maximum frame sizes that may pass the interface and has to be in agreement with the other end of the link (no use in sending frame that overflows the receiver). The former (bridge interface MTU) is more about the L3 interface and it's logical that it's set to lowest value from member ports.

There is a problem with mixed MTU sizes of ports, members of same bridge ... some large frame might ingress through "large MTU" interface and should egress through "not so large MTU" interface. In this case bridge will drop such frame. Which makes obvious the necessity to have same MTU set on all L3 devices members of same broadcast domain (and it should be low enough so that any L2 interface can transport it). If one adds complexity of fragmentation/defragmentation it becomes clear why vast majority of IP networks stick to good ole standard 1500 byte MTUs.

So it's fine for OP to have different MTUs on ports of same bridge, but actual-mtu should end up being same on all drvices (servers, routers, client machines, ...).

And my speculation about why vendors don't support huge MTUs just on all of their devices: if L2 device (switch) is a store&forward device (most of them are), then large configurable MTU sizes mean larger RAM (used as frame cache) is needed ... rising price of device (every penny counts) ... for a feature which is rarely used anyways.
BR,
Metod
 
Zacharias
Forum Guru
Forum Guru
Posts: 2309
Joined: Tue Dec 12, 2017 12:58 am
Location: Greece

Re: CRS317 Bridge MTU not changing

Wed Oct 16, 2019 10:06 pm

Exactly mkx... the MTU should be lower than the L2MTU..

You cant set an MTU larger than L2MTU...
There is a good reference about that here https://wiki.mikrotik.com/wiki/Manual:L ... _interface
 
Michaelcrapse
newbie
Topic Author
Posts: 26
Joined: Wed Oct 25, 2017 9:57 pm

Re: CRS317 Bridge MTU not changing

Wed Oct 16, 2019 11:36 pm

This looks like it's in the beta release changelog.. So it's a known bug, just have to wait until it's brought to stable or LTS
 
User avatar
pukkita
Trainer
Trainer
Posts: 3038
Joined: Wed Dec 04, 2013 11:09 am
Location: Spain

Re: CRS317 Bridge MTU not changing

Mon May 11, 2020 7:16 pm

And my speculation about why vendors don't support huge MTUs just on all of their devices: if L2 device (switch) is a store&forward device (most of them are), then large configurable MTU sizes mean larger RAM (used as frame cache) is needed ... rising price of device (every penny counts) ... for a feature which is rarely used anyways.
I think the reason, specially on WISP-oriented gear, not to use jumbo frames by default, is due to radios not being able to pass L2 jumbo frames at all... you have to use the minimum commonly supported one and use it throughout the network/segment to avoid fragmentation.

Also not all RB's support the same L2MTU size: radios rarely go much higher than 2000, small RBs higher than 4000 something, only 1100, some CRS switches, and CCRs have >9000 L2MTU.

So makes sense to set a minimum "commonly supported" L2MTU by default, it's up to the admin to properly set an L2MTU tailored for his network/segment hardware in order to maximize performance and avoid fragmentation.

As has been said previously, ROS will pick the smallest L2MTU amongst the bridge ports L2MTU for the bridge interface.

Does it pick the expected L2MTU if you disable the VLAN hanging from the bridge?
Simplicity is the Ultimate Sophistication - Da Vinci
Getting the most out of this forum

Who is online

Users browsing this forum: No registered users and 2 guests