Manual:Maximum Transmission Unit on RouterBoards: Difference between revisions
No edit summary |
|||
| Line 90: | Line 90: | ||
==RouterOS features and MTU== | ==RouterOS features and MTU== | ||
There are several features in MikroTik RouterOS that is can benefit from possibility to exceed standard MTU | |||
===VLAN=== | ===VLAN=== | ||
When tagged by VLAN-id (802.1Q) inserts a 4-byte tag and recomputes the frame check sequence (FCS): requires additional 4-bytes | |||
===MPLS=== | ===MPLS=== | ||
===PPPoE=== | |||
===EOIP=== | ===EOIP=== | ||
===PPTP=== | ===PPTP=== | ||
Revision as of 14:06, 19 December 2008
Background
There are several different values of standard (IEEE) MTU out there and it might cause some confusion:
- 1518 bytes - for standard (IEEE) Ethernet frames, this include Layer-2 header (14 bytes) and FCS (Frame Check Sum) 4bytes - this is MTU of the frames that travel thought the wires
- 1514 bytes - for standard (IEEE) Ethernet frames, this include Layer-2 header (14 bytes), but without FCS - This is MTU of the frame that software work with
- 1500 bytes - for standard (IEEE) Layer-3 (IP) packets, this excludes both Layer-2 header and FCS - This is value that can be configured in MikroTik RouterOS
So basically all those values are the exactly the same thing only from different point of view (from physical, Layer-2 and Layer-3 point of view)
Originally MTU was introduced because of the high error rates and low speed of communications. Fragmentation of the data stream gives ability to correct corruption errors only by resending corrupted fragment, not the whole stream. Also on low speed connections such as modems it can take too much time to send a big fragment, so in this case communication is possible only with smaller fragments.
But in present days we have much lower error rates and higher speed of communication, this opens a possibility to increase the value of MTU. By increasing value of MTU we will result in less protocol overhead and reduce CPU utilization mostly due to interrupt reduction.
This way some non-standard frames started to emerge:
- Giant or Jumbo frames - frames that are bigger than standard (IEEE) Ethernet MTU
- Baby Giant or Baby Jumbo frames - frames that are just slightly bigger that standard (IEEE) Ethernet MTU
In order to communicate with such frames it is required that every device in the frame's way (even switches) support that particular frame size. As this is non-standard feature each vendor have different MTU supported.
MTU on RouterBoards
Here is a table of MTU (with Layer 2 header, but without FCS) supported by Mikrotik RouterBoards:
| RouterBoard | ether1 | ether2 | ether3 | ether4 | ether5 | ether6 | ether7 | ether8 | ether9 |
|---|---|---|---|---|---|---|---|---|---|
| RB493, RB493AH | 1522 (+8) | 1518 (+4) | 1518 (+4) | 1518 (+4) | 1518 (+4) | 1518 (+4) | 1518 (+4) | 1518 (+4) | 1518 (+4) |
| RB450 | 1522 (+8) | 1518 (+4) | 1518 (+4) | 1518 (+4) | 1518 (+4) | ||||
| RB433, RB433AH | 1522 (+8) | 1518 (+4) | 1518 (+4) | ||||||
| RB411, RB411A, RB411AH | 1522 (+8) | ||||||||
| CrossRoads | 1600 (+86) | ||||||||
| RB1000 | 9500 (+7986) | 9500 (+7986) | 9500 (+7986) | 9500 (+7986) | |||||
| RB600, RB600A | 9500 (+7986) | 9500 (+7986) | 9000 (+7486) |
RouterOS features and MTU
There are several features in MikroTik RouterOS that is can benefit from possibility to exceed standard MTU
VLAN
When tagged by VLAN-id (802.1Q) inserts a 4-byte tag and recomputes the frame check sequence (FCS): requires additional 4-bytes